ふろしき Blog

コンテンツサービスを科学する株式会社ブートストラップ代表のブログ

負け組なモバイルWebは、これから本当に復活するのか?Googleが考える次のアーキテクチャ

Google I/O 2015でのセッション「The Next Generation Mobile Web(次世代のモバイルWeb)」がそこそこに激アツな気がしたのですが、予想に反し、あまり注目を集めていません。

わかります。大衆向けなメディアだと、AndroidやVR/AR、Google Photosのようなわかりやすいキーワードの方が注目されるでしょう。エンジニア向けメディアであっても、昨今のモバイル技術の状況を鑑みて、ネイティブアプリの方を扱いたいと感じるのが当然です。

先日、某懇親会で「え、モバイルをWebでやっているのですか?それ、完全に負け組じゃないですか」と言われ、そこまで印象が悪いものかと心を痛めました。負け組とか、Webがかわいそうじゃないか。

そんな状況というのもありまして、先日の「第58回HTML5とか勉強会」では、あえてGoogleらが考える「次世代モバイルWeb」のトークをさせて頂きました。そして、驚くほどの反響をいただけました。せっかくなので、その中身について、本エントリーで簡単にご紹介します。

モバイル上のWebは、何がダメなのか?

現状のモバイルWebの問題点は何か?ネイティブにはできて、Webにはできないユースケース、ユーザビリティの阻害要因は何でしょうか?技術的な面だけで見ると、以下3つのポイントが考えられるでしょう。

1. ブックマークが役に立たない

PCとモバイルとでは、アプリが担う役割の大きさが異なります。モバイルでは、一つのアプリに多くの機能やユースケースを与えてはいけません。UIの数は限定し、ユースケースを跨ぐ場合はディープリンクを活用して別のアプリへ移動する。Facebookがメッセーンジャー機能を独立したアプリにしていることからも、その状況が伺えるでしょう。

PCの時代のブックマークに相当していた役割が、モバイルではホームスクリーンへと移った。そして、ブラウザを起動し、ブックマークを使ってWebサイトへ行くというのは、ユーザにとっては不便でしかありません。モバイルWebにおいて、ブックマークはその役割を果たせないのです。

2. 閉じられたら何もできない

ブラウザとネイティブとでは、その上で動いているアプリのライフタイムに決定的な違いがあります。ネイティブアプリは閉じられてもバックグラウンドで処理が行えますが、ブラウザは閉じられると、少なくともクライアント上では何もできなくなります。

PCの時代、コンピューターは必要な時だけ起動され、不要になれば電源を落としました。ブラウザも同様に、必要に応じて起動され、不要になれば閉じられました。しかしモバイルの場合、コンピューターもアプリも、常時起動が当たり前です。使わない時に電源を切る、という活用方法はあまりしません。そうなると、バックグラウンド処理があり、必要に応じてユーザへ通知が行えるネイティブの方が、ユーザに対して優しくなれます。ブラウザという仕組みが、モバイルのユースケースと合わないのです。

3. パフォーマンスが悪い

「ブラウザ vs ネイティブ」を論じる時、非常によく耳にするのがパフォーマンスの悪さ。大きさや重さに制約があり、また使える電力にも制限がある以上、モバイルはPCを超えることなんてできません。

電力消費を抑えようと、ネットワークインタフェースは通常時にはスリープされ、CPUリソースも制限されます。そんな状況下で、出来る限り高いパフォーマンスを求めようとなると、やはり柔軟性の高いネイティブを選ぶことになるでしょう。

次世代モバイルWebでのアプローチ

ここまでに挙げた3つの問題点。Google I/Oでのセッション「The Next Generation Mobile Web」にて、その改善方法を提案しています。

1. WebにモバイルらしいUIを与えよう

ブックマークやブラウザのUIが問題だというのなら、それを根本的に変えてしまおうという案があります。それが「Add To Home Screen」です。Webサイトをブックマークするでなく、ホームスクリーンへランチャーアイコンとして登録する。そしてそこから起動された際は、モバイルらしいUIを被せてWebページを表示させることで、ブラウザが抱えていてユーザビリティの問題を解消しようというものです。

