既存のtool callingコードからCodeActへの移行は大変ですか？

Microsoft Agent Frameworkを使っているなら、context_providers=[HyperlightCodeActProvider()]を追加するだけです。既存のツール定義もそのままcall_tool()経由で呼び出されます。書き換えは最小限で済みます。

CodeActのHyperlight以外のサンドボックスは使えますか？

Docker、Firecracker、E2B、Daytonaなどが使えます。ただしMicrosoft Agent FrameworkのHyperlightCodeActProviderはHyperlight専用です。他のサンドボックスを使う場合は、自分でContextProviderを実装するかサードパーティライブラリを探すことになります。

CodeActはセキュリティ的に大丈夫ですか？

サンドボックス + ネットワークポリシー + ファイルマウント制限の3点を正しく設定すれば、JSON tool callingと同等以上の安全性を確保できます。PoCをDockerで済ませて本番だけHyperlight、という運用は避けたほうが安全です。

CodeActの学習コストはどれくらいですか？

Microsoft Agent Frameworkに慣れている開発者なら、半日で動くサンプルを作れます。HyperlightやVMの知識がゼロから入る場合、サンドボックスの設計に1〜2日かかります。本番運用までの目安は1〜2週間です。

AI活用ツール・副業

【速報】CodeAct入門｜使い方・料金・始め方2026

Q: CodeActはどのLLMで使えますか？

原理的にはPythonコードを生成できる任意のLLMで動きます。Microsoft Agent FrameworkのドキュメントではGPT-5.5/5.6系、Claude Fable 5を推奨しています。コード生成性能が高いほどCodeActの真価が出ます。

Q: CodeActとMCPは競合しますか？

補完関係です。MCPはツール接続のプロトコル、CodeActはエージェントの行動表現方法です。CodeActエージェントが内部からMCPサーバーを呼び出す、という組み合わせが自然な形になります。

2026年6月29日読了時間: 約22分

Microsoft Build 2026 で発表されたCodeActは、AIエージェントの動かし方を根本から塗り替える可能性を秘めた仕組みだ。LLMが JSON で「次に呼ぶツール」を指定する従来方式ではなく、エージェントが Python コードを直接書き、サンドボックスで一気に実行する。Microsoft の自社測定では レイテンシ52.4%減・トークン63.9%減 という派手な数字が出ている。

本稿は、CodeAct の正体・Microsoft Agent Framework での実装（agent-framework-hyperlight）・料金の考え方・つまずきポイントを、実コード付きで一気通貫に解説する。Build 2026 のスライドを眺めただけでは分からない、現場で組み込むときの判断材料に絞った。

この記事で分かること

CodeAct の核となる発想と、ICML 2024 論文「Executable Code Actions」との関係
agent-framework-hyperlight パッケージの導入手順と最小実装コード
従来の tool calling (JSON) との比較表と、どちらを選ぶべきかの判断軸
Hyperlight micro-VM の隔離モデルと「料金がどこに発生するか」
失敗しやすいケースと、本番投入前に潰しておくべき落とし穴

CodeActとは｜LLMがコードを"action"として実行する仕組み

CodeAct の発想は単純だ。「LLMの行動空間 (action space)を、JSON の関数呼び出しではなく、Python コードそのものにする」。これだけ。

例えば「為替レートを取得してドル→円換算してCSVに保存」というタスク。従来の tool calling だと、LLM は get_rate() → multiply() → save_csv() の3回、モデルにラリーを返す必要があった。CodeAct なら、1回の応答で次のコードを書き、それをサンドボックスで実行して結果だけ受け取る。

# LLMが1ターンで生成するコード（イメージ）
rate = call_tool("get_rate", currency="USD")
jpy = 1000 * rate
call_tool("save_csv", path="out.csv", value=jpy)
print(f"saved: {jpy} JPY")

なぜ "コード" が action として優れているのか

理由は3つに集約される。

