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

このTipsでできること

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

型そのものは、ベストプラクティスのページの「Let Claude interview you」の節に載っています。この記事は、その型を使うときに分かれ道になる点を、claudev2.1.287の--help出力と公式ドキュメントで確かめてまとめます。具体的には、質問が自動で閉じる条件、plan modeとの使い分け、回答する相手のいない非対話実行で質問が通らない理由です。

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

Claude Codeは渡された指示の範囲で考えます。あなたが「エッジケース」と思わずに省略した条件は、指示に書かれていないので、実装でも埋まりません。

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

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

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

インタビューをさせるプロンプトは、実装の詳細を書かず、インタビューという役割だけを与えます。以下がその型です。そのページの英語のプロンプト例を日本語にしたもので、構成は同じです。

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

[機能の簡単な説明]の部分だけ自分の機能名に置き換えます。最小限のプロンプトで始め、AskUserQuestionでインタビューさせるのが前提の型です。ツール名を文面に書くのは、質問を選択式のダイアログとして出させるためです。

「当たり前の質問はしなくていい」の一文は、質問の方向を決める指定です。省くと、自明な確認を止める指示がなくなります。

AskUserQuestionの仕組み — 選択式・自由記述・自動継続

AskUserQuestionは、Claude Codeが判断や確認を求めるときに使う選択式の質問ツールです。ツール一覧では、権限の確認が不要なツールとして載っています。質問ごとに選択肢が並び、選んで答えるか、Otherの行や備考欄に自分の言葉で書いて答えます。

自由記述で答えた内容は、Claude Codeが中立的な言い回しに直してからClaudeへ渡します。「まず待って」「先に説明して」のような依頼も、そのまま伝わります。この挙動は、回答が「続けてよい」という合図として扱われてしまう不具合の修正として入りました。

注意したいのは、無応答のときの動きです。質問は無期限に開いたままで、席を外している間も待ち続けます。ただしこれはv2.1.200で変わった点で、そのバージョンの更新履歴に「AskUserQuestionのダイアログは既定では自動継続しなくなった」と記されています。

設定の書き方は次のとおりです。設定できるのはユーザー設定(~/.claude/settings.json)か管理設定で、プロジェクトの設定ファイルには置けません。/configの「Question auto-continue timeout」の行からも変えられ、その場合もユーザー設定に書き込まれます。v2.1.200以降の機能です。管理設定や--settingsフラグでこのキーが指定されている環境では、/configにこの行は表示されません。

{
  "askUserQuestionTimeout": "5m"
}

要件を固めるインタビューでは、この設定との相性に注意が要ります。回答を放置して自動継続が働くと、未回答の論点はClaudeの判断で埋まります。「私が考慮していなさそうな部分を聞いて」という本来の狙いとは逆向きです。インタビュー中は既定の無期限のままにしておくほうが、狙いに沿います。

組織で管理設定が入っているなら、自動継続の有無は自分では変えられない場合があります。シェルにCLAUDE_AFK_TIMEOUT_MSが入っていると、その1セッションでは設定よりそちらが優先されます。切り分けはAskUserQuestionが応答しないときの原因にあります。

残り20秒はカウントダウンが表示され、キー入力で時計が戻ります。フォーカスを報告するターミナルでは、ウィンドウに切り替えるだけでも戻ります。このタイムアウトの対象はAskUserQuestionの選択式質問だけで、plan modeの承認を含む権限の確認は、放置しても自動では閉じません。

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

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

抽象的な説明だけでは掴みにくいので、流れを一例で追います。以下は実際の出力の記録ではなく、「ユーザーに通知機能を追加したい」とだけ伝えた場合に出てきうる質問の例です。

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

「大量送信時のレート制限」のような項目は、機能の説明文には出てこない考慮点です。実装が始まってから気づくはずだった論点を、コードを書く前に洗い出せるのが、逆質問の効くところです。

回答が出そろうと、Claude CodeはSPEC.mdに要件をまとめます。まだ実装は始まっていないので、修正の手間はこの時点が最も小さくなります。

仕様書に書く最小要素

有効な仕様書の条件は3つあります。自己完結していること、つまり関係するファイルとインターフェースを名前で特定していること。スコープ外を明記していること。機能が動くことを証明する、端から端までの検証手順で締めていること。仕様を精密にする時間のほうが、実装を見守る時間より効く、という指摘も添えられています。

この3点を、そのままSPEC.mdの見出しに写すと次のような骨組みになります。見出し名は筆者の例で、固定の書式ではありません。

# 通知機能の仕様
 
