コードを書かせる前に、依頼内容と前提をメモにまとめてから落ち着いてAIに渡そうとしている開発者
AIコーディング約15分

AIにコードを書かせる前に渡す前提と制約｜伝え方の型

AIに「この処理書いて」と頼んで、返ってきたコードが「動くけど、なんか違う」。 直してもらうたびに少しずつズレて、気づけば自分で書いた方が速かったかも——そんな夜、ありますよね。

原因は、AIの賢さ不足とは限りません。 多くの場合、頼む前に渡せていなかった前提があるだけです。あなたの頭の中にある「当然こうだろう」を、AIは見えていません。だから、もっともらしく、でも微妙に違う方向へ走り出してしまう。

この記事は、AIにコードを書かせる前に渡しておきたい前提と制約を、どう言葉にして渡すかの型にまとめたものです。プロンプトのテクニックというより、手戻りを生まない依頼の組み立て方の話です。深掘りなので少し長めですが、一度に全部やる必要はありません。まず効く所から、一緒に見ていきましょう。

結論：AIにコードを書かせる前に、①ゴールと背景（何のための何か）→ ②入出力の仕様（型・例・並び）→ ③制約（技術・組織・禁止事項）→ ④既存コードの文脈（流儀・依存・置き場所）→ ⑤完成の判断基準（テスト観点）の5つを、短くてもいいので言葉にして渡します。全部書く必要はなく、その依頼で迷いが生まれそうな所だけを埋めれば十分。むしろ多くの依頼は、入出力の例1組＋「やってほしくないこと」1つの2行で足ります。記事後半のテンプレ全体は、重い依頼のときの保険だと思ってください。前提をそろえてから渡すと、生成コードの一発目の精度が上がり、レビューと手直しの往復が大きく減ります。

書く前の数分が、書いた後の数十分を救う。 これは「AIに丁寧にお願いする」マナーの話ではなく、自分の時間を守るための実務です。

なぜ「動くけど違う」が生まれるのか

開発者の頭の中にある前提のうち、言葉にして渡せた一部だけがAIに届き、残りはAIが推測で埋めることを示した概念図

AIは、与えられた文脈のなかで「一番ありそうな続き」を作るのが得意です。 裏を返すと、与えられなかった文脈は、AIの中の「世の中で一番よくあるパターン」で埋められます。それがあなたのプロジェクトの流儀と一致していればラッキー、ずれていれば「動くけど違う」になります。

たとえば「ユーザー一覧を取得する関数を書いて」と頼んだとき、あなたの頭の中には言わなかった前提がたくさんあります。

これらを渡さなければ、AIはそれぞれ「ありそうな方」に決めて書きます。 そして悪いことに、その判断は明示されないまま、コードの中に静かに埋まります。レビューで一つずつ気づいて直す——その往復が、AIで速くなったはずの時間を食い潰していく正体です。

つまり、対策はシンプルです。 AIに推測させていた部分を、先に言葉にして渡す。これだけで、一発目の精度が変わります。次の章から、渡すべき5つを順に見ていきます。

渡し方の全体像：5つの前提

先に地図を出します。次の5つを、依頼の前に（あるいは依頼文の中に）そろえます。

渡すもの何を防ぐか最低限ひとことで言うと
①ゴールと背景的外れな実装・過剰な作り込み「何のための何か」
②入出力の仕様型・並び・件数の取り違え「何を受け取り、何を返すか」
③制約禁止事項違反・機密事故・予算超過「越えてはいけない線」
④既存コードの文脈流儀ズレ・車輪の再発明「この場所での書き方」
⑤完成の判断基準「動くけど違う」の見逃し「どうなれば合格か」

ポイントは、5つ全部を毎回フルで書かないことです。 小さな関数なら①②だけ、既存コードに差し込むなら④が要、本番に出すなら③が要——というように、その依頼で迷いが生まれそうな所を選んで埋めます。全部書こうとすると続きません。続かない型は、型として失敗です。

では一つずつ、何をどう渡すかを見ていきます。

前提1：ゴールと背景——「何のための何か」を一文で

最初に渡すのは、コードの仕様ではなく「これは何を達成するためのものか」です。 ここがあると、AIは細部で迷ったときに「ゴールに沿う方」を選べます。逆にここが無いと、頼んだ通りだけど目的からずれた実装が返ってきます。

