Skip to Content
Docs08. コーディングエージェントオープンソースのコーディングエージェント
中級coding-agentsmcp更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

オープンソースのコーディングエージェント

この記事の目的

オープンソース(OSS)のコーディングエージェントコードベースを読み、ファイルを編集し、コマンドを実行して検証するループで開発タスクを遂行する Agent。コード補完と異なり「タスク単位の委任」を受けられる。 — Aider / Cline / Continue / OpenHands / Goose / opencode — を俯瞰し、「OSS 系という選択肢」を評価する軸を持てるようになります。個別ツールの詳細な選定よりも、OSS を選ぶ動機・引き受ける責任・商用ツールとの違いの理解が主眼です。

対象読者

前提知識

本文

最終確認日: Cline Desktop と Continue の保守表記・リポジトリ状態は 2026-09-10、その他は 2026-08-18 — 本記事の情報はこの日付時点の各公式サイト・公式リポジトリに基づきます。OSS はプロジェクト体制の変化が特に速いため、参照時は必ず現況を確認してください。

概要

OSS 系コーディングエージェントに共通するアイデンティティは BYOK(Bring Your Own Key: 自分の API キーでモデルに接続)とマルチプロバイダー対応です。ベンダーのサブスクリプションではなく、任意のモデル(ローカルモデル含む)を自分の契約・自分の経路で使えます。これがもたらすのは、①データの経路を自分で決められる(データ主権)②モデルの進化に乗り換えで追従できる ③コードが読める・拡張できる、という自由です。

引き換えに、運用責任(モデル契約・コスト管理・セキュリティ設定・プロジェクト存続性の監視)を自分で負うのが OSS 系の本質的なトレードオフです。

主要ツールの一言サマリー(2026-08、Cline・Continue は 2026-09 部分更新)

ツール形態ライセンス / 主体特徴
AiderCLIApache-2.0 / コミュニティrepo map と Git 自動コミットが特徴の草分け。エージェントが自律実行しない人間主導設計。リリースは約 1 年(12 か月超)停止中(最新 v0.86.0 = 2025-08-09。リポジトリは非アーカイブ)
ClineVS Code 拡張中核(+ JetBrains / CLI / SDK / Desktop)Apache-2.0 / Cline Bot Inc.Plan / Act モード、diff ビュー、都度承認が基本。非常に活発
ContinueIDE 拡張 + CLIApache-2.0 / Continue DevREADME は積極的な保守終了・read-only 方針と最終 2.0.0 を案内。GitHub API の archived / disabled は false(2026-09-10)。新規採用は保守を引き受けられるかで判断
OpenHands(旧 OpenDevin)セルフホスト可能なエージェント実行基盤MIT(オープンコア) / All Hands AIDocker / VM のサンドボックスモデルが生成したコードの実行やコンピュータ操作を、本番システムから隔離された使い捨て環境(ネットワーク・資源制限付き)で行う仕組み。実行が第一級。LLM ベースのリスク評価承認。他社エージェントの実行基盤にもなる
GooseCLI + デスクトップApache-2.0 / Linux Foundation 傘下 AAIF に移管拡張機構が MCPツールやデータソースを LLM アプリケーションに接続するための標準プロトコル。概要は ツール使用、接続の実務は ツール接続標準(MCP とエコシステム) そのもの。コーディング専用でない汎用エージェント。既定モードが Autonomous(全自動)
opencodeターミナル TUI(+ デスクトップ / IDE)MIT / Anomaly(旧 SST)75+ プロバイダー、既存サブスクリプション接続対応、opencode.json でコマンドパターン単位の権限制御。既定はほぼ allow

Cline は 2026-09-09 に desktop-v0.0.24 を公開しています。Desktop も提供面として評価できますが、この release の存在だけでは製品全体の GA を確認できないため、採用する機能の preview・安定性を個別に確認します。Continue は README の保守方針と GitHub のアーカイブ属性が別の情報です。「非アーカイブだから活発に保守されている」とは判断しません。

OSS 系を評価する 4 つの軸

