連載: AIに仕事を奪われる不安から始めるハーネス作成入門
第15回: Human-in-the-loopはどこに入れるべきか
第1〜14回: ✅ 公開済み ｜ 当該記事: 📖 ｜ 次回: 第16回
はじめに――「AIに任せっぱなし」への漠然とした不安
AIエージェントが業務の一部を自動化すると聞いたとき、「本当に全部任せて大丈夫なのか？」と感じた方は多いのではないでしょうか。
実は、その感覚は正しいものです。AIエージェントは万能ではなく、特に業務クリティカルな場面では「人間が確認・承認するポイント」を設けることが欠かせません。これを**Human-in-the-loop（HITL）**と呼びます。
今回は、ハーネスにおけるHITLを「どこに」「どのように」入れるべきかを、設計観点で整理します。
Human-in-the-loopとは何か
Human-in-the-loopとは、AIの処理フローの中に「人間の判断・承認」を組み込む設計パターンです。
AIがすべてを自律的に実行するのではなく、特定のタイミングで人間に判断を委ねることで、安全性と信頼性を確保します。既存の業務システムでも、承認フローやダブルチェックの仕組みがありますが、それと同じ考え方です。
HITLの3つのレベル
| レベル | 内容 | 典型例 |
|---|---|---|
| 承認型 | AIの出力を人間が承認してから実行 | メール送信前の確認、デプロイ前のレビュー |
| 監視型 | AIが実行した結果を人間が事後確認 | ログレビュー、定期監査 |
| 介入型 | 異常時のみ人間が介入 | エラーエスカレーション、フォールバック |
どのレベルを選ぶかは、「その操作の影響度」と「失敗時の可逆性」で判断できます。
なぜHITLが必要なのか――判断基準を持つ
「全部人間が確認すればいい」という考え方もありますが、それではAIエージェントを使う意味が薄れます。かといって、全自動ではリスクが残ります。
そこで大切なのは、「どの処理に承認を入れるか」の判断基準を持つことです。
承認を入れるべきかの判断軸
- 影響範囲: 外部システムへの書き込み、メール送信など「取り消せない操作」があるか
- コスト: 課金APIの呼び出しなど、金銭的な影響があるか
- セキュリティ: 機密情報や個人情報を扱うか
- 可逆性: 失敗したときに元に戻せるか
これらの軸で「高」に該当する処理があれば、承認ポイントを設ける候補です。
ハーネスのどのレイヤーにHITLを置くか
ハーネスのアーキテクチャを振り返ると、HITLを置くレイヤーは大きく3つに分かれます。
1. 入力レイヤー（タスク受付時）
エージェントにタスクを投入する前の段階です。ここでは主に「タスク内容の妥当性確認」を行います。
- タスクが許可された範囲内かのバリデーション
- 機密情報が含まれていないかのチェック
- リスクレベルの自動判定
2. 処理レイヤー（ツール実行前）
MCPツールの呼び出しなど、実際に外部システムを操作する前の段階です。ここが最も重要な承認ポイントになります。
- ツールのパラメータ確認（何をどこに書き込むのか）
- コスト見積の確認（API呼び出し回数、課金額）
- 実行計画のレビュー
3. 出力レイヤー（結果確認時）
エージェントの処理が完了した後の段階です。
- 出力内容の品質確認
- 異常検知時のエスカレーション
- 監査ログの記録
承認ポイント一覧――実務で使える設計表
ここまでの整理をもとに、ハーネスで使える承認ポイント一覧を作成しました。
| # | レイヤー | 承認ポイント | 判断基準 | HITLレベル | 実装例 |
|---|---|---|---|---|---|
| 1 | 入力 | タスク受付時のバリデーション | タスクが許可範囲外の場合 | 介入型 | ホワイトリストチェック |
| 2 | 入力 | 機密情報スキャン | 機密情報パターン検出時 | 介入型 | 正規表現マッチング |
| 3 | 処理 | 外部API書き込み前承認 | 常に（取り消せない操作） | 承認型 | Slack承認フロー |
| 4 | 処理 | 課金API呼び出し前確認 | 閾値超過時 | 承認型 | コスト見積表示 |
| 5 | 処理 | データ削除・更新前確認 | 常に（破壊的操作） | 承認型 | 実行計画プレビュー |
| 6 | 処理 | バッチ処理の中間チェック | 件数閾値超過時 | 監視型 | 進捗レポート通知 |
| 7 | 出力 | 処理結果の品質確認 | AI出力の信頼度が低い場合 | 監視型 | 信頼度スコア表示 |
| 8 | 出力 | エラー時のエスカレーション | リトライ失敗・異常終了時 | 介入型 | アラート通知 |
| 9 | 出力 | 監査ログ記録 | 常に（全処理） | 監視型 | 構造化ログ出力 |
ログ・監査の設計観点
HITLを機能させるためには、「何が起きたか」を追跡できるログが不可欠です。
ログに含めるべき情報
import logging
from datetime import datetime
def log_approval_event(task_id: str, action: str, decision: str, approver: str):
"""承認イベントを構造化ログとして記録"""
log_entry = {
"timestamp": datetime.utcnow().isoformat(),
"task_id": task_id,
"event_type": "approval",
"action": action,
"decision": decision, # approved / rejected / timeout
"approver": approver,
"layer": "processing" # input / processing / output
}
logging.info(f"HITL_EVENT: {log_entry}")
ポイントは以下の通りです。
- タイムスタンプ: いつ承認イベントが発生したか
- タスクID: どのタスクに対する承認か
- アクション: 何をしようとしていたか
- 判断結果: 承認・却下・タイムアウトのいずれか
- 承認者: 誰が判断したか
「承認疲れ」を防ぐ設計のコツ
承認ポイントを増やしすぎると、「承認疲れ」が起きます。人間が確認を形骸化し、「とりあえずOK」を押してしまう状態です。
これを防ぐための判断基準を持っておきましょう。
- リスクベースで絞る: 影響度が低い処理は自動承認にする
- 段階的に緩和: 最初は厳しく、実績が貯まったら自動化率を上げる
- コンテキストを添える: 承認通知に「なぜ承認が必要か」の説明を付ける
- タイムアウトを設ける: 一定時間応答がなければ安全な側に倒す（デフォルト拒否）
SE経験が活きるポイント
業務システムを開発・運用してきたSEの方であれば、HITLの考え方はなじみ深いはずです。
- ワークフローエンジンの承認設計 → エージェントの承認フロー設計に応用
- 障害対応のエスカレーションルール → エラー時の介入型HITLに応用
- 監査ログの設計 → HITLイベントのログ設計に応用
- テスト設計の観点 → 承認フローのテストケース設計に応用
AI時代だからこそ、こうした「人間がシステムを制御する」設計の経験が求められています。
実装の第一歩――まずは承認ポイントを洗い出す
実際にハーネスにHITLを組み込むには、まず自分のハーネスの処理フローを書き出し、各処理に対して上記の承認ポイント一覧を埋めてみてください。
最初から完璧を目指す必要はありません。「影響が大きい処理」から承認型HITLを導入し、微調整していくのが現実的なアプローチです。
まとめ
- Human-in-the-loopは「全自動」と「全手動」の間を埋める設計パターン
- 承認ポイントは「影響範囲」「コスト」「セキュリティ」「可逆性」の4軸で判断
- 入力・処理・出力の3レイヤーでHITLの配置を検討
- 承認疲れを防ぐために、リスクベースで絞り段階的に緩和
- SEの業務システム経験がそのままHITL設計に活きる
次回予告
第16回「Slack承認を想定したハーネス処理フローを描く」では、今回整理した承認ポイントを実際のSlack連携フローに落とし込みます。Mermaidシーケンス図を使って、タスク受付から承認・実行・結果通知までのフローを可視化します。「承認ポイントはわかったけど、具体的にどう実装するの？」という疑問に答える回です。
📖 連載一覧: 第1〜14回 ✅ 公開済み ｜ 第15回（本記事） ｜ 第16回 Slack承認を想定したハーネス処理フローを描く