AIを使ったシステム開発で、プロジェクト管理はどう変わるのか

AIを使ったシステム開発が急速に現実的なものになっています。

これまで開発者が時間をかけて作成していた設計書、プログラム、テストコード、調査資料などを、生成AIやAIエージェントが短時間で作成できるようになりました。

一方で、開発現場では新しい問題も起きます。

「コードはできているが、本当に仕様を満たしているのか分からない」

「AIへ修正を依頼したら、関係のない箇所まで変更されていた」

「コード生成が速すぎてレビューが追いつかない」

「AIにレビューさせているが、そのレビューを信用してよいのか分からない」

このような状況では、従来と同じプロジェクト管理を続けるだけでは不十分です。

ただし、AI駆動開発だからといって、これまでのプロジェクトマネジメントが不要になるわけでもありません。

重要なのは、プロジェクト管理の基本原則を捨てることではなく、AIを前提として管理方法を組み替えることです。

本記事では、AIを利用してシステム開発を行うとき、プロジェクト管理の何が変わり、PM・PLは何を見直す必要があるのかを整理します。

なお、本記事で扱うのは「PMがAIを使って議事録やWBSを作成する方法」ではありません。

ChatGPT、Claude Code、GitHub Copilot、Cursorなどを設計・実装・テスト・レビューといった開発作業そのものに利用するプロジェクトを対象とします。

---

AI駆動開発でもプロジェクト管理の基本は変わらない

最初に押さえておきたいのは、AIを使って開発するようになっても、プロジェクトマネジメントの基本的な目的は変わらないということです。

プロジェクトでは引き続き、

• 何を作るのか
• いつまでに作るのか
• どの品質を満たすのか
• どのリスクへ対応するのか
• 変更をどう管理するのか
• 誰が判断し、誰が責任を持つのか

を明確にする必要があります。

つまり、スコープ、スケジュール、コスト、品質、リスク、変更、ステークホルダーといった管理領域そのものがなくなるわけではありません。

変わるのは、それらをどのように確認し、どのタイミングで判断するかです。

この記事でいう「AI駆動開発」とは

ここではAI駆動開発を、

生成AIやAIエージェントを、要件整理、設計、プログラミング、テスト、レビュー、ドキュメント作成などの開発プロセスへ組み込む開発

とします。

AI機能そのものを組み込んだシステムを開発する「AIシステム開発」とは分けて考えます。

例えば、通常の業務システムをClaude CodeやGitHub Copilotなどを利用して開発する場合も、本記事ではAI駆動開発に含みます。

また、AIで議事録を作成したり、PM自身がWBS案を作ったりするAI活用とも異なります。

PM業務そのものへのAI活用については、関連記事「AI時代のプロジェクトマネジメント入門」でも解説しています。

変わるのは管理原則ではなく管理方法

例えば、従来から「成果物の品質を確認する」という品質管理の考え方があります。

これはAI駆動開発でも変わりません。

しかし、AIが短時間で大量のコードを作成するようになると、人間が従来と同じ方法ですべてのコードを詳細レビューすることが難しくなります。

その場合、

「レビューする」

という原則は変わりませんが、

「何をAIに確認させ、何を人間が確認し、どの条件なら人間へエスカレーションするか」

というレビュー方法を変える必要があります。

AI駆動開発で重要なのは、このように従来の管理原則をAI前提のプロセスへ変換することです。

AIを使えば必ずプロジェクトが速くなるわけではない

AI駆動開発について、「AIがコードを書けば開発期間を大幅に短縮できる」と考えたくなります。

しかし、個々の作業が速くなることと、プロジェクト全体が同じ割合で速くなることは別問題です。

DORAの2025年の調査では、AI活用とソフトウェアデリバリーのスループットにはプラスの関係が確認された一方、デリバリーの安定性とは依然としてマイナスの関係が示されています。DORAは、AIによる開発速度の向上が、自動テスト、バージョン管理、フィードバックなど下流工程の弱さを増幅する可能性を指摘しています。

