WebMCP対応のフォームが「合格」に。Lighthouse 13.5で変わった診断の読み方

WebMCPに対応させたフォームなのに、診断結果は「該当なし」。その表示が「合格」に変わる更新が、Lighthouse 13.5に入りました。[1][2]

Lighthouseは、Webサイトの状態を調べるツールです。今回の変更では、AIに操作を伝えるWebMCPのフォーム対応を、診断結果から読み取りやすくなります。

ただし、診断の「合格」は、AIによる購入成功を保証するものではありません。 何が変わり、どこまで確認できるのかを整理します。

WebMCPの何が変わった？9月17日と18日の更新を整理

WebMCPの仕様文書と、Lighthouseの診断更新は、別の出来事です。2026年9月17日付のWebMCP文書と、9月18日公開のLighthouse 13.5を分けて見ます。[1][2]

日付	対象	今回確認した内容
9月17日	WebMCP文書	Draft Community Group Reportとして掲載
9月18日	Lighthouse 13.5	フォーム対応の判定修正と、登録ツール数に関する警告

WebMCPは、サイトが用意した操作をAI向けのツールとして伝える仕組みです。文書は草案であり、W3Cの正式標準になったという発表ではありません。[1]

また、これらは9月26日に確認した直近の変更ですが、過去24〜48時間以内に起きたニュースではありません。リリース日と、記事で取り上げた日を区別します。

WebMCPの全体像を先に知りたい方は、WebMCPの基本をまとめた記事から読むと、今回の診断変更を理解しやすくなります。

フォームのWebMCP対応が、n/aから「合格」になる条件

対象フォームがすべてWebMCP用の注釈に対応している場合、診断結果を従来のn/aからpassにする変更です。n/aは該当なし、passは合格に当たります。[2][3]

ここでいう注釈は、フォームが何をする操作なのかをAIに伝えるための情報です。今回の修正は、対応がそろっている状態を診断結果に表すものと読めます。

一部のフォームが未対応でも、一律に「失敗」にはならない

この変更を説明するPull Requestは、未対応のフォームがある場合に一律でfailへ変えるものではないと説明しています。つまり「すべて対応していればpass」と「一つでも未対応ならfail」は、同じルールではありません。[3]

状態	今回の変更から読み取れること
対象フォームがすべて対応	n/aではなくpassとして表示
一部が未対応	この修正だけを根拠に、一律failとは判断できない

以前のn/aと新しいpassだけを並べて、「実装品質が上がった」と結論づけるのも早計です。サイトを変更していなくても、診断側の版によって表示が変わる可能性があるからです。

比較するときは、サイトの更新日だけでなく、Lighthouseのバージョンも残しておきます。

WebMCPツールを増やしすぎると、警告が出る

Lighthouse 13.5には、登録したWebMCPツールが推奨数を超えた場合の警告も追加されました。フォームの網羅性とは別の診断変更です。[2][4]

これは、WebMCPの仕様そのものが一律の固定上限を決めた、という意味ではありません。診断ツールが示す推奨と、仕様上の制限を分けて読みます。

自社で警告が出たら、まず登録した操作の一覧を見ます。以下は編集部が提案する見直しの観点です。

• 同じ操作が、名前だけ変えて複数登録されていないか。
• そのページで利用できない操作まで登録していないか。
• 名前と説明から、操作の違いを読み取れるか。

例えば、商品検索と在庫確認には別々の目的があります。一方、同じ条件で同じ検索をする操作が重複していれば、整理の候補になります。これは説明用の例で、Lighthouseが実行結果の正しさまで保証するという話ではありません。

自社サイトで確認するのは、診断の版と実際の操作

確認は、使ったLighthouseの版を記録し、診断結果を読み、その後に実際の操作を試す順番で進めます。

13.5の公開時点では、Chrome DevToolsへの搭載はChrome 156、PageSpeed Insightsへの反映は今後の予定として案内されていました。リリース記事を見ただけで、手元のすべての環境が13.5になったとは判断できません。[2]

まず診断レポートのバージョンを確かめます。そのうえで、対象URL、診断日、フォームの結果、登録ツールの警告を記録してください。

診断の合格と、AIの身元確認・購入成功は別

WebMCPのフォーム診断がpassでも、そのAIが誰なのか、注文を誰が承認したのかまでは分かりません。Web Bot Authのような身元検証と、サイト側の操作・承認の設計は、それぞれ別に確認する領域です。[5]

実際の操作を試すときは、例えば「商品を検索できるか」「条件に合う結果が返るか」を、自社で用意したテスト条件で確認します。注文を扱う場合は、テスト環境で数量や金額、承認のタイミングまで見ます。

診断の表示を読むことと、顧客が使う操作を確かめること。この二つの記録をそろえると、WebMCP対応のどこまで確認できたかを説明しやすくなります。