その実装には、W3CのWeb標準「Web Application Manifest」を使います。この機能により、モバイルらしいランチャーアイコンを登録させたり、モバイルだと嫌がられがちなLandscapeを使えないようにしたり、邪魔なアドレスバーを無くしたりと、Webに足りていないものを埋めていきます。

2. Webにモバイルらしいライフタイムを与えよう

モバイルは、ネイティブアプリにあるようなバックグラウンド処理を必要としています。ブラウザはタブの有無に依存せず、独立して処理を行える仕組みを持てば、ネイティブと同じ時間をユーザと共にすることができるでしょう。その解決策として期待されているのがWeb標準「Service Worker」です。

Service Workerは、ブラウザ内で独立したローカルプロキシとして動くことで、ネットワークに依存せずにWebページを扱えるようにすると共に、Pushサービスからメッセージを受け取りユーザに通知するといった活用方法が期待されています。元々は、オフラインWebアプリを作るためのWeb標準「AppCache」の置き換えとしての役割が期待されていましたが、Service Workerはライフタイムの問題というレベルで着眼し、解決を試みています。

3. ユーザにストレスの無いパフォーマンスを目指そう

最後にパフォーマンスについて。これはどのようにして解決すべきかという具体的な方法は説明されませんでしたが、目指すべき指標のようなものが説明されました。ひたすら速いを目指すというよりも、ユーザがパフォーマンスの劣化を意識しないという基準のようなものがあり、そこを満足するように努力していこう、というものでしょう。それが「RAIL」です。

RAILは、Reaction(応答の速さ)、Animation(アニメーションの速さ)、Idle(処理無し状態を作る時間)、Load(読み込みの速さ)の略称です。これらが一定の基準を満たせば、ユーザは「パフォーマンスの劣化を気にしない、遅さを感じない、ということです。速さの基準を満たせれば、ネイティブであることにこだわる必要はない。詳しくは過去の私のブログでも紹介しているので、気になる方は確認してみるといいでしょう。

furoshiki.hatenadiary.jp

最後に

まとめると、モバイルWebはこう作るといい感じ!ということでしょう。

f:id:furoshiki0223:20150615173525j:plain

このセッションで語られた内容は、モバイルWebがアーキテクチャの転換期であることを予感させられます。実態としてはアプリストアの影響が強かったり、Androidのバージョンのフラグメント問題が解決されていないため、すぐにそうなれるとは思えません。ただ、長くても2年後には、何かしらの変化が期待できそうですね。

時期が来ても、ネイティブアプリが全て失われるということでもなく、互いの良さを活かす形で共存していくのだろうと私は考えています。なんでもかんでもネイティブにするのではなく、Webに向いている所はWebでやるという、今のPCみたいな状況に戻るのではないかと思うのですが、さて、どうなるんでしょう。どちらにせよ、Webが複雑化するのは避けられ無さそうですね。

こちらが発表スライドです。もう少し細かく、説明していますので、併せてご確認ください。

Webのパフォーマンスモデル「RAIL」とは何か?

ここ数年のうちに、人々が利用するメインコンピューターは、デスクトップからモバイルへと移りました。

少ないハードウェアリソース、不安定なネットワーク、逼迫するバッテリー消費、シンプルなユーザインタフェース、開発者はこうした制約の中で、Webサイトを制作することが求めらるようになりました。Webのパフォーマンスに関する考え方も大きく変化があったのですが、我々は具体的に何を基準にし、どの程度にチューンすれば良いのでしょう?その答えが、パフォーマンスモデル「RAIL」にあります。

RAILは、開発者向けカンファレンス「Google I/O 2015」にて発表されました。厳密にはI/Oが初というわけではありませんが、実に2桁近いセッションでこのキーワードが紹介されています。今後は一般的になっていくのでしょう。

モバイル時代のWebのパフォーマンスモデル

一見するとRubyと関係しそうですが、全くコンテキストの異なるキーワードです。RAILとは、モバイル時代のWebのパフォーマンスの4大要素、Response、Animation、Idle、Loadの頭文字からとった略称です。それぞれの項目が、一体何を意味しているのか紹介してみます。

1. R : Responseは100ms未満になるように!!

