配点を根拠の強さへ合わせ直した版

クロール可能性

エージェント対応

信頼性シグナル

コンテンツ構造

構造化データ

基準の変更履歴

海外の一次情報は毎週追いますが、採点基準のリリースは原則として月次です。毎週スコアが動くと、社内で「先週とスコアが違う理由」を毎週説明することになり、稟議にも共有にも載せられなくなるためです。提供元の重大な仕様変更と、私たち自身の誤りの訂正だけは臨時に反映します。

1. 2026.08 第76版2026-08-14臨時改訂表現スコアに影響なし

   この変更履歴の強調が、画面では効いていなかった

   7

   • スコアは変わりません。判断も、配点も、根拠も一切変えていません。 変えたのは画面への出し方だけです。
   • ★ この変更履歴と、各項目の説明・配点の理由・判断の理由が、強調とコードの記法を字のまま出していました。 アスタリスクとバッククォートが、そのまま画面に並んでいたということです。記事本文は Markdown を通るので効いていましたが、同じ書き方の文字列を画面へ直接置いていた場所は、記法が解かれていませんでした。 この評価基準のページだけで 568 箇所です。
   • 強調が効かないと、拾い読みができません。 この文章は段落ごとに要点を太字にする書き方をしているので、太字が消えることは飾りの欠落ではなく、読み方が 1 つ失われることです。
   • 公開済みの版の文言は 1 文字も編集していません。 直したのは描画側だけで、保存されている文字列はそのままです（src/components/rich-text.tsx）。
   • ★ 同じ見落としが起きないように、機械検査を足しました（pnpm check:markup）。散文の欄を RichText に通さず画面へ置いていないか、** が対になっているかを見ます。記事だけを見ていた検査を、画面の文字列まで広げた形です。
   • 変更履歴を版ごとに畳みました。 78 版すべてを開いたまま並べると、このページは 85 画面ぶんありました。履歴は 1 行も減らしていません。 版・日付・種類・スコアへの影響・題と件数は畳んだままでも読めます。
   • 記事に節の目次を付けました。 記事は 1 本 1 万〜2 万 6 千字あり、節が 14〜20 あります。広い画面でだけ、本文の右の余白に出します（本文の 1 行の長さは変えていません）。
2. 2026.08 第75版2026-08-14臨時改訂表現スコアに影響なし

   24 本目のまとめに、旧版の論理が残っていた

   6

   • スコアは変わりません。
   • ★ 本文では直したのに、まとめだけ旧版のままでした。 見出し・E-E-A-T・セマンティック HTML をまとめて「効く先はスクリーンリーダー」と書いていました。E-E-A-T を分離し、「ランキング要因ではない ≠ 検索と無関係」をまとめにも書きました。直した箇所の周辺だけを見て、要約を見落としていました。
   • まとめと Core Rule の「最も効く」も残っていました。 「他の提案より長期的に影響しやすい」「直接・決定論的に測れるもの」へ揃えました。
   • 「新しい呼び名を採らないと明言している」は解釈が強すぎました。 「Google が AEO / GEO を別の体系として扱わず、Google 検索の観点では still SEO と位置づけている例」に直しました。
   • 「重要な限定」の日付が 8 月 13 日のままでした。 見出しと Last Verified に合わせて 14 日へ。
   • ★ 表の見出しが空欄の箇所がありました。 | | Google が書いていること | のような形で、Markdown としては壊れていませんが、列の意味が読者に伝わりません。 24 本目の 2 個を埋め、check:tables に警告として追加しました（記事全体では 56 個あります。壊れてはいないので落としません）。
3. 2026.08 第74版2026-08-14定期改訂根拠表現スコアに影響なし

   24 本目で E-E-A-T の扱いを誤っていた。あわせて提供元の記述を 2 節ぶん足した

   9

   • スコアは変わりません。
   • ★ E-E-A-T を「効く先はスクリーンリーダー」の組に入れていました。まったく違います。 Google は SEO スターター ガイドで「E-E-A-T はランキング要因ではない」としていますが、別の資料では「E-E-A-T 自体は特定のランキング要因ではないが、良い E-E-A-T を示すコンテンツを識別する複数の要因を組み合わせて使うことは有用」とし、YMYL では強い E-E-A-T と整合する内容にさらに重みを与えるとしています。「ランキング要因ではない」と「検索と無関係」は別です。
   • ★ 評価基準 v7 で著者の明示を 6 → 3 へ下げた理由も言い直しました。 正しくは「E-E-A-T という抽象概念そのものを決定論的に 6 点で測る根拠が無い」であって、「E-E-A-T は検索に効かない」ではありません。 配点そのものは変えません。 v7 は公開済みなので配点理由は編集せず、訂正はこの版と台帳・記事に残します。
   • ★ 「複数の提供元が新しい形式を求めていない」は言い過ぎでした。 直接そう言っているのは Google だけです。 OpenAI が言っているのは「Instant Checkout 対応だから商品結果で優遇されるわけではない」までで、「新しい形式は要らない」とは言っていません。提供元をまたいで言えるのは「AI 専用の追加実装それ自体が露出上の優遇を保証する構造は確認できない」までです。
   • ★ 「増え続けています」がまだ時系列の主張のままでした。 数段落あとで「時系列の主張はしません」と書いているのに、前半で破っていました。業界側の言説を体系的に測ってもいません。 「SILVE がこれまで検証対象としてきた範囲だけでも、複数の用語と施策が存在します」に直しました。
   • 「最も効く」を「他の提案より長期的に影響しやすい」に直しました。 原文は「will likely influence ... more than any of the other suggestions in this guide」です。「機械では測れない」も「直接・決定論的には測れない」へ（代理指標なら観測できるため）。
   • ★ Google が「やらなくてよいこと」を節ひとつで挙げていることを、記事に足しました。 「Mythbusting generative AI search: what you don't need to do」節で、llms.txt などの特別なマークアップ・コンテンツの細分化・AI 向けの書き換え・不自然な言及の獲得・構造化データへの過度な注力の 5 つを挙げています。導入文は「AEO や GEO という用語はよく見かけるが、提案されている多くの hack は有効でも、Google 検索の実際の動作に裏づけられてもいない」です。これは SILVE の読みではなく、提供元自身の記述です。
   • ★ 「AI 検索 ≠ AI エージェント」の節を足しました。 同じガイドの別の節でエージェントを扱っており、ブラウザのエージェントがスクリーンショットの解析・DOM の検査・アクセシビリティツリーの解釈を通じてアクセスし得るとしています。「AI 検索に特別な実装は要らない」は「エージェント対応にも追加実装が要らない」ではありません。 この記事を「AI 対策不要論」と読ませないための、いちばん強い歯止めです。
   • 確認方法の表を 1 行直しました。 「JavaScript を切って本文が残るか」では、正しく実装されたサイトを誤って落とし得ます。 Google は「ブロックされていなければ JavaScript 内のコンテンツも処理できる」としています。レンダリング後の DOM と Search Console の URL 検査で確認するへ改めました。
4. 2026.08 第73版2026-08-14定期改訂採点項目の追加・廃止スコアが変わります

   配点の見直し（v7）を実際に反映し、24 本目を公開した

   5

   • ★ スコアが変わります。 2026.08.60 で決めた配点の見直し（実効重み 91 → 79）が、これまで反映されていませんでした。 版を作っただけで、公開する操作をしていませんでした。今日から採点は v7 です。
   • ★ 反映の途中で、書き出しの不具合を見つけて直しました。 公開の処理が、版に固定したスナップショットではなく現在の項目定義を引き直していました。そのため v6 が実効重み 91 ではなく 86 で公開されました。 参照している診断が 0 件だったので取り消して入れ直し、v6 = 91 / v7 = 79 に揃えました。
   • 同じ型の不具合を 2026.08.60 でも直していますが、そのときはコード側だけでした。 書き出しの経路が、その固定を無視していました。 版のスナップショットが正であって、現在の項目定義ではありません。
   • ★ 24 本目「AI 検索のための特別な対策は要るのか — 提供元自身が書いていること」を公開しました。 提供元が「新しいファイルもマークアップも要らない」と書いている箇所を集めた記事です。ただし「追加の技術要件は無い」であって「要件が無い」ではありません。 「特別な実装は要らない」と「何もしなくてよい」を混ぜないよう、冒頭と結びの 2 箇所で書いています。
   • この記事は、v7 で配点を下げた根拠そのものです。 提供元が「最も効く」と言っているもの（独自で有用なコンテンツ）だけ、私たちは測れません。
5. 2026.08 第72版2026-08-14定期改訂項目の追加・廃止根拠スコアに影響なし

   24 本目を下書きで用意し、節の呼び名の誤りを訂正した

   5

   • スコアは変わりません。
   • ★ 24 本目「AI 検索のための特別な対策は要るのか — 提供元自身が書いていること」を下書きで用意しました。 23 本目と同じ構造で、部品は 8 つの台帳に散っていたのに、「提供元は何を要ると言っているのか」としてまとめた記事がありませんでした。 まだ公開していません。
   • ★ 節の呼び名を間違えていました。 2026.08.60 で「Google は SEO の俗説として 2 つ明記していました」と書きましたが、Google はその節を「SEO の俗説」とは呼んでいません。 正しくは「Things we believe you shouldn't focus on」（過剰に注目しなくてよいと考えるもの）です。こちらが付けた呼び名を、資料の言葉として書いていました。
   • 記述の中身は正しく、配点を下げた判断も変わりません。 直したのは呼び名だけです。公開済みのリリースノートは編集しないので、訂正はこの版に残します。 診断項目の注記とチェックリスト v7 の配点理由は直しました。
   • 規則にしました。 「節の名前を、資料が使っていない言葉で呼ばない」（AI_SPECIFIC_REQUIREMENTS.md R6）。
6. 2026.08 第71版2026-08-13臨時改訂根拠表現スコアに影響なし

   23 本目から、証拠の射程を超えた一般化を 1 つ削った

   5

   • スコアは変わりません。
   • ★ 「大半のサイトは既定のままで、この設定に引っかかりません」を削りました。 公式資料から確認できるのは既定値が「含める」であることまでで、実際の設定状況のデータは示されていません。 反論を封じるために足した一文が、それ自体、新しい無根拠な一般化になっていました。「既定のままであれば、この設定自体は阻害要因になりません」に直しています。
   • 「掲載資格も提供元の側にあります」を「掲載資格の一部も」に直しました。 記事自身が直後で 4 つの置き場所（サイト側の実装・提供元側の設定・アカウントの状態・参加関係）を整理しているのに、言い切ると、サイト側の条件を忘れたように読めます。 インデックス可能性・スニペットの資格・クロールの許可は前提として残っています。
   • 「どれも新しい実装ではなく、確認と登録です」も強すぎました。 Google で UCP による決済機能を実装するには、Merchant Center の設定・商品データ・API の統合が実際に必要です。 OpenAI の Instant Checkout も実装の手順を求めます。「特別なファイルは要らない」と「プロトコルの実装は要る場合がある」を混同しないよう分けました。
   • 表とリンクの指摘は、ソースを確認したところ問題ありませんでした。 表は見出しと区切り行がそろっており、リンクも相対です（localhost はソースに 1 件もありません）。貼り付けの副作用でした。 ただし「調べたら大丈夫だった」を人手で毎回確かめるのは続かないので、npm run check:tables を追加しました（167 個すべて PASS）。
7. 2026.08 第70版2026-08-13臨時改訂表現スコアに影響なし

   読者が読めない書き方を 2 つ直した

   6

   • スコアは変わりません。 読みやすさの修正です。
   • ★ 本文に出てくる「2026.08.xx」が何なのか、どこにも書いていませんでした。 これは訂正を行った判断基準の版の番号で、変更履歴のついた基準という約束の実体です。消さずに、記事の冒頭で 1 行説明するようにしました（22 本）。
   • ★ 公開前の推敲を、記事の本文に残していました。 23 本目に「以前はこう書いていましたが」という記述が 7 箇所ありましたが、その記事は今日まで公開していません。読者が見たことのない文章についての説明でした。 直接の記述へ書き換えました。公開前の直しは記事に書かず、証拠台帳が履歴を持ちます。
   • ★ 英文の引用に日本語が添えられていない箇所がありました。 調べたところ 117 箇所のうち 2 箇所で、前後に日本語の説明がありませんでした。原文は消しません（一次資料と照合できなくなるため）が、日本語の読みを添えました。
   • npm run check:quotes を追加しました。 日本語を含まない引用について、前後に実質的な日本語があるかを機械で見ます。「論文自身がこう書いています」のような導入だけの定型は、説明とみなしません。 機械にできるのはここまでで、訳の正しさは見ません。
   • どちらも読者の指摘で気づきました。 「ほとんど大丈夫」を機械で保証できる形にしていませんでした。
8. 2026.08 第69版2026-08-13臨時改訂根拠表現スコアに影響なし

   下書きの記事で、旧表現の取り残しと引用資料の取り違えを直した

   6

   • スコアは変わりません。 公開前の下書きの修正です。
   • ★ 前の版で直したはずの表現が、1 箇所に残っていました。 「掲載の可否を決める設定」と「要件の置き場所が移ったことが見える」が PC1 の注記に残っており、PC8 で直した思想と矛盾していました。 一括で直したつもりで、取り残していました。
   • ★ 引用資料を取り違えていました。 UCP の参加要件（Merchant Center が good standing であること）の出所として support ページを挙げていましたが、そのページにこの記述はありません。 実際の出所は開発者向けガイドで、見出しは「Prepare your Merchant Center account」です。claim の出所は、その記述が実際にあるページにします。
   • ★ そして「UCP そのものの要件」と「Google 上での UCP 実装の要件」を分けました。 UCP はオープンな標準であり、Merchant Center はプロトコル自体の一般要件ではありません。 この分離は主張を弱めるどころか強くします — UCP 仕様への準拠 ≠ Google の UCP 機能への参加資格、が言えるようになります。
   • Search Console の生成 AI レポートを、1 つのレポートのように書いていました。 逐語は「generative AI performance reports for Search and Discover」で、面ごとに別のレポートです。Search 向けは AI Overviews と AI Mode、Discover には別のレポートがあります。一部サイトへの段階的な提供である点も明記しました。
   • 据え置いたもの — PC8 の格付け（multi_source_observation / 確信度 中）、時系列を主張しない判断、採点ゼロ。いずれもレビューで妥当と判定されています。
9. 2026.08 第68版2026-08-13臨時改訂表現根拠スコアに影響なし

   下書きの記事が、自分の準備状態 ≠ 可視性を跨いでいた

   7

   • スコアは変わりません。 公開前の下書きの修正です。
   • ★ 記事の主語が「掲載の可否」になっていました。 Google は資格の条件を満たしてもクロール・インデックス・表示を保証しないと明記しています。 OpenAI も、拒否すれば出ないとする一方、許可については表示されるために推奨するという書き方です。「可否」と書くと、SILVE 自身の準備状態 ≠ 可視性を跨ぎます。 題名を含めて「掲載資格・参加の条件」へ直しました。この記事が扱うのは「実際に出るか」ではなく「出る資格の一部がどこにあるか」です。
   • ★ 時系列を避けると書きながら、本文で破っていました。 前半に「要件の置き場所が変わっている」と書き、後半で「移ってきているとは書かない」と述べていました。過去のある時点と比べていない以上、変化を主張できません。 「要件の所在は一か所ではない」に直しました。
   • ★ 「サイトのログからは AI 検索での露出を測れない」は広すぎました。 サイトのログでも、クローラのアクセスや参照流入は観測できる場合があります。正確には、サイト側のログだけでは AI Overviews や AI Mode の中で URL が表示された回数そのものは観測できません。
   • ★ 「サイト側で操作できるのは参加しないことだけ」も強すぎました。 OpenAI は「To help ensure your site appears in search results, we recommend allowing OAI-SearchBot」と書いており、許可という操作はできますし、それが表示される道です。 正確には「除外はサイト側からできる。しかし許可したことは掲載の保証にはならない」です。
   • 反論への先回りを 1 文足しました。 この設定は既定で「含める」です。 本記事は、これが多くのサイトで頻発する阻害要因だと主張していません。 重要なのは公開サイトの状態だけでは確認できない掲載資格が存在するという、測定上の境界のほうです。
   • 「提供元をまたぐ動き」とは書きません。 言えるのは「Google と OpenAI という 2 つの提供元の、複数の機能で同型の構造を確認できる」までです。Microsoft・Anthropic・Perplexity は一次資料を確認できていません。確認できていないことは、確認できていないまま残します。
10. 2026.08 第67版2026-08-13定期改訂表現スコアに影響なし

    英語の概念語を日本語の主表記へそろえた

    6

    • スコアは変わりません。 表記だけの変更です。
    • ★ 同じ概念を、同じ日本語で表すようにしました。 準備状態（Readiness）・可視性（Visibility）・成果（Outcome）・発見（Discovery）・取得（Retrieval）・引用（Citation）・推薦（Recommendation）・選択（Selection）・行動（Action）など、約 600 箇所を日本語の主表記へ変えています。重要語は各ページの初出で 1 回だけ原語を併記します。
    • 単純な「英語禁止」ではありません。 規格名・クローラ名・Schema.org のプロパティ・論文の題名・コード・URL は原語のままです。 英語を残した箇所は「正式名称を守るため」か「検索・実装上必要」かで説明できます。
    • ★ 公開済みの版は、表記統一でも編集していません。 この変更履歴そのものと、公開済みのチェックリスト各版の配点理由は当時の表記のままです。「サイト全体で表記を揃える」というガイドと「公開済みの版は編集しない」という原則が衝突しますが、不変性を優先しました。 新しい版から新表記を使います。
    • 英語の逐語引用は翻訳していません。 原典と照合できなくなるためです。引用行はすべて原文のままです。
    • 規則を docs/methodology/NOTATION.md に置きました。 機械置換で実際に壊した箇所（CSS 変数・URL・テンプレートリテラルの識別子・機能名の分断・論文の節見出し）も、触ってはいけない場所の実例として記録しています。
11. 2026.08 第66版2026-08-13臨時改訂根拠スコアに影響なし

    下書きの記事で、最も強い証拠を要旨から逐語へ差し替えた

    4

    • スコアは変わりません。 公開前の下書きの修正です。
    • ★ レビューへ出す前に、最も強い証拠の原文を取り直しました。 [掲載の条件はどこにあるか](/articles/platform-participation)の PC6（ACP の公式 FAQ）を要旨で記録していましたが、原文のほうが強い記述でした。
    • 逐語はこうです。 「Does implementing the protocol mean my products will automatically be listed through AI agents? No, each AI platform will manage their own process for how businesses can participate. If your business wants to participate in ChatGPT, you'll need to apply.」 「参加したいなら申請が必要」が要旨から落ちていました。
    • 要旨で記録すると、原文より弱くなることがあります。 とくに最も強い証拠は逐語で持ちます。
12. 2026.08 第65版2026-08-13臨時改訂項目の追加・廃止スコアに影響なし

    記事の取り込みが、勝手に公開しないようにした

    6

    • スコアは変わりません。 記事の出し方の話です。
    • ★ [前の版で追加した記事](/articles/platform-participation)を、下書きへ戻しました。 レビューのやり取りを経ていないのに公開状態にしていました。 手順は「台帳 → 記事 → 正本 → 読む順路 → レビュー → 公開」と決めたばかりで、その直後に実装側が飛ばしました。
    • ★ 原因は手順ではなく、仕組みが何も強制していなかったことです。 取り込みスクリプトは記事の作成時に公開日を入れており、さらに更新側も「下書きなら公開日を入れる」条件になっていました。つまり手で下書きに戻しても、次の取り込みで勝手に公開へ戻ります。
    • 取り込みは公開しなくなりました。 新しい記事は下書きとして入り、公開は管理画面の公開ボタンから明示的に行います。取り込みは公開日に一切触れません — 公開済みは公開のまま、下書きは下書きのまま、本文と題名と説明文とタグだけがファイルへ揃います。何度流しても安全です。
    • 取り込みの最後に、下書きのまま残っている記事を必ず出すようにしました。 公開しなくなった以上「入れたのに出ていない」が普通に起きます。黙っていると、書いた本人が公開したつもりで放置します。
    • これは課金の枠やページ数のときと同じ型の不備でした。 合意したことを、仕組みが守れる形にしていなかった。 手順を HANDOFF.md の「記事の作り方」に書き、なぜ仕組みに落としたかも残しました。
13. 2026.08 第64版2026-08-13定期改訂根拠項目の追加・廃止スコアに影響なし

    記事を 1 本追加した — 掲載の条件はどこにあるか

    8

    • スコアは変わりません。 採点には使わない記事です。
    • ★ [掲載の条件はどこにあるか](/articles/platform-participation)を公開しました。 これまで話題ごとに分けた構成では置き場所が無かった主張です。Search Console の生成 AI 掲載設定は 12 本の記事に部品として散っていましたが、どの記事もそれを「どこで決まるか」としてまとめていませんでした。
    • 中身は、提供元の記述が同居していることの整理です。 Google は「新しい機械可読ファイルもマークアップも要らない」と書く一方、「Search Console で生成 AI 機能に含まれている必要がある」とも書いています。矛盾ではなく、条件の置き場所が違います。要件が減ったのではありません。
    • 最も強い証拠は Google 以外の提供元にありました。 ACP の公式 FAQ が「プロトコルを実装しても自動的に掲載されず、各 AI プラットフォームが独自に参加方法を管理する」と明記しています。仕様への準拠と、参加は別だと提供元自身が書いています。
    • ★ この記事は SILVE の診断の限界の説明でもあります。 掲載設定は robots.txt にも HTML にも現れないので、公開ページを取得しても観測できません。満点でも掲載の条件をすべて満たしているとは限りません。 2026.08.59 で結果画面へ書いた注意書きの、背景そのものです。自社ツールに都合の悪い話ですが、書かないほうが問題です。
    • ★ 「移ってきている」という時系列の主張はしていません。 比較の基準を持っていないからです。 過去のある時点で条件がいくつあったかを測っていない以上、「増えた」と書けば[効果検証の記事](/articles/causal-evaluation)が否定していることを自分でやることになります。 言えるのは 2026 年 8 月時点でそうなっていることまでです。
    • 横断の読みを、提供元の記述として書きません。 個々の事実は公式資料の逐語ですが、まとめ方は SILVE の解釈です。台帳では official ではなく multi_source_observation、確信度は中としています。
    • 取り込みの過程で、資料の題名の誤りを 1 件見つけて訂正しました。 OpenAI の Agentic Commerce のページを「Agentic Commerce Protocol | OpenAI Developers」と記録していましたが、このページは SPA で <title> が返らず、題名を確認できていませんでした。 同ドメインが案内している Markdown 版で取得すると「Agentic Commerce」です。あわせて題名の確認日が抜けていた資料 14 件を確認して埋めました。
14. 2026.08 第63版2026-08-13臨時改訂根拠スコアに影響なし

    資料の変更検出を実際に動かして、2 つの欠陥を潰した

    6

    • スコアは変わりません。 前の版で作った検査そのものの修正です。
    • ★ 作った直後に「変更あり」が 2 回出ましたが、どちらも資料の変更ではなく、こちらの欠陥でした。
    • ★ HTTP 200 でも本文が取れていないことがありました。 同じ URL への連続取得のうち 1 回が 0 字を返しました（応答は 200）。抽出に失敗しているだけなのにハッシュが変わるので「変更あり」になります。200 を「取得できた」と同義に扱わないようにし、抽出が空・極端に短いものは取得できなかったものとして報告し、基準も書き換えないようにしました。403 を「消失」と扱わないのと同じ規則です。成功したように見える失敗のほうが危ない。
    • ★ 基準にハッシュしか持たせていませんでした。 変化を検出したあと、「何が変わったのか」を調べる手立てがありませんでした。 実際に 2 回、原因を特定するために使い捨てのスクリプトを書く羽目になっています。正規化後の本文を手元（git 管理外）に残し、変更を報告するときに最初の相違箇所を出すようにしました。検出できても中身を出せない検査は、結局のところ読まれません。
    • --due の「30 日」に根拠が無いことを書きました。 運用の都合で置いた窓で、[スコアの帯](/articles/measurement-layers)の 50 / 75 と同じ性質です。根拠の無い閾値は、無いと書きます。 環境変数で変えられるようにもしました。この値を変えても、台帳側の再検証期限は 1 日も動きません。
    • どちらの欠陥も、設計を眺めていても出てきませんでした。 基準を取り直して 2 回目を走らせ、出てきた「変更あり」を 1 件ずつ潰して初めて分かったものです。検出系を作ったら、必ず 2 回以上まわして誤検知を 0 にしてから運用に載せる、を規則にしました。
