はじめに

前回の記事「【用語ざっくり】グラウンディングとは？ ─ RAGとの違いを図解で整理する」では、AIの回答を根拠につなぐと「人が確かめられる」ようになる、と書きました。

今回はその続きで、「確かめられる」をAIがどうやって実現しているのか、つまり出典の示し方を扱います。

生成AIを使っていると、回答の横に [1] のような番号やリンクが出てくることがあります。あれはどういう仕組みなのかを、Claude・Gemini・OpenAI の3社を並べて軽めに整理します。

※本記事は個人の整理メモです。各社の仕様は 2026年10月10日時点 の公式ドキュメント等で確認した範囲で書いています。実際にAPIを呼んで試したわけではありません。機能名や項目名は変わりやすいので、使う前に最新のドキュメントを確認してください。
※本記事の図は公開情報をもとに筆者が独自に作成したものであり、各社公式の資料ではありません。

一言でいうと

👉 AIの出典表示とは、回答中のテキストや引用位置と、根拠となる資料を対応づける仕組みです。資料内の位置まで返るかは、APIや根拠の種類によって異なります。

画面に出るリンクは、見た目だけの飾りではありません。本記事で扱うAPIでは、「回答のどこが、どの資料に基づくか」という対応情報が、構造化されたデータとして返ります。

たとえで言うと

レポートの脚注が近いです。

レポートでは、本文の文の後ろに小さな番号を付け、ページの下や巻末の参考文献で「資料A、p.12」のように示します。読む人は番号をたどれば、その文が何に基づいているかを確かめられます。

AIの出典表示も同じ形です。違いは、番号や対応関係を人が手で書くのではなく、APIが「回答のこの区間（または位置）は、この資料に基づく」というデータとして返す点です。資料の中のページや文字位置まで返すAPIもあれば、資料（URLやファイル）の単位までのAPIもあります。画面に [1] やリンクを出すのは、そのデータを受け取ったアプリ側の仕事になります。

出典表示の基本形

各社で項目名は違いますが、返ってくる情報は次の3点で整理できます。ただし、③まで返るとは限りません。

点	中身	例
① 回答の文	回答のどの部分が出典を持つか	文字の開始・終了位置、引用付きのテキストブロック
② 根拠の資料	どの資料が根拠か（資料を識別する情報）	渡した文書の番号とタイトル、URLとタイトル、ファイルIDとファイル名
③ 資料内の位置	資料のどこが根拠か	文字位置、ページ番号、ブロック番号（Claude の Citations）

👉 本記事で扱う範囲では、③の項目を返すのは Claude の Citations だけです。Gemini（Generate Content API の Google検索グラウンディング）と OpenAI（Web検索・ファイル検索）の引用情報には、資料の中の位置を示す項目がなく、②の資料（URLやファイル）の単位までになります。ここが3社を比べるときのポイントです。

3社を並べて見る

Claude：Citations 機能

Claude の Messages API には Citations（引用） という機能があります。こちらから渡した文書（ドキュメント）に対して、回答のどこが文書のどこに基づくかを返します。

文書ごとに citations.enabled=true を指定して有効にする
対応する文書の種類は、プレーンテキスト・PDF・カスタムコンテンツの3つ
テキストとPDFは自動で文単位に分割され、それが引用の最小単位になる。カスタムコンテンツは渡したブロック単位
回答は複数の text ブロックに分かれ、根拠のあるブロックに citations が付く
引用には、文書の番号（document_index）に加えて、文書の中の位置（下の表）と、引用した文そのもの（cited_text）が入る

位置の表し方は、文書の種類で変わります。

文書の種類	引用の種類（`type`）	位置の表し方
プレーンテキスト	`char_location`	文字位置（`start_char_index`／`end_char_index`、0始まり）
PDF	`page_location`	ページ番号（`start_page_number`／`end_page_number`、1始まり）
カスタムコンテンツ	`content_block_location`	ブロック番号（`start_block_index`／`end_block_index`、0始まり）

いずれも終わりの値は「その手前まで」（exclusive）とされています。

中身をのぞくと（公式ドキュメントの例から抜粋）

{
  "type": "text",
  "text": "the grass is green",
  "citations": [
    {
      "type": "char_location",
      "cited_text": "The grass is green.",
      "document_index": 0,
      "document_title": "Example Document",
      "start_char_index": 0,
      "end_char_index": 20
    }
  ]
}

cited_text は文書から引用した文そのもので、出力トークンには数えられないとされています。

なお、Claude の Web検索ツールを使った場合も、回答に引用（web_search_result_location。URL・タイトル・引用した文など）が付きます。公式ドキュメントでは、Web検索では引用が常に有効とされています。

