OpenAI Presence発表から考える、AIエージェントのガードレール設計

AIエージェントの導入で難しいのは、モデルに何ができるかを確認することだけではありません。

何を許可し、どの条件で個別承認を求め、どの時点で処理を止めて人へ引き継ぐのかを、実際に運用できる形へ落とし込む必要があります。

2026年7月22日、OpenAIは企業向けのAIエージェント運用製品「OpenAI Presence」を発表しました。

Presenceは音声・チャットのエージェントを対象に、ポリシーと標準業務手順(SOP)、ガードレール、事前に許可された操作、シミュレーション、評価ツール、Codexを使った改善プロセスを一体化した製品と説明されています。

今回の発表で明らかになったのは、ガードレールの詳細な技術実装ではなく、企業向けエージェントを本番運用するうえで必要となる構成要素です。

本稿では、公開された範囲から読み取れる設計要素を手がかりに、Presenceに限らず、AIエージェントを導入する企業が自社側で詰めるべき実務論点を整理します。

対象は、Presenceの導入を検討している企業だけでなく、他社製品や自社開発でエージェントにガードレールを組み込もうとしている実務者全般です。

Presence自体の料金体系や音声認識の性能など、製品仕様の網羅的な解説は本稿の対象外とします。

なお実務では、「何を、どこで、どの条件で止めるのか」まで具体化することが課題になります。

OpenAIが「運用基盤」として切り出したもの

OpenAIの説明によれば、PresenceはAIモデル単体ではなく、企業が顧客対応や社内のサービスリクエスト対応にAIエージェントを投入するための運用基盤です。

企業側は、エージェントが何を実行できるか、どの場面で承認が必要か、どの場面で人が引き継ぐかを定義します。

これに対してガードレールは、やり取りが企業の定めた境界外へ進んだ場合に介入できると説明されています。

本番投入前にシナリオをシミュレーションするツールや、投入後の挙動を評価する仕組みも一体で提供されるといいます。

もう一点、OpenAIの説明で目を引くのが、自社のコーディングエージェントCodexを使った継続的な改善のプロセスです。

本番セッションやエスカレーション、品質シグナルから見つかった課題を、Presenceプラグインを使うCodexが調査し、更新案を提示します。

企業側のチームは、その変更を本番稼働中のバージョンと比較してテストし、承認したうえで管理された形で展開します。

発表文では、本番運用から得たシグナルをもとに更新案を作成し、テストと承認を経て反映するプロセスが説明されています。

OpenAIはこの基盤を自社の英語対応の電話サポートに既に投入しており、着信した問い合わせ案件の75%を人の支援なしで解決していると発表しています。

現在、Presenceは対象となる企業顧客向けの限定一般提供プログラムとして提供されています。

導入はOpenAIのForward Deployed Engineers(FDE)と一部のグローバルシステムインテグレーターが主導し、セルフサービス製品としてはまだ提供されていません。

導入を検討する企業は、OpenAIのアカウントチームへ問い合わせる形です。

許可範囲・個別承認・実行時制御を分けて考える

私たちがこの発表を読んで最初に注目したのは、モデルの性能ではなく、権限と承認の置き方です。

ガードレールの実装というと、すべてのやり取りを人が事前承認する方式を思い浮かべがちですが、それでは対応件数の多い定型業務でAIエージェントを使う意味が薄れてしまいます。

Presenceの発表から読み取れるのは、すべての処理を一律に人が事前承認するのではなく、エージェントが自律的に実行できる範囲、個別承認を必要とする条件、人へ引き継ぐ条件をあらかじめ分けて設計する考え方です。

ガードレールについては、やり取りが企業の定めた境界外へ進んだ場合に介入できると説明されています。

この分離ができていれば、全件を確認するのではなく、例外案件、高リスク操作、変更承認などに人の時間を集中させやすくなります。

私たちは、この構成を四つの層に分けて考えると整理しやすいと考えています。

一つ目はポリシーで、何を許可し、何を禁止するかです。

二つ目は認可・承認で、どの操作を自律実行でき、何に個別承認が必要かです。

三つ目は実行時の強制で、実際に禁止操作や上限超過を止められるかです。

四つ目は評価・変更管理で、本番前後の評価、更新、承認、ロールバックをどう行うかです。

特に重要なのは、エージェントや運用基盤側のガードレール判定と、CRM・決済・チケット管理といった接続先システム側の権限制御を区別することです。

たとえば、エージェントが「この返金は許可範囲内」と判断しても、接続先システム側でも金額上限、対象顧客、操作回数、本人確認、書き込み権限などを強制できなければ、障害や誤判定時の影響を限定できません。

ただし、この設計が機能する前提は、「境界」自体が具体的に定義されていることです。

境界が曖昧なままガードレールだけ導入しても、何を検知すればよいかが定まらず、結局すべてを人が見るか、逆に何も検知できずに素通りするかのどちらかに寄ってしまいます。

ここは製品を導入する側の宿題であり、ベンダーの機能だけでは埋まりません。

私たちは、分析・提案と、意思決定と、実行を、それぞれ別の権限として分けて設計することを重視しています。

人を承認工程に置くだけでは、品質向上は保証されない

Presenceの改善プロセスでは、Codexが提示した更新案を、企業側のチームがテストして承認したうえで反映すると説明されています。

人による承認工程を置くこと自体は重要です。

ただし、それだけで人とAIの組み合わせによる成績向上が保証されるわけではありません。

