AMPページには、オリジナルURL、Google AMP キャッシュURL、Google AMP View URLの三つのURLが存在します。（通常のユーザーはAMP キャッシュURLを目にする機会は（まず）ありません。）

AMPページは、素早くページを表示するためにGoogleのキャッシュに読み込まれています。Googleの検索を行って表示される検索結果から表示されるAMPページは、Googleのドメイン上のキャッシュメモリから予めロードされて表示されます。表示されるURLは、”www.google.com”で始まるGoogle AMP ビューワー URLです。

2017年2月6日、Accelerated Mobile Pages Projectのブログに、検索結果表示のAMPページにソースのAMPドキュメントのURLにアクセスしたりシェアできる機能が追加されたことが発表されました。この記事は、当該機能の発表とAMPの三つのURLについてのそれぞれの役割とGoogleの取り組みなどを説明した内容になっています。

当該記事の”What’s in an AMP URL?“の概要を訳して紹介します。（記事の内容を直訳するのではなく、訳して概要をまとめて紹介します。実際の所、前半は少し割愛していますが、後半は殆ど訳しました。）

What’s in a URL?

ウェッブ上ではたくさんのものがURL上に存在します。URL(Uniform Resource Locator)は、ウェッブ上のアドレスのことです。表示されるページのコンテントが置かれている場所を意味します。URLを見れば、そのページの属性、ブランド、所有者が明確に分かります。

Googleの検索で表示されるAMPページでは、オリジナルコンテントのアドレスではなく、GoogleのAMPビューワーのURLとなっているため、この概念が少し不鮮明なところが生じています。以下は、これまでのGoogle検索で表示されるAMPページの表示画面の例です。

URLの欄には、”www.google.com”で始まるGoogle AMP ビュワー URLが表示され、その下にAMPソースのドメインが表示されます。記事、コンテントは、ソースのあるドメインからではなく、ビューワーURLから予めロードされ表示されています。

AMP ビューワー URL

https://www.google.com/amp が先頭にくるURLは、”AMP Viewer” URLと呼ばれるものです。

ソースドメイン表示の右にアンカーボタンが加えられました。アンカーボタンをクリックすると、正規（ページソース）URLが表示されます。リンクから、ソースページにアクセスすることもできます。AMP ビューワー URLは、Googleのmobile Search Engine Result Page (SERP)に関連する構成機能です。

ユーザーが検索を行って、AMPが実行された結果（AMPページが含まれる検索結果ページ）が表示される時、これらの検索結果の一部はバックグラウンドで予め描写（レンダー）が行われています。ユーザーが予め描写された結果(pre-rendered result)をクリックすると、AMPページが即座（瞬時）にロードされます。

プリレンダリング（予めの描写）は、検索結果ページの中に隠されたiframeにロードされる動作です。プリレンダリングされるのは、AMPページのコンテントと付加されたパラメータで指定されたプリレンダーされるAMPドキュメントです。Java スクリプトのコンポーネントが、”AMP Viewer”と呼ばれるこれらのiframeの動作を操作しています。

ユーザーのブラウザーは（既に描画されている）ドキュメントとAMPランタイムをロードし、AMPページの描画（表示）を開始します。AMPランタイムで管理されている画像や埋め込まれたコンテントなどその他の全てのリソースはため、それら以外はこの時点ではロードされません。AMPランタイムは、あるリソースをフェッチすることがありますが、それはリソースにプライバシーを確保された方法で格納されます。

ユーザーが検索結果をクリックすると、AMPビューワーがすることは、既に描画されているiframeを表示し、AMPランタイムにAMPドキュメントが見える状態になっていることを通知するだけです。

お分かりのように、この動作は極めて単純です。ネットワークアクティビティや新しいページを伴う複雑なナビゲーションは存在しません。そのため、結果が殆ど瞬時にロードされるエクスピリエンスとなります。

google.com/amp のURLはどこから来てどこに行くのか？

上記の全ての動作は、ユーザーがまだオリジナルページ（この例では、サーチ結果ページです）にいる間に起こります。言い換えると、ユーザーは他のページに行っている（移動している）わけではありません。単に同じページ上でiframeを見ているだけです。そのためブラウザの表示するURLは変わりありません。

我々は、ブラウザのURLが画面に表示されるページを反映しているべきであると考えます。ユーザーもリンクを行いやすいです。ユーザーがブラウザのリフレッシュを押した時、検索結果に潜んでいる物ではなく、同じページが表示されることを期待（予想）します。そのため、AMPビューワーは、URLをマニュアルで更新します。これは、ヒストリーAPIを使用した時にも起こります。このAPIは、AMPビューワーが難しいナビゲーションをせずにブラウザURLバーを更新することを可能にします。

