Google Developers Japan: AMP URL の正体

Japan

このブログでは、Google から開発者のみなさま向けの情報をいち早くお届けします。

この記事は Alex Fischer、Google 検索ソフトウェアエンジニアによる Google Developers Blog の記事 "What’s in an AMP URL?" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
（この投稿は長文です。）本日（*原文公開当時）、Google 検索に 1 つの AMP 統合機能が追加され、ユーザーが AMP ドキュメントの canonical URL にアクセスし、それをコピーしたり共有したりできるようになりました。このニュースを詳しく取り上げる前に、少し後戻りして AMP の世界の URL とそれが AMP のメリットであるスピードとどう関連しているのかについて説明しましょう。

URL とは何でしょうか。ウェブでは、それはさまざまなものを意味します。URL とオリジンは、ある程度、コンテンツの信頼性と所有権を示すものです。ニューヨークタイムズの記事を読むとき、一瞬でも URL に目を向ければ、読んでいるものが本当にニューヨークタイムズの記事なのかどうか、その信頼度がわかります。帰属先、ブランド、所有権がわかるからです。

しかし、最近リリースされたさまざまなモバイルアプリや Google 検索の AMP 対応によって、この点が少しわかりにくくなっています。この投稿では、まず私たちの技術的な決定の理由を説明し、さまざまな AMP URL について詳しく説明します。次に、 URL にまつわる懸念事項に対処するために行った変更点について、概略を説明します。

まず、AMP ドキュメントには、次の 3 種類の URL があります。

オリジナル URL: AMP フォーマットで記述されたサイトオーナーのドキュメントです。http://www.example.com/amp/doc.html
AMP Cache URL: AMP Cache から提供されるドキュメントです（例: Google が提供するすべての AMP は、Google AMP Cache 経由で提供されます）。ほとんどのユーザーは、この URL を目にすることはありません。https://www-example-com.cdn.ampproject.org/c/www.example.com/amp/doc.html
Google AMP ビューアー URL: AMP ビューアーに表示されるドキュメントです（例: 検索結果ページに表示されるとき）。https://www.google.com/amp/www.example.com/amp.doc.html

本質的に同一のコンテンツについて、オリジンが異なる 3 種類の URL が存在します。そのため、混乱を生む可能性もありますが、これには主に 2 つの理由があります。それは、キャッシュとプリレンダリングです。これらは AMP のスピードに大きく貢献しますが、どちらにも新しい URL が必要になります。その点について、詳しく説明しましょう。

AMP Cache URL
まず、AMP Cache URL について説明します。AMP Cache が存在する理由は、Google の AMP デベロッパーアドボケートである Paul Bakaus の投稿で丁寧に説明されています。この投稿では、AMP Cache のメリットが詳しく説明されていますが、なぜ新しい URL が必要になるのかという点は、特に説明されていません。この質問への回答は、AMP の設計原則の 1 つである「導入の簡単さ」によるものです。AMP は、いくつかのモバイルウェブの問題を大規模に解決しようとするものです。そのため、AMP のコンポーネントは誰でも簡単に使えるものでなければなりません。

AMP Cache が提供する検証、ユーザーからの近さなどのさまざまなメリットは、他の方法でも得ることができます。しかし、自身の DNS エントリを管理していない小さなサイトでは、複雑な API 経由でコンテンツをプッシュするエンジニアリングリソースがなかったり、コンテンツ配信ネットワークの費用がまかなえなかったりするため、そのようなテクノロジーを利用できません。

そのため、Google AMP Cache は簡単な URL 「変換」によって動作します。ウェブマスターは、ある URL でコンテンツを利用可能にするだけです。Google AP Cache はそのコンテンツをキャッシュし、オリジナルを反映した変換済みのドキュメントを、全世界に広がる Google のインフラ上の新しい URL で提供します。これはとてもシンプルな方法です。一方で、オリジナルの URL を使って AMP Cache を活用しようとする場合、ウェブマスターが DNS レコードを変更したり、ネームサーバーを再設定したりしなければなりません。実際にそれを行っているサイトもありますが、大多数のサイトでは、URL ベースの方が使いやすいアプローチでしょう。
AMP ビューアー URL
先ほどのセクションでは、Google AMP Cache URL について説明しました。これは、キャッシュされた AMP ドキュメントを指す URL でした。しかし、www.google.com/amp という URL はどうでしょう。なぜこれが必要になるのでしょうか。これは、プリレンダリングに必要な「AMP ビューアー」の URL です。

AMP がプライバシーとリソースに配慮したプリレンダリングをビルトインでサポートしていることは、滅多に話題に上がることはなく、誤解されることもよくあります。AMP ドキュメントはプリレンダリングが可能です。その際に、リソースを連続で取得したり、ユーザーの CPU やメモリを大量に消費したり、プライバシーに注意が必要なアナリティクスコードを実行する必要はありません。この点は、呼び出し側のアプリがモバイルウェブページでも、ネイティブアプリでも変わりません。ただし、新しい URL が必要になります。主にこれは、モバイルウェブの実装が関係しています。ここでは、例として、Google のモバイル検索結果ページ（SERP）を使って説明します。
プリレンダリングの仕組み

ユーザーが AMP に対応した結果を返す Google 検索を行う場合、その結果の一部は裏でプリレンダリングされています。ユーザーがプリレンダリングされた結果をクリックすると、AMP ページが即座に読み込まれます。

呼び出し元のページ（検索結果ページ）の隠し iframe に、AMP ページのコンテンツと、AMP ドキュメントがプリレンダリング中であることを示す追加パラメータを読み込むことで、プリレンダリングは機能します。この iframe のライフサイクルを管理する JavaScript コンポーネントは、「AMP ビューアー」と呼ばれます。

