Webサイトを納品する前にチェックする項目はたくさんあります。確認方法としては、Chromeブラウザでページを開いて表示内容やデベロッパーツールから確認している方が多いのではないかと思います。
これらの人間が目視で確認している内容ですが、Chrome DevTools MCPを活用することでAIに代わりに確認してもらうことが可能です。
AIに見てもらうことで、以下のようなメリットがあります。
- 機械的にチェックできるようになる（漏れが起きづらい）
- チェックの基準を組織で統一しやすくなる
- 確認時の結果がレポートという形で残る
AIでできることはAIに任せて、Web制作をどんどん効率化していきましょう！
AIに何をチェックしてもらう？
具体的にAIにチェックしてもらう内容ですが、今回は以下の動きを見ていけたらと思います。
- タイトル、ディスクリプション、OGP、ファビコン、カノニカルの設定
- 見出しの階層構造
- 画像の代替テキスト
- コンソールエラー
- ネットワークの404
なお、AIが見れる情報としては基本的にChromeのデベロッパーツールで確認できる内容すべてです。なので、他にもデベロッパーツールのここをチェックしている、という項目がある方はAIに任せるアイデアが出てきやすいかなと思います。
AIにチェックしてもらうための登場人物
様々な前提知識が必要かもしれませんが、ひとまず登場人物を整理しておきます。難しいと思った方は深く理解せず先に進んでしまっても問題ございません。
なお、Chrome DevTools MCPを使う際の登場人物です。同じくChrome DevTools MCPを使ってパフォーマンス確認している時と同じ内容（「Chrome DevTools MCPを設定しよう」まで）になりますのであらかじめご了承ください…。
登場人物としては、以下の通りです。
- AI搭載エディタ（VS Code、Cursorなど）
- AIエージェント
- Chrome DevTools MCP
- Chromeブラウザ
AI搭載エディタ
AI搭載エディタは、チャットでAIエージェントを動かす仕組みを備えたエディタを指します。VS CodeやCursorがよく使われるエディタになります。
無料で開始はできますが、十分に使うためには基本的には有料という前提で捉えてもらえると良いかと思います。
VS Codeについてはもう少しだけ補足すると、VS CodeにGitHub Copilotの拡張機能を導入することで、AI搭載型に変わります。料金を支払うのはVS Codeに対してではなくGitHub Copilotに対してです。
- GitHub Copilot 料金：https://github.com/features/copilot/plans?locale=ja
- Cursor 料金：https://cursor.com/ja/pricing
AIエージェント
AIエージェントは、タスクを遂行してくれるAIのようなイメージを持ってもらえたらと思います。ほぼ先ほどのエディタの紹介とイコールではあるのですが、登場人物として「エディタ」と「AI」ということで分類したような形です。
AIにはモデルがありまして、ちょっとずつ得意なこと苦手なことが違ってきます。その時々によってトレンドは変わってくるのですが、コーディングに強いとされているのは「Claude」です。
Chrome DevTools MCP
Chrome DevTools MCPは、AIに対して「Chromeのデベロッパーツール見たりブラウザを操作してもいいですよ！」という権限を与えられるツールのようなイメージです。
MCPはここだけで使われている用語ではなく、Model Context Protocolの略でAIとツールを繋ぐための統一的な仕組みになります。Anthropic社が提唱しました。
Googleカレンダーに繋いで自分の予定をAIに管理してもらったり、Slackに繋いで代わりに投稿してもらったり、Figmaに繋いでデザインデータからコーディングしてもらったり、とChromeに限らず様々なツールと繋ぐことが可能です。
少し横にそれましたが、Chrome DevTools MCPは、MCPの仕組みを使ってChrome DevToolsと繋ぐための仕組みです。
AIがChromeを見て行動することが可能になります。
Chromeブラウザ
AIがChromeの情報を見にいきますので、パソコンにChromeブラウザが入っていることが前提となります。
Chrome DevTools MCPを設定しよう
今回はGitHub Copilotが入っているVS Codeに設定する方法を確認していきましょう。
上部のメニューの「表示」から「コマンド パレット」を開きます。
「MCP: ユーザー構成を開く」を入力して開きます。
mcp.jsonが開かれるはずです。ここにchrome-devtoolsを設定しましょう。
{
"inputs": [],
"servers": {
"chrome-devtools": {
"command": "npx",
"args": ["chrome-devtools-mcp@latest"]
}
}
}設定できたら、以下を入力して動作を確認してみましょう。「表示」から「チャット」を開きます。
チャットに以下を入力して実行しましょう。
Please check the LCP of web.dev.
すると、AIが処理を開始してくれます。ブラウザが立ち上がり「https://web.dev/」が開いてLCPを確認してくれるはずです。
許可が求められたら実行しても問題ないタスクかを確認して許可していきます。以下の場合は「https://web.dev/」を開いていいですか？と聞かれている様子です。
結果を返してくれました！LCPの値や内訳、評価なども教えてくれていることが分かります。
この結果でも十分そうですが、もっと次に繋がるように詳細を返してもらうように依頼の仕方を変えていきましょう。
AIに品質チェックしてもらおう！
チェック対象のURLをAIに渡してチェックしてもらう流れになります。依頼の内容はAIと一緒に考えました。依頼内容によってAIの返答の内容が変わってきますので、欲しい情報に合わせて調整してもらえたらと思います。
事前準備
ファイルを生成して欲しいので、プロジェクトを用意しておきます。空のフォルダを作ってドラッグ&ドロップでVS Codeにプロジェクトフォルダとして開いておきます。
「performance-test」というフォルダを作りました。
これをVS Codeにドラッグ&ドロップで開きます。中身は空ですがエクスプローラーに認識されました。
タイトル、ディスクリプション、OGP、ファビコン、カノニカルの確認
まずは、タイトル、ディスクリプション、OGP、ファビコン、カノニカルを確認してもらいます。確認してもらった後に評価と改善案までセットでお願いしています。
chrome-devtoolsのMCPを通じて取得できる情報（Elements、Network など）を使って、
以下の構成の「HTML metaレポート」を Markdown で出力してください。
# 前提
- 対象読者は HTML/CSS/JS を扱える Web コーダーです。
- 専門用語は使ってよいですが、簡単な補足説明も書いてください。
- すべて日本語で出力してください。
- 実際に Elements / Network から確認できた情報のみを使い、推測や想像で値を作らないでください。
- 値が取得できなかった場合は「なし」または「不明」と明記してください。
# 調査対象URL
{ここに URL を入れる}
# レポート構成
0. ファイル名
- 調査対象URLをもとに、以下のルールでレポートのファイル名を決めて、最初に記載してください。
- ドメイン名とパスの「.（ドット）」と「/（スラッシュ）」を「_（アンダーバー）」に変える
- 接頭辞に「meta_」をつける
- 拡張子は `.md`
- 例：https://www.example.com/about.html → `meta_www_example_com_about_html.md`
出力例：
- ファイル名：`meta_www_example_com_about_html.md`
1. タイトル、ディスクリプション
HTMLの `<head>` 内から、以下を取得して報告してください。
- タイトル：
- 実際の `<title>` の文言
- 文字数（全角・半角混在でそのままの文字数）
- ディスクリプション：
- `<meta name="description">` の content の文言
- 文字数
補足として、以下もコメントしてください。
- タイトルの内容はページ内容と整合しているか（主観でOK）
- ディスクリプションはページ内容を要約できているか
2. カノニカル
- `<link rel="canonical">` を取得し、以下の情報を出してください。
- カノニカルURL（相対パスの場合は、実際のページURLを基準にした絶対URLも併記）
- 同じページ内に複数のカノニカルタグが存在する場合は、その数と全URLを列挙
書式例：
- カノニカルURL：`https://www.example.com/about.html`
- 備考：カノニカルタグは1つのみ／2つ以上存在 など
3. OGP
`<meta property="og:*">` を中心に、以下を取得してください。
- og:title：
- og:description：
- og:site_name：
- og:type：
- og:image：
- content に指定された URL
- Network 情報から確認できる HTTP ステータス（例：200 / 404 / 301 など）
- リダイレクトが発生している場合は最終的な URL も併記
`og:*` が存在しない場合は、その旨を明記してください（例：「OGPタグは設定されていません」）。
4. favicon
- `<link rel="icon">`, `<link rel="shortcut icon">` などを調査し、利用されている favicon の URL を列挙してください。
- それぞれについて、Network のレスポンスから以下を記載してください。
- リクエストURL
- HTTPステータス（200 / 404 など）
- Content-Type（例：image/png, image/x-icon など）
書式例（テーブルで）：
| 種類 | URL | ステータス | Content-Type |
|------------------|--------------------------------|-----------|---------------|
| rel="icon" | https://www.example.com/... | 200 | image/png |
| rel="shortcut icon" | ... | 404 | image/x-icon |
5. 評価
以下の観点で、項目ごとに評価を行ってください。
- タイトル、ディスクリプションは適切か
- カノニカルは妥当か
- OGPは適切に設定されているか
- OGP画像はHTTPステータス200で取得できているか
- faviconはHTTPステータス200で取得できているか
評価は、次のような Markdown テーブルでまとめてください。
| 項目 | 評価（OK / 要改善） | コメント（理由・背景） |
|------------------------------------|----------------------|----------------------------------------------------------|
| タイトル・ディスクリプション | | |
| カノニカル | | |
| OGP 設定 | | |
| OGP画像の取得ステータス | | |
| favicon の取得ステータス | | |
6. 改善案
5. の評価を踏まえ、具体的な改善案を箇条書きで提案してください。
- 各改善案には「優先度（高 / 中 / 低）」を付けてください。
- できるだけ、実務でそのまま対応内容に落とし込めるレベルで書いてください（例：○○タグを追加、△△の文言をこう変更 など）。
- Webコーダーがすぐに手を動かせるよう、可能であれば簡単なコード断片（`<link ...>` の例など）も記載してください。
書式例：
- 【優先度：高】タイトルの内容改善
- 現状：〜〜〜
- 課題：〜〜〜
- 提案：〜〜〜 のように変更し、ページ内容とキーワードを明確にする。
- 【優先度：中】OGP画像のサイズ・パスの見直し
- 現状：〜〜〜
- 課題：〜〜〜
- 提案：〜〜〜
---
# 出力形式
- 出力形式は Markdown とし、テーブルは Markdown のテーブル構文を使用してください。
- セクション構成は上記 0〜6 の順番で出力してください。調査対象URLに、ご自身が確認して欲しいURLを入れます。自分は「https://haniwaman.com/」で依頼してみようと思います。
ファイルを編集して欲しいのでモードはAgentにしておきましょう。
少し待つと、レポートをmdファイルで作成してもらえます。
評価と改善案を出してくれました。そういえば、OGP画像の設定をしていなかった…😅
このように、人間がブラウザを見ながらポチポチ確認していたメタタグに関する確認ですが、AIに依頼すれば確認だけでなく分かりやすい形のレポートと改善案を一緒に返してくれるようになります。
見出しの階層構造の確認
次は見出しの階層構造を見ていきましょう！個人的には漏れがちなチェック内容だと思います。調査対象URLの{ここに URL を入れる}を変更してください。
chrome-devtoolsのMCPを通じて取得できる情報（Elements）を使って、
以下の構成のレポートを Markdown で出力してください。
# 前提
- 対象読者は HTML/CSS/JS を扱える Web コーダーです。
- 専門用語は使ってよいですが、簡単な補足説明も書いてください。
- すべて日本語で出力してください。
- MCP から取得できた情報のみを使い、推測で見出しを補完しないでください。
- タグが存在しない場合は「なし」と明記してください。
# 調査対象URL
{ここに URL を入れる}
# レポート構成
0. ファイル名
- 調査対象URLをもとに、以下のルールでファイル名を決めて最初に記載してください。
- ドメイン名とパスの「.（ドット）」と「/（スラッシュ）」を「_（アンダーバー）」に変える
- 先頭に「heading_」をつける
- 例：https://www.example.com/about.html → `heading_www_example_com_about_html.md`
出力例：
- ファイル名：`heading_www_example_com_about_html.md`
1. 見出し構造
HTML の DOM から取得した `<h1>〜<h6>` を、**DOM の順序のまま階層構造として整形して表示してください。**
階層は以下のフォーマットで表現してください（インデントで階層を示す）：
- h1 ~~~~~
- h2 ~~~~~
- h3 ~~~~~
- h3 ~~~~~
- h3 ~~~~~
- h2 ~~~~~
- h2 ~~~~~
- h3 ~~~~~
- h4 ~~~~~
- h5 ~~~~~
- h5 ~~~~~
- h4 ~~~~~
- h3 ~~~~~
- h2 ~~~~~
補足事項：
- 見出しタグ内のテキストは、通常のテキストノードと画像のalt属性を合わせて取得してください。
- インデントはスペース2つ（または4つ）で統一。
- 実際に取得できた順番・階層をそのまま再現してください。
- もし階層が不自然（例：h2 → h4 → h3）でも、そのまま出力してください（評価で触れるため）。
2. 評価
以下の観点で、見出し構造を評価してください。
- 見出し階層は論理的に適切か
（例：h1 は1つか、h2〜h6 のレベルは飛んでいないか）
- DOM の順序とセマンティクスが一致しているか
（例：見た目は大見出しなのに h3 が使われている など）
- コーディングのミスが疑われる箇所はあるか
評価は Markdown のテーブル形式でまとめてください：
| 評価項目 | 評価（OK / 要改善） | コメント（理由・背景） |
|----------|----------------------|--------------------------|
| h1 の数 | | |
| 階層の一貫性 | | |
| h2→h3→h4 の順序性 | | |
| 不自然なレベル飛び | | |
3. 改善案
評価に基づき、具体的な改善案を記載してください。
- 単なる抽象的なコメントではなく、**実際のタグ修正例**を含めてください。
- 優先度（高 / 中 / 低）をつけてください。
- コーダーがすぐ手を動かせる粒度で記載してください。
出力形式は Markdown とし、表は Markdown のテーブルで作成してください。調査対象URLに、ご自身が確認して欲しいURLを入れます。自分は「https://haniwaman.com/」で依頼してみようと思います。
ファイルを編集して欲しいのでモードはAgentにしておきましょう。
結果を返してくれました！
評価と改善案です。見出し構造は特に問題なさそうですね。
画像の代替テキスト（alt） 確認
もっと良い依頼の仕方はありそうな気がします…。調査対象URLの{ここに URL を入れる}を変更してください。
chrome-devtoolsのMCPを通じて取得できる情報（Elements）を使って、
以下の構成のレポートを Markdown で出力してください。
# 前提
- 対象読者は HTML/CSS/JS を扱える Web コーダーです。
- 専門用語は使ってよいですが、簡単な補足説明も書いてください。
- すべて日本語で出力してください。
- MCP から取得できた Elements（DOM）情報のみを使用し、推測で alt を補完したり、架空の値を生成したりしないでください。
- alt が存在しない場合は「なし」と記載してください。
- src 属性が相対パスの場合は、実際の DOM から取得した値をそのまま使い、補完しないでください。
# 調査対象URL
{ここに URL を入れる}
# レポート構成
0. ファイル名
調査対象URLをもとに、以下のルールでファイル名を決めて最初に記載してください。
- ドメイン名とパスの「.（ドット）」と「/（スラッシュ）」を「_（アンダーバー）」に変える
- 先頭に「alt_」をつける
- 例：https://www.example.com/about.html → `alt_www_example_com_about_html.md`
出力例：
- ファイル名：`alt_www_example_com_about_html.md`
1. altの一覧
HTML の DOM から取得した `<img>` タグの情報を次の形式で表として一覧化してください。
- **画像の src**
- **alt 属性の値（空欄の場合は「なし」）**
Markdown のテーブル形式で出力してください。
例：
| 画像パス | alt |
|----------|------|
| /img/hero.jpg | メインビジュアル |
| /img/icon.png | なし |
| https://example.com/banner.jpg | キャンペーンバナー |
2. 評価
取得した alt 情報をもとに、以下の観点から評価してください。
- **空欄（alt="") が問題ないケースか？**
（例：装飾目的の画像なら空欄は正しい）
- **画像の内容を正しく説明できているか？**
（例：意味がある画像なのに「image」「写真1」など曖昧すぎないか）
- **冗長な代替テキストになっていないか？**
（例：「画像：〜〜〜」など不要な前置き）
- **SEO / アクセシビリティ上の問題がないか**
Markdown テーブルでまとめてください。
項目例：
| 画像パス | 評価（OK / 要改善） | コメント |
|----------|---------------------|-----------|
3. 改善案
評価に基づき、具体的な改善案を記載してください。
- 単なる抽象的なコメントではなく、**実際のタグ修正例**を含めてください。
- 優先度（高 / 中 / 低）をつけてください。
- コーダーがすぐ手を動かせる粒度で記載してください。
出力形式は Markdown とし、表は Markdown のテーブルで作成してください。依頼してみましょう。
レポートを作成してくれました。サムネイル画像にaltの設定がありません。
評価や改善案も基本的には「サムネイル画像にaltをつけてください」という内容です。WordPressの場合はメディアのアイキャッチ画像として設定してる代替テキストに入力することで反映されるようになります。
コンソールエラー確認
Chromeデベロッパーツールのコンソールのエラー確認です。調査対象URLの{ここに URL を入れる}を変更してください。
chrome-devtoolsのMCPを通じて取得できる情報（Console）を使って、
以下の構成のレポートを Markdown で出力してください。
# 前提
- 対象読者は HTML/CSS/JS を扱える Web コーダーです。
- 専門用語は使ってよいですが、簡単な補足説明も書いてください。
- すべて日本語で出力してください。
- MCP から取得できた Console 情報のみを使用し、推測でログ内容を補完しないでください。
- エラーが存在しない場合は「なし」と記載してください。
# 調査対象URL
{ここに URL を入れる}
# レポート構成
0. ファイル名
調査対象URLをもとに、以下のルールでファイル名を決めて最初に記載してください。
- ドメイン名とパスの「.（ドット）」と「/（スラッシュ）」を「_（アンダーバー）」に変える
- 先頭に「console_」をつける
- 拡張子は `.md`
例：
https://www.example.com/about.html
→ `console_www_example_com_about_html.md`
1. コンソールエラー一覧
MCP Console API から取得できるログを、そのまま以下の情報セットで表形式にしてください。
- **レベル**（error / warn / info）
- **メッセージ本文**
- **発生件数（同一メッセージは統合）**
- **発生元ファイル（可能な場合）**
- **行・列番号（可能な場合）**
- **スタックトレース（取得できれば）**
表形式（Markdown）で出力してください。
例：
| レベル | メッセージ | 件数 | 発生元 | 行数 | 備考 |
|--------|------------|------|--------|-------|------|
| error | Failed to load resource: the server responded with a status of 404 | 3 | /assets/app.js | 120 | なし |
| warn | Deprecation warning: ... | 1 | /assets/vendor.js | 52 | 今後非推奨 |
※ 値が取得できなかった項目は「なし」としてください。
2. 評価
それぞれのログがページに与える影響度を、以下の基準で評価してください。
- **高**：表示崩れ / JS 実行停止 / 重要機能の不具合
- **中**：UX 低下 / 実行順の問題 / ライブラリ読み込み失敗など
- **低**：軽微な警告 / 非推奨 API などで動作には影響しない
Markdown テーブルでまとめてください：
| メッセージ | 影響度（高/中/低） | コメント（理由） |
|------------|----------------------|-------------------|
3. 改善案
評価に基づき、各エラーに対して具体的な改善案を出してください。
- 単なる抽象的な説明ではなく、**実際のタグ修正例（script, link など）**を含めること
- 修正の優先度（高 / 中 / 低）をつけること
- コーダーがそのまま対応できる粒度にすること
出力形式は Markdown とし、表は Markdown のテーブルで作成してください。依頼してみましょう。
レポートを作成してくれました。エラーはなさそうです！
ネットワークの404確認
Chromeデベロッパーツールのネットワークの404を確認します。調査対象URLの{ここに URL を入れる}を変更してください。
chrome-devtoolsのMCPを通じて取得できる情報（Network）を使って、
以下の構成のレポートを Markdown で出力してください。
# 前提
- 対象読者は HTML/CSS/JS を扱える Web コーダーです。
- 専門用語は使ってよいですが、簡単な補足説明も書いてください。
- すべて日本語で出力してください。
- MCP から取得できた情報のみを使い、推測で見出しを補完しないでください。
- タグが存在しない場合は「なし」と明記してください。
# 調査対象URL
{ここに URL を入れる}
# レポート構成
0. ファイル名
- 調査対象URLをもとに、以下のルールでファイル名を決めて最初に記載してください。
- ドメイン名とパスの「.（ドット）」と「/（スラッシュ）」を「_（アンダーバー）」に変える
- 先頭に「404_」をつける
- 例：https://www.example.com/about.html → `404_www_example_com_about_html.md`
出力例：
- ファイル名：`404_www_example_com_about_html.md`
1. 404の一覧
**ステータスコードが 404 のものだけ**を抽出し、
以下の情報を Markdown のテーブル形式で一覧化してください。
- **URL（実際に Network で取得されたもの）**
- **種類（推測ではなく、以下の手順で分類）**
1. 拡張子から判定（.js, .css, .png, .jpg, .svg, .woff, .json など）
2. 拡張子がない場合は、Network の `resourceType` を使用
3. どちらも取得できない場合は「不明」と記載
表形式：
| URL | 種類 | 備考 |
|-----|------|-------|
404 が 1 件もない場合：
- 「なし」と明記。
2. 評価
各 404 リソースがページや機能に与える影響度を評価してください。
- **高**：JavaScript / CSS の読み込み失敗、主要画像の404、フォーム・APIが404
- **中**：補助的画像、軽微な機能の動作に関連するスクリプトが404
- **低**：トラッキングタグ、未使用リソース、favicon などで致命度が低いもの
Markdown テーブルで以下の形式でまとめてください：
| URL | 種類 | 影響度（高/中/低） | コメント |
|------|-------|----------------------|------------|
3. 改善案
評価に基づき、404 を解消するための具体的な改善案を記載してください。
- 抽象的な説明ではなく、**実際のタグ修正例（script, link, img など）**を含めてください
- 修正の優先度（高 / 中 / 低）を必ず付けてください
- コーダーがそのまま対応できる粒度で記述してください
出力形式は Markdown とし、表は Markdown のテーブルで作成してください。依頼してみましょう。
レポートを作成してくれました。こちらもエラーはなさそうです！
おわりに
Chrome DevTools MCPを活用することで、Chromeで確認していたあらゆる作業をAIに依頼することが可能になります。
もしかしたら確認時間的にはAIが見ても人間が見ても変わりない可能性はありますが、機械的になることで以下のようなメリットがあります。
- 機械的にチェックできるようになる（漏れが起きづらい）
- チェックの基準を組織で統一しやすくなる
- 確認時の結果がレポートという形で残る
個人的にはWeb制作フローに機械的に組み込めるという所がメリットとして大きいのかなと思います。Web制作を効率化する1つの手法として、ぜひ試してみてください！
