項目の説明から、廃止した語彙と事実誤りを外した版

基準の変更履歴

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

文中の ★ は、私たちが特に重く見ている点の目印です（多いほど重く見ています）。編集上の目印であって、測った値ではありません。

1. 2026.08 第224版2026-08-24定期改訂表現結果に影響なし

   押すと空になるリンクを、記事一覧から外しました

   7

   • ★★★ 記事一覧のカテゴリ 6 個のうち、5 個が「該当する記事がありません」でした。 中身があったのは「AEO / GEO / LLMO 解説」だけで、最新ニュース・実践Tips・今週のまとめ・AAO 視点・エージェント vs アシスタントは、押しても空のページでした。
   • ★★ 原因は、カテゴリの「定義」をそのままリンクにしていたことです。 定義は「置きうる棚」であって、「中身のある棚」ではありません。 記事が入っているカテゴリだけを、件数つきで出すようにしました（タグはもともと件数つきで出しています。同じ「記事の本数」なので並べられます）。
   • ★★ 同じ型を一度潰していました。 記事 0 本の「今週のまとめ」をメニューから外した回です。あのときメニューは直しましたが、記事一覧の絞り込みは直していませんでした。 原則を書いた場所と、原則が効くべき場所がずれる —— 私たちが繰り返している型です。
   • ★ 数から作るので、二度と空になりません。 記事を入れれば勝手に出ますし、最後の 1 本を下げれば勝手に消えます。手で並べ替える表は持ちません。
   • ★ こちらからリンクは貼りませんが、?category= を直接開かれたときは絞り込みとして受け取り、「該当する記事がありません」と正直に出します。 貼らないことと、来た URL を無視することは別です。
   • 検査を足しました。 定義から ?category= のリンクを組み立てていないかを見ます。わざと壊して、実際に落ちることを確かめてあります。
   • 測る内容は変わりません。
2. 2026.08 第223版2026-08-22定期改訂表現結果に影響なし

   紙から来た人が、最初の画面で行き先を見つけられるようにしました

   4

   • ★★ 書籍に刷られる QR を実際に取り出して読んだところ、行き先は https://silve.jp/（トップページ）でした。 そこに書籍への言及が 1 つもありませんでした。 「Web Companion は公式サイトから案内する」と紙に印刷されるのに、着地した最初の画面で案内が切れていました。
   • ★ トップページに 1 行足しました。 新しい面は作っていません —— 「概念モデルが多すぎる」という外部レビューを受けて圧縮したばかりなので、既に「根拠は全部公開している」と述べている節の中に置きました。同じことを言っている節なので、増やさずに済みます。
   • ★★ 記事の本数には足していません。 「全 ◯ 本」の外に置いています ——本 1 冊と記事 1 本を同じ 1 として数えないという、/articles と同じ扱いです。
   • 測る内容は変わりません。
3. 2026.08 第222版2026-08-21定期改訂表現結果に影響なし

   書籍のページを作りました

   7

   • ★★ これは宣伝の枠ではありません。 書籍『AI検索の設計術』の巻末が「個別ページの URL は刊行時点で固定せず、SILVE 公式サイトを恒久的な入口とする」と印刷するため、紙を持った方がこのサイトへ Web Companion を探しに来ます。 URL は印刷より先に存在している必要があります。
   • ★★ メニューは増やしていません。 利用者の指摘 ——「記事もメディアなので新たにメニューを作るより統合すべきでは」。そのとおりです。 書籍は記事と同じ「読むもの」で、別の入口を要するものではありません。 フッターの「メディア」と、記事の一覧・読む順番のページから行けるようにしました。
   • ★★★ 記事の一覧には混ぜていません。 一覧は「全 ◯ 本」と数えています。そこへ 1 冊足すと数が 1 増えます。 本 1 冊と記事 1 本を同じ 1 として数えることになり、これは私たちがいちばんやらないと決めた形です。 同じ画面に、別の枠として置き、数には入れません。
   • 章と記事の対応表を置きました。 記事のほうが細かいので 1 対 1 ではありません（用語の 7 本が 1 つの章に入ります）。★ これは判断であって、機械で導けるものではありません。 手で書いたものはずれるので、読む順番に載っている記事が対応表にちょうど 1 回現れることを検査で見ています。
   • ★★★ 正誤表を、1 件も無いうちから置きました。 「公開済みの版は編集しない。訂正は新しい版で出す」を、紙にも適用した形です。刊行後に誤りが見つかったときは、本文を書き換えたことにせず、何をどう間違えたかを残します。
   • ★ 発売日は書いていません。決まっていないからです。 検査が、発売前に日付が入っていないことを見ています。
   • 測る内容は変わりません。
4. 2026.08 第221版2026-08-21定期改訂表現結果に影響なし

   ★ の意味を書き、規約と売り文句の言い方をそろえました

   5

   • ★★★ ★ が画面に 800 箇所以上出ていることに気づきました。 変更履歴に集中していますが、記事の本文にも出ます。消すことも考えましたが、これは記法の漏れではなく、書き方そのものでした ——「★ 重要な一文」という形で、どの版でも、どの記事でも同じ意味で使っています。
   • ★★ 問題は記号があることではなく、意味がどこにも書いていないことでした。 説明の無い 3 段階の目盛りは、私たちがいちばん嫌う形です（閾値は重みと同じで校正できない）。変更履歴の先頭に、編集上の目印であって測った値ではないと書きました。
   • ★★ 利用規約を第 1.3 版にしました。 第 7 条の「改善手順」を「直し方の案内」に改めています。画面で使う呼び名を変えたので、規約だけが、いまは使っていない名前で同じものを指していました。 免責の範囲は変わらず、利用者の義務を新たに課すものでもありません。
   • ★★ 「稟議や依頼の下書きに要る時間が消えます」を書き直しました。 どれだけ短くなるかは測っていません。 測っていない効果を、「消える」という一番強い言い方で書いていました。 言えるのは出力の形までです ——「そのまま貼れる」は事実で、その先に何が起きるかは、そのサイトと組織の事情によります。
   • 測る内容は変わりません。
5. 2026.08 第220版2026-08-21定期改訂表現結果に影響なし

   画面に記法がそのまま出ていたのを直しました

   7

   • ★★★ 「私たちの考え方」のページに、強調の記号がアスタリスクのまま出ていました。 「これは現在の診断項目ではありません。」という一文が、囲みの記号ごと表示されていました。2026.08.76 と同じ型です（あのときは評価基準ページで 568 箇所）。
   • ★★ 検査も素通ししていました。 記法が解かれているかを見る検査は欄の名前で判定しており、今回漏れていた 2 つの欄（lead / body）がその一覧に入っていませんでした。 一覧に無い名前は、最初から見ていません。 欄を足し、素のまま出してよい欄は理由つきで除外に書き、使われなくなった除外は検査の失敗として出すようにしました。
   • ★★ 2026.08.218 で畳んだ言い方が、届いていない画面がありました。 診断ページの「無料で分かること」と、トップの料金の面に、古い呼び名（「直し方」「欠けると届かない ○ 項目」）と、箇条書きの中の中黒が残っていました。同じ項目を 2 つの名前で呼ばないという規律に戻しました。
   • ★★ 「使い切ると 1 回あたり 約 50 円」を書き直しました。 使い切った先に 1 回 50 円かかる、と読めます。 同じ面の 3 行下に「追加料金はありません」と書いてあるので、読み手はどちらが本当か決められません。 これは月額を回数で割った単価なので、「100 回すべて使った場合、1 回あたり 約 50 円」にしました。
   • ★ 英語が主表記になっていた 2 箇所を日本語にしました（Readiness / Visibility → 準備状態 / 可視性）。同じ画面の図はもともと日本語で書いています。
   • ★★ 「Readiness 90 点」という例を書き直しました。 v21 で総合点を廃止したので、SILVE はもう点を出しません。 自社が出さない単位を自社の例に使うと、「準備状態は点で出る」と読めます —— 同じ画面に「総合点は出しません」と書いてあります。 合成できないという主張は、単位が違うことだけで成り立ちます。
   • 測る内容は変わりません。
6. 2026.08 第219版2026-08-21定期改訂表現結果に影響なし

   別のものを指す「4」が隣り合っていたのを直しました

   5

   • ★★ 利用者の指摘 ——「直前の『欠けると何が伝わらなくなるか』で 4 項目について話しており、これとは全く異なるものだ」。そのとおりです。 すぐ上の段落が「最初の 4 項目は、クロール・インデックス・AI への直接入力に関わる条件です」と書き、その直後の見出しが「測っているのは、4 つのうち 1 つだけです」でした。前者は診断項目の数、後者は測定レイヤーの数で、まったく別のものです。
   • 見出しを「測っているのは、AI がこのサイトを使える状態かまでです」に変えました。 数は図が持ちます（図の中に 4 つのレイヤーが並び、1 層目だけに「SILVE が測る範囲」が付いています）。見出しでは範囲そのものを言います。
   • ★ 図の 1 層目の問い（「AI システムがこのサイトを使える状態か」）を、そのまま見出しに上げました。 図と見出しで別の言い方をしないためです。
   • ★ 「〜まで」で上限を示すので、否定語を使わずに範囲が閉じます ——条件は肯定形で述べ、結果は述べないという書き方の規律に沿います。測れていないもの（実際に使われたか・エージェントが実行できたか・事業に何が起きたか）は、図と、その下の注記が引き続き述べます。
   • 測る内容は変わりません。
7. 2026.08 第218版2026-08-21定期改訂表現結果に影響なし

   同じものを 3 通りの名前で売っていたのをやめました

   6

   • ★★★ 利用者の指摘 ——「有料で増えるものの書き方だが、・の中に・が入っており、読みにくい」。入れ子をほどいたら、読みにくさは記号の話ではありませんでした —— 「全項目の改善手順」「項目ごとの直し方」「どう直すか」が、3 つの名前で 3 行に分かれていました。 売っているものは 1 つです。1 行にまとめ、区切りは読点にしました。
   • ★★★ もう 1 つの指摘 ——「社内共有用の書き出しとあり、その下に報告書の印刷、CSV / JSON の書き出しとある。これらはほぼ同じじゃないのか」。同じでした。 上の行の説明が「CSV / JSON と、印刷用の体裁が出ます」で、下の 2 行がそれを 1 つずつ書いていました。 料金表の 3 行を 1 行にしました。
   • 料金表の「なぜそうなったか…」と「項目ごとの直し方」も 1 行に畳みました。 無料側の呼び名（到達・利用の条件 / 欠けると届かない）が違うだけで、同じ項目の同じ中身を指しており、有料側はどちらも「全 10 項目」でした。
   • ★ 申し込みページの一覧にだけ「社内共有用の要約」がありませんでした。 料金表と結果画面には載っていたので、申し込みページだけが少なく見えていました。 足しました。
   • ★★ 同じものを別の名前で 3 回並べると、表は長くなるのに中身は増えません。 見せているものが多いか少ないかではなく、数え方が一貫しているかの問題です —— これは「単位の違うものを 1 つの数にしない」と同じ話で、売り文句の側でも同じ規律を守ります。
   • 画面の中身は変わりません。 出るもの・出ないものは 2026.08.217 と同じです。
8. 2026.08 第217版2026-08-21定期改訂表現結果に影響なし

   無料でも値は全部出し、理由と直し方に鍵をかけました

   7

   • ★★★ 線を引く場所を変えました。 直前の版（2026.08.216）では判定しない区分の値そのものを伏せていましたが、利用者の判断 ——「値だけは全て出す。それ以下の内容に鍵をかけて有料プランへのリンクを置いてくれ。なぜこの結果になったのか、どうやったら直せるのかに価値がある」。そのとおりです。
   • 無料でも、10 項目すべての割合を出します。 鍵をかけるのは「なぜその結果になったのか（提供元の資料が何と書いているか）」「どのページ・どの画像が該当するのか」「どう直すか」です。そこに有料プランへの入口を置きました。
   • ★ 到達・利用の条件は、無料でも理由と直し方まで出します。 欠けるとその範囲で取得・掲載・利用が制限されるので、そこはお金を払わなくても直せるようにするという方針が既にあります（2026.08.185）。
   • ★★ 伏せたものは、画面のデータに入れていません。 ぼかしや非表示はソースを見れば読めます ——「ボタンだけ非表示は不可」と同じ規律です。
   • ★★ 結果より先に出ていた注釈を、ページ下部にまとめました。 利用者の指摘 ——「結果よりも先にこの文章が出るのは違和感がある。ページ下部に注釈があるのだからそこにまとめてくれ」。「測れた範囲が狭くなっています」の帯と、無料診断の範囲についての説明を、「この結果について」へ移しました。 ★ 「無料診断・入力した 1 ページ」というラベルだけは、題のすぐ下に残しています —— 範囲は、数字より先に見えていなければ意味がないためです。
   • ★ 2026.08.192 に「測れた範囲を結論より先に置く」と決めたのは、総評が「条件はすべて満たしていました」で終わると、観測できなかったものが「欠けていない」に化けるからでした。その心配は残っていますが、いまそれを止めているのは帯ではなく、一覧の行に出る「判定していません」のほうです（2026.08.213）。
   • 画面を変えたので、無料の範囲を説明している場所もすべて合わせ直しました。
9. 2026.08 第216版2026-08-21定期改訂表現結果に影響なし

   無料の結果を、到達・利用の条件だけに絞りました

   7

   • ★★★ 利用者の指摘 ——「有料にした時とあまり視覚的な文量が変わっていないのは違和感がある」。そのとおりでした。 それまで無料でも 10 項目すべての観測値が出ており、伏せていたのは「提供元の推奨」と「エージェント対応」の直し方だけでした。画面の量がほとんど変わらないので、何を買うのかが伝わりません。
   • 無料では、判定する区分（到達・利用の条件）だけを出します。 残りの項目は項目名だけを鍵つきで並べ、値・改善候補・詳細は出しません。 ★ 「測っていない」のではありません。測ったうえで、値を出していないだけであることを、その場に書いています。
   • ★★ 値を出してから、ぼかしや非表示で隠すことはしていません。 ぼかしはソースを見れば読めます —— 「ボタンだけ非表示は不可」（有料の認可を直したときと同じ規律）。観測値は画面のデータに入れていません。 ★ 項目名は隠しません —— 診断基準のページに全項目を公開しており、何を測っているかは秘密ではありません。秘密なのはそのサイトの値です。
   • ★★★ 画面を絞ったので、売り文句も同時に絞りました。 無料で見られる範囲の説明（トップの FAQ・診断ページ・料金表・結果画面）を、すべて到達・利用の条件だけに書き換えています。 画面だけ、あるいは説明だけを動かすと、「画面の主張と実装がずれる」という以前の問題を作り直すことになります。
   • ★ 料金表に「見られる項目」の行を戻しました。 2026.08.208 にこの位置の行を外したのは、当時「全件 vs 例」に差が無かったからです。いまは見られる項目そのものに差があります。
   • ★★ 診断中の画面が、無料とアカウントで違っていました。 利用者の指摘 ——「診断中の UI が無料と有料で微妙に違うのだが、想定内か」。想定内ではありませんでした。 枠の形・点の色・見出し・待ち行列の区別が、別々に書いたことでずれていました。 違ってよいのは取るページ数（1 ページ / 最大 30 ページ）だけで、それは実装から導いています。1 つの部品にまとめました。 ★ あわせて、アカウント側の診断中・失敗の画面が本文の枠に入っておらず、全幅で左に寄っていたのも直しました。
   • ★ 数を手書きしていて、検査に 2 回止められました。「4 項目」「6 項目」と書いたところ、画面の文言に項目数を手書きしていないかを見る検査が落ちました。公開中の版から導く形に直しました —— 区分が動いた日に、ここだけ古くなるのを防ぐためです。
10. 2026.08 第215版2026-08-21定期改訂表現結果に影響なし

    無料の測定範囲を前に出し、トップの概念を減らしました

    10

    • ★★★ 無料診断は「入力した 1 ページだけ」です。それが押す前に見えていませんでした。 外部レビューでのご指摘 ——「『あなたのサイトは』＋『無料で診断』の組み合わせは、サイト全体を診断してくれると期待させやすい。これは単なる注意書きではなく、測定結果を正しく読ませるための Methodology の一部」。そのとおりです。
    • 押す直前に、範囲と回数を出すようにしました ——「入力した 1 ページだけを取得します（サイト全体ではありません）。アカウント不要・このブラウザーから累積 3 回まで」。★ 回数の上限も、料金表まで読まないと分からない状態でした。 2 回使ったあとで突然「上限です」と出るより、最初から分かるほうが誠実です。
    • ★★ 無料の結果画面にも、数字より先に範囲を出します ——「無料診断・入力した 1 ページの観測です。サイト全体の状態を表すものではありません」。分母の説明は折り込みの中にもありましたが、そこは数字を読み終えたあとにしか目に入りません。範囲は、数字より先に見えていなければ意味がありません。
    • ★★★ トップに概念モデルが 5 つ出ていました（診断の 10 項目・測定の 4 レイヤー・3 つの最適化・7 段階・記事の体系）。ご指摘 ——「どれも単体ではよくできているが、LP としては『全部説明したくなる研究者側の論理』が勝っている。削ることで品質が下がる段階ではなく、削ることで品質が上がる段階」。「3 つの最適化」と「7 段階の図」を、考え方のページへ移しました。消してはいません。トップには入口だけを残します。
    • ★★ 「PerplexityBot を拒否 → Perplexity には読まれません」は強すぎました。 PerplexityBot は検索・リンク掲載用ですが、利用者が URL を指定して読ませる Perplexity-User は別の仕様で、robots.txt を一般に無視すると明言されています。 ★ クローラーの一覧では「拒否したときに何が起きるかは提供元の資料に書かれていない。こちらが埋めない」と決めていたのに、その規律がトップの表示例まで流れていませんでした。
    • ★★ AI 検索クローラーの割合について、注釈を強めました。「83%」が「AI 検索市場の 83% をカバー」と読まれ得る、というご指摘に対し、表示の形式は変えません —— 全項目が「100% ＝ 観測した対象すべてで条件を確認できた」で統一されているほうが読みやすく、ここだけ実数にすると「なぜここだけ形式が違うのか」を考えさせるためです。 ★ 代わりに線を 1 本引きました ——「6 つを等しく 1 と数えているので、各サービスの利用者数・検索量・市場シェアを表すものではありません」。実数（5 / 6 件）は各項目の詳細に出ています。
    • ★ 記事一覧の左に出ている数字にラベルがありませんでした。 「各行の左の数字は、判断基準を読む順番です」と 1 行添えました。こちらが付けた番号なのに、何の数かを書いていませんでした。
    • ★★ 「毎月 15 日に更新します」を「見直します」に改めました。 ご指摘 ——「新しい一次資料が何もなければ、変えないことも正しい Methodology。毎月必ず更新すると約束すると、変更すること自体が目的化する」。そのとおりです。 約束するのは見直す日のほうにしました。
    • ★ 「海外一次情報の取り込み」の書き方を精密にしました。 実際には記事・論文・実践者の議論も探索しています。探索には二次情報も使い、診断基準へ採用する根拠は提供元の公式資料と一次研究を優先する —— この区別を 1 文で書きました。「一次情報しか読まない」と誤読されるより正確です。
    • ★ ナビゲーションの「評価基準」を「診断基準」に統一しました。 ページ自身が「診断基準 v26」と名乗っているのに、入口の名前だけ違っていました。
