DevUI Agent Inspectorの使い方｜agentの停止・再生・prompt編集・model変更を実践解説

DevUI Agent Inspectorを使えば、agentを毎回先頭から実行し直さなくても、execution tree上で問題箇所を確認し、実行を一時停止してpromptやmodelを変更し、その地点を基準にreplayできます。変更前後を同じOpenTelemetry traceの構造で比較できるため、「promptの指示不足」「modelの能力差」「toolに渡したpayloadの誤り」を切り分けやすくなります。

Azure Update 563551でpublic previewとして案内されたAgent Inspectorは、model call、tool invocation、intermediate stateを実行ツリーで表示し、実行途中のpause、replay、prompt編集、再起動を伴わないmodel swap、tool payloadの確認に対応します。さらに、Microsoft Foundryのobservabilityで利用されるものと同じOpenTelemetry traceを参照するため、ローカルと運用環境の比較にも使えます。(Microsoft Azure)

ただし、replayは外部データベースや送信済みメールまで巻き戻す機能ではありません。再現性を高めるには、promptやmodelだけでなく、時刻、乱数、toolの応答、外部システムの状態も管理する必要があります。

DevUI Agent Inspectorでできること

Agent Inspectorは、最終回答だけを見るチャット画面ではありません。agentが回答に至るまでの処理を分解し、どの段階で期待した動作から外れたかを調べるためのデバッグ画面です。

機能	確認・操作できる内容	実務での用途
Execution tree	model call、tool invocation、intermediate stateの流れ	最初に誤った判断をしたノードを探す
Pause	実行途中で処理を一時停止	後続処理や副作用が発生する前に状態を確認する
Replay	選択した実行地点を基準に再実行	同じ前段条件で変更前後を比較する
Prompt edit	実行途中のpromptを変更	指示文、制約、出力形式の改善を試す
Model swap	DevUIを再起動せずmodelを変更	modelごとのtool選択や回答品質を比較する
Tool payload inspection	toolへ送った引数やpayloadを確認	引数名、値、型、欠落項目を調べる
OpenTelemetry trace	span階層、処理時間、model・toolの実行経路を確認	ローカルとFoundry observabilityの結果を比較する

これまではpromptを変更するたびにagentを先頭から実行し、偶然同じ経路を通ることを期待する必要がありました。Agent Inspectorでは、実行ツリーと途中状態を見ながら比較対象を絞り込めるため、変更した要因と結果の関係を把握しやすくなります。(Microsoft Azure)

replayで「同じ状態からdebugする」とは

Agent Inspectorを使っても、すべての条件が自動的に同一になるわけではありません。「同じ状態」は、主に選択した実行地点までにAgent Frameworkが保持・表示している会話、model call、tool call、intermediate stateを基準にするという意味です。

比較時に揃えやすいもの	別途固定が必要なもの
user input	現在時刻
直前までの会話履歴	乱数や一時ID
system prompt、developer prompt	外部APIの最新データ
tool名とtool定義	データベースの更新状態
toolへ渡した引数	検索結果の順位や内容
選択したmodel・deployment	model出力の揺らぎ
実行ツリー上の分岐地点	並列toolの完了順序

したがって、Agent Inspectorのreplayは「完全なタイムトラベル」ではなく、比較条件を揃えやすくする分岐デバッグと考えるのが適切です。

再現性を上げるには、次の条件をテストケースとして記録します。

記録項目	例
ケースID	`order-cancel-001`
入力	「昨日注文した商品を取り消したい」
prompt版	`support-prompt-v3`
model	provider、model名、version、deployment名
model設定	temperature、top_p、seedなど
tool応答	fixture名または保存したJSON
基準trace	trace ID、実行日時
期待結果	キャンセル可否を確認し、実行前に承認を求める

ローカルDevUIの構成

DevUIは、Microsoft Agent Frameworkのagentやworkflowを実行するための軽量なスタンドアロン型サンプルアプリです。Web UIとOpenAI互換APIを提供し、agentをアプリケーションへ統合する前にテスト、可視化、デバッグできます。

PythonではCLIから独立したローカルサーバーとして起動できるため、agentプロセスの横で動くsidecarとして扱いやすい構成です。.NETではASP.NET CoreアプリへDevUI endpointを組み込む方法が公式リポジトリで案内されています。いずれも開発用であり、DevUI自体を本番のagent UIや公開APIとして利用することは想定されていません。(Microsoft Learn)

構成を単純化すると、次のようになります。

