5カ月でコード100万行を生成してソフトウェア構築 AIコーディングを生かすための工夫とは？ OpenAI解説：開発期間を10分の1に短縮させた「ハーネスエンジニアリング」事例

OpenAIのソフトウェア開発チームは「ハーネスエンジニアリング」を実践し、同社のAIコーディングエージェント「Codex」を活用して、手作業のコーディングなしで社内向けソフトウェアを開発したという。公式ブログで取り組みの成果と課題を共有した。

[＠IT]

　OpenAIは2026年2月11日（米国時間）、同社のソフトウェア開発チームが「ハーネスエンジニアリング」を実践し、AI（人工知能）コーディングエージェント「Codex」を活用して社内向けソフトウェアを開発したと発表した。

　この実験的なプロジェクトにおいて、手作業によるコード記述は一切実施されなかったという。OpenAIは公式ブログで、実験プロジェクトの全容を共有した。

OpenAI社内の「ハーネスエンジニアリング」の具体例

　CodexはWebアプリ、CLI（コマンドラインインタフェース）、IDE（統合開発環境）拡張機能、最近リリースされたWindows/macOSアプリで利用できる。OpenAIは、これら全てのCodex製品体験の基盤となるエージェントループおよびロジックを、「Codexハーネス」と呼んでいる。Codexハーネスは以下の役割を担う。

• ユーザー、AIモデル、ツール間のやりとりをオーケストレーション（調整、管理）するエージェントループ
• スレッド（ユーザーとエージェントの会話）のライフサイクル管理とイベント履歴の永続化
• 構成と認証
• ツールの実行とエージェントの拡張

　OpenAIのソフトウェア開発チームは実験プロジェクトにおいて、人間が自らコードを書くのではなく、環境設計、意図の明示、フィードバックループの構築に注力した。Codexハーネスを効果的に機能させ、優れた信頼性とパフォーマンスを発揮させるためだ。

5カ月で100万行のコードを生成

　実験プロジェクトでは、アプリケーションロジック、テスト、CI（継続的インテグレーション）設定、ドキュメント、オブザーバビリティ（可観測性）機能、内部ツールなど、コードの全行がCodexによって生成された。「手作業でコードを書く場合の約10分の1の時間で社内向けのソフトウェアを構築できた」と、OpenAIは推計している。

　この全自動化の取り組みは、プロジェクトを開発した2025年8月下旬から徹底されていた。空のgitリポジトリの初期スキャフォールド（足場）となるディレクトリ構造、CI設定、フォーマットルール、パッケージマネジャーの設定、アプリケーションフレームワークを全てCodex CLI（GPT-5ベース）に生成させていたという。

　5カ月後、リポジトリにはアプリケーションロジック、インフラ、ツール、ドキュメント、開発者ユーティリティーにわたる約100万行のコードが保存されるようになった。

　その間に約1500件のプルリクエスト（PR）が作成され、マージされた。Codexを操作する同チームのエンジニアは、当初の3人から現在は7人に増えており、このPR処理では、エンジニア1人当たり平均3.5件／日という高いスループットが実現された。

　開発されたソフトウェア（β段階）は、社内ユーザーだけでなく、外部のαテスターにも日常的に利用されている。

エンジニアの役割の再定義

　この実験プロジェクトでは、人間のエンジニアの役割が従来のソフトウェア開発プロジェクトとは根本的に異なっていた。コードを書くことではなく、エージェントが有用な作業を実行できるように調整することがチームの主な仕事になった。

　当初は予想より進捗（しんちょく）が遅いという課題もあったものの、それはCodexに、高レベルの目標に向けて進むためのツール、抽象化、内部構造が欠けていたためだった。そこでチームは、大きな目標を小さな構成要素（設計、コード、レビュー、テストなど）に分解し、Codexにこれらのブロックを構築させ、それらを用いてより複雑なタスクを実行させた。

　何かが失敗した場合、人間のエンジニアは常に、Codexがそのタスクに対応できるようにするために、「どのような能力が欠けているのか」「このタスクをCodexが理解して実行できるようにするには、われわれはどうすればよいのか」と質問していたという。

　エンジニアはほぼ完全にプロンプトを通じてCodexハーネスへ指示を出すようになった。まずはタスクを説明してCodexを実行し、PRを作成させる。提出されたPRをマージさせるため、Codexに以下の指示を与えていた。

