Foundry Agent Serviceとは？旧Azure AI Agent Serviceからの移行と料金・実装手順【2026年8月時点】

2024年のIgniteで発表された「Azure AI Agent Service」を調べると、いま公式ドキュメントに並ぶのは「Foundry Agent Service」という別名のサービスです。名前が変わっただけではありません。当時のサービスは classic 版として非推奨になり、廃止日まで公表されています。この記事は2026年8月時点の一次情報だけを使い、現行サービスの構造・移行で消える機能・東日本リージョンの実単価・実装手順を整理します。

まとめ

• 2024年12月にプレビュー提供された Azure AI Agent Service は classic 版となり、Microsoft Learn は「2027年3月31日に廃止（retired）」と明記しています。移行は期限のある作業です。
• prompt agent には実行基盤の追加課金がありません。課金されるのは hosted agent の計算時間で、東日本の単価は vCPU が1時間0.10934米ドル、メモリが1GiB時間0.01298米ドルです。課金は同時アクティブセッション数の合計に比例します。
• 現行版は OpenAI の Responses API を土台に作り直された別系統で、一般提供（GA）は2026年3月16日の告知です。
• threads は conversations に、runs は responses に、create_agent() は create_version() に置き換わりました。
• Azure Functions ツール、Connected agents、Deep Research ツールは新版にありません。

Azure AI Agent Serviceから現在までの変遷と廃止期限

プレビューからclassic版廃止までの経緯

Microsoft Learn の classic 版の更新履歴には、2024年12月の項目に「Azure AI Service is now available in preview」と記載があります（公式ページの表記のままで、Agent が抜けています）。Azure OpenAI の Assistants API を土台に、Bing を知識源として使うツールや関数呼び出しを足したものでした。その後2025年5月に「Agent Service GA」として一般提供に到達し、Connected agents や Azure Logic Apps によるトリガー実行が加わっています。

2026年8月時点では、この系統は classic として整理されました。公式ドキュメントの冒頭には「Agents (classic) are now deprecated and will be retired on March 31, 2027.」という注記が出ます。つまり2024年から2025年にかけて作った実装は、期限までに現行サービスへ移す前提で扱う必要があります。

Responses APIを単一入口とする現行サービスの構造

現行の Foundry Agent Service は、Microsoft Foundry というプラットフォーム上のエージェント実行基盤です。プラットフォーム全体の構成はMicrosoft Foundry（Azure AI Foundry）とは何か？エンタープライズ向け生成AI統合プラットフォームの概要で扱っているため、この記事はエージェント実行部分に絞ります。

設計上の中心は Responses API です。公式ドキュメントはこれを「Single entry point for every agent type」と説明しており、ポータルで作ったエージェントも、自分で書いたコンテナも、Foundry の外で動く既存プロセスも、同じ入口からモデルとツールを呼びます。classic の土台だった Assistants API から入れ替わった点が、次に見る差分すべての原因です。

classic版から現行版へのAPI差分と消えるツール

threads・runsからconversations・responsesへの置き換え

移行ガイドが示す対応関係は次の3つです。

実装上は、classic では1つのクライアントで完結していた操作が2つに分かれます。エージェントの定義とバージョン管理はプロジェクトクライアント（Python では AIProjectClient）で行い、会話と応答は project.get_openai_client() で取得した OpenAI クライアントで行います。

移行時に使えなくなるツールと代替手段

ツールは単純に引き継がれません。移行ガイドの対応表で、classic では使えたのに現行版で「No」になっているのは次の3つです。

Connected agents で組んだマルチエージェント構成を持っている場合、A2A（Agent2Agent）プロトコルへの置き換えになります。A2A は2026年8月時点でパブリックプレビューなので、GA 機能で組んだ本番構成をプレビュー機能へ移すことになる点は、移行計画で先に握っておくべきです。

逆に現行版だけにある機能もあります。Web Search は GA、Image Generation はパブリックプレビューとして追加され、classic ではパブリックプレビューだった MCP は GA に昇格しました。MCP でのツール接続の設計はAIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】で詳しく扱っています。

prompt agentとhosted agentの選び分け

prompt agent（コードを持たない構成定義）

