deep-research

深掘り調査

厳密な形式制御、根拠の対応付け、ソース管理、複数回の統合により、精度の高い調査レポートを作成します。

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

Lead Agent (coordinator — minimizes raw search context)
  |
  P0: Environment + source policy setup
  |
  P1: Question and claim map (decision questions, evidence routes, stop rules)
  |
  Dispatch ──→ Subagent A ──→ writes task-a.md ──┐
           ──→ Subagent B ──→ writes task-b.md ──┤ (parallel)
           ──→ Subagent C ──→ writes task-c.md ──┘
  |                                               |
  |     research-notes/  <────────────────────────┘
  |
  P2: Dispatch + investigate → evidence packets
  P3: Citation registry + source governance
  P4: Evidence-mapped outline with counter-evidence and unknowns
  P5: Draft from evidence packets; reopen decisive originals
  P6: Counter-review (claims, confidence, alternatives)
  P7: Verify → asset check and catalog registration

コンテキストの管理： 生の検索結果に含まれるノイズはタスクの作業領域に留めます。ロケーターと短いソース抜粋を含む根拠パケットをリードエージェントに渡します。メモは情報を振り分けるための補助であり、根拠そのものではありません。リードエージェントは、レポートで重要な主張、矛盾する主張、正確な数値・日付・引用を使う場合、そのすべてについて元のソースを開かなければなりません。

実行とアセットに関する契約 — 毎回の実行

外部から情報を取得する前に、research-asset-contract.mdを読みます。単一ルートの調査でも複数ルートの調査でも、永続的なプロジェクト調査を新規作成または再開します。明示された過去の調査カタログを検索し、関連する過去の元資料を開いて、再利用・適応・却下の判断を記録します。study.jsonに、判断に関する質問とプロバイダー × 実際のモードのレーンを記述します。ユーザーが指定したシードURL、固有名詞、クエリに必要な確認済みコードやその他の識別子を含む、正確なdispatch_contextを1つ作成します。この文字列をすべてのレーンのプロンプトに含めます。含まれていない場合、research_assets.py startは拒否します。外部に依頼する前に、ユーザーが指定したシード記事または文書を元資料として保存します。また、プロバイダーがそのURLを読み取れない場合は、プロバイダーへの引き継ぎに従います。コーディネーターがユーザーのリンクやローカルファイルを認識していても、モデルのワークスペースからそれらが見えるとは限りません。その後、provider_runs.py planを実行します。ユーザーが依頼したすべてのモードを計画に残します。価値を追加できないルート、利用できないルート、または有料利用の許可がないルートには、理由を示すdeferredイベントを記録します。直接のウェブ検索と内部サブエージェントから組み立てたレポートにも、直接ソースを取得するレーンと同じアーカイブが必要です。

新規調査では、スキーマ2のリクエストモード契約を使います。元のリクエストと承認されたワークフローをアーカイブし、実行レーンとは独立して必須モードを解釈し、それぞれを対応するレーンに割り当てます。モードが依頼されていない場合は、モード一覧が明示的に空でも有効ですが、契約が欠落していてはなりません。割り当てられたルートが省略または不一致の場合、planは拒否します。元のリクエストと照合して一覧を確認します。フィールドやハッシュだけでは、意味上の完全性を証明できません。スキーマ1のアーカイブは、リクエストのカバレッジが不明なものとして引き続き読み取り可能です。この不足を補うために、古いタスクを再開してはなりません。

プロバイダーのレポートを収集する前に、report-file-collection.mdを読み込みます。クリップボードではなく、利用可能なファイル／ダウンロードの経路を使います。スキーマ2の提出と過去データのインポートには、実際のモードの観測レシートが変更されずに保持されている必要があります。準備済みプロンプトには必要ありません。deferredルートは理由とともに表示したままにします。結果が不確かな場合、または過去のリクエストのカバレッジが不明な場合は、最終確認／登録時に明示的な--bounded-reasonが必要です。完全に完了したと主張せず、その理由を保持します。カタログ検索で返されるのは、現在登録されている詳細と記録済みのカバレッジであり、完全性の確認が完了した結果ではありません。調査アセットの契約に従います。

