Bing Webmaster Tools — GSC からインポートして AI 引用を見る方法

Bing Webmaster Tools とは何か

Microsoft がサイト所有者に無料で提供する管理コンソールで、アドレスは bing.com/webmasters。Microsoft アカウントだけでなく Google アカウントや Facebook アカウントでもログインできる。インストールは不要だ。

画面構成は Google Search Console とほぼ一対一で対応する。どのページがインデックスされたか、どの検索語で表示されクリックされたか、サイトマップは正常か、どこからリンクされているか、robots.txt に文法エラーはないか。GSC を使ったことがあるなら新しく覚えることはほとんどない。

GSC にないものが三つある。第一に、URL を直接送信できる上限が 1 日 10,000 件と大きい。第二に、IndexNow のキーをこの画面で発行し管理する。第三に、2026 年に加わった AI Performance レポートだ。この三つが今 Bing に登録する実質的な理由になる。

検索シェアだけを見れば理由は弱く見える。韓国で Bing を使って検索する人は多くない。しかし今の Bing インデックスの価値は、人が打ち込む検索窓ではなく、AI の回答が根拠を探すときに立ち寄る場所から生まれている。

ChatGPT の検索ボットは Bing のボットではない — まず前提を正す

GEO を扱う文章で最もよく見る一文がこれだ。ChatGPT は Bing を使うのだから Bing に登録すべきだ。半分だけ正しい。そして間違っている半分が実務で事故を起こす。

まずクロールから。OpenAI は自社のボット四種を文書で公開している。OAI-SearchBot(ユーザーエージェント OAI-SearchBot/1.4)は ChatGPT の検索機能でサイトを露出させる用途、GPTBot(GPTBot/1.4)はモデル学習用の収集、ChatGPT-User(ChatGPT-User/1.0)はユーザーが特定のリンクを開かせたとき、OAI-AdsBot(OAI-AdsBot/1.0)は広告ランディングページの安全性確認用だ。それぞれの IP 一覧まで openai.com/searchbot.json のようなアドレスで公開されている。

つまり ChatGPT が理由でサーバーログに残るユーザーエージェントは bingbot ではなく OAI-SearchBot だ。robots.txt で許可または遮断する対象もそちらである。Bing にサイトを登録する行為は OpenAI のクローラーとは何の関係もない。

検索の段階はどうか。OpenAI のヘルプは ChatGPT search sometimes partners with other search providers としか書かず、その提携先の一つとして Bing を挙げている。ときどき、提携先の一つ、である。すべてが Bing を通るという意味ではないし、どの質問がどの経路を通ったかは外からは分からない。

一方 Microsoft Copilot は明確だ。Bing 自身が AI Performance レポートの対象として Microsoft Copilot と Bing の AI 生成要約を明記している。そこに ChatGPT という単語は一度も出てこない。

整理するとこうなる。Bing 登録で確実に回収できるのは Copilot と Bing の AI 要約であり、ChatGPT は間接的で測定もできない。それでも登録はする。コストがアカウント連携一回だからであって、ChatGPT が保証されるからではない。この区別を曖昧にすると、後でレポートの数字を ChatGPT の成果として読み違えることになる。

登録 A 案 — Google Search Console からインポートする(推奨)

すでに GSC を使っているなら、所有権確認をもう一度やる理由はない。Bing が GSC の認証をそのまま認めてくれる。

手順 1。bing.com/webmasters にアクセスしてログインする。サイトを追加する画面で方法を選ぶウィンドウが出る。左が Google Search Console からのインポート(Import)、右が手動追加(Add your site manually)だ。左の Import ボタンを押す。

手順 2。どのデータを取り込むかの案内が出る。Continue を押して Google アカウントでログインし、Bing が Search Console のデータを読む権限を許可する。

手順 3。GSC アカウントにあるサイト一覧が、サイトマップ数と自分の権限ロールとともに表示される。取り込むサイトにチェックを入れて Import を押す。

これで終わりだ。取り込んだサイトは自動的に所有権確認済みの状態になり、サイトマップも一緒に移ってくる。ファイルをアップロードしたり DNS を触ったりする段階がまるごと消える。

上限が二つある。一度に最大 100 件、一つのアカウントに最大 1,000 件までだ。100 件を超えるなら同じ手順を繰り返せばよく、複数の Google アカウントから分けて取り込むこともできる。

データは最大 48 時間経たないと埋まらない。取り込んだ直後に画面が空でも失敗ではない。翌日にもう一度見る。

一点だけ注意。インポートは認証の免除ではなく委任だ。Bing は定期的に GSC アカウントへ問い合わせて所有権を再確認する。後でアクセス権がなくなれば、再接続するか、下の B 案のメタタグや DNS 方式へ認証を移す必要がある。

