モバイルサイトの表示速度を改善しようと調べていると、必ずと言っていいほど「AMP」という言葉に行き当たります。ただ、検索して出てくる解説記事の多くは数年前に書かれたもので、「AMPに対応すれば検索で有利になる」と書かれているものも少なくありません。一方で「AMPはもう終わった」という記事も見つかり、結局いま自社サイトに導入すべきなのか判断がつかない——そんな状態の方も多いはずです。本記事では、AMPの基本的な仕組みから、2021年と2026年に起きたGoogleの方針転換までを時系列で整理し、2026年時点でAMP対応が必要かどうかを判断するための材料をまとめます。
AMP（Accelerated Mobile Pages）とは
AMPの読み方・意味
AMPは「Accelerated Mobile Pages」の略で、日本語では「アンプ」と読みます。直訳すると「高速化されたモバイルページ」で、その名のとおりスマートフォンでのWebページ表示を速くするために設計された、オープンソースのフレームワークです。
通常のWebページは、HTML・CSS・JavaScript・画像・広告タグ・アクセス解析タグなど多くの要素を読み込みます。モバイル回線ではこれらの読み込みに時間がかかり、ユーザーが待ちきれずに離脱してしまう。この課題に対してAMPが取った解決策は、「使える技術をあえて制限することで、遅くなりようがないページを作る」というものでした。
一般的な高速化手法が「重いものを軽くする」アプローチなのに対し、AMPは「重くなる要素を最初から使わせない」という、かなり思い切った設計思想を持っている点が特徴です。
AMPが生まれた背景
AMPは2015年10月にGoogleが主導するプロジェクトとして発表され、当時のTwitter（現X）も協力企業として名を連ねていました。翌2016年2月にはGoogle検索の「トップニュース」枠でAMPページの表示が始まり、同年9月には通常のモバイル検索結果にも拡大しています。
背景には、当時のモバイルWebを取り巻く2つの事情がありました。
ひとつは、モバイル回線の遅さと重いWebページのミスマッチです。ニュースサイトを中心に広告タグやトラッキングタグが肥大化し、読み込みに数秒〜十数秒かかるページが珍しくありませんでした。
もうひとつは、FacebookやAppleが自社プラットフォーム内でニュース記事を高速表示する仕組み（Instant ArticlesやApple News）を打ち出していたことです。オープンなWebから読者がプラットフォーム内へ流れることへの危機感が、Google側にAMPを推進させた要因のひとつだったと指摘されています。
つまりAMPは、単なる技術仕様であると同時に、当時のWebとプラットフォームの主導権争いの中から生まれたという側面を持っていました。
AMPの仕組み
AMPを構成する3つの技術要素
AMPは伝統的に、次の3つの要素で構成されると説明されてきました。
| 構成要素 | 役割 | 特徴 |
|---|---|---|
| AMP HTML | ページの記述言語 | 通常のHTMLに独自の制限と独自タグを加えたもの。<img>の代わりに<amp-img>を使うなど |
| AMP JS | 描画を制御するライブラリ | 画像・動画・広告の読み込み順序や遅延読み込みを一括管理。開発者独自のJavaScriptは原則禁止 |
| AMP Cache | 配信用のCDN | Googleなどが提供するキャッシュ基盤。AMPページを事前に取得・最適化して配信していた |
AMP HTMLは、表示速度を落とす要因になりうるタグや記述を禁止し、代わりに最適化済みの独自コンポーネントを提供します。たとえば画像は<amp-img>で記述し、幅と高さを必ず指定させることで、読み込み中のレイアウトのガタつき（レイアウトシフト）を構造的に防いでいます。
AMP JSは、ページ内のすべてのリソース読み込みを管理する司令塔です。外部リソースの読み込みを非同期化し、ファーストビューに関係のない画像は後回しにする、といった制御を自動で行います。開発者が自由にJavaScriptを書けない代わりに、パフォーマンスの下限が保証される設計です。
AMP Cacheは、AMPページのコピーをCDN上に保持し、そこから配信する仕組みでした。ユーザーが検索結果のAMPリンクをタップすると、元のサイトのサーバーではなくGoogleのキャッシュから瞬時にページが返る——これがAMPの「速さ」を体感的に支えていた最大の要素です。ただし、この配信経路については後述するとおり2026年に大きな変更がありました。
通常のHTMLページとの違い
AMPページと通常のWebページの違いを整理すると、次のようになります。
| 比較項目 | AMPページ | 通常のWebページ |
|---|---|---|
| HTML | 使えるタグに制限あり（AMP HTML） | 制限なし |
| JavaScript | 独自JSは原則使用不可 | 自由に使用可能 |
| CSS | インライン記述で上限75KBなどの制約 | 制限なし |
| 画像 | <amp-img>でサイズ指定必須 |
<img>で自由に記述 |
| フォーム・動的機能 | AMP用コンポーネントの範囲内 | 自由に実装可能 |
| 検証 | AMP仕様への準拠チェックが必要 | 特になし |
CSSの75KB上限は、実際に導入したサイトが最初につまずくポイントとしてよく挙げられます。既存サイトのデザインをそのまま持ち込もうとすると容量を超えてしまい、AMP用に別のスタイルを組み直す必要が出てくるためです。
AMPを導入するメリット
表示速度の向上
AMPの最大かつ本質的なメリットは、やはり表示速度です。制限の厳しい仕様に沿って作られている以上、極端に重いページにはなりようがありません。技術力やリソースにばらつきのある大規模メディアで、記事ページの速度を一定水準に揃える手段としては、当時かなり有効な選択肢でした。
さらにAMP Cacheからの配信が有効だった時期は、ユーザーがリンクをタップした瞬間にほぼ待ち時間なくページが開く、という体験を実現していました。
離脱率の改善・ユーザー体験の向上
表示速度と離脱率の相関は、Googleをはじめ多くの調査で繰り返し指摘されています。読み込みが数秒遅れるだけで離脱率が跳ね上がる、というデータは業界内で広く共有されてきました。
AMPページはレイアウトシフトが起きにくい設計になっているため、「読もうとした瞬間に広告が挿入されて誤タップする」といったストレスも起きにくくなります。速さそのものよりも、こうした体験の安定性のほうがAMPの実質的な価値だったという見方もできます。
過去には検索結果での優遇があった
かつてAMPには、SEO上の明確な「特典」がありました。
- モバイル検索のトップニュース（Top Stories）カルーセルに載るための実質的な必須条件だった
- 検索結果上でAMPページには雷マーク（稲妻アイコン）が表示され、他の結果との視覚的な差別化になっていた
特にニュースメディアにとって、トップニュース枠は流入の生命線でした。多くのパブリッシャーがAMP対応に踏み切った最大の理由がここにあったと言われています。ただし、これらの優遇はいずれも現在は存在しません。この点は次章で詳しく整理します。
AMPを導入するデメリット・注意点
デザイン・機能の制約
AMPの速さは制限とのトレードオフです。独自JavaScriptが使えないため、凝ったインタラクションや動的なUIは実装できません。フォームやカルーセルなども、AMPが用意したコンポーネントの範囲内で組む必要があります。
BtoBサイトの場合、資料請求フォーム、チャットボット、MAツールのトラッキングタグ、ABテストツールといった要素が制約に引っかかりやすく、リード獲得に必要な仕掛けをAMPページ上で再現できないケースが起こりえます。
実装・運用の手間が増える
AMPを導入すると、多くの場合「通常ページ」と「AMPページ」の2種類を管理することになります。
| 発生する運用コスト | 具体例 |
|---|---|
| 二重管理 | 通常ページとAMPページで表示崩れが起きていないか両方確認する |
| タグ管理 | 解析タグ・広告タグをAMP用に別途設定する |
| 検証対応 | AMP仕様のエラーが出ていないか継続的にチェックする |
| 計測の分断 | AMPページと通常ページでデータが分かれ、分析が煩雑になる |
サイト改修やデザイン変更のたびにAMP側も追随させる必要があり、この継続的な運用負荷が「AMPをやめる」判断の主因になったというのは、離脱したメディアの説明としてよく語られる内容です。
現在のSEOへの影響（2021年と2026年の方針転換）
ここが本記事で最も重要なポイントです。AMPとSEOの関係は、この数年で二段階に分けて大きく変わりました。
第1段階：2021年のページエクスペリエンスアップデート
2021年、Googleはトップニュースカルーセルの掲載要件からAMPを外しました。以降は、AMPを使っていなくてもページエクスペリエンス（Core Web Vitalsを含む）の基準を満たしていればトップニュースに表示される対象となっています。同じ時期に、検索結果に表示されていたAMPの雷マークも廃止されました。
つまり、多くのメディアがAMPを導入した最大の動機だった「トップニュース枠のための必須条件」は、この時点で消滅しています。
第2段階：2026年7月のAMPキャッシュ配信の終了
そして2026年7月1日、GoogleはAMPページをAMPキャッシュから配信する経路そのものを終了しました。従来は検索結果のAMPリンクをタップするとGoogleのキャッシュから配信され、AMPビューア上でgoogle.comのURLとして表示されていましたが、現在はユーザーのブラウザがサイト自身のAMPページへ直接遷移し、そのサイトのURLがそのまま表示されます。あわせて、URL表示の問題を回避するために使われていた署名交換（Signed Exchanges／SXG）のサポートも終了し、Googleの公式ドキュメントからAMPビューア・AMPキャッシュ・署名交換に関する記述が削除されています。
この変更について、GoogleはAMPコンテンツは他のWebページと同じようにランキングされると説明しており、順位への影響ではなく「配信方法の変更」であるという位置づけを示しています。
Google公式ドキュメントでも現在は、AMPページは他のWebページと同じようにインデックスされ、ページの構築技術にかかわらず同じ基準が適用されると明記されています。
整理すると、AMPをめぐる状況は次のように推移しました。
| 時期 | 出来事 | SEO上の意味 |
|---|---|---|
| 2015年10月 | AMPプロジェクト発表 | ― |
| 2016年2月 | Google検索のトップニュースでAMP表示開始 | AMP対応が露出増につながる時期 |
| 2021年 | トップニュースのAMP要件撤廃／雷マーク廃止 | AMP導入の最大の動機が消滅 |
| 2026年7月 | AMPキャッシュ・AMPビューアからの配信終了 | 配信面での固有の優位性が消滅 |
| 現在 | AMPは仕様として存続、ランキングは他ページと同等 | AMP対応そのものによる検索上の優遇はない |
「AMPを導入すればSEOで有利になる」という説明は、2021年以前の状況を前提にした古い情報です。現在この前提で記事を書いている解説ページも残っているため、情報の公開日・更新日を確認しながら読むことをおすすめします。
AMP対応は必要か？現在の判断基準
Core Web Vitals・ページエクスペリエンスとの関係
現在、Googleがページの体験を評価する指標として公式に位置づけているのはCore Web Vitalsです。2026年時点で参照される主な指標と目安は次のとおりです。
| 指標 | 測るもの | 「良好」の目安 |
|---|---|---|
| LCP（Largest Contentful Paint） | メインコンテンツが表示されるまでの時間 | 2.5秒以内 |
| INP（Interaction to Next Paint） | クリックやタップへの応答速度 | 200ミリ秒以内 |
| CLS（Cumulative Layout Shift） | レイアウトのずれにくさ | 0.1以下 |
なおINPは、2024年3月にFID（First Input Delay）に代わって導入された比較的新しい指標です。
重要なのは、これらの指標はAMPかどうかを問わないという点です。通常のHTMLページでも基準を満たせば同じように評価されますし、逆にAMPページであっても、外部リソースの使い方次第では指標が悪化する可能性はあります。AMPは「良いスコアを出しやすい手段のひとつ」ではあっても、それ自体が評価対象ではないという整理になります。
AMP対応を今から検討する価値があるケース・ないケース
現時点での判断の目安を整理すると、次のようになります。
| 状況 | 判断の目安 |
|---|---|
| これから新規にサイトを作る | AMPを前提にする必然性は乏しい。通常ページでCore Web Vitalsを満たす設計を優先 |
| 既にAMPを運用していて問題が出ていない | 直ちに撤去する必要はないが、運用コストに見合うか定期的に見直す |
| AMPの制約がCV導線を阻害している | 撤去し、通常ページの高速化に投資する判断が合理的 |
| BtoBのリード獲得サイト | フォーム・MAツール・チャットとの相性を考えると制約が重くなりやすい |
海外の大手メディアの中には、AMPを撤去しても検索流入が落ちなかったと報告している例が複数報じられています。ただし、これらは各社の環境に依存した結果であり、すべてのサイトに同じことが起きるとは限りません。撤去を検討する場合は、AMP URLから通常ページへのリダイレクト設計を含めて慎重に進める必要があります。
AMPを使わずにサイトを高速化する方法
AMPに依存せず表示速度を改善する手段は、現在では十分に揃っています。
- 画像の最適化：WebPやAVIFといった次世代フォーマットへの変換、適切なサイズでの配信
- 遅延読み込み（lazy loading）：ファーストビュー外の画像・動画の読み込みを後回しにする
- 重要リソースの優先読み込み：主要画像に
fetchpriority="high"を指定し、LCPを改善する - JavaScriptの削減と分割：不要なライブラリを外し、長い処理を小さく分割してINPを改善する
- 画像・動画のサイズ属性指定：領域を先に確保してCLSを抑える
- CDNの導入：配信距離を短縮し、応答時間を改善する
- キャッシュの活用：サーバーキャッシュ・ブラウザキャッシュを適切に設定する
これらはAMPと違ってデザインや機能の自由度を犠牲にしません。「速さのために表現を諦める」必要がなくなったことが、AMPの役割が縮小した最大の理由と言えます。
AMPの実装方法
基本的な実装の流れ
AMPページを自前で実装する場合、大まかな流れは次のようになります。
- HTMLをAMP HTMLの仕様に沿って記述する（
<html amp>の宣言、AMP JSの読み込み、<amp-img>への置き換えなど） - CSSをインラインで記述し、容量の上限内に収める
- 通常ページに
rel="amphtml"でAMPページを指定し、AMPページ側からはrel="canonical"で通常ページを指定する - AMP用に解析タグ（
amp-analytics）などを設定する - 検証ツールでエラーがないか確認する
この相互リンクの設定は、通常ページとAMPページが重複コンテンツとして扱われないようにするために欠かせない手順です。
WordPressでの対応方法
WordPressの場合は、プラグインによる導入が一般的です。
| プラグイン | 概要 |
|---|---|
| 公式AMPプラグイン（AMP） | AMPプロジェクト側が公開している標準的な選択肢。セットアップウィザードを備え、既存テーマを活かす設定も可能 |
| AMP for WP | 設定項目やデザインのカスタマイズ性が比較的高いサードパーティ製プラグイン |
公式プラグインでは、サイト全体をAMPで構成する方式、通常テーマをAMP化する方式、AMP専用の簡易テンプレートを使う方式といった複数のモードが用意されており、サイトの状況に応じて選べる設計になっています。
ただし、プラグインを有効化すれば終わりではない点には注意が必要です。既存のテーマや他のプラグインがAMP非対応のJavaScriptを出力していると検証エラーになり、機能が無効化されたり表示が崩れたりします。導入後は必ず主要なページを実機で確認してください。
実装後の確認方法
AMPが正しく実装されているかは、次の方法で確認できます。
| 確認手段 | 用途 |
|---|---|
| AMPテストツール（Googleが提供） | 個別のURLがAMP仕様に準拠しているかを確認する |
| Google Search ConsoleのAMPレポート | サイト全体のAMPページのエラーを一覧で把握する |
| ブラウザの開発者ツール | URLの末尾に#development=1を付けてコンソールで検証エラーを確認する |
| PageSpeed Insights | AMPかどうかにかかわらず、実際の表示パフォーマンスとCore Web Vitalsを測定する |
なおSearch ConsoleのAMPレポートは、2026年時点でも拡張レポートのひとつとして提供が続いています。ただし、AMPをめぐるGoogleの機能提供は段階的に縮小してきた経緯があるため、今後の変更可能性も念頭に置いておくのが現実的でしょう。
まとめ
AMP（Accelerated Mobile Pages）は、2015年にGoogleが主導して立ち上げた、モバイルページ高速化のためのフレームワークです。AMP HTML・AMP JS・AMP Cacheという3要素で構成され、使える技術を制限することで表示速度の下限を保証する設計を採っていました。
一方で、AMPを取り巻く状況はこの数年で大きく変わりました。2021年にはトップニュースカルーセルの掲載要件からAMPが外され、検索結果の雷マークも廃止されました。さらに2026年7月には、AMPキャッシュ・AMPビューアを経由した配信そのものが終了し、検索結果からは各サイトのAMPページへ直接遷移する形になっています。Googleは、AMPコンテンツも他のWebページと同じようにランキングされると説明しています。
したがって、「AMPを導入すればSEOで有利になる」という説明は過去の状況を前提にした情報であり、現在は当てはまりません。現在のGoogleが公式に示している評価軸はCore Web Vitals（LCP・INP・CLS）であり、これはページがAMPで作られているかどうかを問いません。
これから高速化に取り組むのであれば、AMPという特定の技術を前提にするのではなく、画像フォーマットの最適化、遅延読み込み、JavaScriptの削減、CDNの活用といった一般的な手法で、通常ページのCore Web Vitalsを改善していくアプローチが現実的です。既にAMPを運用しているサイトについても、得られている効果と二重管理の運用コストを比較し、継続するかどうかを改めて判断する時期に来ていると言えるでしょう。