ユーザがWebページに対して何かしらの操作を行った場合、その反応は100ms未満で起きるような作りにしましょう。決済完了ボタンなど、速くし過ぎることで「失敗してしまった感」を与えるケースもありますが、概ねこの考えで間違いはないでしょう。

2. A : Animationは16ms毎になるように!!

Webページ上で何かしらビジュアル面で動きを与える場合、その動きは16ms毎で更新されるような作りにしましょう。毎フレームごとにJavaScriptを呼び出す場合は出来る限りGCを避けるようにしたり、CSSを活用するなど、アニメーションを速くする対策を施しましょう。

3. I : Idleは100ms未満で起きるように!!

Webページ上でJavaScriptを活用して何かしらのスクリプトを動かす場合は、100ms未満でメインスレッドにも処理が行えるような余裕(=Idle)を持たせる作りにしましょう。JavaScriptの処理実行時は、ユーザの操作をブロックしてしまうため、適度にメインスレッドへ処理が帰るように工夫が必要です。これは1のResponseと、同じ理由と言えます。

4. L : Loadは1000ms未満に終わるように!!

ハイパーリンクやサブミットボタンが押下された時のWebページ読み込みは、アクションを起こしてからDOM生成までを1000ms未満で完了するように作りましょう。

守れないとどうなるのか?

ここまで理由もなく「◯◯秒未満で!」と繰り返してきましたが、一応は根拠と呼べるものがあります。それが、以下2つの定説です。

アニメーション反応応答と人間の認識

f:id:furoshiki0223:20150531011240j:plainThe Illusion of Motion - Paul Bakaus' blog

滑らかなアニメーションが行える周期は、一秒間に60回の更新が行われた状態、ということになります。また、秒間24回よりも小さな更新で、ちらつきを感じるようになるとも言われています。

アクション待ちに対する人間の心理

f:id:furoshiki0223:20150531011921j:plainO'Reilly Media - Technology and Business Training

すぐに応答したと感じられるのは100ミリ秒であり、また1000ミリ秒以上経過すると、心理的なコンテキストが変わってしまいます。パフォーマンスコミュニティにおいては「250ミリ秒という時間がユーザのエンゲージメントにとって重要」という認識を持っているようです…が、少なくとも、ResponseとIdleのようなWebページ上での部分的な反応については100ミリ秒で、LoadのようなWebページの内容が完全に変わってしまうような反応についても、心理的コンテキストが変わらない1000ミリ秒で次の情報へ意識を導かなくてはいけない、ということが言えるでしょう。

RAILに足りていないこと

RAILはあくまで、従来のWebサイトのコンテキストで語られています。しかし実態として、Android Chromeはネイティブアプリと同じユースケースで活用できるよう、機能の拡充が進められています。特にService Worker + Notificationの登場で、Webにブラウザを閉じた後にも実行し続けるという、まさにモバイルのネイティブのようなライフサイクルを与えることができるようになりました。Webサイトというより、ネイティブアプリに近い課題が生じることになります。

f:id:furoshiki0223:20150531014036j:plainGoogle I/O 2015サイトがまさにその好例

RAILには含まれていない重要なポイントとしては、「バッテリー消費」なんかが挙げられるでしょう。バッテリー消費で一番問題になるのはディスプレイ、二番目はネットワークと言われ、特に後者については様々なノウハウがあります。Androidアプリにおいても、断続的に飛ばしたいXHRをBatch化させたり、pollingを廃するなど、ネットワークインタフェースの利用時間を減らすような努力が求められています。ブラウザ上で動くアプリも、ブラウザを閉じている間までネットワークの利用が可能というのであれば、当然ですが意識しなくてはいけません。既にApache Cordovaなんかでは、こういうTIPSが利いていたりするのですが…

少なくともWebサイトにおいては十分価値のある考え方なので、ぜひとも、RAILに沿って実践してみると良いでしょう。興味がありましたら、「High Performance Browser Networking」の著者であるIlya Grigorikのスライドをチェックしてみてください。

docs.google.com

「Fast ASP.NET Websites」の著者であるDean Alan Hume氏のプレゼンスライドも参考になるでしょう。こちらは具体的な戦略まで書かれているため、入り口としては非常に有益です。

f:id:furoshiki0223:20150601010303j:plainFaster Mobile Websites - Speaker Deck