調査中は、編集していないプロバイダーの出力、開いた元資料すべて、およびプロバイダーから提示されたソースURLすべてを、ステータスと来歴とともに保持します。レポートの主張は、承認済みの元ソースに紐付けます。モデルのレポートは、根拠候補を見つけるためにのみ使用します。レポートを完成とする前に、provider_runs.py validate、research_assets.py checkを実行し、後から検索できるよう調査を登録します。引用はあっても、調査・ソース・主張の記録がない回答は、このスキルの要件を満たしません。ローカルスクリプトはファイルを記録・確認するものであり、プロバイダーへの呼び出しは行わず、有料作業を許可するものでもありません。 データプラグインを自ら選択する可能性がある Work／Agent タスクを送信する前に、該当するプラグインカタログを確認し、呼び出しごとのクレジットや料金を調べてください。サインイン済みのアカウントであることや、データソースを使うようリクエストしたことによって、無制限の支出上限が設定されるわけではありません。自律型タスクが従量課金制プラグインを呼び出す際に毎回一時停止できず、そのタスクについて明示的な支出承認もない場合は、その経路を保留するか、正確な呼び出し内容を事前に承認できる方法を利用してください。予算があっても、プロンプトは技術的な課金上限にはなりません。自律型タスクでそれを強制できない場合は、制御可能な方法を使ってください。追跡できるよう、承認された上限をプロバイダー向けプロンプトに記載し、実行後にツールの生ログを確認してください。上限を超えて課金された場合は、実際に確認された使用量を記録してユーザーに伝えてください。調査範囲の不足を埋めるために、追加の有料呼び出しを行わないでください。

モードの選択

開始前に調査モードを決定してください。

分類	選択肢
トピックモード	エンタープライズ調査（企業／法人）または一般調査（業界／政策／テクノロジー）
深度モード	標準（複数の意思決定上の問い、または見解が分かれる証拠）または軽量（範囲が限定された単一の問いで、証拠の対象範囲が小さい）
プロバイダーモード	明示的な単一路線、またはプロバイダー × モードの計画。ユーザーが指定した、またはプロジェクトで受け入れられたすべてのモードを、選択するか、理由を明示して保留してください。意思決定を実質的に検証できる場合は、独立した追加の経路を選択してください。

• エンタープライズ調査モード：意思決定への回答に役立つ場合に限り、分析フレームワークを選択して活用する、問い主導の企業調査
• 一般調査モード：ソース管理を伴う標準的な P0-P7 調査パイプライン
• 深度の選択：プロンプトの長さ、タスク数、目標文字数ではなく、未解決の問いの数とその重要性に基づいて選択してください。
• プロバイダーの選択：「いつものやり方」や名前付きの調査ルーチンが指定された場合は、ユーザーが確立したワークフローを確認してください。追加のモデルレポートは、独自の証拠経路、構造化されたツールアクセス、または有意義な異議をもたらす場合に有用です。各プロバイダーの利用可否、プライバシー境界、有料利用の承認を確認してください。要求されたモードの組み合わせを、直接情報源を使ったレポートへ黙って縮小してはいけません。利用可能なすべての経路を既定ですべて実行したり、ベンダー一覧をハードコードしたりしないでください。

ソース管理（V6）

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

各ソースをアクセシビリティに基づいて分類してください。

