エディタ型からCLI型・自律型へと多様化するコーディングエージェント
はじめに：コーディングエージェントの新たな分類
今年初めに筆者が投稿した「ClineとAIコーディングツールの現状」ではAIコーディングツールを「コード補完」「チャットアシスタント」「コーディングエージェント」の3つに分類しました。しかし現在では「エージェント」が包括的な概念となり、この区別の必要性が薄れています。
さらに現在は役割や機能ではなく
- コーディングエージェントがどこまで自律的に開発プロセスに関与するのか
- 開発タスクが実行される環境はどこか
- ユーザーとの対話インターフェイス
が本質的な違いになってきました。
本記事では、こうした変化を踏まえて解説します。
本記事の分類について
「AI Agents Are Here. What Now?」ではAIエージェントの重要な特性の一つとして「自律性（autonomy）」が挙げられています。「自律的（agentic）」であるとは、ある目標が与えられた際に、それをサブタスクに分解し、各サブタスクを人間の直接的な介入なしに実行して解決できることを指します。
本記事では、現在のコーディングエージェントの自律性をSAEの自動運転レベルのアナロジーに当てはめます。巷で呼ばれている名称を参考に、「エディタ型」「CLI型」「自律型」という３つのタイプを示すキーワードを用意しました。
エディタ型（GitHub Copilot, Cursor）
- 自動運転レベル： レベル2（部分自動化）
- 開発者の関与： 常に監視し、いつでも介入可能。リアルタイムに差分確認・承認・修正
- 動作環境： エディタ内
- 重視する価値： 安全性 - 全ての変更を制御可能
CLI型（Claude Code, Codex CLI）
- 自動運転レベル： レベル3（条件付き自動化）
- 開発者の関与： エージェントが開発担当。重要な判断時に確認を求められる
- 動作環境： ターミナル、ファイルシステム
- 重視する価値： 効率性向上 - エージェントのモジュール化
自律型（Devin, OpenHands）
- 自動運転レベル： レベル4（高度自動化）
- 開発者の関与： 目標設定と結果確認のみ。緊急時のみ介入
- 動作環境： VM・コンテナ（サンドボックス）
- 重視する価値： 生産性最大化 - タスク完全自動実行
- ※分類の軸としてはVM・コンテナ型が自然かもしれませんが市場での呼称に合わせました
各タイプに優劣はありません。レベルが上がるほど開発者の介入頻度が減りますが、 ある程度はコントロール可能です。製品ごとに介入レベルの思想があり、それが機能デザインや最適なタスクにも反映されています。この点が本記事の分類の動機です。
開発者たちの評判としても「エディタ型は好きだが自律型に分類された製品は不満がある」「CLI型のエージェントのみしっくりくる」など評価が分かれています。
そこで各タイプを試してもらうために、製品を可能な限りリストアップしたのち、筆者が実用しているものの中から「最初に選ぶならこれ」「なるべく低コストで」「仕組みを知りたい」の３つをピックアップしました。目的に応じて参考にしてください。ただしこれは個人用途向けでEnterprise版はスコープに含めていません。
エディタ型コーディングエージェント
エディタ型コーディングエージェントは、CursorやGitHub Copilot、Cline に代表されるIDEのエディタに統合されたコーディングエージェントです。開発者がエディタのチャットパネルで指示を入力すると、エディタ情報がAIモデルに送信されます。モデルの応答をエージェントが解析し、ファイル編集やコマンドを実行、開発者は差分を確認しながら承認や修正が可能です。
コードのインデックス化
各製品によって特徴が表れているのがユーザーのソースコードをエージェントがどう検索インデックス化して活用するかの戦略です。
通常ワークスペース全体は大きすぎて全てをモデルに渡せないため、インデックスの参照によって関連性の高いコード断片が抽出されます。
CursorやGitHub Copilotはローカルとリモートにユーザーのソースコードから生成したインデックスを保持します[1][2]。Cursorは埋め込み形式のみを自社管理のサーバーに保持し、コード断片はローカルから取得するというセキュリティモデルを採用しています。そしてWindsurfは個人利用ではローカルのみでインデックスを構築します[3]。
一方、ClineやRoo Codeなどはデフォルトでインデックス化には対応していません。実行時にオンデマンドでコード断片を収集し、モデルに送信するコンテキストに挿入する簡易的な処理のみです。
この部分の挙動はコンテキストウィンドウ問題に影響します。コンテキストウィンドウ問題とは会話を重ねるうちに、蓄積されたファイルや実行結果の情報によってコーディングの精度が悪化するよく知られた現象です。
コミュニティではコンテキストウィンドウ問題に対応するためにローカルに履歴ファイルを書き出したり、外部プログラム経由で取得するなど試行錯誤が進められています。
「Unlocking Persistent Memory: How Cline's new_task Tool Eliminates Context Window Limitations」ではClineのnew_taskツールが現在のコンテキスト情報を決められた書式にそって変換し、新規セッションに引き継ぐための方法を説明します。
このようにコードをインデックス化する、しない。コード生成に使うコード断片をどのように参照するのかはコーディングエージェントにとって重要な要素になっています。
おすすめ製品
- 最初に選ぶなら：Cursor
- ユーザーが多く、入門記事が見つかりやすい
- なるべく低コストで：Copilot Chat
- Cursor Proと比較してコストが抑えられる
- 仕組みを知りたい：Roo Code
- VS Code拡張のClineをオリジナルに再設計されリファクタリングされたもの。自分で改造したい人向けに最適
CLI型コーディングエージェント
CLI型コーディングエージェントはClaude Code やCodex CLI などのターミナル（コマンドライン）上で動作するコーディングエージェントです。開発者がターミナルの対話シェルやコマンドへの引数入力で動作し、コード編集やコマンド実行を自動化します。
特徴
CLI型はターミナル上で動作し、対話シェルやコマンド引数で指示を受けてコード編集やコマンド実行を自動化します。エージェントはファイルの探索・更新・差分提示を行い、その内容をターミナル上で順次表示。開発者は各変更を確認しながら受け入れます。エディタ型とは異なり、チャットや差分確認がすべてターミナルで完結します。
また、対話シェルを起動せずに、コマンド引数やパイプ処理による即時実行も可能で、許可フローを省略した自動化も対応です。それによってCLI型は柔軟な操作や外部との連携がしやすいのが特徴です。
エディタ型は現在開いているファイルなど多くのコンテキストを持つのに対し、CLI型は制約上、それらを手入力しない限りエージェント側で判断することになるため、初期コンテキストより少ない状態から開始します。そして必要なコンテキストはエージェント自身が「半自律的」に探索して構築します。「CLI型はコード理解能力が高い」と評価されるのはこの探索の性能によるものです。
またCLI型にはエディタ型に見られたような「コードのインデックス化」を備えた製品はありません。なのでClineなどと同じく実行時にファイル処理でコードを抽出して送信するアーキテクチャを取ります。
GUIサポート
いくつかの製品はターミナルで実行しているエージェントとデスクトップのGUIを連携してサポートする機能を持ちます。Goose Desktop はシンプルなラッパーで、コマンドラインと同じ操作をデスクトップアプリのUIから実行できます。
Claude CodeのGUIサポートはVS CodeやJetBrains IDE内のターミナルでの実行時にエディタウィンドウと連携する拡張機能／プラグインです。差分表示をターミナルではなくエディタ上で行うのでCLI型にはない機能性を補完します。
Amazon Q Developer in IDE のエディタ拡張はターミナルUIをチャットパネルに置き換える逆輸入的なアプローチでエディタ型コーディングエージェントのような体験を提供します。
おすすめ製品
- 最初に選ぶなら：Claude Code
- コーディングエージェントとしての評価が高いClaude系モデルのAnthropic公式ツール。一番期待通りに動作する。
- 反面、潤沢なトークン量でAPIアクセスするので料金はかさみがち。
- なるべく低コストで：Amazon Q Developer CLI
- AWS Builder IDによる無料プランあり
- Claudeを含む複数のモデルに対応したBedrockが自動で選択する
- 仕組みを知りたい：Codex CLI
- 後発で素直な実装なのでコードが読みやすい
- MCPサポートやRust移行、サンドボックス実行など活発に開発されているので過程で学べる
自律型コーディングエージェント
最後に自律型コーディングエージェントです。自律型コーディングエージェントは、「Introducing Devin, the first AI software engineer」によってそのコンセプトが広く知られるようになりました 。「完全自律型」とより強調されることもあります。
特徴
自律型コーディングエージェントは、人間の開発者と同じようにタスクを受け取り、完了を報告することを想定しています。
DevinやManusはエージェント自身がWebブラウザを使う能力を持ち、タスクの最中に自由にインターネットアクセスをします。
またDevinやCursor Background Agentsは変更後のコードをユーザーが追加で自由に編集したり、ターミナルでコマンド実行するためのインターフェイスを用意します。これはWeb IDE機能と呼ばれています。IDEに非対応の製品はエージェントがGitHubへ変更ブランチをPushするのみで、そのコードを編集したい場合は自分でチェックアウトするなどの作業が必要になります。
自律型コーディングエージェントはより少ない情報量から自動でコンテキストを探索し、タスクを計画・実行します。ユーザーとの会話は最小限になることを目指しています。これはソースコード変更を中心に細かいフィードバックサイクルを繰り返すエディタ型とCLI型とは対照的です。
Devinのコードのインデックス化：
エディタ型で説明したワークスペース全体のコードをインデックス化してタスクに活用する機能は自律型コーディングエージェントも備えています。通常はGitHubリポジトリの紐付けを行うと自動で実行されるはずです。
興味深いのはDevinはこのコンポーネントを使って単独のDeepWikiというサービスを提供している点です。DeepWikiのコード理解性能が評判になるほどDevinの能力のPRになっています。
laiso
実行環境
自律型コーディングエージェントはユーザーの介入をなくすために、独立した開発環境で長時間のタスク実行が必要になります。このため、マネージドなサンドボックス環境で実行されます。多くは開発元が管理するLinuxベースのコンテナやMicroVMのサンドボックス環境で実現されています。
サンドボックスのレベルに違いがあり、Codexはセットアップ以降のタスク実行時にインターネットから隔離されています。DevinやCursor Background Agentsのように実行時に外部アクセスもできるシェルにログインしてコマンド実行できる製品もあります。
またインスタンスの状態管理について、DevinやCursor Background Agentsはステートフルに扱えます。セットアップした状態のスナップショットを保持し、起動とスリープを繰り返してタスク横断的に再利用します。一方、JulesやGitHub ActionsベースのCopilot Coding AgentやClaude Code GitHub Actionsはタスクの実行ごとに環境をステートレスに運用します。
筆者は以下の記事でCursor Background Agentsの実行環境を詳しく解析しました。
laiso
メリットとトレードオフ
自律型コーディングエージェントの最大のメリットは、タスクの成功率が高まるほど開発者の介在時間が短縮され、生産性が向上する点です。タスクの成功率は、ユーザーの使い方だけでなく、モデルやエージェント自体の進化によっても向上します。近年のLLM分野の進歩がその好例です。
また、タスクごとに独立した開発環境を持ち、開始と完了時のみ開発者が関与するため、複数タスクの並列実行が可能となり、エディタ型やCLI型よりも一人当たりの生産性が高まります。
一方で、トレードオフも存在します。自律型はタスク完了まで中断せず進行するため、タスクごとのレイテンシが長くなりがちです。成功率が低い場合は手戻りが発生し、かえって生産性が下がるリスクもあります。エディタ型やCLI型では細かいフィードバックが得られるため、このリスクを回避しやすいです。そのため現状では、「最初から成功率の高いタスクを割り当てる＝ジュニアエンジニア的な使い方」が主流です。
さらに、タスク成功率を上げるためには適切な指示やコンテキストの準備が必要であり、これが隠れたコストとなります。こうしたドキュメント整備はチームの資産にもなりますが、スピード重視のプロジェクトではボトルネックとなる場合もあります。
おすすめ製品
- 最初に選ぶなら：Devin
- 製品として先行しており、実績がある。自律型コーディングエージェントのコンセプトを学ぶのに最適。
- なるべく低コストで：Jules
- Google製の後発サービスで無料で利用できる
- 仕組みを知りたい：なし
- 領域として新し過ぎるため既存製品をカバーできる参考実装がありません
- OSSとしてはOpenHandsがあります
使い分けの指針
ここまで「エディタ型」「CLI型」「自律型」という３つのタイプのコーディングエージェントの説明をしました。次に、それぞれのタイプをどのような指標で選択すべきかについて私見を述べます。
エディタ型：豊富な学習リソースを活用したい入門者
まずどのような状況でも最初におすすめしたいのはエディタ型のコーディングエージェントです。
本記事ではCursorを最初に挙げましたが、”Clineに全部賭けて”もよいですし、学生特典を受けて無料でCopilotを使うのもいいかもしれません。十分に競争が進んでおり体験に差はありません。
すでに多くのユーザーに活用されているため学習リソースに事欠きません。エンジニアではなくドキュメント作成するホワイトワーカー向けのコンテンツすらあります。
ソフトウェア開発自体の入門を今から始める人によっては「コーディング不要に見える」自律型コーディングエージェントに目移りしてしまうかもしれませんが、そのような人でもエディタ型にまず入門してください。理由は現在の自律型コーディングエージェントはまだコーディングの知識なしにブラックボックスで利用できる水準でないからです（急がば回れ）。
CLI型：エディタ型がしっくりこなかった熟練のツール開発者
次にCLI型コーディングエージェントです。
CLI型の最大の特徴は「エディタから独立している」という点です。そのためエディタ型を導入してみたもののしっくりこなかった開発者には進んで試して欲しいです。
エディタ型をうまく活用できないと感じてしまう点はいくつかあります。典型的には普及した時期にツール呼び出し性能の悪いモデル（gemini-2.0-flashやgpt-4oなど、Aider LLM Leaderboardsで下位になるようなモデル）で試した、コードベースが大きくタスクも読み：書き＝９：１程度のものが多い、そもそもVSCodeベースのエディタ操作に馴染めない。などです。
これらはCLI型に切り替え、愛用しているエディタで、エージェントなしの自分のコーディングモードとのコンテキストスイッチをもうけることで改善される可能性があります。本記事であげたClaude Codeはモデル由来の問題が起きないですし、入力コンテキストの比重がファイル寄りになるCLI型の方が読み：書き＝９：１タスクに適用する余地があります。
またCLI型を好むような開発者はシステム運用時の隙間家具的なツールの作成機会も多いと思います。エディタ型と違いCLI型はエージェント機能を自分のプログラムから呼び出したり連携したりできるので、自作ツール内でもうまく活用できると思います。
自律型：新技術の検証に関心のあるアーキテクト
最後に自律型コーディングエージェントですが、これは一番実験的な段階なので「果たしてこの技術が本当に使いものになるのか」という検証をしたい新しいもの好きの方におすすめします。自律型コーディングエージェントを自分たちのプロジェクトや組織にどのように適用するのかを考えてアーキテクトの立場で評価します。
もしかしたら今の形の自律型コーディングエージェントのコンセプトは来年には別物になっているかもしれませんし、「時代に早過ぎたよね」と廃れている可能性すらあります。
それでもこれまでの投資がサンクコストになるリスクを承知で、今の段階からキャッチアップして独自の自律型コーディングエージェントを構築できるぐらいのノウハウを構築するのは、2020年代のAIブームがここまで拡大した現在の状況で考えると、きっと無駄にならないでしょう。
おわりに：「自律型コーディングエージェントにベットすべきですか？」
自律型コーディングエージェントにベットする必要はありません。ただし私の予想はよく外れます。
結論としては、エディタ型のVSCodeやCursorの利用だけではなく、CLI型のClaude Codeや自律型のDevinなどの動向を定点観測しておくのをおすすめします。
付録：コーディングエージェント比較表
本記事執筆のために作成した「コーディングエージェント比較表」のリンクです。記事内で名前を出していない製品を含む完全なリストと比較項目を網羅してあります。