Gemini：Generate Content API の Google検索グラウンディング（groundingMetadata）

Gemini API の Generate Content API（generateContent）では、google_search ツールを有効にすると、モデルが必要に応じてGoogle検索を行い、その結果をもとに答えます（Grounding with Google Search）。このとき回答に groundingMetadata が付き、回答と検索結果の対応が返ります。

※ここで説明する groundingMetadata は、Generate Content API の形式です。Gemini API には Interactions API もあり、そちらでは引用が回答テキストの注釈（url_citation）として返るなど、返し方が異なります。本記事では Gemini API 全体に共通する形式としては扱いません。

項目	中身
`webSearchQueries`	実際に使われた検索クエリ
`groundingChunks`	根拠になったWebページの一覧（`web.uri` と `web.title`）
`groundingSupports`	回答の区間（`segment` の `startIndex`／`endIndex`）と、`groundingChunks` の番号（`groundingChunkIndices`）の対応
`searchEntryPoint`	検索候補（Search Suggestions）を表示するためのHTML/CSS

つまり、①回答の区間 → groundingSupports、②根拠の資料 → groundingChunks という形で分かれています。1つの区間に、複数の出典が結びつくこともあります。groundingChunks の Web の項目は uri と title で、ページの中のどこが根拠かを示す③の項目はありません。

中身をのぞくと（公式ドキュメントの例の形を簡略化）

"groundingMetadata": {
  "webSearchQueries": ["..."],
  "groundingChunks": [
    { "web": { "uri": "https://vertexaisearch.cloud.google.com/...", "title": "..." } }
  ],
  "groundingSupports": [
    {
      "segment": { "startIndex": 0, "endIndex": 85, "text": "..." },
      "groundingChunkIndices": [0]
    }
  ]
}

公式ドキュメントの例では、uri は vertexaisearch.cloud.google.com で始まるリダイレクト用のURLになっています。

また、Generate Content API の API定義（v1beta の proto）では、segment の型である Segment の startIndex／endIndex がバイト単位（measured in bytes）と定義されています。日本語のように1文字が複数バイトになる言語では、文字数として扱うとずれるので注意が必要そうです。なお、これは Generate Content API の Segment についての話で、Interactions API の注釈の位置の数え方とは分けて考える必要があります。

Gemini はこのほかに、Google マップやファイル検索などの根拠にも対応していますが、本記事では Generate Content API の Google検索グラウンディングに絞っています。

OpenAI：Web検索・ファイル検索の注釈（annotations）

OpenAI の Responses API では、Web検索ツール（web_search）やファイル検索ツール（file_search）を使うと、回答のテキストに annotations（注釈） が付きます。

ツール	注釈の種類（`type`）	主な項目
Web検索	`url_citation`	`url`、`title`、`start_index`、`end_index`
ファイル検索	`file_citation`	`file_id`、`filename`、`index`

Web検索では、start_index／end_index で回答テキストの中の引用の位置を示します（APIリファレンスの説明は「メッセージ内のURL引用の最初／最後の文字の位置」）。根拠側はURLとタイトル、つまりページ単位です
ファイル検索は、あらかじめ作ったベクトルストアの中のファイルを検索します。注釈はどのファイルが根拠か（file_id／filename）を示し、index は回答テキストのどこに引用を入れるかの位置です（SDKの説明は「ファイル引用を挿入する出力テキスト内の位置」）
どちらの注釈にも、ページの中やファイルの中のどこが根拠かを示す③の項目はありません
ファイル検索で実際に取ってきた検索結果は、既定では返らず、include に file_search_call.results を指定すると含められるとされています

中身をのぞくと（公式SDKの型定義に合わせた抜粋）

{
  "type": "output_text",
  "text": "...",
  "annotations": [
    {
      "type": "url_citation",
      "url": "https://example.com/...",
      "title": "...",
      "start_index": 120,
      "end_index": 245
    }
  ]
}

比較表

	Claude（Citations）	Gemini（Generate Content API の Google検索グラウンディング）	OpenAI（Web検索／ファイル検索）
根拠の出どころ	渡した文書（テキスト・PDF・カスタム）※Web検索ツールでも引用あり	Google検索の結果	Web検索の結果／ベクトルストア内のファイル
① 回答側の位置	引用付きの `text` ブロック	`segment` の `startIndex`／`endIndex`（`Segment` の定義ではバイト単位）	`url_citation` は `start_index`／`end_index`、`file_citation` は `index`
② 根拠の資料を識別する情報	`document_index`、`document_title`	`groundingChunks` の `web.uri`／`web.title`（`groundingChunkIndices` で参照）	`url`／`title`、`file_id`／`filename`
③ 資料内の位置	渡した文書の Citations では文字位置／ページ／ブロック番号（あわせて `cited_text`）。Web検索の引用では資料内の位置情報なし	該当する項目なし	該当する項目なし
引用の粒度	渡した文書の場合、文単位（カスタムはブロック単位）で資料内の位置まで返る。Web検索ではURL単位の引用	回答の区間 ↔ Webページ	回答中の引用位置 ↔ Webページ／ファイル