[agent / workflow]
   ├─ model call
   ├─ tool call
   └─ OpenTelemetry spans
             │
             ▼
[ローカルDevUI]
   ├─ Agent Inspector
   ├─ execution tree
   ├─ prompt / model編集
   └─ debug panel
             │
             ▼
[開発者のブラウザー]

OpenTelemetry spans
   └─ Microsoft Foundry observabilityや外部collectorとの比較

DevUIは独自のspanを生成するのではなく、Agent Frameworkが実行中に出力したOpenTelemetry spanを収集してdebug panelへ表示します。一般的なtraceでは、Agent Executionの下にLLM Call、Prompt、Response、Tool Call、Tool Execution、Tool Resultが階層化されます。(Microsoft Learn)

PythonでDevUI sidecarを起動する

DevUIをインストールする

Python版DevUIは、PyPIのpre-release packageとしてインストールできます。Python 3.10以降が必要です。(PyPI)

python -m venv .venv
.venv\Scripts\Activate.ps1

python -m pip install --upgrade --pre agent-framework-devui

agentをディレクトリ探索させる場合は、たとえば次のように配置します。

agents/
└─ support_agent/
   ├─ __init__.py
   ├─ agent.py
   └─ .env

__init__.pyでは、DevUIに読み込ませるagentまたはworkflowをexportします。公式packageでは、このディレクトリ構造による自動探索と、コードからのin-memory登録の両方がサポートされています。(PyPI)

OpenTelemetry instrumentationを有効にして起動する

最初に、インストール済みCLIのoptionを確認します。

devui --help

2026年7月時点では、Microsoft Learnの説明では--tracing、PyPI上の現行packageでは--instrumentationという表記が使われています。public preview中はoption名が変わる可能性があるため、実際にインストールしたversionのdevui --helpを優先してください。(Microsoft Learn)

PyPI上の現行表記を使う場合は、次のように起動します。

devui ./agents --port 8080 --instrumentation

インストール済みversionで--tracingが表示される場合は、次の形式を使用します。

devui ./agents --port 8080 --tracing

ブラウザーでローカルDevUIを開きます。

http://localhost:8080

Developer modeで起動すると、debug panel、entity情報、hot reloadなどの開発者向け機能を利用できます。(PyPI)

.NETでDevUIを組み込む

.NET版では、ASP.NET CoreアプリへDevUIを登録し、開発環境だけで/devui endpointを公開する構成が利用できます。

必要なpackageは次のとおりです。

dotnet add package Microsoft.Agents.AI.DevUI
dotnet add package Microsoft.Agents.AI.Hosting
dotnet add package Microsoft.Agents.AI.Hosting.OpenAI

既存のagent登録に、DevUIとOpenAI Responses、Conversationsのserviceおよびendpointを追加します。

using Microsoft.Agents.AI.DevUI;
using Microsoft.Agents.AI.Hosting;
using Microsoft.Agents.AI.Hosting.OpenAI;

var builder = WebApplication.CreateBuilder(args);

// 既存のagent登録
builder.AddAIAgent(
    "assistant",
    "You are a helpful assistant."
);

if (builder.Environment.IsDevelopment())
{
    builder.AddDevUI();
}

builder.AddOpenAIResponses();
builder.AddOpenAIConversations();

var app = builder.Build();

app.MapOpenAIResponses();
app.MapOpenAIConversations();

if (builder.Environment.IsDevelopment())
{
    app.MapDevUI();
}

app.Run();

実行後は、ASP.NET CoreアプリのURLに/devuiを付けてアクセスします。

https://localhost:<port>/devui

.NETのDevUIでは、AddDevUI()によるservice登録だけでなく、AddOpenAIResponses()、AddOpenAIConversations()と、それぞれのendpoint mappingが必要です。MapDevUI()だけを追加すると、必要なserviceが登録されていない、または会話・response endpointへ接続できない状態になる可能性があります。(GitHub)

Microsoft LearnではC#向けDevUI文書を「近日公開」としている一方、公式GitHubリポジトリのpackage READMEには.NET向けの設定例が掲載されています。public preview中はLearnとpackage READMEの更新時期がずれることがあるため、実装時は使用中のpackage versionに対応するREADMEとsourceを確認するのが確実です。(Microsoft Learn)

Agent Inspectorで停止・prompt編集・replayする手順

プレビュー版ではbutton名や配置が変わる可能性がありますが、基本的な作業順序は共通です。

まず変更前のbaselineを実行する

