アプリが自分でバグを直せたらどうなる？

EAS Workflows と EAS Simulator があれば、バグレポートがそのまま修正入りの pull request になり、修正が効いていることを示す録画まで付いてくる。

エージェント開発の未来は、自分で自分を直せるアプリにある。ユーザーがバグを報告してきたとしよう。短い説明がひとつだけで、再現手順も証拠もない。いつもなら、そこから自分で調べるしかない。EAS Workflows と EAS Simulator を使えば、エージェントがクラウド上のシミュレータでバグを再現し、修正案を出し、修正前後の証拠を添えた pull request を開ける。あなたは報告を読み、変更を確認し、マージするかどうかを決めるだけだ。EAS Workflows は Expo のインフラ上でエージェントを動かす。EAS Simulator はエージェントにデバイスを渡し、アプリを動かして動作を検証させる。ここでは Settings のクラッシュを例に、この2つがどう連携して調査を進めるかを見ていく。 アプリが自分で自分を直せたらどうなるだろう？

バグレポートから始める

この例のレポートはよくあるものだ。「Settings を一番下までスクロールするとクラッシュする」。書かれているのは症状だけで、再現方法も原因もない。

該当する GitHub issue に repro ラベルを付けると workflow が起動し、レポートが Claude Code に渡される。エージェントの任務は、シミュレータ上で不具合を再現し、原因を突き止め、修正を検証してから PR を開くことだ。

このサンプルは issue #9 と PR #10 で確認できる。

クラウド上のシミュレータでエージェントに調査させる

エージェントは EAS Simulator にアプリをインストールし、Settings を開く。スクロールを始める前に、アプリはすぐクラッシュする。

これで調査の出発点がより正確になる。エージェントは実行した手順、観察された挙動、再現セッションへのリンクを issue に貼る。

やり取りはすべて agent-device を通して行われる。Callstack のデバイス自動化 CLI だ。これによりエージェントは EAS Simulator 上で画面を見て、アプリを操作し、スクリーンショットを撮れる。セッションのリプレイを見れば、後から何が起きたかを確認できる。

修正が効いた証拠を手に入れる

エージェントは原因を特定し、アプリを修正し、アプリを再ビルドして2つ目のシミュレータセッションにインストールする。Settings を開いて一番下までスクロールする。今度は画面が正常に読み込まれ、クラッシュしない。

この PR は調査の流れをひとつにつなげる。原因、変更、修正前後のスクリーンショット、そして2つのシミュレータセッションへのリンクだ。修正後に Settings のテスト22件がすべて通り、lint と typecheck も通ったことも報告されている。

報告をたどって再現の流れを追い、diff を確認し、修正後のアプリが同じ経路をたどるのを見られる。レビューは macOS、Windows、Linux のブラウザだけで完結し、ローカルに iOS Simulator を用意する必要はない。

ワークフローを自分のアプリにつなぐ

このサンプルは GitHub Action で、ラベルを付けた issue 番号を EAS Workflows に転送する。EAS Workflow はリポジトリをチェックアウトし、依存関係をインストールしてからコーディングエージェントを起動する。

3つ目の部品は agent prompt だ。アプリ、シミュレータのビルド profile、エージェントがこなすべき調査を記述する。どんな証拠を返す必要があるかも定めている。再現セッションの URL、検証セッションの URL、修正前後のスクリーンショットだ。

この指示には、調査が失敗したときの動きも書かれている。バグを再現できなければ、何を試したかを報告して止まる。修正がシミュレータ上で依然として失敗するなら、PR を開かず検証失敗として報告する。目に見えない挙動については、スクリーンショットに加えてログか回帰テストを添えるよう prompt は求めている。

自分のプロジェクトに当てはめるには、アプリのビルド profile、ナビゲーションの文脈、そして Expo、GitHub、エージェントの認証情報を用意する。eas-simulator skill が、エージェントにシミュレータセッションを操作するための指針を与える。

prompt はマージを人間に委ねるようエージェントに求めている。この境界を支えるために、リポジトリの権限とブランチ保護を設定しよう。

このワークフローは Nathan Schroeder の X の投稿に着想を得ている。

自分の流れを試す

失敗したかどうかを自分で判断できるバグと、シミュレータ上で動くアプリのビルドから始めよう。役に立つ再現とは何を示すべきかを先に考え、サンプルリポジトリを使ってレポートを自分のエージェントにつなぐ。

問題の再現だけを任せることもできるし、修正と検証までまとめて任せることもできる。どちらを選んでも、何が起きたかを他人が理解できるだけの証拠を残すようエージェントに求めよう。

EAS Simulator は現在 early access だ。waitlist に参加すればアクセスを申請できる。クラウド上のシミュレータを自分のマシンで使う方法をさらに知りたいなら、You don't need a Mac to develop iOS apps を読んでほしい。

あなたのアプリが自己修復できたらどうなるだろうか？