Deep Research

厳密なフォーマット制御、エビデンスマッピング、ソース管理、マルチパス統合を備えた高品質なリサーチレポートを作成します。

アーキテクチャ: リードエージェント + サブエージェント

Lead Agent (コーディネーター — 生の検索コンテキストを最小化)
  |
  P0: 環境 + ソースポリシーセットアップ
  |
  P1: リサーチタスクボード (ロール、クエリ、並列グループ)
  |
  Dispatch ──→ Subagent A ──→ task-a.md を作成 ──┐
           ──→ Subagent B ──→ task-b.md を作成 ──┤ (並列実行)
           ──→ Subagent C ──→ task-c.md を作成 ──┘
  |                                               |
  |     research-notes/  <────────────────────────┘
  |
  P2: source_type + as_of + authority を用いた引用レジストリの構築
  P3: カウンター主張フラグ付きのエビデンスマップ概要
  P4: ノートから草稿を作成 (生の検索結果からではなく)
  P5: カウンターレビュー (主張、確信度、代替案)
  P6: 検証 (レジストリ内のすべての [n]、追跡可能性チェック)
  P7: ポーランド化 → 確信度マーカー付きの最終レポート

コンテキスト効率: サブエージェントの生の検索結果は彼らのコンテキスト内に留まり、廃棄されます。リードエージェントは蒸留されたノートのみを見ます(約60-70%のコンテキスト削減)。

モード選択

開始前にリサーチモードを決定します:

次元	オプション
トピックモード	エンタープライズリサーチ (企業/法人) またはゼネラルリサーチ (業界/ポリシー/技術)
深度モード	標準 (5-6タスク、3000-8000語) またはライトウェイト (3-4タスク、2000-4000語)

• エンタープライズリサーチモード: 構造化分析フレームワーク (SWOT、リスク行列、競争障壁の定量化) を伴う6次元データ収集
• ゼネラルリサーチモード: ソース管理を伴う標準 P0-P7 リサーチパイプライン
• 深度選択: 単一エンティティ/コンセプト < 30語の場合はライトウェイト、マルチエンティティ比較または「深入」/「包括的」リクエストの場合は標準

ソース管理 (V6)

ソースアクセシビリティ分類

重要ルール: すべてのソースはアクセシビリティで分類する必要があります:

アクセシビリティ	定義	例	使用ルール
public	認証なしで任意の外部研究者が利用可能	公開ウェブサイト、ニュース記事、WHOIS (プライバシーなし)、学術論文	✅ 常に許可
semi-public	登録または限定的なアクセスが必要	LinkedInプロフィール、Crunchbase基本、業界レポート (無料版)	✅ 開示付きで許可
exclusive-user-provided	ユーザーの有料サブスクリプション、プライベートAPI、プロプライエタリデータベース	Crunchbase Pro、PitchBook、プライベートデータフィード、内部データベース	✅ 許可 (第三者リサーチ)
private-user-owned	ユーザーが自身を研究するときのユーザー自身のアカウント	ユーザーのドメインレジストラー(ユーザー自身の企業用)、ユーザーの銀行(ユーザー自身の財務用)	❌ 禁止 - 循環検証

⚠️ 循環検証禁止: 以下の行為をしてはいけません:

• ユーザーのプライベートデータを使用して、彼らが既に知っていることを「発見」する
• ユーザーのプライベートアカウントにアクセスしてユーザー自身の企業を研究する
• ユーザーのプライベートな知識を「リサーチ結果」として提示する

✅ 排他的情報利益: 以下を行うべき:

• ユーザーの Crunchbase Pro を使用して競合他社を研究する
• ユーザーのプロプライエタリデータベースを市場調査に使用する
• ユーザーのプライベート API を投資分析に使用する
• ユーザーが提供する任意の排他的ソースを第三者リサーチに活用する

ソースタイプラベル

すべてのソースは以下のタグも付ける必要があります:

