blog シナモンブログ

【第7回】Super RAG API活用事例：「文書 vs 文書」の検索 — 作業計画書から過去の事故・ヒヤリハットを検索し、危険を予測する

【第7回】Super RAG API活用事例：「文書 vs 文書」の検索 — 作業計画書から過去の事故・ヒヤリハットを検索し、危険を予測する

はじめに

本記事のメッセージ：通常のRAGは「質問文を入力 → 関連文書を検索・参照して1問1答」というパターンで動きます。一方、現場の業務には「文書そのものを入力にして、関連する別の文書群を引き出したい」——たとえば、明日の作業計画書を入力にして、過去の類似作業で起こった事故・ヒヤリハット事例を引き出したい——というニーズがあります。これを実現するのが「文書 vs 文書」のカスタム検索パイプラインで、その土台は Super RAGの前処理エンジンと検索基盤（DocReader による構造保持、ハイブリッド検索、Dictionary 前処理） をAPIで組み合わせることで実現できます。本記事ではこのパターンを、製造業の安全管理を例に深掘りします。

たとえば、ある製造業の事業所で安全管理者を務める Mさんを思い浮かべてください。労働安全衛生法に基づき、製造業の指定業種で常時従業員50名以上の事業場には安全管理者の選任義務があり、Mさんはその役割を担っています。月例業務のひとつに「翌月の特殊作業に対する事前リスクアセスメント」があり、過去5年分の事故報告書とヒヤリハット事例の中から、似た作業条件の事例を洗い出して KYミーティングで共有する——この準備に毎回時間がかかっていました。ベテランの記憶頼り、ファイル名での部分検索、社内ファイルサーバーのフォルダと全文検索システムの巡回。「あの時の事例、似ていた気がするけど、どこに保存したっけ？」、「この事例、似ていると思ったけど実は手順が違うな。」が日常の風景です。

第6回までで、Super RAGが 抽出（DocReader）／ハイブリッド検索／回答戦略 という3本柱で精度を積み上げている話をしてきました。本記事ではこの3本柱が、Mさんのような現場の業務にどう効くか——特に、通常のチャット形式では収まりきらない「文書 vs 文書」の検索シーンに焦点を当ててご紹介します。

本連載について

本記事は第7回です。連載は、(I)なぜSuper RAG、(II)どう組み込むか、(III)中身を可視化、(IV)現場で何が起きているか、(V)導入判断、という5章構成で進めています。第III章（第4〜6回）で抽出・検索・回答戦略の3本柱の地図が出揃ったので、今回からは第IV章「現場で何が起きているか」に入り、業務シーンでこの地図がどう機能するかを順次ご紹介します。

第7回は、第2回でご紹介した3つの組み込みパターンのうちパターン②（検索特化）の現場事例にあたります。Super RAGを「前処理エンジンと検索基盤の部品」として活用し、その上に業務固有のクエリ分解と結果統合のロジックを自社開発側で組み立てるアーキテクチャです。本記事の事例は、第三者がインターネット上で公開されている事故概要報告書を実証実験用データとし、製造現場向けの「作業計画書から事故・ヒヤリハット事例を引き出す」検索パイプラインを試験実装した上で解説しています。

業務シーン — 製造業の安全管理と KY活動

製造業の事業所では、KY活動（危険予知活動）やTBM（ツールボックス・ミーティング）といった、作業前のリスクアセスメントが日常的に行われています。明日や今日の作業に潜む危険を事前に洗い出し、対策を共有してから作業に入る——というサイクルです。

KY活動の業務フロー（Before）

このサイクルの根幹に据えられているのが、過去の事故報告書とヒヤリハット事例の参照です。

  • ハインリッヒの法則を引くまでもなく、現場で起きる「ヒヤリ」とした出来事は、重大事故の前兆として大量に蓄積されています
  • 過去の類似作業で、どんな事故やヒヤリハットが起きたか、何が原因だったか、どんな対策を取るべきか——これらが組織の中に「経験」として記録されています
  • KYミーティングでは、この経験を引き出して「今日の作業で気をつけるべきポイント」を皆で確認することが目的です

