AI AGENT HARNESSクラウド別

Microsoft AzureのAgent Harness設計｜Agent FrameworkとFoundry Agent Service

検索意図：Microsoft Azure Agent Harness Foundry Agent Service Hosted agents Entra RBAC VNet 比較

結論

Agent HarnessはMicrosoft Agent Framework内でモデル、ツール、承認、状態を束ねるアプリケーション側の実行設計です。Hosted agentsは、そのコードをFoundry管理下の隔離環境へ配置するクラウド実行基盤です。両者を同一製品として扱わず、Harness、ホスティング、ID・権限、ネットワーク、監視、業務承認を別々に設計します。

対象：Microsoft Azureを利用するAI・DX責任者・クラウド・ID基盤担当者・Microsoft 365・セキュリティ担当者更新：2026-08-18次回確認：2026-09-18

Agent Harness内を探す⌄

FIT / NO-FIT

先に、導入対象かを判定する

向いている条件

✓Microsoft Entra IDとAzure RBACを既存のID・権限管理へ組み込める
✓独自コードのagentを管理されたsession isolationとscale-to-zeroで動かしたい
✓Application Insights／OpenTelemetryを既存の監視運用へ接続できる
✓Microsoft 365 Copilot／Teamsへの公開を別の配布・承認工程として管理できる

まだ導入しない条件

—Harness実装を持たず、prompt設定だけで完結させたい
—外部リソースへの権限をagent identityへ個別付与できない
—trace、session file、conversationのデータ分類・保持方針を決められない
—個別機能のpreview／experimental利用を承認する手順がない

DECISION CRITERIA

発注前に確認する判断基準

01責任分界

Agent Harnessの実装責任とHosted agentsの基盤責任を分けて説明できるか

進められる状態: 自社が持つ指示、ツール、承認、評価と、Foundryが持つendpoint、identity、session isolation、scalingを構成図で分離している
止めるサイン: Hosted agentsへ配置すれば、業務ルール、承認、評価、復旧まで自動的に完成すると考える

02ID・権限

利用者、プロジェクト、agentのidentityとRBAC scopeを分けられるか

進められる状態: 呼び出し主体、project managed identity、agent identityを識別し、外部リソースには用途別の最小権限を付与する
止めるサイン: Azure Owner／ContributorだけでFoundry data planeも操作できる、またはagent identityが外部データへ自動アクセスできると見なす

03閉域・監視

VNetの保護対象とtelemetryの送信・閲覧権限を確認したか

進められる状態: account、project、ACR、Storage、Application Insights、agent endpointの経路を個別確認し、traceの内容と閲覧者を定義している
止めるサイン: VNet integrationを「全endpointが非公開」の意味で使う、またはpromptやtool引数を無条件でtraceへ残す

04提供状態

GAの基盤とpreview／experimentalの追加機能を分離したか

進められる状態: Agent Framework 1.0とHosted agents GAを基礎にし、Harnessのbackground agents・file access・looping、A2A等の個別状態を再確認する
止めるサイン: Microsoftブランド配下の機能を一括してGAと記載し、SLAや本番可否を個別確認しない

OPERATING FLOW

業務を完了するまでの役割分担

0101 / BUILD

Harnessをアプリケーションとして実装

Microsoft Agent Frameworkでモデル、ツール、context、todo、approval、telemetryを構成し、業務固有の停止条件を加える。

責任：Agent開発チーム

0202 / HOST

Hosted agentとして配置

ResponsesまたはInvocations protocolを選び、Foundryのversion、session、endpoint、compute条件を設定する。

責任：Azure・Foundry基盤担当

0303 / AUTHORIZE

identityと接続経路を限定

agent identityへ接続先ごとのRBACを付与し、VNet、private endpoint、tool connection、Microsoft 365公開範囲を確認する。

責任：ID・ネットワーク・セキュリティ担当

0404 / OBSERVE

trace・評価・人の承認で運用

Application Insightsのtrace、品質評価、費用、権限拒否、承認結果を確認し、変更時は新versionとして再評価する。

責任：業務責任者＋運用担当

REFERENCE ARCHITECTURE

HarnessコードとFoundry実行基盤を分離した構成

01 / CHANNEL

Microsoft 365・Teams・業務UI

利用者identity、公開範囲、管理者承認、各サービス側のデータ取扱いを管理する。

02 / HARNESS

Microsoft Agent Framework

Agent Harnessがtool loop、context、memory、approval、planning、業務固有の制御を持つ。

03 / HOSTING

Foundry Hosted agents

専用endpointとagent identity、session単位の隔離、永続file、scaling、versionを管理する。

04 / ACCESS

Entra ID・RBAC・VNet・Toolbox

