OpenAI Codexのソフトウェアファクトリー、コーディングをエージェント監督へ置き換え

OpenAIは数カ月のうちに、Codexを任意のコーディング支援ツールから、ほぼすべての社内業務を支える運用レイヤーへと変えた。OpenAI Codexのソフトウェアファクトリーは現在、エージェントをコード、ドキュメント、コミュニケーションシステム、テスト基盤、そして本番テレメトリーへ接続している。

この結論は、OpenAI本社を訪れ、エンジニアおよびエンジニアリングリーダー7人に取材したGergely Oroszによるものだ。彼の内部レポートは、エージェントがソフトウェアの作成、検査、デプロイ、監視をますます担う組織を描いている。

重要な対立軸は、もはやCodexと人間の入力速度の比較ではない。問われているのは、エージェントの処理能力と、その出力を信頼するために必要な人間の注意力、レビュープロセス、組織的統制とのせめぎ合いだ。

OpenAIの事例は、特に有利な条件がそろったケースでもある。従業員はモデルを広範に利用でき、深い社内統合があり、エージェントのハーネス改善に専念するチームも存在する。大半の企業にはこうした条件がないため、見出しの成果が示すほど再現は確実ではない。

OpenAI Codexのソフトウェアファクトリーが標準ワークフローに

最も明確な変化は、Codexが個々の開発者を支援する存在から、OpenAI全体の業務を調整する存在へ移行したことだ。

Oroszによると、この移行は2026年1月ごろに始まった。4カ月以内に、非エンジニアリング部門でのCodex利用率は、ほぼゼロから約90％へ上昇したという。

財務、採用、法務、マーケティング、研究の従業員も、エンジニアとともにこのシステムを導入した。現在では、ほぼすべてのOpenAI従業員が、通常の1週間の間にCodexまたはChatGPT Workを利用しているとされる。

OpenAI自身の職場分析も、この説明のおおまかな方向性を裏付けている。同社によれば、Codexは平均的な従業員が生成する出力トークンの85％超を担っている。

OpenAIによれば、平均的なエンジニアではその比率は99％に達する。全社では、OpenAIツールで週次に生成される出力トークンの99.8％をCodexが占めるとされる。

これらの数値は、完了した事業価値ではなくモデル出力を測ったものだ。それでも、社内のAI業務におけるインターフェースが、会話から委任された実行へと決定的に移行したことを示している。

チャットボットは通常、新たな指示が与えられるたびに待機する。一方、エージェントは目標を受け取り、ツールを使い、結果を調べ、より長い意思決定の連鎖を通じて作業を続ける。

この違いは、Codexがソフトウェア開発以外にも広がった理由を説明する。テーマの調査、プレゼンテーションの作成、スプレッドシートの変換、Slackの監視はいずれも、エージェントがソフトウェアを通じて操作できるデジタル成果物を含む。

OpenAIは2026年2月にMac向けCodexデスクトップアプリを公開し、3月にはWindowsへ提供範囲を拡大した。同じ基盤となるエージェントハーネスを使うChatGPT Workは、7月に続いた。

導入曲線は、インターフェースが非エンジニアにとって使いやすくなる前から始まっていたとされる。Oroszによれば、製品がなおコードを表示し、技術的な知識を前提としていた段階でも、これらの従業員の利用率は40％近くに達していた。

このパターンは、職場におけるAI導入についての一般的な見方に疑問を投げかける。洗練されたインターフェースよりも、相当量の作業を完了し、利用可能な成果物を返すエージェントの能力のほうが重要だった。

より長時間にわたる作業が、この移行を加速させたようだ。Oroszによれば、目標ベースのワークフローが改善した4月から5月にかけて、社内利用率は約60％から90％へ上昇した。

従業員は成果を指定し、エージェントに複数のステップにまたがる作業を続けさせられる。また、従業員がすべてのスレッドを監督する必要がないよう、システムは追加のエージェントへサブタスクを委任することもできる。

OpenAIは外部での利用についても同様の傾向を説明している。5月までに、サンプル対象となった個人ユーザーの70.2％が、人間なら1時間超を要すると推定される作業を少なくとも1回依頼していた。

同社によると、25.6％は8時間を超えると推定される作業を依頼していた。これらの推定はモデルの判断に基づくため、OpenAIは正確な値ではなく方向性を示すものとして扱うよう助言している。