しかし、現場の実態はどうでしょうか。過去の事故報告書もヒヤリハット報告も、確かに記録としては残っているのです。多くの場合、社内ファイルサーバーに非構造なデータのままで蓄積されています。問題は、それを必要なときに引き出すのが難しいことです。

  • ファイル名で検索しても、ファイル名は「20230815_事故報告_製造2課.docx」のような事務的な命名で、中身を表していない
  • フォルダで分類しても、「製造2課フォルダ」「メンテナンス事例フォルダ」のような部署軸・形式軸に整理されていて、「同じ作業条件の事例」では引けない
  • 結局、ベテランの「あの時のあの事例、似てたよね」という記憶に頼ることになり、組織知化されない

化学プラントなど熟練作業の現場では、「この音やにおいは異常の兆候」、「この場面では必ず絶縁手袋を確認する」といった暗黙知（カンコツ）が、ベテランの頭の中だけに蓄積されている、という構造的な課題が指摘されてきました。Mさんが時間をかけて事例を洗い出すのは、結局はこの暗黙知を一人で組織知に変換し直す作業だったわけです。

なぜ通常のRAGでは足りないか — 「質問に答える」と「文書から文書を探す」の違い

ここで、第1〜6回でご紹介してきた「通常のRAG」の使い方を思い出してください。利用者が自然文の質問を入力すると、AIが関連文書から該当箇所を引き出して、1問1答の形で回答を返す——これがチャット形式の RAG の基本パターンです。

「質問に答える」RAG vs 「文書 vs 文書」のパイプライン

Mさんの業務に当てはめると、こうなります。

  • 「製品Aの容器交換作業で、過去に発生した事故は？」と聞けば、関連する事故事例が引ける
  • 「深夜帯の高所作業のヒヤリハット事例を教えて」と聞けば、それらしい事例が引ける

これは確かに便利です。ただし、業務の本当のニーズは「明日の作業全体に対して、観点を漏らさず関連事例を洗い出す」ことなのです。明日の作業計画書には、複数の工程・複数の対象設備・複数の作業条件・複数の危険観点が詰まっています。これらを1問1答で順に聞いていくと、

  • 「工程Xに関する事例は？」
  • 「工程Yに関する事例は？」
  • 「設備Aの取扱事例は？」
  • 「夜間作業の事例は？」
  • 「○○な状況での事例は？」

——と、何回もの質問を繰り返す必要があります。漏れも出ますし、観点の組み合わせ（工程X × 夜間 × 設備A）まで考えると、組み合わせ爆発します。また、質問ごとに異なる報告書から継ぎはぎで回答が生成され、実は一貫性のある対策になっていない可能性もあります。

ここで、発想を転換します。質問文を組み立てるのではなく、明日の作業計画書（文書）そのものを検索の入口にするのです。作業計画書には、工程・対象・条件・想定される危険要素がすでに記載されています。これらを機械的に分解して、観点ごとに過去事例を引き、まとめて返してくれる——これが「文書 vs 文書」のカスタム検索です。

通常のRAGとの違いを整理すると、こうなります。

観点通常のRAG（質問→回答）文書 vs 文書 のパイプライン
入力自然文の質問業務文書（作業計画書など）
入力の解釈質問1つを意味で検索文書を複数観点に分解
検索1回の検索観点ごとに多段検索
出力1つの回答観点別の関連文書群
適する業務個別の問い合わせリスクアセスメント・事前準備

「質問が文書である」という違いが、検索の組み立て方を根本から変えます。入力文書を読み解き、観点に分解し、観点ごとに検索を組み立てて、結果を統合する——この一連の処理が、「文書 vs 文書」の検索パイプラインの中身です。

