エージェントにツールを使わせるとき、いまの標準は「モデルがJSONでツール呼び出しを1つ出す → 実行する → 結果を渡してまたモデルに考えさせる」というループだ。1ステップごとにモデルの推論が1往復走る。天気を2都市ぶん引いて比べるだけでも、get_weatherを2回、それぞれが別ターン。ユーザーの注文を全件なめて合計を出すような処理になると、このターン数がそのまま遅延とトークン消費に積み上がっていく。

Microsoftが6月のBuild 2026で正式に出した Microsoft Agent Framework の新機能 CodeAct は、このループそのものを畳んでしまう。モデルにツールを1個ずつ選ばせるのをやめて、「やりたいこと全部を1本のPythonプログラムとして書け」とやらせる。書かれたコードを隔離環境で一度だけ走らせ、結果をまとめて返す。

ベンチマークの数字がわかりやすい。注文データをルックアップしながら合計を計算する、典型的な「小さな呼び出しの連鎖」型ワークロードでの比較がこれだ。

	従来のツール呼び出し	CodeAct	差
所要時間	27.81秒	13.23秒	52.4%短縮
トークン	6,890	2,489	63.9%削減

出典は公式ブログの計測値。
https://devblogs.microsoft.com/agent-framework/codeact-with-hyperlight/

何が「コードを書かせる」と速いのか

ポイントは、モデルが賢くなったわけでも、ツールが速くなったわけでもないこと。同じモデル・同じツール・同じプロンプトのまま、オーケストレーション(ツールをどの順でどう繋ぐか)の主導権をモデルの逐次判断からコードの制御構文に移しただけだ。ループ・分岐・フィルタ・集計をモデルに何ターンも考えさせる代わりに、for文や条件分岐としてコードに書いてしまう。中間結果をモデルのコンテキストに毎回戻さないので、トークンが伸びない。公式ドキュメントもはっきり「モデルの品質ではなくオーケストレーションのオーバーヘッドがボトルネックになっている」と書いている。

Modern AI agents often are not bottlenecked by model quality, but by orchestration overhead.
(CodeAct | Microsoft Learn)

「モデルにコードを書かせて実行する」という発想自体は目新しいものではない。研究でも他フレームワークでも繰り返し試されてきた。Microsoftの実装が現実的なのは、後述するサンドボックスの作りと、既存のツール定義をそのまま流用できる設計のほうにある。

モデルが書くのは「ツールを呼ぶコード」

CodeActが有効なエージェントには、ツールが直接見えない。代わりに execute_code というツールが1つだけ生える。モデルはその中で call_tool("ツール名", ...) を呼ぶコードを書く。Pythonでの最小構成はこうだ(公式ドキュメントより)。

pip install agent-framework-hyperlight --pre

from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from agent_framework.hyperlight import HyperlightCodeActProvider
from azure.identity import AzureCliCredential

# ツールはプロバイダ側に登録する。モデルからは直接見えず、
# サンドボックス内の call_tool(...) 経由でのみ呼べる
codeact = HyperlightCodeActProvider(
    tools=[compute, fetch_data],
    approval_mode="never_require",
)

agent = Agent(
    client=FoundryChatClient(...),
    name="HyperlightCodeActProviderAgent",
    instructions="You are a helpful assistant.",
    context_providers=[codeact],
)

result = await agent.run(
    "全ユーザーを取得し、admin を抽出し、7*(3*2) を計算して、"
    "それぞれを出力して。execute_code と call_tool(...) を使うこと。"
)
print(result.text)

HyperlightCodeActProvider に渡したツールは、モデルの直接のツール一覧からは消える。モデルはあくまで「コードの中から call_tool で呼ぶ部品」として扱う。逐次承認が要る副作用つきの操作(メール送信など)は、逆にプロバイダに入れずエージェント直付けのツールとして残し、approval_mode="always_require" を付けておく、という使い分けが推奨されている。CodeActの承認は execute_code の呼び出し1回まるごとにかかり、中の個別の call_tool 単位では止められないからだ。

.NET側も用意されている。パッケージは Microsoft.Agents.AI.Hyperlight で、HyperlightCodeActProvider と、手動配線用の HyperlightExecuteCodeFunction を提供する。ただし現時点では依存先の Hyperlight.HyperlightSandbox.Api がまだnuget.orgに公開されておらず、そのままだとリストアに失敗するとドキュメントが明記している。試すならPython版が先だ。

