【2026年最新】Claude Code×プロジェクト管理プロンプト30選

この記事でわかること（結論ファースト）

「また週報を書く時間が…」

ある顧問先の製造業（従業員300名規模）のPMが、こうつぶやいていました。彼は週に3本のプロジェクトを掛け持ちし、毎週月曜日の午前中を進捗レポートの整形作業に費やしていた。担当者から集めたテキストを、ステークホルダー向けに読みやすく加工する。それだけで月に10時間以上消えていくわけです。

「これ、Claudeに投げてみましょうか」と提案したのが3か月前。今はプロンプト1本で叩き台を出し、5分で最終確認するだけになっています。100社以上の企業向けAI研修・導入支援を通じて実感しているのは、PM業務こそAI活用の恩恵を受けやすい領域だということです。なぜなら、PM業務の多くが「情報の整理・構造化・レポーティング」という、LLMが最も得意とする作業だからです。

この記事では、Claude CodeをPM業務に活用するプロンプト30選を、計画フェーズ・進捗管理フェーズ・リスク/変更管理フェーズの3カテゴリに分けて全公開します。コピペ可能な形式で提供しますので、今日の業務からすぐに試せます。既存のJira・Asana・Backlog・Notionとの連携パターンも最後にまとめます。

なぜ今、Claude Code × PM業務なのか

世界のプロジェクト管理におけるAI市場は、2026年時点で約36.6億米ドル規模に達し、2036年には402億ドル（CAGR 27.08%）に成長すると予測されています（Panorama Data Insights, 2026年）。PMIはAIプロジェクト管理の国際資格「PMI-CPMAI（Certified Professional in Managing AI）」を日本語でも提供開始しており、AI×PM領域は急速に標準化が進んでいます。

一方、現場の声は違います。「AIツールは導入したが、PM業務に使いこなせていない」という声が研修参加者からも続々と届きます。理由は明快で、汎用的なChatGPTやClaudeをそのまま使っても、PM業務の文脈が伝わらないからです。

Claude Codeの強みは、長いコンテキストウィンドウと、Markdown/CSV/JSONなど多様なフォーマットへの変換精度にあります。これはPM業務との相性が抜群です。WBSはMarkdown表、ガントチャートはMermaid記法、ステータスレポートは構造化テキスト——これらすべてClaude Codeが得意とするアウトプット形式です。

AIエージェントの基本的な活用戦略については、AIエージェント導入完全ガイドでも詳しく解説しています。PM業務への応用を始める前に、基礎概念を整理しておくと理解が深まります。

さっそく30個のプロンプトを見ていきましょう。

まず試したい「5分即効」プロンプト3選

まずは難易度の低い3つから始めましょう。この3つをマスターするだけで、週に3〜5時間の工数削減が見込めます。

即効プロンプト1：ステータスレポート自動整形

研修先でこれを試したら、全員が「え、これだけで？」と声を上げました。各担当者から集めた進捗テキストをそのままClaude Codeに貼り付けて、ステークホルダー向けに整形させるだけです。

以下の進捗報告テキストを、経営層向けの週次ステータスレポートに整形してください。

【元テキスト】
{各担当者から収集した進捗報告をここに貼り付ける}

【整形要件】
- 先週の主な進捗（箇条書き3〜5点）
- 今週の予定作業（箇条書き3〜5点）
- 課題・懸念事項（RED/AMBER/GREENで分類）
- 全体進捗率（見た目でわかるプログレスバー付き）
- 次回確認が必要なアクション（担当者・期限付き）

文体は簡潔なビジネス文書で。数字と固有名詞は元テキストから変えないこと。
不足している情報があれば、最初に確認してから作業を開始してください。

想定効果: 100社以上の研修・コンサル経験をもとに構成した想定シナリオとして——週次レポートの整形作業が従来の90分→15分程度に短縮される（整形精度は元データの品質に依存）

即効プロンプト2：会議アジェンダ生成

以下の情報をもとに、キックオフミーティングのアジェンダを作成してください。

【プロジェクト概要】
- プロジェクト名: {プロジェクト名}
- 目的: {目的}
- 参加者: {参加者リスト（役割付き）}
- 会議時間: {分}
- 想定課題: {事前に判明している懸念点}

【アジェンダ要件】
- 各項目に時間配分を明記
- アイスブレイク5分を冒頭に入れる
- 意思決定が必要な議題にはDMark（要決定）を付ける
- アクションアイテム記録の時間を必ず末尾に確保

