ベンダー選定

OpenAI Presenceで電話業務のAI化が本番製品になった｜どのベンダー経由で・いくらで・何から始めるかの発注判断

2026年7月23日22分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

5分で自社の状況を診断する

GXO COLUMN

AI・DX

結論：注目すべきは「音声AIができた」ではなく「本番運用の型が製品化された」こと

2026年7月22日（米国時間）、OpenAIが音声・チャットの業務用AIエージェントを本番運用するための基盤「OpenAI Presence」を発表しました。単なる音声合成や賢いチャットボットではなく、会社の方針（ポリシー／標準手順）、ガードレール、承認済みアクション、シミュレーション、評価ツール、そしてCodexによる継続改善プロセスを一つにまとめた「運用の型」を製品として提供する点が新しさです。

そしてもう一つ重要なのは提供形態です。OpenAI Presenceはセルフサービスで誰でも今日から使える製品ではなく、OpenAIのForward Deployed Engineer（FDE）と一部のグローバルSIer（システムインテグレーター）が主導する限定的な一般提供（limited general availability）として案内されています。つまり「良いモデルを借りて自分で組む」段階から、「導入支援とセットで運用まで持っていく」段階へ、提供の重心が移ったことを示しています。

だから経営者が最初にすべき判断は「うちも音声AIを入れるか」ではありません。「電話・チャット業務のどこを、どのベンダー経由で、いくらで、何から着手するか」です。この記事は、発表を恐怖でも礼賛でもなく、その発注判断に翻訳します。承認済みアクション・ガードレール・評価という製品の構成要素を、そのまま発注側の要件チェックへ読み替えられるように整理します。AIエージェント導入の要件整理を検討している経営者・情シス向けに、AIエージェント開発・運用の考え方へ接続する形でまとめます。

AI ASSESSMENT

PoC の前に「そもそも使えるか」を30分で見極めませんか？

対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。

30分壁打ちを予約

要点：まず押さえる事実

横にスクロールして確認できます

項目	確認できた内容
発表	OpenAIが「OpenAI Presence」を発表（2026年7月22日・米国時間）
何か	音声・チャットの業務用AIエージェントを本番運用する基盤
構成要素	ポリシー／標準手順、ガードレール、承認済みアクション、シミュレーション、評価ツール、Codexによる継続改善
承認済みアクション例	本人確認、請求問題の解決、アカウント変更、返金処理（公式説明より）
自社実績	OpenAI自社の英語電話サポートで着信の75%を人手介在なしで解決と公表（企業自己申告・第三者未検証）
提供形態	セルフサービスではない。FDEと一部グローバルSIer主導の限定一般提供
価格	公式は未開示（要問い合わせ）
早期顧客	BBVA Mexico、ソフトバンク、Retail Insurance Australia（IAG）などと報じられている（VentureBeat）

数値の扱いに注意してください。「着信の75%を人手介在なしで解決」はOpenAI自社の英語サポート回線での自己申告値であり、第三者による独立検証は公表されていません。海外メディアは「導入10日で人への引き継ぎが15ポイント低下した」とも報じていますが、これも企業側の申告に基づく報道であり、自社の日本語・自社業務でそのまま再現する保証はありません。ベンチマーク数値を「うちでも出る前提」で稟議に書くのは、後述する典型的な発注ミスです。

なぜ「音声AIの話」ではなく「発注判断の話」なのか

音声AI自体は目新しくありません。これまで多くの企業がIVRの改善や簡単なFAQボットを試し、その多くがPoC（実証実験）で止まりました。止まった理由は技術力の不足よりも、「本番で誰がどこまで実行を許すか」「間違えたとき誰が責任を取り、どう止めるか」を決めきれなかったことにあります。

OpenAI Presenceが製品として束ねたのは、まさにその「決めきれなかった部分」です。ポリシー、ガードレール、承認済みアクション、評価は、いずれも技術というより運用ガバナンスの構成要素です。裏を返せば、これらを外部の製品が用意したからといって、自社が「何を許し、何を許さないか」を決める仕事は消えません。むしろ、製品側が「approved actions（承認済みアクション）」という枠を明示的に持つほど、発注側は「その枠に何を入れるか」を自分で定義しなければならなくなります。

