なぜ OpenAI は開発が異常に速いのか｜DRI と精鋭少人数チームで Codex を 7 週間・100 万行を 5 か月でリリースする組織

01.結論：OpenAI の速度は『DRI ＋ 精鋭少人数チーム ＋ Codex で全自動化』から生まれる

OpenAI は ChatGPT で知られる生成 AI の最大手で、開発者向けのコーディング AI として Codex（コーデックス：自然言語の指示からコードを生成・編集・実行する AI ツール群）を社内外に提供しています。本記事で扱う数字や運用は、ほとんどがこの Codex を中心に回っています。

2026 年 5 月の Sequoia AI Ascent（米国の VC である Sequoia Capital が毎年開催する AI イベント）で、Greg Brockman 氏（OpenAI 共同創業者・President）はこう語りました。「2025 年 12 月に、モデルが典型的なエンジニアリングタスクの約 20% から約 80% をこなせるようになった。ワークフローをこれらの AI を前提に作り直す必要がある」。OpenAI 公式も 「OpenAI エンジニアの 95% が毎週 Codex を使う」と公表しています。

本記事の中核となる観察は、OpenAI の速度を作っているのは 「Codex というツールを持っているから」だけでは説明できないという点です。同じツールを与えられても、組織のかたちが違えば速度は出ません。OpenAI の組織のかたちを、本記事では次の 3 つの軸で分解します。

• DRI と精鋭少人数チームの組み合わせ：すべての主要プロジェクトに「責任を負う 1 名」を必ず置き、その人の判断で動かす運用
• エンジニア・PM・デザイナー・GTM の振る舞い：エンジニアはどこまで Codex に任せ、PM 1 名で 17 人をどう動かし、デザイナー 2 人で CLI（コマンドライン版）・IDE（エディタ拡張版）・Web（ブラウザ版）の 3 種類の体験を全部担当するのか
• Codex を多並列で動かす Harness Engineering 流のリズム：3 人で 5 か月、100 万行、1,500 件の PR（Pull Request：コード変更の提案単位）を一行も手書きせずに作るときに、人間は何をしているのか

02.数字の量感：Codex 7週間17人、Harness 3人で5か月100万行

まず、OpenAI が出している数字の桁を整理します。出典はすべて一次情報・主要技術メディアの取材です。

Codex を 17 人・7 週間でゼロからリリースした

OpenAI のコード生成プロダクト Codex は、2025 年初頭にわずか 17 人・7 週間でゼロからリリースされました。3,000 人規模の組織内で実行された極小チーム・極短納期のプロジェクトです。詳細は Implicator『Inside OpenAI's 7-Week Sprint to Build Codex』と Pragmatic Engineer『How Codex is built』に整理されています。

Pragmatic Engineer の取材では 「チームは小さかったが、全員シニアだった。そうでなければプロジェクトは失敗していた」と紹介されています。「速度は人数ではなくシニア度で出す」という考え方が、OpenAI の少人数チーム運用の核にあります。

Harness Engineering：3 人で 5 か月・約 100 万行・1,500 PR

2026 年 2 月、OpenAI は Harness Engineeringという社内実験の結果を公開しました。これは「AI ネイティブなプロダクト開発」の現時点でのベンチマークと言える内容です。

この事例で本質的に重要なのは、「3 人で 100 万行」という出力量そのものではなく、「3 人で 5 か月運用しても、コード生成がボトルネックにならなかった」という事実です。3 人それぞれが、Codex を多数並列で動かし、仕様を書き、レビューし、検証する側に回ります。Harness Engineering は、「AI ネイティブなエンジニアリングチーム」の OpenAI 自身による最初の公開事例と位置づけられます。

OpenAI 公式：エンジニアの 95% が毎週 Codex を使う

OpenAI は GPT-5.1-Codex-Max の公式リリース記事で、社内の Codex 利用状況を 「OpenAI エンジニアの 95% が毎週 Codex を使い、導入後に約 70% 多くの PR を出荷している」と公表しています。これは、Codex が単なる任意の補助ツールではなく、OpenAI 社内のエンジニアにとって標準的な作業環境になっていることを示す一次情報です。

社員数・採用密度・モデル利用も速度の前提になる

OpenAI の速度も、社員数・採用密度・モデル利用条件を切り分けて読む必要があります。Implicator は、OpenAI が 1 年で 1,000 人超から 3,000 人へ拡大したと報じています。急拡大している一方で、Codex チーム自体は 17 人に絞られており、人数の多さと少人数チームの切り出しが同時に起きています。