仮定した点は必ず「仮定」と明記してください。

即効プロンプト3：議事録からアクションアイテム抽出

以下の議事録テキストから、アクションアイテムを構造化して抽出してください。

【議事録】
{議事録テキストをここに貼り付ける}

【抽出フォーマット】
| No | アクション内容 | 担当者 | 期限 | 優先度(H/M/L) | ステータス |
|---|---|---|---|---|---|

- 期限が明示されていない場合は「未定」と記載
- 担当者が不明な場合は「要確認」と記載
- 優先度は文脈から推定（推定の場合は「推定」付記）

数字と固有名詞は元テキストから変えないこと。

Claude Code × PM業務の「3つの型」

この3つの型を意識してプロンプトを設計すると、アウトプットの質が安定します。以降のプロンプト集は、この分類に沿って構成しています。

計画・WBS・スケジュール管理プロンプト10選

#1 WBSたたき台の生成（製造業・IT・建設対応）

顧問先の建設会社のPMが「WBSのレビューに1週間かかっていた」と言っていました。Claude Codeにたたき台を出してもらってからは、「直しが半分以下になった」とのことです。たたき台の質が上がれば、レビューの論点が明確になるのは当然です。

事例区分: 想定シナリオ
以下は100社以上の研修・コンサル経験をもとに構成した典型的なシナリオです。

以下の情報をもとに、プロジェクトのWBS（作業分解構造）を作成してください。

【プロジェクト情報】
- プロジェクト名: {プロジェクト名}
- 業種・業界: {業種}
- プロジェクト目的: {目的}
- 主要デリバラブル: {成果物リスト}
- 期間: {開始日} 〜 {終了日}
- チーム規模: {人数}・{役割構成}

【WBS要件】
- レベル3まで分解（レベル1: フェーズ / レベル2: 成果物 / レベル3: 作業パッケージ）
- 各作業パッケージに推定工数（人日）を付与
- PMBOKのWBS作成基準（100%ルール）に準拠
- Markdown表形式で出力（WBS番号・作業名・工数・担当役割を列に）

不足情報があれば最初に確認してください。仮定した点は必ず「仮定」と明記してください。

#2 マイルストーン計画の生成

以下のWBSをもとに、プロジェクトのマイルストーン計画を作成してください。

【WBS情報】
{WBSをここに貼り付ける}

【マイルストーン要件】
- 主要な意思決定ポイントを洗い出す
- 各マイルストーンに達成条件（Definition of Done）を明記
- ステークホルダーへの承認が必要な箇所にApprovalMarkを付ける
- Markdown表形式: マイルストーン名 / 目標日 / 達成条件 / 承認者

数字と固有名詞は変えないこと。

#3 Mermaid記法でガントチャート生成

以下のタスクリストから、Mermaid記法のガントチャートを生成してください。

【タスクリスト】
{タスク名 / 開始日 / 終了日 / 担当者 / 前提タスクのリスト}

【ガントチャート要件】
- dateFormatはYYYY-MM-DD
- セクションはフェーズ別に分ける
- クリティカルパスのタスクにはcritフラグを付ける
- 週単位の表示
- 出力はMermaidコードブロックのみ（説明不要）

生成後、クリティカルパスのタスクを別途テキストで説明してください。

#4 リソース配分表の生成

以下のプロジェクト情報とチームメンバーリストから、リソース配分表を作成してください。

【プロジェクト期間】{開始日}〜{終了日}
【チームメンバー】{名前 / 役割 / 稼働率(%)}
【主要タスク】{タスク名 / 必要スキル / 工数(人日)}

【出力フォーマット】
- 週次リソースヒートマップ（Markdown表）
- 過負荷リスクがある週を「⚠️ 要注意」でマーク
- アロケーション率が80%を超えるメンバーを警告

数字と固有名詞は根拠（計算式）を添えてください。

#5 プロジェクト憲章（チャーター）のドラフト

以下の情報からプロジェクト憲章のドラフトを作成してください。

【基本情報】
- プロジェクト名: {名称}
- スポンサー: {氏名・役職}
- PM: {氏名}
- 背景・目的: {ビジネス課題と解決策}
- スコープ（含む）: {スコープに含む内容}
- スコープ外: {明示的にスコープ外とする内容}
- 予算: {概算}
- 期間: {開始}〜{終了}
- 主要ステークホルダー: {リスト}
- 成功基準: {KPI}

