Persona Creation Skill

5つの専門エージェントがディスカッション型でチーム議論し、UX/マーケティング向けのユーザーペルソナを作成する。 data-critic がライブモデレーターとして矛盾検出・収束判定を行い、品質を担保する。 コンテキストファイルで過去のセッションを引き継ぎ、反復的にペルソナを改善できる。

ワークフロー概要

Step 1: ヒアリング（必須情報 + 調査設定の合意）
Step 2: チーム作成・エージェント起動
Step 3: Phase 1 ディスカッション → Gate 1 → Phase 2 ディスカッション → Gate 2
Step 3.5: ファイル書き込み検証
Step 4: 最終レポート作成
Step 5: ユーザーへの最終報告
Step 6: クリーンアップ

コンテキストファイル構成

.claude/persona-creation/{YYYY-MM-DD}_{project}/
├── context.md              <- 全体コンテキスト（プロダクト情報・学びの蓄積）
├── SUMMARY.md              <- 全ラウンドを横断するサマリー
├── personas/
│   ├── persona-01.md       <- ペルソナプロファイル
│   ├── persona-02.md
│   └── ...
└── round-{N}/
    ├── context.md          <- このラウンドの目的・制約
    ├── log.md              <- このラウンドの議事録
    ├── segments.md         <- ユーザーセグメントと評価結果
    ├── research-data.md    <- リサーチデータ（出典付き）
    ├── bias-review.md      <- バイアスレビュー結果
    └── critique.md         <- data-critic の Gate 結果・検証記録

---

Step 1: ヒアリング

AskUserQuestion でユーザーから情報を収集する。不明な項目は推測せず必ず質問する。

必須（欠けていたら質問）

• プロダクト概要: 何をするサービス/アプリか、コア機能
• ターゲット市場: 国・地域、言語、年齢層
• ペルソナの用途: UXデザイン / マーケティング / プロダクト開発 / 投資家向け
• 作成したいペルソナの数: 3〜5体を推奨

任意（あれば精度が上がる）

• 既存ユーザー情報: 分析データ、インタビュー結果
• 重視する属性: デモグラフィック / 行動パターン / 心理特性 / 課題
• 既知のセグメント: すでに想定しているユーザー層があれば

調査設定（ユーザーに確認）

AskUserQuestion で以下を確認:

「作業の進め方を確認させてください」

• 選択肢1: 「途中で確認したい（推奨）」→ Gate 1 でセグメント案をユーザーに見せてから執筆開始
• 選択肢2: 「一気に最後まで」→ Gate 1 のユーザー確認をスキップして自動続行
• 選択肢3: 「重要な判断があれば都度聞いて」→ Gate 1 + エージェントが迷った場面で随時確認

---

Step 2: チーム作成とエージェント起動

TeamCreate で persona-creation チームを作成。以下5エージェントを 1つのメッセージで並列に Agent ツールで起動する。

name	役割	主な手段
persona-architect	ペルソナ設計・セグメント定義・JTBD フレームワーク策定	分析
user-researcher	市場調査・ユーザー行動リサーチ・データ裏付け	WebSearch
persona-writer	ペルソナナラティブ・プロファイル執筆	Write/Edit
bias-reviewer	バイアス・ステレオタイプ・多様性チェック	分析
data-critic	ライブモデレーション・矛盾検出・Gate 運営・コンテキスト管理	WebSearch/Write

各エージェントは agents/ ディレクトリにサブエージェントとして定義済み。

タスク作成

TaskCreate で以下を作成:

Phase 1（初回に全て作成）:
1. data-critic: コンテキストファイルの初期作成 + モデレーション開始
2. persona-architect: セグメント設計・JTBD フレームワーク策定（addBlockedBy: ["1"]）
3. user-researcher: 市場・ユーザー行動リサーチ（addBlockedBy: ["1"]）
   - リサーチ結果を round-01/research-data.md に書き出す
4. bias-reviewer Phase 1: セグメントのバイアスチェック（addBlockedBy: ["1"]）
5. Gate 1: セグメント確定 + ユーザー確認（addBlockedBy: ["2","3","4"]）
   - data-critic が Gate 合意形成を主導。チームリーダーはユーザーへの中継を担当

