benchmark-due-diligence

ベンチマークのデューデリジェンス

ユーザーが羨むベンチマーク――創業者、KOL、企業、または製品など、成功がどこか不自然なほど輝かしく見える対象――を取り上げ、単なる中立的な報告ではなく、**「これが自分にとって何を意味するか」**で締めくくる分析を作成します。成果物では、バランスの取れたブリーフィングでは決して答えない3つの問いに答えます。成功のうち、実態はどれほどで、マーケティングによる膨張はどれほどなのか？再現可能な手法によるものと、運やタイミングによるものはそれぞれどれほどなのか？そして、依頼者は具体的に何を活用できるのか？

これは、敵対的で意思決定を重視する、deep-researchの姉妹スキルです。deep-researchが世界の信頼できる全体像を構築するのに対し、このスキルではその全体像は証明されるまで誇張されていると見なし、検証を生き残った情報を依頼者自身の行動に変換します。

重要：インラインで実行し、決して context: fork にしない

このスキルはオーケストレーターです。並行する収集エージェントと検証エージェントを（WorkflowツールまたはTaskエージェント経由で）起動し、他のスキル（deep-research、osint-investigate、qcc）を呼び出すこともあります。サブエージェントは、サブエージェントの起動やスキルの呼び出しができません。context: forkを設定すると、並列処理全体が気づかないうちに破綻します。contextフィールドを追加しないでください。（osint-investigateのドキュメントにも記載されている、好みの問題ではなく厳格なランタイムルールです。）

依頼者を守る唯一のルール：2つのインジェクションチャネル

エージェントが目にするものは、必ず次の2つのチャネルのどちらかを通ります。これらを分離することが、このスキルで最も重要な規律です。

チャネル	内容	インジェクション先
FACTS	ベンチマークについて、すでに検証済みの公開情報（関係性、所有者、見出しとなる主張に付けられた ⚠️ to-verify フラグなど）	すべてのエージェント――収集、検証、統合
COMMISSIONER_CONTEXT	依頼者の非公開の実情――実際に利用可能なリソース、クライアント名、戦略的意図、現実に活用できるもの	最終マッピングエージェント（フェーズ4）のみ

**この分離が譲れない理由：**収集エージェントと検証エージェントは入力を受け取り、それを使って外部のWebSearchを実行します。依頼者のクライアント名や戦略がプロンプトに漏れると、オープンウェブ上で検索され、プライバシー侵害につながります。マッピングフェーズでは「依頼者が誰か」という情報が本当に必要ですが、収集フェーズでは決して目にしてはいけません。実行中に覚えておくことに頼らず、オーケストレーションにこの分離を組み込んでください（references/workflow_orchestration_template.mdを参照）。

フェーズ 0 — 見た目ではなく証拠で土台を固める（エージェントを動かす前に実施）

12 エージェントへの並列展開を最も手早く無駄にする方法は、見た目から推測した土台の上にそれを構築することです。よく起こる失敗パターンは 2 つあり、どちらも実際の実行で問題を引き起こしています。

1. 名前やドメインからエンティティ間の関係を推測する。 「コンテンツが academy.example.com にあり、この人が創設者なのだから、このコミュニティも所有しているはずだ」——実際には、招待されたゲストにすぎなかった、という場合があります。共通のドメイン、似た名前、同時に言及されていることは観察事項であり、所有権を示すものではありません。A↔B の関係を事実として扱う前に、権威ある情報源で確認してください。
2. 依頼者のクライアントを、依頼者の資産として扱う。 依頼者がアクセラレーターやブランドのためにサービスを提供している場合、そのアクセラレーターはクライアントの資産です。依頼者はそのオーディエンスや資本を活用できません。依頼者が実際には管理していないリソースにベンチマークの戦略を当てはめると、空中楼閣を築くことになります。

そのため、並列展開の前に、雰囲気ではなく証拠に基づいて以下を確立します。

• ベンチマーク対象の実際のエンティティグラフ — 誰が誰を所有し、誰が単なるパートナーやゲストなのか。名前から推測してはいけません。
• 主要な主張の帰属先 — ベンチマークのストーリー全体は通常、「製品 X をゼロから 100 万ユーザーに増やした」といった 1 つの実績指標に基づいています。その人物は創設者ですか、それとも退職したグロースリードですか？これは最優先の確認事項です。⚠️ を付けて FACTS に記録してください。
• 依頼者が実際に管理しているもの — 所有資産とクライアント／パートナーの資産を分けます。

結果を FACTS（公開部分）と COMMISSIONER_CONTEXT（非公開部分）に記録してください。土台が不確かだと、後続のエージェントは自信満々に誤った結論を出します。

4 段階のオーケストレーション

Workflow ツール（推奨。決定論的なファンアウトが可能です。すぐに使えるテンプレートは references/workflow_orchestration_template.md を参照）または Task エージェントを使用します。エージェント数は、ユーザーが求める徹底度に合わせて調整します（簡単に確認する場合は数個の観点、詳細に監査する場合は複数回の投票による検証を含めて 6 つ以上）。

フェーズ 1 ＋ 2 — 観点ごとに、収集 → 検証をパイプラインとして実施（各観点では、収集が終わった時点ですぐに検証します。全体の完了を待つ必要はありません）。