また、AIによる生産性向上の程度は、開発者、対象システム、AIツール、作業内容によって大きく変わります。

METRが2025年に実施した特定条件下の実験では、成熟したOSSプロジェクトに詳しい開発者が当時のAIツールを利用した場合、作業時間が19％増えたという結果もありました。その後METRは、2026年時点ではAIによる速度向上が進んでいる可能性を示しつつ、現在の効果量については測定上の問題から明確な結論を出していません。

したがってPMは、「AIを入れたから開発期間を半分にできる」といった前提で計画するのではなく、実際の開発プロセスを見ながら生産性を評価する必要があります。

---

AI駆動開発で大きく変わるのは「開発の流れ」である

AI駆動開発でPMが最初に注目すべきなのは、単純な作業時間ではなく、開発プロセス全体の流れです。

従来の開発では、設計やプログラミング自体に多くの時間がかかっていました。

例えば、

設計
↓
実装
↓
レビュー
↓
テスト
↓
修正

という流れです。

AIを使えば、設計案、コード、テストコード、修正案などを短時間で生成できます。

その結果、

AIによる生成
↓
レビュー
↓
問題発見
↓
AIによる修正
↓
再レビュー
↓
テスト
↓
人間による判断

という短い反復が何度も発生するようになります。

「作る時間」が短くなると別の場所が詰まり始める

例えば、従来は開発者が2日かけて実装していた機能を、AIを使って数時間で作れるようになったとします。

しかし、その変更について、

• 要件を満たしているか
• 共通設計に準拠しているか
• 他機能へ影響していないか
• テストが十分か
• セキュリティ上問題がないか

を確認する必要は残ります。

AIが生成する速度だけ上がって、レビューや意思決定の速度が変わらなければ、今度はレビュー待ちが大量に発生します。

つまりAI駆動開発では、プロジェクトのボトルネックが、

「成果物を作ること」から「作られた成果物を検証し、判断すること」へ移りやすくなる

ということです。

ここが、AI駆動開発のプロジェクト管理を考えるうえで重要なポイントです。

PMが管理すべきなのは、AIがどれだけ速くコードを書いたかではありません。

要求が、検証済み・承認済みの成果物になるまでどれだけ時間がかかっているかを見る必要があります。

---

従来どおりでは把握しにくくなる進捗と生産性

AIを使った開発では、従来以上に「何をもって完了とするか」が重要になります。

コードを書き終えただけでは進捗100％にしない

例えばWBSに、

「ログイン機能実装」

というタスクがあったとします。

AIがコードを生成した時点で、このタスクを100％としてよいでしょうか。

実際には、

• コードレビュー
• 自動テスト
• 要件との整合確認
• 他機能への影響確認
• 必要な修正

が残っている可能性があります。

そのため、AI駆動開発では、

「生成完了」と「成果物として完了」を区別する

ことが重要になります。

例えば、

生成完了
→ AIレビュー完了
→ 自動テスト完了
→ 必要な人間レビュー完了
→ 完了

という品質ゲートを設定します。

関連記事「進捗管理の目的と実施方法」でも、進捗率を担当者の感覚ではなく、明確なルールで設定する重要性を説明しています。AI駆動開発では、このルールをさらに成果物の検証状態まで含めて設定する必要があります。

AIの生成速度だけを生産性にしない

AIが1時間で大量のコードを作ったとしても、その後のレビューに1日かかれば、プロジェクト全体として大幅に速くなったとは言えません。

見るべきなのは、

生成時間＋レビュー時間＋修正時間＋テスト時間＋承認時間

です。

AI導入後は、開発者の実装時間だけを見るのではなく、要求から検証済み成果物になるまでのリードタイムを見る方が実態を把握しやすくなります。

また、レビュー待ち件数、AIレビューでの指摘数、人間レビューへエスカレーションされた割合、手戻り件数なども、管理指標として検討できます。

---

AI駆動開発でPMが見直すべき7つの管理ポイント

