Google 公式発表:AI のコード生成成功率が 28% から 96% へ急上昇!その秘訣は「あるフォルダ」にあり、コンテキスト使用量は 90% 減
【解説】Google はわずか 1 週間で「Agent Skills」規格を、Gemini API、ADK(Agent Development Kit)、Android Studio という 3 つの主要製品ラインナップに統合しました。公式データによれば、このスキルパックを導入した結果、Gemini 3.1 Pro におけるコード生成の成功率は28.2% から 96.6% へと劇的に向上し、同時に基礎的なコンテキスト使用量は90% も削減されました。この「AI に拡張機能を装着する」動きは、開発者と AI エージェントの協業方法を根本から再定義しようとしています。
あなたの AI アシスタント、2 年前の SDK でコードを書いていませんか?
こんな光景を想像してみてください。AI アシスタントに Gemini API を呼び出すコード作成を依頼します。AI は自信満々でコードを提示してきます。構文も完璧で、ロジックも明解です。しかし、使われているのは半年前に廃止された古いインターフェースでした。
これは仮定の話ではありません。毎日どこかで起きている現実です。
Google Developers Blog は 3 月 25 日付の記事で、この問題を極めて率直に指摘しています。
"Large language models (LLMs) have fixed knowledge, being trained at a specific point in time."
「大規模言語モデル(LLM)の知識は『固定』されており、特定の時点でのトレーニング完了時のままです」
LLM の知識には有効期限がありますが、ソフトウェアエンジニアリングの実践は週単位で変化します。SDK は更新され、API は迭代(イテレーション)し、ベストプラクティスは進化し続けます。それなのに、あなたの AI アシスタントはトレーニングデータのタイムカプセルの中に閉じ込められたままなのです。
これがいわゆるナレッジギャップ(知識の格差)です。
これに対する Google の解決策は、モデルの再トレーニングでもなければ、RAG(検索拡張生成)の導入でもありません。その答えとは――AI に「スキルパック」を装着させることです。
たった 1 つのフォルダが、そのまま「スキル」になる
このスキルパックはAgent Skillsと呼ばれ、その中核思想は驚くほどシンプルです。ドメイン知識を 1 つのフォルダにパッケージ化し、AI が必要に応じて読み込むようにするのです。
フォルダの中には 1 つの `SKILL.md` ファイルを配置します。YAML 形式のヘッダーにメタデータを書き、Markdown 本文に具体的な指示を記述する。ただそれだけです。
しかし、Google が真に注力しているのは、このスキルパックの読み込み方式にあります。
「段階的开示」:Google 流のコンテキストエコノミー
Google for Developers の公式アカウントは 4 月 1 日の投稿で、Agent Skills の価値を一言で要約しました。
"By using progressive disclosure, you can load domain expertise only when needed. This can reduce baseline context usage by 90%."
「段階的开示(プログレッシブ・ディスクロージャー)を用いることで、必要な時にのみ専門知識を読み込むことができます。これにより、基礎的なコンテキスト使用量を 90% 削減可能です」
▲ Google for Developers 公式ツイート:Agent Skills の 3 層構造とコンテキスト 90% 削減の推广(170 以上の高評価)
3 段構えの階層構造、段階的に進行:
- L1 メタデータ
(1 スキルあたり約 100 トークン):エージェントに「どんなスキルを持つか」のみを伝達。いわばメニュー表 - L2 スキル本文
(5000 トークン未満):エージェントが必要と判断した時のみ完全な指示を読み込む。いわば注文 - L3 外部リソース
(オンデマンド取得):スクリプト、ドキュメント、コードサンプルなど。いわば料理の提供
従来の手法はどうだったでしょうか。すべての知識を system prompt に一括して詰め込むというものでした。これは、食事のたびにメニュー全体を丸暗記するようなものです。
Google ADK の公式ガイドでは、こう試算しています。10 のスキルを持っている場合、従来の方式では呼び出しごとに 10,000 トークンのコンテキストを投入する必要があります。一方、Agent Skills の L1 メニュー方式であれば、必要なのはわずか1,000 トークンです。
トークンとは即ちコストです。90% の削減は、そのまま 90% のコスト削減を意味します。
28.2% → 96.6%:データが語る真実
アーキテクチャの話だけではインパクトに欠けます。Google が公開した評価データこそが、真の切り札なのです。
Google は117 問のプログラミング問題(Python および TypeScript を網羅)を用いて、ある検証を行いました。Gemini に Agent Skills を装着させた場合、コード生成の正答率はどこまで向上するのか、というものです。
その結果は以下の通りです。
| 96.6% | ||
| 87.2% | ||
| 84.6% | ||
▲ @ai_for_success 氏によるまとめツイートが議論を沸騰させる:約 900 の高評価、12 万人が閲覧
Gemini 3.1 Pro は 28% から 96% へ、約 3.5 倍の向上。
Gemini 3 Flash は 6.8% から 87% へ、約 13 倍の向上。
さらにカテゴリー別のデータも驚異的です。エージェント的タスク(Agentic tasks)では100%、ドキュメント処理でも100%、SDK 利用に至っては94.6%の達成率を示しました。
この数字は瞬く間に X(旧 Twitter)中を駆け巡りました。
▲ @TeksEdge 氏による疑問:内部ベンチマークでは好調だが、SkillsBench ではどうなるのか?
熱狂する声がある一方で、冷静な見方をする人々もいます。@TeksEdge 氏はこう問いかけました。「内部テストでの成績は素晴らしいが、独立したベンチマークではどうなるのか?」
この疑問は健全なものです。自作自演のテストでは説得力に欠けるのは事実です。しかし、仮に割り引いて考えたとしても、0% から 52% への向上(Gemini 2.5 Flash)、6.8% から 87% への向上(Gemini 3 Flash)という桁外れの改善を、単なる「スコア稼ぎ」と片付けるのは困難でしょう。
公式ドキュメント、IDE、SDK へ実装――Google は本気だ
単にブログ記事を書き、デモ用リポジトリを公開するだけなら、それは「様子見(試水)」と呼ばれるでしょう。
しかし、今回の Google の動きはそれにとどまりません。
第 1 弾:Android Studio への実装。
Android Developer の公式ドキュメントに『Extend Agent Mode with skills』というページが新設され、Agent Skills が IDE のエージェントモードと直接連携するようになっています。
"Skills let you enhance Agent Mode's capabilities with specialized expertise and custom workflows. They are based on the Agent Skills open standard."
「スキル機能により、専門知識やカスタムワークフローを用いてエージェントモードの機能を強化できます。これらは Agent Skills 公開規格に基づいています」
▲ @github_skydoves 氏による Android Studio エージェントモードのスキルドキュメント共有、62 リツイート
注目すべきはopen standard(公開規格)という表現です。これは Google 独自のフォーマットではなく、公式ドキュメントに明記されたオープンな規格なのです。
第 2 弾:ADK(Agent Development Kit)への統合。
ADK には 3 つのネイティブ API、すなわち `list_skills`(L1 メニュー)、`load_skill`(L2 本文)、`load_skill_resource`(L3 リソース)が標準搭載され、単純なものから複雑なものまで 4 種類のスキルモードを完全にカバーしています。
第 3 弾:サンプルリポジトリのオープンソース化。一行 `npx skills add` を実行するだけで、まるで npm パッケージをインストールするかのように自然にエージェントへスキルを装着できます。
開発者コミュニティのリアルな反応
X(Twitter)上での議論は大変興味深いものです。
最も注目すべき声は、データへの驚きを表すものです。
▲ @_techibee 氏:「AI は愚笨なのではない……古くなっているだけだ。Agent Skills がその解決策となる。再学習不要で、即座に新しいツールを習得する」
"AI isn't dumb... It's just outdated. Google's Agent Skills fixes: Learns new tools instantly, Uses latest docs & SDKs, No retraining needed. Basically... AI that upgrades itself on the fly."
「AI は愚笨なのではありません。単に時代遅れなだけです。Google の Agent Skills はこれを修正します。新しいツールを即座に学習し、最新のドキュメントや SDK を利用可能にします。再学習は不要です。要するに……その場で自己アップグレードする AI なのです」
また、Agent Skills を MCP(Model Context Protocol)と組み合わせて見る向きもあります。
▲ @Anandzork 氏による Agent Skills と Docs MCP の組み合わせ、インストールガイドと性能比較図
@Anandzork 氏が提示した比較図は非常に直感的です。単体実行で 7.7%、MCP 追加で 72.4%、Skill 追加で 82.9%、そして両方を追加すると 96.3% に達します。同氏はさらに「トークン消費量も 63% 削減された」と強調しています。
AI エージェントがリアルタイムで知識を更新できる時代、手動でドキュメントを検索している開発者はどうなるのか。この問いを真剣に考える人が増えています。
しかし、浮かれすぎるのは禁物だ。Google 自身も冷や水を浴びせている
実は Google のブログ記事には、重要な「ただし書き」がいくつか隠されています。
Skills が常に AGENTS.md より優れているとは限らない――Google 自身、Vercel の研究を引用し、特定のシナリオでは直接 AGENTS.md を記述する方が効果的であることを認めています。更新メカニズムが未だ確立していない――スキルを装着した後、SDK がアップグレードされてもスキルは自動追従しません。ワークスペース内には時代遅れのスキルが蓄積し、かえってエージェントを誤誘導する恐れがあります。スクリプトの実行には未対応――ADK ドキュメントでは Experimental(実験的機能)と明記されており、L3 レイヤーのリソースは現状では閲覧のみで実行はできません。
さらに現実的な問題として、GitHub Discussion では、ADK が Agent Skills 規格を公式にサポートするかどうかの開発者からの質問に対し、「現時点で明確な計画はないが、チームで評価中である」という回答が返されています。
公式ドキュメントに記載して大々的に推進する一方で、中核となる SDK のサポートは「評価中」という状態。大企業が新しい規格を押し出す際のお決まりのパターンです。まずは世論を盛り上げ、後から機能を追いつかせるのです。
真のシグナル:「プロンプトエンジニアリング」から「スキル配信」へ
データや製品ラインの詳細をいったん脇に置くとして、この出来事が示す最も重要なシグナルとは何でしょうか。
Google は「AI への知識投入」を、個人の職人技からインフラストラクチャへと変えようとしています。
これまで:あなたは優秀なプロンプトエンジニアとして、GPT に信頼できる API 呼び出しコードを書かせるため、完璧な system prompt を 3 日かけて調整していました。それがあなたの競争力だったのです。
今:SDK 管理者が `SKILL.md` ファイルを 1 つ公開するだけで、すべてのエージェントが最新の API 知識を自動的に得られるようになります。あなたの 3 日間の職人技は、`npx skills add` という 1 行のコマンドに取って代わられたのです。
▲ @iRomin 氏:「Native Agent Skills は、モデルを信頼できるコンテキスト上に構築することで DX を最適化する」
だからこそ、Agent Skills 規格の主要な維持管理を行っているのが Google ではないという事実に注目すべきなのです。その正体は Anthropic です。
そうです、この規格は元来 Anthropic の Claude Code に由来し、2025 年末にオープン規格として公開されました。Google はその最大の「採用企業」の 1 つですが、Microsoft、OpenAI、GitHub Copilot、Cursor など、26 以上のプラットフォームが追随しています。
すべての大手企業が同じファイル形式に収束しつつある今、これは単なる新機能のリリースなどという生易しいものではありません。
これはエコシステムにおける役割の再定義です。SKILL.md を作成する者が、AI エージェントへの知識の入り口を支配するのです。
SDK 管理者、フレームワーク開発者、ドキュメント作成チーム――これまで「人間のために書く」ことを役割としていた人々が、これからは「AI のために書く」ことになります。
それも、この規格に従って、です。
— 以上 —