PageSpeed Insights MCP

PageSpeed Insights MCP

Google PageSpeed Insights でウェブページを測定し、複数回の実行結果の中央値とそのばらつきを並べて報告するため、数値とともに不確実性も把握できます。MCP に対応したアシスタントからでも、ターミナルからでも利用できます。

標準ライブラリのみを使用します。仮想環境も、pip も、コンパイルが必要な依存関係もありません。クローンして実行するだけです。

ドキュメント · インストール · よくある質問

なぜ別のものが必要なのか

PageSpeed MCP サーバーはすでにいくつかあります。私たちの知る限り、そのどれもが Lighthouse を一度だけ実行し、その数値をモデルに渡しています。

Lighthouse の単回実行はノイズです。変更していないページでも、Total Blocking Time は実行ごとに日常的に3倍も変動します。主要なパフォーマンススコアは重み付けされた複合値で、その変動をすべて引き継ぎます。一度だけ測定すると、誤差範囲のない数値しか得られず、本当のリグレッションと測定値の揺れを見分ける方法もありません。これはわずかな精度の問題ではありません。何かを測定することと、自信満々に推測することの違いです。

さらにもう一つ、根本的な問題があります。目に見えないため、もっと厄介です。PageSpeed は URL ごとに結果をキャッシュし、再利用します。5回尋ねても、同じ分析結果を5回渡されることがあり、気づかないうちに中央値が Google のキャッシュ内容への投票になってしまいます。2026年7月30日のデプロイから数分後、実際にそれが起きました。3回中2回の実行で、デプロイ前のタイムスタンプとバイト単位で同一の結果が返され、修正が機能していることを示した新しい実行結果が1つあったにもかかわらず、平均値は修正前のスコアに引き戻されました。単回実行の結果だけを報告するツールなら、古い数値を最新のものとして報告し、問題を示す手がかりは何もありませんでした。

このツールはデフォルトで5回の実行結果の中央値を取り、すべての数値の横に最小値と最大値の範囲を表示し、キャッシュから再生された結果を除外して、除外した件数も伝えます。

ラボの結果はユーザーの実態ではありません

同じ日の午後、同じページで測定した次の2つは、どちらも事実です。

	LCP	判定
Lighthouse のラボ測定、モバイル	21.36 s	パフォーマンス 27 / 100
実際の Chrome ユーザー、28日間の p75	1.20 s	高速

これは BBC のホームページです。ラボでは、サイトは壊滅的に遅いという結果になります。実際のユーザーは1.2秒で表示できています。

どちらの数値も間違いではありません。答えている問いが異なります。Lighthouse はスロットリングされたハードウェア上でのシミュレーションです。再現性があり、まだ誰も訪れていないページでも実行できるため、有用です。フィールドデータは実際の Chrome ユーザーに起きたことを示すもので、Google のランキングで使われるのはこれだけです。一方だけを表示するツールは、どちらを選んだとしても、誤解を招きます。

そこでこのツールは、両方を別々に報告し、決して一つの数値に統合しません。

機能

• N 回の異なる分析結果の中央値と、すべてのスコアおよび指標の横に最小値と最大値の範囲を表示します。
• Google は URL をおよそ1分に1回再分析し、その間にリクエストしたすべてのものにキャッシュ結果を返すため、真に異なる分析結果が N 件得られるまでリクエストを続けます。連続して5回リクエストしても、同じ測定を5回繰り返しただけです。
• リクエスト数と所要秒数を示し、時間切れになった場合は、件数を水増しせず、実際より少ない分析結果を正直に報告します。
• Google にデータがある場合は、Chrome UX Report の実ユーザーデータと、最大6か月分の週ごとの履歴を取得します。
• Google にデータがない場合は、そのことを明確に伝え、ラボのスコアを実際の訪問者に関する証拠として扱いません。
• クォータ切れとページの障害、設定ミスのあるキーとその両方を区別します。

実際に聞いてみること

異なる機能を試せる4つの質問です。どれもツール名を知っている必要はありません。

「considus.com のモバイルでの速度はどれくらいで、その数値の確信度はどの程度ですか？」 これを実現するために作られました。実際に異なる複数の分析結果の中央値と、そのばらつきが得られます。1回の測定結果を事実として引用することはありません。

「このサイトには実際のユーザーデータがありますか、それともラボの測定値だけですか？」 Chrome UX Report を読み込みます。これは実際の訪問者についての唯一の証拠であり、Google がランキングに使う唯一のデータです。多くの小規模サイトにはデータがなく、その場合はラボのスコアだけで済ませず、そのことを伝えます。

