III-D9 技術監査の手順を身につける
III-Dまでの技術要素を、抜け漏れなく点検する監査手順
このレッスンの狙い：自社サイトのテクニカルAIO監査を実行できる
最終更新: 2026-07-23
この記事の要点
- 自社サイトのテクニカルAIO監査を実行できる
- 技術監査とは何をすることか
- 4つの監査ゾーンで整理する
バラバラに学んできたrobots.txtの設定、構造化データ、llms.txt、サイト構造の話——これらを1つの点検フローとしてつなげ直すのがこのレッスンです。抜け漏れのない技術監査の型があれば、自社サイトはもちろん、クライアントサイトの診断でも同じ手順をそのまま使い回せます。
技術監査とは何をすることか
技術監査とは、「AIがそもそも自社サイトに到達し、正しく内容を取得できる状態になっているか」を、思いつきではなく決まった手順で点検することです。どれだけ良いコンテンツを書いても、robots.txtで塞がれていたりJavaScriptの向こうにコンテンツが隠れていたりすれば、AI検索には登場しません(編III-D1参照)。技術監査は、この「土台」部分に抜け漏れがないかを確認する作業であり、一度やって終わりではなく半年に1度は見直すべき定期点検として位置づけるのが実務的です。AI各社のクローラーポリシーやCDNの機能は数か月単位で更新され続けているためです。
4つの監査ゾーンで整理する
これまで学んできた内容は、次の4つのゾーンに整理すると監査として扱いやすくなります。
| 監査ゾーン | 対応編 | 主なチェック内容 |
|---|---|---|
| クローラー制御 | 編III-A | robots.txtでの個別記述・なりすまし対策 |
| 構造化データ | 編III-B | JSON-LDの実装・構文エラーの有無 |
| llms.txt・メタデータ | 編III-C | 設置の有無・過大な期待値の排除 |
| サイト構造・レンダリング・速度 | 編III-D(本編) | JS依存・重複整理・速度の最低ライン |
1つのゾーンだけを完璧にしても、他のゾーンに穴があれば土台としては機能しません。監査は必ず4ゾーンを一巡させることが前提になります。
見落としやすいチェック項目
各ゾーンの中でも、特に見落とされやすい項目を挙げておきます。クローラー制御では、「学習用」と「検索・索引用」を区別せず一括ブロックしていないかが盲点です。GPTBotを拒否したつもりでOAI-SearchBotまで巻き込んでいるケースは珍しくありません。構造化データでは、実装した後の構文エラー確認が抜けがちです。カンマ抜けなど些細なミスがあると、AIはその構造化データを一切解釈できません。サイト構造では、料金・FAQ・事例といった「引用してほしい重要コンテンツ」がクライアントサイドレンダリングに依存していないかが最重要チェック項目になります(編III-D1・D2参照)。画像変換や重量級APIエンドポイントをAIクローラーが無制限に叩ける状態になっていないか、というコスト事故対策の視点も、意外と監査項目から漏れやすい部分です。
速度は「加点」ではなく「最低ライン」で見る
技術監査でCore Web Vitals(表示速度の指標)を見る際は、優先順位のつけ方に注意が必要です。Google AI Overviews・AI Modeに表示された107,352ページを分析した調査では、LCPとの相関は-0.12〜-0.18、CLSとの相関は-0.05〜-0.09と、いずれも弱い相関にとどまりました（出典: Search Engine Land, 2026年1月）。この調査は「良いパフォーマンスが優位性を生むわけではないが、深刻な失敗は不利益をもたらす」と結論づけています。つまり監査では、極端に遅いページや大きなレイアウトのズレ(壊滅的な失敗)だけを是正すればよく、微差を追いかけるために監査の時間を使いすぎないことが賢明です。
実践ステップ
- CDNまたはサーバーログで、直近1〜3か月のAIクローラー別アクセス状況(頻度・404率)を確認する
- アクセスしてきたボットを学習用・検索索引用・エージェント代行用の3種に仕分け、robots.txtの設定と一致しているか照合する(編III-A参照)
- 主要ページのJSON-LD構造化データを検証ツールにかけ、構文エラーがないか確認する(編III-B参照)
- llms.txtを設置している場合、その説明が過大な効果を謳っていないか位置づけを再確認する(編III-C参照)
- 料金・FAQ・事例のページがJavaScriptに依存せずAIクローラーに読めるかを確認する(編III-D1・D2参照)
- 重複ページや古いモバイル専用URLが整理されているかを確認する(編III-D6・D8参照)
- 監査結果を1枚の一覧表にまとめ、半年後に同じ手順で再監査する予定をカレンダーに入れる
# 監査後のrobots.txt設定例(検索・索引用は許可、学習用は個別判断)
User-agent: OAI-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: GPTBot
Disallow: /members/
Sitemap: https://example.com/sitemap.xmlまとめ
技術監査は、バラバラに学んだ知識を1つの点検フローに束ね直す作業です。クローラー制御・構造化データ・llms.txt・サイト構造という4つのゾーンを一巡させ、見落としやすいポイントを重点的に確認すれば、抜け漏れのない監査が実現できます。速度のような指標は「加点」ではなく「最低ラインの是正」として扱い、時間をかけすぎないことも実務上のコツです。ここまでの4ゾーンが一巡できていれば、編III全体を1枚に束ね直す準備はもう整っています。
このレッスンはテキストとスライドで学べます。スライドは上のビューアからご覧ください。
確認テスト
選択肢をクリックすると、その場で正誤と解説が表示されます。
Q1. 技術監査の4つのゾーンは、クローラー制御・構造化データ・llms.txt/メタデータ・サイト構造(レンダリング・速度含む)の4つである。
本文中に4つの監査ゾーンとしてこの4つが表で整理されています。
Q2. 技術監査は基本的にどのくらいの頻度で見直すべきとされているか。
半年に1度は見直すべき定期点検として位置づけるのが実務的とされています。
Q3. クローラー制御ゾーンで見落としやすいとされる盲点はどれか。
「学習用」と「検索・索引用」を区別せず一括ブロックしていないかが盲点として挙げられています。
このレッスンのFAQ
Q. 技術監査は1つのゾーンだけ完璧にすればよいですか？
いいえ。1つのゾーンだけを完璧にしても他のゾーンに穴があれば土台として機能しないため、4ゾーンを一巡させることが前提です。
Q. 技術監査でCore Web Vitalsをどう扱うべきですか？
「加点」ではなく「最低ラインの是正」として扱い、極端に遅いページや大きなレイアウトのズレだけを是正すればよいとされています。
Q. なぜ技術監査を定期的に繰り返す必要がありますか？
AI各社のクローラーポリシーやCDNの機能が数か月単位で更新され続けているためです。