🔐

生成AIアプリケーションをAzure上で開発する時にGPTモデルもClaudeも使いたい。そんな時に抑えておきたいセキュリティ観点。

に公開
Security
Databricks
llm
Azure OpenAI
Claude
tech

はじめに

生成AIのビジネス活用が本格化する中、Azure上でOpenAI社製のGPTシリーズや Anthoropic社製のClaude 3など複数の大規模言語モデル（LLM）を組み合わせて使うアーキテクチャも現実的になってきました。一方で、企業内データを扱うとなれば、セキュリティやプライバシーへの配慮は避けて通れません。

この記事では「Azure上で生成AIアプリを構築する際に、GPTとClaudeを併用する場合におさえておきたいセキュリティ観点」について、技術構成と実践ポイントを交えて解説します。

本情報は2025.7月時点の調査結果であり、今後各サービスの仕様変更などにより記事の内容と異なる場合があります。

1. モデルによるデータの取り扱い方の違い

✅ Azure OpenAI（GPT-4oなど）の場合

  • Microsoftが提供する商用サービスとして、通常はプロンプトやレスポンスは保存されず再学習にも使用されません。ただし、Abuse Monitoring（不正検知）目的で最大30日間ログが保存されます。

    ただし、「Modified Abuse Monitoring」（Abuse Monitoring（ログ保存・人によるレビュー）を完全にオフにする）オプションを申請・承認されれば、保存もレビューも行われません。

  • 日本リージョン（Japan East）でも提供中で、機密データも国内に閉じた処理が可能ですが、一部の最新モデル（o3など）は日本リージョンで未提供の場合があります。

✅ Claude（Anthropic）の場合（Databricks経由）

  • Claude APIはAnthropicのポリシーにより、すべての入力・出力を保存せず、モデル学習にも利用しません。（Anthropic 本家 API を直接叩く場合は３０日間の保管がされますが、Azure Databricks経由であれば保管されません。詳しくはこちら）

  • Azure Databricksを通じてClaudeを呼び出す場合、AI Gatewayを経由してプロンプト送信されるため、APIキーや送信内容はDatabricksが中継・統制します。

  • ただしモデル実行はAnthropicクラウド側（米国）で行われるため、プロンプトは一時的に国外送信される点に注意が必要です。

  • Databricks環境自体は日本リージョン（Japan East/West）に展開可能で、ユーザーデータやログなどのストレージは日本国内で完結可能です。

  • AI GatewayやUnity Catalogといったセキュリティ・ガバナンス機能も統合されており、データの流通・処理・監査を一元管理できます。

2. ログ・監査と可視性の違い

項目 Azure OpenAI Claude（Databricks）
API呼び出しログ Azure MonitorやApp Insightsで確認可能 Unity Catalogによりプロンプト単位で完全な監査可能
データの保存可否 明示的に保存しなければ保持されない 保存先（Delta Tableなど）をユーザーが制御
出力の安全性制御 Content Safety APIやPrompt Flowで対応 AI GatewayでPII検出／出力制御が可能

特にDatabricksでは、AI Gateway + Unity Catalogにより「誰がどのプロンプトを使い、どんなデータにアクセスし、何を出力したか」まで詳細にトレースでき、エンタープライズ向けの可視性が強みです。

また、Mosaic AIの一部として提供されるモデルサービング／評価機能を活用すれば、プロンプトや応答の品質をログに残しながら、安全な評価プロセスを構築することも可能です。

3. リージョンとデータ所在地の考慮

Azure OpenAIは日本国内リージョンでモデル推論まで完結可能なため、データが一切国外に出ない構成が可能です。対してClaude（Databricks経由）は、モデル推論がAnthropicクラウド（主に米国）で行われるため、データが一時的に国外転送されることを許容できるかがポイントです。

このため、

  • 全データ国内完結が絶対要件（金融・公共など） → Azure OpenAI のみ
  • 内容を匿名化・マスキングできる前提 → Claude（Databricks）もOK
    という判断になります。

Databricks自体は日本リージョン対応しており、ユーザーデータ、ノートブック、Deltaテーブル、監査ログなどの保存先を日本国内に限定可能です。

4. プロンプトの安全性と出力制御

両者とも生成内容に対するセーフティガードを提供しています。

対策項目 Azure OpenAI Claude（Databricks）
不適切な入力制御 Prompt Flowでガードレール設定 AI Gatewayで禁止語・正規表現などルール定義可能
出力のトーン・有害表現の検出 Content Safety APIを併用 出力フィルター機能あり（例：PII自動マスク）

Claude側の制御はDatabricksが持つため、プロンプト自体の事前マスキングや、出力ルールをノーコードで設定できるのが特徴です。

5. APIキーとアクセス制御

Claudeの場合、DatabricksがAPIキーの管理とリクエスト代行を行うため、ユーザーはキーに直接触れずに利用可能です。さらにAI Gatewayによるレート制限やリソースポリシー設定も可能です。

Azure OpenAIの場合は、Key VaultやマネージドIDと組み合わせることでセキュアにAPIアクセス制御を実現できます。

Databricks側では、Unity Catalogによるモデル・データへのRBAC制御、オブジェクトレベル権限制御、監査ログ保持が可能で、組織ポリシーに準じたガバナンスを構築できます。

おわりに：併用時の設計指針

ClaudeとGPTを組み合わせることで、用途に応じて「推論性能」「コーディング能力」「日本リージョン対応」「エンタープライズ制御」などの強みを相互補完できます。

ただし、それぞれのモデルやサービスにはデータの流れ・ログの可視性・国外送信の有無といったセキュリティ面での差異があるため、

🔐 「どのデータを、どのモデルに、どんなルートで送るか」

を明示的に設計し、必要に応じてマスキングやフィルタを入れることが安全な運用の鍵です。

Azure上でのLLM活用を安心・安全に進めるための一助になれば幸いです。

参考リンク

Discussion