【Azure AI入門②】Azure AI Foundryのリソース・認証・閉域｜プロジェクト構成とPrivate Endpointで安全な土台を作る

Azure AI Foundry を「触ってみる」だけなら、ポータルでプロジェクトを作ってプレイグラウンドで遊べば十分です。ですが、チームや会社で本番運用するとなると、話は一気に変わります。「誰がアクセスできるのか（権限）」「APIキーをどう守るのか（認証）」「社外から叩かれないか（ネットワーク）」——この土台の設計を飛ばすと、後から必ず痛い目を見ます。

プロジェクトとかリソースとか、階層がよく分からない…。あと本番でAPIキーを直書きするのは怖いって言われたけど、じゃあどうすればいいの？

この記事は Azure AI Foundry シリーズの第2回として、Foundry を「安全に立ち上げる土台」にフォーカスします。具体的には次の流れで整理します。

• リソースとプロジェクトの階層（土台と作業場の関係）を理解している
• 接続（Connections）で外部リソースを安全に参照できる
• エンドポイント / API キーを確認し、RBAC で権限を付与できる
• キーレス認証（マネージド ID + Entra）で接続できる
• ファイアウォール / Private Endpoint で閉域化できる

「モデルを呼ぶ」より一段手前の、地味だけど一番大事な話です。ここを固めておくと、後続の記事（モデルデプロイ・エージェント・RAG）がすべて安全な土台の上に乗ります。各セクション末に「ここが説明できればOK」の自己チェックを置いています。

リソースとプロジェクトの階層｜土台と作業場

Foundry を最初に触ると、「Foundry リソース」と「プロジェクト」という2つの言葉が出てきて混乱しがちです。まずこの階層を押さえましょう。

Foundry リソースが「土台（Azure 上の器）」、その中に作るプロジェクトが「実際の作業場」です。モデルのデプロイ・エージェント・接続・評価といった成果物は、すべてプロジェクト単位で束ねられます。

イメージは「会社（リソース）の中にプロジェクトチーム（プロジェクト）がいくつもある」感じです。1つのリソースの下に、用途別・チーム別にプロジェクトを並べて、それぞれで別々のモデルやエージェントを開発します。

Foundry リソース（土台・Azure 上の器）
│
├─ プロジェクトA（チャットボット開発）
│   ├─ gpt-4o デプロイ
│   ├─ エージェント
│   └─ AI Search への接続
│
└─ プロジェクトB（社内文書RAG）
    ├─ gpt-4o-mini デプロイ
    └─ embedding デプロイ

→ 成果物は「プロジェクト」に紐づく
   権限もプロジェクト単位で分けられる

もう1つ知っておきたいのが、プロジェクトに2つの種類があることです。用途で選び分けます。

迷ったら、まずは軽量なFoundry プロジェクトで始めて問題ありません。組織で共有インフラをガッチリ統制したくなったら、ハブベースを検討する——という順番で十分です。

【ここが説明できればOK①】
「Foundry リソースは土台で、その中のプロジェクトが作業場。モデル・エージェント・接続はプロジェクト単位で束ねられ、権限もプロジェクトで分けられる」——これを言えればOKです。

接続（Connections）｜外部リソースを安全に参照する

Foundry のプロジェクトは、単体で完結するわけではありません。RAG なら AI Search、ファイルを扱うなら Storage、別リージョンの Azure OpenAI ……と、外部のリソースと連携します。このときに使うのが接続（Connections）です。

接続の何が嬉しいかというと、資格情報（キーや接続文字列）をコードに書かずに済む点です。接続を一度プロジェクトに登録しておけば、資格情報は裏側で安全に保持され、アプリからは「接続名」で参照するだけになります。可能なら接続自体もマネージド ID ベースにして、キーそのものを持たない形が理想です。

【ここが説明できればOK②】
「接続（Connections）は AI Search / Storage / 他の Azure OpenAI などを、資格情報をコードに書かずにプロジェクトから参照する仕組み」——これを言えればOKです。

エンドポイント / API キーの確認と RBAC での権限付与

プロジェクトを作ったら、アプリから呼び出すためにエンドポイント URL・API キー・api-version の3点を確認します。ポータルのプロジェクト画面、または Azure CLI から取得できます。

ここで重要なのが権限（RBAC）です。「キーを知っていれば誰でも叩ける」状態は本番では危険なので、誰に・どのスコープで・何ができるかをロールで設計します。Foundry には用途別の組み込みロールが用意されています。

ポイントは最小権限です。アプリには「推論できるだけ」の Azure AI User を、開発者には Azure AI Developer を、というふうに役割に必要な分だけを対象スコープ（リソース or プロジェクト）で割り当てます。ロール割り当ては Terraform でコード化しておくと、環境の再現性も担保できます。

# アプリのマネージド ID に「Azure AI User」相当のロールを付与する例（Terraform）
resource "azurerm_role_assignment" "app_ai_user" {
  scope                = azurerm_ai_foundry_project.this.id
  role_definition_name = "Cognitive Services OpenAI User"
  principal_id         = azurerm_user_assigned_identity.app.principal_id
}

