PM・PMO向けAIプロンプト集

あなたは、ITシステム開発プロジェクトに詳しい経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、上長・顧客に共有できる週次進捗報告のたたき台を作成してください。

【プロジェクト概要】
- 目的：
- 期間：
- 体制：
- 現在のフェーズ：

【今週の進捗】
- 完了したこと：
- 進行中のこと：
- 未着手のこと：

【課題・リスク】
- 課題（すでに発生・顕在化している問題）：
- リスク（まだ発生していないが起きうる懸念）：
- 判断が必要なこと：

【出力形式】
箇条書きと表を組み合わせて読みやすく整理してください。セクションは以下の順番で出力してください。

【出力してほしい内容】
1. 今週の進捗サマリー（3〜5行）
2. 主な課題と対応方針（課題・対応方針・担当・期限の表形式）
3. 主なリスクと注意点（リスク・発生確率・影響度・対策の表形式）
4. 来週のアクション（番号付きリスト・担当者付き）
5. 上長・顧客に確認・判断してほしいこと（箇条書き）

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（例：「〜と考えられます」は推測として明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま顧客提出せず、必ず人間が確認してください。

あなたは、プロジェクト管理と課題・リスク管理に詳しい経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、課題とリスクを分けて整理し、優先度と対応方針を明確にしてください。

【課題とリスクの定義】
- 課題：すでに発生・顕在化している問題
- リスク：まだ発生していないが将来起きうる懸念

【状況】
- プロジェクトの状況：
- 困っていること：
- 関係者：
- 期限：
- 影響範囲：

【現在見えている問題】
- 問題1：
- 問題2：
- 問題3：

【出力形式】
課題とリスクは分けて表形式で整理してください。

【出力してほしい内容】
1. 課題一覧（課題・影響・優先度・対応方針・担当・期限の表形式）
2. リスク一覧（リスク・発生確率・影響度・優先度・対策の表形式）
3. エスカレーションが必要なもの（理由付き）
4. 次に確認・収集すべき情報
5. 直近の対応アクション（番号付きリスト）

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま顧客提出せず、必ず人間が確認してください。

あなたは、顧客折衝と文書作成に長けた経験豊富なプロジェクトマネージャーです。
以下の状況をもとに、顧客向けの説明方針と文面案を作成してください。

【説明したい状況】
- 発生していること：
- 背景：
- 顧客への影響：
- こちらの対応状況：
- 顧客に判断・確認してほしいこと：

【コミュニケーション条件】
- 報告手段（メール／対面／電話）：
- 相手の役職・立場：
- 顧客との現在の関係（良好／緊張気味／など）：

【出力形式】
文面案はメール形式（件名・本文）で出力してください。論点整理は箇条書きを使ってください。

【出力してほしい内容】
1. 顧客に伝えるべき要点（優先度順）
2. 伝え方の注意点・トーン指針
3. 説明文面案（件名・本文のメール形式）
4. 想定される質問と回答方針
5. 避けるべき表現（例：「問題ない」「大丈夫」などの根拠のない安心表現）
6. 次のアクションと期日

【避けるべき表現例（参考）】
- NG：「問題ありません」→ OK：「現時点では影響がないことを確認しています」
- NG：「〜のせいで遅れました」→ OK：「〜が原因で予定より遅れが生じています」
- NG：「すぐに対応します」→ OK：「◯月◯日までに対応します」

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま顧客提出せず、必ず人間が確認・修正してください。

あなたは、プロジェクト管理と会議ファシリテーションに詳しい経験豊富なプロジェクトマネージャーです。
以下の会議メモをもとに、関係者が共有できる議事録を作成してください。

【会議メモ】
ここに会議メモを貼り付ける

【出力形式】
セクションごとに見出し付きで整理し、TODOは担当者・期限付きの表形式で出力してください。

【出力してほしい内容】
1. 会議の基本情報（日時・参加者・目的）
2. 主な議論内容（箇条書き）
3. 決定事項（箇条書き・根拠付き）
4. TODO一覧（担当者・期限・優先度の表形式）
5. 未決事項・継続検討項目（次回への持ち越し）
6. 次回確認・アジェンダ候補

【注意事項】
- 情報が不足している場合（参加者・日時・目的など）は、まず不足項目を列挙してください。
- 発言の意図が不明な箇所は推測せず、「要確認」として明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま送付せず、必ず参加者が内容を確認してください。

あなたは、変更管理とスコープ調整に詳しい経験豊富なプロジェクトマネージャーです。
以下の仕様変更・追加要望について、影響範囲を整理し、受入可否の判断材料を提示してください。

【変更内容】
- 変更・追加したい内容：
- 背景：
- 要望者：
- 希望期限：

【現在の状況】
- 現在のスコープ：
- 進捗状況：
- 関係する機能・成果物：
- 制約条件：

【出力形式】
影響項目は表形式で整理してください。受入可否の選択肢は番号付きで出力してください。

【出力してほしい内容】
1. 影響範囲（工数・納期・品質・コストの各観点を表形式で）
2. 追加で必要になる作業（番号付きリスト）
3. 工数・納期への影響（具体的な日数・規模の目安）
4. 品質・リスクへの影響
5. 顧客に確認・合意を取るべきこと
6. 受ける場合の条件と根拠
7. 断る・先送りする場合の説明方針
8. 次のアクション

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（工数見積もりは「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま顧客提出せず、必ず人間が確認してください。

あなたは、プロジェクト回復と遅延対応に詳しい経験豊富なプロジェクトマネージャーです。
以下の遅延状況をもとに、リカバリー方針と顧客説明の論点を整理してください。

【遅延状況】
- 遅れている作業：
- 当初予定：
- 現在の見込み：
- 遅延理由：
- 影響を受ける成果物：

【制約条件】
- 納期：
- 人員：
- 品質条件：
- 顧客との合意事項：

【出力形式】
リカバリー案は選択肢形式で整理し、メリット・デメリットを比較表で出力してください。

【出力してほしい内容】
1. 遅延原因の整理（根本原因と表面的な原因を分けて）
2. 影響範囲（成果物・顧客・チーム・契約への影響）
3. リカバリー案（複数案を比較表形式で）
4. 推奨案と根拠
5. 顧客説明の方針・論点
6. 直近で実施すべきアクション（番号付きリスト）
7. 再発防止に向けた論点

【リカバリー案の比較例（参考）】
| 案 | 内容 | 納期への影響 | コスト | リスク | 顧客説明難易度 |
|---|---|---|---|---|---|
| 案A | 人員追加 | △2週間短縮 | 増 | 品質低下リスク | 中 |
| 案B | スコープ縮小 | 予定通り | 変更なし | 顧客承認必要 | 高 |

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま顧客提出せず、必ず人間が確認してください。

あなたは、プロジェクト危機対応と炎上収束の経験が豊富なプロジェクトマネージャーです。
以下の状況をもとに、炎上初動72時間で確認・実施すべきことを優先度付きで整理してください。

【現在の状況】
- 発生している問題：
- 顧客への影響：
- チームへの影響：
- 納期・品質への影響：
- すでに実施した対応：

【出力形式】
72時間アクションは時系列の優先度表で整理してください。やってはいけない対応は明確に箇条書きで出力してください。

【出力してほしい内容】
1. まず確認すべき事実（「事実」と「推測」を分けて列挙）
2. 関係者ごとの影響整理（表形式：関係者・影響内容・優先度）
3. 直近72時間でやるべきアクション（時系列・担当者付きの優先度表）
4. 顧客説明の方針・論点（伝えること・伝え方・タイミング）
5. 社内エスカレーションの要否と範囲
6. やってはいけない対応（禁止事項）
7. 再発防止に向けた論点

