営業部門は AI Agent で過去の見積もりを検索し、調達部門はサプライヤー情報を整理し、カスタマーサービス部門は顧客記録を参照したいと考えています。概念実証の段階でチームが重視するのは回答の品質ですが、本番稼働の準備に入ると、管理者が対処すべき課題は変わります。AI Agent はどのシステムに接続できるのか、誰のデータを閲覧できるのか、内容を変更できるのか、問題が起きた場合はどこから調査を始めるべきなのか、といった点です。
機能を完成させてからガバナンス規程を追加しようとすると、IT・情報セキュリティ部門は既存の設計に制限を上乗せすることしかできず、事業部門もテスト段階の利便性を本番環境の要件と捉えがちです。そのため、本番稼働前に接続、権限、監査に関するルールを明確に定め、初回の開放範囲はむしろ限定的にすることを推奨します。社内データはまず読み取りのみを許可し、書き込みは認めない。外部ドメインは一つずつ審査したうえで開放し、すべての操作について検証可能な記録を残す、という進め方です。
AI Agent がアクセスできるデータを先に制限し、実行可能な操作はその後に決める
奇美病院の取り組みは、非常に参考になる事例です。同院は2005年からデータ分析能力を蓄積し、その後、疾病リスク予測、生成 AI（generative AI）による文書作成支援へと取り組みを広げ、段階的に AI Agent の活用へと進んできました。ただし、データガバナンスと安全な実行環境にはなお強化が必要なため、AI Agent は現時点でまだ正式に稼働していません。同院は安全なサンドボックス（Sandbox）を「ロブスターのいけす」に例えています。これは、プログラムを制限された環境内で実行し、本番システムに直接影響を与えたり、本来アクセスすべきでないデータに接触したりすることを防ぐ仕組みです。
企業はまず、2つのリストを作成するとよいでしょう。1つ目は、注文データベース、見積書ファイル、サプライヤー情報、カスタマーサービス記録などのデータソース一覧です。2つ目は、検索、ダウンロード、送信、下書き作成、システムへの書き込みなど、AI Agent が実行する可能性のある操作一覧です。AI Agent にデータの読み取りを許可することは、一括エクスポートまで許可することを意味しません。見積書の下書き作成を許可することも、顧客への直接送信を許可することとは異なります。データソースと操作権限を分けて整理することで、管理者はリスクの所在を明確に把握できます。
初回の本番稼働では、読み取りと書き込みを分けることができます。まずは AI Agent に社内データの検索、差異の整理、下書きの作成を担当させ、その後、従業員が確認します。一方、マスターデータの変更、価格の承認、発注書の送信、顧客ステータスの更新については、当面、既存システムと承認フローで処理します。外部接続も一度にすべて開放するのではなく、必要なドメイン、用途、責任者を一つずつ明記し、リストに含まれていない接続はすべて拒否します。
本番稼働前の審査では、まずプロジェクトチームにデータソース、許可する操作、外部ドメインという3つのリストを提出させ、その後、実際のアカウントを使用して、権限を超えたアクセスや禁止された書き込み操作をシステムが確実に遮断できるかテストします。この3つのリストすら明確に作成できない段階では、機能の範囲を拡大すべきではありません。
権限はプロンプトに記載するだけでなく、職務と組織の役割分担に沿って設定する
「自部門のデータのみ閲覧できる」というルールをプロンプトに記載しただけでは、それはモデルに対するテキスト上の指示にすぎず、本人確認やシステム権限の代わりにはなりません。企業はまず、次の3種類の問いに答える必要があります。誰がどの AI Agent を利用できるのか、各 AI Agent はどの部門のデータを読み取れるのか、そして誰が接続設定や管理画面の設定を変更できるのか、という問いです。この3種類の権限がすべて同じ管理者アカウントに集中していると、問題発生後に、その原因が事業上の要件なのか、操作ミスなのか、あるいは誰かが不適切に設定を変更したのかを判別することが難しくなります。
見積もりプロセスを例にすると、営業担当者は自分が担当する顧客の過去の注文を検索し、下書きを作成できます。営業責任者は部門内の案件を閲覧でき、IT 部門は接続設定を担当し、情報セキュリティ部門は異常な記録を確認します。調達における相見積もりでも、同じ原則を適用できます。担当者が閲覧できるのは指定されたサプライヤーと品目に限られます。複数の部門が同じ AI Agent を共同利用しているからといって、他部門の契約条件まで開放してはなりません。こうしたルールは、アカウント、ロール、データ範囲に実際に設定する必要があり、ユーザーが会話のたびに AI Agent へ注意を促すことを前提にしてはいけません。
IT、情報セキュリティ、事業部門の責任者が共同でロールマトリクス（role matrix）を作成し、各ロールが利用できる機能、閲覧できるデータ、変更できる設定、必要な承認者を項目ごとに明記することを推奨します。テストでは、通常のプロセスが問題なく完了できることを確認するだけでなく、ユーザーの所属部門が権限条件を満たしていない場合、アカウントが無効化されている場合、未承認データへのアクセスを試みた場合なども想定し、ネガティブテストを実施する必要があります。システムがこれらの操作を確実に拒否することを確認してから、実際の業務ニーズに応じて権限を段階的に緩和します。
記録を残すだけでは不十分。誰が何をしたのかまで追跡できるようにする
AI Agent が誤作動した際、最終的に生成された文書だけを残しても、問題を追跡するには不十分です。企業は、どのユーザーがタスクを開始したのか、AI Agent がどのデータを読み取ったのか、どのツールを呼び出したのか、いつシステムに拒否されたのか、誰が権限を変更したのかまで確認できるようにする必要があります。監査記録を自由に削除・改変できたり、誰かが記録をダウンロードしても履歴が残らなかったりする場合、情報セキュリティ部門や内部監査部門は依然として事実関係を再現できません。
奇美病院では現在、AI Agent がタスクを理解して計画を立てた後、ロボティック・プロセス・オートメーション（Robotic Process Automation、RPA）が定型操作を実行するという役割分担を検討しています。企業もこの方法で責任範囲を分けることができます。AI Agent は情報を整理して次のステップを提案し、RPA は事前に定義され、結果を予測できる操作だけを実行します。支払い、価格の承認、顧客マスターデータの変更、社外への送信などの業務では、いったんプロセスを停止し、責任者の確認を待ちます。導入当初から、AI Agent がタスクを理解した後に本番システムを直接変更できるようにする必要はありません。
EgentWrX では、同一の管理メカニズムを通じて、こうした制限を実装できます。AI Agent は社内ネットワーク経由でデータベースを読み取ることができ、社内データベースへの接続は読み取り専用で変更不可に設定できます。外部ドメインについては、一つずつ審査したうえで接続を許可します。フロントエンドとバックエンドの権限は分けて管理し、管理者は部門やカスタムロールに応じて機能とデータ範囲を制限できます。監査ログ（audit log）は検索・エクスポートが可能で、ハッシュチェーン（hash chain）を用いて記録が改変されていないか検証できます。管理者が監査記録をダウンロードした場合も、その行為自体が記録されます。こうした仕組みにより、企業は操作を実際に制限し、記録を検証できます。ただし、どのプロセスを開放するのか、誰が承認を担当するのかについては、各企業が自ら決定する必要があります。
正式な本番稼働前に、情報セキュリティ部門または内部監査部門が毎週・毎月どの記録を抽出確認するのかを定めておく必要があります。少なくとも、AI Agent の実行状況、権限変更、監査データのダウンロードを対象に含めるとともに、利用停止の条件、報告先、調査手順も明確に記載します。チームが記録から「誰が、いつ、どの権限を使用し、何をしたのか」に答えられるようになってから、次のデータソースや書き込み操作を開放するかどうかを評価します。
よくある質問
データベースは最初に必ず読み取り専用に設定すべきですか？
初回の本番稼働では、読み取り専用に設定することを推奨します。AI Agent にはデータの検索、比較、整理を担当させ、マスターデータの変更、価格の承認、帳票の送信などの操作は引き続き既存システムで処理します。チームがテストとリスク審査を完了してから、書き込み権限を開放するかどうかを項目ごとに評価してください。データベース全体の権限を一度に付与すべきではありません。
プロンプトで AI Agent を制限すれば、システム権限の代わりになりますか？
なりません。プロンプトは AI Agent に業務ルールを伝えることはできますが、アカウント、ロール、データ範囲などのシステム権限の代わりにはなりません。企業は、閲覧可能なデータ、利用可能な機能、管理画面の設定権限を分けて管理し、権限のないアカウントを使用して、システムが実際にアクセスを拒否するかテストする必要があります。プロンプト上のルールと実際の権限設定が異なる状態を防ぐためです。
どのような操作で人による確認を残すべきですか？
支払い、価格の承認、本番データの変更、社外への送信、部門をまたぐデータ開示などの操作では、いったんプロセスを停止し、責任者に確認させることを推奨します。企業は、金額、データの機密性、影響範囲に応じて人による承認が必要な工程を設定し、誰が実行を許可できるのか、誰が例外処理を担当するのかを明確に指定できます。
監査ログには最低限、何を記録すべきですか？
監査ログには最低限、タスクの開始者、実行日時、使用したデータとツール、権限の変更、失敗または拒否された操作、監査データのダウンロード行為を記録する必要があります。情報セキュリティ部門または内部監査部門は定期的に記録を抽出確認し、記録が自由に改変できないことを確認するとともに、権限を超えた行為が発覚した場合に、関連する権限を直ちに無効化して調査を開始できる体制を整える必要があります。
参考資料
- AI との共存から AI ファーストへ、奇美病院が明かす AI 発展の4段階構想 — iThome による、奇美病院の AI 発展プロセス、AI Agent の計画、安全なサンドボックスの前提条件に関する報道。