11. 2026.08 第214版2026-08-21臨時改訂表現結果に影響なし

    「同じ日に測れば同じ結果」という言い方を訂正しました

    6

    • ★★★ 外部レビューでのご指摘 ——「『同じサイトを同じ日に測れば、v25 と同じ結果が出ます』は、厳密には『同一の取得内容を v25 と v26 で評価すれば同じ結果になります』のほうが正確。同日でも HTTP 応答や robots.txt は変化し得るため」。そのとおりです。
    • ★★ これは、こちらが直したばかりの誤りと同じ形でした。 2026.08.212 で「同じ HTML なら同じ結果」を「同一の取得内容を同一の版の評価基準で評価すれば、結果は同一」へそろえたのですが、その修正を説明する文の中で、同じ種類の言い方をしていました。
    • 決定論的なのは測り方であって、取得できる内容ではありません。 同じ日でも、HTTP の応答・robots.txt・HTML・取得の成否は変わり得ます。
    • ★ 訂正して読み替えてください —— v25 と v26 は、同一の取得内容を評価すれば同じ結果になります（判定・項目・区分・数え方・測る範囲のいずれも変えていないため）。
    • ★ 前の版の文は書き換えていません。 公開した版は書き換えず、訂正は新しい版として残す、という原則のとおりです。「スコアへの影響」欄の定義（これから従う規則のほう）は、正しい言い方に直しました。
    • ★★ 同じ言い方が二度と入らないよう、機械で見張るようにしました。 画面のコピーに「同じ HTML」「同じ日に測れば」と書けなくなります（変更履歴と過去の版は対象外です —— 当時の記録なので）。
12. 2026.08 第213版2026-08-21定期改訂表現結果に影響なし

    診断結果を持ち主だけに見せ、対象が 0 件の項目も出すようにしました

    7

    • ★★★ 診断結果のページと書き出しに、認証の確認が 1 つもありませんでした。 URL を知っていれば誰でも開けます。 無料のあいだは実害がありませんでした（有料で実行された診断が存在しないため）が、有料を開始すると、URL 1 本で有料の中身（全項目の直し方・伝わっていない実体の一覧・書き出し）が誰にでも渡ります。 料金表は CSV / JSON を有料の欄に置いているのに、実装では誰でも取れていました。
    • 持ち主か運営者だけが開けるようにしました。共有は、すでにご提供している 3 つが担います ——印刷（PDF 保存）・CSV / JSON の書き出し・社内共有用の要約。 どれも「持ち主が出力してお渡しする」形なので、URL が独り歩きしません。 ★ 署名つきの共有 URL は作りませんでした —— 期限と失効の仕組みが要るうえ、「URL が漏れたら中身も漏れる」という性質は変わらないためです。要るとわかってから作ります。
    • ★ アカウントを使わない簡易診断は、これまでどおりです。持ち主がおらず、中身も無料の範囲しかありません。
    • ★★★ 対象が 0 件の項目を、一覧に出すようにしました。 ご指摘 ——「区分の見出しが「4 項目」と言っているのに 3 行しか出ない」。「代表 URL の指定」（重複候補 0 組）と「ラベルのある入力欄」（入力欄 0 個）は、多くのサイトで同時に消えていました。
    • ★ 0 / 0 は出しません。「満点にも 0 点にも読めてしまう」というそれまでの理由は正しいので、割合は出さず「—」と「対象なし」を出します。「判定していません」（測ろうとして観測できなかった）と「対象なし」（測った結果 0 個だった）は、必ず書き分けます。
    • ★★ 書き出しが内部の項目 ID をそのまま出していました。 「内部リンク」の ID が agent.… なのに、区分は「提供元の推奨」——agent. は加重和の版のカテゴリで、v22 でこの項目は区分ごと移っています。ID だけが当時の分類を持ち続けていました。
    • 外へ出す名前を、観測の定義そのものに持たせました（対象＋観測属性。区分も評価語も入れません）。★ 写像表は作りません —— 正本が 2 つになると、必ずずれます。 ★ 機械で見張ります ——「すべての観測が名前を持つ」「同じ名前が違う単位に付いていない」「評価語が入っていない」「区分の名前が入っていない」「書き出しが内部 ID を出していない」。実際にこの検査が、内部リンクの名前の取り違えを 1 件捕まえました（v21 はリンクを数え、v22 はページを数えるので、別の名前にすべきでした）。
13. 2026.08 第212版2026-08-21臨時改訂表現結果に影響なし

    周辺のコピーを、現在の測り方に合わせ直しました

    11

    • ★★★ 2026.08.180 で撤回した断定が、2 か所に残っていました。 トップと料金表に「欠けていると、残りをいくら整えても届きません」。robots.txt・noindex・nosnippet では制限されるものが違い、nosnippet は掲載自体は残ります。区分の説明と同じ言い方（「該当する制御があると、その範囲で取得・掲載・利用が制限されます」）にそろえました。
    • ★★ 「同じ HTML なら同じ結果」は狭すぎました。 判定は HTML だけでなく robots.txt・HTTP のステータス・取得の成否も使います。利用規約の言い方が正確だったので、トップ・診断ページ・私たちの考え方の 3 か所をそちらへそろえました ——「同一の取得内容を同一の版の評価基準で評価すれば、結果は同一になります」。
    • ★★ 「AI は一切関与しません」は広すぎました。 記事の下書きに生成 AI を使うことがあると運営者情報に明記しているので、「診断の判定と、結果の説明文の生成に、生成 AI は使っていません」（規約・プライバシーと同じ範囲）に直しました。
    • ★★ 旧い診断機能の説明が残っていました。 「組織名・サービス名の表記揺れ」は v22 で診断項目から外れ、その入力欄も 2026.08.186 に消しています。現在の診断機能に見えていたので、「これは現在の診断項目ではありません」を先に置き、記事と改善設計の話であることを明示しました。
    • ★ 診断の流れ（STEP 02）のカテゴリ名が加重和の版のままでした（「クローラー対応・エージェント対応・コンテンツ構造」）。区分の正本から並べるようにしたので、区分が変われば一緒に変わります。
    • ★★ 評価基準のページで、2 つの版番号が並んで見えていました。 上部に出ていたのは「この診断基準を公開した時点の Methodology 版」で、判断基準の順路のページに出る「現在の Methodology 版」とは別の数です。並ぶと 13 版ずれて見え、どちらかが古いように読めました。 「診断基準 v◯◯」を見出しにし、公開時と現在の Methodology 版を併記しました。あわせて「無料は 1 ページ」も添えました。
    • ★★ AI クローラーの一覧で、総論が提供元の差を潰していました。 「塞ぐと、そこには出なくなります」と一括りにしていましたが、同じページの各行はもっと慎重に書いてあります —— Anthropic は「可視性が下がり得る」、OpenAI は「ナビゲーショナルリンクとしては残り得る」、Perplexity は結果を書いていません。 「拒否したときに何が起きるかは提供元ごとに違います」に改めました。
    • ★ OAI-AdsBot を「ユーザー操作による取得」に入れていました。 これは出稿側が提出したランディングページを提供元が確かめるもので、利用者の操作が起点ではありません。 「広告として出したページの検証」として分けました。
    • ★ 測定モデルの記事が、旧い言い方のままでした（「決定論的なのは採点」「診断で満点なのに出ない」「接続しない限り採点しません」）。記事は 4 層（準備状態 / 可視性 / 実行 / 成果）なのに、まとめと一覧の説明文だけが 3 層で、「実行」が抜けていました。
    • ★ 利用規約 第 6 条の「配点」 を「観測・判定の方法」へ、更新のお知らせの「サイトの点」 を「サイトの結果」へ、有料プランの「効いたかどうか」 を「基準上の変化」へ直しました。
    • いずれも書き方の話で、測り方は変えていません。
14. 2026.08 第211版2026-08-21定期改訂表現結果に影響なし

    項目の説明から、廃止した語彙と事実誤りを外しました（v26）

    7

    • ★★★ 外部レビューでのご指摘 ——「現行 v25 項目の説明にも、旧いスコアリングの語が残っている」。本番の評価基準ページを取って数えたところ、変更履歴より前（＝現行項目の説明）に 11 箇所ありました。
    • ★★★ 語彙だけの問題ではありませんでした。 代替テキストの説明に「100% を求める判定にしていない（8 割で満点）」と書いていましたが、v22 以降の観測に段階も閾値もありません。実測の割合をそのまま出しています。項目の動きについて、事実と違うことを書いていました。 同じ形が 2 つあり、「重複は減点する」（いまは「固有の title があるページ」に数えないだけ）と「入力欄が無いサイトは減点しない」（いまは行そのものを出しません）も直しました。
    • ★★ なぜ版を切ったのか —— 項目の説明のうち「この判断の理由」は、版を公開したときに保存されます。公開済みの版は編集しないので、新しい版として出す以外に、この文が入れ替わる経路がありません。 v26 は文言だけの版で、項目・区分・数え方・測る範囲・判定は 1 つも変えていません。同じサイトを同じ日に測れば、v25 と同じ結果が出ます。
    • ★ 資料は読み直していません。 こちらの書き方を直しただけなので、最終確認日は動かしていません。読み直していないものを、読み直したとは書きません。
    • ★ v25 の表示は動かしていません。 当時そう書いてあったことは事実なので、v25 を開けば当時の注記が出ます。
    • ★★ 「代表 URL の指定」の名前と説明が、検出しているものと違っていました。 ご指摘 ——「重複 URL の canonical は代表 URL へ向けるので、各重複ページの自己参照 canonical を見る項目ではない」。そのとおりでした。 v22 で観測を「重複候補の組」へ変えたときに、項目名と説明だけが加重和の版の検出器（各ページの自己参照）のまま残っていました。 画面に出る短い名前は既に「代表 URL の指定」だったので、同じ項目に 2 つの説明が並んでいました。 直し方の文も、自己参照から重複の組の話へ改めました。
    • ★ 検査を 1 つ足しました。 版の要約が「外した語そのもの」を引用することがあります（この版がまさにそれです）。引用している部分だけを、版と理由を書いて外します。文言が変われば一致しなくなり、検査が落ちて理由を書き直すことになります。
15. 2026.08 第210版2026-08-21臨時改訂表現結果に影響なし

    トップページのサンプルが、切り替わっても動いていませんでした

    6

    • ★★ 利用者の指摘 ——「別のサンプルに切り替わっても、100% の部分は変わらず動いていない。別のサイトを測定しているという設定なので、同じ 100% であってもまた 0 からカウントアップしてほしい」。
    • 数え上げの引き金が「値の変化」だけでした。 値が同じ行では処理が再実行されず、止まったままでした。★ 100% は 3 例のうち 2 例以上で同じなので、8 行のうちほとんどが動いていませんでした。
    • 引き金を「どのサンプルか」に変えました。 切り替わったら、値が同じでも 0 から引き直します —— 別のサイトを測った結果だからです。
    • ★ あわせて 2 つ直しました。 (1) 「描画から時間が経っていたら動かさない」という安全弁が切り替えにも効いていて、放っておくと 2 例目以降が永久に動かない状態でした（切り替えでは効かせません）。(2) 動きを抑制する設定のときに切り替えると、前のサンプルの数字が残る可能性がありました（その場で実値に合わせます）。
    • ★ JavaScript を実行しない読み手に 0% を見せないという規則は、そのままです。サーバーが返す HTML には実値が入っています。
    • 結果画面は変えていません。 あちらは値が入れ替わることがなく、引き直す理由もありません。
16. 2026.08 第209版2026-08-21臨時改訂表現結果に影響なし

    文字しかないサイトなので、活字の設計を組み直しました

    10

    • ★★★ 本文の 1 行が長すぎました。 記事は 768px の幅に 16px で、和文 1 行 48 文字でした。長い日本語で読みやすいのは 35〜45 字で、48 字は行を見失う長さです。記事は 1 本 1 万〜2.6 万字あるので、ここが紙面でいちばん効きます。672px / 17px（約 40 字）にしました。
    • ★★★ 書体が 1 種類しかありませんでした。 図版がほとんど無いサイトで、紙面の性格を決めるのは書体です。読み物の見出しと引用だけを明朝にしました —— ページの題、記事の見出し、引用。UI・数字・結果画面はゴシックのままです。「読むもの」と「操作するもの」で分けます。
    • ★★ 一次資料の引用を、紙面の中心に置きました。 英文の引用が 129 箇所あり、そこがこの製品の差そのものなのに、薄い灰色の小さな箱に収まっていて本文より弱く見えていました。地を敷くのをやめ、太い罫と字の大きさで引きます。 あわせて、引用の最後に — 提供元（確認日） と書くと出典が引用の外に出るようにしました。出典は引用された文の一部ではありません。
    • ★★ 測った数字を、本文から引き抜けるようにしました。 記事には「10 項目のうち 8 項目が段階 1〜2」のような数が散文に埋もれています。図版を持たないサイトで、紙面のリズムを作れるのは数字です。★ 新しい主張を作る場所ではありません —— 本文に既に書いてある数だけを引きます。
    • ★ 節に通し番号を打ちました。 節が 14〜20 ある記事で、いま何節目かが本文から分かりませんでした。 右の目次と同じ番号にそろえます（巻末の記録は数に入れません）。CSS だけなので、JavaScript が無くても出ますし、印刷にも出ます。
    • ★ 地の色を、青みの灰から紙の色へ（#f8fafc → #faf9f7）。文字しかないサイトで、地の色は面積がいちばん大きいためです。明度はほぼ据え置きで、本文とのコントラストは動かしていません。
    • ★ 下層ページに、題の面を作りました。 トップは白と薄灰を交互に切り替えて読む速度を作っているのに、その規則が下層に通っておらず、端から端まで白いまま長く続いていました。
    • ★ 記事一覧に、読む順路の番号を左に置きました。 写真も図も無い一覧に、新しい主張を足さずに構造を出せます（順番は「判断基準を読む順番」が既に持っているものです）。
    • ★★ 検査を 1 つ直しました。 出典の行を引用の中に置けるようにしたところ、その行が日本語なので「英文のみの引用」ではなくなり、その引用が検査から静かに外れていました（129 → 128）。出典は引用の中身ではないので、判定の前に落とします。129 に戻しました。
    • 測り方は何も変えていません。
17. 2026.08 第208版2026-08-21臨時改訂表現結果に影響なし

    売り文句と画面の言葉を、実装に合わせ直しました

    13

    • ★★★ 無い機能を 2 つ売っていました。 1 つは「伝わっていない実体の全件」——料金表・/signup・トップページの 5 か所で「無料は例、有料は全件」と書いていましたが、実装は無料も有料もまったく同じ一覧を出していました。 検出の時点で 12 行に打ち切って保存しており、打ち切った側はどこにも残っていません。 さらに 2 項目（操作要素・入力欄）は、1 ページあたり 5 例しか集めていません（変数名も Samples です）。差が無いものを差分表から外しました。
    • ★★★ もう 1 つは「robots.txt・構造化データの記述例」です。組み立てる関数を、どこからも呼んでいませんでした。 5 例のうち 4 例は現在の評価基準に対応する項目が無く、3 例は 2026.08.186 に「記述例がもう出ないから」という理由で消した入力欄（会社名）を穴埋めに使うものでした。消した理由が分かっていたのに、売り文句だけ残っていました。 仕組みごと削除しました。 できてから載せます。
    • ★★★ 評価基準のページが、v25 を「配点」で説明していました。 全 10 項目に「配点対象」の札が付き、各項目に「配点の理由」が出ていました。中身は「単一項目としての影響が最も大きいため最重量」「配点は控えめ」——重みが全部 0 の版で、重みを決めた理由を出していました。 札を出すのをやめ、代わりに「提供元の記述」（一次資料が何と書いているか）を出します。これまで「提供元の推奨」と「エージェント対応」の項目には、なぜ見ているかが 1 行も出ていませんでした。
    • ★★ 変更履歴の札も直しました。 v21 以降の 33 版すべてに「スコアに影響なし」「スコアが変わります」が付いていました。総合スコアを廃止した版（2026.08.159）にも「スコアが変わります」が付いていました。 「結果に影響なし」「結果が変わります」に改めます。
    • ★★ 「スコア」という語が、画面と記事に 60 箇所以上残っていました。 /about の見出し「スコアも説明も、コードで決めます」（3 行後に「総合点は出しません」と書いてあります）、/legal の「算出したスコアを保存します」（実装は保存していません）、/signup の「スコアの推移」、記事の「SILVE が減点するのは」「満点でも」。すべて、いま実際にやっていること（数える・判定する・診断項目にする）の言い方に直しました。
    • ★★★ 検査が見ていない場所に残っていました。 画面の主張を実装と突き合わせる検査（2026.08.187）は、src/app と src/components しか見ておらず、売り文句を持つ src/lib の定数を 1 つも見ていませんでした。そして評価基準のページと札の部品を、「旧い版を描くから」という理由でファイルごと除外していました。どちらも現在の版も描いています。 走査範囲を広げ、除外は行ごとに理由付きで持つ形に変えました。
    • ★ 見る語も増やしました（スコア・点数・満点・採点・減点・加点・重み・失点）。あわせて画面側にも否定形の免除を入れました ——「1 つのスコアに合成しません」は、消えた概念を正しく説明している文だからです。記事にだけ入れていた規則を、画面にも当てます。
    • ★★ 社内共有用の要約に、撤回した文が残っていました。 「その範囲は存在しないものとして扱われます」は、2026.08.180 に「一括りが強すぎる」として画面から消した文です（nosnippet は掲載自体は残ります）。貼られて社外へ出ていくテキストに、2 回残っていました。
    • ★ 同じ操作に、2 つの所要時間を約束していました。 /diagnose のボタンは未ログインでも「診断中…（30 秒〜1 分）」と出し、同じフォームの下は「1 ページのみ取得します」、トップページの同じ操作は「5〜15 秒」でした。数字を 1 か所に集めても、どちらを出すかは人が選んでいました。取得するページ数から導く形にしました。
    • ★ 押しても着かないリンクが 2 つありました。 /methodology の「変更履歴」（/about#changelog —— そのアンカーは存在せず、履歴は評価基準のページにあります）と、ログイン画面の「取得する情報の扱い」（/legal#data —— 正しくは #privacy-data）。飛び先が実在するかを機械で検査するようにしました。
    • ★ 同じ 4 項目が、2 つの画面で違う順に並んでいました。 評価基準のページは metricId のアルファベット順（重みが全部 0 なので、重い順が効かなくなっていました）、結果画面とトップページのサンプルは正本の順でした。正本の順にそろえました。
    • ★★ Methodology の版番号が、2 つの画面で 13 版ずれていました。 判断基準の順路のページは「2026.08 第183版」、評価基準のページは「第196版」を最新として出していました。手書きの定数だったためです。履歴の先頭から導く形にしました —— この値は版を公開したときに記録もされるので、ずれたままだと「どの Methodology の版で公開したか」という過去の事実まで狂います。
    • 測り方は何も変えていません。 同じサイトを同じ日に測れば、同じ結果が出ます。
