OpenAIのOna買収、Codex長時間実行基盤の焦点

OpenAI は 2026年6月11日、Ona を買収する合意を発表した。OpenAI の説明では、Ona の安全なクラウド実行・オーケストレーション技術を Codex のエコシステムへ取り込み、長時間動くエージェントが企業の管理下で作業できるようにすることが狙いである。

この発表は、単なる買収ニュースとして読むより、Codex の実行基盤がどこへ向かうかとして読むほうが実務に近い。OpenAI は Codex が週 500万人超に使われていると説明し、作業が数分ではなく数時間から数日に伸びていると述べた。つまり、Codex は「ローカル端末上の補助ツール」から、途中で人間が確認し、判断し、レビューしながら進む持続的な仕事の基盤へ近づいている。

この流れは、OpenAI Codex支出管理 や OpenAI CodexのOracle Cloud調達 で見た企業導入の論点と同じ線上にある。さらに Codex rate limits障害の耐障害設計 を踏まえると、長時間実行では性能だけでなく、実行場所、停止条件、監査、費用、代替手順までまとめて設計する必要がある。

事実: OpenAIはOnaをCodexチームに迎える

OpenAI の発表によると、Ona は secure cloud execution と orchestration technology を持つ会社であり、買収完了後に Codex チームへ加わる予定だ。取引は通常の完了条件と必要な規制承認の対象で、完了までは OpenAI と Ona は別会社として独立して運営される。

OpenAI が強調したのは、Codex に「persistent place to work」を与えることだ。Codex の仕事が長くなれば、開始した端末に人間が張り付く運用は限界に来る。ノートPCを閉じても、別の場所へ移動しても、作業が企業の環境内で進み、人間が進捗確認、方向修正、意思決定、レビューを行える必要がある。

Ona 側も、OpenAI 参加の理由をクラウド上の企業向け実行環境として説明している。Ona の記事では、年初から週次 agent session が production で 13倍に伸びたこと、銀行、製薬、政府系ファンドなど要求水準の高い組織で使われていることが示された。ここでの焦点は、AI が賢いかどうかだけではない。企業のシステムが実際に存在する場所で、文脈、アクセス、ツール、状態を持って作業し、その進捗を見える形にすることだ。

事実: 長時間実行には環境と統制が必要になる

OpenAI は、企業が agent を production workflow に入れるには、モデルだけでは足りないと説明している。必要になるのは、どこで動くか、何へアクセスできるか、認証情報をどうスコープするか、活動をどうログに残すか、作業をどうレビューへ渡すかである。

Ona の説明も同じ方向を向いている。Ona は、agent には context、access、tools が必要であり、安全な環境の中で versioning、review、audit、sharing ができなければならないと述べている。さらに、customer cloud 内への deployment、scoped credentials、audit trails、agent orchestration、runtime AI security を、cloud agents に必要な構成要素として挙げている。

ここで重要なのは、OpenAI が「OpenAI 側のクラウドにすべて任せる」とだけ言っているわけではない点だ。発表では、Ona の customer-controlled execution model により、agent が組織自身の cloud environment 内で動き、OpenAI が intelligence と orchestration を提供する構図が示されている。日本企業にとっては、データ境界、ログ、ID管理、ネットワーク、秘密情報管理を自社の統制とどう接続するかが焦点になる。

分析: Codexの競争軸はモデルから実行基盤へ広がる

ここからは分析である。

Codex の評価は、これまで「どれだけコードを読めるか」「どれだけテストを書けるか」「どれだけ修正できるか」に寄りがちだった。しかし長時間実行が前提になると、競争軸はモデル性能だけでは済まない。agent が安全に滞在できる実行環境、途中状態の保持、権限の分離、レビュー導線、停止手段、ログの可観測性が重要になる。

