ヒューマンインターベンションレート：AI導入が本当に機能しているかを示す唯一の指標

本番でAIエージェントを動かしている企業のほとんどは、そのエージェントが実際にどのくらい人の手を必要とするのか答えられません。ヒューマンインターベンションレートは、その問いに答える数字です。この記事を読み終えるころには、すでに回しているワークフローの一つについて、自分で計算できるようになっているはずです。

FabricLoopがAI組織のために置いている枠組みは、ヒューマンインターベンションレートをはっきり定義しています。自動化された作業が、どのくらいの頻度で人を必要とするか。それが定義であり、この記事もそこから外れません。ここから先は、概念ページが最後まで書き切っていない部分です。実際の計算を、一つの本物のワークフローに当てはめ、理念ではなく具体的な数字にします。

この数字が実際に測っているもの

ヒューマンインターベンションレート（HIR）は、定義された一つのワークフローと一つの期間のなかで、エージェントの行動のうち、結果を完成と見なせる前に人が介入しなければならなかった割合です。ここでの「介入」にははっきりした意味があります。人が出力を直した、エージェントの判断を覆した、あるいは先に進む前にエージェントが明示的に出した問いに人が答えた、ということです。FabricLoopのLoop Agentがask_humanの瞬間と呼ぶものです。その行動の件数を、同じ期間にエージェントが取った行動の総数で割ると、HIRになります。

この指標が稼働率や精度の下ではなく横に並ぶ理由は、それらの数字には見えないものを測るからです。社内ベンチマークで精度95%を出していても、間違う5%が黙って通り、自信のない20%は毎回フラグが立つ別のエージェントより、導入としては悪いことがあります。HIRはエージェントが上手かどうかを問いません。人が必要なときをシステムが知っているか、そして必要なときに人が実際に現れるかを問います。展開してよいかを決めるのは、後者の問いです。

一つの本物のワークフローでHIRを計算する

ITや運用のチームが今日実際に回しうるワークフローを考えてみてください。届いたサポートチケットを仕分けし、分類し（請求、不具合報告、返金、アカウントアクセスなど）、一次返信の下書きを作るエージェントです。下書きはすべて、顧客に届く前にレビュー待ちに入ります。勝手に送信されるものはありません。このレビューの手順そのものは介入ではありません。変更の必要がなかった下書きでレビュー担当が「送信」を押すのは、設計どおりにワークフローが動いている状態です。介入は、下書きに手が必要だったときに起きます。書き直した、分類を直した、別のキューへ回した、あるいはエージェント自身が作業の途中で止まり、何も書く前に質問した、といった場合です。

以下の数字は説明のための例であり、実在の企業のデータではありません。ただし話の形と、その背後の計算は、自社のログから組むものとまったく同じです。

パイロット月に、エージェントは640件のチケットに触れます。そのうち415件が介入を必要とします。書き直し、再分類、あるいは別ルートへの回送です。その415件のうち、何かを書く前にエージェント自身がフラグを立てたのは75件だけです。残りは、あとからレビュー担当が見つける誤りです。HIRは64.8%、エスカレーション比率はわずか18%です。間違っているときの大半で、エージェントは自信を持って間違っています。この問題のいちばん悪い形です。

チームは修正ログを引き、介入の一件ずつに理由を付けます。目立つのは二つの分類です。金額が絡むと返金ポリシーを読み違えること、そして明らかに怒っている顧客に、落ち着いた手続き的な返信を書いてしまうことです。どちらもモデルに触れずに直せます。返金が50ドルを超える、あるいは感情のしきい値を超えるチケットは、下書きではなくask_humanのエスカレーションを起こす、という明示的なルールを足します。それ以外は、これまでどおり下書きしてレビューします。

3か月目までにHIRは80%以上下がります。ただし、より多くを教えてくれるのはエスカレーション比率です。18%から79%へ上がっています。残っているものの大半は、エージェントが間違いを見つかることではありません。本当に曖昧なケース（VIPアカウント、ポリシーの例外、しきい値ぴったりでの返金）を正しく見分け、動く前に聞いていることです。低下は本物で、稼いだものです。修正のたびに理由が明示的なルールへ戻り、それを生んだ具体的な誤りは繰り返さなくなります。一方、まだ判断が必要な分類は、下書きで回避せずフラグが立ち続けます。