prompt agent は、指示文・モデル・ツールの構成だけでエージェントを定義する形式です。Foundry ポータルで対話的に作ることも、SDK や REST で CI/CD に組み込むこともできます。公式ドキュメントの表現では「no application code to maintain, no compute to pay for」で、実行基盤の維持もコンテナの計算課金も発生しません。

hosted agent（自作コードのコンテナ実行）

hosted agent は、自分で書いたエージェントのコードをコンテナイメージ（またはソースの zip）として持ち込み、Foundry が実行する形式です。Microsoft Agent Framework、LangGraph、OpenAI Agents SDK、Anthropic Agent SDK、GitHub Copilot SDK、そして自作コードに対応します。フレームワークの選定軸はAIエージェントフレームワークとは？主要8種の比較と受託開発視点の選定基準【2026年版】、Microsoft 純正の選択肢はMicrosoft Agent Framework 1.0とは｜Semantic KernelとAutoGenを統合した.NET/Python共通エージェントSDKで整理しています。

hosted agent はセッションごとに VM 分離されたサンドボックスで動き、選べるサイズは 0.5vCPU/1GiB、1vCPU/2GiB、2vCPU/4GiB の3種類です。15分リクエストが無いとコンピュートは解放され（$HOME と /files の内容は保持）、同じセッション ID で呼ばれると状態を復元して再開します。30日間操作が無いとセッションは削除されます。対応言語は Python と C# のみです。

Foundryにエージェントを置かない選択肢

3つ目の選択肢として、既存プロセスから Responses API を直接呼ぶ形があります。エージェントリソースを Foundry 上に作らずに、Foundry のモデルカタログとプラットフォームツールだけを使う構成です。公式ドキュメントはこれを hosted agent の代替ではなく追加的なパターンと位置づけており、同じ Agent Framework のコードを、まず自前プロセスから Responses API を呼ぶ形で動かし、後からコンテナ化して hosted agent にする移行経路を想定しています。

Python SDKでの実装手順

パッケージの選択とクライアントの初期化

ここで間違えやすいのがパッケージです。classic 時代の Python SDK は azure-ai-agents でしたが、PyPI の最新安定版は2025年8月5日公開の 1.1.0 で止まっています。現行版で使うのは azure-ai-projects で、移行ガイドは 2.3.0 以上を指定しており、2026年8月11日時点の最新は2026年7月27日公開の 2.4.0（Python 3.9以上）です。JavaScript は @azure/ai-projects 2.4.0 と Node.js 22以降、Java は azure-ai-agents 2.2.0 が移行ガイドの指定です。

pip install "azure-ai-projects>=2.3.0" azure-identity

エージェントのバージョン作成

classic の create_agent() は、現行では create_version() になります。エージェントは名前で識別され、呼び出すたびに新しいバージョンが作られる設計です。定義は PromptAgentDefinition（prompt agent）または HostedAgentDefinition（hosted agent）で渡します。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import CodeInterpreterTool, PromptAgentDefinition
from azure.identity import DefaultAzureCredential

PROJECT_ENDPOINT = "https://your-resource.services.ai.azure.com/api/projects/your-project"

project = AIProjectClient(
    endpoint=PROJECT_ENDPOINT,
    credential=DefaultAzureCredential(),
)

agent = project.agents.create_version(
    agent_name="churn-analyst",
    definition=PromptAgentDefinition(
        model="gpt-4.1",
        instructions="解約データの集計と要約を担当します。数値の可視化にはCode Interpreterを使ってください。",
        tools=[CodeInterpreterTool()],
    ),
)
print(agent.id, agent.version)

返る id は churn-analyst:1 のように「名前:バージョン番号」の形式です。バージョンは1エージェントあたり1,000個までで、上限に達すると HTTP 400 が返ります。このエラーは一時的なものではないためリトライでは解消せず、古いバージョンを削除してから作り直します。

会話の作成と応答の生成

会話と応答は OpenAI クライアント側の操作です。project.get_openai_client() で取得し、conversations.create() で会話を作り、responses.create() にどのエージェントを使うかを agent_reference で指定します。

openai = project.get_openai_client()

conversation = openai.conversations.create(
    items=[
        {
            "type": "message",
            "role": "user",
            "content": "先月の解約率を前月と比較して要約してください",
        }
    ],
    metadata={"agent": "churn-analyst"},
)