Google Chromeの開発者が語るこれからのWebに必要なこと、ちょっとした懸念点とか

ーーーー HTML5はネタが出尽くした。あとは、IE8やAndroid2.X標準ブラウザのような、レガシーブラウザがいなくなればいいだけではないか?

私は最近、そんな言葉を耳にすることがあるのです。しかし、ブラウザ開発者たちは未だに、そんなことを微塵も感じさせないほど働いています。まだまだ進化の速度を、落とすわけにはいかないようです。2014年06月14日に開催された「HTML5 Night」にて、Google Chromeの開発者である及川卓也氏の口から、これからのChrome開発について語られました。

f:id:furoshiki0223:20150204165554j:plain

本記事では、及川氏の講演のダイジェストをお届けします。

今のChromeには何が不足しているのか?

Chromeは2013年の4月に大事な出来事がありました。Appleと一緒に開発していた、「WebKit」をフォークしました。それが、Chroniumと同様なオープンソースのレンダリングエンジンである、「Blink」です。Blinkは、HTML5などのWebプラットフォーム機能を実現しています。

Blinkプロジェクトでは、2014年冒頭に、今年は何をしようかということを話し合いました。Blinkはオープンソースのプロジェクトなので、話し合いは全て「blink-dev」という、メーリングリストで行われます。これがメールスレッドになるのですが、書かれていることはだいたいこんな感じです。

f:id:furoshiki0223:20150204165555j:plain

ざっくり言いますと、「モバイル」が大事ということです。

ご存知の通り、モバイルの方がデスクトップより売れているし使われています。そういう状況ですが、モバイルのアプリを開発する立場からすると、残念ですが、Webよりもネイティブアプリの方が良いと言われています。

そこでとある機関が、モバイル開発者になぜHTML5を使わないのかという、アンケートをとりました。こちらがその結果です。

f:id:furoshiki0223:20150204165556j:plain

不満は主に、パフォーマンスが悪い、APIが足りない、ツールが整っていない、ということです。

最大の問題であるパフォーマンス、「速いことは正義」です。これについては色々とやってはいますが、HTML5はあまり関係ないので、Blink Contributorsが集まった時の資料「Blink On 2: Mobile@60 FPS」を御覧ください。


Blinkは「API不足」をどう改善しているのか?

ハードウェアアクセスが大切ですし、痒い所に手が届くオフライン制御も大切です。Blinkでもいま取り組んでいます。ServiceWorker、WebMIDI、WebAudio。全ては紹介しきれないので、ServiceWorkerについて触りだけお話します。

ServiceWorkerで何が出来るのかというと、より高度なオフライン機能、ネイティブアプリに追いつく、AppCacheからの学びを活かすような設計となっています。オフラインと言っても、完全にオフラインという場合だけではなく、ネットワークが不安定であったり、しょっちゅう切れたりなど、今はそのような異なる状況に対応したWebアプリを書くのがとても難しかったりします。

f:id:furoshiki0223:20150204165557j:plain

仕組みとしては、WebサイトからインストールされたJavaScriptが、独立したWorkerスレッドで動作し、Webサイトからのイベントハンドリングを実現する、というものです。つまり、頭の良い、In-browserなHTTPプロキシです。これが、インターネット上のページとキャッシュの、両方を制御できるということです。

詳しくは、こちらをご確認下さい。


Blinkは「ツールの不足」をどう改善しているのか?

HTML5は、様々な要素の統合が難しい、最新のUI/UXが作りにくい、成熟したフレームワークが不足しているというのが、アンケートの結果から得られました。これらについても、Blinkでいままさに取り組んでいます。WebComponents、Polymer、WebAnimation。こちらも全ては紹介できないので、WebComponentsとPolymerについて。

WebComponentsとPolymerは、Webにコンポーネント技術を取り込むためのものです。例えば、Google Chart APIの場合、グラフを表示するための情報を、JavaScript上に書き込まなくてはいけませんでした。

f:id:furoshiki0223:20150204165558j:plainf:id:furoshiki0223:20150204165559j:plain

WebComponentsを採用すると、グラフを意味するgoogle-chart要素の属性に、グラフの表示に必要な情報書き込むだけです。

