コンセンスボット

規制下の現場における文書照会

GMPのように規制がかかる現場では、答えが合っているかより根拠がどこにあるかが先です。実務者はSOP、品質記録、電子文書をそれぞれ別のシステムで探し、目で照合します。時間がかかるうえ、人によって見つけ出す根拠が違うこともあります。

かといって一般的なLLMをつなぐと、かえって厄介になります。文書にない内容をもっともらしく作り出すからです。規程業務において、もっともらしい誤答は答えがないことより悪いものです。

回答の検証方式

コンセンスボットは回答の生成後に検証の段階を置きます。

生成された回答の主要な主張と引用根拠を原文と自動的に照合します。根拠が十分でない、または原文と食い違う場合は再検索して生成し直し、それでも確認できなければ「未確認」と応答します。この検証は一部の標本ではなく全件に適用され、平均0.7秒かかります。

処理の手順

1. 質問の受付 — 質問の意図と主要キーワードを分析して種類（文書照会型・手順案内型・記録確認型）を分け、EDMS・QMS・社内Wiki・業務DBのどこを探すか検索範囲を決めます。
2. 根拠の収集 — SOP、MBR、SPEC、品質記録、変更・逸脱記録から関連資料を集めます。キーワード検索と意味ベース検索を併せて実行し、本文・表・メタデータ・構造化レコードを探索したうえで、最新版や文書番号、表の項目、レコード単位まで絞って根拠箇所を選びます。
3. 回答の生成 — 選んだ根拠から回答を作成し、使用した文書名・文書番号・版・関連項目を添えます。この回答が前述の全件検証を通過して初めて利用者に届きます。

検索範囲

社内のSOPと規程、品質記録、電子文書を一つの窓口で調べます。密な埋め込みと疎な埋め込みを併用するハイブリッド検索のため、用語が正確に一致しなくても見つけられます。

単なる検索だけではありません。複数の文書を並べて比較する、改訂前後の版の差分を指摘する、品質記録を条件別に集計するといった作業も同じ窓口で処理します。

連携対象はQMS、EDMSなどの文書管理システムです。

オンプレミス稼働

vLLM、ベクトルDB、埋め込みモデルまで全構成要素が顧客サーバー上で動作します。外部APIを呼び出さないため、規程文書と品質記録が社外に出ることはありません。

導入形態はオンプレミスまたは顧客専用クラウド（VPC・Dedicated）から選択します。ISO/IEC 27001とGS認証1等級を取得しています。

知識の蓄積

現場から「この答えはこう直すべきだ」というフィードバックが上がると、管理者の承認を経て知識ウィキに蓄積されます。担当者が替わっても、組織が積み上げてきた判断基準が残ります。

導入事例

製薬・バイオ製造業の品質・生産の実務者が対話形式で質問すると、関連文書を検索・比較・検証して出典とともに回答する形で運用されています。

規程文書1,527件、品質記録146,919件、電子文書63,000件超を横断検索しており、生成された回答は全件が自動の根拠検証を経ます。品質が落ちていないかを確認するため、119件の回帰テストを常時実行しています。

導入要件

配備とサーバー — 顧客のセキュリティ方針に応じてオンプレミスまたはプライベートクラウドに構築します。業務システムと文書保管庫に到達する内部網の構成が必要で、LLM・埋め込みモデルを動かすGPUサーバーと、API・検索・ベクトルDBを運用するサーバー資源が要ります。外部網が制限された環境では、モデルとパッケージの搬入・更新の手順をあらかじめ定めておく必要があります。

文書の準備 — SOP・MBR・SPECなどの規程・標準文書、QMS記録、社内Wikiが回答の根拠になります。文書番号・文書種類・版・施行日・作成部署といったメタデータが原文と結びついている必要があり、重複・廃棄・旧版の文書を識別できる状態であることが求められます。表と本文が検索可能な形で抽出されている必要もあります。

連携 — EDMS、QMS、社内Wiki・電子文書保管庫、必要な業務DBと連携します。APIまたはDB照会を基本とし、システムの特性に応じてファイル・バッチ方式も用います。変更分は定期的に再収集してインデックスを更新し、原本システムの文書番号・版などの識別情報はそのまま維持します。

権限と運用 — 一般利用者、管理者、ドメイン査読者で役割を分けます。利用者は回答と根拠を確認してフィードバックを登録し、管理者とドメイン担当者が訂正要請や否定的なフィードバックを査読して承認または差し戻します。承認されたものだけがナレッジWikiとオントロジーに反映され、変更・承認の履歴と回答の根拠を追跡できる必要があります。

お問い合わせいただければ無料のPoC環境をご提供します。