PMは消えるのか、それとも進化するのかーーAI駆動開発時代における、プロジェクトマネジメント再定義論

*AI駆動開発 **自社の知見·技術*

AI-Agent（以下、Agent）が要件定義のたたき台をつくり、コードを書き、テストまで回す。人が直接手を動かす仕事が減るにつれ、「プロジェクトマネジメントも必要なくなるのではないか」という見方が出てきた。だが、私たちは逆だと考えている。AI駆動開発の時代には、PMの重要性はむしろ高まる。ただし、従来のやり方をそのまま続ければよいわけではない。管理する対象、関係者、タスクの分け方、QCD＋Rの評価軸、プロジェクトの進め方、そしてPMに必要な力まで、Agentがチームに加わった現実に合わせて見直す必要がある。

序章　「PM不要論」は本当か

AI駆動開発（AIDD）は、2025年から2026年にかけて「試す段階」から「実際の開発で使う段階」へ入った。AI要件定義サミット2026には約1,400名が来場し、Devin、Cursor、Claude Code、GitHub Copilotといった名称も、一部の先進企業だけでなく、広く開発現場で使われる言葉になっている。日本企業の生成AI活用率も、総務省「令和7年版 情報通信白書」では55.2%、JUAS「企業IT動向調査2025」では言語系生成AIの活用率が41.2%に達している。
その一方で、最近よく聞くようになったのが「AIがここまで開発を進められるなら、PMはいらなくなるのではないか」という意見だ。Claudeが要件定義のたたき台を書き、CursorやCodexがコードを生成し、Devinがテストを回す。人が直接作業する場面が減れば、進捗を管理し、メンバーを配置し、納期と品質を守る従来型PMの役割が小さく見えるのも無理はない。

しかし、現場で起きていることはむしろ逆だ。Gartnerは2025年5月、2027年までにソフトウェアエンジニアリングリーダーの職務記述の70%で、生成AIを監督する責任が明記されるようになると予測した。McKinsey「The State of AI 2025」でも、Agentを試している組織は62%に達する一方、企業の実務で本格運用できている例は約10%にとどまるとされている。AIは広がっているが、安定運用には至っていない。この差を埋めるのがマネジメントである。
私たちの考えは明確だ。AI駆動開発の時代には、プロジェクトマネジメントの重要性は下がらない。むしろ高まる。ただし、管理対象、ステークホルダー、ワークフロー、QCD＋R、ライフサイクル、人材要件といったPMの前提を、AIとAgentがいる開発現場に合わせて更新しなければならない。本稿では、その具体像を整理する。

第1章　AgentがPMにもたらす四つの新しい不確実性

AI駆動開発では、コードや文書の生成にかかる時間は大きく短縮される。ただし、プロジェクトはコードを書く作業だけで成り立っているわけではない。
Agentを開発フローに組み込むと、チームは「人だけ」から「人とAgentの混成」へ変わる。Agentには、人の作業者とは異なる四つの不確実性がある。これは単なるツールの不具合ではなく、Agentを働き手として使う以上、あらかじめ管理すべき特性である。

不確実性1　同じ入力でも結果が変わる

同じ入力を与えても、Agentが毎回まったく同じ結果を返すとは限らない。プロンプトのわずかな違い、会話履歴、参照するコンテキスト、温度パラメータなどで出力が変わる。「同じ仕様書なら同じ成果物が得られる」という従来の前提は、そのままでは通用しない。

不確実性2　モデル更新でAIの挙動が変わる

GPT、Claude、Geminiなどの基盤モデルは、数か月単位で更新される。昨日まで安定していたAgentが、モデル更新後に違う動きをすることもある。人の入れ替えに近い面がある一方、更新時期や影響を事前に読み切りにくい点が厄介だ。

不確実性3　コンテキスト次第で性能が変わる

Agentの出力品質は、対話履歴や参照する知識資産、与えられたコンテキストに大きく左右される。ーー長時間の対話、累積する履歴、参照する知識資産の量ーープロジェクトが進むにつれて情報が増え、途中から回答の質が落ちることもある。こういった問題は、すでに現場で起きている。

不確実性4　AI利用コストが変動する

人月単価は比較的固定しやすいが、Agentの費用はトークン消費量、推論回数、利用モデルによって変わる。運用を始めてから、利用費が想定の数倍に膨らむこともある。Agentコストは、契約時に決めた金額だけで管理できる費目ではない。

現場で実際に起きているアンチパターン

これらの不確実性を放置すると、AIDDプロジェクトでは具体的に次のような事態が生じる。