社内向けのカスタマイズは、作業時間の長期化と同じほど重要だった。チームは、汎用エージェントに再利用可能な手順、ツール、領域コンテキストを与える、役割別のスキルとプラグインを作成した。

この組み合わせにより、Codexは単なるアプリケーションではなくインフラになった。従業員は、繰り返し発生するワークフローを毎回新しい会話へ翻訳する必要がなくなった。

導入に伴って依存も生まれた。Oroszによれば、小規模な障害であっても、担当チームに自動監視のアラートが届く前に社内から不満の声が上がることがある。

その結果、OpenAIは生産性エンジンであると同時に、共有された単一障害点も作り出した。より多くの業務が1つのエージェントハーネスを通過するほど、そのハーネスが遅延または停止した際の運用上の影響は大きくなる。

コード生成の高速化がレビューとデリバリーを圧迫

Codexはコードを生み出すコストを下げたが、その妥当性を検証し、リリースするコストをなくしたわけではない。

Oroszによると、OpenAIでは1月以降、統合開発環境の利用が減少している。IDEは、コード編集、ナビゲーション、テスト、デバッグを1つの開発者向けインターフェースに統合する。

代わりにエンジニアは、Codexを通じて実装を委任する機会を増やしている。彼らの仕事は、成果の定義、コンテキストの提供、結果の判断、どの変更をデプロイに値するとみなすかの決定へと移る。

これは希少資源を変える。人が1つの会議に出席している間にエージェントが複数の実装を生成できるようになると、人間の入力時間は生産を制限しなくなる。

ボトルネックとなるのは注意力だ。エンジニアは依然として、価値ある問題を特定し、不十分な解決策を見抜き、曖昧さを解消し、本番環境の結果に責任を負わなければならない。

従来のプルリクエストは、人間が作成する変更のより遅い流れを前提に設計されていた。共有リポジトリへマージする前に、同僚が検査できる限定されたコードのまとまりを提供する。

各エンジニアが多数のエージェントを起動できるようになると、このモデルには負荷がかかる。OpenAIの応用インフラストラクチャエンジニアリング担当バイスプレジデントであるVenkat Venkataramaniは、プルリクエストの量が加速度的に増えていると説明した。

増加した出力は、コードレビューだけに影響するわけではない。すべての変更は、ビルド能力、テスト実行、デプロイ基盤、ストレージ、可観測性、レビュー担当者の注意力を消費する。

OpenAIのチームは、この大量の変更を前提に継続的インテグレーションと継続的デプロイメントを見直している。これらのシステムは、開発者の提出後に変更を自動でビルド、テスト、リリースする。

従来の順序は、コード作成が比較的高コストであることを前提としていた。エージェント型開発は、別の変更を提案することが安価になる一方で、その安全性を証明することは依然として高コストであるため、この関係を逆転させる。

OpenAIは、専門化されたレビューエージェントで対応している。1つの汎用モデルに変更を検査させるのではなく、ワークフローはセキュリティ、インフラ、パフォーマンス、コンプライアンスといった観点をそれぞれ別のエージェントに割り当てられる。

各レビュー担当には、関連するリポジトリの知識と組織ルールが与えられる。高リスクの変更では、より広範なエージェントレビューと人間による必須承認を発動できる。

低リスク領域では、より軽い統制を適用できる。一部のリポジトリでは、人を待たずに、エージェントが狭く分類された変更を承認することを許可できる。

これは、すべてに共通するレビュー手順から、リスクベースのルーティングへの移行だ。同時に、正確な分類、最新のドキュメント、信頼できるアクセス制御にも依存する。

このアプローチは、受け入れられた提案数や開発者アンケートを通じてAI導入を測定している組織に圧力をかける。こうした指標では、追加コードと高速な実験によって生じる下流コストを見落とす。

チームは、顧客成果を改善せずに、より多くのプルリクエストをマージできる。また、保守義務、運用ノイズ、アーキテクチャの不整合を増やす可能性もある。

ネイティブモバイルの配信は、その隔たりを明確に示す。OpenAIはアプリケーションの変更を迅速に生成できるが、意味のあるiOSおよびAndroidの更新は、依然として外部のレビュー手続きを通過する。

アプリストアの承認には数時間から数日かかることがある。そのため、エージェント生成の変更は、エージェントが制御できない配布システムの前で蓄積していく。

同じ不一致は企業内にも見られる。セキュリティ評価、変更管理委員会、コンプライアンスレビュー、顧客検証は、実装が高速化しただけで加速することはめったにない。

