AIが読めるドキュメントの書き方｜社内文書を「AI-Readable」に直す3つの手当て
社内文書をRAGに投入した。ツールは動いている。それなのに、返ってくる回答が的外れで、現場からは「これなら自分で探した方が早い」と言われる。
こうなると、まず疑うのは検索の仕組みのほうだ。埋め込みモデルを替える、チャンクサイズを調整する、リランカーを足す。筆者もその順で手を入れた。
それで多少は良くなる。ただ、本当に効いたのは別のところだった。投入した文書そのものが、AIに読ませる前提で書かれていなかったのである。
- 精度が出ないとき、文書側に出ている3つの症状
- 見出し・節の独立性・メタ情報という3つの手当て
- 「書く手間が増えるのでは」への実務上の答え
精度が出ないとき、文書側に出ている症状
RAGの回答が当たらない原因として技術記事でよく挙がるのは、チャンク分割の粗さ、検索の取りこぼし、リランキングの不在、クエリと文書の語彙のずれ、インデックスの更新停止といったあたりである。このうち後半の3つは、実は文書の書き方と地続きにある。
筆者が社内でRAGを動かして原因を切り分けたかぎり、文書側の症状は3つに集約された。
- 見出しが内容を表していない：「はじめに」「その他」「補足」といった見出しばかりで、その節に何が書いてあるのかを見出しから判別できない
- 長大な文書が途中で切られる：数十ページのマニュアルや議事録が機械的に分割され、条件と結論が別々の断片に分かれてしまう
- 社内固有の略語・通称が拾えない：質問する側の言い方と文書側の言い方が違い、そもそも検索に引っかからない
あたま3つめは特に厄介でした。人間なら「ああ、あれのことね」で通じる社内の通称が、文書にもクエリにも揺れたまま入っている。検索が悪いのではなく、同じものを指す言葉が組織の中で統一されていなかっただけ、という話です。
どれも、読み手が人間である限りは問題にならなかったものばかりだ。人は目次を眺めて当たりを付け、前後を読んで文脈を補い、略語を経験で読み替える。その補完がすべて効かなくなったのが、読み手をAIに替えたときに起きたことである。
手当て1｜見出しを、内容が分かる名前にする
最初にやるべきは見出しの手直しで、これが費用対効果としては一番大きい。
理由は2つある。一つは、多くのRAG実装が章・節の構造をチャンクの境界として使うため、見出しの付け方がそのまま分割の質になること。文字数だけで機械的に切ると、「〜の場合は」という条件と、その結論が別のチャンクに分かれてしまう。見出しが適切な間隔で入っていれば、意味のまとまりごとに切れる。
もう一つは、AIが答えを組み立てるとき、見出しとその直下の文を手がかりに「この節が質問に関係あるか」を判断していることだ。英語圏のドキュメント論でも、各見出しの直下の最初の段落に最も重要な情報を置くことが繰り返し推奨されている。
見出しは「その節が答える問い」を書く。「その他」ではなく「有給を半日単位で取るときの申請方法」と書く。長くなっても構わない。見出しは目次の飾りではなく、AIにとっての検索対象そのものになっている。
あわせて、節が長くなりすぎていないかも見る。1つの見出しの下に数千字が続いていると、どう切ってもどこかで文脈が途切れる。話題が変わるところで見出しを足すだけで、分割の精度は上がる。チャンク分割そのものの仕組みはRAGとは？仕組み・チャンク分割・ベクトルDBを初心者向けに解説で扱っている。
手当て2｜節を、それ単体で読める形にする
見出しを直しても、節の中身が前後に寄りかかっていると効果は出ない。
- 直前を読んでいる前提の指示語：「上記の場合は」「これを踏まえて」
- 社内でだけ通じる通称：「例のツール」「うちの標準フロー」
- 主語の省略：誰が承認するのか、誰に提出するのかが書かれていない
AIが読むのは、文書全体ではなく検索でヒットした断片である。その断片だけを渡されて答えを組み立てるので、断片の外に置かれた前提は最初から存在しないのと同じになる。
あたまここで一番手強いのが、書き手にとって「暗黙だから書かれていない」前提です。何が抜けているかは、書き手をいくら眺めても分かりません。AIが誤答したときに、はじめて姿を現します。
だから、誤答をつぶすべき不具合として扱うのはもったいない。どの略語が拾えなかったか、どの条件が欠けていたかを記録していけば、明文化すべき前提のリストが業務単位で手に入る。品質の低い回答は、ナレッジの穴の在り処を教えてくれている。
略語・通称は、初出で正式名称を併記するだけで語彙のずれはかなり埋まる。「AI-Readable化」を全社で一斉にやる必要はなく、まず問い合わせの多い業務の文書だけでいい。
手当て3｜メタ情報を、本文の外側に構造化する
本文をいくら整えても、そもそも探す範囲を絞れなければAIは的外れな断片を拾ってくる。ここで効いてくるのが、本文の外側に付ける情報のほうだ。
筆者は個人のナレッジ基盤（Obsidianで運用しているknowledge-wiki）をAIエージェントに読ませている。そこで実際に効いている設計は次の4つだった。
- frontmatterでメタ情報を構造化する：要約・タグ・分類を各ファイルの先頭に置く。本文を読まなくても、探す範囲を絞り込める
- 1ファイル1トピックを徹底する：ファイル単位が、そのまま「単体で読める塊」になる。分割の心配がそもそも要らなくなる
- 関連をリンクで明示する：文脈を「近くに置いてあること」に頼らず、リンクとして書く。離れたページからでも辿れる
- 出典と確からしさを本文に埋め込む：どこから来た情報か、事実なのか推測なのかを本文に残す。AIが情報の強さを判別できる
4つめは見落とされやすいが、効き方が他と違う。出典が書かれていない文書ばかりを読ませると、AIは古い情報と最新の情報、確定事項と検討中の案を同じ重みで扱ってしまう。もっともらしく断定された誤答の多くは、ここから来ている。
社内文書に置き換えるなら、Obsidianのfrontmatterに相当するのは各ツールのプロパティ欄で、リンクに相当するのは関連ページへの参照になる。組織のナレッジDBでこの設計を組むときの落とし穴はナレッジDBの設計でハマった5つの課題と、その対策にまとめている。
「書く手間が増えるのでは」という反論
見出しを付け直し、略語を開き、frontmatterに要約を書く。忙しくて書かれないことがそもそもの問題だったのに、書く条件を厳しくしてどうするのか。
もっともな反問だと思う。実際、キャプチャの摩擦を上げるとナレッジは目に見えて集まらなくなる。
ただ、この2つは同時に満たす必要がない。書くときは雑でいい。走り書きでも、箇条書き数行でも、まず残す。構造を整えるのは、後からAIと一緒にやればいい。見出しを付け直す、略語を正式名称に開く、要約をfrontmatterに起こすといった作業は、まさに生成AIが得意とする種類の仕事である。
入力の摩擦は上げず、構造化は後段の工程に回す。この時間差にすれば、「AIに読ませるための整備」と「そもそも書いてもらう」が両立する。AI向けの整備を、AIに手伝わせるということでもある。
まとめ
RAGの回答精度が上がらないとき、手を入れる先は検索の仕組みだけではない。見出しが内容を表していない、長大な文書が途中で切れる、社内の略語が拾えない。この3つはいずれも文書側の症状で、読み手が人間だった間は誰も困らなかったものだ。
手当ては3つ。見出しをその節が答える問いにする。節の中身を、断片として切り出されても意味が通る形にする。そして要約・分類・関連・出典を、本文の外側に構造として付ける。
全社の文書を一度に直す必要はない。問い合わせの多い業務の文書から始めて、AIが誤答したところを記録していけば、次にどこを直すべきかは向こうから教えてもらえる。この整備をどう位置づけるかという全体像は「貯めるナレッジ」から「AIが動かすナレッジ」へで扱った。
自分の職場で一番よく聞かれる質問は何だろうか。その答えが書いてある文書を開いて、見出しだけ眺めてみるところからでいい。
関連記事
コメント