コスト破綻型：モデルの使い分けやリトライ回数を管理しないまま運用し、Agent費用が想定を超えて採算が崩れる。
品質劣化型：モデル更新後に出力品質が落ちても、バージョン管理や回帰テストがないため発見が遅れる。
属人化型：知識資産、プロンプト、Agent構成の管理者が決まっておらず、担当者が異動するとAgentが動かなくなる。
ワークフロー設計不在型：責任範囲、承認者、利用モデルを決めずにタスクを丸投げし、問題が起きても、どこで人が介入すべきか分からない。

人だけのチームにも、能力差や解釈の違い、属人化はある。だからPMが必要とされてきた。Agentが加わると、出力の揺れやモデル更新、変動費といった新しい管理要素が増える。管理すべき変化が増えるほど、それらをまとめる役割は重要になる。これが、AI時代にPMの必要性が高まると考える理由だ。

第2章　管理対象の拡張 — 人とAgent、最終成果物と中間成果物の統合管理

PMを見直す第一歩は、何を管理するかを広げることだ。
従来のPMは、主に「人」と「最終成果物」を管理してきた。誰が、いつまでに、何を納品するのか。WBS、ガントチャート、進捗会議、品質ゲートも、この考え方を前提にしている。
AI駆動開発では、それだけでは足りない。
AIDDでは、ナレッジベース、プロンプト、Agentの役割定義、Human-in-the-Loopの介入点、協働ワークフローなど、最終成果物に至るまでの「中間成果物」が品質を左右する。仕様書や運用マニュアルも、Agentが読み取り、再利用できる知識資産として整える必要がある。これらが不十分なら、最後に生成されるコードや文書の品質も安定しない。
特にワークフローは、機械可読な設定資産として管理して初めて、再利用と継続的な改善ができる。中間成果物は、単なる作業途中の副産物ではない。PMが責任を持って管理すべき成果物である。

この再定義がWBSにもたらす具体的な追加項目
運用開始後は、ナレッジベースを定期的に更新し、担当者と更新頻度を決める必要がある。基盤モデルが更新されたら、プロンプトやAgent構成への影響を確認する。Agentの判断ログは品質会議でレビューし、誤りの傾向と改善策を組織の知識として残す。Human-in-the-Loopの介入点も、実績データを見ながら見直していく。さらに、タスクの分け方、モデルの選び方、承認ゲートなど、協働ワークフローそのものも継続的な改善対象になる。
これらは従来のWBSにはなかった仕事だ。管理対象を広げるとは、こうした作業を一時的な対応ではなく、正式なタスクとしてWBSに組み込むことを意味する。

第3章　ステークホルダー地図の再描画 — 内と外で増える関係者

AIDDプロジェクトでは、管理対象だけでなく、関係者の範囲も広がる。従来の「発注者と受注者」「業務部門とIT部門」という関係だけでは、プロジェクト全体を捉えられない。

内部ステークホルダーの拡張

業務部門とIT部門は、引き続き要件と運用の中心を担う。そこに、複数プロジェクトを横断して知識資産、設定資産、Agent構成を管理するPMOが加わる。現場の暗黙知を持つ人も、単なるキーパーソンではなく「知識資産オーナー」として正式な役割を持つ。さらに、法務、コンプライアンス、情報セキュリティも、Agentの判断範囲、外部送信の制約、監査要件の設計に深く関わる。

外部ステークホルダーの新規追加

外部の関係者も増える。OpenAI、Anthropic、Googleなどのモデル提供会社は、価格、利用規約、API仕様、サービス提供方針の変更によって、プロジェクトに直接影響する。Cursor、Devin、CopilotなどのAgentツールやプラットフォームにも、基盤モデルとは別の更新リスクがある。金融、医療、公共分野では、Agentの判断ログや知識資産の追跡性が監査要件になるため、外部監査人や規制当局も設計段階から意識すべき相手になる。
PMは、誰と何を合意し、どの変更を継続的に追い、問題が起きたときに誰へ判断を仰ぐかを設計し直す必要がある。AIDD時代のステークホルダー管理は、従来よりも関係者が多く、意思決定の回数も増える。

第4章　Agentを「開発チームの一員」として扱うこと

私たちは、Agentを単なる便利なツールではなく、開発チームの一員として扱うべきだと考えている。
そのためには、人と同じように役割と責任を決めなければならない。要件整理、実装、レビューのどこを担当するのか。何を任せ、何は任せないのか。どこまで自律的に判断してよく、どこから人の承認が必要なのか。人とAgent、Agent同士で、どの情報をどの粒度で受け渡すのかも設計する。運用後は判断ログを確認し、誤りの傾向に応じてプロンプトやナレッジを更新する。モデルやAgent構成を変える場合には、引継ぎと影響評価も必要だ。