f:id:furoshiki0223:20150204165600j:plain

Googleのサービスを利用するためのWebComponentsが、GitHub上にもたくさん用意されています。

https://github.com/googlewebcomponents
f:id:furoshiki0223:20150204165601j:plain

以上です。応援宜しくお願いします、ご清聴ありがとうございました。

Googleが力を入れているのは?

この講演はGoogle I/O 2014が開催される前に行なわれたものですが、一貫して「Service Worker」「WebComponents」を推しているようですね。オフラインの機能でネイティブの上を行こうとService Workerに取り組みつつ、ツールの不足をWebComponentsを活用することでGoogleのサービスを提供していくことで解決しようという方向性のようです。先日の「第49回HTML5とか勉強会」でも、一貫して同じことに触れていました。

どちらも彼らのビジネスと上手く協調できているし、実に理にかなっています。ただ、Microsoftさん的には納得いかないところもあり、エコシステム的にまだまだ問題もあるようです。このあたり、Microsoftさんは結構後手に回ってしまうので「なんだよまたIEが遅れているのかよ」「本当にIEだけ機能が全然実装されねぇよな」という空気感が出てしまうのが目に浮かびます。ただ、最近IEが実装できない機能って、「技術的な理由でできない」というより「政治的な理由でできない」が中心なんですよね。

開発者たる我々からすれば、そんなことは本当にどうでもいいことなので、Microsoftさんには社内の他の製品との利害関係を整理してしがらみを捨てて、一緒にWeb標準を育てていけるよう頑張って欲しいところです。彼らは最近自分たちのことを「俺たちはもうトップの企業じゃない。そこらのチャレンジャー企業と何にも変わらなくなった」と言ってて、社内的にもそんな空気感がただよい始めているみたいなので、変な形で既存利益に拘るようなことはしないだろう、と信じています。

ただ、一点。Google的にパフォーマンスは、Web標準(WebPerf-WG)の「◯◯ Timing」系APIで解決しようという意思はあまり感じられません。あくまで、彼らの提供している独自のサービス「PageSpeed Insights」を推していたりします。ただ、このツール、彼ら自身もまだまだ機能が十分に足りていないという認識を持っているようです。Google I/O 2014でPaul Lewis氏のセッションでも、途中からこのツール使わず、他で提供しているサービスを利用してパフォーマンス計測の一連の流れをデモしていました。。「検索に0.02秒かかりました」とか出してきて「聞いてねー(笑)」と思うほど、パフォーマンスが良かったアピールしてくるGoogleさんの、らしくない意外な一面ですね。

アプリケーションプラットフォームと呼ぶには、まだまだ色んな問題が残っているんですね、、、Webって。これからが楽しみです。

Chrome for Business - 企業向けブラウザとしてのChromeの機能、まとめ

Google Chromeは、どちらかと言えばコンシューマー向けブラウザという印象が強いでしょう。実際にそれを裏付けるデータがあります。「StatCounter GlobalStats」の世界ブラウザシェアの内容を結果を確認すると、以下の結果が得られます。

f:id:furoshiki0223:20140113195217p:plain
青がInternet Explorer緑がChrome

企業の営業時間にIEのシェアが上がり、休日にChromeのシェアが上がるあたり、やはりChrome=コンシューマーに利用される傾向がある、IE=企業に利用される傾向がある、と結論付けざる得ないでしょう。実際にこれらのブラウザは異なる指針を持って開発が進められており、Chromeは短いリリース頻度による最新技術指向、IEは長いサポート期間による安定指向という傾向があります。

とはいえ、Chromeもエンタープライズ市場を捨てているわけではありません。Googleは「Chrome for Business」というサービスを提供しており、企業への導入に必要な様々な機能を提供しています。

このサービスはやや煩雑で、その理解に時間を要します。そこで、本記事ではこのサービスについて、要件定義段階で判断材料に使えそうな情報を掻い摘んで紹介します。細かい部分は端折ってはいますが、サービスの全体像についてある程度把握できよう整理しています。

  1. インターネットを必要としないインストール
  2. ポリシーによる運用環境の管理
  3. 古いIE向けWebコンテンツの維持
  4. サポートライフサイクル

1. インターネットを必要としないインストール

