AIによるWebサイト監査：根拠の収集から検証済みの修正まで、AIエージェントで進める方法

1. AIによるWebサイト監査とは

Webサイト監査は、サイトがどのように作られ、配信され、つながっているかを確認する作業です。保護されているか、検索エンジンやAIシステムが読み取れるか、人が使えるか、どれだけ速いか、どのサードパーティサービスを読み込んでいるかを調べます。AIによるWebサイト監査では、この作業にAIエージェントが加わります。エージェントはチェックを開始し、結果を読み、平易な言葉で説明し、何から直すかをあなたと決め、修正を担当する人やコーディングエージェントへの変更依頼を書きます。

同じ言葉で、かなり異なる三つのものが語られています。

このガイドが扱うのは三つ目の方式です。AIが実際に時間を節約でき、しかもすべての指摘が確認可能な根拠に結び付くからです。チェックは再現可能なまま、エージェントが判断、文脈、そして変更を出荷する人やツールへの引き継ぎを加えます。MCPが初めての方は、MCPガイドでホスト、クライアント、サーバー、ツールをやさしく説明しています。

2. AIエージェント単独でできることとできないこと

言語モデルは、読む、要約する、書くことが非常に得意です。しかしネットワークツールではありません。アプリケーションがその用途のツールを与えない限り、表示されるページの下で、ブラウザやクローラーが見ているものを見ることはできません。次の表は、せいぜいWeb閲覧ツールを持つ程度で単独で動くエージェントと、構造化されたチェックを使って動く同じエージェントを比べています。

Claude Code、Codex、Cursorのようにターミナルを持つコーディングエージェントなら、curl、dig、opensslを自分で実行することもできます。一つの指摘を確認するには役立ちますが、エージェントは場当たり的にコマンドを選びます。網羅範囲は思い付いたものに左右され、実行ごとに結果が変わり、プローブを確認済みのドメインだけに限定する仕組みもありません。

中央の列のリスクには名前があります。LLMアプリケーションのリスクに関するOWASPの一覧は、誤情報を、もっともらしく見える誤った、または誤解を招く出力と説明しています。主な原因の一つがハルシネーションで、検証せずに信頼されるとさらに悪化します。監査では、モデルが一度もレコードを読んでいないドメインについて「DMARCポリシーがnoneに設定されています」と言ったり、サーバーが実際には送っているヘッダーを「ない」と報告したりする形で現れます。

二つ目のリスクはページ自体から来ます。Webサイトを読むエージェントは、信頼できないテキストを読んでいます。ページにはモデルに向けた指示が含まれていることがあり、人間の訪問者には見えないよう隠されている場合もあります。OWASPはこれを間接プロンプトインジェクションと呼びます。慎重な監査環境では、ページの内容を指示ではなく報告対象のデータとして扱い、エージェントの行動は必ず人が承認するようにします。

エージェントが得意なのは、根拠を取り巻くすべてです。指摘がこのサイトにとって何を意味するかの説明、関連する指摘のグループ化、チェックでは分からない文脈（その古いステージング用サブドメインはまだ使われているか）の確認、そしてコーディングエージェントが動ける精度の修正依頼の作成です。この分業こそ、優れたAIによるWebサイト監査の核心です。

3. 対象となる6分野と、それぞれのチェックリスト

徹底したWebサイト監査は、六つの層を見ます。それぞれ異なる問いに答え、異なる種類の根拠を生みます。Webサイト監査ガイドは、一つの顧客の利用の流れに沿って六つすべてをたどります。ここでは実務用のチェックリストを示します。

セキュリティ

• HTTPSとTLS：信頼できる証明書チェーン、数週間以内に期限が切れないこと、TLS 1.2または1.3、HTTPからHTTPSへのリダイレクト。
• セキュリティヘッダー：HTMLレスポンスでのStrict-Transport-Security、Content-Security-Policy、X-Content-Type-Options、フレーム埋め込み対策、Referrer-Policy。
• CORS：非公開データを含むレスポンスにAccess-Control-Allow-Origin: *がないこと、資格情報と組み合わされたオリジンの反映がないこと。
• DNSとメール用DNS：メールを送信するすべてのドメインに有効なSPFとDMARCのレコードがあり、メールを送らないドメインには制限的なレコード（v=spf1 -all、p=reject）があること。
• 公開されたファイルとシークレット：/.env、/.git/、古いバックアップなどのパスに到達できず、フロントエンドのJavaScriptにAPIキーがないこと。
• サブドメイン：削除されたクラウドリソースを指し、第三者に取得されかねないDNSレコード（サブドメインテイクオーバー）がないこと。
• 攻撃対象領域：意図したオープンポートとHTTPメソッドだけがあり、把握しているサインインページや管理ページだけが存在し、WordPressを運用している場合はCMSとプラグインが最新であること。
• サプライチェーン：サードパーティのスクリプトが、自分で選んだ配信元からのみ読み込まれていること。

