← 最新の論文
💻 computer science

Scaling Mobile Chaos Testing with AI-Driven Test Execution

本論文は、LLMベースのテスト実行とサービスレベルのフォールト注入を統合し、大規模なレジリエンス検証を自動化するAI駆動型のモバイル・カオス・テスティング・システムを提示しており、Uberのモバイルアプリケーションにおける重要なアーキテクチャ上のリスクの特定とデバッグ時間の削減に成功している。

原著者: Juan Marcano, Ashish Samant, Kai Song, Lingchao Chen, Kaelan Mikowicz, Tim Smyth, Mengdie Zhang, Ali Zamani, Arturo Bravo Rovirosa, Sowjanya Puligadda, Srikanth Prodduturi, Mayank Bansal

公開日 2026-07-21
📖 1 分で読めます☕ さくっと読める

原著者: Juan Marcano, Ashish Samant, Kai Song, Lingchao Chen, Kaelan Mikowicz, Tim Smyth, Mengdie Zhang, Ali Zamani, Arturo Bravo Rovirosa, Sowjanya Puligadda, Srikanth Prodduturi, Mayank Bansal

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む

インターネットを、何百万もの小さなデジタル・メッセンジャー(アプリ)がメッセージや食べ物、乗り物を届けるために駆け回っている、巨大で賑やかな都市だと想像してみてください。舞台裏では、これらのメッセンジャーは、すべてがスムーズに動くように、発電所、信号機、倉庫のような、目に見えない巨大なサービスのネットワークに依存しています。時として、これら目に見えない部品の一つが壊れたり、動作が遅くなったりすることがあります。これを「障害(failure)」と呼びます。ソフトウェアエンジニアリングの世界には、「カオスエンジニアリング」と呼ばれる手法があります。これは、基本的には、システムが生き残れるかどうかを確認するために、意図的にわざと壊してみる技術です。それは、建物の避難訓練のようなものです。ただし、火災の代わりに、停電をシミュレートして非常用照明が機能するかどうかを確認するのです。

しかし、モバイルアプリ(スマートフォンのアプリ)のテストは非常に困難です。単純なウェブサイトとは異なり、スマホアプリは、何千もの異なる都市、言語、そしてユーザーの習慣に対応しなければなりません。もし、あらゆる都市におけるあらゆる壊れ方をテストしようとすれば、何百万ものテストスクリプトを書く必要があるでしょう。それは、ニューヨークのようなサイズの都市にあるすべてのドアが、正しくロックされるかどうかをチェックしようとするようなものであり、人間が手作業で行うのは不可能です。この論文は、AIを使って人間の代わりにテストを行うことで、この不可能な数学の問題に取り組んでいます。

Uber(ライダーをドライバーに、人々を食事へとつなげる企業)の研究者たちは、2つの強力なツールを組み合わせたシステムを構築しました。最初のツールは、DragonCrawlという名前のAIロボットです。DragonCrawlを、超スマートで好奇心旺盛なティーンエイジャーだと考えてください。彼はスマートフォンの画面を見ることができ、それが何を見ているのか(例えば、「あ、これはピザを注文するためのボタンだ」など)を理解し、すべてのボタンに対して人間が特定の指示を書かなくても、次に何をクリックすべきかを判断できます。2つ目のツールは、uHavocという、制御されたサボタージュ(破壊工作)を行うシステムです。これは、バックエンド(目に見えないサービスのネットワーク)の一部を意図的に壊して、スマートフォンのアプリがどのように反応するかをテストします。

通常、これら2つのツールは別々に機能していました。DragonCrawlは、すべてが完璧な状態でアプリが動作するかどうかをテストし、uHavocはサーバーがクラッシュに耐えられるかをテストしていました。しかし、研究者たちは、これらを組み合わせれば、自動的に実行される「カオス・テスティング・マシン」を作り出せることに気づきました。彼らは、DragonCrawlがアプリ内をナビゲートしている間に、uHavocが同時にバックグラウンドで何かを壊すように設定しました。その目的は、バックエンドのサービスが調子の悪い日であっても、アプリが(配車を予約するように)動作を維持できるかどうかを確認することでした。

この論文は、彼らがどのようにこのシステムを構築し、それを起動したときに何が起きたかを説明しています。彼らは単に推測したのではなく、2024年第1四半期から18万回以上システムを実行しました。彼らは、UberのRider、Driver、Eatsアプリにおける47の重要なフロー(配車予約や食事の注文など)をテストしました。結果は素晴らしいものでした。AI駆動のシステムは、人間が見落としていた23件の深刻な問題を発見しました。そのほとんどは、小さくて重要でないサービスが故障したことが、大きな重要な機能(配車の支払いなど)のクラッシュを引き起こすケースでした。実際、発見された問題のうち2つは、アプリを完全にフリーズさせ、クラッシュさせるものでした。これは、実機のスマートフォン上でテストして初めて捉えられる問題です。

彼らの発見の中で最も興味深い部分の一つは、「責任の押し付け合い(blame game)」をどのように解決したかです。テストが失敗したとき、以前はシニアエンジニアが、どの壊れたサービスがスマートフォンのアプリの挙動に影響を与えたのかを特定するのに数時間を要していました。彼らの新しいシステムは、証拠を分析して犯人を推測するAIを使用しています。上位5つの推測を見たとき、その的中率は**88%**でした。これにより、問題を修正する時間は数時間から数分へと短縮されました。

また、この論文は、これが単なる理論ではないことも強調しています。彼らは、現実の世界で顧客に迷惑をかけることなく、これが機能することを証明しました。彼らは、バックグラウンドで何かが壊れている状況でも、AIが**99%**のテストに合格するという、驚異的な信頼性を持っていることを明らかにしました。これは、このシステムが毎晩実行され、常にディザスター(災害)への準備ができているかをチェックするのに十分な堅牢性を持っていることを意味します。著者らは、このアプローチが「組合せ爆発」の問題、つまり、必要なテストの数が急激に増大して対処不能になるという問題を解決すると主張しています。リアルタイムで画面に適応するAIを使用することで、何百万ものテストスクリプトを書く必要はなく、AIが進行しながら自ら解決策を見つけ出したのです。

しかし、論文は、このシステムに「できないこと」についても注意深く述べています。このシステムは、海底ケーブルの切断や、Uberが制御していないサービス(サードパーティの地図プロバイダーなど)の障害をテストすることはできません。また、サービスが適切にラベル付けされ、追跡されていることが前提であり、それには事前の多大な準備が必要です。しかし、このシステムが解決できる問題については、論文はこれが大きな飛躍であると示唆しています。これは、モバイル・カオス・テスティングを、稀で高価な手作業のイベントから、毎晩行われるルーチンで自動化された安全チェックへと変え、あなたがスマホで「注文」をタップしたときに、アプリがインターネットから投げかけられるあらゆる事態に対して準備ができていることを保証するものなのです。

自分の分野の論文に埋もれていませんか?

研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。

Digest を試す →