【ここが説明できればOK③】
「エンドポイント・キー・api-version を確認し、Azure AI Developer / User などの組み込みロールを最小権限で対象スコープに割り当てる」——これを言えればOKです。

キーレス認証｜API キーをやめてマネージド ID + Entra に

API キーは手軽ですが、漏洩リスクとローテーションの手間がつきまといます。Git に誤ってコミットしたり、ログに出たり——キー流出は生成 AI 利用で最も多い事故の1つです。そこで本番で推奨されるのがキーレス認証です。

キーレス認証とは、API キーの代わりにマネージド ID + Microsoft Entraでトークンを取得して認証する方式です。キーという「持ち歩く秘密」を、そもそも存在させません。

仕組みはシンプルです。アプリ（App Service や Container Apps など）にマネージド ID を持たせ、その ID に前節の Azure AI User ロールを与えておきます。すると、アプリは実行時に Entra から一時トークンを受け取り、キーを一切持たずに Foundry を呼び出せます。

「検証はキーでサッと、本番はキーレス（マネージドID＋Entra）」。この使い分けが言えれば、認証まわりは実務レベルだよ！

【ここが説明できればOK④】
「本番は API キーではなく、マネージド ID + Entra のキーレス認証。アプリの ID に Azure AI User ロールを与え、キーを持たずにトークンで呼ぶ」——これを言えればOKです。

ネットワークで閉じる｜ファイアウォールと Private Endpoint

認証で「誰が」を絞ったら、次は「どこから」を絞ります。既定では Foundry のエンドポイントはインターネット公開されているので、社外の未知の経路から到達できてしまいます。これを段階的に閉じていきます。

閉域化には強さの段階があります。要件に応じて選びます。

• ① ファイアウォール（許可 IP / 選択した VNet）：特定のグローバル IP や CIDR、選んだサブネットからのみ許可し、それ以外を拒否。手軽な絞り込み。
• ② パブリックアクセスの無効化：インターネット公開そのものをオフにする。
• ③ Private Endpoint（閉域化の本命）：VNet 内にプライベート IP を生やして、社内ネットワーク（オンプレ含む）からのみ到達できるようにする。

ここはPrivate Endpoint と ファイアウォールの違いが肝です。ファイアウォールは「公開されている入口に、許可リストの門番を置く」イメージ。対して Private Endpoint は「そもそも社内ネットワークの中に専用の入口を作る」ため、オンプレや VNet 内から閉域で到達できます（＝プライベート IP が生える）。本気で閉じるなら Private Endpoint です。

【段階①】ファイアウォール
  インターネット公開のまま、許可IP/サブネットだけ通す
  （手軽・でも入口自体は公開されている）

【段階③】Private Endpoint（本命）
  VNet ─ プライベートIP ─ Foundry
  社内ネットワーク/オンプレからのみ到達
  ＋ Private DNS ゾーンで名前解決
  ＋ マネージドVNet で「出ていく通信」も制御

→ 「入口を社内に作る」のが Private Endpoint
   「公開入口に門番を置く」のがファイアウォール

Private Endpoint を使うときの忘れがちな相棒が Private DNS ゾーンです。プライベート IP を生やしても、名前解決（FQDN → プライベート IP）が効かないと繋がりません。Private DNS ゾーンを VNet にリンクして初めて閉域が完成します。さらに、マネージド VNet を使えば Foundry から外へ出ていく通信（アウトバウンド）も制御でき、「入りも出も閉じた」状態にできます。

【ここが説明できればOK⑤】
「ファイアウォールは公開入口に許可リストの門番を置く方式、Private Endpoint は VNet 内にプライベート IP を生やして社内から閉域で到達する本命。Private DNS ゾーンで名前解決、マネージド VNet で送信も制御」——これを言えればOKです。

まとめ

今回は Foundry を安全に立ち上げる土台を、階層 → 接続 → 権限 → 認証 → ネットワークの順で固めました。

• リソース（土台）＞プロジェクト（作業場）の階層。成果物と権限はプロジェクト単位
• 接続（Connections）で外部リソースの資格情報をコードに書かずに参照
• RBAC で Azure AI Developer / User を最小権限割り当て
• 本番はキーレス（マネージド ID + Entra）。キーは持たない
• 閉域はファイアウォール →無効化 → Private Endpointの段階。本命は PE＋Private DNS

土台が固まったら、次はいよいよモデルを選んでデプロイし、アプリから呼び出す実践です。第3回では、モデルカタログの見方・サーバーレス API とマネージドコンピュートの違い・SDK での呼び出しまでを整理します。

あわせて読みたい

• 【Azure AI入門①】Azure AI Foundry / Azure OpenAIとは？用語を整理して全体像をつかむ
• Azure VNet入門⑥｜Private Endpoint・閉域設計とセキュリティ運用
• Azure入門｜クラウドとは・VMかApp Serviceか（はじめの地図）