AIサイト監査：500ページのサイトに必要なチャットセッション数

本記事のモデルでは、500ページのウェブサイトをAIチャットで監査すると、1巡するだけで約21セッション、ご自身の作業時間にして約15時間かかります。より大きなコストは、21個の結果を足し合わせても1つの監査にならないことです。各セッションはほかのセッションが見た証拠を持たずに始まり、ページごとに異なる項目を確認し、判定を独自の言葉で書きます。そのため、統合できる共通の方法も、翌月に繰り返せる方法もありません。AIセッションは問題の説明と修正に非常に優れており、完全な検出事項の一覧から始めたときに最も力を発揮します。

ChatGPT、Claude、そのほかのアシスタントのどれでウェブサイトを監査する場合でも、以下の計算は変わりません。特定の製品ではなく、チャットセッションの仕組みそのものから導かれるからです。本シリーズの第1回1つのAIセッションではウェブサイト全体を監査できない理由では、1セッションで扱える範囲を整理し、1セッションあたり25ページと100ページの場合のサイトあたりのセッション数をモデル化しました。今回は、新しいセッションを開き続けた場合に積み上がるもの、つまりご自身の作業時間とセッション間のぶれを集計します。

500ページのサイトは上位4分の1に入るが、珍しくはない

このモデルではサイトの規模がすべてを左右するため、まず実際の規模から見ていきます。2026年5月から10月にかけてSEOReportが監査した外部ウェブサイトのうち、XML サイトマップに1件以上のURLが記載されていた29サイトでは、サイトマップに記載されたURL数の中央値は約90でした。4分の1のサイトは20以下、4分の1は440超、上位10分の1は3,000超でした。

これらはSEOReportの監査に申し込まれたサイトであり、ウェブ全体から無作為に抽出したものではありません。500ページのサイトはその中で上位4分の1にぎりぎり入る規模で、典型的にはブログやサービス・製品ページを持ち、場合によっては複数言語に対応している、事業が軌道に乗った企業のサイトです。サイトマップには、そのサイトが検索エンジンに見つけてほしいページが記載されます。タグ、絞り込み、アーカイブのURLはサイトマップの外にあることもあるため、サイトマップの件数は監査で考慮すべきページ数の下限にすぎません。

モデル：1セッションあたりのページ数から、サイトあたりのセッション数へ

これは測定ではなくモデルです。数値はすべて、明示した4つの前提から導かれており、どの前提も変更できます。

1. 1セッションあたり25ページ。 本シリーズ第1回で用いた2つの処理量のうち、少ないほうです。丁寧なページレビューでは、目に見えるテキストよりはるかに多くの情報を読みます。ステータスコード、レスポンスヘッダー、head 内のタグ、構造化データ、そしてそのページとサイトマップやほかのページとの関係です。2026年5月から10月にかけてSEOReportが監査した外部ウェブサイト45サイトでは、検出された506件の問題のうち94%が、ページの閲覧者には決して見えない場所にありました。また、中央値のサイトでは5か所の異なる証拠の場所で問題が検出されていました。1ページあたりこれだけの証拠を保持したうえで慎重に回答させるなら、処理量は多いほうではなく少ないほうの値になります。シンプルなページならもっと多く、重いテンプレートならもっと少なくなります。
2. サイト全体に関わるファイル用に追加で1セッション。 robots.txt、XML サイトマップ、そして HTTP と HTTPS の間、www ありと www なしのホスト名の間のリダイレクトです。
3. 1セッションあたりご自身の作業時間20分。 方法を改めて説明してページリストを渡すのに約10分、出力を保存してマスターリストに統合するのに約10分です。
4. 1ページあたりご自身の作業時間1分。 ページをヘッダーごと取得または貼り付け、セッションが実際にそれを読んだかを確認する時間です。アシスタントの取得ツールは、ヘッダーを除いてテキストに変換したページを返すことが多く、そのためにこの手順が必要になります。違いはAIエージェントがページを確認するときに見ているもので紹介しています。

計算式は次のとおりです。セッション数 ＝ ページ数 ÷ 25（端数切り上げ）＋ 1。ご自身の作業時間（分）＝ 20 × セッション数 ＋ ページ数。

作業時間は、セッション数ほど1セッションあたりの前提に左右されません。セッションが大きくなっても、ページの扱いにかかる時間は減らないからです。1セッションあたり10ページなら、500ページのサイトには51セッション、約25時間が必要です。第1回で用いた多めの処理量である1セッションあたり100ページでも、6セッションで、作業時間はやはり約10時間かかります。

さらに、この作業時間には3つのものが含まれていません。アシスタント自体の処理時間、修正作業そのもの、そして1巡目を確認するための2巡目です。

