こんにちは！

コーディングエージェントシリーズ、ついに最終回です！

2026年に入り、Claude Code、Cursor 3、GitHub Copilot Coding Agentはいずれも、単なるコード補完やチャット型支援を超え、複数エージェントを使った開発ワークフローへ進化しつつあります。本稿では、AIコーディングエージェントの最新動向を、Claude CodeのAuto Memory / Subagents、Cursor 3のAgents Window、GitHub CopilotのCoding Agent、そしてSWE-benchの読み方まで含めて整理します。

第1回では、2025年12月時点で百花繚乱状態にあったAIコーディングエージェントの全体像を俯瞰し、商用からOSSまで20以上のツールを「CLIベース」「IDE統合型」「AI特化IDE型」「自律型」の4つのカテゴリに整理しました。

第2回では、Claude Code・Codex CLI・Aiderを詳細比較したうえで、現在のコーディングエージェントが共通して抱える構造的課題——コンテキストウィンドウの限界、セッション間の記憶喪失、ベンチマークと実世界のギャップ——を、Claude Codeの「4つの構造的問題」として整理しました。

そして第2回の最後では、最終回でMicrosoftのAmplifierを取り上げ、これらの課題への解決アプローチを詳しく見ていく、と予告していました。

……のですが。

はじめに：予告したことと、ちがう話をします

正直にお話しします。

第2回を書いてから、ほんの数ヶ月で、コーディングエージェントを取り巻く景色がガラッと変わってしまいました。

第2回で「Claude Codeの4つの構造的問題」として整理した課題に対して、Claude Code自身の進化によって、対応が急速に進みつつあるのです。

これは予想外でした。

Amplifierという「外部からの解決策」を期待していた話が、Anthropic自身の手によって内部から対処されはじめた、という状況です。それも、わずか数ヶ月で。

そこで本記事では、当初の予告から大幅に内容を変更し、以下の構成でお届けすることにしました。

• まず、第2回で挙げた4つの課題に対して、どのような対応が進んでいるのかを見ていきます
• 次に、Cursor・GitHub Copilotといった競合の進化を概観します
• そのうえで、Amplifierが今、どのような位置づけにあるのかを改めて評価します
• 最後に、ベンチマークの読み方（再訪）と、開発者の役割が変わりつつある現実について考えます

第2回の予告を期待してくださった方には申し訳ないのですが、2026年5月時点で本当に重要なのは「Amplifierがどう課題を解決するか」ではなく、業界全体が次のステージに入りつつあるという事実だと判断しました。

それでは、いってみましょう！

シリーズ構成（再掲）

3-1. 第2回の課題、Claude Codeはどう対応しているのか

第2回でまとめた「4つの構造的問題」を、もう一度確認してみましょう。

ひとつずつ見ていきます。

3-1-1. 記憶喪失問題への対応：Auto Memory

第2回で「毎日昨日のことを全部わすれるエンジニア」と表現したClaude Codeの記憶喪失問題。

これに対するAnthropicの回答のひとつが、Auto Memory（v2.1.59〜）です。

公式ドキュメントによれば、Auto Memoryは、Claude Codeが作業中に自動で「メモを取る」機能です。デバッグのパターン、ビルドコマンド、アーキテクチャ上の決定、ユーザーの好み——こうした情報を、プロジェクト単位のauto memory directoryに蓄積していきます。MEMORY.mdはその索引として機能し、セッション開始時には最初の200行または25KBまでが読み込まれます。

なお、auto memoryはmachine-localで、同じGitリポジトリ内のworktreeやサブディレクトリで共有される設計です。

また、GitHub Issueやコミュニティ上では、蓄積されたメモリを自動で整理・統合する実験的な挙動（Auto Dreamと呼ばれることがある）も報告されています。ただし、これについては公式ドキュメント上で安定機能として整理されているわけではないため、本稿では詳細な説明は控えます。

ポイント： 第2回で指摘した「CLAUDE.mdは手動管理」というジレンマに対して、自動でメモリを蓄積する仕組みが整備されつつあります。「記憶喪失が完全に解決した」とまでは言えませんが、永続記憶に向けた機能が急速に整備されているのは確かです。

3-1-2. コンテキスト溢れ問題への対応：要約・圧縮の仕組み

第2回で「約50回のツール使用で200Kトークンの限界に達する」と書いたコンテキスト問題。

これに対しては、Claude Codeには要約・圧縮の仕組みが整備されています。