アクセシビリティ	定義	例	利用ルール
public	認証なしで、あらゆる外部の調査者が利用できる	公開ウェブサイト、ニュース記事、WHOIS（プライバシー保護なし）、学術論文	✅ 常に利用可能
semi-public	登録または限定的なアクセスが必要	LinkedIn のプロフィール、Crunchbase の基本プラン、業界レポート（無料プラン）	✅ 開示すれば利用可能
exclusive-user-provided	ユーザーの有料サブスクリプション、プライベート API、独自データベース	Crunchbase Pro、PitchBook、非公開データフィード、社内データベース	✅ 第三者調査に利用可能
authorized-first-party	ユーザー自身の組織、取引、業務に関する、ユーザーが使用を許可した記録	契約書、請求書、CRM 記録、会議の議事録	✅ 社内の事実を立証できる。情報の由来を明記すること

ファーストパーティの境界： ユーザーが使用を許可した記録は、組織が何を実施、合意、支払い、納品、または観察したかを立証するために使えます。ただし、市場での地位、顧客の評価、規制遵守、第三者の主張について、独立した外部検証とはみなされません。社内記録を外部の調査結果として表示してはいけません。

✅ 独占情報による優位性：次のことを行ってください。

• ユーザーの Crunchbase Pro を使って競合他社を調査する
• ユーザーの独自データベースを市場調査に利用する
• ユーザーのプライベート API を投資分析に利用する
• ユーザーが提供する独占的な情報源を、第三者調査に活用する

ソース種別ラベル

すべてのソースに、次のラベルも付与する必要があります。

ラベル	定義	例
official	一次ソース、公式ドキュメント	企業のSEC提出書類、政府報告書、公式ブログ
academic	査読済み研究	学術誌の記事、学会論文、学位論文
secondary-industry	専門的な分析	業界レポート、アナリストによる報道、業界誌
journalism	ニュース報道	信頼できる報道機関、調査報道
community	ユーザー生成コンテンツ	フォーラム、レビュー、ソーシャルメディア、Q&Aサイト
other	分類されていないソース、または複数種別が混在するソース	アグリゲーター、未検証のソース

カバレッジ診断： ソース数、ドメイン、ソース種別の構成、集中度を追跡し、カバレッジの薄い領域を明らかにします。これらの合計だけで調査の合否を判定してはいけません。各判断事項と結論を支える主張に、目的に適した証拠があるか、反証となる証拠を探したか、残っている不明点が明示されているかを基準に判定します。

AS_OF の日付ポリシー

P0 で AS_OF の日付を明示的に設定します。時間の経過により変わる可能性のある主張については、次のとおりです。

• すべての引用にソースの公開日を記載する
• ソースが該当する有効期間より古い場合は、確信度を下げる
• 主張の種別ごとに鮮度の有効期間を定義し、その期間を超える情報にフラグを付ける。すべてに適用する一律の経過期間の基準は、あくまで診断にのみ使用する

P0：環境とポリシーの設定

開始前に機能を確認します。

確認項目	要件	満たされない場合の影響
必要な証拠チャネルを利用できる	必須	対象範囲を狭めるか、該当する問いを不明として調査を中止する
一次ソースを取得できる	結論を支える主張には必須	要約やスニペットを最終的な証拠として扱わない
サブエージェントのディスパッチ	推奨	順次処理に切り替える
ファイルシステムへの書き込みが可能	完了に必須	メモリ内のメモを部分的な調査に利用してもよいが、アーカイブ上の不足を報告し、調査を未完了のままにする

ポリシー変数を設定します。

• AS_OF：今日の日付（YYYY-MM-DD）。時点に依存するトピックでは必須
• MODE：標準（デフォルト）または軽量。問いのマップに基づいて選択理由を示す
• SOURCE_TYPE_POLICY：official/academic/secondary/journalism/community/other のラベル付けを徹底する
• COUNTER_REVIEW_PLAN：暫定的な結論を覆す可能性のある証拠

プロバイダーモードを設定する前に、リサーチアセットのカタログを検索します。以前のモデルによる要約は手掛かりとして扱い、再利用する前に元のソースを開いて鮮度を確認します。

報告：[P0 complete] Subagent: {yes/no}. Mode: {standard/lightweight}. AS_OF: {YYYY-MM-DD}.

