Human-in-the-Loop の Service API 化（v1.14.0）

状態: draft / 重要度: ★★★★

TL;DR

• これまで HITL（Human-in-the-Loop）はコンソール UI 経由のみだったが、v1.14.0 で Service API 経由 で承認・差し戻し操作ができるようになった
• これにより外部システム（Slack、社内 BPM、Teams、Linear 等）から HITL ワークフローを駆動できる
• 本番運用での承認フロー、検収プロセス、リスク管理に直接効く

想定読者

• Dify ワークフローを 業務システム に組み込みたい開発者
• 承認フロー / SLA / リスク管理を Dify 外のツールから制御したい運用者
• 既に HITL を Console 経由で運用していて、自動化したい運用者

なぜ重要か

LLM 出力に対する人間判断は、ハイリスクなドメイン（金融・医療・法務・カスタマーサポート）では不可避。コンソール UI のみだと:
- 担当者が Dify に毎回ログイン必要
- 既存の業務ツール（Slack/Teams）から離れる
- 承認 SLA の自動測定が困難

Service API で外部連携可能になると:
- Slack のメッセージから直接承認/差し戻しできる
- 既存の業務ワークフローエンジン（Camunda, Zapier, n8n）から制御できる
- 監査ログを統合できる

アウトライン（執筆予定）

1. これまでの HITL（Console モード）の制約

• どこから承認するか
• どんなフローが組めなかったか

2. v1.14.0 で追加された Service API

• エンドポイント（要確認）
• 想定リクエスト/レスポンス
• 認証方式（API Key / Service Token / OAuth）

3. 統合パターン例

• パターン A: Slack Bot → HITL 承認
• パターン B: 社内 BPM → HITL 起動 → 結果コールバック
• パターン C: n8n / Zapier から自動承認ルール

4. 実装サンプル（Python / curl）

5. 監査・ログとの統合

• 誰がいつ何を承認したかの記録
• 自社の SIEM への送信

6. 制限事項と注意点

• レート制限
• 並行承認の競合
• API トークン管理

検証が必要な事項

• [ ] 正確なエンドポイント仕様（v1.14.0 PR から特定）
• [ ] 認証スコープ
• [ ] レート制限値
• [ ] Cloud と Self-host で差異あるか
• [ ] OpenAPI v2 ドキュメントへの記載有無

ソース:
- GitHub Release v1.14.0 — Human-in-the-loop (HITL) セクション
- Dify Service API Docs

本記事は非公式まとめです。正式仕様は Dify 公式ドキュメントをご確認ください。