Human-in-the-loop設計―AIエージェントに判断させる/させないの設計原則

AIエージェントに「どこまで自律判断させ、どこで人間の承認を必須にするか」は、精神論や一般的な権限モデルの図解では決まらない。商談ステージ変更や見積割引など実際のアクション単位で権限を3層に分類する。承認が必要になる条件を商談金額やSLAで数値化することが、経営層に説明できる、最も実務的な設計原則である。

この設計思想を「Human-in-the-loop設計」と呼ぶ。AIエージェントの行動を、リスクと取り消し不能性に応じて振り分ける設計を指す。実行前に人間の承認を挟むか（HITL）、自律実行を許しつつ異常時のみ人間が介入するか（HOTL）かを決める。

AI導入を推進する立場で、誤操作や暴走のリスクへの説明責任を一人で負っていると感じてはいないだろうか。「AIと人間の協業が大事」という言葉は正しいが、それだけでは商談ステージを誤って進めたエージェントの挙動を、経営会議で説明する言葉にはならない。

この課題は日本企業だけのものではない。Gartnerは2026年5月、AIエージェントを自律性のレベル別に4段階分類し、段階的なガバナンス設計を提言した。具体的には、読取専用のObserveから完全自律のAutonomousまでの区分である。同社は2027年までに、企業の40%がガバナンス不備の露呈によって自律エージェントを降格・廃止すると予測している。「とりあえず自律させてみる」という進め方自体が、すでにリスクとして認識され始めている。

なぜ「協業が大事」では止まれないのか

国内の議論はどこで止まっているのか

国内でAIエージェントの権限設計を語る記事は増えているが、多くは「人間とAIの協業が大事」という総論か、権限モデルの名称を並べる用語解説に留まる。もっとも具体化が進んでいる論考のひとつが、untype.jpの連載「AIエージェント時代の権限設計」だ。リスクカテゴリ別の承認パターンや、Rubber Stamp対策まで踏み込んでいる。しかし対象は医療・金融・ソフトウェア開発が中心で、MA/SFA/CRMの実務には触れていない。商談ステージ変更や見積割引をどう扱うかという問いは、まだ誰も具体的に答えていない。

海外ではどこまで実装が進んでいるのか

海外でも、体制づくりと実装の間には大きな溝がある。Forresterは2026年、Fortune100企業の60%がAI governance責任者を新設すると予測した。一方、自動化プラットフォームでエージェント機能を実際に有効化する組織は15%未満にとどまるとも見ている。責任者を置くことと、現場でHuman-in-the-loop設計を機能させることは、別の話だ。

経営幹部自身も、同じ壁にぶつかっている

この壁は現場担当者だけの悩みではない。Gong社が2026年1月に米英の経営幹部2,056名を対象に実施した調査がある。その結果、58%の企業でAI導入プロジェクトが停滞していた。停滞の要因はデータ・セキュリティへの懸念（34%）に次いで、説明可能性の欠如（30%）、透明性の不足（28%）が挙げられている。同社が発表した新製品は、スコープ限定アクセス・完全な監査証跡・設定可能な人間の監督を標準機能として実装した。「止められる設計」そのものが、経営層の信頼を得るための機能になり始めている。

アクションを3層に分けて権限を設計する

この3層分類は、次章で数値化するエスカレーション基準（商談金額・セグメント・SLA違反リスク）と対応している。まず、MA/SFA（Marketo・HubSpot・Salesforceなど）の実アクション単位で、権限を3つの層に分ける。以下、便宜上①自律実行可・②要承認・③人間必須と呼ぶ。

AIに任せて構わないアクションとは

基準は「実行しても影響が限定的で、後から修正できるか」である。リードスコアの再計算、行動トリガーに基づく内部通知、重複データの統合候補の提示（あくまで候補の提示までで、実際の統合・削除は行わない）などが該当する。顧客に直接触れず、取り消しも容易なため、承認を挟むコストの方が導入の障害になりやすい層だ。

承認を挟むべきアクションとは

基準は「顧客に直接触れる、または金額が動くが、取り消しは可能か」である。メールの一斉送信、商談ステージの変更、見積割引の適用がここに入る。実行しても取り消せるが、顧客体験や売上に直接影響するため、実行前に一度人の目を通す設計にする。

人間が握るべきアクションとは

基準は「取り消せない、または説明責任が個人に直接及ぶか」である。契約解除、データの削除・統合の実行がここに入る。①層の「統合候補の提示」まではAIに任せられるが、実際にデータを削除・統合する実行権限は、この層に置く。この層でAIエージェントに単独判断を許すと、誤りが起きた際に「誰が承認したか」を説明できなくなる。取り消し不能性がある限り、AIエージェントには「提案」までしか任せない。

エスカレーション基準を数値で定義する

どの条件で「要承認」が「人間必須」に格上げされるか

②の「要承認」アクションは、条件によっては③の「人間必須」へ格上げする必要がある。基準は3つ、商談金額・顧客セグメント・SLA違反リスクだ。

