G-gen の武井です。当記事は Google Cloud Next '26 in Las Vegas のブレイクアウトセッション「One tool to rule them all: Extending and customizing the Gemini CLI」について、速報レポートをお届けします。
G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。
- セッションの概要
- AI 開発ツールが抱える 3 つの課題
- Gemini CLI と拡張ポイント
- John のジャーニーで見る Gemini CLI 拡張デモ
- Extensions Gallery によるコミュニティ連携
セッションの概要
本セッションでは、ターミナル上で動作する AI エージェント Gemini CLI を、開発者個人のワークフローに合わせてカスタマイズし、さらにそのカスタマイズをチームやコミュニティへ共有するための拡張ポイント（Agent Skills、Sub-agents、Hooks、Extensions）について解説していました。
登壇者は Google Cloud の Aishanee Shah 氏と Abhi Patel 氏の2名です。座学だけでなく、John という架空の開発者が Gemini CLI のコードベースをキャッチアップし、得られた知見を共有可能なパッケージにまでまとめ上げるジャーニーを題材に、ライブデモを交えて段階的に紹介する構成です。
Gemini CLI の詳細な解説については、以下の記事を参照してください。
AI 開発ツールが抱える 3 つの課題
近年の AI モデルはコーディング、コードベース探索、リサーチに非常に強くなった一方、その周辺ツール（Web 上の AI チャット、IDE、CLI ツールなど）が急増した結果、開発者がそれらの間を伝書鳩（messenger pigeons）のようにつないでいる現状が指摘されました。
Abhi 氏自身、Chrome チームに在籍していた頃、エラーやスタックトレースを Web の Gemini チャットへコピー＆ペーストし、結果をまた IDE に戻す、という非効率な作業に多くの時間を費やしていたとのことです。
セッションでは、こうした現状から派生する課題が 3 つに整理されていました。
1つ目はテクノロジーの孤島（tech islands）です。Web アプリ、IDE、CLI ツールが乱立しているなかで、それらをいかに効果的に組み合わせるかという問題を指します。
2つ目は認知的過負荷（cognitive overload）です。プロンプトの構造設計や適切なコンテキストの収集を、ユーザー側が常に意識しながら組み立てる必要があるという課題です。
3つ目は車輪の再発明（reinventing the wheel）です。完璧なプロンプトやワークフローを構築できたとしても、それをチームや組織全体で共有・再利用する手段がなければ、各々が同じ努力を繰り返すことになります。
これらの課題を解決する鍵として、複数のツールとコンテキストを束ねるオーケストレーターが必要であり、その役割を担うのが Gemini CLI である、というのがセッションの出発点として提示されました。
Gemini CLI と拡張ポイント
Gemini CLI とは
Gemini CLI は、ターミナル上で動作するオープンソースの AI エージェントです。最先端の Gemini モデルへの軽量かつ直接的なアクセスを提供し、開発者が指定したゴールに向けてコンテキストを収集・維持しながらタスクを実行します。詳細は以下を参照してください。
拡張ポイントの全体像
セッションでは、Gemini CLI を自分のワークフローに合わせて深くカスタマイズする手段として、以下 4 つの拡張ポイントが紹介されました。
- Agent Skills（エージェントスキル） : 専門知識・手続きワークフロー・関連リソースをひとまとめにしたモジュール
- Sub-agents（サブエージェント） : 特定タスクに特化した独立エージェント。コンテキストとツール選択をメインエージェントから分離する
- Hooks（フック） : エージェントのライフサイクル上の任意のタイミングに介入するための設定可能なポイント
- Extensions（エクステンション） : Skills、Sub-agents、Hooks、コマンド、MCP サーバー、コンテキストファイルなどを 1 つの共有可能なパッケージにまとめる仕組み
Aishanee 氏は「2026 年の開発者は、こうしたカスタマイズの作り込みとメタワークフローの構築に多くの時間を使っている」と述べ、AI 時代の開発者の作業の重心が、自らコードを書くことから、エージェントツール群の設計・編成へとシフトしていることを強調していました。
John のジャーニーで見る Gemini CLI 拡張デモ
1. 組み込みツールによるコードベースの探索
John はまず、Gemini CLI のリポジトリをクローンしたうえで、ターミナルから Gemini CLI を起動し、自然言語で「サブエージェントの委譲（sub-agent delegation）がどう動くのか理解したい」と尋ねます。
ここで Gemini CLI は思考モード（thinking mode）に入り、組み込みツールを使って必要なファイルを段階的に読み込みます。1つ目のファイルを読んで把握、必要な情報を絞り込んで次のファイルを読む、という形で探索を進め、最終的に Markdown 形式の要約を返しました。
John は視覚的に理解したいタイプなので、続けて「フローチャートに変換して」と依頼します。すでに直前の探索で十分なコンテキストを集めているため、追加のファイル読み込みなしに、ターミナル内に ASCII アートのフローチャートが描画されました。
ここまでが、組み込みツールだけで実現できる「単発の探索」です。一度きりのコードリーディングや、ざっと全体像をつかみたい場面には十分強力ですが、生成された図をチームメイトと共有したい・設計ドキュメントに貼り付けたい、といった次の段階には不向きです。
2. Agent Skills で専門知識をパッケージ化する
そこで登場するのが Agent Skills（エージェントスキル）です。Agent Skills は、専門知識・ワークフロー・スクリプトをまとめたモジュール式の自己完結パッケージで、エージェント向けの作業手順書のような位置づけのものです。Agent Skills の構造は単純で、以下のようなディレクトリで成り立ちます。
- skill.md : 必須ファイル。YAML フロントマターでスキルの
nameとdescriptionを定義し、Markdown 本文にエージェントへの指示を記述する - references/ : 補助的な参考資料を置く任意ディレクトリ
- scripts/ : 検証や変換などに使うスクリプトを置く任意ディレクトリ
特に重要なのは skill.md の description フィールドです。これはカタログ上の説明文として機能し、メインエージェントは多数のスキルの中からこの description を読んでどれを呼び出すか判断します。
スキルが実際に呼び出されたタイミングではじめて、Markdown 本文の指示や参照ファイルの中身がコンテキストにロードされる仕組みです。これによりメインエージェントのコンテキストを過剰に汚染することなく、必要な専門知識をジャストインタイムで投入できる点が肝になります。
デモでは、John があらかじめ用意していた Mermaid 作図用のスキルを、Gemini CLI に再ロードさせて使用します。直前の探索で集めたコンテキストはセッションに残っているので、John が「Mermaid の図を作って」と指示するだけで、エージェントはカタログから Mermaid スキルを発見・起動し、ファイルを生成しました。
ここで興味深いのが、Mermaid スキルには png ファイルへの変換スクリプトと生成されたファイルが破損していないかを検証するスクリプトまでバンドルされていた点です。スキル単体でMermaid ソースの生成 > png ファイルへの変換 > 検証までを完結させており、最終的には共有可能な2つのファイルを得ることができました。
Aishanee 氏はこの設計について、自分がすでに解いた問題に毎回トークンを消費させるのではなく、一度作って・バンドルして・再利用するという思想を強調していました。
3. Sub-agents でコンテキストを分離する
スキルは強力ですが、ワークフローが長く・複雑になるにつれて限界も見えてきます。スキルを呼び出すたびに、その参照ファイルや手順がメインエージェントのコンテキスト（記憶）に挿入されるため、複数のスキルをまたぐ作業では情報が断片化し、過負荷に陥ってしまうのです。たとえば「Mermaid 図の生成と検証」のような専門タスクの細部がノイズとなり、本来の目的である探索タスクの邪魔をしかねません。
そこで真価を発揮するのが Sub-agents（サブエージェント）です。
サブエージェントは、特定のタスクに専念する独立したエージェントです。メインエージェントとは明確に分離された「独自のコンテキスト」と「専用のツールセット」を持ちます。タスクが完了すると、サブエージェントは「最終結果」と「次に繋がる最も価値の高い情報」だけを抽出してメインエージェントに返却します。これにより、メインのセッションを常にクリーンな状態に保つことができます。
サブエージェントを構成する中核要素は、特定の役割を与える「ペルソナ（システムプロンプト）」と、それに最適化された「ツールセット」の2つです。Abhi 氏も紹介しているように、CLI には組み込みのサブエージェントとして Codebase Investigator などが用意されています。これは、新機能の調査時などに発生する「長大なコードベースの探索」という重い処理を、メインの思考プロセスから切り離し、独立したコンテキストに閉じ込めるために生まれたものです。
カスタムサブエージェントにはローカル型とリモート型の2種類があります。ローカル型は Gemini CLI の組み込みツール（read、grep、skills など）を直接利用するもので、リモート型は A2A プロトコルに対応した既存エージェントへ接続するもので、クラウド側のエージェントを呼び出す用途に有効です。
サブエージェントの定義ファイルは、設定を記述するフロントマター（YAML 形式など）と、システム指示を記述する Markdown 本文から構成されます。フロントマターには name、description、tools（許可するツールのリスト）、model（使用するLLM）などを定義します。
ここで最も重要なのが description の質です。メインエージェントは、この説明文を頼りに「暗黙的な呼び出し（Implicit invocation）」を行います。説明が貧弱だと、メインエージェントは「いつ、どのタスクを委譲すべきか」を正しく判断できないため、役割と発動条件を明確に記述することがサブエージェントを使いこなす最大の肝となります。
また、サブエージェントごとにツールを厳格に制限できるのも大きな利点です。例えば「Codebase Investigator」では、ファイルを意図せず書き換えないよう、許可ツールを読み取り系（Read-only）のみに絞り込んでいます。
さらに発展的な設計として、サブエージェントの定義内に MCP（Model Context Protocol）サーバーをインライン化することも可能です。たとえば、50を超える機能を持つ Google Workspace の MCP ツール群を特定のサブエージェント内に閉じ込めることで、メインエージェントのコンテキストを汚染せずに高度な外部連携を実現できます。Abhi 氏はこのアーキテクチャの利点を「メインエージェントを context rot（コンテキストの腐敗。不要な情報やツールによってコンテキストが劣化すること）から守る手段」と強調していました。
デモでは、John が Mermaid スキルとアーキテクチャ図作成を1つにまとめた architect-visualizer というサブエージェントを事前に作成しておき、@architect-visualizer のように @ 構文で呼び出していました。
新規セッションから始めても、サブエージェントは自身のシステム指示に従って Mermaid スキルをアクティブにし、必要に応じて何度もコードベースを読み返しながら 正確性を担保するためのダブルチェックを行います。これらのファイル読み込みはサブエージェントのコンテキストに閉じ込められ、メインエージェントには ASCII の図と最終ファイルの場所だけが返却されました。
4. Extensions でカスタマイズをチームに共有する
ここまでで作成した Skills と Sub-agents は、いまだ John の手元のローカルにあるだけです。チームに展開し、社内全体で再利用するためには Extensions（拡張機能）でパッケージ化します。
Extensions は、Skills、Sub-agents、Hooks、コマンド、MCP サーバー、コンテキストファイル（gemini.md、claude.md、agents.md など）を一括で 1 つの共有可能なディレクトリにまとめる仕組みです。最低限、以下が揃っていれば成立します。
gemini-extensions.json（マニフェストファイル）- 共有したい Skills / Sub-agents / Hooks / コマンド / MCP サーバーの定義
- エージェント側に「いつ・どう使うか」を伝えるためのコンテキストファイル
なお Hooks は、エージェントのライフサイクルにおける任意の介入ポイントを設定する仕組みで、Google 社内でも独自機能を解放する目的で使用されているとのことでした。
ドキュメントを読み込んでマニフェストを手書きするのは煩雑です。そこでデモでは、Gemini CLI に同梱されている組み込みサブエージェント cli_help agent を @構文で呼び出し、対話的に Extension を組み立てるという画期的なアプローチが紹介されました。
cli_help agent は、ドキュメントを参照してマニフェスト構造を理解した上で、組み込みの ask user ツール（ユーザーに質問を投げかける機能）を使用します。これにより、「どんな拡張機能を作るか」「どのスキルを含めるか」「どのサブエージェントから呼び出すか」を順番に確認してくれます。
ユーザー（John）は、「Mermaid スキルとアーキテクチャ図のサブエージェントを含む architecture-visualizer 拡張を作りたい」といった自然言語で答えるだけでよく、必要な JSON やコンテキストファイルはすべて自動で生成されました。
完成した Extension の配布方法は、ユースケースに応じて使い分けられます。誰でも利用できる形で公開する場合は、パブリックな Git リポジトリで配布します。一方、機密性の高いプロンプトや MCP サーバーを社内限定で配布したい場合は、プライベートリポジトリやローカル共有フォルダを使ったセキュアディストリビューションを取ります。Abhi 氏は、Google 社内では各チームが独自の Extension を作成し、それを社内に広く共有する文化が根付いていると紹介していました。
Extensions Gallery によるコミュニティ連携
最後に紹介されたのが、コミュニティ全体で Extension を発見・共有できる Extensions Gallery です。2026年4月現在、数百規模の Extension が公開されており、Googler が開発した BigQuery や Google Workspace の Extensions から、サードパーティ企業が自社製品向けに公開している Extensions まで、幅広く利用できます。
ここで強調されていたのは、ギャラリー内の各 Extensions も、本セッションで紹介された仕組みの組み合わせに過ぎないという点でした。同じ部品を組み合わせて掛け算的にスケールさせ、コミュニティ全体で共有していく、というのが Gemini CLI の Extensions の構想の本質と言えそうです。
武井 祐介 (記事一覧)
クラウドソリューション部クラウドエンジニアリング課。
Google Cloud Partner Top Engineer 2026 選出。
Follow @ggenyutakei