ほとんどのエンジニアは、結果が悪いとAIのせいにします。本当の問題は？プロンプトです。
実際にうまくいくのはこれです：
1. 最初に具体的にする
曖昧なプロンプト＝曖昧な回答です。
❌ 「エラーを処理する関数を書いて。」
✅ 「非同期エラーをキャッチして、ステータスコードとメッセージを含む構造化JSONレスポンスを返す、Python FastAPIのミドルウェアを書いて。」
2. 制約を使う
AIに「やってはいけないこと」を伝えます。
「コメント禁止。print文禁止。requestsではなくhttpxでasync/awaitを使って。」
制約は、生成される前に膨らみ（バloat）を削減します。
3. 例を与える
既存のコードを指して「このスタイルに合わせて」と言いましょう。Claude Code、Cursor、GitHub Copilotのどれを使っていても、AIにコードベースを直接読ませることで、命名規則、パターン、アーキテクチャに自然に合うようになります。長い説明は不要です。ブラウザベースのAIなら、単にスニペットを貼り付ければ同じです。考え方も結果も同じになります。
4. 役割を割り当てる
「あなたはスケーラビリティの観点からこのAPI設計をレビューするシニアバックエンドエンジニアです。」
これにより推論の枠組みが誘導され、より鋭く集中したレビューが得られます。
5. 複雑なタスクを分解する
AIに「ワンショットで完全な認証システムを作って」と頼まないでください。
代わりに：モデル→ルート→デコレータ／依存関係→pytestテスト。各ステップが次のステップの土台になり、エラーも見つけやすくなります。
6. 再生成ではなく洗練する
何かがおかしい？再スタートしないでください。こう言いましょう：
「このPython関数は、パースしたJSONの代わりにNoneを返しています。この関数だけデバッグして、残りには触れないで。」
的を絞った修正はトークンを節約し、すでに動いているものを維持します。
7. 出力の長さをコントロールする
「このキャッシュの問題に対するアプローチを3つ出して。各アプローチはそれぞれ1段落で。」
出力が長い＝良い出力、ではありません。単に読む・レビューする時間が増えるだけです。
8. AIがあなたを誤解させ得るタイミングを知る
システムアーキテクチャの設計、セキュリティに関わる重要な判断、規模に応じたパフォーマンス見積もりなどでは、AIは非常に自信満々に聞こえても、完全に間違っている可能性があります。必ず、あなた自身の判断とドメイン知識で出力を検証してください。
根本の原則は？
AIは悪い指示書を直せません。出力の品質は、入力の明確さに直接比例します。
