Claude Codeに逆質問させて要件を固めるインタビュー術

このTipsでできること

Claude Codeに新機能の実装を頼むとき、思いついた要件をそのまま投げると、実装後に前提の食い違いが見つかって手戻りになります。この記事では、実装させる前にClaude Code側から質問を返させ、仕様書にまとめてから実装セッションを始める手順を扱います。使うのはAskUserQuestionという選択式の質問ツールです。

なぜ最初に指示を渡すと手戻りが起きるか

Claude Codeは渡された指示の範囲でしか考慮しません。あなたが「エッジケース」と思わずに省略した条件は、実装から丸ごと抜け落ちます。

一般的な指示の渡し方では、Claudeは曖昧な部分を自分なりの解釈で埋めて実装を進めます。UIの細部、権限まわりの扱い、対象外にする範囲。ここが人間のレビュアーの想定とずれていると、実装が終わったあとに設計からやり直すことになります。

対処の発想はシンプルです。先に書かせるのではなく、先に聞かせる。Claude Codeを実装者としてではなく、要件を掘り下げるインタビュアーとして先に動かします。

Claudeに逆質問させるプロンプトの書き方

インタビューをさせるプロンプトは、実装の詳細を書かず、インタビューという役割だけを与えます。以下がその型です。

[機能の簡単な説明]を作りたい。AskUserQuestionツールを使って詳しくインタビューしてほしい。
 
技術的な実装方法、UI/UX、エッジケース、懸念点、トレードオフについて聞いて。
当たり前の質問はしなくていい。私が考慮していなさそうな難しい部分を深掘りして。
 
すべてカバーしたと思うまでインタビューを続けて、その後SPEC.mdに完全な仕様書を書いて。

[機能の簡単な説明]の部分だけ自分の機能名に置き換えます。「当たり前の質問はしなくていい」という一文が効きます。これを外すと、Claude Codeは表面的な確認質問を並べるだけで、考慮漏れの深掘りまで届きません。

AskUserQuestionツールの仕組み — 選択式・自由記述・タイムアウト

AskUserQuestionとは、Claude Codeが実装前に判断や確認を求めるときに使う選択式の質問ツールです。質問ごとに選択肢が並び、選んで答えるか、「Other」の行や備考欄に自分の言葉で書いて答えます。

自由記述で答えた内容は、Claude Codeが中立的な言い回しに直してから解釈に反映します。「まず待って」「先に説明して」のような依頼もそのまま伝わります。

質問はデフォルトでは無期限に開いたままです。席を外している間も待ち続けます。askUserQuestionTimeout設定を60s・5m・10mのいずれかにすると、無応答が続いたときに選択済みの内容だけで自動的に会話を再開させられます。残り20秒はカウントダウンが表示され、キー入力や画面へのフォーカスでタイマーがリセットされます。

一問一答で終わらせず、答えた内容から派生する追加質問を重ねさせるのがコツです。プロンプト側で「すべてカバーしたと思うまで続けて」と明示しているのはそのためです。

インタビューの実例 — 通知機能を頼んだ場合

抽象的な説明だけでは掴みにくいので、実際の流れを追います。「ユーザーに通知機能を追加したい」とだけ伝えた場合、Claude CodeはAskUserQuestionで次のような質問を返してきます。

• 通知の配信経路はメール・アプリ内・push通知のどれを想定していますか(複数選択可)
• 既読・未読の状態はどこまで細かく管理しますか(全体で1つ / 通知種別ごと)
• 大量送信時のレート制限は必要ですか
• 通知設定をユーザーがオフにできる粒度はどこまでですか(全体一括 / 種別ごと)

それぞれに選択肢が並び、想定していなかった項目には「Other」で自分の言葉を書き足せます。「大量送信時のレート制限」のような質問は、機能の説明文には出てこない考慮点です。ここが逆質問の効くところで、実装が始まってから気づくはずだった論点を、コードを書く前に洗い出せます。

回答が出そろうと、Claude CodeはSPEC.mdに要件をまとめます。この時点で仕様書をひと通り読み、認識のずれがないか確認してから次に進みます。ずれがあれば、SPEC.mdを直接指摘して修正させます。まだ実装は始まっていないので、修正コストはこの時点がもっとも低くなります。

仕様書に書くべき最小要素

インタビューが終わったら、Claude CodeにSPEC.mdとして仕様書を書かせます。有効な仕様書は自己完結している必要があります。

• 関係するファイルとインターフェースを名前で特定している
• スコープ外にすることを明記している
• 機能が動いていることを証明する、端から端までの検証手順で締めている

仕様を精密にする時間は、実装を見守る時間より効きます。曖昧な仕様のまま実装を始めると、実装中の判断がすべて手探りになるからです。

