AIに社内システムを操作させるときの権限設計｜最小権限で始める考え方

AIの使い方は、質問に答えてもらう段階から、社内システムを操作させる段階へ広がりつつあります。たとえば、顧客管理システムで取引の履歴を調べて報告書の下書きを作る使い方です。在庫数を確認して発注書の案を作る、といった使い方も考えられます。

こうした使い方をするには、AIに社内システムへのアクセスを許可しなければなりません。便利な反面、権限を広く渡しすぎると、意図しないデータの変更や情報の漏えいにつながるおそれがあります。この記事で扱うのは、AIに社内システムを操作させるときの権限の考え方と設計の手順です。

AIが社内システムを操作する仕組み

AIが社内システムを操作するときは、多くの場合「エージェント」と呼ばれる仕組みを使います。エージェントとは、AIが指示に沿って、検索や入力などの手順を続けて実行する仕組みのことです。システムとのやり取りには、APIと呼ばれる接続方法がよく使われます。APIは、システム同士がデータを受け渡すために用意された決まった手順です。

AIが操作できる範囲は、AIに渡したアカウントや鍵の権限で決まります。指示文に「削除はしないこと」と書いても、それだけで操作を防げるとは限りません。AIが指示を誤って解釈したり、想定外の入力を受け取ったりすることがあるためです。操作の制限は、指示文より権限の設定で行うのが基本です。

基本は「使う人の権限を超えない」こと

権限の渡し方には、大きく分けて2つの方法があります。一つは、AI専用のアカウントを作り、そのアカウントに広い権限を与える方法です。もう一つは、AIを使う社員本人の権限の範囲で、AIに操作させる方法です。

AI専用のアカウントに広い権限を与えると、設定は簡単になります。その一方で、本来はその情報を見られない社員が、AIを通して情報を引き出せてしまう問題が起こります。たとえば、人事評価の資料を閲覧できない社員がAIに質問し、内容を知ることができる状態です。

社内で使うAIでは、AIを使う人の権限を超えない設計を基本にしましょう。そのうえで、業務に必要な範囲にさらに絞り込みます。この考え方を「最小権限」といい、セキュリティの基本的な原則の一つです。必要な権限だけを渡しておけば、AIが誤った操作をした場合でも、影響の範囲を小さくできます。

夜間に自動で処理を行う場合など、特定の社員に結びつかない処理では、AI専用のアカウントが必要になることもあるでしょう。その場合は、処理の対象となるデータと操作だけに権限を限り、ほかの用途には使わないようにしてください。

操作の種類ごとに権限を分ける

権限を考えるときは、システムへの操作を種類ごとに分けると整理しやすくなります。操作の種類と、始めるときの設定の目安を表にまとめました。

最初は「参照」だけを許可して試すと、問題が起きても影響を小さくできます。作成を許可する場合も、AIが作ったデータは下書きとして扱い、人が確認してから確定する流れにしましょう。変更や送信のように取り消しにくい操作は、人の承認を入れることが前提です。承認の入れ方はAIの操作に人の承認を入れる設計で詳しく説明しています。

参照の権限でも、範囲の絞り込みは欠かせません。顧客管理システムのすべての項目を見せる必要があるのか、業務に使う項目だけでよいのかを確認しましょう。たとえば報告書の下書きを作る業務なら、取引の履歴は必要でも、個人の連絡先までは必要ないかもしれません。

権限設計の進め方

権限の設計は、次の順番で進めると抜けが少なくなります。

最初に、AIに任せたい業務を一つ選び、その業務で使うシステムとデータを書き出します。業務の単位で考えると、必要な権限を具体的に決めやすくなるためです。複数の業務をまとめて検討すると、権限が広がりやすい点に注意してください。

次に、書き出したデータごとに、参照・作成・変更・削除のどれが必要かを決めます。迷った場合は、より狭い権限から始めるとよいでしょう。不足があれば、試した結果を見て追加できます。

最後に、権限の設定を誰が管理するかを決めます。システムごとに担当者が違う会社では、AIに関する権限の一覧を一か所にまとめておくと便利です。異動や退職があったときに、AIの権限も合わせて見直せるようにしておきます。

