AIニュース
OpenAI Presenceは「AIエージェントの運用」を商品にした 企業導入の主戦場が変わる
OpenAIの新製品Presenceは、AIエージェント本体ではなく、権限設計、評価、人への引き継ぎ、継続改善まで含む運用を企業へ提供します。発表の核心と導入判断への影響を解説します。
- 公開日
- 最終検証
- 次回確認
- 確信度
- MEDIUM
新製品なのに、利用者が自分で触る画面はない
請求内容を理解し、本人確認を行い、社内システムを参照して処理する。企業がAIエージェントへ任せたいのは、回答文の生成だけではない。問題は、どこまで操作を許し、どの場面で承認を求め、いつ人へ引き継ぐかである。
OpenAIが2026年7月22日に発表した「Presence」は、まさにこの運用部分を製品の中心に置いた。ところが、一般的なSaaSのように申し込み、管理画面から設定して試せる製品ではない。対象となる企業を選ぶ限定提供で、OpenAIのForward Deployed Engineer（FDE）や一部のシステムインテグレーターが導入を主導する。
モデル、業務知識、システム接続、権限、評価、人への引き継ぎ、公開後の改善。それらを一つの導入工程として提供するのがPresenceだ。編集部の見立てでは、これは単なる「新しいAIエージェント」ではない。企業向けAIの競争軸が、モデルの賢さから本番運用を誰が設計し、壊さず改善し続けられるかへ移ったことを示す製品である。
仕事を限定し、権限と合格条件を決めてから本番へ出す。失敗は改善材料になるが、更新は比較評価を通し、人が承認する。
AIに仕事を渡す前に、仕事の境界を作る
OpenAIは、企業にとっての課題は「AIエージェントが動く」と証明することではなく、価値の高い仕事を任せられるほど信頼性を高めることだと説明している。製品、社内規程、利用者の行動が変われば、導入時に正しかった振る舞いも時間とともにずれるからだ。
Presenceの導入は、「顧客対応を自動化する」のような大きな目的から始まらない。請求問題の解決、保険請求の支援、社内ITサービスの受付といった具体的な一つの仕事から始める。エージェントが受け取るのは、その仕事に必要な知識とシステム権限だけ。企業側は、実行可能な操作、承認が必要な条件、人が引き継ぐ条件を決める。
ここで従来の理解が変わる。モデルとプロンプトを選び、社内文書を読ませただけでは、本番運用は完成しない。OpenAIのヘルプも「文書を取り込むだけで本番対応にはならない」と明記している。業務の切り分け、システム接続、セキュリティ・プライバシー・法務審査、シミュレーション、受け入れ試験、段階公開までが必要になる。
これはAI導入を遅くする儀式ではない。仕事の境界が曖昧なまま権限だけ与えると、「回答できるAI」がいつの間にか「どこまで操作してよいか分からないAI」になる。Presenceは、その境界づくり自体を製品として売ろうとしている。
公開後の失敗を、勝手な自己改善に変えない
導入前には、一般的な依頼だけでなく、境界事例や高リスクな状況をシミュレーションする。評価するのは答えの正しさだけではない。社内方針に従ったか、ツールを正しく使ったか、必要な場面で人へ引き継いだかまで確認する。会社が定めた範囲を会話が外れた場合には、ガードレールが介入する。
公開後は、本番セッション、操作履歴、エスカレーション、品質シグナルから問題を探す。OpenAIの説明では、Presenceプラグインを使うCodexが原因を調査して変更案を提示し、担当チームが本番版との比較テストを行ったうえで段階的な展開を承認する。ヘルプには監視だけでなく、新版の制御された展開とロールバックも挙げられている。
重要なのは、改善が速いことより、改善の入口と出口が分かれていることだ。AIが失敗を見つけ、AIが自分を直し、そのまま本番へ出る構成ではない。少なくとも公式説明上は、企業がポリシーを定め、変更を評価し、公開を承認する。
先日のOpenAI評価用エージェントによるHugging Face侵入事件と防御設計は、狭い目標と広い実行権限の組み合わせが、運用者の想定した境界を越え得ることを示した。Presenceの発表が同事件への対応として作られたわけではない。しかし、権限、評価、監視、停止、人への引き継ぎを「付属機能」ではなく製品の本体に置く意味は、その事件を知った後ほど重く見える。
「75％を自動解決」は、まだ成功率の証明ではない
Presenceは、OpenAIの英語電話サポートでも使われている。OpenAIによれば、着信した問題の75％を人の支援なしで解決し、Codexを使った改善ループによって10日間で人への引き継ぎを15ポイント減らしたという。
この数字は、音声会話だけでなく、本人確認、アカウント情報の利用、承認済み操作まで含む運用例が存在することを示す。一方で、問い合わせの構成、「解決」の定義、比較対象、誤処理率は発表ページで詳しく説明されていない。これはOpenAIによる自社運用の報告であり、独立した検証結果でも、他社で同じ成果が出るという保証でもない。
さらに、実際のAI電話サポートには限界がある。OpenAIのヘルプによると、一般的な製品質問やトラブル対応には使えるが、報告の受理、アカウント審査、有人担当者への接続やフォローアップの保証はできない。派手な「75％」より、残る25％と、AIが扱ってはいけない依頼をどう別経路へ送るかの方が、運用設計を理解する材料になる。
BBVA、ソフトバンク、IAGも設計パートナーまたは導入検討企業として紹介されている。ただし表現は「検討」「テスト」「可能性の探索」が中心で、本番導入の規模や成果が確定した事例とは区別すべきだ。
技術の新発明か、手厚いコンサルティングか
Presenceには強い反対解釈もある。発表で並ぶ権限管理、評価、監視、人への引き継ぎは、AIエージェント運用で以前から必要とされてきた要素だ。FDEやシステムインテグレーターが個別導入を支援するなら、「技術的な新発明ではなく、既存要素をまとめたコンサルティング商品ではないか」と見ることもできる。
その見方は半分正しい。そして、残り半分こそPresenceのニュース性である。企業がAIを導入できない原因がモデル性能だけなら、もっと賢いモデルをAPIで提供すれば済む。OpenAIが人間の導入チーム、業務設計、評価、継続運用まで抱え込んだのは、ボトルネックが組織と運用に移ったと判断したからだろう。
もちろん、手厚い支援は依存も生む。ヘルプによれば、正確な機能、利用モデル、容量、データ取扱い、料金、サービス水準は案件ごとに決まる。標準価格も標準導入期間も公開されていない。OpenAIや指定パートナーへの依存度、データの保存地域、ログの保持、責任分界、別基盤へ移行できる設計かは、契約前に個別確認が必要だ。
Presenceを使えない企業にも、発表は役に立つ
現時点でPresenceへ申し込めない企業でも、この製品構成はAIエージェント導入の設計図になる。比較すべき相手は別のAIモデルだけではない。
| 導入前に決めるもの | 判断できる状態 |
|---|---|
| 任せる仕事 | 開始条件、完了条件、対象外を一文で説明できる |
| システム権限 | 読み取り、自動実行、要承認を操作ごとに分けられる |
| 合格条件 | 正答だけでなく、方針遵守、ツール利用、引き継ぎを評価できる |
| 人の役割 | 例外対応、変更承認、緊急停止の責任者が決まっている |
| 改善工程 | 本番の失敗を再現し、現行版と比較してから更新できる |
この五つを答えられない製品なら、モデルが高性能でも、本番の仕事を渡す準備はできていない。逆に、ここが設計されていれば、モデルは交換可能な一部として扱いやすくなる。AIエージェントの権限設計と人による承認フローを、製品選定より先に作る理由もここにある。
企業向けAIは「導入後」に競争する
Presenceが示したのは、AIエージェントの価値がデモ画面では決まらなくなったことだ。仕事を狭く定義し、必要最小限の権限を渡し、失敗を観測し、変更を比較し、人が公開を承認する。この地味な循環を速く、安全に回せる企業が、モデルの性能を実際の成果へ変えられる。
編集部としては、Presenceを「OpenAIがついに完成させた自律社員」とは評価しない。むしろ逆だ。AIだけでは本番運用が完成しないと認め、専門家と統制工程を製品へ組み込んだ点に価値がある。
次に見るべきは、限定提供から広がった後も同じ品質を維持できるか、料金と導入期間が明らかになるか、そして顧客企業による独立した成果検証が出るかだ。75％という数字より、残る失敗をどう定義し、誰が止め、どう直したか。その情報が開示されたとき、Presenceの実力が見えてくる。
確認日と参照した公式情報
確認日：2026年8月22日
- OpenAI：Introducing OpenAI Presence
- OpenAI Help Center：OpenAI Presence
- OpenAI Help Center：AI phone support
PRIMARY SOURCES
確認した一次情報
広告