Azure AI Projects SDK for Pythonを使ってエージェントや生成AIアプリを作っているなら、2.1.0は「とりあえず更新して終わり」のリリースではありません。2026年4月20日に公開された2.1.0では、Hosted Agents向けのSession操作、Skills、Toolboxes、get_openai_client()のAgent endpoint対応、評価機能まわりの型ヒント強化、Tracingの挙動変更が入っています。結論から言うと、新規開発は2.1.0前提で検証し、既存プロダクションはTracingとプレビュー機能の利用有無を確認してから段階的に上げるのが安全です。(PyPI)
Azure AI Projects SDK for Python 2.1.0は何を示しているのか
Azure AI Projects SDK for Python 2.1.0の重要点は、単なる機能追加ではなく、Microsoftがエージェント開発・AIアプリ開発の「作る、動かす、評価する、観測する」面をかなり速いテンポで整えていることです。
特に今回のリリースでは、モデル呼び出しそのものよりも、実務で必要になる周辺領域が強化されています。
| 領域 | 2.1.0で注目すべき変更 | 開発現場への影響 |
|---|---|---|
| Agent endpoint | get_openai_client(agent_name=...)に対応 | Foundry Project単位だけでなく、Agent endpointを意識した実装・検証がしやすくなる |
| Hosted Agents | .beta.agentsにSession操作を追加 | セッション作成、ファイルアップロード、ダウンロードなどをSDKから扱いやすくなる |
| Skills | beta.skillsサブクライアントを追加 | エージェントに持たせる機能単位をSDKで管理しやすくなる |
| Toolboxes | beta.toolboxesサブクライアントを追加 | ツール群やバージョン管理をアプリ開発の流れに組み込みやすくなる |
| Evaluation | .evals.create()などの型ヒントを強化 | 評価用ペイロードの記述ミスを開発時に検出しやすくなる |
| Tracing | tracing有効時のtrace context propagationがデフォルト有効に | 観測性は上がるが、セキュリティ・プライバシー確認が必要になる |
Azure AI Projects SDK for Pythonは、Microsoft Foundry Project内のリソースへアクセスするためのクライアントライブラリです。公式ドキュメントでは、Agentsの作成・実行、各種ツール連携、OpenAI互換クライアントの取得、評価、Red Team、デプロイ、接続、データセット、インデックスなどを扱う用途が示されています。(Microsoft Learn)
なぜ2.1.0は開発者が追うべきリリースなのか
SDKのバージョンアップは、開発者にとって「新機能が増えたか」だけでなく、次の3点を確認するタイミングです。
まず、互換性です。既存コードがそのまま動くか、環境変数名やプレビュー機能の有効化条件が変わっていないかを確認する必要があります。
次に、開発体験です。2.1.0では評価APIまわりのTypedDictが増え、get_openai_client()で返されるOpenAI clientの型ヒント不足も修正されています。AIアプリ開発ではJSON風の深い設定を扱うことが多いため、型補完や静的解析の効き方は実装速度に直結します。(PyPI)
最後に、運用影響です。Tracingのtrace context propagationが、tracing有効時にデフォルトで有効になります。分散トレースの相関は取りやすくなりますが、外部サービスへ送られるヘッダーや、baggage、メッセージ内容の記録設定は慎重に扱う必要があります。(Microsoft Learn)
リリース履歴から見るMicrosoftの反復速度
Azure AI Projects SDK for Pythonは、2026年3月6日に2.0.0が公開され、Foundry REST APIのGA版であるv1を使う最初の安定版リリースとして位置付けられました。その後、3月12日に2.0.1、4月20日に2.1.0が公開されています。PyPIのリリース履歴でも、2.0.0、2.0.1、2.1.0が短期間に並んでいます。(PyPI)
| バージョン | 公開日 | 意味合い |
|---|---|---|
| 2.0.0 | 2026年3月6日 | Foundry REST API v1を使う最初の安定版リリース |
| 2.0.1 | 2026年3月12日 | Memory Storesまわりの不具合修正 |
| 2.1.0 | 2026年4月20日 | Agent、Skills、Toolboxes、Evaluation、Tracingを広く強化 |
この流れを見ると、MicrosoftはAzure AI Projects SDK for Pythonを、単なる「AIモデル呼び出し用SDK」ではなく、エージェント/AIアプリの開発ライフサイクルを支える面として育てていると考えられます。モデルを呼ぶだけならOpenAI互換クライアントで足りますが、実務ではプロジェクト、接続、データセット、評価、トレース、ツール、Agentの状態管理まで必要になります。2.1.0は、その領域が急速に広がっていることを示すリリースです。
2.1.0の主要変更点を実務目線で整理
get_openai_client()がAgent endpointを扱いやすくなった
2.1.0では、AIProjectClientのget_openai_client()に任意引数agent_nameが追加されました。agent_nameを指定すると、返されるOpenAI clientはFoundry Project endpointではなくAgent endpointのbase URLを使います。Agent endpointはプレビュー機能のため、この使い方ではAIProjectClient作成時にallow_preview=Trueが必要です。(PyPI)
これは、エージェントを中心にアプリを組むチームにとって重要です。従来の「プロジェクト内のモデルに問い合わせる」実装から、「特定のAgent endpointをアプリの実行単位として扱う」実装へ移りやすくなるためです。
基本形は次のように考えます。
import os
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
with (
DefaultAzureCredential() as credential,
AIProjectClient(
endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
credential=credential,
allow_preview=True,
) as project_client,
):
with project_client.get_openai_client(
agent_name=os.environ["FOUNDRY_AGENT_NAME"]
) as openai_client:
# responses、conversations、evalsなど、
# 利用する操作に応じて公式サンプルと同じ形で呼び出す
pass
ここで注意したいのは、allow_preview=Trueを安易に全環境へ入れないことです。検証環境では有効にしても、プロダクションでは「どのプレビュー機能を、どの責任範囲で使っているか」をチーム内で明示しておくべきです。
.beta.agentsにSession操作が追加された
2.1.0では、.beta.agentsサブクライアントにHosted Agents向けのSession操作が追加されました。主な操作には、Sessionの作成・削除・取得・一覧、Session fileのアップロード・ダウンロード・削除・一覧があります。これらはHosted Agentsで動作する操作としてリリースノートに記載されています。(PyPI)
これにより、次のような実装シナリオが組みやすくなります。
| シナリオ | 使いどころ |
|---|---|
| ユーザーごとの会話セッション管理 | サポートボット、業務アシスタント、社内FAQエージェント |
| セッション単位のファイル受け渡し | 契約書レビュー、帳票確認、ログ解析、ドキュメント検索 |
| 検証用セッションの作成・削除 | QA、評価、デモ環境、PoCの自動化 |
特にAIアプリでは、単発のチャットだけでなく、ユーザーの操作履歴やアップロードファイルを含めた「作業単位」を管理する必要があります。Session操作の追加は、SDKがアプリケーション実装に近づいているサインです。
beta.skillsでエージェント機能の部品化が進む
新しく追加されたbeta.skillsでは、Skillの作成、パッケージからの作成、削除、ダウンロード、取得、一覧、更新が扱えます。(PyPI)
Skillsは、エージェントに持たせる能力を部品として扱う発想に近いものです。たとえば、社内申請を支援するエージェントであれば、次のような切り分けが考えられます。
| Skillの例 | 役割 |
|---|---|
| 申請ルール確認 | 入力内容が社内規定に合っているか確認する |
| 添付資料チェック | 必要書類がそろっているか確認する |
| 承認者候補の提示 | 部門や金額に応じて承認者を推定する |
| 申請文面の整形 | ユーザー入力を正式な申請文に整える |
実務では、ひとつの巨大なエージェントにすべてを詰め込むより、機能を小さく分けてテストし、再利用できる形にした方が保守しやすくなります。beta.skillsの追加は、そうした設計にSDK側が寄ってきていると見てよいでしょう。
beta.toolboxesでツール群の管理がしやすくなる
2.1.0ではbeta.toolboxesも追加されました。操作には、Toolboxの作成・取得・一覧・更新・削除に加えて、versionの作成・取得・一覧・削除が含まれます。(PyPI)
AIエージェント開発では、ツール連携が増えるほど「どのツールを、どのバージョンで、どのAgentに使わせるのか」が問題になります。たとえば、検索、コード実行、ファイル検索、社内API、OpenAPI連携などを組み合わせる場合、ツール構成を手作業で管理すると再現性が落ちます。
ToolboxesがSDKから扱えるようになると、CI/CDや検証環境で次のような管理がしやすくなります。
| 管理したいこと | 実務上のメリット |
|---|---|
| ツール構成のバージョン化 | 本番と検証で同じ構成を再現しやすい |
| 不要なToolboxの削除 | PoC後のリソース散乱を防げる |
| 一覧取得 | 運用中のAgentが依存するツール群を棚卸ししやすい |
| 更新 | ツール追加や設定変更をコード化しやすい |
ただし、beta配下の機能はプレビュー扱いです。新機能を先行して使える一方、仕様や命名、サポート範囲が変わる可能性があります。プロダクション投入前に、依存する操作と代替手段を整理しておくことが重要です。
Evaluationの型ヒント強化は地味だが重要
2.1.0では、AIProjectClient.get_openai_client()で取得したOpenAI clientの.evals.create()と.evals.runs.create()に対して、型ヒントのサポートが追加されました。リリースノートでは、評価設定やデータソース、Azure AI向けターゲット、Red Team、Trace、CSV関連などのTypedDictが追加されたことが示されています。(PyPI)
これは、AIアプリチームにとってかなり実用的です。評価処理は、モデル名、対象Agent、評価基準、データソース、CSV、合成データ、Red Teamなどの設定が増えやすく、ペイロードの形も複雑になりがちです。
型ヒントが効くと、次のようなミスを早い段階で見つけやすくなります。
| よくあるミス | 型ヒントで改善しやすい点 |
|---|---|
| キー名のタイプミス | エディタ補完で候補を確認しやすい |
| 必須項目の抜け | 静的解析や補完で気づきやすい |
| データソース種別の混同 | TypedDictの名前から用途を推測しやすい |
| 評価ターゲットの指定ミス | Agent向け、Model向けなどの違いを整理しやすい |
AIアプリの品質管理では、評価を「最後に人間が見るもの」にしないことが重要です。SDK側の型が整うほど、評価設定をコードレビューしやすくなり、CIに組み込むハードルも下がります。
Tracingの変更は必ず確認する
2.1.0のBreaking Changesとして、tracing有効時にtrace context propagationがデフォルトで有効になる変更があります。公式ドキュメントでは、OpenAI clientがget_openai_client()から取得された場合に、traceparentやtracestateなどのW3C Trace ContextヘッダーをHTTPリクエストへ挿入し、クライアント側のspanとサーバー側のspanを関連付ける説明がされています。(PyPI)
これは観測性の観点では便利です。Azure Monitorなどで、ユーザー操作、Agent呼び出し、Azure OpenAIや関連サービスの処理を横断して見やすくなります。
一方で、セキュリティ・プライバシーの観点では確認が必要です。ドキュメントでは、trace identifierがサービス側に共有される可能性や、baggage headerにユーザー識別子、セッション情報、認証情報、業務データ、個人情報が含まれ得る点が説明されています。baggage propagationはデフォルトでは無効ですが、必要に応じて明示的に制御する必要があります。(Microsoft Learn)
Tracingを使っている場合は、アップグレード前に次を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| tracingを有効化しているか | AZURE_EXPERIMENTAL_ENABLE_GENAI_TRACING=trueやOpenTelemetry設定の有無を確認 |
| trace context propagationを許容できるか | 社内の監査・コンプライアンス要件で外部送信ヘッダーを確認 |
| baggageを使っているか | 個人情報や認証情報がbaggageに混入していないか確認 |
| content recordingを使っているか | メッセージ内容やツール呼び出し詳細が記録される範囲を確認 |
| binary data tracingを使うか | ファイルや画像の内容がトレースに含まれるリスクを確認 |
trace context propagationを無効にしたい場合は、環境変数AZURE_TRACING_GEN_AI_ENABLE_TRACE_CONTEXT_PROPAGATION=falseを使うか、AIProjectInstrumentor().instrument()にenable_trace_context_propagation=Falseを渡す方法がドキュメントで示されています。(Microsoft Learn)
サンプルの環境変数名変更に注意
2.1.0では、サンプル内の環境変数名が次のように変更されています。(PyPI)
| 旧サンプル名 | 新サンプル名 |
|---|---|
AZURE_AI_PROJECT_ENDPOINT | FOUNDRY_PROJECT_ENDPOINT |
AZURE_AI_MODEL_DEPLOYMENT_NAME | FOUNDRY_MODEL_NAME |
AZURE_AI_MODEL_AGENT_NAME | FOUNDRY_AGENT_NAME |
これはサンプル更新の一部であり、既存アプリが独自に使っている環境変数名まで強制的に変わるわけではありません。ただし、公式サンプルをコピーして検証しているチームでは、.env、GitHub Actions、Azure Pipelines、Docker Compose、Kubernetes Secretなどの名前が食い違い、起動時にKeyErrorや未設定エラーが起きる可能性があります。
移行時は、コードだけでなく設定ファイルも検索してください。
grep -R "AZURE_AI_PROJECT_ENDPOINT\|AZURE_AI_MODEL_DEPLOYMENT_NAME\|AZURE_AI_MODEL_AGENT_NAME" .
見つかった場合は、プロジェクト方針に合わせてリネームするか、互換用に両方を読む実装にします。長期的には、公式サンプルに合わせてFOUNDRY_*へ寄せた方が、今後のサンプル追従は楽になります。
アップグレード前に確認すべき環境
Azure AI Projects SDK for Python 2.1.0を使うには、Python 3.9以上が前提です。PyPIのメタ情報でもPython >=3.9が示されており、公式ドキュメントの前提条件にもPython 3.9以降が含まれています。(PyPI)
インストールとバージョン確認は次のコマンドで行えます。
pip install --upgrade azure-ai-projects==2.1.0
pip show azure-ai-projects
新規プロジェクトなら、requirements.txtやpyproject.tomlで明示的にバージョンを固定しておくと、チームメンバーやCI環境で再現しやすくなります。
azure-ai-projects==2.1.0
既存プロジェクトでは、いきなり本番環境でpip install -U azure-ai-projectsを実行するのは避けてください。Azure SDK系は依存パッケージも含めて更新される可能性があるため、ロックファイルやconstraintsファイルを使い、ステージング環境で確認してから反映するのが安全です。
2.1.0へ移行する手順
現在のバージョンと依存関係を確認する
まず、現在のSDKバージョンを確認します。
pip show azure-ai-projects
pip freeze | grep -E "azure-ai-projects|azure-core|azure-identity|openai"
Azure AI Projects SDK for Pythonは、OpenAI互換クライアント、Azure Identity、Azure Coreなどと組み合わせて使うことが多いため、単体のバージョンだけを見ても十分ではありません。特にget_openai_client()や評価機能を使っている場合は、OpenAIパッケージ側の挙動も確認してください。
ステージング環境で2.1.0に固定する
次に、ステージング環境で2.1.0へ上げます。
pip install --upgrade azure-ai-projects==2.1.0
この時点で、最低限次のスモークテストを実行します。
| テスト | 目的 |
|---|---|
AIProjectClientを作成できるか | endpoint、credential、ロール設定の確認 |
get_openai_client()を取得できるか | OpenAI互換クライアントの認証・base URL確認 |
| 既存のResponsesやConversationsが動くか | アプリの中核処理が壊れていないか確認 |
| Agent関連処理が動くか | allow_previewやAgent名の設定確認 |
| Evaluation処理が動くか | 型ヒント変更後のペイロード確認 |
| Tracingが想定通りか | trace context propagationの挙動確認 |
Tracing設定をレビューする
Tracingを使っているチームは、アップグレード作業の中で必ず設定をレビューしてください。
echo $AZURE_EXPERIMENTAL_ENABLE_GENAI_TRACING
echo $AZURE_TRACING_GEN_AI_ENABLE_TRACE_CONTEXT_PROPAGATION
echo $AZURE_TRACING_GEN_AI_TRACE_CONTEXT_PROPAGATION_INCLUDE_BAGGAGE
echo $OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT
特に、金融、医療、公共、個人情報を扱う業務システムでは、トレースに含まれるヘッダーやメッセージ内容をレビュー対象に含めるべきです。便利だから有効にするのではなく、「どの情報を、どのバックエンドに、どの保持期間で送るのか」を明確にしてください。
サンプル追従と実装差分を分けて管理する
2.1.0では、Hosted Agents、Sessions、Skills、Toolboxes、構造化入力、File Search、Code Interpreter、CSV評価、合成データ評価、Chat Completions basicなどのサンプルが追加されています。(PyPI)
サンプルを読むときは、次の2つを分けて考えると失敗しにくくなります。
| 観点 | 見るべき内容 |
|---|---|
| SDKの新しい呼び出し方 | サブクライアント名、メソッド名、引数、環境変数 |
| 自社アプリへの適用 | 認証、例外処理、ログ、権限、CI/CD、データ保持 |
サンプルは動作確認には有用ですが、そのまま本番実装に貼り付けるものではありません。特にプレビュー機能、ファイル操作、トレース、評価データは、自社のセキュリティ基準に合わせて調整してください。
すぐアップグレードすべきチーム、慎重に進めるべきチーム
2.1.0は魅力的な更新ですが、全チームが同じ速度で本番投入すべきとは限りません。
| チームの状況 | 推奨アクション |
|---|---|
| 新規にAzure AI Projects SDK for Pythonで開発する | 2.1.0を前提に設計・検証する |
| Hosted Agentsを検証している | 2.1.0へ上げ、Session、Skills、Toolboxesのサンプルを確認する |
| Evaluationをコード化している | 型ヒント強化の恩恵が大きいため、早めに検証する |
| Tracingを有効化している | アップグレード前にtrace propagationとbaggage設定を確認する |
| 2.0.xで本番安定稼働している | ステージング検証後に段階的に移行する |
| 1.xや2.0.0b系から移行する | 2.0.0時点の破壊的変更も含めて確認する |
| プレビュー機能を本番禁止にしている | .beta配下とallow_preview=Trueの使用箇所を制限する |
特に1.xやベータ版から移行する場合、2.1.0だけを見て判断すると危険です。2.0.0では、allow_previewの導入、クラス名・メソッド名の変更、.betaサブクライアントへの移動など、多くの破壊的変更が入っています。移行計画では2.0.0の変更点も合わせて確認してください。(PyPI)
よくある失敗と回避策
Azure AI Projects SDKを「モデル呼び出し用SDK」だけだと思い込む
Azure AI Projects SDK for Pythonは、モデルを呼び出すだけのライブラリではありません。Foundry Project内のAgents、Deployments、Connections、Datasets、Indexes、Evaluations、Tracingなど、AIアプリ開発に必要な周辺リソースも扱います。公式ドキュメントでも、Agents、ツール連携、評価、Red Team、Fine-tuning、Deployments、Connections、Datasets、Indexesなどの用途が示されています。(Microsoft Learn)
モデル呼び出しだけを見ていると、2.1.0の価値を見落とします。今回の更新は、Agentをアプリとして運用するための面が広がっている点に注目すべきです。
.betaを「すぐ本番で使える安定機能」と扱う
.betaサブクライアントは、名前の通りプレビュー機能を扱う領域です。公式APIリファレンスでは、.beta配下のメソッドはプレビューであり、.betaという名前によりプレビュー利用が示されるため、メソッド利用自体にallow_preview=Trueが不要なケースが説明されています。一方、Hosted AgentやWorkflow Agent作成などではallow_preview=Trueが必要になるケースもあります。(Microsoft Learn)
つまり、allow_preview=Trueが不要だから安定版、という意味ではありません。設計レビューでは「.betaを使っているか」をチェック項目に入れてください。
サンプルの環境変数変更を見落とす
公式サンプルに追従している場合、FOUNDRY_PROJECT_ENDPOINT、FOUNDRY_MODEL_NAME、FOUNDRY_AGENT_NAMEへの変更を見落とすと、検証環境だけ動かない、CIだけ落ちる、といった問題が起きます。
環境変数の移行は、コード検索だけでなく、次の場所も確認してください。
| 確認場所 | 例 |
|---|---|
| ローカル設定 | .env、direnv、シェルプロファイル |
| CI/CD | GitHub Actions Secrets、Azure Pipelines variables |
| コンテナ | Dockerfile、docker-compose.yml |
| クラウド設定 | App Service設定、Container Apps、Kubernetes Secret |
| ドキュメント | README、オンボーディング手順、社内Wiki |
tracingの便利さだけを見て有効化する
Tracingは障害調査や性能分析に有効ですが、AIアプリではユーザー入力、ファイル名、ツール呼び出し、業務データがトレースに混ざりやすくなります。特にcontent recordingやbinary data tracingは、情報量が増える分だけリスクも増えます。公式ドキュメントでも、メッセージ内容やバイナリデータの記録には機微情報やトレースサイズの注意が示されています。(Microsoft Learn)
本番で有効化する前に、最低限次を決めてください。
| 決めること | 例 |
|---|---|
| 何を記録するか | trace IDのみ、メッセージ内容なし |
| どこへ送るか | Azure Monitor、OTLP対応バックエンド |
| 誰が見られるか | SRE、開発リード、セキュリティ担当のみ |
| いつ削除するか | 監査要件に沿った保持期間 |
| 何を記録しないか | 個人情報、認証情報、添付ファイル本文 |
開発チームが次に取るべき行動
Azure AI Projects SDK for Python 2.1.0は、AgentとAIアプリを作るチームにとって、かなり実務寄りの更新です。Hosted AgentsのSession操作、Skills、Toolboxes、評価の型ヒント、Tracingの相関強化を見ると、Microsoftが「モデルを呼ぶSDK」から「AIアプリを継続的に開発・評価・運用するSDK」へ面を広げていることが分かります。
次にやるべきことはシンプルです。まず、現在のazure-ai-projectsのバージョンを確認します。次に、2.1.0をステージング環境へ入れ、get_openai_client()、Agent、Evaluation、Tracingの既存処理をテストします。Tracingを使っている場合は、trace context propagation、baggage、content recordingの扱いを必ずレビューしてください。最後に、公式サンプルの環境変数名変更に合わせて、.env、CI/CD、運用ドキュメントを更新します。
新規開発なら、2.1.0を起点に設計して問題ありません。既存プロダクションなら、プレビュー機能とTracing設定を切り分けて、段階的に移行するのが最も安全です。

コメント