18. 2026.08 第196版2026-08-21定期改訂表現結果に影響なし

    結果の要約を、1 画面に収まる密度にしました

    4

    • ★★ 100% をグレーで出していたのをやめました。 空のバーの灰色と見分けがつきませんでした。 色は区分のもの（到達・利用は緑、提供元の推奨は琥珀、エージェント対応は青）で、割合の値では変えません。 到達・利用で欠けている項目だけ赤にします —— これは値の閾値ではなく、判定する区分の二値（欠けがあるか）です。
    • ★ 配置を変えました。 上半分に「到達・利用の条件」を 2 列で、下半分に「提供元の推奨」と「エージェント対応」を左右に置きます。余白を減らし、1 画面で全体が見える密度にしました。
    • 判定の文を短くしました。「4 項目とも、制限は見つかりませんでした」→「制限なし」。正確な言い回しは、区分の説明文が持ちます。
    • ★★ トップページのサンプルを、結果画面と同じ形にしました。 サンプルはそのまま診断結果として読まれます。 ここだけ別の見せ方をすると、実物との印象がずれます。
19. 2026.08 第195版2026-08-21定期改訂表現結果に影響なし

    結果画面の見た目を、測定ツールらしく整えました

    5

    • ★ カードを 3 枚並べるのをやめ、1 枚のパネルにしました。 枠を 3 つ並べると、区分が「別々の指標」に見えます。 同じ 1 回の観測を性質で分けているだけなので、外枠は 1 枚、中は罫線と余白で分けます。
    • ★★ 100% を全部緑にするのをやめました。 緑だらけになると成績表に見えます。 色は区分の帯にだけ使い、100% の数字はニュートラルにします。 欠けている項目だけ、その区分の色を数字に乗せます。
    • 数字を主役にしました。 割合を等幅数字で大きく置き、その横に極細のバーを添えます。大きなゲージや円グラフにはしません —— 円ゲージは「点数」の見え方が強く、SILVE が避けてきた表現に近づきます。
    • ★ 提供元の名前を、輪郭だけの小さなバッジにしました。 「Google AI Overviews / AI Mode」を項目の隣に文章として並べると、項目名より目立ってしまいます。 バッジには提供元の名前だけを出し、正式な名前はカーソルを乗せると出ます。情報は落としていません。
    • 「この結果について」と「クロールした範囲」を、同じ行の形にそろえました。 枠付きのカードを積むと、読み終わった方にも重い画面が残ります。 細い罫線と余白だけで区切り、開いたときに中身を出します。
20. 2026.08 第194版2026-08-21定期改訂表現結果に影響なし

    割合を最上部のカードへ、実数を詳細へ

    5

    • ★★ 利用者の指摘 ——「割合は最上部にのみ表示し、詳細では実数だけでいい。最初の 3 カードで、いかに直感的に伝えられるかがポイントだ」。そのとおりでした。 両方に出すと、同じことを 2 回言うことになります。
    • カード（最上部） —— 項目ごとの割合とバーを並べます。 「robots.txt 100% / 公開取得 100% / インデックス 100% / AI 直接入力 100%」「代替テキスト 26%」のように、短い名前で横に並べます。
    • 詳細 —— 実数と、欠けている数と、現物の一覧、直し方。割合は出しません。
    • ★★★ 区分をまとめた割合は、カードでも作りません。 「到達・利用の条件 96%」のような数字は出しません。その 4 項目は分母が 6 宛先 / 30 ページ / 30 ページ / 30 ページ でそろっておらず、1 つにするには重みが要るためです。 カードの中に、項目ごとの割合をそのまま並べます。
    • ★ バーの長さだけが割合を示します。 色は区分のもので、値では変えません。
21. 2026.08 第193版2026-08-21定期改訂表現結果に影響なし

    項目ごとに割合を出すようにしました（総合点は作りません）

    8

    • ★★★ 項目ごとの割合を、数字の主役にしました。 「97%（29 / 30 ページ）」のように、割合を大きく、実数を隣に置きます。細いバーも添えます。
    • きっかけは、5 段階（5 つ星）の検討でした。 星は却下しましたが、そこで桁で違う状態が同じに見えていたことが分かりました。代替テキストが 24 枚欠けているサイトと 1,207 枚欠けているサイトが、どちらも「改善候補」として同じ表示になっていました。
    • ★★ 1 項目の中の割合は、廃止した総合スコアとは別物です。 「29 / 30 ページ = 97%」は項目の中で完結しており、変換率が要りません。 禁じたのは「異なる単位を 1 つにすること」であって、1 項目の割合ではありませんでした。
    • ★★★ 区分をまとめた割合は作りません。 「到達・利用の条件 96%」のような数字は出しません。その 4 項目は分母が 6 宛先 / 30 ページ / 30 ページ / 30 ページ でそろっておらず、1 つの % にするには「4 項目を等価にするか、対象 96 個を全部足すか」を決める必要があり、それが重みだからです。 機械で検査します。
    • ★ 割合の値で色を変えません。 90% を黄色にした瞬間、こちらが閾値を作ることになります。色は区分にだけ使い（到達・利用は緑、推奨は琥珀、エージェント対応は青）、バーの長さだけが割合を示します。
    • ★★ 端点を丸めません。 4,976 / 4,995 は 99.6% ですが、四捨五入すると 100% になり「全部確認できた」と読めます。切り捨てて 99% と書きます。 「100%」は 1 件も欠けていない場合だけに使います。 同じ理由で、0 でないものを 0% とは書きません。
    • 見出しを「満たしている側」で統一しました。 「代替テキストがない画像」ではなく「代替テキストのある画像 26%」。欠けている側は、その下に 1 行で添えます。
    • ★ 以前「割合は出さない」と決めていたのを撤回しました。 理由は「並べると平均したくなるから」でしたが、実数からも割合は計算できるので、平均したい人を止められていませんでした。 止まっていたのは、桁で違う状態を一目で見分けることのほうでした。
22. 2026.08 第192版2026-08-20定期改訂表現結果に影響なし

    測れなかったものが、総評で「満たしている」に化けていました

    7

    • ★★★ 本文が 1 文字も取れていないサイトに、「条件はすべて満たしていました」と出していました。
    • 実測 —— ある企業サイトは、初期 HTML の可視テキストが 16 文字、内部リンクが 0 本でした。1 ページしか取得できません。 それでも総評は「測った範囲では、条件はすべて満たしていました」でした。
    • ★ 項目ごとには正しく書けていました。「画像の代替テキスト：判定していません（本文が静的 HTML から取れていないため）」「代表 URL の指定：判定していません」。総評だけが、それを「欠けていない」として扱っていました。
    • SILVE は 2026.08.47 から「観測できなかったものを満点に変換しない」と決めています。項目ごとには守れていて、総評だけ守れていませんでした。
    • ★★ 測れた範囲を、結論より先に出すようにしました。 「取得できたのは 1 ページです。起点ページに内部リンクが 1 本も見つからず、これ以上辿れませんでした。判定できなかった項目が 4 件あります。」閾値は要りません —— どれもそのまま数えられる事実です。
    • ★★★ 「直してください」とは書きません。 測れないのはこちらの限界であって、そのサイトの欠陥だと一次資料が言っているわけではありません。 Google は JavaScript を処理すると明記しており、他社のレンダリング能力を示す一次資料は確認できていません。 その 2 つを事実として添えるだけにします。
    • この枠に「してください」が入らないことを、機械で検査するようにしました。
23. 2026.08 第191版2026-08-20定期改訂表現結果に影響なし

    「判定はしません」が、実際とずれていました

    5

    • ★★★ 利用者の指摘 ——「必須条件ではないので判定はしません、とあるが、診断の基準として判定しているよな？」そのとおりでした。
    • 実際にやっているのは「数えて出す」です。 「代替テキストがない画像 379 枚」と出ている時点で、読む方には判定に見えます。
    • ★ 判定していないのは、正確には 3 つです。 合否の印（✓ / ✕）をつけない。総評（「4 項目中 1 項目で制限を確認」）に数えない。色で良し悪しを示さない。 一語に潰すと実態と食い違って見えます。 「合否はつけず、欠けている数をそのまま出します」に改めました。
    • ★★ もう 1 点 ——「推奨されている、または意味のないものではないのだから、わざわざ AI 検索に影響があるかどうかはここに書かなくていい」。これもそのとおりでした。 「この結果について」に「到達・利用条件を除いて、直すと『AI に選ばれやすくなる』とは書きません」が既にあります。同じことを 2 か所で言っていました。
    • エージェント対応の末尾も肯定形にしました。「ここが欠けても検索への到達には影響しません」ではなく、「AI 検索とは別の、もう一つの経路です」。検索に出なくても、利用者が Atlas などにサイトを操作させることはあります。
24. 2026.08 第190版2026-08-20定期改訂表現根拠結果に影響なし

    「効かないこと」しか書いていない区分がありました

    7

    • ★★★ 利用者の指摘 ——「この書き方だと、エージェント対応はなくても別に関係ないと読める。ならば、なぜ測る？」そのとおりでした。
    • 境界（AI 検索への到達には影響しない）しか書いておらず、何に効くのかを書いていませんでした。 効かないことしか書かない項目は、測る理由が読者に伝わりません。
    • ★★ エージェント対応は、SILVE の項目の中で最も根拠が強い部類です。 OpenAI は「ChatGPT Atlas のエージェントは ARIA のタグ・ラベル・ロールを使って、ページ構造と操作要素を理解する」と明記し、Google もアクセシビリティツリーをエージェントの主要な入力の一つとして挙げています。 別々の会社が、別々の資料で、同じことを書いています。
    • ★ 到達・利用の条件でさえ、nosnippet は Google 単独の記述です。 根拠の強さで言えば、エージェント対応のほうが上です。説明にそれを書きました。
    • エージェントは、AI 検索とは別の到達経路です。 検索に出なくても、利用者が Atlas などにサイトを操作させることはあります。そのとき効くのがここです。
    • ★ 「提供元の推奨」も同じでした。「必須条件ではありません」「届かなくなるわけではありません」と、否定しか書いていませんでした。 「直すと変わり得るのは、提供元が明示している範囲での情報の理解です」を足しました。それでも「AI 検索に選ばれやすくなる」とは書きません —— 各社は選び方を公開しておらず、外から確かめてもモデルが変われば結果は持たないためです。
    • 区分の説明が否定形だけで終わっていないことを、機械で検査するようにしました。
25. 2026.08 第189版2026-08-20定期改訂表現結果に影響なし

    区分の名前を短くし、「○○ではありません」で始めるのをやめました

    6

    • ★ 区分の名前を短くし、長さをそろえました。 3 枚のカードに横並びで出るので、長さが不揃いだと比べにくいためです。「AI 検索への到達・利用条件」→「到達・利用の条件」、「提供元が推奨する実装」→「提供元の推奨」、「ブラウザエージェント対応」→「エージェント対応」。
    • 「AI 検索への」を落としても意味は保てます。 すぐ下の説明文が「クロール・インデックス・AI への直接入力」と書いており、画面全体が AI 検索の診断結果だからです。
    • ★★ 利用者の指摘 ——「『AI 検索の話ではありません』という 1 文目に違和感がある」。そのとおりでした。
    • 狙いは誤読を止めることでした。 エージェント対応を同じ結果画面に並べると「これを直せば AI 検索に効く」と読まれます。Google 自身がエージェント対応を「関係があって、時間が余っていれば」と位置付けているので、そこを切りたかったのです。
    • ★ しかし、節の 1 文目を「これは○○ではありません」で始めるのは、入れていることへの言い訳に読めます。 同じ形が「提供元の推奨」にもありました（「必須条件ではありません」で始まっていました）。何であるかを先に言い、境界は結果として添えるように直しました。
    • 「ブラウザを操作する AI エージェントが、ページのボタンや入力欄を読み取れるかどうかです。上の 2 つとは別の話で、ここが欠けても AI 検索への到達には影響しません。」
26. 2026.08 第188版2026-08-20測り方の変更分類結果が変わります

    「まだ確定していないもの」を空にしました（v25・診断項目は 10 に）

    6

    • ★★★ 利用者の問い ——「まだ確定していないものとはなんだ？ なぜ根拠が足りないのに評価項目にしているんだ？」
    • 入っていたのは「初期 HTML に本文が見つからないページ」1 項目だけでした。構造としては評価項目ではありません —— 判定せず、直し方も出さず、「直すとしたら、ここ」にも入れていませんでした。しかし画面では、ほかの 3 区分と同じ大きさのカードで横に並んでいました。見た目が「4 つ目の評価区分」になっていました。
    • ★ 残していたのは、判定できるのが片側だけだったからです。 「初期 HTML に本文がある」は、どのクローラーに対しても確実に言えます（レンダリング能力に依存しません）。一方「無い」は結論になりません —— Google は JavaScript を処理すると明記しており、他社はレンダリングの有無を公表していません。
    • ★★ それでも落としました。 項目になる条件（欠けると機械に何が伝わらなくなるかを 1 文で言えること）を満たしていないもののために、区分を 1 つ用意していました。満たしていないものを、器を作ってまで残すのは筋が通りません。
    • 診断項目は 10 になります —— 到達・利用条件 4 / 提供元が推奨する実装 4 / ブラウザエージェント対応 2。 結果画面のカードも 3 枚になります。
    • ★ 検出そのものは残しています。 評価基準 v22〜v24 がこの項目を参照しているため、消すと過去の基準で測り直せなくなります。 落としたのは「この版の項目一覧から」であって、仕組みからではありません。
27. 2026.08 第186版2026-08-20定期改訂表現結果に影響なし

    所要時間・検出するもの・入力欄が、実際と違っていました

    5

    • ★★★ 所要時間の記述が、どれも実測と合っていませんでした。 画面には「約 10 秒」「最大 60 秒」「1 分ほど」が手書きされていましたが、測るページ数を 10 → 25 → 30 と変えたときに、時間の記述だけが取り残されていました。
    • ★ 実測しました（2026-08-20）。 無料（1 ページ）は 4.2〜14.0 秒、有料（最大 30 ページ）は 21.3〜41.7 秒です（silve.jp と smarthr.jp）。相手のサーバー次第で 3 倍以上ぶれるので、「5〜15 秒」「30 秒〜1 分」と幅でご案内します。 数は 1 か所に持ち、画面に手書きしていないことを機械で検査します。
    • ★★ 「構造化データなどをコードで検出します」と書いていましたが、構造化データは 1 項目も検出していません。 現在検出しているのはクローラー対応 5 項目・エージェント対応 4 項目・コンテンツ構造 2 項目です。そのとおりに書き直しました。
    • ★★★ 会社名・ブランド名の入力欄を消しました。 この欄の説明は「改善手順に出す構造化データの記述例に、この名称が入ります」でしたが、その記述例はもう出ません。 使っていたのは Organization と Article のコード例で、どちらも v22 で診断項目から外しています。
    • コード側に「説明できる用途が無くなったら、欄ごと畳む」と書いてありました。用途が無くなったので、そのとおりにしました。 入力を受け取る仕組みは残します —— 過去の診断が保持しているためです。
28. 2026.08 第185版2026-08-20定期改訂表現結果に影響なし

    無料でお約束していた直し方が、出ていませんでした

    5

    • ★★★ 無料の診断で「欠けると届かなくなる項目は、直し方まで読めます」とご案内しながら、実際には直し方が 1 つも出ていませんでした。 料金の比較表にも「無料：欠けると届かない項目の直し方」と書いていました。売っているものと、動いているものがずれていました。
    • 実装のほうを合わせました。 到達・利用条件が欠けていれば、ほかを直しても届きません。そこだけは、お金を払わなくても直せるようにするというのが、もともと決めてあった方針です。同じずれが起きないよう、機械で検査します。
    • ★★ 料金表に項目数を手書きしていました。「全 30 項目の結果と、直し方」と書いていましたが、項目は 30 → 15 → 11 と変わっています。「優先課題 3 件」に至っては、評価基準 v21 で概念ごと消えていました。存在しないものを「無料で読めます」とご案内していました。
    • ★ 同じファイルの 10 行下に「数を手書きしない」と自分で書いてありました。 原則を書いた場所と、原則が効くべき場所がずれる —— この製品が繰り返している型です。画面の文言に項目数を手書きしていないことを、機械で検査するようにしました。
    • 無料で読めるものの案内も直しました。「総合スコアと 5 つの観点別スコア、優先課題 3 件」と書いていましたが、3 つとも v21 で無くなっています。 現在は「項目ごとに何個中何個が機械に伝わっているか、伝わっていないものの例、そして到達・利用条件の直し方」です。
29. 2026.08 第183版2026-08-20定期改訂表現結果に影響なし

    結果のすぐ下の注記を、1 文に絞りました

    4

    • ★★ 利用者の指摘 ——「あの文章は注意事項の欄でよくないか。結果のすぐ近くに置いている理由は？」
    • 置いた理由は方針です ——条件は肯定形で述べ、結果は述べず、境界を 1 文で添える。 カードが「制限は見つかりませんでした」と言う以上、その主張の隣に境界が無いと「AI 検索に出ます」と読まれます。
    • ★ ただし、2 文と長い説明になっていました。境界ではなく、解説になっていました。 さらに「掲載・引用を保証しません」は「この結果について」にも出ており、同じことを 2 か所で言っていました。
    • 3 つに分けました。「4 項目が何なのか」（提供元の制御条件と、SILVE が外部から確認した取得状態）は区分の説明へ。「Google 自身が『技術要件を満たしたからといって索引されるとは限らない』と明記している」は「この結果について」へ。結果のすぐ下に残すのは、「ここに出しているのは条件です。実際に AI の回答へ出るかどうかは、これとは別です」の 1 文だけです。
