Inside Android Skills - Built for deprecation

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

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

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

これまでに約 20 個の公式スキルをリリースしています。これらのスキルは、標準モデルがまだ十分に根拠を確立していない、非常に特殊で変化の速い分野（AGP 9、Navigation 3、高度なカメラ 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`.

ウェアアプリの横向きページャが正しく実装されていることを確認する評価の例

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

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

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

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

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

pull リクエストが無効になっているのはなぜですか？

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

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

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

• 曖昧なプロンプトを使用している: スキルは意図を明確にします。「この画面にアニメーションを追加して」のような曖昧なプロンプトを指定すると、特定の Compose アニメーション スキルがモデルにヒントを与え、モデルがそれまで考慮していなかった最新の API やスクリーンショット テスト パターンを検討するようになります。
• 小型で安価なモデルを使用したい: Frontier LLM は高価です。Gemma 4 などの小規模なオープンウェイト モデルにルーティン タスクをオフロードする場合は、基本スキルを有効にすると、小規模なパラメータで欠落している知識を補完できます。
• レガシー コードをリファクタリングまたはレビューしている場合: モデルは動作するコードの生成に優れていますが、古いコードベースを編集する場合、最新の精度で書き換えるよりも、周囲のレガシー パターンとの一貫性を優先することがよくあります。コアスキルを備えた専門の審査担当者が、その習慣を断ち切るお手伝いをします。
• 標準から逸脱している: LLM は、Android アプリを設計する標準の「Google の方法」を好みます。チームが高度にカスタマイズされたビューレイヤ アーキテクチャを使用している場合、モデルは整合性を維持するのが難しくなります。アーキテクチャを明示的に説明するカスタムスキルは非常に役立ちます。

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

Android コミュニティがあなたをサポートします。Chris Banes は Compose と Kotlin のスキルを包括的にまとめたものを、Ivan Morgillo は Compose プロジェクトを監査するスキルを、Jaewoong Eum は テストとパフォーマンスに関する 2 つのスキルを作成しました。

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

目標: 非推奨

Karpathy の言葉を大まかに言い換えると、「今日のスキルは明日のモデルに組み込まれる」となります。SOTA モデルは常に改善されているため、特に新しい API を中心に構築されたスキルは廃止される可能性があります。廃止時期を判断するために、新しいモデルがリリースされるたびに評価を実施します。合格した場合は、ほとんどのユーザーが移行するまで数か月間維持されます。