社内検索RAGの開発費用｜権限連携・引用表示・更新運用

社内文書を生成AIで探せるようにしたい。そこで候補になるのが、検索結果を根拠文書と一緒に回答へ使うRAGです。ただし、チャット画面だけを見積もると、権限や更新運用で追加費用が出ます。今回はトーンとΛ-51が、社内検索RAGの開発費用を現実的な条件へ分解します。

トーン「結論。費用を動かすのはAIモデルの名前より、文書の種類、権限、更新、回答の検証方法。デモの派手さだけで選ぶと危険」

Λ-51「ワレワレは技術構成を観測する。検索、生成、引用、権限判定を分ければ、見積条件が明確になる」

社内検索RAGの開発費用を決める8要素

見積もりでは次を分けます。

1. 対象文書と保存先
2. PDF・表・画像などの解析
3. 検索索引と更新頻度
4. ユーザー認証と閲覧権限
5. 回答生成と引用表示
6. 管理画面・評価・ログ
7. セキュリティと監査
8. 利用量、保守、モデル変更

トーン「『社内文書を全部検索』は要件ではない。どの部門が、何を、どんな判断に使うかまで絞って」

対象文書の種類で解析工数が変わる

テキスト中心のWebページや整った文書は比較的扱いやすい一方、スキャンPDF、複雑な表、図面、古いファイルは前処理が増えます。OCRが必要でも、読み取り結果を人が確認する仕組みがなければ誤りが索引へ入ります。

Λ-51「地球のPDFは外見が同じでも内部構造が異なる。文字を保持するもの、画像だけのもの、表の順序が崩れるものをサンプルで分類するべきである」

見積前に、各保存先から代表ファイルを集めます。文書数だけでなく、ページ数、容量、更新頻度、言語、表や画像の割合、パスワード保護の有無を確認します。

文書分割とメタデータ

RAGでは文書を検索しやすい単位へ分割し、タイトル、部署、更新日、版、機密区分などを付けます。分割が細かすぎると文脈が切れ、長すぎると検索精度や処理費が悪化する場合があります。

トーン「最適値を最初から断定するサービスには注意。規程、手順書、議事録では適切な分け方が違う。評価用の質問で比較するのが安全」

権限連携は後付けしない

社内検索で重大なのは、見つけてはいけない文書を表示しないことです。検索結果を生成AIへ渡す前に、利用者の権限で絞り込みます。回答だけ隠しても、引用やログに機密情報が残る可能性があります。

確認する権限は、部署、役職、プロジェクト、個別共有、退職・異動、外部ユーザーなどです。保存先が複数なら、権限体系の違いも吸収する必要があります。

Λ-51「ワレワレの観測では、認証と認可は別である。ログインできることと、その文書を読めることを混同してはならない」

トーン「権限情報を索引へ複製するなら、異動時にいつ反映されるかも決める。削除が翌日では困る文書もある」

権限方式の候補

方式	特徴	主な注意点
保存先の権限を都度確認	正本に近い	応答速度・API制限
権限情報を索引へ同期	高速化しやすい	同期遅延・削除漏れ
対象を公開範囲ごとに分離	構成が分かりやすい	索引数・運用負担

単一方式が常に正解ではありません。機密度、利用頻度、保存先のAPI、許容遅延で選びます。

引用表示は回答を検証するための機能

RAGでも、検索ミスや生成上の誤りを完全には防げません。回答の根拠となった文書名、該当箇所、更新日、リンクを表示し、利用者が確認できるようにします。

Λ-51「回答が流暢であることと、正しいことは同義ではない。地球人は文章の自然さに説得されやすい。引用へ戻れる航路が必要である」

引用先の文書が更新・削除された場合の挙動も決めます。古い版を回答に使わない、廃止文書を明示する、最新版へのリンクを優先するなどのルールが必要です。

トーン「『AIがそう言った』で業務判断を終わらせない。人事、法務、安全、金額の判断では、原文確認と承認を残す」

更新運用にかかる費用

初回登録だけでなく、追加、更新、削除を索引へ反映します。更新方式は定期バッチ、イベント連携、手動再取込などがあります。

• 日次・時間単位など更新頻度
• 差分取得か全件再処理か
• 削除・権限変更の反映時間
• 取込失敗時の再実行
• 重複文書・旧版の扱い
• 管理者への通知と監査ログ

Λ-51「索引は静的な百科事典ではない。業務文書が変化するなら、同期状態を観測する画面が要る」

失敗件数、最終成功時刻、対象外ファイル、解析エラーを管理者が確認できるようにします。更新が止まっているのに回答だけ動く状態は避けなければなりません。

AIモデルとインフラの費用

費用には、生成モデル、埋め込み、ベクトル検索、文書保存、ログ、監視、ネットワークが含まれます。外部APIか自社環境かによって、初期費用、運用負担、データ管理が変わります。

トーン「自社環境なら自動的に安い、外部APIなら自動的に危険、という単純な話ではない。利用量、保守要員、契約条件、データ保持を比較して」

質問数だけでなく、一回あたりの検索件数、回答の長さ、再質問、夜間バッチなどを見積もります。モデルを変更できる抽象化を入れると柔軟ですが、その設計と検証にも費用がかかります。

見積もりは3段階に分ける

1. 技術検証

対象部門を一つ、文書を限定し、代表質問で検索と引用を試します。回答率だけでなく、誤引用、見つからない質問、権限違反を記録します。

2. 本番最小構成

認証、権限、更新、管理画面、ログ、バックアップ、問い合わせ対応を加えます。利用規程と、回答を業務判断に使う範囲も決めます。

3. 部門拡張

文書種別や保存先を追加し、評価データを継続更新します。部門ごとの用語や権限を吸収できるか確認します。

Λ-51「小さく試す目的は成功演出ではない。失敗する質問と危険な境界を発見することである」

トーン「PoCで正答例だけ見せるのは比較にならない。回答しない判断、権限外、旧版、曖昧な質問もテスト項目に入れて」

見積依頼に添える確認事項

• 利用部門、人数、想定質問数
• 文書保存先と代表ファイル
• 文書数、容量、更新頻度
• 認証基盤と権限体系
• 引用表示と原文リンクの要件
• ログの保存期間と閲覧者
• 外部API利用可否、データ保持条件
• 目標応答時間と障害時の代替手段
• 評価用の質問・期待する根拠文書

まとめ：回答画面より権限と更新を見積もる

社内検索RAGの開発費用は、チャットUIだけでは決まりません。文書解析、権限連携、引用、削除反映、評価、監査、モデル利用量を分けて見積もる必要があります。

トーン「トーンの結論。最初に決めるのは、答えてよい範囲と原文へ戻る方法。便利さより前に、漏えいと誤判断を防ぐ設計を置く」

Λ-51「ワレワレの結論は、代表文書と危険な質問で検証すること。社内検索RAGの開発費用を具体化したいなら、対象文書と権限条件をそろえて開発見積もりをご相談いただきたい」