検索アーキテクチャ — 「文書 vs 文書」のカスタムパイプライン

Mさんの業務に当てはめた、典型的なパイプラインを描きます。

「文書 vs 文書」パイプラインの全体像

ステップ1：作業計画書を入力 利用者は、明日の作業計画書（Word／Excel／PDF など）をシステムに渡します。たとえば「11月15日 深夜帯、製造ラインAA、製品Bの容器交換作業、作業者3名、使用工具：チェーンブロック、特記：足場が湿気あり」のような業務文書です。

ステップ2：前処理（Super RAG API） 入力された作業計画書を、Super RAGが前処理します。具体的には、

  • POST /api/v3.3/actions/document-extract/ で、構造を保ったテキスト化（DocReader）
  • POST /api/v3.3/actions/chunking/ で、意味のある単位への分割

この時点で、作業計画書は「工程の表」「条件の記述」「特記事項」などのまとまりとして、機械が扱える単位に整理されます。

ステップ3：クエリセット生成（APIフロントエンドで組み立てる工程） ここが「文書 vs 文書」パイプラインのAPIフロントエンド側の責務です。前処理された作業計画書から、観点ごとに検索クエリを組み立てます。安全管理であれば、典型的な観点は以下のようになります。

  • 工程観点：「容器交換作業」「チェーンブロック使用作業」
  • 対象観点：「製造ラインAA」「製品Bの取扱」
  • 条件観点：「深夜帯作業」「足場湿潤環境」「3名体制」
  • 危険観点：「落下リスク」「熱・薬液暴露リスク」「視認性低下リスク」

これらが、それぞれ独立した検索クエリのセットになります。観点軸は業務によって決まるので、ここはプロンプトで設定します。

ステップ4：多段検索（Super RAGの検索を呼び出す） 組み立てた観点ごとのクエリを、Super RAGの検索エンドポイント（POST /api/v3/workflows/retrieve/）に投げます。検索対象は、過去の事故報告書とヒヤリハット事例が登録されたフォルダです。観点ごとに、関連度順で文書の断片リストが返ってきます。

ここで第5回でご紹介したハイブリッド検索（意味と語の両軸）が効きます。「足場が湿潤」のような状況描写（意味寄り）と「製造ラインAA」のような固有名（語寄り）の両方が混じる検索でも、両軸が同時に走ることで取りこぼしが減ります。

ステップ5：結果の統合（APIフロントエンドで組み立てる工程） 観点ごとに返ってきた事例を、重複排除・スコア統合・関連度の再評価などで統合し、最終的な参考事例ファイルリストとして利用者に提示します。同じ事例が複数の観点でヒットしていれば、それは特に重要な事例として上位に据える、といった重み付けもここで行えます。

ステップ6：根拠付きで提示 最終結果は、事例タイトル・関連した観点・元文書の引用箇所・出典を伴って提示されます。Mさんは KYミーティングで、「この事例は工程観点と条件観点の両方でヒットしました。元の事故報告書はこちらです」のような根拠付きで共有できます。

このパイプラインのSuper RAGが担う部分は、ステップ2の前処理とステップ4の検索です。APIフロントエンドが担う部分は、ステップ1のデータ投入、ステップ3のクエリ分解、ステップ5の統合、ステップ6の結果表示です。Super RAGを「部品」として組み込み、業務固有の検索フローを自社で組み立てる——これがパターン②（検索特化）の構造です。

📺 デモ動画：ここまでで説明したパイプラインが実際にどう動くかを、動画でご覧いただけます。Super RAGのAPIを使って構築したデモアプリケーション上で、作業計画書をアップロードしてから関連事例が提示されるまでの一連の流れ、およびLLMリランクを使った精度測定（Hit@1で 84.6%）まで通してご確認いただけます。

動画では、関連性の定義・検索設定・精度測定・実際の検索実行という4つの画面を順にご覧いただけます。APIフロントエンドを弊社で試験的に実装したものです。記事本文では概念を中心に説明していますが、動画では具体的な数値（最大8チャンクで検索を回す、リランク前69.2%→リランク後84.6%への精度向上など）も合わせてご紹介します。

