AIに実装を頼むときの依頼文テンプレ｜この5行があれば戻りが減る

AIに実装を頼む依頼文は、目的・現状・やること・やらないこと・完成の条件の5行から始めます。 長い説明は要りません。大事なのは、AIが迷いやすい場所を先にふさぐこと。この5行は、私が毎日の実装依頼で実際に使っている型です。

この記事で分かることは4つ。5行テンプレートの使い方、具体的な埋め方、項目が抜けたときに起きる失敗、そして5行だけでは足りないときの情報の足し方です。

まずはこの5行をそのまま使う

AIへの実装依頼のテンプレートを探しているなら、まず次の形をそのまま使ってください。

目的：この変更で、誰の何を良くしたいか
現状：今どうなっていて、何に困っているか
やること：変更する場所と動きを具体的に
やらないこと：触ってほしくない場所や今回は後回しにすること
完成の条件：何を確認できたら終わりか

先にひとつ、正直に書いておきます。この5行は、どこかの会社が決めた公式の書式ではありません。OpenAIは、Codexへの良い依頼に入れる要素として「望んでいる動き」「関係するコードや再現手順」「守ってほしい制約」「変更を確かめる方法」を挙げています(Codexのプロンプトの書き方)。この記事の5行は、その要素を初心者がそのまま書ける順番に並べ直した実用の型です。

5行すべてを長く書く必要はありません。各行が一文でも、何もない状態よりずっと伝わります。それぞれの行には担当があり、抜けると起きる失敗も決まっています。

行	担当する仕事	抜けたときに起きやすいこと
目的	目指す結果を共有する	作りは丁寧なのに、方向がずれる
現状	AIが調べ始める入口を決める	別のファイルや古い画面を直される
やること	変更する範囲を決める	望んだ変更が半分しか入らない
やらないこと	触らない境界(柵)を引く	頼んでいない場所まで変わる
完成の条件	終わりの判定(線)を決める	見た目だけ直って「完成」と報告される

OpenAIのモデル向けガイドも、大事な依頼では「前提となる文脈」「守るべき制約」「成功の条件」を分けて渡し、重要な曖昧さが残るときは先に質問させるよう勧めています(OpenAIのモデルガイダンス)。Anthropic(Claude Codeの開発元)も、正確なファイル名・制約・既存の見本を示すほど、修正のやり直しが減ると説明しています(Claude Codeのベストプラクティス)。文脈と制約と成功条件を混ぜずに分ける。5行はそのための仕切りです。

悪い依頼を5行へ直すとこう変わる

GitHub公式のプロンプトの手引きは、「曖昧な言葉を避け、最初に目標を示してから具体的な要件を書く」ことを勧めています(GitHub Copilotのプロンプトの手引き)。悪い例と直した例を並べます。

悪い依頼はこうです。

お問い合わせボタンをいい感じに直して

「いい感じ」では、文字、色、位置のどれを変えるのか決まりません。5行に直すとこうなります。

1. 目的：スマホで見た人が、迷わず問い合わせ画面を開けるようにする。
2. 現状：記事の最後にボタンがあるが、文字が小さく、押せる場所も狭い。
3. やること：ボタンの文字を「お問い合わせ」に変え、スマホでは横幅いっぱいにする。
4. やらないこと：パソコン版の配置、問い合わせ画面の内容、色の設定は変えない。
5. 完成の条件：スマホ幅で文字が切れず、ボタンを押すと今の問い合わせ画面が開く。

変える場所と残す場所が両方あるので、返ってきた結果も確認しやすくなります。自分の場合は昔、「ボタンを見やすくして」とだけ頼み、必要のない色まで変わったことがありました。「色は変えない」という柵を引いていなかったからです。別の場面では、完成の条件を書かなかったため、見た目だけ直って作業が終わり、実際に押すと行き先が違っていました。

不具合の修正でも同じ型が使えます。原因が分からないときの例です。

1. 目的：スマホからログインできない状態を直す。
2. 現状：ログイン画面でメールとパスワードを入れて送信すると、エラー表示のないまま同じ画面に戻る。再現手順は「トップ→ログイン→送信」。
3. やること：まず原因を調べて、変更する前に、疑わしいファイルの候補と直し方を説明する。
4. やらないこと：ログイン処理の外部との通信(API)の呼び方は変えない。会員登録の画面は触らない。
5. 完成の条件：上の再現手順でログインが成功する。関連する最小のテストが通る。

OpenAIの公式ドキュメントにある不具合修正の例でも、再現手順と制約を渡し、修正後に同じ再現手順とテストを実行させています(Codexのプロンプトの書き方)。原因不明のときは「先に調べて説明して」を「やること」に書けばよく、分からないファイル名を推測して書く必要はありません。

完成の条件は「AIが確認できる形」で書く

「きれいになったら完成」は、AIには判定できません。人が見て感じる言葉を、AI自身が確かめられる条件に変えます。たとえば次のような形です。