21セッションを足しても1つの監査にならない理由

作業時間は目に見えるので、予算を立てられます。ぶれは見えにくく、まとめた結果の信頼性を損なうのはこちらです。

各セッションはほかのセッションの検出事項を知らずに始まります。 セッション14は、セッション3がブログのテンプレートで同じ canonical タグの欠落を見つけたことを知りません。そのため新しい問題として再度報告したり、180ページに及ぶテンプレートの問題を1ページだけのメモとして扱ったりします。プロジェクトファイルやメモリ機能で以前のメモを引き継げば多少は助けになりますが、メモは結論にすぎません。セッション14にセッション3と同じ判断基準を適用させるものではないのです。

何を確認するかは各セッションが決めます。 まとまったページのレビューを頼まれると、アシスタントはページごとにどのシグナルを確認するかを自分で選びます。あるセッションは構造化データを読み、別のセッションは問題なさそうに見えたので読み飛ばします。最終的に、どのページを開いたかはわかっても、どのページでどのチェックを実行したかはわかりません。

判定の書き方はセッションごとに異なります。 「canonical がない」「rel=canonical リンクがない」「canonical タグが存在しない」は、同じ1つの検出事項を3通りに書いたものです。重大度もぶれます。同じ問題が、あるセッションでは「重大」、次のセッションでは「軽微」とされます。優先順位を決める数字、つまりその問題がいくつのページに共通しているかは、すべての行を手作業で表記統一して初めてわかります。

ページ間の問題はセッションのすき間に落ちます。 2026年5月から10月にかけてSEOReportが監査した同じ外部ウェブサイト45サイトのうち、32サイト（71%）には、個々のURLを見ただけではわからない問題が少なくとも1つありました。そうした問題は、サイトマップとそこに記載されたページを比べたとき、ページ同士を比べたとき、あるいは記事全体をまとめて読んだときにしか現れません。サイトを25ページずつに分割すると、まさにその比較が分断されます。セッション4とセッション19でそれぞれレビューされたほぼ重複する2つの記事は、決して突き合わされません。重複していますが、ユーザーが正規ページとして選択していませんの原因となる重複ページが、ページ単位のレビューをすり抜けてしまう経路の1つがこれです。

翌月に同じことを繰り返せません。 同じ質問を2回しても、別の言い回しで、ときには別の判定で返ってくることがあります。12月に21セッションをやり直して問題が減っていたとしても、サイトが改善したのか、セッションの判断が変わったのかを区別できません。決まった方法がなければ、比較の基準がないのです。

flowchart TD
    subgraph many["多数のチャットセッション"]
        A["次の25ページを選ぶ"] --> B["新しいセッション：方法を再度説明する"]
        B --> C["セッションが自分で選んだ項目を独自の言葉で確認する"]
        C --> D["検出事項を自分のメモにコピーする"]
        D --> E{"残りのページはあるか"}
        E -->|"ある"| A
        E -->|"ない"| F["21セット分のメモを手作業で統合する"]
        F --> G["翌月に繰り返せる記録が残らない"]
    end
    subgraph one["1回の監査、その後は検出事項ごとにAI"]
        H["1回の監査：毎回同じ方法"] --> I["証拠付きの検出事項一覧"]
        I --> J["検出事項1件につきAIセッション1つ"]
        J --> K["後日の監査も同じ方法"]
        K -->|"未解決の検出事項"| J
    end

1回の監査で変わること、変わらないこと

監査もサンプリングを行います。SEOReportの完全な診断では、ホームページ、サイトマップに記載されたページ、そして内部リンクの参照先ページを調べます。すべてのページを読むわけではなく、サンプルに基づく検出事項にはそれぞれ調べたページ数が記載されるため、どの結果についても対象範囲が記録に残ります。

変わるのは方法です。どの診断でも、定義済みの同じチェック群を同じやり方で実行し、それぞれの証拠を記録します。そのため、同じサイトの2つのレポートを検出事項ごとに比較できます。チャットセッションのすき間に落ちていた比較も、1回の実行の中で行われます。記載先のページと矛盾するサイトマップのエントリ、存在しないページへの内部リンク、ほぼ重複する記事、食い違う記事の日付、どこからもリンクされていないページなどです。出力は1つの一覧にまとまります。証拠と影響を受けるURLを伴う検出事項、検証手順付きの優先順位つき修正計画、そして PDF、Markdown、JSON 形式のエクスポートです。その構成はスコア付きSEOレポートの内容で詳しく紹介しています。