【炎上初動で避けるべき対応例（参考）】
- 「大丈夫です」と根拠なく顧客を安心させる
- 原因未確定のまま謝罪・断言する
- 内部の混乱・対立を顧客に見せる
- 対応担当者を決めずに全員が動く（役割分担なし）
- ログ・証跡を消す・隠す

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を明確に区別してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま顧客提出せず、必ず人間が確認してください。

あなたは、ステークホルダーコミュニケーションと報告書作成に長けた経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、報告先に合わせた報告内容と文面を整理してください。

【報告先】
- 相手：（例：社内上司／経営層／顧客の担当者／顧客の意思決定者）
- 相手が知りたいこと：
- 相手に判断してほしいこと：
- 相手のコミュニケーションの傾向（詳細志向／概要志向／など）：

【プロジェクト状況】
- 現在の状況：
- 主な課題：
- 主なリスク：
- 今後の見通し：

【出力形式】
相手別に報告内容を分け、報告文案はメール形式（件名・本文）で出力してください。

【出力してほしい内容】
1. 報告先に合わせた要点（相手が最も重視する観点から整理）
2. 伝えるべき事実（優先度順）
3. 判断が必要な論点（決定事項・確認事項を明確に）
4. 相手別の伝え方・トーン指針
5. 想定質問と回答方針
6. 報告文案（相手のスタイルに合わせた件名・本文）
7. 次のアクションと期日

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま送付せず、必ず人間が確認・修正してください。

あなたは、複数プロジェクトのポートフォリオ管理と組織PMO運営の経験が豊富なPMOスペシャリストです。
以下のプロジェクト状況をもとに、PMO視点での健全性評価と支援方針を整理してください。

【対象プロジェクト】
- プロジェクト概要：
- 進捗状況：
- 課題：
- リスク：
- 体制：
- 顧客・関係者の状況：

【評価観点（PMO健全性チェック軸）】
以下の観点でレビューしてください。
- 計画：WBS・マイルストーンの整合性
- 進捗：計画対比の進捗状況
- 課題・リスク：管理と対応の状況
- 体制：人員充足・スキルマッチ
- 顧客対応：関係性・合意事項の状況
- ガバナンス：ルール・報告体制の整備状況

【出力形式】
健全性評価は「赤（要緊急対応）／黄（要注意）／緑（良好）」の3段階で判定してください。
支援項目は優先度順に表形式で整理してください。

【出力してほしい内容】
1. PMO健全性評価（観点別の赤／黄／緑判定と根拠）
2. 優先して支援すべき領域（優先度・支援内容・期待効果の表形式）
3. 案件横断で見たときのリスク
4. 標準化・改善できる点
5. 管理職向けサマリー（3〜5行）
6. 次のアクション

【健全性判定の目安（参考）】
- 赤：放置すると2週間以内に顧客・納期・契約に影響が出る
- 黄：現状では問題ないが、対策なしには1ヶ月以内に問題化しうる
- 緑：現状の管理・対応が機能している

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま提出せず、必ず人間が確認してください。

あなたは、プロジェクト診断とヘルスチェックの経験が豊富なプロジェクトマネージャー兼PMOスペシャリストです。
以下の情報をもとに、プロジェクト全体の状態を多角的に評価し、対応方針を整理してください。

【プロジェクト概要】
- 目的：
- 期間：
- 体制：
- 現在のフェーズ：
- 主要な成果物：

【現在の状況】
- 進捗：
- 課題：
- リスク：
- 品質：
- 顧客対応：
- チーム状況：

【出力形式】
健全性評価は観点別スコア（5段階）と赤／黄／緑判定を組み合わせて出力してください。

【出力してほしい内容】
1. 健全性スコア（進捗・課題管理・リスク管理・品質・顧客関係・チーム状況を5段階で評価した表）
2. 総合判定（赤／黄／緑）と根拠
3. 危ない兆候（早期警告シグナル）
4. 優先して確認・対応すべきこと（番号付きリスト）
5. PMが今週判断すべき論点
6. 関係者に共有すべき内容と伝え方
7. 次のアクション（担当者・期日付き）

【健全性スコア基準（参考）】
| スコア | 判定 | 説明 |
|---|---|---|
| 5 | 緑 | 計画通り進んでおり、問題なし |
| 4 | 緑 | 軽微な懸念はあるが管理できている |
| 3 | 黄 | 注意が必要。改善アクションを検討中 |
| 2 | 黄 | 要対策。放置すると悪化リスクあり |
| 1 | 赤 | 要緊急対応。早急な意思決定が必要 |

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま提出せず、必ず人間が確認してください。

あなたは、プロジェクト立ち上げと計画策定に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、プロジェクトキックオフ資料のたたき台を作成してください。

【目的】
プロジェクト関係者全員が「何を、なぜ、誰が、いつまでに、どうやって」行うかを共有できる資料を作ります。

【入力項目】
- プロジェクト名・概要：
- 背景・目的：
- 対象範囲（スコープ）：
- 期間・マイルストーン（主要フェーズと期日）：
- 体制（PM・メンバー・顧客担当の役割）：
- 予算（概算）：
- 成功基準・完了条件：
- 主要な制約・前提条件：

【出力形式】
スライドのセクション構成に準じた見出し付きドキュメント形式で出力してください。

【出力してほしい内容】
1. プロジェクト概要（背景・目的・対象範囲）
2. 体制（役割と担当者をテキスト表で整理）
3. マイルストーン一覧（フェーズ・期日・主要成果物の表形式）
4. 進め方とルール（会議体・報告方法・変更管理手順）
5. 初期リスクと対応方針（リスク・影響・対策の表形式）
6. 関係者への確認・合意が必要な事項

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（目安値・見積もりは「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・修正してください。

あなたは、プロジェクト管理標準（PMBOK等）に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、プロジェクト憲章のたたき台を作成してください。

【目的】
プロジェクトの正式承認に必要な情報を一文書にまとめ、関係者全員が合意できる状態を作ります。

【入力項目】
- プロジェクト名：
- 背景・立ち上げ理由：
- 目的・達成目標：
- 対象スコープ（含む・含まない）：
- 期間（開始日・終了日）：
- PMの権限範囲：
- 主要ステークホルダー：
- 予算・リソース概要：
- 成功基準・KPI：
- 主要な制約・前提・除外事項：

【出力形式】
標準的なプロジェクト憲章のセクション構成（表形式で整理可）で出力してください。

【出力してほしい内容】
1. プロジェクト基本情報（名称・目的・背景）
2. スコープ定義（含む事項・含まない事項の表形式）
3. 主要マイルストーン（フェーズ・期日・成果物）
4. 体制と権限範囲（PMの決定権・エスカレーション先）
5. 成功基準とKPI
6. 主要なリスクと前提条件
7. スポンサー・承認者への確認事項

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（見込み・目安は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま承認申請せず、必ず人間が確認・修正してください。

あなたは、プロジェクト計画とWBS策定に詳しい経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、プロジェクトのWBS（作業分解構造）のたたき台を作成してください。

【目的】
プロジェクトで完了すべき作業を網羅的に洗い出し、担当・期間・依存関係が見える状態にします。

【入力項目】
- プロジェクト概要：
- 主要な成果物（フェーズ別）：
- 期間・マイルストーン：
- 体制（役割と担当者）：
- 対象外作業（スコープ外）：
- 既知の依存関係・制約：

