client-validation-document

/digital-marketing-pro:client-validation-document — Part 5: 唯一の承認ポイント

このスキルでは、Part 5 の成果物であるクライアント検証ドキュメントを作成します。調査で得られた v1 の偏りのない知見を正式に提示し、クライアントが承認・却下・編集を判断する、プロジェクトの唯一の機会です。

コンテキストの効率化

負荷の高いスキルです。参照ファイルを Read する前に Grep し、一致した範囲だけを offset と limit を指定して Read してください。ファイルを開く前に ${CLAUDE_PLUGIN_DATA}/<brand>/ の内容を一覧表示してください。セッション途中で再度実行する場合は、すでにコンテキストにあるファイルをスキップしてください。

これは 12-Part のフローにおける唯一の承認ポイントです。ここで承認されるまで、Part 6 以降には進みません。

このドキュメントについて

クライアント検証ドキュメントは、Part 2、3、4 で得られた、戦略上もっとも重要な知見（偏りのない調査と4つの主要ドキュメント）を、体系的なレビュー用ドキュメントにまとめたものです。各知見には、以下を含めます。

• 知見そのもの
• 根拠／情報源
• 承認された場合に想定される影響
• クライアント向けの回答 विकल्प：ACCEPT / REJECT / EDIT / DEFER
• （REJECT または EDIT の場合）クライアントが修正版とその理由を提示

クライアントの回答は、Part 6 の Decision Matrix に反映され、必要な v2 の再実行内容が決まります。

このドキュメントではないもの

• Growth Plan ではありません。 戦略的な提言に見せかけたものではなく、調査結果をまとめたものです。Growth Plan は Part 8 で作成します。
• 網羅的なものではありません。 戦略に実質的な影響を及ぼす知見のみを含みます。詳細は元のドキュメントに記載します。
• スライドデッキではありません。 クライアントが丁寧に読み、回答するための文書です。スライドでは必要な厳密さを表現できません。
• 任意ではありません。 すべてのプロジェクトで Part 5 を実施します。これを省略して Part 6 に進むことはできません。

前提条件

このスキルを実行する前に、以下を満たしている必要があります。

1. Part 2、3、4 が完了していること（または、一部の調査が継続中であることを明示したうえで、実質的に完了していること）
2. プロジェクトの状態ファイル _engagement.json で、Part 3 と 4 が completed と示されていること
3. Living Project Instruction File が最新の v1 戦略的事実を反映していること

前提条件が満たされていない場合、出力を作成してはいけません。不足している内容をユーザーに伝えてください。

ドキュメント構成

クライアント検証ドキュメントは、知見のカテゴリーごとに構成します。各カテゴリーには3〜8件の知見を含め、ドキュメント全体では通常、カテゴリーをまたいで12〜25件の知見を扱います。

セクション1：エグゼクティブブリーフィング

長さ： 1ページ。

内容：

• このドキュメントの目的
• 読み方（ACCEPT / REJECT / EDIT / DEFER のフレームワーク）
• クライアントの回答後の流れ（Decision Matrix に基づき、Part 6 で v2 を再実行）
• 判断期限（通常7〜14日）

セクション2：カテゴリー別の知見

各カテゴリーには、構造化された形式で知見を記載します。カテゴリーは以下のとおりです。

A. ビジネスと SBU に関する知見（3.1 より）

事業の実態に関する知見 — SBU の分離、ユニットエコノミクス、バリューチェーン、成長レバー、制約、リスクなど。通常3〜5件の知見を含みます。

B. オーディエンスとセグメンテーションに関する知見（3.2 + 4.3 より）

ターゲットグループ、ペルソナの優先順位、意思決定ユニット、MQL／SQL の定義に関する知見。通常3〜5件の知見を含みます。

C. ポジショニングとコミュニケーションに関する知見（3.3 より）

選定したポジショニング、メッセージングの柱、トーン・オブ・ボイス、使用禁止ルール、デリケートな話題への対応に関する知見。通常3〜5件の知見を含みます。

D. チャネルと予算に関する知見（3.4 より）

チャネルの選定、市場内と市場外の配分、予算配分、チャネルの実施順序に関する知見。通常2〜4件の知見を含みます。

E. 競合に関する知見（4.1 + 4.2 より）

競合リスト、競争上のポジショニング、3つの質問への回答（うまくできていること／うまくできていないこと／実施していないこと）に関する知見。通常2〜4件の知見を含みます。

F. 市場と顧客に関する知見（4.3 + 4.4 より）

市場規模、顧客行動のパターン、需要シグナルに関する知見。通常2〜4件の知見を含みます。

セクション3：未解決の質問

偏りのない調査では解決できず、クライアントの入力が必要な質問です。クライアントがここに回答を記入します。

