生成AI関連
Claude Coworkとは？AIに”作業”を任せるという選択肢
プロジェクトマネージャーの朝は、日次レポートの作成から始まることが少なくありません。
WBSを開き、進捗率の変化を読み取り、前日との差分を整理し、遅延やリスクを洗い出す。さらに、それを読み手に伝わる形式でドキュメントにまとめる。1案件あたり30分〜1時間、複数案件を抱えていれば、それだけで午前中が終わってしまうこともあります。
この作業は重要ですが、定型的でありながら判断を要するという厄介な性質を持っています。単純作業とも言い切れないため、自動化が難しいと思われがちです。
しかし、Claude Coworkを使えば、フォルダを渡して一言指示するだけで、WBSの読み取りからレポート生成、セルフレビューまでを一気に完了できます。
前回の記事では、Claude Coworkの基本と「作業を任せる」という考え方を紹介しました。本記事ではその実践編として、再利用可能なフォルダ構成とCONTEXT.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とプロジェクト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の内容を勝手に改変しない
- 根拠がない進捗差分を作らない
- ユーザー未指定のプロジェクトを対象にしない
このように、「やるべきこと」だけでなく「やってはいけないこと」を明記することで、出力の品質が安定します。
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から読み取った定量情報が整理されます。
| 指標 | 値 |
|---|---|
| 完了タスク | 13件 |
| 作業中タスク | 8件 |
| 未着手タスク | 16件 |
| 実績進捗率 | 40.7% |
| 予定進捗率 | 31.6% |
| 差異 | +9.1pt（前倒し） |
このサマリーにより、PMは一目で「全体は計画より進んでいる」と判断できます。
レポート本文では、CONTEXT.mdで指定した視覚的なフォーマットが適用されます。
このように、CONTEXT.mdに書いた「視覚的な強調ルール」がそのままWord文書に反映されます。フォーマットの指示も毎回不要です。
日次レポートを「一度きり」ではなく「毎日繰り返す」仕組みにするために、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を設計する際のポイントを整理します。日次レポートに限らず、Coworkに定型作業を任せる際に共通して使える考え方です。
| # | ポイント | 説明 | 例 |
|---|---|---|---|
| 1 | 作業順序を最初に定義する | Coworkが迷わず実行できるよう、ステップを番号付きで記載する | 「1. CONTEXTを読む → 2. WBSを分析 → 3. レポート生成」 |
| 2 | 情報の優先順位を明示する | 複数の情報源がある場合、どれを優先するかを順位付けする | 「定量情報はWBS優先、差分把握は過去レポート優先」 |
| 3 | 解釈ルールを具体的に書く | 数値や状態の「読み方」を一意に定義する | 「進捗率0%＝未着手、0〜100%＝作業中、100%＝完了」 |
| 4 | リスクキーワードを列挙する | 注目すべき語句をリスト化し、検出精度を上げる | 「待ち、確定待ち、レビュー待ち、調整中」 |
| 5 | 禁止事項を明記する | やってほしくないことを明示し、出力品質を安定させる | 「WBSの内容を改変しない」「根拠なしに断定しない」 |
| 6 | 事実と推定を分ける | 断定していいことと推定に留めるべきことの基準を示す | 「差分が確認できない場合は"現時点の状況"として記載」 |
| 7 | 読み手を意識する | 誰がレポートを読むかを明記し、トーンや粒度を調整する | 「読み手はPMとチームリーダー」 |
これらのポイントを押さえることで、CONTEXT.mdは単なる「指示書」ではなく、AIへの引き継ぎ資料として機能します。人間が新しい担当者に業務を引き継ぐときと同じように、「作業手順」「判断基準」「注意事項」を構造化して伝えるイメージです。
本記事では、Claude Coworkを使って案件の日次レポートを自動生成する仕組みを紹介しました。
振り返ると、この仕組みの核心はCONTEXT.mdにあります。作業順序、解釈ルール、注目キーワード、禁止事項——これらを構造化して書いておくことで、Coworkは「フォルダを渡すだけ」で期待通りの成果物を生成できるようになります。
CONTEXT.mdは、いわば「AIへの引き継ぎ資料」です。一度書けば、毎日の日次レポートに限らず、週次サマリーやリスク分析レポートなど、他の定型作業にも同じ設計パターンを応用できます。
Coworkの基本や「作業を任せる」という考え方については、前回の記事をご覧ください。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。