ここが発注判断の核心です。良い製品を選ぶだけでは足りず、自社の業務・権限・責任分界を要件として言語化できるかどうかが、PoC止まりと本番稼働を分けます。要件が曖昧なまま「OpenAIだから安心」で進めると、追加費用・責任の押し付け合い・成果の出ない稼働という、従来のシステム開発と同じ失敗を音声AIで繰り返します。だからこそ、製品の構成要素を「発注側が問う要件」に変換しておくことに価値があります。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

誰が読むべきか

電話・チャットのカスタマーサポートに人手がかかり、採用も追いつかない中堅企業の経営者・事業責任者
「AI電話対応を入れたい」と現場から言われたが、どこから手をつけ、どう発注すればよいか判断材料がない情シス（0〜1名体制を含む）
過去にチャットボットやIVR改善を試み、PoCで止まった経験がある担当者
ベンダーから音声AIの提案を受けており、その提案が自社に適正か第三者の視点で確かめたい方

逆に、まだサポート業務の件数が少なく、FAQ整備や導線改善で十分に足りる段階の企業は、いきなり本番運用基盤を検討する前に、業務の棚卸しから始めるべきです。判断の入口としてAI活用の現状診断・要件整理を使い、そもそも自動化に値する業務量とパターンがあるかを先に確かめることをおすすめします。

製品の6要素を「発注側の要件チェック」に変換する

OpenAI Presenceが束ねた6要素は、そのまま「発注時に自社が定義・確認すべき要件」の一覧になります。ベンダーが誰であっても（OpenAI経由でも国内SIer経由でも）、この6点を自社の言葉で埋められるかが、本番稼働の前提です。

1. ポリシー／標準手順（何を答え、何を答えないか）

AIに任せる前に、そもそも人間の対応方針が文書化されているかを確認します。返金の可否基準、例外対応の判断者、言ってはいけない表現、といった標準手順が曖昧なら、AIに与える「正解」も曖昧になります。発注側の要件は「AIの精度」ではなく、まず「自社の応対基準が明文化されているか」です。ここが未整備なら、AI化はその整備を強制する良い機会でもあります。

2. ガードレール（越えてはいけない一線）

ガードレールは「AIが自由に振る舞える範囲の外枠」です。個人情報の扱い、金額の上限、断定してはいけない領域（法律・医療・契約の解釈など）を、技術ではなく業務判断として線引きします。要件チェックとしては「越えたら止まる／人へ渡す条件を、金額・トピック・本人確認レベルで具体的に定義できているか」を問います。

3. 承認済みアクション（AIに実行を許す操作）

ここが最も慎重に設計すべき箇所です。公式説明では、本人確認・請求問題の解決・アカウント変更・返金処理などが承認済みアクションの例として挙げられています。重要なのは、これらが「回答」ではなく「実行」だという点です。回答は間違っても訂正できますが、返金やアカウント変更は実世界に副作用を残します。承認済みアクションは後述の「取消可能性」で必ず切り分けてください。

4. シミュレーション（本番前の当て逃げテスト）

本番投入前に、よくある依頼・エッジケース・高リスクシナリオに対してAIを当てて挙動を確認する工程です。発注側の要件は「どんなシナリオ集で、誰が合否を判定するか」です。ベンダー任せにせず、自社の実際のクレーム・イレギュラー事例をシナリオとして提供できるかが、テストの実効性を左右します。

5. 評価ツール（稼働後も品質を測り続ける仕組み）

一度作って終わりではなく、稼働後の会話を継続的に評価する仕組みが要ります。要件チェックは「何を良し悪しの指標にするか（解決率だけでなく、誤実行率・不要な人手介在率・苦情率など）」「誰がその指標を見て、何点を割ったら改修するか」を決めておくことです。解決率75%のような単一指標だけを追うと、強引に自己完結して顧客満足を落とす失敗につながります。

6. Codexによる継続改善（改修プロセスに人の承認が挟まるか）

OpenAI PresenceはCodexが会話を分析して改善案を提案し、担当者がテスト・承認してから反映する、という改善ループを持つと説明されています。ここで発注側が確認すべきは「AIが自分で自分を書き換えるのか、必ず人の承認を挟むのか」です。無人で挙動が変わる仕組みは、統制の観点では要注意です。承認フローとログが残るかを要件に含めてください。

承認済みアクションは「金額」と「取消可能性」で線を引く

承認済みアクションの設計は、抽象論では失敗します。おすすめは「取消可能性」と「金額・影響度」の2軸で操作を分類し、AIに許す範囲を段階的に広げる方法です。

横にスクロールして確認できます