PMBOKのプロジェクト憲章フォーマットに準拠してください。
仮定した点は必ず「仮定」と明記してください。

#6 スコープ変更管理記録の生成

以下の変更要求を、変更管理記録（Change Request Log）に記録してください。

【変更要求内容】
{変更内容の説明}

【記録フォーマット】
- CR番号: CR-{連番}
- 変更区分: スコープ / スケジュール / コスト / 品質
- 変更内容の説明（50字以内）
- 変更理由
- 影響範囲分析: スケジュール影響 / コスト影響 / リスク影響
- 推奨対応策（3案）
- 承認ステータス: 未決 / 承認 / 却下

数字と固有名詞は変えないこと。影響範囲の数値は計算根拠を添えてください。

#7 コミュニケーション計画の生成

以下の情報から、プロジェクトのコミュニケーション計画を作成してください。

【ステークホルダー情報】
{ステークホルダー名 / 役割 / 関心事 / 影響度(H/M/L) / 協力度(H/M/L)}

【コミュニケーション計画要件】
- 各ステークホルダーへの報告頻度・手段・担当者を明記
- 会議体の一覧（名称 / 目的 / 頻度 / 参加者 / ファシリテーター）
- 緊急時エスカレーションルートを明記
- Markdown表形式で出力

仮定した点は「仮定」と明記してください。

#8 キックオフ資料のアウトライン生成

以下のプロジェクト情報から、キックオフ資料のアウトライン（スライド構成案）を作成してください。

【プロジェクト情報】
{プロジェクト名 / 目的 / スコープ / スケジュール概要 / チーム構成}

【アウトライン要件】
- スライド枚数の目安: 15〜20枚
- 各スライドにタイトル・キーメッセージ・推奨ビジュアル（表/図の種類）を付ける
- 意思決定が必要なスライドに「要決定」マークを付ける
- 想定所要時間を各スライドに付与

出力はMarkdown形式（# スライド番号. タイトル）で。

#9 前提条件・制約事項の整理

以下のプロジェクト情報から、前提条件と制約事項を整理してください。

【プロジェクト情報】
{目的 / スコープ / 関係者情報 / 環境情報}

【整理フォーマット】
前提条件（ASSUMPTIONs）:
| No | 前提条件 | リスクレベル（外れた場合の影響） | 確認責任者 |

制約事項（CONSTRAINTs）:
| No | 制約内容 | 種別（予算/スケジュール/リソース/技術） | 緩和可能性 |

依存関係（DEPENDENCIEs）:
| No | 依存内容 | 依存先 | 解消期限 |

仮定した点は「仮定」と明記してください。

#10 プロジェクト計画書レビューのセルフチェックリスト生成

以下のプロジェクト計画書のドラフトを、PMBOKとアジャイル観点の両面からレビューしてください。

【計画書ドラフト】
{計画書テキストをここに貼り付ける}

【レビュー観点】
1. スコープの明確性（100%ルールを満たすか）
2. WBSと予算の整合性
3. リスクの識別漏れ
4. ステークホルダーの関与計画の妥当性
5. コミュニケーション計画の網羅性
6. 変更管理プロセスの定義
7. 品質管理計画の有無

各観点について「OK / 要確認 / NG」と改善提案を記載してください。

進捗管理・ステータスレポートプロンプト10選

#11 週次進捗レポートの自動整形

これが冒頭のエピソードで登場したプロンプトの発展版です。担当者から集めた雑多なテキストを、経営層が5分で読めるレポートに変換します。

以下の進捗報告テキストを、経営層向け週次ステータスレポートに整形してください。

【元テキスト（各担当者報告）】
{複数の担当者報告をここに貼り付ける}

【整形フォーマット】
## 週次ステータスレポート: {プロジェクト名}
**報告期間**: {開始日}〜{終了日}
**報告者**: {PM名}

### 全体ステータス
🟢 GREEN / 🟡 AMBER / 🔴 RED（理由1行）

### 先週の主な進捗（箇条書き 最大5点）

### 今週の予定（箇条書き 最大5点）

### 課題・リスク（RED/AMBER/GREENで分類・各1行）

### アクションアイテム
| No | アクション | 担当 | 期限 |

数字と固有名詞は元テキストから変えないこと。

#12 進捗遅延の根本原因分析（RCA）

以下のプロジェクト遅延状況について、根本原因分析（RCA）を実施してください。