競合他社も同じ構造的圧力に直面している。Anthropicが約40万件のClaude Codeセッションを調査した結果では、人間が依然として大半の計画判断を行い、エージェントはより多くの実行判断を担っていた。

同社の利用調査でも、領域の専門知識はより高い成功率と関連していることが分かった。コーディングエージェントは仕事の配分を変えたが、判断を不要にしたわけではない。

したがって、浮上しつつある競争は、個別のコーディングベンチマークにおけるOpenAI CodexとClaude Codeの比較ではない。豊富な機械実行を中心に、組織全体のデリバリーシステムを再設計できるのはどの組織か、という競争である。

OpenAIは、モデル、製品、社内環境を一体で構築しているため、現在大きな優位性を持つ。自社のワークフローで弱点が明らかになれば、エージェント自体を調整できる。

企業の購入者は、既存のリポジトリ、統制、承認チェーンにエージェントを統合しなければならない。その制約要因は、モデルへのアクセスよりも組織の準備態勢である場合が多いだろう。

ファクトリーはコンテキストとフィードバックループで機能する

OpenAIのモデルがファクトリーに似ているのは、コード生成が完全に自律化されているからではなく、エージェントが生産サイクル全体に関与するからだ。

プロセスは、人間が望む成果を定義するところから始まる。その人が、どの問題が重要か、どの制約が適用されるか、許容可能な結果が何を達成すべきかを決める。

次にCodexは、リポジトリ、ドキュメント、Slack、Notion、ログ、監視システム、社内データソースからコンテキストを収集する。この取得段階によって、エージェントが変更を加える前に何を理解できるかが決まる。

OpenAIは、ドキュメントをソースコードに近づけたとされる。これにより、運用上の知識をエージェントとエンジニアの双方がリポジトリ内で見つけやすくなる。

エージェントは変更を実装し、テストを実行し、失敗を修正し、プルリクエストを開く。自動チェックが問題を特定した場合には、リクエストの監視を続けて対応することもできる。

パフォーマンスに敏感な変更は、追加評価に進む場合がある。パフォーマンスハーネスは、選定されたビルドを統制された比較へ送ることで、デプロイ前に性能劣化を検出する。

その後、複数のレビューエージェントが異なる領域のレンズを通して作業を検査する。その価値は、単に専門家ラベルを採用することではなく、焦点を絞った指示とOpenAI固有の知識へのアクセスに由来する。

ワークフローは変更をリスク別に分類する。この分類が、その変更により多くのエージェントレビュー、人間による判断、あるいはより簡単な承認経路が必要かを決定する。

Oroszが記録したプロセスでは、人間が依然として本番デプロイを承認する。承認後は、別のエージェントがロールアウトを追跡し、運用シグナルを監視する。

そのデプロイエージェントは、機能フラグを見つけ、変更を解釈し、成功指標を選び、監視ダッシュボードを作成できる。その後、問題の証拠を探してロールアウトを観察する。

本番環境の挙動は、新たな開発へフィードバックされる。OpenAIが報告するPerf Factoryは、アラートをグループ化し、レイテンシーの劣化を特定し、有力な原因を調査して、修正案を提示する。

もう1つの社内システムであるSevbotは、サービス障害時の対応を支援する。状況のコンテキストを収集し、緩和策を提案し、対応チャンネル内の質問に答える。

Sevbotは現在、提案した緩和策を独自に実行することはない。エンジニアが特定のアクションを承認する必要があり、リスクの高い境界では人間による判断が維持されている。

このサイクル全体は、単一のモデル応答よりも重要だ。エージェントは構造化されたコンテキストを受け取り、制約付きのツールを通じて操作し、自動テストに直面し、その後の段階に証拠を返す。

OpenAIは、この周辺システムをハーネスと呼ぶ。ハーネスは、モデルをツール、データ、権限、実行環境、メモリ、フィードバック機構に接続する。

同社の以前のハーネス実験は、このエンジニアリングが重要である理由を示している。あるチームによれば、Codexは約100万行のコードを含む社内製品のすべての行を生成したという。

OpenAIは、このプロジェクトに要した時間は手作業による実装に必要な時間のおよそ10分の1だったと見積もっている。ただし、これはグリーンフィールドの社内プロジェクトに関する同社の推定であり、独立した業界ベンチマークではない。

より示唆的な教訓は、エージェントには理解しやすい環境が必要だったことだ。リポジトリの知識は明確に整理される必要があり、テストは有用なフィードバックを提供し、アーキテクチャ上の制約は機械で検証可能な形で強制されなければならなかった。