ラベル	定義	例
official	一次ソース、公式ドキュメント	企業SEC提出書類、政府レポート、公式ブログ
academic	ピアレビュー研究	学術誌記事、カンファレンス論文、博士論文
secondary-industry	プロフェッショナル分析	業界レポート、アナリストカバレッジ、業界誌
journalism	ニュースレポート	信頼できるメディア、調査報道
community	ユーザー生成コンテンツ	フォーラム、レビュー、ソーシャルメディア、Q&Aサイト
other	未分類または混合	アグリゲータ、未検証ソース

品質ゲート:

• 標準モード: 最終承認セットで ≥30% の公式ソース
• ライトウェイトモード: ≥20% の公式ソース
• 最大単一ソースシェア: ≤25% (標準)、≤30% (ライトウェイト)
• 最小ユニークドメイン: 5 (標準)、3 (ライトウェイト)

AS_OF 日付ポリシー

P0 で AS_OF 日付を明示的に設定します。すべての時間的に敏感な主張について:

• 各引用にソース公開日を含める
• ソースが関連地平線より古い場合は確信度を下げる
• レジストリで古いソースにフラグを付ける (研究 >3年、ニュース >6ヶ月(急速に変動するトピック))

P0: 環境 & ポリシーセットアップ

開始前に機能をチェック:

チェック	要件	欠落の影響
web_search利用可能	必須	停止 - 進められません
web_fetch利用可能	DEEP タスク用に必須	SCAN のみモード
サブエージェント派遣	推奨	シーケンシャルに低下
ファイルシステム書き込み可能	必須	メモリ内ノートのみ

ポリシー変数を設定:

• AS_OF: 今日の日付 (YYYY-MM-DD) - 時間的トピックでは必須
• MODE: 標準 (デフォルト) またはライトウェイト
• SOURCE_TYPE_POLICY: 公式/学術/二次/ジャーナリズム/コミュニティ/その他ラベルを強制
• COUNTER_REVIEW_PLAN: テストする反対解釈

レポート: [P0 complete] Subagent: {yes/no}. Mode: {standard/lightweight}. AS_OF: {YYYY-MM-DD}.

特定の企業/エンタープライズを調査する場合、6次元カバレッジ、定量化分析フレームワーク、3段階品質管理を確保する特化したワークフローに従います。

エンタープライズワークフロー概要

エンタープライズリサーチ進捗:
- [ ] E1: インテーク — 企業エンティティ、リサーチ深度、フォーマット契約を確認
- [ ] E2: 6次元データ収集 (可能な限り並列)
  - [ ] D1: 企業基礎 (エンティティ、設立、資金調達、所有権)
  - [ ] D2: ビジネス & 製品 (セグメント、製品、収益構造)
  - [ ] D3: 競争ポジション (業界ランク、競合他社、障壁)
  - [ ] D4: 財務 & 運用 (3年財務、効率メトリクス)
  - [ ] D5: 最近の動向 (6ヶ月イベント、戦略シグナル)
  - [ ] D6: 内部/プロプライエタリソース (または制限事項を注記)
- [ ] E3: 構造化分析フレームワーク
  - [ ] SWOT分析 (エビデンスベース、4象限 × 3-5エントリ)
  - [ ] 競争障壁定量化 (7次元、重み付けスコア)
  - [ ] リスク行列 (8カテゴリ、確率 × インパクト)
  - [ ] 総合スコアカード (6次元、重み付け合計)
- [ ] E4: 各段階移行で L1/L2/L3 品質チェック
- [ ] E5: 7章エンタープライズテンプレートを使用して草稿
- [ ] E6: マルチパス草稿 + UNION マージ (下の一般的なステップ 6-7 と同じ)
- [ ] E7: ヒューマンレビューのために草稿を提示して繰り返す

P1: リサーチタスクボード

リサーチクエスチョンを 4-6 の調査タスク (標準) または 3-4 タスク (ライトウェイト) に分解します。

各タスク割り当ては以下を含みます:

• エキスパートロール: スペシャリストペルソナ (例: 「ポリシー歴史家」、「エコシステムマッパー」)
• 目的: 1文の調査目標
• クエリ: 2-3 の事前計画検索クエリ
• 深度: DEEP (2-3 の完全記事を取得) または SCAN (スニペットで十分)
• 出力: リサーチノートファイルへのパス
• 並列グループ: グループA (独立) またはグループB (グループAに依存)