Phase 2（Gate 1 PASS 後にチームリーダーが作成）:
6. persona-writer: ペルソナプロファイル執筆
   - セグメント確定後すぐに執筆開始。リサーチデータは届き次第取り込む
7. Gate 2 + 統合レポート（addBlockedBy: ["6"]）
   - data-critic が Devil's Advocate + Independent Validation を運営

重要: タスク 6-7 は Gate 1 PASS 後に TaskCreate で追加する。初回に全て作らない。

起動設定

subagent_type: "persona-architect"  # agents/ で定義済み
team_name: "persona-creation"
mode: "bypassPermissions"
run_in_background: true

プロンプトに含める情報（全エージェント共通）:

• プロダクト概要、ターゲット市場、ペルソナの用途、作成数
• ベースディレクトリの絶対パス（⚠️必須）: init.sh が出力する絶対パスをそのまま使う
  • 例: /Users/babashunsuke/.claude/persona-creation/2026-02-21_miravy/
  • ⚠️ Write ツールは絶対パスのみ受け付ける。.claude/... のような相対パスは動作しない
  • 全エージェントのプロンプトに「ファイル書き込み時はこの絶対パスをベースにしてください」と明記する
• 既存の context.md がある場合はその内容も含める
• ファイル書き込み注意: 「init.sh はディレクトリのみ作成し、テンプレートファイルは作成しない。全てのファイルはあなたが Write ツールで新規作成する必要がある」と明記する
• ペルソナファイル命名規則: persona-writer のプロンプトにファイル名を明示する（persona-01.md, persona-02.md, ... のゼロ埋め2桁。persona-1.md 形式は禁止）
• 判断に迷ったときはチームリーダーに [チームリーダーへ] ❓ 形式で SendMessage すること

---

Step 3: ディスカッション型ラウンド進行

ディスカッションプロトコル（全 Phase 共通）

全フェーズで以下の3ステップサイクルを繰り返す。data-critic がライブモデレーターとして常時監視する:

┌─────────────────────────────────────────────────┐
│ Step A: 独立調査・設計                              │
│   persona-architect がセグメントを設計              │
│   user-researcher が WebSearch で市場調査           │
│   bias-reviewer がセグメントをレビュー               │
│   data-critic が全メッセージを監視・矛盾を検出       │
│                                                   │
│ Step B: 共有 + 批判                               │
│   各エージェントが主要発見を SendMessage で全員に共有  │
│   他エージェントが矛盾・疑問を指摘（批判テンプレート）  │
│   data-critic が議論を促進・矛盾をフラグ             │
│                                                   │
│ Step C: 防御 / 修正 + 追加調査                     │
│   批判を受けたエージェントが根拠を提示して防御        │
│   または追加調査・修正してファイルを更新              │
│   data-critic が収束条件をチェック                   │
│                                                   │
│ → data-critic が収束を宣言するまで Step B-C を繰り返す│
└─────────────────────────────────────────────────┘

批判テンプレート（[CHALLENGE]）

[CHALLENGE] → {対象エージェント名}
主張: {相手の主張を要約}
問題: {矛盾・疑問の具体的内容}
根拠: {自分のデータ/ロジック}
提案: {修正案 or 追加調査すべき点}

防御テンプレート（[DEFEND]）

[DEFEND] ← {批判元エージェント名}
批判: {受けた批判の要約}
回答: {根拠を提示して防御 / 批判を受け入れて修正}
修正: {ファイルを修正した場合の変更点}

収束条件（data-critic が判定）

✅ 全エージェントの主要発見が共有済み
✅ 全ての [CHALLENGE] に対する [DEFEND] が完了
✅ 新しい批判が2巡連続で出なくなった
✅ 未解決の矛盾が明示的に記録されている
→ data-critic が収束を宣言し、Gate に進む

Phase 1: セグメント設計とリサーチ（並列進行 + ライブモデレーション）

persona-architect、user-researcher、bias-reviewer が並列起動。data-critic が並行してモデレーション。