利用者委任またはagent identityを使い、許可したresourceとtoolだけへ接続する。

05 / GOVERN

Application Insights・評価・Purview

OpenTelemetryと評価で挙動を確認し、必要な場合はPurview middlewareとpolicyを明示的に構成する。

横断制御

agentごとのEntra identity
Foundry data plane RBAC
tool・resource別の最小権限
approval必須操作
VNet・private endpoint確認
traceのredactionと閲覧制御
version単位の再評価

Agent HarnessはFoundryとは独立したアプリケーション実装です。Hosted agentsのGAは、Harness内のexperimental機能や接続先サービスまで一括してGAにするものではありません。

USE CASES

最初に検証する3業務

Microsoft 365内の業務回答支援

入力: Teamsからの質問、利用者identity、権限内の業務データ
Agentの処理: OBOまたはagent identityを用途に応じて選び、許可済みtoolで検索・回答案を作成する
成果物: 出典と実行記録を伴う回答案
人が決める範囲: 組織公開はMicrosoft 365管理者が承認し、対外回答・契約判断は業務担当者が確定する

最初のKPI：確認込み回答時間、権限越境件数、出典不備率

複数Azure resourceの運用調査

入力: 監視alert、許可済みlog、runbook、resource metadata
Agentの処理: Harnessが調査todoを作り、読み取りtoolを順に実行して原因候補と根拠を整理する
成果物: 調査手順、根拠、推奨対応の下書き
人が決める範囲: 設定変更、再起動、権限変更、削除は運用担当者が承認する

最初のKPI：一次切り分け時間、誤操作件数、人への移管率

長い調査・文書作成タスク

入力: 目的、承認済みsource、成果物条件
Agentの処理: Harnessのplanning、todo、context compaction、file memoryで作業を分割し、Hosted agentsのsessionへ状態を保持する
成果物: 参照元と作業履歴を伴う成果物案
人が決める範囲: source追加、shell実行、外部公開は承認し、experimental機能は本番採用前に個別審査する

最初のKPI：完了率、承認待ち時間、再実行率、根拠不備率

ROI / TCO

効果と費用を同じ前提で比べる

業務便益とAzure運用費を同じ期間で比較

対象件数 ×（現在時間 − 導入後の確認・修正・例外対応を含む人手時間）× 時間単価 −（model費＋Hosted compute費＋tool費＋監視費＋（基盤運用工数 × 時間単価））

Hosted runtimeのCPU・memoryはactive sessionの実測利用量で置く
model token、Toolbox・接続先、memory、Microsoft 365／Purview等のlicenseを別項目にする
Application Insightsの保存・検索と、評価・権限レビューの人件費を含める
preview機能の再試験・変更対応をゼロ円と置かない

検討例：先行1業務で月間件数、現行時間、確認後時間、active session時間、token、trace量を測り、1か月の実測から継続・縮小・停止を判断する。固定の削減率は使用しない。

BlueAIの比較式であり、Microsoftの価格表や成果保証ではありません。region、契約、利用量、license、個別preview状態を最新の公式情報と見積で更新してください。

Hosted runtime・model

長時間session、高い同時実行、重いmodel・contextほど増える

active sessionのCPU・memory、model token、永続状態、同時実行数を分けて確認する。

接続・ネットワーク

閉域対象、環境数、接続先、region分離が増えるほど構築・運用費が増える

Foundry project、ACR、Storage、VNet、private endpoint、DNS、Toolbox接続の構成範囲。

監視・コンプライアンス

trace量、保持期間、監査頻度、利用者・tenant範囲で変動する

Application Insights／Log Analyticsの保持・照会、評価、Purview、Microsoft 365公開のlicenseと管理。

STOP CONDITIONS

失敗を小さく止める条件

Harnessとhostingの混同

兆候：業務approval、tool policy、評価の所有者がFoundry側として記載されている

対応：Harnessコード、Hosted runtime、Azure control、業務運用の責任分界を構成図とRACIに分ける

identityの過剰権限

兆候：project managed identityとagent identityを共用扱いし、subscriptionまたはresource group全体へ広いroleを付ける

対応：呼び出しにはFoundry Agent Consumerを検討し、agent identityには接続先data planeの最小roleだけを付与する

traceからの情報漏えい

兆候：prompt、tool引数、取得文書、個人情報がredactionなしでApplication Insightsへ送信される

対応：取得前にデータ分類し、span内容を制限・マスクし、Monitoring Readerと保持期間を最小化する

個別previewの本番混入

兆候：A2A、background agents、file access、looping、shell等をGAのHarness／Hosted agentsと同じ扱いで採用する

対応：packageと機能単位でlifecycle、SLA、region、制約を記録し、代替手段と停止条件を持つ