タスク分解ルール

1. 各タスクはスペシャリストが所有する1つのコヒーレントな副トピックをカバー
2. グループA タスクは独立し、ソース多様化している必要があります
3. 並列グループあたり最大 3 タスク (同時実行制限)
4. すべてのタスクは時間敏感な主張にフラグを付け、予期される引用老化リスク

エンタープライズリサーチ統合

エンタープライズリサーチモード時、タスクボードは6次元にマッピング:

• タスク A: 企業基礎 (エンティティ、設立、資金調達、所有権)
• タスク B: ビジネス & 製品 (セグメント、製品、収益構造)
• タスク C: 競争ポジション (業界ランク、競合他社、障壁)
• タスク D: 財務 & 運用 (3年財務、効率メトリクス)
• タスク E: 最近の動向 (6ヶ月イベント、戦略シグナル)
• タスク F: 内部/プロプライエタリソース (または制限事項を記録)

レポート: [P1 complete] {N} tasks in {M} groups. Dispatching Group A.

---

エンタープライズリサーチモード (特化したパイプライン)

特定の企業/エンタープライズを調査する場合、6次元カバレッジ、定量化分析フレームワーク、3段階品質管理を確保する特化したワークフローに従います。

E1: インテーク

上記の P0/P1 と同じ、プラス:

• 調査している正確な法人エンティティを確認 (親会社対子会社)
• リサーチ深度を選択: クイックスキャン (3-5ページ) / 標準 (10-20ページ) / ディープ (20-40ページ)
• 特定の比較対象 (ベンチマーク企業) を特定

P2: 派遣 + 調査

サブエージェントは references/subagent_prompt.md を使用してタスクを実行し、references/research_notes_format.md に出力します。

サブエージェント付き (Claude Code / Cowork / DeerFlow)

1. グループA タスクを並列派遣 (最大3同時)
2. 各サブエージェントは検索、取得、ソースタイプをタグ付け
3. すべてのソース行は Source-Type と As Of を含む
4. グループA 完了を待つ
5. グループB を派遣 (グループA ノートを読める)

サブエージェント出力要件

各 task-{id}.md は以下を含む必要があります:

• ソースセクション: 実際の検索結果からの URL、Source-Type、As Of、Authority (1-10)
• 結果セクション: ソース番号付き最大 10 文の事実
• ディープリード注記 (DEEP タスク): 2-3 ソースを完全に読んだもの、重要データ/インサイト付き
• ギャップセクション: 検索されたが見つからなかったもの、代替解釈

サブエージェントなし (低下モード)

リードエージェントがタスクをシーケンシャルに実行し、各スペシャリストとして機能します。生の検索結果はノートを書いた後に廃棄されます。

エンタープライズリサーチ: 6次元収集

references/enterprise_research_methodology.md を参照して以下を実施:

• 次元ごとの詳細収集ワークフロー (クエリ戦略、データフィールド、検証)
• データソース優先度マトリクス (P0-P3 ランキング)
• クロス検証ルール (最小ソース数、最大偏差閾値)

重要原則:

• エビデンスドリブン: すべての結論は引用可能なソースをトレースする必要があります
• マルチソース検証: 重要データは ≥2 の独立ソースが必要
• 抑制された判断: 推測は明示的にマーク、無根拠な主張を避ける
• 構造化提示: 複雑な情報はテーブル、リスト、階層を介して

各次元完了後に L1 品質チェックを実施 (enterprise_quality_checklist.md を参照)。

タスクごとのステータス: [P2 task-{id} complete] {N} sources, {M} findings. 全体ステータス: [P2 complete] {N} tasks done, {M} total sources. Building registry.

E3: 構造化分析フレームワーク

references/enterprise_analysis_frameworks.md から順序でフレームワークを適用:

1. SWOT分析 — 各エントリにエビデンス + ソース + インパクト評価付き
2. 競争障壁定量化 — 7次元、重み付けスコア → A+/A/B+/B/C+/C 評価
3. リスク行列 — 8 必須カテゴリ、確率 × インパクト → 赤/黄/緑
4. 総合スコアカード — 6次元重み付け合計 → X/10