なぜ「文書 vs 文書」検索は Super RAGの前処理を必要とするか

ここで、本記事の核となる差別化要素をお伝えします。「文書 vs 文書」のカスタム検索は、入力側の文書も検索対象側の文書も、両方が業務文書である点に大きな特徴があります。そして、両方とも「日本語＋複雑レイアウト＋表＋図」が混在する、前処理が難しい素材です。

文書 vs 文書 検索が Super RAGの前処理に依存する理由

入力側（作業計画書）の中身

作業計画書は、見た目はシンプルでも中身は意外と多層的です。

  • 工程表：作業のステップを順番に並べた表（手順1、手順2、…）。セル結合で「使用工具」が複数手順にまたがって記載されることもある
  • 作業条件の表：日時・場所・担当者・特記事項などが、表形式で書かれる
  • 設備図・作業範囲図：作業対象の設備の図面や、作業範囲を示した平面図が貼り付けられている
  • 本文：注意事項・特記・参考情報などが文章で書かれる

これらを「意味のある単位で読み取れない」と、ステップ3の観点分解ができません。表のセル結合が崩れて「使用工具」と「手順」の対応が壊れたり、図のキャプション（「図1：作業範囲」のような）が本文から切り離されたり、不適切な位置でチャンキングされると、観点軸に沿って抽出できなくなります。

検索対象側（事故報告書・ヒヤリハット）の中身

検索対象側も、同じくらい複雑です。

  • 事故報告書のセクション構造：「事故概要」「発生状況」「直接原因」「根本原因」「是正措置」「再発防止策」など、章立てが決まっていることが多い
  • 現場写真・図解：事故現場の写真、損傷状況の図解、作業手順のフロー図が含まれる
  • 損傷状況の表：損傷部位・程度・修理コストなどを表形式で整理
  • 手書き要素：現場で記入されたヒヤリハット報告書がスキャンされた手書き文書

これらが構造を保ったまま検索対象になっていることが、「同じ作業条件で発生した類似事例」を引き当てる前提です。たとえば「事故概要が容器交換作業で、根本原因が足場の湿潤」というような複合条件で引きたいとき、セクション構造が壊れていたら、文章を全部混ぜて検索することになり、ノイズに埋もれます。

第4〜6回の3本柱が、両側の文書品質を支える

ここで、第4〜6回でご紹介してきた Super RAGの3本柱が、両側の文書品質を支える土台として効いてきます。

  • 第4回（DocReader による構造保持）：表のセル結合、図のキャプション、章立て——これらが崩れずに残っているから、入力側の作業計画書も検索対象側の事故報告書も、両方が同じ粒度で対応付けできる
  • 第5回（ハイブリッド検索）：「足場が湿潤」（意味寄り）と「製造ラインAA」（語寄り）の両方が混じる検索クエリにも、Super RAGなら一度の呼び出しで両軸対応
  • 第6回（Dictionary 前処理）：「ラインAA」「TBM」「KYT」「PRTR物質」のような社内独自用語・業界用語が、用語集で標準化されてから検索に流れる

つまり、「文書 vs 文書」のカスタム検索は、自社開発側がクエリ分解と統合を組むだけでは成立しません。両側の文書が高品質に前処理されていることが前提条件で、その前処理層を Super RAGが提供している、という関係です。

個別 LLM 開発との差別化

率直に言えば、OpenAI GPT API + 自社のベクター DB を組み合わせれば、検索パイプラインの形だけは作れます。LangChain のようなフレームワークを使えば、観点分解・多段検索・統合の処理も書けます。実装パターン自体は、いま誰でも書ける時代です。