報酬面でも、Levels.fyi の自己申告データでは、OpenAI の米国ソフトウェアエンジニア報酬中央値は年 $555K、L5 は年 $1.15M とされています。これは、OpenAI が高年収で経験豊富なエンジニアを採用している可能性が高いことを示す指標です。

モデル利用についても、公開情報だけで見ると「社内の全員が常に同じ最高モデルを使っている」とまでは断定できません。ただし、Pragmatic Engineer は、OpenAI と Anthropic の社員には LLM（Large Language Model：大規模言語モデル）利用上限がないと報じています。さらに OpenAI 公式の GPT-5.3-Codex 発表では、同モデルを「これまでで最も高性能なエージェント型コーディングモデル（agentic coding model）」と位置づけ、Codex チームが初期版を訓練デバッグ、デプロイ管理、評価診断に使ったと説明しています。つまり、OpenAI の速度は、公開プランの制限付き利用と同じ条件ではなく、フロンティア級の Codex モデルを大きく使える環境も含めて理解する必要があります。

03.Codex 立ち上げチーム

Codex の 17 人という編成には、明確な狙いがあります。本章では、その内訳とリズムを読み解きます。

17 人の内訳：4 領域 × シニア中心

Codex のチームは、4 つの領域に明確に切られています。それぞれの領域に必要最小限の人数だけを置き、ロール間の責任境界をはっきりさせる運用です。

• エンジニアリング 8 名：シニア中心。プロダクトコード、モデル統合、CLI（コマンドラインインターフェース、ターミナル版）／IDE（統合開発環境、エディタ拡張版）連携の実装を担当
• リサーチ 4 名：コーディング特化のファインチューニング（既存の AI モデルを、特定タスクに合わせて追加学習する工程）、評価セット作成、モデル更新のたびの体験への影響測定
• デザイン 2 名：CLI／IDE／Web の 3 つの体験を 2 人で見る。1 人あたり 1.5 体験を担当
• GTM 2 名：GTM ＝ Go-to-Market、すなわち「プロダクトを世の中に出すための営業・マーケ・対外発信」を担う領域。リリース戦略、ドキュメント整備、外部発表を担当する
• PM 1 名：プロダクト全体の DRI（責任者）。意思決定を 1 名に集約する

この編成の特徴は、「全員シニア」「全員が複数領域を兼ねる」の 2 点です。デザイナー 2 人で CLI と IDE と Web を分担する、GTM 2 人がドキュメント執筆もすると、エンジニアリングがインフラもプロダクトも書く、といった具合に、領域横断が前提で組まれています。

リサーチが 4 名プロダクトに常駐する理由

17 人中最も特徴的なのが、リサーチャーが 4 名プロダクトチームに常駐していることです。通常の SaaS プロダクト開発では、リサーチャー（モデル研究者）はプロダクトチームではなく中央のリサーチ組織に所属し、プロダクトチームは API を呼び出す側に回ります。OpenAI の Codex はこの構造を取りません。

理由は、AI ネイティブな製品では、モデル特性そのものがプロダクトのコアバリューだからです。コード生成の品質は、UI のデザインやプロンプトのチューニングだけでは限界があります。Codex 専用にモデルをファインチューニングし、評価セットを設計し、モデル更新のたびに体験への影響を測る、という作業がプロダクトチームの中で完結しないと、改善のサイクルが回りません。

Implicator の取材は 「リサーチをプロダクトチームに引き込むことで、モデルの改善と UI の改善を同じテンポで回せる」と整理しています。Codex では、リサーチャー（あるいは AI モデル担当）とプロダクトチームの距離を詰め、モデル改善と体験改善を同じチームのリズムで回しています。

7 週間のリズム：DRI が即決、合議は行わない

Codex を 7 週間でリリースできた最大の理由は、「合議をしない」運用です。Pragmatic Engineer の取材によれば、Codex チームの日々のリズムは次のようなものでした。

• 毎朝、各領域のリードが Slack で前日の進捗と当日の予定を共有する
• 仕様が決まらない論点は PM（DRI）が 当日中に判断する。複数案で迷ったら DRI が選ぶ
• コードレビューは「ブロッキングではない」位置づけ。リード同士が承認したら PR を取り込む
• 週次の MTG は 1〜2 本に絞る。長い議事録は残さない
• 意思決定のログは Slack のチャンネルに残し、後から経緯を辿れる状態にする

