本文へスキップ
記事一覧

エージェント型 AI で 7 年を 7 日に

Ghazi Triki 著 · 4 分で読めます

7 年から 7 日へ
この記事の内容

チームが 2 スプリントで出荷したプロジェクトに対して、COCOMO II のスプレッドシートが 33 か月という暦上の期間を予測するのを眺めたことがあるなら、問題はすでにおわかりでしょう。現在使われているあらゆる見積もりモデルは、開発者がすべての行を自分で入力し、コンテキストの切り替えにはコストがかかり、カレンダーは午後 5 時で止まる世界を前提に調整されています。 そのような世界は、もはや存在しません。私たちは最近、プロトコル層、データ層、レンダリングエンジン、プラットフォーム統合からなる 286 KLOC、672 ファイル、複数のサブシステムを持つアプリケーションをゼロから開発し、7 日間でテスト可能なアルファ版に到達しました。

すべてのモデル（COCOMO Basic／Intermediate／Post-Architecture、ファンクションポイント、SLOC ベースライン、Putnam/SLIM）による予測の中央値は 30.3 か月でした。生産性倍率の中央値は 4,240 倍です。最も控えめなベースライン（複雑なシステムで 1 開発者日あたり 25 SLOC）でさえ、1,433 倍のずれがありました。モデルが間違っているのではありません。適用の仕方が誤っているのです。以下では、モデルごとの内訳、同一作者による実証的な較正、そして 2024 年から 2026 年にかけての RCT（ランダム化比較試験）の文献が、エージェント型 AI がどこで期間を短縮し、どこでは短縮しないのかについて実際に何を示しているのかをご紹介します。

見積もりを打ち破ったプロジェクト

RIADVICE では最近、分散アーキテクチャ上で複数のサブシステムを連携させる、複雑で機能の豊富なアプリケーションを開発しました。市場の要件により新たな実装が求められたため、単一のコードベースからモバイルとデスクトップを対象とする、ネイティブのクロスプラットフォーム環境として構築したものです。その規模はコードベースが物語っています。

  • 672 のソースファイルにわたる 286,662 SLOC（約 286 KLOC）
  • 総変更行数 1,329,399 行（追加 862,488 行、削除 466,911 行）
  • テスト可能な最初のアルファ版に到達するまでの、7 日間の開発稼働日における 700 件のコミット
  • 数十のロケールへの完全な国際化対応
  • プロトコル処理、データ管理、レンダリング、プラットフォーム統合という、互いにまったく関連のない複数のサブシステム。すべてを対象環境向けにゼロから構築

これはラッパーでも、見た目だけを変えた薄い作り直しでもありません。既存のソリューションでは満たせなかった市場の要件を満たすために、一から構築したネイティブ実装です。私は 1 行目を書く前に、コードベースの成長に合わせて業界標準のソフトウェア工数見積もりモデルをすべて実行する独自の分析ツールを、プロジェクトに組み込みました。目的は率直なものでした。古典的なモデルが予測するものと、AI 支援による開発が実際に生み出すものとの差を測ることです。その結果は、誤差の範囲ではありません。まったく別の次元の差です。

見積もりモデルの予測と実際の結果

このツールは、ソフトウェアエンジニアリングの文献にある主要な見積もりモデルをすべて実行します。COCOMO Basic（Organic、Semi-Detached、Embedded）、COCOMO Intermediate（Semi-Detached と Embedded、調整済み）、COCOMO II Post-Architecture（調整済み）、ファンクションポイント、SLOC 生産性ベースライン、Putnam/SLIM であり、いずれも原典の文献で公表された定数を用いて、プロジェクトの種類に合わせて較正しています。

見積もりモデル予測工数予測期間実績に対する倍率
COCOMO Basic（Organic）913 人月33.3 か月2,282 倍
COCOMO Basic（Semi-Detached）1,696 人月33.7 か月4,240 倍
COCOMO Basic（Embedded）3,200 人月33.1 か月8,000 倍
COCOMO Intermediate（Semi-Det.、調整済み）1,259 人月30.4 か月3,148 倍
COCOMO Intermediate（Embedded、調整済み）2,376 人月30.1 か月5,940 倍
COCOMO II Post-Architecture（調整済み）1,703 人月30.3 か月4,257 倍
ファンクションポイント（概算）17.9 人月7.5 か月45 倍
SLOC 生産性ベースライン（1 開発者日 25 SLOC）573 人月573.3 か月1,433 倍
Putnam/SLIM対象外（期間が 30 日未満のため T 4/3 が発散）該当なし該当なし

全モデルを通じた生産性倍率の中央値は 4,240 倍です。最も控えめなモデルでさえ、実際の約 1,400 倍の期間がかかると予測しています。最も楽観的なファンクションポイントでも 7.5 か月と予測しており、実際の 7 日の 45 倍です。モデルによれば、このプロジェクトには 7 か月から 47 年かかるはずでした。アルファ版は 7 日でテスト可能な状態になりました。

