Claude Codeでレポート粒度を相手別に変換｜経営/部門/現場の3粒度を1ファクトから生成する実装レシピ

同じ案件の進捗を、経営会議向けに3行、部長会議向けに半ページ、現場朝会向けに口頭の箇条書き——PMは1週間に何回も「同じ内容の粒度違い」を書き直しています。情報が増えるからではなく、相手によって伝える深さと文脈が違うからです。

「AIで書き直させればいい」と聞きますが、そのまま依頼すると粒度がぶれ、伝わるものが伝わらなくなります。本当に効くのは、Skillで「経営／部門／現場」の3粒度テンプレを固定し、1ファクトから3粒度を一括生成する運用です。

この記事では、Claude Codeでレポート粒度変換を半自動化する実装を、現場で動かせる粒度で解説します。

なぜ「粒度違い」は時間を食うのか

同じ事象を3回書き直すのが時間を食うのは、再現性の問題です。

粒度の判断軸がぶれる：経営向けは「投資判断材料」、部門向けは「リソース配分」、現場向けは「明日のアクション」と相手のニーズが違う
テンプレが個人依存：PMごとに章立てが違い、読み手が学習コストを払う
過去報告との整合が取れない：「先週はこう書いたが今週はこう」とトーンがブレる

Claude Codeは、Skillで3粒度のテンプレを固定し、1ファクトから3粒度を一括生成する運用を素直に組めます。

Claude Codeを「粒度変換器」にする全体像

必要な要素は次の3つです。

ファクトYAML：今週の事実情報（数値・出来事・判断）を構造化
粒度変換Skill：3粒度テンプレに従って自動生成、PMが手で校正
CLAUDE.md粒度ルール：経営／部門／現場それぞれのテンプレと禁則事項を明記

これが揃えば、PMはファクトYAMLを書くだけで、3粒度の報告ドラフトが一括で揃います。

ステップ1：ファクトYAMLを設計する

tmp/reports/{YYYY-MM-DD}-facts.yaml のように週次ファクトを構造化します。

project_id: "PROJ-2026-A"
week_of: "2026-04-27"
progress:
  spi: 0.92
  cpi: 0.95
  phase_completion:
    requirements: 1.0
    basic_design: 0.85
    implementation: 0.30
events:
  - type: "decision"
    summary: "認証方式をSAMLからOIDCへ変更"
    impact: "実装工数+10pd、外部APIコスト年額+200万"
  - type: "incident"
    summary: "ステージング環境で結合テスト中にDB接続エラー"
    impact: "テスト3日遅延"
  - type: "milestone"
    summary: "基本設計レビュー完了"
risks:
  - id: R-007
    update: "他システム連携の不整合リスクが顕在化"
next_week_focus:
  - "認証方式変更に伴う実装着手"
  - "結合テスト遅延リカバリ計画策定"

ファクトYAMLは「事実」だけを書く場所。解釈や所感は次のステップで粒度別に作ります。

ステップ2：粒度変換Skillを定義する

.claude/skills/report-translate/SKILL.md を作成します。

---
name: report-translate
description: tmp/reports/{date}-facts.yaml を読み、CLAUDE.mdの3粒度テンプレに従って tmp/reports/{date}-{audience}.md を一括生成する（audience: exec / division / team）
disable-model-invocation: true
allowed-tools: Read, Write
---

# レポート粒度変換Skill

## 入力
- `tmp/reports/{YYYY-MM-DD}-facts.yaml`

## 処理
1. ファクトYAMLを読み込む
2. 3粒度（exec / division / team）のテンプレに従って3ファイル一括生成
   - exec: 経営向け、A4 1/3ページ、投資判断材料に絞る
   - division: 部門向け、A4 1ページ、リソース配分材料を含む
   - team: 現場向け、口頭読み上げ用、明日のアクションを箇条書き
3. 各粒度で「禁則事項」を反映（CLAUDE.md参照）
4. PMコメント欄は **空欄** で出力