実装は新しいセッションで始める

仕様書が固まったら、そのまま同じセッションで実装を続けません。新しいセッションを開き、仕様書を読ませてから実装させます。

インタビューのやり取りは実装に不要な文脈です。同じセッションに残したまま実装させると、質問と回答の応酬がコンテキストを圧迫し、実装の判断が薄まります。新しいセッションなら、実装に集中した文脈と、参照できる書面の仕様書の両方がそろいます。

セッションを分ける発想は、Claude Codeのメモリー設計そのものにも表れています。CLAUDE.mdと自動メモリー、セッション単位の文脈を分けて使う考え方はClaude Code memoryの三層構造にまとめています。

いつ逆質問させ、いつ直接指示するか

インタビュー手法はどんな作業にも向くわけではありません。作業の性質で使い分けます。

見極めの軸は「あなた自身が要件を全部言語化できているか」です。言語化できているならインタビューは不要です。逆に、頭の中にあるのに文章にしていない前提が多いほど、インタビューの価値が上がります。表の判定に迷ったら、まず作業を1行で説明してみて、その1文に「たぶん」「多分」が混じるかどうかを確かめます。混じるならインタビューに寄せる合図です。

よくあるつまずき

インタビューが終わらない: 「すべてカバーしたと思うまで続けて」という指示は、際限なく質問を重ねさせるリスクもあります。長引きすぎたら「ここまでで仕様書にまとめて」と割り込んで区切ります。

非対話モードでは使えない: AskUserQuestionはユーザーとの対話が前提のツールで、claude -pの非対話モードでは通常ブロックします。スクリプトやパイプラインに組み込む場合の制約はClaude Code -pモードでスクリプトやパイプラインを自動化する基本で扱っています。インタビュー手法はターミナルでの対話セッション向けの技術です。

「当たり前の質問はしなくていい」を省略する: この一文を外すと、Claude Codeは「対象OSは何ですか」のような自明な質問を並べ、時間を消費するわりに考慮漏れの発見が薄くなります。

インタビューの答えを口頭でしか残さない: SPEC.mdへの書き出しを省略し、同じセッションのまま実装に移ると、仕様書というレビュー可能な成果物が残りません。チームでレビューするなら、SPEC.mdをコミット前にプルリクエストのdescriptionへ貼るところまでが手順の一部です。

まとめ

新機能を頼むときは、実装させる前にインタビューさせます。プロンプトには役割と終了条件だけを渡し、詳細はClaude Code自身に聞かせます。仕様書は自己完結させ、検証手順まで書かせます。実装は文脈をリセットした新しいセッションで始めます。バグ修正や横展開のような要件が明確な作業には向かないので、作業の性質で使い分けます。

手法自体はシンプルですが、効果は仕様が固まるまでの時間ではなく、実装後の手戻りが減る形で現れます。最初の1回で効果を実感しにくければ、直近で手戻りが起きた機能に絞って試すと、判断材料が集まりやすくなります。

よくある質問

インタビューはどんな機能でも効果がありますか

エッジケースやトレードオフの検討が必要な、要件が固まっていない機能で効果が出ます。要件がすでに明確な作業では、インタビューの手間がそのままオーバーヘッドになります。

SPEC.mdはどこに置けばいいですか

作業対象のリポジトリのルート直下に置き、実装完了後はdocs/配下や関連プルリクエストの説明欄に移してレビュー用の記録として残す運用がやりやすいです。ファイル名は固定ではなく、複数機能を並行して進めるならSPEC-<機能名>.mdのように分けても構いません。

AskUserQuestionへの回答はあとから見返せますか

セッションの会話履歴として残るので、同じセッション内では見返せます。長時間のセッションを見返しやすく保つ習慣はClaude Codeのセッションを快適に保つ5つの習慣にまとめています。

普通のチャットで質問させるのと何が違いますか

自由形式のチャットでも「質問してから実装して」と頼めば近いことはできます。違いは、AskUserQuestionが選択肢という構造を持つ点です。読み手は選ぶだけで答えられ、書き手のClaude Codeは選択肢という形で論点をあらかじめ整理してから提示します。自由記述のやり取りに比べて、1問あたりのタイピング量が減り、論点の抜け漏れも見た目で把握しやすくなります。

チーム開発でも使える手法ですか

使えます。CLAUDE.mdの規約とレビュー体制を設計している場合は、SPEC.mdの検証手順をレビューの合格基準として流用できます。チーム導入の設計はClaude Codeチーム導入ガイド、PM視点での仕様書運用はClaudeで仕様書とロードマップを書くPM実務パターンで扱っています。