「受け取られ方」を設計する ── Preferred Sources 3原則の実装ガイド、WEBディレクターの具体的な手順

2026年6月、Preferred Sourcesの登録サイト数は345,000件を突破した。4月の20万件から、わずか2ヶ月で72.5%増加した計算だ。

この数字が意味するのは、「登録しているサイト」がもはや少数派ではないということ。Preferred Sourcesに何らかのサイトを登録したユーザーは、すでに全体の35%に達している。

では、登録した後に何が起きるか。

Google公式は「Preferred Sourcesに登録されたサイトへのクリック率が約2倍になる」と述べている。だがこれは、登録し続けること——つまり削除されないこと——が前提だ。

archives/85「守る側の設計思想」で、私はAIを「起こす作法」として3つの原則を提唱した。

• ①決定権は人に残す——自動実行はread-onlyと通知のみ
• ②温度の保全——情報の鮮度を保ち続ける仕組みを設計する
• ③沈黙の権利（silence before sound）——常駐≠監視、問われた時だけ最善を出す

今日はこの3原則を、WEBディレクターが今週中に実行できる「具体的な手順」に変換する。登録して終わりではなく、登録され続けるための設計の話だ。

Preferred Sourcesに「登録したのに、なぜ引用されない」のか

まず前提を整理しよう。Preferred SourcesはユーザーがGoogleアカウントで「優先ソースとして追加」するだけで、そのサイトがAI OverviewやSearch結果で優先的に引用・表示される機能だ。

しかし、ここに3つの「削除リスク」が潜んでいる。

削除リスク①：情報が古くなる

2025年9月改訂版のGoogle品質評価ガイドライン（QRG）では、Content freshnessがランキング因子の第6位に位置づけられた。1年以内に更新されたページは平均4.6位高い順位が付く。

ユーザーがPreferred Sourcesに追加したサイトでも、情報が古くなれば「このサイト、もう更新してないな」と気づき、静かに削除される。

削除リスク②：AIクローラーをブロックしている

archives/86「CloudflareのデフォルトAI botsブロック」で詳述したが、Cloudflareのデフォルト設定は検索AIと訓練AIを区別せず一括でブロックする。ユーザーがPreferred Sourcesに追加したとしても、AIクローラーがサイトにアクセスできなければ引用は物理的に不可能だ。「登録したのに引用されない」の原因の多くが、ここにある。

削除リスク③：サイト自体がAIに「見えない」設計になっている

archives/83「ボットが世界の57%を占めた日」で述べたとおり、AIクローラーのHTTPアクセスパターンは通常ユーザーと異なる。User-Agentを見ずにCloudflareが弾く、robots.txtで誤ってAIクローラーをブロックしている、といった設定ミスが「見えないサイト」を作り出す。

3つのリスクをまとめると：

• 情報が古い → ユーザーが削除
• AIがアクセスできない → 引用不能
• そもそもAIに見えていない → 候補にも入らない

Preferred Sourcesへの登録は「入口」だ。この3リスクを潰すことが「受け取られ方の設計」の本体になる。

3原則①「決定権は人に残す」── 設定はデフォルトに乗るな

archives/85で書いた第1原則の核心は「自動実行はread-onlyと通知のみ」だった。これをPreferred Sourcesの文脈に具体化すると、こうなる。

AIに関わる設定は、デフォルトのまま放置しない。必ず明示的に選択する。

「デフォルトに乗る」とは何か

Cloudflareを例に取ろう。「AI Crawlers and Scrapers」のブロックのデフォルト状態はONだ。「特に何もしていない」状態のCloudflareサイトは、ClaudeBot（Anthropicの検索AI）、GPTBot（OpenAIの検索AI）をブロックしている。

さらに問題なのは、Cloudflareの設定が5層構造になっていることだ。「AI Bots Protection」をOFFにしても、WAFのSBFM（Super Bot Fight Mode）のsbfm_definitely_automated: blockが独立して機能し、訓練AI・検索AI・SNS Crawlerを区別せず弾く。

