Google Cloud は 2026年8月11日、Developer Device Platform（DDP） の public preview を発表しました。利用開始は 8月12日からです。
📑目次
DDPはFirebase Test Labをさらに進化させたマネージド基盤です。実機と高並列エミュレータにオンデマンドで接続でき、公式では「agentic development向けに作られた最初のデバイスプラットフォーム」と位置づけています。
読者課題とこの記事の範囲
手元の1〜2台だけでは、端末差、foldable UI、ハード固有のバグを完全に再現できません。一方で、coding agentの操作範囲をモバイルまで広げたい場合、クラウド実機ファームの公式手順はまだ分かりにくいのが現状です。
本記事ではこれらの点を整理します。
- Device Streaming API / Device Run API / DDP agent skill の三点
- 先行 Device Streaming の料金感
- preview で試す／待つ判断材料
DDP の三点サマリー
先に全体像を示します。DDPの中核はDevice Streaming、Device Run、agent skillの3つの柱で構成されています。
三点の早見表
| 柱 | 何をするか | 主な入口 | preview での注意 |
|---|---|---|---|
| Device Streaming API | 遠隔の実機／エミュを対話操作・デバッグ | Android Studio Device Manager 系／API | セッション分課金・終了時 wipe 前提 |
| Device Run API | 数百台並列テスト・smart sharding / auto-retry | gcloud beta device-run |
BETA CLI・行列設計が先 |
| DDP agent skill | agent が multi-step UI／視覚異常／チップ性能まで回す | google/skills 系 skill | 製品 docs URL は変動しうる |
出典:
この三点を混同すると、「Studioで1台触る話」「CIで数百台回す話」「agentに操作を任せる話」が同じ計画に押し込まれてしまいます。まずは用途を明確に分けて読むのが安全です。
Developer Device Platform（DDP）とは何か
DDPはGoogleがfully managedで提供する実機と高並列仮想エミュレータの基盤です。
- Firebase Test Lab の evolution
- agentic development 向けに設計された device platform
- public preview（利用開始: Starting August 12）
- preview 中は pay-per-minute（emulator と physical で単価差）
対象となる読者は次のようなチームです。
- GCP 上でモバイル QA／CI を回している
- Claude Code や Codex など coding agent を、モバイル UI 操作まで伸ばしたい
- 自前ラックや他社デバイスファームと比較し、公式マネージド路線を評価したい
docs が薄いときの読み方
注意点もあります。2026-08-11 時点の調査では、docs.cloud.google.com/developer-device-platform 系や agent-skill 専用 docs が 404 になるケースがありました。
- 一次情報は Cloud Blog と、既存の Device Streaming／gcloud device-run ドキュメントを併用するのが現実的です
- preview では製品ページより API・CLI・skill 索引の方が先に動くことがあります
Device Streaming API でできること
Device Streaming は、選んだ実機やエミュレータへ対話接続し、スクロール・タップ・デバッグ・性能監視を行う柱です。Device Streaming API は、Google データセンター上のリモート物理 Android へ安全に接続し、ローカル接続に近い操作感を目指す API 面として説明されています。
先行導線（Android Studio + Firebase）
DDP 発表時点でも、学習と Pilot に使えるのは Android Device Streaming（Android Developers） の Studio 導線です。
- Android Studio で Device Manager を開き、Firebase から接続する
- プロジェクトを選ぶ（Editor/Owner、または Test Lab Direct Access Admin + Service Usage Consumer）
- 端末を Start し、Running Devices で操作する。必要なら Extend Reservation
- 終了時は Return and Erase Device（wipe / factory reset）
追加の実務メモです。
- 接続は ADB over SSL。Studio Jellyfish 以降が予約に必要だが、予約後は ADB を使う他ツールも利用できる
- 例示端末には Pixel 系列や Samsung など大手 OEM が含まれる
- セッション終了後のデータ消去が前提なので、検証データは毎回再投入する設計にする
独立 hands-on の示唆（先行 Firebase）
日本語の独立 hands-on として、クラシル（Dely）Tech Blog（2024-04-10）は Firebase Device Streaming Open Alpha を試しています。
- 予約から約1分で利用可能
- 当時はおおよそ15分制限と延長
- ローカル実機より操作が重い、といった現場メモ
DDP固有機能の証明ではありませんが、クラウド実機ストリーミングの体感レイテンシとセッション運用を先にイメージする材料になります。
出典:
Device Run API と並列テスト
Device RunはCI/CD向けの柱です。公式ブログでは数百台への並列投入、端末固有問題の切り分け、smart sharding、smart auto-retriesを挙げています。対話デバッグ（Streaming）とは目的が異なります。
CLI 面では gcloud beta device-run が公開されています。
gcloud beta device-run devices list|describeでカタログ確認sessionsグループで自動化セッション／ジョブを管理- BETA のため、フラグや応答は変更されうる
読者が先に決める設計
並列Runを「全部載せ」にすると、previewの段階でもコストとflakyが同時に膨らみます。最初のPilotでは次の点を固定してください。
- critical path の instrumentation と主要 API level だけを行列化する
- flaky（環境依存のゆらぎ）と hardware-specific（機種固有）を分け、retry 方針を書く
- agent 任せの全端末全ケースは後回しにする
- 失敗ログの保存先と、人が見る合格基準を先に決める
結論として、Device Runの価値は「台数の多さ」そのものではなく、shard設計と局所的なretryで失敗を安く切り分ける点にあります。
DDP agent skill — coding agent を実機操作ループへ
DDPがFirebase系との差分として特に強調しているのがagent skillです。公式ブログが示す主な能力は次の通りです。
- multi-step user journeys
- visual artifacts（見た目の異常）の検知
- on-device chip performance の把握
- hardware-specific なバグ修正・最適化
第三者の整理でも、google/skills カタログの Developer tools に Developer Device Platform が列挙されています（騰訊雲開発者コミュニティの 2026-08-08 解説など）。チャット専用の説明文ではなく、製品ライン単位でインストール可能な skill として扱われています。
skill 索引に見える実装メモ
tool.luが索引するdeveloper-device-platform-basics系の記述では、Preview時点の実装手順が具体的に示されています。
- API 有効化例:
devicerun.googleapis.com/devicestreaming.googleapis.com/（Preview 中）testing.googleapis.com gcloud beta device-run devices listで端末確認- deviceStreaming 対応端末の予約。課金発生前の明示確認を必須にする
- ADB forwarder で localhost に繋ぎ、session ACTIVE 後に操作する
課金ゲートを先に置く
ここでの実務判断は単純です。agentに予約・延長・長時間操作を任せると、分課金が静かに積み上がっていきます。
- skill を入れるなら、人間またはポリシーによる課金確認プロンプトを必須化する
- 公式 agent-skill docs URL が 404 の場合でも、Cloud Blog・CLI・skill リポジトリ側で手順を固定できる
出典:
料金・クォータの読み方
DDP previewの公式説明はpay-per-minute課金です。emulatorとphysicalで単価に差があります。ただし発表ブログには具体的な1分あたりの料金表は記載されていません。確定単価は請求コンソールと最新ドキュメントで確認してください。
先行 Device Streaming の参考値
先行のAndroid Device Streaming（Firebase）は、コスト感を掴む参考値になります。DDP本体の確定単価ではありません。
| 項目 | 参考値（先行系） | 読み方 |
|---|---|---|
| Device Streaming 月次 | Spark/Blaze とも 30 no-cost minutes / project | まずは無料枠で smoke |
| Streaming 超過（Blaze） | $0.15 / additional minute | agent の長時間操作で効く |
| Test Lab 自動テスト超過 | physical $5/hour、virtual $1/hour（分切り上げ） | Streaming と別枠 |
| Spark 日次 run 上限 | virtual 10 / physical 5 | 自動テスト側の上限 |
出典: Firebase Test Lab usage quotas and pricing（更新 2026-08-09 時点の調査メモ）
運用への含意
- agent の操作ループは「分」が単位なので、idle 切断と erase を Runbook 化する
- 並列 Run は 台数 × 時間 で急増する。shard と局所 retry が先
- 無料枠を「全自動 E2E の完成」ではなく「コスト測定用 Pilot」に使う
既存ファーム／OSS との比較 — いつ DDP を選ぶか
DDPを唯一解にしない方が判断が速いです。用途別に並べます。
| 選択肢 | 強み | 弱み・前提 | DDP との関係 |
|---|---|---|---|
| 手元実機のみ | 低遅延・センサー実体験 | 台数・機種カバレッジ不足 | 補完対象 |
| Firebase Android Device Streaming | Studio 統合・既存 IAM/料金 docs | agent skill / Device Run 三点セットは DDP 側ストーリー | DDP の先行系 |
| Firebase Test Lab 行列 | CI 向け自動テスト実績 | 対話デバッグは別機能 | DDP が evolution と公称 |
| 自前ラック／他社デバイスファーム | カスタム管理 | 調達・保守コスト | コスト比較対象 |
| phone-harness 系 OSS | ローカル agent 実験が速い | 機種多様性・運用は自前 | agent UX 比較軸 |
選定チェック
次に該当する場合はDDP Pilotの優先度を上げると良いでしょう。
- GCP 請求アカウントと IAM 運用が既にある
- 必要なのは対話デバッグ、並列回帰、agent 自律操作のどれか（または組み合わせ）が言語化できる
- preview の API／docs 変動を許容できる
- 分単価と日次上限をチームで監視できる
逆に、確定単価表・安定したドキュメント・Studio完全統合が必須条件であれば、ウォッチリストに登録し、先行するDevice Streamingで小規模なsmoke testを先に実施する判断も妥当です。
導入前チェックリスト（今日やること）
読者の次アクションは、概念理解ではなく same-day pre-flight → adopt-or-wait です。今日中に 1〜5 を完了し、実測メモを残してから拡大可否を決めてください。
今日やる pre-flight（1〜5）
- GCP/Firebase プロジェクトと請求アカウントを確認する
- IAM を確認する（Editor/Owner、または Test Lab Direct Access Admin + Service Usage Consumer）
- API 候補を有効化する:
devicestreaming.googleapis.com/devicerun.googleapis.com/（必要なら）testing.googleapis.com gcloud beta device-run devices listで Device Run カタログを見る- Studio から 1台だけ Streaming 予約 → monorepo の smoke → 必ず erase
拡大は実測のあと（6〜9）
- CI には最初から全端末を載せず、critical path × 代表 API level の小行列にする
- agent skill を入れる場合は、予約・延長の課金確認プロンプトを必須化する
- コスト上限（分／日）と自動切断ルールをチーム Runbook に書く
- preview 終了・単価改定のウォッチ担当を決める
adopt-or-wait の決め方
- 採用（Pilot 拡大）: 1〜5 の分単価・失敗モード・erase 運用がメモに残っている
- 待つ: 確定単価表・安定した製品 docs・Studio 完全統合が必須条件
- 拡大禁止の例: 課金確認なしで agent に予約・延長・長時間操作を任せる
関連記事:
- Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
- MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計
- エージェント向け検索の設計｜どう探させ、何を返すか
よくある質問（FAQ）
DDP と Firebase Test Lab / Android Device Streaming は別物ですか？
公式は DDP を Test Lab の evolution であり、agentic 向けの device platform と説明しています。Streaming の先行導線と料金ドキュメントは、いまも学習・比較材料として有効です。三点セット（Streaming + Run + agent skill）の製品ストーリーは DDP 側に寄ります。
いつから使えて、いくらですか？
利用開始は発表ブログの Starting August 12 です。preview は pay-per-minute（実機/エミュで差）です。具体単価表はブログ未掲載のため、先行 Device Streaming の超過 $0.15/min などを参考値として扱い、請求コンソールで確認してください。
coding agent だけでモバイル E2E を任せられますか？
公式は multi-step UI や視覚アーティファクト検知などを示します。一方で preview・分課金・ハード固有 flaky があります。人の合格基準とコスト上限なしの全自動は推奨しません。
iOS は対象ですか？
本稿の一次情報は Android 実機ストリーミング／Device Run 文脈が中心です。iOS 対応範囲は公式発表を都度確認し、未記載の範囲は断定しません。
agent-skill の公式 docs が 404 なのはなぜですか？
2026-08-11 調査では docs.cloud.google.com/developer-device-platform/agent-skill が 404 でした。Cloud Blog、gcloud device-run、google/skills／第三者 skill 索引を併用し、リンク切れ前提で手順を固定してください。
まとめ — 次に取るアクション
DDPは「クラウド実機ファーム×agent」をGCP公式に載せたpublic previewです（公式発表日：2026年8月11日、利用開始：8月12日）。中核はDevice Streaming、Device Run、agent skillの3点です。Firebase系の先行資産は無駄にならず、学習とPilotの入口として活用できます。
今日の pre-flight（チェックリスト 1〜5）
- 請求アカウントと IAM を確認する
- Device Streaming / Device Run 系 API を有効化する
gcloud beta device-run devices listを実行する- Studio で 1台 Streaming smoke を回し、必ず erase する
- 任意で critical path の小規模 Device Run 行列を1本だけ試す
adopt-or-wait
- 今すぐ拡大: 分単価、失敗モード、課金確認プロンプト、日次上限が Runbook に残っている
- まだ待つ: 確定単価表・安定 docs・Studio 完全統合が必須ならウォッチリストへ
- 拡大しない: 課金ゲートなしの agent 全自動ループ
次の一手は、上の pre-flight 1〜5 を今日中に実施し、実測メモを残してから agent 連携を広げることです。preview の価値は「全部自動化できた」ことではなく、「公式レール上で再現可能な検証ループを、コスト付きで回せた」ことにあります。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す