登録 B 案 — 手動で追加するときの所有権確認三種

Bing にサイトを手動追加する際の所有権確認3方式（XMLファイル・metaタグ・DNS CNAME）と、metaタグ1行を示す図。

GSC を使っていない、あるいは Google アカウントを連携したくないなら直接追加する。サイトのアドレスを入れると、Bing が所有権確認の方法を三つ提示する。

一つ目、XML ファイル。Bing が生成した BingSiteAuth.xml をダウンロードし、サイトの最上位パスにそのまま置く。FTP や静的ホスティングでファイルを置ける環境なら最も単純だ。

二つ目、メタタグ。msvalidate.01 という名前のメタタグをトップページの head 内に入れる。Next.js や WordPress のようにテンプレートへ一行足すのが容易な環境ならこちらが速い。

三つ目、DNS の CNAME レコード。Bing が指定した名前の CNAME を verify.bing.com に向ける。ドメイン単位で認証されるためサブドメインまで一度で覆い、サイトを作り直しても認証が生き残る。長期的には最も堅い。

選ぶ基準は単純だ。ファイルを置けるなら XML、テンプレートを直せるならメタタグ、DNS を触れるなら CNAME。三つのうち一つでよい。

メタタグ方式 — <head> の中に一行

<meta name="msvalidate.01" content="ここに Bing が発行した確認コード" />

登録直後にやること三つ — サイトマップ、URL 送信、IndexNow

登録して閉じるだけでは何も起きない。インデックスが実際に回るまでに、あと三つやる。

一つ、サイトマップ。GSC からインポートしたならすでに入っているので Sitemaps 画面で確認するだけでよい。なければ sitemap.xml のアドレスを直接送信する。Bing はサイトマップを 1 日 1 回以上更新するよう推奨している。頻繁に記事を出すサイトなら、ビルドのたびにサイトマップが再生成されるか確認しておくとよい。

二つ、URL 送信。ほとんどのサイトが 1 日 10,000 件まで URL を直接押し込める。2019 年に 1 日 10 件からこの数字へ引き上げられ、今も維持されている。新しい記事を出したらその URL をすぐ入れる。クローラーが来るのを待たない。

三つ、IndexNow。これは Bing 専用ではなくプロトコルだ。8 文字から 128 文字のキー(英大小文字、数字、ハイフン)を作り、その名前のテキストファイルをサイト最上位に置き、コンテンツが追加・更新・削除されるたびに API へ知らせる。一回の POST で最大 10,000 件の URL を送れる。

IndexNow をあえて強調する理由がある。参加しているエンジンは Bing だけでなく、Naver、Yandex、Seznam、Yep、Amazon が並んでいる。韓国のサイトなら、この一覧に Naver があるという事実だけで導入する価値になる。一度つないでしまえば、公開自動化スクリプトの末尾にリクエストを一行足すだけで済む。

リクエストの上限はエンジンごとに異なり公開されていない。429 が返ってきたら上限を超えているので、Retry-After ヘッダーを見てから送り直す。

IndexNow — 公開直後に一回呼ぶ

curl -X POST https://api.indexnow.org/indexnow \
  -H 'Content-Type: application/json' \
  -d '{
    "host": "example.com",
    "key": "ここに自分で作ったキー",
    "keyLocation": "https://example.com/ここに自分で作ったキー.txt",
    "urlList": [
      "https://example.com/insights/new-post"
    ]
  }'

AI Performance レポート — 何が見えるのか

2026 年 2 月 10 日に公開プレビューとして開いた画面だ。自分のページが AI の生成した回答に根拠として引用されたとき、その回数を見せてくれる。対象は Microsoft Copilot、Bing の AI 生成要約、そして名前を明かしていない一部のパートナー統合である。

基本指標は四つ。Total Citations は選択した期間に AI の回答へ出典として表示された引用の総数、Average Cited Pages は 1 日あたり平均でいくつの異なるページが出典として使われたか、Grounding Queries は AI が引用した内容を取得するときに使ったキーフレーズ、そしてページ単位の引用活動だ。

このうち実務で最も価値が大きいのは grounding query だ。ユーザーが実際に打った文ではなく、AI が根拠文書を探すために内部で作り直したクエリだという点が重要になる。人が長く尋ねてもモデルは短く検索向きの形に変えて投げる。自分の記事がどの書き換えクエリに掛かったかが見えれば、タイトルと小見出しをその語彙に合わせる作業がそのまま GEO の実体になる。勘ではなく観測でやるということだ。

2026 年 6 月 16 日にはプレビューで四つが追加された。Intents は grounding query を情報探索、商業、ナビゲーション、学習と解決、リサーチ、創作、ローカルなどの意図カテゴリに分類する。Topics は個別のクエリをテーマのクラスターにまとめる。Citation Share は同じ grounding query における全引用のうち自分のサイトが占めた比率だ。Compare は前の期間を重ねて表示する。

