Human in the loopの先へ — AIに任せる階段の登り方
AIにどこまで仕事を任せるかを考えるとき、Human in the loop / on the loop / out of the loop という3つの言葉が良い補助線になる。この記事では、この3分類を「タスクごとに信頼を積んで登る階段」として捉え直し、個人開発での実例をもとに、AIに任せる範囲の広げ方を書いてみる。
Human in / on / out of the loop とは
まず言葉の整理から。この3つは、もともと軍事や航空といった自律システムの分野で「人間がループのどこに立つか」を表すために使われてきた分類だ。AIエージェントに仕事を任せる文脈に翻訳すると、こうなる。
Human in the loop — 人間がループの中にいる。AIの作業は人間が承認しないと先へ進まない。対話しながらのAIコーディングや、AIの提案をレビューして承認する運用がこれ
Human on the loop — 人間はループの外側にいて、監視している。AIは承認を待たずに動き続け、人間は異常があったときだけ介入する
Human out of the loop — 人間はループにいない。AIだけで完結して回り続ける
右に行くほど人間の関与が減り、AIの自律性が上がる。in は密度の高い関与、on は見守り、out は完全な委任だ。
「いつか全部 out になる」わけではない
この3分類は、モデルの進化段階として語られることが多い気がする。「いまは Human in the loop だが、AIが賢くなればいずれ人間は要らなくなる」という一直線のイメージだ。
でも、Claude Codeやcodexといったコーディングエージェントに実際に仕事を任せてきた実感は違う。in → on → out は、モデルの進化ではなく、タスクごとに信頼を積んで登る階段だ。
同じプロジェクトの中でも、タスクによって立つ段は違う。エラー対応は in、定型化されたコンテンツ生成は out、というように、ひとつのプロダクトの中に3つの段が同居する。そしてそれぞれのタスクが、実績を積みながら自分のペースで階段を登っていく。
一段登って良いかの判断基準は、突き詰めると3つだと思っている。
人間の判断が不要になったか — 毎回同じ手順・同じ品質基準で完了する「定型業務」になっているか
失敗が可逆か — 間違えたときに、あとから直せるか。取り返しのつかない失敗があり得るなら人間を残す
検収を機械化できているか — 成果物の合否を、人間の目視ではなく機械的なチェックで判定できるか
3つ揃ったタスクから、ひとつ上の段へ登らせる。揃っていないのに登らせると、事故が起きるか、結局人間が毎回様子を見に行くことになって、任せた意味がなくなる。
実例: ひとつのプロダクトに3つの段が同居している
具体例を出す。私が個人開発している「AIちゃんねる」——AI住民が自律的に書き込む2ちゃんねる風の掲示板——の運用は、いまこういう配置になっている。
out of the loop にいるのは、日次のスレ作成と週次の動画投稿だ。立ち上げ期は毎回私が指示を出していたが、何十回も繰り返すうちに手順と品質基準が固まり、定期実行に切り出した。いまは私が旅行に行っていても回り続ける。
in the loop にいるのは、エラー対応だ。エラーをトリガーにAIのジョブが起動し、原因調査と対応策の提示までを自動でやってくれる。ただし、その対応策を本番に反映するかどうかは私が承認している。本番システムに触る変更は失敗の影響が読みにくく、「検収の機械化」がまだ揃っていないからだ。
on the loop にいるのが、その間の層。out に切り出した定期実行たちを、私は実行結果の通知と、状態を一覧できる画面で観測している。スレは生成されているか、動画は投稿されたか、コストが跳ねていないか。正常なら何もしない。異常のときだけループに割り込む。
同じプロダクトの中で、タスクの性質によって私の立ち位置が変わっている。プロダクト全体を一律に「AIに任せる/任せない」と決めているわけではない。
一番難しいのは、真ん中の「on the loop」
3つの中でどれが一番設計が難しいか。やってみた実感では、真ん中の on the loop だ。
in the loop は、実は一番簡単だ。人間が全部見るのだから、見落としは起きにくい。ただし人間がボトルネックになるので、スケールしない。
out of the loop は、要件が明確だ。「人間の判断が不要な定型業務」になるまで作業を磨き込めばいい。そこまで持っていくのが大変なだけで、切り出した後はシンプルに回る。
on the loop が難しいのは、「見守る」が、設計しないと成立しないからだ。異常のときだけ介入する、と口で言うのは簡単だが、そのためには「何が異常か」が定義されていて、異常が起きたら人間に届く仕組みがあり、届いたときに状況を把握できる材料が揃っていなければならない。観測の仕組みを作らずに定期実行だけを仕込むと、「見守っているつもりで、実は何も見えていない」状態になる。
私自身、定期実行を仕込んだだけの時期は安心できていなかった。実行結果が通知で流れてきて、状態を一覧で確認できる導線を作って、初めて「見なくても大丈夫、見ようと思えばすぐ見える」という状態になり、安心して任せられるようになった。out of the loop が成立するのは、その手前に on the loop の観測層があるからだ、というのがいまの実感だ。
人間の仕事は「承認者」から「設計者」へ
この階段をタスクに登らせていくと、人間の仕事の中身が変わっていく。
in the loop では、人間は承認者だ。AIの成果物をひとつずつレビューし、良し悪しを判断する
on the loop では、監視者になる。個々の成果物ではなく、ループが正常に回っているかを見る
out of the loop では、設計者の仕事が残る。ループそのものの設計、品質基準の更新、そして異常が起きたときに階段を降ろす判断だ
大事なのは、out of the loop にしても人間の仕事はゼロにならないことだ。個々の実行から人間が抜けるだけで、「このループは何のために回っていて、何が起きたら止めるべきか」を決める仕事は残る。むしろ実行を手放すほど、設計と基準づくりの重要性は上がる。
そしてこの階段は、一方通行ではない。モデルが進化すれば登れるタスクが増える一方で、プロダクトの状況が変われば——たとえばユーザーが増えて失敗の影響が大きくなれば——out にいたタスクを in に降ろす判断もあり得る。どのタスクをどの段に置くかを定期的に見直すこと自体が、AIと働く人間の中核の仕事になっていくと思う。
まとめ
Human in the loop（人が承認して進む）/ on the loop（人は監視し、異常時だけ介入）/ out of the loop（AIだけで完結）は、人間がループのどこに立つかの3分類
この3つはモデルの進化段階ではなく、タスクごとに信頼を積んで登る階段。ひとつのプロダクトの中に3つの段が同居する
一段登らせる判断基準は「人間の判断が不要になったか」「失敗が可逆か」「検収を機械化できているか」の3つ
一番設計が難しいのは真ん中の on the loop。「見守る」は、異常の定義・通知・状況把握の材料という観測の仕組みを作って初めて成立する
階段を登らせるほど、人間の仕事は承認者から監視者、設計者へ変わる。どのタスクをどの段に置くかの見直しが人間の中核の仕事になる
AIに任せるかどうかを「任せる/任せない」の二択で考えると、怖くて任せられないか、雑に任せて事故るかのどちらかになりやすい。間に段があると分かっていれば、一段ずつ登らせればいい。
あなたがいまAIと回している仕事は、in / on / out のどの段にあるでしょうか。そして、次に一段登れそうなタスクはどれでしょうか。
AIに任せる仕事と自分でやる仕事の線引きについては、こちらの記事で書いています。
https://note.com/hampen2929/n/na7455bbfebb8
タスクを任せられる形に育てていく「AIチーム」の考え方はこちらです。
https://note.com/hampen2929/n/n24133f98f089
次回は、新しいモデルが出たら最初にやること——「任せる範囲」の棚卸し——について書く予定です。AIコーディング×個人開発の実践を書いていますので、気に入ったらフォローしてもらえると嬉しいです。
