解説

最近、生成AI(LLM)を利用する企業が増える中で、「入力データの取り扱い」や「誰がデータにアクセスできるのか」といったセキュリティとプライバシーの懸念が高まっています。

高性能なAIを活用しつつも、規制産業など機密性の高いデータを扱う環境では、データ保持自体が大きなハードルとなってきました。本件は、この相反する要求(高度な利用と厳格な秘匿性)を両立させようとする動きです。

特に注目すべき点は、AIによる不正利用の監視は続けつつも、「活動データの保存場所」や「暗号鍵管理」といった権限をすべて利用企業側に委ねる設計を採用している点です。

ポイント

  • Anthropicが発表した「Enterprise Frontier Safeguards」(EFS)は、データ保持によるプライバシー懸念を解消しつつ、AIの不正利用監視を継続可能にする新仕組みである。
  • EFSでは、活動データを顧客自身のクラウド(S3, Azure Blobなど)に保存し、暗号化鍵や監査ログ管理もすべて顧客が行うため、Anthropic側の人的レビューは不要となる。
  • これにより、金融や医療などの規制産業を含む企業が、高い機密性を維持したまま生成AIを導入・運用できるようになる。

情シスへの影響

【データ保存環境の変更と統合】

EFSを利用する場合、監視活動に必要なトラフィックデータをAnthropicではなく、顧客側(Amazon S3, Azure Blob Storage, Google Cloud Storageなど)が管理するクラウドストレージに保存することが求められます。これは、既存のデータロギング・監視パイプラインへの追加的な処理や連携が必要となる可能性があります。

【アクセス制御と鍵管理の徹底】

すべての機密なデータ(活動ログ、検知フラグ等)は顧客が管理する暗号鍵の下で保護されます。したがって、シークレットマネージャによる適切なキーライフサイクル管理、およびクラウドストレージへのアクセス制御ポリシー(IAM/RBAC)を再確認し、適用することが必須となります。

【システムの利用範囲と連携】

EFSはClaude Code、Claude Enterpriseといった既存のAnthropicのエコシステムや、Amazon Bedrock, Microsoft Foundryなど複数のプラットフォーム経由で利用可能です。どのAPIゲートウェイまたはプラットフォーム経由でAIサービスを利用するかによって、ログの収集元や処理フローが異なるため、適用経路の選定とそれに応じた連携設計が必要です。

影響範囲

対象クラウドストレージ:Amazon S3, Azure Blob Storage, Google Cloud Storageなど。

対象システム/API:Claude Code, Claude Enterprise, Claude Platform, Amazon Bedrock, Claude Platform on AWS, Google의 Agent Platform, Microsoft Foundry経由のAIサービス利用環境。

影響を受ける領域:ログ管理(Activity Data)、アクセス制御、データ保存ポリシー、セキュリティ監視体制(監査ログ)。

留意点:すべての機能がオプトイン方式であり、モデルの挙動や料金には直接的な影響はないものの、ストレージ・読み書き・転送コストが発生する可能性が高い。

重要度

★★★★☆

対象者

  • M365管理者
  • Entra管理者
  • AD管理者
  • セキュリティ担当者
  • ネットワーク管理者

優先度

計画的に対応

優先度の理由

EFSは、セキュリティ機能の強化とプライバシー保護のための高度な仕組みであり、導入には既存環境への組み込みやポリシー変更が必要です。しかし、現時点では「利用検討」フェーズが中心であり、悪用確認された脆弱性ではないため、「今すぐ対応」とするのは過剰です。今後の業務要件に合わせてデータ保管場所やアクセス制御の見直しを計画する期間が必要なため、「計画的に対応」と判断しました。

確認手順

  • 現在のAIサービス(LLM)利用におけるログ収集先、保存ポリシー、および保持期間の規定を確認する。
  • Anthropicなどの主要AIベンダーが提供するデータ監視/ロギング機能について、顧客クラウドへのデータ保管オプションとアクセス制御の仕様を公式ドキュメントで確認する。
  • 自社の最も機密性の高いデータを扱うシステムの利用フローにおける、ログ収集・保管単位(セッション単位か永続的なストリーミングか)を特定し、要件定義を行う。
  • クラウドストレージ側の暗号化鍵管理サービスにおいて、AIデータ監視専用のアクセスキーと監査ポリシーを分離して設計する。
  • ベンダーから提供されるEFSなどの次期セキュリティ機能が、利用中の主要プラットフォーム(例:AWS Bedrock, Azure OpenAI等)にどのような形で統合・影響を与えるかを確認する。

推奨対応

  • 最優先で自社のデータガバナンス要件とAIベンダーのデータ保持ポリシーを照合し、最適なモデル選択を行う。
  • ログデータを外部(S3やAzure Blobなど)に保管する場合、データの暗号化鍵管理プロセスを強化し、誰が、どの権限で鍵にアクセスできるかを再定義する。
  • AI利用のためのロギングシステム設計において、監査目的(不正検知か履歴追跡か)に応じてログの保存期間と粒度を設定し、既存のセキュリティ運用フローに組み込むためのPoCを検討する。