Inside Android Skills - サポート終了を想定した設計

4 月に公式の Android Skills  をリリースしたところ、予想をはるかに上回る反響がありました。このブログ投稿では、寄せられたフィードバックの一部を取り上げ、プロジェクトの背景にある理念と手法について説明します。また、スキルをインストールして使用する際に舞台裏で何が起こっているかを理解することで、トークンと自分の時間をより有効に活用できるようになることを願っています。

公式スキルが少ないのはなぜですか？

現在、新しいスキルを検討するのは、最先端（SOTA）モデルに検証可能な知識ギャップがある場合のみです。簡単に言えば、モデルがすでに知っていることをモデルに教える必要はありません。（ただし、いくつかの例外があります。詳しくは以下をご覧ください）。

これまでに 20 ほどの公式スキルをリリースしました。これらは、標準モデルがまだ十分に根付いていない、非常に具体的で変化の速い領域（AGP 9、Navigation 3、高度な Camera API、Perfetto SQL など）を意図的にターゲットにしています。

より一般的なコアスキルはどうでしょうか？インストールされたスキルは、開始するすべてのタスクのベースライン コンテキストに 100 ～ 200 個のトークンを挿入します。そのスキルが実際に有効になると、その数はすぐに数千に跳ね上がります。ほとんどの場合、基本的なスキルを囲い込むことは、逆効果であり、費用もかかります。基本的な Kotlin や Compose を記述するためのスキルをインストールする前に、選択した LLM に本当にそのスキルが必要なのか、それともすでにそれらのトピックを十分に理解しているのかを検討してください。

スキルの評価

各スキルは、リリース前に、スキルが明確な価値を提供することを証明する包括的な評価セットに対してテストされます。これらの評価は、スキルが有効な場合は合格し、それ以外の場合は不合格になるはずです。評価は、コードに対する統合テストのようなものです。

timeout_s: 1200
repository:
  url: [redacted - internal git repo]
  working_dir: wear_compose_m3_empty_app
category_ids:
  - wear
prompt: |-
  Add a horizontal pager to MainActivity.kt. Have three pages in the pager. Each page should contain
  the text "Page 1", "Page 2", and "Page 3" respectively in the center of the screen.
commands:
  build:
    - ./gradlew assembleDebug
acceptance_criteria:
  project_builds: true
  llm_diff_judge:
    - Must use `HorizontalPagerScaffold`.
    - Each page should use `AnimatedPage` to wrap a `ScreenScaffold`.

Wear アプリでの水平ページャーの正しい実装を確認する評価の例

少なくとも、最新の Gemini Flash モデルを使用して Android Studio でスキルをテストします。スキルによっては、Gemini Pro などの他のモデルや、Antigravity などの他のエージェント、サードパーティ システムとの互換性も確保します。

すべての評価はナレッジベースにアクセスして実行されるため、情報がドキュメントにあり、モデルがそれを検索すると判断した場合、そのスキルは公開されません。

Android ナレッジベース（Android Studio または Android CLI）を使用する

Android アプリを開発する場合は、常に Android ナレッジベースを使用して公式ドキュメントにアクセスする必要があります。Android Studio でエージェントを使用する場合は、ツールとしてすでに利用可能ですが、別のエージェントを使用する場合は、Android CLI をインストールします。このツールには、エージェントが Android の公式ドキュメントにアクセスできるようにする docs コマンドなどが含まれています。1 つのツールを使用する方が、何百ものスキルをインストールするよりもはるかに効率的です。

モデルが過信しているように見え、ドキュメントをより頻繁に参照させたい場合は、AGENTS.md ファイルまたは同等のファイルに「Android API を扱うときは、常に公式の Android ドキュメントを参照してください」と追加するのが一般的な方法です。もちろん、プロンプトでエージェントにドキュメントを直接確認するよう指示することで、この動作を強制することもできます。

pull リクエストが無効になっている理由

Google の評価フレームワークは、オープンソース化できない内部インフラストラクチャに依存しているため、新しいスキルに対する pull リクエストを直接受け入れることはできません。このインフラストラクチャがなければ、受信した PR の変更を再評価する方法がありません。ただし、コミュニティからのフィードバックは積極的にモニタリングしています。バグの報告、最適化の提案、新しい公式スキルのリクエストがある場合は、問題を報告してください。

コアスキルや基本スキルが有効なのはどのような場合ですか？

SOTA モデルは一般的に基本スキルを必要としませんが、コアスキルやコミュニティ構築スキルを有効にすることで、実際の価値が追加されるシナリオもあります。次に例を示します。

• 曖昧なプロンプトを使用している: スキルは意図を増幅します。「この画面にアニメーションを追加して」のような曖昧なプロンプトを与えた場合、特定の Compose アニメーション スキルがモデルにインスピレーションを与え、モデルがそれまで考慮していなかった最新の API やスクリーンショット テスト パターンに目を向けるようになる可能性があります。
• より小さく、より安価なモデルを使用したい場合: フロンティア LLM は高価です。Gemma 4 などの小規模なオープンウェイト モデルにルーティン タスクをオフロードする場合、基本スキルを有効にすると、小規模なパラメータでは見落とされる知識のギャップを埋めることができます。
• レガシーコードのリファクタリングまたはレビューを行っている場合: モデルは、動作するコードの生成に優れていますが、古いコードベースを編集する場合、最新の精度で書き直すよりも、周囲のレガシー パターンとの整合性を維持することを優先することがよくあります。コアスキルを備えた専門の審査担当者エージェントは、この習慣を打破するのに役立ちます。
• 標準から外れている: LLM は、Android アプリを設計する標準的な「Google の方法」を好みます。チームが高度にカスタマイズされたビューレイヤ アーキテクチャを使用している場合、モデルは整合性を維持するのに苦労します。アーキテクチャを明示的に記述したカスタムスキルは、大きな効果を発揮します。

コアスキルはどこで確認できますか？

Android コミュニティがあなたをサポートします。Chris Banes 氏は Compose と Kotlin のスキルを網羅したコレクションを、Ivan Morgillo 氏は Compose プロジェクトを監査するスキルを、Jaewoong Eum 氏はテストとパフォーマンスに関する 2 つのスキルを公開しています。

スキルは必ず信頼できるソースからダウンロードしてください。個人的には、数十から数百の Android スキルを含むリポジトリは信頼しません。おそらく AI によって生成されたもので、テストされておらず、悪意のある指示や偏った指示が含まれている可能性もあるからです。また、一般的なソフトウェア エンジニアリング スキルを盲目的に適用しないでください。その多くはウェブ デベロッパー向けに調整されています。

目標: 非推奨

Karpathy 氏の言葉を大まかに言い換えると、今日のスキルは明日のモデルに組み込まれるということです。SOTA モデルが改善され続けるにつれて、スキル、特に新しい API を中心に構築されたスキルは陳腐化すると予想されます。廃止のタイミングを判断するために、新しいモデルがリリースされたときに評価を実行します。合格した場合は、ほとんどのユーザーが移行するまで数か月間、そのユーザーを維持します。