Claude CodeをPM補佐にする 情報集約 × スキル3本の設計パターン

Claude CodeをPM補佐にする 情報集約 × スキル3本の設計パターン

Claude Code を活用してプロジェクトのタスク管理業務を半自動化した事例をご紹介します。 複数のツールに分散した情報を一元管理し、会議後の転記作業を効率化する仕組みを実装しました。
2026.05.15

AI事業本部/西日本開発チームの片桐です。
今回は、Claude Code を活用してプロジェクトのタスク管理業務を半自動化した事例をご紹介します。

この記事について

[対象読者]

  • Claude Code を使って業務を効率化したい方
  • 複数プロジェクトのPM運用をしており、情報の分散に悩んでいる方
  • 複数のツールにある情報を一元管理したい方
  • コンテキストエンジニアリング(AIに渡す情報の質・範囲を設計する考え方)に興味がある方

私が考えたClaude Code活用の運用設計

この構成を考えるにあたり、以下の2記事がとても参考になりました。
プロジェクト情報をAIが参照しやすい形で整理する考え方(コンテキストエンジニアリング)と、ワークスペースを起点に日々のフローを設計するアプローチ、どちらも今回の設計のベースになっています。

業務の中では、プロジェクトごとに連絡ツールが異なったり、データの保存場所が違ったりして、状況把握に時間がかかることがあります。

Claude Code は、与えられたコンテキストをもとにドラフト作成やタスク整理を行うことができます。
一方で、情報が散在したままだと、手動で情報を集めない限り、散在した情報を踏まえたドラフト作成やタスク整理を安定して行うことができません。

私が解決した課題

1. 情報が各ツールに分散して追いにくい

例としてコミュニケーションは Teams、議事録は Meet の文字起こし、タスク管理は Backlog のように分散すると、探すだけで時間がかかります。
最初に inbox/ へ集約することで、確認導線を短くしています。

2. 会議後の転記作業が重い

議事録整形、アクション抽出、タスク化は定型業務ですが、手作業だと負担が大きくなります。
Claude Code に初稿生成を任せて、人間は判断と修正に集中する運用にしました。

3. プロジェクトごとに運用ルールがぶれやすい

命名規則や保存場所がプロジェクトごとに異なると、引き継ぎコストが増えます。
CLAUDE.md で共通ルールを定義することで、横展開しやすくしています。


そこで、プロジェクトごとの情報を1つのフォルダにまとめ、Claude Code や AI エージェントが参照しやすい形で運用する構成にしました。

ディレクトリ構成は以下です。

my-pm-system/
  ├── CLAUDE.md                         # 全体ルール・プロジェクト一覧
  ├── .claude/
  │   ├── skills/                       # スキル定義
  │   └── hooks/                        # フック定義
  ├── .mcp.json                         # MCP サーバー設定
  ├── _templates/                       # 複製元テンプレート(プロジェクトタイプ別)
  │   ├── project/                      #   標準プロジェクト
  │   ├── internal/                     #   社内プロジェクト
  │   └── research/                     #   調査・検証プロジェクト
  └── <project-x>/                      # プロジェクト単位
      ├── CLAUDE.md                     # プロジェクト固有情報(データソース設定など)
      ├── core/                         # 概要情報
      │   ├── summary.md                #   プロジェクト概要・メンバー
      │   └── phases.md                 #   フェーズ・進捗
      ├── tasks/                        # タスク
      │   ├── backlog.md                #   バックログ
      │   └── 2026-W20.md               #   週次タスク(YYYY-Www)
      ├── minutes/                      # 議事録(YYYY-MM-DD 単位)
      │   └── 2026-05-13.md
      ├── inbox/                        # 外部ソース取り込み
      │   ├── meet-2026-05-13.md        #   Meet 文字起こし
      │   ├── slack-project-x-...md     #   Slack 取得結果
      │   └── gmail-2026-05-13.md       #   Gmail 取得結果
      ├── communications/               # 連絡ツールログ(mail / slack)
      ├── docs/                         # プロジェクトドキュメント
      ├── templates/                    # メール・メッセージ雛形
      └── dashboard/
          └── index.html                # プロジェクト進捗表示(HTML)

