2025年アプリチームの AI 活用を振り返る

こんにちは、株式会社IVRy のボルドーです。
今回はこの 1年間のモバイルアプリチームの振り返りを AI 主軸で紹介します。

アプリチームとして社外への発信と交流が盛んに

私は昨年 Web Frontend Engineer としての側面でアドベントカレンダーの記事を書いていました。

昨年末にアプリエンジニアが 2人加わりモバイルアプリ開発チームが組織され、私自身もモバイルアプリ専属となりました。そして春から夏にかけて更に 2人加わりアプリエンジニアが 5人となったことで今まで人的リソースの都合でもどかしい思いを抱えながら見送っていた様々なことに手を入れることができるようになりました。弊社全体としても正社員エンジニアの人数が 2024年末の 37名から 57名へと増加しています。

Flutter コミュニティとの交流

大きな変化として Flutter コミュニティとの交流機会を持てるようになりました。

• FlutterNinjas Tokyo 2025 への協賛

  • FlutterNinjas Tokyo 2025 に参加してきました

• FlutterKaigi 2025 への参加

  • 弊社 shanonim さんが運営スタッフとして参加

  • 【参加レポート】IVRy のアプリエンジニア全員で #FlutterKaigi に参加しました

初のウェビナー

アプリチームは発足から間もないこともあり、社外の方にもっと知ってもらおうということでアプリチームとして初めてウェビナーを開催しました。

本題: AI 活用の振り返り

開発時の活用: Claude Code, Cursor, Devin, MCP etc...

社内では日々コーディング支援ツールの議論が活発に行われています。 Cursor や Claude Code の導入などは komtaki さんを中心にあっという間に導入されました。

アプリチームでも amemiya さんが中心となって AIモブプロ会 が行われており、日々ツールの使い方についてナレッジの共有が活発に行われています。

2025年は様々な MCP (Model Context Protocol) サーバーが登場し、アプリチームでも積極的に活用してきました。今後もアンテナを張り続け便利そうなものはどんどん使っていきたいと思っています。

On-Device AI の模索

FlutterNinjas Tokyo 2025 での Sasha さんの発表を契機にスマートフォンでの On-Device AI の動向を注視し、アプリチーム内でもハッカソンを開催して活用方法を模索していました。
FlutterKaigi 2025 での kyoheig3 さんの発表「モバイル端末で動く LLM はどこまで実用的なのか」にて iOS ではストア審査でのリジェクトリスクがありそうという見解が示され今のところ静観しています。

ただし、スマートフォン以外では既に十分な活路があるため後述する E2Eテストやデータ基板上では活用を始めています。

E2Eテストでの AI 活用

「電話」の E2Eテストは難易度が高く、試行錯誤の末に以下記事で紹介しているように Airtest を用いてなんとか実現することができました。

ただし、この Airtest を用いた E2Eテストは画像認識ベースでのテストのため、信頼性に課題があります。そこで前述の On-Device AI に着目し、テスト実行時のシステムログを On-Device AI に流してあるべきログが正しい順序で出ていることを確認するように改修を進めています。
具体的には、検証環境用のリリースビルドでもログを流すようにした上で、 Android では adb, iOS では pymobiledevice3 を用いてテスト実行と同時にログを収集します。そのログを AI に流して検証させるということをしています。

On-Device AI を採用した理由として（コスト面は無視できないものの）どちらかというと実行速度の面が大きいです。

• ログの検証という比較的簡易なタスクであること

• 複数のテストケースがあり、OS、アプリバージョン、端末等 複数環境で毎日実行されること

このような状況に相応しいと判断し採用しました。一方でログの成功シナリオは Claude Code を用いてソースコードと実行時ログの両面から整理させました。

これによって、上記 記事にあるような誤操作が発生してしまった際にもいち早く気付けるようになります。一度は誤操作が発生してしまっても AI アラートによって即座に気づきその後の再発防止のために画像やしきい値の調整を行うことが可能になります。

データ基盤 Databricks での AI 活用

IVRy では Databricks を社内データ基盤として採用し、2025 年 7 月から本格利用を開始しています。アプリチームでも Databricks 上にモニタリングダッシュボードを作成してチェックしています。
下記記事で紹介しているように AI に SQL を書かせ実行させることでモバイルアプリエンジニアでも手軽に高度な分析クエリが書けるようになりました。

上記は主に Firebase Analytics のログ分析クエリを AI に書かせるという内容ですが、それだけでなく Crashlytics のログを ai_query を使って分析させるということも行っています。

具体的には、E2Eテストの章でも述べた「システムログの検証」を Databricks 上でも行います。Crashlytics にはカスタムログというものも記録できるので、アイブリーアプリではこれを利用してクラッシュ（もしくはエラー）が発生した時点までのカスタムログが記録されています。
Databricks にインポートした Crashlytics の logs をまとめて ai_query で以下のように検証・解説させています。

select
  -- ユーザーがどのような操作をした際に発生したか
  ai_query(...) as ai_summary_user_operation,
  -- その操作時にあるべきログが正しい順序で出ているか
  ai_query(...) as ai_summary_logs_inspection,
  -- このエラーの原因は何か
  ai_query(...) as ai_summary_cause,
  ...
from crashlytics_logs

実際のところ ai_query を用いた分析は思うような成果が出ておらず、コンテキストの拡充に課題を感じています。その他にも AI モデルを高性能なものにすると速度が著しく落ちるため databricks-gemma-3-12b を使っているのですが、より相応しいモデルがないか検証を進めていこうと考えています。

まとめ

IVRy アプリチームの 2025年の AI 活用事例を紹介しました。

• 開発支援ツールとしての AI は存分に活用できており、引き続き積極的に活用方法を模索していく

• E2Eテストとデータ基板上でのログ分析を進めているがまだ道半ばである

• On-Device AI に注視しスマートフォンでの活路を模索している

来年も引き続き会社・チームとして AI の活用方法を模索していきたいと思います。来年も IVRy をよろしくお願いします！

IVRyでは、Advent Calendar をもう1レーン走らせています。本日は、yuri_ivry さんの『「IVRy、エンジニア入りまくってるイメージ。実際いまどんな感じ？」2025年末編』が公開されました！ぜひご覧ください。

We are hiring!

IVRyでは「イベントや最新ニュース、募集ポジションの情報を受け取りたい」「会社について詳しく話を聞いてみたい」といった方に向けて、キャリア登録やカジュアル面談の機会をご用意しています。ご興味をお持ちいただけた方は、ぜひ以下のページよりご登録・お申し込みください。