エンジニアリングの実践：Codex が主力開発者となったとき、人間エンジニアは何をしているのか？
執筆者：Ryan Lopopolo | 2026 年 2 月 11 日
本記事を再読し、共有させていただきます。
過去 5 ヶ月間、OpenAI のあるチームはある一風変わった実験を行いました。ソフトウェア製品のプロトタイプ版を、人間によるコーディングを一切行わず、ゼロから完成させたのです。
これはおもちゃのようなプロジェクトではありません。実際の内部デイリーアクティブユーザーと外部アルファテスターを抱え、完全なデリバリー、デプロイ、障害対応、修正のプロセスを通過しました。アプリケーションロジック、テスト、CI 設定、ドキュメント、可観測性、内部ツールのすべてにおいて、コードの 1 行たりとも Codex 以外のものが書いたものはありません。推定によると、これらすべての作業は、人手でコーディングした場合の10 分の 1 の時間で完了しました。
舵取りは人間、作業はエージェント。
これはチームが意図的に課した制約です。エンジニアがコードを書かず、環境の設計、意図の明確化、フィードバックループの構築に注力したとき、ソフトウェアエンジニアリングがどのようになるのかを明らかにするためでした。
空のリポジトリから始める
2025 年 8 月末、最初のコミットが空の Git リポジトリにプッシュされました。
初期アーキテクチャ（リポジトリ構造、CI 設定、フォーマットルール、パッケージマネージャの設定、アプリケーションフレームワーク）はすべて、既存のテンプレート群をガイドとして Codex CLI が GPT-5 と連携して生成しました。エージェントに「このリポジトリでどのように作業するか」を指示する AGENTS.md ファイルでさえ、Codex 自身が作成したものです。
5 ヶ月後、このリポジトリには約100 万行のコードが蓄積されました。アプリケーションロジック、インフラストラクチャ、ツールチェーン、ドキュメント、内部開発者ツールが含まれています。その間、約 1500 のプルリクエストがマージされましたが、その背後で Codex を動かしていたのはわずか 3 人のエンジニアだけでした。平均すると、1 人あたり 1 日 3.5 件の PR を処理した計算になります。さらにチームが 7 名に拡大するにつれ、このスループットは増加傾向にあります。重要なのは、これが数字合わせのためのものではないということです。製品はすでに数百人のベータユーザーによって運用されており、毎日使用するヘビーユーザーも多数含まれています。
開発プロセス全体を通じて、人間が直接コードを貢献することは一度もありませんでした。これがチームの中核的な信条、すなわち手書きコードなしです。
エンジニアの役割の変化
手動コーディングという概念がなくなった今、エンジニアの注意はシステム設計、アーキテクチャの意思決定、そしててこの効果（レバレッジ）を生む行為にすべて向けられるようになりました。
初期の進捗は予想より遅れましたが、それは Codex の能力不足が原因ではありません。環境の説明が十分ではなかったためです。エージェントには高レベルの目標を推進するために必要なツール、抽象化レイヤー、内部構造が欠けており、自然と行き詰まってしまいました。この段階でのエンジニアの主な任務は、「エージェントが仕事をできるようにすること」でした。
実際の実務では、これは深さ優先のアプローチになります。大きな目標を小さなモジュール（設計、コーディング、レビュー、テストなど）に分割し、エージェントに 1 つずつ構築させて、それらのモジュールを使ってより複雑なタスクを解放していきます。ボトルネックに遭遇した際、解決策は「もう一度試す」ことではなく、「何が欠けているのか？どうすればその機能をエージェントにとって明確かつ実行的なものにできるか？」と自問することでした。
人間とシステムの対話はほぼプロンプトに依存しています。エンジニアがタスクを記述し、エージェントを実行し、PR を作成するのを待ちます。PR のプロセスを完了させるためには、Codex に自身の変更点をローカルでレビューさせたり、他のエージェントに専門的なレビューを依頼したり、人間やエージェントからのフィードバックに応答させたりして、すべての関係者が満足するまで循環させます（これは事実上のラルフ・ウィガム・サイクルです）。Codex はコンテキスト収集のために標準的な開発ツール（gh、ローカルスクリプト、埋め込みスキル）を直接呼び出し、人間が CLI に内容を貼り付ける必要はありません。
人間が PR をレビューすることも可能ですが、必須ではありません。時が経つにつれ、レビュー作業のほとんどは「エージェントからエージェントへ」というモードに移行しました。
アプリケーション自体を「可読」にする
コードの生成量が増えるにつれ、人的 QA が新たなボトルネックとなりました。人間の時間と注意には限りがあるため、チームはアプリケーションの UI、ログ、メトリクスなどを Codex が直接読み取れるようにする方法を模索し、エージェントの自律性を拡大しようとしました。
例えば、アプリケーションが git worktree ベースで起動できるようにし、Codex が変更ごとに個別のインスタンスを実行できるようにしました。また、Chrome DevTools プロトコルをエージェントのランタイムに接続し、DOM スナップショット、スクリーンショット、ナビゲーションを処理するスキルをカプセル化しました。これにより、Codex はバグを自ら再現し、修正を検証し、UI の動作について直接推論することが可能になりました。
可観測性ツールも同様の目的で整備されました。ログ、メトリクス、トレースデータは、ローカルの可観測性スタックを通じて Codex に公開され、このスタックは各 worktree に対して一時的なものであり、タスク完了後にはログやメトリクスとともに破棄されます。Codex は LogQL でログを照会し、PromQL でメトリクスを照会できます。このコンテキストがあることで、「サービスが 800ms 以内に起動することを確認する」や「この 4 つの主要なユーザージャーニーにおけるどのスパンも 2 秒を超えないようにする」といったプロンプトが実際に機能するようになります。
Codex が 1 つのタスクに 6 時間以上連続で作業することも珍しくなく、多くの場合、人間が寝ている間に実行されています。
コードリポジトリを「記録システム」とする
コンテキスト管理は、エージェントが大規模かつ複雑なタスクを効果的に実行するための最大の課題の 1 つです。チームが最も早く学んだ教訓はシンプルです。Codex に与えるべきは、1000 ページのマニュアルではなく、地図であるということです。
彼らは「巨大な 1 つの AGENTS.md」というアプローチを試しましたが、案の定失敗しました。これにはいくつかの理由があります。第一に、コンテキストはそもそも希少なリソースであり、巨大な指示ファイルはタスク、コード、関連ドキュメントを圧迫してしまいます。第二に、すべてが「重要」である場合、エージェントは意識的にナビゲートするのではなく、局所的なパターンマッチングを行ってしまうからです。さらに、こうしたファイルは急速に陳腐化し、人間がメンテナンスをやめると静かに問題の源となります。
そのため、AGENTS.md は百科事典ではなく、目次としての役割を持つようになりました。
リポジトリの知識は、構造化された docs/ ディレクトリに格納され、記録システム（System of Record）として機能します。短い AGENTS.md（約 100 行）がコンテキストに注入されますが、これは主に、より深い真の情報源がある場所を指し示す地図として機能します。
AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│ ├── index.md
│ ├── core-beliefs.md
│ └── ...
├── exec-plans/
│ ├── active/
│ ├── completed/
│ └── tech-debt-tracker.md
├── generated/
│ └── db-schema.md
├── product-specs/
│ ├── index.md
│ ├── new-user-onboarding.md
│ └── ...
├── references/
│ ├── design-system-reference-llms.txt
│ ├── nixpacks-llms.txt
│ ├── uv-llms.txt
│ └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md設計ドキュメントにはインデックスと目次があり、検証ステータスと一連の中核理念が含まれています。アーキテクチャドキュメントは、ドメインとパッケージ階層のトップレベルの地図を提供します。クオリティスコアドキュメントは、各製品ドメインとアーキテクチャレイヤーに対してスコアを付け、ギャップを追跡し続けます。
計画はファーストクラスシチズンとして扱われます。小規模な変更には軽量な一時計画が用いられ、複雑な作業は進捗と意思決定のログを添えて実行計画として記録され、すべてリポジトリにコミットされます。アクティブな計画、完了済みの計画、既知の技術的負債はすべてバージョン管理され、一元化された場所に保管されるため、エージェントは外部コンテキストに依存せずに自律的に動作できます。
これにより、段階的な開示が実現しました。エージェントは小さく安定した入り口から始め、必要な情報を次のステップで探すように誘導され、最初から情報に溺れることがありません。
このルールは厳格に適用されています。専用のリンターと CI タスクが、ナレッジベースの最新性、相互リンク、構造の正確性を検証します。定期的に実行される「ドキュメントガーデナー」エージェントが、実際のコードの動作を反映しなくなった古くなったコンテンツをスキャンし、修正用の PR を作成します。
エージェントによる可読性のために最適化する
コードベースが成長するにつれ、Codex の意思決定フレームワークも進化しました。
リポジトリ全体がエージェントによって生成されているため、チームはまず Codex による可読性を最適化しました。エンジニアリングチームが新入社員にとってコードを分かりやすくするのと同様に、人間エンジニアの目標は、エージェントがリポジトリから直接、完全なビジネスドメインを推論できるようにすることです。
エージェントの視点から見ると、実行時コンテキストからアクセスできないものは存在しないも同然です。Google ドキュメント、チャット履歴、人間の頭の中にある知識は、システムからは見えません。リポジトリローカルで、バージョン管理された成果物（コード、Markdown、スキーマ、実行可能な計画）だけが、エージェントの見る世界なのです。
チームは、ますます多くのコンテキストをリポジトリに押し込む必要があると認識しました。アーキテクチャパターンについて合意形成がなされた Slack での議論があったとして、もしエージェントがそれを見つけられなければ、その事象に関する知識は 3 ヶ月遅れで入社してきた新入社員と同等、つまり「何も知らない」のと同じです。
このフレームワークは多くのトレードオフも明確にしました。チームは、リポジトリ内での推論に完全に内在化できる依存関係や抽象化を好むようになりました。エージェントにとって、往々にして「退屈」と呼ばれる技術（組み合わせ可能性、API の安定性、トレーニングデータセットへの出現頻度が高いため）は、モデル化が容易です。場合によっては、パブリックライブラリの不透明な上流の動作を回避するよりも、エージェントに機能のサブセットを再実装させる方が安価です。例えば、チームは一般的な p-limit スタイルのパッケージを導入する代わりに、独自の並行処理対応 map ヘルパー関数を使用しました。これは OpenTelemetry 計装と密接に統合され、テストカバレッジは 100% で、動作が完全に制御可能です。
アーキテクチャの制約でマイクロマネジメントを代替する
ドキュメントだけでは、完全にエージェントによって生成されたコードベースの一貫性を維持することはできません。実装プロセスをマイクロマネジメントするのではなく、不変条件（インバリアント）を強制することで、基盤を揺るがすことなくエージェントに迅速なデリバリーを可能にさせるのです。
例えば、Codex に対して境界部分でデータの形状を解決することは求めますが、どのライブラリを使用するかまでは規定しません（モデルは Zod を好む傾向にありますが、強制はしていません）。
エージェントは、厳格な境界と予測可能な構造を持つ環境で最も効率的に動作します。そのため、チームは厳格なアーキテクチャモデルの周りにアプリケーションを構築しました。各ビジネスドメインは固定されたレイヤー群に分割され、依存関係の方向は厳密に検証され、限られたエッジのみが許可されます。これらの制約は、カスタムリンター（これも Codex 生成）と構造テストによって機械的に強制されます。
ルールは以下の通りです。各ビジネスドメイン内（例：アプリケーション設定）では、コードは固定されたレイヤー群（Types → Config → Repo → Service → Runtime → UI）に対してのみ「前方」に依存できます。横断的関心事（認証、コネクタ、テレメトリ、機能フラグ）は、Providers を通じた単一の明示的なインターフェースからのみ入ることができます。他のいかなる方法も許可されず、自動化によって強制されます。
このようなアーキテクチャは通常、チームが数百人規模に拡大した際に初めて本格的に導入されるものです。しかし、コーディングエージェントにとっては、これは初期段階での前提条件となります。制約があって初めて、速度が低下せず、アーキテクチャが漂流しないのです。
実際には、これを補完するものとして、少数の「テイストの不変条件」も存在します。構造化ログ、命名規則、ファイルサイズの制限、特定のプラットフォームの信頼性要件などが、カスタムリンタによって静的に強制されます。これらのリンタはカスタマイズされているため、エラーメッセージに直接修正指示を注入でき、エージェントが理解しやすくなっています。
人間中心のワークフローでは、これらのルールは迂遠に見えるかもしれません。しかし、エージェントがいれば、これらは倍率装置となります。一度コード化されれば、即座にすべての場所に適用されるからです。
チームは、どこを管理し、どこを管理しないかという線引きも明確にしました。大規模なエンジニアリングプラットフォーム組織を率いるリーダーシップに似ています。中央レベルで境界を強制し、ローカルレベルでは自律性を認めるのです。境界の内側であれば、エージェントはソリューションの表現方法に大きな自由を持てます。
生成されたコードが常に人間のスタイルの好みに合うとは限りませんが、それは問題ではありません。出力が正しく、保守可能で、将来のエージェントの実行にとっても明確に読みやすいものであれば合格です。
人間の嗜好は継続的にシステムにフィードバックされます。レビューのコメント、リファクタリングの PR、ユーザー向けのバグは、ドキュメントの更新として記録されるか、ツールに直接コード化されます。ドキュメントが不十分な場合は、ルールがコードへと変換されます。
スループットがマージの概念を変える
Codex のスループットが向上するにつれ、従来のエンジニアリング規範の多くが適用されなくなりました。
このリポジトリでは、ブロックするマージゲートを最小限に抑えるように運用されています。PR のライフサイクルは短く、テストの偶発的な失敗は、進行を無期限に止めるのではなく、その後の再実行で解決されます。エージェントのスループットが人間の注意力を遥かに凌駕するシステムでは、修正コストは低く、待機コストの方が高いのです。
低スループットの環境でこれを行えば無責任ですが、ここ（高スループット環境）では、これが往々にして正しい選択となります。
「エージェント生成」が意味するもの
コードベース全体が Codex エージェントによって生成されたと言うとき、それは文字通りコードベース全体を指します。
エージェントが生成したものには、製品コードとテスト、CI 設定とリリースツール、内部開発者ツール、ドキュメントと設計履歴、評価フレームワーク、レビューのコメントと返信、リポジトリ自体を管理するスクリプト、本番用ダッシュボードの定義ファイルが含まれます。
人間は常にそこにいますが、作業の抽象度レベルは過去とは全く異なります。チームはタスクの優先順位付け、ユーザーフィードバックの受け入れ基準への変換、結果の検証を優先します。エージェントが行き詰まった場合、それは「欠けているもの（ツール、ガイダンスと制約、ドキュメント）」を特定し、それをリポジトリにフィードバックするよう促すシグナルと見なされます。修正自体は Codex 自身が記述します。
エージェントは標準的な開発ツールを直接使用でき、レビューのフィードバックを取得し、インラインで返信し、更新をプッシュし、頻繁に自身の PR を圧縮してマージすることさえあります。
自律性の向上
テスト、検証、レビュー、フィードバック処理、リカバリといった開発プロセスの多くの部分がシステムに直接コード化されるにつれ、このリポジトリはある重要な閾値を超えました。Codex が新機能をエンドツーエンドで駆動できるようになったのです。
プロンプトが与えられると、エージェントは今や完全なプロセスを完了できます。コードベースの現在の状態を検証し、報告されたバグを再現し、故障をデモする動画を録画し、修正を実装し、アプリケーションを実行して修正を検証し、解決策を示す 2 本目の動画を録画し、PR を作成し、エージェントや人間からのフィードバックに応え、ビルドの故障を検出して修正し、判断が必要な場合にのみ人間に委ね、最後に変更をマージします。
この機能は、このリポジトリ固有の構造とツールに大きく依存しており、これが他のシナリオに無条件に汎化できると仮定すべきではありません。少なくとも現時点では。
エントロピーとガーベジコレクション
完全自律型エージェントは新たな問題ももたらします。Codex はリポジトリ内に既存するパターンを再現します。理想そうでないパターンであってもです。時間が経つにつれ、これは避けられないドリフト（逸脱）につながります。
当初、人間が手動でこの問題に対処していました。チームはかつて毎週金曜日の 20% の時間を「AI の残骸」の掃除に費やしていました。これは明らかに拡張可能ではありません。
その後、チームは「ゴールドプリンシプル（黄金原則）」と呼ぶものを直接リポジトリにコード化し、循環的なクリーンアッププロセスを確立しました。これらの原則は、将来のエージェントの実行に対するコードベースの可読性と一貫性を維持することを目的とした、主観的な意見を含んだ機械的なルールです。例えば、不変条件を一元管理できるように、手作りのヘルパー関数ではなく共有ツールキットを使用することを推奨する、データを「YOLO 的（やけくそ的）」に探索するのではなく境界で検証する、あるいはエージェントが推測に基づいた構造を構築するのを避けるために型付き SDK に依存する、などです。
チームは定期的にバックグラウンドの Codex タスクを実行し、偏差のスキャン、クオリティスコアの更新、標的を絞ったリファクタリング PR の作成を行います。そのほとんどは 1 分以内でレビューされ、自動的にマージされます。
この仕組みはガーベジコレクションに似ています。技術的負債は高金利のローンと同じです。積み上がってから一度に完済しようとするより、小額でも返済し続ける方がマシです。人間の嗜好がシステムに取り込まれれば、それはコードの 1 行 1 行に継続的に作用します。これにより、コードベース内で数週間も蔓延させることなく、毎日不良なパターンを発見して解決できるのです。
学び続けていること
これまでのところ、この戦略は OpenAI 内部でのリリースと導入において良好な結果を残しています。本物のユーザーのために本物の製品を作ることは、チームの投資を実現に結びつけ、長期的な保守可能性へと導く助けとなりました。
不明確な点もあります。完全にエージェントによって生成されたシステムにおいて、アーキテクチャの一貫性は時間とともにどのように進化していくのか？人間の判断力はどの側面で最大の効果を発揮し、それをどのようにコード化してより大きな役割を果たさせることができるのか？モデルの能力が向上し続ける中で、このシステムは将来的にどのように進化していくのか？
1 つだけ確かなことがあります。ソフトウェア構築には依然として規律が必要ですが、その規律はコードそのものよりも、それを支える構造においてより重要になっているということです。コードベースの一貫性を保つためのツール、抽象化、フィードバックループが、かつてなく重要になっています。
現在最も困難な課題は、環境の設計、フィードバックループ、制御システムに集中しています。これは、エージェントが大規模で複雑かつ信頼性の高いソフトウェアを構築・維持するという目標を達成するのを助けるためです。
Codex のようなエージェントがソフトウェアライフサイクルにおいて占める割合が高まるにつれ、これらの問題はさらに重要になるでしょう。