この構成の狙いは、プロジェクト運用に必要な情報を役割ごとに分離し、更新フローを固定化することです。
具体的には、外部情報は inbox/、意思決定ログは minutes/、実行管理は tasks/、前提情報は core/、コミュニケーション履歴は communications/、補足資料は docs/、定型文は templates/に集約します。
dashboard/ には HTML でダッシュボードを作成することで、プロジェクトの状況を人が視覚的に把握しやすくしています。

再現に必要な最小構成

ここからは、実際に手元で試せる最小構成に絞って説明します。
ポイントは「運用ルール」「収集・整理・可視化のスキル」「受け皿となるディレクトリ」の3点を先に揃えることです。

最低限、以下を用意すれば動かし始められます。

  1. ルート CLAUDE.md(運用ルールとガードレール)
  2. .claude/skills/ の3スキル(sync-sources / gen-minutes / gen-dashboard
  3. 1プロジェクト分の inbox/, minutes/, tasks/, dashboard/ ディレクトリ

次のセクションでは、まず土台になる CLAUDE.md の最小例を示します。

CLAUDE.md の実例(最小版)

実運用では項目は増えますが、最初は以下で十分です。
ここで使う YAML Frontmatter は、AI やスクリプトがプロジェクトのメタ情報を安定して読み取るための共通フォーマットとして使います。

---
status: ACTIVE
project: project-x
owner: katagiri
---

# PM システムルール(最小版)

## グローバルルール
- ドキュメントは Markdown + YAML Frontmatter
- タスクステータスは `TODO` / `IN_PROGRESS` / `DONE` / `PENDING`
- 週次タスクは `tasks/YYYY-Www.md`
- 議事録は `minutes/YYYY-MM-DD.md`
- 外部取得データは `inbox/` に保存(例: `slack-`, `meet-`, `gmail-`

## AI運用ルール
- 外部送信(メール送信、予定登録、チケット更新)は必ずユーザー確認を取る
- 未確定情報は `PENDING` で記載し、推測で埋めない
- 秘匿情報をリポジトリや同期フォルダに保存しない

CLAUDE.md は「AIへの指示書」兼「運用手順書」です。
これがないと、スキルの出力品質やファイル更新の一貫性が安定しません。

実運用ではこう拡張していく

最小版から始めて、プロジェクト数や利用ツールが増えるにつれて、ルートの CLAUDE.md には以下のような項目を追加していきます。

ルート CLAUDE.md の拡張例
## プロジェクト一覧

| フォルダ        | プロジェクト名 | ステータス |
| ----------- | ------- | ------ |
| _templates  | (複製用テンプレート) | -      |
| project-a   | プロジェクトA   | ACTIVE |
| project-b   | プロジェクトB   | ACTIVE |

## 利用可能なスキル

| スキル                    | 用途                          |
| --------------------- | --------------------------- |
| `/new-project`        | 対話式で新プロジェクトをセットアップ              |
| `/sync-sources`       | 外部ソース取得 → `inbox/` に保存       |
| `/gen-minutes`        | Meet 文字起こし → 議事録 + ToDo 生成   |
| `/gen-dashboard`      | `dashboard/index.html` 再生成 |
| `/weekly-report`      | 週次レポート生成                    |

## 接続中の MCP サーバー

- **Google Calendar / Gmail / Drive**: カレンダー参照・Gmail・Drive操作
- **teams**: Microsoft Teams チャット
- **backlog**: Backlog プロジェクト管理
- **slack**: チャンネル読み取り・下書き作成

## Slack 操作ルール

1. 現在のプロジェクト `CLAUDE.md` の「データソース設定」に書かれたチャンネルを優先
2. 複数該当する場合は操作目的に合うものをユーザーに確認
3. 未設定の場合は DM を使わずユーザーに確認
4. DM はユーザーが明示的に指示した場合のみ

一方、プロジェクトごとの CLAUDE.md には、sync-sources が参照する データソース接続情報 を書きます。

プロジェクト別 CLAUDE.md のデータソース設定例
---
status: ACTIVE
project: project-x
owner: katagiri
---

# project-x

## データソース設定

### Gmail
- 検索クエリ: `from:client@example.com OR subject:"project-x"`

### Google Drive(Meet 文字起こし)
- フォルダID: `1AbCdEf...`

### Teams
- チャンネル: `project-x-general`

### Backlog
- プロジェクトキー: `PROJX`

### Slack
- チャンネル: `#project-x-pm`

sync-sources 実行時は、このセクションを読み込んで各ツールへのアクセス条件を決定するため、プロジェクトごとの設定はここに集約しておくと運用がブレません。

Skills の実例

スキルの概念や設定方法については前回の記事をご参照ください。
今回は、最小運用で使う3つのスキル(収集・整理・可視化)を紹介します。

スキル定義は .claude/skills/<skill-name>/SKILL.md に配置します。
冒頭のYAML Frontmatterで以下の項目を指定することで、Claude Codeがスキルを認識し、適切なタイミングで呼び出せるようになります。

  • name: スキル名(呼び出し時の識別子)
  • description: スキルの概要(Claude Codeが「使うべきか」を判断する手がかり)
  • when_to_use: 想定する利用シーン
  • user-invocable: true にするとユーザーから /<skill-name> で直接呼び出せる
  • allowed-tools: スキル実行時に許可するツール群

呼び出し方は、Claude Codeに自然言語で指示(例: 「sync-sources を実行して」)するか、user-invocable: true のスキルなら /sync-sources のようなスラッシュコマンドが利用できます。

以下は最小例で、実運用ではより詳細な手順を記述します。

1) sync-sources スキル例

外部ツールから情報を収集し、inbox/ に統一形式で保存するスキルです。

sync-sources スキル定義の例
---
name: sync-sources
description: Meet / Teams / Gmail / Backlog / Slack を取得して inbox/ に Markdown 保存する
when_to_use: 朝のルーティン時、またはミーティング後に外部情報を取り込みたいとき
user-invocable: true
allowed-tools: [Bash, Read, Write]
---

## 実行手順

1. 起動位置からスコープを判定する(プロジェクト / ルート)
2. 各プロジェクトの `CLAUDE.md` からデータソース設定を読み込む
3. 各ソース(Gmail / Meet / Teams / Backlog / Slack)を並列で取得し、`inbox/<source>-YYYY-...md` に保存する
4. 取得件数とスキップ理由をサマリー表示する

## 重要

- 取得済みファイルは上書きしない(同名なら `-2`, `-3` のサフィックスを付ける)
- 機微情報(パスワード・個人情報など)を含むデータは要約のみ残す

2) gen-minutes スキル例

