エージェントを本番に載せる前に、エスカレーション先の名前を決める

本番前の打ち合わせで、スライドは整っています。

エージェントが答える。 システムを触る。 承認された操作を実行する。 必要なら人へ上げる。

最後のページで、誰かが言います。

「エスカレーションは、適宜担当者へ。」

全員うなずく。 名前は、決まっていません。

エージェントを本番に載せる前に、エスカレーション先の名前を決めてください。

条件と、セットで一行に残します。

2026年7月、Presence が示したのは「人へ上げる」前提の仕事

2026年7月22日、OpenAIは Presence を発表しました。企業向けエージェントが、回答・解決・システム利用・承認済みアクションの実行・人へのエスカレーションまで行う、という説明です。ポリシー、ガードレール、エスカレーションの仕組みがセット、と書かれています。

提供は OpenAI の Forward Deployed Engineers や選定されたシステムインテグレーター経由の限定GAで、セルフサーブではありません。

つまり、すぐ誰でも載せられる製品ではない。 その代わり、設計の話として「人へ上げる」が前面に出ています。

現場で載せる前に決めたいのも、同じです。

人へ上げる、の中身です。

「担当者へ」では、止まったあとが長い

問い合わせ対応を例にします。

エージェントが一次回答まで進める。 顧客の言い方が強い。 金額の修正を求めている。

ポリシー上、エージェント単独では進めない。

ここで「担当者へエスカレーション」とだけ書いてあると、現場ではこうなります。

誰の担当か分からない。 営業とサポートのどちらか分からない。 当番表を探す。 探しているあいだ、顧客は待つ。

待ち時間は、モデルの性能では説明できません。

エスカレーション先が名前で決まっていれば、

「金額変更・怒りの兆候 → 田中（サポートリーダー）へ。15分以内に一次返信。」

と動きます。

名前があると、探す作業が消えます。

承認境界や権限の上限とは、決める順番が違う

エージェントが単独で進めてよい範囲は、エージェントに任せる前に、承認なしで進めてよい範囲を決めるの話です。

権限の上限は、攻撃を見つけるAIが出ても、先に決めるのは権限の上限側へ回します。

こちらは、その境界を越えたとき、誰の机に載せるかです。

承認なしで進めていい、と決めたのは初回メールの下書きまで、かもしれません。

境界を越えたのは、送付済みの見積の金額変更要求、かもしれません。

境界の話と、名前の話はセットですが、同じ文書に混ぜると読まれません。

先に名前を決めるほうが、本番初日の動きは速くなります。

非同期で動くほど、引き渡し地点が見えにくい

エージェントがバックグラウンドで動くと、進捗の見え方が問題になります。

止まっているのか、進んでいるのか。

その話は、非同期・長時間エージェントは、止まっているのか進んでいるのかが見えないと側です。

こちらは、止まった・境界を越えたときの受け皿です。

進捗が見えていても、受け皿が名前でないと、結局は待ちます。

Presence の説明でも、解決とエスカレーションは並んで書かれています。

解決できる案件と、人が必要な案件を分ける設計は、名前がないと機能しません。

本番前に書く一行の型

長いマニュアルは後回しで構いません。

業務ごとに、一行ずつです。

• 「見積内容の変更要求 → 営業・佐藤。エージェントは再見積を出さない。」
• 「技術的な障害報告 → サポート・当番表のA枠。エージェントは再現手順まで。」
• 「契約条件の例外 → 法務・山田。エージェントは条文引用のみ。」

条件＋名前＋エージェントがしてはいけないこと。

これが一行に収まる粒度が、現場で使えます。

初回メール、問い合わせ、見積、社内共有——場面で名前が変わる

同じエージェントでも、エスカレーション先は一つではありません。

初回メール

エージェントが下書きまで。 顧客名の読み間違いや、約束の表現が強い。 → 担当営業・本人へ。送信は人のみ。

問い合わせ

エージェントがFAQとログ確認まで。 過去の障害と今回の症状が一致しない。 → サポートリーダーへ。顧客への追加質問は人が送る。

見積

エージェントがたたき台まで。 単価表にない品目が出た。 → 見積担当・課長へ。金額確定前に顧客へ返さない。

社内共有

エージェントが議事録要約まで。 人事・評価に触れる内容が混ざった。 → 人事部・指定窓口へ。社内掲示板へは出さない。

場面ごとに名前が違うのは自然です。

一つの「担当者へ」にまとめるほうが、あとで破綻します。

限定GAの話を、自社の全社展開の前に使う

Presence は FDE や SI 経由の限定GAです。 自社がすぐ載せられる、という意味ではありません。

それでも、設計の順番の参考にはなります。

ポリシーとガードレールとエスカレーションがセット、と発表にある。

自社で小さく試すときも、同じ順番が使えます。

いきなり全問い合わせを任せない。 一種類だけ試す。 その一種類について、エスカレーション先の名前を先に決める。

限定で試すほど、名前は具体である必要があります。

「適宜」は、限定試験では機能しません。

会議で決めるなら、15分で足りる議題

本番前の会議で長くなるのは、機能の説明です。

15分だけ、名前の議題を切り出してください。

1. 試す業務を一つ決める（例：問い合わせの一次整理）
2. エージェントが止まる条件を三つ書く（例：金額・怒り・技術未確認）
3. 各条件の受け皿を名前で書く（例：佐藤・当番A・課長）

機能の話はそのあとでよいです。

名前が決まると、デモの見方も変わります。

「上手に答えたか」より「上げる地点が正しいか」を見ます。

発表の数字を、自社の数字にしない

エンタープライズ向けの発表では、解決率や満足度の話が添えられることがあります。

自社の数字として、発表の数値をそのまま置かないでください。

まず見るのは、エスカレーション後の一次対応時間です。

名前があるかないかで、数字は変わります。

名前が決まっていれば、遅さの原因が「誰を探していたか」と分かります。

名前がなければ、モデルのせいに見えます。

本番に載せる前の最後の確認

載せる前に、次の四つだけ確認してください。

• エスカレーション先に、苗字だけでなく引き継ぎ方法まで書いたか
• 当番が変わる業務は、表ではなく名前の欄を更新する運用があるか
• エージェントが「人に上げます」と言ったあと、顧客へ何を返すか決まっているか
• 社内共有の場面で、個人情報が混ざったときの受け皿が名前で書いてあるか

四つとも、機能の話ではありません。

人の受け皿の話です。

デモ成功後に名前を決めないと起きること

デモでは、エージェントがスムーズに答えます。

本番初日、初めて境界を越えた案件が来る。

そのとき「担当者へ」しか書いていないと、成功体験が一晩で薄れます。

現場の記憶に残るのは、モデルの賢さではなく、待たされた時間です。

デモの議事録に、成功した案件だけでなく、上げた案件の受け皿名を一行足してください。

「金額変更 → 佐藤」がデモ資料にあれば、本番の初日が違います。

小さく載せるほど、名前は具体である

全問い合わせを任せない。 夜間だけ。 FAQ だけ。

小さく載せるほど、エスカレーション表は短くてよい。

短い表ほど、名前は具体でないと機能しません。

限定GAの製品を今すぐ入れる話ではなく、自社の試験範囲でも同じです。

試す範囲が小さいほど、受け皿の名前を先に決めるメリットが大きい。

エージェントを本番に載せる前に、エスカレーション先の名前を決めてください。

ポリシーより先に、一行でよいので残します。

曖昧な「担当者へ」のまま載せると、止まったあとの待ちが長くなります。

名前と条件が決まっていると、エージェントは人の時間を守る道具に近づきます。