企業向けの場合、インターネットに接続されていない環境下でブラウザのインストールが求められる場合が多いでしょう。Googleは、Chromeをローカルのみでインストールを完結できるMSI型のインストーラーを提供しています。

ダウンロードは、以下のサイトで行えます。
https://www.google.com/intl/ja/chrome/business/browser/admin/

「Chrome MSI をダウンロード」をクリックすれば、利用許諾が表示されます。「合意してインストール」という記述がありますが、これは表現として誤りです。このボタンをクリックすると、ファイルのダウンロードが始まるだけで、インストールが開始されるわけではありません。

f:id:furoshiki0223:20140113210112p:plain

あとは、ダウンロードされたファイル「GoogleChromeStandaloneEnterprise.msi」を、インストールしたいコンピュータへ配布し、実行するだけで完了です。

ただ、これはあくまでローカルでインストールができる方法でしかありません。大規模な企業システムへ適用する場合、グループポリシー管理やレガシー資産の維持が必要となるでしょう。これらの対策は、次章以降で説明します。

2. ポリシーによる運用環境の管理

開発者が意外と見落としがちなのが、IT管理者によるポリシー管理の有無です。

企業系システムでは、IT管理者側でシステム利用者ができること・できないことを細かく制御したいという要望に、答えることが求められることもあるでしょう。Firefoxはシステムごとに利用するブラウザをバイナリレベルで分けて、ガチガチにカスタマイズして動作させることが可能です。しかし、ChromeやIEは基本的に一つのOSに一つのバージョンしか利用できないため、システム単体だけで判断が行えないというリスクを負っています。

IEは、Active Directoryの「グループポリシー」やユーザによる「設定」により、ブラウザの動作を制限させることができます。特にWindows7世代は、この機能に頼って古いシステムを動かしているケースも少なくありません。Chromeはこの代替手段として、「Chromeポリシー(※ Group Policy APIと呼んでいる箇所もあり)」という独自のポリシー管理機構を持ちます。

以下のURLにて、説明されています。
https://support.google.com/chrome/a/answer/187202

★ ポリシーの設定値

Chromeでは、200を超える細かいポリシーの設定を持ちます。Chromeブラウザから「chrome://policy」にアクセスすると、ポリシーの設定値を確認できます。

それこそ、アクセスできるURLのホワイトリスト・ブラックリスト、ブックマークバーを有効化させるかといった基本的な設定から、プロキシサーバのURL、プラグインを有効化させるサイトのURLに至るまで、幅位広い範囲にその影響は及びます。

なお、個々のポリシーの意味は、以下のURLにて説明されています。
http://www.chromium.org/administrators/policy-list-3

★ 設定を行う手段

ポリシーは、Chromeでは以下3つのレイヤーから操作できるようにしています。

f:id:furoshiki0223:20140114015656p:plain

最上位はChromeでログインすることにより反映される設定で、Googleアカウントレベルで指定するポリシーです。それを、OSが持つActive Directoryなどにより指定されたポリシーで上書きします。OSに依存しているのでなく、OSで管理されたアカウント単位で設定するものです。そして最終的には、デバイス/OSレベルで個別設定されたポリシーで上書きされます。レジストリレベルと考えるとしっくりくるでしょう。

言うまでもなく、最上位のクラウドベースは、インターネットがあること前提です。IT管理者が、「http://admin.google.com」へアクセスし管理対象のGoogleアカウントユーザの設定を指定します。

インターネットに依存させないレベルでは、OSユーザポリシー、マシンポリシーなどが該当します。これらはOSが持つ管理機構次第であるため、別途OSごとにその設定方法を理解しておく必要があるでしょう。マシンレベルにまで達すると、Windowsの場合、システム利用者側で設定をインストールする手間が発生するため、規模によっては現実的でないかもしれません。

筆者の感覚として、国内のエンタープライズに適した利用方法は、イントラネット内で完結し強制力も高い「OSユーザポリシー」あたりが妥当に思えます。

ここで紹介した以外には、帯域外管理を利用してポリシーの設定をプッシュさせるなんていう方法も提案されています。Googleアカウントにログインしていなくても設定が強制されるため、システム利用者の環境をガチガチに固めることが可能です。

