セキュリティ
📅 2026-10-06 ⏱️ 8分 Dean Dean

AIエージェントのID・権限・監査ログ:承認と実行結果を追う記録の作り方

依頼者、実行主体、認証情報の参照先、権限、承認、実際の結果を結び付ける記録例を紹介。Entraの証跡と業務操作を照合し、成功・拒否・承認待ち・部分失敗を分けて確認します。

スマートフォンの周囲に盾と確認マーク、利用者の表示、権限の切り替え、操作を示す図柄を配した概念イラスト
📋 要点
  • 操作記録は、主体、認証情報の参照先、許可範囲、承認、実行の証跡の五項目で整理します。依頼者・実行主体・承認者を分け、秘密情報を複製せず対象と結果への参照を残します。
  • Microsoft Entraの委任権限とアプリケーション権限は別の仕組みです。対象リソースに必要な範囲を選び、接続への同意と個別の書き込み承認を区別します。
  • サインイン成功や承認済みという記録だけでは作業完了を証明できません。成功、拒否、承認待ち、結果未確定を分け、下流アプリの実際の状態と照合します。
  • FoneClawの電池状態の読み取りと予定作成にも同じ確認方法を使えます。アクセスの取り消しは過去の書き込みを元に戻す操作ではなく、再試行前には保存先を確認します。

あとから追える五つの項目を記録する

AIエージェントのID・権限・監査ログを整理するなら、まず一件の依頼から実際の結果までを追える記録にします。誰が依頼し、どの主体が、どの接続と権限で、何を試みたか。さらに、誰が承認し、対象に何が反映されたかを分けて残します。

以下は、読者が手作業で記録を作るための架空例です。実在するログ画面やFoneClawの出力形式ではありません。「指定された業務文書を読み、返信案だけ作る」という依頼なら、次の五項目をたどれる形にします。

項目記録例
主体依頼者:佐藤さん。実行主体:業務用エージェントA。表示名と操作に使うIDを区別する
認証情報の参照先限定接続「業務文書・閲覧用」への参照。トークンそのものは記録しない
許可範囲指定文書の閲覧と返信案の作成。文書変更とメール送信は含めない
承認承認者:文書の管理者。対象、目的、判断、判断時刻を残す
実行の証跡依頼ID、操作ID、日時、対象への参照、試行、結果、確認した証拠への参照

たとえば依頼IDをREQ-001とし、文書閲覧をACT-001、返信案作成をACT-002として分けます。これは説明用に付けた番号です。利用サービスが相関IDや操作IDを返す場合は、それも対応付けます。返信案への参照があっても、文書閲覧の証拠がなければ、その文書を実際に使ったかは未確認と残します。

依頼者は作業を求めた人、実行主体は外部サービスへアクセスしたID、承認者はその操作を判断した人です。同じ人が複数の役割を担う場合も、役割は区別します。チャット上のエージェント名やAPIキーだけでは、所有者、責任範囲、権限の見直しまで管理できません。

記録には秘密のトークンや文書全文を複製せず、必要な担当者だけが対象と結果をたどれる参照を残します。承認済みでも未実行、実行を試みても結果不明という状態があるため、承認と結果を一つの「完了」欄へまとめないことが重要です。

企業の実行主体と権限範囲を決める

企業のAIエージェントでは、誰が依頼し、どのIDが外部サービスにアクセスするかを先に決めます。MicrosoftのEntra Agent IDの認可に関する説明では、利用者の代理で行う委任アクセスと、管理者が許可するアプリケーション権限が区別されています。前者は利用者を代理するアクセス、後者は利用者の操作とは別にアプリのIDで行うアクセスです。

この区別はEntraの仕組みに関するもので、すべてのAIエージェントが同じ認可方式を備えるという意味ではありません。エージェントIDには高い権限を持つロールやAPI権限の制限もあります。必要な操作が許されるかは、対象サービスと権限の仕様に沿って確認します。

