Claude CodeにPM業務を自動介入させる「PM Layer」の設計と実践
はじめに
前回の記事ではClaude Codeで第二の脳の作り方を紹介しました。その一部でClaudeにPMをやらせるということを紹介しましたが、今回はPMに焦点を当てて紹介したいと思います。
前回の記事はこちら：
https://qiita.com/yamapiiii/items/cc2450f410b64329d275
具体的には、以下を既存のワークフローに自動で介入させる仕組みを作りました。
- 新プロジェクト開始時に「なぜやるのか」「成功指標は何か」を自動で問いかける
- 週次レビューで全プロジェクトの健康状態を横断診断する
- 放置プロジェクトに対して「なぜ止まっているか」の仮説を出す
- タスク分解時に粒度・優先度・リスクを自動チェックする
この記事でわかること
- Claude CodeにPM業務を組み込む設計パターン
- PdM（What/Why）とPjM（How/When）の自動化の違い
-
pm_brief.mdの自動生成テンプレート - 実プロジェクトでの適用例（5 Whys、JTBD、RICE、リーンキャンバス）
対象読者
- PM/PdMでAIを業務に活用したい人
- 個人開発でプロジェクトが完走しない人
- Claude Codeの「コーディング以外の使い方」を探している開発者
Note: プロダクトマネジメントの全てを参考にして作りました
発想の原点：PM = コンテキストエンジニアリング
最近読んだ記事にこんな指摘がありました。
優秀なAIエージェント ≠ 全てを知っているAI
優秀なAIエージェント = 必要な情報に適切にアクセスできるAI
そしてこう続きます。
PMも同じ。全てを把握する必要はない。情報が流れる仕組みを作ることがPMの仕事。
これを読んで気づいたのは、私がGitリポジトリで運用している「第二の脳（brain）」は、まさにコンテキストエンジニアリングの基盤だということ。
brain リポジトリ
├── 20_Projects/ ← プロジェクトのWhy/What/意思決定ログ
├── 30_Tech_Notes/ ← 技術知識
├── 50_Business_Context/ ← ビジネス文脈
└── roadmap.md / GitHub Issues ← 計画と進捗
全てがテキストファイルで、Claude Codeが直接読み書きできる。コンテキストが常に最新で、AIがアクセスできる状態。
であれば、PM業務もClaude Codeに任せられるのでは？
PM Layerの設計思想
「/pm」コマンドを作らなかった理由
最初は /pm-check のようなコマンドを作ろうとしました。でもすぐにやめました。
❌ /pm を手動で呼ぶ = 結局自分がPMの仕事をしている
✅ 既存フローにPMが自動介入 = 本当に自律的
PMの仕事は「特定のタイミングで思い出してやるもの」ではなく、ワークフローの各所に自然に埋め込まれるべきものです。
PdM × PjM の分離
PM Layerは2つの役割を持ちます。
| 役割 | 視点 | 問い |
|---|---|---|
| PdM（プロダクト） | What / Why | このPJの「完了」とは？誰が喜ぶ？やらなかったらどうなる？成功をどう測る？ |
| PjM（プロジェクト） | How / When | 最初の1歩は？ブロッカーは？他PJとの競合は？1週間後の理想は？ |
個人開発だとこの2つが混ざりがちですが、意識的に分離することで「何を作るか迷って手が止まる」と「どう進めるか迷って手が止まる」を切り分けられます。
自動介入ポイント：5つのタイミング
PM Layerが介入するのは以下の5箇所です。
| タイミング | コマンド | PMがやること |
|---|---|---|
| プロジェクト化 | /new-project |
Why/What/成功指標を問い、pm_brief.md を自動生成 |
| タスク分解 | /decompose |
粒度・優先度・リスクを自動チェック |
| Issue作成 | /issue |
他プロジェクトとの競合・依存を警告 |
| 週次レビュー | /weekly-review |
全PJ横断のPMヘルス診断 |
| 放置検出 | /stale-check |
停滞パターンに基づく仮説 + 次アクション提案 |
フロー図
pm_brief.md：プロジェクトの「健康診断書」
/new-project を叩くと、Claude Codeが対話的に情報を引き出し、以下のテンプレートで pm_brief.md を自動生成します。
# PM Brief: {project_name}
## PdM（What / Why）
### なぜやるか
{ユーザーの発言から抽出 or 問いかけて引き出す}
### 誰のためか
- 主要受益者: {自分 / チーム / ユーザー / 組織}
### 成功指標
- 定性: {どういう状態になれば成功か}
- 定量: {測定可能な指標。不明なら「未定義 → 要設定」}
### やらないとどうなるか
{機会損失 / リスクを言語化}
## PjM（How / When）
### 初手
{最初の具体的アクション}
### リスク・ブロッカー
- [ ] {技術的リスク}
- [ ] {リソースリスク}
- [ ] {依存リスク}
### 他プロジェクトとの関係
| プロジェクト | 関係 | 影響 |
|---|---|---|
| {project} | 競合 / 依存 / 無関係 | {具体的影響} |
### 優先度（相対）
- 全Active中の位置: {高 / 中 / 低}
- 根拠: {なぜその優先度か}
ポイント: 「成功指標」と「やらないとどうなるか」を最初に言語化させることで、「なんとなく始めてなんとなく放置する」を防ぐ。
週次PMヘルス診断
/weekly-review 実行時に、通常のレビュー（git log要約、Inbox未処理チェック）に加えて、PM視点の診断が自動で走ります。
プロジェクト横断チェック
- キャパシティ: Activeプロジェクト数 vs 推奨上限（3〜5個）
- フォーカス: 今週どのプロジェクトに時間を使ったか
- 競合: 同時進行で互いにブロックしているものはないか
個別プロジェクトチェック
- pm_brief.md の鮮度: 最終更新から2週間以上 → 要更新
- 成功指標の有無: 未定義のまま放置されていないか
- リスクの顕在化: ブロッカーが現実になっていないか
健康度スコア
🟢 健全: pm_brief.md あり、成功指標定義済、直近1週間に活動あり
🟡 注意: pm_brief.md あり、成功指標未定義 or 2週間以上放置
🔴 要対処: pm_brief.md なし or 30日以上放置 or ブロッカー未解決
停滞パターン診断
/stale-check が放置プロジェクトを検出すると、パターンに基づいた仮説と次アクションを提示します。
| パターン | 仮説 | 提案 |
|---|---|---|
| 開始直後に停滞 | 初手が大きすぎた | タスクを再分解 |
| MS途中で停滞 | ブロッカーに当たった | ブロッカー特定 → 迂回策 |
| 完了間近で停滞 | 最後の仕上げが面倒 | 「完了」の再定義（スコープ縮小） |
| 複数PJ同時停滞 | キャパオーバー | 1つに絞る提案 |
| 断続的に少し進む | 優先度が低い | 凍結 or やめる決断を促す |
個人開発あるある:
- 「やりたいことが多すぎて全部中途半端」→ キャパオーバーパターン
- 「あと少しなのに完成しない」→ 完了間近停滞パターン
- 「たまに触るけど進まない」→ 優先度低パターン（やめる勇気を促す）
実践例：個人開発の読書管理アプリ
PM Layerを実際のプロジェクトに適用した例です。
プロジェクト概要
読んだ本のメモと読書習慣を記録し、AIが「次に読むべき本」を提案してくれるWebアプリ。
Phase 1：問題定義（Discovery）
/new-project 時にClaude Codeが問いかけ、以下を整理。
5 Whys（自動深掘り）:
問題: 読書メモが散らばって活用できていない
Why 1: なぜ？ → メモの取り方がバラバラで後から検索できない
Why 2: なぜ？ → ツールが統一されていない（Notion、メモ帳、Kindle）
Why 3: なぜ？ → 「メモを残す → 振り返る」の習慣が仕組み化されていない
Why 4: なぜ？ → 振り返りのトリガーがなく、記録しっぱなしになる
Why 5: なぜ？ → 読書記録を「蓄積 → 活用」するサイクルを設計していなかった
→ 根本原因: 読書メモの蓄積と活用のサイクルが回っていない
JTBD（Jobs to be Done）:
When 次に何を読むか迷ったとき,
I want to 過去に読んだ本の傾向やメモを素早く振り返りたい,
so I can 自分の興味に合った本を短時間で選べる.
Phase 2：解決策の段階的展開
/decompose でMS分解。RICEスコアリングで優先度を自動算出。
| MS | 内容 | RICE Score | 判断 |
|---|---|---|---|
| MS1 | 読書メモの一元管理 | 20 | 確信度高 × 工数小 → 最初 |
| MS2 | タグ・カテゴリ検索 | 12 | |
| MS3 | 読書統計ダッシュボード | 8.5 | |
| MS4 | AIによるおすすめ提案 | 15 | インパクト最大だが確信度低 → 後回し |
Claude Codeが出した判断: 「まずデータが溜まる仕組みを作り、データが揃ってからAI機能に進む戦略が妥当」
Phase 3：検証設計
MVP設計もClaude Codeが整理。
含めるもの（Must）:
✓ 書籍情報の登録（タイトル、著者、日付）
✓ メモの記録・編集
✓ 一覧表示と簡易検索
含めないもの（Won't）:
✗ リッチなUIダッシュボード
✗ ISBN自動取得
✗ SNS共有機能
Go/No-Go 基準:
Go: 2週間で10冊以上登録 → MS2へ
Pivot: 登録が続かない → 入力UIを簡略化
Kill: 「結局Notionでいい」 → プロジェクト凍結
Phase 4：学習ループ設計
【初期】MS1〜2: 手動入力 100%
【中期】MS3初期: 手動 40% + API自動取得 40% + 読書傾向分析 20%
【成熟期】MS4安定: 手動 10% + API自動取得 50% + AI提案 40%
これらすべてがbrainリポジトリにMarkdownとして残る。 半年後に「なぜこの設計にしたのか」を即座に検索できます。
Wantedlyの事例との比較
WantedlyのPdM・吉野氏が公開している「生成AI活用ワークフロー」と比較すると、興味深い違いがあります。
| 観点 | Wantedlyのアプローチ | 私のアプローチ |
|---|---|---|
| ツール | フェーズごとに使い分け（ChatGPT → Perplexity → Cursor → Figma → NotebookLM） | Claude Code 1本 + brainリポジトリ |
| 情報の蓄積 | 各ツールに分散 | Gitリポジトリに一元化 |
| 自動化 | 手動でツール切り替え | PM Layerが自動介入 |
| 強み | 各ツールの得意領域を活かせる | コンテキストが途切れない。過去の意思決定を検索可能 |
どちらが良いという話ではありません。Wantedlyのアプローチは「最適なツールを選ぶ力」が、私のアプローチは「コンテキストを途切れさせない仕組み」が武器です。
共通しているのは、「AIにどの粒度でどの情報を渡すか」が成果を決めるという点。 これがまさにコンテキストエンジニアリング。
Issue作成時の競合チェック
/issue で新しいIssueを作るとき、PM Layerが自動で以下を実行します。
- 全Activeプロジェクトの直近Issueを取得
- 新規Issueとの類似性・依存性をチェック
- 警告があれば表示
⚠️ creative_ai の Issue #45 と関連する可能性があります
⚠️ chrome_extension がブロッカーになる可能性があります
個人開発で5つのプロジェクトを並行していると、自分では気づかない依存関係をAIが検出してくれるのは助かります。
学んだこと
1. PMフレームワークは「テンプレート」より「問い」が重要
pm_brief.md のテンプレートを埋めること自体に価値があるのではなく、「やらないとどうなるか？」「成功をどう測るか？」という問いを強制的に考えさせることに価値があります。
Claude Codeは問いを投げるのが得意です。CLAUDE.md に「問いかける」と指定しているので、安易に答えを出さず、思考を深掘りしてくれます。
2. 個人開発こそPMが必要
チーム開発ではPMがいます。でも個人開発では自分がPM。結果、PMの仕事（スコープ定義、優先度判断、振り返り）がすべてスキップされがち。
PM Layerは「1人チームのPM」を自動化する仕組みです。
3. 「やめる判断」が一番難しい
停滞パターン診断で一番効果があったのは、「優先度が低いなら凍結 or やめる」という提案。人間は始めたものをやめるのが苦手ですが、AIは感情なく「これ、優先度低いですよ」と言ってくれます。
4. 全てをテキストにする価値
PM業務の成果物（5 Whys、JTBD、RICEスコア、Go/No-Go基準）がすべてMarkdownでGitに残る。これにより：
- バージョン管理可能: 「先月のRICEスコアと今月で何が変わったか」が追える
-
検索可能:
/kickoffで過去のPM判断を掘り出せる - AIが読める: 次のプロジェクトで類似の判断をするときに参照される
はじめ方：最小限のPM Layer
全部を一気に作る必要はありません。最小構成は以下の3ステップです。
Step 1：pm_brief.md テンプレートだけ用意する
プロジェクトフォルダに pm_brief.md を手動で作るだけでも効果があります。
# PM Brief: {project_name}
## なぜやるか
{書く}
## 成功指標
- {書く。書けないなら「未定義」と書く}
## やらないとどうなるか
{書く}
## 初手
{書く}
Step 2：CLAUDE.md に1行追加
- 新プロジェクト開始時、pm_brief.md が存在しない場合は作成を促す
これだけで、Claude Codeが「pm_brief.mdがないですが、作りましょうか？」と聞いてくれるようになります。
Step 3：週次レビューにPMチェックを追加
- /weekly-review 実行時、各プロジェクトの pm_brief.md の有無と鮮度をチェックする
まずはこの3ステップから。 自動介入や停滞診断は後から追加すれば十分です。
まとめ
| 項目 | 内容 |
|---|---|
| 何をやったか | Claude CodeにPM業務を自動介入させる「PM Layer」の構築 |
| PdM自動化 |
pm_brief.md 自動生成（Why/What/成功指標/リスク） |
| PjM自動化 | 粒度チェック、競合検出、優先度スコアリング |
| 健康診断 | 週次PMヘルスチェック（キャパ/フォーカス/鮮度） |
| 停滞診断 | 5パターンの仮説 + 次アクション提案 |
| 設計原則 | PMを手動コマンドにしない。既存フローに自動介入させる |
最大の学び: 個人開発で一番足りないのはコーディング力ではなく、「なぜやるのか」「いつやめるのか」を考える仕組みだった。PM Layerはそれをシステムで解決する。