Claude Code と Android CLI を使用したエージェント エンジニアリング

こんにちは。Android デベロッパー リレーションズの Ben です。

プロダクト マネージャーの Steven です。

本日は、Claude Code と Android CLI を使用してエージェント的にアプリを作成する方法について説明します。

デベロッパーとしての役割は少しずつ変化しており、物事は驚くほど速く進んでいます。実際、この講演の内容は、特にオンラインで視聴している方にとっては、すでに古くなっているかもしれません。

そのため、私たちが書いた内容や提示した情報については、前向きな姿勢を取りましたが、今日行われたデモは現実に基づいているため、信頼できるはずです。

もう一つは、この講演では Claude Code を使用しましたが、この情報はエージェントに依存しないということです。

これは考え方のようなものなので、アプリを構築する際に好んで使用するあらゆるものに適用できます。

そこで、自律型エージェントのチームを管理し、成功に導く方法について考えてみましょう。

機能の実装などに失敗したとき、あきらめて「AI にはまだできない」と考えるのではなく、一歩引いて、どの情報が欠けていたのかを考え、今日のバグの扱い方と同じように扱う必要があります。

これらのエージェント ハーネス（Claude Code、Codex、Antigravity）を開発しているチームの発表を読んだことがある方なら、彼らのチームが実際にこれらのハーネスを開発している方法がこれであることがおわかりでしょう。これを未来を垣間見るものとして捉えるなら、おそらく私たち全員が向かっている方向はそこです。

ビルダーや Android デベロッパーにとって、今ほど刺激的な時代はないでしょう。しかし、私のように、何に焦点を当てるべきかを正確に把握するのが難しいと感じている方もいるかもしれません。

デベロッパーである私たちには、インテリジェンスとともにスケールするツールとワークフローが必要です。そうすれば、新しいモデルがフロンティアを拡大しても、私たちの努力が無駄になることはありません。

モデルの改善がエージェントのワークフローのインテリジェンス向上につながり、最終的にはユーザーにとってより良い結果をもたらすことを目指しています。

本日は、4 つのトピックについて説明します。

まず、エージェントが成功できる環境を整えることがなぜ重要なのかを説明します。

次に、コンテキストの概要と、コンテキストを最適に管理する方法について説明します。

その後、エージェント内で作業する Android デベロッパーが利用できる最適なツールをいくつか紹介し、最後に、Agentic Workflows にループを追加するケースについて説明します。

それでは、詳しく見ていきましょう。

環境です。

しかし、これは実際にはどういう意味なのでしょうか。

先ほども言ったように、エージェントが成功できるスペースを作ろうとしています。ユーザーがそこに座って、常に再プロンプトして軌道修正する必要なく、成功できるスペースです。そうすることで、並列エージェントを実行できるようになり、エージェントのチームがすべての作業を代行してくれるようになると、真の生産性の向上が実現します。

しかし、それはコードにアクセスできるだけではありません。

プロジェクトの仕様や、そのプロジェクトでの作業方法に関するルールなど、正確なドキュメントにアクセスする必要があります。

これは当然のことです。

他にも、エージェントをチームのチャット スペースに接続している人もいます。これは、エージェントを起動するためだけでなく、エージェントに割り当てられた機能の開発につながった意思決定のコンテキストを提供するためでもあります。開発者が問題を解決する際に無意識に使用しているような情報をエージェントに提供することで、エージェントの作業を支援できます。

また、過去の決定履歴や pull リクエストなども含まれます。

pull リクエストに寄せられたコメントや、通知された内容などを確認して、修正作業を行うことができます。

また、デバイスやエミュレータにアクセスせずに Android コードを記述することはできないため、エージェントも同様に記述することはできません。

エミュレータは、一見すると何でもできる素晴らしいツールのように思えますが、

プロファイラについても同様です。

パフォーマンスの改善を依頼する場合は、プロファイリングができるように、実機へのアクセスを許可する必要があります。

また、アプリが使用するバックエンド サービスとも、エージェントが通信できることが理想的です。

そこで Android CLI の出番です。

「ツールの新機能」の講演でも紹介されましたが、Android CLI は、さまざまな Android ツールとのインターフェースとなる新しい CLI です。

それ自体は AI プロダクトではなく、単なる CLI（コマンドライン インターフェース）です。

