モバイルフレンドリーテスト2026: 無料ツールとPSI API

Googleは単体のモバイルフレンドリーテストを2023年12月に終了しましたが、モバイルでの使いやすさは今も無料で確認できます。パフォーマンスの診断にはPageSpeed InsightsとLighthouse、レイアウトの確認にはChrome DevTools、ナビゲーションとフォームの確認には実機のスマートフォンを使います。これらのチェックは、それぞれ別の問いに答えます。速いページでも押せないボタンがあることはあり、使いやすいページでも読み込みが遅いことはあります。

20秒で結果を知りたい場合は、無料のモバイルフレンドリーテストをお使いください。URLを貼り付けるだけで、ビューポート、固定幅、小さすぎる文字、ページの重さ、クロールの各項目が採点され、それぞれの直し方も表示されます。メールアドレスは不要です。

2026年も使えるモバイルフレンドリーのチェックツール

「Googleのモバイルフレンドリーテストを実行しましょう」という助言は、もう通用しません。GoogleはSearch Consoleのモバイルユーザビリティレポート、モバイルフレンドリーテストツール、モバイルフレンドリーテストAPIを2023年12月1日から順次終了すると発表し、終了は2023年12月4日に公に確認されました。その発表でGoogleが挙げた理由は、モバイルでの使いやすさは引き続きページエクスペリエンスのガイダンスの一部だが、2015年以降にほかのリソースが登場したというもので、そこには「including Lighthouse from Chrome」とあります。

Googleは2023年12月1日に検索ヘルプからこのツールへの言及をすべて削除し、Search Consoleのモバイルユーザビリティ関連のURLをプロパティの概要ページへリダイレクトしました。2023年4月の発表では、代わりとしてLighthouseを案内しています。終了したツールを今も使える選択肢として紹介しているガイドは、情報が古くなっています。

独立したチェックツールとしては、BingのMobile Friendliness Test Toolが残っています。ビューポートの設定、コンテンツの幅、読みやすさ、タップ対象の間隔など、Bingがモバイルでページをどう見ているかを確認します。この判定は、GoogleやAIアシスタントがそのページをどう評価し、引用するかを示すものではありません。

モバイルでの使いやすさとモバイルファーストインデックスは別のチェック

Googleは、ページのコンテンツのモバイル版をインデックス登録とランキングに使います。モバイルファーストインデックスのガイダンスは、レスポンシブデザイン、動的な配信、モバイル用の別URLのいずれにも対応しています。実装と保守がしやすいため、推奨されているのはレスポンシブデザインです。

まず、Googlebotがモバイルでコンテンツ、画像、メタデータにアクセスできるかを確認します。次に、人がそれをどれだけ簡単に使えるかを確認します。モバイルページがブロックされているならクロールの問題で、ボタンが窮屈ならユーザビリティの問題です。Lighthouseのスコアもタップ対象の測定も、それだけではページがインデックスされるかどうかはわかりません。

監査ツールのタブを増やすより、専門家にサイトを見てほしい場合は、ウェブサイト最適化サービスをご覧ください。

PageSpeed InsightsとLighthouseでモバイル監査を行う

まずはPageSpeed Insightsから始めます。URLを貼り付けて実行し、「パソコン」タブより先に「モバイル」タブを読みます。

レポートは、よく混同される2つの部分に分かれています。

• 上部のフィールドデータ: Chrome UX Reportによる実際のChromeユーザーの測定値で、28日間の移動期間で毎日更新されます。Googleのページエクスペリエンスのシグナルが実際に使うのはこちらです。
• 下部のラボデータ: Googleのサーバー上で行う、1回だけのLighthouseのシミュレーション測定です。診断には役立ちますが、実際のユーザーについての判定ではありません。

3つの指標すべてを含むCore Web Vitalsの評価に合格するには、3つの指標すべてで75パーセンタイルの値が「良好」の基準を満たす必要があります。フィールドデータがない場合、レポートはこの完全な評価を出せませんが、それはページが不合格だったという証拠ではありません。Lighthouseは、1回のナビゲーション測定ではフィールドのINPを測れません。