【遅延状況】
- 遅延しているタスク: {タスク名}
- 計画比遅延日数: {日数}日
- 遅延発覚日: {日付}
- 現象の説明: {何が起きているか}

【RCA手法】なぜなぜ分析（5 Whys）を使ってください。

【出力フォーマット】
なぜ1: 〜（根拠: 〜）
なぜ2: 〜（根拠: 〜）
なぜ3: 〜（根拠: 〜）
なぜ4: 〜（根拠: 〜）
なぜ5（根本原因）: 〜

→ 是正措置: 〜（担当・期限）
→ 再発防止策: 〜

仮定した点は「仮定」と明記してください。

#13 EVM（アーンドバリュー管理）サマリーの生成

以下のEVMデータから、プロジェクト健全性サマリーを作成してください。

【EVMデータ】
- BAC（完成時予算）: {金額}
- PV（計画価値）: {金額}
- EV（アーンドバリュー）: {金額}
- AC（実コスト）: {金額}
- 測定基準日: {日付}

【計算してほしい指標】
- SV（スケジュール差異）・SPI（スケジュール効率指数）
- CV（コスト差異）・CPI（コスト効率指数）
- EAC（完成時見積コスト）3パターン（悲観・基準・楽観）
- TCPI（完成のためのコスト効率）

各指標の計算式も併記してください。数字は根拠（計算式）を添えてください。

#14 ステークホルダーへのエスカレーションメール草案

以下の状況について、プロジェクトスポンサーへのエスカレーションメール草案を作成してください。

【エスカレーション内容】
- 状況: {何が起きているか}
- 影響: {スケジュール/コスト/品質への影響}
- 原因: {把握している原因}
- 要求: {スポンサーに求めること・意思決定事項}
- 期限: {回答が必要な期限}

【メール要件】
- 件名に「[要対応] [プロジェクト名]」を入れる
- 本文は200字以内で状況を要約してから詳細へ
- 選択肢（Option A/B/C）を提示して意思決定を促す
- 添付資料の必要性もコメントする

仮定した点は「仮定」と明記してください。

#15 スプリントレトロスペクティブのファシリテーションガイド

以下のスプリント情報から、レトロスペクティブのファシリテーションガイドを作成してください。

【スプリント情報】
- スプリント番号: {No}
- 期間: {開始日}〜{終了日}
- 完了ストーリーポイント: {SP} / 計画SP: {SP}
- 主な出来事・課題: {箇条書き}
- 参加者数: {人数}

【ファシリテーションガイド要件】
- 手法: Keep / Problem / Try（KPT）
- 各フェーズの時間配分（合計60分以内）
- 参加者が話しやすいアイスブレイク質問（3問）
- 「Try」の優先順位付け方法（ドット投票など）
- 次スプリントへのコミットメントの形式

#16 バーンダウンチャート分析コメントの生成

以下のバーンダウンデータを分析し、状況コメントを生成してください。

【バーンダウンデータ（スプリント日次）】
{日付 / 残ストーリーポイント のCSVまたはテキスト}

【計画ライン】
スプリント開始SP: {SP} / スプリント日数: {日数}

【分析コメント要件】
- 現在のペース（ベロシティ）を計算
- このペースでスプリント完了できるか判定
- 理想ラインとのギャップ原因として考えられる要因（3〜5点）
- スプリントゴール達成のための推奨アクション（2〜3点）

数字は計算根拠を添えてください。

#17 QAチェックリストの生成

以下のプロジェクト情報から、品質管理チェックリストを作成してください。

【プロジェクト情報】
- 種別: {ソフトウェア開発 / インフラ構築 / 業務改善 など}
- 主要デリバラブル: {成果物リスト}
- 品質基準: {要件定義書・仕様書に記載された品質基準}

【チェックリスト要件】
- 各デリバラブルについてゲート条件を洗い出す
- 各チェック項目に確認者と確認方法を付ける
- 「必須」と「推奨」を区別する
- Markdown表形式で出力

#18 プロジェクト週次ダッシュボード用サマリーの生成

以下の情報から、プロジェクト週次ダッシュボード掲載用サマリーテキストを生成してください。

【入力情報】
- プロジェクト名: {名称}
- 全体ステータス: {GREEN/AMBER/RED}
- 完了タスク数: {N}件 / 全体: {M}件（進捗率: {%}）
- 今週の主要進捗: {箇条書き}
- 課題件数: RED:{N}件 / AMBER:{N}件
- 次のマイルストーン: {名称}（{日付}）