Android SDK Manager へのアクセスや、エミュレータの起動など、さまざまな機能を利用できます。

また、Crashlytics などのツールやバックエンドにも接続します。

使用しているエージェントに関係なく、シェルスペースに常駐します。

そうですね。

このリンクからインストールできますが、実際に動作を確認した方がわかりやすいと思います。

それでは

そこで、エージェントを成功に導くことがいかに重要かを単に説明するのではなく、この原則を、私たちが構築した Sideline という本番環境アプリケーションに実際に適用したいと考えました。

Sideline は、テニスプレーヤー向けの Android アプリケーションで、ボールの位置、プレーヤーの位置、コートの位置に関するリアルタイム フィードバックを提供します。

ビデオ再生によるオフラインのコーチング フィードバックを提供し、最高速度、移動距離、最長ラリーなどのフィットネス データを提供します。

これらはすべて、Android デバイス上で直接実行されるカスタム TF Lite モデルによって実現されています。

まず、存在を把握していない問題を解決することはできないということをお伝えしたいと思います。

そこで、Android CLI を使用して Firebase Crashlytics を開発環境に追加したところ、それまで発生していることに気づいていなかった問題がいくつか見つかりました。

1 つ目は、Google Pixel 11 Pro Fold デバイスでアプリケーション応答なし（ANR）エラーが発生したものの、エミュレータでは再現されなかったというものです。

幸いなことに、Android CLI は Android デバイス ストリーミングをサポートしています。

この問題を修正するよう指示すると、エージェントは ANR が発生していたデバイスへの接続を作成しました。これは特に便利でした。当時、私は修正を検証するための Google Pixel 11 Pro Fold を持っていなかったからです。

このように、修正の検証に必要なデバイスにアクセスする機能をエージェントに付与することで、最終的に、可能な機能セットを拡張することができました。

時間を節約するため、すべてのテストを事前に実行し、ここにまとめました。

詳細には立ち入りませんが、私たちが抱えていた問題は、Android 17 に関連するアフィニティ コールでした。

2 行の簡単な修正で、問題ないように見えました。

setenv("KMP_AFFINITY", "disabled", 1);
setenv("KMP_INIT_AT_FORK", "false", 1);

そこで、pull リクエストを作成してマージし、Google Play に送信した新しいビルドで更新しました。

つまり、成功に必要な機能を備えたコーディング環境をセットアップしていなければ、実際の問題を特定することも、修正を検証することもできなかったでしょう。

1.0 ビルドでは、問題が解決されていることがわかります。

しかし、新たな問題が発生しています。これについては後ほど説明します。

それでは

次はコンテキストです。

1 年半から 2 年ほど前、それほど昔ではありませんが、AI の世界では大昔のことです。コンテキスト ウィンドウをどんどん大きくする競争がありました。モデルに投入できる情報が多いほど、より良い結果が得られるという理論でした。私たちは、developer.android.com 全体をプロンプトに含めようとするなど、無茶なことをしていましたが、うまくいきませんでした。

しかし、コンテキスト ウィンドウがほぼ横ばいになっているにもかかわらず、モデルの機能は依然として向上しています。

これが Android Bench 1.0 です。

Android Bench は、AI が Android コードを記述する能力をベンチマークする Google のベンチマークです。

タスクは現実的なものです。

これらは、皆さんが取り組んでいるようなことです。コンテキスト ウィンドウは 100 万のマークで横ばいになっていますが、モデルの能力は向上し続けています。

しかし、コンテキストは依然として固定予算であり、重要なもののために節約したいと考えています。

取り組んでいる問題の解決に役立たないものは、そこに含めたくないでしょう。

多くのエージェント ハーネスは、100 万のコンテキスト ウィンドウをすべて公開しているわけではありません。それは無意味だと考えているからです。

そうすると、結果は悪化するだけです。

実際には、モデルによって異なるスイートスポットがあります。会話を約 150,000 トークンに抑えることができれば、コンテキストの劣化なしにモデルの能力を最大限に引き出すことができます。

しかし、コンテキストは入力内容だけではありません。