## 対象ファイルとインターフェース
- src/notifications/send.ts の sendNotification()
- POST /api/notifications
 
## スコープ外
- メール配信(別チケットで対応)
 
## 検証手順
1. 開発環境でアプリ内通知を1件送る
2. 受信側の画面で未読表示になることを確認する
3. 通知設定をオフにして、同じ操作で届かないことを確認する

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

仕様書が固まったら、同じセッションで実装を続けず、新しいセッションを開いて仕様書を読ませます。理由は、新しいセッションなら実装に集中した文脈で始められ、参照できる書面の仕様書も手元にそろう、というものです。

文脈を分けて使う考え方は、Claude Codeのメモリーの設計とも重なります。CLAUDE.mdと自動メモリー、セッション単位の文脈の役割分担はClaude Code memoryの三層構造にまとめています。

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

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

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

plan modeとの違い

もう1つの選択肢が、plan modeです。claude --permission-mode planで起動するか、Shift+Tabで切り替えて入ります。ベストプラクティスのページによると、このモードのClaudeはファイルを読んで質問に答えるだけで変更を加えず、探索と実行を分けられます。

役割が違います。plan modeはClaudeがコードを読んで実装計画を立てる段階で、インタビューはあなたの頭の中にある要件をClaudeに引き出させる段階です。plan modeには、差分を1文で説明できる作業なら省く、という目安が示されています。同じ基準をインタビューに当てはめるなら、要件が1文で言える作業では不要、という読み方になります。この対応づけはドキュメントの記述ではなく、筆者の解釈です。

答える相手のいない実行では質問が通らない

AskUserQuestionは、答える人がいることが前提のツールです。dontAskモードではAskUserQuestionが許可ルールに一致しても拒否されると明記されています。またclaude -pに--permission-prompts noneを付けると、答えを人に求めるツール(AskUserQuestionなど)がそもそも外され、Claudeは呼び出せなくなります。

v2.1.287のclaude --helpには、次のように出ます。

claude --version
2.1.287 (Claude Code)
 
claude --help(抜粋)
  --permission-mode <mode>   (choices: "acceptEdits", "auto",
                              "bypassPermissions", "manual",
                              "dontAsk", "plan")
  --permission-prompts <target>
                             Who answers permission prompts with --print:
                             "host" (the SDK host or --permission-prompt-tool)
                             or "none" (nobody: anything that would prompt
                             is denied automatically; ...)

--permission-promptsは--print(-p)と組み合わせるオプションです。既定はhostで、noneにすると承認の求めは自動で拒否され、AskUserQuestionのように人の回答が要るツールはそもそも外されます。

-pでの実行でAskUserQuestionが使えるのは、質問を受け取る相手(permission host)がいるときだけです。相手になるのは、Agent SDKのcanUseToolコールバックや--permission-prompt-toolで渡すツールです。素のclaude -pには相手がいないので、Claudeは質問できません。インタビューは対話セッションで行うものです。なお、PreToolUseフックがupdatedInputとpermissionDecision: "allow"を返して質問に答える経路もあります。フックの書き方はPreToolUseフックの使い方にあります。

スクリプトやパイプラインに組み込む場合の制約は、Claude Code -pモードでスクリプトやパイプラインを自動化する基本で扱っています。

autoモードでは明示すると質問が通る

対話セッションでも、権限モードによって質問の出方が変わります。autoモードにはClaudeが確認質問で止まらず作業を続けるよう促す性質があります。ただし、プロンプトやスキルがAskUserQuestionを明示的に頼りにしている場合は、Claudeは引き続き質問します。更新履歴にも、その場合にautoモードが質問を抑えてしまう不具合の修正が載っています。

この記事のプロンプトが「AskUserQuestionツールを使って」と明示するのは、このためにも都合のよい書き方です。

よくあるつまずき

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

答えを口頭でしか残さない、というつまずきもあります。SPEC.mdへの書き出しを省いて同じセッションのまま実装に移ると、レビューできる成果物が残りません。チームでレビューするなら、SPEC.mdの検証手順をレビューの合格基準として流用できます。チーム導入の設計はClaude Codeチーム導入ガイド、PM視点での仕様書の運用はClaudeで仕様書とロードマップを書くPM実務パターンで扱っています。

質問と回答は同じセッションの会話履歴に残るので、そのセッション内では見返せます。長いインタビューのあとに文脈が重くなったときの整え方は、Claude Codeのセッションを快適に保つ5つの習慣にあります。

まとめ

仕様を言葉にしきれていない作業ほど、実装より先に質問させる価値があります。インタビュー中に質問が勝手に閉じるなら、まず/configの自動継続の行を確かめてください。