🌊

【Microsoft Agent Framework 】クライアント生成を理解したい

に公開

はじめに

2026年4月3日 に Microsoft Agent Framework が v1.0.0 / GA として公開されました。RC版の頃に触っていた実装と比べると、特に クライアント生成まわり が整理されており、変更点を追っていく中で、「そもそもクライアント生成って何してるんだっけ?」や接続方法としてAPIkeyを使用したり、事前にAzure認証しておく方法があったり混乱してしまったので今回まとめようと思います。
https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-version-1-0/

Microsoft Agent Frameworkにおける「クライアント生成」とは

まず結論から言うと、Microsoft Agent Framework における「クライアント生成」とは、どのAPIを使い、どのモデルに、どの認証方式で接続するかを表すオブジェクトを作ることです。

たとえば、

  • OpenAIのAPIを使うのか
  • Azure OpenAIを使うのか
  • Microsoft Foundryのproject endpointを使うのか
  • Foundry Agent Service上の管理されたエージェントを使うのか

で接続方法が異なります。
この「接続先」「モデル名」「認証方法」をまとめたものが、ここでいうクライアントです。

クライアント生成方法を整理する

  1. OpenAIChatCompletionClient
    Chat Completions API を使うためのクライアントです。
    シンプルなエージェント や 広いモデル対応 に向いた選択肢として説明されています。
  2. OpenAIChatClient
    Responses API を使うためのクライアントです。
    こちらは コードインタープリター、ファイル検索、Web検索、hosted MCP などのホスト済みツールを含む、よりフル機能な構成向けです。
  3. FoundryChatClient
    Microsoft Foundry の project endpoint に対して直接モデル推論する ときに使うクライアントです。アプリ側が instructions や tools、session 管理を持ちたい場合はこれを使います。
    GA後のサンプルコードはこの方法で実装されてます!
  4. FoundryAgent
    Foundry 上に定義済みの Prompt Agent / HostedAgent に接続するためのクライアントです。つまり「自分のアプリがエージェント定義を持つ」のではなく、「Foundry 側にあるエージェントを呼ぶ」ケースで使います

https://learn.microsoft.com/en-us/agent-framework/agents/providers/?pivots=programming-language-python

API key と AzureCliCredential

GA の発表ブログを見ると、FoundryChatClient と AzureCliCredential() を組み合わせたこの形が紹介されており、今までAPIkeyベースで認証する方法で行っていたため少し混乱してしまいました。

import asyncio

from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential

agent = Agent(
    client= FoundryChatClient(
      project_endpoint="https://your-project.services.ai.azure.com",
      model="gpt-5.3",
      credential=AzureCliCredential(),
    ),
    name="HelloAgent",
    instructions="You are a friendly assistant."
)

print(asyncio.run(agent.run("Write a haiku about shipping 1.0.")))

AzureCliCredential() とは

AzureCliCredential() は、Azure CLI に保存されている現在のログイン情報を使って、Azure AD(Microsoft Entra ID)のアクセストークンを取得するための資格情報クラスです。

Azure Identity ライブラリの一部で、内部的には Azure CLI に対してトークン取得を依頼します。そのため、事前に az login で Azure CLI へログインしておく必要があります。また、取得に使われるのは その時点で Azure CLI がログインしているアカウントです。

つまり AzureCliCredential()自体がログイン処理をするわけではなく、すでに CLI 側にある認証状態をアプリから再利用するための橋渡しだと考えるとわかりやすいです。
Microsoft Agent Framework の FoundryChatClient や、Azure OpenAI 向けに使う OpenAIChatClient / OpenAIChatCompletionClient に credential=AzureCliCredential() を渡すと、アプリは API キーを直接持たずに Azure 認証で接続できます。

ローカル開発と本番運用で認証方式を分けて考える

AzureCliCredential()は、ローカル開発で、開発者本人が Azure CLI にログインして作業する ことを前提にした資格情報です。

となると本番運用時はどう認証するの?と言う疑問出てきたので調査してみます↓

Azure 上で動かすなら最優先は Managed Identity

Azure にホストするアプリでは、Azure の Python 認証ガイドで Managed Identity が推奨 されています。
Managed Identity は Azure リソースに紐づく非人間 ID で、アプリ側にシークレットを置かずに Azure リソースへ認証できます。App Service、Container Apps、VM など多くの Azure ホスティング環境で使えます。

たとえば本番で Azure 上に Agent Framework のアプリを置くなら、次のように ManagedIdentityCredential を明示的に使う考え方がわかりやすいです。

from azure.identity import ManagedIdentityCredential
from agent_framework.foundry import FoundryChatClient

client = FoundryChatClient(
    project_endpoint="https://your-project.services.ai.azure.com",
    model="gpt-4o-mini",
    credential=ManagedIdentityCredential(),
)

ローカルでは AzureCliCredential()、Azure 上の本番では ManagedIdentityCredential()

credentialの整理はできました。でもこれどのタイミングで切り替えるの?

いちばんわかりやすいのは、credential を返す関数を1つだけ作るやり方です。

ローカルでは AzureCliCredential()、Azure 上の本番では ManagedIdentityCredential() を返すようにして、Agent Framework 側はその戻り値を使うだけにします。

import os
from azure.identity import AzureCliCredential, ManagedIdentityCredential

def get_credential():
    env = os.getenv("APP_ENV", "local")

    if env == "production":
        return ManagedIdentityCredential()

    return AzureCliCredential()
from agent_framework.foundry import FoundryChatClient

client = FoundryChatClient(
    project_endpoint="https://your-project.services.ai.azure.com",
    model="gpt-5.3",
    credential=get_credential(),
)

この形なら、コード本体は同じで、切り替えはデプロイ設定だけです。
たとえばローカルでは APP_ENV=local、Azure の本番環境では APP_ENV=production を設定しておけば、自動で切り替わります。

補足
DefaultAzureCredentialと言う認証方法でもローカルと本番の切り替えできそう↓

DefaultAzureCredentialとは、
Azure SDK が使う認証方法を1つに決め打ちせず、複数の資格情報を順番に試して、最初に成功したものを使うための“認証チェーン” です。

イメージとしては、
「ローカルでは開発者のログイン情報、Azure 上では Managed Identity、必要なら環境変数のサービス プリンシパル」 のように、実行環境に応じて使える認証方法を自動で探してくれる仕組みです。だから、同じコードをローカル開発と Azure 上の実行環境で使い回しやすいのが大きな利点です。

https://learn.microsoft.com/en-us/python/api/azure-identity/azure.identity.defaultazurecredential?view=azure-python

今回は「まずクライアント生成を理解すること」なので、ここは深掘りしすぎず、認証の詳細は今後もう少し学んでいきたいです💪

まとめ

個人的には、GA 後に FoundryChatClient のサンプルを見たとき、最初は少し戸惑いました。ですが今回整理してみたことで、Microsoft Agent Framework における「クライアント生成」とは、接続先・モデル・認証方式を決めること だと捉えると理解しやすいと感じました。

一方で、今回あらためて認証まわりを追ってみると、API キー認証、Azure CLI を使ったローカル開発時の認証、Managed Identity を使った本番運用時の認証など、まだ整理しきれていない内容も多いと感じました。
このあたりは自分の中でももう少し理解を深めながら、今後あらためて記事としてまとめていければと思います。

ヘッドウォータース

Discussion