「このページの LCP を実際に遅らせているのは何ですか？」 1つの数値を構成する4つのフェーズに分解し、サーバー、検出、ダウンロード、描画のどれが原因なのかを確認できます。1回の呼び出しで素早くわかり、平均を取る必要もありません。

「その変更で改善しましたか？」 最初の呼び出しでベースラインを記録し、変更を加えた後に比較します。2つの範囲が重ならない場合にのみ差が本物だと判定します。これにより、計測器自体の揺れを改善だと喜んでしまうのを防げます。

始める前に

Google Cloud の API キーが必要です。無料で、所要時間は約1分です。手順3で決めることが1つあります。

1. console.cloud.google.com を開き、アカウントを選びます。
2. API とサービス。
3. サイドバーの API ライブラリ。PageSpeed Insights API を検索して選択し、有効にするを押します。

   この画面を開いている間に決めましょう。 実際のユーザーのデータ、つまり実際の Chrome 訪問者がどのような体験をしたか、また過去6か月間にどう変化したかも確認したい場合は、先に進む前に Chrome UX Report API も検索して有効にします。同じキーを使うため、別の認証情報は不要です。今開いている画面でもう1回検索するだけです。有効にしなくても、それ以外の機能はすべて使えますが、ラボの測定値のみになります。後から追加するには、この画面と手順7に戻る必要があります。今決めておく価値があるのはそのためです。

4. 認証情報。今開いているページではなく、サイドバーから選びます。
5. 上部の 認証情報を作成、次に API キー。
6. 名前を付けます。
7. API の制限で PageSpeed Insights API にチェックを入れます。手順3で有効にした場合は、Chrome UX Report API にもチェックを入れます。
8. サービス アカウントを使用して API 呼び出しを認証するにはチェックを入れないでください。
9. アプリケーションの制限は なしのままにします。
10. 作成を押し、キーをコピーします。

手順4でつまずく人が多く、私もつまずきました。認証情報の画面に行く方法は2つありますが、API キーを作成できるのはそのうち1つだけです。今開いているページから進むと、OAuth クライアントとサービス アカウントしか表示されず、API キーはどこにもありません。そのため、PageSpeed は API キーに対応していないのだと考えるのも無理はありません。実際には対応しています。サイドバーの項目からは別の画面に移動でき、API ライブラリのすぐ下にあります。

手順9は間違っているように見えますが、間違いではありません。このフォームでは HTTP リファラー制限が安全そうな選択肢に見えますが、このようなプログラムからキーを使えなくなります。参照元となるウェブページがないためです。キーでアクセスできる範囲を制限するのは、手順7の API 制限です。

インストール

どちらの方法を選ぶ場合も、後から移動しない場所にクローンしてください。ホームディレクトリ内のフォルダーがおすすめです。アシスタントの設定では、そのパスを指定するため、後で移動するフォルダーを使うと接続が切れてしまいます。ダウンロードフォルダーや一時フォルダーは使わないでください。

どちらの方法も、最後の手順は同じです。setup.py を実行すると、ランダムなポートを使って、お使いのマシン上でのみ利用できる小さなページがブラウザーに開きます。リンクは1回のみ使用でき、完了するとページは自動的に終了します。入力した内容が保存されることもありません。キーを貼り付けてください。何かを保存する前に Google でキーを検証し、実際のユーザーデータを利用できるかどうかを知らせます。

必要なときはいつでも再実行できます。以前にセットアップしたことを検出するため、キー欄を空白のままにすれば、現在のキーがそのまま使われます。

アシスタントに実行してもらう

このコンピューター上でシェルコマンドを実行するAIアシスタントに、これを貼り付けてください。 実行を許可する前に、提案内容を確認してください。

Please install the PageSpeed Insights MCP server from
https://github.com/Considus/pagespeed-insights-mcp on this computer, following the
Install section of its README exactly. Clone it into a permanent folder in my home
directory, then run setup.py and tell me the local link it prints so I can finish
setup in my browser. Show me each command before you run it.

または、コマンドを自分で実行する

macOSやほとんどのLinuxマシンには、Python 3.9以降がすでにインストールされています。Windowsの場合は、python.orgからインストールするか、winget install Python.Python.3.12を実行してください。

git clone https://github.com/Considus/pagespeed-insights-mcp.git
cd pagespeed-insights-mcp
python3 setup.py

アシスタントに接続する

