はじめに

株式会社レコチョクのNX開発推進部でAndroidアプリ開発をしている寺島です。

最近の開発フローにおいて、AIエージェントは欠かせない存在となりました。 私は現在、業務でCursor（Teamプラン）を3〜4ヶ月ほど運用しており、そのコード生成能力やUXには概ね満足しています。 しかし、Androidアプリ開発者として一つだけ見過ごせない課題を感じていました。 それは、 「Android StudioとCursorの2つを立ち上げなければならない」 という二重管理の手間です。 コードはCursorで書き、ビルドやエミュレータ確認はAndroid Studioで行います。 この「エディタの反復横跳び」にストレスを感じている方は多いのではないでしょうか。

現状、Cursorでも概ね満足はしているが、Android Studioとより連携がとれるエディタがないか探してみました。

そして、Webで情報収集している際に「Firebender」というツールを見つけました。 Firebenderは、 「Most powerful AI for Android」 というAndroid開発者に刺さるキャッチフレーズを掲げてました。 また、JetBrains公式のマーケットプレイスで公開されているツールであり、Android Studio（IntelliJベース）との親和性が高い事もわかりました。

そのため、今回はFirebenderというツールについて検証し、Cursorと比較しました。

本記事は、私と同じく 「Cursorの機能は好きだが、Android開発におけるツール分断（2画面運用）などに不満がある」 という方に、読んでいただけたらなと思います。

ツールの特徴とスペック

まず、それぞれのツールがどのようなものか、基本スペックと特徴を解説します。

忙しい人向けの比較表（スペック・価格・ベースIDE）

まずは、忙しい方向けに要点を比較表にまとめました。 使用できるAIモデルはどちらも豊富で、用途に合わせて選択可能です。 価格面では、個人の上位プランにおいてはFirebenderの方が高価格帯のプランまで用意されています。

※価格は執筆時点のものです。

Firebenderとは？

公式サイトで 「Most powerful AI for Android」 と謳われている通り、Androidアプリ開発のエコシステムに特化したAI開発ツールです。 最大の特徴は、独立したエディタではなく、Android Studio (IntelliJ IDEA) のプラグインとして動作する 点です。これにより、普段のAndroid開発環境を変えることなく、強力なAIアシスタントを統合できます。

Firebenderは、単なるチャットボットではなく、プロジェクト全体のコンテキストを深く理解するよう設計されています。

機能詳細

• Deep Context Awareness（深いコンテキスト理解）
  • 単一ファイルだけでなく、プロジェクト全体の構成（Manifest、Gradle、リソースファイルなど）を読み込み、依存関係や整合性を考慮した回答を行います。
  • 「なぜ RecyclerView が更新されないのか？」といった質問に対し、コードだけでなくプロジェクトの状態を踏まえて回答します。
• Actionable AI（自律的な操作・実行）
  • Run & Debug: AIがエディタ内の「実行ボタン」を押し、ビルドからエミュレータへのインストールまでを代行します。
  • Terminal Integration: ライブラリの追加などが必要な場合、ターミナルコマンド（Gradleコマンドなど）を提案し、ユーザーの許可を得て実行します。
• Smart Debugging Aids（デバッグ支援）
  • Logcat Analysis: Logcatに出力されたスタックトレースやエラーログを直接読み取ります。
  • Analyze with Firebender: エラーログを右クリックして「Analyze」を選択するだけで、クラッシュの根本原因を特定し、修正コードを提案します。
• Inline Code Editing（インライン編集）
  • コードを選択して指示（例：「このXMLレイアウトをJetpack Composeに変換して」）を送ると、エディタ上で直接コードを書き換えます（Refactoring）。
  • ショートカット（⌘+K / Ctrl+K）で素早く呼び出し可能です。
• Best Practice Generation（モダンなコード生成）
  • 「ViewModelを使ったログイン画面を作って」などの指示に対し、最新のAndroid開発のベストプラクティス（Hilt, Coroutines, Composeなど）に準拠したコードを生成します。

この中でも自分が便利そうだと感じたのはインライン編集です。コードの一部分だけを選択して、AIエージェントとやりとりをして修正を行うことができます。

Cursorとは？