条件分岐・ループが自然に書ける: JSON tool call では「100社のデータを順に取得して並列処理」のような構造は表現できない。Python なら for ループ1行で済む
中間結果を変数で持ち回せる: 取得した辞書をその場で加工して次の API に渡す処理が、ラリーなしで完結する
エラー処理を try/except で内包できる: 失敗しても LLM に投げ戻さず、エージェント側で自己修復できる

出典: ICML 2024 論文「Executable Code Actions Elicit Better LLM Agents」

CodeAct という言葉自体は2024年2月、UIUC の Xingyao Wang らが arXiv に投稿した論文 (arXiv:2402.01030) が初出。論文では API-Bank ベンチマークで JSON 形式より最大20%高い成功率 を記録した。筆者が論文と Github 実装を読んだ印象では、Python インタプリタを行動空間にすることで「LLM がプログラマとして振る舞える」点が本質的な貢献だった。

なぜ今CodeActなのか｜Build 2026での発表

CodeAct 自体は2024年からある古い概念だ。それが 2026年6月のMicrosoft Build 2026 で再注目された理由は、Microsoft Agent Framework (MAF) の正式サポート機能として組み込まれたから。

Build 2026での発表内容（CodeAct関連）

発表項目	内容	提供開始
agent-framework-hyperlight	CodeAct実装パッケージ（alpha）	2026-06-02
Hyperlight micro-VM	コード実行用サンドボックス	同上
Agent Harness	プロダクション向けエージェント基盤	2026-06-02
Hosted Agents	マネージドエージェント実行環境	2026-06-02

CodeAct を「研究室レベルの面白い手法」から「現場で組み込める正式機能」へ引き上げたのが Microsoft の役割と言える。AutoGen と Semantic Kernel を統合した MAF 1.0 (2026年4月GA) の上に乗ることで、エンタープライズが本番採用しやすい状態が整った。

Microsoftが公表した性能向上の数字

公式ベンチマーク（multi-step workload）

レイテンシ削減: 52.4%減（end-to-end）
トークン使用量: 63.9%減
計測条件: 複数ツールを連鎖呼び出しする代表的シナリオ

※Microsoft Agent Framework devblog で公開された数値。実環境のタスク特性により変動する

数値の裏側はシンプルだ。tool calling の場合、ツール呼び出しのたびに「LLMへの再問い合わせ + プロンプト全文の再送信」が発生する。10回のツール呼び出しなら、入力トークンが10回課金される。CodeAct は1回の応答で完結するため、後段の再問い合わせコストがゼロになる。検証してみると、ツール呼び出し回数が増えるほど CodeAct の優位は広がる傾向にある。

CodeAct vs 従来のtool calling｜何がどう違うのか

並べて比較する。同じタスクを処理した時、両者の振る舞いがどう異なるか。

観点	CodeAct	JSON tool calling
action表現	Pythonコード（任意の構造）	関数名 + JSON引数（フラット）
複数ツールの連鎖	1ターンで完結	ツールごとにLLMにラリー
条件分岐・ループ	if/forで自然に記述	エージェント側ループで疑似実装
エラー回復	try/except で内包	LLMに失敗を再投入して再試行
セキュリティ	サンドボックス必須（Hyperlight等）	JSON検証のみで完結
学習コスト	サンドボックス構築の知識が必要	関数スキーマだけ書けば動く
適したタスク	データ分析・複数API連鎖・自動化	単純な情報取得・予約・登録
本番運用実績	2026年6月〜（MAFで正式サポート）	2023年から多数の本番事例

同じタスクをコードで比較してみる

「Slack に投稿された質問を要約して、回答テンプレを Notion に保存」というタスク。両者の実装を並べる。

JSON tool calling 方式（イメージ）: 3ターンのラリーが必要

# Turn 1: LLMが「slack_get_messages」を呼ぶ
# Turn 2: 結果を受けてLLMが「summarize」を呼ぶ
# Turn 3: 要約結果を受けてLLMが「notion_create_page」を呼ぶ
# → 計3回のLLM呼び出し、毎回プロンプト全文を再送

