エージェントにツールを使わせるとき、いまの標準は「モデルが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 一発から始められる。