この1年のコーディングエージェントの進化と今後半年の予想

プログラマーAGIは、
もう来ていた

コーディングエージェントの1年と、次の半年

社内勉強会
さとうきよし

今日の結論を先に

プログラマーAGIは、
もう来ていた

プログラマーの仕事がすべて自動化されたわけではない。
だが「与えられた目的に対してコードを調査・実装・テスト・修正する知能」は、
平均的な人間プログラマーの水準に到達し、すでに超え始めている

今回の「プログラマーAGI」の定義

含める能力

  • 未知・大規模なコードベースを探索する
  • 要求から変更箇所を特定する
  • 複数ファイルをまたいで実装する
  • CLI・コンパイラ・テスト・ブラウザ等の道具を使う
  • 失敗結果を読み、修正して再実行する
  • リファクタ・移植・バグ修正を長時間継続する
  • 必要に応じて計画を変え、成果物まで持っていく

含めない・別の論点にする能力

  • 顧客自身もまだ知らない要求の発見
  • 何を作るべきかという経営・製品判断
  • 法的・社会的責任を負うこと
  • 長期的な保守方針や組織内の利害調整
  • すべての出力を無条件に信用できること

境界を絞るのは主張を弱めるためではない。「コーディングという狭いが巨大な領域では、すでに閾値を超えた」を明確にするため

軸1　モデルとエージェントの進化

2025年前半は「エージェントらしく動く」こと自体がニュースだった
2026年夏には、長時間・大規模・複数エージェントが前提になった

2025年　エージェント元年から競争へ

2024-11
MCP公開（Anthropic）　エージェントと外部ツールをつなぐ標準化
2025-02
「Vibe Coding」命名（Karpathy）／「CLINEに全部賭けろ」（mizchi）／Claude Code研究プレビュー
2025-05
Claude 4＋Claude Code一般提供、Codex、Julesが出揃う
2025-07〜09
Kiro、GitHub Spec Kit、GPT-5、GPT-5-Codex
2025-11〜12
Claude Opus 4.5、GPT-5.2 / 5.2-Codex　Claude対Codexの競争が本格化

発表者の実感　2025年5月、Claude Codeが「実務で使う道具」になった。当時のCodexはクラウドサンドボックスの非同期実行で、ローカルを直接触るClaude Codeの方が日常開発に入りやすかった。2025年後半からCodexが急速に追い上げた

2026年　分水嶺を越えた

2026-02
Claude Opus 4.6 / GPT-5.3-Codex　ここで一段階変わった
2026-03〜04
GPT-5.4（1Mコンテキスト、ネイティブなPC操作）、GPT-5.5、Sonnet 4.6（数か月前のOpus級を安価に）
2026-05〜07
Opus 4.8、Fable 5、Sonnet 5、GPT-5.6 Sol / Terra / Luna

2026年初頭

「平均的な人間プログラマーと実装速度・完成力で競争する段階」を越えたように見える分水嶺

2026年夏

Fable 5やGPT-5.6 Solでは、実務感覚として「コーディングはAIの方が上」と表現した方が近い

軸2　開発作法の変化

バズワードが変わったのではない。ボトルネックが変わった

「一番困る場所」が移ってきた

Prompt
Engineering

どう言うか

→

Context
Engineering

何を見せるか

→

Spec / Harness
Engineering

どんな環境と制約で働かせるか

→

Loop
Engineering

どう自動で繰り返し、検証し、止めるか

Prompt時代 ボトルネックは「うまく命令できないこと」
Context時代 「必要な情報がモデルから見えないこと」（2025-09 Anthropicが公式記事）
Harness / Loop時代 「環境・検証・繰り返しの設計」（2026-02 OpenAI Harness Engineering、2026-06 Loop Engineering）

年代は厳密に分離しない。モデルの能力向上で「一番困る場所」が移った図として見る

Spec-Driven Developmentと、その先の問題

