Cutting Edge

[アーティクル]
03/03/2015

クライアント側デバイスの簡易検出

Dino Esposito デバイスに合った Web サイトを作成する場合の基本的な選択肢は 2 つです。1 つは個別にモバイルサイト (以下「m-site」) を作成する方法、もう 1 つは現在の画面サイズやデバイスの向きに合わせてコンテンツや動作が動的に切り替わるようにサイトを作り直す方法です。どちらの方法も、あらゆる状況に理想的というわけにはいきません。したがって、最も優れているのは、従来どおり「状況に応じていずれかを選択する」というアプローチです。

m-site アプローチには大きな問題点が 2 つあります。まず、すべてのデバイス (スマートフォン、タブレット、ミニタブレット、従来型携帯電話、ファブレット、ウェアラブルデバイスなど) は、画面サイズを始めとして物理機能が異なります。つまり、「モバイル」を明確に定義する方法などありません。

数年前であれば、デスクトップコンピューターと他のすべてのデバイスを明確に区別できたため、m-site を用意することに意味がありました。現在では、「他のすべて」に分類されるデバイスの選択肢が多くなりすぎ、汎用的で統一性のあるモバイルサイトを定義することはほぼ不可能です。m-site のもう 1 つの問題点は、モバイルデバイスを利用するユーザーに別の URL (通常、m.yourserver.com など) に移動するよう求めることです。

もう 1 つのアプローチ、レスポンシブ UI にも問題があります。中でも重要な問題は、Web サイトをレスポンシブにする方法にあります。レスポンシブサイトは、一般にレスポンシブ Web デザイン (RWD: Responsive Web Design) を使ってビルドするという考え方に基づきます。RWD は、画面サイズとデバイスの向きを検出するために CSS メディアクエリのブラウザー実装を使用する開発アプローチで、CSS を切り替える分岐点 (基本的にはピクセル幅) を定義して、異なる CSS を自動的に適用できるようにします。

実際の効果は魅力的です。定義済みの分岐点を超えるようにブラウザーのウィンドウサイズを変更すると、利用可能な画面領域に適した外観にサイトが変化します。追加のコストをかけることなく、コンテンツはサイトへのアクセスに使用するすべての全画面モバイルブラウザーに適応します。RWD はデバイスに依存せず、現在および将来利用できるようになるデバイスの数や種類に応じて拡張可能です。

2014 年 12 月のコラム「レスポンシブ Web サイトでの効果的な画像処理」(msdn.microsoft.com/magazine/dn857356) で指摘したように、デバイスに依存しないことが RWD の強みですが、これは同時に弱みでもあります。RWD によって実現できる成果 (主にパフォーマンスとユーザビリティ) に顧客が満足すれば問題ありません。RWD の効果に満足し、作業を終わりにしてかまいません。

通常 RWD が適切に機能するのは、多くの対話やウィザードのようなワークフローを必要としないサイトにコンテンツを表示する場合です。用意するフォームが増えれば、ユーザーに選択や入力を求める場面が増えます。こうなると、RWD のような万能型アプローチは適切ではありません。では、次に目指すのは何でしょう。

業界が求めているのは、異なる URL を覚えなくても、適切なコンテンツをあらゆるデバイスに表示できる効率的な方法です。RWD は、この目的を実現するためによく使用されるアプローチの 1 つです。ただし、RWD では当然の如くデバイスに依存しないことが求められます。開発者は、デバイス検出を行うことを好みません。複数のブラウザーで Web サイトを同じように表示するために、ユーザーエージェント文字列を解析し、解析結果に応じて無数のコード分岐を用意しなければならなかった苦い思い出があります。

デバイス検出と機能検出は違う

すべてのブラウザーが標準オブジェクトモデルを使用してプラットフォームと機能を公開するようになるまでは、実際に Web サイトのページを要求しているブラウザーを判断するには現状ユーザーエージェント文字列を解析するしかありません。ユーザーエージェントの解析は大変な作業ですが、この作業をある程度軽減できるツールがいくつかあります。