一件の文書を読むなら、対象文書への閲覧に必要な範囲を選びます。広い書き込み権限や管理者権限を与える必要はありません。Azureのリソースロール、ディレクトリロール、Microsoft Graphの権限は対象が異なるため、「管理者だから使えるはず」ではなく、操作する資源に合う権限かを見ます。

管理者がアプリケーション権限を許可したことやOAuth接続に同意したことと、個々のメール送信や文書変更を承認したことは別です。閲覧だけを頼んだのに送信を試みたなら、今回の依頼範囲から外れた操作として扱います。業務の承認者、エージェントの所有者や管理責任者、必要に応じた有効期限を記録し、担当変更時に接続を継続するか取り消すか判断します。

企業導入全体の評価項目は、企業向けAIエージェント セキュリティ:スマホ上で動くエージェントをどう評価するかで確認できます。保存期間や担当者の役割は、組織の実際の方針に合わせて決めてください。

サインインの証跡と操作結果を照合する

MicrosoftのEntraのエージェント向けサインイン・監査ログの案内では、agentTypeやblueprintIdを使って関連する主体や設定をたどれます。ブループリントの活動はアプリケーションのイベント、エージェントIDはサービスプリンシパルのイベント、エージェントの利用者アカウントは利用者のイベントとして現れます。

少なくともReports Readerの権限を持つ担当者は、Entra IDの「監視と正常性」にあるサインインログでエージェントを絞って確認できます。Microsoft Graphからのエージェント関連ログの照会は、案内されている経路が/betaである点も確認してください。

サインイン成功は実行主体がアクセスした手掛かりですが、指定文書の閲覧、編集、送信の相手や内容までは証明できません。次の順序で、ID側の証跡と対象アプリ側の記録を照合します。

  1. 依頼IDと操作IDを確認し、対象の作業を特定します。
  2. 実行主体、接続先、対象リソース、時刻をID側のイベントと照合します。
  3. 対象アプリに閲覧や変更の記録があるかを確認します。
  4. 返信案、保存された文書、送信結果など、依頼した成果への参照を残します。
  5. 確認できない項目は「未確認」とし、承認やサインイン成功から補完しません。

依頼IDが両方のサービスへ渡されていない場合は、時刻、主体、対象を使って照合する候補を探せます。ただし、近い時刻のイベントだけで同じ操作と断定せず、対応付けの根拠も残します。ログが見つからない時は、権限、保持範囲、記録対象を調べ、見つからないことだけで未実行とも成功とも判断しません。

監査イベントがあるだけで下流の全操作が記録されたり、記録が改ざん不能になったりするわけではありません。追加したスキルによって操作範囲が変わる場合は、AIエージェントのスキル安全性:スマホ権限は実行時に確認すべき理由で、実行時の確認事項を整理できます。

成功・拒否・承認待ち・部分失敗を分けて残す

次の四つは、結果欄の書き方を具体化した提案例です。実際に観測した結果ではありません。許可された範囲、試みた操作、観測した結果をそれぞれ残すと、次に何を確認すべきか判断できます。

状態記録する内容の例次の確認
読み取り成功指定文書の閲覧範囲でアクセス。対象アプリの閲覧記録と返信案への参照を確認。変更と送信は依頼範囲外依頼者が返信案を確認できるか。閲覧以外の操作を試みていないか
書き込みの承認待ち予定作成案の対象と日時を提示。承認判断は未完了。作成ツールの実行はまだ確認していない承認者の判断を待つ。承認された後も実行結果を別に確認する
操作拒否依頼範囲外の文書変更を求められ、操作が拒否された。対象を照合し、確認した範囲では変更なし必要なら依頼範囲を見直す。拒否を回避するために権限を広げない
部分失敗・結果未確定文書閲覧は確認済み。後続の予定作成は実行を試みたが、応答が途切れ、保存結果は未確認保存先を調べるまで作成を繰り返さない

読み取り成功の例でも、返信案が提示されたことだけでは対象文書の閲覧を証明できません。逆に、文書を読めたことだけでは返信案の作成まで完了したとは言えません。操作を分けて記録すれば、確認済みの部分だけを残せます。