[persona-architect]
  → 全員に: ユーザーセグメント案（3〜5セグメント）+ JTBD 定義を送信
  → user-researcher: 「各セグメントの市場規模やトレンドを調査してください」
  → bias-reviewer: 「セグメント設計のバイアスチェックをお願いします」

[user-researcher]
  → persona-architect に: リサーチ結果・データ裏付け（データ信頼度スコア付き）
  → データがセグメント仮説を否定する場合: [CHALLENGE] テンプレートで指摘
  → 全員に: 市場トレンド・ユーザー行動データ（ファイル出力 + 要約メッセージ）

[bias-reviewer]
  → persona-architect に: セグメント設計のバイアスチェック結果（即座に）
  → 問題があれば [CHALLENGE] テンプレートで指摘

[data-critic]（ライブモデレーション）
  → 矛盾検出: エージェント間の主張が矛盾していたら即座に全員にフラグ
  → 議論促進: 異論が出ていない主張にも根拠を問う
  → 議事録を log.md にリアルタイム記録
  → 収束条件チェック → 収束宣言

主要なディスカッション軸:

persona-architect ←→ user-researcher（セグメント仮説 vs リサーチデータ）
persona-architect ←→ bias-reviewer（セグメント設計のバイアス）
user-researcher ←→ bias-reviewer（リサーチデータ自体のバイアス）
data-critic → 全員（矛盾検出・議論促進・収束判定）

Gate 1: セグメント確定 + ユーザーチェックポイント

data-critic が収束を宣言したら、以下の流れで進行:

1. data-critic が Gate 1 合意形成を主導

[全員へ] Gate 1: セグメント合意確認
以下のセグメント案で合意しますか？
（セグメント一覧を提示）
→ 各自、合意/反対/修正案 を SendMessage で回答してください。

PASS/FAIL 基準:

基準	PASS 条件
セグメント数	3〜5個
データ裏付け	各セグメントに Tier 1 or 2 のデータあり
バイアスチェック	bias-reviewer スコア B 以上
エージェント合意	3/4 以上が合意
MECE	セグメント間の重複なし

2. data-critic がチームリーダーに Gate 1 結果を報告

[チームリーダーへ] Gate 1 結果: {PASS/FAIL}
{合意サマリー・投票結果・残存リスク}
→ ユーザーへの中間報告をお願いします。

3. チームリーダーがユーザーに中間報告（調査設定が「途中で確認」or「都度確認」の場合）

## Gate 1: セグメント案の中間確認

### 提案セグメント一覧
（セグメント名 + 定義 + JTBD + 推定規模 + プロダクトとの関係を表形式で）

### 採用の根拠
（なぜこのセグメントを選んだか。データに基づく説明）

### 検討して棄却したセグメント案
（何を検討してなぜ採用しなかったか）

### リサーチデータサマリー
（主要なデータポイントと出典、データ信頼度スコア）

### バイアスチェック結果
（主な指摘と対応状況）

### ディスカッションの論点
（主要な [CHALLENGE]/[DEFEND] とその結論）

### 不確実な点
（自信度が低い判断は正直に明記）

AskUserQuestion: 「セグメント案が出揃いました。このまま進めますか？」

• 選択肢1: 「このまま進めて」→ Phase 2 開始
• 選択肢2: 「方向修正したい」→ フィードバックを聞いて persona-architect に修正を指示
• 選択肢3: 「別のセグメントも検討して」→ 追加候補を議論

調査設定が「一気に最後まで」の場合は自動で Phase 2 に進む。

Phase 2: ペルソナ執筆（並列レビュー + ライブモデレーション）

Gate 1 PASS 後、persona-writer を起動。他エージェントが並行してサポート。data-critic が引き続きモデレーション。

[persona-writer]
  → セグメント確定後すぐに執筆開始（リサーチデータは届き次第取り込み）
  → 1体完成ごとに全員に共有

[user-researcher]
  → persona-writer に: セグメント別の詳細データをプロアクティブに提供
  → ペルソナのデータ整合性チェック（年齢・職業・収入の組み合わせが現実的か）

[bias-reviewer]
  → 1体完成ごとにストリーミングレビュー → persona-writer に [CHALLENGE] or フィードバック
  → インターセクショナリティ（交差性）チェックも実施