Agentの役割設計とHuman-in-the-Loopは切り離せない。Human-in-the-Loopは「最後に人が確認する」だけの仕組みではない。要件の解釈、例外判断、妥当性の確認、承認、責任の引き継ぎのうち、どこに人を置くかを決める設計である。Agentをチームの一員として扱うとは、人とAgentの境界をプロジェクトごとに明確にすることだ。
なお、Agentの能力をどう評価するかは第6章で扱う。本章で焦点を当てるのは、評価方法ではなく、チーム内での役割と責任の設計である。

第5章　タスク分解と人×Agent協働ワークフローの設計

ここまで、管理対象、ステークホルダー、Agentの役割を見てきた。これらを実務に落とし込む鍵が、タスクをどう分け、人とAgentをどう組み合わせるかという協働ワークフローの設計である。
従来のWBSは、主に「誰に割り当てるか」を決めるためのものだった。AIDDでは、それだけでは足りない。タスクごとに、人とAgentのどちらが担うのか、どのモデルを使うのか、どこで承認するのかを同時に考える必要がある。
判断軸は、少なくとも次の六つある。

タスク分解における六つの判断軸

軸1　責任境界
そのタスクをAgentに任せてよいのか、それとも人が判断すべきなのかを決める。誤りが大きな損失につながる仕事ほど、人の関与を厚くする。
軸2　承認主体
成果物を最終的に承認するのは誰か。レビュアー、承認者、問題発生時のエスカレーション先を明確にする。Agentの出力をそのまま次工程へ渡すのか、人が確認するのかもタスクごとに決める。
軸3　安全性
Agentに渡してよい情報の範囲を決める。機密情報、個人情報、外部送信できないデータは、運用を始める前に扱い方を定めておく。
軸4　信頼性
ハルシネーションが許されないタスクと、多少の揺れを許容できるタスクを分ける。規制対応、契約文書、財務計算などは前者、ドラフト作成、要約、アイデア出しなどは後者にあたる。Agentは、まず後者で厚く使うのが現実的だ。
軸5　品質性
品質を何で測り、どの粒度で確認するかを決める。ゴールデンセットによる評価が必要なのか、サンプリングでよいのか、モデル更新のたびに回帰テストを行うのかを使い分ける。
軸6　経済性
高性能で高価なモデルが必要なタスクと、軽量モデルで十分なタスクを分ける。同じ品質をより低いコストで実現できる組み合わせを設計する。

六軸を同時に最適化することが、新PMの中核業務である
この六軸は、別々に最適化できない。安全性を高めれば人の介入が増え、コストは上がる。コストを抑えすぎれば、品質や信頼性にしわ寄せが出る。こうしたトレードオフをタスク単位で判断し、実行可能なワークフローに組み立てることが、AIDD時代のPMにとって重要な仕事になる。
ワークフローは、机上で一度決めれば完成するものではない。Pilotで実際に動かし（第7章で詳述）、レビュー結果、修正履歴、コスト実績を見ながら調整する。うまくいった形は設定資産として残し、別の領域でも使えるようにする。
つまり、協働ワークフローそのものが重要な中間成果物である。これを管理しなければ、AIDDプロジェクトの中核資産を管理していないのと同じだ。人とAgentの協働方法を設計し、継続的に改善することは、PMが手放してはいけない仕事である。

第6章　QCD＋Rの再定義 — 新たな品質KPI、Agentコスト、納期、リスク

従来、プロジェクトはQCD、つまり品質・コスト・納期で評価されてきた。AIDDでは、この三つの見方を更新するとともに、R、すなわちリスクを独立した管理軸として明確に加える必要がある。

Q　品質 — 新たなKPI群の導入

従来の品質管理は、最終成果物のレビュー、テスト、障害密度が中心だった。AIDDでは、それに加えてAgentの判断品質を測らなければならない。重要なのは、指標を並べることではなく、測定方法を決め、日常の運用に組み込むことだ。

C　コスト — Agentコストという新しい主役と、予算ガバナンス