[
  {
    "role": "system",
    "content": "You are an expert Android engineering agent..."
  },
  {
    "role": "workspace_context",
    "content": { "project_root": "/workspace/android-app", "build_system": "Gradle (Kotlin DSL)", "target_sdk": 35 }
  },
  {
    "role": "available_tools",
    "content": [ { "name": "read_file" }, { "name": "edit_file" }, { "name": "bash" }, { "name": "skill_android_cli" } ]
  },
  {
    "role": "user",
    "content": "ProfileViewModelTest is failing when loading errors. Fix the ViewModel and verify with unit tests."
  },
  {
    "role": "assistant",
    "tool_calls": [ { "name": "read_file", "arguments": { "path": "app/src/main/.../ProfileViewModel.kt" } } ]
  },
  {
    "role": "tool",
    "content": "class ProfileViewModel(...) : ViewModel() { ... // full file contents + Gradle output appended here }"
  }
]

実際には、目に見えないところで多くのことが行われています。

これは複数の部分で構成されています。

1 つ目はシステム指示です。

システム指示はエージェントによって提供されます。

これは、このエージェントの動作方法や、エージェントに求める動作を指示するプロンプトのようなものです。

また、ワークスペース情報（現在の作業ディレクトリ、使用している SDK、インストールされているスキルなど）も含まれます。これについては後ほど説明します。さらに、MCP ツールや、エージェントが提供するツールも含まれます。

モデルは、それらを呼び出せることを認識する必要があるため、コンテキストを消費します。

しかし、大きな問題は、エージェントに送信するすべてのプロンプト、すべての新しいメッセージとともに、メッセージとツール呼び出しの履歴全体が送信されることです。

特に Gradle では、この時間が積み重なって大きなものになります。

ご存じのとおり、Gradle のログは非常に長く、非常に詳細です。

そのほとんどは必要ありません。

この点に注意するための簡単なヒントがあります。

Gradle をサイレント モードで実行できます。

./gradlew assembleDebug --quiet

または、より大きなエージェント ハーネスがこれを切り捨てます。

Claude Code と Android Studio では、Gradle ログ全体を送信するのではなく、

しかし、最小限のエージェントの 1 つを使用している場合、その哲学はすべてをモデルに送信することであり、モデルが最もよく知っているため、mini-SWE-agent はその完全な Gradle ログを送信し、非常に高価になる可能性があります。

では、この 150,000 というマジック ウィンドウ内に収めるにはどうすればよいでしょうか。

その鍵となるのが、ワークフローの使用です。

ワークフローは数多く存在します。

私が特に気に入っているのは、Matt Pocock という人が作成したもので、これらのセッションを管理するのに役立つ一連のスキルが用意されています。

まず、「grill-me」というスキルから始まります。

このスキルは、プロジェクト全体またはプロジェクト内の新機能を開始するときに実行します。これにより、エージェントがさまざまな質問をします。

「質問して」と言ってみてください。

アプリに新しい時間アラーム マネージャーを構築したいと考えています。」

すると、何を実装すべきか、どこに属しているかなど、質問を返してきます。

そして、問題の曖昧さをすべて排除し、頭の中から問題へと落とし込みます。

次に、大きな仕様書を作成するスキルを実行します。

別のスキルがそれを問題に分割し、ユーザーが好む問題マネージャーにそれらを提出します。

そして、各問題が 150,000 のウィンドウにほぼ収まるようにします。

そして、そこから 1 つの問題を選択します。ターミナルでも IDE でも、お好みの方法で作業できます。ビルド、検証ループ、最後にコンテキストをクリアします。会話履歴はもうありません。ウィンドウ内に留まります。

それでは

次に、AGENTS.md について説明します。

AGENTS.md では、このプロジェクトまたはワークスペース全体でエージェントが取り組んでいる問題に適用される追加情報をエージェントに提供できます。

ただし、すべてのプロンプトに提供されるため、常に適用されるものだけに限定することが重要です。

そのため、アーキテクチャ ルールやモジュール ルールなどが有効です。

これらは、特にクローズド ソースアプリを開発している場合、エージェントが知り得ない情報です。

しかし、この機能がどこに属しているかについて最初に推論するのを省くために、理解しておくことが非常に重要です。

そのため、デザイン システム モジュールに属する UI コンポーネントなどの要素を配置できます。また、コードレビューでよくある間違いや、よくある要素を配置して、いつでも入力できるようにすることもできます。

# AGENTS.md

- UI components belong in :core:designsystem

- Never use java.util.Date;
  always use kotlinx.datetime

## General guidance
- Avoid changing public API signatures. Anything under an `internal` directory
  is not part of the public API and may change freely.