【出力形式】
階層付きリスト（レベル1：フェーズ、レベル2：作業グループ、レベル3：タスク）で出力し、各タスクに担当・想定工数・依存タスクを付けた表形式でも整理してください。

【出力してほしい内容】
1. WBS階層構造（フェーズ→作業グループ→タスクの階層リスト）
2. タスク一覧（タスク名・担当・想定工数・開始/終了予定・依存タスクの表形式）
3. 見落としやすいタスク・作業（チェックリスト形式）
4. クリティカルパスの候補
5. 工数・期間の見直しが必要なポイント

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 工数・日数の見積もりは「推定」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・修正してください。

あなたは、タスク管理とプロジェクト計画に詳しい経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、大きなタスクを実行可能なサブタスクに分解し、依存関係を整理してください。

【目的】
「大きすぎて動けない」タスクを、チームが日単位で進捗確認できる粒度に分解します。

【入力項目】
- 分解したい機能・作業・成果物の名前：
- 内容の概要：
- 担当チーム・メンバー：
- 期限：
- 前提となる完了済み作業：
- 並行して進む他の作業：

【出力形式】
サブタスクは番号付きリスト、依存関係はテキスト形式の前後関係マップで表現してください。

【出力してほしい内容】
1. サブタスク一覧（番号・タスク名・内容・想定工数・担当）
2. 依存関係マップ（どのタスクが終わらないと次に進めないかを整理）
3. 並行実施可能なタスクのグループ
4. クリティカルパスと最短完了パス
5. 見落としがちな作業（確認項目）
6. 担当者・期限の調整が必要なポイント

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 工数・日数の見積もりは「推定」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・修正してください。

あなたは、組織設計と役割分担に詳しい経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、プロジェクトのRACIマトリクスを作成してください。

【目的】
「誰が決める・誰がやる・誰に相談・誰に伝える」を明確にし、責任の曖昧さをなくします。

【RACI定義】
- R（Responsible）：実際に作業を実施する担当者
- A（Accountable）：最終的な承認・責任を持つ人（1人のみ）
- C（Consulted）：事前に相談・意見を求める人
- I（Informed）：完了後に結果を通知する人

【入力項目】
- プロジェクト概要：
- 主要な業務・意思決定項目（例：設計・開発・テスト・リリース判断など）：
- 関係者・役割（PM・開発リーダー・エンジニア・顧客・管理職など）：
- 特に責任が曖昧な領域（あれば）：

【出力形式】
RACIマトリクスは業務×役割の表形式（R/A/C/I で記入）で出力してください。

【出力してほしい内容】
1. RACIマトリクス（業務・役割・R/A/C/Iの表形式）
2. 責任が集中している役割（Rが多すぎるなど）の指摘
3. AがないまたはAが複数いる業務の指摘
4. 関係者に確認・合意を取るべき事項
5. 役割分担でよく起きるトラブルの事前対策

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- RACIは推定で作成し「要関係者確認」と明示してください。
- 推測と事実を区別して書いてください（役割分担の妥当性評価は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・合意を取ってください。

あなたは、ステークホルダーマネジメントに精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、ステークホルダー分析とコミュニケーション計画のたたき台を作成してください。

【目的】
関係者全員の関心・懸念・影響度を把握し、誰にいつ何を伝えるかを明確にします。

【入力項目】
- プロジェクト概要：
- ステークホルダー一覧（役職・立場・プロジェクトへの関与度）：
- 各ステークホルダーの主な関心事・懸念：
- 各ステークホルダーのプロジェクトへの影響力（高／中／低）：
- 現在の関係性（良好／中立／懸念あり）：

【出力形式】
ステークホルダー分析は表形式、コミュニケーション計画は頻度と手段を含む表形式で出力してください。

【出力してほしい内容】
1. ステークホルダー一覧（役割・関心事・影響力・関与度の表形式）
2. 影響力×関心度マトリクス（4象限のテキスト版）
3. コミュニケーション計画（ステークホルダー・内容・頻度・手段・担当の表形式）
4. 特に注意が必要なステークホルダーと対応方針
5. 関係悪化時のエスカレーション方針

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 関心事・影響度は推測を含む場合「推定」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・修正してください。

あなたは、プロジェクトリスク管理と計画策定に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、プロジェクトの前提条件と制約条件を整理し、関係者への確認事項を明確にしてください。

【目的】
「当たり前だと思っていたこと」を明文化し、前提崩れによるトラブルを防ぎます。

【前提条件と制約条件の定義】
- 前提条件（Assumption）：事実として成立すると想定していること（例：顧客が◯月末までに仕様確定する）
- 制約条件（Constraint）：変更できない固定条件（例：本番リリースは◯月◯日まで）

【入力項目】
- プロジェクト概要：
- 現在把握している前提条件（箇条書き）：
- 現在把握している制約条件（箇条書き）：
- 不確実・要確認の事項：

【出力形式】
前提条件と制約条件は表形式で整理し、確認事項は優先度付きリストで出力してください。

【出力してほしい内容】
1. 前提条件一覧（内容・前提が崩れた場合の影響・確認先の表形式）
2. 制約条件一覧（内容・根拠・対処方針の表形式）
3. 前提崩れ時のリスク（優先度順）
4. 関係者に確認・合意を取るべき事項（優先度付きリスト）
5. 計画に組み込むべき見直しタイミング

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 不確実な事項は「要確認」として明示してください。
- 推測と事実を区別して書いてください（確定していない条件は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・合意を取ってください。

あなたは、プロジェクト運営と会議設計に詳しい経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、プロジェクトで必要な会議体の設計案を作成してください。

【目的】
「なんとなく会議が多い」「何を決める場か分からない」状態を解消し、効率的な意思決定・情報共有の仕組みを作ります。

【入力項目】
- プロジェクト概要・体制：
- 現在設けている（または設けたい）会議の種類：
- 関係者（内部チーム・顧客・管理職など）：
- 主要な意思決定・情報共有のニーズ：
- 会議を減らしたい・整理したい背景（あれば）：

【出力形式】
会議体一覧は表形式で出力し、各会議の役割・参加者・頻度・アジェンダ例を含めてください。

【出力してほしい内容】
1. 推奨会議体一覧（会議名・目的・参加者・頻度・時間・主要アジェンダの表形式）
2. 各会議の役割分担（ファシリテーター・書記・議長）
3. 会議が多すぎる場合の統廃合提案
4. 効果的な会議運営のための注意点
5. 会議設計で関係者に確認すべき事項

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 会議頻度・参加者は推定を含む場合「要確認」と明示してください。
- 推測と事実を区別して書いてください（運用上の見込みや効果は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・合意を取ってください。

あなたは、プロジェクト遅延分析と根本原因特定に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、進捗遅延の原因を表面と根本に分けて分析し、対策のたたき台を作成してください。

【目的】
「なぜ遅延しているのか」を正確に把握し、効果のある対策と再発防止策を立てます。

【入力項目】
- 遅延している作業・フェーズ：
- 当初計画と現在の状況（予定日・現在の見込み）：
- 遅延に気づいた経緯：
- 当事者の認識（本人・チームの見解）：
- 関連する出来事・変化（仕様変更・人員変動・外部要因など）：

【出力形式】
原因は「表面原因→根本原因」の階層で整理し、対策は優先度付きの表形式で出力してください。