公式ドキュメントによれば、特にSkillsについては、compaction（圧縮）後も直近のskill呼び出しが一定範囲で再付与される設計になっています。各skillは最初の5,000トークン、合計25,000トークンの予算で保持されます。

また、/compact コマンドでユーザーが任意のタイミングで圧縮を走らせることもできます。

ポイント： 内部の圧縮パイプラインの詳細は公式に明示されていませんが、「コンテキストが大きくなっても、重要な情報を保持しながら圧縮する仕組み」が整備されつつあることは確かです。第2回で紹介した「約50回で限界」という状況は、改善に向かっています。

3-1-3. 単一エージェント問題への対応：Subagents

第2回で「設計もデバッグも全て1人」と書いた単一エージェント問題。

これに対しては、Claude Codeは Subagents（サブエージェント） という機能で対応しています。

公式ドキュメントによれば、Subagentsは、メインのClaude Codeセッションから独立した「専門エージェント」を呼び出す仕組みです。それぞれが独立したコンテキストウィンドウを持ち、メインセッションのコンテキストを汚染することなく、特定のタスクに集中できます。

実装としては、.claude/agents/ ディレクトリに、エージェント定義をMarkdownで記述します。例えば：

• code-reviewer.md：コードレビュー専門のサブエージェント
• test-writer.md：テストコード生成に特化したサブエージェント
• db-migrator.md：データベースマイグレーション専門

メインのClaude Codeは、タスクの性質を見て適切なサブエージェントを呼び出し、結果だけを受け取ります。

さらに、実験的機能として Agent Teams（環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で有効化）も登場しています。これは、複数のサブエージェントがチームとして協調動作する、より野心的な仕組みです。

ただし、Agent Teamsは公式にもexperimentalと位置づけられており、デフォルトでは無効化されています。セッション再開、タスク調整、終了処理などに既知の制限があるため、現時点では本番開発フローに無条件で組み込むというより、研究・検証用途から使い始めるのが現実的です。

3-1-4. 単線試行錯誤問題への対応：Worktrees統合

第2回で「並行して試せない」と指摘した問題。

Claude Codeはこれに対して、Git Worktrees統合 で対応しています。

Claude Codeでは、Git worktreeを使って複数の作業ブランチを分ける運用が紹介されています。サブエージェントが独立したworktreeで作業できるため、コンフリクトを起こさずに複数のアプローチを並列で試すことができます。

これは、第2回で示唆した「同じ問題に対して複数の解法を並行して試したい」というニーズに対応する機能です。

3-1-5. まとめ：課題は「解決」ではなく「対応が進んでいる」

ここまで見てきたように、第2回で挙げた課題は、完全に消えたわけではありません。

ただし、Claude Code本体にAuto Memory、Subagents、Worktrees、Skills、Agent Teamsといった仕組みが入り、少なくとも**「外部ツールで補うしかなかった課題」の多くに、本体側から対処が始まっている**のは事実です。

3-1-6. その他の進化（参考）

ついでに、2026年に入ってからのClaude Codeの主な追加機能を並べておきます。

• Plugins / Skills / Hooks：拡張性の大幅向上
• MCP統合：外部ツールとの連携（Model Context Protocol）
• Custom Themes：/theme コマンドでカスタマイズ
• Vim Mode：v/Vでvisualモード
• VS Code拡張機能（ベータ）：2026年1月、ネイティブ統合
• Push Notifications：Remote Control経由でモバイル通知

第2回の頃の「Claude Codeはターミナル専用のミニマルなCLI」というイメージとは、もはや別物と言っていいくらい機能が増えています。

3-2. 競合も止まらない：Cursor 3とGitHub Copilotの進化

進化していたのはClaude Codeだけではありません。

第2回でも触れたCursorとGitHub Copilotも、この数ヶ月で大きな転換を遂げています。

3-2-1. Cursor 3：エージェント中心のインターフェースへ

2026年4月2日、Cursorは Cursor 3 をリリースしました。

公式ブログによれば、このリリースに添えられたCEO Michael Truell氏のメッセージは、なかなか挑発的なものでした。

我々は、ソフトウェア開発の第3の時代に入りつつある。 第1の時代は手動でファイルを編集する時代。 第2の時代はAIエージェントとペアで作業する時代。 そして第3の時代は、自律的に動くエージェントの艦隊（fleets of agents）が、改善を出荷し続ける時代である。