これらのチェックには、公開情報を読むだけのものもあります。機密パスへのリクエストやポートスキャンのように、所有者の同意が必要なリクエストを送るものもあるため、監査ツールは所有を確認済みの対象にだけ実行するべきです。アカウント、権限、サインインといったアプリケーション側については、Webセキュリティ監査ガイドで扱っています。

テクニカルSEO

• クロール可能性：robots.txtが、インデックスさせたいページやリソースをブロックしていないこと。
• インデックス：重要なページに不要なnoindexがなく、サイトマップにcanonical URLが載っていること。
• タイトルとメタディスクリプション：存在し、重複せず、ページを説明していること。
• 見出し：明確なメイン見出しが一つあり、構成が論理的であること。
• canonical：各ページが優先URLを指し、リダイレクトやエラーページを指していないこと。
• 構造化データ：表示内容と一致する有効なJSON-LD。
• 内部リンクとリダイレクト：重要なページにナビゲーションやコンテンツから到達でき、複数回のリダイレクトの連鎖がないこと。
• Search Consoleのデータ：表示回数は多いのにクリック率が低いページや、上位のすぐ下に位置するクエリ。多くの場合、最も早く成果が出ます。

ここで重要な制約が一つあります。Googleはページをインデックスする前にJavaScriptをレンダリングしますが、JavaScript SEOの基本では、JavaScriptを実行できないボットがあることもあり、サーバーサイドレンダリングやプリレンダリングを引き続き推奨しています。静的HTMLを読む監査は、そうしたボットと同じようにページを見ます。コンテンツをブラウザで生成するサイトでは、指摘内容をレンダリング後のページと比べてください。詳しくはテクニカルSEO監査ガイドをご覧ください。

AI可視性の準備状況

• AIクローラーの方針：各AIクローラーに対するrobots.txtのルールが、誰も選んでいないプラグインの初期設定ではなく、自分で決めた内容と一致していること。複数の提供元が検索用とトレーニング用のクローラーに別のトークンを定めており、たとえばGoogleは検索クローラーとは別にGoogle-Extendedを説明しています。
• llms.txt：任意です。最も役立つページを載せた短いMarkdownの索引で、主にドキュメントの多いサイトで追加する価値があります。何をして何をしないかはllms.txtガイドで説明しています。
• エンティティの明確さ：事業名、説明、所在地、連絡先がどこでも同じで、Organizationの構造化データで裏付けられていること。
• 回答しやすさ：顧客の実際の質問に、画像ではなくテキストで、上部近くで直接答えているページ。
• プロンプトの網羅：購入者がアシスタントに尋ねる質問の一覧と、それぞれに答える自サイトのページ。
• 情報源のシグナル：署名のある著者や組織、日付、引用など、ページを引用し帰属を示しやすくする要素。

これらは自分のコンテンツに対する準備状況のチェックです。現在どのアシスタントがあなたを引用しているかは分かりません。それには質問と回答を記録する別のログが必要です。Googleは、そのAI機能には通常の検索の適格性以外の追加要件はないとしており、まずクロールのアクセスと明確なコンテンツが先です。質問セットの作り方はAI可視性監査ガイドで紹介しています。

アクセシビリティ

• 代替テキスト：情報を伝えるすべての画像に意味のあるalt属性があり、装飾画像のaltは空であること。
• フォーム：すべての入力項目にプレースホルダーだけでなく、プログラムから参照できるラベルがあること。
• 構造：見出しが順序どおりで、mainやnavなどのランドマークとスキップリンクがあること。
• 名前：すべてのボタンとリンクにアクセシブルな名前があり、空のリンクがないこと。
• 言語：ページがlang属性で言語を宣言していること。
• 手動の確認：キーボードのみでの操作、見えるフォーカス、色のコントラスト、ズームとリフロー、スクリーンリーダーでの確認。

