複数のAndroid端末で不具合を再現する：サポートチーム向け3台検証マトリクス

Posted at 2026-09-19

「ボタンを押しても反応しない」「ログイン後に元の画面へ戻る」「特定の端末だけレイアウトが崩れる」。このような問い合わせを開発チームへ渡すとき、問題になるのは説明の長さではありません。再現条件が分離されていないことです。

Androidでは、OSバージョン、メーカー独自UI、画面密度、言語、権限、ネットワーク、バッテリー制御、既存セッションの状態によって結果が変わります。本記事では、大規模な端末ラボを作らず、3台の実機から始める再現手順を整理します。

1. チケットを「実行可能なテストケース」に変換する

端末を選ぶ前に、次の情報を揃えます。

不明な項目は推測せず「不明」と記録します。既知の事実とサポート側の仮説を分けるだけで、開発者が同じ質問を繰り返す回数を減らせます。

顧客のパスワード、決済情報、認証トークン、私的なメッセージや写真は受け取らない運用にします。テストには専用アカウントと合成データを優先します。

端末数よりも、比較の役割が重要です。

例えば、問い合わせが「Android 12の特定メーカーでトルコ語表示にするとログインループになる」という内容なら、ベースライン端末、同じメーカー／OS世代の端末、別メーカーまたは別OS世代の端末を用意します。

端末を追加する条件も決めておきます。「最近の重要チケットを現行3台でカバーできない」「売上や利用率の高い機種で再発している」など、保守コストを正当化できる場合だけ増やします。

最初にベースライン端末で既知の正常フローを実行します。次に、アプリビルド、アカウント、ネットワークをできるだけ揃えた状態で影響ファミリー端末を試します。

差が出た場合は、次の検証で1項目だけ変更します。

失敗だけでなく成功した試行も記録します。「5回中4回失敗、アプリデータ初期化後は0回」という情報は、単に「たまに失敗する」と書くよりはるかに有用です。

端末を持ち替えながらロック解除、画面移動、記録を繰り返すと、担当者自身が状態差を作ってしまいます。複数のAndroid端末を操作できるデスクトップ環境は、同じ画面を比較し、端末コードと状態を確認する用途に向いています。

一括入力は、全端末が同じ安全な開始状態にある場合だけ使います。1台に権限ダイアログ、キーボード、更新通知、読み込み遅延が出たら同期を止めます。同じクリックが別のUIに送られると、再現条件を壊すだけでなく、誤操作の原因になります。

実務では次のルールが扱いやすいです。

長いチャット履歴をそのまま貼るのではなく、1分で概要を把握できる単位にまとめます。

ファイル名にはケースID、端末コード、ビルド、時刻を含めます。ログは関係する時間範囲だけを切り出し、トークンや個人情報を削除します。録画にも顧客名、メール、メッセージ、注文番号などが写っていないか確認します。

最初から1つに統一する必要はありません。エミュレーターで基本確認し、ローカル実機で可能性の高い条件を試し、足りない機種だけクラウドで補う構成が現実的です。

3台を用意したら、過去に端末差で止まったチケットを5〜10件選びます。次の指標を2週間だけ記録します。

改善が確認できたら、根拠のある1台だけ追加します。改善しない場合は、端末数ではなく、受付項目、開始状態、証拠パケットの不足を見直します。

私はLaiCai Screen Mirroringの開発に関わっています。端末選定、プライバシー、ローカル／クラウドの判断を含む詳細版は、実機Androidで顧客の不具合を再現するサポート手順にまとめました。

重要なのは端末の台数ではなく、別の担当者が同じ条件を再現し、同じ証拠を確認できることです。