Cursor 3では、この「艦隊」を運用するためのインターフェース 「Agents Window」 が中心に据えられました。

公式に確認できる主な特徴：

• Agents Window：エージェント中心のインターフェース
• Local / Cloud Agents：ローカルとクラウドの両方でエージェントを実行
• Composer 2：Cursor独自のフロンティアコーディングモデル
• 統合ブラウザ：開発中のプレビューをエディタ内で確認
• Marketplace Plugins：プラグインによる拡張

「ペアプログラミング」から「小さなエンジニアリングチームのオーケストレーション」へ、というのがCursor 3のメッセージです。

第2回で紹介した「Cursor＝AI特化IDE」というカテゴリ分類は、もはや古い視点になりつつあります。Cursorは今や、エージェント艦隊運用のためのワークスペース になろうとしています。

3-2-2. GitHub Copilot：Coding AgentからCloud Agentへ

GitHub Copilotも、もはや「コード補完ツール」ではなくなりました。

Copilotの進化を時系列で整理すると：

• 2025年9月：Coding AgentがGA（GitHub Issueを割り当てると、Copilotが自律的に分析・実装・PR作成まで行う）
• 2026年1月：Copilot Memory（agentic memory）がpublic preview（リポジトリの有用な情報を自動推定・保存）
• 2026年：Agent Skills、Custom Agents、複数モデル対応（GPT、Claude、Gemini）

特に Coding Agent（現在はCloud Agentとも呼ばれる）は注目に値します。

GitHub上のIssueに対してCopilotをアサインすると、Copilotは以下を完全に非同期で実行します：

1. Issueの内容とリポジトリのコンテキストを分析
2. 実装計画を立案
3. 別ブランチでコードを変更
4. テストを実行
5. PRを作成し、サマリを添える

開発者は「Issueをアサインして、後で戻ってきてPRをレビューする」だけ。第2回で示唆した「自律型エージェント」の世界が、すでにGitHub上の開発ワークフローに組み込まれはじめています。

3-2-3. つまり、業界全体が動いている

Anthropic、Cursor、GitHubの3社の動きを並べてみると、進む方向はかなりはっきりしています。

見ている方向はかなり近いです。単一エージェントで頑張るのではなく、記憶を持たせ、役割を分け、並列に走らせ、最後は人間がレビューする。この形に、主要ツールが一斉に寄ってきています。

OSSエコシステムも同様で、OpenHands、Cline、Aiderなどが、それぞれの方向性で並列処理・専門エージェント・永続記憶を実装しはじめています。OpenHandsは72,000 stars超を記録しており、OSSコーディングエージェントの中でも特に注目を集めています。

3-3. では、Amplifierは何だったのか

ここで本シリーズで取り上げる予定だった、MicrosoftのGitHubリポジトリで公開されている研究プロジェクト Amplifier に戻ります。

正直なところ、本記事の執筆時点で、Amplifierの位置づけはかなり微妙なものになっています。

3-3-1. Amplifierの当初の魅力

Amplifierは、もともと「Claude Codeの構造的課題を、外側から補完する」というポジションで魅力的でした。

• 専門化されたエージェント群
• Knowledge Graph的な永続記憶のアプローチ
• マイクロカーネル設計（オーケストレーターを差し替え可能）

これらは、第2回で挙げた4つの課題に対する、まさに「あるべき姿」のひとつでした。

3-3-2. しかし、商用ツールが追いついた

ところが、ここまで見てきたとおり、Amplifierが提案していた解決策の多くは、Claude Code・Cursor・GitHub Copilotといった商用ツールが、本体機能として実装しはじめました。

• 専門エージェント → Claude Code Subagents、Copilot Custom Agents
• 永続記憶 → Auto Memory、Copilot Memory
• 並列実行 → Worktrees統合、Copilot Coding Agent
• 拡張性 → Plugins / Skills / Hooks、MCP統合

商用ツール側がこれだけ進化してしまうと、「Amplifierでなければできないこと」を見つけるのは、難しくなりつつあります。

3-3-3. Amplifier開発者自身の認識

実は、これはAmplifier開発者のBrian Krabach氏自身が、最初から述べていたことでもあります。

Krabach氏のMedium記事で、こう書いています

"This is not a launch post for Microsoft release."（これはMicrosoftのリリース告知ではない） "research-stage development environment"（研究段階の開発環境である） "Claude today, something else tomorrow. The value is the knowledge, patterns, and automation — not any specific model."（今日はClaude、明日は別のもの。価値はナレッジ、パターン、自動化にあって、特定のモデルにはない）

