2026年6月4日に公開・更新されたAzure Updatesでは、Azure AI Foundry関連の開発体験として「Microsoft Foundry for Visual Studio Code」が一般提供（GA）になったことが案内されています。ポイントは、単なるVS Code拡張機能の名称変更ではなく、モデルカタログ、モデルプレイグラウンド、Hosted agent deploymentをエディター内で扱えるようになり、AIアプリやAIエージェントの開発・検証・展開の流れがVS Code中心に寄ったことです。(マイクロソフト Azure)
開発者にとっては、Azure AI Foundryの画面とVS Codeを何度も行き来する手間が減ります。一方で管理者にとっては、VS Codeからモデルやエージェント、Azure Container Registry、ロール割り当てなどのリソース操作が発生しやすくなるため、RBAC、クォータ、コスト、拡張機能の配布方針を先に確認しておく必要があります。
Azure AI FoundryのVS Code更新で何が変わったのか
今回の更新の中心は、Azure AI Foundryを使ったAI開発の入口が、ポータル中心から「VS Code内で完結しやすいワークフロー」に広がった点です。Azure Updates上ではステータスが「Launched」「General Availability」とされており、Azure Updatesの定義ではLaunchedは本番利用可能な状態として説明されています。(マイクロソフト Azure)
ただし、ここで一般提供になったと見るべき主語は、VS Code向けのFoundry開発体験です。Hosted agent deploymentをVS Codeから扱えることと、すべてのリージョン・すべての組織構成で制約なく運用できることは同じではありません。実際の利用可否は、Azureサブスクリプション、リージョン、モデルの提供状況、組織のネットワーク制御、RBACによって変わります。
| 変更点 | できるようになること | 実務上の意味 |
|---|---|---|
| フルモデルカタログの利用 | VS Code内でモデルを探し、用途に合うモデルを選びやすくなる | PoCの初動が速くなる一方、利用可能モデル・リージョン・料金の確認が重要になる |
| モデルプレイグラウンド | プロンプト、パラメーター、応答をエディター内で試せる | 実装前に出力品質や応答傾向を確認しやすい |
| Hosted agent deployment | ローカルのエージェントをMicrosoft Foundry Agent Serviceへ展開しやすくなる | デプロイ操作が開発者に近づくため、権限とコスト管理が重要になる |
| Foundryリソース管理 | プロジェクト、モデル、エージェントなどをVS Codeから確認・操作できる | ポータル操作に慣れていない開発者でも作業しやすくなる |
| Foundry Toolkitへの統合 | 従来分かれていたFoundry関連機能がFoundry Toolkit側にまとまる | 拡張機能の選定ミスや旧UIとの混在に注意が必要になる |
Microsoft Learnでは、Foundry Toolkit for Visual Studio Codeからプロジェクト作成、モデルデプロイ、モデルプレイグラウンド操作を行えると説明されています。前提条件としてAzureサブスクリプション、VS Code、クォータ、Foundryリソースを作成・管理するためのRBAC権限も挙げられています。(Microsoft Learn)
「Microsoft Foundry」と「Foundry Toolkit」の名称混在に注意する
今回の更新でつまずきやすいのが、拡張機能名の見え方です。Visual Studio Marketplaceでは「Foundry Toolkit for VS Code」が、AI Toolkitの新しい名称であり、Microsoft Foundryとの統合を反映したものだと説明されています。また、以前は別だったMicrosoft Foundry拡張機能は、この単一の拡張機能に統合されたと案内されています。([aka.ms][4])
そのため、社内展開では「Foundry」「Microsoft Foundry」「Foundry Toolkit」「AI Toolkit」という表記が混在しやすくなります。管理者は、開発者に対してインストール対象を明確に示すべきです。
おすすめは、次のように案内を統一することです。
| 社内で統一したい項目 | 推奨する扱い |
|---|---|
| 拡張機能名 | Foundry Toolkit for VS Code |
| 目的 | Azure AI Foundry / Microsoft Foundryのモデル、エージェント、リソースをVS Codeから扱う開発ツール |
| インストール元 | Visual Studio MarketplaceのMicrosoft公式発行元 |
| 旧拡張との関係 | 旧Foundry系拡張を使っている場合は、Foundry Toolkitへの統合状況を確認する |
| 社内ドキュメント表記 | 「Foundry Toolkit for VS Code（Azure AI Foundry開発用）」のように補足する |
VS Code公式ドキュメントでも、Foundry ToolkitにはFoundryサイドバーが直接含まれ、Foundry sidebarは2026年6月1日に廃止されると説明されています。既存ユーザーほど、古い手順書やスクリーンショットを参照して混乱しやすいため、社内の導入手順は早めに更新しておくと安全です。(Visual Studio Code)
開発者にとっての影響：AIアプリ開発の試行錯誤が速くなる
開発者側の最大のメリットは、モデル選定からプロンプト検証、サンプルコード生成、エージェント展開までの距離が短くなることです。
従来は、Azure AI Foundryのポータルでモデルを探し、別画面でデプロイし、エンドポイントやAPIキーを確認し、VS Codeに戻って実装する流れになりがちでした。今回の更新により、VS Code内で作業を進めやすくなります。
モデル選定と検証をVS Codeで進めやすい
Foundry Toolkitでは、Model Catalogから複数のモデルを探し、Playgroundでプロンプトやパラメーターを試せます。VS Code公式ドキュメントでは、OpenAI、Anthropic、Google、GitHubなどのモデルとの統合や、ONNX・Ollamaによるローカルモデル対応も説明されています。(Visual Studio Code)
実務では、次のような使い方が向いています。
| 利用シーン | 使い方の例 | 確認すべきポイント |
|---|---|---|
| チャットボットの初期検証 | 複数モデルに同じ問い合わせを投げて回答品質を比較する | 正確性、応答速度、料金、利用可能リージョン |
| 社内FAQのRAG検証 | システムプロンプトや検索結果の渡し方をPlaygroundで調整する | 機密情報を入力しない運用、評価データの準備 |
| API実装前の確認 | Playgroundで期待する応答形式を固めてからコード化する | JSON形式、エラー時の挙動、トークン使用量 |
| ローカル検証 | ローカルモデルでプロトタイプを作る | 本番モデルとの差、端末性能、再現性 |
Playgroundで良い応答が出たとしても、それだけで本番投入できるわけではありません。入力パターンを増やした評価、禁止すべき回答の確認、レート制限やコストの見積もりを必ず行うべきです。
サンプルコード生成で実装開始が早くなる
Microsoft Learnでは、デプロイ済みモデルを右クリックしてコードファイルを開き、SDK、言語、認証方式を選ぶことでサンプルコードを生成できる流れが説明されています。(Microsoft Learn)
これは初心者にとって便利ですが、生成されたコードをそのまま本番アプリに貼り付けるのは避けるべきです。特にAPIキーやエンドポイントの扱い、ログ出力、例外処理、リトライ、タイムアウト、監査ログは、アプリケーション側で設計し直す必要があります。
開発チームでは、サンプルコードを「動作確認用」と位置づけ、実装テンプレートは別途整備するのがおすすめです。
Hosted agent deploymentで管理上の重要度が上がる
今回の更新で特に管理者が注目すべきなのが、Hosted agent deploymentです。Marketplaceの説明では、VS CodeからHosted AgentをMicrosoft Foundry Agent Serviceへデプロイでき、コンテナーイメージをAzure Container Registryへビルド・プッシュする方法や、ZIPパッケージのアップロード、CPU・メモリ設定、RBAC、バージョン管理などに触れられています。([aka.ms][4])
これは便利な反面、開発者の手元のVS CodeからAzureリソースの作成・変更・デプロイが発生しやすくなるということでもあります。
ACR権限エラーは事前に対策する
Microsoft Foundry拡張機能のMarketplaceページでは、Hosted Agentのデプロイ時に拡張機能がAzure Container Registryを作成し、プロジェクトがコンテナーイメージを取得できるようロールを割り当てると説明されています。ロール割り当て権限がない場合は認可エラーが発生し、推奨回避策として管理者がACRを事前作成し、必要なロールを直接割り当てる方法が示されています。([Visual Studio Marketplace][6])
必要になる代表的なロールは次の通りです。
| 役割 | 割り当て先 | 目的 |
|---|---|---|
| Container Registry Repository Reader | プロジェクトのマネージドID | コンテナーイメージを読み取る |
| Container Registry Repository Catalog Lister | プロジェクトのマネージドID | リポジトリ一覧を取得する |
| Container Registry Repository Writer | 開発者のユーザーアカウント | コンテナーイメージをプッシュする |
注意したいのは、トラブル回避のために開発者へOwnerやUser Access Administratorを広く付与しないことです。Marketplaceでも、ロール自動割り当てのために強い権限を与える方法は過剰権限になり得るため推奨されない扱いになっています。([Visual Studio Marketplace][6])
管理者が確認すべき設定と展開ポイント
Foundry Toolkit for VS CodeのGAは、開発効率を高める更新です。しかし、組織で安全に使うには、拡張機能の導入そのものよりも、Azure側のガバナンス設計が重要です。
事前チェックリスト
| 確認項目 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| 拡張機能の配布方針 | Foundry Toolkit for VS Codeを標準拡張として許可するか、対象者を限定するか | 個人判断で旧拡張や類似拡張を入れてしまう |
| Azureサインイン | 業務用Entra IDアカウントで利用させる | 個人アカウントや別テナントでリソースを作成する |
| RBAC | Foundryリソース作成、モデルデプロイ、ACR操作、ロール割り当ての権限を整理する | デプロイ失敗、または過剰権限の付与 |
| クォータ | モデルデプロイに必要なサブスクリプションクォータを確認する | 検証中にモデルを展開できない |
| リージョン | 利用予定モデルとFoundry機能が対象リージョンで使えるか確認する | 開発環境と本番環境で再現できない |
| コスト管理 | 予算、タグ、リソースグループ、削除ルールを決める | PoCリソースが残り続け、不要コストが発生する |
| ACR | Hosted Agent用のACR作成方針とロール割り当てを決める | デプロイ時に権限エラーが出る |
| 機密情報 | Playgroundやプロンプトに入力してよいデータ範囲を決める | 個人情報・機密情報の入力事故 |
| テレメトリ | VS Codeと拡張機能のテレメトリ設定を確認する | 社内ポリシーと不整合が起きる |
| 本番展開 | VS Codeからの直接デプロイをどこまで許可するか決める | レビューなしに本番リソースが変更される |
Foundry Toolkitは利用データをMicrosoftへ送信して製品改善に使うことがあり、VS Codeのtelemetry.enableTelemetry設定を尊重するとMarketplaceで説明されています。社内でテレメトリ制御ポリシーがある場合は、拡張機能導入時に合わせて確認しておきましょう。([aka.ms][4])
クォータと課金はPoC段階から見る
Microsoft Learnでは、モデルを新規デプロイするにはサブスクリプションがクォータ上限を超えていない必要があると説明されています。(Microsoft Learn)
PoCでは「少し試すだけ」と考えがちですが、モデルデプロイ、エージェント実行、ACR、ログ、評価、トレースなど、複数の課金ポイントが発生する可能性があります。特に複数チームが同時に検証を始めると、クォータ不足や予算超過が起きやすくなります。
最初に決めておきたいルールは次の3つです。
- PoC用の専用サブスクリプションまたはリソースグループを用意する
- リソース名とタグに、所有者、用途、削除予定日を入れる
- 月次ではなく週次でコストと未使用リソースを確認する
開発チーム向けの推奨ワークフロー
Foundry Toolkit for VS Codeを導入したら、いきなり本番エージェントをデプロイするのではなく、小さな流れで検証するのが安全です。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 1 | Foundry Toolkit for VS Codeをインストールする | VS CodeのActivity BarにFoundry Toolkitが表示される |
| 2 | Azureアカウントでサインインする | 対象サブスクリプションとリソースグループが見える |
| 3 | Foundryプロジェクトを開く | Models、Agentsなどのリソースが確認できる |
| 4 | Model Catalogで候補モデルを選ぶ | 用途、料金、リージョン、クォータを確認できている |
| 5 | Model Playgroundでプロンプトを試す | 代表的な入力パターンで期待する出力が得られる |
| 6 | サンプルコードを生成してローカルで試す | 認証情報を直書きせず、環境変数やKey Vault利用方針を決めている |
| 7 | Hosted Agentを開発環境へデプロイする | ACR、RBAC、ログ、ヘルスチェックを確認できている |
| 8 | 評価・トレース・削除まで確認する | 品質評価と不要リソース削除の手順が残っている |
VS Code公式ドキュメントでは、Foundry ToolkitのDeveloper ToolsにModel Catalog、Tool Catalog、Create Agent、Agent Inspector、Deploy to Microsoft Foundry、Hosted Agent Playground、Model Playground、Tracing、Evaluationなどが含まれると説明されています。(Visual Studio Code)
つまり、今後のAzure AI Foundry開発では「作って終わり」ではなく、評価、トレース、再デプロイまでをVS Code上の一連の作業として設計しやすくなります。
移行・展開で失敗しやすいポイント
旧拡張機能と新しいFoundry Toolkitを混在させる
最も起きやすいのは、古い手順書を見て別の拡張機能を入れてしまうケースです。特に「Microsoft Foundry extension」「AI Toolkit」「Foundry Toolkit」の表記が混在している環境では、社内標準を決めないと問い合わせが増えます。
展開時は、インストール対象の拡張機能名、発行元、Marketplaceページ、確認方法を1ページにまとめておきましょう。
Playgroundの成功を本番品質と勘違いする
Playgroundは検証に便利ですが、1〜2個のプロンプトで良い回答が出ただけでは品質保証になりません。最低でも、成功例、失敗例、境界条件、禁止トピック、長文入力、曖昧な質問、悪意ある入力を含めたテストセットを用意する必要があります。
AIエージェントの場合は、ツール呼び出しの失敗、外部APIのタイムアウト、権限不足、レスポンス遅延も評価対象に含めましょう。
開発者に強すぎるAzure権限を与える
Hosted Agentの展開で権限エラーが出ると、対処としてOwner権限を付けたくなります。しかし、これは長期的には危険です。
推奨は、管理者がACRやリソースグループを事前に用意し、必要最小限のロールを割り当てる方式です。特に本番環境では、VS Codeからの直接デプロイを許可せず、Pull Request、CI/CD、承認フローを経由させる設計が現実的です。
APIキーやエンドポイントをコードに直書きする
VS CodeからエンドポイントやAPIキーにアクセスしやすくなるほど、サンプルコードに認証情報を残す事故も起きやすくなります。
開発標準として、次のルールは必須です。
- APIキーをソースコードやREADMEに書かない
.envを使う場合は.gitignoreに含める- 本番ではKey VaultやマネージドIDの利用を検討する
- ログにプロンプト、応答、キー、接続文字列を出さない
- GitHubなど外部リポジトリへの誤コミット対策を入れる
どの組織が優先して確認すべきか
今回の更新は、すべてのAzure利用者がすぐに大きな対応を迫られるものではありません。ただし、次の組織は早めに確認した方がよいでしょう。
| 対象 | 優先度 | 理由 |
|---|---|---|
| Azure AI FoundryでPoCを進めている開発チーム | 高 | VS Code中心の開発に切り替えると検証速度が上がる |
| AIエージェントを内製している組織 | 高 | Hosted Agent展開、評価、トレースの標準化に関係する |
| 開発者にAzureリソース作成権限を与えている組織 | 高 | VS Codeからのリソース操作範囲を把握する必要がある |
| 旧AI Toolkitや旧Foundry拡張を使っているチーム | 中〜高 | Foundry Toolkitへの統合に合わせて手順更新が必要 |
| まだAzure AI Foundryを使っていない組織 | 中 | まずはローカル検証やGitHubホストモデルで試す選択肢がある |
| 厳格なネットワーク分離環境の組織 | 中〜高 | VS Code、Azure、ACR、Foundryリソース間の接続要件を確認する必要がある |
Microsoftのドキュメントでは、Foundry Toolkitの最初のステップとしてGitHubホストモデルやローカルのPrompt Agentから始められ、準備ができたらMicrosoft Foundryに接続してマネージドホスティング、モデルデプロイ、評価、トレース、チーム共同作業に進める流れも説明されています。([aka.ms][4])
まず実施すべきこと
今回のGA更新は、Azure AI Foundryを「ポータルで試すサービス」から「開発者の日常的なVS Codeワークフローに組み込むサービス」へ近づけるものです。開発者にとっては、モデル選定、プロンプト検証、エージェント開発、展開の流れが速くなります。一方で管理者にとっては、拡張機能、RBAC、ACR、クォータ、コスト、テレメトリ、データ入力ルールを整備する必要があります。
最初にやるべきことは、全社展開ではなく、小さな検証です。
1つの開発用サブスクリプション、1つのリソースグループ、1つのFoundryプロジェクトを用意し、Foundry Toolkit for VS Codeからモデルの確認、Playgroundでの検証、サンプルコード生成、Hosted Agentの開発環境デプロイ、不要リソース削除までを一通り試します。その結果をもとに、社内の標準手順、権限設計、禁止事項、コスト確認フローを作るのが安全です。
特にHosted Agentを使う予定がある場合は、ACRとロール割り当てを事前に設計してください。ここを後回しにすると、開発者はデプロイ時の権限エラーに悩み、管理者は過剰権限付与の判断を迫られます。GAになった今こそ、便利になった開発体験をそのまま本番環境へ持ち込むのではなく、組織のガバナンスに合わせて使い方を標準化することが重要です。
[4]: https://aka.ms/foundrytk “
Foundry Toolkit for VS Code – Visual Studio Marketplace
“
[6]: https://marketplace.visualstudio.com/items?itemName=TeamsDevApp.vscode-ai-foundry “
Microsoft Foundry – Visual Studio Marketplace
“
コメント