Microsoft Agent Framework Harness とは — LLMを自律エージェントに変える実行基盤

Microsoft は 2026 年 7 月 22 日、Microsoft Agent Framework の新機能である Agent Harness の一般提供を発表しました。ハーネスは、単体ではテキストを返すだけの言語モデルを、ツールを使い・計画を立て・記憶を保ちながら多段のタスクをこなす自律エージェントへと引き上げる実行基盤です。

「エージェントを作る」と聞くと、モデルにプロンプトを渡す部分を思い浮かべがちですが、実際に手間がかかるのはその周辺、いわゆる「配管（plumbing）」の部分です。ツール呼び出しをどう繰り返すか、途中経過をどう覚えておくか、長くなった文脈をどう畳むか、危険な操作をどう止めるか——こうした共通処理を、ハーネスは標準部品としてまとめて提供します。本記事では、公式発表と関連記事の内容をもとに、Agent Harness が何を解決し、内部でどう動き、.NET / Python でどう使うのかを、図を交えて整理します。

Agent Harness とは何か

LLM が担うのは、プロンプトに対して 1 回の応答を返すところまでです。しかし実運用のエージェントには、ツール呼び出しのループ、途中結果の記憶、長い文脈の圧縮、機微な操作の承認、そして監視といった「モデルの周りの配管」が欠かせません。これらを案件ごとに自前で組み上げるのは負担が大きく、実装のばらつきや品質の差も生まれます。

Agent Harness は、この配管を標準化した実行ループです。既存のチャットクライアントをラップし、指示とツールを与えるだけで、複数ステップにわたるエージェント処理を 1 回の呼び出しにまとめて実行します。開発者はエージェントに「何をさせたいか」に集中でき、基盤の作り込みから解放されます。

なぜ「配管」が必要なのか

従来、エージェント基盤は開発者が一から組み上げるのが一般的でした。ツール実行の制御、履歴の保存、文脈があふれないための要約、承認フロー、テレメトリなどを個別に実装すると、コードは肥大化し、プロジェクトごとに品質もまちまちになります。「まず動くもの」を作った後、堅牢さや復旧性を後付けしていく過程で、思わぬバグや暴走を招くことも少なくありません。

ハーネスの狙いは、こうした一連のパイプラインを 1 つの呼び出しへ集約することにあります。パイプライン全体を単一の呼び出しにまとめる、という設計思想により、エージェントの中核ロジックに手を入れずに、堅牢な実行基盤を初めから利用できます。下のデモは、ハーネス上で動くリサーチアシスタントが、自らツールを選びながら調査を進めていく様子です。

実行ループの中身

ハーネスの中核は、1 回の呼び出しの内側で回る実行ループです。指示を受け取ったモデルが「次に何をするか」を考え、必要ならツールを呼び、その結果を文脈に取り込んで、また考える——このサイクルを、タスクが完了するまで自動で繰り返します。開発者から見れば RunAsync(...) を一度呼ぶだけですが、その裏では何十回ものモデル呼び出しとツール実行が行われることもあります。

このループを安全かつ堅牢に回すために、ハーネスはいくつかの仕掛けを持っています。反復回数には上限が設けられ、ツールを延々と呼び続ける暴走を防ぎます。チャット履歴はモデル呼び出しごとに永続化されるため、途中でプロセスがクラッシュしても、状態を復元して続きから再開できます。そして長時間の実行で文脈ウィンドウがあふれそうになると、古いやり取りを自動で圧縮・要約し、必要な情報を保ちながらトークンを節約します。

標準で備える主な機能

Agent Harness は、実用的なエージェントに必要な機能を既定で備えています。大きく「実行と制御」「記憶と文脈」「拡張」「運用」の 4 系統に整理すると、その守備範囲が見えてきます。

• 関数呼び出し — 自動のツール呼び出しループと、反復回数の上限設定
• 履歴の永続化 — モデル呼び出しごとにチャット履歴を保存し、クラッシュからの復旧に対応
• コンテキスト最適化 — 長時間のツール実行でも文脈ウィンドウの溢れを防ぐ
• タスクプランニング — 永続的なタスクリストと、プラン/実行モードの追跡
• ファイルメモリ — セッションのメモや成果物を永続化
• スキル — パッケージ化した専門知識を、必要なときに段階的に検出・読み込み
• Web 検索 — 基盤サービスが提供する検索機能をエージェントから利用
• ツール承認 — 継続的な承認ルールと、安全な呼び出しの自動承認
• テレメトリ — OpenTelemetry を組み込み、挙動を追跡・監査

.NET と Python での使い方

ハーネスの導入はごく簡単で、既存のチャットクライアントをラップするだけです。.NET では AsHarnessAgent、Python では create_harness_agent を使い、指示とツールを渡します。まずは .NET の例です。

// .NET（C#）：Foundry のクライアントをハーネスでラップする例
AIAgent agent = chatClient.AsHarnessAgent(new HarnessAgentOptions
{
    ChatOptions = new ChatOptions
    {
        Instructions = "あなたは有能なリサーチアシスタントです。…",
        Tools = [ /* 独自の AIFunction ツール */ ],
    },
});

// この 1 行の裏で、思考→ツール実行→記憶のループが完了まで回る
var response = await agent.RunAsync("…調査タスク…");