区分	例	AIへの許可方針
取消可能・低影響	残高照会、配送状況の案内、FAQ回答	AI単独で実行可
取消可能・中影響	予約変更、住所変更	AI実行＋事後ログ通知、本人確認を必須化
取消困難・高影響	返金、解約、与信・請求変更	AIは起票のみ・人の承認後に実行、または金額上限を設定
不可逆・高リスク	大口返金、契約解除、法的判断を伴う対応	AI実行禁止・必ず人へエスカレーション

この表はそのまま社内の意思決定資料に使えます。ポイントは「AIが賢いかどうか」で許可範囲を決めないことです。どれだけ賢くても、不可逆で高リスクな操作をAI単独に許すべきではありません。逆に、取消可能で低影響な操作までいちいち人が介在すると、自動化のメリットが消えます。線引きは技術ではなく経営判断であり、ここを外部ベンダーに丸投げすると、後で「なぜこれをAIに許したのか」を説明できなくなります。

国内ではどう入るか：FDE/SIer主導という現実

OpenAI Presenceは「セルフサービスではない」点を、国内企業は特に重く受け止める必要があります。提供はOpenAIのForward Deployed EngineerとグローバルSIer主導であり、価格・契約条件・地域制限・付随する構築費用は公式には開示されていません。早期顧客としてBBVA Mexicoやソフトバンク、IAGなどが報じられていますが、いずれも大企業です。

中堅企業にとっての現実的な問いは3つです。第一に、自社がこの限定提供の対象になれるのか。第二に、なれるとして、FDEやグローバルSIerとの英語主体のプロジェクト運営と、その規模の予算に耐えられるのか。第三に、OpenAI Presenceそのものでなくても、同じ「運用の型」（ポリシー・ガードレール・承認済みアクション・評価）を、国内ベンダーと組んで別の技術スタックで実現できないか。

多くの中堅企業にとって、最初の一歩はOpenAI Presenceの契約可否を待つことではなく、「自社の電話・チャット業務のどこを・どの区分まで自動化するか」の要件を固めることです。要件が固まっていれば、OpenAI Presenceが使えるようになったときにも、国内ベンダーと別スタックで組むときにも、同じ発注書が流用できます。要件を持たずに製品名だけで動くと、ベンダーが売れるものに引きずられ、自社に不要な範囲まで作らされます。ここはシステム・AI開発の要件整理と伴走やAIエージェントの設計・運用で、発注前に整えておく価値が大きい領域です。

PoC止まりを避ける段階設計

過去の音声AI・チャットボットがPoCで止まった最大の理由は、いきなり「全業務・全チャネルをAIで」と広く始めて、評価も責任分界も曖昧なまま停滞したことです。本番稼働へ抜けるには、狭く始めて評価で広げる段階設計が有効です。

第0段階：棚卸し　入電・チャットの内容を分類し、件数の多い定型問い合わせ上位を特定する。ここで自動化に値する業務量があるかを判定する。
第1段階：回答のみ（取消可能・低影響）　残高照会やFAQなど、間違えても訂正できる回答に限定してAIを稼働。誤実行のリスクがゼロの範囲で品質と顧客反応を測る。
第2段階：本人確認＋中影響アクション　予約・住所変更など、事後で取り消せる操作に、本人確認とログ通知を付けて開放する。
第3段階：高影響アクションの半自動　返金・解約は「AIが起票・人が承認」の半自動から始め、評価指標が安定してから自動化範囲を検討する。

各段階で「次に進む合格条件」を数値で決めておくのが要点です。解決率だけでなく、誤実行率・不要な人手介在率・苦情率を見て、基準を満たしたら次段階へ、割ったら前段階へ戻す。この「戻せる設計」があるかどうかが、PoC止まりと本番運用の分かれ目です。段階設計と合格条件の作り込みに不安があれば、発注前に第三者の視点でAI導入の適合度・要件を診断しておくと、稟議の説得力が上がります。

ベンダーへの質問テンプレート

音声AIの提案を受けたら、製品名やデモの出来ではなく、次の質問への回答で見極めてください。

承認済みアクションは「取消可能性」と「金額・影響度」でどう分類し、どこまでAI単独に許す設計か。上限や禁止操作をどう定義するか。
ガードレールを越えたとき、何を条件に人へエスカレーションするか。その条件は金額・トピック・本人確認レベルで具体的に書けるか。
稼働後の評価指標は何か。解決率以外に、誤実行率・不要な人手介在率・苦情率を測るか。何点を割ったら誰が改修するか。
AIの挙動を改善するとき、無人で書き換わるのか、人の承認とログを必ず挟むのか。
本番前のシミュレーションに、自社の実際のクレーム・イレギュラー事例を反映できるか。合否は誰が判定するか。
初期構築費・月額・従量課金・改善運用費の内訳と、想定外の追加費用が発生する条件は何か。
成果が出なかった場合の責任分界と、契約解除・データ持ち出しの条件はどうなっているか。