公式サイトで 「The AI Code Editor」 と定義されている、VS Codeをフォークして作られたAIネイティブなコードエディタです。 既存のエディタにプラグインを入れるのではなく、エディタ自体をAI向けに再設計することで、「Tab (Copilot++)」による次世代の自動補完や、「Codebase Indexing」 によるプロジェクト全体の把握を実現しています。

Cursorの中核機能は、開発プロセス全体を加速させる以下の2つの機能です。

• Composer (Agent Mode): 「実装の代理人」として動作するモードです。自然言語での指示に基づき、複数のファイルを同時に生成・編集できます。依存関係のある変更（例：ViewModelを変えたらUIも変える）を一括で行えるのが強みです。
• Privacy Mode: 企業利用を想定し、コードを学習に利用させない「Privacy Mode」を標準で備えているのも公式が強調するポイントです。

機能詳細

• Tab (旧 Copilot++): 次世代の自動補完
  • 単なる単語の補完ではなく、カーソルの動きや直前の変更を予測して、複数行のコード修正や次の変更箇所への移動を提案します。
  • Tab キーを押すだけで、AIが提案した「変更の確定」と「次の行への移動」を連続して行えるため、ボイラープレートコード（RecyclerViewのAdapterなど）を書く際に圧倒的な速度が出ます。
• Composer (Agent Mode): 複数ファイルの一括編集
  • Cmd+I (Win: Ctrl+I) で呼び出せる強力なエディタ機能です。
  • 「楽曲リストのUIとViewModel、Repositoryを作成して」と指示するだけで、複数のファイルを同時に生成・編集します。
  • Android開発で面倒な「画面追加に伴う関連ファイルの修正（Activity, ViewModel, Layout XML）」を一撃で終わらせることができます。
• Codebase Indexing (コードベースの理解)
  • プロジェクト全体のコードをベクトル化して学習します（RAG技術）。
  • Chatで質問する際、開いていないファイルの定義や、プロジェクト独自のコーディング規約（例：変数の命名規則や共通コンポーネントの使い方）を理解した上で回答してくれます。
• Rules for AI (.cursorrules): プロジェクト固有のルール設定
  • プロジェクトのルートに .cursorrules（または .mdc）というファイルを置くことで、AIの振る舞いを制御できます。
  • Android開発なら「UIはJetpack Composeで書くこと」「非同期処理にはCoroutinesを使うこと」などを記述しておけば、毎回プロンプトで指示しなくてもAIがルールを守ってくれます。
• Model Selection (モデル選択)
  • Claude 3.5 Sonnet, GPT-4o など、その時点で最強のモデルを自由に切り替えて使用できます。
  • 「複雑なロジックはClaude 3.5 Sonnet」「簡単なコード生成は高速なモデル」といった使い分けが可能です。
• VS Code Fork (完全な互換性)
  • VS Codeをベースに作られているため、既存のVS Code拡張機能がそのまま使えます。
  • Android開発に必要な拡張機能（Kotlin, Gradle for Java, Androidなど）もマーケットプレイスからインストール可能です。

Android開発における立ち位置

Cursorは汎用的なエディタであるため、デフォルトではAndroid専用のGUI（レイアウトエディタやLogcatなど）は搭載されていません。 しかし、VS Codeベースであるため拡張性が高く、「ターミナルで ./gradlew コマンドを実行させる」ことや、「ADBコマンド経由で実機にインストールする」 といった操作をエージェントに指示することは可能です。

つまり、「Android専用の統合環境ではないが、ユーザーの指示や設定次第でビルドプロセスまで完結させられる、極めて自由度の高いAIエディタ」 と言えます。

検証：Androidで「音楽プレーヤーアプリ」を作ってみた

ここまではあくまでも公式ページに記載のある内容を簡単に説明してきました。 ここからは実際に自分が使ってみた使用感について説明できればと思います。

今回の検証では、実際にAndroidアプリを作るときにどのような違いがあるかを調べるために「音楽プレーヤーアプリ」を作成させてみました。

実際に作った音楽アプリは以下のGitHubから参照できます。 どちらのアプリも動作については実際にビルドしてみてください。 （権利上の問題で、画面の画像を一部ぼかしています。）

作成するアプリの要件

検証する前に自分なりに作成するアプリの要件を考えてみました。