• 収集エージェント — 客観的な立場を取ります。すべての調査結果にソース URL と source_kind（对象自述/营销、第三方独立信源、混合のいずれか）を付けます。見つからなかった情報は gaps に記録し、推測で補ってはいけません。
• 検証エージェント — 反証を重視し、懐疑的な姿勢を基本とする立場を取ります。すべての主張を L1–L4 で評価し、坐实 / 大体可信 / 存疑 / 证伪-水分 のいずれかで判定します。特に見出しとなる主張（目玉となる統計、「#1 ランキング」、資金調達額、ユーザー数）について、反証となる証拠を積極的に探すことが役割です。bubble_summary には、その観点で最も誇張されている点を記載します。

評価基準、source_kind、判定、および両方の JSON スキーマについては、references/evidence_grading_rubric.md を参照してください。

一般的な観点（ベンチマークの種類（人物／企業／製品）に合わせて調整してください）：

1. 対象者の背景 ＋見出しとなる主張の帰属（誇張が最も疑われる対象）
2. 企業の基盤 — 法人、創業、資金調達／評価額
3. 中核となる製品／事業の実際の指標 — ユーザー数、売上、ランキング、受賞歴。第三者情報と照合します
4. プレイブックの解体分析 — プラットフォームの一覧、ペルソナ、コンテンツの種類、他者のオーディエンスをどう取り込んでいるか、個人 IP から製品へどう誘導しているか
5. 比較対象 — 構造的に似た同業者または並行する道筋
6. セクター ＋ この種のプレイブックが通常どう成功し、通常どう失敗するか

フェーズ 3 — 統合：デューデリジェンスの結論（単一エージェントがすべての判定を使用します）。

1. 実際の関係図（フェーズ 0 でよくある誤解を修正します）
2. 誇張を検証する表 — 主張 | 証拠レベル | 判定 | 根拠を一行で示す。誇張の大きい順に並べます
3. プレイブックの解体分析 — 具体的で再現可能なアクション
4. 成功要因の帰属分析（中核） — 成功のうち、製品、市場のタイミング、個人 IP マーケティング、運用がそれぞれ占める割合はどの程度ですか？理由とともに割合の範囲を示し、再現可能な手法と運・タイミング・移転できない資質を明確に分けてください。

フェーズ 4 — 統合：依頼者にとっての意味（単一エージェントがフェーズ 3 ＋ COMMISSIONER_CONTEXT を使用します）。

1. リソース対応表 — ベンチマークのプレイブック要素 × 依頼者が実際に持つリソース。各セルに ✅ 取り入れ可能／⚠️ 再現不可能（運／タイミング）／🔄 すでに実施中／🚫 誇張されているため模倣しない、のいずれかを付け、それぞれ一行で説明します
2. 適用先 — 依頼者がこれをどのように活用するかを具体的に示します（依頼者の to-B サービス／独自 IP／ツール）
3. アクションリスト ＋ 未解決の質問（まだ確認されていない事項）

成功要因の重み付けと 4 種類のタグによる対応付けのフレームワークについては、references/attribution_and_resource_mapping.md を参照してください。

すでにあるものを作り直さない

このスキルの強みは、反証を重視した誇張の検証＋成功要因の帰属分析＋依頼者への対応付けの各レイヤーです。その下を支える仕組み自体は新しいものではないため、再利用してください。

• ファンアウトによる収集／ソース管理 — deep-research のリードエージェント＋サブエージェントのパターンを活用します。（ここで独自なのは懐疑的な検証姿勢と L1–L4 による誇張の評価であり、並列処理ではありません。）
• 人物を対象とする場合の本人確認／活動実態の確認 — 本人特定の帰属を再検討するのではなく、osint-investigate（ACH 仮説マトリックス、Bellingcat 方式の手掛かり追跡）を呼び出します。
• 中国本土の企業登記／資金調達 — 工商データには qcc 系のスキルを呼び出します。
• ソーシャルプラットフォームのプレイブックデータ — agent-reach CLI は B站／小红书／抖音／YouTube／X に対応しています。

実行前にお読みください

• references/evidence_discipline_traps.md — 繰り返し起きる落とし穴（外見から関係性を推測する、見出しの主張を誤って帰属させる、クライアントとアセットを混同する、分散の前に基盤を固める、二択にせず段階評価する、プライバシー漏えい）と、実際の解体調査で起きた失敗談を紹介しています。まずこれをお読みください。実際の調査で問題が起きるのは、ここに書かれている点です。
• references/evidence_grading_rubric.md — L1～L4、source_kind、判定、収集／検証スキーマについて説明しています。
• references/attribution_and_resource_mapping.md — 帰属の重み付け、4タグのマッピング、着地点のフレームワークについて説明しています。
• references/workflow_orchestration_template.md — FACTS / COMMISSIONER_CONTEXT の注入をすでに組み込んだ、すぐに記入できる Workflow スクリプトです。

次のステップ

デューデリジェンスの結論がまとまったら、自然な次のステップを提案してください（オプトイン方式。自動実行はしません）。

Due-diligence teardown is done.

Options:
A) Render it as a shareable PDF report — pdf-creator (Recommended if this goes to a partner/team)
B) One dimension needs deeper neutral background — deep-research on that sub-topic
C) No thanks — the markdown teardown is enough