Googleが、自社プロダクトの使い方をAIコーディングエージェントに教える公式の「Agent Skills」リポジトリ google/skills を公開した。AlloyDBやBigQuery、Cloud Run、Firebase、Gemini APIといったGoogle製品の正しい使い方を、エージェントが読み込めるSKILL.md形式でまとめたものだ。導入はnpx skills add google/skillsの一行で済み、Antigravity・Gemini CLI・Claude Codeなど形式に準拠した任意のエージェントから同じスキルを使える。
注目すべきは収録スキルの数より、その「出どころ」だ。Agent Skillsという形式はもともとAnthropicがClaude向けに広めた仕組みで、それをVercelがnpx skillsとしてCLI化し、今回Googleが自社製品解説の公式配布レイヤーとして採用した。つまり一社の便利機能だったSkillが、エージェントをまたいで通用する相互運用の標準レイヤーへと性格を変えつつある。本記事はその転換点を、公式リポジトリ・公式ブログ・GitHub APIの実測値だけを根拠に整理する。
Skillの仕組み自体をゼロから理解したい方は、まず Claude Skillsを徹底解説｜スキルはフォルダ——Anthropicエンジニアが明かした仕組みと使い方 を読むと、本記事の「標準化」の話がより腑に落ちる。
30秒で理解する google/skills
・何者か：Googleが公開した公式Agent Skillsリポジトリ。Google製品の使い方をSKILL.md形式でまとめた「公式ドキュメントの配布レイヤー」
・規模：GitHub実測（2026-06-13）でスター約1万3千・フォーク約1千・Apache 2.0。スキルはskills/cloud配下に30本（公開当初は13本）
・入れ方：npx skills add google/skills（公式ブログ表記はnpx skills install github.com/google/skills）。Antigravity・Gemini CLI・Claude Codeなど準拠エージェントで動く
・意味：Anthropic起点のSkills仕様がVercel→Googleへ波及。Skillが各社共通の標準レイヤーになりつつある
導入直後に見えるのは拍子抜けするほど短いコマンド一行だ。実際の操作はこれだけで、あとはどのスキルを入れるかを対話で選ぶ。
# 公式リポジトリからスキルを導入（対話で選択）
npx skills add google/skills
# 導入済みスキルを確認
npx skills list
# 例：BigQueryスキルだけをClaude CodeとCursorに入れる
npx skills add google/skills -a claude-code -a cursor
何が起きたか — Googleが公式Skillsリポを公開した意味
これまでGoogle Cloudの使い方は、公式ドキュメント・チュートリアル・ブログに分散していた。AIエージェントにCloud Runへデプロイさせようとすると、エージェントは学習済みの古い知識や、検索で拾ったブログのコピペで埋め合わせる。結果、非推奨のSDKパターンや古いCLIフラグを平気で出力する——これが現場で繰り返されてきた問題だ。
google/skillsは、この「エージェントが参照する一次情報」をGoogle自身が公式に供給する試みだ。Googleの公式ブログ（2026年4月23日）は、リポジトリを「シンプルでオープンな形式（a simple, open format）」と表現し、Antigravity・Gemini CLI・サードパーティエージェントから使えると説明している。重要なのは、これがマーケティング資料ではなくエージェントが直接読み込んで実行に使う実務知識だという点だ。
なぜGoogleがこれを「公式」でやる必要があったのか。理由は品質保証にある。コミュニティが作るGoogle Cloud解説スキルは玉石混交で、古いパターンやセキュリティ的に危ういコードを含むことがある。google/skillsのCONTRIBUTING.mdは、外部プルリクエストを一切受け付けず、すべてのスキルがGoogleチームの内部検証・承認を経ると明記している。これは「公式が責任を持って正しい使い方を配る」という宣言であり、後述するコミュニティ系リポジトリとの決定的な違いだ。
・従来：エージェントは古い学習知識やブログのコピペでGoogle Cloudを操作 → 非推奨パターンが頻発
・google/skills：Googleが検証・承認した正しい手順をSKILL.mdで供給 → エージェントが一次情報を参照
・狙い：ドキュメントの配信先をAIエージェントへ拡張し、製品の「正しい使われ方」を公式が担保する
google/skills の中身を解剖する（30スキルを用途別に整理）
リポジトリのスキルはすべてskills/cloud/配下に置かれている。GitHub API実測（2026年6月13日）で30本あり、Googleの公式ブログが公開当初に挙げた13本から大きく拡充されている。用途別に整理すると、Googleが「エージェントにまず教えたい領域」が見えてくる。
最も厚いのがVertex AI Agent系（11本）だ。エージェントのデプロイ、エンドポイント管理、推論、モデルレジストリ、プロンプト管理、RAGエンジン管理、チューニング、評価フライホイール（eval-flywheel）、AI Studioからの移行、そしてスキルレジストリ自体まで揃う。Googleが自社のエージェント基盤（Vertex AI Agent Engine）の運用ノウハウを最優先で配っていることがわかる。
google/skills の30スキル（用途別・実測 2026-06-13）
・Vertex AI Agent系（11）：deploy／endpoint-management／inference／model-registry／prompt-management／rag-engine-management／tuning／tuning-management／eval-flywheel／migrate-from-ai-studio／skill-registry
・Gemini API系（3）：gemini-api／gemini-agents-api／gemini-interactions-api
・Cloud基礎（7）：alloydb-basics／bigquery-basics／cloud-run-basics／cloud-sql-basics／firebase-basics／gke-basics／gcloud
・レシピ（3）：recipe-auth（認証）／recipe-onboarding（オンボーディング）／networking-observability（ネットワーク可観測性）
・Well-Architected Framework（6）：security／reliability／cost-optimization／operational-excellence／performance-optimization／sustainability
注目したいのがWell-Architected Framework（WAF）の6本だ。これはAlloyDBのような「製品の使い方」ではなく、セキュリティ・信頼性・コスト最適化・運用上の卓越性・性能最適化・持続可能性という設計原則をスキル化したものだ。エージェントにコードを書かせるとき、単に動くものではなく「Googleの推奨設計に沿ったもの」を出させたい——その意図が読み取れる。横断的な設計指針をSkillにできること自体が、Skillの応用範囲の広さを示している。
Cloud基礎の7本（AlloyDB・BigQuery・Cloud Run・Cloud SQL・Firebase・GKE・gcloud）は最も直感的だ。各製品の基本操作・典型パターン・よくある落とし穴をまとめてあり、エージェントがその製品を触る前に読み込む「事前知識」として機能する。なお、FlutterとDartのスキルは別リポジトリで提供されると公式が案内している。
npx skills の使い方 — インストールからエージェント認識まで
google/skillsを動かす鍵はnpx skillsというCLIだ。これはGoogle製ではなく、Vercel（vercel-labs/skills）が開発したAgent Skillsのパッケージマネージャである。npmにおけるnpxのように、ローカルにインストールせずnpx skillsで即実行できる。Vercelの公式説明はこれを「オープンなエージェントスキル・エコシステムのためのCLI」と位置づけている。
基本的な流れはnpmやHomebrewを使ったことがあれば直感的だ。リポジトリを指定してスキルを取得し、どのエージェントに入れるかを選ぶと、各エージェントの設定ディレクトリにスキルが配置される。
# スキルを追加（対象エージェントを -a で複数指定可）
npx skills add vercel-labs/agent-skills -a claude-code -a cursor
# キーワードでスキルを検索
npx skills find bigquery
# 1スキル分のプロンプトを生成、または対話的にエージェント起動
npx skills use bigquery-basics
# 導入済み一覧 / 更新 / 削除
npx skills list
npx skills update
npx skills remove bigquery-basics
# 自作スキルの雛形（SKILL.md）を生成
npx skills init
配置方法にはsymlink（既定）とコピー（--copy）の2方式がある。Vercelのドキュメントはsymlinkを推奨既定とし、「各エージェントから正規コピー（single source of truth）へsymlinkを張る。更新が容易」と説明する。複数のエージェント（Claude CodeとCursorとGemini CLI）を併用していても、スキルの実体は1か所にあり、更新すれば全エージェントに反映される。これがコピー方式だとエージェントごとに実体が増え、更新漏れが起きやすい。
npx skills 主要サブコマンド
・add <repo>：リポジトリからスキルを取得しエージェントへ配置（-aで対象指定）
・use <skill>：1スキルのプロンプト生成／対話起動
・find <keyword>：スキルをキーワード検索
・list：導入済みスキル一覧
・update：導入済みスキルを最新化
・remove <skill>：スキルを削除
・init：SKILL.md雛形を作成
インストール後、エージェントがスキルを「認識」する流れは次のMermaidのとおりだ。CLIがリポジトリを取得し、SKILL.mdを解決して各エージェントの設定先へsymlinkを張る。エージェントは起動時にそのディレクトリを走査し、SKILL.mdのメタ情報（名前・説明）だけを読み込んでおき、実際に必要になったとき本文と付属ファイルを展開する。
google/skills] --> B[GitHubから
リポジトリ取得] B --> C[SKILL.mdを解決
対象エージェント選択] C --> D[各エージェントの
設定先へsymlink] D --> E[エージェント起動時に
メタ情報を走査] E --> F[必要時に本文と
付属ファイルを展開] F --> G[正しい手順で
コード生成・実行]
この「メタ情報だけ常時保持し、本文は必要時に展開する」仕組みは、Anthropicが広めたProgressive Disclosure（段階的開示）の考え方そのものだ。GoogleのADK（Agent Development Kit）ではlist_skills（L1）・load_skill（L2）・load_skill_resource（L3）という3階層のツールとして実装されており、トークンを浪費せずに大量のスキルを扱える設計になっている。
Anthropic起点のSkills仕様がどう波及したか
ここで一歩引いて、Skillという形式がどう広がってきたかを時系列で見る。出発点はAnthropicだ。AnthropicはClaude向けに、SKILL.mdというMarkdownファイルへメタ情報（frontmatter）と手順を書き、エージェントが必要なときだけ読み込む「Agent Skills」を広めた。仕組みの詳細は Anthropic Skills入門：Claudeの能力を拡張するMarkdownベースのスキル定義集 で解説したとおりだ。
次に動いたのがコミュニティとVercelだ。Addy Osmani氏が上級エンジニアの思考をスキル化した Agent Skills集 を公開し、Vercelはnpx skillsというCLIを作って「Skillをnpmのように配布・インストールする」レイヤーを整えた。これによりSkillは特定のエージェントに閉じず、リポジトリ単位で配って任意のエージェントに入れられる「パッケージ」になった。
そして今回、Googleが公式リポジトリで参入した。Googleは自社プロダクトの正しい使い方を公式スキルとして配り、しかもGemini CLIはネイティブにスキルを扱う。Anthropic（仕様の起点）→ Vercel（配布CLI）→ Google（公式コンテンツと自社CLI対応）という波及の流れが、ここで一周した。
Agent Skills仕様を提唱
SKILL.md形式] --> B[コミュニティ拡散
Addy Osmani / awesome系] A --> C[Vercel
npx skills CLI化
skills.sh / 70+エージェント対応] C --> D[Google
公式リポ google/skills
Gemini CLIネイティブ対応] B --> E[agentskills.io
ベンダー中立の
オープン標準として整理] C --> E D --> E E --> F[40+ プロダクトが
同一フォーマットを採用]
興味深いのは、GoogleもGemini CLIの公式ドキュメントも、この形式を「Anthropicの仕様」とは呼ばず「agentskills.ioのオープン標準」として説明している点だ。起点がAnthropicであることは業界の共通認識だが、各社は特定ベンダーに紐づかない中立な標準として扱おうとしている。これは標準化が進むときに典型的に起きる現象で、フォーマットが一社の所有物から「みんなのもの」へ移っていく兆候だ。
「便利機能」から「相互運用の標準レイヤー」への位置づけ変化
ここまでの流れを踏まえると、Skillの位置づけが質的に変わったことがわかる。当初Skillは「Claude Codeに自分のワークフローを教える便利機能」だった。スコープは個人やチームのリポジトリに閉じ、価値は「自分のエージェントが賢くなる」ことにあった。
いま起きているのは、その価値の中心が相互運用（interoperability）へ移ったことだ。GoogleがBigQueryスキルを公式配布すると、それはClaude CodeでもCursorでもGemini CLIでも同じように効く。スキルの作り手（Google）と使い手のエージェント（各社）が分離し、一度書いたスキルがエージェントをまたいで通用する資産になる。これはまさにパッケージマネージャやWeb標準が辿った道だ。
この変化が実装者・設計者に突きつける問いは具体的だ。たとえば自社プロダクトを持つ企業なら、「自社の使い方をSKILL.mdで公式配布すべきか」が新しい意思決定項目になる。Google・Cloudflare・Firebaseがすでに動いている以上、エージェント経由で自社製品を使われる時代に、公式スキルがないことは「エージェントが古い情報で自社製品を誤用する」リスクを放置することを意味する。
・個人/チーム段階：Skill＝自分のエージェントにワークフローを教えるメモ。価値は個人最適
・配布段階：npx skillsでリポジトリ単位に配布可能に。Skillがパッケージ化
・標準レイヤー段階：Google等が公式配布。エージェントをまたいで通用する相互運用資産へ
・実装者への問い：自社プロダクトの「公式スキル」を出すべきか、が新たな意思決定に
Antigravity / Gemini CLI / Claude Code でどう動くか
「準拠エージェントなら動く」と書いたが、実際の体験はエージェントによって少しずつ違う。Googleの公式ブログはAntigravity・Gemini CLI・サードパーティエージェントを明示的に挙げている。
Gemini CLIは最もネイティブにスキルを扱える。/skills listで一覧、/skills enable <name>・/skills disable <name>で個別に有効化／無効化でき、ターミナルからはgemini skills install https://github.com/user/repo.git --consentでインストールできる（--consentはセキュリティリスクを了承し対話確認を省くフラグ）。スキルが有効化されると、公式ドキュメントいわく「SKILL.mdの本文とフォルダ構造が会話履歴に追加される」。
# Gemini CLI：スキルの確認と有効化（対話セッション内）
/skills list --all
/skills enable bigquery-basics
# ターミナルから直接インストール
gemini skills install https://github.com/google/skills.git --consent
Antigravity（Googleのエージェント開発環境）でもスキルはネイティブにサポートされる。Claude CodeやCursorは、Agent Skills形式が共通であるため、同じgoogle/skillsのスキルをそのまま読み込める。Claude側のSkillの扱い（.claude/skills/配置、frontmatterのdescriptionによる自動呼び出しなど）は Claude Skillsを徹底解説 のとおりで、google/skillsのSKILL.mdもこの枠組みに乗る。
ここで効いてくるのがnpx skillsのマルチエージェント対応だ。-a claude-code -a cursor -a geminiのように複数指定すれば、1回のコマンドで複数エージェントへ同じスキルを配置できる。symlink方式なら実体は1か所なので、チーム内でエージェントの好みが分かれていても、スキルの管理は一元化できる。
主要実装の比較 — 公式 / Vercel / Google / コミュニティ
Skillエコシステムには性格の異なるプレイヤーが並ぶ。「仕様の起点」「配布のCLI」「公式コンテンツ」「コミュニティ集約」という役割の違いを押さえると、どれを使うべきかが整理できる。下表はそれぞれの位置づけを比較したものだ。
| プレイヤー | 役割 | 提供物 | 対象エージェント | コントリビュート | ライセンス |
|---|---|---|---|---|---|
| Anthropic（起点） | Agent Skills形式の提唱者 | SKILL.md仕様・Claudeのネイティブ実装 | Claude Code / Claude | 仕様は事実上の公開標準 | 製品依存 |
| Vercel（vercel-labs/skills） | 配布CLI（パッケージマネージャ） | npx skills / skills.sh ディレクトリ |
70+（Claude Code・Cursor・Gemini CLI等） | OSSとして受付 | OSS |
| Google（google/skills） | 公式コンテンツ供給 | Google製品の公式スキル30本 | Antigravity / Gemini CLI / 準拠エージェント | 外部PR不可（内部検証のみ） | Apache 2.0 |
| コミュニティ（awesome系等） | スキルの集約・キュレーション | 多数のスキルへのリンク集・横断検索 | 形式準拠の任意エージェント | 誰でも可（玉石混交） | 各リポ依存 |
この比較から、それぞれの使い分けが見える。正確さが最優先で対象がGoogle製品なら、内部検証を経たgoogle/skillsが第一候補だ。外部PRを受け付けない閉じた運用は、裏を返せば品質の担保でもある。配布や自作スキルの管理にはVercelのnpx skillsが事実上の標準ツールになる。幅広いスキルを探すならコミュニティのawesome系リポジトリやskills.shのディレクトリが効くが、品質は自分で見極める必要がある。
Cloudflareがいち早く cloudflare/skills を公開していたことを思い出すと、Googleの参入は「主要クラウドベンダーが公式スキルを持つ」流れの決定打と言える。次はAWSやMicrosoft Azureが続く、と見るのが自然だろう。
自作スキルの作り方 — SKILL.md とプロジェクト構造
google/skillsへ外部PRは出せないが、自分のリポジトリでスキルを作ってnpx skillsで配ることは誰でもできる。最小構成は驚くほど単純で、スキル名のフォルダにSKILL.mdを置くだけだ。雛形はnpx skills initで生成できる。
my-skills/
└─ skills/
└─ bigquery-cost-guard/
├─ SKILL.md # メタ情報＋手順（必須）
├─ reference.md # 詳細リファレンス（任意・必要時に展開）
└─ examples/ # サンプルクエリ等（任意）
SKILL.mdの冒頭にはfrontmatterでメタ情報を書く。ここで最重要なのがdescriptionだ。エージェントは普段このdescriptionだけを読んでおき、ユーザーの依頼に関連すると判断したときに本文を展開する。だから「いつこのスキルを使うべきか」が伝わる説明文を書くことが、スキルが正しく自動呼び出しされるかどうかを決める。
---
name: bigquery-cost-guard
description: BigQueryのクエリコストを見積もり、スキャン量を抑える書き方を提案する。コスト・パーティション・課金バイト数の話題で使う。
---
# BigQuery コストガード
## いつ使うか
ユーザーがBigQueryのクエリを書く・レビューする・遅い/高いと言ったとき。
## 手順
1. `SELECT *` を避け、必要な列だけを指定する
2. パーティション列・クラスタ列でフィルタしてスキャン量を削減する
3. `--dry_run` で課金バイト数を見積もってから実行する
...
自作スキルの設計チェック
・フォルダ名＝スキル名：英小文字とハイフン（例：bigquery-cost-guard）
・descriptionに発火条件：「いつ使うか」を明示。これが自動呼び出しの精度を決める
・本文は手順に絞る：詳細リファレンスは別ファイルに分け、必要時に展開させる（段階的開示）
・配布は自分のリポジトリ：npx skills add <自分のrepo> で任意エージェントへ
命名規約はgoogle/skillsの実例（alloydb-basics・google-cloud-waf-security）が参考になる。製品名＋用途、あるいはカテゴリ＋トピックを英小文字ハイフンでつなぐと、npx skills findでの検索性も上がる。Markdownで書ける手順書がそのまま全エージェント共通の資産になる——この敷居の低さこそ、Skillが急速に広がった理由だ。
実際にテーマを絞ってスキルを束ねた例としては、Claude向けにデザイン領域の知識をまとめた designer-skills｜Claude Codeにデザインの目利きを与えるスキル集 が参考になる。google/skillsが「製品の使い方」を公式に束ねたのと同じ発想で、特定領域の専門知識をスキル集として配る動きは今後さらに増えるだろう。
これからのSkillsエコシステム — 次に来るもの
公式リポジトリの登場で、Skillエコシステムは次の段階に入る。ここからは公式情報に基づく現状の整理と、そこから論理的に導ける見通しを区別して述べる。
確実に言えるのは、主要ベンダーの公式スキル参入が続くことだ。CloudflareとGoogleが公式リポジトリを持ち、Firebaseは製品ドキュメントにAgent Skillsの項目を設けている。エージェント経由で製品を使われる前提に立つベンダーほど、公式スキルを出すインセンティブが強い。次の四半期でAWSやAzure、主要SaaSが追随しても驚きはない。
google / cloudflare] --> D[標準レイヤー
agentskills.io] B[配布CLI
npx skills / skills.sh] --> D C[コミュニティ集約
awesome系・横断検索] --> D D --> E[エージェントは
製品ごと公式スキルを
その場で取得] D --> F[企業は自社の
使い方を公式配布]
もう一つの論点は発見性（discoverability）だ。スキルが増えるほど「どのスキルを入れるべきか」を見つける仕組みが重要になる。Vercelのskills.shはディレクトリの役割を担い、コミュニティのawesome系リポジトリは横断検索を提供する。google/skillsにskill-registryスキルが含まれていることも示唆的で、スキルそのものを管理・登録する基盤が整いつつある。npmにおけるnpmjs.comのような中心的なレジストリが固まれば、エコシステムは一気に成熟するだろう。
実装者が今からできる準備は具体的だ。第一に、自分のチームのワークフローをSKILL.md化してnpx skillsで共有する習慣をつけること。第二に、自社プロダクトがあるなら公式スキルの提供を検討すること。第三に、複数エージェントを併用するならsymlink方式でスキルを一元管理すること。Skillが標準レイヤーになる流れに早く乗るほど、エージェント時代の資産を先に積める。
まとめ
google/skillsは、表面的には「Google Cloudの使い方をまとめた30本のスキル集」だ。しかし本質は、Anthropicが始めたAgent Skillsという形式が、Vercelの配布CLIを経てGoogleの公式採用に至り、一社の便利機能から各社共通の標準レイヤーへ昇格した転換点にある。
・事実：Googleが公式Agent Skillsリポジトリgoogle/skillsを公開（Apache 2.0・実測スター約1万3千・スキル30本）
・入れ方：npx skills add google/skills。Antigravity・Gemini CLI・Claude Codeなど準拠エージェントで動作
・意味：Anthropic→Vercel→Googleと波及し、Skillがエージェントをまたぐ相互運用の標準仕様になりつつある
・実装者への示唆：自社の使い方を公式スキルで配る判断、チームのワークフローをSKILL.md化する習慣が、これからの差を生む
「Skillは便利機能だ」という認識のままだと、この標準化の波を見逃す。次に問うべきは「自分（や自社）の知識を、どのSKILL.mdに書いて配るか」だ。
参照ソース
・google/skills — GitHub公式リポジトリ（README・CONTRIBUTING.md・skills/cloud配下・GitHub API実測値）
・Level Up Your Agents: Announcing Google’s Official Skills Repository — Google Cloud Blog（2026-04-23）
・A developer’s guide to building ADK agents with Skills — Google Developers Blog
・vercel-labs/skills — npx skills CLI（README・サブコマンド・symlink方式）
・Agent Skills — Gemini CLI 公式ドキュメント