【出力要件】
- 3〜5行のサマリーテキスト（ダッシュボードのコメント欄に貼る形式）
- 数字を前面に出す
- 専門用語は避け、経営層でも理解できる表現で

#19 プロジェクト完了報告書のドラフト

以下の情報から、プロジェクト完了報告書（Lessons Learned含む）のドラフトを作成してください。

【プロジェクト情報】
- プロジェクト名: {名称}
- 期間: {開始}〜{終了}（当初計画: {期間}）
- 最終コスト: {金額}（当初予算: {金額}）
- 達成した成果: {KPI達成状況}
- 発生した主要課題: {箇条書き}
- 対応した変更: {変更件数と主な内容}

【報告書要件】
- エグゼクティブサマリー（200字以内）
- 計画比での実績評価（スコープ/コスト/スケジュール/品質）
- ベストプラクティス（次プロジェクトで活かすべき点3〜5点）
- 改善事項（次回避けるべき点3〜5点）
- 感謝・ねぎらいの一言（PMから）

数字と固有名詞は変えないこと。

#20 月次PMレポートの自動生成

以下のデータから、経営会議向け月次PMレポートを生成してください。

【データ】
- 報告月: {YYYY年MM月}
- アクティブプロジェクト数: {N}件
- 各プロジェクト: {名称 / ステータス / 進捗率 / 主要イベント}
- 月中に完了したプロジェクト: {名称 / 最終評価}
- 月中に承認されたプロジェクト: {名称 / 概要}
- 組織全体のリソース稼働率: {%}

【レポート要件】
- 1ページ（A4縦）に収まる分量
- ポートフォリオビューの表（プロジェクト別サマリー）
- 翌月の注目ポイント（2〜3点）
- PMO所見（リスクと推奨アクション）

数字は根拠を添えてください。

リスク・課題・変更管理プロンプト10選

#21 リスク洗い出しとリスク登録票の生成

これは研修で一番「気づきがあった」という声が多かったプロンプトです。自分では思いつかなかったリスクをClaude Codeが「業種の慣行から見ると〜」と指摘してくる。PMBOKのリスク分類に沿って体系的に洗い出してくれるので、抜け漏れが激減します。

事例区分: 想定シナリオ
以下は100社以上の研修・コンサル経験をもとに構成した典型的なシナリオです。

以下のプロジェクト情報をもとに、リスク登録票を作成してください。

【プロジェクト情報】
- プロジェクト名: {名称}
- 業種: {業種}
- 期間: {期間}
- 主要ステークホルダー: {リスト}
- 技術スタック: {使用技術・ツール}
- 外部依存関係: {ベンダー・パートナー}

【リスク登録票フォーマット（Markdown表）】
| No | リスク名 | カテゴリ | 発生確率(H/M/L) | 影響度(H/M/L) | リスクスコア | 対応戦略 | 担当者 | モニタリング方法 |

【リスクカテゴリ】
技術的 / 外部 / 組織的 / プロジェクトマネジメント / その他

最低10件のリスクを洗い出してください。
数字と固有名詞は根拠を添えてください。

#22 課題管理票（Issue Log）の記録・更新

以下の課題情報を課題管理票（Issue Log）に記録してください。

【課題情報】
{課題の説明テキスト}

【記録フォーマット】
| 項目 | 内容 |
|---|---|
| 課題ID | ISS-{連番} |
| 課題名 | {30字以内} |
| 発生日 | {日付} |
| 発見者 | {氏名} |
| 課題の説明 | {100字以内} |
| 影響範囲 | スコープ / スケジュール / コスト / 品質 / {具体的影響} |
| 優先度 | Critical / High / Medium / Low |
| 対応策 | {推奨対応と根拠} |
| 担当者 | {氏名} |
| 目標解決日 | {日付} |
| ステータス | Open |

対応策は3案提示し、推奨案に理由を付けてください。

#23 リスク対応計画の生成

以下のリスク（リスクスコア上位3件）について、詳細な対応計画を作成してください。

【リスク情報】
{リスク登録票から上位3件をここに貼り付ける}

【対応計画要件】
各リスクについて:
- 対応戦略: 回避 / 軽減 / 転嫁 / 受容 から選択と理由
- 具体的対応アクション（担当者・期限付き）
- トリガー条件（このリスクが顕在化したと判断する基準）
- コンティンジェンシー計画（トリガーが発動した場合の対応手順）
- 残余リスクの評価