AMP ビューアーが隠し iframe 内で AMP ドキュメントをプリレンダリング

ユーザーのブラウザは、ドキュメントと AMP ランタイムを読み込み、AMP ページのレンダリングを開始します。イメージや埋め込み要素など、その他のリソースはすべて AMP ランタイムが管理するため、この時点で読み込む必要があるものはこれだけです。AMP ランタイムはリソースを取得することもありますが、それはリソースとプライバシーに配慮した形で行われます。

ユーザーが結果をクリックした際に AMP ビューアーがしなければならないのは、レンダリング済みの iframe を表示させ、AMP ドキュメントが表示されたことを AMP ランタイムに知らせるだけです。

おわかりのように、この操作はとても軽いものです。ネットワークを経由せず、新しいページへの実際のナビゲーションも発生しません。そのため、結果がほぼ即座に読み込まれます。 google.com/amp という URL の正体
以上の動作はすべて、ユーザーがオリジナルのページ（この例では、検索結果ページ）にいる間に行われます。つまり、ユーザーは別のページには移動していません。同じページにある iframe を表示しているだけなので、ブラウザの URL は変わりません。

しかし、ブラウザの URL には、画面に表示されているページの URL を反映させて、ユーザーが簡単にリンクできるようにしたいものです。また、ユーザーがブラウザの更新ボタンを押した際には、裏にある検索結果ページではなく、同じドキュメントが表示されることが期待されます。そのため、AMP ビューアーは手動でこの URL をアップデートしています。これは、History API を使って実現されています。AMP ビューアーは、この API を使って実際のナビゲーションを行わずにブラウザの URL バーをアップデートしています。

ここで問題になるのが、ブラウザがどの URL にアップデートするのかという点です。結果自身の URL（例: www.example.com/amp/doc.html）か、AMP Cache URL（例: www-example-com.cdn.ampproject.org/www.example.com/amp/doc.html）を表示するのが理想的でしょう。しかし、残念ながら、どちらもうまくいきません。History API の大きな制約の 1 つに、新しい URL はオリジナルの URL（リファレンス）と同じオリジンでなければならない、というものがあります。この制約は（セキュリティ上の理由によって）ブラウザによって強制されます。Google 検索においては、この URL が www.google.com オリジンである必要があります。

ヘッダーバーを表示する理由
先ほどのセクションでは、AMP ビューアーが従わなければならない URL の制限について説明しました。しかし、この URL は混乱や誤解を生むことも考えられ、フィッシング攻撃の入り口となる可能性もあります。AMP ページに Google のようなログインページが現れ、URL バーに www.google.com と表示されていれば、ユーザーはそのページが実際に Google のものだと思ってしまうでしょう。そのため、追加で帰属先を表示する必要があります。
コンテンツの帰属先を適切な形で提供できるように、AMP ビューアーでは、表示されているコンテンツの提供元を必ずユーザーに明示しなければなりません。それを実現する手段の 1 つとして、ヘッダーバーを追加して「実際の」ページのオリジンを表示する方法があります。

次のステップ
ここまでのセクションで、いくつかの異なる URL が存在する理由と、AMP ビューアーに必ずヘッダーが存在する理由を明確に理解していただけたと思います。このアプローチと URL の重要性に関しては、皆さんの意見に耳を傾けてきました。では、次のステップは何でしょうか。ご存じのとおり、私たちは慎重に事を進め、ユーザーが AMP ページに期待するスピードやパフォーマンスを維持できるようにしたいと考えています。 2016 年 2 月に Google 検索の AMP 対応を行って以来、私たちは次の手順を踏んできました。

すべての Google の URL（例: Google AMP Cache URL や Google AMP ビューアー URL）で、www.google.com/amp/www.example.com/amp/doc.html のように可能な限りオリジナルのコンテンツの URL を反映させる。
ユーザーがドキュメントを読むためにページをスクロールする際には、AMP ビューアーのヘッダーバーを非表示にして、貴重な画面上の領域を解放する。
ビューアーが利用できないプラットフォームでユーザーが Google AMP ビューアー URL にアクセスした際には、ドキュメントの canonical ページにリダイレクトする。

これらに加え、多くのユーザーがドキュメントの canonical URL にアクセスし、それをコピーしたり共有したりする機能をリクエストしていました。本日より、Google 検索の AMP ビューアーのヘッダーにあるアンカーボタンという形でこの機能がサポートされています。これによって、ユーザーは表示されるリンクを長押しして、ブラウザのネイティブ共有機能を使えるようになります。

今後数週間の間に、Android Google アプリでも、共有ボタンをタップした際にドキュメントのオリジナル URL を共有できるようになります。iOS Google アプリでは、すでにこの機能が利用できるようになっています。

また、私たちは、まもなく登場するウェブプラットフォーム API を活用してこの機能をさらに改善しようとしています。そのような API の 1 つに、Web Share API があります。これを活用すると、AMP ビューアーから AMP ビューアーの URL ではなく、オリジナルの URL を使ってプラットフォームネイティブの共有フローを呼び出すことができます。

私たち Google は、ユーザーとサイトオーナーの両方にとってできる限り最高の AMP 体験を提供したいと常に考えています。エコシステムの繁栄は私たちにとって非常に重要なことで、そのエコシステムにとって重要になるのが、コンテンツの帰属先、ユーザーの信頼、所有権です。このブログ投稿によって、AMP ドキュメントの 3 つの URL の由来と、それらが AMP の高速化に果たしている役割、そして Google 検索の AMP をさらに改善しようという私たちの努力について、理解を深めていただければ幸いです。最後になりますが、エコシステムとは皆さんの参加があってこそ繁栄するものです。ぜひフィードバックをお寄せください。そして、AMP に参加してください。

Posted by Yoshifumi Yamaguchi - Developer Relations Team