Python | The .NET Blog

Agent FrameworkのCodeAct：エージェントのレイテンシを半分にする方法

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元の記事はこちらをご覧ください。

エージェントプロジェクトの開発中、トレースを見て「なぜこんなに時間がかかるんだろう？」と思う瞬間があります。モデルは問題ない。ツールも動いている。でも、1回で計算できる結果を得るのに7回のラウンドトリップが発生している。

これがまさにCodeActが解決する問題です。Agent FrameworkチームはHyperlightパッケージでのアルファサポートをリリースしました。

CodeActとは？

CodeActパターンはエレガントにシンプルです。モデルにツールリストを渡して1つずつ呼び出させる代わりに、単一のexecute_codeツールを与え、計画全体を短いPythonプログラムとして表現させます。エージェントはコードを1回書き、サンドボックスがそれを実行し、1つの統合された結果を得ます。

方式	時間	トークン
従来型	27.81秒	6,890
CodeAct	13.23秒	2,489
改善	52.4%	63.9%

セキュリティ：Hyperlightマイクロ-VM

agent-framework-hyperlightパッケージはHyperlightのマイクロ-VMを使用します。各execute_code呼び出しは独自の新しいマイクロ-VMを取得します。起動はミリ秒単位で計測されます。分離はほぼコストゼロです。

ツールはホストで実行し続けます。モデルが生成したグルーコードはサンドボックスで実行されます。これが正しい分離です。

最小セットアップ

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",
)

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

いつCodeActを使うか（使わないか）

CodeActを使う場合：

タスクが多くの小さなツール呼び出しを連鎖させる（ルックアップ、結合、計算）
レイテンシとトークンコストが重要
モデル生成コードに強力な分離が必要

従来のtool-callingを使う場合：

エージェントがターンごとに1〜2回しかツールを呼び出さない
各呼び出しに個別の承認が必要な副作用がある
ツールの説明が乏しいか曖昧

今すぐ試す

pip install agent-framework-hyperlight --pre

Agent Frameworkブログの完全な投稿でより詳しい解説をご覧ください。

あなたのエージェントはどこで物事を覚えているか？チャット履歴ストレージの実践ガイド

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元の記事はこちらをご覧ください。

AIエージェントを構築する際、ほとんどのエネルギーをモデル、ツール、プロンプトに費やします。会話履歴がどこに保存されるかという問題は実装の詳細に見えますが、実は最も重要なアーキテクチャ上の決定の一つです。

これにより、ユーザーが会話を分岐させたり、回答を元に戻したり、再起動後にセッションを再開したりできるかどうか、そしてデータがインフラから出るかどうかが決まります。Agent FrameworkチームはLデープな分析を公開しました。

2つの基本パターン

サービス管理型: AIサービスが会話状態を保存します。アプリは参照（スレッドID、レスポンスID）を保持し、サービスは各リクエストに関連する履歴を自動的に含めます。

クライアント管理型: アプリが完全な履歴を管理し、各リクエストに関連メッセージを送信します。サービスはステートレスです。すべてを制御できます。

Agent Frameworkによる抽象化

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("私の名前はAliceです。", session);
var second = await agent.RunAsync("私の名前は何ですか？", session);

session = agent.create_session()
first = await agent.run("私の名前はAliceです。", session=session)
second = await agent.run("私の名前は何ですか？", session=session)

セッションが基礎的な違いを処理します。プロバイダーを切り替えてもアプリケーションコードは変わりません。

プロバイダー早見表

プロバイダー	ストレージ	モデル	圧縮
OpenAI/Azure Chat Completions	クライアント	N/A	開発者
Foundry Agent Service	サービス	線形	サービス
Responses API（デフォルト）	サービス	分岐型	サービス
Anthropic Claude, Ollama	クライアント	N/A	開発者

選び方

会話の分岐や「やり直し」が必要？ → サービス管理型のResponses API
データ主権が必要？ → データベースバックドプロバイダーのクライアント管理型
シンプルなチャットボット？ → サービス管理型の線形で十分

完全な記事で意思決定ツリー全体を確認してください。

Python、TypeScript、.NETでazdフックを書く：シェルスクリプトとの決別

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元のバージョンはこちらをクリックしてください。

完全に.NETで書かれたプロジェクトを持ちながら、azdのフックのためにBashスクリプトを書かなければならなかった経験はないだろうか。あの苦痛を知っている人は多いはず。C#でプロジェクト全体を書いているのに、なぜpre-provisioningのステップだけシェル構文に切り替えなければならないのか。

その不満がついに公式に解決された。Azure Developer CLIがフックのマルチ言語サポートを発表し、想像通りの素晴らしい機能となっている。

フックとは

フックはazdのライフサイクルの重要なポイントで実行されるスクリプト — プロビジョニング前、デプロイ後など。azure.yamlで定義され、CLIを変更せずにカスタムロジックを注入できる。

これまではBashとPowerShellのみサポートされていた。今やPython、JavaScript、TypeScript、.NETが使えるようになり、azdが残りを自動で処理する。

検出の仕組み

フックをファイルに向けるだけで、azdが拡張子から言語を推論する：

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

追加設定は不要。拡張子が曖昧な場合はkind: python（または対応する言語）を明示的に指定できる。

言語別の重要な詳細

Python

スクリプトと同じディレクトリ（または親ディレクトリ）にrequirements.txtやpyproject.tomlを置くだけ。azdが自動的に仮想環境を作成し、依存関係をインストールしてスクリプトを実行する。

JavaScriptとTypeScript

同じパターン — スクリプトの近くにpackage.jsonを置くとazdがまずnpm installを実行する。TypeScriptの場合はnpx tsxを使用し、コンパイルステップもtsconfig.jsonも不要。

.NET

2つのモードが利用可能：

プロジェクトモード：スクリプトの隣に.csprojがあれば、azdが自動的にdotnet restoreとdotnet buildを実行。
シングルファイルモード：.NET 10以降では、スタンドアロンの.csファイルをdotnet run script.csで直接実行可能。プロジェクトファイル不要。

エグゼキューター固有の設定

各言語はオプションのconfigブロックをサポート：

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

.NET開発者にとっての重要性

フックはazd基盤のプロジェクトで言語切り替えを強制する最後の場所だった。これで、アプリコード、インフラスクリプト、ライフサイクルフックを含むデプロイパイプライン全体を1つの言語で管理できる。既存の.NETユーティリティをフックで再利用し、共有ライブラリを参照し、シェルスクリプトの保守から解放される。

まとめ

小さな変更のように見えるが、azdの日常ワークフローから多くの摩擦を取り除く変更の一つ。フックのマルチ言語サポートは今すぐ利用可能 — 公式ポストで全ドキュメントを確認してほしい。