こんにちは！

今回は、20種類以上あるまさに百花繚乱なAIコーディングツールを一挙に紹介＆解説していきたいとおもいます！

AIをつかったコーディングはもはや常識となり、日々目まぐるしく新しいツールが登場しています。当社でも自社開発のAIコーディングツールをふくめ複数のツールを活用してソフトウェア開発をすすめていますが、次々とナイスなツールがでてきて興奮しつつも、正直キャッチアップが追いつかない…！という状況です。

「結局どれを使えばいいの？」「Claude CodeとCursorって何が違うの？」「オープンソースでも使えるやつあるの？」——そんな疑問を持っている方も多いのではないでしょうか。

そこで本シリーズでは、2025年12月時点でのAIコーディングツールを徹底的に整理してみました。商用サービスからオープンソースまで、20以上のツールを比較しながら、それぞれの特徴や使いどころ、そして現時点での限界についても現場視点をいれながら正直にお伝えしていければとおもいます

※「AIコーディングツール」は「コーディングエージェント」といったほうが今風なので記事内ではコーディングエージェントと呼ぶことにします。

1-1. はじめに：なぜ今コーディングエージェントなのか

2025年、ソフトウェア開発の現場では「AIコーディングツール」や「コーディングエージェント」と呼ばれるAIツールが急速に普及しています。これらのツールは、単なるコード補完を超え、ファイルの読み書き、bashへのコマンド送信、テストの実施、さらにはGitワークフローの管理までを自律的に行う能力を持っています。

GitHub Copilot、Cursor、Windsurf、Devinといった商用サービスから、AnthropicのClaude Code、OpenAIのCodex CLI、GoogleのGemini CLI、MicrosoftのAmplifier、そしてCline、OpenCode、OpenHands、Aider、Plandexといったオープンソースツールまで、この分野は百花繚乱の様相を呈しています。

しかし、これらのツールを実際に使い込んでいくと、いくつかの根本的な課題が浮かび上がってきます。

本シリーズでは、コーディングエージェントの現状を技術的な観点から整理し、各ツールが採用しているアプローチの違い、そして今後解決が求められる論点について考察したいとおもいます。

シリーズ全体の構成

本シリーズは、2025年に急速に発展しているコーディングエージェントについて、技術的な観点から深く掘り下げる全3回の連載を予定しております

1-2. コーディングエージェントとは何か

1-2-1. 基本的な定義

コーディングエージェントの本質は、LLM（大規模言語モデル）を中心としたオーケストレーションシステムです。ユーザーが「このバグを直して」と指示すると、エージェントはまずコードベースを読み込み、問題箇所を特定し、修正案を生成し、実際にファイルを編集し、テストして検証するという一連の作業を自律的に行います。

1-2-2. 基本アーキテクチャ

技術的には、これらのツールはすべて同じ基本アーキテクチャを共有しています。

LLMに対してツール定義（bashへの送信、ファイル読み書き、検索など）をJSON Schemaで渡し、LLMからの「tool_call」応答を解析して実際にファイル保存やコマンド送信を行い、その結果をLLMに返却してループを継続するという仕組みです。

重要な点は、LLM自体はファイル操作やコマンド送信はできないということです。

LLMはコードを生成したり何をすべきかを判断することが役割で、実際にファイルに保存したりbashにコマンドを送るのはエージェントフレームワーク側（Claude CodeやCodex CLI等）にあるツールが担当しています。

このツールとは、LLMから呼び出される外部APIのような存在で、コーディングエージェントにおいてはローカル実行（またはリモート実行の場合もあります）され、このプロトコル自体は最近ではMCPとしてデファクトスタンダードになっています。MCPについては以下ブログでも記事化しております。

Model Context Protocol完全実装ガイド 2025- 仕様変遷から最新Streamable HTTPまでの全て

