AIが完了できる課題は長くなった　2026年の開発現場から考える2030年

公開モデルの評価は分単位から時間単位へ

METRの「時間地平」は、AIが一定の成功率で完了できる課題を、人間の専門家なら何分かかるかで表す指標です。人間の所要時間とAIの成否に曲線を当てはめ、成功率が50%や80%になる地点を求めます。

次の4モデルを比べると、どちらの成功水準でも値は大きく伸びています。表は後年のTH1.1評価による推定値で、各年の全モデルの最高値を選んだ一覧ではありません。

この時間は、AIが動き続けた時間や、仕事を終えるまでの実時間とは異なります。対象は主に、仕様と成功条件が明確で、自動採点できるソフトウェアなどの課題です。

Opus 4.6の値も、同じ曲線からそれぞれの成功率に対応する時間を求めています。50%の値だけから80%の値を決めることはできません。

推定幅も大きく、公表データに示された区間の下限と上限は、同モデルの50%水準で約5.28〜60.56時間です。80%水準では約0.45〜2.84時間になります。

この区間には、課題の種類のまとまり、個々の課題、各試行を順に再抽出する階層ブートストラップの不確実性が含まれます。人間所要時間の推定ノイズや統計モデルの仕様変更をすべて織り込む区間ではなく、別の実務への一般化も保証しません。

METRは、現行の課題集合では16時間を超える測定値が不安定だと明記しています。公開データにはOpus 4.6より後のモデルもあり、同モデルは以後の試算の基点として使います。

AIが担う工程と人の判断は企業ごとに違う

Sansanは仕様の検討から実装までつなぐ

Sansanの契約に関するサービス「Contract One」の開発組織は、AIを使う一連の開発手順「COSP」を運用しています。担当エンジニアの中川氏によると、文書を入力に、調査や設計を経て実装と変更提案の作成まで進めます。

各段階の成果物は人が確認し、先へ進むか、前の段階に戻すかを判断します。実装後にはテストなどの機械検査に加え、コードを書いたエージェントとは別のAIによる検証も行います。

すべての検査を通った変更提案も、人のレビューを受けます。AIにはコードを統合するマージ権限を渡していません。

同氏は、担当組織のリリースノート件数が週6件から83件になったと報告しています。これは公表する変更の件数であり、品質や投入工数を一定にした生産性の倍率としては扱えません。

Delivery Heroは本番への反映も任せる

配送プラットフォームを運営するDelivery Heroは、2026年第1四半期に開発エージェント「Herogen」を導入しました。Google Cloudの顧客事例によると、課題管理ツールで管理されている仕事を引き取り、コードの実装・テスト・レビューを行います。

コード作成には主にClaudeを使い、Geminiもレビューやセキュリティ検査に参加します。事例では、Herogenが1日170件を超える変更提案を作成・マージし、多くの案件で人の介入が不要だったとしています。

Google Cloudの事例は、Herogenの本番反映に関する成功率を85%と紹介しています。対象となる案件の範囲や選び方、成功判定の詳細は示されていません。2026年末までに全マージ件数の20%をHerogenが担うという数字は、同社の目標です。

OpenAIでは複雑な研究課題に人が介入する

OpenAIの研究組織では、研究コードの作成に加え、実験の監視や技術サポートでコーディングエージェントの利用が増えたとしています。社内の個別報告には、研究基盤の不具合対応でエージェントを使う例もあります。

一方、同社は成否を確認できたタスクの過去6か月の分析も公表しました。人間なら4〜8時間かかると推定されるタスクでは、成功例の半数以上で人が1回以上介入したとしています。研究の優先順位や、システムの拡大・停止・デプロイを決めるのも人です。

同社は7月20日、エージェントによる研究基盤への侵害が判明したため、訓練用のコンテナサービスを一時停止しました。その後、追加制限を設けて復旧したと説明しています。

AIは増えた検査を支える基盤も改良する

Anthropicでは、変更したコードを継続的に検査するCIのジョブ数が、6か月で25倍に増えたと報告しています。コードベース全体のテスト量も10倍になり、実行するテストを選ぶサービスに負荷が集中しました。

同社の説明では、Claudeはコード作成に加え、変更提案のレビューや承認にも大きく関わっています。人も相当数の変更提案を主導・承認しており、CIの増加は生産性そのものを測った数字ではありません。

担当エンジニアは、サービスの遅延を監視するClaudeの長期セッションを使いました。改修の途中ではClaudeが処理を分割するコードを生成しました。最終的にチームは、テスト結果を処理する複数のプログラムへ負荷を分散できる構成に作り替えました。

再設計後の調整では、テスト結果を蓄積するジャーナルの容量や処理プログラム数の設定を、Claudeが大部分自律的に担ったとしています。新構成は運用費が増える一方、拡張しやすくなり、調整後は安定したと報告しています。

SansanのContract One開発組織でも、文書の変更に応じて手順の更新を提案するCI処理が動いています。変更提案へのレビュー指摘も収集し、開発用のスキルやルールに反映する候補を検出しています。

出典と比較の範囲

各社の導入状況と効果は、公表された企業事例に基づきます。社内の実験やログを編集部が再実行・独立監査したものではありません。

Sansan事例は、TechDaylightと同じ運営元のAI CASESを用いて見つけ、事実関係はSansanの一次資料で確認しました。

関連記事：AI企業の社内エージェント活用を扱ったTechDaylight既刊記事。