プロジェクトマネージャーのAI活用：工程別の使いどころと任せてはいけない領域

線引きを決めないまま使うと、根拠のない見積が独り歩きする

生成AIをプロジェクトマネジメントの実務で使うこと自体は、もはや珍しくありません。詰まるのはその先です。どの工程のどの作業に、どこまで任せるか。ここが決まらないまま使うと、便利さの裏で、根拠のない見積が独り歩きしたり、機密情報が社外のサービスに渡ったりします。判断の材料になるのは、工程ごとの使いどころ、任せてはいけない領域とその理由、そして情報漏洩とガバナンスの線引きの3つです。

業界標準の側も動いています。PMIは2026年6月、ポートフォリオ・プログラム・プロジェクトマネジメントにおけるAIの標準（The Standard for Artificial Intelligence in Portfolio, Program, and Project Management）を公開しました。8つの指導原則と5つのパフォーマンス領域からなります。特定の製品に依存しない技術非依存の設計で、EU AI法やISO 42001といった外部の規制・規格との接点にも触れています。この標準が置いている軸は2つ。AI導入を技術課題として扱わないこと、人間の判断と説明責任を中心に据えることです。

PMP試験の側も同じ方向に動きました。2026年7月に改定された新しい試験内容概要（ECO）では、AIは独立したドメインとして切り出されていません。そのかわり、AIを踏まえた計画・見積・リスク予測・予測分析・報告といった論点が、3つのドメインを横断して置かれています。AIをどう使うかは、PMの専門性の一部として問われる領域になったということです。

前提：AIが強い作業と、そもそも向かない作業

工程別の話に入る前に、線引きの基準を1つ持っておくと迷いが減ります。それは「間違っていたときに、PM自身が短時間で気づけるか」という基準です。AIが得意なのは、大量の候補を素早く並べること、長い文章を要約すること、同じ内容を相手に応じて言い換えること、抜けを指摘させることです。これらはいずれも、出てきた結果をPMが読めばその場で妥当性を判断できます。叩き台としての価値は高く、間違っていても損害になりません。

逆に向かないのは、社内の力関係や過去の経緯、顧客担当者の性格、チームメンバーの実力差といった、文書化されていない文脈に依存する判断です。AIはプロジェクト固有の暗黙の事情を知りません。それらしい文章は出てきますが、その根拠が正しいかどうかをPMが検証できないまま採用すると、誤りに気づく機会がありません。

実務者の自己評価も、この慎重さを裏づけています。PMIが2025年4月に公表したPulse of the Profession 2025は、世界の実務者2,841名を対象とした調査ですが、実践的なAIスキルが「豊富」または「良好」と答えた人は約2割にとどまりました。ツールの普及に対して、使いこなす能力の側が追いついていないというのが、標準団体側の現状認識です。

計画工程：WBSの叩き台と、見積の観点出し

計画工程でAIが最も効くのは、白紙から書き始める時間を消すことです。WBSの作成では、プロジェクトの目的、成果物、制約条件、体制を与えたうえで、成果物ベースの分解案を出させます。得られるのは完成品ではなく叩き台です。実際の価値は、その叩き台をチームのレビューにかけると、議論が「何を書くか」ではなく「この分解でよいか」から始められる点にあります。

使い方のコツは、出力をそのまま採用しないことを前提に、粒度と観点を指定することです。「第3階層まで」「成果物で分解し、工程名では分解しない」「各要素に完了の定義を1文で添える」といった条件を付けると、レビューしやすい形で返ってきます。逆に条件を付けずに投げると、どのプロジェクトにも当てはまる無難な一覧が出てきて、レビューする価値がありません。

