サービス内容AIエージェント群料金FAQコラム
IntelligentSales無料で相談する
設計・構築

AIエージェントから人へどう引き継ぐ?——ヒューマン・ハンドオフ(エスカレーション)の設計

公開日: 2026.09.02 執筆: 株式会社DeploAI

\ AI導入を、実装から成果まで伴走 / 「DeploAI FDE」に無料で相談する

「AIエージェントに顧客対応を任せたら、答えられない質問に無理やり答えて、かえって話がこじれた」「難しい案件で、エージェントが黙って止まり、顧客が放置された」——AIエージェントを業務に載せると、こうした“引き継ぎ”の問題に必ず突き当たります。原因は、エージェントの能力不足そのものより、限界に達したときに人へ渡す設計がないことにあります。ここで鍵になるのが ヒューマン・ハンドオフ(人への引き継ぎ) です。結論から言うと、ヒューマン・ハンドオフとは、AIエージェントが自力で対応しきれない場面で、それまでの経緯(文脈)とともに人へ引き継ぐことで、自信が持てない・権限の外・機微・高リスクといった場面で、無理に自動対応を続けず人へきれいに渡す——この設計が、安心して使えるエージェント運用の要になります。

この記事では、ハンドオフとは何か、なぜ必要か、いつ引き継ぐか、良い引き継ぎの条件、Human-in-the-Loopとの違い、導入の勘所を解説します(人の関わりの設計はHuman-in-the-Loop、顧客対応での活用はカスタマーサポートのAI活用、安全の担保はAIエージェントのセキュリティも参照)。

ヒューマン・ハンドオフとは?——エージェントから人へ引き継ぐ

ハンドオフは、エージェントが自力で対応しきれない場面を検知し、文脈ごと人へ渡す仕組みです。 まず全体像を押さえます。

1エージェントが対応得意な範囲は自動で処理する
2トリガーを検知自信が低い・権限外・機微 などを判定
3人へ引き継ぐ(文脈つき)経緯の要約を渡し、担当者が続きから対応

ハンドオフは「対応→トリガー検知→文脈ごと人へ」。黙って止まるのでも、無理に続けるのでもなく、渡す。

エージェントは、得意な範囲では速く正確に働きます。しかし、答えられない質問や、権限の外の判断、機微な場面もあります。ハンドオフは、そこを検知して、それまでのやりとりや状況の要約とともに、人(担当者)へ引き継ぐ仕組みです。ポイントは、黙って止まるのでも、無理に自動対応を続けるのでもなく、きれいに渡すことです。これがあると、エージェントの守備範囲は任せつつ、難しいところは人が受けられます。

なぜヒューマン・ハンドオフの設計が必要なのか?

エージェントには必ず限界があり、それを無視した自動対応は、かえって信頼を損ねるからです。 ここが必要性の核心です。

限界を無視して自動対応を続けると、間違った回答・権限外の判断・機微な場面での機械的な対応が起きます。とくに顧客対応では、これは一発で信頼を失いかねません。かといって、限界に達したときに黙って止まれば、利用者は放置されます。どちらも避けたい。

だからこそ、「ここから先は人へ渡す」という設計が要ります。ハンドオフは、エージェントの弱点をさらす後ろ向きの仕組みではありません。むしろ、難しいところは人が受けられると分かっているからこそ、得意な範囲を安心してエージェントに任せられる——自動化を広げるための土台です。

いつ人へ引き継ぐのか?——ハンドオフのトリガー

鍵は、「どうなったら人へ渡すか」をあらかじめトリガーとして定義しておくことです。 代表的なトリガーを整理します。

トリガー どんなときか
自信が低い エージェントの確信度が低く、誤答の恐れがある
権限・範囲外 対応してよい範囲や権限を超える依頼
機微・苦情 クレームや、感情・センシティブな状況が関わる
高リスク・不可逆 取り返しのつかない判断・操作を伴う
明示的な要望 利用者が「人と話したい」と明確に求めた
繰り返し失敗 同じ問題で何度も解決に至らない

ポイントは、これらをあいまいにせず、判定できる形で決めておくことです。とくに効くのは、自信が低いとき機微・苦情のときの線引きです。確信のない回答を無理に返さない、感情が関わる場面は人が受ける——この2つを押さえるだけで、事故の多くは防げます。高リスク・不可逆な操作は、そもそも人の承認を挟む設計(Human-in-the-Loop)と組み合わせます。

良いヒューマン・ハンドオフの条件——文脈を引き継ぐ