誤り：ゼロをゴールにすること

HIRが月ごとに下がるのを見始めると、次の問いは当然のように見えます。どこまで下げられるか。ゼロをゴールラインにし、エージェントがついに無人で回せるほど良くなった証拠だと扱いたくなります。その直感は逆です。そして、この指標のいちばん多い読み違いです。

本当のゴールは、抽象的に介入を減らすことではありませんでした。人の判断が必要な特定の瞬間だけが表面に出る仕組みです。そうすれば、人の注意は本当に必要なところへ向かい、すべてに均等に割かれたり、まったく届かなかったりしません。HIR 12%で、その12%のほぼすべてが、本当に曖昧な、あるいは賭けの大きいケースをエージェントが正しくフラグしているなら、HIR 2%で、その2%の大半が、エージェントが一度も示さなかった誤りにレビュー担当がたまたまぶつかっている状態より健全です。低い数字のほうが、悪い仕組みを隠しえます。

エスカレーション比率は、まさにそのためです。HIRと並べて見ると、自分がどの話のなかにいるかが分かります。

HIRが下がり、エスカレーション比率が横ばいか低下しているなら、まだ勝ちとして片付けないでください。「介入不要」と記録された行動を無作為に抜き、きれいだと印が付いていたことは伝えずに、誰かに白紙で見直してもらいます。同時に、下流の信号——再オープンしたチケット、苦情、返金の取り戻し、CSAT——が上にずれていないかも見ます。HIRが下がり、下流の問題が上がっているのは、より速く学んだ仕組みではありません。誰も間に合わなかった仕組みです。

今日これを測るなら、何を計装するか

これに必要なのは新しい道具というより、正しいものを記録することです。エージェントを回しているチームの多くは、すでに量を追っています。何件のチケットに触れたか、何件のタスクを下書きしたか。結果を追っているチームはほとんどありません。HIRが実際に必要とするのは、結果だけです。

1. 活動の件数だけでなく、行動ごとに結果を記録する。 そのまま送信、送信前に編集、却下して書き直し、あるいはエージェント自身がエスカレーション。結果レベルの記録がなければ、HIRは計算できません。エージェントが何かをしたことは分かっても、直す必要があったかは分かりません。
2. 分子を直す前に、分母を固定する。 このワークフローで一つの行動とは何かを決めます。触れたチケット一件、下書きしたタスク一件。期間をまたいでその定義を動かさないようにします。HIRの変化が、数え方の変化ではなく、エージェントの判断を映すようにするためです。
3. 介入の一件ずつに理由を付ける。 「編集した」はほとんど何も言いません。「編集した：50ドル超で返金ポリシーを誤適用」は、次に何を直すかを正確に言います。短く一貫した分類は、修正ログをスコアボードではなく作業リストに変えます。
4. HIRの代わりではなく、HIRと並べてエスカレーション比率を追う。 二つの数字がそろって、低下が稼いだものか借りたものかを教えます。上の傾向の表を見てください。
5. ゼロを目標にせず、下限を置く。 ワークフローごとに、その中にある本当の曖昧さから見て、ゼロでない妥当なHIRがどの程度かを決めます。その下限を大きく下回る率は、祝うものではなく、調べるものとして扱います。
6. HIRはワークフローごとに報告し、会社全体を混ぜた一つの数字にはしない。 一つの平均は、どのワークフローが本当に監視を減らせたのか、どのワークフローが見栄えのよい見出し数字の下で静かにリスクを積み上げているのかを隠します。
7. 「きれい」なサンプルを予定どおり再確認する。 介入不要と記録された行動を定期的に抜き、きれいだと印が付いていたことを知らない人に見直してもらいます。レビュー担当がまだ読んでいるかを直接確かめる、唯一の方法です。