6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【AWS re:Invent 2025】Deliver GenAl Mobile Apps and Models at scale: A Testing Architecture(DVT323)レポート

Posted at

はじめに

AWS re:Invent 2025に参加し、Deliver GenAl Mobile Apps and Models at scale: A Testing Architecture(DVT323)を受けたので、そのレポートを残します。

セッションの内容

Agendaは、以下の5つでした。

  1. Benchmarking GenAI apps
  2. Real Devices vs Emulator/Simulator
  3. AWS Device Farm
  4. GenAI driven testing platform
  5. Optimize and Test AI Models at scale Qualcomm AI Hub

image.png

この記事では、上記のAgendaごとにまとめず、セッションを聞いて重要だと思った点を以下のように分類しています。

  1. 生成AIモバイルアプリのベンチマークとAWS Device Farm
  2. 生成AIを使ったテストの自動化(実例付き)
  3. オンデバイスAIモデルの最適化

ここからは、上記の分類別に内容をまとめていきます。

生成AIモバイルアプリのベンチマークとAWS Device Farm

最初のパートでは、モバイルAIアプリの性能をどう測るかについてと、それを実行する環境についてのお話でした。
まずはじめに、生成AIモバイルアプリは単一のものではなく、以下の3つのタイプに分類して定義される、というお話がありました。

  1. オンデバイスモデルを持つ(オンデバイスモデル+バックエンド)アプリ
    • アプリ内にモデル(TFLiteやCore ML形式など)を持ちつつ、API経由でバックエンドとも連携するタイプ
  2. バックエンド依存型アプリ
    • デバイス自体にはモデルを持たず、バックエンドにAPIコールを行い、バックエンド側でAIサービスを利用するタイプ
  3. 自己完結型(Self-sustained)アプリ
    • ネットワーク通信を行わず、デバイス上のモデルだけで完結するタイプ

そこを前提として、生成AIモバイルアプリでは、以下を指標として性能を測るべき、とのことでした。

  • アプリの起動時間(初回起動と2回目以降は区別するべき)
  • 推論時間(=AIが回答を出すまでの時間)
  • メモリ使用量(ピーク時と常駐時)
  • トークンパフォーマンス(最初のトークンが出るまでの時間や、1秒あたりの生成トークン数)

image.png
(ブレブレの画像ですみません…)

また、測定のコツとして、以下が挙げられていました。

  • ウォームアップとしてテストを10〜15回実行してから、本番の計測(例:100回)を行うべき
  • 結果は平均値だけでなく、P50(一般的なユーザー体験)とP95(最悪のケース)を見て、パフォーマンスのブレを確認すべき

上記をテストするためには、開発初期はエミュレータやシミュレータが適しているが、リリース前のユーザー体験の確認には、実機(AWS Device Farm)などが不可欠になってくる、という話でした。

image.png

生成AIを使ったテストの自動化(実例付き)

このパートでは、Amazonのショッピングアプリ開発チームが、テストをする際に、LLMをどのように活用しているかという実例を踏まえたお話が出てきました。

内容は、以下のものでした。

  • 課題:Amazonには1万人のエンジニアがいるが、そのテスト環境がバラバラで、テストが頻繁に壊れるという問題があった
  • 解決策:従来のようにコードでテストを書くのではなく、自然言語で指示できるようにし、LLM自体にアプリを操作させる手法に移行した

デモでは、その解決策を実際にお見せしてくれました。

image.png

デモの内容は、LLMに「Amazonのサイトにいって、ハリーポッターの本を検索して、カートに入れなさい」と指示してテストする、というものでした。
LLMが「検索バーはここにある」→「ハリー・ポッターと入力」→「検索ボタンを押す」と判断していく様子が紹介されました。 また、「カートに入れるボタン」を探したけど見つからなかった時に、エラーにするのではなく、「スクロールすればボタンが出てくるはずだ」と自分で判断してスクロールし、テストを成功させた事例も挙げられていました。
上記の事例は、通常のコードで書くテストでは、失敗と見なされてしまうと思うので、柔軟性の高さに驚きました。

オンデバイスAIモデルの最適化

最後のパートは、スマホ本体でAIを動かすための最適化についてのお話でした。

image.png

すべてをスマホ本体で動かすのではなく、小さなモデル(30億〜50億パラメータ)はスマホで動かし、複雑な処理が必要な場合だけクラウドの巨大なモデルに送る「ハイブリッド構成」が主流であるというお話がありました。

また、クラウドで訓練したモデルを、実際のスマホ(Snapdragon搭載機など)で動かした時にどれくらいの速度やメモリで動くかを、コードを書かずに計測できる「Qualcomm AI Hub」という無料ツールの紹介もありました。これによって、モデルの精度と動作速度のバランスを実機ベースで調整できるとのことでした。

おわりに(感想)

生成AIアプリは、クラウドとデバイスのハイブリッドなシステムであり、その品質を保証するためには「LLM自身を使ってアプリをテストする」という新しいアーキテクチャと、「実機での厳密なパフォーマンス測定」が不可欠である、ということがわかりました。
また、話を聞いていて、AWS Device Farmと、「Remote TestKitと何が違うの?」と思い、調べてみました。

少し前のものにはなりますが、上記の記事によると、

Remote TestKitはより自分で操作して動きを細かく確かめたい時に真価を発揮しますし、
AWS Device Farmはテスト自動化を推進するときに真価を発揮すると思います。

という違いが大きな部分としてあるとのことでした。
今回のようなケースでは、確かにAWS Device Farmが適しているなと思い、納得しました。

最後までご覧いただきありがとうございました!

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?