AI検索の定点観測を自動化する方法｜公式APIの使い方と規約の注意点・記録の型

AI検索での自社の見え方を毎月確かめていると、手作業がだんだんつらくなります。

質問が30件、AIサービスが3つ、ばらつきを見るために各3回とすると、それだけで270回の入力と記録が必要です。

「自動にできないか」と考えるのは、自然な流れです。

この記事は、AI検索の計測の自動化を考える、中小企業のWeb担当者向けにまとめました。自動化する方法と、その落とし穴を扱います。

2026年10月17日に、各社の公式ドキュメントと利用規約を開いて確かめた内容をもとにしています。API（プログラムから使う窓口）の仕様は変わりやすいので、実際に使う前に最新の版を見てください。

手動での確認方法は、次の記事にまとめています。

• ChatGPTで自社サイトがどう表示、引用されているかを確かめる方法
• AIに引用されない記事は、何回測ってから書き直すか

2本目は、測り直しの回数を扱っています。

ここでは、自動にするときに何を選び、何に気をつけるかに絞ります。

先に結論：自動化で押さえる6つのこと

結論を表にまとめます。

論点	確かめられたこと	この記事の判断
自動化の方法	各社が検索ツールつきのAPIを公式に提供している	公式のAPIを使うのが第一候補
APIと画面の違い	地域を省くとOpenAIは米国が既定になる。画面との差は、読んだドキュメントに書かれていなかった	APIの数字は近似値として扱う
画面の自動操作	個人向けの規約に、自動での取り出しを禁じる条項がある	避ける
出典の取り出し	回答に付く引用と、参照した一覧は別の項目に入る	両方を保存する
費用	検索の回数に応じた課金がある	回数を数えて見積もる
ばらつき	自動化しても、回答の変動は消えない	複数回の平均と推移で判断する

地味な作業ですが、記録を残して推移を見る、という基本は手動と同じです。

この記事で使った情報源

使った情報源は、次の表のとおりです。

情報源	使った内容
OpenAIの開発者向けドキュメントと公式ライブラリ	検索ツール、出典の項目、地域の既定
Anthropicの開発者向けドキュメント	検索ツールの設定、応答の形、エラー
Googleの開発者向けドキュメント	検索グラウンディングの応答、課金の単位
Perplexityの開発者向けドキュメント	検索ツールの応答の形
各社の利用規約	自動での取り出しに関する条項

料金の金額は、頻繁に変わるため、この記事には書いていません。

自動化で何が変わり、何が変わらないのか

最初に、楽になる部分と、そうでない部分を分けておきます。

項目	手動計測	自動化
質問の入力	1件ずつ手で入力する	プログラムが一括で実行する
回答と出典の記録	コピーして表に貼る	ファイルに自動で保存する
自社ドメインが出典にあるかの判定	目で確認する	プログラムで機械的に判定する
回答の中身が正しいかの判断	人が読む	人が読む（変わらない）
一般の利用者の画面との一致	画面そのものなので一致する	一致しない場合がある
費用	主に人件費	APIの利用料やツールの料金

自動化で得られるのは、回数を増やせることと、記録の手間が減ることです。

回答の内容が正しいかの判断には、今も人が読む作業が残ります。自動で集めた数字は、画面の回答とずれる場合もあります。

自動化の3つの方法

自動化の方法は、大きく分けて3つです。

方法	概要	筆者の評価
1. 公式のAPIを使う	検索つきの回答を返すAPIに、質問リストを流し込む	簡単なプログラムを動かせる人がいれば第一候補
2. 市販の計測ツールを使う	ツール会社が質問を実行して集計し、画面で見せる	プログラムを書けない場合や、競合比較もしたい場合
3. 画面を自動操作して取得する	ブラウザーを自動で動かし、画面から回答を写し取る	規約に反するおそれがあるため避ける

評価の列は、筆者の判断です。以下、順に見ていきます。

図の4つの箱は、方法1の流れです。質問リストを固定して渡し、APIから回答と出典を受け取り、生データのまま保存して、最後は人が読んで傾向を判断します。

方法1：公式のAPIを使う

最初に、APIで検索つきの回答を得る仕組みを説明します。

APIで検索つきの回答を得る仕組み