セットアップが完了すると、2つ目のプロンプトが表示されます。それを、ページを測定してほしいアシスタントに貼り付けてください。Claude、Cursor、Windsurf、Zed、Codex CLI、VS Code Copilotなど、MCPに対応するものであれば何でも構いません。その後、アプリを再起動してください。MCP サーバーは起動時に読み込まれます。

この手順には理由があります。クライアントごとにMCP設定の保存場所やキーが異なり、その場所も変わるためです。アシスタントは自分の設定の保存場所をすでに把握しているので、古くなりがちなパスの一覧を配布するより、アシスタントに尋ねるほうが確実です。プロンプトに含まれるのは、名前、コマンド、パスだけで、キーは含まれません。

ツール

ツール	説明
analyse_page	すべてを一度に取得でき、最も多くの人が求めるツールです。スコアとそのばらつき、修正の価値が高い順に並べた問題、Googleにデータがあれば実ユーザーデータ、保存や転送ができる自己完結型のHTMLページを取得します。すべての分析で失敗した問題だけをカウントします。監査結果はスコアと同様、ばらつきがあるためです。すべての項目が必要でない場合は、includeで scores、issues、field_data、htmlのうち必要な部分を選べます。指定したすべての部分で、1回の測定結果が使われます。ジョブIDが返されます。
get_field_data	Chrome UX Reportから実ユーザーデータを取得します。1回の呼び出しで、すぐに結果が返ります。週ごとのp75系列にはurlsとhistoryを指定します。
explain_lcp	Largest Contentful Paintが遅くなる原因となっている4つのフェーズのうち、どれかを特定します。サーバーの応答、ブラウザーが最大の画像の取得を開始するまでの待機、ダウンロード、そして描画されるまでの待機です。1回の呼び出しで、すぐに結果が返ります。
compare_to_baseline	変更によって実際に改善したかどうかを確認します。現在の状態を測定して保存済みのベースラインと比較し、2つの範囲が重ならない場合にのみ判定を示します。ジョブIDが返されます。
get_job_result	ジョブIDとして返された測定結果を取得します。いつでもすぐに結果が返ります。job_idを指定するか、最新の結果を取得する場合は何も指定しません。
check_setup	キーが機能するか、Chrome UX Reportにアクセスできるか、どのベースラインが保存されているかを確認します。キーは開示されません。

呼び出しが終わっても続く計測

長時間かかるチェックは毎回タイムアウトしていましたが、サーバーは最初からずっと正常でした。計測を続けてジョブを正しく完了し、もう誰も読んでいないパイプに結果を投稿していたのです。

クライアントは60秒であきらめます。これは1回のツール呼び出しに設けられた厳格な上限で、進捗通知を送っても延長されません。このサーバーは進捗通知を送るため、延長できそうに見えますが、知っておく価値があります。正確な計測はこの上限内に収まりません。Googleはおよそ1分ごとにURLを再分析するため、異なる分析を5回行うには約150秒かかります。回数を増やしても役には立たず、同じキャッシュ済みの分析結果が5回返ってくるだけです。

処理はもう呼び出しの中では行われません。analyse_page と compare_to_baseline は計測を開始してジョブIDを返し、その後も処理を続けます。アシスタントは15秒おきほどに get_job_result で結果を取得し、get_job_result は常にすぐに応答します。計測が完了すると、ツールが返すはずだったものとまったく同じ結果が返るため、後続の処理からはどちらの経路を通ったか分かりません。

特に何もする必要はありません。アシスタントが代わりに結果をポーリングします。

1回の計測に限り、その場ですぐに結果が返るケースもあります。include を ["scores"] に設定し、URLを1つだけ指定して、runs を1にした analyse_page です。これはばらつきを考慮しない単一の分析です。このパッケージがまさに避けようとしている、ノイズの多い1回だけの数値であり、出力にはそのことが明記されます。

完了したジョブは、もう一度確認したい場合に備えて1時間保存されます。サーバーが再起動すると実行中のジョブは失われます。クライアントはしばらくアイドル状態が続くと再起動することがあるため、get_job_result はそのことを知らせ、決して完了しないジョブをポーリングし続けることがないようにします。

クライアントの待機時間が60秒を超える場合は、サーバーに伝えれば呼び出し中により多くの処理を実行します。settings.json の inline_budget_seconds、または環境変数 PAGESPEED_INLINE_BUDGET を設定してください。サーバーがこれを自力で判定することはできません。タイムアウトはプロトコルに含まれておらず、サーバーが引き継ぐ限られた環境変数にも含まれていないためです。

