連載: 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承認を想定したハーネス処理フローを描く