HITLが組織のボトルネックとなる
業務をAIエージェントで効率化しようという話になると、とにかく「事故らないように人間が確認できる仕組みが大事ですね」という話ばかりが出てきがちだ。部下の仕事はそんなに見てなかったはずなのに。仮にAI化を進めたところで、すべてのアウトプットを人間がレビューしていくのであればむしろ時間がかかり、組織のアジリティ(俊敏性)が失われてしまうし、結局はめくら印が横行することだろう。かといって完全にAIに任せるのも難しい。
ではLLMの側にガードレールを仕込めばいいかというと、物理的に実行不可能にしなければ安全性は確保できない。Claude Codeのようなコーディングエージェントが.envを読んでAPIキーを直接使えてしまう状態では、どんなに巧妙なプロンプトでガードレールを仕込んでも突破される可能性がある。LLMの出力を制御・検証する仕組みを構築する技術を"ハーネスエンジニアリング"と呼ぶが、これを真面目にやろうとすると、エージェントに渡す「リスク許容バジェット」を設計し、仮に.envが漏洩しても最大利用金額と可能アクションがAPI側で制限されていれば致命傷にはならないという仕組みの話になっていく。
「おまかせ」は全権委任であり、主導権はAIに移る。「おせっかい」は主導権を人間に残したまま、気づきと提案を差し挟む。
以前おせっかいなAmbient Agentについて書いたことがあるのだけど、エージェントのガバナンスにも同じ構図がある。欲しいのは「おまかせ」でも「放置」でもなく、境界線の内側では自由に動かしつつ逸脱時だけ介入する「おせっかい」型の権限委譲だ。
この境界線の理念を実現しようとして、if (budget > X && time == Y && user_role == Z && vendor_approved == true)というIF文を増やしていっても、破綻するのが目に見えているため、ポリシーを宣言的に定義していく必要が出てくるのだけど、これは結局のところ社内規定集 as a Codeになるのだと気づいた。