30. 2026.08 第182版2026-08-20定期改訂表現結果に影響なし

    測り直しと書き出しを、結果の末尾へ移しました

    6

    • ★★★ 利用者の指摘 ——「再測定はすべての結果を読んでからな気もする。出力もそうかもしれない。今の UI になっている理由を教えてくれ」。理由がありませんでした。
    • 測り直しのボタンは、2026.08.98 に「約束したのに押せる場所が無かった」から足したもので、版番号が出ているヘッダーの中というだけの置き場所でした。印刷と書き出しも、別の日に同じ場所へ足されたものです。
    • ★★ 測り直しは診断回数を 1 回消費します。それを結果の一番上に置いていました ——読む前に押せる位置に、取り消せない消費がありました。
    • ★ 末尾の「この結果を使う」へまとめました。 理由は 2 つで、回数を使うので読み終わってからのほうがよいこと、そして測り直しは「直したあと」に押すものなので、直す場所を読んだ直後が一番近いことです。書き出しと測り直しは性質が違うので、線で分けています ——出力はいつ押しても構いませんが、測り直しは 1 回減ります。
    • ★ 測り直しの説明 4 行も、たたみました。 押す前に読むべきなのは「1 回使います」だけです。ヘッダーには事実だけを置きます。
    • ★ 売り文句と画面がずれていたので直しました。 有料プランの案内に「着手しやすさで分けた改善計画」と書いていましたが、その枠は前の版で外しています（同じ項目が画面に 4 回出ていたため）。着手コストは結果画面のカードにバッジとして載っています。
31. 2026.08 第181版2026-08-20定期改訂表現分類結果に影響なし

    「直す」の前に確かめることがある項目を、分けました

    7

    • ★★★ noindex に「今すぐできる」というバッジを出しながら、その下で「意図した指定ならそのままで問題ありません」と書いていました。 直す前に確かめることがある項目に、「直せる」と書いていました。
    • 「まず確認」と「改善候補」を分けました。 robots.txt の拒否・noindex・nosnippet は、会員限定ページや重複ページで意図的に付けていることが十分あり得ます。 これは重要度の順位ではなく、作業の性質の違いです。
    • ★★ 同じ検査で、robots.txt の改善手順が利用者の意図を決め打ちしていたことも見つかりました。 「許可してください」と書いていましたが、AI 検索クローラーの拒否は意図的であり得ます —— 37 サイトの実測で塞いでいた 3 件は、いずれもニュース・レシピ系のメディアでした。こちらが是非を決める立場にありません。 「まず意図を確かめてください」に改めました。
    • ★ 冒頭の言い方を変えました。「1 項目で満たしていません／4 項目すべて確認」は一瞬迷います。「4 項目中 1 項目で制限を確認」と、母数を先に言います。「問題」ではなく「制限」と書きます ——noindex は意図した設定であり得るので、品質評価の語を使いません。
    • ★★ 上部のカードを索引にしました。 問題が 5 件ある画面では、区分・項目名・件数・対応ラベル・直し方・長い説明が 5 回並び、前回削った密度が戻っていました。 上部は「何を確認・改善するか」だけにし、なぜ・どこ・どう直すかは下の詳細に置きます。同じ説明を 2 回出しません。
    • ★ 冒頭の注記を精密にしました。 「到達・利用条件は、提供元が公開している条件です」と書いていましたが、4 項目のうち「公開取得に成功したページ」は、提供元が公開している条件ではなく、SILVE が外から確認した取得状態です。両方あることを明記しました。
    • ★ 「変わるのは、引用されたときに機械が何を言えるかです」を一般化しすぎていました。 代替テキストは画像の理解、title はページの名前、操作要素と入力欄のラベルはブラウザエージェントの操作可能性であって、引用の話ではありません。「提供元が明示している範囲での情報の理解や、ブラウザエージェントによる操作可能性」に改めました。
32. 2026.08 第180版2026-08-20定期改訂表現分類結果に影響なし

    打ち切った件数の単位と、基準が変わった項目の見せ方を直しました

    7

    • ★★★ 代替テキストの件数が、まだ合っていませんでした。 「483 枚」の一覧で 12 行を表示し「ほか 471 枚」と出していました。471 = 483 − 12。しかし 12 は「ページ数」で、483 は「枚数」です。 前回この計算を直したつもりでしたが、直したのは新しく測る経路だけで、保存した結果を読み直す経路では同じ引き算が再計算されていました。
    • ★★ 原因は、一覧の単位を「実行結果」に持たせていたことです。 保存して読み直すと失われ、そこでまた引き算が走っていました。 一覧の単位は検出器の性質で、実行ごとに変わりません。静的な定義へ移しました。
    • ★ そして、打ち切りの行そのものを検出器が書くようにしました。 数を数えられるのは、その一覧を作った検出器だけです。 画面は引き算をしません。引き算が復活しないよう、機械で検査します。
    • 一覧の見出しも直しました。「該当箇所を見る（12 枚を表示）」は、実際にはページごとの集計を出しているので「該当ページを見る」が正しい表記でした。
    • ★★★ 前回の診断との比較で、基準が変わった項目を別枠にしました。 今回、内部リンクは判定から推奨へ、title は推奨へ、JavaScript は未確定へ移っています。それらを通常の比較表に並べると、「今もこの項目を同じように評価している」ように見えます。 数字は比べられますが、同じものを評価しているとは言えません。 基準の変化とサイトの変化を混ぜないという方針を、比較の画面にも通しました。
    • ★ 「到達・利用条件」の説明が、一括りに強すぎました。「欠けていると、その範囲は存在しないものとして扱われます」と書いていましたが、robots.txt・noindex・nosnippet では制限されるものが違います。 nosnippet は掲載自体は残り、AI の直接入力にならないだけです。「クロール・インデックス・AI への直接入力に関わる条件です。何が制限されるかは、指定の種類によって違います」に改めました。
    • ★ 「公開取得に成功したページ」が SILVE の観測であることを、文の中に入れました。 WAF は User-Agent や IP で挙動を変えられるため、各 AI 提供元のクローラーが同じ応答を受ける保証はありません。
33. 2026.08 第179版2026-08-20測り方の変更分類根拠表現結果が変わります

    内部リンクを推奨へ移し、測る範囲を 30 ページにしました（v24）

    8

    • ★★★ 判定していない項目に、改善を指示していました。 「まだ確定していないもの」の欄で「根拠がまだ足りないため、判定に使っていません」と説明しながら、同じ項目について「本文をサーバー側で HTML に含めてください」と指示し、さらに「この項目の点は、対応したページの割合で決まります」と書いていました。点という概念は廃止済みで、この項目は判定から外れています。旧い文言が 2 つ残っていました。 判定していない項目を、改善の一覧から外しました。
    • ★★★ 代替テキストの件数に、算術の誤りがありました。 「代替テキストがない画像 379 枚」の一覧で、12 行を表示して「ほか 367 枚」と出していました。367 = 379 − 12 です。しかし 12 は「ページ数」で、379 は「枚数」です。単位の違うものを引いていました。 「単位の違うものを 1 つの数にしない」と掲げている製品で、画面が引き算をしていました。一覧が何を数えているかを持たせ、同じ単位で数えるようにしました（12 ページを表示 ＋ ほか 11 ページ）。
    • ★★★ 内部リンクを「到達・利用条件」から「提供元が推奨する実装」へ移しました。 Google の資料は、技術要件（インデックス済みで、スニペット表示が可能であること）と、SEO のベストプラクティス（内部リンクで見つけやすくすること）を明確に分けています。内部リンクは後者です。 「内部リンクが無いと、そのページは存在しないものとして扱われる」は、一次資料から言えません。sitemap・外部リンク・既存の索引など、別の発見経路があり得ます。
    • ★ そもそも、この項目が数えているのは「そのページが見つかるか」ではありませんでした。「そのページに置かれたリンクが、辿れる書き方か」です。欠けたときに影響を受けるのは別のページで、しかも「見つからない」ではなく「この経路では見つからない」までしか言えません。判定する項目は 4 つになります。
    • ★★ 1 回の診断で見るページ数を 25 から 30 にしました。 利用者の指摘 ——「10 からなぜ 25 になった？ 20 や 30 のほうがキリが良い」。そのとおりで、25 に根拠はありませんでした。 実測では 1 ページあたり 1.09〜1.74 秒（itmedia / kintone / silve.jp / smarthr）で、時間から出る上限は 57 ページです。25 は上限ではありませんでした。
    • ★ 本当に効いている制約は、計算で決まらないほうです ——SILVE は、頼まれていない他社のサーバーを取得しにいきます。30 リクエストを無断で送ることの是非は、算術では出ません。判断です。 どうせ根拠が無いなら、説明しやすい数のほうがよいと考えました。 ★ 副作用として、許容できる Crawl-delay が 4.0 秒から 3.3 秒に下がります（国内企業サイト 11 件の実測では宣言 0 件）。
    • ★ 結果画面をさらに短くしました。 「着手しやすさで分けた改善計画」の枠を外し、着手コストは「直すとしたら、ここ」のカードにバッジとして載せました ——同じ項目が画面に 4 回出ていたためです。 「直し方」「該当箇所」「クロールした範囲」「この結果について」も、開くまで出さない形にしました。情報は 1 つも削っていません。
    • ★ 区分ごとに、件数の意味を書き分けました。「1 項目で確認できます」は曖昧でした。判定する区分は「N 項目で満たしていません」、推奨とエージェント対応は「改善候補 N 項目」、未確定は「参考観測 N 項目」です。
34. 2026.08 第178版2026-08-20定期改訂表現分類結果に影響なし

    同じ観測の数が、画面の 2 か所で食い違っていました

    10

    • ★★★ 結果画面の上部と改善計画で、同じ項目の数が食い違っていました。 上部は「代替テキストがない画像 112 枚（対象 168 枚）」、改善計画は「不足しています 56 / 168 枚」。168 − 112 = 56 で、同じ観測の裏表です。 操作要素でも同じことが起きていました（44 と 232）。
    • 原因は、同じ表示を 2 か所で別々に組み立てていたことです。 上部を「欠けている側」に直したとき、改善計画は「伝わっている側」のまま残りました。 見出しと数字の向きを揃える規則を作ったのに、その規則を当てる場所を 1 つ見落としていました。
    • ★ 組み立てを 1 か所に集めました。 そして 「数を自前で組み立てている箇所が無いこと」を機械で検査します。 2 か所に持たなければ、食い違いようがありません。
    • ★★★ 「最大 25 ページ」と書いてありながら 10 ページしか測っていなかった件、本当の原因はプラン側の上限でした。 実際に取得する数は min(プランの上限, 評価基準の上限, コードの安全弁) です。プラン側が 10 のままだったので、評価基準を 25 で公開しても 10 ページしか測りませんでした。
    • そのコードには「CRAWL_LIMITS.maxPages と揃える」と注記が書いてありました。書いてあって、揃っていませんでした。 揃っていることを機械で検査するようにしました。
    • ★ 測ったページ数の説明文が、実際の数と食い違っていました。 10 ページ測ったのに「この 25 ページという数と…」と出ていました。数を直書きしていたためです。実際に測った数から出すようにしました。
    • ★★ 結果画面を組み直しました。 区分ごとに 1 枚のカード（到達・利用条件 / 提供元が推奨する実装 / ブラウザエージェント対応 / まだ確定していないもの）を最上部に置き、その次に「直すとしたら、ここ」を置きます。方法論の説明より前に、直す場所を出します。
    • ★ 色は装飾ではなく、方法論を示すために使います。 緑と赤は到達・利用条件にしか使いません ——代替テキストが欠けていても赤にしません。「AI 検索に届かない」という意味ではないからです。 推奨は琥珀、エージェント対応は青、未確定は灰。色だけに意味を負わせず、区分の名前も必ず併記します。
    • ★ 各項目に、どの提供元に効く話かを併記しました。 「AI への直接入力を全面禁止していないページ」は実質 Google 固有の根拠ですが、初見の方には全 AI サービス共通の条件に見えます。
    • ★ 該当箇所の一覧・直し方・結果の読み方を、たたみました。 情報は 1 つも削っていません。開くまで出さないだけです。 結果と方法論を分けます。
35. 2026.08 第177版2026-08-20測り方の変更採点根拠結果が変わります

    版に固定していたはずのページ数が、固定されていませんでした（v23）

    9

    • ★★★ 公開済みの評価基準 19 版で、1 回の診断で見るページ数が、こちらの操作で動いていました。 利用者に「最大 25 ページと書いてあるのに 10 ページしか測定できていない」とご指摘いただき、追ったところ見つかりました。
    • v4（2026.08.30）は「1 回の診断で見るページ数を版に記録した版」でした。 その説明にはこう書いてあります ——「版を固定してもページ数はコード側の現在値が使われていた」。それを直すための版でした。
    • ★★ ところが、その版のコードは crawlMaxPages: CRAWL_LIMITS.maxPages と書いていました。 CRAWL_LIMITS.maxPages は、まさにその「コード側の現在値」です。 直すと宣言した問題を、同じ行で元に戻していました。
    • v5 以降は 1 つ前の版から引き継ぐ形で連鎖していたため、v4 から v22 までの 19 版が、この 1 行にぶら下がっていました。 コード側の上限を 10 から 25 に変えた瞬間、公開済み 19 版のページ数が全部 25 になりました。
    • ★ 保存済みの診断結果は影響を受けません（実行時の値が保存されています）。影響が出るのは、過去の基準で測り直したときです ——当時と違う分母で走ります。すべての版でページ数を数字で直接書くようにしました。
    • ★★ 既存の検査は、ここを見ていませんでした。 項目の根拠（standardAsOf）と、どのページを選ぶか（選定規則の指紋）は見張っていましたが、「何ページ見るか」はどちらも見ていませんでした。分母を決める値なのに、凍結の対象から漏れていました。
    • 公開時の範囲（ページ数・項目数）を記録し、最新版以外は一致することを検査するようにしました。 ★ 新しい版を足した瞬間に、1 つ前の版が凍結対象になります。記録し忘れると検査が落ちます。 人が覚えていることに頼りません。
    • ★★★ そして、v22 を公開したあとにページ数を書き換えてしまったのも、こちらのミスでした。 公開済みの評価基準は編集しないという原則に反しています。v22 は公開時のまま（最大 10 ページ）に戻し、25 ページにする変更は v23 として出します。
    • v23 で変えたのは測る範囲だけです。 項目・区分・判定・文言は v22 と 1 文字も違いません。
36. 2026.08 第176版2026-08-20定期改訂表現分類結果が変わります

    満たしている条件を、肯定形で書くようにしました

    10

    • ★★★ 利用者の指摘 ——「準備状態かチェックするツールなのに『準備ができている』と言えない理由はなんだ」。言えます。こちらの誤りでした。
    • SILVE はずっと「言えるのは否定側だけ」と書いてきました ——「塞がれていれば届かない」は言えるが「通っていれば認知される」は言えない、と。後半は正しいのですが、そこから「肯定形を一切書けない」を導いていたのが誤りでした。
    • ★★ 「結果を約束できない」ことと、「条件を満たしたと言えない」ことは、別です。 測っているのは条件です ——robots.txt で拒否していないこと、HTTP 200 が返ること、noindex や nosnippet が無いこと、リンクが辿れる形であること。これらは観測した事実なので、そのまま肯定形で書けます。
    • ★ Google 自身が同じ形で書いています。 技術要件を 3 つ肯定形で挙げた上で、「これらの要件を満たしたからといって索引されるとは限らない」と添えています。条件は肯定形で述べ、結果は述べず、境界を 1 文で添える —— それが正しい書き方でした。
    • 結果画面の総評を、こう変えました。「測った 25 ページの範囲では、条件はすべて満たしていました」。そして満たしている中身を並べます ——「AI 検索クローラーは、robots.txt で拒否されていません」「測ったページは、すべて公開取得できました」「検索結果への表示を止める指定はありません」「AI 機能への直接入力を止める指定はありません」「リンクは、すべて辿れる形で書かれています」。
    • ★★ 結果の見た目を直しました。 利用者の指摘 3 件。（1）「診断結果が黒すぎて見にくい。条件を満たしていたなら緑にするとか」——判定する区分は「満たしている / 満たしていない」の二値なので、色を当てられます。満たしていれば緑、満たしていなければ赤にしました。判定しない区分に赤緑を使わない方針は変えません（そちらに色を付けると成績表に見えます）。
    • （2）「総評の直後に、まったく同じ文章が大きく表示されている」——一覧は全区分を含むのに、見出しを区分名にしていたため、すぐ下の見出しと同じ文字列が 2 回出ていました。「診断の結果」に変えました。
    • （3）「2 回目はもっと全体的に補足しないと、同じ情報を 2 回表示させているだけ」——そのとおりでした。 満たしている行は、一覧の 1 行で終わっています。 詳細に残す意味があるのは、一覧に書けなかったことを持つ行だけです（伝わっていない実体の一覧・判定していない理由・直し方）。満たしている行の再掲をやめました。
    • ★★★ 「最大 25 ページと書いてあるのに 10 ページしか測定できていない」というご指摘をいただきました。 実際に取得する数は min(コード側の上限, 公開中の評価基準の上限) です。説明のページはコード側の定数だけを読んでいたため、「最大 25 ページ」と書きながら、公開中の基準（10 ページ）で測っていました。 公開中の基準から取るように直しました。 ★ 原因はもっと深いところにありました —— 次の版の記録をご覧ください。
    • ★ 境界の 1 文は必ず添えます。「これは、提供元が公開している条件を満たしているということです。実際に AI の回答へ出るかどうかは、これとは別です。」「届きます」「引用されます」「万全です」は書きません（機械で見張っています）。
37. 2026.08 第175版2026-08-20定期改訂表現分類結果が変わります

    測るページ数を 25 に増やし、結果の並びを組み直しました

    6

    • ★★ 利用者の指摘 ——「10 件調べてすべて 6/6 だった。パッと見の結果がどれも同じに見える」。確かめました。 37 サイトの robots.txt を調べたところ、34 件（92%）が 6 / 6 でした。塞いでいた 3 件は、いずれもニュース・レシピ系のメディア（PerplexityBot / Claude-SearchBot）で、SaaS 20 社は 1 社も塞いでいませんでした。
    • つまり、最も目立つ位置に、ほとんど動かない数字を置いていました。 塞がれているときだけ、宛先ごとの詳しい説明を出します。 通っている場合は、一覧の 1 行で足ります。
    • ★★ 測るページ数を 10 から 25 に増やしました。 利用者の指摘 ——「ページ数は測定に関係ないと言ったが、実際の修正箇所にもなりうるので、できるだけ多い方が親切なのではないか」。そのとおりでした。 判定が変わるかどうかと、直す場所が分かるかどうかは別の話です。 noindex が付いたページも、辿れない書き方のリンクも、どのページかが分からなければ直せません。
    • 上限を決めているのは根拠ではなく制約です ——相手のサーバーへの負荷と、お待たせする時間。実測で 25 ページ 27 秒でした。
    • ★ 「辿れない書き方のリンクが無いページ」という二重否定をやめ、「すべてのリンクを辿れるページ」にしました。 否定が 2 つ重なっていて読めませんでした。
    • ★★ 結果の並びを組み直しました。 利用者の指摘 ——「予防線が多すぎて、診断結果が冗長で分かりづらい」。総評と一覧 → 各項目の詳細 → 読み方 → 版と測定日 の順にしました。読み方の項目は 6 つから 3 つに減らしました（他の場所が同じことを言っていたものを落としました）。予防線を先に置きません。 読む方が知りたいのは結果であって、こちらの慎重さではありません。
