「ChatGPTにリスクを出させると、どのプロジェクトにも当てはまる一般論が返ってくる」──これはリスク洗い出しにAIを使い始めたPMが最初にぶつかる壁です。
一般論が返ってくるのはAIの性能の問題ではなく、案件固有の前提を入力していないためです。AIは入力した情報以上のことを知りません。前提を整理してから渡すだけで、出力の精度が変わります。
AIにリスクを聞くだけでは一般論になる
「このプロジェクトのリスクを出してください」と書いてAIへ投げると、「コミュニケーション不足のリスク」「スケジュール遅延のリスク」「要件の変更リスク」といった、どのプロジェクトにも当てはまる回答が返ってきます。
これはAIが悪いわけではなく、案件の文脈がゼロの状態から汎用的なリスクを生成しているだけです。PMが「うちのプロジェクトだとここが怖い」と思っている具体の懸念を、AIは知る方法がありません。
逆に言えば、案件の前提情報を丁寧に入力すれば、AIは「この構成なら〇〇が起きやすい」という文脈に沿った候補を出せるようになります。
入力1：案件目的と前提
まずプロジェクトが何を目的としているか、基本の前提を書きます。
- プロジェクトの目的（何を達成するか）
- 背景（なぜ今これをやるか）
- 特殊な制約（法規制、使用システム、顧客の事情など）
例：「老朽化した受注管理システムをクラウドへ移行する。来年3月の会計年度締めまでに稼働させる必要がある。現行システムの設計書が不完全で、実装担当者へのヒアリングが必要。」
この一文があるだけで、AIが出すリスク候補は「設計書不備による仕様認識ズレ」「ヒアリング遅延によるスコープ確定遅延」など、案件に即したものに変わります。
入力2：スコープと対象外
何をやるか（スコープ）と何をやらないか（除外）を書きます。
スコープが曖昧なまま渡すと、AIはリスクの境界線を引けず、関係のない懸念まで出してきます。
例：
- スコープ：受注管理・在庫管理・発注管理の3モジュールを移行する
- 対象外：経理システムとの連携は次フェーズ扱い。今回は手動対応
「対象外」を明記すると、その範囲に関するリスクをAIが出してきたときに「今回は考慮しない」と判断できます。
入力3：体制と制約
プロジェクトメンバーの構成と、分かっている制約を書きます。
- PMの経験年数や専任/兼任の別
- ベンダーの特性（海外拠点、初取引など）
- 顧客担当者の状況（多忙、意思決定が遅いなど）
- インフラ・ツールの制約
「顧客担当者が複数部署を兼任しており、レスポンスに時間がかかる傾向がある」と書けば、AIはコミュニケーション遅延リスクをより具体的な文脈で出せます。
入力4：過去の懸念
同じ類型のプロジェクトや、現在の案件でPM自身が「怖い」と感じている点を書きます。
- 「前回同じ顧客で、テスト期間が圧縮された経緯がある」
- 「要件定義フェーズで顧客内の合意が取れていない部分がある」
- 「担当ベンダーのPMが複数案件掛け持ちで稼働が読めない」
PMの経験的な不安を言語化して入力すると、AIはそれを補強する形でリスク候補を拡張してくれます。直感的に感じていた懸念が構造化される効果があります。
AI出力をPMが取捨選択する方法
前提を整えてAIからリスク候補を受け取ったら、次のステップでPMが判断します。
- 採用する：自分の案件で実際に起きうると判断できるリスク
- 修正する：方向は合っているが粒度や表現が案件に合っていないもの
- 除外する：スコープ外の話や、現状では影響が低いと判断できるもの
AIが出したリスクをそのままリスク台帳に転記しないことが原則です。AIはリスクの候補を出す補助ツールであり、リスクの採否を判断するのはPMの仕事です。
採用したリスクには、発生確率・影響度・対応方針をPMが追加して初めて、機能するリスク管理表になります。
実際のプロンプト構造例
前提4軸を整えたら、次のような形でChatGPTへ渡します。
以下のプロジェクト情報をもとに、想定されるリスクを列挙してください。
PMが事前に対処可能なリスクを優先し、リスク名と発生のトリガーを簡潔に記してください。
【案件目的と前提】
老朽化した受注管理システムをクラウド移行する。来年3月の会計年度締めまでに稼働必要。現行設計書が不完全でエンジニアヒアリングが必要。
【スコープ】
対象：受注管理・在庫管理・発注管理の3モジュール
除外：経理連携は次フェーズ（今回は手動対応）
【体制と制約】
顧客担当者は複数部署兼任でレスポンスに時間がかかる傾向あり。ベンダーPMは複数案件掛け持ち。
【過去の懸念】
前回同顧客案件でテスト期間が圧縮された経緯あり。要件定義で顧客内合意が取れていない部分がある。このプロンプトで得られるリスク候補は「コミュニケーション遅延によるスコープ確定遅延」「設計書不備による認識ズレ」「テスト期間圧縮によるバグ流出リスク」など、案件固有のものになります。
採用したリスクをリスク台帳に落とすステップ
AIから出力されたリスク候補を取捨選択したら、リスク台帳に転記して管理します。転記時に各リスクに追加する項目は3つです。
発生確率（高/中/低）：PMの経験的判断で評価します。AIが出力した候補は、PMの現場感で確率を修正してください。
影響度（高/中/低）：このリスクが顕在化したとき、プロジェクトのスケジュール・コスト・品質に与える影響の大きさで評価します。
対応方針（事前対応/発生後対応/許容）：事前に防ぐか、起きたときに対処するか、影響が小さいため受け入れるかを決めます。
「発生確率：高 × 影響度：高」のリスクから先に事前対応を検討することが、リスク管理の基本優先順位です。AIのリスク洗い出しは量をカバーする補助ツール、台帳への落とし込みはPMの判断仕事、という分業が安定した運用につながります。
リスク台帳の月次レビューを定着させる
リスク台帳は作成したあとに継続的に更新しないと、形骸化します。月に1回、定例会議の前後にリスク台帳を開いて「今月変化したリスクはないか」を確認することが、炎上予防の中核動作です。
月次レビューの手順は3ステップです。
- 前月から変化のあったリスクを更新する（発生確率・影響度・対応方針の変化）
- 顕在化したリスクを「完了」に移す（発生・対処済みの記録として残す）
- 新規リスク候補をAIで追加確認する（月変わりの状況変化を4軸で入力してAIに問う）
この3ステップを30分以内で実施できるようにするには、台帳のフォーマットをシンプルに保つことが条件です。列が多いほど更新が負担になり、結果として台帳が放置されます。発生確率・影響度・対応方針の3列に絞り、コメント欄は1行以内にするルールを自分に課すと、継続しやすくなります。
リスク管理を「台帳を埋める作業」として捉えると続きません。「次の炎上を防ぐための30分」という位置づけで月次レビューを習慣化することが、PMとしての案件品質を安定させる最も確実な方法です。AIを使ったリスク洗い出しは、この習慣をより効率的に実施するための補助手段です。
AIへのリスク洗い出しを続けることで、自分が見落としやすいリスク領域が分かってきます。「このPMはいつも体制リスクを見逃す」「納期交渉のリスクを低く見積もりがち」という個人パターンが、繰り返しの入力と確認を通じて自覚できます。AIを使うことで自分の思考の偏りを補う、というのが上級者の活用法です。
プロジェクト炎上を防ぐリスク管理の実務を体系的に学びたい方は、生成AI×PM実務パックと炎上予防・立て直しパックをご覧ください。
関連Udemyコース一覧はコース一覧ページから確認できます。