15. 2026.08 第62版2026-08-13定期改訂項目の追加・廃止根拠スコアに影響なし

    記事を LLM に書かせないことを決め、一次資料の変更検出を作った

    8

    • スコアは変わりません。 記事の作り方と、資料の見張り方の話です。
    • ★ 候補記事を LLM に要約させる段を廃止しました。 実装は入っていましたが（Claude Sonnet 5）、動かさずに畳みます。フィードの収集は残します。 集めるのは候補の一覧までで、読むのも書くのも人がやります。
    • 理由は、詰まりどころが執筆ではなく証拠の裁定だからです。 記事 22 本のレビューで出た約 30 件の修正に、「文章が下手だった」は 1 件もありません。表の単位を本文で確かめずに 100 倍間違えた、論文の結論文が同じ論文の Limitations と矛盾していた、同じ量に 2 つの値があった（3 本で発生）、403 がこちらの取得手段の問題だった、数字は近いが概念が違った。抽出テキストを渡された要約器には、原理的に見つけられません。
    • そして、自分が読者に言っていることと矛盾します。 Google は「独自で有用なコンテンツが、このガイドの他のどの提案よりも効く」とし、scaled content abuse を名指ししています。要約の量産は、SILVE が顧客に警告している位置に自分が立つことです。
    • ★ 代わりに、一次資料の変更検出を作りました（npm run check:sources）。日付ではなく中身で見ます。 台帳の再検証期限が言うのは「時間が経った」ことだけで、資料が書き換わったかどうかは言いません。 台帳が持つ 124 件の一次資料を取得して正規化し、ハッシュで比較します。変更があれば、それを使う claim と最も早い再検証期限を並べて出します。ここでも LLM は使いません。変わったかどうかはハッシュで分かり、読むのは人です。
    • ★ 誤検知を出さない設計が本体でした。 素朴に作ったところ、ある資料が毎回「変更あり」になりました。原因は配信元の Pod 名で、文字数は同じまま毎回変わるため長さでは気づけません。推測で正規化を足さず、同じ URL を 2 回取って差分の位置を特定してから決めました。 同じ資料を 2 回取って安定性を測るモードも付けています（現在 118/118 で安定）。毎回「変更あり」と言う検査は使われなくなります。
    • ★ 429 を「取得できなかった」と記録しかけました。 5 並列で回すと、URL を 7 件持つホストが軒並み HTTP 429 を返します。これは資料の問題ではなく、こちらの当て方の問題です。 ホストごとに 1.5 秒あけたところ 124/125 が取得できました（残る 1 件は既知の 403）。403 のときに決めた規則を、自分のスクリプトにも当てました。
    • 判断の理由を HANDOFF.md に残しました。 同じ議論を繰り返さないためです。
16. 2026.08 第61版2026-08-13臨時改訂表現根拠スコアに影響なし

    サイト全体を、記事とチェックリストの思想へ突き合わせた

    9

    • スコアは変わりません。 画面の言葉だけを直しています。
    • ★ 「なぜ効くか」というラベルをやめました。 診断結果と CSV で、各項目の説明に「なぜ効くか」という見出しを付けていました。説明文のほうは「根拠は状況証拠にとどまります」「確認できているわけではありません」と書いているのに、見出しが効果を前提にしていました。 「なぜ見ているか」に変えました。SILVE が言えるのは、その項目を見ている理由までです。
    • ★ 用語集の Google-Extended が不完全でした。 「Google 検索の順位には影響しないとされています」だけで、AI Overviews や AI Mode の制御ではないことが落ちていました。 これは 2026.08.55 で記事側を訂正したのとまったく同じ誤読で、用語集は読者が最初に頭の中の地図を作る場所です。 学習と grounding の制御であること、AI Overviews は Google 検索の機能でアクセスの制御は Googlebot 側であることを明記しました。
    • ★ 3 つの画面で、注意書きの中身が食い違っていました。 トップの FAQ は「外部での言及、他サイトとの比較、その時点のプラットフォームの挙動」、[スコアの考え方](/about)は「外部での言及、被リンク、ブランド認知」、[運営者情報](/legal)は「外部での言及、ブランド認知」。被リンクとブランド認知が AI 検索の露出へ影響することを、私たちは一次資料で確認していません。 3 つとも、確認できている要因（外部サイトでの記述・プラットフォームごとの違い・実行ごとのばらつき）と、公開ページからは確認できない条件（Search Console の生成 AI 掲載設定）へ揃えました。
    • 測定モデルの図で、Readiness が「実装済み」に見えていました。 公開ページの取得だけでは確認できない Readiness の条件があります。 「公開ページから観測できる範囲を実装済み」に改め、図の下にも「1 層目も全部ではありません」と書きました。
    • 診断ページの説明文を直しました。 検索結果に出る説明が「AI 検索での発見可能性を診断します」でした。見出しは「AI 検索準備度の診断」なのに、説明文だけが可視性の言い方になっていました。
    • ★ 「毎月 15 日に更新」と、訂正を出し続けることが噛み合っていませんでした。 SILVE の原則は「自分たちの誤りも、新しい版での訂正として履歴に残す」ですが、誤りが見つかったときに次の 15 日まで待つのは、その原則と正面から矛盾します。 実際この 8 月には訂正版を何度も出しています。「毎月 15 日の定例の更新」と「随時の訂正」を分けて書くようにしました。
    • フッターの「直近の海外論調を反映した現時点の視点」を「一次資料にあたって作った基準による、現時点の視点」に改めました。 トップの見出しは「一次資料にあたって作った基準」と書いており、同じことを別の言い方で説明していました。
    • 古くなる数字を 2 つ、導出に変えました。 記事一覧の「22 本」と、[判断基準の読む順番](/methodology)にあった版番号の例（「第29版」のまま止まっていました）。
17. 2026.08 第60版2026-08-13定期改訂採点分類根拠スコアが変わります

    配点を根拠の強さへ合わせ直した（チェックリスト v7・スコアが変わります）

    10

    • ★ スコアが変わります。実効重みは 91 から 79 になりました。 同じサイトを測り直しても点数は変わります。v2 以来はじめて、配点の考え方そのものを見直した版です。
    • ★ 下げる前に、提供元の一次資料を読み直しました。 「根拠が弱いから下げる」で終わらせないためです。その結果、下げる根拠のほうが想定より強いことが分かりました。
    • ★ Google は SEO の俗説として 2 つ明記していました。 ひとつは見出しについて —「Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn't matter if you're using them out of order. ... There's also no magical, ideal amount of headings」。もうひとつは著者について —「Thinking E-E-A-T is a ranking factor」→「No, it's not.」
    • そして生成 AI 向けガイドはこう書いています。 「Creating content that people find unique, compelling, and useful will likely influence your website's presence in generative AI search in the long run more than any of the other suggestions in this guide」。最も効くと提供元が言っているものは、SILVE が決定論的に測れないものです。だからこそ、測れる代理指標の配点を実際の根拠より重くできません。
    • ★ 定義文の存在：5 → 0（暫定採用へ）。 この項目を直接支える資料を確認できていません。 同じ状態にある「質問形式の見出し」は暫定採用・配点 0 で扱っているのに、こちらだけ実効重みの 5.5% を配分していました。同じ証拠の状態に、5 点と 0 点という違う扱いをしていたことになります。 検出は続けますが配点しません。
    • ★ 著者の明示：6 → 3。 Google が「E-E-A-T はランキング要因ではない」と明記しています。 一方で誰が書いたかを機械可読にすること自体は公式に推奨され、Article 構造化データの要素でもあるので 0 にはしません。v6 まではこれが 4 番目に大きい配点でした。
    • ★ 見出し階層の整合性：5 → 2。判定も直しました。 提供元が「順序も数も検索の観点では効かない」と言っているものを、数で採点していました。 判定から「h1 はちょうど 1 つ」と「h2 以上が 2 つ以上」を外し、「h1 が 1 つ以上あるか」と「レベルが飛んでいないか」だけにしました。前者は title link の情報源として、後者はスクリーンリーダーへの有効性として公式の記述があります。 効く先は検索ではなくアクセシビリティで、そこから作られるアクセシビリティツリーはエージェントが操作対象を得る経路でもあるため 0 にはしません。
    • 段落の自己完結性：3 → 2。 検索拡張生成の実装知見からの推論であり公式仕様ではありません。Google は「AI のためにコンテンツを細かく分割する必要はない」と明言しています。
    • ★ 空いた 12 点を配り直していません。 配り直せば「合計 91 を維持するため」という根拠のない理由で他の項目が動きます。実効重みは根拠の合計であって、定数ではありません。 結果として、掲載経路・JavaScript 非依存・取得の成否といった根拠の強い項目の比重が上がります。 それがこの版の狙いです。
    • ★ 版の不変性が、コード上では効いていませんでした。 snapshotStandard() はモジュール読み込み時に評価されるため、Metric の採用状態を変えると過去の版の実効重みが遡って変わります。 実際に今回、v2〜v6 の実効重みが 91 から 86 へ勝手に変わりました。 過去の版の採用状態を明示的に固定して塞ぎ、v1 = 104 / v2〜v6 = 91 という当時の値へ戻しました。「公開済みの版は編集しない」を、DB だけでなくコード上でも成立させます。
18. 2026.08 第59版2026-08-13定期改訂表現根拠スコアに影響なし

    記事の修正を診断ツールへ突き合わせた（チェックリスト v6）

    10

    • ★ スコアは変わりません。 重みも判定ロジックも 1 つも変えていません。チェックリスト v6 は v5 と点数が完全に一致します。
    • 記事 22 本のレビューを一巡したあと、その修正が採点へ波及するかを全項目で照合しました。 採点を変える必要は 1 件もありませんでした。 記事側の修正が「証拠の書き方」に集中していたのに対し、採点は最初から決定論的に観測できるものだけを見ていたためです。
    • 照合の結果、既に正しかったもの。 Google-Extended は ai_search_citation の capability を持たないので、ブロックしても最大配点の項目は減点されません（2026.08.55 の修正と一致）。authority.external_profiles は言及数ではなく sameAs の有無だけを見ています。authority.entity_consistency は表記の一致だけを見ており、「強さ」を測っていません。 llms.txt・質問形式の見出し・FAQ・学習の許諾は、いずれも配点 0 のままです。
    • ★ 見つかった不整合は、すべて言葉の側にありました。 各項目の根拠の注記は慎重に書かれているのに、利用者が読む説明文と配点の理由が、その注記が「確認できていない」と書いている効果を断定していました。 記事レビューで潰したのとまったく同じ型が、製品に残っていました。
    • 例。 content.definition の注記は「この項目自体を直接支える資料は確認できておらず、根拠は状況証拠にとどまる」。同じ項目の配点の理由は「要約生成時に最も引用されやすい構造」。同じ項目の中で矛盾していました。
    • 説明文 11 件を、注記に合わせて書き直しました。 とくに authority.dates は「AI が古い情報を採用しないための判断材料」としていましたが、Google は「新しいほど優遇する」も「古いほど不利になる」も否定しています。 問題になるのは古いことではなく内容が失効していることです。新しさは採点していません。日付が機械可読かどうかだけを見ています。
    • 配点の理由 4 件は、チェックリスト v6 として切りました。 理由は版に固定されるので、公開済みの版は編集しません。 対象は content.definition / authority.dates / authority.author / content.heading_hierarchy です。
    • ★ 観測できない Readiness があることを、画面に書きました。 正本（MEASUREMENT.md）は「Readiness に属するのに観測できないものもある」と書いていましたが、その記述は正本にしかなく、製品のどこにも出ていませんでした。 最大配点の項目は robots.txt だけを見るので、Search Console の生成 AI 掲載設定で除外されているサイトが満点を取り得ます。 結果画面・評価基準のページ・当該項目の説明文の 3 箇所に書きました。
    • トップページと理念のページの言い回しも直しました。 「組織や記事を実体として認識できるか」→「機械可読になっているか」、「AI が同一の実体として認識できません」→「結び付けにくくなります」。測っているのは知名度ではなく、表記の曖昧さの少なさです。
    • ★ 積み残しを 1 件、判断として残しました。 content.definition は実効重み 91 のうち 5（約 5.5%）を占めますが、直接の根拠が無いと自分の注記が書いています。 v2 で structured_data.organization を 8 → 2 へ下げた理由は「必須条件ではないと自分で書いている項目に、スコアの 1/5 を配分している状態は説明できない」でした。同じ理屈がこの項目にも当たります。 重みを動かすとすべての診断結果が変わるため、この版では言葉だけを直しています。
19. 2026.08 第58版2026-08-13臨時改訂根拠表現スコアに影響なし

    因果の記事で、規則を一般化しすぎていた

    9

    • スコアは変わりません。 この層は未実装のままです。
    • ★ 「3.5 倍は ChatGPT というプラットフォーム自体の成長」を訂正しました。 直接観測されたのは、同一ドメインの施策を受けていないページが 3.5 倍になったことです。 論文はこれを platform tailwind を吸収したものと解釈していますが、モデルはプラットフォーム側の変動が処置群と対照群へ等しく乗法的に効くという仮定を置いており、著者自身が「an external platform-wide referral index would strengthen identification」と限界に挙げています。 変数名も platformControlGrowth から controlGroupGrowth へ改めました。変数名で、観測した以上のものを確定させません。
    • ★ 「因果の確信度を、最も弱い重要な検定に合わせる」を書き直しました。 この研究についての結論は正しいのですが、一般規則としては誤りです。 検定ごとに検証している仮定・帰無仮説・検出力が違うので、「複数の検定のうち最も悪い p 値を採る」は方法論として成り立ちません。正しくは「識別の仮定を直接脅かす置換検定・反証検定・頑健性検定が通らなかったとき、その結果を無視して主分析だけから強い因果の格付けを与えない」です。「一番弱い数字を採る」ではなく「どの検定がどの因果の仮定を検証しているか」を見ます。
    • ★ 波及の逆向きの断定を撤回しました。 「一社が候補に入れば、誰かが外れます」と書いていましたが、生成 AI の回答で引用や情報源の数が固定だとは限りません。 「A が入れば必ず B が外れる」というゼロサムの構造とは限らないので、競合的な干渉は理論上の可能性として記録し、推定の向きを断定しません。 論文が明示している向きは「対照群も恩恵を受けて推定が保守的になる」の 1 つだけで、逆の経路は直接検証されていません。
    • ★ 施策の束の内訳が 1 つ抜けていました。 SEO Guard を「Google からの意味のあるクリックがあるページを書き換えの対象から外す」までしか書いていませんでしたが、原文は3 つに分岐します — クリックがあるページは保護、自然検索にも AI にも関心が無いページは公開停止（unpublish）、残りが書き換えの待ち行列です。この施策は「既存の SEO を守りながら書き換える」だけでなく、需要の低いページの公開停止というコーパスへの介入を含みます。 束の中身を落とすと「タイトルを疑問形にしたから 1.8 倍」という誤読を防げません。
    • 80 / 20 は例であって標準ではない、と明示しました。 比率だけを書くと新しい「正解」に見えます。 必要な対照群の大きさは、見込む効果の大きさ・基準時の分散・クラスタ内の相関・ページ間の異質性・波及の有無・主要指標・必要な検出力で変わります。この記事の主題は「数字を手順へ変換しすぎない」ことです。80 / 20 も例外ではありません。
    • 応答単位の反復測定を、プロンプトで Visibility を観測する実験に限定しました。 「AI の応答は確率的なので各ページで反復測定が要ります」とあらゆる実験に当てはまるように書いていました。この研究の主要指標は ChatGPT からの参照セッションで、実際に用いているのは週次の処置群 / 対照群の比です。応答単位ではありません。 3 つのフィールドを持つ設計は変えず、値を page / response / page に固定しないようにしました。
    • Evidence of No Effect を主張する条件を書きました。 非有意は Insufficient Evidence であって Evidence of No Effect ではありません。後者を主張するには、事前に「実質的に無視できる効果の範囲」を決め、同等性 / 非劣性の考え方で検定し、信頼区間がその範囲へ十分に狭く収まることが要ります。「この設計では区別が付かなかった」と「無い」は違います。
    • ★ これで公開中の記事 22 本すべてのレビューを反映し終えました。
20. 2026.08 第57版2026-08-13臨時改訂分類根拠表現スコアに影響なし

    情報環境の記事で、近い数字を同じ量として並べていた

    10

    • スコアは変わりません。 この層は未実装のままです。
    • ★ 12.9% と 14.3% は、標本が違うだけではありませんでした。測っている概念そのものが違います。 Zhen の 12.9% は「ブランド・企業の公式サイト」というサイト種別の比率で、質問対象のブランド自身のサイトかどうかは判定していません。Żatuchin の 14.3% は回答対象のブランド自身が所有するドメインの比率です。「A 社について尋ねて B 社の公式サイトが引用された」は、前者では公式サイトに数え、後者では自社に数えません。
    • ★ 論文にない因果の説明を撤回しました。 「公式サイトの引用は 6,589 ドメインへ分散していた」という観測に、「公式サイトはブランドの数だけ存在するので 1 社あたりの取り分が小さい」と書いていました。論文はその理由を分析していません。 またこの 6,589 は各クエリの対象企業自身のサイトとは限りません。 論文の表現（relatively dispersed）より強い言葉へ寄せないようにし、論文自身の節見出しが Direct Citation of Official Sites Is Rare であることも残しました。
    • ★ 9.5% の分母を訂正しました。 「URL を持たない回答が 9.5%」と書いていましたが、回答の割合ではありません。 分母は 150,093 件の帰属行で、行の単位はブランド × 言語 × モデル × プロンプト × 引用です。1 つの回答が複数の行を生みます。
    • ★ groundingMode を sourceAttributionMode へ改めました。 implicit という値は「モデルの内部知識から生成した」と断定してしまいます。URL が開示されていないことと、内部知識から生成したことが確認されたことは別です。 前版で決めた「提供元が開示したログは内部の取得の全体とは限らない」と同じ形です。値は explicit_url / no_url_attribution / unknown にし、implicit knowledge は原典のラベルとしてのみ保持します。
    • ★ Reddit の研究の「処置」が何かを明確にしました。 処置は「実際に AI Overviews で引用されたこと」ではありません。「参照され得る資格（SFW）× AI Overviews の展開時期」の効果です。「引用されたらコメントが 12% 増えた」という研究ではありません。
    • ★ まとめの「AI Overviews は体験型コミュニティの参加を +12% 増やした」を訂正しました。 +12.0% / +12.4% は対象群（SFW）全体の主分析の値で、体験型の数字ではありません。体験型について言えるのは、処置効果が事実型よりコメントで 2.3 倍・投稿者で 2.8 倍大きかったことです（事実型にも有意な正の効果があります）。
    • AI Mode の符号反転の射程を限定しました。 「インターフェースが変わると効果の符号すら変わり得る」と書いていましたが、負に転じたのは体験型の「上乗せ分」のコメントだけです（9.54 → −0.17）。事実型への基本の処置効果も低下していますが符号は変わっていません。 この分析は主分析と期間も標本も違い（2025 年 12 月まで延長、104,975 分類済み・76,736,725 観測）、AI Mode 後の期間が短いことは著者自身が限界に挙げています。
    • ★ Żatuchin の論文内部にも不整合を見つけました。 ポーランドの求人ポータル対 Wikipedia の絶対件数が、本文と結論では 637 対 297、限界の節では「counts are solid（460 versus 202）」となっています。同一論文内で一致していません。 絶対件数を断定せず、2 倍以上という方向だけを採ります。
    • Platform 層の統制水準を、層から固定しないようにしました。 「Platform = 一部の項目を管理できる」と書いていましたが、Merchant Center の管理対象の商品について Google は属性・表示・各面での見え方を完全に管理できるとしています。同じ層の中で統制の水準が違います。 sourceControlClass と controlLevel を別のフィールドにしている設計はそのままに、層から水準を自動的に決めないという規則にしました。
21. 2026.08 第56版2026-08-13臨時改訂根拠表現スコアに影響なし

    新しさの記事で、自分が禁止した段階の拡張を自分でやっていた

    11

    • スコアは変わりません。 時間の扱いは未実装のままです。
    • ★ 「新しさは引用リストに入るかどうかには効く」を撤回しました。 記事はまず、その研究が already entered citation lists のページしか観測しておらず、内部の候補集合も落選ページも取得していないと正しく書いています。そのすぐ後で「新しさは引用リストに入るかどうかには効く」と書いていました。 まとめにも「新しさが効くのは引用リストに入る段階まで」が残っていました。落選したページを観測していない以上、選ばれやすさは示せません。比較対象が無いからです。
    • 言えるのは「引用リストに実際に現れたページの公開年齢の分布が、時間依存性の高いクエリほど新しい側へ偏っていた」までです。 この違いが、39 日を「AI の新しさランキング要因」へ変換しないという、この記事の中心そのものでした。
    • 論文自身の結論文と Limitations が食い違うときは、Limitations を優先します。 同論文の H2 は「Article-recency differences occur in retrieval selection and citation」と書いていますが、その文言をそのまま段階へ写すと、同じ論文の Limitations と矛盾します。
    • ★ 同じ論文の中に、値の食い違いを見つけました。 回答内の位置と公開年齢の相関に、Table 2-4 の −0.007（有意でない）と Table 2-5 の H2 の ρ = 0.041 が併存しています。符号すら逆です。 どちらかを真値として採りません。 ただしいずれも絶対値が極めて小さく、本文も「Within-answer position was almost unrelated to publication-age distance」と書いているので、方向だけを採ります。
    • 「Freshness と Validity は直交します」を言い換えました。 直交は統計的な独立まで意味してしまいます。実際には無関係ではありません — 時間依存性の高い問いでは新しいページほど有効である確率は高くなります。「独立している」ではなく「同じ変数ではない」が言いたいことです。2×2 の表はそのまま使えます。
    • 新しさの発火条件と、評価される属性を分けました。 「新しさが要求されるのはページ側の属性ではなくクエリ側の条件です」と書いていましたが、二者択一にしすぎていました。発火条件はクエリ側、何日前かはページ側の属性で、発火した文脈の中でページ側の新しさが評価されます。
    • ★ dateModified についての事実誤認を訂正しました。 「フッターの年号を書き換えても dateModified は動きます」と書いていましたが、一般には成立しません。 dateModified は発行者が出力する値です。正しくは「CMS や実装によっては、実質を伴わない編集でも動くことがある」。結論は変わりませんが、理由が違いました。
    • 例文を 2 つ直しました。 「日本の消費税率は 10%」→「日本の消費税の標準税率は 10%」（標準税率 10% / 軽減税率 8% の複数税率です）。「公開が昨日、キャンペーンは明日まで。今日の時点で失効」→「公開が 3 日前、キャンペーンは 8 月 10 日まで」（昨日から見た「明日」は今日なので、時間の計算が合っていませんでした）。有効性を主題にする記事の例文が不正確では話になりません。
    • Baidu の研究の書誌を Crossref で確認しました。 Proceedings of the 49th ACM SIGIR Conference、pp. 4523–4527、DOI 10.1145/3805712.3808457。ただし Industry Track かどうかは確認できていないので書きません。 arXiv の注記は「Accepted at SIGIR 2026」までで、ACM の該当ページは当方の取得に 403 を返します。
    • 同じ型を主題で掃きました。 Zhen らの研究を引くもう 1 本（[情報環境の記事](/articles/information-environment)）は同じ誤りをしていませんでした — 「引用プールに入ることと回答に出ることは別」と正しく書いています。誤りはこの記事だけでした。
