Claude Coworkで案件の進捗状況を日次レポートする

はじめに

プロジェクトマネージャーの朝は、日次レポートの作成から始まることが少なくありません。
WBSを開き、進捗率の変化を読み取り、前日との差分を整理し、遅延やリスクを洗い出す。さらに、それを読み手に伝わる形式でドキュメントにまとめる。1案件あたり30分〜1時間、複数案件を抱えていれば、それだけで午前中が終わってしまうこともあります。
この作業は重要ですが、定型的でありながら判断を要するという厄介な性質を持っています。単純作業とも言い切れないため、自動化が難しいと思われがちです。
しかし、Claude Coworkを使えば、フォルダを渡して一言指示するだけで、WBSの読み取りからレポート生成、セルフレビューまでを一気に完了できます。

前回の記事では、Claude Coworkの基本と「作業を任せる」という考え方を紹介しました。本記事ではその実践編として、再利用可能なフォルダ構成とCONTEXT.mdの設計パターンを具体的に紹介します。この仕組みを一度つくれば、毎日の日次レポートを「一言で生成」できる状態になります。

今回つくるもの

今回構築するのは、以下のようなワークフローです。

1. 人間が一言指示する（「ProjectAの日次レポートを作成して」）
2. Coworkがマスター CONTEXT.md を読み込む
3. プロジェクト別の CONTEXT.md を読み込む
4. 直近レポートと WORKLOG.md を確認する
5. WBS（Excel）を分析する
6. レポート（Word .docx）を生成する
7. 品質基準に基づいてセルフレビューする
8. WORKLOG.md に実行ログを追記する

ポイントは、人間が行うのはステップ1だけという点です。残りはすべて、フォルダ内のCONTEXT構造によって自動的にガイドされます。つまり、「毎回プロンプトを書き直す」必要がなく、フォルダを渡すだけで同じ品質のレポートが生成されます。

フォルダ構成

この仕組みの土台となるのが、以下のフォルダ構成です。

ProjectManagement/
├── CONTEXT.md                    # マスターCONTEXT（共通ルール）
├── ProjectA/
│   ├── CONTEXT.md                # プロジェクト別CONTEXT
│   ├── 00_Management/
│   │   └── WBS.xlsx              # 進捗管理表
│   ├── 10_Report/
│   │   └── 20260306-project-report.docx
│   └── WORKLOG.md                # 実行ログ
└── ProjectB/
    ├── CONTEXT.md
    ├── 00_Management/
    │   └── WBS.xlsx
    ├── 10_Report/
    └── WORKLOG.md

設計思想は3つあります。
1. 2層CONTEXT構造
ProjectManagement/CONTEXT.md（マスター）と ProjectA/CONTEXT.md（プロジェクト別）の2層に分けています。マスターには「どう作業するか」、プロジェクト別には「何に注目するか」を書きます。プロジェクトが増えても、マスターCONTEXTは共通で使い回せます。
2. 番号付きフォルダ
00_Management、10_Report のように番号を付けることで、フォルダの役割と処理順序が直感的にわかります。Coworkがフォルダを走査する際にも、構造を把握しやすくなります。
3. スケーラビリティ
ProjectB、ProjectC と案件が増えても、同じフォルダ構成をコピーして CONTEXT.md を書き換えるだけで対応できます。

CONTEXT.mdの設計

この仕組みの核心は、CONTEXT.mdの書き方にあります。ここでは、マスターCONTEXTとプロジェクトCONTEXTの設計を、実際のファイルから抜粋して解説します。

マスターCONTEXT

ProjectManagement/CONTEXT.md は、Coworkに「作業の仕方」を指示する共通ルールです。
まず、作業順序を明確に定義しています。

