Azureで生成AIやエージェント型AIを作るとき、どのサービスをどう組み合わせれば「全体像」が描けるのかで迷いがちです。本記事ではMicrosoft公式の参照アーキテクチャ図・設計ガイドを厳選し、PoCから企業向け基盤、RAG、マルチエージェントまで段階的に整理します。
Azure 生成AI／エージェント型AIの「アーキテクチャ図」を探す前に押さえるべきこと
生成AI（GenAI）やエージェント型AI（Agentic AI）の設計は、単に「モデルを呼ぶ」だけでは終わりません。ネットワーク隔離（Private Link／VNet）、認証（Microsoft Entra ID）、知識連携（RAG）、ツール実行、監視・評価、ガバナンスまで含めて初めて“企業で使える”全体像になります。
このとき役立つのが、Microsoftが公開している参照アーキテクチャ（Reference Architecture）です。従来のAzure Data FactoryやDatabricksの参照アーキテクチャ図のように、「どのサービスをどう組み合わせるか」を俯瞰でき、さらに実装例（GitHub）やVisioファイルまで付いてくるものが増えています。
名称が揺れるポイント：Azure AI Foundry は Microsoft Foundry にリブランディング
最近ドキュメントを探していて混乱しやすいのが名称です。Microsoft Learnの一部では、URLに「azure-ai-foundry」と残りつつ、ページ本文ではMicrosoft Foundryと表記されるケースがあります。これはAzure AI Foundry が Microsoft Foundry へ名称変更されたためです。検索時は「Azure AI Foundry」「Microsoft Foundry」の両方で探すと取りこぼしが減ります。
また、ポータルには「classic」と「new」の2系統があり、利用している体験（UI）によってドキュメントが分かれます。まずは自分がどちらのポータル／プロジェクト体系で動いているかを確認すると、参照アーキテクチャを読み替えやすくなります。
公式アーキテクチャ図の集約ポイント：Azure Architecture Center（AI & ML）
「まず公式の図を一気に眺めたい」なら、入口としてAzure Architecture Center の AI Architecture Designが最短です。Foundry（旧Azure AI Foundry）やAzure OpenAI、Azure AI Search、データ基盤（Fabric／Data Factory／Databricks）など、生成AIに関係する設計リソースへの導線がまとまっています。
ここから先は、個別の参照アーキテクチャ（Basic／Baseline／Landing Zone）や、RAG、マルチエージェントの設計パターンへと深掘りしていく流れが一番スムーズです。
生成AI／エージェント型AI向け 公式参照アーキテクチャ・設計ガイド（厳選）
| リソース名 | 狙い | 向いている段階 | 図で分かること | 公式リンク |
|---|---|---|---|---|
| Basic Microsoft Foundry Chat | 最小構成で「動く全体像」を掴む | 学習／PoC | App Service + Foundry Agent + 検索/モデル呼び出しの基本フロー | Microsoft Learn |
| Baseline Microsoft Foundry Chat | 企業向けの本番設計（ネットワーク/セキュリティ強化） | 本番設計 | Private Link、Firewall、BYO依存リソース、可用性設計 | Microsoft Learn |
| Baseline Foundry Chat in Landing Zone | ランディングゾーン前提の分業（プラットフォーム/ワークロード） | 組織展開／複数チーム運用 | Hub-Spoke、中央DNS/Firewall、ポリシー、サブスクリプション分離 | Microsoft Learn |
| RAG Solution Design & Evaluation Guide | RAGを科学的に設計・評価する | RAG導入／改善 | アプリフローとデータパイプライン、chunk/embedding/index設計の論点 | Microsoft Learn |
| AI Agent Orchestration Patterns | マルチエージェントの協調パターンを体系化 | エージェント設計 | Sequential/Concurrent/Group Chat/Handoff/Magentic などの構造 | Microsoft Learn |
| Baseline Agentic AI Systems Architecture | “行動するAI”のエンドツーエンド全体像 | 高度な自動化／業務実行 | Container Apps/AKS、APIM、サンドボックス、メッセージング等 | Microsoft Tech Community |
上の6つを揃えて読むだけで、「まず動く構成」→「本番の基本形」→「企業の基盤化」→「RAGで社内データに接続」→「マルチエージェント化」→「業務実行まで含むエージェント基盤」まで、設計の階段を迷わず登れます。
最短で全体像を掴むおすすめの読み順
- まず動かす：Basic Microsoft Foundry Chat（“何がどこに繋がるか”を把握）
- 本番の型を見る：Baseline Microsoft Foundry Chat（Private LinkやFirewall、BYO依存など本番の前提を学ぶ）
- 組織に載せる：Landing Zone版（プラットフォームチームとワークロードチームの分業・Hub-Spokeの落とし込み）
- 精度を上げる：RAG設計・評価ガイド（chunk/embedding/index/評価の論点を固める）
- 複数エージェントにする：AI Agent Orchestration Patterns（協調の型を選べるようにする）
- 業務を動かす：Baseline Agentic AI Systems Architecture（実行系・サンドボックス・APIMなど追加要素を補う）
Basic（PoC）アーキテクチャの見どころ：最小構成で“つながり”を理解する
Basic Microsoft Foundry Chatは、学習やPoC向けのシンプルな参照アーキテクチャです。App Service上のWebアプリがチャットUIを提供し、Foundry Agent Service上のエージェントが「検索で根拠を取りに行く→モデルに渡す→応答する」流れをオーケストレーションします。ログはApplication Insightsに流れます。
特に押さえたいポイントは次の3つです。
- 認証の入口：App ServiceのEasy AuthでMicrosoft Entra ID認証を前提にしているため、社内ユーザー向けのチャットを想定した“現実的なPoC”にしやすい
- エージェントがRAGをまとめる：Foundry Agent ServiceがAI Search（または外部知識）から根拠を取り、モデルに渡す構造が図で分かる
- PoCの限界も明示：本番に必要なネットワーク隔離などが意図的に省略されているため、次にBaselineへ移る理由が理解できる
「まずは動くものを作って、社内関係者に見せたい」「UI〜エージェント〜検索〜モデルの接続を手早く試したい」というときに、最初の地図として非常に使いやすいです。
Baseline（本番）アーキテクチャの見どころ：セキュリティと運用を“図で”固める
Baseline Microsoft Foundry Chatは、企業向けの本番設計を意識して、Private Linkによる閉域化、Azure Firewallによる送信制御、可用性（ゾーン冗長）、監視などが盛り込まれています。チャットUIはApp Serviceで動き、Application Gateway + WAFで入口を守りつつ、エージェントはFoundry Agent Serviceでホストされます。
Baselineの図で「サービスの組み合わせ」が一気に具体化する代表例が、以下の構造です。
- インターネット入口：Application Gateway + WAF
- アプリ：App Service（UI/API）
- オーケストレーション：Foundry Agent Service（エージェント実行）
- 知識ストア：Azure AI Search（Private Endpoint経由）
- 会話・状態：Cosmos DB / Storage（エージェントの依存リソースとして“持ち込み”）
- 鍵・秘密情報：Key Vault
- 送信（Egress）：Azure Firewall経由で制御
ここで重要なのは、Foundry Agent Serviceの「標準セットアップ（Bring your own network / storage）」を前提に、会話履歴や状態保存に使うCosmos DB・Storage・AI Searchなどを自分のサブスクリプション側で管理する設計になっている点です。セキュリティ・BC/DRの観点で、運用主体が明確になります。
さらに、BaselineにはVisioファイルのダウンロードが用意されており、社内の設計資料に転用しやすいのも大きなメリットです。
Landing Zone（企業展開）アーキテクチャの見どころ：分業とガバナンスを前提にする
チームや部署が増えてくると、「PoCや単一チームの本番」を超えて、プラットフォームチーム（ネットワーク/ポリシー/共通運用）とワークロードチーム（アプリ/エージェント/データ）の分業が必要になります。その前提を図に落としたのが、Baseline Chat in an Azure Landing Zoneです。
Landing Zone版のアーキテクチャ図は、上段にアプリケーション用サブスクリプション（spoke）、下段にプラットフォーム用サブスクリプション（hub）を分け、Hub-Spoke構成と中央集約型のFirewall/DNSなどを視覚化しています。たとえば、ワークロードの送信（Egress）はhub側Firewallで制御し、Private DNSやDNS Private Resolverなどの要件も整理されます。
「生成AIだけ特別扱いして例外ネットワークにしたくない」「すでにAzure Landing Zoneを採用していて、その中にGenAIを安全に載せたい」という企業では、Landing Zone版が設計レビューの共通言語になります。
“図を眺める”から“設計に使う”へ：参照アーキテクチャの使い分け早見表
| 目的 | 最初に見るべき資料 | 次に深掘りする資料 | 補足 |
|---|---|---|---|
| とにかく動くPoCを作りたい | Basic Microsoft Foundry Chat | Baseline Microsoft Foundry Chat | PoCで得た負荷/コスト/精度の実測をBaselineの設計判断に反映する |
| 最初から本番を見据えたい | Baseline Microsoft Foundry Chat | Landing Zone版、RAGガイド | ネットワーク・運用・評価を同時に設計する |
| 複数部署で横展開したい | Landing Zone版 | AI Agent Orchestration Patterns | 「中央資産（ネットワーク/ポリシー）」と「各チームのエージェント」を分離して考える |
| 社内文書を根拠に回答させたい（RAG） | RAG設計・評価ガイド | Baseline/ Landing Zone（運用要件を追加） | RAGは“検索の品質”が命。評価プロセスを最初から組み込む |
| 業務を実行するエージェントにしたい | AI Agent Orchestration Patterns | Baseline Agentic AI Systems Architecture | ツール実行・権限分離・サンドボックスなど、チャット以上の要素が増える |
RAGの設計図：アプリフローとデータパイプラインを分けて考える
RAG（Retrieval-Augmented Generation）は、アーキテクチャとしてはシンプルでも、設計・評価の論点が多い領域です。MicrosoftのRAG設計・評価ガイドは、アプリ側の問い合わせフローとデータ側の取り込み・前処理フローを分けて整理しているのが特徴です。
RAGアプリ側の基本フロー（問い合わせ時）
- ユーザーがUIで質問
- オーケストレーター（Agent Framework / Semantic Kernel / Foundry Agent Service など）が検索クエリを作る
- Azure AI Searchで検索（ベクトル/全文/ハイブリッドなど）
- 上位結果をプロンプトに詰めてモデルへ
- 回答をUIへ返す
この流れを押さえておくと、Baseline Chatの「エージェントがAI Searchへ行き、モデルへ渡す」構造と、RAGの一般形が一致していることが見えてきます。
RAGデータ側の基本フロー（取り込み時）
RAGの品質は「検索できる形にデータを整える」工程でほぼ決まります。ガイドでは、ドキュメントを取り込んだ後にchunking、metadata付与（enrichment）、embedding、indexへの永続化という流れを高レベルで整理しています。
| 工程 | 目的 | Azureでの代表例 | 設計で決めること |
|---|---|---|---|
| 取り込み | 社内文書を集める | Azure Data Factory / Databricks / Fabric、Storage | 差分更新、権限制御、機密区分 |
| Chunking | 検索に適した単位へ分割 | Databricks（処理）、Python、Prompt Flowなど | 文書タイプ別の分割戦略（段落/見出し/固定長） |
| Enrichment | メタデータを付与して検索精度を上げる | Databricks、Functions、Document Intelligence | タイトル/要約/タグ、部署/公開範囲などの付与 |
| Embedding | ベクトル化して類似検索を可能に | Foundry Models（埋め込みモデル）など | 埋め込みモデル選定、ベクトル次元、コスト |
| Indexing | 検索インデックスに格納 | Azure AI Search | ハイブリッド/セマンティック設定、フィルタ設計 |
ADF／Databricksを既存データ基盤に組み込むときの“現実的”な考え方
質問でよく出るのが「従来のADFやDatabricksの参照アーキテクチャ図のように、GenAIでも全体像を描きたい」という悩みです。結論から言うと、GenAIはアプリ（UI/エージェント）とデータ（取り込み/前処理/検索）の境界が重要で、ADFやDatabricksは主にデータ側に入ります。
設計上のコツは、“RAG用の検索インデックスを作るためのデータ製造ライン”として、既存のETL/ELTに組み込むことです。たとえば次のように分担します。
- ADF：オンプレ/クラウド/SharePoint等からの定期取り込み、差分検知、スケジューリング
- Databricks：PDF/Office文書の前処理、テキスト化、chunking、メタデータ付与、品質チェック
- Azure AI Search：RAGの検索基盤（ベクトル/全文/ハイブリッド）
- Foundry Agent Service（またはSDKオーケストレーター）：問い合わせ時の検索→モデル呼び出し→回答生成
RAGガイドが示すフェーズ（準備→chunking→enrichment→embedding→検索→E2E評価）を、そのままデータ基盤側の工程に当てはめると「どこをDatabricksジョブにするか」「どこをパイプライン化するか」が決めやすくなります。
エージェント型AIの設計：オーケストレーション“パターン”を先に選ぶ
チャットボットが“答える”だけなら単一エージェントでも成立しますが、業務が複雑になるほど、複数の専門エージェントを協調させた方がシンプルになる場面が増えます。Microsoftの設計ガイドでは、マルチエージェントを5つのオーケストレーションパターンとして整理しています。
| パターン | イメージ | 向くユースケース | 設計の注意点 |
|---|---|---|---|
| Sequential | 工程を直列に流す | 下書き→レビュー→整形、段階的な変換処理 | 途中で失敗した出力が下流へ伝播しやすい |
| Concurrent | 複数エージェントを並列に走らせる | 複数観点の分析、複数ドキュメント同時調査 | 共有状態の競合、コスト/レイテンシ増に注意 |
| Group Chat | 会話スレッドで合議する | ブレスト、品質チェック、maker-checker | ループ制御が重要。小さく始める（例：3体程度） |
| Handoff | 担当を切り替えて引き継ぐ | 問い合わせ分類→専門担当へ引き継ぎ、有人エスカレーション | 引き継ぎ条件（閾値）と監査ログを明確に |
| Magentic | 計画を立ててツールで実行する | 実行型の業務自動化（調査→計画→実行） | ツール権限、サンドボックス、失敗時の安全策が必須 |
ここでのポイントは、「サービス選定」より先に協調の型を決めることです。型が決まると、Foundry Agent Service（ノーコード寄り）で足りるのか、Semantic KernelやMicrosoft Agent FrameworkなどのSDKで自前オーケストレーションが必要かが見えてきます。
Baseline Agentic AI Systems Architectureの価値：チャットの外側（実行・隔離・API管理）を補う
マルチエージェントが「ツールを呼び出して業務を動かす」段階になると、チャットの参照アーキテクチャだけでは足りない論点が増えます。Baseline Agentic AI Systems Architectureでは、エージェント/オーケストレーター/API/Prompt FlowなどをAzure Container Apps（またはAKS）で動かす構成例や、Azure OpenAIを直接叩かずAPI Managementを前段に置く発想、そしてコード実行を隔離するサンドボックス（Container Appsのdynamic sessions等）といった“実行系の防御”が整理されています。
特に、エージェントが生成したコードを実行する可能性があるユースケースでは、実行環境の隔離は設計の最優先事項です。「何をどこまで許可するか」をアーキテクチャ図の時点で表現できると、セキュリティレビューが通りやすくなります。
実装に直結する“公式リファレンス実装”も押さえる
参照アーキテクチャを早く理解するコツは、図と文章だけでなく実際にデプロイできるリファレンス実装を併読することです。Baseline ChatとLanding Zone版には、公式のGitHubリポジトリが用意されています。
- Foundry Agent Service chat baseline reference implementation（単体デプロイ）
- Foundry chat baseline in application landing zone（Landing Zone前提）
リポジトリ側を見ると、インフラがBicepなどのIaCで定義され、プライベートエンドポイント、Firewall経由の送信、エージェント依存リソース（Cosmos DB/Storage/AI Search）などが具体的に何を作るのか把握できます。結果として、設計図を「自社の命名規則・ネットワーク規約・監査要件」に落とし込む作業が一気に現実味を帯びます。
RAGの改善を最短化する：評価ツール（RAG Experiment Accelerator）
RAGは「作って終わり」ではなく、検索・プロンプト・モデル・メタデータの組み合わせを回して改善していく領域です。Microsoftは、Azure AI SearchとRAGの実験・評価を加速するためのツールとしてRAG Experiment AcceleratorをGitHubで公開しています。
PoCや改善フェーズで「chunkサイズを変えたら精度は上がる？」「ハイブリッド検索とベクトル検索の差は？」「評価指標は何を採用する？」といった論点が出たときに、こうした実験基盤があると意思決定の速度が変わります。
アーキテクチャ図を“自社向け設計”に落とすチェックリスト
参照アーキテクチャはそのままコピーして使うというより、自社の制約条件に合わせて差し替える前提の“ひな形”です。以下の観点でチェックすると、設計レビューで突っ込まれやすいポイントを先回りできます。
| 観点 | チェック項目 | 図に反映する例 |
|---|---|---|
| ネットワーク | Private Link必須か／送信制御が必要か | BaselineのようにPrivate EndpointとFirewallを明示 |
| 認証・権限 | ユーザー認証、エージェントの権限境界、最小権限 | Entra IDとManaged Identityの経路を描く |
| データ保護 | 会話ログ/プロンプト/検索根拠の保存先と保持期間 | Cosmos DB/Storage/ログ基盤を分離して明示 |
| RAG品質 | chunking/embedding/index設計、評価指標、テストクエリ | RAGガイドの工程をデータ基盤に対応づける |
| 実行型エージェント | ツール権限、危険な操作、コード実行の隔離 | サンドボックス（隔離環境）を別枠で描く |
| 監視・運用 | トレーシング、失敗時の可視化、評価の自動化 | Application Insights/Monitorなどの経路を入れる |
| コスト | トークン/検索/ツール呼び出しの増え方を想定できるか | エージェントの接続先（外部ツール/知識）を整理して描く |
公式アーキテクチャ図・Visio・実装を効率よく見つける検索テクニック
最後に、探す時間を減らすための“検索の型”を紹介します。生成AI系は用語が揺れやすいので、以下のようにキーワードを組み合わせるとヒット率が上がります。
- 製品名の揺れを吸収：「Azure AI Foundry」OR「Microsoft Foundry」
- 欲しい成果物を指定：「reference architecture」「baseline」「landing zone」「visio」
- 領域で絞る：「RAG」「agent orchestration」「agentic」
- 公式に限定：site:learn.microsoft.com / site:techcommunity.microsoft.com / site:github.com Azure-Samples
また、Azure Architecture CenterのAI領域ページから辿ると、関連する参照アーキテクチャがまとまっているため、検索に頼り切らずに“芋づる式”に集められます。
まとめ：公式の「型」をベースに、最短で自社の全体図へ
Azure上の生成AI／エージェント型AIは、モデル選びだけでなく、ネットワーク、認証、知識基盤（RAG）、監視、ガバナンス、そして実行系の安全策までを含めた設計が必要です。Microsoftが提供するBasic／Baseline／Landing Zoneの参照アーキテクチャと、RAGガイド、オーケストレーションパターン、Agentic AIのベースラインを組み合わせることで、PoCから本番、そして業務自動化まで段階的にアーキテクチャを描けるようになります。
まずはBasicでつながりを理解し、Baselineで本番要件を追加し、Landing Zoneで組織運用に載せる。その上でRAGを評価込みで磨き、必要ならマルチエージェントと実行型の防御設計へ拡張する——この順序が、最も迷いにくい王道ルートです。
コメント