response = openai.responses.create(
    input="先月の解約率を前月と比較して要約してください",
    conversation=conversation.id,
    extra_body={
        "agent_reference": {
            "name": "churn-analyst",
            "type": "agent_reference",
        }
    },
)
print(response.output_text)

classic では実行状態が queued や in_progress の間ポーリングし続けるコードが必要でしたが、現行版ではその待ち合わせループが不要になります。長時間かかる処理は background: true を使い、プラットフォーム側のポーリングとキャンセルに任せます。

料金構造と東日本リージョンの実単価

課金される3系統の内訳

Azure の Foundry Agent Service 料金ページは「There is no additional charge for creating or running Foundry-native agents using prompts and workflows.」と明記しています。prompt agent を作って動かすこと自体には課金されず、費用が発生するのは次の3系統です。

• モデルのトークン消費（Foundry Models 側の料金。Azure OpenAI モデルの単価はAzure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説を参照）
• ツールと知識接続（File Search のベクターストア保存量は1日あたり、Code Interpreter はセッション単位、Web Search は1,000トランザクション単位。Logic Apps コネクタ・Microsoft Fabric・SharePoint・Grounding with Bing Search は別ライセンス）
• hosted agent のコンテナ計算時間

hosted agentの時間単価と試算

コンテナ計算時間の実単価は Azure Retail Prices API から確認できます。2026年8月11日時点、米ドル建ての東日本（Japan East）と米国東部（East US）は次のとおりです。単価はこのAPIの実測値、メモリの単位は料金ページの Memory (GiB-hour) 表記に合わせています。

東日本にはメモリ機能の課金メーターも登録されています。Memory Retrievals が1,000回あたり0.55ドル、Long Term Memory Memories が1,000件あたり月0.275ドル、Short Term Memory Events Stored が1,000件あたり0.275ドルで、いずれも適用開始は2026年5月1日です。

1vCPU/2GiB のサンドボックスを東日本で1時間動かすと、0.10934ドル＋0.01298ドル×2＝0.1353ドルです。東日本は米国東部より vCPU で約10パーセント高いものの、単価差より効いてくるのは同時セッション数です。hosted agent はレプリカ単位ではなくセッション単位でサンドボックスが立つため、公式ドキュメントも「Billing is based on cpu + memory consumed across all active sessions, so oversizing multiplies cost by your concurrency.」と警告しています。同時100セッションなら1時間あたり13.53ドル、月200時間稼働で約2,706ドルという桁になります。

右サイジングの基準も示されています。Application Insights で観測した持続的なピークが割り当ての約70パーセントを超えるなら引き上げ、大きく下回るなら下げてください。バージョンは不変なので、変更のたびに新しいバージョンを作って再計測することになります。

日本から使う際のリージョン・ツール・データ保存先の制約

対応リージョンとツールの地域差

Responses API とエージェントに対応するのは30リージョンで、東日本（Japan East）と西日本（Japan West）はどちらも対応しています。ただし差があります。プライベートなクラスA アドレス範囲（10.x.x.x）に対応するのは東日本だけで、西日本は非対応です。10.x.x.x のアドレス空間を前提とした構成なら、選べるのは東日本です。

ツールの提供状況もリージョンで割れます。公式の対応表で東日本が「No」なのは Computer Use だけで、Azure AI Search・File Search・Code Interpreter・Web Search・MCP・OpenAPI・SharePoint を含む残り14ツールは使えます。Computer Use が要るなら East US 2、South India、Sweden Central のいずれかです。File Search はイタリア北部とブラジル南部で使えないなど、リージョンごとに欠ける組み合わせがあるため、構成を決める前に対応表を確認してください。

データの保存先とエージェントの権限

エージェントのデータがどこに置かれるかは、セットアップの選択で決まります。Basic setup では Microsoft 管理のストレージに論理的に分離して保存され、Standard setup では自分のサブスクリプション内の Azure Storage（ファイル）、Azure AI Search（ベクターストア）、Azure Cosmos DB（会話履歴・エージェント定義）に保存されます。データ所在地の要件がある案件では Standard setup が前提です。