セクション 4：回答の仕組み

クライアントが回答をどのように返すか（通常は、構造化された回答ファイルまたはミーティングでの説明）。

指摘事項の形式

各指摘事項は、次の正確な構造に従います。

### Finding {ID}: {Short title}

**Category:** {A/B/C/D/E/F}
**Source:** {Document and step references — e.g., "3.1 Step 4, 4.1 Three-Question Output"}
**Materiality:** {High / Medium / Low}

**Finding:**
{2–4 sentences stating the finding from the unbiased research}

**Evidence:**
- {Cited source 1 with specific data point}
- {Cited source 2}
- {Cited source 3}

**Proposed implication if accepted:**
{1–3 sentences on what this means for the strategy if the client accepts}

**Client response:**

- [ ] ACCEPT — finding is correct as stated
- [ ] REJECT — finding is wrong; correction below
- [ ] EDIT — finding is partially correct; amended version below
- [ ] DEFER — needs further investigation; reason below

**If REJECT or EDIT, client correction:**
{Client fills in: what the correct finding is, with their evidence}

**If DEFER, reason and follow-up plan:**
{Client fills in: what additional research / data is needed, who is accountable, deadline}

重要度の分類

各指摘事項には、回答がどの程度重大な影響を及ぼすかを示す重要度が設定されます。

• 高 — 受け入れるか却下するかによって、チャネル構成、予算、ポジショニング、またはオーディエンスの優先順位が大きく変わります。Decision Matrix に従って v2 の再実行が必要になります。
• 中 — 受け入れるか却下するかによって戦略的な方向性は変わらないものの、戦術的な実行方法が変わります。再実行が必要になる場合と、ならない場合があります。
• 低 — 受け入れるか却下するかによって表現や例は変わりますが、内容は変わりません。再実行は必要ありません。

クライアントは重要度が高い指摘事項に最も注目してください。重要度が中または低の指摘事項も、漏れなく提示します。

Decision Matrix の回答分類

クライアントから回答を受け取った後、回答を Decision Matrix のトリガーに分類します。

クライアントの判断パターン	Decision Matrix のトリガー
競合に関する指摘事項が却下された、または新たな競合を加えて修正された場合	competitors_changed
市場規模に関する指摘事項が却下または修正された場合	target_market_changed
ペルソナの変更を伴うセグメンテーションに関する指摘事項が却下または修正された場合	audiences_changed
ポジショニングに関する指摘事項が却下または修正された場合	positioning_changed
予算またはスコープに関する指摘事項が却下または修正された場合	budget_or_scope_changed
価格設定または提供内容に関する指摘事項が却下または修正された場合	pricing_or_offering_changed
ユニットエコノミクスに関する指摘事項が却下または修正された場合	unit_economics_changed
重要度が低い指摘事項の修正、または軽微な表現の訂正のみの場合	minor_corrections_only

このスキルはトリガーの一覧をまとめ、次を実行します。