22. 2026.08 第55版2026-08-13臨時改訂根拠表現スコアに影響なし

    エンジン差の記事で、測っていない組を主語にしていた

    10

    • スコアは変わりません。 Visibility は未実装のままです。
    • ★ 記事のタイトルが、証拠の射程を超えていました。 「ChatGPT に強いサイトは Google AI Mode にも強いのか」としていましたが、この記事が引く 3 つの査読済み研究は、いずれも Google AI Mode を測定していません。 ChatGPT の消費者向け検索 UI と AI Mode を直接突き合わせた研究もありません。タイトルを「AI 検索ごとに、情報源はどれだけ違うのか」へ変更し、冒頭に「この記事が直接答えられる範囲」を置きました。 言えるのは「あるシステムでの選ばれやすさが別のシステムへ移ると仮定する根拠がない」までで、2 製品間の移り方の比率ではありません。
    • ★ Google-Extended の説明に誤りがありました。 「Google-Extended のブロックが検索順位に影響しないという Google の説明と本観測は矛盾しない。対象が検索順位ではなく AI Overviews の取得だから」と書いていました。これでは Google-Extended が AI Overviews の取得を制御しているように読めます。制御していません。 公式仕様が制御するのは学習と Gemini Apps / Vertex AI の grounding で、Google Search への掲載にもランキングにも影響しません。AI Overviews と AI Mode は Google 検索の機能です。
    • 原論文自身も同じことを書いていました。 「Google further clarifies that this will not affect a websites' ranking in Google Search results, nor does it impact the AIO's access to this content」。したがってこの観測は機構ではなく相関として扱います。なお論文は無統制ではなく、Tranco 順位のビンと 17 の Cloudflare ドメイン分類を含む線形確率モデルで推定しています。それでも観測研究であり、公式仕様上そもそも参加の制御ではありません。
    • ★ この誤りは[この記事](/articles/cross-engine-sources)だけにありました。 [クローラの記事](/articles/ai-crawlers)と [LLMO の記事](/articles/llmo)では以前から正しく書いており、同じ仕様の説明が記事間で食い違っていました。 仕様の正本を持つ台帳を必ず参照します。
    • ★ 「403 で確認できなかった」を解消しました。 ChatGPT がプロンプトを検索クエリへ書き換えることについて、根拠のページが 403 を返すとして記述を落としていました。403 は取得側の問題でした。 取得手段を変えたところ本文を確認でき、公式ヘルプの「ChatGPT search typically rewrites your query into one or more targeted queries that it sends those providers」を採用しました。ただし Google の Query Fan-out と同一視しません。
    • Grossman らの実験設定を精密化しました。 「Google 社内の 3 つの面どうし」と書いていましたが、ブラウザ上の 3 画面を並べたわけではありません。 SERP と AI Overviews は SerpAPI 経由、Gemini は消費者向けアプリではなく、Grounding with Google Search を有効にした Gemini 2.5 Flash API（Thinking off / システム指示なし）です。「同じ Google ですら大きく違う」という結論は変わりませんが、「Gemini アプリを開いたときに起こること」としては読めません。
    • ★ この記事は自分の原則を前半で破っていました。 後半で「引用しか観測していない研究から内部の取得集合を推定しない」と書きながら、前半では論文の用語 retrieved sources をそのまま「取得された情報源」として繰り返していました。SerpAPI から観測できるのは利用者へ返された一覧であり、内部の候補取得集合の全体ではありません。 論文の用語と観測層を分けました。
    • ★ 同じ型を主題で掃いたところ、[AAO の記事](/articles/aao)にも 403 で落としていた逐語が残っていました。 そちらも取得でき、読んで初めて分かった区別がありました。 OpenAI は「Instant Checkout items are not preferred in product results」としつつ、同じ商品を複数の販売者が扱う場合の販売者の順位づけでは「whether Instant Checkout is enabled」を考慮要素に挙げています。 ランキングは 2 つあります。 以前の本文は「実装は掲載に一切関係しない」に寄っていました。どちらの方向にもまとめません。
    • ★ Strauss らを全文確認へ上げ、観測層をもう 1 段深くしました。 「abstract のみ確認」としていましたが、現在は Cambridge University Press で全文が公開されています（Data & Policy, Volume 8, 2026, e15）。全文には重要な限定があり、著者らは「models appear to selectively disclose which websites they visit」とし、この選択的なログ開示自体が独立監査を不可能にする不透明性だとしています。したがって「34% が取得していない」ではなく「公開されたログ上で明示的な取得が確認できなかったのが 34%」です。引用は取得の全体ではない。開示されたログも取得の全体ではない。
23. 2026.08 第54版2026-08-13臨時改訂根拠表現スコアに影響なし

    標本設計の記事で、表の数字を 100 倍間違えていた

    10

    • スコアは変わりません。 Visibility は未実装のままです。
    • ★ 重なりゼロ率を 35% と書いていましたが、正しくは 0.35% でした。100 倍の誤りです。 完全一致率も 7% ではなく 0.07% です。表のこの 2 列はパーセントで、単位は表ではなく本文に書かれていました — 「The identical citation rate ... ranges from near-zero for Gemini (0.01-0.10%) to 3-8% for SearchGPT and Perplexity. The zero-overlap rate is highest for SearchGPT (6-9%) and lowest for Perplexity (1-2%)」。
    • 訂正すると、研究の示唆はむしろ正確になります。 典型的なのは「毎回まったく別の集合になる」ことではなく、部分的には重なるが集合全体としてはかなり入れ替わる状態です。中央値 0.31 はそれを表しています。35% と読むと「3 回に 1 回はまったく別」になり、同じ表の中央値 0.31 と噛み合いません。内部の整合を自分で検算していませんでした。
    • ★ n を「クエリの種類数」と説明していたのも誤りでした。 1 回の収集で使うクエリと応答の観測数です。同研究はトピックごとに 200 件のうち一意 152〜185 件で、重複を意図的に残しています（「よく生成されるクエリは、よく尋ねられるクエリに対応しているはず」という理由）。SILVE の 3 軸へ他者の n を直接対応させないでください。
    • 引用普及率の必要数を訂正しました。 SearchGPT n ≈ 60〜80、Perplexity n ≈ 100〜140、Gemini n ≈ 140〜150 です。Perplexity に 140〜150 を当てていたのは Gemini の値でした。なお論文の直後の要約文は後 2 者をまとめて「nearly twice as many」と丸めており、原典内部に記述の揺れがあります。表には詳細記述の値を採ります。
    • 「信頼区間は非定常性を扱わない」を射程へ戻しました。 言えるのは「この論文の応答単位のブートストラップ区間は、標本が交換可能で定常であることを前提としているため、標本内で分布が動いていると不確かさを過小評価し得る」までです。信頼区間という手法一般へ広げません。
    • Grossman らの書誌を更新しました。 「SIGIR 2026 採択・刊行前、原典は開いていない」としていましたが、現在は Proceedings of the 49th ACM SIGIR Conference、2026 年 7 月 20〜24 日、DOI 付きで収録されています。
    • 著者の役職を「確認できなかった」としていたのを更新しました。 IQRush の公式サイトで Chief Data Scientist と確認できます。利害を記録する判断自体は変えません。
    • 高頻度標本について、論文内部の矛盾を台帳に残しました。 実験設計では 3 プラットフォームを挙げながら、Limitations では「Gemini was excluded from the ten-minute interval experiment due to API rate limits」としています。著者側の整合性の問題なので、SILVE 側で解決せず、矛盾があること自体を記録します。
    • ★ VISIBILITY_SAMPLING.md に S8〜S10 を追加しました。 表の数字は単位を本文で確かめる / 標本サイズの n が何の数かを確かめる / 論文内部の矛盾は解決せずに記録する。 今回の 3 つの誤りは、いずれも表だけを見て本文を読まなかったことが原因です。
24. 2026.08 第53版2026-08-13臨時改訂分類根拠表現スコアに影響なし

    可視性の分類を、測定モデルの記事とそろえた

    11

    • スコアは変わりません。 Visibility は未実装のままです。
    • ★ 同じ Visibility の分類が、2 本の記事で食い違っていました。 [測定モデルの記事](/articles/measurement-layers)は Impression / Citation / Mention / Recommendation / Selection、この記事は Mention / Citation / Recommendation / Selection / Action としていました。Impression が落ちて Action が入っていました。
    • Impression を戻しました。 Google が 2026 年に公式データを提供し始めたのがまさにインプレッションなので、可視性のベクトルから落とす理由がありません。
    • ★ Action をベクトルから外しました。 Action は露出ではなく一段下流の実行です。3 つに分けます — Visibility（Impression / Mention / Citation / Recommendation / Selection）/ Execution（Action）/ Outcome（Transaction / Conversion / Revenue）。これで[エージェント対応の記事](/articles/agent-readiness)の Agent Interaction / Human Handoff / Task Outcome ともつながります。
    • Framework Record の「Action / Transaction」も分けました。 本文で「行動が発生したことと取引が完了したことは別」と書きながら、まとめで結合していました。空室確認まで進んで認証で人へ返した場合、Action は成立しても Transaction は成立していません。
    • ★ 「Citation ≠ Answer Influence も提供元が明記している」は言い過ぎでした。 提供元（Microsoft）が明記しているのは Ranking / Authority / ページの重要度 / 掲載位置ではないという範囲です。Citation ≠ Answer Influence は研究上の区別で、しかも吸収スコア自体が代理指標です。帰属を分けました。
    • ★ 「生成 AI の並び順を順位と呼ばない」を面ごとに限定しました。 原則は維持しますが、提供元が明示的にランキングと定義している面はあります（OpenAI は商品の結果を利用者との関連性で順位付けするとし、販売者の一覧も在庫・価格・品質・主たる販売者かどうかで順位付けすると説明しています）。自由生成の並び順を勝手に順位と読み替えない／提供元が定義している面はその面固有のランキングとして扱う、に分けました。
    • ★ 「57.8% が Web 検索を起動しなかった」を訂正しました。 原論文の逐語は「ChatGPT activates web search only for specific queries, leaving 57.8% of its runs with zero citations」です。観測されたのは引用がゼロだったことで、検索の非起動は著者らの説明です。 これまでレビュー経由で引いていたので、一次資料（PDF）へ差し替えました。
    • その原論文の利害も記録しました。 筆頭著者に「Affiliated with Aurora Intelligence」の脚注があり、同社は AI 可視性 / GEO の測定を扱う事業者です。論文の主題と事業領域が重なるので、独立性の評価として残します。
    • 「Readiness はサイトを検査すれば分かる」が戻っていました。 2026.08.52 で直した定義と食い違っていたので、公開サイトの取得だけでは観測できない Readiness の項目もある（Search Console の生成 AI 掲載設定など）に揃えました。
    • EC の記述を 2026.08.52 の結論に揃えました。 「引用が多くても候補に残らなければ成果につながりません」→「購入や選択を目的の指標にするなら、引用が多いだけでは足りません」。「引用に価値がない」とは書きません。
25. 2026.08 第52版2026-08-13臨時改訂根拠表現スコアに影響なし

    測定モデルの記事を訂正した（同じ提供元でも面ごとに数え方が違う）

    10

    • スコアは変わりません。 Visibility は未実装のままです。
    • ★ Google のインプレッションの集計規則を、Search と Discover で取り違えていました。 「同一サイトの結果が 2 つ出ても合計は 1」と Google 全体の規則のように書いていましたが、それは Search 向けレポートのグラフの話です。Discover 向けはすべてページ単位で、同一プロパティの複数結果をそれぞれ計上します。 規則が逆です。
    • Search 向けでも、グラフと表で違います。 国・デバイス・日付はプロパティ単位、ページ別だけはページ単位で、合計が食い違うことがあるとヘルプ自身が明記しています。次元も違い、Discover 向けにデバイスの次元はありません。
    • この記事の主題そのものでした。 「指標名ではなく定義を見る」と書いておきながら、同じ提供元の中で定義が分かれていることを見落としていました。 比較表を Search / Discover / Bing の 3 列に分けています。
    • ★ 「両社ともランキングではないと明記」も訂正しました。 明記しているのは Microsoft だけです。Google の生成 AI レポートは順位の指標を提供していませんが、「この数値はランキングではない」という否定の明記はヘルプ本文に見当たりません。 「Google が明記している」ではなく「順位の指標が提供されていないので順位として扱わない」と書きます。
    • ★ Readiness を「いつ実行しても同じ結果」と書いていました。 決定論的なのは採点であって、Web ではありません。 HTTP の応答・CDN や WAF・ボット対策・動的生成・A/B テスト・地域差・レンダリング・HTML の変更で入力は変わります。「同じ入力のスナップショットと同じ基準なら、判定は同じ結果を返すよう設計している」に直しました。
    • ★ Readiness を「表示されるための条件」と書いていたのも精密化しました。 測っているのは参加の資格・利用可能性・機械による解釈を支える事前条件と補助的なシグナルです。すべてが「満たさなければ表示されない必要条件」ではありません。 あわせて、Readiness に属するのに公開サイトからは観測できないもの（Search Console の生成 AI 掲載設定）があることも明記し、接続しない限り採点しないとしました。
    • Watanabe と Nakayashiki の研究について、著者 2 名が Glasp Inc. 所属で評価対象が自社ドメインであることを明示しました。 自社ログを使える強みと、自己評価であることの制限を両方書いています。対照群が対応づけられていないこと（論文自身が妥当性への脅威として明記）と、施策に新規ページ生成が含まれコーパスの規模自体が変わっていることも追記しました。
    • 「3.5 倍分まで成果として数えてしまう」を引き算ではなく比に直しました。 どちらも増加の倍率なので 6.1 ÷ 3.5 ≒ 1.75 倍、中断時系列の水準の跳ね上がりが 1.82 倍です。共通の追い風は乗法的に混ざります。
    • Bing の grounding queries が全量ではなく標本であることを追記しました。 「Bing が内部クエリを開示している」ではありません。[Query Fan-out の記事](/articles/query-fanout)の「内部クエリは観測できない」と矛盾しません。
26. 2026.08 第51版2026-08-13臨時改訂根拠表現スコアに影響なし

    Query Fan-out の記事で、Google の主張の射程を戻した

    7

    • スコアは変わりません。 Fan-out は最初から採点していません。
    • ★ 「仮に意図が純粋でも効果が否定されています」は言い過ぎでした。 Google は確かに an ineffective long-term strategy としていますが、挙げている理由は「a high quantity of pages doesn't make a website higher quality or more relevant to users」です。否定されているのは「ページ数を増やすこと自体」が品質や関連性の向上につながるという考え方であって、本当に別々のユーザーの必要に応える独立したページを作ることまでではありません。 「ページ数を増やすこと自体を根拠にはできない。別ページにするならそれぞれに独立したユーザー価値が要る」に直しました。
    • スパムポリシー違反の条件節は元から保持していました。 「主として順位や生成 AI の回答を操作するため」という条件は落としていません。今回直したのは、その後ろの「効果」の話の射程です。
    • 検索回数について言えることを分けました。 確認できるのはモデルの更新で変わり得ることまで（Gemini 3 で「以前より多くの検索を実行できる」）。質問ごとの回数も、AI Overviews と AI Mode の回数差も未公開です。「質問・モデル・体験によって変化する」と一括りに書いていました。
    • Search Console の生成 AI レポートを面ごとに分けました。 Search 向けと Discover 向けは別のレポートで、次元も同じではありません（Discover 向けにデバイスの次元はありません）。いずれにもクエリの次元は無いという結論は変わりません。
    • ★ 小規模・専門サイトの機会を、Google の事実と SILVE の含意に分けました。 Google が述べているのは「従来の検索より幅広く多様な有用リンク」「新しい探索の機会」「これまで見逃していたコンテンツを見つけられる」までです。「主要キーワードで上位にいなくても supporting source として発見される」は SILVE の含意で、従来の検索順位との関係は公開されていません。
    • 「完全一致は要求されていない」を Google の言葉に寄せました。 「AI システムは同義語や求めていることの一般的な意味を理解し、まったく同じ語を使っていないコンテンツとも結び付けられる」「ロングテールの語句が足りないと心配する必要はない」という説明です。掲載資格の話に聞こえる書き方を避けました。
27. 2026.08 第50版2026-08-13臨時改訂根拠表現スコアに影響なし

    取得と引用の記事を訂正した（自分の原則を、引いている研究にも当てた）

    9

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ SAGEO Arena の対象文書の選び方を書いていませんでした。 論文は「Among the documents that reach the generation stage (i.e., ranked within the top-k at the reranking stage), we randomly select one as the target document」としています。つまり対象は、最適化する前から既に再ランキングの上位に入っていた文書です。 したがってこの研究が測っているのは「既に十分関連していた文書が、書き換えたあとも上流の可視性を保てるか」であって、未取得の文書が新たに取得されるようになるかではありません。
    • 「取得から測り直した」ことと「未取得からの参入を測った」ことは違います。 この記事が導入した「主張の段階と、資料が実際に測った段階を一致させる」という原則を、引いている研究自身にも当てた結果です。 そしてこの限定は、この記事の結論（商用プラットフォームを横断したオーガニックな発見可能性の改善は未確立）と正確に一致します。
    • ★ 「+22% / +2.72」は「構造化情報だけ」の条件の値でした。 「本文だけでなく構造化情報へ広げると +22%」と書いていましたが誤りです。Table 2 の 3 条件は、本文だけ −9% / −16% / −6%、構造化情報だけ +22%（ΔRank +2.72）/ −17% / +2%、両方 +15% / −25% / −5%。両方を最適化した条件がいちばん再ランキングを悪化させています。 取得が改善しても下流で失う、という構造はこの記事の主張をさらに強めます。
    • ★ ここでいう「構造化情報」は schema.org ではありません。 論文が扱っているのは 題名・メタディスクリプション・見出し（H1〜H6）・schema / JSON-LD をまとめた複数フィールドで、LLM がそれらを書き換えています。「schema.org を足したら取得が 22% 改善した」という研究ではありません。 論文自身も理由をクエリ関連語の密度と語彙の重なりに帰しています。[機械可読データの記事](/articles/machine-readable-data)の「構造化データを直接的な順位要因として扱う根拠は確認できていない」と矛盾しません。
    • 簡略式であることを明示し、段階どおりの式を併記しました。 P(引用) = P(検索が起動) × P(取得 | 起動) × P(文脈に残る | 取得) × P(引用 | 文脈)。SAGEO の結果は「取得が改善しても再ランキングで落ちる」ことを示しているので、この 2 段は分けて見る必要があります。
    • 45 研究のレビューの位置づけを明記しました。 単著のプレプリントによる critical scoping review であり、systematic review でも meta-analysis でもありません。 査読論文・採択論文・ワークショップ論文・プレプリントが混在しています。結論を否定する話ではなく、証拠の水準を正しく表示するためです。 なお 115.1% / −30.3% はレビューを経由せず GEO 原論文の Table 2 で直接確認できます。
    • 252,000 試行の実験も固定文脈であることを追記しました。 2 件の候補をあらかじめ文脈へ入れて、どちらが最初に引用されるかを測っています。 「関連性と位置が最も安定」はその範囲の話で、オーガニックな取得でも同じ効果が出るという意味ではありません。
    • 「『最大 40%』の唯一正しい読み方です」を「この論文から直接支持される読み方です」に変えました。 解釈に「唯一」を付けません。
28. 2026.08 第49版2026-08-13臨時改訂根拠スコアに影響なし

    「403 で取得できない」は、こちらの取得手段の問題だった

    8

    • スコアは変わりません。本文の主張も変わりません。 確認の程度が上がりました。
    • ★ 2 版にわたって「help.openai.com は 403 を返すので確認できない」と書いていましたが、誤りでした。 WebFetch と curl は 403 を返しますが、Node の fetch では 200 で取得できます。 相手の制限ではなく、こちらの取得手段の問題でした。
    • 逐語で確認できたので、記録を partial から full_text_verified へ上げました。 ChatGPT agent のページ冒頭に「ChatGPT agent is no longer available. Use ChatGPT Work for longer, multi-step tasks and finished deliverables. For supported browser workflows, see Using cloud browser in ChatGPT.」。Cloud browser のページに「ask for confirmation before taking an action that may be difficult to undo or create a financial, legal, account, or other real-world commitment」「does not accept credentials, use autofill or password managers, sign in to websites, or complete payments. If a site requires one of those steps, the task stops」。
    • ★ SOURCE_POLICY.md に手順を書きました。 「取得できない」と結論する前に、別の取得手段 → 一次形式（HTML ではなく PDF、raw ではなく blob）→ アーカイブの順に試します。この 3 つはいずれも今回の一連の作業で実際に効いた手順です（v2 の付録は PDF で、Lighthouse の実装は blob で、OpenAI のヘルプはランタイムの fetch で確認できました）。
    • そのうえで本当に取得できないなら、確認の程度を下げて記録します。 partial / access_restricted を使い、confidence を high にせず、採点に使いません。何も書かないか、確認済みとして書くかの二択にしません。
    • なお ChatGPT agent のページは、冒頭で提供終了としながら下部に旧 agent mode の使い方が残っています。 引用するときは冒頭の現在の状態を採り、下部は「旧 ChatGPT agent の仕様」として扱います。
    • ★ 同じ手段で、別の未解決項目も閉じました。 2026.08.32 で「確認できていない」と記録していた「OAI-SearchBot を拒否したサイトのリンクが表示され得る経路」が、Publishers and Developers FAQ で逐語確認できました。第三者の検索プロバイダから URL を得た場合や、他のページのクロールから URL を得た場合にリンクとページの題名だけを表示することがあり、止めたい場合は noindex メタタグを使うよう案内されています。
    • ★ そこにねじれがあります。 同じ文書が「メタタグを読むには、そのページのクロールが許可されている必要がある」とも書いています。robots.txt で塞ぐと、止めるための noindex を読ませられません。 ai-pipeline の記事に追記しました。
29. 2026.08 第48版2026-08-13臨時改訂根拠表現スコアに影響なし

    旧 ChatGPT agent が提供終了していることを反映した

    8

    • スコアは変わりません。 採点には使っていない記述の更新です。
    • 前版で「現在の提供状況は確認できていない」としていた件を更新しました。 旧 ChatGPT agent は提供終了しており、OpenAI は長い複数ステップの作業を ChatGPT Work へ、対応するブラウザのワークフローを Cloud browser へ案内しています。
    • 現在の Cloud browser の仕様で、人間への引き継ぎを書き直しました。 取り消しが難しい操作や金銭・法的・アカウント上の約束を伴う操作の前に確認を求め、資格情報を受け取らず、サインインや決済の完了は行わず、それらが必要な場面ではタスクが停止します。 引き継ぎは例外ではなく設計上の既定の動作です。
    • ★ 前版で導入した 3 層が、現在の仕様でより直接に説明できるようになりました。 ログインの境界まで正しく到達して停止した場合、Agent Interaction としては正常な引き継ぎですが、購入完了を目的とするなら Task Outcome は未達です。
    • 確認の程度は下げて記録しています。 help.openai.com は当方の取得に 403 を返すため、提供元のページ本文を逐語で確認したわけではありません。 検索結果に現れた本文と、外部レビューによる同ページの取得報告という 2 つの経路が一致したことによる確認で、台帳では verificationDepth: partial / retrieval.status: access_restricted としています。確信度は medium に留め、採点には使いません。
    • ★ 前版で「未確認」とした判断には、こちら側の誤りも混ざっていました。 記事 ID を推測して別のページを叩いており、403 の原因の一部はそれでした（正しい ID は検索経由で判明）。取得できないことと、URL が間違っていることを混同していました。
    • SOURCE_POLICY.md に「取得できない資料は、確認の程度を下げて記録する」を追加しました。何も書かない / 確認済みとして書く / 確認の程度を下げて書くの 3 択のうち、どれを選んだかを残します。URL を推測しないことも明記しました。
    • 同ページは冒頭で提供終了としながら下部に旧仕様の説明が残っているとの指摘があるため、引用するときは冒頭の現在の状態を採り、下部の記述は「旧 ChatGPT agent の仕様」と明示します。