ブラウザーは更新の際、どのURLにすべきかという疑問があります。そのURLは、検索結果自体のURL（例： www.example.com/amp//doc.html）、またはAMPキャッシュURL (例： www-example-com.cdn.ampproject.org/www.example.com/amp/doc.html)となるのでしょうか。残念ながらそのどちらでもありません。ヒストリーAPIは、新しいURLはオリジナルURL (reference: 参照ドキュメント：Mozilla Developer Networkのブラウザヒストリの操作)のように同じオリジン上でなければならないと規定（制限）されています。これは（セキュリティ上の理由によって）ブラウザから強制されるものです。Google検索内であれば、URLはオリジンのwww.google.com上にURL上でなければならないことを意味します。

なぜヘッダーバーを表示するのか？

一つ前のセクションで、AMP ビューワーが操作するURLの制限について説明しました。しかしながら、これらのURLは、複雑で混乱を招きかねません。これらは、フィッシング(phishing)攻撃の対象となる可能性があります。もしも、AMPページがGoogleのログインページの様に見えたり、URLバー（アドレス欄）にhttps://www.google.comと表示されていたら、ユーザーはそのページが本当にGoogleのものかどうやって知る（分かる）のでしょうか？そのため、追加の属性が加えられているのです。

適切なコンテンツの属性を提供するため、全てのAMPビューワーは、ユーザーに見ているコンテントがどこから来ている（表示されているコンテントの元（ソース）の場所）を明確に伝えなければなりません。このことを実現する一つの方法は、ヘッダーバーを追加し、ページの”本当(true)”のオリジンを表示することです。

What’s next? 次に来るものは？

これまでの説明で、異なるURLが存在する理由と全てのAMPビューワーにヘッダーが必要であることの理由が明確になりましたでしょうか。このアプローチとURLの重要性についてのユーザーからのインプットを受け取っています。それで、次に何が来るのか？AMPページへのユーザーの期待するスピードとパフォーマンスを裏切ることなく、我々が出来ることを考案すべきです。

2016年2月のGoogle 検索でのAMPのローンチ以降、我々は以下の様なステップを執り行いました。

• 全ての Google URL（すなわちGoogle AMP キャッシュ URLとGoogle AMP viewer URL）は、コンテントのオリジナルソースを可能な限り最善な方法で反映する。www.google.com/amp/www.example.com/amp/doc.html
• ユーザーがドキュメント（文書）を読むためページをスクロールダウンすると、前画面での貴重なリアル・エステート（表示スペース）を使えるようにAMP ビューワーヘッダーバーは隠される。
• ユーザーがGoogle AMP ビューワー URLを訪問した時、ビューワーが使用できない場合は、ドキュメントの正規（ソース）ページにリダイレクトする。

上記に加えて、多くのユーザーはドキュメントの正規（canonical) URLにアクセス、コピー、シェアする方法を要求していました。本日（2016年2月6日）、我々はこの機能をサポートするため、Google検索のAMP ビューワーヘッダーバーにアンカーボタンを追加しました。この機能は、ブラウザのネーティブシェア機能を利用してリンクをタップことで表示することができます。

これから数週間の間に、Android Google アプリのシェアボタンをタップするとドキュメントのオリジナルURLをシェアできる機能が使えるようになります。この機能は、iOS Google アプリでは既に使用可能です。

最後に、これから登場するウェッブプラットフォームAPIを活用しこの機能を更に向上させることに取り組んでいます。そのAPIの一つは、Web Share APIです。このAPIは、AMPビュワーが、AMPビューワーURLでなくオリジナルURLをネイティブでシェアする機能を起動することを可能にするものです。

我々、Googleは、ユーザーとパブリッシャー双方に出来る限り良好なAMPエクスピリエンスを提供するよう最善を尽くしています。エコシステムの繁栄は、我々にとって非常に重要であり、属する事柄、ユーザの信頼、オーナーシップは、このエコシステムの重要な事柄です。

このブログ投稿が、AMPドキュメントの三つのURLのオリジンの理解、それらのAMPを早くさせる役割とGoogle検索によるAMP体験のさらなる向上に向けた我々の取り組みをご理解頂く手助けとなることを望んでいます。最後に、エコシステムはあなた方の参加によってのみ花開くことができます。フィードバックとAMPへのご参加をお待ちしております。