以下のURLに、Google公式ドキュメントがあります。
https://support.google.com/chrome/a/answer/187202

3. 古いIE向けWebコンテンツの維持

Microsoftがバージョン依存化しざる得ないことを暗に認めてしまっているIE8以下向けに作られたWebコンテンツ・Webシステムは、Chromeの場合そのままでは動かない可能性があります。

企業向けChromeは、こうした古い資産の維持を運用しなくてはいけないことを想定しており、IEへの切り替え、エミュレートするバージョンの指定が行える仕組みを持ちます。

これを、「レガシーブラウザサポート(LBS)」といいます。
https://support.google.com/chrome/a/answer/3019558?hl=ja

考え方としては、以下のイメージです。
f:id:furoshiki0223:20140114032852p:plain
Chrome向けにアクセスするとChromeが起動し、レガシーIE向けにアクセスするとIEが起動するというもの。言うまでもなく、この機能はWindows限定になります。上記のような動作を実現するために、IEとChrome両方にプラグインのインストールなどの対処が必要になります。

4. サポートライフサイクル

Chromeは、IEのような長いサポートライフサイクルも、FirefoxのESRのような特定のバージョンを一定期間サポートする仕組みも持っていません。非常に短い周期でバージョンアップが必要になります。しかし、これはエンタープライズユースでは現実的とは言えません。バージョンアップ前の動作テストに十分な時間を割きたいところです。

Chromeは自動アップデートが必須というわけでなく、2章のグループポリシーを利用すれば、アップデートのタイミングを制御することができます。詳細は、以下のURLにて解説されています。
https://support.google.com/chrome/a/answer/187207?hl=ja

最後に

「Chromeで企業システムを動かすなんてとんでもない!」なんて思われがちですが、ユーザ企業が標準ブラウザとしてIE8を選択してしまったケースでは、その制約から、選択に含めざる得ないことも少なくないはずです。Windows 7世代のWebシステム開発では、IEだけでは実装が困難な難しいなんてことも出てくるはずです。

ただ、Chromeがパーフェクトでないのもまた事実。ガッツリActive Directoryで染めてしまっている場合は、管理がかなり煩雑になったり、新しいポリシーの適用に多くのコストを必要とすることもあります。一長一短ですね。

意外とGoogleも、こういう面白いソリューションを持っているんだという紹介でした。

ブログのGoogleの検索結果表示を操作する方法

Googleの検索結果を操作する方法について解説します。

どのサイトも断片的にしか説明していないため、本記事では変更作業からGoogle側へ反映するまでの一連の流れを手順書化して解説しています。

★ 手順の流れ

  • 1. 検索結果の表示を変更する
    • コンテンツのタイトル/概要を制御したい場合
    • 著者情報を表示したい場合
  • 2. 検索結果の表示状態を確認する
    • Webサイトが外部へ公開されている場合
    • Webサイトが外部へ公開されていない場合
  • 3. Googleのクローラーへ変更を通知する
    • Googleのウェブマスターツールへサイトを登録していない場合
    • Googleのウェブマスターツールへサイトを登録している場合

1. 検索結果の表示を変更する

★ コンテンツのタイトル/概要を制御したい場合

HTMLドキュメント内のhead要素内で、meta要素を埋め込むことで制御します。ブログの場合は、「設定画面」に含まれていることがあります。ここではHTMLドキュメントへ埋め込む場合を前提とします。

以下は、本サイトの例です。

f:id:furoshiki0223:20131118012329p:plain

<meta property="og:title" content="ふろしき.js - 実用的なWeb技術を発信"/>
<meta property="og:url" content="http://furoshiki.hatenadiary.jp/"/>
<meta property="og:description" content="「実用的な技術」に〜" />
  • ①. og:title → 検索結果の「タイトル」を制御します。
  • ②. og:url → 検索結果の「URL」を制御します。
  • ③. og:description → 検索結果の「概要」を制御します。

概要については、検索結果によって変動します。Webサイトを直接検索しない限り、概要は表示されないとみなせます。

★ 著者情報を表示したい場合

著者情報の表示は、Google Plusとの連携によって行えます。Google Plusにてアカウントを作成し、プロフィール情報を入力して下さい。