この運用の効果は、「決まらない論点が組織内に滞留しない」ことです。OpenAI は DRI がその場で決め、間違えたら作り直す、という運用で意思決定の待ち時間を短くしています。

04.DRI（Directly Responsible Individual）モデルの現場運用

OpenAI の組織のかたちの中核にあるのが、Apple 起源の DRI モデルです。Codex の 17 人だけでなく、ChatGPT、API、Sora、Harness などすべての主要プロジェクトに DRI が必ず置かれています。

OpenAI の完全な社内組織図は公開されていません。一方で、Eng Leadership の取材や OpenAI 公式の Codex 利用事例からは、横断インフラと縦割りプロダクトを分け、各プロダクトに DRI を置く構造が読み取れます。

DRI に渡される 3 つの権限：可視性・決定権・accountability

DRI に指名された人には、次の 3 つの権限と責任が同時に与えられます。

• 全体可視性：そのプロジェクトに関わる Slack チャンネル、ドキュメント、コードリポジトリ、評価結果すべてに自由にアクセスできる
• 決定権：合議や上司承認を経ずに、プロダクト方針・優先順位・リリース時期を決められる
• accountability（説明責任）：結果について最終的に責任を負う。失敗した場合の説明も、成功した場合の評価も、まず DRI が引き受ける

重要なのは、これら 3 点がセットで渡されることです。可視性なしに決定権だけ渡しても判断ができません。決定権なしに accountability だけ負わせると、責任だけ被って動けない人を生みます。OpenAI は 「権限と責任を必ず同じ人に集める」を徹底しています。

DRI モデルでは、決定権と accountability が同じ人物に集約されます。責任者の名前を明確にすることで、判断だけが分散したり、責任だけが残ったりする状態を避けています。

横断インフラチームと縦割りプロダクトチームの分離

OpenAI 内では、横断的なインフラチーム（horizontal infrastructure）と 縦割りのプロダクトチーム（vertical product）が明確に分離されています。

この分割の利点は、次の 2 点です。

• 横断インフラの改善が全プロダクトに同時に効く：学習基盤や推論基盤の最適化が、ChatGPT も Codex も Sora もまとめて速くする
• プロダクトチームは内部で完結する DRI 体制で動ける：横断との調整は最小限で、自チーム内の判断でリリースできる

OpenAI は横断インフラと縦割りプロダクトの責任境界を明示的に切ることで、同じような実装が複数のプロダクトチームに分散する状態を防いでいます。

経営層が Slack で直接コード議論に入る

さらに特徴的なのが、経営層が Slack のプロダクトチャンネルに直接入り、設計議論に意見を書く運用です。Eng Leadership の取材は 「executives post in Slack, join internal discussions」と記述しています。

これが成立する前提は、次の 3 点です。

• DRI が明示されているため、誰の判断を仰げばいいかが常に明確であること
• 経営層が「決裁」ではなく「議論への参加」をしていること（決裁権は DRI に残る）
• 議論のログがチャネルに残るので、後から経緯を辿れること

ここで重要なのは、経営層が決裁者として入っているのではなく、コード議論の参加者として入っている点です。意見は出すが決定権は DRI に残す、という線が引かれています。

05.エンジニアにどれだけの権限を渡しているか

OpenAI の速度の前提にあるのが、エンジニア 1 人に対する大きな権限委譲です。同社は、コードを書く工程だけでなく、「コードを動かすまでの承認プロセス」も徹底的に短くしています。

CI・eval・サンドボックスで判断を支える

OpenAI の公開情報から確認できるのは、無条件の直接反映ではなく、PR 作成、テスト追加、リファクタリング、障害対応の調査を Codex が広く支えているという運用です。OpenAI 公式の 「How OpenAI uses Codex」では、Codex が Security、Product Engineering、Frontend、API、Infrastructure、Performance Engineering など複数の技術チームで日常的に使われていると説明されています。

重要なのは、「コードレビューだけを承認ゲートにしない」方向に振っていることです。LLM プロダクトの場合、行単位のコードレビューだけでは「モデルの振る舞いが期待通りか」を検証できません。代わりに CI ガードレール（テスト、型、lint（コードの書き方を機械的にチェックするツール）、eval ハーネス、セキュリティスキャンを、CI が自動で走らせて緑か赤を判定する仕組み）に投資し、人間レビューは設計の妥当性とセキュリティ／DB 関連、認証回りなどのクリティカル領域へ集中させます。

Codex のサンドボックスで失敗を捨てられる