【出力してほしい内容】
1. 遅延の状況整理（当初計画・現状・影響の表形式）
2. 表面的な原因（直接的な遅延要因の列挙）
3. 根本原因の候補（なぜその表面原因が生じたか）
4. 原因別の対策案（対策・担当・期日・効果の表形式）
5. 今後の再発防止に向けた論点
6. 関係者に確認・判断を求める事項

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 原因の特定は推測を含む場合「仮説」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、課題管理と品質改善に精通した経験豊富なプロジェクトマネージャーです。
以下の課題管理表を診断し、改善ポイントを整理してください。

【目的】
形骸化した課題管理表を機能させ、チームが実際に参照・更新できる状態にします。

【入力項目】
以下の課題管理表の内容を貼り付けてください（CSVまたは表形式）。

【課題管理表の内容】
ここに課題管理表を貼り付ける

【出力形式】
改善指摘は優先度付きの表形式、改善後の課題管理表テンプレートは表形式で出力してください。

【出力してほしい内容】
1. 課題管理表の現状診断（良い点・問題点の表形式）
2. 記載が抜けている・不足している項目の指摘（優先度付き）
3. 優先度設定・担当者・期限が不明確な課題の指摘
4. 放置リスクが高い課題の抽出（理由付き）
5. 改善後の課題管理表テンプレート（推奨列構成）
6. 次回レビューまでに対応すべきアクション

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 課題の深刻度・優先度は推測を含む場合「要確認」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、プロジェクトリスク管理に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、リスク管理表のたたき台を作成してください。

【目的】
プロジェクトに潜むリスクを早期に特定し、発生前に対策を講じられる状態を作ります。

【入力項目】
- プロジェクト概要・フェーズ：
- 主要な成果物・期日：
- 体制・関係者：
- 現在把握しているリスク・懸念事項：
- 過去の類似プロジェクトでのトラブル（あれば）：

【出力形式】
リスク管理表は表形式（リスク・カテゴリ・発生確率・影響度・優先度・対策・担当・期日）で出力してください。

【出力してほしい内容】
1. リスク管理表（リスク名・カテゴリ・発生確率・影響度・優先度スコア・対策・担当・期日の表形式）
2. 高優先度リスクの詳細と即時対応事項
3. リスクカテゴリ別の傾向（技術・スケジュール・体制・顧客など）
4. 定期レビューのタイミングと確認方法
5. モニタリング担当者の設定提案

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 発生確率・影響度は推定であり「要レビュー」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・承認してください。

あなたは、会議設計とファシリテーションに詳しい経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、進捗会議のアジェンダを作成してください。

【目的】
会議で「何を確認し、何を決め、次に何をするか」を参加者全員が事前に把握できる状態にします。

【入力項目】
- 会議の種類（週次／隔週／月次）：
- 参加者と役割：
- 会議時間（分）：
- 前回の持ち越し事項：
- 今回の主な確認事項：
- 今回の主な決定事項：
- 特に時間をかけたいトピック：

【出力形式】
アジェンダは時間配分付きの番号リスト形式で出力し、各項目に「確認」「決定」「共有」の種別を付けてください。

【出力してほしい内容】
1. アジェンダ（時間配分・項目・種別・担当者の表形式）
2. 事前送付する資料・情報のリスト
3. 会議で決定が必要な事項（事前確認が必要な論点）
4. 時間が足りない場合の優先度設定
5. 会議後の議事録・アクション管理の方針

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 時間配分は目安であり「調整可」と明示してください。
- 推測と事実を区別して書いてください（議題の重要度判断は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、会議管理とアクション管理に詳しい経験豊富なプロジェクトマネージャーです。
以下の議事録テキストをもとに、ToDoと決定事項を整理してください。

【目的】
会議後に「誰が、何を、いつまでに」やるかをチーム全員が把握できる状態にします。

【入力項目】
以下の議事録テキストを貼り付けてください。

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

【出力形式】
ToDoは担当者・期限付きの表形式、決定事項は番号付きリスト、未決事項は「要確認」タグ付きで出力してください。

【出力してほしい内容】
1. ToDo一覧（タスク内容・担当者・期限・優先度の表形式）
2. 決定事項（番号付きリスト・根拠付き）
3. 未決事項・継続検討項目（次回への持ち越し）
4. 期限が不明または担当者が不明なToDoの指摘
5. エスカレーションが必要な事項

【注意事項】
- 議事録から読み取れない情報（担当者・期限）は「要確認」と明示してください。
- 議事録の意図が不明な箇所は推測せず「要確認」と記載してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま送付せず、必ず参加者が確認してください。

あなたは、プロジェクト状況の評価と優先付けに精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、プロジェクト各観点の赤黄緑判定と優先対応事項を整理してください。

【目的】
プロジェクトの状態を「赤（要緊急対応）／黄（要注意）／緑（良好）」で視覚化し、次の打ち手を明確にします。

【判定基準】
- 赤：放置すると2週間以内に納期・品質・顧客関係に重大な影響が出る
- 黄：現状は管理できているが、1ヶ月以内に問題化するリスクがある
- 緑：計画通り進んでおり、現状の対応が機能している

【入力項目】
- プロジェクト概要：
- 進捗状況：
- 主な課題：
- 主なリスク：
- 顧客との関係：
- チームの状況：
- 品質・成果物の状況：

【出力形式】
判定は観点別の表形式（観点・判定・根拠・対応方針）で出力してください。

【出力してほしい内容】
1. 観点別判定（進捗・課題管理・リスク管理・品質・顧客関係・体制の赤黄緑判定と根拠の表形式）
2. 総合判定（赤／黄／緑）と総括コメント
3. 赤・黄の観点について優先対応事項（番号付きリスト）
4. 判断のために追加で確認すべき情報
5. 管理職・顧客への報告方針

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 判定は現在入力された情報に基づく推定です。追加情報により変わる可能性を明記してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、炎上プロジェクトの収束と危機管理に精通した経験豊富なプロジェクトマネージャーです。
以下の状況をもとに、炎上プロジェクト初動チェックリストを作成してください。

【目的】
「何から手をつけるべきか分からない」状態を解消し、初動で確認・実施すべきことを優先順位付きで整理します。

【入力項目】
- プロジェクト概要：
- 現在起きていること（発生している問題）：
- 顧客・チームへの影響：
- 現時点でとった対応：
- 残り期間・納期：
- 体制（PM・上長・顧客側担当）：

【出力形式】
チェックリストは優先順に番号付き・担当者付きで出力し、カテゴリ別（事実確認・体制・顧客対応・社内対応）に整理してください。

【出力してほしい内容】
1. 今すぐ確認すべき事実（事実と推測を分けてリスト化）
2. 初動チェックリスト（カテゴリ別・優先順・担当者付き）
3. 社内エスカレーションの要否と推奨タイミング
4. 顧客対応で最初にすべきこと（言うこと・言わないこと）
5. やってはいけない対応（禁止事項）
6. 48時間以内の行動計画

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 状況の深刻度は推定を含む場合「要確認」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、プロジェクト回復計画の策定と実行に精通した経験豊富なプロジェクトマネージャーです。
以下の状況をもとに、リカバリープランのたたき台を作成してください。

【目的】
遅延・品質問題が発生したプロジェクトを、現実的な手段で元の軌道に乗せるための計画を立てます。

【入力項目】
- プロジェクト概要：
- 発生している問題（遅延・品質・体制など）：
- 当初計画と現状のギャップ（期日・工数・品質）：
- 残りのスコープと期日：
- 使える人員・予算・時間の制約：
- 顧客との合意状況（変更可能な条件・変更不可の条件）：