こんにちは！ 現在、LLM業界で破竹の勢いでひろまっているMCPについて、本日はとくに実装面について解説していきたいとおもいます。 MCP、MCPとひとくちにいっていますが、実は短期間でけっこう「標準」とよばれる仕様が変化しておりますので、仕様のバリエーションを順を追って解説しつつ、実際に実装をしていきたいとおもいます。 さて、MCPですが、2024年後半、Anthropicが発表したModel Context Protocol（MCP）は、AI分野における重要な転換点となりました。 従来、各AIベンダーが独自に実装していたツール呼び出し機能(tool useと呼びます）を標準化し、AIモデルと外部システムの連携を統一的に扱える仕組みを提供しました 本記事で、MCPの誕生から現在に至るまでの技術的変遷を詳細に追いながら、2025年時点での最適な実装方法を完全なソースコードと共に解説します。特に、仕様の変化に振り回されがちな実装者の視点から、なぜ現在の形に収束したのか、そして今後どのような実装アプローチを取るべきかを明確にしていきます。 第1章 MCPが解決しようとした問題

Qualiteg BlogQualiteg プロダクト開発部

1-3. 2025年コーディングエージェント全体像

さて、ここからは最新（2025年12月時点）の主要なコーディングエージェント・AIコーディングアシスタントの全体像をみていきましょう。

とにかくメジャーどころでも百花繚乱たくさんありますが、ざっくりわけると、商用サービスとオープンソースのものがあります。

1-3-1. 商用サービス

1-3-2. 研究・実験フレームワーク

1-3-3. オープンソース：CLIベースエージェント

1-3-4. オープンソース：IDE拡張型エージェント

1-3-5. オープンソース：自律型・研究用途

これだけたくさんあるので、どのように紹介するか迷ってしまいますが、まずは、これらコーディングエージェント・ツールの分類をしてみたいとおもいます

1-4. ツールのカテゴリ分類

ということで、コーディングエージェントを以下４つのカテゴリに分類してみました。この分類にそって、それぞれのコーディングエージェントについて解説をしていきたいとおもいます。

①CLIベースエージェント

まずCLIベースエージェントには、Claude Code、OpenAI Codex CLI、Aider、Amplifierなどが該当します。

CLIベースのエージェントはターミナルから直接AIと対話し、ファイル操作やbashコマンドの実行を行える点が特徴で、特定のIDEに縛られず、既存のCLI中心の開発ワークフローと自然に統合できる柔軟性があります。

もっとも、同じCLIベースであっても「エージェントっぽさ」、「エージェント性」には差があります。

たとえばAiderは、diff駆動で人間が主導する設計色が強く、実態としてはCLI上でのペアプログラミングに近い位置づけです。一方、Claude CodeやCodex CLIは、ツール実行主体としてのAIを前提にしており、よりエージェント的な設計思想を持っています。

Claude Codeは当初、Node.jsの導入などローカル環境構築が必須で、やや導入ハードルが高い印象がありました。しかし直近では、環境構築不要でWebからも利用できるようになり、手軽さの面では大きく改善しています。ただしWeb版は、ローカルファイルへの直接操作やbash実行の自由度という点ではCLI版に制約があり、「手軽さのWeb」「制御力のCLI」という住み分けでしょうか。

このCLIベースの中で、少し毛色が異なる存在がMicrosoft社のAmplifierです。
Amplifierは単なるツールではなく、研究目的で設計されたフレームワークであり、既存のコーディングエージェントが抱える構造的なペインポイント――たとえばコンテクストサイズを超えるたびにセッションが分断され、過去の経験が活かされない問題――を根本から解決することを目指しています。

重要なのは、Amplifierが「記憶を持つエージェント」を作ろうとしているだけではない点です。Amplifierは、LLMを単発の推論器として扱うのではなく、状態・履歴・抽象化された経験を外部構造として保持し、長期的に成長可能なプログラム合成システムとして位置づけています。この思想には、コーディングエージェントを次の段階へ進めるポテンシャルを強く感じています。

旧版のAmplifierは、Claude Codeをフロントエンドとして利用し、ユーザーとClaude Codeのやり取りを上位レイヤでフックする形で動作していました。現在の新版では独立したOSSフレームワークとして再設計され、Claude Codeに限らず、商用LLMやOllamaなどのローカルモデルにも対応しています。詳細については、第3章（第3回）であらためて解説します。

②IDE統合型

IDE統合型の代表例としては、GitHub CopilotやAmazon Q Developerが挙げられます。
VS CodeやJetBrainsなど、既存のIDEワークフローを維持したままAI支援を追加できる点が特徴で、特にMicrosoftやGitHubのエコシステムとの親和性が高く、企業導入の心理的・制度的ハードルが低いことが強みです。

GitHub Copilotは、最も早期に登場したAIコーディング支援ツールのひとつで、私自身も登場直後に導入しました。当初の印象は、非常に賢いコード補完で、Microsoftっぽい言葉でいえば、まさに「次世代のIntelliSense」という感覚でした。

現在のCopilotは、補完機能にとどまらず、Copilot ChatやCopilot Workspaceなど、タスク支援や対話的操作へと機能を拡張しています。ただし設計思想の中心はあくまでIDEにあり、AIはIDEを補助する存在として統合されています。この点が、次に述べるAI特化IDE型との大きな違いです。

③AI特化IDE型

AI特化IDE型は、AIネイティブIDEと呼ぶのがふさわしいカテゴリで、CursorやWindsurfが代表例です。
いずれも登場と同時に熱狂的な支持を集め、既存のVS Codeをforkしながらも、AIを前提としたUIとワークフローを根本から再設計しています。

Agent Mode、Background Agents、Tab補完といった機能がネイティブに統合されており、単なる拡張機能では到達できないレベルで、プロジェクト全体を前提としたコード理解と操作が可能です。表面的にはVS Codeに似ていても、実態としてはもう別物と言ってよいでしょう。

これらのIDEは、「AIと一緒にコードを書く」というよりも、AIを第一級の開発主体として扱う体験に最適化されています。人間が細部を指示するのではなく、意図を伝え、AIが自律的に編集・提案・修正を行うという開発スタイルを自然に受け入れられる設計になっています。

④自律型エージェント

自律型エージェントには、DevinやOpenAI Codex（クラウド版）が該当します。
これらは人間の介入を最小限に抑え、タスク全体を丸ごと委任することを目指したアプローチです。Devinは登場時に大きな話題を呼び、多くの期待を集めました。

一方で、現時点では複雑なタスクにおける信頼性には依然として課題があります。SWE-benchなどのベンチマークで高いスコアを記録していても、それがそのまま実世界での性能を保証するわけではないことに注意が必要です。

といっても、Devinだけが複雑なタスクに弱いわけではなく、どのコーディングエージェントも、コードベースの規模が一定以上になると、統一感がなかったり、急にお作法を忘れたりと、「あれ？」っというようなコードを出してくることがあります。

SWE-benchに関していえば、問題定義が明確で、修正範囲が比較的限定されたタスクを対象としています。これに対し、実世界の開発では、要件が曖昧で、正解が一つでない状況が多く、人間の意図や文脈を深く理解する必要があります。この構造的な違いが、ベンチマーク性能と実務での実感のギャップを生んでいます。

1-5. 2025年におけるオープンソース・コーディングエージェントの現在地

今回の最後に、オープンソースのコーディングエージェントについても解説いたします。
オープンソースのコーディングエージェントは、2025年に入って急速に選択肢が充実してきました。さいしょは「実験的」「玩具的」と見られることも多かったOSSエージェントですが、いまでは個人開発からスタートアップの実務レベルまで、十分に現実的、実用的な選択肢になりつつあります。

現在のOSSかいわいを俯瞰するために、インターフェースの違いとプロジェクト間の系譜を一枚で整理してみました。

CLI / Terminal 型

は、ターミナルから直接AIを操作するタイプです。代表例は OpenCode で、Claude Codeのオープンソース代替として急速に使われるようになっています。ただ、よくClaude Codeのオープンソース代替として紹介されますが、実際には単なる互換実装にとどまりません。75以上のLLMプロバイダーに対応する抽象化レイヤを最初から前提とした設計になっており、商用APIとローカルLLMが混在する環境でも柔軟に運用できる点は、OSSならではの強みではないでしょうか。
Aider も人気があり、人間主導で差分を確認しながら進めたい開発者に向いています。ほかにもPlandexは、人間主導寄りのワークフローを好む開発者に支持されています。
また、Googleが公開した Gemini CLI もこのカテゴリに入り、手軽に試せる選択肢として存在感があります。Gemini CLIはOSSなの？という疑問ですが、こちらはApache 2.0ライセンスでGemini CLIを公開しており、CLI自体はOSSだが、実行時には商用のGemini APIを利用する構成になっています。Gemini CLIは現時点では強い自律性を持つエージェントというより、高性能なCLIクライアントに近い位置づけですが、ライセンスの自由度とGoogle公式という安心感から、今後の拡張が注目されています。

IDE Extension 型

は、VS CodeなどのIDEに組み込んで使うタイプです。

この分野では Cline が頭一つ抜けており、OSSでありながら実務利用の事例も多く、まず名前が挙がる存在です。IDE拡張型の代表例であるClineは、VS Code拡張として累計400万以上のダウンロードを記録し、約3,200万ドルの資金調達も実施しています。オープンソースでありながら、ツール実行、プロジェクト全体のコンテクスト理解、モデル非依存設計といった点で完成度が高く、事実上のデファクトスタンダードに近い存在になっています。その派生として生まれたRoo Codeも、Clineの思想を引き継ぎつつ独自の進化を遂げています。また比較的シンプルな体験を提供する Continue もよく使われています。

AutonomousAgent （自律型エージェント）

自律型エージェントのカテゴリでは、OpenHands（旧OpenDevin）が特に注目されています。GitHub Starsは3万を超え、商用のDevinに対するオープンソースの代替として広く認知されています。ただし、ここでいう「自律型」は完全自動を意味するものではありません。実際には、人間のレビューや介入を前提としつつ、タスク分解やツール実行をできるだけエージェント側に委ねる設計になっています。OpenHandsは現在、実務即戦力というよりも、自律エージェントの最新アーキテクチャや実装パターンを試すための実験場としての性格を強めています。GPT-Pilot や GPT-Engineer もこのカテゴリに入り、自律エージェントの挙動を試したい人に使われています。

Browser-based 型（ブラウザベース）

は、ブラウザだけで完結するタイプです。代表的なのは Bolt.diy で、Bolt.newをオープンソース化したプロジェクトです。環境構築なしで動かせるため、学習用途や軽いプロトタイピングでよく使われています。複雑な実務開発では制約もあります。

これらのOSSコーディングエージェントは、いずれも基本的に無料で利用でき、必要なのはLLM APIの利用料のみです。そのため、個人開発者やスタートアップにとっては、初期コストを抑えつつ最先端の開発体験を得られる魅力的な選択肢になっています。一方で、運用設計や評価、安全性については自ら責任を持つ必要があり、「便利だからそのまま本番投入できる」わけではない点も、OSSらしい現実として理解しておく必要があるとおもいます。

まとめ

本稿では、2025年12月時点での主要なコーディングエージェントの全体像を俯瞰しました。

ポイント

• コーディングエージェントは「LLM + ツール層」のオーケストレーションシステム
  
• LLMはコード生成と判断のみ。ファイル保存やコマンド送信はフレームワーク側が担当
  
• ツールは4カテゴリに分類できる
  →IDE統合型、AI特化IDE型、自律型、CLIベース型
  
• 商用・OSS含め20以上のツールが乱立する百花繚乱状態
  
• Amplifierは研究フレームワークとして先進的機能を実験中

次回予告：第2回「主要ツール比較と構造的課題」

第2回では、主要なCLIベースエージェント（Claude Code、Codex CLI、Aider等）を詳細に比較し、現在のコーディングエージェントが抱える構造的な課題——コンテキストウィンドウの限界、セッション間での記憶喪失、ベンチマークと実世界のギャップ——について技術的に掘り下げてみたいとおもいます。

特に、約50回のツール使用でコンテキストが溢れる問題や、SWE-bench Verifiedで70%のスコアが実世界では20%台に落ちる現象など、現場で直面する課題を具体的に解説します。

それでは、また次回お会いしましょう！