38. 2026.08 第174版2026-08-20測り方の変更根拠分類採点表現結果が変わります

    一次資料に当たり直して、判定する項目と観測する項目を分けました（v22）

    18

    • ★★★ 提供元の資料と突き合わせたところ、3 項目の説明が事実と食い違っていました。 title ——「そのページが何かを機械が言えません」と書いていましたが、Google はタイトルリンクを 9 つの情報源から決めると明示しています（<title> / ページ上の主要な見出し / <h1> / og:title / 目立つテキスト / ページ内の他のテキスト / アンカーテキスト / そのページを指すリンクのテキスト / WebSite 構造化データ）。<title> はその 1 つでしかありません。
    • canonical ——「どれが正の URL か機械が決められません」と書いていましたが、Google は「どの指定方法も必須ではない。指定しなくてもたいてい問題ない」と明示し、指定が無ければ Google 自身が代表 URL を選ぶとしています。
    • 代替テキスト ——「何が写っているかが機械に伝わりません」と書いていましたが、Google は「alt text と、コンピュータビジョンのアルゴリズムと、ページの内容」を併せて使うと明示しています。
    • ★★ さらに 5 項目（組織・著者・日付・外部プロフィール・サイト名）は、Google の生成 AI 最適化ガイドが「構造化データは生成 AI 検索の必須条件ではない」と名指ししている領域でした。 同じガイドの隣の行にある「llms.txt は不要」は、前の版で落としていました。片方だけ読んでいたことになります。
    • ★★★ ただし「必須ではない」は「関係が無い」ではありません。 同じ資料群に逆向きの記述もあります ——「画像 SEO / 動画 SEO のベストプラクティスに従っていれば、生成 AI 検索にも最適化されている」「max-snippet の量的制限は、publisher が in-page structured data の形でコンテンツを提供している場合には適用されない」。後者は、Google が構造化データと AI 機能を直接結んでいる唯一の明示的な記述です。
    • ★ 総合点をやめた時点で、診断する項目と採点する項目が一致する必要は無くなっていました。 その帰結を取り損ねていたので、区分を分けます。 A（AI 検索への到達・利用条件）だけを判定します。 B（提供元が推奨する実装）は判定しません。
    • ★★ B には ◯/◯ を出しません。 title 9/10 と alt 28/31 を並べた瞬間、「どちらも 90%、だいたい 90 点」と読まれ、平均したくなります。その 2 つに交換可能性はありません。 総合スコアをやめた理由と、まったく同じ形です。内部では ◯/◯ を持ったまま、画面には「代替テキストがない画像 3 枚（対象 31 枚）」と、欠けている件数と母集団で書きます。
    • ★ B にも入場条件を置きました。 置かないと項目が増え続けます。緩めるのは 1 つ目だけで、「何個中何個で数えられる」は緩めません。 これで sitemap（分母が作れません）、semantic HTML（Google 自身が「完璧である必要はない」としています）、明確な見出し（「明確」を決定論的に数えられません）が入りません。「重要ではないから外す」ではなく「外から決定論的に測れる単位を作れないから採用しない」です。
    • ★★ noindex と nosnippet を分けました。 前の版は 4 種類の制御を 1 つにまとめていましたが、noindex は掲載そのものを止め、nosnippet は掲載を残したまま AI Overviews / AI Mode の直接入力だけを止めます。 max-snippet:N は量の制限、data-nosnippet は一部の除外です。単位の違うものを 1 つの数にするなと書いた版で、意味の違う制御を 1 つの ⚪︎× に潰していました。
    • ★ 内部リンクの単位を、本数からページへ変えました。 ナビゲーションに同じリンクが何十本あっても、行き止まりのページが 1 枚あれば問題です。 本数で数えると、その 1 枚が 190 分の 1 に薄まって見えません。
    • ★ canonical の母集団を、全ページから重複候補へ変えました。 Google が「必須ではない」と明記している以上、「canonical が無いページ」を欠落として数えるのは資料と食い違います。 canonical が意味を持つのは重複があるときだけなので、重複候補が 0 組なら行を出しません。
    • ★★★ 代替テキストの分母から、装飾画像を外しました。 これまで <img alt="" aria-hidden="true"> を「代替テキストが無い画像」として数えていました。これは装飾画像の正しい書き方です。 SILVE 自身の説明文に「装飾目的の画像は代替テキストを空にするのが正しい書き方です」と書いてありながら、検出器はそれを数えていました。 silve.jp が 0 / 31 と出ていた原因です。伝えるつもりのないものを「伝わっていない」と数えません。
    • ★ JavaScript なしで本文が取れるページ を判定から外しました。 根拠にしていた「重要な内容がテキスト形式で取れること」は、文脈がテキスト対 画像・動画であって、静的 HTML 対 JavaScript ではありませんでした。 Google は「ブロックされていなければ JavaScript 内の内容を処理できる」と明記し、他社はレンダリングの有無を公表していません。 ただし 初期 HTML に本文が「ある」ことは、どのクローラーに対しても確実に言えます（「無い」ことは結論になりません）。観測として残し、判定には使いません。
    • ★ 「取得できたページ」を「公開取得に成功したページ」に改めました。 これは SILVE が公開取得を試みた結果であって、各社のクローラーが同じ応答を受けることを保証しません（WAF は User-Agent や IP で挙動を変えられます）。
    • ★ 操作要素と入力欄を、AI 検索の表から分けました。 Google 自身が、ブラウザエージェント対応を「自社に関係があり、時間が余っていれば」という位置付けで紹介しています。 AI 検索の条件ではありません。
    • ★ Search Console に「生成 AI パフォーマンスレポート」が出ています。 AI Overviews と AI Mode での表示回数を、ページ・国・日付・デバイス別に見られます（一部のサイト所有者へ段階展開中）。SILVE が外から測るものではなく、サイト所有者ご自身が見るものです。 「測れません」ではなく「ここで見られます」とご案内します。
    • ★★★ これは項目を削った変更ではありません。 15 項目のうち 7 項目を判定から外しましたが、外したのは「根拠が弱いのに採点していたもの」です。 一次資料を再検証した結果、title・代替テキスト・構造化データなどは、AI 検索への掲載の必要条件とは確認できませんでした。 ただし提供元が利用または推奨すると明記しているものは、「提供元が推奨する実装」として引き続き観測します。
    • ★ 過去の診断は、実行した時点の分類のまま表示します。 v21 は「発信元」を診断項目として扱っていました。それを後から「実は推奨でした」と v21 の画面上で置き換えると、v21 の意味そのものを後から書き換えることになります。 公開済みの版は編集しないという原則をここにも当てます。現在の基準との違いは、結果画面に別枠で書きます。
39. 2026.08 第172版2026-08-20定期改訂根拠分類表現結果に影響なし

    拒否したときに何が起きるかを、宛先ごとに書き分けました

    10

    • ★★ これまで全宛先に同じ文を出していました ——「その AI 検索には、サイト全体が届きません」。各社の書き方はまったく違います。断定している提供元は 1 社もありませんでした。
    • OpenAI —「ChatGPT の検索の回答には表示されなくなる。ただしナビゲーショナルリンクとしては残り得る」。さらに「拒否したページの URL を第三者の検索経路から得た場合、リンクと題名だけを ChatGPT Atlas に出すことがある」。Anthropic —「可視性と精度が低下する可能性がある」（断定していません）。Perplexity —拒否した場合の結果を書いていません。 Google —AI 機能専用の拒否設定がなく、通常の検索のクロール・索引の資格を AI 機能が引き継ぐ構造です。
    • 宛先ごとの説明を、結果画面にそのまま出します。書いていない提供元には、こちらが書きません。
    • ★★ noindex の罠が OpenAI にもあると分かりました。 「リンクと題名だけ出るのを避けたいなら noindex を使う。ただし noindex を読ませるには、そのページのクロールを許可しておく必要がある」——Google とまったく同じ構造です。「ページ単位の掲載制御」の適用範囲に OpenAI を足しました。
    • ★ robots.txt を直したあと、いつ反映されるかも宛先ごとに分けました。 OpenAI と Perplexity は約 24 時間ですが、Google は「数日から数か月」と桁が違います。 共通の目安は出しません。
    • ★ WAF / CDN による拒否を、欠落として数えないことにしました。 OpenAI と Perplexity は「公開 IP レンジからのリクエストを許可すること」を掲載の条件として書いていますが、この診断が弾かれたことは、AI 検索のクローラーも弾かれることを意味しません（WAF は User-Agent や認証済みボットの判定で挙動を変えられます）。観測した事実と、提供元が書いている条件を並べるだけにします。
    • ★ 操作要素と入力欄の根拠に OpenAI を足しました。 「ChatGPT Atlas は ARIA タグ（スクリーンリーダーを支えるものと同じラベルとロール）を使ってページ構造と操作要素を解釈する」。提供元をまたいで一致した根拠になりました。
    • ★ 測る範囲の根拠を画面に書きました。「10 ページという数と優先の順番に、一次資料はありません。SILVE の判断です」。AI が何ページ読むかは、どの提供元も公開していません。 書けるのは「同じサイトの複数の URL が 1 つの生成 AI 機能に表示され得る」まで（Google の集計規則）——★ それは「表示された」であって「回答の生成に使われた」ではありません。
    • 広告の着地ページを検証する OAI-AdsBot を一覧に足しました（19 種）。AI 検索の掲載可否とは無関係なので、診断では数えません。
    • ★ Bing の記録を 1 件訂正しました。「サンプルである」という但し書きは Grounding queries にだけ掛かります。 引用回数と URL 別の件数は件数として扱えます。 ただし提供元が 3 回くり返しているとおり、順位でも権威でもありません。
40. 2026.08 第171版2026-08-20定期改訂根拠表現結果に影響なし

    「確認できていない」と書くのをやめ、JavaScript の根拠を当たり直しました

    7

    • ★ 利用者の指摘 ——「『できていない』は、できるのにやっていないのか、物理的にできないのか、そもそもそういう意味ではないのかで印象が大きく変わる。」当たっていました。この 1 語が、少なくとも 6 つの違うものを潰していました。
    • 書き分けを決めました。「その資料には書かれていません（読んだ資料を明記）」「提供元が公開していません」「外からは観測できません」「測っても、モデルが変われば持ちません」「証拠は要りません（論理で言えます）」。
    • ★★ そして「まだ読んでいません」「まだ測っていません」は、書く前にやることだと決めました。 書いた時点で怠慢の告知になります。答えが出るまでやってから書きます。
    • ★★ さっそく 1 件やり直しました。「JavaScript 非依存の本文取得」の説明は「多くの AI クローラーはレンダリングを行わない」と書きながら、それを支える一次資料を持っていませんでした。
    • 当たり直した結果、5 つ分かりました。 (1) Google は「ブロックされていない限り JavaScript 内のコンテンツを処理できる」と明記しています。(2) OpenAI・Anthropic・Perplexity は、レンダリングするかを書いていません（3 社のクローラー文書を全文確認）。(3) レンダリングしない側の根拠は、Vercel と MERJ による実測 1 件（2024-12）です。(4) ★ その実測は Claude-SearchBot を対象に含んでいません。(5) ★ 同じ実測が Applebot は「レンダリングする」と報告しています。
    • 証拠の格を下げました。「複数の観測が一致」から「単一の観測にとどまる」へ、確信度を「高」から「中」へ。1 つの研究で、20 か月前の測定です。
    • ★ もう 1 つ、説明が厳しすぎたので直しました。 構造化データが React Server Components のペイロードの中にある場合、これまで「JavaScript を実行しない取得では見えません」と書いていましたが、同じ実測が「初期 HTML に含まれていれば、JSON データや遅延した RSC でも索引され得る」と報告しています。 RSC のペイロードは初期 HTML の中にあります。「決まった形では見つからなかった」までに直しました。
41. 2026.08 第170版2026-08-20臨時改訂表現採点結果に影響なし

    「分母はサイト全体の数」と書いていたのを訂正し、ページの選び方の見張りを戻しました

    6

    • ★ 利用者の指摘 ——「最大 10 ページという数字も重要になってくる。何ページ読むか・どのページを読むかが、以前よりキーになるという理解でいいか。」そのとおりでした。
    • v20 では「代替テキストのある画像」を割合で段階分けしていたため、見るページが変わっても割合がある程度吸収していました。 v21 は「0 / 31 枚」の実数なので、選ぶページが変われば分子も分母もそのまま動きます。
    • ★★ そして、結果画面の説明が誤っていました。「分母はそのサイトに実際にある数」と書いていましたが、サイトに画像が 500 枚あっても、測った 10 ページに 31 枚あれば「31」と出ます。サイト全体の数ではありません。
    • 「今回測った ◯ ページの中に実際にあった数」に直しました。 あわせて「測るページ数が変われば分母も変わります。無料の診断は 1 ページ、有料は最大 10 ページです」を明記しました。同じサイトでも、見た範囲が違えば数は違います。
    • ★★ ページの選び方を見張る検査が、消えていました。 総合スコアの仕組みを削除したとき（2026.08.161）、その検査が一緒に消えていました。 選び方が黙って変わっても、誰も気づかない状態でした。
    • v21 で分母が実数になった直後に見張りを外していたので、最悪のタイミングでした。 戻しました。選び方を変えるなら、新しい版として出します。
42. 2026.08 第168版2026-08-20臨時改訂表現結果に影響なし

    「確かめていないためです」という書き方をやめました

    6

    • ★ 利用者の指摘 ——「その表現が嫌だ。なら確かめろよ、とユーザーは思う。」当たっていました。
    • 一言で「確かめていない」と言うと、やればできることを怠っていると読めます。 実態は 3 つが混ざっています。やればできる部分（引用されたかどうかの観測が未実装）、やってもすぐ腐る部分（モデルは毎月変わり、「今月効いた」は 3 か月後の主張になりません）、原理的にほぼ無理な部分（1 項目の効果を、時刻・モデル・プロンプトのばらつきから取り出すこと）。
    • さらに、各社は選び方を公開していません。 外から見えるのは入力と出力だけです。
    • ★ 意図的に伏せているのではありません。 確かめられるなら書きます ——「この項目を直すと引用が◯% 増える」は、私たちが出せる中で最も価値のある一文になります。伏せる理由がありません。
    • 書き方をこう変えました ——「各社は選び方を公開しておらず、外から確かめても、モデルが変われば結果は持ちません。」
    • 項目によって確かめやすさが違うことも記録しました。 塞がれていれば出ないことは論理で言えます。サイト名の表記は検索結果に出るサイト名として観測できます。一方「代替テキストを足したから引用が増えた」を単一項目の因果として示すのは、ほぼ無理です。
43. 2026.08 第167版2026-08-20定期改訂根拠表現結果に影響なし

    「直すと AI に選ばれやすくなる」とは書かない、と明示しました

    7

    • ★ 利用者の質問 ——「同水準のコンテンツで、片方が機械に読まれる形なら、そちらのほうがおすすめされやすいのか？」画面はそれに答えていませんでした。
    • 答えは「確かめていない」です。 私たちは効果検証を実装しておらず、「整えると引用されやすくなる」という主張はしていません。
    • ★ 層によって、言えることの性質が違います。 最初の層（そもそも読まれるか）だけは論理で確かです ——塞がれていれば、その宛先の回答には出ません。効果の証拠は要りません。
    • 残りの 3 つで変わるのは「引用されたときに、機械が何を言えるか」です。 著者が特定できなければ、AI は「◯◯社の△△氏によれば」と添えられません。これは効果ではなく、情報が無ければ言えないという論理です。
    • ★ 根拠の偏りも記録しました。 層 2〜4 の 11 項目のうち 10 項目が Google の資料に依存しています。他社（OpenAI・Anthropic・Perplexity）の一次資料には、内容側の指針が存在しません ——いずれもクローラーと robots.txt の話だけです。
    • 発信元の 3 項目（組織・著者・日付）は、資料はあるものの、この項目の主張を直接は支えていません。 Google 自身が「E-E-A-T はランキング要因か」に「No, it's not.」と明記しています（一方で「E-E-A-T と整合する内容を識別する要因の組み合わせは有用」とも書いています。どちらも事実なので、どちらも残しています）。
    • 結果画面の読み方と評価基準ページに、この線をそのまま書きました。
44. 2026.08 第166版2026-08-20臨時改訂表現結果に影響なし

    見出しを、場所の名前から「何が伝わるか」へ変えました

    8

    • ★ 利用者の指摘 ——「『そのページが何か』『ページの中の要素』『発信元』は何を表している？」。聞かれた時点で、見出しが説明になっていませんでした。
    • 以前の見出しは「場所の名前」でした（「ページの中の要素」＝どこにあるか）。場所を言っても、欠けたときに何が起きるかは伝わりません。 4 つとも「何が伝わるか」を問う形に揃えました。
    • そもそも読まれるか — robots.txt の許可・取得・本文・掲載制御。欠けていると、その範囲は存在しないものとして扱われます。
    • どのページかが分かるか — title・内部リンク・正の URL。読まれはしますが、そのページが何のページかを機械が言えません。
    • 画像や操作要素が伝わるか — 代替テキスト・操作要素の名前・入力欄のラベル。本文は読まれますが、文字になっていないものの中身が伝わりません。
    • 誰が・いつ書いたかが分かるか — 組織・著者・日付・外部プロフィール・サイト名。内容は読まれますが、誰が・いつ書いたのかを機械が特定できません。
    • ★ 「最低ライン」という札を外しました。 利用者の指摘 ——「その書き方が嫌だ。無くてもよくないか」。そのとおりでした。すぐ下の 1 文が同じことを、より正確に、責める語調なしで言っています。 札は同じことを成績のような言い方で重ねているだけでした。
    • トップページのサンプルの数字も、結果画面と同じ色に揃えました。
45. 2026.08 第165版2026-08-20臨時改訂表現結果に影響なし

    「宛先」という言い方をやめ、色が数字と食い違っていたのを直しました

    6

    • ★ 利用者の指摘 3 件をまとめて直しました。
    • 1.「届く宛先」という言葉が馴染まない。 そのとおりでした。「AI 検索クローラー」に言い換えました。 robots.txt を触ったことがある方の語彙に寄せています。
    • 2. 全部通っているときに数字が無色だった。 満ちている数字を無色にすると、読み手は「で、これは良いのか」を探すことになります。 緑にしました。★ ただし緑は「塞がれていない」の色であって、「AI の回答に出る」の色ではありません。 すぐ下の但し書きがそれを引き受けます。
    • ★ 3.「6 / 6 なのに枠が赤い」 ——不具合でした。 枠の色を、そのカードの数字ではなく最低ラインの層全体で決めていたため、取得できなかったページや本文が JavaScript 依存のページがあると、クローラーが全部通っていても赤くなっていました。
    • 見出しと数字はクローラーの話をしているのに、色だけ別のことを言っていました。 色は、そのカードの数字だけで決めるように直しました。最低ラインの他の項目に欠けがあることは、その層の見出しで出します。
    • 私たちは「増減と色を必ず対応させる。数字と色が食い違うと、表そのものが信用されない」と自分で書いていました。 同じことをしていました。