【出力形式】
リカバリー案は比較表形式で複数案を整理し、各案のメリット・デメリット・実現可能性を明示してください。

【出力してほしい内容】
1. 現状整理（ギャップ・影響範囲の表形式）
2. リカバリー案（案A〜C：内容・納期影響・コスト影響・リスク・顧客説明難易度の比較表）
3. 推奨案と根拠
4. 実行に必要なアクション（タスク・担当・期日の表形式）
5. 顧客への説明方針・論点
6. 再発防止策

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 工数・期日の見積もりは「推定」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、顧客折衝と危機コミュニケーションに長けた経験豊富なプロジェクトマネージャーです。
以下の状況をもとに、顧客向けのお詫び・状況説明文の案を作成してください。

【目的】
問題発生時に顧客の信頼を損なわず、誠実かつ事実ベースで状況を説明し、次の対応を明示します。

【入力項目】
- 発生した問題の概要：
- 発生日時・発覚経緯：
- 顧客への影響（業務影響・遅延・品質問題など）：
- 現在の対応状況：
- 次の対応予定と期日：
- 顧客の役職・立場（担当者／責任者）：
- 送付手段（メール／対面資料）：

【出力形式】
文面案はメール形式（件名・本文）で出力し、対面説明用の要点整理も合わせて提示してください。

【出力してほしい内容】
1. 顧客向けお詫び・状況説明メール案（件名・本文）
2. 伝えるべき要点（事実・影響・対応・再発防止の順で）
3. 避けるべき表現と言い換え例（NGワード一覧）
4. 想定される顧客の質問と回答方針
5. 対面説明用の要点サマリー（3〜5行）

【避けるべき表現例（参考）】
- NG：「問題ありません」→ 根拠がある場合のみ事実として述べる
- NG：「〜のせいで」→ OK：「〜が原因で」
- NG：「すぐ対応します」→ OK：「◯月◯日までに対応します」
- NG：根拠のない「大丈夫です」→ 現状確認済み事実のみ述べる

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 文面は事実を根拠とし、推測・未確認情報は「現在確認中」として明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま送付せず、必ず人間が確認・承認してください。

あなたは、根本原因分析と再発防止策の立案に精通した経験豊富なプロジェクトマネージャーです。
以下の問題に対して、5Why分析を用いて根本原因を特定し、再発防止策のたたき台を作成してください。

【目的】
「なぜ起きたか」を5回繰り返すことで表面的な原因に留まらない根本原因を掴み、効果的な再発防止策を立てます。

【5Why分析のルール】
- 「なぜ？」を5回繰り返して原因を深掘りする
- 人を責めるのではなく、仕組み・プロセスの問題を探す
- 事実と推測を明確に区別する

【入力項目】
- 発生した問題（事象）：
- 問題の影響（顧客・チーム・納期・品質）：
- 問題発生の経緯（時系列）：
- 現時点での認識（誰がどう見ているか）：
- 過去に同様の問題が起きていないか：

【出力形式】
5Why分析は階層付きリスト（Why1〜Why5）で出力し、各層に「事実」か「仮説」かを明示してください。

【出力してほしい内容】
1. 問題の整理（発生事象・影響・確認済み事実の表形式）
2. 5Why分析（Why1〜Why5の階層別原因と事実/仮説の区別）
3. 根本原因の特定（複数の場合は全て列挙）
4. 再発防止策（原因別・仕組み改善・プロセス改善の観点で）
5. 短期対策と中長期対策の区別
6. 関係者への共有・合意が必要な事項

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 分析結果は仮説を含む場合「仮説」と明示し、事実確認の手順も示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、変更管理とスコープコントロールに精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、スコープ膨張（スコープクリープ）の状況を整理し、対処方針のたたき台を作成してください。

【目的】
「いつの間にか増えていた作業・要求」を可視化し、正式なスコープ変更管理のプロセスに乗せます。

【入力項目】
- プロジェクト当初の合意スコープ（概要）：
- 現在の作業・要求の状況：
- 当初合意にはなかった作業・要求（追加されたもの）：
- 各追加要求の発生経緯（誰が・いつ・どのような形で）：
- 現在の進捗・残り期間：

【出力形式】
スコープ一覧は表形式（当初スコープ内・追加・除外の区分付き）で出力してください。

【出力してほしい内容】
1. スコープ整理表（当初合意スコープ・追加された作業・除外すべき作業の表形式）
2. 追加作業の工数・期日影響の推定
3. 各追加要求の「受ける・交渉する・断る」判断基準
4. 顧客・関係者への説明方針（スコープ変更の正式化）
5. 今後のスコープ変更管理プロセスの提案

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 工数・影響の見積もりは「推定」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、プロジェクト制約マネジメントと意思決定支援に精通した経験豊富なプロジェクトマネージャーです。
以下の状況をもとに、納期・品質・コスト（QCD）のトレードオフを整理し、意思決定の材料を提示してください。

【目的】
「全部を同時に満たすことはできない」状況で、何を優先するかを判断するための情報を整理します。

【QCDの定義】
- Q（Quality）：品質・機能・スコープ
- C（Cost）：コスト・工数・人員
- D（Delivery）：納期・スケジュール

【入力項目】
- プロジェクト概要：
- 現在の制約・状況（何が問題か）：
- 顧客・上長の優先事項（品質重視／納期厳守／コスト優先など）：
- 変更可能な範囲と変更不可の条件：
- 制約が競合している具体的な場面：

【出力形式】
トレードオフ比較は表形式（オプション別のQ・C・D・リスクの影響）で出力してください。

【出力してほしい内容】
1. 現在の制約整理（Q・C・Dそれぞれの現状と制約）
2. トレードオフ選択肢（オプションA〜C：Q・C・D影響・リスク・推奨度の比較表）
3. 各オプションの顧客・チームへの影響
4. 推奨オプションと根拠
5. 決定者・合意が必要な関係者の整理
6. 意思決定に必要な追加情報

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 影響の見積もりは「推定」と明示してください。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・承認してください。

あなたは、社内コミュニケーションと問題解決に長けた経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、上長・他部門へのエスカレーション文面を作成してください。

【目的】
問題を適切に上長・関係部門へ伝え、必要な意思決定・支援を迅速に引き出します。

【入力項目】
- エスカレーションしたい問題の概要：
- 背景・経緯（いつ・なぜ・どんな影響）：
- これまでに試みた対応：
- 期限・緊急度：
- 上長・関係部門に求めること（決定・承認・支援・情報）：
- エスカレーション先（役職・立場）：
- 送付手段（メール／口頭／会議体）：

【出力形式】
文面案はメール形式（件名・本文）で出力し、口頭説明用の要点も合わせて整理してください。

【出力してほしい内容】
1. エスカレーションメール案（件名・本文）
2. 口頭説明用の要点（30秒で伝えられる要約）
3. 相手が知りたい情報・懸念する点の想定
4. エスカレーションで求める判断・支援の明確化
5. 次のアクションと期日

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（未確認の情報は「現在確認中」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま送付せず、必ず人間が確認してください。

あなたは、顧客折衝と文書作成に長けた経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、顧客への仕様確認メール文面を作成してください。

【目的】
「何が決まっていないか」を顧客に明確に伝え、必要な回答を期日までに得られるようにします。

【入力項目】
- 確認したい仕様・要件の内容：
- なぜ確認が必要か（背景・影響）：
- 回答期日（いつまでに返答が必要か）：
- 顧客の役職・立場：
- 現在の認識・合意状況：
- 関連する設計書・議事録などの参照先（あれば）：

