Azure生成AIの安全なデータ管理と共通基盤(ランディングゾーン)入門【2026年版】

確認日:2026年9月24日。Microsoft Learn(Cloud Adoption Framework、Azure Well-Architected Framework、Microsoft Entra、Microsoft Foundry、Azure Key Vault、Azure Private Link、Microsoft Purview、Microsoft Defender for Cloud、Azure Policy の各ドキュメント)で確認しました。この記事は2025年2月に公開した「【初心者向け完全ガイド】Azureで実現する安全なデータ管理と共通基盤構築のポイント」を、生成AIを社内で使う場面に合わせて全面的に書き直したものです。

はじめに:この記事で分かること
- 先に確認:名前が変わった製品
なぜ共通基盤(ランディングゾーン)が必要なのか
- 2つの層に分けて考える
- 設計で決めること(設計領域)
ID とアクセス管理:最小権限とマネージドID
ネットワークの閉域化:プライベートエンドポイント
- 初心者がつまずきやすい2つの点
- 生成AI特有の注意:エージェントの「外への通信」
鍵とシークレットの管理:Azure Key Vault
データの分類と保護:Microsoft Purview
ログと監視:Azure Monitor と Microsoft Defender for Cloud
- ログを集める:診断設定
- 状態を点検し、脅威を見つける:Microsoft Defender for Cloud(旧 Azure Security Center)
ガバナンス:Azure Policy でルールを自動で守らせる
- 生成AI向けのポリシーの例
生成AIを使うときの注意:入力データは学習に使われる?
- どこで処理されるか:デプロイの種類
- そのほかの注意点
小さく始める手順
チェックリスト
まとめ
- 参考リンク

はじめに:この記事で分かること

「社内で生成AIを使いたい。でも、機密データを入れて大丈夫なのか」。Azure で生成AIを使い始める会社の多くが、最初にこの壁にぶつかります。

答えは、AI のサービスを1つ作ることではなく、だれが・どこから・どのデータに触れられるかを会社全体で決めた「土台」を先に用意することです。Microsoft はこの土台をランディングゾーン(共通基盤)と呼び、作り方を公式ガイドとして公開しています。

この記事では、これから Azure を学ぶ方に向けて、次の順番で説明します。

なぜ共通基盤(ランディングゾーン)が必要なのか
ID とアクセス管理(最小権限・マネージドID)
ネットワークの閉域化(プライベートエンドポイント)
鍵とシークレットの管理(Azure Key Vault)
データの分類と保護(Microsoft Purview)
ログと監視(Azure Monitor・Microsoft Defender for Cloud)
ガバナンス(Azure Policy)
生成AIを使うときの注意(入力データは学習に使われるのか)
小さく始める手順と、チェックリスト

先に確認:名前が変わった製品

2025年の旧記事のあとも、いくつかの製品名が変わっています。この記事では新しい名前を使い、必要に応じて旧名を括弧で添えます。

旧名	現在の名前	補足
Azure Active Directory(Azure AD)	Microsoft Entra ID	2023年7月11日に発表。機能・料金・ログイン URL は変わっていない
Azure Security Center / Azure Defender	Microsoft Defender for Cloud	クラウド全体のセキュリティ状態を点検・保護するサービス
Azure AI Studio / Azure AI Foundry	Microsoft Foundry	AI エージェント・モデル・ツールをまとめて扱う Azure のサービス
Azure AI Services	Foundry Tools	音声・翻訳などの AI サービス群
コンテンツフィルター	Guardrails(ガードレール)	有害な入力・出力を検知して止める仕組み
Azure AI User など	Foundry User など	Foundry 用の権限(ロール)名。ロールの ID と中身は同じ

旧記事で「エンタープライズスケールランディングゾーン」と呼んでいたものは、現在の Microsoft Learn では主に「Azure ランディングゾーン」と呼ばれています。

なぜ共通基盤(ランディングゾーン)が必要なのか

部署ごとにバラバラに Azure を契約・設定すると、次のような問題が起こりがちです。

だれが管理者なのか分からないサブスクリプション(Azure の契約・請求の単位)が増える
API キーがコードやチャットに貼られたまま広まる
インターネットから誰でも接続できる設定のまま、社内データを扱ってしまう
ログが取られておらず、問題が起きても追えない

