feature-detection

モバイルユーザーは現在、ウェブトラフィックの大きな割合を占めていますが、多くのサイトは依然として JavaScript でのモバイル検出を適切に処理できていません。結果はおなじみの、読み込みが遅いページ、壊れたタッチ操作、不要なポップアップ、あるいはスマートフォンやタブレットとデスクトップで挙動が異なる機能です。実用的で高速なウェブ体験を構築しようとする開発者、フリーランサー、そして小規模ビジネスオーナーにとって、これは些細な点ではありません。使いやすさ、コンバージョン、顧客の信頼に直接影響します。

厄介な点は、JavaScriptでのモバイル検出が単一の手法ではないことです。画面サイズを判定すること、ユーザーエージェントを読むこと、タッチ機能を検出すること、あるいはブラウザの機能サポートを観察することを意味する場合があります。各手法は別の問題を解決し、それぞれに限界があります。最良のアプローチは、”これはモバイル端末ですか？”と尋ねることではなく、むしろ “この端末とブラウザには実際にどのような能力が備わっているのか？” と問うことです。

JavaScriptにおけるモバイル検出とは？

コアとなるのは、JavaScriptでのモバイル検出のプロセスで、訪問者がモバイル機器をおそらく使用しているか、場合によってはどのようなモバイル環境を使用しているかを識別することです。この情報は、ナビゲーションの適応、操作の最適化、軽量な資材の読み込み、レイアウトの調整、もしくはタッチを重視した使用ケースの挙動の調整に用いられます。

多くの人はこれを画面が小さいかどうかをチェックするだけだと考えがちです。しかし実際にはもっとニュアンスがあります。デスクトップ上の小さなブラウザウィンドウは電話と同じではありません。大きなタブレットは一部のノートパソコンよりも広い画面を持つことがあります。折り畳み式のデバイスは、ユーザーがアプリと対話している最中に形状を変えることがあります。JavaScriptはこれらの状況を検出するのに役立ちますが、実際にどの信号を測定しているのかを理解している場合に限ります。

従来のモバイル検出は、ブラウザが送信するテキスト識別子であるユーザーエージェント文字列に大きく依存していました。長年にわたり、開発者はこの文字列を解析してデバイスがiPhone、Androidフォン、iPad、あるいはデスクトップブラウザかを推測してきました。その方法はまだ存在しますが、以前ほど信頼性は高くありません。プライバシーと互換性の理由から、ブラウザはユーザーエージェントデータを徐々に削減・標準化しています。MDNのユーザーエージェント文字列については以下を参照してください: ユーザーエージェント文字列。

現代のフロントエンド開発は、レスポンシブデザインと機能検出へとより傾斜しています。デバイスカテゴリについての広範な仮定をする代わりに、開発者は CSSのメディアクエリと JavaScript のチェックを用いて、ビューポートサイズ、タッチサポート、向き、ポインタータイプ、ネットワーク条件、またはブラウザ機能に対応します。これにより、よりレジリエントなアプリケーションが生まれ、エッジケースの失敗が減少します。

なぜ開発者は今もモバイル検出を使うのか

レスポンシブデザインがレイアウト作業の多くを処理してくれるとはいえ、JavaScriptでモバイルコンテキストを検出する実践的な理由はまだ存在します。ビジネスサイトは、より小さなビューポートで複雑な価格表を簡略化したいかもしれません。予約アプリは、ホバー駆動のインタラクションをタップベースの操作に切り替えるかもしれません。ダッシュボードは、制約されたモバイル接続のユーザーのために、必須でないスクリプトを遅延させることができます。

パフォーマンスの観点もあります。ユーザーがモバイル環境を利用している可能性が高いと分かっていれば、高解像度メディアを遅延読み込みしたり、インタラクションを圧縮したり、重いアニメーションを避けたりする選択をすることがあります。それは“劣った体験を提供する”ということではなく、より適切な体験を提供することを意味します。

デバイス検出と能力検出の違い

この区別は重要です。デバイス検出はデバイスが何であるかを判断しようとします。能力検出はブラウザが何をできるかを判断します。使いやすさを向上させることが目的なら、通常は能力検出のほうが安全です。

例えば、ホバーを使ったツールチップを表示するかどうかを知りたい場合、「モバイル」というユーザーエージェントを確認するのは弱い解決策です。デバイスがファインポインターを持つか、ホバーをサポートするかを問うほうが良いアプローチです。それが能力の質問であり、JavaScriptは広範なモバイルラベルよりもそうした信号をより効果的に扱えます。

