Cloudflare Content Signals Policyとrobots.txt AIクローラー設定

Cloudflare Content Signals Policy robots.txt AIクローラー 設定ガイド

この記事の結論: Cloudflare Content Signals Policyは、robots.txtにsearch・ai-input・ai-trainという3つのシグナルを追加し、「検索インデックス」「AI検索回答での引用」「AI学習」を別々に許可・拒否できる拡張仕様です。デフォルトはsearch=yes, ai-train=noで、ai-inputは中立のまま残されます。ただしこの仕組みはあくまで勧告的（advisory）であり、技術的な強制力はありません。引用は歓迎しつつ学習だけ拒否したいサイトは、Content Signalsで意思表示をしたうえで、AI Crawl ControlやWAFなど強制力のある手段を併用する必要があります。

最終更新日: 2026年07月14日

はじめに

「AIに学習されたくないが、AI検索では引用されたい」というニーズは、2026年に入ってから多くのサイト運営者が抱える悩みになっています。従来のrobots.txtはAllowとDisallowしか持たず、クローラーを通すか通さないかの二択でした。ところが実際には、同じクローラーが「取得したコンテンツを検索インデックスに使う」「AI検索の回答生成に使う」「AIモデルの学習データに使う」という複数の目的で流用されるケースが増えており、二択のルールでは意図を正確に表現できません。

この課題に対してCloudflareが2025年10月に発表したのが、Content Signals Policyです。robots.txtの記法を拡張し、コンテンツが取得された後に「どう使われることを許可するか」まで踏み込んで宣言できるようにした仕組みです。全プランで利用可能で、既存のrobots.txtと共存する形で追記できます。

本記事では、Content Signals Policyの3つのシグナルの意味、デフォルト設定の読み方、手動でのrobots.txt記述方法、Cloudflareダッシュボードでの設定手順、そして最も重要な「advisory＝強制力がない」という限界とその補完策までを、実装コードとともに解説します。特にaiseo-llmo.comはLLMOメディアとしての立場から、過剰にブロックしてAI検索での引用機会を失わないための設計にも重点を置きます。

→ 詳しくはAI検索最適化ガイド（AIO・AEO・GEO・LLMO）

Content Signals Policyとは何か

Content Signals Policyは、robots.txtの標準的なUser-agent/Allow/Disallowディレクティブに、新しくContent-Signalという行を追加する拡張仕様です。従来のrobots.txtが答えていたのは「このパスをクロールしていいか」という一問だけでした。Content Signals Policyはこれに加えて、「クロールして取得したコンテンツを、その後どう使っていいか」という二問目に答えます。

クロール可否と利用目的は本来別の問題です。たとえば「検索エンジンにインデックスされることは歓迎するが、無断でAIの学習データにされるのは避けたい」というサイトは非常に多く存在します。従来のrobots.txtではこの二つの意図を分離して表現する手段がなく、Disallowで全体を拒否するか、Allowで全体を許可するかしかありませんでした。Content Signals Policyは、この間にあるグラデーションを表現するための語彙を提供します。

仕様自体はCloudflareが単独で策定したものですが、robots.txtという既存の枠組みを拡張する形を取っているため、対応していないクローラーであっても既存のAllow/Disallow部分は問題なく解釈できます。新しい行を追加しても既存のクロール制御が壊れることはありません。

→ 詳しくはLLMOとは？AI検索時代の新SEO完全ガイド

3つのContent Signal：search・ai-input・ai-trainの意味

Content Signals Policyが定義するシグナルは3種類です。それぞれ独立してyesまたはnoを指定できます。

search（検索インデックス）

コンテンツを従来型の検索エンジンのインデックスに使ってよいかを示すシグナルです。Google検索やBing検索など、キーワード検索の結果に表示させる目的での利用を指します。多くのサイトにとって、検索流入は主要なトラフィック源であるため、基本的には許可（yes）が選択されます。

ai-input（AI検索回答での利用）

コンテンツを、生成AIが検索クエリに答える際の入力（グラウンディングソース）として使ってよいかを示すシグナルです。ChatGPT SearchやPerplexity、Google AI Overviewsのような、ユーザーの質問にリアルタイムで回答を生成する仕組みの中で、あなたのページの内容を参照・引用してよいかという意思表示にあたります。ここで許可すると、AI検索の回答内にサイト名やリンクとともに引用される機会が生まれます。

ai-train（AIモデルの学習利用）