エンジニアは蓄積した混乱も取り除かなければならなかった。リポジトリが古いパターンを有効な例として示していれば、エージェントはそうしたパターンを素早く再現できてしまう。

そのため、高いスループットは、OpenAIがガベージコレクションと呼ぶ取り組みの重要性を高める。チームは、古くなったドキュメント、重複した抽象化、不要なコード、一貫性のない慣習を、それらが複雑化する前に取り除く必要がある。

OpenAIはその後、コーディングエージェントを課題管理ツールに接続するオーケストレーション仕様、Symphonyを開発した。対象となる各タスクには専用のワークスペースと、完了まで作業を続けるエージェントを割り当てられる。

同社によれば、そのSymphonyワークフローにより、一部チームでは最初の3週間でマージされたプルリクエストが500パーセント増加した。

繰り返しになるが、プルリクエストの量は顧客価値ではなくアウトプットの指標だ。ただし、この実験は別の重要なボトルネックを示している。人は多数の対話型エージェントセッションを同時に監督することに苦労する。

OpenAIによれば、ほとんどのエンジニアは、コンテキスト切り替えが負担になる前なら3〜5のセッションを無理なく管理できた。Symphonyは、監督の対象を個々のセッションからタスクの状態と成果物へ移す。

課題管理ツールはコントロールプレーンとなる。エージェントはブロックされていない作業を引き受け、失敗後に再開し、フォローアップタスクを作成し、複数のリポジトリにまたがって実行を維持する。

人間は各セッションに繰り返し指示を出す代わりに、計画、優先順位、完成した結果を確認する。このパターンにより、エンジニアは実装より一段上のレベルへ移る。

それは、組織がエージェント型開発に備えるための条件も変える。質の高いチケット、最新のドキュメント、可観測なシステム、決定論的なテストが、本番インフラになる。

同様のワークフローを検討するチームには、組織的なコンテキストを得る信頼できる情報源が必要だ。検索可能なエンジニアリングナレッジベースは役立つ可能性があるが、検索・取得だけで信頼できる自動化が実現するわけではない。

したがって、工場という比喩は慎重に使うべきだ。OpenAIはソフトウェア開発から人を排除したわけではなく、最も重要な意思決定には依然として人間の統制が残っている。

同社が自動化したのは、意図から証拠に至る経路のより多くの部分である。人間の仕事は、その経路を設計し、出力を評価し、制約を維持する方向へ移っている。

生産性の物語には依然として検証の隔たりがある

OpenAIの社内証拠は印象的だが、ほとんどの企業が同じ成果を安全に再現できることを、まだ証明してはいない。

OpenAIには、通常とは異なる優位性がある。従業員は潤沢なコンピュート、幅広いトークン予算、高度な社内モデル、そしてCodexを開発するチームへの直接的なアクセスを利用できる。

社内システムは、企業のリポジトリ、コミュニケーションツール、運用データ、ドキュメントにも接続されている。一般顧客に提供される製品は、組織固有の統合が少なく、より制限されたものだ。

エージェントはコンテキストに依存するため、この差は重要である。不完全なドキュメントや断片化された権限に接続されたエージェントは、モデル研究所全体に組み込まれたエージェントとは異なる結果を生む。

OpenAIの数値も、利用量とアウトプットを強調している。トークンの比率、プルリクエストの量、コード行数は活動を示すが、信頼性、顧客満足度、総保守コストを直接測るものではない。

時間の推定にも注意が必要だ。長時間タスクに関するOpenAIの主張は、同じ作業を人が実施した記録ではなく、モデルが推定した同等の人間工数に基づいている。

独立した証拠は依然として入り混じっている。無作為化されたMETRの調査では、経験豊富なオープンソース開発者が、慣れ親しんだリポジトリで2025年初頭のAIツールを使った場合、作業時間が19パーセント長くなったことが判明した。

この開発者試験には、246件のタスクを完了した16人の開発者が参加した。参加者はそれぞれのリポジトリに平均で約5年間取り組んでいた。

この実験が対象としたのは、初期のツールと、およそ20分から4時間続くタスクだった。OpenAI内部で説明されている、より長時間にわたる2026年のワークフローを検証したものではない。

それでも、この対比は有用な警告となる。モデルの能力、タスクの形状、リポジトリの設計、ユーザーの熟練度、検証コストによって、見かけ上の生産性の結果は逆転し得る。

