dossier

Dossier — 意思決定に役立つエンティティ調査

ポータビリティ： WebSearch + WebFetch、docx パッケージを含む Node.js が必要です。無料 API（SEC EDGAR、GitHub、ProPublica）を利用する場合は、任意で bash_tool + curl も必要です。BYOK MCP（LinkedIn、Crunchbase、Apollo、Pitchbook、SimilarWeb）は任意の拡張機能です。Claude Code CLI でネイティブに動作します。

一般論にとどまらない切り口 — 差別化要因

このスキルは、仮説検証を伴う、意思決定に役立つエンティティ調査です。「Microsoftについて教えて」のような依頼には応じません。実行のたびに、ユーザーに仮説を最初に明示してもらうための質問（Q4）を行い、その仮説を追認するのではなく、検証する資料を作成します。

ユースケースの例：

「火曜日にMicrosoftへ提案する予定です。AI関連支出を自社のFoundryプラットフォームに集約している、という仮説があります。これを検証または反証し、調査結果に基づく会話のきっかけを3つ挙げてください。」

違う例：

「Microsoftについて教えてください。」

仮説を尋ねるQ4こそが、一般論にとどまらないための軸です。これを省くと、このスキルはWikipediaのような要約を作成します。

原則については、references/hypothesis_testing_discipline.md を参照してください。

エージェントの完全性に関するルール（Research-Pack の慣例）

PR #657 の監査に従い、一字一句変更せず固定しています。

• 実行規律。 検索呼び出しは順番に行います。WebSearch + WebFetch は Consensus よりもレート制限が緩いものの、1秒あたり1回の呼び出しを守ってください。次の呼び出しに進む前に、応答を受信したことを確認します。
• 情報源の規律。 このセッションのツール呼び出しで返された情報源のみを引用します。Wikipedia や学習データ由来の知識は [Background — verify before quoting] と表示し、主な調査結果の件数には含めません。
• 3種類の件数を記録。 送信したクエリ数／受信した情報源数／引用した情報源数。さらに、Dossier 固有のティア別内訳（一次／二次／三次）も記録します。これらは監査ログに表示します。
• 再試行ポリシー。 失敗した場合は3秒待ってから1回だけ再試行し、ログに記録します。3回連続で失敗した場合は、処理を停止してユーザーに通知します。
• 情報源の信頼性ティア。 引用には、一次（公式情報、SEC、裁判記録）／二次（大手報道機関、業界紙）／三次（ブログ、フォーラム）のいずれかを付与します。DOCX では、すべての注記にティアを表示します。

フェーズ1：質問によるヒアリング（回答を促す6つの質問を1つずつ行う）

Q1（起点）— 対象の特定

調査対象は誰ですか？正確な名前を教えてください。企業の場合は、ウェブサイトまたは LinkedIn の URL も教えてください。人物の場合は、LinkedIn の URL または一意に特定できる情報（所属企業と役職）を教えてください。

質問の理由： 対象の曖昧さをなくすためです。John Smith は47人います。「Atlas」という社名の企業も3社あります。具体的な調査対象を特定する必要があります。

名前しか提示されない場合は、2つ目の識別情報を尋ねます。名前が曖昧なままでは、調査を進めません。

Q2（Q1に依存）— 対象の種類

対象はどのような種類ですか？次から1つ選んでください：人物／企業／非営利団体／政府機関／その他。

質問の理由： 対象の種類によって、適用する情報源の組み合わせが異なります。人物の場合は LinkedIn、GitHub、Scholar、ニュースを確認します。企業の場合は、上場企業であれば SEC EDGAR、Crunchbase、ニュースを確認し、テクノロジー企業については GitHub も確認します。非営利団体の場合は、ProPublica で Form 990 を確認します。

選択を必須とします。「その他」の場合は、1行で説明してください。

Q3（Q2に依存）— 目的

何に向けた準備ですか？次から1つ選んでください：

1. 営業面談／パートナーシップ提案
2. 投資デューデリジェンス
3. 買収デューデリジェンス
4. ジャーナリズム／デューデリジェンス
5. 就職面接の準備
6. 競合情報の収集
7. 個人的な見極め（デート、採用、ビジネスパートナー）
8. その他（具体的に記入）

質問の理由： 目的によって、調査の視点、深さ、危険信号への感度が決まります。営業の準備には会話のきっかけが必要です。投資デューデリジェンスには事業の勢いや成長を示す兆候が必要です。個人的な見極めでは、センシティブな情報を扱う範囲に注意が必要です。

Q4（Q3に依存）— 仮説 — 必須

調査を始めるにあたり、どのような仮説をお持ちですか？このテーマについて、すでに信じていることは何ですか？また、何を検証または反証したいですか？

