編集｜雲昭
2月に入ってから、「コンテキストエンジニアリング」や「Vibe Coding」の熱狂は、ある新たな用語に道を譲りました。それが「harness engineering（ハーネスエンジニアリング）」です。
この名称を広めたのは、OpenAI Frontierチームの中核エンジニア、Ryan Lopopole（ライアン・ロポポロ）氏です。
彼が最近発表した長文記事が話題となり、まさに「ハーネスエンジニアリング」の定義作と呼ぶにふさわしい内容です。
この記事の中で、Ryan氏は新設されたOpenAI FrontierチームがOpenAI最大のCodexユーザーになったことを明らかにしました。チームは当初3人だけでスタートし、5ヶ月間の極限の実験を経て、最終的に100万行のコードを持つコードベースを稼働させることができました。そのうち人間が書いたコードは0行です。
同時に、「ダークファクトリー」のファンたちを魅了しているのは、このコードベース全体がマージされる前に、全く人間によるコードレビューを受けていないという点です。
では、OpenAI Frontierチームはどのようにして「ハーネスエンジニアリング」を通じて0の手書きコードを実現したのでしょうか？
昨日、ついにRyan氏がOpenAIのこの謎めいたプロジェクトについて深い内幕を明かしました！
昨日公開された最新のLatent Spaceポッドキャストインタビューで、Ryan氏は、この「ゴーストライブラリ」Symphonyの核心的な秘訣は、AIが失敗したときに、すぐにプロンプトを改善しようとするのではなく、「何の能力、コンテキスト、あるいは構造が欠けているのか？」と問うことにあると語りました。
その結果、この「ゴーストライブラリ」自体は実際のコードを一切含まず、AIエージェントが自ら100万行のコードを生成するのに必要なすべてのコンテキスト、仕様、ワークフローを提供しています。この思考の転換により、開発スピードを10倍に向上させ、チームはコードレビューさえ行わなくなり、AIが書いたコードをそのままマージできるようになりました。
もちろん、ポッドキャストではこのゴーストライブラリの7層アーキテクチャ設計についても詳しく議論されました。興味のある方は読み進めてください。ここでは詳述しません。注目すべきは、Ryan氏がMCP（Model Context Protocol）については悲観的な見解を持っている点です。「MCPはもう死んでいる」と。
なぜなら、それはコンテキストに大量のトークンを強制的に注入し、自動圧縮（autocompaction）に影響を与え、エージェントがツールの使い方を忘れてしまう可能性さえあるからです。
さらに、Ryan氏はOpenAIの新チームの中核エンジニアとして、将来のソフトウェアに関する厳密な判断も数多く示しました。
まず、Ryan氏は、将来のソフトウェアはまずエージェントにとって可読でなければならないと考えています。「もしソフトウェアが暗黙のコンテキストで溢れていれば、エージェントは効果的に動作できない」のです。
では、その可読性をどう判断するのでしょうか？
Ryan氏によると、究極の内ループ速度を追求するため、チームは「1分ビルド規律」を強制的に課しています。ビルド時間が1分を超えると、彼らは介入してリファクタリングを行い、エージェントのフィードバックループを十分に短く保ちます。このモードでは、コードは高度にモジュール化され、観測可能で、「トークン効率が高い」ものになります。
これは、従来のソフトウェア開発パラダイムの多くの段階や用語が変化することを意味します。例えば、Ryan氏は、オープンソースソフトウェアの依存関係は消滅する可能性があると指摘しています。彼の見解では、数千行のコード程度の中程度の複雑さのソフトウェアであれば、AIによって完全に書き換えられ、モデルに内包させることができるからです。
また、これまで定義されてきたソフトウェアのバグも再定義されます。エージェント時代において、「バグとは、エージェントが書いたコードで、まだ書かれていない非機能要件との間で不整合が生じているもの」です。
さらに、従来のMVCパターンも再定義されます。AIネイティブ版は「Model-View-Claw」です。ここでClawがハーネスに当たります。
次に、注目すべきは、OpenAIのこの「AIネイティブ」な開発プロセスが「ユーモア」に満ちていることです。
Ryan氏は、「ユーモアはAGIの一部だ」と明かしています。彼らはエージェントに企業文化を理解させることさえあり、ミーム画像の生成やSlackでのやり取りなども含まれます。彼らにとって、ユーモアは知性の重要なテスト指標であり、最新の5.4モデルは「ネタを使う」点で、すでに驚くべき成果を見せています。
もう一つ、読者と同じように気になるのは、OpenAIの新チームFrontierが一体何をしようとしているのか、そしてOpenAIはToB（企業向け）分野に本気で注力するのかという点でしょう。
Ryan氏もこのチームの「陰謀」を率直に共有しました。Frontierの究極のビジョンは、企業が安全かつ大規模にエージェントをデプロイできるようにすることです。この製品は本質的に「Specを配布する」システムで、企業のIM、セキュリティツール、ワークフローツールなどに統合できます。
Ryan氏はさらに、Codexアプリの週間アクティブユーザーが200万人を突破し、毎週25%のペースで成長していると明かしました。この数字は、OpenAIがToB分野で、世界中の企業を真に支援するAIネイティブプラットフォームへと変革しようとする野心を示しています。
さらに、司会者はOpenAIの重要な拡大の兆し、「サンフランシスコ中心からの脱却」を観察しました。Ryan氏は、OpenAIがシアトル、ニューヨーク、ロンドンへと拡大していることを認めました。「サンフランシスコへの引っ越しを避けるためにOpenAIのオファーを断った人を知っている」とRyan氏は冗談めかして言い、「今や彼らには選択肢がない」と付け加えました。
Ryan氏自身、シアトルオフィスの最初のエンジニア採用の一人であり、そこには「マッドメン風のオフィスの雰囲気」があり、ベルビューの新オフィスは「とても緑が多く、金色の装飾があり、太平洋北西部らしい」とのことです。
明らかに、この新設のシアトル・ベルビューオフィスは、OpenAIのToBビジョンにとって重要な支点となっています。
また、Ryan氏は現在、この「ハーネスエンジニアリング」にすっかりハマっていると語っています。彼はエージェントにコードを書かせることに止められなくなり、飛行機の中でさえラップトップを半開きにしてコードを書いているそうです。
「機械をいじるのをやめるのは難しい。機械は私に餌を与えさせたがるからだ。この継続的なフィードバックループ、AIが自律的に動いてコードを生成し続ける様子を見るのは、一種の特別な魅力があるようだ」
Ryan氏は驚くべき数字も明かしました。チームは1日あたり10億トークン（約2000〜3000ドル相当）を使用しているそうです。彼は、そうしなければ「怠慢」だと言います。「トークンをケチることは、効率をケチることと同じだ」
紙幅の都合でこれ以上は展開しませんが、全体的に、アルファ成分が過剰な共有でした。
以下は、編集部が整理した注目のポイントです。
ハーネスエンジニアリングの定義作
司会者：
では、本題に入りましょう。今、スタジオにOpenAIのRyan Lopopole氏をお招きしています。ようこそ。サンフランシスコに来ていただき、番組にお時間を割いていただきありがとうございます。あなたが書いたハーネスエンジニアリングに関する爆発的な記事は、この新分野の定義作になるでしょう。
Ryan Lopopole：
ありがとうございます。これは実に興味深いです。ある意味、私たちがこの分野の議論の仕方を定義したように感じます。
司会者：
まず背景を少し補足させてください。これがあなたのポッドキャスト初出演ですよね？では、あなたの経歴について教えてください。どのチームに所属していて、何をされているのですか？
Ryan Lopopole：
私はOpenAIのFrontierチームにいて、主に最先端製品の探索と新製品開発に取り組んでいます。Frontierは企業向けのプラットフォームで、エージェントが企業内で安全に、かつ大規模にデプロイされ、適切なガバナンスを備えることを核心としています。私とチームの役割は、モデルをどのように製品としてパッケージ化し、企業顧客にソリューションとして販売するかを探ることです。
司会者：
あなたの経歴を補足します：Snowflake、Stripe、Citadelですよね？
Ryan Lopopole：
はい、基本的には同じ種類の顧客です。
司会者：
でも、最初はあなたがそのような経歴だとは思いもしませんでした。Twitterを見たとき、全く逆の印象を受けました。「AIコーディングに全力投球」するようなスタイル、例えばPCをWaymoにくくりつけるような内容ばかりです。それから経歴を見ると、伝統的な企業環境でも非常に「真面目」に活動されていたことがわかります。とても興味深い組み合わせです。
Ryan Lopopole：
ハハ、「AIマキシマリスト」として生きるのは実に面白いです。もし、このような人格で生きるなら、OpenAIが最適な場所です。しかも内部的にはレート制限がないので、先ほど言ったような「フルスロットル」で走れます。
司会者：
つまり、あなたはFrontierチーム内の「特殊部隊」ですね。
Ryan Lopopole：
そうです。私たちは試みるための自由なスペースを与えられており、だからこそ、私は最初に極端な制約を設けました。自分ではコードを一切書かないということです。私の考えでは、企業にデプロイできるエージェントを構築するなら、それは私ができるすべてのことをこなせるべきだ、ということです。過去6〜8ヶ月、これらのコーディングモデルとハーネスを使用してきて、モデルの能力は十分で、ハーネスも十分に成熟しており、能力の点ではほぼ私と同質だと実感しています。そこで、「コードを書かない」という制約から出発し、自分自身がエージェントを通じて仕事を完了しなければならないように追い込みました。
基本的な構築の考え方：モデルができないタスクは分割する
目標：ビルド時間を1分に圧縮
司会者：
簡単に背景を言うと、これがあなたの記事の核心です。あなたたちは5ヶ月かけて内部ツールを開発し、自分で書いたコードは0行ですが、最終的なコードベースは100万行を超え、効率は人力の10倍になったと言っています。
Ryan Lopopole：
はい、それが基本的な考え方でした。最初は、とても初期のCodex CLIとCodex miniモデルを使っていて、当時はモデルの能力は今よりずっと低かったです。しかし、これは良い制約でした。モデルに機能を実装させようとすると、うまく組み立てられないという苛立ちが非常にリアルでした。そこで、ある方法論が生まれました。「モデルができないときは、タスクを分割し、より小さなモジュールを構築し、それらを大きな目標に組み立てる」という方法です。正直、最初の1.5ヶ月は効率が非常に低く、おそらく手書きコードの10倍遅かったです。しかし、このコストを払ったおかげで、最終的にはエンジニア1人の能力を超える開発工程をこなせる「組み立てライン」を構築できました。
その後、GPT-5.1、5.2、5.3、5.4など、多くのモデルバージョンを経験しました。各世代でモデルの振る舞いは異なり、モデルの変化に合わせてコードベースを調整する必要がありました。例えば、興味深い点として、5.2のときはCodexハーネスにバックグラウンドシェルがなかったため、ブロッキングスクリプトを使って長時間のタスクを実行できました。しかし5.3になると、バックグラウンドシェルが登場し、モデルは逆に「忍耐強く」なくなり、ブロッキングタスクを待つのを嫌がるようになりました。そこで、ビルドシステム全体をリファクタリングし、ビルド時間を1分以内に圧縮する必要がありました。多人数が協力し、様々な意見があるコードベースでは、これはほぼ不可能です。しかし、私たちの唯一の目標はエージェントを効率的に動かすことだったので、1週間でMakefileからBazel、そしてTurbo、NXへと移行し、最終的にはビルド速度が十分に速いNXに落ち着きました。
司会者：
TurboからNXへ切り替えたのは興味深いですね。多くの人は逆です。
Ryan Lopopole：
正直、私はフロントエンドのリポジトリアーキテクチャにはあまり詳しいわけではありません。これについてはJoshに聞いてみてください。彼がシステムを構築した人ですから。私はNXチームを知っており、Turbo（Jared Palmer氏によるもの）も知っているので、比較は興味深いです。しかし、私たちの核心的な目標はシンプルです。ビルドを速くすることです。私たちのアプリケーションはReact + Electronのモノリシックアプリで、ビルド時間を1分以内に抑える必要があります。
司会者：
「バックグラウンドシェル」はあまり馴染みがありません。
Ryan Lopopole：
簡単に言うと、Codexがバックグラウンドでタスクを起動し、他のことを続けられる機能です。例えば、ビルドを実行しながら、同時にコードをレビューするなどです。これにより、全体的な時間効率が上がります。
司会者：
なぜ1分でなければならないのですか？5分ではだめなのですか？
Ryan Lopopole：
私たちは内ループ（inner loop）を可能な限り速くしたいと考えており、1分というのは覚えやすい目標であり、達成可能だからです。この時間を超えると、それは信号として扱います。つまり、立ち止まってタスクを分割し、ビルドグラフを最適化し、再びエージェントに仕事をさせる必要がある、ということです。
司会者：
一種の「ラチェット機構」のように聞こえます。ビルド時間の規律を強制しないと、際限なく膨らんでしまう。
Ryan Lopopole：
その通りです。従来のプラットフォームチームのやり方は、ビルド時間が徐々に長くなるのを許容し、許容できないレベルに達してから数週間かけて最適化するというものです。しかし今はトークンが安く、モデルは高度に並列化できるので、システムを継続的に「剪定」し、これらの不変量を維持できます。これにより、コードベースはより安定し、制御可能になり、開発プロセス中により多くの確実性を頼りにできるようになります。
OpenAIはもはや人間によるコードレビューには頼っていない
司会者：
あなたは記事の中で、人間がボトルネックになったと述べています。最初、チームは3人だけでした。100万行近いコード、1500のPRを生み出しましたが、その背景にある考え方は何ですか？
コード自体はある意味「使い捨て」可能ですが、レビューは大量に行われています。記事の中では、「すべてをプロンプト化する」こと、エージェントが見えないものは基本的にゴミであり、存在すべきではないと述べています。では、全体として、どのようにシステムを構築したのですか？また、人間がボトルネックになった後、人間はどのように関与しているのですか？例えば、PRレビューの層はどのように行われていますか？
Ryan Lopopole：
実は、私たちはもう「人間がコードレビューをする」ことにあまり頼っていません。現在の人間によるレビューの多くは、マージ後に行われています。マージ自体もレビューというよりは、自分を「安心させる」儀式に近いです。根本的に、モデルは無限に並列化可能であり、GPUとトークンを投入する意志があれば、生産能力を無限に拡大できます。
唯一真に希少なリソースは、チーム内の人間の同期的な注意です。1日は決まった時間しかなく、食事もするし、睡眠もとりたいですが、機械をいじるのをやめるのは難しいですね。
だから、一歩引いて、システム思考で見る必要があります。エージェントはどこで間違いを犯すのか？私は時間をどこに費やしているのか？今後、これらの時間をどうすれば費やさずに済むか？そして、これらの経験を自動化として定着させ、SDLC（ソフトウェア開発ライフサイクル）の一部の問題を解決するのです。
最初は、コードを非常に注意深く見る必要がありました。なぜなら、エージェントはまだ十分な「構築ブロック」を持っておらず、モジュール化され、分解可能で、信頼性が高く、観測可能なシステムを生成する能力がなく、ましてや実際に動くフロントエンドを出力する能力もなかったからです。一日中端末の前に座り、一度に1つか2つの問題しか処理できないのを避けるため、私たちはモデルの「観測可能性」を向上させることに多くのエネルギーを費やしました。これが記事にあった図です。
司会者：
このトレーシングシステムについて話しましょう。トレースが先ですか、アプリケーションが先ですか？
Ryan Lopopole：
最初はアプリケーションだけでした。その後、vectorからログイン、メトリクス、APIなどに至るまで、おそらく半日程度で構築しました。私たちは意図的に、高レベルで開発効率の良いツールを選びました。現在、エコシステムは非常に充実しています。例えば、MIというツールを多用しており、これを使うとVictoriaMetricsのGo製コンポーネント一式をローカル開発環境に簡単に持ち込めます。それに少しのPythonのグルーコードを加えてサービスを起動すれば、すぐに使えます。非常に重要な設計として、システム全体を「逆転」させました。先に環境を構築してからエージェントを入れるのではなく、エージェントをエントリーポイントとして、Codexを直接起動し、skillsやスクリプトを通じて、必要に応じて開発環境全体を自ら起動し、環境変数を設定して、ローカルアプリケーションが自身が立ち上げたサービスを指すようにします。
これが、今のreasoningモデルと、かつての4.1、4o時代のモデルとの根本的な違いだと考えています。以前のモデルは「思考」せず、明確な状態マシンを持つボックスの中に閉じ込める必要がありました。しかし今は、モデルとハーネスをシステムそのものとし、十分なオプションとコンテキストを与えて、自ら意思決定させるのです。
司会者：
多くのものが「スキャフォールド（足場）」の方向に進んでいるように聞こえます。しかし面白いのは、reasoningモデルが登場してから、かえってそれほど重いスキャフォールドが必要なくなった点です。あなたたちは、spec.mdや非常に短いagent.mdのような構造を使っています。
Ryan Lopopole：
はい、確かに一連の構造を定義しました。例えば、総目録（おそらく100行程度）があり、その下に様々な「skills」があります。この構造の利点は、コードベースに新しいコンテンツを低コストで注入しながら、人間とエージェントの行動をガイドできることです。
司会者：
ある意味、あなたたちはゼロから「エージェントスキル」を再発明したのですね。
Ryan Lopopole：
確かにそうです。なぜなら、私たちが始めたときにはこの概念がまだ存在しなかったからです。総目録ファイルがあり、そこからcore_beliefs.mdやtech debt trackerなどの小さなskillsがあります。
中でも、tech debt trackerとquality scoreは興味深いです。これらは本質的に極小のスキャフォールドであり、Codexへのフックとして機能するマークダウンテーブルです。定義されたビジネスロジックをチェックし、設定されたガードレールに適合しているかを評価し、自身に後続タスクを生成させます。Jiraのようなシステムが登場する前は、これらの後続作業をマークダウンに記録し、定期的にエージェントを起動して「借金を清算」させていました。
ここで重要な洞察があります。モデルは「テキストを渇望している」のです。私たちが行っていることの多くは、本質的にシステムにより多くのテキストを注入することです。例えば、オンラインアラートが発生し、timeoutがないことが原因だったとします。Slackで直接Codexにメンションして、「timeoutを追加してほしい。同時に、信頼性ドキュメントを更新して、すべてのネットワークリクエストにtimeoutが必須であると明記して」と伝えられます。こうしてバグを修正しただけでなく、「何が良い実践か」という知識をシステムに恒久的にエンコードしました。この知識はコンテキストとして後続のコーディングエージェントに受け継がれます。
また、これらのテキストに基づいてテストを生成したり、コードレビューエージェントを動作させたりして、コードの「許容範囲」を絞り込むことができます。
モデルにある程度の判断の余地を与え、過度な従順さを防ぐ
司会者：
しかし、ここには問題があります。「長期的に正しい」ルールを作っているつもりでも、実は例外を見落としていて、後でロールバックしなければならないことがあります。
Ryan Lopopole：
確かに、モデルは時に「過度に従順」になります。だから私たちは設計上、ある程度の判断の余地を与えています。例えば、quality scoreのようなツールは、毎回強制実行するのではなく、モデル自身がいつ呼び出すかを決定します。
プロンプトレイヤーでも、エージェントに「反論」させることを許可しています。当初、コードレビューエージェントを導入したときのフローは、Codexがローカルでコードを生成し、PRをプッシュし、レビューエージェントがトリガーされ、コメントを書き、Codexにそのコメントに応答させる、というものでした。当初の問題は、コードを書くエージェントが「良心的」すぎて、レビュアーに引きずられ、システムが収束しないことでした。そこで、双方のプロンプトを調整しました。レビューエージェントは「通過」を優先するよう（P2以下の問題しか提示しない）にし、P0はコードベース全体を破壊するレベルとしました。同時に、コードを書くエージェントはレビュー意見を拒否したり、後回しにしたりすることを許可しました。現実もそうで、あるレビューは単なるFYI（参考情報）であり、即座に修正を求めているわけではありません。このようなコンテキストを与えないと、エージェントはすべての指示を機械的に実行してしまいます。
司会者：
ある点を確認させてください。これらのエージェントは自動でマージできるのですね？これは多くの人にとって受け入れがたいことかもしれません。しかも、あなたが挙げた範囲はほぼフルスタックです。製品コード、テスト、CI、リリースツール、内部ツール、ドキュメント、レビューコメント、さらにはリポジトリ管理スクリプトまで、すべてエージェントが書いています。
Ryan Lopopole：
はい、基本的に全部そうです。しかも並列実行されています。
司会者：
では、「緊急停止」ボタンはあるのですか？例えば、チームの誰かがワンクリックですべてを止められるような？
Ryan Lopopole：
私たちはネイティブアプリを作っており、インフラではないので、継続的デプロイは行っていません。リリースブランチの作成には人間が関与する必要があり、本番稼働前には人間が承認するスモークテストを経る必要があります。つまり、リリースの段階では人間がゲートを守っています。
司会者：
つまり、あなたたちは「99.999%の可用性」を求められるインフラシステムを作っているわけではないのですね。
Ryan Lopopole：
その通りです。そして強調しておきたいのは、これらはすべて「新規リポジトリ」で行われたことです。これがすべての本番環境にそのまま適用できるわけではありません。
GPT-5.4は初めてトップレベルのコーディングと推論を融合したモデル
既にCodexに自分でブログを書かせている
司会者：
最初の1ヶ月は基本的に「逆方向」に仕事をしていて、システムに適応し続ける必要がありました。しかし今では非常に自動化されています。今、人間はループの中でどれくらいの比重を占めていますか？また、どのボトルネックをさらに自動化したいですか？そして、モデルの能力は今後どう発展し、人間をさらに代替していくと思いますか？例えば、私たちはついにGPT-5.4を手に入れました。これは非常に強力なモデルです。
Ryan Lopopole：
はい、これはトップレベルのコーディング能力と推論能力を初めて融合させたモデルです。Codexレベルのコード能力と汎用推論能力の両方を持ち、さらにcomputer useもサポートしています。今ではCodexに直接ブログを書かせることもできます。以前はチャットとコーディングを切り替える必要が……もしかしたら私は失業するかもしれません（笑）。
司会者：
その言葉で、5.4を使って完全にAI駆動のニュースレターを作れるな、と思いました。
Ryan Lopopole：
はい、これは「クローズドループ」の一例です。例えば、先ほどのダッシュボードですが、CodexにGrafanaダッシュボードのJSONを書かせ、それを公開し、同時にアラートに応答させます。つまり、アラートがトリガーされたとき、それがどのダッシュボードで、どのアラートで、コードベースのどのログに対応しているかを知っています。これらの情報がすべて統合されているからです。
司会者：
つまり、「すべてを所有」している必要があるのですね。
Ryan Lopopole：
その通り、これが非常に重要です。アラートがトリガーされなかった障害が発生した場合でも、既存のダッシュボード、メトリクス、ログに基づいて監視体系の欠陥を特定し、一度に修正できることを意味します。まるで、バックエンドからフロントエンドまで機能を一気に押し出せるフルスタックエンジニアのように。
「コードの細部への執着はもうない」
鍵は「システムプリミティブ」
司会者：
あなたたちが行っている多くの仕事は、本質的に、ソフトウェアを「人間の可読性」ではなく「モデルの書き方」に合わせることのように聞こえます。つまり、human-legibleからagent-legibleへの転換です。これは、より大規模なチームにとって何を意味するのでしょうか？OpenAI内部や、ソフトウェアエンジニアリング業界全体において、皆がこの切り替えをしなければならないのでしょうか？これは非常に急進的な変化です。
Ryan Lopopole：
私のマインドセットは、実際には具体的な実行から「切り離された」状態です。私はコードの細部についてそれほど意見を持っていません。むしろ、500人のチームを管理するようなものです。その場合、各PRを深く掘り下げることは不可能です。だから、私たちはpost-merge reviewを一種の類推として使っています。いくつかのコードをサンプリングして見るだけで、そこからチームの問題点、ボトルネック、どこにサポートが必要か、どこが順調かを推測し、焦点を調整します。
私は「コードを具体的にどう書くか」についてはあまり執着を持っていませんが、「システムプリミティブ」には非常に注目しています。例えば、コマンドベースのクラスがあり、これは再利用可能なビジネスロジックをカプセル化し、同時にトレーシング、メトリクス、観測可能性を備えています。このようなプリミティブこそが鍵です。コードがこれらのプリミティブを使っていれば、自然とレバレッジが効きます。重要なのはコード構造ではなく、正しい抽象化を使っているかどうかです。
AI時代のMVC：Model-View-Claw
司会者：
これは、あなたの記事にあるシステム思考に戻ります。例えば、アーキテクチャを強制する方法や、「エンジニアリングのセンス」をエンコードする方法など。
Ryan Lopopole：
はい。そしてモデルの能力が向上するにつれて、彼ら自身も抽象化を提案し、問題を解き放つ手助けをするのが得意になってきています。これにより、私はより高いレベルに立って、本当にチームの納品を妨げているのは何かを考えることができます。
司会者：
あなたのプロジェクトは本質的に100万行のElectronアプリであり、同時に独自のサービスを管理しており、一種のBFF（backend for frontend）に似ています。
Ryan Lopopole：
はい、バックエンドはありますが、クラウドにデプロイされています。Electron内部には、mainとrendererの2つのプロセスがあり、これは自然とMVCのような構造を形成し、私たちは同じ厳格さでレイヤーを分けています。
ちなみに、ある面白いネタがあります。従来のMVCはModel-View-Controllerですが、AIネイティブ版はModel-View-Clawです。Clawがハーネスです。
司会者：
これは面白い表現ですね。
コーディングエージェントはコードを書くだけでなく、すべてをこなす
Ryan Lopopole：
私は確かに、CodexとハーネスをAI製品構築の方法として、まだ大きな探求の余地があると感じています。現在、モデルのコーディング能力は非常に速く進歩しており、各世代でタスクの複雑さが著しく向上しています。製品の問題を「コードの問題」に圧縮できれば、Codexハーネスで解決するのは非常に自然です。なぜなら、インフラはすべて完了しているので、あなたはプロンプトでそれを駆動するだけでいいからです。
そして、これはエンジニアにとって非常に「理解可能」な能力拡張の方法です。あなたが元々書けるスクリプトをモデルに渡すだけでいいからです。
司会者：
つまり、コーディングエージェントは単にコードを書くだけでなく、あらゆる知識作業を「飲み込む」ということですね。多くの人は、コーディング以外のタスクには別のエージェントが必要だと思い込んでいますが、実際にはコーディングエージェントから上へと拡張しているのですね。
Ryan Lopopole：
その通り。本質的に、タスクをコードの問題として定義すれば、すべてがコーディングエージェントです。
内部で使っている「完全委譲」Skillを暴露
司会者：
では、現実的な質問をします。チケットシステムやPRのような仕組みは、根本的に再構築される必要がありますか？Git自体がマルチエージェントには非常にフレンドリーではありません。
Ryan Lopopole：
私たちはworktreeを多用していますが、それでもマージコンフリクトは存在します。しかし、モデルは実際、コンフリクトの解決が非常に得意です。私が同期的に端末を監視しなくなると、これらのコンフリクトは私にとってほぼ「無視できる」ものになります。
私たちには「dollar land」というskillがあり、これはCodexにPRのライフサイクル全体を処理させます。PRを作成し、人間とエージェントのレビューを待ち、CIが通るのを待ち、flakyを修正し、コンフリクトを処理し、再マージし、マージキューに入り、メインブランチに到達するまでをガイドします。これが「完全委譲」の意味です。人間にとっては非常に重いプロセスですが、エージェントは完全に処理でき、私は基本的にPCを開けっぱなしにしておくだけでいいのです。
以前は私の支配欲が強かったですが、今は逆に「多くの点で、確かに私よりもうまくやっている」と感じています。十分なコンテキストを与えれば、という条件付きですが。
エージェントの各バグに注目する
司会者：
記事には書かれていないけれど、皆が議論していることはありますか？
Ryan Lopopole：
私がはっきりと述べなかったかもしれない点があります。私たちが書いたドキュメント、テスト、レビューエージェントは、本質的に「非機能要件」（高可用性、高品質、保守性など）をモデルのコンテキストに注入するためのものです。私たちはそれをドキュメントとして書くか、lintエラーを通じて正しいやり方を提示します。システム全体の本質は、エンジニアの頭の中にある「何が良いか」という暗黙知をすべて明示化し、エージェントが学習できるようにすることです。
だから、私たちはエージェントのバグに特に注目します。なぜなら、各バグは「まだ書かれていない仕様」があることを意味するからです。これこそが、システムが進化する原動力です。
司会者：
では、皆が誤解していた点は？
Ryan Lopopole：
誤解というよりは、誰かがこの点を指摘してくれて、「そうだ、それこそが私が本当に伝えたかった核心だ」と気づきました。
GPT-5.4にまとめて投げ込むのも、非常に価値がある
司会者：
なるほど、興味深いです。ある興味深い現象があります。多くの人が、あなたの記事のリンクをPiやCodexに直接投げて、「私のリポジトリをこうしてくれ」と言うそうです。これは一種の「完全な再帰」を実現しています。しかも、意外にもうまくいくのですか？
Ryan Lopopole：
はい、意外なほどうまくいきます。実は昨日、私も5.4で試しました。外で講演をしていて時間がなく、「この記事に基づいて、すぐに似たようなスキャフォールドを構築できるか？」と思ったのです。まずそうしてみて、それから小さなサイドプロジェクトを取り上げました。これはコードを一切書いていない、音声TTSで適当に作った非本番級プロジェクトです。そして、「これを完全に自動化された体系にするには、どう変えればいいか？」と尋ねました。このプロセスは非常に価値がありました。コードを修正してくれるだけでなく、システムを「分析」してくれるからです。すべてのコード、コンテキスト、記事を一緒に投げると、問題と改善点を段階的に理解させてくれます。
オープンソースソフトウェアの依存は消滅するかもしれない
AIが内部で書き換える
司会者：
もう一つ、触れたい点があります。あなたの記事に対して、取締役会議長のBret Taylor氏も言及しました。彼は、ソフトウェアの依存は消滅し、将来的には直接「内包（vendored）」できるようになると言っています。どう思いますか？
Ryan Lopopole：
基本的に同意します。しかし現実には、DatadogやTemporalのようなサービスにはまだ費用を払う必要があります。現在のモデルの能力では、「内包」できる依存は、低から中程度の複雑さの範囲にあります。
司会者：
「中程度の複雑さ」とは具体的に何を指しますか？
Ryan Lopopole：
おそらく数千行のコードの依存であれば、1午後で簡単に書き換えられます。そして重要なのは、実はその全機能が必要なわけではないという点です。依存を内包することで、汎用ロジックをすべて剥がし、本当に必要な部分だけを残せます。
司会者：
私はずっと、これは「プラグインの終焉」だと言っています。
Ryan Lopopole：
確かにそうですね。なぜなら、オープンソースプロジェクトは汎用性のために、大量の冗長性と複雑さを導入するからです。しかし、自分で実装すれば、最小限のセットだけが必要です。
もう一つの実利的なメリットは、私たちがリポジトリでCodexセキュリティレビューをデプロイする際、これらの「内包」された依存を直接修正でき、従来のプロセス（PRを作成し、上流のリリースを待ち、それを引き取り、互換性を処理する）を経る必要がないことです。この全プロセスの摩擦コストが大幅に下がります。トークンが安い前提では、コード自体も「安く」なります。
司会者：
しかし、反対意見も明らかです。大規模なテストやセキュリティの問題です。LinuxやMySQLのようなシステムは、「クラウドソースレビュー」に依存して品質を保証しています。もし自分で書き換えれば、他人が犯した過ちを繰り返す可能性があります。
Ryan Lopopole：
その通りです。依存を内包すると、「ゼロから」の状態に戻り、コード品質への信頼を再構築しなければなりません。
内部のAIツールはすべてCodexが書いている
エージェントに任せ、人間はボトルネック
司会者：
最初の話に戻りましょう。システム全体、内部ツールを含め、すべてCodexが書いたのですね？可視化ツールさえも？
Ryan Lopopole：
はい、今、AI関連の内部ツールを作る場合、基本的にはプロンプトで生成しています。先日、誰かに見せたとき、「どれくらいかかりましたか？」と聞かれ、「実は時間をかけていません」と答えました（笑）。
ある興味深い例があります。アプリを最初の内部ユーザーにデプロイした後、パフォーマンスの問題に遭遇しました。そこで、ユーザーにトレース（tarパッケージ）をエクスポートさせ、当番エンジニアに渡しました。彼はCodexを使って非常に美しいローカルツール（Next.jsアプリ）を作りました。ファイルをドラッグ＆ドロップしてトレース全体を可視化できるもので、非常に良くできており、1午後で完成しました。しかし、後で気づいたのですが、これは全く必要ありません。tarパッケージをCodexに投げて分析させれば、数分で結果が得られます。
だから、「人間の可読性」から出発してデバッグプロセスを最適化するのは、実は間違いです。これは人間を不必要に巻き込みますが、エージェントなら直接完了できるからです。
司会者：
これは確かに直感に反します。私たちが慣れ親しんだやり方は、ここではむしろ非効率なのです。
Ryan Lopopole：
はい。例えば、伝統的にはJaegerをデプロイしてトレースを見ますが、今はトレースを見る必要さえありません。なぜなら、私自身がコードを修正しないからです。
司会者：
核心は、一連の「自己完結したシステムスタック」が必要で、それをエージェントに完全にコントロールさせることです。
Ryan Lopopole：
その通り、これが非常に重要です。そして、私たちは今後、この点についてもっと共有していく予定です。
ゴーストライブラリの構築フローを暴露：3つのCodexインスタンスが絶えずループする
司会者：
後でSymphonyについても触れます。今は「spec」の方法でソフトウェアを配布していますが、これは「ゴーストライブラリ」と呼ばれることもあり、クールな呼び名です。
Ryan Lopopole：
はい、この方法により、ソフトウェアの配布コストが大幅に下がります。specを定義し、コーディングエージェントがそのspecに基づいてローカルでシステムを再構築するようにすればいいのです。
プロセスも興味深いです。既存のリポジトリからスキャフォールドを抽出し、新しいリポジトリを作成し、Codexに元のリポジトリに基づいてspecを生成させます。そして、それを実装するために新しいCodexインスタンスを起動し、さらに別のCodexを起動して実装と元のコードを比較し、specを継続的に最適化して、両者がより一致するようにします。このプロセスは、specがシステム全体を高忠実度で再現できるようになるまで、絶えずループします。
人間は「複雑＋全新」の問題に適しており、他はエージェントに任せればいい
司会者：
そして、この過程で、あなたは基本的に人間のバイアスを持ち込んでいません。
Ryan Lopopole：
はい。人間がspecを書くとき、しばしば自分のアイデアを持ち込みがちですが、「こうすべきだ」と思っても、実はエージェント自身がより良い解を見つけられることがあります。
私も最近考えているのは、エージェントが「自分では実装できないspec」を書けるかどうかです。つまり、自身の能力を超えたシステムを想像できるかどうかです。
これは、問題を「単純／複雑」と「既存／全新」の2次元座標で見られると思います。「複雑＋全新」の問題には、まだ人間が必要です。しかし、他の象限は、既に解決されつつあります。
これは、人間が最も価値のある場所に時間を使えることを意味します。本当に未知の領域や、深いリファクタリングを必要とするシステム設計などです。
司会者：
これは、人間をより高い抽象度へと押し上げていることになります。
Ryan Lopopole：
その通り、これこそ私が目指していることです。
ゴーストライブラリの誕生
司会者：
では、正式にSymphonyについて話しましょう。あなたたちはElixirを選びましたね。興味深いです。
Ryan Lopopole：
はい、しかし実際には、Elixirはモデルが選んだ結果に過ぎません。Elixirを選んだのは、そのプロセスモデル（supervisionやGenServerなど）が、私たちのようなタスクオーケストレーションに非常に適しているからです。私たちは本質的に、各タスクのために小さな「デーモン」を起動し、それを完了へと駆動しています。
これは、モデルが同時実行や回復などの多くの能力を「無料で」得られることを意味します。私はElixirとBEAMの知識を補うために特別に学びました。ほとんどの人はこれほど高い同時実行スケールを必要としませんが、確かに優れた思考モデルを提供してくれます。
司会者：
Symphonyはどのようにして誕生したのですか？
Ryan Lopopole：
昨年12月末、各エンジニアは毎日約3.5個のPRを作成していました。1月初頭、5.2モデルが登場すると、特別な最適化なしで、この数字は1人1日あたり5〜10個のPRに急上昇しました。
Ryan Lopopole：
皆さんが同じような感覚を持っているかどうかわかりませんが、このような頻繁なコンテキストの切り替えは、実は非常にエネルギーを消耗します。1日の終わりには、基本的に絞り取られたような気分になります。そこで問題は戻ってきます。人間の時間はどこに費やされているのか？実は、様々な端末ウィンドウ（T-Muxペイン）の間を行き来して、エージェントを前進させることに費やされています。
そこで私たちはもう一つのことを行いました。人間をこのループから外す方法を考えたのです。これがSymphonyの由来です。本質的には、非常に「狂った」スプリントであり、人間がずっと端末の前に座る必要がないようにすることを目指しました。私たちは様々な案を試しました。例えば、開発ボックスやエージェントの自動起動などです。理想的な状態はシンプルで、毎日2回PCを開いて「はい／いいえ」をクリックし、後は海辺で寝そべっていればいいのです。
このモードがもたらした変化の一つは、私が「遅延」に対して鈍感になり、コードそのものへの執着もなくなったことです。私はコードの「創作プロセス」にほとんど参加していないので、もし生成されたものがゴミであれば、ためらいなく捨てられます。Symphonyには「再作業（rework）」状態があります。PRが提出され、人間がレビューするとき、このレビューは非常に軽量であるべきです。マージできるか、できないかです。できない場合、再作業に戻され、ElixirサービスがworktreeとPR全体を直接削除し、一からやり直します。
ここでの重要な問いは、なぜそれがゴミなのか？エージェントは何を間違えたのか？まず、これらの問題を修正し、それから再びタスクを進めるのです。
MCPについては個人的には悲観的
司会者：
なぜこれらの能力はCodex Appにないのですか？
Ryan Lopopole：
私たちのチームは常に「製品より先を走る」ようにしており、可能な限りAIファーストな探索を行っています。私たちが作ったものの多くは、後に正式な製品に入ります。例えば、Codex App、skills、自動化能力など、私たちは深く関与しています。しかし私たちの利点は、製品のペースに縛られず、迅速に試行錯誤し、それからスケール可能なソリューションとして定着させられることです。
このやり方は興味深いですが、非常に混沌としています。私は、コードベースの現在の真の状態を完全に把握していないことがよくあります。なぜなら、私はループの中にいないからです。
例えば、あるとき、チームがPlaywrightをElectronアプリに直接接続し、MCPを通じて駆動させることがありました。私はMCPについては実際かなり悲観的です。なぜなら、それはコンテキストに大量のトークンを強制的に注入し、自動圧縮（autocompaction）に影響を与え、エージェントがツールの使い方を忘れてしまう可能性さえあるからです。実際、私が本当に必要とするPlaywrightの呼び出しは、おそらく3種類だけです。
後に、誰かが直接ローカルデーモンを書き、Playwrightをカプセル化し、極小のCLIを公開しました。私にとって、この出来事があったことを全く知りませんでした。なぜなら、私にとっては、単にCodexを実行すると、それが強化されていたからです。
そのため、人間のレベルでは、同期的な情報共有に多くの時間を費やす必要があります。毎日のスタンドアップは45分もかかります。なぜなら、現在のシステムの状態を「ブロードキャスト」する必要があるからです。
「1万人エンジニア規模」のコードアーキテクチャ
司会者：
これは、1人と複数エージェントの組み合わせならまだしも、複数人と複数エージェントの組み合わせになると、非常に複雑になります。
Ryan Lopopole：
その通り、これが、私たちがコードアーキテクチャにおいて「1万人規模」の設計を採用している理由です。
司会者：
この「1万人規模」とはどういう意味ですか？
Ryan Lopopole：
私たちのリポジトリは、約500のnpmパッケージに分割されています。7人のチームにとって、このアーキテクチャは深刻な「過剰設計」です。しかし、1人を10〜50のエージェントと見なせば、この生産能力の規模は合理的です。このとき、深い分割、モジュールの分離、インターフェース境界が非常に重要になります。
OpenAIは「Slack」を作るべきだ
司会者：
あなたたちはissue管理にLinearを使っているのですか？
Ryan Lopopole：
はい、Slackも多用しています。例えば、低複雑度の修正タスクは、Slackで直接Codexをトリガーして処理させ、同時に知識をコードベースに同期させます。
正直、私の最大のアイデアは、OpenAIが「Slack」を作るべきだということです。なぜなら、AIが本当に「経済的価値のある仕事」をするなら、人間と自然に協調できなければならず、それには新しい協調ツールが必要だからです。
コードベース全体で6つのskillsしかない
司会者：
現在、CodexはモデルからCLI、Appへと進化し、複数のエージェントを並列に実行できますが、チーム協調はまだ欠けています。将来のツールはどう進化すると思いますか？各チームが独自のセットを作るのでしょうか、それとも汎用的なソリューションが登場するのでしょうか？
Ryan Lopopole：
まだ汎用的な答えはありません。しかし、私はある傾向を持っています。「コード構造」と「プロセス構造」をできるだけ一致させることです。コード自体がコンテキストであり、プロンプトだからです。異なるモジュール構造が全く異なると、エージェントは頻繁にコンテキストを切り替える必要があり、効率が下がります。
同じロジックはskillsにも適用されます。私たちのコードベース全体で、skillsは6つしかありません。ある開発プロセスがカバーされていない場合、私たちの最初の反応は新しいskillを追加することではなく、既存のskillに統合することです。このメリットは、エージェントの行動を変えるコストが、人間の行動を変えるコストより低いことです。
第0層：Skill蒸留メカニズム
司会者：
あなたたちはエージェントに自身の行動を変えさせるのですか？例えば、自己最適化など？
Ryan Lopopole：
はい、私たちには「skill蒸留」メカニズムがあります。例えば、Codexに自分のセッションログを振り返らせ、「私をどう使えばもっとうまく使えるか？どんな新しいskillsが必要か？」と尋ねます。これは一種の「自己反思」です。
しかし、より重要なのは、これらのデータを集約することです。チーム全員のセッション、PRコメント、失敗したビルドをすべて収集し、毎日エージェントを動かして分析させます。「全体としてどうすればもっとうまくできるか？」そして、これらの改善をコードベースにフィードバックします。
言い換えれば、各人の経験は自動的にチームの能力に変わります。
PRコメントやビルド失敗は、実は信号であり、ある時点でエージェントがコンテキストを欠いていたことを示しています。私たちの仕事は、この欠けている情報をシステムに補うことです。
司会者：
私も似たようなことをしています。AIツールでタスクを完了するたびに、「次はもっとうまくできるか？」と自問します。これは一種のメタプログラミング的な反思です。
Ryan Lopopole：
その通り、本質的にSymphonyは多層的な「反思システム」と見なせます。ある種の「第ゼロ層」です。この6層は、ポリシー（policy）、設定（configuration）、調整（coordination）、実行、統合、可観測性です。
そのいくつかについては既に触れましたが、第ゼロ層はむしろ、「今の働き方はうまくいっているか？改善できるか？」と問うものです。例えば、私自身のworkflow.mdなどを修正できるか？私には確信はありません。
司会者：
はい、もちろん可能です。
Ryan Lopopole：
そして、このシステムは自分自身でチケットを作成さえできます。私たちは完全な権限を与えているからです。はい、自分自身に「チケット作成」のチケットを作らせるのです。チケットに、どのような後続作業をフォローアップすべきかさえ書き込めます。自己修正。
だから、エージェントをボックスの中に閉じ込めないでください。その領域内で完全なアクセス権を与えるべきです。
司会者：
「エージェントをボックスに入れてはいけない」と言いましたが、私の頭の中の最初の反応は、やはりボックスに入れるべきだ、ただしそのボックスは必要なすべてを提供するものであるべきだ、というものでした。
Ryan Lopopole：
はい、コンテキストとツールを。
エージェントに完全なループを形成させるには、クラウドへの依存を減らすべき
司会者：
その通りです。しかし、私たちは開発者として、様々な外部システムを呼び出すことに慣れています。しかし、ここではPrometheusのようなオープンソースツールを使い、ローカルで実行させることで、完全なループを形成できますよね？
Ryan Lopopole：
はい。私は、クラウドへの依存を可能な限り減らすべきだと考えています。同時に、エージェントが何にアクセスできるかを真剣に考えるべきです。彼らは何を見ているのか？その情報はループにフィードバックされているか？最も基本的な点として、例えば自分の呼び出しチェーンを見せれば、どこで間違えたかを判断できます。しかし、問題は、それを再フィードバックしているかどうかです。最も基本的なレベルでは、入力と出力を明確に見る必要があります。エージェントはこれらの出力にアクセスできるか？
エージェントは多くの点で自己改善できます。本質的に、これらはすべてテキストですよね？私の仕事は、テキストをあるエージェントから別のエージェントへ流す方法を考えることです。興味深いことに、このAIの波が始まったとき、Andre氏は「英語が最も熱い新しいプログラミング言語だ」と言いました。今、それが現実になりました。
多くのソフトウェアはもともと人間のために設計され、GUIがありました。しかし今、私たちはCLIの進化を見ています。ほぼすべてのツールにCLIがあり、エージェントはそれを非常にうまく使います。
次の鍵は、より良い視覚能力を持つかどうかです。より良い小規模サンドボックスを持つかどうかです。しかし今のところ、この方法は非常に効果的です。モデルはツールを使うのが好きで、テキストを読むのが好きなので、直接CLIを与えて自由にさせれば、ほぼすべてのことに適用できます。
非テキストコンテンツ、OpenAI内部での処理方法：併用
Ryan Lopopole：
はい。私たちは非テキストのものもこの形式に変換し、モデルのパフォーマンスを向上させています。例えば、エージェントにUIを「見せたい」ですが、それは人間のような視覚感知ではありません。モデルは赤い四角を見るのではなく、「赤い四角のボタン」というような意味論を見て、潜在空間で理解しています。
だから、本当にレイアウトを理解させたい場合、逆に画像をASCIIにラスタライズしてから与えた方が簡単なことがあります。しかも、実は両方の方法を同時に使って、モデルが操作対象を理解するのをさらに最適化できます。
調整層は特に難しい
司会者：
もういくつかの層について話しましょうか？特に興味深いものはありますか？
Ryan Lopopole：
私は「調整層」が特に難しいと思います。
司会者：
では、それについて話しましょう。
Ryan Lopopole：
これもTemporalの核心です。ここでの鍵は、specをElixir実装に変換するとき、モデルが「近道」できることです。なぜなら、ネイティブなプロセス監視を持つランタイムで使える一連のプリミティブがあるからです。これは、specを実装にマッピングする非常にエレガントな方法だと考えています。
まるでフルスタックWeb開発でTypeScriptリポジトリを使うのと同じで、フロントエンドとバックエンドで型を共有でき、複雑さが下がります。これは、かつてのGraphQLに少し似ています。
そしてここには人間が介在しないので、私個人がElixirを書けるかどうかは、最も適切なツールを選ぶかどうかに影響しません。これは実にクレイジーなことです。
統合層：「MCPはもう死んでいる」
司会者：
興味深いです。このパラダイムでは、言語によって振る舞いが異なるのではないかと考えています。例えば、ある言語は遅く、ある言語はバグが出やすく、時折サーバーの再起動が必要など。
Ryan Lopopole：
あるかもしれません。可観測性層はすでに成熟していると考えています。統合層なら……MCPは既に「死んでいます」。しかし全体を見ると、これは非常に興味深い層構造で、上下に行き来できます。システムで働く開発者に共通言語を提供します。
ポリシー層もクールです。CIが通るのを待つシステムを保証するために多くのコードを書く必要はなく、それは単にあなたの「組織知」です。GitHub CLIを与え、「CIは必ず通らなければならない」と一言加えれば十分です。
CLIの利点は「トークン効率が良い」こと
司会者：
では、CLIのメンテナはエージェントのために特別な最適化をする必要があると思いますか？
Ryan Lopopole：
実は必要ありません。例えばGitHub CLIは、設計時には今日のような使い方を想定していなかったでしょうが、既に非常に使いやすいです。
CLIの利点は「トークン効率が良い」ことで、さらなる最適化も容易です。例えば、BuildkiteやJenkinsのログを見ると、通常は大量の出力があります。人間の開発者のために、Dev Productivityチームはログから重要な例外を抽出し、ページの先頭に置くコードを書くことがよくあります。
CLIも同じように設計すべきです。例えば、各ファイルがフォーマットされたことをエージェントに伝える必要はなく、エージェントは「フォーマットされたかどうか」だけを気にします。これで、書き込み操作を実行するかどうかを決定できます。
同様に、PNPMの分散スクリプトを使うと、出力が非常に多くなりますが、実際はその大部分がテストログです。私たちは最終的にラッパーを書き、無関係な情報を圧縮し、失敗部分だけを残しました。
司会者：
はい、エラーストリームを別途パイプできます。
Ryan Lopopole：
はい、しかしまあ、これは少しエンジニアリングの細部に過ぎません。私も以前CLIをメンテナンスしていたので、ここには共感します。
司会者：
他に補足はありますか？
Ryan Lopopole：
このspecは長く、多くの強い仮定を持っています。しかし重要なのは、これを利用し、同時に自分に合うように改造すべきだということです。
本質的に、ソフトウェアはデプロイ環境に適応できるとき、より柔軟になります。だから、LinearやGitHubはspecに書かれていますが、必須ではありません。JiraやBitbucketに置き換えても構いません。
重要なのは、IDフォーマットやエージェントのループメカニズムなど、いくつかの核心的なものが明確に定義されていることです。これにより、完全なシステムを迅速に立ち上げ、それから徐々に進化させられます。
私たちは、これを修正不可能な静的仕様にするつもりはなく、むしろ青写真のようなもので、まず動くようにしてから、ゆっくりと最適化していくべきです。そして、これらの多くは実はプロンプトであり、非常に長いプロンプトです。本質的にエージェントは指示に従うのが得意なので、十分に明確な指示を与えれば、結果の信頼性は高まります。
私たちがSymphonyを使うのと同じで、人間にエージェントの仕事を監視させたくはありません。だから、成功基準を非常に厳格に定義し、そうすることでデプロイ成功率を高め、サポートチケットを減らします。
4つのCodexを並列実行し、システムが正しいパスを自動的に進むように設計する
司会者：
これは「使い捨て可能性」に戻ります。以前は、Codexタスクを実行するのに2時間かかり、軌道が外れるのを恐れてずっと監視していました。しかし今は、直接4つ並列に実行できます。
Ryan Lopopole：
はい、私がCodex Appで最も好きなのはこれです。直接4倍の並列実行。問題ありません、そのうちの一つは正しいはずで、たぶんもっといいものさえあるかもしれません。
考えすぎないでください。私の最初の例は、実際にはdeep researchです。発表されたばかりの頃、LLMに関する質問をしたら、それが法律問題だと誤解し、1時間かけて完全に見当違いのレポートを書きました。当時は「このものを監視しなきゃ」と思いましたが、実は違います。監視すべきではありません。システムが自動的に正しいパスを進むように設計すべきで、自分でベビーシッターをするのではありません。deep researchでひどい結果が得られれば、実はプロンプトを微調整する必要があると既に気づいていますよね？これがシステムにフィードバックする「ガードレール」であり、エージェントの実行をさらに整列させます。これらの考え方は、ここでも同じです。
神レベルのCLI：人間をループから外す
司会者：
ところで、Symphonyの顧客からのフィードバックはどうですか？
Ryan Lopopole：
私はまだ真の意味での「顧客」はいないと考えています。なぜなら、これは私たちが内部で使っているものだからです。あなたが満足すれば、あなたが顧客です。
司会者：
外部からはどう見られていますか？
Ryan Lopopole：
皆、この低コストでソフトウェアやアイデアを配布する方法に非常に興奮しています。私たちユーザーにとって、生産性はさらに5倍向上しました。これはここに「持続可能なモード」があることを示しています。人間をループから外し、同時に出力結果への信頼を築くことです。
例えば、ここで示したビデオは、私たちがコーディングエージェントにPR作成時に添付してほしいと期待する内容です。これは信頼構築の一部です。根本的に、このシステムの最も興味深い点は、エージェントをより「協調するチームメイト」のようにさせることです。私はあなたが1週間に処理した各チケットを監視しませんし、あなたがCursorやClaude Codeで行った完全な画面録画を欲しいとも思いません。私はただ、あなたがコードが信頼でき、マージ可能であることをあなたの考える適切な方法で証明し、その全プロセスを私がレビュアーとして理解できる結果に圧縮してほしいのです。
これは実は非常に自然です。そして、これを達成できます。なぜなら、Codexのようなシステムは本当に強力だからです。
司会者：
はい、FFmpegのようなものは「神レベルCLIツール」です。
Ryan Lopopole：
はい、まるでスイスアーミーナイフのようなものです。私はかつて、FFmpegの各フラグは小さなSaaSになり得るとよく言っていました。UIを被せてサービスにすれば、FFmpegを使えない人々はお金を払ってくれるでしょう。
私たちがこれらの実験を始めたとき、非常に強い「未来感」がありました。画面に次々とウィンドウがポップアップし、ファイルが自動的にデスクトップに現れ、システムがあなたのPCをコントロールし、しかも本当に生産的なことをしている。私は基本的に、PCがスリープしないように保証し、時々マウスを動かすだけの存在でした。
司会者：
多くの会社員も実際そうやって、「マウス自動移動器」を買ったりしています。
Ryan Lopopole：
その通りです。
OpenAI内部でCodex Sparkモデルをどう使っているか
司会者：
一つ質問があります。今、これらがこれほど強力で、非同期に大量のエージェントを投げて実行できるなら、Sparkモデル（軽量版Codexモデル）についてどう考えますか？例えば5.3 Sparkは、1行のコード修正や色の変更など、迅速な小修正に適しています。IDEを開きたくないが、それをやらせたい。しかし問題は、私がまだボトルネックなのでは？なぜこれらもシステムに自動的に処理させないのですか？
Ryan Lopopole：
Sparkは確かに全く異なる種類のモデルです。アーキテクチャが異なり、複雑な推論はサポートしていませんが、速度は極めて速いです。正直、私はまだ完全に使いこなせていません。最初は高推論モデルのタスクに使おうとしましたが、実際にコードを書く前に大量のコンテキストを消費してしまいました。
ちなみに、5.4のような100万トークンのコンテキストは、エージェントにとって非常に重要です。コンテキストを圧縮する前に、より長く実行でき、トークンが多ければ多いほど、効果は上がります。
Sparkについては、直感は正しいです。迅速なプロトタイピング、アイデアの探索、ドキュメントの更新に適しています。私たちにとって、フィードバックをlint（ESLintルールなど）に変換するのには非常に使いやすいです。なぜなら、成熟したインフラが既にあるからです。この種のタスクはうまくこなし、迅速にブロックを解除でき、「自己修復」的なコードメンテナンスにも適しています。
今のモデル：まだ真にゼロから製品を一発で生成できない
複雑なタスクのリファクタリングは依然として人間の介入が必要
司会者：
では、あなたたちは実際にモデルを極限までプッシュしているのですね。今のモデルには、まだ何ができないのですか？
Ryan Lopopole：
彼らはまだ「全く新しい製品アイデア」から直接、使用可能なプロトタイプ（ゼロツーワン）を一発で生成することはできません。これが、私が現在「介入」に最も時間を費やしている場所です。既存のインターフェースが全くないアイデアを、操作可能な製品に変換するのです。
もう一つの難点は「複雑なリファクタリング」です。モデルの更新ごとに進歩していますが、最も複雑なリファクタリングタスクには、依然として頻繁な介入が必要です。私は、モノリシックシステムを分解するための追加ツールを構築さえ必要です。
しかし、これらはすべて継続的に改善されると予想しています。わずか1ヶ月で、低複雑度のタスクしかできなかった段階から、「大規模＋低複雑度」のタスクを処理できる段階まで進歩しました。だから、モデルを過小評価してはいけません。モデルはより高複雑度の空間へと拡張し続けます。
だから、正しい戦略は「モデルの能力と戦う」ことではなく、「モデルを中心にシステムを設計し」、モデルがますます複雑な部分を処理するようにし、あなたは徐々により高次の問題へと退くことです。
モデルと既存のエージェント製品は、二つの異なる問題を解決する
司会者：
タスクタイプ自体が異なるように聞こえます。例えば、Codexは既存のコードベースを理解するのが得意ですが、Lovable、Bolt、Replitなどの会社は、ゼロから1へのスキャフォールドの問題——アイデアを直接製品にする——を解決しています。
Ryan Lopopole：
はい、この二種類の問題は異なります。モデルもこの点で「飛躍的」な進歩を遂げています。しかし、現在のソフトウェアエンジニアリングエージェントとはまだ異なります。
私はよく言いますが、モデルの能力は実際私と「同型」ですが、唯一の違いは、私が自分の頭の中のものをモデルが理解できるコンテキストに変換する必要があることです。そして、これらの「白紙プロジェクト」では、私自身も得意ではありません。
だから、エージェントの実行中に、私は半ばまで進んで初めて何が欠けているかに気づくことがよくあり、これが同期インタラクションが必要な理由です。しかし、より良いハーネスやスキャフォールドがあれば、私を導き、可能性空間を収束させ、例えば強い制約フレームワークやテンプレートを提供でき、これらはモデルにより多くの「非機能要件」のコンテキストを与え、結果の発散を防ぎます。
OpenAIのToB製品：Frontier
司会者：
最後にFrontierについて話しましょう。
Ryan Lopopole：
はい、しかし、ここでは青写真を詳しく展開することは恐らくできません。Frontierは、私たちが企業のAI転換を推進したいと考えるプラットフォームであり、大企業から小企業まで適用可能です。核心の目標は、企業が「高可観測、安全、制御可能、識別可能」なエージェントを簡単にデプロイできるようにすることです。
それは、企業内部のIMシステムにアクセスし、セキュリティツールを統合し、ワークフローツールに接続する必要があります。本質的に、あなたは「specを配布する」のです。ここにはいくつかのハーネスコンポーネントがあると予想され、Agent SDKが核心であり、スタートアップチームや企業開発者が「箱からすぐに使える」実行環境を持ち、シェルツール、Codexスタイルの実行環境、ファイル添付、コンテナなど、モデルの能力を十分に活用できます。
私たちの目標は、これらの能力を十分に良いものにし、同時に安全に組み合わせられるようにすることです。例えば、GPT OSSのセーフガードモデルのように、一つクールな点があります。それは「セキュリティ仕様」と対接する能力を自帯しています。セキュリティ仕様はしばしば企業がカスタマイズするものです。
私たちには、これらの企業が企業内のエージェントに制御を加え、データの外部流出を防ぐ責任があり、しかも彼ら自身の関心に基づいて制御します。例えば、社内のコードネームを識別するなどです。だから、重要なのは、プラットフォームをカスタマイズできる十分な「フック」を提供しながら、デフォルトでは可能な限り「箱からすぐに使える」ようにすることです。これが私たちが探っている空間です。
Frontierの購入者と2種類のユーザー
司会者：
はい、これは実はSnowflake、Brex、Stripeのような会社にとって切実なものです。
あなたたちのデモビデオに戻りたいのですが、あれは「大規模エージェント管理」のシナリオを非常によく示しています。例えば、ユーザーにコントロールパネルを与え、複数のエージェントを実行するとき、単一のインスタンスにドリルダウンして、具体的に何をしているかを見られます。もちろんできます。しかし、問題は、この製品のユーザーは誰ですか？CEOですか、CTOですか、それともCIOですか？
Ryan Lopopole：
私の個人的見解では、この製品の「購入者」は一種の人物ですが、「ユーザー」は二種類の人物です。第一種は、実際にこれらのエージェントを使って生産性を向上させる従業員で、彼らが接するのはエージェントが現れるインターフェース、利用可能なコネクタなどです。
そして、このようなコントロールパネルは、IT、GRC（ガバナンス／リスク／コンプライアンス）、AIイノベーションオフィス、セキュリティチームなど、企業内でエージェントを従業員の作業環境に安全にデプロイし、同時に規制要件と顧客のコンプライアンス約束に適合させる責任を負う人々のためのものです。
つまり、これは「氷山構造」に似ています。従業員が見るのは水面の上の部分で、その下にはシステム全体があります。
司会者：
はい、つまり、UIの各層はエージェントの異なる抽象レベルに対応しているわけです。
Ryan Lopopole：
その通り。そして、単一のエージェントの実行軌跡のレベルにまで掘り下げられることは、非常に重要です。セキュリティのためだけでなく、「スキル」を開発する責任者にとっても重要です。
私たちは以前、内部データエージェントを発表しましたが、Frontierの多くの能力を使い、エージェントに私たちのデータオントロジーを理解させ、データウェアハウスに何があるかを知らせました。
司会者：
セマンティック層のようなものですか？私は以前この分野に少し触れたことがありますが、正直、人間自身で統一定義するのが難しいです。例えば、「収益をどう計算するか」。「何がアクティブユーザーと見なされるか」。会社には5人のデータサイエンティストがいて、各自の定義が異なるかもしれません。さらには内部政治もあり、マーケティングは「これは私の貢献だ」と言い、営業は「これは私のものだ」と言い、合計が100%を超えることもあります。
Ryan Lopopole：
はい、まさにそうです。
司会者：
そして、スタートアップでは、すべてがARRになります（笑）。これは確かに興味深いです。
Ryan Lopopole：
はい。私たちはこれについてブログも書きました。
エージェントに業務データ、さらには企業文化を与える
司会者：
では、皆さんはそれを見てみてください。とにかく、「データをフィードバック層として」は重要です。まずこの問題を解決しなければ、製品のフィードバックメカニズムを閉ループにできません。
Ryan Lopopole：
その通り。エージェントがビジネスを理解するには、収益とは何か、ユーザーのセグメンテーションは何か、製品ラインは何かを知る必要があります。私たちが以前述べたハーネスコードベースにあるcore_beliefs.mdのように、チームは誰か、製品は何か、ターゲット顧客は誰か、パイロット顧客は誰か、今後12ヶ月のビジョンは何か——これらはすべて、ソフトウェアを構築する際の重要なコンテキストです。
司会者：
では、これらもエージェントに与えるのですか？
Ryan Lopopole：
はい。
司会者：
そして、これらは動的に変化しますよね？静的なspecではありません。
Ryan Lopopole：
はい、絶えず反復されます。
もう一つ、おそらく「脳炸裂」な点があります。私たちはエージェントに「スキル」を与え、ディープフライ（deep fried）ミーム画像の生成や、Slackのリアクション文化を学習させました。Slack + ChatGPT + Codexを通じて、エージェントに私の代わりにメッセージを送らせることができるからです。
ユーモアは実はAGIの一部です。
GPT-5.4はもうネタを使える
ユーモアはAGIの一部
司会者：
では、それは面白いですか？
Ryan Lopopole：
なかなかのものです。ユーモアは実は非常に難しい能力です。なぜなら、わずかな文字の中に大量のコンテキストを圧縮しなければならないからです。これが、5.4のようなモデルが私たちにとって大きな向上である理由です。「ネタを使う」この点で。
司会者：
なるほど、結論は：5.4は私たちをもっとネタを使えるようにする（笑）。
あなたたちは、Codexにエージェントの記録を振り返らせ、あなたたちをツッコミさせることができます。
Ryan Lopopole：
ハハ、試してみる価値があります。
Frontierが狙うのはエージェントの大規模展開
司会者：
最後の質問に戻ります。私が思うに、あなたたちがやっているこのセットは、実はすべての会社が採用すべきモデルであり、あなたたちの製品を使うかどうかにかかわらずそうです。私の最初の反応は、すべての会社にこれが必要だ、というものでした。
Ryan Lopopole：
はい。
司会者：
少し「退屈」に聞こえるかもしれませんが、セキュリティやコンプライアンスなどですが、もし本当に大規模にエージェントを管理するなら、これらは必須です。あなたたちのこのダッシュボードは、私が最初に理解したTemporalに非常に似ています。会社のすべての長時間実行されるプロセスを見られるパネルです。
Ryan Lopopole：
はい、まさにそうです。ただし、それは高度にカスタマイズされ、各会社の関心は異なります。しかし、将来、この層のサービスを専門に行う会社がたくさん出てくると考えています。
司会者：
私は今、完全にFrontierの「信者」です（笑）。最初はFrontierを見て、それからハーネスとSymphonyを見て、最後に「ああ、これがあなたたちがこの能力を提供する方法だったのか」と気づきました。
Ryan Lopopole：
はい。私たちは一連の「構築ブロック」をこれらのエージェントに組み立てさせ、これらのブロック自体も製品の一部です。例えば、エージェントの振る舞いを制御したり、モデルが暴走したときに権限を取り消したりなど、これらはすべてFrontierを通じて提供されます。
会社には多くの異なる役割があり、彼らはこのプラットフォームで自分に必要な情報を見ることができ、それによってエージェントの大規模展開を推進できます。
司会者：
これは、OpenAIが以前言及した「AGIの5段階」を思い出させます。その一つは「AI組織」です。これは基本的にその方向です。
Ryan Lopopole：
はい。例えば、私たちのチームは今、あることをやっています。Codexのエージェント実行軌跡を収集し、それを精製してチームレベルの知識ベースを形成し、コードベースにフィードバックするのです。しかし、これは必ずしもCodexに結びつける必要はなく、ChatGPTにも私たちの「ミーム文化」、製品ロジック、働き方を学習させたいと願っています。そうすれば、私がそれに尋ねるとき、完全なコンテキストを持っています。
私はFrontierがこれを実現できることに非常に興奮しています。
OpenAI内部でも葛藤：これらの能力を直接モデルに学習させるか
司会者：
モデルチームは、あなたたちがこのように使っているのを見て、どんなフィードバックをしていますか？あなたたちは大量の使用データと軌跡を持っています。
Ryan Lopopole：
確かに、核心的な緊張関係があります。私たちはハーネス（システムエンジニアリング層）を強化し続けるべきか、それともこれらの能力を直接モデルに学習させ、モデルがデフォルトでこれらのことをできるようにするべきか。
はい。私たちのこのような働き方の「成功」は、モデルが徐々により良い「センス」を持つようになることを意味します。なぜなら、私たちが方向を示すことができるからです。そして、私たちが構築したこれらのものは、エージェントのパフォーマンスを低下させません。本質的に、これらはエージェントにテストを実行させるだけであり、「テストを実行する」ことは信頼性の高いソフトウェアを書く一部です。
もし私たちがCodexに加えてROSのようなスキャフォールドを丸ごと追加し、その出力を強制的に制限するなら、このような追加のハーネスは最終的に廃棄されるかもしれません。しかし、もし私たちがこれらのガードレールをCodexのネイティブ出力の上に、つまりコード自体に直接構築できれば、摩擦はなく、モデルの継続的な進化に影響を与えず、同時にこれは良いエンジニアリングの実践でもあります。これこそが鍵です。
司会者：
私は以前、研究科学者たちと同様の問題を議論しました。例えば、強化学習におけるon-policyとoff-policyです。あなたの意味は、on-policyのハーネスを構築すべきだ、つまり、モデル自体の分布内で強化し、分布から逸脱した外部システムを作るべきではない、ということですか？
Ryan Lopopole：
その通りです。
1ヶ月に1バージョン、Codexチームは狂ったようにリリースしている
司会者：
興味深いです。まだ触れていないが、補足すべきことはありますか？
Ryan Lopopole：
私はCodexチームの継続的な「高強度の反復」の恩恵を受けられることにずっと興奮しています。彼らの核心のエンジニアリング文化は「狂ったようにリリースする」ことで、彼らは本当にそれを実践しています。5.3からSpark、そして5.4まで、ほぼ1ヶ月で完了したと感じており、この速度は非常に驚異的です。
司会者：
はい、1ヶ月前は5.3で、昨日はもう5.4です。次は毎月5.5が来るのですか？
Ryan Lopopole：
ハハ、これは私には言えませんが、予測市場の人々は興奮するかもしれません。
司会者：
しかし、興味深い点は、これも成長と同期していることです。彼らは既に200万人のユーザーがいると言っています。しかし、ある意味、あなたはもうCodex自体だけを気にするのではなく、より大きな図を気にしています。コーディングは入り口に過ぎず、真の目標は「知識作業」全体です。
Ryan Lopopole：
その通り、これこそが核心の方向です。これも私たちのチームが支援しようとしていること——セルフホストのハーネスを稼働させることです。次は、実際に「仕事をする」ことです。
OpenAIはサンフランシスコから離れ、シアトル、ロンドンへと拡大している
司会者：
他に皆さんに言いたいことはありますか？あなたはシアトルにいますよね？
Ryan Lopopole：
はい、私たちはBellevueに新しいオフィスがあり、録音の前日にオープンしたばかりです。環境は良く、ワシントン州で未来を築くことに参加できてうれしいです。
言いたいのは、Frontierに関して、企業顧客にサービスを提供するにはまだやるべきことがたくさんあり、私たちは採用中です。まだCodex Appを試したことがなければ、ダウンロードしてみてください。私たちは200万の週間アクティブユーザーを突破し、毎週25%成長しており、速度は非常に速いです。ぜひ参加してください。
司会者：
一つ観察があります。OpenAIは以前、非常に「サンフランシスコ中心」の会社でした。多くの人がサンフランシスコへの引っ越しを避けるために加入を諦めました。しかし今、ロンドンやシアトルに拡大しており、これは企業文化を変えるでしょうか？
Ryan Lopopole：
私はシアトルオフィスの最初のエンジニアの一人なので、私にとってこれは非常に自然です。これも私がずっと推進してきたことで、発展も順調です。そこでは既に安定した製品ラインが確立され、同時にゼロから1へのイノベーションプロジェクトも大量にあります。
これが実は私たちが「応用AI」を行う核心の方法です。迅速なスプリント、絶え間ない探索、モデルがどのシナリオで本当に着地できるかを見ることです。
また、ニューヨークにもオフィスがあり、エンジニアリングチームの規模も小さくありません。
司会者：
なるほど、これは基本的に私の「AI巡礼地図」です。エンジニアを募集している場所に行けばいいのですね。
Ryan Lopopole：
ニューヨークオフィスも素晴らしく、以前REIのオフィスビルでした。しかし、ニューヨークのスペースは結局限られており、シアトルのような大規模オフィスを持つのは難しいです。シアトルは少し「マッドメン」のようなスタイルで、非常に美しいです。Bellevueの新オフィスは緑を基調とし、金属の装飾があり、太平洋北西部の感じがします。
司会者：
確かに、ニューヨークの雰囲気が好きな人もいます。
Ryan Lopopole：
はい。私たちのオフィス環境チームは非常に良くやっていて、ここで働けるのは幸運です。
司会者：
はい、今日はありがとうございました。内容は非常に充実していて、あなたたちは本当に「狂ったように進めている」ですね。
Ryan Lopopole：
交流できてうれしかったです。良い金曜日を。
司会者：
良い金曜日を。
さて、記事はここで終わりです。皆様、良い週末をお過ごしください。
——好文推薦——