通常のAPIは、AIモデルが学習した知識だけで答えます。これだけでは、今のウェブ上の情報をもとに、どのサイトを出典にしたかは分かりません。

そこで各社は、APIの呼び出しにウェブ検索のツールを付けられるようにしています。ツールを付けると、モデルが検索し、その結果をもとに回答を作り、参照したページの情報を返します。

定点観測の自動化では、この出典のURLを受け取り、自社のドメインが含まれているかを数えるのが基本の考え方です。

各社のAPIで確認できたこと

2026年10月17日時点で、公式ドキュメントから確かめた内容を表にします。

提供元	機能	出典の受け取り方	検索するかの判断
OpenAI	Responsesの検索ツール	回答の注釈にURLとタイトルが入る。参照した一覧は、追加の指定で取れる	ツールとして渡し、モデルが判断する
Anthropic	Claude APIの検索ツール	検索結果と、回答文に付く引用が別の項目に入る	Claudeが質問から判断する
Google	Gemini APIの検索グラウンディング	検索語句、出典、回答との対応が入る	モデルが判断する
Perplexity	Agent APIの検索ツール	回答とは別に、検索結果の一覧が返る	ツールとして渡す

つまり、同じ質問でも、検索せずに答える回があり、その回は出典が付きません。

記録のときは、検索が行われたかも残しておくと、引用率の解釈を誤りにくくなります。

引用と参照の一覧は別物

各社の応答には、回答に付く引用と、検索で見つかった一覧の、2種類が入ります。表にまとめます。

提供元	回答に付く引用	検索で参照した一覧
OpenAI	回答の注釈（url_citation）。URL、タイトル、位置が入る	include で追加指定すると、検索の記録に参照した全URLが入る
Anthropic	文章ブロックの citations。URL、タイトル、引用された文が入る	web_search_tool_result に URL、タイトル、更新時期が入る
Google	groundingSupports が、回答の部分と出典を結ぶ	groundingChunks に出典のURIとタイトルが入る
Perplexity	目印を付けるかは、質問文の書き方しだい	search_results に id、URL、タイトルなどが入る

OpenAIのドキュメントは、参照した一覧が、回答に付く引用より多いことが多いと説明しています。引用だけを数えると、見えている出典の一部しか拾えません。

Perplexityのドキュメントは、引用の目印を付けるかは質問文に依存すると説明しています。出典の正本として、search_results の id と url を使うよう書かれています。

自社のドメインの判定では、両方を別の列に保存しておくと、あとで分析の幅が広がります。

Geminiの出典URLに注意する

Googleのドキュメントの応答例では、出典のURIが、vertexaisearch.cloud.google.com の転送用URLの形で示されています。タイトルの欄には、出典のドメイン名が入っています。

この形だと、URIのホスト名だけでは、自社のドメインかを判定できません。タイトルの欄もあわせて確認します。

また、2026年10月17日に開いたこのページは、題名に「Legacy」と付いていました。新しい仕組みへの移行を案内する場合があるので、使う前に最新の案内を確かめてください。

APIの結果は、画面の回答と同じではない

ここが、自動化でいちばん大事な注意点です。APIの回答は、一般の利用者が画面で見る回答と同じとは限りません。

違いの可能性を、確かめられたことと筆者の推測に分けます。

項目	確かめられたこと	筆者の推測
地域	OpenAIの公式ライブラリは、地域を省くと米国が既定になると説明している	日本の見え方に近づけるには、国を明示する
モデル	APIでは、呼び出す側がモデルを選ぶ	画面の裏側と同じとは限らない
検索の設定	OpenAIの検索量の設定は、出典の数を保証しないと説明されている	設定しだいで出典の数が変わる
個人への調整	画面での扱いは、読んだドキュメントに書かれていない	ログイン状態や過去の会話が影響する可能性がある

このため、APIの数字は、一般の利用者の見え方そのものではありません。条件をそろえて繰り返し測れる、近似値として位置づけます。

実務では、最初の数か月は、手動の計測とAPIの計測を同じ質問で並行して行い、傾向がそろうかを確かめます。そろうと分かってから、自動化に比重を移すのが安全です。

画面の自動操作を避ける理由