質問する理由： これは最も重要な質問です。すでに考えていることをただ裏付けるだけの調査資料には、価値がありません。最初に仮説を示していただければ、それを裏付ける証拠だけでなく、反証する証拠も探し、実際の判断に役立つ結論を提示できます。

例：

• 「Microsoft は AI 支出を自社の Foundry に集約していると考えています。検証または反証してください。」
• 「CEO は実力不足だと思います。TAM の話ばかりで、実績がありません。確かめてください。」
• 「この非営利団体の間接費率は不自然だと思います。990 を確認してください。」
• 「この人物には CTO の役割を担えるだけの技術力があると思います。検証してください。」

必須です。 ユーザーが「仮説はありません」と答えた場合は、一度だけ再考を促してください。「では、推測してみてください。後から更新できる立場を選んでください。検証すべき仮説がなければ、調査資料は一般的な人物紹介にすぎず、判断の助けになりません。」

それでも拒否された場合は、暗黙の仮説「見つけられる最も意外な事実は何か？」に切り替え、監査ログにフォールバックしたことを記録してください。

この質問は、一般論に終わらないための要です。省略すると、このスキルは Wikipedia の要約になってしまいます。

Q5（Q3に依存）— 深さ

調査にかける時間は、5 分の概要と 15 分の意思決定向け調査資料のどちらにしますか？

質問する理由： 概要モードでは検索は約 10 回までとし、ネットワークと評判の調査を省略します。意思決定向けの調査では、すべての項目をより深く掘り下げます。この判断がご自身にとってどれほど重要かに応じて選んでください。

選択を必須とします。

Q6（Q3 ∈ {journalism, personal vetting} の場合のみ質問）— 配慮事項

除外してほしいセンシティブな情報はありますか？たとえば、個人の医療情報、家族に関する詳細、政治的経歴、または扱わないでほしい特定の話題などです。

質問する理由： 調査の種類によっては、倫理上の制約があります。共有するつもりのない情報を提示してしまうより、事前に把握しておきたいです。

営業／投資／買収／競合情報の場合は省略します（配慮の必要性が低いため）。ジャーナリズム／個人の身元確認の場合は質問します（配慮の必要性が高いため）。

停止条件： Q6 の後（または依存関係による質問の省略でそれより前）に、必要な情報の確認を終え、フェーズ 2 を開始します。フェーズ 2 の開始後に、インテークを再開してはいけません。

フェーズ 2：対象の特定

フェーズ 3 の前に、対象を特定の実体に絞り込みます。

• 人物：LinkedIn URL、または（勤務先＋役職＋都市）を確認
• 企業：ドメイン、または（登記上の名称＋設立管轄）を確認
• 非営利団体：EIN、または（登記上の名称＋州）を確認
• 政府機関：公式の .gov URL を確認

Q1 で一度再確認を求めた後も曖昧な場合は、中断して、対象を識別できる情報を添えて Q1 を再度質問してください。先に進むことはできません。

フェーズ 3：情報源マトリックスの選択

Q2 の対象種別に基づいて振り分けます。標準的な情報源の一覧は、references/subject_type_source_matrix.md を参照してください。

人物

• LinkedIn（手動で取得、または BYOK の場合は LinkedIn MCP）
• 個人のウェブサイト
• Twitter/X（レート制限あり。利用できない場合は適切に対応）
• GitHub（技術分野の対象の場合）
• Google Scholar（研究者の場合）
• ニュース（WebSearch + WebFetch）
• カンファレンスの講演録、ポッドキャスト（WebSearch）

企業

• 公式ウェブサイト（会社概要、経営陣、ニュース、採用情報）
• SEC EDGAR（無料 API。上場企業の 10-K、10-Q、8-K）
• Crunchbase の無料プラン（または BYOK の場合は Crunchbase MCP）
• ニュース（WebSearch + WebFetch）
• GitHub（テクノロジー企業の場合）
• Glassdoor + Comparably（評判。スクレイピングがブロックされた場合は適切に対応）
• LinkedIn の企業ページ

非営利団体

• ProPublica Nonprofit Explorer（無料。Form 990）
• 公式ウェブサイト
• ニュース
• GuideStar（アクセス可能な場合）

政府機関

• 公式の .gov サイト
• ニュース
• ProPublica（連邦機関の場合）

有料 MCP（Apollo、Pitchbook、SimilarWeb）が接続されている場合は使用します。ただし、調査結果は監査ログに BYOK による情報源として記録してください。

フェーズ 4：仮説主導型検索

フェーズ 4 の検索はすべて、次のいずれかに分類する必要があります。

• 仮説を支持する証拠（仮説を裏付ける）、または
• 仮説を反証する証拠（仮説を覆す可能性がある）

検索予算の30％以上を、仮説を反証するクエリに割り当てます。 scripts/disconfirming_evidence_balance.py によって強制されます。

