OpenAI ハーネスエンジニアリング：Codex を活用した手動コードゼロ開発

OpenAI は、約100万行のコードを含む内部ソフトウェア製品を、ヒューマンが手動で書いたコードを一行も含まずに構築・出荷することに成功しました。Codex エージェントを活用することで、チームは従来の手動コーディングに比べて開発時間を約1/10に短縮し、人間の役割をコードを書くことから、エージェントの自律性を可能にする環境、仕様、フィードバックループの設計へとシフトさせました。

「手動で書かれたコードなし」実験

2025年8月に、少人数のエンジニアチームが Codex（GPT-5 によってガイド）を使用して、初期リポジトリのスキャフォールドや CI 設定からアプリケーションロジック、ドキュメント、内部ツールまでをすべて生成しました。5か月間で、チームは3人から7人に拡大し、約1,500件のマージ済みプルリクエスト（PR）を管理しました。

このアプローチの主な成果は次のとおりです:

高スループット: エンジニア1人あたり1日平均3.5件のPR。
包括的生成: エージェントは製品コードやテストだけでなく、プロダクションダッシュボード定義、評価ハーネス、リポジトリ管理に使用されるスクリプトも生成しました。
Human-in-the-Loop の指揮: 人間は作業の優先順位付け、ユーザーフィードバックを受け入れ基準に変換、結果の検証に関与し続けましたが、コードを直接書くことはありませんでした。

エンジニアリング役割の再定義：コーディングからスキャフォールドへ

エージェント優先のワークフローでは、主なエンジニアリングのボトルネックはエージェントの能力ではなく、環境の仕様です。OpenAI は、環境が不十分に指定されると進捗が停滞し、人間は「深さ優先」の作業に注力することが判明しました。すなわち、上位目標を小さな構成要素に分解し、エージェントの作業を可視化かつ強制可能にするツールを作成することです。

エージェント間ワークフロー

人間は主にプロンプトを通じてシステムとやり取りします。PR を完了させるために、Codex に以下を指示します:

自身の変更をローカルでレビューする。
ローカルおよびクラウドで追加のエージェントレビューを要求する。
フィードバックに基づいて反復し、すべてのエージェントレビュアが満足するまで続ける。

時間が経つにつれ、チームはほぼすべてのレビュー作業をエージェント間のやり取りにシフトし、人間による PR レビューの必要性を最小化しました。

エージェント向けアプリケーション可視性の向上

人間の QA の負担を減らすため、OpenAI はアプリケーションの内部状態を Codex が直接読み取れるようにすることに注力しました。これにより、エージェントは人間の介入なしにシステムを推論できます。

ランタイムアクセス: アプリは git worktree ごとに起動可能で、Codex は変更ごとに分離されたインスタンスを起動できます。
UI バリデーション: Chrome DevTools Protocol をエージェントランタイムに組み込むことで、Codex は DOM スナップショットやスクリーンショットを使用してバグを再現し、UI 動作を検証できます。
可観測性: エージェントはローカルの可観測性スタックにアクセスでき、LogQL でログを、PromQL でメトリクスをクエリし、特定のパフォーマンス目標（例：サービス起動が800ms未満で完了すること）を満たすことができます。

リポジトリ知識を記録システムとして

OpenAI は、モノリシックな指示マニュアルはエージェントにとって効果が薄く、タスクコンテキストを圧迫しすぐに陳腐化すると判明しました。その代わりに「マップ」アプローチを実装しました:

AGENTS.md を目次として: 約100行の短いファイルが、より深い真実の情報源へのポインタを提供します。
構造化ドキュメント: docs/ ディレクトリが記録システムとして機能し、インデックス化された設計ドキュメント、アーキテクチャマップ、製品ドメインの品質評価を含みます。
実行計画: 複雑な作業はバージョン管理された実行計画に記録され、意思決定ログがリポジトリにチェックインされます。
機械的強制: 専用のリンターと「doc-gardening」エージェントが、ドキュメントと実際のコード動作が同期したままであることを保証します。

アーキテクチャと「テイスト」の強制

完全にエージェント生成されたコードベースでアーキテクチャのドリフトを防ぐため、OpenAI は実装詳細を細かく管理するのではなく、厳格な機械的制約を採用しています。

固定アーキテクチャモデル

各ビジネスドメインは、厳密に検証された依存方向を持つ固定レイヤーシステムに従います: Types $\rightarrow$ Config $\rightarrow$ Repo $\rightarrow$ Service $\rightarrow$ Runtime $\rightarrow$ UI。横断的関心事（例：認証、テレメトリ）は、明示的な「Providers」経由でのみ入ります。

テイスト不変条件

カスタムリンターは「テイスト」および信頼性要件を強制します。例:

スキーマ/タイプの構造化ロギングと命名規則。
ファイルサイズの上限。
境界パーシング（例：Zod を使用）により「YOLO スタイル」のデータ探索を防止。

エントロピーと「AI スロップ」の管理

完全な自律性は、最適でないパターンの再現につながる可能性があります。OpenAI は継続的な「ガーベジコレクション」プロセスでこれを管理します:

ゴールデン原則: 主観的な機械的ルールがリポジトリにエンコードされています。
自動クリーンアップ: 背景の Codex タスクが定期的にこれらの原則からの逸脱をスキャンし、リファクタリング PR を作成します。これらは短時間の人間レビューの後、自動マージされることが多いです。

現在の能力と将来の未知数

システムは、Codex が新機能をエンドツーエンドで駆動できる閾値に達しました。単一のプロンプトから、エージェントはコードベースを検証し、バグを再現（失敗のビデオを記録）し、修正を実装・検証（解決のビデオを記録）し、フィードバックに応答した後に変更をマージできます。

OpenAI は、内部リリースではうまく機能したものの、数年にわたるアーキテクチャの一貫性がどのように変化するか、またモデルがより高性能になるにつれてシステムがどのように適応するかは未知であると指摘しています。