いちばん重要なのは、「文脈を引き継ぐ」ことです。 ここが、良い引き継ぎと悪い引き継ぎを分けます。

人へ渡すときに、それまでのやりとりや状況の要約を一緒に渡せば、担当者は一から聞き直さずに済み、利用者も同じ説明を繰り返さずに済みます。逆に、文脈なしで「担当者におつなぎします」だけで放り投げると、利用者は最初から説明し直すことになり、かえって不満が募ります。せっかくのハンドオフが逆効果になるのです。

良いハンドオフの条件は、文脈の引き継ぎに加えて次の3つです。①利用者に見通しを伝える(「担当者におつなぎします」と一言添える)、②適切な担当・窓口に振り分ける(誰が受けるべきかを判断する)、③引き継いだ事例を記録して改善に活かす(どこで人が必要になったかを次の改善へ)。この記録は、エージェントの守備範囲を少しずつ広げる材料にもなります。

Human-in-the-Loop(HITL)との違い

ハンドオフとHITLは近いですが、「人がどう関わるか」が違います。 混同しやすいので整理します。

  • Human-in-the-Loop(HITL):処理の流れの中に人が入り、承認・確認・介在する。エージェントは動き続け、要所で人がチェックする(詳しくはHuman-in-the-Loopを参照)
  • ヒューマン・ハンドオフ:エージェントが限界に達したとき、対応そのものを人へ渡す。そこから先は人が主役になる

一言でいえば、HITLは「流れの中で人が確認する」、ハンドオフは「限界で人へバトンを渡す」。両者は排他ではなく、組み合わせて使います。高リスクな操作はHITLで承認を挟み、対応しきれない場面はハンドオフで人へ渡す——という具合です。

具体例:カスタマーサポートのエージェントで引き継ぐ

抽象的なので、あるカスタマーサポートのエージェントを例にします(状況はすべて説明用の仮の例です)。

問い合わせに一次対応するエージェントが、対応しきれない問い合わせに直面する場面です。ハンドオフの設計がない場合とある場合を比べます。

状況 設計なし 設計あり
答えられない質問 無理に推測で回答し、誤案内 自信が低いと判定し、経緯つきで人へ引き継ぎ
強い苦情 機械的な定型返答で、相手を怒らせる 機微と判定し、担当者へエスカレーション
引き継ぎの体験 (引き継げず)顧客が放置される 「担当者におつなぎします」+要約で、続きから対応

ポイントは、エージェントが「できること」と「人へ渡すこと」を、あらかじめ線引きしていることです。定型的な問い合わせはエージェントが即応し、確信のない質問や苦情は人へきれいに渡す。こうすると、自動化で件数をさばきつつ、難しい対応の品質も守れます。逆に線引きがないと、エージェントが無理をして事故を起こすか、黙って止まって顧客を放置するか——どちらかになりがちです。

ヒューマン・ハンドオフ導入の勘所と注意点

鍵は、「どこまで任せ、どこから渡すか」を業務に合わせて決め、文脈と改善のループまで設計することです。 勘所を整理します。

  1. トリガーを具体的に決める:自信の低さ・権限外・機微など、人へ渡す条件を判定できる形で定義する。あいまいだと、渡すべき場面で渡せない
  2. 文脈を必ず引き継ぐ:やりとりの要約を人に渡す。利用者に同じ説明を繰り返させない設計にする
  3. 引き継ぎを改善に回す:どこで人が必要になったかを記録し、エージェントの守備範囲や案内を改善する。ハンドオフを“作りっぱなし”にしない

難しいのは、任せる範囲と渡す範囲の線引きを、業務の実態に合わせて決めることです。渡しすぎれば自動化の効果が薄れ、渡さなすぎれば事故が起きる。この線引きは一度で完璧にはならず、運用しながら、引き継ぎの記録をもとに調整し続けるもの。ここを設計できるかが、安心して使えるエージェント運用の分かれ目になります。

DeploAIのFDEはヒューマン・ハンドオフの設計をどう支援するか

DeploAI の FDE(Forward Deployed Engineer)は、「どこまで任せ、どこから人へ渡すか」から、文脈の引き継ぎと改善のループまでを現場で組み立てます。

エージェントを安心して業務に載せる難所は、賢さより「限界に達したときに、人へきれいに渡す設計」にあります。FDE は、ハンドオフのトリガー定義、文脈を引き継ぐ仕組み、担当・窓口への振り分け、Human-in-the-Loopとの組み合わせ、引き継ぎ事例を改善に回す流れまでを、業務に合わせて実装します。ハンドオフを「弱点」ではなく「自動化を安心して広げる土台」として設計し、人とエージェントの役割分担を運用まで定着させるのが特徴です。

