ここまでで「動かす・調整する」はできました。残るのは、本番で使うための2つの武器です。1つは「守り」＝セキュリティ（キーをどう守り、社外からどう遮断し、危険な出力をどう止めるか）。もう1つは「拡張」＝自社データや外部システムと繋ぐ（RAG・関数呼び出し）。この2つを押さえると、Azure OpenAI が「遊び」から「業務システム」に変わります。
APIキーを本番でそのまま使うのは怖いって言われた…。あと「社内文書に基づいて答えさせたい」んだけど、それってどうやるの？
この記事は Azure OpenAI シリーズの第4回として、セキュリティ（守り）と拡張（RAG・関数）を次の流れで整理します。
- キーレス認証（マネージド ID + RBAC）を構成できる
- Private Endpoint / IP 制限 / パブリックアクセス無効化で閉域化できる
- コンテンツフィルター / 責任ある AI を理解している
- RAG（On Your Data）/ embedding / Function calling / エージェントの概念を理解している
キーレス認証｜API キーをやめてマネージド ID + RBAC に
第2回では分かりやすさ優先で API キーを使いましたが、本番でキーを使い続けるのは危険です。Git に誤ってコミットしたり、ログに出たり——キー流出は生成 AI 利用で最も多い事故の1つ。そこで推奨されるのがキーレス認証です。
キーレス認証とは、API キーの代わりにマネージド ID + RBAC（Microsoft Entra）で認証する方式です。アプリの ID に「Cognitive Services OpenAI User」ロールを与えれば、キーを一切持たずに呼び出せます。
仕組みはシンプルです。アプリ（App Service や Container Apps など）にマネージド ID を持たせ、その ID に Cognitive Services OpenAI User ロールを割り当てます。すると、アプリは実行時に Entra から一時トークンを受け取り、キーなしで Azure OpenAI を呼べます。ロール割り当ては Terraform でコード化しておくと再現性も担保できます。
# アプリのマネージド ID に OpenAI User ロールを付与（Terraform）
resource "azurerm_role_assignment" "app_openai" {
scope = azurerm_cognitive_account.openai.id
role_definition_name = "Cognitive Services OpenAI User"
principal_id = azurerm_user_assigned_identity.app.principal_id
}【ここが説明できればOK①】
「本番は API キーではなくキーレス認証。アプリのマネージド ID に Cognitive Services OpenAI User ロールを与え、Entra のトークンで呼ぶ」——これを言えればOKです。
ネットワークで閉じる｜Private Endpoint と IP 制限
認証で「誰が」を絞ったら、次は「どこから」を絞ります。既定では Azure OpenAI のエンドポイントはインターネット公開されているので、これを段階的に閉じます。
- IP 制限：許可した IP / CIDR からのみアクセスを通す。手軽な絞り込み。
- パブリックアクセスの無効化：インターネット公開そのものをオフにする。
- Private Endpoint（本命）：VNet 内にプライベート IP を生やして、社内ネットワーク（オンプレ含む）からのみ到達できるようにする。
ここは Private Endpoint と IP 制限の違いが肝です。IP 制限は「公開されている入口に許可リストの門番を置く」イメージ。対して Private Endpoint は「そもそも社内ネットワークの中に専用の入口を作る」ため、オンプレや VNet 内から閉域で到達できます。本気で閉じるなら Private Endpoint に、パブリックアクセス無効化を組み合わせるのが定石です。
【IP制限】 公開のまま、許可IPだけ通す（門番）
【パブリック無効】インターネット公開をオフ
【Private EP】 VNet内にプライベートIP → 社内から閉域到達（本命）
＋ Private DNS ゾーンで名前解決
→ 本命は「Private Endpoint ＋ パブリック無効化」【ここが説明できればOK②】
「IP 制限は公開入口に許可リスト、Private Endpoint は VNet 内にプライベート IP を生やして社内から閉域到達する本命。パブリックアクセス無効化と組み合わせる」——これを言えればOKです。
コンテンツフィルター｜危険な入出力を止める
「守り」の3つ目は、出力の安全性です。Azure OpenAI には、既定でコンテンツフィルターが働いています。
コンテンツフィルターは、入力（プロンプト）と出力（応答）の両方を暴力・憎悪・性的・自傷の4カテゴリで判定し、設定した重大度しきい値を超えたらブロックする仕組みです。
ポイントはカテゴリごとに重大度しきい値を調整できることです。各カテゴリで「安全／低／中／高」の重大度が判定され、どのレベルからブロックするかを設定します。医療・法律のような文脈では緩める、子ども向けサービスでは締める、といった用途に応じた設計が可能です。これが「責任ある AI（Responsible AI）」の実装面の入口になります。
【ここが説明できればOK③】
「コンテンツフィルターは入力・出力を暴力/憎悪/性的/自傷の4カテゴリ×重大度で判定しブロックする。カテゴリごとにしきい値を用途に合わせて調整できる」——これを言えればOKです。
RAG（On Your Data）｜自社データに基づいて答えさせる
ここから「拡張」に入ります。実務で最も需要が高いのが RAG（Retrieval-Augmented Generation）です。GPT は「学習時点の一般知識」しか持っていないので、社内規程や最新情報は知りません。それを補うのが RAG です。
RAG とは、質問に関連する文書を検索して取り出し、それをプロンプトに差し込んで、根拠のある回答を生成する手法です。ハルシネーション（もっともらしい嘘）を大きく減らせます。
その中核が embedding（ベクトル化）です。第1回で出てきた text-embedding モデルで文書を数値ベクトルに変換して Azure AI Search に格納しておき、質問もベクトル化して「意味が近い文書」を取り出します。キーワード一致では拾えない「言い回しの違う関連文書」まで見つけられるのが強みです。
【事前準備】
社内文書 → embedding でベクトル化 → AI Search に格納
【質問時】
質問 → ベクトル化 → AI Search で類似文書を検索
→ 取り出した文書をプロンプトに差し込む
→ GPT が「根拠付き・引用付き」で回答Azure OpenAI には On Your Data という機能があり、AI Search をデータソースとして接続するだけで、引用付きで自社データに答える構成をローコードで作れます。「まず最短で RAG を動かす」ならこれが便利です。
【ここが説明できればOK④】
「RAG は関連文書を検索してプロンプトに差し込み根拠付き回答を作る手法。embedding でベクトル化し AI Search で検索、On Your Data で最短構築できる」——これを言えればOKです。
Function calling とエージェント｜AI に外部システムを叩かせる
拡張のもう1つが 関数呼び出し（Function calling / Tools）です。RAG が「文書を読ませる」なら、Function calling は「システムを操作させる」拡張です。
仕組みはこうです。自分で用意した関数（在庫を調べる、予約を取る、社内 API を叩く…）のスキーマ（引数の定義）をモデルに渡すと、モデルは「この質問に答えるには、この引数でこの関数を呼ぶべきだ」と判断し、関数呼び出しを要求してきます。アプリが実際に関数を実行して結果を返すと、モデルはそれを踏まえて最終回答を作ります。
ユーザー「東京の明日の天気は？」
↓
モデル「get_weather(city="東京", date="明日") を呼んで」 ← 関数呼び出しを要求
↓
アプリが実際に関数を実行 → 結果をモデルに返す
↓
モデル「東京の明日は晴れ、最高25℃です」 ← 結果を踏まえて回答この Function calling を土台に、複数のツールを使い分けて自律的にタスクを進めるのがエージェントです。Azure では、こうしたエージェント開発をプロンプトフローや Azure AI Foundry の Agent Service でグラフ化・評価・デプロイまで行えます（本格的なエージェント構築は Foundry シリーズで詳しく扱います）。
「文書に答えさせる＝RAG」「システムを操作させる＝Function calling」。この2つが拡張の両輪。組み合わせると一気に業務システムっぽくなるよ！
【ここが説明できればOK⑤】
「Function calling は関数スキーマを渡すとモデルが引数付きで呼び出しを要求し、結果を再投入して回答する。これを土台にエージェント（プロンプトフロー/Agent Service）を組む」——これを言えればOKです。
まとめ
- 守り①：本番はキーレス認証（マネージド ID + OpenAI User ロール）
- 守り②：Private Endpoint ＋ パブリック無効化で閉域化
- 守り③：コンテンツフィルター（4カテゴリ×重大度）で危険な入出力をブロック
- 拡張①：RAG（embedding + AI Search + On Your Data）で自社データに回答
- 拡張②：Function calling でシステム操作、エージェントで自律化
守りと拡張が揃えば、あとは「本番で安定して回し続ける」運用です。最終回の第5回で、クォータ / レート制限（429対策）・PTU・監視・コスト最適化を整理して、シリーズを締めくくります。