CodeAct 方式: 1ターンで完結

msgs = call_tool("slack_get_messages", channel="qa", limit=20)
summary = call_tool("summarize", text=str(msgs))
call_tool("notion_create_page", title="今週のQ&A", body=summary)
print("done")

前者が3回課金、後者が1回課金。レイテンシも約3分の1で済む。Microsoft 公表の「52.4%減」はこの単純なケースの効果が積み重なった結果と読める。

筆者の判断軸

ツール呼び出しが 3回以上連鎖するシナリオ なら CodeAct に倒した方がコスト・速度の両面で有利。逆に「天気を聞く」「予約を1件入れる」だけなら JSON tool calling のままで十分。サンドボックス構築のオーバーヘッドが効いてこない。

agent-framework-hyperlightの使い方｜CodeActをセットアップする

Microsoft Agent Framework に CodeAct を組み込む実装手順を見ていく。前提として MAF 1.0 (2026-04 GA) と Python 3.10+ がインストールされている状態を想定する。

STEP 1: パッケージのインストール

alphaパッケージのため --pre フラグが必須。

# pip を使う場合
pip install agent-framework-hyperlight --pre

# uv を使う場合
uv add --prerelease=allow agent-framework-hyperlight

# 既存の MAF と一緒にインストール
pip install agent-framework agent-framework-hyperlight --pre

このパッケージは agent-framework-core に依存するが、OpenAI や Azure Foundry のコネクタは含まない。モデル接続は別途インストールする必要がある。筆者は Foundry Local を組み合わせて検証したが、Azure OpenAI でも動く。

対応プラットフォーム（2026年6月時点）

Linux / Windows のみ。macOS は roadmap 入りだが未対応。M シリーズの Mac で検証したい場合は WSL2 か Docker 経由になる。Apple Silicon ネイティブ対応は未定で、ここは公式の動きを待つしかない。

STEP 2: HyperlightCodeActProvider を Agent に組み込む

最小構成のサンプルコード。HyperlightCodeActProvider は ContextProvider として動き、エージェント実行時に execute_code ツールを自動登録する。

from agent_framework import ChatAgent
from agent_framework.openai import AzureOpenAIChatClient
from agent_framework_hyperlight import HyperlightCodeActProvider

# CodeAct を有効化した Provider を作成
code_act = HyperlightCodeActProvider()

agent = ChatAgent(
    chat_client=AzureOpenAIChatClient(
        endpoint="https://your-endpoint.openai.azure.com",
        deployment_name="gpt-5.6",
    ),
    instructions="あなたはデータ分析エージェントです。",
    context_providers=[code_act],
)

# 実行: LLMが内部で Python コードを書いて Hyperlight で実行する
result = await agent.run("売上CSVを読んで、月別合計と前月比を計算してください")
print(result.text)

注目すべきは context_providers=[code_act] だけで CodeAct が有効になる点。既存の MAF コードベースに後付けで挿せる。これは現場目線でかなり助かる。

STEP 3: ファイルマウントとネットワークポリシーの指定

本番運用では「どのディレクトリを読み書き可能にするか」「ネットワークアクセスを許すか」を絞り込む。

from agent_framework_hyperlight import (
    HyperlightCodeActProvider,
    FileMount,
    NetworkPolicy,
)

code_act = HyperlightCodeActProvider(
    file_mounts=[
        FileMount(host="/data/sales", guest="/sales", read_only=True),
        FileMount(host="/tmp/output", guest="/out", read_only=False),
    ],
    network_policy=NetworkPolicy(
        allow_outbound=False,  # 外部APIを叩かせない
        allowed_hosts=[],
    ),
)

読み取り専用マウントとネットワーク遮断の組み合わせは、社内データ分析エージェントを社外漏洩リスクなしで動かしたい時の鉄板パターン。Microsoft の公式ドキュメントもこの設定を推奨している。

