導入
クラウド実機でモバイルの自動テストを組むと、スクリプトのロジックとは別のところで足をすくわれます。ひとつはアイドル時間です。共有端末なので、放っておくと勝手に返却されてしまいます。もうひとつは使い捨てデータです。同じメールアドレスは一度しか使えず、登録のテストケースを複数回実行するには工夫が必要です。
どちらも「スクリプトは正しいのに動かない」という、初心者がいちばん混乱するタイプの壁です。私自身、Katalon でクラウド実機（Remote TestKit の Appium Cloud）のスクリプトを組んでいたときに、この2つと正面から向き合いました。半年前の自分に読ませたい内容です。
罠1：デバッグしている間に、端末が勝手に返却される
クラウド実機は共有リソースなので、自動返却の仕様があります。私が使っていた環境では、レンタルした端末は10分間アイドルすると自動返却されました。
厄介なのはデバッグ中です。ブレークポイントで止めてコードを直していると、その「操作していない時間」がアイドル判定に達し、端末が返却されてしまう。スクリプトが失敗したように見えますが、原因はコードではなくセッションの仕様です。
対処1：deviceKeepingTimeout で自動返却までの時間を延ばす
自動化ツールの capability（接続設定） に、自動返却までの時間を指定するパラメータがあります。
deviceKeepingTimeout：自動返却されるまでの時間。ミリ秒で指定（1〜30分の範囲）
returnDeviceAfterTest：テスト後の自動返却の有無。false で自動返却しない
デバッグ中は、これを最大の30分に延ばしていました。
capability を書く場所は、使っているツールごとに違います（Appium の caps、Katalon のプロジェクト設定、akaAT の設定ファイルなど）。「どこに書くか」はツールのドキュメントを確認してください。
対処2以前に知っておきたい、もうひとつの時間の壁
ここからが、実際に試して初めて分かった部分です。端末はいったん返却されると、クリーニング処理のあいだ（30分間）は同じ端末を再レンタルできません。
自動テストは「安定して最後まで走る個体」＝いわば「実績あり端末」を選んで回したくなります。ところがデバッグ中に自動返却が続くと、その実績あり端末が次々とクリーニング待ちに入り、使える実績端末を使い尽くしてしまう。そうなると、また「安定して動く端末」を探さなくてはなりません。
だから deviceKeepingTimeout を延ばす対策は、単に「便利」なだけでなく、限りある実績端末を無駄に返却で溶かさないためにも効いてきます。
導線：この自動返却の仕様と capabilities は、公式FAQにもまとまっています → Appium Cloud FAQ（「端末が勝手に返却される」の項）。
罠2：登録テストが、実行するたびに失敗する
ユーザー登録（サインアップ）の自動テストには、定番の壁があります。登録に使うメールアドレスは一度しか使えないため、ユニークにする必要があるのです。
やっかいなのは、デバッグ（初回）は問題なく通ってしまうこと。安心して自動実行に載せると、2回目以降は「既に登録済み」で必ず失敗します。手動で毎回アドレスを差し替える「運用でカバー」もできますが、それでは自動化の意味がなく、テストデータも汚れていきます。
対処：実行時のタイムスタンプを埋め込んで、毎回ユニークにする
実行時のタイムスタンプ（エポックミリ秒）をアドレスに組み込み、実行のたびに一意な値を作ります。実際に書いたコード（Java）はこうでした。
// 実行時のタイムスタンプ(エポックミリ秒)を埋め込んで、毎回ユニークにする
String email = "user_" + System.currentTimeMillis() + "@example.com";
// 例: user_1738051230123@example.com
System.currentTimeMillis() は 1970年からの経過ミリ秒（13桁）を返すので、実行のたびに確実に別の値になり、日付をまたいでも衝突しません。これで「同じアドレスで落ちる」問題は根本から消え、繰り返し実行やリトライにも耐えられます。
まとめ
クラウド実機の「謎の失敗」は、コードのバグではなく**セッション仕様（アイドル自動返却）**であることが多い。まず capability の deviceKeepingTimeout（ミリ秒指定）を疑い、デバッグ時は長めにする
返却された端末はクリーニングで一定時間 再レンタル不可。実績端末を無駄に溶かさないためにも、自動返却対策は効く
サインアップ系テストは動的テストデータが必須。実行時刻などを埋め込んで使い捨てアドレスを自動生成すれば、実行のたびに落ちることはなくなる
「運用でカバー」を「コードで解決」に置き換えるのが、繰り返し実行できる自動テストの第一歩