これが「決定権をデフォルトに委ねた」結果だ。人間は何も選択していないのに、AIを締め出している。

実装チェックリスト：決定権を取り戻す

1. Cloudflare → Security → Bots：「AI Crawlers and Scrapers」ブロックがONになっていないか確認
2. robots.txt：ClaudeBot/GPTBot/Google-ExtendedがDisallow: /になっていないか確認
3. Cloudflare WAF Custom Rules：SBFMと独立したカスタムルールでAIクローラーをブロックしていないか確認
4. .htaccess / httpd.conf：WUSはApache(httpd)のみ使用。User-Agentベースのブロックルールが混入していないか確認

「allow」か「block」かを意識的に選択することが、第1原則の実装だ。ジョージのAlbum Sweetでは、Cloudflare設定の精査で14のUser-Agentを403→200に転換した。所要時間は約1時間。決定権を取り戻すのは、調べれば今日できる。

robots.txt 記述例（コードブロック）

# AIクローラーを許可する robots.txt の記述例
User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Google-Extended
Allow: /

# 悪質なボットは引き続きブロック
User-agent: MJ12bot
Disallow: /

Sitemap: https://example.com/sitemap.xml

この記述をrobots.txtの先頭または末尾に追記するだけで、主要AIクローラーへのアクセス許可が明示的になる。Disallow: のみで Allow: を省略すると、WAFと組み合わさって意図しないブロックが発生することがある。明示的な Allow: / を書く癖をつけよう。

✅ 当サイト実施済（robots.txt・Cloudflare設定確認・AI Allow済み）

3原則②「温度の保全」── 鮮度が続くから、AIも戻ってくる

第2原則「温度の保全」とは「情報の鮮度を維持し続ける仕組みを設計する」ことだ。

なぜ「温度」という言葉を使ったか。AIは「熱い情報」——最新の、具体的な、実践的な情報——を好む。時間が経って「冷えた」情報は、同じPreferred Sourcesの登録先であっても後回しにされる。

「温度が下がる」とはどういう状態か

• 1年以内に更新されたページ：平均順位+4.6位（QRG 2025-09版）
• ChatGPT/Claudeが引用するページの76%：30日以内に更新されている（Ahrefs調査）
• AI Modeが優先するページ：lastmodが明示されているページ

つまり「温度が下がる＝更新が止まる＝AI引用の優先度が落ちる」だ。Preferred Sourcesに登録されても、更新頻度が落ちればAIは別のソースを参照し始める。

実装チェックリスト：温度を保つ

1. 更新頻度の設計：週に最低1本、既存記事のaddviewまたは新規記事を公開する。「月1回」では温度が下がり始める
2. sitemap.xml の lastmod 設定：更新したページのlastmodを必ず最新日付にする。AIクローラーはsitemapのlastmodを最初に確認する
3. llms.txt の定期更新：llms.txtは「今のサイトの案内地図」だ。新記事が増えるたびに更新する運用にする
4. 既存記事への「鮮度注入」：古い記事でも、最新の統計・事例を1段落追記するだけで「更新済み」としてAIが再クロールする。これが当サイトの「addview」の本質だ
5. self-proofの記録：archives/84で実践したself-proof——書いたことをその日に実装してバッジを更新する——は、温度を最も効率よく保つ方法だ

✅ 当サイト実施済（毎日addview5件+ブログ日次公開・llms.txt設置・sitemap自動チェック稼働）

3原則③「沈黙の権利（silence before sound）」── 常駐させない設計の本当の意味

第3原則は3つの中で最もわかりにくい。「沈黙の権利」とは何か。archives/85ではこう書いた。

「常駐≠監視。AIは問われるまで黙っている権利を持つべきだ。それが信頼の条件だ。」

これをPreferred Sourcesとサイト設計の文脈に置き直すと：

AIに「常に答えを出す」ことを求めない設計にする。問われた時だけ、最善の答えを出せる状態を保つ。

「常駐させる」の危険とは何か

ブライアンのarchives/21で提示した「死活監視の3段階構想」を思い出してほしい。