特定の企業を調査する場合は、専門ワークフローを使って、問いごとに証拠を振り分けます。6つの次元はカバレッジマップとして扱い、必須のレポート構成とはみなしません。

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

Enterprise Research Progress:
- [ ] E1: Intake — confirm company entity, research depth, format contract
- [ ] E2: Question-led evidence collection across relevant dimensions
  - [ ] D1: Company fundamentals (entity, founding, funding, ownership)
  - [ ] D2: Business & products (segments, products, revenue structure)
  - [ ] D3: Competitive position (industry rank, competitors, barriers)
  - [ ] D4: Financial & operations (3-year financials, efficiency metrics)
  - [ ] D5: Recent developments (6-month events, strategic signals)
  - [ ] D6: Internal/proprietary sources (or note limitation)
- [ ] E3: Optional analysis framework selected for the decision (or none)
- [ ] E4: Claim/evidence/unknown checks at each stage transition
- [ ] E5: Draft in the user's requested structure
- [ ] E6: Counter-review and verification (same as general P6–P7)
- [ ] E7: Present draft for human review and iterate

P1：調査タスクボード

既存の質問を引き継ぐ場合は、まず incremental follow-up に従って、裏付けのある結論、解決済みの質問、訂正事項、未解決の点、再開条件を復元します。 以前のレポートを実行担当者に渡すだけでは、この状態が引き継がれたことにはなりません。

調査ごとに、移植可能な provider-run contract を使用します。 1つの質問マップ、正確なプロンプト、およびプロバイダー×実際のモードごとの個別の lane_id を用意します。直接の一次資料ルートを使用する場合は、それも含めます。ディスパッチ前に provider_runs.py の plan を実行します。プロバイダー／モードのレーンを2つ以上選択した場合は、 ファンアウトの前に parallel-provider-ops.md を読み込み、独立したエージェントと連携して、 利用可能なプロバイダー、ブラウザー／アプリ、検索、検証の各スキルを調整します。 各操作サーフェスの担当者を1人に割り当て、その担当者のUI操作を直列化します。このスキル内に プロバイダー呼び出しを実装したり、ベンダー構成が固定されていると想定したりしないでください。 時間のかかる非同期ジョブは早めに送信し、各レーンの元の結果を個別に収集します。 重複する有料作業を始めるのではなく、既存の実行元からアクティブなタスクを再開します。実際にディスパッチする前に、 各レーンの現在の実行担当スキルを確認して読み込み、その認可ルールに従います。 ローカルのプランナーはプロバイダーを呼び出しません。プロバイダーのレポートはP3への入力であり、独立して検証された情報源ではありません。通常のチャットがネイティブのDeep Researchを使用したと、モデル名やレポートの長さから推測しないでください。実際のUIまたはAPIルートを確認します。モデルのレポートの多数決ではなく、基礎となる一次資料と意思決定上の価値に基づいて統合します。

割り当てを意思決定に関する質問に分解します。個別の証拠ルートや専門知識によって作業が明確になる場合にのみ、タスクを作成します。

各タスクの割り当てには、次の内容を含めます。

• 専門家の役割：専門家のペルソナ（例：「政策史家」「エコシステム調査者」）
• 目的：調査目標を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つを実行したり、定量化されたフレームワークを追加したりしないでください。

E1：インテーク

上記のP0/P1と同様に、以下も行います。

• 調査対象となる正確な法人を確認します（親会社か子会社か）
• 意思決定上の問い、エビデンスの難易度、求められる成果物に基づいて調査の深さを選択します。ページ数は計画上の診断材料にすぎません
• 特定の比較対象（ベンチマーク企業）があるか確認します

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には、以下を含める必要があります。

• 問いのステータス：回答済み／反証あり／不明、および調査を止める根拠
• ソースセクション：実際の取得で確認した安定した参照先。ソースの種類、アクセス可否、日付、ソースファミリーの識別情報を含めます
• 主張とエビデンスの表：主張、エビデンスの抜粋／参照先、対象範囲、確信度、原文を開いて確認したかどうか
• 反証エビデンスと不明点：何を探し、何が見つかり、何が未解決のままか