モデル同士の食い違いは 50 倍から 8,000 倍

これらのモデルは互いに一致していません。同じコードベースに対して、予測は 17.9 人月から 3,200 人月まで幅があり、その差は 178 倍に及びます。51 の実プロジェクトで COCOMO II、SEER-SEM、SLIM、TruePlanning を比較した SEAA 2013 のベンチマークでは、MMRE は 50～100% でした。COCOMO NASA データセットを用いた 2023 年の評価では、MMRE は 1.0 近く、PRED(0.25) は 0.0 で、誤差 25% の範囲内に収まったプロジェクトは一つもありませんでした。これらのモデルは、そもそも AI 支援のプロジェクトを想定して設計されたものではありません。しかし、モデルの不正確さを考慮してもなお、この差の大きさは、何かが構造的に変わったことを示しています。

エージェント型 AI と開発者の生産性について研究が実際に示していること

4,240 倍という数字は極端であり、私はそれを誇張したくはありません。グリーンフィールドでの土台作りは変更行数を膨らませますし、SLOC は価値の指標としては不十分です。そこで、査読付きの文献を見てみましょう。

Copilot 型のアシスタントは、控えめながら確かな効果をもたらします。 Peng ら（2023）は、AI ペアプログラマーを使った開発者がタスクを 55.8% 速く完了したことを明らかにしました（95% 信頼区間：21～89%）。これまでで最大規模の研究である Microsoft／Accenture／Fortune 100 の RCT（2025、n=4,867）では、完了タスク数が 26% 増加しました。Google の社内 RCT（2024）では、タスクにかかる時間が約 21% 短縮されました。BIS／Ant Group のフィールド実験（2024）では、若手スタッフのコード出力が 55% 増加しました。率直にまとめると、適したタスクで 1.26～1.56 倍です。確かな効果ではありますが、変革的とまでは言えません。

エージェント型 AI は、まったく異なる領域で機能します。 Cognition による Devin の 2025 年のレビューでは、顧客の成果として ETL 移行で 10 倍、Java のバージョン移行で 14 倍、セキュリティ修正で 20 倍が報告されています。Nubank は、以前は数年がかりで 1,000 人のエンジニアを要すると見積もられていた数百万行規模のリファクタリングで、効率が 12 倍に向上し、20 倍のコスト削減したと報告しています。今回の移植は、まさにこの範囲に収まります。コミットのヒストグラムには、22 時、0 時、1 時に密集したバーストが見られ、エージェント主導のセッションの特徴を示しています。

反証も現実に存在します。 Metr.org の 2025 年の RCT（経験豊富な開発者 16 人、成熟したプロジェクトでの 246 タスク）では、AI によって完了時間が 19% 増加しました。つまり、慣れ親しんだコードベースでは、経験豊富な開発者の作業を遅くしたのです。AI ツールを導入した 807 の GitHub リポジトリを対象とした 2026 年の差分の差分法による研究（He ら、MSR ’26）では、「一時的な」開発速度の向上と、長期的な減速を招く「持続的な」コードの複雑性の増加が見いだされました。そのタイトルがすべてを物語っています。Speed at the Cost of Quality（品質を犠牲にした速度）。コンセンサスは次のとおりです。AI はグリーンフィールドや構造化された開発では大いに役立ち、補完的なタスクでは控えめに役立ち、成熟したコードベースでは開発速度を損なうことがあります。 品質面の負債は現実のものです。

モデルが破綻する理由：三つの構造的変化

古典的なモデルのコストドライバーには、「開発者が、眠ることなくコードベース全体をコンテキストに保持する自律型エージェントを持っている」という設定がありません。三つの変化が、期間の曲線を押しつぶしています。

  1. 入力作業というボトルネックが消えた。

モデルは、工数のかなりの部分が機械的な作業、つまりボイラープレート、土台作り、繰り返しのリファクタリング、ローカライズ用リソース、その他の構造化データであると想定しています。今回の移植では、その量の多くが、エージェントが一括で生成または変換できる、極めて規則的なテキストと配線でした。手書きのコードそのもの、つまり土台作り、コンストラクター、プラットフォームとのつなぎ込みも、今では 1 行ずつ入力するのではなく、まとめて生成されます。

  1. コンテキスト切り替えのコストが崩れつつある。

プロトコル層、データ層、レンダリングエンジンの間を行き来する人間は、そのたびにコンテキストを読み込むコストを払います。672 ファイルのリポジトリ全体を読み込んだエージェントは、そのコストを一度払うだけです。この非対称性は、これほどの規模のコードベースでは急速に積み重なります。

  1. カレンダーはもはやボトルネックではない。

