OpenAI Presenceとは？音声・チャット業務をAIエージェント化する仕組みと導入前の確認点
OpenAIは2026年7月22日、音声・チャット業務にAIエージェントを導入する企業向け製品「OpenAI Presence」を発表しました。
Presenceは質問へ回答するだけでなく、承認された情報の参照、業務システムの更新、許可された操作、人への引き継ぎまで担う仕組みです。
ただし、2026年7月29日時点では限定的な一般提供であり、誰でも申し込めるセルフサービス製品ではありません。料金や日本国内での提供条件も確認できていません。
本記事では、公式情報で確認できる機能と公表実績を整理したうえで、導入前に決めたい権限、承認、人への引き継ぎ、評価方法を解説します。
OpenAI Presenceとは何か
音声・チャットに対応する企業向けAIエージェント
OpenAI Presenceは、企業が顧客向けまたは社内向けの業務へAIエージェントを導入するための、マネージド型エンタープライズ製品です。対応チャネルとして音声とチャットが明記されており、顧客サポート、アウトバウンドセールス、高リスクな社内業務などが用途として例示されています。
公式情報によると、Presenceのエージェントは利用者からの質問に答え、問題の解決を支援できます。企業が承認した社内知識を参照するほか、APIやツールを通じて業務システムへ接続し、情報の検索、記録の更新、会社が許可した操作を実行する構成も可能です。
従来のFAQ型チャットボットは、用意された質問と回答の提示を中心とするものが一般的でした。これに対しPresenceは、会話を入口として社内情報や業務システムへ接続し、承認された範囲で業務処理まで進められる点に特徴があります。
もっとも、すべての導入先で同じ機能を利用できるわけではありません。接続するシステム、利用チャネル、認証方式、エージェントに許可する操作、人への引き継ぎ方法などは、個別案件の技術的なスコーピングによって確定するとされています。「Presenceを導入すれば、あらゆる電話・チャット業務をすぐ自動化できる」という意味ではありません。
誰でも使えるセルフサービス製品ではない
2026年7月29日の確認時点で、Presenceは対象となる企業顧客向けの限定的な一般提供です。一般利用者や企業がWebサイトから契約し、自社だけで設定を完了させるセルフサービス製品ではありません。
OpenAIのForward Deployed Engineers（顧客企業の現場に入り、導入や実装を支援する技術者）や、選定されたシステムインテグレーターが導入を支援します。利用できるかどうかは、対象業務との適合性、企業側の実装準備状況、提供可能な支援体制などによって決まり、関心のある企業にはOpenAIのアカウント担当者への問い合わせが案内されています。
料金、最低契約規模、標準的な導入期間、日本国内での正式な申込方法は、公開情報から確認できません。したがって、中小企業や小規模な士業事務所が導入対象になることや、直ちに契約できることは現時点で断定できません。
Realtime APIとは提供形態が異なる
OpenAIは2026年5月、Realtime APIで利用できる音声モデルとしてGPT-Realtime-2なども発表しています。Realtime APIは、開発者がリアルタイム音声アプリケーションを構築するためのAPIです。会話を続けながらリクエストを処理し、ツールを呼び出し、利用者の訂正や割り込みに対応する用途が想定されています。
一方、Presenceは企業ごとの業務設計、システム連携、評価、承認、運用改善を含むマネージド型の導入製品です。開発者向けAPIであるRealtime APIとは、提供形態も導入方法も異なります。
Presenceの個別案件でどのモデルが使用されるかは公開情報から特定できません。公式ヘルプセンターでは、モデルや構成は業務に応じて選定され、変更される場合があると説明されています。Realtime APIの仕様を、そのままPresence固有の仕様として扱わないことが重要です。
Presenceでできる業務と公表実績の読み方
一次受付から承認済み操作までをつなぐ
Presenceで想定される業務は、次のような段階に分けると理解しやすくなります。
- 音声またはチャットによる一次受付
- 質問への回答と問題解決の支援
- 承認された社内知識の参照
- 業務システム内の情報検索
- 許可された記録更新や操作
- 人または別のサポート経路への引き継ぎ
例えば、問い合わせ内容を聞き取り、承認済みの資料から一般的な案内を行い、条件を満たす場合だけ予約を登録する、といった流れが考えられます。個別判断が必要になった場合や処理を継続できない場合には、人へ引き継ぐ構成を設定できます。
ここで重要なのは、「会話ができること」と「業務システムを操作できること」を同じ権限として扱わないことです。操作対象や承認条件は企業側が設定し、エージェントには担当業務に必要な知識とシステムアクセスだけを与える設計が示されています。
また、文書を読み込ませるだけで本番運用へ移れるわけではありません。スコーピング、システム連携、シミュレーション、テスト、セキュリティ・プライバシー・法務面のレビュー、企業側の承認などが必要です。
OpenAIの自社サポートでは75％を解決と公表
OpenAIは、自社の英語電話サポート「1-888-GPT-0090」でPresenceを使用していると発表しています。同社の公表値では、数週間で有人サポートの品質基準と同等以上に達し、問い合わせの75％を人の支援なしに解決したとされています。
さらに、Codexを利用した改善サイクルにより、10日間で人への引き継ぎ率が15パーセントポイント低下したと説明されています。ここでいう15パーセントポイントは、単純な「15％改善」と同じ意味ではありません。
これらはOpenAI自身の運用環境と評価基準による公表値であり、第三者が検証した結果ではありません。英語電話サポートでの実績を、日本の中小企業や士業の窓口へそのまま当てはめることはできません。問い合わせ内容、業務手順、使用言語、システム連携、例外の多さなどが異なれば、結果も変わると考えられます。
導入効果を検討するときは、75％という数値を自社の目標へ転用するのではなく、自社における現在の問い合わせ件数や一次完了率を測り、試験結果と比較する必要があります。
BBVA、SoftBank、IAGは検討・テスト段階を含む
OpenAIの発表では、BBVAがメキシコで日常的な銀行業務の音声サポートを検討し、SoftBankが自然な日本語による顧客対応をテストし、IAGが悪天候などで需要が集中する場面の支援を検討していると紹介されています。
これらを一括して「Presenceの導入企業」と表現するのは正確ではありません。公式発表に沿って、検討中またはテスト中として扱う必要があります。
SoftBankの担当者コメントでは、現場チームが日本語会話の自然さと正確さを高く評価したとされています。ただし、評価方法、サンプル数、定量的な結果は公表されていません。一般的な日本語会話での評価が、法令用語や専門用語を含む士業の相談でも再現されるとは断定できません。
導入前に決めたい権限・承認・人への引き継ぎ
権限は操作単位で分ける
AIエージェントの導入で先に決めたいのは、「何を自動化するか」だけではありません。「何をさせないか」と「どこから人へ戻すか」を具体化する必要があります。
編集部では、少なくとも次の操作を別々の権限として整理することが有効と考えます。
- 利用者と会話する
- 承認済みの一般情報を参照する
- 顧客情報を参照する
- 対応記録を作成・更新する
- 予約など、取り消し可能な操作を行う
- 申請や送信など、外部へ確定情報を出す
閲覧できることが、更新してよいことを意味するわけではありません。同様に、社内記録を更新できることと、外部へ情報を送信できることも分けて考える必要があります。
例えば、本人確認が終わる前は一般情報だけを案内し、個別の顧客情報にはアクセスさせない設計が考えられます。本人確認後も、記録の下書きまではAIが行い、確定や外部送信には担当者の承認を必要とする方法があります。
なお、「権限分離」は編集部による業務設計上の整理であり、OpenAIが製品発表で使用している主要用語ではありません。ただし、必要なシステムアクセスだけを付与し、権限と承認ステップを設定する考え方は公式情報で確認できます。
人の承認を残す操作を先に定義する
取り消しにくい処理や、誤りが生じた場合の影響が大きい処理は、人の承認対象にすることが考えられます。具体的には、金銭、契約、申請、報酬、重要条件に関する処理、本人の明示的な意思確認が必要な処理、個別具体的な専門判断などです。
本番環境の設定変更にも承認が必要です。Presenceでは、会話記録、エスカレーション、品質シグナルなどから改善点を特定し、CodexとPresenceプラグインが変更案を提示する流れが説明されています。しかし、Codexが変更案を自動的に本番へ反映するとは記載されていません。企業側のチームが現在の本番版と比較してテストし、承認したうえで段階的に展開する構成です。
このため、AIが作成した処理案を承認する担当者と、本番設定を変更できる管理者を分ける方法も検討できます。変更履歴、操作履歴、承認履歴を確認できる状態にしておくことが、運用後の検証に役立つと考えられます。
人へ引き継ぐ条件を文章化する
Presenceは必要に応じて人または別のサポート経路へ引き継げますが、具体的な条件は企業側が設定します。公開情報では、応答時間、引き継ぎ先、共有する情報項目が一律に決められているわけではありません。
編集部では、次のような条件を導入前に文章化することが重要と考えます。
- 利用者が人による対応を希望した
- 根拠となる承認済み情報を確認できない
- 回答への確信が不足している
- 同じ質問や確認を繰り返している
- 本人確認または権限確認に失敗した
- システム連携や更新処理に失敗した
- 許可されていない操作を求められた
- 個別の専門判断を求められた
- 苦情、異議、緊急性、損害につながる可能性を検知した
引き継ぐだけでなく、担当者が対応を再開できる情報を渡すことも必要です。問い合わせの要約、確認済み事項、未解決事項、実行済みの操作、引き継ぎ理由などが候補になります。ただし、これらすべてがPresenceの標準項目として提供されるとは確認できていないため、個別導入時の確認が必要です。
中小企業・士業はどの業務から検討できるか
反復性が高く、取り消しやすい業務から始める
中小企業が導入可能かどうかは現時点では不明ですが、問い合わせ業務を整理する準備は製品の利用可否にかかわらず進められます。
最初の候補にしやすいと考えられるのは、次のような業務です。
- 定型的な一般案内
- 面談や折り返し対応の受付
- 問い合わせ内容の一次聞き取り
- 担当部署や担当者への振り分け
- 承認済み情報の検索
- 問い合わせ内容と対応結果の記録
- 営業時間外や繁忙時の一次受付
選定の基準は、反復性が高いか、処理を取り消せるか、誤りが生じた場合の影響が比較的小さいか、標準的な手順を文章化できるかです。相談窓口全体を一度に置き換えるのではなく、一つの限定された業務から試すほうが、問題の原因や改善点を確認しやすいと考えられます。
中小企業診断士やコンサルタントが支援する場合も、単に「何件を自動化できるか」を検討するだけでは不十分です。問い合わせ業務の可視化、標準業務手順、権限、承認条件、引き継ぎ条件、評価指標を一体として設計することが重要です。
Web制作会社についても、画面や会話の設計に加え、電話・チャットとCRM、予約、文書管理などをつなぐ要件整理が必要になる可能性があります。ただし、Presenceが接続できる具体的なシステム一覧や認証方式は公開されていないため、既存顧客のシステムと連携できると事前に断定することは避けるべきです。
士業では一般案内と個別判断を分ける
税理士、社会保険労務士、行政書士、司法書士などの事務所では、面談予約、相談分野の聞き取り、一般的な必要書類の案内、担当者への振り分けなどへの応用可能性が考えられます。
一方、次のような領域は人による判断や承認を残す候補です。
- 個別具体的な法令、適法性、期限の判断
- 受任や契約の確定
- 申告、申請、登記の内容確定と外部提出
- 報酬や重要条件の確定
- 本人確認、代理権、委任関係、利害対立に関する判断
- 苦情、異議、紛争や損害につながる可能性がある相談
これは確認済みの製品仕様を基にした編集部の検討であり、日本の士業で実証された運用方法ではありません。OpenAIの公式発表には、日本の士業事務所を対象とした導入事例は掲載されていません。また、日本の各士業法、業務独占、守秘義務、本人確認義務、個人情報保護などへの適合性も、製品発表だけでは判断できません。
士業で利用を検討する場合は、関係法令、所管官庁、各士業団体などの一次情報を確認し、必要に応じて各分野の専門家による個別判断を得る必要があります。
導入可否が分からなくても準備できる
まず、直近1か月の電話、メール、チャットを、個人情報の取り扱いに注意しながら次のように分類します。
- 定型的な一般案内
- 予約・折り返し受付
- 担当者への振り分け
- 個別の専門判断
- 苦情・異議・緊急案件
- システム更新・外部送信を伴う処理
次に、AIへ任せない業務と、人へ引き継ぐ条件を先に書き出します。あわせて、問い合わせ件数、平均対応時間、折り返し件数、一次対応で完了した件数、誤案内、引き継ぎ件数などの現状値を測定します。
標準業務手順、承認者、障害時の代替窓口も整理しておけば、Presenceに限らず、別のAIサービスや既存業務の改善を検討する際にも利用できます。
小さく試し、自社の基準で評価する方法
通常ケースだけでなく例外も試す
Presenceの公式情報では、本番導入前に一般的な依頼、例外ケース、高リスクな状況を対象としたシミュレーションと評価を実施できると説明されています。
面談予約を試す場合でも、正しい日時を入力する通常ケースだけでは十分ではありません。曖昧な希望、誤入力、重複予約、本人確認の失敗、予約システムとの接続障害、人による対応の希望なども試す必要があります。
評価項目としては、次のようなものが考えられます。
- 期待した結果へ到達したか
- 承認済み情報だけを根拠に回答したか
- 方針や標準業務手順に従ったか
- 許可されたツールを正しく使用したか
- 必要な場面で人へ引き継いだか
- 不要な引き継ぎを増やしていないか
- 誤更新や情報漏えいにつながる動作がなかったか
- 担当者へ必要な情報が渡ったか
- 利用者が人へ円滑に接続できたか
AI窓口の評価では、自動解決率だけを見ると、無理に処理を継続してしまう問題を見落とす可能性があります。「処理を完了できたか」と同時に、「処理すべきでない場面で適切に止まり、人へ戻せたか」を測ることが重要です。
契約・国内要件を個別に確認する
OpenAIまたは導入支援事業者への問い合わせ時には、少なくとも次の点を確認する必要があります。
- 日本国内での提供条件と対象企業
- 料金、最低契約規模、想定導入期間
- 日本語および専門用語の評価方法
- 接続可能な電話、チャット、CRM、予約、文書管理システム
- 認証、権限、承認フローの設定粒度
- データの保存場所、保存期間、学習利用、削除方法
- ログの閲覧権限と監査方法
- 人への引き継ぎ方法と共有可能な情報
- 応答時間、稼働率、障害時の対応
- 本番変更の承認、段階展開、ロールバックの方法
- AI利用、録音、利用目的の告知方法
利用者がAIと会話していることが文脈上明白でない場合、OpenAIはAIである旨を明示する必要があると説明しています。一方、日本国内の音声通話でどのように表示・告知するか、録音や利用目的をどう案内するかは公開情報から確定できません。実際の業務、契約条件、国内要件に応じた個別確認が必要です。
データの保存場所、保存期間、学習利用、ログ管理についても、公開情報だけでは確定できません。顧客情報や機密性の高い相談内容を扱う場合は、アクセス制御、保存方針、削除方法、監査方法まで事前に確認する必要があります。
まとめ：最初に「何をさせないか」を決める
OpenAI Presenceは、音声・チャットで質問へ回答するだけでなく、承認された情報の参照、業務システムの操作、人への引き継ぎまで含む企業向けAIエージェント製品です。
ただし、2026年7月29日時点では限定的な一般提供であり、料金、最低契約規模、日本国内での提供条件、日本語の専門業務における品質は確認できていません。OpenAIの自社サポートにおける75％の解決率も、他社や士業で再現されることを示す数値ではありません。
導入を検討する際は、自動化する件数より先に、対象業務、操作権限、人の承認を必要とする条件、人へ引き継ぐ条件を整理する必要があります。最初から相談窓口全体を対象にせず、一般案内や予約など、反復性が高く、取り消しやすい限定業務から試す方法が考えられます。
士業では、一般案内と個別の専門判断を明確に分け、国内法令や職業上の義務を別途確認することが欠かせません。
読後の第一歩として、直近1か月の問い合わせを6種類に分類し、「AIへ任せない業務」と「人へ引き継ぐ条件」を一つずつ書き出してみてください。この整理は、Presenceを利用できるかどうかにかかわらず、現在の問い合わせ業務を見直す材料になります。
出典一覧
- OpenAI「Introducing OpenAI Presence」（2026-07-22）
- OpenAI Help Center「OpenAI Presence」（確認日：2026-07-29）
- OpenAI「Advancing voice intelligence with new models in the API」（2026-05-07）
- OpenAI Help Center「AI phone support」（確認日：2026-07-29）
この記事はAIが生成し、編集長のチェックを受けて公開しています。
