ツールを使うAIエージェントの中身は、意外なほど単純なループでできている。モデルが「この関数をこの引数で呼べ」というJSONを吐き、ハーネス(モデルの周りを固める実行基盤)がそれを実行し、結果をまた文脈に戻す。次の一手をモデルに考えさせて、また呼ぶ。これを延々と繰り返す。
問題は、多段の作業ほどこの往復が効いてくることだ。5都市の天気を引いて、雨の街だけ拾って、平均気温を出す。人間ならコードで一気に書く処理を、従来のツール呼び出しは1ステップ1往復に分解する。往復のたびにツールのスキーマも中間結果も文脈へ積み直されるので、トークンは膨らみ、レイテンシも伸びる。
MicrosoftがAgent Frameworkに載せてきたCodeActは、この往復そのものを畳む発想だ。ステップごとにJSONを返させる代わりに、モデルに短いPythonプログラムを1本書かせる。ループも条件分岐も変数もそのプログラムの中でやらせ、ツールはcall_tool(...)経由で呼ぶ。それをサンドボックスで一度だけ走らせ、まとまった結果を返す。BUILD 2026で公表された同社の代表的なマルチステップ・ワークロードでの数字はこうだ。
| 従来のツール呼び出し | CodeAct | |
|---|---|---|
| 実行時間 | 27.81秒 | 13.23秒(52.4%短縮) |
| 消費トークン | 6,890 | 2,489(63.9%削減) |
出典はMicrosoft自身の計測なので、額面通りの「2倍速」を鵜呑みにはできない。ただ往復を減らせばトークンと時間が両方効く、という向きは筋が通っている。
なぜ「使い捨てVM」が要るのか
CodeActというアイデア自体は新しくない。学術界で提案され、いくつかのエージェントが採用してきた。厄介なのはいつも同じ一点、モデルが書いた任意のコードを実行するという事実だ。これはハーネスにとって最大の攻撃面になる。プロンプトインジェクションで外部から悪意ある指示が混ざれば、モデルはファイルを消すコードも認証情報を送るコードも平気で書きうる。
素直な対策は「呼び出しごとに新しいサンドボックスを用意し、終わったら捨てる」ことだ。だが実現手段が悩ましい。コンテナはカーネルを共有するので隔離が薄い。まっとうなVMは硬いが、起動に時間がかかる。1回のツール実行のたびにVMを立てて捨てるなど、コスト的に非現実的とされてきた。
ここで効いてくるのがHyperlightだ。MicrosoftがRustで書いたmicro-VMマネージャで、2025年3月にオープンソース化され、同年2月にCNCF Sandboxへ迎えられている。普通のVMと違い、ゲストにはメモリの一区画とCPUしか見せない。カーネルもOSも仮想デバイスも積まない。
all it exposes to its VM guests is a linear slice of memory and a CPU. No virtual devices. No operating system.
OSを起動しないので、立ち上がりが桁違いに速い。同社の説明では従来型VMの起動が約125msなのに対し、Hyperlightは1〜2ms、1ms未満を目指して開発が続いている。ハードウェアの隔離(ハイパーバイザ)を保ったまま、コンテナ並みの軽さで使い捨てられる。喩えるなら、計算のたびに新品のパソコンを渡し、終わったら丸ごと裁断するようなものだ。
組み合わさると何が変わるか
agent-framework-hyperlight(現在アルファ)は、この2つを結線する。CodeActが吐くプログラムを、呼び出しごとに真新しいHyperlight micro-VMの中で走らせる。ブログの表現を借りれば「ツール呼び出し1回という粒度で、強い隔離が実質タダで手に入る」。
使い方は、ツールを定義してプロバイダに渡すだけだ。
from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider
@tool
def get_weather(city: str) -> dict[str, float | str]:
"""Return the current weather for a city."""
return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}
codeact = HyperlightCodeActProvider(
tools=[get_weather],
approval_mode="never_require",
)
@toolで普通のPython関数を宣言し、HyperlightCodeActProviderに一覧で渡す。モデルがget_weatherを必要な回数だけ呼ぶプログラムを書き、それが隔離VMの中で実行される。approval_modeは危険な操作に人間の承認を挟むかどうかのつまみで、ここでは「常に不要」にしている。実運用では、シェル実行やファイル書き込みを含む場面ほど、ここを絞る判断が要る。
私が面白いと思うのは、安全モデルの重心が移っている点だ。従来は「モデルに呼ばせるツールをあらかじめ制限する」方向で守っていた。CodeActは逆に、任意のオーケストレーションコードを書かせることを許し、そのかわり1回の実行に爆発半径を封じ込める。効率化のパターン(CodeAct)に、隔離のプリミティブ(Hyperlight)を当てて初めて本番投入できる形にした、という組み立てだ。同じ「コードでツールを呼ばせる」路線でもOpenAIのProgrammatic Tool Callingは効率を主眼に置くのに対し、Microsoftのこの一手は隔離を先に立てているところに色が出ている。
注意点も正直に書いておく。Hyperlight WasmでPythonを動かすには言語ランタイムをwasmイメージに同梱する必要があり、wasm32-wasip2をターゲットにする都合上、素のCPythonがそのまま全部動くわけではない。パッケージがアルファである以上、APIも数字も動く前提で読むべきだ。それでも、「エージェントに書かせたコードをどう安全に実行するか」という、エージェント時代の地味だが避けて通れない課題に、既存のセキュリティ基盤を持ち込んで正面から答えている点は評価していい。往復を畳んで速く安くするより、その速さを本番で使える安全性とセットで出してきたことのほうが、実務では重い。
一次ソースは以下。