Microsoft developer platformのDialog Mode更新まとめ｜Agent DialogとWeb Dashboard対応の確認ポイント

結論から言うと、2026年5月5日の「Microsoft developer platform documentation update: feat(dialog): agent dialog mode with web dashboard support」は、Microsoftのmicrosoft/conductorでエージェントがワークフロー実行中にユーザーと複数ターンの会話を行えるようにする更新です。既存ワークフローをすべて書き換える必要がある変更ではなく、主にdialog.trigger_promptを追加した通常のagentが対象になります。対応すべき人は、ConductorでAIエージェントワークフローを設計している開発者、Web Dashboardを使って実行状況を確認しているチーム、CIや自動実行で--skip-gatesを使っている運用担当者です。元PRはGitHub上で2026年5月4日にmainへマージされ、Dialog Mode追加が変更の中心として説明されています。(GitHub)

Microsoft developer platform documentation updateで追加されたDialog Modeとは

今回の更新で追加されたDialog Modeは、エージェントが処理結果を出したあと、必要に応じてワークフローを一時停止し、ユーザーと自由形式の会話を行うための仕組みです。

従来の人間確認は「承認する」「差し戻す」「却下する」のような選択式のhuman gateが中心でした。一方、Dialog Modeでは「要件が曖昧なので、どの方向で調査すべきか確認したい」「複数の設計案があり、どちらを採用するか聞きたい」といった場面で、エージェントとユーザーが会話できます。

Conductor自体は、GitHub Copilot SDKやAnthropic Claudeを使ってマルチエージェントワークフローをYAMLで定義・実行するCLIツールです。README上でも、機能一覧に「Dialog mode — Agents can pause for multi-turn conversation when uncertain」が追加されており、Web Dashboardによるリアルタイム可視化やhuman gateと並ぶ機能として位置づけられています。(GitHub)

何が変わったのか

PR #130では、Dialog Modeを単なるドキュメント追加ではなく、コア処理・プロバイダー・Web Dashboard・テスト・サンプルまで含む機能追加として整理しています。変更点は次のように見ると分かりやすいです。(GitHub)

領域	主な変更	実務上の意味
Core	gates/dialog.py、engine/dialog_evaluator.py、スキーマ、ワークフローエンジン連携を追加	エージェント出力を評価し、条件に合う場合だけ会話を開始できる
Provider Support	CopilotとClaudeプロバイダーにDialog対応を追加	既存のCopilot／Claudeベースのワークフローで利用しやすい
Web Dashboard	DialogDetail、DialogEngagementPrompt、DialogOverlayなどのReactコンポーネントを追加	ブラウザ上で会話UIを扱える
Tests	スキーマ、評価器、Dialog gateのテストを追加	設定ミスや判定ロジックを検証しやすい
Docs & Examples	workflow-syntax.mdとdialog-mode.yaml、dialog-test.yamlを追加	実装前に設定例を見ながら検証できる

重要なのは、Dialog Modeが「すべてのエージェントをチャット化する機能」ではないことです。エージェントの実行後に、ユーザー定義の条件をLLM evaluatorが見て、会話が必要かどうかを判断します。会話が終わると、会話の transcript が追加コンテキストとして渡され、エージェントが再実行されます。(GitHub)

Dialog Modeの動作イメージ

Dialog Modeの流れは、次の順番で理解すると実装判断がしやすくなります。

ステップ	何が起きるか	確認すべき点
エージェント実行	通常どおりプロンプトに基づいて出力する	出力スキーマが曖昧すぎないか
Dialog評価	dialog.trigger_promptの条件に照らして、会話が必要か判断する	trigger条件が広すぎないか
ユーザー選択	Discussするか、会話をスキップして続行するか選ぶ	自動実行時に待ち状態にならないか
複数ターン会話	ユーザーとエージェントが不足情報を確認する	機密情報が会話に出ないか
再実行	会話内容を追加コンテキストとしてエージェントが再出力する	出力が後続ステップの期待形式を満たすか

ドキュメントでは、Dialogが発火した場合に「Discuss」と「Do your best and continue」の選択肢が提示され、会話後にエージェントが会話 transcript を追加コンテキストとして再実行されると説明されています。Web Dashboardでは、グラフ領域が一時的にチャットインターフェースに置き換わる点も押さえておきたい変更です。(GitHub)

対応が必要な人と影響範囲

今回の更新で最も影響を受けるのは、Microsoft developer platform上でConductorのワークフローを設計・運用しているチームです。特に、曖昧な要件をAIエージェントに処理させている場合は、Dialog Modeによって「途中で人間に確認する」設計が取りやすくなります。