これを防ぐのがランディングゾーンです。公式の Cloud Adoption Framework(CAF) では、Azure ランディングゾーンを「複数のサブスクリプションからなる Azure 環境を、統制し、守り、広げていくための実績あるアーキテクチャ」と説明しています。飛行機にたとえると、どの機体(アプリ)が来ても安全に着陸できるよう、あらかじめ整えた滑走路です。

2つの層に分けて考える

プラットフォームランディングゾーン:会社全体の土台。管理グループ(サブスクリプションをまとめる入れ物)の階層、共通のネットワーク、監視、セキュリティのルールをここで一元管理します。公式には、多くの組織は1つの Microsoft Entra テナントにつき1つで十分とされています。
アプリケーションランディングゾーン:各アプリ(ワークロード)用の区画。開発・テスト・本番などの環境を持ち、土台のルール(ガードレール)の範囲内で、各チームが自由に作ります。

参考の管理グループ階層には、社内向け(Corp)、インターネット公開向け(Online)、試用のための Sandbox などの区分があります。社内向けの生成AIアプリなら社内向けの区画に置き、土台のルールを自動で引き継がせます。

設計で決めること(設計領域)

CAF は、ランディングゾーンを作る前に検討すべきことを8つの設計領域に整理しています。

設計領域	決めることの例
Azure の請求と Microsoft Entra テナント	契約の形態、テナントをいくつ持つか
ID とアクセス管理	だれに、どの範囲で、どの権限を渡すか
リソースの整理	管理グループとサブスクリプションの分け方、名前やタグの付け方
ネットワークのトポロジと接続	ハブ&スポーク(共通のハブに各ネットワークをつなぐ形)にするか、社内との接続方法
セキュリティ	脅威の検知、暗号化、鍵の管理
管理	監視、ログの集約、バックアップ
ガバナンス	ルール(ポリシー)の自動チェックと強制、コスト管理
プラットフォームの自動化と DevOps	コード(IaC)で土台を作り、変更を管理する方法

作り方は2通りあります。公式が推奨するのは、Terraform か Bicep(どちらも設定をコードで書く道具)で土台を作る Azure landing zone IaC accelerator です。コードに慣れていない組織向けには、画面操作で作れるポータルアクセラレーターも用意されていますが、あとからの更新や変更管理は難しくなると説明されています(実装オプション)。

なお、CAF には AI 導入専用のガイドもあり、「戦略 → 計画 → 準備 → 統制 → 保護 → 管理」の6段階で進め方を整理しています(AI strategy)。

ID とアクセス管理:最小権限とマネージドID

クラウドでは、ネットワークの内側か外側かより「だれが操作しているか」が安全の中心になります。Microsoft はこれをゼロトラストと呼び、「明示的に確認する」「最小権限でアクセスさせる」「侵害は起こりうる前提で考える」の3原則を掲げています。

人のアカウント:Microsoft Entra ID(旧 Azure AD)

社員のサインインは Microsoft Entra ID で管理します。多要素認証(MFA)や、場所・端末などの条件でアクセスを制御する Microsoft Entra 条件付きアクセス(旧 Azure AD 条件付きアクセス)を使い、特に管理者アカウントを強く守ります(名称変更の公式説明)。

権限は「必要な分だけ」:Foundry のロール

Azure の権限は Azure RBAC(ロールベースのアクセス制御)で、「だれに・どの範囲で・どの役割(ロール)を」渡すかを決めます。Microsoft Foundry には専用のロールがあり、公式ドキュメントは最小権限のためにこれらを使うよう勧めています(Foundry の RBAC)。

ロール(旧名)	主な用途
Foundry Agent Consumer	エージェントを呼び出すだけの人・アプリ向け。いちばん権限が小さい
Foundry User(旧 Azure AI User)	プロジェクトの中で開発・テストする開発者向け
Foundry Project Manager(旧 Azure AI Project Manager)	プロジェクトの管理、メンバーへの Foundry User の付与
Foundry Account Owner(旧 Azure AI Account Owner)	Foundry リソースの管理、モデルのデプロイ
Foundry Owner(旧 Azure AI Owner)	すべての操作ができる強い権限