SDDの登場

  • 2025-07 Kiro（AWS）、2025-09 Spec Kit（GitHub）
  • Vibe Codingへの反動として、仕様を先に構造化し、計画・タスク・実装へ落とす
  • モデルが仕様を実装できる段階に来たため、「正しい仕様を渡すこと」が中心課題になった

ただし、限界がある

問題は、仕様を正確に文章化できないことだけではない。

顧客やユーザー自身が、動くものを見るまで欲しい仕様を知らないことがある

その意味で、Vibe Codingは雑な開発ではなく「高速な仕様探索」として再評価される可能性がある　→　後半の未来予想へつながる

Human-in-the-loop から Human-on-the-loop へ

Human-in-the-loop

  • AIが途中で止まり、人間の承認や修正を待つ
  • Claude Codeでは許可プロンプトの93%が承認され、承認疲れが問題になったとの報告
  • 人間が毎回承認する方が安全、とは限らない

Human-on-the-loop

  • AIのループは自走し、人間は外から監視。異常時や判断時だけ介入する
  • 経験者ほど自動承認を増やす一方、必要時には中断もする（Anthropic 2026-02調査)
  • 「放置」ではなく、監視の粒度が上がる

人間がループに入ると品質が上がった時代から、人間がループに入ること自体が速度のボトルネックになる時代へ

軸3　接続・環境・制御の変化

周辺ツールの流行は、その時点のモデルが何を苦手としていたかの履歴である

MCPからSkillsへ、ではなく役割分担へ

MCP　「接続」の標準

  • 2024-11公開。モデルが外部データ・ツールから孤立していた時代の答え
  • 2025年前半、対応が広がり大きな話題に
  • 2025-12、Linux Foundation傘下AAIFへ寄贈
  • 「終わった」のではなく、業界標準インフラへ沈み込んだ

Skills　「手順と知識」

  • 2025-10公開、2025-12にオープン標準化
  • 指示・スクリプト・資料をフォルダに置き、必要な時だけ読む単純な仕組み
  • モデルがCLI・README・手順書を扱えるようになったから成立
  • 高性能モデルには、常時スキーマを見せるより必要時に手順書を読む方が効率的な場合がある

話題の中心が移ったのは、モデルの弱点とボトルネックが変わったから。MCP回で話した内容は、いまはインフラとして下の層にある

ハーネスは、AIを縛るものから、AIを働かせるものへ

以前　檻としてのハーネス

  • 変なことをしないように檻へ入れる
  • 1操作ごとに承認する
  • 人間が常時付き添う
  • クラウドサンドボックスで隔離実行（初期Codex、Jules）

現在　働く環境としてのハーネス

  • 長時間仕事を続けるための記憶と進捗管理
  • テスト・レビュー・コンパイラを自動のフィードバックにする
  • 複数エージェントを並列に動かす
  • 異常時だけ人間へエスカレーションする

「ガードレールが不要になった」ではない。モデルが信頼できるようになったため、制御の目的が「暴走を止める」だけでなく「大きな仕事を安全に任せる」へ変わった。権限の「被害半径」を制御する必要は残る

軸4　評価尺度と作業規模の変化

ベンチマークが変わったのは測定技術の流行ではない
以前は現実的でなかった規模の仕事が、測れる対象になったからである

ベンチマークが測る「仕事の大きさ」

短い関数・補完 HumanEval等 単一Issueの修正 SWE-bench系 実OSSのIssueをパッチで解決 複数ファイル・複数言語 実務的な変更 数時間〜数日の 長時間タスク METR time horizon リポジトリ全体 移植・再実装 DeepSWE / MirrorCode 複数エージェント開発

ベンチマークの難易度は、昨日まで人間の仕事だった範囲の地図である

新世代ベンチマークと、時間軸の物差し

DeepSWE 2026-05

  • 91のアクティブOSS、5言語
  • 113の新規長時間タスク
  • 短く自然な要求から探索・実装させる
  • 参照解は平均668行追加・7ファイル編集
  • 外部挙動を手書きverifierで検証

MirrorCode 2026-06

  • ソースを与えず、入出力挙動の観察からプログラム全体を再実装させる
  • 人間でも十分な技術力と時間が要る仕事が、評価項目になったこと自体が象徴的

