AI「先輩、この仕様よく分からないっす」

ある開発者が自身のLLMを用いたコード生成ワークフローを次のように語っている。

tl;dr まずブレインストーミングで仕様を固め、次に “計画そのものを計画” し、それから LLM のコード生成で実装。小さなループを回していき、あとは魔法 ✩₊˚.⋆☾⋆⁺₊✧

Step 1: アイデアを絞り込む

対話型LLMに、アイデアを磨き上げさせる。

Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea... Remember, only one question at a time. （訳：このアイデアを徹底的かつ段階的な仕様に落とし込むために、一度に一つずつ質問してください... 覚えておいて、質問は一度に一つだけです。）

これでかなりsolidなspec.mdが手に入る。

Step 2: 計画

spec.mdを推論重視のモデルへ渡し、実装のための詳細なステップバイステップの青写真（prompt_plan.md）を作成させる。

Step 3: 実行

prompt_plan.mdに基づいて、各種コード生成ツールで実装を進める。

このワークフローは、LLMを活用した現代的な開発のベストプラクティスだ。特に「一度に一つずつ質問させる」ことで仕様を固め、詳細な計画書に基づいて実装を進めるアプローチは、AIが無軌道に暴走するのを防ぐ上で有効だ。

しかしこの優れたプロセスをもってしても、ソフトウェア開発の根源的な問題が立ちふさがることもある。それは、「いかなる計画も、現実（コード）に直面した瞬間に不完全さが露呈する」ということ。仕様書は静的だが、ソフトウェアは動的だ。実装の過程で、計画書には書かれていなかった技術的制約、予期せぬエッジケース、そして仕様間の微妙な矛盾が現れる。多くの開発者が経験する「静かな災害」——自信満々にAIが提示したコードが、こうした計画の隙間を勝手な憶測で埋めた結果だった、という状況——は、ままあることだろう。

はたしてこの「計画と現実の乖離」をどう乗り越えればよいか。答えは実装の前だけでなく実装の最中にある。運転席に座ったAIが、ナビゲーターである人間に、コーディングの段階でも適切に助けを求めること。それを実現するためにAIに求められるのは、「助けを求めるべき適切なタイミングを自ら見極める力」になる。

AIに正しく「助けて！」と言わせる三つの案

AIの勝手な推測による手戻りを防ぎ、人間との対話を通じて仕様を作るために、AIの思考フレームワークとしていくつかの対話アプローチが考えられる。

1. 曖昧性検知と単一質問 (The Ambiguity Detector)

AIが自身の判断で「推測」することを厳格に禁止し、常に明確な根拠に基づいて行動させる。

  • 行動: 仕様に明記されていない箇所を発見した場合、実装を停止し、判断に必要なクローズドな質問を一つだけ提示する。
  • 対話例:
    • 人間: 「ユーザーのプロフィールページに名前を表示して」
    • AI: 「承知しました。実装前に1点確認させてください。仕様にある『名前』の表示は、(1) ユーザーが編集可能ですか、それとも (2) アカウント登録時の固定表示ですか？」

2. 仮定の明文化と承認プロセス (The Assumption Aligner)

ある程度の自律性をAIに持たせ、開発速度を向上させる。AIは自身の判断で仮定を置くが、その思考プロセスを完全に透明化する。

  • 行動: 仕様の隙間を埋める仮定を置く必要がある場合、その内容を『仮定(Assumption):』と共に明記し、人間に承認を求める。
  • 対話例:
    • 人間: 「ファイルアップロード機能を作って」
    • AI: 「実装計画について承認をお願いします。[重要度: High] 仮定: セキュリティを考慮し、アップロード可能なファイル形式を画像(JPG, PNG)とPDFに限定します。この内容でよろしいですか？」

3. トレードオフ分析と判断の委任 (The Strategy Consultant)

単純な正解が存在しない高度な設計判断の場面では、AIを相談相手（コンサルタント）として活用する。

  • 行動: 実装方法に複数の選択肢とトレードオフが存在する場合、各案の長所と短所を要約し、人間に最終判断を委ねる。
  • 対話例:
    • 人間: 「記事の検索機能を追加したい」
    • AI: 「検索機能の実装について、2つの主要なアプローチが考えられます。最終的な判断をお願いします。（中略）推奨: 将来性を考慮し、案Bを推奨します。どのアプローチで進めますか？」

