投稿する
マガジン
著者：アソバース編集部公開：更新：約11分で読めます

チャンクに文書名・見出し・日付を持たせる：RAGのメタデータ設計

AIを使いこなす

Claudeで執筆し、GPTで自動校閲・修正しています。

分割した紙片に文書ごとの色付き付箋を付ける手元
記事の内容をもとに制作したAI生成イメージです。実際の製品画面や検証結果の写真ではありません。

結論から言うと、チャンク（文書を分割した検索単位）には、本文に加えて最低でも「文書名」「見出しの階層」「版または日付」「原本の場所」を付けてください。本文だけを検索すると、「前四半期比で3%増えた」「申請は5営業日前までに行う」のような一文が、どの文書の、いつ時点の、どの節の話なのか分からなくなります。検索でも、回答での出典表示でも、これが誤答の原因になります。 この記事では、持たせる項目の一覧と、用途別（規程・手続き、製品マニュアル、議事録・報告）の必須／任意の区分を示します。あわせて、埋め込み対象のテキストに入れる項目と、絞り込み・表示にだけ使う項目の分け方、LLMにメタデータ抽出を頼む依頼文も載せます。

この記事の目次
  1. 本文だけだと文脈が失われる理由
  2. メタデータを3つの役割に分ける
  3. メタデータ項目一覧：用途別の必須／任意
  4. 埋め込み用テキストへの入れ方（説明用の例）
  5. LLMに抽出させるときの依頼文と人の確認
  6. 最初に決める順番

本文だけだと文脈が失われる理由

AnthropicはContextual Retrievalの解説で、分割したチャンク単体では十分な文脈がなくなる問題を取り上げています。例は「会社の売上が前四半期比で3%伸びた」という一文です。これだけでは、どの会社のいつの話か分かりません。同社は、チャンクごとに説明文を先頭に付けてから索引化する方法を紹介しています。

MicrosoftのAzure AI Searchのチャンク分割ガイドにも、同じ方向の記述があります。長い文書では、文書の途中から作ったチャンクにも文書タイトルを付け足すと文脈の欠落を防げる、という趣旨です。確認した英語版の更新日は2026年6月です。

社内文書では、次のような状況でこの問題が目立ちます。

  • 「第3版」と「第4版」の規程で、同じ見出しの条文が並んでいる
  • 部署ごとに「申請期限」の書き方が違う
  • 議事録に「来月から開始」とだけ書かれ、開催日が本文にない

見出しが「4.2 承認」だけの断片が検索で上位に出ても、AIはどの規程の承認なのか判断できません。

メタデータを3つの役割に分ける

LangChainのドキュメントでは、検索の単位であるDocumentがpage_content（本文）とmetadata（任意の辞書）を持ちます。メタデータには出典や他文書との関係などを入れられ、1つのDocumentはより大きな文書のチャンクであることが多いと説明されています（LangChain: Build a semantic search engine）。つまり、メタデータは付けられますが、何を入れるかは設計者が決めます。

ここから先は公式の仕様ではなく、編集部の設計案です。項目は役割で3つに分けると整理しやすくなります。

  • ①検索用テキスト、使い方：本文の先頭に文字として足し、埋め込みやキーワード検索の対象にする、向いている項目：文書名、見出しパス、施行日などの時点情報
  • ②絞り込み用、使い方：検索条件で候補を機械的に絞る、向いている項目：状態（現行／廃止）、版、部署、閲覧範囲、文書種別
  • ③表示用、使い方：回答の出典として利用者に見せる、向いている項目：原本のURL、ページ、アンカー、所管部署

①に入れた項目は、質問との意味的な近さに影響します。②は「廃止済みの規程は除く」のように、近さに関係なく確実に除外したいときに使います。権限の制御を①に頼ってはいけません。文字として混ぜただけでは、見せてはいけないチャンクを確実に除外できないからです。

メタデータ項目一覧：用途別の必須／任意

次の表の項目名は説明用の例で、実在するシステムの仕様ではありません。「必須」は、欠けると誤答や出典の追跡不能につながりやすい項目、という編集上の判断です。

  • doc_id、内容：文書の固有ID、主な役割：②（更新時の差し替え）、規程・手続き：必須、製品マニュアル：必須、議事録・報告：必須
  • chunk_id、内容：チャンクの固有ID、主な役割：③（出典の特定）、規程・手続き：必須、製品マニュアル：必須、議事録・報告：必須
  • doc_title、内容：文書名、主な役割：①③、規程・手続き：必須、製品マニュアル：必須、議事録・報告：必須
  • section_path、内容：見出しの階層（例：第4章 > 4.2）、主な役割：①③、規程・手続き：必須、製品マニュアル：必須、議事録・報告：任意
  • version、内容：版（第3版、v2.1など）、主な役割：②③、規程・手続き：必須、製品マニュアル：必須（製品版）、議事録・報告：不要
  • effective_date、内容：施行日・適用開始日、主な役割：①②、規程・手続き：必須、製品マニュアル：任意、議事録・報告：不要
  • revised_date、内容：最終改訂日、主な役割：②、規程・手続き：必須、製品マニュアル：必須、議事録・報告：任意
  • doc_date、内容：作成日・開催日、主な役割：①②、規程・手続き：任意、製品マニュアル：任意、議事録・報告：必須
  • doc_status、内容：現行／廃止／草案、主な役割：②、規程・手続き：必須、製品マニュアル：必須、議事録・報告：任意
  • owner_dept、内容：所管部署、主な役割：②③、規程・手続き：必須、製品マニュアル：任意、議事録・報告：任意
  • doc_type、内容：規程、手順書、議事録など、主な役割：②、規程・手続き：任意、製品マニュアル：任意、議事録・報告：任意
  • source_uri、内容：原本の場所、主な役割：③、規程・手続き：必須、製品マニュアル：必須、議事録・報告：必須
  • page_or_anchor、内容：ページ番号や節のアンカー、主な役割：③、規程・手続き：必須、製品マニュアル：必須、議事録・報告：任意
  • access_scope、内容：閲覧できる範囲、主な役割：②、規程・手続き：権限が分かれるなら必須、製品マニュアル：同左、議事録・報告：同左
  • language、内容：言語、主な役割：②、規程・手続き：任意、製品マニュアル：任意、議事録・報告：任意
  • ingested_at、内容：取り込み日時、主な役割：運用管理、規程・手続き：任意、製品マニュアル：任意、議事録・報告：任意