Agentの利用が増えると、モデルAPI、トークン、推論にかかる費用は、プロジェクト全体に占める変動費として無視できなくなる。人月中心のプロジェクトにはなかったコスト構造だ。実案件では、Agent利用費が総コストの10〜30%を占める例もあり、タスクや規模によってはさらに大きくなる。
PMは、1タスクあたりの想定コスト、フェーズごとのモデル選択、利用上限、超過時のエスカレーションを決める必要がある。同じ品質をより低い費用で出すために、モデルの使い分け、プロンプト改善、リトライ削減も継続的に行う。
具体的には、プロジェクト・フェーズ・Agent種別ごとの予算枠を設ける。想定を超えた場合に呼び出しを止めるサーキットブレーカーを用意する。月次では、人月単価だけでなくAgent費用も予実管理し、差異の原因をモデル選択、プロンプト効率、リトライ回数などに分けて分析する。
人月単価だけを見る管理から、人件費とAgent費用を並べて見る管理へ。PMは、コストの見える化と統制の仕組みを作り直す必要がある。

D　納期 — 時間軸の意味そのものが変わる

コードや文書のドラフトは、Agentによって短時間で作れるようになった。実装作業だけを見れば、確かに期間は短くなる。
ただし、プロジェクト全体の「納期」は単純には短くならない。AIDDでは、本番稼働はゴールではなく、人とAgentが安定して協働できる状態に入った時点が一つの区切りになる。納期は、コードが完成する日ではなく、運用が安定する日まで含めて考える必要がある。
そのため、フェーズごとに異なる期限を置く。前期準備では知識資産の初期整備とPilot対象の選定、上流設計・運用設計ではAgentアーキテクチャ、Human-in-the-Loop、ワークフローの確定、Pilotでは協働方法の実証、横展開では運用KPIが安定するまでを管理する。
さらに、Agentには学習曲線がある。立ち上げ直後は出力品質が安定せず、人が修正する工数も大きい。運用が成熟すれば介入は減り、生産性は上がる。この変化を直線的に見積もると、計画はずれる。納期は、立ち上げ期の試行錯誤と、その後の改善を織り込んで設定しなければならない。

R　リスク — AIDD特有のリスク類型を体系に組み込む

AIDDでは、従来のリスク一覧にはなかった問題が増える。モデル更新による品質低下、情報漏えい、Agentの誤判断、利用費の急増などだ。これらは単独で起きるとは限らず、連鎖することもある。PMはAIDD特有のリスクをQCDと並べて管理し、リスクレジスタを更新する必要がある。
QCDからQCD＋Rへ。これが、AI駆動開発に合った評価の考え方である。

第7章　ライフサイクルとフェーズの再設計

従来のSIプロジェクトは、要件定義、設計、実装、テスト、本番稼働へと順番に進む直線型だった。AIDDでは、この進め方だけでは十分ではない。
AIDDのプロジェクトは、大きく四つのフェーズで考えると分かりやすい。各フェーズでは、PMが答えるべき問いを明確にする。

1. 前期準備
現状を把握し、知識資産を棚卸しし、AI Ready度を評価する。そのうえで、どこから始めれば早く価値を出せるかを決める。
2. 上流設計・運用設計
業務要件、Agentアーキテクチャ、責任分界、Human-in-the-Loop、QCD＋RのKPI、協働ワークフローを設計する。人とAgentの境界をどこに置き、誰が何を測るかをここで決める。
3. タスク六軸分解とPilot実施
六つの判断軸でタスクを分解し、Pilotで協働ワークフローを試す。成功パターンを何で評価し、どの粒度で記録し、どう組織知として残すかを決める。
4. 横展開と評価
Pilotで確立した方法を他領域へ広げ、運用KPIと知識資産、設定資産を継続的に育てる。横展開の可否を判断する基準と、知見を管理する責任者を明確にする。

このライフサイクルは、一方向に進んで終わるものではない。横展開で得た知見を前期準備へ戻し、Pilotで分かったAgentの特性を設計やワークフローの見直しに反映する。本番稼働後のデータも、知識資産やAgent構成を改善する材料になる。
PMの役割は、各フェーズの期限を守るだけではない。フェーズ間で学びを循環させ、現場の経験を組織知に変え続けることが重要になる。順番に工程を進めるPMから、改善の循環を設計し、回すPMへ。これがAIDD時代のフェーズ管理である。

第8章　PMBOKは捨てるのか — 既存PM体系との関係

ここまで「再定義」という言葉を使ってきたが、PMBOK、PRINCE2、アジャイルなどの既存体系を否定するわけではない。スコープ、コスト、品質、スケジュール、リスク、ステークホルダー管理という骨格は、AIDDでも引き続き有効だ。変わるのは、管理対象と評価方法である。
この見直しは、PMOの役割やSI契約の責任分界にも影響する。Agent費用を誰が負担するのか。Agentの判断に問題があった場合、誰が責任を負うのか。これらは別稿のテーマだが、PMの再定義と切り離せない。
したがって、「PMBOKは捨てるべきか」という問いへの答えは、はっきり「いいえ」だ。既存の枠組みを活かしながら、中身をAIDDに合わせて更新する。それが現実的な進化の仕方である。