つまり、Amplifierは最初から 「特定のモデル・ツールに依存しない、研究フレームワーク」 として位置づけられていました。

商用ツールの進化が早すぎて、結果的に「研究フレームワーク」としての側面がより色濃くなった、というのが現状の見方として妥当でしょう。

3-3-4. それでもAmplifierが意味を持つケース

「ではもうAmplifierには価値がないのか」というと、そうとも言い切れません。以下のようなケースでは、依然として検討に値する選択肢です。

ただし、コミュニティの評価は必ずしも好意的なものばかりではありません。「アイデアは良い、だが実用にはまだ研究途上」という評価が、もっとも実態に近いところでしょう。

3-3-5. Amplifierの本当の役割

それでもなお、Amplifierには重要な役割があると考えています。

それは、「商用ツールが採用する前のアイデアを、先に試す研究プラットフォーム」 としての役割です。

実際、Amplifierが提案していた多くの概念——専門エージェントの組み合わせ、永続記憶のアプローチ、マイクロカーネル設計——は、形を変えながら商用ツールに取り込まれていきました。OSSの研究プロジェクトが、業界の方向性を先取りして示すという、健全な役割を果たしてきたとも言えます。

つまり、Amplifierは「Claude Codeの代替」ではなく、「次にClaude Codeが向かう方向を示す実験場」 として見るのが、いちばんしっくりくる位置づけかもしれません。

3-4. ベンチマークの読み方（再訪）

第2回で、SWE-bench Proの結果について「従来のSWE-bench Verifiedで70%以上のスコアを達成していたモデルが、23%程度まで性能が低下する」と紹介しました。

この問題は、2026年5月時点でも依然として重要です。

3-4-1. 2026年5月時点の主要なベンチマーク数値

公式に確認できた数値を整理します。

Claude Opus 4.7のSWE-bench Verified 87.6%は、かなり高い数値です。これだけ見ると「もう実用上の問題はないのでは」と感じます。

3-4-2. しかし、memorization懸念は残る

ところが、SWE-bench系の評価には、memorization（記憶）/ contamination（汚染）の懸念 が指摘されています。

AnthropicのProject Glasswing発表でも、OpenAIのGPT-5.5発表でも、評価結果を読む際にこの点が注記されています。

実際、より厳格なベンチマーク（SWE-bench Pro）では、スコアが大幅に低下します：

• Claude Mythos Preview：Verified 93.9% → Pro 77.8%
• Claude Opus 4.7：Verified 87.6% → Pro 64.3%
• GPT-5.5：Pro 58.6%

また、実務では公開OSSベンチマークとは異なる制約が加わるため、プライベートな商用コードベースで同等の性能が出るとは限りません。

つまり、公開ベンチマークの数値は有用な参考値ではあるが、自社コードベースでの性能をそのまま保証するものではない、ということです。

3-4-3. 何を信じるべきか

ベンチマークの数字は、ツール選定の参考にはなりますが、自社のコードベースで、自社のタスクで実測すること 以外に、本当の性能を知る方法はありません。

実務的なアドバイスとしては、以下のようなものになります：

• ベンチマークは「上限の指標」として見る（実環境ではこれより低い）
• 自社の代表的タスク3〜5本で、実際に複数ツールを試す
• 「成功率」だけでなく「失敗時の挙動」も評価する（暴走するか、適切に止まるか）
• セキュリティ要件・データ取扱要件と照らし合わせる

ベンチマークが上がっても、実務での「使える/使えない」は別問題である、というのは、2025年12月時点の第1回・第2回から、本質的に変わっていません。

3-5. 開発者の役割は、すでに変わりつつある

ここまでの話を踏まえると、ひとつの大きな構造変化が見えてきます。

それは、開発者の役割が「コーダー」から「エージェント・オーケストレーター」へと変わりつつある、という変化です。

3-5-1. 「コードを書く人」から「エージェントを指揮する人」へ

Cursor 3のキーワード「fleets of agents（エージェントの艦隊）」、GitHub Copilotの「Coding Agent」、Claude Codeの「Subagents + Worktrees」——これらに共通しているのは、人間が複数のエージェントを並列に走らせ、結果をレビュー・統合する という働き方への移行です。

1人の開発者が、複数のエージェントを同時に走らせるような働き方が、一部では現実のものになりつつあります。