対象者	対応優先度	理由
ConductorでYAMLワークフローを作成している開発者	高	dialog.trigger_promptを使うかどうかの設計判断が必要
Web Dashboardを運用画面として使うチーム	高	Dialog UIが実行中の操作体験に影響する
CI/CDやバッチでConductorを実行している担当者	高	--skip-gates時はDialogが自動スキップされるため、想定どおりか確認が必要
AIエージェントの出力品質をレビューするリードエンジニア	中	不確実性や曖昧さを検知する基準を設計できる
既存ワークフローを手動実行だけで使っているユーザー	中	対話が増えることで作業時間や運用手順が変わる可能性がある
Dialogを使わない既存ワークフローの利用者	低	dialog設定を追加しない限り、直接の影響は限定的

ドキュメント上、Dialogは通常のagentタイプのみを対象とし、human_gate、script、workflowには対応しないとされています。また、CIや自動化で使われる--skip-gatesが設定されている場合、Dialogは自動的にスキップされます。(GitHub)

まず確認すべき設定ポイント

既存ワークフローを確認する場合は、いきなりDialog Modeを全エージェントに追加するのではなく、曖昧さが業務影響につながるステップから見直すのが現実的です。

確認項目	見る場所	判断基準
Dialogを入れるべきエージェントか	agents配下の各ステップ	要件確認、調査方針、設計判断など、人間の意図確認が必要な処理か
trigger条件が明確か	dialog.trigger_prompt	「不確実なとき」だけでなく、どの種類の不確実性かを書けているか
自動実行で止まらないか	CLIオプション、CI設定	--skip-gates利用時にDialogがスキップされても問題ないか
Web Dashboardで操作できるか	--web実行、フロントエンド配布物	チャットUIが表示され、会話・スキップ・続行ができるか
後続ステップの入力が壊れないか	outputスキーマとroutes	会話後の再出力が後続エージェントの期待値に合うか
情報漏えいリスクがないか	エージェント出力、会話ログ	ファイルパス、コード片、顧客情報などを表示してよいか

特に重要なのはtrigger_promptです。ドキュメントでは、trigger promptは「何を質問するか」ではなく「いつDialogを発火させるか」を説明するものだとされています。質問内容は、エージェント出力の文脈からevaluatorが生成します。(GitHub)

設定例: 曖昧な要件だけDialogを発火させる

最小構成では、通常のagentにdialog.trigger_promptを追加します。たとえば、調査エージェントがテーマの解釈に迷う可能性がある場合は、次のように設定できます。

agents:
  - name: researcher
    prompt: |
      Research the given topic thoroughly:
      {{ workflow.input.topic }}

      If the topic is broad, explain the assumptions you made.
    output:
      summary:
        type: string
        description: Research summary
      assumptions:
        type: string
        description: Assumptions made during research
    dialog:
      trigger_prompt: |
        Trigger dialog if the agent expresses significant uncertainty
        about the user's intent, encounters ambiguous requirements,
        or makes assumptions that could change the direction of the work.

        Do not trigger dialog for minor uncertainty that the agent can
        reasonably resolve on its own.
    routes:
      - to: writer

公開されているdialog-mode.yamlの例でも、researcherエージェントが曖昧さや複数解釈に遭遇した場合にDialogを発火させ、軽微な不確実性では発火しないようにしています。--webを付けて実行する例も示されているため、CLIだけでなくWeb Dashboardでの挙動確認にも使えます。(GitHub)

使うべき場面と使わないほうがよい場面

Dialog Modeは便利ですが、入れすぎるとワークフローの自動化メリットを損ないます。判断基準は「人間の確認によって、後続の手戻りが大きく減るか」です。

使うべき場面	理由
要件が広すぎて、調査範囲や設計方針が複数ある	早い段階で方向性をそろえられる
コードレビューやリファクタリングで対象範囲が曖昧	誤った前提で大量の修正を進めるリスクを減らせる
ビジネス判断やドメイン知識が必要	エージェントだけでは判断しにくい前提を補える
出力の前提が後続工程に強く影響する	早期確認でワークフロー全体の品質を上げやすい

使わないほうがよい場面	理由
テスト実行やビルドなど機械的な処理	会話よりもscript stepや条件分岐のほうが適している
些細な表現ゆれまで毎回確認したい場合	Dialogが頻発し、運用負荷が高くなる
完全自動化を前提にしたCIジョブ	--skip-gatesでスキップされる前提の設計が必要
機密情報を出力に含む可能性が高い処理	会話UIやログに表示される情報を慎重に扱う必要がある

実務では、「不確実なら必ず聞く」ではなく、「聞かないと大きな手戻りが起きるときだけ聞く」と考えると失敗しにくくなります。

Web Dashboard対応で確認したいこと

今回の更新名にある「web dashboard support」は、単にドキュメントにスクリーンショットが追加されたという意味ではありません。PRでは、Dialog用のReactコンポーネント、ワークフローストア、イベントタイプ、詳細パネル、レイアウト、静的アセットの更新が含まれています。(GitHub)

