OpenAIがOnaを買収、Codexのcloud環境が変わる件

OpenAIがOnaを買収するというアナウンスを読んで、まず「あー、そっちに舵切ったか」と思った。
Onaはセキュアで永続的なクラウド環境を提供する会社で、OpenAIはそこをCodexと組み合わせてlong-runningなAIエージェントを動かせる基盤にしようとしている。
enterpriseのworkflowをまるごとエージェントに任せる、という方向性がはっきり見えた。

Codexが「実行環境込み」になる意味

今まで自分がCodex（というかGPT-4系のcode completion）を使うとき、コード生成はLLMに任せて、実行・確認は手元かCI上でやるという分断があった。
Onaが入ることで、その「実行」の部分をセキュアなクラウド環境ごとOpenAIが持とうとしている。
つまり「コードを書いてもらう」だけじゃなくて「書いて・実行して・フィードバックを拾って・また書く」というループをエージェントが自律でまわせるようになる設計だ。

これ、個人開発でも地味にえぐい影響があると思った。
自分は今、SaaSのサイドプロジェクトとして小さなデータパイプラインを一人で管理しているんだけど、cronで動かしてるスクリプトが落ちたときの原因調査とかをLLMに投げてもあくまで「推測」しか返ってこない。
実行環境にアクセスできないから当然なんだが、Codexがcloud環境と一体化したら、そこが変わる可能性がある。

自分のコードのどこが影響を受けるか

現状のパイプラインはこんな構成で動いている。

# 今のローカル実行フロー（簡略）
python fetch_data.py --date $(date +%Y-%m-%d)
python transform.py --input raw/ --output processed/
python load_to_db.py --source processed/

これをGitHub Actionsに乗せていて、失敗したらSlackに通知が飛ぶだけ。
エラーログを見て自分でデバッグするという作業が毎回発生する。
long-runningなエージェントが「ログを読む→原因を特定する→修正PRを作る」までやれるなら、自分がやることがかなり減る。

一方で、気になる点もある。
セキュアな永続環境と言っても、enterprise寄りの設計だろうから個人プランでどこまで使えるかは不透明だ。
OpenAIのAPIコストも、エージェントがループをたくさんまわせばまわすほど跳ね上がる。
今でもGPT-4oを使ったバッチ処理でトークン数を気にしながらプロンプトを削ってるのに、実行ループを自律で動かされたらコスト管理が難しくなる気がした。

チームでも少し話した。
同僚のバックエンドエンジニアは「エージェントが勝手にPRを作るのはまだ怖い、レビューなしでmainに入ったら終わり」と言っていた。
それはそう。
エージェントに自律性を与えるほど、どこで人間が介入するかの設計が問われる。
Codexのcloud環境が「どこまでを自律で動かしていいか」のpermission設計をどう提供するかが、実務での採用判断にかかってくると思った。

# こういうpermission境界の設定がAPIで来たら使いたいイメージ
agent:
  allowed_actions:
    - read_logs
    - create_branch
    - open_draft_pr
  denied_actions:
    - merge_to_main
    - deploy_to_production
    - delete_resources

妄想込みではあるけど、こういう粒度でコントロールできないと怖くて本番環境には向けられない。

とりあえず次にやること

Onaの買収が完了してCodexに統合されるまでの間、自分がやれることは今のうちにエージェントに渡しやすいコードの構造を整えておくことだと思っている。
ログの出力形式を揃える、スクリプトの責務を小さく分割する、エラーをexception typeで明確に分類する、といった地味な作業だ。
どのみちコードの品質を上げることにはなるので、損はない。

OpenAIがどういうAPIエンドポイントでcloud環境へのアクセスを提供してくるかは、リリースノートを追い続けるしかない。
Codexのdocumentationに変化が出てきたら、すぐとりあえず動かしてみるつもりだ。
コスト面だけはリリース直後に検証してから本番に入れるか判断する、そこだけは慎重にいく。