「それなら、画面そのものを自動で操作すればよいのでは」と考える人もいるでしょう。技術的には可能ですが、各社の個人向けの利用規約に、自動での取り出しを禁じる条項があります。

各社の規約で確かめられたこと

2026年10月17日に、各社の規約の該当箇所を開いて確かめました。表にまとめます。

提供元	規約の該当箇所	適用範囲の注記
OpenAI	禁止事項に、データまたはアウトプットを自動またはプログラムで引き出すことがある	2026年1月1日発効の個人向けの規約。APIなどは、別の事業者向けの規約が定める
Perplexity	ロボット、クローラー、スクレイパーなどの自動的な手段で、サービスから情報を集めることの禁止がある	2026年1月23日更新の規約。APIは別の規約が定める
Anthropic	個人向けの規約に、ボットやスクリプトなどの自動的な手段でのアクセスの禁止と、データを収集することの禁止がある	APIキーでのアクセスや、明示的に許可された場合は例外とされている
Google	利用規約に、ウェブページの機械可読の指示（robots.txtなど）に反して、自動的な手段でコンテンツにアクセスすることの禁止がある	2026年7月30日発効の規約。禁止の範囲は、指示に反する場合

表の4社は、条項の書き方も範囲も違います。

OpenAIとPerplexityは、個人向けの規約と、APIの規約が別の文書です。公式のAPIを使うなら、APIを定める規約が適用されます。

規約を確認するときの考え方

規約は改定されます。地域や契約の種類（個人向けか法人向けか、画面かAPIか）によって、適用される文書も変わります。

上の表は目安です。実施の前に、自社が使う契約の最新の規約を確認してください。

規約に反すると、アカウントが停止されるおそれがあります。業務で使っているアカウントが止まれば、計測以外の仕事にも影響が出ます。

自動化したいなら、公式に用意されたAPIを使います。これが、いちばん安全な選び方です。

拡張機能での自動保存も同じ

画面の回答を、ブラウザーの拡張機能などで自動保存する方法も、使い方によっては、規約の定める自動での取り出しに当たる可能性があります。

判断がつかないときは使わず、各社の最新の規約を確認するか、公式のAPIを使います。

方法2：市販の計測ツールを使う

プログラムを書く人がいない場合や、競合との比較まで見たい場合は、市販の計測ツールが選択肢になります。導入前に確認したい点を、表にまとめます。

確認ポイント	聞くこと	理由
データの取り方	公式のAPIか、画面の取得か、利用者の協力データか	画面の取得なら、規約上の扱いを確認したい
質問の自由度	自社で作った質問リストを登録できるか	ツール側の質問だけでは、顧客の質問とずれる
対象サービス	どのサービスを、どのモデルと条件で測るか	サービスごとに見え方が違う
地域と言語	日本と日本語の条件で測れるか	地域を指定しないと、別の国の条件になる場合がある
繰り返し回数	1つの質問を何回実行して集計するか	1回だけの結果は、ばらつきが大きい
更新頻度	毎日、毎週、毎月のどれか	月1回では、施策の影響を細かく追えない
生データの出力	回答本文と出典のURLを取り出せるか	数字が変わった理由を、あとから確かめたい
判定の定義	言及と引用を、何で判定するか	社名の表記ゆれを拾えているか確認したい
費用の単位	質問数、実行回数、ブランド数のどれで変わるか	質問を増やしたときの伸び方が分かる

ツールの数字は、集め方が違うため、ツール間では一致しません。1つのツールの中で推移を見て、ときどき手動で同じ質問を実行して確かめます。

導入前に自社で決めておくこと

ツールを選ぶ前に、自社で決めておく項目があります。ここは筆者の考えで、公式の定めではありません。

決めること	内容
質問リスト	顧客が実際にする質問を、分類して持っておく
対象サービス	顧客がよく使うサービスから、2〜3個に絞る
頻度と回数	月に何回、1つの質問を何回実行するか
担当者	結果を読んで、判断する人を決める
利用額の上限	想定を超えたときに止める条件を決める

質問リストの作り方は、計測の前提になる作業です。先に整えておくと、ツールを比べるときも、自社の質問で試せます。無料の試用期間があれば、その間に確かめます。

公式のAPIで計測するスクリプトの例

