Microsoft Agent Framework、個人財務アシスタントの生産環境対応を解説

Microsoft Agent Framework を用いた「クロー（爪型インターフェース）」とエージェント・ハーネスの構築シリーズ第 4 部です。

これまでの 3 部で、パーソナルファイナンスアシスタントは単なるツールの集合体から、真に能力を発揮するエージェントへと進化しました。計画立案やポートフォリオの読み込み、取引前の確認、重要な情報の記憶、オンデマンドでのスキルロード、シェルによるファイル整理、CodeAct による計算処理、そして研究タスクを背景のエージェントへ分散させる機能などを実装しています。もちろん、これは開発者のローカルマシン上で動作するものです。

しかし、「自分の環境では動く」ことと「他者がすぐに使える状態にある」ことは別問題です。

今回の最終章では、以下の 4 つの軸を通じてそのギャップを埋めます。

• 可観測性（Observability）: OpenTelemetry のトレース、トークン使用量、ツール呼び出しを通じて、クローが何を行っているかを可視化します。
• ガバナンス（Governance）: Microsoft Purview を介してプロンプトとレスポンスをスクリーンし、規制の厳しい金融コンテキストにおいてデータアクセスの発見可能性、分類、監査性を確保します。
• デプロイメント（Deployment）: クローを Foundry Hosted Agent としてホストします。
• 評価（Evals）: ローカルの金融チェックとホストされた Foundry による評価で品質を測定し、その結果を用いてプロンプト、ツール、スキルを微調整します。

これを実現するために、私たちは一つの構造的な変更を加えます。これまでの各ステップは単一のプログラムとして実装されていましたが、本番環境のエージェントは通常、複数の方法で実行されます。開発中は対話型で動作し、実際の利用時にはクラウド上でホストされ、CI 内では評価用ハーネス内で動作します。そこで、クローを「共有エージェントファクトリ」と、「それを利用する 3 つの軽量なホスト（コンソール、ホストサービス、評価ランナー）」に分割しました。エージェント本体は一度定義するだけでよく、その周囲を取り巻くホストのみが用途に応じて切り替わります。

一度定義：共有エージェント

クローの独自機能——指示、ファイルアクセス、評価とリスク管理スキル、メモリ、承認プロセス、シェル、CodeAct、そして背景調査エージェント——はすべて一つのファクトリに集約されました。各ホストはこのファクトリを呼び出すだけです。

.NET では、このファクトリが構築されたエージェントと、ホスト側で破棄すべきリソースを返します。

await using ClawAgentBuild build = await ClawAgentFactory.CreateAsync(new ClawAgentFactoryOptions
{
    Log = Console.WriteLine,
});

// build.Agent は Part 3 のクローと同じです。スキル、シェル、CodeAct、背景エージェント、承認機能が含まれています。

Python では非同期ファクトリが非同期コンテキストマネージャーを返すため、シェルや MCP スキルセッションは確実にクリーンに終了します。

agent = await build_claw_agent(credential=AzureCliCredential())
async with agent:
    # … エージェントを実行 …

すべてのホストで単一の定義を使用することで、観測性、ガバナンス、デプロイメント、評価がすべて同一のエージェントに適用されます。微妙に異なる 3 つのコピーが存在するわけではありません。

何が行われているかを確認しましょう：観測性について

ファイルの読み取り、コードの実行、ツールの呼び出しを行うエージェントは、小さな分散システムです。何か問題が発生した際——スキルが誤作動したり、ツールがループに陥ったり、予想以上の 10 倍のコストがかかったりした場合——その状況を把握する必要があります。ハネス（枠組み）はすでにモデル呼び出し、ツール実行、トークン使用量に関する OpenTelemetry のスパン、メトリクス、ログを出力しています。あとはエクスポーターを設定するだけです。

エージェントには単一の OpenTelemetry ソース名が割り当てられており、ホストはこの特定の信号だけを購読できます。

.NET では、ハネスの設定オプションとしてこれを実現します：