エンジニアに大きな権限を渡せるのは、Codex の実行が ephemeral（エフェメラル：使い捨ての）コンテナで隔離されているからです。コンテナとは、アプリを実行するための独立した小さな実行環境のことで、ホスト OS から切り離されているため、中で何が起きてもホスト側に影響しません。Codex はこのサンドボックス（隔離環境）で動作し、破壊的操作の影響範囲がコンテナ内に閉じています。エンジニアは「壊しても捨てれば終わり」という前提でエージェントを走らせられます。

この設計の効果は、「権限を渡しても事故が起きにくい」ことです。本番環境への影響を伴う操作は別途明示的に承認が必要ですが、それ以外の試行錯誤は自由度が極めて高い。失敗のコストが低いから、エンジニアは大胆に手を動かせます。

横断インフラへの依頼は Slack 1 本で完結する

OpenAI のもうひとつの特徴が、横断インフラチームへの依頼の軽さです。Eng Leadership の取材によれば、エンジニアが必要なインフラ機能を Slack のチャンネルに書き込めば、横断インフラチームのメンバーが反応し、その場で対応の可否と時期が決まります。

この軽さが成立する前提は、次の 3 点です。

• 横断インフラチームに「リクエストを受ける窓口」の DRI がいる
• プロダクト側のエンジニアが、横断インフラチームのチャンネルに自由に書き込める
• 応答が遅い場合、プロダクト側の DRI が経営層に Slack で直接相談できる

結果として、横断インフラへの依頼から実装までのリードタイムが 「数日〜1 週間」のオーダーに収まっています。

PR 70% 増の意味：人が判断する量が増えている

OpenAI 社内で Codex 導入後、エンジニアが 約 70% 多くの PR を出荷していると OpenAI 公式が公表しています。これは「コード生成速度が 70% 速くなった」ではなく、「人間が承認・統合・検証できる PR 数が 70% 増えた」と読むほうが正確です。

この数字の本質は、エンジニアが 「書く側」から「判断する側」へシフトしていることを意味します。Codex が生成した複数案を比較し、設計の妥当性を見抜き、テスト結果と eval スコアを評価し、マージするかどうかを決める。1 日あたりの判断件数が増え、判断品質を保つための仕組み（CI、eval、サンドボックス）への投資が同時に進んでいる、という状態です。

06.Harness Engineering：3 人がどう 100 万行を作ったか

本章では、OpenAI が 2026 年 2 月に公表した Harness Engineeringの事例を、もう一段深く分解します。3 人で 5 か月、100 万行、1,500 PR、手書きゼロ。この数字の中身に何があるのかを見ていきます。

Spec → Plan → Review → Execute の 4 フェーズ

Harness Engineering の名前の由来は、「evaluation harness（評価ハーネス：モデルの出力を自動評価する仕組み）」です。チーム名そのものが、「コード生成は Codex が行い、人間は評価ハーネスを書く側に回る」という設計思想を表しています。

具体的な進め方として、Spec-Driven Development（SDD）の 4 フェーズが基本になります。Drew Breunig『The Rise of Spec Driven Development』で観察記事として広く読まれている流れです。

SDD は 「もっと PRD を書け」という話ではありません。PRD は不要ですが、Spec はエージェントの境界条件として明文化します。Spec が曖昧だとエージェント間で衝突が起き、レビューコストが爆発します。短くて明確な Spec を、必要なときに必要なだけ書く運用が、Harness Engineering を成立させる前提条件です。

1 人 1 日 3.5 PR のリズム

Harness Engineering の数字を「1 人 1 日あたり」に直すと、3.5 PR / 日 / 人になります。普通の開発者は、忙しい日でも 1 日に 2〜3 PR を出すのが上限です（レビュー・テスト・CI を含めると）。Harness Engineering の 3.5 PR / 日 / 人は、人間が書く側ではなく、Codex が書いたものを人間がレビュー・承認・統合する側に完全に回った結果の数字です。

3 人それぞれの日々のリズムは、OpenAI の公開記事から、次のような流れが推測できます。

• 朝：前日に Codex が夜間に走らせた PR を確認し、緑のものをマージ
• 午前：その日の Spec を書き、Codex に Plan を提案させる
• 午後：複数の Codex セッションが並列で実装するのを監督。失敗したセッションは破棄して再生成
• 夕方：人間レビューが必要な PR（設計の妥当性、セキュリティ関連）を集中的に見る
• 夜：明日に向けた Spec を仕込み、夜間バッチで Codex を走らせる