このようなツールの 1 つが detectmobilebrowsers.com (英語) から入手できるスクリプトです。このスクリプトは、正規表現を使用して既知のモバイルキーワードのリストをチェックし、「モバイルかどうか」という疑問の答えを見つけます。この状況で「モバイルである」という答えは、単純にデスクトップブラウザーではないことを意味します。もう 1 つ Modernizr というツールもあります。このツールは、ユーザーエージェントを解析するプラグイン、タブレットの検出を試みるためにタッチイベントを検出するプラグインなど、多数のプラグインを備えています。

ただし、JavaScript で検出可能な機能以外を検出する場合、Modernizr は適切なツールではありません。ブラウザーがタブレットかスマートフォンかを JavaScript で検出することはできません。JavaScript を使用して可能なことはブラウザーの ID をブラウザーに問い合わせることだけです。しかし、大半のブラウザー (特にモバイルブラウザー) は多くの理由からこのことについて不正確な情報を返します。たとえば、ユーザーエージェントに基づいてブラウザーを特定しようとするレガシコードは、ブラウザーの ID を正しく認識しません。

Modernizr を利用する場合は、機能検出とデバイス検出の違いを意識する必要があります。この 2 つは、りんごとみかんぐらいの違いがあります。つまり、異なる目的で使用される別物です。要求を行っているデバイスのフォームファクターを判断する必要がある場合、機能検出は適切な方法ではありません。Modernizr にタッチイベントをチェックするように要求することで、JavaScript を使用してタブレットとスマートフォンを検出している開発者もいます。しかし、タッチ対応のデスクトップや、デスクトップとしても使えるタブレットなどが増えていることを考えると、タッチイベントをチェックするだけでは正しい答えを得にくくなっています。

ユーザーエージェントを分析して、利用可能な情報を簡単に返せるようにするには専門的なサポートが必要です。専門的なサポートはなんらかのフレームワークを意味し、市場に登場する新しいデバイスを追加するために絶えず更新が必要です。また、誤検知を正しく処理し、モバイルブラウザーから返される不適切な情報を採用しないように統計的な分析を使用する、優れた解析ロジックも必要です。率直に言えば、かなり大変な作業です。ただし、このような作業をサポートする企業があり、デバイス記述リポジトリ (DDR: Device Description Repository) というツールを提供します。

WURFL.JS エンドポイント

簡易形式の JavaScript デバイス検出により、単一ページアプリケーション (SPA: Single Page Application) など、クライアント側で処理の多くが行われる Web アプリケーションのユーザーエクスペリエンス (UX) が向上します。WURFL (wurfl.sourceforge.net、英語) は、サーバー側のソリューションとしてここ数年人気の DDR です。2013 年 8 月のコラム「ASP.NET MVC 4 でモバイル向けに最適化したビューを作成する (第 2 部): WURFL を使用する」(msdn.microsoft.com/magazine/dn342866.aspx) では、ASP.NET MVC アプリケーションでの WURFL の使用について取り上げました。

サーバー側 WURFL は、オンプレミスで使用するか、クラウドで DDR にアクセスするかに関係なく、ライセンス料金がかかります。WURFL チームは最近、JavaScript を使用してクライアント側から呼び出すことができる無料の HTTP エンドポイント (WURFL.JS) をリリースしました。WURFL.JS エンドポイント経由での JavaScript によるデバイス検出は、次の行を HTML に追加するだけで有効になります (ASP.NET では、マスターページやレイアウトファイルにこの行を置くこともできます)。

<script type="text/javascript" src="http://wurfl.io/wurfl.js"></script>

この行で参照されているリソース (wurfl.js) は、オンプレミスにダウンロードしてホストしたり、クラウドサイトにアップロードできる、プレーンな JavaScript ファイルではありません。これは JavaScript に似た HTTP エンドポイントで、JavaScript オブジェクトをドキュメントオブジェクトモデル (DOM) に直接挿入します。ブラウザーがこのエンドポイントに対して呼び出しを行うと、実際には以下のようなコードが DOM に含まれるようになります。

var WURFL = {
  "complete_device_name":"iPhone 5",
  "is_mobile":false,
  "form_factor":"Smartphone"};