まとめ

  • ヒューマン・ハンドオフとは、エージェントが対応しきれない場面で、文脈ごと人へ引き継ぐこと。黙って止まるのでも無理に続けるのでもなく、きれいに渡す。
  • 必要なのは、エージェントに限界があり、無視した自動対応はかえって信頼を損ねるから。渡す設計があるから、得意な範囲を安心して任せられる。
  • 引き継ぐトリガーは、自信が低い・権限外・機微・高リスク・明示的な要望・繰り返し失敗。判定できる形で定義する。
  • 良い引き継ぎの条件は、文脈を引き継ぐ・見通しを伝える・適切に振り分ける・記録して改善すること。
  • HITL=流れの中で人が確認/ハンドオフ=限界で人へ渡す。組み合わせて使う。DeploAI の FDE が、線引きから運用の定着まで伴走する。

AIエージェントを安心して業務に載せたい方は、Human-in-the-Loopで人の関わりの設計を、カスタマーサポートのAI活用で顧客対応での使い方を確認してみてください。導入のご相談はお問い合わせから承っています。

関連記事:AIエージェントを業務に組み込むには?(Human-in-the-Loop)カスタマーサポート(CS)のAI活用AIエージェントのセキュリティAIエージェントのオブザーバビリティとは?

よくある質問

ヒューマン・ハンドオフ(人への引き継ぎ)とは何ですか?
AIエージェントが自力で対応しきれない場面で、その対応を人(担当者)に引き継ぐことです。エスカレーションとも呼ばれます。エージェントには、答えられない質問、権限の外の判断、機微な状況などの限界があります。そこで無理に自動対応を続けず、適切なタイミングで、それまでの経緯(文脈)とともに人へ渡す——この設計が、安心して使えるエージェント運用の要になります。
なぜヒューマン・ハンドオフの設計が必要なのですか?
エージェントに限界があるからです。限界を無視して自動対応を続けると、間違った回答をしたり、権限外の判断をしたり、機微な場面で機械的な対応をして、かえって信頼を損ねます。かといって、限界に達したときに黙って止まると、利用者は放置されます。人へきれいに引き継ぐ設計があれば、エージェントの得意な範囲は任せつつ、難しいところは人が受けられ、全体の体験と信頼が保てます。
どんなときに人へ引き継ぐべきですか?
代表的なのは、(1)エージェントの自信(確信度)が低いとき、(2)権限や対応範囲の外のとき、(3)クレームや機微な感情が関わるとき、(4)高リスク・取り返しのつかない判断のとき、(5)利用者が人との対応を明確に求めたとき、(6)同じ問題で繰り返し解決できないとき、です。これらをトリガーとして定義し、達したら自動的に人へ引き継ぐように設計します。
良いヒューマン・ハンドオフの条件は何ですか?
いちばん重要なのは「文脈を引き継ぐ」ことです。人に渡すとき、それまでのやりとりや状況の要約を一緒に渡せば、担当者は一から聞き直さずに済み、利用者も同じ説明を繰り返さずに済みます。加えて、利用者に「担当者におつなぎします」と見通しを伝える、適切な担当・窓口に振り分ける、引き継いだ事例を記録して改善に活かす、といった設計が良いハンドオフの条件です。
DeploAIのFDEはヒューマン・ハンドオフの設計を支援しますか?
はい。DeploAI の FDE(Forward Deployed Engineer)は、どこまでをエージェントに任せ、どこから人へ引き継ぐか(トリガー)を業務に合わせて定義し、文脈を引き継ぐ仕組み、担当・窓口への振り分け、引き継ぎ事例を改善に回す流れまでを設計・実装します。ハンドオフは、エージェントの弱点ではなく、安心して自動化を広げるための土台です。人とエージェントの役割分担を現場で組み立て、運用まで定着させます。

執筆・編集

DeploAI FDE コラム編集部

事業を理解したエンジニアが現場で伴走する FDE(Forward Deployed Engineer)サービスを提供する株式会社DeploAI のコラム編集部です。AI導入の進め方・組織づくり・業務別ユースケースなど、実践に役立つ情報をお届けします。

FDE のサービス内容はこちら →

この記事のテーマについて、相談してみませんか?

DeploAI の FDE は、フロント部門の AI 化を「実装」から「成果が出るまで」伴走します。課題の整理だけでも、お気軽にどうぞ。