AI駆動開発では、特に次の7領域を見直す必要があります。

管理領域	AI利用によって起こりやすい変化	PMが見直すこと
要件・スコープ	AIが曖昧な前提を補完する	前提、制約、未確定事項
設計	機能ごとに異なる設計を生成する可能性	共通設計、正しい設計情報
進捗	実装だけが早く完了する	完了条件、品質ゲート
品質・レビュー	生成量が増えて人間レビューが追いつかない	AIと人のレビュー分担
テスト	AIがテスト自体も生成できる	テストの妥当性
変更・構成	短時間で広範囲を変更できる	変更単位、差分、ロールバック
役割	AIが実作業を担う	AI・開発者・レビュアーの責任

それぞれを個別に管理するだけでなく、相互関係を見る必要があります。

例えば、共通設計が不十分であれば、AIレビューを強化しても設計の正解そのものが存在しません。

逆に設計ルールを詳細に整備しても、そのルールをAIへ適切に参照させなければ一貫した実装にはつながりません。

AI駆動開発では、個々のツールを導入することより、開発プロセス全体を一つの管理システムとして設計することが重要です。

---

AIが作った成果物を、誰がどのようにレビューするのか

AI駆動開発で特に重要になるのがレビューです。

しかし、「AIが作ったものは人間が全部レビューする」というルールだけでは、AIによる開発速度を十分に活かせない場合があります。

AIが大量の成果物を生成できるほど、人間による全量レビュー自体がボトルネックになるからです。

そこで、レビューを一つの作業として考えるのではなく、

機械的な検証 → AIレビュー → 人間による判断

という複数の品質ゲートとして設計します。

機械的に判定できるものは自動化する

まず、ルールによって機械的に判定できるものは自動化します。

コードであれば、

• ビルド
• Lint
• 型チェック
• 単体テスト
• 静的解析
• セキュリティチェック

などがあります。

設計書についてもAIを利用できます。

例えば、

• 設計書間で用語が一致しているか
• 画面とAPIの項目定義が一致しているか
• 同じデータ項目の型や桁数が異なっていないか
• 共通設計のルールに反していないか
• 関連する設計書間で記述が矛盾していないか

といった比較・照合によって判断しやすい内容はAIレビューと相性があります。

人間が大量の文書を目視で突き合わせるよりも、AIに網羅的に確認させた方が効率化しやすい領域です。

業務知識が必要な判断は人間が行う

一方で、すべてをAIレビューへ置き換えるべきではありません。

例えば、

「返品可能期間を30日とする」

という仕様が設計書に書かれていたとします。

画面設計、API設計、DB設計のすべてで30日になっていれば、AIは「整合している」と判断できます。

しかし、

そもそも30日という業務ルールが正しいのか

は別問題です。

このような判断は、人間でも業務知識が不足していれば間違えます。

業務ルール、契約条件、法的判断、顧客固有の運用、例外処理など、プロジェクト固有の知識を必要とする部分については、適切な知識を持つ人が確認する必要があります。

重要なのは、

AIが得意か、人間が得意かではなく、その判断に何の知識が必要なのか

でレビュー担当を分けることです。

AIレビューにもレビュー基準を設定する

AIへ単に、

「この設計書をレビューしてください」

と指示するだけでは、プロジェクトの品質管理としては不十分です。

例えば、

• 何をレビューするか
• 何を正しい情報として参照するか
• どの観点を確認するか
• どの程度の問題を重大とするか
• どの形式で指摘を出すか
• どの問題を人間へエスカレーションするか

を定義します。

AIレビュー自体を一つのレビュー工程として設計するということです。

GitHub Copilotのコードレビューでも、AIによるレビューは承認そのものとしては扱われず、コメントとして提供される仕組みになっています。GitHubも、Copilotが生成した変更について人間が十分にレビューしてからマージするよう案内しています。

AIレビューも人間が定期的にチェックする

さらに重要なのは、レビュールールを一度作ったら終わりにしないことです。

例えばAIレビューを運用していると、

