2026年7月22日 · ISZ.AI Solution Architecture Team

閉域ネットワークでもAIが「嘘をつく」問題は解決できる：社内ナレッジ検索の精度を本気で上げる方法

「セキュリティ部門からの指摘でChatGPTは閉域網専用インスタンスに切り替えたのに、現場からは『回答が的外れ』『平気で嘘をつく』という声が止まらない」。そんな相談が増えています。

閉域網 RAG ハルシネーションの問題は、閉域環境での運用それ自体が原因ではありません。閉域環境での運用という判断は正しく、問題はセキュリティを固めた後の検索精度がほぼ手つかずのままになっているケースがほとんどだ、という点にあります。テキストをベクトルDBに放り込んで終わりという構成では、エンタープライズの要求には到底応えられません。

この記事では、閉域網という制約の中でハルシネーション（AI の誤回答・でたらめな情報生成）をどこまで抑えられるか、技術的な実装から運用の勘どころまでを整理します。

現場が「使えない」と言う本当の理由

よくある説明は「モデルの性能が不十分だから」ですが、現場の不満の根っこはほぼ例外なくデータの問題です。

社内マニュアルや過去の稟議書がPDF、Word、Excelなどに分散し、複雑なレイアウトや表が崩れたままインデックスに入っている。この状態でAIが正確な回答を返せるはずがありません。

もう一つ見落とされがちなのが「相互参照の壁」です。業務規程には「原則としてAを行う。ただしBの場合はCを適用（詳細は別紙参照）」という記述が山積みです。一般的なRAG実装はこの文脈のつながりを辿れないため、断片的な情報から都合よく補完した回答を生成してしまいます。

加えて、アクセス権限の設計が甘い全社共通インデックスは、情報漏洩リスクと「欲しい情報に辿り着けない」という相反する問題を同時に抱えます。

精度を上げるために変えるべき3つのポイント

① テキスト抽出とチャンキングをやり直す

「PDFを丸ごとEmbeddingに投げる」は最も安易で最も精度が出ない方法です。

章構造や見出し階層を意味単位で保持したまま分割するセマンティック・チャンキングに切り替えるだけで、検索ヒット率が目に見えて改善します。表データはAI-OCRと構造解析を組み合わせてMarkdown形式のテーブルに変換してからインデックスに入れる。この一手間を惜しむと、数値が含まれる質問ほど回答がブレます。

② ベクトル検索単体を卒業する

意味的類似度で検索するベクトル検索は「質問の意図をつかむ」のは得意ですが、製品型番・法令条文番号・固有の社内用語といった完全一致が必要な固有名詞には弱いという限界があります。

BM25等のキーワード検索と組み合わせたハイブリッド検索を実装することで、この弱点を補えます。どちらの検索にも「得意な質問のタイプ」があるので、両方の結果を合流させる設計が安定感の高い回答に直結します。

③ LLMに渡す前にノイズを減らす

一次検索で引っかかった候補は、そのままLLMのコンテキストに入れるのではなく、Cross-Encoderなどのリランカーで**「この質問への真の関連度」を再評価**してから投入します。

コンテキストのノイズが多いほどLLMはでたらめな補完をしやすくなります。渡す情報を精鋭化するだけで、ハルシネーション率は大幅に落とせます。

標準RAG vs 精度重視のRAG：何が違うのか

評価項目 よくある基本実装 精度重視の実装
検索方式 ベクトル検索のみ ハイブリッド（ベクトル＋キーワード）
ドキュメント解析 テキスト単純切り出し セマンティック構造解析＋表変換
ノイズ除去 なし リランカーによる再評価
アクセス権限 全社共通インデックス 職種・部署単位のACL連動フィルタ
ハルシネーション 日常的に発生する 発生時も引用元ページを明示できる

閉域環境での構成パターン

外部クラウドへのデータ送信が制限される環境でも、選択肢は二つあります。

Azure OpenAI Service（閉域網接続）：Microsoftのエンタープライズ契約のもと、VNet経由で接続し、入力データが学習に使われないOpt-Outを契約上保証。金融・保険系でも採用実績が多い構成です。

オンプレミス / ローカルLLM：防衛・行政・一部の金融機関など、外部通信ゼロが求められる環境では、Llama 3やQwen等のオープンウェイトモデルを社内GPUサーバー上で動かします。レイテンシとコストのトレードオフを見ながら判断します。

[ 社内クライアント ]
       │ （SSL暗号化）
[ 認証ゲートウェイ / ACL ]
       │
[ RAGエンジン（ハイブリッド検索 + リランカー）]
       ├──► [ 閉域ベクトルDB / ナレッジストア ]
       ▼
[ エンタープライズLLM（Azure OpenAI / ローカルモデル）]

精度が出ない社内AIを立て直すには

「ChatGPTを入れたが現場に使われない」「閉域環境に移行したら余計に使いにくくなった」という状態は、珍しいケースではありません。ほとんどの場合、モデルを替えるよりデータの前処理とRAGの構成を見直すほうが早く、コストも低く抑えられます。

ISZ.AIでは、データ構造化・前処理から高精度RAG構築、権限管理の組み込み、運用後の精度モニタリングまでを一気通貫で対応しています。まず1〜2週間の現状診断から始められるので、「どこから手をつければいいかわからない」という段階でもお声がけください。

よくある質問

ハルシネーションを完全にゼロにすることはできますか。 確率的なモデルである以上、完全にゼロにすることは現実的な目標ではありません。現実的な目標は、ハルシネーションの発生率を実用に耐えるレベルまで下げることと、発生した場合に引用元のページを提示して人が検証できる状態にしておくことです。検索精度とリランキングの改善で発生率は大きく下げられます。

すでにベクトルDBで社内AIを運用していますが、作り直す必要がありますか。 多くの場合、ゼロから作り直す必要はありません。既存のベクトルDBはそのまま活かしつつ、チャンキング方式の見直し、キーワード検索の追加、リランカーの導入といった改修を段階的に加えることで精度を引き上げられます。まずは現状のインデックス構成と質問への正答率を確認するところから始めます。

閉域網ではどのLLMを使うのが現実的ですか。 外部クラウドへの接続が一定条件で許可される環境ではAzure OpenAI Serviceの閉域網接続構成、外部通信そのものが禁止される環境ではLlama 3やQwenなどのオープンウェイトモデルを社内GPUサーバーで動かす構成が現実的です。どちらもレイテンシとコストのトレードオフがあるため、要件に応じて選定します。

ハイブリッド検索やリランカーの導入にはどのくらいの費用と期間がかかりますか。 既存のRAG基盤の構成次第ですが、データの前処理・チャンキングの見直しからハイブリッド検索とリランカーの実装までを含めると、数週間から2〜3ヶ月程度が目安です。まずは現状のインデックスと典型的な質問パターンを確認し、どこにボトルネックがあるかを診断するところから始めます。

次のステップ

AIを、スライドではなく本番環境へ。

課題を教えてください。戦略、ソフトウェア、そして必要であれば工場まで、私たちが対応します。

専門家に相談する