W3Cは、ツールではアクセシビリティのすべての側面を自動で確認できず、人間の判断が必要だと明言しています。自動チェックはラベルの欠落を見つけますが、そのラベルが理にかなっているかを判断できるのは人だけです。WCAG 2.2に沿った手動確認は、アクセシビリティ監査ガイドで説明しています。

パフォーマンス

• Core Web Vitals：ページ読み込みの75パーセンタイルで、Largest Contentful Paintが2.5秒以内、Interaction to Next Paintが200ミリ秒以内、Cumulative Layout Shiftが0.1以下（web.dev）。
• まずフィールドデータ：Chrome UXレポートのデータは、ページやサイトに十分なトラフィックがあって対象に含まれる場合、過去28日間に実際のChromeユーザーが体験した内容を示します。Lighthouseのラボ結果は原因の特定に役立ちます。
• モバイルを優先：ホームページ、商品やサービスのページ、チェックアウトや問い合わせフォームなど、重要なページのモバイル版をテストします。
• よくある原因：大きすぎるヒーロー画像、レンダリングをブロックするスクリプトとフォント、寸法のない画像や遅れて出るバナーによるレイアウトシフト、重いサードパーティタグ。

PageSpeed Insightsのドキュメントは、ラボデータとフィールドデータは異なることがあると述べており、ラボのスコアが良くても実際の訪問者の体験が良いとは限りません。遅い指標をその原因となる要素に結び付ける方法は、Webサイトパフォーマンス監査ガイドで紹介しています。

連携

• 一覧化：ページ上のすべての分析ツール、タグマネージャー、広告ピクセル、同意ツール、サイト所有権確認タグと、それぞれの担当者。
• 重複と残骸：同じ分析タグの二重設置や、昨年終了したキャンペーンのピクセル。
• 同意：必要な場合は同意ツールがあり、タグがその同意を待つこと。
• 個人データ：タグが読むデータレイヤー、URL、ページタイトルにメールアドレス、電話番号、氏名が含まれないこと。たとえばGoogleアナリティクスのヘルプは、サイト所有者に、URL、タイトル、イベントに個人を特定できる情報を含めないよう求めています。

静的チェックで分かるのは、マークアップが宣言している内容です。タグが本当に同意を待つのか、クリック後にどのイベントが発火するのかは、開発者ツールを開いたブラウザセッションで確認する必要があります。その追跡手順はWebサイト連携監査ガイドで解説しています。

4. AIでWebサイトを監査する手順

Model Context Protocol（MCP）は、AIアプリケーションが他のサービスのツールを呼び出すための共通の方法です。監査サービスを接続すれば、チャットやコーディングツール内のエージェントが、チェックを実行して結果を直接扱えます。ワークフローは9ステップで、最初の二つはサイトごとに一度だけ行い、残りは監査のたびに繰り返します。