仮定した点は「仮定」と明記してください。

#24 変更影響分析レポートの生成

以下の変更要求について、影響分析レポートを作成してください。

【変更要求】
- 変更ID: CR-{番号}
- 変更内容: {詳細説明}
- 変更要求者: {氏名・役職}
- 要求日: {日付}

【影響分析要件】
スケジュールへの影響:
- 影響するタスク: {リスト}
- 遅延予測日数: {日数}（計算根拠を示す）

コストへの影響:
- 追加工数: {人日}
- 追加コスト: {概算}（計算根拠を示す）

品質・スコープへの影響:
- スコープ変更の有無と内容
- 品質基準への影響

リスクへの影響:
- 新たに発生するリスク
- 軽減されるリスク

推奨: 承認 / 条件付き承認 / 却下（理由付き）

#25 ベンダー・パートナーへのエスカレーション文書

以下の状況について、ベンダーへのフォーマルなエスカレーション文書を作成してください。

【状況】
- ベンダー名: {名称}
- 契約内容（概要）: {概要}
- 問題の内容: {具体的な問題}
- 発生日・発覚日: {日付}
- 自社への影響: {スケジュール/コスト/品質への影響}
- これまでの対応経緯: {時系列}

【文書要件】
- 事実と意見を明確に分離
- 要求事項（いつまでに何をしてほしいか）を明記
- 回答期限を設定
- トーンはプロフェッショナルかつ毅然として
- 件名は「[正式通知] {問題概要}」形式

数字と固有名詞は変えないこと。

#26 ポストモーテム（障害後振り返り）テンプレートの生成

以下のインシデント・障害について、ポストモーテムドキュメントを作成してください。

【インシデント情報】
- 発生日時: {日時}
- 終結日時: {日時}
- 影響範囲: {何が・どの程度影響を受けたか}
- タイムライン: {発生〜解決の経緯を時系列で}
- 根本原因（暫定）: {現時点での原因仮説}

【ポストモーテム要件】
- 責任の追及ではなく「システム・プロセスの改善」にフォーカス
- 「何が上手くいったか」を必ず含める
- アクションアイテムに優先度・担当者・期限を付ける
- 再発防止のための具体的変更（3〜5点）
- 次回検証日の設定

仮定した点は「仮定」と明記してください。

#27 リスクレビュー会議のファシリテーションガイド

以下のリスク登録票を使ったリスクレビュー会議のファシリテーションガイドを作成してください。

【リスク登録票】
{リスク登録票をここに貼り付ける}

【ファシリテーションガイド要件】
- 会議時間: {分}
- 参加者: {役割リスト}
- アジェンダ（時間配分付き）
- 各リスクのレビューで聞くべき質問（3〜5問）
- リスクスコア更新の基準
- 会議後のアクション（リスク担当者への連絡文）

「批判なしの発散」フェーズと「評価・収束」フェーズを分けて設計してください。

#28 コンティンジェンシーバジェット計算の補助

以下のリスク情報から、コンティンジェンシーリザーブの計算を補助してください。

【リスク情報】
| リスク名 | 発生確率(%) | 影響コスト(万円) |
{リスクリストをここに入力}

【計算方法】
1. 期待金額価値（EMV）= 発生確率 × 影響コスト
2. 各リスクのEMVを算出
3. 合計EMVをコンティンジェンシーリザーブの参考値として提示

【補足計算】
- 感度分析: 発生確率が±10%ブレた場合の影響範囲
- 推奨バッファ額（合計EMVの何%が妥当か、業界慣行を参考に）

数字は計算根拠（計算式）を全て明記してください。

#29 ステークホルダーマップの生成

以下のステークホルダー情報から、ステークホルダーマップ（Power-Interest Grid）を生成してください。

【ステークホルダー情報】
{ステークホルダー名 / 役職 / 影響度(H/M/L) / 関心度(H/M/L) / 関係（支持/中立/抵抗）}

【出力フォーマット】
1. Power-Interest Grid（Markdown表またはテキストArt）
2. 各グループ（Manage Closely / Keep Satisfied / Keep Informed / Monitor）の推奨対応戦略
3. 抵抗勢力への対応策（具体的なコミュニケーション戦略）

仮定した点は「仮定」と明記してください。

