🗣️

Claude Code の AskUserQuestionTool でスペック駆動開発を快適にする！

に公開
AI
prompt
Claude
Anthropic
Claude Code
tech

Claude Code に「インタビュアー」になってもらい、自分でも言語化できていなかった要件を引き出してもらうアプローチの紹介です。

Anthropic のメンバーが X で紹介していたプロンプトがベースになっています。

元ポスト：https://x.com/trq212/status/2005315275026260309/

TL;DR

  • Claude Code には AskUserQuestionTool という対話ツールがあり、ユーザーに質問を投げかけることができる
  • これを活用すると、対話形式で要件を深掘りできる
  • 曖昧な SPEC を渡して「インタビューして」と依頼すると、自分でも気づいていなかった判断基準や制約 が浮かび上がる
  • 実際に試したところ、たった8行の初期 SPEC から 39個の質問 が生成され、仕様が具体化された

プロンプト

日本語版にしたプロンプトがこちらです。

@SPEC.md を読み込み、その内容を前提として AskUserQuestionTool を使い、
技術実装・UI / UX・懸念点・トレードオフなど、あらゆる観点について
ユーザーに対して詳細なヒアリングを行ってください。

質問は表面的・自明なものを避け、
ユーザー自身もまだ言語化していない前提・判断基準・制約・優先順位が
浮かび上がるような、深掘りの質問にしてください。

ヒアリングは一度で終わらせず、
理解が十分に完成するまで継続的にインタビューを続けてください。

すべての前提・要件・意思決定の背景が明確になった段階で、
最終的な仕様（spec）を作成し、ファイルに書き出してください。

ポイントは「AskUserQuestionTool を使う」「自明な質問を避ける」「継続的にインタビューする」の3点です。

実際に試してみた：匿名投稿サービスの SPEC

では、実際にこのプロンプトを試してみましょう。

架空のサービスを作る体で、以下のような 超ざっくりした SPEC を用意しました。

# SPEC.md

- X(旧twitter)のような投稿サービスを作りたい
- 完全匿名性で、誰に届くかわからない
- 1メッセージにつき一人しか開封ができない
- 開封したらそのメッセージは消滅する
- プライバシーに配慮し、メッセージの内容は匿名性を維持できるようにする（住所を書いたり、特定の人物名を書いてはいけない）
- 毎日使いたくなるようなギミックを用意する
- サービスが継続できるように最低限の収益の方法も考慮する
- pc, ios, androidあらゆる機種で使えるようにする

8行です。

しかし、先ほどのプロンプトを使うと、Claude Code は次々と質問を投げかけてきます。

生成された39個の質問

上記のSPECファイルで 10回のインタビューセッション を経て、39個の質問 が生成されました。（質問毎に答えを選択し、セッション毎にSubmitをするイメージです）

実際には以下のようにターミナル上で質問され、答えを選択する形式になります。

←  ☐ コア体験  ☐ 匿名性レベル  ☐ リスク認識  ☐ 利用動機  ✔ Submit  →

「1人だけが開封できる」という制約は、どのような体験を生み出すことを意図していますか？

❯ 1. [ ] 希少性・特別感
     「自分だけに届いた」という偶然の出会いの貴重さを演出したい
  2. [ ] 一期一会の緊張感
     開封するかどうかの決断に重みを持たせ、読む行為自体を特別にしたい
  3. [ ] 情報の流出防止
     拡散されないことで、送り手が安心して本音を書けるようにしたい
  4. [ ] Type something
     Next

Enter to select · Tab/Arrow keys to navigate · Esc to cancel

ただし、記事がおそろしく長くなってしまうので質問と選択肢のみに割愛します。

以下が実際の39問です。これらがインタラクティブに容易に答えることができるのも良い点ですし、選択肢に良いものが無い場合には自分でフリーテキストで答えられるのも素晴らしい点です。


#### 第1回

**Q1. 「1人だけが開封できる」制約が生み出したい体験は？**
- 希少性・特別感 
- 一期一会の緊張感
- 情報の流出防止

**Q2. 運営者もメッセージを読めない状態を目指すか？**
- E2E暗号化
- 運営のみ閲覧可 
- まだ決めていない

**Q3. 類似サービス（Secret等）の誹謗中傷問題についてどう考えるか？**
- 設計で回避
- AIモデレーション （＋独自のフィードバック案を追加）
- 深く検討したい

**Q4. ユーザーの主な利用動機は？**
- 感情の吐露 
- 善意の発信
- 暇つぶし・好奇心
- 複数想定

---

#### 第2回

