実行型AIで再定義されるシステム開発の3つの常識｜AI時代のPM生存戦略①

最近、プロジェクトの現場でこんな変化を感じていないでしょうか。

「AIを使ったら、実装があっという間に終わった」
「想定していた工数よりも、なぜか圧倒的に早く進んでいる」

一見すると、喜ばしい変化のように見えます。

しかしその一方で、こんな説明しづらい違和感もありませんか。

「このコード、本当に大丈夫なのか？」
「見積もりの根拠が、なんとなく曖昧になってきた」
「進捗は順調なのに、なぜか不安が消えない」

このモヤモヤの正体こそが、いま現場で起きている構造的な変化です。

つまり問題はAIではなく、「これまでの前提」のほうにあります。

これまで私たちが前提としてきた

実装には時間がかかる
人日でコストを積み上げる
レビューで品質を担保する

といった常識が、静かに、しかし確実に変わり始めています。

本シリーズ（全4回）では、この変化の正体を「実行型AI」という観点から整理し、PMやリーダーが「指揮官」としてプロジェクトを成功に導くためのマネジメントのアップデート手法を解説します。

第1回の今回は、PMが今まさに直面している「3つの常識のシフト」についてお話しします。

「答えるAI」から「動くAI」へ：実行型AIの衝撃
実行型AI時代にPMが直面する「3つの常識のシフト」
PMは「作業の管理者」から「リスクの指揮官」へ
まとめ：実行型AIという「劇薬」の手綱を握る指揮官へ

「答えるAI」から「動くAI」へ：実行型AIの衝撃

少し前まで、AIを活用した開発といえば「ブラウザ上のAIに質問してコードを書かせ、それを自分のエディタにコピペして手直しする」というスタイルが主流でした。これはあくまで「優秀な相談相手」としての使い方です。

しかし現在、Claude CodeやCursorの各種エージェント機能などに代表される「実行型AI」は、まったく異なるアプローチをとっています。

これらのツールはエンジニアの作業環境（ターミナルやエディタ）で動作し、コード読解・編集・コマンド実行を支援します。そして人間の大まかな指示を起点として、必要な権限承認を挟みながら、以下のようなサイクルを半自律的に反復します（たとえば、複数ファイルにまたがる仕様変更やテストコードの生成をわずか数分で実行します）。

既存のソースコードやディレクトリ構造を自ら読み込む
必要なコードを書き換える、あるいは新規作成する
テストを実行し、エラーが出たらそのメッセージを読んで自ら修正する

もちろん、AIが完全に自律してシステムを完成させるわけではありません。人間のレビューと制御は絶対に必要です。

しかし、この「人の指示を前提とした高速実装エンジン」の登場は、システム開発の進め方そのものを根底から揺るがし始めています。

実行型AI時代にPMが直面する「3つの常識のシフト」

この強力なエンジンが現場に入ってくることで、PMがこれまで頼りにしてきた常識は、以下のように大きくシフトしていきます。

シフト①：「何に人日を使うか」が根本から変わる（見積もりの再定義）

よく「AI時代は人日見積もりがなくなる」といった極端な意見を耳にしますが、現場の実態は違います。見積もりという概念そのものが消えるのではなく、「何に人日（コスト）を使うか」という内訳が根本から変わるのです。

開発プロセス	従来の人日（コスト）の使われ方	AIエージェント導入後の使われ方（シフト後）
要件定義・設計	仕様書を書き起こすための時間	顧客の曖昧な要件を整理し、AIが迷わず動けるレベルに言語化する時間（増加）
実装（製造）	手を動かしてコードをタイピングする時間（工数の大半を占める）	AIが高速出力するため、極めて短時間に圧縮される（激減）
テスト・レビュー	エンジニアが書いたコードの作法やバグのチェック	AIが書いたコードがプロジェクトの設計ルールや基本構造に合致しているか、意図通り動くかを検証・監査する時間（激増）

実装の時間は数分〜数時間に圧縮されます。しかしその分、「要件の言語化」と「出力結果の検証」に圧倒的な時間がかかるようになります。

「工数＝作る時間」という従来の感覚から、「工数＝意思決定＋検証の時間」へと頭を切り替えないと、予算もスケジュールも破綻してしまいます。

シフト②：「テストの設計」が品質そのものになる（品質管理の再定義）

若手が「AIで動くものができました」と持ってきたコード。表面上は動いていても、内部で1回で済むデータ通信を何度も繰り返すような非効率な処理（N+1問題など）が走っていないか、セキュリティ的な脆弱性はないか、人間がすべてソースコードを目視で追ってチェックするのはもはや現実的ではありません。

ここで重要になるのが、TDD（テスト駆動開発）を含む「テスト先行・検証先行」の考え方です。AIに任せる範囲が広がるほど、人間は「何をもって正しいとするか」を先に定義する必要があります。

「とりあえず画面が動いたからOK」ではなく、「この仕様を満たし、エッジケース（極端な条件や例外的な入力など）による予期せぬエラーを防ぐためには、どのようなテストケースが必要か」を人間が設計する。そして、そのテストをパスさせることで、AIのコードの品質を担保します。

もちろん、コードレビュー自体が不要になるわけではありません。ただしレビューの重心は、実装の細部を追うこと以上に、テスト観点・設計整合性・非機能要件の確認へと移っていきます。

つまり、「コードのレビュー」以上に「テスト設計・テストコードのレビュー」が今後の品質保証の要になっていきます。テストの設計力が、そのままプロダクトの品質を左右する時代へのシフトです。

シフト③：立ちはだかる「セキュリティと社内ルール」の壁

技術の進化とは裏腹に、PMが直面する一番泥臭い壁がこれです。

どんなに優秀な高速実装エンジンでも、ローカルファイルに広範にアクセスし、外部のAPIと頻繁に通信するツールを、大企業の現場（特に金融、公共、大規模な基幹システムなど）のネットワークで、明日からいきなり導入できるわけがありません。

たとえば「ソースコードの外部送信可否」「実行ログの監査」「接続先の制限」「学習利用に関する契約条件」などは、導入初期に必ず論点になります。

このような情報システム部門の懸念に対し、セキュリティポリシーを遵守しつつ、いかに安全な開発環境を構築していくか。

この社内調整やルールの再定義こそが、現場のPMが汗をかいて突破すべき最初のハードルになります。

PMは「作業の管理者」から「リスクの指揮官」へ

このように開発の常識が激変していく中で、PMの役割はどうなるのでしょうか。「AIが管理もやってくれるからPMは不要になる」と考えるのは早計です。

結論から言えば、PMの重要度はこれまで以上に増していきます。

確かに、誰がどのモジュールを今日どこまで書いたか、といった「定型的なガントチャートの更新」の一部は自動化されていくでしょう。しかし、AIが組み込まれた新しい開発プロセスにおいて、「このブラックボックスを含んだシステムを、本当に本番環境にリリースして良いか（Go/No-Go）」の最終的な意思決定を下すのは、人間であるPMです。

また、先述したセキュリティ部門との交渉や、「AIを使えばもっと安く早くできるんでしょ？」と過度な期待を抱く顧客との折衝など、ステークホルダー間の複雑な政治的調整は、AIには決して代行できません。

これからのPMは、単なる進捗作業の管理者ではなく、プロジェクト全体のリスクと責任をコントロールする「指揮官」へと、自らの役割をアップデートしていく必要があります。

「何かあったら責任を取る人」から「何かある前に止める人」へ。それが、これからのPMに求められる姿です。