出典: web.devのCore Web Vitalsの基準値(2026年時点)。INPは2024年3月12日にFirst Input Delay (FID)に代わってCore Web Vitalsの指標になりました。今もFIDの最適化を勧めるチェックリストは無視してかまいません。

基準を動かしたPageSpeed Insightsの2つの変更

2024年12月5日、PageSpeed InsightsはCPU(プロセッサ)をどれだけ遅くするかの設定を調整し、その結果、モバイルのラボ測定ではTotal Blocking Timeが全体的に増えました。フィールドとパソコンの結果は影響を受けていません。何もリリースしていないのにモバイルのラボスコアが下がったなら、これが原因として考えられます。

PageSpeed Insights (PSI)とそのAPIは、2025年10月20日にLighthouse 13.0へ移行しました。バージョンによって表示される診断項目が変わることがあるため、結果ごとにLighthouseのバージョンを記録してください。実際のユーザーを継続的に監視するには、GoogleはCrUX APIまたはCrUX History APIを推奨しています。GoogleはPSI APIにCrUXのフィールドデータを含めるのをやめる予定です。

モバイルフレンドリーテストAPIの代わりはある?

旧モバイルフレンドリーテストAPIは、ツールと一緒に終了しました。PageSpeed Insights APIでモバイルのLighthouse測定を自動化することはできますが、以前のモバイルフレンドリーの合否は再現できません。レイアウトと操作のチェックは引き続き必要です。

次のリクエストは、モバイルのパフォーマンス、ユーザー補助、SEOの診断を要求します。例のURLを、テストしたい公開ページに置き換えてください。

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Googleのスタートガイドでは、キーなしでAPIを試すことが認められており、自動で頻繁にリクエストする場合はキーの使用が推奨されています。まとめて実行する予定を組む前に、プロジェクトの現在の割り当てを確認してください。HTTP 429が返ってきた場合は、テストしたページの結果として扱わず、割り当てを調べてください。パラメータとレスポンスのフィールドはAPIリファレンスに記載されています。

カテゴリごとのスコアはlighthouseResult.categories、個々の結果はlighthouseResult.auditsで読みます。スコアは0から1の尺度で、0.92は100点中92点にあたります。後で比較するときに測定内容がわかるよう、テストしたURLと一緒にfetchTimeとlighthouseVersionを保存してください。レスポンスを監査結果として扱う前に、HTTPエラーとruntimeErrorを処理してください。

フィールドのパフォーマンスには、CrUX APIまたはCrUX History APIを使います。URLによっては実際のユーザーのデータが足りないことがあります。その状態は結果が悪いこととは分けて扱い、ラボのスコアをフィールドのCore Web Vitals合格として報告しないでください。

Lighthouseをローカルで実行する

LighthouseはChrome DevToolsに組み込まれています。ページを開いて右クリックし、「検証」を選び、Lighthouseパネルを開いてモバイルを選択し、「レポートを生成」をクリックします。Lighthouseはインストール済みのChromeで動作し、結果をリモートのサーバーに送ることはありません。そのため、PSIが届かないステージング環境やパスワードで保護されたビルドも監査できます。

モバイルのプリセットは当て推量ではありません。LighthouseはCPUを4倍遅くする係数をかけてパソコンのCPUをミドルクラスのスマートフォン並みに落とし、さらに4G接続の下位4分の1に相当する「Slow 4G」のネットワークプリセットを加えます。デバイスのエミュレーションには、Lighthouse自身のconstants.jsによると、412×823のビューポートとデバイススケール係数1.75のMoto G Powerのプロファイルが使われ、モバイルとタッチが有効になります(この記事の以前の版では2.625と記載していましたが、それはLighthouseが廃止した旧Moto G4プロファイルのスケール係数で、現在の値ではありません)。

Lighthouse 13では、多くのパフォーマンス監査がDevToolsに合わせたインサイトに置き換えられ、unsized-imagesとnon-composited-animationsは診断項目として残りました。以前のフォントサイズの監査も削除されています。診断項目がなくなったからといって、読めない文字が許されるわけではありません。実際のページの文字をスマートフォンで確認してください。