ここでは、OpenAIの公式ライブラリを使った、簡単なスクリプトの例を示します。やることは次の4つです。

1. 質問リスト（CSV）を読み込む
2. 検索つきでAPIに質問する
3. 引用と参照の一覧に、自社のドメインが含まれるかを判定する
4. 結果をCSVに追記し、応答の生データも保存する

動作の確認について

この例は、OpenAIの公式ドキュメントと、公式ライブラリの型定義をもとに書いています。応答の形を模した疑似データで、出典の取り出し処理が動くことは確かめました。

実際のAPIは、筆者が呼び出していません。最初に1問だけ実行して、結果を目で確かめてから、全件に広げてください。

準備

Python 3.10 以上を用意し、公式ライブラリを入れます。

pip install openai

APIキーは、プログラムに直接書かず、環境変数に入れます。公式ライブラリは、環境変数 OPENAI_API_KEY を既定で読み込みます。

モデル名は、契約しているものを環境変数で渡す形にすると、モデルを変えたときにコードを直さずに済みます。

export OPENAI_API_KEY="（発行したAPIキー）"
export OPENAI_MODEL="（利用するモデル名）"

質問リストは、「質問ID」と「質問文」の2列のCSVにして、questions.csv の名前で保存します。

question_id,question
Q001,東京で中小企業向けの会計ソフト導入支援に強い会社は？
Q002,クラウド会計ソフトを入れるときの相談先のおすすめは？

スクリプト本体

次のスクリプトを、monitor.py の名前で保存します。ドメインと社名は、自社のものに書き換えてください。

import csv
import os
from datetime import datetime, timezone
from pathlib import Path
from urllib.parse import urlparse
from openai import OpenAI
OWN_DOMAINS = ["example.co.jp"]
BRAND_NAMES = ["株式会社サンプル", "サンプル社"]
REPEAT = 3
MODEL = os.environ["OPENAI_MODEL"]
client = OpenAI()
def is_own(url):
    host = (urlparse(url).hostname or "").lower()
    return any(host == d or host.endswith("." + d) for d in OWN_DOMAINS)
def ask(question):
    res = client.responses.create(
        model=MODEL,
        input=question,
        tools=[{"type": "web_search",
                "user_location": {"type": "approximate", "country": "JP"}}],
        include=["web_search_call.action.sources"],
    )
    searched, cited, seen = False, [], []
    for item in res.output:
        if item.type == "web_search_call":
            searched = True
            seen += [s.url for s in (getattr(item.action, "sources", None) or [])]
        elif item.type == "message":
            for part in item.content:
                for a in getattr(part, "annotations", None) or []:
                    if a.type == "url_citation" and a.url not in cited:
                        cited.append(a.url)
    return res, searched, cited, seen
Path("raw").mkdir(exist_ok=True)
new_file = not Path("results.csv").exists()
questions = list(csv.DictReader(open("questions.csv", encoding="utf-8")))
with open("results.csv", "a", encoding="utf-8", newline="") as f:
    w = csv.writer(f)
    if new_file:
        w.writerow(["run_at", "model", "question_id", "repeat", "searched",
                    "mentioned", "cited_own", "seen_own", "cited_urls", "seen_urls", "answer"])
    for q in questions:
        for i in range(1, REPEAT + 1):
            now = datetime.now(timezone.utc).isoformat(timespec="seconds")
            try:
                res, searched, cited, seen = ask(q["question"])
            except Exception as e:
                w.writerow([now, MODEL, q["question_id"], i, "", "", "", "", "", "", "ERROR: " + str(e)])
                continue
            answer = res.output_text
            w.writerow([now, MODEL, q["question_id"], i, searched,
                        any(n in answer for n in BRAND_NAMES),
                        any(is_own(u) for u in cited), any(is_own(u) for u in seen),
                        " ".join(cited), " ".join(seen), answer])
            name = now.replace(":", "") + "_" + q["question_id"] + "_" + str(i) + ".json"
            Path("raw", name).write_text(res.to_json(), encoding="utf-8")

実行すると、results.csv に1回の質問につき1行が追記されます。raw フォルダには、応答の全体がJSONで保存されます。

コードのポイント

コードのポイントを補足します。

