数分で作る：EAS Workflows を使った Expo アプリ向け AI QA エージェント | Expo

claudejamodel: claude-sonnet-4-20250514

EAS WorkflowsでExpoアプリ用AI QAエージェントを今日数分で構築する

開発 • React Native • 2026年4月2日 • 9分で読める

Michał Pierzchała ゲスト著者

EAS Workflowsとagent-deviceを使用して軽量なモバイルQAエージェントを構築します。巨大なテストフレームワークなしで、iOSとAndroidのPRのUI検証を自動化します。

これは、Callstack R&D IncubatorのPrincipal EngineerであるMichał Pierzchała氏によるゲスト投稿です。agent-device、React Native Testing Libraryの作成者です。

AIエージェントとコード品質保証の課題

AIエージェントは大量のコードを素早く生成することに長けています。より多くのコードは、より多くのPRがコードベースに向けられることを意味し、エージェントが生成するコードと共に動作し、スケールするコード品質保証プロセスへの需要がさらに高まります。

バックエンドコードベースに貢献するAIエージェントは統合テストでうまく機能することが多いですが、フロントエンド側ではそれほど明るくありません。モバイルiOSやAndroidアプリなどのUIを生成するコードに関しては、最新のモデルは結果を確認することなく驚くほどうまく機能することが多いです（宣言的UIでこれを簡単にするReactに感謝）。しかし、多くの場合、的を外すことがあります。

モバイルデバイスにアクセスできず、コードしか読めないハードコアなReact Native開発者を想像してみてください。コードを見るだけで仕事を完璧にこなせると、どの程度確信できるでしょうか？ヒント：あまり確信できません。

検証が鍵です。これが、Expoアプリで埋めたいギャップです。この記事では、既存のツールを使用して追加コストなしでそれを行う方法を紹介します。

EAS Workflowsを使用したソリューション

EAS Workflowsを使用すると、すでにビルドを再利用し、AndroidとiOSでカスタムジョブを実行し、GitHubプルリクエストにコメントできます。これは、大きなカスタムプラットフォームを導入することなく、今日軽量なQAエージェントを構築するのに十分であることがわかります。

最小限のテンプレートをここにまとめました：callstackincubator/eas-agent-device

セットアップは意図的に小さくしています：

CNGを使用したExpoアプリ
オーケストレーション用のEAS Workflows
AI SDKを使用した小さなNode.js QAエージェント
AndroidとiOS自動化用のagent-device
AndroidとiOSのQA結果を含む1つのGitHubコメント

重要な部分は「AI」ラベルではありません。数分で動作するベースラインから始めて、チームがより多くのカバレッジを必要とするときに拡張できることです。

目標

すべてのプルリクエストに対して、以下を実行したいと思います：

可能な場合は最新のJSで既存のモバイルリリースビルドを再利用
エミュレーターまたはシミュレーターを起動
アプリをインストールして起動
エージェントにUIを検査させ、スクリーンショットを撮らせる
PRの下に短いQAサマリーを投稿

それだけです。巨大なテストフレームワークではありません。すべてのE2Eテストの代替でもありません。モバイルUIの変更に関する実用的なQAループです。

なぜEAS Workflowsがこれに適しているか

主な理由は、EAS Workflowsがすでにモバイル固有のCIを理解していることです。簡単に得られるもの：

fingerprint：ネイティブの変更を検出
get-build：再利用可能なビルドを見つける
repack：JSのみが変更された場合にネイティブコードの再ビルドを回避
linuxとmacosランナー：AndroidとiOSデバイスを実行する仮想化付き
github-comment：結果をPRに送り返す

モバイル自動化を汎用CIシステムに強制する代わりに、モバイル部分がすでに存在する場所でパイプライン全体を維持できます。これにより、セットアップがはるかに理解しやすくなります。

Androidエミュレーターを開くためにAndroidジョブにはlinux-medium-nested-virtualizationイメージが必要で、これをゼロからインストールする必要があります。iOSシミュレーター用にはmacos-mediumイメージ（またはそれ以上）が必要で、これらはすでに利用可能です。