30. 2026.08 第47版2026-08-13定期改訂採点根拠表現

    観測できなかった項目を満点にするのをやめた（チェックリスト v5）

    15

    • ★ 同じサイトでもスコアが動きます。 操作要素・入力欄・画像が 1 件も見つからないページでは、これまで該当項目を満点にしていました。これをやめ、分子からも分母からも外します。 該当するサイトでは分母が変わるため、点が上下し得ます。
    • ★ なぜ満点をやめたのか。 「操作要素が無いページに『名前が無い』という欠点は存在しない」という理屈自体は正しいのですが、見つからないことと、無いことは違います。 SILVE は静的 HTML を解析するので、JavaScript で後から作られる要素が見えません。 SPA の骨組みだけの HTML では操作要素も入力欄も 0 件に見えますが、それは欠点が無いのではなく観測できていないのです。観測できなかったものを満点に変換すると、測れていないサイトほど高得点になります。
    • しかも記事自身がそれを書いていました。 「静的 HTML 解析では JS で後付けされた操作要素が見えない。検出数は下限値」と明記した数行前で、その欠測を満点にしていました。
    • 0 点にもしません。 0 点にすると「満点を取りようがない項目」になり、根拠のないもので減点することになります。版ごとの採用状態が分母から外すのと同じ扱いを、実行時にも適用します。
    • 理由を 2 つに分けます。 本文が静的 HTML から取れているページで 0 件なら対象なし、本文自体が取れていないなら判定不能。結果画面には「この項目はスコアの計算から外しています（満点にはしていません）」と出します。
    • ★ 横断の原則にしました。 Not observed ≠ Pass. Not applicable ≠ Not observable. 静的解析だけで判定する以上、この区別を全項目で守ります。新しい検出器を書くときは、0 件の扱いを必ずこの 3 分岐で書きます。
    • ★ この版を指定しても、古い挙動は復元されません。 検出ロジックはコード側にあり、版へスナップショットしていないためです（ページ数は版に固定したので復元されます）。既知の設計上の制約で、この版で新しく生じたものではありません。 したがってこの版の役割は挙動の固定ではなく、採点方法が変わった日を記録に残すことです。過去の結果を再現したい場合は、当時の診断結果そのものを見てください。
    • 実走で確認した影響（cybozu.co.jp / 10 ページ）: agent.form_labels が対象なし判定になり、41 点 → 39 点。満点で分母に入っていたものが分母から外れた分の下落で、サイトの実態は変わっていません。
    • 分母がサイトによって変わります。 これは意図した挙動です。「その項目が成立しないサイト」と「その項目で失敗しているサイト」を同じ分母で比べるほうが誤りだからです。ただし前回と適用範囲が変わった場合、その差はサイト側の変化として出ます。ページ数のときと同じで、範囲の変化と実態の変化は別なので、比較を読むときは注意してください。
    • ★ agent.layout_stability を「Provisional・配点しない」と書いていたのは誤りでした。 実装は adopted で重み 2 です（確信度 low・直接性 supporting）。同じ記事の採点表と Framework Record が食い違っていました。CLS の実測ではなく、その原因になりやすい要素を静的に数えた限定的な代理指標であることは変わりません。
    • ★ 現在のスコアが測っている範囲を明示しました。 「Agent Readiness とは完了できるか」と定義しながら、採点しているのは静的・決定論的に観測できる技術的前提条件の一部です。タスクの実行テストは採点していません。定義と実装の距離を書いていませんでした。
    • 「認証で止まっても成功」を 3 層に分けました。 Agent Interaction（引き継ぎの境界まで到達できたか）/ Human Handoff（引き継ぎが成立したか）/ Task Outcome（目的が達成されたか）。購入完了が目的なら、人間へ引き継いだ時点で Task Outcome は未達です。
    • W3C の Using ARIA が 2026 年 2 月 24 日に Discontinued Draft になっていました。 「four rules of ARIA は歴史的な参照のために残すが、この文書の作業を続ける予定はない」とされ、今後の指針は ARIA Authoring Practices Guide を見るよう案内されています。原則が否定されたわけではありませんが、現行の規範資料としては ARIA in HTML（W3C 勧告）と APG を併読します。
    • セマンティック HTML について「Google がランキング要因ではないと位置づけている」を弱めました。 ガイドが述べているのは「専用要件ではない」「明示している利点はスクリーンリーダー等による解析・移動のしやすさ」までで、順位要因ではないと明示的に否定しているわけではありません。
    • 旧 ChatGPT agent の説明を現在形で書くのをやめました。 提供終了し後継へ移行したとの指摘を受けましたが、help.openai.com は当方の取得に 403 を返すため一次資料で確認できていません。 したがって2025 年時点の記述として扱い、現在の提供状況は未確認と明記します。
31. 2026.08 第46版2026-08-13臨時改訂根拠分類表現スコアに影響なし

    エンティティの記事を訂正した（外部の証拠は Visibility ではない）

    9

    • スコアは変わりません。 重みの記載を実装に合わせただけで、実装側は動かしていません。
    • ★ 外部での表現（層 5）を Visibility 側に置いていたのは、自分の定義との食い違いでした。 MEASUREMENT.md の Visibility は「実際に使われた・表示されたか」の観測値です。Wikidata に項目がある / 独立媒体で説明されている、という状態は、AI が実際にその企業を表示・引用・推薦したことではありません。 層 5 を External Evidence / Ecosystem Presence として独立させ、Entity Visibility（AI が実際に認識・引用・推薦したか）と分けました。「自分で制御できない＝ Visibility」ではありません。 制御可能性の軸と、観測対象の軸は別です。
    • ★ Knowledge Graph Search API を採点しない理由が違っていました。 「企業名で一致を探すのは提供元の想定を超えている」と書いていましたが、Google は典型的な用途として「条件に一致する最も著名なエンティティのランク付きリストを取得する」を挙げており、名前で引くこと自体は想定の範囲内です。 正しい理由は「この API に存在することが Entity の確立や Readiness に対応するという公式の根拠が無い」です。読み取り専用・本番依存に不向き・移行案内は、それとは別に道具として過信しない理由です。結論は同じでも、理由が違えば別の場面で誤用します。
    • ★ authority.entity_consistency の重みを 6 と書いていましたが、実装は 3 です。 実効重み 91 のうち約 3.3% です。最初に HANDOFF を直したときに、記事と正本を掃いていませんでした。
    • あわせて「なぜ 3 点なのか」を書きました。 直接性が inferred である一方、Google は「Organization の name / alternateName をサイト名と揃える」「url は組織を一意に識別するのに役立つ」「iso6523Code や naics は裏側で曖昧さの解消に使われる」と述べており、曖昧さの解消が重要であること自体は支持されています。 ただし「正式名称・通称・英語・カタカナの混在」という日本語固有の形に対応する海外の一次資料はありません。方向は支持されているが項目の形は独自なので 3 に留めます。
    • そして「表記が複数あること」自体は減点していません。 判定は、申告された正式名称と別名に対して、サイト上の Organization 構造化データの名称がすべて一致すれば 2 点、一部なら 1 点、どれも一致しなければ 0 点です。alternateName として正常に併存している表記と、同一性が食い違っている状態を分けています。 測っているのは「表記の数」ではなく「申告と実装のずれ」です。
    • OpenAI の商品識別子を「GTIN / MPN が必須級」と書いていたのを訂正しました。 独自スキーマで必須なのは商品 ID・ブランド・販売者名で、GTIN と MPN は任意です。GTIN か MPN が必要になるのは Google 互換の経路で identifier_exists を省略または yes にする場合という条件付きです。2026.08.43 で直した内容が、この記事に届いていませんでした。
    • 「Knowledge Graph にできるのは公開だけ」を精密化しました。 Google は「コンテンツの所有者から直接、事実情報を受け取ることもある。ナレッジパネルをクレームした人が変更を提案する場合を含む」と述べています。任意のエンティティを登録できる公開の制度はありませんが、事実情報を渡せる経路はあります。採否と統合は Google 側が決めます。
    • 見出し「識別子は名前より強い」を「識別子は、名前だけでは残る曖昧さを減らせる」に変えました。 重み付けのように読めるのを避け、この記事の原則（強くするのではなく曖昧でなくする）に揃えました。
32. 2026.08 第45版2026-08-13臨時改訂根拠表現スコアに影響なし

    llms.txt の記事を訂正し、横断修正の掃き方そのものを直した

    8

    • スコアは変わりません。 llms.txt は配点対象外のままです。
    • ★ Lighthouse は「取得できたかどうか」だけを見ているのではありませんでした。 監査の実装（core/audits/agentic/llms-txt.js）を読むと、2xx で取得できた場合に中身を検査します。H1 が 1 つ以上ある / Markdown 形式のリンクが 1 つ以上ある / 50 文字以上あるの 3 つで、1 つでも欠けると失敗です。5xx と取得失敗は失敗、4xx（404 を含む）は対象外。
    • ★ とくにリンクの検査は Markdown 記法を要求します。 [テキスト](URL) の形でないと数えられないので、裸の URL を並べただけでは「リンクが 1 つも無い」と判定されます。 内容として正しくても落ちます。
    • Chrome の公開ドキュメントには、この中身の検査が書かれていません。 「404 は対象外、サーバエラーは失敗」という説明だけを読むと、取得できさえすれば通ると誤解します。判定の実体は実装側にありました。
    • 「サイトマップは全ページを列挙する」を、llms.txt 提案側の対比として限定しました。 Google はサイトマップを「重要だと考えるページやファイルを伝えるもの」と説明しており、全ページの列挙を要求していません。 提案側の枠組みを Web の仕様上の定義として書かないようにしました。
    • 「不正確な llms.txt は無いより悪い」が SILVE の推論であることを明示しました。 実験で確かめられた事実ではありません。提案側の利用モデル（llms.txt を小さく保ち、エージェントが必要なリンクをたどる）から導いた運用方針です。
    • ★ Google の生成 AI 掲載設定を、3 回目にしてようやく全記事へ反映しました。 この記事は「専用要件ではない」と書いており、2026.08.34 の「追加の技術要件」でも 2026.08.42 の英語原文でも網に掛かりませんでした。 今回は主題（AI Overviews / AI Mode の掲載資格に触れている記事）で掃き直し、9 本すべてに反映しました（ai-pipeline も未反映だったので追加）。
    • ★ 掃き方そのものを規則にしました。 SOURCE_POLICY.md を「語句ではなく主題で掃く」に書き換え、主題で候補を出す → 当該の主張をしているものへ絞る → 絞り込みの誤検出を 1 件ずつ潰すという手順と、記録には件数ではなく「どう探したか」を書くことを明記しました。探し方が弱ければ、件数は当てになりません。
33. 2026.08 第44版2026-08-13臨時改訂根拠スコアに影響なし

    Content API の終了日について、根拠を 1 つから 2 つにした

    4

    • スコアは変わりません。本文も変わりません。 台帳の根拠だけを増やしました。
    • 終了日の出典が正しいかの指摘を受け、再検証しました。 「リリースノートには月までしか書かれておらず、正確な日付は別ページにある」という指摘だったので、「月だけなら月だけと答えよ」と明示したうえで取り直しました。 結果、リリースノートのページ上部の警告ボックスに「Content API for Shopping will be sunset on August 18, 2026.」と日付まで記載されていることを確認しました。
    • ★ ただし指摘のとおり、別のページにも同じ日付がありました。 Google Ads Scripts の Advanced APIs のページに「Note: the Content API for Shopping will be sunset on August 18, 2026. Use the Merchant API, which is described in the previous section, instead.」とあります。どちらか一方に絞る理由が無いので、両方を根拠にしました。
    • SOURCE_POLICY.md に「同じ事実を述べる公式ページが複数あるなら、1 つに絞らない」を追加しました。1 つだけを根拠にすると、そのページが改稿された瞬間に根拠を失います。 他者と帰属が食い違ったときも、勝ち負けを決めずに両方を確認して両方を持ちます。
34. 2026.08 第43版2026-08-13臨時改訂根拠表現スコアに影響なし

    機械可読データの記事を訂正した（プロトコルの射程と、参加資格）

    7

    • スコアは変わりません。 構造化データの配点（7 / 91）も変えていません。
    • ★ 「Structured data ≠ AI ranking factor」という断定をやめました。 Google が明記しているのは「生成 AI 検索に構造化データは必須ではない」「専用の schema.org マークアップを追加する必要はない」までで、順位要因ではないと証明したわけではありません。 「構造化データを生成 AI 検索の直接的な順位要因として扱う根拠は確認できていない」に改めました。「証拠がない」と「存在しないことが証明された」を混ぜないという自分の規則に反していました。同じ理由で「AI 専用スキーマは存在しない」も射程を付けています（Google 検索の生成 AI 機能に出るために追加すべきものは無い）。
    • ★ 5 層目を「操作と取引」だけに置くのをやめました。 ACP は 2026 年 3 月に商品探索へ拡張され、UCP も catalog.search / catalog.lookup を capability として持ちます。プロトコルの射程と、あるプラットフォームの現在の実装は別です（2026.08.40 で SOURCE_POLICY.md に入れた規則）。層の名前を capability / 相互作用プロトコルに変え、7 段階との対応も「プロトコルの capability による」としました。この横断規則が、この記事にまだ届いていませんでした。
    • ★ OpenAI の商品フィードは、誰でも接続できるわけではありません。 導入ガイドは「Onboarding product feeds in ChatGPT is currently available to approved partners.」と明記しています。仕様が公開されていることと、接続できることは別です。 ここは事業者側で整えられる Readiness と、プラットフォーム側が決める参加資格の境目にあたります。
    • 「識別子・バリエーション・価格・在庫を必須級」を経路別に分けました。 OpenAI 独自スキーマでは商品 ID・価格・在庫が必須、バリエーション情報はバリエーションがある場合の推奨、GTIN / MPN は任意です。一方 Google 互換の経路では identifier_exists を省略または yes にするなら GTIN か MPN が必要です。「必須級」は、必須と推奨と条件付き必須を潰してしまいます。
    • ★ 層 4 の実装先が変わります。 Google の Content API for Shopping は 2026 年 8 月 18 日に終了し、Merchant API が後継です（公式リリースノートに「Content API for Shopping will be sunset on August 18, 2026.」。延長申請のフォームもあります）。この版の公開日から 5 日後です。 古い記事や社内手順が Content API を前提にしていないか確認してください。5 層モデル自体は変わりませんが、各層の具体的な実装は入れ替わります。層の名前で古びない書き方をし、具体名には日付を添えます。
    • 「Fresh before rich」の帰属を明確にしました。 これは SILVE の原則の名前であって、OpenAI の表現ではありません。 言えるのは「OpenAI の運用案内が SILVE の原則と整合している」までです。
35. 2026.08 第42版2026-08-13臨時改訂根拠表現スコアに影響なし

    Google の掲載条件の横断修正に、2 本の取りこぼしがあった

    5

    • スコアは変わりません。 記述の追加だけです。
    • ★ 2026.08.34 で「22 本すべてを掃いた」と書きましたが、2 本残っていました。 ai-crawlers と cross-engine-sources に、Search Console の生成 AI 掲載設定（Search generative AI control）が入っていませんでした。両方に追記しています。
    • 原因は grep のパターンでした。 日本語の「追加の技術要件」で掃いたのですが、この 2 本は英語の原文を引用していました（There are no additional technical requirements.）。訳文だけで掃いたので、原文のまま置かれている記述が網に掛かりませんでした。
    • SOURCE_POLICY.md に「横断修正は、原文の言語でも掃く」を追加しました。引用の多い記事ほど、原文のまま置かれている可能性が高いこと、掃いた結果は「0 件だった」ではなく「どのパターンで掃いたか」を残すことを明記しています。
    • ai-crawlers では、この設定が「4 つの制御」に収まらない例だと書き足しました。 クローラでもトークンでもなく、用途を制御する第 3 の面です。2026.08.41 で入れた Fetcher / Token / Meta directive の整理に、さらに Search Console のようなサイト単位の設定が加わります。
36. 2026.08 第41版2026-08-13臨時改訂根拠分類表現スコアに影響なし

    AI クローラの分類を訂正した（制御は User-Agent とは限らない）

    11

    • スコアは変わりません。 追加した用途は採点対象外（notScoredFor）にしているため、実効重みも判定も動きません。
    • ★ Bingbot の「学習」を「—」としていたのは誤りでした。 Microsoft は学習専用のボットを持ちませんが、Bing が取得したコンテンツを生成 AI の基盤モデルの学習に使う経路があり、制御は robots.txt ではなく robots meta タグにあります。 指定なし＝回答にも学習にも使われ得る / nocache＝回答には URL・題名・スニペットのみ、学習にもその範囲だけ / noarchive＝回答に含まれずリンクもされず、学習にも使わない / 両方＝nocache 扱い。いずれも通常の検索結果には出ます。
    • ★ これは OpenAI との決定的な違いです。 OpenAI は「OAI-SearchBot を許可し GPTBot を拒否」で学習と掲載を分離できますが、Microsoft では学習を完全に断つ noarchive が Bing Chat からの除外とリンク停止を伴います。 つまり Microsoft では「学習は拒否、AI の回答には出たい」を完全な形では実現できません。 「検索と学習を分離できるか」の表に Microsoft を追加しました。
    • ★ 枠組みそのものを一段広げました。 Bot × Capability という整理は、暗黙に「用途ごとに User-Agent が分かれている」ことを前提にしていました。Microsoft はそうではありません。 BOT_CAPABILITY.md に「制御は User-Agent とは限らない」を足し、記録すべきは Fetcher / Token / Meta directive × Capability の 3 つ組だと明記しました。ボット名で用途を分けられないからといって、用途が無いことにはなりません。
    • ★ 「モデル学習を塞いだときに失うもの：なし」を訂正しました。 それは SILVE の検索 Readiness に配点しないという意味であって、何も失わないという意味ではありません。 Google-Extended の拒否は Gemini の学習だけでなく Gemini Apps と Vertex AI の grounding も同時に止めます。Microsoft の noarchive は学習と Bing Chat 掲載の両方を止めます。表の列を「塞いだときの SILVE の採点」と「実際に失い得るもの」に分けました。
    • Meta-ExternalAgent の「検索・掲載」を ○ から △ にしました。 公式資料が述べているのは学習と製品改善のための直接索引までで、AI 検索での掲載・引用とは書かれていません。 もともと採点していない（notScoredFor）ので採点への影響はありません。直したのは表示上の分類です。
    • Perplexity の「そもそも学習に使っていない」を限定しました。 公式が述べているのは PerplexityBot と Perplexity-User を基盤モデルの学習のための収集に使わないということで、会社全体が Web の情報を一切学習に使わない、まではこの文書から言えません。
    • Googlebot の grounding を「—」から「○」にしました。 表の ○ は「その取得データがその用途に使われうる」という意味なので、Search インデックス経由で AI Overviews / AI Mode の grounding に使われる Googlebot は ○ です。 表の凡例にこの定義を明記しました（その User-Agent 自体が用途を制御するかどうかとは別です）。
    • CCBot の学習を ○ から △ にしました。 Common Crawl 自身が基盤モデルを学習しているわけではなく、公開データセットを作り、下流での学習利用は利用者次第です。事業者が自社の学習のために直接取得する GPTBot / ClaudeBot とは性質が違います。
    • 「4 つの制御」が概念上の整理であることを明記しました。 同じ指定名でも効果は事業者ごとに違います（nosnippet は Google では AI Overviews / AI Mode への直接入力を、Apple では AI 生成回答での文脈利用を止め、Microsoft では noindex / noarchive / nocache が学習と Copilot 利用に独自の意味を持ちます）。
    • 記事内で日付と版が食い違っていました。 冒頭は 2026-08-13 / 2026.08.38、Policy Record は 2026.08.29 / 2026-08-11 のままでした。揃えています。
37. 2026.08 第40版2026-08-13臨時改訂根拠表現スコアに影響なし

    ACO の記事を訂正し、「項目名から推測しない」の原則を精密にした

    11

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 「順位付けに使われるという公式記述は無い」は誤りでした。 OpenAI の Product Feed 仕様には Performance Signals という節があり、本文にこう書かれています — 「Share popularity and return-rate metrics where available. These signals can be used to enhance ranking and highlight high-performing products.」 popularity_score と return_rate については、順位付けや強調に使いうると提供元が明記しています。
    • ただし 4 項目をまとめて扱いません。 star_rating と review_count は別の Reviews and Q&A の節にあり、「信頼性を高め、購買判断を助ける」としか書かれていません。順位付けへの利用は同じ強さでは書かれていないので、分けて扱います。
    • ★ 原則は捨てず、精密にしました。 「項目名から効果を推測しない」は維持したうえで、こう言い換えます — 「項目名から推測しない。公式が用途を明記したものだけを、その明記された射程で採用する」。 popularity_score と return_rate についても、言えるのは「使いうると述べている」までで、重みも因果効果も非公開です。「入れれば上がる」ではありません。
    • この見落としの原因も記録しました。 表の行だけを見て「効果の記述は無い」と書いていました。表の上にある本文を読んでいませんでした。 SOURCE_POLICY.md に「仕様の項目名から効果を推測しない」として、「用途が書かれていない」と断定する前にその節の本文を読むことを明記しました。
    • ★ ACP の merchant discovery を、実装済みの仕組みとして書いていました。 /.well-known/acp.json を使う discovery の RFC は存在しますが Proposal / unreleased で、ACP 公式サイト自身が「We're working to create discovery mechanisms for AI platforms to identify businesses that have implemented ACP」としています。UCP の /.well-known/ucp は正式仕様なので、両者を並べて書けません。
    • OpenAI 独自スキーマの無条件必須項目を 14 から 15 に訂正しました。 return_policy を落としていました。
    • UCP の「Google が 3 つの技術評議会すべてで多数」を取り下げました。 現在の一次資料から再現できず、ガバナンス構造そのものが短期間で拡張しています（Tech Council は 2026 年 4 月に 16 席へ拡大し、分野別 council の形成も進行中）。時点を固定せずに「多数を占めている」と書くと、すぐ古くなります。
    • ★ 「Merchant Center が探索、UCP が取引」を Google の実装の話へ限定しました。 UCP の core concepts には catalog.search / catalog.lookup が capability として載っており、プロトコル自体は商品の探索も扱います。 ACP がチェックアウト中心から商品探索へ広がったのと同じ構図なので、SOURCE_POLICY.md に「プロトコルの射程と、実装の射程を分ける」として横断の規則にしました。「A を実装した」だけでは、どの段階に対応したのかが決まりません。
    • 「独立確認は存在しない」を射程へ戻しました。 用語を使っている独立媒体は複数あります。見つかっていないのは Wingo を命名者として独立に帰属する資料です。
    • 米国医療の Accountable Care Organization を確認済みにしました。 CMS の資料を取得できず未確認としていましたが、確認できました。ACO の略称衝突は Agentic Commerce Optimization / Ant Colony Optimization / Accountable Care Organization の少なくとも 3 系統です。
