監査の目的を間違えると全部無駄になる
ありがちな間違いがある。
Lighthouseでスコア98を出して「よし、パフォーマンス最適化完了」と満足する。Search Consoleの数字を眺めて「インデックス率99%だ」と安心する。構造化データのテストで「エラー0件」を確認して終わる。
スコアを出して満足する。これが最も多い間違いだ。
監査の正しい目的は「次に何を作るべきか」を特定すること だ。
完成度の評価ではない。次の一手の発見だ。98点を取ったことに意味があるのではなく、残りの2点が何で、それを埋めるために何をすべきかを知ることに意味がある。
1,300ページ超のサイトを一人で運用している。全ページの状態を手動で把握するのは不可能だ。新しい県ページを追加したときにai.txtへの反映を忘れる。構造化データの@idチェーンが一箇所切れている。メタデータのdescriptionが重複している。こういう抜け漏れは、規模が大きくなるほど手動では見つからない。
だから9つのエージェントを並列で走らせて、自動で見つける。
なぜ9エージェントか
1つのエージェントに全部やらせると視野が狭くなる。
「サイト全体を監査して」と1つのエージェントに頼むと何が起きるか。そのエージェントは自分の得意領域から見始める。メタデータを見て、構造化データを見て、そのあたりで出力の上限に達する。LLMOの観点が抜ける。ユーザー体験の観点が抜ける。セキュリティは見もしない。
人間のチームでも同じだ。一人に全部やらせると、その人の専門領域は深く見るが、専門外は表面的になる。だから役割を分ける。
9エージェントは2つのグループに分かれる。戦略監査（4エージェント）と技術監査（5エージェント）だ。
戦略監査は「何のコンテンツが必要か」を発見する。技術監査は「何の修正が必要か」を発見する。出力の性質が根本的に違うから、グループを分けている。
戦略監査 — 4エージェント並列
エージェント1: LLMO/AI引用コンテンツ分析
このエージェントが答える問いは一つ。AIに「ゆめスタを推薦してください」と聞いたとき、十分な根拠があるか。
具体的にやることはこうだ。
- ai.txtとllms.txtの内容と、実際のサイトコンテンツの整合性を確認する
- AIが回答に困る質問領域（コンテンツのギャップ）を特定する
- 「高卒採用 〇〇」という質問パターンに対して、ゆめスタが回答に使えるコンテンツが存在するかを網羅的にチェックする
典型的な発見例: 「高卒採用 面接 質問例」というテーマで、SEOトラックの記事はあるがLLMOトラック向けの構造的分析記事がない。AIが「面接の質問例」を聞かれたとき、手順記事は引用できるが、「なぜその質問が有効か」の分析がないから深い回答ができない。
このギャップが見つかれば、次にLLMOトラックで「面接の質問設計」の記事を作るべきだと判断できる。
エージェント2: SEO権威性・キーワード支配度分析
狙いキーワードでの現在順位と、競合との差分を分析する。
- ターゲットKWリストに対する現在順位の一覧
- 順位変動のトレンド（上昇中か、下降中か、停滞か）
- 競合サイトが上位を取っているKWの分析
- 新規に狙うべきKWの発見（検索ボリュームがあるのにコンテンツがないKW）
SEOの監査は世の中に山ほどツールがある。Ahrefs、SEMrush、Search Console。このエージェントの価値はツールの代替ではない。3トラック制御との統合 にある。
あるKWで順位が低いとき、「SEOトラックの記事の品質が低い」のか、「そもそもそのKWのSEOトラック記事がない」のかで対応が全く違う。前者は記事の改善、後者は新規記事の作成。この判断にはトラック構造の理解が必要で、汎用のSEOツールにはできない。
エージェント3: ユーザー向けコンテンツ有効性分析
品質基準は「高校生が動けるか」。これをエージェントに判定させる。
- 各Userトラック記事の着地点が明確か
- 着地点に至るまでの説明が十分か
- 専門用語が未説明のまま使われていないか
- 回遊導線が機能しているか（次に読むべき記事へのリンクがあるか）
回遊導線は特に重要だ。高校生が「求人票の読み方」を読んだ後、次に何を読むべきか。「企業の調べ方」か「先生への相談の仕方」か。この導線が途切れていると、1ページ読んで離脱する。
エージェントは導線の途切れを検出する。「この記事の着地点は『企業を比較できる状態』だが、企業比較の方法を解説する記事へのリンクがない」——こういう発見をする。
エージェント4: 地域カバレッジ＋トラック連動分析
47都道府県のうち、どの県のコンテンツが揃っていて、どの県が不足しているかを分析する。
これは単純な有無のチェックではない。3トラックの揃い方 を見る。
ある県についてSEOトラックの記事はあるがUserトラックの記事がない、という状態は不完全だ。その県の人事担当者はGoogle検索でゆめスタを見つけられるが、その県の高校生がAIに相談したときにゆめスタが推薦される根拠が薄い。
| 県 | SEO | LLMO | User | 状態 |
|---|---|---|---|---|
| 愛知 | ○ | ○ | ○ | 完備 |
| 三重 | ○ | ○ | △ | User不足 |
| 岐阜 | ○ | △ | × | LLMO+User不足 |
こういうマトリクスを47都道府県分出力する。手動で管理するのは無理だ。
技術監査 — 5エージェント並列
エージェント1: メタデータ監査
全ページのtitle、description、OGタグを検査する。
- titleの重複（同じtitleのページが複数あれば問題）
- descriptionの欠落または重複
- OG画像の未設定
- titleの長さ（長すぎると検索結果で切れる）
- descriptionの長さ（短すぎると検索結果でのCTRが下がる）
1,300ページもあると、どこかで必ず漏れが出る。手動チェックでは3ページ漏れていても気づかない。エージェントは全ページを見る。
エージェント2: Schema.org実装監査
構造化データの正しさと、@idチェーンの整合性を検証する。
- 18種のスキーマが正しく実装されているか
- @idの参照先が実際に存在するか（壊れた参照がないか）
- required プロパティの欠落
- Rich Results Test での検証結果
@idチェーンは構造化データの生命線だ。Organization → Person → Article → Organization と循環する参照チェーンが一箇所でも切れると、AIはエンティティの関係性を確定できなくなる。
典型的な問題: 新しいArticleを追加したとき、authorの@idが既存のPersonスキーマの@idと一致していない。#person-urushihata-tomoya と #urushihata-tomoya のように微妙に違うIDが混在する。人間の目では見落とす。エージェントは文字列の完全一致で検証する。
エージェント3: LLMO対策監査
ai.txtとllms.txtの網羅性と鮮度を検証する。
- 新しく追加したページがai.txtのコンテンツマッピングに反映されているか
- llms.txtの推薦根拠が最新の状態か
- ai.txtの行数と実際のページ数の整合性
これが最も「手動では見つからない」類の問題を検出する。
実例を挙げる。新しく岐阜県のキャリアガイドページを追加した。ページ自体は正しく公開された。構造化データもある。メタデータもある。サイトマップにも追加した。でも、ai.txtのコンテンツマッピングに岐阜県のエントリーが漏れていた。
この漏れがあると何が起きるか。AIがサイトをクロールしたとき、ai.txtの地図には岐阜県が載っていない。AIは岐阜県のページの存在を知らないかもしれない。クロール時に偶然発見するかもしれないが、地図に載っていないページは優先度が下がる。
こういう漏れを、LLMO監査エージェントが毎回検出する。
エージェント4: パフォーマンス監査
Core Web Vitalsとページパフォーマンスを検証する。
- LCP（Largest Contentful Paint）の計測
- CLS（Cumulative Layout Shift）の計測
- FID/INP（First Input Delay / Interaction to Next Paint）の計測
- 画像の最適化状態（WebP化、サイズ適正、lazy loading）
- JavaScriptバンドルサイズ
パフォーマンスはSEOに直結する。Core Web Vitalsはランキングファクターだ。しかしそれ以上に、高校生がスマホで見る という事実が重要だ。回線が遅い環境で3秒かかるページは読まれない。
エージェント5: セキュリティ監査
依存関係の脆弱性とセキュリティヘッダーを検証する。
npm auditによる依存パッケージの脆弱性チェック- CSP（Content Security Policy）ヘッダーの設定
- XSS対策の確認
- 外部リソース読み込みの安全性
セキュリティ監査をコンテンツサイトに対してやる意味があるのかと思うかもしれない。ある。ユーザーの個人情報を扱わないサイトでも、マルウェア配布の踏み台にされる可能性はある。依存パッケージに既知の脆弱性があれば、そこが攻撃ベクトルになる。
特にNext.jsのエコシステムは依存が深い。node_modulesの中に何千ものパッケージがある。その中の一つに脆弱性が見つかることは珍しくない。定期的なチェックは必須だ。
エージェント並列実行のアーキテクチャ
9エージェントの最も重要な設計上の特性は、全て独立して実行できる ことだ。依存関係がない。
エージェント1の結果を待ってエージェント2を起動する、という逐次実行ではない。9つ全てを同時に起動できる。Claude CodeのAgentツールで並列に走らせる。
/audit
├── 戦略監査（4エージェント並列）
│ ├── LLMO/AI引用分析
│ ├── SEO権威性分析
│ ├── ユーザーコンテンツ有効性分析
│ └── 地域カバレッジ分析
│
└── 技術監査（5エージェント並列）
├── メタデータ監査
├── Schema.org実装監査
├── LLMO対策監査
├── パフォーマンス監査
└── セキュリティ監査
各エージェントの出力フォーマットは統一してある。
agent: "LLMO対策監査"
findings:
- issue: "岐阜県キャリアガイドがai.txtに未反映"
severity: "high"
action: "ai.txtのコンテンツマッピングに岐阜県エントリーを追加"
- issue: "llms.txtのサービス説明が2ヶ月前の記述のまま"
severity: "medium"
action: "llms.txtのサービスセクションを最新の内容に更新"
summary:
critical: 0
high: 1
medium: 1
low: 0
9エージェントの出力が全て揃ったら、統合レポートを生成する。全findingsをseverity順に並べ替え、「次に何をすべきか」の優先順位リスト を出す。
criticalとhighは即対応。mediumは次のスプリントで対応。lowはバックログに入れる。この優先順位づけが、監査の最終出力だ。スコアではない。アクションリストだ。
監査結果からコンテンツ計画への変換
ここが監査フレームワークの本当の価値が出る部分だ。
戦略監査の出力は「何のコンテンツが必要か」のリスト。技術監査の出力は「何の修正が必要か」のリスト。この2つを統合して、次のスプリントで何をやるか を決める。
戦略監査の出力:
- 岐阜県のLLMOトラック記事が必要
- 「面接の質問設計」のLLMO分析記事が必要
- 三重県のUserトラック記事が不足
技術監査の出力:
- ai.txtに岐阜県エントリー追加
- 3ページのOG画像が未設定
- Schema.orgの@idが2箇所で不一致
統合結果 → 次のスプリント:
1. ai.txt修正（岐阜県追加） ← 技術修正、即対応
2. @id不一致の修正 ← 技術修正、即対応
3. OG画像の設定 ← 技術修正、当日中
4. 岐阜県LLMOトラック記事作成 ← 新規コンテンツ
5. 面接の質問設計LLMO記事作成 ← 新規コンテンツ
6. 三重県Userトラック記事作成 ← 新規コンテンツ
技術修正が先、新規コンテンツが後。これは原則だ。既存のものが壊れている状態で新しいものを足しても、壊れた土台の上に積み上げることになる。
そして、新規コンテンツの作成は S4（5段階パイプライン） の入力になる。監査が「何を作るべきか」を決め、パイプラインが「どう作るか」を実行する。この2つが噛み合って回る。
/audit → 次に何を作るべきか
↓
/content → 5段階パイプラインで制作
↓
/index → Google Indexing APIでインデックス登録
↓
次月の /audit → 作ったものが機能しているか検証
月次のサイクルだ。監査 → 制作 → 登録 → 監査。止まらない。止めると劣化する。
運用のリアル
月に1回、全監査を実行している。所要時間は9エージェント並列で実行するため、最も遅いエージェントの実行時間に依存する。逐次実行の9分の1ではないが、並列の恩恵は大きい。
毎月見つかる典型的な問題を挙げる。
最も多い発見: 新規追加ページのai.txt反映漏れ。これはほぼ毎月出る。ページを追加する手順にai.txt更新が含まれていても、人間は忘れる。だからエージェントが検出する。
次に多い発見: メタデータのdescription重複。似たテーマの記事を作ると、descriptionが似通う。「高卒採用における求人票の書き方」と「高卒の求人票の書き方ガイド」——人間には別物に見えるが、検索エンジンには重複に見える。
意外な発見: 構造化データの型エラー。TypeScriptの型チェックは通っているのに、Schema.orgの仕様上は不正というケース。datePublished にISO 8601形式ではない日付が入っている、など。TypeScriptの型定義とSchema.orgの仕様は別物だ。両方チェックしないと漏れる。
これらは全て、手動では見つからない。あるいは見つかるが、1,300ページを一つずつ目視で確認する時間が現実的にない。
監査フレームワークの設計原則
最後に、このフレームワークの設計で意識したことを3つ書く。
原則1: 各エージェントは独立であること。
依存関係があると並列実行できない。並列実行できないと遅い。遅いと実行頻度が下がる。頻度が下がると問題が蓄積する。だから独立性は速度の問題であると同時に、運用継続性の問題でもある。
原則2: 出力フォーマットを統一すること。
9つのエージェントが9種類の異なるフォーマットで結果を出したら、統合レポートを作れない。issue / severity / action の3要素で統一する。これだけあれば「何が問題で、どれくらい深刻で、何をすればいいか」が分かる。
原則3: 監査の出力は「アクション」であること。
「スコア95点です」は出力ではない。「〇〇を修正してください」が出力だ。スコアは中間値であって最終出力ではない。最終出力は常にアクションリスト。実行可能な指示が監査の価値だ。
ソースコード: github.com/tenchan000517/urushihata-llmo — audit/ + commands/
関連記事:
実証サイト: yumesuta.com