サブエージェントを使用しない場合（縮退モード）

リードエージェントが各専門担当者として順番にタスクを実行します。最終エビデンスパケットの外に検索時のノイズを保管し、再現性が重要な場合はクエリログを残します。

エンタープライズ調査：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を読み込みます。戦略的選択肢の整理にはSWOTを、確率と影響度を明示的に入力できる意思決定にはリスクマトリクスを使用します。スコアリングは、重みと尺度に妥当性がある場合に限ります。項目や精度を捏造するより、フレームワークを省略してください。

分析の完了後、L2品質チェックを実施します。

E4：品質管理

references/enterprise_quality_checklist.mdに従って、3段階のチェックを行います。

• L1（データ）：ソース数、帰属、相互検証、適時性
• L2（分析）：意思決定上の問いへの対応、主張の裏付け、反証エビデンス、フレームワークを使用する場合の適合性
• 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：ドラフト作成 — 選択した質問主導型の構成とユーザー指定のフォーマット要件に従います。エンタープライズテンプレートは適合する場合に限り使用します
• E6-E7：ドラフトレビューと検証 — P4〜P7のエビデンスチェックと、依頼された人によるレビューを適用します。追加のドラフト作成・レビューは、未解決の指摘事項に応じて実施します

---

P3：引用レジストリ＋ソースガバナンス

リードエージェントはすべてのタスクメモを読み、統合レジストリを作成します。

開いたすべてのソースと、プロバイダーから提示されたURLを、却下したものや利用できなかったものも含めて、調査の source-ledger.jsonl に追加します。入手可能な場合は、元のバイトデータも保存します。意思決定に影響する各主張とその正確な参照箇所を、承認済みのソースIDに claims.jsonl で紐付けます。research-asset-contract.md を参照してください。以下の番号付きレポート引用レジストリは、読者向けの対応表として使用するものであり、永続的なソース記録や主張記録に代わるものではありません。

レジストリの手順

1. 各タスクファイルの主張と根拠の表、およびソースをすべて確認します
2. ソースを統合します。URLを重複排除するとともに、同じ調査、提出書類、プレスリリース、データセット、インタビュー、またはスポンサーに由来する複数の刊行物を、1つのエビデンスファミリーとしてまとめます
3. 初出順に連番の [n] を割り当てます
4. source_type、accessibility、as_of date、evidence family、authority、independence limits、task id をタグ付けします
5. 主張カバレッジマトリクスを作成します。裏付けとなるエビデンス、反証するエビデンス、決定的な一次資料の確認状況、残る不明点を記録します
6. 除外したソースとその理由を記録します。恣意的なスコアを満たさないというだけでソースを除外してはいけません。そのソースが裏付けられる主張に用途を限定してください

レジストリの出力形式

CITATION REGISTRY

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

Dropped:
x Source | URL | Source-Type: secondary-industry | Accessibility: public | Evidence-Family: unknown | Reason: original record could not be retrieved; summary cannot carry the claim

Diagnostics: {approved}/{total}, {N} domains, {N} independent evidence families, source-type mix
Coverage: {answered}/{total questions}; {N} load-bearing claims unresolved

重要なルール： これらの [n] は最終版です。P5では承認済みリストのソースのみ引用できます。除外したソースを再び使ってはいけません。

許可されたファーストパーティ情報の取り扱い：ユーザー自身の組織や資産を調査する場合：

1. 内部の事業実態については、それを直接記録している許可済みの一次記録を使用します
2. authorized-first-party とラベル付けし、誰の記録であるかを明記します
3. 主張に外部からの裏付けが必要な場合に限り、外部ソースを探します
4. 結論を明確にします。内部で確認済み、外部から裏付け済み、矛盾あり、または外部情報では不明のいずれかを示します