仮説「Microsoft は AI 支出を Foundry に集約している」の例：

• 支持する証拠： 「Microsoft Foundry adoption 2026」、「Microsoft AI infrastructure consolidation」
• 反証する証拠： 「Microsoft OpenAI deal renegotiation」、「Microsoft AI vendor diversification」、「Microsoft third-party model partnerships 2026」

これにより、調査資料は確証バイアスに陥らず、意思決定に活用できるものになります。

検索ごとに：

• citation_tracker.py を使って、分類（支持／反証）とともに記録します
• 各結果の URL に source_tier_classifier.py でソース階層を適用します

フェーズ 5：過去12か月の活動タイムライン

活動タイムラインの期間はデフォルトで過去12か月とし、基礎となるアイデンティティについてはさらに遡ります。

カテゴリ：

• ニュース（買収、採用、退職、製品の発表）
• 資金調達ラウンド／財務イベント
• 論争／法的イベント
• 公的な発言／戦略の転換

新しい順に並べます。各項目にハイパーリンクと階層を付けます。

フェーズ 6：ネットワークと評判のシグナル

ネットワーク

• 企業： 投資家（出資先／投資元）、顧客（社名が判明しているもの）、パートナー
• 人物： 共同創業者、アドバイザー、メンター、勤務先、取締役としての役職
• 非営利団体： 資金提供者、理事会、リーダーシップ

仮説との関連性に基づいて順位付けした5～10件を記載します。

評判

• ニュースにおける評判（直近12か月）
• 企業の Glassdoor 情報（総合評価と代表的なレビュー3件）
• 人物に関する同業者からの言及
• 注意事項：評判データにはノイズが多いため、それに応じて階層を付けます

フェーズ 7：危険信号の確認

センセーショナルに扱わず、明らかにします。

• 訴訟（裁判記録 → 一次資料の階層）
• 規制措置（SEC、DOJ、当局による措置 → 一次資料）
• 異例の退職（90日以内の主要人材の退職）
• 財務シグナル（10-K における継続企業に関する注記 → 一次資料）
• 評判への打撃（継続的な否定的報道 → 二次資料）

各危険信号に階層を付けます。 DOCX では、各危険信号の横に階層が表示されます。

フェーズ 8：会話のきっかけの作成

一般論ではなく、実際の調査結果に結び付いた具体的なきっかけを3～5件作成します。

基準については、references/conversation_hook_quality.md を参照してください。

❌ 一般的	✅ 調査結果に基づく
「ロードマップについて尋ねる」	「最近の [X] の買収に触れる――これは、同社が Y の垂直市場に投資していることを示しています。会話の例：「[X] の発表を拝見しました。Y に関するロードマップはどう変わりますか？」」
「採用について尋ねる」	「同社のエンジニアリング担当 VP が3週間前に退職しました（LinkedIn）。会話の例：「[name] さんが退職されたことに気付きました。エンジニアリング部門のリーダーシップ体制はどうなりますか？」」
「企業理念について話す」	「先週、同社は料金ページを更新しました（同社の公式サイト）。会話の例：「料金体系が更新されているのを拝見しました。変更の背景を教えていただけますか？」」

各きっかけには次を含めます。

• きっかけ（1文）
• 関連する調査結果（ハイパーリンクと階層を付記）
• 会話の例（ユーザーが応用できる、そのまま使える表現）

フェーズ 9：DOCX の生成（9 セクション）

Node.js と docx ライブラリを使用します。

1. エグゼクティブサマリー — 1 段落で、対象者が誰か、なぜ重要なのか、仮説に対する判定（SUPPORTED / PARTIALLY SUPPORTED / DISPROVEN / INCONCLUSIVE）、知っておくべきこと 3 点を箇条書きで記載します。
2. 基本情報テーブル — 設立／出生、所在地、規模／段階、現在の役職、主な所属先を記載します。すべてのセルに出典を付け、ホバーテキストで情報源のティアを表示します。
3. 仮説の検証 — ユーザーの仮説をそのまま記載します。裏付けとなる証拠（ハイパーリンク付き引用を 3～5 件、箇条書きで記載）。反証となる証拠（ハイパーリンク付き引用を 3～5 件、箇条書きで記載）。判定の段落（証拠の重みを説明する 2～3 文）。
4. 過去 12 か月の活動タイムライン — ニュース、資金調達、採用、退職、製品発表、論争を記載します。新しいものから順に並べ、各項目にハイパーリンクを付けます。
5. ネットワークの兆候 — 協業者／投資家／関係者を、仮説との関連性が高い順に 5～10 件記載します。
6. 評判の兆候 — ニュースでの評判、企業の場合は Glassdoor、人物の場合は同業者による言及を記載します。評判データにはノイズが多いことを注記します。
7. 危険信号と隠れたパターン — 訴訟、規制措置、異例の退職、財務上の兆候、評判への悪影響を、ティア別に記載します。
8. 会話のきっかけ — 調査結果に結び付いた具体的なきっかけを 3～5 件記載します。それぞれに、きっかけ、調査結果、提案する切り出し方を含めます。
9. 出典情報と監査ログ — 出典ごとにティアを付けて一覧表示します。検索サマリーテーブル（#、クエリ、分類、返された出典、引用した出典）を記載します。3 種類の件数とティア別の件数を記載します。失敗した検索も記載します。BYOK-MCP の使用フラグを記載します。