• Google公式が推奨するAndroidアプリのアーキテクチャを参考にする
• Google公式が推奨するMedia3のアーキテクチャを参考にする
• Jetpack Composeを使う
• 楽曲一覧画面・プレイヤー画面・再生リスト画面は必ず作る

上記を重要な方針としつつ、細かな実装計画は以下のようになりました。 どちらのツールにも以下の実装計画を投げています。

# Project Specification: Android Music Player App

## 1. Overview
Android向けのローカル音楽再生アプリケーション。
Google公式の推奨アーキテクチャ（MAD）と、Media3ライブラリを使用し、バックグラウンド再生や再生キューの操作（並び替え・削除）に対応する。

## 2. References (Strict Compliance)
以下の公式ドキュメントに基づいたアーキテクチャで実装すること。
1.  **General App Architecture:** [Guide to App Architecture](https://developer.android.com/topic/architecture?hl=ja) (MVVM, Unidirectional Data Flow)
2.  **Media Architecture:** [Media3 Architecture](https://developer.android.com/media/media3?hl=ja) (Client/Controller  Service/Session separation)

## 3. Tech Stack
* **Language:** Kotlin
* **UI:** Jetpack Compose (Material 3)
* **Media:** AndroidX Media3 (ExoPlayer, Session, UI)
* **DI:** Hilt
* **Async:** Coroutines, Flow
* **Image Loading:** Coil (for Album Art)
* **Navigation:** Jetpack Navigation Compose

## 4. Screen Specifications

### A. Library Screen (楽曲表示画面)
* **Data Source:** `MediaStore` APIを使用し、端末内のMusicディレクトリ配下の音声ファイルを取得する。
* **Display:** 取得した楽曲をリスト表示する。
* **Sorting:** タイトル順（Alphabetical）でソートして表示する。
* **Action:** 楽曲をタップすると、その楽曲から再生を開始し、Player Screenへ遷移（またはミニプレイヤー表示）する。

### B. Player Screen (プレイヤー画面)
* **Controls:** 再生/一時停止、前の曲、次の曲、シークバー。
* **Shuffle:** ランダム再生（シャッフルモード）のON/OFF切り替え機能を実装する (`Player.setShuffleModeEnabled`)。
* **Metadata:** 現在再生中の曲のタイトル、アーティスト、アートワークを表示する。

### C. Queue Screen (再生リスト画面)
* **Display:** 現在プレイヤー（ExoPlayer）にセットされているプレイリスト（MediaItemのリスト）を表示する。
    * *Note:* 静的なリストではなく、Playerが保持している現在のキュー(`player.mediaItemCount` / `player.getMediaItemAt`)と同期すること。
* **Reorder:** リスト内の楽曲をドラッグ＆ドロップ等で並び替えできる。
    * 並び替え結果は即座に `player.moveMediaItem(from, to)` に反映させること。
* **Remove:** リスト内の楽曲を削除できる。
    * 削除操作は `player.removeMediaItem(index)` に反映させること。

## 5. Architecture & Data Flow

### Layering
1.  **Data Layer:**
    * `AudioRepository`: ContentResolverを使用して楽曲情報を取得・変換する。
2.  **Service Layer (The "Engine"):**
    * `MusicService` (extends `MediaSessionService`): ExoPlayerのインスタンスを保持・管理する。
    * Notification管理とバックグラウンド再生の維持を担当。
3.  **UI Layer:**
    * `MusicViewModel`: `MediaController` (Media3) を保持し、Serviceと通信する。
    * UIの状態（再生位置、現在の曲、キューのリスト）は、`MediaController` のリスナーから `StateFlow` に変換してComposeに公開する。

### Key Constraints for AI
* **Direct Player Access Forbidden:** UI（Composable）から直接 `ExoPlayer` インスタンスを触らないこと。必ず `MediaController` を介すること。
* **Permission:** `READ_MEDIA_AUDIO` (Android 13+) および `READ_EXTERNAL_STORAGE` (Older) のハンドリングを含めること。

## 6. Implementation Steps (Plan)

### Phase 1: Skeleton & Service
* Hilt setup, Dependencies setup.
* `MediaSessionService` の実装（ExoPlayerの初期化）。
* `MusicViewModel` で `MediaController` を接続するロジックの実装。

### Phase 2: Data Layer & Library Screen
* `ContentResolver` で楽曲を取得する `AudioRepository` の実装。
* 取得した楽曲を `MediaItem` リストとしてPlayerにセット(`player.setMediaItems`)するロジック。
* **Library Screen** のUI実装（タイトル順ソート表示）。

### Phase 3: Player Screen & Controls
* 再生/停止、シーク、シャッフルボタンの実装。
* アートワークとメタデータの表示。
* バックグラウンド再生と通知（Notification）の確認。

### Phase 4: Queue Screen (Complex)
* 現在の再生キューを取得し表示するUIの実装。
* 並び替え(`moveMediaItem`) と 削除(`removeMediaItem`) のロジック実装。
* UIリストの並び替え操作（ComposeのReorderable機能などを使用）の実装。

かなり詳細に作ってもらうような構成になっています。このマークダウンに関してはGemini 3 Proに作成してもらいました。Geminiには画面構成と使用するライブラリとアーキテクチャの指示をしました。何度かやりとりを繰り返したうえでの上記の指示書になりました。

アーキテクチャでの指示では、直接Android Developerの公式ページのURLを参照するように伝えています。

上記をもとに Firebender と Cursor に音楽プレーヤーを作ってもらったときの比較をこれから説明します。

なお、どちらのツールもインストールした状態のままを使っています。AGENT.mdやMCPなどは全く設定していません。 また、ある程度アプリが動く状態になった時点で実装を終了しています。

Firebenderで作った音楽プレーヤー

https://github.com/mnhiro/Media3PlayerFirebender

実際に作ってもらったアプリの各画面

〜一覧画面〜

楽曲の一覧画面は楽曲名とアーティスト名が表示されていて、標準な状態で作れているかなと思います。 楽曲を選択するとプレイヤー画面が立ち上がります。

〜プレイヤー画面〜

こちらはシークバーが存在していなかったです。 その他のボタンはすべて動作していて、経過時間の値は正しく表示されていました。 また、プレイヤーのデザインに関してはFirebenderの方が好みでした。意図していないデザイン調整のためマイナス評価にもなり得るとも思います。 ただ、プレイヤーのデザイン面に関してはプロンプトにて指定していなかったので、今回は評価外になりそうです。

〜再生リスト画面〜

再生リストに関しては再生中の楽曲一覧が表示できるだけで、削除も並び替えも機能しませんでした。 タップするとその楽曲が再生開始されます。

Cursorで作った音楽プレーヤー

https://github.com/mnhiro/Media3PlayerCursor

実際に作ってもらったアプリについて

〜一覧画面〜

Firebenderで作ったアプリと同様に、楽曲の一覧画面は楽曲名とアーティスト名が表示されていて、標準な状態で作れているかなと思います。 楽曲を選択するとプレイヤー画面が立ち上がります。

〜プレイヤー画面〜

ジャケットは一覧画面で表示できていたのに、プレイヤー画面は表示できていませんでした。 シークバーは自分で操作すると再生位置が変わるのですが、自動でシークしていかないような状態でした。（経過時間の表示は無しでした） また、各種ボタンは機能していました。

〜再生リスト画面〜

再生リストに関しては削除はできるのですが、並び替えができません。 また、プレイヤー画面でシャッフルした場合に、再生リスト側には反映されませんでした。 加えて、再生リストで楽曲をタップしても再生がされないです。

Round 1：実装計画（Planning）

Round 1は、実装を行う前の計画についてです。

上のmdファイルで気になる部分がないかをAskモードで確認しつつ、Planモードで計画してもらい、最終的にAgentモードで実装をしてもらいました。 どちらも同じようにモード指定ができたので、同様に指示出しを行ってます。

Cursorではアーキテクチャの状態をMermaidで図示しましたが、Firebenderの方はそのような図を出力しませんでした。実際にMermaidで作ってくれた図が以下です。この図自体は作成したアプリの再生機構のアーキテクチャを図示しています。

graph TB
    subgraph ui [UI Layer]
        LibraryScreen[Library Screen]
        PlayerScreen[Player Screen]
        QueueScreen[Queue Screen]
        ViewModel[MusicViewModel]
    end

    subgraph service [Service Layer]
        MusicService[MusicService<br />MediaSessionService]
        ExoPlayer[ExoPlayer Instance]
    end

    subgraph data [Data Layer]
        AudioRepository[AudioRepository]
        MediaStore[MediaStore API]
    end

    LibraryScreen --> ViewModel
    PlayerScreen --> ViewModel
    QueueScreen --> ViewModel
    ViewModel -->|MediaController| MusicService
    MusicService --> ExoPlayer
    AudioRepository --> MediaStore
    ViewModel --> AudioRepository
    MusicService -->|setMediaItems| ExoPlayer

また、Cursorはファイル構成も図で示してくれました。以下が実際のファイル構成です。実装計画の段階でアーキテクチャやファイル構成を示してくれるので、ドキュメントやPRの作成などの際もCursorだと大分手間が省けます。

app/src/main/java/com/example/media3playercursor/
├── MusicApplication.kt
├── MainActivity.kt
├── data/
│   ├── model/
│   │   └── AudioItem.kt
│   ├── mapper/
│   │   └── MediaItemMapper.kt
│   └── repository/
│       └── AudioRepository.kt
├── di/
│   └── AppModule.kt
├── service/
│   └── MusicService.kt
├── ui/
│   ├── navigation/
│   │   └── NavGraph.kt
│   ├── permission/
│   │   └── PermissionHandler.kt
│   ├── screen/
│   │   ├── LibraryScreen.kt
│   │   ├── PlayerScreen.kt
│   │   └── QueueScreen.kt
│   └── viewmodel/
│       └── MusicViewModel.kt

Firebenderでは、実装をすぐさまに開始してくれてエラー解決などのやり取りも早いです。しかし、実装計画時の説明の丁寧さをみると、個人的には 計画されたプランを読みやすいCursorに軍配があがりました。

Round 2：ビルドとエラー修正（Building & Debugging）

Round 2は、ビルドとエラー修正についての話になります。特にどちらもDI周りのエラーを解消するのに苦労しました。 自分のやり方が良くなかったのかもしれないですが、どちらもDI周りの設定に一番時間がかかりました。

DI導入にかかった時間はそれぞれ以下のような感じです。

• Firebender: 2時間
• Cursor: 1時間

Firebenderは Koin で、Cursorは Hilt で実装してくれました。もともとはどちらも Hilt で実装をお願いしていたのですが、会話を重ねていくうちにFirebenderの方はKoinでの実装になってしまいました。（エラーの解消方法としてどうしてもKoinを提案され、妥協してしまいました。）

また、ビルド＆デバッグで不便を感じた部分としては、 「CursorはAndroid Studioと画面を行き来が面倒くさい！！！」 という部分です。 Firebenderは特別設定無しで、エージェントとの会話中にプロジェクトのビルドやアプリのインストールまで実行してくれます。（コマンド実行の確認はCursorと同じで、実行前には実行するか確認もしてくれる。）

Firebenderの方は、エラーの内容把握からビルド＆アプリインストールまでAIエージェントとの会話中にできるので、とても便利でした。ただし、インポート周りをいじっているときは、アプリのビルドコマンドを実行する前にGradleのSyncボタンを押しておく必要はありました。（ここはAGENT.mdのようなファイルで指示すれば自動でやってくれるようになりそうな気もしてます。）

ここでの最大のポイントは、 Firebenderは画面上のウィンドウの切り替えが少なく済む という点です。

Round 2では、Firebenderに軍配が上がりそうです。 Android Studioを移動しなくて済むという点はデバッグ時にストレスがなく扱いやすかったです！

Round 3：最終的な品質と所要時間（Quality & Time Performance）

Round 3は、実装にかかった総時間とアプリの品質についてです。

それぞれの実装にかかった時間は以下のようになりました。

• Firebender: 2.5時間
• Cursor: 1.5時間

DI周りでのエラー解決にかかった時間が、最終的な実装にかかった時間に繋がっています。その点ではCursorの方がエラー解決のための手間がかからないのかもしれないです。エディタの切り替えをする必要があるが、最終的にかかる時間はCursorの方が短いことを考えると、Cursorの方が良さそう？と思ってしまいました。

また、どちらのAIエージェントも再生リスト画面については実装が中途半端な感じがしました。並び替えや削除ができず、自分の期待した機能としては少し違った状態でした。（これは自分の指示書が良くなかったのかもしれないです。）

品質的に特筆すべきだったのは、Firebenderで作ったアプリのUIがなんか少しオシャレな感じになっていたことです。

添付画像のように再生中はジャケットがアニメーションするように作られていました。

今回は実装指示の段階でデザインに関しては、指示していませんでした。 そのため、余計なデザイン調整がマイナスな評価になる場面もありそうです。（出来上がりの状態は、個人的には好みです。）

ただ、Round 3でも軍配はCursorにあがりそうです。なぜならば、今回デザインに関しては指示してなかったこと＆指示書の再現度としてはどちらのAIエージェントも同等程度だったからです。

チャットでのやり取りに差があるので、実装にかかる時間が必ずCursorの方が早いわけではないと思ってます。しかし、今回に関してはCursorに軍配があがりました。

比較まとめ：Androidアプリエンジニアはどっちを選ぶ？

ここではあくまでも自分が2つを使い比べてみて思ったことをあげて行こうと思います。 自分自身がAndroidアプリエンジニアのため、Androidアプリエンジニアとしてはどっちがいいかという点でみていきます。

以下、使った後に調べた内容で比較表を作りました。

表について簡単に説明します。Outputのトークンは倍以上の差が出ました。Tokenが少なくやりたいことを実現できたのはCursorでした。 やり取りについては大きく値が異なっています。これはコマンドを実行するか確認された際のやり取りも回数として含めています。Firebender側は実装確認のためにビルドを行います。そのため、やりとり回数が多くなってます。また、ビルドの回数は多くなっているので、実装されたコードが動かない状態なことが多かったです。Cursorの方は実装後のコードが動かないことが少なく、動作するアプリになるまでが早かったです。

やりとり時にかかったコストがFirebenderだと、1500円近くになってしまっていました。プラン上限が来るまでは大丈夫ですが、プランの上限を超えた時の費用が大きくなりそうです。 Cursor側はやりとり時のコストもFirebenderと比べると安いです。

以上の比較からどちらを選ぶかをまとめました。

Firebenderを選ぶべき人

Firebenderは、Android StudioのAIエージェントとしては特化している部分があると感じました。ビルドやアプリインストールを自動でやってくれて、エラー解決までまとめてAndroid Studio上でできる点は魅力を感じました。ただ、ビルドやアプリインストールはADBコマンドをCursorでも認識＆使用できるようにしてあげれば、同様のことが実現可能なのかと思ってます。よって、特別Firebenderを使わなくても良いのかなと個人的には思いました。今回は試せていませんが、アプリのQAをさせるモードもあるので、QAモードを使ってみるとまた意見が変わってくるのかもしれないです。また、アプリのUIに関してはFirebenderの方がより良い物を出してくれたので、Composeの実装はFirebenderに任せるような方法も良さそうです。

～要点～

• Android Studio1つで開発を完結させたい人
• アプリのビルドやインストール、デバッグなどをAIエージェントとのやりとりで解決したい人

Cursorを選ぶべき人

Cursorは、Androidアプリに限らず、その他の開発でも使い回すことができます。やはりそこが一番の強みなのかと思いました。また、実装時のMermaidでの図示はかなり役に立ちます。ドキュメントとして実装内容を残すのに、今までかけていた時間を大幅に減らせます。（FirebenderでもMermaidの図を書けるようにAGENT.mdを指定することはできるかもしれないですが、今回は設定をいじらずの検証としています。）最終的に実装にかかる時間もCursorの方が短く済んだので、個人的には今後もCursorを使うのかなと自分は思ってます。

～要点～

• 要件定義や設計図をしっかり書きたい人
• Android以外のWebフロント/バックエンドも同じエディタで書きたい人
• 実装をよりスピーディーに行いたい人
• より安くAIエージェントを使いたい方

まとめ

今回はWebで情報収集をしていて目に留まったFirebenderを触ってみて、今使用しているCursorとの差を調査してみました。 結果的にどちらか一方しか選べないよとなった場合には、値段が高い割にはまだAndroidアプリ開発に特化していると感じれない点が多いため、FirebenderではなくCursorの方が良かったです。 Cursorでは出来ていた実装計画時の図解やAndroidアプリ開発により特化したAIとしてアップデートが進めば乗り換えることも視野に入れて良いと感じました。

生成AIの発展は日々変わっていっているので、今後も動向見守りながら使うAIをうまく切り替えて行ければと考えています。 読んでいただきありがとうございました。