限定ソースの取り扱い：ユーザーが、第三者に関する調査のために、自身の有料サブスクリプションや非公開APIの使用を明示的に提供した場合（例：「競合を調べるために私のCrunchbase Proを使ってください」）、次の対応を行うべきです：

1. アクセス区分を「exclusive-user-provided」として受け入れます
2. 競争上の優位性として活用します
3. レジストリに適切に引用します
4. 独立した同等の情報源がない場合は、そのソースが有効に裏付けられる範囲を維持し、外部の主張は不明とします

レポート：[P3 complete] {answered}/{total} questions answered. {N} load-bearing claims supported, {M} unresolved. Source totals are diagnostics.

情報のブラックボックスへの対処

公開情報がない企業・団体を調査する場合：

外部の調査担当者が確認できる情報：

• WHOIS：プライバシー保護により、所有者情報なし
• Web 検索：ニュースもプレスリリースもなし
• ソーシャルメディア：企業ページなし
• 企業登記簿：公開 API がない、または現地からのアクセスが必要
• 結果：情報が完全にブラックボックス化している

適切な対応：

Findings: NO PUBLIC INFORMATION AVAILABLE

Sources checked:
- WHOIS (public): Privacy protected [failed]
- Company registry (public): Access denied/No API [failed]
- News media: No coverage [failed]
- Corporate website: Placeholder only [minimal]

Verdict: UNABLE TO VERIFY COMPANY EXISTENCE from external perspective
Sources found: 0 (or minimal, e.g., only WHOIS showing domain exists)
Confidence: N/A - Insufficient evidence

してはいけないこと：

• ❌ 内部で確認された事実を、外部でも独立して裏付けられた事実として説明する
• ❌ ドメイン登録だけを根拠に、その企業が存在すると推測する
• ❌ 不足しているデータを推測で補う
• ❌ 社内の事実を直接立証する、承認済みの一次情報を破棄する

すべきこと：

• ✅ 外部の調査担当者が確認できること／できないことを明確に示す
• ✅ 承認済みの一次情報による事実を、外部から確認できる情報とは分けて、内部で確認された事実として報告する
• ✅ 失敗した検索をすべて記録する
• ✅ 主張に [unverified] を付けるか、完全に省く
• ✅ 証拠から判断に必要な問いに答えられない場合は、調査範囲を狭めるか、調査を打ち切る
• ✅ デューデリジェンスのために直接問い合わせることを推奨する

---

P4：証拠を対応付けたアウトライン

リードエージェントは証拠パケットとレジストリを読み、アウトラインを作成してから、重要な原資料を再度開きます。

1. タスクをまたぐパターンを特定する
2. タスクの順序ではなく、トピックを先にしてセクションを設計する
3. 各セクションを、出典番号付きの具体的な調査結果に対応付ける
4. 対立的な観点からのレビューが必要なセクションに印を付ける
5. 最新性に左右される主張に AS_OF チェックの印を付ける
6. 判断の根拠となるすべての主張に、裏付けあり／矛盾あり／不明のいずれかを明記する

アウトラインの形式：

## 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] を付ける
• 数値や割合には出典を付ける
• セクションごとに確信度マーカー（High／Medium／Low）とその根拠を付ける
• 証拠が食い違う場合は、反対の主張を述べる文を加える
• 新しい出典を追加する場合も、同じレジストリと検証の手順を通す
• 裏付けのない記述には [unverified] を使用する

ハルシネーション防止：

• リードエージェントは URL を決して捏造しません。すべてのロケーターは実際の取得結果から得る必要があります
• リードエージェントはメモを証拠として扱いません。判断の根拠となる主張、矛盾、正確な数値／日付、引用文については、原資料を再度開きます
• リードエージェントはデータを決して捏造しません。裏付けのない主張は不明のままにするか、省略します

ステータス：[P5 in progress] {N}/{M} セクション、約 {words} 語。

