Microsoft Azureで生成AIやCopilot連携を設計している場合、今回の「AI Architecture Design – Azure Architecture Center」で最も重要なのは、単にモデルAPIを呼び出す設計から、Microsoft Foundryを中心に、モデル選択・エージェント・RAG・監視・権限制御・ネットワーク分離までを一体で設計する流れが強まっている点です。既存のAzure OpenAI利用が直ちに使えなくなるという話ではありませんが、新規開発や更改ではFoundry、Foundry Agent Service、Responses API、Azure Well-Architected FrameworkのAIワークロード観点を前提に確認する必要があります。Azure Architecture Centerは、AI/機械学習を含むワークロードでAzure Well-Architected FrameworkのAI guidanceに従うことを推奨しています。(Microsoft Learn)
AI Architecture Design – Azure Architecture Centerとは
「AI Architecture Design – Azure Architecture Center」は、Microsoft Azure上でAIワークロードを設計するための公式ガイドです。AIの基本概念、生成AI、言語モデル、Copilot、RAG、エージェントベースのアーキテクチャ、Foundry、Azure Machine Learning、Fabric、データ基盤、参照アーキテクチャなどを横断的に整理しています。
実務上は、次のような読者が確認すべきページです。
| 対象者 | 確認すべきポイント |
|---|---|
| Azure管理者 | Foundryリソース、RBAC、Azure Policy、ネットワーク、Private Endpoint、コスト管理 |
| 開発者 | モデル選択、Responses API、SDK、Agent Service、RAG構成、CI/CD |
| セキュリティ担当者 | コンテンツフィルター、ガードレール、プロンプトインジェクション対策、監査ログ |
| アーキテクト | Azure Well-Architected Framework、可用性、データ主権、運用設計 |
| データ担当者 | Azure AI Search、Storage、Cosmos DB、Fabric、グラウンディングデータ設計 |
特に注意したいのは、AIワークロードが通常のアプリケーションと違い、出力が常に決定的とは限らないことです。MicrosoftのWell-Architected Frameworkでは、AIワークロードは非決定的な挙動、データ設計、アプリケーション設計、運用上の課題を考慮して設計する必要があると説明されています。(Microsoft Learn)
Microsoft AzureのAI/Copilot設計で何が変わるのか
今回の要点は、Azure上のAI設計が「モデルを選んで呼び出す」段階から、「モデル、エージェント、データ、運用、ガバナンスをまとめて設計する」段階へ移っていることです。
AI Architecture Designでは、生成AIの例としてMicrosoft 365 CopilotとMicrosoft Foundryが挙げられています。Foundryは、エージェントホスティングと、GPT-5.2、Claude、Phi、Grokなどの言語モデルカタログにアクセスできるPaaSとして説明されています。これらのモデルは、コンテンツ生成、要約、画像理解、セマンティック検索、自然言語からコードへの変換、動画生成、音声対音声などのタスクに適用できます。(Microsoft Learn)
| 変更・注目点 | 実務への影響 | まず確認すること |
|---|---|---|
| Foundry中心の設計 | Azure OpenAI単体ではなく、モデル、エージェント、評価、ツールをまとめて扱う | Foundryリソースとプロジェクトの構成 |
| 複数モデルの利用 | OpenAI以外のモデルも選択肢に入る | モデルの用途、リージョン、料金、データ要件 |
| エージェント設計の重視 | チャットボットから、ツール実行や複数ステップ処理へ広がる | Agent Service、ワークフロー、権限 |
| RAGの一般化 | 社内データを根拠にした回答設計が重要になる | Azure AI Search、Storage、Cosmos DB、データ更新 |
| ガバナンス強化 | 管理者がAI資産を横断管理する必要がある | RBAC、Azure Policy、監視、コストアラート |
| API・SDK移行 | 既存コードの修正が必要になる場合がある | Responses API、SDKバージョン、エンドポイント |
Foundryは「モデル置き場」ではなくAI開発・運用基盤
Microsoft Foundryは、企業向けAI運用、モデルビルダー、アプリケーション開発のためのAzure PaaSとして位置付けられています。モデル、エージェント、ツールを単一の管理グループで扱い、トレース、監視、評価、RBAC、ネットワーク、ポリシーなどのエンタープライズ向け機能を提供します。(Microsoft Learn)
従来のAzure AI StudioやAzure AI Foundry、Azure AI Servicesは、現在のMicrosoft FoundryやFoundry Toolsという形に整理されています。公式情報では、Assistants APIからResponses API、月次のapi-version指定から/openai/v1/の安定ルート、複数SDK・複数エンドポイントから統一されたプロジェクトクライアントと単一プロジェクトエンドポイントへ移る構図が示されています。(Microsoft Learn)
新規構築ではFoundryリソースとプロジェクト境界を先に決める
Foundryでは、上位のFoundryリソースがガバナンスやモデルデプロイ、セキュリティ設定を担い、その下にプロジェクトが作られます。プロジェクトは、チームやユースケースごとの開発・評価・エージェント管理の境界になります。Storage、Key Vault、Azure AI Searchなどの接続先リソースはFoundryとは別のAzureリソースであり、それぞれネットワーク、アクセス制御、コンプライアンス設定を管理する必要があります。(Microsoft Learn)
実務では、次のように分けると管理しやすくなります。
| 設計単位 | 推奨例 | 避けたい例 |
|---|---|---|
| Foundryリソース | 事業部、システム、環境単位 | 全社で1つに集約しすぎる |
| プロジェクト | ユースケース、チーム、PoC単位 | 個人ごとに乱立させる |
| モデルデプロイ | 用途別に名前・タグを付ける | 目的不明のデプロイを残す |
| 接続先データ | 専用Storage、専用AI Search、専用Cosmos DB | 既存業務データを無計画に直結する |
| 環境分離 | dev、test、prodを分ける | Playgroundと本番を同一管理にする |
Azure OpenAIからFoundryへの移行で確認すべきこと
既存のAzure OpenAIリソースは、Foundryリソースへアップグレードできます。Microsoftの公式情報では、アップグレードにより、より広いモデルカタログ、Agent Service、評価機能へアクセスでき、既存のAzure OpenAI APIエンドポイント、作業状態、セキュリティ構成を保持できると説明されています。(Microsoft Learn)
ただし、移行は「ボタンを押せば終わり」ではありません。特に管理者は、次の点を事前に確認してください。
| 確認項目 | 理由 |
|---|---|
| リージョン対応 | FoundryのモデルやAgent Serviceはリージョンによって利用可否が異なる |
| マネージドID | アップグレードや自動化、接続先アクセスで必要になる |
| RBACとAzure Policy | 広い権限設定がFoundry専用機能への意図しないアクセスにつながる可能性がある |
| Private EndpointとDNS | Foundry機能を使うには追加FQDNの名前解決が必要になる場合がある |
| Terraform/Bicepのバージョン | 非破壊更新やkind変更で失敗しないようにする |
| ロールバック条件 | 非OpenAIモデルのデプロイやFoundry固有リソースを削除しないと戻せない場合がある |
Private Endpoint利用環境ではDNS追加が重要
Private Network構成でAzure OpenAIからFoundryへ移行する場合は、DNS設定が大きな落とし穴になります。Foundryリソースは、{custom-domain}.openai.azure.com、{custom-domain}.services.ai.azure.com、{custom-domain}.cognitiveservices.azure.comの3種類のFQDNで機能を公開します。公式情報では、必要なDNSゾーンまたは条件付きフォワーダーを構成し、services.ai.azure.comとcognitiveservices.azure.com向けのIP構成を作成するためにPrivate Link Endpointの更新、または削除・再作成が必要になると説明されています。(Microsoft Learn)
この作業を忘れると、管理画面では移行済みに見えても、アプリケーションやSDKからエージェント、ツール、Foundry APIへ接続できないことがあります。
開発者が注意すべきAPI・SDK移行
開発者が最も早く確認すべきなのは、SDKとAPIの移行スケジュールです。公式の移行ガイドでは、azure-ai-inferenceパッケージは2026年5月30日にリタイア予定、Assistants APIは2026年8月26日に終了予定とされ、Foundry Agents ServiceとResponses APIへの移行が案内されています。(Microsoft Learn)
| 旧来の考え方 | 現在の方向性 | 対応 |
|---|---|---|
AzureOpenAI()中心 | 標準のOpenAI()クライアントとFoundryエンドポイント | 認証・base URLを見直す |
| Assistants API | Responses API / Agents v2 | エージェント作成・会話管理コードを更新 |
azure-ai-projects 1.x | azure-ai-projects 2.x | ポータル体験とSDKバージョンを合わせる |
| 複数エンドポイント管理 | 単一プロジェクトエンドポイント | 環境変数とIaCを整理する |
| ポータルで手作業作成 | エージェント定義をコード化 | CI/CDでバージョン管理する |
特に、SDKのバージョンとポータル体験が一致しないと、ModuleNotFoundError、予期しないAPI挙動、404、MethodNotAllowedなどのエラーが起きやすくなります。公式ガイドでも、2.x SDKサンプルを1.x環境で使う、またはその逆を行うとエラーになると注意されています。(Microsoft Learn)
エージェントは「画面で作って終わり」にしない
Foundry Agent Serviceは、AIエージェントの構築、デプロイ、スケーリングを行うフルマネージド基盤です。エージェントはモデル、指示、ツールの組み合わせで構成され、外部データへのアクセス、ツール呼び出し、複数ステップの意思決定を行えます。Prompt agents、Workflow agents、Hosted agentsという種類があり、Hosted agentsはパブリックプレビューとして提供されています。(Microsoft Learn)
開発現場では、エージェントを次のように扱うべきです。
- システムプロンプト、接続、ツール、モデル設定をソース管理する
- エージェント定義をCI/CDでデプロイする
- 本番反映前に評価データセットでテストする
- バージョンごとに差分とロールバック手順を残す
- ポータル上の手作業変更を本番運用に混ぜない
Azure Architecture Centerの参照アーキテクチャでも、エージェント定義、接続、システムプロンプト、構成パラメーターをソース管理し、CI/CDパイプラインで小さく安全にデプロイすることが推奨されています。(Microsoft Learn)
RAGとエージェント設計で確認すべきデータ構成
AI Architecture Designでは、RAGは言語モデルに外部の根拠データを与えるアーキテクチャパターンとして説明されています。RAGはベクター検索ストアに限定されず、任意のデータストア技術を利用できます。また、Foundry IQ knowledge basesは、Foundryエージェントが必要とするグラウンディングデータのターンキーなRAGアプローチとして紹介されています。(Microsoft Learn)
RAGを導入する場合は、モデル性能だけでなく、データ運用を設計してください。
| 項目 | 確認内容 |
|---|---|
| データソース | SharePoint、Blob Storage、社内DB、FAQ、マニュアルなど |
| 更新頻度 | 日次、週次、リアルタイムのどれが必要か |
| 検索方式 | キーワード検索、ベクター検索、ハイブリッド検索 |
| アクセス制御 | ユーザーごとに見える文書を制限できるか |
| 根拠表示 | 回答に引用元や参照箇所を出せるか |
| 評価 | 正答率、根拠一致、回答漏れ、誤回答率を測るか |
| 削除対応 | 退職者情報、機密文書、古い規程を除外できるか |
よくある失敗は、PoCでは小さな文書セットでうまく動いたものの、本番で権限、文書更新、重複データ、古い規程、検索ノイズに対応できなくなるケースです。RAGは「検索を足す機能」ではなく、データライフサイクル管理を含むアーキテクチャとして扱う必要があります。
本番展開ではネットワーク、ID、監視を最初から組み込む
Azure Architecture CenterのFoundryチャット参照アーキテクチャでは、App Service、Application Gateway、Web Application Firewall、Private Endpoint、Key Vault、Storage、Azure AI Search、Cosmos DB、Foundry、Agent Service、Azure Monitor、Application Insightsなどを組み合わせた構成が示されています。チャットUIからエージェントへの通信はPrivate Endpoint経由で行い、Foundryポータルとエージェントへのパブリックアクセスをブロックし、アウトバウンド通信はAzure Firewall経由で制御する構成です。(Microsoft Learn)
本番展開前に、最低限次の設定を確認してください。
| 分野 | 確認すべき設定 |
|---|---|
| ID | Microsoft Entra ID、マネージドID、最小権限のRBAC |
| ネットワーク | VNet統合、Private Endpoint、DNS、Azure Firewall、WAF |
| シークレット | Key Vault、ローカル認証の扱い、APIキーの保管方法 |
| 監視 | Azure Monitor、Application Insights、Log Analytics、診断設定 |
| セキュリティ | コンテンツフィルター、ガードレール、Defender、Purview連携 |
| コスト | トークン使用量、モデル別料金、予算、アラート |
| 可用性 | リージョン、ゾーン冗長、フェイルオーバー方針 |
ガードレールとコンテンツフィルターは後付けにしない
Foundryでは、モデルやエージェントの推論パイプラインにコンテンツ安全性の制御を統合できます。ガードレールでは、検出するリスク、スキャンする介入点、検出時の応答アクションを定義できます。入力、出力だけでなく、ツール呼び出しやツール応答のスキャンも考慮対象になります。(Microsoft Learn)
社内利用でも、次のようなリスクは本番前に評価すべきです。
- プロンプトインジェクションにより、内部指示が無視される
- ユーザーが見てはいけない文書をRAGが参照する
- エージェントが外部APIを過剰に呼び出す
- 誤った要約が業務判断に使われる
- 個人情報や機密情報がログや分析基盤に複製される
- 長大なプロンプトによりコストが急増する
Microsoft Defender for AI servicesは、エージェントのリクエストや応答に基づくjailbreaking試行やデータ漏えいに関するアラートに対応し、Microsoft Purviewとの連携も説明されています。(Microsoft Learn)
コスト管理はモデル選定とトークン監視が鍵
AI/Copilot系のワークロードは、リクエスト数だけでなく、入力トークン、出力トークン、RAGで投入する文脈量、エージェントのツール呼び出し回数、評価処理、ファインチューニング、画像生成などでコストが変わります。
参照アーキテクチャでは、要件を満たす最も低コストなモデルを選ぶこと、Microsoft Cost Managementやモデル使用量メトリックでトークン使用量を追跡すること、予算と異常検知アラートを設定すること、Playgroundの利用を本番では制限することが推奨されています。(Microsoft Learn)
| コストが増えやすい原因 | 対策 |
|---|---|
| 毎回長いシステムプロンプトを送る | 共通指示を整理し、必要な文脈だけ渡す |
| RAGで大量の文書チャンクを投入する | 検索精度を上げ、上位件数を調整する |
| 高性能モデルを全処理に使う | 分類、要約、回答生成でモデルを分ける |
| エージェントがツールを何度も呼ぶ | 最大ステップ数、タイムアウト、再試行制御を設ける |
| Playgroundを自由利用させる | 検証環境に限定し、予算アラートを設定する |
| 本番と検証が同じデプロイを使う | 環境ごとにリソースとクォータを分ける |
モデルデプロイタイプも重要です。Foundryでは、Global、Data Zone、Regional、Standard、Provisioned、Batchなどのデプロイタイプがあり、データ処理場所、課金方式、レイテンシ、スループットの考え方が異なります。リージョンやデータ主権の要件がある場合は、コストだけでなく処理場所を確認してください。(Microsoft Learn)
データ主権と可用性の注意点
Foundryでは、保存データは指定されたAzure geographyに保存されます。一方、推論データの処理場所はデプロイタイプによって変わり、GlobalデプロイではAzure管理のクロスリージョン処理、Data Zoneでは米国またはEUのゾーン内、StandardまたはRegionalではデプロイリージョン内で処理されます。公式情報では、Foundryは自動クロスリージョンフェイルオーバーをサポートしていないため、マルチリージョン可用性が必要な場合は、対象リージョンごとにFoundryリソースを展開し、データ同期とルーティングをアプリケーション層で管理する必要があると説明されています。(Microsoft Learn)
日本企業で特に注意したいのは、次のようなケースです。
| ケース | 注意点 |
|---|---|
| 個人情報を含む問い合わせ対応 | ログ、プロンプト、RAG検索結果の保存先を確認する |
| 金融・医療・公共系システム | データ処理リージョン、監査ログ、暗号化、承認フローを確認する |
| グローバル利用 | 国・地域ごとのデータ規制とモデル提供リージョンを確認する |
| 障害時の継続運用 | 別リージョンのFoundryリソース、DNS切替、データ同期を設計する |
| 社内ナレッジ検索 | ユーザー権限に応じた文書フィルタリングを実装する |
実務で使える移行・展開チェックリスト
AI Architecture Designの更新内容を実務に落とし込むなら、次の順序で確認すると抜け漏れを減らせます。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | 既存AI資産を棚卸しする | Azure OpenAIリソース、モデル、API、SDK、エンドポイント一覧 |
| 2 | ユースケースを分類する | チャット、RAG、要約、検索、エージェント、Copilot連携の分類表 |
| 3 | Foundry構成を決める | リソース、プロジェクト、環境分離、命名規則 |
| 4 | リージョンとモデルを確認する | 利用可能モデル、デプロイタイプ、データ処理場所 |
| 5 | RBACとPolicyを見直す | 最小権限ロール、禁止モデル、利用可能リージョン |
| 6 | ネットワークを設計する | Private Endpoint、DNS、Firewall、WAF、VNet統合 |
| 7 | SDKとAPIを更新する | Responses API移行計画、SDKバージョン、認証方式 |
| 8 | RAGデータを整備する | データソース、検索方式、更新頻度、権限制御 |
| 9 | 評価と監視を組み込む | 評価データ、Application Insights、Log Analytics、アラート |
| 10 | 段階展開する | PoC、検証、本番、ロールバック手順 |
最初から全社展開するのではなく、1つの業務ユースケースで「モデル選択、RAG、エージェント、監視、コスト、権限」を一通り検証してから横展開するのが安全です。
失敗しやすいポイントと回避策
| 失敗しやすいポイント | 何が起きるか | 回避策 |
|---|---|---|
| Foundryを単なる新ポータルとして扱う | RBAC、プロジェクト、接続先管理が整理されない | リソース境界とプロジェクト境界を設計書に明記する |
| 既存RBACをそのまま使う | 想定外のユーザーがFoundry機能を利用できる | Azure Policyとカスタムロールを見直す |
| DNS変更を忘れる | Private Endpoint環境でAPI接続に失敗する | 3種類のFQDNとPrivate Link構成を検証する |
| Preview機能を本番前提にする | 仕様変更や制限により運用リスクが出る | GA/Previewラベルを確認し、本番利用可否を判断する |
| エージェントをポータルで手作業変更する | 差分追跡やロールバックができない | Agent as CodeとCI/CDを導入する |
| トークン使用量を監視しない | 月末に想定外の請求が発生する | 予算、クォータ、異常検知アラートを設定する |
| RAGの権限制御を後回しにする | ユーザーが閲覧権限のない情報を参照する | 文書単位・ユーザー単位のアクセス制御を設計する |
| モデル名をコードに直書きする | モデル切替やリージョン変更で修正範囲が広がる | 環境変数、設定ファイル、デプロイ名で抽象化する |
まず管理者と開発者がやるべきこと
今回のAI Architecture Design – Azure Architecture Centerの要点を踏まえると、Microsoft AzureでAI/Copilot系システムを運用する組織は、次の5つを優先してください。
- 既存のAzure OpenAI、AI Search、Storage、Cosmos DB、SDK、API利用状況を棚卸しする
- 新規開発はFoundryリソース、プロジェクト、Agent Service、Responses APIを前提に設計する
- RBAC、Azure Policy、Private Endpoint、DNS、Key Vault、マネージドIDを移行前に確認する
- RAGとエージェントは、評価、監視、ガードレール、コスト管理まで含めて本番設計する
azure-ai-inferenceやAssistants APIを使っているコードは、移行期限を待たずに検証環境で更新を始める
AIの導入は、モデルを選ぶだけでは成功しません。Microsoft Azure上で安全に運用するには、Foundryを中心に、データ、ID、ネットワーク、監視、コスト、評価を最初から設計に含めることが重要です。まずは小さなユースケースでFoundry構成とRAG/エージェント運用を検証し、その結果を標準アーキテクチャとしてチームに展開しましょう。
コメント