OpenAIがOnaを買収｜Codexの更なる長時間実行が実現するか
Codexに長い作業を任せられるなら、開発や社内ツール改善の進め方は変わります。
ただ、Ona買収報道だけで動く前に、公式確認と検証範囲を分けておく必要があります。
OpenAIがOnaを買収すると聞いて、Codexの長時間実行が一気に実用化するのか気になった方も多いはずです。
この買収は、2026年6月11日にOpenAIが公式に発表しました。ただし案件の完了は規制当局の承認後で、Onaの技術がCodexへどう統合されるかの細部はこれからです。
そのため、この記事では「Ona統合でいつ・何ができるようになるか」を先取りで断定しません。
代わりに、OpenAI公式で確認できるCodexのクラウド実行機能をもとに、今すぐ自社業務へ入れてよい範囲と、統合の続報を待つべき範囲を分けて整理します。
OpenAIのOna買収はどこまで確認できるか
まず押さえたいのは、「買収の発表」と「統合の中身」は分けて読むことです。
OpenAIは公式ブログで、Onaの買収に合意したことを発表しています。狙いは、Codexに安全で永続的なクラウド環境を持たせ、手元のPCを閉じている間も長時間のエージェント作業を走らせられるようにすることだと説明されています。一方で、案件の完了は規制当局の承認後で、それまでは両社は独立した会社のままです。
出典: OpenAI公式「OpenAI to acquire Ona」(英語)
要点「買収は公式発表・統合の中身はこれから」を分ける
現時点で安全な書き方は、「OpenAIがOnaの買収を公式発表した(完了は承認後)」と事実を押さえつつ、「Codexで具体的に何がいつ変わるかは続報待ち」と分けて書くことです。導入判断や稟議資料では、この線引きを崩さないほうがよいでしょう。
買収の狙い自体は公式に示されています。
ただし、Onaの技術がCodexへいつ、どの機能名で入るかという統合の細部は、まだ公式に示されていません。だからこそ、現場では「もう統合された前提」で動かないことが大切です。
Codexの長時間実行で今できること
Onaの話をいったん脇に置くと、Codex自体はすでにクラウド上で開発タスクを進めるAIエージェントという位置づけです。
OpenAI公式はCodexを、ソフトウェアエンジニアリング向けに作業を委任できるエージェントとして説明しており、Web、CLI、IDE、cloud tasksという複数の利用面を用意しています。
出典: OpenAI公式「Introducing Codex」(英語)
出典: OpenAI Developers「Codex」(英語)
ここでいう長時間実行は、社内のあらゆる業務をAIが常駐して片づける、という意味ではありません。
GitHubリポジトリに接続し、コード調査、修正、テスト、PR作成のような開発タスクをバックグラウンドで進めるのが中心です。PC操作まで含む別の方向性は、Codex computer useの解説と合わせて見ると切り分けやすくなります。
| 項目 | Codex cloud tasks | Codex CLI | 人間レビュー |
|---|---|---|---|
| 実行場所 | OpenAI側のクラウド環境 | 手元の端末 | 社内の判断工程 |
| 向く作業 | リポジトリ内の調査・修正・PR | 対話的な開発作業 | 要件判断・承認 |
| 強み | バックグラウンド実行と並列化 | 手元環境との近さ | 責任ある最終判断 |
| 注意点 | 権限と外部通信の管理 | ローカル秘密情報の保護 | 作業待ちと属人化 |
つまり、Codexの企業導入で最初に見るべきなのは、「AIに常駐させたい業務」ではなく「リポジトリ内で完結する仕事か」です。
生成AIを会社でどう選ぶか迷っている段階なら、先に生成AIは会社でどれを選ぶべきかのように、用途別の主軸と補完を分けておくと判断がぶれにくくなります。
Ona統合で変わる可能性と、まだ待つべき理由
統合が具体化したときに読者が注目すべき論点は「Codexの実行環境がどれだけ長時間・安定運用に寄るか」です。
AIエージェント常駐業務では、タスクを長く走らせるだけでなく、途中ログ、失敗時の復旧、外部通信、承認フローまで含めて設計する必要があります。
注意未発表の統合を前提に業務設計しない
Onaの統合時期、正式機能名、日本での提供条件は確認できません。「近いうちにできるはず」という前提で本番業務を組むと、予算・担当者・社内説明が先走ります。
ここでの現実的な見方は、OpenAIの投資や買収ニュースを追いながらも、導入判断は今ある公式機能で試せる範囲に限定することです。
AI戦略全体の初動を整理したい場合は、AI戦略に不安がある時の3つの問いも、社内稟議の前段として使いやすいでしょう。
自社で試すなら先に決めること
Codexを試すなら、いきなり本番リポジトリや顧客データに触らせる必要はありません。
検証環境で小さく試すところから始めるほうが、長時間タスク自動化の向き不向きも、社内で必要な権限設計も見えやすくなります。
- 検証用リポジトリを1つ用意する
- 任せる作業を「調査」「小修正」「テスト実行」などに限定する
- 本番DB、顧客情報、APIキーを読めない環境にする
- PRは人間が必ずレビューしてからマージする
- 月次で利用ログと追加クレジットの状況を確認する
この順番なら、失敗しても被害は小さく済みます。
中小企業がAIを始める時も、最初から全社導入を狙うより、1業務を30日で試す設計のほうが定着しやすいため、必要に応じて中小企業がAIを何から始めるべきかの考え方に寄せるとよいでしょう。
| 先に試す | まだ任せない | 理由 |
|---|---|---|
| README整理 | 本番DB変更 | 失敗時の影響が違う |
| テスト追加 | 顧客データ処理 | 個人情報リスクがある |
| 小さなバグ修正 | 決済・請求処理 | 人間承認が必須 |
| PR下書き | 自動マージ | レビュー責任を残す |
特に見落としやすいのは、AIに渡した情報は、あとから「なかったこと」にしにくい点です。
ChatGPT系ツール全般の情報漏洩リスクは、チャットGPT情報漏洩の実例まとめでも整理しているので、Codexを使う前に社内ルールへ落としておく価値があります。
料金・上限は公式ページで確認してから予算化する
Codexの料金で混同しやすいのは、ChatGPTプランの利用枠と、開発者向けの追加クレジットを同じものとして扱うことです。
OpenAI HelpではChatGPTプラン別のCodex利用枠が説明され、OpenAI Developers PricingではCodexのadditional creditsが案内されています。金額や上限は変わる可能性があるため、導入前に公式ページで再確認してください。
出典: OpenAI Help「Using Codex with your ChatGPT plan」(英語)
出典: OpenAI Developers「Codex Pricing」(英語)
メモ現時点では、この記事内で独自のドル換算や月額試算は行いません。公式の利用枠・追加クレジット・組織契約条件を確認し、月次の利用ログと合わせて予算化するのが安全です。
経営判断としては、正式なOna統合を待つより先に、「どの作業ならAIエージェントに渡してよいか」を決めるほうが前に進みます。
OpenAIの発表が更新されたら、その時点で機能名、料金、上限、日本での提供条件を見直せば十分です。
よくある質問
QOpenAIはOnaを本当に買収したのですか?
Aはい。OpenAIは2026年6月11日に、Onaの買収に合意したと公式発表しました。ただし案件の完了は規制当局の承認後で、それまでは両社は独立した会社のままです。「買収は発表済み・完了と統合はこれから」と分けて押さえるのが安全です。
QOna買収でCodexの長時間実行はすぐ強化されますか?
A公式の統合ロードマップは確認できません。既存のCodex cloud tasksは使えますが、Ona由来の具体機能や提供時期は未確認です。
QCodexは常駐AIエージェントとして使えますか?
Aリポジトリ内の開発タスクをバックグラウンドで任せる用途には向きます。ただし社内業務全般の常駐処理には、権限設計、レビュー、外部通信管理が必要です。
QCodex cloud tasksとCodex CLIは何が違いますか?
ACodex cloud tasksはOpenAI側のクラウド環境でタスクを進める形、Codex CLIはローカル端末で対話的に使う形です。長時間実行や環境分離を重視するなら、クラウド側の仕様確認が欠かせません。
Q中小企業は今すぐCodexを業務導入すべきですか?
Aいきなり本番業務に入れるより、検証用リポジトリで小さな修正・テスト・ドキュメント整備から試すのが現実的です。顧客情報や本番権限を渡すのは後回しにします。
Q料金はどこを見ればよいですか?
AChatGPTプラン別の利用枠はOpenAI Help、追加クレジットや開発者向け情報はOpenAI Developers Pricingで確認します。金額や上限は変わる可能性があるため、導入前に公式ページを再確認してください。
結論として、Ona買収は追う価値のある動きです。
ただし、今の経営判断では、すでに公式に使えるCodex機能だけで小さく検証し、統合の続報が出るまでは本番業務を預けすぎないことが現実的です。