Vaccaroらによる系統的レビューとメタ分析(Nature Human Behaviour誌、2024年)では、人間とAIの組み合わせは平均すると人間単独より高い成績を示した一方、人間単独とAI単独のうち成績の高い方には及びませんでした。

また、意思決定を伴うタスクでは、組み合わせによる成績低下がみられました。

ただし、この研究が扱っているのは主にタスクの成績であり、安全性やPresenceの変更承認プロセスを直接評価したものではありません。

ここから言えるのは、「人を工程に加えれば自動的に相乗効果が生まれるわけではない」という限定的な点です。

この研究から、Presenceの承認画面に何を表示すべきかが直接導かれるわけではありません。

一方、変更管理の実務としては、承認者が少なくとも、変更差分、変更理由、影響するポリシー、テスト結果、既存ケースへの回帰影響、ロールバック条件を確認できることが望ましいと私たちは考えます。

変更理由や影響範囲、評価結果が十分に示されない場合、承認は形だけの通過点になり、「人が検証・承認する」という安全弁も実質的には機能しにくくなります。

製品を評価する際は、この承認画面が何を提示するのかを具体的に確認する価値があると私たちは考えます。

対象業務のリスクは異なりますが、変更案を作成し、テストし、人が承認したうえで反映するという変更管理の形は、私たちが自社のコンテンツ運用で採用している考え方とも共通します。

「75%」という数字の読み方

もう一つ、数字の扱いには注意が必要です。

OpenAIは、自社の英語対応電話サポートにおいて、着信した問い合わせ案件の75%を人の支援なしで解決していると発表しています。

ただし、これはOpenAI自身の一つのサポート窓口における発表値であり、Presenceの一般的な導入効果を示すベンチマークではありません。

業種、問い合わせの複雑さ、既存のFAQやナレッジの整備度合いによって、解決できる割合は大きく変わります。

対象となる言語とチャネルは示されていますが、「解決」の判定基準、正確な集計期間、問い合わせの構成、除外条件などは、発表文からは確認できません。

この75%はOpenAIによる公表値であり、少なくともOpenAIの公式発表には、測定方法の詳細や第三者検証に関する記載はありません。

導入を検討する際は、自社の問い合わせ内容に近い条件でのシミュレーション結果を、個別にベンダーへ確認することをお勧めします。

導入前に分けて考えたい3つの制御レイヤー

自社でガードレール付きのAIエージェントを導入する際、何を製品の設定に任せ、何を自社側で用意すべきかを整理する叩き台を一つ示します。

あくまで一例であり、実際にどこに線を引くかは、業務のリスクの大きさ・取り消しのしやすさ・自社の体制に応じて各社が決めることです。

制御レイヤー	主に決めること	確認しておきたいこと
業務ルール・組織	許可する操作、禁止する操作、個別承認が必要な条件、人へ引き継ぐ条件	例外条件まで具体化されているか。承認者、対応期限、承認者不在時の扱い、定期的な見直しが決まっているか
エージェント運用基盤	ポリシーとSOPの適用、シミュレーション、評価、逸脱検知、通知、エスカレーション、変更管理	見逃しと過剰介入をどう評価するか。制御機能が動かない場合に処理を止めるか。変更前後を比較できるか。段階展開とロールバックが可能か
接続先システム	実際に読み書きできる情報と実行可能な操作を制限する	最小権限になっているか。参照と更新を分けているか。金額・回数・対象の上限、許可リスト、本人確認、監査ログが製品設定とは別に強制されているか

ここで重要なのは、ガードレールによる検知と、接続先システムによる強制を同じものと考えないことです。

エージェントや運用基盤側の境界判定が誤った場合でも、接続先の認可、金額上限、許可リスト、操作回数制限などによって影響を限定できる構造が必要です。

ガードレールは、ID管理、アクセス制御、入力検証、監査、停止・復旧手段を代替するものではありません。

まとめ

OpenAI Presenceの発表から得られる実務的な示唆は、ガードレールを一つの機能として捉えるのではなく、ポリシー、操作権限、個別承認、実行時の強制、エスカレーション、評価、変更管理を組み合わせて設計する必要があるという点です。

製品側にガードレール機能があっても、許可範囲が曖昧であれば、過剰な介入か見逃しのどちらかが増えます。

また、接続先システムの権限が広すぎれば、エージェント側の判定を誤った際の影響を限定できません。

導入検討の第一歩として、自社業務について次の五つを表にすることをお勧めします。

AIが閲覧できる情報、自律実行できる操作、個別承認が必要な操作、必ず人へ引き継ぐ条件、接続先システム側で禁止・制限する操作です。

Presenceを含む運用基盤を評価する際は、ガードレールの有無だけでなく、これらの条件をどの層で定義し、どの層で強制し、変更後の挙動をどのように検証・承認・復旧できるかまで確認する必要があります。

情報確認について

本記事は、OpenAIの公式発表「Introducing OpenAI Presence」(2026年7月22日)、および Michelle Vaccaro、Abdullah Almaatouq、Thomas W. Malone による「When combinations of humans and AI are useful: A systematic review and meta-analysis」(Nature Human Behaviour、第8巻、2293〜2303頁、2024年)を主要な参照元として、2026年7月23日に確認して作成しています。

Presenceに関する75%などの性能値はOpenAIによる発表値であり、一般的な導入効果を示すものではありません。

提供条件、対象地域、機能、料金などは今後変更される可能性があります。

最新の情報はOpenAIの公式発表でご確認ください。