分析完了後に L2 品質チェックを実施。

E4: 品質管理

references/enterprise_quality_checklist.md から3段階チェック:

• L1 (データ): ソース数、属性、クロス検証、タイムリーネス
• L2 (分析): SWOT 完全性、リスクカバレッジ、障壁スコアリング、結論サポート
• L3 (ドキュメント): 構造準拠、フォーマット一貫性、読みやすさ、付録

E5: エンタープライズテンプレートを使用した草稿

enterprise_quality_checklist.md から7章エンタープライズレポートテンプレートを使用:

1. 企業概要
2. ビジネス & 製品構造
3. 市場 & 競争ポジション
4. 財務 & 運用分析
5. リスク & 懸念事項
6. 最近の動向
7. 総合評価 & 結論

プラス付録: データソースインデックス、用語集、免責事項。

E3-E7: エンタープライズ分析、草稿、レビュー

• E3: 構造化分析 — references/enterprise_analysis_frameworks.md からフレームワークを適用
• E4: 品質管理 — references/enterprise_quality_checklist.md に従い L1/L2/L3 チェックを実施
• E5: 草稿 — 7章エンタープライズテンプレートを使用
• E6-E7: マルチパス草稿とレビュー — 下の P4-P7 と同じ

---

P3: 引用レジストリ + ソース管理

リードエージェントがすべてのタスクノートを読み、統一レジストリを構築します。

レジストリプロセス

1. すべてのタスクファイルの ## Sources セクションを読む
2. すべてのソースをマージ、URL で重複を除去
3. 最初の出現順に [n] 番号を割り当て
4. タグ付け: source_type、as_of日付、authority スコア (1-10)、タスク id
5. 品質ゲートを適用:
   • 標準: ≥12 承認ソース、≥5 ユニークドメイン、≥30% 公式
   • ライトウェイト: ≥6 承認ソース、≥3 ユニークドメイン、≥20% 公式
   • 最大単一ソースシェア: ≤25% (標準)、≤30% (ライトウェイト)
6. ソースを削除 (閾値以下) してそれらを明示的にリスト

レジストリ出力フォーマット

CITATION REGISTRY

Approved:
[1] Author/Org — Title | URL | Source-Type: official | Accessibility: public | Date: 2026-03-01 | Auth: 8 | task-a
[2] ...

Dropped:
x Source | URL | Source-Type: community | Accessibility: privileged | Auth: 3 | Reason: PRIVILEGED SOURCE - NOT ALLOWED

Stats: {approved}/{total}, {N} domains, official_share {xx}%
Privileged sources rejected: {N}

重要ルール: これらの [n] は最終です。P5 は承認リストからのみ引用できます。削除ソースは決して再出現しません。

循環検証の処理: ユーザー自身の企業/資産を調査する場合、ユーザーのプライベートアカウント内でデータを発見した場合 (例: ユーザーのドメインレジストラーが彼らがドメインを所有していることを示す)、以下を必ず実施:

1. レジストリから拒否 (ユーザーは既にこれを知っています)
2. 「CIRCULAR - USER ALREADY KNOWS」として削除セクションに注記
3. 同等の公開ソースを検索 (例: 公開WHOIS、ニュース記事)
4. 外部調査者の視点からのみ報告

排他的ソースの処理: ユーザーが第三者リサーチのために有料サブスクリプションまたはプライベートAPI を明示的に提供した場合 (例: 「競合他社を調査するために Crunchbase Pro を使用」):

1. 「exclusive-user-provided」アクセシビリティとして受け入れる
2. 競争利益として使用
3. レジストリで適切に引用
4. 公開同等物が存在しない場合、クレームを [unverified] とマークするか省略

レポート: [P3 complete] {approved}/{total} sources. {N} domains. Official share: {xx}%. Privileged rejected: {N}.

情報ブラックボックスの処理

公開フットプリントのないエンティティ (「字节跳动子公司」の例のような) を調査する場合:

外部研究者が見つけるもの:

• WHOIS: プライバシー保護 → オーナー情報なし
• Web検索: ニュース、プレスリリースなし
• ソーシャルメディア: 企業ページなし
• ビジネスレジストリ: 公開APIなしまたはローカルアクセス必須
• 結果: 完全な情報ブラックボックス

正しい応答:

結果: 公開情報利用不可

チェックされたソース:
- WHOIS (公開): プライバシー保護 [失敗]
- 企業レジストリ (公開): アクセス拒否/APIなし [失敗]
- ニュースメディア: カバレッジなし [失敗]
- 企業ウェブサイト: プレースホルダーのみ [最小限]

評決: 外部視点から企業存在を検証できない
見つかったソース: 0 (または最小限、例: ドメイン存在を示すWHOISのみ)
確信度: N/A - 不十分なエビデンス

しないこと:

• ❌ ユーザー自身の認証情報を使用してギャップを「埋める」
• ❌ ドメイン登録だけに基づいて企業存在を仮定
• ❌ 推測で欠落データを埋める
• ❌ プライベート手段でアクセスした情報を「検証済み」と主張

すること:

• ✅ 外部研究者が検証できる/できないことを明確に述べる
• ✅ すべての失敗した検索試行を文書化
• ✅ 主張を [unverified] としてマークするか完全に省略
• ✅ ライトウェイトモードへのダウングレードまたは不十分な公開ソースの場合は停止を推奨
• ✅ デューデリジェンスの直接接触を推奨

---

P4: エビデンスマップ概要

リードエージェントがノート + レジストリを読んで概要を構築します。

1. クロスタスク パターンを特定
2. セクションを設計 (タスク順ではなくトピックファーストで)
3. 各セクションを特定の結果とソース番号にマップ
4. カウンターレビューが必要なセクションにフラグを付け
5. 最近性を考慮する主張を AS_OF チェック でマーク

概要フォーマット:

## N. {Section Title}
Sources: [1][3][7] from tasks a, b
Claims: {claim from task-a finding 3}, {claim from task-b finding 1}
Counter-claim candidates: {alternative explanations}
Recency checks: {source dates + AS_OF}
Gaps: {limited official evidence}

---

P5: ノートから草稿

references/report_template_v6.md を使用してセクションごとに書きます。

ルール:

• すべての事実的主張には引用 [n] が必要
• 数字/パーセンテージはソースが必要
• セクションごとに 確信度マーカー を追加: 高/中/低 と根拠付き
• エビデンスが競合する場合、反論文 を追加
• 新しいソースは導入不可
• サポートされていないステートメントは [unverified] を使用

ハルシネーション対策:

• リードエージェントは URL を発明しない — サブエージェントノートのみ
• リードエージェントはデータを捏造しない — ノートにない場合は [unverified] とマーク

ステータス: [P5 in progress] {N}/{M} sections, ~{words} words.

---

P6: カウンターレビュー (必須)

主要な結論ごとに、反対方向チェックを実施:

1. 結論は間違っている可能性は?
2. どの高インパクト主張が単一ソースに依存?
3. どの主張が公式/学術サポートを欠いている?
4. 古いソースが時間敏感な主張に使用されている?
5. ≥3 の問題を見つける (0 見つかった場合は再検討)

カウンターレビューチーム使用 (推奨)

包括的な並列レビューのため、カウンターレビューチームを使用:

# 1. 入力を準備
counter-review-inputs/
  ├── draft_report.md
  ├── citation_registry.md
  ├── task-notes/
  └── p0_config.md

# 2. 4 人のスペシャリストエージェントに並列派遣
SendMessage to: claim-validator
SendMessage to: source-diversity-checker
SendMessage to: recency-validator
SendMessage to: contradiction-finder

# 3. すべてのスペシャリストの完了を待つ

# 4. コーディネーターに統合用に送信
SendMessage to: counter-review-coordinator
  inputs: [4 specialist reports]

# 5. 最終 P6 カウンターレビューレポートを受信

references/counter_review_team_guide.md を詳細使用法として参照。