「この種類の不具合を何度も見逃している」

「重要でない内容を大量に指摘している」

「新しく追加した設計ルールを確認できていない」

といった問題が見つかることがあります。

そのため、

AIレビュー
↓
人間が一部をサンプリングして確認
↓
見逃し・誤判定を分析
↓
レビュー観点やルールを修正
↓
再びAIレビュー

という改善サイクルを回します。

PMが管理すべきなのは、「AIレビューを導入したか」ではありません。

AIレビューという仕組みが期待した品質で機能しているかまで管理する必要があります。

---

AIを使うほど設計情報の管理が重要になる

AIがコードを作れるようになると、「設計書は不要になるのではないか」と考える人もいるかもしれません。

しかし実際には逆で、AIを利用するほど設計上の判断基準を明確にする重要性が高まります。

AIは、プロジェクトで過去に何を合意し、どの方式を採用し、なぜその判断をしたのかを自動的にすべて理解しているわけではありません。

情報がなければ、もっともらしい方法を補完して実装することがあります。

機能設計より先に共通設計を整備する

特に注意したいのが、AIを使って機能ごとの設計書を大量に作成するケースです。

いきなり、

「ログイン画面を設計して」

「ユーザー登録画面を設計して」

「注文画面を設計して」

と機能単位で設計させると、それぞれの機能でAIが異なる設計判断をする可能性があります。

その前に、システム全体で統一する設計を整理します。

例えば、

• 画面共通設計
• 帳票共通設計
• UI・入力チェックのルール
• メッセージ設計
• 認証・認可方式
• エラー処理方式
• ログ出力方式
• データアクセス方式
• 外部インターフェース方式
• トランザクション管理
• アプリケーション処理方式

などです。

これらの共通設計を先に固め、その内容をAIが参照する設計基準としたうえで、機能設計へ進むことが重要です。

設計書はAIにとってのコンテキストにもなる

従来、設計書は主に開発者やレビュアーへ仕様を伝える成果物でした。

AI駆動開発では、もう一つ役割が加わります。

AIへ「このプロジェクトでは何を正しい設計とするか」を伝えるためのコンテキストです。

そのため、

設計書Aには旧仕様、
設計書Bには新仕様、
ソースコードには別の仕様

という状態は従来以上に危険です。

PMは「現在の正しい情報はどこにあるのか」というSource of Truth（正しい情報源）を明確にする必要があります。

そしてAIが機能設計を作成するときにも、レビューするときにも、その共通設計を参照させます。

---

AIによる変更速度が上がるほど変更管理・構成管理が重要になる

AIは指示した箇所以外も変更する場合があります。

例えば、

「この画面の入力方法を少し変更して」

と依頼しただけでも、

• 画面
• 共通コンポーネント
• API
• 型定義
• テスト
• CSS

など広い範囲を変更することがあります。

変更内容自体が妥当でも、別機能へ影響すれば問題です。

そのためAI駆動開発では、変更を高速化する一方で、

変更を小さく保つこと

も重要になります。

変更単位を小さくし、

変更
→ 差分確認
→ AIレビュー
→ テスト
→ 必要な人間レビュー
→ コミット

と確認しながら進めます。

問題が発生したときに、どこから問題が入ったのか分からないほど大量の変更を一度に取り込む状態は避けなければなりません。

これはAI特有の新しいプロジェクト管理原則ではありません。

関連記事「仕様変更の管理方法」でも、合意した要件・設計をベースラインとして、変更の影響を確認しながら管理する重要性を説明しています。

AIによって変更速度が上がるほど、この従来からある原則を、より短いサイクルで確実に実施する必要があります。

---

AI駆動開発でPMの役割は「作業監視」から「統制設計」へ広がる

AI駆動開発だからといって、PM自身がすべてのAIツールに詳しくなり、生成されたコードを一行ずつレビューする必要はありません。

PMが行うべきなのは、個々の成果物をすべて自分で確認することではなく、適切に確認される仕組みを作ることです。

