オープンソースのコーディングエージェント3選、本番利用の判断軸

この記事のまとめ

オープンソースのコーディングエージェントは、ターミナルで動くものを中心に選択肢が広がっています。この記事では、OpenCode、Gemini CLI、Kimi Code CLIの3つを公式情報の範囲で整理します。あわせて、本番で使えるかを判断するための3つの観点をまとめます。

OpenCodeはターミナル・デスクトップ・IDE拡張で使え、変更させずに方針だけ出すPlanモードや、変更を取り消す/undoコマンドがあります。
Gemini CLIはApache 2.0ライセンスで、ReActループと組み込みツール、Model Context Protocol（MCP）サーバーを使います。Kimi Code CLIはMITライセンスで、サブエージェントやライフサイクルフック、Agent Client Protocol（ACP）連携を備えます。
本番投入の前には、私有データ・外部コンテンツ・外部行動という3つの権限の棚卸しが推奨されています。
フォークの前に、プラグインやMCP、フックで足りるかを確かめる考え方が取れます。

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

OpenCodeの特徴と使い方

OpenCodeは、複数の使い方を選べるオープンソースのコーディングエージェントです。私が注目したのは、単にターミナルで動くだけでなく、「方針を出すだけ」と「実際に変更する」を切り替えられる設計にあります。

OpenCodeは、オープンソースのAIコーディングエージェントです。ターミナル上のインターフェース、デスクトップアプリ、IDE拡張という形で使えます（参照*1）。

作業の進め方を選べる点も特徴です。OpenCodeにはPlanモードがあり、このモードではコードを変更する機能が無効です。代わりに、機能をどう実装するかの案を提示します。

Tabキーで切り替えられます。また、出てきた変更が意図と違ったときは、/undoコマンドで取り消せます（参照*1）。

名前が同じリポジトリが複数ある点は、調べるときに引っかかりやすいポイントです。GitHubのopencode-ai/opencodeリポジトリはすでに保守されておらず、記録のためにアーカイブされています。

プロジェクトは、元の作者とCharmチームによってCrushという名前で続いています（参照*2）。実際に使おうとするとき、GitHubで検索してアーカイブ済みのリポジトリに辿り着いてしまうケースがあるため、現行情報はopencode.aiのドキュメントで確認するのが確実です。

Gemini CLIの特徴と使い方

Gemini CLIは、ターミナルからGeminiを使うオープンソースのエージェントです。

Gemini CLIは、Geminiの機能をそのままターミナルに持ち込むオープンソースのAIエージェントです。Geminiへ軽量にアクセスでき、入力したプロンプトからモデルまでの道のりが短くなります。ライセンスはApache 2.0です（参照*3）。

動き方は、考えることと動くことを交互に繰り返す形です。Gemini CLIは、reason and act（ReAct）ループを使い、組み込みツールとローカルまたはリモートのMCPサーバーを組み合わせます。私がAIエージェントの業務利用を検証する中で感じるのは、このReActの「観察して次を決める」という構造が、単発の命令実行と本質的に異なるという点です。

これにより、バグ修正、新機能の作成、テストカバレッジの改善といった複雑な用途に対応します。Gemini Code Assistの個人向け、Standard、EnterpriseはそれぞれGemini CLI用のクォータを提供し、そのクォータはGemini Code Assistのエージェントモードと共有されます（参照*4）。

試しやすさに関わる条件もあります。個人のGoogleアカウントを使う場合の無料枠は、1分あたり60リクエスト、1日あたり1,000リクエストです（参照*3）。

Kimi Code CLIの特徴と使い方

Kimi Code CLIは、ターミナルで動き、作業を分担させる仕組みを持つエージェントです。サブエージェント、ライフサイクルフック、ACP連携という3つの拡張ポイントが整理されているのが特徴で、運用フローに組み込みやすい設計だと感じます。

