生成AI 監査ログと管理者権限の比較 統制できるベンダーを見分ける方法

生成AIを複数ベンダーで併用する企業が増えているが、統制設計の実務では「管理者が何を見られるか」「どこまで止められるか」がベンダーごとに大きく異なる。特に監査ログの取得可否と管理者権限の範囲は、統制の成立条件そのものである。この記事では、主要な生成AIサービスにおける監査ログと管理者権限の違いを技術的に比較し、統制可能なベンダーとそうでないベンダーを見分ける基準を示す。

生成AI 監査ログと管理者権限がなぜ統制の成立条件なのか

企業が生成AIを統制するとは、利用の事実を記録し、リスクの高い操作を事前または事後に検知し、必要に応じて止める仕組みを置くことを指す。この仕組みが成立するには、管理者が「誰が・いつ・何をしたか」を見られる監査ログと、利用者の操作に介入できる管理者権限の両方が必要になる。

監査ログがなければ、利用の事実そのものが記録に残らない。管理者権限がなければ、リスクを検知しても止める手段を持たない。この2つが揃って初めて、統制は技術的に成立する。逆に言えば、どちらか一方でも欠けていれば、その生成AIサービスは「統制できない前提で運用する」という判断を迫られる。

ベンダーごとに提供する機能の粒度が異なるため、同じ「Enterprise プラン」でも取得できるログの項目や管理者の操作範囲は一致しない。統制設計の実務では、この違いを技術仕様の次元で把握し、統制可能なベンダーとそうでないベンダーを分類することが最初の判断になる。

監査ログで取得できる項目の違い ベンダー別の比較表

監査ログとして記録される項目は、ベンダーが提供するエンタープライズ向けプランの設計思想に依存する。以下、主要な生成AIサービスで取得可能な監査ログの範囲を比較する。

この表から、Microsoft・Google・OpenAIは管理者向けの監査ログ機能を標準で備えているが、Anthropicは現時点でコンソール経由の対話ログを取得する仕組みを提供していないことがわかる。統制設計の実務では、この差が「統制可能」と「統制不可」の境界線になる。

管理者権限の範囲 何ができて何ができないか

監査ログが取得できても、管理者が利用者の操作に介入できなければ統制は成立しない。管理者権限として実際に行使できる操作の範囲は、ベンダーごとに以下のように異なる。

Microsoft Copilot for Microsoft 365

• ライセンスの割り当て・剥奪（個別ユーザー単位またはグループ単位）
• 利用可能なアプリの制限（Word/Excel等の範囲を絞る）
• データ損失防止（DLP）ポリシーの適用（機密ラベルの付いたファイルへのアクセス制御）
• 外部共有の許可・禁止
• Purview による監査ログの取得と保存期間の設定

Microsoft の管理者権限は、Microsoft 365 Copilot 導入とオンボード ガイド（IT管理者向け） に詳述されている通り、既存の Microsoft 365 テナント管理の延長として設計されている。そのため、他のベンダーに比べて管理者が操作できる範囲は広い。

Google Gemini for Google Workspace

• ライセンスの割り当て・剥奪（ユーザー単位またはOU単位）
• 利用可能なアプリの制限（Gmail/Docs等の範囲を絞る）
• 外部共有の許可・禁止
• 監査ログの取得と保存期間の設定

Google も Microsoft と同様、管理者が組織単位で利用範囲を制御できる仕組みを持つ。ただし、DLPポリシーの粒度や適用タイミングの設定項目は、Microsoft Purview と比べて少ない。

ChatGPT Enterprise

• ユーザーの追加・削除
• 会話の共有範囲の設定（組織内のみ・外部許可等）
• データ保持期間の設定（会話履歴の自動削除）
• 監査ログの取得

OpenAI の管理者権限は、テナント単位の設定が中心であり、ユーザーごとに利用可能な機能を細かく制御する仕組みは提供されていない。全員に同じ設定が適用される前提である。

Claude for Enterprise

• API キーの発行・無効化
• 利用量の上限設定（トークン数・リクエスト数）
• API経由の操作ログの取得

Anthropic が提供する管理機能は、API利用を前提としたものに限られる。コンソール経由で利用する場合、管理者が介入できる操作はほぼ存在しない。統制設計の実務では、この仕様を「統制不可」として扱い、利用を制限するか、API経由の利用に限定するかの判断を迫られる。

監査ロールの付与が社内で承認されない場合の代替策

監査ログの取得には、管理者に監査ロールを付与する必要があるが、このロールは多くの場合、メールやファイルの閲覧権限を含む。そのため、情報セキュリティ部門や法務部門から「監査目的であっても閲覧範囲が広すぎる」として承認されないことがある。

実際、Copilot for Microsoft 365 の導入事例では、監査ログの取得をPurview前提で設計したが、監査ロールの付与が社内承認されなかった。メール等まで閲覧範囲が及ぶことが理由である。この場合、以下の代替策を検討する必要がある。

