- 公開日
AIが外部システムへ接続するときは、利用者の代理として動くのか、アプリケーション自身の権限で動くのかを、要求ごとに確定します。接続に使ったアカウントの広い権限を、そのまま依頼者の権限とみなしてはいけません。依頼者、実行主体、対象組織、操作、回答先を対応させ、主体を確認できない要求は実行に進めない構成にします。
ここでいう「固定」は、全員を同じアカウントへまとめる意味ではありません。一つの要求が検索、取得、回答へ進む途中で、別の利用者や管理者の主体へすり替わらないようにすることです。
この記事は、AIの実行主体を固定する応用を扱います。認証・認可・委任の基本は「AIは誰の権限で動くのか 認証・認可・委任の基本」で先に確認できます。
利用者の代理と、アプリケーション自身の操作を分ける
サービスアカウントは、プログラムやサービスが処理するために用意するアカウントです。人のログインがない定期処理などに使えますが、人が依頼する処理の権限確認まで自動的に担うものではありません。実行先が利用者別の権限を検査できるなら、その仕組みを使う設計を検討します。
具体例として、Microsoft Graphの認証・認可の説明では、サインインした利用者の代理としてアクセスするdelegated accessと、アプリ自身の識別情報でアクセスするapp-only accessが区別されています。前者は利用者とアプリの両方の認可が必要です。これは2026年10月12日に確認したMicrosoftの方式であり、名称だけを他のAPIへ当てはめず、それぞれの認証方式と権限の仕様を確認します。
Microsoftのapp-only accessの説明も、アプリ自身のアクセスは一人の利用者の権利だけに制限されるものではないとしています。したがって、利用者の要求を受けた後で、接続用アプリが読める全資料を検索して回答する構成では、利用者との対応を別に検査する必要があります。
| 処理の種類 | 主体を決める考え方 | 確認する境界 |
|---|---|---|
| 利用者が自分の資料を検索 | 利用者の代理として実行する方式を検討 | アプリに許された操作と、利用者が読める対象 |
| 組織が認めた定期集計 | 専用の実行主体と対象範囲を定義 | サービス主体の権限、処理目的、結果の受領者 |
| 広い権限の接続しか使えない検索 | 利用者別認可を強制できる設計か先に確認 | 取得前の許可判定と、回答・ログまでの制限 |
利用者別の認可ができない場合に、「AIへ秘密を出さないよう頼む」だけで代替しません。接続先を限定する、利用可能な資料を絞る、当該用途を提供しないなど、データを取得する手前の構成を見直します。
共有チャットの二人を、同じ利用者として扱わない
架空の社内チャットで、社員Aと社員Bがそれぞれ「案件Xの見積書を要約して」と依頼する場面を考えます。Aには案件Xの見積書の閲覧権限があり、Bにはありません。AIアプリの接続用アカウントは複数案件へアクセスできるとします。チャットの会話は同じでも、二人の認可結果は異なります。
システムは、チャット基盤が検証した送信者の識別情報を受け取り、その組織内での現在の利用者と対応させます。メッセージ本文に書かれた名前、表示名、AIが推測した発言者を、この対応の根拠にはしません。対応表が見つからない場合は、Aの直前の接続状態を流用せず、その要求を停止します。
Aの要求では、対象と操作がAの権限内であることを確認してから見積書を取得し、要約します。Bの同じ要求では、接続用アカウントが取得できても、Bに返すための取得・利用を許可しません。拒否の応答には、権限外の金額や文書名など、存在を含めて開示が制限される情報を不用意に追加しない設計にします。
さらに、Aが読めることと、回答を共有チャットへ投稿してよいことは別です。Bもそのチャットを見られるなら、A向けの要約をそのまま投稿すると情報が渡ってしまいます。この例では、権限を確かめたAの専用の閲覧経路に結果を返すか、全員が見られる内容だけに限定します。回答先を変えるために必要な許可やユーザーへの説明も、連携の設計に含めます。
要求の受け渡しで保持する情報
主体を固定するには、ツールへ「社員Aとして検索して」という自然言語だけを渡す方法を避けます。認証済みの情報からシステム側で作った文脈を、要求と結び付けます。次は独自の連携設計で保持する項目の例であり、特定APIの必須フィールド一覧ではありません。
- 要求を識別するID
- 検証された依頼者の識別情報と、その識別元
- 実際の接続主体と、利用者代理・アプリ自身などの実行方式
- 対象組織と対象資料、許可する操作
- 判断に使用した権限情報やポリシーの版
- 委任がある場合の識別情報、範囲、期限
- 結果を返す相手と経路
識別子は、発行元や組織との組合せで解釈します。異なる組織で同じ文字列の利用者IDがあり得る構成なら、利用者IDだけで対応させません。また、AIがツール引数の利用者IDを書き換えても、接続主体や認可対象を変更できないようにします。
OWASPのマルチテナント設計指針は、テナント文脈を信頼できる主体に結び付け、キャッシュやセッションでも分離する考え方を示しています。要求の途中で文脈が欠けた場合に、前回の利用者や既定の管理者を補って進む構成は避けます。主体が未確認なら、そのことを示して接続の確認へ戻します。
実行記録は、アカウント名だけで終わらせない
監査ログに「検索サービスが実行」とだけ残ると、AとBのどちらの要求だったかを説明できません。一方、ログに全文の見積書や資格情報を残せば、ログ自体が別の漏えい経路になります。何をどこまで残すかはリスクと運用目的に合わせ、必要な識別情報と判断結果を記録します。
架空例の記録は、次のように比較できます。
| 要求 | 依頼者と実行主体 | 認可・出力の結果 |
|---|---|---|
| Aによる案件Xの検索 | 依頼者A、検索サービス主体、組織T | Aの閲覧を確認。共有チャットへの掲載はせず、認められた回答経路へ |
| Bによる同じ検索 | 依頼者B、検索サービス主体、組織T | Bの閲覧権限なし。対象内容を返さず拒否 |
| 発言者との対応が欠けた検索 | 依頼者未確認、接続主体のみ既知 | 実行前に停止。主体の対応を調査 |
| 途中で別主体へ変わった検索 | 開始時と実行時の主体が不一致 | 不一致として停止し、結果の返却を保留 |
記録には実際の日時と相関用IDを付け、外部システムの操作記録と照合できるようにします。拒否された要求も、禁止情報を複製しない範囲で判断理由を残します。認可を通したが検索自体は失敗した場合には、認可成功と処理成功を別に記録します。
共有する管理者パスワードを、連携の土台にしない
複数の担当者が一つの人用管理者アカウントを共有し、AIにもその資格情報を使わせると、依頼者や操作した主体を区別しにくくなります。担当変更時の失効も、他の利用者へ影響しやすくなります。利用者の資格情報を共有チャットやプロンプトへ貼り、AIにログイン主体を選ばせる設計にはしません。
専用のサービス主体を使うこと自体と、複数人が人用アカウントの資格情報を共有することは異なります。サービス主体を使う場合も、資格情報はシステムの保護された管理機構で扱い、権限を用途に絞ります。処理の依頼者との対応を維持し、そのサービスが取得できる範囲を全利用者の閲覧範囲にしないことが必要です。
運用負担として、利用者対応、権限変更、接続主体、回答先の管理が増えます。管理を簡単にするために主体の区別をなくすのではなく、利用者ごとの代理方式を標準化する、利用用途別にサービス主体を分けるなど、責任範囲を明確にできる方式を選びます。
導入前には、同じ質問を権限の異なる二人から送る試験に加え、主体欠落、同名の別利用者、組織違い、セッション切替、キャッシュ再利用を確認します。試験は架空資料と許可された環境で行い、正当な要求が使えることと、権限外の要求が取得・回答まで進まないことを分けて記録します。本稿の例は未実行であり、実際の接続方式と認可結果はその環境で確かめる必要があります。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
