note・YouTube・Instagram・TikTok…主要プラットフォームは結局AIを遮断しているのか【2026年実測】

前回は、curl を使って「自社サイトがAIに読まれているか」を自分で確認する方法を紹介しました。

<　自社サイトがAIに読まれているか、curl 一発で調べる方法コピペで使えるチェックコマンド付き

今回はその視点を外に向けて、主要なプラットフォームは、AIに対してどういう姿勢を取っているのかを実際に調べてみます。

自社の情報をAI検索に拾わせたいとき、どこで発信するかは意外と重要です。発信先のプラットフォーム自体がAIを遮断していれば、そこに置いたコンテンツはAIに届きにくくなります。note、YouTube、Instagram、TikTok の4つを、前回と同じ curl で実測してみました。

前提：AI遮断には「層」がある

本題に入る前に、ひとつ押さえておきたいことがあります。「AIを遮断する」と一口に言っても、その手段はいくつかの層に分かれます。

ひとつは robots.txt による宣言。「このボットは来ないでほしい」というルールを書いたファイルで、行儀のよいAIはこれに従います。ただしこれはあくまで“お願い”で、強制力はありません。もうひとつは サーバーやCDNでの物理的な遮断。特定のアクセスに 403（拒否）を返して、そもそも通さない方法です。さらに、ログインの壁でコンテンツ自体を非公開にする方法や、利用規約で縛る方法もあります。

重要なのは、これらは別の層なので、片方だけ見ても実態はつかめないという点です。実際に測ってみると、そのことがよく分かります。

実測の方法

以下の数字は、前回紹介したのと同じ curl コマンドで確認しました。誰でも再現できます。robots.txt の中身を取得し、トップページにAIボットを名乗ってアクセスしてステータスコードを見る、という流れです。

# robots.txt の中身を見る
curl -A "ClaudeBot" -s https://（対象サイト）/robots.txt | head -30

# AIボットを名乗ってトップページのステータスを見る
curl -A "ClaudeBot" -s -o /dev/null -w "%{http_code}\n" https://（対象サイト）/

ケースA：YouTube──入り口は開放、守りは規約側

YouTube の robots.txt には、AIクローラーを名指しで拒否する記述がありませんでした。塞いでいるのは /api/ などの内部エンドポイントや、検索結果・ログイン画面といった動的ページが中心で、動画の視聴ページ（/watch）自体は対象外です。実際にAIボットで /watch ページを叩くと、正常に取得できました。

ただし、これは「AIが自由に使ってよい」という意味ではありません。YouTube は動画データや字幕を内部APIと認証の裏側に置いており、大量取得や無断利用は利用規約で制限しています。入り口は広く開けておき、中身は規約と技術（認証・API制限）で守る、という多層的なやり方です。

ケースB：note──CDNレベルで物理遮断

note を調べると、様子が一変します。AIボットを名乗ってアクセスすると、403（拒否）が返ってきました。しかもレスポンスの server はCDN（CloudFront）で、note本体のサーバーに到達する前の段階で弾かれています。

これは robots.txt がどう書かれているか以前に、CDNのレベルで物理的にAIを遮断していることを意味します。クリエイターの創作物が資産であるプラットフォームとして、“お願い”ではなく確実に止める方法を選んでいる、という姿勢が読み取れます。

ケースC：Instagram──robots.txtでAIを名指し拒否

Instagram（Meta）の robots.txt は、ClaudeBot GPTBot Google-Extended PerplexityBot Applebot-Extended といったAIボットを、**ひとつずつ名指しで Disallow: /（全体拒否）**していました。ファイルの冒頭には「Metaの書面による許可なく自動収集を禁ずる」という注意書きも明記されています。方針として、はっきりAIによる収集を拒否している形です。

ところが、AIボットでトップページのステータスを見ると 200 が返りました。ここが今回いちばん興味深い点です。

ケースD：TikTok──20以上のAIボットを列挙して拒否

TikTok（ByteDance）はさらに徹底していました。robots.txt に、GPTBot ClaudeBot PerplexityBot CCBot をはじめ、Bytespider（TikTok自社の収集ボット）や meta-externalagent（Metaのボット）まで含め、20以上のAI系ボットをまとめて列挙し Disallow: /。そのうえで、それ以外のボットには /foryou と /discover だけを部分的に許可する、という限定的な開放でした。ほぼ全方位でAIを拒否する強い姿勢です。

そして TikTok も、トップページのステータスは 200 でした。

なぜ「拒否」なのに 200 なのか

Instagram も TikTok も、robots.txt では明確にAIを拒否しているのに、curl のステータスは 200。これは矛盾ではありません。robots.txt はあくまで“ルールの宣言”であって、サーバーが物理的にアクセスを止めているわけではないからです。

行儀のよいAIクローラーは、robots.txt に Disallow と書かれていれば、ステータスが 200 でも取得を控えます。つまり Instagram・TikTok は「ルールで来ないでと伝える」層で守っている。一方 note は、そのルールに頼らず「サーバーで通さない」層（403）で守っている。同じ『AI拒否』でも、使っている層が違うわけです。

これは前回の記事で触れた「ステータスコードだけ見ても、robots.txt だけ見ても、片方では判断を誤る」という話の、そのままの実例になっています。robots.txt を見なければ Instagram・TikTok の拒否姿勢は分かりませんし、ステータスだけ見れば「200だから開いている」と誤解してしまいます。

4媒体の横断整理

実測結果を並べると、主要プラットフォームが4者4様の守り方をしていることが見えてきます。YouTube は robots.txt を広く開け、守りを規約側に置く。note はCDNで物理的に 403 遮断する。Instagram と TikTok は robots.txt でAIボットを名指し拒否する。手段は違えど、note・Instagram・TikTok の3つは、方向としては「AIに対して閉じる」側に寄っていました。

ユーザーの投稿や創作が資産となるプラットフォームほど、その資産をAIに流用されることに慎重になる、という傾向が読み取れます。もっとも、これらの方針は各社の判断で頻繁に変わりますし、robots.txt を無視するボットも存在するため、「これで完全に守られている／使われない」と言い切れるものではない点は付け加えておきます。

示唆：AIに拾わせたい情報は、どこに置くか

ここから、自社の発信戦略へのヒントが得られます。

note や Instagram、TikTok のような外部プラットフォームは、その時々の方針でAIに対して閉じる方向に動くことがあります。そこに置いたコンテンツが、AIに拾われるかどうかは、プラットフォーム側の設定次第で、こちらではコントロールできません。

一方、自社サイト（オウンドメディア）であれば、AIに読ませるか否かを自分で決められます。前回の記事で見たように、遮断していれば解除できますし、逆に守りたければ遮断もできます。AIに確実に拾わせたい情報――会社の強み、専門的な知見、独自の事例――は、他社プラットフォーム任せにせず、コントロールできる自社サイトに“母艦”として置いておくのが、最も確実な選択肢になり得ます。

SNSやプラットフォームでの発信は、あくまで入り口として活用しつつ、核となる情報資産は自社サイトに集約する。AI検索時代においては、この基本方針の重要性があらためて増しているように思います。

比較表

以下4媒体のAIクローラーに対する方針をまとめました。

プラットフォーム	robots.txt	トップの応答	遮断の層	実質的な姿勢
YouTube	AI名指しの拒否なし（`/watch`は許可）	200	規約・API・認証	入り口は開放、中身は規約で締める
note	―	403 CloudFront	CDN／サーバー	物理的に遮断（強い）
Instagram	AIボットを名指しで`Disallow: /`	200	robots.txt＋ログイン壁	ルールで拒否＋非ログインで実質非公開