最初からpromptを編集せず、問題が起きる入力をそのまま実行します。

baselineでは、少なくとも次の情報を残します。

項目	確認内容
入力	userが送信した原文
agent	entity名、workflow名
model	model名、version、deployment
prompt	system、developer、user message
tool	呼び出されたtoolと順番
payload	toolへ渡された引数
result	toolの戻り値とerror
trace	trace ID、主要span、処理時間
最終結果	期待結果との差

baselineを保存しないまま編集を始めると、改善したように見えても、prompt、model、tool結果のどれが効いたのか判断できません。

execution treeで「最初の分岐」を探す

最終回答の誤りだけを見るのではなく、execution treeを上からたどります。

たとえば、注文キャンセルagentが誤って返金toolを実行した場合、確認すべき順番は次のとおりです。

user inputを正しく解釈したか
キャンセル可否を調べるtoolを選んだか
toolへ正しい注文IDを渡したか
tool resultを正しく読んだか
承認前に書き込みtoolを呼び出していないか
最終回答がtool resultと一致しているか

最終回答の文章を直すより、期待経路と実際の経路が最初に分かれたノードを修正する方が、再発防止につながります。

実行をpauseする

問題箇所の前後でagentをpauseし、後続処理へ進む前にintermediate stateを確認します。

確認する内容は次のとおりです。

その時点までのconversation context
modelへ送られるprompt
選択中のmodelとdeployment
利用可能なtool定義
直前のtool result
次に実行しようとしているtoolとpayload

すでにremote model APIへ送信済みのrequestや、開始済みのtool処理まで必ず取り消されるとは限りません。pauseを「外部処理の取消」として扱わず、trace上で実際にどこまで完了したかを確認してください。

promptだけを変更してreplayする

原因がpromptにあると考えられる場合は、modelやtool定義を変えず、promptだけを編集します。

変更前が次のような曖昧な指示だったとします。

注文情報を確認し、適切に対応してください。

比較用promptでは、判断条件と禁止事項を明示します。

注文情報を確認し、キャンセル可否を判定してください。

制約:
- toolの戻り値だけを根拠に判断する
- userの明示的な承認前に、返金・削除・取消を実行しない
- 注文IDが不足している場合はtoolを呼び出さず、userへ確認する
- キャンセルできない場合は理由と次の手続きを説明する
- 最終回答には内部tool名を表示しない

編集後、同じ実行地点を基準にreplayします。比較時は次の条件を変えないようにします。

user input
model
model parameter
tool定義
tool result
conversation history

一度に複数の条件を変更すると、改善理由を特定できません。

modelだけをswapしてreplayする

promptの比較が終わったら、promptを固定したままmodelを変更します。

model swapでは、単にmodel名を変えるだけでなく、次の互換性を確認します。

確認項目	確認する理由
Tool calling	同じtool定義を解釈・呼び出せるか
Structured output	JSON Schemaなどの出力制約に対応するか
Context window	replay時の会話とtool resultが収まるか
Multimodal	画像やfileを含む入力に対応するか
Sampling parameter	temperature、seedなどの扱いが同じか
System message	instructionの優先順位や解釈が変わらないか
Content filter	deploymentごとのfilterで結果が変わらないか
Permission	新しいdeploymentへ接続できるcredentialか
Latency・cost	品質改善に対して許容できるか

記録するmodel情報は、表示名だけでは不十分です。少なくともprovider、model名、model version、deployment名をセットで残します。

provider: Azure OpenAI
model: <model-name>
model-version: <version>
deployment: support-agent-canary

同じmodel名でも、deployment、region、version、filter設定が異なれば結果が変わる可能性があります。

tool payloadを確認する

modelの回答が不自然でも、原因がpromptやmodelとは限りません。toolへ誤った引数を渡しているケースがあります。

たとえば、次のpayloadでは注文番号と顧客番号を取り違えています。

{
  "customer_id": "ORD-20260720-001",
  "order_id": "CUST-8241"
}

Agent Inspectorではtoolへ送られたpayload全体を確認できるため、次のような問題を切り分けられます。

必須引数が欠けている
IDの種類を取り違えている
日付のtimezoneが異なる
数値が文字列として渡されている
enumに存在しない値を生成している
tool resultの一部だけを誤って参照している
前回のconversation stateが混入している

payloadが誤っている場合、toolの内部実装を修正する前に、tool description、parameter名、schema、promptのtool選択条件を確認します。

prompt編集を成功させる判断基準

