2026年5月5日の Microsoft developer platform documentation update で確認すべき要点は、.NET Agent Framework に Microsoft.Agents.AI.Hyperlight パッケージが追加され、CodeAct integration (.NET) を扱うための入口が整備されたことです。既存のエージェントが自動的に CodeAct に切り替わる更新ではありません。対応すべきなのは、Microsoft Agent Framework for .NET でツール呼び出しの多いAIエージェントを作っているチーム、またはモデルが生成したコードを Hyperlight サンドボックス上で安全に実行したいチームです。PRは2026年5月5日に main にマージされ、dotnet-1.4.0 のリリース項目にも含まれています。(GitHub)
今回の更新で特に見るべきポイントは、HyperlightCodeActProvider、HyperlightExecuteCodeFunction、call_tool(...)、ファイルマウント、アウトバウンド通信の許可リスト、承認モードです。導入前に「どのツールをサンドボックス内から呼ばせるか」「どのファイルやドメインを許可するか」「人による承認をどこで挟むか」を整理しておくと、検証がスムーズになります。
Microsoft developer platformの今回の更新内容
今回追加された Microsoft.Agents.AI.Hyperlight は、Microsoft Agent Framework の .NET 側で CodeAct を使うための新しいパッケージです。READMEでは、Hyperlight の VM-isolated sandbox を背景にした「first-class CodeAct support」と説明されており、主な入口として HyperlightCodeActProvider と HyperlightExecuteCodeFunction の2つが示されています。(GitHub)
| 追加・変更された要素 | 何をするものか | 実務上の見方 |
|---|---|---|
Microsoft.Agents.AI.Hyperlight | .NET Agent Framework向けの Hyperlight CodeAct integration パッケージ | CodeActを.NETエージェントに組み込むための新しい選択肢 |
HyperlightCodeActProvider | 各エージェント実行時に execute_code ツールとCodeAct向けの指示を注入する AIContextProvider | 通常はこちらを優先して検証する |
HyperlightExecuteCodeFunction | execute_code を単独の AIFunction として手動登録する入口 | 構成が固定されているエージェントや静的な配線で使いやすい |
call_tool(...) | サンドボックス内のコードからホスト側ツールを呼び出す仕組み | モデルに直接ツールを並べるのではなく、コード内から連携させる |
FileMount | ホスト側ファイルをサンドボックス内のパスに公開する設定 | 読ませたいファイルだけを最小限に限定する |
AllowedDomain | サンドボックスからの外向き通信を許可するドメイン設定 | APIアクセスを必要なドメイン・HTTPメソッドに絞る |
CodeActApprovalMode | execute_code 実行時の承認要否を制御する設定 | 機密操作や副作用のある処理では重要 |
このパッケージは net8.0、net9.0、net10.0 をターゲットにしており、プロジェクト側では Hyperlight.HyperlightSandbox.Api を参照します。中央パッケージ管理では Hyperlight.HyperlightSandbox.Api のバージョンとして 0.4.0 が記載されています。導入時は、利用中のAgent Frameworkのバージョン、NuGet上の公開状態、プレリリース利用の可否を合わせて確認してください。(GitHub)
CodeAct integration (.NET)とは何か
CodeActは、AIエージェントに1回ずつツールを選ばせるのではなく、モデルに短いコードを書かせ、そのコードを execute_code ツールで実行する考え方です。Microsoft Learnでは、CodeActにより制御フロー、データ変換、ツールのオーケストレーションを単一の実行ステップにまとめられると説明されています。(Microsoft Learn)
従来のツール呼び出しでは、たとえば「ドキュメント検索」「データ取得」「集計」「要約」という処理が、モデル、ツール、モデル、ツールという複数ターンになりがちです。CodeActでは、モデルが1つの短いプログラムを書き、その中で call_tool(...) を使って必要なツールを呼び出します。Microsoftのブログでは、代表的なツール多用ワークロードでレイテンシを約50%、トークン使用量を60%以上削減できる可能性が示されていますが、これはワークロード依存のため、自社のツールセットでベンチマークするのが現実的です。(Microsoft for Developers)
| 比較項目 | 従来の直接ツール呼び出し | CodeAct + Hyperlight |
|---|---|---|
| モデルとの往復 | ツールごとに複数ターンになりやすい | 1つの execute_code にまとめやすい |
| 得意な処理 | 単発の検索、単発のAPI呼び出し | 複数ツールの連携、集計、条件分岐、整形 |
| 監査のしやすさ | 各ツール呼び出しは見えやすい | 1つのコードブロック内の処理を追う必要がある |
| 承認設計 | ツール単位で承認しやすい | execute_code 全体への承認になりやすい |
| セキュリティ設計 | ホストツールの権限管理が中心 | サンドボックス権限、マウント、通信許可も重要 |
誰が対応すべきか
すぐに確認すべきなのは、Microsoft Agent Framework for .NET を使い、エージェントに複数のツールを連続して呼ばせている開発チームです。たとえば、社内ドキュメント検索、データベース照会、軽い計算、表形式データの加工、レポート生成を1つのエージェントで組み合わせている場合は、CodeActで往復回数を減らせる可能性があります。
一方で、単発のFAQ応答、1回のAPI呼び出しで完結する処理、または各操作を必ず個別承認したい業務では、従来の直接ツール呼び出しを維持したほうが分かりやすい場合があります。Microsoft Learnでも、1〜2回のツール呼び出しで済むタスクや、個別承認が必要な操作では直接ツール呼び出しを使う判断が示されています。(Microsoft Learn)
| 対応優先度 | 対象 | 理由 |
|---|---|---|
| 高 | .NET Agent Frameworkで複数ツールを連鎖させているチーム | レイテンシやトークン使用量の改善余地がある |
| 高 | AIエージェントにコード実行やデータ加工を任せたいチーム | Hyperlightサンドボックスによる隔離実行を検証できる |
| 中 | 既存の直接ツール呼び出しを運用中のチーム | 置き換え候補として比較検証する価値がある |
| 低 | 単発応答中心のチャットボット | CodeActの効果が出にくい |
| 慎重に判断 | 承認・監査が厳しい業務アプリ | execute_code 全体承認になる点を設計で補う必要がある |
既存の.NETエージェントへの影響範囲
この更新は、新しいパッケージとサンプル、テスト、関連プロジェクトを追加するものです。既存コードが自動的に書き換わるわけではないため、通常は「導入したプロジェクトだけに影響する」と考えてよい更新です。ただし、Agent Framework全体のバージョンを上げる場合は、同じリリースに含まれる他の変更も必ず確認してください。dotnet-1.4.0のリリースには、Hyperlight CodeAct以外の.NET関連変更も複数含まれています。(GitHub)
ツールの見え方が変わる
HyperlightCodeActProvider を使うと、モデルに見える主な入口は execute_code になります。 provider-owned tools はサンドボックス内から call_tool(...) で呼ばれますが、モデルに直接並ぶツールとして扱われるわけではありません。実装上も、providerは execute_code ツールとCodeAct用の指示を注入し、設定済みツールはゲストコードから call_tool(...) で使える形にします。(GitHub)
これは便利ですが、運用上は注意が必要です。これまで「どのツールが何回呼ばれたか」をツール呼び出しログだけで追っていた場合、CodeAct導入後は execute_code 内部の実行内容、call_tool(...) の橋渡しログ、生成されたコードの記録を合わせて確認する必要があります。
承認の単位が変わる
CodeActApprovalMode には、execute_code を常に承認必須にする AlwaysRequire と、設定済みツール側の承認要件から判断する NeverRequire があります。コード上では、設定ツールの中に ApprovalRequiredAIFunction が含まれる場合も execute_code の承認要否に反映されます。(GitHub)
実務では、メール送信、チケット更新、注文処理、権限変更のように副作用があるツールを call_tool(...) で呼ばせる場合、AlwaysRequire を検討するのが安全です。サンプルでも、send_email のような機密性のあるツールを ApprovalRequiredAIFunction でラップし、execute_code 全体に承認を要求する例が示されています。(GitHub)
サンドボックスは万能な安全装置ではない
Hyperlightはモデル生成コードを隔離して実行するための重要な仕組みですが、ホスト側ツールそのものを無害化するわけではありません。Microsoftのブログでも、サンドボックス内のコードが call_tool(...) を使うとホスト側ランタイムのツールにブリッジされ、実際のツール処理はアプリケーション側で実行されると説明されています。(Microsoft for Developers)
つまり、危険なのは「サンドボックス外にある広すぎるホストツール」です。たとえば run_sql(query) のような自由度の高いツールをそのまま渡すより、get_order_summary(orderId) や search_docs(topic) のように目的を限定したツールを渡すほうが安全に運用できます。
移行・検証前に確認すべき設定
導入時は、まず小さな検証用エージェントで動作を確認し、その後に本番相当の権限設計へ進めるのが安全です。
| 手順 | 確認すること | 判断基準 |
|---|---|---|
| パッケージ確認 | Microsoft.Agents.AI.Hyperlight の公開状態、バージョン、プレリリース設定 | 本番導入前に固定バージョンで復元できるか |
| 対象フレームワーク確認 | net8.0、net9.0、net10.0 との整合 | 既存プロジェクトのTFMと合うか |
| 入口の選択 | HyperlightCodeActProvider か HyperlightExecuteCodeFunction か | 通常はProvider、固定構成なら手動Function |
| ゲスト環境 | Wasm利用時のゲストモジュールパスなど | サンプルでは HYPERLIGHT_PYTHON_GUEST_PATH を使う |
| ツール定義 | 名前、説明、引数、戻り値の明確さ | モデルがコードから呼びやすい契約になっているか |
| ファイルアクセス | FileMount と HostInputDirectory | 読み書きさせる範囲を最小化できているか |
| ネットワーク | AllowedDomain とHTTPメソッド | 必要なAPIだけに絞れているか |
| 承認 | CodeActApprovalMode と ApprovalRequiredAIFunction | 副作用のある操作に承認が入るか |
| ログ | 生成コード、execute_code、call_tool(...) の記録 | 事故時に何が実行されたか追跡できるか |
HyperlightCodeActProviderOptions では、既定のバックエンド、Wasm向けの CreateForWasm(string)、ヒープサイズ、スタックサイズ、ツール、承認モード、ファイルマウント、許可ドメインなどを設定できます。オプションを省略した場合は既定値が使われるため、検証では必ず「何も許可していない状態」と「必要な権限だけを追加した状態」の差を確認しましょう。(GitHub)
導入時の最小イメージ
NuGetから利用できる状態であれば、プレリリースを許可してパッケージを追加します。実際のバージョン指定は、利用しているAgent Frameworkのリリースと社内のパッケージ管理ルールに合わせてください。
dotnet add package Microsoft.Agents.AI.Hyperlight --prereleaseProviderを使う場合の考え方は、次のようになります。実プロジェクトでは、利用中のAzure OpenAI、OpenAI、Foundryなどのクライアント構成に合わせてエージェント作成部分を調整します。
using Microsoft.Agents.AI.Hyperlight;
using Microsoft.Extensions.AI;
var options = HyperlightCodeActProviderOptions.CreateForWasm(guestPath);
options.Tools =
[
fetchDocsFunction,
queryDataFunction,
new ApprovalRequiredAIFunction(sendEmailFunction)
];
options.FileMounts =
[
new FileMount("./data/orders.csv", "/input/orders.csv")
];
options.AllowedDomains =
[
new AllowedDomain("https://api.example.com", ["GET"])
];
options.ApprovalMode = CodeActApprovalMode.AlwaysRequire;
using var codeAct = new HyperlightCodeActProvider(options);
// エージェント作成時に AIContextProviders = [codeAct] のように登録する公式サンプルでは、HyperlightCodeActProviderOptions.CreateForWasm(guestPath) でゲストパスを指定し、AIContextProviders = [codeAct] としてエージェントに登録する形が示されています。インタープリター用途のサンプルと、provider-owned toolsを call_tool(...) で呼び出すサンプルが用意されています。(GitHub)
失敗しやすいポイント
ツール説明が曖昧なままCodeActに移す
CodeActでは、モデルがツールを「選ぶ」だけでなく、コード内でツール名や引数を使います。そのため、ツール名、説明、引数名、戻り値の意味が曖昧だと、直接ツール呼び出しより失敗が見えにくくなります。
悪い例は search(string q) のように目的も戻り値も分からないツールです。良い例は search_product_docs(string topic) のように用途を限定し、説明に「製品ドキュメントのみを検索し、最大5件のタイトルと要約を返す」と書く形です。
広すぎるファイルマウントを与える
FileMount は便利ですが、ホスト側の広いディレクトリをそのまま渡すと、モデル生成コードが想定外のファイルを参照する余地が広がります。検証ではサンプルデータ専用ディレクトリを作り、必要なCSVやJSONだけをマウントしてください。
許可ドメインを大きくしすぎる
AllowedDomain では、URLまたはドメインとHTTPメソッドを指定できます。たとえば参照だけなら GET のみにし、更新系APIの POST や PATCH は別の承認付きツールに分けるほうが安全です。AllowedDomain のモデルでは、対象と任意のHTTPメソッドリストを持てるため、必要最小限に絞る設計ができます。(GitHub)
本番相当の承認フローを後回しにする
開発中は NeverRequire で動かしたくなりますが、メール送信、データ更新、外部API呼び出しを含む場合は早い段階で承認フローを入れてください。後から承認を足すと、プロンプト、ログ、UI、再実行時の扱いをまとめて直すことになりがちです。
「サンドボックス内で実行されるから安全」と考える
安全性の中心は、サンドボックスそのものだけではありません。渡すツールの権限、ファイルマウント、ネットワーク許可、承認、ログ、エラー時の停止条件をセットで設計する必要があります。HyperlightCodeActProvider のコメントでも、ゲストコードは明示的に設定されたファイルマウントや許可ドメインだけを持つため、必要最小限の権限を設定し、機密リソースに届く場合は AlwaysRequire を検討するよう示されています。(GitHub)
まず実施すべき確認リスト
今回の Microsoft.Agents.AI.Hyperlight 更新に対して、.NET開発チームが最初に行うべきことは次の3つです。
まず、現在のAgent Frameworkのバージョンと、dotnet-1.4.0以降への更新計画を確認します。次に、既存エージェントの中から「3回以上のツール呼び出しを連鎖している処理」を1つ選び、CodeActで置き換えた場合のレイテンシ、トークン使用量、ログの見やすさを比較します。最後に、call_tool(...) 経由で呼ばせるツールを棚卸しし、副作用のあるツールには ApprovalRequiredAIFunction または CodeActApprovalMode.AlwaysRequire を適用する方針を決めます。
CodeAct integration (.NET) は、単なる新機能というより、AIエージェントのツール実行設計を変える選択肢です。小さな検証では「速くなるか」だけを見がちですが、本番運用では「何を許可したか」「誰が承認したか」「何が実行されたか」を追跡できることが重要です。まずは読み取り専用ツールと限定されたファイルマウントから始め、効果とリスクを測ったうえで、更新系ツールや外部API連携へ広げていきましょう。
コメント