python ${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py decision-matrix \
  --brand {slug} --id {id} \
  --triggers "{comma-separated-trigger-list}"

その出力は、Part 6 の v2 再実行計画に反映されます。

作成手順

1. 前提条件を確認する — Parts 2、3、4 が完了していることを確認します。

2. v1 のソースドキュメントを読み込む：

   • part-03-four-core-documents/v1/3.1-business-and-sbu-analysis.md
   • part-03-four-core-documents/v1/3.2-segmentation-framework.md
   • part-03-four-core-documents/v1/3.3-brand-positioning-and-communications.md
   • part-03-four-core-documents/v1/3.4-dmflow.md
   • part-04-competitive-customer-market/v1/4.1-competitor-ad-analysis.md
   • part-04-competitive-customer-market/v1/4.2-competitor-positioning.md
   • part-04-competitive-customer-market/v1/4.3-customer-analysis.md
   • part-04-competitive-customer-market/v1/4.4-market-analysis.md

3. 重要な指摘事項を抽出する。 各ソースドキュメントから、戦略上最も重大な指摘事項を2～5件特定します。重要度は高または中を優先し、クライアントが確認するメリットが明確にある場合に限り、重要度が低の指摘事項も含めます。

4. 指摘事項を所定の形式にまとめる。 社内用の専門用語ではなく、クライアントに伝わりやすい表現を使います。各指摘事項は単独で理解できるようにし、クライアントがソースドキュメントを読まなくてもわかる内容にします。

5. 各ソースドキュメントの「未解決の質問」セクションをもとに、「未解決の質問」セクションを追加する。

6. 回答の仕組みのセクションを追加する — クライアントに回答の返送方法を案内します（推奨：ドキュメントと併せて client-validation-responses.json ファイルを作成します）。

7. ドキュメントを次の場所に保存する：

   engagements/{id}/part-05-client-validation/client-validation-document.md
   

8. 回答テンプレートを生成する：

   engagements/{id}/part-05-client-validation/client-validation-responses.template.json
   

   各指摘事項につき1つのエントリーを含め、判断／修正のフィールドは空欄にします。

9. _engagement.json で Part 5 を awaiting_input に設定する（completed にはしないでください。Part 5 が完了するのは、クライアントの回答が記録された後です）。

10. ユーザーにドキュメント、回答の仕組み、および通常7～14日の判断期間について説明する。

クライアントの回答を記録する

クライアントから回答（記入済みの JSON ファイル、または会議で記録した口頭での説明）が返ってきたら、次の手順を実行します。

1. 記入済みの回答ファイルを次の場所に保存します。

   engagements/{id}/part-05-client-validation/client-validation-responses.json
   

2. engagement-state.py decision-matrix --validation-file <path> を実行し、v2 の再実行計画を判断します。

3. Part 5 を completed にします。

4. Part 6（v2 の再実行）に進みます。

品質を徹底する

1. クライアントに伝わる平易な言葉を使います。「MQL/SQL ファネルのアーキテクチャ」のような専門用語は使いません。「見込み顧客が関心を持った段階から購入の準備が整うまでの流れ」と言い換えます。
2. **各調査結果は単独で意味が通じるようにします。**クライアントが調査結果を理解するために、参照元のドキュメントを確認する必要がないようにします。
3. 根拠を明確に示します。「市場データによると……」のような曖昧な主張は認められません。具体的なデータとともに、出典を明記します。
4. **重要度を正直に評価します。**受け入れにくい調査結果を伝えやすくするために、「Low」に引き下げてはいけません。
5. 未解決の質問は、本当に答えが必要な質問に限ります。「未解決の質問」セクションを設けるためだけに、質問を作り上げてはいけません。
6. **回答方法を構造化します。**自由形式のクライアントメールは Decision Matrix のトリガーに変換しにくいため、JSON 回答テンプレートを使ってパターンを明確にします。

例

例 1：ドキュメントの作成

User: We've completed Parts 2, 3, 4 for Acme. Time to prepare the Client Validation Document.

Skill response:
1. Verify pre-conditions ✓
2. Pull findings from the 8 source documents (4 from Part 3 + 4 from Part 4) using grep first to locate each category's section, then targeted Read with offset+limit — avoid bulk-Read on all 8 files up front or you'll blow the per-skill 5K-token budget
3. Extract 18 material findings across categories A–F:
   - 4 in Business & SBU
   - 3 in Audience & Segmentation
   - 4 in Positioning & Communications
   - 3 in Channel & Budget
   - 2 in Competitive
   - 2 in Market & Customer
4. 12 are High materiality, 5 Medium, 1 Low
5. 4 Open Questions identified from source docs
6. Save document at engagements/2026-q2/part-05-client-validation/client-validation-document.md (~22 pages)
7. Save response template at engagements/2026-q2/part-05-client-validation/client-validation-responses.template.json
8. Mark Part 5 as awaiting_input
9. Brief: "Document ready. 18 findings, 4 open questions. Recommend client meeting in 5–7 days for live walk-through, with responses returned within 2 weeks."

例 2：クライアントの回答の記録

User: Acme client returned responses. They accepted most but rejected the positioning finding (they want to keep their existing positioning) and added 2 new competitors we missed.

Skill response:
1. Read the populated client-validation-responses.json
2. Categorise responses: 16 ACCEPT, 1 REJECT (positioning), 1 EDIT (competitor list)
3. Determine triggers: positioning_changed + competitors_changed
4. Run engagement-state.py decision-matrix --triggers "positioning_changed,competitors_changed"
5. Output: triggered re-runs = 3.1, 3.2, 3.3, 3.4, 4.1, 4.2 (the union of both triggers' re-run sets)
6. Estimate cost: ~85K tokens
7. Mark Part 5 completed
8. Brief: "Part 5 closed. 6 v2 re-runs triggered. Recommend reviewing the re-run plan and approving before invoking four-core-documents and competitor-analysis with view=v2."

関連スキル

• engagement-workflow — 12 部構成のフローを統括します
• four-core-documents — 検証対象の v1 ドキュメントを作成し、Part 5 の後に v2 の再実行も行います
• 既存のスキル／エージェント competitor-analysis、audience-intelligence、market-intelligence が Part 4 のドキュメントを作成しました

関連リファレンス

• engagement-flow-methodology.md — Part 5 の概要
• decision-matrix-rerun.md — 回答を再実行に反映する方法
• two-views-model.md — v1 + v2 のアーキテクチャ
• stone-vs-opinion.md — 確信度のタグ付けに関する背景