10月16日、OpenAIが「Maintaining software with the GPT-6 family」と題した記事を公開した。80万行超のコードを2週間で削除提案・マージ、コンテナイメージを48%縮小、CIのmedian完了時間を55%短縮、特定テストスイートでは実行時間を95%削減——これらはすべて、OpenAIのCore Experimentationチームが自社コードベースで実施したAI活用コードメンテナンスの実測値だ。同チームによる現場の知見として、GPT-6ファミリーとCodexを用いたワークフローの詳細が紹介されている。

Core Experimentationチームは社内の実験基盤ソフトウェアの構築・保守を担当している。記事の核心となるワークフローは「短いプロンプトを起点に、エージェントが証拠を集めて削除候補を提案し、エンジニアがレビューしてマージする」というものだ。AIが自律的にコードを書き換えるのではなく、発見・提案をAIが担い、判断・承認を人間が担うという役割分担が一貫している。

800k行削除：不要コードの大規模クリーンアップ

最も注目すべき事例が、GPT-6 AstraをCodex上で使った不要コードの削除だ。

ここで登場する「Codex」は、OpenAIが提供するコード実行エージェント基盤であり、かつてのCodex APIとは別物である点に注意が必要だ。エージェントがリポジトリ上でツールを呼び出しながら自律的に調査・PR作成を行う環境として機能している。

従来、不要コードの検出には静的解析ツールとランタイムログを組み合わせた複雑なシステムが必要だった。しかし以前のモデルでも、「調査対象と検証基準を明示したプロンプト」を与えれば、静的解析を自前で書かせて不要コードを除去できることが分かっていた。

GPT-6 Astraではさらに一歩進めた。「どこを調べるか」「何を証拠とするか」をモデル自身に判断させる、あえて曖昧な短いプロンプトを与えた。Astraは過去のPR、Slackスレッド、社内プロジェクトトラッカー、本番環境のパフォーマンスプロファイリングテーブルを自律的に調査し、「この行は本番で一度も実行されていない」という証拠を揃えた上で削除を提案した。各削除の根拠も説明したため、コードレビューが加速したという。

結果として、5人のエンジニアが2週間（主業務の合間）で1,400件以上のPRをマージし、80万行超のコードを削除した。定量的な効果として、あるサービスのコンテナイメージが3.31GBから1.72GBへ48%縮小し、別のクリーンアップではテストスイートからビジュアルスナップショットのバリアントを約400件削除できた。

静的解析が苦手な「陳腐化した実験フラグ」の検出

より難しい問題がstale experiment（陳腐化した実験コード）のクリーンアップだ。未使用コードと違い、陳腐化した実験コードは本番でまだ動作しており、eligibility evaluation（フィーチャーフラグの適用条件評価）に依存しているため静的解析では検出しにくい。

ここでも短いプロンプトからスタートし、Astraにブレインストーミングをさせながら、対象コードベース全体をスキャンするプロンプトを段階的に磨いた。Astraは各stale experimentのCPUコストを計測し、優先度付きのレポートを生成した。

印象的な具体例がある。数年前に作られたStatsigのフィーチャーフラグ（内部開発者が他のすべてのフラグをオーバーライドできるもの）が、全フィーチャーへのマッピングによって大量のCPUファンアウトを引き起こしていた。Astraはこれを発見したが、フラグ管理コンソールで「Permanent」と明示されていたため、自動削除せず人間によるレビューを提案した。確認の結果、フラグを削除し、主要サービスで約0.42%のCPU削減を実現した。この「Permanentフラグを見て自動削除しない」という判断はAIによるものであり、人間のレビューを促す設計がワークフローとして機能していることを示す好例だ。

GPT-6 Astra vs GPT-6.1 Sol：コスト比較

同チームはGPT-6.1 Solで同じワークフローを試し、コストと検出数を比較した。対象は6,000ファイル以上・100万行超（Python、TypeScript、Go、Rust）のコードベースだ。

表中の「Ultra」「Medium」はOpenAI APIのreasoning effortパラメータに対応する設定値で、Ultraほど推論に多くのトークンを費やし、精度は上がるがコストも増える。

GPT-6.1 Sol UltraはAstra Ultraの92%の検出数を、コストは14%で達成した。差異を分析すると、モデル間の主な違いは「他のフィーチャーフラグに依存している定数フラグ」の検出有無で、Astraは検出できたがSolは見落とす傾向があった。こうしたエラーパターンをプロンプトで補正することで、安価なモデルでも同等の結果に近づけられると記事では述べている。コストと検出精度のトレードオフを定量的に把握したうえでモデルを選択できる点は、実務運用における重要な知見だ。

CI最適化への応用

記事後半では、同様のアプローチをCI（継続的インテグレーション）の最適化にも適用した結果が紹介されている。約30件のCI最適化PRをマージした結果、CIのmedian完了時間が約10分から4.5分へ、90パーセンタイルが12.5分から6分へ短縮した。

特筆すべきはモックの欠落修正だ。単一の変更で、63テストからなるresolverスイートの実行時間が592.6秒から29.8秒へ、95%削減された。不要コードの削除と同様に、AIが問題箇所を特定・提案し、エンジニアがレビューしてマージするワークフローをそのまま転用できた点が、このアプローチの汎用性を示している。CI改善はコードベースのクリーンアップと比べて効果が即座に開発体験へ直結するため、優先的に着手するタスクの候補として検討する価値がある。

実践的なアドバイス

記事の締めくくりでは、自分のコードベースで試す場合の進め方が示されている。

1. 小さなタスク（未使用コード1件、陳腐化したフラグ1つ、flaky test 1件）から始める
2. モデルとreasoning effortレベルを比較し、安価な設定で十分か確認する
3. コードレビューのフィードバックをプロンプトに反映させながら、サブディレクトリ→全体へ段階的に拡張する

「提案の中には、期待されるメリットに見合わない複雑さを追加するものもあった」とも率直に述べており、優先度付けと効果測定がワークフローの重要な要素であると強調している。AIの提案をそのまま受け入れるのではなく、コストとメリットを判断するエンジニアの目が依然として不可欠だというのが、この大規模実践から得られた正直な結論だ。

詳細はMaintaining software with the GPT-6 familyを参照していただきたい。