AIAgent agent = chatClient.AsHarnessAgent(new HarnessAgentOptions

{

OpenTelemetrySourceName = ClawAgentFactory.OpenTelemetrySourceName,

// … file access, skills, shell, CodeAct, background agents …

});

OTEL_EXPORTER_OTLP_ENDPOINT 環境変数が設定されている場合、コンソールホストは該当ソースを指すトレースとメトリクスプロバイダーを起動し、設定された OTLP コレクターへテレメトリーを送信します。

var otlpEndpoint = Environment.GetEnvironmentVariable("OTEL_EXPORTER_OTLP_ENDPOINT");

var telemetryEnabled = !string.IsNullOrWhiteSpace(otlpEndpoint);

using var tracerProvider = telemetryEnabled

? Sdk.CreateTracerProviderBuilder()

.AddSource(ClawAgentFactory.OpenTelemetrySourceName)

.AddOtlpExporter(options => options.Endpoint = new Uri(otlpEndpoint!))

.Build()

: null;

Python では、計測（インストルメンテーション）がデフォルトで有効になっており、環境変数（OTLP エンドポイント、コンソールエクスポーター、機密データのキャプチャなど）からプロバイダーを接続する単一の呼び出しで設定されます。

agent_framework.observability モジュールから configure_otel_providers と get_tracer をインポートします。

from agent_framework.observability import configure_otel_providers, get_tracer

configure_otel_providers()
with get_tracer().start_as_current_span("Claw Console Session"):
    agent = await build_claw_agent(credential=AzureCliCredential())
    async with agent:
        # … run the agent; spans, metrics, and logs flow to your collector …

このハッチ（Harness）が自動でやってくれることと、手動で設定するものの違いは以下の通りです。ハッチはツール呼び出しごとのスパンやモデルのターンごとのスパン、トークン使用量のメトリクス、構造化ログといったテレメトリを生成します。データを送る先はあなたが選びます。OTLP カスタマー、コンソール、あるいは Azure Monitor や Application Insights です。

ローカル環境ではエクスポート機能を自分で設定する必要がありますが、Foundry 上でホストする場合は何も手動で設定する必要はありません。ホストランタイムが自動的にエクスポートパイプラインを登録し、APPLICATIONINSIGHTS_CONNECTION_STRING を注入してくれるからです（詳細は後述のデプロイメントセクションをご覧ください）。

ガバナンスを維持しよう：Purview

財務アシスタントのようなシステムは機密性の高いデータを扱います。規制が厳しい環境では、組織の方針に基づいてプロンプトや回答をスクリーニングする必要があります。具体的にはクレジットカード番号、機密保有情報、禁止されたコンテンツなどをチェックし、監査証跡を残すことが求められます。Microsoft Purview はまさにその役割を果たします。また、この統合はチャットクライアントの周りを薄いラッパーとして実装されているため、Claw が行う他の機能ともシームレスに連携できます。

導入はオプトイン方式です。PURVIEW_CLIENT_APP_ID 環境変数が設定されていればファクトリが Purview を追加し、そうでなければ従来の動作のまま変更されません。.NET ではチャットクライアントのビルダーステップとして実装されます：

purviewClientAppId が空でない場合、chatClient をビルダー模式で構築し、Purview 設定を適用します。

if (!string.IsNullOrWhiteSpace(purviewClientAppId))
{
    chatClient = chatClient
        .AsBuilder()
        .WithPurview(browserCredential, new PurviewSettings("Claw"))
        .Build();
}

Python では、FoundryChatClient に渡すチャットミドルウェアとして実装されます。

from agent_framework.microsoft import PurviewChatPolicyMiddleware, PurviewSettings

middleware = []
if client_app_id := os.environ.get("PURVIEW_CLIENT_APP_ID"):
    credential = InteractiveBrowserCredential(client_id=client_app_id)
    middleware = [PurviewChatPolicyMiddleware(credential, PurviewSettings(app_name="Claw"))]

client = FoundryChatClient(credential=..., middleware=middleware)