しかし、現場で動く検索パイプラインを作ろうとすると、前処理層の実装で躓きます。

  • 表のセル結合を保ったまま読み取る処理は、汎用 OCR や PyMuPDF では難しい
  • スキャン PDF の手書きヒヤリハット報告を、テキスト化、チャンク化する処理は、自前で組むと大変
  • 図のキャプションを本文と紐付けたまま保つには、レイアウト解析の精度が必要
  • 「日本語＋複雑レイアウト＋表＋図＋手書き」の業務文書を扱う前処理エンジンを、業務に耐える品質で自前構築し、その後も保守し続けるのは、専門チームと継続投資が必要

Super RAGはこの前処理層と検索基盤を提供することで、お客様が「文書 vs 文書」検索の上位層（クエリ分解・観点設計・統合）に集中できるようにする——これが個別 LLM 開発との明確な差別化です。

また、Super RAGはOpenAPI形式（JSONファイル）で仕様書を公開しており、近年普及しているコーディングエージェント（AIによる開発支援）に読み込ませれば、人間がAPIの細部まで理解しなくても、業務固有のカスタムパイプラインを短期間で構築できる——という現代的な開発スタイルに適しています。本記事のデモアプリケーションも、StreamlitとSuper RAGのAPIを組み合わせて、わずか3日程度で構築されたものです。「Super RAGを部品として活用し、業務固有性は自社で組み立てる」というパターン②の思想は、こうした迅速な開発と相性が良い構造になっています。

このアーキテクチャは何を意味するか — 第2回・第6回の設計判断との整合

ここで、シリーズの伏線を回収します。

パターン②（検索特化）の本格活用

第2回で「3つの組み込みパターン」をご紹介したとき、パターン②は「前処理と検索は Super RAG、上位のオーケストレーションは自社」と紹介しました。本事例はまさにそのパターン②の本格活用で、さらに業務固有のクエリ分解と統合ロジックを自社が制御することで、「文書 vs 文書」検索を実現しています。

第2回でパターン②の代表例として Dify 連携の経費審査を図説しましたが、同じパターン②でも、上位のオーケストレーションの組み立て方には複数の選択肢があります。Dify のような汎用ワークフロー基盤を使う形と、本事例のように自社コードで業務固有の検索ロジックを組み立てる形の両方が、パターン②に含まれます。業務固有性が高いケースでは、後者のほうが業務への最適化がしやすくなります。

第6回の分業設計と整合

第6回で「Multi-hop の推論オーケストレーションはエージェント基盤との分業」と打ち出した思想が、本事例では「カスタム検索のオーケストレーション」として現れています。Super RAGは知識ソースの理解と検索品質を提供し、業務固有のクエリ分解と統合は自社開発側が組み立てる——という役割分担です。

第6回では「Multi-hopニーズには Dify などのエージェント基盤」を例として挙げました。デモでは汎用的にパイプラインを組みましたが、本来は業務固有性を注入して最適化したい領域です。「観点軸の設計」「クエリ分解の論理」「統合の重み付け」が業務によって独自で、プロンプトを調整するだけでなく、コードレベルで最適化すると精度はさらに上がります。この場合、コーディングエージェントで検索ロジックを組む方式が向いています。同じパターン②の中でも、より安定的かつ可視性の高いDify を使うか、可視性は落ちるものの、コーディングエージェントの効率性と自由度を優先して独自ロジックで組むかは、業務固有性の高さで選び分けるとよいでしょう。

なお、自社に開発体制が無い場合や、検索パイプライン設計に専門知識が必要な場合は、シナモンAIのパートナーと共同で設計・実装する選択肢があります。詳しくは後続の記事でご紹介する予定ですが、ご興味がございましたら、ページ末尾のお問い合わせフォームよりお気軽にご相談ください。

横展開・軸A — 製造業内での他の「文書 vs 文書」シーン

「文書 vs 文書」のパイプラインは、KY活動だけのものではありません。製造業の中だけを見ても、同じパターンで設計できる業務が多数あります。

製造業内の「文書 vs 文書」活用案

