AI PMOとは？進捗を動かす5つの設計

プロジェクト定例の前日、PMOが議事録、課題表、WBS、チャットを見比べている。報告書は整った。ところが、三日前に決まった仕様変更がWBSへ反映されていない。担当者も期限も曖昧なままだ。

ここで生成AIに週報を書かせても、文章作成が速くなるだけである。必要なのは、散らばった情報から「何を決めるべきか」を拾い、人が判断できる形へ戻す仕組みだ。

AI PMOは、PMOを無人化する考え方ではない。決定、課題、変更、リスク、承認を構造化し、プロジェクトの管理サイクルを短くする設計である。

AI PMOとは、報告書を自動生成する仕組みではない

「AI PMO」に統一された公的定義があるわけではない。ここでは、生成AIや機械学習をプロジェクト管理へ組み込み、情報整理、差分検知、判断材料の作成を支援する運用をAI PMOと呼ぶ。議事録の要約も一部だが、そこで止まると管理品質はあまり変わらない。

PMI日本支部のプロジェクトマネジメントにおけるAI活用ガイドは、AI活用に必要な要素として、入力データの要件、情報処理方法、ツール、処理フローを挙げている。PMO業務をAIへ渡すには、先に帳票と流れを決める必要があるということだ。

PMIが2026年6月に公表したAIをポートフォリオ、プログラム、プロジェクト管理へ適用する標準も、人間による監督を全段階へ置いている。AI PMOの主役はAIではない。判断責任を持つPMと、判断に必要な情報を整える仕組みである。

では、どの管理業務から設計すればよいのか。実務では次の5つに分けると扱いやすい。

1. 決定事項を「誰が・何を・いつまでに」で残す

最初の対象は議事録の要約ではなく、決定事項の抽出である。

会議で「この方向で進めましょう」と決まっても、対象、責任者、期限、前提が抜けていれば実行へ移せない。AIには自由文の要約を依頼する前に、次の項目で出力させる。

AIは会話から候補を作れる。ただし、決定者が確定していない発言を「決定済み」と扱わせてはいけない。未確定なら確認待ちへ戻す。

関係者ごとの判断範囲は、ステークホルダーの分析で決める5項目のように先に整理しておくとよい。誰の発言が承認に当たるかを仕様にできるからだ。

2. 課題とリスクを同じ箱へ入れない

次に、課題管理表を整える。よくある失敗は、すでに発生した問題と、将来起こり得るリスクを同じ列へ入れることだ。

• 課題は、発生済みで対応が必要な事象
• リスクは、未発生だが監視や予防が必要な事象
• 依存関係は、別タスクや外部判断が完了しないと進めない条件

この3種類を分けると、AIが提案すべき次の行動も変わる。課題には担当者と解決期限が要る。リスクには発生確率、影響、予防策、発生時の対応が要る。依存関係には先行タスクと解除条件が要る。

AIに優先度を決めさせる場合も、文章の強さで判断させない。顧客影響、品質、納期、費用、法務・セキュリティの5軸で点を付け、根拠を示させる。根拠が見つからない項目はゼロ点にせず、情報不足としてPMへ返す。

PMIの調査は、生成AIを広く使うプロジェクト実務者と、試行段階の実務者の間に活用差があると報告している。一方で、PMIの生成AIとプロジェクト管理に関する調査は、組織的な支援がなければ効果を広げにくいとも指摘する。個人のプロンプト術だけで終わらせず、共通の課題分類と判断軸を持つ必要がある。

3. 仕様変更を差分と影響範囲で追う

プロジェクトが崩れる原因は、変更そのものより、変更の伝播漏れにある。

画面項目を一つ変えた。するとAPI、データ定義、権限、テストケース、運用手順も変わるかもしれない。AI PMOでは、変更依頼を単なるコメントとして保存せず、次の形へ変換する。

1. 変更前と変更後
2. 変更理由
3. 影響する要件ID
4. 影響する成果物
5. 納期と費用への影響
6. 承認者
7. 反映確認の条件

