OpenAI、Codexでの保守の事例を公開　5人で80万行削除

OpenAIは、社内のエンジニアがコーディングエージェント「Codex」に、使わないコードや終わった実験の後片付けをさせた事例を開発者ブログで公開した。5人が2週間、ほかの仕事の合間に進め、1400本を超えるプルリクエスト（PR）をマージし、80万行以上を消したという（会社の申告）。日本時間17日には、ChatGPTのエージェント「dot」に深夜の障害対応を手伝わせた例もXに投稿した。手元のリポジトリで何から試せるかを整理する。

短い頼み方で証拠まで集める

ブログを書いたのは、社内の実験基盤を作るCore Experimentationチームのロドリゴ・ロイム氏だ。ブログのページの日付は10月14日で、本人とOpenAI DevelopersがXで紹介したのは日本時間17日の未明から朝にかけてだった。

一つ前のGPT-5.6 Solでは、調べる範囲と確認の基準を細かく指定する必要があった。GPT-6 Astraでは「使っていないコードを探して片付けて。Slackや機能フラグの管理画面など、確認に要るものは何を見てもいい」という短くあいまいな頼み方で動いたという。Astraは過去のPR、Slackのスレッド、社内の課題管理を読み、本番の性能計測の表で、消す行が実際には一度も呼ばれていないことを確かめた。消す理由も1件ずつ説明したので、レビューが速くなったとしている。

成果の例として、あるサービスのコンテナイメージが3.31GBから1.72GBへ48％小さくなり、テストの画面スナップショットが約400種類減ったと書いている。

古い実験フラグとCIの待ち時間

もっと難しいのが、終わった実験の後片付けだ。実験のコードは本番でまだ動いていることがあり、静的解析だけでは判断しにくい。ロイム氏はAstraと相談しながらプロンプトを作らせ、「本番の動きは変えない」「緊急停止用のフラグは残す」「1件ごとに小さな下書きPRを作る」と条件をつけた。最後はリポジトリ全体を調べさせ、CPUの使用量まで見て優先順位をつけた報告書を出させた。

何年も誰も気づかなかった実験が、大きなCPUを食っていた例もあった。全機能のフラグに一括でつながる1行のPythonコードで、Astraはコストを調べたうえで、管理画面で「恒久」の印がついていたため人に判断を回した。消した結果、主なサービスでCPUを約0.42％減らせたと見積もっている。

CIでは、負荷を減らす案を1日あたりに節約できる分数で並べさせ、約30本のPRを入れた。CIが終わるまでの時間の中央値は約10分から4.5分に、90パーセンタイルは12.5分から6分に縮んだという。

安いモデルで足りるかを比べる

個人や小さなチームにいちばん役立つのは、モデルの比較だ。6000を超えるファイル、100万行のディレクトリで同じプロンプトを走らせ、ロイム氏が結果を確かめた（API標準料金、会社の申告）。

• GPT-6 Astra Ultra：109.06ドルで142件、1件あたり0.77ドル
• GPT-6.1 Sol Ultra：15.12ドルで131件、1件あたり0.12ドル
• GPT-6.1 Sol Medium：5.27ドルで86件、1件あたり0.06ドル

Sol UltraはAstraの92％の件数を14％の費用で出した。取りこぼしの多くは、ほかのフラグの前提として使われている値の固定したフラグだった。こうした見落としの型をプロンプトで補えば安いモデルでも近づけるが、新しいモデルが出たらプロンプトを見直すべきだとしている。

試す順番として、使っていないコード1か所、古いフラグ1つ、不安定なテスト1本のような小さな作業から始めるよう勧めている。Codexに証拠を集めさせて小さな下書きPRを出させ、うまくいけばサブディレクトリ、次にリポジトリ全体へ広げる。不安定なテストの修正、AGENTS.mdの指示の見直し、CIの負荷を減らす案出しに使うプロンプトの全文も載っている。

dotが夜中の障害対応を担う（Xのみ）

OpenAI Developersは日本時間17日朝、「dotを当番に」とXに投稿した。社員のアリ氏が午前3時の障害対応にdotを使い、dotが原因を調べてCodexのスレッドを立て、アリ氏はスマートフォンのChatGPTアプリからその作業に指示を出したという。ChatGPTの公式ヘルプによると、10月5〜9日の更新で、dotはCodexで作業を始めたり既存のスレッドを続けたりできるようになった。ただ、障害の中身や、dotが解決まで届いたかは投稿に書かれていない。

編集部の見方

この事例は、OpenAI社内の大きなリポジトリで、Slackや本番の計測データにつながった環境での話だ。手元の小さなリポジトリで同じ数字が出るとは限らない。それでも「頼み方は短くてよいが、証拠と安全の条件は書く」「安いモデルと高いモデルを同じ仕事で比べる」という2点は、そのまま使える。まずはSol Mediumで不安定なテスト1本から試し、出てきた下書きPRを自分の目で確かめるところから始めたい。