渡すと良いこと：

たとえば「速くしたい」と言わずに「月初に経理が使う社内ツールで、1万行のCSVを数秒で取り込めれば十分」と渡すだけで、AIは過剰な最適化も、逆に遅すぎる実装も避けやすくなります。背景は、AIが下す無数の小さな判断の「方位磁石」になります。

前提2：入出力の仕様——型・例・並びまで具体的に

次に、いちばん事故が減るのがここです。 「何を受け取り、何を返すか」を、できれば具体例つきで渡します。言葉で「ユーザー情報」と言うより、実際のデータの形を1つ見せる方が、誤解は桁違いに減ります。

渡すと良いこと：

例として、こう渡します。

入力例: {"userId": "u123", "from": "2026-01-01", "to": "2026-03-31"}
期待する出力例: [{"date": "2026-01-15", "amount": 1200}, ...]
- amount は税込・円・整数
- date 昇順
- 該当なしのときは空配列を返す（null や例外ではなく）

ここまで渡すと、関門2でつまずきがちな境界の扱いを、書く段階で先回りして指定できます。 「該当なしは空配列」「マイナスは0として扱う」のような決めごとは、あなたしか知らない前提です。先に言えば、後で直さずに済みます。

前提3：制約——越えてはいけない線を先に引く

ここは技術というより、「やってはいけないこと」の話です。AIは指示されなければ、便利な方・一般的な方へ進みます。それが組織のルールや既存の設計を踏み越えることがあります。

渡すと良いこと：

特に「やってほしくないこと」は、言わないと伝わりません。 「既存のテーブルは変更しないで」「新しいライブラリは足さず標準機能で」——この一言があるだけで、後から「そこは触ってほしくなかった」と巻き戻す事故が防げます。禁止事項は、自由度を奪うのではなく、AIの迷いを減らして安全な範囲に集中させる枠です。

なお、AIに渡すプロンプトそのものに機密や個人情報を入れてよいかは、コードを書かせる前の確認事項です。ここは「AIで何とかしろ」と言われたら｜まず確認する6つの確認3とも重なります。

前提4：既存コードの文脈——「この場所での書き方」を渡す

前提を渡さない曖昧な依頼と、5つの前提をそろえた依頼を左右に並べ、返ってくる生成コードの精度の違いを示した比較図

既存のコードベースに差し込むコードを書かせるなら、ここが要です。 AIは、与えられなければ「世の中で一番よくある書き方」で書きます。それはあなたのプロジェクトの流儀とは限りません。命名規則、エラーハンドリングの作法、使っているユーティリティ——これらを渡さないと、浮いたコードが返ってきます。

渡すと良いこと：

いちばん効くのは、「似たお手本を1つ見せる」ことです。 言葉で流儀を説明するより、実例を1つ見せる方が、AIはずっと正確に真似します。これは「既存のコードベースにAIを馴染ませる」核心で、車輪の再発明（同じ関数を作り直す）も同時に防げます。渡せる文脈が大きいほど、生成コードは「最初から馴染んだ」状態に近づきます。

とはいえ、レガシーが混ざって書き方の流儀が割れている現場では、どれを手本にすればいいか自体が分からないことも多いはずです。そこで選べずに止まってしまうくらいなら、自分が一番新しく＝マシだと思う実装を1つ貼ればOK。完璧なお手本である必要はありません。「この向きに寄せたい」という1例があるだけで、AIは何もないときよりずっと安定します。

その「見せる」やり方は、いまは一つではありません。お使いの環境に合わせて選べます。

どれを選んでも、思想は同じです。先に前提を言葉にして、AIから見える場所に置く。貼るか、読ませるか、常設するかは、その場の手間と頻度で決めれば十分です。

前提5：完成の判断基準——テスト観点を先に言う

最後に、「どうなれば、できたと言えるか」を渡します。 これは前提2と地続きですが、ここでは「正しく動いたと判断する条件」を、テストの観点として渡すのがポイントです。先に合格条件を言うと、AIはそれを満たすコード（と、ときにテスト自体）を書こうとします。

渡すと良いこと：

