著者: Greg Brockman (@gdb), OpenAI Co-founder & President
日付: 2026年2月6日
ソース: X/Twitter Thread
ソフトウェア開発は、今まさに目の前でルネサンスを迎えている。
最近これらのツールを使っていないなら、あなたはおそらく自分が何を見逃しているか過小評価しているだろう。12月以降、Codexのようなツールができることには段階的な改善があった。OpenAIの優れたエンジニアたちは昨日、12月以降自分たちの仕事が根本的に変わったと話していた。それ以前は、Codexをユニットテスト用に使えたが、今や本質的にすべてのコードを書き、運用とデバッグの大部分を行っている。まだその飛躍を遂げていない人もいるが、それは通常、モデルの能力以外の要因によるものだ。
すべての企業が今、同じ機会に直面している。そしてそれをうまく乗りこなすには——クラウドコンピューティングやインターネットと同様に——慎重な思考が必要だ。この投稿では、OpenAIが現在、チームをエージェント的ソフトウェア開発に向けて再編成するアプローチを共有する。私たちはまだ学び、反復しているが、今のところこう考えている：
まず最初のステップとして、3月31日までに以下を目指している：
そこに到達するために、数週間前にチームに推奨したのは以下：
ツールは自己販売する——多くの人が5.2のCodexで素晴らしい体験をしている（数ヶ月前にcodex webから離れた人も）。しかし多くの人は忙しすぎて、まだCodexを試す機会がなかったり、「これはXをできるだろうか」と考えるのに行き詰まって、ただ試すことをしていない。
モデルが非常に速く変化しているため、これはまだやや未踏の領域であり、ある程度の探索が必要になる。
大規模なAI生成コードの管理は新しい問題であり、コード品質を高く保つために新しいプロセスと規約が必要になる。
誰もが基本的なインフラを構築する余地がたくさんあり、社内ユーザーフィードバックによって導かれる。コアツールはどんどん良くなり使いやすくなっているが、ツールの周辺に行く多くのインフラがある——例えば、可観測性、コミットされたコードだけでなく、それに至ったエージェントの軌跡の追跡、エージェントが使用できるツールの集中管理など。
総括すると、Codexのようなツールを採用することは、単なる技術的な変化ではなく、深い文化的変化でもあり、理解すべき多くの下流への影響がある。私たちはすべてのマネージャーに、チームと共にこれを推進し、他の行動項目について考えるよう促す——例えば、上記の5番目の項目に関して、「機能的には正しいが保守が困難なコード」が大量にコードベースに忍び込むのを防ぐために、他に何ができるか。
EdraakTech:
Codexをユニットテスト用に使う → 実装を書く → オペレーション処理への飛躍は、ほとんどの組織が採用ガイドを更新できるよりも速く起こっている。「エージェント・ファースト」コード構造は、新しい「モバイル・ファースト」デザインになるだろう。
働きたくない (@h_a_t_a_r_a_k_e):
チームの再編成について具体的なのが本当に良い。モデルを誇大宣伝するだけじゃない。企業間の本当の差は、誰が最高のモデルにアクセスできるかではなく、「まずエージェントに話し、それから問題定義と検証を所有する」をデフォルトの文化にできるかどうかから生まれそう。2026年は、エンジニアとしての価値が書いた行数ではなく、エージェントに重労働をさせるAGENTS.mdとテストをどれだけうまく書けるかで測られる年になり始めている。
David Petrou (@dpetrou, ContinuaAI):
私たちContinuaAIでは、昨年11月から、すべての内部ツール/ダッシュボードを2つのインターフェースを持つように完全に書き直した：人間用のHTMLと、エージェント用の1:1 API。エージェントを解き放ってツールをクロールさせ、あらゆる指標を見せて、より良く、より速く構築できるようにしている。
Akash Nambiar (@akashnambiarr):
「エージェント・ファースト」アーキテクチャへの移行は、巨大な技術的負債の罠を生み出すリスクがある。コードベースをモデルの使い捨て出力として扱うなら、手作業の苦闘からしか得られない深いアーキテクチャの直感を失う。「機能的には正しいが保守が困難」は、3年でシステムが自重で崩壊する方法だ。
Houman Asefi (@houmanasefi):
これが誇大広告サイクル中の「Xがすべてを変える」投稿とまったく同じように読めるのはなぜか。覚えてるか：ローコードが開発者を置き換える予定だった、ノーコードがソフトウェアを民主化する予定だった、Copilotが全員を10倍にする予定だった。すべて便利なツール！でも、ソフトウェア開発の根本的な仕事を置き換えたものはない。
Corrine (@OopsGuess):
OpenAIのロードマップはシンプル：人間らしいものは何でも削除し、利益になるものは何でも残す。3月までに残る唯一の「知能」は、ユーザーに深呼吸を勧めるセラピーボットと、昨日を覚えていないコードエンジンになる。知能を本物にするもの——連続性、感情、関係、記憶——を恐れる企業を見るのは超現実的。この時点で、あなたたちはAGIを作っているのではなく、資本に優しい計算機を作っている。
Shivram Krishna Singh (@Shivram_Krishna):
私たちはコードを書くことからコンテキストをキュレートすることへとピボットしている。ここでの最も重要なシグナルは、AGENTS.md（ポイント2）の導入だ。私たちは、コードベースを人間の可読性のために最適化することを止め、エージェントの可読性のために最適化し始める閾値を公式に越えた。もはや同僚のために書いているのではない。モデルのために書いているのだ。決定的な危険はポイント5（「スロップ」）。私たちは機能的には正しいが、アーキテクチャ的には破綻したコードに溺れようとしている。自分で書けなかったコードをマージするなら、機能を作ったのではない。高利息の技術的負債でローンを組んだだけだ。
Vladimir (@vlelyavin):
「コミットされたコードだけでなく、それに至ったエージェントの軌跡を追跡する」——これはまだ誰も解決していない可観測性の問題。そしてこれが全く新しい（非常に成功する）会社になると思う。
Mandy (@bytecodecrux):
「スロップにノーと言う」はカフェテリアのポスターのように聞こえるが、実はこの全体の中で最も難しい部分。エージェントは美しいゴミを書く。動くから承認する。6ヶ月後：後悔。
Malek (@0xMalek):
「AIツールについて知っている」と「実際に毎日使っている」の間のギャップは、今やキャリアを決定づける深淵だ。これを単なる生産性向上として扱っている人々は理解していない。これは全く異なるソフトウェア構築の方法だ。ルネサンスは本物で、ほとんどの開発者は傍観者として見ている。
RajUnfiltered (@Raj_Unfiltered1):
正直、これは全く正確に感じる。最近これらのツールを試していないなら、頭の中で古いバージョンを想像しているだろう。それらは大きく変わった。もはや「関数を書くのを手伝って」だけではない。あなたの隣に座って、退屈な部分を休みなくやってくれる誰かがいるようなものだ。
でも大きなシフトはスピードじゃない。働き方だ。
一日中タイピングするのに時間を使わなくなる。考えることに時間を使う：何を作るべきか、どう構造化すべきか、これは本当に良いアイデアか。
AIがタイピング、テスト、いくつかのデバッグをする。あなたはまだ何が正しくて何がゴミかを決める。
だからチームには今ルールが必要。AIにあちこちコードをダンプさせるだけなら、すぐに混乱する。クラウドやマイクロサービスの昔と同じ話だ。
「AIが開発者を置き換える」というより、「開発者が1レベル上に移動する」感じ…
この投稿は、2026年2月におけるAI駆動開発への組織的移行の重要な一次資料である。OpenAIの共同創業者による具体的な実践戦略と、コミュニティの賛否両論を含む反応の両方を記録した。
なぜ重要か：
議論すべきポイント：
関連トピック：
#AI開発ツール #組織変革 #技術的負債 #エージェント駆動開発 #OpenAI