ブラウザーは要求時に自身のユーザーエージェント文字列を送信します。サーバー側 WURFL フレームワークのサポートにより、エンドポイントがこの文字列を分析し、要求元のデバイスに関する主要な情報を判断します。その後、この情報は WURFL というグローバルオブジェクトの 3 つのプロパティにフォーマットされます (図 1 参照)。興味深いことに、Web ページがネイティブモバイルアプリの WebView コンポーネント内に表示されているかどうかを、WURFL.JS で確実に検出することもできます。form_factor プロパティが App を返す場合は、Web ページが WebView コンポーネント内に表示されています。

図 1 WURFL.JS によって DOM ページに挿入されるデバイス情報

プロパティ	説明
complete_device_name	検出したデバイスを説明する名前。通常は、ベンダーとデバイスの名前 ("iPhone 5" など)。
form_factor	定義済み文字列の 1 つ。Desktop (デスクトップ)、App (アプリ)、Tablet (タブレット)、Smartphone (スマートフォン)、Feature Phone (フィーチャーフォン)、Smart-TV (スマートテレビ)、Robot (ロボット)、Other non-Mobile (その他、モバイル以外)、Other Mobile (その他、モバイル) など。
is_mobile	ブール値。デバイスがデスクトップ以外かどうか。

WURFL.JS は、多くのキャッシュを利用して迅速な応答を確保しています。開発段階では、debug=true を URL に追加することで、キャッシュをオフに切り替えることができます。DOM の ready イベントが発生したら、WURFL オブジェクトを安全に使用することができ、クライアント側の機能を有効または無効にしたり、オプションのデータをサーバーに要求できるようになります。

WURFL.JS による RWD の強化

ページにビデオが含まれている場合に、パフォーマンスの理由からスマートフォンではビデオを再生できないようにするとします。プレーンな RWD では、このような調整を行うことはできません。一定の分岐点よりも小さくなったらビデオプレーヤーを非表示にすると、デスクトップブラウザーのウィンドウサイズを小さくした場合も再生できなくなります。このような場合、以下のように RWD と一緒に WURFL.JS を使用すると問題が解決されます。

<script type="text/javascript">
  $(document).ready(function () {
    if (WURFL.form_factor == "Smartphone") {
      $("#video_player").hide();
    }
  });
</script>

まず、ページを読み込み、RWD レイアウトに従ってスタイルを設定します。次に、WURFL を使用してフォームファクターをチェックし、ビデオプレーヤーを非表示にします。デスクトップのブラウザーがスマートフォンサイズに変更された場合は依然としてビデオを再生できますが、実際のスマートフォンの場合は再生できなくなります。以下のコードは、先ほどのコードを少し改良したものです。

<script type="text/javascript">
  $(document).ready(function () {
    if (WURFL.form_factor != "Desktop" &&
        WURFL.form_factor != "Tablet") {
      $("#video_player").hide();
    }
  });
</script>

この場合、デバイスがデスクトップまたはタブレットの場合を除いて、すべての場面でビデオプレーヤーが非表示になります。WURFL.JS にとって興味深いシナリオは他にもあります。現在稼働中の RWD サイトがあり、このサイトではすべてのビューがサーバー (ASP.NET MVC アプリケーション内など) で生成されるものとします。

やがて、スマートフォンのユーザーから適切なエクスペリエンスが得られないというフィードバックが寄せられます。こうしたスマートフォンユーザー向けにまったく新しい m-site を作成することを検討すべきでしょうか。2013 年 8 月のコラムで説明したように、WURFL のサーバー側サービスを使用できる場合は、同じサイト内にビューの切り替え機能を簡単に実装することができます。

このアプローチによって、必要な作業の大半を省略できます。このアプローチを採用しない場合は、2015 年 1 月のコラム「Mobilize an Existing Web Site」(msdn.microsoft.com/magazine/dn890366、英語) でデモを行ったように、別の独立したサイトを作成してリダイレクトメカニズムを実装するほかありません。同じ URL で標準サイトと m-site を表示する場合は、依然としてサーバー側での適切なデバイス検出が必要です。