コンテンツを、AIモデル自体の訓練データとして使ってよいかを示すシグナルです。ここで許可すると、あなたが書いた文章の一部がモデルのパラメータに「記憶」される可能性があります。一度学習されたコンテンツは、後から拒否に切り替えても既存モデルからは基本的に除去できません。多くのサイト運営者がここをnoにする理由は、著作権や競争優位性の観点から、自社コンテンツがそのまま競合の学習材料になることを避けたいためです。

3シグナルの比較表

この3行構成が、Content Signals Policyの核心です。従来のrobots.txtが「通す/通さない」の一段階だったのに対し、取得後の用途を3段階に分けて意思表示できるようになった点が最大の変化です。

デフォルト設定と各値の効果

Cloudflareが提示するデフォルト設定はsearch=yes, ai-train=noです。ai-inputについてはデフォルト値が設定されておらず、中立のまま残されます。

この設計にはCloudflareの明確な方針が反映されています。検索インデックス化は従来から広く許容されてきた慣行であるためyesがデフォルトになる一方、AI学習への利用は同意なく行われることへの懸念が強いためnoがデフォルトになっています。そしてai-inputについては、「検索エンジンでの表示は許すがAI検索での引用は拒否したい」というサイトと、「AI検索での引用こそ積極的に得たい」というサイトの両方が存在するため、Cloudflareは顧客の意向を代わりに推測しない方針を取り、あえて未設定のまま残しています。

この点は、AI検索での露出を狙うLLMOの観点からは重要な意味を持ちます。ai-inputが未設定のままだと、AIクローラー側の実装によって解釈が分かれる可能性があります。引用獲得を明確に狙うサイトであれば、ai-input=yesを明示的に指定しておくことが望ましいといえます。

デフォルト値と明示指定の効果対応表

robots.txt手動設定の書き方

Content Signals Policyは、既存のrobots.txtにContent-Signalという行を追加するだけで導入できます。DNSやサーバー設定の変更は不要で、テキストファイル1つを編集すれば反映されます。

基本形：引用歓迎・学習拒否パターン

多くのメディアサイトにとって現実的な選択肢は、検索とAI引用は歓迎しつつ学習だけを拒否する設定です。

User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

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

この設定は、従来型検索エンジンへのインデックス許可と、AI検索での引用許可を維持しながら、モデル訓練への流用だけを明確に拒否する意思表示です。LLMOの観点から、AI検索での可視性を確保しつつコンテンツ資産を守りたいサイトにとって基準となる設定といえます。

全拒否パターン：AI関連の利用を一切許可しない

学習利用だけでなく、AI検索での引用そのものを望まないサイトもあります。会員限定コンテンツや、AI経由での要約流通を望まない専門メディアなどが該当します。

User-Agent: *
Content-Signal: search=yes, ai-input=no, ai-train=no
Allow: /

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

検索エンジンのインデックスだけは維持しつつ、AI検索の回答内での利用と学習利用の両方を拒否する設定です。ただし後述する通り、この設定はあくまで勧告であり、AI Crawl ControlやWAFと組み合わせない限り技術的な強制力は持ちません。

全許可パターン：二次利用をすべて歓迎する

オープンなナレッジベースやコミュニティ発の情報発信サイトなど、コンテンツの拡散自体を目的とするサイトでは、全面的な許可が合理的な選択になる場合があります。

User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /

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

パス別に使い分けるパターン

会員限定エリアと公開エリアが混在するサイトでは、User-Agentブロックとパス指定を組み合わせて、公開エリアはAI引用を歓迎しつつ、会員エリアは全面的に保護する設定が可能です。

# 公開記事エリア：検索・AI引用は歓迎、学習は拒否
User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /articles/
Allow: /glossary/

# 会員限定エリアはクロール自体を拒否
User-Agent: *
Disallow: /members/
Disallow: /premium/

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

なお、Content-SignalはUser-Agentごとに個別に指定することも可能です。特定のAIクローラーだけ扱いを変えたい場合は、User-Agent: GPTBotのように個別ブロックを作成し、そのブロック内にContent-Signalを記述します。

# GPTBotには学習利用を明示的に拒否
User-Agent: GPTBot
Content-Signal: ai-train=no
Allow: /

# OAI-SearchBotにはAI検索引用を明示的に許可
User-Agent: OAI-SearchBot
Content-Signal: ai-input=yes
Allow: /

Managed robots.txt（ダッシュボード）での設定手順