たとえば「空のリストを渡しても落ちず空で返すこと、同じIDで2回呼んでも重複登録しないこと」と先に言えば、AIはその2点を意識して書きます。 合格条件を後出しでテストするより、先に渡して書かせる段階で織り込む方が、手戻りは減ります。もちろん、生成されたテストを鵜呑みにはしません。テストが緑でも人が一段見る前提は、ここでも変わりません。

ありがちな落とし穴と、その回避

型を使ううえでつまずきやすい所を、先に潰しておきます。

落とし穴の多くは、「渡せば伝わるはず」という思い込みから来ます。 渡すのは出発点で、ゴールは渡した前提どおりのコードが返ること。そのために、最後の確認だけは手放さないでおきましょう。

明日からやること（小さく始める3つ）

全部を仕組み化しようとすると重いので、まずこの3つから。

  1. 依頼の前に、入出力の例を1組だけ書く：「この入力でこの出力」を1つ。前提2が片付くだけで、取り違えの多くが消えます。
  2. 「やってほしくないこと」を一言添える：「既存テーブルは変更しないで」など禁止を1つ。前提3の一番重い事故が防げます。
  3. 似たお手本を1つ見せてから頼む：流儀を言葉で説明する代わりに実例を見せる。どれを手本にするか迷ったら、一番新しいと思う実装でOKです。依頼文に貼ってもいいし、エージェント型ツールなら対象ファイルを読ませてもいい。前提4が一気に効きます。

この3つだけでも、生成コードの一発目がかなり変わります。 慣れてきたら、後半のテンプレを下敷きにして、ゴールや完成基準も足していけば十分です。

コピーして使う「依頼テンプレ」

新しい依頼のたびに、必要な行だけ埋めて使ってください。依頼文にそのまま貼ってもいいですし、毎回似た前提になるなら CLAUDE.md やルールファイルに常設しておいて、依頼では差分だけ書く形でもかまいません。空欄は消してかまいません。一度に全部でなく、その依頼で迷いそうな所だけで十分です。

# 依頼の前提

## ゴール・背景
- 何のための何か：
- 使う人・場面：
- どこまでやれば十分か（対象外も）：

## 入出力
- 入力（型・例）：
- 出力（型・例）：
- 並び順・件数・単位：
- ありえない値の扱い（空・null・負）：

## 制約
- 言語・バージョン・環境：
- 使ってよい/ダメなライブラリ：
- 機密・個人情報の扱い：
- やってほしくないこと（禁止）：

## 既存コードの文脈
- 似たお手本（下に貼る／対象ファイルを読ませる／CLAUDE.md等に常設）：
- 命名・エラー処理の作法：
- 使う共通関数・置き場所：

## 完成の判断基準（テスト観点）
- 必ず満たす正常系：
- 押さえる異常系・境界：
- これは起きてはいけない：

渡す前のチェックリスト

依頼を送る前に、迷いそうな所が埋まっているかをさっと確認します。全部に○が要るわけではなく、その依頼で関係する行だけで十分です。各ブロックは、その依頼で1つも該当しなければ、丸ごと飛ばしてかまいません。

そして忙しい日の最低ラインを1つだけ挙げるなら——どうしても1つしか選べないときは、②の入出力例を渡す。ここだけ押さえれば、取り違えの多くは防げます。

①ゴール・背景

②入出力

③制約

④既存コードの文脈

⑤完成の判断基準

最後に

AIに前提を渡すのは、手取り足取り教えるためではありません。 自分の頭の中にある「当然」を、AIにも見えるようにするだけのことです。それは遠回りに見えて、いちばんの近道になります。書く前の数分で、書いた後の往復が減るからです。

前提を渡して書かせたコードがほぼ思い通りに返ってきて、ひとつ頷きながら次の作業へ進もうとしている開発者

5つ全部でなくても、今日ひとつ「入出力の例を渡す」ができたなら、それはもう「動くけど違う」を減らす確かな一歩です。 そして、前提を渡して書かせたコードも、最後はやっぱり人が見ます。書いた後の見る順番は、AI生成コードのレビュー・検証チェックリストにまとめました。前に渡す型と、後で見る型。この2つがそろうと、AIコーディングはぐっと落ち着きます。

関連用語