• Codex自身に変更点をレビューさせるため、ローカルとクラウドの両方で追加のエージェントレビューをリクエストする
• 人間やエージェントからのフィードバックに応答し、全てのエージェントレビュアーが満足するまで、ループを反復する

　Codexは、チームの標準的な開発ツール（gh、ローカルスクリプト、リポジトリに組み込んだエージェントスキルなど）を直接使用し、コンテキストを収集する。

　チームは時間の経過とともに、ほとんどのレビュー作業をAIエージェント同士の相互レビューへと移行させた。

アプリケーションの可読性向上

　だが、コードの生成量が増加するにつれて、人間の品質保証（QA）能力がボトルネックとなった。そこでチームは、CodexがアプリケーションのUI（ユーザーインタフェース）やログ、メトリクス（指標）自体を直接読み取れるようにした。

　例えば、アプリケーションをgitワークツリーごとに起動できるようにし、Codexが変更を加えるたびにインスタンスを起動、操作できるようにした。「Chrome DevTools MCP」（MCP：Model Context Protocol）をエージェントランタイムに組み込み、DOM（Document Object Model）、スクリーンショット、ナビゲーション操作のスキルを実装した。これにより、Codexがバグの再現、修正の検証、UI動作について直接リーズニングできるようになった。

Chrome DevTools MCPを用いてアプリケーションのUI動作を検証するCodex（提供：OpenAI）

　オブザーバビリティツールについても同様の手法を採用し、ワークツリーごとに一時的に構築されるローカルオブザーバビリティスタックを介して、ログ、メトリクス、トレースがCodexに公開されるようにした。

　Codexは、ログやメトリクスを含む完全に隔離されたアプリケーション環境で動作し、タスク完了後はこれらのデータは破棄される。「LogQL」によるログのクエリや、「PromQL」によるメトリクスのクエリも可能だ。こうした環境により、「サービス起動を800ミリ秒未満で完了させる」や「4つの重要なユーザージャーニーのスパンが2秒を超えないようにする」といった具体的な指示も、Codexが対応できるようになった。

Codexへのオブザーバビリティスタックの提供（提供：OpenAI）

コンテキストの管理方法

　エージェントに大規模なタスクを実行させる上で最大の課題の一つが、コンテキスト管理だ。まず、1つの巨大なAGENTS.mdファイルを与えるアプローチを試したが、失敗に終わった。過度な指示は最適化の方向を誤らせ、内容がすぐに陳腐化し、検証が困難になったという。

　そこでチームは、AGENTS.mdを「目次」として位置付け直した。リポジトリのナレッジベースについては、構造化されたdocsディレクトリに格納し、約100行のAGENTS.mdをエントリポイントとして、より深い情報源へのリンクを提供するようにした。そして、docsディレクトリ内のナレッジベースを正しい情報源として扱うようにした。

リポジトリ内のナレッジストアのレイアウト（提供：OpenAI）

　また専用リンターとCIジョブがナレッジベースの鮮度、相互参照、構造を自動検証している。「ドキュメントガーデニング」エージェントが定期的に、陳腐化したドキュメントを検出してPRを作成する仕組みも構築した。

エージェントにとっての可読性も重要

　エージェントにとっては、実行時にコンテキスト内でアクセスできない情報は存在しないに等しい。Googleドキュメントやチャットスレッド、人間の頭の中にある知識は、システムからアクセスできない。リポジトリ内に存在するバージョン管理された成果物（コード、マークダウン、スキーマ、実行計画など）だけが、エージェントの認識対象だ。

　チームは、時間の経過とともにリポジトリに、より多くのコンテキストを投入する必要があることを学んだ。その際は、適切な情報を整理して提供し、Codexがリーズニングできるようにすることが効果的とした。

　またAIを制御する上では「あえて車輪を再発明する」方が効率的なケースもあるという。内部動作が不透明なパブリックの外部ライブラリを導入し、その挙動の回避策を練るよりも、必要な機能のみをエージェントに再実装させた方が、かえって工数がかからないからだ。

　チームはその一例として汎用（はんよう）的な「p-limit」形式のパッケージを導入する代わりに、独自の「map-with-concurrency」ヘルパーを実装させた事例を紹介している。

アーキテクチャとルールの徹底