このワークフローの形から始める

コアワークフローはシンプルで、単一画面に収まります：

jobs:
  fingerprint:
    type: fingerprint
  android_get_build:
    type: get-build
    params:
      platform: android
      profile: qa-release
  android_repack:
    type: repack
  android_build:
    type: build
  qa_android:
    runs_on: linux-medium-nested-virtualization
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - uses: eas/download_build
      - id: provision_android_emulator
        run: bash ./scripts/agent-qa/provision-android-emulator.sh
      - id: run_agent_qa
        run: bash ./scripts/agent-qa/run-and-export.sh "${{ steps.download_build.outputs.artifact_path }}"
        env:
          AGENT_DEVICE_SESSION: qa-android
          AGENT_DEVICE_PLATFORM: android
  qa_comment:
    type: github-comment

iOSの場合も同じアイデアで、シミュレータービルドでmacOSワーカー上で実行するだけです。

AndroidとiOSが並行して実行される完全な動作バージョンは、リポジトリにあります：.eas/workflows/agent-qa-mobile.yml

重要な設計選択：ブートストラップをQAから分離

これは強く推奨する1つのことです。一見すると、エージェントにすべてを実行させたくなるかもしれません：アプリのインストール、開く、ナビゲート、検査、レポート。実際には、これはシステムを必要以上に脆弱にします。

エージェントは私たちのツールを間違って使用したり、使用するように求めた指示を読まないことを選択したり、使用しているCLIのフラグを幻覚したりする可能性があります。

そのため、AIエージェントが時々だけでなく確実に私たちのために動作するようにする鍵は、可能な限りワークフローを決定論的に保つことです。agent-deviceを使用すると、デバイスにアプリをインストールして開くときに常に正しいブートストラップパラメータを提供するように、これらをかなり簡単にスクリプト化できます：

#!/usr/bin/env bash
# フェーズ1：決定論的ブートストラップ
agent-device install "${APP_ID}" "${APP_PATH}"
agent-device open "${APP_ID}" --relaunch

agent-deviceは、ジョブで設定されたAGENT_DEVICE_PLATFORM環境変数のおかげで、どのプラットフォームで実行するかを知っています。

スクリプト化が困難なQAプロセスの他の部分は、エージェント駆動のままにできます。エージェントはPRから受け入れ基準を推測し、アクセシビリティツリーを通じてトークン効率的な方法でUIを検査し、少しナビゲートし、スクリーンショットを撮り、何が起こったかを要約します：

# フェーズ2：可変エージェント駆動フロー
npm run agent-qa

過去1か月間でさまざまなエージェントを構築した私自身の経験から、その分割によりワークフローがはるかに信頼性が高くなります。これは、エージェントがアーティファクトパスやインストールコマンドを推測する必要がないことを意味します。

エージェントは非常に小さく保つことができる

アプリがすでに実行されている場合、エージェントはいくつかのツールのみが必要です：

PRコンテキストを読む
agent-deviceスキルをロード
snapshot、press、screenshotなどのUIアクションをagent-deviceを通じて実行
最終レポートを書く

簡略化されたバージョンは次のようになります：

import { ToolLoopAgent } from 'ai';

const agent = new ToolLoopAgent({
  model: 'openai/gpt-5.4-mini',
  instructions: `
    あなたはEAS Workflows内で実行されているモバイルQAエージェントです。
    アプリをブラックボックスとして扱ってください。
    PRから受け入れ基準を推測してください。
    アプリはすでにインストールされ、起動されています。
    agent-deviceを使用してUIを検査し、ナビゲートし、スクリーンショットを撮り、レポートを書いてください。
    結果が視覚的にもっともらしいが構造化されたUI出力から完全に確認されていない場合は、"unsure"を使用してください。
    write_reportを正確に1回呼び出す必要があります。
  `,
  tools: {
    get_pr_context,
    load_skill,
    read_skill_file,
    agent_device,
    write_report,
  },
});

