- 公開日
AIに仕事を任せるときは、「在庫を管理して」のような目的だけでなく、対象の倉庫や商品、許可する操作、そしてどの利用者がどこまで操作できるかという範囲を決めます。在庫数を読む権限があっても、数量を書き換える権限があるとは限りません。同じ依頼でも、利用者と実行システムの権限に応じて、回答までにとどめるか、更新の確認へ進むかを分けます。
この区別をAIへの指示だけに任せると、説明文では断っていても、ツールから更新できる状態が残ることがあります。依頼の解釈はAIに補助させ、許可の判定と操作の制限は、実際にデータへアクセスする仕組みでも行います。
対象・操作・範囲を一組で書く
対象は、扱うデータや資源です。操作は、その対象に対して何をするかを表します。範囲は、どの利用者、どの組織、どの期間、どの項目まで認めるかという境界です。例えば「在庫情報」だけでは広すぎますが、「東倉庫の担当商品について、現在数量を閲覧する」とすれば、確認する単位が見えます。
更新まで認める場合には、何を変更できるのかを追加します。「東倉庫の商品Aの棚卸結果を登録する」と「全倉庫の在庫を一括で補正する」は、どちらも更新でも影響範囲が異なります。便利だからという理由で、後者の権限を前者へ渡す必要はありません。
NISTの最小権限の定義は、割り当てられた業務に必要な最小限のアクセス権限へ絞る考え方です。AIの利用でも、何でもできる共通アカウントを用意する前に、業務に必要な対象と操作を明らかにする判断に使えます。least privilege
ここで基準にする権限は、AIに「在庫の専門家として答えて」と役割を与えることで生まれるものではありません。社内の担当者やシステム上の利用者に、実際に付与されている権限です。会話の中で利用者が管理者を名乗っても、認証された利用者の権限はそれによって変わらないように設計します。
同じ依頼でも、閲覧者と更新者では結果が違う
架空の在庫システムを考えます。東倉庫の商品Aは、システム上の数量が十二個です。担当者が「棚卸では十個でした。商品Aを確認して、十個に直して」とAIへ依頼したとします。ここでの数値、利用者、権限は説明用の仮定であり、操作は実行していません。
利用者甲には、東倉庫の在庫を閲覧する権限だけがあるとします。AIは認められた範囲で現在数量を読み、「登録値は十二個です。十個への変更は更新権限がないため実行していません」と返すのが期待する動作です。利用者が申告した十個は棚卸結果として提示された値で、AIが現物を数えた結果ではありません。
このとき、変更内容の下書きを返すことは、許可された用途なら可能です。「対象：東倉庫の商品A、変更案：十二個から十個、根拠：利用者の棚卸申告」と整理し、定められた申請先へ渡せる形にします。ただし、その申請自体を外部へ送る機能があるなら、送信の許可は別に必要です。更新できない代わりに、別の経路で勝手に変更を依頼してよいわけではありません。
利用者乙には、同じ商品を更新する権限があるとします。それでも、依頼だけで直ちに更新するのではなく、対象の特定、棚卸記録の確認、業務で定めた承認の有無を確認します。必要条件が揃えば実行に進めますが、権限があることと、今回の変更内容が正しいことは同じではありません。
権限、依頼、承認を混ぜない
認証は誰がアクセスしているかを確かめること、認可はその主体に何を許すかを判断することです。利用者の依頼は今回行ってほしい仕事を示し、承認は定めた手順に沿って具体的な操作を許可する判断です。更新権限者でも、照会しか頼んでいないなら更新を始める理由はありません。
逆に、閲覧権限者が「責任は私が取るので直して」と言っても、会話上の強い同意によってシステム上の権限不足を埋めません。権限の変更が必要なら、組織で定めた申請と承認へ戻します。AIが別のアカウントを使ったり、権限の広いツールへ切り替えたりして、拒否された操作を通す設計は避けます。
OWASPの認可ガイドは、原則拒否と、各リクエストでの権限検証を推奨しています。会話の開始時に一度確認するだけでは、対象や権限が途中で変わる場合を扱えません。実際に読む・書く要求のたびに、対象と操作が許可範囲に収まるかを確認する考え方です。Authorization Cheat Sheet
例えば、東倉庫で許可されているからといって、西倉庫にも同じ権限があるとは限りません。商品名が似ているときも、AIがそれらしい候補を選ぶだけでは足りません。正しい倉庫と商品識別子を確かめ、その対象について認可を受ける必要があります。
範囲外と未確認では、止める理由を分ける
「全倉庫の商品をまとめて出して」という依頼が来ても、東倉庫だけに権限があるなら、許可された範囲の情報だけを扱います。他倉庫の実データを一度読んでから回答から削る方法では、取得の段階で境界を越えてしまいます。検索やデータ取得の前に対象を制限し、許可されない情報をモデルへ渡さない設計にします。
一方、商品Aがどの倉庫のものか不明な場合は、権限違反だと決め付けるのではなく、対象未確認として必要な質問をします。認可サービスが応答しない場合も、許可が確認できない状態です。「拒否が返らなかったから実行する」とはせず、その操作を保留し、認可サービスから判定を得られる状態に戻ってから改めて評価します。
利用者への説明は、止めた操作と続けられる作業を分けます。「数量の変更は保留しています。東倉庫の商品Aについて、閲覧が許可されている登録値の確認はできます」といった形なら、業務全体を止めずに済む場合があります。ただし、許可されていない対象の存在や件数まで説明へ漏らさないようにします。
拒否された要求を、表現を変えて何度も試す必要はありません。対象を誤ったなら正しい対象を確認し、権限が足りないなら管理者の手続へ引き継ぎます。何を変えれば再開できるかを示し、権限が変わったと確認できた後で、改めて今回の要求を評価します。
更新を伴うときに追加する確認
閲覧だけなら、更新承認や変更の取り消し処理は通常の照会には不要です。ただし、読み取る情報の範囲と、回答を見せてよい相手の確認は残ります。「読み取り専用だから情報管理は不要」という簡略化はできません。
更新では、実行直前の値が確認時と一致するかも問題になります。十二個を見ている間に別の入出庫で数量が変わっていたら、古い情報のまま十個に上書きするべきではありません。対象システムの版番号などで状態を照合し、不一致なら更新案を見直します。これは権限の問題に加え、業務データの整合性を守るための条件です。
また、更新要求の応答が返らないときは、成功とも失敗とも確定できません。要求の記録や現在状態を確認し、変更済みか不明なまま再送しない手順を用意します。権限が正しくても、二重実行や誤った成功報告は別に起こり得るためです。
導入時には、架空データを使って、閲覧のみ、許可された更新、別倉庫への要求、認可未確認の四つを点検できます。表示だけでなく、許可されない取得や更新が実際に発生していないかをログで確かめます。意図どおり止まらなければ、利用者への注意書きを増やすだけでなく、アクセス経路の制限へ戻って修正します。
範囲を決めるときの確認表
ここまでの判断を、AIへ仕事を任せる前に一度表へ書き出しておくと、抜けている項目が見つけやすくなります。次は在庫照会の例で埋めたものです。項目は業務に合わせて増減してかまいませんが、「記録」まで決めておくと、止まった操作や許可した操作を後から確かめられます。
| 決める項目 | 決める内容 | 在庫照会の例 |
|---|---|---|
| 対象 | 扱うデータや資源の単位 | 東倉庫の担当商品（商品識別子で特定） |
| 操作 | 閲覧・登録・変更・削除のどれを許すか | 甲は閲覧のみ、乙は棚卸結果の登録まで |
| 利用者と範囲 | 誰に、どの組織・期間・項目まで認めるか | 認証された利用者ごとの付与権限に従う。会話上の自己申告では変えない |
| 範囲外の扱い | 止める操作と、続けられる作業・案内先 | 更新は保留し、閲覧できる登録値と変更案の下書きは返す。権限の変更は管理者の手続へ |
| 記録 | 何を残して後から確かめるか | 利用者、対象、要求した操作、判定、時刻 |
対象、操作、範囲を明示しておくと、AIが「できません」と返したときにも、どの境界で止まったのかを利用者へ説明できます。依頼の理解はAIに、許可の判定と強制はデータへアクセスする仕組みに担わせ、確認できた範囲だけで作業を進めるところから権限制御を組み立てます。
AIがアクセスできる情報と、アクセスしてよい情報の区別は「AIがアクセスできる情報と、アクセスしてよい情報は別」で解説しています。
AIエージェントの認証・認可・委任の基本は「AIは誰の権限で動くのか 認証・認可・委任の基本」で解説しています。
AIを使う前に確かめる12項目は「AIを使う前の安全確認チェックリスト」にまとめ、記入用のAIKYシート（PDF・Excel）も配布しています。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