ロール名の変更が段階的に進んでいるため、公式はスクリプトではロール名ではなくロール ID を使うよう勧めています。次は公式ドキュメントに載っている、Foundry User を割り当てる例です(値は自分の環境に置き換えます)。

az role assignment create --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" --assignee "joe@contoso.com" --scope /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/this-rg

API キーをやめて、Entra ID 認証にする

見落としやすいのが API キーです。公式ドキュメントには、キーで認証した場合は「ロールによる制限なしに全権限が与えられる」と書かれています。つまりキーが1つ漏れると、権限の設計が意味をなさなくなります。

そこで、Microsoft Entra ID による認証に切り替え、キーによる認証(ローカル認証)を無効にします。Bicep や ARM テンプレートでは disableLocalAuth を true にし、既存のリソースは PowerShell で次のように設定できます(公式手順)。

Set-AzCognitiveServicesAccount -ResourceGroupName "my-resource-group" -Name "my-resource-name" -DisableLocalAuth $true

設定はすぐには反映されず、数分から数時間かかることがあると公式に注意書きがあります。古いキーで接続を試して 401 エラーになることを確認してから、無効化が済んだとみなしましょう。

アプリの認証は「マネージドID」で

アプリが Foundry やストレージにアクセスするときは、パスワードやキーの代わりにマネージドIDを使います。Azure のリソースに付ける「アプリ専用の ID」で、資格情報(パスワードなど)を人が管理する必要がなく、追加料金もかかりません(公式の概要)。

システム割り当て:1つのリソースと一緒に作られ、リソースを消すと ID も消える
ユーザー割り当て:独立して作り、複数のリソースで共有できる。公式は Microsoft のサービスではこちらを推奨している

社内でコーディングエージェントを使う場合も考え方は同じです。「実行してはいけない操作」をあらかじめ止める設定は Claude Code を会社で安全に使う権限設定入門で解説しています。

ネットワークの閉域化:プライベートエンドポイント

次は「どこから接続できるか」です。Azure の多くのサービスは、初期状態ではインターネット上の公開の窓口(パブリックエンドポイント)から接続できます。社内データを扱う生成AIでは、これを社内ネットワークからだけに絞るのが基本です。

そのための仕組みが Azure Private Link とプライベートエンドポイントです。公式には、プライベートエンドポイントは「仮想ネットワーク(VNet)のプライベート IP アドレスを使うネットワークインターフェイス」と説明されています。簡単にいうと、Azure のサービスを自社の VNet の中に「内線番号」として引き込む仕組みです(公式の概要)。

初心者がつまずきやすい2つの点

プライベートエンドポイントを作っても、公開の窓口は自動では閉じない:公式にも、パブリックネットワークへのアクセスを必ずしも制限しないと書かれています。Foundry では「パブリックネットワークアクセス」を Disabled にして、はじめて閉域になります。
DNS(名前解決)の設定が重要:同じ接続先の名前が、VNet の中からはプライベート IP に、外からは公開 IP に解決されるようにします。通常は privatelink で始まるプライベート DNS ゾーンを使います。

Foundry の公式手順では、VNet の中の仮想マシンなどから次のコマンドを実行し、プライベート IP が返ることを確かめる方法が紹介されています(Foundry のネットワーク分離)。

nslookup <your-foundry-endpoint-hostname>

生成AI特有の注意:エージェントの「外への通信」

Foundry では、受け付ける側(インバウンド)だけでなく、Foundry やエージェントから外へ出る通信(アウトバウンド)も考える必要があります。公式ドキュメントでは、エージェントのデータを自社のテナント内に置く「Standard setup」では、Azure Storage・Azure AI Search・Azure Cosmos DB を自分で用意する(BYO)必要があると説明されています。

また、Bing による検索(Grounding with Bing)、Web 検索、SharePoint 検索といった一部のツールは、閉域の構成でも公開のエンドポイントを通って通信します。すべての通信を社内に閉じる必要がある場合は、これらのツールを Azure Policy で使えないようにできる、と公式に書かれています。

鍵とシークレットの管理:Azure Key Vault

接続文字列、証明書、外部サービスの API キーなど、どうしても必要な秘密の情報(シークレット)は、コードや設定ファイルに書かず Azure Key Vault に保管します。Key Vault は、シークレット・暗号化の鍵・証明書をまとめて安全に管理するサービスです(公式の概要)。

