本記事は、Claude Codeの開発に携わるAnthropicのThariq Shihipar（@trq212）氏がXに投稿した内容をもとに作成しています。原文はこちらをご参照ください → https://x.com/trq212
「とりあえず作って」が失敗する理由
Claude Codeに新しい機能の開発を頼むとき、つい「ユーザー通知機能を作って」と伝えてしまいがちです。でもこれだと、返ってくるものが思っていたのと違うことがよく起きます。
理由はシンプルで、「ユーザー通知機能」という言葉には決めなければならないことが山ほど含まれているからです。
- どのタイミングで通知を送る？
- メール通知？プッシュ通知？Slack通知？
- ユーザーが通知をオフにできる？
- どんな文面で送る？
- 送信失敗したらどうする？
これらを決めないままClaude Codeが「たぶんこういうことだろう」と推測して作り始めると、完成してから「あ、そういう意味じゃなかった」が発生します。手戻りの時間とコストが無駄になります。
仕様書インタビューとは何か
Thariq氏が「大きな機能や新しいプロジェクトを作るときのお気に入りのやり方」として紹介しているのが、仕様書インタビューです。
仕組みはシンプルです。
- まず最小限の仕様書（草稿）を作る
- Claude Codeにインタビュアーになってもらう
- 質問に答えながら仕様書を詳細化していく
- 完成した仕様書をもとに、別のセッションで実装を依頼する
「作る前に話し合う」という、当たり前のようで見落としがちなプロセスです。
実際の手順
ステップ1：最小限の仕様書を作る
SPEC.mdというファイルに、実現したいことを書きます。完璧である必要はありません。
# ユーザー通知機能
- 特定のアクションをしたときにメールを送りたい
- ユーザーが通知設定を変えられるようにしたい
- 種類：登録完了、注文確認、パスワードリセット
これくらいの箇条書きで十分です。
ステップ2：Claude Codeにインタビューを依頼する
以下のプロンプトをコピーして使えます。
この仕様書を読んで、AskUserQuestionToolを使って、
技術実装・UI/UX・懸念点・トレードオフなど、
あらゆる面について詳しくインタビューしてください。
当たり前の質問は避け、深掘りしてください。
完全に終わるまでインタビューを続けたあと、
仕様書ファイルに内容を書き込んでください。
@SPEC.md
ステップ3：質問に答え続ける
Claude Codeが次々と質問を投げかけてきます。大きな機能では40問以上になることもあるとThariq氏は言います。
実際に来る質問のイメージ：
- 「通知メールはHTMLメールですか？テキストメールですか？」
- 「通知設定は種類ごとに個別にオン/オフできますか？全部まとめて切り替えですか？」
- 「配信が遅れることは許容できますか？即時が必要ですか？」
- 「ユーザーがメールを受け取れない場合（迷惑メールなど）の対応はどうしますか？」
- 「通知の送信ログを保存しますか？保存するとしたら何日分ですか？」
これらの質問に答えていくと、最初には気づかなかった仕様の抜け漏れや矛盾が次々と明らかになります。
ステップ4：新しいセッションで実装を依頼する
インタビューが終わると、Claude Codeが詳細な仕様書として整理してファイルに書き込みます。その後は別のセッション（会話）を新しく始めて、その仕様書を読み込んで実装を依頼します。
なぜ「別のセッション」に分けるのか
仕様書が固まってきたタイミングで「じゃあそのまま実装もお願い」としたくなりますよね。でもThariq氏はあえてセッションを分けることを薦めています。
理由は、仕様を詰める議論でコンテキスト（AIが把握している情報）がいっぱいになっているからです。そのまま実装を頼むと、議論の内容がノイズになって精度が下がることがあります。
仕様書というファイルを介することで情報が整理・構造化され、実装のセッションはその仕様書だけを読んで集中して動けます。
このアプローチが特に効果的な場面
大きな機能の新規開発
決めなければならないことが多いほど、事前に整理しておく価値が高くなります。
チームメンバーとの認識合わせ
質問とその回答が仕様書として残るので、チーム内の共有ドキュメントとしても使えます。「あのとき何を決めたっけ」という確認にもなります。
非エンジニアが要件を整理したいとき
Thariq氏が言う「当たり前でない質問」を投げかけてくれるので、自分では気づかなかった技術的な考慮事項を引き出してもらえます。技術の知識がなくても、質問に答えるだけで詳細な仕様書ができあがります。
手戻りを減らしたいとき
実装後に「思っていたのと違う」が起きるコストは大きいです。作る前に曖昧さを排除しておくのが一番コスパの良い投資です。
使っているツール：AskUserQuestionTool
このアプローチで中心的な役割を果たすのが、Claude CodeのAskUserQuestionToolです。
このツールを使うと、質問がテキストとして流れてくるのではなく、選択肢付きのポップアップ（モーダル）として表示されます。Claude Codeがユーザーの回答を受け取るまで処理が止まるため、一問一答で集中して答えやすくなります。
このツール自体がどうやって生まれたか、詳しくはClaude Codeのエージェント設計の記事で解説しています。
まとめ
「作ってもらう前に話し合う」——言葉にすると当たり前ですが、AIツールを使うときに意外と忘れがちなプロセスです。
仕様書インタビューのアプローチは：
- 非エンジニアでも実践できる
- 実装の手戻りを大幅に減らせる
- 自分では気づかなかった考慮事項を引き出してもらえる
特に「大きな機能」「新しいプロジェクト」を始めるときは、まずこのアプローチを試してみてください。
すぐ使えるプロンプト
そのままコピーして使えます。@SPEC.mdの部分はあなたの仕様書ファイルに書き換えてください。
この仕様書を読んで、AskUserQuestionToolを使って、
技術実装・UI/UX・懸念点・トレードオフなど、
あらゆる面について詳しくインタビューしてください。
当たり前の質問は避け、深掘りを続けてください。
完全に終わるまでインタビューを続けたあと、
仕様書ファイルに内容を書き込んでください。
@SPEC.md
コメント