## 必須の作業順序
1. この `ProjectManagement/CONTEXT.md` を読む
2. ユーザーが指定した `<ProjectName>/CONTEXT.md` を読む
3. `<ProjectName>/10_Report/` を確認し、直近のレポートを読む
4. `<ProjectName>/WORKLOG.md` を読む
5. `<ProjectName>/00_Management/WBS.xlsx` を読む
6. レポートを新規作成する
7. レポート内容を自己レビューする
8. `<ProjectName>/WORKLOG.md` を更新する

この順序を定義することで、Coworkは「何をどの順番で処理するか」を迷わずに実行できます。
次に、WBSの読み取りルールを具体的に指定しています。

### 進捗の解釈
- `実績進捗率 = 0` → 未着手
- `0 < 実績進捗率 < 1` → 作業中
- `実績進捗率 = 1` → 完了
- `実績進捗率 < 予定進捗率`、または `進捗遅延 = 遅れ` の場合は遅れ候補とみなす
- `予定進捗率 = 0` でも `実績進捗率 > 0` の場合は、先行着手として扱う

数値の解釈ルールを明示することで、Coworkが「進捗50%」を見たときにどう判断すべきかが一意に決まります。
また、障壁キーワードもリスト化しています。

### 障壁・リスクの解釈
`備考` に以下のような語がある場合は、障壁・依存関係・未解決論点として候補抽出する。

- 待ち
- 確定待ち
- レビュー待ち
- 調整中
- 改善中
- 論点
- 未着手
- 確認中

さらに、レポートの品質レビュー基準と禁止事項も定めています。

## 品質レビュー基準
- WBSの数値と矛盾していないか
- 昨日までの進捗と今日の予定が混ざっていないか
- 障壁が「事実」として書かれているか
- 遅れだけでなく、前倒し着手や順調な点も拾えているか

## 禁止事項
- WBSの内容を勝手に改変しない
- 根拠がない進捗差分を作らない
- ユーザー未指定のプロジェクトを対象にしない

このように、「やるべきこと」だけでなく「やってはいけないこと」を明記することで、出力の品質が安定します。

プロジェクトCONTEXT

ProjectA/CONTEXT.md は、そのプロジェクト固有の「注目すべきポイント」を定義します。

## プロジェクト概要
ProjectA は、社内問い合わせやFAQ、文書要約などを支援する
AI チャット系業務システムの構築プロジェクトである。

## このプロジェクトで重要視する観点
日次レポートでは、特に以下を重視すること。

1. 予定に対する進捗差
2. 実装着手の前倒し・後ろ倒し
3. 依存関係による停滞
4. 安全性・レビュー待ち・仕様未確定の論点
5. 直近1週間に完了予定の作業の見通し

そして、プロジェクト固有の注目すべき信号を定義しています。

## このWBSで特に注目すべき信号
以下のような記述は、重要な障壁または論点として扱う。

- ネットワーク設定待ち
- API仕様確定待ち
- レビュー待ち
- 最終確定待ち
- 安全制御改善中
- 監視項目の定義待ち

マスターCONTEXTにも汎用的な障壁キーワードはありますが、プロジェクトCONTEXTではそのプロジェクト特有の表現を追加しています。「API仕様確定待ち」「安全制御改善中」といった語は、このプロジェクトのWBSに実際に出現するキーワードです。
このように、マスター＝「作業の仕方」、プロジェクト＝「何に注目するか」という役割分担が設計の原則です。

生成されるレポートの実例

実際にCoworkが生成したレポート（ProjectA/10_Report/20260306-project-report.docx）の内容を紹介します。
レポート冒頭の全体サマリーには、WBSから読み取った定量情報が整理されます。

このサマリーにより、PMは一目で「全体は計画より進んでいる」と判断できます。
レポート本文では、CONTEXT.mdで指定した視覚的なフォーマットが適用されます。

• 赤系：障壁・遅延タスク（例：プロンプト設計 — 実績70% vs 予定75%、本日期限）
• 緑系：順調・先行着手タスク（例：前倒し着手6件）
• 黄色：要注意（例：期限が近いが未確定の項目）
• グレー：完了済みタスク