アクセス制御は Azure RBAC で:API バージョン 2026-02-01 以降、新しく作る Key Vault では Azure RBAC が既定の方式になりました。従来の「アクセスポリシー」は公式ドキュメントで legacy(旧方式)と表記されています(RBAC ガイド)。
アプリ・環境ごとに分ける:公式は「アプリごと・環境(開発・検証・本番)ごとに1つの Key Vault」を勧めています。
読むだけのアプリには読むだけの権限:たとえばシークレットを読むだけのアプリには Key Vault Secrets User を割り当てます。
さらに厳しい要件には:Premium レベルでは、鍵を専用のハードウェア(HSM)の中で守れます。

Key Vault も、前の章のプライベートエンドポイントで閉域化できます。シークレットは定期的に入れ替える(ローテーション)ことも大切です。

データの分類と保護:Microsoft Purview

どのデータを生成AIに渡してよいかは、データに「区分」がなければ決められません。Well-Architected Framework のセキュリティでも、最初のほうの項目(SE:03)で、すべてのデータに機密度のラベルを付け、それを設計に反映するよう求めています。

この分類と保護を担うのが Microsoft Purview です。公式には「AI の時代に、データがどこにあっても統制・保護・管理するためのソリューション群」と説明され、データセキュリティ、データガバナンス、コンプライアンスの3分野があります(公式の概要)。

機能	できること
秘密度ラベル(Sensitivity labels)	「社外秘」などのラベルをファイルやメールに付け、暗号化などの保護をデータに追従させる
データ損失防止(DLP)	機密情報の持ち出しを検知・ブロックする。ブラウザー経由で外部の生成AIサイトへ機密情報を貼り付けるのを警告・ブロックする設定もある
DSPM(データセキュリティ態勢管理)	機密データのリスクを見つけて対処する。AI アプリやエージェントも対象
監査(Audit)	対応する AI アプリでの操作やプロンプトと応答を記録し、あとから検索する

Purview は Microsoft Foundry を「Enterprise AI apps」として対象に含めています。どの機能がどのアプリに対応しているかはアプリごとに違うため、導入前に生成AI向けの公式ページで確認してください。

Azure で OpenAI などのモデルを実際に使い始める手順は Azure OpenAI 入門で解説しています。

社内文書を AI に参照させる仕組み(RAG)を作る場合は、検索した人が本来見てよい文書だけを使うことが重要です。この点は RAG 入門でも取り上げています。

ログと監視:Azure Monitor と Microsoft Defender for Cloud

対策をしても、問題はゼロにはなりません。「何が起きたかを後から追える」状態にしておくことが大切です。

ログを集める:診断設定

Azure Monitor の診断設定を使うと、各リソースのログを Log Analytics ワークスペース(ログを検索・分析する場所)やストレージに送れます。注意したいのは、アクティビティログ(だれがリソースを作った・変えたか)は自動で集まる一方、リソースログは既定では集められず、診断設定を作る必要があることです(公式の説明)。Foundry、Key Vault、ストレージなど、生成AIの仕組みで使うリソースごとに設定しましょう。

状態を点検し、脅威を見つける:Microsoft Defender for Cloud(旧 Azure Security Center)

Microsoft Defender for Cloud は、クラウド全体の設定の弱点を点検し(CSPM)、サーバーやストレージなどを脅威から守る(CWPP)サービスです(公式の概要)。

Foundational CSPM(無料):推奨事項の一覧と、セキュリティの状態を点数で示すセキュアスコアが使える
Defender CSPM(有料プラン):攻撃経路の分析などに加え、社内の生成AIアプリを見つけて弱点を示す AI セキュリティ態勢管理(AI SPM)が使える
Defender for AI Services(有料プラン):生成AIアプリを狙った脅威をリアルタイムで検知する

料金は変わることがあるため、公式の料金ページで確認してください。CAF の Secure AI ガイドでは、まず Azure Resource Graph と Defender for Cloud で社内の AI 資産の一覧を作ることを勧めています(Secure AI)。

ガバナンス:Azure Policy でルールを自動で守らせる

