ClaudeやCopilotがあなたのファイルシステムにいる。何を見せるか、誰が決める？

過去12か月のどこかで、AIアシスタントが貴社のファイルシステムに登場しました。IT部門が承認したかもしれません。あるいは、事業部門がM365導入の一環としてMicrosoft Copilotを展開したかもしれません。従業員が自分でClaudeや他のAIツールを業務用ドライブに接続した可能性もあります。

どのような経緯であれ、結果は同じです。AIシステムが従業員に代わってエンタープライズファイルを取得するようになり、多くの組織では、AIシステムが何を閲覧できるかを明確に決定した人はいません。人間のファイルアクセスを管理するアクセス制御は、AIアクター向けに設計されていません。人間のファイルアクセスを追跡する監査ログは、コンプライアンスが求める帰属詳細でAIによる取得を記録するようには構成されていません。誰が何にアクセスできるかを定義するポリシーも、従業員向けに作成されており、従業員の代理として動作するAIシステム向けではありません。

本記事は、今や運用上の緊急課題となった「AIアシスタントがファイルシステムで何を閲覧できるか、誰が決めているのか」という問いに答える必要があるCISOやコンプライアンス担当者向けです。

エグゼクティブサマリー

主旨：AIアシスタントは、人間ユーザー向けに設計された認可モデルの下でエンタープライズファイルシステムにアクセスしていますが、これらのアクセス権、セッション境界、監査証跡はAIアクターにとって構造的に不十分です。組織がAIアクセス制御でカバーしていると信じている範囲と、実際にカバーできている範囲には大きなギャップがあり、その多くは見えにくく、直接的なコンプライアンスリスクを伴います。

なぜ重要か：規制当局や監査人から「AIがどのファイルにアクセスしたのか」「誰が各取得を承認したのか」「機密区分の適用がどのように担保されたのか」と問われたとき、その答えを出せるのはAI連携がそのために設計されている場合だけです。ほとんどのケースではそうなっていません。このギャップは、調査が始まる前に発見すべきであり、調査中に気付くべきではありません。

5つの重要なポイント

1. AIアシスタントがエンタープライズファイルシステムにアクセスする際、多くの場合サービスアカウントで動作し、その権限は個々のユーザーの認可範囲を超えています—つまり、AIは質問した従業員が他の経路では閲覧できない文書も取得できてしまいます。
2. セッションレベルの認可は、リクエストごとのRBACやABACの強制と同等ではありません。 これは単一のチェックポイントであり、その後は機械の速度で監視されないアクセスが続きます。
3. 多くのAIファイルアクセス監査ログはサービスアカウントのIDのみを記録し、取得を引き起こした人間ユーザーを記録していません。 これは単なるログのギャップではなく、HIPAAコンプライアンスのギャップ、GDPRコンプライアンスのギャップ、フォレンジック調査のギャップです。
4. ファイルに適用されたデータ分類や機密ラベルは、AI連携が取得レイヤーで明示的に評価しない限り、AIによる取得には影響しません。 AIアシスタントは、未分類の文書と同じように「Confidential」や「Restricted」とマークされた文書も取得できます。
5. ガバナンス上の問いは「AIファイルアクセスを許可するかどうか」ではありません—AIによって従業員の生産性は向上し、ブロックすればシャドーAIが増加します。問題は、AIファイルアクセスが、組織内の他のすべてのデータアクセスと同じポリシー、同じ強制力、同じ監査証跡で管理されているかどうかです。

誰も承認していないアクセスモデル

組織がファイルシステムアクセス権を持つAIアシスタントを導入する際、通常はサービスアカウントを設定してAIをファイルリポジトリに認証させます。このサービスアカウントには、全ユーザーのニーズに対応できるよう広範な権限が付与されます—AIがどのユーザーにも必要なファイルを取得できる必要があるためです。その結果、対象範囲内のすべてにアクセスできる単一の認証情報が、AIを利用するすべてのユーザー間で共有されることになります。

このような権限プロファイルを持つ人間ユーザーアカウントを、意図的に作成する組織はありません。リポジトリ内のすべての機密ファイルにアクセスできる共有アカウントを、どの従業員でも利用でき、個別のアクセス制限もない—これはID・アクセス管理レビュー、リスク評価、コンプライアンス監査のすべてで不合格となるでしょう。

しかし、同じ権限構成がAIサービスアカウントに適用されると、それがインフラの一部に見えるため、アクセス制御ポリシーとして認識されず、レビューを通過してしまうことがよくあります。AIはシステムとして扱われ、ユーザーの代理でデータアクセス判断を行うアクターとは見なされません。この区別は精査には耐えられず、規制調査にも耐えられません。

