jiayi-ThE-CREATOR kigyou-report — 就活企業分析レポート生成 skill
ユーザーが指定した企業を構造化レポートに蒸留し、Obsidian Vault の「企業分析报告/」に保存する skill。フル版 12 セクションと、下流 skill が読む節だけの極簡版（--min）がある（公開情報が薄い企業は簡易 5 版に縮退。エッジケース参照）。
詳細は references/ に分離（必要な Step で読む）
この SKILL.md と同じディレクトリの references/ 配下：
| ファイル | いつ読むか |
|---|---|
style-guide.md |
Step 3 と Step 5：Callout / テーブル / Wikilink の書式規約 ＋ Web リサーチのクエリ設計 |
report-skeleton.md |
Step 5：各要素の書式サンプル（過去レポートを書式参考として全読しないため） |
division-section.md |
Step 5 でセクション 4 を書くとき：業界別の構造モデル選択・Mermaid テンプレ・各部門サブセクションの構造・引用ルール・公式ページの取得手順 |
パス解決（正本はレジストリ）
パスの唯一の定義元は vault.paths.env（clone 版はリポジトリ直下、plugin 版は ~/.config/shukatsu-skills/。下の手順で解決する）。このスキルで使うキー：
VAULT_KIGYOU_REPORTS → 企業分析报告/（レポート保存先）
VAULT_SHUKATSU_DISTILL → 就活蒸留システムの根目録（素材参照元は 素材/ 配下、蒸留知識参照元は 蒸留知識/ 配下）
VAULT_ROOT → vault 根（Step 2 の grep 起点）
ファイル名形式 → 【<企業名>】企業分析レポート.md
解決方法：
# vault.paths.env の場所は clone 版 / plugin 版で変わる。先頭から順に、最初に見つかったものを使う
for c in "${SHUKATSU_SKILLS_ROOT:-}/vault.paths.env" \
"$HOME/.config/shukatsu-skills/vault.paths.env" \
"${CLAUDE_PLUGIN_ROOT:-}/vault.paths.env"; do
[ -f "$c" ] && { set -a; . "$c"; set +a; break; }
done
SKILLS_ROOT="${CLAUDE_PLUGIN_ROOT:-$SHUKATSU_SKILLS_ROOT}" # tools/ の置き場
どれも見つからなければ、推測でパスを直さず「セットアップが未完了です。$SKILLS_ROOT/setup.sh を実行してください」と案内して終了する。
本文にパスを直書きしない（vault 再編で壊れるのを防ぐ）。 パスが存在しなかったら推測で直さず、レジストリを読んで解決し直すこと。
起動フロー
/kigyou-report <企業名>→ フル版（12 セクション）/kigyou-report <企業名> --min→ 極簡版（5 セクション。下記）/kigyou-report（引数なし） → ユーザーに企業名を確認
極簡版（--min）
下流の skill（/es-coach・/mensetsu-report）が実際に読む節だけを書く軽量モード。フル版の約 2/3 の分量で、選考に直接効く部分は落とさない。
出力するのは以下の 5 セクションだけ：
| # | セクション | フル版での番号 | なぜ残すか |
|---|---|---|---|
| 1 | 一言で言うと + 会社概要テーブル | 1〜2 | 全体像。これが無いと他の節が読めない |
| 2 | 部門・職種マップ | 4 | /es-coach が志望部門の節を読む。最重要 |
| 3 | 採用フロー | 5 | 選考の段取り。/mensetsu-report が読む |
| 4 | 企業理念・求める人材像 | 6 | /es-coach の企業適合評価の根拠。最重要 |
| 5 | 面接対策（想定質問 TOP 10 + 逆質問 3 つ） | 11 | /mensetsu-report の土台 |
落とすのは：日本市場での位置づけ / 年収・キャリアパス / 競合比較 / 内定者の共通パターン / ES 攻略法 / 一年間の準備プラン / FAQ。 （実測では、これらはレポート全体の約 31% を占めるが、下流 skill は一度も読まない。読むのは人間だけ。）
- frontmatter に
report_type: 極簡版と明記する（/es-coach等が「この企業は年収情報が無い」と分かるように） - セクション 2 と 4 はフル版と同じ密度で書く——ここを削ると極簡版の意味が無くなる
- 後からフル版に格上げしたくなったら
/kigyou-report <企業名>を実行し、「既存レポートの更新ルール」の①完全再生成を選ぶ
情報が薄くて書けない場合の「簡易版」（エッジケース参照）とは別物。極簡版は情報はあるが意図的に軽く作るモード。
Step 1 — 企業名の確認
ユーザーが指定した企業名を受け取る。曖昧な場合は以下を確認：
- 正式社名（例：「GS」→「ゴールドマン・サックス証券株式会社」）
- 日本拠点か / グローバル本社か
- 親会社・子会社の関係（例：「MS」は MUFG との JV を含むか）
Step 2 — Vault 既存ノート検索
# 上の「パス解決」の手順で vault.paths.env を読み込んでおくこと
# -c で「言及回数」を数え、回数の多い順に並べる。-l + head だと
# ディレクトリの走査順に先頭 20 件を取るだけで、関連度とは無関係になる
grep -rc --include="*.md" --exclude-dir=".*" \
"<企業名>\|<英略称>\|<別表記>" \
"${VAULT_ROOT}/" \
2>/dev/null | awk -F: '$NF>0' | sort -t: -k2 -rn | head -15
--include="*.md"と--exclude-dir=".*"は必須。付けないとプラグインの JS バンドル（数 MB）・エディタのセッション JSON・index のバックアップまで候補に入る（実測：ある企業名では命中バイトの 95% がこの種のゴミで、最大 4.9MB のmain.jsが候補に混ざっていた）。-lではなく-cを使い、言及回数で並べる。走査順の先頭 20 件では、企業名が 1 回出てくるだけの日記が上位に来て、その企業専用のノートが 20 位圏外に落ちる。回数順なら「その企業について書かれたノート」が自然に上位に来る。
[!important] ヒットしても全部は読まない（トークン紀律・必須） 上位から順にファイル名で絞り、読むのは最大 5 件。企業名が 1 回出てくるだけの日記・クリップ記事を全読すると、それだけで数万字を消費する。
- ファイル名とパスだけを見て、下の優先順位に当たるものを選ぶ。日付ベースのノート（日記・日次ブリーフ・週次レビュー）、クリップ記事、Inbox の候補メモ、
*_MOC.mdや*_index.mdのような目次ファイルは、タイトルに企業名が無ければ外す- 選んだファイルが 10k字を超える場合は全読せず、
grep -n "<企業名>" <file>で行を特定し、Readの offset/limit で該当箇所の前後だけ読む- 1 件読むごとに「この企業について新しい事実が得られたか」を判断し、得られなければ次は読まない
- 同業他社の企業分析レポートが上位に来るのは正常（セクション 8 の競合比較に使える）。ただし他社レポートも全読せず、比較に要る節だけ
grepで取る
読む優先順位：
- 個別研究ノート（
【個別企業研究】...md、【<企業名>】...md）— これは全読してよい - 説明会・OB 訪問メモ（タイトルに日付や「説明会」「Insight Day」を含むもの）— 一次情報なので優先
- 素材フォルダ（
${VAULT_SHUKATSU_DISTILL}/素材/配下）— 該当箇所のみ部分読み - 蒸留知識（
VAULT_SHUKATSU_CHISHIKI配下）— 該当企業への言及箇所のみ部分読み
[!important] Vault 優先原則 Web リサーチより vault 既存ノートを優先。ユーザーが OB 訪問・説明会で得た一次情報は、Web 情報より価値が高い。Web は最新トピック（最近の deal、組織変動、年収レンジ）の補完用に使う。
Step 3 — Web リサーチ
references/style-guide.md の「Web リサーチのクエリ設計」に従い、**最低 3 回（最大 5 回）**実行する。静的な部門・事業構造は WebSearch で取らず、Step 5 の公式ページ取得（references/division-section.md の手順）に一本化する。
Step 4 — 情報不足時のユーザー確認（オプション）
以下が vault・Web いずれにもない 場合は必ずユーザーに確認：
- 直近の説明会・OB 訪問で得た非公開情報
- ユーザーの志望部門（IBD / Markets など、戦略を変える要素）
- ユーザーが既に持っている独自の強み・経験（差別化材料）
確認が不要なら、Step 5 へ直行。
Step 5 — レポート生成（フル版 12 セクション / 極簡版 5 セクション）
書式サンプル：references/report-skeleton.md
書式規約：references/style-guide.md
セクション 4 の詳細：references/division-section.md
[!danger] 過去のレポートを「書式の参考」として読まない 既存の企業分析レポートは 1 本 20〜46k字ある。書式を真似るためだけにこれを全読すると、それだけで 3〜4 万トークンを消費する（しかも書式の情報は
report-skeleton.mdとstyle-guide.mdに既に書いてある）。 既存レポートの構成を確認したいときは見出しだけを取る：grep -n "^#\{2,3\} " <既存レポート>。 既存レポートの中身を読んでよいのは、①同じ企業の更新時（差分更新の判断）②競合比較で他社レポートの該当節だけを部分読みするとき——いずれもgrepで節を特定してから部分読みする。
ファイル名
【<企業名>】企業分析レポート.md
例：【ゴールドマン・サックス】企業分析レポート.md / 【三菱商事】企業分析レポート.md / 【マッキンゼー】企業分析レポート.md
Frontmatter（Properties）
---
company: <正式社名>
company_en: <English Name>
tier: <S / A / B>
industry: <業界分類>
country: <親会社国 / 日本拠点>
hq_japan: <日本本社住所>
founded_japan: <日本拠点設立年>
employees_japan: <日本従業員数>
parent_global: <親会社名>
ceo_japan: <日本代表者>
report_type: 企業分析レポート # 極簡版なら 極簡版
target_year: <27卒・28卒 等>
generated: <YYYY-MM-DD>
sources: Web / Vault素材
tags:
- 就活
- <業界タグ>
- <企業短縮タグ>
related:
- "[[<関連ノート 1>]]"
- "[[<関連ノート 2>]]"
---
必須 12 セクション（フル版）
極簡版（--min）の場合は「起動フロー」の表にある 5 セクションだけを書き、以下の 4・5・6・11 はフル版と同じ密度で書く。
各セクションは 必ず以下の順番で生成する。情報が不足する場合は「（情報不足：要 OB 訪問 / 公式 IR 確認）」と明記して空欄にせず、ユーザーが後で埋められるようにする。
- タイトル + 一言で言うと callout + 使い方 tip — TL;DR を
> [!success]で 1 段落 - 会社概要テーブル — 設立・親会社・代表者・人員規模・主要事業
- 日本市場における位置づけ — 業界順位、最新トピック（
> [!important]）、戦略の重心 - 部門・職種マップ（業務詳説） —
references/division-section.mdの構造を厳守（3 層ピラミッド Mermaid + 全部門一覧表 + 協働シナリオ 3 例 → 各部門サブセクション → 部門サマリー比較表） - 採用フロー — Mermaid
flowchart+ スケジュールテーブル - 企業理念・求める人材像 — 冒頭に 企業理念／パーパス／コアバリュー（公式原文を
> [!quote]で引用）と 公式の「求める人物像」（採用ページ原文を> [!quote]で引用、無ければ「公式の明示なし」と明記）を必ず置く。その後に 5 つの核 + 落選 / 内定の差分テーブル +> [!danger]致命傷 + 理念をES・面接にどう使うかの> [!tip] - 年収・キャリアパス — 役職別テーブル + Mermaid 昇進フロー
- 競合比較 — 同業 2-3 社とのテーブル比較 +
> [!quote]差別化志望理由 - 内定者の共通パターン — Vault 蒸留データから 5 つ抽出、学歴傾向、強み事例
- ES 攻略法 — 典型設問 + 4 段式テンプレ +
> [!danger]雷区 - 面接対策 — 想定質問 TOP 15（カテゴリ分け）+ 圧迫対策 + 逆質問 5 つ
- 一年間の準備プラン — Mermaid
gantt+ 月別 To-Do
- 加えて FAQ + 関連ノート Wikilinks + 情報源 + メンテナンス note をフッターに
セクション 6（理念・求める人物像）と セクション 4 の部門節は
/es-coachが添削時に読む参照元。ここが薄いと ES 添削の企業適合評価ができなくなるので手を抜かない。
Step 6 — 保存と報告
ファイルを $VAULT_KIGYOU_REPORTS/【<企業名>】企業分析レポート.md（レジストリ解決）に保存後、以下を報告：
[保存完了]
パス: <絶対パス>
[サマリー]
- 企業: <正式社名> (tier: <S/A/B>)
- 業界: <業界分類>
- 形式: フル版（12 セクション）/ 極簡版（5 セクション）
- Vault 参照: <N 件のノートを参照>
- Web ソース: <M 件のリンク>
[ハイライト 3 点]
1. <最も重要な発見 1>
2. <最も重要な発見 2>
3. <最も重要な発見 3>
[次のアクション提案]
- このレポートを基に ES を書くなら → `/es-coach` 起動
- 面接対策レポートを作るなら → `/mensetsu-report`
- 関連企業も同形式で作るなら → `/kigyou-report <競合名>`
既存レポートの更新ルール
同名ファイル 【<企業名>】企業分析レポート.md が既に存在する場合：
- ユーザーに確認：「既存レポートが <更新日> にあります。①完全再生成 / ②差分更新（最新トピックのみ） / ③別ファイル名で新規作成、どれにしますか」
- 差分更新の場合：セクション 3（最新動向）、セクション 7（年収）、関連ノート、情報源のみ更新
- 完全再生成の場合：旧ファイルを
.archive/【<企業名>】企業分析レポート_<旧YYYY-MM-DD>.mdにバックアップしてから上書き
エッジケース
- 新興スタートアップ等で公開情報が薄い場合：5 セクション簡易版（概要 / 事業 / 採用 / 強み / 想定質問）に縮退、frontmatter に
report_type: 簡易版と明記。情報不足による縮退なので、意図的に軽く作る--min（極簡版）とは別物 - 業界が不明な場合：先にユーザーに業界分類（金融 / 商社 / コンサル / IT / メーカー / その他）を確認
- 企業が複数の名称を持つ場合（例：「三井住友銀行」と「SMBC」）：正式名称をファイル名に、frontmatter に
aliases:で別名を列挙