## 出力フォーマット
- exec: `tmp/reports/{date}-exec.md`
- division: `tmp/reports/{date}-division.md`
- team: `tmp/reports/{date}-team.md`

## 厳守
- 数値はファクトYAMLそのままを使い、加工しない
- 解釈・所感はAIが書かず、PMコメント欄を空けて返す
- 過去報告のトーンを引用しない（独立に生成）

「数値を加工しない」が安全装置。AIが勝手に「概ね順調」「やや遅延」と判断すると、経営報告のトーンがPMの意図と乖離します。

ステップ3：CLAUDE.mdに粒度ルールを書く

## レポート粒度変換ルール

### 経営向け（exec）テンプレ
- 投資判断に直結する数値を優先（コスト・スケジュール・主要リスク）
- インシデントは「事業影響」の文脈で説明
- 文章は1段落＋箇条書き3〜5行
- 禁則：技術用語、固有名詞の細かい説明、現場の苦労話

### 部門向け（division）テンプレ
- リソース配分判断に必要な情報を含む（要員稼働、他案件影響）
- 章立て：①サマリー ②進捗指標 ③主要イベント ④リスク ⑤次週の重点
- 文章は段落構成、A4 1ページ
- 禁則：経営判断に関わる戦略示唆（部長権限を超える内容は書かない）

### 現場向け（team）テンプレ
- 明日のアクションが見える形式
- 章立て：①今週のハイライト ②明日からのToDo ③相談したいこと
- 口頭読み上げ前提のため、句点で短く区切る
- 禁則：抽象的な経営トーン（「順調に推移」など現場で意味のない表現）

### 共通の運用
- 解釈・所感はPMが手で書く
- 数値は必ずファクトYAMLそのまま
- レポート間で同じ事実を矛盾なく語る（粒度変換は内容変更ではない）

「禁則事項」を粒度ごとに明記するのが運用の核心。AIが書きがちな「無難な経営トーン」を現場用に持ち込むと、現場の信頼を失います。

ステップ4：実際の運用フロー

毎週金曜の運用は次の通りです。

金曜午前：PMが tmp/reports/{date}-facts.yaml にファクトを書く（30分）
金曜午後：/report-translate で3粒度ドラフトが一括生成される
金曜夕方：3粒度それぞれのPMコメント欄を埋める（15分×3=45分）
月曜朝：経営向けは月曜午前のステアリングに、部門向けは月曜午後の部長会議に、現場向けは月曜朝会で読み上げ

合計で2時間弱。これまで4〜5時間使っていたPMには、月曜の朝会前に余裕が生まれます。

期待効果と運用上の注意点

導入チームから報告される効果は3点です。

粒度違いの書き直し時間が4時間→2時間：ファクトを1度書けば3粒度が揃う
報告のトーンが安定する：テンプレが固定され、読み手が学習コストを払わなくて済む
粒度間の矛盾が起きにくい：同じファクトを参照するため、内容のブレが消える

落とし穴は3つ。

解釈・所感をAIに書かせない：これを許すと経営トーンが薄まる
テンプレを頻繁に変えない：四半期ごとの見直しに留める
ファクトYAMLの精度に投資する：ここがブレると3粒度すべてがブレる

まとめ

レポート粒度変換は3粒度のニーズを分離することで再現可能化できる
ファクトYAMLを単一ソースにし、Skillで3粒度を一括生成する仕組みが現実解
解釈・所感は粒度別にPMが書く（AIに任せない）
「禁則事項」を粒度ごとに明記すると、報告のトーンが守られる

ここまでで「動く粒度変換器」は手に入ります。実務でこれを“信頼される報告運用”に育てるには、報告戦略、ステークホルダー別のメッセージング、定型化と例外運用の使い分けといった上位設計が必要です。

AIX-101『仕様書・報告書・議事録』と MGR-101『PMのリーダーシップ』を組み合わせると、本記事のSkillをベースに、報告書設計とリーダーとしての伝え方を体系で学べます。「同じ内容を粒度違いで何度も書き直す」PMが、最短で“仕組みで伝える運用”に到達するための導線です。