その実際的な結果として、サービスアカウント経由でエンタープライズファイルシステムに接続されたAIアシスタントは、質問した従業員が本来閲覧を許可されていない文書も取得できます。ジュニアアナリストがClaudeに競合状況の要約を依頼すると、自身の権限を超えた機密文書をもとに回答を受け取ることがあります。カスタマーサービス担当者がCopilotにアカウント履歴の取得を依頼すると、他アカウントのファイルまで意図せず表示されることもあります。AIは誤動作しているのではなく、構成通りに動作しているだけです。アクセスモデルがこの事態を防ぐよう設計されていなかったのです。

セッションレベルの認可はゼロトラストではない。1つのゲートしかない境界線だ。

AIによるファイルアクセスへのガバナンス対応として最も一般的なのは「認証を担保している」と主張することです。AIは接続前に認証され、アクセスが検証され、組織のゼロトラストアーキテクチャ内でセッションが確立される—これは事実ですが、十分ではありません。

セッションレベルの認証は、セッション確立時点でAIシステムがファイルリポジトリに接続する許可を持つことを検証します。しかし、AIを操作する特定のユーザーが、特定のクエリで取得しようとする特定のファイルにアクセスする権限があるかどうかまでは検証しません。セッションが一度確立されると、その後のすべての操作は接続時に確立された認可を引き継ぎます—サービスアカウントが到達できるものは、どのユーザーでも、どんな目的でも、追加の認可チェックなしにAIが取得できます。

これは、ビルの入口で訪問者の身元を確認し、その後の滞在中は全オフィスやサーバールーム、役員室まで無制限に立ち入りを許可するのと同じです。最初の認証は行われましたが、それ以降は暗黙の信頼—まさにゼロトラストデータ交換の原則が排除しようとするものです。

人間ユーザーの場合、セッションレベルの制御は継続的検証の近似として合理的です。なぜなら、人間のセッション行動は人間の業務速度に制約されるからです。しかし、1回のセッションで数千件のファイル操作を実行できるAIシステムでは、セッションレベルの認可は単なるチェックポイントであり、その後は機械の速度で監視されないアクセスが続きます。これは境界型モデルであり、ゼロトラストではありません。

リクエストごとのRBACやABACの強制は、個々のファイル操作—すべての取得、検索、ダウンロード—が、その時点でリクエストしたユーザーの実際のアクセス権に照らして評価されることを意味します。AIはセッションレベルの認可を継承せず、そのクエリに対してのみ、実行元ユーザーの具体的な権限を継承します。そのユーザーが文書を閲覧する権限を持たない場合、AIは取得できません—サービスアカウントの到達範囲やセッション状態、クエリの表現方法に関係なくです。

AIは機密ラベルを見ていない—AIが評価しない限り守られない

成熟したデータガバナンスプログラムを持つ多くの組織は、データ分類フレームワークに投資しています。ファイルに機密ラベルを付与し、どのように取り扱うか、誰がアクセスできるか、何ができるかを定義します。Microsoft Information Protection、ネイティブのファイル分類システム、手動分類ワークフロー—これらは実際のガバナンス投資であり、人間によるファイルアクセス管理には有効です。

しかし、AI連携が明示的に評価しない限り、AIによる取得には影響しません。「Confidential」とラベル付けされた文書も、未分類の文書と同じくAIが簡単に取得できます。機密ラベルはファイルに付与されたメタデータです。そのメタデータがAIに返される前に評価されるか、完全に無視されるかは、AI連携の設計次第です。多くのAIファイルシステム連携では、取得レイヤーで機密ラベルは評価されません。AIはクエリに最も関連する文書を取得しますが、その関連性評価に機密区分は考慮されません。

コンプライアンス担当者にとっての示唆は明確です。投資してきたデータガバナンス制御は、AI連携が明示的に強制しない限り、AIアクセスには及びません。すべての分類判断、機密ラベル、リポジトリ内ファイルに適用されたアクセス制限—いずれも、AI連携が取得レイヤーで評価しない限り、AI取得を制約しません。分類フレームワークがAIによる機密ファイルの不正露出を防ぐと信じている組織は、監査で通用しない誤った安心感を持っています。

5つのアクセス制御失敗例—実際に起こること

答えられない質問—答えられるようになるまで

コンプライアンス担当者にとって、AIファイルアクセスガバナンスの問題は、極めて具体的かつ答えにくい問いに集約されます。規制当局や監査人から「AIアシスタントが何にアクセスしたか」「誰が各取得を承認したか」「データ保護義務がどう担保されたか」を問われたとき、答えられるか？

その答えは、AI連携が何を記録し、何を強制するよう設計されたかに完全に依存します。多くのAIファイルアクセス監査証跡は、サービスアカウントがファイルを取得したことしか記録しません。どの従業員のクエリが取得を引き起こしたか、その取得が従業員のアクセス権と整合していたか、ファイルの機密区分が評価されたか、取得内容がどう扱われたか—これらは記録されません。

