OpenAIの企業向けエージェント基盤「Presence」を業務目線で読む｜モデル提供から「運用まで面倒を見る」へ

OpenAIが2026年7月22日に発表した「Presence」は、新しいモデルの発表ではありません。業務目線でいちばん効くのは、モデルを配る会社が「そのモデルで動くエージェントを本番に配備し、統治し、改善し続ける」運用レイヤーまで降りてきた、という一点です。顧客サポートや営業、社内IT対応といった現場に、音声とチャットの本番用エージェントを提供するマネージド基盤という位置づけです。この記事では、報道で確認できた範囲の事実を淡々と押さえたうえで、エージェント導入を検討する企業にとって何を意味するのかを、誇張も不安あおりもせずに切り分けます。数値はいずれもOpenAIの公表値である前提で読みます。

Presenceとは何が発表されたのか#

まず事実を押さえます。複数の報道によると、OpenAIは2026年7月22日にPresenceを発表しました。顧客対応の請求トラブル、保険金請求、従業員のITサービス依頼といった具体的な業務を対象に、音声とチャットの本番用エージェントを配備するための基盤です。特徴は、モデルの推論単体ではなく、その周囲に「企業が定めるポリシー」「ガードレール」「人へのエスカレーション(引き継ぎ)ルール」を組み合わせ、社内データやシステムに接続する形で提供される点にあります。

各配備は特定の業務に範囲を絞って始まり、エージェントにはその業務に必要な情報とシステム権限だけが与えられる、と説明されています。何を許可し、どの操作で承認を挟み、どこで人に引き継ぐか、という境界を企業側が設定する設計です。これは「賢いモデルを渡すので後はご自由に」という提供形態とは方向が違い、運用と統治の枠組みまでを製品として束ねている点が新しさです。

「モデルを配る会社」が運用・統治まで降りてきた#

これまでOpenAIの企業向け提供の中心は、モデルとAPIという「素材」でした。エージェントとして本番で動かすには、利用する側がフレームワークを選び、ガードレールや監視、権限設計、人の承認導線を自分たちで組む必要がありました。Presenceは、その組み立てとその後の運用・改善までを一つのマネージド基盤として引き受ける、という位置づけです。IT Brief Asiaなどの報道は、これをOpenAIの企業戦略が「生のモデル提供」から「本番級エージェントを構築・統治・継続改善する完全マネージド型」へ移る動きと整理しています。

業務目線で言い換えると、エージェント基盤という中間層に、モデルの供給元そのものが降りてきた、という構図です。フレームワークやオーケストレーションを内製で組む選択肢はこれまで通り残りますが、その隣に「供給元が運用まで面倒を見る」選択肢が並んだ、と読むのが実務的です。エージェント開発フレームワークの現在地は別記事で整理しています。

公表された数値をどう受け止めるか#

Presenceの説明で目を引くのは、OpenAI自身が使っているという実績値です。複数の報道によると、OpenAIは自社の英語電話サポート回線をPresenceで動かし、受電した問い合わせの75%を人手なしで解決していると説明しています。さらに、production(本番)データと実際のエスカレーションをもとにCodexが改善案を出す仕組みで、その支援チャネルにおいて導入10日以内に人への引き継ぎを15ポイント低減した、とも説明されています。

これらは、運用しながら自動で改善が回るというPresenceの売りを示す具体例として有用です。ただし受け止め方には注意が要ります。いずれもOpenAI自身の、自社の一つのサポート回線という条件での公表値です。対象業務、問い合わせの内容分布、許容できる誤答の水準は現場ごとに大きく異なり、同じ数字が自社でそのまま出る保証はありません。

内製で組むか、運用基盤を借りるか#