38. 2026.08 第39版2026-08-13臨時改訂根拠表現スコアに影響なし

    AAO の記事を訂正した（Lighthouse を「科学が確立した」方向へ読みすぎていた）

    9

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 「エージェント対応度は決定論的に測れる」は範囲が広すぎました。 Chrome は確かに「Lighthouse uses a set of deterministic signals ... reproducible and suitable for integration into CI/CD pipelines」と書いています。しかし同じページに「Why results fluctuate」という節があり、JavaScript による WebMCP ツール登録のタイミング / DOM の規模や複雑さの変化によるアクセシビリティツリーの構造変化 / 広告・寸法未指定の画像・後から挿入される要素によるレイアウトのずれが、結果を変動させ得るとしています。監査ロジックが決定論的であることと、観測結果が常に同じ値になることは別です。 測れるのはエージェントとのやり取りに関する一部の技術的 Readiness であって、サイト全体のエージェント対応度ではありません。
    • Chrome 自身の留保をもっと前面に出しました。 「The Agentic Browsing category and WebMCP support are experimental and based on proposed standards」「the current focus is to gather data and provide actionable signals rather than a definitive ranking」。Lighthouse に入ったことは、その項目が可視性を上げる証拠ではありません。
    • ★ 「このシリーズで唯一、具体的なシグナルを持つ」を撤回しました。 他の用語にも Googlebot・OAI-SearchBot・インデックス可能性・スニペットの資格・Search Console の生成 AI 掲載設定など、決定論的に確認できるシグナルは既にあります。 新しいのは「操作そのものを対象にした公式の監査が付いた」ことであって、シグナルの有無ではありません。シリーズを通した整合として、これは 1〜6 本目と食い違っていました。
    • ★ ACP と UCP の「保証しない」を分けました。 まとめでは「ACP / UCP を実装しても自動的に選ばれるわけではない（OpenAI が明記）」と書いていましたが、明記があるのは ACP 側だけです。 ACP 公式 FAQ は実装しただけでは商品が AI エージェントへ自動掲載されず各プラットフォームが参加方法を管理すると明記しています。UCP については「推薦順位を高める公式根拠を確認できていない」であって、「否定が明記されている」ではありません。 記事本文はこの区別を正しく書いていたのに、まとめだけが強くなっていました。
    • ACP の射程を 2026 年 3 月以降へ更新しました。 公開当初はチェックアウトと決済が中心でしたが、OpenAI は 2026 年 3 月に ACP を商品探索へ拡張し、あわせて初期の Instant Checkout が販売者に十分な柔軟性を提供できていなかったとして販売者自身のチェックアウトを使えるようにしています。この変化自体がこの記事の主題を裏づけます — 1 つのプロトコルの中でも、発見・選択・取引は別の問題として扱う必要があります。
    • 商品フィードを「構造化データ」と呼ぶのをやめました。 SILVE は構造化データを schema.org の意味で使っているので、機械可読な商品データ（商品フィード）と書き分けます。
    • Kalicube の既知の問題に 1 件足しました。 2025 年の Search Engine Land 記事の題名を「Search, answer, assistive: The new optimization approach」としていますが、実際は「Search, answer, and assistive engine optimization: A 3-part approach」です。公開日の誤り（February 17 / 実際は February 24）と同じ列に並べました。
    • 結論の位置を変えました。 「エージェント対応の科学が確立した」ではなく、「agentic Web の一部はすでに機械的に監査できる。ただし agent optimization 全体の科学は確立していない」が、現在の一次資料から言える限界です。
39. 2026.08 第38版2026-08-13臨時改訂根拠表現スコアに影響なし

    LLMO の記事を訂正した（資料に無い分類を帰属させていた／「完全に別系統」は言い過ぎ）

    9

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 資料に書かれていない分類を、その資料に帰属させていました。 「Search Engine Land のガイドは GEO＝検索の AI 回答に選ばれるか / LLMO＝モデルの内部知識の一部になるか、という位置づけを示している」と書いていましたが、現在のガイドを全文確認したところ、その分類は見当たりません。 実際のガイドは LLMO を「content / website / brand presence を最適化して AI 生成回答に出るための実践」と定義し、GEO との区分も対象とする面の違い（GEO は AI answer engine 全般、LLMO は conversational AI）として書いています。帰属を取り下げました。「整理が揺れている」という指摘自体は残ります（同じガイドに学習データ由来の説明と現在の可視性の説明が混在しているため）が、ガイドが 2 つを明示的に分類しているという意味ではありません。
    • 同ガイドを独立資料として扱うのをやめました。 Search Engine Land は Semrush 所有で、ガイド自身が「Unless otherwise noted, this page's content was written by either an employee or a paid contractor of Semrush Inc.」と開示しています。independence を independent から affiliated へ改めました。一方、2023 年 10 月の Kopp の記事は買収より前の公開なので、この所有関係を遡って適用しません。
    • ★ 「OpenAI の 3 つのボットは完全に別系統」を撤回しました。 設定が互いに独立していることは OpenAI 自身の記述ですが、同じ文書は「If your site has allowed both bots, we may use the results from just one crawl for both use cases to avoid duplicative crawling.」とも述べています。独立しているのは用途と robots.txt の設定であって、クロールの実装経路まで分離されているとは限りません。 分けるべきは「何に使われるか」であって、取得が物理的に別々に走ることではありません。この表現は 5 箇所（記事 3 本・レコード・robots.ts のコメント・HANDOFF）に広がっていたので、まとめて直しました。
    • OAI-SearchBot について「これが掲載を決める」と書くのをやめました。 公式が明言しているのは拒否すれば検索の回答に表示されないという否定側だけです。許可は参加の条件であって、特定の回答への掲載を保証しません。Readiness と Visibility の区別がここにも出ます。
    • ★ 「制御できる / できない」を二値で書いていました。 Parametric Knowledge を「実質的に確認も制御もできない」としていましたが、同じ記事の後半では GPTBot の拒否や Google-Extended による制御を正しく説明しており、矛盾していました。モデル内部に何が入ったかは観測も決定論的な操作もできない。一方、将来の学習への入力可否はプラットフォームによって制御できる、と二段階に分けました。
    • Retrieval / Grounding の「比較的直接制御できる」も限定しました。 制御できるのは参加条件の一部であって、特定のクエリで取得されること自体は保証できません。 サイト側が持てるのは Readiness であって Visibility ではない、という SILVE 全体の立て付けと揃えました。
    • Googlebot の節に Search Console の生成 AI 掲載設定を足しました。 クロールのアクセス管理は Googlebot ですが、生成 AI 機能に出る資格にはこの設定も関係します（2026.08.33 以降の横断修正）。
    • Google の記述を 2026.08.36 / .37 と同じ表現に統一しました。 ガイドは AEO と GEO を業界用語として取り上げ、Google Search では SEO の範囲として整理しています。LLMO は本文に登場しません。
40. 2026.08 第37版2026-08-13臨時改訂根拠表現スコアに影響なし

    AIEO の記事を訂正した（本文の留保と、表の断定が食い違っていた）

    9

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 「日本では主に AI Engine Optimization」という断定をやめました。 同じ記事の本文が「どちらが優勢かを言うには日本語の記事を一定数抽出して比率を出す必要があり、それは行っていない」と正しく留保しているのに、冒頭・結論・まとめ・Canonical Record の 4 箇所で「主に」「主流」と書いていました。 言えるのは「日本語圏で複数の用例を確認できる」までです。
    • ★ UCD の年代を「内部で不一致」としていたのは誤りでした。 Kalicube の UCD 専用ページが実在し、2019 created / 2020 first published / 2024 named and formalised as a framework / 2026 UCD Funnel formalisation と整理しています。2019 と 2024 は矛盾ではなく別のマイルストーンです。 なお この記事は本文で「粒度の違いである可能性を排除できていない」と留保していました。留保が正しく、表とまとめの断定が誤っていました。 本文で留保したなら、表とまとめでも同じ強さにすること。
    • AIEO 本体の命名年（2023 と 2024）の食い違いは解消していません。 UCD の件と混ぜないでください。
    • ★ 提唱者側の命名史に、もう 1 つ別の年がありました。 Kalicube の entity ページは Assistive Engine Optimization を 2020 年に命名したとし、AIEO の同義語で両者を interchangeably に使うと説明しています。ただし命名を主張している文字列は Assistive Engine Optimization であって、AI Assistive Engine Optimization ではありません。 別名称の主張として分けて記録しました。これで提唱者側の資料には 2020 / 2023 / 2024（canonical）/ AI Engine Optimisation（Framework の一覧） が併存することになります。
    • しかもその略称は「AEO」です。 Barnard / Kalicube は Answer Engine Optimization の命名も主張しているので、同じ提唱者の資料の中で AEO が 2 つの展開形を指しています。 略称の衝突は他人との間だけでなく、提唱者の内部でも起きています。
    • 「独立確認資料：存在しない」を射程へ戻しました。 用語を扱う第三者の記事は 2025〜2026 年に存在します。見つかっていないのは命名の年と主体を裏づける同時代の独立資料です。
    • Google の記述を 2026.08.36 と同じ表現に統一しました。 ガイドは AEO と GEO を業界用語として取り上げ、Google Search ではそれらを SEO の範囲として整理しています。AIEO も assistive engine optimization も本文に登場しません。AIO の記事で直した表現が、この記事に届いていませんでした。
    • 「『誰に向かないか』は特に効きます」を非因果の表現にしました。 比較のための判断材料として情報価値が高いことと、推薦されやすくなる要因として実証されていることは別です（aeo の Decision-useful Information Principle）。
41. 2026.08 第36版2026-08-13臨時改訂根拠表現スコアに影響なし

    AIO の記事を訂正した（媒体の所有関係の開示と、断定の射程）

    11

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 普及率の根拠にしていた媒体が、この用語を製品名にしているベンダーの所有でした。 「業界リーダーの 63% が AIO に言及」という数字の出典は Search Engine Land ですが、同媒体は Semrush が所有しており、その Semrush 自身が Enterprise 向けに AI Optimization（AIO）を提供しています。 記事自身が末尾で所有関係と「寄稿者は Semrush への言及を求められていない」旨を開示しています。数字を無効にはしませんが、提唱者側の資料と独立資料を分ける基準は媒体にも当てます。
    • ★ その結果、この資料は「独立確認」から外れました。 用語レコードは同記事を origin.independentSourceIds に入れていましたが、独立性を affiliated に改めた瞬間に機械検査が落ちました（independentSourceIds には independence=independent の資料しか入れられない）。利害の記録を直すと、その資料に依存していた別の主張が自動的に露出する — 検査がそう設計されていたことの実例です。
    • 「用語を一貫して使い続けた人は 3 分の 1 未満」を訂正しました。 原文は 「fewer than one-third of thought leaders have maintained consistent usage of AI-related SEO terminology and sentiment over the past year」で、用語の使い方と、それに対する評価の両方での一貫性を測っています。同調査は評価のぶれを標準偏差で測ったとも説明しています。
    • 「業界標準の展開形：存在しない」を「確立していない」にしました。 確認できるのは「単一の標準展開形が確立しているとは確認できない」ことであって、存在しないことを証明したわけではありません。 記事末尾の Canonical Record 側は最初から「確立していない」だったので、冒頭と食い違っていました。
    • Artificial Intelligence Optimization の同義性を、AI 検索の文脈へ限定しました。 その文脈では AI Optimization とほぼ同義に使われますが、「AI を使って最適化する」という別系統の用法もあります（2023 年の AIO Writing がその例）。「AI に向けた最適化」と「AI を使った最適化」は別のことです。
    • 「Google は略しません」という絶対表現をやめました。 言えるのは「Google Search Central の主要な公式文書では正式名称で表記しており、AIO を正式な略称として定義していない」までです。Google のあらゆる公開物で一度も使われていない、とは確認していません。
    • 「Google が定義している略語は SEO・AEO・GEO の 3 つだけ」を、一次資料の書き方に寄せました。 ガイドは AEO と GEO を業界用語として取り上げ、Google Search ではそれらを SEO の範囲として整理しています。AIO は本文に登場しません。
    • 「AIO 固有の技術的施策は見当たりません」を、確認した資料の範囲へ限定しました。 存在しないことの証明ではありません。
    • 「名前が増えても、測るべきものは増えません」を「名前が増えただけでは」に直しました（2 箇所）。2026.08.32 で段階モデルの記事に入れた訂正が、この記事に届いていませんでした。同じ言い回しを複数の記事に置くと、片方だけ直る。
    • 同じ「存在しない」が AAO の記事にもありました。 用語記事の冒頭で「業界標準の展開形：存在しない」としながら、末尾の Canonical Record では「確立していない」と書いていた記事が 2 本（AIO / AAO）。両方そろえました。1 本を直したら、同じ書式の記事を掃く。
42. 2026.08 第35版2026-08-13臨時改訂根拠表現スコアに影響なし

    GEO の記事を再訂正した（前版の検証が 2 件とも誤っていた）

    6

    • スコアは変わりません。 前版（2026.08.34）で行った検証のうち 2 件が誤っていたので訂正します。訂正の訂正です。
    • ★ 架空のデータを許容するプロンプトは、公開リポジトリだけでなく論文の付録に印刷されていました。 前版で「v2 の付録にプロンプト本文は見当たらない」と書きましたが、誤りです。 v2（2024-05-28）の付録 B.5「Prompts for GEO methods」は、プロンプト本文を Figure 10〜13 として組版しています。Statistics Addition は「Addition of fake data is expected」「Add positive, compelling statistics（even highly hypothetical）」、Cite Sources は「You may invent these sources but ensure they sound plausible」、Quotation Addition は「Add more quotes in the source, even though fake and artificial.」。この v2 が KDD '24 の版です。 v3（2024-06-28）でプロンプト本文が消え、公開リポジトリを参照する形になりました。本文の手法説明（credible sources）は両版で変わっていません。
    • 誤判定の原因を残します。 HTML へ変換された版だけを見て、PDF の組版を確認していませんでした。図として組まれた内容は、テキスト抽出では落ちることがあります。 「載っていない」と言う前に、その資料の一次形式（この場合は PDF）を見ること。
    • ★ Statistics Addition の +33% は、1 行だけ違う指標から計算した値でした。 Table 1 の Position-Adjusted Word Count は Word / Position / Overall の 3 つの下位指標に分かれています。+33% は Word（25.9 / 19.5）から出した値で、同じ表の Quotation（+41%）と Cite Sources（+27%）は Overall から出していました。 Overall で揃えると Statistics は +31%（25.2 / 19.3）です。前版でこの指摘を「基準を取り違えている」として退けましたが、退けたこちらが列を取り違えていました。
    • 表に載せる値は、どの列から計算したかを明示します。 上の 3 行はすべて総合列（Overall / Average）です。論文の caption が「The best methods improve upon baseline by 41% and 28%」と書いている値とも一致します。
    • 記事の中心の主張は変わりません。 「最大 40%」が固定文脈での値であること、Perplexity 実験も固定文脈であること、架空の統計・引用・出典を許容した実験であること。むしろ最後の点は、リポジトリではなく査読を経た版の付録に印刷されていたぶん、強い根拠になりました。
43. 2026.08 第34版2026-08-12臨時改訂根拠表現スコアに影響なし

    GEO の記事を訂正した（Perplexity 実験の読み方・数値・掲載条件）

    8

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ Perplexity の実験を「実際の検索でも効いた」と読める書き方をしていました。 論文は Perplexity が情報源 URL の指定を許さないため、情報源のテキストをファイルとしてアップロードし、そのファイルだけから回答を生成させたと書いています（test set から 200 件）。Web を検索させていません。 したがってこの結果が示すのは「商用の稼働サービスでも、あらかじめ与えた情報源なら生成回答内の可視性に差が出た」ことであって、オーガニックな発見可能性の証拠ではありません。 実験の場所が研究環境か商用サービスかという軸と、固定文脈か自然な取得かという軸を混同していました。この記事自身の主題がその区別なので、最も直すべき箇所でした。
    • 「論文が隠していたものをコードから掘り当てた」という構図をやめました。 現行 v3 の付録 B.5 は「We present all prompts in our public repository」としており、プロンプトの置き場所は論文自身が案内しています。 食い違っているのは、本文の抽象的な手法説明（credible sources など）と、同じ研究が正式な置き場所として示した具体的な実験条件のあいだです。架空の統計・引用・出典を許容するプロンプトが存在するという指摘自体は取り下げません（現行のリポジトリで確認できます）。
    • 版差については主張を控えます。 v2 の付録に同じプロンプトが印刷されていたという指摘がありましたが、こちらで取得できた v2 の付録にもプロンプト本文は見当たりませんでした。 確認できていないことは書きません。
    • Cite Sources の Subjective Impression を +15% から +13% に訂正しました。 現行 v3 の Table 1 は基準 19.5 / 19.3、Cite Sources 24.9 / 21.9 で、相対改善は約 +13% です。Quotation の +41% / +28% は論文が caption で自ら述べている値、Statistics の +33% / +23% も表から再現できます。
    • Perplexity 実験の Quotation Addition を +20.6% から +22% にしました。 論文自身が 22% と報告しています。
    • ★ Subjective Impression は人間による評価ではありません。 7 つの下位指標を GPT-3.5 で評価（G-Eval）し、G-Eval のスコアは較正が悪いため Position-Adjusted Word Count と同じ平均・分散になるよう正規化しています。「+28%」は読者が 28% 強く感じたという意味ではありません。 指標の性質を書いていなかったので追記しました。
    • Google の掲載条件を、22 本すべてで掃きました。 2026.08.33 で AEO の記事に入れた「Search Console の生成 AI 掲載設定」の件は、geo と measurement-layers にも同じ記述がありました。あわせて 4 つの台帳の claim と MEASUREMENT.md の規則にも、「追加の技術要件が無い」は掲載条件の全体ではないという注記を入れています。
44. 2026.08 第33版2026-08-12臨時改訂根拠表現スコアに影響なし

    AEO の記事に 2026 年の Google の掲載条件を反映し、研究の記述を測った量の名前に直した

    9

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ Google の生成 AI 機能の掲載条件が、2026 年の仕様に追いついていませんでした。 これまで「通常の Search の技術要件を満たすことであり、追加の技術要件はありません」とだけ書いていましたが、Google の資料は 2 ページあり、記述が食い違って見えます。 AI 機能の表示に関するページは「追加の技術要件はありません」とし、生成 AI 向け最適化ガイドは「Search の技術要件に加えて、サイトが Search Console で Search generative AI features に含まれている必要がある」としています。矛盾ではありません — 前者はサイト側に新しい実装を求めないという意味で、掲載可否を決める設定が別にあることを否定していません。どちらのページを引いているかで結論が変わるので、毎回確認します。
    • Search Console の「Search generative AI control」について、一次資料で確認できた範囲を書きました。 選択肢は「含める / 除外する」の 2 つで既定は含める。除外すると AI Overviews・AI Mode・Discover の生成 AI 機能でリンク表示にも grounding にも使われなくなりますが、通常の検索結果には影響せず、Search の他の部分のランキングや掲載のシグナルとしては使われません。一部のサイト所有者への段階的な提供にとどまります。診断では検出できません（Search Console は所有者しか見られないため）。配点はせず、施策より先に確認する項目として記事に書いています。
    • 「Google 上位 10 ドメインとの平均ドメイン重複率」を「ドメイン単位の Jaccard 類似度」に直しました。 分母は両者の和集合なので、「Google 上位 10 件のうち何%が AI にも出たか」と読むと数字の意味が変わります。値そのものは原典どおりです。
    • 「ChatGPT 経由の参照 6.1 倍」を「ChatGPT からのリファラルセッション 6.1 倍」に直しました。 同研究が測っているのは引用数ではなく GA4 のセッションです。引用・言及・インプレッション・参照流入を同じ「参照」でまとめません。
    • 同研究の限界を 2 つ足しました。 (1) 施策には新規ページの生成が含まれ、コーパスの規模自体が変わっています（論文自身が treatment changed corpus size と明記）。推定された効果は既存ページの改善とページ追加を合わせたもので、既存ページを直した効果としては読めません。(2) 著者 2 名は Glasp Inc. 所属で、評価対象は自社ドメインの自社施策です。 提唱者側の資料と独立資料を分ける基準を、研究にも同じく当てます。
    • 評価の言い方を弱めました。 「AEO 施策が実際の Web 環境で成果を出しうることを示した重要な初期証拠」→「AEO と呼ばれる施策の束を投入した後に、実際の Web 環境で対照群との差が観測された重要な初期のフィールド証拠」。置換検定 p=0.16 と事前トレンドの存在が、「成果を出せる」という言い方を支えません。
    • ★ 記事の強調が、22 本のうち 23 箇所で効いていませんでした。 日本語では、閉じの ** の直前が約物で直後が文字だと強調にならず、アスタリスクがそのまま本文に出ます（**視点も粒度も違います。**前者は のような書き方）。欧文では単語の後に空白が入るので、まず起きません。読者にはアスタリスクが 2 つ並んで見えていました。 全記事を直し、pnpm check:markup で検査するようにしました。判定はレンダリング結果だけで行います — 原文を正規表現で当てにいくと、開始と終了の ** を区別できずに誤検出します。
    • ★ 資料の題名の検査も、用語レコードを見ていませんでした。 「資料の題名 82 件すべて一致」と言いながら、.record.json の資料は一度も実ページと突き合わせていませんでした。対象を広げると 114 件中 10 件の食い違いが出ました。うち 2 件は題名に注記を混ぜていたもの、1 件は英語版の URL に日本語版の題名、1 件はShift_JIS のページを UTF-8 で読んで文字化けしていたもの、そして 1 件は提唱者側のページが記録後に改題されていました（Kalicube）。題名が変わるということは本文も変わり得ます。 検査側も、文字コードの判定・数値文字参照の復号・「取得できなかった」と「題名が違う」の分離を直しました。
45. 2026.08 第32版2026-08-12臨時改訂表現根拠スコアに影響なし

    段階モデルの記事を訂正した（古い配点が残っていた／断定が強すぎた箇所）

    12

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。訂正したのは記事の記述です。
    • ★ 段階 2 の配点が古いままでした。 /articles/ai-pipeline の対応表が段階 2 を 40 としていましたが、2026.08.12 で構造化データ 4 項目を 20 → 7 に引き下げた時点で 27 になっていました。同じ記事の「配点の 68%（91 のうち 62）」は引き下げ後の正しい値だったため、記事の中で 35+40+13+4+12=104 と 91 が同居していました。 測定可能性を掲げる記事に、自分の配点の矛盾が残っていたことになります。合計が 91 に一致すること、1 項目を複数の段階に数えていないことを本文に明記しました。
    • ★ AIEO について「独立した確認資料が 1 件も無い」は言い過ぎでした。 用語レコードで独立資料が無いのは命名の主体と時期についてです。AIEO を扱う第三者の記事やサービスは存在します。資料の適用範囲を広げないという自分の原則に反していました（EVIDENCE_POLICY.md の Claim scope）。
    • Google UCP を「取引だけ」と書いていました。 Google 自身の解説は UCP の capability として checkout のほかに product discovery（リアルタイムの在庫確認や価格）を挙げています。一方で Google の実装への参加条件は有効な Merchant Center アカウントであり、フィードが不要になるわけでもありません。「商品データ＝Merchant Center / 取引＝UCP」という二分をやめました。
    • OpenAI のクローラについて、書いていなかった留保を足しました。 「OAI-SearchBot と GPTBot は独立」は OpenAI 自身の記述（each setting is independent of the others）なので維持しますが、同じ文書は OAI-SearchBot を拒否したサイトもナビゲーションのリンクとしては表示され得ると述べています。掲載経路を塞ぐことは「回答の中で情報源として使われる可能性」を断つのであって、「画面から名前が消えること」ではありません。
    • 「Discovery はすべての起点」をやめました。 同じ記事の冒頭で「商品フィードから取得される」「URL を直接渡される」経路があると書いており、矛盾していました。「このモデル上の最初の段階」に直しています。
    • 段階 5・6 について「公式仕様に基づく検出基準が確立していない」の射程を限定しました。 個別の仕様（商品フィードの必須項目、UCP や ACP の要件）は公開されており、充足は検出できます。確立していないのは推薦されやすさ・選ばれやすさをサイト側から決定論的に評価する一般的な基準のほうです。
    • 「新しい用語のほとんどは既存段階の別名」を、検証した 8 用語の範囲へ戻しました。 用語一般への一般化は、こちらが持っている証拠を超えています。
    • 「名前が増えても、測るべきものは増えません」を「名前が増えただけでは」に直しました。 新しいプロトコルやインターフェースが現れれば測るべきものは増えると、同じ記事が認めています。
    • ★ 同じ種類の数値ずれが、他の 3 箇所にもありました。 段階 2 の件を受けて全記事を掃いたところ、machine-readable-data が構造化データの実効重みを 20（引き下げ前の値）のままにしており、agent-readiness の記事と方針文書がカテゴリ計 6 項目・実効重み 12 としていました。正しくは 7 項目・実効重み 25 です。 12 は段階 7（Action / Transaction）の小計で、カテゴリには JS 非依存（9）と内部リンク（4）も入ります。段階の小計とカテゴリ計は別の集計軸なので、同じ名前で置かないことにしました。
    • OpenAI のナビゲーションリンクについて、機構の記述は書きません。 「第三者検索プロバイダー経由で URL を得た場合」という説明が Help Center にあるという指摘がありましたが、help.openai.com は当方の取得に 403 を返し、本文を確認できていません。 検索結果のスニペットを最終根拠にしない方針なので、逐語確認できた「表示され得る」という事実までにとどめ、確認できていないことは台帳にそう書いてあります。
    • ★ 台帳をまたぐ一貫性の検査が、用語レコードを見ていませんでした。 2026.08.25 で入れた「同じ URL に別の題名／同じ id に別の URL」の検査は、フレームワーク台帳だけを対象にしていました。対象を用語レコードへ広げたところ、3 つの URL で題名が割れているのが即座に 10 件見つかりました（Google の生成 AI ガイド、OpenAI のクローラ文書、Google のクローラ文書）。実ページの題名を検証済みのフレームワーク台帳側へ揃えています。検査の対象から外れている場所に、まさにその種類のずれが溜まります。