- The SDK code is written for Java 8.

たとえば、このプロジェクトでは kotlinx.datetime を使用することをおすすめします。

常に適用できるベスト プラクティスを提供したいと考えていましたが、実際にはモデルのリリースごとに変化します。

追加のコンテキストに関する動作は、モデルによって異なります。

たとえば、Opus 4.6 の時代には、「絶対にしないでください」という大きな大文字がよく使われていました。

そして、Opus 5 がリリースされたとき、Anthropic は「実は、大文字はもうあまり効果がありません。

小文字を使用してください。」

つまり、常に最新の状態に保つ必要があります。

ただし、普遍的なルールとして、短くまとめることが挙げられます。

そのため、250 行程度に抑えてください。

次のものは、少し意見が分かれるかもしれません。多くの人が好んで行っていることですが、今年 2 月に発表された研究によると、エージェントに独自の AGENTS.md を変更させると、パフォーマンスが約 2 ～ 3% 低下することがわかりました。これは、それほど大きな問題ではありません。

しかし、重要なのは、費用が 20% 増加したことです。

つまり、エージェントに独自の AGENTS.md を記述させたことで、パフォーマンスがわずかに低下し、コストが急増しました。

この問題を回避する方法として、エージェントに各 pull リクエストの最後に振り返りを書かせ、チームとして振り返りを行う際にそれらをすべて読み、どのような変更を加えるかを決定するという方法があります。このファイルは、エージェントを使用する大規模なチームで作業する場合、重要なチーム インフラストラクチャの重要な要素となるためです。

簡単に説明すると、こちらが作成した Sideline アプリケーションの AGENTS.md です。

ここで注目していただきたい点が 2 つあります。

1 つ目は、明確に定義されたアーキテクチャを使用することで、トークンを節約し、コンテキストの長さを短縮できることです。

基本的に、これにより、エージェントがコードベースを常に詳しく調べて推論を重ねる必要がなくなります。

従うべきガイドラインが明確に定義されています。

2 つ目は、特にクローズドソース アプリケーションに関するものです。

当然ながら、クローズド ソースの場合、エージェントの LLM はコードベースでトレーニングできません。

そのため、このような場合は、AGENTS.md のクリーンアップ、確認、改良、改善に時間をかけ、サイクルを繰り返すことが特に重要です。長期的には、その方がメリットがあるからです。

AGENTS.md にすべてを配置するべきでないとしたら、エージェントやモデルの動作をどのように変更すればよいのでしょうか。

1 つ目はフックです。フックは、AGENTS.md に記述するような処理（たとえば、記述が完了したら常に linter を実行するなど）に非常に適しています。

// settings.json

"hooks": {
  "Stop": [{
    "command": "./gradlew lintDebug"
  }]
}

それがフックになる可能性があります。

フックとは、エージェントがサブスクライブ可能なすべてのイベントを公開するもので、考えられるほぼすべてのイベントに対応しています。主なイベントは、セッションの開始、セッションの停止、ファイルの読み取りと書き込みです。

そのため、AGENTS.md の下部に「常に linter を実行する」や「完了を宣言する前に常にテストスイートを実行する」と記述する代わりに、決定論的なスクリプトを実行できる停止フックを使用することで、AI のわずかなランダム性を抑制できます。

もう 1 つは、エージェントに読み取りや書き込みをさせたくないファイルがある場合です。たとえば、サーバーに送信したくないシークレット ファイルがある場合や、AGENTS.md にエージェントが書き込みできないようにしたい場合、そのためのフックを設定できます。

読み取りまたは書き込みのフックがあり、編集しようとしているファイルが渡されると、「いいえ、それはできません」と返すことができます。

これは、決定論を追加する方法にすぎません。

次はスキルです。

そして、AGENTS.md をフックに変換するスキルが実際にあります。

それはまったく別の話です。

しかし、スキルは、関連性がある場合にのみコンテキストを追加する方法です。

AGENTS.md は、常に重要なものに使用します。

スキルは、特定の状況（主にドキュメント）に関連するものです。

スキルは、名前、説明、本文の 3 つの部分で構成されています。重要なのは、説明が 1,024 文字に制限されていることです。

---

name: android-cli
description: >
  Loaded into context (≤1024 chars)
---
# Skill Body

本文は膨大な量になることがあり、他のスクリプトが含まれることもあります。これはよくあることです。

