「賢さ」ではなく「どこで動くか」の勝負になってきた
homulaは、エンタープライズ企業のAIエージェント導入を、データの置き場所やセキュリティ境界まで含めて設計するAIインテグレーターです。特定のベンダーやモデルに縛られず、自社にとって最適な構成を選べるようにすることを支援の軸にしています。
2026年6月11日（米国時間）、OpenAIはクラウド実行基盤を手がける Ona（旧Gitpod） の買収を発表しました（OpenAI: OpenAI to acquire Ona）。一見すると「コーディングエージェントCodexの強化」という地味な話に見えますが、これは数週間前にAnthropicが打ち出した動きと同じ場所に着地した出来事です。フロンティアの2大ラボが、ほぼ同時に「エージェントをどこで実行するか」という一点に投資を集中させ始めた——本記事ではこの収束が何を意味するかを、一次情報ベースで整理します。
エージェント競争はこれまで「どのモデルが賢いか」を軸に語られてきました。しかし本番導入の現場で最後に問われるのは賢さではなく、ファイルの書き込み・APIコール・社内DBへの問い合わせといった「実行」が、自社のセキュリティ境界の内側で起きるのか外側で起きるのかです。情報システム部門が首を縦に振るかどうかは、いつもここで決まります。
OpenAIは「顧客が制御する実行環境」を買いに行った
OpenAIによれば、Codexの最も価値ある仕事は「数分」ではなく「数時間〜数日」かけて進むようになっており、利用者が作業を始めた端末に縛られず、より大きな仕事を委ねられるようにしたい——というのが買収の動機です（OpenAI: OpenAI to acquire Ona、CNBC）。Codexの週間利用者は 500万人超、年初から 400%増 と報じられており、その負荷を本番品質で支える実行基盤が必要になったという文脈です。
Onaは独・旧Gitpodを母体とするスタートアップで、CEOのJohannes Landgraf氏らのチームがOpenAIのCodex部門に合流します。注目すべきはその技術の性格です。Onaが提供する 「顧客が制御する実行モデル（customer-controlled execution model）」 では、エージェントは組織自身のクラウド環境の内側で動作し、OpenAIは知能とオーケストレーションを供給するという役割分担になります。これにより、企業はインフラ・データ・セキュリティ境界に対する制御を保ったまま、Codexにできることを狭めずに済む、という設計です。
Landgraf氏の言葉が今回の本質を端的に表しています。
エージェントに必要なのは知能だけではない。信頼できる作業環境（trusted workspace） が要る。
OpenAIのCore ProductsリードThibault Sottiaux氏も「Onaは、最高水準の信頼とスケールで運用する顧客に向けて、Codexを本番ワークフローへ安全に展開しやすくする」とコメントしています。買収はクロージング条件・規制当局の承認を前提とし、金額は非開示です。
ポイントは「OpenAIが実行基盤を“作る”のではなく“買った”」ことです。モデルを持つラボがわざわざ企業を買収してまで実行レイヤーを取りにいくということは、ここが片手間の機能ではなく戦略的な構造になった、という何よりの証拠です。
Anthropicは数週間前に同じ設計を出していた
この動きは突然ではありません。Anthropicは先行して、Claude Managed Agents向けに 自己ホスト型サンドボックス（self-hosted sandboxes） と MCPトンネル（MCP tunnels） を発表しています（Anthropic: New in Claude Managed Agents、The New Stack）。その核心は、エージェントを2つの層に切り分けたことにあります。
- エージェントループ（オーケストレーション・コンテキスト管理・エラー復旧） は、引き続きAnthropicのインフラ上で動く。
- ツール実行（コマンド実行・ファイル書き込み・APIコールなど外界へ働きかける一切） は、自社インフラ、あるいはCloudflare・Daytona・Modal・Vercelといったマネージドプロバイダ上の、顧客が制御する環境へ移せる。
さらにMCPトンネルにより、エージェントは社内ネットワーク内のMCPサーバーを公開せずに到達できます。軽量ゲートウェイが外向きに1本だけ接続を張る方式で、インバウンドのファイアウォール開放も公開エンドポイントも不要、通信は端から端まで暗号化されます。
整理すると、OpenAIとAnthropicは表現こそ違え、まったく同じ結論にたどり着いています。
| OpenAI（Ona買収） | Anthropic（自己ホスト型サンドボックス） | |
|---|---|---|
| ベンダー側に残すもの | 知能・オーケストレーション | エージェントループ・コンテキスト管理 |
| 顧客境界内に置くもの | 実行環境・データ・セキュリティ境界 | ツール実行・ファイル・社内システム接続 |
| 手段 | 企業買収（旧Gitpod） | 製品機能（ベータ／リサーチプレビュー） |
| 狙う課題 | 数時間〜数日の長時間タスクの本番展開 | 実行と内部システムを境界の外に出さない |
Anthropic側の機能論と「コントロールプレーンが新しい競争軸になる」という論点は、以前の記事AIエージェントの「実行場所」を自社に取り戻すで詳しく扱いました。本記事の主眼は、そこにOpenAIがM&Aという最も重い投資手段で合流したことで、これが一社の特徴ではなく業界の構造になった、という点にあります。
なぜ「実行プレーン」が主戦場になるのか
エージェントの構成要素は、おおまかに「考える層（制御プレーン）」と「動く層（実行プレーン）」に分けられます。これまで競争は前者——モデルの賢さ——に集中してきました。しかし本番導入で詰まるのは、決まって後者です。理由は3つあります。
第一に、データと権限が実行プレーンに集中するから。 賢さはAPI越しに借りられますが、社内ファイル・認証情報・本番APIへのアクセスは実行が起きる場所に紐づきます。ここが境界の外にあると、監査・DLP・アクセス制御が効きません。
第二に、エージェントが「長く走る」ようになったから。 Codexの仕事が数時間〜数日に伸び、Anthropicも数日規模の自律実行を可能にしつつある今、その間ずっとどこかで実行環境が生き続けます。長時間・無人で動く処理ほど、実行場所の隔離・監視・巻き戻しが品質とリスクを左右します。
第三に、ここがロックインの分岐点になるから。 実行プレーンを特定ベンダーのオーケストレーションに固定すると、モデルやベンダーを乗り換える自由を失います。逆に実行と接続を自社標準として握れば、上に載せる「知能」は差し替え可能な部品になります。
裏を返せば、各ラボが実行レイヤーを取りにいくのは、そこが次のロックインポイントだからでもあります。便利な純正実行環境にそのまま乗ると、「知能の差し替え自由」と引き換えに「実行基盤の依存」を抱え込みかねません。便利さと中立性のトレードオフを意識して選ぶ必要があります。
エンタープライズ購買担当者の判断軸
ベンダーの純正実行環境は確かに楽です。しかし「楽だから乗る」と「設計として選ぶ」は違います。実行プレーンを評価するときの最低限の問いを挙げます。
- 実行は自社境界の内側に置けるか。 ファイル・認証情報・社内システム接続が、物理的に自社が制御する環境で完結するか。プロバイダ任せでも、ネットワークポリシーと監査ログが自社のものとして効くか。
- オーケストレーションと実行を分離できるか。 「知能」と「実行」が疎結合で、モデルやベンダーを替えても業務側を作り直さずに済むか。
- 誰が・何をしたかを一貫して追えるか。 どのモデル・どのエージェントが、どのデータに触れ、何を実行したかを、RBAC・承認フロー・監査ログで横断的に追跡できるか。
- 長時間タスクを安全に止められるか。 数時間〜数日走る処理を、隔離・監視し、必要なら途中で止めて巻き戻せるか。
純正の実行環境は1や4を満たしやすい一方、2の「中立性」では弱くなりがちです。便利さ（純正）と入れ替え可能性（中立）のどちらを優先するかを、業務の重要度ごとに決めておくことが、この時代の購買判断の核になります。
homulaの観点——実行プレーンを「自社の資産」にする
homulaの支援では、この実行プレーンを特定ベンダーに預けきらず、自社側の標準として設計することを基本にしています。
実装の中心は Agens（AIエージェント実行基盤）です。AgensはLLMベンダーに依存しないMulti-LLM設計で、ツール接続はMCPで共通化（200以上のツールと構築ゼロで接続）、実行は隔離されたサンドボックスで行い、成果はフォルダとして会社の資産に残ります。OpenAIやAnthropicが示した「思考はベンダー、実行は自社境界」という分離を、特定の純正環境に固定せずに実現するという発想です。
統制面は Agens Control が担います。承認フロー・DLP・5年分の監査ログ・RBACにより、どのモデルを選んでも「誰が・どのデータに触れ・何を実行したか」を一貫して追跡できます。長時間・無人で走るエージェントが当たり前になるほど、この「実行の統制」が効くかどうかが、本番に乗せられるかの分かれ目になります。エージェントに任せる業務範囲と権限設計の考え方は、関連記事サブエージェントへの委譲と長時間自律やデータ主権とAIエージェントもあわせてご覧ください。
まず着手すべきは、最も価値が高く、かつ実行が境界の外に出ては困る業務を1つ選び、実行プレーンを自社境界内に置いた小さな本番を作ることです。homulaのブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で行い、この「最初の1本」を安全に立ち上げます。
まとめ
- 2026年6月11日、OpenAIが Ona（旧Gitpod） を買収。Codexの数時間〜数日規模の仕事を、顧客が制御する実行環境で本番展開できるようにする狙い
- これはAnthropicの 自己ホスト型サンドボックス＋MCPトンネル と同じ設計——「オーケストレーションはベンダー、実行とデータは自社境界内」への収束。ラボがM&Aまでして取りにいく以上、これは機能ではなく業界構造
- 競争軸はモデルの賢さ（制御プレーン）から、どこで動かすか（実行プレーン） へ移りつつある。データ・権限・長時間タスクのリスクがここに集中するため
- 購買判断の核は、純正実行環境の便利さと、ベンダー中立な入れ替え可能性のトレードオフを業務ごとに決めること。実行プレーンを自社の標準＝資産として握れば、上に載せる「知能」は差し替え可能な部品になる
「自社のどの業務を、どこで実行させるべきか」——実行プレーンの設計を、セキュリティ要件と合わせて一緒に描きませんか。