引用
Claudeは、ドキュメントに関する質問に回答する際に詳細な引用を提供することができ、レスポンス内の情報ソースを追跡して検証するのに役立ちます。
引用機能は現在、Claude Opus 4、Claude Sonnet 4、Claude Sonnet 3.7、Claude Sonnet 3.5(新)およびHaiku 3.5で利用可能です。
Claude Sonnet 3.7での引用
Claude Sonnet 3.7は、ユーザーからのより明示的な指示がなければ、他のClaudeモデルと比較して引用を行う可能性が低い場合があります。Claude Sonnet 3.7で引用を使用する場合は、例えば"回答の裏付けとして引用を使用してください。"
のような追加指示をuser
ターンに含めることをお勧めします。
また、モデルが応答の構造化を求められた場合、その形式内で明示的に引用を使用するよう指示されない限り、引用を使用する可能性は低いことが観察されています。例えば、モデルが応答で
引用機能に関するフィードバックや提案をこのフォームを使用して共有してください。
以下はMessages APIで引用を使用する例です:
プロンプトベースのアプローチとの比較
プロンプトベースの引用ソリューションと比較して、引用機能には以下の利点があります:
- コスト削減: プロンプトベースのアプローチでClaudeに直接引用を出力させる場合、
cited_text
が出力トークンとしてカウントされないため、コスト削減が見込めます。 - より信頼性の高い引用: 引用を上記のレスポンス形式に解析し、
cited_text
を抽出するため、引用は提供されたドキュメントへの有効なポインタを確実に含みます。 - 引用品質の向上: 評価の結果、純粋にプロンプトベースのアプローチと比較して、引用機能はドキュメントから最も関連性の高い引用を行う可能性が大幅に高いことがわかりました。
引用の仕組み
以下の手順でClaudeに引用を統合します:
ドキュメントが処理される
- ドキュメントの内容は「チャンク」に分割され、可能な引用の最小粒度が定義されます。例えば、文単位のチャンキングでは、Claudeは単一の文を引用したり、連続する複数の文を連結して段落(またはそれ以上)を引用したりすることができます!
- PDFの場合: PDFサポートで説明されているようにテキストが抽出され、コンテンツは文に分割されます。PDFからの画像の引用は現在サポートされていません。
- プレーンテキストドキュメントの場合: コンテンツは引用可能な文に分割されます。
- カスタムコンテンツドキュメントの場合: 提供されたコンテンツブロックがそのまま使用され、それ以上のチャンキングは行われません。
Claudeが引用付きの回答を提供する
- レスポンスには、各テキストブロックがClaudeが主張する内容とその主張をサポートする引用のリストを含む複数のテキストブロックが含まれるようになりました。
- 引用はソースドキュメント内の特定の場所を参照します。これらの引用の形式は、引用元のドキュメントのタイプによって異なります。
- PDFの場合: 引用にはページ番号の範囲(1から始まる)が含まれます。
- プレーンテキストドキュメントの場合: 引用には文字インデックスの範囲(0から始まる)が含まれます。
- カスタムコンテンツドキュメントの場合: 引用には、提供された元のコンテンツリストに対応するコンテンツブロックインデックスの範囲(0から始まる)が含まれます。
- ドキュメントインデックスは参照ソースを示すために提供され、元のリクエスト内のすべてのドキュメントのリストに従って0から始まります。
自動チャンキングとカスタムコンテンツ
デフォルトでは、プレーンテキストとPDFドキュメントは自動的に文に分割されます。引用の粒度をより細かく制御する必要がある場合(例:箇条書きや書き起こしなど)は、代わりにカスタムコンテンツドキュメントを使用してください。詳細はドキュメントタイプを参照してください。
例えば、ClaudeがRAGチャンクから特定の文を引用できるようにしたい場合は、各RAGチャンクをプレーンテキストドキュメントに入れるべきです。それ以上のチャンキングを行いたくない場合や、追加のチャンキングをカスタマイズしたい場合は、RAGチャンクをカスタムコンテンツドキュメントに入れることができます。
引用可能なコンテンツと引用不可能なコンテンツ
- ドキュメントの
source
コンテンツ内のテキストは引用元として使用できます。 title
とcontext
はオプションのフィールドで、モデルに渡されますが引用コンテンツとしては使用されません。title
は長さが制限されているため、ドキュメントのメタデータをテキストまたは文字列化されたJSONとして保存するにはcontext
フィールドが役立つ場合があります。
引用インデックス
- ドキュメントインデックスは、リクエスト内のすべてのドキュメントコンテンツブロックのリスト(すべてのメッセージにまたがる)から0から始まります。
- 文字インデックスは0から始まり、終了インデックスは排他的です。
- ページ番号は1から始まり、終了ページ番号は排他的です。
- コンテンツブロックインデックスは、カスタムコンテンツドキュメントで提供された
content
リストから0から始まり、終了インデックスは排他的です。
トークンコスト
- 引用を有効にすると、システムプロンプトの追加とドキュメントのチャンキングにより、入力トークンがわずかに増加します。
- ただし、引用機能は出力トークンの使用が非常に効率的です。内部的には、モデルは標準化された形式で引用を出力し、それが引用テキストとドキュメント位置インデックスに解析されます。
cited_text
フィールドは便宜上提供されており、出力トークンとしてカウントされません。 - 後続の会話ターンで渡される場合も、
cited_text
は入力トークンとしてカウントされません。
機能の互換性
引用はプロンプトキャッシング、トークンカウント、バッチ処理などの他のAPI機能と連携して動作します。
プロンプトキャッシングと引用の併用
引用とプロンプトキャッシングは効果的に一緒に使用できます。
レスポンスで生成された引用ブロックは直接キャッシュできませんが、参照元のドキュメントはキャッシュできます。パフォーマンスを最適化するには、トップレベルのドキュメントコンテンツブロックにcache_control
を適用します。
この例では:
- ドキュメントコンテンツはドキュメントブロックの
cache_control
を使用してキャッシュされます - ドキュメントで引用が有効になっています
- Claudeはキャッシュされたドキュメントコンテンツを活用しながら、引用付きのレスポンスを生成できます
- 同じドキュメントを使用する後続のリクエストは、キャッシュされたコンテンツの恩恵を受けます
ドキュメントタイプ
ドキュメントタイプの選択
引用のために3つのドキュメントタイプをサポートしています。ドキュメントはメッセージ内に直接提供するか(base64、テキスト、またはURL)、Files APIを通じてアップロードしてfile_id
で参照することができます:
タイプ | 最適な用途 | チャンキング | 引用形式 |
---|---|---|---|
プレーンテキスト | シンプルなテキストドキュメント、散文 | 文 | 文字インデックス(0から始まる) |
テキストコンテンツを含むPDFファイル | 文 | ページ番号(1から始まる) | |
カスタムコンテンツ | リスト、書き起こし、特殊な書式、より細かい引用 | 追加のチャンキングなし | ブロックインデックス(0から始まる) |
プレーンテキストドキュメント
プレーンテキストドキュメントは自動的に文に分割されます。インラインで提供するか、file_id
で参照することができます:
PDFドキュメント
PDFドキュメントはbase64エンコードされたデータまたはfile_id
で提供できます。PDFテキストは抽出され、文に分割されます。画像引用はまだサポートされていないため、抽出可能なテキストを含まないドキュメントのスキャンであるPDFは引用できません。
カスタムコンテンツドキュメント
カスタムコンテンツドキュメントでは、引用の粒度を制御できます。追加のチャンキングは行われず、提供されたコンテンツブロックに従ってチャンクがモデルに提供されます。
レスポンス構造
引用が有効になっている場合、レスポンスには引用付きの複数のテキストブロックが含まれます:
ストリーミングサポート
ストリーミングレスポンスでは、現在のtext
コンテンツブロックのcitations
リストに追加される単一の引用を含むcitations_delta
タイプが追加されました。