robots.txtファイルを直接編集する手間を省きたい場合、CloudflareはダッシュボードからContent Signalsを設定できるManaged robots.txt機能を提供しています。DNSがCloudflareを経由しているドメインであれば、以下の手順でGUIから設定できます。

1. Cloudflareダッシュボードにログインし、対象ドメインを選択する
2. 左メニューの「Overview」を開く
3. 「Control AI Crawlers」タブを選択する
4. 「Managed robots.txt」セクションを開く
5. 「Direct AI bot traffic via robots.txt」のトグルを有効化する
6. search / ai-input / ai-train それぞれの許可・拒否を選択する
7. 保存すると、Cloudflareがオリジンのrobots.txtにContent-Signal行を自動的に注入・管理する

手動編集とManaged robots.txtの比較表

パス単位で細かく制御したい場合や、CMS側でrobots.txtを動的生成しているサイトでは手動編集が適しています。一方、とにかく早く標準的な設定を反映させたい場合はManaged robots.txtが手間なく導入できる選択肢です。

→ 詳しくはAIクローラーのrobots.txt設定とAI検索引用戦略【2026年版】

advisory＝強制力なしの限界とAI Crawl Control・WAFとの併用

Content Signals Policyを導入する際に必ず理解しておくべき最も重要な点は、この仕組みが**advisory（勧告的）**であるということです。robots.txt自体がそもそも「お願い」であり「ファイアウォール」ではないのと同様に、Content Signalsも技術的な強制力を持ちません。

具体的には、Content-Signal: ai-train=noと記述しても、それを読み取って行動を変えるかどうかはクローラー運営元の自主的な判断に委ねられます。誠実にルールを守るクローラーであれば意図通りに動きますが、ルールを無視してコンテンツを収集するボットに対しては何の効力も持ちません。実際、一部の海外メディアの調査ではrobots.txtのDisallow指定そのものを無視してクロールを続けるボットの存在が報告されており、Content Signalsについても同様のリスクが指摘されています。

つまりContent Signals Policyは、「意思表示」としての価値はある一方、「防御」としては不十分です。本気でAIクローラーの挙動を制御したいサイトは、以下の技術的な手段を組み合わせる必要があります。

AI Crawl Controlとの併用

CloudflareのAI Crawl Controlは、実際にAIクローラーのアクセスをブロック・許可・あるいは402 Payment Requiredで課金するといった、技術的な強制力を持つ制御機能です。Content Signalsが「意思表示」のレイヤーだとすれば、AI Crawl Controlは「執行」のレイヤーにあたります。

• ブロック: 指定したAIクローラーのリクエストをネットワークレベルで遮断する
• 許可: 指定したAIクローラーのみを通過させる
• 402 Payment Requiredでの課金: クロールごとに課金を要求し、支払いに応じたクローラーだけを通す仕組み（Pay per Crawlに近い発想）

WAF（Web Application Firewall）との併用

Bot Management機能を使えば、User-Agent文字列の詐称や、正規のクローラーを装った不正アクセスを検知してブロックできます。Content Signalsで意思表示をしていても、悪意あるスクレイパーがブラウザを偽装してアクセスしてくるケースには対応できないため、WAFレベルでの検知が補完的に必要になります。

制御手段の比較表

結論として、「Content Signalsで方針を宣言し、AI Crawl ControlとWAFで実際に執行する」という二段構えが、2026年時点での現実的な防御設計です。

AI検索で引用されたい場合と学習を拒否したい場合の設定使い分け

LLMOメディアとしての立場からは、この使い分けが最も実務的に重要なテーマです。過剰にブロックしてしまうと、せっかく作成したコンテンツがAI検索の回答に一切登場しなくなり、露出機会そのものを失うリスクがあります。

引用を狙う側が陥りやすい失敗パターン

「AIに使われるのが怖いから」という理由で、ai-inputまで一律に拒否してしまうサイトが少なくありません。しかしai-inputを拒否すると、ChatGPT SearchやPerplexity、AI Overviewsといった生成AI検索の回答内で自社サイトが引用される可能性そのものが失われます。これは、検索流入の一部がAI検索へとシフトしつつある2026年の状況において、機会損失につながりかねません。

拒否すべきは「学習に使われること」であり、「検索回答で参照・引用されること」ではないケースが大半です。両者を混同せず、ai-train=noとai-input=yesを明確に分けて指定することが、引用機会を守りながらコンテンツ資産を保護する鍵になります。

用途別の推奨設定パターン

設定変更後に確認すべきこと

設定を変更した後は、以下の観点で効果を検証します。