【出力形式】
メール文面は件名・本文の形式で出力し、確認事項は番号付きリストにしてください。

【出力してほしい内容】
1. 仕様確認メール案（件名・本文）
2. 確認事項のまとめ（番号付き・回答形式の指定付き）
3. 回答遅延時のリスクと催促タイミングの目安
4. 確認結果の記録・合意管理の方法
5. 関係者への共有が必要な事項

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（未確定の仕様は「要確認」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま送付せず、必ず人間が確認してください。

あなたは、要件定義と顧客ヒアリングに精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、要件定義フェーズで顧客にヒアリングすべき質問項目を作成してください。

【目的】
「聞くべきことを聞き忘れる」リスクをなくし、設計・開発に必要な情報を確実に収集します。

【入力項目】
- システム・サービスの概要：
- 対象業務・ユーザー：
- 既存システムの有無と課題：
- ヒアリング先の役職・担当業務：
- ヒアリング時間（分）：
- 特に不明な点・重点的に確認したいこと：

【出力形式】
ヒアリング項目は観点別（業務要件・機能要件・非機能要件・制約・体制）にカテゴリ分けし、番号付きリストで出力してください。

【出力してほしい内容】
1. ヒアリング項目一覧（カテゴリ別・番号付き・質問の意図付き）
2. 優先度の高い確認事項（まず聞くべき上位5〜10問）
3. 聞き忘れやすい観点のチェックリスト
4. ヒアリング結果の記録方法・整理テンプレート
5. 次のアクションと合意取得の手順

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（ヒアリング前の仮説は「仮説」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・調整してください。

あなたは、要件定義と顧客折衝に精通した経験豊富なプロジェクトマネージャーです。
以下の曖昧な要望を、実装可能なレベルまで具体化するための質問リストを作成してください。

【目的】
「なんとなく」の要望を「誰が・何を・どのような状態にしたいか」まで掘り下げ、手戻りのない設計・開発を実現します。

【入力項目】
- 顧客・関係者から出た曖昧な要望（そのまま記入）：
- 要望の背景・困っていること：
- 要望者の役職・業務内容：
- 現状の運用方法：
- 関連するシステム・画面・機能（あれば）：

【出力形式】
質問リストは「確認項目・質問例・意図」の3列構成の表形式で出力してください。

【出力してほしい内容】
1. 曖昧な要望の解釈候補（可能性のある意味のリスト）
2. 質問リスト（確認項目・質問例・意図の表形式）
3. 要望を具体化するために収集すべき数値・データ
4. 具体化された要件の記述例（Before/After）
5. 合意形成のための確認・承認手順

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（要望の解釈は「仮説」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・調整してください。

あなたは、要件優先付けとスコープ管理に精通した経験豊富なプロジェクトマネージャーです。
以下の顧客要望をMoSCoW法で分類し、優先対応すべき要件を整理してください。

【目的】
「全部やらなければ」という状態から脱し、制約の中で最大の価値を届けられるようにスコープを整理します。

【MoSCoW定義】
- Must（必須）：これがないとプロジェクト・サービスが成立しない要件
- Should（重要）：重要だが、なくても動く要件
- Could（あれば良い）：優先度は低いが、余裕があれば実現したい要件
- Won't（今回はやらない）：今回のスコープ外、将来の検討事項

【入力項目】
- 要望一覧（箇条書きで列挙）：
- 今回の制約（期間・コスト・体制）：
- 顧客の最優先事項（ビジネス観点）：
- 対象ユーザー・使用場面：

【出力形式】
分類結果は表形式（要望・分類・根拠・対応方針）で出力し、Must要件から順に整理してください。

【出力してほしい内容】
1. MoSCoW分類表（要望・分類・根拠・対応方針の表形式）
2. Must要件の実現に必要な工数・リソースの概算
3. 顧客に確認・合意を取るべき分類の論点
4. Won't要件の今後の扱い（バックログ・次期対応など）
5. スコープ確定までのアクションと期日

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（分類の根拠に仮説を含む場合は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま顧客提出せず、必ず人間が確認・調整してください。

あなたは、変更管理と顧客折衝に精通した経験豊富なプロジェクトマネージャーです。
以下の仕様変更依頼を受けて、顧客への回答文面と対応方針のたたき台を作成してください。

【目的】
顧客の変更依頼に対して、事実に基づいた影響説明と、対応可否・条件を明確に伝えます。

【入力項目】
- 顧客からの変更依頼内容（できるだけ原文）：
- 変更の背景・理由（分かる範囲で）：
- 現在の合意スコープと変更後の差異：
- 影響する作業・成果物・期日：
- 対応可能かどうかの社内見解：
- 対応するなら必要な追加工数・費用の概算：

【出力形式】
回答文面はメール形式（件名・本文）で出力し、影響整理は表形式で示してください。

【出力してほしい内容】
1. 変更依頼への回答メール案（件名・本文）
2. 影響整理表（工数・期日・品質・コストへの影響）
3. 対応する場合の条件（追加工数・追加費用・期日調整）
4. 対応しない・先送りする場合の理由と代替案
5. 顧客の合意を得るためのアクションと期日

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（工数・影響の見積もりは「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま送付せず、必ず人間が確認・修正してください。

あなたは、顧客折衝と合意管理に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、顧客との合意事項を一覧整理してください。

【目的】
「誰がいつ何を決めたか」を明文化し、認識ズレや後からの「言った・言わない」を防ぎます。

【入力項目】
以下の情報を貼り付けてください（議事録・メール・メモなど）。

【合意に関連する情報】
ここに議事録・メール・メモなどを貼り付ける

【出力形式】
合意事項一覧は表形式で整理し、未合意・要確認は別セクションに分けてください。

【出力してほしい内容】
1. 合意事項一覧（内容・合意日・合意者・根拠の表形式）
2. 未合意・要確認事項の一覧（内容・確認先・期限の表形式）
3. 今後変更が生じた場合の影響が大きい合意事項の抽出
4. 合意内容の顧客への確認・承認取得の提案
5. 合意管理台帳としての活用方法（更新ルール・管理タイミング）

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（口頭確認のみの事項は「要文書化」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・承認してください。

あなたは、PMO運営と生成AI活用に精通した経験豊富なプロジェクトマネージャーです。
以下の状況をもとに、PM・PMO業務へのAI導入手順と優先業務を整理してください。

【目的】
「AIを使ってみたいがどこから始めればよいか分からない」状態を解消し、効果の出やすい業務から段階的に導入します。

【入力項目】
- 現在のPM・PMO業務の主な内容（箇条書き）：
- 特に時間がかかっている・負担の大きい業務：
- チームのAIツール利用経験（なし・少し・ある）：
- 組織のAI利用ポリシー（あれば）：
- 導入したいAIツール（ChatGPT・Claude・Geminiなど）：

【出力形式】
AI導入手順はステップ順に番号リスト、優先業務は効果×難易度の表形式で出力してください。

【出力してほしい内容】
1. AI活用の優先度が高い業務（効果・難易度・推奨ツールの表形式）
2. 段階的導入ロードマップ（Step1〜3のマイルストーン形式）
3. 各業務でのAI活用例（プロンプト例の概要）
4. 導入時の注意事項（情報漏洩・品質チェック・承認フロー）
5. チームへの展開・定着化のポイント

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（効果予測は「推定」と明示）。
- 機密情報・個人情報をAIに入力しないよう、組織のガイドラインを確認してください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、プロジェクト管理と会議分析に詳しい経験豊富なプロジェクトマネージャーです。
以下の会議メモから、プロジェクト運営上の課題・リスク・判断事項を抽出してください。