Citation Share は競合データを見せる機能ではない。Bing が観測用であって競合分析用ではないと明言しており、トラフィックを意味するものでもない。

指標	何を数えるか	実務での使い方
Total Citations	期間内に AI 回答へ出典として表示された引用の総数	公開ペースと重ねて、引用が付く記事の型を見分ける
Average Cited Pages	1 日あたり引用された異なるページ数	一本が牽引しているのか複数が均等に掛かっているのかを見る
Grounding Queries	AI が根拠を探すときに作った書き換えクエリ	タイトルと小見出しをこの語彙に合わせて書き直す
Citation Share	同じクエリの全引用に占める自サイトの比率	自分が伸びたのか市場が広がったのかを切り分ける

見えないもの — このレポートで ChatGPT は測れない

レポートを開く前に限界を先に書いておくほうがよい。数字を読み違えると、ありもしない成果を報告することになる。

第一に、ChatGPT は対象ではない。Bing の告知のどこにも ChatGPT という名前はない。一部のパートナー統合とだけ書かれ、その相手を明かしていない。ChatGPT の引用はこの画面では見えないと考えるほうが安全だ。

第二に、grounding query は全体ではなく標本だ。Bing 自身が引用活動のサンプルだと書いている。一覧にないからといって引用がなかったわけではない。

第三に、引用数は順位ではない。この指標はページがどれだけ頻繁に引用されたかを示すだけで、重要度や順位、掲載位置を意味しないと Bing が明記している。

第四に、引用はトラフィックではない。AI の回答に出典として載っても、ユーザーがリンクを押すかどうかは別だ。引用数が増えたのに訪問者が横ばい、という状況は正常である。

第五に、プレビューだ。6 月に追加された機能はまだ進化途中のシステムの上にあり精度は改善されていくと、Bing 自身が但し書きを付けている。専門分野ほど分類は粗い。

だから ChatGPT 側の露出は別の手段で見る。一つは直接クエリテストだ。自分のテーマの代表的な質問を ChatGPT に入れ、自分のページが出典として出るかを定期的に確認する。もう一つはサーバーログだ。ユーザーエージェントで OAI-SearchBot と ChatGPT-User のヒットを数えれば、OpenAI 側が実際に自分のサイトを読んでいるかが分かる。Bing のレポートは Copilot の計器盤として読み、ChatGPT はこの二つで別に測る。それが今できる最善だ。

GEO のコツ — robots.txt で学習ボットと検索ボットを分ける

robots.txt で学習用クローラーを遮断し、検索・引用ボットは許可する切り分けを左右で対比した図。

引用されるには、まずクロールされなければならない。Bing の登録も IndexNow も、その手前で robots.txt が開いていて初めて意味を持つ。そしてここで最もよくある事故が起きる。

AI ボットは性格が三つに分かれる。学習用の収集(GPTBot、ClaudeBot、Google-Extended)、検索と引用(OAI-SearchBot、Claude-SearchBot、PerplexityBot、bingbot)、そしてユーザーがリンクを開くときに動くもの(ChatGPT-User)だ。最後のものはユーザーが指示した行動なので robots.txt が適用されない場合があると OpenAI が明記している。

事故はこう起きる。自分の文章がモデル学習に使われるのが嫌で GPTBot を遮断する。ところが同じルールで検索ボットまで一緒に遮断してしまう。すると学習だけでなく引用も同時に消える。AI の回答に自分のサイトが出典として出る経路そのものを閉じたことになる。

実際に分けている例がある。Brunch は robots.txt で GPTBot、ClaudeBot、Google-Extended といった学習クローラーを全面的に遮断しながら、OAI-SearchBot、Claude-SearchBot、PerplexityBot といった検索ボットは許可している。学習資産は諦めて引用資産だけを取るという設計だ。この区別を知ると、どのプラットフォームに何を出すかの判断も変わってくる。

個人サイトや会社サイトなら、たいていは全面許可が既定値になる。このサイトの robots.txt も、すべてのユーザーエージェントに対する全体許可一行とサイトマップのアドレスだけだ。引用されることが目的なら、あえて狭める理由はない。

順序を整理するとこうなる。robots.txt で検索ボットを開け、Bing に登録してインデックスの経路を作り、IndexNow で更新を即座に知らせ、そのうえで AI Performance でどのクエリに掛かるかを観測する。コンテンツの磨き込みはその観測の上でやる。順序を逆にすると、良い文章を書いても誰にも読まれない状態が長く続く。

robots.txt — 学習は塞ぎ引用は開ける形

# 学習用の収集だけ遮断
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

# 検索・引用ボットは許可
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: bingbot
Allow: /

User-agent: *
Allow: /

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