はじめに
先日、一般提供(GA)が発表された Azure AI Foundry Agent Service を触ってみました。この記事では、実際に環境を構築し、エージェントを動かしてみた手順と所感をお伝えします。
Azure AI Foundry Agent Serviceとは
Azure AI Foundry Agent Serviceは、モデル、ツール、フレームワークを単一のランタイムに統合し、AIエージェントを作成・構成・実行するためのMicrosoftのクラウドサービスです。大規模言語モデル(LLM)とツールを組み合わせてデータの読み取りや関数の呼び出しを行い、複雑なビジネスプロセスを自動化することができます。
この記事の狙い
- GA版の注目ポイント
- 実際のセットアップ手順をキャッチアップ
- サンプルアプリやBing Searchと組み合わせた検証例を紹介
GAリリースのキーポイント
以下にキーポイントをまとめました。
個人的には、接続されたエージェント機能や、A2Aでマルチエージェントが構成しやすくなることに期待しています。
マルチエージェント・オーケストレーション
- 接続されたエージェント（プレビュー）：エージェントが他のエージェントをツールとして呼び出してタスクを処理できる
- マルチエージェントワークフロー（プレビュー）：複数のエージェントを調整する複雑なマルチステッププロセスを実行できる
- Semantic KernelおよびAutoGenの統合ランタイムと直接統合
Connected Agent エコシステムの構築
- Azure Logic Apps ワークフローにエージェントをアクションとして追加して複雑なビジネスプロセスを自動化できる
- Microsoft FabricやBing Search、SharePoint等のナレッジと統合できる
- Microsoftとパートナーが提供するエージェントのコードサンプルライブラリを提供
- Agent2Agent (A2A) API ヘッドを使用してエージェントをシームレスに使用できる
- Crew AI、LangGraph、LlamaIndex などの一般的なエージェント・オーケストレーション・フレームワークと統合される
エンタープライズ向けの信頼性
- AgentOpsツールによる評価と監視:エージェントの評価、トレース、監視、レポート機能を提供
- ガバナンスと安全性:データの分離、コンテンツフィルタリング、安全管理、ユーザ固有のDBへの会話履歴保存、エージェントやモデルの管理
サポートされるモデル
サポートされるモデルは下記から確認できます。
環境構築
環境構築については、Microsoftの公式ドキュメントに沿って進めました。今回の構成は下記で紹介するクイックスタートで検証したので基本的にこのガイドに沿って作業すればOKでした。ここでは、私が試した手順上で気になった点を中心に紹介します。
セットアップ方法は3種類
GA時点で、Agent Serviceのデプロイ方法は以下の3種類に分かれています。最初は「基本的なセットアップ」で済みますが、ちゃんと運用するにはネットワークやガバナンスの設計も必要になりそうな気配がします。
🟢 基本的なセットアップ（Quick Start）
OpenAI Assistants API互換で最小限の構成
Azureが提供するリソースをそのまま利用するので個別管理は不要
✅ まず試してみるなら十分。今回はこの構成で始めました。
🟡 標準セットアップ
キー管理やストレージなどを独自のAzureリソースとして分離可能
💡 本番での運用を意識する場合は、個人的にはこれが今後の主流になりそうな気がします。
🔴 BYOネットワークセットアップ（標準＋仮想ネットワーク）
上記の標準構成に加えて、独自の仮想ネットワーク内で閉じた構成が可能
⚠️ 企業利用やセキュリティ要件が厳しいシナリオ向けと思われます。Azureネットワーク周りの知識が必須です。
必要なロールの設定
前身のAzure OpenAI Assistants APIでは考慮不要だったのでちょっと盲点だったのですが、Azure AI Foundry Agent Serviceを触るには適切なロールが必要です。
公式ドキュメントにも案内がありますが、必要なロールを選択して、先にロール設定を済ませておくのがスムーズです。
私は、Azure管理者に「Azure AI Project Manager」ロールを追加してもらいました。
企業アカウントで検証している人は特に注意です。
クイックスタートのセットアップ
Azure Portalではなく、Azure AI Foundryの画面からセットアップします。
こちらの手順に沿ってデプロイを進めると、Azure上には2種類のリソースが作成されます。
- Azure AI Foundry（親リソース）
- Azure AI Foundry プロジェクト（個々のAgentや設定を含む子リソース）
プロジェクト単位でモデルのデプロイ、エージェントや接続先を切り分けられるので、チーム単位や目的別に分けて構築することも視野に入れておくと良さそうです。
補足：ネットワーク設定
Azure AI Foundryのリソースは、デフォルトではすべてのアクセスが許可されている状態になっています。環境に応じて明示的にFirewall設定を見直す必要があるので注意しましょう。
設定箇所は以下：
📍Azure Portal > 該当の Azure AI Foundry リソース > 「リソース管理」> 「ネットワーク」
このメニューから"特定のIP範囲だけ許可する"などの設定を行うことで、不要なアクセスをブロックできます。
PoCや社内利用であっても、アクセス範囲の制御は忘れずにチェックしておきたいポイントです。
補足：リソースの削除
リソースの削除は、作成時とは異なり、Azure AI FoundryからではなくAzure Portalから実行できました。
エージェントの構成
事前準備：Grounding with Bing Search のデプロイ
今回の検証では、Bing検索を使う構成にしたかったので、先に「Grounding with Bing Search」リソースをAzure側でデプロイしておきました。（公式ドキュメント）
Azure Portalからすぐ作成できるので、必要な方は先に用意しておくとスムーズです。
まずは画面構成をチェック
Azure AI Foundry にアクセスすると、左側に多くのメニューが並んでいます。
特にGAの発表で紹介されていたAgentOps関連のメニューも表示されており、かなり期待できそうです。
エージェントの作成
エージェントはAPIでcreateすることもできますが、今回はAzure AI Foundryの画面を使ってみます。
「エージェント」メニューを選択すると、モデル選択画面が表示されました。
ここで使用するモデルを選びます。今回は gpt-4o を選択しましたが、他にも複数のモデルが選択肢として用意されていました。
モデルを選ぶだけでエージェントの初期構成が自動で作成されます。このあたりの手軽さはかなり良いですね。
エージェント名が自動でセットされるので、左側のメニューから「エージェント名」を変更します。「手順」のフィールドにインストラクション（＝エージェントへの指示）を入れますが、一旦このまま進めます。
Bing検索との連携
作成したエージェントを選択し、左側のメニューから、「ナレッジの追加 > Bing検索を使用したグラウンド」を選択します。
その後、「接続の作成」というボタンが表示されるので、事前に用意しておいた Grounding with Bing Search のリソースを選べば完了です。
プレイグラウンドでテスト
プレイグラウンドでエージェントの動作を確認します。
ユーザーからの挨拶にはWeb検索なしで挨拶を返し、必要な場合にWeb検索して回答していることが確認できました。応答時間や使用トークン数などもチェックできます。
応答メッセージの下部にある「実行情報の表示」を押すと、動作の詳細も確認できました。
補足：プロジェクトを跨った接続設定などのAzure Foundryリソースの確認
プロジェクトの接続先のリソースは、画面右下の「管理センター」から確認することができます。
アプリケーションからの利用
Azure AI Foundryのプロジェクトとエージェントを作成したら、Pythonアプリケーションからエージェントに問い合わせを行ってみます。
サンプルコード
今回使用したサンプルコードと稼働環境は以下の通りです。
稼働環境
Windows 11
openai==1.79.0
azure-ai-agents==1.0.0
azure-identity==1.23.0
Microsoft Azure CLI [Microsoft.AzureCLI] バージョン 2.73.0
サンプルコード
サンプルコード(agent.py)
import os
from azure.ai.agents import AgentsClient
from azure.ai.agents.models import MessageRole
from azure.identity import DefaultAzureCredential
from dotenv import load_dotenv
# .env ファイルから環境変数の読み込み
load_dotenv(".env")
endpoint = os.getenv("PROJECT_ENDPOINT")
if endpoint is None:
raise ValueError("Environment variable 'PROJECT_ENDPOINT' is not set.")
agentid = os.getenv("AGENT_ID")
if agentid is None:
raise ValueError("Environment variable 'AGENT_ID' is not set.")
# ユーザからエージェントへのメッセージ
user_message = "東京の人口は現在何人ですか？"
print(f"User message: {user_message}")
# クライアントの作成と実行
agents_client = AgentsClient(
endpoint=endpoint,
credential=DefaultAzureCredential(),
)
# スレッドを作成し実行
with agents_client:
# スレッドの作成
thread = agents_client.threads.create()
print(f"Created thread, ID: {thread.id}")
# メッセージの作成
message = agents_client.messages.create(
thread_id=thread.id,
role=MessageRole.USER,
content=user_message,
)
print(f"Created message, ID: {message.id}")
# runの作成と処理
run = agents_client.runs.create_and_process(thread_id=thread.id, agent_id=agentid)
print(f"Run finished with status: {run.status}")
if run.status == "failed":
print(f"Run failed: {run.last_error}")
# runの詳細を取得するためにrun_stepsを取得
run_steps = agents_client.run_steps.list(thread_id=thread.id, run_id=run.id)
for step in run_steps:
print(f"Step {step['id']} status: {step['status']}")
step_details = step.get("step_details", {})
tool_calls = step_details.get("tool_calls", [])
if tool_calls:
print(" Tool calls:")
for call in tool_calls:
print(f" Tool Call ID: {call.get('id')}")
print(f" Type: {call.get('type')}")
print() # add an extra newline between steps
# エージェントからの応答メッセージと引用（あれば）を表示
response_message = agents_client.messages.get_last_message_by_role(thread_id=thread.id, role=MessageRole.AGENT)
if response_message:
for text_message in response_message.text_messages:
print(f"Agent response: {text_message.text.value}")
for annotation in response_message.url_citation_annotations:
print(f"URL Citation: [{annotation.url_citation.title}]({annotation.url_citation.url})")
.envの準備
コードの実行前に、エージェントの接続情報を .env ファイルに記述しておきます。
PROJECT_ENDPOINT="https://xxxxxxx"
AGENT_ID="asst_xxxxxxxx"
それぞれの値は以下の場所から確認できます。
- PROJECT_ENDPOINT：Azure AI Foundry > 「プロジェクト」 > 「概要」 > 「エンドポイントとキー」
- AGENT_ID：Azure AI Foundry > 「エージェント」 > 「ID」
認証設定（DefaultAzureCredential）
認証にはAzure SDK for Python の DefaultAzureCredentialを使います。
ローカル実行時には、あらかじめ自分の環境で認証を通しておく必要があります。
以下は、Windows環境での認証手順です。
使用環境
Windows 11
Microsoft Azure CLI [Microsoft.AzureCLI] バージョン 2.73.0
認証ステップ
- ブラウザベースの認証に戻す（Windowsの場合）
az account clear
az config set core.enable_broker_on_windows=false
az login
- テナントIDを指定してログイン
az login --tenant [テナントID]
サンプルの実行
認証と .env の準備が整えば、あとはPythonコードを実行するだけです。
$ python agent.py
User message: 東京の人口は現在何人ですか？
Created thread, ID: thread_xxxxxxxxxxxxx
Created message, ID: msg_xxxxxxxxxxxxx
Run finished with status: RunStatus.COMPLETED
Step step_xxxxxxxxxxxxx status: completed
Step step_yyyyyyyyyyyyy status: completed
Tool calls:
Tool Call ID: call_xxxxxxxxxxxxx
Type: bing_grounding
Agent response: 2025年4月1日時点で、東京都の人口は約14,220,200人と推計されています。このうち、区部が9,904,595人、市部が4,240,210人、郡部が53,461人、そして島部が21,934人です【3:3†source】。
URL Citation: [「東京都の人口（推計）」の概要（令和7年4月1日現在）](https://www.metro.tokyo.lg.jp/information/press/2025/04/2025043003)
さいごに
今回、GA版として公開された Azure AI Foundry Agent Service を一通り触ってみましたが、エージェントの作成が非常にシンプルで、実行結果もGUIでしっかり確認できる点が印象的でした。特に、初学者からプロトタイプ開発まで、スピード感を持って試せる作りになっていると感じました。
一方で、Grounding with Bing Search を使った回答では、同じプロンプトでも参照するWebサイトが毎回変わったり、応答のぶれが生じる場面もありました。このあたりはプロンプト設計や応答整形の工夫、あるいはKnowledge Source側での制御が必要そうです。
今回は単体のエージェントのみを試しましたが、今後は複数エージェントを連携させる構成や、AgentOpsの評価・監視機能にも触れてみたいと思っています。
Discussion