ted0321 企業ディープダイブ・レポート
企業を要約せず、意思決定を左右する因果構造を解明する。すべての重要主張を証拠へ接続し、事実・推論・仮説・不明を分離する。
必要な参照ファイルを読む
- 分析開始時に
references/analysis-routing.mdを読み、企業タイプと分析ルートを決める。 - 情報収集前に
references/evidence-contract.mdを読み、証拠台帳と主張の基準を固定する。 - 成果物設計時に
references/report-architecture.mdを読み、ページ構成とビジュアル規則を決める。 assets/のテンプレートを実行フォルダへコピーして使う。テンプレート自体は編集しない。- 完成形のデータ構造を確認したい場合は
examples/sample_run/を参照する。架空企業のため、分析内容を実在企業へ流用しない。
1. 分析条件を固定する
- 対象企業を法人名、国、公式URL、ティッカー等で特定し、同名企業を区別する。
- 次の項目を1ページの分析ブリーフにする。
- 読者と意思決定
- 中心問い
- 対象期間と地域
- 比較対象
- 希望する成果物形式
- 軽微な不足は次の既定値で補い、冒頭に明記する。
- 読者: 経営・事業戦略担当
- 中心問い: この企業の価値を生む構造は何か。その構造は今後1〜3年で強まるか。
- 成果物: 12ページ相当のMarkdownレポート、証拠台帳、主張グラフ
- 有料情報、認証が必要な情報、個人情報、規約に抵触し得る収集方法を使う前に確認を取る。
- 既定では
company-deep-dive/<company-slug>/<YYYY-MM-DD>/を実行フォルダにする。
2. 企業を分類して調査ルートを選ぶ
- 上場・非上場、単一事業・複合企業、成長・成熟、情報量を分類する。
- SaaS、Marketplace、製造業、消費財・小売、金融、メディア、インフラ、専門サービスのうち、主たる事業型を選ぶ。
- 分類結果に応じてKPI、一次情報、競争単位、リスク項目を切り替える。
- 分類根拠と不確実性を
analysis_brief.yamlに残す。 - 汎用フレームワークを先に当てはめない。企業固有の価値創出メカニズムを先に仮説化する。
3. 仮説と証拠スロットを設計する
- 最終判断を左右する仮説を3〜5個に絞る。
- 各仮説について次を定義する。
- 支持された場合の意味
- 反証された場合の意味
- 必要な証拠
- 先行指標と遅行指標
- 反証条件
- レポート各ページを、埋めるべき証拠スロットへ変換する。
- 支持証拠だけでなく、反証、矛盾、欠測、事業撤退や指標定義変更も検索対象にする。
4. 証拠を収集して台帳化する
- 変化し得る企業情報には、その時点で利用可能なWeb、接続済みデータ、企業開示資料を使う。
- 会社開示、規制当局、統計、特許、裁判・行政資料などの一次情報を優先する。
- ニュース、業界資料、レビュー、SNSは補助信号として扱い、単独で業績や市場規模を断定しない。
- 各証拠に
E001形式のIDを付け、evidence_ledger.csvに記録する。 - 数値には単位、期間、地域、定義、出典を必ず付ける。
- 取得できない情報は推測で埋めず、
UNKNOWNとして必要な追加調査を残す。
5. 企業の因果モデルを組み立てる
次の順で分析する。
- 顧客、提供価値、課金、供給、チャネルを結ぶビジネスモデル図を作る。
- 売上から利益・キャッシュまでを企業固有のKPIドライバーツリーに分解する。
- セグメント、地域、顧客群ごとの経済性と資源配分を比較する。
- 競争優位を「資産や能力 → 顧客行動 → 経済効果」の因果で示す。
- 成長ドライバーごとに、余地、実行能力、証拠、制約を評価する。
- 各主張を
C001形式でclaim_graph.jsonに登録し、証拠IDと接続する。
単なるSWOT、3C、PESTの列挙で終えない。各図に「だから業績・競争・意思決定に何が起きるか」を書く。
6. Evidence Courtを通す
- 転載・同一発表由来の情報を独立した複数ソースとして数えない。
- 各主張を
FACT、INFERENCE、HYPOTHESIS、UNKNOWNに分類する。 - 重要主張ごとに反証証拠、代替説明、反証条件を確認する。
- 矛盾する情報を無理に統合せず、
CONTRADICTIONとして両論を残す。 - 確度を
HIGH、MEDIUM、LOWで示し、理由を1文で書く。 - Tier 1の重要主張は、原則として独立した証拠2件以上、そのうち一次情報1件以上を要求する。
条件を満たせない場合は断定を弱め、部分レポートとして不足証拠を明示する。
7. 将来シナリオを作る
- Bull、Base、Bearの3シナリオを、物語ではなく因果の変化として定義する。
- 各シナリオに次を付ける。
- 発生条件
- KPIへの伝播経路
- 先行指標
- 反証条件
- 戦略的含意
- 直近で監視すべき5〜10個の指標をStrategic Watchlistにする。
- 予測値を置く場合は、前提、計算式、範囲、出典を示す。
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 が使えない場合は、同じ検査項目を手作業で確認し、未実行であることを伝える。