inbox/ に集まった会議メモを議事録形式に整形するスキルです。

gen-minutes スキル定義の例
---
name: gen-minutes
description: inbox/ の Meet 文字起こしから議事録とアクションアイテムを生成する
when_to_use: Google Meet ミーティング後に議事録化したいとき
arguments:
  - name: date
    description: 対象日付(YYYY-MM-DD)。省略時は最新の meet-*.md を使用
    required: false
user-invocable: true
allowed-tools: [Read, Write, Edit]
---

## 実行手順

1. 入力ファイルを決定する(`date` 指定があれば `inbox/meet-${date}.md`、なければ最新の `meet-*.md`
2. `core/summary.md``CLAUDE.md` を読み込んでコンテキストを補完する
3. 文字起こしから「議題」「決定事項」「アクションアイテム」「懸念事項」を抽出する
4. `minutes/YYYY-MM-DD.md` に Frontmatter 付きで保存する
5. 週次タスクファイル(`tasks/YYYY-Www.md`)にアクションアイテムを追記し、ユーザー確認を取る

## 重要

- 推測で補完しない(聞き取り不明瞭な箇所は「※聞き取り不明瞭」と明記)
- 顧客発言は改変しない

3) gen-dashboard スキル例

タスク・議事録の状態を集約して、ブラウザで確認できるHTMLを生成するスキルです。