これはログ設定の問題ではなく、アーキテクチャの問題です。コンプライアンス上必要な帰属情報は、取得時点で記録されなければならず、後から再構築することはできません。

HIPAAの最小限必要ルールは、保護対象保健情報へのアクセスを目的達成に必要な最小限に制限することを求めます。AIがクエリに答えるためにPHIを取得する場合、最小限必要コンプライアンスを証明するには、誰がどのクエリで何を取得したかを正確に把握する必要があります。

GDPRは、個人データ処理に文書化された合法的根拠を要求します。AIによる取得では、どのユーザーが取得を指示し、その目的が何だったかを把握する必要があります。SOXは財務データへのアクセスの完全な記録を要求します。

FedRAMPコンプライアンスは、認可された情報システム内のすべての操作（AI操作を含む）について、責任ある人間アクターを特定できる帰属レベルの監査ログを要求します。

監査人が問うこと—答えるために必要なもの

AIをブロックしても解決しない。ガバナンスこそが解決策。

AIファイルアクセスへの懸念に対する反射的な対応—AIツールのブロック、アクセス権の剥奪、ガバナンスフレームワークの整備待ち—は、別の問題を生み出します。業務に本当にAIが役立つと感じている従業員は、他の手段でAIにアクセスします。個人アカウント、ブラウザベースのAIツール、エンタープライズガバナンスと無縁で正規データにアクセスできない消費者向けアプリケーションなどです。

これは仮定の話ではありません。シャドーAIはすでに多くの組織に存在し、正規AIツールを制限すると、ガバナンス外のAI利用がむしろ加速します。

ガバナンス上の問いは「AIファイルアクセスを許可するかどうか」ではありません。AIファイルアクセスが、組織内の他のすべてのデータアクセスと同じポリシー、同じ強制力、同じ監査証跡で管理されているかどうかが重要です。デスクトップアプリケーション経由でファイルにアクセスする従業員には、アクセス制御、セッション監視、監査ログが適用されます。

同じ従業員がAIアシスタント経由で同じファイルにアクセスする場合も、リクエストごとの認可、機密ラベルの強制、二重帰属ログなど、同一の制御が適用されるべきです。AI経路がこれらの制御を一つでも回避すれば、それは将来的に悪用・発覚するガバナンスギャップとなります。

KiteworksがAIの閲覧範囲を厳格に制御する仕組み

AI導入によるコンプライアンスリスクを生まずに運用できる組織は、AIを最も長くブロックした組織ではなく、AIへのガバナンス適用を最速で実現した組織です。そのためには、「AIが何を閲覧できるかを決めるのは誰か」という問いに、他のアクターと同じく「ポリシーエンジンが、個々のリクエストごとに、実ユーザーの実際の権限に基づき評価する」と答えられるアーキテクチャが必要です。

Kiteworksは、AI操作レベルでリクエストごとのRBACおよびABACを強制します—セッション確立時ではありません。Claude、Copilot、またはMCP互換AIアシスタントがKiteworksプライベートデータネットワーク経由で実行するすべてのファイル取得、検索、フォルダー操作は、認証済みユーザーの現時点のアクセス権に照らしてデータ返却前に評価されます。

AIは、サービスアカウントの権限ではなく、ユーザーの権限を個々の操作ごとに継承します。ユーザーが文書を閲覧できなければ、AIも取得できません。セッション状態やクエリ構成、サービスアカウントの到達範囲に関係なくです。

機密ラベルの強制は取得レイヤーで実施されます。Microsoft Information Protectionの分類やKiteworksのデータ分類ポリシーが、AIへのデータ返却前に評価されます。認可されていないユーザーのクエリに対しては、Confidential文書は表示されません—AIが「言及しないよう指示されている」からではなく、ガバナンスレイヤーがそもそも返却しないからです。

すべてのAIファイル操作は、AIシステムIDと認証済み人間ユーザーの二重帰属でログ記録され、Kiteworks監査ログに蓄積され、リアルタイムでSIEM連携されます。上記のコンプライアンス質問には、アーキテクチャがそれを生成するよう設計されているため、答えがあります。

AIファイルアクセスも人間アクセスと同じ厳格さで管理されていることを証明したいCISOや、AIが何にアクセスし誰が承認したかの監査対応ドキュメントが必要なコンプライアンス担当者に、Kiteworksはその両方を可能にするガバナンスデータレイヤーを提供します。仕組みを詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  手頃なAIプライバシー保護のためのゼロトラスト戦略
• ブログ記事
  77%の組織がAIデータセキュリティで失敗している理由
• eBook
  AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレット状態に
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく「機能している証拠」を求めている