公開日 ・ 約16分で読めます
AIに仕事を任せるプロンプトの設計。完了・検品・上限の書き方
AIに仕事を任せるプロンプトの設計とは、何を・どんな形式でと指示する前に「何ができたら終わりか」「誰が検品するか」「何回で打ち切るか」の3つを先に書き、終わりの判定をAIの自己申告から切り離す書き方のことです。
僕はAIVESTという会社を経営しながら、自分でもClaude Codeを触り、アプリ開発・社内ツール・マーケ制作の指示文を同じ型で書いてきました。検索で出てくるプロンプトの書き方は、要素・原則・例文集までは揃っています。この記事はそこに無い「出口側の設計」を、自社の指示文の現物と、毎朝の記事便が「AIの自己申告ではなくコードの判定で止まる」実例で埋めます。ChatGPTやGeminiに業務を頼む場合でも、同じ型で書けます。
AIに仕事を任せるプロンプトの設計とは。終わり方を先に書くこと
入力側の5要素は前提として押さえる
上位の解説が扱う「指示・文脈・入力データ・出力の形式・役割」といった要素や、「具体的に書く」「例を示す」「役割を与える」といった原則は、僕も前提として大事だと思っています。これらはPrompt Engineering Guideの「プロンプトの要素」やAnthropicの公式ドキュメントに整理されているもので、僕の発明ではありません（出典は末尾）。1回の質問で答えが返る用途なら、ここまでで十分です。
業務を任せるなら、出口側の3つを先に書く
問題は、1回の返答で終わらない仕事を任せるときです。記事を1本仕上げる、社内ツールを作る、資料を作って検品まで通す。こういう仕事は、AIが「できました」と言った時点で終わるのではなく、何かが真になった時点で終わるように書かないと、終わりがAIの気分で決まります。
僕が指示文に必ず入れているのは、次の3つです。
先に固定した、測れる基準（何ができたら終わりか）
作った本人ではない判定者（誰が検品するか）
達成または上限（何回で打ち切るか）
この3つが1つでも欠けると、停止の判定は主観に戻ります。これがこの記事の背骨で、以下はこの3つを順に、書き方まで落としたものです。
なぜ「改善して」「全部やって」は失敗するのか
2026年8月下旬から9月上旬にかけて、Xでは「『改善して』と言うとよくわからない結果になる」という投稿や、「Claude Codeに『全部やって』と言うのをやめろ」という趣旨の投稿が続けて見えました（出典は末尾）。僕はこれを「言い方が雑だから」ではなく、指示文に3つの欠落があるからだと見ています。
欠落1: 終わりがない
「改善して」には、改善が終わった状態の定義がありません。AIは何かを変えて「改善しました」と返します。変えた内容が期待と違っても、指示文の側に照合する基準がないので、違うと言えるのは読んだ人の感覚だけです。基準が後から決まる指示は、必ず「まあこれでいい」に着地します。
欠落2: 採点者が本人
「全部やって」と頼まれたAIは、作った本人が「全部できました」と申告します。作った本人は自分の成果物の欠けに気づきにくく、気づいても直せる範囲に判定を寄せます。人の仕事で作業者と検品者を分けるのと同じ理由で、AIでも分けないと甘くなります。
欠落3: 上限がない
「納得いくまで直して」は、止まる保証がありません。従量課金なら費用が、定額プランなら利用枠が、上限なしに消えます。止まったとしたら、それはたまたまです。
先に書くこと①: 何ができたら終わりか。完了条件を測れる形で固定する
悪い例と良い例
悪い例は「読みやすい記事にして」「品質を上げて」です。判定を相手に丸投げしています。良い例はこうなります。
本文が2,500字以上ある
見出しが3本以上あり、そのうち1本は疑問形である
本文中のリンクに切れているものがない
指定した箇条書きの7項目が、すべて本文に登場する
違いは、着手前に決まっていて、第三者が同じ答えを出せることです。文章の良し悪しのような主観的な質も、いきなり人の判断に回さず、まず形式（存在・件数・数値）、次に機械で測れる代理指標（文字数・リンク切れ・必須項目の有無）、最後にどうしても残る判断、の順に落とします。人の判断に残る部分を減らす作業が、設計の実質です。
完了述語を1行で書く
僕は指示文に、合格条件の散文とは別に「完了述語」を必ず1行入れています。完了述語とは、実行すると合否が終了コード（正常終了なら0）で返るコマンドのことです。
完了述語: 検査スクリプトが exit 0 を返すこと。検査内容: 必須7節の存在／本文のリンク切れ0／画像枚数が2〜5枚（自社の指示文の規約より）
散文の合格条件だけを渡すと、実行するAIが結局それを主観で解釈し、停止条件が主観に戻ります。検査スクリプトがまだ無いなら、それを作ることを最初の担当の仕事に含めるのが僕の規約です。どうしても機械で判定できない場合は「機械判定は不可能」と明記し、代わりに判定者を2名以上に増やします。黙って省略はしません。
先に書くこと②: 誰が検品するか。作った本人に採点させない
検品者は3通りから選ぶ
別のAI: 成果物だけを渡し、作った経緯は渡さない。新しい会話で起動する
人: 最終判断が要る箇所だけに絞る。判定待ちは1か所に集める（人の判定待ちを集約する仕組みの記事）
検査スクリプト: 形式と数値はここに寄せる。人とAIの判定を減らす（記事の機械ゲートの記事）
順番は、スクリプトで測れるものは全部スクリプト、残りを別のAI、最後に人です。
検品者に渡す3つの決まり
別のAIに検品させるとき、「厳しくレビューして」とだけ書いても厳しさは再現しません。僕は指示文に次の3点を書きます。
既定は不合格。進捗のために合格を出さない
判定は合格・要修正の二値。合格には成果物からの逐語引用を必ず添え、引用できない合格は無効とする。0〜10点の採点はしない（甘くなり、ばらつく）
差し戻しは「対象物の名前・観測した症状・推定原因」の3点で書く。曖昧な賞賛や励ましは役割の失敗
検品者に修正させないことも重要です。判定と修正を同じ人格に持たせると、直せる範囲に判定が寄ります。
先に書くこと③: 何回で打ち切るか。上限の数値と打ち切り後に残すもの
上限は数字で書く
僕の既定は「最大3ラウンド、担当は5〜7体まで」です。依頼する側が「上限は要らない、納得するまで回して」と言っても、上限は書きます。上限があるから、費用の見積もりが1行で書けます（担当数×ラウンド数×判定者数）。ハードストップの考え方全般はAI自動化のリスク設計の記事に書きました。
打ち切ったときに何を残すか
上限に達したときの規約を、達する前に書いておきます。
何を落とすか（優先度の低い要件を明示的に外す）
何を残すか（絶対に落とせない要件）
残った未達を成果物に明記する
成果物の一覧に「未達の正直な開示」の欄を先に用意しておくのが、正直さを設計で作る唯一の方法だと僕は思っています。書く欄が無い成果物は、必ず「完璧です」と言って出てきます。
そのまま使えるプロンプトの書き方。指示文の型7手順
僕が自社の指示文を書くときの型です。手順の番号が、そのまま指示文の節の順番になります。穴埋めのテンプレートは末尾の付録に置きました。
何を作るかを1〜2文で書き、水準は「〜ではない」の否定形で下限を切る。例: 「社内共有で終わる資料ではなく、そのまま顧客に出せる水準」。「高品質に」は判定の丸投げ
着手前に、測れる形で固定する。形式・数値・必須項目。「以後のすべての判定は、この条件に対して採点する」の1文を添える
領域ごとに担当を1つずつ置き、責務を重ねない。部品を合わせる「合成」の担当を必ず1つ明示する
作った本人とは別に置く。既定は不合格・二値判定＋逐語引用・指摘は対象物名＋症状＋推定原因
最大ラウンド数を数字で書く。上限到達時に何を落とし、何を残すかを書く
成果物一覧に「残っている未達」の欄を作る。空欄で出すことを許可する
「検査スクリプトが exit 0 を返すこと」と検査内容を列挙する。無いなら、作ることを担当1の仕事に含める
反復の1周は「実装→実行→証拠の捕捉（ログ・出力ファイル・画面）→検品→修正」です。証拠の捕捉を省くと、検品者は現物ではなく報告文を評価することになり、自己申告に戻ります。
禁止事項は失敗から条文にする。2026年7月23日の実障害
「〜するな」の禁止事項を思いつきで並べても効きません。僕は、起きた事故だけを条文にしています。
自社のブログ記事便は、毎朝定時に企画・執筆・画像・最終投稿の4工程を子のAIに分けて回しています。2026年7月23日の朝9時12分の便で、画像工程のAIが画像生成をバックグラウンドで待ったままターンを終え、決められた形式の結果を返さずに便全体が失敗しました。この事故は、画像工程の指示文に次の1文として残っています。
生成は必ずフォアグラウンドで1枚ずつ直列に行う。バックグラウンド実行の使用禁止（生成待ちでターンを終えると結果が返らず、便全体が失敗する。2026年7月23日9時12分便の実障害）
事故の日時と、何が起きたかを1文で記録する
「何をしていれば防げたか」を、実行するAIが従える禁止形か命令形の1文に言い換える
その1文を、該当する工程の指示文に、事故の日付つきで追記する
同じ事故を検出する検査項目を、可能なら検査スクリプトにも足す
日付を条文に残すのは、後で読んだ人（未来の自分を含む）が「なぜこの制約があるのか」を追えるようにするためです。事故を検査項目へ昇格させる運用の全体はAI運用の再発防止の記事に書きました。
自社の実例。毎朝の記事便のプロンプトはどう止まるか
返す項目を先に固定する
記事便の4工程は、それぞれ「返す項目」が指示文の側で先に決まっています。企画工程なら記事ディレクトリ・slug・タイトル・仮説・構成・不採用案。執筆工程なら本文文字数・見出し数・FAQ数・使った一次情報。答案用紙の欄を先に決めておくと、AIは自由文で「できました」と返せません。欄が埋まらなければ、その時点で失敗として扱えます。
公開の完了述語は、機械ゲートの終了コード
最終工程の指示文には「判断せず、決められたコードを順に実行して結果を報告する係」と書いてあり、公開の条件は1行です。
検査スクリプトが exit 0 なら公開する
検査の中身は、タイトル32字以内・抜粋80〜120字・本文2,500字以上・見出し3本以上・狙いキーワードの含有・内部リンクの実在・画像枚数2〜5枚と画像URLの応答などです。落ちた場合の修理は1回だけ。再失敗ならそこで止めて未達を報告し、公開しません。「基準の緩和や検査の回避は絶対にしない」と指示文に明記してあります。これが、上限と打ち切り規約の自社での実物です。AIが自分で改善を回す側の仕組みはループエンジニアリングの記事に書きました。
同じ型で書いた指示文が39件ある
2026年9月5日時点で、この型で書いた指示文のファイルは、自社のアプリ開発・社内ツール・マーケ制作を合わせて39件あります（複製を除いた実数）。正直に書くと、39件それぞれの実行結果を1件ずつ突き合わせた記録はこの記事のためには照合していないので、「この型にすると品質が何割上がる」といった数値はここでは書きません。書けるのは、同じ型を39回使ってきたという事実までです。
型を作る前は、指示文を書くたびに「今回はどこで止めるか」を考えていました。今は7つの欄を埋めるだけで、止まり方が先に決まります。考える時間が減ったというより、考える場所が固定された感覚です。
繰り返し使う指示文はスキルとして保存しておくと、毎回書き直さずに済みます（Claude Codeのカスタムスキルの記事）。指示書に文脈をどう持たせるかは、次の記事に委ねます。
関連記事ChatGPTのメモリ機能を業務で使う。覚えさせない線引きの設計ChatGPTのメモリ機能は会話をまたいで文脈を記憶する仕組みです。業務利用の鍵はオンオフ操作ではなく、何を覚えさせ何を覚えさせないかの設計。AIに会社の文脈を持たせて毎日運用する僕が、3層設計と鮮度管理の実務を解説します。書いたプロンプトを出す前に検査する8項目
僕は書いた指示文自体を、渡す前に検査スクリプトに通しています。終了コードは不合格の数で、0でなければ渡しません。「停止条件をコードに置け」と言う指示文を、自分は目視で通す、というのは通らないからです。検査項目を一般語に直すと次の8つです。
目的と、水準の明示的な宣言があるか（「〜ではない」型で下限を切っているか）
基準が着手前に固定され、数値か決定的な述語で測れるか
担当分けが2つ以上あり、1領域1所有者になっているか
反復の1周に「証拠の捕捉」が含まれているか
検品者が生産者から独立していると明記されているか
ラウンド上限の数値と、上限到達時の打ち切り規約の両方があるか
成果物一覧に「未達の開示」の欄があるか
完了述語が実行できるコマンドとして書かれているか（または「機械判定は不可能」と明示しているか）
8項目のうち6（上限）と8（完了述語）は省略禁止にしています。この2つが欠けた指示文が、いちばん「止まらない」からです。
プロンプト設計でよくある質問
AIへの指示を、要素（指示・文脈・入力・出力・役割）と書き方の原則に沿って組み立てることを指すのが一般的な意味です。僕は、業務を任せる指示に限っては「何ができたら終わりか・誰が検品するか・何回で打ち切るか」を先に決めて書くことまでを設計と呼んでいます。入力側だけ設計しても、終わりはAIの自己申告のままだからです。
一般には「具体的に書く」「例を示す」「役割を与える」などが3原則として挙げられます（出典は末尾）。僕が業務を任せる指示で守っている3つは別で、「先に固定した測れる基準」「作った本人ではない判定者」「達成または上限」です。前者は良い答えを引き出す原則、後者は仕事を止める原則で、両方要ります。
この記事の型7手順を、そのまま節にして書きます。目的と水準、完了条件、担当分け、検品者、上限と打ち切り、未達の開示、実行できる完了述語です。設計書と指示文を分けず、指示文そのものをファイルとして保存し、差分が取れて再実行できる形にしておくと、事故が起きたときに条文を足す場所になります。
「良い感じに」「改善して」を禁句にして、終わった状態を先に書くことです。1回の質問で終わる用途なら、具体的に・例を示す・形式を指定する、で十分です。反復が要る仕事なら、完了条件を測れる形にし、検品者を本人と分け、上限を数字で書きます。
重要な要素は、入力側の5要素と出口側の3つで、ツールが変わっても同じです。変わるのは完了述語の実行手段です。Claude Codeのようにコマンドを実行できる環境なら検査スクリプトを完了述語にできます。ChatGPTやGeminiのチャット画面なら、検品は別の会話か人が担当し、完了条件のチェックリストを渡して照合させる形になります。
まとめ。完了・検品・上限を先に書く
AIに仕事を任せるプロンプトの設計を、自社の指示文の現物と記事便の実例から整理しました。
「改善して」「全部やって」が失敗するのは、終わりがない・採点者が本人・上限がない、の3つの欠落があるから
先に書くのは、測れる完了条件、本人ではない検品者、ラウンド上限と打ち切り規約の3点セット
完了述語は「検査スクリプトが exit 0 を返すこと」の形で1行書く。無いなら作ることを最初の担当に含める
禁止事項は思いつきで並べず、起きた事故を日付つきで条文にする
書いた指示文自体を8項目で検査してから渡す
自社の業務をAIに任せる指示文を、完了条件と検品の設計から一緒に作りたい場合は、AI顧問サービスの内容を確認のうえお問い合わせからご相談ください。
AIに任せた業務で起きた事故を「機械が合否判定できる1文」に言い換え、実行前の関門と回帰検査に固定する5ステップを、事故1件ごとに書き込める記入式の「AI運用 再発防止チェックシート」を無料で配布しています。この記事の「事故を条文にする手順」をそのまま運用に載せる下書きに使えます。
付録。指示文の型の穴埋めテンプレート
目的と水準: ＿＿を作る。水準は「＿＿ではなく、＿＿」
完了条件: ＿＿／＿＿／＿＿（以後のすべての判定は、この条件に対して採点する）
担当: 1. ＿＿（＿＿を所有） 2. ＿＿（＿＿を所有） 3. 合成担当 ＿＿
反復: 実装→実行→証拠の捕捉（＿＿）→検品→修正
検品者: 生産者と別に起動する。既定は要修正。合格・要修正の二値＋逐語引用。指摘は対象物名・症状・推定原因
上限と打ち切り: 最大＿ラウンド。到達時は＿＿を落とし、＿＿を残す
成果物: ＿＿／各ラウンドの検品記録／未達の開示（空欄可）
完了述語: ＿＿が exit 0 を返すこと（検査内容: ＿＿／＿＿／＿＿）
出典
線引きを先に書きます。「完了・検品・上限を先に書く」という整理、指示文の型7手順、8項目の検査、事故を条文にする手順、記事便の実物と39件の件数は、僕の自社運用の記録（指示文の規約と検査スクリプト、記事便の指示文と定時実行ログ。いずれも社内記録）に基づく一次情報です。借りた部分は3つあります。「停止条件＝ゴール達成またはターン上限」というゴール駆動型の定義は、僕がハーネス設計で参照している設計パターン集の定義で、僕の発明ではありません。プロンプトの要素と原則は下記の公式資料に、丸投げ指示と自己採点への警告は下記のX投稿に依っています。
Anthropic公式ドキュメント: プロンプトエンジニアリングの概要（2026年9月5日確認）: 明確に書く・例を示す・役割を与える等の原則
Prompt Engineering Guide「プロンプトの要素」（promptingguide.ai・リンクは省略）: 指示・文脈・入力データ・出力指示子の4要素。上位記事はこれに役割を加えた5要素で整理しているものが多い
@risu_aiafi の投稿（x.com）（2026年9月3日確認）: 「会社作って」「全部やって」と言うのをやめろ、という趣旨
@daifukujinji の投稿（x.com）（2026年9月3日確認）: 成果物を作った本人に検品させるな、検品は専任を置け、という趣旨
@suthio_ の投稿（x.com）（2026年9月3日確認）: 「改善して」と言うとよくわからない結果になる、という趣旨
上位記事の網羅範囲の確認に参照したもの（リンクは省略・2026年9月5日確認）: SHIFT、日立ソリューションズ・クリエイト、cocoo、Smart at、AI総研の各プロンプト解説。いずれも要素・原則・型・例文集の入力側を丁寧に扱っており、本記事は上位が扱っていない出口側の設計（完了条件の固定・検品者の独立・上限と打ち切り・事故から条文・指示文自体の検査）に絞りました
この記事が役に立ったらシェア
Related