OpenAIの環境はエージェント向けに再設計されている。多くの企業は当初、人間向けに最適化されたシステムにエージェントを置き、なぜ出力の信頼性が低いままなのかと疑問に思うだろう。

セキュリティも再現における別の問題を生む。有用なエージェントには、ソースコード、認証情報、コミュニケーションシステム、デプロイメントツール、本番情報へのアクセスが必要になる。

新たな接続が増えるたびに、誤りや操作された指示による影響範囲も広がる。プロンプトインジェクションは、エージェントが読むドキュメント、ウェブサイト、メッセージ、ツール出力の中に悪意のある指示を隠せる。

OpenAIは、サンドボックス化、管理されたネットワークポリシー、集中認証、コマンドルール、詳細なテレメトリーによって、こうしたリスクを抑えているとしている。同社のCodexの安全対策は、制限のないネットワークアクセスを遮断し、未知の宛先には承認を求める。

同社はプロンプト、ツールの活動、承認、ネットワークポリシー上の判断も記録する。セキュリティチームは、これらの記録をエンドポイントのアラートと組み合わせ、エージェントが異常なアクションを実行した理由を再構築できる。

こうした統制は製品の一部であり、任意の管理上の装飾ではない。幅広い権限を持つ高速なエージェントは、小さな誤解を、重大な結果を伴うアクションの急速な連鎖へ変えてしまう可能性がある。

レビューの自動化にも固有の不確実性がある。専門化されたエージェントは、特にすべての変更を一貫して検査できる場合、多忙な人間が見落とす欠陥を発見する可能性がある。

しかし、関連するモデルを使う複数のエージェントは、同じ盲点を共有する場合がある。自動レビュー担当者の一致は、変更が正しいことを保証しない。

チームには自動化バイアスのリスクもある。プロセスが包括的に見えるため、レビュー担当者が機械に承認された変更を十分に注意深く調べなくなる可能性がある。

工場化は共有理解も弱めうる。エンジニアは伝統的に、機能の実装、障害のデバッグ、同僚の判断のレビューを通じてシステムを学ぶ。

エージェントがそうした仕事をより多く担うようになると、組織にはアーキテクチャの知識を維持する別の方法が必要になる。そうでなければ、人間は承認権限を保持しながら、それを行使するために必要なコンテキストを失うかもしれない。

OpenAIが示す答えは、センス、判断力、主体性をより重視することだ。こうした資質は、エンジニアがより良い成果を指定し、もっともらしいが望ましくない実装を退ける助けとなる。

しかし、それらを評価し教えることは難しい。ジュニアエンジニアは歴史的に、エージェントがますます吸収している小規模な実装タスクを通じて判断力を育んできた。

したがって、長期的な人員配置への影響は依然として定まっていない。エージェント型ワークフローは、経験豊富なエンジニア一人が成し遂げられる範囲を広げる一方で、職業への従来型の入口を狭める可能性がある。

OpenAIの事例も、雇用の置き換えに還元すべきではない。文書化されたシステムは、優先順位付け、ドメイン知識、リスク受容、インシデント対応の権限において、依然として人に依存している。

目先の変化はより具体的だ。組織は、ガバナンス、インフラ、学習システムが吸収できる速度を上回って、提案作業を生成できるようになる。

そのため、フィードバックループの質が決定的になる。弱いテストや古くなったドキュメントはエラーを素早く伝播させる一方、強固な統制は失敗した試みを有用な情報へ変える。

中心的な主張は方向性としては信頼できるが、範囲としては不完全だ。OpenAIは、エージェントを支援するよう設計された企業を、エージェントがどれほど深く変えられるかを示した。

しかし、断片化されたシステムと限られたAI専門知識を持つ一般的な企業全体で、同じアーキテクチャが経済的で、安全かつ保守可能であり続けることは、まだ示していない。

このモデルが広がるかを示す3つのシグナル

次の試験は、OpenAIが許容できないリスクを移転することなく、社内の運用モデルを顧客向けの再現可能なシステムへ変えられるかどうかだ。

第一のシグナルは、成果に関するより広範な証拠だ。購入者は、サイクルタイム、インシデント、ロールバック率、顧客への影響、保守作業における測定可能な変化を探すべきである。

コードが増えるだけでは足りない。OpenAI Codexのソフトウェア工場が本社の外でも説得力を持つのは、独立したチームが欠陥や運用負荷を増やすことなく、デリバリーを改善した場合に限られる。