　エージェントによって全て生成されたコードベースの一貫性は、ドキュメントだけでは保てない。チームは、実装の細部を管理するのではなく、不変条件を強制することで、エージェントが基盤を損なうことなく、迅速にリリースできるようにした。

　エージェントは、厳格な境界と予測可能な構造を持つ環境で最も効果を発揮する。そこでチームは堅牢（けんろう）なアーキテクチャモデルを基にアプリケーションを構築した。各ビジネスドメインは、固定されたレイヤーのセットに分割され、依存方向はカスタムリンター（Codexが生成する）と構造テストによって機械的に強制される。

明示的な横断的境界を持つ階層型ドメインアーキテクチャ：横断的な事項（認証、コネクター、テレメトリー、機能フラグなど）は、単一の明示的なインタフェース（プロバイダー）経由でのみ入力される（提供：OpenAI）

　こうしたアーキテクチャの確立は通常、何百人ものエンジニアがそろうまで後回しにされる。だが、コーディングエージェントを使用する場合は、プロジェクト初期の絶対条件だと、OpenAIは強調する。

　「制約こそが、アーキテクチャの劣化や設計との乖離（かいり）を招くことなく、開発速度を向上させられるためだ」（OpenAI）

Codexがエンドツーエンドで新機能を開発できる段階に

　開発ループのより多くの要素（テスト、検証、レビュー、フィードバック処理、リカバリー）がCodexハーネスに直接組み込まれたことで、Codexが単一のプロンプトから以下を実行し、新機能をエンドツーエンドで開発できる段階に達した。

• コードベースの現状を検証
• 報告されたバグを再現
• 失敗を実証する動画を録画
• 修正を実装
• アプリケーションを実行して修正を検証
• 解決を実証する動画を録画
• PRを作成する
• エージェントと人間のフィードバックに対応
• ビルドの失敗を検出、修正
• 判断が必要な場合のみ人間にエスカレーション
• 変更をマージ

「AIスロップ」の課題とどう向き合うか

　だが、エージェントの完全な自律性は新たな問題も生む。Codexはリポジトリに存在するパターンを複製するが、それが最適でない場合、時間とともにコードベース全体が正しい設計から乖離する事態につながる。

　チームは当初、毎週金曜日の20％の時間を「AIスロップ」（粗悪なAI生成コード）の手動クリーンアップに費やしていたが、これではコードベースの規模拡大に対応できなかった。

　そこで、コードベースの可読性と一貫性を保つ機械的なルールである「黄金原則」をリポジトリにルールとして組み込み、定期的なクリーンアッププロセスを構築した。

　原則の具体例として、不変条件を一元管理するために「場当たり的に記述されたヘルパー関数」よりも「リポジトリ内の共有ユーティリティー」を優先することや、当てずっぽうなデータアクセスを防ぐために、境界を確実に検証するか型付きSDK（ソフトウェア開発キット）に依存することなどが挙げられている。

　バックグラウンドで動作するCodexが設計との逸脱を検出し、コードベースの品質評価（グレード）を更新し、対象を絞ったリファクタリングPRを作成する。これらは大抵、1分以内でレビューされ、自動マージされる。

　チームは「技術的負債は高金利のローンのようなものであり、放置して後から痛みを伴いながらまとめて対処するより、継続的に少額ずつ返済する方がよい」と指摘している。ガベージコレクションのような仕組みにより、リポジトリ内に悪いパターンがあった場合でも、コードベースに長期的に拡散するのを防いでいるとした。

今後の展望と課題

　実験プロジェクトで培われたハーネスエンジニアリングの取り組みは、今のところ良好に機能しているという。ただし、チームは以下の点について、まだ学んでいる段階だと率直に認めている。

• エージェントによって全て生成されたシステムにおいて、アーキテクチャの一貫性が年単位でどのように進化するのか
• 人間の判断が最も効果を発揮するのはどの領域か、その判断をどのように組み込んで効果を得るか
• モデルの能力が向上し続ける中、このシステムがどのように変化するか

　OpenAIは「ソフトウェア構築には引き続き規律が必要だが、その規律はコードそのものよりも、開発基盤となる枠組み（スキャフォールド）の設計に現れるようになった」と述べている。ツール活用、抽象化、フィードバックループが、コードベースの一貫性を保つ上で、ますます重要になっている。