設計レビュー

新製品や新設備の設計レビューでは、設計図・仕様書・FMEA（故障モード影響解析）レポートを入力にして、過去の類似設計で発生したトラブル事例・設計変更履歴・部品リコール情報を引き出したい、というニーズがあります。観点軸は「機能・部品・条件・故障モード」など。設計レビュー会議の準備で、設計者やレビューアが過去事例を漏れなく確認するのに使えます。

保全業務

日常点検から得られる、設備の故障兆候（例えば異常な振動音など）を入力にして、過去の類似故障事例・修理手順書・代替部品情報を引き出したい、というニーズがあります。観点軸は「設備種別・症状・運転条件・経年」など。突発故障時の初動対応や、定期保全計画の事前検討で使われます。

特許調査

新規開発中の構成案・技術仕様書を入力にして、過去の類似特許・技術論文・社内技報を引き出したい、というニーズがあります。観点軸は「技術分野・構成要素・効果・適用領域」など。発明発掘や、出願前の先行技術調査で使われます。特許の図面（フロー図、構造図）が読み取れる前処理が、ここでも効きます。

品質管理

不良品の検査レポート・現品写真・不良サンプルの分析データなどを入力にして、過去の類似不良事例・原因分析報告・対策実績を引き出したい、というニーズがあります。観点軸は「製品種別・症状・発生工程・原因系統」など。品質クレーム対応や、製造ラインの改善活動で使われます。

「観点軸が明確になっている業務」ほど、パイプラインの効果が出やすい

これらの製造業内シーンに共通するのは、観点軸が業務として明確になっていることです。設計レビューなら「機能・部品・故障モード」、保全業務なら「設備種別・症状・運転条件」、品質管理なら「製品種別・症状・発生工程」——というように、ベテランが頭の中で使っている分解の軸が、業務ノウハウとして言語化できる業務ほど、「文書 vs 文書」のパイプラインを組みやすい、という関係があります。

逆に言うと、「文書 vs 文書」のパイプライン設計の最初のステップは、業務担当者にヒアリングして観点軸を引き出すことです。技術的な話より先に、業務理解が出発点になります。

横展開・軸B — 業種を超えるトラブル検索パターン

「文書 vs 文書」のパターンは、製造業を超えて業種横断的な「トラブル検索」のパターンとしても見ることができます。

業種横断のトラブル検索パターン

簡単に俯瞰しておきます。

  • IT運用：障害アラートのログ → 過去の類似障害と対応手順、事後評価
  • 法務：契約レビュー対象の文書 → 過去の類似契約・修正履歴・関連法令
  • サポート業務（コールセンター等）：クレーム内容 → 過去の類似クレームと対応記録・成功事例
  • 医療：今日のインシデント報告 → 過去の類似事例と原因分析・予防策

いずれも、「ある業務文書をきっかけに、関連する別の文書群を引き出したい」というパターンです。業種が違っても、業務の核に「過去の経験を組織知として引き出す」というニーズがある限り、同じ「文書 vs 文書」のパイプラインで設計できます。

ここで重要なのは、業種ごとに観点軸が変わることです。IT運用なら「障害種別・影響範囲・関連サービス」、法務なら「契約類型・条項・リスクレベル」、コールセンターなら「商品・問い合わせ種別・顧客属性」——というように、業務理解が出発点になる構図は、軸A の製造業内シーンと共通です。

ストーリーの続き — Super RAGを入れた後の Mさんの業務

冒頭で登場した Mさんの業務に戻ります。Super RAGをパターン②の構成で導入したあと、Mさんの月例業務はどう変わるでしょうか。

これまで時間を掛けていた事前リスクアセスメントの準備が、大幅に短縮されます。明日の作業計画書を入力すると、観点別に整理された関連事例リストが、根拠付きで返ってきます。Mさんはそれを目で確認して、KYミーティング向けの資料に整える——これが今の流れです。

