モデルは配られた。次に売られ始めたのは「統制」そのもの
homulaは、特定のベンダーやツールに縛られず、企業が自社にとって最適なAI構成を選び使い続けられるよう支援するAIインテグレーターです。その立場からこの1か月のニュースを追うと、フロンティア各社の主戦場が「より賢いモデル」から**「そのモデルを本番でどう統制して回すか」**へ、はっきり移動してきたのがわかります。
その象徴が、2026年7月22日にOpenAIが発表した Presence です。これは新しいモデルでも、単なるAPIでもありません。企業がリアルタイム音声・チャットのエージェントを"安全に本番投入して運用する"ための基盤——つまり、これまで各社が手作りで積み上げてきた統制層（ガバナンス・レイヤー）を、そのまま製品にしたものです（OpenAI、VentureBeat）。
何が発表されたか——Presenceが束ねる「本番運用の部品」
Presenceは、エージェントを本番で動かすために企業が必要とする部品を1つのプラットフォームにまとめた、とOpenAIは説明しています。報道から要素を整理すると、次のようになります（Help Net Security）。
- ポリシーと標準手順（SOP）: 会社の規程・業務手順をエージェントの振る舞いに組み込む。
- ガードレールと権限制御: エージェントがどのデータ・どの社内システムにアクセスできるか、どのアクションを実行してよいかを限定する。
- 人間へのエスカレーション規則: 会話やタスクをいつ人間に引き継ぐかをルール化する。
- 事前シミュレーション: 本番投入前に、一般的な問い合わせ・エッジケース・高リスクなシナリオに対してエージェントを試験する。
- 評価ツールとCodexによる改善ループ: 稼働後もCodexが応対を点検し改善案を出す（後述）。
用途としてOpenAIは、カスタマーサポート、アウトバウンドの営業開発、調達、ITサービス、人事などを挙げています。リアルタイム音声は GPT-Live と統合し、最新モデルの更新に追随して進化する設計です。
Presenceは自社内でも稼働しています。OpenAIによれば、自社の英語電話サポート回線で運用され、入電の75%を人間の介入なしで解決しているとのことです（同社の主張）。数字そのものより重要なのは、「モデルを出す会社」が自ら統制付きの本番運用を回して見せているという事実です。
Presenceの正体は「統制層の製品化」
ここで一歩引いて構造を見ると、Presenceが売っているのは賢さではなく**"安全に本番へ出すための足回り"**だと分かります。従来、企業がエージェントを本番投入するとき自前で組んでいたものを、OpenAIが標準部品として提供し始めた——それが本質です。
| 統制の論点 | Presenceが提供する部品 | 企業が本来やっていたこと |
|---|---|---|
| 何にアクセスさせるか | 権限制御（データ・システム単位） | 個別の認可設計・接続管理 |
| 何をさせてよいか | 承認済みアクション（approved actions） | ツール単位の許可リスト |
| いつ人間に返すか | エスカレーション規則 | 手作りの分岐・運用ルール |
| 出す前に確かめる | 事前シミュレーション | テストシナリオの自前整備 |
| 出した後に良くする | Codexの点検＋人間の承認 | 手動のログ分析・改善 |
とりわけ設計思想がよく表れているのが改善ループです。Codexが応対を点検し、弱点を見つけ、振る舞いの改善案を提示する。ただし変更が本番に反映される前に、担当者がテストして承認しなければならない（Help Net Security）。自動で賢くなりっぱなしにせず、人間の承認を挟む——この「human-in-the-loop を製品の中核に据える」姿勢は、企業がエージェント運用でいちばん怖がっている点を正しく突いています。
見落とされがちな条件——それは「自前」ではない
Presenceは魅力的ですが、日本企業が導入を検討するうえで見落としてはいけない前提があります。PresenceはセルフサービスのAPI製品ではありません。導入は OpenAIのForward Deployed Engineer（FDE）と、選ばれたグローバルのシステムインテグレーターが主導する形で提供されます（VentureBeat）。
つまり、統制層が単一ベンダーの製品として提供されるということです。初期顧客には、メキシコの BBVA、日本語エージェントを稼働させた SoftBank Corp.、豪 IAG傘下の Retail Insurance Australia などが並びます。SoftBankの事例が示すとおり、これは日本市場にも直接届く動きです。
便利さの裏で問われるのは、**「自社の統制ルール（誰が・何に・どこまで）を、どのベンダーの製品の中に埋め込むのか」**です。ポリシー・権限・承認・監査は本来、モデルやプラットフォームを乗り換えても持ち運べる自社の資産であるべきもの。統制層を1社の製品に丸ごと預けると、その利便性と引き換えに、将来の乗り換え余地（可搬性）を失いかねません。
日本企業が置き直すべき論点
Presenceの登場は、エージェント導入の重心を**「どのモデルが賢いか」から「統制層を誰が・どこに持つか」へ**動かします。導入判断で押さえるべきは三つです。
- 統制層は自社の資産として設計する。ポリシー・権限・承認・監査ログの要件を、まず製品非依存の言葉で定義しておく。そのうえでPresenceのような製品を"実装の選択肢"として評価すれば、後から別の基盤へ寄せ直しても統制の骨格は崩れません。
- 接続の入口を単一ベンダーに固定しない。Presenceは強力ですが、音声・チャットの応対領域に閉じた提供形態です。社内には他にも多数の業務・ツールがあり、それらを横断する接続と統制は、特定ベンダーの製品外でも一貫して効く枠組みが要ります。
- 人間の承認とエスカレーションを"運用の型"にする。Presenceが人間の承認を中核に据えたのは正しい。だとすれば自社導入でも、承認フロー・エスカレーション・監査を最初から設計に織り込むことが、便利さと安全の両立点になります。この考え方は AIエージェントの統制は『ツール単位』へ とも地続きです。
homulaの観点——統制層はベンダーではなく自社に置く
homulaの基本方針は、どのベンダーのエージェント基盤が勝つかに賭けるのではなく、どれが来ても崩れない「自社の統制層」を先に設計することです。Presenceの登場は、この方針をむしろ後押しします。統制が"製品として売れる価値"だと大手自身が証明したからです。
homulaの Agens は、MCPを活用したエンタープライズ向け統合プラットフォームとして、200以上のツールと構築ゼロで接続します。Presenceが音声・チャットの応対を1社の枠で束ねるのに対し、Agensはベンダー中立の立場で"どのツールを・どの業務に・どの順で開くか"という接続設計そのものを、自社の側に置いたまま整えます。特定モデル・特定基盤に依存しないため、Presenceのような製品を一部に採用しても、統制の骨格を作り込み直さずに済みます。接続設計は MCP活用支援 で扱う領域です。
そして「エージェントに無条件で権限を渡さない」を担保するのが Agens Control です。承認フロー・DLP・5年分の監査ログ・RBACをセットで提供し、誰の・どのエージェントが・どのツールを・どの権限で呼んだかを、ベンダー横断で追える状態をつくります。Presenceが自社製品の"内側"で人間の承認を効かせるのに対し、Agens Controlは製品の外側から、複数ベンダーをまたいで同じ統制を効かせる——これが単一ベンダーへの依存を避けたい日本企業の現実的な守りになります。
導入の順序としては、(1) 自社の統制要件（権限・承認・監査・エスカレーション）を製品非依存で言語化する → (2) 低リスクな応対業務から、Presenceを含む選択肢を実装候補として比較する → (3) Agens Controlで承認・監査・RBACの境界を横断的に設計し、段階的に開く、が現実的です。homulaの AIエージェント・ブートキャンプ では、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で行い、この最初の一歩を素早く形にします。
まとめ
2026年7月22日、OpenAIは音声・チャットのエンタープライズ・エージェント基盤 Presence を発表しました。ポリシー・権限・承認済みアクション・人間へのエスカレーション・事前シミュレーション・Codexによる改善ループ（＋人間の承認）を1つに束ねた、いわば統制層そのものの製品化です。SoftBankの日本語エージェントも稼働し、日本市場にも直接届く動きになっています。
要点は二つ。第一に、フロンティア各社の勝負どころはモデルの賢さから、本番運用の統制へ移った——統制はもはやコストではなく、売れる価値です。第二に、その統制層を単一ベンダーの製品に丸ごと預けるのか、自社の資産として持ち続けるのかが、便利さと可搬性を両立させる分かれ目になります。Presenceのような製品を賢く"部分利用"しつつ、統制の骨格は自社の側に——それが、エージェントの本番化を安全な拡大に変える設計です。
エージェント導入は「どのモデルか」ではなく「統制層を誰が持つか」の勝負になりました。製品の優劣を待つ前に、自社の権限・承認・監査を製品非依存で定義することが、安全な先行のカギです。