この文章は、生成AIと共同執筆しました。文章の構成作成や、誤字脱字チェックと修正に生成AIを使用していますが、全ての文章の原型は筆者が執筆しています。文責も当然、筆者が負っています。
1. はじめに
「組織内の文書を生成AIに読ませて、質問したら答えてくれるようにできないか」
昨年あたりから、身の回りでこういう要望を聞いたり、直接的な相談を受けることが本当に増えました。組織内ルールの確認・検索、FAQ対応、過去のやり取りの掘り起こし、引き継ぎ資料の要約。組織内には人が読み切れないほどの文書が残っていて、それを生成AIが掘り起こして扱ってくれるなら、確かに便利そうに思えますし、ネット上にはそれが簡単に可能になるような情報が氾濫しています。
実際に手元で雑に試してみると、最初の手応えは割と良いことが多いです。手元の製品マニュアルを何本か読み込ませて、いくつか質問を投げると、それらしい回答が返ってきます。デモとしては十分のように思えます。ところが、読み込ませる文書を組織内全体のリポジトリにした途端、急に話が怪しくなってきます。。「この回答、それっぽいのが本当に正しいか少し怪しい」「古い文書を参照している」「そもそも答えがない質問に、それっぽい何か（笑）を返してたら気づけるのか」細かく見ていくと、次から次へと問題が見つかります。
公開Web向けに整備されたFAQや、きれいにメンテナンスされた製品ドキュメントとは違って、組織内の情報はそもそもとっ散らかっています。この前提を一足飛びに飛ばして「とりあえず動いた」で進めてしまうと、PoCの段階では気づけなかった失敗が、全組織内展開の直前、あるいは実際に展開した後になって表面化します。ここでは、その落とし穴を「検証の設計」でどう先回りするかを考えてみようと思います。本文書では、まず、なぜ組織内RAGがPoCで止まりがちなのか、その仕組みを整理してみます。
2. RAGは「検索してから答える」仕組み
RAGという言葉にあまり馴染みのない方のために、まず仕組みを押さえておきましょう。RAGは Retrieval-Augmented Generation の略で、「検索で補強した生成(AI)」くらいの意味です。やっていること自体は、それほど複雑ではありません。
ユーザーが質問を投げると、システムはいきなり回答を作り始めるのではなく、まず組織内の文書群から関連しそうな箇所を検索します。「就業規則の有給休暇の付与日数は？」と聞かれたら、就業規則の該当部分を探し出す。そして、見つけてきた文書の中身を生成AIに渡して、「この内容をもとに質問に答えて」と指示します。生成AIは渡された文書を根拠にして、自然な日本語で回答を組み立てる。これがRAGの基本的な流れです。
少し補足すると、検索の前段では文書をあらかじめ適当な長さに区切って蓄えておきます。長い規程を丸ごと渡すわけにはいかないので、章や段落といった単位に分割して、それぞれを後から探しやすい形にして保管しておきます。質問が来ると、その質問に意味の近い区切りを引き当てて、上位の数件を生成AIに渡す。つまり、どんな単位で区切るか、何件渡すか、といった設計も回答の質に響いてきます。細かいところはともかく、ここでは「検索して、見つけた断片を根拠に答える」という骨格だけ掴んでもらえれば、と思います。
ここで大事なのは、生成AIが答える内容は、検索で何を拾ってきたかにほぼ依存する、という点だということです。生成AIモデル自体がどれだけ賢くても、検索が見当違いの文書を渡してしまえば、その文書をもとにした回答も的を外します。逆に、古い版の組織内規定を渡せば、古い内容をもっともらしく答えてしまう。渡された材料の範囲でしか答えられない、という意味では、RAGは優秀な新人に資料を手渡して回答を任せるのに近いかもしれません。手渡す資料を間違えれば、どれだけ優秀な新人でも答えは外れます。RAGの品質は、生成AIの部分だけでなく、その手前の「検索」と、検索対象になる「文書群そのものの状態」によって大きく左右される、とご理解いただければとおもいます。
3. 組織内情報は「分散」している
組織内RAGが難しくなる一番の理由は、対象になる情報が一か所にまとまっていないことです。
ちょっとご自分の組織を思い浮かべてみてください。就業規則や各種規程は人事のフォルダにあるかもしれませんが、実際の運用ルールは組織内Wikiに書かれていて、細かい例外はSlackのやり取りで決まって、その経緯はメールに残っている。かもしれない。プロジェクトの仕様は議事録とチケットに分かれていて、お客様とのやり取りはCRMに、関連資料は共有ドライブに散らばっている。一つの問いに答えるための材料が、平気で五つも六つもの場所に分かれて存在していることが多いです。
しかも、それぞれの情報源は性格が違います。規程は正式だけど更新が遅い。Wikiは更新されるけど書き手によって粒度がバラバラ。Slackは最新だけど断片的で、文脈を知らないと意味が取れない。メールは経緯が詳しいけど、どれが最終決定なのか追いにくい。同じ「組織内情報」とひとくくりにしても、信頼度も鮮度も形式も、まったく揃っていないことなんて普通です。
そのうえ、組織内には独特の言語があります。正式名称じゃなくて略称やコードネームで呼ばれるプロジェクト、部署でしか通じない用語、人によって表記の揺れる固有名詞。「あの件」「例のシステム」で通じてしまう会話が、文書のあちこちに残っています。公開Webなら誰にでも分かるように書かれている情報が、組織内では「分かってる人同士の省略だらけの記述」になっている。検索する側からすると、質問の言葉と文書の言葉が素直に一致しないケースが、外部の情報を扱うときよりずっと多いのが自然です。
参考にした検証事例では、情報源ごとの件数分布まで現実に寄せて評価環境を作っていました。チャットツールの投稿が数十万件あるのに対して、正式なドキュメントは数千件しかない、といった偏りです。実際の組織内も、たいていこうなっているはずです。量が多いのは断片的な情報で、きちんと整った正式文書は意外と少ない。この偏りが検索を難しくします。膨大な雑談やメモの山の中に、数少ない正解の文書が埋もれているからです。単一の文書をうまく検索できれば済む話ではなく、散らばった断片を正しく束ねて、しかもノイズに埋もれた正解を掘り当てて、はじめて業務判断に足る答えになる。これが実際に、組織内情報を俯瞰して眺めた際の現実です。
4. 組織内RAGの本番展開でありがちな失敗
では、この散らかった情報を相手にしたとき、組織内RAGは具体的にどう失敗するのか。代表的だと思われるパターンを挙げます。特に、PoCの小さなデータでは見えにくくて、本番ではじめて顔を出す可能性が高いものを選んでいます。
古い情報をそのまま使ってしまう
改定前の規程と改定後の規程が両方フォルダに残っていると、検索が古い方を拾って、もう存在しないルールを堂々と答えてしまいます。読み手が事情を知らない場合、それを最新だと信じて行動してしまうケースが多いです。
最新版を見落とす
逆のパターンで、一番新しい決定がSlackやメールにしか書かれていなくて、正式文書がまだ更新されていない場合、システムは古い正式文書だけを根拠にして、現場の実態とズレた回答を返します。
矛盾した情報を矛盾と気づかずに断定する
文書Aと文書Bで記述が食い違っているとき、本来は「情報が分かれています」と示すべきなのに、片方だけを拾って言い切ってしまうことがあります。
似た文書の取り違え
「2024年度版」と「2023年度版」、本案件と別案件の資料など、タイトルや内容がよく似た文書が並んでいると、検索が正しい情報を提示してくれることは稀です。多くの場合、正しく判断するためには人による介入が必要です。
答えが存在しないのに作ってしまう（ハルシネーション）
まだ決まっていない事項や、組織内に存在しないルールを聞かれたとき、「該当する情報はありません」と言えずに、それらしい回答をでっち上げてしまう。この手の誤りは、（生成AIが書く文章に慣れている人には自明ですが）文章があまりに自然なので、かえって気付くことが難しいケースがあります。
これらの失敗に共通するのは、デモや小規模なPoCでは姿を現しにくい、という点です。文書を数本しか入れていなければ、古い版も矛盾も似た資料も存在しないので、そもそも失敗のしようがありません。むしろPoCで好成績が出てしまうことが、油断を生んでしまうのかもしれません。本番で対象を全社の情報に広げた瞬間、これまで存在しなかった古い版や紛らわしい文書がどっと増えて、それまで見えなかった失敗が一斉に立ち上がる。「小さく試したらうまくいったのに、本番にしたら急に頼りなくなった」という声の多くは、この構造から生まれています。
5. 「信頼できる回答」とは
いま挙げた失敗のどれもが、出力された文章を読んだだけでは見抜けません。生成AIは、根拠が古かろうが、矛盾していようが、そもそも根拠がなかろうが、一様に流暢で自信ありげな文章を返してきます。文体に迷いがないぶん、むしろ紛れ込んだ誤りに対して違和感を抱くのは難しいケースが多いです。
人間の同僚であれば、自信のない案件には「たしかこうだったと思うけど、確認します」と言ってくれるし、声色や言い回しに不自然な感じを印象として受けるかもしれません。ところが生成AIの回答には、その手がかりがありません。正しい回答も間違った回答も、見た目の説得力はほとんど変わらない。だからこそ、回答文の自然さを品質の証拠だと思い込むことは大変危険です。
組織内RAGで本当に確認すべきは、文章の巧みさではなくて、その回答が何に支えられているかです。どの文書を根拠にしているか。その文書の更新日はいつか。正式な文書なのか、個人のメモなのか。必要な情報源を漏れなく拾えているか。そして、不確かなときや答えがないときに、ちゃんと「分からない」「情報がない」と言えるか。これらは出力の見た目とは別のレイヤーにある性質で、意識していないと見えてこないものです。
逆に言えば、ここを測る仕組みさえ持てば、流暢さに惑わされずに済みます。組織内RAGの評価というのは、回答の上手さを採点する作業ではなくて、回答の足元が業務に耐えるかを点検する作業とも言えます。
6. 検証設計は、危ない失敗を事前に見つけるために行う
「検証」や「評価」と聞くと、モデルに点数をつけてランキングする作業を思い浮かべるかもしれません。検索手法Aと手法Bを比べて、正答率が高い方を選ぶ、みたいな感じで。もちろんそれも評価の一部ではあります。しかし、組織内RAGにおける検証の主目的は、点数の良し悪しを競うことではありません。業務で使い始める前に、危ない失敗をあぶり出すことにあります。
考えてみれば当たり前で、平均正答率が90%だったとしても、残りの10%が「契約条件を古い版で答える」「存在しない規程をでっち上げる」みたいな致命的な失敗なら、その組織内RAGはそのまま現場には出すことは難しい。逆に、間違いが「組織内イベントの開催場所をたまに取り違える」程度なら、用途次第では許容できます。大事なのは平均点ではなくて、どんな失敗が、どのくらいの深刻さで起きるのかを把握することです。
そして、この「危ない失敗」は、整ったきれいなデータをいくら評価しても出てきません。古い文書も、矛盾も、似た資料も、答えのない問いも含んだ、本番に近い環境ではじめて姿を現します。だから検証設計の出発点は、評価環境をどう現実に寄せるか、というところにあります。どんな情報を、どんな状態で評価データに入れるか。それ次第で、見つけられる失敗の範囲が決定されるのです。
次回はこのあたりを掘り下げられればと思います。散らかった組織内情報を、どうやって検証用のデータに落とし込むのか。全部を対象にするのではなく、どの業務範囲から手をつけて、どの情報源を選んで、鮮度や正式性やノイズをどう作り込むか。評価環境の設計こそが、組織内RAGの検証の出来を左右する土台になります。
7. まとめ
社内RAGがPoCで止まるのは、技術が未熟だからというより、評価の見方がズレているからです。生成AIは流暢に答えるので、PoCでは「よさそうな回答」が出ているように見えます。しかし本番で問われるのは、必要な根拠を拾えているか、古い情報や矛盾を取り違えていないか、答えがないときに「ない」と言えるか——文章の見た目とは別の層の信頼性です。
社内情報は複数の場所に分散していて、新旧が入り混じり、似た文書や答えのない領域を含んでいます。この現実を前提に、危ない失敗を事前に見つける活動として検証を設計する。それが、PoCを本番につなぐための第一歩になります。第2回では、その検証の土台になる評価環境の作り方に踏み込んでいきます。
参考文献
- Amazon Web Services, 「RAG とは何ですか? – 検索拡張生成 AI の説明」, https://aws.amazon.com/jp/what-is/retrieval-augmented-generation/
- Qiita, 「RAG評価ツール「RAGAS」とは？」, https://qiita.com/ist-i-j/items/13496a07e14a92e898fe
- 山田育矢 監修・著, 鈴木正敏・山田康輔・李凌寒 著, 『大規模言語モデル入門』, 技術評論社, 2023年, ISBN 978-4-297-13633-8
- DevelopersIO, 「社内情報管理のためのRAG構築-どのように検証していくべきか」, クラスメソッド株式会社, https://dev.classmethod.jp/articles/enterprise-rag-evaluation-design/