#30 クロージングチェックリストの生成

以下のプロジェクト情報から、プロジェクトクロージングチェックリストを作成してください。

【プロジェクト情報】
- プロジェクト名: {名称}
- 種別: {開発 / インフラ / 業務改善 など}
- 最終デリバラブル: {成果物リスト}
- 契約・調達の有無: {有/無 + 内容}
- チームメンバー: {人数}

【チェックリスト要件】
- デリバラブル引き渡し確認
- 契約・調達クローズ
- リソース解放（チームメンバー・機器・ライセンス）
- 財務クローズ（請求・支払いの完了確認）
- 文書アーカイブ（どこに・何を保存するか）
- ステークホルダーへの正式クローズ通知
- Lessons Learnedの記録・共有

各項目に「確認者」「確認方法」「完了基準」を付けてください。

【要注意】Claude Code × PM業務のよくある失敗パターン4選

失敗1：プロンプトに「コンテキスト」を入れない

❌ よくある間違い: 「WBSを作ってください」だけで投げる

⭕ 正しいアプローチ: 業種・期間・チーム規模・デリバラブルを全て入力してから投げる

なぜ重要か: LLMは「文脈の生き物」です。コンテキストが薄いと、汎用的すぎてそのままでは使えないアウトプットが返ってきます。最初の入力に5分かけるだけで、レビュー時間を大幅に削減できます。研修でこれを伝えると「なるほど、今までコンテキストを省いていました」という声が必ず出ます。

失敗2：AIの数字をそのまま使う

❌ よくある間違い: Claude Codeが出したEMV計算やリソース配分数字をそのまま計画書に載せる

⭕ 正しいアプローチ: 計算根拠を表示させ、入力データの正しさを確認した上で使う

なぜ重要か: 私が見た失敗例では、リスクコストの入力単位を「万円」と「円」で混在させたまま投げて、EMVが100倍になっていたケースがありました。プロンプトに「数字は計算根拠（計算式）を添えてください」と入れることで、検証が格段に楽になります。

失敗3：機密情報をそのままクラウドAIに入力する

❌ よくある間違い: クライアント名・個人名・契約金額を含む議事録をそのままClaude.aiに貼り付ける

⭕ 正しいアプローチ: 固有名詞をマスク（「クライアントA社」「担当者B氏」）してから投入する。Claude Codeをローカル実行する場合は情報管理ポリシーを確認した上で判断する

なぜ重要か: 企業のAI活用ガバナンスポリシーはまだ整備途上です。「使うな」という極端な運用より、「どの情報をどの範囲で使うか」のルールを先に決めることをお勧めします（詳細は後述のガバナンスセクションを参照）。

失敗4：最初から「完成品」を求める

❌ よくある間違い: 「プロジェクト計画書を全部作って」と一度で投げる

⭕ 正しいアプローチ: 「まずWBSのたたき台→次にマイルストーン→次にリスク」と段階的に進める

なぜ重要か: 一度に大きなアウトプットを求めると、各パーツの品質が下がります。「生成→レビュー→フィードバック→再生成」のサイクルを小さく回す方が、結果的に品質も速度も上がります。

プロジェクト機密・個人情報のガバナンス設計

AI活用でPMが最も心配するのが情報セキュリティです。企業向けAI研修を100社以上実施してきた経験から、現実的なガバナンス設計を提案します。

事例区分: 想定シナリオ
以下は100社以上の研修・コンサル経験をもとに構成した典型的なシナリオです。

3段階の情報管理ルール

実用的なマスキング方法

# 使用前のマスキング例
変換前: 株式会社○○様との進捗会議で田中部長から指摘があった件について
変換後: クライアントA社との進捗会議でB部長（製造部門）から指摘があった件について

# プロンプト内でのマスキング指示
以下の議事録は機密情報をマスクして入力しています。
マスク形式: 社名→「クライアントX社」/ 人名→「担当者Y氏」
アウトプットにもマスク形式を維持してください。

Claude CodeのEnterprise版を使う場合、データがAnthropic側の学習に使われないことが契約上保証されます。社内規定と照らし合わせてご確認ください（参考: Anthropicプライバシーポリシー）。

既存ツール（Jira / Asana / Backlog / Slack）との連携パターン

「Claude Codeと既存のPMツールは共存できるのか？」——これが研修参加者から最もよく聞かれる質問です。答えは「完全に共存できる、むしろ相性が良い」です。

Claude Code × Jira

