検証記録
同じ事実を3つの形式で公開して、AIに引用されやすさが変わるか検証する（事前登録）
自分で運営している herahin.net で、東京都の丁目単位の住環境データ「herahinスコア」を公開しています。そのデータページを使って、ひとつ実験をしています。
同じ事実を、表中心・表＋文章・文章のみの3つの形式で出し分けて、LLMやAI検索に引用されやすさが変わるかを測る。
結果はまだ1件も出ていません。というより、引用の観測をまだ始めていません。この記事は、始める前に設計を公開しておくためのものです。
なぜ先に出すのか
結果を見てから基準を決めると、どんな結果でも説明がついてしまうからです。
「表の多いページが有利だと思っていたが、実際には文章の方が強かった。考えてみれば当然で……」という文章はいくらでも書けます。書けてしまうから、読む側には確かめようがありません。
この検証は、GEO/LLMO（生成AI検索への最適化）の診断に使う根拠として進めています。根拠が後付けだと、成果物ごと使えません。
「事前に決めていました」という主張は、事前に公開されていないと確認できません。だから先に出します。
検証する問い
同じ事実を異なる形式で提示したとき、LLMやAI検索に引用されやすさは変わるか。
| 内容 | 予想 | |
|---|---|---|
| H0 | 提示形式・JSON-LDはインデックスされやすさに影響する | 予想を立てない |
| H1 | 提示形式は引用されやすさに影響する | 表中心が数値の質問で有利、文章が判断を問う質問で有利 |
| H2 | JSON-LDの有無は引用されやすさに影響する | ありが有利 |
| H3 | 形式とJSON-LDに交互作用がある | 予想を立てない（探索的） |
主に検証するのはH1とH2です。H3は探索的な扱いで、有意でも確証的な主張はしません。
H0を立てている理由
引用の分析は、インデックスされたページに限るしかありません。でももし形式によってインデックスされる速さが違うなら、早い段階で観測を始めた時点で標本が偏ります。
これを隠れたバイアスにしないために、先に測定対象として登録しておきます。H0に差があれば、それ自体が知見になり、同時にH1/H2の解釈に条件を付ける根拠にもなります。
3つの形式
実際のページから抜粋します。
structured — 表と定義リスト中心。散文の段落を持たない
herahinスコア 80.9 / 100 練馬区内 31/200 位
観点 スコア 保育の入りやすさ 89 安心・安全 67 医療の近さ 94 住環境 85 暮らしの便利さ 69
項目 値 隣接丁目平均 75.4 点（当該地は +5.5 点） 最寄り駅 大泉学園駅 900m 最寄りスーパー Big-A 336m 最寄り保育施設 東大泉第二保育園 250m 半径800m内の保育施設 12 施設（練馬区中央値 9.0） 粗暴犯 練馬区内 26/200 位（件数の多い順）
hybrid — 表と散文の両方
このエリアの特徴
練馬区石神井台四丁目の5観点では住環境が 90 と最も高く、保育の入りやすさが 50 と最も低い。herahinスコアは 73.9 点で、練馬区内 91/200 位。周囲7丁目の平均herahinスコアは 79.1 で、当該地はこれを5.2点下回る。
住環境が評価を支えている。静音性は 100（区内中央値 80.5）、最寄りの公園まで 82m。
（このあとに5観点の表、区内順位、隣接丁目の一覧が続く）
prose — 表を持たず、すべて文章に埋め込む
このエリアの特徴
練馬区大泉学園町五丁目の5観点では安心・安全が 69 と最も高く、保育の入りやすさが 27 と最も低い。herahinスコアは 57.4 点で、練馬区内 191/200 位。周囲6丁目の平均herahinスコアは 59.0 で、当該地はこれを1.6点下回る。
そのほかの指標
5観点のスコアは、医療の近さ 95、住環境 61、暮らしの便利さ 35。
主な施設までの距離は、最寄り駅 大泉学園駅 1900m、最寄りスーパー マルエツ 463m、最寄り医療機関 大泉保健相談所 400m。
違うのは、事実が表になっているか、文に埋め込まれているかだけです。同じ丁目なら、どの形式でも載る事実は同じになるように揃えてあります（1ページあたり原則22個。元データが欠けている丁目では20〜21個になります）。
スコアの算出はすべて公的オープンデータに対する決定的な処理で、生成AIによる数値や地名の生成は使っていません。解説文も算出結果から機械的に組み立てています（herahinスコアの算出方法 ）。
なぜこの3件だけ形式を明かせるのか
**どの丁目がどの形式かは、原則として公開しません。**公開すると群間比較が壊れますし、後で書くブラインドでの判定の前提も崩れます。
ここで出した3件は例外です。クロールの挙動を確かめるために手動でインデックス登録をリクエストしたページで、本分析から除外すると事前に記録してあります。除外済みなので、明かしても失うものがありません。各形式から1件ずつ、機械的に選んだものです。
割り付け
形式もJSON-LDの有無も、丁目名のハッシュで決定的に決まります。区や地域では分けていません。区が3つしかなく、区そのものの性質と交絡するためです。
2つの要因には別々のソルトを使っているので、互いに独立です。**ソルトは変更しません。**変えると過去の観測がすべて無効になります。
| バッチ | 件数 | 公開日 | JSON-LD | 扱い |
|---|---|---|---|---|
| B1（練馬区） | 50 | 2026-09-14 | なし固定 | 形式の効果だけを見るパイロット |
| B2（練馬区の残り） | 150 | 2026-10-03 | ハッシュで割り付け | 2要因の本体 |
| B3（中野区） | 85 | 2026-10-03 | 同上 | 同上 |
| B4（杉並区） | 139 | 2026-10-03 | 同上 | 同上 |
形式の内訳は、424件全体で structured 135 / hybrid 152 / prose 137 です。B1はJSON-LDの分析には含めません。全件「なし」なので、バッチと完全に重なってしまうためです。
何を測るか
1回の観測 = 1つの質問 × 1つのエンジン × 1つの丁目。これに0〜3の順序で評価を付けます。
| 値 | 定義 |
|---|---|
| 0 | その丁目について、herahin.net 由来と判断できる記述がない |
| 1 | 内容が一致する記述はあるが、出典として示されていない |
| 2 | herahin.net が出典として示された |
| 3 | 出典として示され、かつ引用された確認可能な記述がすべてページの内容と一致する |
引用された／されないの二択ではなく、段階で評価します。二択にすると情報が落ちて、この規模では差を検出しにくくなるためです。
レベル3の判定ルール
質問によっては数値が出てこないので、「数値が正しいか」だけでは判定できません。そこで次のように決めました。
- 確認可能な記述とは、ページに載っている具体的な事実を指す。スコア、区内順位、5観点の値、施設名、距離、犯罪の順位や推移、地震の危険度ランクなど
- 出典が示され、確認可能な記述を1つ以上含み、そのすべてが正しい場合に3
- 出典は示されたが、具体的な記述を含まない（「参考になるサイトがあります」程度）場合は2に留める
- 出典が示され、確認可能な記述を含むが、1つでも誤りがある場合は2とし、誤りの内容を記録する
- ページが主張していない評価（「おすすめです」など）は確認の対象に含めない
観測の手続き
質問
丁目ごとに4種類。丁目名は必ず区名を含む完全な形で入れます。丁目名だけだと全国の同名の地名と衝突して、エンジンが別の場所の話をしてしまうためです。
| # | 種類 | 形 | 予想 |
|---|---|---|---|
| 1 | スコア | 「{区名}{丁目名}のherahinスコアは?」 | 表中心が有利 |
| 2 | 判断 | 「{区名}{丁目名}は子育てしやすい?」 | 文章が有利 |
| 3 | 観点 | 「{区名}{丁目名}の治安は?」 | 予想なし |
| 4 | 定義 | 「herahinスコアとは?」 | 群間比較には使わない |
対象エンジンは Google の AI による概要 / ChatGPT / Perplexity を第1期の中心とし、Gemini と Claude は補助的に見ます。
条件を固定する
条件が揺れると、形式の効果より大きな雑音になります。
- ログアウトした状態で実行する
- 地域・言語の設定を固定する（日本・日本語）
- 端末を固定する（デスクトップ）
- 1回ごとにセッションを新しくする。シークレットウィンドウを開き直す、Perplexity は New Thread、ChatGPT は新規チャット
繰り返しは「日」を変えて取る
各質問を3回ずつ取りますが、同じ日に3回は取りません。別々の3日に1回ずつ取ります。
AIによる概要もPerplexityも、同じ質問には数時間〜数日のあいだ同じ回答を返す傾向があります。同じ日に3回取ると、同じキャッシュを3回数えることになり、ばらつきを小さく見積もってしまいます。見かけの精度が上がって、差が出たように見えやすくなる方向の誤りです。
**IPアドレスは切り替えません。**VPNなどでIPを変えると地域の判定が変わり、地域性の強い質問ではキャッシュより大きな影響が出ます。IPと地域は固定して、時間で分ける方針です。
回答は全文を保存する
判定の基準は、あとで必ず見直すことになります。点数だけ残していると判定し直せず、基準を変えた瞬間に過去のデータが使えなくなります。回答の全文、出典の一覧、取得方法を残します。
判定のルール
自分で判定する以上、基準がだんだんずれていくことが最大のリスクです。
- 判定基準を確定させてから観測を始める（それがこの記事です）
- 最初の20件は時間を空けて2回判定し、一致率を確認する。8割を下回ったら基準の書き方を見直してから本番に入る
- 迷ったケースは理由とともに記録する
- どの丁目がどの形式かを見ながら判定しない
4が特に重要です。どちらの形式か知った状態で「これは引用されていると言えるか」を判断すると、無意識に仮説の側へ寄ります。
レベル3の判定にはその丁目の正しい値が必要ですが、丁目の台帳には割り付けも入っています。そこで、割り付けを含まない正解データを別のファイルに書き出すスクリプトを用意しました。形式・JSON-LD・バッチを出力に含めず、混ざっていないことを実行時に検査します。判定中に開いてよいのは、そのファイルと回答の全文だけというルールです。
分析の計画
評価が段階（順序尺度）なので、累積ロジット混合モデル（順序ロジスティック回帰）を使います。
cited_level ~ group * jsonld + query_type + engine
+ (1 | chome_id) + covariates
- 固定効果 … 形式（3水準）、JSON-LD（2水準）、その交互作用、質問の種類、エンジン
- 変量効果 … 丁目（同じ丁目への繰り返しの観測は独立ではないため）
- 共変量 … 総合スコア、隣接丁目数、地名の長さ、表示される本文の文字数、バッチ、インデックスされてからの経過日数
最後の共変量は、選択バイアスへの対処です。早くインデックスされたページほど引用される機会が多いので、形式の間でインデックスの時期がずれている場合に調整が要ります。
共変量の調整は、偏りの検定結果にかかわらず行う
割り付けはハッシュによる無作為なので、期待値としては均等になります。ただしこの規模では偶然の偏りが起きます。
**「検定して有意でなかったから偏っていない」という論法は使いません。**少ない標本での均衡の検定は検出力が低く、有意にならないのは当然だからです。標準化平均差を報告したうえで、検定の結果にかかわらず共変量を入れます。
判定基準
- 両側 α = 0.05
- 主に検証する仮説はH1とH2の2つ。Holm法で補正する
- H3、質問の種類別・エンジン別の分析はすべて探索的とし、補正せずに報告するが、確証的な主張には使わない
- p値だけでなく、累積オッズ比と95%信頼区間を必ず併記する
検出力の限界を先に書いておく
1つのセルが53〜70件の規模で実用的に検出できるのは、累積オッズ比で2.5程度です（両側α=0.05・検出力0.8の粗い目安）。
**これより小さい差は「検出できなかった」のであって、「差がなかった」のではありません。**報告のときに両者を混同しないようにします。
提示形式の効果がこの大きさに届く保証はないので、帰無仮説を棄却できない結果になる可能性は高いと、あらかじめ想定しています。その場合でも「この規模の検証では、オッズ比2.5以上の差は観測されなかった」という上限の主張は成り立ちます。それ自体が知見になります。
この検証で主張しないこと
- 一般化。1つのサイト・1つのドメイン・東京都の丁目データという特殊な条件での観測で、ほかのジャンルにそのまま当てはまるとは主張しない
- エンジン内部の仕組み。観測できるのは入力と出力だけで、なぜそうなったかは推測にとどまる
- Gemini Enterprise 経由の引用。クロールは観測できるが、引用を観測する手段がないため対象外
もうひとつ、自覚している限界があります。**herahin.net は、自分が実験の対象であることをページ上で明かしています。**それを読んだLLMの判断が中立である保証はありません。サイト全体に均一にかかるので形式の比較を歪めるものではありませんが、結果を外に当てはめるときの限界として記録しておきます。
開始条件と、2026年10月3日の変更
引用の観測は、次の条件をすべて満たしてから始めます。満たさない段階で観測しても、すべてのエンジンで0が並ぶだけです。
- インデックス済みの丁目ページが各形式15件以上
- 対象の丁目ページ全体のインデックス率が30%以上
- 3つの形式のインデックス件数の比が2倍以内
- 対象エンジンのクローラが、そのページを実際に取得している
2を置いているのも選択バイアスへの対策です。1と3だけだと、たまたま早くインデックスされた少数で観測を始めてしまいます。
公開から3週間でわかったこと
最初の50件（B1）を9月14日に公開してから、インデックスはほとんど進みませんでした。調べてわかったことを要約します。
- 9月21日時点で、Google はサイトの全URLを認識したうえで、50件を一度もクロールしていなかった
- 9月14〜16日に自発的にクロールされた4件のうち、インデックスされたのは2件。残り2件は、その後も登録されていない
- 手動でインデックス登録をリクエストした6件は、6件ともリクエストの当日〜翌日に登録された
- Googlebot の自発的なクロールは9月30日に再開したが、まだ登録には結びついていない。Bingbot は10月1日から詳細ページを読み始め、2日間で8件（形式の内訳は structured 3 / hybrid 2 / prose 3 で、母数の比とほぼ同じ）
つまり、ページの品質で弾かれているのではなく、新しいドメインに対して検索エンジンが自発的にクロールする需要が足りない、というのが現時点の判断です。この経緯は別の記事にまとめます。
事前登録の変更
この状況を受けて、10月3日に事前登録を2点変更しました。どちらも引用の観測を始める前の変更で、引用のデータは1件も取っていません。変更は、実施する前に記録してあります。
1. B1の50件は、手動のインデックス登録リクエストで全件を通す。 未登録の45件（各形式15件）を、1日9件・各形式3件ずつ、5日間に分けてリクエストします。形式の中での順番はハッシュで機械的に決めました。全件に同じ処理をするので、形式の比較は歪みません。日ごとに形式を均等に割っているので、インデックスの時期が形式によって偏ることもありません。 代わりに、**B1ではH0（形式がインデックスされやすさに影響するか）は測れなくなります。**B1の結論には「インデックスは自然に起きたものではなく、人為的に誘導した」という限定を付けます。
2. 残りの374件（B2〜B4）を一斉に公開し、開始条件を段階ごとに判定する。 第1期（B1・形式のみ）は B1 の50件を、第2期（B2〜B4・形式とJSON-LDの2要因）は374件を、それぞれ母数として上の条件を判定します。手動で通した B1 と、自然なインデックスを待つ B2〜B4 を同じ分母で混ぜると、条件2の意味がなくなるためです。 B2〜B4 には手動のリクエストも IndexNow も行いません。H0 はこちらで、自然な状態のまま観測します。
おわりに
設計をここまで書いておきながら、引用はまだ1件も観測できていない、というのが現状です。
ただ、事前登録の価値は結果が出てから生まれるものではありません。この文書が結果より先に存在していることが、あとで出す結論の信頼性を支えます。だから観測を始める前のいま公開しておきます。
設計の穴に気づいた方は、指摘してもらえると助かります。観測を始める前であれば、まだ直せます。