AIコーディングで起きている「プロンプト格差」
ChatGPTやClaudeを使ったコーディングが当たり前になりました。生成AIを使えば、それなりに動くコードは短時間で出力できます。
しかし現場では、こんな声が増えています。
「AIで書いたけれど、レビューで全部書き直しになった」 「動くけど、保守できないと言われた」 「なぜダメなのか自分でも分からない」
問題はAIではありません。問題は、プロンプトの書き方によって出力品質に大きな差が生まれていることです。
同じAIを使っても、プロンプト次第で「実務で使えるコード」と「動くだけのコード」に分かれます。このギャップが、いま一気に拡大しています。
なぜプロンプトの書き方で結果が変わるのか
AIは指示された通りに出力します。曖昧な指示には曖昧な出力が返ってきます。
たとえば「ログイン機能を作って」と指示した場合、AIは動くコードを返します。ただし、実務で通らない理由はだいたい決まっています。
- 要件が曖昧なまま形だけが先に出ている
- エラーハンドリングが考慮されていない
- セキュリティ対策が不十分
- 既存のコードベースと整合性が取れていない
- 保守性や拡張性が想定されていない
つまり、コードとしては成立していても、プロダクションコードとして成立していないのです。
実務では「動くか」よりも「運用できるか」が重要です。運用できるとは、レビュー、テスト、デプロイ、保守という複数のフェーズに耐えられることです。そこに耐えられないコードは、いくら速く書けても却下されます。
AIに伝えるべき5つの基本要素
効果的なプロンプトには、次の5つの要素が含まれています。
1. コンテキスト（背景情報）
AIはあなたのプロジェクトを知りません。言語、フレームワーク、バージョン、既存の設計パターンを明示します。
「React 18でTypeScriptを使っています。状態管理はZustandです」
この一文があるだけで、出力されるコードの方向性が大きく変わります。
2. 目的（何を達成したいか）
「ログイン機能を作って」ではなく、「メールアドレスとパスワードで認証し、JWTトークンを発行するログインAPIを作りたい」と伝えます。
目的が具体的であるほど、AIは適切な実装を選択できます。
3. 制約条件（守るべきルール）
「既存のUserモデルを使う」「外部ライブラリは追加しない」「関数は50行以内」など、プロジェクト固有のルールを伝えます。
制約がないと、AIは最も一般的な実装を選びます。それがあなたのプロジェクトに合うとは限りません。
4. 期待する出力形式
「コードだけ出力して」「コメント付きで」「テストコードも一緒に」など、出力形式を指定します。
形式を指定しないと、説明文が長くなったり、逆に説明が足りなかったりします。
5. 例示（あれば）
入力と期待する出力の例を1〜2個示すと、仕様の認識ズレを防げます。
「入力: { email: “test@example.com” } → 出力: { valid: true }」
例があると、AIはパターンを理解して一貫した実装を返します。
シーン別プロンプトテンプレート
実務でよく使うシーン別のプロンプト例を紹介します。
新規機能の実装
【環境】
– Next.js 14 (App Router)
– TypeScript
– Prisma + PostgreSQL
【やりたいこと】
ユーザーのプロフィール編集機能を作りたい。
名前、メールアドレス、プロフィール画像を更新できる。
【制約】
– Server Actionsを使う
– バリデーションはZodで行う
– 画像はCloudinaryにアップロード済みのURLを受け取る
【出力形式】
– Server Actionの関数
– 入力のZodスキーマ
– エラーハンドリング込み
バグ修正
【現象】
フォーム送信後にページがリロードされてしまう。
【期待する動作】
送信後はリロードせずに完了メッセージを表示したい。
【該当コード】
（コードを貼り付け）
【環境】
React 18, react-hook-form
【お願い】
原因と修正方法を説明してください。
コードレビュー依頼
以下のコードをレビューしてください。
【観点】
– セキュリティ上の問題
– パフォーマンスの改善点
– 可読性の向上
– エッジケースの考慮漏
【コード】
（コードを貼り付け）
【出力形式】
問題点ごとに、理由と改善案をセットで示してください。
リファクタリング
以下のコードをリファクタリングしてください。
【現在の問題】
– 1つの関数が200行を超えている
– 同じ処理が3箇所に重複している
– テストが書きにくい構造になっている
【方針】
– 単一責任の原則に従って分割する
– 共通処理はユーティリティ関数に切り出す
– 依存性注入でテスト可能にする
【コード】
（コードを貼り付け）
やってはいけないプロンプトのNG例
実務で失敗するプロンプトには共通点があります。
NG1: 丸投げ
「ECサイトを作って」
これではAIは何を作ればいいか分かりません。結果として、最も一般的で表面的な実装が返ってきます。
NG2: 文脈なしのコード貼り付け
「このコードを直して」（コードだけ貼り付け）
何が問題なのか、どう直したいのかが分からないと、AIは推測で修正します。推測が外れると、余計な修正が入ったり、本当の問題が直らなかったりします。
NG3: 複数の要求を一度に
「ログイン機能を作って、あとユーザー管理画面も、それからメール送信機能も」
一度に複数の機能を要求すると、どれも中途半端になります。機能ごとに分けて依頼する方が、品質の高いコードが返ってきます。
NG4: 抽象的すぎる指示
「もっと良くして」「きれいにして」
何が「良い」のか「きれい」なのか、基準がないとAIは判断できません。「関数を20行以内に分割して」「変数名を具体的にして」のように、具体的に伝えます。
実務で通用するために必要なこと
AIを使いこなすためには、プロンプトの書き方だけでなく、出力を評価する力が必要です。
AIの出力を鵜呑みにしない
AIは自信満々に間違ったコードを出力することがあります。特に以下の点は必ず確認します。
- セキュリティ（SQLインジェクション、XSS、認証の抜け穴）
- エラーハンドリング（例外処理の漏れ）
- エッジケース（null、空配列、境界値）
- パフォーマンス（N+1問題、不要な再レンダリング）
段階的に進める
最初から完璧なコードを求めず、段階的に改善します。
- まず動くものを出力させる
- レビュー観点を伝えて問題点を洗い出す
- 問題点を1つずつ修正させる
- テストコードを追加させる
一度に完璧を求めると、どこかで破綻します。
自分で理解できないコードは使わない
AIが出力したコードを理解せずにコピペすると、バグが発生したときに対処できません。「このコードの処理を説明して」と追加で聞いて、理解してから使います。
これからAIコーディングを始める人へ
もしAIとの協働コーディングを始めるなら、プロンプトのテンプレートを暗記することから入らない方がいいです。
必要なのはテンプレートではなく、伝える力です。
次の問いに答えられるかを、自分の基準にしてください。
- 今から作るものは何か、30秒で説明できるか
- なぜこの実装方法を選ぶのか、理由があるか
- 完成したコードを、他人がレビューできる状態か
- 半年後の自分が見ても理解できるか
- テストは書けるか、書く必要があるか
この問いに答えられるようになるほど、AIへの指示も自然と具体的になります。
まとめ
AIコーディングの本質は「速く書ける」ことではありません。本質は「伝える精度が品質を決める」ことです。
動くかどうかではなく、運用できるかどうか。 速いかどうかではなく、保守できるかどうか。 便利かどうかではなく、理解しているかどうか。
AIは優秀なアシスタントです。しかし、指示が曖昧なら曖昧な結果しか返ってきません。
プロンプトの書き方を磨くことは、自分の思考を整理する訓練でもあります。何を作りたいのか、なぜその方法なのか、どこまで考慮すべきか。
AIを使いこなせる人は、結局のところ、自分の頭で考えられる人です。