46. 2026.08 第164版2026-08-20定期改訂根拠結果に影響なし

    AI クローラーの一覧を公開しました

    7

    • ★ 利用者の指摘 ——「届く宛先が 6 種なのはなぜだ？ 6 種のみが情報を公開しているのか、本当はそれ以上あるが調べていないのか、主要なものなのか、なんとなくなのか。」
    • 答える場所がありませんでした。 全 18 種の一覧・用途の分類・一次資料の URL・最終確認日はすべてコードの中にあり、画面のどこにも出ていませんでした。 評価基準の根拠は全部公開しているのに、クローラーの分類だけが非公開でした。
    • ★ /crawlers を作りました。 用途別（AI 検索での掲載・引用 / アシスタントの参照 / モデルの学習 / ユーザー操作による取得）に全種を並べ、一次資料へのリンクと確認日を添えています。
    • 「届く宛先」が 6 種になる手順も書きました。 (1) 一次資料に当たって調べたものだけを載せる（18 種）(2) そのうち「AI 検索での掲載・引用」の用途を持つのが 7 種 (3) 拒否の意味が一意に読めないものを外して 6 種。
    • ★ 外している 1 種の理由も出しています。 meta-externalagent は学習と掲載が同じ User-agent に同居しており、拒否されていても「学習を断りたいのか、掲載を断りたいのか」を判別できません。判別できないものを掲載の遮断として数えると、「学習の拒否は減点しない」という原則を迂回して減点することになります。
    • ★ 「これで全部です」とは書いていません。 私たちが調べた範囲です。「まだ調べていない」ものと「調べたが確定できなかった」ものを区別するため、後者は「未確定」として一覧に残しています（Bytespider）。
    • 現行の公式文書に記載が無い User-agent も載せました。 robots.txt に書かれたまま残っていることがあるためです。「過去に案内されていた」とは書きません —— 確認できるのは「現在の文書に含まれていない」ことだけです。
47. 2026.08 第163版2026-08-20臨時改訂表現結果に影響なし

    見ている 6 種のクローラーを、名前で全部出すようにしました

    5

    • ★ 利用者の指摘 ——「届く宛先というのが各クローラーの数という認識で合っているか。その 6 つは診断結果のどこに書かれている？」。どこにも書かれていませんでした。
    • 「6 / 6」という数と、塞がれている宛先の名前だけを出していました。 つまり全部通っているときは、1 件も名前が出ませんでした。
    • ★ 数だけにするのは、宛先ごとの可否を 1 つの数へ潰すことです。 採点でやめたことを、表示でやっていました。 誰が通って誰が塞がれているかは、この診断が出すべき情報そのものです。
    • 見ている 6 種を、運営者とあわせて全部表示します。 OAI-SearchBot（OpenAI）・Googlebot（Google）・Claude-SearchBot（Anthropic）・PerplexityBot（Perplexity）・Bingbot（Microsoft）・Applebot（Apple）。
    • 新しい AI 検索が増えたときは、この一覧に行が 1 本増えます。 既存の判定は動きません。
48. 2026.08 第162版2026-08-20臨時改訂表現結果に影響なし

    結果画面に「読み方」を置き、私たちの経緯を外しました

    4

    • ★ 利用者から「診断結果の見方を教えてくれ」と言われました。 それが欠落そのものでした ——「なぜ総合点が無いか」は書いてあるのに、「ある数字をどう読むか」が書いていませんでした。
    • 点数を出さない形は、読み手にとって初見です。 結果の先頭に読み方を置きました。上から順に読むこと（上の層が欠けていると下の層は届かない）、分母はそのサイトに実際にある数であってこちらが決めた満点ではないこと、足し合わせた総合点は出さないこと、そして 満たしていないことは欠陥を意味しないこと。
    • ★ 「以前は 100 点満点で、拒否しているサイトでも 69 点出ました」という説明を、結果画面から外しました。 利用者の指摘です ——「過去の形式はユーザーには関係ない」。そのとおりでした。あれは私たちの反省であって、結果を読む人の役に立ちません。 しかも結果を読んでいる最中に「前は間違っていた」と読ませることになります。
    • 経緯が必要な方は、評価基準ページの変更履歴でご覧いただけます。 消したのではなく、置き場所を変えました。
49. 2026.08 第161版2026-08-20定期改訂項目の追加・廃止表現結果に影響なし

    総合スコアの仕組みを、コードからも消しました

    7

    • ★ v21 で総合スコアを廃止しましたが、それを描くための仕組みは残っていました。 約 2,000 行が、「出すべきでなかった」と自分で宣言した数字を表示するためだけに動いていました。
    • ★ 消した理由は「使っていないから」ではありません。 v21 を出した直後、設定を 1 か所書き忘れただけで、総合 0 点が本番に出るところでした。 2 つの仕組みが並んでいる限り、片方を壊したことに気づけません。
    • まだ正式に開始していない段階で、加重和で測った診断はすべて私たち自身が実行したものです。 調査で分かったことは文章として残しています。残っていたのは数字だけで、その数字は間違った形で出したものでした。 削除しました。
    • ★ 版の記録（v1〜v20）と変更履歴は残しています。 なぜ配点が 104 から 70 になり、最後にゼロになったかという記録は、私たちが売っているものそのものだからです。評価基準ページの変更履歴でご覧いただけます。
    • 改善計画と社内共有用の要約を、観測の上に作り直しました。 どちらも「失点の大きい順」に依存していたため、v21 で一度動かなくなっていました。並びは層の順を保ち、「改善余地 ◯ 点」のような合計は作りません。
    • 前回との比較も作り直しました。 以前は「+5 点のうちサイト側 +8 / 基準側 −3」という引き算でしたが、合成しなければ引き算で復元する必要がありません。 「代替テキストのある画像 0 / 31 → 24 / 31」のように、どの項目がどう動いたかが直接出ます。
    • ★ 「数えた対象が変わりました」を別に出すようにしました。 画像やページを減らせば「伝わっていないもの」も減りますが、伝わるようになったわけではありません。
50. 2026.08 第159版2026-08-20測り方の変更採点項目の追加・廃止分類結果が変わります

    総合スコアを廃止しました（チェックリスト v21）

    11

    • ★ 20 版のあいだ続けてきた総合スコア（重みを掛けて 100 点満点へ正規化する形）を、やめました。
    • 理由は 1 つです。あの形は「項目は交換可能である」と黙って言っていました。 実際、AI 検索クローラーを robots.txt で全面拒否しているサイトが、画像の代替テキストや見出しを整えることで、拒否したまま点を取り戻せました。 前提条件を 3 つとも満たさなくても 69 点出ます。塞がれていたら、整えた代替テキストは誰にも読まれません。
    • ★ 調べていくと、総合スコアが成立する条件が 3 つとも欠けていました。 (1) 実効重み 70 のうち 9 点（13%）は AI 検索の引用可否に効かない項目（エージェント操作向け）で、14 点（20%）は Google 向けのみでした。宛先の違う話を足していました。 (2) 判定できない項目は分母から外れるため、A 社の 70 点と B 社の 70 点は違う分母で出た数字でした。(3) 重み 10/9/6/4/3/2/1 に外部の校正がありません。
    • ★ 「重みだけ消す」はできませんでした。 全項目を等価にして「◯ 項目中 ◯ 項目」で出す案も検討しましたが、等価も重みです。 しかも ⚪︎ か × かを決めるには閾値が要り、閾値は重みと同じで校正できません。
    • ★ 実データで確かめました。 同じサイトの同じ観測に 3 つの集計方法を当てると 75.5% / 96.4% / 82 点になりました。集計方法が、暗黙に重みを決めていました。
    • ★ 代わりに、同じ単位のものだけを数えます。「届く宛先 6 / 6」「本文が取れるページ 9 / 10」「代替テキストのある画像 0 / 31」。どれも私たちが決めた分母を持ちません。 そのサイトに実際にある宛先・ページ・画像の数です。重みも閾値も要りません。
    • ★ 優先順位は、層の入れ子構造が持ちます。 サイト全体が塞がれていれば、その下のページも要素も届きません。だから上から読めばよく、「robots.txt を 10 点、代替テキストを 2 点」と決める必要がありません。
    • ★ 項目を 30 から 15 に絞りました。 残す条件は 2 つで、「これが欠けていると機械に何が伝わらなくなるか」を 1 文で言えることと、「何個中何個」で数えられる実体があることです。落としたのは、段落の長さ・数値の記述の多さ・レイアウトの安定性など、欠けても何かが伝わらなくなるわけではない項目です。
    • ★ 「これが無いと AI に認知されない」と言えるのは、15 のうち 4 項目だけです。 残りは「認知はされるが、○○が伝わらない」であって、別の話です。混ぜて表示しません。
    • ★ そして、その 4 項目ですら言えるのは否定側だけです。「塞がれていれば届かない」は言えますが、「通っていれば認知される」は言えません。 画面にも「届きます」とは書きません。
    • 過去の診断は、実行した時点の版のまま読めます。 総合スコアも消していません。公開した版は書き換えません。
51. 2026.08 第123版2026-08-19臨時改訂採点結果が変わります

    取得できなかった robots.txt を「制限なし」と読まないようにしました（チェックリスト v19）

    8

    • ★ 配点は 1 点も変えていません。 配点される重みの合計は 70 のままで、robots.txt が取得できているサイトのスコアは動きません。
    • 発端は、私たち自身の週次バッチが 403 で失敗したことでした。 前日の確認では同じ User-Agent で 200 だったのに、本番から叩くと 403 になりました。違いはリクエストの出どころです。
    • そこで気づきました。 掲載経路の項目（配点が最も大きい項目）は、robots.txt が見つからないことを、そのまま「何も塞がれていない」と読んで満点にしていました。
    • ★ しかし「見つからない」には 2 つの意味があります。 「本当に置かれていない」と「取得できなかった」です。前者だけが「制限が無い」と読めます。
    • 404 とそれ以外の失敗を分け、後者は判定しないことにしました。 これは 2026.08.47 で決めた「観測できなかったものを満点に変換しない」の適用漏れでした。
    • ★ あわせて、robots.txt の Crawl-delay に従うようにしました。 私たちは「robots.txt を尊重する」と書いていましたが、この指示だけ読んでいませんでした。 国内の企業サイト 11 件を確認したところ宣言は 0 件で、実務上ほとんど影響はありません。
    • 従えない間隔が宣言されている場合は、無視して取りに行くのではなく、取得を行いません。 その場合はスコアを出さず、理由を表示します。尊重すると書いた以上、書いたとおりにします。
    • 過去の診断は再採点されません。 採点は診断ごとに保存されています。
52. 2026.08 第88版2026-08-17定期改訂採点根拠結果が変わります

    残りの項目にも同じ検定を当てました。5 件のうち 3 件は動きませんでした（チェックリスト v17）

    12

    • ★ 同じサイトを同じ日に測っても点が変わります。 配点される重みの合計は 73 から 71 になります。
    • 2026.08.84 で「同じ検定をまだ当てていない」と列挙した 5 項目に、当てました。 検定は 1 つです ——「その資料は、不在を不備と述べているか」。
    • ★ 5 件のうち動かしたのは 2 件で、3 件は据え置きました。同じ検定を当てて「切らない」結論が出ることが重要です。全部下がるなら、それは検定ではなく方針です。
    • 「title と meta description」は、2 つの基準が混ざっていました。 title については Google が「サイトのすべてのページに title 要素でタイトルを指定してください」と無条件で書いています。一方 meta description については「スニペットは主にページの内容そのものから作られます」「より正確に説明できる場合に使われることがあります」で、無いことを不備とする記述がありません。
    • meta description を採点から外しました。観測としては出し続けます。 判定は title の網羅と重複だけで行います。2026.08.60 で見出しの数え上げを、2026.08.77 でリンクの本数を外したのと同じ型です。
    • title についても正直に書いておきます。 Google は「title が無い場合や不適切な場合は、見出し・本文・外部サイトのアンカーテキストから自分で生成する」とも書いています。したがって「無いと表示されない」ではありません。 それでも無条件の指示がある数少ない項目なので、採点は残します。
    • ★ 「構造化データの実装」を 3 点から 1 点にしました。 提供元は構造化データを基本的な検索には任意とし、必須性を「リッチリザルトの対象になるか」に限定して書いています。不在を不備とする記述はありません。
    • 私たちは 2026.08.11 で同じことを書いていました ——「Google が『生成 AI 検索に構造化データは必須ではなく、専用の schema.org マークアップも存在しない』と明記している」。それでこのカテゴリを 20 点から 7 点へ下げたのに、この項目だけ 3 点のまま残っていました。 カテゴリ内でも最大の配点で、最も一般的な「何かしらの JSON-LD があるか」が最も重い状態でした。0 にはしません —— 構文が壊れた JSON-LD はあっても無視されるだけなので、実害があり、検出には意味があります。
    • ★ 据え置いた 3 件の理由も書きます。
    • 「操作要素の名前」と「入力欄のラベル」は据え置きます。資料の性質が他と違います。 これらは Chrome の Lighthouse が agentic browsing の審査項目として明記しているものです。監査項目とは「満たしていなければ落ちる」ものであり、提供元が不在を不備として扱っていることそのものです。「無くてもよい」と書いてある資料とは、証拠の性格が根本的に違います。
    • 「Organization の明示」も据え置きます。 2026.08.11 でまさにこの理由により 8 点から 2 点へ下げています。 同じ理由で二度下げるのは、根拠を二重に数えることになります。
    • 空いた 2 点は配り直していません。 配点される重みの合計は、根拠の合計であって定数ではありません。
53. 2026.08 第87版2026-08-17定期改訂採点根拠

    HTML を見ても分からない場所で、掲載が止められていました（チェックリスト v16）

    8

    • 配点は 1 つも変えていません（合計 73 のまま）。検出できる範囲が広がるので、該当するサイトではスコアが変わります。
    • 2026.08.85 で「ページ単位の掲載制御」を追加したとき、注記に「X-Robots-Tag（HTTP ヘッダ）は見ていないので検出は下限です」と書きました。その穴を塞ぎます。
    • 提供元は 2 つの書き方が同じであると明記しています —— 「Any rule that can be used in a robots meta tag can also be specified as an X-Robots-Tag.」（robots メタタグで使えるルールは、すべて X-Robots-Tag でも指定できます）
    • ★ つまり HTML を見ても分からない場所で、掲載を止められます。 メタタグで書いたサイトは前の版で捉えられていましたが、同じことを HTTP ヘッダでやっているサイトは素通りしていました。
    • ★ 書き方が紛らわしい点を、資料を読んで区別しました。 max-snippet: 0 は「指定名: 値」ですが、googlebot: nofollow は「事業者名: 指定」で、見た目が同じです。 左側が既知の指定名かどうかで判別しています。7 通りの形を実際に通して確認しました（-1 は「長さは提供元が決める」なので制限として数えない、同じヘッダが複数あると連結される、メタタグとの併用、など）。
    • ★ ヘッダ由来の指定は、結果画面にそう書きます。 「ページのソースを見ても出てきません」と明記し、改善手順にも「サーバやリバースプロキシの設定も確認してください」を足しました。見えない場所にある設定を、見える場所と同じ書き方で案内しません。
    • 残る限界も書いておきます。 画像や PDF などページ以外のリソースに付いた指定は見ていません。unavailable_after（期限つきの除外）は、期限が来ているかどうかまでは判定していません。
    • これで、網羅性の点検で見つかった穴は一巡しました。 資料の側から数え直す方式（COVERAGE_AUDIT.md）は今後も続けます。
54. 2026.08 第86版2026-08-17定期改訂採点項目の追加・廃止根拠結果が変わります

    集めていたのに、読んでいなかったデータがありました（チェックリスト v15）

    10

    • ★ 項目が 2 つ増えます。 配点される重みの合計は 70 から 73 になり、スコアが変わります。
    • ★ 点検のやり方を変えました。 これまでは「入っている項目が正しいか」だけを見ていましたが、提供元の資料が挙げている提案を逐語で全部書き出し、私たちの項目へ突き合わせました（Google の生成 AI 向けガイドは 23 個の提案を持ちます）。思いついたものを足すのではなく、資料の側から数えます。
    • ★ そのうち 2 件は「既にデータを集めているのに、どの項目も読んでいない」状態でした。 採点していなかったのではなく、集めたものを使っていませんでした。
    • 画像の代替テキスト（重み 2）を追加しました。 Google は alt を「画像のメタデータとして最も重要な属性」とし、「Bad (missing alt text)」を明示的な悪い例として挙げています。これは canonical（「指定しなくてもおそらく問題ない」）や sitemap（「小規模なら不要」）とは、資料の書き方が違います。 こちらは不在そのものを悪い例として名指ししています。
    • 装飾目的の画像は代替テキストを空にするのが正しい書き方なので、100% を求める判定にはしていません。 また画像が 1 枚も無いページでは、この項目を採点しません（分母からも外します）。
    • 取得したページ同士の重複（重み 1）を追加しました。 提供元は重複を減らすことを勧めていますが「時間があれば（if time permits）」と条件を付けています。提供元が自分で優先度を下げているものに、重い配点はしません。 見ているのは取得した最大 10 ページの範囲だけで、サイト全体の重複ではありません。
    • ★ 見つけたが、採らなかったものも記録します。穴を全部埋めるのが正しいのではありません。
    • モバイル対応（viewport の指定）は採りませんでした。 現行の資料に一度も出てきません。 出典は 2011〜2014 年のブログだけで、現行のモバイル ファースト インデックスの資料は「モバイル版を持つことは検索結果に含まれるための必須条件ではない」と書いており、viewport には言及がありません。 古いブログを根拠に採点項目を作りません。
    • 「表があるか」も採りませんでした。 挙げているのは 1 社のブログの助言にとどまり、しかも「表があるか」は構造の明快さの弱い代理指標にすぎません。
    • 新しい 2 項目には、最初から「判定できないときは分母から外す」を入れてあります。 画像が無いページ、比べる相手が 1 ページしか無い場合が該当します。2026.08.78 と 2026.08.81 で 2 度直した型を、新しい項目では最初から避けます。