1. サーバーアクセスログで、OAI-SearchBotやPerplexityBotなど検索引用用クローラーのアクセスが継続しているかを確認する
2. ChatGPT Search・Perplexity・Google AI Overviewsで自社名や主要キーワードを検索し、引用の有無を追跡する
3. GA4の参照元レポートでchatgpt.com・perplexity.aiなど生成AI検索からの流入が維持・増加しているかを見る
4. ai-train=noにしたことで学習用クローラー（GPTBot・ClaudeBot・Google-Extendedなど）のアクセス傾向がどう変化したかを比較する

ai-input=yesにしていても、実際に引用が増えるかどうかはコンテンツの質・構造・出典の明示度に依存します。Content Signalsはあくまでアクセス制御の意思表示であり、引用されるかどうかを保証する仕組みではない点には注意が必要です。

→ 詳しくはLLMO完全ガイド

Content Signals Policy vs 従来のrobots.txt Disallow vs Pay per Crawl

AIクローラー対策の選択肢は複数存在し、それぞれ強制力・粒度・目的が異なります。導入前にこの違いを整理しておくことが重要です。

Content Signals Policyは「意思表示のコスト」が極めて低い一方、実効性を担保するには他の仕組みとの併用が前提になります。逆にPay per Crawlのような有償クロールの仕組みは実効性と収益性を兼ね備えますが、導入と運用のハードルは相対的に高くなります。多くのサイトにとっての現実的な出発点は、まずContent Signals Policyで意思表示をしたうえで、必要に応じてAI Crawl Controlのような強制力のある仕組みへ段階的に移行することです。

llms.txtとContent Signalsの違い

llms.txtとContent Signals Policyは、どちらもAI関連の設定ファイルという点で混同されがちですが、担っている役割はまったく異なります。

両者は競合する仕組みではなく、補完関係にあります。robots.txtとContent Signalsで「何を・どう使ってよいか」というアクセス制御の方針を定め、llms.txtで許可した範囲のコンテンツについて「何が重要か」という要約を提供する、という二段構えが整理された設計といえます。

→ 詳しくはllms.txtは必要か不要か？Google公式見解とエージェントコマースの結論

OAI-SearchBot・PerplexityBot・GPTBot・ClaudeBotそれぞれの挙動

Content Signalsは仕様として全クローラーに向けて公開されていますが、実際にどう解釈するかはクローラー運営元ごとの実装に依存します。

• OAI-SearchBot（OpenAI）: ChatGPT Searchのインデックス構築用クローラーで、検索回答での引用に関わります。ai-inputの許可設定が特に関係するクローラーです。
• GPTBot（OpenAI）: モデルの学習データ収集用クローラーです。ai-train=noの意思表示が主に関係します。OAI-SearchBotとは別のクローラーである点に注意が必要です。
• PerplexityBot（Perplexity）: 回答生成時の引用ソース取得に使われます。Perplexityは引用元へのリンクを回答内に明示する仕様のため、ai-input=yesにしておく実務的な価値が比較的高いクローラーです。
• ClaudeBot（Anthropic）: 学習データ収集用途で使われます。AnthropicはClaudeBot（学習用）とClaude-Web（検索引用用のリアルタイム参照）を分離しているため、目的に応じて個別のUser-Agentブロックで制御するのが確実です。

現時点でCloudflareの発表内容や開発者向けドキュメントには、各クローラーがContent Signalsのどの項目まで厳密に遵守しているかの詳細な一覧は限定的にしか公開されていません。導入後はサーバーログで実際の挙動を継続的に確認し、想定通りに機能しているかを検証する運用が現実的です。

設定しても引用が減らないか（引用を狙う側の視点）

「学習だけ拒否すれば引用は維持できる」という理屈は理論上正しいものの、実務上は運用の細部で意図せず引用機会を失うケースがあります。

注意点1：User-Agentブロックの粒度がずれている

User-Agent: *に対してai-input=noを設定してしまうと、全てのAIクローラーからの引用が一律に拒否される状態になります。「特定のクローラーだけ学習を拒否したい」という意図であれば、User-Agent: GPTBotのように個別ブロックでai-train=noを指定し、User-Agent: *側のai-inputはyesのまま維持する必要があります。

注意点2：DisallowとContent-Signalの矛盾

Disallow: /でクロール自体を拒否しているパスに対してContent-Signal: ai-input=yesと書いても、そもそもクロールされていなければ意味を持ちません。クロール可否（Allow/Disallow）と利用目的（Content-Signal）は別のレイヤーであることを忘れず、両方の整合性を確認します。