このように、CONTEXT.mdに書いた「視覚的な強調ルール」がそのままWord文書に反映されます。フォーマットの指示も毎回不要です。

WORKLOGで再現性を確保する

日次レポートを「一度きり」ではなく「毎日繰り返す」仕組みにするために、WORKLOG.md を活用しています。
WORKLOGは、Coworkが作業を完了するたびに自動で追記する実行ログです。次回の実行時に、Coworkはこのログを読み込み、「前回何を確認したか」「前回のレポートで何を報告したか」を把握したうえで差分を抽出します。
実際のWORKLOGエントリは以下のような内容です。

## 2026-03-06

### 実施内容
- 参照したファイル: `ProjectManagement/CONTEXT.md`、`ProjectA/CONTEXT.md`
- 参照したファイル: `ProjectA/00_Management/WBS.xlsx`（基準日：2026年3月5日）
- 過去レポート: 存在なし（初回レポート）
- WORKLOG: 未記入（本日初回記入）

### 作成レポート
`ProjectA/10_Report/20260306-project-report.docx`

### 主要な所見（3行）
1. 全体の実績進捗率は40.7%（予定31.6%）と計画を9.1pt上回っており、
   前倒し着手タスクが6件ある。
2. プロンプト設計のみ遅延フラグあり（実績70% vs 予定75%）。
3. 依存未解決事項が7件あり、3月中旬以降の実装タスクへの波及リスクがある。

### 更新・作成ファイル
- `ProjectA/10_Report/20260306-project-report.docx`（新規作成）
- `ProjectA/WORKLOG.md`（本エントリ追記）

翌日Coworkを実行すると、このWORKLOGと前日のレポートを参照し、「昨日から何が変わったか」を正確に把握できます。これにより、毎日のレポートが積み重なるほど精度が上がる仕組みになっています。

効果的なCONTEXT.mdを書くためのポイント

ここまでの実例をふまえ、CONTEXT.mdを設計する際のポイントを整理します。日次レポートに限らず、Coworkに定型作業を任せる際に共通して使える考え方です。

これらのポイントを押さえることで、CONTEXT.mdは単なる「指示書」ではなく、AIへの引き継ぎ資料として機能します。人間が新しい担当者に業務を引き継ぐときと同じように、「作業手順」「判断基準」「注意事項」を構造化して伝えるイメージです。

まとめ

本記事では、Claude Coworkを使って案件の日次レポートを自動生成する仕組みを紹介しました。
振り返ると、この仕組みの核心はCONTEXT.mdにあります。作業順序、解釈ルール、注目キーワード、禁止事項——これらを構造化して書いておくことで、Coworkは「フォルダを渡すだけ」で期待通りの成果物を生成できるようになります。
CONTEXT.mdは、いわば「AIへの引き継ぎ資料」です。一度書けば、毎日の日次レポートに限らず、週次サマリーやリスク分析レポートなど、他の定型作業にも同じ設計パターンを応用できます。
Coworkの基本や「作業を任せる」という考え方については、前回の記事をご覧ください。

生成AI活用支援サービスのご紹介

Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。

1. 無料診断パック：業務・プロセスの現状を無料で診断し、生成AI活用の可能性をレポートします。
2. 検証（PoC）パック：診断で有効性が確認された業務を対象に、プロトタイプ構築を支援します。
3. コンサルティングサービス：生成AI導入戦略の策定から運用体制構築までを包括的に支援します。

生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。

執筆・編集

Tech Fun Magazine R&Dチーム

Tech Funの生成AI研究に携わるエンジニアが、最新のAIモデル動向やプロンプト設計、実業務への応用手法など、生成AIに特化した知見を執筆・編集しています。
モデル評価や業務シナリオに応じたAI活用設計など、日々のR&D活動で得られる実践的なノウハウをわかりやすく紹介します。