スタイル

本文は Arial 12pt、見出しはネイビー（#1a3a5c）、テーブルヘッダーはライトブルー（#e8f0f8）、危険信号のコールアウトは赤、会話のきっかけのコールアウトは緑にします。

ハイパーリンクの形式

new ExternalHyperlink({
  link: "https://...",
  children: [new TextRun({ text: title, style: "Hyperlink" })],
});

フェーズ 10：納品

• 保存先：<output-dir>/dossier_<entity-slug>_<YYYY-MM-DD>.docx
• チャットでのサマリー：ファイルパス + 仮説に対する判定 + 監査件数 + ティア別の内訳 + 使用した BYOK MCP（該当する場合）
• 検証：python3 -c "import zipfile,sys; zipfile.ZipFile(sys.argv[1]).testzip()" <docx> を使用して ZIP の整合性を確認します（出力がなければ正常）。その後、必須セクションが含まれていることを確認します。

ツール

スクリプト	役割
scripts/citation_tracker.py	~/.dossier_sessions/<session>.json における 3 種類の件数監査 + 裏付け／反証の分類 + 出典ティアのタグ付け
scripts/disconfirming_evidence_balance.py	検索予算の 30% 以上が反証クエリに割り当てられていることを検証します。偏りがある場合は警告します。
scripts/source_tier_classifier.py	ドメインのヒューリスティクスに基づき、URL を一次／二次／三次に分類します。

参考資料

• references/hypothesis_testing_discipline.md — 30% 以上のルール + 判定に適した情報と百科事典的な情報（7 件以上の出典）
• references/subject_type_source_matrix.md — 人物／企業／非営利団体／政府機関の出典マトリックス（7 件以上の出典）
• references/conversation_hook_quality.md — 調査結果に結び付いた会話のきっかけに関する指針（7 件以上の出典）

エラー処理

エラー	動作
対象者の名前が曖昧	続行を拒否します。識別情報を追加して Q1 に再回答するよう求めます。
ユーザーが仮説の提示を拒否	1 回だけ再考を促します。それでも拒否された場合は、「見つけられたら最も驚くことは何ですか？」を暗黙の仮説として使用します。監査ログに記録します。
対象者に公開情報がまったくない	その旨を明示します。別の名前または調査初期段階の対象を提案します。情報を捏造しません。
LinkedIn のスクレイピングがブロックされた	監査ログに記録します。WebSearch に切り替え、ユーザーに手動で確認するよう提案します。
SEC EDGAR の取得に失敗	1 回再試行します。それでも失敗した場合は「公開提出書類を取得できませんでした」と記録して続行します。
感情分析データが乏しい	評判セクションに「公開情報の兆候は限定的」と記載します。学習データから推測しません。
機微なトピックが見つかった（Q6 の除外対象）	DOCX から除外します。除外に従ったことがユーザーに伝わるよう、チャットには記載します（DOCX には記載しません）。
ツールが 3 回連続で失敗	停止し、ユーザーに通知して、ここまでに収集した情報を共有します。
DOCX の生成に失敗	生データを JSON のフォールバックとして保存します。

拒否すべきアンチパターン

• Q4 仮説を必須にせずに人物調査書を作成する
• 検索予算の <30% しか反証となる証拠に割り当てない
• 受付時の質問をまとめて行う
• 曖昧な対象者名を受け入れる
• 汎用的な会話のきっかけ（「相手のロードマップについて聞く」など）
• 危険信号を扇情的に扱う（論評を加えず、段階分けする）
• 危険信号に関する情報源の信頼性レベルを省略する
• LinkedIn またはスクレイピングがブロックされた場合に、網羅できたと捏造する
• 監査ログに記録せずに BYOK-MCP のデータを使用する
• Q6 でユーザーが除外したセンシティブなトピックを含める
• 確証バイアスに基づく結論（反証となる証拠を検討せずに「SUPPORTED」とする）

---

バージョン： 1.0.0 ソース仕様： megaprompts/12-dossier-megaprompt.md（メンテナーのローカルドラフト仕様。gitignore 対象のため、公開リポジトリには含まれていません） ビルドパターン： パス B（直接変換）。リサーチパックの姉妹版で、仮説検証を行うバリアントです。