• 自社ドメインの判定は、ホスト名が自社のドメインと一致するか、その下のサブドメインかで行います。文字が含まれるだけの別ドメインを、数えないためです。
• 引用と参照の一覧を分けて判定します。 引用だけを見ると、参照された出典を取りこぼします。
• 地域を日本に指定しています。 OpenAIの公式ライブラリは、省くと米国が既定になると説明しています。
• 失敗した回も1行残します。 通信エラーや利用上限で失敗した回を飛ばすと、分母が変わって、引用率がずれます。
• 言及の判定は、社名の表記が回答文に含まれるかだけを見る単純なものです。 最終的には人が読んで確かめます。

他のサービスで取り出す場所

ほかの3社でも、同じ考え方で記録できます。出典が入っている場所は、公式ドキュメントによると次のとおりです。

サービス	回答に付く引用	検索で参照した一覧	取り出すときの注意
Anthropic	文章ブロックの citations の url	検索結果ブロックの url	エラーは、200の応答の中にエラーの項目として入る
Google	groundingSupports	groundingChunks の uri と title	uriが転送用のURLの形なので、titleも見る
Perplexity	質問文で目印を頼んだ場合の、回答中の番号	search_results の url	id と url を正本にする

Anthropicのドキュメントは、検索が長引いたとき、応答が途中で区切られる stop_reason の値（pause_turn）があると説明しています。その回の扱いを決めて、記録に残します。

また、検索ツールには複数の版があり、使える機能とモデルが版ごとに違います。契約しているモデルに合う版を、公式ドキュメントで確かめます。

表示にかかわる条件

OpenAIとAnthropicのドキュメントには、APIの出力を利用者に直接見せるとき、出典を見える形で示す必要があるという趣旨の説明があります。Googleは、検索の候補の表示に関する条件を、利用規約で定めると説明しています。

社内の報告に転記する程度なら、問題になりにくいと考えられます。回答を加工して社外に公開するなら、規約と表示の条件を確認してください。

動かすときの注意

動かすときは、次の点に気をつけます。

• 最初は1問、1回だけで試す。応答を表示して、出典の入り場所を目で確かめる
• 実行の間隔をあける。短時間に多く送ると、利用上限にかかることがある
• APIキーを、共有するファイルに書かない
• 定期実行は、手動の実行が安定してから設定する

費用の考え方

具体的な料金は、サービスとモデルで違い、頻繁に改定されます。この記事には金額を書きません。

必ず、各社の料金ページで最新の内容を確認してください。

課金は、文章の量と検索の回数の2本立て

検索つきのAPIの費用は、おおむね次の2つの合計です。公式ドキュメントの説明をもとにまとめます。

提供元	検索の課金（公式の説明）	文章の課金
OpenAI	検索の操作ごとに、ツールの呼び出し費用がかかる	モデルの文章量に応じて別にかかる
Google	新しいモデルでは、モデルが実行した検索クエリごとに課金される	モデルの文章量に応じて別にかかる
Perplexity	検索ツールの呼び出し回数に応じて課金される	モデルの文章量が別にかかる
Anthropic	課金の単位は確認していない。応答の usage に、検索の回数が記録される	料金ページで確認する

Googleのドキュメントは、1回の質問でモデルが複数の検索を行えば、その分だけ課金されると説明しています。1問が1回の課金になるとは限りません。

月の費用の見積もり方

月の費用は、次の掛け算で見積もります。

質問の数 × サービスの数 × 繰り返しの回数 × 月の実行回数 × 1回あたりの費用

たとえば、質問30件、サービス3つ、各3回、月1回なら、月に270回の呼び出しです。毎週にすると、約4倍になります。

費用を抑える工夫

費用を抑える工夫は、次の4つです。

• まず1つのサービスと少数の質問で、1回あたりの実際の費用を測る
• 1回の質問で検索する回数の上限を設定する（Anthropicには max_uses がある）
• 重要な質問だけ毎週、ほかは毎月、のように頻度を分ける
• 管理画面で、利用額の上限や通知を設定する

設定の誤りで同じ処理が繰り返し動いた場合の事故を、防げます。

記録とばらつきの扱い

自動化の利点は、記録が漏れなく残ることです。