ここまでのルールを「お願い」で済ませると、必ずどこかで守られなくなります。Azure Policy は、会社のルールを JSON で定義し、リソースの設定が守られているかを自動で評価・強制するサービスです(公式の概要)。

ルール1つをポリシー定義、複数をまとめたものをイニシアティブと呼ぶ
管理グループ・サブスクリプション・リソースグループなどに割り当てると、その下のすべてのリソースに引き継がれる
ルール違反の作成を拒否する(deny)、記録だけする(audit)、設定を足す(modify)などの動きを選べる

Azure RBAC が「だれが操作できるか」を決めるのに対し、Azure Policy は「操作した結果がルールに合っているか」を見ます。権限を持つ人でも、ルールに反するリソースは作れません。この2つを組み合わせるのが基本です。

生成AI向けのポリシーの例

Allowed Locations(組み込み):リソースを作れるリージョンを限定する
Azure AI Services resources should have key access disabled (disable local authentication)(組み込み):キー認証が有効な Foundry などのリソースを見つける・防ぐ
診断ログを Log Analytics に送ることを必須にする
公開エンドポイントを使うエージェントツールを使えないようにする

公式は、いきなり拒否(deny)で強制せず、まず記録だけ(audit)で始めて影響を確かめることを勧めています。

生成AIを使うときの注意:入力データは学習に使われる?

社内で一番よく聞かれる質問です。Microsoft Learn の「Data, privacy, and security for Foundry Models sold by Azure」には、次のように書かれています。対象は「Azure が販売するモデル(Models sold by Azure)」で、Azure OpenAI のモデルも含まれます。

よくある疑問	公式ページの記載(要約)
入力(プロンプト)や出力は、ほかの顧客に見られる?	いいえ
OpenAI などモデルの提供元に渡る?	いいえ。モデルは Microsoft の Azure 環境で動き、OpenAI の API や ChatGPT とはやりとりしない
モデルの学習や改善に使われる?	提供元のモデル改善には使われない。基盤モデルの学習には、顧客の許可や指示なしには使われない
モデルの中に保存される?	いいえ。モデルはステートレス(状態を持たない)
サービス側に保存されるデータはある?	ある。会話履歴を保持する Responses API、アップロードしたファイル、ファインチューニング用データなどは、自社の Foundry リソース内(リソースと同じ地域)に暗号化して保存され、いつでも削除できる
Microsoft の人が見ることはある?	不正利用の監視のため、フラグが立った入出力は AI などによる自動レビューの対象になり、必要に応じて権限のある Microsoft 社員が確認することがある

人による確認を望まない、機密性の高い用途の顧客は、追加の条件を満たせば不正利用監視の変更(modified abuse monitoring)を申請できます(公式の説明)。承認された場合でも自動レビューは行われることがある、と公式に書かれています。

どこで処理されるか:デプロイの種類

デプロイの種類	入出力が処理される場所
Standard などの通常のデプロイ	顧客が指定した地域(geography)の中
DataZone	指定したデータゾーンの中(例:米国内、EU 加盟国内)
Global	そのモデルが展開されているどの地域でも処理されうる

どの種類でも、アップロードしたデータなど保存されるデータは顧客が指定した地域に置かれ、変わるのは処理の場所だけと説明されています。データの所在地に社内規程がある場合は、デプロイの種類を必ず確認しましょう。

そのほかの注意点

対象モデルを確認する:上の記載は「Models sold by Azure」についてのものです。Foundry では他社のモデルも選べるため、使うモデルがどの扱いになるかを確認してください。プレビュー機能は異なるプライバシーの扱いになる場合がある、とも書かれています。
資料に仕込まれた指示に備える:文書やメールに隠れた指示で AI を操ろうとする攻撃(間接プロンプトインジェクション)があります。Foundry の Guardrails には、これを検知する Prompt Shields があります。
社員向けのルールを決める:どの区分のデータなら入力してよいかを、データ分類と合わせて周知します。毎回同じ説明を AI に渡す工夫は手元のデータを AI が読めるナレッジに変える実践ガイドも参考になります。

小さく始める手順

すべてを一度に整える必要はありません。CAF も、土台のルールを後から更新すれば各区画に反映できる設計になっています。社内向けの生成AIアプリを1つ動かすまでの、現実的な順番の例です。