これにより、すべてのプロンプトがモデルに到達する前、すべてのレスポンスがユーザーに届く前にチェックされます。ブロックされたコンテンツはポリシーメッセージに置換され、対話履歴は監査用にログ記録されます。Purview を利用するには、適切な Graph 権限を持つ Microsoft 365 E5 テナントが必要です。完全なセットアップについては、AgentWithPurview や purview_agent のサンプルをご参照ください。

Ship it: Foundry Hosted Agent としてデプロイする

エージェントホストアプリケーションの作成

エージェントは一度定義すれば、その後は再構築ではなく接続作業が中心となります。ホストされたホストは同じ build.Agent を受け取り、Foundry が実行できるように Responses プロトコルを通じて公開します。.NET では、ホスト全体が薄手の ASP.NET アプリとして実装されます。

本番環境では、特定の認証情報（例：ManagedIdentityCredential）を使用することが推奨されます。以下に示すチェーン化された認証情報は、ローカル Docker デバッグ用に開発者用トークンをまず試し、その後 DefaultAzureCredential を使用します。

using Azure.Core;
using Azure.Identity;
using ClawAgent;
using Microsoft.Agents.AI.Foundry.Hosting;

// A specific credential is preferable in production (e.g. ManagedIdentityCredential); the chained
// credential below tries a dev token first (for local Docker debugging), then DefaultAzureCredential.
TokenCredential credential = new ChainedTokenCredential(
    new DevTemporaryTokenCredential(),
    new DefaultAzureCredential());

await using ClawAgentBuild build = await ClawAgentFactory.CreateAsync(new ClawAgentFactoryOptions
{
    ProjectEndpoint = Environment.GetEnvironmentVariable("FOUNDRY_PROJECT_ENDPOINT"),
    DeploymentName = Environment.GetEnvironmentVariable("FOUNDRY_MODEL"),
    Credential = credential,

    // Disable filesystem and shell access on the hosted container (see the risk note below).
    EnableFileAccess = false,
    EnableShell = false,
});

var builder = WebApplication.CreateBuilder(args);

// Registers the Responses API host for the agent AND auto-applies OpenTelemetry.
builder.Services.AddFoundryResponses(build.Agent);

var app = builder.Build();

// The endpoint that live Foundry calls.
app.MapFoundryResponses();

app.Run();

Python では、これはレスポンスホストサーバーとなります。

from agent_framework_foundry_hosting import ResponsesHostServer

agent = await build_claw_agent(

credential=DefaultAzureCredential(),

enable_file_access=False, # off on the hosted container

enable_shell=False, # off on the hosted container

)

await ResponsesHostServer(agent).run_async()

ホスト環境では、コアのテレメトリ収集とエクスポートが自動的に設定されます。言語を問わず、追加のエクスポート設定は不要です。

.NET では AddFoundryResponses がエージェントを OpenTelemetryAgent でラップし、Foundry ホスティングランタイムが OTLP エクスポーターパイプラインを登録します。Python の Agent Framework はネイティブに計測済み（デフォルトで有効）であり、ホスティングランタイムがスパンを収集・エクスポートするため、ホスト環境では configure_otel_providers() を呼び出す必要がありません（ローカルコンソールとは異なります）。エージェントが Foundry で実行されると、APPLICATIONINSIGHTS_CONNECTION_STRING が自動的に注入されるため、設定なしでトレース、メトリクス、ログが Application Insights に転送されます。

これらのトレースにプロンプトやレスポンスの内容を含めたい場合は（デフォルトでは無効）、.NET では OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true を、Python では ENABLE_SENSITIVE_DATA=true を設定してください。

ホスト型エージェントでは、ファイルアクセスとシェル機能を無効化しています。これはコンソール版との意図的な違いです。共有環境でホストする場合、モデルにコンテナのファイルシステムへの任意の読み書き権限を与えたり、シェルコマンドの実行を許可したりすることは、拒否リストを設定していても、データ漏洩や改ざん、永続化といった重大なセキュリティリスクとなります。そのため、ホスト版では EnableFileAccess = false と EnableShell = false を設定しています。ただし、バックグラウンドエージェントは有効のままです。

