
OpenAI Presenceが示す本番AIエージェント運用|顧客対応と社内業務をどう安全に任せるか
目次
1. AIエージェントは「試す」段階から「任せる」段階へ入った
AIエージェントの導入で、いちばん難しいのは「動くデモ」を作ることではありません。顧客の問い合わせに答える、返金可否を判断する、保険請求の状況を案内する、社内ITの申請を処理する。こうした業務では、AIが一度うまく答えるだけでは足りません。毎日変わる商品、ポリシー、顧客の言い回し、例外対応に合わせて、品質を落とさず運用し続ける必要があります。
OpenAIは2026年7月22日、企業が音声・チャットのAIエージェントを本番環境で動かすための製品としてOpenAI Presenceを発表しました。OpenAIの公式発表によると、Presenceは顧客対応や社内業務のワークフローにAIエージェントを組み込み、質問への回答、課題解決、社内システム利用、承認済みアクション、人間へのエスカレーションまでを扱うための仕組みです。
今回の発表で重要なのは、OpenAIが「高性能なモデルを提供する会社」から、「企業の業務にエージェントを入れて運用改善まで回す会社」へ踏み込んでいる点です。AIエージェントの本番化では、モデルの賢さだけでなく、権限、評価、承認、ログ、改善フローが成果を左右します。Presenceはその運用部品を、企業向けの導入プロセスとして束ねようとしている発表だと捉えるべきです。
本番AIエージェントでは、業務範囲、権限、評価、改善をひとつの運用ループとして設計します。
2. OpenAI Presenceで何が発表されたのか
OpenAI Presenceは、対象業務を決めたうえで、必要な知識とシステムアクセスだけをAIエージェントに与える考え方を前提にしています。公式発表では、請求に関する問い合わせ対応、保険請求の支援、従業員のITサービスリクエストなどが例として挙げられています。企業側は、AIが何をしてよいか、どの場面で承認が必要か、いつ人間へ引き継ぐかをポリシーとして設定します。
Presenceが扱う部品は、単なるチャットUIにとどまりません。OpenAIは、ポリシーと標準業務手順、ガードレール、承認済みアクション、シミュレーション、評価ツール、Codexを使った改善プロセスを組み合わせると説明しています。これらは、AIエージェントを業務システムの一部として扱うための土台です。たとえば、返金判断のようにルールがある業務では、AIが顧客の発話を理解するだけでなく、口座情報や契約条件を確認し、会社のルールに沿って提案し、必要なら人間へ渡す必要があります。
実績として、OpenAIは自社の英語電話サポートチャネルでPresenceを使い、1-888-GPT-0090に寄せられる問い合わせに対応していると説明しています。公式発表では、数週間で人間のフロントラインサポート品質を測るベンチマークに到達または上回り、現在は受信した問題の75%を人間の支援なしで解決しているとされています。さらに、Codexを使った改善ループにより、10日間で人間への引き継ぎを15ポイント減らしたことも示されています。
導入先の例として、BBVAはメキシコで日常的な銀行ニーズに向けた音声サポートを検討し、SoftBankは自然な日本語の顧客会話をテストし、IAGは悪天候など需要が集中する場面での顧客支援を検討しています。つまりPresenceは、問い合わせ対応の効率化だけでなく、金融、通信、保険のように信頼性と説明責任が重い業界を意識した発表です。
なお、現時点のPresenceは誰でもすぐ契約できるセルフサービス製品ではありません。OpenAIの公式発表では、対象は適格なエンタープライズ顧客で、限定的な一般提供プログラムとして提供され、OpenAIのForward Deployed Engineersや選定されたシステムインテグレーターが導入を支援するとされています。この点は、導入を検討する企業にとって重要です。Presenceは「買ってすぐ使うツール」ではなく、業務設計を伴う本番導入プログラムに近い位置づけです。
3. 本番運用の焦点はモデル性能ではなく、仕事の境界線にある
企業がAIエージェントを導入するとき、議論はつい「どのモデルが賢いか」に寄りがちです。もちろん性能は重要ですが、顧客対応や社内業務で本当に問題になるのは、AIがどこまで仕事をしてよいかという境界線です。問い合わせに回答するだけなら比較的始めやすくても、アカウント情報を読む、返金を提案する、契約内容に触れる、社内システムに変更を入れるとなると、リスクの種類が変わります。
Presenceの発表は、この境界線を明示的に扱っている点に価値があります。AIにすべてを任せるのではなく、業務ごとに必要な知識と権限を限定し、会社がポリシーを設定し、承認が必要なアクションを分け、人間への引き継ぎ条件を決める。これは、AIエージェントを「優秀な個人」として見るのではなく、「権限管理された業務プロセス」として設計する発想です。
たとえば社内ITサポートで考えると、パスワードリセットの案内、端末の初期設定手順、SaaSアカウント申請の一次受付はAIに任せやすい領域です。一方で、管理者権限の付与、退職者アカウントの削除、セキュリティ例外の承認は、人間の確認や別システムの承認フローが必要です。この切り分けをせずにAIを導入すると、便利さより先に事故対応が増えます。
顧客対応でも同じです。配送状況の案内やFAQ回答はAIが得意でも、返金、補償、契約変更、クレーム対応は、会社の判断基準と監査可能な履歴が必要です。AIが自然に会話できるほど、顧客は人間に近い期待を持ちます。だからこそ、AIが自信を持って答えるべき範囲と、人間へ引き継ぐべき範囲を設計することが、体験品質とリスク管理の両方を支えます。
4. 企業が先に設計すべき4つの運用部品
最初に設計すべきなのは、ジョブ単位のスコープです。「顧客対応にAIを入れる」では広すぎます。「請求額に関する一次問い合わせを受け、本人確認済みの顧客に対して契約プランと請求履歴を参照し、標準ポリシーに沿って回答し、例外は担当者へ渡す」のように、仕事の開始条件、参照情報、許可された行動、終了条件を定義します。AIエージェントは万能窓口ではなく、まずは狭く定義された業務から始める方が安定します。
次に、アクセス権限を決めます。AIが読めるデータ、使えるツール、実行できるアクションを業務ごとに分ける必要があります。顧客対応エージェントがFAQと契約ステータスを参照するのは自然ですが、人事評価や社内の未公開財務資料まで読める状態にする必要はありません。便利さを優先して権限を広げると、誤回答より深刻な情報漏えいリスクを抱えます。
三つ目は、評価とシミュレーションです。本番前には、よくある問い合わせだけでなく、曖昧な依頼、感情的なクレーム、ポリシー外の要求、本人確認が不十分なケース、禁止された操作を誘導するケースを試す必要があります。OpenAIの発表でも、一般的なリクエスト、エッジケース、高リスクシナリオに対してシミュレーションや採点を行う考え方が示されています。ここを軽く扱うと、デモでは成功しても実運用で信頼を失います。
四つ目は、改善ループです。AIエージェントは一度設定して終わりではありません。商品、規約、顧客の質問、社内ポリシーは変わり続けます。Presenceでは、本番セッション、エスカレーション、品質シグナルから改善点を見つけ、Codexが更新案を提案し、チームがテストして承認したうえで段階的に反映する流れが説明されています。これは、AI運用を「プロンプト修正」ではなく、業務システムの継続改善として扱う考え方です。
導入前には、業務範囲、アクセス権限、評価、改善ループを個別に確認します。
| 運用部品 | 決めること | 確認例 |
|---|---|---|
| 業務スコープ | AIが担当する仕事の範囲 | 請求問い合わせは一次回答まで、返金例外は人間へ引き継ぐ |
| 権限管理 | 読める情報と実行できる操作 | FAQ、契約ステータス、対応履歴は許可し、機密フォルダは除外する |
| 評価・シミュレーション | 本番前に試すケース | 通常質問、例外、クレーム、禁止操作の誘導を採点する |
| 改善ループ | 本番後の更新手順 | エスカレーション理由を見て、更新案をテスト後に承認する |
5. 導入判断で見るべき指標
Presenceのような本番AIエージェントを評価するとき、利用回数だけでは判断できません。顧客対応でAIの利用が増えても、人間への引き継ぎが増えたり、確認担当者の負荷が増えたりすれば、業務全体では改善していない可能性があります。見るべき指標は、AI単体の応答数ではなく、業務の最後まで含めた成果です。
第一の指標は、自己解決率です。OpenAIは自社電話サポートで、受信した問題の75%を人間の支援なしで解決していると説明しています。ただし、自社でこの数字を見るときは、単純に高ければよいわけではありません。返金、契約変更、医療・金融・法務に関わる相談など、人間が見るべきものまでAIで閉じていないかを同時に確認する必要があります。高い自己解決率と低い事故率がセットで見えて、はじめて品質指標になります。
第二の指標は、エスカレーションの質です。人間へ引き継ぐ件数が多いか少ないかだけでなく、なぜ引き継いだのか、必要な情報が揃っているか、担当者がすぐ判断できる状態になっているかを見ます。AIが会話の要約、本人確認状況、参照したポリシー、未解決の論点を整理して渡せれば、人間の対応時間は短くなります。逆に、曖昧な会話ログだけが渡されるなら、AIは入り口を増やしただけになります。
第三の指標は、ポリシー遵守率です。AIが正しい答えを出しているように見えても、会社の承認ルールや説明方針に沿っていなければ本番運用には向きません。返品不可の商品に例外を提案していないか、本人確認前に契約情報へ触れていないか、社内ITで権限変更を勝手に進めていないか。こうした項目は、会話品質とは別に監査する必要があります。
第四の指標は、改善サイクルの速さです。問い合わせの傾向が変わったとき、どれくらい早くFAQ、ポリシー、評価ケース、エージェントの振る舞いを更新できるか。PresenceがCodexを使った改善ループを強調しているのは、ここが本番運用のボトルネックになりやすいからです。AIエージェントは導入初日より、運用開始後の30日、90日、180日でどれだけ賢く、安定し、説明しやすくなったかを見るべきです。
6. まとめ
OpenAI Presenceは、AIエージェントの価値が「会話できること」から「業務を安全に完了できること」へ移っていることを示す発表です。OpenAIの公式発表では、音声・チャットでの顧客対応、社内業務、承認済みアクション、人間へのエスカレーション、シミュレーション、評価、Codexによる改善ループまでが示されました。限定的なエンタープライズ向け提供である点からも、これはセルフサービス型ツールというより、本番業務へAIを組み込むための運用プログラムと見るべきです。
企業が学ぶべきことは、Presenceそのものをすぐ導入するかどうかだけではありません。AIに任せる仕事を狭く定義する。必要な情報と操作だけを与える。高リスクケースを本番前に試す。エスカレーションと改善のループを作る。この4点が揃って初めて、AIエージェントは便利なデモから、監査できる業務基盤へ近づきます。
OpenBridgeでは、AIエージェント、RAG、業務システム連携、権限設計、ログ設計の知見を活かし、企業がAIを安全に業務へ組み込むための設計を支援しています。顧客対応、社内問い合わせ、営業支援、ナレッジ検索などの領域では、モデル選定より先に、業務範囲、アクセス制御、評価、改善サイクルを整えることが現実的な第一歩です。