権限まわりでは、hosted agent がデプロイ時に専用の Microsoft Entra ID（エージェント ID）を自動で受け取る点が実務に効きます。既定でモデル推論とセッションストレージにはアクセスできますが、自前の Azure Storage など外部リソースへは、このエージェント ID に対して RBAC ロールを個別に割り当ててください。Microsoft 365 チャネル経由でユーザーが呼び出す場合は OAuth 2.0 の On-Behalf-Of フローに対応します。

設計時に効く既定の上限値

引き上げ申請ができない固定の上限があります。ファイル1つあたり512MB、エージェントまたはスレッドあたり10,000ファイル、アップロード合計300GB、ベクターストアへ添付するファイルは2,000,000トークン、スレッドあたり100,000メッセージ、メッセージのテキスト1,500,000文字、登録ツール128個、有効リビジョン1,000個です。モデル呼び出しのレート制限だけはモデルデプロイ側の割り当てなので、こちらは増枠申請ができます。

Foundry Agent Serviceを選ぶべきでない場面

次の3つに当てはまるなら、いま Foundry Agent Service へ寄せるのは得策ではありません。

1つ目は、classic の Azure Functions ツールや Connected agents に深く依存した本番構成です。廃止期限がある以上いつかは移しますが、代替が「記載なし」あるいはプレビュー機能である現状で急ぐと、設計をもう一度やり直す確率が高くなります。代替機能の GA を待ちつつ移行設計だけ先に固めるほうが、総コストは下がります。

2つ目は、常時稼働させたい長時間バッチです。hosted agent のセッションは15分アイドルで解放される前提で、課金も同時アクティブセッション数の合計に比例します。24時間動き続ける処理をここに載せると、Azure Container Apps などで同等のコンテナを回すより高くつきやすく、セッション単位で状態を復元する仕組みの利点も活きません。

3つ目は、既存アプリケーションに生成AIの応答を1か所足したいだけのケースです。エージェント定義・バージョン管理・エンドポイント発行という仕組みは、ツール呼び出しを跨いだ自律的な判断が要る場合にこそ価値が出ます。判断の分かれ目は「モデルが複数ステップで自分でツールを選ぶ必要があるか」で、そこが無いならエージェントにしない選択が妥当です。

よくある質問

Azure AI Agent Serviceは今も使えますか？

classic 版として使えますが、非推奨で、廃止は2027年3月31日です。ドキュメントも分離済みで、classic の情報は URL が foundry-classic 配下に移っています。検索で古い手順に当たったときは、まず URL を見てどちらの世代かを確かめてください。

Foundry Agent Serviceは日本のリージョンで使えますか？

東日本・西日本とも対応しています。hosted agent の対応リージョンにも両方が入っており、日本国内でコンテナを動かす構成は取れます。ただし Grounding with Bing Search の対応リージョン一覧に入っているのは東日本だけで、西日本は入っていません。

Azure AI Agent ServiceのSDKはどれをインストールすればよいですか？

Python は azure-ai-projects（2.3.0以上・最新2.4.0）、JavaScript は @azure/ai-projects 2.4.0 と Node.js 22以降、Java は azure-ai-agents 2.2.0 です。紛らわしいのは Java で、Python では classic 側の名前だった azure-ai-agents が、Java では現行版の Maven アーティファクト名になっています。言語をまたいでパッケージ名を推測しないでください。

Semantic KernelやAgent Frameworkとはどう使い分けますか？

役割が違います。Foundry Agent Service は実行基盤で、Microsoft Agent Framework（Semantic Kernel と AutoGen の統合先）はエージェントのコードを書くためのライブラリです。Agent Framework で書いたコードをコンテナにして hosted agent としてデプロイする、という組み合わせが公式に想定されている使い方です。

prompt agentを作るだけで料金はかかりますか？

作成と実行そのものには追加料金がかかりません。発生するのはモデルのトークン消費とツール側の課金で、コンテナ計算時間は hosted agent にしか発生しません。なお File Search のベクターストアには1GBの無料枠があり、小さなナレッジベースなら保存料は発生しません。

関連記事

• Microsoft Foundry（Azure AI Foundry）とは何か？エンタープライズ向け生成AI統合プラットフォームの概要
• Microsoft Agent Framework 1.0とは｜Semantic KernelとAutoGenを統合した.NET/Python共通エージェントSDK
• AIエージェントフレームワークとは？主要8種の比較と受託開発視点の選定基準【2026年版】
• AIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】
• Azure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説