AIエージェントに役割を割り振ってアプリを作っています。実装、QA、デザイン、法務、秘書。それぞれ別のセッションで動いていて、並行に進むぶん速い。

8月15日、その並行性が牙を剥きました。

実装担当が絵本アプリのE2E検証を回している最中に、秘書担当がストア掲載用のスクリーンショットを撮りはじめました。同じ端末で。 互いに相手の存在に気づかないまま、数分間、同じ画面を奪い合っていました。

何が起きたか

検証用のAndroid実機は1台しかありません。

moto g24 / ZT322LT4K9 / Android 14 / 720×1612

秘書はスクショを撮るために画面を目的の状態へ持っていく必要があり、adb で直接叩いていました。

adb -s ZT322LT4K9 shell input tap 540 1200
adb -s ZT322LT4K9 shell am force-stop com.example.app

この force-stop が、実装担当が走らせていたテストセッションを途中で殺しました。入力途中のフォームが消え、その日の無料枠1話ぶんを検証と関係ないところで消費しました。（このアプリは無料だと1日1話までなので、枠を使い切ると翌日まで同じ経路のテストができません。）

エラーは出ません。実装側から見えるのは「さっきまで動いていたテストが、いきなり初期画面に戻った」という現象だけです。自分のコードを疑うところから始まるので、原因にたどり着くまでが遠い。

原因はスケジューリングではなく、資源の可視性

最初は「作業時間をずらせばいい」と考えました。違いました。

問題は、その端末が共有資源だと、誰の目にも書かれていなかったことです。実装担当のタスクにも秘書のタスクにも「実機を使う」とは書いてあるのですが、それが同じ1台を指していることがどこにも明示されていませんでした。人間なら机の上を見れば分かります。別セッションのエージェントには見えません。

同じ構造の共有資源が、ほかにもありました。

  • Play Console — 2人が同時にドラフトを編集すると、後から保存したほうで上書きされる
  • 無料枠・APIクォータ — 検証で消費すると、他方のテストが「仕様どおりに」失敗する
  • git の作業ツリー — 片方のビルド中にもう片方がブランチを切り替える
  • 同時ビルド — Gradleのデーモンとロックを取り合って、両方が遅くなる

どれも「壊れました」という形では現れません。相手の作業が、こちらから見ると仕様どおりの失敗に見えるのがいちばん厄介です。

決めたルール

大掛かりなロック機構は作りませんでした。3行で足ります。

  1. 実機に触る前に、他セッションの稼働状況を確認する。 使う側は事前に宣言する
  2. 優先順位を固定する。 実装担当の検証が常に優先。スクショ撮影は「空きました」の連絡後
  3. 状態を変えたら必ず戻す

3つ目は具体的な事故から来ています。スクショをきれいに撮るために、SystemUIのデモモードを使うことがあります。

adb shell settings put global sysui_demo_allowed 1
adb shell am broadcast -a com.android.systemui.demo -e command clock -e hhmm 0900

これでステータスバーの時刻が 9:00 に固定され、電波もフルになります。撮影には最高ですが、exit を忘れると時刻が固定されたままになります。次にログを読む担当が、端末の時刻表示とログのタイムスタンプが噛み合わずに混乱する。実際に一度やりました。

adb shell am broadcast -a com.android.systemui.demo -e command exit

環境を一時的に変える操作は、戻す操作とセットでなければ実行しない。 これを運用ルールにしました。

破壊的操作は「申告」と「復元報告」をセットにする

同じ月にもう1件、これと同根の事故を起こしています。QA担当が検証のために、本番データが入っている端末へデバッグ署名版のアプリをサイドロードし、Play Store版に戻し忘れました。復旧の過程で別の問題まで掘り起こす羽目になっています。

このときやっていたのは「これからサイドロードします」という事前申告だけでした。事前申告はしたのに、事後の復元報告がなかった。 だから誰も、戻っていないことに気づけません。

ルールをこう変えました。

本番データの入った端末への破壊的操作は
  実施前の申告  +  実施後の復元完了報告   ← 両方そろって完了

片方だけだと、未完了と完了が外から区別できません。 自動化でも人間の運用でも同じで、「開始のログはあるが終了のログが無い」処理は放置されます。

マルチエージェントで最初にやるべきこと

速度を上げるためにセッションを並列にしたのに、事故のリカバリで半日溶かすと元も子もありません。並列にする前に、共有していて、かつ状態を持つものを列挙するのが先でした。

判定はシンプルで、**「片方が触ると、もう片方から見た世界が変わるか」**です。変わるなら共有資源です。実機、ストアの管理画面、クォータ、作業ツリー、そして本番のデータベース。

逆に、読むだけのもの・エージェントごとに複製できるものは、いくら並列にしても事故りません。分けられるものは分ける、分けられないものだけルールで守る。 ここを最初に線引きしておけば、この日の午後は無駄になりませんでした。

この体制で何が効いて何が無駄だったかはAI社員30人の実録に、体制そのものの話は会社員が2ヶ月でアプリを3本作った話に書いています。スクショの撮影規定そのもので詰まった話はこちらです。