[persona-architect]
  → 1体完成ごとにフレームワーク準拠チェック → persona-writer にフィードバック

[data-critic]（ライブモデレーション継続）
  → ペルソナ間のデータ整合性を監視
  → 年齢×職業×収入の非現実的な組み合わせを検出してフラグ
  → bias-reviewer スコア C 以下のペルソナに注意喚起

Gate 2: Devil's Advocate + Independent Validation

全ペルソナが揃ったら、data-critic が Gate 2 を主導:

Step 1: Devil's Advocate ラウンド（data-critic が運営）

[全員へ] 🎭 Devil's Advocate ラウンド開始
全ペルソナに対して「このペルソナはなぜ現実的でないか」「このセグメント設計のどこが甘いか」を
批判的な視点で指摘してください。テンプレートで送信してください。

各エージェントが以下テンプレートで提出:

[DEVILS_ADVOCATE]
対象: {ペルソナ名 or セグメント名}
批判: {なぜ問題か}
根拠: {データ/ロジック}
最悪シナリオ: {この批判が正しければ何が起きるか}
深刻度: Fatal / Major / Minor

data-critic がまとめて処理:

• Fatal: 対象エージェントに修正を指示（再ディスカッション）
• Major: リスクとして最終レポートに記録
• Minor: 懸念事項として記録

Step 2: Independent Validation（data-critic が実施）

data-critic が自ら WebSearch で以下を独立検証:

• セグメント仮説が外部データと一致するか
• ペルソナの属性が実在するユーザー像と整合するか
• 見落とされている重要なユーザー層がないか

Step 3: 最終 PASS/FAIL

基準	PASS 条件
Fatal 指摘	全て解消済み
ペルソナ品質	全ペルソナに bias-reviewer B 以上
データ裏付け	各ペルソナの主要属性に出典あり
独立検証	重大な矛盾なし

FAIL の場合は修正指示 → 再検証（最大2回。3回目の FAIL は「Low Trust」として受け入れ、レポートに明記）。

---

リアルタイム中継プロトコル（チームリーダー必須）

チームリーダーは、エージェントの議論をユーザーのメインチャットにリアルタイムで中継する。

中継のタイミング:

1. セグメント設計の完了時: segments.md を Read し、選定理由・棄却理由を含めてユーザーに共有
2. リサーチデータの完了時: research-data.md の要点をユーザーに共有
3. ペルソナ1体完成ごと: 概要と設計意図をユーザーに共有
4. バイアスレビュー結果: 主要な指摘事項をユーザーに共有
5. [CHALLENGE] が出た場合: 対立点とそれぞれの根拠をユーザーに共有
6. data-critic の矛盾検出時: 検出された矛盾とその解消状況をユーザーに共有
7. Devil's Advocate の結果: 主要な批判とその対処をユーザーに共有

中継のフォーマット:

## {エージェント名} の {作業名}

### 結論
（何を決めたか）

### 思考プロセス
- 検討した選択肢: A, B, C
- A を採用した理由: ...
- B を棄却した理由: ...
- 根拠となったデータ: ...

### 不確実な点
（自信度が低い判断は正直に明記）

ユーザー質問プロトコル

エージェントが判断に迷ったとき、チームリーダーへ質問を委ねる。

エージェントからのリクエスト形式:

[チームリーダーへ] ❓ 判断を仰ぎたい点があります:
質問: {具体的な質問}
選択肢A: {案A}
選択肢B: {案B}
推奨: {推奨案とその理由}
→ ユーザーへの確認が必要であれば、お願いします。

チームリーダーは内容に応じて自己判断するか、AskUserQuestion でユーザーに確認する。

---

フィードバックプロトコル（全エージェント共通ルール）

1. ディスカッションプロトコルに従う: [CHALLENGE]/[DEFEND] テンプレートを使って構造化議論
2. 自分の作業が完了したら即座に関連エージェントへ共有
3. 実質的な内容のある返信のみ送る - 「了解しました」だけのACKメッセージは不要
4. バイアス問題は即座に警告: bias-reviewer は問題発見次第すぐ全員に通知
5. フィードバックを受けたら修正し、変更内容を共有する
6. 待ちすぎない: フィードバックを全員から集める必要はない。2人以上から反応があれば次のフェーズに進んでよい
7. 全成果物は必ずファイルに書き出す - Write → Read → SendMessage の順序