1. 接続する。AIクライアントで監査サービスをMCP接続として追加し、ブラウザでサインインします。アカウントが必要なリモートMCPサーバーは通常、MCP認可仕様に記されたOAuthを使うため、サインイン画面でアクセスを承認し、パスワードやAPIキーをチャットに貼り付けることはありません。SitelemetryはChatGPT、Claude、Claude Code、Codex、Cursorでこの方法で接続できます。各クライアントの手順はMCP接続ガイドにあります。
2. 範囲と認可を決める。対象にするサイトとページを決め、自分が所有するか、テストの書面許可を得たサイトだけを監査します。パッシブなチェックは訪問者なら誰でも見られる内容を読みますが、アクティブなセキュリティチェックはプローブのリクエストを送るため、ドメインの管理権限を確認してから実行します。範囲はエージェントに平易な言葉で伝えます。本番環境のみ、この3つのURLだけ、フォーム送信はしない、といった具合です。
3. 監査を実行する。全体監査、または一つの分野を依頼します。「https://www.example.comの全体監査を実行し、指摘を重大度順に一覧にして」といった形です。長い監査はバックグラウンドジョブとして動くことがあります。二つ目のスキャンを始めず、エージェントに結果を待たせましょう。
4. 根拠を読む。各指摘には、重大度、観測された根拠、影響、対処方法が付いているべきです。重大度が高いものはエージェントに根拠を引用させ、一つか二つはcurl -sIやdigで自分でも再現します。再現できる指摘なら、自信を持って修正できます。
5. 優先順位を付ける。重大度、次に露出度（ページは公開か、サインインや決済を扱うか）、最後に工数の順に並べます。同じサーバー設定で設定できる複数のヘッダーのように、一つの修正で済む指摘をまとめ、このサイトにとって重要な指摘とリスクの低い指摘をエージェントに尋ねます。
6. エージェント向けの修正プロンプトをコーディングエージェントに渡す。選んだ指摘を、根拠、制約、受け入れ基準、再テスト手順を含む一つの正確な変更依頼にします（例は後述）。リポジトリで作業するコーディングエージェントに渡すか、同じクライアントがリポジトリにアクセスできるなら両方を任せます。
7. 通常のプロセスで出荷する。差分をレビューし、ステージングでテストし、他の変更と同様にデプロイします。監査はコードレビューの代わりにはならず、コーディングエージェントが人の承認なしにデプロイしてはいけません。
8. 再監査して検証する。デプロイ後に、同じ対象で同じチェックを実行します。指摘が解決したといえるのは、新しい結果にもう現れないときであり、エージェントがファイルを編集したと言ったときではありません。
9. 監視する。監査を定期実行にして、プラグインの更新、新しいタグ、期限切れが近い証明書を、訪問者が気付く前に捉えます。小規模サイトの多くには週次が合い、毎日デプロイするサイトには日次の実行が有効です。

MCP仕様は、ツール呼び出しを拒否できる人間の介在を推奨しています。またOWASPは、エージェントがタスクに必要な以上の機能、権限、自律性を持つと有害な行動につながるリスクを、過剰なエージェンシーとして独立したリスクに挙げています。実務では、監査ツールには読み取りを任せ、コードの変更とデプロイは人が承認するようにします。

コーディングエージェントが推測せずに動ける修正プロンプトは、次のような形です（説明用の例）。

Fix: Strict-Transport-Security header missing
Target: https://www.example.com (all HTTPS responses)
Evidence: GET / over HTTPS returned 200 without a
Strict-Transport-Security header.
Constraints:
- Change only the header configuration of the web server or CDN.
- Use max-age=300 for now (first rollout stage); no preload.
- Do not change redirects, cookies or other headers.
Acceptance criteria:
- curl -sI https://www.example.com/ shows a
  Strict-Transport-Security header with max-age=300.
- The header is present on HTML, CSS and JavaScript responses.
Retest:
- Re-run the security audit for www.example.com and confirm
  the finding no longer appears.

各部分には役割があります。根拠は観測された内容をコーディングエージェントに伝え、問題を再発見する手間を省きます。制約は変更を小さく保ちます。HSTSを短いmax-ageで始め、段階的に引き上げるのは、HSTSガイドが説明する慎重な進め方です。受け入れ基準は誰でも実行できるコマンドで、再テストの手順は問題を見つけたのと同じチェックで流れを締めくくります。

5. AIによるWebサイト監査ツールの評価方法

Webサイト監査に最適なAIツールを探すと、長い一覧が見つかります。最適な選択はサイトによって異なりますが、役立つAI監査ツールと、スキャナーを付けただけのチャットボットを分ける問いは、どの製品でも同じです。

そのうえで、頼る前に、候補のツールを自分のサイトで試します。

• 二度実行する。変更していない同じページで実行し、指摘と重大度が一致するはずです。
• 三つの指摘を手作業で確認する。セキュリティ、SEO、アクセシビリティから一つずつ選び、curl、dig、ページのソースで確かめます。
• ステージングで既知の問題を仕込む。altのない画像や重複したタイトルなどを入れ、報告されるかを見ます。
• 一つの指摘を修正して再監査する。その指摘は消え、無関係なものは変わらないはずです。
• 限界を読む。すべてをチェックすると主張するツールより、チェックしないことを明示するツールのほうが信頼しやすいものです。

Sitelemetryの対象範囲、修正の引き継ぎ方法、限界はセクション8にまとめています。

6. よくある落とし穴と回避方法