AIには関連資料を検索させ、影響候補を出させる。ただし、候補を自動確定してはいけない。参照できていない資料や、更新されていない仕様があるからだ。

AI要件定義は版管理を先に決めるで扱ったように、比較対象の版が固定されて初めて差分が意味を持つ。AI PMOを導入する前に、最新版の置き場所、更新責任者、承認済みの印を決めておきたい。

SIer案件では変更を契約と検収までつなぐ

たとえば、定例会で「請求データの締め時刻を18時から20時へ変える」と決まったとする。決定ログだけ更新しても足りない。

AIには、次の伝播候補を同じ変更IDへ結びつけさせる。

ここでは承認も二つに分ける。ベンダー内部では、工数と技術影響を承認する。顧客側では、業務変更、費用、納期、受け入れ条件を承認する。片方だけを「承認済み」にすると、実装は進んでも検収で止まる。

AIは変更IDを手掛かりに漏れを探せる。一方、契約変更の要否や顧客承認を確定するのは人である。この責任分界まで管理表へ入れると、冒頭のような「会議では決まったがWBSへ反映されていない」状態を検知しやすくなる。

4. 進捗報告を作業率ではなく証拠へ結びつける

「進捗80%」という報告は、AIにとっても人にとっても扱いにくい。残り20%が一日で終わるのか、承認待ちで二週間止まるのか分からないからだ。

進捗は、成果物と完了条件へ結びつける。

AIはWBS、課題表、変更履歴、成果物の更新日時を突き合わせ、矛盾を見つける役に向いている。「完了」と書かれているのに成果物がない。期限を過ぎているのに課題化されていない。テスト失敗が残るのにリリース判定が進んでいる。こうした不一致を週報の前に出せれば、PMOは転記ではなく調整へ時間を使える。

実行履歴を設計する観点は、AIエージェント監視で残す5つのログも参考になる。AIの提案を採用したのか、誰が修正したのかまで追えると、次回の精度改善にもつながる。

5. 承認と停止条件を管理フローへ組み込む

最後は、AIが止まる条件である。

次の操作は、候補作成までをAIへ任せ、確定は人が行う。

• 納期、予算、契約範囲の変更
• 顧客や外部パートナーへの連絡
• 要件や受け入れ条件の確定
• リスクの受容
• 本番反映やリリース判定
• 個人情報や機密情報を含む出力

停止条件は「危なそうなら止める」では弱い。金額影響あり、外部送信あり、承認者不明、根拠資料なし、複数の最新版候補あり、というように機械判定できる条件へ落とす。

AI PMOの価値は、自動化率の高さではない。判断が必要な場所で正しく止まり、誰に何を確認すべきかを返せることにある。

AI PMOを4週間で試す進め方

全社のプロジェクトを一度に接続すると、帳票差と権限差の調整だけで止まる。最初は一つのプロジェクト、一つの管理サイクルに絞る。週ごとの作成物と合格条件を対応させると、試行がデモで終わりにくい。

評価は週報作成時間だけにしない。決定事項の反映漏れ、期限超過課題の検知率、変更影響の確認時間など、管理品質に近い指標を一つ選ぶ。

この4週間で、情報源、決定、課題、変更、承認、停止のつながりを試せる。ここまで通してから対象業務を増やす。プロンプトを量産するより、入力、出力、責任、停止の型を一つ完成させる方が横展開しやすい。

AI PMOは、PMOの仕事を減らす仕組みではない。情報収集と転記を減らし、PMOが意思決定、調整、予防へ時間を使えるようにする仕組みである。

プロジェクト管理の情報が散らばり、変更や承認の追跡に時間がかかっているなら、まず一つの管理サイクルを構造化してみてほしい。株式会社Atsumellでは、業務フローの整理から、AIが読める要件・設計ドキュメント、AIエージェントの実装まで支援している。相談はお問い合わせフォームから受け付けている。

関連記事

• SIerの人月モデルはAIでどう崩れるのか
• SIerが仕様駆動開発を導入すべき3つの理由
• AI導入は下流から始めるな — 上流工程から始めるべき3つの理由