← 返回列表

実機テスト端末マトリクス（solo の最小保有計画）

2026/9/17

背景与問題

OPC（B 方向）。Android は 2 万 4,000 機種あると言われ、実機をいくつ持つべきか迷う。自社ユーザーの実態（シニアは端末更新が遅い）に合わせた最小マトリクスと、実機で補えない部分の分担を決める。

发现

（出典はいずれも 2026-09-17 アクセス）

Android は約 24,000 機種。テストマトリクスは自社のトラフィック加重データで作り、ハード依存の検証用に特定機を手動追加するのが定石（drizz.dev）。
本番相当の最小マトリクスは 12〜16 台（画面・GPU/SoC・RAM・OS・OEM skin の各セグメント 1 台）という実務値（Game-Ace）。高トラフィック 20〜40 台に絞るとクラッシュフリー率 99%+ を維持できたという報告（Appmaisters）。
fragmentation はカバレッジでなくメンテ問題として扱うのが小規模チームの現実解（Sofy.ai）。
総意：2 万機種を追わない。自社 analytics 主導の小マトリクス+クラウドファーム（Firebase Test Lab 等）+長尾はクラッシュレポートで拾う。
推测：シニア層は端末更新サイクルが長く、旧 OS・低 RAM 機の比率が一般より高い。一般の統計を当てはめない。

结论

自社の最小セットを確定：実機 3〜5 台（低 RAM 1・サポート最旧 OS 1・主要 OEM skin 1〜2・手元 iPhone 1）+Firebase Test Lab で長尾補完。12〜16 台は本番品質の参考値で、solo の初期値ではない。
「サポート最旧 OS」は実ユーザー 95% カバー線で年 1 回再判定し、判定日と根拠をopc-year-end-checklist に記録する（感覚で切り捨てない）。
シニア向けは旧 OS 保持を一般より長く：analytics の OS 分布を四半期 1 回見て、下限を引く判断の材料にする（推测：親世代は「壊れるまで変えない」）。
長尾の主監視はクラッシュレポート：実機マトリクスの外で起きた問題は「再現機の追加」か「cloud farm で確認」のどちらかで受ける運用を 1 回決めておく。

待办 / 下次继续

analytics から上位 10 機種・OS 分布を出力（マトリクス v1 の実値）。
Firebase Test Lab の無料枠で主要 3 機の自動テストを 1 回走らせる。

关联

opc-year-end-checklist opc-senior-accessibility-basics opc-release-precheck-5min opc-rollback-drill