承認待ちの記録では、判断を求めている操作と対象を明確にします。「承認された」と「実行された」は別の状態です。拒否の場合も、拒否表示を見ただけで対象が必ず無変更と断定せず、確認した時刻と範囲を添えます。

部分失敗では、「失敗」とだけ書くと再試行で重複を作るおそれがあります。「閲覧は完了、作成結果は未確認」と分け、保存先を確認します。予定が見つかればその結果を追記し、見つからない場合も対象カレンダーや日時を照合してから再試行を判断してください。

スマホの操作にも同じ問いを当てる

私たちのFoneClawで「今の電池残量と省電力状態を教えて」と頼む場合も、五つの問いを使えます。依頼した本人、モデルの接続設定、操作の有効化、実際の承認設定、端末から返った値を確認します。これを利用者が手作業でまとめることはできますが、企業向けの改ざん不能な監査ログやEntra連携として出力する形式ではありません。

device_battery_statusは、電池と省電力状態を取得する読み取り専用の操作です。設定は変えません。既定の承認扱いは自動ですが、実際の動作は全体の承認モードとツールごとの設定に沿います。記録には、取得した時刻、返された値、設定変更を含めない依頼だったことを残せます。時間とともに電池残量が変わるため、後から見た値との差だけで取得失敗とは判断しません。

一方、calendar_create_eventは予定を書き込む操作で、既定では承認を求める扱いです。足りない日付、開始・終了時刻、通知の指定を確認してから実行します。たとえば「10月8日の14時から14時30分まで、打ち合わせ。通知は10分前」と依頼する場合は、年、端末のタイムゾーン、対象カレンダーも必要に応じて確認します。未指定の時間や通知を推測で埋めないでください。

作成後は、ツールが返すactualStartとactualEndを実際の作成時刻として確認し、カレンダー側で予定名、開始・終了、通知を照合します。意図した時刻と違うなら、作成済みの予定を確認してから修正を判断します。「作成しました」という返答だけで確認を終えないことが大切です。

Androidの権限、FoneClaw内で有効にしたツール、モデル提供者の認証情報、承認設定は別の管理対象です。オンラインモデルへ渡した文脈の処理も、端末上の操作結果だけからは分かりません。対応機能はFoneClawの機能一覧で確認できます。

拒否を確かめ、不要な権限を取り消す

権限を見直したら、影響の小さい操作で拒否の動作を確認します。たとえば電池状態の読み取りツールを一時的に無効にし、同じ読み取りを依頼する確認方法があります。変更前の設定を控え、対象ツールが実行されずに止まるかを見てください。古い会話の値やモデルの推測を、新しく取得した結果として扱わないことも確認します。

記録には「無効にした項目」「依頼した操作」「表示された拒否や停止」「新しい取得結果を確認できたか」を残します。ツール名を含む返答だけでは実行の証拠にはなりません。必要な操作だけを再び有効にし、元の承認設定へ戻して、読み取り結果を確認します。これは読者向けの提案で、特定環境で確認済みの試験結果ではありません。

使われなくなったエージェントID、接続、端末権限は、それぞれの管理画面と組織の手順で取り消します。漏えいが疑われる認証情報は更新し、不要な承認の上書き設定も見直します。取り消した範囲と時刻を記録し、既存セッションなどの扱いは接続先の仕様に従って確認してください。

アクセスの取り消しは、すでに保存した予定や送信したメールを元に戻す操作ではありません。書き込みが途中で失敗した場合は、まず対象アプリの状態を確認し、必要なら別の修正・取り消し操作として判断します。結果が不明なまま全タスクを再実行しないでください。

記録の閲覧者、保存先、保持期間も、自分や組織の方針に沿って管理します。保存された情報が後の判断に影響する場合は、AIエージェントのメモリーポイズニング対策:スマホでAsk AIと保存メモリーを確認するで、その内容自体を見直す方法を確認できます。