explain_lcp を読む前に知っておくべきことが2つあり、どちらもすべての回答に表示されます。4つのフェーズの合計はLCPにはなりません。その差は丸めによるものでもありません。実際のオリジン12件では、合計は40ミリ秒少ない場合から2.6秒多い場合までありました。各フェーズはそれぞれ独立した75パーセンタイルであり、パーセンタイルは足し合わせられません。また、フェーズが測定されるのは最大要素が画像だった訪問に限られます。一部のサイトではその割合は少ないため、回答には常に、どの割合の訪問について説明しているかが記載されます。

2つ目の点は、注意事項であると同時に、役立つ情報でもあります。ある大規模サイトでは、LCPは1.5秒と余裕があるように見えますが、画像がLCPとなる訪問の8分の1では、画像のダウンロードが始まるまでに3.3秒かかっています。見出しに表示される数値からは、そのことは分かりません。

compare_to_baseline は、調査結果だけでは分からない「行った変更に効果があったか」という疑問に答えます。URLに対する最初の呼び出しではベースラインが記録されるだけで、比較は行われません。まだ比較対象がないためです。変更を加えてもう一度呼び出すと、新たに計測して、どこが変わったかを報告します。

2つの最小値から最大値までの範囲がまったく重ならない場合に限り、判定を示します。これは意図的に慎重な基準であり、小さな実際の改善を見逃すことがあります。その理由は、2種類の誤りが同じ程度に悪いわけではないからです。変化があったのに何も変わらなかったと伝えるのは、少し自信を失わせるだけです。一方、ノイズにすぎないのに改善したと伝えると、クライアントに伝えてしまう可能性のある主張になります。変更が実際にあった場合は、中央値の差と、範囲から確実に保証されるより小さな数値の両方を報告します。引用する数値は、保証されたほうを使ってください。

ベースラインは設定ファイルと同じ場所にある baselines.json にURLとストラテジーごとに保存され、明示的に指示しない限り変更されません。フィールドデータは意図的に比較対象から除外されています。28日間のローリングウィンドウでは、今週行った変更を反映できないためです。

スキル

skills/pagespeed-insights-read/ は、結果の読み取り方をアシスタントに教えます。 サーバーは、不確実性を伴わずに数値を示すことを拒みます。ただし、アシスタントが回答する際にその不確実性を落とすのを防ぐことはできません。最もよくある誤りは、4つの削減見込みを合計して、9秒短縮できると約束することです。

これは任意です。なくてもすべて動作し、ツールの説明にも同じ警告が記載されています。このスキルがあれば、回答に至る過程で警告が言い換えによって失われるのを防げます。

クライアントごとにスキルの保存場所は異なり、ディスクから読み込むのではなくアカウントと同期するものもあれば、そもそもスキル機能がないものもあります。そのため、特定のクライアントのパスを表示するのではなく、お使いのクライアントに尋ねてください。クローンした場所のフォルダーパスを入力して、これを貼り付けます。

I have a skill folder on this computer and I would like you to install it into
whichever client you are running inside, if that client supports skills.

  Skill folder = /path/to/pagespeed-insights-mcp/skills/pagespeed-insights-read

Please:
1. Work out whether this client supports skills, and where it keeps them on this
   machine.
2. Install the folder there, keeping its folder name unchanged. Most clients take
   the name of the folder as the name of the skill, so renaming it renames the
   skill.
3. Prefer linking to the folder above rather than copying it, if this client
   follows links, so it updates when I next pull. Copy it if not.
4. If this client syncs skills from an account rather than reading this disk, do
   not guess at a path. Tell me where to add it instead.
5. Tell me what you did and whether I need to restart the app.

If this client has no concept of skills, say so plainly and do nothing.
Everything works without it.

セットアップでは、実際のパスをあらかじめ入力した同じプロンプトが表示されます。

2つの URL を対象に5回分析するには数分かかります。何度も要求しても速くはなりません。Google は、何をしても URL をおよそ1分に1回再分析するため、時間がかかるのはリクエストをキューに入れるためではなく、新しい測定結果が得られるのを待つためです。新しい分析結果が出るたびにサーバーが進捗状況を送信するので、クライアントが処理を諦めずに済みます。アシスタントが速くするために runs=1 を使うと提案した場合は、いいえ、それこそがこの機能で防ごうとしていることだと伝えてください。

問題がある場合は、まず check_setup を実行してください。設定の問題なのか、ページの読み込みが遅いのかを約2秒で切り分けられます。

ターミナルから