見積については、金額や工数の数値そのものをAIに出させることに意味はありません。AIは自社の生産性データも、このチームの実力も、過去の類似案件の実績も知らないからです。使えるのは「観点出し」に限った場面です。この成果物を作るために必要な作業として何を数え忘れがちか、という問いをAIに投げます。テストデータの準備、移行リハーサル、ドキュメントのレビュー対応、環境構築、受入支援といった、見積から落ちやすい項目を列挙させ、自分の見積と突き合わせるのです。同じ発想は、前提条件と制約条件の洗い出しにも使えます。計画書のドラフトを読ませ、「この計画が暗黙に前提としている事柄を列挙せよ」と指示すると、書いた本人には自明すぎて明文化していない前提が浮かび上がることがあります。前提が明文化されれば、それが崩れる可能性はそのままリスクとして管理対象になります。

リスク特定：網羅性のチェックに使う

リスク管理の成否は、洗い出しの網羅性でほぼ決まります。そして網羅性は、その場にいる人の経験の範囲に強く縛られます。ここがAIの使いどころです。推奨できるのは、AIに最初からリスクを列挙させるのではなく、チームで洗い出したあとの「抜け漏れチェック」として使う順序です。先にAIに出させると、チームの発想がその一覧に引きずられ、自社固有のリスクが出てこなくなります。人間が先に出し、そのうえでプロジェクト概要と自分たちのリスク一覧をAIに与え、「この一覧に含まれていないリスクのカテゴリを指摘せよ」と問う。この順序であれば、AIは思考の代替ではなく補完として働きます。

指摘させる切り口を指定すると精度が上がります。技術、外部、組織、プロジェクトマネジメントといった発生源の分類ごとに問う、あるいは調達先、法規制、要員確保、他プロジェクトとの依存関係といった具体的な領域を指定して問う、という使い方です。ステークホルダー分析でも同様に、洗い出した関係者一覧に対して「関与が見落とされがちな立場」を指摘させる使い方ができます。

ただし、AIが出したリスクをそのままリスク登録簿に転記してはいけません。発生確率と影響度の評価、リスクオーナーの指名、対応策とトリガーの設定は、プロジェクトの事情を知る人間の仕事です。AIの出力は「検討すべき論点の候補」であって、「管理すべきリスク」ではありません。この2つを混同すると、誰も本気で見ていない行が並んだ登録簿ができあがります。

実行・監視工程：議事録、課題抽出、ステータスレポート

実行フェーズに入ると、PMの時間の多くは会議と文書に消えます。定型性が高い分、ここは結果が見えやすい。会議の文字起こしからの議事録作成が代表例です。効くのは、単に要約させるのではなく、出力の型を指定することです。決定事項、未決事項、アクションアイテム（担当者と期限を含む）、次回議題、という4区分で出力させると、そのまま運用に載る形になります。あわせて「担当者または期限が特定できていないアクションを明示せよ」と指示すると、会議の場で詰め切れなかった箇所が可視化され、その場で確認すべきことが分かります。

課題の抽出でも同じ考え方が使えます。会議録やチャットのログから「対応が必要だが課題管理表に登録されていない可能性がある事項」を拾わせ、PMが登録の要否を判断します。判断するのは人間で、拾うのがAI、という分担です。ステータスレポートでは、AIに事実を作らせない。これが唯一の線です。進捗率、実績値、課題の件数といった数字は、必ず実データを入力として与えます。AIに任せてよいのは、与えた数字を読み手に合わせた文章に整える部分、および前回報告との差分を指摘する部分です。数字をAIに推測させた瞬間、報告書は信頼を失います。

ステークホルダー向けの文面の書き分けも、実用性の高い用途です。同じ「結合テストが1週間遅延した」という事実でも、経営層向けには影響と対応方針とリスクを先に、現場チーム向けには具体的な作業の変更を先に、顧客向けには事実と原因と復旧見込みを丁寧に、という書き分けが必要です。AIは、読み手と伝えたい要点を指定すれば、この言い換えを短時間で複数案出せます。ただし採用するのはPMであり、悪い知らせを和らげすぎて事実が伝わらなくなっていないかは、必ず人間が確認します。

品質・テスト工程：観点出しと、レビューの網羅性

