ハーネスエンジニアリング：エージェント優先の世界でCodexを活用する

手動で書かれたコードをゼロにする転換

OpenAIは 手動で書かれたコードをゼロ行 で内部ソフトウェア製品を開発・出荷することに成功しました。5か月間で、少人数のエンジニアチームがCodexエージェントを用いてアプリケーションロジック、テスト、CI設定、ドキュメント、可観測性ツールを生成し、約100万行のコードベースを作り上げました。チームは、このエージェント優先アプローチにより開発時間が手動コーディングに比べて約1/10に短縮されたと見積もっています。

このモデルでは、人間はもはやコードの主要な作者ではなく、舵取り役として機能します。エンジニアリングの役割は、システム設計、意図の指定、エージェントが信頼できる作業を行うために必要なフィードバックループの構築へとシフトしました。

エンジニアリング役割の再定義：コーディングから足場作りへ

人間がコードを書くのをやめると、主要なエンジニアリング課題は エージェントが有用な作業を行えるようにすること になります。そのために必要なツール、抽象化、内部構造を提供します。

システム優先開発

実験の初期は環境が不十分に指定されていたため進捗が遅かったです。これを克服するため、エンジニアは深さ優先アプローチを採用しました：大きな目標を小さな構成要素に分割し、エージェントにそれらを構築させ、得られたブロックを使ってより複雑なタスクを解放します。失敗が起きたときの解決策は、プロンプトを「もっと頑張らせる」ことではなく、どの機能やツールが欠けているかを特定し、エージェントに提供することでした。

エージェント駆動ワークフロー

人間は主にプロンプトを通じてシステムとやり取りします。典型的なワークフローは次の通りです：

エンジニアがタスクを記述する。
エージェントが実行し、プルリクエスト（PR）を作成する。
エージェントがローカルで自分の変更をレビューし、追加のエージェントレビューを要求する。
エージェントが人間またはエージェントからのフィードバックに基づいて反復し、すべてのレビュアーが満足するまで続ける。

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

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

人間のQAがボトルネックになるのを防ぐため、OpenAIはアプリケーションとそのテレメトリをCodexエージェントが直接読めるようにすることに注力しました。

UI 可読性: Chrome DevTools Protocol をエージェントランタイムに組み込み、git worktree ごとにアプリを起動可能にすることで、エージェントはインスタンスを起動し、バグを再現し、修正を検証し、DOM スナップショットやスクリーンショットを用いて UI 挙動を推論できます。
可観測性可読性: エージェントはローカルかつ一時的な可観測性スタックにアクセスできます。LogQL でログを、PromQL でメトリクスをクエリできるため、たとえば「サービス起動が800ms未満で完了することを保証する」などのパフォーマンス系プロンプトに対応できます。

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

エージェントのパフォーマンスは正確なコンテキスト管理に依存します。OpenAIは、モノリシックなマニュアルがタスク固有のコンテキストを埋もれさせ、すぐに陳腐化するため逆効果であることを発見しました。

マップ vs. マニュアル

巨大な指示ファイルの代わりに、チームは約100行の短い AGENTS.md ファイル（目次）を使用します。このマップはエージェントを構造化された docs/ ディレクトリへ誘導し、そこが記録システムとして機能します。この手法により 段階的開示 が可能となり、エージェントは小さなエントリーポイントから始め、より深い情報の所在を学びます。

知識の機械的強制

ドキュメントのドリフトを防ぐため、チームは以下を導入しています：

専用リントツールと CI ジョブ：知識ベースが最新かつ相互リンクされていることを検証します。
Doc‑gardening エージェント：古くなったドキュメントをスキャンし、実際のコード挙動に合わせて修正 PR を自動で作成します。

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

100万行規模のエージェント生成コードベースで一貫性を保つため、OpenAIは個々の実装を細かく管理するのではなく、厳格なアーキテクチャ不変条件を適用します。

固定アーキテクチャ層

各ビジネスドメインは固定された層に分割され、依存関係の方向は厳密に検証されます：Types → Config → Repo → Service → Runtime → UI。横断的関心事（例：auth、telemetry）は明示的な「Providers」経由でのみ入り、これらの制約はカスタムのエージェント生成リントツールで機械的に強制されます。

「テイスト」のエンコード

人間のエンジニアリング「テイスト」―命名規則、構造化ロギング、ファイルサイズ上限など―はカスタムリントに組み込まれます。ルールが違反されると、リントは修正指示をエージェントのコンテキストに直接注入します。これにより、人間の判断が一度だけ捕捉され、コードベース全体に普遍的に適用されます。

自律性とエントロピー問題

開発ループが完全にコード化されると、Codexはエンドツーエンドの自律性の閾値に達しました。単一のプロンプトだけで、エージェントはバグを再現し、失敗動画を記録し、修正を実装し、アプリを駆動して検証し、解決動画を記録し、PR をマージできます。

「AI スロップ」の管理

完全自律は、エージェントがリポジトリ内の他所で見られる最適でないパターンを再現するリスクを伴います。これに対抗するため、OpenAIは「ガーベジコレクション」プロセスを実装しました：

Golden Principles: 共有ユーティリティパッケージを手作りヘルパーより優先するなど、意見的な機械的ルールをリポジトリに定義します。
Recurring Cleanup: 背景で走る Codex タスクがこれらの原則からの逸脱をスキャンし、対象リファクタリング PR を自動で作成します。

コミュニティの視点と批判

OpenAIチームはこれを生産性の飛躍と位置付けましたが、Hacker News コミュニティは複数の重要な反論を提示しました：

"まだ理解できないのは、膨大なコード量が何でかっこいいのかという点です… 私は、生成される行数をできるだけ少なく最適化すべきだと主張します。その次に最適化すべきは人間の可読性です。"

批評者は、100万行のコードベースが効率性の例か「肥大化」かを疑問視し、人間主導のアプローチであればはるかに少ないコードで同等の成果が得られた可能性があると指摘しました。また、具体的に構築された製品名が明かされておらず、リポジトリが非公開である点から透明性の欠如にも懸念が示されました。

しかし、一部の開発者はエージェント中心のワークフローで同様の経験を報告し、エージェントが主要な作者になるほど、型安全性や境界パーシングといった厳格なエンジニアリングベストプラクティスの必要性がより重要になると指摘しています。エージェントが信頼性を大規模に保つ唯一の手段が、これらの制約であるからです。