OpenAI Presenceとは​何か​ ──企業の​顧客対応を​AIエージェントに​任せる​新プロダクトを​解説

AIエージェントを業務に入れたい。多くの企業がそう考えていますが、実際に本番へ出す段になると、決まって同じ壁にぶつかります——賢いだけでは、任せられない。

2026年7月22日、OpenAIが「OpenAI Presence（プレゼンス）」を発表しました^[1]。ひとことで言うと、AIエージェントを企業の現場業務で"本番運用"するためのプロダクトです。チャットや音声で顧客対応や社内手続きをこなし、会社のシステムを使い、承認された操作を実行し、手に負えなくなったら人へ引き継ぐ——その一連を回すための仕組みが、ひとまとめになっています。

見逃せないのは、これがもう「実験」ではないという点です。OpenAI自身の英語電話サポートはすでにPresenceで動いていて、問い合わせの75%を人手なしで解決しています^[1]。「AIエージェントは動くのか？」という問いは終わり、論点は「本番で信頼できるほど安定して回せるか」に移りました。Presenceは、その答えとして出てきた製品です。

この記事で分かること——①Presenceが実際に何なのか ②何が"新しい"のか ③どんな部品でできているのか ④実績の数字 ⑤使う前に知っておくべきこと。専門用語は都度かみくだくので、AIの発注を検討している立場の方でも読み進められます。本文の数値・事例はすべてOpenAIの公式発表を確認したもので、電脳技巧集団（AI職人ギルド）が自ら検証したものではありません。

01Presenceとは​何か​ ──モデルではなく​「運用のか​たまり」

これまでOpenAIが売ってきたのは、GPTのようなモデル（AIの頭脳）そのものでした。開発者がAPI経由でモデルを呼び出し、アプリは自分たちで組む。Presenceはそこから一歩踏み込んで、「エージェントを業務で使い続けるための土台」ごと提供する製品です。

Presenceの各導入は、いつも「1つの具体的な仕事」から始まります。たとえば「請求に関する問い合わせを解決する」「保険金請求のサポート」「社員のIT依頼に対応する」といった単位です。そしてエージェントには、その仕事に必要な知識とシステムアクセスだけが渡されます。何でもできる万能AIを1体置くのではなく、役割を絞った担当者を業務ごとに立てるイメージに近い。

会社側は、そのエージェントについて次を決めます——何をしてよいか、どこで承認が要るか、いつ人が代わるか。この「境界線を会社が握る」という設計思想が、Presence全体を貫いています。

02何が​"新しい​"のか ──​「作って​終わり」ではなく​「変わり続ける」

従来のチャットボット導入の弱点は、作った瞬間から古くなることでした。商品も、社内ルールも、顧客の聞き方も、日々変わります。台本を書き込んだボットはそれに追いつけず、放置され、いつのまにか使われなくなる。

Presenceが違うのは、「変わり続けること」を最初から前提に置いている点です。本番で動かすと、実際のやりとりや「人へ引き継がれた場面（エスカレーション）」から、エージェントの弱点が見えてきます。そこで登場するのがOpenAIのコーディング支援AI「Codex（コーデックス）」です。Codexがそうした本番のシグナルを調べ、改善案を自動で提案します。チームはその案を本番と同じ条件でテストし、承認してから段階的に反映できます。

03Presenceを​構成する​6つの​部品

公式は、本番でエージェントを回すために必要な要素として次を挙げています。役割ごとに整理すると分かりやすい^[1]。

部品	ざっくり言うと	何のためか
ポリシー / 標準手順	エージェントの行動ルール	「会社としてこう対応する」を定義
ガードレール	越えてはいけない線での介入	境界の外に出そうな時に止める
承認された操作	実行してよい処理の範囲	返金・変更などを許可制にする
シミュレーション	公開前のリハーサル	よくある依頼・エッジケース・高リスク場面を事前検証
評価ツール	出来の採点	正しい結果に至ったか・手順を守ったかを判定
Codexによる改善	本番シグナルからの提案	公開後に変わる状況へ追従