• 再現手順をもう一度実行して、症状が出ないこと
• 関連する最小のテストが通ること
• ビルド(=公開用にファイルをまとめる処理)が成功すること
• lint(=書き方の自動チェック)がエラーなしで終わること
• スマホ幅のスクリーンショットで、文字が切れていないこと

Anthropic公式も、AIに渡せる合否判定の例として、テスト・ビルド・終了コード・lint・スクリーンショットを挙げています(Claude Codeのベストプラクティス)。ただし、これを毎回全部やる必要はありません。変更の内容に合う最小の確認をひとつかふたつ選べば足ります。実行できない確認があれば、「未確認」として報告してもらいます。

もうひとつ大事なのは、「成功しました」という自己申告で終わらせないことです。実行したコマンドとその結果まで報告するよう、完成の条件に書き添えてください。依頼を送る直前には、初めて読む人になったつもりで見直します。「どの画面か」「何を変えるか」「どこまで確認するか」が一つに決まっていれば送れます。

5行だけで足りないときは情報を足す

短く明確な作業なら5行で走り出せます。ただ、すべての依頼に5行で十分だとは言えません。次の場面では情報を足します。

• 原因が分からない：実装より先に調査を頼む。「変更前に候補を説明する」をやることに書く。
• 変更が大きい：小さな工程に分けて、1回ずつ頼む。GitHub公式も、大きい仕事を複数の小さい作業へ分けるよう案内しています(GitHub Copilotのプロンプトの手引き)。
• 見た目の変更：言葉で形を説明しきれないときは、見本の画像を渡す。
• 既存の書き方に合わせたい：手本になる参考ファイルを1つ示す。
• 黒い画面(CLI)で頼むとき：エディタと違って開いているファイルが自動で伝わるとは限らないため、ファイルのパス(置き場所)を文中に明示する(Codexのプロンプトの書き方)。

また、毎回同じ説明(プロジェクトの決まり・テストのやり方)を貼っているなら、それは依頼文ではなく共通指示ファイルの仕事です。Codexなら AGENTS.md、Claude Codeなら CLAUDE.md、GitHub Copilotなら copilot-instructions.md が対応します。GitHub公式は、こうした共通指示を「短く、それだけで意味が通る文」で書くよう案内しています(Copilotの指示のカスタマイズ)。対応するファイル名や範囲は製品ごとに違い、更新もされるので、使う時点の公式案内で確認してください。

よくある質問

5行はそれぞれ長く書く必要がありますか？

いいえ。一文ずつで始めて大丈夫です。必要な目標・対象・制約・確認方法を一度ずつ簡潔に書き、結果を左右しない背景や、同じ指示の繰り返しはむしろ減らします。OpenAIのガイドも、指示は一度ずつ、簡潔かつ正確に書くよう勧めています。

直すファイル名が分からないときはどう書きますか？

推測でパスを書いてはいけません。画面名・症状・再現手順など分かる範囲を「現状」に書き、「まず関係ファイルを調べて、変更前に候補を説明する」を「やること」に含めます。調査と実装を分けるだけで、間違った場所の書き換えを防げます。

「いい感じに直して」では駄目ですか？

アイデアや提案を集める段階なら使えます。ただ実装の依頼では解釈が分かれます。文字の大きさ、幅、押した後の動き、変えない部分など、目で見て判定できる条件に置き換えてください。

テンプレートを使えば、AIは必ず指示どおりに動きますか？

保証はできません。GitHub公式も、AIは非決定的(=同じ指示に毎回まったく同じようには従わない)だと明記しています(Copilotの指示のカスタマイズ)。だからこそ、完成の条件と、変更差分・検証結果の確認をセットにします。足りなければ、小さく具体的に直して頼み直します。

まとめ

5行は長文を書くための型ではなく、「目標・出発点・範囲・境界・終わりの判定」の抜けを見つけるチェックリストです。次にやることは3つです。

• 次のAIへの依頼で、上の5行テンプレートをコピーし、一文ずつ埋めて送る
• 返ってきたら、完成の条件に書いた確認(動き・テスト・差分)を自分の目でも見る
• 手戻りが起きたら、どの行の情報が足りなかったかを振り返り、自分専用の型に育てる

公式一次情報

確認日: 2026-07-26

• Prompting | ChatGPT Learn: Codexへの良い依頼の要素(望む動作・関係するコードや再現手順・制約・検証方法)と、修正後に再現手順やテストを再実行する例
• Model guidance | OpenAI API: 重要な依頼では文脈・制約・承認の境界・成功条件を分けて渡し、指示は一度ずつ簡潔に書くという案内
• Best practices for Claude Code - Claude Code Docs: 正確なファイル・制約・見本を示すほど修正回数が減ることと、テストやビルドなどAIが読める合否判定の例
• Prompt engineering for GitHub Copilot Chat - GitHub Docs: 目標から具体要件の順で書く・例を与える・大きな仕事を分ける・曖昧な語を避けるという方法
• About customizing GitHub Copilot responses - GitHub Docs: 共通指示は短く自己完結した文で書くことと、AIは同じ指示に毎回同じように従うとは限らないという注意