JavaScriptにおけるモバイル検出の主要な要素

賢い判断をするには、主な検出方法とそれぞれが得意とすることを理解する必要があります。1つの方法ですべて完璧ということはなく、それぞれの用途に適したツールを適切に使うことで強みが生まれます。

ユーザーエージェント検出

ユーザーエージェント検出は、シンプルで馴染みがあるため、今なお広く使われています。JavaScriptでは、開発者はしばしば navigator.userAgent を検査し、Android、iPhone、iPad などのマーカーを探します。

function isMobileByUserAgent() {
  return /Android|iPhone|iPad|iPod|Opera Mini|IEMobile|WPDesktop/i.test(
    navigator.userAgent
  );
}

console.log(isMobileByUserAgent());

このアプローチは、特にレガシーなコードベースや分析スクリプトで迅速なヒューリスティックとして機能することがあります。既知のデバイスファミリーの大まかな分類が必要な場合にも役立ちます。

欠点は信頼性です。ユーザーエージェント文字列は偽装されたり、変更されたり、ブラウザ間で正規化されたりすることがあります。将来性が保証されず、新しいデバイスが登場するとしばしば壊れます。ビジネスロジックがそれらに強く依存している場合、保守が大変になります。

ビューポートと画面サイズ検出

より一般的なパターンは、ビューポートの幅を検出して、それに応じて挙動を適応させることです。これはレスポンシブウェブデザインと密接に連携し、しばしばユーザーが実際に画面上で体験するものと一致します。

function isSmallViewport() {
  return window.innerWidth <= 768;
}

console.log(isSmallViewport());

レイアウトや利用可能な画面面積が問題になる場合に有用です。サイドメニューが特定の幅以下で折りたたまれるべき場合、ビューポート検出は非常に合理的な解決策です。

とはいえ、これが何を意味するのかを正確に理解することが重要です。これはユーザーが電話機を使用しているかどうかを教えるものではありません。現在のビューポートが小さいという情報だけです。デスクトップブラウザをリサイズした場合も同じ結果になることがあります。多くのインターフェースの決定にはそれで問題ありませんが、デバイス分類には不十分です。

タッチ機能検出

タッチ機能をモバイル使用と同義とみなす開発者もいますが、それは誤解を招くことがあります。多くのノートパソコンはタッチ機能を搭載しており、モバイルブラウザでも予想外の挙動を示すことがあります。それでも、インターフェースで異なるジェスチャーやコントロールが必要な場合、タッチ機能は有用です。

function supportsTouch() {
  return (
    'ontouchstart' in window ||
    navigator.maxTouchPoints > 0 ||
    navigator.msMaxTouchPoints > 0
  );
}

console.log(supportsTouch());

これは特定のインタラクションの問題に答える場合に最も有効です。タップ対象を大きくしたい、スワイプのジェスチャー、タッチ向けに調整されたドラッグ挙動が必要な場合、この検査は役立ちます。訪問者が「モバイル」であるかどうかを判断しようとする場合、それだけでは広すぎます。

JavaScriptによるメディアクエリ

JavaScript は、CSS のメディアクエリで使用されるのと同じ種類の条件を読み取ることもできます。これは、スタイリングとスクリプトのロジックを整合させる最もきれいな方法の1つであることが多いです。

const mobileQuery = window.matchMedia('(max-width: 768px)');

function handleViewportChange(e) {
  if (e.matches) {
    console.log('Likely mobile-sized viewport');
  } else {
    console.log('Larger viewport');
  }
}

handleViewportChange(mobileQuery);
mobileQuery.addEventListener('change', handleViewportChange);

このアプローチは、UI が動的に変化する場合に特に有用です。ユーザーは電話を回転させたり、ブラウザをリサイズしたり、分割画面モード間を移動したりすることがあります。メディアクエリベースの検出を使えば、デバイスの状態が変わらないと仮定するのではなく、リアルタイムにスクリプトを反応させることができます。

ポインターとホバー検出

より新しく、見落とされがちな戦略の1つは、入力の挙動をチェックすることです。これは、多くのモバイル特有のUX問題が実際には入力の問題であることが多いからです。

const hasCoarsePointer = window.matchMedia('(pointer: coarse)').matches;
const supportsHover = window.matchMedia('(hover: hover)').matches;

console.log({ hasCoarsePointer, supportsHover });

粗いポインターは通常、指による操作を示します。一方、ホバーのサポートはマウスやトラックパッドの使用と関連づくことが多いです。これは、メニュー、ツールチップ、対話的コントロールの挙動を決定する際、広範なモバイル検出よりも有用であることが多いです。