• エージェント管理基盤へ載せ替える: 生成AIの利用状況を別の管理基盤（社内開発または外部SaaS）で記録し、監査目的の大半をそちらへ移す。ただし「誰が誰に共有したか」の操作記録だけは代替手段がなく、残存リスクとして記録することになる。
• 監査ロールの権限を絞る: ベンダーが提供するカスタムロール機能を使い、監査対象をCopilot関連の操作のみに限定する。ただし、この機能が提供されているかはベンダーごとに異なる。
• 監査ログの取得を諦め、入口統制で補う: ライセンスの配布範囲を絞り、利用者を限定することで、出口統制（監査ログによる事後検知）ではなく入口統制（利用者の事前選別）へ設計を切り替える。

監査設計は「技術的に取得できるか」ではなく「その権限が社内で承認されるか」で決まる。技術仕様の確認だけで統制設計を進めると、承認段階で手戻りが発生する。

統制できるベンダーとできないベンダーの見分け方

統制可能なベンダーとそうでないベンダーを見分ける基準は、以下の3つの質問に対する回答で判断できる。

1. 管理者が監査ログを取得できるか? — 取得できない場合、利用の事実そのものが記録に残らない。統制設計の前提が成立しない。
2. 管理者が利用者の操作に介入できるか? — 介入できない場合、リスクを検知しても止める手段がない。統制は「お願いベース」に留まる。
3. 管理者権限の付与が社内で承認される見込みはあるか? — 技術的に可能でも、社内の承認プロセスで止まる場合、統制設計は成立しない。

この3つの質問すべてに「はい」と答えられるベンダーだけが、統制可能なベンダーとして設計の前提に置ける。1つでも「いいえ」があれば、そのベンダーは「統制できない前提で運用する」か「利用を制限する」かの判断を迫られる。

たとえば、Anthropic のClaude for Enterprise は、API経由の利用に限定すれば監査ログと管理者権限の両方が揃うが、コンソール経由の利用ではどちらも欠ける。この場合、統制可能な利用形態（API経由）と統制不可能な利用形態（コンソール経由）を分けて設計し、後者を禁止するか、残存リスクとして受け入れるかを判断する。

統制設計はライセンス配布範囲という前提に依存する

統制設計は、どのベンダーを選ぶかだけでなく、そのベンダーのライセンスをどの範囲に配布するかという前提にも依存する。前提が変われば、統制の思想ではなく装置の置き場所を組み替える必要がある。

実際の事例として、Copilotの有償ライセンスが一部にしか配布されていない前提では、広く使われるエージェントをCopilot Studioへ昇格させ、環境分離・コネクタDLP・環境別クレジット割当・公開承認フローという統制装置を必ず通過させる設計が成立していた。しかし有償ライセンスが対象組織のほぼ全員に配布された結果、全社展開の主経路は「Copilot Studioへ昇格」ではなく「Agent Builderのままギャラリーへ掲載」へ転換した。Agent Builderは環境の概念を持たず、コネクタDLPの対象外である。そのため、Copilot Studio環境側に置いた統制装置の上を、全社展開の主経路が通らなくなった。

この場合、統制の思想（入口は止めず出口で締めるガードレール型）は変えず、装置の置き場所を「環境」から「人（セキュリティグループ）とデータ（権限・ラベル）」へ再配置する方針で組み替えた。統制設計はライセンスの配布範囲という前提に依存している。前提が変われば、統制の思想ではなく装置の置き場所を組み替える。

未使用エージェントの削除基準が成立しない理由

統制設計の実務では、放置されたエージェントやチャットボットを自動削除する基準を設けることが検討されるが、この基準は成立しないことが多い。理由は、低頻度で稼働するエージェントが存在するためである。

たとえば、90日間未使用のエージェントを一律で削除する基準を設けたが撤回した事例がある。半年に1回など低頻度で稼働するエージェントが存在するため、未使用期間による一律削除は成立しなかった。削除基準は、稼働頻度ではなく「所有者の在籍状況」や「承認フローの通過有無」など、別の軸で設計する必要がある。

検証・決定・手順書の順序を崩さない

統制設計の実務では、検証、決定、手順書の順序を崩すと手戻りが発生する。特に、監査ログの取得可否や管理者権限の範囲は、ベンダーの技術仕様だけでなく、社内の承認プロセスにも依存する。決定を急がせる前に、検証結果を材料として先に出す。

具体的には、以下の手順で進める。

1. ベンダーの技術仕様を確認し、監査ログと管理者権限の範囲を表にまとめる。
2. 監査ロールの付与や管理者権限の行使が社内で承認される見込みを、情報セキュリティ部門・法務部門と事前に確認する。
3. 承認される見込みが立った時点で、統制設計の方針を決定する。
4. 決定した方針に基づき、手順書を作成する。

この順序を崩して「手順書を先に作り、後から承認を取る」という進め方をすると、承認段階で「この権限は付与できない」と止まり、手順書を最初から書き直すことになる。