Kimi Code CLIは、ターミナルで動くAIコーディングエージェントです。コードの読み書き、シェルコマンドの実行、ファイル検索、Webページの取得ができ、返ってきた結果をもとに次の一手を選ぶ仕組みです。Moonshot AIのKimiモデルでそのまま動き、他の互換プロバイダを使う設定もできます（参照*5）。

拡張の入り口は3つあります。

1つ目はサブエージェントで、coder、explore、planという組み込みのサブエージェントを切り離した文脈で動かし、本体の会話を散らかさずに並行作業を進められます。
2つ目はライフサイクルフックで、要所でローカルのコマンドを実行し、危険なツール呼び出しの抑止、判断の記録、通知、自前の自動化との接続に使えます。
3つ目はACPによるエディタ連携で、kimi acpを使えばZedやJetBrains、その他のAgent Client Protocol対応クライアントからセッションを操作できます。

（参照*5）。

名前の変化も押さえておきたい点です。Kimi CLIは、同じチームによる次世代のターミナルAIエージェントであるKimi Code CLIへ移行中です。

Kimi Code CLIを入れると設定とセッションが自動で引き継がれます。Kimi CLI側は段階的に終息予定で、ドキュメントと既存のインストールは引き続き利用できます（参照*6）。

共通する仕組みと設計の違い

エージェントの基本動作とMCP・ACP

ターミナル型のエージェントは、読む・直す・実行する・結果から次を決める、という流れで動きます。この構造は、AIを「一発で答えを出す道具」として使うのではなく、「試行と観察を繰り返す工程に組み込む」という発想の転換を求めます。

この流れは、各ツールの説明からも読み取れます。Kimi Code CLIは、コードの読み書き、シェルコマンドの実行、ファイル検索、Webページ取得を行い、受け取ったフィードバックをもとに次のステップを選びます（参照*5）。

Gemini CLIは、ReActループと組み込みツール、ローカルまたはリモートのMCPサーバーを使って作業を進めます（参照*4）。

外の道具やエディタとつなぐ規格も共通しています。MCPは、AIアシスタントが外部のサービスやツールとやり取りするための標準的な方法で、OpenCodeはこれを実装して外部ツールで機能を広げます（参照*2）。

もう一つがACPです。Kimi CLIはACPを標準でサポートし、ACP対応のエディタやIDEと組み合わせて使えます（参照*6）。

スキャフォールド設計の多様性

同じオープンソースでも、エージェントの中身の作りは大きく分かれます。

この点は、ソースコードの中身を調べた研究が示しています。ある論文は、コミットハッシュを固定した13のオープンソース・コーディングエージェントのスキャフォールドを分析し、ソースコード水準の設計分類を示しました。各エージェントは、制御アーキテクチャ、ツールと環境のインターフェース、リソース管理という3層に整理した12の観点で特徴づけられています。

分析によると、スキャフォールドの設計はきれいに分類しきれません。制御戦略は決め打ちのパイプラインからモンテカルロ木探索まで幅があり、ツール数は0から37まで、コンテキストの圧縮方法は7種類に分かれます（参照*7）。

ループの作り方にも重なりがあります。同じ論文は、ReAct、生成とテストと修復、計画と実行、複数回のリトライ、木探索という5つのループ要素を、組み合わせられる部品として位置づけました。13のエージェントのうち11が、単一の制御構造に頼らず複数の要素を重ねています（参照*7）。

この分析は特定時点のコミットに固定した13件が対象で、この記事で紹介した3つのツールを直接評価したものではありません。ただ、オープンソースであれば、こうした中身を自分で読んで見比べられるという点が、クローズドなツールとの本質的な違いです。

本番利用の判断軸

権限とセキュリティのリスク

本番で使うかを考えるとき、まず見るのは権限の持ち方とその危うさです。生成AI導入支援の現場で実感するのは、セキュリティの議論がモデル選定よりも後回しになりやすいという点です。コーディングエージェントは特に、権限の範囲が広いため、この順番は逆にすべきだと考えています。