一般的なアプローチの比較

最も効果的なモバイル検出戦略は、あなたが問おうとしている質問次第です。下の表は、各手法がどこで最も適しているかを示します。

手法	最適とされる用途	長所	制限事項
ユーザーエージェント検出、大まかなデバイス分類	大まかなデバイス分類	シンプルで馴染みがあり、実装が速い	壊れやすい、偽装されやすい、将来性が低い
ビューポート幅、レイアウトとレスポンシブ挙動	レイアウトとレスポンシブ挙動	画面空間に一致、保守が容易	実際のデバイス種別を特定しない
タッチ検出、タッチ専用のインタラクション	タッチ専用のインタラクション	ジェスチャーやタップ関連のロジックに有用	タッチはモバイルを意味しない
JavaScriptによるメディアクエリ、ダイナミックなレスポシブ挙動	ダイナミックなレスポンシブ挙動	CSSのロジックと同期、変化に反応	デバイス識別にはまだ焦点が当たっていない
ポインターとホバー検出、入力特化のUX調整	入力特化のUX調整	対話型デザインに優れている	完全なモバイル分類システムではない

「モバイル」がしばしば狙いとして間違っている理由

JavaScriptのモバイル検出で最も大きな誤りの1つは、すべての電話とタブレットを1つのカテゴリとして扱うことです。高速接続の現代の旗艦端末は、あるタスクで旧式のデスクトップ機を上回ることがあります。キーボード付きのタブレットは、電話よりもラップトップのように振る舞うことがあります。折りたたみデバイスは、狭いレイアウトと広いレイアウトを瞬時に切り替えることができます。

そのため、文脈を重視するアプローチのほうが効果的です。レイアウトを適応するにはビューポートロジックを、インタラクションを調整するにはポインターとホバー検出を、重いエフェクトを抑えるには機能とパフォーマンスの信号を組み合わせると良いでしょう。これにより、誤解を招く前提が減り、よりクリーンなアーキテクチャになります。

JavaScriptでのモバイル検出の始め方

始める最も簡単な方法は、完璧なモバイルの定義を追い求めるのをやめ、代わりに変更したい正確な挙動を定義することです。その枠組みは実装を単純化します。すべての可能なデバイスを特定しようとするのをやめ、特定のユーザー体験の問題を解決しているだけです。

例えば、ナビゲーションがタッチファーストデバイスで機能しなくなる場合は、ポインターとタッチ検出に焦点を当ててください。コンテンツが小さな画面で窮屈に感じる場合は、ビューポートベースのロジックに焦点を当ててください。第三者のスクリプトが小型デバイスで遅くなる場合は、画面幅、ネットワーク対応の読み込み、プログレッシブエンハンスメントに焦点を当ててください。

まずレスポンシブデザインから始める

JavaScriptの検出ロジックを書く前に、CSSでレイアウトがすでにレスポンシブであることを確認してください。多くのケースで、CSSのメディアクエリは JavaScript よりも問題を優雅に解決します。JavaScriptでのモバイル検出は、レスポンシブデザインを置き換えるのではなく、挙動をサポートするべきです。

視覚的なレイアウトと間隔がすでにレスポンシブである場合、あなたの JavaScript はより軽く、意図的になります。デバイス対応のロジックを追加するのは、インタラクション、パフォーマンス、または条件付き読み込みが真に必要なときだけです。

挙動変更には機能検出を使う

挙動を変えることが目標なら、機能検出が通常は適切な出発点です。これは、デバイスのラベルから推測するのではなく、ブラウザがある機能をサポートしているかを確認することを意味します。機能検出の詳細は: 機能検出。

ホバーサポートを基にしたメニューの挙動を適用する実用例を紹介します:

const canHover = window.matchMedia('(hover: hover)').matches;

const menuButton = document.querySelector('.menu-button');
const menu = document.querySelector('.menu');

if (canHover) {
  menuButton.addEventListener('mouseenter', () => {
    menu.classList.add('open');
  });

  menuButton.addEventListener('mouseleave', () => {
    menu.classList.remove('open');
  });
} else {
  menuButton.addEventListener('click', () => {
    menu.classList.toggle('open');
  });
}

これは、ユーザーがどのように対話するかに適応する強力なパターンです。タッチ対応のノートパソコンと電話は、ホバー依存のロジックを避けることがあり、デスクトップブラウザはより豊かなマウス対応の挙動を維持します。

必要に応じて信号を組み合わせる

