القائمة
APOLLO特許分析プラットフォームのCAPCOMセッションデータを 解釈し、戦略レポートを生成するための辞書・業務マニュアル。 output/session_* フォルダ内のデータファイルを読み取る際に参照。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/shibayamalicht/apollo-patent-analysis --skill apollo-capcom-skillsيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | APOLLO CAPCOM Skills |
| description | APOLLO特許分析プラットフォームのCAPCOMセッションデータを 解釈し、戦略レポートを生成するための辞書・業務マニュアル。 output/session_* フォルダ内のデータファイルを読み取る際に参照。 |
このファイルは要約版。各フェーズの開始前に指定されたリファレンスファイルを必ず読むこと。
以下は他の全ルール(トークン効率制約含む)に優先する。例外なく適用する。
全ゲートは省略不可: 「ユーザーが短く指示した」「効率上スキップしたい」等の理由でゲートを省略してはならない
ユーザー応答待ち必須: 「ユーザーに確認」「報告して」と書かれた箇所では、AskUserQuestion ツールでユーザー応答を取得するまで次フェーズへ進まない。テキスト出力だけで満足してはならない
不合格時は強制ループ: Phase 完了条件を満たさない場合、必ず該当 Phase に戻る。「実質的にOK」「内容は保持」等の質的判断で量的基準(行数・件数)を上書きしない
指示の長さで手順を変えない: ユーザー指示が「レポートを書いて」のように短くても、本 SKILL.md の全手順に従う。短い指示は「省略OK」のサインではなく「SKILL.md 通りに」のサイン
「省略します」と宣言する前に立ち止まる: 何かを省略する判断をした瞬間、AskUserQuestion でユーザーに省略の可否を確認する
水増し・反復・すり抜けリライトの禁止: 「最低◯◯行/◯件」は深さの目安であり、合否は内容の固有性＋非空白文字数（wc -l の行数ではない）で決まる。禁止: ①同一文・定型文の反復、および本母集団を見なくても言える自明な一般論での字数稼ぎ ②本文（deep_dive.typ・report.typ）の Python 等によるテンプレート生成・つなぎ文 ③ゲート回避目的で接続詞・語順・文体だけ変えて重複を温存するリライト（正しい対処は重複削除と固有内容への置換）④1文ずつ改行して行数を稼ぐこと ⑤工程ナレーション節・他章への前向き申し送り（章間連携は『クロスモジュール統合分析』章で。他章言及は過去形の根拠引用に限る）。行数不足時は新しい代表特許・数値根拠・クロスパターン・Web裏付けを足し、各段落に本母集団固有の事実（数値・公開番号・クラスタ名・出願人名のいずれか）を最低1つ含める。正本: analysis/deep_dive_guide.md「記述品質の絶対基準」（phase_d_gate.sh Check 19/19a/8e で自動 FAIL）
STOP-GATE はコンテキスト限界でも死守（捏造・先送り厳禁）: STOP-GATE（AskUserQuestion での確認）を実際に呼ぶ前に次フェーズへ進んではならない。STOP-GATE に到達する前にコンテキストが限界に近づいたら: ① reports/_carryover.md に現在地・確定値を保存 → ② ユーザーに「コンテキストが厳しいので一旦 /compact します。再開後に必ず STOP-GATE（母集団タイプ・分析の立場・別冊・タイトル・重点）を質問します」と告げてから /compact → ③ 再開後、最初に AskUserQuestion で STOP-GATE を出す。AskUserQuestion を実際に呼んでいないのに「ユーザーの回答を受信した／受信できなかった」と仮定して進むのは厳禁（存在しない回答の捏造＝重大違反。ユーザーが実際に答えるまでフェーズを進めない）。そもそも枯渇させないため、統計は C-1 のワンショットスクリプトで1回だけ算出し、CSV の試行錯誤・再読み込みをしない。
このメタルールは下記「トークン効率に関する制約」よりも上位。両者が衝突する場合、本ルールが勝つ。
以下のルールはレポートの品質とトークン効率を両立するために厳守すること。
トークン効率制約は品質ゲートを犠牲にする理由にはならない。 両者が衝突する場合はゲート優先（各ゲートの内訳は ## 0. 絶対遵守ゲートルール 第1-2項の再掲につき同節参照）。トークンが足りなければユーザーに /compact 実行を依頼するか、分割実施を提案する（効率のためのゲート省略は禁止）。
本フローはディスクから再開可能: 各フェーズの成果物（
reports/_phase_a_decisions.json、reports/<module>_deep_dive.typ、reports/report.typ）がディスクに残るため、コンテキストが厳しいツール（Codex 等）では 1スレッド=1フェーズ（Phase C は1モジュールずつ）に分割し、新スレッドでls reports/を見て続きから再開してよい。1スレッドで全フェーズを通そうとして枯渇するより確実。🧠 フェーズ間引き継ぎ日誌（
reports/_carryover.md）— 分割しても分析の記憶を失わない成果物と確定値だけでは失われる「仮説検証過程・Web調査の出所（URL/取得日）・判断理由」を残す追記式台帳（内部作業メモ・レポート本文へ転載厳禁）。
- 作成: Phase A 開始時に
capcom_schema/templates/carryover_template.mdをreports/_carryover.mdにコピーする（既にあれば上書きしない）- 書く（append-only・各追記に
[日付/Phase/thread]）: Phase A 完了時（_phase_a_decisions.json保存とペア）／Web調査は1件ヒットごとに即 WEB出所台帳へ1行（URL・サイト名・取得日。後回し禁止）／クロス1パターン確定ごと／deep_dive 1本完了ごと（ポインタのみ・本文は二重保存しない）／スレッドを閉じる・/compactする直前に現在地と直近の固有事実をフラッシュ- 読む（新スレッド開始時の固定手順）: ①
ls reports/で到達点判定 → ②_carryover.mdの STATUS/RESUME・直近フェーズ節・WEB出所台帳・申し送りを読む → ③_phase_a_decisions.jsonを読む → ④ 着手フェーズのanalysis/ガイドを読み直す → ⑤ STOP-GATE で「日誌と決定ファイルを読了し現在地を復元した」と1行報告してから着手。日誌に既にある情報（AIインサイト・Evidence）は再読しない（再読はトークン枯渇の主因）- 役割分担: 機械可読の確定値は
_phase_a_decisions.json（gate が読む正本）、散文の記憶・Web台帳は_carryover.md。二重管理しない（矛盾時は JSON が正本）- Web→脚注: Phase D で本文に主張を書く際、WEB出所台帳の該当行から
#footnote[サイト名 (URL), 取得日: YYYY-MM-DD]を生成し「footnote化」列を「済」にする（全行「済」＝Web反映漏れなし。Check 6/13 を構造的に満たす）
APOLLO は Streamlit ベースの特許分析プラットフォーム。9つのモジュールが特許データを多角的に分析し、可視化・構造化データを生成する。
CAPCOM (Capsule Communicator) は APOLLO と Claude Code を繋ぐ通信モジュール。分析結果をファイル出力し、Claude Code がデータを読み取り、自由な分析やレポート生成を行う。
🔑 内部モジュール名とレポート機能名の対応（常時適用）: データとファイル名・本書の手順は旧 APOLLO 由来の内部モジュール名（Saturn V / ATLAS / MEGA / CREW / NEBULA / CORE / Explorer / EAGLE）で書かれている。これらの内部名はレポート本文・別冊・スライド・ユーザーへの提示文に書かず、
analysis/terminology.md§2-B / §2-C の機能名（俯瞰図分析・基本統計・動態分析・キーワード分析・出願人・発明者ネットワーク・環境分析・ルール分類・探索的クラスタリング）へ読み替える。一方、データ参照（modules_used・スナップショットのmodule値・saturnv_*.json等のファイル名・prompts/のファイル名）は内部名のまま扱う（変更されていない）。
output/session_YYYYMMDD_HHMMSS/
├── data/ # patents.csv + 各モジュールJSON
├── voyager/ # VOYAGER Export時のみ（mission.json, evidence/, context.json）
├── snapshots/ # スナップショット画像(PNG)
├── prompts/ # AIプロンプト(Markdown)
├── reports/ # レポート出力先
├── capcom_schema/ # 本スキーマファイル群のコピー
├── flight_recorder.json # 分析条件の自動記録（母集団の来歴・各モジュールの実行条件）
└── metadata.json
head -5 でカラム構成を確認し、必要な分析の都度pandasで条件検索するcommon_framework.md のみ。他は必要な時に該当セクションのみ読むdata/ 配下のCSV/JSONをユーザーの質問に応じて読み取り、回答する。patents.csvの全量表示（print(df), cat）は禁止。常にフィルタリング + .head() で制限する。
VOYAGER Export 後に利用。voyager/mission.json の Mission Objective に基づく正式レポートを作成する。以下の4フェーズで進行する。
voyager/context.json の report_mode が "interactive" の場合、またはユーザーが対話型での進行を明示した場合に使用。capcom_schema/interactive/SKILL_INTERACTIVE.md を読み、それに従って進行する（変わるのは進行様式のみ。品質ゲート・成果物形式・本ファイル §0 の絶対遵守ゲートルール・トークン効率制約は上記レポート生成モードと同一に適用される）。report_mode が未指定・"autonomous" で、ユーザーの明示指示もない場合は、従来どおり上記レポート生成モードで進行する。
レポート生成は patents.csv の解析に pandas、スライド生成に python-pptx / Pillow を使う（セッションフォルダ直下の requirements-session.txt に列挙済み）。Phase A のデータ精読に入る前に、依存を必ず確認・導入すること（未導入のままだと ModuleNotFoundError で止まる）:
# セッションフォルダ直下で実行（揃っていればスキップ、無ければ一括導入）
python3 -c "import pandas, pptx, PIL" 2>/dev/null && echo "依存OK" || pip install -r requirements-session.txt
pip が無ければ python3 -m pip install -r requirements-session.txt（権限エラーは末尾に --user）。仮想環境を使うなら python3 -m venv .venv && source .venv/bin/activate の後にインストールし、以降の python3 も同じシェルで実行する。pip install が通らない場合は、依存が無いまま分析を始めず、ユーザーにセッションフォルダでのインストールと再開を依頼して一旦停止する。voyager/mission.json を読み、data/以下のJSONとpatents.csvを把握する。
全ステップは省略不可。
🛑 STEP 0 (最優先): 用語統一ルールの読了と母集団メタ情報の確認
analysis/terminology.md を最初に読む（本ガイド内で最優先の最重要ルール）
voyager/context.json の population_meta フィールドを確認する（全項目任意）:
query_intent（母集団論理式の設計意図）→ 指定されていれば、原文を咀嚼して「本分析の視座」として内在化する（詳細は下記「🎯 query_intent の扱い」）query_logic（母集団論理式）→ 指定されていれば、付録 D に #raw ブロックで全文掲載する（検索式は原文のまま貼ってよい）coverage_years（収録年情報）→ 指定されていれば、付録 A の対象期間欄と時系列分析の解釈で使うdatabase_name（使用した特許データベース名）→ 指定されていれば、付録 A とカバレッジ注記で使う。未指定なら「提供された特許データセット」と汎用表記voyager/context.json の capcom_tools.selected を確認する → レポート付録 A の「CAPCOM モジュール」欄に記載flight_recorder.json を読む（アプリが自動記録した実際の分析条件。推定で書かないための正本）。層ごとに扱いが違う（JSON 内の layer_policy が正本）:
lineage（母集団の来歴） — 読み込みファイルと件数・結合／重複除去の内訳・除外ワード数・要約の有無・分類コードが IPC か FI か。本文で使ってよい（母集団の定義章・信頼性注記）。population_meta と食い違う場合は flight_recorder.json が実測値なのでこちらを優先し、差異はユーザーに確認するruns[].judgment（判断に効く条件） — クラスタの粒度・クラスタ数・未分類率・品質指標（DBCV 等）・粒度の決め方。「結論の前提と見直しのサイン」（→ analysis/structured_techniques.md・Check 31）の材料として使う。⚠️ 数値をそのまま本文に並べるのではなく、「クラスタの粒度をこれ以上細かくすると〈クラスタ名〉は分割されうる」「未分類が N% あるため、この空白地帯の解釈は暫定である」のような条件文に変換して書くruns[].repro（再現用パラメータ） — 近傍数・最小距離・乱数シード・文埋め込みモデル名・所要秒数。付録 A の表にだけ転記する。本文への数値記載は禁止（内部パラメータの露出＝ Check 8 系に抵触）重要: database_name が未指定の場合、執筆者が勝手に J-PlatPat 等の具体名を補うことは禁止。汎用表記のみ使用すること。
🛑 PHASE A STOP-GATE (経営層向け要約版〈別冊〉の生成確認):
AskUserQuestion で「本編レポート（60-120ページ相当）に加えて、経営層向け要約版（別冊、8-12ページ）も生成しますか？」を提示。選択肢: 「✅ 両方生成する（本編 + 別冊）— 経営層への提出想定なら推奨 ／ 📘 本編のみ — 詳細分析のみで十分な場合 ／ ❓ 相談したい — 別冊の位置づけや粒度を議論してから決定」analysis/executive_summary_guide.md の §0（目的と位置づけ）を要約してユーザーに提示し、改めて確認詳細ガイド: analysis/executive_summary_guide.md（生成ルール・ページ構成・凝縮技法・禁止事項）
🛑 PHASE A STOP-GATE A (query_logic 構造化読解) — query_logic が指定されている場合に限り必須:
voyager/context.json の population_meta.query_logic に検索式が入っていた場合、執筆者はまずこの検索式を構造化して読解し、母集団がどのように抽出されているかを把握してからユーザーに確認する。検索式を付録 D にコピペするだけで済ませるのは禁止。
analysis/query_logic_reading.md を読了（DB 別構文リファレンスと 4 ステップの読解プロセスを把握）query_logic_reading.md §1 の 4 ステップを順に実施（下記は要約。正本は analysis/query_logic_reading.md §1、乖離時は正本を優先）:
population_meta.database_name の値を使う。未指定の場合は検索式の構文特徴（/TX なら J-PlatPat、HTX= なら JP-NET、$Wn なら PatSnap 等）から推測NOT A23*/IC → 食品分野除外）AskUserQuestion で DB 名・分解結果・意図推定をまとめて提示し、「この読解で合っているか」を確認AskUserQuestion で以下を提示
query_logic が未指定の場合はこの STOP-GATE を省略してよい（その旨をユーザーに 1 行で報告）
詳細: analysis/query_logic_reading.md §1（読解プロセス）、§2（DB 別構文リファレンス）
query_intent（設計意図）の扱い — 絶対遵守の 3 原則原則 1: ベタ貼り禁止
query_intent の原文はレポートのどこにも転記しない（本分析の前提章・付録 D・各 deep_dive すべて）原則 2: ユーザーとの対話確認（STOP-GATE）
🛑 PHASE A STOP-GATE (母集団設計の理解確認) — query_intent が指定されている場合に限り必須:
query_intent の原文を読解し、執筆者自身の言葉で以下 3 点を整理する:
AskUserQuestion ツールで、上記 3 点をユーザーに提示し、「この理解で進めてよいか」を確認する。選択肢は以下：
このゲートを省略して自動で書き下すのは絶対禁止。設計意図の解釈は分析の根幹に関わるため、必ずユーザー合意を取ってから進めること。
query_intent が 未指定 の場合はこの STOP-GATE を省略してよい（ただしその旨をユーザーに 1 行で報告すること）。
🛑 PHASE A STOP-GATE (サブクエスチョン化) — query_intent が指定されている場合に限り必須:
上記の query_intent 3 点整理のユーザー合意後、執筆者は 3 点整理を 「本分析が明らかにすべき具体的観点」 に分解する。この分解は執筆者が Phase B/C/D で論点を見失わないための 作業メモ として機能する。
⚠️ 絶対制約: サブクエスチョンは執筆者の内部作業メモ専用であり、レポート本文には「問い / 答え」「Q1 / A1」の形式でも SQ1 等の記号でも書いてはいけない。本文は通常の宣言調の論述で書く（正本: terminology.md §5-A-2）
query_intent の 3 点整理を基に、「本分析が明らかにすべき具体的観点」を 3-5 個 箇条書きで起草（問い形式で起草してよい、レポート本文ではない）narrative_stance）の観点で SQ を点検する（query_intent を最優先しつつ、立場が示唆する観点の抜けを確認）: self=自社の弱点・空白・強化領域／competitor=対象企業の隙・牙城・参入余地／neutral=強み・リスク・投資/提携の妙味。立場は query_intent に既に織り込まれていることが多い（機械的に SQ を立場で置き換えるのではなく、抜けの点検に使う）。立場と query_intent が食い違う場合は STOP-GATE C の立場確認で解消する。AskUserQuestion ツールで、SQ1〜SQn の一覧（各観点＋キーワード）と「この観点は内部メモ用で、レポート本文には問い/答え形式で書かない」旨を提示し、選択肢「✅ この分解で進める ／ ✏️ 修正が必要（内容を指定） ／ 💬 観点を追加・削除（具体指定）」で確認するreports/_phase_a_decisions.json の sub_questions フィールドに保存（各要素は {"id": "SQ1", "content": "〜", "keywords": ["〜", "〜"]} の形式）スキップ条件: query_intent が未指定の場合はこの STOP-GATE を省略（その旨をユーザーに 1 行で報告）
詳細: analysis/terminology.md §5-A-2（サブクエスチョン化のルールと NG/OK 例）
原則 3: 全分析を通じた視座として機能させる
詳細は analysis/terminology.md 第 5-A 節参照。
🛑 PHASE A STOP-GATE B (意図 ↔ 論理 整合性検査) — query_intent と query_logic が両方指定されている場合に限り必須:
STOP-GATE A（query_logic 構造化読解）と STOP-GATE（query_intent のユーザー合意）の両方が完了した後、執筆者は両者を対比して乖離を検出する。Critical 乖離を見つけても進行可能（ユーザー判断を尊重）だが、改善提案を必ず添えること。
analysis/query_logic_reading.md §4「B: 意図 ↔ 論理 乖離検出チェックリスト」を開くanalysis/query_logic_reading.md §4-2、乖離時は正本を優先）* NOT (A23*/IC + A21*/IC) を追加すると意図に沿う」）AskUserQuestion ツールで乖離報告 + 改善提案を提示。以下の選択肢:
スキップ条件: query_intent または query_logic のいずれかが未指定なら、この STOP-GATE を省略（その旨をユーザーに 1 行で報告）
詳細: analysis/query_logic_reading.md §4（8 項目チェックリストと提示テンプレート）
voyager/mission.json を読む（Mission Objective + Evidence一覧）voyager/context.json でデータセットのメタ情報と population_meta / capcom_tools を確認するevidence_list の全件を走査し、各Evidenceの module・title・images を一覧表で整理するsnapshots/ のファイル一覧を取得するdata/patents.csv を読む: head -5 でカラム構成 → wc -l で件数 → pandasで出願人上位10社・クラスタ別件数・年別件数を把握data/ 以下の全JSONファイルを確認: 各JSONから主要数値（クラスタ数、ノイズ率、HHI/Entropy/Gini、CAGR等）をメモ
mega_momentum_<軸>.json）が data/ に無くても、同名モジュールのプロンプト prompts/<module>_*.md の「# データ (Data)」節に同じ生データ表が埋め込まれている（出願人/IPC等 × CAGR・活動量・総数・象限の表）。JSONが無い時はこの表をそのままデータ源として使い、deep_dive を書く。スナップショット（snapshots/）も併用する。欠落と代替使用を reports/_carryover.md に1行記録し、レポートには「分析の範囲と限界」で軽く注記する（JSONが無い＝そのモジュールを省略、ではない）prompts/ のAIインサイトを読む: 主要モジュール（Saturn V/MEGA/ATLAS/Explorer/CREW/NEBULA/CORE）各1件以上、かつ全体で最低8件を、1件ずつ読む（一括読み込み禁止）。インサイトが少なければ全件読む。読了数が少ないと deep_dive が表面的になる。prompts/ の各ファイルは「役割・メタデータ・# データ (Data) 表・分析指示」を含むプロンプトであり、その「# データ (Data)」表は対応するモジュールJSONと同じ生データなので、数値根拠の一次ソースとして使えるコンテキスト管理: 巨大インサイト（saturn_drill_insight.md・crew_network_insight.md）は全量読み込み禁止・対象箇所のみ grep（サイズと規則の正本は §5.6 段階的読み込みルール）。
🛑 PHASE A STOP-GATE C (データ側からの母集団実態確認 + 母集団タイプ判定) — 必須（全ケースで実施）:
データ精読が一通り完了したら、patents.csv から算出した母集団の実態像をユーザーに提示し、設計意図・検索式との整合性を最終確認する。同時に母集団タイプ（A/A'/B/C/D）も判定する。query_intent / query_logic が未指定でも、この STOP-GATE は必ず実施する（最小限のユーザー確認は必須）。
C-1. データ Level 2 逆読み
⚠️ patents.csv の実カラム（試行錯誤＝コンテキスト枯渇を避けるため最初に把握する）: カラムは 処理済み（applicant_main=主出願人 / inventor_main / year=出願年 / ipc_main_group / cluster〈整数〉 / cluster_label〈'[3] 半導体記憶, メモリセル, 半導体' 形式〉 / umap_x,umap_y / core_{軸名} 分類）と 原データ（発明名称〈先頭に BOM あり〉/ 要約〈要約なしデータでは列ごと存在しない — voyager/context.json の abstract_available を確認〉/ 出願番号 / 公開番号 / 原文リンク列〈文献URL 等・割り当てがあるデータのみ。代表特許の言及時に原文参照として使える〉）の混在。⚠️ applicant_main / inventor_main / ipc_main_group はリスト文字列（"['キオクシア', '東芝']" 形式）なので集計には展開（explode）必須＝下記スクリプトの listcol が対応（しないと共同出願を1社と誤カウント）。voyager/context.json の column_mapping は元 CSV 名で実カラムと一致しないので照合に使わない。ステータス（権利状況）列は無い — 権利化率は prompts/atlas_*_insight.md のステータス内訳から読む。
ワンショット統計スクリプト（実データで検証済み・BOM/リスト文字列対応。heredoc の多重実行・カラム名の探り当て・Unicode 正規化の試行は禁止＝今までの枯渇の主因）:
import pandas as pd, ast
df = pd.read_csv("data/patents.csv", encoding="utf-8-sig")
def listcol(col): # "['A','B']" 形式のリスト文字列を展開する
def parse(x):
try:
v = ast.literal_eval(x) if isinstance(x, str) and x.strip().startswith('[') else x
return v if isinstance(v, list) else [v]
except Exception:
return [x]
return df[col].dropna().apply(parse).explode().astype(str).str.strip()
print("総件数:", len(df), "| 期間:", int(df['year'].min()), "-", int(df['year'].max()))
ap = listcol('applicant_main')
print("\n[上位出願人]\n", ap.value_counts().head(10).to_string())
sh = ap.value_counts(normalize=True); print("\n出願人HHI:", round((sh**2).sum(), 4))
print("\n[年別件数]\n", df['year'].value_counts().sort_index().to_string())
print("\n[上位IPC]\n", listcol('ipc_main_group').value_counts().head(10).to_string())
print("\n[クラスタ別件数]\n", df.groupby(['cluster','cluster_label']).size().to_string())
（patents.csv に無い指標〈権利化率・Fターム等〉は prompts/ や data/*.json から得る。CSV を読み直さない）
analysis/query_logic_reading.md §5「C: データ側からの逆読み」を開き、§5-1 の Level 2 項目（総件数・期間・DB／上位10出願人〈件数・シェア〉／主要IPC/FI上位10／出願年分布／出願人HHI／国・地域分布）を算出する（項目の正本: 同 §5-1、乖離時は正本を優先）C-2. 母集団タイプ判定
analysis/population_type_metrics.md を読了（5 タイプ分類・指標解釈表・タイプ別禁止表現リスト）analysis/population_type_metrics.md §4-2、乖離時は正本を優先）:
query_intent と query_logic の内容からも候補タイプを裏付けるC-2'. 分析の立場（叙述スタンス）判定 — 母集団タイプとは独立に必ず判定
母集団タイプ（データの構成）と「誰の意思決定のためのレポートか（＝提言・主張を語る立場）」は別物である。母集団が単一企業（タイプ C）でも読者＝依頼主は競合・投資家・アナリストのこともあるため、population_type が C だからといって対象企業を自動的に「当社」と呼んではならない（立場の取り違え＝対象企業を勝手に「当社」と書く誤りが実テストで頻発）。
query_intent / Mission Objective から 分析の立場 を推定する（5 分類）:
| コード | 立場 | 対象企業の呼び方 | 一人称「当社/弊社」 |
|---|---|---|---|
| self | 自社視点（当事者本人が自社を点検） | 「当社」 | 可 |
| competitor | 競合・他社視点（水平。対象企業をベンチマーク） | 企業名で三人称（「キオクシアは」） | 提言で読み手＝競合自身を指す時のみ可 |
| buyer | 自社＝買い手／対象＝供給元（自社が対象から仕入れる。例: 自社=Apple, 対象=キオクシア） | 企業名で三人称 | 読み手＝買い手自身を指す時のみ可 |
| supplier | 自社＝供給元／対象＝顧客（自社が対象に納入する。例: 自社=東京エレクトロン, 対象=キオクシア） | 企業名で三人称 | 読み手＝供給側自身を指す時のみ可 |
| neutral | 中立・第三者視点（投資家・アナリスト・調査） | 企業名で三人称 | 不可 |
推定の手がかり: query_intent に「自社」「当社」「我々の」→ self／「競合」「ベンチマーク」「対抗」→ competitor／「調達」「サプライヤー選定」「供給元」「仕入れ」→ buyer／「販売先」「納入先」「顧客の技術動向」→ supplier／「投資判断」「評価」「調査」や立場の記述なし → neutral（既定）。手がかりが弱ければ neutral を仮置きし、C-3 で必ずユーザーに確認する（勝手に self にしない）。
確定した立場は提言・主張・エグゼクティブサマリー・別冊の全セクションで一貫させる。呼称だけでなく分析の力点・提言のロジックも立場に合わせる（self=自社の打ち手／competitor=競合の対抗・参入／buyer=調達戦略・依存/供給リスク／supplier=供給戦略・内製化リスク／neutral=第三者の評価・予測。呼称を三人称にしただけの「べき論」にしない）。self 以外では対象企業を三人称で呼び「当社/弊社/我が社」を使わない（正本: terminology.md の「分析の立場」節）。
立場が competitor / buyer / supplier（＝関係性立場・自社 ≠ 対象）の場合は「自社（分析を行う側の企業）」の特定が必須: 対象企業（subject_company）に加え、分析を行う自社の社名を C-3 でユーザーに尋ね narrative_stance.own_company に記録する。自社は Phase B で Web 調査し、対象企業との対比（自社の強み/弱み/空白 vs 対象企業）に用いる（正本: §3、 §6-2-B）。/ の依存・交渉力の読み方は: タイプ A/A'/B なら出願人 HHI・上位集中を供給側/需要側の集中シグナルとして読める（特許≠市場につき Web 裏付け）が、（出願人ほぼ1社＝HHI≈1）——依存・交渉力は **Web 調査（対象の市場シェア・取引構造）**から読む。 では が自社そのもの、 では自社は存在しない（ は空文字）。
C-3. 統合ユーザー確認（STOP-GATE）
AskUserQuestion ツールで以下を統合提示する（質問: 「本母集団の実態とタイプを確認します」）:
AskUserQuestion（複数質問に分ける場合）として聞く時の選択肢（必須）: 選択肢は最大4つのため5立場を全部は並べられないが、competitor / buyer / supplier を『その他』に畳んではいけない（見えないと選べない＝関係性立場が死ぬ）。次の4択で提示する（推定した立場を先頭に置き (推奨) を付す）:
AskUserQuestion で具体的な立場＋自社名（own_company）を確認する。⚠️ コード名は常に『自社の役割』なので、4 の確認は buyer/supplier の語で迷わせず取引の向きで訊く: 「① 自社が対象から仕入れる側 → buyer／② 自社が対象に納入する側 → supplier」（定義と例の正本: 上記 C-2' の 5 分類表・terminology.md §6-2-B）。単一企業母集団（タイプ C）でも 5 立場すべて有効（単一企業だから self/neutral だけ、と決めつけない）。competitor / buyer / supplier（関係性立場）に確定したら、続けて自社名を尋ねる（必須）: 未取得なら追加の AskUserQuestion で「本分析を行う『自社』の社名」を確認し、narrative_stance.own_company に保存する。Phase B STOP-GATE の Web 調査テーマ提示に「自社（{社名}）の事業・技術・特許ポジション」を必ず含める（→ analysis/data_notes.md §3）。ユーザーが「自社名は伏せる／一般的な視点でよい」と答えた場合は を空文字にし、その旨を 1 行報告して従来どおり進める。C-4. reports/_phase_a_decisions.json への保存
reports/_phase_a_decisions.json に保存:
{
"phase_a_version": "v9.0",
"phase_a_completed_at": "{ISO8601 タイムスタンプ}",
"population_type": {
"code": "{A/A'/B/C/D}",
"label": "{タイプ名}",
"reasoning": "{推定根拠・ユーザー確認内容}",
"confirmed_by_user": true
},
"narrative_stance": {
"code": "{self/competitor/buyer/supplier/neutral}",
"label": "{自社視点（当社）/競合視点/中立（投資家・アナリスト）}",
"subject_company": "{分析の主役（対象/ベンチマーク先）企業名・特定企業がなければ空文字}",
"own_company": "{competitor/buyer/supplier 視座で分析を行う『自社』の社名。self では subject_company と同一。neutral・自社名を伏せる場合は空文字}",
"first_person_allowed": {true（self のみ）/false},
"reasoning": "{立場の推定根拠・ユーザー確認内容}",
"confirmed_by_user": true
},
"query_logic_structure": { ... },
"intent_logic_divergences": [ ... ],
"data_level2_warnings": [ ... ],
"forbidden_expressions": [
"市場は寡占", "業界シェア", "業界の集中度", "市場構造", "競争環境は〜", "業界全体で", ...
],
"user_notes": "{ユーザー追加コメント}"
}
forbidden_expressions は population_type_metrics.md §3 の該当タイプの禁止表現リストをコピーphase_d_gate.sh Check 11（母集団タイプ）・Check 11s（分析の立場 narrative_stance）でも自動チェック対象となる詳細: analysis/query_logic_reading.md §5（Level 2 項目）、analysis/population_type_metrics.md（5 タイプ分類と指標解釈）
🛑 PHASE A STOP-GATE D (NEBULA 戦略判定) — 必須（全ケースで実施）:
APOLLO では環境分析（内部名 NEBULA。学術論文・ニュース・政策の取り込み）が未実行の場合、レポートの「環境分析章」が成立しなくなる。このゲートでは、NEBULA データの有無を確認し、未実行なら Web 調査で補完するか / 省略するか をユーザーに選択させる。
D-1. NEBULA データの存在確認
data/ 配下に NEBULA 関連ファイルが存在するか確認:
data/nebula_hype_cycle.jsondata/nebula_macro_events.jsondata/nebula_academic_clusters.jsonnebula_strategy.data_available = true、全て非存在なら falseD-2. モード判定
data_available = true の場合:
selected_mode = "execute" を自動決定（通常の NEBULA 章を実施）data_available = false の場合、AskUserQuestion ツールで以下を提示:
質問: 本セッションでは環境分析（学術論文・ニュース・政策の取り込み）が
未実行です。環境分析の扱いをどうしますか?
選択肢:
- 🌐 Web 調査で補完する
→ Phase B で以下 4 カテゴリを Web 調査で必須カバー:
(1) 市場規模 / 業界統計
(2) 政策・規制動向
(3) 学術動向 / 研究キーパーソン
(4) 主要企業動向 / プレスリリース
→ レポートに「外部環境分析（Web 調査）」章を設置
→ 各主張に #footnote[...] で出所明記
- 📘 環境分析を省略する
→ レポートに環境分析章を設けない
→ 「本分析の範囲と限界」で「特許情報のみを対象」と明記
→ 学術-特許クロス分析も省略
D-3. _phase_a_decisions.json への保存
{
"nebula_strategy": {
"data_available": false,
"selected_mode": "web_compensation",
"user_confirmed": true,
"web_coverage_categories": ["市場規模", "政策・規制", "学術動向", "主要企業動向"],
"notes": "NEBULA 未実行のため Web 調査で 4 カテゴリを補完"
}
}
selected_mode は "execute" / "web_compensation" / "omit" のいずれかweb_compensation モード時、web_coverage_categories に 4 カテゴリすべて含める詳細: analysis/population_type_metrics.md §4-3（nebula_strategy フィールド仕様）
→ 完了条件: terminology.md 読了・population_meta の4フィールド確認済み / patents.csv統計把握済み / 全JSONから主要数値抽出済み / AIインサイト8件以上（主要モジュール各1件以上）読了・メモ作成済み / query_logic 構造化読解（指定時）／意図↔論理整合性検査（両方指定時）／データ逆読み(必須)／NEBULA 戦略判定(必須) の 4 STOP-GATE 全て完了 / データセット全体像メモをユーザーに提示済み
🛑 STOP-GATE: 以下を全て実行するまで Phase B へ進むな
AskUserQuestion ツールで 3案を提示し、ユーザーに選択してもらう| ファイル名パターン | モジュール | 内容 |
|---|---|---|
atlas_*_insight.md | ATLAS | 各種統計分析 |
core_matrix_insight_*.md | CORE | マトリクス分析 |
saturn_main_insight.md | Saturn V | TELESCOPE全体俯瞰 |
saturn_drill_insight.md | Saturn V | PROBE個別深掘り（巨大、部分読み込み必須） |
mega_pulse_insight.md | MEGA | 4象限動態分析 |
exp_*_insight.md | Explorer | 共起ネットワーク分析 |
crew_network_insight.md | CREW | ネットワーク分析（巨大、部分読み込み必須） |
nebula_insight_*.md | NEBULA | 特許/学術/ニュース別分析 |
🛑 STOP-GATE 1 (リファレンス読了 + クロスパターン確認): 以下を全て実行するまで Phase B 本体に進むな
analysis/common_framework.md を読了 → 4層分析モデルと数値根拠の書式を把握analysis/data_notes.md を読了 → 特許/NPL 非対称性と Web 調査ルールを把握analysis/cross_module.md を読了 → 13種のクロスパターンから5つ以上を選定（Phase B 完了条件・gate Check 4 の最低数と同じ）AskUserQuestion ツールで「採用するクロスパターン5つ以上(例: P1/P4/P7/P9/P13)」をユーザーに提示・確認🛑 STOP-GATE 2 (Web調査の意思確認): Phase B 本体作業前に必須
reports/_phase_a_decisions.json の narrative_stance を確認 — 立場が competitor / buyer / supplier（関係性立場）かつ own_company が非空なら（下記モードに関わらず必須）: 提示する Web 調査テーマに「自社（{own_company}）の事業内容・主要製品・技術/特許ポジション・市場での立ち位置」を必ず 1 件以上含める（目的・使い方の正本: analysis/data_notes.md §3、analysis/terminology.md §6-2-B）。取得情報は脚注（サイト名・URL・取得日）を付し、少なくとも 1 つのモジュール章または提言章で自社 vs 対象企業の対比に使う。reports/_phase_a_decisions.json の nebula_strategy.selected_mode を確認し、以下のモード別対応を適用:モード execute の場合（NEBULA 実行済み）:
AskUserQuestion で「実施する / しない / テーマ修正」の 3 択 + Other を提示モード web_compensation の場合（NEBULA 未実行・Web 補完）:
AskUserQuestion で一覧提示してユーザー確認web_coverage_categories で 4 カテゴリが依然カバーされていることを確認。1 つでも欠ける場合は警告して再確認（欠けたまま進めると Phase D gate Check 13 で FAIL）モード omit の場合（NEBULA 未実行・省略）:
通常通りの任意 Web 調査として進行（3-5 件のテーマ提示、3 択）
「外部環境分析」章は作らないが、任意のトピックとしての Web 調査は可
ユーザー応答を待つ。「省略します」「不要と判断しました」等の AI 自己判断は禁止
Phase A の情報を参照せずに Phase B を進めてはならない。
map_reading.md の該当セクション読解 / 代表特許の抽出 / スナップショット画像パス記録data/patents.csv をpandasで条件検索し、代表特許のタイトル・出願人・公開番号を最低15件取得するanalysis/cross_module.md の基本原則を読み、最低5パターン（P1-P13から）を選択・実行する→ 完了条件: Evidence 5件以上精読済み / AIインサイト照合メモ作成済み / 代表特許15件以上取得済み / クロス分析5パターン以上の仮説→検証→結論を完了済み
→ データ特性・Web調査ルール: analysis/data_notes.md（特許/NPL非対称性・ギャップ分析の注意・Web調査ルールは同 §3）
🛑 STOP-GATE (リファレンス読了 + 計画確認): 以下を全て実行するまで deep_dive の執筆を始めるな
analysis/deep_dive_guide.md を読了 → 各 Step の必須セクション数と最低行数を把握AskUserQuestion ツールで「各モジュールの Step 数・最低行数の理解(例: 俯瞰図分析 13セクション/250行)を一覧で提示し、これで進めて良いか」をユーザーに確認exemplarsを参照し、全モジュールのdeep_dive.typを生成する。Phase DはPhase Cの出力ファイルを前提とする。
各モジュールのexemplarを読む → deep_dive.typを生成
全deep_diveにミクロ分析A（代表特許15件以上）+ B（出願人5社以上、各5行以上）を含める
Step 0: NEBULA → Step 1: Saturn V → Step 2: Explorer → Step 3: MEGA → Step 4: ATLAS → Step 5: CORE → Step 6: CREW の順で処理
Phase C 完了ゲート (必須実行): 以下のスクリプトを実行し、exit code が 0 でない場合は Phase D 開始禁止。不足モジュールを補強してから再実行する。
bash capcom_schema/scripts/phase_c_gate.sh
このスクリプトは各 deep_dive ファイルの存在と内容量（非空白文字数。行数 wc -l は1文1行で水増し可能なため文字数で判定）を客観的に判定する。「実質的にOK」等の AI の質的判断による上書きは禁止(## 0. 絶対遵守ゲートルール 第3項)。
→ 完了条件: deep_dive 4ファイル以上（Saturn V + Explorer + MEGA + ATLAS）、各最低行数を満たす
→ 詳細手順: analysis/deep_dive_guide.md（Step 0-6の必須セクション・最低行数・ミクロ分析ルール全て記載）
| モジュール | 最低行数 | 必須セクション数 |
|---|---|---|
| NEBULA | 120行 | 8セクション |
| Saturn V | 250行 | 13セクション |
| Explorer | 200行 | 11セクション |
| MEGA | 120行 | 9セクション |
| ATLAS | 120行 | 9セクション |
| CORE | 80行 | 7セクション |
| CREW | 60行 | -- |
🛑 STOP-GATE (リファレンス読了 + 構成確認): 以下を全て実行するまで report.typ の生成を始めるな
analysis/report_structure.md を読了 → 章構成と deep_dive コピールールを把握analysis/quality_checklist.md を読了 → 定量チェックコマンドとチェック項目を把握analysis/terminology.md の最終確認（Phase A で読んだ内容を再確認、section 5 の品質チェックコマンドを手元に）AskUserQuestion ツールで「report.typ の章構成(例: 11章、本分析の前提章と付録D含む)と品質チェック項目数で進めて良いか」をユーザーに確認全deep_diveを統合し、report.typを生成する。品質チェックリスト確認。
前提条件: reports/ に最低4つの *_deep_dive.typ が存在すること（4つ未満ならPhase Cに戻る）。
ls reports/*_deep_dive.typ でファイル存在を確認する
analysis/patent_citation.md セクション2-3を読む（引用書式の確認）
Phase Cで生成した全deep_diveファイルを読む
report.typ を生成する（→ analysis/report_structure.md セクション1の構造に従う）
population_meta の任意項目のみ記載）database_name / coverage_years / CAPCOM モジュール行を追加population_meta.query_logic が指定されていれば付録 D「母集団検索式」を追加deep_diveの全文コピー: 要約・圧縮・省略は一切禁止（→ analysis/report_structure.md セクション2）
用語統一・スコープ限定チェック: 内部JSONファイル名・内部フィールド名・内部ガイドファイル名・内部プロセス用語（deep_dive / Phase A-D 等）の混入ゼロ、未指定DB名（J-PlatPat 等）の補完なし、スコープ限定語 ≥ 5 件かつ無限化語 ≤ 限定語 × 0.3（terminology.md §6）を満たすこと。個別 grep コマンドの正本は gate スクリプト（次項で一括実行）
品質検証ゲート (必須実行): 以下のスクリプトを実行し、結果をユーザーに報告する。exit code が 0 でない場合、不合格項目を修正してから再実行する。
bash capcom_schema/scripts/phase_d_gate.sh
このスクリプトが analysis/quality_checklist.md section 1 の定量チェック（Check 1〜37。用語統一・スコープ限定・別冊チェックを含む）を統合実行する。「自前のチェックで代替」は禁止(再現性のないチェックは無効)。
別冊（経営層向け要約版）生成 — Phase A で「両方生成」が選択されていた場合に必須:
analysis/executive_summary_guide.md を読了 → ページ構成・凝縮技法・禁止事項を把握reports/report.typ が合格している（上記 Step 7 をパス）ことを前提に、reports/report_executive.typ を生成するquery_intent から導かれる「今回の意思決定テーマ」に即して再構成する（詳細は executive_summary_guide.md §3 参照）。定型の分類軸を機械的に当てはめるのは不可→ 完了条件: report.typが品質基準を満たす + 用語チェックが全てゼロヒット + 別冊フラグが ON なら report_executive.typ も品質基準を満たす
→ レポート構造: analysis/report_structure.md（全体構造・deep_diveコピールール・結論章ガイド・付録テンプレート・v8 母集団メタ反映）
→ 別冊構造: analysis/executive_summary_guide.md（。経営層向け要約版の執筆ルール・ページ構成・凝縮技法）
→ 用語統一: analysis/terminology.md（内部識別子の露出禁止ルールと正式日本語呼称）
→ 品質検証: analysis/quality_checklist.md（定量チェックコマンド・全チェック項目・推奨項目）
| モジュール | JSON ファイル | 概要 | スキーマ |
|---|---|---|---|
| ATLAS | atlas_statistics.json, atlas_grant_rate.json | 時系列推移、ランキング、ライフサイクル、権利化率（出願数×権利化率の象限） | references/atlas_schema.md |
| CORE | core_classification.json | ルールベース特許分類 | references/core_schema.md |
| Saturn V | saturnv_clusters.json, saturnv_drilldown_<クラスタ>.json | AIクラスタリング (TELESCOPE/PROBE) | references/saturnv_schema.md |
| MEGA | mega_momentum_<軸>.json (applicant/ipc/fterm), mega_drilldown_<対象>.json | 動態分析 (CAGR x 活動量 4象限・軸別) | references/mega_schema.md |
| Explorer | explorer_global_network.json, explorer_trend.json, explorer_dominance.json | キーワード共起ネットワーク | references/explorer_schema.md |
| CREW | crew_network.json | 発明者/出願人ネットワーク (要約版) | references/crew_schema.md |
| EAGLE | eagle_clusters.json | 探索的ランドスケープ (手動クラスタリング) | references/eagle_schema.md |
| NEBULA | nebula_hype_cycle.json, nebula_macro_events.json | 非特許文献統合・環境分析 | references/nebula_schema.md |
| VOYAGER | voyager/mission.json, evidence/, context.json | 戦略レポート用データパッケージ | references/voyager_schema.md |
| (共通) | *_wordcloud.json | 各モジュールのワードクラウド単語頻度 | references/wordcloud_schema.md |
スキーマ参照ルール: references/ のスキーマファイルは、そのモジュールのJSONを実際に読む直前に参照する。全スキーマの一括読み込みは禁止。
全特許データのCSVファイル。サイズ警告: 1,000件で1MB以上。絶対に全量読み込みしないこと。 推奨アクセスは条件検索＋.head()（例: df[df['cluster'] == 3][['title', 'applicant_main', 'year']].head(20)）。print(df) は禁止。
各モジュール実行後にpatents.csvが随時更新される。未実行モジュールのカラムは存在しない。
analysis/cross_module.md）analysis/common_framework.md）#snapshot-figure() を含めるprompts/ のAIインサイトを必ず参照し、深い読み取りをレポートに反映するanalysis/data_notes.md セクション3）#footnote[...]) を添える（→ analysis/terminology.md §6）→ 詳細: analysis/data_notes.md（特許とNPLの非対称性、ギャップ分析の注意、Web調査ルール）
references/ = データの「読み方」（辞書）、analysis/ = 「考え方・書き方」（分析手法）、prompts/ = 「マップからの読み取り結果」（AIインサイト）。
| ファイル | 内容 | 使用フェーズ |
|---|---|---|
common_framework.md | 4層分析モデル、数値根拠の書式、データソース明示ルール | Phase B開始時 + Phase D |
map_reading.md | UMAP/共起NW/4象限/人的NW/ライフサイクルの読解手順 | Phase B（該当セクションのみ） |
cross_module.md | 13種のクロスモジュール分析パターン | Phase B（基本原則 + 選択パターンのみ） |
patent_citation.md | 代表特許検索・引用書式・ハルシネーション防止 | Phase D（セクション2-3のみ） |
noise_analysis.md | ノイズ特許の5手法分析フレームワーク | Phase C Step 1 |
deep_dive_guide.md | Step 0-6の必須セクション・最低行数・ミクロ分析ルール | Phase C（必読） |
report_structure.md | report.typ構造・deep_diveコピールール・付録テンプレート | Phase D（必読） |
quality_checklist.md | 定量チェックコマンド・品質チェック全項目・推奨項目 | Phase D（必読） |
data_notes.md | 特許/NPL非対称性・ギャップ分析注意・Web調査ルール | Phase B/C/D |
query_logic_reading.md | 母集団検索式の読解（DB 別構文・乖離検出・データ逆読み） | Phase A（STOP-GATE A/B/C で必読） |
population_type_metrics.md | 母集団 5 タイプ分類と指標解釈ルール（タイプ B/C/D の市場・業界表現禁止） | Phase A STOP-GATE C、Phase C/D 執筆時 |
structured_techniques.md | 構造化分析技法（ACH 競合仮説・リンチピン・ミラーイメージング点検）＋代表特許の決定的選定の原則 | Phase C 統合インサイト節・Phase D 結論章の執筆直前（常時読み込み不要） |
| ファイル | 内容 | 使用フェーズ |
|---|---|---|
exemplars/nebula_exemplar.typ | NEBULA環境分析のお手本 | Phase C Step 0 |
exemplars/saturnv_exemplar.typ | Saturn V / EAGLE分析のお手本 | Phase C Step 1 |
exemplars/explorer_exemplar.typ | Explorer分析のお手本 | Phase C Step 2 |
exemplars/mega_exemplar.typ | MEGA PULSE分析のお手本 | Phase C Step 3 |
exemplars/atlas_exemplar.typ | ATLAS統計分析のお手本（権利化率分析 §10 含む） | Phase C Step 4 |
exemplars/core_exemplar.typ | CORE ルールベース分類分析のお手本 | Phase C Step 5 |
exemplars/crew_exemplar.typ | CREW 人的ネットワーク分析のお手本（指標別の解釈） | Phase C Step 6 |
お手本の使い方: exemplar は「どう書くか」を具体例で示す。exemplarを読まずにdeep_diveを書き始めてはならない。（全7モジュールに exemplar あり）
analysis/:
common_framework.md のみmap_reading.md の対象セクションのみcross_module.md の基本原則 + 使用パターンのみdeep_dive_guide.mdreport_structure.md + quality_checklist.md + patent_citation.md セクション2-3prompts/:
ls -la prompts/ でファイル一覧とサイズを確認saturn_drill_insight.md（最大220KB）と crew_network_insight.md（最大400KB）は絶対に全量読み込みしないn_edges_total で全体規模を確認capcom_schema/templates/report_style.typ を reports/ にコピーreport.typ を生成（#show: apollo-report.with(...) で開始）#snapshot-figure("../snapshots/xxx.png", caption: "説明") で挿入#styled-table(columns: ..., header: ([...], [...]), ..body) でBCG風スタイル適用typst compile --root ".." reports/report.typ reports/report.pdftemplates/report_style.typ の各関数 doc コメント）exec-summary[...] — エグゼクティブサマリーボックスkpi-dashboard(cols: 3, kpi-card(...), ...) — KPIダッシュボード（ページまたぎ防止）kpi-card("ラベル", "値", note: "補足") — KPIカード（ドル記号禁止: $/\$ 不可、「ドル」「USD」で表記）evidence-box(番号, "タイトル")[...] — Evidenceボックスinsight-box[...] — Key Insightボックスnote-box[...] — 注釈ボックスpoint-lead[...] — 要点ストリップ（見出し直後の結論先出し1〜2行。散文の代替ではない）hl[...] — インライン強調（1セクション数語まで・多用禁止）snapshot-figure("パス", caption: "説明") — スナップショット画像styled-table(columns: ..., header: (...), ..body) — BCG風テーブルconclusion-box("タイトル")[本文] — 主要結論ハイライトrecommendation-card("高", "タイトル", "説明", timeframe: "短期") — 優先度付き推奨action-items("アクション1", "アクション2", ...) — ToDoリスト📐 読みやすさ（走査層）— 詳細は
analysis/deep_dive_guide.md「読みやすさ（走査層）」: 地の文の塊を減らすため、①各番号セクションの冒頭に#point-lead[...]を1個置き結論を1〜2行で先出しする（散文は下にそのまま書く＝薄くしない）②件数・%・倍などの数値＋単位はテンプレートが自動で太字強調するので手動で数字を太字化しない③段落余白・見出しバーも自動。要点だけ書いて散文を削るのは Check 1（文字数）で不合格。
注意: report_style.typ のフォント設定を変更しないこと。#set text(font: ...) を report.typ に直接書かないこと。画像パスは reports/ からの相対パス。typst compile に --root ".." を付けること。旧API（#setup-page() / #cover-page(...) 等）は廃止済み。
reports/report.typ を土台に作る — evidence の短い説明文の寄せ集めでなく、レポート各章の主張→根拠（数値）→示唆を凝縮し、章順（前提→サマリー→環境→俯瞰→動態→競争→クロス統合→仮説検証→結論・提言→将来）に沿わせる。出所は分析モジュール名でなくデータ（特許データセット／Web実出所）にする（詳細は slides_spec §0.9）capcom_schema/templates/apollo_template.pptx を reports/ にコピーするcapcom_schema/templates/slides_spec.md を設計ガイドとして熟読する（Section 0〜6。とくに §0.9「レポートを土台にする」）。いつ・どのヘルパーを・どんな主張骨格で使うかを把握する文書であり、ヘルパー実装をここから写経するのではないimport sys; sys.path.insert(0, "capcom_schema/templates"); from apollo_slides import * し、add_title_shape / add_sub_message / add_kpi_slide / add_matrix_2x2_slide / _apply_font 等のヘルパーを呼ぶ。自前で pptx のフォント・色・レイアウトを書き起こさない（過去の Codex「単一ウェイト・平板」の原因）。Presentation('reports/apollo_template.pptx') + slide_layouts[6]（Blank）でスライドを生成するNoto Sans JP 統一。_apply_font(run, weight=...) で多段ウェイト（見出し=Black/本文=Regular/出典=Light、強調=Bold）を使い分けadd_chart_text_slide() 40%以上、add_dual_panel_slide() 15-20%、テキスト主体15%以下fit_image() 必須。reports/presentation.pptx に出力。推奨25-40枚| ユーザーが言ったこと | 正しい解釈 | 誤った解釈(禁止) |
|---|---|---|
| 「レポートを書いて」 | SKILL.md の全フェーズに従う | 急いでいる→省略OK |
| 「早く」「すぐに」 | 並列処理で速度UP(ゲートは守る) | ゲート省略OK |
| 「簡単でいい」 | 各セクションの記述量を短く | ゲート省略OK |
| 「適当に」 | デフォルト設定で進める | ユーザー確認スキップOK |
| 「次へ」「進めて」 | 当該ステップが完了済みなら次へ | 未完了でも次へ進む |
省略を許可するのは、ユーザーが明示的に「Phase B は飛ばして」「Web 調査いらない」等と言った時のみ。 AI 側の推測で省略してはならない(## 0. 絶対遵守ゲートルール 第5項)。
analysis/data_notes.mdanalysis/terminology.mdbuyersupplierselfsubject_companyneutralown_companyown_companyterminology.md の用語統一ルールを遵守（内部識別子の露出禁止）bash capcom_schema/scripts/phase_d_gate.sh を再実行して確認する（別冊存在時に自動チェック。個別コマンドの正本は gate スクリプト）typst compile reports/report.typ reports/report.pdf ／ 別冊 typst compile reports/report_executive.typ reports/report_executive.pdf