9月16日、The Pragmatic Engineerが「Inside OpenAI's agentic software factory」と題した記事を公開した。OpenAIが自社の開発フローをCodexエージェントで全面移行した実態と、それに伴うエンジニアリング組織・インフラの変容について、VP of Engineeringをはじめとする社内リーダー7名への取材をもとに詳しく紹介している。エンジニアリング部門だけでなく、財務・法務・採用といった非エンジニア部門までがCodexを日常的に使う体制が、上からの指示なしに自発的に形成されたという事実は、AIエージェント導入の議論において一つの到達点を示している。
Codexが「空気」になったOpenAI社内
記事の取材対象はOpenAIのエンジニアリングリーダー7名。VP of Engineering、ChatGPT担当エンジニアリングHeadなど、実務の中心にいる人物たちだ。
取材を通じて明らかになったのは、財務・法務・採用といった非エンジニア部門も含め、OpenAI全社員がほぼ週次でCodexとChatGPT Workを使用しているという点だ。上からの「使え」という指示なしに、自発的に移行が進んだとされる。
元記事に掲載されたトークン使用量のグラフによれば、2025年1月以降、非エンジニア部門のCodex利用率が急上昇している。記事中では具体的な利用率の数値も示されているが、詳細は元記事のグラフを直接確認していただきたい。
OpenAI社内のCodex利用状況（部門別）。出典: OpenAI
Desktop Lead のAndrew Ambrosino はこう表現する。
「ここ数ヶ月の大きなテーマは、あらゆるものがコーディングエージェントになったことだ。最終的なアウトプットがコードかどうかに関わらず、エージェントが成果物を書く。」
なぜ非エンジニアまで使うようになったのか
採用の経緯には3つの要因がある。
① 長時間・複雑タスクへの対応。Codexに /goal 設定が追加され、ゴールを設定すれば完了まで動き続けるようになった。この変更後、利用率が大きく跳ね上がったとされる。Engineering Lead（Productivity担当）のAkshay Nathanは「能力のオーバーハング（モデルは高性能なのに使われていない状態）が、今は認知のギャップに変わった」と説明する。Slackの監視やAirtableの更新にも使えると気づいた人が口コミで広めている。
② ロール別プラグインの配布。各チームが自分たちの業務に特化したワークフローをプラグインとして作成・共有した。「空っぽの箱を渡すだけでは使われない」というのがAndrewの認識だ。
③ ドメインエキスパートのエンジニアチームへの組み込み。モデルが一部領域でエンジニアより詳しくなった結果、スライドデッキや財務レポートの「良し悪し」を判断できる業務専門家をエンジニアチームに常駐させる体制が生まれた。
IDEの位置づけの変化とPRの再発明
2025年1月以降、IDE利用が低下している。 Codexアプリ（Macは2月、Windowsは3月にリリース）がIDEの代替として機能し始めたためだ。
Andrew自身、2024年12月時点では「CodexアプリはiPadのような失敗作になるかもしれない」と懸念していたと明かす。CLIとIDEの中間に位置するツールが市場で生き残れるかを疑っていた。しかし実際は、「AIエージェントが高度化するほどIDEの重要性は下がる」という直感が正しかった。
より深刻な変化はプルリクエスト（PR）とコードレビューの在り方だ。VP of EngineeringのVenkat Venkataramaniは現状をこう説明する。
「エンジニア1人あたりのPR数がホッケースティック状に増加している。ビルド・テスト・デプロイのパイプライン全体が、劇的に高い負荷にさらされている。一部のシステムでは約10倍の負荷増だ。多くの企業なら2〜3年かけて起きる成長が、OpenAIでは6ヶ月で起きている。」
この状況を受け、コードレビューの再設計が進んでいる。インフラエンジニアとセキュリティエンジニアが全変更を個別レビューするのはこれまで非現実的だったが、エージェントを使えばそれが可能になる。さらに「変更をプロダクションまで手を繋いで連れていく」エージェントも構築中で、監視グラフの観察から専用ダッシュボードの構築まで自律的にこなす。
モバイルアプリが最大のボトルネック
皮肉なことに、最もCodexの恩恵を受けにくいのがネイティブモバイルアプリの配信だ。
コードはエージェントが数分で書けるようになった。しかしiOS/Androidへの反映にはApple・Googleの審査プロセスが必要で、数時間〜数日かかる。ChatGPT Head of EngineeringのSulman Choudhryは「Codexの利用はモバイルファーストなのに、コードをユーザーの手元に届けるスピードがまったく追いついていない」と指摘する。
「ソフトウェアが数分で書けるなら、それを電話に届けるのに何日も待つのはますます馬鹿げた話に見えてくる。今の我々はその理想から程遠い。」
App Storeの審査プロセスはモバイルアプリ配信の構造的な制約であり続けており、AIによる開発速度の向上がその制約をより鮮明に浮かび上がらせている。※この点についてOpenAIが具体的な解決策を持っているわけではなく、業界全体の課題として記事内でも提起にとどまっている。
"ソフトウェアファクトリー"という概念
OpenAIはこの仕組みを「ソフトウェアファクトリー」と呼ぶ。自動車工場でロボットと人間が協業するように、AIエージェントと人間が協業して継続的にソフトウェアを生産する体制だ。
その具体例が Perf Factory。本番環境のパフォーマンスを常時監視し、問題を検出すると自動的にCodexエージェントを起動して修正を試みるフィードバックループだ。こうした「エージェントが別のエージェントを呼ぶ」構造が、OpenAIの開発インフラに組み込まれつつある。
ソフトウェアファクトリーという発想自体は以前から議論されてきた概念だが、実際の大規模プロダクション環境への適用事例として、本記事が紹介するOpenAIの実態は数少ない具体的な報告の一つだ。同様のエージェント活用の先行事例としては、Ramp社のInspect AIエージェントが参考になる。また、OpenAIによるCodexの公式発表も合わせて参照されたい。
エンジニアの仕事はどう変わるか
記事では「エンジニアリングの専門分化が薄れ、判断力と自律性がより重要になる」という見解が示されている。以前なら数チームが必要だったリライトや移行作業が、1〜2人のエンジニアで完遂できる事例が出始めている。
OpenAI内部では無制限のトークン予算でCodexを使えるが、外部向けCodexの機能は社内版より大幅に制限されている点は留意が必要だ。社内版はほぼすべてのOpenAIシステムに接続されており、外部公開版とは異なる「深い統合」がなされている。
詳細はInside OpenAI's agentic software factoryを参照していただきたい。