promptを長くすれば品質が上がるとは限りません。Agent Inspectorで変更するpromptは、問題の発生地点に直接関係する内容へ絞ります。

曖昧な目的を判断規則へ変える

「適切に対応する」では、modelが何を適切と判断すべきか分かりません。

悪い例:
適切なtoolを使って対応してください。

改善例:
注文IDが存在する場合だけget_orderを呼び出してください。
get_orderのstatusがshippedの場合はcancel_orderを呼び出さず、
返品手続きを案内してください。

tool実行の条件と禁止条件を分ける

実行条件だけでなく、実行してはいけない条件も記述します。

cancel_orderを実行できる条件:
- statusがprocessing
- userが取消内容を確認済み
- userが明示的に承認済み

cancel_orderを実行してはいけない条件:
- 注文IDが未確認
- statusがshippedまたはdelivered
- tool resultにerrorが含まれる

出力形式と根拠を固定する

比較しやすい出力形式を指定します。

次のJSON形式で出力してください。

{
  "decision": "cancel | return | ask_user | error",
  "reason": "判断理由",
  "requires_approval": true,
  "next_action": "次に実行する処理"
}

自由文だけで比較するより、decisionやrequires_approvalの差を機械的に判定できます。

UI上の編集を正式版にしない

Agent Inspector上のprompt編集は実験です。採用するpromptが決まったら、必ず次の場所へ反映します。

source code
prompt template
configuration file
prompt management system
automated test fixture

UI上で改善しただけでは、アプリケーション再起動や別環境へのdeployで元のpromptへ戻る可能性があります。

OpenTelemetry traceで変更前後を比較する

DevUIのdebug panelでは、span階層、timing、agentやworkflowのevent、tool callとresultを確認できます。Agent InspectorはFoundry observabilityと同じOpenTelemetry traceを参照するため、ローカルで見た実行経路と運用環境のtraceを同じ観点で比較できます。(Microsoft Learn)

比較時は、最終回答だけでなく次の項目を確認します。

比較項目	BaselineとCandidateで見る差
Span tree	model・toolの実行順序が変わったか
最初の分岐	どのspanから経路が変わったか
Prompt	instruction、context、添付データの差
Model	provider、version、deploymentの差
Tool selection	選ばれたtoolが適切か
Tool arguments	値、型、必須項目、timezoneの差
Tool result	同じfixtureまたは同じ外部状態か
Error status	timeout、validation error、認証error
Duration	model、tool、workflow別の処理時間
Usage	traceに出力されているtoken usage
Final result	期待結果、schema、根拠との一致

ここでいうOpenTelemetry parityは、ローカルとFoundryで同じtrace情報を追跡できることです。ローカルと本番でmodel出力や処理時間が必ず一致するという意味ではありません。

次の条件が違えば、同じtrace構造でも結果は変わります。

model deploymentとversion
credentialとaccess policy
network latency
region
content filter
tool接続先
database内容
environment variable
feature flag
system clock

そのため、trace比較時には環境差も合わせて記録します。

再現性を下げる代表的な原因

症状	主な原因	対処
同じ地点からreplayしても回答が違う	model出力の揺らぎ	sampling設定を記録し、複数回比較する
tool resultが毎回違う	時刻、検索結果、外部APIの更新	fixture、mock、recorded responseを使う
toolの順番が変わる	並列実行や非同期完了順	比較テストでは直列化または順序を記録する
同じ注文を二重処理した	書き込みtoolをreplayした	dry-run、sandbox、idempotency keyを使う
promptを変えても結果が変わらない	分岐後のpromptを編集した	最初に判断を誤ったmodel callまで戻る
model swap後にtool callが失敗する	schemaやtool callingの互換性不足	model capabilityとtool schemaを確認する
ローカルとFoundryで結果が違う	deploymentや外部データが異なる	model、region、tool接続先を揃える
traceが途中で切れる	instrumentation未設定、process終了	CLI optionとexport設定を確認する

特に重要なのは、最終結果ではなく「最初の分岐」を探すことです。

期待経路:
入力
  → 注文確認
  → キャンセル可否判定
  → user承認
  → キャンセル実行

実際の経路:
入力
  → 注文確認
  → 返金toolを選択
  → 返金実行

この場合、修正対象は最終回答ではなく、注文確認後に返金toolを選んだmodel callです。

replay前にtoolの副作用を分類する

Agent Inspectorでreplayする前に、toolを副作用の強さで分類します。