AIに任せる仕事の大きさも変わります。2026年8月23日から10月4日にかけてSEOReportが監査した外部ウェブサイト249サイトでは、レポートで検出された個別の問題（不合格または警告の検出事項）の中央値は14件で、4分の1のサイトでは17件以上でした。1つの問題が多数のページに影響することはありますが、それでも明確に定義された1つのタスクです。証拠が添付された約14件のタスクリストは、終わりの見えない21回の発見作業とはまったく別の仕事です。

監査が担わないのは、判断の代わりをすることと修正を書くことです。そこでこそAIセッションが真価を発揮します。これはAIによるスポットチェックについての以前の記事が、逆の方向から示した論点でもあります。

大規模サイトでAIセッションを上手に使う方法

セッションに渡すのはサイトではなく検出事項です。 各セッションは、1件の検出事項とその証拠、影響を受けるURLから始めてください。AIエージェント向けページで説明しているとおり、エージェント自身がレポートを作成し、REST API や MCP サーバーを通じてすべての検出事項を読み取ることもできます。そうすれば、サイトを一から調べ直すのではなく、診断結果から作業を始められます。

1セッションには修正1件を割り当てます。 タスクを絞ると、セッションの注意が1つの原因に集中し、回答のレビューも簡単になります。次のような形のプロンプトが効果的です。

Finding: XML sitemap lists URLs that redirect.
Evidence: https://www.example.com/old-pricing -> 301 -> https://www.example.com/pricing
          https://www.example.com/team -> 301 -> https://www.example.com/about
Platform: [your CMS, sitemap generator and hosting]
Task: Explain the most likely reason the sitemap still lists these URLs on this
platform, and give the smallest change that makes it list only final URLs.
Address this finding only.

どうしてもチャットで問題を探すなら、先に方法を書き出してください。 すべてのセッションの冒頭に同じチェックリストを貼り付け、各セッションに決まったページリストを割り当て、出力形式を1つに統一します。URL、チェック項目、観測値、判定の4列の表です。そうすれば統合は機械的な作業になります。これで表現と確認範囲のぶれは減らせますが、ページ間でしか現れない問題を拾えるようにはなりません。

後日の監査と Google で確認します。 Search Console で報告された問題については、まず影響を受けるURLをすべて修正し、そのうち1つで URL 検査の「公開 URL をテスト」を実行して、Google が変更後のページを取得できることを確かめます。このライブテストでは重複や canonical の判断は確認されないため、そうした問題についてはアクセスできることの確認にとどまります。そのうえで、その問題の「修正を検証」をクリックします。Google のページ インデックス登録レポートのドキュメント（2026年10月に確認）によると、検証には通常最大で2週間ほどかかり、場合によってはそれよりはるかに長くかかります。後日のレポート、または継続的なSEOモニタリングで説明している API による週次モニタリングで、問題を見つけたのと同じ方法でその検出事項が解消したかどうかを確認できます。

小規模サイトであれば負担はずっと軽くなります。モデルでは、20ページのサイトは2セッション、約1時間で済み、1ページだけの疑問なら監査はまったく必要ありません。サイトが大きくなるほどコストは増え、再現性のある方法の価値も高まります。

よくある質問

ウェブ閲覧機能を持つアシスタントなら、単独でサイト全体を監査できますか？

ウェブ閲覧機能があれば貼り付けが不要になるため、モデルの1ページあたり1分は短くなります。それでもアシスタントはページを1つずつ開き、どのページを開くかを自分で選び、ヘッダーを含む完全なレスポンスではなく、テキストに変換されたページを受け取ることがよくあります。ツールの挙動はアシスタントによって異なり、いずれにしても、翌月も同じように実行される決まった方法が加わるわけではありません。

コンテキストウィンドウが大きくなれば問題は解消しますか？

1セッションあたりのページ数が増えるので、セッション数は減ります。モデルでは、1セッションあたり100ページでも、500ページのサイトには6セッション、約10時間が必要です。1ページの扱いにかかる時間は変わらないからです。また、実行ごとのぶれもそのまま残ります。

1セッションあたり25ページは現実的な数字ですか？

これは、テキストだけでなくヘッダー、head 内のタグ、構造化データまで読むセッションを想定して選んだ前提です。ご自身のページに合わせて変更し、次の式を使ってください。セッション数 ＝ ページ数 ÷ 1セッションあたりのページ数（端数切り上げ）＋ 1。ぶれに関する結論は、この前提には左右されません。

チャットのやり取りの記録を監査記録として残すべきですか？

作業メモとして残してください。やり取りの記録には、セッションが何を結論づけたかは残りますが、その時点のステータスコードやヘッダーの値など、セッションが見た生の証拠は通常残りません。検出事項ごとに証拠を保存した記録があれば、後から判定を検証し、次回の監査と比較できます。