AWS Device Farm

AWS Device Farm は、AWS が運用する実機のスマートフォンやタブレット上で、モバイルアプリや Web アプリのテストとリモート操作をクラウド上で実行できるマネージドなアプリテストサービスです。多数の機種・OS バージョンの組み合わせを自前で用意せずに、実際のデバイス上でアプリがどう動くかを検証でき、自動テストの並列実行と、ブラウザ越しに実機を直接操作する手動テストの両方に対応します。

解決する課題

モバイルアプリは、画面サイズ・OS バージョン・チップ・メーカー独自のカスタマイズなど、無数の端末バリエーションの上で動きます。エミュレーターやシミュレーターだけでは、特定機種でのみ起きるクラッシュ、実機の GPU やセンサー、ネットワーク状況に依存する不具合を見つけきれません。かといって主要機種を社内で買い揃え、OS をパッチし、充電し、保管する端末ラボの運用は、台数が増えるほど大きな負担になります。

Device Farm は、この実機の調達・維持・管理をサービスとして肩代わりします。利用者はテスト対象のアプリとテストスクリプトをアップロードするだけで、AWS が保有する実機の端末プール上でテストを実行できます。多数の機種で並列にテストを走らせて互換性を一括検証したり、特定機種の不具合を実機をリモート操作しながら再現・調査したりでき、端末ラボを持たずに実機品質の検証サイクルを回せます。

主要概念と用語

• プロジェクト: テスト対象アプリや実行履歴をまとめる単位。アプリやチームごとにプロジェクトを分けて管理する。
• 実行（run）: アップロードしたアプリとテストを、選んだ端末群に対して一括実行する一回分の単位。端末ごとの結果が集約される。
• デバイスプール: テストを流す対象端末の集合。機種・OS バージョン・メーカーなどの条件で動的に選ぶか、特定端末を明示的に選んで構成する。
• テストタイプ: 実行するテストの種類。Appium などのフレームワークを用いた自動テストと、スクリプト不要で画面を自動巡回する組み込みの探索テスト（fuzz/explorer 系）がある。
• リモートアクセス（手動テスト）: ブラウザ越しに実機を専有してリアルタイムに操作するセッション。タップやスワイプ、入力を遠隔で行い不具合を手で再現する。
• アーティファクト: テスト実行で得られる成果物。ログ、スクリーンショット、動画、パフォーマンス指標などが端末ごとに記録される。
• プライベートデバイス: 自分のアカウント専用に確保された専有端末。一般の共有プールと分け、機種・構成を固定して継続的に使える。

仕様・制限・クォータ

• 対応プラットフォームは Android と iOS のネイティブ／ハイブリッドアプリ、および Web アプリです。アップロードするアプリは各プラットフォームのパッケージ形式（Android はアプリパッケージ、iOS は署名済みのアプリ）で渡します。
• 自動テストは Appium をはじめとする複数のテストフレームワークに対応し、加えてスクリプトを書かずに画面を自動巡回する組み込みの探索テストも利用できます。対応フレームワークの種類は時期によって増減します。
• 端末プールは AWS が用意する実機で構成され、選べる機種・OS バージョンは入れ替わります。常に最新・全機種が揃うわけではないため、ターゲット機種が含まれるかは実行前に確認します。
• 1 回の実行で対象にできる端末数や、テストの最大実行時間、同時に実行できる数などにはアカウント・リージョン単位の制限があります。長時間のテストはタイムアウトの上限に注意します。
• 具体的な対応機種一覧・上限値・対応フレームワークは時期やリージョンで変わり得るため、最新情報はサービスのコンソールとドキュメントで確認してください。

内部の仕組み

テストを実行すると、Device Farm はまずアップロードされたアプリとテストパッケージを受け取り、検証して取り込みます。次に、指定されたデバイスプールの条件に従って対象端末を解決し、AWS が運用する物理端末群の中から空いている実機を確保します。共有プールの場合はテストの実行中だけ端末が割り当てられ、終了すると初期状態に戻されて次の利用者へ返されます。

確保された各端末上でアプリがインストールされ、テストタイプに応じた処理が走ります。Appium のような自動テストでは、指定したスクリプトが端末上のアプリを操作し、その間の画面・ログ・操作結果が逐次収集されます。組み込みの探索テストでは、スクリプトなしでアプリ内の画面要素を自動的にたどり、クラッシュや異常を検出します。複数端末を対象にした実行では、これらが端末ごとに並行して進むため、多機種の検証を短時間で済ませられます。

実行の進行に合わせて、各端末からはログ、スクリーンショット、操作の録画動画、CPU・メモリ・起動時間などのパフォーマンス指標といったアーティファクトが集約されます。手動のリモートアクセスでは、確保した実機がセッションの間だけ利用者に専有され、ブラウザからの操作がリアルタイムに端末へ中継されます。実行が終わると端末は解放され、結果一式が機種ごとに参照できる形で残ります。

設計パターン / ベストプラクティス