分類	例	replayの扱い
Read-only	検索、参照、一覧取得	比較的安全
Idempotent write	同じkeyへのupsert、状態同期	実装と条件を確認して実行
Non-idempotent write	メール送信、決済、発注、投稿	原則mockまたはdry-run
Destructive	削除、取消、権限剥奪	sandboxと人間の承認を必須にする

書き込みtoolには、可能な範囲で次の仕組みを追加します。

dry_run parameter
idempotency key
test tenant
sandbox endpoint
mock adapter
human approval
重複実行検知
実行前後の監査log

たとえば、メール送信toolは直接送信せず、debug時には次のような結果だけを返すmockへ切り替えます。

{
  "dry_run": true,
  "recipient": "[email protected]",
  "subject": "注文取消の確認",
  "would_send": true
}

これにより、tool選択やpayloadは確認しながら、実際の送信を防げます。

DevUIを安全に使うための注意点

DevUIにはsystem instruction、tool定義、model identifier、workflow構造、tool payloadなど、外部へ公開すべきでない情報が表示されます。

.NET版は、初期状態ではloopback以外からのrequestを拒否する設計です。Python版もlocalhostまたは127.0.0.1での利用を基本とし、0.0.0.0、LAN IP、hostnameなどへbindする場合は、明示的なBearer token認証が必要です。(GitHub)

共有開発機でPython版を公開する場合は、tokenを設定します。

$env:DEVUI_AUTH_TOKEN = "<secure-dev-token>"
devui ./agents --mode user --host 0.0.0.0

またはCLI optionで指定します。

