AIで開発費は下がる？Googleの新ベンチマークで見えた「改修・移行は苦手」と発注者の見積もりの考え方

「AIでプログラムが書けるなら、システム開発の費用も期間も下がるはず」。経営層からそう言われて、開発会社の見積もりをどう受け止めればいいか迷っている発注者の方は多いのではないでしょうか。

2026年9月、GoogleがAIのコーディング能力を測る評価基準（ベンチマーク）の最新版「Android Bench 2.0」を公開し、国内でも@ITが9月26日に報じました。エンジニアが数日〜1週間かけるような大きな作業をAIに任せたところ、最も成績の良いAIでも合格率は約28%にとどまり、特に既存システムの改修や移行は、新しくコードを書くより苦手という傾向が示されています。

発注者にとっての結論を先にお伝えします。AIによってシステム開発の一部の作業が速くなる場面はありますが、「AIを使うから全体の費用が大きく下がる」とは言い切れません。特に既存システムの改修・移行案件では、AIの得意・不得意を踏まえて「どの工程でAIを使い、どこを人が確認するのか」を開発会社と話し合うことが、適正な見積もりと品質を両立する近道です。

GoogleのAI開発ベンチマーク「Android Bench 2.0」の要点

まずは、公表された事実を整理します（内容は執筆時点・2026年9月のものです）。

📰 出典：Android Developers Blog「Android Bench 2.0: Pushing the frontier with challenging long-horizon tasks」（2026年9月17日）

• Googleは2026年9月17日（米国時間）、AI（大規模言語モデル）やAIエージェント（＝指示を受けて自律的に作業を進めるAI）のAndroidアプリ開発能力を測る「Android Bench 2.0」を公開しました
• 新たに、エンジニアが数日から1週間ほどかかる複雑な「長期タスク」を評価に加えました。依存ライブラリ（＝システムが利用している部品）の更新、新機能の追加、アプリのゼロからの構築、他の仕組みで作られたアプリのAndroid向け移植などが含まれます
• 長期タスクでの最高合格率は約28%で、従来の小規模なタスクでの約91%と比べて大きく下がりました
• AIは、既存コードの作り直し（リファクタリング）よりも新しいコードを書く方が得意で、改修や移行では「コードの量」より「システム構造の複雑さ」が成否を分けると説明されています
• 一方、手順が確立した定型的な書き換えは、125以上のファイル・8,000行を超える規模でも一貫してこなせたとしています
• 実行してみないと分からない不具合や、使っている仕組み（フレームワーク）の大きな仕様変更が絡む作業では、AIの成績が落ちる傾向も示されました

評価方法も変わりました。要件の9割を満たしても、細かな例外ケースを1つ落とすと「0点」になる合否判定だけでは実力が分からないとして、機能・見た目の再現度・既存機能を壊していないか等を組み合わせた「完了率」という指標が導入されています。

📰 出典：Android Developers「Android Bench methodology」

評価方法の説明ページによると、長期タスクは4分野・30件です。また、テストは模擬的なサーバーを相手に行われるため、通信障害や応答の遅れなど、実際の運用環境で起きることへの対応力は結果に反映されない、という限界も明記されています。

📰 出典：@IT「『1週間の開発タスク』でAIの限界を検証 Googleが『Android Bench 2.0』公開」（2026年9月26日）

国内では@ITがこの発表を「新規作成は得意でも改修が苦手」という見出しで紹介しています。

発注者にとって何が変わるか・変わらないか（筆者の見解）

ここからは、上記の事実をもとにした筆者の見解です。なお、このベンチマークはAndroidアプリ開発を題材にした特定の条件での評価であり、あらゆるシステム開発にそのまま当てはまるわけではない点にご注意ください。

変わること：AIの「得意・不得意」で見積もりの考え方が分かれる

AIが得意な作業（新しい画面や機能を一から書く、手順が決まった書き換えなど）では、開発会社の作業時間が短くなる可能性があります。一方で、長年使ってきた業務システムの改修や、古い仕組みからの移行のように、既存の構造を理解したうえでの判断が必要な作業は、AIだけでは進みにくいと考えられます。