3-5-2. これが意味すること

この変化が示唆するものは、いくつかあります。

1つ目は、「タスクの分解能力」の重要性が増したことです。

エージェントを並列に走らせるためには、タスクを「並列に実行できる単位」に分解する必要があります。これは、実装そのものを書く能力よりも、設計・分解・統合の能力が問われる仕事です。

2つ目は、レビューの負担が増えたことです。

エージェントが書いたコードは、人間が書いたコードより 「一見もっともらしいが、微妙にずれている」 ことが多くあります。並列に5本のPRが上がってきたら、それを5本ぶんレビューする必要があります。

3つ目は、コストの感覚が変わることです。

Cursor 3のCloud Agent、GitHub CopilotのCoding Agent、Claude CodeのSubagents——これらは並列度に応じてコストが増えます。「速度を金で買う」という選択が、開発の現場で日常になりつつあります。

3-5-3. それでも変わらないこと

一方で、変わらないことも、はっきりしてきました。

• ベンチマークの数字と、実務での使いやすさは別問題
• 自社コードベースでの実測なしに、ツール選定はできない
• エージェントを「監視なしで走らせる」のは、依然としてリスクが高い
• セキュリティ・プライバシー要件は、ツール選定の前提として効いてくる

ツールが進化しても、「何を作るべきか」を決めるのは人間です。エージェントが書いたコードが「正しいかどうか」を判断するのも、最終的には人間です。

「コードを書く時間が減って、考える時間が増えた」——これは、2026年5月時点でAIコーディングエージェントを使っている多くの開発者が共通して感じていることだと思います。

第3回まとめ

本稿では、当初予告したAmplifier中心の内容から方向を変え、2026年5月時点のコーディングエージェント業界全体を概観しました。

ポイント

• 第2回で挙げた「Claude Codeの4つの構造的問題」に対して、Claude Code自身の進化（Auto Memory、Subagents、Worktrees統合）で対応が進んでいる
• Cursor 3は「エージェントの艦隊」、GitHub Copilotは2025年にCoding AgentをGA化し、業界全体が「エージェント・オーケストレーション」の時代に入りつつある
• Amplifierは「Claude Codeの代替」ではなく、「商用ツールの方向性を先取りする研究プラットフォーム」 として位置づけるのが現実的
• SWE-bench系にはmemorizationの懸念があり、自社コードベースでの実測が不可欠
• 開発者の役割は「コーダー」から「エージェント・オーケストレーター」へと、変わりつつある

シリーズを振り返って

3回にわたってお届けしてきた本シリーズ、いかがでしたでしょうか。

第1回（2025年12月）の時点では、「20以上のツールがあって、どれを選べばいいかわからない」という状況でした。

第2回（2026年1月）では、「ツールの本質的な限界」を整理し、構造的課題を浮き彫りにしました。

そして第3回（2026年5月）では、その課題への対応が想像よりずっと早く進んでおり、業界全体が次のステージに入りつつあることを確認しました。

わずか5ヶ月で、この業界の景色がここまで変わってしまうとは、第1回を書いた時点ではまったく予想していませんでした。

おそらく、この記事を書いている2026年5月の時点での「最新動向」も、半年後には古い情報になっているはずです。それくらい、この分野の進化は速い。

ただ、3回を通して見えてきた本質的なポイントは、おそらく当面変わりません。

• 何を作るべきかを決めるのは、依然として人間である
• エージェントが書いたコードを評価できるのも、依然として人間である
• ベンチマークの数字よりも、自社の実測のほうが信頼できる
• ツールは増え続けるが、本質的な選定基準（自社のコード、要件、運用体制）は変わらない

エージェントの艦隊を指揮する立場に立った今、「何を指揮するか」を考えるのが、開発者にとって、これまで以上に大事な仕事になったような気がしています。

企業でのAIコーディングエージェント導入をご検討の方へ

企業でコーディングエージェントを導入する際には、単に「どのツールが最も賢いか」ではなく、自社コードベースでの成功率、レビュー負荷、セキュリティ要件、権限設計、利用コスト、失敗時の止め方まで含めて評価する必要があります。

Qualitegでは、AIエージェントやLLM活用の実装知見をもとに、ツール選定からPoC設計、社内開発プロセスへの組み込み、運用ルール整備までご支援しています。

ご相談・お問い合わせはこちらから受け付けております

それでは、3部作にお付き合いいただき、ありがとうございました！
またお会いしましょう！