Foundry Toolkit for Visual Studio Codeの2026年4月更新で最も重要なのは、Microsoft Foundryを使ったAIアプリケーション／AIエージェント開発を、VS Code内で設計・検証・デバッグ・デプロイまで進めやすくなった点です。2026年4月24日にMicrosoft公式のAzure Updatesで「Foundry Toolkit for Visual Studio Code reaches general availability」として更新され、Foundry Toolkit for VS Codeは一般提供となりました。(Microsoft Azure)
これまでAI Toolkit for VS Codeとして使っていた開発者にとっては、単なる名称変更ではありません。モデル選定、Prompt AgentやHosted Agentの作成、GitHub Copilotとの連携、Agent Inspectorによるデバッグ、Microsoft Foundry Agent Serviceへのデプロイといった作業を、日常的なVS Codeワークフローに寄せられるようになりました。Microsoftは、AI ToolkitからMicrosoft Foundry Toolkitへのリブランドについて、既存機能を削除・非推奨化する予定はないと説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
developers、DevOps engineers、platform teamsが今すぐ取るべき行動は、いきなり本番エージェントを作ることではありません。まずは1つの実業務シナリオを選び、Foundry Toolkit for Visual Studio Codeで「モデル比較」「プロンプト設計」「ツール接続」「デバッグ」「評価」「デプロイ手順」までを小さく検証することです。
Foundry Toolkit for Visual Studio Codeの最新動向: GAで何が変わったか
今回のGAは、AI開発を「VS Codeの中で完結しやすくする」方向への大きな節目です。Microsoftの発表では、Foundry Toolkit for VS CodeはAI Toolkitから名称変更され、モデルの検証からproduction-grade AI agentsの開発までをVS Code内で進められるツールとして位置付けられています。(TECHCOMMUNITY.MICROSOFT.COM)
| 更新ポイント | 何が変わったか | 実務での見方 |
|---|---|---|
| 一般提供化 | Foundry Toolkit for VS CodeがGAとして提供 | チーム標準ツール候補として評価しやすくなった |
| AI Toolkitからの名称変更 | Microsoft Foundry Toolkitへリブランド | 社内ドキュメントや手順書の名称を更新する |
| モデル検証の強化 | Microsoft Foundry、GitHub、OpenAI、Anthropic、Ollamaなどのモデルを扱える | PoC段階で複数モデルを比較しやすい |
| Agent Builder | ノーコード／ローコードでエージェント案を作成 | 企画・業務部門との初期検証に向く |
| GitHub Copilot連携 | Foundry toolsやskillsを使い、Agent Frameworkベースの作成を支援 | 生成されたコードや設定はレビュー前提で使う |
| Agent Inspector | ワークフロー可視化、ブレークポイント、ローカルトレースに対応 | AIエージェントを「黒箱」のままにしない |
| Microsoft Foundry Agent Serviceへの展開 | ローカルからクラウドへの移行導線を用意 | 本番化前に権限、クォータ、監査、評価基準を確認する |
| エッジ最適化 | Phiモデルファミリー、NPU/GPU向けの量子化・プロファイルに言及 | Copilot+ PCやオンデバイスAIの検証候補になる |
重要なのは、Foundry Toolkit for Visual Studio Codeが「モデルを試す拡張機能」から、「AIエージェント開発の作業台」に近づいたことです。特にAgent Builder、Agent Inspector、Tool Catalog、Model Catalogが同じVS Code体験の中にまとまることで、プロンプト調整と実装、検証、運用準備の距離が短くなります。(Visual Studio Code)
GAの意味を誤解しない：安定したのは「VS Codeの開発導線」
Azure Updatesでは、Launchedは「Fully released, production-ready product available to all Azure customers」と説明されています。つまり今回の一般提供化は、Foundry Toolkit for Visual Studio Codeを正式な開発ツールとして扱いやすくなったことを意味します。(Microsoft Azure)
ただし、「Foundry ToolkitがGAになった」ことと、「関連するすべての機能・接続先・ホステッドエージェント機能が完全にGAである」ことは同じではありません。たとえば、MicrosoftのFoundryブログでは、最新のHosted AgentsへのデプロイはFoundry Toolkitのpre-releaseで利用できると説明されています。(Microsoft for Developers)
また、Tool Catalogのドキュメントでは、Toolbox supportはpreviewで、Foundry Toolkitのpre-release版でのみ利用可能とされています。(Visual Studio Code)
| 判断項目 | 推奨される扱い |
|---|---|
| VS Code内でのモデル探索、プロンプト検証、エージェント設計 | 通常の開発検証に組み込みやすい |
| Agent Inspectorによるローカルデバッグ | 開発標準に入れる価値が高い |
| Microsoft Foundryへのデプロイ | 小規模な検証から段階的に進める |
| Hosted AgentsやToolboxなどpreview表記のある機能 | 本番前に利用条件、サポート範囲、変更リスクを確認する |
| 自動ツール実行、MCP連携、外部API接続 | 承認フロー、監査、シークレット管理を先に設計する |
実務では、GAという言葉だけで導入可否を決めず、「どの部分がGAで、どの部分がpreviewか」を分けて管理することが重要です。プラットフォームチームは、機能ごとに利用レベルを「検証可」「限定利用可」「本番利用可」の3段階で定義しておくと、チーム内の混乱を防げます。
開発者にとっての更新ポイント
モデル選定をVS Code内で始めやすくなった
Foundry Toolkit for Visual Studio Codeでは、Model Catalogを使って複数のモデル提供元を探索できます。公式ドキュメントでは、Microsoft Foundry、Foundry Local、GitHub、ONNX、Ollama、OpenAI、Anthropic、Googleなどがモデルソースとして挙げられています。(Visual Studio Code)
これは、AIアプリ開発でよくある「最初にどのモデルを使えばよいか分からない」という問題を減らします。たとえば、以下のように目的別に切り分けると選びやすくなります。
| 目的 | 最初に見る候補 | 判断基準 |
|---|---|---|
| すばやいPoC | GitHub ModelsやPlaygroundで試せるモデル | セットアップの軽さ、応答品質、レイテンシ |
| 本番候補の検証 | Microsoft Foundry上にデプロイできるモデル | クォータ、リージョン、セキュリティ、コスト |
| ローカル実行 | ONNX、Ollama、Foundry Local | オフライン性、端末性能、データ持ち出し制限 |
| 独自モデル利用 | BYOM、外部デプロイ済みモデル | 接続方式、認証、運用監視、SLA |
| エッジAI | Phi系モデルやNPU/GPU向け構成 | 推論速度、メモリ使用量、量子化後の精度 |
初心者は「有名なモデルだから」という理由だけで選びがちですが、実務では応答品質だけでは不十分です。入力データの機密性、呼び出し回数、レスポンス時間、リージョン、運用コスト、評価方法まで含めて比較する必要があります。
Agent Builderでプロンプトエージェントを素早く作れる
Agent Builderは、プロンプトエンジニアリングとツール連携をまとめて扱うための機能です。公式ドキュメントでは、MCPサーバーとの接続、新しいMCPサーバーのスキャフォールド、function callingによる外部APIやサービス連携が説明されています。(Visual Studio Code)
実務での使いどころは、完成品の開発よりも「業務要件の確認」です。たとえば、問い合わせ分類エージェントを作る場合、最初から大規模なコードを書くのではなく、Agent Builderで次の内容を検証します。
- どの入力項目が必要か
- どの分類軸が業務に合うか
- モデルの回答に揺れがあるか
- 人間の承認が必要な判断はどこか
- 外部ツールやナレッジベース接続が必要か
この段階で業務部門と画面を見ながら調整できるため、後から「想定していた業務フローと違う」と気付くリスクを下げられます。
Hosted AgentとPrompt Agentを使い分ける
Foundry Toolkit for Visual Studio Codeでは、Hosted AgentとPrompt Agentを作成できます。公式ドキュメントでは、Hosted Agentはサポートコードやインフラを伴ってデプロイサービスとして実行されるエージェント、Prompt Agentは指示、モデル設定、任意のツールで定義される軽量なエージェントとして説明されています。(Visual Studio Code)
| 種類 | 向いている用途 | 注意点 |
|---|---|---|
| Prompt Agent | FAQ応答、分類、要約、簡単な業務支援 | 複雑な状態管理や本格的な外部連携には限界が出やすい |
| Hosted Agent | 複数ツール連携、ワークフロー実行、本番運用を見据えた構成 | コード、権限、デプロイ、監視の設計が必要 |
| テンプレートからのHosted Agent | 短時間で構成を確認したい場合 | 生成された構成をそのまま本番化しない |
| Copilot + Foundry skills | 独自シナリオのたたき台を作りたい場合 | 生成内容のレビューとテストが必須 |
判断基準は単純です。業務ロジックが軽く、まず動きを確認したいならPrompt Agent。複数ステップの処理、外部API、監査、デプロイ、再現性が必要ならHosted Agentを検討します。
Agent InspectorでAIエージェントをデバッグ対象にできる
AIエージェント開発で失敗しやすいのは、「何となく動いた」状態で本番に近づけてしまうことです。Agent Inspectorは、VS Code内でエージェントをデバッグ、可視化、改善するための機能です。公式ドキュメントでは、F5での起動、ブレークポイント、変数確認、ステップ実行、ストリーミング応答、ツール呼び出し、ワークフローグラフの可視化が説明されています。(Visual Studio Code)
特に次のようなケースでは、Agent Inspectorを使う価値が高くなります。
- ツール呼び出しの順序が想定と違う
- 複数エージェントの連携で回答が不安定
- MCPサーバー接続後に失敗箇所が追いにくい
- ローカルでは動くがクラウド展開時に挙動が変わる
- 生成AIの判断過程を開発チーム内で説明したい
AIエージェントは通常のアプリよりも挙動の揺れが出やすいため、ログとトレースを見ずに改善するのは危険です。Agent Inspectorは、プロンプト修正だけに頼らず、ソフトウェア開発として原因を追うための重要な機能です。
DevOps engineersとplatform teamsが準備すべきこと
Foundry Toolkit for Visual Studio CodeのGAは、開発者だけの話ではありません。むしろ本番利用を考える場合、DevOps engineersとplatform teamsの準備が成否を分けます。
標準テンプレートを作る
各開発者が自由にモデル、ツール、認証方式、ログ設計を選ぶと、後から運用できないAIエージェントが増えます。Platform teamは、少なくとも次の標準を用意しておくべきです。
| 標準化する項目 | 具体例 |
|---|---|
| モデル選定ルール | 機密データを扱う場合はMicrosoft Foundry上の承認済みモデルのみ使う |
| エージェントテンプレート | 単一エージェント、承認付きツール実行、RAG連携などのひな形 |
| MCP接続ルール | 利用可能なMCPサーバー、承認要否、ログ保存方針 |
| 評価データセット | よくある問い合わせ、NG回答例、期待する分類結果 |
| デプロイ手順 | dev、staging、productionの環境差分と承認フロー |
| 監査・ログ | 誰が、どのエージェントで、どのツールを呼んだか追跡する |
Tool Catalogは、Foundry toolsやローカルMCPサーバーを接続し、エージェントへ追加する場所として利用できます。公式ドキュメントでは、Tool CatalogがFoundry tools、stdio／HTTP／SSEのMCPサーバー、Toolbox、Agent Framework Pythonプロジェクトの生成、Microsoft Foundry側での資格情報・ポリシー・監査性の管理に関係すると説明されています。(Visual Studio Code)
telemetryと企業ポリシーを確認する
Visual Studio Marketplaceの説明では、Microsoft Foundry Toolkit for Visual Studio Codeは利用状況データをMicrosoftへ送信して製品改善に使うこと、またVS Codeのtelemetry.enableTelemetry設定を尊重することが説明されています。([Visual Studio Marketplace][10])
企業環境では、拡張機能の導入前に次を確認してください。
| 確認項目 | 見落とすと起きる問題 |
|---|---|
| VS Code拡張機能の利用許可 | 開発者ごとに導入可否が分かれ、手順が統一できない |
| telemetry設定 | 社内ポリシーとVS Code設定が不整合になる |
| Azureサブスクリプション権限 | モデルデプロイやAgent Service利用時に権限不足で止まる |
| GitHub連携 | GitHub ModelsやCopilot利用時の認証が整理されない |
| シークレット管理 | APIキーや接続文字列がプロンプトやローカル設定に残る |
| ネットワーク制限 | プロキシ、ファイアウォール、地域制限で接続が失敗する |
GAになったからといって、全社展開を急ぐ必要はありません。まずは「承認済みワークスペース」「承認済みモデル」「承認済みMCPツール」を決め、そこから段階的に広げるのが安全です。
まず試すならこの手順：30分PoCの進め方
Foundry Toolkit for Visual Studio Codeを評価するなら、抽象的なデモではなく、実際の業務に近い小さなテーマを選びます。おすすめは「問い合わせ分類」「社内FAQ回答」「ログ要約」「コードレビュー補助」のように、入力と期待結果を用意しやすいテーマです。
| 手順 | 作業 | 成功条件 |
|---|---|---|
| 1 | VS CodeにFoundry Toolkitをインストール | Activity BarにFoundry Toolkitのアイコンが表示される |
| 2 | Microsoft FoundryまたはGitHubモデルに接続 | Model Catalogで候補モデルを確認できる |
| 3 | Playgroundで3〜5個の入力を試す | 回答品質、速度、コスト感の比較材料が得られる |
| 4 | Agent Builderで指示文を作る | タスク、出力形式、禁止事項が明文化される |
| 5 | 必要ならTool CatalogやMCPを接続 | 外部ツールの呼び出し条件と承認要否が分かる |
| 6 | Agent Inspectorで実行を確認 | どのツールが呼ばれたか、どこで失敗したか追跡できる |
| 7 | 評価用データで再テスト | 成功率、NG回答、改善点を記録できる |
| 8 | 本番化判断を行う | Hosted Agent化、Foundry展開、運用監視の要否が決まる |
Visual Studio MarketplaceのGetting startedでも、インストール後にModel Catalogを開き、任意のモデルカードからPlaygroundで試す流れが示されています。([Visual Studio Marketplace][10])
PoCで最も避けたいのは、1回の成功例だけで「使える」と判断することです。最低でも、成功しやすい入力、失敗しやすい入力、あいまいな入力、禁止したい入力を用意してください。AIエージェントの品質は、良い回答だけでなく「失敗したときのふるまい」で決まります。
実務で使いやすい活用シーン
問い合わせ分類エージェント
カスタマーサポートや社内ヘルプデスクでは、問い合わせ文からカテゴリ、優先度、担当チームを分類する用途に向いています。最初は返信文の自動生成まで任せず、分類と要約に限定すると導入しやすくなります。
判断基準は、分類精度だけではありません。誤分類したときに人間が気付けるか、根拠を説明できるか、既存チケットシステムと連携できるかを確認します。
社内ナレッジ検索エージェント
社内規程、開発ガイドライン、API仕様書、障害対応手順などを参照するエージェントも有力です。ただし、ナレッジ検索では「もっともらしい嘘」が問題になります。回答には参照元や根拠を出させ、情報が見つからない場合は「不明」と返す設計が必要です。
DevOps診断アシスタント
ログ、メトリクス、デプロイ履歴、CI/CDの失敗ログを要約するアシスタントは、DevOpsチームとの相性が高い用途です。MCPや外部ツールを使う場合は、読み取り専用から始めるのが安全です。いきなり再起動、削除、デプロイのような破壊的操作を許可しないでください。
コードレビュー補助
GitHub CopilotやAgent Frameworkと組み合わせて、特定の観点に絞ったレビュー補助にも使えます。たとえば「認証情報がハードコードされていないか」「例外処理が不足していないか」「APIレスポンスの型チェックがあるか」のように、観点を明確にすると実用性が高まります。
ただし、生成AIのレビュー結果を人間のレビューの代替にしないことが重要です。AIは見落とすことも、誤検出することもあります。レビューの一次チェックとして使い、最終判断は開発者が行うべきです。
導入時に失敗しやすいポイント
「GAだから全部本番利用できる」と考える
今回GAになったのはFoundry Toolkit for Visual Studio Codeの提供です。接続先のサービス、preview機能、モデル、リージョン、組織ポリシーまで一括で本番保証されるわけではありません。
本番前には、利用するモデル、エージェント種別、ツール接続、デプロイ先、監査ログ、データ保持方針を個別に確認してください。
モデル比較を感覚で決める
「このモデルの回答が自然だった」という印象だけで採用すると、後で品質問題が出ます。比較時は、同じ入力セットを使い、次の観点で評価します。
| 評価観点 | 確認例 |
|---|---|
| 正確性 | 業務ルールに合った回答を返すか |
| 一貫性 | 同じ入力に対して大きく揺れないか |
| 安全性 | 禁止した操作や回答を避けられるか |
| コスト | 想定呼び出し回数で予算内に収まるか |
| レイテンシ | ユーザー体験に耐える応答時間か |
| 運用性 | ログ、監視、エラー追跡が可能か |
ツール実行の承認設計を後回しにする
MCPサーバーや外部APIと接続すると、AIエージェントは情報検索だけでなく、実際の操作に近づきます。便利になる一方で、誤実行のリスクも増えます。
特に、ファイル操作、データ更新、チケット作成、通知送信、デプロイ、コマンド実行は、人間の承認を挟む設計から始めるべきです。Tool CatalogやAgent Builderで接続できるからといって、すべてを自動実行にするのは危険です。
生成されたコードをそのまま信頼する
GitHub Copilotやテンプレートでエージェントコードを生成できる点は大きな利点です。しかし、生成コードは要件を満たす「たたき台」であり、セキュリティ、例外処理、ログ、依存関係、テストまで保証するものではありません。
レビューでは、少なくとも次を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 認証 | 資格情報が環境変数や安全なストアで扱われているか |
| 例外処理 | モデル応答失敗、API失敗、タイムアウトに対応しているか |
| 入出力検証 | ユーザー入力やツール出力を無条件に信頼していないか |
| ログ | 機密情報をログに出していないか |
| テスト | 正常系だけでなく異常系のテストがあるか |
| 依存関係 | ライブラリのバージョンとライセンスを確認しているか |
既存のAI Toolkit利用者が確認すべき移行ポイント
AI Toolkit for VS Codeをすでに使っていたチームは、名称変更だけで済ませず、拡張機能、ドキュメント、教育資料、CI/CD手順を確認してください。
| 確認項目 | 対応 |
|---|---|
| 拡張機能名 | AI Toolkit表記をMicrosoft Foundry Toolkitへ更新 |
| 社内手順書 | 画面名、アイコン名、メニュー名の変更を確認 |
| 既存プロジェクト | 既存機能がそのまま使えるか検証 |
| Marketplace導入手順 | 新規メンバー向けのインストール手順を更新 |
| Foundry sidebar | Foundry Toolkit sidebarへの移行を確認 |
| 教育資料 | Agent Builder、Agent Inspector、Tool Catalogを追加説明 |
公式ドキュメントでは、Foundry ToolkitにFoundry sidebarの機能が統合されており、Foundry sidebarは2026年6月1日にretireすると説明されています。(Visual Studio Code)
この日付は、既存利用者にとって見落としやすいポイントです。社内研修やハンズオン資料で古いサイドバーを前提にしている場合は、早めに更新しておきましょう。
グローバルチームで使う場合の判断基準
Foundry Toolkit for Visual Studio Codeはグローバル読者向けにも扱いやすいテーマですが、国や地域をまたぐ開発では追加の確認が必要です。
データの場所と利用モデルを分けて考える
同じFoundry Toolkitから見えるモデルでも、ローカル実行、GitHub経由、Microsoft Foundry上のデプロイ、外部プロバイダーのモデルでは、データの流れや運用条件が変わります。Model Catalogでは、ホスト元、publisher、対応機能、リモート／ローカル、CPU／GPU／NPU、fine-tuning supportなどのフィルターが使えると説明されています。(Visual Studio Code)
グローバルチームでは、次の分類表を作っておくと安全です。
| 分類 | 例 | 確認すべきこと |
|---|---|---|
| ローカル実行 | ONNX、Ollama、Foundry Local | 端末性能、モデル配布、更新管理 |
| クラウド実行 | Microsoft Foundry上のモデル | リージョン、クォータ、課金、監査 |
| 外部プロバイダー | OpenAI、Anthropic、Googleなど | 契約条件、データ処理、接続方式 |
| GitHub連携 | GitHub Models、Copilot | 組織ポリシー、利用権限、開発者アカウント |
| BYOM | 外部デプロイ済みモデル | 認証、SLA、障害時対応 |
チームごとの自由度を決める
グローバル開発では、すべてを中央集権にするとスピードが落ちます。一方で、各チームが自由にモデルやツールを追加するとガバナンスが崩れます。
現実的には、以下のように権限を分けると運用しやすくなります。
| ロール | 許可する作業 |
|---|---|
| platform team | 承認済みモデル、MCPツール、テンプレート、評価基準の管理 |
| DevOps engineers | デプロイ、監視、ログ、環境変数、シークレット管理 |
| developers | 承認済み範囲内でのAgent Builder、Playground、Agent Inspector利用 |
| business users | PoCレビュー、期待出力の定義、業務ルールの確認 |
この分担により、開発者のスピードと組織の統制を両立しやすくなります。
読み終えたら次にやること
Foundry Toolkit for Visual Studio Codeの2026年4月更新は、AIエージェント開発をVS Code中心に寄せるための重要なアップデートです。特に、Model Catalog、Agent Builder、Agent Inspector、Tool Catalog、Microsoft Foundry Agent Serviceへの導線は、developersだけでなくDevOps engineersやplatform teamsにも影響します。
次にやるべきことは明確です。
まず、VS CodeにFoundry Toolkitを導入し、1つの業務シナリオで小さなPoCを作ります。次に、モデル比較、プロンプト、ツール接続、デバッグ、評価データ、デプロイ条件を記録します。最後に、platform teamが承認済みモデル、MCP接続ルール、テンプレート、評価基準を整備します。
GAを「すぐ本番投入できる合図」と見るのではなく、「標準化して使い始めるタイミング」と捉えるのが、今回の更新を実務で活かす最も安全な進め方です。
[10]: https://marketplace.visualstudio.com/items?itemName=ms-windows-ai-studio.windows-ai-studio “
Foundry Toolkit for VS Code – Visual Studio Marketplace
“
コメント