AI Agent が企業サービスにログインし、データを照会してフォームへ入力し、さらには注文まで送信できるようになると、アカウントがログイン可能かどうかを確認するだけでは不十分です。管理者は、この AI Agent が誰を代理しているのか、どのデータを閲覧できるのか、どの操作を直接実行できるのか、そして問題発生後に各ステップを追跡できるのかを把握する必要があります。
企業が管理すべき対象は、入口での本人認証だけではありません。AI Agent を開放する前に、役割、データ、操作範囲を権限マトリクスとして整理し、リスクのあるステップには人による承認を設定するとともに、情報セキュリティ部門や監査部門が追跡できる記録を残すことを推奨します。いずれか一つでも欠けていれば、システムが権限外の操作を阻止できず、事後の責任所在も確認しにくくなる可能性があります。
まず AI Agent が誰を代理しているのかを確認し、閲覧可能な情報を決める
Sierra は現在、Meta、Walmart、Shopify、Stripe などの企業と共同で、個人向け AI Agent プロトコル（Personal Agent Protocol）を開発しています。iThome の報道によると、この仕組みは本人認証、ユーザーによる権限付与、企業による管理を一体化し、企業が訪問者を「人間」「権限を付与された AI Agent」「許可されていない自動化プログラム」のいずれかとして識別できるようにすることを目指しています。企業側は、どのサービスを開放するか、また AI Agent が Web サイト、API、あるいは企業独自の AI Agent のどの経路を通じて業務を遂行するかも決定できます。
このプロトコルは今月後半に v0.1 仕様が公開される予定ですが、より詳細な操作権限、プッシュ通知、決済については今後の計画とされています。そのため企業は現時点で、まだ公開されていない標準を完成済みの解決策として扱うべきではありません。ただし、報道で取り上げられている問題は、すでに Web サイトやシステムの入口で発生しています。AI Agent は人間と同じようにページを読み込み、ボタンをクリックしてフォームへ入力できますが、企業側では誰から委任されたのかを把握できない場合があります。また、ログインに成功したという事実だけで、すべての操作について同意が得られていると判断することもできません。
企業は、まず権限マトリクスを作成できます。各行には営業、購買、カスタマーサービス、部門管理者、システム管理者など、社内の実際の役割を割り当てます。各列には、利用可能な AI Agent の機能、読み取り可能なデータ範囲、書き込み可能なシステム、明確に禁止する操作を設定します。営業担当者が自身の担当顧客に関する過去の見積もりを参照できるからといって、ほかの事業部門の粗利益データまで閲覧できるとは限りません。カスタマーサービス担当者が返金案を作成できるからといって、AI Agent が返金を直接承認できるわけでもありません。
EgentWrX では、組織構造に応じて階層別に権限を設定できます。ユーザーが部門範囲の権限しか持っていない場合、閲覧できるのは所属部門とその下位部門のみです。導入チームは、まず権限マトリクスを完成させ、共有アカウント、範囲が広すぎる権限、退職者から未回収の権限を洗い出したうえで、どのデータと機能を開放するのが適切かを判断する必要があります。その後、IT 部門、データ責任者、業務部門が共同で承認し、単一の部門がデータ所有者に代わって判断することを避けます。
書き込み権限は操作ごとに分け、一括で許可しない
読み取り専用と書き込み可能という区分は出発点にはなりますが、企業プロセスにおけるリスクを表すには不十分です。購買 AI Agent が価格比較の結果を下書きに書き込む、発注書を上長へ提出する、注文を正式に送信するという三つのステップは、いずれもシステム内のデータを変更しますが、その影響は異なります。同様に、営業 AI Agent による顧客連絡先情報の更新、見積条件の変更、正式な見積書の送付についても、同じ許可条件を適用すべきではありません。
各プロセスのステップを「自動実行可」「実行前に承認が必要」「実行禁止」のいずれかに分類することを推奨します。一般公開されている返品ポリシーの照会や、ユーザーが閲覧権限を持つデータの整理は、自動実行可に分類できます。一方、金銭、社外への確約、データの削除、条件が曖昧な作業、部門の基準値を超える作業については、処理を停止し、指定された管理者の確認を待つ必要があります。企業内に明確な基準値がまだない場合は、社外への送信や重要システムへの書き込みを承認必須とする方が、最初から開放して後から対処するよりも安全です。
承認画面も、管理者が内容を理解できるように設計し、「承認」ボタンだけを表示してはなりません。管理者が実行を許可するかどうか判断するには、少なくとも AI Agent が実行しようとしている操作、データソース、変更前後の差分、影響を受ける対象を確認できる必要があります。カスタマーサービスでの返金を例にすると、承認者は注文、返金理由、金額、送信予定の回答を確認できなければなりません。購買での発注であれば、仕入先、品目、条件、合計金額を確認する必要があります。
EgentWrX のワークフローでは、次の担当へ引き継ぐ前に人による承認を必要とする設定が可能です。前のステージが完了すると、プロセスは停止し、担当者による承認を待ちます。企業はまず、範囲が明確で、すでに責任者が決まっているプロセスを一つ選び、各操作をこの三つに分類するべきです。そのうえで、承認者が内容を理解できるか、却下できるか、却下後の作業を誰に戻すかを実際にテストし、AI Agent が実行できる範囲を段階的に拡大します。
開放する前に、事後の追跡が可能か確認する
事前の権限付与で確認できるのは、AI Agent が本来何を実行できるかという点に限られます。企業はさらに、AI Agent が実際に何を行ったのかを確認できなければなりません。最低限の監査チェックリストには、ユーザー、AI Agent、実行時刻、使用したデータの範囲、呼び出したサービス、操作結果、承認者を含める必要があります。ワークフローが Web サイト、API、企業独自の AI Agent をまたぐ場合、これらの経路では同一の本人情報と権限情報を使用することが望まれます。そうしなければ、同じ業務に関する記録が分断され、相互に関連付けられなくなります。
監査ログも、インシデントが発生してから初めて確認するようでは不十分です。情報セキュリティ部門と監査部門は、短時間での大量データ読み取り、所属外の部門へのアクセス試行、管理者による却下後の再申請、社外へ送信した内容と承認済みバージョンとの相違など、複数の高リスク事象をあらかじめ選定できます。そのうえで、誰が通知を受け取り、誰が記録を確認し、誰がアカウントまたはプロセスの停止を決定するのかを定めます。EgentWrX は、検索およびエクスポートが可能な監査ログを提供しており、記録の完全性を検証できます。管理者が監査記録をダウンロードした操作自体も記録されます。
本番稼働前に、情報セキュリティ部門、監査部門、プロセス責任者は、テストタスクの結果から遡って調査し、実行者、権限付与元、データ範囲、承認記録を特定できるか確認してください。また、権限を取り消した後も、既存の作業セッションから引き続き操作できないかを確認する必要があります。導入チームは、記録が不完全な項目を補完し、権限取り消し後も実行を継続できる経路を閉じてから、本番データを開放します。
よくある質問
企業は、どのような AI Agent の権限から棚卸しを始めるべきですか？
まず、社内データの読み取り、システムへの書き込み、社外へのコンテンツ送信を行うプロセスを棚卸しします。ユーザーの役割、データ範囲、実行可能な操作、禁止事項を一つの権限マトリクスにまとめ、IT 部門、データ責任者、業務部門が共同で承認します。
AI Agent が従業員のアカウントでログインしている場合でも、別途管理が必要ですか？
必要です。ログインで証明できるのはアカウントの本人性だけであり、AI Agent がどの業務を委任されているのかまでは確認できないためです。企業は、読み取り可能なデータ、呼び出し可能なサービス、実行可能な操作を制限し、権限を取り消せるようにするとともに、その記録を残す必要があります。
どのような AI Agent の操作に管理者の承認が必要ですか？
金銭、社外への確約、重要データの削除や変更、条件が曖昧な操作には、優先的に承認ポイントを設定するべきです。管理者は承認前に、データソース、変更内容、影響を受ける対象を確認できる必要があり、単一の承認ボタンだけを表示してはなりません。
監査ログには最低限どのような情報を記録する必要がありますか？
少なくとも、ユーザー、AI Agent、実行時刻、データ範囲、呼び出したサービス、操作結果、承認者を記録する必要があります。また企業は、定期的な抜き取り確認と異常時の追跡手順をあらかじめ定め、Web サイトと API にまたがる記録を同一のタスクに関連付けられることを確認する必要があります。
参考資料
- Sierra と Meta が Personal Agent Protocol を推進、AI Agent による企業サービスへのアクセスを標準化 — iThome の陳曉莉記者が、プロトコルの開発背景、運用方針、今後の計画について報じています。