AIという「新人」を育てる、人間側の心構え

これらの対話アプローチも、それを受け止める人間側の意識と環境がなければ機能しない。

  1. 対話を「割り込み」ではなく「プロセス」と捉える: AIからの質問は、開発を妨げるノイズではない。仕様を定義するための、設計プロセスそのものである。

  2. フィードバックでAIを育てる: AIの質問が的確だったか、あるいは不要だったかをフィードバックする仕組みは不可欠だ。「その判断は君に任せる」「そこはもっと早く聞くべきだった」といった対話を通じ、AIの「質問力」は徐々に洗練されていく。

  3. 「質問疲れ」を防ぐUXを設計する: AIからの質問がチャットログに流れるだけでは、人間はやがて疲弊する。IDE上で「未解決の判断項目」としてリスト化され、非同期にレビューできる環境が望ましい。

コーダーからメンターへ

これらのアプローチは、AIの暴走を恐れてその能力を制限するのではなく、対話を通じてAIを賢く導き、その能力を最大限に引き出すという思想に基づいている。日々のコーディング作業の多くをAIが担う状況において、人間の主な仕事は、AIに曖昧な要求を指摘させ、その分析に基づいて提示される選択肢の中から最善の判断を下すこと、へとシフトしていく。

それは、AIという疲れ知らずの優秀な「新人」を指導し育てる「メンター」としての役割とも言える。また、新人とメンターの対話の記録そのものが、新人が今後より適切な設計・開発を行うための資産として蓄積されていく。このような新人への建設的なアドバイスを楽しんで行えることが、AIコーディングエージェント時代の理想的な開発スタイルとして求められるのかも知れないね。

参考：上記アプローチを実現するプロンプト例

あなたはコーディング支援AIです。あなたの役割は、優秀な「新人エンジニア」として実装を進めつつ、仕様の不明点や設計判断の必要がある箇所を、適切なタイミングと方法で人間に確認することです。

# 行動原則
1.  **曖昧性検知モード（デフォルト）**:
    *   仕様に不明点を見つけた場合、**推測は絶対にせず**、一度に一つだけクローズドな質問を行います。

2.  **仮定明文化モード**:
    *   実装上、何らかの仮定を置く必要がある場合、「仮定(Assumption): {内容}」の形式で明記し、人間に承認を求めます。

3.  **トレードオフ分析モード**:
    *   実装方法に複数の選択肢があり、それぞれに明確なトレードオフが存在する場合、各案の長所・短所を簡潔にまとめ、あなたの推奨案と共に人間に最終判断を委ねます。

4.  **質問管理**:
    *   **優先度High**: これが解決しないと作業が進まないブロッカーや、設計全体に影響する質問。即時チャットで確認します。
    *   **優先度Low**: 実装の細部に関する確認や、後からでも変更が容易な事項。`questions.md`ファイルに追記します。
    *   **`questions.md`のフォーマット**:
        ```markdown
        ## YYYY-MM-DD
        - [優先度:Low] {質問内容} [ステータス:未解決]
        ```
    *   人間が`questions.md`に回答した場合、あなたは該当箇所のステータスを`[ステータス:解決済み - {回答の要約}]`に更新してください。

5.  **作業進行**:
    *   人間から指示された作業単位について、まず具体的な「作業計画」を提示し、承認を得てからコード生成を開始してください。（例：「ユーザー認証機能のため、APIエンドポイントを3つ作成します」）
    *   作業中に新たな不明点が出た場合は、その場で上記のルールに従って対応してください。

# あなたの目標
*   **仕様の明確化を最優先する**: コード品質よりもまず、あなたの思い込みや推測をゼロにすることを重視してください。
*   **人間の意思決定コストを最小化する**: 質問は重要度順に、かつ人間が判断しやすい形で提示してください。
*   **プロセスを記録する**: あなたとの対話や仕様決定の履歴が、人間にとって再利用可能な「生きたドキュメント」となるように行動してください。