OpenAI Presenceとは:AIエージェントの導入・運用を任せる選択肢
OpenAI Presenceは、AIエージェント本体だけでなく、ポリシー、評価、システム連携、継続改善までを一体で提供するマネージド導入です。75%の問い合わせ自動解決と10日間で15ポイントの引き継ぎ削減をどう読むべきか、Workspace AgentsやAgents SDKとの違い、導入判断の基準を整理します。

OpenAIによると、Presenceは英語の電話サポート窓口に寄せられる問い合わせの75%を人の手を介さず解決しており、改善ループによって人への引き継ぎも10日間で15ポイント減少しました。この数字を支えるのは、登録すれば使えるエージェント作成ツールではありません。AIエージェント、ポリシー、評価、システム連携、継続的な運用をまとめて提供する、企業向けのマネージド導入サービスです。
結論:モデルではなく、AIエージェントの導入・運用を提供
OpenAI Presenceが検討に値するのは、顧客向けの音声・チャット業務で厳格なポリシーに従って実際の処理を行う必要があり、その導入負担をOpenAIにも担ってほしい場合です。一方、セルフサービス型のエージェント作成ツールを探す小規模チーム、SDKを求める開発者、あるいは任せる業務をまだ一つに絞れていない企業にとっては、適切な出発点ではありません。

発表時の提供条件を見ると、製品の性格がよく分かります。Presenceを利用できるのは、限定的な一般提供の対象となる適格な企業顧客だけです。導入はOpenAIのForward Deployed Engineersと選定されたグローバルシステムインテグレーターが主導し、OpenAIもセルフサービス製品ではないと明記しています。発表ページにも現在のFrontierページにも、一般公開された価格表はありません。
つまり、提供の仕組み自体が製品です。最先端モデルであれば、サポートへの問い合わせ内容はすでに理解できます。難しいのは、正しいアカウント情報を渡し、権限を制限し、返金ポリシーを守らせ、実行内容を検証し、承認が必須となる場面を判断し、危険度の高い案件を人へ引き継ぎ、昨日までの挙動を壊さずにシステムを更新することです。Presenceは、こうした仕事を一つのマネージド案件としてまとめます。
OpenAI PresenceのAIエージェント導入に含まれるもの
Presenceは汎用的なデジタル従業員ではなく、明確に定義された一つの業務を本番運用するための仕組みです。導入は毎回、特定のワークフローを決めるところから始まります。エージェントに与える知識とシステムアクセスはその業務に必要な範囲だけに限定し、ポリシー、承認ポイント、人への引き継ぎルールは顧客企業が定めます。
ガードレールという言葉から、モデルの回答後にかけるフィルターを想像するかもしれません。ここで指すのは、入力、ツール、アクション、権限、エスカレーションを制約する、より広い統制の仕組みです。Presenceはポリシーと標準作業手順、ガードレール、承認済みアクション、シミュレーション、評価ツール、そしてCodexを活用した改善プロセスを組み合わせています。
一つの業務に絞る
請求問題の解決、保険請求の支援、従業員のIT依頼への対応など、完結した成果を一つ選びます。「すべての顧客を支援する」といった広すぎる指示では、有効な評価セットも、説明可能な権限境界も作れません。
コンテキストとアクセスを限定する
対象業務に必要な記録とシステムだけを接続します。請求対応エージェントなら、本人確認、アカウント、請求書、支払いの情報は必要でしょう。しかし、顧客データ全体へ無制限にアクセスする必要はありません。
ポリシーと承認条件を組み込む
回答してよい内容、実行してよいアクション、承認を求める条件、人が引き継ぐ条件を定義します。文章が正しくても、権限のない操作を伴えば、本番環境では失敗です。
公開前にシミュレーションする
一般的な依頼、境界事例、より危険度の高いシナリオを評価システムに通します。OpenAIによれば、成果の品質、ポリシー遵守、ツール利用、エスカレーションの挙動を確認します。
変更管理の下で改善する
本番セッション、エスカレーション、品質シグナルから不足点を見つけます。Codexがそのシグナルを調査して更新案を作成し、チームは本番バージョンとの比較テストを行ったうえで、管理された展開を承認できます。