もしホスト環境でファイルアクセスが必要であれば、コンテナのディスクに依存するのではなく、Azure Blob Storage などを基盤とした外部の AgentFileStore を提供してください。.NET では以下のように記述します。

await using ClawAgentBuild build = await ClawAgentFactory.CreateAsync(new ClawAgentFactoryOptions
{
    // ...
    EnableFileAccess = true,
    FileStore = new MyBlobAgentFileStore(blobContainerClient),
});

Python では file_access_store 引数を使用します。

agent = await build_claw_agent(
    credential=DefaultAzureCredential(),
    enable_file_access=True,
    file_access_store=MyBlobAgentFileStore(blob_container_client),
)
async with agent:
    # … run the agent …

クラウ（Claw）はこのストアの抽象化を通じてファイルの読み書きを行うため、ファイルは一時的なコンテナディスク上ではなく、管理・永続性・共有が可能な Blob Storage 上に保存されます。

コンテナ内での CodeAct の有効化

これは 2 つ目の意図的な分岐です。ローカル環境では、CodeAct は Hyperlight で実行され、ゲストコードが VM ベースのマイクロサンドボックスに隔離されます。一方、ホスト版ビルドでは、LocalCodeAct に基づく CodeActProvider を使用し、生成された Python コードを子プロセスで実行します。この場合、サンドボックスとしてはホストコンテナ自体を利用します。これは、標準的な Hosted-LocalCodeAct サンプルと同じアプローチです（コンテナイメージには python3 がインストールされています）。

.NET では以下のように記述します：

await using ClawAgentBuild build = await ClawAgentFactory.CreateAsync(new ClawAgentFactoryOptions

{

// ...

CodeActProvider = new LocalCodeActProvider(

Environment.GetEnvironmentVariable("LOCAL_CODEACT_PYTHON") ?? "python3"),

});

LocalCodeAct はそれ自体がサンドボックスではありません。モデル生成の Python コードを実行するものであり、必ずホストエージェントコンテナなどの外部でサンドボックス化された環境内で実行してください。もし CodeAct を完全に無効にしたい場合は、EnableCodeAct = false と設定します。

ビルドとデプロイ

両方のホストには agent.manifest.yaml と agent.yaml が同梱されていますが、2 つのファイルは異なる役割を担っています。manifest は azd ai agent init コマンドに渡されるテンプレートで、エージェントの名前、メタデータ、プロトコル、および設定可能なパラメータを含みます。一方、agent 定義は Foundry が実行する内容を記述したもので、Responses プロトコル、CPU とメモリの割り当て、コンテナが必要とする環境変数などを指定します。

実際の .NET マニフェスト、.NET エージェント定義、Python のマニフェスト、および Python のエージェント定義については、それぞれのドキュメントをご参照ください。

デプロイパスは言語によって異なります。Python では Foundry のデフォルトコード（ZIP）デプロイが使用されます。azd は自己完結型のサンプルフォルダをアップロードし、requirements.txt をインストールして hosted.py を起動します。プロジェクトの初期化時には、このエントリーポイントを指定してください。

cd python/samples/02-agents/harness/build_your_own_claw/claw_step04_production_ready

azd ai agent init -m agent.manifest.yaml --entry-point hosted.py

azd up # または後続のプッシュでは azd deploy

.NET サンプルは、Agent Framework リポジトリソース（ProjectReference）に対してビルドされ、リポジトリレベルの中央パッケージ管理を使用しているため、コンテナイメージとしてデプロイされます。ZIP デプロイではプロジェクトフォルダのみがアップロードされるため、サーバーサイドでの復元ではフォルダ外の参照や Directory.Packages.props を解決できません。まずローカルで公開し、その後 azd にビルドとプッシュを行わせてください。

ClawAgent.Hosted から:

dotnet publish -c Release -f net10.0 -r linux-x64 --self-contained false -o out

初回のみ:

azd ai agent init -m agent.manifest.yaml --deploy-mode container

azd up # または後続のプッシュで再公開後に azd deploy