記録と見直しの運用

権限を設定したあとは、AIが行った操作を記録として残します。操作した日時と指示した人、対象のシステムと操作の内容が分かるようにしておくと安心です。記録があれば、問題が起きたときに原因を調べられます。利用の傾向を見て、権限が足りない業務や広すぎる設定に気づくこともできるでしょう。

権限は、一度決めたら終わりにしないことが大切です。業務の変化やシステムの追加に合わせて、定期的に棚卸しをしましょう。棚卸しとは、設定されている権限を一覧にして、今も必要かどうかを確認する作業です。使われていない権限は外しておくと、万一のときの影響を小さくできます。

顧客管理の情報から商談メモを作る例

架空の会社で、営業担当者が自分の担当顧客の商談履歴を読み、次回の訪問準備メモをAIで作るとします。AIに必要なのは、担当案件の履歴を読むことと、本人だけが確認できる下書きを保存することです。顧客の住所変更や、他の営業担当者の案件を見る権限は今回の処理に含めません。

権限を「営業システムにアクセス可」と一つにまとめず、利用者、対象データ、操作の組み合わせで決めます。次の表は、この業務を試す際の設計例です。

役職が上だから、すべての情報を参照できると決める必要はありません。実際の業務で必要な範囲を確認します。AI専用のアカウントを使う場合も、利用者が誰でも同じ広い権限を使える構成にしないことが重要です。

操作の直前に確認する条件

AIが「案件Aを変更したい」と提案しても、その提案を理由に権限を付与してはいけません。操作を受け付ける側が、実行者、対象の案件、要求された操作を確認する設計にします。画面からボタンを隠しただけでは、別の経路から実行される可能性が残ります。

OWASPは、初期状態では許可せず、要求ごとに権限を確認することを推奨しています。AIとの連携でも、どの操作を許可するかはアプリ側で確認します。OWASPの認可に関する指針

権限を確認できなかった場合は、操作を実行せず止めます。接続先の情報を取得できなかったから一時的に全件を許可する、といった動作にすると、確認の失敗がそのまま情報の露出につながります。利用者には、再試行すべきか管理者へ連絡すべきかを案内します。

公開前に確認する順番

まず、担当者本人が自分の案件を参照できることを確かめます。次に、他者の案件番号を指定した質問で、権限外の内容が返らないことを確認します。番号を直接指定した場合も、自然な文章で別案件の内容を求めた場合も試します。

その後、参照だけを許可したアカウントで変更を依頼し、実行されないことを確認します。AIが拒否の文章を表示するだけでなく、接続先のデータも変わっていないかを見ます。表示と実際の処理の両方を確認するためです。

最後に、担当者の変更とアカウント停止を試します。担当替え後に新しい案件を扱えること、以前の案件へアクセスできなくなることを同じ質問で確認します。反映に時間がかかる構成なら、その時間と暫定対応を運用手順へ残します。

権限の棚卸しで見る項目

定期点検では、設定された権限と実際に使われた操作を並べます。一度も使っていない書き込み権限、終了した試験用の接続、管理者不明のAI専用アカウントがあれば、必要性を確認します。

権限を減らす際も、処理が止まった場合の担当者を決めてから変更します。必要な権限がないという問い合わせを受けた場合は、業務と対象データを確認し、必要な部分だけを追加します。「動くまで管理者権限を付ける」という対応を日常化させないことが、最小権限を続けるうえで大切です。

まとめ

AIに社内システムを操作させるときは、AIに渡す権限で操作の範囲が決まります。AIを使う人の権限を超えない設計を基本にし、業務に必要な範囲だけを許可しましょう。操作を参照・作成・変更・削除に分け、参照から始めると安全に試せます。操作の記録と権限の棚卸しも、運用の中で続けていくことが必要です。

e-Grantsでは、社内データとの連携や権限・承認の設計を含めた、AIを使える社内インフラの構築を支援しています。AIに任せたい業務はあるものの、どこまで権限を渡してよいか迷っている場合は、AIを使える社内インフラの構築のページをご覧ください。