社内向けAIチャットボットをRAGで作る前に決める4つの可用性設計軸

社内文書検索やFAQ対応にAIチャットボットを導入する検討が進むと、必ず技術選定の壁にぶつかります。単純にLLM（大規模言語モデル。文章生成や質問応答を行うAIモデル）をチャット画面につなぐだけでは、社内データを参照した回答や業務システム連携はできません。

この記事は、社内アシスタントや顧客サポート向けチャットボットの基盤設計を任されたSRE・インフラ担当者に向けた内容です。アーキテクチャ選定を、可用性・運用コスト・障害対応の観点から整理します。

どんな場面でこの判断が必要になるか

典型的なきっかけは「社内ドキュメントを検索できるチャットボットが欲しい」という依頼です。

ここで安易にLLM単体構成を選ぶと、後から「最新の社内規定を反映できない」「回答の正確性を検証できない」といった問題が噴出します。逆に最初から複雑な構成を組むと、開発期間とインフラコストが膨らみます。

判断が必要になるのは、主に次の場面です。

• FAQ的な単純応答から社内データ参照型への拡張を検討するとき
• ベンダーから複数のアーキテクチャ案を提示されて比較するとき
• 既存の監視・SLO運用体制にチャットボットを組み込むとき

判断軸1: データ鮮度要件

最初の軸は、回答に使う情報がどれだけ頻繁に更新されるかです。

LLMは学習時点の知識をパラメータに内包していますが、社内規定や在庫情報のような変化の速い情報は反映されません。ここで使われるのがRAG（検索拡張生成）という仕組みです。

RAGは、ユーザーの質問に対してまず社内の文書やデータベースから関連情報を検索し、その内容をLLMへのプロンプト（指示文）に含めてから回答を生成させる方式です。たとえば「有給休暇の申請方法」という質問なら、就業規則の該当ページを検索で取得し、その本文をLLMに渡してから回答させます。

データが日次・週次で更新されるなら、検索対象のベクトルデータベース（文章を数値ベクトル化して類似度検索するためのデータストア）の再インデックス処理をどの頻度・どの方式（差分更新か全件再構築か）で回すかが、そのままインフラのバッチジョブ設計と直結します。

判断軸2: 可用性要件とSLO設計

2つ目の軸は、チャットボットが止まったときの業務影響度です。

顧客向けサポートチャットボットと、社内の一部門だけが使う情報検索ツールでは、求められる可用性が全く違います。ここで必要になるのがSLO（サービスレベル目標）の明文化です。

SLOは「レイテンシは95パーセンタイルで2秒以内」「可用性は月間99.5%以上」のように、数値で合意された品質目標です。LLM呼び出しを含むシステムでは、LLM APIそのものの応答時間がボトルネックになりやすく、社内で完結する従来のWebアプリよりSLO設計が難しくなります。

外部LLM APIのレイテンシ変動やレート制限（一定時間あたりのリクエスト数上限）は自社ではコントロールできません。そのため、タイムアウト時のフォールバック応答や、リトライ回数の上限をあらかじめ決めておく必要があります。

判断軸3: セキュリティとアクセス制御の粒度

3つ目の軸は、チャットボットが扱う情報の機密度と、ユーザーごとのアクセス権限の違いです。

人事情報を扱う社内アシスタントであれば、質問者の役職や部署によって参照できる文書を分ける必要があります。これはRAGの検索層に認証・認可の仕組みを組み込む設計になり、単純なチャットボットより実装コストが上がります。

たとえば、一般社員がRAG経由で役員向け人事評価資料にアクセスできてしまう構成は、ベクトル検索の対象範囲をユーザー権限でフィルタしていないことが原因で起こりえます。IaC（Infrastructure as Code。インフラ構成をコードで定義・管理する手法）でTerraformやPulumiを使っている場合、この権限境界をIAMロールやVPC内のネットワーク分離としてコード化しておくと、監査時の説明がしやすくなります。

判断軸4: 運用コストとオブザーバビリティ

4つ目の軸は、稼働後の監視コストと、問題発生時に原因を追跡できる体制があるかです。

LLM呼び出しは従量課金のため、トークン数（LLMが処理する文章の単位）に応じてコストが変動します。想定外に長い会話やループする質問が続くと、コストが急増するリスクがあります。

オブザーバビリティ（システムの内部状態を外部から観測できる性質）の観点では、通常のアプリケーションログに加えて、LLMへのプロンプト内容・検索でヒットした文書・生成された回答をセットで記録する仕組みが必要です。これがないと、誤った回答が出たときに「検索が悪かったのか、プロンプトが悪かったのか、モデルの問題か」を切り分けられません。

アーキテクチャ比較

ケース別の推奨

• 社内FAQの試験導入で、参照する文書が月1回程度しか変わらないなら、まず基本LLM直結型か軽量なRAG型で始めて構いません
• 部署をまたいで機密度の異なる文書を扱うなら、RAG型に認可フィルタを組み込んだ構成を選び、Terraformなどでアクセス境界をコード化しておくべきです
• 顧客対応で受注状況の照会まで行うなら、業務システムAPI連携込みの構成にし、SLOを顧客向けサポート水準（可用性99.9%程度など、既存のサポートチャネルと同等の基準）に合わせて設計します
• 社内向けで利用者が少数かつ許容できるダウンタイムが長いなら、監視体制を簡略化してコストを抑える選択も妥当です

あえて見送るべき条件

すべての社内問い合わせ対応にRAG型やシステム連携型を導入する必要はありません。

• 参照する情報が数ページのFAQに収まり、更新頻度も低いなら、ベクトルデータベースを構築する複雑さは見合いません
• 社内で試験的に使うだけで、権限が異なるユーザー層が存在しないなら、認可フィルタの実装は後回しにできます
• LLM呼び出しのログ基盤や監視ダッシュボードを整備する体制がまだ整っていないなら、まず小規模構成で運用ノウハウを溜めてから拡張する方が安全です

導入前に確認すること

チャットボットの構成を決める前に、次の点を確認しておくと判断がぶれません。

• 参照データの更新頻度と、RAGの再インデックス作業を誰がどの頻度で回すか
• 想定利用者数と許容ダウンタイムから逆算したSLO値
• ユーザー権限ごとにアクセス可能な文書範囲をどう技術的に分離するか
• LLM呼び出しのプロンプト・検索結果・回答をログとして記録する仕組みがあるか

これらを埋めてから初めてベンダー選定やモデル選定に進むと、後戻りの少ない構成にたどり着きやすくなります。