個別機能の比較よりも、次の 4 軸で見ると OSS 系の判断がしやすくなります。

  1. ガバナンスと存続性(最重要) — この 6 ツールだけでも、直近 1 年で「買収されて開発終了(Continue)」「財団へ移管(Goose)」「運営組織の移転(opencode)」「開発停滞(Aider)」の 4 パターンが実際に起きています。OSS を選ぶことは、プロジェクトの健全性を継続監視する責任を負うことです。リリース頻度・ガバナンス形態(企業スポンサー / 財団 / 個人)・収益モデル(オープンコア / ホスティング)を選定時と定期見直しの両方で確認します
  2. 既定の安全度 — 承認モデルの既定値がツール間で正反対です。最も保守的な Aider(人が明示的に実行コマンドを打つ)から、Cline(都度承認が基本)、OpenHands(リスク評価ベースの選択制)、Goose / opencode(既定が全自動・ほぼ許可)まで幅があります。「OSS だから安全」でも「同じ既定」でもありません。導入時に必ず権限設定を確認します(権限とセキュリティ)
  3. コスト構造 — ソフトウェアは無料でも、API 従量課金(使うほど増える)と自己運用の人件費がかかります。商用ツールのシート課金と比べる際は「無料 ≠ 運用コストゼロ」で総額を見積もります(コスト管理)
  4. エコシステム互換性 — MCP 対応は 6 ツール中 5 つ(Aider は記載なし)と事実上の標準です。ルールファイルコーディングエージェントがセッション開始時に読み込む、プロジェクト固有の指示書(AGENTS.md・CLAUDE.md など)。恒常的な規約を毎回の依頼文から分離する。は AGENTS.md 対応(Goose / opencode)と独自形式(.clinerules / CONVENTIONS.md 等)が混在しており、マルチツール環境では互換性が保守コストに直結します(ルールファイルと設定)

サンドボックスと実行環境

ローカル直接実行が基本の中で、OpenHands は Docker / VM / クラウドでの隔離実行を第一級の設計にしている点が特徴です。逆に言えば、他のツールをローカルで使う場合の隔離(コンテナ・権限分離)は利用者側の責任になります。商用ツールが備える組織管理(SSO・ポリシー強制・監査ログ)も、OSS 単体には基本的にないため、チーム導入では自前の統制(設定ファイルのリポジトリ管理・CI での検査)で代替する設計が必要です。

実務での注意点

アンチパターン

  • 「OSS だから安心・無料」で導入を決める — データはモデルプロバイダーに送られ(BYOK 先の規約次第)、運用・監視の責任は自分に来ます。→ データ経路・総コスト・存続性リスクを商用ツールと同じ基準で評価します
  • 既定設定のまま使い始める — Goose / opencode のように既定が全自動のツールがあります。→ 導入初日に承認モード・権限設定(deny リスト)を確認・変更します
  • 存続性を監視しない — 買収・停滞は 1 年以内に実例が複数あります。→ 四半期ごとの依存見直しにエージェント本体も含め、乗り換え先の当たりを常に持っておきます
  • チーム統制なしの野良運用 — 個人ごとにバラバラの設定・モデル契約で使うと、統制もコスト把握もできません。→ 設定ファイル(ルール・権限)をリポジトリで共有し、API キーは組織管理にします

チェックリスト

  • プロジェクトの健全性(直近リリース・ガバナンス・収益モデル)を確認したか
  • 承認モデルの既定値を確認し、チーム標準の設定に変更したか
  • BYOK 先(モデルプロバイダー)のデータ取り扱い・学習利用ポリシーを確認したか
  • API 従量コストの上限・監視を設定したか
  • 設定・ルール・権限ファイルをリポジトリ管理してチームで共有しているか
  • 存続性リスクに備えた代替ツールの候補があるか

関連トピック

参考資料

TODO・未確認事項

  • Aider の MCP 対応有無(公式ドキュメントに記載がないことのみ確認)、OpenHands のローカルモデル対応・ルールファイル現行仕様は未確認です

変わりやすい項目(定点観測)

Devinコーディングエージェントのコスト最適化