Human on the Loop
Standing Outside the Loop, Not Inside It
AIに仕事を任せるとき、多くの組織は「1手ごとに人が承認する」やり方から始めます。安全ですが、 人が律速になってAIの速度が死にます。human on the loop は、人がループの外側に立ち、 設計・監視・停止・軌道修正だけを担うかたちです。SOUZOUDOが自社の実務で使っている考え方を、そのまま公開します。
The Difference
どちらが正しいという話ではありません。扱っている作業のリスクに対して、どちらが釣り合うかという話です。
Human in the Loop
AIが1手動くたびに、人が内容を見て承認する。判断は常に人が持っているので、 間違った出力がそのまま外に出ることはありません。
安全。ただし人の可処分時間が上限になる。
Human on the Loop
AIが一周を最後まで回し、人は止める・差し戻す・承認するだけを担う。 人は個々の手ではなく、ループそのものを見ます。
速い。ただし境界が緩いと事故る。
Why It Matters
「念のため全部確認する」は、一見すると安全側の判断です。ところが確認の対象が1日に何十件も出てくるようになると、 確認そのものが仕事になります。承認待ちの列が伸び、AIは止まったまま待ち、人は判断の中身ではなく件数に押されるようになる。
減らしていいのは、取り消しがきく行為だけです。 社内で完結して、あとから戻せることまで毎回確認していると、本当に止めるべき場面での判断が鈍ります。 逆に、外部に届いてしまうもの・戻せないものは、何回聞かれても人が押すべきです。
human on the loop は「AIを賢くすること」で成り立つのではありません。 人が見ていなくても壊れない構造を、ループの内側に埋め込むことで成り立ちます。
Four Conditions
どれか1つでも欠けると、on the loop は「見ていないだけ」になります。
「これはやらない」をルールとして書くだけでは足りません。書いたものは忘れられます。 触ってはいけない対象に手が伸びた時点で、仕組みの側が止める必要があります。
何が起きたかを知るのに、やり取りを最初から読み返さないといけないなら、それは一望できていません。 いつ・どこで・何をして・何が残ったのかが、1行で追える形になっていること。
異常に気づいてから止め方を探しているようでは間に合いません。 止めるための手順が1つに決まっていて、迷わず押せること。止めても調査は続けられること。
試行回数・時間・件数・コスト。上限を先に決めておかないと、AIは失敗したまま回り続けます。 上限に当たったら勝手に方針を変えず、止まって現状を報告する。ここまで含めて設計です。
Blast Radius
すべての行動を、2つの軸で分けます。「戻せるか」と「外に出るか」。 迷ったときは重い側に倒す。この表があるだけで、確認の回数は大きく減ります。
| 内部で完結する | 外部に出る／他人に届く | |
|---|---|---|
| 戻せる | 自走してよい 調査・分析・下書き・試行。報告だけ受け取る。 | 下書きで止める 作るところまでAI。送信・投稿は人が押す。 |
| 戻せない | 控えを取ってから 上書き・削除の前に、戻し方を先に用意する。 | 必ず止まって確認 公開・送金・契約・顧客データ。例外なく人の判断。 |
Draft First
いちばん効くのはこの1つです。作る作業はAIに渡し、確定のボタンだけを人の手元に残す。 人はループの外から「確定」を押すだけになります。
下書きとして保存する。送信はしない。
Web / EC
非公開のまま登録する。公開ボタンは人が押す。
Code
作業ブランチで進める。本番には直接入れない。
Documents
上書きせず新版を作り、差分を示す。
Bulk
まず1件だけ試し、結果を見せてから残りを回す。
Anything
試し実行できるものは、必ず先に試し実行する。
The Design Sheet
ループを回し始める前に、この8つを先に決めて人に見せます。 埋まらない欄があるなら、それが人に聞くべき唯一の質問です。 逆に言えば、ここが埋まっていれば他は聞かずに進められます。
シートが埋まったら、必ず1件だけ実行して結果を見せます。ここが最大のチェックポイントです。 承認が出てから残りを回す。100件を一気に回して100件間違えるのが、いちばん高くつきます。
The Cycle
4つのうちどれが欠けても、on the loop は成立しません。 とくに落ちやすいのは3番目です。
Step 01
何を・どこまで・どう終わらせるかを先に3行で示す。長い計画書は要らない。ここが人の入口チェックポイントになる。
Step 02
宣言した範囲だけをやる。勝手に広げない、勝手に縮めない。範囲外の問題を見つけたら、直さずに記録して報告に載せる。
Step 03
自分の成果物を自分で確かめる。テストを回す、実際に開く、数字を再計算する、送る前に読み返す。「たぶん動く」は検証ではない。
Step 04
やったこと・やらなかったこと・詰まったこと・次の一手。成功だけを報告しない。
同じ確認を3回求められたら、それはルールにすべきサインです。同じミスを2回したら、それは仕組みに書き戻すべきサインです。 ループエンジニアリングは一度きりの設計ではなく、回しながら締めていく作業になります。
Guardrails
「やってはいけない」を一律に禁止すると、正当な作業まで止まって、最後にはガードごと外されます。 止める強さを3段階に分けるのが実務的です。
認証情報など、AIが書き換える理由が存在しない対象。承認の余地を作らず、その場で拒否します。
ここが設計の中心です。権限を持つ人が見ているときは承認して進められる。 一方、無人で走っているループには答える人がいないので、そこで必ず止まります。 同じ1つのルールが、人がいるかどうかで自動的に振る舞いを変えます。
止めるほどではないが、あとで人が見たい領域。作業は進めつつ「これは要確認です」と明示させ、 確定の手前で人の目に入るようにします。
ガードを足すときは、通すべき入力が通ることを先に確かめてください。 止めるべきものを止められるかより、こちらの方が重要です。誤検知するガードは邪魔者になり、いずれ外されて意味を失います。
Reporting
人が全部を見ないで済むのは、報告が信用できるときだけです。 毎回この4つで返すと決めておくと、読む側は数十秒で状況を掴めます。
推測と事実を混ぜないこと。長さより情報密度。 この型が崩れた瞬間、人は全部を自分で見に行くしかなくなり、on the loop は終わります。
Honestly
できることだけを並べた説明は、導入したあとで裏切ります。先に限界を書いておきます。
仕組みで止められるのは、仕組みを通った操作だけ
ガードは、AIがその経路を通ったときにしか効きません。人が手で直接操作すれば通ります。 本当に塞ぐなら、サービス側の権限設定など、経路の外側にも手を打つ必要があります。
無人で走るループは、承認を求められた時点で止まる
答える人がいないからです。これは仕様どおりの挙動ですが、 「なぜ進んでいないのか」が記録を見ないと分からないという別の問題を生みます。
報告が信用できなくなった時点で、全部が崩れる
人が全部を見ないで済むのは、報告が正確なときだけです。 成功だけを報告する運用は、on the loop を成立させません。 失敗・スキップ・未確認を明示することが、速度を出すための条件になります。
一度きりの設計では終わらない
同じ確認を3回求められたら、それはルールにすべきサインです。 同じ失敗を2回したら、それは仕組みに書き戻すべきサインです。 回しながら締めていく作業になります。