.NET の Dockerfile は、事前に公開された out/ ディレクトリを、Python 3 が有効な aspnet:10.0 イメージにコピーします。完全な前提条件とアイデンティティ割り当てについては、.NET デプロイガイドまたは Python デプロイガイドに従ってください。

その良さを証明する：評価（evals）

デプロイ前後に、この「クロー」が実際に機能しているか評価したいものです。また、変更後に回帰現象が発生していないことを確認したり、さまざまなプロンプトをテストして最適バージョンを見つけたい場合もあるでしょう。

評価ホストはエージェントを構築し、少人数の金融関連クエリに対して実行します。この際、2 段階のチェックが行われます。

ローカルチェックは単純な関数で構成されており、高速かつ無料で CI（継続的インテグレーション）環境でも実行可能です。.NET では以下のように記述できます。

LocalEvaluator localEvaluator = new(

FunctionEvaluator.Create("numeric_valuation", item =>

!item.Query.Contains("Value MSFT", StringComparison.OrdinalIgnoreCase)

|| Regex.IsMatch(item.Response, @"\d")));

AgentEvaluationResults results = await build.Agent.EvaluateAsync(queries, localEvaluator);

Console.WriteLine($"Passed: {results.Passed}/{results.Total}");

Python では、@evaluator デコレータを用いて同様の仕組みを実装できます。

@evaluator(name="numeric_valuation_answer")

def numeric_valuation_answer(query: str, response: str) -> bool:

return "msft" not in query.lower() or any(c.isdigit() for c in response)

local = LocalEvaluator(numeric_valuation_answer)

results = await evaluate_agent(agent=agent, queries=queries, evaluators=local)

print(f"{results[0].passed}/{results[0].total}")

ホスト型 Foundry 評価では、モデルによる品質スコア（関連性や一貫性など）が算出され、共有可能なレポートが生成されます。ただし、FOUNDRY_PROJECT_ENDPOINT が設定されている場合に限り利用可能で、ローカルチェックは常に優先して実行されます。

// .NET

FoundryEvals foundryEvals = new(projectClient, deploymentName, FoundryEvals.Relevance, FoundryEvals.Coherence);

AgentEvaluationResults quality = await build.Agent.EvaluateAsync(queries, foundryEvals);

Python

from agent_framework.foundry import FoundryChatClient, FoundryEvals

foundry = FoundryEvals(

client=FoundryChatClient(credential=credential),

evaluators=[FoundryEvals.RELEVANCE, FoundryEvals.COHERENCE],

)

quality = await evaluate_agent(agent=agent, queries=queries, evaluators=foundry)

これらの評価をすべての変更に対して実行すれば、スコアから新しい指示やツール、スキルが性能向上に寄与したのか、逆に低下させたのかがわかります。これが、デプロイされたエージェントの誠実さを保つためのチューニングループです。

Run it

.NET ではコンソール、評価スクリプト、またはホストサービスを実行します:

cd dotnet

dotnet run --project samples/02-agents/Harness/BuildYourOwnClaw/Claw_Step04_ProductionReady/ClawAgent.Console

dotnet run --project samples/02-agents/Harness/BuildYourOwnClaw/Claw_Step04_ProductionReady/ClawAgent.Evals

dotnet run --project samples/02-agents/Harness/BuildYourOwnClaw/Claw_Step04_ProductionReady/ClawAgent.Hosted

Python では以下を実行します:

uv run python/samples/02-agents/harness/build_your_own_claw/claw_step04_production_ready/console.py

uv run python/samples/02-agents/harness/build_your_own_claw/claw_step04_production_ready/evals.py

uv run python/samples/02-agents/harness/build_your_own_claw/claw_step04_production_ready/hosted.py

コンソールはパート 3 のクローと全く同じように動作しますが、テレメトリデータが収集先に流れるようになっています。

ローカルでトレースを確認するには、OTEL_EXPORTER_OTLP_ENDPOINT をコレクターを指すように設定するか（Python の場合は ENABLE_CONSOLE_EXPORTERS=true を設定）、ガバナンス機能を有効にするには PURVIEW_CLIENT_APP_ID を設定します。