gen-dashboard スキル定義の例
---
name: gen-dashboard
description: tasks/・minutes/・core/ から dashboard/index.html を再生成する
when_to_use: ダッシュボードを最新データに更新したいとき
user-invocable: true
allowed-tools: [Read, Write, Bash]
---

## 実行手順

1. プロジェクト層で起動されているか確認する(プロジェクト層でなければ中断)
2. `tasks/` `minutes/` `core/` `CLAUDE.md` を読み込む
3. ヘッダー(プロジェクト名・現フェーズ)、タスクサマリー、直近議事録、進捗ゲージ、PENDING 警告を生成する
4. `dashboard/index.html` に書き出す

## 重要

- 外部CDN依存は最小限にし、オフラインでも閲覧可能にする
- 個人情報・連絡先は含めない(タイトル・進捗・件数のみ)

この仕組みを使ってみる

手順1. プロジェクトの初期構成を作る

_templates/ 配下の雛形を <project-x>/ にコピーし、必要なディレクトリ(inbox/, minutes/, tasks/, dashboard/ など)とプロジェクト用 CLAUDE.md を生成します。
初期化用に /new-project のようなスキルを用意しておくと、プロジェクトタイプ(顧客向け / 社内 / 調査 など)に応じた雛形を選んで毎回同じ構成で立ち上げられます。

雛形の中身はプロジェクトタイプごとに異なります。例として標準(project)テンプレートは以下のような構成です。

project テンプレートの中身
_templates/project/
  ├── CLAUDE.md                    # データソース設定の雛形(PENDING 入り)
  ├── core/
  │   ├── summary.md               # プロジェクト概要
  │   └── phases.md                # フェーズ管理
  ├── tasks/
  │   └── backlog.md               # バックログ雛形
  ├── inbox/                       # 空ディレクトリ
  ├── minutes/                     # 空ディレクトリ
  ├── docs/                        # 空ディレクトリ
  ├── dashboard/
  │   └── index.html               # ダッシュボード雛形
  ├── templates/
  │   ├── mail-schedule-request.md
  │   ├── mail-progress-report.md
  │   └── mail-concern-report.md
  └── communications/
      ├── mail/                    # 空ディレクトリ
      └── slack/                   # 空ディレクトリ

new-project スキルのサンプルも紹介しておきます。

new-project スキル定義の例
---
name: new-project
description: 標準テンプレートを使って新規プロジェクトの初期構成を作成する
when_to_use: 新しいプロジェクトの管理を始めたいとき
arguments:
  - name: project-name
    description: プロジェクト名(ディレクトリ名としても使用)
    required: true
user-invocable: true
allowed-tools: [Bash, Read, Write, Edit]
---

## 実行手順

1. 引数 `project-name` が既存ディレクトリと衝突しないか検証する
2. プロジェクトタイプを対話的に選択させる(project / internal / research)
3. `_templates/<タイプ>/` の中身を `<project-name>/` にコピーする
4. `CLAUDE.md``project:` フィールドを引数の名前で置換する
5. データソース設定は `PENDING` のまま残し、後で手動補完する旨を案内する

Claude Code への入力例:

/new-project project-x

生成されるもの:

  • project-x/{inbox, minutes, tasks, dashboard, ...} ディレクトリ(雛形からコピー)
  • project-x/CLAUDE.md(データソース設定は PENDING の雛形が入る)

手順2. コネクタ/MCP で収集基盤を作り、inbox に集約する

作成したプロジェクトディレクトリに移動し、Claude Code を起動します。
その後、sync-sources スキルを実行すると、MCP やコネクタ経由で Meet、Slack、Gmail、Backlog の情報を inbox/ に取り込みます。

コネクタの設定は 公式ドキュメント を参照してください。