評価ハーネスが CI に組み込まれている

3.5 PR / 日 / 人を成立させるもうひとつの前提が、評価ハーネスが CI に組み込まれていることです。各 PR がマージ可能と判定されるためには、次のチェックが順次パスする必要があります。

• ユニットテストと統合テストが緑であること
• 型・lint・format が機械的にパスすること
• 評価ハーネス（あらかじめ用意した入力に対するモデル出力の自動評価）に回帰がないこと
• セキュリティスキャンとライセンス確認がパスすること
• サンドボックス内で動作確認が取れること

これら 5 層を 人間が手動で確認するのではなく、CI が機械的に判定することが大切です。人間は「CI が緑であること」を前提に、設計の妥当性や、検証では捕捉できない振る舞いだけをレビューします。

「人間レビューが必要な範囲」の選別が先にできている

Harness Engineering が成立する最大の前提は、「どのコードに人間レビューが必要で、どのコードに不要か」を事前に決めてあることです。Codex 全盛時代の verification の本質は、「全コードを人間が見ない代わりに、見るべき範囲を厳密に絞り込む」運用設計です。

07.PM・デザイナー・GTM の実際の振る舞い

本章では、Codex の 17 人チームのうち、PM 1 名、デザイナー 2 名、GTM 2 名がどう動いていたかを分解します。

PM 1 人で 17 人を動かす：意思決定の集約

Codex のチームには PM が 1 人しかいません。これは「人手不足だから」ではなく、明確な意図のある選択です。意思決定の責任を 1 名に集約することで、合議や PRD 調整の往復をなくし、判断速度を最大化するという DRI モデルの典型例です。

この PM 1 人がやっていたことは、次のようなものです。

• 仕様の最終決定：エンジニア・リサーチ・デザインから上がる論点を当日中に裁く
• 公開時期の判断：何を含めて何を切るか、どこで線を引くか
• 対外発信の方向性：GTM と組んで、何をどう発表するか
• 経営層との接続：経営層との直接やりとりを担う窓口
• ロードマップではなく、「次の 1 週間で何を出すか」の指示

重要なのは、PM 1 人で 17 人を「動かす」ことが可能なのは、エンジニア・デザイナー・リサーチが自律的に動ける前提があるからです。PM が指示しなくても各領域が自力で進める。PM の仕事は 「判断の集約」であって、「タスク管理」ではありません。

デザイナー 2 人で CLI／IDE／Web を担当する

Codex のデザイナーは 2 人だけで、CLI・IDE・Web の 3 つの体験を分担します。1 人あたり 1.5 体験を担当する計算です。

• Figma で UI を作るだけでなく、Codex に渡して自分で実装の試作までやる
• 細かい挙動の調整（ホバー、A11y、エラー表示）は、デザイナー自身が PR を出す
• 3 つの体験の整合性は、デザイナー 2 人の間で Slack で完結する
• ユーザーリサーチも自分で回し、結果を Spec の改訂に反映する

2 人で 3 体験は数字上は無理筋に見えますが、Codex が実装フェーズの大部分を引き受けるため、デザイナーが手を動かすのは仕様策定と最終確認に集中できます。

GTM が早い段階からチームに入る

Codex の 17 人のうち 2 名が GTM（Go-to-Market）です。プロダクトが完成してから営業・マーケに渡すのではなく、立ち上げ初日から GTM がプロダクトチームに常駐します。

• 公開前のドキュメント（公式ブログ記事、API リファレンス、デモ動画）を、エンジニアと並走で書く
• 初期ユーザー（β）の選定と関係構築を、リリース 1〜2 か月前から始める
• 対外発信（X・ブログ・カンファレンス）の方向性を、PM・経営層と詰める
• 公開後のサポート・フィードバック収集の仕組みを、事前に設計する

GTM がプロダクトに早期から入ることで、「作ってから売り方を考える」のコストが消えます。リリースの瞬間にドキュメント・公式ブログ・X・初期ユーザーのフィードバックがすべて揃っており、リリース直後の伸びが指数関数的に速い、というのが Codex を含む OpenAI 製品のリリースに共通する特徴です。

08.Brockman『December 2025 inflection』と『retool your workflow』

In December 2025, the models went from doing roughly 20% to roughly 80% of typical engineering tasks. You absolutely need to retool your workflow around these AIs. We still want a human to be accountable for all code that gets merged.和訳：2025 年 12 月、モデルが典型的なエンジニアリングタスクの約 20% から約 80% をこなせるように変わった。これらの AI を前提にワークフローを作り直す必要が絶対にある。それでも、マージされる全コードに人間の accountability（最終責任）が必要だ、という方針は変わらない。