• まず主要なターゲット機種・OS を洗い出し、利用者層に合わせたデバイスプールを設計する。市場シェアの高い機種や、過去に不具合が出た機種を優先的に含める。
• 自動テストを CI に組み込み、ビルドのたびに代表機種のプールで回す。リリース前には機種数を広げ、日常はコストを抑えた最小プールにするなど、頻度に応じてプールを使い分ける。
• スクリプトを書く前に組み込みの探索テストでざっと網羅し、クラッシュの多い画面を把握してから、再現性の高い箇所を Appium などの自動テストで厚く固める。
• 特定機種でのみ起きる不具合は、リモートアクセスで実機を手元のように操作して再現・調査する。録画やログと併せて原因を切り分ける。
• 機種・構成を固定して安定的に回したい継続テストには、専有のプライベートデバイスを用い、共有プールの端末入れ替えによる揺らぎを避ける。

運用・監視

実行の進行状況と結果は Device Farm のコンソールや API で確認でき、どの端末でテストが成功・失敗したか、どの機種でクラッシュが起きたかを機種横断で俯瞰できます。失敗した端末についてはログ・スクリーンショット・録画動画をたどり、特定機種・特定 OS でのみ起きる問題を切り分けられます。

継続的な品質維持の観点では、テスト実行をビルドパイプラインに組み込み、結果を通知や後続処理と連携させるのが実務的です。実行結果やパフォーマンス指標を蓄積して機種ごとの傾向を追えば、回帰の早期発見や、サポート対象機種を見直す判断材料になります。手動調査が必要な不具合はリモートアクセスのセッションで掘り下げ、自動テストとリモート操作を場面で使い分けます。

コスト

Device Farm の料金は、実機を使ってテストや操作を行った時間に基づく従量制が基本です。自動テストでは端末上でテストが実行された時間（デバイス分）に応じて課金され、手動のリモートアクセスでも端末を専有した時間に応じて費用が発生します。多くの端末で並列にテストを流すほど、合計のデバイス時間は増えます。

機種・構成を固定して継続利用する専有のプライベートデバイスには、利用時間ではなく確保した期間に応じた料金体系もあります。コストを抑えるには、日常のテストは代表機種に絞った最小プールで回し、リリース前など必要な場面でだけ機種数を広げる、テストの実行時間を無駄に長くしないといった運用が有効です。具体的な料金はプランやリージョンで変わるため、見積もりは料金ページと計算ツールで確認してください。

セキュリティ

Device Farm の操作権限は IAM で制御します。誰がプロジェクトを作成し、アプリやテストをアップロードし、実行できるかをポリシーで限定して、不用意なアップロードや実行を防ぎます。アップロードするアプリやテストデータには機微な情報が含まれ得るため、アクセスできる主体を必要な範囲に絞ることが基本の防御になります。

実機を共有プールで使う場合、テスト終了後に端末は初期化されて次の利用者へ返されますが、テスト中に端末へ書き込んだ認証情報やテストデータの扱いには注意します。本番の認証情報を埋め込んだビルドをそのままテストに使わず、テスト専用の資格情報やダミーデータを用いるのが安全です。機種・データの隔離をより厳密にしたい場合は、共有しない専有のプライベートデバイスを利用します。操作は CloudTrail に記録されるため、いつ誰が何を実行したかを監査できます。

関連サービス・比較

混同されやすいのが、ブラウザの自動テストを大規模に並列実行する AWS のサービス群との違いです。Device Farm は実機のモバイル端末上でのアプリ検証とリモート操作に主眼があり、対象は主にネイティブ／ハイブリッドのモバイルアプリです。一方、Web アプリのブラウザテストを多数のブラウザ・バージョンで並列に流すことに特化したサービスは、実機の物理端末ではなくブラウザ環境のスケールに重きを置きます。検証したい対象がモバイル実機の挙動か、Web ブラウザの互換性かで使い分けます。

ハンズオン / CLI例

以下は、プロジェクトを作成し、アプリとテストをアップロードして自動テストを実行する基本的な流れの例です。アップロードはまず登録 API で受け取り用 URL を発行し、その URL へ実体をアップロードしてから実行を開始します。各 ARN や端末プールは環境に合わせて置き換えてください。

# プロジェクトを作成
aws devicefarm create-project --name "MyMobileApp"

# アプリのアップロード枠を作成（返る uploadUrl へ実体を PUT する）
aws devicefarm create-upload \
  --project-arn arn:aws:devicefarm:us-west-2:123456789012:project:PROJECT-ID \
  --name app-release.apk \
  --type ANDROID_APP

# 発行された署名付き URL へアプリ本体をアップロード
curl -T app-release.apk "https://prod-upload.s3-url.example/..."

# アップロード済みアプリとテストを指定して自動テストを実行
aws devicefarm schedule-run \
  --project-arn arn:aws:devicefarm:us-west-2:123456789012:project:PROJECT-ID \
  --app-arn arn:aws:devicefarm:us-west-2:123456789012:upload:APP-UPLOAD-ID \
  --device-pool-arn arn:aws:devicefarm:us-west-2:123456789012:devicepool:POOL-ID \
  --name "smoke-run" \
  --test type=BUILTIN_FUZZ