55. 2026.08 第85版2026-08-17定期改訂採点項目の追加・廃止根拠結果が変わります

    掲載を止めるもう 1 つの制御面を、見ていませんでした（チェックリスト v14）

    11

    • ★ 項目が 1 つ増えます。 配点される重みの合計は 66 から 70 になり、スコアが変わります。配点対象の項目を増やすのは、初期の基準以来はじめてです。
    • ★ これまでの点検は、すべて「入っている項目が正しいか」でした。「入っていない項目は何か」を一度も見ていませんでした。 探した結果、最大配点の項目に穴が開いていました。
    • 「AI 検索クローラーの許可状況」（重み 10・最大配点）は、robots.txt しか見ていません。 ところが Google は掲載を止める方法を 2 つ挙げています。
    • > To limit the information shown from your pages in Search, use nosnippet, data-nosnippet, max-snippet, or noindex controls.（ページから表示される情報を制限するには、これらの指定を使います）
    • ★ つまり robots.txt を全面的に許可したまま、全ページに nosnippet を付けたサイトが、最大配点の項目で満点を取れていました。 実際には表示されない状態なのに、「開いている」と評価していたことになります。
    • ★ 私たちは知っていました。 この変更履歴に「nosnippet は Google では AI Overviews / AI Mode への直接入力を止める」と自分で書いています。知っていて、書いていて、測っていませんでした。 採点しない以前に、クローラーが robots メタタグを 1 つも読み取っていませんでした。
    • 追加した項目は「ページ単位の掲載制御」（重み 4）です。 これは 2026.08.84 で立てた区分でいう「無いと成立しない」側です —— 提供元が「無くてもよい」と書いている推奨ではなく、指定があれば表示されなくなる仕組みそのものです。
    • ただし robots.txt の遮断（重み 10）と同じ重みにはしていません。 あちらは取得そのものを止めるので後続のすべてが成立しませんが、こちらは取得はされ、通常の検索結果にも出た上でスニペットとして使われなくなります。止まる範囲が違うので、重みも変えます。
    • ★ 意図した設定であることは十分あり得ます（会員限定ページ、重複ページなど）。したがって改善手順は「直してください」ではなく「意図どおりか確かめてください」と書いています。学習クローラーへの方針表明と同じ姿勢です。一方で、テンプレートや CMS の設定で意図せず全ページに付いてしまう事故は実在します。
    • 検出の限界も書いておきます。 X-Robots-Tag（HTTP ヘッダ）は見ていません。 同じ制御をヘッダでも行えるので、この項目の検出は下限です。 また data-nosnippet（本文の一部だけを除外する指定）は、ページ全体の制御とは意味が違うので減点しません。効く相手も事業者ごとに異なるため、この版では Google についてのみ「効く」と宣言しています。
    • ★ これは網羅性の点検の最初の 1 件にすぎません。 同じ探し方をまだ当てていない領域を記録しました —— Microsoft の現行 AI 向け指針が挙げる「構造と明快さ」のうち表を見ていないこと、「深さと専門性」に対応する項目が無いこと、X-Robots-Tag。見つけていないのか、見て採らなかったのかを区別して残します。
56. 2026.08 第84版2026-08-17定期改訂採点根拠結果が変わります

    「無いと成立しない」と「あると良い」を、同じ減点で扱っていました（チェックリスト v13）

    12

    • ★ 同じサイトを同じ日に測っても点が変わります。 配点される重みの合計が 73 から 66 になります。
    • ★ 根拠は一次資料であって、著名サイトの点数ではありません。 きっかけはご利用者からの問い（「著名なサイトが 50〜60 点になるが妥当なのか」）でしたが、大手だから最適化されているとは限りません。点数の分布は、この基準が正しいかどうかの証拠になりません。 下げた理由はすべて、提供元の資料が「無くてもよい」と書いていることです。分布を見て配点を決めるのは、私たちが記事で否定している「観測を根拠のように扱う」ことそのものです。
    • ★ 調べた結果、採点項目に性質の違う 2 種類が混ざっていて、同じ強さで減点していました。
    • 片方は「無ければ後続が成立しない」条件です。 クローラーを robots.txt で塞いでいれば載りません。静的な HTML に本文が無ければ、レンダリングしないクローラーには読めません。ページが取得できなければ何も始まりません。リンクが辿れなければ他のページへ届きません。これは提供元の推奨ではなく、仕組みの前提です。
    • もう片方は、提供元自身が「無くてもよい」と書いているものです。 Google は canonical について「指定は必須ではありません。指定しなくてもおそらく問題なく動作します」と明言しています。sitemap については「サイトが小規模（約 500 ページ以下）で、内部リンクが十分に張られていれば不要な場合があります」と条件を書いています。
    • 後者を前者と同じ強さで減点していました。 canonical を 3 点から 1 点、sitemap を 3 点から 2 点にしました（sitemap は「多くの場合は有益」とも書かれているので 1 にはしません）。なお私たちは最大 10 ページしか取得しないので、そのサイトが 500 ページ以上かを判定できません。 条件を確かめられないまま条件つきの推奨を減点している、という自覚のもとで下げています。
    • ★ 「数値・データの記述」を 4 点から 2 点にしました。根拠の中身に問題があります。 この項目は 22 項目で唯一、査読済みの研究を根拠に持ちます。しかし著者らの公式実装は、該当する操作のプロンプトに「架空でもよい（even if hypothetical）」を含んでいました。 つまり実験が測ったのは、架空を含む「統計の形をしたテキスト」の効果です。私たちの検出器も、正しい数値と捏造された数値を区別できません。 重い配点は「数値を足すこと」を最も安い得点源にしますが、それは私たち自身が「数値を足すこと自体を目的化させない」と書いている方向です。査読済みという格は残るので 0 にはしません。
    • 「連絡先の機械可読性」を 3 点から 1 点にしました。 この項目の根拠の注記には元から「配点は最小に留める」と書いてありましたが、73 点中 3 点は最小ではありませんでした。 確信度も元から「低」で、根拠は schema.org の仕様定義であって「無いことが不備である」という推奨ではありません。問い合わせ窓口が期待されないサイト（技術リファレンスなど）にも無条件で当たっていました。
    • 成立条件の 4 項目は 1 点も動かしていません（計 29 点）。結果として、スコアの 44% を「無いと成立しないもの」が占めます。 それがこの版の狙いです。
    • 空いた 7 点は配り直していません。 配点される重みの合計は、根拠の合計であって定数ではありません。
    • ★ 同じ検定をまだ当てていない項目があります。 「title と meta」「構造化データの実装」「操作要素の名前」「入力欄のラベル」「Organization の明示」は、今回の一次資料の通読対象に入れていません。一部だけ下げて恣意的にならないよう、当てた項目と当てていない項目を明記しています。 次の版で同じ問いを当てます —— 「その資料は、不在を不備と述べているか」。
    • これは「点が甘くなった」ではありません。 分母が小さくなるので点は上がる方向に動きやすいですが、上げるために下げたのではありません。 提供元が「無くてもよい」と書いているものを減点し続けることを説明できないから下げました。点が上がるのは副作用です。
57. 2026.08 第82版2026-08-17定期改訂採点根拠結果が変わります

    発信元メタデータの配点を、調査の結果へ合わせました（チェックリスト v12）

    11

    • ★ 同じサイトを同じ日に測っても点が変わります。 配点される重みの合計が 79 から 73 になります。2026.08.60（91 → 79）以来、2 度目の配点そのものの見直しです。
    • 問いを 1 つに絞って調べました —— 「一次資料に、不在（署名が無い・日付が無い・sameAs が無い）を不備とする記述はあるか」。「日付があれば使われることがある」はこの問いの答えではありません。 私たちは不在を減点しているので、不在が問題だと言う資料が要ります。
    • Google / OpenAI / Perplexity / Microsoft の一次資料を通読しました。 Google は author も datePublished も sameAs も Recommended とし、「必須項目はありません」と明記しています。署名の推奨は「署名が期待されるような場合に」という条件つきです。OpenAI と Perplexity には内容側の指針が存在せず、Microsoft の現行の AI 向け指針は著者にも日付にも触れていません。
    • ★ 公開日・更新日を 4 点から 1 点にしました。 4 つのどこにも、日付が無いことを不備とする資料がありませんでした。 ただし 0 にはしません —— 機械可読な日付という仕組み自体は公式に定義され、実際に使われています。支えられていないのは「無いことを減点すること」だけです。記事の構造化データが「記事を持つサイトにのみ意味がある」として 1 点なのと、同じ状態と判断しました。
    • あわせて、重い配点そのものが良くない方向へ働いていました。 日付を持たないサイトが最も安く点を得る方法は、日付が意味を持たないページにも日付を刻むことです。Google は日付の操作を警告サインの自己点検質問に挙げています。私たちがお客様に注意を促している位置に、自分の配点が立っていました。
    • ★ 著者情報を 3 点から 2 点にしました。 同じ型ですが、不在を問題と明記した資料が 1 件だけ存在します（2014 年・従来の検索について）。同じ提供元の現行の AI 向け指針は著者に触れていないので採点の根拠にはしませんが、日付と同じ 1 点まで下げる理由もありません。
    • ★ 外部プロフィールとの接続を 4 点から 2 点にしました。決め手は内部の整合性です。 sameAs は運営組織（Organization）の 1 プロパティですが、その運営組織があるかどうかを見る項目は 2 点で、その理由に「このスキーマで生成 AI での露出が上がるという根拠は確認できていません」と書いてあります。親が 2 点で、その中の 1 プロパティが 4 点という状態は説明できません。 確信度も高から中へ下げました —— 資料は仕組みを述べていますが、効果については何も述べていません。
    • ★ 組織名表記の一貫性は 3 点のまま据え置きました。 証拠の扱いが既に「推論にとどまる」と正しく書かれており、以前 6 点から 3 点へ訂正済みです。そして表記揺れは日本語に固有の問題で、海外の一次資料が無いのは当然です。「一次資料が無い」を理由に下げると、私たちが日本向けに持っている価値そのものを削ることになります。根拠が弱いから下げる、を機械的には当てません。
    • 空いた 6 点は配り直していません。 配り直せば「合計を維持するため」という根拠のない理由で他の項目が動きます。配点される重みの合計は、根拠の合計であって定数ではありません。
    • 結果として、発信元メタデータが全体に占める割合は約 18% から約 11% になります。 直接の根拠がはっきりしているカテゴリ（クローラー対応・エージェント対応）の比重が上がります。それがこの版の狙いです。
    • 解決していないことも書いておきます。 「署名や日付が期待されるページか」を私たちは判定できません。ページごとに適用外とする案は、記事の構造化データの有無で判定すると「正しくマークアップしたサイトだけが減点され得る」という逆転が起きるため採れませんでした。重みを下げたのは、その代わりの措置です。
58. 2026.08 第81版2026-08-17定期改訂採点結果が変わります

    比べる相手が無いのに減点していました（チェックリスト v11）

    6

    • 配点は 1 つも変えていません（合計 79 のまま）。2026.08.78（v9）とまったく同じ型で、判定できていないものを減点していました。点は上がる方向にしか動きません。
    • ★ v9 の修正が、片方にしか当たっていませんでした。 組織名表記の項目は「ご申告いただいた名称」と「サイト上の組織名」を突き合わせますが、成立しない場合が 2 通りあります。 v9 では「会社名が未申告」だけを直し、「サイトに運営組織の構造化データが 1 つも無い」を見落としていました。どちらも突き合わせる相手が存在しない、まったく同じ状態です。
    • 報告された症状だけを直して、分岐を 1 つずつ見なかったのが原因です。
    • ★ さらに、同じ 1 つの事実で二重に減点していました。 運営組織の構造化データが無いことは、構造化データのカテゴリの項目（2 点）が既に減点しています。 そこへこの項目が 3 点をもう一度引いていました。合計 5 点が、1 つの事実に対して引かれていました。同じ観測を 2 つの項目で数えません。
    • ★ v9 で足した検査は、これを捕まえられませんでした。 あの検査は「採点側と画面側が同じものを判定不能と見なしているか」を見ます。古い実装は両方が「判定済み」で一致していたので、素通りしました。 整合性は見られても、判定が正しいかは機械では見られません。 検査自身にその限界を書きました。
    • 会社名を申告して診断された場合にだけ効きます。 未申告の場合は v9 で既に採点から外れています。
59. 2026.08 第80版2026-08-17定期改訂根拠分類結果に影響なし

    「どの AI に効くか」の宣言を、根拠のあるものだけに絞りました（チェックリスト v10）

    9

    • スコアは変わりません。 重み・判定・配点の理由は 1 つも変えていません。変えたのは「この項目はどの AI に効くと考えているか」の宣言だけです。この欄は表示と説明にしか使っておらず、採点には関与しません。
    • ★ 発信元メタデータの 4 項目は、すべて Google の資料しか引いていないのに、3〜4 の AI に効くと宣言していました。 14 個の宣言のうち、根拠を確認できたのは 2 個だけでした。
    • SILVE 自身の原則に反していました。 「プラットフォーム固有の仕様を他プラットフォームへ一般化しない。「AI bot」という単一カテゴリで一律評価しない」と決めているのは私たちです。
    • 4 つすべての一次資料に当たりました。 「調べていないので分からない」を「効く」の理由にしないためです。OpenAI と Perplexity の公開資料には、内容側の指針が存在しません（どちらもクローラーと robots.txt の話だけです）。Microsoft の現行の AI 向け指針が挙げているのは、鮮度・構造・深さ・根拠の 4 つで、著者にも日付にも一度も触れていません。
    • ★ 唯一の例外を、あえて採りませんでした。 「著者が不明であること（admin 名義）は問題である」と明記した資料が 1 件だけ見つかりました。ただし 2014 年の、従来の検索についてのものです。同じ提供元の現行の AI 向け指針が著者に触れていない以上、AI 検索へ適用するのは資料の射程を超えます。 資料としては記録に残しました — 読めますが、採点の根拠にはしていません。
    • ★ 自分の正本と実装が食い違っていました。 エンティティの正本には「Google 向けのエンティティ施策を ChatGPT のエンティティ最適化として一般化しない」と書いてあるのに、実装は ChatGPT に効くと宣言していました。 2026.08.59 で直したのと同じ型で、向きが逆です（あのときは注記が慎重で説明文が断定していた。今回は正本が慎重で、実装のほうが広かった）。
    • 「エージェントに効く」という宣言も 1 件外しました。 エージェントが sameAs を使うという資料は、肯定も否定も見つけられませんでした。見つけられなかったものを「効く」と書き続けません。
    • 注記を 1 件、正本へ寄せました。 組織名表記の項目に「海外の一次資料に対応するものは存在しない」と書いていましたが、正確ではありません。対応する記述は在ります（「サイト名に使っているものと同じ名称を使う」）。在りますが範囲が違う、が正しい書き方です。「資料が無い」と「資料はあるが範囲が違う」は別です。
    • 配点は変えていません。 調査では「日付の不在を不備とする資料が、4 つのどこにも無い」ところまで分かっていますが、明らかな過大宣言の修正と、配点の判断は別の版で扱います。 混ぜると、点が動いた理由を説明できなくなるためです。
60. 2026.08 第78版2026-08-17定期改訂採点表現結果が変わります

    判定できていない項目で、減点していました（チェックリスト v9）

    8

    • ★ 判定できていない項目で減点していました。 「組織名表記の一貫性」は、利用者が会社名を申告していないと判定できません。 検出器にも「評価対象外（満点でも 0 点でもなく判定不能）」と書いてありました。ところが実際には 0 点として扱われ、重み 3 のまま分母に残って減点していました。
    • 匿名の診断は会社名を受け取らないので、全員に毎回起きていました。 しかも改善インパクト順の上位に入るため、無料でご覧いただいている方にも見えていました。
    • 点は上がる方向にしか動きません。 判定できていなかった項目が分母から外れるだけです（会社名を申告して診断されている場合は、元から判定できているので変わりません）。実例として cybozu.co.jp は 47 → 49 になります。
    • ★ これは 2026.08.47 の漏れです。 あのとき「観測できなかった項目を満点にするのをやめる」として、エージェント対応の 3 項目にまったく同じ手当てをしました。そのときの説明にこう書いています — 「0 点にすると『満点を取りようがない項目』になり、根拠のないもので減点することになる」。同じ診断の中に、正しく処理されている項目と漏れている項目が並んでいました。
    • ★ 社内共有用の要約と改善計画が、判定できていないことを断定していました。 結果画面の 2 箇所は「判定できませんでした」と出るように直してありましたが、改善計画と社内共有用の要約は「サイト上の組織名表記に揺れがあります」と書いたままでした。 同じ項目が、同じページの中で違うことを言っていたことになります。社内共有用の要約はそのまま貼ってお使いいただくものなので、観測していないことの断定が外へ出ていきます。 4 箇所とも同じ判断を通すようにしました。
    • ★ 全項目の表が「この診断では対象外」を「暫定・配点なし」と書いていました。 配点されない理由は 4 つ（参考情報 / 暫定採用 / 配点 0 / このサイトでは対象が無い）ありますが、表は最初の 1 つしか見ていませんでした。そのため、採用済みの基準なのに「まだ暫定です」と読める状態でした。実例として、入力欄が 1 つも無いサイトの「フォーム入力欄のラベル」が ✗（赤）0/2 と出ていました。判定していないのに未達に見えます。「この診断では対象外」を足し、記号と素点は中立にしました。
    • ★ 3 度目を防ぐ検査を足しました。 採点は「分母から外す」印を見て、画面は「観測できていない」印を見ています。この 2 つがずれると、画面と点数が違うことを言います。 会社名の申告が無い場合など、判定できない入力を実際に全項目へ通して、両者が一致することを確かめるようにしました。元の欠陥を戻すと本当に検査が落ちることを確認してから入れています。
    • この版では、記事を持たないサイトの扱いには手をつけていません。 「著者情報」「公開日・更新日」は、記事のないコーポレートサイトでも減点として効きます。明らかな欠陥の修正と、配点の見直しを同じ版に混ぜると、点が動いた理由を説明できなくなるためです。適用外とみなす条件を整理したうえで、別の版として扱います。