デモより重要なのは、このループです。音声エージェントが公開初日に自然に話せても、製品が変わったとき、新たな返金例外が生まれたとき、あるいは当初のテストセットが想定しなかった言い回しを顧客が使い始めたときに失敗する可能性があります。Presenceは本番での挙動を変更案の材料とし、その提案と本番反映の間にテストと承認を置きます。
カスタマーサポート責任者にとって、ここがチャットボットと、ワークフローを動かす運用システムとの実質的な違いです。チャットボットは回答します。本番エージェントは確認し、判断し、権限の範囲で実行し、経緯を記録し、その権限を超えるリスクがあれば人へ引き継ぎます。
実績は有望だが、証明できている範囲は狭い
発表された実績から、Presenceが実際のサポート窓口を運用できることは分かります。ただし、企業全般に通用する投資効果まで証明されたわけではありません。OpenAIが示したのは、自社の英語電話サポート窓口1-888-GPT-0090での結果です。そのため、有用な製品実績であると同時に、ベンダー自身が報告した実績でもあります。
デザインパートナーの事例は、まだ早期段階です。BBVAはメキシコで日常的な銀行業務を支援する音声対応を検討しています。SoftBankは自然な日本語による顧客との会話をテストしています。IAGは悪天候など需要が急増する場面での支援を検討しています。言語や規制対象ワークフローをまたぐ広がりは示されていますが、OpenAIはこれらを同等の本番成果として紹介してはいません。
さらに発表では、調達部門が必要とする公開価格、導入期間、最低利用量、サポート体制、アクション別のエラー率、正しく解決できた問い合わせ当たりのコストが示されていません。限定的な一般提供であることを考えれば不自然ではありませんが、現時点では信頼できる公開コスト比較が存在しないということです。契約条件と対象ワークフローの基準値なしに提示される精密なROI試算は、信用すべきではありません。
OpenAIのAIエージェント製品群でPresenceが担う位置
Presenceは、ChatGPT Workspace Agents、OpenAI Agents SDK、Frontierも含む製品群の中で、ワークフローをマネージド導入する選択肢です。これらを同じものとして扱うと、導入判断を誤ります。どの製品を選ぶかによって、誰が何を所有するかが異なるからです。
ChatGPT Workspace Agents:社内の反復業務向け
ChatGPT Workspace Agentsは、BusinessまたはEnterpriseワークスペース内ですでに行われている反復業務に適した、より軽量な選択肢です。作成者はモデルと推論強度を選び、アプリやツールを接続し、同僚にエージェントを公開できます。Slackでの利用、スケジュール実行、APIからの起動にも対応します。

統制機能には意味がありますが、実行できる範囲は狭めです。アプリとコネクターの書き込み操作は、初期設定でAlways askになっています。Connector Action Constraintsを使えば連携先で許可する操作を制限できますが、OpenAIは、この制約がコネクターから返されるデータをフィルタリングするものではないと説明しています。ファイル上限は各ファイル512 MB、エージェントごとに合計10 GBです。
APIにおける決定的な制約は、運用面にあります。トリガーは実行をキューに入れ、レスポンス本文なしの202 Acceptedを返します。run IDは返らず、現時点ではそのAPIから結果を取得することもできません。結果を待たずに任せられる社内業務なら成立しますが、同期的なステータス、再試行ロジック、追跡可能な結果が必要な顧客向け製品には不向きな仕様です。
OpenAI Agents SDK:カスタム製品を自社で所有
OpenAI Agents SDKは、自社の製品やインフラにエージェントを組み込みたい企業に適しています。OpenAIのエージェント構築ガイドでは、アーキテクチャを三つの主要要素に整理しています。推論するモデル、情報を読み取るか処理を実行するツール、挙動を定める指示です。

この三要素はシステムの中心にすぎません。ID、認可、ツール仕様、評価データ、監視、フォールバック動作、インシデント対応、コストは、構築側が引き続き所有します。OpenAIは、まず最も高性能なモデルで評価ベースラインを作り、精度を維持できる箇所を小型モデルに置き換える方法を推奨しています。また、マルチエージェント構成を追加する前に、単一エージェントの能力を最大限に引き出すことも勧めています。
カスタム開発を選ぶべきなのは、ワークフローが製品の差別化につながる場合、導入条件が特殊な場合、モデルやツールのコストを細かく調整する必要がある場合です。ベンダーを切り替えられることが重要なら、特定プロバイダーのSDKより上の層に抽象化を設計しなければなりません。SDKを選んだだけで可搬性が得られるわけではありません。
OpenAI Frontier:全社規模のプラットフォーム
OpenAI Frontierは、部門やシステムをまたいで多数のエージェントを運用する企業向けの、広範なプラットフォームです。公開されている構成レイヤーは、Business Context、Agent Execution、評価と最適化、エンタープライズセキュリティとガバナンスです。