AIDD時代では、PMBOKの知識エリアそのものが変わるわけではありません。
変わるのは、それぞれの知識エリアが管理すべき対象です。
人だけを前提とした管理から、人とAgentが協働するプロジェクト全体を管理する体系へと拡張されることが、AIDD時代のプロジェクトマネジメントの本質です。

第9章　新PMに求められる能力プロファイル

PMの仕事が変われば、求められる能力も変わる。次世代PMに必要な力は、PMBOKの分類に合わせて、テクニカル、リーダーシップ、戦略・ビジネスの三つに整理できる。
テクニカルスキル（追加要件）
テクニカル面では、基盤モデルやAgentツールの特徴と費用構造を理解する必要がある。プロンプトやAgentオーケストレーションを自分で実装できなくても、設計者と会話し、レビューできる知識は必要だ。ハルシネーション率、知識資産の参照率、Agent予算の予実といった新しい指標を読み、QCD＋Rを設計・運用する力も求められる。さらに、六つの判断軸のバランスを見ながらタスクを分解する設計力が欠かせない。
リーダーシップスキル（追加要件）
リーダーシップ面では、人とAgentが混在するチームをまとめる力が必要になる。Agentに期待しすぎる経営層と、利用に抵抗する現場の間に立ち、現実的な進め方を作る。現場の暗黙知を言葉にし、知識資産として整える対話力も重要だ。モデル提供会社やツールベンダーとは、契約だけでなく、製品ロードマップや変更情報を継続的に収集する関係を築く必要がある。
戦略・ビジネススキル（追加要件）
戦略・ビジネス面では、AIDDの投資対効果を経営層に説明する力が求められる。Agent費用と生産性向上を、CFOやCEOが判断できる形で示す。監査、法務、コンプライアンスと連携しながら、リスク管理と現場の使いやすさを両立させる。さらに、一つのプロジェクトで得た成功を、組織全体で再利用できる資産へ変える構想力も必要だ。

こうした力は、個人の勉強だけで身につけるのは難しい。組織として、次世代PMを育てる仕組みも合わせて設計する必要がある。

終章　協働を統御する力こそ、次世代PMの中核能力である

冒頭の問いに戻ろう。AI駆動開発の時代に、PMは不要になるのか。
答えは「いいえ」だ。むしろ、これまで以上に高度なPMが必要になる。ただし、従来のように人月を割り振り、進捗会議を回すだけでは足りない。人とAgentを一つのチームとして管理し、最終成果物だけでなく知識資産や設定資産も扱う。増えたステークホルダーを整理し、六つの判断軸でタスクを分け、人とAgentの協働ワークフローを改善し続ける。QCD＋Rを管理し、各フェーズで得た学びを組織知へ変える。これが次世代PMに求められる仕事である。
Agentが増えるからPMがいらなくなるのではない。Agentが増えるほど、チーム全体をまとめる役割が必要になる。AI駆動開発の成否は、Agentを導入したかどうかではなく、人とAgentの協働を継続的に管理できるかどうかで決まる。
これまでInsightシリーズでは、協働の設計、上流工程への重心移行、知識基盤と運用基盤の整備について論じてきた。これらを現場で機能させるには、全体をまとめ、改善を続けるプロジェクトマネジメントが必要だ。協働を理念で終わらせず、日々の運用に落とし込む仕組みが、AIDDを企業の中核プロセスとして定着させる鍵になる。
PMがなくなるのではない。AI駆動開発に合わせて、PMの役割を作り直す必要がある。
これから求められるのはAIを使いこなすエンジニアだけではありません。AIと人がそれぞれの強みを発揮できるプロジェクトを設計し、成果へ導くPMです。PMは消えるのではなく、その役割そのものが大きく変わろうとしているのです。

本稿は「AI駆動開発 再定義シリーズ」の第1弾である。今後は、契約、組織、人材育成、変化管理、AIDD成熟度モデルなどのテーマを順次取り上げる。
人とAgentの協働を、自社のプロジェクトマネジメントへどう組み込むか。知識資産の整備、運用設計、QCD＋RのKPI設計、協働ワークフロー、PMO体制まで、具体的な検討を支援している。関心のある方は、ぜひご相談いただきたい。

会社概要

会社名：株式会社イー・ビジネス
所在地：〒105-6405 東京都港区虎ノ門1丁目17番1号 虎ノ門ヒルズビジネスタワー5階
設立：2007年6月12日
社員数：333名（2026年2月現在）
コーポレートサイト：https://www.e-business.co.jp/