ワークフローの最後に、チェックボックスがある。
AIが生成した文書。自動化されたリスク判定。エージェントが提案した次のアクション。それらが画面に並び、最後に人間が「承認」を押す。ログには担当者の名前が残る。監査のとき、その名前が「判断した人」として参照される。
多くの組織で、この仕組みは疑われていない。むしろ、これがあるから安全だと信じられている。
Human-in-the-Loop という安心装置
HITL（Human-in-the-Loop）は、AIシステムにおけるガバナンスの基本形とされてきた。その構造はシンプルだ。AIが出力し、人間がレビューし、承認する。最終判断は常に人間の手にある。
この構造が広く受け入れられてきた理由は明確だ。
まず、人間が判断するという事実そのものが安心感をもたらす。どれだけ高度なモデルが動いていても、最後に人間の目が入るなら、致命的なミスは防げるはずだ——そう考えるのは自然なことだ。
次に、レビューという制度が存在すること自体が、組織に安定をもたらす。承認フローがある。チェックリストがある。記録が残る。制度として成立しているという感覚が、ガバナンスの実質を支えているように見える。
そして、責任の所在が明確になるという期待がある。承認者の名前がログに刻まれる以上、その判断には責任が伴う。責任が特定の個人に帰属するという構造は、組織にとって管理可能なかたちに見える。
安心感、制度的安定、責任の帰属。この三つが揃うとき、HITLは十分に機能しているように映る。
見えにくい構造的限界
しかし、この構造にはいくつかの前提がある。そして、その前提が静かに崩れ始めている。
**能力の非対称性：**AIが処理する情報の規模と速度は、人間の認知能力をすでに超えている。数百ページの契約書を数秒で分析するモデルの出力を、人間が同等の精度でレビューすることは物理的に困難だ。レビューは行われる。しかし、レビューの深度がAIの処理深度に追いつかないとき、承認は「内容の検証」ではなく「手続きの完了」になる。承認者は何かを判断しているのではなく、承認という行為を遂行している。
**生産性との緊張：**AIの導入目的の一つは、業務の高速化だ。しかしHITLは、その速度にブレーキをかける構造でもある。すべてのAI出力に人間のレビューを挟めば、処理速度はレビュー速度に律速される。組織はやがて選択を迫られる。レビューの質を維持して速度を犠牲にするか、速度を優先してレビューを形骸化させるか。多くの場合、後者が静かに進行する。
**責任の個人集中：**承認者の名前がログに残るという事実は、一見すると責任構造の明確化に見える。しかし実態はどうか。承認者がAIの出力を実質的に検証できない状況で、承認のログだけが残るとき、そこにあるのは「責任の明確化」ではなく「責任の押しつけ」だ。判断の権限を持たない人間に、判断の責任だけが集中する。この構造は、ガバナンスではない。
三つの問題は独立しているように見えるが、根は同じだ。HITLが前提としていた「人間のレビューが実質的に機能する」という条件が、AIの能力向上とともに成立しにくくなっている。
エージェントの時代が問いを加速させる
この問題は、AIエージェントの登場によってさらに加速する。
従来のAIは、人間の指示を受けて一つのタスクを処理し、結果を返すものだった。エージェントは違う。目標を与えられると、自ら計画を立て、複数のステップを実行し、途中で判断を行いながら結果に到達する。その過程で行われる判断の数は、従来のAI出力とは桁が異なる。
エージェントの各ステップにHITLを適用すれば、エージェントの意味がなくなる。自律的に動くために設計されたシステムに、すべての判断で人間の承認を求めれば、それはもはや自律ではない。
では、最終結果だけをレビューすればよいのか。これはHuman-on-the-Loop（HOTL）と呼ばれる考え方だ。人間はループの中ではなく、ループの上にいる。常時監視はしないが、異常があれば介入する。
HOTLは現実的な妥協に見える。しかし、ここにも同じ問いが残る。エージェントが自律的に実行した数十のステップを、最終結果だけ見て適切に評価できるのか。途中の判断が見えない状態で、結果の妥当性をどう検証するのか。
HITLでは足りない。HOTLでも十分ではない。問題は「人間をどこに配置するか」ではなく、もっと手前にある。
問いの転換
ここまでの議論が示しているのは、HITLという構造そのものの欠陥ではない。HITLが答えようとしている問いの立て方に、限界があるということだ。
「人間はどこでAIを監視すべきか」——この問いは、人間の配置を最適化しようとしている。しかし本当に設計すべきなのは、配置ではない。
何を人間が判断し、何をAIに委ね、何をエージェントに任せるのか。その境界そのものを、意図的に設計すること。
それが Decision Design（判断の設計） である。
Decision Designは、判断という行為そのものを設計対象とする思想だ。
その中心にあるのが Decision Boundary（判断の境界） という概念である。誰が決めるのか。どこまでを任せ、どこからを引き受けるのか。その線を、無自覚のまま放置せず、意図的に設計すること。それがDecision Designである。
承認ボタンの位置を変えても、問題は解決しない。問題は、承認という行為が何を意味しているのかが設計されていないことにある。
ここから先では、Decision Designの具体的な構造——三層モデル、Decision Boundaryの実装方法、そしてこの概念が既存のガバナンスフレームワークとどう異なるのかを展開する。
詳細版について
本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。