クローンしたフォルダーからは、モジュールとして python3 -m pagespeed_insights を実行します。どこからでも使える pagespeed コマンドを利用するには、ランチャーを PATH にリンクします。

mkdir -p ~/.local/bin
ln -s "$PWD/pagespeed" ~/.local/bin/pagespeed

~/.local/bin が PATH に含まれていない場合は、シェルのプロファイルに export PATH="$HOME/.local/bin:$PATH" を追加してください。Windows ではシンボリックリンクの手順はありません。フォルダーを PATH に追加するか、フォルダー内から python -m pagespeed_insights を使い続けてください。

セットアップにはそのコマンドが表示されますが、実行はされません。設定以外の場所には何も書き込みません。実行ファイルを PATH のディレクトリーにひそかに配置するツールを防ぐために、このルールがあります。

pagespeed https://example.com/
pagespeed --runs 3 --strategy both https://example.com/
pagespeed --field --history https://example.com/
pagespeed --lcp https://example.com/
pagespeed --findings https://example.com/
pagespeed --compare https://example.com/
pagespeed --baselines
pagespeed --field --report report.html https://example.com/
pagespeed --json https://example.com/

--report は、スクリプトもネットワーク接続も外部ファイルも使わない、自己完結型の HTML ページを1つ作成します。ファイルから開けて、メールで送ってもそのまま使えます。これは重要です。最も大きな問題点は、チェックを実行した人ではなく、ホスティング事業者やサードパーティーの判断に関係することがよくあるためです。

アシスタントに同じページを保存させることもできます。レポートを依頼すると、保存先を尋ねられます。サーバーが書き込むのは、指定したフォルダーに、依頼があった場合だけです。フォルダーを作成することはなく、既存のレポートを上書きすることもありません。変更前と変更後を比較する人には、両方が必要だからです。フォルダーを指定しない場合は、設定ファイルと同じ場所にある reports フォルダーに保存され、ファイルを見つけられるようフルパスが返されます。

保存したファイルには埋め込みフォントが含まれ、サイズは約150KBです。会話に返されるコピーではフォントが省かれます。145KBの base64 を使うと、コンテキストウィンドウの大部分がタイポグラフィに費やされるためです。どちらも同じレンダラーを使います。

URL を指定しない場合は、セットアップ時に保存した URL が使われます。

終了コードは、問題の種類ごとに分かれています。そのため、CI で実行するプログラムから、サイトの問題と Google 側の一時的な問題を区別できます。

コード	意味
0	問題ありません
1	その他の問題が発生しました
2	引数が正しくありません
3	クォータを使い切りました。サイトではなく、インフラストラクチャ側の問題です
4	認証情報が拒否されました。サイトではなく、設定の問題です
5	ページに到達できません。これはサイト側の問題です
6	Google に到達できません。サイトではなく、ネットワーク側の問題です

ページに問題があることを示すのは5だけです。3や6でビルドを失敗させるのは、Google が混み合っていたことを理由に失敗させることになります。

問題が発生した場合

すべてのエラーには、スタックトレースではなく、解決方法を示す文章が添えられています。また、その大半は測定対象のサイトとは関係ありません。どれがどれなのかを把握しておけば、壊れてもいないものを変更せずに済みます。

キーなしで429が返る場合。 共有の匿名プールを使っています。このプールはほかの利用者も使っており、通常は昼過ぎまでに使い切られます。測定対象のページについては何も示していません。セットアップを実行してキーを追加してください。

キーありで429が返る場合。 ご自身のプロジェクトの1日あたりの割り当てを使い切っています。太平洋時間の午前0時にリセットされます。

PageSpeed Insightsから400または403が返る場合。 キーがないか、間違っているか、HTTPリファラー制限が設定されています。よくある原因は最後のケースです。開始する前にの手順9が問題を引き起こしています。プログラムには参照元のWebページがないため、この制限が設定されたキーは毎回拒否されます。APIの制限を使うか、制限を設定しないでください。この画面を開いている間に、プロジェクトでPageSpeed Insights APIが有効になっていることも確認してください。

オリジンのフィールドデータがない場合。 これは失敗ではないため、ツールもエラーとして報告しません。Googleが実ユーザーデータを公開するのは、ユーザーの匿名性を保てるだけのトラフィックがあるオリジンだけです。そのため、小規模なサイト、新しいサイト、公開前のサイトにはデータがなく、訪問者が来るまでデータはありません。残るのはラボデータだけですが、これはシミュレーションであり、実際のユーザー体験を示すものではありません。