日本の開発組織では、この変化が特に効く。委託先、社内開発、SaaS、オンプレミス、プライベートクラウド、GitHub、社内チケット、脆弱性管理が混在しやすいからだ。Codex に長い仕事を任せるほど、リポジトリだけでなく、仕様書、設計判断、障害履歴、CI/CD、チケット、秘密情報、社内規程へ近づく。単に「AIに作業を投げる」ではなく、AI 作業者をどの業務環境に入れるかの設計になる。

この意味では、OpenAI Codex Security と同じ課題が出てくる。脆弱性対応でも、agent はコードを読み、再現し、修正案を出し、人間レビューへ渡す。Ona 買収で見えているのは、そのような作業を一時的なセッションではなく、企業の管理下にある持続的な環境へ移す方向性だ。

分析: 日本企業は「便利な自動化」より先に責任分界を決める

長時間実行の価値は分かりやすい。夜間にテストを回す、巨大リポジトリを調べる、移行計画を分解する、脆弱性修正を準備する、複数ツールをまたいで調査する。人間が画面の前にいない時間も進むなら、開発リードタイムは短くなる可能性がある。

ただし、日本企業が先に決めるべきなのは「何を自動化するか」だけではない。責任分界である。agent が企業クラウド内で実行されるなら、その環境を誰が管理するのか。認証情報は誰の名義で発行するのか。読み取りと書き込みをどう分けるのか。失敗した変更、過剰なアクセス、情報持ち出し、費用超過、レビュー漏れが起きたとき、どのチームが止めるのか。

この論点は、支出管理とも直結する。長時間実行は便利だが、計算資源、モデル利用、クラウド環境、CI 実行、外部 API 呼び出しを消費する。Codex支出管理の設定 と切り離して考えると、PoC では便利でも本番展開で説明しにくくなる。利用上限、予算、作業キュー、優先度、緊急停止を同じ運用表に置くべきだ。

導入前に確認するチェックリスト

第一に、長時間実行させる対象を分類する。テスト実行、コード調査、ドキュメント整理、脆弱性修正、依存更新、移行作業では、必要な権限と許容リスクが違う。最初は read-only に近い調査や、低機密リポジトリのテスト修正から始めるほうがよい。

第二に、実行環境の所有者を決める。Ona のような customer-controlled cloud environment を使う場合でも、クラウドアカウント、ネットワーク、ログ保管、秘密情報管理、環境イメージ更新を誰が見るのかを曖昧にしてはいけない。

第三に、認証情報をスコープする。agent に人間の強い権限をそのまま渡すのではなく、リポジトリ、チケット、CI、デプロイ、ドキュメントごとに必要最小限の権限を切る。書き込みや本番操作は、原則として人間レビューを通す設計にする。

第四に、監査ログを先に設計する。どのデータを読み、どのコマンドを実行し、どのファイルを変更し、どの提案を出し、誰が承認したかを追える必要がある。金融、医療、公共、製造では、成果物よりも説明責任のほうが導入判断を左右する場面がある。

第五に、停止条件を決める。長時間動く agent は、期待通りに進まないときも長時間動けてしまう。時間、費用、エラー回数、権限要求、危険操作、レビュー未完了をトリガーに、どこで自動停止または人間確認へ戻すかを決めるべきだ。

まとめ

OpenAI の Ona 買収は、Codex を長時間動く企業エージェントへ近づける発表である。事実としては、買収は完了条件と規制承認の対象であり、完了後に Ona チームが Codex チームへ加わる予定だ。OpenAI と Ona の説明を合わせると、狙いは安全で永続的なクラウド環境、顧客管理型の実行、スコープ済み認証情報、監査、レビューを Codex の実務基盤にすることだと読める。

日本企業が見るべきなのは、「Codex がさらに便利になる」という表面だけではない。長時間実行を許すほど、クラウド環境、ID、権限、費用、監査、レビュー責任を先に決める必要がある。Codex の次の導入判断は、モデル比較ではなく、AI 作業者を安全に働かせる開発基盤設計になる。

出典

• OpenAI to acquire Ona - OpenAI
• Ona is joining OpenAI - Ona