Googleが’google/agents-cli’を出しました。名前だけを見ると、新しいAIエージェント開発ツールに見えます。ただ、私は少し違う見方をしています。これはCodexやClaude Codeの代わりではありません。そうしたコーディングエージェントが、Google Cloud上でADKエージェントを作り、評価し、配備するときに迷わないようにする手順の束です。
今はエージェントのデモを作るだけなら、それほど難しくありません。難しいのはその後です。どの文書を読ませてよいのか。間違った回答をどう拾うのか。誰が承認するのか。配備後のログはどこで見るのか。問題が起きたら誰が止めるのか。ここが曖昧なままなら、エージェントは便利な仕組みではなく、新しい運用リスクになります。
このテーマを取り上げた理由
私は最近、「AIエージェントを作る」という言葉だけでは判断しなくなりました。最初の版はすぐ出ます。本当に困るのは二週目です。昨日と違う答えをした理由、参照した資料、修正担当者を聞かれたときです。
その意味で’agents-cli’は気になります。公式GitHubのFAQは、これがCodex、Claude Code、Antigravity CLIの代替ではないと明記しています。コーディングエージェントがADKエージェントを作成、評価、配備するためのコマンドとスキルを持たせる道具です。
派手さはありません。ただ、実務ではこちらのほうが重要です。エージェントそのものより、エージェントを囲む手順が見えるかどうかが効いてきます。
実際に見た仕事
私は最初から顧客向けのサポートボットには入れません。まず社内のtriage agentを想定します。たとえば取引先からの問い合わせやポリシー例外の相談が来たとき、次の情報を受け取る小さなエージェントです。
- 入ってきた依頼
- 現行のポリシー文書
- 顧客またはプロジェクトの状態メモ
- 出力すべき形式
やることも狭くします。回答案を作り、根拠となる段落を示し、人の確認が必要かを付け、次の担当者を出す。これくらいなら実務に近く、失敗も見つけやすいです。
実際に見比べた点
私は’agents-cli’を万能の作成ツールではなく、lifecycle wrapperとして読みました。
| 段階 | 期待すること | まだ信用しないこと |
|---|---|---|
| Setup | Python 3.11以上、‘uv’、Node.js、スキル導入が再現できる | 誰かが記憶でコマンドを打つ |
| Scaffold | agent code、test、eval、deployの場所が分かれる | 生成ファイルが増えるだけで誰も見ない |
| ADK code | tool、callback、state、agent behaviorが見える | 長いpromptだけで境界がない |
| Evaluation | test case、grading、version compare、failure analysisがある | 一つの例に答えたから十分とする |
| Deployment | Agent Runtime、Cloud Run、GKEへの道筋が見える | 権限と費用の責任者がいないcloud deploy |
| Observability | 失敗を説明するlogやtraceが残る | 初日以降、誰も見ないproduction agent |
公式の導入例は’uvx google-agents-cli setup’です。スキルだけを入れる場合は’npx skills add google/agents-cli’も示されています。入口は軽いです。ただ、入口が軽い道具ほど、運用の線引きを先に見ておくべきです。
私が置いたチェック項目
最初のpilotの横に三つ置きます。
一つ目は失敗例のファイルです。曖昧な依頼、古いポリシー、根拠が足りない依頼をあえて入れます。きれいな例だけ通ることには、あまり価値がありません。
二つ目は確認する人です。出力を人が承認するなら、その人が何を見て通すのかを先に決めます。
三つ目は止め方です。配備後に動きが変わったとき、会議を開く前に止める経路が必要です。
運用で止まる部分
止まるのはCLIコマンドではありません。たいてい「信用してよいか」で止まります。
生成されたエージェントは見た目が整っていても、こう崩れます。
- ポリシー段落は合っているが、版の日付を見落とす
- 例外相談を違う担当者へ回す
- 社内確認用の案件を顧客向けの文章にしてしまう
- 簡単なeval setは通るが、実際の依頼で揺れる
- 配備はできたが、二日目からlogを見る人がいない
だから私はscaffoldよりevalを見ます。公式文書にはeval生成、grading、version compare、failure analysis、metric list、prompt optimizeの流れがあります。ここを飛ばすなら、CLIはきれいな初稿を作るだけです。
もう一度選ぶなら
この道具を試す条件は三つです。
チームがGoogle Cloudに慣れていること。エージェントがADK、Agent Runtime、Cloud Run、GKE、Gemini Enterpriseの近くに置かれる可能性があること。そして配備後もevaluation caseを直す人がいることです。
逆に、ローカル自動化一つ、単発スクリプト一つ、単純なチャットボット一つなら、ここまでの道具立ては重すぎるかもしれません。道具が仕事より大きくなると、自動化ではなく運用負担になります。
最初は狭くてよいです。社内triage agent一つ、source set一つ、output format一つ、deployment target一つ、そして少し意地悪なeval caseを10から50件。私はこのくらいが最初の線だと思います。
ルーティングに入れる場合と避けます
本番運用に近づけるなら、まず人が最後に確認する内部triageやポリシー確認に限ります。顧客への最終送信、記録変更、例外承認まで任せる使い方は避けます。
私が先に見るのは、コマンドが通るかではなく、失敗したときに止める場所が見えるかです。そこが曖昧なら、良いCLIでも現場では負担になります。
使う前に確認すること
- Windows環境の扱いを確認する。現行ドキュメントはnative WindowsではなくWSL 2を案内しています。
- ローカルのAI Studio開発で足りるのか、Google Cloud配備まで必要なのかを分ける。
- scaffoldを信じる前にeval caseを書く。
- 失敗した依頼を一つはrepoに残す。
- 確認者、cloud project owner、費用責任者を名前で決める。
- logの場所が見えないうちは、実行権限や配備権限を広げない。
- LLM-as-judgeはふるい分けであって、敏感な判断の最終決定者にはしない。
確認した資料
2026年7月6日時点で、公式GitHub repo、getting started、CLI reference、evaluation guide、deployment guide、Google Cloud quickstart、Google Developers Blog、PyPI package pageを確認しました。変化の早い道具なので、ADK、Agent Platform、agents-cliを混ぜて語る二次情報より公式資料を優先しました。
短い結論
ADKエージェントをGoogle Cloudへ載せる可能性があるなら、‘agents-cli’は試す価値があります。ローカルで小さな作業を一つ自動化したいだけなら、重すぎるかもしれません。
pilot cardに書くなら、こうです。
‘agents-cli’は、エージェントのlifecycleを見える形にするための道具です。lifecycleを考えなくてよくする道具ではありません。
CLIはコーディングエージェントに正しい手順を思い出させることができます。ただし、そのエージェントを作るべきか、eval setが正直か、組織が運用できるかは人が決めます。
二時間のpilotなら
本番権限なしで二時間だけ渡します。
一時間目はスキル導入、狭いagent scaffold、design spec作成です。仕事は地味なほうがいいです。社内triage agentは期待出力がはっきりしています。根拠段落、確認フラグ、担当者、次の行動。この四つが外れればすぐ分かります。
二時間目はeval set作成とgradingです。普通の依頼、根拠不足の依頼、古いポリシーの依頼、拒否すべき依頼を混ぜます。その後でpromptかpolicyを一つだけ変え、最初の版と比べます。
二時間目で使える失敗メモが出ないなら、配備はしません。厳しく見えますが、実務に入ってから失敗パターンを知るより安く済みます。
rollout noteに残す質問
| 質問 | 広げる前の答え |
|---|---|
| エージェントが読んでよい資料は何か | 指定したポリシー文書とsource bundleだけ |
| やってはいけないことは何か | 最終回答の送信、記録変更、例外承認 |
| 改善したと言える証拠は何か | 修正回数を増やさず確認時間が減ること |
| pilotを止める条件は何か | 根拠の捏造、担当者の誤配、log不足 |
| 次版の責任者は誰か | 「AIチーム」ではなく名前のあるeditorまたはplatform owner |
このメモがあって初めて、道具が実務に乗ります。なければ’agents-cli’は、組織が運用できる速さより速くソフトウェアを作る別の手段になるだけです。
FAQ
Google Agents CLIはCodexやClaude Codeの代わりですか
違います。公式FAQは、これはcoding agentそのものではなく、coding agentのための道具だと説明しています。ADKエージェント作業を助けるskillとcommand layerと見るのが自然です。
Google Cloudなしで使えますか
ローカル開発はできます。ドキュメントではAI Studio API keyを使ったローカル開発が示されています。ただし配備やcloud機能にはGoogle Cloudが必要です。
production agentは自動で安全になりますか
なりません。構造、評価、配備、logには役立ちますが、eval set、権限、source policy、review boundaryはチーム側の責任です。
どこから始めるべきですか
顧客に直接出ない社内triage agentから始めるのが安全です。小さくても厳しめのeval setを通れないなら、権限を広げないほうがいいです。
業務フロー
このガイドがつながる業務フロー
読んでいるガイドが、どの業務フローに関係するのかを確認できます。
自動化プラットフォーム、アプリビルダー、エージェントビルダー、会計ツール、汎用AIアシスタントを比較するルートです。
関連トピックを見る- 向いている場合
- 単体ツール購入、社内ワークフロー構築、広いプラットフォーム導入で迷うチーム
- 向かない場合
- 判断基準よりも手順書が先に必要な場合は、実装型の記事の方が向いています。
参照した公開情報
報道内容、公式文書、政策背景、製品情報、変わる可能性のある主張を確認するために参照した公開情報です。
- google/agents-cli GitHub repository Google
- Agents CLI getting started Google
- Agents CLI reference Google
- Agents CLI evaluation guide Google
- Agents CLI deployment guide Google
- Build an agent with ADK and Agents CLI in Agent Platform Google Cloud
- Agents CLI in Agent Platform: create to production in one CLI Google Developers Blog
- google-agents-cli on PyPI PyPI