KYミーティングの中身も変わりました。「ベテランの記憶頼り」だった部分が、「過去の事例を組織として参照する」に変わったことで、新人作業者も含めて全員が同じ前提で議論できます。「この事例、似たようなのが3年前にもあったんだね」「そのときの対策はこう書いてある」というやり取りが、根拠を伴って進みます。ベテランのアドバイスの根拠となる事例も見つかるでしょう。

そして、Mさん自身の業務時間も再配分できました。事例検索に費やしていた半日を、業務改善の検討、新人教育、現場巡視といった、より付加価値の高い活動に振り向けられます。これは、AIが人を代替するのではなく、人がより本質的な仕事に集中できるようにする、という現代の AI 活用のひとつのかたちです。

なお、ミーティングの場で「この事例の対策は、結局どう改善されたの？」、「どの個所を根拠に関連性が高いと判断したの？」と Mさんが Super RAGに対話形式で追加質問する場面もあります。ここで重要なのは、先に類似事例を絞り込んで「文書を固定」してから、その固定された文書に対して繰り返し質問できるという点です。通常のRAGでは質問を変えるたびに参照される文書も入れ替わってしまい、一貫した分析が難しくなりますが、本パイプラインでは一度絞り込んだ事例セットを軸に、原因・予防策・対策の有効性などを多角的に掘り下げることができます。これは第6回でご紹介した「Single-hop の繰り返しでカバーできるシンプルな多段推論」を、文書固定モードで活用している姿です。事前リスクアセスメントと、文書固定での追加質問が、現場でうまく組み合わさっている実態がここにあります。

【持ち帰り検討材料】自業務の「文書 vs 文書」シーン棚卸しフロー

ここまでお読みいただいて、「うちの業務にも、似たような『文書から文書を探す』シーンはないだろうか」と思われたかもしれません。この見当をつけるための簡易シートをご用意しました。

自業務の「文書 vs 文書」シーン棚卸しシート

5つの観点で、それぞれ「やること／成果物／Tips」を押さえていきます。

観点1：「文書 → 文書」シーンを洗い出す

自業務のなかで、「ある文書をきっかけに、関連する別の文書を探す」シーンを 3〜5件ほど洗い出します。本記事でご紹介した KY活動・設計レビュー・品質管理・保全業務のような、何かの文書の複数個所を参照しながら別文書を探す・突き合わせる業務シーンが目印です。Tips：「そのシーンで、ベテランが頭の中でやっていること」を観察すると、シーンが浮かび上がりやすくなります。

観点2：参照ドキュメントの所在と形式

各シーンで参照したい過去文書（事故報告書、過去案件、設計レビュー記録、クレーム対応記録など）が、どこに、どんな形式で保存されているかを確認します。Tips：Excel・Word・PDF・スキャン PDF・手書き、それぞれが何割ずつあるかを把握しておくと、Super RAGの前処理が特に効く領域（複雑レイアウト、スキャン、手書き）が見えてきます。

観点3：観点軸の洗い出し

各シーンで「業務担当者が頭の中で使っている突合せの軸」を、業務ヒアリングで引き出します。

  • KY活動 → 工程・対象・条件・危険観点
  • 設計レビュー → 機能・部品・条件・故障モード
  • 品質管理 → 製品・症状・発生工程・原因系統
  • 保全業務 → 設備種別・症状・運転条件・経年

観点軸が明確になっている業務ほど、「文書 vs 文書」パイプラインの効果が出やすい——これが本記事の重要なメッセージのひとつです。Tips：観点軸は完璧でなくて構いません。3〜4軸あれば、まず動きます。

観点4：API利用パターンの確認

第2回でご紹介した3つの組み込みパターンのうち、どれパターンで実装するか見立てます。

  • パターン①（Super RAG 中心）：標準UIで対話形式の問い合わせができれば足りる場合
  • パターン②（検索特化）：Super RAGの前処理と検索の上に、業務固有のオーケストレーションを Dify などのワークフロー基盤、または自社コードで組み立てたい場合（本記事の事例はここ）
  • パターン③（前処理特化）：前処理のみ Super RAG を使い、ベクター DB から検索基盤・推論まで自社で完結したい場合