METR time horizon

  • 人間の専門家が要する時間で仕事の大きさを測る
  • 50%成功のtime horizonは約7か月ごとに倍増と報告

対照例　METRの2025年のRCTでは、当時のAIツールで熟練OSS開発者が本人の予想に反し平均19%遅くなった。その後METR自身が「急速な進歩により現在のツールを代表しない」と追記。1年前のスナップショットは、それほど短期間に古くなる

大規模開発　半年で実験になり、1年で実用になった

半年前　大規模「実験」

2026-01　Cursor　ブラウザをゼロから

数百エージェント並列、約1週間、100万行超・1000ファイル

2026-02　Anthropic　Rust製Cコンパイラ

16のClaude、約2000セッション、約2万ドル、約10万行。Linux 6.9をx86 / ARM / RISC-V向けにビルド可能

今　実運用への「実用」

2026-06　Stripe　5000万行Rubyの全体移行

チームなら2か月超の移行を1日で（Anthropic発表によれば。第三者検証は限定的）

2026-07　Bun　Zig→Rust全面移植

実プロダクトのランタイムを移植し、本番投入　→　次のスライドで詳細

大規模コードが生成されたことと、製品品質で完成したことは同義ではない。実験と製品事例を分けて見る

BunのZig→Rust全面移植　2026-07-08公開

53.5万行

もとのZigコード（コメント除く）

11日間

1人のエンジニア＋Fable 5＋約50のDynamic Workflows

6502

コミット数

◆ すべてのプラットフォームでテスト100%通過、実運用へ投入。既知の移植起因回帰は公開時点で19件・修正済み
◆ Claude Code自身も、Rust版Bunを本番利用している

半年前には「大規模なものを作る実験」だった。1年後には、何千万回もダウンロードされるランタイムの実移植に使われた

4本の証拠が、同じ結論を指している

❶

モデル／製品

長時間・大規模コード・ツール利用・自律的な修正が標準機能になった

❷

開発作法

人間が一手ずつ指示する前提から、ループを設計して監視する前提へ

❸

周辺技術

檻と許可プロンプトから、長時間働かせるハーネスへ

❹

評価／実例

Issue修正から、リポジトリ規模・移植・再実装・数日単位の仕事へ

別々の方向から見ても、同じ変化を示している

実装勝負は終わった

人間の主戦場は、コードを書くことから
何を作るか・どう確かめるかへ移る

・ソフトウェア開発の全工程が終わった、という意味ではない

・人間の仕事が明日消える、という意味でもない

・ただし「実装は人間の希少能力」という前提は、もう置けない

今後半年の予想

技術側とプロセス側の、2本立てで考える

予想①　最強が普通になる

重要なのは最高性能の更新だけではない。今の最高性能が、より安く・速く・日常的に使える層へ降りてくる

すでに起きている根拠

  • 2025年末のOpus級能力が、2026-02のSonnet 4.6価格帯へ
  • Sonnet 5は数か月前のOpus 4.8級を低価格で
  • GPT-5.6は「1トークン・1ドルあたりの有用な仕事」を前面に
  • Qwen3.6-27B等、小型公開モデルも1年前の高性能帯へ
  • METRの尺度は約7か月で倍増という傾向

技術者に来る変化

  • 今は高くて常用できないモデルを、毎日の雑な作業にも使える
  • 実装・レビュー・テスト・調査に複数体を常時並走させる
  • 限界が人間のタイピング速度ではなく、計算資源と検証能力になる
  • 数万〜数十万行の生成・移植が通常の選択肢になる

半年後には、今の「高級な知能」を燃やすことへの心理的な抵抗が消え始める

予想②　新しいボトルネックが前へ出る

実装が制約でなくなると、意思決定と検証が制約になる

❶

仕様発見

顧客は動くものを見て初めて「欲しいもの」が分かる。生成→操作→反応→仕様更新の高速ループが必要になる

❷

検証と品質保証