例えば、

• AIへ何を任せるか
• AIに何を変更させてよいか
• 何をもって完了とするか
• AIレビューで何を確認するか
• どの条件なら人間レビューを行うか
• 誰が業務仕様を確認するか
• 誰が技術判断を行うか
• 誰が最終承認するか

を決めます。

AIに実装を任せても、責任までAIへ移るわけではありません。

プロジェクトとして重要なのは、

AI・開発者・レビュアー・業務担当者・PMの責任境界を明確にすること

です。

「AI時代にプロジェクトマネージャーは何をする仕事になるのか」でも、PMは単純な作業管理者ではなく、判断や実行環境を設計する役割が重要になることを説明しています。

AI駆動開発では、それが開発プロセスそのものにも広がります。

PMはAIを管理するのではありません。

AIを含む開発プロセス全体を管理するのです。

---

AI駆動開発を始めるPMが最初に決めるべき6つのルール

ここまでの内容を、実際のプロジェクトへ落とし込んでみましょう。

AIを使った開発を始める場合、少なくとも次の6点は早い段階で決めておくとよいでしょう。

1．何をもってタスク完了とするか

AIが成果物を生成しただけでは完了としません。

レビュー、テスト、承認など、必要な品質ゲートを決めます。

2．AIが変更してよい範囲を決める

AIが自由に変更できる範囲と、人間の確認が必要な範囲を明確にします。

3．正しい要件・設計情報を決める

AIが参照すべき要件、共通設計、機能設計、開発ルールを整理し、「何を正しい情報とするか」を明確にします。

特に機能設計を大量に作成する前に、システム全体で統一する共通設計を整備します。

4．変更を小さく管理する

一度に大量の変更を行うのではなく、レビューやテストが可能な単位に分けます。

5．AIレビューの観点と判定基準を決める

AIへ何を確認させるのか、どの資料を基準にするのか、どの程度の問題を重要と判断するのかを決めます。

6．どの判断を人間へ戻すか決める

すべてを同じ深さで人間が確認する必要はありません。

一方で、業務ルール、重要な設計判断、認証・権限、個人情報、決済など、影響が大きい内容は人間による確認を必須にすることが考えられます。

さらにAIレビュー自体についても、人間が定期的に結果を確認し、必要に応じてレビュールールを改善します。

最初から完璧なルールを作る必要はありません。

実際のAI利用状況を見ながら、どこで手戻りが起きているか、AIは何を見逃しているか、人間の確認負荷がどこに集中しているかを確認し、プロセスを改善していくことが重要です。

---

まとめ

AI駆動開発でも、プロジェクトマネジメントの基本原則がなくなるわけではありません。

スコープ、進捗、品質、リスク、変更、責任、合意といった管理はこれまでと同様に必要です。

ただし、AIによって設計、実装、テストなどの生成速度が上がると、プロジェクトのボトルネックは「作ること」だけではなく、レビュー、検証、意思決定、変更統制へ移りやすくなります。

そのためPMは、

• コード生成をタスク完了としない
• 共通設計を整えてから機能設計を進める
• 設計情報をAIが参照できる状態にする
• 自動検証、AIレビュー、人間レビューを組み合わせる
• 業務知識が必要な判断は人間へ戻す
• AIレビュー自体も人間が確認し、ルールを改善する
• 小さな変更単位を維持する
• AI・開発者・レビュアーの責任を明確にする

といった管理方法を整える必要があります。

AI駆動開発のプロジェクト管理で重要なのは、AIがどれだけ速く成果物を作れるかだけを見ることではありません。

AIが生成した成果物を、プロジェクトとして安全に検証し、判断し、完成させられる仕組みを作ることです。

まずは現在のプロジェクトについて、

「AIによって速くなった作業はどこか」

と、

「その結果、レビュー待ち、確認作業、手戻りが増えている場所はどこか」

を確認してみてください。

そこが、AI駆動開発に合わせてプロジェクト管理を見直す最初のポイントになります。