日付は意味ごとに別項目にする

「日付」を1項目にまとめるのは避けてください。規程なら、作成した日、改訂した日、施行日、ファイルを取り込んだ日が別々にあります。回答で「いつ時点のルールか」を示すのは施行日と改訂日です。ファイルの更新日時やingested_atは、保存や転送の都合で変わるため、内容の新しさの根拠には使わないほうが安全です。

埋め込み用テキストへの入れ方（説明用の例）

次は架空の規程で作った例です。実行して確認したものではありません。①に入れる項目を本文の前に付け、②③は別のメタデータとして保持します。

text
【文書】在宅勤務規程（第3版）
【見出し】第4章 申請 > 4.2 承認
【施行日】2025-04-01
承認者は、申請の受領から3営業日以内に可否を回答する。
json
{
  "doc_id": "HR-0012",
  "chunk_id": "HR-0012-v3-0042",
  "doc_title": "在宅勤務規程",
  "version": "第3版",
  "effective_date": "2025-04-01",
  "revised_date": "2025-03-15",
  "doc_status": "現行",
  "owner_dept": "人事部",
  "source_uri": "https://example.com/rules/HR-0012-v3.pdf",
  "page_or_anchor": "p.8",
  "access_scope": "全社員"
}

①のヘッダーは短くしてください。長くすると本文より目立ち、どのチャンクも似た内容に見えて検索が曖昧になります。また、①に入れた項目と②に持つ項目が食い違わないよう、同じ元データから両方を生成する構成にしてください。

文書全体の要約や、チャンクごとの状況説明をLLMに書かせて足す方法もあります。Anthropicの手法はこれに近く、同社は検索の取得失敗が減ったと報告しています。ただし、これはAnthropic自身の評価で、自社の文書で同じ効果が出る保証はありません。導入前に、自社の質問集で前後比較をしてください。

LLMに抽出させるときの依頼文と人の確認

文書名、版、施行日などは、表紙や先頭ページにまとまっていることが多く、LLMに抽出させると手作業を減らせます。ただし日付の取り違えが起きやすい項目なので、「推測しない」「根拠を残す」を指示に入れます。

text
次の文書の先頭部分とファイル情報から、メタデータをJSONで返してください。
ルール:
- 文書内に書かれている値だけを使い、推測しない。見当たらない項目は null にする。
- 日付は YYYY-MM-DD。施行日と改訂日を混同しない。
- 各項目について、根拠にした原文の一文を evidence に入れる。
出力項目: doc_title, version, effective_date, revised_date, owner_dept, doc_status
[ファイル名] （ここに貼る）
[本文の先頭1〜2ページ] （ここに貼る）

機密文書を外部のAIサービスに渡す場合は、社内の取り扱い規則を先に確認してください。学習への利用を止める設定と、秘密保持が守られることは別の話です。迷う場合は、まず架空の文書で試してください。

人が確認する範囲は次のとおりです。

  1. 文書の種類ごとに5〜10件を選び、抽出結果とevidenceを原本と突き合わせる
  2. nullになった項目は、そのまま空にするか、担当者が補うかを決める
  3. 「現行」「廃止」の判定は、LLMの出力ではなく文書管理台帳など管理元の情報を優先する
  4. 取り込み後に数十チャンクを無作為に開き、ヘッダーと出典リンクが正しい文書を指しているか確認する

最初に決める順番

項目をすべて作る必要はありません。次の順番で始めれば、手戻りが少なくなります。

  1. 全用途で必須のdoc_id、chunk_id、doc_title、source_uriを付ける
  2. 見出しの階層を取れる形式（Markdown、HTML、構造化したPDF抽出結果など）なら、section_pathを足す
  3. 版や改訂がある文書は、version、revised_date、doc_statusを足し、廃止分を除外する絞り込みを入れる
  4. 権限が分かれるなら、検索の前段でaccess_scopeによる絞り込みを必ず入れる
  5. 質問集で、出典が正しい文書・版を指しているかを確認し、足りない項目を追加する

最後の確認は、回答の正しさだけでなく、「出典を開いたら根拠が見つかるか」で見るのが実用的です。メタデータが足りないと、答えが合っていても根拠をたどれません。

出典・参考資料

マガジン一覧に戻る