スキルを使用すると、さまざまなことができます。

例を見てみましょう。

これは Android CLI の説明です。

すべてを読む必要はありません。

Android CLI がどのような場合に役立つかを示す簡単な説明のようなものだと考えてください。

そして、これが本文です。

これは巨大なため、常にすべてを読み込むことは避けたいですよね。

このライブラリは、Android CLI を使用する場合にのみ読み込む必要があります。スキルを使用すると、これを実現できます。

ただし、インストールするスキルを慎重に選ぶことが重要です。

オンラインで見かける、何百ものエージェント エンジニアリング スキルを含むリポジトリを、やみくもにインストールしたくはありません。

1 つ目は、セキュリティ リスクが非常に大きいことです。

これらのスキルに何が含まれているかはわかりません。エージェントに何でもするように指示している可能性があります。

Android のスキルセットもあります。審査済みですが、そのようなことは書かれていません。

2 つ目は、100 個の説明に 1,000 文字を掛けると 100,000 文字になり、コーディングを始める前にこれだけの文字数を追加することになります。

すでにその期間に近づいています。

そのため、Android スキルでは、Android CLI ベーススキルをすべてインストールすることをおすすめします。そこから、Android CLI は利用可能なスキルを検索し、アプリに適したスキルをインストールできます。

> android init

✓ Installed base skill: android-cli

# Audit & add skills only when needed:
> android skills find compose
> android skills add edge-to-edge

また、どのようなスキルが利用可能かを知っておくのも良いでしょう。Compose スキルやエッジツーエッジ スキルなど、プロジェクトに適したスキルを手動で追加できます。これらはかなり汎用的なスキルです。

もちろん、スキルを監査するスキルもあります。

Claude Code には /skill-doctor があり、これを使用すると、有効化されていないスキルが含まれていることがわかります。つまり、1,000 文字の説明が無駄になっているということです。

Claude Code を使用していない場合でも、ほとんどのエージェント ハーネスには、同様の処理を行うための統計画面や監査画面が用意されています。

Android CLI のリンクはこちらです。

しかし、スキルリスト コマンドがあり、プロジェクトに Navigation 3 があるとします。

android skills list
android skills add navigation-3

Navigation 3 はかなり新しいライブラリであるため、まだトレーニングが十分に行われていません。Navigation 3 のスキルを追加できます。

よくあるのは、

次は MCP です。

しかし、「なぜ Android CLI を MCP サーバーではなく CLI にしたのか」という質問をよく受けます。

CLI は、AI が登場するずっと前、マウスさえ存在しない頃から構築されてきました。そのため、高速で、コンポーズ可能であり、シェル セッションでローカルに実行されるため、実質的に無料で実行できます。

また、Terminal Bench のようなベンチマークは、ソフトウェア エンジニアリングにおいて最大のベンチマークとなっています。そのため、モデル メーカーはターミナルの使用に対して積極的に取り組んでおり、最近では CLI の使用に非常に長けています。

しかし、MCP が不要になるわけではありません。

MCP サーバーは、すでに使用している外部サービスに最適です。特に、すでに MCP サービスをホストしている場合はなおさらです。

直接接続できるため、インストール不要でエージェントにコンテキストを追加できます。

GitHub、Figma、Slack などが MCP サーバーを公開しています。

これまでシェルで実行していたものは、シェルに残すことができます。Android CLI を介した Android コマンドだけでなく、Perfetto や Gradle も、開発で使用するすべてのものにアクセスできるローカルに置くのが理にかなっています。

以前はパフォーマンスの改善に取り組んでいました。

私はいつも、Perfetto はあらゆるパフォーマンスの問題を解決するために必要な唯一のツールだと言っていました。

しかし、学習曲線は非常に急でした。これは、先ほどの Rahul の講演でも触れられていました。

AI がパフォーマンスの向上にどのように役立つかを見てみましょう。

ありがとう、Ben。

そのため、Sideline アプリケーションを動作させるには、30 フレーム/秒でリアルタイムに実行する必要があります。

この Google Pixel 10 Pro Fold では、1 秒あたり約 20 ～ 22 フレームしか達成できていません。

このフレーム落ちが問題になります。アプリケーションが宣伝どおりに動作しないことを意味するため、この問題を修正する必要があります。

Android CLI には、Android プロファイラコマンドが用意されています。