Jiraはチケット管理の運用ツールです。Claude Codeは「Jiraチケットの内容を設計する」フェーズで活用します。

Claude Code × Asana / Backlog

タスク管理ツールとの連携では、「Claude CodeでタスクのドラフトをMarkdown表で生成→ツールにインポート」のフローが実用的です。

# Backlog用タスクリスト生成プロンプト（Markdown表形式）
以下のWBSから、Backlogにインポート可能なタスクリストを生成してください。

【WBS】
{WBSをここに貼り付ける}

【出力フォーマット（Markdown表）】
| タスク名 | 担当者 | 開始日 | 期限 | 優先度 | 親タスク | 概要 |

Backlogのインポート形式に合わせてください。
優先度は「高/中/低」で表記。

Claude Code × Slack

Slackとの組み合わせでは「Claude Codeで文章生成→Slackに貼り付け」が最もシンプルです。Slack APIとClaudeを組み合わせたワークフロー自動化も可能ですが、まずは手動フローから始めることを推奨します。

• 週次進捗レポートをClaude Codeで生成→プロジェクトチャンネルに投稿
• 課題発生時のエスカレーションメッセージをClaude Codeで整形
• 会議後の議事録サマリーをClaude Codeで作成→議事録チャンネルに投稿

生成AIを使った企業全体の導入・展開戦略については、生成AI企業導入90日ロードマップも合わせてご参照ください。

ROI：Claude Code × PM業務の時間対効果

投資対効果を数字で確認しておきましょう。以下は、100社以上の研修・コンサル経験をもとに構成した想定シナリオです。実際の効果は組織環境・スキルレベル・業種によって大きく異なります。

事例区分: 想定シナリオ
以下は複数の研修事例の傾向をもとに構成した典型的な想定値です。個別の成果を保証するものではありません。

一般的なPM（PM業務20時間/週の想定）がこの30選を活用した場合、定型業務の工数削減だけで週4〜6時間の余力が生まれると想定できます。その余力を「ステークホルダーとの関係構築」「戦略的な課題発見」「チームメンバーの育成」に振り向けることができます。

AIエージェントによる業務自動化のROIについては、Claude Code主要機能20選でも詳しく解説しています。

PM/PMO向けClaude Code活用ロードマップ

「どこから始めればいいか」——研修参加者からよく聞かれます。以下の3フェーズで進めることをお勧めします。

Phase 1は「週次レポート整形」から始めることを強くお勧めします。理由は3つ：成果が即座に見える・リスクが低い（機密情報が少ない）・繰り返し使う定型業務なので効果を実感しやすい——からです。

参考・出典

• プロジェクト管理におけるAI市場：2036年に402億ドル規模へ — Panorama Data Insights Ltd.（参照日: 2026-05-12）
• PMI Certified Professional in Managing AI (PMI-CPMAI)™ — Project Management Institute（参照日: 2026-05-12）
• Claude CodeでPM業務を効率化する方法 — Qiita / nogataka（参照日: 2026-05-12）
• Claude Codeでプロジェクト管理を効率化する方法 — StartLink（参照日: 2026-05-12）
• 製造業PMがWBSをゼロから作る方法｜Claude Codeで30分たたき台術 — PMラボ（参照日: 2026-05-12）
• Turning Claude Code Into a Management Platform That Empowers My Team — Wix Engineering（参照日: 2026-05-12）

まとめ：今日から始める3つのアクション

1. 今日やること: #11「週次ステータスレポート整形」プロンプトを、今週の進捗報告で1回試す。最初の5分の投資で、整形作業がどれだけ変わるか体感してください。
2. 今週中: 自分のPM業務で「最も時間がかかっていること」を1つ特定し、このプロンプト集の中から対応するプロンプトを選んでカスタマイズする。
3. 今月中: チームの定例会議で「AI活用ルール（情報管理の3段階）」を共有し、チームで使うプロンプトテンプレートを3〜5個選定して共有ドキュメントに整備する。

あわせて読みたい:

• Claude Code × 経営企画 業務30選 — 事業計画・予算管理・役員レポートへの応用
• Claude Code × ITヘルプデスク 業務30選 — サポート業務での活用パターン

次回予告: 次の記事では、Claude CodeとPM業務を組み合わせた「PMO自動化の最前線——ステータスレポートを完全自動化する3ステップ」をテーマに、より発展的なワークフロー構築をお届けします。

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。