まず結論：Presenceは今すぐセルフサーブで触れる製品ではない
2026年7月22日、OpenAIは法人向けエージェント基盤「Presence」を発表した。名前だけ見るとAPIキーを発行して今日から使えそうだが、実際は違う。Presenceは限定GA（Limited General Availability）として提供され、導入はOpenAIのForward Deployed Engineers（FDE）と一部のグローバルSIが個別にリードする、コンサルティング色の強い形態を取っている。self-serveでサインアップして触れるプロダクトではない。
この記事では「今すぐ使えるかどうか」の先、つまりPresenceが何をどう組み立てているかを実装者視点で分解する。すでに手元にあるAgents SDKとRealtime APIで自前構築する場合との違い、Codexを使った継続改善ループの中身、そして自前実装とPresenceのどちらを選ぶべきかの判断軸まで見ていく。ROIや雇用への影響といった経営判断の話はここでは扱わない。
Presenceを構成する6つのビルディングブロック
OpenAIの公式発表では、Presenceは次の要素の組み合わせだと説明されている。
“Presence brings together the components teams need to run agents in production: policies and standard operating procedures, guardrails, approved actions, simulations, evaluation tools, and a Codex-powered improvement process”
複数の技術メディアの報道を突き合わせると、実質的には以下の6レイヤーで構成されていると理解できる。
- ポリシー・標準業務手順書（SOP） — エージェントが従うべき業務ルールの定義
- ガードレール — 会話が想定範囲を逸脱した際に介入する安全装置
- 承認済みアクション — エージェントが実行してよい操作のホワイトリスト
- エスカレーションルール — いつ・どの条件で人間に引き継ぐかの判定ロジック
- シミュレーション・評価ツール — ポリシー変更を本番投入前にテストする環境
- Codexによる改善プロセス — 本番ログから修正案を継続的に提案する仕組み
ここで重要なのは、モデルの推論力そのものは主役ではないという点だ。OpenAIが強調しているのは「製品・ポリシー・顧客の行動が変わっても、エージェントの挙動を予測可能に保つ」ための運用レイヤーであり、モデルはその上に乗る一部品にすぎない。
自前で組むなら — Agents SDK・Realtime APIとの対応表
上記6レイヤーは、実は既存のAgents SDKやRealtime APIにも概念としては存在する。何が違うかというと、Presenceは「それらをどう組み合わせて業務ポリシーに落とし込み、テストし、継続的に直していくか」という運用プロセスごとパッケージ化している点だ。対応関係を整理すると次のようになる。
| Presenceの構成要素 | 自前実装での対応（Agents SDK / Realtime API） | 何が違うか |
|---|---|---|
| ポリシー・SOP | Agentのinstructions＋外部ナレッジ（RAG） | Presenceは業務手順書ベースでの管理・更新フローを提供 |
| ガードレール | @input_guardrail / @output_guardrail |
自前は関数を書く。Presenceは設定として管理する想定 |
| 承認済みアクション | Tools定義＋Human-in-the-Loop承認フロー | Presenceは承認済みアクションのカタログを一元管理 |
| エスカレーションルール | handoff() |
Presenceは条件付きエスカレーションを設定レベルで定義 |
| シミュレーション・評価 | 自作のevalハーネス（LangSmith等の外部ツール併用も一般的） | Presenceは評価環境が組み込み |
| 継続的改善ループ | 自作（ログ分析→修正案作成→テスト→反映のパイプライン） | PresenceはCodexが分析・修正案の提案までを肩代わり |
| 音声・チャットチャネル | Realtime API（WebRTC / WebSocket / SIP） | Presenceはチャネル運用込みで提供 |
ガードレールとエスカレーションの部分は、Agents SDKの公式ドキュメントに実際のコード例が載っている。たとえばガードレールは、入力または出力を評価する関数をデコレータで登録する形だ。
@input_guardrail
async def math_guardrail(
ctx: RunContextWrapper[None], agent: Agent, input: str | list[TResponseInputItem]
) -> GuardrailFunctionOutput:
result = await Runner.run(guardrail_agent, input, context=ctx.context)
return GuardrailFunctionOutput(
output_info=result.final_output,
tripwire_triggered=result.final_output.is_math_homework,
)
エスカレーション（Presence用語）に相当するのは、Agents SDKではhandoff()による別エージェントへの引き継ぎだ。
from agents import Agent, handoff, RunContextWrapper
from pydantic import BaseModel
class EscalationData(BaseModel):
reason: str
async def on_handoff(ctx: RunContextWrapper[None], input_data: EscalationData):
print(f"Escalation agent called with reason: {input_data.reason}")
handoff_obj = handoff(agent=agent, on_handoff=on_handoff, input_type=EscalationData)
音声チャネルについては、VoicePipelineで作る音声AIエージェント完全ガイドで解説した通り、Realtime APIはブラウザ向けのWebRTC、サーバー向けのWebSocket、電話網接続向けのSIPという複数のトランスポートを提供している。Presenceが担っているのは、この上にポリシー・ガードレール・エスカレーションを載せて「1つの運用可能な製品」に仕立てる部分であり、トランスポート層そのものを再発明しているわけではない。ガードレール単体の設計判断についてはAIエージェントガードレール比較2026も参照してほしい。
Codexによる継続改善ループの中身
Presenceで最も実装者的に興味深いのが、この継続改善ループだ。OpenAIは自社の英語電話サポート回線にPresenceを使っており、75%の着信を人間の介在なしに解決していると説明している。さらに、Codexが本番のセッション記録とエスカレーション（人間への引き継ぎ）を分析して修正案を提案する仕組みにより、導入から10日以内に有人転送率を15ポイント削減したと述べている。
ここで重要な注意点がある。この数字はOpenAI自身が自社の運用実績として発表したものであり、第三者機関による監査は入っていない。効果があったこと自体を疑う理由はないが、「どんな環境でも同じ削減幅が出る」という保証ではない点は踏まえておくべきだ。
OpenAIが公表している範囲で、このループの流れは次のように整理できる。
- 本番セッションとエスカレーションのログをCodexが分析する
- Codexが修正案（ポリシー・プロンプト・ガードレールの調整案）を提案する
- 人間のチームがシミュレーション環境でその修正案をテストする
- 問題がなければ人間が承認し、本番に反映する
もし自前でこの継続改善ループを再現するなら、少なくとも次の要素をゼロから構築する必要がある。
- 本番セッション・エスカレーションのログ収集基盤 — 会話ログとエスカレーション発生理由をひも付けて保存する仕組み
- エスカレーション理由のラベリング — なぜ人間に引き継がれたのかを分類できる状態にする
- 修正案を生成するエージェント — CodexやCLIコーディングエージェントを使い、ログを読んでプロンプト・ポリシーの差分案を作らせる
- 安全にテストするためのシミュレーション／評価ハーネス — 修正案を本番投入する前に再現テストする環境（自作、またはLangSmith等の外部ツール）
- 人間のレビューゲートとロールバック手順 — 承認フローとバージョン管理、問題発生時に戻せる仕組み
Presenceが肩代わりしているのは、この一連のパイプラインを「業務ポリシー変更の継続改善サイクル」として製品化した部分であり、Codexというコーディングエージェントそのものを差分提案役として使う発想自体は、自前構築でも応用できる。
自前実装 vs Presence — 判断軸
ここまでの整理を踏まえると、「自前でAgents SDK・Realtime APIを組むか」「Presenceの限定GAを待つ・申し込むか」の判断は、次の3つの軸で考えると整理しやすい。
| 判断軸 | 自前実装が向くケース | Presenceが向くケース |
|---|---|---|
| ガバナンス要件 | 規制業種でも自社で監査ログ・承認フローを完全に統制したい | OpenAIのシミュレーション・評価の仕組みごと使いたい（先行検証にはBBVA・Insurance Australia Groupなどの規制業種も含まれる） |
| 対応言語・音声の複雑さ | すでに日本語特化のRAG・音声パイプラインの知見がある | 日本語対応も含めた検証をベンダー側に任せたい（SoftBankが日本語対応をトライアル中） |
| エスカレーション設計の複雑さ | 自社の業務フローが独特で、汎用的な承認・引き継ぎ設計に収まらない | 継続改善ループ（ログ分析→修正案→テスト→反映）を自作するコストを避けたい |
加えて実務的な前提として、Presenceは限定GAでありFDE主導の個別導入になるため、「今すぐ試して比較する」という選択肢自体が現時点では取りにくい。したがって当面は、Agents SDKとRealtime APIで自前構築しつつ、ガードレール・エスカレーション・継続改善の設計を上記の対応表に沿って作り込んでおき、Presenceの提供範囲が広がったタイミングで乗り換えるかどうかを判断する、という段階的なアプローチが現実的だろう。エスカレーション設計そのものの詳細はHuman-in-the-Loop完全ガイド、監査ログの設計はAIエージェントの監査ログ設計で扱っているので、自前実装を進める場合はあわせて参照してほしい。
よくある質問
Q. OpenAI Presenceは今すぐセルフサーブで試せますか？
いいえ。2026年7月時点では限定GA（Limited General Availability）として提供されており、OpenAIのForward Deployed Engineersと一部のグローバルSIが個別に導入をリードする形態です。APIキーを取得して自分で組み込むセルフサーブ製品ではありません。
Q. Presenceの構成要素は何ですか？
OpenAI公式は「ポリシー・標準業務手順書（SOP）、ガードレール、承認済みアクション、シミュレーション、評価ツール、Codexによる改善プロセス」の組み合わせと説明しています。加えてエスカレーションルールも中核要素として複数のメディアで報じられています。
Q. Agents SDKやRealtime APIで自作するのと何が違いますか？
ガードレールやエスカレーション（handoff）に相当する概念的な部品はAgents SDKにも存在します。違いは、それらを業務ポリシーに落とし込み、シミュレーションでテストし、継続的に改善するという運用プロセス一式をPresenceがパッケージとして提供している点です。
Q. Codexによる改善ループとは具体的に何をしていますか？
OpenAIの説明では、本番セッションとエスカレーションの記録をCodexが分析して修正案を提案し、人間のチームがシミュレーションでテスト・承認してから本番に反映する、という流れです。自社の英語サポート回線では導入10日以内に有人転送率を15ポイント削減したとOpenAIは述べていますが、この数字は自己申告であり第三者監査は入っていません。
Q. どんな企業が先行検証していますか？
BBVA（メキシコの銀行窓口向け音声サポート）、SoftBank（日本語対応のトライアル）、Insurance Australia Group（自然災害時の顧客対応）の名前が挙がっています。ただしいずれも検証・パイロット段階であり、OpenAIが本番稼働の実績として挙げているのは自社のサポート回線のみです。
関連記事・次に読む
- VoicePipelineで作る音声AIエージェント完全ガイド2026 — Realtime APIの音声チャネル実装を詳しく解説
- OpenAI Agents SDK TS比較｜Python版との違い — Agents SDK自体の実装選択肢を比較
- Human-in-the-Loop完全ガイド｜エージェント承認設計【2026】 — エスカレーション・承認設計の実装パターン
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
参考・出典
- Introducing OpenAI Presence — OpenAI公式発表（2026-07-22）
- OpenAI Presence | OpenAI Help Center — 提供形態・FAQ（参照日: 2026-07-27）
- OpenAI unveils Presence — VentureBeat（参照日: 2026-07-27）
- OpenAI Presence connects AI agents to enterprise data with built-in guardrails — Help Net Security（参照日: 2026-07-27）
- OpenAI tries the consulting path with ‘Presence’ — The Register（参照日: 2026-07-27）
- Guardrails – OpenAI Agents SDK — 公式ドキュメント（参照日: 2026-07-27）
- Handoffs – OpenAI Agents SDK — 公式ドキュメント（参照日: 2026-07-27）
- Voice agents | OpenAI API — Realtime API公式ドキュメント（参照日: 2026-07-27）
まとめ
OpenAI Presenceは「新しいモデル」ではなく「運用プロセスの製品化」だ。ガードレール・エスカレーション・継続改善という、AIエージェントを本番で回すために誰もが結局作ることになる仕組みを、OpenAI自身がFDE主導でパッケージ化して提供している。ただし現時点では限定GAでセルフサーブではないため、大半の開発チームにとっての現実的な選択肢は、Agents SDKとRealtime APIで同等のレイヤーを自前で組みながら、Presenceの提供範囲拡大を注視することになる。自前で組む場合は、本記事の対応表をチェックリストとして、ガードレール・エスカレーション・継続改善の3点から設計を始めるとよい。
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。100社以上の企業向けAI研修・導入支援。著書累計31,000部突破。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