生成コードはマイクロVMの中で走る

ここが個人的にいちばん面白い設計判断だった。モデルが書いたコードは信用できない。素朴にホストで exec したら事故る。CodeActはこれを Hyperlight というMicrosoft製のマイクロVMの中で実行する。

Hyperlightは「アプリに埋め込めるVMM(仮想マシンマネージャ)」で、Rust製・Apache 2.0、CNCFのSandboxプロジェクトでもある。普通のVMが起動に120ミリ秒以上かかるのに対し、Hyperlightのマイクロ VM は1〜2ミリ秒で立ち上がる(Microsoft Open Source Blog)。OSを丸ごと積まず、ハードウェア仮想化(LinuxではKVM、WindowsではWindows Hypervisor Platform)で隔離する。だからツール呼び出しのたびに使い捨てのVMを立てても遅延として無視できる、という前提が成り立っている。コンテナのプロセス分離より一段強い、ハードウェア境界での隔離だと思えばいい。

注意したいのは、隔離されるのはモデルが書いたオーケステレーションのコードだけで、call_tool の先の実際のツール関数はホストのプロセスでフル権限のまま動く点だ。

call_tool(...) is a bridge back to host callbacks; it is not an in-sandbox reimplementation of the tool.

つまりサンドボックスはモデルの暴走コードを閉じ込めるためのもので、ツール自体のI/Oを縛るものではない。機密リソースに触る処理は、サンドボックスの権限を広げるのではなく「狭くレビュー済みのホストツール」として切り出せ、という設計思想になっている。サンドボックス側に渡せる権限は、読み取り専用の /input、書き込み可能な /output、file_mounts でのパスマウント、allowed_domains での外向き通信のallowlistに絞られている。出力は最後の式の値ではなく明示的に print(...) した内容が返る、生成物は /output/<ファイル名> に書く、という細かな作法もある。

使う前に知っておくべき制約

アルファ版だけあって穴はある。現状の制約を正直に並べると、サンドボックスのゲストはPythonのみ(.NETではJavaScriptバックエンドも選べる)、対応プラットフォームはLinux(KVM)とWindows(WHP)だけでmacOSは未対応、そして execute_code の呼び出しをまたいでインメモリの変数は持ち越せない。コール間でデータを残したければマウントしたファイルか /output を使う必要がある。

もうひとつ実務的に効くのが、ツールの「契約」の重みが変わることだ。従来はモデルがツール一覧から1つ選ぶだけだったが、CodeActではモデルがそのツールのシグネチャに向けてコードを書く。だから引数名・型注釈・戻り値の形が今まで以上に効く。雑な型注釈のツールを渡すと、モデルが正しいコードを書けず、かえって失敗が増える。

そして当然ながら、効くのは「オーケストレーションのオーバーヘッドが支配的なとき」だけだ。ツール呼び出しが1〜2回で終わる軽いタスクなら、マイクロVMを立てて承認境界を1つにまとめる抽象化のほうがオーバーヘッドになる。公式も「小さなタスクには向かない」とはっきり書いている。万能スイッチではなく、ツールヘビーなワークフロー向けの最適化だと割り切るのが正しい。

どこから試すか

裏取りした一次ソースは次の4つ。Build 2026のまとめ(Agent Framework Blog)、CodeActの設計と計測(codeact-with-hyperlight)、パターン解説と連携ガイドの公式ドキュメント2本(CodeAct / Hyperlight CodeAct)だ。ブログとドキュメントでimport文の表記が一部揺れている(agent_framework_hyperlight 直下か agent_framework.hyperlight か)ので、コードはより新しい公式ドキュメント側の from agent_framework.hyperlight import ... に合わせた。手元で動かすときはインストール直後の実際のモジュール構成を確認したほうがいい。

LLMエージェントの最適化というと、つい「もっと賢いモデル」「もっと速い推論」に目が行く。CodeActが示しているのは、ボトルネックがしばしばモデルの外側、つまりツールをどう繋ぐかの制御フローにあって、そこをコードに落とすだけで半分の時間と4割弱のトークンで済む、という地味だが効く事実だ。Linux/Windowsでツールを多数呼ぶ既存のエージェントを持っているなら、ベンチの再現は pip install 一発から始められる。