AMPのこれまでとこれから

こんにちは。GORAN です。今日は僕がエンジニアを志すキッカケにもなった技術AMPについての記事です。（全て個人の意見です）

半年くらい前にCore Web Vitalsについてという記事で「AMPオワコンというわけでもないぞ」という主旨のことをつぶやいておりましたが、その理由も今回語ろうと思っています。

はじめに

AMPが発表されたのは2015年、リリースされたのは2016年でして、プロジェクト自体はかれこれ6年モノになります。僕としてはuskay氏の勉強会がAMPとの出会いでして、2017年の5月くらいだった記憶です。 当時は「ページ読み込みに3秒かかったら53%が離脱する」みたいなキャッチフレーズで、表示速度への問題提起とセットにして売り出されてましたね。

リリースの背景

Googleがウェブにおける体験に対するページ表示速度の占める割合の大きさに気づいた（問題意識を持ち始めた）ことがキッカケだろうと思っています。かなり初期の段階で「AMPをキッカケにウェブの体験を変えていきたい」という意思表示はあったので、CWVやSXGなど、昨今リリースされたAMPでの（ある種の）成功体験に基づく基準や技術というのは構想に入っていたでしょうし、そこまで見据えてのリリースだった可能性もありますね。

普及までの流れ

それまで読み込み速度の改善というのは以下の2つの壁に阻まれており、意識の高いデベロッパーがいたとしても、社内を啓蒙し世界の意識へスケールさせていくようなことは不可能でした。

1. 非機能要件の壁
2. プライオリティの壁

AMPが流行った理由はこの2つの障壁を排除したことにあり、トーンダウンしてきたのもその排除の仕方に起因します。

非機能要件の壁を越える

AMPが採択した解決方法は、これまで非機能要件であった読み込み速度を仕様として機能要件に落とし込むというものでした。具体的には、Validationを設けて「validかinvalidか」という検証可能な状態を作りました。（これによって「非AMP」というワードが生まれました）

デベロッパーにとっては「AMP validなページを作る」というのが要件に入ってくるわけですから、対応方針の見通しが良くなります。

プライオリティの壁を越える

非機能要件が持つ永遠の課題ですが、個人がそれに対して問題意識を持っていても組織の意思決定として「予算が〜」「工数が〜」という理由で結果「やりたくてもやれない」状況に陥るのは定番のパターンです。AMPはそれをSEOでの優遇措置という手法で解決しました。

具体的には、AMP validなページには（モバイル検索結果において）以下のインセンティブがありました。

• AMPバッジがつく
• トップカルーセルにキュレーションされる
• GoogleドメインのCDN（AMP Cache）から配信される

いずれもSEO界隈（特に大手パブリッシャー）にとってはあまりにも強力なものであり、（ほぼ強制的に）AMPに対応せざるを得ない状況になりました。

トーンダウン

こうした対応により爆発的に普及したAMPですが、GORANの感覚としては、この1年くらいでだいぶトーンダウンしてきたかなと感じています。

その原因というのは上述の通り、2つの障壁の排除の仕方にあったわけですが、2018年に公開されたAMP letterという文書の中で、既に問題視されていたことでした。そこではウェブというエコシステムに対してAMPが有する以下の問題が指摘されています。

• SEO視点での優遇措置
• ユーザーが気付かぬうちにGoogleのドメイン内に留まってしまう

SEO視点での優遇措置

この対応によってAMPは一時代を築きあげたわけですが、言い換えればAMP対応していないページにディスアドバンテージを作っていることと大差ないので、フェアではありません。

ユーザーが気付かぬうちにGoogleのドメイン内に留まってしまう

もうひとつURLの問題がありました。これはAMP Cacheの仕様によるものですが、AMP validなページはGoogleのCDNにキャッシュされ、モバイルの検索結果画面からの遷移ではそのキャッシュが読まれます。つまりはGoogleのドメインから配信されることになり、元のURLが表示されないという大きな問題がありました。URLを細かくチェックするユーザーというのは非常に少ないと思われますが、それらが気付かぬうちに（意図せぬまま）Googleのドメイン内に留まるというのは健全ではありません。