保存しておく項目

あとから「なぜ数字が変わったのか」を調べられるように、次の項目を必ず保存します。

項目	理由
実行日時	推移を見るため
サービス名とモデル名	モデルが変わると、数字が一斉に動くことがあるため
設定（地域、検索の設定など）	条件が変わっていないことを確かめるため
質問IDと繰り返しの番号	同じ質問の複数回の結果を束ねるため
検索が行われたか	検索なしの回を区別するため
回答本文と、引用、参照の一覧	判定のルールを変えたとき、過去分を判定し直すため
応答の生データ（JSON）	項目の取り出し方を誤ったとき、やり直すため
エラーの内容	失敗した回を、分母から正しく扱うため

回答本文と生データは、消さずに残します。判定方法を見直したとき、過去にさかのぼって数え直せます。

ばらつきへの向き合い方

AIの回答は、同じ質問と同じ設定でも、実行のたびに変わります。APIで自動化しても、このばらつきはなくなりません。

自動化するときは、次の点を意識します。

• 1つの質問は複数回実行し、何回中何回引用されたかで記録する
• 1日に集中させず、日を分けて実行する
• 月単位、数か月単位の推移で判断する。先月より数ポイント上がった程度の変化は、ばらつきの範囲かもしれない
• モデルや地域の設定を変えたときは、変更日と内容を記録して、前後を単純に比べない

手動の計測との突き合わせ

自動化したあとも、毎月いくつかの重要な質問だけは、画面で手動の計測を行います。自動の傾向とずれていないかを確かめるためです。

大きく食い違うなら、地域の設定やモデルの選び方を見直すきっかけになります。

よくある失敗

自動化で起きやすい失敗を、表にまとめます。

失敗	起きること
地域を指定せずに測る	OpenAIでは米国が既定のため、日本の見え方とかけ離れた結果になる
モデルを毎回、最新に自動で切り替える	更新のたびに数字が変わり、施策の効果と区別できない
出典の判定を、文字列の部分一致で行う	自社のドメインを含む別のドメインを、誤って数える
エラーの回を記録しない	分母が月によって変わり、引用率がずれる
集計結果だけ残し、回答本文を捨てる	数字が動いた理由を、あとから確かめられない
画面の自動操作ツールを使う	規約に反するおそれがあり、画面の変更で動かなくなる

よくある質問

Q1. プログラムを書ける人がいなくても、自動化できますか？

市販の計測ツールを使う方法があります。確認ポイントの表のうち、質問リストを登録できるか、日本と日本語の条件で測れるか、生データを出力できるか、の3つは特に確かめてください。

この記事のスクリプト程度なら、社外のエンジニアに依頼する方法もあります。

Q2. APIの結果と画面の結果がずれるなら、自動化する意味はありますか？

あります。条件をそろえて何度でも測れるので、傾向を見るのに向いています。

画面の実態は手動で、推移は自動で見る、という役割分担が現実的です。

Q3. どのサービスのAPIから始めればよいですか？

自社の顧客がよく使うと考えられるサービスを1つ選び、少数の質問で試すのがおすすめです。

仕組みが安定したら、同じ記録の形のまま、ほかのサービスを足していきます。

Q4. 計測の頻度は、どのくらいがよいですか？

月1回から始め、重要な質問だけ週1回にする形が目安です。この頻度は、筆者の考えです。

回答はもともとばらつくので、頻度を上げても、判断の精度がすぐに上がるとは限りません。頻度より、繰り返しの回数と続けた期間を優先してください。

まとめ

AI検索の定点観測を自動化するなら、各社が公式に提供している、検索つきのAPIを使うのが基本です。出典のURLつきで回答を返す仕組みが、APIで用意されています。

ただし、APIの回答は、画面で見る回答と同じとは限りません。地域を日本に指定し、モデルを固定し、手動の計測と並行して差を確かめながら、傾向を見る道具として使います。

• 画面の自動操作は、規約に反するおそれがあるため避ける
• 引用と参照の一覧を、別の列で保存する
• 回答本文と生データを残し、複数回と数か月の推移で判断する
• 費用は、検索の回数にもかかることに注意する

まずは1つのサービス、10件ほどの質問から、小さく始めてください。

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。