目的と扱うデータを決める:使い道と、入力するデータの区分(公開・社内・機密など)を決めます。
区画を分ける:管理グループとサブスクリプションを分け、試用(Sandbox)と本番を混ぜないようにします。IaC に慣れていれば公式の accelerator を使います。
ID を固める:管理者の多要素認証と条件付きアクセスを設定し、開発者には Foundry User など必要最小限のロールだけを割り当てます。
Foundry リソースを作り、キー認証を無効にする:アプリからはマネージドID で接続します。
閉域にする:パブリックネットワークアクセスを Disabled にしてプライベートエンドポイントを作り、nslookup でプライベート IP に解決されることを確認します。
シークレットを Key Vault へ:Azure RBAC の方式で、アプリ・環境ごとに分けます。
ログと監視を始める:診断設定で各リソースのログを Log Analytics に送り、Defender for Cloud を有効にしてセキュアスコアを確認します。
ポリシーを audit で入れる:許可リージョンやキー認証の無効化などを、まず記録だけで割り当て、違反を直してから deny に切り替えます。
データ保護と社内ルール:Purview で秘密度ラベルや DLP を整え、利用ルールを社員に周知します。
定期的に見直す:セキュアスコア、ポリシーの準拠状況、ロールの割り当てを月に一度など決まった間隔で見直します。

不正利用監視の設定状況は、公式ページで紹介されている次のコマンドで確認できます。監視のためのデータ保存がオフになっている場合だけ、結果に ContentLogging が false として表示されます。

az cognitiveservices account show -n <resource_name> -g <resource_group>

AI エージェントを「言うことを聞く」状態に保つには、権限・設定・自動チェックを重ねて使うことが大切です。考え方は Claude Code を「言うことを聞く」エージェントにする4つのレイヤーでも整理しています。

チェックリスト

社内の生成AI環境を点検するときの一覧です。Well-Architected Framework のセキュリティのチェックリスト(SE:01〜SE:12)のうち、特に関係の深い項目を中心にまとめました。

分野	確認すること	主なサービス
土台	管理グループとサブスクリプションが分かれ、本番と試用が混ざっていない	Azure ランディングゾーン
ID	管理者に多要素認証と条件付きアクセスが設定されている	Microsoft Entra ID
ID	開発者・利用者に必要最小限のロールだけが割り当てられている	Azure RBAC(Foundry のロール)
ID	API キー認証が無効で、アプリはマネージドID を使っている	マネージドID
ネットワーク	パブリックネットワークアクセスが無効で、プライベートエンドポイント経由になっている	Azure Private Link
ネットワーク	VNet の中から名前がプライベート IP に解決される	プライベート DNS ゾーン
シークレット	シークレットがコードになく、Key Vault に RBAC で保管されている	Azure Key Vault
データ	データの区分と、生成AIに入力してよい範囲が決まっている	Microsoft Purview
データ	デプロイの種類(Standard・DataZone・Global)が社内規程に合っている	Microsoft Foundry
ログ	各リソースの診断設定があり、ログが Log Analytics に集まっている	Azure Monitor
監視	Defender for Cloud が有効で、推奨事項とセキュアスコアを見ている	Microsoft Defender for Cloud
ガバナンス	主要なルールがポリシーとして割り当てられている	Azure Policy
AI 固有	Guardrails(Prompt Shields を含む)が設定されている	Microsoft Foundry

まとめ

生成AIを社内で安全に使うには、AI のサービスより先に、会社全体の土台(Azure ランディングゾーン)を用意するのが近道です。
ID は Microsoft Entra ID(旧 Azure AD)で管理し、最小権限のロールとマネージドID を使い、API キー認証は無効にします。
プライベートエンドポイントを作るだけでは閉域にならないので、パブリックネットワークアクセスの無効化と DNS をセットで確認します。
シークレットは Key Vault、データの分類と保護は Purview、ログは診断設定、点検は Defender for Cloud、ルールの強制は Azure Policy が担います。
Azure が販売するモデルでは、入出力はほかの顧客や OpenAI に渡らず、許可なく基盤モデルの学習に使われないと公式に書かれています。ただし不正利用監視や保存される機能、デプロイの種類による処理場所は確認が必要です。
すべてを一度にやらず、audit から始めて少しずつ強めていきましょう。