Hyperlight micro-VM｜なぜサンドボックスが必要か

CodeAct の最大の弱点は「LLMが書いたコードを生で実行する」点。悪意あるユーザーがプロンプトインジェクションで rm -rf / を書かせられたら一発で詰む。Microsoft が agent-framework-hyperlight を別パッケージにした最大の理由はここにある。

Hyperlightとは｜起動1ms以下のmicro-VM

Hyperlight は Microsoft が OSS で開発しているハイパーバイザベースの軽量実行環境。VM とコンテナの中間に位置し、1呼び出しごとに新しいmicro-VMを起動・破棄する設計になっている。コールドスタートが1ms以下というベンチマークが公開されている。

他のサンドボックスとの違い

サンドボックス	隔離レベル	起動オーバーヘッド	向く用途
Hyperlight	ハードウェア仮想化	~1ms	CodeAct本番運用
Docker	プロセス分離	~500ms	開発・PoC
Firecracker	VM分離	~125ms	FaaS基盤
subprocess	なし	~10ms	非推奨

CodeAct を Docker で動かしている事例も見るが、500ms のオーバーヘッドが10回連鎖すると5秒の遅延になる。Hyperlight 採用の決め手は、コード実行回数が増えても体感速度が落ちない点だ。

CodeActの料金｜何にいくら払うのか

「CodeAct を使うとトークン費用が下がる」という話と「サンドボックスのコストはどこに乗るのか」という話は別。実運用に踏み込む前に、課金構造を整理しておく。

CodeAct自体は無料｜OSS + MITライセンス

Microsoft Agent Framework および agent-framework-hyperlight は MIT ライセンスの OSS。パッケージ利用そのものに課金はない。これは LangChain や AutoGen と同じスタンスだ。

実際に発生する3つのコスト

コスト項目	課金形態	CodeActでの影響
LLM API利用料	トークン従量（OpenAI/Azure/Anthropic等）	約63%減（公式値）
コード実行環境	サーバー費 or Hosted Agents従量	アイドル時は無課金、実行時のみ加算
Azure Foundry Hosted Agents	2026-04-22から従量課金開始	compute秒 + メモリ秒で算定

セルフホスト vs Azure Foundry の損益分岐

CodeAct を VM/コンテナでセルフホストするか、Azure Foundry Hosted Agents に乗せるかで月額が変わる。筆者がざっくり試算した目安を出す。

セルフホスト（社内VM）

初期コスト: VM準備 + ネットワーク設定
月額: 固定（VM稼働時間に依存）
向く規模: 1日100実行以上
運用負荷: 監視・パッチ適用が自社負担

Azure Foundry Hosted Agents

初期コスト: ほぼゼロ
月額: 実行時間 × compute単価
向く規模: 断続的な利用
運用負荷: Azure が面倒を見る

コスト最適化のコツ

CodeAct の真の節約はトークン費用に効いてくる。GPT-5.6 で1日1万回のエージェント実行なら、tool calling 比で月数十万円規模の差が出る試算もある。一方、コード実行コストは「タスクの重さ次第」。重い分析を回すなら、サンドボックス側のメモリ単価を事前に見積もっておくこと。

CodeActのつまずきポイント｜事前に知っておくべき罠

CodeAct はまだ alpha 段階の機能。本番投入前に知っておきたい既知の罠を挙げる。

罠1: 日本語テキストでコード抽出が失敗するバグ

LLM が出力するレスポンスに、Pythonコードブロックの前に日本語の説明文を含めた場合、一部の CodeAct 実装でパースが失敗するケースが報告されている（langgraph-codeact Issue #32）。Microsoft Agent Framework の Hyperlight プロバイダは比較的耐性があるが、念のため システムプロンプトで「コードのみ出力せよ」と明示しておくと安全。

# 推奨プロンプト
instructions = """
あなたはデータ分析エージェントです。
回答は必ず Python コードブロックのみで返してください。
コードの前後に日本語の説明を含めないでください。
"""

