【AI×DevOps Study #20】AI Agent のための RAG System１（全2回）

■AI×DevOps Study #20の概要
2026年8月19日に開催した「AI×DevOps Study」第20回のアーカイブ動画です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
今回のテーマは、AI Agent のための RAG Systemです。
※本勉強会は全2回で構成されています。※

1回目の今回は「RAGの作成」を軸にRAG の基礎と日本語実装についてお話しします。
RAGの必要性からRAGの精度を上げるためのポイント、日本語のRAGを構築する際のハードルや実装について説明します。

■登壇者情報（敬称略）
深津航
株式会社Scalar Founder & CEO。日本オラクル株式会社、決済系のスタートアップを経て、株式会社Scalarを創業。

■関連コンテンツ
・Youtube（過去の勉強会動画も公開中！）
www.youtube.com/@scalar-labs

・Zenn ブログ
https://zenn.dev/p/scalar_sol_blog

・イベントページ（connpass）
https://scalar.connpass.com/

Transcript

1. AIxDevOps AI Agent のための RAG System #1 RAG の基礎と日本語実装 全2回の技術勉強会（第1回） 2026年8月19日 株式会社Scalar 深津航
2. 自己紹介 名前：深津航 所属：株式会社 Scalar CEO, Co-Founder 主な関心事項 • 日本のIT強化 • アーキテクチャ /設計 • DevSecOps, FinOps • AIが与える各種業界へのインパクト ◦ ▪ 株式会社 Scalar としての活動 株式会社Scalarは、分散トランザクションマネージャー のScalarDBと改ざん検知ソフトウェアの ScalarDLを展 開中。マイクロサービス化におけるシステムの課題や AI などのデータ基盤の信頼性を担保するソリューションを 展開しています。 ソフトウェア開発、システム開発、マーケティング、営 業、経営など様々な役割で活動中。 個人的には、 Moltbookが面白い LinkedIn: https://www.linkedin.com/in/wataru-fukatsu-1692655/ AIxDevOps 2 © 2026 Scalar, inc.
3. 本勉強会のゴールと対象者 【ゴール】 【対象者】 RAG の基本構造と限界を理解する AI Agent / RAG を実装するエンジニア 最近の RAG 技術、特に Agentic RAG の⽅向性を理解する エンタープライズ AI 基盤を設計するアーキテクト ⽇本語⽂書‧業務⽂書で RAG を実装する際の課題を理解 する 社内データ活⽤を進める情シス‧DX 部⾨ AI Agent から RAG を使う際の Tool 化‧権限‧監査‧評価 を理解する データ基盤‧DB‧ガバナンスに関⼼がある技術リーダー AI / RAG / Agent 提案を⾏う営業‧プリセールス 企業向け RAG / Agent 基盤の作り⽅を理解する これまで説明してきた RAG の回の元となる技術についての解説回です。 20260416 AI×DevOpsStudy #12 Claude Codeによる製造業向けの RAGとAI Agent開発 2026年07月28日 AI×DevOpsStudy #19 製造業における AIエージェント活用！ RAG/ScalarDBで支える部品選定支援システム AIxDevOps © 2026 Scalar, inc. 2 / 74
4. 全2回の進め方 前編は「RAG を作れるようにする」、後編は「Agent から安全に使えるようにする」。 【前編（本日）】RAG の基礎と日本語実装 1. なぜ AI Agent に RAG が必要か 2. RAG の基本構成 — Query / Retriever / Vector / Prompt / Answer 3. なぜ RAG の精度が上がらないのか — 落とし穴とハードネガティブ 4. Naive RAG から Advanced RAG へ — rewrite / hybrid / rerank 5. 日本語 RAG の難しさ — 形態素解析・表記ゆれ・PDF・表 6. 日本語検索の実装 — Sudachi / kuromoji / GiNZA / BM25 / Embedding 7. Embedding モデル選定 — BGE-M3 / multilingual E5 / 日本語特化 【後編】Agent 時代の RAG Self-RAG / CRAG、RAPTOR / GraphRAG、Multi-Hop、Agentic RAG、MCP、セキュリティ、評価 AIxDevOps © 2026 Scalar, inc. 3 / 74
5. AIxDevOps なぜ RAG が必要か 第1章 LLM 単体の限界、外部知識、業務データ AIxDevOps © 2026 Scalar, inc. 4 / 74
6. 企業知識は LLM の外側にある LLM の内部知識は「学習時点で圧縮された知識」でしかない。 一方、企業業務で必要になるのは次の4つ。 ・現在の事実（いま何が起きているか） ・社内固有のルール（規程・手順・例外） ・顧客ごとの状況（契約・履歴・ステータス） ・権限に応じた情報アクセス（誰が何を見てよいか） この4つはいずれもモデルの重みの中にはない。したがって、 LLM をどれだけ大きくしても業務の問いには答えられない。 企業知識の大半は LLM の外側にあり、それを補う仕組みが要る。 AIxDevOps © 2026 Scalar, inc. 5 / 74
7. LLM 単体には6つの限界がある いずれも「モデルの賢さ」では解決しない。知識をどこに置くかの問題である。 LLM の限界 説明 最新情報を知らない 学習後に発⽣した情報、社内の最新ルール、最新価格を知らない 社内情報を知らない 契約書、提案書、議事録、CRM、設計書などにアクセスできない ユーザー別の権限を知らない 誰がどの情報を⾒てよいかを判断できない 出典を保証できない もっともらしいが根拠不明な回答を作ることがある データの鮮度を判断できない 古い仕様書と最新仕様書を区別できない 業務状態を知らない 受注状況、在庫、障害状況、顧客ステータスを知らない AIxDevOps © 2026 Scalar, inc. 6 / 74
8. RAG は検索した結果を根拠に回答する RAG = Retrieval-Augmented Generation（検索拡張⽣成）。学習済み知識だけで答えず、外部を検索してその結果を根拠にする。 ✓ 質問 検索器 データストア LLM 根拠付き回答 検索対象 索引 投⼊ 出⼒ ⽂書‧DB‧Web‧社内ナ 意味検索のためのベクトル 検索された⽂章をプロンプ 根拠と出典を伴う回答 レッジ 索引 トへ AIxDevOps © 2026 Scalar, inc. 7 / 74
9. RAG が Agent に提供する5つのもの AI Agent における RAG は「検索付きチャットの部品」ではなく、業務環境の中で正しく判断するための知識アクセス基盤である。 RAG が提供するもの 意味 外部知識へのアクセス LLM が知らない最新情報‧社内情報を取得する 業務データとの接続 ⽂書、DB、CRM、契約、FAQ、ログなどを参照する 根拠付き回答 回答の出典‧証拠を⽰す 権限に応じた知識利⽤ ⾒てよい情報だけを検索‧利⽤する 判断‧実⾏の前提情報 Agent が業務アクションを起こす前に事実確認する ⽰唆 5つ⽬が Agent 特有。Agent は「回答する」だけでなく「実⾏する」ため、実⾏前の事実確認が RAG の役割になる。 AIxDevOps © 2026 Scalar, inc. 8 / 74
10. RAG が解決を目指す 5つの課題 RAG は、LLM が構造的に抱える次の5つの課題を補完するために使う。 1. LLM が事実に基づかない出力をしてしまう（ハルシネーション） 2. LLM の出力の根拠を調べるのが困難（説明責任を果たせない） 3. LLM が学習する情報の制御が困難（何を知っているか管理できない） 4. より新しい情報や異分野のデータへの適用が困難（再学習コスト） 5. 知識を扱うために大規模なモデルが必要（コストと運用の重さ） RAG は「LLM が持っていない情報を補完して回答作成を支援する」仕組み。 モデルを大きくするのではなく、外部の知識源を検索して渡すことで解決する。 AIxDevOps © 2026 Scalar, inc. 9 / 74
11. 出典の有無が説明責任を分ける 【LLM が⼀般知識で回答した場合】 【RAG を使い出典も含めて回答する場合】 「おそらく、この契約では再委託は禁⽌されてい ます。」 「契約書第12条において、事前の書⾯承諾なしに 再委託してはならないと定められています。出典 ：A社契約書 v3.2, 第12条, 2026年4⽉1⽇版」 • • • • 根拠がどこにあるか分からない 正しいかどうか検証できない 後から監査に答えられない 業務判断の材料にできない AIxDevOps • • • © 2026 Scalar, inc. ⽂書‧条番号‧版‧⽇付まで辿れる 誤りがあれば原⽂で確認できる 業務プロセスに対して説明責任を果たせる 10 / 74
12. Chatbot RAG と Agentic RAG の違い 両者の違いは「誰が検索を決めるか」。Chatbot RAG は検索が固定⼿順、Agentic RAG は Agent が検索の要否と順序を決める。 Chatbot RAG Agentic RAG • ユーザー質問を受け取る • ユーザー依頼を受け取る • 関連⽂書を検索する • Agent がタスクを分解する • LLM が回答する • 必要な情報を判断する • （固定⼿順。1往復で終わる） • 複数の検索‧DB‧API を呼ぶ • 根拠を確認し、必要なら追加検索 • 判断し、回答または業務アクション AIxDevOps © 2026 Scalar, inc. 11 / 74
13. AIxDevOps RAG の基本構成 第2章 Query、Retriever、Vector、Prompt、Answer AIxDevOps © 2026 Scalar, inc. 12 / 74
14. RAG は5⼯程に分解できる RAG を⾼度化するには、各⼯程ごとに精度を上げる仕組みを作る。⼯程を分解しておくと、失敗の原因を⼯程単位で特定できる。 Query Retriever Vector Prompt Answer Query Retriever Vector Prompt Answer 質問を検索可能な形 関連情報を広く探す 意味検索⽤の索引を 根拠を⽂脈に埋める 根拠付きで回答する へ変換する 引く ⽰唆 「RAG の精度が悪い」は診断ではない。5⼯程のどこで落ちたのかを⾔えるようにするのが設計の第⼀歩。 AIxDevOps © 2026 Scalar, inc. 13 / 74
15. Query：検索できる問いに変える ユーザーの自然文をそのまま検索に使うと、検索漏れが起きやすい。 Query 工程の役割は、質問を「検索できる問い」に変換すること。 【Query の4つの役割】 1. 意図を抽出する ― 何を知りたいのか、何を実行したいのか 2. 検索条件へ変換する ― キーワード、日付、顧客、製品、権限などへ変換 3. 必要なら分解する ― 複数文書・複数DBにまたがる問いに分ける 4. 曖昧さを減らす ― 略語、表記揺れ、対象範囲を補正する 特に「意図を抽出する」部分では、これまでのやりとりやドメインナレッジを 補完するプロンプトを用意しておくと、意図を汲み取りやすくなる。 AIxDevOps © 2026 Scalar, inc. 14 / 74
16. Query の良い例と悪い例 【悪い例】 【良い例】 「料⾦を教えて」 「2026年7⽉時点の Enterprise プランの料⾦と割 引条件を検索して」 • • • • いつ時点の料⾦か分からない どのプランか分からない 割引条件を含むのか分からない 検索してもヒットが広がりすぎる • • • 検索結果が数百件に広がり、Rerank でも上位に正 解が来ない。 AIxDevOps 時点（effective_date）が⼊っている 対象（プラン名）が特定されている 観点（料⾦‧割引条件）が明⽰されている メタデータフィルタに落とせるので、検索対象が 最初から絞られる。 © 2026 Scalar, inc. 15 / 74
17. Retriever：広く集めて、落とす Retriever の原則は「候補を広く集め、不要なものを落とす」。単独の検索⽅式ではなく、4つを組み合わせて実⾏するのが実務の基本 形。 Vector Search Keyword / BM25 Metadata Filter Rerank 意味が近い⽂書を探す。表 固有名詞‧型番‧条⽂番号 顧客/⽇付/版/権限で絞る 候補を再評価し、上位の根 記ゆれに強い に強い 拠を選ぶ ⽰唆 「まず広く（Recall を稼ぐ）、次に絞る（Precision を上げる）」の順序が重要。最初から絞ると、落とした⽂書は戻らない。 AIxDevOps © 2026 Scalar, inc. 16 / 74
18. Vector：意味検索のための索引 曖昧なデータを探すために、意味で検索できる仕組みを作る。この索引がベクトルである。4つの部品でできている。 Chunk Embedding Metadata Index ⽂書を意味のある単位に分 テキストを数値ベクトル化 ⽂書名‧ページ‧版‧更新 近傍探索を⾼速化する 割する する ⽇‧権限 注意 4つのうち Metadata は忘れられがちだが、業務 RAG ではここが権限制御と鮮度制御の⼟台になる。ベクトルだけ持っていても業 務では使えない。 AIxDevOps © 2026 Scalar, inc. 17 / 74
19. Prompt：文脈を組み立てる 検索結果をそのまま貼るのではなく、 4つの要素を明示的に組み立てる（ Prompt Assembly）。 • • • • System Instruction ― 役割、禁止事項、回答形式 User Query ― 元の質問、制約、目的 Retrieved Context ― 検索された根拠文書、ページ・節・更新日 Output Contract ― 出典の付け方、確信度、未確認時の対応の指示 取り出した結果を回答に埋め込む際は、「根拠外の推測を抑制するための情報」を 一緒に埋め込む。たとえば次のような指示を Output Contract に置く。 「提示された文脈にない事実は書かないこと。根拠が不十分な場合は 『提供された資料からは確認できません』と答えること。」 AIxDevOps © 2026 Scalar, inc. 18 / 74
20. Answer：4要素を必ず含める 回答テンプレートを用意し、次の 4要素を必ず含めるよう指示する。 根拠が不十分な回答やハルシネーションを抑制できる。 • • • • 結論 ― 質問に対する短い答え 根拠 ― 参照文書・ページ・節 前提条件 ― いつの情報か、どの範囲か 限界 ― 不明点・未確認事項、追加確認先 「限界」を書かせるのが特に効く。答えられないときに黙って推測させず、 「ここまでは分かった / ここからは分からない」を明示させる。 業務では、間違った断定よりも、正直な保留のほうが価値が高い。 AIxDevOps © 2026 Scalar, inc. 19 / 74
21. AIxDevOps 精度が上がらない理由 ! AIxDevOps ✕ 第3章 RAG の落とし穴とハードネガティブ © 2026 Scalar, inc. 20 / 74
22. RAG が失敗する 3つの理由 1. RAG に対する期待値と実装のギャップが発生する RAG はどのようにデータを格納し、どのように返却するかで精度が変わる。 満たすべき期待値と、実装可能なレベルをすり合わせておく必要がある。 2. 十分なデータの前処理をしていない 前処理が甘いと、そもそも正しい結果を生成できない。 日本語の業務文書では、ここが最大の失敗要因になる（第 5章で詳述）。 3. 導入後の継続的な改善をしない RAG は作って終わりではない。日々更新されるデータ、日々進化し続ける LLM、 ユーザーのフィードバックを受け入れ、仕組みを改善し続ける必要がある。 AIxDevOps © 2026 Scalar, inc. 21 / 74
23. 精度は⼆箇所で落ちる 【検索で精度が落ちる】 【回答の⽣成で精度が落ちる】 • 関連性の低い情報の取得 → ノイズが⽂脈を汚す • 検索結果の不適切な反映 → 根拠があるのに使わない、取り違える • 必要な情報の不⾜ → そもそも根拠が Top-k に⼊っていない • LLM の能⼒不⾜ → ⻑い⽂脈の中で情報を統合できない 対処：Query rewrite / Hybrid search / Rerank / メタデータフィルタ（第4章） 対処：Prompt Assembly / Output Contract / Rerank による順序制御 / Verifier（後編） AIxDevOps © 2026 Scalar, inc. 22 / 74
24. 情報量を増やすほど良い訳ではない RAG システムに与える情報量と性能の関係は、単調増加ではない。研究で次の3点が報告されている。 1. 最初は上がる 2. 途中で反転する 3. 良い検索ほど顕著 与える情報量が増えるほど RAG の性 ある時点を境に、性能が低下し始める ⾼性能な検索エンジンを使うほど、こ 能も向上する の現象が強く出る ⽰唆 「Top-k を増やせば精度が上がる」「⻑いコンテキストに全部⼊れればよい」という直感は誤り。3番⽬は特に反直感的で、検索 を良くしたのに回答が悪くなる。 出典: Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG（arXiv:2410.05983） AIxDevOps © 2026 Scalar, inc. 23 / 74
25. ハードネガティブとは何か LLM に渡す情報は、単に無関係な情報よりも、 「関連しているように見えて実は役に立たない情報」 のほうが、AI の判断を狂わせやすい。 この紛らわしい情報をハードネガティブ（ hard negative）と呼ぶ。 そして検索エンジンの性能が上がれば上がるほど、こういった紛らわしい情報も 増えてしまうという特性がある。検索が賢くなると、無関係な文書は減るが、 「惜しい文書」の割合が上がるためである。 例：「宿泊費の上限」を聞かれたときに、旧版の経費規程、海外出張規程、 別部門の細則が上位に並ぶ。どれも本物らしく見えるが、答えではない。 → 対処は「LLM 側」と「RAG システム側」の両方に必要になる。 AIxDevOps © 2026 Scalar, inc. 24 / 74
26. LLM 側の対処： 3つの方法 1. 検索結果の並べ替え（ Re-Rank） LLM は文章の始めと終わりに注目する傾向があるため、最も関連性の高い情報を 文脈の最初と最後に配置する。文書の要約と該当箇所を、検索結果としてフィードバック する文章の冒頭に持ってくる。 2. RAG 特有の LLM ファインチューニング ハードネガティブを含む文章をたくさん読ませ、関係ない情報に惑わされないよう訓練する。 文章空間が大きいと学習コストが高くなるため、テーマごとに RAG と LLM を分割して訓練する。 3. 中間推論を含む RAG 指向ファインチューニング 検索結果からそのまま回答を生成させず、「まず情報を整理し、それから回答を考える」 と明示的に指示する。プロンプトに的確な指示を組み込むだけでも精度は上がる。 AIxDevOps © 2026 Scalar, inc. 25 / 74
27. データ側の対処： 4つの方法 1. ひとつの意味を形成する単位に分割する 前後に文脈が連なる文章を、適切な意味の単位で分割しておく。文字数だけで 切ると、前後の文が互いにハードネガティブを引き起こす要因になる。 2. 文章全体の要約を用意しておく あらかじめ文書を要約し、分割されたチャンクと同じ領域に配置する。文書そのものと、 文書中の特定の文章の両方を返せるようになり、回答精度が上がる。 3. 広く検索した後に並べ替える ベクトル空間の次元を下げて広く候補を取り、文書分類ごとに空間を分けて暴発を防ぐ。 同時に LLM にキーワードを選出させ、キーワード検索も併用して候補を広げる。 そのうえで質問とのコサイン距離で並べ替え、近いものを重要な根拠として認識させる。 4. 見当違いの文章は返却しない 質問と検索結果のコサイン距離を測り、関連度がない文章は回答に含めない。 AIxDevOps © 2026 Scalar, inc. 26 / 74
28. RAG の性能評価の視点 【検索結果の評価視点】 • Context Relevance（⽂脈の関連性） 検索された⽂脈は質問に関連しているか • Answer Faithfulness（回答の忠実性） 回答は検索⽂脈に⽀えられているか • Answer Relevance（回答の関連性） 回答は質問に答えているか AIxDevOps 【検索結果に基づいて回答する LLM の評価視点】 • • • • Noise Robustness（ノイズへの頑健性） Negative Rejection（回答不可能な質問の却下） Information Integration（情報の統合） Counterfactual Robustness（反事実への頑健性） ハードネガティブ対策の効果は、主に Noise Robustness と Negative Rejection に表れる。 © 2026 Scalar, inc. 27 / 74
29. AIxDevOps Advanced RAG へ 第4章 Query rewrite、Hybrid search、Rerank AIxDevOps © 2026 Scalar, inc. 28 / 74
30. Naive RAG とは何か Naive RAG は RAG の最小構成 を指す。 「検索して、検索結果をプロンプトに入れ、 LLM が回答する」だけの構成。 最小の構成となるため、 PoC などで、LLM が社内文書に接続し、検索し、結果を 返せるかどうかを検証する際に、最初に構築する RAG になる。 まずこれを構築して社内文書との接続を確認するところからスタートすることで、 基本的な機能が動作するかを検証できる。 ただし、品質は保証しない。 Naive RAG は「つながるか」の検証用であって、 「使えるか」の検証用ではない。ここを取り違えると期待値がずれる。 AIxDevOps © 2026 Scalar, inc. 29 / 74
31. 限界は LLM の問題ではない Naive RAG の限界は「LLM の問題」だけではなく、 検索・データ管理・アクセス制御の問題でもある。 よくある誤診と実際の原因： 「LLM が賢くない」 → 実際は必要な文書が Top-k に入っていない（検索の問題） 「回答が古い」 → 実際は旧版文書が索引に残っている（データ管理の問題） 「見せてはいけない情報が出た」 → 実際は索引に権限メタデータがない（アクセス制御の問題） 「回答が不安定」 → 実際は関係ない文書が毎回混ざる（検索の問題） 本番導入では、 RAG は「LLM 連携機能」ではなく、 データ検索・権限制御・運用監査を含む業務システムとして設計する。 AIxDevOps © 2026 Scalar, inc. 30 / 74
32. 課題は5つに集中しやすい 課題は LLM ではなく「検索‧⽂脈‧データ管理」に集中しやすい。現場で出る不具合はほぼこの5つに分類できる。 検索ミス ⽂脈不⾜ 権限漏れ 古い情報 不安定な回答 表現ゆれで正しい⽂ 断⽚だけで意味を誤 ⾒せてはいけない情 旧版や失効データを 関係ない⽂書でもっ 書を逃す 解する 報が混⼊する 参照する ともらしく誤答 ⽰唆 1‧2‧5 は検索品質の問題で Advanced RAG が効く。3‧4 はデータ基盤の問題で、検索アルゴリズムでは解けない。 AIxDevOps © 2026 Scalar, inc. 31 / 74
33. RAG 成熟度の3段階 RAG は「検索アルゴリズムの⾼度化」と「データ基盤の堅牢化」の2軸で進む。⾶ばして最終段階には⾏けない。 1. Naive RAG 2. Advanced RAG 3. Enterprise RAG 質問をそのまま検索し、上位⽂書をその 質問を整形し、複数検索を統合し、再評 権限‧鮮度‧監査‧トランザクションを まま投⼊する 価してから回答に使う データ基盤で保証する ⽰唆 本章で扱うのは Naive → Advanced。Enterprise 段階に必要なデータ基盤は本章の終盤と後編で扱う。 AIxDevOps © 2026 Scalar, inc. 32 / 74
34. Query rewrite：検索しやすい形へ ユーザーの⾃然⽂をそのまま検索に使うと検索漏れが起きやすい。検索の前に、質問を検索器が扱える形へ変換する。 User Query（曖昧‧⼝語‧省略） Query Rewrite Search Queries（複数） ⾔い換え 分解 ⽤語展開 条件抽出 同義語‧略語を展開する 複合的な問いをサブ質問に 社内⽤語‧正式名称を補う メタデータ条件を取り出す 割る ⽰唆 出⼒は1本の⽂字列ではない。ベクトル検索⽤クエリ‧キーワード検索⽤クエリ‧フィルタ条件の3点セットにする。 AIxDevOps © 2026 Scalar, inc. 33 / 74
35. Query rewrite の実例 例：経費精算ルールの宿泊費上限を聞かれた場合 【入力】 「最新版の出張時のホテル代はいくら？」 【変換（検索語の展開）】 「経費精算規程」「出張規程」「宿泊費上限」「国内出張」「最新版」 【抽出（メタデータ条件）】 effective_date（発効日）、document_status（承認済みか）、 department（適用部門）、 region（国内／海外） 「ホテル代」という口語は社内文書には出てこない。「宿泊費」「宿泊料上限」に 変換して初めて BM25 が効く。同時に「最新版」を filter に落とすことで、 旧版の規程が上位に来る事故を検索段階で防げる。 AIxDevOps © 2026 Scalar, inc. 34 / 74
36. Hybrid search：弱点を相互補完 ベクトル検索だけでは固有名詞‧型番‧規程番号‧略語に弱い。意味の近さで広く拾い、キーワードで正確性を補う。 Rewritten Query Vector Search / Keyword Search Fusion（RRF） Candidate Docs Vector Search Keyword Search Fusion 意味の近い⽂書を広く拾う ⽤語‧ID‧番号を正確に拾う RRF などで両者の順位を統合する ⽰唆 狙いは相互補完。ベクトルは型番を拾えず、BM25 は「解約したい」と「契約終了」を結べない。 AIxDevOps © 2026 Scalar, inc. 35 / 74
37. Rerank：回答に使う順に並べる ⼀次検索の上位が、必ずしも回答に最も有⽤とは限らない。質問と候補をペアで評価し直し、根拠として使える順に並べ替える。 ⼀次検索の順位 Rerank 後の順位 ‧候補 1 score = 0.82 ‧再順位 1 relevance = 0.94 ‧候補 2 score = 0.76 ‧再順位 2 relevance = 0.87 ‧候補 3 score = 0.70 ‧再順位 3 relevance = 0.80 ‧候補 4 score = 0.64 ‧再順位 4 relevance = 0.73 ‧候補 5 score = 0.58 ‧再順位 5 relevance = 0.66 ⽰唆 Cross-encoder / LLM Reranker は質問と候補をペアで読むため、「答えているか」を判定できる。 AIxDevOps © 2026 Scalar, inc. 36 / 74
38. 業務利⽤で必要な4つの制御 Advanced RAG は検索テクニックだけでなく、データガバナンスの設計でもある。検索の前後に4つの制御を⼊れる。 権限 鮮度 ⽂脈 監査 ユーザー属性‧所属‧案件 最新版‧発効⽇‧失効⽇‧ 親⼦チャンク‧セクション 誰が、何を検索し、どの根 ‧契約に応じて検索対象を 承認済み状態をメタデータ ‧表や前後段落をまとめて 拠で回答したかを記録する 制限する で制御する 投⼊する ⽰唆 実装のポイントは、検索対象を「ドキュメント全⽂」ではなく、権限‧版‧有効期間‧出典‧テナント情報を持つデータとして 管理すること。テキストだけを持つ設計では後から権限を⾜せない。 AIxDevOps © 2026 Scalar, inc. 37 / 74
39. 参照アーキテクチャ PoC から本番化する際は、検索パイプラインとデータ管理パイプラインを分けて設計する。 Ingest Normalize Index Retrieve Rerank ⼯程 担当すること Ingest / Normalize ⽂書取得、抽出‧分割、メタデータ付与 Index Vector / Keyword 索引、最新版索引の維持 Retrieve / Rerank rewrite + hybrid + filter、根拠候補の再順位付け Generate / Audit 根拠付き回答⽣成、検索‧回答‧根拠の記録 AIxDevOps © 2026 Scalar, inc. Generate Audit 38 / 74
40. 導入ステップと評価指標 Advanced RAG は一気に作るより、評価指標を置いて段階導入する。 Step 1 Naive RAG をベースラインにする 現在の検索漏れ・誤答を可視化する。ここを測らずに改善はできない。 Step 2 Query rewrite を入れる 表現ゆれ・省略・部門用語に対応する。 Step 3 Hybrid + Rerank を入れる 検索漏れとノイズを同時に削減する。 Step 4 データ基盤を統合する 権限・鮮度・業務データの一貫性を強化する。 【評価指標】 Recall@k / 回答正確率 / 根拠一致率 / 権限違反ゼロ / 旧版参照率 / 回答レイテンシ AIxDevOps © 2026 Scalar, inc. 39 / 74
41. AIxDevOps ⽇本語 RAG の難しさ 第5章 形態素解析、表記ゆれ、PDF、表 </> AIxDevOps © 2026 Scalar, inc. 40 / 74
42. ⽂書を⼊れて検索すれば終わりではない ⽇本語 RAG は「⽂書を⼊れて検索すれば終わり」ではない。難しさは「モデル」だけでなく「⼊⼒データの壊れ⽅」にも由来する。 ⽂書収集 前処理 索引化 検索 なぜ難しいか 何が起きるか 何が必要か ⽇本語は単語境界が曖昧 検索漏れ ⽇本語向け前処理 同じ意味でも表記が揺れる 誤ったチャンク化 検索⽅式の⼯夫 業務⽂書が PDF 中⼼で構造が崩れる 表や図表の⽋落 PDF‧表の構造化 回答の根拠不⾜ 評価と改善サイクル AIxDevOps © 2026 Scalar, inc. 回答 41 / 74
43. 日本語で起きやすい 4つの問題 1. 形態素解析 / トークナイズ 単語の境界が明示されないため、分かち書き・索引化・クエリ理解が難しい。 2. 表記ゆれ / 同義表現 漢字・ひらがな・カタカナ・英字・略語で、同じ概念が複数の表現を持つ。 3. PDF / OCR / レイアウト 段組み、ヘッダ／フッタ、改行、図表埋め込みでテキスト化が崩れやすい。 4. 表 / 図 / 構造データ セルの関係や見出しの階層が落ちると、意味が壊れたまま検索される。 優先度：固有名詞・表記ゆれ・文脈切断を先に潰す。 ここが崩れると、後段の LLM では補正しにくい。 AIxDevOps © 2026 Scalar, inc. 42 / 74
44. 1. 形態素解析が難しい理由 日本語は英語のような空白区切りがなく、単語境界の推定が必要になる。 • • • 専門用語・固有名詞・製品名は辞書にないことが多い 複合語の切り方で意味と検索精度が変わる クエリ側と文書側で分割単位がずれるとヒットしにくい 例：「生成AI活用支援基盤」を 生成 / AI / 活用 / 支援 / 基盤 と切るか、一語として扱うか。 【影響】検索漏れ、チャンク化の不整合、Embedding の意味が薄まる 【対応の方向性】 日本語向け形態素解析器の活用／ユーザー辞書・業界辞書の追加／ 文字 n-gram や BM25 の併用／クエリ正規化と同義語展開 AIxDevOps © 2026 Scalar, inc. 43 / 74
45. 2. 表記ゆれが検索を難しくする ユーザーの質問表現と⽂書表現が違うと、正しい⽂書が検索上位に来ない。同じ意味でも、検索上は別物として扱われる。 意味 実際に現れる表記例 認証 認証 / authentication / auth データベース DB / Database / データベース 申込 申し込み / 申込み / エントリー ⽣成AI ⽣成AI / GenAI / LLM活⽤ ⽰唆 対応は「正規化‧同義語辞書‧クエリ書き換え‧ハイブリッド検索」で吸収する。Embedding だけでは略語や社内独⾃語を拾え ない。 AIxDevOps © 2026 Scalar, inc. 44 / 74
46. 3. PDF：読めると使えるは違う 業務ナレッジの多くは PDF で配布される。しかし PDF は見た目を保存する形式で、 論理構造が弱いことが多い。段組み・注釈・ヘッダ／フッタ・ページ番号が 本文に混入しやすく、スキャン PDF では OCR 品質が検索品質を左右する。 【よくある壊れ方】 • • • 本文の途中にページヘッダが入る 左右2段組みが1行ずつ交互に混ざる OCR 誤認で用語が別文字になる（「認証」→「認詔」など） 【必要な対策】 • • • • レイアウト解析（段組み・領域の判定） 見出し・段落単位での抽出 OCR 後の補正（辞書照合・言語モデルによる訂正） 出典ページ・座標の保持（回答から原文に戻れるようにする） AIxDevOps © 2026 Scalar, inc. 45 / 74
47. 4. 表はセル関係が壊れると死ぬ 例：料⾦表 / SLA表 / 製品仕様表。単純にテキスト抽出すると、列⾒出しとセルの関係が失われる。 プラン 容量 価格 Std 100GB ¥10万 Ent 1TB ¥50万 壊れ⽅ 単純抽出後は「Std 100GB ¥10万 Ent 1TB ¥50万」と並び、 どの数値がどの列のものか分からなくなる。 表構造抽出 HTML / Markdown 化 セル結合の保持 表専⽤要約 セルの⾏列関係を保ったま 構造を保持した形式に変換 結合セル‧階層⾒出しを失 表の内容を⽂章として1本⽤ ま取り出す して埋め込む わない 意する AIxDevOps © 2026 Scalar, inc. 46 / 74
48. ファイルからどう情報を取り出すか ⽂書ファイルは Excel‧PowerPoint‧Word‧PDF‧画像‧動画など様々。フォーマットに合った抽出ライブラリを使い、必要に応じて OCR をかける。 ⽂書 テキスト抽出 分割 / 要約 メタデータ抽出 索引へ テキスト抽出 OCR 処理 ナレーティブ⽣成 フォーマット別のライブラリを使う ⼿書き‧写真の⽂書に適⽤する 純粋な画像‧動画は説明⽂を⽣成して抽 出する ⽰唆 ⽂書の要約を作ると Contextual Embedding に使える。要約ベクトルとチャンクを合成すると識別精度が上がる。 AIxDevOps © 2026 Scalar, inc. 47 / 74
49. 抽出・OCR に使えるライブラリ Docling — https://www.docling.ai/ 文書ファイルから文字列や画像などを分離して取り出せる。中に含まれる画像を AI-OCR にかけることもできる。表構造の抽出にも対応しており、 Markdown / JSON へ構造を保ったまま変換できる。 国立国会図書館 NDLOCR-Lite — https://lab.ndl.go.jp/news/2025/2026-02-24/ 日本語の手書きを含む高度なAI-OCR モデル。日本語の縦書き・旧字体・ 帳票など、汎用 OCR が苦手とする領域で精度が出る。 Apache POI — https://github.com/apache/poi Office 文書（Word / Excel / PowerPoint）の構造を解析できるライブラリ。 セル・スタイル・見出し階層をそのまま取り出せるため、表の関係を保てる。 選定の観点：構造を保てるか／日本語の精度／出典位置を返せるか／ライセンス AIxDevOps © 2026 Scalar, inc. 48 / 74
50. ⽇本語 RAG の改善アプローチ ⽇本語では「検索前の整形」と「検索後の選別」の両⽅が特に重要になる。⼯程ごとにやることを固定しておく。 前処理 チャンク化 索引化 検索 ⽣成 前処理 チャンク化 索引化 検索 ⽣成 正規化 ⾒出し単位 BM25 + Embedding Query rewrite 出典付与 OCR 補正 表‧図表は別扱い メタデータ付与 Hybrid search 根拠確認 ノイズ除去 Rerank ⽰唆 評価観点は検索品質‧⽣成品質‧運⽤品質の3つ。特に運⽤品質（⽂書を⾜しても品質を保てるか）が抜けやすい。 AIxDevOps © 2026 Scalar, inc. 49 / 74
51. AIxDevOps ⽇本語検索の実装 第6章 Sudachi、kuromoji、GiNZA、BM25、Embedding </> AIxDevOps © 2026 Scalar, inc. 50 / 74
52. 実装でまず決めるべきゴール PoC ではなく、業務検索として成⽴する基準を先に定義する。ゴールが違えば選ぶ部品も変わる。 Goal A：キーワード検索強化 Goal B：意味検索強化 Goal C：RAG 向け統合検索 社内⽤語‧製品名‧型番を正確に引く ⾔い換え‧曖昧質問‧⾃然⽂検索に対応す 検索漏れとノイズを両⽅減らす Elasticsearch / OpenSearch / Solr で実装 る Hybrid Search + Rerank + Metadata filter しやすい Embedding + Vector DB が中⼼ 権限‧更新‧評価まで含める kuromoji + BM25 が中⼼ BM25 だけでは拾えない⽂書を補完する ⽰唆 業務 RAG では C を⽬標にし、A / B を部品として組み合わせる。A だけ、B だけで作ると必ずどちらかの⽳が残る。 AIxDevOps © 2026 Scalar, inc. 51 / 74
53. ⽇本語解析ツールの使い分け GiNZA / Sudachi / kuromoji は競合というより⽤途が異なる。どこで何を使うかを決めておく。 ツール 主な⽤途 検索実装での役割 GiNZA spaCy ベースの⽇本語 NLP 固有表現抽出、係り受け、メタデータ化、クエリ理解 Sudachi ⽇本語形態素解析器 分割粒度の調整、正規化、ユーザー辞書、索引前処理 kuromoji Lucene 系の⽇本語 Tokenizer Elasticsearch / OpenSearch / Solr の全⽂検索 Analyzer BM25 統計的キーワードランキング 完全⼀致‧固有名詞‧数値条件の初期検索 Embedding 意味ベクトル検索 ⾔い換え‧類似概念‧⾃然⽂質問の補完検索 ⽰唆 検索エンジンには kuromoji、前処理‧解析には Sudachi と GiNZA、ランキングには BM25 と Embedding を組み合わせる。 AIxDevOps © 2026 Scalar, inc. 52 / 74
54. Sudachi：分割粒度と辞書 ⽇本語 RAG では「どこで単語を切るか」が検索結果を⼤きく左右する。Sudachi は分割粒度を3段階から選べる。 Split Mode A Split Mode B Split Mode C 細かく分割する 中間的な分割 複合語を保持する 未知語や部分⼀致に強い 汎⽤検索のバランス型 固有名詞‧専⾨⽤語に強い ノイズも増えやすい 実務ではまず候補にしやすい 完全⼀致に寄りやすい 実装ポイント 注意点 ユーザー辞書に製品名‧顧客名‧業界⽤語を登録する Tokenizer 並列実⾏時はインスタンス共有に注意する 原形化‧表記正規化を検索前処理に組み込む 辞書更新時は索引の再作成‧差分更新を設計する AIxDevOps © 2026 Scalar, inc. 53 / 74
55. kuromoji：Analyzer 設計 Lucene 系検索では、 Analyzer 設計が BM25 の効き方を決める。 BM25 の前提は「良いトークンが索引化されていること」。 【Analyzer の基本】 char_filter：表記正規化 ／ tokenizer：kuromoji_tokenizer filter：baseform（原形化）／ part_of_speech（品詞フィルタ） filter：readingform（読み）／ stemmer など 【設計パターン】 本文：search mode で検索向け分割 ／ タイトル：固有名詞を重視 型番・ID：keyword / n-gram を併用 ／ 読み仮名検索： readingform を追加 【よくある失敗】 Analyzer 未調整で検索漏れ ／ ストップ品詞を落としすぎる ／ 同義語辞書だけに頼る ／ フィールドごとの特性を無視する AIxDevOps © 2026 Scalar, inc. 54 / 74
56. GiNZA：理解とメタデータ抽出 GiNZA は spaCy ベースで、形態素解析に加えて文構造・固有表現を扱える。 全文検索エンジンの Tokenizer というより、検索前処理・クエリ理解に向く。 • • • 文書や質問から固有表現を抽出する 係り受け・文節情報で、関係性のある語を近くに保つ 「誰が・何を・いつ・どこで」をメタデータ化する 【クエリ理解の例】 「A社向けの契約更新条件」 → 顧客名 = A社、文書種別 = 契約、観点 = 更新条件 【索引拡張の例】 固有表現・文書タイプ・日付・部署・製品名を metadata field として保存する 使いどころ： RAG の検索精度を上げる「検索補助情報」の生成 AIxDevOps © 2026 Scalar, inc. 55 / 74
57. BM25：⽇本語検索の基礎体⼒ BM25 はキーワード⼀致‧専⾨⽤語‧固有名詞‧数値条件に強い。結果の理由を説明しやすいのも実務上の利点。 BM25 が⾒るもの ⽇本語での強み ⽇本語での弱み TF：クエリ語がどれだけ出るか 製品名‧⼈名‧組織名に強い 表記ゆれに弱い IDF：珍しい語かどうか 型番‧コード‧正確な⽤語に強い ⾔い換えに弱い ⽂書⻑：⻑すぎる⽂書を補正 業務検索の初期候補に向く Analyzer が悪いと取りこぼす 結果の理由を説明しやすい スコアの調整がしやすい 意味的な近さは扱いにくい ⽰唆 BM25 単独ではなく、正規化‧同義語‧Embedding と組み合わせて補完する。「古い技術だから不要」ではなく、Dense の⽳を 塞ぐ役として残す。 AIxDevOps © 2026 Scalar, inc. 56 / 74
58. Embedding：意味検索で補完する ⾃然⽂の質問では、完全⼀致だけでは拾えない関連⽂書を探せる。ただし「意味の近さ」を返すだけで、「正しい根拠」を保証はしな い。 できること 注意点 実装ポイント 意味が近い⽂を検索する 数値‧⽇付‧固有名詞は過信しない チャンク単位で埋め込む ⾔い換えに強い チャンクが⼤きすぎると焦点がぼける タイトル‧⾒出しをチャンクに含める 質問⽂のまま検索しやすい ⽇本語の表記ゆれは正規化と併⽤ 表は Markdown / JSON 化して埋め込む FAQ‧議事録‧仕様書で有効 権限‧鮮度は別途制御が必要 BM25 候補と統合する ⽰唆 「タイトル‧⾒出しをチャンクに含める」は費⽤対効果が⾼い。チャンク単体では⽂脈が失われるが、⾒出しがあれば所属が分 かる。 AIxDevOps © 2026 Scalar, inc. 57 / 74
59. 推奨アーキテクチャ：Hybrid Search BM25 で正確性、Embedding で網羅性、Rerank で最終品質を上げる。最初から Embedding だけに寄せず、BM25 を残すことが⽇本 語業務検索では重要。 Query Normalize BM25 + Dense Fusion Rerank BM25 側の⼯夫 Embedding 側の⼯夫 統合側の⼯夫 kuromoji Analyzer ⽇本語対応モデル 候補の重複排除 フィールド別 Boost チャンク設計 RRF / Weighted sum 同義語‧読み仮名‧n-gram metadata filter Cross-encoder rerank Answer ⽰唆 例：「DL-AUDITOR-504002」「ISO 42001」のような語は BM25 / Entity 側で拾う。 AIxDevOps © 2026 Scalar, inc. 58 / 74
60. 正規化と形態素解析の使い分け 【正規化】 NFKC、改行統一、空白縮約、全角／半角、英数字、記号、日付表記を安定化する。 最重要：インデックス時と検索時で同一の契約（同じ正規化処理）にすること。 片方だけ正規化すると、正規化したぶんだけヒットしなくなる。 【形態素解析の使い分け】 BM25 / TF-IDF 用には形態素解析済みの語を使う。 Dense embedding には自然文をそのまま維持する。 Dense 用テキスト： 「ScalarDB は複数のデータベースにまたがる ACID トランザクションを提供します。」 BM25 / TF-IDF 用トークン： ScalarDB 複数 データベース またがる ACID トランザクション 提供 候補：Kuromoji / Sudachi / GiNZA / MeCab AIxDevOps © 2026 Scalar, inc. 59 / 74
61. チャンク分割：構造を残す 【避けるべき分割】 固定文字数だけで切ると、見出し・条件・例外・参照先が分断され、 LLM が誤答しやすくなる。「ただし〜の場合を除く」だけが別チャンクになる、 という切れ方が典型的な事故。 【推奨分割】 見出し → 段落 → 文境界 を優先する。文書種別ごとに単位を決める。 契約書：条・項 ／ FAQ：Q&A ／ 議事録：議題・決定事項 【メタデータは必須】 source / section / char_start / char_end / entities / top_keywords / ACL / timestamp char_start・char_end を持っておくと、回答から原文の該当箇所へ正確に戻れる。 ACL と timestamp を持っておくと、権限フィルタと鮮度フィルタが後から効かせられる。 AIxDevOps © 2026 Scalar, inc. 60 / 74
62. 固有名詞と表記ゆれを吸収する 会社名‧製品名‧略称‧型番‧法令名を落とすと、業務 RAG では致命的になる。同じ意味でも検索上は別物になりやすい。 ゆれの例 正規形（canonical） Scalar / スカラー / Scalar社 / 株式会社Scalar canonical: 株式会社Scalar aliases: [Scalar, スカラー, Scalar社] NER で抽出 近似表記を lint ⼈⼿で統合 同義語辞書化 検索時にクエリ拡張 ⽰唆 ⾃動抽出だけでは統合を誤る。「機械が候補を出し、⼈が確定する」運⽤にすると辞書の品質を保てる。 AIxDevOps © 2026 Scalar, inc. 61 / 74
63. Rerank と評価：検索品質を先に測る Rerank は「単語は⼀致しているが質問に答えていない」チャンクを落とす。評価は「回答が正しいか」より先に「正しい根拠を検索で きているか」を⾒る。 Chunk 品質 Recall@k Rerank 後 Top3 MRR 観点 ⾒るもの Chunk ⽂が途中で切れていないか Recall@10 正解チャンクを拾えているか MRR 正解が上位に出ているか Faithfulness 回答が根拠に忠実か ACL 権限外の⽂書が漏えいしていないか AIxDevOps © 2026 Scalar, inc. Faithfulness 引⽤正確性 62 / 74
64. AIxDevOps Embedding モデル選定 第7章 BGE-M3、multilingual E5、日本語特化モデル AIxDevOps © 2026 Scalar, inc. 63 / 74
65. 失敗は「検索ミス」として表⾯化する 同じ⽂書でも、Embedding の作り⽅で取れる根拠が変わる。選定ミスは検索ミスとして表⾯化する。 Query Embedding Vector DB Prompt よくある選定ミス ⽣成の前に検索を⾒る ⽇本語⽂書なのに多⾔語ベンチだけで選ぶ 正しい根拠が Top-k に⼊るか 短⽂ベンチで⻑⽂ PDF 検索を判断する 根拠が回答に正しく引⽤されるか 固有名詞検索を dense だけに任せる 再検索‧再埋め込み運⽤に耐えるか Answer ⽰唆 ⽣成モデルより先に「正しい根拠を取れるか」を評価する。根拠が⼊っていなければ、モデルを替えても答えは直らない。 AIxDevOps © 2026 Scalar, inc. 64 / 74
66. 選定基準：業務検索の条件で選ぶ ベンチマークのランキングではなく、対象⽂書‧検索クエリ‧権限‧運⽤コストで選ぶ。公開ベンチは候補選定、実データ評価が採⽤ 判断。 観点 確認すること ⾔語‧表記 ⽇本語、英語混在、カタカナ、略語、型番、社内⽤語 検索タイプ 意味検索、キーワード、固有名詞、類似事例、⻑⽂検索 ⼊⼒⻑ FAQ 短⽂、議事録、契約書、仕様書、PDF の表 運⽤制約 オンプレ / API、レイテンシ、GPU、ライセンス、再埋め込みコスト 評価⽅法 Recall@k、MRR、引⽤正確性、業務タスク成功率 ⽰唆 候補モデルを 2〜4 個に絞り、社内データで A/B 評価する。「再埋め込みコスト」は特に⾒落とされるが、モデル変更は索引の全 再⽣成を意味する。 AIxDevOps © 2026 Scalar, inc. 65 / 74
67. BGE-M3：多機能‧⻑⽂に強い Dense / Sparse / Multi-vector を1モデルで扱えるのが特徴。100以上の⾔語、8192 tokens、3 つの retrieval mode を持つ。 Dense Sparse Multi-vector 意味の近さで検索する 語彙の重みで検索する トークン単位の相互作⽤ 質問応答‧類似事例に強い 固有名詞‧型番に効く ⻑⽂‧細粒度マッチに強い ⽰唆 向いている使い⽅：⽇本語‧英語混在、⻑⽂ PDF、専⾨⽤語が多く、キーワード検索と意味検索の両⽅を重視する RAG。Sparse を持つため BM25 の代替にもなり得る。 出典: BGE-M3 paper / BGE documentation / Hugging Face model card AIxDevOps © 2026 Scalar, inc. 66 / 74
68. multilingual E5：安定した基準線 small / base / large のサイズ展開があり、効率と品質のバランスを取りやすい。まず作る RAG のベースラインとして使いやすい。 強み 使い⽅の注意 向いている⽤途 多⾔語検索の代表的 OSS モデル query / passage の⾮対称性 多⾔語 FAQ small / base / large のサイズ展開 prefix / input_type の扱い 英⽇混在ナレッジ GPU / CPU 制約に合わせやすい 実装差が品質に影響する まず作る RAG のベースライン ⽰唆 採⽤判断：シンプルな Dense 基盤で始めたい場合の有⼒候補。⽇本語特化モデルとの実データ⽐較は必須。 出典: multilingual E5 technical report / model card AIxDevOps © 2026 Scalar, inc. 67 / 74
69. ⽇本語特化モデルは常に勝つのか 【⽇本語特化モデル】 【評価基盤】 Ruri / Sarashina / AMBER / E5系⽇本語派⽣など JMTEB / JMTEB-lite / MTEB / MMTEB そのうえで社内 golden set で⾒る • • • 語順‧表記‧ドメイン適応で有利になり得る 社内⽂書がほぼ⽇本語なら第⼀候補 JMTEB と社内評価で確認する 【多⾔語モデル】 【注意】 「⽇本語モデルだから常に勝つ」 「多⾔語モデルだから⽇本語が弱い」 とは限らない。 BGE-M3 / multilingual E5 / Qwen 系など • 英⽇混在‧クロスリンガルで強いことが多い AIxDevOps タスク‧⽂書形式‧検索意図で逆転する。 だから横並び評価が必要になる。 © 2026 Scalar, inc. 68 / 74
70. ⽐較マトリクス：候補の⾒⽅ RAG ⽤途では「検索対象の性質」と「運⽤条件」を同時に⾒る。◎ / ◦ / △ は⼀般的な傾向であり、実際の優劣は対象データ ‧chunking‧rerank‧評価セットで変わる。 観点 BGE-M3 multilingual E5 ⽇本語特化 ⽇本語 ◦ ◦ ◎ 英⽇混在 ◎ ◎ △〜◦ 翻訳せず横断検索するか ⻑⽂ ◎ △〜◦ モデル次第 契約書‧仕様書‧PDF ⻑⽂ 固有名詞 ◎ ◦ ◦ BM25 / Sparse 併⽤が重要 実装容易性 ◦ ◎ ◦ ホスティング‧index 構成 運⽤コスト ◦ ◎ モデル次第 AIxDevOps © 2026 Scalar, inc. ⾒極めポイント JMTEB と社内⽂書で⽐較する 次元数‧推論速度‧GPU 要件 69 / 74
71. 3候補を同じ条件で評価する 最初から1つに決めず、実データで短く比較する。 標準候補：BGE-M3 日本語・英語混在、長文・固有名詞があるRAG。Hybrid / Sparse を活かせるなら最初に試す。 軽量候補：multilingual E5 シンプルな Dense 検索、コスト・実装容易性重視。多言語ベースラインとして比較する。 日本語最適化候補：Ruri / Sarashina / AMBER 等 社内文書がほぼ日本語の場合。JMTEB と社内評価で確認する。 【評価セットの作り方】 1. 実際の業務質問を 50〜200 件集める 2. 正解根拠の文書・ページ・節を付ける 3. 日本語の表記ゆれ・英数字・略語を含める 4. モデル × chunking × hybrid × rerank を比較する 【採用判断のルール】 Top-k に正解根拠が入る／引用が正しい／レイテンシとコストが許容範囲／再埋め込み運用が可能 AIxDevOps © 2026 Scalar, inc. 70 / 74
72. 前編の実装チェックリスト 【1. 前処理】 □ Unicode 正規化（NFKC）／全角・半角／大文字・小文字を統一した □ 索引時と検索時で同一の正規化契約になっている □ 表記ゆれ辞書と固有名詞辞書を用意した □ PDF・表を構造化して取り込んでいる（出典ページ・座標を保持） 【2. 検索】 □ kuromoji Analyzer をフィールドごとに設計した □ Sudachi の辞書と分割粒度を検証した □ BM25 と Embedding を併用している □ Rerank を導入した □ 権限・鮮度をメタデータフィルタで効かせている 【3. 評価・運用】 □ 日本語の質問セット（ 50〜200件）を作った □ Recall@k / MRR を測っている □ 誤検索を辞書へ反映する運用がある □ 索引更新と権限同期を監視している AIxDevOps © 2026 Scalar, inc. 71 / 74
73. 本番運⽤を⽀えるデータ基盤 第4章で⾒たとおり、権限漏れと古い情報は検索アルゴリズムでは解けない。⽂書‧メタデータ‧業務状態‧権限を⼀貫して扱うデー タ層が要る。 ⽂書DB‧業務DB‧Vector DB ScalarDB（異種DBを仮想 統合） Advanced RAG 根拠付き回答 整合性 権限 鮮度‧監査 ⽂書本体‧チャンク‧埋め込み‧メタ テナント‧プロジェクト‧部⾨などの権 更新‧索引‧監査ログをトランザクショ データ‧権限を⼀貫して更新できる 限属性を検索前フィルタに反映できる ンとして扱える ⽰唆 期待効果：古い情報や権限外の情報を、検索段階で混⼊させにくくする。⽣成側のガードで防ぐより確実で安価。 AIxDevOps © 2026 Scalar, inc. 72 / 74
74. 前編まとめと後編予告 【前編でおさえたこと】 ・企業知識の大半は LLM の外側にある。RAG はそこへ触るための仕組み ・RAG は5工程（Query / Retriever / Vector / Prompt / Answer）に分解して改善する ・情報量を増やすほど良い訳ではない。ハードネガティブが判断を狂わせる ・Naive RAG は「つながるか」の検証用。Advanced RAG は rewrite / hybrid / rerank ・権限漏れと古い情報は検索アルゴリズムでは解けない。データ設計の問題 ・日本語では前処理が最大の変数。形態素解析・表記ゆれ・PDF・表を先に潰す ・Embedding はベンチ順位ではなく、社内 golden set で横並び評価して選ぶ 【後編（第2回）で扱うこと】 ・検索を制御する — Self-RAG / CRAG ・構造で検索する — RAPTOR / GraphRAG、Multi-Hop RAG ・Agent から使う — RAG as Tool、Agentic RAG、MCP ・安全に運用する — セキュリティと評価 AIxDevOps © 2026 Scalar, inc. 73 / 74
75. Please give us a star on GitH ub! udy AIxDevOps St 毎週⽕曜開催 GitHub scalar-labs/scalardb connpass Scalar AIxDevOps © 2026 Scalar, inc.