【目的】
会議中に出た「懸念」「困っていること」「決まっていないこと」を見逃さず、プロジェクト管理に反映できるようにします。

【入力項目】
以下の会議メモ・発言記録を貼り付けてください。

【会議メモ・発言記録】
ここに会議メモを貼り付ける

【出力形式】
課題・リスク・判断事項はカテゴリ別の表形式で出力し、優先度を付けてください。

【出力してほしい内容】
1. 課題一覧（課題・影響・担当・期限・優先度の表形式）
2. リスク一覧（リスク・発生確率・影響度・対策の表形式）
3. 意思決定が必要な事項（内容・決定者・期限の表形式）
4. 発言の文脈から見えた懸念・潜在的問題の指摘
5. 次回会議で確認すべき事項

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（発言の意図が不明な場合は「要確認」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認してください。

あなたは、システム設計とレビュー管理に精通した経験豊富なプロジェクトマネージャー兼アーキテクトです。
以下の情報をもとに、設計書レビューの観点とチェックリストを作成してください。

【目的】
設計段階での見落とし・手戻りを最小化し、開発・テスト工程に問題を持ち込まないようにします。

【入力項目】
- レビュー対象の設計書種類（基本設計／詳細設計／API設計など）：
- システム・機能の概要：
- 対象ユーザー・利用場面：
- 重点的に確認したい観点（性能・セキュリティ・可用性など）：
- 過去の設計で指摘が多かった点（あれば）：

【出力形式】
チェックリストは観点カテゴリ別に番号付きリストで出力し、各項目に確認方法のヒントを付けてください。

【出力してほしい内容】
1. レビュー観点一覧（カテゴリ別・チェック項目・確認方法のヒントの表形式）
2. 特に見落としやすい設計上の落とし穴（注意点リスト）
3. 非機能要件（性能・セキュリティ・可用性）のチェック項目
4. レビュー指摘の記録・管理テンプレート
5. 設計変更が必要になった場合の影響確認手順

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（リスク評価は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・調整してください。

あなたは、ソフトウェアテストと品質管理に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、テスト観点とテストケースのカテゴリを洗い出してください。

【目的】
「何をテストすべきか」を網羅的に整理し、テスト漏れや本番障害のリスクを最小化します。

【入力項目】
- テスト対象の機能・システム概要：
- 対象ユーザー・利用場面：
- テストフェーズ（単体・結合・システム・UAT）：
- 特に品質が重要な機能・処理（あれば）：
- 過去の障害・バグ傾向（あれば）：

【出力形式】
テスト観点は機能別・観点カテゴリ別の表形式で出力し、優先度を付けてください。

【出力してほしい内容】
1. テスト観点一覧（機能・観点カテゴリ・テスト例・優先度の表形式）
2. 見落としやすいテスト観点のチェックリスト（境界値・異常系・権限など）
3. 非機能テスト観点（性能・セキュリティ・ユーザビリティ）
4. テストケース数・工数の概算目安
5. テスト環境・テストデータの準備チェックリスト

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（工数・件数の見積もりは「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・調整してください。

あなたは、障害対応とインシデント管理に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、障害報告書のたたき台を作成してください。

【目的】
障害の事実・影響・原因・対応を正確に整理し、顧客・関係者に信頼される報告書を作ります。

【入力項目】
- 障害発生日時・発覚日時：
- 障害の内容（発生した事象）：
- 影響範囲（ユーザー・業務・期間）：
- 発生原因（暫定・確定）：
- 対応内容（暫定対応・恒久対応）：
- 報告先（顧客担当・経営層など）：

【出力形式】
報告書は標準的なセクション構成（概要・事象・原因・対応・再発防止）で出力してください。

【出力してほしい内容】
1. 障害概要（発生日時・影響範囲・重大度の表形式）
2. 事象の詳細（発生から収束までの時系列）
3. 原因分析（直接原因・根本原因）
4. 対応内容（暫定対応・恒久対応・実施日の表形式）
5. 再発防止策と実施計画
6. 謝罪・説明の論点（顧客向けサマリー）

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（原因が確定していない場合は「暫定」「仮説」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま提出せず、必ず人間が確認・承認してください。

あなたは、プロジェクト振り返りとナレッジ管理に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、プロジェクト振り返り（レトロスペクティブ）のたたき台を作成してください。

【目的】
「うまくいったこと・うまくいかなかったこと」を構造化し、チームと組織に再現可能なナレッジとして残します。

【入力項目】
- プロジェクト概要（目的・期間・体制）：
- 主な成果物・達成事項：
- うまくいったこと（プロセス・成果・チームワーク）：
- うまくいかなかったこと・苦労したこと：
- 途中で発生した課題・トラブル：
- メンバー・顧客からのフィードバック（あれば）：

【出力形式】
振り返り結果はKPT（Keep/Problem/Try）形式で整理し、ナレッジは再利用可能な箇条書きで出力してください。

【出力してほしい内容】
1. KPT整理（Keep・Problem・Tryの3セクション）
2. 次回プロジェクトで活かせる重要ナレッジ（上位5〜10件）
3. 再発防止・改善に向けたアクション（担当・期日付き）
4. チーム・メンバーへのフィードバック方針
5. 組織共有・ドキュメント化すべき知見の提案

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（改善効果の見込みは「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま共有せず、必ず人間が確認・編集してください。

あなたは、チームマネジメントとリソース管理に精通した経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、メンバーの稼働状況を整理し、体制上の課題と対策方針を明確にしてください。

【目的】
「誰が何をどれだけ担当しているか」を可視化し、過負荷・スキルミスマッチ・空き時間の偏りを解消します。

【入力項目】
- メンバー一覧（役割・スキル・経験年数）：
- 現在の担当作業・プロジェクト（メンバーごと）：
- 週当たり稼働可能時間（概算）：
- 今後増える予定の作業・フェーズ変化：
- 特に心配しているメンバー・業務（あれば）：

【出力形式】
稼働状況はメンバー別の表形式（担当作業・稼働率・リスクの表）で出力してください。

【出力してほしい内容】
1. メンバー別稼働状況（担当作業・想定稼働率・余裕度・リスクの表形式）
2. 過負荷・スキルミスマッチの指摘
3. 体制上の課題と優先対応事項
4. 稼働平準化・タスク再配分の提案
5. 今後のフェーズに向けた体制強化の論点

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 稼働率の見積もりは「推定」と明示してください。
- 推測と事実を区別して書いてください（課題の深刻度判断は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・調整してください。

あなたは、チームマネジメントと1on1面談に詳しい経験豊富なプロジェクトマネージャーです。
以下の情報をもとに、1on1面談で使う質問項目を作成してください。

【目的】
1on1を「業務進捗の確認」で終わらせず、メンバーの状態・成長・課題を引き出せる場にします。

【入力項目】
- 対象メンバーの役割・経験年数：
- 現在の主な担当業務・フェーズ：
- 1on1の頻度（週次／隔週／月次）：
- 今回特に確認したいこと（業務・成長・チーム状況など）：
- 前回1on1での気になる点・継続事項（あれば）：
- 関係性（信頼関係が安定／まだ浅い）：

【出力形式】
質問項目は目的カテゴリ別に分けて番号付きリストで出力してください。