導入を検討する側の実質的な論点は、rent(借りる)かown(自前で持つ)かの判断です。内製は、フレームワーク選定からガードレール・監視・権限設計・人の承認導線まで自分たちで握れるぶん、要件に合わせて細部を作り込めますが、その設計と運用・改善の負荷を継続して負います。Presenceのような運用基盤を借りる形は、立ち上げと継続改善の枠組みを供給元に委ねられる一方、価格や提供条件、ロックインの度合いといった外部要因に依存します。

どちらが正解ということはありません。判断材料は、扱う業務の重要度と誤答の許容度、社内の監査・データ管理要件、内製を維持できる人員、そして「後から乗り換えられるか」という退出のしやすさです。まずは範囲を絞った一業務で、内製案と基盤案を同じ評価軸で並べて比べるのが堅実です。エージェントに社内データを接続する際の情報管理の勘所は、別記事のガイドラインが参考になります。

「まだ誰でも今すぐ使えるわけではない」現実#

もう一つ冷静に押さえたいのは提供形態です。報道によると、Presenceはself-serveのプランがなく、申し込めばすぐ使える製品ではありません。OpenAIのForward Deployed Engineers(顧客先に入り込む導入エンジニア)や一部のシステムインテグレータが主導して導入する、限定的な一般提供の形をとり、公開価格も示されていないと報じられています。early customer(初期顧客)として、BBVA Mexico、SoftBank Corp.、IAG(オーストラリアの保険大手Insurance Australia Group)といった名前が挙がっています。報道によると、IAGは豪雨や自然災害など問い合わせが急増する高負荷時の顧客対応・保険金請求サポートでの活用を検討しているとされます。

ガードレール・エスカレーション・監査を分けて見る#

基盤を借りるにせよ内製するにせよ、本番のエージェントで品質と安全を左右するのは、モデルの賢さそのものより周辺の設計です。Presenceが前面に出しているガードレール・エスカレーション・権限の絞り込みは、まさにその周辺にあたります。導入検討では、この三つを別々の観点として評価すると見通しがよくなります。

• ガードレール: 何を答えてよく、どの操作を禁じるか。取り消せない操作(返金確定、契約変更など)の前に承認を挟めるか。
• エスカレーション: どの条件で人に引き継ぐか。引き継ぎ時に文脈を欠落なく渡せるか。引き継ぎ率を継続的に測れるか。
• 監査: 誰が・いつ・どのデータにアクセスし、何を実行したかを後から追えるか。誤答や事故が起きたとき原因を特定できるか。

音声とチャットで顧客に直接応答する用途は、誤答や不適切な応答がそのまま体験や信頼に響きます。だからこそ、自動解決率のような攻めの指標と同じ重みで、誤ったとき・止めたときの守りの導線を評価する必要があります。誤情報の混入をどう抑えるかは、エージェントに限らず生成AI全般の課題として整理しています。

検討を進める手順#

本記事の発表日・製品の位置づけ・提供形態(self-serveなし、Forward Deployed Engineersや一部インテグレータ主導)・初期顧客・自動解決率75%・10日で15ポイント低減という数値は、Help Net Security、CX Today、IT Brief Asia、Bloomberg Lawなどの報道で確認できた範囲に基づきます。数値はいずれもOpenAIの公表値で、実環境での成果を保証するものではありません。提供条件や価格は変わりうるため、適用可否は個別に一次情報で確認してください。

よくある質問#

まとめ#

Presenceは、賢い新モデルという見出しよりも「モデルの供給元が、エージェントの運用と統治まで面倒を見るレイヤーに降りてきた」動きとして読むと、実務にはまります。自社サポートで75%を自動解決したという公表値は魅力的ですが、それは条件付きの一例です。提供はまだ限定的で、誰でも今すぐ横展開できるわけでもありません。だからこそ、内製か基盤かを同じ軸で冷静に並べ、ガードレール・エスカレーション・監査を数字と同じ重みで要件化する。この切り分けが、供給元が運用まで担う新しい選択肢を、宣伝の期待値ではなく自社の実務に見合う形で取り込む近道だと考えます。