Chrome UX Reportに、このプロジェクトでは使用されていないと表示される場合。 APIが有効になっていないか、1分ほど前に有効にしたばかりで、まだ反映されていません。この2つは外部からは区別できません。また、表示される前にすでに再試行されています。何も変更せず、数分待ってから再実行してください。

Chrome UX Reportがキーを拒否する場合。 キー自体に問題はなく、APIの制限にChrome UX Report APIが含まれていないだけです。Google Cloudコンソールで、［認証情報］からキーを編集し、APIの制限に追加してください。

Lighthouseがページを読み込めなかった場合。 これまでの問題とは異なり、これは実際にサイトに関する問題です。ログインが不要で、地域によるブロックもなく、匿名の訪問者に対してURLが200を返すことを確認してください。

Googleにまったく接続できなかった場合。 ネットワーク、DNS、またはタイムアウトの問題です。報告されるまでに、すでにバックオフ付きで再試行されています。

アシスタントにリクエストがタイムアウトしたと表示される場合。 約1分を超える処理はジョブIDとして返されるようになったため、ここでそのような時間がかかる処理はないはずです。この表示が出る場合は、クライアントが待てる時間を超える処理が呼び出し内に設定されています。settings.jsonのinline_budget_secondsとPAGESPEED_INLINE_BUDGET変数を確認し、値を小さくするか、設定を削除してください。

ジョブが失われたと表示される場合。 測定中にサーバーが再起動しました。アイドル状態が続いていたサーバーに対して、クライアントが再起動を行ったためです。測定を再開し、実行中はアシスタントによるポーリングを続けてください。

どれに該当するかわからない場合は、check_setupで確認できます。キーが機能するか、Chrome UX Reportに接続できるか、どのベースラインが保持されているかを確認できますが、キーが開示されることはありません。

更新

パッケージもインストーラーもないため、ダウンロードするものはありません。サーバーはクローンしたディレクトリから mcp_server.py として実行されるので、更新はプルして再起動するだけです。

キーと保存した URL はそのディレクトリではなく、プラットフォームの設定ディレクトリにある settings.json に保存されます。そのため、更新してもそのまま残り、キーを再度尋ねられることもありません。

再起動の部分で戸惑う人が多くいます。stdio MCP サーバーは長時間実行されるプロセスで、アプリが起動したときに mcp_server.py を一度だけ読み込みます。すでに実行中のサーバーのファイルを書き換えても何も起きないため、アプリを正しく終了してから、もう一度開いてください。macOS ではウィンドウを閉じるだけでは不十分です。Windows でも、アプリがトレイに残る場合は最後のタブを閉じるだけでは不十分です。

リリースにはタグが付いており、GitHub のリリースページにはそれぞれの変更点が記載されています。pagespeed --version で現在のバージョンを確認でき、アシスタントもサーバーのハンドシェイクから同じバージョン番号を読み取れます。git pull を実行すると最新の main に切り替わりますが、最新のタグより先に進んでいる場合もあります。

アシスタントに作業を依頼する

これを、シェルコマンドをこのコンピューター上で実行する AI アシスタントに貼り付けてください。プルは実行できますが、自身が動作しているアプリは再起動できないため、最後の手順はご自身で行ってください。

Please update my PageSpeed Insights MCP server. Find where it's installed by
reading the path out of this app's MCP config rather than guessing it, run git
pull in that folder, and tell me what changed. Don't run setup.py and don't edit
my settings.json, my key and saved URLs are already in it. Then remind me to quit
this app completely and open it again, because the server only reads
mcp_server.py at startup.

またはコマンドを自分で実行する

クローンしたフォルダーで実行してください。

cd pagespeed-insights-mcp
git pull

ファイルの保存場所

キーと保存した URL は、プラットフォームの設定ディレクトリにある settings.json に保存されます。

• macOS、~/Library/Application Support/pagespeed-insights-mcp/
• Linux、~/.config/pagespeed-insights-mcp/
• Windows、%APPDATA%\pagespeed-insights-mcp\

保存した URL を追加、変更、削除するには、クローンしたフォルダーから python3 setup.py をもう一度実行してください。入力欄には前回保存した内容が表示されるので、リストを編集して送信します。リストを空にすると、毎回サイト名を指定する状態に戻ります。新しいキーを入力しない限り、キーはそのまま保持されます。この操作に使える CLI フラグはありません。ファイルは小さく、プレーンな形式なので、手動で編集しても同じように機能します。また、ファイルを削除すれば、キーはマシンから削除されます。