人間が全diffを読む方式はスケールしない。テスト・型・静的解析・複数モデルレビューで機械的証拠を積み上げる

❸

ループを閉じること

失敗を分類し、修正し、再実行する。いつ停止し、いつ人間へ上げるか。ループの設計品質が出力品質を決める

❹

システム理解と意図の説明

なぜこの設計か説明できるか。何を保証し何を保証しないか。事故時に原因を追跡できるか

自己点検　発表者自身が検証・品質保証を研究しており職業上のバイアスの可能性はある。ただし各社の公開実装も、モデルの賢さそのものより検証可能なループと環境へ重心を移している

おまけ　この資料自体も、1年前とは違う作り方をしている

約2年半前
LLMはタイトル候補や短い文章のたたき台に使える程度
1年前
Claudeと相談しながら構成を作り、スライド本文も生成
今回
過去資料を読ませ、リアルタイム音声で長時間壁打ちして設計書を作成。スライドはコーディングエージェントが生成

音声会話は「予想より早く来た」ではなく「やっとまともな全二重会話が来た」が正直な感覚。重要なのは音声の新規性ではなく、会話相手が論点を保持し、構成候補を作り、事実確認へつなげ、資料の設計図まで作れるようになったこと

人間を超えたか、ではない

どこまで離れるか
どこまで安く、普通になるか

半年後の「普通」を、いまの上限から想像しない

参照

この資料一式・発表設計資料

github.com/stealthinu/talks

構成を検討したChatGPT（gpt-live）との壁打ちログ

chatgpt.com/share/6a5ae50c-757c-83e8-81ca-740da74170f6

過去2回の発表

MCPとエージェント（2025-04）　speakerdeck.com/stealthinu/mcptoeziento

生成AIの「現在地」だけでなく「速度」も見よう（2025-07）　speakerdeck.com/stealthinu/...

ありがとうございました

ご質問どうぞ

さとうきよし

挨拶。タイトルは強い言葉だが、今日はこの仮説を検証材料つきで渡すのが目的、と最初に言う。0:00-2:00

結論先出し。聴衆に「検証すべき仮説」として渡す。口頭では「コーディング部分の実装勝負は、もう終わったのではないか」とも言い換える。2:00-5:00

万能AGIの話ではないと最初に区切る。反論1「定義が恣意的では」への先回りでもある

ここから4本の軸で見ていく。軸1は製品の歴史。5:00-10:00

ここは実感ベースと明示。製品の優劣は当時の使用感として話す

各社ベンチは条件が違い横比較不可。あくまで発表者の実感と明示。Fable 5は公開直後に一時停止し7/1再提供、運用・安全面の課題も伴う点は口頭で補足

10:00-15:00。この章の中心フレーズ

流行語の変遷ではなくボトルネックの移動である、が要点

深掘りしすぎない。未来予想への橋として1枚

軸2の結論。「以前は人間がループに入ると速かった。今は入ると遅くなる」

15:00-19:00

「MCPはオワコン?」への回答。置き換えではなく役割分担

OpenAI Harness Engineering (2026-02)、Anthropic Managed Agents (2026-04) など各社が同方向

19:00-23:00

SWE-benchには学習混入や検証器誤判定の課題もある点は口頭で

倍増則は根拠であって保証ではない。19%の話は「評価が古くなる速度」の例として使う

Cursorのブラウザは実験と明記。前回予想「大規模プロジェクトの自動開発」の答え合わせ

今回いちばん強い具体例。Jarred Sumner個人＋監督1人という点を強調

23:00-25:00。収束パート

結論スライド。下段3行で誤解を防ぐ

25:00-28:30。ここから未来予想。［予想］であることを明示して話す

「RTX 3090でFable 5が動く」と断定しない。能力水準が降りる速度の話

バイアスの自己開示を必ず入れる

28:30-30:00。人間味のある締めパート

最後の一枚。少し間を置いて読む

質疑用の付録（完全年表、METRグラフ、MCP/Skills比較、各事例の数字）は設計資料側にある