これをコーディング エージェントに追加し、30 フレーム/秒の要件を満たすように指示すると、2 つの興味深いことが起こります。

1 つ目は、Android Profiler コマンドを使用して修正を見つけることです。

接続された Google Pixel 10 Pro Fold デバイスでシステム トレースを記録したところ、AI スレッドがデバイスの最も遅いコアで実行されていることがわかりました。

2 つ目は、Android ドキュメント検索を使用したことです。興味深いことに、私たちが明示的に指示したわけではないのに、Performance Hint API の公式ガイダンスを取得しました。

エージェントはシステム スケジュールを最適化することを学習し、それによって 1 秒あたり 30 フレームの要件を満たすことができました。

つまり、基本的には、ガイダンスに沿って修正が行われたということです。

Android CLI の重要な点は、エージェントに接続することで、そのツールに詳しくなくても、達成する必要があるタスクに適したツールを見つけられることです。

実行すると、Sideline がユーザーの要件である 30 フレーム/秒を満たし、Google Pixel 10 Pro Fold で動作するようになったことがわかります。

それでは

次に、これらをループでまとめます。

エージェントに大きな変更を実装するよう依頼すると、完了したという返答が返ってきます。

アプリをインストールして、手動でクリックしてバグを報告するようなことは、やめる必要があります。

エージェントの QA テスターになるのをやめ、何をもって完了とするかを事前に定義する必要があります。

例を挙げましょう。

プロジェクト全体を Nav3 に移行したいと伝えると、エージェントはしばらく姿を消しますが、自信を持って戻ってきて、「移行が完了しました。

私が一番だ。」

しかし、スマートフォンを回転させると、アプリがクラッシュし、スライドの遷移がすべて失われ、Gradle ファイルがクリーンアップされませんでした。

これは、現在の世界に似ています。

理想的には、このようなことをする必要がないのが望ましいのですが、これが現在の現実です。

そのため、期待する内容を事前にすべて定義しておく必要があります。そうすれば、エージェントはそれらの条件をすべて満たすまでループできます。

これが検証ループです。

この効果については、非常に強力なデータがあります。

これが Android Bench 2.0 です。このセッションの冒頭で紹介した AI ベンチマークの新しいバージョンです。

現在の合格率は約 40% です。

これらのタスクは非常に難しく、非常に大規模で現実的ですが、そのうちの 1 つは Nav2 から Nav3 への移行であり、これは皆さんが現在プロジェクトで行っているようなことです。

Fable 5.1 の場合、合格率は 22% です。これは、「Nav2 を Nav3 に移行する」などの自然なプロンプトを設定した場合の合格率です。

しかし、事前に失敗するテストスイートを与えると、これは答えを与えるのではなく、Nav3 への移行方法を教えるのではなく、すでに失敗しているテストスイートを与え、それらのことがすべて完了すると合格するテストスイートを与えると、ベンチマーク全体の合格率は 90% に跳ね上がります。

このことからわかるのは、これらのモデルは、私たちが思いつくほぼすべての Android タスクを実装できるようになったものの、「完了」の意味を常に理解しているわけではないということです。

そのため、事前に失敗するテストスイートを完全に作成する必要はありません。

検証ループは、プロンプトの追加と同じくらいシンプルにできます。

たとえば、UI で作業しているときに、Compose プレビューをレンダリングして Figma の仕様と一致していることを確認し、結果を表示するように指示できます。

「完了しました」というテキストの回答を受け入れるだけでなく、結果を表示して完了したことを証明するよう求めると、本当にうまくいくようです。

ビジネス ロジックに取り組んでいる場合は、ユニットテストを実行するよう指示できます。また、冒頭で見たように、クラッシュの修正に取り組んでいる場合は、リモートテストラボを介して、クラッシュが発生した実機でクラッシュが修正されたことを検証するよう指示できます。

実は、Claude Code には検証ループの構築を支援するスキルが組み込まれています。

ぜひご確認ください。

また、Android Studio で独自の AI エージェントを使用している場合は、Android Studio が提供するさまざまなツールを使用して、作業内容に応じたループを構築できます。

たとえば、linter のように、すべての lint エラーが修正されるまで停止しないように指示できます。また、私が特に気に入っているのはジャーニーです。ジャーニーを実行して、機能していることを確認するように指示できます。

