株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
社内ドキュメント検索AIエージェントとは、仕様書・マニュアル・社内Wikiなど散在するドキュメントに対して自然言語で質問し、AIが関連情報を検索・要約して回答するシステムである。2026年現在、従来の「1回検索して1回生成する」RAGから、AIエージェントが検索結果を評価して再検索を繰り返す「Agentic RAG」へと進化している。本記事では、社内検索AIに必要な要件を整理しながら、本番品質の社内ドキュメント検索AIを構築するための設計パターンを解説する。
社内ドキュメント検索AIが本番運用で直面する5つの課題
| 課題 | 内容 |
|---|---|
| 1. ファイルパス解決 | DBに相対パス、実ファイルは環境ごとに異なる場所 |
| 2. 環境差異 | ローカル/Azure/AWSで異なるストレージ形態 |
| 3. 大規模ドキュメント | 文書と指示・履歴等を合わせた入力が、利用モデルのトークン上限を超えることがある |
| 4. マルチフォーマット | PDF/Word(.doc/.docx)/Excel/画像混在 |
| 5. 精度と速度のトレードオフ | Agentic RAGは追加検索で回答を改善できる場合があるが、呼び出し回数・待ち時間・費用が増える場合もある |
本番品質に必要な6レイヤー
レイヤー1: Agentic RAGの設計
単純なRAGは「クエリ→ベクトル検索→コンテキストに追加→LLM回答」の1パス構成で説明できる。Agentic RAGはエージェントが検索の要否や方法を判断する方式であり、検索結果の評価と再検索を含める実装例では以下のループを回す。
- ユーザーの質問を受け取る
- 検索クエリを生成(LLM)
- ドキュメントを検索(ベクトル検索 or メタデータ検索)
- 検索結果を評価(LLM) → 不十分なら再検索
- 十分な情報が集まったら回答生成
Agentic RAGのメリット
- 曖昧な質問に対し検索クエリを生成・書き換えできる。改善するかは対象質問で評価する
- 1回の検索で情報が不足しても追加検索する
- 複数のデータソース(ベクトルDB/メタデータDB/外部API)を組み合わせられる
- 検索結果の品質評価ができる
レイヤー2: ファイルパス解決の設計
本番運用で最も厄介なのは「DBに保存されているファイルパスと、実ファイルの置き場所が異なる」問題である。これを解決するパス解決層パターンを実装する。
パス解決クラスの設計
設計例として、文書の相対パスと環境ごとの保存先を分け、ファイル取得を共通の窓口へ集約する。ローカルやマウント済み共有のパス結合にはPythonのpathlibが使える。Blobはファイルシステムのパスとは異なるため、対応するAPIで取得する処理を分ける。
環境変数による切替
保存先の種類と基準ディレクトリ等を起動時の設定として読み込み、対応する取得処理を選ぶ。Pythonのos.getenvは環境変数を読む関数であり、ストレージの切替自体はアプリケーション側で実装する。変数名はアプリごとに定義する。
このように保存先ごとの取得処理を実装し、両環境で検証すれば、アプリケーションの呼び出し側を共通化できる。DB内には環境に依存しない相対パスや文書識別子を保持し、実際の保存先との対応を管理する。
レイヤー3: Azure Files / Azure Blob Storageの選択
Azure環境で文書を保存する候補には、共有ファイル向けのAzure FilesとオブジェクトストレージのAzure Blob Storageがある。それぞれ特性が異なり、以下ではマウントとAPIアクセスを比較する。
Azure Files(SMB/NFSマウント)
- App Serviceにファイル共有としてマウント可能。SMBとNFSの対応条件は実行環境で異なり、NFSはApp Service on Linuxのみ。NFSには同一仮想ネットワークやPremiumのFile storageアカウント等の条件がある
- マウント先を指定すれば既存のファイル操作を活用できる。ただし権限・ロック・ネットワーク遅延等の違いを検証する
- 設定: Azure Portal → App Service → 構成 → パスマッピング → 新しいAzure Storageマウント
- 性能上の注意: 実効速度はストレージの階層、IOPS・帯域、配置リージョン、アクセス方法に依存する。大容量ファイルが常にBlobより遅いとは限らない
Azure Blob Storage(API経由)
- 大量の非構造化データを扱うオブジェクトストレージ。速度や費用が常にFilesより有利とは限らず、容量・操作回数・転送量・アクセス層等を含めて比較する
- 接続文字列とコンテナー名で管理
- API経由で使う本構成では、アプリケーションコードからBlob APIやSDKを呼び出す。App Service on Linuxには読み取り専用のBlobマウントという別の利用方法もある
- 大容量・大量ファイル向け
選択基準
件数やサイズだけで選択を固定せず、共有ファイルとしてのアクセスが必要か、APIでオブジェクトを取得する構成が適するかを先に検討する。代表的なファイル・同時アクセス数で速度を計測し、容量・操作・転送を含む費用も比較する。複数の保存先に対応する場合は、取得処理の違いを共通の窓口にまとめる設計を検討する。
レイヤー4: マルチフォーマット対応
社内ドキュメントは多様なフォーマットで存在する。それぞれに対応するパーサーが必要。
| フォーマット | ライブラリ・サービス候補 | 備考 |
|---|---|---|
| PyMuPDF (pymupdf) | テキスト・表・画像を扱えるが、読み順や表構造の抽出結果は文書ごとに確認 | |
| Word (.docx) | python-docx | 標準的な.docx |
| Word (.doc) | antiword | 古い.doc用。Pythonパッケージとは別に、実行環境に合う方法で導入 |
| Excel (.xlsx) | openpyxl / pandas | セル単位の抽出 |
| 画像(OCR必要) | AzureのRead OCR / Geminiの文書理解 | 図面・スキャンPDF。文字認識と図表の解釈は分けて評価 |
| PowerPoint | python-pptx | スライド単位の抽出 |
`.doc`対応の罠
古い`.doc`ファイル(Word 97-2003)は、`.docx`向けの`python-docx`では読めない。`antiword`などの別ツールや形式変換を組み合わせる。Debianのantiwordパッケージを使う場合は`apt-get install antiword`が導入方法の例となる。macOSでは対応する配布元の導入手順を確認する。Dockerで使う場合も、選んだツールをDockerfileへ記載して実行イメージに含める。
レイヤー5: トークン制限とマルチエージェント分割
LLMの制限は一律80,000文字ではなく、利用モデルとトークン数で決まる。文書以外の指示・会話履歴・ツール定義と、出力用の余裕も考慮する。例えばClaudeは入力のトークン数を事前に見積もる機能を提供する。上限を超える場合は文書をチャンクへ分けて必要部分を取得し、処理を複数エージェントへ分担させる方法もある。分担する場合も、各呼び出しの入力を上限内に収める。
マルチエージェント分割パターン
- 検索エージェント: クエリから関連ドキュメントを特定する
- 要約エージェント: 長いドキュメントをチャンク単位で要約する
- 統合エージェント: 複数の要約を統合して最終回答を生成する
- 評価エージェント: 回答の品質をチェックし、不十分なら再検索を指示する
各エージェントの入力・出力と状態の共有範囲を設計し、結果を受け渡す。OpenAI Agents SDK、Google ADK、LangGraphは、分業や処理フローを組むための仕組みを提供する。状態を共有する方式もあるため、全エージェントが必ず独立した状態を持つと決めず、採用するSDKの仕様に合わせる。
レイヤー6: メタデータDBの設計
ベクトル間の類似度だけを見ても、「このドキュメントはどのフォルダにあるか」「いつ更新されたか」といった属性条件は反映されない。メタデータの列やフィルターを検索条件へ組み合わせる。例えばpgvectorはWHERE条件を伴う近傍検索に対応しており、ベクトル検索と属性検索のために必ず別DBを用意する必要はない。
推奨スキーマ
設計例として、文書を識別する情報と、検索で使うフォルダ・文書種別・更新日時を保持する。後述のfolder_path、document_type、updated_atは本記事の説明用の列名である。pgvectorのフィルターとインデックスの説明を参考に、検索条件とデータ量に合う索引を設計する。
ハイブリッド検索のクエリ例
- 「特定部門の仕様書で2024年以降の文書」→ folder_path + document_type + updated_at で絞り込み
- 「〇〇工事に関する書類」→ ベクトル検索で関連度順
- 「先月更新された仕様書」→ updated_at + document_type で絞り込み
PostgreSQLならpgvector拡張でベクトル検索を同じDBで実装できるため、システム構成がシンプルになる。
LLMプロバイダーの切替対応
本番運用では、LLMプロバイダーを固定せず切替可能にしておく。OpenAI、Anthropic Claude、Google Gemini、Azure OpenAIなどを環境変数で切り替えられる設計が望ましい。
プロバイダーごとの呼び出しを共通の窓口へまとめる抽象化レイヤー（例えば`LLMClient`という自作インターフェース）を実装する方法がある。各社の認証・入力形式・モデル機能の差を吸収する処理と動作確認が必要であり、設定1行の変更だけで互換性が得られるとは限らない。
ドキュメント更新検知の仕組み
ドキュメントが更新された際に、ベクトルDBのインデックスを再構築する必要がある。以下のパターンが一般的。
定期バッチ方式
夜間バッチで全ドキュメントをスキャンし、`updated_at`が変わったものだけを再インデックス化する。シンプルだが更新反映に時間がかかる。
ファイル監視方式
ファイルシステムの変更イベントを契機に再インデックス化する。Linuxのinotifyは候補だが、ネットワークファイルシステム上で別のマシンが起こした変更は検知できないため、定期確認等を併用する。AzureではBlob StorageがEvent Gridへ作成・削除等のイベントを発行する。これをAzure Filesにも共通する機能とみなさず、Filesでは更新日時の定期確認や書き込み処理からの通知等を検討する。
Webhook方式
SharePointやBoxのWebhookを利用し、変更通知を受けて文書を取得・再インデックス化する方法もある。通知遅延や再試行は提供元と受信処理に依存するため、常に最もリアルタイムとは限らない。要件に応じて定期的な差分確認を併用する。
Streamlitでの実装上の注意点
社内向けの簡易UIはStreamlitで構築するケースが多い。ただし以下の制約に注意が必要。
ページURLの重複を避ける
Streamlitの複数ページ構成では、ファイル名や関数名からURLが推定される。st.Pageのurl_pathで明示的に指定することもできる。登録するページのURLが重ならないようにし、ファイル名の数字プレフィックスだけで一意になると考えず、実際のURLを確認する。アプリ内の全ファイルに同名禁止の制約があるわけではない。
Expanderのネストと対象バージョン
Streamlitは1.46.0でexpander等のネスト制限を撤廃したため、現行版で一律にネスト不可とはいえない。ただし公式API資料は、画面サイズに応じた見やすさのためネストを避けることを勧めている。マークダウンヘッダーや`st.divider()`も使い分け、利用中のバージョンで表示を確認する。
セッション状態の管理
マルチエージェントの状態やメッセージ履歴をst.session_stateで管理すると、同じユーザーセッション内のスクリプト再実行をまたいで保持できる。一方、ブラウザの再読み込みではWebSocket接続とSession Stateがリセットされる。再読み込み後にも必要な履歴はDB等へ保存し、認証された利用者に対応する情報を復元する仕組みを別途設ける。
社内ナレッジ検索AIの導入で決める項目
renueでも社内検索にAIを活用しています。導入先の構成を検討する際は、次の項目を要件として整理します。
- 検索対象と対応ファイル形式
- 利用者の権限に応じた検索範囲
- 検索・要約・評価の処理分担
- データの保存先と取得方法
- モデルの切替条件と評価方法
- 更新時の再索引と運用責任
- 稼働環境と障害時の復旧方法
導入時のよくある失敗パターン
- ファイルパスをハードコード: 本番環境で動かない
- 単一の長大プロンプトで実装: トークン制限で失敗
- ベクトル検索のみに依存: 属性条件が必要な質問では、メタデータによる絞り込みも組み合わせて評価する
- .doc対応を忘れる: 古い仕様書が読めない
- LLMプロバイダーを固定: API障害時に動かなくなる
- 更新検知の仕組みがない: 古い情報を返し続ける
- エラーの客観的事実を記録しない: 再現・デバッグができない
業界別の活用パターン
| 業界 | 主な活用ドキュメント |
|---|---|
| 製造業 | 設計仕様書、工程手順書、品質管理マニュアル |
| 金融 | 商品説明書、規程類、稟議書、コンプライアンス資料 |
| 法務 | 契約書、判例、法令、規則 |
| 医療 | 診療プロトコル、薬剤情報、症例報告 |
| 建設 | 設計図、施工要領、安全管理規程 |
| 電力・インフラ | 運用マニュアル、保守手順、各種仕様書 |