最も強力な証拠は、導入前後の類似チームを比較するものになるだろう。エージェントが生成した変更のレビュー、修正、保守に費やした時間も含めるべきだ。

第二のシグナルは、レビューとデプロイメントの統制がどのように進化するかだ。OpenAIの現在のアーキテクチャは、選ばれた本番環境およびインシデント対応の境界に、依然として人間を置いている。

今後のリリースは、どの判断が自律化され、どの判断が意図的に人間に残されるかを明らかにする。その境界の配置が、システムの実務的なリスクモデルを定義する。

エージェント生成のダッシュボード、専門的なレビュー、リスク分類が、既存の統制では見逃す障害を捉えるかを注視すべきだ。また、一般的なモデルの盲点が相関したレビューの失敗を生まないかも見る必要がある。

第三のシグナルは、Anthropic、Google、Microsoft、そしてエンタープライズソフトウェアベンダーによる競争上の反応だ。いずれにも、人が仕事を委任するインターフェースを支配する動機がある。

Anthropicはすでに、長時間稼働するClaudeエージェントを開発環境とエンタープライズワークフローに接続している。GoogleとMicrosoftは、エージェントを大規模な生産性スイート、クラウドプラットフォーム、アイデンティティシステムと組み合わせられる。

戦略的な賞は、コード生成の先にある。勝つシステムは、組織のコンテキストを読み取り、タスクを振り分け、完成した成果物を返すコントロールレイヤーになり得る。

この立場は大きな乗り換えコストを生む。スキル、権限、レビューポリシー、組織知識、ワークフローの履歴が、選ばれたハーネスの周囲に蓄積する。

同時に、運用上の依存も集中する。モデルの退行、サービス障害、セキュリティ上の欠陥、ポリシー変更は、多くの部門にまたがって同時に業務を中断させる可能性がある。

したがって、エンタープライズでの導入は、生の能力と同じくらい可搬性と監査可能性に依存する。購入者は、エージェントが何にアクセスし、何を判断し、何を変更し、別のエージェントに何を引き渡したのかを理解する必要がある。

スキル、ツール接続、トレース、評価のためのオープン標準は、1社のプロバイダーへの依存を減らすだろう。閉じた社内統合はより速い進展をもたらすかもしれないが、移行を難しくする。

エンジニアの役割は、これら3つのシグナルの背後にある、より長期的な4つ目の問いとして残る。OpenAIの従業員は、コードを直接書く時間を減らし、システムを指揮する時間を増やしている。

これはエンジニアリングの専門性を不要にするものではない。専門性がプロセスに介在する場所を変え、仕様策定、アーキテクチャ、評価、セキュリティ、運用上の判断へと重心を移す。

最も能力の高い組織は、既存のワークフローに単にエージェントを追加するだけではない。どの知識を機械可読にすべきか、どの意思決定について人が説明責任を持ち続けるべきかを判断する。

また、破棄された実験、レビューのコスト、障害からの復旧も測定する。実装が安価でも、その先で高コストな不確実性を生むなら、本当に安価とは言えない。

Oroszの訪問は、まだ形成途上にある重要な転換点を捉えている。OpenAIはもはや、エンジニアがより速くソフトウェアを書くのを支援する目的だけでCodexを使っているわけではない。

同社は、コンテキストを収集し、作業を実行し、変更をレビューし、デプロイを監視し、本番環境からのシグナルを学習するエージェントを中心に、ソフトウェア開発を再編している。

その結果として生まれるのはエージェント型のソフトウェア工場だ。ただし、人間のいない暗闇の工場ではない。人は依然として目標を選び、制約を定め、リスクを受け入れ、システムが予期せぬ振る舞いをしたときに介入する。

読者にとって実践的な問いは、OpenAIのワークフローを直ちに模倣すべきかどうかではない。実装コストが劇的に下がったとき、自社のデリバリーシステムのどの部分がボトルネックになるのか、ということだ。

まずは、測定可能な成果、信頼できるテスト、最新のコンテキスト、そして取り消し可能なアクションを備えた、範囲の限定されたワークフローを1つ特定する。そのうえで、エージェントの目に見える速度だけでなく、レビューと保守にかかる負担全体を測定する。

その実験が成功したなら、自律性を拡大する前にフィードバックシステムを拡充する。OpenAI Codexのソフトウェア工場が示唆するのは、エージェントはより良い環境によってスケールし、その成果物をリリースに値するものと判断するのは人間の判断だ、ということである。