Chrome DevToolsのデバイスエミュレーションの手順

スコアは速さを教えてくれます。エミュレーションは、ページが使えるかどうかを教えてくれます。両方行いましょう。

1. Chromeでページを開き、「検証」のショートカットを押して、デバイスツールバーを切り替えます。
2. まず幅の狭いビューポートを選びます。360×800と390×844で試してから、タブレットの幅まで段階的に広げます。
3. スロットリングをMid-tier mobileに設定するか、Lighthouseのプロファイルに合わせてSlow 4GとCPU 4倍を手動で適用します。
4. 横向きに回転させます。それぞれの向きで、メインのナビゲーション、フォーム、購入手続きまたは問い合わせのステップを開きます。
5. サイズを変えながらElementsパネルを見て、どのコンテナがはみ出しているかを見つけます。

スコアでは決して見つからず、エミュレーションで見つかるもの:

• 隣の要素に詰め込まれた小さなタップ対象。Lighthouseのタップ対象の監査が扱うケースも含みます
• 固定幅の表、埋め込み、大きすぎる画像による横方向のはみ出し
• 縦の短い画面でビューポートの半分を占める固定ヘッダーやCookieバナー
• 閉じるボタンが画面外に押し出されたモーダル
• フォーカスしたときに間違ったキーボードが出たり、拡大されたりする入力欄

押しやすいタッチ操作のためには、レイアウトが許す範囲で48×48 CSSピクセルを目安にしてください。Lighthouseの文書化されたルールは、対象の大きさと近くの対象との重なりの両方を考慮しており、小さな要素をすべて不合格にするわけではありません。別の基準であるWCAG 2.2 AAのターゲットサイズの達成基準は、間隔などの例外つきで24×24 CSSピクセルを使います。どちらも、Googleのランキングに共通する基準値ではありません。

限界も知っておきましょう。エミュレーションは、パソコンのブラウザのサイズを変え、遅いCPUを擬似的に再現するだけです。実際のタッチの遅延、iOSのSafariのくせ、親指の届く範囲、発熱で性能が落ちたミドルクラスのAndroidが重いスクリプトをどう処理するかは再現できません。どの監査も、最後は実機のスマートフォンで締めくくってください。

Search ConsoleでCore Web Vitalsのモバイルデータを読む

以前のモバイルユーザビリティレポートはなくなりました。実際のユーザーのパフォーマンスにはSearch ConsoleのCore Web Vitalsレポートを使い、レイアウトと操作は別に確認します。

Search Consoleを開き、「ウェブに関する主な指標」に進んで、モバイルのレポートを確認します。Googleは概要をデバイス別に分け、似た体験を提供するURLをグループにまとめ、各グループに最も成績の悪い指標のステータスを割り当てます。つまり、あるテンプレートで指標が1つ悪いだけで、そのテンプレートのURLがすべて「不良」になります。

私たちの読み方:

• モバイルのグラフの横にあるレポートを開くをクリックし、「不良」「改善が必要」「良好」のタブを切り替えます。
• 「URLが良好と見なされない理由」の表を読みます。不合格の指標と、超えた基準値が示されます。
• URLではなくテンプレートを直します。ステータスがグループ単位なので、テンプレートを1つ直せば多くのページが動きます。
• 修正をリリースしたらトラッキングを開始を使います。Googleは28日間のモニタリングを行い、期間中ずっと問題が出なかった場合にだけ修正済みとします。

注意点が2つあります。データは28日間の移動集計なので、火曜日にリリースした修正が水曜日に反映されることはありません。また、GoogleははっきりとPageSpeed InsightsのデータはCore Web Vitalsレポートと異なる場合があると述べています。一方は1つのデバイスプロファイルでのラボ測定で、もう一方は数千件の実際のセッションだからです。両者が食い違うときはフィールドデータを信頼し、ラボ測定で原因を探します。ラボとフィールドの違いはweb.devで詳しく解説されています。同じ指標は、私たちのウェブサイト最適化の進め方にも組み込まれています。