Web Dashboardを使っているチームは、次の観点で確認してください。

• conductor run workflow.yaml --webでDialogが発火したとき、チャットUIが表示されるか
• 「Discuss」と「Do your best and continue」の選択が直感的に操作できるか
• Dialog中にワークフロー全体の状態が分かりにくくならないか
• 会話終了後、対象エージェントが再実行され、後続ステップへ進むか
• ダッシュボードの静的アセットが古いまま配信されていないか

社内でConductorをラップした独自UIを使っている場合は、Dialog関連イベントを無視していないかも確認が必要です。UI側がDialogイベントを理解していないと、ワークフローが止まったように見える可能性があります。

移行時に失敗しやすいポイント

trigger_promptを広く書きすぎる

「不明点があればDialogする」とだけ書くと、エージェントが少しでも前提を置いた場面で会話が発火しやすくなります。たとえば調査ワークフローなら、「複数の解釈があり、選ぶ方向によって結論が変わる場合」など、発火条件を業務影響に結びつけて書くべきです。

自動化ワークフローでDialog前提にしてしまう

CIや夜間バッチでは、人間がDashboardで応答できないことがあります。ドキュメントでは--skip-gates設定時にDialogが自動スキップされると説明されているため、自動実行時は「会話しなくても最低限進められるプロンプト」にしておく必要があります。(GitHub)

human_gateとDialog Modeを混同する

human gateは明確な選択肢を提示して承認や分岐を行う仕組みです。Dialog Modeは、自由形式の会話で曖昧さを解消する仕組みです。

承認フローならhuman gate、要件確認ならDialog Mode、テスト実行ならscript stepというように使い分けると、ワークフローが読みやすくなります。

後続ステップの出力形式を確認しない

Dialog後は、会話内容を踏まえてエージェントが再出力します。そのため、後続ステップがsummaryやanalysisなど特定フィールドを期待している場合は、会話後も同じスキーマで出力されるようにプロンプトとoutput定義を整えておく必要があります。

ファイルリンクや表示内容の安全性を軽視する

PRでは、相対ファイルリンクの扱いやパストラバーサルに関するレビューコメントもあり、最終的に..セグメントやWindowsドライブレターを拒否する防御強化が行われたと説明されています。Dialogではエージェント出力やファイルパスがユーザーに提示されるため、表示してよい情報か、リンクとして扱ってよいパスかを確認してください。(GitHub)

導入前の実務チェックリスト

Dialog Modeを本番ワークフローに入れる前に、次の順で確認すると安全です。

| 順番 | 作業 | 完了条件 |
| -: | ————————– | ———————————- |
| 1 | 対象エージェントを選ぶ | 曖昧さが大きな手戻りにつながるステップだけを選定する |
| 2 | dialog.trigger_promptを書く | 発火条件が業務上の判断基準として説明できる |
| 3 | サンプル入力でCLI実行する | 会話が必要なケースと不要なケースを再現できる |
| 4 | --webでDashboard確認する | Dialog UIで会話・スキップ・続行ができる |
| 5 | --skip-gates時の挙動を見る | 自動実行時に想定どおりスキップされる |
| 6 | 後続ステップの出力を確認する | Dialog後もroutesとoutput schemaが破綻しない |
| 7 | ログと表示情報を確認する | 機密情報や不要なファイルパスが露出していない |
| 8 | チーム向け運用ルールを決める | いつDiscussし、いつskipするかを共有できている |

まずは公開されているdialog-test.yamlのように、必ずDialogが発火するテスト用ワークフローで動作を確認すると、UIやイベントの挙動を把握しやすくなります。このサンプルでは、コードベース分析の質問が広すぎるという前提で、複数の分析アプローチを示し、Dialogを強制的に発火させる構成になっています。(GitHub)

今回の更新で取るべき次の行動

今回のMicrosoft developer platform documentation updateは、Conductorのワークフローに「人間へ確認してから続ける」柔軟性を加える更新です。既存ワークフローを一括変更する必要はありませんが、要件確認・設計判断・調査範囲の決定をAIエージェントに任せている場合は、Dialog Modeを検討する価値があります。

最初にやるべきことは、既存YAMLの中から「エージェントが勝手に前提を置くと困るステップ」を1つ選ぶことです。そのステップにだけdialog.trigger_promptを追加し、CLI実行、Web Dashboard実行、--skip-gates実行の3パターンで確認してください。Dialogが頻発するなら条件を狭め、逆に重要な曖昧さを見逃すなら条件を具体化します。

Dialog Modeは、自動化を止める機能ではなく、自動化の中で「人間に聞くべき瞬間」を明確にする機能です。うまく使えば、AIエージェントの独断による手戻りを減らし、ワークフロー全体の品質を上げられます。