AIエージェント開発ツールの分類と選び方
この章の目次開く
学習者結局どれを使えばいいの？比較記事を読んでも、書いてあることがバラバラで…
製品比較が成立しにくくなっている
比較記事がかみ合わない理由には、根拠があります。同じ製品が複数の形態を持つようになったからです。
かつては「ターミナルで動くもの」「エディタに組み込むもの」「クラウドで動くもの」がだいたい別製品でした。いまは1つの製品が全部を持っています。Claude Codeの公式ドキュメントも、エージェントループとツールはどこで使っても同じで、変わるのはコードが実行される場所と、こちらが操作する面だけだと明記しています。
「どの製品を使うか」より「どのマスで作業するか」のほうが、実務上の意味を持ちます。分けるべき2つの軸
そこで、製品ではなく軸で整理します。
軸1：どこでコードが実行されるか
| 実行場所 | 性質 |
|---|---|
| ローカル | 自分のマシン。ファイルにも環境にも完全にアクセスできる |
| クラウド | 提供者が管理する仮想マシン、または自社でホストする環境 |
| リモート操作 | 実行はローカル、操作だけを別の画面から行う |
軸2：どこから操作するか
ターミナル、デスクトップアプリ、IDEの拡張、Webブラウザ、チャットツール、CI/CDパイプライン。
この2軸で考えると、選択が具体的になります。「席を外して進めたい」なら実行場所はクラウド、「画面を見ながら詰めたい」ならローカル、「外出先から様子を見たい」なら操作面はモバイル。実行環境の章で扱った4つの判断軸が、そのままここに効きます。
評価すべき7項目
製品を評価するときに見るべき項目です。これが本章の本体で、次に選び直すときも同じリストが使えます。
| 項目 | なぜ見るか | 本書の該当章 |
|---|---|---|
| 指示ファイルの規約 | 共通規約に対応していれば、ナレッジを持ち出せる | 11章 |
| 権限モデルの粒度 | 禁止が許可より優先されるか、モードで段階を切れるか | 5章 |
| サンドボックス | OSレベルの隔離があるか。判断が乗っ取られても効く層 | 5章 |
| 拡張点 | フックで決定的な処理を挟めるか。ツールを追加できるか | 13章・14章 |
| 組織向けの管理設定 | 個人設定で上書きできない層があるか | 10章 |
| 課金モデル | 従量か定額か。使用量を可視化できるか | 17章 |
| 資産の持ち出しやすさ | やめるときに何が残るか | 後述 |
ロックインを決めるのは指示ファイル
7項目の最後、資産の持ち出しやすさについて補足します。
エージェントを使い込むほど、蓄積するものがあります。プロジェクト固有の前提、禁止事項、手順の型、うまくいった指示の書き方。これが乗り換えコストの正体です。モデルやツールは差し替えられますが、蓄積したナレッジは差し替えられません。
ここで効くのが、11章で扱った薄いアダプタの考え方です。ナレッジ本体をツール非依存の場所に置き、ツール固有のファイルは参照するだけにしておく。この形にしておけば、乗り換えは「数行の参照ファイルを1つ足す」だけで済みます。
先生ツールを選ぶときに「乗り換えやすいか」を見るのは後ろ向きに聞こえるけど、この分野では最も前向きな判断だよ。半年後に良いものが出たとき、すぐ試せるからね。
共通規約という追い風
幸い、状況は良い方向に動いています。指示ファイルとツール接続の両方で、共通規約が広がっています。
指示ファイルについては、AGENTS.md という規約に多数のツールが対応しています。2026年8月時点で agents.md に掲載されている対応ツールは次のとおりです。
Codex（OpenAI）／Jules（Google）／Factory／Aider／goose／opencode／Zed／Warp／VS Code／Devin（Cognition）／Autopilot & Coded Agents（UiPath）／Junie（JetBrains）／Amp／Cursor／RooCode／Gemini CLI（Google）／Kilo Code／Phoenix／Semgrep／Coding agent（GitHub Copilot）／Ona／Windsurf（Cognition）／Augment Code
同サイトによれば、6万を超えるオープンソースプロジェクトで使われています。
ツール接続については、13章で扱ったMCPが同じ役割を果たしています。1つ作れば、対応する複数のクライアントで使えます。
分類の目安
そのうえで、大まかな類型を挙げておきます。ただし前述のとおり製品はこれらをまたぎます。
| 類型 | 性質 | 向く作業 |
|---|---|---|
| ターミナル中心 | 実行ループが主役。シェルの全機能が使える | 大きなリファクタ、調査、自動化 |
| エディタ統合 | 人がファイル単位で運転する比重が大きい | UI調整、細部の詰め、既存コードの理解 |
| クラウド非同期 | 仮想マシンで走り、PRを開いて終わる | 席を外して進めたい定義済みの作業 |
| CI・レビュー統合 | PRやCIのイベントを起点に動く | 指摘の自動修正、定型的な検査 |
併用は前提でよい
最後に、実務的な現実を1つ。規模が大きい組織ほど、複数のツールが併用されます。部署によって事情が違い、好みも違い、統一しようとしても抜け道ができます。
18章で書いたとおり、握るべきは境界であって道具ではありません。禁止ルールと権限の下限を組織側で押さえ、ナレッジをツール非依存の場所に置く。この2つができていれば、併用は問題になりません。
よくあるハマりどころ
比較記事のランキングで決める。 評価基準が書かれていない順位は、自分の状況に対しては情報量がほぼありません。上の7項目で自分の要件を先に決めます。
性能だけで選ぶ。 モデルの性能は変わり続けます。変わりにくいのは権限モデルや拡張点の設計です。
乗り換えコストを見ない。 使い込むほど蓄積が増え、あとから動けなくなります。
統一にこだわる。 統一より、資産がツールに縛られないことのほうが重要です。
この章の一覧をそのまま信じる。 2026年8月時点のものです。必ず各製品のドキュメントで現状を確認してください。
ちゃんと使うためのポイント
- 製品はカテゴリをまたぐ。分けるべきは実行場所と操作面の2軸
- 評価は7項目（指示ファイル規約・権限モデル・サンドボックス・拡張点・管理設定・課金・持ち出しやすさ）
- ロックインの正体は蓄積したナレッジ。薄いアダプタで逃がしておく
- 共通規約（指示ファイル・MCP）に対応しているかは、持ち出しやすさの目安になる
- 併用は前提でよい。握るのは境界であって道具ではない
- ランキングではなく、自分の要件を先に決めてから照合する
最後の章では、ここまでの内容を実務で使える形に圧縮します。指示の型、設定ファイルの早見表、始めるときのチェックリストです。
参考リンク
- AGENTS.md — 共通規約と対応ツールの一覧。この章の一覧はここから取っている
- How Claude Code works（公式） — 実行環境と操作面の分離についての記述
- What is the Model Context Protocol?（公式） — ツール接続側の共通規約