MCPやコネクタ設定後に下記のように入力することで、各種情報を集めてきます。

Claude Code への入力例:

sync-sources を実行して。対象: project-x、期間: 直近7日

生成されるもの(例):

inbox/
  gmail-2026-05-13.md            (3 通取得)
  meet-2026-05-13.md             (1 件取得)
  slack-project-x-2026-05-13.md  (12 件取得)
  backlog-2026-05-13.md          (5 チケット取得)

この「情報を集約する」工程をスキル化しておくことで、毎回同じ条件で収集でき、Claude Code が参照すべきコンテキストを安定して渡せるようになります。
ぜひご自分の環境に合わせて考えてみてください。

手順3. Skills を実行して議事録・ダッシュボードを更新する

情報収集完了後は、gen-minutes で議事録を生成し、gen-dashboard で可視化を更新します。

Claude Code への入力例:

議事録作成時
gen-minutes を実行して

生成されるもの(例):

  • minutes/yyyy-mm-dd.md(DRAFT 状態の議事録。アクションアイテムは tasks/yyyy-Wx.md に自動追記)

ダッシュボード作成時
gen-dashboard を実行して

生成されるもの(例):

  • dashboard/index.html(TODO / IN_PROGRESS / DONE 件数、直近議事録リンク、PENDING 警告を含む静的HTML)

実行例

この一連を定期的に回すと、「情報が集まるだけ」で終わらず、ドラフトの作成から視覚的にプロジェクト状況を把握できるページ作成まで、最小限の確認操作で実行できるようになります。

MTG日程調整のための下書きを作成させた例

「Googleカレンダーを参照して、日程調整メールを作成して」と指示をするだけで、カレンダーと前回の議事録などを参照し、下書きを作成してくれます。

SCR-20260515-knbc

頻繁に使う操作は、/schedule-meeting のように前述のスキルとしてまとめておくと、毎回同じ手順で再現できます。

生成されるダッシュボードイメージ

こちらは、プロジェクトごとに作成されるダッシュボードのイメージです。
タスクのステータス内訳、直近の議事録リンク、フェーズ進捗が一目で確認できる構成にしています。
SCR-20260512-ihqt

運用して分かった効果

この構成を実際に使ってみて、主に2つの変化がありました。

情報探索・転記の削減
以前は会議後に議事録の整形・アクション抽出・タスク起票を個別に手作業で行っていましたが、gen-minutes の実行で初稿生成まで自動化でき、確認・修正に集中できるようになりました。

引き継ぎコストの低減
保存先と命名ルールが統一されることで、メンバーの途中参加時に「どこに何があるか」を説明する手間が減りました。

一方で、AIの出力をそのまま確定情報として扱わない運用は欠かせません。
情報収集・タスク洗い出し・ドラフト作成までをAIに任せ、最終判断は人が行う形にしています。
Markdownでログを残しておくことで、あとから見直しや修正もしやすくなります。

注意点と対策

1. 秘匿情報は公開領域や同期領域に置かない

2. 送信・更新系の操作は人間確認を挟む

メール送信、予定登録、ステータス変更などは自動確定しない設計にします。
「下書きまで自動、確定は人間」の線引きが安全です。

3. 収集データ品質への依存を理解する

MCP やコネクタ経由のデータは欠損・遅延が起こり得ます。
取り込み結果を点検し、必要時に手動補完できる手順を残します。

おわりに

Claude Code を活用したタスク管理は、全自動化を目指す前に、「運用データを整える自動化」にフォーカスすることで効果が出やすいと感じています。
新機能もリリースされていますので、試しながら効果的な物があればブログにて紹介していきます!


生成AI活用はクラスメソッドにお任せ

過去に支援してきた生成AIの支援実績100+を元にホワイトペーパーを作成しました。御社が抱えている課題のうち、どれが解決できて、どのようなサービスが受けられるのか?4つのフェーズに分けてまとめています。どうぞお気軽にご覧ください。

生成AI資料イメージ

無料でダウンロードする

この記事をシェアする

関連記事