注意点3：キャッシュ・CDN側の遅延

Cloudflare経由でrobots.txtを配信している場合、設定変更が末端のクローラーに反映されるまでにキャッシュの影響でタイムラグが生じることがあります。設定変更直後に検証する場合は、この遅延を考慮したうえで数日単位で効果を観察します。

引用を狙う側にとっての結論は、「不安だからと一律にブロックするのではなく、学習利用と検索引用を明確に切り分けて意思表示する」ことに尽きます。過剰な防御は、AI検索経由の新しい流入チャネルを自ら閉ざす結果になりかねません。

日本語サイトで導入する際の注意点

Content Signals PolicyはCloudflareのグローバル機能として提供されているため、日本語サイトでも同様に利用できますが、いくつか留意すべき点があります。

第一に、Cloudflareのダッシュボード表記や公式ドキュメントは基本的に英語が主体であり、日本語での情報がまだ限定的です。Managed robots.txtの設定画面も英語表記が中心のため、search・ai-input・ai-trainという用語の意味を正しく理解したうえで操作する必要があります。

第二に、日本語コンテンツに対するAIクローラーのアクセス頻度は、英語コンテンツと比較して相対的に低い傾向が報告されています。したがってai-input=yesに設定しても、英語圏サイトほど即座に引用効果を実感できない場合があります。効果測定には英語圏サイトよりも長いスパンでの観察が必要になることがあります。

第三に、日本語サイトの多くはCMSやサーバー構成が多様で、robots.txtがビルド時に静的生成されるケースと、CMS側で動的生成されるケースが混在します。Content-Signal行を追加する際は、デプロイフローのどこでrobots.txtが生成されているかを確認し、手動編集した内容がビルドで上書きされないよう注意が必要です。

402 Payment Requiredで課金する仕組み

Content Signals Policyそのものには課金機能はありませんが、Cloudflareが同時期に展開しているAI Crawl Controlの一部機能として、HTTPステータスコード402（Payment Required）を用いたクロール課金の仕組みが提供されています。

この仕組みは、AIクローラーがコンテンツを取得しようとした際に、Cloudflareのエッジ側で402レスポンスを返し、料金の支払いが確認できたクローラーにのみ実際のコンテンツを提供するという流れです。従来「無料で使われるか、完全にブロックするか」の二択だった状況に対して、「対価を払うなら使わせる」という第三の選択肢を提供します。

Content Signals Policyのai-trainやai-inputをnoにする代わりに、この課金の仕組みを使ってコンテンツへのアクセスに対価を求めるという運用も、収益化を重視するメディアにとっては選択肢の一つになります。ただし決済インフラとの連携や、クローラー側の支払い対応状況に依存するため、導入のハードルはContent Signals Policyの単純な意思表示よりも高くなります。

WordPressプラグインでの代替手段

サーバー側の設定変更やCloudflareのダッシュボード操作が難しい環境では、WordPressプラグインを使ってContent Signals相当の設定を代替する方法もあります。robots.txtの内容を管理画面から編集できるSEOプラグイン（All in One SEOやYoast SEOなど）の「robots.txt編集」機能を使えば、Content-Signal行をテーマやサーバー設定を触らずに追記できます。

# WordPressのSEOプラグインのrobots.txt編集画面に貼り付ける例
User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

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

ただしこの方法はCloudflareのAI Crawl Controlのような強制力のある機能とは連動しないため、あくまで「意思表示」のレイヤーにとどまる点は変わりません。強制力を求める場合は、WordPress側のセキュリティプラグインでBot Managementに相当する機能を別途導入するか、CloudflareなどのCDN層でのアクセス制御を検討する必要があります。

まとめ：段階的な導入ステップ

最後に、Content Signals Policyを導入する際の現実的なステップを整理します。

1. 現状把握: サーバーアクセスログを確認し、どのAIクローラーがどの程度アクセスしているかを把握する
2. 方針決定: 「引用は歓迎、学習は拒否」など、サイトごとの方針をsearch・ai-input・ai-trainの3値で言語化する
3. robots.txtへの反映: 手動編集またはManaged robots.txtでContent-Signal行を追加する
4. 効果検証: 1〜2週間ほどログとAI検索での引用状況を観察する
5. 強制力の追加検討: 意思表示だけで不十分と判断した場合、AI Crawl ControlやWAFの導入を検討する