テスト観点の洗い出しも、リスク特定と同じ構造の作業です。すなわち、経験の範囲が網羅性の上限になる作業であり、AIによる補完が効きます。仕様や受入条件を与えたうえで、正常系だけでなく、境界値、異常系、同時実行、権限の組み合わせ、データ移行後の整合性、障害からの復旧といった観点で不足を指摘させます。ここでも順序は同じで、テスト設計者が先に観点を出し、AIには抜けの指摘をさせるのが安全です。

受入基準の明確化にも使えます。「操作しやすいこと」「性能が十分であること」といった検証不能な受入条件をAIに読ませ、「この基準で合否をどう判定するか」と問うと、判定基準が定義されていないことが浮き彫りになります。曖昧な受入条件は検収時の紛争の火種になるため、計画段階で潰しておく価値があります。ただし、仕様書やテストケースは多くの場合そのプロジェクトの機密情報です。外部のAIサービスに入力してよいかは、次に述べるガバナンスの判断が先に必要です。

任せてはいけない領域：この5つは人間が持つ

ここまで使いどころを述べてきましたが、線引きの反対側のほうが重要です。次の5つは、AIの出力を参考にすることはあっても、判断そのものを委ねてはいけない領域です。第1に、意思決定の責任です。スコープを削るか納期を延ばすか、この課題をエスカレーションするかしないか、といった判断の結果はPMが負います。AIに「どうすべきか」を尋ねて出てきた案を採用すること自体は問題ありませんが、その判断の理由をPM自身の言葉で説明できない状態で採用してはいけません。説明できないということは、判断していないということです。PMIの標準が人間による監督と説明責任を中心に据えているのも、この点にあります。

第2に、見積の最終確定です。観点出しに使う話は先に書きましたが、数値のコミットメントは別の話です。見積は自社の生産性実績、このチームの構成、過去の類似案件のデータにもとづいて確定するものであり、それらを知らないAIが出した数値には根拠がありません。根拠のない数値でコミットすれば、その責任はAIではなくPMに来ます。

第3に、人事評価と要員評価です。メンバーの成果や適性の評価にAIの判断を用いると、学習データに由来する偏りが評価に混入するおそれがあり、かつ評価された本人に対して説明ができません。評価は不利益処分につながりうる領域であり、根拠の説明可能性が特に強く求められます。文章表現を整える用途と、評価そのものを行う用途は、明確に分けるべきです。

第4に、機密情報の入力です。これは次のブロックで詳しく述べますが、顧客の非公開情報、個人データ、営業秘密、未公表の経営情報は、社内で許可された環境以外に入力してはいけません。第5に、顧客への一次回答です。障害の原因説明、契約解釈、責任範囲に関する回答をAIの出力のまま送ることは避けるべきです。事実確認を経ていない説明は、後から訂正しても信頼が戻りません。AIは社内向けの下書きまでにとどめ、対外的な文面は必ず人間が事実と表現の両面で確認してから出します。

情報漏洩とガバナンス：入力する前に確認すること

PMが扱う情報は、その多くが他社から預かったものです。顧客の業務仕様、要員名簿、価格情報、システム構成。これらを外部のAIサービスに入力する行為は、技術的な問題である前に、契約と法令の問題になります。第1の論点が、秘密保持義務との関係です。顧客と締結した秘密保持契約は、通常、第三者への開示を制限しています。外部のAIサービスへの入力がこの「開示」に当たるかどうかは、サービス提供者との契約条件によって評価が変わります。2026年4月に公表された法務解説では、サービス提供者に機密保持義務が課されているか、適切なセキュリティ措置がとられているかを確認することが重要だと整理されています。

第2の論点が、営業秘密の秘密管理性です。不正競争防止法上の営業秘密として保護されるためには、秘密として管理されている実態が必要です。機密保持義務のない外部サービスに、秘密である旨の管理もせずに入力すると、秘密として管理する意思が外形上認識できなくなり、営業秘密としての保護を失うおそれがあります。自社の情報についても、無警戒に入力してよい理由はありません。