プロフィール作成が完了したら、今度は著者情報の表示を行うための設定をGoogle Plus側で行います。Google plus画面の右上の写真をクリックし、「プロフィールを表示」をクリックし、「基本情報」をクリックして下さい。

f:id:furoshiki0223:20131118013437p:plain
f:id:furoshiki0223:20131118013447p:plain

「リンク」欄の、「寄稿先」を登録します。
f:id:furoshiki0223:20131118014112p:plain
f:id:furoshiki0223:20131118013815p:plain
f:id:furoshiki0223:20131118013821p:plain

Webサイト側に、以下のリンクを埋め込んで下さい。a要素のGoogleは消さないで下さい。

<a href="https://plus.google.com/[profile_id]?rel=author" style="display:none;">Google</a>

これで完了です。正しく設定できているかを確認するには、次章の手順に進んで下さい。

2. 検索結果の表示状態を確認する

まず、「構造化データ テスト ツール」へアクセスします。
http://www.google.com/webmasters/tools/richsnippets?hl=ja

★ HTMLが外部へ公開されている場合

「URL」タブのURL欄へ入力し、「プレビュー」をクリックします。
f:id:furoshiki0223:20131118000307p:plain

★ HTMLが外部へ公開されていない場合

「HTML」タブでHTMLドキュメントをコピー&ペーストし、「プレビュー」をクリックします。
f:id:furoshiki0223:20131118000435p:plain

3. Googleのクローラーへ変更を通知する

★ Googleのウェブマスターツールへサイトを登録していない場合

以下のURLへアクセスし、URLを入力、「リクエストを送信」をクリックします。
https://www.google.com/webmasters/tools/submit-url?hl=ja
f:id:furoshiki0223:20131118010155p:plain

★ Googleのウェブマスターツールへサイトを登録している場合

Googleが提供している「ウェブマスター ツール」へアクセスします。ホーム内から、登録している自身のWebサイトを選択します。ここでは例として、本ブログページを選択します。
https://www.google.com/webmasters/tools/home?hl=ja
f:id:furoshiki0223:20131117234815p:plain

次に、「クロール」の「Fetch as Google」を選択します。今回はWebサイト全体の表示方法を変更するため、②のURL欄は空欄にし、③の取得をクリックしましょう。
f:id:furoshiki0223:20131117234824p:plain

「インデックスに送信」をクリックして、表示されたモーダルウィンドウ上の「OK」ボタンをクリックします。
f:id:furoshiki0223:20131117234833p:plain

この設定では、即時では反映されません。クローラーの訪問が早くなるため、Googleの検索結果ページへの反映が早くなります。

このブログの筆者について

川田 寛

コンテンツサービスの開発や運営代行を専門とする集団「株式会社ブートストラップ」の社長です。ネットではふろしきと呼ばれています。

2009年にNTTグループへ新卒入社し、ITエンジニアとしてクラウド技術・Web技術の研究開発と技術コンサルティングに従事。2015年よりピクシブに入社し、エンジニアリングマネージャー・事業責任者・執行役員CCOなど、様々な立場からコンテンツサービスの事業づくりに関わりました。2021年にメディアドゥへVPoEとしてジョインし出版関係の事業に関わったのち、2023年に独立しています。

関わってきたインターネット事業としては、ECサービスのBOOTH、UGCプラットフォームのpixiv(主に海外展開)、制作ツールのpixiv Sketch、VR・VTuber関連ではVRoid、Wikiサービスのピクシブ百科事典など、10を超える多様なCtoCコンテンツサービス。また、NTTドコモのすご得コンテンツ、メディアドゥのWeb3サービスであるFanTopなど、いくつかのBtoCコンテンツサービスにも関わってきました。

幸運なことに、私はコンテンツに関係する幅広いインターネットサービスのテクノロジー&ビジネスの知識を得ることができました。これを日本のコンテンツ発展に役立てたいと思い、株式会社ブートストラップを創業しました。

このブログでは現在、出版社やIPホルダー、ライセンサーといったコンテンツに関わる人々に向けて、インターネット事業に関するTipsや業界内のトレンドなどの情報を発信しています。私と話をしてみたいという方は、以下のフォームより気軽にご連絡ください。

お問い合わせフォーム