90-DAY ROADMAP

90日で本番判断まで進める

0〜30日

責任分界と公式状態を確定

—Harness、Hosted runtime、identity、業務承認の所有者を分離
—利用するpackage・protocol・regionのlifecycleを確認
—データ、tool、trace、session fileを分類

判定：GAとpreview／experimentalが機能単位で記録され、最小権限と人の承認境界が承認される

31〜60日

1業務を隔離環境で検証

—ResponsesまたはInvocationsで1用途を配置
—agent identityの拒否・許可とVNet経路を試験
—Application Insightsでtrace、費用、失敗を確認

判定：権限越境0件で、停止・再配置・session削除・手作業復帰を再現できる

61〜90日

限定公開と運用判定

—対象利用者と実行上限を限定
—Microsoft 365公開または業務UI接続を別工程で審査
—実測KPIと総費用から継続・縮小・停止を決定

適用範囲：自社入力による工数便益とmodel、compute、tool、network、監視、運用費の比較式。市場平均・成果保証ではない。

提供状態：実測利用量、Microsoft価格表、個別見積で案件ごとに更新。

確認日
2026-08-18

執筆：株式会社BlueAI技術レビュー：BlueAI 技術レビュー次回確認：2026-09-18

RELATED GUIDES

01 基礎・比較

AGENT HARNESS / FOUNDATION

Agent Harness完全ガイド

Agent Harnessは、モデルにツールを渡すだけの部品ではなく、依頼受付から計画、権限確認、実行、人の承認、記録、停止までを管理する実行基盤です。最初は1業務・読み取り中心・承認必須で検証します。

BlueAI実務フレームBlueAI試算

更新 2026-08-18
技術レビュー：BlueAI 技術レビュー設計条件を見る →

02 基礎・比較

AGENT HARNESS / FOUNDATION

Agent Harnessのセキュリティ

Agent Harnessのsecurityは、モデルを信用して権限を渡す設計ではなく、入力を未信頼として扱い、専用ID・最小権限・tool policy・人の承認・完全な証跡・即時停止を実行基盤側で強制します。

BlueAI実務フレームBlueAI試算

更新 2026-08-18
技術レビュー：BlueAI 技術レビュー設計条件を見る →

03 基礎・比較

AGENT HARNESS / FOUNDATION

Agent Harness基盤比較

製品名ではなく、必要なsurfaceと自社が所有する範囲で選びます。DeepSeek Harnessは公式OSSですがDeveloper Previewかつprereleaseで、安定した本番標準基盤とは断定できません。LangGraphは低レベルorchestration、OpenAI Agents SDKはagent primitiveを組むSDKとして評価します。

BlueAI実務フレームBlueAI試算

更新 2026-08-18
技術レビュー：BlueAI 技術レビュー設計条件を見る →

FROM GUIDE TO DECISION

自社の業務・費用・承認条件に置き換える。

一般情報は登録なしで確認できます。次に、AI利益MAPで投資回収を試算し、RFPで権限・評価・停止条件を発注文書へ落とします。

AI利益MAPでROI試算 →RFPを作成 →構成を相談する →

先に、導入対象かを判定する

向いている条件

まだ導入しない条件

発注前に確認する判断基準

Agent Harnessの実装責任とHosted agentsの基盤責任を分けて説明できるか

利用者、プロジェクト、agentのidentityとRBAC scopeを分けられるか

VNetの保護対象とtelemetryの送信・閲覧権限を確認したか

GAの基盤とpreview／experimentalの追加機能を分離したか

業務を完了するまでの役割分担

Harnessをアプリケーションとして実装

Hosted agentとして配置

identityと接続経路を限定

trace・評価・人の承認で運用

HarnessコードとFoundry実行基盤を分離した構成

Microsoft 365・Teams・業務UI

Microsoft Agent Framework

Foundry Hosted agents

Entra ID・RBAC・VNet・Toolbox

Application Insights・評価・Purview

最初に検証する3業務

Microsoft 365内の業務回答支援

複数Azure resourceの運用調査

長い調査・文書作成タスク

効果と費用を同じ前提で比べる

Hosted runtime・model

接続・ネットワーク

監視・コンプライアンス

失敗を小さく止める条件

Harnessとhostingの混同

identityの過剰権限

traceからの情報漏えい

個別previewの本番混入

90日で本番判断まで進める

責任分界と公式状態を確定

1業務を隔離環境で検証

限定公開と運用判定

根拠・確認範囲・更新日

別の軸から判断する

Agent Harness完全ガイド

Agent Harnessのセキュリティ

Agent Harness基盤比較

自社の業務・費用・承認条件に置き換える。