はじめに

大規模言語モデル(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・コンテンツフィルタ・仮想ネットワーク分離

Microsoft Foundry の構成

エージェントを構成する 3 つの要素

Foundry のエージェントは、次の 3 要素で定義されます。

  • Model(モデル): 推論を担うモデル。コードを変えずに後から差し替え可能です。
  • Instructions(手順): 役割・目的・制約を記述する指示文(システムプロンプト相当)。
  • Tools(ツール): 外部データ取得や操作を行う道具。検索や関数呼び出しなどです。

この 3 要素を分けて考えることが、保守しやすいエージェント設計の第一歩になります。

Screenshot of Foundry Agent Service

単体エージェントの最小実装(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 へ委譲し、結果を集約して最終回答を生成する図

Orchestrator は要求を小さなサブタスクへ分解し、専門の Worker に委譲して結果を統合します。各 Worker の Instructions は単一の役割に絞れるため、プロンプトが短く品質が安定します。

協調ロジックを自前で書くこともできますが、Microsoft Agent Framework(Semantic Kernel と AutoGen の後継)の Workflows を使うと、実行順序や分岐をグラフとして明示的に制御できます。

まとめ

  • Microsoft Foundry は、モデル・ツール・実行基盤・監視を統合したエージェント開発基盤です。
  • エージェントは Model / Instructions / Tools の 3 要素で考えると設計しやすくなります。
  • 単体エージェントは「スレッド・メッセージ・ラン」の単位で会話を管理します。
  • 複雑な処理は Orchestrator-Worker のように役割分担させて品質を安定させます。
  • 次のアクション: 認証設計(Managed Identity)とフレームワーク選定に進みましょう。

参考リンク


この記事の執筆にあたり、AI の支援を受けています。