第3の論点が、個人データの取扱いです。個人情報保護委員会は2023年6月2日に、生成AIサービスの利用に関する注意喚起を公表しています。そこで示されている考え方は、個人情報取扱事業者がプロンプトに個人情報を含めて入力する場合、それが特定した利用目的の達成に必要な範囲内であることを確認すべきこと、そして入力した個人データが応答の生成以外の目的、たとえば機械学習に利用される場合には個人情報保護法上の問題を生じうること、というものです。実務的には、入力データが学習に利用されない設定・契約になっているかを事前に確認することが出発点になります。

第4の論点が、社内ルールとの整合です。総務省と経済産業省は、AI事業者ガイドラインを策定しており、2026年3月31日に第1.2版が公表されました。これは拘束力のあるルールではなく、事業者が自主的に検討すべき行動を整理した文書ですが、多くの企業の社内AI利用ルールがこれを参照して作られています。PMとして最低限すべきことは、自社のルールで「どのサービスに」「どの区分の情報まで」入力してよいかを確認し、その範囲内で使うことです。ルールがない状態で個人の判断で使うことが、最も危険な状態です。

運用に落とすと、判断は次の順序になります。まず、この情報の持ち主は誰か。自社か、顧客か、個人か。次に、その情報を外部サービスに渡すことが契約と社内ルールで許されているか。次に、使おうとしているサービスは、入力データを学習に利用しない設定・契約になっているか。最後に、それでも渡す必要があるのか、固有名詞を伏せた抽象化した形で用が足りないか。この4段階を通れば、多くの事故は防げます。実務では4番目で止まる相談が意外に多く、顧客名や製品名を伏せて構造だけを問う形にすれば、たいていは用が足ります。なお、どのサービスが安全かという問いに、製品名で一般的な答えを出すことはできません。同じ提供元でも、個人向けプランと法人向けプランで学習利用の扱いや契約条件が異なることが一般的であり、条件も改定されます。判断すべきは製品名ではなく、自社が締結している契約条件と設定です。

失敗しても捨てられる作業から入れる

組織としてAIをPM業務に入れる場合、いきなり全工程で使おうとすると、たいてい定着しません。2025年7月に11か国の管理職層2,545名を対象に実施された調査では、PMソフトウェアの新規購入を検討する最大のきっかけがAI機能の追加意向であった一方（55%）、最大の課題としてAIの導入そのものを挙げた回答が41%、社内にAIスキルを持つ人材がいないことを挙げた回答が39%、既存の業務フローへの統合の難しさを挙げた回答が36%ありました。同じ調査では、セキュリティを重要と評価した回答が71%に上っています。ツールを入れれば解決する類の課題ではない、ということです。

順序としては、失敗しても損害が小さく、成果が測りやすいところから始めるのが確実です。具体的には、議事録の作成と要約から入り、次にステータスレポートの文章整形、次に叩き台の作成（WBS、テスト観点、リスクの抜け漏れチェック）へ広げる、という順序です。いずれも、出力の正しさをPMがその場で判断でき、間違っていても捨てれば済みます。

同時に決めておくことが2つあります。1つは、入力してよい情報の区分を明文化すること。もう1つは、AIの出力をそのまま外部に出さないという運用ルールです。この2つがないまま利用だけが広がると、事故が起きるまで誰も気づきません。PM自身のスキルの話もしておきます。叩き台が自動で出てくるようになった分、PMの仕事のうち「書く時間」は減ります。減らないのは、出てきたものが正しいかを判断する力、優先順位を決める力、関係者と合意を作る力です。むしろ、一見もっともらしい出力が大量に並ぶ状況で、どれを採用しどれを捨てるかを決める場面が増えます。

守る線は5つです。AIは叩き台と抜け漏れチェックに使い、確定と判断は人間が持つ。人間が先に考え、AIには後から補完させる。数字と事実は必ず実データを与え、推測させない。入力してよい情報の範囲は、契約と社内ルールにもとづいて先に決める。対外的な文面は人間が確認してから出す。なお、この5つを守ったときにPMの工数が何割減るのかという数値は、PMIも各種調査も工程別には公表しておらず、確認できていません。減るのは書く時間であって、判断にかかる時間ではない。現時点で言えるのはそこまでです。