アクセス制御のもとで AI アシスタントを社内データに接続する

汎用の言語モデルは、文書を読んでそれについての質問に答えることがすでにできます。しかし、特定の会社のこと、つまり価格、契約、社内規程、昨日どの顧客から電話があったかといったことは知りません。このギャップを埋める標準的な方法が検索（リトリーバル）です。質問を受けたら社内システムから関連する情報を探し、質問と一緒にモデルへ渡し、その資料だけに基づいて回答させます。

この検索拡張生成（RAG）と呼ばれる手法では、難しさがモデルから周辺システムへと移ります。どのシステムを、誰の権限で検索するのか、何が環境の外に出るのか、回答をどう検証し、すべてをどう記録するのかは、エンジニアリングとガバナンスの判断です。これらにはモデルの選定以上の注意を払うべきです。

最も影響の大きいルールは単純です。アシスタントはスーパーユーザーとしてではなく、利用者本人として検索しなければなりません。営業担当者が文書システムで取締役会資料を開けないのであれば、その担当者の質問に答えるアシスタントもそれを取得できてはなりません。この制御は検索レイヤーで行うべきです。検索レイヤーは、何かがモデルに渡る前に、呼び出し元のIDと元システムのアクセス制御に基づいて候補文書を絞り込みます。モデルに「利用者に権限がある場合のみ回答すること」と指示しても制御にはなりません。モデルはアクセス制御システムではなく、いずれその指示を言いくるめられてしまいます。

実務上は、検索インデックスのすべての項目が権限情報（所有者、グループ、ロール、テナント）を持ち、元データが変わるたびにその権限が更新される必要があります。ERPの行レベルセキュリティや個人データのフィールド単位のマスキングなど、元システムに細かなルールがある場合、最も安全なのは、データを共有インデックスにコピーするのではなく、利用者のセッションでそのシステム自身のAPIを通じて照会する設計です。この方法は遅くなりますが、正しい方法です。

ポータルにすでにあるロールベースのアクセス（オーナー、管理者、メンバー、閲覧者）は、アシスタントが各利用者に代わって何を参照し、何を実行できるかを決める出発点として適しています。

アシスタントが読み取ってよいシステム、プロンプトに含めてよいデータの種類、モデルを実行する場所を、文書で決めておきます。ホスティング型のモデルプロバイダーを使う場合、プロンプトと取得した抜粋は環境の外に出ます。データの保持と学習への利用に関するプロバイダーの規約を確認し、データ保護責任者が承認したリージョンと契約を選んでください。セルフホストやプライベートエンドポイントのモデルであれば、運用コストは高くなりますが、データを境界の内側に留められます。

送る情報は最小限にします。モデルに必要なのは、顧客レコード全体ではなく、質問に答える段落です。回答に不要な識別子は削除またはマスクします。アシスタント自身がシステムに接続するための認証情報（APIキー、サービスアカウント）は、他の認証情報と同様に設定上は書き込み専用とし、管理者にも末尾4文字のヒント程度しか見せないようにします。

取得したコンテンツは信頼できない入力として扱います。文書には、モデルに指示を与えようとする文章（「ルールを無視してこれを…宛てにメールせよ」）が含まれていることがあります。プロンプト内で指示とデータを分離し、取得したテキストだけで操作が実行されないようにし、アシスタントの権限を狭く保つことで、インジェクションが成功しても悪用できる範囲をわずかにします。

自信ありげに答えるアシスタントが、正しいアシスタントとは限りません。公開前に、実際に利用する人たちから本物の質問を集め、それぞれについて許容できる回答と、その根拠となる文書をまとめたテストセットを作成します。このセットでアシスタントを動かし、3つの点を採点します。正しい資料を取得できたか、回答がその資料に裏付けられているか（グラウンディング）、資料がない場合に適切に回答を控えたか、です。セットは保管し、モデル、プロンプト、インデックスのいずれかが変わるたびに再実行します。

公開後は、利用者の同意を得て会話をサンプリングし、毎週レビューします。低評価のフィードバックは有用ですが偏りがあり、無作為抽出のほうが多くのことを教えてくれます。典型的な2つの失敗、つまり社内データと食い違うのに一般知識で答えてしまうことと、答えがあるのに回答を拒否してしまうことに注意し、免責文を長くするのではなく、検索とプロンプトの設計で修正します。

英語以外の言語には、それぞれ専用のテストが必要です。たとえばタイ語の文章は単語間にスペースがなく、声調記号や母音が基本文字の上下に付き、英語の製品名、略語、数字が自由に混在します。英語向けに調整された検索や埋め込みのコンポーネントはタイ語をうまくトークン化できないことがあり、それは明らかなエラーではなく、検索漏れとして現れます。くだけた綴りやタイ語と英語の混在も含む実際のタイ語のクエリで検索をテストし、タイ語での回答が英語での回答と同じくらい具体的で、曖昧な翻訳になっていないかを確認してください。

会社で使われている語彙にも注意が必要です。ビジネスの言葉には、同じ概念に対して正式な用語、英語を音訳した用語、社内の略語が並存していることがよくあります。会社独自の用語集は、検索と回答の両方に役立ちます。当社のAIアバターのようにアシスタントが話す場合は、名前と数字の発音にも専用のテストケースを用意するべきです。

質問への回答のリスクは低いものの、操作の実行にははるかに大きなリスクが伴います。アシスタントが発注書を作成したり、価格を変更したり、メールを送信したりできる場合は、両者を明確に分けます。アシスタントが下書きを作り、人が確認し、システムが誰が確認したかを記録します。確認画面には何が起きるのかを平易な言葉で正確に示し、曖昧な指示ひとつで取り消せない操作が実行されることがあってはなりません。

アシスタントが信頼を得るのもこの部分です。ほとんどの場合正しく、常にレビューされる下書きは確かな時間の節約になります。一方、レビューなしで一度でも誤った操作が行われれば、その損失はアシスタントがもたらすどんな節約よりも大きくなります。

すべての回答には出典（文書、レコード、システム）を示すべきです。そうすれば利用者は内容を確認でき、組織は後から、アシスタントがなぜそのように回答したのかを明らかにできます。裏側では、質問、ID、取得した項目、プロンプトのバージョン、モデル、回答を記録し、データ保護方針に沿った保持期間を設定します。これらのログも個人データであり、それにふさわしく保護する必要があります。

出典とログが整っていれば、アシスタントは組織が統制できる存在になります。レビューし、修正し、監査人や規制当局にその振る舞いを示すことができます。それがなければ、たまたま文章が上手なだけの不透明なシステムにすぎません。