| name | persona-creation |
| description | UX/マーケティング向けのユーザーペルソナを、5つの専門エージェントチームで作成するスキル。 ペルソナ設計、ユーザーリサーチ、ナラティブ執筆、バイアスレビュー、データ検証の 5観点からペルソナをディスカッション型で議論・作成し、Markdownドキュメントとして出力する。 data-critic がライブモデレーターとして矛盾を検出・収束を判定する。 コンテキストファイルで過去のセッションを引き継げる。 Use when: ユーザーペルソナを作りたい、ターゲットユーザーを定義したい、 ペルソナシートを作成したい、UXリサーチ用のペルソナが必要、 マーケティング用のターゲット分析をしたい。 Triggers: "ペルソナ", "persona", "ターゲットユーザー", "target user", "ユーザー像", "ユーザー定義", "user profile", "ペルソナシート", "ターゲット分析", "ユーザーセグメント", "customer profile"
|
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」として受け入れ、レポートに明記）。
リアルタイム中継プロトコル（チームリーダー必須）
チームリーダーは、エージェントの議論をユーザーのメインチャットにリアルタイムで中継する。
中継のタイミング:
- セグメント設計の完了時: segments.md を Read し、選定理由・棄却理由を含めてユーザーに共有
- リサーチデータの完了時: research-data.md の要点をユーザーに共有
- ペルソナ1体完成ごと: 概要と設計意図をユーザーに共有
- バイアスレビュー結果: 主要な指摘事項をユーザーに共有
- [CHALLENGE] が出た場合: 対立点とそれぞれの根拠をユーザーに共有
- data-critic の矛盾検出時: 検出された矛盾とその解消状況をユーザーに共有
- Devil's Advocate の結果: 主要な批判とその対処をユーザーに共有
中継のフォーマット:
## {エージェント名} の {作業名}
### 結論
（何を決めたか）
### 思考プロセス
- 検討した選択肢: A, B, C
- A を採用した理由: ...
- B を棄却した理由: ...
- 根拠となったデータ: ...
### 不確実な点
（自信度が低い判断は正直に明記）
ユーザー質問プロトコル
エージェントが判断に迷ったとき、チームリーダーへ質問を委ねる。
エージェントからのリクエスト形式:
[チームリーダーへ] ❓ 判断を仰ぎたい点があります:
質問: {具体的な質問}
選択肢A: {案A}
選択肢B: {案B}
推奨: {推奨案とその理由}
→ ユーザーへの確認が必要であれば、お願いします。
チームリーダーは内容に応じて自己判断するか、AskUserQuestion でユーザーに確認する。
フィードバックプロトコル（全エージェント共通ルール）
- ディスカッションプロトコルに従う: [CHALLENGE]/[DEFEND] テンプレートを使って構造化議論
- 自分の作業が完了したら即座に関連エージェントへ共有
- 実質的な内容のある返信のみ送る - 「了解しました」だけのACKメッセージは不要
- バイアス問題は即座に警告: bias-reviewer は問題発見次第すぐ全員に通知
- フィードバックを受けたら修正し、変更内容を共有する
- 待ちすぎない: フィードバックを全員から集める必要はない。2人以上から反応があれば次のフェーズに進んでよい
- 全成果物は必ずファイルに書き出す - 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 が書き込み
検証手順:
- Glob で
personas/*.md のファイル数を確認（期待するペルソナ数と一致するか）
- 各ファイルを Read して、テンプレートのまま・空でないことを確認
- 不足・空のファイルがあった場合:
- まず該当エージェントに SendMessage で「Write ツールでファイルに書き込んでください」と依頼
- エージェントが応答しない、またはシャットダウン済みの場合: ディスカッションログからエージェントのコンテンツを抽出し、チームリーダー自身が Write で書き込む（フォールバック書き込み）
- 全ファイルの実体を確認できたら Step 4 に進む
Step 4: 最終レポート作成
全ファイルを Read で全文読み込み、PERSONAS_REPORT.md に統合する。テンプレートは references/report-template.md を参照。
重要: 数字だけのサマリー表は不十分。各判断に「なぜそう考えたか」の根拠を必ず添える。
Step 4.5: ペルソナ改善ラウンド（任意）
最終レポート作成後、ユーザーとの対話で改善点が見つかった場合に実施する追加ラウンド。
チームを再起動せず、チームリーダーが直接ペルソナファイルを Edit で修正する。
改善の進め方
- ユーザーとの対話またはレポートレビューで改善項目を洗い出す
- 改善項目を
PERSONAS_IMPROVEMENT_TODO.md（プロジェクトルート）にリスト化する
- 各項目を順に対応:
- 対象ペルソナファイルを Read → Edit で修正
- segments.md に影響がある場合はそちらも修正
- 改善ログを
round-01/improvement-log.md に記録
- 全項目完了後、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: クリーンアップ
- 全エージェントに
shutdown_request を送信
- 全員シャットダウン後に
TeamDelete でチーム削除
Shell Scripts リファレンス
init.sh - プロジェクト初期化
bash scripts/init.sh <project-name>
bash scripts/init.sh miravy
new-round.sh - 新ラウンド作成
bash scripts/new-round.sh <project-dir>
bash scripts/new-round.sh ~/.claude/persona-creation/2026-02-20_miravy