つまり今後は、案件ごとに「AIで効率化できる部分がどれだけあるか」によって、費用や期間への影響が大きく変わってくるはずです。見積もりを見るときも、「AIを使っているか」ではなく、どの工程にどう使うかを確認する視点が重要になります。

変わること：「動いているように見える」ことと「完成」の差に注意が必要

今回の評価方法の見直しは、AIが要件の大部分を満たしても、細かな例外ケースで失敗しうることを示しています。業務システムでは、月末処理や例外的な取引など「たまにしか起きないケース」こそ重要です。AIが生成したコードが増えるほど、発注者側の受け入れテスト（＝納品物が要件どおりか確認する作業）の重要性は増すと筆者は考えます。

変わらないこと：何を作るかを決め、結果を確認するのは人

長期タスクの最高合格率が約28%という結果からも、執筆時点では、大きな開発をAIに丸ごと任せて完成させるのはまだ難しい段階といえます。要件を決めること、設計の判断、品質の確認、そして本番環境で起きる問題への対応は、引き続き開発会社のエンジニアと発注者が担う部分です。

「AIで速くなった分を、テストやレビューの時間に回している開発会社も多いんです。『早く書ける』と『安心して使える』は別物なので、そこは分けて考えてもらえるとありがたいです」

今やるべきこと・まだ様子見でいいこと

今やるべきこと

• 案件を「新規開発」と「既存の改修・移行」に分けて考える：AIの効果が出やすいかどうかが異なるため、社内説明でも一括りにしない
• 見積もりの前提に「AIの使い方」を含めてもらう：どの工程で使い、誰がどうレビューするのかを確認する
• 受け入れテストの準備を早めに始める：例外ケースや月末処理など、業務上外せないケースを洗い出しておく
• 経営層への説明材料を持つ：「AIで費用がこれだけ下がる」と断定せず、「作業によって効果に差がある」と伝える

まだ様子見でいいこと

• ベンチマークの順位だけでAI製品や開発会社を選ぶこと：評価は特定条件での結果で、実案件の成否はチームの体制や進め方にも左右されます
• AI活用を理由にした大幅な値下げを一律に求めること：案件の性質によって効果は異なるため、まずは工程ごとの説明を聞いてから判断しましょう
• 大規模な移行をAI前提で一気に進める計画：まずは小さな範囲で試し、効果を確かめてから広げる方が安全です

発注者がやることチェックリスト

• ☐ 今回の案件が「新規開発」「既存システムの改修」「移行」のどれに近いか整理した
• ☐ 開発会社に、どの工程でAIを使う予定かを確認した
• ☐ AIが作成したコードを誰がどのようにレビュー・テストするか確認した
• ☐ 業務上外せない例外ケース（月末処理・特殊な取引など）を一覧にした
• ☐ 受け入れテストの担当者とスケジュールを決めた
• ☐ AIツールの利用料が見積もりに含まれるかどうかを確認した
• ☐ 社内（経営層）に「AIの効果は作業によって差がある」ことを説明した

開発会社への質問例

• 「今回の開発で、AIを使うのはどの工程ですか？使わない工程はどこですか？」
• 「AIが書いたコードは、どなたがどのようにレビュー・テストしていますか？」
• 「既存システムの改修部分について、AIで効率化できる部分とできない部分を教えていただけますか？」
• 「AIを使うことで、費用や期間にどのような影響がありますか？見積もりのどこに反映されていますか？」
• 「AIツールの利用料は見積もりに含まれていますか？別途発生する可能性はありますか？」

まとめ：AIの効果は「作業の種類」で変わる。見積もりは工程ごとに確認を

Googleの「Android Bench 2.0」は、AIが新しいコードを書くのは得意な一方、既存システムの改修や移行、1週間規模の複雑な作業ではまだ課題が大きいことを示しました。

• AIで速くなる作業と、そうでない作業がある
• 既存システムの改修・移行では、AIによる効果を過大に見込まない
• AIが作ったコードほど、レビューと受け入れテストが大切になる
• 見積もりは「AIを使うか」ではなく「どの工程でどう使うか」で確認する

AIの進化は速く、評価結果も今後変わっていくはずです。数字に一喜一憂するより、開発会社と「どこにAIを使い、どこを人が確かめるか」を率直に話し合える関係をつくることが、発注者にとって一番の備えになります。

あわせて読みたい関連記事