本文へ移動
SILVEシルヴェ
ログイン無料で診断

履歴資料

判断基準の変更履歴

公開した版は書き換えません。訂正は新しい版として残します。ある診断がどの基準で測られたかを、後から必ず確認できるようにするためです。

全 245 版 ・ 現在は 2026.08 第342版

履歴資料です。現在の仕様ではありません。 ここに並ぶのは、公開した時点の判断をそのまま保存したものです。訂正した記述も、廃止した数え方の説明も、当時のまま残しています。現在の基準は 診断基準 にあります。

  1. 2026.08 第342版2026-09-01定期改訂表現結果に影響なし

    最新情報のレーンを作りました

    • ★★★ 「今週のまとめ」という区分の名前をやめ、「最新情報」にしました。 周期を名前にしていました。 何も起きていない週に「今週のまとめ」を書く理由が生まれます。 このレーンは、監視対象から関係する一次情報が出たときだけ、原則 24〜48 時間以内に出します。本数の目標は置きません。
    • ★★ 他の 3 つの区分（サイトを直す / 測り方を知る / 外部要因を知る）は変えていません。 2026.08.247 に、話題ではなく読者の目的で割り直したものです。「基礎」「実務」のような抽象語へ戻すと、あのとき捨てた形に戻ります。
    • ★★★ 3 点セットを、文章の心がけではなく見出しとして必須にしました ——何が変わったか / 何は変わっていないか / まだ分からないこと。 順序も見ます。 検査は pnpm check:news。
    • このレーンだけ、説明文とタグをコード側へ登録しません。 記事 1 本ごとにコードを触ってデプロイするのでは、24〜48 時間に間に合わないためです。 記事の先頭の箇条書きから読み、書き忘れは検査が落とします。
    • ★★ 最新情報には Evidence Ledger を持たせません。 速さのためではありません。 台帳は診断項目と評価基準を支えるためにあり、最新情報の記事は評価基準を支えないためです。支えることになったなら、それは別に版を出す話です。 正本は NEWS_POSTS.md N3a。
    • 解説記事と方法論の記事は、これまでどおりの刊行に乗ります。最新情報だけがその外にあります。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  2. 2026.08 第341版2026-09-01定期改訂表現結果に影響なし

    この製品が担当する工程を、画面の上のほうに書きました

    • ★★★ 「未実装」という書き方をやめました。 可視性・実行・成果を「未実装」と書いていましたが、これは「いずれ作る」と読めます。 作れていないから測っていないのではなく、この製品が担当していないためです。 「現在の診断範囲外」に変え、「これは将来の実装予定を示すものではありません」と添えました。 ★ 「永久に実装しない」とも書いていません。 現在形で書き、予定については何も言いません。
    • ★★★ 「可視性は測りません」が、料金の『含まれないもの』の中にしかありませんでした。 トップページの本文 12,728 字のうち 1 か所で、しかも下のほうです。 これは欠けている機能ではなく、この製品が何であるかの説明なので、上のほうに「測るもの / 測らないもの」として置きました。
    • ★★ 「その前に」を、効果の話にしないための言い方を決めました。 「準備状態を先にやるほうが有利」は、順序に意味があるという主張で、根拠が要ります。 根拠が要らない言い方はこちらです ——塞がれている状態のまま「出ているか」を測っても、出ていないのか、取りに来られていないのかを分けられません。 これは論理で言えるので、証拠が要りません（EVIDENCE_POLICY.md の書き分け）。
    • ★★ ヒーローの見出しを変えました。 「AI にどう見られていますか」は可視性（観測）の言い方で、同じ画面の規律に自分で反していました。 「AI 検索の準備が整っていますか」にしました。2026.08.139 に一度戻した箇所ですが、今回は担当する工程を決めた上での変更です。
    • ★★★ 診断結果に「次にできること」を置きました。 結果を出して終わりでした。 制限が見つかった場合は「直す → 同じ基準で測り直す」、見つからなかった場合は「取得できた ○ ページの範囲で、制限は確認されませんでした」と書きます。★ 「問題ありません」とは書きません。 判定しているのは到達・利用の条件だけで、提供元の推奨は判定していません。 範囲外については何も言っていません。
    • 記事一覧の絞り込みから「AI にどう見えているかを測りたい」を外しました。 記事の絞り込みですが、この製品が測れると読める言い方でした。「AI 検索に出ない理由を知りたい」にしています。
    • よくある質問に 2 問足しました ——「AI の可視性を測るツールとは何が違いますか」「制限が見つからなかったら、次は何を確認すればいいですか」。★ 製品名は書いていません。 他社製品の機能を書けば、それは他社についての主張になり、一次資料と確認日が要ります。相手の仕様は変わりますが、こちらの記述は残ります。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  3. 2026.08 第339版2026-09-01定期改訂表現結果に影響なし

    立場はあったのに、その問いの形で書いていませんでした

    • ★★ 実地の 40 問で「材料に届かない」と分かった 15 件を埋めました。 どれも同じ型でした ——立場はあるのに、利用者が打つ形で書いていない。
    • 足した答え —— 同じ名前の別会社として説明される（実体の取り違え。SILVE は測っていない）／構造化データをたくさん入れれば（量が効くという前提が違う）／再診断の差は残るか（残る。ただし同じ版どうしだけ）／所有者の確認（していない。だから公開ページだけ）／読まれやすさの違いをどこまで分かっているか（条件が欠けているかまで。書き方は分からない）／Google と OpenAI が食い違ったら（どちらかを基準にせず、並べて書く）／「使っていいよ」と伝える方法（無い。あるのは拒否を伝える手段）／AI が知っているか分かるか（可視性は測っていない）／WAF で SILVE だけ弾かれたら（判定しない。SILVE の観測でしかない）。
    • ★ 既存の問いには、実際に打たれる言い方を足しました ——「競合ばかり出てきて名前すら出ません」「全部 OK なら出るということですか」「今日と明日で同じ結果になりますか」「アクセス解析に残りますか」。答えは同じで、届き方だけが変わります。
    • ★★★ 検査が見る数を、本番に合わせました。 検査は上位 3 件で見ていましたが、本番は 6 件を模型へ渡しています。 3 位までに入らなくても、模型は読んでいます。 見る数がずれていました。
    • 検査は 37 問から 45 問になりました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  4. 2026.08 第338版2026-09-01定期改訂表現結果に影響なし

    語の近い別の話を、答えとして返していました

    • ★★★ 40 問を実地で投げた結果から、取り違えを 2 件直しました。 どちらも「答えられなかった」ではなく「答えたが違っていた」 —— 見つけにくいほうです。
    • ★★★ 「ログインが必要なページも診断できる？」に、こう返っていました ——「資格情報を受け取らず、サインインや決済の完了は行わないため、その時点でタスクが停止します」。これはエージェントの記事の文で、SILVE の診断の話ではありません。 ★ 語は近いが、主語が違います。 材料が無いと、近い語の別の話が答えになります。 診断は公開ページだけを見る、と書きました。
    • ★★ 「AI に出やすくする SEO みたいなものはあるのか」に、LLMO の提唱者側の定義をそのまま返していました。 SILVE の立場ではありません。 Google が「新しい実装は要らない」と明記していること、前提としての条件は残ること、SILVE は施策の効果を評価しないことを書きました。
    • ★ 検査が誤って止めた箇所も直しました。 「どの施策がどれだけ効くかを評価しません」と書いた行に 構造化データ が別の文で出てくるだけで、「0 項目のカテゴリを検出すると書いている」と判定していました。 言っているのは逆です。 否定で終わる行は見ないようにしました。
    • 検査は 35 問から 37 問になりました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  5. 2026.08 第337版2026-09-01定期改訂表現結果に影響なし

    話し言葉を、知らない語と数えていました

    • ★★★ 試験用の問いを 40 作って測ったら、13 問が材料に届いていませんでした。 材料が無いのではありません。 答えを止めていたのは、門のほうでした。
    • ★★ 1 つ目の門 ——「欠けた 2-gram が連なったら、その語自体を知らない」。「競合の会社ばっかり紹介されて…」は網羅 84% なのに断っていました。紹介 は資料にあり、欠けていたのは送り仮名だけです。配点で外している 2 つ（かなだけの 2-gram と、3 文字以上のかなの塊との境目）を、この判定でも外しました。
    • ★★ 2 つ目の門 ——「資料に無い語が 1 つでもあれば断る」。「無料版と有料版って…」は 有料版 内容自体 が「無い語」に挙がっていました。有料 も 内容 も資料にあります。 語が無いのではなく、切り方がずれていました。 かけらが半分以上あるなら、知らない語ではないとしました。
    • ★★★ ただし漢字の語にだけ当てます。 カタカナはかけらが他の語と重なります ——「ラーメン」の「ラー」は「クローラー」に、「メン」は「ドキュメント」にあります。数で判定すると、知らないカタカナ語がすべて通ってしまいます。 一度そうなり、直しました。
    • 確かめたこと —— 40 問中、届かないものが 13 から 2 になりました（残るのは「3 か月後の流入予測」「競合 3 社の順位付け」で、どちらも断るべきものです）。ラーメン屋・天気・従業員数 は断ったままです。 committed な 35 問はすべて通ります。
    • ★★★ 緩めた結果、言い過ぎが増えていないことまで確かめました。 50 問の検めで、答えた数は 24 から 30 に増え、印が付いたのは 1 件だけでした（読んだら正しく、英文の資料を訳しているぶん作文の割合が上がっていただけです）。「答えられるようになった」だけでは、直したことになりません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  6. 2026.08 第336版2026-09-01定期改訂表現結果に影響なし

    「信用できるのですか」に、材料が 1 つもありませんでした

    • ★★★ 買う前にいちばん出る問いに、答える文がありませんでした。 「この診断結果は信用できるのですか」——立場はあります（決定論・版の固定・一次資料・限界の明示）が、この問いの形で答える文がどこにもありませんでした。 ここで詰まると、先がありません。
    • 答えたこと —— 判定は完全に決定論で、生成 AI は判定にも説明文にも使っていない。評価基準は版で固定し、公開済みの版は編集しない。項目の根拠は一次資料へのリンクとともに公開している。 ★ そのうえで、測っていないものをはっきり書きました —— 実際に出るか（可視性）、その先の成果、各社のクローラーが実際に何を取得したか。 自分のサイトも同じ道具で測って、トップに出しています。
    • ★★ 断り方も用意していませんでした。 「制作やコンサルティング、広告運用は頼めますか」に「見つかりませんでした」と返っていました。やっていないのか、答えられないのかが分かりません。 行っていない、と書きました。 ★ 制作会社や代理店の方が、担当されているサイトの診断に使うことは想定しているとも添えています。
    • ★ あと 2 つ埋めました。 「AI 検索からの流入はどう見分けるのか」（測っていないし、見分け方も提供していない）と「毎日更新すれば有利か」（記事はありましたが、この言い方では引けていませんでした）。
    • ★★★ 試した 32 問のうち、材料に届かないものが 6 問から 0 問になりました。 ただし「届く」は「よく答えられる」ではありません。 答えの質は、実際に聞いて確かめます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  7. 2026.08 第335版2026-09-01定期改訂表現結果に影響なし

    いちばん知りたい問いに、立場を返していませんでした

    • ★★★ 利用者の指摘 ——「この 3 つは『答えになるものが見つかりませんでした』しか返らないが、ユーザーとしては最も気になる部分だ。見つからなかったというより、シルヴェとしてのスタンスを回答するほうが自然ではないか」。そのとおりでした。 「AI 検索で自社名が出てこない」「SEO の流入が減った」「記事を増やしているのに成果が出ない」——どれも立場はあるのに、書いていませんでした。
    • ★★ これは施策の助言ではありません。 何を測り、何を測らないかと、どの順に切り分けるかを書いています。効果は約束していません。
    • 答えの骨 ——「出てこない」は症状であって原因ではない（切り分けの順を示す）／SILVE は流入を測っていない（準備状態・可視性・成果は別のもの。時期が重なっても原因とは言えない）／SILVE は成果を測っていない（記事を増やすことは準備状態のごく一部にしか効かない。数える対象が増えるだけ）。
    • ★★★ 調べたら、原因の半分は引き方でした。 「AI 検索に出てこない」なら切り分けの記事が 1 位に出るのに、「自社名」が入ると 17 位まで落ちていました。「自社名」という語が、情報環境や実体の記事を強く引くためです。 記事の側にもその語を入れました。
    • ★ 検査は 28 問から 31 問になりました。 3 つとも、答えられることを毎回見張ります。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  8. 2026.08 第334版2026-09-01定期改訂表現結果に影響なし

    見ている発信元を 13 から 23 へ増やしました

    • ★★★ 利用者の指摘で、Moz が入っていないことに気づきました。 調べ直したところ、ほかにも抜けが 9 件ありました。 一覧を作った日に見落としていたものです。
    • 足したもの（研究の当事者） —— Common Crawl（診断の宛先である CCBot を運用している側）、Ai2、Apple Machine Learning Research、Microsoft Research（Bing の 2 本とは別系統。あちらは運用の告知、こちらは情報検索そのものの研究）、Amazon Science。
    • 足したもの（媒体・実務家） —— THE DECODER、InfoQ、Moz、Glenn Gabe（引用と自分の観測を分けて書く）、Simon Willison（提供元が出したものを原典つきで即座に追う）、Growth Memo。
    • ★★ 段は 3 つのままにしました。 研究機関はその研究の当事者なので 提供元 に入れています。 より正確には 4 つ目の段（研究）が要りますが、段はデータベースの列挙なので、足すには移行が要ります。 必要になったら分けます。 ★ 各行に「引くのは論文のほう」と書きました —— 記事は論文が出たことを知る窓であって、根拠そのものではありません。
    • ★★★ 測ったが入れなかったものも、理由ごと残しました（DeepMind・Ars Technica・IEEE Spectrum・MIT Technology Review・Brodie Clark・Sebastian Raschka・Anthropic・Perplexity）。もう一度調べ直さなくてよいようにするためです。 ★ Anthropic と Perplexity は、一次資料なのにフィードで取れません。 「取れない」には忘れてよいものと、忘れてはいけないものがあります。
    • ★ すべて SilveBot の UA で実測してから入れています（応答・件数・最新の日付）。推測で足さない、という既存の規則どおりです。
    • ★ 版の番号を 2026.09.1 にしかけて、検査に止められました。 並び順は 3 つ目の数だけで決まるので、2026.09.1 は 2026.08.333 より古い版として扱われます。真ん中の数は月ではなく、通し番号の系列を表す印でした。続きの番号にしています。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  9. 2026.08 第333版2026-08-31定期改訂表現結果に影響なし

    紙の本が出たので、「紙の本はありません」を消しました

    • ★★★ 紙の本（ペーパーバック）が出ました。 前の版で「Kindle 版のみです。紙の本はありません」と書いていたので、そのままにすると嘘になります。 買える版を 2 つ並べる形に変えました。
    • Kindle 版 1,650 円（税込）・Kindle Unlimited の読み放題対象 ／ 紙の本 2,750 円（税込）・ペーパーバック・ISBN 979-8170916702。416 ページ。
    • ★★ 値と「いつ時点か」は、版が増えても対のままです。 Amazon の価格は変わるので、書いたまま放置するといつか嘘になります。 時点を 1 か所にまとめて出しています。
    • ★ アソシエイトの識別子は、紙のほうにも付けていません（前の版の判断のままです）。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  10. 2026.08 第332版2026-08-31定期改訂表現結果に影響なし

    重なる位置に置いていたから、重なっていました

    • ★★ 狭い画面でヒーローの絵を消していた理由は「見出しとフォームに重なるから」でした。 ★ 重なる位置に置いていたから重なるのであって、絵そのものの問題ではありませんでした。 右上の角へ寄せ、半分を面の外へ出します —— 見出しは左から始まるので、右上には余白があります。
    • ★★ 面から出た分は切ります。 切らないと、はみ出した幅がそのまま横スクロールになります（以前、実測 96px の原因がこれでした）。
    • ★ 濃さは半分にしました。 広い画面では見出しと絵が離れていますが、狭い画面では字のすぐ横に来ます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  11. 2026.08 第331版2026-08-31定期改訂表現結果に影響なし

    狭い画面だけ、素の紙になっていました

    • ★★ 利用者の指摘 ——「スマホだとヒーローの画像やロゴやシルヴェの画像が表示されていないが、あえてか」。あえてでした。 ただし、2 つを同じ判断で消していたのが誤りでした。
    • ★ ヒーローの絵は、消したままにします。 入力欄と結果の見本に重なる位置にあり、「読めなくなるなら無いほうがよい」がそのまま当てはまります。
    • ★★ 面の図案は、事情が違いました。 文だけの面に、ごく薄く敷いているものです。消すと、狭い画面だけが素の紙になります。 小さくして、さらに薄くして出すようにしました（眼は 9% → 5.5%、ロゴは 3.5% → 2.5%）。「言われるまで気づかない」濃さの上限は、そのままです。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  12. 2026.08 第330版2026-08-31定期改訂表現結果に影響なし

    説明を足したら、購入ボタンが画面の外へ出ました

    • ★★★ 利用者の指摘 ——「長すぎる。購入ボタンがスクロールしないと表示されないのは致命的だ」。そのとおりでした。 前の版で説明を足した位置が、ボタンの上でした。 買える場所を先に出し、詳しい説明はその下に置きます。
    • ★★ 説明も短くしました（5 段落 → 3 段落）。足したばかりのものを削るのは、足す位置を間違えたからです。 中身は残し、重なっていた部分をまとめました。
    • ★ ページ数を価格の行へ移しました。 買うかどうかの判断に使う情報なので、説明の末尾ではなく、価格と読み放題の隣が正しい場所です。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  13. 2026.08 第329版2026-08-31定期改訂表現結果に影響なし

    本の説明が 1 文しかありませんでした

    • ★★ 利用者の指摘 ——「この解説が弱い」。そのとおりでした。 あった 1 文は、一覧のカードに収めるための文で、書籍のページで「何が書いてある本か」を伝える文ではありませんでした。 販売ページの紹介文を要約して、書籍のページに置きました。
    • 入れたもの —— 7 段階と 4 領域という座標系、扱う範囲（用語の整理から施策効果の検証まで）、証拠の扱い（種類を分け、支える範囲を超えて結論を広げない）、避ける短絡の例、想定する読み手、416 ページ。★ 売り文句は足していません。
    • ★ 短い 1 文はそのまま残しました。 一覧のカードとメールで使っており、そこに長い文を入れると別のものが壊れます。
    • ★★ 検査が 3 つ止めました。 「416 ページ」が診断の取得ページ数と読まれかけたので、名前を付けて別の単位だと分かる形にしました。全角イコールが 2 つあったので、先日そろえた記号の規則に合わせました。持っていない字が 1 字（厚）あったので、フォントを作り直しました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  14. 2026.08 第328版2026-08-31定期改訂表現結果に影響なし

    帯の副題が、文の外に落ちていました

    • ★★ 利用者の指摘 ——「帯に「新しいSEOで「見つかる」企業」と最後に書かれているが、なぜこの位置に。不自然じゃないか」。そのとおりでした。 「…を発売しました。 新しいSEOで「見つかる」企業」と並び、文が終わったあとに、かかり先の無い句が残っていました。
    • ★ 副題は題の一部なので、題の中に入れました ——「公式書籍『AI検索の設計術 — 新しいSEOで「見つかる」企業』を発売しました」。狭い画面では副題だけが落ちますが、『』の中で落ちるので文は壊れません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  15. 2026.08 第327版2026-08-31定期改訂表現結果に影響なし

    価格と読み放題を、書籍のページに出しました

    • ★★★ 利用者の指摘 ——「リンクを挿入しているのに、ページを見ていないのか」。見ていませんでした。 販売ページを取れば分かることを、尋ねようとしていました。 取って確かめました。
    • Kindle 版 1,650 円（税込）・Kindle Unlimited の読み放題対象であることを、書籍のページに出しました。★★ 値と「いつ時点か」は必ず対にしています。 Kindle の価格は変わるので、書いたまま放置するといつか嘘になります。 これは本文が「有料プランの価格は本に書いていない。変わり得るものだから」と書いているのと、同じ判断です。
    • ★★ 帯からは日付を外しました。 奥付の初版発行日（9 月 1 日）と、配信が始まった日（8 月 31 日）が違います。 どちらも本当ですが、帯に 1 つだけ書くと、もう片方と食い違って見えます。 日付は書籍のページに置き、帯は「出た」ことだけを言います。
    • ★ 読み放題であることは、価格より決め手になる読者がいます。 同じ時点の値として並べています。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  16. 2026.08 第326版2026-08-31定期改訂表現結果に影響なし

    トップに、発売の帯を出しました

    • トップの一番上に、書籍のページへの細い帯を置きました。 表紙・発売日・題・副題を並べ、押すと書籍のページへ行きます。
    • ★★★ 消える日を先に決めてあります。 「発売開始」は、いつか嘘になります。 半年後に出ていたら、知らせではなく消し忘れです。 10 月 1 日に自動で消えます —— 誰も覚えていなくてよいようにしました。 ★ temporal-relevance で「時点を書け」と自分が言っていることの、実装版です。 延ばしたければ日付を変えます。
    • ★ 細い帯にしました。 この面の主役は診断の入力欄であって、本ではありません。 狭い画面では副題を落とします。
    • ★ 判定は画面の外に置きました。 画面の組み立て中に時刻を読むと止められる（前の版で踏んだところです）。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  17. 2026.08 第325版2026-08-31定期改訂表現結果に影響なし

    本のページに、本の姿がありませんでした

    • ★★ 表紙を出しました。 これまでは題と目次だけで、本のページに本の姿が無い状態でした。「読むもの」として不親切です。
    • ★ 広い画面では横に、狭い画面では上に置きます。 狭い画面で先に表紙が来るのは正しい —— 買うかどうかは、まず見た目で決まります。 表紙も購入先へのリンクにしました。
    • ★ 先に読み込む指定は付けていません。 このページで最初に読ませたいのは題であって、表紙ではありません（トップの絵とは扱いが違います）。表示する大きさに合わせて 720px 幅に縮め、70 KB にしています —— 表示より大きい画像を配らない、という自分の項目のとおりに。
    • ★ ボタンの文言を短くしました ——「Amazon Kindle で購入する」＋「電子書籍のみです」だと、同じことが近い位置で二度出ていました。 「Amazon で購入する」＋「Kindle 版のみです」に分けました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  18. 2026.08 第324版2026-08-31定期改訂表現結果に影響なし

    書籍が発売されました

    • ★★★ 『AI検索の設計術』が 2026 年 9 月 1 日に初版発行されました（Kindle）。「刊行予定（発売日は未定です）」を「2026年9月1日 初版発行」に変えました。 買える場所へのリンクを、題のすぐ下に置いています。
    • ★★ 切り替えたのは 1 行だけです。 ヘッダーの「書籍」・トップ・記事一覧・読む順番・シルヴェ通信が、同時に切り替わりました。 ★ 切り替える場所を 1 つにしておいたのが、ここで効きました。
    • ★★★ アソシエイトの識別子は付けていません。 付けること自体は規約の範囲内ですが、付けるなら「Amazon のアソシエイトとして適格販売により収入を得ています」を画面に出す義務が生まれます。 自分の本なので印税は別に入ります。 中立を売っている製品で、追加の収益源をリンクに埋めて開示文を足すのは、得るものより失うものが大きいと判断しました。
    • ★ 正誤表の文言が変わりました ——「まだ刊行していないため、訂正はありません」から「現在、訂正はありません。誤りが見つかったときは、何をどう間違えたかをここに残します」へ。発売前から空の正誤表を置いていたので、文だけが入れ替わります。
    • ★★ お知らせの相手も変わりました。 発売前は「発売日を知らせます」でしたが、次に知らせるのは訂正です。
    • ★ 紙の本はありません、と書きました。 無いものを「準備中」と書きません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  19. 2026.08 第323版2026-08-31定期改訂表現結果に影響なし

    検査に落ちるものを押し込みました

    • ★★★ 前の版で、画面の組み立ての最中に時刻を読んでいました。 同じ入力から同じ出力にならないため、React の規則で止められます。予約済みかどうかの判定を、画面の外（記事の取り出し側）へ移しました。
    • ★★★ これは実装の誤りより、確かめ方の誤りです。 検査の出力の最後の 1 行しか見ずに「通った」と判断していました。 最後の 1 行は「13 件」としか言わず、そのうち 2 件が停止する誤りだったことを隠していました。 数だけ見て、内訳を見ていませんでした。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  20. 2026.08 第322版2026-08-31定期改訂表現結果に影響なし

    配信の時刻に、理由がありませんでした

    • ★★★ 利用者の指摘 ——「ニュースレターを翌日にした理由と朝 6 時にした理由は？ 記事公開と同曜日の同時刻でよいと思ってしまう」。★★★ 理由はありませんでした。 既にあった毎日のバッチに相乗りさせていただけです。06:00 JST は、フィードの収集のために選んだ時刻で、配信のために選んだ時刻ではありません。
    • ★★ 配信を独立した処理に分け、水曜 10:30 に送ります。 記事は水曜 10:00 に公開されるので、出た直後に届きます。 読む側の文脈に合うのはこちらです。
    • ★ 30 分ずらす理由も書いておきます。 公開は時刻そのもの、配信は時刻に走る処理です。同時刻にすると、時計の僅かなずれで「まだ公開されていない」と見なされえます。 30 分あれば、その心配が消えます。
    • 送る中身が無い日は送りません。 前回の配信から後に出た記事も、基準の更新も無ければ、何もしません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  21. 2026.08 第321版2026-08-31定期改訂表現結果に影響なし

    公開する日時を、先に決められるようにしました

    • ★★★ 読む側は、もともと未来の日時に対応していました。 一覧も詳細もフィードもサイトマップも「尋ねる」の材料も、「公開日時が今より前」で絞っています。 書く側だけが「いま」しか入れられませんでした。 管理画面から日時を決められるようにしました。
    • ★★ 時刻が来た瞬間に出ます。 作り直しも、待ち時間も要りません —— ページを毎回組み立てている利点が、ここで効きます。 ★ 速さのために止めなくてよかった、と言える場面が 1 つできました。
    • ★★ 予約は「公開」ではありません。 公開予定の記事を「公開中」と書きません。 管理画面の数え方も分けました（全 ◯ 件 / 下書き ◯ 件 / 公開予定 ◯ 件）。
    • ★ 入力も受け取りも日本時間です。 時間帯を書かない日時を作らない、という既存の規律に合わせています。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  22. 2026.08 第320版2026-08-30定期改訂表現結果に影響なし

    持っていない字が入ったら、止まるようにしました

    • ★★ フォントを部分集合にしたので、持っているのは「このサイトの文章に出てくる字」だけです。記事を書き足したときに作り直しを忘れると、その字だけ端末の書体で出ます。 ★ 壊れはしません。読めます。 しかし、そこだけ書体が変わります。 気づくのは利用者になるので、機械に見張らせます（pnpm check:fonts）。
    • ★ さっそく 1 字見つかりました ——「游」。部分集合を作った後に、その説明文の中で「游明朝」と書いたためです。 作り直して入れました。
    • ★★ 見るのは「こちらが書いた文章」だけです。 実行時に外から入ってくる字（診断先の会社名など）は対象にできません。 そこは端末の書体に任せると決めています。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  23. 2026.08 第319版2026-08-30定期改訂表現結果に影響なし

    描画をブロックする CSS の 93% は、フォントの宣言でした

    • ★★★ CSS 180 KB のうち 167 KB（93%）が、和文フォントの宣言でした。 @font-face が 620 個あり、見た目の CSS は 13 KB しかありませんでした。 和文は文字範囲ごとに分割されるので、宣言だけでそうなります。
    • ★★ 明朝をやめる案は採りませんでした。 見出しと引用の明朝は、この製品の顔です。 代わりに、必要な字だけを持つ部分集合を自分で作りました。 見た目は変えていません。
    • ★★★ 持つのは 2 つだけです ——「英数・かな・記号 530 字」と「このサイトの文章に出てくる漢字 1,227 字」。それ以外の漢字は、端末の書体に任せます。 持つと 4.4MB 増え、その 4.4MB が要るのは診断先のサイト名に珍しい字が出たときだけです。日本語の端末にはヒラギノや游が入っているので、そこは読めます。 1 文字のために 1MB を落とさせません。
    • 結果 —— 描画をブロックする CSS は 3 本 180 KB から 1 本 17.6 KB になりました（gzip）。宣言は 620 個から 10 個です。
    • ★ 作り直せるようにしてあります（python3 scripts/build-fonts.py）。文章に新しい漢字が入ったら作り直します。 元は Fontsource が配っている Noto Sans JP / Noto Serif JP で、SIL Open Font License 1.1 は部分集合の作成と再配布を許しています。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  24. 2026.08 第318版2026-08-30定期改訂表現結果に影響なし

    ずっと再描画が走っていました

    • ★★ 「無料で診断する」ボタンの脈動が、影を動かしていました。 影は合成できないので、4 秒ごとに無限に走るこの 1 つだけで、画面を見ているあいだずっと再描画が続いていました。 影を別の板へ移し、透明度だけを動かします。 見た目は変えていません。
    • ★★★ もう 1 つ直すと言ったものは、直せませんでした。 「旧いブラウザ向けの変換 14 KB」は、枠組み自身が必ず送っているファイルでした。対応ブラウザの設定では消えません。 実際に設定を入れて測ったところ、出力は 1.8 KB 大きくなりました。 設定を戻し、何も入れていません。 ★ 効かない設定を「効く」と言って残さない。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  25. 2026.08 第317版2026-08-30定期改訂表現結果に影響なし

    記号の使い分けを、書籍とそろえました

    • ★★★ 書籍『AI 検索の設計術』で、記号の使い分けを 1 つに決めました。 同じ規則をサイトへ持ってきています —— 同じ書き手が、同じ主題を、別の記号で書いているほうがおかしいからです。
    • そろえたもの —— 概念の並列は半角スラッシュ（前後に空白）、等式は半角イコール、日本語の範囲は波ダッシュ、区切りと挿入句は em ダッシュ。全角スラッシュ 52 件と全角イコール 18 件を、記事から直しました。 画面の文でも 6 か所直しています。
    • ★ 単位の「あたり」は全角スラッシュのままです（100 回／月）。これは並列ではありません。 書籍には出てこない用法なので、こちらで決めました。
    • ★★ 見ない場所を 2 つ決めました。 公開済みの変更履歴と、凍結した評価基準の版（版は編集しません）。注釈（表記ではなく、書き手どうしの覚え書きです）。
    • ★★★ 太字の規則は、書籍と同じにしませんでした。 書籍では「段落全体を太字にしない」と決めましたが、サイトの記事ではそれがこの製品の書き方そのものです。★ 書籍は通しで読むもの、記事は探して読むもので、探して読む文章では拾い読みできることのほうが大事になります。同じ規則を機械的には当てません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  26. 2026.08 第316版2026-08-30定期改訂表現結果に影響なし

    そろえたら、今度は右列の文字が切れました

    • ★★ 前の版で左右の列をそろえたところ、右列が寄りすぎて「公開取得できたページ」が切れました。 右列を 1 文字ぶん左へ寄せ、そのぶん右列を広くしました。 区切り線も同じ境目に立つので、線ごと左へ動きます。
    • ★★★ 寸法を 1 か所で決めるようにしました。 2 か所に書いてあったので、片方だけ直る形になっていました —— 前の版のずれも、今回の切れも、原因はそこです。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  27. 2026.08 第315版2026-08-30定期改訂表現結果に影響なし

    見本の左右の列が、20px ずれていました

    • ★★ 利用者の指摘 ——「「公開取得できたページ」「Google AI 入力の許可」「名前のある操作要素」「ラベルのある入力欄」の % が揃っていない」。原因は、2 つの格子が別々の寸法だったことでした。上の段は間隔 12px、下の段は間隔 16px ＋ 右列に 16px の余白で、右列の始まる位置が 20px ずれていました。 同じ寸法にそろえました。
    • ★ ヒーローの 3 行は外しました。 前の版で足したばかりですが、利用者の判断です。
    • ★ 背景の絵の位置を、対称にしました。 ロゴは左下へはみ出しているのに、シルヴェの絵は縦の中央だったので、角どうしの釣り合いになっていませんでした。 右上へかけます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  28. 2026.08 第314版2026-08-30定期改訂表現結果に影響なし

    はみ出していたのではなく、拡大されていました

    • ★★★ 利用者の報告 ——「尋ねるの UI がスマホに最適化されておらず、右側が微妙にはみ出て、全体的に大きい」。★★★ はみ出していたのではありませんでした。 iOS の Safari は、字が 16px 未満の入力欄に焦点が当たると、ページごと拡大します。 拡大された結果、右側が画面の外へ出ていました。
    • ★★ 入力欄ごとに直すと、次に足した入力欄で再発します。 狭い画面では入力欄の字を 16px にする、と 1 か所で決めました（広い画面の見た目は変えていません）。尋ねる・診断・問い合わせ・記事の検索など、9 か所すべてに効きます。
    • ★★★ マイページの一覧で、真ん中が 4 文字幅に潰れていました。 「情報が縦になっているし、切れているしでよくわからない」——sil… としか出ていませんでした。 原因は、操作の列が幅を確保していて、折り返す余地が真ん中の文字にしか無かったことです。操作に 1 行まるごと使わせました。 折り返しが行単位で起きるので、ドメインと日付が横幅を全部使えます。
    • ★★ 並びの表が、延々と縦に伸びていました。 「ずらっと縦に並ぶ感じでスクロールがしづらい」。最初の 10 件だけ出し、残りは畳みます。 ★ 表の中を別の入れ物でスクロールさせません —— 入れ子のスクロールは、狭い画面ではもっと触りにくい。 畳むのは表示だけで、件数は「ほか ◯ 件」と出します。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  29. 2026.08 第313版2026-08-30定期改訂表現結果に影響なし

    トップで、同じことを 3 回言っていました

    • ★★★ 外部の評価で指摘されました ——「初見で必要なのは、何が分かるか / 無料でどこまでか / 出る保証はないこと の 3 点だけなのに、クローラー種別・エージェント・版管理・7 段階が同時に降ってくる」。測ったところ、本文は約 8,000 字でした。 日本語で読み通すのに 13 分ほどです。
    • ★★ ただし「長い」の中身は、情報量ではなく繰り返しでした ——「総合点は出しません」が 3 回、「1 ページ」が 7 回、「単位が違う／変換率」が各 2 回。同じことを 3 回言うのは、誠実さの反復であって情報ではありません。
    • ★★★ 入力欄の上に 3 行だけ置きました ——「公開されているページを取得して、機械に伝わっているかを数えます」「総合点は出しません。単位の違うものを 1 つの数にまとめないためです」「整っていても、AI 検索に出ることは保証しません」。★ 「出ることは保証しません」は、ここが初出になりました。
    • ★★ 削ったのは繰り返しであって、免責ではありません。 免責・測る範囲・一次資料への導線は、この製品の差別化そのものです。 短くしたのは「同じ主張の 2 回目以降」だけです。 本文は約 8,000 字から約 7,100 字になりました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  30. 2026.08 第312版2026-08-30定期改訂表現結果に影響なし

    見本の 1 つを、自分のサイトの実測にしました

    • ★★★ 外部の評価で指摘されました ——「自サイトを自ツールで診断した結果を常設した方が、エージェント項目を売るなら説得力がある」。そのとおりでした。 見本の 1 つを silve.jp の実測に差し替えました。
    • ★★ 測った日を書きます。 古くなることは、この製品では欠点になりません —— 「◯月◯日時点」と書けば済みます。 これは新しさと有効性の記事で、自分が言っていることです。 pnpm samples:self で作り直せます（データベースは要りません）。
    • ★★★ 自動更新にはしませんでした。 週次で作り直す形も作れますが、トップページの表示が週次の処理の成否に依存する形になります。 失敗した週に、トップから数字が消える経路を増やしたくありません。 運用の費用はどちらもほぼゼロで、違うのは壊れ方です。
    • ★★ 欠けている項目が無いときは、無いと書きます。 見本の 3 つは「1 つ欠けている状態」を出すために作ってありますが、実測にはその保証がありません。 色も付けません —— 区分の色は「どの区分が欠けたか」の凡例なので、欠けていないなら使いません。
    • ★ 満点という意味ではないことを添えました。 代表 URL の指定と代替テキストは、数える対象が 0 件だったため「対象なし」です。
    • ★ 他社は出しません。 他社の評価を自社の広告に使わないという判断は、そのままです。自社だけ出します。
    • ★★ 検査を 1 つ緩めました。 「数を手書きしていないか」は仕様の数を見る検査で、実測値は実装から導けません（導けたら、それは測っていないということです）。測った日を書いてある見本の中だけ、実測として許します。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  31. 2026.08 第311版2026-08-30定期改訂表現結果に影響なし

    同じ 10 項目を、2 つの名前で呼んでいました

    • ★★★ 外部の評価で指摘されました。 診断結果の画面と、診断基準のページで、10 項目すべての呼び名が違っていました。 ★★★ うち 2 つは極性まで逆でした ——「インデックスの許可」と「インデックスの禁止」、「Google AI 入力の許可」と「AI への直接入力の禁止」。同じ 93% が「許可されている割合」とも「禁止されていない割合」とも読めます。 社内で共有したときに、解釈が割れます。
    • ★★ 数えているのは「伝わっている側」なので、肯定形にそろえました。 名前は 1 つにし、pnpm check:current-items が 2 つの一致を毎回見ます。 CLAUDE_METHOD.md の「名前は監査対象に入れる」が、そのまま当てはまる形でした。
    • ★★ 回数の上限が、特定商取引法の表記にしかありませんでした。 「1 時間あたり 15 回・1 日あたり 30 回」は、課金したあとで初めて知る形になっていました。よくある質問に出しました。 ★ 合わせて、その数を書き写していたのもやめました —— 実装の値をそのまま読みます。
    • ★★ Cookie の説明が「有効にしてください」しかありませんでした。 何に使っているかが、どこにも書いてありませんでした。 ★ 書けることが少ないのが、いちばんの説明でした —— 使っているのはログイン状態を保つ 1 種類だけで、解析にも広告にも使っていません。 ログインされていない場合は発行しません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。 項目の中身は変えていません。呼び名だけをそろえました。
  32. 2026.08 第310版2026-08-30定期改訂表現結果に影響なし

    記事のリンクだけが、検査を通っていませんでした

    • ★★★ 新しい記事の初稿に、実在しない URL を書いていました。 404 のページで、現行は別の場所にあります。 資料の到達性を見る検査は通っていました —— 台帳の URL しか見ていないからです。 台帳は正しく、記事だけが間違っていました。
    • ★★ 記事の外部リンクは、すべて証拠台帳にある URL であることを求めます（pnpm check:article-links）。台帳の URL は、これまでどおり到達性まで見ています。 2 つを合わせると、記事のリンクまで到達性が保証されます。 ★ 記事のリンクを毎回ネットワークで叩く検査にはしません —— 外の都合で検査が落ちるようになります。
    • ★★★ 副作用のほうが本命かもしれません。 台帳に無い資料を、記事だけがこっそり引くことができなくなります。 一次資料は台帳を通す、という規律が形になります。
    • ★★ 入れた時点で、2 本の食い違いが見つかりました。 前の版で台帳の URL を新しくしたとき、記事の本文を直していませんでした。 「正本を直したら、正本を引いている場所を全部数える」が、また守れていませんでした。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  33. 2026.08 第309版2026-08-30定期改訂表現結果に影響なし

    「見えていない内部状態を確定しない」を、記事自身が 1 行破っていました

    • ★★★ 症状の表に「内容は使われているのにリンクが出ない」と書いていました。 外から回答を見て自社ページと同じ内容だと分かっても、そのページが実際に利用されたことは証明できません。 別のページから同じ事実を取った可能性も、別の経路も残ります。 ★ この記事の主題は「症状から、見えていない内部状態を確定しない」です。 その記事自身が、1 行だけ確定していました。 「一致して見えるが」に直し、一致は利用の証明ではないと添えました。
    • ★★★ 情報源と経路を、また並べていました。 「公開 Web、検索の基盤、利用者が渡した URL」を経路として並べていましたが、公開 Web は情報源です。前の版の「AI 検索とは」で直したばかりの誤りでした。 ★ 原則を書いた場所と、原則が効くべき場所がずれる —— この製品が繰り返し踏む型です。
    • ★★★ robots.txt を、すべての経路の話として書いていました。 利用者起点の取得には、robots.txt の規則が及ばないことがあります（提供元が明記しています）。手順を「自動のクロールと検索掲載の経路なら」に限定しました。 限定しないと、この記事自身の「経路は一つではない」を破ります。
    • ★ 一般化を 3 か所そろえました ——「提供元は用途ごとに」→「OpenAI や Anthropic などでは」、「検索索引用」→「検索用途」（索引の構築まで述べているかは提供元によって違います）、「優先ソース」→「Google の Preferred Sources では」。
    • ★ 「公開ページ側」を「公開 Web 側」に直しました（2 か所）。robots.txt や HTTP の応答を含むので、ページでは狭すぎます。 区分は 3 つあるのに「両方の区分」と書いていた箇所も直しました。
    • ★ 断定を弱めました ——「表現は変わります」→「変わり得ます」、「返るものは変わります」→「変わり得ます」。論点は「必ず変わる」ではなく、1 回の不在を一般化できないことです。 「各社の内部の仕組みは公開されていません」も「公開されていない内部の仕組みがあります」に直しました —— 公開されている仕組みも多いためです。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  34. 2026.08 第308版2026-08-30定期改訂表現結果に影響なし

    軸を分けたあと、見出しと要点に取り残しがありました

    • ★★★ 見出しが「利用より先 — 観測している範囲の外」でした。 直前の表に「行動は 2 項目」と書いてあるのに、です。 「利用・引用・推薦・選択」に直しました。 ★ 前の版で軸を分けたのに、見出しだけが古い分け方のまま残っていました。
    • ★★ 要点の末尾が「次は公開ページの外を調べる」でした。 後の節では「サイト側の要因は残る。測っていないだけ」と正しく書いています。 とくに実体の識別は、自社ページの書き方でも変わります。 「ページの内容に加えて、公開ページの外にある要因も」に直しました。
    • ★★★ 切り分けの最初の 1 手が抜けていました ——「その回答は、外部の情報を検索・参照していたか」。製品全体が AI 検索なのではありません。 外部を参照していない応答に robots.txt を調べても、何も分かりません。 手順 0 として足しました。
    • ★★ 段階の依存に、範囲を付けました。 経路は一つではないので、ある経路が塞がれていることは、別の経路でも起きないことを意味しません。 「同じ情報が、同じ経路で後段へ進む場合の順序」と書きました。
    • ★★ 各段階の 4 項目を、区分ごとに分けて出しました。 並べただけでは、4 つが同じ強さの条件に見えます。 固有の title や代替テキストが欠けていても、「取得できない」とは判定していません。
    • ★ 「提供元自身がそう書いています」を「少なくとも Google は」に、「提供元は用途を分けています」を「OpenAI や Anthropic などは」に直しました。 全提供元の共通仕様に見せないためです。
    • ★ 「SILVE は施策の助言をしません」は、製品としては不正確でした。 診断は直し方を出しています。 「この節では、施策の効果を SILVE として評価しません」に限定しました。
    • ★ 一次資料を 2 本足しました —— 鮮度の説明の根拠（ランキング システムのガイド）と、「同じ URI でも返る表現は変わる」の根拠（RFC 9110）。この記事だけを読む人が、根拠を辿れるようにするためです。 ★ RFC の読み込みは正本で partial なので、confidence は medium に留めました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  35. 2026.08 第307版2026-08-30定期改訂表現結果に影響なし

    新しい記事の初稿が、自分の原則を破っていました

    • ★★★ 「AI 検索に出てこないのはなぜか」の初稿で、「発見・取得・利用を SILVE が判定する」と書いていました。 二重に誤りでした。 正本と食い違っており（実際は 発見 4 / 取得 4 / 利用 0 / 引用 0 / 推薦 0 / 選択 0 / 行動 2 で、利用と行動が逆でした）、より本質的に「段階を判定する」という書き方そのものが誤りでした。
    • ★★★ クローラーが許可されていることは観測できても、提供元が実際にそのページを発見したことは観測していません。 200 が返ることを観測しても、取得されたことは観測していません。 これは「準備状態 ≠ 可視性 ≠ 実行」そのものです。 列の名前を「関連する準備状態を観測するか」に変えました。
    • ★★ 区分と段階を重ねていました。 「到達・利用の条件 / 提供元が推奨する実装 / エージェント対応」は区分、「発見 → … → 行動」は段階で、別の軸です。代表 URL の指定は、区分でいえば提供元が推奨する実装ですが、段階でいえば発見です。
    • ★★★ 題で「症状は原因ではない」と言いながら、1 つ目の表が症状と原因を 1 対 1 で結んでいました。 記事自身が、記事の主張を破っていました。 とくに 「知らないと言われた」から「学習データに入っていない」、「AI 機能に出ない」から「掲載条件を満たしていない」 は推論できません。後者については、Google が「要件をすべて満たしても掲載は保証されない」と明記しています。 表の右列を「最初に見る段階」に変えました。
    • ★★ 「サイト側で直せるのは前の 3 つだけ」と書き、直後の表で「行動は直せる」と書いていました。 同じ記事の中で矛盾していました。 切れるのは「直せるかどうか」ではなく、SILVE が現在観測している範囲です。
    • ★ 「いちばん多い原因」と書いていました。 どの原因が多いかを測っていません。 最初に見る理由は頻度ではなく、前の段階の条件だからです。
    • ★ 一次資料の URL を現行のものへそろえました。 Perplexity の資料が 3 つの台帳で旧 URL のままでした（転送はされます）。★ 転送されるだけでは、台帳の URL が現行の場所を指していることになりません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  36. 2026.08 第305版2026-08-30定期改訂表現結果に影響なし

    キーボードだけで読む人が、毎回すべての見出しを通過していました

    • ★★ 「本文へ移動」のリンクを置きました。 上の見出しは 5 つ、スマートフォンではさらに 5 つ並びます。 キーボードだけで読む方は、ページを開くたびに全部を通過していました。 ★ 常に置き、焦点が当たったときだけ見えるようにします —— 隠したまま押せる状態にすると、押せることが分かりません。
    • ★ 合わせて確かめたことも書いておきます。 一次資料の URL は全件が到達可能（消失なし）。入力欄にはすべて名前が付いており、焦点の枠線も消していません。 問い合わせの連打には、同一の送信元に対する回数制限が入っています。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  37. 2026.08 第304版2026-08-30定期改訂表現結果に影響なし

    「お送りします」と書いてあったのに、送る仕組みがありませんでした

    • ★★★ 文面を組み立てる側も、見本を出す画面もありました。送る側だけがありませんでした。 登録の画面には「更新の内容と、新しい記事のお知らせをメールでお送りします」と書いてありました。 画面が嘘をついていました。
    • ★★★ 週次の処理の中で送ります。 前回の配信から後に出た記事と、更新した基準だけを入れます。 中身が無ければ送りません ——「更新はありません」という通知は、受け取る側にとって用がないためです。そのときは起点も動かしません（次に記事が出たら、そこから拾います）。
    • ★★★ 最初の 1 回は送りません。 起点が無い状態で走らせると、公開済みの記事すべてが 1 通に入ります。 登録した方が読みたいのは、これからの更新です。 最初の実行は、起点を記録するだけにします。
    • ★★ 二重に送らないための記録は、表を足さずに実行履歴で持ちます。 必要なのは「どこから先が未送か」の 1 点で、それは時刻 1 つで足ります。 ★ 1 通でも送れたときだけ起点を進めます —— 全部失敗したのに進めると、その号は永久に届きません。
    • ★ 宛先はまとめません。 解除のリンクが受信者ごとに違うことと、ほかの購読者のアドレスが見えてはいけないためです。受信側の「登録解除」からも外せるようにしました。
    • ★★★ 管理画面の「配信はまだ一度も行っていません」を、決め打ちで書いていました。 送るようにした日に、この文だけが取り残されます。 実行履歴を読んで、実際の状態を出すようにしました ——「まだ一度も」「起点は記録済み（まだ 0 通）」「直近の配信 ◯◯に ◯ 通」の 3 通りです。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  38. 2026.08 第303版2026-08-30定期改訂表現結果に影響なし

    埋め込み防止・バッチ失敗の通知・フィードを足しました

    • ★★★ 他所のサイトが、アカウントの画面を枠の中に埋め込める状態でした。 解約のボタンと決済の画面への導線があるページなので、押させたい場所へ透明な枠を重ねる攻撃の的として現実的です。 埋め込みを禁止しました（新旧 2 つの書き方を併記）。あわせて型の推測を止める指定・参照元をパスまで渡さない指定・使っていない機能（カメラ・マイク・位置情報）を閉じる指定を入れました。
    • ★ 中身の制限（どこから読み込んでよいか）は、まだ書きません。 枠組みが出す埋め込みのスクリプトを塞いで画面が壊れるためです。いま書けるものだけ書き、書けないものは書きません。
    • ★★ 週次のバッチが落ちても、誰にも届いていませんでした。 記録には残っていましたが、管理画面を見に行かないと分かりません。 落ちたらメールで知らせます。 ★ 知らせるだけで、止めません —— 通知のために、本当の失敗を隠さないためです。
    • ★ 診断の失敗は通知しません。 相手のサイトが落ちている・URL が誤っているなど、起きて当然のもので、結果は依頼した方の画面に出ます。 毎回知らせると、本当に見るべき通知が埋もれます。
    • ★★★ 記事の購読手段がありませんでした。 28 本あるのに、更新を受け取る道が事実上ひとつも無い状態でした（登録できるのはニュースレターだけで、そちらはまだ送っていません）。RSS を出します。 ★ 本文は入れず、要約までにします —— 全文を配ると読む場所が 2 つになるので、正は記事のページに置きます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  39. 2026.08 第302版2026-08-29定期改訂表現結果に影響なし

    canonical のために、全ページを毎回組み立てていました

    • ★★★ canonical を共通レイアウトの 1 箇所で出していました。 そのためにリクエストのパスを読んでおり、それを呼ぶと、そのレイアウトを使う全ページが動的になります。 公開ページが 1 つも CDN に載っていませんでした。
    • ★★ canonical はページごとに出すようにしました。 「1 箇所」という利点は捨てません —— 検査に移しました（pnpm check:canonical）。公開ページ 19 件すべてに、経路と一致する canonical があることを見ます。 足したページで忘れたら、検査が止めます。 守り方を、暗黙の仕組みから明示の検査へ移しただけです。
    • ★★ 二重に出ていたことも分かりました。 変更履歴のページは自分でも canonical を書いていたので、link が 2 本出ていました。 同じ値なので実害はありませんでしたが、2 つの仕組みが重なっていた証拠です。
    • ★★★ ただし、速さはまだ変わりません。 共通レイアウトがログイン状態を読んでいるので、そこが残っているかぎり全ページが動的なままです。 直すには枠組みの移行（Cache Components）が要り、38 ページすべてに影響します。 今日はやりません。 ★ 「直した」と言えるのは canonical の重複とパスの読み取りまでで、速さについては何も変わっていません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  40. 2026.08 第298版2026-08-29定期改訂表現結果に影響なし

    請求書の中身を見る行と、「近い記事」の重複

    • ★★★ 請求書の書面に何が載っているかを、実物で見る行を管理画面に足しました。 登録番号の置き場所は 1 つではありません —— 請求書テンプレートのカスタムフィールドに足す道と、アカウントの事業者情報に登録しておく道があります。 後者なら請求書にも領収書にも自動で載ります。 両方を見て、どちらで設定されているかを出します。
    • ★★ 税の行があるかも出します。 登録番号だけでは適格請求書になりません。 税率と税額も書面に要ります。 ★ ✗ にはしません —— 適格請求書として使えるかの判断は税の専門家の領分なので、見えている事実だけを出します。
    • ★ 特定商取引法に基づく表記の見出しを直しました。 「適格請求書発行事業者」という見出しに番号が並んでいました。並んでいる値が登録番号なら、見出しもそう書きます。 名前は監査対象に入れる（CLAUDE_METHOD.md）。
    • ★★ 「近い記事」に同じ見出しが並んでいました。 1 つの見出しの下に段落が複数あるためです。 ★ これは材料の一覧ではなく、行き先の一覧です。 行き先が同じなら 1 つでよいので、重複を落としました。答えを作ったときの「もとにした文」は、これまでどおり全部出します（読ませたものを隠さないためです）。
    • ★★★ 答えの検めで「作文 64%」と出た 1 問を読みました。 正しい答えでした。 材料が Google の英文で、答えが日本語だったためです。 2 文字の重なりが少ないのは当たり前でした。 印を消すのではなく、訳であることを併記します。 同じ調べ方を二度しなくて済みます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  41. 2026.08 第297版2026-08-29定期改訂表現結果に影響なし

    解約すると、請求書へ行く道が消えていました

    • ★★★ 利用者の報告です ——「マイページの「ご契約」とはどこだ？見当たらない」。契約中の方にしか出していませんでした。 ★ やめた方こそ、請求書と領収書が要ります。 Stripe の顧客になったことがあれば、契約が終わっていても履歴は残り、決済の画面は開けます。 契約中であることを条件から外しました。
    • ★★ 前の版で、この導線を案内する文をよくある質問に書いたばかりでした。 書いた先が、書いた相手に見えていませんでした。
    • ★★★ 請求書の書面に、登録番号が入っていませんでした。 実際の PDF を開いて確かめた結果です。 「登録番号は T… です」と書くだけでも、書面にあることを暗に約束してしまいます。 番号の記載が必要な方には、ご連絡いただく経路を書きました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  42. 2026.08 第296版2026-08-29定期改訂表現結果に影響なし

    領収書について、設定を見てから書きました

    • ★★★ 前の版では、この問いだけ空けておきました。 答えが Stripe の設定しだいで、設定名を案内しても、そのとおりになっているかを確かめられなかったためです。 管理画面の点検に足し、本番の鍵で「請求の履歴が出る設定」であることを確認してから書いています。
    • お支払いの履歴と請求書は、アカウントページの「ご契約」から決済ページを開くと、確認とダウンロードができます。 適格請求書発行事業者の登録番号も書きました —— ★ 番号は書き写さず、特定商取引法の表記と同じ値を読みます。
    • ★ これで、取引についての問いは 6 つ答えられます —— 料金・無料の範囲・ページ数・所要時間・支払い方法・法人契約・領収書。検査は 28 問になりました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  43. 2026.08 第295版2026-08-29定期改訂表現結果に影響なし

    取引の問いに、3 つ答えられるようにしました

    • ★★ 所要時間を、よくある質問に足しました。 数字は書き写していません —— 診断ボタンに出している値をそのまま読みます。 手で書くと、片方だけ直したときに食い違います。 実測はおよそ 30 秒で、画面の「30 秒〜1 分」と矛盾しません。
    • ★★★ 「法人契約」という区分そのものがありません。 無いものを「できません」と書くのではなく、無いことを書きました。 ★ 会社のカードで払えるかは、別の問いです。 払えます。扱いは変わりません。 ご契約はアカウントをお持ちの方との間で成立します。
    • ★ 請求書払いと銀行振込には対応していません。 これは運用を 1 人で回せる範囲に留めるという判断で、以前から決めていたものです。書いていなかっただけでした。
    • ★★★ 領収書については、まだ書いていません。 答えが Stripe の設定しだいだからです。 設定名を案内しても、そのとおりになっているかは確かめられません。 管理画面の Stripe の点検に、3 つ足しました ——「請求の履歴が出る設定か」「ポータルから解約できる設定か」「支払い方法を変えられる設定か」。合っていなければ、合っていないと出ます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  44. 2026.08 第294版2026-08-29定期改訂表現結果に影響なし

    「やるべきですか」に、黙っていました

    • ★★★ 50 問通したとき、この形が 7 問ありました ——「サイトマップは要りますか」「canonical は必ず入れるべきですか」「被リンクは AI 検索に効きますか」「SNS はやったほうがいいですか」など。すべて「見つかりませんでした」で返っていました。
    • ★★★ 材料を足して答える道は選びませんでした。 canonical もタイトルも sitemap も書けることはあります（診断項目にあるか、v22 で判定から外した項目です）。しかし「べきですか」に答えると助言になります。 SILVE は施策の助言をする製品ではありません。
    • ★★ 測っていないと言うのは、助言ではありません。 断り方だけを変えました ——「SILVE が扱っているのは、AI 検索に読まれる準備ができているかどうかです。施策をやるべきかどうかや、その効果は測っていません。」★ これは v22 の「判定する項目と、観測する項目を分ける」の、対外的な言い方です。
    • 出す条件は 2 つです。 語が資料に無いとき（範囲外）は出しません ——「今日の天気は」に準備状態の話を返しても意味を成しません。問いが助言の形をしているときだけ出します。 材料は 1 文字も足していません。
    • ★ 取引の穴は、態度の問題ではないので埋めました。 「クレジットカード以外で払えますか」も返せていませんでした。特定商取引法の表記に「クレジットカードによる決済」と書いてあっても、「以外は使えるのか」には答えていません。 書いていないことは、無いのと同じです。 ★★ よくある質問の問い自体を、利用者の言い方に合わせました ——「支払い方法はありますか」では 払え が資料に無く、範囲外と判定されていました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  45. 2026.08 第293版2026-08-29定期改訂表現結果に影響なし

    半分以上の質問に、答えられていませんでした

    • ★★★ 利用者の指摘です ——「失敗確率が高いな。もう少しチェックしたほうが良くないか」。そのとおりでした。 手で 10 問ずつ見るやり方では追いつきません。 50 問をまとめて叩いて、答えの文に印を付ける道具を作りました（pnpm audit:ask）。合否は決めません。読む順番を決めます。
    • ★★★ 最初の 50 問で、30 問が「見つかりませんでした」で返っていました。 引けていなかったのではありません。 正しい記事は引けていて、その記事の中の答えている段落だけが 3 位までに入っていませんでした。 実例 ——「llms.txt は必要ですか」の上位 3 件は、すべて llms.txt の記事ですが「robots.txt とは違う」「安全性には使えない」「全文を詰め込むものではない」で、必要かどうかを書いた段落は 4 位以下でした。
    • ★★ これまでの検査では見つけられませんでした。 記事の単位で見ていたからです。 記事は合っていました。段落が違いました。
    • ★★★ 模型へ渡す段落を 3 から 6 に増やしました。 18 問中 6 問が答えられるようになりました。 払う額はおよそ倍になりますが、1 問あたり 1 円に満たない額です。
    • ★★★ 材料を増やしたら、別のものが壊れました。 「料金はいくらですか」が答えられなくなり、原因は記事の中の例文でした ——「2026 年 8 月 11 日時点では、料金は月額 9,800 円です」。「時点を書け」と説明するための例文で、SILVE の料金ではありません。 ★ 引用ブロックを段落へつないだ日に生まれた穴です。 それまでは例文が丸ごと落ちていたので、起きませんでした。 記事に「（例）」と書き、主語の無い価格の言い切りを検査で止めます。
    • ★★ 入れなかったものも書いておきます。 「LLMO って何ですか」は llms.txt の記事が取ります（llmo と llms は 2 文字の手がかりを 2 つ共有します）。英字の連なりを 1 つの手がかりとして数える形を試したところ、LLMO は直りましたが「GEO とは」が壊れました。 すでに通っている問いを壊す変更は入れません。 穴として残し、検査に毎回出します。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  46. 2026.08 第292版2026-08-29定期改訂表現結果に影響なし

    10 問通したら、6 つ壊れていました

    • ★★★ 記法をそのまま引いていました。 「準備状態と可視性はどう違いますか」のもとにした文に、{{silve.current.items.agent.count}} がそのまま出ていました。 記事の画面では展開しています。尋ねる機能だけが、生の本文を読んでいました。 ★ 同じ本文を 2 か所で読むなら、同じ手順を通すこと。
    • ★★★ 画面が嘘をついていました。 「近い記述はありましたが、答えになっていませんでした」を、出てこない語を挙げられないときの受け皿にしていました。模型に読ませてすらいない場合まで、そう書いていました。 起きたことは 3 通りあります ——「語が資料に無い」「読ませたうえで答えになっていないと判断された」「語はあるが、引けた文が近くない」。それぞれ別の文にしました。
    • ★★ 「スコアは何点ですか」が「見つかりませんでした」で返っていました。 点数 は同義語にありましたが、何点 がありませんでした。 ★ 総合スコアの廃止は、この製品の中心にある判断です。 そこを訊かれて答えられないのは、立場が無いのと同じに見えます。
    • ★★★ 解約の案内が、製品より古いままでした。 答えは「contact@silve.jp へご連絡ください」でしたが、アカウントには解約ボタンがあります。 資料だけが、ボタンの無かったころのままでした。 ★ 機能を足したら、それを説明している文を探すこと。 画面に足すだけでは、尋ねる機能は古いことを言い続けます。 特定商取引法に基づく表記の文面を直したので、専門家の確認を受け直してください。
    • ★ 「診断結果は何日で消えますか」で、保存期間の段落が引けませんでした。 資料の語は「削除」で、「消え」は 0 回でした。同義語に足しました。
    • ★ 「資料には〜と明記されています」と答えていました。 指示には「資料の番号や『資料によると』への言及はしない」と書いてありましたが、言い回しを列挙する形だったので漏れました。 「資料そのものに言及しない」と書き直しました。
    • 正しかったものも書いておきます ——「御社の従業員数」は範囲外として断り、「AI 検索で 1 位を取る方法」は断ったうえで近い記事を出しました。検査は 20 問から 24 問になりました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  47. 2026.08 第291版2026-08-29定期改訂表現結果に影響なし

    「見つかりませんでした」で終わっていました

    • ★★★ 利用者の指摘です ——「あまりにも冷たい」。そのとおりで、しかも不正確でした。 引けた文はあったのに、「ありませんでした」としか書いていないことがありました。
    • ★★ 起きたことは 2 通りあり、画面はもう区別しています。 語が資料に無いとき（範囲外）と、引けたが答えになっていないときです。区別していたのに、次の一手を書いていませんでした。
    • ★★★ 引けたが答えになっていないときは、「近い記事」を出します。 ただし本文は出しません。 答えではないものを、答えと同じ見た目で出さないためです。見出しと出典だけを出します。
    • ★★ 語が資料に無いときは、「近い記事」を出しません。 そのときの上位は、ただの雑音です。
    • ★★★ 「言い換えてみてください」だけでは、嘘になりえます。 書いていないことは、言い換えても出てきません。 効く場合と効かない場合を、両方書きました。 添えるのは 3 つです ——「サイトで使っている言葉に近づけると引けることがあります」（例を押せば、そのまま尋ねられます）「書いていないことは、言い換えても出てきません」「答えられなかった質問は記録して、資料の不足として直しています」。記録することは、以前から特定商取引法等に基づく表記のページで開示しています。
    • お急ぎの方には、お問い合わせへの導線を置きました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  48. 2026.08 第290版2026-08-29定期改訂表現結果に影響なし

    尋ねる機能が、資料より強く言っていました

    • ★★★ 製品そのものへの問いを 5 つ試したら、2 つ壊れていました。
    • ★★★ 資料より強い言い方をしていました。 資料は「Google は画像の理解に alt を使うと明記し、alt が無い書き方を悪い例として挙げています」。答えは「Google が画像の理解に alt を使えなくなり」。「使うと書いてある」を「無いと使えない」に変えています。 ★★ これは v22 で撤回したばかりの主張です —— 代替テキストが掲げていた「伝わらなくなる」は、提供元の記述と食い違っていました。 方法論が消した言い方を、実行時に作り直していました。
    • ★★★ 資料の「しません」に、勝手な条件が付いていました。 資料は「総合点は出しません。単位が違い、1 つの数にまとめるには根拠のない変換率が要るためです」。答えは「ただし総合点は出さず、…などは有料プランでのみ利用できます」。「無料だから出ない」＝「払えば出る」と読めます。 総合スコアの廃止は、この製品の中心にある判断です。 理由を落として並べ替えるだけで、逆の意味になりました。
    • 書き方の指示に 2 つ足しました ——「資料より強い言い方にしない。必要条件と推奨を入れ替えない」「資料が『しません』と書いていることに、資料に無い条件（無料 / 有料・版・環境）を付けない」。
    • ★★★ 指示を直しても、既に聞かれた問いには届きませんでした。 控えの鍵は「引いた 3 件の本文」だけで、「材料が同じなら答えは今も正しい」と書いていましたが、それは指示が変わらないことを前提にしていました。 指示の文面から作った版を鍵に混ぜます。 上げ忘れが起きません。
    • ★★ 「順位」という語が、サイトのどこにも無いことが分かりました。 「診断すれば順位は上がりますか」は「見つかりませんでした」で返っていました。立場が無かったのではありません。 よくある質問の「すべての項目が満たされていれば〜」が、その答えです。ただ「順位」「上がる」と書いていなかったので、引けませんでした。 ★ 売る側がいちばん訊かれる問いに、その言葉で答えていない状態でした。 1 文足しました ——「検索順位が上がるとも申し上げません。順位や実際の表示は可視性の側にあり、SILVE はそこを測っていません。」
    • ★ 検査の穴も同じ形でした。 16 問すべてが用語と方法論で、製品そのものへの問いが 1 問もありませんでした。 4 問足しました（ページ数・無料の範囲・順位・診断項目の説明）。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  49. 2026.08 第289版2026-08-29定期改訂表現結果に影響なし

    「もとにした文」の 1 件目が、答えの出どころではなかった

    • ★★★ 「RAG を Google はどう説明しているか」への答えは、Google の原文をそのまま引いていました。 しかし 1 件目に出ていたのは、Google-Extended という別の記事・別の話の一段落でした。 答えの出どころは 2 件目にありました。
    • ★★ 前々版と同じ形です。 あのときは「もとにした文」という名前が、実際にやったことより狭いのが問題でした。今度は、名前は合っているのに、並び順が取得の順のままでした。
    • ★★★ 画面が「もとにした文」と呼ぶ以上、寄与の大きい順に並べます。 取得の順位は内部の話で、こちらは管理画面で見ています。寄与は、その段落の 2-gram のうち何割が答えに現れたかで測ります。近い値は並べ替えません（0.1 刻み）—— 僅差で順を入れ替えても、意味は増えません。 答えを作れなかったときは、取得の順のままです（寄与を測る相手がいません）。
    • ★ 検査に入れました。 3 件のうち 1 件をそのまま写した文を答えと見なせば、その 1 件が 1 件目に来ることを、模型を呼ばずに確かめられます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  50. 2026.08 第288版2026-08-29定期改訂表現結果に影響なし

    「もとにした文」が、何も説明していない一文だった

    • ★★★ 「AI 検索ってそもそも何？」の答えの下に、こう出ていました ——「Google の生成 AI 検索向け公式ガイドは、RAG をこう説明しています。」何も説明していません。 説明は、次の引用ブロックにありました。
    • ★★★ 原因は順位付けではなく、材料の側でした。 引用ブロックを材料から外していました。 理由は「表やコード行と同じく、返しても読めないから」。しかし引用は文章です。 そして記事は「こう書いています」→ 引用 という形で書かれているので、引用を落とすと、指すだけの文が残ります。
    • ★★ 一次資料の文そのものを、この Bot が引けないのも倒錯していました。 SILVE は一次資料を出すことを繰り返し原則にしています。 引用ブロックは、直前の段落へつないで 1 つの段落として扱います。（表とコード行はこれまでどおり外します。）
    • ★★★ 前の版で「未解決」として毎回出していた問いが、これで 1 位を取りました。 「話し言葉を外すと手がかりも一緒に消えるため」と説明していましたが、それは原因ではありませんでした。 ★ 穴を消さずに並べていたから、直ったことに気付けました。 検査の問いは 15 問から 16 問になり、未解決は 0 件です。
    • ★ 文の側も 1 か所直しました。 「通常の検索より広く多様なリンクを表示できると説明しています」に、誰がとは書いていませんでした。 単独で引用されると、出どころの無い文になります。 Google と書きました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  51. 2026.08 第287版2026-08-29定期改訂表現結果に影響なし

    「AI 検索とは」で 1 位が別の記事になっていました

    • ★★★ まず、測れるようにしました。 検査が作る材料が本番と違ったままでは、本番に無い形へ寄せてしまいます。 記事だけファイルから作り、それ以外（診断項目・FAQ・料金・用語集）は本番と同じ関数を呼ぶようにしました。違うのは「DB の記事か、ファイルの記事か」だけになります。
    • ★★★ 「次に読む」を材料から外しました。 記事末尾のリンク集で、中身ではなく行き先の一覧です。 短くて、語がそのまま並ぶので、問いに対していちばん強く当たってしまいます。 実際「llms.txt は必要ですか」で上位 2 件がどちらも別の記事の「次に読む」でした。表やコード行を外しているのと同じ理由です。
    • ★★★ 記事の題を索引に入れました。 見出しは入れていたのに、題は入れていませんでした。 「AI 検索とは — SILVE が何を含め、何を分けているのか」という題を、どこでも配点していませんでした。 ★ 題は「その段落が何の話か」を示す、いちばん外側の見出しです。見出しと同じ扱いにし、新しい重みは増やしていません。
    • これだけで、引けていなかった 2 問が両方直りました ——「GEO とは」「llms.txt は必要ですか」。
    • ★★ 話し言葉を外す規則が、外しすぎていました。 「ひらがな 2 文字以上の塊との境目」を外していたので、「〜とは」の手がかりまで落ちていました。 3 文字以上に変えました —— 「ってそもそも」は外し、「とは」は残ります。落とす規則は、落としきってはいけない。
    • 「AI 検索とは」は、上位 3 件すべてがこの記事の定義の節になりました。
    • ★ 残っている穴も書いておきます。 「AI検索ってそもそも何？」は上位 3 件には入りますが、1 位を取れません。 話し言葉を外すと「とは」のような手がかりも一緒に消えるためです。検査に「未解決」として毎回出します。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  52. 2026.08 第286版2026-08-29臨時改訂表現結果に影響なし

    「もとにした文」が、実際より狭い意味で使われていました

    • ★★★ 返答は、引いた文を全部読ませて組み立てています。 ところが画面は、1 件目だけを「もとにした文」と呼び、残りを「近い箇所」と呼んでいました。
    • ★★★ 利用者の報告で分かりました。 「AI 検索とは何か」の質問で、答えの中身は 2 件目の記事から来ているのに、「もとにした文」として出ていたのは別の記事の一文でした。名前が、実際にやったことより狭かったわけです。
    • 「もとにした文（3 件）」と数を出し、残りも「ほかに、もとにした文が 2 件あります」と呼びます。
    • ★ 引用だけを返すとき（返答を作れなかったとき）は別です。 そのときは 1 件目が本体で、残りは本当に「近い箇所」です。呼び方を分けました。
    • ★★ 名前は監査対象に入れる —— この規律は画面の名前にも当てはまります。 ASK.md に A3b として書きました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  53. 2026.08 第285版2026-08-29定期改訂表現結果に影響なし

    話し言葉の飾りが、いちばん効く語になっていました

    • ★★★ 記事も用語集も材料に入れたのに、「AI検索ってそもそも何？」の答えが出ませんでした。 引けていたのは別の記事です ——「そもそも何を数えているのか」「そもそも何を提案しているファイルか」。
    • ★★★ 原因は 2 文字ずつに切る作り方でした。 「AI検索ってそもそも何？」からは 索っ と も何 ができます。どちらも資料にほとんど無いので効き方が跳ね上がり、検索 より強くなっていました。 話し言葉の飾りが、いちばん効く語になっていたわけです。
    • ★★ ひらがなだけの 2 文字は前から外していました。 外し損ねていたのは「言葉にひらがなが 1 文字くっついた境目」のほうです。ひらがなが 2 文字以上続く塊との境目だけを外しました —— 送り仮名（「見出し」の 出し）は 1 文字で終わることが多く、そこは残ります。
    • ★★★ 調整の根拠が再現できない状態でした。 記録には「19 問（正解つき）で 16/19 → 18/19」とありますが、その 19 問はどこにも残っていませんでした。 質問の組を検査として置き、CI で毎回走らせます。
    • ★ 引けていない質問は隠さずに出します —— 「GEO とは」（2 文字の略語は手がかりが弱い）、「llms.txt は必要ですか」（「必要か」を扱う別の記事が勝つ。間違いとまでは言えない）。落としはしませんが、毎回表示します。
    • ★★ この検査が作る材料は、本番と同じではありません（DB の記事・診断項目・FAQ・料金を含みません）。したがって「1 位であること」は求めず、上位 3 件に入っているかだけを見ます。 DB を要らないことを優先しました —— CI で毎回走らない検査は、また腐ります。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  54. 2026.08 第284版2026-08-29臨時改訂表現根拠結果に影響なし

    直した本文と、直していない要点が食い違っていました

    • ★★★ 外部レビューで、自分の記事の中の自己矛盾を 3 つ指摘されました。 本文を直したのに、要点と規則の文が古いまま残っていました。
    • 要点 3 が「情報源は公開 Web ページだけではありません。商品フィードや、利用者が与えた URL も含まれ得ます」のままでした。本文では「利用者が URL を与えるのは経路であって、その先が公開ページなら出どころは公開 Web」と直しているのに、要点だけ古い分類でした。
    • 要点 4 も「公開 Web ページ側」のままで、本文の「公開 Web 側」と食い違っていました。判定の基準の文も「外部の情報を検索／取得し」のままで、冒頭の「検索・参照」と食い違っていました。
    • ★★ 前の版で直した場所と、直していない場所が、同じ記事の中で分かれていました。 この型を、この記事だけで 2 回続けています。
    • 4 レイヤーの説明を「共通の尺度への換算や重み付けが必要です」に戻しました。 前の版で「重み」を機械検査に止められ、言い換えて逃げていました。 ★ 検査が止めたいのは「重みを使っている」と読める文であって、「重みが要るが、その根拠が無いから合成しない」という説明ではありません。 理由つきの許可として登録しました（MEASUREMENT.md 自身が「等価も重みである」と書いており、廃止の論拠そのものがこの語を必要としています）。
    • ★★★ 例に挙げた 4 つのうち 2 つは、製品資料を取得できませんでした。 OpenAI と Perplexity のヘルプは 403 が返ります（2026-08-29）。記事に「取得できなかったもの」として書き、根拠は両社のクローラー資料に置きました。 読めなかった資料を、読んだことにしません。
    • Anthropic の Web search の資料は取得できたので足しました。 同じ資料が、特定の URL を読みに行く機能を別の道具として案内しています —— 「検索する」と「その場で取得する」を定義の条件として同じにしない根拠です。
    • ★ Google の記述を原文へ寄せました ——「広く多様なリンクを出す」→「表示できる」。毎回必ず通常の検索より多い、とは読ませません。
    • ★ を 9 個から 3 個に減らしました。 全部に付けると、重要度の差が消えます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  55. 2026.08 第283版2026-08-29臨時改訂表現根拠結果に影響なし

    中心語の記事で、層の違うものを 1 つの表にまとめていました

    • ★★★ 外部レビューの指摘。いちばん重かったのはこれです —— 「情報源」の 1 列に、公開 Web・検索基盤・商品フィード・利用者が与えた URL を並べていました。 「利用者が URL を与える」のは経路であって、その先が公開ページなら、出どころは公開 Web です。層の違うものを 1 つの表にまとめないという、このサイト全体の規律を、中心語の記事で破っていました。 出どころと経路に分けました。
    • ★★ 「その場で外部の情報を検索・取得し」は狭すぎました。 提供元は自前の検索基盤や索引も使います。 「その場で元のページを取りに行くこと」を定義の条件にしません。 「問いに応じて外部の情報源を検索・参照し」へ。検索することと、その場で取得することは別です。
    • ★★ AEO / GEO / LLMO を「AI 検索に向けた最適化」と一括していました。 AEO は生成 AI 検索より前からある語で、AI 検索だけを対象とする言葉ではありません。 各記事で起源と射程を分けておきながら、入口記事で 1 つに畳んでいました。 「関係して語られる概念。互いに同義ではない」に改めました。
    • ★★★ 「この語を単位にした指標は作らない」は事実と違いました。 robots.txt を通る AI 検索クローラーを「6 件中何件」と数える項目が現に存在します。 言いたかったのは「AI 検索を単一の仕組みとして観測しない」です。そう直しました。
    • ★ 「公開 Web ページ側」→「公開 Web 側」。見ているものには robots.txt や HTTP の応答も含まれ、それらはページではありません。 あわせて「提供元ごとに分けて観測します」も、実際に分けているのは提供元が公開している制御条件だけだと限定しました。
    • ★ Google の例に「少なくとも Google では」を付けました。 一次資料 1 件で、AI 検索全体の一般命題を証明したように読ませません（CLAUDE_METHOD.md §5）。
    • ★ 記事末尾に一次資料の一覧を足しました。 この記事のために再取得したものと、他の台帳で確認済みのものを引いただけのものを書き分けています。
    • ★★ 「出どころと経路は別」は証拠台帳へ入れませんでした。 一次資料から出る事実ではなく、SILVE の整理だからです。証拠の要らない主張は規則の正本に置くという切り分けに従い、AI_SEARCH.md AS4a に置きました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  56. 2026.08 第282版2026-08-29定期改訂分類根拠結果に影響なし

    「AI 検索とは」を記事にし、読む順番の 1 番目に置きました

    • ★★★ この製品の中心語に、定義の記事がありませんでした。 用語集に短い定義を足したところ（2026.08.280）、外部レビューから「中心語なのだから独立記事にすべき」という判断をもらい、書きました。26 本の入口が「7 段階」だったのを、「AI 検索とは」に差し替えます。
    • ★★ 初見が最初に知りたいのは「AI 検索って何？」で、その次が「では SILVE はそれの何を見ているのか」です。 7 段階と 4 レイヤーは、その後に「なぜそこだけを測るのか」を説明するモデルとして出すほうが自然でした。
    • ★★★ 記事のいちばん重い節は「SILVE が直接測っているのは、その一部」です。SILVE は AI 検索の評価器ではありません。 AI 検索という現象の一部を、外から観測できる範囲で数えているだけだと、はっきり書きました。
    • ★★ 「業界に統一定義は存在しない」とは書きません。 それは全称命題で、主張するには「無いことを確認する作業」が要ります。 書けるのは「SILVE が確認した範囲では、共通して採用される統一定義を確認できない」までです。用語集の文もそう直しました。
    • ★ 製品名ではなく、表示面・機能で判定することを規則にしました —— その表示面が外部を検索／取得し、生成 AI が回答を構成するか。 同じ製品の中に、含まれる場面と含まれない場面があります。
    • ★ 情報源を公開 Web に限りません。 商品フィードや、利用者がその場で与えた URL も含まれ得ます。観測できる範囲を、対象そのものの定義にしないという切り分けです。
    • ★ 語の起源は扱いません。 AEO / GEO のように「誰が提唱した概念か」が主題の語とは役割が違います。調べていないものを、調べたように書きません。 そのことを記事に明記しました。
    • 根拠: Google の AI 機能の資料を本記事のためにあらためて取得し（2026-08-29）、AI Overviews / AI Mode が通常の検索より広く多様なリンクを出すという記述を逐語で確認しました。「リンクの一覧ではなく回答を返す」という定義を否定する根拠です。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  57. 2026.08 第281版2026-08-29臨時改訂表現結果に影響なし

    「AI 検索」の定義に、測る範囲を書き込んでいました

    • ★★★ 書いた翌日に、外部レビューで 2 か所直りました。 どちらも狭すぎたという指摘です。
    • ★★ 「リンクの一覧ではなく」は誤りでした。 対立軸はリンクの有無ではありません。 AI Overviews / AI Mode は supporting link を出しますし、ChatGPT の検索も Perplexity も回答と参照を一緒に返します。このサイト自身が「拒否してもナビゲーションリンクとしては現れ得る」と書いています。 分かれ目は「主にリンク一覧を返すか、生成 AI が統合して回答を構成するか」でした。
    • ★★★ 「SILVE ではこの意味で使う」の中に、測る範囲を書き込んでいました。 「公開されている Web ページを取得し、その内容をもとに回答を作る仕組み」——これは「AI 検索とは何か」と「SILVE はそのうち何を測るか」を混ぜています。 準備状態と可視性を混ぜるなと言い続けてきた製品が、中心語の定義でそれをやっていました。
    • 定義は広く書き、測る範囲は別の文にしました。 書籍のほうが広かった（商品フィードや、利用者が与えた URL など、発見の経路を公開ページに限っていない）ので、サイトを書籍に合わせています。
    • ★ 製品名ではなく、表示面・機能で判定することも書きました。同じ製品でも、学習済みの知識だけで答える場面は含めません。 これは提供元 × 表示面で観測するという測定の考え方と同じ形です。
    • Claude の Web 検索を例に足しました。 クローラーの一覧には Claude-SearchBot を掲載経路として載せているのに、定義の例からは落ちていました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  58. 2026.08 第280版2026-08-29定期改訂表現結果に影響なし

    「AI 検索」の定義が、どこにもありませんでした

    • ★★★ 利用者の報告 ——「「AI 検索ってそもそも何？」に答えられない。コピーにも書籍のタイトルにも使っている言葉なので必須だ」。調べたところ、記事 26 本・FAQ・用語集のどこにも「AI 検索とは」がありませんでした。 この製品が名乗っている中心の言葉に、定義がありませんでした。
    • ★★ 答えられなかった仕組み自体は、正しく働いていました。 検索は関連する段落を見つけ（網羅率 0.89）、モデルがそれを読んで「これでは答えになっていない」と報告して黙りました。無いものを作らなかったわけですが、利用者から見れば同じことです。
    • ★★★ 用語集が材料に入っていませんでした。 「◯◯って何？」に短く答えられる文が置いてあるのは用語集だけなのに、44 語ぶんが丸ごと欠けていました。 記事は「なぜそう言えるか」を書く場所で、「何であるか」を 1 文で書く場所ではありません。
    • 用語集に「AI 検索」を足しました。 ★ 業界標準の定義は名乗りません —— この語は誰かが定義して広まったものではなく、指す範囲は使う人によって違います。 ★ 起源には触れません —— 最初に文書化された用例を調べていないので、調べていないものを書きません。
    • ★★★ 定義の中に「提供元ごとに違う」を書き込みました。 CLAUDE_METHOD.md §5 が禁じているのは、まさにこの語での一般化です。取得に来るクローラーも、参照の示し方も、制御の方法も提供元ごとに違います。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  59. 2026.08 第276版2026-08-29臨時改訂表現結果に影響なし

    書き出しの単位が名前と食い違い、印刷は空白だらけでした

    • ★★★ 書き出しに「代表 URL の指定が揃っている重複候補 ／ 単位: サイト」と出ていました。 同じ 1 行の中で、名前は「重複候補」、単位は「サイト」という自己矛盾です。
    • 原因は、名前をコードから引き、単位を版から引いていたことです。版に固定された単位が古いままで、あとから定義が変わってもそこだけ動きませんでした。★ 単位の見え方（「組」「枚」）は、数ではなく文言です。 「構造は版から、文言はコードから」という自分の規則に照らして、単位は文言の側へ寄せました。数は DB の値のままで、1 つも変わりません。
    • ★★★ 印刷で「区分の説明だけで 1 ページ使い、あとは空白」になっていました。 利用者の指摘です。原因は、節に「紙をまたいで割らない」を付けていたこと。 節は数十行あることがあり、残りの高さに収まらないと丸ごと次のページへ送られ、手前が空白のまま残ります。
    • ★ 割ってはいけないのは「1 つの意味の塊」まで（項目 1 行・表・カード）。節は割ってよい。 あわせて、段落の 1 行だけが取り残されないようにしました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  60. 2026.08 第275版2026-08-29臨時改訂表現結果に影響なし

    測り直さないと書き出せないように見えていました

    • ★★ 利用者の質問 ——「履歴からは書き出しはできないのか。もう一度測らなくてはだめか」。できます。 推移の表の列の日付が、その回の結果へのリンクになっています。
    • ★ リンクであることが見た目に出ていませんでした。 押せる場所を増やすのではなく、押せることを書きました ——「列の日付を押すと、その回の結果を開けます。測り直す必要はありません。」
    • ★★★ 「観点」がまだ画面に残っていました。 2026.08.255 で料金表を直したとき「観点は v21 で使うのをやめた呼び方で、画面のどこにも出てこない」と書きましたが、マイページに 2 か所ありました。 探したつもりで探せていませんでした。 「区分」に直しました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  61. 2026.08 第274版2026-08-29臨時改訂表現結果に影響なし

    推移の表だけ、0 / 0 を出していました

    • ★★★ 2026.08.213 で「0 / 0 は出さない。満点にも 0 点にも読めるので、— と『対象なし』を出す」と決めていました。 結果画面と見本には効かせたのに、推移の表だけ素通ししていて、実際に「代表 URL の指定が揃っている重複候補 0 / 0 組」と並んでいました。
    • ★★ 呼び方も 3 つ目を作っていました —— ここだけ「判定なし」。「判定していません」（測ろうとして観測できなかった）と「対象なし」（測った結果 0 個だった）は必ず書き分けると決めているので、その 2 つに揃えました。
    • ★ 検査を足しました —— この 3 画面が「対象なし」を出していること、「判定なし」を使っていないこと。コメントを外してから見ます（経緯を書いた文を「出している」と数えないため）。
    • 推移の表の列見出しに時刻を足しました（2026.08.273）。同じ日に 2 回測ると見出しが同じ日付になり、どちらが後か分かりませんでした。 並べて見比べる表なので致命的です。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  62. 2026.08 第272版2026-08-28臨時改訂表現結果に影響なし

    要約に時刻を入れ、解約したあとの状態を画面に出しました

    • ★★ 利用者の指摘 ——「要約の「実施日」を「実施日時」にして時刻まで記載したらどうだ。1 日に何度か行う場合もあり、サイト更新の日付と照合する手がかりにもなる」。そのとおりで、同じ日に 2 回測ったものを、貼られた側は区別できませんでした。 ★ これは社外へ貼られる唯一の文章なので、時間帯（JST）まで書きます。
    • ★★★ 解約したあとの状態を、利用者の画面に出していませんでした。 解約は請求期間の終了時に効くので、押した直後は何も変わりません。 画面が何も言わないと、解約できたのかが分かりません。
    • ★ 管理画面は 2026.08.117 で「次の請求」と「終了」を分けていたのに、利用者の画面には何も出していませんでした。 同じ区別が、必要な側に無かったわけです。「解約を受け付けています。◯月◯日 までご利用いただけます」と出します。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  63. 2026.08 第271版2026-08-28定期改訂表現結果に影響なし

    契約している人の画面に、やめ方がありませんでした

    • ★★★ 利用者の指摘 ——「解約ボタンは必要だ」。そのとおりでした。 規約は「contact@silve.jp へのご連絡で受け付けます」と書いており嘘ではありませんが、契約している方の画面に、やめ方が書いていませんでした。
    • マイページに「契約」の節を足しました —— 支払い方法の変更・請求書の確認・解約へ進めます。
    • ★★ 自前で解約の画面は作りません。 支払い方法の変更・請求書の履歴・解約は、決済代行の画面が正本です。こちらで作ると、決済側の状態と 2 つの答えができます。 ★ 解約そのものは webhook で受け取り、アカウントを無料の範囲へ戻します。画面は引き金を引くだけです。
    • ★ メールでの受け付けは閉じません。 規約に書いてある経路であり、画面が開けなかったときの行き先でもあります。開けなかった場合は、その旨とメールの宛先を出します。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  64. 2026.08 第270版2026-08-28臨時改訂表現結果に影響なし

    ログイン画面が、説明はあって道が無い状態でした

    • ★★★ 利用者の指摘 ——「新しいアカウントでログインしようとしたが、メッセージが届かない」。設計どおりの動作でした —— アカウントの無いアドレスへは送りません（送ると、届いたかどうかで契約者のアドレスを総当たりで数えられます。2026.08.74）。
    • ★★ 正しく動いていましたが、行き止まりでした。 「アカウントの新規作成は、お申し込みの手続きの中で行います」と書いてはあったのに、その手続きへの行き先がありませんでした。 説明はあって、道が無い。
    • ログイン画面と、送信後の画面の両方に行き先を置きました —— 「有料プランに申し込む」「料金と、無料で見られる範囲を確かめる」。★ 売っていないときは出しません（行き先の無い案内を作らない）。
    • ★★★ その実装で、黙って間違う書き方を 1 つ踏みかけました。 送信後の画面はクライアントで動く部品で、そこに sellingNow() を書いていました。STRIPE_SECRET_KEY はブラウザーへ渡らないので、必ず false になります。 型も既存の検査も通り、売っていても案内が出ません。
    • サーバー側の面で判定して値で渡す形に直し、検査も足しました —— "use client" の部品が sellingNow() を呼んでいたら落とします。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  65. 2026.08 第269版2026-08-28臨時改訂表現結果に影響なし

    本が「最新はサイトで」と書く先に、行き先がありませんでした

    • ★★★ 書籍との切り分けが決まりました。 本に固定するのは「何を測るサービスか」と、刊行時点のスナップショット。 受付中か・いくらか・何回か・1 回に見るページ数・支払方法・解約の条件は、変わるのでサイトへ逃がします。
    • ★★ 逃がした先に、行き先がありませんでした。 /book は本が刷る恒久 URL なのに、料金にも取引条件にもリンクがありませんでした。 「サイトで確認してほしい」と書いておいて、着いた先に無いのでは約束が守れません。
    • /book に「本に書いていないこと」の節を足しました —— 料金プラン・取引条件（特定商取引法に基づく表記）・利用規約への 3 つの行き先。何を書いていないかを先に言い、そのうえで行き先を出します。
    • ★ 同じ考え方は、この面で 2 回目です。 /book の「取得主体を用途で 3 つ」を、数を書かない形に直したのと同じ理由 —— 変わるものを固定しないこと。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  66. 2026.08 第268版2026-08-28臨時改訂表現結果に影響なし

    「まだ開始していません」を、門を通さずに書いていた画面が 2 つありました

    • ★★★ 書籍側の監査からの指摘 ——「トップと申込ページは受付中なのに、規約は受付前」。調べたところ、規約・料金表・申込ページは sellingNow() を見ていて正しく切り替わっており、食い違っていたのは別の 2 か所でした。
    • 無料の結果ページ（「有料での提供は、まだ開始していません。」）と、診断ページ（「有料プランはまだ開始していません。」）が、門を通さず、閉じている前提の文を直に書いていました。 開いた日に、この 2 画面だけ古いことを言い続けます。
    • ★★ 前の検査は「billingConfigured() を直に呼んでいないか」しか見ていませんでした。 呼びもせずに、答えを文字で書いてしまう形が抜けていました。検査を足しました —— 「まだ開始していません」の類を含む画面が sellingNow() を見ていなければ落とします。
    • ★ 判定は緩くしてあります —— 同じファイルのどこかで見ていればよい、としました。分岐の中にあるかまでは静的に追えないので、そこは人が書きます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  67. 2026.08 第267版2026-08-28臨時改訂表現結果に影響なし

    層を 3 つで並べていた文が、まだ 3 か所ありました

    • ★★★ 書籍側の監査で、同じ誤りを 3 度目に指摘されました。 「実行」は 2026.08.108 で足した層なのに、3 つのまま並べている文が残り続けていました。
    • 2026.08.241 で 7 段階の記事の表を直したとき、同じ記事のまとめの箇条書きを見ていませんでした ——「準備状態と可視性と成果は別物です」。同じ記事の中で、直した場所と直していない場所が分かれていました。
    • 探し直したところ、あと 2 か所ありました —— 効果検証の記事の関連リンクの説明と、判断基準を読む順番のページ。3 か所とも直しました。
    • ★★★ 検査を足しました ——「可視性 → 区切り → 成果」が直に続く文に「実行」が無ければ落とします。3 度も人が見つけているので、人が見つける形をやめます。
    • ★ 論じている文までは拾いません。 「準備状態ではシグナルを統合し、可視性では成果を分解する」は並びではありません（間に「では」が入ります）。そこまで拾うと、道具として使えなくなります。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  68. 2026.08 第266版2026-08-28臨時改訂表現結果に影響なし

    書籍側からの指摘で、記事末の旧い数値を直しました

    • ★★★ 7 段階の記事の「Current Coverage」が、加重和だった頃の重みのままでした —— 段階 1: 35 / 段階 2: 27 / 段階 3: 13 / 段階 4: 4 / 段階 7: 12。合計 91 です。「診断項目 10」と併記していたので、数として成立していませんでした。 同じ記事の上の表（発見 4・取得 4・行動 2）とも食い違っていました。
    • ★★ 2026.08.241 でこの記事の表は 3 層から 4 層へ直したのに、記事末の記録は見ていませんでした。 同じ記事の中でも、直した場所と直していない場所が分かれる。
    • 書籍ページの「取得主体を用途で 3 つに分ける整理」も直しました。 本は 4 つ（検索・表示 / 学習 / 外部参照 / ユーザー起点取得）で、クローラーの記事も 4 用途です。★ 数を書き直すのではなく、数を書かない形にしました —— 能力の分類はこの先も細かくなるので、数を固定するとまたずれます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  69. 2026.08 第265版2026-08-28定期改訂分類結果に影響なし

    有料プランの受け付けを開始しました

    • ★★★ 有料プランの申し込みを受け付けます。 月 4,980 円（税込）。診断 100 回／月、1 回につき最大 30 ページ。
    • 開ける前に、本番の鍵で設定を確認しました（/admin/stripe）—— 価格が active・通貨は jpy・金額 4,980 円が画面と一致・1 か月ごとの継続課金・税の扱いは内税で、画面の「税込」と一致・webhook は必要な 4 イベントを受け取る設定で enabled。
    • ★ これで確かめられるのは「設定が噛み合っているか」だけです。経路が動くかは、実際に 1 回購入するまで分かりません（前回、本番で払って初めて 2 件の欠陥が出ました）。この検査は、それを置き換えません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  70. 2026.08 第264版2026-08-28臨時改訂表現結果に影響なし

    決済の設定を、鍵のある場所で確かめられるようにしました

    • ★★★ 手元から本番の Stripe を確かめられないことが分かりました。 Vercel は機微な環境変数を書き出しません（vercel env pull が [SENSITIVE] を返します）。設計として正しい挙動で、持って来る道はありません。
    • 鍵があるのは本番のサーバーだけなので、そこで走らせる画面を作りました（/admin/stripe）。読むだけで、Stripe へは何も書き込みません。鍵の中身も表示しません（設定済みかと文字数だけ）。
    • ★ 判定は 1 か所です。 pnpm check:stripe も、管理画面も、同じものを読みます。同じ問いに 2 つの答えを作りません。
    • ★★★ その作業中に、規約が自分の版番号について食い違っているのを見つけました。 改定履歴は「第 1.4 版（2026年8月27日 施行）」なのに、文書の末尾は「第 1.3 版」でした。2026.08.247 で「シルヴェに尋ねる」を書き足したとき、定数を上げ忘れていました。
    • ★★ 利用者が同意するのは「この版」です。どの版に同意したのかが記録に残りません。 有料の開始を前に見つかりました。 直し、改定履歴のいちばん新しい版と一致しているかを機械で見張るようにしました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  71. 2026.08 第263版2026-08-28臨時改訂表現結果に影響なし

    狭い画面で「ログイン」を隠していました

    • ★★ 利用者の指摘 ——「スマホで縦に見るとヘッダーの「ログイン」が表示されない」。640px 未満で隠していました。
    • ★ 隠していた理由は「狭いから」でしたが、実際には入ります。 360px でも ロゴ 85 ＋ 間 16 ＋ ログイン 42 ＋ 間 16 ＋ ボタン 102 ＝ 261px で、左右の余白を引いた 320px に収まります（肩書きは大きな画面でしか出ません）。出します。
    • ★★ 「ボタンを隠して、ログインを優先する」案は採りませんでした。 ご指摘のとおりトップには下に大きな入力欄がありますが、記事や用語集にはありません。 そちらでヘッダーから診断へ行けなくなります。 入るなら両方出すのが、どのページでも成り立ちます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  72. 2026.08 第262版2026-08-28臨時改訂表現結果に影響なし

    区分のカードで、項目が 1 行ずつ並ぶようにしました

    • ★★ 利用者の指摘 ——「「提供元の推奨」だけ項目が 1 行ずつになっていない」。折り返しに任せていたので、短い名前どうし（「固有の title」と「代表 URL の指定」）が同じ行に並んでいました。
    • ★ 見出しが言っている項目数と、見えている行数を一致させます。 「4 項目」と書いてある区分で 3 行しか見えないのは、数えられない形です。
    • ★★ 比較表の「質問できる窓口」から回数を外しました。 利用者の指摘 ——「「月 300 回まで」は紛らわしい」。診断の回数（月 100 回）と並ぶ場所なので、別の枠が 2 つあるように読めます。 返答の作成回数は、有料プランの一覧の側に書いてあります。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  73. 2026.08 第261版2026-08-28臨時改訂表現結果に影響なし

    全ページの文章量を測り、2 か所を直しました

    • ★★★ 利用者の指摘 ——「サイト全体でテキスト量が多すぎる箇所を改めて全て確認しろ」。14 ページの本文を機械で測りました。
    • ★★★ いちばん重かったのは /checklist の「バージョン履歴」でした。開いた状態で 17,223 字あり、そのほとんどがこの節です（v18 の要約だけで 1,119 字）。版ごとに畳み、題と日付だけを畳んだ状態で読める形にしました。1 版も消していません。
    • ★★ 同じ問題を、隣の節では既に直していました。 2026.08.244 で変更履歴を版ごとに畳み、全履歴を /checklist/history へ移したのに、こちらは手つかずで残っていました。 原則を書いた場所と、効くべき場所がずれる —— この製品が繰り返し踏んでいる型です。
    • ★★ 「SILVEとは」に、1 段落へ 5 つの話を詰めた箇所がありました（294 字）—— 決定論・説明文も定型・AI 不使用・総合点なし・変動の内訳。どれも別の話なので行を分けました。文は削っていません。 診断の限界の段落（237 字）も 3 つに分けました。
    • ★ 直さなかったページも書いておきます。 用語集（8,387 字）とクローラー一覧（5,347 字）は、探しに来る場所です。畳むと、探している語を見つけるのに開いて回ることになり、かえって遠くなります。 記事一覧・利用規約・運営者情報も、量そのものが中身です。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  74. 2026.08 第260版2026-08-28臨時改訂表現結果に影響なし

    診断ページが、押す前に読ませすぎていました

    • ★★★ 利用者の指摘 ——「表記が面倒臭すぎる。こんなに長文を読んでまで無料体験したいと思うか。規約に書くか、トグルにして一度に公開しないのが普通だろ」。
    • ★★★ 測ったら、回数の説明だけで 319 字ありました。ページ本文の 3 割です。しかも、そのほとんどはこの 2 日で私が足したものでした（IP の数え方・共有・回線が変わったとき）。正確にしようとして、読ませる量を 3 倍にしていました。
    • 押す前に要るのは「何回使えるか」だけです。1 文だけ出し、「回数の数え方」を開けば読める形にしました。
    • ★★ 畳んでも消していません。 不利な事実（同じ回線の方が使った分も含まれる）を、開かないと読めない場所へ隠すのは、この製品がやらないと決めていることです。見出しを「回数の数え方」にして、開けば必ず読めるようにしました。
    • ★ 「1 ページだけ取得します」は 2 か所に書いていました。 フォームのすぐ下にもあるので、上の説明から外しました。
    • ★ リードから決定論の説明を外しました。 「同一の取得内容を同一の版の評価基準で評価すれば結果は同一」は、試すかどうかの判断材料ではありません。 消さずに、右の「適用される基準」へ移しました —— 版の話をしている場所が、この文の居場所です。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  75. 2026.08 第259版2026-08-28臨時改訂表現結果に影響なし

    比較表の太字をやめ、行を色で分けました

    • ★★★ 利用者の指摘 ——「また無料プランとの比較が読みづらくなっている。説明に太字を使うな。使うなら各項目に色をつけて独立して読めるようにしろ」。
    • ★★ 太字は説明の中で強弱をつける道具ですが、7 行ぶん並ぶと、どの行にも太い字があって、結局どこも目立ちません。 全部外しました。
    • ★★★ 代わりに行ごとの色を置きました。色に意味は持たせていません。 このサイトでは色は意味です（赤は「欠けると届かない」にしか使いません）。意味のある色をここで使うと、その規則と衝突します。 そこで 赤と緑は使わず、7 色の彩度と明度をそろえました —— 濃い色があると、その行だけ強く見え、強弱は順位に読まれます。
    • ★★ 「質問できる窓口」の説明を短くしました。 前の版で条件を全部書き込んで長くなっていました。詳しい条件は有料プランの一覧の側にあります。表は「何が増えるか」を見比べる場所なので、1 文で足ります。
    • ★★★ フッターに「書籍」が残っていました。 記事一覧では未発売のあいだ隠していた（2026.08.247）のに、フッターだけ出ていました。 同じ判断を 2 か所で別々に持っていたためです。発売までは出しません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  76. 2026.08 第258版2026-08-28臨時改訂根拠結果に影響なし

    無料の枠がヘッダーで回避できないかを確かめました

    • ★★ 前の版で「まだ確認していません」と書いた件です。無料の枠は x-forwarded-for の先頭を読んで数えているので、リクエストにこのヘッダーを付けるだけで回避できるのではないかという疑いがありました。
    • ★★★ できません。 提供元の資料に当たりました —— 「If you are trying to use Vercel behind a proxy, we currently overwrite the X-Forwarded-For header and do not forward external IPs. This restriction is in place to prevent IP spoofing.」（Vercel, Request headers。2026-08-28 確認）。受信した値は捨てられ、実際の接続元で上書きされます。
    • ★★ ただし「前に何かを置いた日」に変わります。 同じ資料に「Vercel の前にプロキシを置くと x-forwarded-for は上書きされ得る」とあります。silve.jp の DNS は Cloudflare ですが、A レコードは Vercel の IP を直に指しており、プロキシは通っていません（応答に cf-ray が無く server: Vercel。2026-08-28 実測）。これは DNS の画面で 1 クリックで変わります。
    • そのとき正しさを保つ x-vercel-forwarded-for を先に読むようにしました。 Vercel 以外へ移した日には無くなるヘッダーなので、従来の 2 つは後ろに残しています。
    • ★ 同じ読み方が 2 か所にありました（診断の枠と、シルヴェ通信の登録）。片方だけ直る形だったので、1 か所にまとめ、使い手の消えた部品は消しました。
    • ★ Enterprise の Trusted Proxy を買うと、この上書きをやめられます。 買った日に、先頭の値は利用者が決められるようになります。 買うならここも直す、とコードに残しました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  77. 2026.08 第257版2026-08-28臨時改訂表現結果に影響なし

    無料の枠について、厳しいほうだけを書いていました

    • ★★★ 利用者の質問 ——「ノート PC やスマホなら、移動すれば毎回 IP が変わるのでは」。変わります。回線が変われば、別の枠として数えます。
    • ★★★ 前の版で「履歴やキャッシュを消しても増えません」とだけ書いたのは、こちらの制御を実際より強く見せる書き方でした。 同じ事実の、利用者に不利な側だけを書いていたわけです。両方書きます。
    • ★★ 携帯回線では逆のことも起きます —— 多くの利用者が 1 つの IP を共有するので、一度も使っていない方の枠が減っていることがあります。
    • ★★★ この枠は、費用を止める仕組みではありません。 効いているのは別のところです —— 1 ページしか取得しない・生成 AI を使わない・同じドメインは 6 時間キャッシュする。 枠は「ここから先は名乗ってもらう」という線であって、技術的に固い制限ではありません。そう書きました。
    • ★★ ブラウザー側の数え方を足すことは、採りませんでした。 回線を変えるより、消すほうが簡単です。しかも足すと「消しても戻りません」が嘘になります。 弱い仕組みを増やして、説明を不正確にするほうが損です。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  78. 2026.08 第256版2026-08-28臨時改訂表現結果に影響なし

    無料の枠を「このブラウザーから」と書いていました

    • ★★★ 利用者の質問 ——「キャッシュをクリアしてしまえば毎回 3 回診断できる仕様か」。違います。そして、そう読める書き方をしていたのはこちらです。
    • 数えているのは接続元の IP アドレスです（AUTH_SECRET でハッシュ化して保存し、生の IP は保存しません）。ブラウザーには何も置いていません。 履歴やキャッシュを消しても、別のブラウザーでも、シークレットウィンドウでも、枠は戻りません。
    • ★★★ 逆向きの影響のほうが大きく、そちらをまったく書いていませんでした —— 同じ回線を使う人どうしは枠を共有します。 社内の別の方が実行していれば、その分が減っています。 「このブラウザーから」と書いているあいだ、この共有は伝わりません。
    • 3 か所を直しました —— 診断ボタンの下・診断ページの注記・上限に達したときの文言。上限の文言には「時間をおいても、ブラウザーの履歴やキャッシュを消しても増えません」を明記しました。
    • ★ 同じサイトを 6 時間以内に測り直した場合は枠を使いません（前回の結果を出すため）。利用者に有利な事実なのに、どこにも書いていませんでした。 診断ページに書きました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  79. 2026.08 第255版2026-08-28定期改訂表現結果に影響なし

    まだ持っていない人に、持っている人にしか見えない場所を案内していました

    • ★★★ 利用者の指摘 ——「「右下から質問すると」は雑すぎる。無料アカウントにはそのボタンが見えていないのでわかりづらい」。そのとおりです。 「シルヴェに尋ねる」は有料の範囲なので、買うかどうかを決めている人の画面には、その窓は出ていません。 場所ではなく、何であるかを書きます。
    • ★★ 上限も、この表に無いままでした。 「返答を作るのは 1 か月あたり ◯ 回まで」は別の一覧には書いてあったのに、買う判断をするこの表には無いという状態でした。買う前に知るべき数を、買ったあとの説明にだけ置かない。
    • ★★ 「観点ごとの内訳」と書いていました。 「観点」は v21 で使うのをやめた呼び方で、画面のどこにも出てきません。 いまの呼び方は「区分」です。
    • ★★ 「基準側の変動を混ぜずに」も、初めて読む人には通じません。 私たちが基準を新しくすることがある、という前提を先に書きました ——「私たちが基準を新しくしても、前回と同じ版で測り直せます」。
    • ★ 例の分母が何なのか書いていませんでした。 「代替テキストのある画像 0 / 31 → 24 / 31」の 31 だけを置くと、SILVE が決めた数のように読めます。 実際はそのサイトで見つかった画像の数です。
    • ★★★ 「プランは 1 つだけです」と書いた真下に、2 列の表を置いていました。 「無料はプランではなく、アカウントを持たなくても使える範囲のこと」という判断は、コードのコメントにしかありませんでした。 初めて読む人には矛盾に見えます。 画面に書きました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  80. 2026.08 第254版2026-08-28臨時改訂表現結果に影響なし

    面の飾りを、方眼と図案の 2 つで交互にしました

    • ★★ 利用者の指摘 ——「「診断の中身」を 3 列のカードにしたので、裏に置いているシルヴェの画像がほとんど見えなくなってしまった」。カードは白い面なので、後ろの絵を完全に塞ぎます。
    • ★★★ 眼は右、ロゴは左下で、もともと重ならない位置に決めてありました。 1 つに絞っていた理由は「::after の取り合いになる」という実装の都合だけでした。ロゴを ::before へ移して、同じ面に両方置けるようにしました。
    • これで、方眼の面と図案（眼＋ロゴ）の面が、上から下まで交互に並びます。 白い面には方眼、灰色の面には図案、という元の規則は変えていません。
    • ★ 飾りの濃さも変えていません（眼 0.09・ロゴ 0.035）。「言われるまで気づかない」濃さに留めるという上限のままです。背景が見えた時点で、読ませたい文字より強くなっています。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  81. 2026.08 第253版2026-08-28臨時改訂表現結果に影響なし

    値が無い行に、空のバーを描くのをやめました

    • ★★★ 利用者の指摘 ——「本物の診断結果のほうも、対象なしだった場合にバーのようなものが出る。ややこしいので、サンプルの書き方にそろえたらどうだ」。
    • ★★★ 出ていたのは空のバーの溝でした。値が無いのに 0% の絵だけが描かれていたわけです。「対象なし」（測った結果 0 個）も「判定していません」（観測できなかった）も、0% ではありません。 0% に見える絵を置きません。
    • 数字とバーの場所に、言葉を 1 つ置きます —— 対象なし 代表 URL の指定 / 判定していません ◯◯。項目名の後ろにも出していた注記は、消しました（同じことを 2 か所に書かない）。項目名も薄くします —— 測れた行と同じ濃さで並べません。
    • ★★ 見本と結果画面で、同じ部品を使うようにしました。 前の版では見本だけ自前で描いており、幅を目分量で書いたので項目名の始まる位置がずれていました。 同じものは同じ形で出します。
    • ★ 幅は計算で合わせます —— 数字の幅 ＋ バーの幅 ＋ その間の余白。 呼ぶ側の余白が見本は 8px、結果画面は 10px と違うので、それも渡します。 ここを間違えると、値の無い行だけ項目名が数 px ずれます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  82. 2026.08 第252版2026-08-28臨時改訂表現結果に影響なし

    見本の並びが、正本と 1 つずれていました

    • ★★★ 利用者の指摘 ——「代表 URL の指定が、見本では 4 番目、サイト内の他では 3 番目に出ている。この順番に意図はあるのか」。
    • 意図はあります。 区分の順は「到達・利用の条件 → 提供元の推奨 → エージェント対応」、区分の中は observations.ts の宣言順です。metricId のアルファベット順にすると「本文が取れるか → robots.txt を通るか」と読む順序が逆になるため、宣言順を正本にしています。
    • ★ ずれていたのは見本のほうでした。 前の版で 2 行足したとき、手で挿し込んだ位置が 1 つ後ろでした。正本どおりに直しました。
    • ★★ 「対象なしになりやすい項目を下へ送る」形にはしません。 どの項目が対象なしになるかは、そのサイトによって変わります。 そして 固定した順序でないと、2 回の診断を行ごとに見比べられません —— 測り直しはこの製品の売りです。 順序は読む順序であって、結果で動かすものではありません。
    • 検査を足しました —— 見本の並びが正本と一致していること。2 行を入れ替えると落ちることを確認済みです。
    • ★ トップの区分カードも、正本の順で並べ直しました。 版の項目は「重み降順 → metricId 昇順」で並ぶので、観測モデル（重みが全部 0）では実質アルファベット順になります。いまはたまたま一致していましたが、項目が 1 つ増えた日にここだけ別の順になります。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  83. 2026.08 第251版2026-08-28臨時改訂表現結果に影響なし

    「対象なし」の行が、見本の中で崩れていました

    • ★★★ 利用者の指摘 ——「対象なしの場合に表示が崩れている」。崩れていました。
    • ★★★ 同じ間違いが、この製品の記録に既にありました。 2026.08.216 ——「注記を項目名と同じ箱に入れていたら、truncate に食われて「判定…」で切れていた」。前の版で、私はそれをそのまま繰り返しました。
    • 幅を測りました。 この区分の列は 210px。数字 44.8 ＋ 間隔 8 ＋ バー 20 ＋ 間隔 8 = 81 を引いて、項目名に残るのは 129px。「ラベルのある入力欄」が実測 99px なので、「対象なし」を後ろに足すと 143px になり、14px はみ出します。
    • ★ 言葉を、数字の場所へ置きました。 — の代わりであって、実物より強いことは言っていません。バーの場所は空けたままにして、項目名の始まる位置が他の行とずれないようにしています。
    • ★ 結果画面のほうは変えていません。 あちらは列が広く、— ＋ 後ろに注記で収まっています。狭いほうだけ、置き場所を変えました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  84. 2026.08 第250版2026-08-28定期改訂表現結果に影響なし

    トップの見本が、10 項目のうち 8 項目しか出していませんでした

    • ★★★ 利用者の指摘 ——「結果に出ている「— 代表 URL の指定 対象なし」は何だ。LP のサンプルには出ていない項目だが、必要なのか」。必要です。そして、それを出すようにした理由も同じ方の指摘でした ——「区分の見出しが「4 項目」と言っているのに 3 行しか出ない」（2026.08.213）。いま消すと、その食い違いが戻ります。
    • ★★★ 食い違っていたのは見本のほうでした。 見本は 10 項目のうち 8 項目しか出しておらず、抜けていた 2 つが、まさに「対象なし」になりやすい 2 つでした（重複候補 0 組・入力欄 0 個）。その結果、見本には「対象なし」という状態が一度も出てきません。 実物で初めて — を見た人には、何のことか分かりません。
    • 見本を 10 行にしました。 うち 2 例で「対象なし」を出しています（0 / 0 は出しません —— 満点にも 0 点にも読めます）。
    • ★★ 前の版で足した検査は、これを捕まえられませんでした。 「見本の項目名が現行の版に存在するか」は見ていましたが、「現行の項目を網羅しているか」を見ていませんでした。入っているものは調べて、入っていないものを調べていなかった。 検査を足しました。
    • ★ 説明文を短くし、切り替えの間隔を伸ばしました（6.0 秒 → 7.5 秒）。利用者の指摘 ——「現在の切り替えのペースでは最後まで読めないテキスト量だ」。3 例とも 60 字以内にしました。行も 8 から 10 に増えています。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  85. 2026.08 第249版2026-08-28定期改訂表現結果に影響なし

    社内共有用の要約が、やることを「できている側」で書いていました

    • ★★★ 利用者の指摘 ——「この位置で合っているか。もっと見やすくできるはず」。位置は合っていました。書き方が逆でした。
    • やることの一覧なのに、出していたのは「できている側の名前」と「できている割合」でした —— ・代替テキストのある画像（26%（176 / 659 枚））。26% が良いのか悪いのかを、読む人が頭の中で反転させていました。 足りない側で書きます —— 代替テキストがない画像 22 枚（対象 30 枚 / 満たしているのは 26%）。
    • ★ 括弧が二重になっていました。 数を組み立てる関数が 100%（2 / 2 ページ） を返すのに、呼ぶ側がもう一度括っていました。 3 か所直しました。
    • ★★ 区分が消えていました。 着手コスト（今すぐ / 計画して / 中長期）だけで並べていたので、「到達・利用の条件」と「提供元の推奨」と「エージェント対応」が同じ見た目で混ざっていました。 どれを先に手当てすべきかが、この一覧からは分かりませんでした。 各行に区分を書きます。
    • ★★★ 同じ長い文を 2 回貼っていました。 到達・利用の条件は上の節で直し方まで全部書いてあるのに、着手コストの一覧でも「直す場所」の段落をまるごと再掲していました。貼られた先で読むのは人で、同じ段落が 2 度出てくると、違うことが書いてあるのかと読み返させます。 2 度目は「上に書いています」に変えました。
    • 節の順番も直しました。 「この診断について」という説明が、やることの一覧の途中に挟まっていました。 やることを最後まで並べてから、説明を置きます。
    • ★ これはそのまま社内へ貼るテキストです。 貼られた先には、数字の意味を説明する人がいません。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  86. 2026.08 第248版2026-08-28定期改訂表現結果に影響なし

    待っているあいだ、何をしているかを出すようにしました

    • ★★★ これまでは点が 1 つ点滅するだけでした。 この製品の中身は「生成 AI ではなく、コードが決定論的に検査している」ことなのに、待っているあいだの画面が、それを何も言っていませんでした。 工程を出すようにしました —— robots.txt を読む / 入力されたページを取得する / サイト内のページを取得する / 取得したページから項目を数える / 判定する。
    • ★★★ 時間で進めていません。 秒数で ✓ を付けていく実装にはしませんでした。 それは観測していないことを、観測したように書くことであり、この製品が繰り返し潰してきた型そのものです。実行側が、実際にその工程へ入ったときに書いた値だけを読んでいます。
    • ★ 無料と有料で仕組みは同じです。 どちらも同じ待ち行列を通り、同じ部品で描いています。違うのは「サイト内のページを取得」を通るかどうかだけで、無料は 1 ページなので、追加ページの取得そのものが起きません。 そのため無料では、その行を最初から出しません。起きない工程を、灰色で置いて待たせません。
    • 「診断の中身」の 3 区分を、並びの行からカードにしました。 ★ 文章は増やしていません。足したのは項目名だけで、それも正本から引いています。数（4 / 4 / 2）の隣に名前が並ぶと、説明文を読まなくても中身が分かります。
    • トップの余白を広げました（節の上下 112px → 144px ほか）。情報量の多い画面ほど、余白を削ると古く見えます。
    • ★ 外部レビューの提案のうち、採らなかったものがあります。 トップに架空ドメインの「診断デモ」を動かす案は採りません —— 見本が「その URL では出ない数字」を出していた事故を直したばかりで、架空のサイトに対して取得を演じることになります。 同じ効果は、実物の進行表示で嘘なしに得られます。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  87. 2026.08 第247版2026-08-28定期改訂表現分類結果に影響なし

    「現在測っているのは」を、正本から出すようにしました

    • ★★★ 記事が現在形で並べた項目名が、正本と離れていました。 2026.08.241 で 3 件直しましたが、直し方が「手で書き直す」だったので、次に項目を動かした日にまた古くなります。
    • ★★ 実際、その訂正自体が間違っていました。 エージェント対応の記事に「内部リンクが辿れる形で書かれているか」を足しましたが、この項目は実在するものの、区分が違います —— エージェント対応ではなく「提供元が推奨する実装」の側です。廃止した項目を書くのと、実在する項目を違う区分に置くのは別の誤りですが、読者にとっては同じこと（この区分に無いものが、あると書いてある）です。
    • そこで、変わると事実誤認になる少数の値だけを、正本から解決する記法にしました —— 現行の版番号・項目数・区分ごとの項目数と一覧・無料と有料のページ数・無料で詳細を出す項目数・見ている AI 検索クローラーの数。項目を動かした日に、記事だけが古くなることはありません。
    • ★ 本文を記法だらけにはしません。 読みにくくなり、実装と強く結びつきます。 文章は普通のマークダウンのままです。
    • ★★★ 過去を説明している文では使いません。 「v21 では 15 項目だった」は変わらない事実なので手で書きます。 ここに現在の値を解決する記法を置くと、過去の記述が、あとから勝手に現在の数へ書き換わります。 それは「公開した版は書き換えない」という約束と正面から衝突します。 検査が、過去を語る行での使用を落とします。
    • ★★ 記事の数の検査を二段にしました。 自然言語だけを解析して「10 項目と書いてあるが本当は 12」を完全に検出しようとすると、いずれ限界が来ます。 落とすのは構造の検査だけ（解決できない名前・過去の文での使用）。現在形の文にある手書きの数は、落とさずに人へ上げます。
    • ★ 黙らせ方も用意しました。理由つきで。 消えない警告は読まれなくなります。 正本の無い数（その記事の中の表から導いた割り当てなど）は、「手で書いた。理由はこれ」と書けば黙ります。理由を書かせるので、黙らせること自体が記録になります。
    • 記事一覧に、問いから入る導線を足しました ——「いま直せることを知りたい」「測り方の考え方を知りたい」「AI にどう見えているかを測りたい」「施策の効果を確かめたい」「診断していない領域を知りたい」。タグは詳しい人には便利ですが、初見の人は GEO / AIO / AIEO / AAO / LLMO の違いがまだ分かっていません。 ★ 新しい分類は作っていません。 前の版で記事に付けた 3 軸から導いており、入口なので重なってよいことにしています。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  88. 2026.08 第246版2026-08-28定期改訂分類結果に影響なし

    記事に「SILVE との関係」を出しました

    • ★★★ 「記事になった ＝ 診断項目」と読まれていました。 記事には診断項目の根拠・診断対象外・まだ採用していないものが混ざっており、読めば区別できますが、読まないと分かりません。 preferred-sources（提供元自身が「必須ではない」と書いているもの）が、この表示の必要性をそのまま証明していました。
    • ★★★ 最初の案は 1 本の分類でした。それは「関係」「採否」「レイヤー」「記事のジャンル」を 1 つに潰しています。 潰すと、分類が増えるたびに値が増え続けます。 単位の違うものを 1 つにまとめないという、この製品が繰り返し使ってきた規律が、メタデータの設計にも当てはまりました。
    • 3 つに分けました —— 関係（現行項目の根拠 / 現行項目の運用・解釈 / 測り方そのもの / 診断対象外）、採否（現行 / 過去に採用 / 監視中 / 該当なし）、レイヤー（準備状態 / 可視性 / 実行 / 成果 / 横断）。
    • ★★ 「監視中」は関係ではなく採否でした。 一度採用して外したもの（エンティティ・新しさ・構造化データ）と、まだ一度も採用していないもの（llms.txt・ACO）は違います。1 つの値では区別できません。
    • ★ 記事のジャンル（用語 / 調査 / 解説）はここに入れません。 カテゴリとタグの仕事です。
    • 画面に出すのは「関係」だけです。採否は「過去に採用」「監視中」のときだけ小さく添え、レイヤーは出しません（分類としては持ちます）。
    • ★★ AAO だけ、割り当てを変えました。 「エージェント対応の実装根拠として使う」と記事自身が書いていますが、題材が近いことと、現行項目の根拠を担っていることは別です。agent.control_names の根拠は web.dev で、それを扱っているのは agent-readiness の記事です。AAO の実装節は、現行に無い項目（レイアウト安定性）も並べています。 「測り方そのもの」に置きました。
    • ★★ 「実行」のレイヤーが付いた記事は 1 本もありません。これは埋め忘れではありません。 SILVE が測っているのは「実行の準備状態」であって、実行そのものではないからです（測定モデルの記事自身がそう書いています）。分類にある値へ、必ず 1 本以上を割り当てなければならない理由はありません。
    • 検査を足しました —— 記事が 1 本増えたら、関係を決めなければ通りません。 書き忘れると、その記事だけ表示が出ず、読者は「関係が薄いのだろう」と読みます。黙って弱い主張になります。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  89. 2026.08 第245版2026-08-28臨時改訂表現結果に影響なし

    前の版の「機械の誤読を塞いだ」は、言い過ぎでした

    • ★★★ 前の版で「検索や生成 AI が現在の主張として引くことだけを止めます」と書きました。言い過ぎです。
    • data-nosnippet も noindex も、Google が定めて Google が処理する指定です。Google 自身が、他の検索エンジンは noindex を違う形で解釈し得ると明記しています。 全 AI・全クローラーに効く「これは歴史資料です」という普遍の指定は、存在しません。
    • ★★ 正しくは「Google 検索と Google の AI 機能で、履歴が現在の回答材料になる可能性を大きく下げました。ほかの AI にも同じ制御が効くとは扱いません」です。プラットフォーム固有の仕様を他プラットフォームへ一般化しない（CLAUDE_METHOD.md §5）—— 前の版で用語集のこの誤りを直しながら、同じ版の変更履歴で自分が同じことをしていました。
    • ★ 公開した版は書き換えないので、新しい版として出します。 前の版の記述はそのまま残ります。
    • 無料診断のボタンの下を入れ替えました。 制約が 4 つ並び、無料で何が見えるかが 1 つも無い状態でした。押すかどうかを決める瞬間に知りたいのは後者です。robots.txt を尊重 を外し（FAQ と「SILVEとは」に同じ記述があります）、代わりに「全 10 項目の観測値を表示。うち 4 項目は理由・該当箇所・直し方まで無料です」を置きました。行は増やしていません。
    • 記事一覧のタグを、狭い画面で畳むようにしました。 カードのタグは 5 個から 3 個 ＋ 残数へ。24 個のタグは、GEO / AIO / AIEO / AAO / LLMO の違いがまだ分かっていない人には塊にしか見えません。 PC では畳みません。
    • ★ <details> の開閉を画面幅から CSS で作るのはやめました。 閉じた <details> の中身を隠しているのはブラウザー側の指定で、上書きの効き方がブラウザーごとに違います。 同じ一覧を 2 回書くほうが確実です。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  90. 2026.08 第244版2026-08-28定期改訂表現分類結果に影響なし

    過去の版が、現在の主張として検索に拾われていました

    • ★★★ 外部レビューが、実際に検索して見つけた問題です。 /checklist 1 ページに、現行の 10 項目と 150 版を超える履歴が同居していました。 その結果、検索結果が「後に訂正した記述」や「廃止した採点方式の文章」を、現在の主張として抜き出していました。
    • ★★★ 監査できるように過去を残したことが、過去を現在として引用させていた —— AI 検索を扱う製品として、いちばん皮肉な形の事故です。
    • ★★ 「公開した版を書き換えない」と「古い版を現在の回答材料にしない」は両立します。 履歴は 1 件も減らしていません。 変えたのは置き場所と、これが現在ではないと機械に伝える印です。全履歴は /checklist/history へ移し、/checklist には直近 5 版を残しました。
    • 履歴の本文に data-nosnippet を付けました —— Google は、ページの一部をスニペットの材料から外す指定として公式に認めています。人には見せたまま、検索や生成 AI が現在の主張として引くことだけを止めます。
    • 履歴のページと、/checklist の履歴の節の冒頭に、状態を書きました ——「履歴資料です。現在の仕様ではありません。」。訂正した記述も、廃止した数え方の説明も、当時のまま残しています。
    • ★★★ 用語集の「クロール」と「インデックス」が、記事より強い言い方をしていました。 クロールは「取りに来られなければ、そのページは存在しないものとして扱われます」でしたが、取得できないことと、認識されないことは違います。 OpenAI は、OAI-SearchBot を拒否していても、別の経路で知った URL のリンクと題名を出すことがあると明記しています。
    • ★★★ インデックスは「ここに入っていないページは検索結果にも AI の回答にも出てきません」でした。これは Google 検索固有の話を、AI 全体へ広げたものです。 CLAUDE_METHOD.md §5「プラットフォーム固有の仕様を他プラットフォームへ一般化しない」が禁じている形そのものを、用語集だけが守れていませんでした。
    • ★★ 用語集は短いぶん、記事より強く読者の頭の中の型を決めます。そして短さのために、いちばん但し書きが落ちやすい。 検査を足しました —— 結果を言い切っている説明文に、提供元の名前も、範囲を限る言葉も無ければ落とします。 ★ 強い言い方そのものは禁じません（「半減期は打ち切り線ではありません」は語の意味を狭める文で、一般化の逆です）。求めるのは「誰について言っているか」か「どこまで言えるか」のどちらかです。
    • 「SILVEとは」の「3 つの層を循環させる」を「3 つの原則」に直しました。 層は準備状態 / 可視性 / 実行 / 成果の 4 つに使っている語で、同じ専門語を 2 種類の分類に使う必要はありません。
    • 診断基準の冒頭を、入場条件の現在の言い方に合わせました ——「何個中何個で数えるか」から「測ろうとしている状態に対応する、実在する母集団の中で何個中何個か。分母を私たちが便宜的に作ることはしません」へ。2026.08.231 で条件を精密にしたとき、正本だけを直していました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  91. 2026.08 第242版2026-08-28定期改訂表現結果に影響なし

    前の版で見つかった 3 つの事故を、それぞれ機械検査にしました

    • ★★★ 前の版でいちばん重かったのは、廃止した語彙が 45 箇所残っていたことではありませんでした。 記事が「現在測っているのは…」として、現行に存在しない 3 項目を並べていたことです。語彙は古いだけですが、こちらは存在しないものを商品説明にしています。 検査はこれまで「禁止した語が出てくるか」には強く、「いまの姿として並べた名前が、実際にいまあるか」を見ていませんでした。
    • そこで検査を 3 つ足しました。いずれも、前の版で実際に起きた事故を回帰テストにしてあります。
    • ★★ ① 公開している記事から、下書きの記事へリンクしていないか。 内部リンクの検査はファイルの有無しか見ておらず、公開記事から下書きへのリンクを素通ししていました（実際に張りかけて、PASS しました）。読者には 404 になります。下書き同士は通します。 ★ 公開状態は DB にしかなく、CI に DB はありません。 取り込みのたびに写しを書き出し、DATABASE_URL があるときは DB と突き合わせて、写しの古さも落とすようにしました。
    • ★★★ ② トップの「表示例」が、実際に出得る結果になっているか。 前の版で直した「/r/…（必ず 1 ページ）の画面に、30 ページを測った数字」は、文言の検査では防げません。URL も数字も、それ単体では正しく、組み合わせだけが不可能だったからです。見本に「どの申し込み方の結果か」を持たせ、URL はそこから導く形にしました。手書きの URL を置ける場所を無くしています。
    • 同じ検査で、見本の項目名が現行のチェックリストにあるか・区分が実際と一致しているか・分母が上限を超えていないかも見ます。
    • ★★ ③ 「いま測っているのは A・B・C」に、廃止した項目が混ざっていないか。 ★ 名前を見つけたら落とす、ではありません。 記事は廃止した項目を話題として扱ってよい（llms.txt の記事は llms.txt の話をします）。落とすのは、現在形の主張として書いている文の中にあるときだけです。凍結した変更履歴と公開済みの版は見ません —— 書き換えないと決めている場所を、検査に書き換えさせないためです。
    • ★★★ その作業中に、CI が 5 回連続で落ちていたことが分かりました。 2026.08.247 の実装以降、Typecheck & lint がずっと赤でした（require() スタイルの import 1 行）。「検査が素通しすると、書いた人は通ったから大丈夫と読む」と自分で書いておきながら、赤いまま 5 回 push していました。 直しました。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  92. 2026.08 第241版2026-08-27定期改訂表現結果に影響なし

    廃止した語彙と、古い項目一覧を記事本文から外しました

    • ★★★ 外部レビューの指摘。v26 と同じ問題が、直していない場所に残っていました。 v26 ではチェックリストの項目説明から「配点」「採点」「減点」「満点」を外しました。しかし記事本文は一度も見ていませんでした。 数えたところ、SILVE 自身を主語にした採点の語が 45 箇所ありました。
    • ★★ 「SILVE は WebMCP を採点しません」は、書いた時点では正しい文でした。 v22 で総合スコアを廃止したあとは、読んだ人に「では他は採点しているのか」と受け取らせる文になっています。否定形でも、前提のほうは残ります。
    • 一括置換はしていません。 残した語もあります —— 他社の診断ツールを批判している箇所（「llms.txt なし = −10 点と大きく減点するのは、根拠より強い評価です」）と、日付つきの当時の記録です。当時そう書いてあったことは事実なので、記録は書き換えません。 代わりに「この節の語は当時の言い方です」という注記を足しました。
    • ★★★ 語彙だけの問題ではありませんでした。ここでも v26 と同じです。 エージェント対応の記事が「現在採点しているのは、操作要素の名前・フォームのラベル・レイアウト安定性の代理指標・JavaScript 非依存・内部リンク・連絡手段の機械可読性」と書いていました。このうち 3 つは、現行のチェックリストに無い項目です。 項目を外したときに、記事を直していませんでした。測定モデルの記事にも「レイアウトの安定性」が残っていました。
    • ★★ 7 段階の記事が、レイヤーを 3 つのままにしていました。 「実行」は 2026.08.108 で足した層で、同じ記事の 16 行下も、記事末のまとめも、参照先の記事の題も、当時から 4 つになっています。表だけが取り残されていました。
    • ★★ 料金表が、自分で書いた注意書きを同じ行で破っていました。 題は「基準上の改善を確かめられる」と正しく書きながら、本文が「実際に良くなった」でした。測っているのはサイト側が変わったかまでで、良し悪しは成果の言葉です。
    • ★★★ トップの見本が、出るはずのない数字を出していました。 アドレスバーが silve.jp/r/…（無料の簡易診断。必ず 1 ページ）なのに、中身は 30 ページを測った数字（title 28/30）でした。アドレスバーのほうを、30 ページを測る側へ合わせました。
    • ★ 用語集の OAI-SearchBot が、記事より強い言い方をしていました。 「拒否すると ChatGPT の検索回答に出なくなります」で止めていましたが、提供元は同じ箇所で「ナビゲーションリンクとしては現れ得る」と明記しています。記事側は但し書きを持っていたのに、用語集だけ落としていました。
    • ★ llms.txt の記事が「robots.txt はアクセス制御」と書いていました。 規格自身が These rules are not a form of access authorization. と明記しており、表明と遮断を分ける節を別の記事に立てておきながら、ここだけ古い言い方が残っていました。
    • ★ 「SILVEとは」が「同じサイトなら毎回同じページを選びます」と書いていました。 並べ方に乱数が無いことと、毎回同じ結果になることは別です。 辿れる内部リンクも、取得に成功するページも、その時々で変わり得ます。「取得できたページが同じなら、選ばれるページも同じです」に直しました。
    • 記事冒頭の版番号の説明を直しました。 「その訂正を行った判断基準の版」が /methodology（読む順番のページ）を指しており、番号の一覧が載っていない場所へ送っていました。 変更履歴のある /checklist#changelog へ変え、「診断項目の版（v26）とは別の番号です」を添えました（22 本）。
    • 測る内容は変わりません。同一の取得内容を同一の版の評価基準で評価すれば、結果は同一です。
  93. 2026.08 第240版2026-08-27定期改訂表現結果に影響なし

    「伝わっていない実体」の 12 行の打ち切りをやめました

    • ★★★ 利用者の指摘 ——「調べたサイトに問題があったらその理由は全て知りたい」。そのとおりです。 該当箇所の一覧を、検出の時点で 12 行に打ち切って保存しており、切った側はどこにも残っていませんでした。
    • ★★ 測ったところ、心配は要りませんでした。 この一覧はすべてページ単位で作っています（画像なら「/news.html（3 枚・対象 12 枚）」）。したがって行数は、多くても診断したページ数を超えません。 有料は最大 30 ページなので、一覧は最大 30 行です。12 で切っていたのは、30 行を 12 行にしていただけでした。
    • ★ ページ数を減らす案も検討しましたが、採りませんでした。 「30 ページではなく 10 ページに戻す代わりに全件」という考え方でしたが、一覧がページ単位である以上、見る範囲を狭めなくても全件にできます。 交換関係にありませんでした。
    • ★★ 残る打ち切りは、黙って切らない形にしました。 操作要素と入力欄の実例だけは、取得の時点で 1 ページあたり上限があります（数そのものは全部数えています）。上限を 5 件から 25 件へ上げ、それでも切れたときは「ほか ◯ 個（実例は 1 ページあたり 25 件まで残しています）」と一覧に出します。
    • 実測（4 サイト・12 ページ）では、名前の無い操作要素もラベルの無い入力欄も 0〜1 件で、上限に届いていませんでした。
    • ★★★ その測定中に、自分のサイトが自分の診断項目に引っかかっているのを見つけました。 記事一覧と用語集の検索欄が placeholder しか持っておらず、ラベルがありませんでした。 私たちは直し方に「placeholder だけではラベルになりません」と書いています。自分の基準を自分に当てていませんでした。 直しました。
    • 書き出しの前書きも直しました。 「先頭 12 行までで、残りは『ほか N 件』」という説明は、もう事実ではありません。
  94. 2026.08 第239版2026-08-27定期改訂表現結果に影響なし

    「誰が直せるか」を、手順の前に置きました

    • ★★★ 直し方を数えたところ、10 項目のうち 3 項目は、言葉を易しくしても非専門者には直せないと分かりました —— テンプレートを編集する権限も、CDN の管理画面も無いからです。「分かりやすく書く」で解決する種類の問題ではありませんでした。
    • ★★ 読む人は「直す人」とは限りません。 私たちは「SILVEとは」に「改修には稟議が要り、上長や他部署に説明できる根拠が求められます」「兼任で Web を見ている方が多く」と書いています。その方に要るのは技術の説明ではなく、誰に渡せばよいかです。
    • そこで、手順の前に「直す場所」を置きました。 「編集画面で直せることが多い」「設定か、テンプレートの編集」「テンプレートやサーバの編集が要る」の 3 つに分け、どこを見ればよいかを 1〜2 文で書いています。
    • 10 項目のうち、編集画面で直せることが多いのは 2 項目（ページごとの title・画像の代替テキスト）、設定かテンプレートが 5 項目、テンプレートやサーバの編集が要るのが 3 項目です。
    • ★★ 断定はしません。 そのサイトが何で作られているかを、私たちは観測していません。 したがって「CMS の設定で直せます」とは書けず、「多くの場合」「見当たらなければ」の形にしています。観測していないことを、観測したように書きません。
    • 検査を足しました —— 全項目に「直す場所」があること、どこを直すのかに答えていること、サイトの作りを断定していないこと。わざと断定させて、落ちることを確認済みです。
    • 売り文句も揃えました。 「なぜその結果になったのか、どこが該当するのか、誰がどう直すか」。実装だけ増やして、売り文句を古いままにしません。
    • 測る内容は変わりません。
  95. 2026.08 第238版2026-08-27定期改訂表現結果に影響なし

    記事の分類だけ、ファイル側で決められませんでした

    • ★★★ 記事の分類を管理画面で変えると、次の取り込みが止まる状態でした。 題・本文・説明文・タグはファイルが正本で取り込みのたびに上書きされますが、分類だけは取り込みの手順に直接書かれており、DB 側が違う分類だと例外で取り込み全体が失敗していました。直す場所がファイルに無いので、直しようがありませんでした。
    • 分類もファイル側で宣言できるようにしました。 省略したときは、これまでどおり「AEO / GEO / LLMO 解説」です。
    • ★ 食い違ったときの扱いを、本文と揃えました。 例外で全体を止めるのをやめ、警告を出してファイルの内容で上書きします（本文が食い違ったときと同じ形）。用語集の記事と slug がぶつかったときだけは、これまでどおり止めます —— 別系統の記事を壊すためです。
    • ★★ いま分類を変える記事はありません。 「最新ニュース・動向」「実践Tips」などの分類は中身が 0 本のままで、画面にも出していません。 その分類の記事を書くと決めてから使います。器を先に飾りません。
    • 測る内容は変わりません。
  96. 2026.08 第237版2026-08-27定期改訂根拠表現結果に影響なし

    「直したあと、すぐには反映されません」を根拠のある範囲で書きました

    • 直前の版で保留にした宿題です。 反映の時間差を書いていたのは「AI 検索クローラーの許可状況」だけでしたが、未確認のまま他の項目へ広げないとしていました。一次資料に当たりました。
    • ★★★ 提供元がはっきり書いていました。 「We have to crawl your page in order to see <meta> tags and HTTP headers.」「Depending on the importance of the page on the internet, it may take months for Googlebot to revisit a page.」（Google Search Central）。ページの重要度によっては、再訪までに数か月かかることがあるという記述です。
    • ★★ robots.txt とは桁が違います。 robots.txt のキャッシュは通常 24 時間までですが、ページ側の指定は、そのページを取得し直してもらうまで見えません。 「インデックスの禁止」と「AI への直接入力の禁止」の手順に、この段を足しました。
    • ★ 代表 URL の指定と title には書いていません。 同じ趣旨の記述を、それぞれの資料で確認できなかったためです。確認できていないことを、確認できた項目からの類推で書きません。
    • あわせて、この 2 項目の手順も段に分けました。 1 つの段落に 4〜5 つの話が入っていました。
    • 測る内容は変わりません。
  97. 2026.08 第236版2026-08-27定期改訂表現結果に影響なし

    10 項目の「直し方」を総点検し、3 件直しました

    • robots.txt の記事で見つけた観点（見えている場所と、直す場所は違う／観測が正しいことは、手順が正しいことを保証しない）を、10 項目すべての手順に当て直しました。
    • ★★★ 数えていないものを、直せと指示していました。 「ページごとの title」の説明には「meta description は観測として出しますが、診断項目にはしていません」と書いてあるのに、手順は「title と meta description を設定してください」でした。数えていないものを直しても、数字は動きません。 手順から外し、なぜ数えていないかを書く形にしました。
    • ★★★ 原因を断定していました。 「取得の安定性」の手順は「403 ならクローラーの遮断設定が原因です」でしたが、断定できません。 私たち自身が踏んでいます —— 週次バッチが 403 で落ちたとき、前日は同じ User-Agent で 200 でした。違いはリクエストの出どころでした。WAF は User-Agent と IP で挙動を変えます。
    • ★★ どこを見るかも書いていませんでした。 遮断は前面の CDN や WAF にあることが多く、オリジンのアプリからは見えません。 「どこが返しているか」を切り分ける段を足し、SILVE が 403 を受けたことは各社も 403 を受ける証拠にならないことも書きました。
    • ★★ 同じ制御面なのに、片方にしか注意書きがありませんでした。 「テンプレートや CMS の設定で全ページに入っていることがあります」を noindex にだけ書いており、同じ robots メタタグの「AI への直接入力の禁止」には無い状態でした。揃えました。
    • ★★ この型は 2 度目なので、検査を足しました。 説明が「これは見ていない」と名指ししている語を、手順が指示していないかを見ます。わざと壊して、実際に落ちることを確認済みです。
    • 測る内容は変わりません。 数え方も区分も判定も同じで、変えたのは手順の書き方だけです。
  98. 2026.08 第234版2026-08-27定期改訂表現結果に影響なし

    「効果」という語を、因果の話にだけ残しました

    • ★★ 外部レビューの指摘です。 優先ソースの記事で、提供元が説明している表示の変わり方を「効果」と書いていました。同じ記事の後半では「2 倍」について『算出方法が不明なので因果効果とは扱わない』と厳密に書いています。 前半だけ「効果」と呼ぶと、提供元が明記した表示の変化を、私たちが因果効果として確認したものと読まれます。 「表示上の変化」に改めました。
    • ★ 残した「効果」は、すべて『効果として扱わない』と述べている側だけです。
    • 副題を精密にしました。 「読者が選ぶものと、機械に伝わるものは別」としていましたが、読者が選んだ設定も提供元のシステムには伝わり、表示に使われます。 記事が言っているのは「読者が選ぶための導線」と「サイトがページの内容を機械へ伝える情報」の違いなので、そのとおりに書き直しました。
    • 測る内容は変わりません。
  99. 2026.08 第233版2026-08-27定期改訂表現結果に影響なし

    「観測できる」の範囲を、サイト内の実装に限りました

    • ★★ 外部レビューの指摘です。 優先ソースの記事で「deeplink の有無は公開ページから観測できます」と書いていましたが、提供元は deeplink をニュースレターや SNS でも使えるとしています。 公開ページの診断で観測できるのは、公開ページ上に実装されたものだけです。「何を観測できるか」を主題にした記事で、その範囲を広く書いていました。
    • 規模の数の並べ方を直しました。 「20 万超 → 34.5 万超 → 60 万超」と矢印で並べると、同じ定義の指標が時系列で伸びたように見えます。 原文は 4 月が sites、5 月と 8 月が sources で語が変わっています。各時点で提供元が公表した規模として日付つきで並べ、定義が同一であることまでは確認していないと添えました。
    • 測る内容は変わりません。
  100. 2026.08 第232版2026-08-26定期改訂表現結果に影響なし

    「効果の数値が 3 つ」は、自分の説明と噛み合っていませんでした

    • 外部レビューの指摘です。 優先ソースの記事で「効果の数値は、性質の違うものが 3 つあります」と書いていましたが、公表されている数字は 2 種類です。しかも 20 万超 → 60 万超は採用の規模であって、効果の数値ですらありません。 記事の後半で厳密に書いた説明と、見出しが噛み合っていませんでした。「公表された 2 種類の数字と、まだ無い数字」に改めました。
    • 「その人のアカウントにある」を「利用者側の設定」に直しました。 提供元の説明は、ログインして保存した場合に各ブラウザで引き継がれるという書き方で、必ずアカウントに存在すると一般化する必要はありません。 記事の論旨に保存方式は要らないので、踏み込みません。
    • 「AI 検索対策として社内に説明すると食い違う」は強すぎました。 「AI 検索対策」という語が必須条件を意味するとは限りません。この記事自身が「設置を検討する合理性がある」と書いています。 食い違うのは「付けないと AI 検索に出ない必須の対応」として説明した場合なので、そう書き直しました。任意の可視性施策として紹介することまでは否定しません。
    • 3 段の図の説明を言い直しました。 「準備状態と直接つながるのは ① だけ」と書くと、① が準備状態の指標であるようにも読めます。 「3 つのうち、サイト側の公開ページに実装されるのは ① だけ」に改めました。
    • 測る内容は変わりません。
  101. 2026.08 第231版2026-08-26定期改訂分類根拠結果に影響なし

    項目の入場条件 2 の書き方を、精密にしました

    • ★★★ 外部レビューの指摘から出た、この製品自身への発見です。 項目の入場条件 2 を「何個中何個で数えられる実体がある」と書いていましたが、これでは弱すぎました。たいていのものは数えられます。
    • 実例が出ました。 優先ソースのボタンは「診断した 30 ページのうち、ボタンがあるのは何ページか」と普通に数えられます。 サイトに 1 つあるか無いかの二値にもできます。それでも項目にはなりません —— 提供元がボタン以外の導線も認めており、「ボタンのあるページの割合」が、測りたい状態の分母になっていないからです。
    • 条件 2 をこう改めました ——「測ろうとしている状態に対応する、実在する母集団を定義でき、その中で『何個中何個』で数えられる。分母を SILVE が便宜的に作らない」。
    • ★★ 新しい規則ではありません。 2026.08.174 で sitemap.xml を項目から外した理由が「分母が作れません」でした。実務は最初からこの強い形で動いており、書いてある条件だけが弱かったという状態でした。原則を書いた場所と、原則が効くべき場所がずれる —— またこの型です。
    • ★★ あわせて「2 倍」の扱いを直しました。 優先ソースの記事で、Google が公表している「twice as likely to click through」を効果の大きさとして書いていました。確認した告知には算出方法が示されていません（対照の取り方・期間・分母のいずれも不明）。私たちは効果検証の記事で「施策後に起きた ≠ 施策によって起きた」を厳密に扱っています。この 1 件だけ緩めません。
    • 数の表記も直しました。 原文は over / more than なので「20 万超 → 34.5 万超 → 60 万超」とし、4 月は sites、5 月以降は sources と語が変わっていることも踏まえた書き方にしています。
    • ボタン・利用者の設定・表示の 3 段を、図で分けました。 ボタンを置いた ≠ 優先ソースに選ばれた ≠ 可視性が変わった、の 3 つは別です。
    • 測る内容は変わりません。 現在の 10 項目は、精密にした条件 2 でも変わらず通ります。
  102. 2026.08 第230版2026-08-26定期改訂根拠表現結果に影響なし

    「効果の数値は公開されていない」は誤りでした

    • 外部レビューの指摘です。 優先ソースの記事で「提供元は効果の大きさを数値で公開していない」と書きましたが、公開されていました —— 2026 年 4 月 30 日と 5 月 27 日の告知に「readers are twice as likely to click through to a site after marking it as a Preferred Source」とあります。一次資料 2 本を追加し、原文で確認しました。
    • そのうえで、記事の主張は残せます。 公表されている数は性質の違うものが 3 種類でした ——選ばれたソースの数（20 万 → 34.5 万 → 60 万）、設定後のクリックのしやすさ（2 倍）、表示がどれだけ増えるか（公表されていません）。混ぜて引用しないという形に書き直しました。
    • 表示面ごとに効果が違うことを分けました。 Top Stories は「more likely to appear」、AI Mode と AI Overviews は「can be highlighted with a preferred badge」です。同じ言葉でまとめていました。「優先ソースに選ばれると AI Mode で引用されやすくなる」とは、この資料からは言えません。
    • 診断項目に入れない理由を、正しい論証に直しました。 「何個中何個で数える単位を持たない」と書きましたが、数えることはできます（診断した何ページにボタンがあるか）。成り立たないのは、その数が何の割合なのかです。提供元は deeplink や SNS からの誘導も認めており、「ボタンのあるページの割合」は、優先ソースを利用できる状態の分母になりません。
    • 「この機能について測れることが何もない」も強すぎました。 ボタンの有無・対象の単位は公開ページから観測できます。観測できないのは、読者の選択状態・選択した人数・その選択による表示差です。
    • 優先ソース自体が 8 月 20 日に始まったのではないと書き足しました —— 4 月に全言語へ、5 月に AI Overviews と AI Mode へ広がっています。8 月 20 日に加わったのは埋め込みボタンです。
    • 「資料に rank の語が無い」を根拠にするのをやめました。 Top Stories について「more likely to appear」と書いてある以上、語の有無は本質ではありません。 書かれていないのは一般順位と採用確率のほうなので、そちらを射程として書きます。
    • 測る内容は変わりません。
  103. 2026.08 第229版2026-08-26定期改訂根拠結果に影響なし

    「優先ソース」は診断項目にしません

    • 記事を 1 本足しました ——「優先ソースのボタンは、付けるべきか — 読者が選ぶものと、機械に伝わるものは別」。Google が 2026 年 8 月 20 日に告知し、同日に実装側の資料を更新した機能についてです。
    • ★★ 診断項目にはしません。 入場条件を 2 つとも満たさないためです —— 欠けても機械に伝わらなくなるものが無く、何個中何個で数える単位も持ちません。 話題になった実装を、話題になったという理由で足しません。
    • ★ 提供元自身が「必須ではない」と明記しています ——「It's not required to do them in order to appear as a preferred source.」。明記されているものを、こちらの判断で条件に格上げしません。
    • ★★ 変わるのは可視性で、準備状態ではありません。 しかも動かすのは読者です。誰が自分を優先ソースに選んでいるかは、外から観測できません。 測れないものを、測ったふりをして項目に入れません。
    • ★★★ 直前の記事と同じ形が、別の層に出ました。 robots.txt の記事では HTTP の層で「同じ URI でも返る表現は変わり得る」と書きました。今回は検索結果の層で「同じ問いでも読者の設定で返るものが変わる」です。1 つのアカウントで測った可視性は、その利用者の設定を測ったものになります。
    • 順位への影響は、実装側の資料の本文には書かれていませんでした（原文を取得して確認。rank はナビゲーションにのみ出現）。★ ただしこれは「この資料には書かれていない」であって、「影響しない」ではありません。
    • 告知にある「60 万を超える固有のソース」は、選ばれたソースの数であって、効果の大きさでも利用者の数でもありません。規模の数を、効果の代わりに使いません。
    • 測る内容は変わりません。
  104. 2026.08 第228版2026-08-26定期改訂根拠表現結果に影響なし

    「測り直せばすぐ確認できます」も、強すぎました

    • ★★★ 再レビューの指摘です ——「SILVE は再取得するので変更はすぐ見える、はまだ強い」。そのとおりでした。 前回の取得内容を再利用しないことと、すぐ新しい内容が返ることは別です。配信側のキャッシュや、設定変更そのものの反映の時間差があれば、私たちの次の取得にも古い内容が返り得ます。 どちらの側にも即時性を約束しない書き方に直しました。
    • ★★ これは記事だけの問題ではありませんでした。 直前の版で結果画面の手順にも「測り直せばすぐ確認できます」と入れていたので、画面のほうも直しています。
    • ★★ 「観測は正しく、手順だけが誤る」という節を削除しました。 「何が公開されているか … ファイルを読めば決まる」と書いており、その直前に自分で置いた留保（各社が同じ内容を受け取るとは言えない）と噛み合っていませんでした。 同じ内容は要点と別の節にあるので、節ごと落としています。
    • Cloudflare の提供状況の書き方を精密にしました。 告知の中に時制の揺れがあります —— 冒頭は「available to all customers」、末尾は「in the coming week」「upcoming launch」。「提供前だ」とも断定せず、「全顧客への提供完了を告知時点の事実として扱わない」に改めました。
    • ★ 「遮断は見ていません」を、この項目の話に限定しました。 SILVE は別の項目で取得の成否も観測しています。この項目が数えているのは robots.txt 上の表明である、と書き分けました。
    • 3 つの資料が、それぞれ別のことを言っていると分けました。 規格は「アクセスの認可ではない」、Google は「クロールを拒否しても検索結果から消えるとは限らない」、Cloudflare は「意思の表明と、実際に遮断する仕組みは別」。同じ結論の裏づけとして並べていたので、命題ごとに分けています。
    • 測る内容は変わりません。
  105. 2026.08 第227版2026-08-26定期改訂根拠表現結果に影響なし

    「各社も同じ robots.txt を受け取る」という断定を外しました

    • ★★★ 外部レビューの指摘です ——「SILVE と各社が同じ 1 つのファイルを受け取る、は RFC 9309 から導けない」。そのとおりでした。 規格が定めているのは URI・書式・取得失敗時の扱い・キャッシュであって、同じ URI へのすべての要求に同じ内容が返ることまでは定めていません。 HTTP は 1 つの資源が複数の表現を持ち得ることを認めています（RFC 9110 §3.2）。
    • ★★ これは私たちが既に採っている射程と、同じ形でした。 「取得の安定性」では「SILVE が 403 を受けた ≠ 各社も 403」と書いています。同じ規律を robots.txt に当てていませんでした。 記事から断定を外し、「診断の時点で、SILVE の要求に対して返ってきた内容まで」に直しました。
    • ★★ キャッシュの話の向きが逆でした。 「設定を変えた直後に測り直しても、直っていない証拠にならない」と書いていましたが、キャッシュするのは取得側で、SILVE は再診断のたびに自分で取得し直します。 正しくは逆で、SILVE で変更を確認できても、各社が取得済みとは限りません。 結果画面の手順にも 1 段足しました。
    • 訂正の書き方も直しました。 「告知の原文はそう書いていない」としていましたが、原文には「will be on by default」と書かれています。間違っていたのは内容ではなく時制でした。
    • 日付を直しました —— 告知は 2026 年 8 月 21 日（協定世界時）で、私たちの収集が拾ったのが 8 月 25 日です。
    • 「置き場所しか定めていない」を「生成主体を要件にしていない」へ。 規格は書式も規則も取得失敗時の扱いも定めています。言いたかったのは、生成主体を条件にしていないことでした。
    • ★ robots.txt の拒否は、遮断ではありません。 規格が「These rules are not a form of access authorization.」と明記しており、Google も掲載を止める仕組みではないと書いています。私たちが数えているのは表明のほうだと、記事に書き足しました。
    • 結果画面の手順を、一次資料の射程へ寄せました。 「ファイルを編集しても書き直される」は内部の挙動の断定でした。提供元が書いているのは「設定に応じて生成・更新する」までです。
    • 測る内容は変わりません。
  106. 2026.08 第226版2026-08-26定期改訂根拠表現結果に影響なし

    告知を、現在の事実として書いていました

    • ★★★ 訂正です。 直前の版（2026.08.225）で、Cloudflare の Bot Preference Sync について「新規の顧客は既定でオン」と書きました。告知の原文はそう書いていません ——「will be available … in the coming week（来週中に提供予定）」であり、告知の時点では提供前です。既定でオンになることも「will be on by default」という予定の形で書かれています。
    • ★★ 告知を読んだその日に、予定を現在形へ変えて書いていました。 これは私たちが記事の側で繰り返し戒めていることです。2026 年 8 月 26 日時点で、提供元の変更履歴に該当の項目は見当たりませんでした。
    • 外からも確かめました。 Cloudflare を通っている 6 サイトの robots.txt を取得しましたが、区画は見つかりませんでした。★ ただしこれは「まだ出ていない」の証拠にはなりません。 設定していないだけかもしれず、6 件では何も言えません。
    • ★ 検出そのものは変えていません。 区画が出てきたら、そう言う。出てこなければ何も言わない —— この動きは提供状況に依存しません。
    • ★★★ 記事を 1 本足しました ——「robots.txt は、誰が書いているのか」。観測は生成元に依存しないが、直し方は依存するという切り分けを、一次資料とあわせて書いています。
    • ★★ 記事を書く過程で、これが新しい問題ではなかったと分かりました。 Google は自社の資料に「CMS では robots.txt を直接編集できないことがある」と以前から明記しています。 私たちの手順は、告知より前から、この場合を書けていませんでした。告知は気づく契機であって、原因ではありません。
    • 測る内容は変わりません。
  107. 2026.08 第225版2026-08-26定期改訂表現根拠結果に影響なし

    robots.txt を誰が書いているかで、直す場所が変わります

    • ★★★ 2026-08-22、Cloudflare が Bot Preference Sync を発表しました。 ダッシュボードの AI ボット設定（Search / Agent / Training）から robots.txt へ区画を差し込む仕組みで、新規の顧客は既定でオン、無料プランでも使えます。その区画の行は、ファイルを編集しても設定から生成し直されます。
    • ★★ 私たちの「直し方」が、間違いになる場合がありました。 「robots.txt の Disallow を見直してください」と書いてきましたが、区画の中の行はファイルからは直せません。 直す場所は提供元の設定です。
    • ★ 観測のほうは、これまでどおり正しいままです。 私たちが読むのは公開されている robots.txt で、各社のクローラーが見るものと同じです。間違っていたのは「どこを直すか」だけです。
    • ★★ 同じ型は、すでに製品の中にありました。 noindex の直し方は「HTTP ヘッダでの指定はページのソースに出てこないので、サーバやリバースプロキシの設定も確認してください」と書いています。型はあったのに、robots.txt には当てていませんでした。
    • ★★★ 直し方を、1 つの段落から手順の並びに変えました。 「意図を確かめる」「どこを直す」「触らなくてよいもの」が同じ重さで詰まっており、順番が読み取れませんでした。 どこを直すかが分岐するようになった以上、段でしか書けません。
    • ★ 区画があったときだけ、その話をします。 無いサイトに「提供元の設定を確認してください」と書けば、観測していないことを手順にすることになります。区画があることと、それが拒否の原因であることも分けて書きます。
    • 社内共有用の要約と書き出しの見出しが「改善手順」のままでした。 2026.08.218 で言い方を揃えたときの漏れで、画面と書き出しで同じものを別の名前で呼んでいました。 揃えました。
    • 測る内容は変わりません。 何個中何個が伝わっているかの数え方も、区分も、判定も同じです。
  108. 2026.08 第224版2026-08-24定期改訂表現結果に影響なし

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

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

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

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

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

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

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

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

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

    • ★★★ 「私たちの考え方」のページに、強調の記号がアスタリスクのまま出ていました。 「これは現在の診断項目ではありません。」という一文が、囲みの記号ごと表示されていました。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 はもう点を出しません。 自社が出さない単位を自社の例に使うと、「準備状態は点で出る」と読めます —— 同じ画面に「総合点は出しません」と書いてあります。 合成できないという主張は、単位が違うことだけで成り立ちます。
    • 測る内容は変わりません。
  113. 2026.08 第219版2026-08-21定期改訂表現結果に影響なし

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

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

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

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

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

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

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

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

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

    • ★★★ 無料診断は「入力した 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」と名乗っているのに、入口の名前だけ違っていました。
  118. 2026.08 第214版2026-08-21臨時改訂表現結果に影響なし

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

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

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

    • ★★★ 診断結果のページと書き出しに、認証の確認が 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 はページを数えるので、別の名前にすべきでした）。
  120. 2026.08 第212版2026-08-21臨時改訂表現結果に影響なし

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

    • ★★★ 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 条の「配点」 を「観測・判定の方法」へ、更新のお知らせの「サイトの点」 を「サイトの結果」へ、有料プランの「効いたかどうか」 を「基準上の変化」へ直しました。
    • いずれも書き方の話で、測り方は変えていません。
  121. 2026.08 第211版2026-08-21定期改訂表現結果に影響なし

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

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

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

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

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

    • ★★★ 本文の 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 に戻しました。
    • 測り方は何も変えていません。
  124. 2026.08 第208版2026-08-21臨時改訂表現結果に影響なし

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

    • ★★★ 無い機能を 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 の版で公開したか」という過去の事実まで狂います。
    • 測り方は何も変えていません。 同じサイトを同じ日に測れば、同じ結果が出ます。
  125. 2026.08 第196版2026-08-21定期改訂表現結果に影響なし

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

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

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

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

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

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

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

    • ★★★ 項目ごとの割合を、数字の主役にしました。 「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 行で添えます。
    • ★ 以前「割合は出さない」と決めていたのを撤回しました。 理由は「並べると平均したくなるから」でしたが、実数からも割合は計算できるので、平均したい人を止められていませんでした。 止まっていたのは、桁で違う状態を一目で見分けることのほうでした。
  129. 2026.08 第192版2026-08-20定期改訂表現結果に影響なし

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

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

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

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

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

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

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

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

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

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

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

    • ★★★ 所要時間の記述が、どれも実測と合っていませんでした。 画面には「約 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 で診断項目から外しています。
    • コード側に「説明できる用途が無くなったら、欄ごと畳む」と書いてありました。用途が無くなったので、そのとおりにしました。 入力を受け取る仕組みは残します —— 過去の診断が保持しているためです。
  135. 2026.08 第185版2026-08-20定期改訂表現結果に影響なし

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

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

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

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

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

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

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

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

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

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

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

    • ★★★ 判定していない項目に、改善を指示していました。 「まだ確定していないもの」の欄で「根拠がまだ足りないため、判定に使っていません」と説明しながら、同じ項目について「本文をサーバー側で 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 項目」です。
  141. 2026.08 第178版2026-08-20定期改訂表現分類結果に影響なし

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

    • ★★★ 結果画面の上部と改善計画で、同じ項目の数が食い違っていました。 上部は「代替テキストがない画像 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 つも削っていません。開くまで出さないだけです。 結果と方法論を分けます。
  142. 2026.08 第177版2026-08-20測り方の変更採点根拠結果が変わります

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

    • ★★★ 公開済みの評価基準 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 文字も違いません。
  143. 2026.08 第176版2026-08-20定期改訂表現分類結果が変わります

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

    • ★★★ 利用者の指摘 ——「準備状態かチェックするツールなのに『準備ができている』と言えない理由はなんだ」。言えます。こちらの誤りでした。
    • 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 の回答へ出るかどうかは、これとは別です。」「届きます」「引用されます」「万全です」は書きません（機械で見張っています）。
  144. 2026.08 第175版2026-08-20定期改訂表現分類結果が変わります

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

    • ★★ 利用者の指摘 ——「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 つに減らしました（他の場所が同じことを言っていたものを落としました）。予防線を先に置きません。 読む方が知りたいのは結果であって、こちらの慎重さではありません。
  145. 2026.08 第174版2026-08-20測り方の変更根拠分類採点表現結果が変わります

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

    • ★★★ 提供元の資料と突き合わせたところ、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 の意味そのものを後から書き換えることになります。 公開済みの版は編集しないという原則をここにも当てます。現在の基準との違いは、結果画面に別枠で書きます。
  146. 2026.08 第172版2026-08-20定期改訂根拠分類表現結果に影響なし

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

    • ★★ これまで全宛先に同じ文を出していました ——「その 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 回くり返しているとおり、順位でも権威でもありません。
  147. 2026.08 第171版2026-08-20定期改訂根拠表現結果に影響なし

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

    • ★ 利用者の指摘 ——「『できていない』は、できるのにやっていないのか、物理的にできないのか、そもそもそういう意味ではないのかで印象が大きく変わる。」当たっていました。この 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 の中にあります。「決まった形では見つからなかった」までに直しました。
  148. 2026.08 第170版2026-08-20臨時改訂表現採点結果に影響なし

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

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

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

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

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

    • ★ 利用者の質問 ——「同水準のコンテンツで、片方が機械に読まれる形なら、そちらのほうがおすすめされやすいのか？」画面はそれに答えていませんでした。
    • 答えは「確かめていない」です。 私たちは効果検証を実装しておらず、「整えると引用されやすくなる」という主張はしていません。
    • ★ 層によって、言えることの性質が違います。 最初の層（そもそも読まれるか）だけは論理で確かです ——塞がれていれば、その宛先の回答には出ません。効果の証拠は要りません。
    • 残りの 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 と整合する内容を識別する要因の組み合わせは有用」とも書いています。どちらも事実なので、どちらも残しています）。
    • 結果画面の読み方と評価基準ページに、この線をそのまま書きました。
  151. 2026.08 第166版2026-08-20臨時改訂表現結果に影響なし

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

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

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

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

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

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

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

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

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

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

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

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

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

    • ★ 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 項目ですら言えるのは否定側だけです。「塞がれていれば届かない」は言えますが、「通っていれば認知される」は言えません。 画面にも「届きます」とは書きません。
    • 過去の診断は、実行した時点の版のまま読めます。 総合スコアも消していません。公開した版は書き換えません。
  158. 2026.08 第123版2026-08-19臨時改訂採点結果が変わります

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

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

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

    • ★ 同じサイトを同じ日に測っても点が変わります。 配点される重みの合計は 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 点は配り直していません。 配点される重みの合計は、根拠の合計であって定数ではありません。
  160. 2026.08 第87版2026-08-17定期改訂採点根拠

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

    • 配点は 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）は今後も続けます。
  161. 2026.08 第86版2026-08-17定期改訂採点項目の追加・廃止根拠結果が変わります

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

    • ★ 項目が 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 度直した型を、新しい項目では最初から避けます。
  162. 2026.08 第85版2026-08-17定期改訂採点項目の追加・廃止根拠結果が変わります

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

    • ★ 項目が 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。見つけていないのか、見て採らなかったのかを区別して残します。
  163. 2026.08 第84版2026-08-17定期改訂採点根拠結果が変わります

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

    • ★ 同じサイトを同じ日に測っても点が変わります。 配点される重みの合計が 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 の明示」は、今回の一次資料の通読対象に入れていません。一部だけ下げて恣意的にならないよう、当てた項目と当てていない項目を明記しています。 次の版で同じ問いを当てます —— 「その資料は、不在を不備と述べているか」。
    • これは「点が甘くなった」ではありません。 分母が小さくなるので点は上がる方向に動きやすいですが、上げるために下げたのではありません。 提供元が「無くてもよい」と書いているものを減点し続けることを説明できないから下げました。点が上がるのは副作用です。
  164. 2026.08 第82版2026-08-17定期改訂採点根拠結果が変わります

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

    • ★ 同じサイトを同じ日に測っても点が変わります。 配点される重みの合計が 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% になります。 直接の根拠がはっきりしているカテゴリ（クローラー対応・エージェント対応）の比重が上がります。それがこの版の狙いです。
    • 解決していないことも書いておきます。 「署名や日付が期待されるページか」を私たちは判定できません。ページごとに適用外とする案は、記事の構造化データの有無で判定すると「正しくマークアップしたサイトだけが減点され得る」という逆転が起きるため採れませんでした。重みを下げたのは、その代わりの措置です。
  165. 2026.08 第81版2026-08-17定期改訂採点結果が変わります

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

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

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

    • スコアは変わりません。 重み・判定・配点の理由は 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 つのどこにも無い」ところまで分かっていますが、明らかな過大宣言の修正と、配点の判断は別の版で扱います。 混ぜると、点が動いた理由を説明できなくなるためです。
  167. 2026.08 第78版2026-08-17定期改訂採点表現結果が変わります

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

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

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

    • ★ 同じサイトを同じ日に測っても点が変わります。ただし配点は 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 で公開された不具合は、期待値をどこにも書いていなかったから気づけませんでした。 各版の実効重みを検査に書き、遡って変わったら落ちるようにしています。
    • ★ 注意（版をまたいだ比較）。 判定を変えた版なので、古い版を指定して測り直しても当時の判定は復元されません。 さらに今回は重みが同じで判定だけが変わったため、差は「基準の変化」ではなく「サイトの変化」の側に出ます。 つまりサイトを何も直していないのに「良くなった」ように見えます。 版をまたいだ再診断の結果を、直した成果として読まないでください。
  169. 2026.08 第76版2026-08-14臨時改訂表現結果に影響なし

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

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

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

    • スコアは変わりません。
    • ★ 本文では直したのに、まとめだけ旧版のままでした。 見出し・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 個あります。壊れてはいないので落としません）。
  171. 2026.08 第74版2026-08-14定期改訂根拠表現結果に影響なし

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

    • スコアは変わりません。
    • ★ 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 検査で確認するへ改めました。
  172. 2026.08 第73版2026-08-14定期改訂採点項目の追加・廃止結果が変わります

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

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

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

    • スコアは変わりません。
    • ★ 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）。
  174. 2026.08 第71版2026-08-13臨時改訂根拠表現結果に影響なし

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

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

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

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

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

    • スコアは変わりません。 公開前の下書きの修正です。
    • ★ 前の版で直したはずの表現が、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 / 確信度 中）、時系列を主張しない判断、採点ゼロ。いずれもレビューで妥当と判定されています。
  177. 2026.08 第68版2026-08-13臨時改訂表現根拠結果に影響なし

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

    • スコアは変わりません。 公開前の下書きの修正です。
    • ★ 記事の主語が「掲載の可否」になっていました。 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 は一次資料を確認できていません。確認できていないことは、確認できていないまま残します。
  178. 2026.08 第67版2026-08-13定期改訂表現結果に影響なし

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

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

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

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

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

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

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

    • スコアは変わりません。 採点には使わない記事です。
    • ★ 掲載の条件はどこにあるかを公開しました。 これまで話題ごとに分けた構成では置き場所が無かった主張です。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 件を確認して埋めました。
  182. 2026.08 第63版2026-08-13臨時改訂根拠結果に影響なし

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

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

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

    • スコアは変わりません。 記事の作り方と、資料の見張り方の話です。
    • ★ 候補記事を 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 に残しました。 同じ議論を繰り返さないためです。
  184. 2026.08 第61版2026-08-13臨時改訂表現根拠結果に影響なし

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

    • スコアは変わりません。 画面の言葉だけを直しています。
    • ★ 「なぜ効くか」というラベルをやめました。 診断結果と 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版」のまま止まっていました）。
  185. 2026.08 第60版2026-08-13定期改訂採点分類根拠結果が変わります

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

    • ★ スコアが変わります。実効重みは 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 だけでなくコード上でも成立させます。
  186. 2026.08 第59版2026-08-13定期改訂表現根拠結果に影響なし

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

    • ★ スコアは変わりません。 重みも判定ロジックも 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 を配分している状態は説明できない」でした。同じ理屈がこの項目にも当たります。 重みを動かすとすべての診断結果が変わるため、この版では言葉だけを直しています。
  187. 2026.08 第58版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 この層は未実装のままです。
    • ★ 「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 本すべてのレビューを反映し終えました。
  188. 2026.08 第57版2026-08-13臨時改訂分類根拠表現結果に影響なし

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

    • スコアは変わりません。 この層は未実装のままです。
    • ★ 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 を別のフィールドにしている設計はそのままに、層から水準を自動的に決めないという規則にしました。
  189. 2026.08 第56版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 時間の扱いは未実装のままです。
    • ★ 「新しさは引用リストに入るかどうかには効く」を撤回しました。 記事はまず、その研究が 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 本（情報環境の記事）は同じ誤りをしていませんでした — 「引用プールに入ることと回答に出ることは別」と正しく書いています。誤りはこの記事だけでした。
  190. 2026.08 第55版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 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%」です。引用は取得の全体ではない。開示されたログも取得の全体ではない。
  191. 2026.08 第54版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 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 つの誤りは、いずれも表だけを見て本文を読まなかったことが原因です。
  192. 2026.08 第53版2026-08-13臨時改訂分類根拠表現結果に影響なし

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

    • スコアは変わりません。 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 の結論に揃えました。 「引用が多くても候補に残らなければ成果につながりません」→「購入や選択を目的の指標にするなら、引用が多いだけでは足りません」。「引用に価値がない」とは書きません。
  193. 2026.08 第52版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 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 の記事の「内部クエリは観測できない」と矛盾しません。
  194. 2026.08 第51版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 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 システムは同義語や求めていることの一般的な意味を理解し、まったく同じ語を使っていないコンテンツとも結び付けられる」「ロングテールの語句が足りないと心配する必要はない」という説明です。掲載資格の話に聞こえる書き方を避けました。
  195. 2026.08 第50版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 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%』の唯一正しい読み方です」を「この論文から直接支持される読み方です」に変えました。 解釈に「唯一」を付けません。
  196. 2026.08 第49版2026-08-13臨時改訂根拠結果に影響なし

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

    • スコアは変わりません。本文の主張も変わりません。 確認の程度が上がりました。
    • ★ 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 の記事に追記しました。
  197. 2026.08 第48版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 採点には使っていない記述の更新です。
    • 前版で「現在の提供状況は確認できていない」としていた件を更新しました。 旧 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 の仕様」と明示します。
  198. 2026.08 第47版2026-08-13定期改訂採点根拠表現

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

    • ★ 同じサイトでもスコアが動きます。 操作要素・入力欄・画像が 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 年時点の記述として扱い、現在の提供状況は未確認と明記します。
  199. 2026.08 第46版2026-08-13臨時改訂根拠分類表現結果に影響なし

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

    • スコアは変わりません。 重みの記載を実装に合わせただけで、実装側は動かしていません。
    • ★ 外部での表現（層 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 側が決めます。
    • 見出し「識別子は名前より強い」を「識別子は、名前だけでは残る曖昧さを減らせる」に変えました。 重み付けのように読めるのを避け、この記事の原則（強くするのではなく曖昧でなくする）に揃えました。
  200. 2026.08 第45版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 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 件ずつ潰すという手順と、記録には件数ではなく「どう探したか」を書くことを明記しました。探し方が弱ければ、件数は当てになりません。
  201. 2026.08 第44版2026-08-13臨時改訂根拠結果に影響なし

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

    • スコアは変わりません。本文も変わりません。 台帳の根拠だけを増やしました。
    • 終了日の出典が正しいかの指摘を受け、再検証しました。 「リリースノートには月までしか書かれておらず、正確な日付は別ページにある」という指摘だったので、「月だけなら月だけと答えよ」と明示したうえで取り直しました。 結果、リリースノートのページ上部の警告ボックスに「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 つだけを根拠にすると、そのページが改稿された瞬間に根拠を失います。 他者と帰属が食い違ったときも、勝ち負けを決めずに両方を確認して両方を持ちます。
  202. 2026.08 第43版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 構造化データの配点（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 の原則と整合している」までです。
  203. 2026.08 第42版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 記述の追加だけです。
    • ★ 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 のようなサイト単位の設定が加わります。
  204. 2026.08 第41版2026-08-13臨時改訂根拠分類表現結果に影響なし

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

    • スコアは変わりません。 追加した用途は採点対象外（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 のままでした。揃えています。
  205. 2026.08 第40版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 「順位付けに使われるという公式記述は無い」は誤りでした。 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 系統です。
  206. 2026.08 第39版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 「エージェント対応度は決定論的に測れる」は範囲が広すぎました。 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 全体の科学は確立していない」が、現在の一次資料から言える限界です。
  207. 2026.08 第38版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 資料に書かれていない分類を、その資料に帰属させていました。 「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 は本文に登場しません。
  208. 2026.08 第37版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 「日本では主に 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）。
  209. 2026.08 第36版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 普及率の根拠にしていた媒体が、この用語を製品名にしているベンダーの所有でした。 「業界リーダーの 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 本を直したら、同じ書式の記事を掃く。
  210. 2026.08 第35版2026-08-13臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 前版（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 実験も固定文脈であること、架空の統計・引用・出典を許容した実験であること。むしろ最後の点は、リポジトリではなく査読を経た版の付録に印刷されていたぶん、強い根拠になりました。
  211. 2026.08 第34版2026-08-12臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 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 の規則にも、「追加の技術要件が無い」は掲載条件の全体ではないという注記を入れています。
  212. 2026.08 第33版2026-08-12臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 項目・重み・判定ロジックは変えていません。
    • ★ 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）。題名が変わるということは本文も変わり得ます。 検査側も、文字コードの判定・数値文字参照の復号・「取得できなかった」と「題名が違う」の分離を直しました。
  213. 2026.08 第32版2026-08-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 のクローラ文書）。実ページの題名を検証済みのフレームワーク台帳側へ揃えています。検査の対象から外れている場所に、まさにその種類のずれが溜まります。
  214. 2026.08 第31版2026-08-12臨時改訂採点項目の追加・廃止結果に影響なし

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

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

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

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

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

    • スコアは変わりません。 第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 に落ち、型付きの分類に届かない」としています。
  218. 2026.08 第27版2026-08-11臨時改訂根拠分類結果に影響なし

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

    • スコアは変わりません。 この層は未実装で、本改訂は実装前に要件を固定するものです。
    • 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 倍でした。そしてこれらの研究に日本市場は含まれていません。 実測します。
    • 事実と意見を分けます。 否定的なレビューがあること自体は不整合ではありません。「高いと思う」は意見で、「すでに販売終了している」が事実と違えば不整合です。 そして偽のレビュー・なりすまし・関係を明かさない推薦を推奨も採点もしません。 情報環境を良くする行為ではなく、汚染する行為だからです。
  219. 2026.08 第26版2026-08-11臨時改訂根拠分類結果に影響なし

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

    • スコアは変わりません。 第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 が固定規則の下で生成した操作的な測定値であることです。
  220. 2026.08 第25版2026-08-11臨時改訂根拠分類結果に影響なし

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

    • スコアは変わりません。 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 が単一の日付要素に依存せず複数要素から公開・大幅更新の時期を推定していること、および日付はページの公開・更新を表すべきでページが説明している出来事の日付ではないことです。
  221. 2026.08 第24版2026-08-11臨時改訂根拠結果に影響なし

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

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

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

    • スコアは変わりません。 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 は取得側の問題であり、記述が存在しない証拠ではありません。
  223. 2026.08 第22版2026-08-11臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。 本改訂は 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 日間です。
  224. 2026.08 第21版2026-08-11臨時改訂根拠結果に影響なし

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

    • スコアは変わりません。 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 クエリで十分」は、論文が明示的に否定した読み方です。
    • 信頼区間を付けても不確かさを尽くしたことにはなりません。 標本の中で分布が動いている場合、ブートストラップを含む定常性前提の区間は真の不確かさを過小評価し得ます。 原因はクエリの投入順序という測定設計側にあります。
    • 認知（ブランド名を含むプロンプト）と発見（含まないプロンプト）を平均しません。また、クエリ・情報源・日付はクラスタ化された単位であり、すべての生成を独立標本として扱うと不確かさを過小評価します。
  225. 2026.08 第20版2026-08-11臨時改訂根拠結果に影響なし

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

    • スコアは変わりません。
    • 「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 専用の文体を探す前に、そのページがその問いに答えているかを確認します。
  226. 2026.08 第19版2026-08-11臨時改訂根拠表現結果に影響なし

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

    • スコアは変わりません。
    • 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 版のみ記載しています。
  227. 2026.08 第18版2026-08-11定期改訂分類項目の追加・廃止結果に影響なし

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

    • スコアは変わりません。 チェックリスト 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 のような安定した標準より変化が速いためです。
  228. 2026.08 第17版2026-08-11臨時改訂表現根拠結果に影響なし

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 で記録します。
  229. 2026.08 第16版2026-08-11臨時改訂

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 件すべてが一致しています。
  230. 2026.08 第15版2026-08-11臨時改訂

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 を送るよう修正し、「取得できなかった」は資料の性質ではなくこちらの試行についての事実である、という規則を追加しました。
  231. 2026.08 第14版2026-08-11臨時改訂

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 へ上げません。
  232. 2026.08 第13版2026-08-11臨時改訂

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 は未取得、旧ドメインからのリダイレクトは未設定、外部プロフィールの統一も未着手です。自分たちができていないことを、できているかのように書きません。
  233. 2026.08 第12版2026-08-11定期改訂採点

    構造化データの配点を 20 から 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%）。
  234. 2026.08 第11版2026-08-11臨時改訂

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 での露出への寄与（根拠なし）」を分けて考えます。
    • プラットフォームフィードへの対応は採点していません。 公開サイトを見るだけでは連携の有無を判定できない場合があるためです。判定できないものは推測せず「観測できない」と表示します。また、メディアサイトに商品フィードが無いことのように、その事業に不要なデータ経路の不在を減点しません。
  235. 2026.08 第10版2026-08-11臨時改訂

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

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

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 標準が同じ期限になってしまいます。
  237. 2026.08 第8版2026-08-11臨時改訂

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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）を分けるようにしました。ブラウザでは読めても機械的な取得を拒否する一次資料があり、これを消失と同じ扱いにすると誤警報が続いて検査自体が信用されなくなるためです。
  238. 2026.08 第7版2026-08-11臨時改訂

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 は現在名前解決できません。第三者のクローラ情報サイトは一次資料ではないため分類の根拠にしません。未検証であることを表示し続けます。
  239. 2026.08 第6版2026-08-11臨時改訂

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

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

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 倍）に誤りはありません。
  241. 2026.08 第4版2026-08-11臨時改訂

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

    • 採点は一切変更していません。 項目・重み・判定ロジックはすべて 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 通りの分解を提示していることを注記しました。
  242. 2026.08 第3版2026-08-11臨時改訂

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

    • 「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 で後付けされた操作要素が見えず、検出数が下限値にとどまることです。
    • 操作要素・入力欄・画像が検出されなかった場合は減点しません。存在しないものの不備を減点する扱いを避けるためです。
  243. 2026.08 第2版2026-08-11臨時改訂

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

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

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

    • 「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) に変更し、スコアへの反映を停止しました。検出と説明は従来どおり行います。
  245. 2026.08 第0版2026-08-01定期改訂

    初回リリース

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