**Q5. メッセージはどのように受信者に割り当てられるか？**
- 完全ランダム
- タイムライン型 （＋FB率表示の案を追加）
- 緑の他人

**Q6. フィードバックは送信者に通知されるか？**
- 通知する （＋どのメッセージかはわからない、20通送信後から）
- 通知しない
- 選択制

**Q7. メッセージの形式は？**
- テキストのみ 
- テキスト+絵文字
- マルチメディア

**Q8. 毎日使いたくなるギミックの方向性は？**
- 回数制限 
- ストリーク・実績 
- 日替わりテーマ 
- 複合・検討中

---

#### 第3回

**Q9. タイムラインのプレビューに表示される情報は？**
- 率のみ 
- 率+テーマ
- 率+文字数
- カスタマイズ検討

**Q10. 誰にも開封されなかったメッセージはどうなる？**
- 時間切れ消滅
- 再配布 
- 送信者に通知
- 無期限待機

**Q11. 1日に送信・開封できる回数は？**
- 各1回ずつ 
- 送信は無制限
- 段階的に増加
- 具体的に調整したい

**Q12. ユーザー認証方式は？**
- 完全匿名（端末IDのみ）
- メール認証
- SNS連携
- 電話番号認証 

---

#### 第4回

**Q13. 収益化の方法は？**
- 広告表示 
- プレミアム
- 消費アイテム
- ハイブリッド

**Q14. 日替わりテーマの運用は？**
- 強制
- 任意 
- ボーナス付き

**Q15. フィードバックの選択肢は？**
- 2段階
- 3段階
- リアクション式 

**Q16. メッセージの文字数制限は？**
- 短文（140字）
- 中文（280字） 
- 長文（500字以上）

---

#### 第5回

**Q17. タイムラインに同時に何通表示される？**
- 1通のみ
- 3〜5通 
- スクロール可能

**Q18. 利用停止の基準と期間は？**
- 段階制 
- 率ベース
- AI判定併用

**Q19. プライバシー保護（住所・人物名検知）の実装は？**
- AIフィルター
- ルールベース
- ハイブリッド 

**Q20. 技術スタックの希望は？**
- Flutter
- React Native
- おまかせ 

---

#### 第6回

**Q21. リアクションの種類は？**
- 感情ベース 
- ポジティブのみ
- オリジナル

**Q22. 広告の表示タイミングは？**
- メッセージ開封後
- タイムライン内
- バナー 

**Q23. ストリーク・実績の報酬は？**
- バッジのみ 
- 機能解放
- カスタム要素

**Q24. MVPのスコープは？**
- コア機能のみ 
- フル機能
- 段階的

---

#### 第7回

**Q25. ターゲットユーザー層は？**
- 10代後半〜20代
- 20代〜30代
- 幅広く 

**Q26. タイムラインのソート順は？**
- ランダム 
- フィードバック率順
- 時系列

**Q27. 再配布のタイミングは？**
- 24時間後に1回
- 即時再配布 
- 時間切れ消滅

**Q28. 日替わりテーマは誰が決める？**
- 運営が設定
- AI自動生成
- プリセット 

---

#### 第8回

**Q29. 開封せずにスキップする機能は？**
- スキップ可能
- スキップ不可 
- 1回だけ

**Q30. 受信するために先に送信が必要？**
- 送信必須
- 独立 
- 初回のみ

**Q31. サービスの展開地域は？**
- 日本国内のみ
- グローバル 
- 段階的拡大

**Q32. サービス名のイメージは？**
- 「Y」 
- 別のアイデア
- まだ決めていない

---

#### 第9回

**Q33. リアクションは何種類？**
- 3種類
- 5種類 
- 状況に応じて

**Q34. 異なる言語のユーザー間でメッセージは届く？**
- 言語混在 
- 言語別
- 選択制

**Q35. ストリーク・バッジの設計は？**
- 日数表示のみ
- マイルストーン
- 累積実績 

---

#### 第10回

**Q36. タイムライン表示後、何時間で再配布？**
- 24時間 
- 12時間
- 48時間

**Q37. 5種類の絵文字の具体的な選定は？**
- 基本感情（:heart::blush::sob::thinking::rage:）
- ポジティブ寄り（:heart::blush::sob::thinking::thumbsdown:） 
- カスタム

**Q38. フィードバック率の計算方法は？**
- ポジティブのみ
- ネガティブ除外
- 総合スコア 

**Q39. BAN判定の閾値は？**
- 回数ベース
- 率ベース 
- 詳細は後で

生成された仕様書

そして、これらの質問に全て答えた結果、Claude Code が自動的に生成した仕様書がこちらです。