Cloud Security Allianceの研究ノートは、独立した評価の結果を紹介しています。商用および一般に入手できる本番AIエージェント100件を対象にした評価（AI Risk Quadrant Q2 2026）では、基準となるセキュリティのベンチマークに合格したのは11パーセントだけでした。残る89パーセントは、大きな被害を起こせるだけの能力を持ちながら、それを防ぐ備えが足りない状態に置かれています（参照*8）。

危うさの中身は、3つの条件が同時に成り立つ構造にあります。同研究ノートは、私有データへのアクセス、信頼できない外部コンテンツへの接触、外部への行動の実行が同時にそろう状態を「Lethal Trifecta」と呼び、評価対象の98パーセントに存在するとしました。埋め合わせとなる制御がない本番環境では、悪意のある文書やメール、Webページが1つあるだけで、許可していない動作の引き金になりうると述べています（参照*8）。

コーディングエージェントの位置づけも示されています。同研究ノートによると、本番エージェントの中でも能力が高く広く使われている分類であるコーディングエージェントは、能力のスコアで2位、防御では8位でした。

この種のエージェントは、コードリポジトリ、クラウドのビルドパイプライン、パッケージレジストリ、デプロイの仕組みへの書き込み権限を持つのが普通だと整理されています（参照*8）。この結果は100件の評価対象についてのもので、この記事で取り上げた3ツールの評価ではありません。

確認できる制御と運用体制

制御は一枚岩ではなく、層に分けて確かめる考え方が示されています。

ある論文は、安全のための制御を5つの層に整理しました。

第1層はプロンプト水準のガードレールで、セキュリティ方針、動作の安全性、編集前に読むこと、gitの進め方、エラーからの復旧を扱います。
第2層はスキーマ水準のツール制限で、プランモードのホワイトリスト、サブエージェントごとのallowed_tools、MCPの発見の制限が含まれます。
第3層は実行時の承認で、手動・半自動・自動という段階と、パターンやコマンド、接頭辞、危険度のルール、保存される権限があります。
第4層はツール側の検証で、DANGEROUS_PATTERNSのブロックリスト、古い読み取りの検知、出力の切り詰め、タイムアウトが挙げられています。
第5層はライフサイクルフックで、ツール実行前のブロック（終了コード2）、引数の書き換え、JSON標準入力のプロトコルが並びます。

（参照*9）。

これは論文が示した整理であり、この5層を備えれば安全が保証されるという内容ではありません。重要なのは、層ごとに何が制御されていて、何が制御されていないかを自組織で把握することです。

導入前の確認手順も提案されています。Cloud Security Allianceの研究ノートは、新しい本番エージェントを承認する前に、セキュリティチームが明示的なトライフェクタ監査を行うべきだとしました。具体的な手順は3つあります。

そのエージェントが私有データにアクセスするかを文書化します。
処理する信頼できないコンテンツの供給元をすべて洗い出します。
実行できる外部行動をすべて列挙します。

同ノートは、ベンダーの防御に関する主張を額面どおり受け取らず、組織の側で積極的に検証することも求めています（参照*8）。私が生成AI導入を支援する中で繰り返し見てきたのも、この点です。ベンダーのセキュリティ説明を信じて進め、後から権限の範囲に気づくというパターンは、珍しくありません。

フォークとカスタマイズの価値

ライセンスと拡張ポイント

自社向けに手を入れる前に、ライセンスと、改変せずに広げられる仕組みを確認しておくことをすすめます。フォークは自由度が高い反面、上流の変更を取り込み続けるコストが発生します。プラグインやMCP、フックで届く範囲かどうかを先に見極めるのが、現実的な判断の順番です。

このソフトウェアを入手した人には、使用、複製、改変、結合、公開、配布、サブライセンス、販売を制限なく扱う権利が無償で許諾されます。ただし、ライセンス文に記された条件に従うことが前提です（参照*10）。