例えば見積割引は、通常であれば②の要承認でよい。しかし、次のいずれかに該当する場合は、承認者を増やすか③の人間必須に格上げする。案件規模が一定の基準を超える場合、エンタープライズ・セグメントの商談である場合、あるいは既にSLA違反が発生している商談である場合だ。商談ステージの変更も同様で、契約直前フェーズへの遷移は、通常のステージ変更より重く扱う。

金額・セグメント・SLA違反リスクという3条件を、承認フローの分岐条件として事前に定義しておく。そうすれば「どの案件を特別扱いするか」を、毎回人間が個別に判断する必要がなくなる。

ここで示す金額・セグメントの基準は、業種・商流・平均商談規模によって企業ごとに異なる。重要なのは具体的な閾値そのものではなく、「どの変数を使って分岐させるか」という設計の型を先に決めておくことだ。

承認を「機能させる」にはどう設計すればいいか

条件を精緻に定義しても、承認者が形だけ確認して次々と承認する「Rubber Stamp化」が起きれば、Human-in-the-loop設計は機能しない。この問題は他分野のAIエージェント権限設計でも指摘されている。untype.jpの連載では、承認件数の上限設定・時間の予算化・判断根拠情報の提示・承認者のローテーションという4つの対策が提案されている。

MA/SFAの文脈でも、この対策はそのまま応用できる。1日に処理する承認件数に上限を設け、見積割引の根拠（過去の類似商談・利益率への影響）を承認画面に自動表示し、同じ担当者が承認し続けないようローテーションを組む。

もう一つ欠かせないのが、監査ログの設計だ。前段で触れたGong社の新製品が、スコープ限定アクセス・完全な監査証跡・設定可能な人間の監督を標準機能として実装していたのは、この文脈で理解できる。誰が、いつ、どの根拠で承認したかを記録していなければ、経営会議で「なぜこの案件だけ承認を経ずに実行されたのか」と問われた際に答えられない。

認可アーキテクチャの議論だけでは経営は動かない

なぜ技術設計だけでは社内の合意が取れないのか

AIエージェントの権限設計を検討すると、多くはLayerX（法人向けSaaSを展開する企業で、AIエージェント向け認可基盤の技術検討をエンジニアブログで公開している）やAuth0（Oktaが提供する認証・認可基盤サービス）のような認可アーキテクチャの議論に行き着く。クレデンシャルの持たせ方、スコープの切り方、ログの取り方――これらはエンジニアが解くべき正しい問いだが、経営会議で語られる言葉ではない。逆に、MazricaやGENIEEのようなSFA/CRMのAI機能訴求は、効率化の話に終始する。議事録自動作成やネクストアクション推奨による「入力しないSFA」がその典型だ。しかし「どこまで任せて、どこで人間が責任を持つか」という問いには答えない。

本記事で示した3層モデルとエスカレーション基準は、この間を埋める言語になる。「リードスコア更新は自律実行、見積割引は要承認、契約解除は人間必須」という整理は、エンジニアにも、法務にも、営業責任者にも共通して伝わる。技術設計の前に、まずこの合意を社内で取っておく必要がある。

この設計を実践しようとすると、何にぶつかるのか

しかし、この3層モデルを実際に運用しようとすると、多くの企業が同じ壁にぶつかる。商談ステージや見積割引の履歴に、承認の判断根拠となる金額・セグメント・SLA状態が紐づいて記録されているか。MA・SFA・CRMをまたいで、誰が何を承認したかを一貫して追跡できる監査ログが存在するか。

答えが「ない」であれば、3層モデルは紙の上の設計に留まり、AIエージェントの運用を任せられる基盤にはならない。Human-in-the-loop設計は、権限の話である前に、データ構造の話でもある。

まとめ

Q1. Human-in-the-loop設計とは何か？ A. 取り消せない操作の前に人の承認を挟むか（HITL）、動かしながら異常時だけ介入するか（HOTL）を、リスクの大きさで選ぶ設計を指す。精神論ではなく、実アクション単位の分岐ロジックとして定義する。

Q2. AIエージェントにどこまで任せてよいか？ A. 「実行しても影響が限定的で、修正可能か」を基準に、自律実行可・要承認・人間必須の3層に分ける。リードスコア更新は任せられるが、契約解除やデータの削除・統合の実行は人間が握る。

Q3. 承認基準の「数値化」とは、具体的な金額を決めることか？ A. 違う。金額そのものより、商談金額・セグメント・SLA違反リスクという変数を使って承認レベルを分岐させる設計の型を先に決めることを指す。閾値は業種・商流によって企業ごとに異なる。

Q4. 承認フローを用意すれば十分か？ A. 不十分。承認件数の上限設定・時間の予算化・判断根拠の提示・承認者のローテーションがなければ、確認は形だけの「Rubber Stamp」になる。その結果、設計は機能しなくなる。

Q5. この設計を導入する前に、何を確認すべきか？ A. 3層モデルを運用する前提として、商談・承認の判断根拠となるデータが記録され、MA・SFA・CRMをまたいで監査ログを追跡できるかどうかだ。ここが欠けていれば、権限設計は紙の上で終わる。