以上の懸念されていた問題点は予想通り膨れ上がり、結果としていずれもGoogleが提供を停止することが発表されています。その発表をもって大手のパブリッシャーたちも軒並みAMP対応から手を引き、現状の「そういえばAMP聞かんなぁ」という状況になっているわけです。

AMPじゃない方が速い

AMP letterでは指摘されていませんが、もうひとつの大きな問題です。AMPは簡単にいうと遅くしようがない技術という思想ですので、決して最速の技術ではありません。きちんとした最適化を図れば自前で作る方が絶対に速くなります。 そういった観点で、リリース当初から、既にAMPを導入するよりもパフォーマンスの良いコンテンツを配信していたデベロッパー・ウェブマスターの反感を買っていました。 もちろんGoogleの狙いとしてはAMPが普及することによるウェブコンテンツ全体の表示速度の底上げだったはずなので、それに対しては一定の結果が得られたのだろうと思います。

AMPのこれから

GORANとしては、トーンダウンしてきたことは事実として認めつつ、総合的には「AMPによって間違いなく表示速度に対する世界の意識が変わった」というポジティブな印象を持っています。トーンダウンしてきたことに対しても、AMPが持っていた「表示速度に対する意識の啓蒙」という役割を終えたに過ぎず、Web ComponentsやフレームワークとしてのAMPの成長に対してはまだ伸び代を感じています。

Bento

これが今回この記事を書くキッカケにもなったファクトで、先日ようやく正式リリースされました。構想自体は2018年のAMP Confで発表されていました記憶です。僕もpaul氏が#eccube_dayで来日されていた際のセミナー聞いてました。（2019年だったかな）

AMPはリリース当初からWb Componentsベースの設計を進めていて、<amp-img>に始まり、今では<amp-tiktok>など相当数のコンポーネントが用意されています。

AMPがもたらした素晴らしい体験はかなり早いうちから「非AMPでも同様の体験を」という意思表示がされていて、そのうちのひとつとしてAMP CacheはSXGとして羽ばたいていったわけですが、「非AMPでもAMP componentを使って良いんだよ」という啓蒙も頻繁にされていました。当時はBento AMPと呼称されていて、この度晴れてBentoとして日の目を浴びることとなったわけです。これによってAMPは「validなページを作るための枠組み・制約」から「部品単位で簡単に使えて、かつパフォーマンスも良いコンポーネントライブラリ」として進化を遂げたと思っています。今回は経緯を解説する記事なので、Bentoの詳しい仕様は別記事にします。

Stories

もうひつの伸びしろです。イマイチ流行っていないのが不思議なのですが、AMPにはWeb Storiesという使い方があります。（AMP Storiesとも呼ばれます）

簡単にいうと、Instagramのストーリーズと同じことをウェブでも再現できるフレームワークです。この見せ方はクリエイティブと非常に相性が良いので、スポーツ×Webの業界に身を置くものとしては、今後チケットLPの代替になっていったりするのではなかろうかと期待もしています。 実を言うとGoogleはすでにStoriesに対する優遇措置を設けていて、Google Discover・Google検索・Google画像検索においてリッチリザルトを提供しています。

また、最近もアクションボタンやインタラクションのアップデートがあるなど、開発コミュニティとしても落ち込んでいないので、息の長いものになるのではないかと予想しています。こちらも別記事にて詳細は解説したいなと思います。

おわりに

以上がAMPに対するGORANなりの見解です。抜け落ちている箇所もあるかと思いますが、それでもそこそこ長くなってしまいました。笑

この記事を読んで、「まだAMP可能性あるかも」と感じていただけたなら幸いです。GORANはこれからもAMPを追い続けますし、応援し続けます。Make the web faster！！

---