信号が1つでは十分でない場合があります。モバイル使用についてより広い推定を行う必要がある場合は、チェックを組み合わせることで精度を高めつつ、確実性があるふりをすることを避けられます。

function isLikelyMobile() {
  const smallScreen = window.matchMedia('(max-width: 768px)').matches;
  const coarsePointer = window.matchMedia('(pointer: coarse)').matches;
  const mobileUA = /Android|iPhone|iPad|iPod|Opera Mini|IEMobile|WPDesktop/i.test(
    navigator.userAgent
  );

  return smallScreen && (coarsePointer || mobileUA);
}

console.log(isLikelyMobile());

これは厳格なセキュリティやビジネス上の必須ルールとしては使うべきではありません。ヒューリスティックです。ただしUIの調整には、分析や軽量体験のフォールバックカテゴリとして実用的です。

リサイズと向きの変更を監視する

一般的な間違いの1つは、ページ読み込み時に一度だけチェックして、それ以降更新しないことです。モバイル条件はページが開いている間に変化します。向きの変更、分割画面アプリ、折りたたみデバイス、ブラウザのリサイズはすべて環境に影響します。

function updateDeviceState() {
  const mobileSized = window.matchMedia('(max-width: 768px)').matches;
  document.body.classList.toggle('mobile-sized', mobileSized);
}

window.addEventListener('resize', updateDeviceState);
window.addEventListener('orientationchange', updateDeviceState);
updateDeviceState();

この種のイベントベースの更新は、現在の文脈に合わせてインターフェースを整合させます。ダッシュボード、ウェブアプリ、予約システム、長時間開いたままのツールには特に重要です。

よくある実装ミスを避ける

最初の誤りは、ユーザーエージェント検出を唯一の真実として使うことです。手軽に感じるかもしれませんが、時間とともに隠れたバグを生み出します。二つ目は、モバイル検出を用いて必須コンテンツをゲートすることです。スクリプトの推測が間違っていても、ユーザーはコア機能を失うべきではありません。

別のよくある問題は過剰な設計です。すべてのサイトが複雑なデバイス検出レイヤーを必要とするわけではありません。目的が小さな画面でカードを積み重ねることや、タップエリアを拡大することだけなら、CSSと数個のターゲットを絞った JavaScript チェックで十分です。ロジックを実際の製品ニーズに結びつけておきましょう。

ほとんどのウェブサイト向けの実践的なセットアップ

多くのビジネスサイトやウェブアプリには、以下のような現実的なアプローチが適しています:

レイアウトと間隔には CSS メディアクエリを使用する。
ビューポートまたは入力タイプに紐づく挙動には matchMedia() を使う。
タッチ、ホバー、ポインター関連のインタラクションには機能検出を使用する。
エッジケースや分析のためにユーザーエージェントのチェックを控えめに使い、主要戦略にはしない。

このワークフローは、フロントエンドを壊れにくくする柔軟性を提供します。テスト、説明、そしてプロジェクト間の保守も容易になります。

モバイル検出ロジックのテスト

テストは重要です。モバイル検出のバグはしばしばエッジケースに隠れます。電話幅にリサイズしたデスクトップブラウザでは問題なく見えても、実機のタッチ入力とブラウザのUI要素では挙動が異なることがあります。

素早いビューポートチェックにはブラウザのデベロッパーツールを使用しますが、可能な限り実機のスマホやタブレットでもテストしてください。向きの変更、キーボードオーバーレイ、タップ挙動、ホバー状態、低速条件下でのパフォーマンスに注意してください。あなたのサイトが顧客にも提供される場合、これらの細部が検出方法以上のユーザー体験を形づくります。

結論

JavaScriptにおけるモバイル検出は、完璧なデバイスカテゴリを識別することよりも、目的に適した信号を選ぶことです。ユーザーエージェント検出は限定されたケースでまだ役立つことがありますが、現代の開発はビューポートサイズ、機能サポート、タッチ機能、入力挙動に焦点を当てるほうが、より堅牢でUXの意思決定に正確、保守もしやすいです。

次のステップは簡単です。携帯電話で挙動が異なるサイトの一部（ナビゲーション、フォーム、メディア、対話的ウィジェットなど）を見直します。そして、本当に検出する必要があるものを問います。画面空間、タッチ、ホバー、あるいはおおまかなモバイルのヒューリスティックでしょう。これをはっきり答えれば、JavaScriptはよりクリーンになり、すべてのデバイスでユーザー体験が滑らかになります。

タグ: feature-detection

JavaScriptにおけるモバイル検出 — 機能優先