ポイントは、これらがバラバラのツールではなく、ひとつの流れとして連動することです。会社のシステムをつなぎ→エージェントの振る舞いを定義し→性能を評価し→ポリシーを守らせ→公開後の変化を管理する。「賢いモデル」だけでは埋まらなかった、その周辺の全部をパッケージにした、と理解すればいい。

04実績の​数字 ──OpenAI自身の​サポート窓口で

Presenceがただの構想でないことは、OpenAI自身が"自社の電話窓口"で使っていることに表れています。英語電話サポート（1-888-GPT-0090）はPresenceで動いており、公式は次の数字を挙げています^[1]。

導入を進めている企業も公式に名前が出ています。BBVA（メキシコで日常的な銀行取引の音声サポートを検討）、ソフトバンク（自然な日本語での顧客対応を検証）、IAG（悪天候など需要が跳ねる場面での即応を検討）。日本の読者としては、ソフトバンクが日本語音声のデザインパートナーに入っている点が目を引きます^[1]。音声での一次対応をAIに任せる流れは、CAGでも実装・検証してきたテーマです。

関連記事 ｜ 音声の一次対応リアルタイム音声AIに「人間の監督」を組み込む ──話すAIを本番に出すための設計 →

05使う​前に​知っておく​こと​ ──まだ​"誰でも​今すぐ"ではない

魅力的に見えますが、現時点のPresenceには前提があります。ここを外すと期待値がずれます^[1]。

項目	現状（2026年7月22日 発表時点）
提供段階	限定的な一般提供（limited GA）。まだセルフサーブではない（自分で契約して即利用、はできない）
導入の主体	OpenAIの Forward Deployed Engineers（FDE＝顧客先に入る導入エンジニア） と、選ばれた大手システムインテグレーターが主導
対応チャネル	今日時点で音声・チャットのリアルタイム対応（顧客サポート、アウトバウンド営業、高リスクな社内業務）
主な対象業務	請求解決・保険金請求・IT依頼など、間違えると影響が大きい業務

つまり、気軽なSaaSではなく「エンジニアと二人三脚で入れる」重い導入です。裏を返せば、間違いの影響が大きい業務に耐える設計（承認・ガードレール・評価）が要る、ということでもあります。

では、まだ使えない中小企業には関係ないかというと、そうではありません。Presenceの"設計の型"は、規模を問わず持ち帰れます。AIエージェントを業務に入れるとき、最低限これらを先に決めておく——という指針として効きます。

• 業務単位で権限を絞る。 万能AIを1体置かない。必要な知識とシステムだけ渡す。
• 人へ戻す条件を明文化する。「どこからは人間」を先に決める。
• 改善ループを回す前提で作る。 本番の失敗を教材にする設計にする。
• 本番セッションから評価する。 作って終わりにしない。

この4点は、Presenceが大企業向けに実証したものを、そのまま自社のAI導入チェックリストとして使えます。CAGでも、AIエージェントを業務に組み込む際はこの骨格で設計しています。

関連記事 ｜ 実装の現場から顧客対応AIを、業務に載せるまで ──「賢さ」より「境界と引き継ぎ」を設計した話 →

06まとめ ──​「モデルの​時代」から​「運用の​時代」へ

Presenceが示すのは、AIエージェント競争の主戦場が、モデルの賢さから"本番で安定して回す運用"へ移ったということです。賢いモデルは前提条件になり、勝負は「境界を握れるか」「変化に追従できるか」に移っています。

持ち帰りたい3点

• エージェントは"1つの仕事"から。 万能を狙わず、業務単位で権限を絞る。
• 境界は会社が握る。 何をしてよいか・どこで人に戻すかを先に決める。
• 改善はループで。 本番の失敗を教材に、AIが改善案を書き、人が承認して直す。

「AIエージェントを入れたいが、どこから手をつければいいか分からない」——そんな段階なら、Presenceの設計の型は、そのまま自社の出発点になります。まだ製品としては重い導入ですが、その設計思想は、今日から自分たちの業務に当てられるものです。