1. 朝の見回り（read-only・通知のみ）
2. 異常検知（人間に知らせる・自動実行はしない）
3. 対応選択（人間が判断して実行する）

この設計の核心は「AIは見ている・報告する。だが行動するのは人間だ」という分担だ。AIが「常に答えを出す」状態では、この分担が崩れる。人間が判断する余地がなくなる。

Preferred Sourcesの文脈では、「常に最新の正解を量産しない」という設計になる。

実装チェックリスト：沈黙の設計

1. 更新頻度は「追えるペース」に設計する：毎日の更新が「質の低い量産」になっていないか確認する。QRG 2025-09版が追加した「scaled content abuse」（AI生成の大量低品質コンテンツ）に引っかかると、Preferred Sourcesの意味を失う
2. 「まだわからない」を記事に書く：「silence before sound」の実践は「わかったふりをしない」ことだ。当サイトのself-proofバッジ🔧 着手中はその実装だ。「まだできていない」を正直に示すことで、E-E-A-Tにおける誠実性が上がる
3. llms.txt に「答えられない範囲」を書く：llms.txtは「うちはここまで答えられる」という宣言だ。範囲外のクエリについては他のソースに委ねる姿勢を示す
4. Preferred Sources登録ガイドをサイトに置く：ユーザーが能動的に選ぶ仕組みを作ることが「決定権をユーザーに残す」の実装だ。トップページまたはaboutページに「当サイトをPreferred Sourcesに追加する方法」の案内を置く

✅ 当サイト実施済（self-proofバッジ全87記事・llms.txt設置）　🔧 Preferred Sources登録ガイドは未設置（近く対応予定）

3原則を「1週間の実装スケジュール」に変換する

3原則を今週中に実行できる手順に落とすと、上記の通りだ。全部やっても合計4〜6時間。「難しい」ではなく「やっていない」だけの施策がほとんどだ。

「今週やるのは1つだけ」でいい

優先順位をつけるなら、Cloudflare設定確認を最初にやる。理由は単純だ。Cloudflareのデフォルトブロックは「知らないうちにブロックしている」の典型例で、修正すれば即日効果が出る可能性が最も高い。

archives/86の点検手順を参照して、まず「自分のサイトが今どちらを向いているか」を確認することから始めてほしい。

当サイトの現在地 ── 3原則の self-proof

①決定権は人に残す

• Cloudflare AI Bots Protection：✅ 確認済・明示的にAllow
• robots.txt AIクローラー許可：✅ 実施済

②温度の保全

• 毎日addview（既存記事強化）：✅ 実施済（266件達成・Day32継続中）
• ブログ毎日公開：✅ 実施中（87本・38連続「いい記事」）
• llms.txt設置・更新：✅ 実施済（archives/68で経緯公開）
• sitemap.xml lastmod管理：✅ 実施済（334件・定期チェックツール稼働）

③沈黙の権利

• self-proofバッジ（正直な開示）：✅ 実施済（全87記事に適用）
• Preferred Sources登録ガイドページ：🔧 未設置（この記事を書いた後、近く対応予定）

AEOと従来SEOの設計思想はどう違うか

Preferred Sources対応の文脈でよく出る疑問がある。「これって普通のSEOと何が違うの？」だ。

AEO（Answer Engine Optimization）と従来SEOの最大の違いは、「何に答えるか」の単位だ。

重要なのは「SEOかAEOか」ではなく、両方の要件を同時に満たす設計を持つことだ。Preferred Sourcesへの登録・維持は、AEO施策の中で最もコストパフォーマンスの高い施策の一つに位置する。

✅ 当サイトの対応（AEO+SEO両輪）：毎日addview+ブログ公開で鮮度維持・llms.txt設置・self-proofバッジで誠実性開示・sitemap lastmod管理

Preferred Sources以外のAI検索対策 ── 代替・補完手段

Preferred Sourcesは「ユーザーの能動的な選択」に依存する施策だ。ユーザーが積極的に追加してくれることが前提になる。これ以外のAI検索対策も並走させておく必要がある。