Python でも、同じ設計をほぼそのまま書けます。指示とツールを渡してエージェントを作り、run(...) で実行するだけです。

# Python：create_harness_agent でエージェントを作る例
from agent_framework import create_harness_agent

agent = create_harness_agent(
    client=client,
    agent_instructions="あなたは有能なリサーチアシスタントです。…",
    tools=[],
)

response = await agent.run("…調査タスク…")

ラップした瞬間から、ツール呼び出しループ・履歴保存・コンテキスト最適化・承認といった標準処理が有効になります。Tools に業務固有の関数を渡せば、社内 API の呼び出しやデータベース検索なども、エージェントが必要に応じて自律的に使い分けます。リサーチアシスタント、データ処理エージェント、個人向けの資産管理アシスタントなど、幅広い用途が想定されています。

「claw」と自作ハーネス

関連記事では、計画・ツール利用・記憶・自律実行を備えた CLI 型のエージェントを claw と呼び、その内側にあるのがハーネスだと説明しています。ハーネスは、ツール・プランニング・メモリ・承認・可観測性・マネージドなデプロイという 6 つの構成要素から成り、これらを部品として組み合わせれば自作も可能です。標準のハーネスをそのまま使うだけでなく、要件に応じて構成要素を差し替えたり、独自のループを組んだりできる余地が残されている、というわけです。

ただし前提として重視されているのが、モデルそのものの能力です。ハーネスはモデルにできることを何倍にも広げますが、エンジンはあくまでモデルであり、指示追従・関数呼び出し・長い文脈・多段推論に強い最新世代のモデルを使うことが推奨されています。土台となるモデルが弱ければ、いくら配管を整えても安定した自律動作は望めません。

導入前に押さえておきたい注意点

ハーネスは強力な反面、「1 回の呼び出しで多段の処理が走る」という性質から、設計時に意識しておきたい点もあります。

• コストとレイテンシ — 1 タスクの裏でモデルを何度も呼ぶため、トークン消費と実行時間は単発のチャットより大きくなります。反復回数の上限やモデルの選定で、コストと品質のバランスを取る設計が要ります。
• ツール承認の設計 — メール送信やデータ削除のような不可逆な操作は、自動承認に任せず人間の確認を挟む承認ルールを組むのが安全です。どこまでを自動化し、どこで止めるかは業務要件次第です。
• 可観測性の確保 — 自律的に動く分、「なぜその判断をしたか」を後から追えることが重要です。組み込みの OpenTelemetry を活用し、ツール呼び出しや失敗を記録・監査できる状態にしておきます。
• モデル依存の見極め — 前述のとおり、成果はモデルの実力に大きく左右されます。PoC の段階から、本番で使うモデルに近い構成で検証しておくと、想定外のふるまいを早期に発見できます。

まとめと位置づけ

Agent Harness の登場により、.NET / C# のエコシステムの中で、本格的な自律エージェントを短いコードで構築できるようになりました。Python と同じ設計で書ける点、Foundry と連携してスキル管理やホスティングまで見据えられる点も、業務システムへ組み込むうえで扱いやすい特徴です。エージェント基盤を自前で作り込む段階から、業務ロジックとツール設計に集中する段階へと、重心が移ったといえます。

エンハンスド株式会社では、LLM や AI エージェントを業務システムへ実装・内製化する支援を行っています。Microsoft Agent Framework をはじめとするモダンな基盤の選定から、ツール設計・運用までご相談いただけます。

よくある質問

Agent Harness と LangChain のようなエージェントフレームワークは何が違いますか？

ハーネスは Microsoft Agent Framework の一部として提供され、.NET / C# を第一級でサポートしながら Python でも同じ設計で書ける点が特徴です。履歴の永続化やコンテキスト最適化、ツール承認、OpenTelemetry によるテレメトリといった実運用向けの機能が標準で組み込まれており、Foundry と連携したスキル管理やホスティングまで見据えられます。既存のチャットクライアントをラップするだけで導入できる手軽さも利点です。

ハーネスを使うには特定のモデルが必要ですか？

特定モデルへの縛りはありませんが、成果はモデルの実力に大きく左右されます。指示追従・関数呼び出し・長い文脈・多段推論に強い最新世代のモデルを使うことが推奨されています。土台のモデルが弱いと、いくら配管を整えても安定した自律動作は得られにくくなります。

エージェントが暴走してツールを呼び続ける心配はありませんか？

ハーネスには反復回数の上限が設けられており、ツールを延々と呼び続ける暴走を防ぎます。加えて、不可逆な操作には人間の確認を挟む承認ルールを設計でき、履歴はモデル呼び出しごとに永続化されるため、問題があっても状態を追跡・復旧できます。

.NET と Python のどちらでも同じことができますか？

はい。.NET では AsHarnessAgent、Python では create_harness_agent と入口は異なりますが、指示とツールを渡してエージェントを実行するという設計は共通です。チーム構成や既存資産に合わせて言語を選べます。

参照元

本記事は、以下の Microsoft 公式ブログおよびドキュメントを参照して作成しています。

• The Microsoft Agent Framework Harness is now released（Microsoft DevBlogs）
• Build your own claw and agent harness with Microsoft Agent Framework（Microsoft DevBlogs）
• Agent Harnesses（Microsoft Learn ドキュメント）

このテーマの全体像は .NET × AI 活用 完全ガイド にまとめています。