また、ジャーニーを記述している場合（ジャーニーは記述が非常に簡単で、作業中の機能に関するプロンプトにすぎません）、そのジャーニーを実行して、完了を宣言する前にパスすることを確認するように指示できます。

ただし、ジャーニーの実行には時間がかかります。

また、検証ループのレベルを階層化することもできます。

そこで、まず単体テストと Compose プレビューがすべて正しくレンダリングされていることを確認するよう依頼します。

そして、それが合格したら、接続テストと Android Journeys を実行し、それが合格した場合にのみ、リモート デバイス テストラボのような、何時間もかかる完全なテストスイートを実行します。

この追加情報を与えると、各実行で各ステップを実行しようとするのではなく、階層ごとにループすることがわかります。

モデルは非常に自信に満ちているからです。

そのため、常に完成していると考え、最初のテストですべて合格すると考えています。

では、Sideline で見てみましょう。

このアイデアを Sideline アプリに適用してみましょう。具体的には、近日公開予定の XR グラス向けの新機能を追加します。

まだハードウェアがないため、XR エミュレータを使用して、コーディング エージェントに新しいフォーム ファクタ向けに Sideline を拡張するよう指示します。

その際、エージェントに JVM テスト、Compose プレビュー テスト、エミュレータ テストの順にループするよう具体的に指示します。

各ループは、前のループを基に構築するように指示されます。

このとき、まず気づくのは、ループ 1 と 2 の間で、6 つの Compose プレビュー状態を定義するために使用されているのが JVM テストであるということです。

もちろん、エミュレータは呼び出されないため、非常に高速に実行されます。

同様に、ループ 2 とループ 3 の間では、長い文字列などの問題が、エミュレータを実行する前に検出され、修正されます。

最後に、エミュレータ ループが実行されると、JVM テストと Compose プレビューでは修正できなかった追加のバグが見つかります。

しかし、基本的には、ループごとにアプリケーションをさらに強化します。最初に最も高速で最も強力でないループを実行し、次に最も低速で最も強力なループを実行します。

結果は次のとおりです。

この動画では、メガネにスイングの種類とラケットから放たれたボールの速度が表示されています。これにより、ボールから目を離さずにテニスをプレイしながら、リアルタイムでゲームプレイに関するフィードバックを得ることができます。

先ほど、以前に発生した 2 つの Crashlytics の問題について説明すると言いました。

このアプローチが機能することはすでに検証済みなので、Claude Code の /schedule コマンドを使用してループ処理を行い、任意の頻度を設定できます。これにより、すべてのバグを修正し、修正されたことを検証して、エンジニアに pull リクエストとして送信し、確認とマージを依頼する自己修復アプリケーションが実現します。

いいですね

本日の内容は以上です。

重要なポイントを 1 つ挙げるとすれば、エージェントが成功する環境を構築し、ソフトウェア開発やバグへの対処と同じように扱う世界について考え始めることです。

このようにして、パラレル エージェントを有効にします。

このトピックに関するアドバイスは、オンラインでたくさん見つかりますが、その多くは互いに矛盾しています。

これは、この急速に変化する環境の現実です。

そのため、プロジェクトに独自の評価を作成することをおすすめします。

そして、新しいアドバイスや新しいモデルが登場したときに、実際にそれを測定して、それが役に立つかどうかを確認できます。

そしてもちろん、あらゆることにスキルが必要です。

Claude Code で評価を構築するのに役立つスキルがあります。

/claude-api build-eval

ぜひご覧ください。

本日は Android Bench についてお話ししました。

Android Bench は Google の評価です。

これは、状況が改善されていることを確認するための測定方法です。

このベンチマークを構築する際に得られた教訓を参考に、同じ間違いを繰り返さないようにしたい場合は、Android Bench の講演をご覧ください。

2 つのパネルもあります。

1 つは米国に、もう 1 つはロンドンにあります。

どちらも、コミュニティで実際にこの種のコンセプトについて話しているオンラインにアップされています。

そこで、Android デベロッパー コミュニティのメンバーをパネルに迎え、この原則を仕事でどのように実践しているかについて話してもらいます。

また、皆様からのフィードバックをお待ちしております。

Google が開発しているものが実際に役立っているかどうかをぜひお聞かせください。

アンケートにご協力ください。

この画面はそのままにしておきます。

そして、

ご覧いただきありがとうございました。

ありがとうございました