macOS と Linux では、settings.json は所有者のみ読み取り可能な状態で書き込まれます。Windows では、POSIX のファイルモードがなく、要求も何も通知されずに無視されるため、そうなりません。その代わり、既定で自分だけがアクセスできるユーザープロファイル内に %APPDATA% があることで保護されます。これは実際の保護ですが、このツールが設定するのではなく継承されるものなので、どの保護に依存しているかを把握しておくとよいでしょう。

実行中の測定は、設定ファイルと同じ場所にある jobs フォルダーに状態を保存します。測定ごとに小さなファイルが 1 つ作成され、完了から 1 時間後に削除されます。これにより、クライアントが気付かないうちにサーバーを再起動した場合でも、ポーリングで結果を取得できます。

PAGESPEED_CONFIG_DIR を設定すると、保存場所を自由に変更できます。また、保存済みのキーではなく独自のシークレットマネージャーにキーを保管したい場合は、PAGESPEED_API_KEY でキーを上書きできます。PAGESPEED_INLINE_BUDGET では、1 回のツール呼び出しの中で処理する秒数を指定できます。この時間を超える場合は、代わりにジョブ ID が返されます。既定値は 45 です。

キーをシステムのキーチェーンではなくファイルに保存するのは、意図的なトレードオフであり、率直にお伝えしておくべきことです。キーチェーンにポータブルな方法でアクセスするには、パッケージのインストールが必要です。パッケージのインストールには仮想環境と pip の手順が必要になり、その時点で、最もその利点を必要とする人にとっての「クローンして実行する」という利点がすべて失われます。これと、実際の認証情報の性質を比べて判断してください。ステップ 7 の指示どおりに制限した PageSpeed キーは、公開ウェブページの公開測定結果に対する読み取り専用アクセス権です。個人データは含まず、アカウントのロックを解除することもなく、API は無料なので請求が発生することもありません。盗まれた場合に起こり得る最悪の事態は、1 日あたり 25,000 回分のクォータを使われることです。それを防ぐには、キーを削除すればよいのです。これは煩わしいことではありますが、情報漏えいではありません。

実行しないこと

単一の実行結果を測定値として報告することはありません。そのためのフラグはなく、今後も追加する予定はありません。

ラボデータとフィールドデータを統合して、ひとつの数値にすることはありません。実際のサイトでは両者に桁違いの差があり、平均を取れば、ここにある唯一の誠実さが失われてしまいます。

変化がばらつきの範囲内にある場合、それをリグレッションとは呼びません。ばらつきはご自身で確認できるよう表示されます。その範囲内の変動は、何かが起きた証拠ではありません。

Google Search Console にはアクセスしません。Search Console は OAuth とプロパティごとの認可が必要です。所有するプロパティの非公開データを扱うためです。一方、PageSpeed と Chrome UX Report が扱うのは、誰でも測定できる公開ページの公開データです。これは種類の異なるツールであり、必要な認証情報も異なります。ここに無理に追加すれば、現在はひとつの文字列だけで済むものに、同意フローを持ち込むことになります。

テスト

python3 -m unittest discover -s tests -v

API キーもネットワークも必要ありません。CI では Linux、macOS、Windows 上で Python 3.9 と 3.12 を使ってテストを実行します。

テストのうち2つは、開発中に見つかったバグを再発防止するもので、どちらもエラーではなく、一見もっともらしい数値を返していました。PageSpeed は埋め込みの CLS に100を掛けて報告するため、そのまま受け取ると、健全な 0.08 が 8.0 と表示されます。この2つの数値の違いがすべてを左右する指標で、これは致命的なスコアです。また、Chrome UX Report は CLS を文字列として返しますが、他の指標はすべて数値です。そのため、単純に比較すると TypeError が発生します。どちらの問題も、自ら表面化することはありません。測定ツールでは、正しく見える誤った数値こそが、唯一問題となる種類のバグです。

プライバシーポリシー

これはローカルだけで完結するツールではありません。そうであるかのように書くのは適切ではありません。ページを測定するには Google に測定を依頼するため、確認するアドレスは Google に送信されます。これは情報漏えいではなく、ツールの動作そのものですが、後から小さく記すのではなく、最初に明記しておく価値があります。

このマシンから送信される情報とその送信先

測定する URL は PageSpeed Insights API に送信され、フィールドデータを求めた場合は Chrome UX Report API にも送信されます。API キーをお持ちの場合は、そのリクエストにキーも含まれます。それ以外の情報は送信されません。その後、Google は自社のインフラからそのページを読み込んで測定するため、ページの所有者に表示されるのは、あなたからのアクセスではなく Google からのアクセスです。