Tips：「文書 vs 文書」シーンは基本的にパターン②の領域です。Dify のような汎用ワークフロー基盤と、本記事のような自社コードでの組み立て、どちらの選択肢もパターン②の中にあります。ただし、自社の基盤（ベクターDB格納・検索・推論）を利用する場合は、パターン③でも実現可能です。業務固有性の高さによって②か③を選び分けるとよいでしょう。

観点5：トライアルでの検証相談

棚卸しが終わったら、実データで実際に Super RAGのAPIを使って業務に合った文書検索が可能か確認するのが確実です。スコープ・期間・対象ファイル数といった具体パラメータは、業務要件によって最適な形が変わります。コーディングエージェントで自社実装して頂くことも可能ですが、難しい場合は弊社で無償・有償PoCとしてお手伝いさせて頂く選択肢もございます。記事末尾のお問い合わせフォームからお気軽にご相談ください。Tips：観点1〜4の結果を整理してお伝えいただくと、初回トライアルで何を試すかの設計が一気にスムーズになります。

次回予告

次回（第8回）は、ユースケース事例② サポート・FAQ／用語集運用をお届けします。本記事までで「文書 vs 文書」のカスタム検索という、業務固有の検索パイプラインの世界をご紹介しました。次回は視点を変えて、サポート業務の問い合わせ対応に使える、FAQ・用語集の整備運用——日常的に発生する大量の問い合わせ用の資料をSuper RAGでどう整えるか——を取り上げます。

特に、既存の文書群から FAQ データを半自動生成する仕組みや、社内用語集を整備して Dictionary 前処理の効果を引き出す運用は、第6回でご紹介した Dictionary 前処理の現場版として、本記事と対になる内容です。

まとめ

通常のRAGは「自然文の質問に対して、関連文書から1問1答する」パターンを主体としています。一方、現場の業務には「ある業務文書を入力にして、関連する別の文書群を引き出したい」——明日の作業計画書から過去の事故・ヒヤリハットを引き出す、設計図から過去のトラブル事例を引き出す、不良品の検査レポートから過去の類似不良を引き出す——という「文書 vs 文書」のニーズが多数あります。

これを実現するのが、本記事でご紹介した「文書 vs 文書のカスタム検索パイプライン」でした。第2回でご紹介したパターン②（検索特化）の本格活用にあたり、Super RAGは前処理と検索基盤を担い、業務固有のクエリ分解と統合は自社開発側で組み立てます。

このパイプラインが成立する前提は、入力側の業務文書も、検索対象側の事故報告書・過去事例も、両方が「日本語＋複雑レイアウト＋表＋図」の構造を保ったまま読み取れていることです。第4回の DocReader による構造保持、第5回のハイブリッド検索、第6回の Dictionary 前処理——Super RAGの3本柱が、ここで一体となって効いてきます。

製造業のなかでは、KY活動・設計レビュー・保全業務・特許調査・品質管理など、観点軸が明確な業務に幅広く応用できる可能性があります。さらに業種を超えて、IT運用・法務・コールセンター・医療などでも、「文書から文書を探す」業務全般に同じパイプラインが応用できます。 「うちの業務にも、似た『文書 vs 文書』のシーンがあるかも」と思われた方は、本記事の持ち帰り検討材料の5観点棚卸しをご検討ください。そのうえで実データでの検証をご希望でしたら、記事末尾のお問い合わせフォームからお気軽にご相談ください。無償・有償のトライアルで、お客様の実データで Super RAGの前処理品質と検索精度を確認いただけます。

＜このシリーズの記事＞

お問い合わせ
Super RAG資料ダウンロード
ブログ一覧に戻る