コーディングエージェントの進化は業務システムの作り方をどう変えるか

コーディングエージェントは、開発者が書いた課題を受け取り、コードを読み、直し、テストを回し、プルリクエストを出すところまで来ています。業務システムの作り方で変わるのは、コードを書く工程の重さです。その分、何を作るかを決める工程、作ったものを確かめる工程、受け入れて運用する工程の重さが増します。現場の業務画面にこの進歩が届くかどうかは、この増えた側の工程を誰が担うかで決まります。

どこまで来たか

主な道具の公式の説明を見ると、できることはほぼ揃ってきました。

• GitHub Copilot のクラウドエージェントは、リポジトリを調べ、実装の計画を立て、ブランチ上でコードを変更します。GitHub Actions で動く一時的な開発環境を持ち、自動テストやリンターを実行できます。
• Claude Code は、コードベースを読み、ファイルを編集し、コマンドを実行し、ブランチを作ってプルリクエストを開きます。
• OpenAI の Codex のクラウド版は、タスクごとに作業環境を持ち、利用者の PC が止まっていても作業を続け、変更とテスト結果を返します。

どれだけ長い仕事を任せられるかも測られています。METR は、人間の専門家がかかる時間で測った仕事の長さのうち、AI が50%の確率で成功する長さ（タイムホライズン）を追っています。2025年3月の報告では、この長さが過去6年にわたっておよそ7か月ごとに倍になってきたとしました。2026年5月更新のデータでは、Claude Opus 4.6 のタイムホライズンは約12時間です。METR 自身、16時間を超える測定は現在の課題の組み方では信頼できないと注記しています。

ベンチマークの数字をどう読むか

コーディングの性能でよく引かれてきたのが SWE-bench Verified です。実在するオープンソースの課題から、人が確認した500問を集めたものです。ただ OpenAI は2026年2月、この問題集は学習データへの混入が進んでいるとして、点数の報告をやめ、他の開発元にもやめるよう勧めました。Anthropic も2026年9月の Claude Opus 5.5 の発表で、この水準の能力になるとベンチマークの差は実際の違いを測る指標として信頼しにくくなっている、と書いています。

もっと重要なのは、テストに通ることと使ってもらえることの差です。METR が2026年3月に公表した測定では、SWE-bench Verified の対象のうち3つのリポジトリの保守担当者が、テストに通った AI のプルリクエスト296件を見たところ、実際に取り込むと判断した割合は、自動採点の点数より平均で約24ポイント低くなりました。人が書いた正解のコードでも、取り込まれたのは約68%です。

テストは、正しさの一部しか見ていません。読みやすさ、既存の書き方との揃い、将来の変更のしやすさは、最後は人が判断しています。

現場の業務画面に届くまでに足りないもの

開発者向けのエージェントが前提にしているのは、課題がすでに文章になっていて、リポジトリがあり、テストがあり、レビューする開発者がいる環境です。中小の工場の業務画面づくりには、このうちのどれも最初からはありません。

1. 要件。工場にあるのは、紙の帳票と、口頭の「こうしてほしい」です。それを課題の文章にする工程が要ります。
2. 骨組み。業務画面は、品目、工程、在庫、実績といった共通のデータの上に乗ります。エージェントは渡されたコードを直すのは得意ですが、どのデータを共通にするかという設計は、先に決まっていないと画面ごとにばらばらになります。
3. 確認。Google の DORA の2025年の報告は、AI の導入がソフトウェアの提供の安定性と負の関係を持ち続けていると書き、強い自動テスト、成熟したバージョン管理、速いフィードバックのような制御の仕組みが無いと、変更の量が増えるほど不安定になると指摘しています。
4. 運用。誰が本番に出し、問題があったら誰が戻し、誰がどの画面を使えるのか。この部分は、エージェントの性能が上がっても自動では決まりません。

作り方はどう変わるか

開発者自身も、まだ移行の途中です。Stack Overflow の2025年の調査では、AI ツールを使っているか使う予定の開発者は84%に達した一方で、AI エージェントについては52%が使っていないか単純な AI ツールにとどめており、38%は使う予定がないと答えています。

業務システムの作り方について言えば、変わるのは次の点だと考えます。

• 画面を作る費用と時間は下がり続ける。直す回数を増やせるようになる。
• そのかわり、作る前に「何を作るか」を現場の言葉から決める工程と、作ったあとに確かめて受け入れる工程が、費用と時間の中心になる。
• 共通の骨組みを先に持っている会社ほど、速く作っても散らからない。

weaveAI は、この増えた側の工程を道具の中に持つことを狙っています。現場の言葉の要望から画面を作り、画面と一緒にテストケースを作って実行し、レビューで重複を見つけて課題として追跡する。エージェントがどれだけ速くなっても、決める、確かめる、受け入れるの三つは残ります。