罠2: 競合フレームワークとの依存関係衝突

LangChain 系の CodeAct 実装（langgraph-codeact）は 2026年2月25日にアーカイブ化された。LangGraph v1 系との非互換問題（langgraph-codeact Issue #39）が解決されず、開発が止まったままだ。これから新規採用するなら、Microsoft Agent Framework 側に寄せた方が長期保守の観点で安全と言える。

注意: langgraph-codeact は非推奨

既存プロジェクトで langgraph-codeact を使っている場合、LangGraph v1.0.4 以上にアップデートすると依存関係が壊れる。LangGraph 0.x に固定するか、Microsoft Agent Framework への移行を検討すべき段階に入っている。

罠3: プロンプトインジェクションでサンドボックスを突破される

Hyperlight でファイルマウントを read_only=True にしていても、エージェントに「外部APIにデータを送信せよ」と書かせれば、書き出し権限なしでも情報は漏れる。ネットワークポリシーの設定は必須。「読み取り専用なら安全」ではない。

罠4: macOSで動かない

前述の通り Hyperlight は Linux/Windows のみ。M1/M2 Mac の開発機で試そうとして詰まる人を何人か見た。検証は WSL2 か Docker for Mac 経由、本番は Linux VM で組むのが鉄板。Apple Silicon ネイティブ対応は roadmap 入りしているが時期未定。

罠5: 論文CodeAct と MAF実装は別物

ICML 2024 論文の CodeAct（Xingyao Wang 氏ら）は Llama2/Mistral をファインチューンした専用モデル CodeActAgent を使う前提だった。一方、Microsoft Agent Framework の CodeAct は 汎用LLM + Hyperlight VM の組み合わせ。アーキテクチャが違う。論文の数字（API-Bank で20%向上）を MAF にそのまま当てはめると期待外れになる可能性がある。MAF 側の数字（52.4%/63.9%）は別ベンチマークの値だと理解しておくこと。

CodeActが活きるユースケース｜実例で見る

CodeAct の旨味が出るのは、ツール呼び出しが連鎖するシナリオ。具体的にどんな業務が当てはまるか、4つのユースケースで整理する。

[1] 社内データ分析の自動化

「先月の売上を地域別に集計して、前年比でグラフ化」のような依頼を Slack から受けてエージェントが完結する。CSV読み込み → pandas処理 → matplotlib描画を1ターンで実行。

想定削減: tool calling比で 8〜10ターン → 1ターン

[2] 複数SaaSをまたぐ業務

Salesforce から商談を取得 → 各社の Crunchbase 情報を補完 → スプシに書き出し。3-4個のAPIを連鎖させる典型例で、CodeAct の効果が出やすい。

想定削減: 月数万円のトークン費用

[3] 自己修復が必要な処理

API のレート制限に当たった時、try/except で待機 → リトライを CodeAct 側で完結。tool calling だとエラーごとに LLM に投げ戻すので、ラリーが増える。

想定削減: エラー時のラリー数を 1/3 に

[4] 機械学習パイプライン

データ前処理 → モデル訓練 → 評価レポート生成までを一連で実行。論文 CodeAct が想定していた本来のユースケースで、Pythonエコシステム（scikit-learn等）の利用が前提になる。

想定削減: 開発工数を半減

逆に向かないユースケース

単発のツール呼び出し: 「天気を聞く」「予約を1件入れる」程度なら、JSON tool calling の方が実装も運用もシンプル
セキュリティ要件が極端に厳しい: 金融機関の本番環境などで「LLM生成コードの直接実行」が監査で通らないケース
Pythonエコシステム外のタスク: .NET 側にも CodeAct 実装はあるが、Python ほどライブラリが揃っていない
LLM の出力品質が低いモデルを使う場合: 弱いモデルだとコード生成の精度が不安定で、自己修復ループが永遠に終わらないリスク

CodeActと他フレームワークの位置関係