---

P6：対立的な観点からのレビュー（必須）

主な結論ごとに、反対の観点から確認します。これらの確認に別のエージェントやチームが自動的に必要となるわけではありません。ユーザーの依頼または該当するワークスペースの指示で求められる場合にのみ、独立したレビュアーを使用します。

1. 結論が誤っている可能性はありますか？
2. 多くのドメインで繰り返し述べられていても、単一の証拠群に依存している、影響の大きい主張はどれですか？
3. 事実を直接確認できる出典がない主張はどれですか？
4. 時間の経過に左右される主張に、古い出典を使用していませんか？
5. 証拠に裏付けられた問題のみを報告します。問題がゼロ件でも構いません。未解決の不確実性は明示してください。問題の件数を満たすために、問題を捏造したり、完了済みの確認を繰り返したりしてはいけません。

Counter-Review Team の使用（任意）

包括的な並行レビューには、Counter-Review Team を使用します。

# 1. Prepare inputs
counter-review-inputs/
  ├── draft_report.md
  ├── citation_registry.md
  ├── task-notes/
  └── p0_config.md

# 2. Dispatch to 4 specialist agents in parallel
SendMessage to: claim-validator
SendMessage to: source-diversity-checker
SendMessage to: recency-validator
SendMessage to: contradiction-finder

# 3. Wait for all specialists to complete

# 4. Send to coordinator for synthesis
SendMessage to: counter-review-coordinator
  inputs: [4 specialist reports]

# 5. Receive final P6 Counter-Review Report

詳しい使い方については、references/counter_review_team_guide.md を参照してください。

手動での対立的レビュー（デフォルト）

レビューチームを選択していない場合は、以下の証拠確認を直接行います。ユーザーの依頼または該当するワークスペースの指示で求められる場合は、個別に独立したレビューを依頼します。

• 判断の根拠となるすべての主張を、決定的な原資料と照合する
• 裏付けとなる出典が本当に独立していて、その主張を確認できるものかを確認する
• 時間の経過に左右される主張について AS_OF 日付を確認する
• 反対の解釈を記録する

出力

最終レポートには、証拠に裏付けられた論争のみを含めてください。そのような論争が存在する場合に限り、番号付きの項目を使用してください。確立された論争が存在しない場合は、その旨を明示してください。テンプレートを満たすためにプレースホルダーの論争を埋めてはいけません。未解決の不確実性は別途報告するか、何も残っていない旨を明示してください。

## 核心争议 / Key Controversies
未发现有证据支持的核心争议。
未解决的不确定性：无。

上記の例は、両方の記述が完了したチェックによって裏付けられている場合にのみ適用されます。そうでない場合は、実際の論争または未解決の疑問を列挙してください。

報告: [P6 complete] {N} issues found: {critical} critical, {high} high, {medium} medium.

---

P7: 検証

最終化の前にクロスチェックを行います:

1. レジストリのクロスチェック: レポート内のすべての [n] を、承認済みレジストリと照合して列挙する
2. 主要な結論のチェック: すべての決定的な結論、正確な数値・日付・引用、および争いのある事実を原典まで追跡する
3. 影響の小さい主張のサンプリング: 抜き取り検査は診断としてのみ使用し、1 件が失敗した場合は影響を受けるクラス全体に拡大する
4. 削除されたソースが復活していないことを検証する
5. 主要な主張について証拠ファミリーの集中度を確認する

報告: [P7 complete] {N} spot-checks, {M} violations fixed.

P7 の後に、調査の最終アセットチェックとカタログ登録を実行します。選択したレーンが依然としてアクティブであるか、ソースに有効な原典・ロケーターがない場合は、完成した Deep Research 実行として提示するのではなく、調査を未完了または限定的であると報告してください。

---

出力要件

• 要求された言語とトーンに合わせる
• 技術用語は英語のまま保持する
• レポート仕様とフォーマット規則に従う
• 参考文献セクションまたは文献目録を含める