これらのリクエストに対する Google の取り扱いは Google のプライバシーポリシーと API 利用規約に従うものであり、Considus が保証できる範囲外です。

送信されない情報

このツールに Considus のサーバーは関与しません。アカウントも、テレメトリも、クラッシュレポートも、利用回数の計測も、ライセンス確認もありません。測定した内容やその日時、ツールを実行したこと自体を、私たちが知ることはありません。こちら側に、それらを知る手段はありません。

書き込まれる情報とその場所

settings.json には API キーと保存した URL が、プラットフォームの設定ディレクトリに保存されます。PAGESPEED_CONFIG_DIR を設定すれば、保存場所を自由に変更できます。

後続の実行で、変化が実際のものかノイズなのかを判定できるよう、ベースラインも同じ場所に保存されます。

HTML レポートは、設定ファイルと同じ場所にある reports フォルダー、または会話内で指定したフォルダーに保存されます。すでに存在するフォルダー以外には書き込まず、既存のファイルを上書きすることもありません。

測定の実行中は、進行状況とその後の結果が、設定ファイルと同じ場所にある jobs フォルダー内の小さなファイルに書き込まれます。ポーリングを行うサーバープロセスと、その対象となる測定を実行するサーバープロセスが、常に同じとは限らないためです。これらのファイルには公開ページの測定結果のみが保存され、ジョブの完了から1時間後に削除されます。

すべてのデータはご自身のディスクに保存され、削除するかどうかもご自身で決められます。settings.json を削除すると、マシンからキーが削除されます。

キーがファイルに保存されることについて

macOS と Linux では、所有者のみが読み取れる権限で書き込まれます。Windows では、POSIX ファイルモードがないため、この指定は無視されます。代わりに、ユーザープロファイル内にある %APPDATA% によって保護されます。これは実際に機能する保護ですが、このツールが設定するものではなく、継承されるものです。そのため保証としては弱く、その点は知っておく価値があります。

キーをキーチェーンではなくファイルに保存しているのは、キーチェーンにポータブルな方法でアクセスするにはパッケージをインストールする必要があり、そのために仮想環境と pip の手順が必要になるからです。それでは、「クローンして実行する」という利点が失われてしまいます。これを、認証情報の性質と照らし合わせて判断してください。セットアップ手順のとおりに制限された PageSpeed キーでアクセスできるのは、公開ページの公開測定データの読み取りだけです。個人データは含まれず、アカウントのロックを解除することもなく、API は無料なので課金にも使われません。キーが盗まれた場合の最大の影響は、キーを削除すればリセットできる割り当てを消費されることです。この判断に納得できない場合は、ご自身のシークレットマネージャーで PAGESPEED_API_KEY を設定すれば、キーは一切保存されません。

データの保持と、共有先について

当方は何も保持しないため、保管するものも、お客様に代わって削除するものもありません。当方には共有できるものが届かないため、誰にも何も共有されません。関係するサードパーティは Google のみで、上記の測定リクエストに限られます。

これらについて問い合わせる場合

[email protected] にメールするか、github.com/Considus/pagespeed-insights-mcp/issues でイシューを作成してください。considus.com 自体に適用されるポリシーは considus.com/privacy にあります。対象が別のものであるため、別の文書になっています。

サポート

これは無料で、今後も無料です。Apache 2.0 により、何かを返す義務を負うことなく、自由に利用、改変し、商用製品として提供できます。これは意図したものです。

不具合や、信頼できない数値があれば、 イシューを作成してください。 悪用につながる問題は、公開イシューではなく、SECURITY.md に記載されているとおり、GitHub の非公開報告窓口または [email protected] からご報告ください。これらのいずれにも該当しないお問い合わせ（報道やライセンスに関するものを含む）は、[email protected] までお寄せください。その他のお問い合わせ方法は considus.com/support に記載されています。

実際には存在しなかったリグレッションの調査を避けるのに役立った場合は、 コーヒーをごちそうしてください。役に立たなかった場合は、どこが間違っていたかを教えていただくほうが、コーヒーより価値があります。もっとも役立つのは、もっともらしく見えた数値が実際には誤っていた場合のバグ報告です。

ライセンス

Apache 2.0 です。LICENSE と NOTICE をご覧ください。

非公式のコミュニティプロジェクトです。Google LLC との提携、承認、後援はありません。Google の公開 API を 2 つ呼び出しますが、Google のコードは含まず、Google のデータも再配布しません。