はじめに
今回は生成AI文脈での Human in the loop と Human on the loop の違い、実際にHuman on the loop を目指して考えた具体的なアイデアを紹介します。
単に人がAIを使う状態から、AIが生成、判断、実行した内容を人間が確認してから次に進む設計が Human in the loop でしたが、ここ数ヶ月で大きくHITLからHOTLへの移行が発生しています。
今回はそれぞれの違いとそこからみえる今後の生成AI活用、具体的な業務への適用案を考えてみます。
この記事の主張
- 生成AI活用は「人がAIをどううまく使うか」から「AIが安全に動けるループを人が設計し、監督する」フェーズに移っている
- 現状ではすべてをHOTLにすることはまだ危険なので、リスクに応じてHITLとHOTLを使い分ける必要がある
Human in the Loop(HITL)とは
文字通りAIにおけるループの中に人間が介在する設計
AIの生成、判断、実行などのフェーズの途中に人間による確認、承認、修正を挟む設計を指す
生成AIを使った作業では「AIに作業を任せるが、最終的に人間が成果物を確認する」ような形になりやすい
具体的には
- AIが作成した文章を人間が確認して公開する
- AIが仕様調査した結果を人間が確認して回答する
- AIがコードを生成し、人間がレビューしてマージする
- AIエージェントがツール実行前に人間の承認を求める
- RAGの回答に対して、人間が引用元や根拠を確認する
HITLのメリット
- 人間の判断が挟まるので誤情報や誤操作を止めやすい
- 既存業務に導入しやすい
HOTLの限界
- 人間が毎回確認するため、処理量が増えると人間の確認がボトルネックになる
- 承認が形骸化しやすく、何も確認せずに承認してしまいがち
- 人間がAIの出力をすべて正しく検証できるとは限らない
- AIによる実行も検証もAIに指示を出す人の個人技に依存しやすい
HOTLとは
AIが一定範囲で自律的に動き、人間はその外側から任意のタイミングで監視・制御・介入をする設計
人間は毎回の細かい判断者ではなく、ループの設計者、監督者になる
生成AIエージェントの場合、下記のような設計が必要になる
- 実行の計画
- 実行における関連ツールの権限
- 実行内容や結果を観測する仕組み
- 実行中に意図しない挙動を検出して停止する仕組み
- 実行結果を評価する仕組み
さらに、実行結果からよりよい結果に改善するために次回移行使える記憶やskillsの改善の仕組みがあると更に便利になる
具体的には
- AIエージェントが自律的にMRがを確認し、レビュー観点を出す
- AIがSlackメンションや依頼を監視し、分類・要約・下準備を行う
- AIがIssueやMRを読み、必要な調査やコメント案を作成する
- AIが定期的にログや差分を見て、異常や対応候補を通知する
- 人間は実行ログや差分などを確認し、権限や停止条件などループが回る仕組みを監督する側に回る
HOTLのメリット
- 人間が介在しないので、24時間動き続ける事ができ、大量の処理が可能
- 人間のリソースを本当に集中すべき箇所に集中できる
- 判断が必要なタイミングがHITLより少なく、個人のAI活用ではなく、ループの設計ができればチームへの展開がしやすい
- AIが先回りして人間の判断に必要な情報収集・整理・下準備をできる
HOTLのリスク
- AIの自律性が高くなるほど、誤動作の影響範囲や手戻りコストが上がる
- プロンプトインジェクションなど意図しないツール実行によるリスクが増える
- ログや実行内容など人間が確認するための仕組みがないと人間は把握できない
- 手動で止められないので監視・停止・権限の設計が重要
それぞれの違い
| 観点 | Human in the Loop | Human on the Loop |
|---|---|---|
| 人間の位置 | 判断サイクルの中 | 判断サイクルの外側・上位 |
| AIの自律性 | 低〜中 | 中〜高 |
| 人間の役割 | 確認者・承認者・修正者 | 設計者・監督者・介入者 |
| 向いている業務 | 高リスク、不可逆、外部影響が大きい業務 | 低〜中リスク、大量処理、下準備、監視 |
| 典型例 | コードレビュー、公開前確認、ツール実行承認 | MR監視、Slack監視、ログ監視、調査自動化 |
| 失敗パターン | 人間がボトルネックになる | 監視不能・暴走・責任不明になる |
低リスク領域、簡単なものはHOTLへ、高リスク領域、複雑なものはHITLへ振り分ける
ただ、これまでAIにまかせていた1つの処理だけでなく、AをやってBをやってCを確認してDをする、のようなそれぞれのタスクが軽いが複数のタスクを必要とするようなものはskillsの登場もありHOTLで実行可能になってきている。
なぜ今、HITLからHIOLへの移行が起きているのか
AIへの期待値がチャットから作業になってきた
これまでのChatGPT的な利用では、人間が問いを立て、AIが応える形式だった。
現在主流なツールは商用展開されているものだとCodex、Claude Code、DevinのようなAIが調査、編集、実行、検証まで行うハーネスが用意されている物が多く、人間は生成AIに作業の代替を期待するようになっている
さらにそこから、人間がプロンプトを投げる部分がボトルネックになり、AIが自分でプロンプトを作成し、自分で実行する仕組みが注目されている。ここ1年くらい生成AI活用している人間は把握していた課題だが、最近「ループエンジニアリング」、と名前がつけられ、より話題になっている。
承認フローだけではスケールしない
生成AIの活用がすすむにつれ、すべてのAI出力を人間が確認するのは現実的ではなくなってきた。そもそも立ち返ると、組織内の全エンジニアのコードを確認できているわけでもなく、AIに任せても人間に任せても変わらない。
大量のレビュー、ログ確認、仕様調査などが発生し、人間の確認で詰まるが、生成AIは人間に依頼するのと比べても遥かに簡単に、安価にスケールできるのでより強いボトルネック感が発生する
人間が見るべき作業はどれか、を考え直す必要があり、リスクが高い判断や例外に集中する方針が選択されやすい
AI活用はスケールしなかった
ここ一年くらい、ある程度生成AI活用に取り組んでいる組織ではAI活用にかなり投資している。筆者の組織もその一つ。
ただ、生成AI活用はスケールしづらいことに多くの組織が気づき始めている。おそらく下記のような要因がある。
- 優秀な人がAIをうまく使うだけでは組織全体の生産性は上がりづらい
- 優秀な人の使い方などを展開してもらうのは発想、アイデアの共有として有意義なものの、プロンプト能力、言語化能力といった個人の能力に依存する部分は変わらない
- 生成AIを正しく活用できるのはシニアエンジニアが多いが、組織のジュニアエンジニアをすぐに全員シニアエンジニアに育てることが不可能な以上、組織的な生成AI活用はシニアエンジニアだけ進んでほかは止まってしまう
- シニアエンジニアの負担が減らない。シニアエンジニア、マネージャー目線だと人間に作業を切り分けて振ることとAIエージェントに指示を与えることに大きく差はない。組織として、ミドルエンジニアがシニアになる可能性や属人化の防止など人間に振るメリットが残る以上、現状維持バイアスの強いマネージャーの場合は生成AI活用の動機が弱い
- HOTLの場合はシニアがループを設計すれば明確にシニアの負担が減ることにつながり、タスクの手離れを実現できる。シニアエンジニアのAI活用を明確に組織に適用できる手段としてHOTLの考え方に移行しつつある、と考察している
個別型: Webhookを自作エージェントで受け取ってHOTLっぽくする
例えばGitHub/GitLabのWebhookを受け取ってレビュー、MR分類などをするエージェントを作成すると、HOTLに近づく。
Webhookをエージェントのプロセスに飛ばし、その内容に応じてイベントの内容を解析し、必要なワークフローを実行する
処理の流れ
- GitHub/GitLabからWebhookを受け取る
- イベント種別を判定する
- 対象MRやIssueの情報を取得する
- AIエージェントが解析する
- 必要に応じてMRの分類や要約、レビュー観点の記載や実際のコードレビューなどを行う
- SlackやMRコメントとして人間に通知する
- マージなど高リスクの操作を人間が行う
アイデア
開発の多くはGit起点で進むので、GitのWebhookを利用するといろんな活用ができる。実際に作成したものも含めると簡単な順に以下のようなものが挙げられる
- MRの分類
- AIが作成したものかどうか
- 人間がレビューしたほうがいいかどうか
- レビュー負荷を下げる
- 変更差分の要約
- 影響範囲の推定
- レビュー観点の提案
- 品質のサポート
- テスト観点の提案
- テスト設計の代替
- セキュリティ観点の確認
この案のメリットとしては、対象業務の範囲がある程度絞られるので権限設計などが明確であること、開発フローに自然に組み込めること、AIレビューやQA観点出しといった、現在のAI活用で人間が行っている課題と接続しやすいことなどがある。
汎用型: Hermesで自分宛てのslackをすべて監視させ、自律的な作業をすべてskillsにしていく
次に、個人的にここ半年くらいで一番筋がいいと思っているエージェント構築手段であるHermes Agentを紹介する
NousResearch/hermes-agent: The agent that grows with you
簡単に言うとOpenClawのようなサーバーにインストールするパーソナルエージェントで、特徴として、プロジェクトを学習して記憶したり、独自のスキルを構築したり、自動で構築したスキルのブラッシュアップをしてくれる。
アイデア
生成AIの活用において実務ベースで面倒な業務の棚卸しごとHermesに任せる事ができる。自分宛のslackの連絡や、普段自分がwatchしているチャンネルをすべてHermesに読ませて記憶させていく。
- 他人から自分宛てに作業依頼が来る
- Hermesが内容を確認し、対応方針をユーザーに確認する
- ユーザーが対応、またはHermesに指示して対応する
- 対応内容や注意点を記憶する
- 次回以降の対応はHermesが対応する
という形が実現できる。この方法であれば自分から業務を棚卸ししなくても、通常通り仕事をしていれば自然とHermesに業務知識を蓄積していくことができる。もちろん、これは定型業務ではない、といった場合や機密情報を含む場合などはHermesに任せなくてもいい。
この方法で単純なタスクはHermesに任せる事ができるようになる。
少し具体的にすると下記のような感じになる。
- Slackで自分宛てのメンションを検知する
- AIが内容を分類する
- 対応可能なskillがあるか判断する
- 対応に必要な情報を取得する
- 返信下書きや要約、調査結果、対応案を作成し、人間に提示する
- 人間が承認・修正・却下する
- 実行ログや修正内容を次回改善に使う
この案の場合は開発に限らず、自分の業務導線に自然に入りやすい。 作業内容がskill化されるので引き継ぎやチームへの横展開も簡単にできる。
同じようなタスクをチームで分担している場合はチーム単位でHermesを用意すると個人のナレッジが集約されて組織の力になる。
まとめ
- Human in the Loop は、AIの判断や実行の途中に人間の確認点を置く設計
- Human on the Loop は、AIが一定範囲で自律的に動き、人間が外側から監督・介入する設計
- 生成AIエージェントの普及により、実務ではHITLだけでは人間がボトルネックになりやすくなっている
- 一方で、HOTLは放置ではなく、権限・ログ・評価・停止・監査の設計があって初めて成立する
- 低リスクで大量処理が必要な領域はHOTLに向いている
- 高リスクで不可逆な操作はHITLを残すべき
- AI活用を個人技で終わらせないためには、プロンプトではなく、AIが安全に動ける業務ループを設計する必要がある
- そのための具体案がwebhookをトリガーとしたエージェントや、Hermes Agentの活用