Gemini CLIは、Apache 2.0ライセンスのオープンソースです（参照*3）。

本体を書き換えずに機能を足す道もあります。Cloudflareのドキュメントは、OpenCodeのプラグインがエージェントにツールを提供する仕組みだと説明し、402応答を扱うx402-fetchツールを作る例として、.opencode/plugins/x402-payment.tsを作成する手順を示しています（参照*11）。

Kimi Code CLIでは、ライフサイクルフックで要所にローカルのコマンドを挟み、危険なツール呼び出しの抑止や判断の記録ができます（参照*5）。プラグインやMCP、フックで届く範囲かどうかが、フォークを検討するかどうかの分かれ目になります。まずここで試して、それでも足りなければ本体に手を入れるという順番が妥当だと思います。

現場の採用状況から見る投資判断

どのくらい使われているかは、GitHub上の実データから手がかりが得られます。

ある論文は、人気のあるGitHubリポジトリ2,361件から集めた25,264件のエージェント生成プルリクエストを分析しました。調べたのは、エージェント型コーディングツールの採用、プロジェクト単位での生産性、人とエージェントの協働パターンの3点です。結果として、中央値のリポジトリは3か月の期間で1件から2件のエージェントPRしか生み出しておらず、集中的な採用は一部のプロジェクトにとどまっています（参照*12）。

監督のかたちにも偏りがありました。同じ分析では、人とエージェントの協働は一人の開発者が監督するモデルが大半で、その開発者がエージェントの貢献をレビューしたり手直ししたりしています。

複数人で協働するパターンはあまり見られませんでした（参照*12）。これは対象期間のスナップショットから言える範囲の結果ですが、「一人の開発者が監督する」という実態は、現時点のエージェント利用が「個人の作業効率化」に留まっていることを示唆しています。チームの開発プロセスに組み込む段階は、まだ途上だと見ています。

評価とテストでの位置づけ

既製のエージェントは、研究の比較対象としても使われています。

テスト生成の研究では、Gemini CLIが基準側に置かれました。ある論文は、20個のアプリケーションと1,464件のテストシナリオを対象に、提案手法のSakuraを評価しています。

複数のLLMで動かしたGemini CLIのような既製のエージェント型ツールと比べ、同じモデルを使ったベースラインに対して、テストのコンパイル可能性で50から78パーセント、正解テストと生成テストのカバレッジの重なりで38から66パーセント上回ったと報告しました（参照*13）。これはこの研究の条件下での結果です。

対象の難しさで成績が変わる例もあります。別の論文は、7つのLLMと4つのエージェントフレームワークを評価し、最も良いエージェントが全体の70.7パーセントのタスクを解決したと示しました。

小規模なコアでは90パーセントを超えた一方、複雑なSoC水準のプロジェクトでは65パーセントを下回っています（参照*14）。自社の課題に近い題材で確かめる意味は、この差から読み取れます。ベンチマークの数字ではなく、自分たちの実際の業務に近いタスクで手元で試すことが、投資判断の前提になります。

おわりに

オープンソースのコーディングエージェントは、OpenCode、Gemini CLI、Kimi Code CLIのように、使い方も拡張の仕組みも公開された形で選べるようになっています。中身の設計はプロジェクトごとに大きく異なり、ソースコードを読んで見比べられることが、オープンソースならではの材料です。私自身、ツールを導入する前にソースコードと拡張ポイントを確認することを習慣にしており、フォークが必要かどうかもその段階で判断できます。

一方で、コーディングエージェントは能力の評価が高い分類でありながら、防御の評価では下位でした。導入を決める前に、私有データ、外部コンテンツ、外部行動という権限の持ち方を洗い出し、層ごとの制御と監督のかたちまで含めて確かめることが、公開された調査からは繰り返し求められています。便利さと危うさが同居しているのがコーディングエージェントの現在地です。使わない理由にはなりませんが、使う前に権限の棚卸しを済ませる手間を省く理由にもなりません。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））