46. 2026.08 第31版2026-08-12臨時改訂採点項目の追加・廃止スコアに影響なし

    ページ数を版に固定した（前版で宣言した記録先が存在していなかった訂正）

    6

    • スコアは変わりません。 項目・重み・採用状態・判定ロジックはチェックリスト v3 から 1 つも変えていません。変えたのは、1 回の診断で見るページ数をどこに書いておくかだけです。
    • ★ 前版で「今回から採点方法の変更も版として記録します」と書きましたが、記録する先がありませんでした。 ページ数はチェックリストの外にある定数で、5 から 10 に変えてもどの版にも残らず、診断結果から「この結果は何ページで測ったのか」を辿れませんでした。宣言だけが先に出ていた状態です。
    • チェックリスト v4 を公開し、ページ数をその版の値として固定しました。以後、公開した版を見れば、その版が何ページで測るのかが分かります。
    • 過去の版で測り直すと、当時のページ数に戻ります。 ここが実利です。同じ基準での再診断は「サイトを直した分だけ」を見るための機能ですが、版を固定してもページ数は現在の値が使われていました。 v1 で測り直すと、5 ページで測った過去の結果に 10 ページの結果をぶつけることになり、範囲の差がサイト側の変化として出ていました。
    • この差は specDelta には出しません。 ドリフト分離は重みの差分から基準側の変動を出すもので、ページ数は重みではありません。範囲が違う比較は、これまでどおり結果画面の「解析したページ数が違います」で説明します。無理に基準側の変動へ寄せると、重みを変えていないのに基準が動いたことになり、分離そのものの意味が薄れます。
    • 無料の範囲は 1 ページのままです。実際に取得する数は「その版が決めた上限」と「プランの上限」の小さいほうです。
47. 2026.08 第30版2026-08-12定期改訂採点

    1 回の診断で見るページ数を 5 から 10 に増やした

    5

    • 同じサイトでもスコアが動く可能性があります。 ページ比率で段階を分けている項目（JavaScript 依存・canonical・構造化データの有無）は、見るページ数が変わると取り得る値が変わります。とくに「全ページで満たしていること」を求める段階は、分母が増えるぶん達成が難しくなります。
    • 5 という数字に外部の根拠はありませんでした。 一般的なサイトのグローバルメニューが 5〜8 項目なので、それを少し上回る 10 に置き直しています。10 も根拠のある数字ではなく、待ち時間との兼ね合いで決めた値です。
    • ★ これまで、クロールの設定は版として記録していませんでした。 項目・重み・採用状態は版に固定していましたが、ページ数のような採点方法そのものは版の外にあり、変えてもスコアの変動として説明されない状態でした。今回から採点方法の変更も版として記録します。
    • 前回と見たページ数が違う診断を比較したときは、結果画面で「解析したページ数が違います」と表示します。その差はサイトの変化とは限らないためです。
    • 無料の範囲は 1 ページのままです（従来、登録済みの無料利用者には表示と異なり 5 ページ取得していた不具合も併せて修正しました）。
48. 2026.08 第29版2026-08-12臨時改訂根拠分類スコアに影響なし

    施策の効果を前後比較で判定しない方針を固定した

    12

    • スコアは変わりません。 効果検証の機能は未実装で、本改訂は実装前に要件を固定するものです。
    • ★ 対照群を置くだけで 6.1 倍が 1.75 倍になります。 2026 年の自然実験では、施策を受けたページが 1 月から 5 月で 6.1 倍になった一方、施策を受けていない同一ドメインのページも 3.5 倍伸びていました。論文自身が「素朴な前後比較は 6.1 倍の全体を施策の成果に帰属させてしまう」と書いています。
    • ★ さらに事前トレンドがありました。 週次の中断時系列分析では、介入前から週あたり +0.027（月あたり約 +11%、p = 0.007）で処置群が対照群を上回って伸びていました。このトレンドが続くだけなら、施策が無くても処置群は上回ります。 介入時点の水準の跳ね上がりは 1.82 倍（95% CI 1.31〜2.54）でしたが、傾きの変化は p = 0.53 で有意ではありません。 「施策後も伸び続けた」は傾きの効果の証拠になりません。
    • ★ 同じ論文の中に p = 0.001 と p = 0.16 が併存しています。 介入日をずらして偽の効果を探す置換検定では、介入前のノイズだけで観測とほぼ同じ大きさの跳ね上がりが起きており（偽の最大 0.65 に対し観測 0.60）、p = 0.16 でした。著者は効果を suggestive であって conclusive ではないとしています。SILVE は因果の確信度を、最も弱い重要な検定に合わせます。 置換検定を通らなかったことは失敗ではなく、過剰な因果の主張を止めた成功です。
    • 使ってはいけない数字が、同じ論文の中に明示されています。 谷から山への 38.2 倍について論文は「一過性の急上昇で、持続した水準はその半分未満」とし、介入後 4 週と介入前平均を比べた 4.85 倍（信頼区間つき）についても「水準の跳ね上がりと既存トレンドの継続を混ぜたもので、介入の効果として読むべきではない」と明記しています。信頼区間が付いていることは、その数字が因果効果であることを意味しません。
    • 「悪化しなかった」を「改善した」と読み替えません。 同研究の防護指標では、処置ページの自然検索クリックは実際には約 25% 減っています（サイト全体は約 20% 減）。論文は施策特有の崩壊ではないとしつつ、AEO が自然検索を押し上げるという主張はこの期間に支持が得られなかったと明記しています。
    • 束の効果を構成要素の効果にしません。 施策は URL の正規化・404 ログからの需要の発掘・タイトルと冒頭要約の書き換え・防護規則の 4 つの束で、新規ページの生成でコーパスの規模自体も変わっています。 「疑問形のタイトルが 1.8 倍効いた」とは言えません。
    • 波及の向きを一律に仮定しません。 施策がドメイン全体の引用されやすさを高めたなら対照群も恩恵を受けて推定は保守的になりますが、処置群が対照群の引用を奪うなら過大評価になります。AI の回答は相対的な選択なので、一社が候補に入れば誰かが外れます。
    • 測定の変更を施策の効果にしません。 同研究では 3 月中旬のボット除外方針の変更があり、エンゲージメント率が 0.486 から 0.896 へ上昇しています。
    • 因果の状態を二値にしません（established / supported / suggestive / inconclusive / unsupported）。「有意差なし」と「効果がゼロ」も分けます。
    • この研究の 1.8〜2.3 倍を、SILVE の採点の重みや業界の基準値として採用しません。 1 つのドメイン、1 つの束、ChatGPT に偏ったチャネル、有意な事前トレンド、曖昧な介入日、短く変動の大きい介入前の期間から出た値です。著者 2 名は Glasp Inc. 所属で、評価対象は自社ドメインの自社施策です（interestDisclosure: stakeholder）。
    • あわせて既存の用語レコードを 1 件訂正しました。 AEO の用語レコードで同じ研究を independence: independent として記録していましたが、著者が自社ドメインの自社施策を評価しているため first_party が正しい記述です。
49. 2026.08 第28版2026-08-12臨時改訂根拠表現スコアに影響なし

    改訂版のある資料を旧版で記録していた誤りを訂正し、版の扱いを規則にした

    8

    • スコアは変わりません。 第27版の訂正です。公開済みの第27版は変更していません。
    • ★ 第27版の訂正：改訂されている論文を、旧版の数値で記録していました。 Reddit と AI Overviews の研究について、検索結果に出ていた版を固定した URL（...v1）をそのまま取得してしまい、v1 の値（コメント投稿者 +12.3%、57,441,564 観測、2025 年 6 月まで）を記録していました。最新版は v3（2026-06-20 改訂）で、観測期間が 2025 年 7 月末まで延び、60,696,936 観測・コメント投稿者 +12.4% に更新されています。訂正しました。
    • ★ 版の扱いを規則にしました。 取得は版を含まない URL で行い、版の履歴を確認し、確認した版と改訂日を記録します。検索結果が示す URL は最新版とは限りません。 併せて、版を固定した URL を記録していると検証が警告するようにしました（意図的に壊して発火を確認済み）。
    • AI Mode 後の減衰に、実際の係数を入れました。 体験型の上乗せ効果は、コメントで 9.54 から −0.17 へ（変化 −9.71、p < 0.001）とわずかに負へ転じ、投稿者で 6.29 から 2.57 へ（変化 −3.72、p < 0.001）と 59% 低下しています。事実型への基本の効果も低下していますが、体験型に集中した追加の低下はその 2 倍以上です。
    • ★ 言語と市場を同じ軸にしない規則を追加しました。 同じ研究の中で、ポーランド語で切れば Wikipedia が首位（3.71%）、ポーランド市場で切れば YouTube が首位（6.4%、2,289 件 / 35,880 引用）になります。矛盾ではなく、分析の単位が違います。 sourceLanguage と sourceMarket を別のフィールドで持ちます。
    • ★ 根拠の様態を別の軸で持つようにしました（groundingMode: explicit_url / implicit / unknown）。URL を伴う 131,514 件では自社 14.3% / 第三者 85.7% ですが、URL を持たない暗黙的知識の行を含む 150,093 行では自社 14.4% / 第三者 76.1% / URL なし 9.5% です。URL の無い 9.5% を、無理に Owned か第三者へ振り分けません。
    • ★ 平均がブランド間の幅を隠していることを記録しました。 自社引用が最も多いブランドは 34.4%、0.0% のブランドも複数存在します。 論文は「ブランド自身の Web サイトは、最も自社引用の多いブランドにとってさえ少数派の情報源であり、多くのブランドにとっては情報源ですらない」と要約しています。業界平均の自社引用比率を自社の目標値にしません。
    • カテゴリ比率を研究間で直接比較しない注意も追記しました。 この研究の型付き分類は catch-all の other_web が 77.0% を占め、論文自身が「実在するニュースやレビューのドメインの多くは other_web に落ち、型付きの分類に届かない」としています。
50. 2026.08 第27版2026-08-11臨時改訂根拠分類スコアに影響なし

    情報源を統制構造で 4 層に分け、言及数を採点に入れない方針を固定した

    11

    • スコアは変わりません。 この層は未実装で、本改訂は実装前に要件を固定するものです。
    • AI が企業について参照する情報は、企業自身の Web だけでは閉じていません。 中国語圏 4 プラットフォームの研究では、ニュース 28.8%・業界ポータル 24.1%・ソーシャル 16.4% の合計が約 69% で、ブランドの公式サイトは 12.9% でした。別の研究では第三者 85.7% / 自社 14.3% です。
    • ★ ただし「だから自社サイトは無意味」ではありません。 公式サイトの 12.9% は6,589 の異なるドメインへ分散しており、分類できた 9,384 ドメイン中で最も分散していました。公式サイトが引用されないのではなく、公式サイトはブランドの数だけ存在するので 1 社あたりの取り分が小さいのです。 Owned の役割は引用シェアではなく、正典となる事実の出所であることにあります。
    • 数字の基準も確認しました。 85.7% は Nordic-Baltic の URL 基盤（131,514 件）の値で、URL を持たない暗黙的知識の行を含めると自社 14.4% / 第三者 76.1% / URL なし 9.5% になります。引用が付かない回答が約 1 割あるという点も落としません。
    • ★ 情報源を統制構造で 4 層に分けました。 Owned（直接編集できる）/ Platform（一部の項目を管理できる）/ Earned（直接書き換えられない）/ Community（統制の対象ではない）です。特に Platform を Owned に混ぜません。 Google は Business Profile の情報が公式サイトからクロールした公開情報・第三者からライセンスを受けたデータ・利用者の投稿・Google 自身のやり取りから編成されると説明しています。「公式サイトを直せば Google 上の企業情報も直る」とは言えません。 brandOwned と brandManaged を別のフィールドで持ちます。
    • Web ページの改善だけが自社側の施策ではありません。 Google は商品情報を managed products（Merchant Center で管理）と unmanaged products（アカウントが無くてもクロールで発見）の 2 経路で得るとしており、AI Mode などの面に向けた conversational attributes も提供しています。ただし「完全に任意」と明記されており、Google の商品面に限定された仕様です。
    • ★ 言及数を採点に入れません。 複数の情報源にまたがる出現回数が予測モデルで重要だったという観測はありますが、予測上の関連であって介入実験ではありません。 逆の因果もあり得ます — もともと知られているブランドだから多くの情報源が書き、AI にも出る。言及数は不祥事でも増えます。
    • ★ インターフェースが変われば効果の符号も変わり得ます。 Google が安全でない内容を AI Overviews で参照しない方針を利用した差分の差分法の研究（105,012 サブレディット、5,744 万観測）では、AI Overviews が体験型コミュニティの日次コメントを 12.0%、投稿者を 12.3% 増やしました。しかし同じ研究の後半で、対話型の AI Mode 登場後にこの上乗せ効果は大きく減衰し、コメントではわずかに負に転じ、投稿者では 59% 低下しています。 第23版の「面が違えば別物」を因果推定つきで裏づけています。前半だけを引くと逆の話になります。
    • この研究を「フォーラムに投稿すれば AI に出る」の根拠にしません。 測られているのは AI Overviews への露出がコミュニティの参加へ与えた効果であって、ブランドが投稿を増やしたときの可視性への効果ではありません。
    • 固定の重要ドメイン一覧を持ちません。 Wikipedia は 12 言語中 11 言語で首位でしたが占有率は 3.71〜5.70%、リトアニア語では経済紙 vz.lt が上回り、ポーランドの国内ブランドでは YouTube が首位で人材ポータルが Wikipedia の約 2 倍でした。そしてこれらの研究に日本市場は含まれていません。 実測します。
    • 事実と意見を分けます。 否定的なレビューがあること自体は不整合ではありません。「高いと思う」は意見で、「すでに販売終了している」が事実と違えば不整合です。 そして偽のレビュー・なりすまし・関係を明かさない推薦を推奨も採点もしません。 情報環境を良くする行為ではなく、汚染する行為だからです。
51. 2026.08 第26版2026-08-11臨時改訂根拠分類スコアに影響なし

    原著が使った語を段階へ写していた誤りを訂正し、機械検査を追加した

    6

    • スコアは変わりません。 第25版の訂正と、機械検査の追加です。公開済みの第25版は変更していません。
    • 第25版の訂正：原著の retrieval selection という語を、そのまま取得段階へ写していました。 中国語圏の生成検索を調べた研究は本文でそう書いていますが、同じ論文の限界の節に「観測しているのはすでに引用リストへ入った Web ページであり、オープンな Web 上の完全な候補集合も落選したページも取得していない」と明記されています。 つまり内部の取得は観測されていません。これを取得段階へ写すことは、取得と引用を分けるという自分たちの規則を破ることでした。 該当 claim の段階を引用・吸収に直し、内部取得の効果の直接証拠としては扱いません。
    • ★ この誤りを機械が捕まえられるようにしました。 claim が主張する段階は、支える資料が実際に評価した段階に覆われていなければなりません。 これまでは資料の取得条件だけを見ていたため、「引用しか見ていない」と宣言している観測研究でも取得の主張を支えられてしまっていました。新しい検査を入れたところ、既存の台帳から同種の問題が 4 件見つかりました。
    • その 4 件の内訳です。 3 件は資料側の申告漏れでした。ACL の研究は出力長・話題の網羅度・回答の反転を測っており、実際には生成段階も評価していたため、資料の宣言を直しました。残る 3 件はレビュー資料を引く claim で、レビューは自ら測定していないので段階の一覧が情報を持ちません。 取得条件が not_applicable の資料を照合対象から外しました。
    • ★ 新しさの成果と利用者の成果を分ける規則を追加しました。 Baidu の本番 A/B では、上位に出る結果の年齢が 12.81% 新しくなった一方、利用者側の指標は 0.06〜0.78% の改善でした。時間的な順位付けを大きく動かしても、利用者側の増分は小幅です。この 2 つを 1 つの「Freshness の効果」に潰しません。 Readiness / Visibility / Outcome を分けるのと同じ構造です。
    • Zhen らの研究について、限界を 3 つ追記しました。 収集は 2026 年 6〜7 月に集中していること、単一要因の無作為化を行っていないため結果は当該クエリ集合とプラットフォームの範囲内での条件付きの関連であること、引用の吸収の型や意味役割は LLM が固定規則の下で生成した操作的な測定値であることです。
52. 2026.08 第25版2026-08-11臨時改訂根拠分類スコアに影響なし

    新しさと有効性を分け、一律の Freshness 加点を作らない方針を固定した

    12

    • スコアは変わりません。 Temporal Validity は未実装で、本改訂は実装前に要件を固定するものです。
    • Google は「新しい方が有利」と「古い方が重い」を、同じページで両方とも否定しています。 「Google は新しいコンテンツを好むのだからページを調整し続けた方がよい」は誤りで、コンテンツは年齢に関係なく品質で評価される、些細な変更で日付を更新して人工的に新しく見せることに追加の価値は無いとしています。同時に「古いコンテンツの方が重い」も誤りで、有用なページは新しくても古くても有用だとしています。片方だけを引くと反対方向の誤りになります。
    • 新しさが要求されるのは、ページ側の属性ではなくクエリ側の条件です。 Google の freshness systems は queries where it would be expected に対するものであり、すべてのクエリではありません。queryTemporalDemand（high / medium / low / atemporal）を独立軸として持ちます。
    • ★ 引用ページの半減期 39 日を、更新期限として扱いません。 中国語圏 4 プラットフォームの研究で、引用ページの公開からの経過日数の半減期は時間依存性の高いクエリで約 39 日、低いクエリで約 68 日、データセット全体で約 60 日でした。これは分布に当てはめた減衰の尺度であって、打ち切り線でも更新期限でもありません。論文自身が「今後の縦断研究のための検証可能なベンチマーク」と位置づけています。 「39 日以内なら +X 点」というスコアリング規則は作りません。
    • 同じ研究の中でもプラットフォーム差が大きい点も記録しました。 DeepSeek の Web では高 55 日 / 低 181 日、Tencent Yuanbao は最も古いページを引用します。全体の 60 日を単一の規則として使えません。
    • ★ 新しさが効く段階を限定しました。 同研究では、公開日の新しさによる差が生じるのは取得の選択と引用の段階であって回答内の順序ではなく（相関 ρ = 0.041）、引用の吸収の程度との相関は −0.009 とほぼ無相関でした。「新しくすれば深く引用される」は支持されません。 品質スコアとの相関も ρ = 0.069 で、新しさは品質の代理指標になりません。
    • 新しさ（Recency）と有効性（Validity）を分けました。 SIGIR 2026 採択の Baidu 本番検索の研究は、静的な時間窓では時系列上は新しいが意味的にはすでに失効したコンテンツが残るとし、普遍的な失効の閾値は存在しないとしています。速報では 2 日前の報道でも失効し得る一方、交通規則では数年前の政策文書が依然として完全に有効です。
    • temporalValidity に old という値を作りません。 年齢は数値のメタデータ、有効性は意味論です。値は current / superseded / expired / historical / unknown とします。避けるべきは「古い」ではなく「失効している」です。
    • 一律の Freshness 加点を作りません。 「更新 30 日以内 +10 点」のようなグローバルな規則は、静的な話題に不要な更新圧力をかけ、日付だけを書き換えるゲーミングを誘発します。 時間の要求がある場合にのみ有効性を評価します。古いことを減点するのではなく、要求される有効性を満たしていないことを問題にします。
    • 確認と更新を別の記録にします（lastReviewedAt / lastMaterialUpdateAt）。「確認したが変更は不要だった」を「更新した」と偽装する必要をなくすためです。 2 年前公開で昨日確認済みのページと、1 か月前公開で以後未確認のページでは、前者の方が信頼できることがあります。
    • ★ 台帳をまたいだ資料の一貫性を機械検査に加えました。 今回、Google の同じ 1 ページについて、片方の台帳が <title> を、もう片方が本文の見出しを記録していたことが分かりました。読者から見れば同じページです。 同じ URL に別の題名が付いている場合と、同じ id が別の URL を指している場合に検証が落ちます。
    • 採用しなかったものが 1 つあります。 「Google は大幅に更新した場合に可視の日付も更新することを案内している」という記述は、その趣旨の一文を一次資料で特定できなかったため採用していません。 確認できたのは、Google が単一の日付要素に依存せず複数要素から公開・大幅更新の時期を推定していること、および日付はページの公開・更新を表すべきでページが説明している出来事の日付ではないことです。
53. 2026.08 第24版2026-08-11臨時改訂根拠スコアに影響なし

    利害のある資料の免除条件を、主張を直接述べる査読資料に限定した

    4

    • スコアは変わりません。 機械検査の条件を厳しくしただけです。
    • 第23版で入れた「査読資料があれば免除」を締めました。 免除に使える査読資料を、その主張を直接述べているもの（directness: direct_claim）に限定しました。査読が検査したのはその論文が述べたことであって、隣接する主張ではないからです。
    • 免除の判定範囲が claim 単位であることを明文化しました。 判定に使うのはその claim の sourceIds が指す資料だけで、台帳全体ではありません。「台帳のどこかに査読論文が 1 本あるので通る」という抜け道は作りません。
    • 設計上の負債を 1 つ記録しました。 第23版で追加した first_party_specification は、他の値（固定文脈 / 取得から再実行 / 商用の観測）がどうやって取得を観測したかを表すのに対し、観測ではなく当事者が仕様を宣言したという性質を表しており、意味論が混ざっています。現状は機械検査で当事者の資料に限定しており実用上は機能するため作り直していませんが、台帳が増える前に 2 軸へ分離します。
54. 2026.08 第23版2026-08-11臨時改訂根拠分類スコアに影響なし

    エンジンごとに情報源が違うことを分離して扱う方針を固定した

    12

    • スコアは変わりません。 Visibility レイヤーは未実装で、本改訂は実装前に要件を固定するものです。
    • 同じ提供元の中ですら情報源は一致しません。 Google の従来検索・AI Overviews・Gemini 2.5 Flash を 11,500 クエリで比較した査読済み研究（SIGIR 2026）で、取得された情報源の平均 Jaccard 類似度は 0.11〜0.18（URL 単位）でした。論文自身が「3 つとも Google が開発したものであるにもかかわらず」と書いています。
    • 「Google 検索 1 位なら AI Overviews にも出る」は成り立ちません。 ACL 2026 の研究では、AI Overviews が参照したドメインの平均 53% が従来検索の上位 10 件に無く、27% は上位 100 件にも無いという結果でした。
    • ただし反対方向へも飛びません。 Google は、supporting link として表示されるにはインデックスされスニペット付きで表示される資格が必要で、それ以外の追加要件は無いと明記しています。適格性（Eligibility）と選択（Selection）を分ける規則にしました。 前者は上流、後者は下流であり、両者は矛盾しません。
    • 取得するページ数からして違います。 同じクエリに対する平均取得ページ数は GPT-4o with Search Tool が 1 未満、GPT-4o Search が 4、Gemini と AI Overviews が 9、Perplexity Sonar が 14 でした。それでも話題の網羅度は概ね同等です。「同じ答え」と「同じ情報源」は別だという規則を立てました。
    • 見えている引用は、エンジンが見た Web の全体ではありません。 LMArena の約 14,000 件のログを用いた研究では、Gemini が回答の 92% でクリック可能な引用元を示さず、Perplexity Sonar は約 10 件を参照しながら引用は 3〜4 件でした。観測している層（従来の検索結果 / 取得 / supporting link / 引用）を宣言する項目を追加しました。
    • エンジン差を測る前に、同じエンジンの中でぶれます。 同じクエリを同じ端末・同じ地域で 2 回実行したときの一致度は、従来検索 0.78・AI Overviews 0.66・Gemini 0.46 でした。1 回ずつ測って 2 つのエンジンを比べると、エンジン差とばらつきが区別できません。
    • 引く研究はいずれも 2025 年の測定です。 掲載年は 2026 年ですが、対象は当時のシステムです。約 2 か月あけた再実行で AI Overviews の共通ページは 18%（従来検索は 45%）でした。エンジン差の観測を恒久的な性質として書かない規則にしました。
    • 重なりの低さは差の証拠であって、順位付けの仕組みの証拠ではありません。 「A は信号 X を重視する」と書くには別の証拠が要ります。同様に、情報源が違うことからコンテンツの複製へ飛ばない規則にしました。 Google は特別なファイルもマークアップも不要だと明記しています。
    • ★ 第22版で追加した commercialAffiliation を interestDisclosure へ一般化しました。 商業だけが利害ではないためです。今回採用した研究の 1 つは政策提言を目的とする団体によるもので、商業的利害はないが結論の方向に事前の立場があります。 種類を commercial / advocacy / stakeholder に分けました。Validator の規則も、査読を経た資料が 1 つでもあれば対象外とするよう緩めました。 立場があることと、検査を受けていないことは別だからです。
    • ★ 資料の取得条件に first_party_specification を追加しました。 プラットフォームが自社の取得の仕様を記述したものは測定ではありませんが、取得についての直接の証拠にはなります。 研究の測定条件と同じ列に置けないため独立の値にし、当事者（first_party）の資料にのみ使えるよう機械検査を追加しました。
    • 採用しなかったものが 2 つあります。 ひとつは、Google-Extended をブロックしているサイトが AI Overviews から取得されにくいという観測です。相関であって因果ではなく、ブロックしているのが大手発行元やソーシャルメディアに偏っているため交絡を排除できません。crawlability の採点は変えていません。 もうひとつは ChatGPT のクエリ書き換えについての記述で、根拠とされるページが 403 を返し本文を確認できなかったため採用していません。403 は取得側の問題であり、記述が存在しない証拠ではありません。