ホスト環境では、テレメトリを Application Insights に送信するために APPLICATIONINSIGHTS_CONNECTION_STRING を設定してください。

ホスト環境での利用

デプロイされたエージェントは、Foundry Agent プレイグラウンドからも呼び出すことができます。

実行可能なサンプル

• .NET: dotnet/samples/02-agents/Harness/BuildYourOwnClaw/Claw_Step04_ProductionReady
• Python: python/samples/02-agents/harness/build_your_own_claw/claw_step04_production_ready

これらのビルディングブロックを、自分自身でエージェントを作成する際に活用できます。

ご存知の通り、各機能は単独でも利用可能です。これらはハッチスに閉じ込められているわけではありません：

• Feature：.NET / Python
• Observability：agent.AsBuilder().UseOpenTelemetry(sourceName).Build() で任意の AIAgent を装飾できます。チャットバックドのエージェントは、clientFactory 内で IChatClient も計測可能です。完全なサンプルと UseOpenTelemetry ソースをご覧ください。 / from agent_framework.observability import configure_otel_providers でエクスポートを設定します。観測機能のソースコードをご覧ください。
• Governance：WithPurview は ChatClientBuilder の拡張です：chatClient.AsBuilder().WithPurview(credential, settings).Build()。WithPurview ソースとサンプルをご覧ください。 / チャットクライアントに PurviewChatPolicyMiddleware を追加します。ミドルウェアのソースとサンプルをご覧ください。

ホスティング

builder.Services.AddFoundryResponses(agent) を呼び出して AIAgent を登録し、app.MapFoundryResponses() でエンドポイントをマップします。これらはどちらもホスティングソースに含まれる ASP.NET 拡張機能です。

ResponsesHostServer(agent) でエージェントをラップし、run_async() で実行してください。詳細はレスポンスホストのソースコードをご参照ください。

評価（Evals）

ローカルでのチェックには LocalEvaluator または FunctionEvaluator を、ホスト環境での品質評価には FoundryEvals を使用します。

コア評価モジュールから LocalEvaluator、evaluate_agent、@evaluator を利用するか、あるいは FoundryEvals を選択してください。

これらを結びつける共通のパターンは、共有エージェントファクトリです。エージェントを一度定義し、必要なホストでラップするだけです。観測性（Observability）はエージェントとその背後にあるチャットクライアントにデコレーターとして付与され、ガバナンスはチャットクライアントのミドルウェアとして実装されます。そしてホスティングと評価は、完成したエージェントを対象に行われます。

今後の展望

これで本シリーズは完結です。4 部構成で、単一のツールから始まり、Microsoft Agent Framework のビルディングブロックをすべて活用して構築された、ガバナンス機能付き・観測可能・デプロイ済み・継続評価可能な金融アシスタント「Claw」に至るまでの過程を紹介しました。各コンポーネントは、そのままあなたのエージェントでも利用可能です。

このハッチ（Harness）により、計画立案、ファイルアクセス、承認フロー、メモリ管理、スキル、シェル、CodeAct、バックグラウンドエージェントといった機能が提供されました。今回のパートでは、エージェントの内部構造を変更することなく、これを本番環境で運用可能な状態へと仕上げました。

Claw をベースに、サポート、オペレーション、リサーチなど、ご自身のドメインに合わせて機能を差し替えてください。そうすれば、実際にリリースできるエージェント開発へのスタートダッシュが切れます。

image シリーズ構成

Microsoft Agent Framework を活用した「独自のクローとエージェント・ハーネスの構築」シリーズの一部です。

• 概要：独自のクローとエージェント・ハーネスを構築する
• パート 1：エージェント・ハーネスとクローの紹介
• パート 2：データの安全な扱い方
• パート 3：機能のスケーリング
• パート 4：本番環境向けにクローを整備する（現在地）

「Agent Harness: Making your claw production-ready」という記事は、Microsoft Agent Framework の公式ブログで最初に公開されました。