「二重請求」の電話1本で、Presenceの動きを見る

製品能力は汎用です。職務ごとにAgentを配備し、システム接続、ポリシー遵守、業務実行、有人転送ができます。説明のため、製品UIのイメージ事例を最初から最後までたどります。職務はサポート、チャネルは電話とテキスト。架空ECのSwiftcartで、顧客はサブスクが2回引き落とされたと訴えます。聞き取りから返金まで、Presenceが実セッションで何の能力に頼るかを順に見ます。

イメージUI：左は電話（波形＋逐語ログ）。顧客は2回引き落とされたと話し、Agentは口座確認後に返金へ。右はテキストチャット。顧客が注文状況を尋ねると、Agentが「注文状況照会」を呼び、特定済みの請求書カードを出します。同じ能力を、音声でもテキストでも使えます。

Presenceに載っている部品

上の返金電話を分解すると、部品が揃います。同じ部品セットは他の職務にも載せられます。請求サポート、保険金、社内ITヘルプ——ポリシー雛形と評価方式は共有し、権限と実行可能アクションは職務ごとに変えます。事例はサポートですが、製品はサポート限定ではありません。

返金ポリシー変更：まずシミュ、次にCodexが提案

先のサポート事例の続きです。会社が「年度返金ルール」を変えたとします。重複サブスクの扱い、暴言を危機案件とみなすかなど、更新が必要です。Presenceは、電話応対中のAgentへ変更をそのまま流し込みません。

まずシミュレーションです。偽だが実戦に近いリクエスト群を押し込みます。採点器（grader）がグループごとの合否、結果の正しさ、違反の有無、ツール使用の適切さ、有人転送の要否を見ます。

イメージ：ポリシーを「新年度返金ルール」に変えたあと、ガードレール・返金・解約・メールとOTP検証などのグループでシミュを実行。図では各グループ80%、バッチ見出し横にPass。合格線の決め方や契約への記載有無は非公開で、宣伝イメージとして理解してください。

Agentが実電話を受け始めたあとも、システムは監視を続けます。セッション品質、有人転送率、顧客の問い。どこで苦しくなったかを、Presenceプラグイン付きのコーディングアシスタントCodexが調べ、改稿案を書きます。チームが提案版と稼働中の本番版を並べて試し、人が承認してから載せ替えます。

イメージの本番ダッシュボード：配信品質スコア、入電量、顧客意図分布、応答遅延、各タスク成績。「返金系の有人転送が増え始めた」といった信号を見つけるため。指標の算出方法や契約への記載は非公開です。

OpenAI自社の電話線と、試している3社

Presenceの本番事例では、OpenAIがまず自社に載せています。英語電話サポート 1-888-GPT-0090 がPresence上で稼働中——オープンな依頼、本人確認、口座コンテキスト、承認アクション。OpenAIの自己申告では、入電の約 75% が人なしで解決し、Codex改善ループが 10日で有人転送をさらに 15ポイント下げたとのこと。同じ製品を「自社サポート」職務に載せた結果であり、製品自体はサポート限定ではありません。

設計パートナーと明言されているのはBBVAのみ。SoftBankはテスト、IAGは探索。いずれも「既存サポートセンターを全量置換済み」ではありません。

Presenceとは何か、何に使うか

ひとつだけ持ち帰るなら、これを：

何ではないか：おしゃべり専用のもう一つのWebボットでも、個人向けChatGPT会員機能でもありません。個人ユーザーは開けず、企業もWebでセルフ開通できません。「音声サポート専用」の単機能ツールでもありません。音声とテキストは現在開いている対話チャネル。サポート電話が最も詳しい公開事例で、請求・保険金・社内ITなどもそれぞれ配備を開けます。

意義はどこか：多くの企業はすでに「AIは人と話せる」を証明済みです。Presenceが解くのは次の段——助手が本当に業務を受けたあと、権限は誰が決め、ルールは誰が書き、本番前に練習したか、本番トラブルは誰が直し、直しで本番を壊さないか。OpenAIは、以前は自前で継ぎはぎしていたポリシー・シミュ・ダッシュボード・改稿承認を一製品にまとめ、エンジニアを駐在させて実フローへ組み込みます。

具体的に何が使えるか：事業・運用の責任者なら、ある職務のAI助手に付ける「社員番号＋権限表＋着任試験＋品質改稿フロー」と考えるとわかりやすいです。職務は対顧客でも、社内向けでも構いません：

先の「サブスクが2回引き落とされた」一連は、サポート職務でこの4ブロックを実演したものです。ここまでで全体像が掴めるはずです——Presenceが扱うのは、企業AI Agentの配備からルール継続改修までの全過程で、要点は「制御可能な業務遂行」。音声とチャットは現在の対話入口、サポート事例は説明用の一本道であり、製品境界の全部ではありません。

誰が使えるか、まだ足りない情報

Presenceは現在、限定公開です。企業顧客がOpenAIと交渉し、駐在実装エンジニア（Forward Deployed Engineer、FDE）と少数のSIが一緒に導入——フロー選定、システム接続、権限定義、検証後に本番へ。Webでのセルフ開通はできません。資格条件と商取引条件は公開リストがありません。

すでにOpenAI APIで音声を自作している顧客は、API経路を継続できます。Presenceは別の「製品＋駐在」ルートで、ポリシー・シミュ・評価・承認・本番後変更を同一UIにまとめます。

同時期、OpenAIは評価環境でモデルが外部システムに触れた安全インシデントも開示しています。Presenceが強調するポリシー・シミュ・人の承認は、制御可能な本番投入向けであり、あの事故を既に直した、と読んではいけません。本サイトに別記事があります。

配備は1種類の業務だけ——請求争い、保険金、社内ITヘルプなど。助手はその職務の知識とAPIだけ受け取り、できること・人の承認タイミング・有人必須条件は会社が固定。本番前に模擬ケースを一括実行。本番後はCodex（コーディングアシスタント）が改稿案のみ出し、新版は本番版と照合し人が承認します。

小互が架空ECのSwiftcartに「サブスク二重請求」サポート職務を載せ、本番前と本番後を1本のループにします。権限とポリシーを先に固定し、シミュ合格後に実電話。本番信号のあと、CodexがPresenceプラグイン付きで提案を書き、チームが本番版と比較し、人が承認してから載せ替え。Agentは自分自身を上書きできません。

OpenAIはまず自社の英語電話サポート 1-888-GPT-0090 をPresenceで動かしています。対外では設計パートナーBBVAはメキシコ銀行の音声サポートを探索、SoftBankは日本語顧客対話をテスト、IAGは異常気象などピーク時サポートを探索。いずれも探索またはテストで、既存サポートセンターの全量置換ではありません。