8行の曖昧な SPEC が、約400行の詳細な仕様書 に変わりました。

# Y - 匿名ボトルメール型メッセージングサービス 仕様書

## 1. サービス概要

### 1.1 基本情報
- **サービス名**: Y
- **コンセプト**: 匿名のボトルメール型メッセージングサービス
- **ターゲット**: 幅広い年齢層（特定層に限定しない）
- **展開地域**: グローバル（言語混在）
- **プラットフォーム**: iOS, Android, Web

### 1.2 サービスの核となる体験
- **希少性・特別感**: 「自分だけに届いた」という偶然の出会いの貴重さを演出
- **主な利用動機**: 感情の吐露（誰かに聞いてほしいけど、知り合いには言えない心の内を放流する）
- **匿名性レベル**: ユーザー間は完全匿名、運営のみ必要時に閲覧可能

---

## 2. コア機能

### 2.1 メッセージ送信
- **形式**: テキストのみ
- **文字数制限**: 280文字
- **1日の送信上限**: 1通
- **日替わりテーマ**: 任意（ヒント程度）
  - プリセットから自動ローテーションで表示
  - テーマに沿わなくても送信可能

### 2.2 メッセージ受信（タイムライン）
- **表示数**: 3〜5通の未開封メッセージ
- **表示順序**: ランダム
- **表示情報**: フィードバック率（総合スコア）のみ
- **1日の開封上限**: 1通
- **スキップ**: 不可（タップしたら開封確定）

### 2.3 メッセージのライフサイクル
1. 送信されたメッセージはランダムなユーザーのタイムラインに表示される
2. 24時間経過しても開封されなかった場合、別のユーザーのタイムラインに再配布
3. 誰かが開封した時点でメッセージは消滅
4. 1人だけが開封可能

### 2.4 送信と受信の関係
- 送信と受信は完全に独立
- 送信しなくても受信できる
- 受信しなくても送信できる

---

## 3. フィードバックシステム

### 3.1 リアクション
- **種類**: 5種類の絵文字（ポジティブ寄り）
  - ❤️ (ハート) - 最も良い
  - 😊 (笑顔) - 良い
  - 😢 (泣き顔) - 共感・しんみり
  - 🤔 (考え中) - 微妙・中立
  - 👎 (サムズダウン) - 不快

### 3.2 フィードバック通知
- 送信者にフィードバックの存在は通知される
- **ただし、どのメッセージへのフィードバックかはわからない**
- 初めてフィードバックを受け取れるのは **20メッセージ送信後**

### 3.3 フィードバック率（総合スコア）
- 各リアクションに重み付けをしてスコア化
- タイムラインに表示される「率」はこの総合スコア
- 詳細な重み付けは運用しながら調整

---

## 4. モデレーション・安全対策

### 4.1 コンテンツフィルタリング
- **方式**: ハイブリッド
  1. まずルールベース（正規表現 + 禁止ワードリスト）で高速チェック
  2. 疑わしいものだけAIで再判定
- **チェック対象**:
  - 住所の記載
  - 特定の人物名
  - 攻撃的・違法なコンテンツ

### 4.2 利用停止（BAN）システム
- **方式**: 段階制（率ベース）
- 総合スコアが一定以下になった場合に段階的に制裁
  1. 警告
  2. 1日停止
  3. 3日停止
  4. 7日停止
  5. 永久BAN
- 具体的な閾値は運用しながら調整

### 4.3 過去の類似サービスからの学び
- 「誰に届くかわからない」仕組み自体が標的型いじめを防ぐ
- AIモデレーション + フィードバックによる自浄作用
- 悪質ユーザーは段階的BANで排除

---

## 5. ギミック・リテンション施策

### 5.1 日替わりテーマ
- プリセットから毎日自動でテーマを表示
- 例: 「小さな幸せ」「今日の失敗談」「誰かに言いたかったこと」など
- 強制ではなく、書きやすさを提供するヒント

### 5.2 ストリーク・実績（バッジ）
- **報酬**: バッジのみ（機能解放なし）
- **種類**: 累積実績で獲得
  - 送信数バッジ（10, 50, 100, 500, 1000通など）
  - 受信数バッジ
  - 良いフィードバック率バッジ
  - 連続ログインバッジ（7日, 30日, 100日など）

### 5.3 回数制限
- 1日1通送信、1通開封の制限が希少性を演出
- 「今日の1通」を大切にする体験

---

## 6. ユーザー認証・アカウント

### 6.1 認証方式
- **電話番号認証（SMS）**
- 複数アカウント作成のハードルを高く
- BANが効きやすい