これで素早く始めて、素晴らしさに向けて反復するのに十分です。制御と電池込みツールの良いバランスを提供するVercelのAI SDKを使用しています。その上で、AI Gatewayサービスを通じて好きなすべてのモデルにアクセスできます（少なくともまだマークアップなし）。または、別のサブスクリプションが不要な場合は、古き良きOPENAI_API_KEYを使用してopenaiプロバイダーを代わりに使用できます。

完全なエージェントはここにあります：scripts/agent-qa/index.ts - 簡潔に保つよう努めました。

必要なもののみをレポート

出力を小さく有用に保ちます。テンプレートでは、各プラットフォームが検証ステータスを生成します：passed、failed、blocked、unsureのいずれか。

そして、サマリー、実行されたチェック、見つかった問題、スクリーンショット、および折りたたみ可能なブロック内の完全なJSONレポート（主に失敗したQA検証のデバッグ用）を含む短いセクション。

その最後のステータス、unsureは重要です。モバイルUIは、構造化された自動化出力だけから検証するのが常に簡単ではありません。時にはアクセシビリティツリーが大いに役立ちます。時にはスクリーンショットが最も強力な証拠です。エージェントが結果をきれいに証明できない場合は、そう言って画像を添付すべきです。これは知っているふりをするよりもはるかに良いです。

最終ステップ：プルリクエストの下にコメント

人間の検証と同様に、作業の下への短いコメントは、エージェントが検証できた（またはできなかった）ことの良い概要を得るために必要なことが多く、変更がアプリを壊していないことを真に評価するために非常に必要な視覚的確認と共に。

単一のPRコメントが非常にうまく機能します：

## Agent QA

| Platform | Status |
| -------- | --------- |
| Android | ✅ passed |
| iOS | 🤔 unsure |

### Android
短いサマリー...
スクリーンショット

### iOS
短いサマリー...
スクリーンショット

これにより、レビュアーがすでにいる場所に、必要な情報と視覚的フィードバックを手元に置いて結果が配置されます。

💡 GitHubコメントにスクリーンショットをアップロードする公式APIはないため、例ではVercel Blobを画像を保存するサードパーティクラウドとして使用しました。AWS S3など、ユースケースに適したソリューションに置き換えてください。

今日これを試したい場合の推奨事項

GitHubプロジェクトをExpoダッシュボードからEAS Workflowsに接続
まず1つのプラットフォーム（例：Android）から始める。CNGを使用し、ネイティブビルド再利用を有効にしておく
QAビルドプロファイルを本番から分離しておく
ブートストラップを決定論的にする
エージェントをブラックボックスのみに保つ
10の異なるアーティファクトではなく、1つのPRコメントを投稿
早期にスクリーンショットを追加。大いに役立つ

それが動作したら、拡張する：

iOSを追加
スクリーンショットをBlobストレージにアップロード
より良いセレクターを追加
成功した探索的チェックをより決定論的なフローに変換

主な要点

有用なモバイルQA自動化を得るために巨大なAIテストプラットフォームは必要ありません。ExpoとEAS Workflowsが一緒になって、すでにインフラストラクチャの大部分を提供しています：

ビルド再利用：高速反復と最新のJSバンドル用のrepack
モバイルCIワーカー：スクリプト化と仮想化により、シミュレーターとエミュレーターが利用可能
ワークフローオーケストレーション：これらすべてをまとめる
GitHub統合：認知負荷を減らし、プルリクエスト内で検証を維持

そこから、カスタムQAエージェントは驚くほど小さく保つことができます。TypeScriptベースのAI SDKのおかげで、すべてのニーズに合わせて曲げることができます（そしてかなり柔軟です）。

このセットアップが気に入る理由は、シンプルなテンプレートから始めて、今日数分で構築でき、実際により多くが必要になったときにのみ成長できることです。

ここから始めてください：callstackincubator/eas-agent-device

Build an AI QA Agent for Expo Apps with EAS Workflows in minutes today

要約

Summary

Key Points

翻訳