Azure AI FoundryのVS Code拡張機能は、開発者がVisual Studio CodeからFoundryプロジェクトを開き、モデルカタログの確認、モデルのデプロイ、モデルプレイグラウンドでの検証、サンプルコード生成まで進められるようにする開発者向けの拡張機能です。結論として、これは既存システムを即座に壊すような変更ではありませんが、AIモデルの作成・デプロイ・検証が開発者のローカルIDEに近づくため、管理者はRBAC、クォータ、課金、モデル利用ルール、キー管理を事前に確認する必要があります。公式ドキュメントでは、Microsoft Foundry for Visual Studio Code拡張機能を使って、プロジェクト作成、Foundryモデルカタログからのモデルデプロイ、VS Code内でのモデルプレイグラウンド操作を行えると説明されています。(Microsoft Learn)
なお、現在の公式ドキュメントでは「Azure AI Foundry」から「Microsoft Foundry」へ名称が移行しています。Microsoftの説明では、Azure AI Studio / Azure AI Foundryは現在のMicrosoft Foundryへ進化しており、基盤となるAzureリソース種別は引き続きMicrosoft.CognitiveServices/accountsです。既存環境を調査するときは、画面名・ロール名・リソース種別が混在して見える可能性があります。(Microsoft Learn)
Azure AI FoundryのVS Code拡張機能は何が変わるのか
今回整理すべきポイントは、「Azure AI FoundryがVS Codeだけで完結する」という意味ではありません。正しくは、Foundryポータルで行っていた一部の開発作業を、VS Code上から直接実行しやすくなるという変化です。
公式手順では、拡張機能の画面が「Resources」「Tools」「Help and Feedback」の3領域で構成され、Resourcesにはデプロイ済みモデル、エージェント、接続、ベクターストアなどが表示されます。Toolsからはモデルカタログ、モデルプレイグラウンド、エージェントプレイグラウンドなどにアクセスできます。(Microsoft Learn)
| 変化する作業 | VS Code拡張機能でできること | 実務上の影響 |
|---|---|---|
| プロジェクト作成 | VS Code内からFoundryプロジェクトを作成できる | 管理者がリソースグループ名、リージョン、命名規則を決めておかないと、試作用リソースが乱立しやすい |
| モデル探索 | モデルカタログを開き、提供元・発行元・機能・モデル種別などで絞り込める | 開発者が複数モデルを比較しやすくなる一方、利用許可済みモデルの基準が必要 |
| モデルデプロイ | デプロイ名、デプロイ種類、モデルバージョン、Tokens per minuteを指定してデプロイできる | クォータ消費、課金、リージョン、レート制限の管理が重要になる |
| モデル管理 | デプロイ情報、エンドポイント、認証方式、キー、レート制限、モデルバージョンを確認できる | 開発者の生産性は上がるが、キーやエンドポイント情報の取り扱いルールが必要 |
| サンプルコード生成 | SDK、言語、認証方式を選んでスターターコードを生成できる | PoCから実装への移行が速くなるが、生成コードをそのまま本番利用しないレビュー体制が必要 |
| プレイグラウンド操作 | プロンプト入力、出力確認、システム指示の調整、コード表示、履歴確認ができる | プロンプト検証が容易になるため、機密情報を入力しないルールの徹底が必要 |
特に重要なのは、モデルカードからエンドポイント情報やキーにアクセスできる点です。便利な一方で、スクリーンショット、チャットツールへの貼り付け、ローカルファイルへの平文保存が起きると情報漏えいリスクになります。(Microsoft Learn)
対象者と影響範囲
この拡張機能の影響は、AIアプリを作る開発者だけにとどまりません。VS Codeからモデルのデプロイやプロジェクト操作が可能になるため、Azure管理者、セキュリティ担当、FinOps担当、プラットフォームチームも確認対象です。
| 対象者 | 確認すべきこと | 判断基準 |
|---|---|---|
| アプリ開発者 | 既定プロジェクト、使用できるモデル、認証方式、サンプルコードの扱い | 「個人の試作」ではなく、チームの標準プロジェクトで作業できているか |
| Azure管理者 | RBAC、リソースグループ、リージョン、クォータ、ロール割り当て | 開発者にOwner権限を渡さず、必要最小限の権限で運用できるか |
| セキュリティ担当 | APIキー、プロンプト入力、データ所在地、プレビュー機能の扱い | 機密データや個人情報をプレイグラウンドに入力しない統制があるか |
| AI基盤チーム | 利用可能モデル、デプロイ種類、レート制限、SDKバージョン | 本番候補のモデル・リージョン・APIが標準化されているか |
| FinOps担当 | モデルデプロイ数、TPM、不要リソース、課金単位 | PoC終了後にモデルやリソースグループを削除する運用があるか |
Foundryは、開発者、MLエンジニア、データサイエンティスト、IT管理者、プラットフォームエンジニアを対象にした統合AIプラットフォームとして説明されています。VS Code拡張機能はその中でも「開発環境からモデルやエージェントを扱う」導線に位置づけられます。(Microsoft Learn)
導入前に確認すべき前提条件
公式手順では、Azureサブスクリプション、Visual Studio Code、モデルデプロイ用のクォータ、Foundryリソースを作成・管理するための適切なRBAC権限が前提条件として挙げられています。拡張機能はVisual Studio Code MarketplaceまたはVS Code内の拡張機能ビューからインストールできます。(Microsoft Learn)
導入前チェックは、次の順で進めると失敗を減らせます。
| 確認項目 | 具体的な確認内容 | よくある失敗 |
|---|---|---|
| Azureサブスクリプション | PoC用、本番用、部門用のどのサブスクリプションを使うか | 個人検証用サブスクリプションで本番候補の検証を始めてしまう |
| RBAC | Foundry User、Foundry Project Manager、Foundry Ownerなどの役割を誰に付与するか | 開発者に広すぎるOwner権限を付与してしまう |
| クォータ | 新しいモデルをデプロイできる余裕があるか | モデルデプロイ時にクォータエラーで止まる |
| リージョン | 使用したいモデルやResponses APIが対象リージョンで使えるか | 既存リソースのリージョンが機能に対応していない |
| モデル利用ルール | Microsoft、OpenAI、Meta、DeepSeek、Hugging Faceなどのうち、どのモデルを許可するか | 開発者ごとに異なるモデルでPoCが進み、比較できない |
| 認証方式 | Entra ID認証を優先するか、APIキーを許可するか | APIキーがローカルやリポジトリに残る |
| コスト管理 | TPM、デプロイ数、不要リソース削除の基準 | PoC後のモデルやリソースグループが残り続ける |
クォータに達している場合は、クォータを確認し、増加申請または未使用デプロイの削除を検討する必要があります。拡張機能のトラブルシューティングでも、モデルデプロイがクォータエラーで失敗する場合の対処として、サブスクリプションクォータの確認が挙げられています。(Microsoft Learn)
管理者が最初に見直すべきRBACと認証
Azure AI Foundry、現在のMicrosoft Foundryで最初に確認すべき設定はRBACです。Microsoftの公式情報では、RBACロールはMicrosoft Entra IDで認証する場合に適用され、キーベース認証ではロール制限なしのフルアクセスを許可するため、セキュリティと細かなアクセス制御の観点からEntra ID認証が推奨されています。(Microsoft Learn)
また、Foundry RBACロールは名称変更が進んでおり、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerに対応します。ロール名の展開中は旧名が表示されることがありますが、ロールIDと中核的な権限は変わらないとされています。(Microsoft Learn)
実務では、次のように分けると管理しやすくなります。
| 利用シーン | 推奨される権限設計の考え方 |
|---|---|
| 個人検証 | 専用リソースグループと検証用Foundryプロジェクトを用意し、不要になったらまとめて削除する |
| チーム開発 | リード開発者にプロジェクト管理権限を付与し、一般開発者はプロジェクト単位の利用権限に絞る |
| 本番前検証 | モデルデプロイ、TPM変更、キー参照を実行できる担当者を限定する |
| 本番運用 | デプロイ変更は承認制にし、開発者はサンプルコード生成やプレイグラウンド検証までに制限する |
注意したいのは、VS Code拡張機能が便利だからといって、全開発者にOwnerやUser Access Administratorを付与しないことです。Hosted Agentの展開ではACRのロール割り当てが関係する場合があり、Marketplaceの説明では、権限不足時の回避策としてACRロールの事前割り当てが推奨され、過剰な権限付与は推奨されていません。([Visual Studio Marketplace][5])
開発者向けの基本手順
開発者がAzure AI FoundryのVS Code拡張機能を使う場合は、いきなりモデルをデプロイするのではなく、既定プロジェクトと権限を確認してから進めるのが安全です。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | VS CodeにMicrosoft Foundry拡張機能をインストールする | 左側ナビゲーションにFoundryアイコンが表示されるか |
| 2 | Azure ResourcesビューからAzureにサインインする | 正しいテナント、サブスクリプション、リソースグループを選んでいるか |
| 3 | Foundryプロジェクトを右クリックして拡張機能で開く | チーム標準のプロジェクトを開いているか |
| 4 | 必要に応じて既定プロジェクトを切り替える | 誤って別プロジェクトへデプロイしないか |
| 5 | モデルカタログを開く | 許可済みのモデル、リージョン、デプロイ種類か |
| 6 | モデルをデプロイする | デプロイ名、モデルバージョン、TPMを記録しているか |
| 7 | モデルカードを確認する | エンドポイント、認証方式、レート制限、キーを安全に扱っているか |
| 8 | プレイグラウンドで検証する | 機密情報や個人情報をプロンプトに入れていないか |
| 9 | サンプルコードを生成する | SDK、言語、認証方式がチーム標準と合っているか |
| 10 | 不要なモデルを削除する | PoC後の課金リソースが残っていないか |
公式手順では、コマンドパレットからFoundry: Open Model Catalogを実行したり、ResourcesセクションのModelsからモデルカタログを開いたりできます。モデルデプロイでは、デプロイ名、デプロイ種類、モデルバージョン、Tokens per minuteを指定し、デプロイ後はModelsセクションにデプロイ名で表示されます。(Microsoft Learn)
モデルデプロイ時の注意点
モデルカタログにアクセスできることと、そのモデルを本番で使ってよいことは別です。Foundry Modelsの概要では、Microsoft、OpenAI、DeepSeek、Hugging Face、Metaなどのモデルを探索できると説明されていますが、利用者はモデルカードや関連ドキュメントを確認し、ユースケースに適したモデルを選ぶ責任があります。(Microsoft Learn)
特に、パートナーやコミュニティのモデルではAzure Marketplaceへのサブスクライブが必要になる場合があります。一方、Azureによって販売されるFoundry Models、たとえばAzure OpenAIモデルでは、その要件が適用されない例も示されています。モデル選定では、提供元、契約条件、データ処理、サポート範囲を必ず確認してください。(Microsoft Learn)
判断基準としては、次の順に確認すると実務で迷いにくくなります。
| 判断軸 | 確認する内容 |
|---|---|
| 用途 | チャット、要約、コード生成、画像理解、エージェントなど、目的に合うか |
| 提供元 | Microsoft、OpenAI、Meta、DeepSeek、Hugging Face、その他プロバイダーのどれか |
| 契約・条件 | Marketplaceサブスクライブや追加条件が必要か |
| リージョン | 自社のデータ所在地・可用性要件に合うリージョンで使えるか |
| スループット | TPMやレート制限が想定ユーザー数に足りるか |
| コスト | PoC、検証、本番で許容できる課金か |
| セキュリティ | キー管理、Entra ID認証、ログ、プロンプト入力ルールが整っているか |
VS Code上でモデルをデプロイできるようになると、検証スピードは上がります。その分、開発者の判断だけでモデルが増えやすくなるため、「許可済みモデル一覧」「デプロイ名の命名規則」「PoC終了後の削除期限」を先に決めることが重要です。
移行・展開で見落としやすいポイント
Azure AI Foundry周辺では、名称、ポータル、SDK、APIの移行が進んでいます。公式の移行ドキュメントでは、Azure AI Studio / Azure AI FoundryからMicrosoft Foundryへ名称が進化したことに加え、2026年5月30日にazure-ai-inferenceパッケージが廃止予定であること、2026年8月26日にAssistants APIが終了予定であることが示されています。(Microsoft Learn)
VS Code拡張機能を導入しても、既存アプリのSDKやAPIが自動で移行されるわけではありません。特に、サンプルコードを生成してアプリに組み込む場合は、既存プロジェクトが旧ポータル、旧SDK、旧API前提になっていないかを確認してください。公式ドキュメントでも、SDKバージョンがポータル体験と一致しないとエラーの原因になると説明されています。(Microsoft Learn)
移行期の開発チームでは、次の3点を標準ルールとして決めておくと混乱を避けられます。
| 項目 | 推奨ルール |
|---|---|
| 名称 | 社内資料では「Azure AI Foundry（現 Microsoft Foundry）」のように併記し、旧名検索にも対応する |
| SDK | 新規開発は現行ポータルと対応するSDKバージョンを使い、旧SDKの利用箇所を棚卸しする |
| API | Assistants API依存のワークロードは終了予定日から逆算し、Responses APIやFoundry Agentsへの移行計画を立てる |
セキュリティとプライバシーで確認すべきこと
VS Code拡張機能によって、モデルプレイグラウンドが開発者の通常作業に近づきます。そのため、セキュリティ上の最大の注意点は「試しに入力したプロンプト」や「モデルカードで確認したキー・エンドポイント」の扱いです。
Microsoftのデータ、プライバシー、セキュリティに関する公式情報では、Azureで販売されるFoundry Modelsについて、プロンプト、出力、埋め込み、トレーニングデータは他の顧客やOpenAIなどのプロバイダーには利用可能にならず、許可や指示なしに生成AI基盤モデルのトレーニングにも使われないと説明されています。一方で、サービス提供や不正利用監視のためにデータが処理されること、Responses APIなど一部機能ではメッセージ履歴などが保存されることも説明されています。(Microsoft Learn)
また、GlobalやDataZoneのデプロイ種類では、プロンプトや応答の処理場所が通常の標準デプロイとは異なる場合があります。データ所在地や規制要件が厳しい業務では、モデルの機能だけでなく、デプロイ種類と処理地域も確認してください。(Microsoft Learn)
| リスク | 起きやすい例 | 対策 |
|---|---|---|
| 機密情報の入力 | プレイグラウンドに顧客名、契約内容、社内コードを貼り付ける | 検証用プロンプトのテンプレートを作り、機密情報入力を禁止する |
| キー漏えい | モデルカードのAPIキーをメモやチャットに貼る | Entra ID認証を優先し、キー参照できる担当者を限定する |
| リージョン不一致 | Global/DataZoneの意味を確認せずにデプロイする | デプロイ種類ごとの処理場所を確認し、承認フローに入れる |
| サンプルコードの直投入 | 生成されたコードをレビューせず本番に入れる | 認証、ログ、例外処理、レート制限をレビューする |
| 不要リソース放置 | PoC後のモデルデプロイやリソースグループが残る | 削除期限、タグ、予算アラートを設定する |
よくあるトラブルと対処
拡張機能のトラブルは、インストール、サインイン、権限、クォータの4つに集中します。公式のトラブルシューティングでは、拡張機能が表示されない場合はVS Codeの再起動と拡張機能が有効かの確認、サインイン失敗やサブスクリプション未表示の場合はAzureアカウントの権限確認とサインアウト・再サインイン、モデルデプロイのクォータエラーではサブスクリプションクォータの確認や未使用デプロイの削除が案内されています。(Microsoft Learn)
| 症状 | 主な原因 | 対処 |
|---|---|---|
| Foundryアイコンが表示されない | 拡張機能が無効、VS Codeの反映遅延 | VS Codeを再起動し、拡張機能ビューで有効化を確認する |
| サブスクリプションが表示されない | サインイン先テナント違い、RBAC不足 | Azure Resourcesビューでサインアウト後、正しいアカウントで再サインインする |
| プロジェクトが開けない | Foundryプロジェクトへの権限不足 | Foundry Userなど、必要なロール割り当てを管理者に確認する |
| モデルデプロイに失敗する | クォータ不足、リージョン不一致、Marketplace条件未対応 | クォータ、モデルの対応リージョン、Marketplaceサブスクライブ要件を確認する |
| Hosted Agent展開でACR権限エラー | ACR作成やロール割り当て権限が不足 | 管理者がACRロールを事前割り当てする。安易にOwner権限を配布しない |
開発者が自力で解決しようとして権限を広げるより、管理者が標準の問い合わせテンプレートを用意するほうが安全です。テンプレートには、サブスクリプションID、リソースグループ名、Foundryプロジェクト名、使用モデル、エラー内容、必要な操作を記入させると、権限付与の判断がしやすくなります。
組織展開する場合のおすすめ手順
全社展開では、いきなり全開発者に拡張機能を配るのではなく、小さなチームで検証してから標準化するのが現実的です。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 事前整理 | 許可モデル、リージョン、RBAC、命名規則、削除ルールを決める | 管理者と開発チームが同じルールを参照できる |
| パイロット | 1つのFoundryプロジェクトで拡張機能、モデルデプロイ、プレイグラウンドを試す | デプロイ、コード生成、削除まで一連の手順を確認できる |
| 標準化 | サンプルコード、認証方式、ローカル設定、プロンプト入力ルールを文書化する | 新規メンバーが同じ手順で開始できる |
| 拡大展開 | チーム単位で利用を広げ、クォータと課金を監視する | 不要リソースの削除とモデル利用状況のレビューが回る |
| 本番適用 | 承認済みモデル、CI/CD、監視、セキュリティレビューを組み込む | VS Codeで作った試作が本番標準に沿って移行できる |
最初のゴールは、モデルを大量に試すことではありません。1つの承認済みモデルを、正しいプロジェクトに、適切な権限でデプロイし、プレイグラウンドで検証し、サンプルコードを安全に取り込むところまでを標準手順にすることです。
まず取るべき次のアクション
Azure AI FoundryのVS Code拡張機能は、開発者にとっては便利な近道ですが、管理者にとってはAIリソース作成とモデル利用の入口が増えることを意味します。導入前に、RBAC、クォータ、モデル利用ルール、キー管理、データ入力ルール、不要リソース削除の基準を決めてください。
すでにAzure AI FoundryやAzure AI Studio時代の環境を使っている場合は、名称変更、ロール名変更、SDK移行、Assistants APIの終了予定もあわせて棚卸しする必要があります。新規チームで始める場合は、まず検証用のリソースグループとFoundryプロジェクトを用意し、許可済みモデルを1つ選んで、VS Code拡張機能からデプロイ、プレイグラウンド検証、サンプルコード生成、削除までを一度通して確認しましょう。
[5]: https://marketplace.visualstudio.com/items?itemName=TeamsDevApp.vscode-ai-foundry “
Microsoft Foundry – Visual Studio Marketplace
“
コメント