マニュアルカウンターレビュー (フォールバック)

カウンターレビューチームが利用できない場合、マニュアルチェックを実施:

• すべての高確信主張が ≥2 ソースあることを検証
• 重要な主張の公式/学術バックアップを確認
• 時間敏感な主張の AS_OF 日付を検証
• 反対解釈を文書化

出力

最終レポートに含める:

## 核心争議 / Key Controversies
- **争议 1:** [主张 A 与反向证据 B 对比] [n][m]
- **争议 2:** ...

レポート: [P6 complete] {N} issues found: {critical} critical, {high} high, {medium} medium.

---

P7: 検証

最終化前にクロスチェック:

1. レジストリクロスチェック: レポート内のすべての [n] 対 承認レジストリ
2. スポットチェック 5+主張: タスクノートをトレース
3. トレース不可能な主張を削除/修正
4. 削除ソースが復活していないことを検証
5. 重要な主張のソース集中度をチェック

レポート: [P7 complete] {N} spot-checks, {M} violations fixed.

---

出力要件

• リクエストされた言語とトーンを一致させる
• 技術用語は英語のまま保つ
• レポート仕様とフォーマットルールを尊重
• 参考文献またはビブリオグラフィーセクションを含める

リファレンスファイル

コア V6 パイプラインリファレンス

ファイル	読むタイミング
source_accessibility_policy.md	P0 (重要): ソース分類ルール - まず最初に読む
subagent_prompt.md	P2: サブエージェントへのタスク派遣
research_notes_format.md	P2: サブエージェント出力フォーマット
report_template_v6.md	P5: 確信度マーカーとカウンターレビュー付きで草稿
quality_gates.md	すべてのフェーズ: 品質閾値とハルシネーション対策チェック

ゼネラルリサーチリファレンス

ファイル	読むタイミング
research_report_template.md	概要を構築して構造を草稿
formatting_rules.md	セクションフォーマットと引用ルールを強制
source_quality_rubric.md	ソースをスコア化および優先順位付け
research_plan_checklist.md	リサーチプランとクエリセットを構築
completeness_review_checklist.md	カバレッジ、引用、準拠をレビュー

エンタープライズリサーチリファレンス (エンタープライズリサーチモード時に読み込み)

ファイル	読むタイミング
enterprise_research_methodology.md	6次元データ収集ワークフロー、ソース優先度、クロス検証ルール
enterprise_analysis_frameworks.md	SWOT テンプレート、競争障壁定量化、リスク行列、総合スコアリング
enterprise_quality_checklist.md	L1/L2/L3 品質チェック、次元ごとチェックリスト、7章レポートテンプレート

アンチパターン

• カウンターパスなしのシングルパス草稿
• セクション別にパスを分割するのではなく完全レポート草稿
• フォーマット契約またはユーザーテンプレートを無視
• 引用またはエビデンステーブルマッピングなしの主張
• 不一致の日付を明確にせずにミックス
• 検証なしで外部 AI 出力をコピー
• 中間草稿または生リサーチ出力を削除
• リードエージェントが生の検索結果を読む — サブエージェントノートのみ読む
• URL を発明する — 実際の検索結果からのみ URL を使用
• 削除ソースを復活させる — P3 で削除されたものは決して再出現しない
• 時間敏感な主張の AS_OF を欠く — 常にソース日付を含める
• カウンターレビューをスキップ — 必須 P6 は ≥3 の問題を見つける必要があります
• 循環検証 — ユーザー自身の知識を「発見」するためにユーザーのプライベートデータを使用しない
• 排他的ソースを無視 — ユーザーが Crunchbase Pro 等を競合他社研究のために提供した場合、使用する

次のステップ: 検証と配信

リサーチ完了後、検証と出力を提案:

リサーチレポート完成: [N] ソース引用、[M] 主張。

オプション:
A) 事実検証 — レポートで /fact-checker を実行 (推奨)
B) スライド作成 — 結果から /ppt-creator を実行
C) PDF としてエクスポート — 公式配信の /pdf-creator を実行
D) いいえ — レポートはそのままで準備完了です