結論:Human-in-the-Loopは「信頼」ではなく「仕組み」で運用する
- Human-in-the-Loopとは、AIエージェントの処理の要所に人間の確認・承認を組み込む設計です。AIを信頼するかどうかという心構えの話ではなく、どこに何を置くかという設計の問題です。
- パターンは3つあります。①実行前に止める「承認ゲート」、②実行後に一定割合を確認する「検査サイクル」、③想定外の事態で人間へ引き継ぐ「エスカレーション基準」です。
- 承認ゲートの実装例はAtlassianのJira Software Cloud、検査サイクルの考え方はScrum Guideの「検査と適応」の原則に、それぞれ一次情報として確認できます(出典は本文末尾)。
- 任せる業務の線引きはAIエージェントに任せていい業務・任せてはいけない業務の線引きで扱いました。本記事は、線引きを決めたあとの「監視役」の設計に絞って整理します。
なぜ「監視役」を最初から設計するのか
「この業務は任せてよい」という判定が済んだ時点で運用設計が止まり、実行後にその判断が正しかったかを継続的に確認する仕組みまで手が回っていない企業は少なくありません。入力データの傾向の変化、想定外の例外、モデルやプロンプトの更新は、最初の線引きの時点では見えていません。線引きは「入口の基準」であり、実行結果を人間がどこかで確認する仕組みとセットにしておく必要があります。Human-in-the-Loopは、この確認の場所と方法を、担当者の感覚ではなく仕組みとして決める考え方です。以下、3つのパターンに分けて整理します。
設計パターン①:承認ゲート — 実行前に人間が止める
もっとも厳格な設計が、AIエージェントの処理を特定のポイントで一時停止し、人間の承認を得るまで先に進めない「承認ゲート」です。
Atlassianの公式ドキュメントによると、Jira Software Cloudでは一部の作業アイテムが次のステータスに移動する前に承認を必要とする設定ができ、承認者に指定されたメンバーが確認・承認する仕組みが用意されています(承認ステップはワークフローの任意のステータスに追加可能。Jira Software Cloud Premiumプランで利用可)。担当者が承認待ちのステータスまで処理を進めると承認者に通知が届き、承認されるまで次の工程には進みません。
AIエージェントの運用では、対外発信・本番環境の設定変更・確定処理など、取り消しにくく影響範囲が広い処理の直前に、この一時停止を挟む設計になります。どの処理に置くべきかは、任せていい業務・任せてはいけない業務の線引きで整理した「可逆性・影響範囲・判断の性質」の3軸がそのまま判断基準になります。
設計パターン②:検査サイクル — 実行後に定期的に確認する
すべての処理に承認ゲートを置くと、AIエージェントを導入する意味が薄れます。任せてよいと判定した定型作業には、事前に止めるのではなく、実行後に一定間隔で成果物を確認する「検査サイクル」を組み合わせるのが現実的です。
この考え方は、Scrum Guideの原則と重なります。Scrum Guideは透明性・検査・適応の3本柱について「透明性のない検査は誤解を招き、無駄である」「適応のない検査は無意味である」と説明し、「スクラムの作成物と合意した目標に向けた進捗は、頻繁かつ真摯に検査されなければならない」としています。あわせて、スプリントレビューは「価値をリリースするためのゲートとみなすべきではない」とも明記しています。実行は止めず、頻繁な検査で軌道修正するという設計思想です。
AIエージェント運用に当てはめると、出力の一定割合を人間が抜き取って確認する「サンプリング監査」になります。承認ゲートが実行前に100%を止める設計であるのに対し、検査サイクルは実行を止めず事後に一部を確認する設計です。定型的で取り消しやすい業務ほど検査サイクル寄りに、取り消しにくく影響が大きい業務ほど承認ゲート寄りに設計します。
設計パターン③:エスカレーション基準 — 異常時に人間へ引き継ぐ
承認ゲートと検査サイクルは、想定できる処理を対象にした仕組みです。実際の運用では、エラーの多発、権限範囲を超えた操作の試行、明らかに不自然な出力など、事前に想定していなかった異常も起こります。これに備えるのがエスカレーション基準です。
Atlassianの公式ドキュメントによると、Jira Service Managementには、アラートを次の担当者に引き継ぐ「エスカレーション」の仕組みが用意されています。重要なのは機能そのものより、「誰が」「何をもって」引き継ぐかを、異常が起きる前に決めておくという発想です。
AIエージェント運用でも、「エラー率が一定の閾値を超えたら処理を止めて人間に通知する」「権限外の操作のログが記録されたら即座に停止する」「出力が過去の傾向から大きく外れたら一時停止する」といった基準を、平時のうちに具体的な数値や条件として決めておく必要があります。基準がないと、承認ゲートと検査サイクルの隙間をすり抜けた問題に誰も気づけません。
自社の運用に当てはめると
社内で完結する記事の下書き生成やキーワード調査、データの収集・整理は検査サイクルの対象にし、成果物を社外へ発信する工程やシステムの設定変更は承認ゲートの対象にしています。この基準は、任せていい業務・任せてはいけない業務の線引きで整理した「影響が社内で閉じるか、社外・顧客に及ぶか」という軸そのものです。
まとめ
Human-in-the-Loopは、AIエージェントを信頼するかどうかという心構えの問題ではなく、①承認ゲート、②検査サイクル、③エスカレーション基準という3つの仕組みを、処理の性質に応じてどこに配置するかという設計の問題です。「何を任せるか」の線引きを終えた企業ほど、次はこの「監視役」の設計に取り組むタイミングです。
Human-in-the-Loopの設計から相談したい場合は、AIエージェント導入支援サービスをご覧ください。承認ゲートの配置から検査サイクルの運用設計まで、実務目線でご相談いただけます。
出典
- Atlassian「What are approvals?」https://support.atlassian.com/jira-software-cloud/docs/what-are-approvals/ /「Set up approvals in Jira」https://support.atlassian.com/jira-software-cloud/docs/set-up-approvals-in-jira/ — Jira Software Cloudの承認ステップの仕組み(Premiumプランで利用可)を確認。確認日:2026年9月17日
- Scrum Guide(2020年版)https://scrumguides.org/scrum-guide.html — 透明性・検査・適応の原則、スプリントレビューに関する記述を確認。確認日:2026年9月17日
- Atlassian「Escalate an alert」https://support.atlassian.com/jira-service-management-cloud/docs/escalate-an-alert/ — Jira Service Managementのエスカレーション機能を確認。確認日:2026年9月17日