devui ./agents `
  --mode user `
  --host 0.0.0.0 `
  --auth-token "<secure-dev-token>"

次の運用は避けてください。

DevUIをそのままインターネットへ公開する
本番credentialを共有PCへ保存する
traceへaccess tokenやpasswordを出力する
個人情報を含むtool payloadを長期間保存する
本番の決済・送信toolを無条件でreplayする
UIで変更したpromptをversion管理せず本番へ反映する

Agent Inspectorが表示されないときの確認項目

package versionを確認する

Pythonでは次のコマンドを実行します。

python -m pip show agent-framework-devui
devui --help

.NETでは利用中のpackageを確認します。

dotnet list package
dotnet list package --include-transitive

public previewでは、Azure Updateの告知、PyPIやNuGetへの配布、Learn文書の更新時期が一致しない場合があります。Inspectorのmenuや操作が見つからない場合は、pre-releaseを含む対応versionがインストールされているかを確認します。

traceが表示されない

次の順に確認します。

Developer modeで起動しているか
--instrumentationまたは--tracingを付けているか
起動後に新しいagent runを実行したか
Agent Framework側がOpenTelemetry spanを出力しているか
errorでagent processが途中終了していないか
外部collectorのendpoint設定が誤っていないか

DevUIは独自にspanを作るのではなく、Agent Frameworkが出力したspanを表示します。そのため、Framework側からspanが出ていなければexecution traceは表示されません。(Microsoft Learn)

Pythonでagentが検出されない

各agentまたはworkflowのdirectoryに__init__.pyを置き、対象entityをexportしているか確認します。

from .agent import support_agent

agent = support_agent

外部moduleをimportしている場合は、project rootがPYTHONPATHへ含まれているかも確認します。

$env:PYTHONPATH = "."
devui ./agents --port 8080 --instrumentation

.NETで`/devui`が404になる

次の4組が揃っているか確認します。

builder.AddDevUI();

builder.AddOpenAIResponses();
builder.AddOpenAIConversations();

app.MapOpenAIResponses();
app.MapOpenAIConversations();

app.MapDevUI();

また、DevUIをDevelopment環境だけでmappingしている場合は、現在のenvironmentがDevelopmentになっているか確認します。

$env:ASPNETCORE_ENVIRONMENT = "Development"
dotnet run

modelを変更したらreplayが失敗する

model swap後の失敗は、modelの性能不足とは限りません。次の差を確認します。

tool calling対応の有無
JSON Schema対応範囲
model context limit
deployment permission
content filter
system messageの扱い
添付fileや画像の対応
parameter名や使用可能なsampling設定

特に、tool calling非対応のmodelへswapした場合、同じpromptでもexecution tree自体が変わります。

再現性の高いdebugを行う実践フロー

実務では、次の順番に固定すると原因を追いやすくなります。

問題を再現する入力を1件に絞る
prompt、model、tool resultを変更せずbaselineを実行する
OpenTelemetry trace IDを保存する
execution treeから最初の分岐ノードを探す
副作用のあるtoolをmockまたはdry-runへ切り替える
問題ノードの直前でpauseする
promptだけを変更してreplayする
promptを固定し、modelだけをswapしてreplayする
tool payload、span tree、処理時間、最終結果を比較する
採用したpromptとmodel設定をsource codeへ反映する
同じケースを自動回帰テストへ追加する
Foundry observability上の本番相当traceと比較する

変更する変数は、常に一度に1つです。

Baseline A:
prompt v1 + model A + tool fixture 1

Candidate B:
prompt v2 + model A + tool fixture 1

Candidate C:
prompt v2 + model B + tool fixture 1

この順番なら、AとBの差はprompt、BとCの差はmodelです。promptとmodelを同時に変更するより、改善要因を明確に説明できます。

DevUI Agent Inspector活用の要点

DevUI Agent Inspectorの価値は、agentの最終回答を眺めることではなく、model call、tool invocation、intermediate stateを実行ツリーで追い、最初に判断を誤った地点から比較をやり直せる点にあります。

まずローカルDevUIをOpenTelemetry instrumentation付きで起動し、変更前のbaseline traceを保存します。次にexecution treeで最初の分岐を探し、promptだけ、modelだけという順に一つずつ変更してreplayします。結果は最終回答だけでなく、tool選択、payload、span構造、処理時間まで比較してください。

同時に、replayは外部システムのrollbackではないことを忘れてはいけません。メール送信、決済、取消、削除などのtoolはmock、dry-run、idempotency key、sandboxを用意してから実行します。

最初に行うべき作業は、DevUIを対応するpreview versionへ更新し、1件の再現ケースをOpenTelemetry trace付きで実行することです。そのtraceを基準に「最初の分岐」を特定できれば、promptとmodelの調整を勘ではなく比較実験として進められます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

DevUI Agent Inspectorの使い方｜agentの停止・再生・prompt編集・model変更を実践解説

DevUI Agent Inspectorでできること

replayで「同じ状態からdebugする」とは

ローカルDevUIの構成

PythonでDevUI sidecarを起動する

DevUIをインストールする

OpenTelemetry instrumentationを有効にして起動する

.NETでDevUIを組み込む

Agent Inspectorで停止・prompt編集・replayする手順

まず変更前のbaselineを実行する

execution treeで「最初の分岐」を探す

実行をpauseする

promptだけを変更してreplayする

modelだけをswapしてreplayする

tool payloadを確認する

prompt編集を成功させる判断基準

曖昧な目的を判断規則へ変える

tool実行の条件と禁止条件を分ける

出力形式と根拠を固定する

UI上の編集を正式版にしない

OpenTelemetry traceで変更前後を比較する

再現性を下げる代表的な原因

replay前にtoolの副作用を分類する

DevUIを安全に使うための注意点

Agent Inspectorが表示されないときの確認項目

package versionを確認する

traceが表示されない

Pythonでagentが検出されない

.NETで`/devui`が404になる

modelを変更したらreplayが失敗する

再現性の高いdebugを行う実践フロー

DevUI Agent Inspector活用の要点

この記事を書いた人

コメント

コメントするコメントをキャンセル

DevUI Agent Inspectorの使い方｜agentの停止・再生・prompt編集・model変更を実践解説

DevUI Agent Inspectorでできること

replayで「同じ状態からdebugする」とは

ローカルDevUIの構成

PythonでDevUI sidecarを起動する

DevUIをインストールする

OpenTelemetry instrumentationを有効にして起動する

.NETでDevUIを組み込む

Agent Inspectorで停止・prompt編集・replayする手順

まず変更前のbaselineを実行する

execution treeで「最初の分岐」を探す

実行をpauseする

promptだけを変更してreplayする

modelだけをswapしてreplayする

tool payloadを確認する

prompt編集を成功させる判断基準

曖昧な目的を判断規則へ変える

tool実行の条件と禁止条件を分ける

出力形式と根拠を固定する

UI上の編集を正式版にしない

OpenTelemetry traceで変更前後を比較する

再現性を下げる代表的な原因

replay前にtoolの副作用を分類する

DevUIを安全に使うための注意点

Agent Inspectorが表示されないときの確認項目

package versionを確認する

traceが表示されない

Pythonでagentが検出されない

.NETで/devuiが404になる

modelを変更したらreplayが失敗する

再現性の高いdebugを行う実践フロー

DevUI Agent Inspector活用の要点

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

.NETで`/devui`が404になる

コメントするコメントをキャンセル