（2026年10月10日時点、ドキュメント等で確認した範囲。Gemini は Interactions API では返し方が異なります）

ざっくり言うと、資料の中の位置（③）まで細かく返すか、資料（②）の単位までにとどめるかが、根拠の種類によって違います。渡した文書が根拠なら中身の位置まで示しやすく、Web検索が根拠ならページ単位になりやすい、と捉えると整理しやすそうです。

また、3社とも、出典の表示のしかたについてルールを設けています。Gemini は検索候補（Search Suggestions）の表示、OpenAI は Web検索の引用を見える形でクリックできるように表示すること、Claude は Web検索の結果をそのまま見せる場合に元の出典を含めること、といった内容です。使う前に各社の利用条件を確認しておくと安心です。

よくある誤解

誤解1：出典が付いていれば正しい

出典は「この資料を根拠にした」という印で、回答が正しいことの保証ではありません。根拠の資料そのものが古い、あるいは間違っていることもあります。前回書いたとおり、グラウンディングしてもハルシネーションはゼロにはなりません。

誤解2：リンク先にその内容が必ず書いてある

AIが資料を読み違えたり、資料にないことを付け足したりすると、リンク先と回答の中身がずれることがあります。また、アプリ側の処理で表示上の引用位置がずれることもあります（たとえば Gemini の Generate Content API の Segment の位置はバイト単位なので、文字数として扱うとずれます）。

Claude の Citations のように、引用した文（cited_text）そのものを返す仕組みであれば、回答と根拠の文を並べて見比べやすくなります。それでも、回答の文が引用した文を正しく言い換えているかは、人が見る必要があります。

誤解3：どのAIでも同じ形で返ってくる

考え方は似ていますが、項目名も、位置の数え方も、粒度も違います。同じ「引用」でも、Claude は資料内の文字位置やページまで返し、本記事で扱った Gemini や OpenAI の引用情報は、Webページやファイルの単位までの対応です。Gemini では、同じ Google検索でも Generate Content API と Interactions API で返し方が違います。複数のAIを切り替えて使うアプリでは、この差を吸収する処理が必要になります。

👉 結局は、リンク先を開く → 該当箇所にその内容があるか見る → 資料自体が新しく信頼できるかを見る、の3ステップを人がやるのが確実です。

似た用語との違い

用語	ひとことで	本記事との関係
グラウンディング	回答を根拠の情報につなぎとめること	出典表示は、グラウンディングした結果を人が確かめるための手段
引用（Citation）	回答のどこが、どの資料（APIによっては資料のどこ）に基づくかを示すこと	本記事の主題。各社のAPIでは `citations` や `url_citation` などの名前で返る
帰属（Attribution）	回答の内容がどの情報源に由来するかを示すこと	引用より広い言い方。「回答が情報源に帰属できるか」を評価する研究の文脈でも使われることがある
Groundedness の評価	回答が根拠に沿っている度合いを測ること	出典が付いていても中身が合っているかは別。それを測る側の話

ざっくり分けると、グラウンディングが「つなぐ」、引用・帰属が「示す」、Groundedness の評価が「測る」 です。

まとめ

AIの出典表示は、回答中のテキストや引用位置と、根拠となる資料を対応づける仕組み。本記事で扱うAPIでは、その対応情報が構造化されたデータとして返る
3社とも「回答のどこが」「どの資料に基づくか」を返す点は共通。資料内の位置まで返るかは、APIや根拠の種類によって異なる
Claude は渡した文書の文字位置・ページまで、Gemini（Generate Content API の Google検索グラウンディング）は回答の区間とWebページの対応を、OpenAI は回答中の引用位置とURL／ファイルの対応を返す
項目名・位置の数え方・粒度は各社で異なる
出典が付いていても正しいとは限らない。最後は人がリンク先を確かめる

👉 一言でまとめると、「AIの出典表示は、AIが付けてくれる脚注」 です。脚注と同じで、たどって確かめるのは読む人の役目です。

参考（公式情報など）

確認日：2026年10月10日。Claude は公式ドキュメントを直接確認しました。Gemini と OpenAI は、検索結果に表示された公式ドキュメントの記述、および GitHub で公開されている公式API定義・公式SDKの型定義を照合しました。いずれも実際にAPIを呼び出して検証したものではありません。