55. 2026.08 第22版2026-08-11臨時改訂根拠表現スコアに影響なし

    標本サイズの但し書きと、原因の帰属の強さを訂正した

    9

    • スコアは変わりません。 本改訂は 2026.08 第21版の記述の訂正です。公開済みの第21版は変更していません。
    • 第21版の訂正 1：標本サイズの目安を落としていました。 第21版は「SearchGPT は 150 クエリで十分は論文が否定した読み方」とだけ書きましたが、同論文は引用シェアの目安として実際に n ≥ 150 を挙げています。 正しくは、目安は示されている一方で、SearchGPT については固定 n の手順が現実的な予算内で目標精度を達成できないとも同時に書かれている、です。収束しなかったトピックもあり、最小 n の厳密な導出は論文が意図的に開いたままにしています。「150 で十分」も「目安など無い」も、どちらも片側だけの引用になります。
    • 第21版の訂正 2：Perplexity の値を n ≈ 90〜100 と書いていました。 論文の記述は n ≈ 100 です。引用普及率の値も追加しました（SearchGPT が n ≈ 60〜80、Gemini と Perplexity が n ≈ 140〜150）。指標を変えるとプラットフォームの順序が入れ替わります。
    • 第21版の訂正 3：原因の帰属を断定形で書いていました。 第21版は「原因はクエリの投入順序という測定設計側にある」と書きましたが、論文の記述は「クエリ順序の効果が最も可能性が高い」です。 断定に直しました。
    • 第21版の訂正 4：無作為化を対処法として書いていました。 論文は、順序の無作為化がこの問題を解決することを実証していません。 SILVE がクエリ順序を無作為化するのは運用上の緩和策としての判断であり、論文の結論ではありません。区別して書き直しました。
    • 不確かさを 3 つに分けました。 システムの非決定性・標本誤差・標本内の非定常性です。信頼区間は前の 2 つを扱う道具で、3 つ目は扱いません。 標本の枠に「クエリ順序の決め方」「順序を無作為化したか」「定常性を評価したか」「区間の前提が満たされているか」を追加し、定常性を評価していない区間を「評価済み」と表示しません。
    • 発行者の利害関係を、資料の質とは別の項目として記録するようにしました（commercialAffiliation）。今回の標本設計の主資料の著者が所属する IQRush は、公式サイトで自らを AI 検索の可視性の測定・検証を提供する事業者と説明しています。論文の主題と事業領域が直接重なります。 これは結論を無効にするものではありませんが、記録しないまま「独立した研究」と表示しないための項目です。なお著者の役職は同社サイト上で確認できなかったため記載していません。
    • Validator を 1 つ追加しました。 主題を事業にしている資料だけを根拠に confidence: high の claim を作れません。独立した資料を足すか、確信度を下げます。
    • 1 つの研究で収束したクエリ数を、業界の最低標本サイズとして扱わないことを規則にしました。 対象は 3 プラットフォーム・3 つの消費財トピック・約 9 日間です。
56. 2026.08 第21版2026-08-11臨時改訂根拠スコアに影響なし

    AI Visibility を推定値として扱う標本設計の要件を固定した

    9

    • スコアは変わりません。 Visibility レイヤーは未実装で、本改訂は実装前に標本設計の要件を固定するものです。
    • AI Visibility を固定値ではなく標本からの推定値として扱う方針を明文化しました。 「Visibility 62%」は「今回の標本から 62% と推定した」という意味でしかありません。
    • 同じクエリでも引用元は大きく変わります。 3 プラットフォームを反復測定した研究では、ドメイン単位の Jaccard 中央値が 0.31、引用元の重なりがゼロだった割合が 35%、完全一致は 7% という観測が報告されています（Gemini の 1 トピック）。「一度引用された」と「安定して引用される」は別です。
    • 見かけの差が測定ノイズに収まる例を記録しました。 200 クエリで引用シェア 9.5% と 6.0%、3.5 ポイント差でも、95% 信頼区間は 5.5〜12.5% と 4.0〜8.0% で、後者の区間全体が前者に含まれていました。 同論文はこうした重なりが例外ではなく通例だとしています。SILVE は区間が大きく重なる差を順位差として表示しません。
    • 「何回測るか」を 3 つに分けました。 クエリ数・言い換え数・試行回数です。1 プロンプト × 100 試行と 20 プロンプト × 5 試行は、どちらも 100 応答ですが測っているものが違います。 試行を増やしてもプロンプトの網羅不足は解決しません。
    • 研究が出す標本サイズはクエリ数であって試行回数ではありません。 引用シェアの信頼区間幅 0.05 を目標としたとき、Gemini は n ≈ 40〜50、Perplexity は n ≈ 90〜100 でした。指標が引用普及率に変われば必要な標本のプラットフォーム順序も変わるため、「n クエリで十分」と一般化できません。
    • 数値だけを引いて但し書きを落とさないことを規則にしました。 同論文は SearchGPT について、曲線が n ≈ 120 以降で滑らかになるとしつつ、それを不安定さが解消された証拠と解釈すべきではないと明記しています（標本全体に近づくほど部分標本が枯渇した母集団から抽出されるため）。「SearchGPT は 150 クエリで十分」は、論文が明示的に否定した読み方です。
    • 信頼区間を付けても不確かさを尽くしたことにはなりません。 標本の中で分布が動いている場合、ブートストラップを含む定常性前提の区間は真の不確かさを過小評価し得ます。 原因はクエリの投入順序という測定設計側にあります。
    • 認知（ブランド名を含むプロンプト）と発見（含まないプロンプト）を平均しません。また、クエリ・情報源・日付はクラスタ化された単位であり、すべての生成を独立標本として扱うと不確かさを過小評価します。
57. 2026.08 第20版2026-08-11臨時改訂根拠スコアに影響なし

    取得と引用を分け、主張と根拠の段階が一致しているかを機械検査に加えた

    8

    • スコアは変わりません。
    • 「AI に引用されやすい文章」への書き換えが逆効果になり得ることを整理しました。 引用は取得を前提とするため、取得率が低ければ引用側をいくら改善しても全体の可視性は上がりません。
    • GEO 原論文の「最大 40%」が何を測っていたのかを明確にしました。 主要実験は検索結果の上位 5 件をあらかじめ取得して生成モデルへ与える構成で、書き換えた文書が再び取得されるかを測っていません。 したがって発見可能性の証明ではありません。さらにレビューは、同じ施策でも 5 番目の情報源が 115.1% 得をする一方 1 番目は 30.3% 失うと整理しており、全員が同時に得をする施策ではないことを示しています。
    • 取得から測り直した研究（SAGEO Arena、KDD 2026）の結果を記録しました。 171,003 文書・2,700 クエリで取得・再ランキング・生成の全段階を通したところ、本文だけの最適化は平均で取得 −9% / 再ランキング −16% / 引用 −6% でした。AutoGEO を本文だけに適用した場合は −36% / −42% / −22% です。最適化した文書が取得結果から脱落し、生成器に届かなくなると論文は結論づけています。
    • 構造化情報まで範囲を広げると取得は +22% 改善しましたが、条件付きです。 論文自身がその理由をBM25 ベースの取得器が語彙的な重なりを優先する性質に帰しており、商用エンジンの取得器が同じとは限りません。数値だけを引いて理由を落とすと、環境依存の結果が普遍則に見えます。
    • 反対方向へも一般化しません。 SAGEO Arena は研究用に構築されたパイプラインであって商用エンジンの再現ではないため、「GEO の書き換えは全部逆効果」も言えません。
    • ★ 主張と根拠の段階が一致しているかを機械検査に加えました。 claim に段階（取得 / 再ランキング / 生成 / 引用 / 吸収 / 行動）を、資料に取得条件（固定文脈 / 取得から再実行 / 商用の観測 / 該当なし）を持たせ、取得・再ランキングについての主張を、取得を測っていない資料だけで支えている場合に検証が落ちます。 直接性を下げるのではなく根拠として認めません。段階が違う資料は、弱い根拠ではなく別の主張の根拠だからです。
    • 最も再現性が高い要因は、レビューによればトピックの関連性と文脈内の位置です。AI 専用の文体を探す前に、そのページがその問いに答えているかを確認します。
58. 2026.08 第19版2026-08-11臨時改訂根拠表現スコアに影響なし

    llms.txt の公開日を確定し、変更履歴に「何が変わったか」の種類を追加した

    6

    • スコアは変わりません。
    • llms.txt の日付を確定しました。 提唱元の正典ページには「Published September 3, 2024 / Modified August 10, 2026」と表示され、dcterms.date メタタグにも 2024-09-03 が入っています。前版では日まで確認できず「2024 年 9 月」と丸めていましたが、3 箇所で確認して 2024 年 9 月 3 日・v2 は 2026 年 8 月 10 日更新に戻しました。
    • 原因は取得方法でした。 要約された取得結果では日付の粒度が落ちることがあります。日付が主張に効く場合は、要約ではなく生の HTML を取得して確認するという規則を追加しました。
    • 変更履歴に「何が変わったか」の種類を追加しました。 従来の minor / patch はリリースの重さを表すだけで、「分類だけ変えてスコアは動かない」といった変更を表現できませんでした。 実際、前版（llms.txt のカテゴリ移動）は minor でありながらスコアは 42 点のまま不変です。
    • 種類は採点 / 分類 / 根拠 / 表現 / 項目の追加・廃止の 5 つで、複数該当してよいものとしました。あわせてスコアへの影響を別欄で持ちます。「スコアに影響なし」は、同じサイトを同じ日に測れば同じ点になるという意味です。基準を変えた側が、その影響を自分で説明するための欄です。
    • 過去の版には遡って付けていません。 公開済みの版は編集しないという原則によります。直近 3 版のみ記載しています。
59. 2026.08 第18版2026-08-11定期改訂分類項目の追加・廃止スコアに影響なし

    llms.txt を検索対策のカテゴリからエージェント対応へ移した

    8

    • スコアは変わりません。 チェックリスト v3 を公開しましたが、変更したのは 1 項目の所属カテゴリだけです。判定ロジックも重みも他の項目も変えていません。実効重みは 91 のまま、実走スコアも 42 点のまま（cybozu.co.jp）です。
    • crawlability.llms_txt を廃止し、agent.llms_txt を追加しました。 旧 ID はレジストリに残します（過去の版が参照しているため）。
    • 理由は表示される文脈です。 Google は「Google Search は llms.txt を使用せず、可視性にも順位にも利も害も無い」と明記しています。それをクロール可能性（検索側）のカテゴリに置いていたため、診断画面では検索対策の並びで表示されていました。「これが無いから AI 検索に出ない」と読まれる位置に置いていたこと自体が誤りでした。
    • 一方 Chrome の Lighthouse は llms.txt を agentic browsing の監査項目として扱い、「LLM と AI エージェント向けにサイト内容の機械可読な要約を提供する emerging convention」と説明しています。矛盾ではなく、見ているシステムが違います。 効く先はエージェント側であって検索側ではありません。
    • 移した後も配点しません。 Chrome 自身が提供を任意とし、404 を Not Applicable として扱っています（失敗にしていません）。提唱元も自らを proposal と呼び、agentic browsing カテゴリ自体が experimental です。提供元が任意としているものを減点対象にはできません。
    • 「robots.txt の AI 版」という説明を採用しません。提唱元自身が、robots.txt はどのようなアクセスが許容されるかを伝えるものであるのに対し、llms.txt はエージェントが情報を必要としたときに随時使われるものだと説明しています。アクセス制御ではなく案内です。
    • 大手が公開していることを、その検索製品が読む証拠にしません。 OpenAI と Anthropic は自社の開発者向けドキュメントの llms.txt を公開していますが、それは公開する側の振る舞いであって、ChatGPT や Claude が任意サイトの llms.txt を読む証拠ではありません。
    • 再検証の間隔を 45 日に設定しました。提唱は 2026 年 8 月に v2 へ更新されており、Chrome 側も experimental です。robots.txt のような安定した標準より変化が速いためです。
60. 2026.08 第17版2026-08-11臨時改訂表現根拠スコアに影響なし

    引用から条件節が落ちていたのを訂正し、資料の題名候補を保存するようにした

    4

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.12（チェックリスト v2）のままです。
    • Query Fan-out の記事で、Google の記述から条件節が落ちていたのを訂正しました。 Google が違反としているのは「fan-out クエリごとにページを作ること」そのものではなく、順位や生成 AI の回答を操作することを主目的として、検索の変化形ごとに別コンテンツを大量に作る場合です。この条件を落とすと、正当なトピック網羅まで違反であるかのように読めます。 英文の引用自体は条件節を含んでいましたが、日本語の要約 3 箇所で落としていました。
    • 条件を落とさないことと、弱めないことは両方必要です。 この記述の引用では (1)「非推奨」ではなく「スパムポリシーに違反する」と書かれている点を弱めない、(2) 条件節「操作を主目的として」を落とさない、の両方を守ります。片方だけを守ると、過小にも過大にもなります。 なお条件を満たさない場合でも「ページ数の多さは品質にも関連性にも寄与しない」という効果面の否定は残ります。
    • 資料の題名について、確認時点の候補（<title> / og:title / <h1>）を保存するようにしました。 後で題名が変わったときに、こちらの記録が誤っていたのか、資料側が題名を変えたのかを区別するためです。保存が無いとこの 2 つを切り分けられません。pnpm content:check-titles -- --write で記録します。
61. 2026.08 第16版2026-08-11臨時改訂

    Query Fan-out の解釈方針を公開し、資料の題名検査をツール化した

    6

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.12（チェックリスト v2）のままです。
    • Query Fan-out の解釈モデルを公開しました。Query Fan-out 自体は Google 公式の技術であり、SILVE のものは解釈と運用方針だけです。 Fan-out は Google 側の取得アーキテクチャであってサイト側のシグナルではないため、独立したスコアを作りません。
    • Google が「fan-out クエリごとにページを作ること」を名指しで警告している点を中核に据えました。 人々が検索し得るあらゆる変化形ごとに個別コンテンツを作ることは、順位や生成 AI の回答を操作する目的であれば scaled content abuse のスパムポリシーに違反すると明記されています。さらにページ数の多さはサイトの品質にもユーザーにとっての関連性にも寄与しないとされています。「非推奨」と弱めて引用しません。
    • 検索回数は公開されていません。 公式資料の表現は concurrent, related queries / multiple related searches / a multitude of queries であり、固定値は示されていません。2025 年 11 月の Gemini 3 導入時には「より多くの検索を実行できるようになった」とされており、回数はモデルの更新で変わります。 「Fan-out は平均○回」という数字は確認した公式資料には存在しません。
    • 内部の fan-out クエリは観測できません。 Search Console の生成 AI レポートにクエリの次元は含まれていません。第三者ツールが出す推定を Google の一次データと区別し、推定結果を採点の根拠にしません。
    • 資料の題名検査をツールにしました（pnpm content:check-titles）。この検査はこれまでに 9 件の誤った題名を検出しています。媒体によって <title> と読者向けの見出しが違うため、<title> / og:title / <h1> の 3 候補と照合するようにしました。1 候補だけで照合すると偽陽性が出続けて検査が信用されなくなります。現在 49 件すべてが一致しています。
62. 2026.08 第15版2026-08-11臨時改訂

    AI 上の露出を 5 段階に分け、測定の信頼性条件を固定した

    8

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.12（チェックリスト v2）のままです。
    • AI Visibility Vector を公開しました。「AI に出た」には言及・引用・推薦・選択・行動という 5 つの違う現象が隠れています。 これは 2026.08.5 で「未実装」としていた Visibility 列の中身を定義したものです。
    • Citation ≠ Ranking ≠ Authority ≠ Traffic ≠ Answer Influence を提供元の記述で固定しました。あわせて Microsoft は、引用の活動がモデルの進化・競合コンテンツ・鮮度シグナル・ユーザー需要・パートナーの更新周期に影響され得ると述べています。引用が増えても施策の成果とは即断できません。
    • 単発のプロンプト結果を順位と呼ばない根拠を具体化しました。 45 研究のレビューによれば、4 エンジン・45 日間で日次の情報源の重なりは Jaccard 係数 約 0.34〜0.42、米独 4,706 クエリでの 2 か月間のページの重なりは AI Overviews で 18%（オーガニック検索は 45%）、温度 0 の反復でも判断の 9〜28% が変わります。 測定は run / paraphrase / date / engine の 4 次元を変える必要があります。
    • 固定試行回数を規範にしません。 「1 プロンプトあたり 7〜8 回」はある研究の出発点であり、レビュー自身が「普遍的な標準ではない」と明記しています（スイスのクエリという小さな母集団と最大 10 回の反復に由来）。本来は判断に必要な精度に達するまで測る逐次的な精度分析です。
    • null を捨てません。 検索が起動しなかった回答を除外すると選択バイアスになります。同レビューが引用する構成では ChatGPT の反復のうち 57.8% が Web 検索を起動しませんでした。 引用を含む回答だけを分母にした値を全体の可視性と呼ぶことはできません。指標名に分母を含めます。
    • Readiness と Visibility で扱いを逆にする方針を明文化しました。 Readiness では一つのシグナルを一度だけ採点して複数段階へ写像し、Visibility では実際に起きた出来事を段階別に分解して記録します。
    • 資料の取得についての記録を訂正しました。 openai.com は取得クライアントによって 403 を返すため、当初「アクセス制限」として Internet Archive のキャプチャで確認したと記録していましたが、実際には現行ページを読めました。 到達性チェックがブラウザの User-Agent を送るよう修正し、「取得できなかった」は資料の性質ではなくこちらの試行についての事実である、という規則を追加しました。
63. 2026.08 第14版2026-08-11臨時改訂

    ビジネスプロフィールの対象条件を訂正し、版番号の表示を明確にした

    5

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.12（チェックリスト v2）のままです。
    • Google ビジネスプロフィールの記述を訂正しました。 前版では「オンライン専業は対象外という否定形の明記は確認できていない」として確信度を下げていましたが、Google は明記していました。 「Business Profiles aren't for online-only businesses」「Only businesses that make face-to-face contact with customers are eligible」「a business must make in-person contact with customers during its stated hours」であり、対象外の一覧に「ブランド・団体・アーティスト・その他のオンライン専業の事業」が挙げられています。確信度を high に戻しました。
    • 探索不足の原因も記録しました。 表記や住所の指針を書くページだけを見て、対象条件を書く別ページを開いていませんでした。同一のヘルプセンター内でも、条件を書くページと運用指針を書くページは別です。 「あるページに無いことは同一ドメインの別ページにも無いことを意味しない」の再実例として資料に残しています。
    • 版番号の表示を明確にしました。 版番号の第 3 要素は「その系列の何番目の改訂か」を示す連番であって日付ではありません。2026.08.13 は 8 月 13 日ではなく「2026.08 系列の 13 番目の改訂」です。変更履歴では版番号とリリース日が並ぶため誤読を招きやすく、表示を 「2026.08 第13版」 の形に変えました。保存している識別子そのものは変更していません（公開済み版の識別子を変えると、その版で採点した診断との対応が切れるため）。
    • 2 つの原則を Canonical Principle として明文化しました。 (1) 資料の格は適用範囲を広げない — 査読済み・公式であることは、その資料が述べていない領域の主張を支えません。(2) 部分一致の資料で複合 Metric を格上げしない — Metric が複数の判定を束ねている場合、その一部を直接支える資料が見つかっても evidenceDirectness を direct へ上げません。
64. 2026.08 第13版2026-08-11臨時改訂

    エンティティの扱いを整理し、共起と外部言及を採点しない根拠を固定した

    9

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.12（チェックリスト v2）のままです。
    • Entity Identity Readiness を公開しました。中心原則は 「エンティティを強くするのではなく、曖昧でなくする」 です。「強くする」と言った瞬間に、言及数や知名度の代理指標になります。
    • Knowledge Graph Search API を判定に使わない根拠を記録しました。 Google 自身がこの API を読み取り専用とし、本番の重要な処理が依存すべきではないと明記しています。さらに相互に接続されたグラフではなく個々のエンティティのみを返します。提供元が本番依存を想定していない道具を、診断の判定基準にはできません。
    • 外部言及の件数を採点しない根拠を固定しました。 Google は生成 AI 機能がブログ・動画・フォーラムの内容を示し得るとしつつ、不自然な言及の獲得は見た目ほど役に立たないと明記しています。前半と後半の両方を引きます。
    • 共起（Co-occurrence）の適用範囲を限定しました。 共起統計がエンティティ解決に役立ち得ることには研究の裏づけがあります（NAACL 2018 の ELDEN）。しかし同論文はエンティティリンキングのベンチマークを評価しており、検索順位にも生成 AI での可視性にも言及していません。 「共起を増やせば AI に推薦される」は根拠の適用範囲を超えます。査読済みであることは、その主張の適用範囲を広げません。
    • sameAs は同一性を示すプロパティであって権威の蓄積ではないため、URL の件数を採点しません。 Wikipedia・Wikidata・ナレッジパネルの有無も報告のみとします。AI 検索目的での Wikipedia ページ作成は推奨しません。
    • 部分的に一致する資料を格上げしない判断を記録しました。 Google は Organization 構造化データについて「サイト名と同じ name / alternateName を使う」よう推奨しており、表記の一貫性には公式根拠があります。しかし authority.entity_consistency が実際に検出しているのは日本語の表記揺れであり範囲が違うため、evidenceDirectness は inferred のまま据え置きました。
    • Google ビジネスプロフィールの対象事業を確認しました。対象は物理的な所在地を持つ事業か顧客のもとへ出向く事業です。オンライン専業のサービスにエンティティ対策として勧めるのは不適切です。
    • SILVE 自身のブランド改名が未完了であることを記事に明記しました。 silve.jp は未取得、旧ドメインからのリダイレクトは未設定、外部プロフィールの統一も未着手です。自分たちができていないことを、できているかのように書きません。