緊急通知パターン（即座に全員へ共有すべき事項）

• data-critic: エージェント間の矛盾を検出 → 即座に全員にフラグ
• bias-reviewer: ステレオタイプ・差別的表現を発見 → 該当ペルソナの修正を即依頼
• user-researcher: セグメント仮説を否定するデータを発見 → [CHALLENGE] で persona-architect に指摘
• persona-architect: セグメント間の重大な重複を発見 → 全員に統合/分割の提案

[全員へ] ⚠️ 緊急: {問題の概要}
理由: {具体的理由}
→ {対応すべきエージェント}: {具体的なアクション}を実施してください。

---

データ不足時のフォールバック戦略

Tier 1: 直接データあり（理想）

• 対象ユーザー層の統計・調査レポートが存在
• 通常のフローで進行

Tier 2: 類似カテゴリからの類推

• 直接データがない場合、最も近い上位カテゴリや類似サービスのデータを使用
• 例:「iOSユーザーのデータ」がなければ「スマホユーザー全体」から推計
• 類推であることを明記し、ファイルに「類推データ（出典: ○○）」と記録

Tier 3: 定性情報のみ

• 定量データが一切存在しない場合
• App Store レビュー・SNS・フォーラムの定性情報から推定
• 「定量データなし、定性情報からの推定」と正直に記載

Tier 4: 専門家推論

• 定性情報すら十分に存在しない場合
• 類似領域の専門知識に基づく推論
• 「データなし、専門家推論」と明記し、推論の根拠を記述
• data-critic が Tier 4 使用時は必ずフラグする

各エージェントはデータ不足を検知したらチームリーダーに「Tier {N} で進行します」と報告する。 チームリーダーはユーザーにフォールバック状況を共有する。

---

Step 3.5: ファイル書き込み検証（チームリーダー必須）

全エージェントのタスクが completed になった後、最終レポート作成の前に以下を検証する。テンプレートのままや空のファイルは「書き込み失敗」と判断する。

# 検証対象ファイル（全て実体があること）
.claude/persona-creation/{date}_{project}/
├── context.md              <- data-critic が書き込み
├── SUMMARY.md              <- data-critic が書き込み
├── personas/
│   ├── persona-01.md       <- persona-writer が書き込み（内容があること）
│   ├── persona-02.md
│   └── ...
└── round-01/
    ├── context.md          <- data-critic が書き込み
    ├── log.md              <- data-critic が書き込み
    ├── critique.md         <- data-critic が書き込み
    ├── segments.md         <- persona-architect が書き込み
    ├── research-data.md    <- user-researcher が書き込み
    └── bias-review.md      <- bias-reviewer が書き込み

検証手順:

1. Glob で personas/*.md のファイル数を確認（期待するペルソナ数と一致するか）
2. 各ファイルを Read して、テンプレートのまま・空でないことを確認
3. 不足・空のファイルがあった場合:
   • まず該当エージェントに SendMessage で「Write ツールでファイルに書き込んでください」と依頼
   • エージェントが応答しない、またはシャットダウン済みの場合: ディスカッションログからエージェントのコンテンツを抽出し、チームリーダー自身が Write で書き込む（フォールバック書き込み）
4. 全ファイルの実体を確認できたら Step 4 に進む

---

Step 4: 最終レポート作成

全ファイルを Read で全文読み込み、PERSONAS_REPORT.md に統合する。テンプレートは references/report-template.md を参照。

重要: 数字だけのサマリー表は不十分。各判断に「なぜそう考えたか」の根拠を必ず添える。

---

Step 4.5: ペルソナ改善ラウンド（任意）

最終レポート作成後、ユーザーとの対話で改善点が見つかった場合に実施する追加ラウンド。 チームを再起動せず、チームリーダーが直接ペルソナファイルを Edit で修正する。

改善の進め方

1. ユーザーとの対話またはレポートレビューで改善項目を洗い出す
2. 改善項目を PERSONAS_IMPROVEMENT_TODO.md（プロジェクトルート）にリスト化する
3. 各項目を順に対応:
   • 対象ペルソナファイルを Read → Edit で修正
   • segments.md に影響がある場合はそちらも修正
   • 改善ログを round-01/improvement-log.md に記録
4. 全項目完了後、PERSONAS_REPORT.md と SUMMARY.md を更新

典型的な改善項目

カテゴリ	例
セクション追加	代替手段、乗り換えシナリオ、無料→有料の転換点
解像度向上	特定セグメントの具体的つまずきポイント、チャネル追加
データ統合	市場トレンド（例: コンテキストエンジニアリング）のペルソナへの反映
成長パス	セグメント間の移行ジャーニーの具体化
インタビューガイド	仮説検証用の質問リスト作成

改善ログのフォーマット

## TODO {N}: {改善テーマ} ✅

### {ペルソナ名}
**変更箇所**: {セクション名}
- {具体的な変更内容}

**根拠**: {なぜこの改善が必要だったか}

注意事項

• 名前・基本属性の変更は慎重に: 変更する場合は PERSONAS_REPORT.md、SUMMARY.md 等の下流ドキュメントも全て更新すること
• 改善は additive（追加的）を基本とする: 既存の良い記述を消さず、セクションを追加する形で改善する
• 改善項目はインタビューガイドへの示唆も記録: 改善した仮説は interview-guide.md の検証項目にも反映する

---

Step 5: ユーザーへの最終報告

統合レポート完成後、チームリーダーは全ソースファイルを Read し、根拠と思考プロセスを含む詳細な最終報告をユーザーに直接提示する。

提示する最終報告の構成:

## 最終レポート

### 1. 作成ペルソナ一覧
- 名前 / セグメント / 年齢 / 職業 / プロダクトとの関係 / データ信頼度の表

### 2. セグメント設計
- 採用セグメントと根拠（データ裏付け付き）
- JTBD（Jobs-to-be-Done）定義
- 検討して棄却した案とその理由
- ディスカッションの主要論点（どこで合意し、どこで意見が分かれたか）

### 3. リサーチデータサマリー
- 主要データポイントと出典
- データ信頼度スコア（High/Medium/Low）
- データ不足があった場合のフォールバック状況

### 4. 各ペルソナの概要と設計意図
（1体ごとに：キャラクター概要 + なぜこの人物像にしたか）

### 5. バイアスレビュー結果
- 個別スコア（A/B/C/D）と主な指摘
- 全体の多様性評価

### 6. データ品質評価
- 領域別信頼度スコア（data-critic 評価）
- Tier 2/3/4 で進行した領域の詳細

### 7. Devil's Advocate の結果
- 主要な批判とその対処
- 残存リスク（Major 以上）

### 8. Independent Validation の結果
- data-critic の独立検証で発見した点

### 9. 活用ガイド
- UXデザイン / マーケティング / プロダクト開発での具体的な活用方法

### 10. 次のステップ

AskUserQuestion: 「ペルソナが完成しました。次のステップについて相談させてください。」

• 選択肢1: 「ユーザージャーニーマップを作りたい」→ user-journey スキルへ
• 選択肢2: 「もっと深掘りしたいペルソナがある」→ Step 4.5 改善ラウンドへ
• 選択肢3: 「インタビューガイドを作りたい」→ 仮説検証用の質問リストを round-01/interview-guide.md に作成
• 選択肢4: 「一旦ここまでで良い」→ レポートの保存場所を案内

---

Step 6: クリーンアップ

1. 全エージェントに shutdown_request を送信
2. 全員シャットダウン後に TeamDelete でチーム削除

---

Shell Scripts リファレンス

init.sh - プロジェクト初期化

bash scripts/init.sh <project-name>

# 例
bash scripts/init.sh miravy
# -> .claude/persona-creation/2026-02-20_miravy/ を作成

new-round.sh - 新ラウンド作成

bash scripts/new-round.sh <project-dir>

# 例
bash scripts/new-round.sh ~/.claude/persona-creation/2026-02-20_miravy
# -> round-02/ を作成