### 6.2 グローバル対応
- 世界中の電話番号に対応
- 言語設定は端末に準拠
- 異なる言語のユーザー間でもメッセージは届く（言語混在）

---

## 7. 収益化

### 7.1 広告モデル
- **表示形式**: バナー広告
- **表示位置**: 画面上部または下部に常時表示
- 体験を大きく損なわない形で実装

### 7.2 将来的な拡張候補（MVPには含まない）
- プレミアムプラン（広告非表示、追加開封権など）
- 消費アイテム（追加開封チケットなど）

---

## 8. 技術要件

### 8.1 プラットフォーム
- iOS, Android, Webすべてで利用可能
- クロスプラットフォームフレームワークの使用を推奨

### 8.2 技術スタック
- フロントエンド・バックエンドともに要件に応じて選定
- 詳細は設計フェーズで決定

### 8.3 インフラ要件
- グローバル展開を見据えたスケーラビリティ
- メッセージの確実な削除（消滅）を保証する設計

---

## 9. MVP（最小限の製品）スコープ

### 9.1 MVP に含まれる機能
- ユーザー登録（電話番号認証）
- メッセージ送信（280文字、1日1通）
- タイムライン表示（3〜5通、フィードバック率表示）
- メッセージ開封（1日1通、開封後消滅）
- フィードバック送信（5種類の絵文字）
- フィードバック通知（20メッセージ送信後から）
- 基本的なコンテンツモデレーション
- バナー広告

### 9.2 MVP に含まれない機能（後続リリース）
- 日替わりテーマ
- ストリーク・実績バッジ
- 詳細なBAN段階制
- プレミアムプラン
- 消費アイテム

---

## 10. 用語集

| 用語 | 説明 |
|------|------|
| メッセージ | ユーザーが送信する280文字以内のテキスト |
| タイムライン | 未開封メッセージが表示される画面 |
| 開封 | メッセージを読むこと。1通につき1人だけ可能 |
| フィードバック | 開封後に送信する絵文字リアクション |
| フィードバック率 | 送信者の過去のメッセージに対するフィードバックの総合スコア |
| 再配布 | 24時間未開封のメッセージを別のユーザーに割り当てること |
| バッジ | 実績に応じて獲得できるプロフィール装飾 |

---

## 11. 決定事項サマリー

| 項目 | 決定内容 |
|------|----------|
| サービス名 | Y |
| コア体験 | 希少性・特別感 |
| 匿名性 | ユーザー間は完全匿名、運営のみ閲覧可能 |
| メッセージ形式 | テキストのみ、280文字 |
| 送信制限 | 1日1通 |
| 開封制限 | 1日1通 |
| タイムライン表示数 | 3〜5通 |
| タイムライン表示順 | ランダム |
| プレビュー情報 | フィードバック率のみ |
| スキップ | 不可 |
| 再配布 | 24時間後 |
| 送受信の関係 | 独立 |
| リアクション | 5種類の絵文字（ポジティブ寄り） |
| FB通知 | あり（どのメッセージかは不明） |
| FB開始条件 | 20メッセージ送信後 |
| モデレーション | ハイブリッド（ルール + AI） |
| BAN方式 | 段階制（率ベース） |
| 認証方式 | 電話番号認証 |
| 展開地域 | グローバル |
| 言語 | 混在（言語を超えてメッセージが届く） |
| 収益化 | バナー広告 |
| ギミック | 日替わりテーマ、ストリーク、実績バッジ |
| 報酬 | バッジのみ |
| テーマ運用 | プリセットからローテーション |
| MVP | コア機能のみ |

---

*この仕様書は、2026年1月3日時点でのヒアリング結果に基づいて作成されました。*

このように、曖昧なアイデアから始まっても、インタビュー形式で深掘りすることで仕様を具体化できます。

もちろん、まだまだこれだけで作り込んでいくのは難しいのですが、ここをスタート地点にして、より具体的な要件をさらに AskUserQuestionTool で深堀りしていくことができます。

注意点

もちろんすべてが最高というわけではなく、以下については注意が必要です。でも以下に関しては良いものを作る上では現状は避けて通れないものかと思うので「がんばりましょう！」という気持ちです。

  • 質問に答えるのに時間がかかる
  • 全ての質問が有用とは限らない（ただし、大半が「その観点必要だ！」と思えます）
  • 最終判断は自分で行う必要がある

まとめ

壁打ち相手がほしいとき、要件を整理したいとき、いつでも使えるテクニックです。ぜひ試してみてください！

Discussion