企業ディープダイブ・レポート

企業を要約せず、意思決定を左右する因果構造を解明する。すべての重要主張を証拠へ接続し、事実・推論・仮説・不明を分離する。

必要な参照ファイルを読む

• 分析開始時に references/analysis-routing.md を読み、企業タイプと分析ルートを決める。
• 情報収集前に references/evidence-contract.md を読み、証拠台帳と主張の基準を固定する。
• 成果物設計時に references/report-architecture.md を読み、ページ構成とビジュアル規則を決める。
• assets/ のテンプレートを実行フォルダへコピーして使う。テンプレート自体は編集しない。
• 完成形のデータ構造を確認したい場合は examples/sample_run/ を参照する。架空企業のため、分析内容を実在企業へ流用しない。

1. 分析条件を固定する

1. 対象企業を法人名、国、公式URL、ティッカー等で特定し、同名企業を区別する。
2. 次の項目を1ページの分析ブリーフにする。
   • 読者と意思決定
   • 中心問い
   • 対象期間と地域
   • 比較対象
   • 希望する成果物形式
3. 軽微な不足は次の既定値で補い、冒頭に明記する。
   • 読者: 経営・事業戦略担当
   • 中心問い: この企業の価値を生む構造は何か。その構造は今後1〜3年で強まるか。
   • 成果物: 12ページ相当のMarkdownレポート、証拠台帳、主張グラフ
4. 有料情報、認証が必要な情報、個人情報、規約に抵触し得る収集方法を使う前に確認を取る。
5. 既定では company-deep-dive/<company-slug>/<YYYY-MM-DD>/ を実行フォルダにする。

2. 企業を分類して調査ルートを選ぶ

1. 上場・非上場、単一事業・複合企業、成長・成熟、情報量を分類する。
2. SaaS、Marketplace、製造業、消費財・小売、金融、メディア、インフラ、専門サービスのうち、主たる事業型を選ぶ。
3. 分類結果に応じてKPI、一次情報、競争単位、リスク項目を切り替える。
4. 分類根拠と不確実性を analysis_brief.yaml に残す。
5. 汎用フレームワークを先に当てはめない。企業固有の価値創出メカニズムを先に仮説化する。

3. 仮説と証拠スロットを設計する

1. 最終判断を左右する仮説を3〜5個に絞る。
2. 各仮説について次を定義する。
   • 支持された場合の意味
   • 反証された場合の意味
   • 必要な証拠
   • 先行指標と遅行指標
   • 反証条件
3. レポート各ページを、埋めるべき証拠スロットへ変換する。
4. 支持証拠だけでなく、反証、矛盾、欠測、事業撤退や指標定義変更も検索対象にする。

4. 証拠を収集して台帳化する

1. 変化し得る企業情報には、その時点で利用可能なWeb、接続済みデータ、企業開示資料を使う。
2. 会社開示、規制当局、統計、特許、裁判・行政資料などの一次情報を優先する。
3. ニュース、業界資料、レビュー、SNSは補助信号として扱い、単独で業績や市場規模を断定しない。
4. 各証拠に E001 形式のIDを付け、evidence_ledger.csv に記録する。
5. 数値には単位、期間、地域、定義、出典を必ず付ける。
6. 取得できない情報は推測で埋めず、UNKNOWN として必要な追加調査を残す。

5. 企業の因果モデルを組み立てる

次の順で分析する。

1. 顧客、提供価値、課金、供給、チャネルを結ぶビジネスモデル図を作る。
2. 売上から利益・キャッシュまでを企業固有のKPIドライバーツリーに分解する。
3. セグメント、地域、顧客群ごとの経済性と資源配分を比較する。
4. 競争優位を「資産や能力 → 顧客行動 → 経済効果」の因果で示す。
5. 成長ドライバーごとに、余地、実行能力、証拠、制約を評価する。
6. 各主張を C001 形式で claim_graph.json に登録し、証拠IDと接続する。

単なるSWOT、3C、PESTの列挙で終えない。各図に「だから業績・競争・意思決定に何が起きるか」を書く。

6. Evidence Courtを通す

1. 転載・同一発表由来の情報を独立した複数ソースとして数えない。
2. 各主張を FACT、INFERENCE、HYPOTHESIS、UNKNOWN に分類する。
3. 重要主張ごとに反証証拠、代替説明、反証条件を確認する。
4. 矛盾する情報を無理に統合せず、CONTRADICTION として両論を残す。
5. 確度を HIGH、MEDIUM、LOW で示し、理由を1文で書く。
6. Tier 1の重要主張は、原則として独立した証拠2件以上、そのうち一次情報1件以上を要求する。

条件を満たせない場合は断定を弱め、部分レポートとして不足証拠を明示する。

7. 将来シナリオを作る

1. Bull、Base、Bearの3シナリオを、物語ではなく因果の変化として定義する。
2. 各シナリオに次を付ける。
   • 発生条件
   • KPIへの伝播経路
   • 先行指標
   • 反証条件
   • 戦略的含意
3. 直近で監視すべき5〜10個の指標をStrategic Watchlistにする。
4. 予測値を置く場合は、前提、計算式、範囲、出典を示す。

8. 成果物を生成する

最低限、次を作る。

• company_dossier.md: 12ページ相当の企業レポート
• evidence_ledger.csv: 証拠台帳
• claim_graph.json: 主張と証拠の接続
• analysis_brief.yaml: 分析条件と分類結果

スライド、Word、PDFの作成手段が利用できる場合は、同じ主張IDと証拠IDを維持したまま編集可能な成果物を追加する。資料は必ずレンダリングして視覚確認する。

9. 完了条件を検査する

次をすべて満たすまで完成としない。

• Executive Thesisが中心問いへ直接答えている。
• ビジネスモデル図とKPIツリーが対象企業固有になっている。
• 重要主張が証拠IDへ追跡できる。
• 数値の単位、期間、地域、定義が欠けていない。
• 事実、推論、仮説、不明が見分けられる。
• 支持証拠だけでなく反証と矛盾を扱っている。
• 3シナリオに判定用の先行指標がある。
• レポート各ページの主メッセージが1つに絞られている。

最後に次を実行し、エラーを修正する。

python <skill-directory>/scripts/validate_run.py <run-directory>

実行環境で python が使えない場合は、同じ検査項目を手作業で確認し、未実行であることを伝える。