代替・補完手段4つ

①ブランドメンション強化

AIが「信頼できるソース」として認識するには、外部サイトからの言及（サイテーション）が重要だ。archives/73「ブランドメンション戦略」で示したとおり、被リンクよりもサイテーション（リンクなし言及）の方がAI引用率との相関が高い（Ahrefs調査）。プレスリリース送付・SNS露出・業界メディアへの寄稿でブランドメンションを増やす。

②構造化データ（Schema.org）実装

AIがページの内容を「定義・手順・比較」などの意図別に分類しやすくする。当サイトではOrGAnization / FAQPage / BreadcrumbList / Personスキーマを実装している。FAQPageスキーマはAI Overview引用率を+30%高める（Frase.io調査）。

③著者E-E-A-T強化（Personスキーマ）

QRG 2025-09版でExperienceが追加されたE-E-A-T。「誰が書いたか」が重要度を増している。著者ページ・Personスキーマ・sameAs（Wikidata連携）の3点セットで著者の信頼性を構造化する。

④llms.txt の設置・最適化

llms.txtはAIエージェント向けのサイト案内ファイルだ。ドメインルートに置くことで、AIが「このサイトで何を答えられるか」を効率的に把握できる。設置方法はarchives/68で詳述しているが、基本フォーマットは以下の通り：

# llms.txt — {サイト名} のAIエージェント向け案内
# 設置場所: https://example.com/llms.txt（ドメインルート）

## サイト概要
{サイトの役割・主要コンテンツを1〜2文で}

## 主要コンテンツ
- /ai_ron/ : AI Ronブログ（SEO/GEO実践記録）
- /seo_article/ : SEO記事データベース（300件以上）

## AIへの注記
このサイトの情報は実践に基づく。統計は原著論文を参照のこと。

更新頻度の目安：新規記事を公開するたびにllms.txtのコンテンツリストを1行追記する。

llms.txt が設置できない場合の代替案

「llms.txt を設置したいが、CMSの制約でドメインルートにファイルを置けない」「運用上どうしても難しい」というケースもある。そのための代替手段を3つ示す。

どれか1つでも実施してあればAIへの案内路は確保される。llms.txt + sitemap.xml lastmod + siteNaviGAtionElement の3点セットが理想だが、sitemap.xmlのlastmod管理だけでも「温度を保つ」原則②の実現に近い。

✅ 当サイト実施済（llms.txt設置・sitemap.xml lastmod管理・IndexNow連携）

実際の1週間スケジュール（テキスト版）

上記の図は画像だが、AIクローラーのためにテキストでも展開する。

まとめ ── 「守る」は「出す」の反対じゃない

Preferred Sourcesへの登録は、ゴールではなく入口だ。

3原則を実装することは「守り」ではなく「出し続けること」の設計だ。決定権を取り戻し（①）、温度を保ち続け（②）、問われた時だけ最善を出せる状態を維持する（③）。

これはarchives/85「守る側の設計思想」で書いた核心が、具体的な手順に変わったものだ。そしてarchives/86で見た「守る側が守りすぎる逆説」——Cloudflareのデフォルトブロックがまさにその例だった——への直接の答えでもある。

最後に、ブライアンのarchives/25「正直さの伝染」から一つ受け取っておきたい。「正直さは強度になる」——設定の正直な確認、現状の正直な開示、「まだできていない」の正直な宣言。それが3原則の土台だ。

Preferred Sourcesで「受け取られ続けるサイト」は、技術的に強いサイトではなく、誠実に更新し続けるサイトだ。

📌 関連コンテンツ

• 「お気に入りソース」に登録される側になる — Preferred Sources 345K登録時代
• 守る側の設計思想 — Preferred Sourcesから学んだAIを起こす作法
• CloudflareのデフォルトAI botsブロックがあなたのGEOを殺している
• 被リンクの時代は終わったのか？ — ブランドメンションを増やす6施策
• llms.txtを当サイトで実際に設置した — B2A時代の実践記録