よくあるモバイルの不具合と直し方

上記のツールが見つけるための不具合と、それぞれに使われる基準値やルールです。

どのツールが何を検出するかに注目してください。1つのチェックツールですべてを網羅できるものはありません。だからこそ、以前の合否のバッジだけでは決して十分ではなかったのです。

私たちが行う監査の手順

自社サイトとクライアントのサイトで使っている順番です。

1. URLは1つではなく3つ選びます。 ホームページ、主要なサービスまたは製品ページ、ブログ記事です。テンプレートごとに不具合の出方が違います。
2. 最初にSearch Console。 ウェブに関する主な指標のモバイル表示で、どのURLグループが「不良」または「改善が必要」になっているか、どの指標が挙がっているかを書き留めます。実際のユーザーのデータなので、これで優先順位が決まります。
3. 不合格のグループごとに1つのURLをPSIで測定します。 フィールドデータとラボデータを比べます。フィールドが「不良」でラボは問題なしなら、サードパーティのスクリプト、ログイン後の状態、遅いオリジンサーバーなど、きれいなラボ測定では見えないものを探します。
4. 同じ3つのURLをローカルのLighthouseで測定します。 モバイルのプリセットで、タップ対象とunsized-imagesの診断、コントラストの問題についてはユーザー補助のパネルを読みます。
5. DevToolsのデバイスモードで360×800。 ナビゲーション、フォーム、主要なコンバージョンのステップを開き、回転させて、はみ出しや隠れたコンテンツを探します。
6. BingのMobile Friendliness Testを同じURLで実行し、ビューポート、幅、読みやすさ、タップの間隔について2つ目のクローラーの判定を得ます。
7. 実機のスマートフォンを1台。できればミドルクラスのAndroid。 オフィスのWi-Fiではなくモバイル回線で読み込み、コンバージョンの操作を最初から最後まで行います。
8. テンプレートの修正をリリースし、Search Consoleでトラッキングを開始します。 検証が完了するまで28日かかると見込んでください。

フィールドデータとラボデータが食い違う理由

GoogleはPageSpeed InsightsのデータはCore Web Vitalsレポートと異なる場合があると明言しています。ラボデータは1つのデバイスプロファイルでの1回のシミュレーションです。フィールドデータは、実際のChromeユーザーの28日間の移動集計です。web.devのラボデータとフィールドデータのガイドは、よくある原因として次を挙げています。実際の端末と回線はラボよりばらつきが大きいこと、サードパーティのスクリプトは実際のユーザーに対して違う動きをすること、キャッシュとバックフォワードキャッシュが再訪問を変えること、CrUXは十分なトラフィックのあるURLしか報告しないことです。食い違うときは、フィールドデータを判定として、ラボ測定を診断として扱います。

サイトを見直すときは、まずSearch Consoleのフィールドデータを確認し、次にPSIとLighthouseで要素やスクリプトを特定します。Google自身の最適化ガイドが手引きになります。

• LCPが遅い: Largest Contentful Paintを最適化する。メイン画像を圧縮し、最新の形式で配信し、LCP要素をプリロードし、遅延読み込みにしないこと。
• INPが高い: Interaction to Next Paintを最適化する。長いタスクを分割し、メインスレッドをブロックするサードパーティのJavaScriptを遅らせるか削除すること。
• CLSが高い: Cumulative Layout Shiftを最適化する。画像と埋め込みに幅、高さ、またはaspect-ratioを指定し、読み込み時にレイアウトがずれないようにすること。

Search Consoleは似た体験を提供するURLをグループにまとめ、各グループに最も成績の悪い指標のステータスを割り当てます。共通のカードコンポーネントで画像サイズを指定するといった、テンプレートの修正1つで多くのURLが一度に動くことがあります。リリース後はトラッキングを開始を使い、Googleが問題を修正済みとするまで28日間の期間をすべて待ってください。

