推奨環境の外に落ちた端末に、何を見せるか
ブラウザで動く AR を使った施策を設計するとき、いちばん手薄になるのが推奨環境を外れた端末の扱いです。
動くケースの設計は誰でもやります。動かないケースは「動きません」で済ませがちで、その結果、利用者の画面には何も起きないか、真っ黒な画面が出ます。何も起きないのがいちばん悪いというのが、この記事の主張です。
題材として、ある WebAR グッズ制作サービスが公開している動作条件を使います(2026年9月9日時点)。
→ ブラウザで動くARグッズを作れる AR Goods Makers
条件は2つある
公開されている条件を、そのまま書き出します。
1. 端末が2台必要
AR体験には、ARを起動するスマートフォンと、体験用画像を表示する別の端末が必要です。組み合わせは PC と1台、あるいは2台のスマートフォン。1台きりでは成立しません。
2. 推奨環境
iOS は18以降でSafari、Android は13以降でChromeが推奨とされ、そこから外れた環境は動作保証もサポートも対象外です。
設計者として重要なのは、この2つが独立した条件だという点です。推奨環境を満たしていても端末が1台なら体験できないし、端末が2台あっても古い OS なら動きません。よくある実装は、この2つを1つの isSupported に潰してしまいます。
失敗の種類を分ける
判定を1つのブール値にすると、利用者に出せるメッセージも1種類になります。「お使いの環境では利用できません」。これでは利用者は次の行動を取れません。
分けます。
function diagnose(ua, caps) {
const os = detectOs(ua); // { name: 'ios'|'android'|'other', major: number }
if (os.name === 'ios' && os.major < 18) return 'os_too_old';
if (os.name === 'android' && os.major < 13) return 'os_too_old';
if (os.name === 'other') return 'os_unsupported';
if (!caps.isTargetBrowser) return 'browser_mismatch';
if (!caps.hasCamera) return 'no_camera';
if (!caps.cameraPermission) return 'permission_denied';
return 'ok';
}
それぞれに、利用者が実際に取れる行動を割り当てます。
| 判定 | 画面に出すもの |
|---|---|
os_too_old |
必要な OS のバージョンを明示する。「対応していません」で止めない |
browser_mismatch |
標準ブラウザで開き直す導線。URL をコピーできるようにする |
permission_denied |
許可の出し直し方を、OS ごとの手順で示す |
no_camera |
代替コンテンツへ(後述) |
os_unsupported |
代替コンテンツへ |
browser_mismatch は実際によく踏みます。QR コードを読み取ったアプリの内蔵ブラウザで開かれる場合があるためです。ここで「動きません」と出すのは、あと一手で成功できる利用者を取り逃がしていることになります。
端末が2台という条件は、検出できない
やっかいなのが1つ目の条件です。「利用者がもう1台端末を持っているか」は、ブラウザからは分かりません。
検出できない条件を設計に組み込むには、前提のほうを動かすしかありません。選択肢は3つです。
- こちらで表示用の端末を用意する — 会場やイベントで配る場合。据え置きの画面を1つ置けば、利用者は自分のスマートフォン1台で済む
- 案内に先出しする — 持ち帰ってもらう場合。配布物の紙面や案内ページに、必要な環境を書いておく
- 代替を用意する — AR を使わない形でも中身が伝わるようにする
実務では、QR の遷移先を分岐させるのがいちばん効きました。遷移先の1枚目を「体験の入り口」にして、そこで条件を説明し、2台ある人だけが次へ進む。いきなり AR を起動しません。
代替コンテンツは「劣化版」にしない
no_camera や os_unsupported に落ちた利用者へ、何を出すか。
ここでよく作られるのが「AR の代わりに静止画」という劣化版です。体験の価値が落ちるので、利用者は損をした気分になります。
このサービスには、AR 体験とは別にデジタルコンテンツの配信という機能がありました。特典画像・PDF・動画・音声を届けられるもので、画像と PDF はダウンロードでき、動画と音声はストリーミングが基本、回数制限付きダウンロードにも対応するとされています。
つまり、AR とは独立した配信経路があるということです。設計としてはこう置けます。
QR → 入口ページ
├─ 条件を満たす → AR 体験
└─ 満たさない → デジタルコンテンツの配信（AR の代替ではなく、それ自体が特典）
代替を「AR のかわり」と説明しないことが肝心です。最初から2つの受け取り方があるという見せ方にすれば、どちらに落ちても利用者の体験は完結します。
容量の制約を先に見る
代替経路を用意すると、配信するファイルが増えます。ここで容量の上限に当たります。
配信データの枠は基本3GBで、そこを超えると1GBあたり2,000円の初回費用が乗ります。
AR 用のアセットと配信用の特典が同じ枠を食うなら、枠の割り当てを先に決めてからエンコードの設定を決めることになります。逆順にすると、必ず超えます。
権利の処理も分岐に影響する
音を使う場合、JASRAC／NexTone の管理楽曲は、商品税抜販売価格 × 数量 × 1.5% の費用が発生します。
計算式に販売価格と数量が入っているため、AR 体験と代替コンテンツで同じ曲を使うかどうかが金額の話になります。設計段階で決める項目に入れておきます。
計測しないと直せない
最後に、判定結果をログに残す話です。
diagnose() の戻り値を、そのままイベントとして送っておきます。すると運用が始まってから、どの理由で何%が落ちているかが分かります。
-
browser_mismatchが多い → 入口ページの案内を直す -
os_too_oldが多い → 推奨環境の告知を配布物の紙面に入れる -
permission_deniedが多い → 許可を求める前の説明文を直す
「動かなかった」を1つのカウンタで数えていると、どれも直せません。理由ごとに数えていれば、次に打つ手が決まります。
まとめ
- 動作条件は独立した複数の条件。1つのブール値に潰さない
- 失敗の理由ごとに、利用者が取れる行動を出す
- 検出できない条件(端末の台数)は、前提のほうを動かして解決する
- 代替は劣化版にしない。独立した受け取り方として設計する
- 容量と権利は、分岐を増やすと効いてくる。先に枠を決める
- 判定結果を理由別に計測する
動作条件は更新されることがあります。実装に入る前に、最新の記載を見てください。
本ページはプロモーションが含まれています
Top comments (0)