Content Signals Policyは導入コストが低い一方、単体では防御手段として不完全という性質を理解したうえで、自社の目的に応じた組み合わせを設計することが重要です。

よくある質問

Q1. Content Signals Policyを設定すればAIクローラーは確実に指示に従いますか？

A. 確実ではありません。Content Signals Policyはadvisory（勧告的）な仕組みであり、法的・技術的な強制力を持ちません。誠実にルールを守るクローラーには有効ですが、無視するボットに対しては効果がなく、強制したい場合はAI Crawl ControlやWAFの併用が必要です。

Q2. AI検索での引用を維持しつつ学習だけ拒否するにはどう書けばよいですか？

A. Content-Signal: ai-input=yes, ai-train=noと明示的に指定します。ai-inputを歓迎する意思表示をしつつ、ai-trainだけを拒否することで、検索回答での引用機会を保ちながら学習データへの流用を避ける設定になります。

Q3. llms.txtとContent Signals Policyは何が違いますか？

A. llms.txtはサイトの主要コンテンツをAIに案内する要約ファイルで、Content Signals Policyは取得後のコンテンツ利用目的（検索・AI引用・AI学習）を宣言する仕組みです。両者は競合せず、robots.txtでアクセス制御の方針を定めたうえでllms.txtが補完する関係にあります。

Q4. OAI-SearchBot・PerplexityBot・GPTBot・ClaudeBotはそれぞれどう扱えばよいですか?

A. OAI-SearchBotとPerplexityBotは検索引用用、GPTBotとClaudeBotは学習用に分類されます。学習用クローラーにはai-train=no、検索引用用クローラーにはai-input=yesを意識した個別のUser-Agentブロックで設定すると、目的に応じた制御がしやすくなります。

Q5. 設定しても引用が減ってしまうことはありますか?

A. あります。User-Agent: *に対して誤ってai-input=noを設定してしまうと、全AIクローラーからの引用機会を一律に失います。学習拒否と引用許可を混同せず、個別のUser-Agentブロックで意図通りに分離できているかを確認することが重要です。

Q6. 日本語サイトで導入する際に特に注意すべきことは何ですか?

A. Cloudflareのダッシュボード表記が英語主体であること、日本語コンテンツはAIクローラーのアクセス頻度が英語圏より低い傾向があること、CMSのビルドフローでrobots.txtが上書きされないよう確認が必要なことの3点です。

Q7. 402 Payment Requiredによる課金の仕組みとContent Signals Policyの関係は?

A. 402課金はAI Crawl Controlの機能であり、Content Signals Policy自体には課金機能はありません。ai-train=noのような意思表示に加えて、対価を払うクローラーにのみアクセスを許可する仕組みとして併用できる位置づけです。

Q8. WordPressサイトでも導入できますか?

A. できます。All in One SEOやYoast SEOなどのプラグインのrobots.txt編集機能からContent-Signal行を追記可能です。ただしこの方法は意思表示のレイヤーにとどまり、強制力を求める場合はCDN層でのアクセス制御を別途検討する必要があります。

Q9. Content Signals PolicyとAI Crawl Controlはどちらを先に導入すべきですか?

A. Content Signals Policyを先に導入するのが自然です。導入コストが低く、まず意思表示の方針を固めたうえで、実効性が必要だと判断した範囲についてAI Crawl Controlのような強制力のある手段を追加する段階的なアプローチが現実的です。

Q10. デフォルト設定のままで問題ありませんか?

A. サイトの方針次第です。デフォルトのsearch=yes, ai-train=noは多くのサイトにとって妥当な出発点ですが、ai-inputが中立のままだとAI検索での引用意図が不明確になるため、引用獲得を積極的に狙うサイトはai-input=yesを明示的に指定することを推奨します。

関連用語

• robots.txt
• クローラー
• llms.txt
• LLM
• RAG
• Perplexity
• ChatGPT Search
• GEO
• インデックス
• AI Overview

関連記事

• AI検索最適化ガイド（AIO・AEO・GEO・LLMO）
• LLMOとは？AI検索時代の新SEO完全ガイド
• LLMO完全ガイド
• AIクローラーのrobots.txt設定とAI検索引用戦略【2026年版】
• AIクローラーのアクセスログ分析 GPTBot・ClaudeBotとGEO
• llms.txtは必要か不要か？Google公式見解とエージェントコマースの結論
• マルチモーダルAIクローラーと動画理解最適化
• RSL(Really Simple Licensing)とは?robots.txtでAIライセンスを設定する方法