Android Studioで好きなAIエージェントを使う：BYOAが開発者に与える変化

要点：Android Studioはエージェントの作業環境になる

Googleは2026年9月24日、Android Studio CanaryでBring Your Own Agent（BYOA）のプレビューを発表しました。開発者はClaude Agent、OpenAI Codex、Google Antigravityを接続でき、Android StudioはプロジェクトのコンテキストとAndroid向けツールを提供します。重要なのはメニューにモデルが増えることだけではありません。IDEが共通の作業面となり、複数のエージェントがプロジェクトを調べ、ビルド診断やCompose Previewを使い、エミュレーターを操作し、作業を開発者へ戻せるようになります。

エージェントを選びやすくなる一方、評価は重要になります。コーディングエージェントは最初のコードの見栄えではなく、Androidの仕事全体を安全かつ安定して完了できるかで判断すべきです。開発ツールを比較するなら、BTTCソフトウェアディレクトリでコーディング、仕事効率化、テスト関連のソフトも探せます。

BYOA発表で変わること

Android Developersの公式発表によると、BYOAはAndroid Studio Rabbit 2 Canaryでプレビュー展開されます。最初にClaude Agent、Codex、Antigravityが紹介され、Settings > Tools > AI > Agentsの登録画面からACP対応エージェントを追加できます。Android Studio内蔵のGemini体験も継続しますが、最新のGemini体験や関連プラン、APIを使いたい場合はAntigravityが推奨されています。

実際の変化は、単一ベンダーのアシスタントから複数プロバイダーのワークフローへ移ることです。大規模なリファクタリングには一つのエージェント、リポジトリ探索には別のエージェント、機密コードにはローカルまたは企業管理の選択肢を使えます。利用枠に達したり特定の作業で結果が悪かったりしても、プロジェクト全体を作り直さずに切り替えられます。

ただし、BYOAが料金プランや機能を統一するわけではありません。ログイン、利用枠、提供地域、ツール権限はプロバイダーごとに異なります。同じコードベースと受け入れ条件で比較できる点が、プレビューの現実的な価値です。

モデル名よりIDEのコンテキストが重要な理由

Androidプロジェクトには、一般的なチャット画面が自動では把握しない情報があります。Gradle設定、ビルドバリアント、Manifest、生成ソース、リソース修飾子、Compose Preview、SDKレベル、エミュレーターの状態、端末ごとの差です。Googleは、Android Studioがプロジェクトグラフやビルド設定をACP対応エージェントへ渡し、関連ファイルに集中させると説明しています。

多くの失敗は構文エラーではありません。Kotlinとして正しくても、ライフサイクルを誤り、flavorを無視し、Previewを壊し、権限を忘れることがあります。診断機能とAndroidツールを使えるIDEなら、パッチを出す前にエージェントが仮説を検証しやすくなります。

Android Studio Quail 4の更新もこの方向を示します。組み込みのAndroid skills、プロファイリングや移行のワークフロー、ローカルGemma、多段階作業後の変更サマリーが紹介されています。長期的な差はモデル名だけでなく、エージェント、専門知識、ツール、レビュー画面の組み合わせから生まれます。

複数エージェントを安全に試す方法

使い捨てブランチと範囲の狭いタスクから始めます。依存関係を一つ更新する、小さなCompose画面を追加する、再現可能なテスト失敗を直す、性能トレースを説明する、といった作業が適しています。プレビュー版に本番の秘密鍵、リリース署名鍵、顧客データ、デプロイ環境への無制限アクセスを与えてはいけません。

各エージェントに同じプロンプトと成功条件を与え、次を記録します。

1. 過剰な指示なしで関連モジュールとファイルを特定できるか。
2. 広い変更の前に計画を説明するか。
3. 正しいGradleタスクを実行し、失敗を解釈できるか。
4. 必要に応じてCompose Preview、エミュレーター、Android診断を使うか。
5. 依頼した範囲を守るか。
6. レビュー可能なdiffと再現可能な検証コマンドを残すか。

速度だけでなく権限も測ります。最初は読み取りを許可し、書き込みは段階的に開放します。ネットワークや破壊的なコマンドには確認を要求し、停止とロールバックの手段を残します。ログ、diff、テスト結果、承認点が保存されて初めて、プロバイダー切り替えが役に立ちます。

Claude Agent、Codex、Antigravity、ローカルモデルをどう選ぶか

ベンチマークだけで決めず、仕事と制約を合わせます。

• リポジトリ規模の変更： 計画、コードベースの探索、長期コンテキスト、失敗後の復旧を重視します。
• UI作業： Kotlinを書くだけでなく、Compose Preview、エミュレーター、画面キャプチャ、アクセシビリティ確認を使えるか見ます。
• 機密プロジェクト： 企業管理、データ処理、ネットワーク方針、監査ログ、ローカルモデルの品質を比較します。
• 費用重視： token、サブスクリプション枠、API料金、待ち時間、人間のレビュー時間を合わせて測ります。
• 混成チーム： ログインと権限の境界が明確なACPワークフローを選び、未承認の個別統合を増やさないようにします。

最適解は一つの勝者ではなく組み合わせかもしれません。低リスクの変換はローカルモデル、難しい推論はクラウドエージェント、結果の確認はAndroid向けワークフローという分担です。IDEは引き継ぎを見えるようにし、制御できるようにする必要があります。

プレビューで確認する点

BYOAはプレビューのため、Canaryやプロバイダーの更新で挙動が変わる可能性があります。共有プロジェクトで使う前にアップグレードをテストし、権限、コンテキスト制限、料金、認証、セッション保存を確認してください。

便利さと正しさも分けて考えます。エージェントがエミュレーターを操作できても、すべての端末で動く証明にはなりません。生成パッチはレビューの代わりにならず、ビルド成功だけでアクセシビリティ、プライバシー、電池、ローカライズの問題が消えるわけでもありません。静的解析、単体テスト、UIテスト、人間のレビュー、リリース確認を残しましょう。

よくある質問

BYOAは安定版でも利用できますか？

公式発表はAndroid Studio Rabbit 2 Canaryからのプレビュー対応を説明しています。導入前に現在のAndroid Studioプレビューチャンネルを確認してください。

BYOAでClaude、Codex、Antigravityは同じになりますか？

いいえ。モデル、プラン、権限、制限、ワークフローは異なります。BYOAは共通のAndroid Studio画面を提供しますが、プロバイダー固有の差は残ります。

ローカルエージェントなら必ず安全ですか？

自動的に安全になるわけではありません。コードの外部送信や利用枠への依存を減らせても、権限、品質、パッケージの出所、ログ、実行可能なコマンドは確認が必要です。

小規模チームは何から始めるべきですか？

可逆的な作業を一つ選び、使い捨てブランチで同じ条件のもと二つのエージェントを比較します。リリース、インフラ、ユーザーデータに影響する書き込みには人間の承認を残してください。

まとめ

Android StudioのBYOAプレビューは、Androidプロジェクトを理解し、ネイティブツールを持つIDEへ複数のプロバイダーを持ち込む方向を示します。柔軟性、豊かなコンテキスト、ベンダーロックインの軽減が利点です。一方で、重要なコードを任せる前に権限、診断、テスト証拠、費用、プライバシー、復旧を測る必要があります。IDE以外のソフトウェアを探すなら、BTTCソフトウェアディレクトリとBTTCブログも参照してください。