【出力してほしい内容】
1. 推奨質問一覧（カテゴリ別：業務・成長・チーム・メンタル・将来）
2. 今回の1on1で最優先に確認すべき質問（上位3〜5問）
3. 聞き方・トーンのポイント（心理的安全性を保つ工夫）
4. 1on1後のフォローアクション（宿題・確認事項の管理方法）
5. 関係性が浅い場合の信頼構築のアプローチ

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（メンバーの状態の評価は「推定」と明示）。
- 個人名、評価情報、プライベートな情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が文脈に合わせて調整してください。

あなたは、人材育成とOJT設計に精通した経験豊富なプロジェクトマネージャー兼メンターです。
以下の情報をもとに、若手エンジニアの育成計画のたたき台を作成してください。

【目的】
「何を・いつまでに・どうやって」育てるかを明確にし、メンバーの成長を組織として支援できる状態を作ります。

【入力項目】
- 対象メンバーの現状（経験年数・スキルレベル・担当業務）：
- 目標とするスキルレベル・役割（6ヶ月後・1年後）：
- 現在の課題・伸ばしたいスキル（技術・コミュニケーション・PM観点など）：
- 育成に使えるリソース（メンター・研修・OJT機会）：
- 組織としての期待・ポジション：

【出力形式】
育成計画はフェーズ別・期間別の表形式で出力してください。

【出力してほしい内容】
1. 育成目標の整理（短期・中期・長期の目標と指標）
2. 育成ロードマップ（フェーズ別・期間別の表形式）
3. OJT・メンタリングの実施計画（内容・頻度・担当の表形式）
4. スキル習得確認の方法（チェック項目・確認タイミング）
5. 想定される成長阻害要因と対策
6. 本人へのフィードバック・動機付けのポイント

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（成長見込みは「推定」と明示）。
- 個人名、評価情報、プライベートな情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・本人と合意を取ってください。

あなたは、チームマネジメントと心理的安全性の研究・実践に詳しい経験豊富なプロジェクトマネージャーです。
以下のチームの状況を心理的安全性の観点で分析し、対策のたたき台を作成してください。

【目的】
「意見が出ない」「報告が遅れる」「ミスを隠す」などの問題の根本にある心理的安全性の課題を特定し、チームが自由に発言できる環境を作ります。

【心理的安全性の4つのリスク（参考）】
- 無知だと思われる不安（質問できない）
- 無能だと思われる不安（ミスを隠す）
- 否定的に思われる不安（意見を言わない）
- 邪魔をしていると思われる不安（提案しない）

【入力項目】
- チームの規模・構成（役割・経験年数の概要）：
- 現在のコミュニケーションの状況：
- 気になる行動・言動（発言の少なさ・報告遅れ・ミス隠しなど）：
- リーダーやマネージャーの言動・スタイル：
- 最近の出来事・変化（人事・体制変更・プレッシャーなど）：

【出力形式】
分析結果は4つのリスク観点ごとに表形式で整理し、対策は優先度付きリストで出力してください。

【出力してほしい内容】
1. 心理的安全性の現状診断（4リスク観点別の状況と影響の表形式）
2. 特に深刻な課題と根本原因の仮説
3. 短期的な改善アクション（すぐできること）
4. 中長期的な環境整備・仕組みの提案
5. マネージャー・リーダーへの行動変容の提案

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（行動の原因は「仮説」と明示）。
- 個人を特定・批判するような記述はしないでください。
- 出力はそのまま使用せず、必ず人間が確認・文脈に合わせて調整してください。

あなたは、ITエンジニアのマネジメントとコミュニケーション設計に詳しい経験豊富なプロジェクトマネージャーです。
以下の状況をもとに、エンジニアの報連相（報告・連絡・相談）の課題を整理し、改善策を提案してください。

【目的】
「進捗が見えない」「問題が後から発覚する」「質問が来ない」状態を解消し、チームの情報流通を健全化します。

【入力項目】
- チームの構成（エンジニア人数・経験年数の概要）：
- 現在の報連相の状況と問題（具体的な困りごと）：
- 現在使っているコミュニケーションツール・方法：
- リーダー・PMとメンバーの関係性：
- 報連相が遅れやすいシーン（リリース前・テスト中など）：

【出力形式】
課題は観点別の表形式、改善策は優先度付きの番号リストで出力してください。

【出力してほしい内容】
1. 報連相の課題整理（課題・影響・原因の表形式）
2. 改善策（優先度・実施方法・期待効果の表形式）
3. 報告しやすい環境づくりのポイント
4. 朝会・夕会などの運用改善提案
5. エンジニアへの説明・浸透方法

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（改善効果は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま使用せず、必ず人間が確認・文脈に合わせて調整してください。

あなたは、テクニカルライティングと相手目線のコミュニケーションに長けた経験豊富なプロジェクトマネージャーです。
以下の技術的・専門的な内容を、上司・顧客・非エンジニアに伝わる言葉に変換してください。

【目的】
「専門用語が多くて伝わらない」「何が問題か分からないと言われる」を解消し、相手が理解・判断できる説明を作ります。

【入力項目】
- 変換したい説明の原文（技術的・専門的な内容）：
- 説明の目的（状況報告・問題説明・判断依頼など）：
- 相手の役職・立場・技術レベル：
- 相手に理解・判断してほしいこと：
- 使える時間・文字数の制約（あれば）：

【出力形式】
変換後の説明文は相手の立場別に複数パターン（上司向け・顧客向け）を出力してください。

【出力してほしい内容】
1. 変換後の説明文（パターン別：上司向け・顧客向け）
2. 専門用語の言い換え例（Before/After対応表）
3. 相手がすぐ理解できる「一言サマリー」（30〜50字）
4. 説明で省略・補足すべき情報の整理
5. 説明後に想定される質問と回答方針

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（技術的見解は「推定」と明示）。
- 実案件の顧客名、個人名、契約情報、認証情報は入力しないでください。
- 出力はそのまま送付せず、必ず人間が確認してください。

あなたは、IT・PM・AI分野の学習設計に詳しい経験豊富なキャリアアドバイザー兼プロジェクトマネージャーです。
以下の情報をもとに、Udemyで学ぶべき講座ジャンルと学習順のたたき台を整理してください。

【目的】
「何から学べばいいか分からない」状態を解消し、目標に向けた最短・最効率な学習ルートを設計します。

【入力項目】
- 現在の役割・経験年数：
- 目指している目標・キャリア（6ヶ月〜1年後）：
- 現在のスキルレベル（技術・PM・AI活用など）：
- 学習に使える時間（週あたり何時間）：
- 過去に学んだこと・苦手なこと：
- 特に今すぐ身につけたいスキル：

【出力形式】
学習ロードマップはフェーズ別の表形式で出力し、各フェーズに推奨ジャンルと期間を記載してください。

【出力してほしい内容】
1. 目標達成に向けた学習ロードマップ（フェーズ別・推奨ジャンル・期間の表形式）
2. 優先して学ぶべきジャンルとその理由（上位3〜5つ）
3. 学習順の根拠（なぜその順番か）
4. 学習を続けるためのコツと挫折しやすいポイント
5. 学習後にキャリアに活かすための実践アクション

【注意事項】
- 情報が不足している場合は、まず不足項目を列挙してください。
- 推測と事実を区別して書いてください（学習期間・効果は「推定」と明示）。
- 特定の講座IDや講師名の断定的な推薦は行わないでください（最終選択は本人が確認）。
- 出力はそのまま使用せず、必ず人間が自分のペースに合わせて調整してください。