AIエージェントをエンタープライズシステムに組み込むプラクティス
【信頼境界の二層分離(Trust Boundary Split)】
💡 ポイント
「社内向けエージェントと顧客向けエージェント、同じスタックで動かしていませんか?それ、情報漏洩の時限爆弾です。」
従業員向けと顧客向けでは信頼レベル・データ境界・失敗コストが根本的に異なります。同一設計で済ませると、顧客経路から内部情報が漏れる最悪のシナリオが現実になります。
🔥 解決する課題
- 顧客向けエージェント経由での内部情報漏洩(最も致命的なリスク)
- 敵対的入力(ジェイルブレイク・間接プロンプトインジェクション)による暴走
- 従業員向けの「緩い前提」を顧客向けにそのまま適用してしまう設計事故
- 顧客向け障害がブランド毀損・法的責任に直結する不可逆リスク
🏗️ 提案パターン
従業員向けと顧客向けを物理的/論理的に分離した二層のプレーンとして設計します。従業員向けは社内IdP(Okta/Entra)でSSO認証し、社内データに広くアクセスできます。一方、顧客向けエージェントはDMZ相当の隔離環境に配置し、内部データは「公開可能と明示したread model(投影)」のみ参照可能にします。顧客向けの出力にはDLP(データ漏洩防止)検査を必須通過させ、ガードレールも格段に厳格にします。オーケストレーション基盤やモデルゲートウェイは共有してもよいですが、データ到達経路は必ず分離します。
✅ 選定条件
- 採用する場合:顧客と従業員の両方がエージェントを利用する。B2C/B2B両面を持つ企業。顧客接点と社内業務が同一基盤を共有しようとしている。
- 採用しない場合:純粋に社内専用の用途のみ(過剰な分離はコスト増になります)。
⚠️ 落とし穴
- 「オーケストレーション基盤を共有しているから大丈夫」と思い込み、データ到達経路まで共有してしまうケース。基盤の共有とデータ経路の分離は両立が必要です。
- 顧客向けガードレールの設計を後回しにすると、本番稼働後に重大インシデントが発生します。ジェイルブレイク検知・トピック制限・拒否方針は初期設計に含めてください。
- 監査ログの設計で顧客識別子とPIIの保持期間管理を怠ると、コンプライアンス違反に繋がります。
🛠️ 実装方針
- まずネットワークセグメンテーションで顧客向けプレーンを隔離します。VPC/サブネット分離で顧客向けエージェントをDMZ相当の環境に配置し、内部ネットワークへの直接到達を遮断します。
- 顧客向けプレーンが参照するデータをCQRSのread model(公開可能データの投影)として構築します。内部DBへの直接アクセスではなく、公開可能と明示したデータのみを投影するビューを用意します。
- DLP(データ漏洩防止)検査パイプラインを顧客向け出力経路に設置します。全出力を通過させ、内部由来情報のリークを検知・ブロックします。
- 顧客向けプレーンにガードレールポリシーを配備します。ジェイルブレイク検知・トピック制限・トーン制御・拒否方針を含む、従業員向けより格段に厳格なポリシーセットを適用します。
- 認証基盤を分離します。従業員向けは社内IdP(Okta/Entra ID)でSSO、顧客向けは顧客IdP(Auth0/CIAM)を使い、認証経路を完全に分けます。
#
AIエージェント# #
エンタープライズアーキテクチャ#