65. 2026.08 第12版2026-08-11定期改訂採点

    構造化データの配点を 20 から 7 へ引き下げた（採点変更）

    7

    • これは採点の変更です。 チェックリスト v2 を公開しました。変更したのは構造化データ 4 項目の重みだけで、検出ロジックも他の項目の重みも変えていません。
    • structured_data.present 5 → 3 / structured_data.organization 8 → 2 / structured_data.article 5 → 1 / structured_data.breadcrumb 2 → 1。配点対象の合計 20 → 7、実効重み 104 → 91、全体に占める割合は約 19% → 約 8% です。
    • 理由は Google 自身の記述です。 生成 AI 検索に構造化データは必須ではなく、追加すべき特別な schema.org マークアップも存在しないと明記されています。有用性として挙げられているのは通常の検索でのリッチリザルトの対象化です。SILVE はこれを最初から根拠の直接性 supporting として記録していましたが、supporting な根拠しか持たない項目群がスコアの約 1/5 を決めている状態は説明できませんでした。
    • とくに structured_data.organization の 8 点は「ブランドを実体として認識させる起点」という理由づけでしたが、Organization スキーマでブランドが実体として確立される、あるいは生成 AI での露出が上がるという根拠は確認できていません。 ここが最大の過大評価でした。
    • 0 にはしていません。 同じ資料が「通常の SEO 戦略の一部として使い続けるのは良い考え」とも述べているためです。0 にするのは根拠の読み違いで、方向が逆に振れるだけになります。
    • サイトを変更していなくてもスコアが動きます。 これは基準側の変更であり、診断結果では「サイト側の変化」と「評価基準の更新による影響」に分けて表示されます。実走（cybozu.co.jp）では 38 点 → 42 点で、内訳はサイト側 +0 / 基準側 +4 です。構造化データの評価が低いサイトほど、その重みが下がった分だけスコアが上がります。
    • 段階モデルのカバレッジも更新しました。段階 2（Retrieval）の配点が 40 → 27 になり、配点の 68%（91 のうち 62）が段階 1〜2 に集中する形になっています（従来は 72%）。
66. 2026.08 第11版2026-08-11臨時改訂

    構造化データの位置づけを整理し、自社の配点に見直し候補を立てた

    7

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.3 のままです。
    • 「構造化データ」を 5 層に分けました。 セマンティック HTML / ページ構造化データ（Schema.org）/ プラットフォームフィード（Merchant Center・OpenAI 商品フィード）/ データ API / アクションプロトコル。すべて機械可読ですが、渡す相手も目的も違うため一つのスコアにまとめません。
    • Google は「生成 AI 検索に構造化データは必須ではなく、追加すべき特別な schema.org マークアップも存在しない」と明記しています。 ただし同じ文書が、通常の SEO の一部として使い続けるのは良い考えだとも述べています。片方だけを引かないようにしました。
    • 対照的に、Merchant Center フィードと Google ビジネスプロフィールについては「AI の回答と通常の検索結果の両方で可視性に役立ち得る」と明記されています。 構造化データとフィードを同じ扱いにしない根拠です。
    • フィードの利点は鮮度です。Google はフィードを週次・日次・時間単位で任意のタイミングに更新できるとする一方、サイトの変更がクロールで処理されるまでの時間は保証しないとしています。ただし「両方入れれば万全」でもありません。 サイトとフィードを併用すると遅延によるデータ不整合が生じ得ると Google 自身が述べています。
    • ★ 自社の配点に見直し候補を立てました。 現在 SILVE は実効重み 104 のうち 20（約 19%）を構造化データに置いています。「AI 検索の必須条件ではない」と書きながら 19% を配分している状態を隠さずに記録し、次の見直し対象としました。見直すときは「Google 検索での理解とリッチリザルト対象化への寄与（根拠あり）」と「生成 AI での露出への寄与（根拠なし）」を分けて考えます。
    • プラットフォームフィードへの対応は採点していません。 公開サイトを見るだけでは連携の有無を判定できない場合があるためです。判定できないものは推測せず「観測できない」と表示します。また、メディアサイトに商品フィードが無いことのように、その事業に不要なデータ経路の不在を減点しません。
67. 2026.08 第10版2026-08-11臨時改訂

    ブランド名を SILVE（シルヴェ）へ変更した

    5

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.3 のままです。名称以外に変わったものはありません。
    • サービス名を「aiopt」から SILVE（シルヴェ） へ変更しました。正式表記は SILVE - シルヴェ -｜AI検索時代の道標。 です。過去の記事・用語集・方法論の文書もすべて新名称に統一しています。
    • ドメインを silve.jp へ変更しました。記事内の URL、構造化データ、スキーマの識別子も合わせています。
    • 診断クローラの User-Agent を aioptBot から SilveBot へ変更しました。 robots.txt で旧名を名指しして許可・拒否していた場合は、SilveBot への書き換えが必要です。クロールの挙動（robots.txt の尊重、1 ページのみ取得、同一ホストへの間隔）は変更していません。
    • 過去に公開した版の判断内容は書き換えていません。 変更したのは名称の表記だけで、各版の項目・重み・根拠・確信度はそのままです。
68. 2026.08 第9版2026-08-11臨時改訂

    資料の題名を実ページと突き合わせ、8 件の誤りを訂正した

    7

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.3 のままです。
    • 記録していた資料の題名を実際のページと機械的に突き合わせ、8 件の誤りを訂正しました。 いずれも URL や見出しから題名を推測して記録したもので、そのままでは読者がその題名で検索しても資料に辿り着けません。例: 「Bots — OpenAI Developers」は実際には「Overview of OpenAI Crawlers」、「About Anthropic's web crawlers」は実際には「Does Anthropic crawl data from the web, and how can site owners block the crawler?」でした。
    • 資料の題名を確認した日（canonicalTitleVerifiedAt）を記録するようにし、公式資料でこれが欠けている場合は警告するようにしました。確認時は英語で取得します。 ロケールによって題名が翻訳されて返るため、そのまま記録すると英語の一次資料に別言語の題名が付きます。
    • 取得できないことと、資料が消えたことを分けて記録するようにしました。 401 / 403 はアクセス制限、429 はレート制限であって消失ではありません。公式資料ほど自動取得を拒否するため、これを消失と同じ扱いにすると一次資料ほど偽陽性を出し、検査そのものが信用されなくなります。
    • アーカイブは「当時こう書かれていた」の証明であって「現在もそうである」の証明ではないという規則を機械検査に加えました。現行仕様についての主張をアーカイブだけで支えている場合は警告します。逆に、命名日の反証のような過去についての主張ではアーカイブが最良の根拠になります。
    • Lighthouse の Agentic Browsing カテゴリと WebMCP サポートについて、Chrome 自身が experimental であり提案段階の標準に基づくと明記していることを記録しました。 エージェント対応を重く配点しない根拠がさらに強くなっています。テストには Chrome 150 以降が必要で、オリジントライアル開始時点の Chrome 149 とは別の情報です。バージョン番号を固定して引用しません。
    • 再検証の期限を、採用状態でも決めるようにしました。candidate は 45 日、provisional は 60 日です。固まっていないものほど早く古くなるためで、証拠の種類だけで決めると提案段階の仕様と確立した Web 標準が同じ期限になってしまいます。
69. 2026.08 第8版2026-08-11臨時改訂

    エージェント対応の判断基準を公開し、資料の取り違えを訂正した

    8

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.3 のままです。
    • Agent Readiness の操作モデルを公開しました。測るのは「AI に選ばれるか」ではなく「AI が操作を完了できるか」です。 推薦されるかどうかは別レイヤー（Visibility）として扱います。
    • セマンティック HTML を AI 検索のランキング要因として扱わない根拠を明記しました。 Google 自身が「完璧にセマンティックな HTML であることは必須ではない」と述べ、その価値をスクリーンリーダーなど他の利用者への配慮として位置づけています。一方 web.dev はブラウザエージェントの操作性という別の観点から推奨しています。目的が違うだけで矛盾はしませんが、混ぜて「AI 対策になる」と説明することはしません。
    • 資料の取り違えを訂正しました。 Google には題名の似た別々の 2 ページがあります。「Explore agentic experiences」の節を持つのは fundamentals/ai-optimization-guide、技術要件を扱うのは appearance/ai-features です。2026.08.5 と 2026.08.7 で追加した 2 件の証拠台帳が、後者の URL に前者の題名を記録していました。引用した本文は正しい URL のものなので、主張の内容に誤りはありません。
    • 出典の混同を防ぐ検査を記録しました。 操作要素の名前とラベルを審査項目として挙げているのは Lighthouse の agentic browsing であって web.dev ではありません。web.dev の記事本文には accessible name と aria-label という語が一度も出てきません（語の出現数まで確認済み）。エージェント対応項目の説明で web.dev を単独の根拠にしません。
    • WebMCP を実験段階として記録しました。Chrome の Early Preview は 2026 年 2 月 10 日、オリジントライアルは 2026 年 6 月 9 日に告知され Chrome 149 から開始です。仕様が固まっていないため採点しません。 実装していないことは対応不足を意味せず、実装が AI 検索で有利になる根拠もありません。
    • エージェントのためにセキュリティを弱めないことを原則として明記しました。 認証や確認で止まることは Readiness の失敗ではありません。OpenAI は ChatGPT のエージェントが購入の完了のような手順の前に確認を求めると説明しています。また、エージェント向けの隠し指示は最適化ではなくプロンプトインジェクションであるため、採点も推奨もしません。
    • 資料 URL の到達性チェックで、消失（404 / 名前解決の失敗）と自動取得の拒否（401 / 403 / 429）を分けるようにしました。ブラウザでは読めても機械的な取得を拒否する一次資料があり、これを消失と同じ扱いにすると誤警報が続いて検査自体が信用されなくなるためです。
70. 2026.08 第7版2026-08-11臨時改訂

    AI クローラ定義を一次資料で検証し、未検証を 11 件から 1 件に減らした

    7

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.3 のままです。採点対象となる掲載経路クローラは 6 件のままで、実走スコアも変わっていません。
    • 未検証だったクローラ定義 11 件のうち 10 件を一次資料の本文で確認しました。 Anthropic・Perplexity・Apple・Microsoft・Common Crawl・Meta の公式文書を読み、用途の分類と verifiedAt を更新しています。これまでは分類はしていても裏取りが済んでいませんでした。
    • Perplexity の分類の誤りが判明する可能性を潰しました。 Perplexity は公式に「PerplexityBot を基盤モデルの学習には使わない」と明記しています。したがって PerplexityBot のブロックは学習の拒否ではなく検索掲載の拒否であり、掲載経路として扱う現在の分類が正しいことを確認しました。
    • Meta のクローラ分類を修正しました。 meta-externalagent は学習だけでなくコンテンツの直接索引にも使われます。ただし用途が同じ User-agent に同居しており、ブロックされていても学習を拒否したいのか掲載を拒否したいのか判別できません。分類には両方の用途を持たせたうえで、掲載経路としては採点しない扱いにしました。meta-externalfetcher（ユーザー起点取得）を追加しています。
    • Apple の学習用途を制御トークン側（Applebot-Extended）に持たせました。Google で Googlebot ではなく Google-Extended に学習を持たせているのと同じ扱いに揃えています。Applebot を名指ししただけで学習方針を表明したと判定されるのを避けるためです。
    • anthropic-ai の注記を訂正しました。従来「過去に案内されていた UA」としていましたが、確認できるのは現行の公式文書が 3 つのボットのみを記載していることだけです。過去に公式案内されていたことの証拠は確認できていません。
    • Bytespider（ByteDance）は未検証のまま残しています。 公式ドキュメントを複数経路で探索しましたが見つからず、これまで出典として記録していた URL は現在名前解決できません。第三者のクローラ情報サイトは一次資料ではないため分類の根拠にしません。未検証であることを表示し続けます。
71. 2026.08 第6版2026-08-11臨時改訂

    フレームワークの根拠を機械検証の対象にし、引用の価値についての表現を対称にした

    5

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.3 のままです。
    • フレームワーク記事の根拠を機械可読な台帳にしました。 これまで用語記事だけが検証機構の対象で、SILVE 自身のモデルを説明する記事の根拠は人手管理でした。プラットフォームの仕様は研究より早く古くなるため、こちらのほうが自動での再検証が要る領域です。台帳が無いフレームワーク記事は検証が失敗します。
    • 再検証期限を機械が言うようにしました。 公式仕様は 120 日、研究は 365 日を既定とし、プレビュー中の機能仕様（Google の生成 AI レポート、Bing の AI Performance）は 90 日に短縮しています。期限超過は警告であり、編集は止めません。時間の経過を理由に作業が止まると、検証機構そのものが外されるためです。
    • 一次資料の要件を機械検査に追加しました。プラットフォーム仕様に関する主張を業界メディアの記事だけで支えることはできません。公式と位置づける主張には、提供元自身の資料が必要です。
    • 引用の価値についての表現を対称にしました。 Microsoft は AI 回答内での露出も見るべきだと述べており、一方で 45 研究のレビューは「引用が流入・売上を予測する」の確信度を Very low としています。前者は提供元自身の解釈と業界調査に基づくもので因果の証明ではなく、後者もレビュー範囲での評価であって価値の不在の証明ではありません。したがって SILVE は「引用に価値があるとも無いとも、現時点では一律には言えない」までに表現を留めます。
72. 2026.08 第5版2026-08-11臨時改訂

    測定の 3 レイヤーを正本化し、研究数値の記録ミスを訂正した

    6

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.3 のままです。
    • AI Readiness / Visibility / Outcome Model を公開しました。Readiness（AI が使える状態か）・Visibility（実際に使われたか）・Outcome（事業に何が起きたか）を別の量として扱い、単一スコアへ合成しないことを明文化したものです。段階モデル（7 段階）とは直交する軸です。
    • プラットフォーム間で指標を比較しない規則を追加しました。Google の生成 AI レポートは同一サイトの複数結果を 1 インプレッションに合算する一方、Bing の AI Performance は引用ごとに計上します。数え方が違う量の比・差分・合計は意味を持たないため、Visibility は提供元の指標定義を保持したまま別々に保存します。
    • 各社が自ら明記している限界を記録しました。Bing は引用回数について「ランキング・権威性・ページ重要度・掲載位置を示すものではない」と述べ、Citation Share についても「競合ドメインを開示せず、トラフィックシェアでもない観測指標」としています。Google の生成 AI レポートにはクリック・CTR・掲載順位が含まれていません。
    • 引用と事業成果の関係を未確立として記録しました。45 研究を対象とした 2026 年 7 月のレビューは「引用スコアがクリック・コンバージョン・売上を予測する」という主張の確信度を Very low としています。一方で Microsoft はクリック以外のシグナルへ分析を広げるべきだと述べており、両方向の断定を避けます。
    • 研究数値の記録ミスを訂正しました。AEO レコードが Watanabe & Nakayashiki の 5.7 倍を「プラットフォーム全体」の成長率として注記していましたが、正しくは対象サイト全体の ChatGPT 経由参照の値です。対照群 3.5 倍・処理群 6.1 倍との位置関係とも整合します。引用していた主分析の推定値（1.82 倍）に誤りはありません。
73. 2026.08 第4版2026-08-11臨時改訂

    診断の段階モデルを公開し、資料の記録ミスを訂正した

    7

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 2026.08.3 のままです。
    • AI Information-to-Action Pipeline（7 段階の操作モデル）を公開しました。Discovery / Retrieval / Usage / Citation / Recommendation / Selection / Action・Transaction の 7 段階で、どの用語がどの問題を扱っているかを整理するものです。業界標準の分類ではなく SILVE の操作モデルであることを明記しています。
    • 現在の診断項目を 7 段階へ割り当てた結果を公開しました。配点の 72%（104 のうち 75）が段階 1〜2 に置かれており、段階 5（推薦）と段階 6（選択）は 1 項目も測っていません。空欄を埋めるために根拠の薄い項目を追加することはしません。
    • 用語ごとの独立スコアを作らない方針を明文化しました。crawlability が SEO / AEO / GEO / LLMO のすべてに関係するように、同じシグナルが複数の用語にまたがるため、用語別のスコアは同一シグナルの二重採点になります。
    • 資料の記録ミスを訂正しました。Google の生成 AI 向け最適化ガイドについて、7 件の用語レコードが別ページのタイトルを記録していました。正しくは「Optimizing your website for generative AI features on Google Search」です。URL は正しかったため、引用内容そのものに誤りはありません。
    • 資料に lastUpdated を追加しました。プラットフォーム公式文書は公開日を出さず最終更新日だけを表示することが多く、両者を publishedAt に混ぜると資料の古さを誤って伝えるためです。
    • GEO レコードのプレプリント要約を訂正しました。同レビューの abstract が挙げる 9 段階のうち、顕出性（prominence）と忠実性（fidelity）の 2 つを落としていました。あわせて、同レビューが粒度の異なる 3 通りの分解を提示していることを注記しました。
74. 2026.08 第3版2026-08-11臨時改訂

    エージェント操作の観点を 3 項目追加した

    7

    • 「AI に読まれるか」と「AI に操作できるか」は別問題です。後者について、Chrome が公開している agentic browsing の審査基準に基づく 3 項目を追加しました。
    • agent.control_names（操作要素の名前とセマンティクス、配点 4）— Chrome の審査は names/labels を明示しており、web.dev は改造した div/span より button と a を使うこと、それが無理なら role と tabindex を与えることを推奨しています。
    • agent.form_labels（フォーム入力欄のラベル、配点 3）— web.dev は label の for 属性について「AI エージェントがその欄の目的を理解する助けになる」と明記しています。for のほか aria-label / aria-labelledby / title / label による内包も可としています。
    • agent.layout_stability（レイアウト安定性、配点 2）— Chrome は CLS を審査対象としていますが、CLS はページを描画しないと測れません。ここでは寸法未指定の画像・iframe という代表的な原因を代理指標として観測しているだけなので、直接性を supporting、確信度を低とし、最小配点に留めました。
    • 3 項目とも対象プラットフォームは「エージェント」のみです。AI 検索に引用されるかどうかには影響しません。効く先を広げて書かないことを方針としています。
    • 配点を抑えている理由は 2 つあります。第一に Chrome 自身が「エージェントウェブの標準はまだ形成途上」として加重平均による順位付けを避けていること、第二に静的 HTML 解析では JavaScript で後付けされた操作要素が見えず、検出数が下限値にとどまることです。
    • 操作要素・入力欄・画像が検出されなかった場合は減点しません。存在しないものの不備を減点する扱いを避けるためです。
75. 2026.08 第2版2026-08-11臨時改訂

    根拠の「直接性」を導入し、数値記述の確信度を下げた

    5

    • 各項目に evidenceDirectness（直接性）を追加しました。「査読済み論文を引いている」ことと「その論文がこの項目を検証している」ことは別であり、資料の格だけを見ると、実際には検証されていない主張まで強い根拠があるように見えるためです。
    • content.numeric_evidence（数値・データの記述）の確信度を「高」から「中」に下げました。根拠としていた GEO 論文を再検証したところ、2 つの問題が判明したためです。
    • 第一に、著者らの公式実装は統計追加のプロンプトに "even if hypothetical"（架空でも可）を含んでおり、実験が測定したのは架空を含む「統計の形をしたテキスト」の効果でした。第二に、実験対象はすでに回答生成の文脈に入っている情報源であり、発見されやすくなることは示していません。
    • この項目が測っているのは記述の具体性であって真偽ではなく、検出器は正しい数値と捏造された数値を区別できません。改善提案では「検証可能な数値」と明示し、数値を足すこと自体を目的化させない方針にしました。
    • 同じ論文を根拠にしていた content.definition と content.answer_density についても、論文が当該項目を検証していない旨を注記に明示しました。
76. 2026.08 第1版2026-08-11臨時改訂

    AI クローラの分類を用途別に是正

    5

    • 「AI クローラをブロックしている数」で一律に減点していた項目 (crawlability.ai_bots) を廃止しました。掲載経路の遮断と学習の拒否という、性質のまったく異なる 2 つを同じ配点で扱っていたためです。
    • 掲載経路 (crawlability.ai_search_access) を採点対象とし、学習クローラの許可状況 (crawlability.ai_training_policy) は採点しない参考情報に変更しました。基盤モデルの学習を拒否することは正当な知財ポリシーであり、減点する根拠がありません。
    • この結果、GPTBot や Google-Extended を拒否しつつ OAI-SearchBot を許可している構成は減点されなくなります。知財管理が厳格な企業ほど不当に低く出る、以前の挙動を是正するものです。
    • Google-Extended のラベルを修正しました。これは Gemini の学習と grounding を制御するもので、Google Search および AI Overviews への掲載には影響しません。
    • llms.txt を暫定採用 (provisional) に変更し、スコアへの反映を停止しました。検出と説明は従来どおり行います。
77. 2026.08 第0版2026-08-01定期改訂

    初回リリース

    1

    • AI Readiness の 23 項目による初版基準を公開しました。

バージョン履歴

• v72026/8/15提供元の一次資料に当たり直して、配点を根拠の強さへ合わせた版。実効重みは 91 から 79 になり、スコアが変わる。Google は「Things we believe you shouldn't focus on」節で「見出しの順序と数は Google 検索の観点では効かない」「E-E-A-T はランキング要因ではない」を明記しており、生成 AI 向けガイドは「独自で有用なコンテンツが、このガイドの他のどの提案よりも効く」としている。最も効くと提供元が言っているものは、SILVE が決定論的に測れないものである。だからこそ測れる代理指標の配点を、実際の根拠より重くしない。定義文 5→0（直接の資料が無く、同じ状態の質問見出しは配点 0 だった）、著者 6→3、見出し階層 5→2、段落の自己完結性 3→2。空いた 12 点は配り直していない。実効重みは根拠の合計であって定数ではない。
• v62026/8/15配点の理由を、根拠の注記に合わせた版。重みは 1 つも変えていないのでスコアは動かない。記事 22 本の外部レビューを一巡した結果、見つかった誤りの大半は事実誤認ではなく「証拠の射程を超えた書き方」だった。同じ型が診断ツール側に残っていた。各項目の根拠の注記は慎重に書かれているのに、利用者が読む説明文と配点の理由が、その注記が「確認できていない」と書いている効果を断定していた。定義文・日付・著者・見出し階層の 4 項目で、注記と説明を揃えた。
• v52026/8/15観測できなかった項目を満点にするのをやめた版。項目・重み・判定ロジックは v4 と同じで、変えたのは「対象が 1 件も見つからなかったときにどう採点するか」だけ。操作要素・入力欄・画像が 0 件のとき、従来は満点にしていたが、静的 HTML の解析では JavaScript で後から作られる要素が見えないため、0 件は「欠点が無い」ではなく「観測できていない」場合がある。観測できなかったものを満点に変換すると、測れていないサイトほど高得点になる。今後は分子からも分母からも外す（0 点にはしない）。Not observed ≠ Pass。
• v42026/8/151 回の診断で見るページ数を、版の値として固定した版。項目・重み・採用状態・判定ロジックは v3 から変えていないので、同じページを見るかぎりスコアは動かない。ページ比率で段階を分けている項目 (JavaScript 依存・canonical・構造化データの有無) は見るページ数が変われば取り得る値が変わるため、ページ数は環境設定ではなく採点方法の一部である。版に持たせたことで、古い版で測り直すと当時のページ数が復元される。
• v32026/8/15llms.txt をクロール可能性からエージェント対応へ移した版。判定ロジックも重みも他項目も変えていない。どちらも配点対象外なので実効重みは 91 のまま。Google が「Google Search は llms.txt を使用せず、可視性にも順位にも影響しない」と明記しているのに、検索側のカテゴリに置いていたため「これが無いから AI 検索に出ない」と読まれる位置にあった。効く先は Chrome の agentic browsing 側である。
• v22026/8/15構造化データ 4 項目の重みだけを引き下げた版 (合計 20 → 7)。検出ロジックも他項目の重みも変えていない。Google が「生成 AI 検索に構造化データは必須ではなく、専用の schema.org マークアップも存在しない」と明記しているのに対し、v1 では supporting な根拠しか持たない項目群が実効重みの約 19% を占めていたため。0 にはしない。同じ資料が通常の SEO の一部として使い続けるのは良い考えだとも述べている。
• v12026/8/15固定コアとして「AI に読まれるか」(クロール可能性・JS 非依存) を最重量に置き、エージェント対応は今後の論調で動かす余地を残して控えめに配点している。根拠が確立していない項目は暫定採用とし、検出はするが配点しない。