CodeAct は Microsoft 独占技術ではない。各社のエージェントフレームワークに似た思想の実装がある。並べてみる。

フレームワーク	CodeAct系の実装	状態（2026-06）
Microsoft Agent Framework	agent-framework-hyperlight	alpha、活発に開発中
LangChain (LangGraph)	langgraph-codeact	2026-02-25 アーカイブ化
Claude Agent SDK	Code Execution Tool（β）	Anthropic公式、独自実装
Manus.im	CodeAct アーキテクチャ採用	独自実装、商用提供
OpenAI Assistants API	Code Interpreter Tool	2023年から提供（思想は近い）

エンタープライズ採用で長期保守を見るなら、現時点では Microsoft Agent Framework か Claude Agent SDK の二択。LangGraph 系がアーカイブ化された経緯を踏まえると、OSS系は乱立から淘汰のフェーズに入っている。

よくある質問（FAQ）

Q1: CodeAct はどのLLMで使えますか？

原理的には Python コードを生成できる任意のLLMで動く。Microsoft Agent Framework のドキュメントでは GPT-5.5/5.6 系、Claude Fable 5 を推奨。コード生成性能が高いほど CodeAct の真価が出る。GPT-4o や Claude 3.5 でも動くが、自己修復ループが長くなる傾向あり。

Q2: 既存の tool calling コードから移行は大変ですか？

Microsoft Agent Framework を使っているなら、context_providers=[HyperlightCodeActProvider()] を追加するだけ。既存のツール定義もそのまま call_tool() 経由で呼び出される。書き換えは最小限で済む。

Q3: Hyperlight 以外のサンドボックスは使えますか？

使える。Docker、Firecracker、E2B、Daytona など。ただし Microsoft Agent Framework の HyperlightCodeActProvider はあくまで Hyperlight 専用。他のサンドボックスを使う場合は、自分で ContextProvider を実装するか、サードパーティライブラリを探すことになる。

Q4: セキュリティ的に大丈夫ですか？

サンドボックス + ネットワークポリシー + ファイルマウント制限の3点を正しく設定すれば、JSON tool calling と同等以上の安全性を確保できる。ただし設定が複雑になるため、PoCを Docker で済ませて本番だけ Hyperlight、という運用は避けたほうがいい（PoCで気付けない罠が本番で出る）。

Q5: 学習コストはどれくらいですか？

Microsoft Agent Framework に慣れている開発者なら、半日で動くサンプルを作れる。Hyperlight や VM の知識がゼロから入る場合、サンドボックスの設計に1〜2日かかる印象。本番運用までの目安は1〜2週間。

Q6: CodeAct と MCP は競合しますか？

補完関係。MCP（Model Context Protocol）はツール接続のプロトコル、CodeAct はエージェントの行動表現方法。CodeAct エージェントが内部から MCP サーバーを呼び出す、という組み合わせが自然な形になる。

まとめ｜CodeActは「ツール連鎖が多いエージェント」の次の標準

CodeAct を一言でまとめると、「ツール呼び出しを Python コードで束ねる」だけのシンプルな発想だ。ところがその効果は大きく、Microsoft の自社測定で レイテンシ52%減・トークン63%減。論文ベンチマークでも成功率20%向上。エージェントの「ラリー回数を減らす」という単純な勝ち筋を、サンドボックス技術と組み合わせて実用化したのが Microsoft Build 2026 の意義だ。

今日から始めるアクション

Linux/Windows 環境で pip install agent-framework-hyperlight --pre を実行
本記事 STEP 2 のサンプルコードを動かして、最小構成の挙動を確認
既存の tool calling エージェントで「3回以上ラリーが起きている」処理を1つ選び、CodeAct に書き換える
Hyperlight のファイルマウントとネットワークポリシーを本番要件に合わせて締める

本格的に AI エージェントを業務に組み込みたいなら、CodeAct 単体だけでなく、エージェント基盤全体を理解しておくと判断が早くなる。関連記事も参考にしてほしい。