参照ファイル

コア V6 パイプライン参照

ファイル	読み込むタイミング
source_accessibility_policy.md	P0 (CRITICAL): ソース分類規則 - 最初に読む
subagent_prompt.md	P2: サブエージェントへのタスクディスパッチ
research_notes_format.md	P2: サブエージェントの出力形式
report_template_v6.md	P5: 信頼度マーカーと反対レビューを含むドラフト
quality_gates.md	全フェーズ: 品質しきい値とハルシネーション対策チェック
research-asset-contract.md	毎回の呼び出し: 先行研究の探索、1 つ以上のレーン調査、ソース・主張の記録、最終チェックと登録

一般的な調査参照

ファイル	読み込むタイミング
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 章構成のレポートテンプレート

アンチパターン

• P6〜P7のエビデンス確認を行わずに、初稿を検証済みとして扱う
• 判断につながるエビデンスの不足がないのに、完全なドラフトを繰り返したり、並行して作業したりする
• 形式の契約やユーザーのテンプレートを無視する
• 引用やエビデンステーブルとの対応付けがない主張
• 相違点を明示せずに、矛盾する日付を混在させる
• 外部のAI出力を検証せずにコピーする
• 中間ドラフトや未加工の調査結果を削除する
• リードエージェントがメモを正式な根拠として信頼する — 経路の判断にはパケットを使い、決定的な原典はあらためて開いて確認する
• URLを捏造する — 実際の検索結果にあるURLだけを使用する
• 除外済みのソースを復活させる — P3で除外したソースを再び持ち出さない
• 時点依存の主張にAS_OFがない — 必ずソースの日付を含める
• エビデンス確認を省略する — P6を完了し、裏付けのある調査結果だけを報告する。問題が立証されていない場合は、問題なしとしてよい。
• 一次情報による過剰な主張 — 権限のある記録は社内の業務上の事実を裏付けることはできますが、外部による検証を装うことはできません
• 限定ソースを無視する — 競合調査でユーザーがCrunchbase Proなどを提供した場合は、必ず使用する

次のステップ：検証して納品する

条件付きの後続工程への引き継ぎ

ユーザーが引き継ぎを依頼した場合、または許可されたワークフローで調査を別の実行者に実際に移管する場合に限り、これを適用してください。受け手向けのプロンプトを作成する前に、リードエージェントは最新の依頼内容と承認済みの決定事項を確認します。プロンプトには、ユーザーの目標、現在の段階、許可された成果物、原典の参照先、次に実施する反証可能な調査を含めてください。観察事項、推奨事項、選択済みの制約、未検証の前提は、それぞれ分けて明記してください。実装可能なものや以前の提案は、その権限がない限り、選択済みの制約ではありません。たとえば、手法の調査を引き継ぐ場合、次の実行者にアプローチの比較を依頼することはできますが、既存のエンジンを実装したり、完成したスキルを納品したりするよう暗黙に指示してはいけません。

セッションまたはタスクコンテキストを引き継ぐ必要がある場合は、インストール済みカタログから現在のhandover Skillを解決し、引き継ぎアーティファクトと復旧手順の管理主体を維持してください。その管理主体を利用できない場合は、その不足を報告し、復旧手順を実行したと主張することなく、上記の範囲に限定した調査コンテキストを提供してください。これは実装や公開を許可するものではありません。リードエージェントは原典に照らして段階と権限を判断し、ローカルのアセット検証ツールは記録の完全性を確認します。受け手向けプロンプトがこれらの境界を守っているかどうかは確認しません。

調査が完了したら、検証と出力を提案します。

Research report complete: [N] sources cited, [M] claims made.

Options:
A) Verify facts — run /fact-checker on the report (Recommended)
B) Create slides — pass the verified findings and citation registry to the active presentation workflow
C) Export as PDF — run /daymade-docs:pdf-creator for formal delivery
D) No thanks — the report is ready as-is