これらに具体的に答えられないベンダーは、技術力の前に運用設計の経験が不足しています。特に「うちに任せれば大丈夫」で詳細を濁す提案は、後の追加費用と責任の空白を招きます。

発注前チェックリスト

見積もりの読み方：音声AIで膨らみやすい費目

音声AI・AIエージェントの見積もりは、モデル利用料そのものより「その周辺」で費用が膨らみます。読むときは次の費目が分離され、条件が明記されているかを確認してください。

初期構築費：業務分析、社内システム連携、権限設計、ポリシー・ガードレール定義、シミュレーション整備。ここを安く見せて後で追加請求する提案に注意。
従量課金：通話・チャットの量に比例する部分。ピーク時の想定件数で試算されているか。
運用改善費：稼働後の評価・改修は継続的に発生する。「作って終わり」の見積もりは、後で別途請求になりやすい。
連携・保守：CRMや基幹システムとの接続と、その保守。ここが曖昧だと本番で止まる。

「一式」でまとめられた見積もりは、内訳を分解させてください。分解を渋る場合、その裏に想定外費用が隠れていることが少なくありません。既存の提案を客観的に確かめたいときは、開発の見積もり・要件を第三者の視点で整理する使い方が有効です。

FAQ

Q. OpenAI Presenceは今すぐ日本の中堅企業でも使えますか。 A. セルフサービスではなく、FDEと一部グローバルSIer主導の限定提供です。対象・価格・地域制限は公式未開示のため、まずは自社が対象になるかの確認が必要です。多くの中堅企業は、契約可否を待つより先に業務要件を固める方が現実的です。

Q. 「着信の75%を人手なしで解決」はうちでも出ますか。 A. これはOpenAI自社の英語サポート回線での自己申告値であり、第三者検証は公表されていません。業種・言語・問い合わせの複雑さで結果は変わります。この数値を前提に稟議を書くのは避け、自社データで段階的に検証してください。

Q. 音声AIを入れれば人員を削減できますか。 A. 定型問い合わせの自動化で人の負荷は下げられますが、エスカレーション対応・監視・改善の人手は残ります。「人がゼロになる」前提の投資回収計画は危険です。まず取消可能な回答業務から始め、効果を測って範囲を広げるのが安全です。

Q. OpenAI以外の選択肢はありますか。 A. あります。重要なのは製品名より「ポリシー・ガードレール・承認済みアクション・評価」という運用の型を実現できるかです。国内ベンダーと別スタックで同じ型を組む選択肢も十分に現実的です。要件を固めておけば、どの選択肢にも同じ発注書が使えます。

Q. 何から始めるべきですか。 A. 入電・チャットの内容分類（棚卸し）です。件数の多い定型問い合わせを特定し、自動化に値する業務量があるかを判定してから、狭い範囲でPoCを設計します。

Q. 失敗しやすいのはどこですか。 A. 承認済みアクションの線引きを曖昧にしたまま高影響操作をAIに許すこと、評価指標を解決率だけにすること、いきなり全業務を対象にすることの3つです。段階設計と合格条件で回避できます。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、製品を選ぶ前に第三者の視点で要件を整える段階です。

ベンダーから音声AI・AIエージェントの提案を受けたが、自社に適正か判断できない
AI電話対応を入れたいが、承認済みアクションの線引きや段階設計を自社で描けない
過去にチャットボットやIVR改善がPoCで止まった経験がある
見積もりの「一式」が妥当か、追加費用の条件が読めない

GXOは特定製品の販売代理ではなく、AIエージェントの設計・運用とAI・システム開発の要件整理、そして発注前の第三者検証を組み合わせて、「どのベンダー経由で・いくらで・何から着手するか」を発注側の立場で整理します。まずは自社の業務に本当に自動化余地があるかをAI導入の適合度診断・要件整理で確かめ、必要に応じて導入相談・セカンドオピニオンの問い合わせへお進みください。製品の発表に急かされて発注するのではなく、要件を持って発注する側に回ることが、PoC止まりと追加費用を避ける最短路です。