これらに共通する考え方は同じです。エージェントを、サーバーをまだ見ていない、素早く説明上手な同僚として扱いましょう。根拠を渡し、権限は狭く保ち、結果は稼働中のサイトで確かめます。

7. 実例：小さなクリニックのWebサイト

ある歯科クリニックが、www.example-clinic.comでオンライン予約フォーム付きのWordPressサイトを運営しています。事務長がAIアシスタントに監査サービスを接続し、ドメインを確認したうえで、ホームページと予約ページの全体監査を依頼します。結果の一部は次のとおりです（説明用で、実際のデータではありません）。

エージェントは、最初の二つを優先する理由を説明します。バックアップはパスを推測できる誰にでもデータを公開してしまい、トラッキングコード内のアドレスはデータレイヤーを読むすべてのサードパーティタグに渡されるからです。さらに、AIクローラーのブロックは意図的なものかを尋ねます。誰も決めていなかったため、これは修正ではなくオーナーが判断する事項になります。

バックアップの対応はコードではありません。ファイルを削除し、サーバー上の他のコピーを探し、どのプロセスが作成したかを突き止めます。次にアクセスログで過去のダウンロードを確認し、バックアップに含まれていたパスワードやキーを変更し、患者データが漏えいした可能性があるなら、クリニックのデータ侵害対応手順に従います。フォームのラベルについては、エージェントが5つの項目とそれがある予約ページを明記した修正プロンプトを書きます。制約は見た目のデザインを変えないこと、受け入れ基準はスクリーンリーダーが各項目のラベルを読み上げることです。開発者のコーディングエージェントが変更を加え、開発者がレビューしてデプロイし、再監査で指摘が消えたことを確認します。DMARCレコードはDNSの管理者に回し、DMARC導入ガイドで説明しているとおり、レポート付きのp=noneから始めます。どの項目も同じ形で終わります。変更し、デプロイし、それを見つけた監査で再度確認する、という流れです。

8. Sitelemetryでこのワークフローを実行する

Sitelemetryは、このガイドのワークフロー向けに作られたAIによるWebサイト監査ツールです。

• 6つの分野。セキュリティは、Enterpriseプランで最大27モジュール：DNS、SPFとDMARC、TLS、HTTPS対応状況、セキュリティヘッダー、CORS、公開されたファイル、APIとシークレットの露出、サブドメインテイクオーバー、サプライチェーン、認証の入口、オープンポート、HTTPメソッド、WordPressなど。テクニカルSEOは、Google Search Consoleのクリック数、CTR、掲載順位、クイックウィンを含みます。そのほか、AI可視性の準備状況、アクセシビリティ、PageSpeed Insights、Lighthouse、CrUXフィールドデータによるパフォーマンス、連携があります。
• 根拠と修正。指摘には重大度、根拠、影響、対処方法が付き、各監査から、制約、受け入れ基準、再テスト手順を含むエージェント向けの修正プロンプトを一つ作成できます。
• AIツールの中で。ChatGPT、Claude、Claude Code、Codex、CursorでOAuthサインインのMCPとして動作します。接続方法はMCP接続ガイドをご覧ください。OAuthサインインでは、ブラウザ画面でアクセスを承認するだけで、パスワードやAPIキーをチャットに貼り付けることはありません。
• 検証と監視。修正後に再監査し、稼働中のサイトで確認します。プランに応じて、監視は週次、日次、毎時で実行されます。レポートはJSONまたはPDFでエクスポートでき、Enterpriseではホワイトラベルのレポートも使えます。
• プラン。Starterは$49/月、Professionalは$149/月、Enterpriseは$249/月です。各プランの内容は料金ページで確認できます。

その限界は、このガイドが確認するよう勧めている点そのものです。ホスト型監査は対象を変更せずに観察し、アクティブなセキュリティチェックは確認済みの対象にのみ実行します。SEO、AI可視性、アクセシビリティ、連携のチェックはJavaScriptを実行せず静的HTMLを読みます。AI可視性はコンテンツの準備状況を確認するもので、AIアシスタントには問い合わせません。アクセシビリティのチェックは静的でWCAG 2.2に基づくものであり、完全な手動評価ではなく、セキュリティ監査もペネトレーションテストではありません。静的解析では見えない部分は、セクション3の手動チェックで補ってください。