モデルは、人間の労働日を前提とした要員配置の方程式によって、人月を暦上の月数に換算します。エージェントのセッションは夜通し稼働します。コミットのヒストグラムには、7 時から翌 1 時まで途切れない出力が表れています。稼働時間は 8 時間ではなく 18 時間です。

同一作者による実証的な較正

パラメトリックモデルの予測は桁違いに食い違うため、私はプロジェクト横断の実証的な較正も行いました。同じエコシステムにある三つの本番リポジトリで、エージェント型 AI ツールの導入前と導入後の、1 人日あたりの自分のコード変更量を比較したものです。

プロジェクトAI 導入前の変更量／開発者日AI 導入後の変更量／開発者日倍率
プロジェクト A（ロードバランサー）6732,0563.1 倍
プロジェクト B（レポートサービス）2392,1278.9 倍
プロジェクト C（処理サービス）1,3229820.7 倍
全体（平均／中央値）該当なし該当なし4.2 倍／3.1 倍

同じ作者、同じ領域、実際の保守作業です。実証的な倍率は 3～9 倍であり、グリーンフィールドでの 4,240 倍という数字よりはるかに控えめで、公表されているエージェント型 AI の研究の上限と一致しています。実際に遅くなったプロジェクトも一つあります。効果はタスクに依存し、普遍的なものではありません。

プロジェクト計画にとっての意味

未較正のモデルと 1 日 25 SLOC というベースラインで今もソフトウェアプロジェクトを見積もっているなら、AI 支援の作業では 1 桁から 3 桁の誤差が生じます。RIADVICE では、次のように取り組んでいます。

  1. 自社の実績で較正する。 AI を使った場合と使わない場合で、1 人日あたりの自社のコード出力を比較します。そのほうが安価で誠実であり、プロジェクト計画で根拠を示せる 3～9 倍という範囲が得られます。
  2. グリーンフィールドと保守を分けて考える。 エージェント型 AI の倍率は、グリーンフィールドや構造化された開発で最も大きく、成熟したコードベースの保守では最も小さくなります（マイナスになることもあります）。両方に同じ数字を当てはめてはいけません。
  3. 品質面の負債を予算に組み込む。 AI による開発速度には、複雑性の持続的な増加が伴います。堅牢化のフェーズを計画し、それを計測しましょう。リリースのたびに循環的複雑度を追跡し、コピー＆ペーストの検出を実行します。
  4. 曲線の前半だけでなく、全体を見積もる。 欠陥密度が 2 倍になるような 10 倍の速度向上は、10 倍の向上ではありません。安定化までの期間が長くなるという代償を払って、スケジュールを前倒ししただけです。

結論

あらゆる見積もりモデルが 7 か月から 47 年かかると予測したプロジェクトが、7 日でテスト可能なアルファ版に到達しました。4,240 倍という中央値の倍率を、そのままプロジェクト計画に使うべきではありません。しかしそれは、工数を圧縮しているのと同じ力によって、複雑なソフトウェア開発の期間もまた圧縮されつつあるという明確なシグナルです。公表されている研究は、AI が 1.26 倍の小さな後押しから 20 倍の急伸までをもたらすこと、そして成熟したコードベースではマイナスの効果になる現実的なリスクと、測定可能な品質面のコストがあることを示しています。このプロジェクトには数十年かかると告げたモデルは、今も企業の見積もり用スプレッドシートで使われ続けているモデルそのものです。問われているのは、エージェント型 AI がプロジェクトの期間を変えるかどうかではありません。その問いには、研究がすでに答えを出しています。問われているのは、皆様の見積もりの実務がエビデンスに追いついているかどうかです。もし数字が今も COBOL とアセンブリで較正された 1981 年のモデルから出ているのであれば、較正し直す時期です。少なくとも、そのモデルが出力するカレンダーを信じるのはやめるべきでしょう。

「実務で直面する予測の課題により良く対処するためには、依然として大きな改善の余地がある。」

（Accuracy of Contemporary Parametric Software Estimation Models、SEAA 2013）

🏆 信頼のエンジニアリングとクラウドの専門性

RIADVICE：ソフトウェアエンジニアリングの信頼できるパートナー

私たちは、AI 時代に成果を届けるためのエンジニアリングの規律とツールを備え、複雑なソフトウェアシステムを設計、構築、デプロイします。納期、予算、品質のすべてを守ります。

サービスの詳細を見る →

📚 出典と参考文献

この記事は、AI 支援によるソフトウェア開発の生産性とソフトウェア工数見積もりに関する、査読付きの研究、ランダム化比較試験、業界のフィールドレポートに基づいています。

⚡ RIADVICE.com は、信頼のエンジニアリング、クラウドの専門性、エンタープライズ級のソフトウェアソリューションを、納期、予算、品質のすべてを守ってお届けします。

この記事を共有

関連記事