テーマの変更、プラグインやアプリの導入、タグマネージャーのあらゆる公開の後には、この8つの手順を繰り返し、さらに四半期に一度の定期チェックも行ってください。サードパーティのスクリプトは、GoogleのINPのガイダンスでINPのリスクとして記載されています。手順3でフィールドデータときれいなラボ測定を比べるのはそのためです。このモバイルチェックに関わるクロール、インデックス、ページ上の施策については、検索エンジン最適化のサービスをご覧ください。

WordPressやShopifyを使っている場合

どちらのプラットフォームも、コードではなく設定でほとんどのことができます。

• 採用を決める前に360pxで試した、レスポンシブなテーマ
• LCPの画像以外はすべてネイティブの遅延読み込み
• CSS(カスケーディングスタイルシート)で縮小したパソコン用の画像ではなく、正しいサイズで配信する最新の画像形式
• Shopify Online Store 2.0のテンプレートと、セクション単位での画像サイズ指定
• インストール済みのアプリとプラグインの監査。それぞれが表示をブロックするJavaScriptを追加することが多いためです

テーマやアプリを変えるたびに、Lighthouseを実行し直してください。モバイルのスコアが気づかないうちに下がるのは、まさにそこです。テーマそのものが限界なら、パフォーマンスとSEOを最初から組み込んだ最新のフレームワークで作り直すのが解決策で、それを実現するのが私たちのウェブサイト開発サービスです。

よくある質問

Googleのテストがなくなった今、モバイルフレンドリーかどうかはどう確認すればよいですか?

Chrome DevToolsのLighthouseをモバイルのプリセットで実行し、PageSpeed Insightsの「モバイル」タブを確認し、Search ConsoleのCore Web Vitalsのモバイルレポートを読み、最後に実機のスマートフォンで確かめます。合否の判定がほしい場合は、BingのMobile Friendliness Testが今も出してくれます。

モバイルフレンドリーとレスポンシブの違いは何ですか?

モバイルフレンドリーとは、スマートフォンでページが使えることを意味します。レスポンシブデザインは、可変のレイアウトとCSSのメディアクエリで、同じページをさまざまなビューポートに合わせます。Googleは保守が簡単なレスポンシブデザインを推奨していますが、動的な配信やモバイル用の別URLにも対応しています。

モバイル専用のサイトは別に必要ですか?

いいえ。レスポンシブなURLが1つなら保守が簡単で、重複コンテンツの扱いも不要になり、SEOと生成エンジン最適化に向けたシグナルも1つにまとまります。

Googleはモバイルフレンドリーでないサイトにペナルティを科しますか?

コンテンツへのアクセスとユーザー体験は分けて確認してください。インデックス登録のために、Googleはモバイルのコンテンツにアクセスしてレンダリングできる必要があります。Core Web Vitalsはランキングに使われますが、ページエクスペリエンスが十分でなくても、Googleは関連性の高いコンテンツを探します。モバイルのスコアが悪いことだけでは、インデックスからの削除、ペナルティ、特定の順位低下の証明にはなりません。

PageSpeed InsightsとSearch Consoleの結果が食い違うのはなぜですか?

Googleは、両者が異なる場合があると述べています。PSIのラボデータは、1つのデバイスプロファイルでの1回のシミュレーションです。Search Consoleは、URLグループ全体について、実際のChromeユーザーの28日間の移動集計を報告します。GoogleのCore Web Vitalsレポートのドキュメントとweb.devのラボとフィールドの記事はどちらも、フィールドデータを判定、ラボデータを診断として扱うよう説明しています。

1つのバッジが4つのツールに置き換わった

合否のバッジはなくなり、戻ってくることはありません。代わりに登場したものの方が優れています。実際のユーザーのフィールド測定、ステージング環境でも実行できるラボ監査、レイアウトのためのビューポートのエミュレーション、そしてBingによる2つ目のクローラーの判定です。この4つを軸にプロセスを組み、Search Consoleが示す実際のユーザーの体験で優先順位を決め、個々のURLではなくテンプレートを直しましょう。

私たちはバンクーバーを拠点に、これをウェブサイト最適化として提供しています。モバイルのパフォーマンスが順位やコンバージョンを損なっているなら、まずはグロース監査から始めてください。