Greg Brockman 氏（OpenAI President、Sequoia AI Ascent 2026）

Brockman 氏の発言で重要な点は、次の 3 つです。

• 2025 年 12 月に AI の能力が屈曲点を超えた（典型タスクの 20% → 80%）
• ワークフロー（組織のやり方）を AI 前提に作り直す必要がある
• ただし、マージされる全コードに人間の accountability（最終的に責任を負う 1 人）が必要

ここで言う「retool your workflow（ワークフローを作り直せ）」は、IDE を置き換える、補完を Copilot から Codex に変える、といった表層的な話ではありません。仕様策定・実装・レビュー・検証のサイクル全体を、エージェントが多並列で走る前提に組み直せという意味です。OpenAI が Harness Engineering を社内実験として実行し、結果を公開したのは、まさにこの「ワークフローの作り直し」の実例を見せるためでした。

Brockman 氏が同時に「人間の accountability が必要」と釘を刺している点も大切です。これは前章までで扱った「人間レビューが必要な範囲の選別」「DRI による責任主体の明確化」と直結しています。権限を委譲した上で、必ず誰かが最後に責任を負う。これが OpenAI の組織のかたちの一貫した思想です。

09.verification（検証）が新しいボトルネックになった

Codex が十分に速くなった結果、OpenAI 内でも組織のスループットを決めるのは 「生成されたコードをどれだけ速く・正しく検証できるか」に移っています。

『マージされる全コードに人間の accountability が必要』

Brockman 氏の Sequoia AI Ascent 発言で見落とされがちな部分が、「We still want a human to be accountable for all code that gets merged」です。モデルが典型的なエンジニアリングタスクの 80% をこなせるようになっても、マージされる全コードに人間の最終責任が要るという制約を、彼は明示的に置いています。

ここで言う accountability は、「コードを 1 行ずつレビューする」とは意味が違います。Codex が書いたコードのうち、退屈な部分（データ変換、CRUD、ボイラープレート）まで人間が読む必要はありません。代わりに、設計の妥当性、セキュリティ／DB／決済などのクリティカルな箇所、テスト・型・lint が機械的に検証してくれない振る舞い、に人間レビューを集中させます。「書く」から「検証する範囲を選ぶ」へ、エンジニアの仕事の重心が移っています。

Agoda 調査が示す『速くなったのに速くならない』現実

この構造を具体的な数字で示したのが、旅行 OTA 大手 Agoda が 2025 年に公開した 『AI Developer Report 2025』です。東南アジア・インドの開発者を対象とした大規模調査として、AI ツール導入後に開発組織で何が起きているかを定量化しています。コードレビュープロセス変更の 57% は、同じ Agoda の ガバナンス続報で公表された数字です。

この数字が示しているのは、個人の生産性は確かに上がるが、レビュー・検証・統合の負荷がそのまま組織側に積み上がるという構造です。同じ観察は、AWS Enterprise Strategy ブログ『Your AI Coding Assistants Will Overwhelm Your Delivery Pipeline』でも整理されており、「コード生成は爆速化したが、デリバリーパイプライン側があふれている」という同じ構図が報告されています。本当のボトルネックは、次の 3 点に整理できます。

• テスト・CI・lint の充実度
• 人間のレビューキャパシティ
• eval（評価）ハーネスの整備

verification への投資こそが、コード生成速度を 「実際のリリース速度」に変える要になります。プロンプト設計の上流側については プロンプト・ベストプラクティスでも整理しています。

10.まとめ

本記事を通じて見えてきた OpenAI の速度は、「Codex というツール」だけでは説明できません。背後には、DRI による責任主体の明確化、シニア中心の少人数チーム、エンジニアへの大きな権限委譲とサンドボックス、横断インフラと縦割りプロダクトの分離、経営層が直接コード議論に入る低プロセス文化、PM・デザイナー・GTM が早期から並走する編成、という前提条件が積み重なっています。

Brockman 氏の 「retool your workflow（ワークフローの作り直し）」は、IDE の置き換えだけではなく、責任主体、チーム編成、検証体制、リリース判断までを含む開発の前提変更を指しています。OpenAI 公式の 「エンジニアの 95% が毎週 Codex を使う」という数字も、単なるツール利用率ではなく、組織全体が Codex を前提に作業を組み替えていることを示す指標として読む必要があります。