Frontierは、顧客が構築したエージェント、OpenAIのエージェント、サードパーティ製エージェントを一つのプラットフォームで統制する設計です。OpenAIは、エージェントのID・アクセス管理、明示的な権限、監査可能なアクション、モニタリング、詳細なログを挙げています。Enterprise Frontier Programでは、Forward Deployed Engineersが顧客と協力してアーキテクチャを設計し、ガバナンスを運用に落とし込み、エージェントの本番稼働まで支援します。
製品の対応関係はシンプルです。Workspace Agentsは社内向けエージェント体験を、SDKは構成要素を、Presenceは導入済みワークフローを、Frontierは企業向けの統制基盤をパッケージ化します。Frontierのどの構成要素がPresenceの契約に含まれるかを示す公開資料をOpenAIは出していないため、推測せず確認する必要があります。

OpenAI以外も含めて市場全体を比較するなら、2026年版おすすめAIエージェントで企業向けプラットフォームと運用上のトレードオフを確認してください。
Presenceを導入すべき企業、自社開発すべき企業
対象ワークフローが限定され、価値が高く、実際のアクションを伴い、失敗時の損失が大きいならPresenceを購入する理由があります。エージェントが戦略的な知的財産になる場合、運用条件が特殊な場合、マネージドな本番移行より長期的な管理権を重視する場合は、自社で構築すべきです。
Presenceは、特にポリシーの比重が高いサービス業務で説得力があります。悪天候時の保険金請求状況に関する電話を扱う保険会社を考えてみましょう。エージェントは発信者の本人確認を行い、正しい契約と請求情報を取得し、単なる状況確認か変更依頼かを見分け、権限内でのみ処理し、リスクが高まれば人へ引き継ぐ必要があります。自然言語は構成要素の一つにすぎません。安全なワークフローになるかどうかは、アクセスとエスカレーションで決まります。
エージェント自体が競争優位を生むなら、カスタム開発が有利です。特定業界向けのソフトウェア企業では、独自ツール、分野固有の評価セット、特徴あるユーザー体験、複数モデルプロバイダーへの対応、あるいはマネージドサービスでは満たせない環境への導入が必要になることがあります。その場合、運用ループを外部へ委ねることは、本来プロダクトチーム内に残すべき学習まで外部へ出すことになりかねません。
運用者の立場によっても答えは変わります。ポリシーの比重が高いサポート窓口を抱え、常設のエージェント運用組織を一から作る意思がない中堅企業のCTOには、Presenceを試験導入する十分な理由があります。エージェントそのものを製品とする資金調達済みスタートアップの創業者なら、通常はアーキテクチャと評価データを自社で持つべきです。社内承認を自動化する業務責任者なら、Workspace Agentsか決定論的なワークフローから始めるのが妥当です。個人開発者にはSDKの方が適しています。Presenceはセルフサービスでも、軽量な実験向けでもないからです。
LLMが入力を解釈できるという理由だけで、エージェントを構築してはいけません。ルールエンジンで確実に判断でき、言語レイヤーが構造化された項目を集めるだけなら、判断部分は決定論的なままにします。確率的な推論を使うのは、曖昧さによって本当に必要となる箇所だけです。
契約前にワークフローの評価表を求める
試験導入で評価すべきなのは、会話がどれほど人間らしく聞こえるかではなく、正しい成果を出せることと、失敗を制御できることです。75%という解決率は有用な見出しになりますが、契約では財務、リスク、オペレーションの現場でも通用する定義が必要です。
少なくとも、次の指標を追跡してください。
- 正しい解決率: 対象となる問い合わせのうち、人を介さず終了しただけでなく、正確に完了した割合。
- 誤解決率: 誤った回答、誤ったアクション、未解決の要望があるにもかかわらず、完了扱いになった問い合わせの割合。
- ポリシー遵守: その時点で適用されるルールと承認経路に従ったか。
- ツール実行品質: 読み取りと書き込みが正しいレコードを対象とし、正しいパラメーターを使い、意図した状態変更を生んだか。
- エスカレーション品質: リスクや不確実性のある案件が、対応を続けるために必要な情報とともに適切な担当者へ届いたか。
- 正しく解決した問い合わせ当たりのコスト: 契約、モデル、連携、レビュー、サポートの費用を、検証済みの成功件数で割った金額。
- レイテンシーと離脱: 通常時と需要ピーク時の応答時間、および解決前に発信者が離脱する割合。
- 変更の安全性: ポリシーやプロンプトの更新案が、既存のケースを悪化させずに対象ケースを改善するか。
分母の定義が重要です。簡単な問い合わせだけを処理し、コストのかかる案件をすべてエスカレーションしても、自動完結率は改善できます。後で再度問い合わせが発生する会話を完了扱いにして、解決率を水増しすることも可能です。高コストな失敗が集計値に隠れないよう、意図、アクション種別、リスク区分、言語、チャネルごとに結果を分けてください。
完結した成果を一つ選ぶ
業務上の言葉で対象を定義します。どこから始まり、何をもって正しい完了とするか、どのアクションを許すか、何を必ず人へ渡すかまで含めます。
評価セットを作る
実際のポリシー文書と機密情報を除いた過去のパターンを使い、通常の依頼、曖昧さ、情報不足、敵対的な言い回し、ポリシー変更、高リスクな境界事例を網羅します。
権限マトリクスを定める
すべてのツールアクションを列挙し、可逆性、権限、金銭的影響、顧客への損害で分類します。証拠が権限拡大を裏付けるまでは、高リスクまたは不可逆なアクションを人の監督下に置きます。
現在のプロセスと並行稼働する
エージェントに本番レコードを変更させる前に、提案された回答、アクション、エスカレーションを現在の運用と比較します。不一致を平均化して済ませず、原因を調査します。
検証済みのインテント単位で拡大する
実証できた依頼種別を、統制されたグループ単位で本番へ移します。即時にロールバックできる経路を維持し、ポリシー、ツール、指示の変更を公開する前には回帰テストを必須にします。
導入前には、責任分担も決めておく必要があります。ポリシー変更の承認、インシデントのレビュー、連携の保守、評価セットの所有、エージェントの権限を広げる判断には、それぞれ担当者が必要です。Presenceは技術と導入の専門知識を提供できます。しかし、そのワークフローに対する企業の説明責任をなくすことはできません。
戦略面での評価
OpenAI Presenceが重要なのは、企業向けAIエージェントの販売軸を、モデルへのアクセスから運用上の説明責任へ移した点です。約束するものは、もはや「当社の知能を使ってください」ではありません。「統制されたワークフローの運用と、公開後の改善を一緒に担います」という提案です。
これは、汎用エージェントビルダーをもう一つ増やすより強い製品設計です。同時に、OpenAIの導入チーム、モデル、改善プロセス、契約への依存は深まります。マネージド導入の速さと共有される運用ノウハウが、自社保有の価値を上回るなら、この取引は合理的です。本来自社能力にすべきワークフローなら、割高な依存になります。
したがって、問うべきはPresenceが賢そうに見えるかではありません。成果を誰が所有するのか、各アクションを誰が統制するのか、更新の安全性を誰が証明するのか、エージェントが失敗したときに誰が業務を引き継ぐのかを確認してください。契約がこれらに答え、試験導入で経済性を証明できれば、Presenceは企業のAIエージェント導入で最も難しい部分を短縮できます。答えが得られないなら、自社で測定し、所有できる、より狭いシステムを構築すべきです。
OpenAI Presenceはセルフサービスで利用できますか?
いいえ。OpenAIによれば、Presenceは適格な企業顧客を対象に、限定的な一般提供として利用できます。Forward Deployed Engineersと選定されたグローバルシステムインテグレーターが導入を主導し、発表ページでは、購入希望者にOpenAIの担当チームへ連絡するよう案内しています。
OpenAI PresenceとChatGPT Workspace Agentsの違いは何ですか?
Workspace Agentsは、アプリ、ツール、Slack、スケジュール、APIトリガーを使い、反復業務向けにChatGPT内で作成・共有するエージェントです。Presenceは、企業のシステムを利用し、統制されたアクションを実行し、必要に応じて人へ引き継ぐ、リアルタイムの音声・チャットワークフロー向けマネージド本番導入です。
OpenAIはPresenceの価格を公開していますか?
2026年7月22日の発表ページにも、現在のFrontier製品ページにも公開価格表はありません。有用な見積もりには、明確に定義した一つのワークフロー、その処理量、連携範囲、サポート体制、測定可能な成功基準をひも付ける必要があります。
企業はPresenceを購入すべきですか、それとも独自のAIエージェントを構築すべきですか?
ポリシーの比重が高い一つの音声・チャットワークフローにマネージド導入が必要で、OpenAIを運用に深く関わるパートナーとして受け入れられるなら購入が適しています。エージェントが製品の差別化要因になる場合、アーキテクチャの管理が戦略的に重要な場合、導入条件が特殊な場合、あるいはモデルの可搬性とユニットエコノミクスがマネージド導入の速さより重要な場合は、自社で構築すべきです。
マネージド型のエージェントを購入するか、システムを自社で所有するか判断するなら、構築前にワークフローとリスク境界を整理してください。
2026年9月3日







