はじめに
大規模言語モデル（LLM）は強力ですが、単体では複数ステップにわたる業務処理や外部データの参照を安定して行うのが苦手です。そこで登場するのが「エージェント」です。エージェントはモデルに目的・制約・ツールを与え、自律的に複数の行動を選ばせる仕組みです。
さらに、調査・執筆・レビューのように性質の異なる作業を一つのエージェントに詰め込むと、プロンプトが肥大化し品質が安定しません。役割ごとにエージェントを分割して協調させる「マルチエージェント」が有効になります。
本記事では Microsoft Foundry（旧称 Azure AI Foundry）を土台に、単体エージェントの作成からマルチエージェント協調の最小実装までを順に解説します。
Microsoft Foundry が提供するもの
Microsoft Foundry は、モデルカタログ・エージェント実行基盤・ツール・評価・監視を統合した開発プラットフォームです。エージェント機能は Foundry Agent Service（旧称 Azure AI Agent Service）として提供され、次の要素を一手に引き受けます。
| 機能領域 | 内容 |
|---|---|
| モデル | Foundry モデルカタログのモデル（GPT 系・オープンモデルなど）を切り替えて利用 |
| ツール | ファイル検索・コードインタープリター・Web 検索・MCP サーバ・カスタム関数 |
| 実行基盤 | 会話（スレッド）とツール呼び出しのライフサイクルを managed に処理 |
| 監視 | トレース・メトリクス・Application Insights 連携 |
| セキュリティ | Microsoft Entra ID・RBAC・コンテンツフィルタ・仮想ネットワーク分離 |
エージェントを構成する 3 つの要素
Foundry のエージェントは、次の 3 要素で定義されます。
- Model(モデル): 推論を担うモデル。コードを変えずに後から差し替え可能です。
- Instructions(手順): 役割・目的・制約を記述する指示文（システムプロンプト相当）。
- Tools(ツール): 外部データ取得や操作を行う道具。検索や関数呼び出しなどです。
この 3 要素を分けて考えることが、保守しやすいエージェント設計の第一歩になります。
単体エージェントの最小実装（Python）
まずは 1 体のエージェントを作ります。Python では azure-ai-projects SDK を利用します。認証は API キーではなく Managed Identity（DefaultAzureCredential）を推奨します。
# pip install azure-ai-projects azure-identity
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
project = AIProjectClient(
endpoint="https://<your-foundry>.services.ai.azure.com/api/projects/<project>",
credential=DefaultAzureCredential(),
)
# 1) エージェント定義（Model + Instructions）
agent = project.agents.create_agent(
model="gpt-4o",
name="research-agent",
instructions="あなたはリサーチ担当です。事実に基づき簡潔に回答します。",
)
# 2) 会話スレッドを作成し、メッセージを投入
thread = project.agents.threads.create()
project.agents.messages.create(
thread_id=thread.id, role="user", content="Azure の主要な AI サービスを 3 つ挙げて。"
)
# 3) 実行（ツール呼び出しの反復は SDK が内部で処理）
run = project.agents.runs.create_and_process(
thread_id=thread.id, agent_id=agent.id
)
print(run.status)
会話状態が「スレッド・メッセージ・ラン」という単位で管理される点が特徴です。ツール呼び出しの反復は create_and_process が内部で回します。
マルチエージェントを協調させる
単体で扱いきれない処理は、役割ごとにエージェントを分けます。代表的なのが、まとめ役（Orchestrator）が作業役（Worker）へ仕事を割り振る Orchestrator-Worker パターンです。
Orchestrator は要求を小さなサブタスクへ分解し、専門の Worker に委譲して結果を統合します。各 Worker の Instructions は単一の役割に絞れるため、プロンプトが短く品質が安定します。
協調ロジックを自前で書くこともできますが、Microsoft Agent Framework（Semantic Kernel と AutoGen の後継）の Workflows を使うと、実行順序や分岐をグラフとして明示的に制御できます。
まとめ
- Microsoft Foundry は、モデル・ツール・実行基盤・監視を統合したエージェント開発基盤です。
- エージェントは Model / Instructions / Tools の 3 要素で考えると設計しやすくなります。
- 単体エージェントは「スレッド・メッセージ・ラン」の単位で会話を管理します。
- 複雑な処理は Orchestrator-Worker のように役割分担させて品質を安定させます。
- 次のアクション: 認証設計（Managed Identity）とフレームワーク選定に進みましょう。
参考リンク
- Microsoft Foundry とは — モデル・エージェント・ツールを統合した開発プラットフォームの全体像
- Foundry Agent Service の概要 — エージェントの 3 要素（Model / Instructions / Tools）と実行基盤
- Microsoft Foundry でワークフローを構築する — 複数エージェントを協調させるワークフローの作り方
- Microsoft Agent Framework の概要 — Semantic Kernel と AutoGen の後継フレームワーク
- AI エージェントオーケストレーションパターン — マルチエージェント設計パターンの選び方
この記事の執筆にあたり、AI の支援を受けています。
