目次
の実装にLangChainやLangGraphを選ぶと、Google Cloud向けの配備・評価・観測まで別の手順を作り直す必要がある——Agents CLIの拡張機構は、この分断を減らすための仕組みです。エージェント本体のフレームワークは維持しながら、Cloud Runへの配備や評価結果の形式など、共通化できる工程をAgents CLIへ戻せます。
Googleは2026年10月21日、Agents CLI Extension Systemを使ってLangChainエージェントを作成・実行・評価・配備する手順と、独自の配備ポリシーを追加する例を公開しました。拡張機構自体はAgents CLI 1.5.0で導入され、1.8.0ではファーストパーティのLangChain拡張が提供されています。本記事は公式ブログ、、Google Cloudドキュメントを同年10月25日に確認した導入判断の解説です。本サイトではコマンドを実行しておらず、記載する動作は提供元の資料に基づきます。
スポンサーリンク
変わったのはフレームワークではなくライフサイクルの接続方法
Agents CLIは、コーディングエージェントへエージェント開発の手順とコマンドを提供するツールです。Gemini CLIだけの機能ではなく、Claude Code、Codex、そのほかのコーディングエージェントからも利用できます。プロジェクトの作成、ローカル実行、評価、Cloud RunやAgent Runtimeへの配備、公開、観測を一つのコマンド体系へまとめます。
従来の問題は、この体系の一部がGoogleのAgent Development Kit（ADK）を前提にしていたことです。チームがLangChain、LangGraph、独自フレームワークを使う場合、CLIをフォークする、外側へラッパースクリプトを置く、配備や評価の仕組みを作り直すといった選択が必要でした。Extension Systemは、組み込みコマンドの一部だけを上書きし、新しいコマンドも追加できるため、フレームワーク固有部分と共通部分を分けられます。
| 層 | LangChain拡張での扱い | 判断の要点 |
|---|---|---|
| エージェント本体 | LangChain／LangGraphで実装 | ADKへ書き換える必要はない |
| ローカル実行 | runとplaygroundを上書き | ネイティブコマンドと同じ名前でも実体が変わる |
| 評価データ生成 | eval.generateを上書き | 共通形式へ出力し、採点・比較へ渡す |
| 配備・基盤 | 多くの既存コマンドを再利用 | Cloud RunではADKと共通の配備経路を使う |
| 未対応機能 | 一部コマンドを明示的に拒否 | 対応範囲を確認してから採用する |
LangChainテンプレートはADKへの移植ではない
公式例では、agents-cli createへLangChainテンプレートと1.8.0のタグを指定してプロジェクトを作ります。生成物はlangchain、langgraph、langchain-google-genaiを使い、google-adkには依存しません。エージェントはLangGraphのCompiledStateGraphとして定義され、FastAPIでA2Aトラフィックを受ける構成です。
一方、プロジェクトの外形はADK版と近く、アプリ、テスト、Terraform、マニフェスト、Dockerfile、観測用コードを同じような配置で持ちます。Cloud Runへの配備では、拡張がdeployを上書きせず、既存のgcloud run deploy --source .へつながります。ここから分かるのは、Agents CLIがLangChainをADKへ変換するのではなく、共通の配備契約へ合わせるアダプターを提供していることです。
既存のLangChainプロジェクトへ採用する場合は、生成テンプレートへ全面移行する前に、現在の起動点、依存管理、コンテナ、環境変数、A2A対応、観測基盤を比較してください。エージェントのロジックだけが同じでも、の公開方法やセッション状態、ストリーミング、ツール結果の扱いが変われば、本番挙動は同じになりません。
スポンサーリンク
24前後のコマンドすべてがLangChain対応になるわけではない
Googleの説明では、フレームワークに依存する6つのコマンドが拡張の対象です。playground、run、eval.generateなどはLangChain向け実装へ置き換わります。eval.datasetとeval.optimizeはADKのエージェントオブジェクトを必要とするため、無理に動かさず明示的に拒否します。publish.gemini-enterpriseも配備先によって対応が分かれます。
対して、deploy、infra、install、info、lint、loginなど約18のコマンドはフレームワーク非依存として再利用されます。評価ではLangChain側のeval.generateが標準のEvaluationDataset形式を出し、その後のeval.grade、eval.compare、eval.analyzeを組み込み機能へ戻せます。
この境界は導入判断の中心です。「LangChain対応」という表示だけで必要な工程がすべて動くと考えず、現在使うコマンドを一覧にして、ネイティブ、上書き、拒否の三つへ分類します。評価データの合成や自動最適化が必須なら、現時点のLangChain拡張だけでは満たせません。独自実装を足すのか、別の評価パイプラインを維持するのかを先に決める必要があります。
拡張はGitで配布し、実行内容を固定する
拡張はリポジトリ内のディレクトリとagents-cli-extension.yamlで定義します。GitHubに限らず、セルフホストを含むGitホストやローカルパスから導入できます。インストール時に参照を正確なコミットSHAへ解決し、ロックファイルへ記録します。新しいチェックアウトでも同じSHAから作業コピーを復元し、更新はagents-cli extension updateで明示的に進めます。
プロジェクト単位とユーザー単位のスコープがあり、同じコマンドを定義した場合はプロジェクト側が優先されます。競合は暗黙に結合せず、インストール時や一覧に表示されます。agents-cli infoでは、どの拡張がどのコマンドをどの実行ベクトルへ置き換えたか確認できます。コーディングエージェントが端末を操作する場合も、上書きされたコマンドには警告が出るため、人とAIの両方が実体を追跡できます。
ただし、1.8.0時点でExtension Systemは実験的機能です。マニフェストやコマンド体系には破壊的変更の可能性があるため、Agents CLI本体と拡張の版を固定し、更新時に差分をレビューします。GitのSHA固定は、内容が安全で目的に合うことを保証する仕組みではありません。導入前にマニフェスト、呼び出すスクリプト、必要な資格情報、配備先を確認したうえで固定することが重要です。
スポンサーリンク
独自拡張は組織の共通工程を入れる場所になる
公式ブログは、deployを上書きしてを作成し、重大なが見つかれば配備を止める例を示しています。これはAgents CLIに標準搭載された保証ではなく、組織が独自拡張で追加できるパターンです。SSO、承認、モデルリスク管理、監査記録なども同じ考え方で共通コマンドへ組み込めます。
ラッパースクリプトを別名で用意すると、開発者やコーディングエージェントが元のdeployを直接呼び、組織の工程を迂回する場合があります。拡張で同じコマンドを置き換える利点は、通常の操作を変えずに共通工程へ通せることです。一方、誤った拡張は全チームの配備を止めたり、不適切な引数で本番へ変更を加えたりします。拡張そのものをプロダクトとして版管理し、テスト、レビュー、方法を持たせてください。
導入が向くチームと、急がなくてよいチーム
- 向く：ADKとLangChainが混在し、配備・評価・観測の重複を減らしたい
- 向く：複数チームへ同じ配備前チェックや基盤設定を適用したい
- 検証が必要：評価データ合成や自動最適化など、現在拒否される機能を使う
- 急がなくてよい：ADKへ統一済みで、既存のAgents CLI工程に不足がない
- 急がなくてよい：Google Cloud以外への配備が中心で、共通化できる工程が少ない
試す場合は、Python 3.11以降、uv、Google Cloud SDK、課金を有効にしたプロジェクトが必要です。まず非本番の小さなサービスで、現行のLangChainプロジェクトと生成テンプレートの差分を確認します。次に、ローカル実行、評価データ生成、採点、Cloud Run配備、Cloud Traceの観測を一周させます。成功件数だけでなく、上書きされたコマンド、使えなかった機能、生成物の差分、配備時間、運用担当者が理解できた範囲を記録してください。
評価設計を先に整える場合は、AIの改善を勘で判断しないための評価データと回帰テストも参照できます。Agents CLIの拡張機構が提供するのは評価を運ぶ共通経路であり、自社に合う合格条件そのものではありません。フレームワークを替えても同じ評価データと指標で比較できる状態を作ると、ツール導入の効果を判断しやすくなります。
採用前に確認する6項目
- 既存工程のうち、フレームワーク固有部分と共通化できる部分を分けたか
- 必要なコマンドをネイティブ・上書き・拒否へ分類したか
- プロジェクトの起動点、状態管理、A2A、観測方法の差を検証したか
- Agents CLI本体、拡張、GitコミットSHAを固定したか
- 独自拡張をテストし、更新とロールバックの担当者を決めたか
- 同じ評価データでADK版・LangChain版・現行環境を比較できるか
Agents CLI Extension Systemの価値は、すべてのエージェントを一つのフレームワークへ寄せることではありません。実装の選択を残しながら、配備・評価・観測・組織ポリシーの共通部分を再利用できる点にあります。実験的機能であることと未対応コマンドを受け入れ、版固定と比較評価を続けられるチームなら、有力な選択肢になります。
関連記事
スポンサーリンク