WURFL.JS を使用することによって生じる二次効果として、WURFL オブジェクトからデバイスの情報を収集して、Google Analytics に渡すことができるようになります。その結果、ユーザーがサイトを表示する方法や最も使用されているデバイスを即座に測定できるようになります。新しい analytics.js にアップグレードする場合は、以下のコードが必要です。

<script type="text/javascript">
  /* Universal tracking code of Google Analytics:
    see http://goo.gl/HakYmP
  */
  ga('create', 'UA-XXXX-Y', 'auto');
  ga('send', 'pageview', {'dimension1': WURFL.form_factor});
</script>

従来の Google Analytics スクリプト (ga.js) を使用している場合は、以下のように少し変更が必要です。

_gaq.push(['_setCustomVar', 1, 'form_factor', WURFL.form_factor, 1]);

Google Analytics には、モバイルやタブレットのトラフィックを追跡するための多くの組み込み機能があります。モバイルトラフィックにはタブレットのトラフィックも含まれているため、この場合もスマートフォンとタブレットをすぐに区別することはできません。WURFL.JS により、当初は Google Analytics に含まれていない便利な情報が追加されるため、データの予測ではなく実際の数値だけに注目するカスタムレポートを作成できます。ただし、WURFL.JS はデータプロバイダーにすぎません。Google Analytics と連携するだけでなく、他の分析ツールと併用することもできます。

まとめ

多くの場合、RWD サイトの実装はプレーンな ASP.NET Web フォームの Web サイトの実装に比べて困難です (よりコストがかかります)。RWD のメリットに惑わされてはいけません。RWD は、デスクトップや高性能デバイスでは優れたソリューションになりますが、ビジネスにとって小型のデバイスに効率的に機能を実装することが不可欠の場合は適切でないこともあります。RWD はデバイスに依存しないことを重視しています。つまり、RWD Web サイトでは、デスクトップブラウザーで 480 x 360 ピクセルにサイズ変更したウィンドウと、全画面の小型フィーチャーフォンに同じコンテンツを提供します。

この 2 つでは、ハードウェアも接続状況も大きく異なります。客観的には、パフォーマンスが RWD の弱点です。とは言え、すべてのサイトでパフォーマンスが問題になるわけではありません。パフォーマンスの問題は、主に低性能デバイスに影響します。一般的なサイト閲覧者が低性能デバイスを使用していなければ、RWD に移行すれば満足のいく結果を得られます。

ただし、近い将来、扱うデータの量やユーザーの期待値が高まることが考えられます。その結果、多くのデバイスでのレンダリングが不適切になります。理想的には、アドホックなビューが必要です。今回は、基になるデバイスを検出する際に、軽量かつあまり目立たないクライアント側ソリューションとして WURFL.JS を取り上げました。

WURFL.JS とは、DOM にデバイス情報 (具体的にはフォームファクター) を挿入するエンドポイントです。つまり、WURFL.JS によって、デバイスがデスクトップ、タブレット、スマートフォン、従来型携帯電話、Xbox、またはネイティブアプリであるかどうかがわかります。フォームファクターの情報に基づいてページに少し変更を加えたり、フォームファクター情報を分析ツールに提供することも可能です。

フォームファクターごとにサイトのパフォーマンスを把握することは、サイトが成功するかどうか、改良すべき領域があるかどうかの重要な指標になります。Google Analytics と WURFL.JS を併用する方法の詳細については、bit.ly/1u0lpGB (英語) を参照してください。

Dino Esposito は、『Microsoft .NET: Architecting Applications for the Enterprise』(Microsoft Press、2014 年) および『Programming ASP.NET MVC 5』(Microsoft Press、2014 年) の共著者です。JetBrains の Microsoft .NET Framework および Android プラットフォームのテクニカルエバンジェリストでもあります。世界各国で開催される業界のイベントで頻繁に講演しており、software2cents.wordpress.com (英語) や Twitter (twitter.com/despos、英語) でソフトウェアに関するビジョンを紹介しています。

この記事のレビューに協力してくれた技術スタッフの Jon Arne Saeteras に心より感謝いたします。

Cutting Edge

クライアント側デバイスの簡易検出

デバイス検出と機能検出は違う

WURFL.JS エンドポイント

WURFL.JS による RWD の強化

まとめ

その他のリソース