61. 2026.08 第77版2026-08-16定期改訂採点根拠結果が変わります

    判断は正しかったが、そのとおりに測れていなかった（チェックリスト v8）

    14

    • ★ 同じサイトを同じ日に測っても点が変わります。ただし配点は 1 点も変えていません。 実効重みは v7 と同じ 79 のままです。変えたのは測り方（判定）のほうです。
    • この違いは、読む側にとって意味がまったく違います。 配点を変えたのなら SILVE の判断が変わったということですが、今回は SILVE の判断は前から正しく、そのとおりに測れていなかったということです。
    • どちらも、自分のサイトを測って初めて分かりました。 2026-08-16 に SILVE 自身を診断したところ、見つかった欠陥の半分は診断ツール自身のものでした。そのうち 2 件は直すと SILVE 自身の点が上がるため、実装側の判断だけで動かさず、版として切っています。
    • ★ 1. 内部リンクを本数で採点していました。 v7 までは「入口ページから辿れるリンク先が 20 件以上で 2 点・5 件以上で 1 点」としていましたが、この閾値を支える記述は一次資料のどこにもありませんでした。 資料を読み直すと、逆に「1 ページが持つべき理想的なリンク数というものはない」と明記されていました。
    • これは v7 で見出しの採点から「h1 はちょうど 1 つ」「h2 が 2 つ以上」を外したのとまったく同じ型で、Google は同じ言い回しを使っています（見出しのほうは「理想的な見出しの数というものもない」）。提供元が「理想的な数は無い」と言っているものを、こちらが数で採点していました。
    • 資料が実際に述べているのはマークアップの形です。 辿れる形として <a href="..."> を挙げ、辿れない形を具体例で列挙しています — routerLink、a 以外の要素の href、href の無い onclick、javascript: の href。そこで、形で判定するようにしました。 なお <a href="/x" onclick="..."> は同じ資料が辿れる例として挙げているので、onclick が付いているだけでは減点しません。
    • リンクの本数は観測として出し続けます。 判定に使わないだけで、見て意味のある数字ではあるためです。結果画面には「本数はこの項目の判定には使っていません」と明記しました。
    • ★ 2. 正しい書き方をしているサイトを減点していました。 構造化データを読む処理が、入れ子を決め打ちの 4 つの鍵でしか降りておらず、author の中を見ていませんでした。 そのため Article の中に入れ子で書かれた著者（Person）を検出できず、schema.org の標準的な書き方をしているサイトは著者の項目で 3 点中 1 点が上限になっていました。
    • 鍵を 1 つずつ足す形では直りません。 author を足しても reviewedBy が残り、それを足しても別の鍵が残ります。列挙をやめて、値が実体であるものは全部降りるようにしました。
    • この項目の根拠も配点も間違っていませんでした。 v7 で 6 → 3 へ下げた判断はそのままで、その判断どおりに測れていなかっただけなので、重みは動かしていません。
    • 同じ原因で、もう 1 項目が動きます。 publisher の中に入れ子で書かれた運営組織（Organization）も、これまで検出できていませんでした。これも「宣言されているのに見えていなかった」側なので、検出されるのが正しい形です。
    • ★ 公開済みの版を守る仕掛けを作り直しました。 2026.08.73 で「コード上の版が現在の値を読んでしまう」問題を塞ぎましたが、あのときの措置は採用状態しか凍結できませんでした。 今回は根拠の注記と資料の再読日を直す必要があったため、フィールド単位で凍結できる形に一般化しています（src/lib/checklist/frozen.ts）。v1〜v7 の内容は 1 文字も変わっていません。
    • ★ さらに、版ごとの実効重みを機械が見るようにしました（pnpm check:scoring）。2026.08.73 で v6 が 91 ではなく 86 で公開された不具合は、期待値をどこにも書いていなかったから気づけませんでした。 各版の実効重みを検査に書き、遡って変わったら落ちるようにしています。
    • ★ 注意（版をまたいだ比較）。 判定を変えた版なので、古い版を指定して測り直しても当時の判定は復元されません。 さらに今回は重みが同じで判定だけが変わったため、差は「基準の変化」ではなく「サイトの変化」の側に出ます。 つまりサイトを何も直していないのに「良くなった」ように見えます。 版をまたいだ再診断の結果を、直した成果として読まないでください。
62. 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 行の長さは変えていません）。
63. 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 個あります。壊れてはいないので落としません）。
64. 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 検査で確認するへ改めました。
65. 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 で配点を下げた根拠そのものです。 提供元が「最も効く」と言っているもの（独自で有用なコンテンツ）だけ、私たちは測れません。
66. 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）。
67. 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）。
68. 2026.08 第70版2026-08-13臨時改訂表現結果に影響なし

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

    6

    • スコアは変わりません。 読みやすさの修正です。
    • ★ 本文に出てくる「2026.08.xx」が何なのか、どこにも書いていませんでした。 これは訂正を行った判断基準の版の番号で、変更履歴のついた基準という約束の実体です。消さずに、記事の冒頭で 1 行説明するようにしました（22 本）。
    • ★ 公開前の推敲を、記事の本文に残していました。 23 本目に「以前はこう書いていましたが」という記述が 7 箇所ありましたが、その記事は今日まで公開していません。読者が見たことのない文章についての説明でした。 直接の記述へ書き換えました。公開前の直しは記事に書かず、証拠台帳が履歴を持ちます。
    • ★ 英文の引用に日本語が添えられていない箇所がありました。 調べたところ 117 箇所のうち 2 箇所で、前後に日本語の説明がありませんでした。原文は消しません（一次資料と照合できなくなるため）が、日本語の読みを添えました。
    • npm run check:quotes を追加しました。 日本語を含まない引用について、前後に実質的な日本語があるかを機械で見ます。「論文自身がこう書いています」のような導入だけの定型は、説明とみなしません。 機械にできるのはここまでで、訳の正しさは見ません。
    • どちらも読者の指摘で気づきました。 「ほとんど大丈夫」を機械で保証できる形にしていませんでした。
69. 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 / 確信度 中）、時系列を主張しない判断、採点ゼロ。いずれもレビューで妥当と判定されています。
70. 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 は一次資料を確認できていません。確認できていないことは、確認できていないまま残します。
71. 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・テンプレートリテラルの識別子・機能名の分断・論文の節見出し）も、触ってはいけない場所の実例として記録しています。
72. 2026.08 第66版2026-08-13臨時改訂根拠結果に影響なし

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

    4

    • スコアは変わりません。 公開前の下書きの修正です。
    • ★ レビューへ出す前に、最も強い証拠の原文を取り直しました。 掲載の条件はどこにあるかの 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.」 「参加したいなら申請が必要」が要旨から落ちていました。
    • 要旨で記録すると、原文より弱くなることがあります。 とくに最も強い証拠は逐語で持ちます。
73. 2026.08 第65版2026-08-13臨時改訂項目の追加・廃止結果に影響なし

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

    6

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

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

    8

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

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

    6

    • スコアは変わりません。 前の版で作った検査そのものの修正です。
    • ★ 作った直後に「変更あり」が 2 回出ましたが、どちらも資料の変更ではなく、こちらの欠陥でした。
    • ★ HTTP 200 でも本文が取れていないことがありました。 同じ URL への連続取得のうち 1 回が 0 字を返しました（応答は 200）。抽出に失敗しているだけなのにハッシュが変わるので「変更あり」になります。200 を「取得できた」と同義に扱わないようにし、抽出が空・極端に短いものは取得できなかったものとして報告し、基準も書き換えないようにしました。403 を「消失」と扱わないのと同じ規則です。成功したように見える失敗のほうが危ない。
    • ★ 基準にハッシュしか持たせていませんでした。 変化を検出したあと、「何が変わったのか」を調べる手立てがありませんでした。 実際に 2 回、原因を特定するために使い捨てのスクリプトを書く羽目になっています。正規化後の本文を手元（git 管理外）に残し、変更を報告するときに最初の相違箇所を出すようにしました。検出できても中身を出せない検査は、結局のところ読まれません。
    • --due の「30 日」に根拠が無いことを書きました。 運用の都合で置いた窓で、スコアの帯の 50 / 75 と同じ性質です。根拠の無い閾値は、無いと書きます。 環境変数で変えられるようにもしました。この値を変えても、台帳側の再検証期限は 1 日も動きません。
    • どちらの欠陥も、設計を眺めていても出てきませんでした。 基準を取り直して 2 回目を走らせ、出てきた「変更あり」を 1 件ずつ潰して初めて分かったものです。検出系を作ったら、必ず 2 回以上まわして誤検知を 0 にしてから運用に載せる、を規則にしました。
76. 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 に残しました。 同じ議論を繰り返さないためです。
77. 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 は「外部での言及、他サイトとの比較、その時点のプラットフォームの挙動」、スコアの考え方は「外部での言及、被リンク、ブランド認知」、運営者情報は「外部での言及、ブランド認知」。被リンクとブランド認知が AI 検索の露出へ影響することを、私たちは一次資料で確認していません。 3 つとも、確認できている要因（外部サイトでの記述・プラットフォームごとの違い・実行ごとのばらつき）と、公開ページからは確認できない条件（Search Console の生成 AI 掲載設定）へ揃えました。
    • 測定モデルの図で、Readiness が「実装済み」に見えていました。 公開ページの取得だけでは確認できない Readiness の条件があります。 「公開ページから観測できる範囲を実装済み」に改め、図の下にも「1 層目も全部ではありません」と書きました。
    • 診断ページの説明文を直しました。 検索結果に出る説明が「AI 検索での発見可能性を診断します」でした。見出しは「AI 検索準備度の診断」なのに、説明文だけが可視性の言い方になっていました。
    • ★ 「毎月 15 日に更新」と、訂正を出し続けることが噛み合っていませんでした。 SILVE の原則は「自分たちの誤りも、新しい版での訂正として履歴に残す」ですが、誤りが見つかったときに次の 15 日まで待つのは、その原則と正面から矛盾します。 実際この 8 月には訂正版を何度も出しています。「毎月 15 日の定例の更新」と「随時の訂正」を分けて書くようにしました。
    • フッターの「直近の海外論調を反映した現時点の視点」を「一次資料にあたって作った基準による、現時点の視点」に改めました。 トップの見出しは「一次資料にあたって作った基準」と書いており、同じことを別の言い方で説明していました。
    • 古くなる数字を 2 つ、導出に変えました。 記事一覧の「22 本」と、判断基準の読む順番にあった版番号の例（「第29版」のまま止まっていました）。
78. 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 だけでなくコード上でも成立させます。
79. 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 を配分している状態は説明できない」でした。同じ理屈がこの項目にも当たります。 重みを動かすとすべての診断結果が変わるため、この版では言葉だけを直しています。
80. 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 本すべてのレビューを反映し終えました。
81. 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 を別のフィールドにしている設計はそのままに、層から水準を自動的に決めないという規則にしました。
82. 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 本（情報環境の記事）は同じ誤りをしていませんでした — 「引用プールに入ることと回答に出ることは別」と正しく書いています。誤りはこの記事だけでした。
83. 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 ドメイン分類を含む線形確率モデルで推定しています。それでも観測研究であり、公式仕様上そもそも参加の制御ではありません。
    • ★ この誤りはこの記事だけにありました。 クローラの記事と 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 の記事にも 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%」です。引用は取得の全体ではない。開示されたログも取得の全体ではない。
84. 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 つの誤りは、いずれも表だけを見て本文を読まなかったことが原因です。
85. 2026.08 第53版2026-08-13臨時改訂分類根拠表現結果に影響なし

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

    11

    • スコアは変わりません。 Visibility は未実装のままです。
    • ★ 同じ Visibility の分類が、2 本の記事で食い違っていました。 測定モデルの記事は 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）。これでエージェント対応の記事の 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 の結論に揃えました。 「引用が多くても候補に残らなければ成果につながりません」→「購入や選択を目的の指標にするなら、引用が多いだけでは足りません」。「引用に価値がない」とは書きません。
86. 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 の記事の「内部クエリは観測できない」と矛盾しません。
87. 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 システムは同義語や求めていることの一般的な意味を理解し、まったく同じ語を使っていないコンテンツとも結び付けられる」「ロングテールの語句が足りないと心配する必要はない」という説明です。掲載資格の話に聞こえる書き方を避けました。
88. 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% 改善した」という研究ではありません。 論文自身も理由をクエリ関連語の密度と語彙の重なりに帰しています。機械可読データの記事の「構造化データを直接的な順位要因として扱う根拠は確認できていない」と矛盾しません。
    • 簡略式であることを明示し、段階どおりの式を併記しました。 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%』の唯一正しい読み方です」を「この論文から直接支持される読み方です」に変えました。 解釈に「唯一」を付けません。
89. 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 の記事に追記しました。
90. 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 の仕様」と明示します。
91. 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 年時点の記述として扱い、現在の提供状況は未確認と明記します。
92. 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 側が決めます。
    • 見出し「識別子は名前より強い」を「識別子は、名前だけでは残る曖昧さを減らせる」に変えました。 重み付けのように読めるのを避け、この記事の原則（強くするのではなく曖昧でなくする）に揃えました。
93. 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 件ずつ潰すという手順と、記録には件数ではなく「どう探したか」を書くことを明記しました。探し方が弱ければ、件数は当てになりません。
94. 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 つだけを根拠にすると、そのページが改稿された瞬間に根拠を失います。 他者と帰属が食い違ったときも、勝ち負けを決めずに両方を確認して両方を持ちます。
95. 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 の原則と整合している」までです。
96. 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 のようなサイト単位の設定が加わります。
97. 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 のままでした。揃えています。
98. 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 系統です。
99. 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 全体の科学は確立していない」が、現在の一次資料から言える限界です。
100. 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 は本文に登場しません。
101. 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）。
102. 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 本を直したら、同じ書式の記事を掃く。
103. 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 実験も固定文脈であること、架空の統計・引用・出典を許容した実験であること。むしろ最後の点は、リポジトリではなく査読を経た版の付録に印刷されていたぶん、強い根拠になりました。
104. 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 の規則にも、「追加の技術要件が無い」は掲載条件の全体ではないという注記を入れています。
105. 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）。題名が変わるということは本文も変わり得ます。 検査側も、文字コードの判定・数値文字参照の復号・「取得できなかった」と「題名が違う」の分離を直しました。
106. 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 のクローラ文書）。実ページの題名を検証済みのフレームワーク台帳側へ揃えています。検査の対象から外れている場所に、まさにその種類のずれが溜まります。
107. 2026.08 第31版2026-08-12臨時改訂採点項目の追加・廃止結果に影響なし

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

     6

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

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

     5

     • 同じサイトでもスコアが動く可能性があります。 ページ比率で段階を分けている項目（JavaScript 依存・canonical・構造化データの有無）は、見るページ数が変わると取り得る値が変わります。とくに「全ページで満たしていること」を求める段階は、分母が増えるぶん達成が難しくなります。
     • 5 という数字に外部の根拠はありませんでした。 一般的なサイトのグローバルメニューが 5〜8 項目なので、それを少し上回る 10 に置き直しています。10 も根拠のある数字ではなく、待ち時間との兼ね合いで決めた値です。
     • ★ これまで、クロールの設定は版として記録していませんでした。 項目・重み・採用状態は版に固定していましたが、ページ数のような採点方法そのものは版の外にあり、変えてもスコアの変動として説明されない状態でした。今回から採点方法の変更も版として記録します。
     • 前回と見たページ数が違う診断を比較したときは、結果画面で「解析したページ数が違います」と表示します。その差はサイトの変化とは限らないためです。
     • 無料の範囲は 1 ページのままです（従来、登録済みの無料利用者には表示と異なり 5 ページ取得していた不具合も併せて修正しました）。
109. 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 が正しい記述です。
110. 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 に落ち、型付きの分類に届かない」としています。
111. 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 倍でした。そしてこれらの研究に日本市場は含まれていません。 実測します。
     • 事実と意見を分けます。 否定的なレビューがあること自体は不整合ではありません。「高いと思う」は意見で、「すでに販売終了している」が事実と違えば不整合です。 そして偽のレビュー・なりすまし・関係を明かさない推薦を推奨も採点もしません。 情報環境を良くする行為ではなく、汚染する行為だからです。
112. 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 が固定規則の下で生成した操作的な測定値であることです。
113. 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 が単一の日付要素に依存せず複数要素から公開・大幅更新の時期を推定していること、および日付はページの公開・更新を表すべきでページが説明している出来事の日付ではないことです。
114. 2026.08 第24版2026-08-11臨時改訂根拠結果に影響なし

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

     4

     • スコアは変わりません。 機械検査の条件を厳しくしただけです。
     • 第23版で入れた「査読資料があれば免除」を締めました。 免除に使える査読資料を、その主張を直接述べているもの（directness: direct_claim）に限定しました。査読が検査したのはその論文が述べたことであって、隣接する主張ではないからです。
     • 免除の判定範囲が claim 単位であることを明文化しました。 判定に使うのはその claim の sourceIds が指す資料だけで、台帳全体ではありません。「台帳のどこかに査読論文が 1 本あるので通る」という抜け道は作りません。
     • 設計上の負債を 1 つ記録しました。 第23版で追加した first_party_specification は、他の値（固定文脈 / 取得から再実行 / 商用の観測）がどうやって取得を観測したかを表すのに対し、観測ではなく当事者が仕様を宣言したという性質を表しており、意味論が混ざっています。現状は機械検査で当事者の資料に限定しており実用上は機能するため作り直していませんが、台帳が増える前に 2 軸へ分離します。
115. 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 は取得側の問題であり、記述が存在しない証拠ではありません。
116. 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 日間です。
117. 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 クエリで十分」は、論文が明示的に否定した読み方です。
     • 信頼区間を付けても不確かさを尽くしたことにはなりません。 標本の中で分布が動いている場合、ブートストラップを含む定常性前提の区間は真の不確かさを過小評価し得ます。 原因はクエリの投入順序という測定設計側にあります。
     • 認知（ブランド名を含むプロンプト）と発見（含まないプロンプト）を平均しません。また、クエリ・情報源・日付はクラスタ化された単位であり、すべての生成を独立標本として扱うと不確かさを過小評価します。
118. 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 専用の文体を探す前に、そのページがその問いに答えているかを確認します。
119. 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 版のみ記載しています。
120. 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 のような安定した標準より変化が速いためです。
121. 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 で記録します。
122. 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 件すべてが一致しています。
123. 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 を送るよう修正し、「取得できなかった」は資料の性質ではなくこちらの試行についての事実である、という規則を追加しました。
124. 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 へ上げません。
125. 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 は未取得、旧ドメインからのリダイレクトは未設定、外部プロフィールの統一も未着手です。自分たちができていないことを、できているかのように書きません。
126. 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%）。
127. 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 での露出への寄与（根拠なし）」を分けて考えます。
     • プラットフォームフィードへの対応は採点していません。 公開サイトを見るだけでは連携の有無を判定できない場合があるためです。判定できないものは推測せず「観測できない」と表示します。また、メディアサイトに商品フィードが無いことのように、その事業に不要なデータ経路の不在を減点しません。
128. 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 ページのみ取得、同一ホストへの間隔）は変更していません。
     • 過去に公開した版の判断内容は書き換えていません。 変更したのは名称の表記だけで、各版の項目・重み・根拠・確信度はそのままです。
129. 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 標準が同じ期限になってしまいます。
130. 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）を分けるようにしました。ブラウザでは読めても機械的な取得を拒否する一次資料があり、これを消失と同じ扱いにすると誤警報が続いて検査自体が信用されなくなるためです。
131. 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 は現在名前解決できません。第三者のクローラ情報サイトは一次資料ではないため分類の根拠にしません。未検証であることを表示し続けます。
132. 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 は「引用に価値があるとも無いとも、現時点では一律には言えない」までに表現を留めます。
133. 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 倍）に誤りはありません。
134. 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 通りの分解を提示していることを注記しました。
135. 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 で後付けされた操作要素が見えず、検出数が下限値にとどまることです。
     • 操作要素・入力欄・画像が検出されなかった場合は減点しません。存在しないものの不備を減点する扱いを避けるためです。
136. 2026.08 第2版2026-08-11臨時改訂

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

     5

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

     初回リリース

     1

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