翻訳 | 核子可楽（Hezi Keler）
企画 | Tina
編集 | 蔡芳芳
「多くのエンジニアはツールに適応しようとするが、ごく一部の者は不満を抱きながらツールそのものを書き換える」
OpenAI Codex の技術責任者であるマイケル・ボーリン（Michael Bolin）氏は、まさに後者の典型だ。Google カレンダーから Facebook のビルドシステム「Buck」、仮想ファイルシステム「Eden」を経て、現在は OpenAI の Codex を主導する同氏のキャリアは、過去 10 年以上にわたるソフトウェアエンジニアリング基盤の進化そのものを体現している。
最近のエピソード『The Developing Dev』ポッドキャストにおいて、ホストのライアン氏がマイケル・ボーリン氏と、20 年にわたるエンジニアリング実践に渡る深い対談を行った。インタビューの中で同氏は、JavaScript エンジニアから開発ツール群の主導的開発者へと至る変遷を振り返り、そこでの判断ミスや能力の限界、そして成長の代償について率直に語った。さらに重要なのは、AI が開発の在り方を再構築しつつある現在、どの能力を堅持すべきか、何を再定義すべきかという、すべてのエンジニアが直面する問いへの回答を試みている点だ。
同氏によれば、真の差を生むのはコードを書く速度ではなく、「どのような問題を解決することを選ぶか」、そして「より良いシステムとは何かをいかに定義するか」であるという。
注目すべき主要な見解は以下の通りだ。
- 多くの工学的ブレークスルーは、「現状への不満」と迅速な実証実験から生まれる
- エンジニアの影響力は、最終的に「企業が真に懸念する課題」を解決できるかどうかに依存する
- AI プログラミング時代において、コードの 80〜90% はモデルが生成可能だが、重要な部分は依然として人間が掌握する必要がある
- コードを書くこと以上に、「正しい問いを立てる能力」の重要性が増している
- 長期的には、プログラミングエージェントの実行はローカルではなくクラウドへ移行していく
- AI は何でもできるかのように見えるが、システムのより低層部がどのように動作するかを理解する能力は、現時点では依然として重要だ
以下、InfoQ が原文の意図を損なわない範囲で整理・編集したインタビュー全文の翻訳をお届けする。
エンジニアからツール創造者へ：問題に駆動された成長の軌跡
ライアン： あなたのウェブサイトを詳しく調べてみたが、ほぼすべてのコンテンツに掘り下げる価値があることに気づいた。その中で、かつてあなたが多大な心血を注いだあるプロジェクトがあるが、現在ではすべてのリンクが切れており、関連資料が全く見当たらない。「Chickenfoot」とは一体何だったのか？
マイケル： 長い話になるが、あれは修士課程の卒業制作プロジェクトで、Firefox 向け拡張機能として JavaScript で構築された数少ない事例の一つだった。本質的には Firefox のサイドバーに埋め込まれた小型のプログラミングツールで、リアルタイムインタープリタとしてエンドユーザーが随時呼び出せるようになっており、その中核理念は「Web プログラミングの実現」にあった。
そこには「enter」や「click」といった関数が含まれており、これらの関数を呼び出す際にユーザーは文字列パラメータを渡す。例えば「click search」と入力すればクリック操作が実行されるといった具合だ。このプロジェクトの主な工数は、基盤となるヒューリスティックアルゴリズムの構築に費やされた。「enter first name」と入力すると、「first name」というキーワードを認識して最も近いテキストボックスを特定し、JavaScript を通じてそれを入力内容へと変換する仕組みだ。
今振り返ると興味深いが、当時の私たちの取り組みは、現在の AI プログラミング支援ツールの原理と非常に似通っている。異なるのは、現在では自然言語処理が実際に実現され、かつてのような JavaScript による代替案に依存しなくて済む点だ。
ライアン： 面白い。つまり、フロントエンドのインターフェースを解析し、対話型インターフェースを通じてユーザーの指示記述を対応する操作へと変換するものだったのだな。
マイケル： その通りだ。アクセシビリティラベルやトグル技術などを活用してテキストを機能に変換していた。特に Craigslist のような単純なサイトでは極めて効果的だった。実際、私の知人でこのツールを使ってタスクを自動化し、その効率性の高さを活かして実際に収益を上げていた者もいて、非常に興味深かった。
ライアン： あなたは業界入りしてすぐに Google に入社し、Google カレンダープロジェクトに情熱を注いだと聞いている。Google に入社したきっかけは何か？また、その経験からどのような思い出が残っているか？
マイケル： 私がインターネットに触れたのは 1990 年代のことだ。当時はウェブを閲覧する際、必要な情報を見つけるために無数の検索エンジンを行き来しなければならなかった。2000 年 3 月、ルームメイトに「ほら、いい感じの新しい検索エンジンが出てきたぞ」と言われたのを今でも鮮明に覚えている。当時はまだスタンフォード大学のドメイン下にあった頃の話だ。
その時、Google 検索が他より優れていると直感した。詳しく調べてみると、他社検索エンジンとのインターフェースの差は歴然としていた。Yahoo! のインターフェースはごちゃごちゃしていたが、Google は意図的にミニマリストなデザインを追求しており、原則レベルでの指向性が明確だったことは周知の事実だ。その後、多くの企業がこのスタイルを模倣し始めた。そして周囲で Google で働き始める人々が出てきた。「なるほど、彼らが採用しているのはトップクラスの才能ばかりだ」と思ったものだ。
私はぜひ彼らと共に働きたいと考えた。彼らは Web を本当に理解していた。対照的に、当時のマイクロソフトは Web を理解しておらず、IE プロジェクトの停止さえ発表していた。Web への入り口であるはずのものを、マイクロソフトは壊そうとしていた。一方の Google は明らかに Web への先見性を持ち、プロジェクトのエンジニアリング品質とその影響力の大きさから、卒業時に最も憧れる先となった。
ライアン： 当時の Google の文化はどうだっただろうか。記事で、プロダクトとインフラという 2 つの事業線の間に齟齬があったと記していたが。
マイケル： 多くの企業、特に一定規模に成長した企業には顕著な傾向がある。創設チームが最も得意とし、最も成功してきた事業分野が、長年にわたって「贔屓」され続けるのだ。
Google もまた例外ではなかった。情報検索にせよ基盤インフラにせよ、それは企業の成長を支える中核能力であり、当然ながら社内でもより高い地位を占めていた。
私が Google に惹かれた大きな理由の一つは Gmail のようなプロダクトの存在だ。これらは当時、「ユーザー体験志向」が強く、方向性も比較的オープンで想像力をかき立てるものだった。しかし社内におけるその地位は、検索のような中核事業には到底及ばなかった。
例えば私が携わっていた Google カレンダーは、主に消費者向け市場向けであり、一部企業向け販売シナリオもあったにはせよ、ビジネスの観点からは収益の中核ではなかった。ある意味では、直接収益を生み出す事業というより、「サービス支援型」のプロダクトチームとして位置づけられていた。当時は概ねそのような状況だった。
ライアン： あなたは結局 Google を去った。投稿を見る限り、Google での时光は苦楽入り交じるものだったようだが、退職を決意した要因は何か？
マイケル： Google には前後して 4 年間在籍した。率直に言って、退職を決めた決定的要因はキャリアプランだ。第一に、4 年働いて多少の蓄えができ、選択肢が広がった。しかしそれ以上に、自分にある悪癖があることに気づいたのだ。それは「自分自身にとっては重要だが、Google にとっては重要ではないかもしれないプロジェクト」に全精力を注いでしまうという習慣だ。私が担当していたカレンダープロジェクトがまさにそれだった。
その後、カレンダー配下の小機能モジュールである効率化ツール「Google Tasks」に移った。ユーザー数はカレンダーより 2 桁も少なくなったが、それでも情熱は尽きなかった。JavaScript 基盤や Closure ツールキットにも魅了された。これらのプロジェクトも素晴らしく、開発プロセスを楽しみ、自分の貢献に誇りを持っていた。Closure については本まで執筆したほどで、まさにやる気に満ちていた。しかしキャリア開発の観点からすれば、これが最善の選択だっただろうか？
「自分も高品質なエンジニアリング課題に取り組んでいるのに、なぜ評価されるのはいつも他人なのか？これほど必死になって何になるのか？」そう思った。選択は努力に勝るのかもしれない。そこで、自分が情熱を注げる事業に専念するか、会社が最も重視する方向性のどちらかに進むべきだと悟った。
ライアン： その後、あなたは再び大手ハイテク企業に戻り、当時の Facebook（現 Meta）に入社した。あなたはすでに JavaScript の専門家だったが、Meta での最初の主要プロジェクトは Android コードベース向けのビルドツール構築だったと聞いている。その舞台裏を聞かせてほしい。
マイケル： 当時、社内には極めて明確な方向性があった。「Facebook はスマホを作る」というものだ。
それ以前にも失敗尝试はあったが、今回は雰囲気が異なり、「今度こそ本気だ」と誰もが感じていた。計画としては HTC と提携し、Android をカスタマイズして新たな試みを行うというものだった。
入社したての私にとって、これは非常に興奮する話だった。それまで Java 関連の仕事もいくつか経験していたが、全体としては JavaScript 寄りで、このプロジェクトにより Java に触れる機会が増えたことはありがたかった。
当時社内には「Face Web」という方向性もあり、本質的には HTML5 と Facebook の Web 体験をそのままスマホに移すことを目指していた。しかしすぐに、その道は不可能だと判明した。同時に、モバイルが企業の成否を分ける主戦場になるとの認識が明確になっていった。
ちょうどその頃、友人から「JavaScript が好きなのはわかるが、今はもっと Java か Objective-C に注力すべきだ。さもなければプロダクトマネージャーに転向するしかないぞ」と忠告された。今振り返れば、これは非常に重要でタイムリーな助言だった。
「Objective-C は好きになれん。やはり Java がいい」。そう考え、私はプロジェクトに加わった。今回は他プロジェクトと異なり、厳格なデッドラインがあった。通常、プロジェクトは完了次第公開できるが、これは HTC 側へ成果物を提出し、3 月 1 日頃までにスマホへコードを書き込むための猶予を確保する必要があった。
全速力での開発となり、初期の Android コードベースは Google から請け負った外部ベンチャーから直接引き継いだものだった。大手企業とはそういうもので、Facebook もネイティブアプリを自社開発する気はなく、金を出して請け負わせた結果、相手が完成後に放置し、コードだけを放り投げてきた形だった。本来なら Google 側でその「ゴミ」は破棄すべきだったが、そのまま保持していた。私たちが受け取ったのはそんな代物で、そのくせイテレーション速度には高い要求が突きつけられた。
長年の Web 開発に携わった者なら、「編集してリフレッシュ」という操作フローには慣れただろう。しかし Android のビルドシステムは…あまりに粗末だった。Ant などのビルドツールはモジュール化などされておらず、無理やり 4〜5 のモジュールに分割するしかなかった。
開発のたびに苦痛を味わった。「このビルドシステムを組み直さねば」と直感した。Java でもっとまともな仕事はできるはずだ。イテレーションビルドでこれほど遅延するはずがない。Facebook にはハッカソンの文化があるため、私はハッカソンを主宰し、Google のビルドシステムスタイルを模して、すっきりと新たなビルドシステムを構築することにした。
実は当時、社内には「FB Build」というビルドシステムも存在した。これもまた Google のビルドシステムの「模倣版」で、Python で書かれ C 言語のみをサポートしていた。私は「これを直すか、さもなくば諦めて辞めるかだ」と思った。旧プロジェクトの修正ほど面倒なことはない。
ライアン： もし直せなかったら、本当に辞めていただろうか？
マイケル： 少なくともプロジェクト変更を申請し、毎日気持ちよく出社できる方法を見出しただろう。私はコードを書き、物事を成し遂げ、自分の能力を最大限に発揮するために出社している。
興味深いことに、今振り返れば周囲の人々には感心させられる。ほぼ全員が「それはひどい考えだ」と言った。一人を除いては、誰もこのプロジェクトに期待していなかった。
私はシニア Android エンジニアとして、誰にも止められはしなかった。反対意見は表明されるが、「ダメだ」とは直接言われない。その点は Google 時代とは異なっていた。Google であれば、多くの事案は明確に却下されていただろう。
そこで私はその方向で進め続けた。するとすぐに、明らかに優れたバージョンが完成した。パフォーマンスは約 2 倍に向上した。結果が出れば人々の態度も変わる。「なるほど、この方向性のほうが優れている。ではこれでいこう」と多くの者が気づき始めた。
ライアン： 大企業には「山積する不利益要素」に手を付けたがらないという慣性がある。他の多くのエンジニアも同様の問題に気づいていながら、「何とかなる」と考え、新規プロジェクトを立ち上げるのを避ける傾向がある。しかも Google 側には競合製品もあり、勝てない可能性すらある。なぜ、自らのプロジェクトが競合を打ち破り、市場の優先選択肢になると確信できたのか？
マイケル： いくつか理由がある。まず前述の通り、私は他の Java プロジェクトも手掛けてきた。そのため、本来のビルドツールがこれほど遅いはずがないと感じた。あるいは、ソフトウェアエンジニアの経験則からして、この基盤実装がこれほど非効率であるはずがないと思えた。実際、反対意見の多くは硬直的な論理に基づいていた。「標準案から逸脱すれば、標準サポートを失う」「もし来週標準の性能が 100 倍向上し、新方式がそれを受け継げなかったらどうする？」といったものだ。
よくよく考えれば馬鹿げている。Facebook のエンジニアたち自身、独自の PHP 仮想マシンや言語を開発し、イノベーションを受け入れてきたではないか。なぜ今回に限って例外なのか？当時、モバイルプロジェクト全体が手探り状態で、私は不安と過酷な時間的プレッシャーにさらされていた。
上層部はこのプロジェクトを科学実験のように扱おうとしていたが、私たちには厳格なデッドラインがあった。これで本当に時間を最大限活用できているのか？幸い最終的には成功した。また当時、私はあえてプロジェクトのインフラ的性格を薄め、「Android 向けビルドシステムを作る」ことだけを強調し、事業拡大の野心を露呈させないよう細心の注意を払った。
他者のプロジェクトの縄張りを侵すつもりはなかった。摩擦を生むだけだからだ。設計段階から他チームも利用可能にすることを見据え、決して強要はしなかった。すると約 1 年後、iOS チームから「我々のビルドシステムはひどい。Buck で共同開発しないか？」と打診があった。私は即座に「もちろん、喜んで」と答えた。
ライアン： 興味深い点だ。入社当初のあなたには信頼性がなかった。新人なら誰しも通る道だ。自らのプロジェクトを推進するには、より多くの支援を勝ち取る必要がある。誰もが「やめるべきだ」と言う中で、いかにして彼らを説得し、これが正しい方向だと信じ込ませたのか？
マイケル： 実は巧みな手を使った。ジョン・パーロウという同僚がいて、彼もシニア Android エンジニアで Google 出身者だった。彼が「その通りだ。誰も反対しないうちに動くべきだ。成功すれば私が支援する」と言ってくれた。このような初期の支援者と優秀なプログラマーがいたおかげで、開発サイクルは加速した。
彼は初期に肯定を示してくれた数少ない人物の一人で、大いに助かった。しかし認めなければならない過ちも犯した。信頼性の欠如について言えば、Google から転職した当初、ここにはベル研究所の精鋭、純粋なトップ人材が集まっていると期待していた。しかし Facebook に来て気づいたのは、「こいつら大卒者じゃないか。何を知っているというのか？」ということだ。
しかし失敗を重ねるにつれ、彼らへの敬意が芽生えてきた。私が Google 流のやり方を話すと、彼らは「うちはそんなのどうでもいい」と言い放つ。そして多くの場合、彼らのほうが正しかった。ある場所で有効な方法が、別の場所でも通用するとは限らないのだ。
ライアン： 最後に一つ。あなたが開発したツールの性能は、同種ソリューションの数倍を叩き出した。この技術的直感はいかにして培われたのか？いかなる重要な設計により、これほどの高効率を実現できたのか？
マイケル： 最も重要だったのは、Google のツール実装ロジックを最初から最後まで徹底的に整理し尽くした点だ。「一体何をしているのか？問題点はどこか？」を突き詰めた。
すぐに大きな問題点が見つかった。変更があるたびに、最初から全てを再構築してしまう点だ。これが遅さの根本原因で、特に増分ビルドのシナリオでは性能が極めて悪かった。
そこでさらに低層部を分解して検討した。「どの要素が何に依存しているか？どのステップが重複不要か？」と。Android のリソース処理のように複雑な部分もあり、ロジックも入り組んでいた。そのため初期システムは「単純かつ乱暴」な戦略、つまり変更があれば全てクリアしてやり直すという方針をとっていた。
しかし深く潜り込むと、最適化可能だとわかった。「ある入力が変化していなければ、対応するステップの結果はキャッシュでき、再実行は不要だ」。このキャッシュ機構を導入しただけで、全体速度は劇的に向上した。
もう一つの問題はモジュール性だ。当時は 4 つのモジュールしかサポートしておらず、新規モジュールを追加するには約 200 行の XML 形式 ANT ビルドスクリプトが必要で、その設定を真に理解している者はいなかった。その結果、誰もモジュール分割を行わなかった。分割すれば、その複雑な設定群の保守責任を負わされるからだ。
Buck が成し遂げた重要な点は、「モジュール追加」を極めてシンプルにしたことだ。これにより、人々はモジュール分割に前向きになり、モジュール数は増加した。モジュールが増えれば、ビルドはより細粒度で増分実行可能となり、全体効率がさらに向上した。
本質的にこれは、単なる技術最適化ではなく、思考様式の変革だった。
ライアン： つまり、重複労働の削減だな。
マイケル： その通りだ。
「適切な問題を選ぶ」：IDE と仮想ファイルシステムのリファクタリング
ライアン： Android ビルドの問題を解決した後、あなたは社内の他分野へと軸足を移した。IDE 関連の業務に深く関わるようになったが、当時 IDE 領域でどのような問題を目にし、深掘りする気になったのか？
マイケル： Buck 完成後、短期間 iOS Messenger の開発に携わった。「Android はやったから、別方面も試そう」と考えたが、正直 iOS 開発は好きになれなかったし、今も好きではない。
多くの人が知らないが、Objective-C には初期に ARC（自動参照カウント）という仕組みがあった。現在はコンパイラが自動処理するが、当時は開発者が手動で参照カウントを管理する必要があった。オブジェクト生成や参照追加のたびにコードを書く必要があったのだ。現在では目にする機会もないが、買収で引き継いだ iOS Messenger のコードは非常に古く、この方式で書かれており、保守は苦痛を極めた。
現在なら Codex などのツールで整理できるが、当時は自力で修正するしかなかった。加えて Xcode 自体の使用感も肌に合わなかった。ヘッダーファイルと実装ファイルの分離など、好まない設計が多かった。
より巨視的に見れば、Android にせよ iOS にせよ、Facebook のアプリ規模は常に最大級だった。全機能を 1 つのアプリに詰め込んで統一リリースしていた。これは Google の戦略とは異なる。Google は Drive や Sheets など複数アプリに分割し、プラットフォームを自社掌握しているため、システムにアプリ群をプリインストールできた。
この差異により、Facebook は他社より遥かに早くモバイル開発ツールの規模の限界に直面することになった。
開発者にとっては苦痛だが、開発ツールの観点からは興味深かった。他社が未だ遭遇していない問題、しかも「研究プロジェクト」ではなく業務に直結する問題を解決せざるを得なかったからだ。Xcode も同様で、「この規模では Xcode はもはや支えきれない」と Apple にフィードバックしたところ、「それならプロジェクト規模を小さく分割すべきだ」との返答だった。こうなれば、独自ツール開発にも一定の合理性が生まれる。
当時の私の思考は単純だった。「IDE とは本質的に何か？コンパイラ（Clang など）や言語サービスとのやり取りに過ぎない。なら、その上に使いやすい「殻」を被せればよい」。
当時、社はバージョン管理を Git から Mercurial へ移行しつつあり、主要 IDE がこれらのカスタムニーズをネイティブサポートする可能性は低いと気づいた。さらに構築システムには Buck を採用しており、これらは高度にカスタマイズされた社内ツールだ。Xcode がこうした「Facebook 特有」のワークフローを適切にサポートできるはずもなかった。全体として、私たちに適した開発体験の構築に注力することは理にかなっていた。
対照的に Android 側には同様の動機がなかった。IntelliJ が十分に優れており、大規模開発を支える使用方法を既に見出していたからだ。しかし iOS に関しては、当時の Xcode は明らかに使いにくかった。
ライアン： つまり Xcode が要件を満たさなかっただけでなく、社内には別チームが担当するもう一つの IDE、Web IDE が存在していたよな？
マイケル： ああ、Web IDE だ（笑）。方向性そのものを笑っているわけではない。問題は、それが放棄された Google のオープンソースプロジェクトを基盤としており、かつ GWT（Google Web Toolkit）で書かれていた点だ。Java でコードを書き、自動生成された JavaScript に変換する方式だ。
当初はその基盤上で作業を試み、「信用」を築こうとさえし、ビルド速度の最適化などを手伝ったこともある。
しかし再びお馴染みの判断基準に戻った。「イテレーション速度」と「技術スタック」を見るのだ。すると、このプロジェクトが既に廃棄されたオープンソースプロジェクトを基盤としており、GWT などという技術を使っていることがわかった。一方、私たちの会社は React の発祥の地だ。
そこで疑問が湧く。「なぜ、私たちが最も得意とし、最も信頼する技術スタックの上に開発ツールを構築してはいけないのか？」
私の第一感は「その道は誤りだ」だった。そこで Buck の時と同様、新規プロジェクトを立ち上げた。戦略は同じく、正面衝突を避け、「全てを乗っ取る」ようなことはしない。「ここに新しいエディタを作るが、まずは iOS シナリオに特化しよう」というスタンスだ。
ライアン： 摩擦を避ける意図があったわけだ。しかし当時、その Web IDE には多くのユーザーがいただろう？
マイケル： その通り。約 1000 人のエンジニアが利用していた。
ライアン： しかし最終的に会社はあなたのルート（後の Nucleide）を選んだ。ユーザーがほぼ皆無だったのに、なぜ選ばれたのか？
マイケル： 主に 2 つの理由がある。
第一に技術ルートだ。私が強調したのは、私たちが作るのは「Web IDE」ではなく「デスクトップ IDE」である点だ。Xcode を代替したいなら、開発者はシミュレータへの直接接続、スマホを挿してのデバッグ、ローカル環境の直接操作を望むはずだ。理論上 Web でも可能だが、コストと複雑さが段違いになる。
第二に「歴史的信用」だ。Buck で成功を収めたため、「前回も成し遂げたのだから、今回も試してみるか」という信頼があった。
ライアン： その経験と他の実績が評価され、E8（いわゆるプリンシパルエンジニアに相当）へ昇進したと聞く。その時の気持ちは？
マイケル： 興奮したのはもちろんだが、それ以上に「整合性」を感じた。Google 時代、私は技術面だけでなく、自分の行う業務と会社が重視する方向性の間にズレがあると感じることが多かった。
Facebook での今回の昇進は、単なる技術的成長の確認に留まらなかった。「いかなる業務が重要で、かつ会社の方向性に合致しているか」を理解できた証でもあった。この理解は技術力と同じか、あるいはそれ以上に重要だ。
ライアン： Nucleide も Buck もオープンソース化されたが、その狙いは？
マイケル： その通りだ。特に Buck のオープンソース化は象徴的だった。Nucleide は外部ではそれほど普及しなかったが。
企業はオープンソースから多大な恩恵を受けている。「これが我々の核心的な堀（競争優位性）でなければ、共有したほうがよい」という発想が働く。私のキャリアで手掛けた Codex なども同様だ。直接ツールを使わなくとも、実装方法を公開し参考にしてもらうこと自体に価値がある。
理想を言えば、外部からのコントリビュート（PR やバグ修正など）も得られる。Uber や Airbnb も後に Buck を採用した。
ある意味自然な流れだ。Facebook は最大規模のアプリの一つであり、多くの問題を最初に経験する。そして次の波の企業が同様の問題に直面した際、私たちがどう解決したかを見に来る。
興味深い点として、Google 内部では Blaze、外部向けには Bazel を使っている。「Buck をオープンソース化すれば、彼らにもっと公開させる圧力になるか？」と考えたこともあった。結果として彼らも一部公開したが、完全に我々のおかげとは限らないにせよ、多少の推進力にはなっただろう。
もう一つの現実的要因は採用だ。オープンソースは「私たちが何をし、何が得意か」を外部に示す。この分野で最前線を行きたい人材にとって、ここが来るべき場所だと示せる。
ライアン： オープンソース化の決定はボトムアップだったのか？エンジニアからの提案か、それとも経営陣が価値を認めての推進か？内部方針文書などはあったのか？
マイケル： そういう文書はなかったと思うが、両方のケースがあっただろう。React や PyTorch のような成功事例は企業に巨大な価値をもたらした。一方、長期プロジェクトは経済状況が良い時期は問題ないが、マクロ経済環境が悪化すると、経営陣が「エンジニアがオープンソースに注ぎ込みすぎだ」と不満を漏らすこともある。
全体としては、大半のオープンソースプロジェクトはボトムアップで推進され、さほど抵抗には遭わない。技術共有やブログ執筆もでき、これらは長期的価値があり、採用にも寄与し、想定より寿命が長い。
ライアン： E8 に昇進したのだから、期待値も上がっただろう。E8 クラスの難題に取り組む時が来たのか？昇進後、あなたは何をした？
マイケル： ハハ、あの頃は天狗になっていたな。当時の私は Web の読み込み速度問題の解決に挑もうとした。確かに巨大な課題で、当時の facebook.com の読み込みは芳しくなく、アーキテクチャも陳腐化していた。しかし問題が大きすぎる上、私に経験が不足していた。Facebook の Web 担当チームメンバーの多くはこの分野に長年従事していたが、私は主にモバイルと開発ツールが専門で、この分野には疎かった。
当時、同僚と V8 エンジンをソースコードからコンパイルし、JS 生成メカニズムを V8 に適合優化できるか試したが、やみくもに各種手法を試すもことごとく失敗した。
今振り返れば、人間には向き不向きがある。私はゼロから大量のコードを書くプロジェクトは得意だが、当時の課題はデータ分析や他チームとの調整が主で、これは私の得意分野ではなかった。
ライアン： キャリアのこの段階を「英雄の旅」と表現していたが、これは何を指すのか？
マイケル： 恥ずかしながら、これは一部のエンジニアが抱く「誰かこの技術的難題を解決してくれないか」という幻想を指す。この期待が自己膨張を招いたのだ。多くのエンジニアが「このエンジニアリングの難題はあまりに長く放置されている。なぜ誰も手をつけないのか？」と考える。私の考えは単純で、「JS なら自分が一番知っている」だった。そこで飛び込んだ。
しかし成し遂げられず、完全に失敗した。振り返り、重要な教訓を再認識した。「確かに多くの問題は解決できるが、心から楽しめ、かつ卓越して成し遂げられることは少数だ」。他の分野も徐々に拡大はするが、結果として真に情熱を注げることに集中すべきだと悟った。万事において最高を目指せるわけではない。
誰もが这个道理を理解し、自らの限界を素直に受け入れるべきだ。
ライアン： では、真に E8 クラスの問題をどう見つけたのか？その後は？
マイケル： ある種の運の要素もあった。小規模なエンジニア会議を開き、将来のボトルネックになりうる点をブレインストーミングした際、私は「コードベースの継続的膨張がいずれ拡張性問題を引き起こす」と指摘した。当時の部門責任者で、後に私の上司となるブライアン・オサリバン氏（Brian O'Sullivan）がこれに注目してくれた。
氏はこの問題を事前に解決するため、仮想ファイルシステムの開発チームを立ち上げることを決断した。そこで私、アダム・シンプキンス（Adam Simpkins）、ウェス・ファーロング（Wes Furlong）の 3 名がチームに加わった。2 名とも超一流のエンジニアで、長らく「自分がプロジェクトで一番の役立たずではないか」と感じるほどだった。
ライアン： 仮想ファイルシステムに言及したが、Meta のような大企業にとって、これを自社開発する利点は何か？
マイケル： 以前はモノレポ（全コードを 1 つのリポジトリで管理）を採用していた。しかし実際に必要とするのはその一部に過ぎず、特定ファイルを随時参照するだけだ。そこで中核的発想は、仮想ファイルシステム向けにツールを設計することだった。リポジトリのクローンやコミットバージョン切り替え時、システムはリポジトリ内の全ファイルをディスクに書き込む必要がなくなる。従来型ファイルシステムのこのデフォルト動作を排除することで、リポジトリ規模に応じたファイル数の指数関数的増加を回避できる。
この作業には 2 つの重要局面がある。第一に仮想ファイルシステムの構築だ。ユーザーがあるコミット時点でファイル内容を要求すると、システムは動的に対応ファイルを生成し、完全なファイルレイアウト効果を提示する。OS がファイル内容を要求する際も、即座にデータを呼び出し、ユーザーが実際に目にする完全なファイル構造として提示する。
もう一つは、私の得意分野である「ツールチェーン全体で全ファイル読み込みを頻繁に行うツールの予測」だ。例えば grep などのツールは全内容を直接読み込む。元々のツールをそのまま使い全ファイルを表示させていては、新しい仮想ファイルシステムの意味がなくなるため、開発フローやツール設計を仮想ファイルシステム中心にどう調整するかが問われる。
ライアン： 巨視的には、巨大なファイルシステムの遅延読み込み（Lazy Loading）ということか。効率が高く、初期段階で全内容を処理する必要もない。
マイケル： その通りだ。
ライアン： 先ほど、この基本フレームワークに全機能を統合するのが得意だと言っていたが？
マイケル： その通りだ。実はハンソン・ワン（Hanson Wang。現在 Codex チームのメンバー）と協力していた際、IDE やエディタで超高速ファイル検索を実現する従来案の多くが、まずファイルシステム全体を総なめにしてファイルを検索することに気づいた。
「これは大問題だ」と直感した。そこで「いかにファイルシステム本来の利点を損なわずファイル検索を実現し、現状を打破する新方案を生み出すか」を模索した。最終的に「Miles（my files の略）」というファイルシステムを開発した。
これは cron ジョブによりメインブランチの全新規コミットをインデックス化し、ファイルの追加・削除を追跡する（コンテンツではなくファイル名のみをインデックス。それだけで十分だ）。ハンソンはインデックス維持の巧妙な案を提案し、ファイルの曖昧マッチング機能を実現した。つまり新システムは部分文字列マッチだけでなく、ファイル名がキャメルケースの場合でも大文字のみを入力したり、スペルミスがあっても正確に識別できる。
これまでにチェックアウトされた全ファイルを記録する極めて興味深い表現方式を考案し、いくつかのフラグを付与して「あるコミット実行時、そのファイルは存在したか？」を記録するようにした。システムへクエリを送る際、現在のコミットバージョンや、ローカルでのファイル追加・削除の有無などを伝えると、対応データが返ってくる。
当時、100 万ファイルを超えるクエリ処理で、応答時間は 10〜20 ミリ秒程度だった。このフレームワークは Xcode や MDS コードのデフォルトレスポンスより遥かに高速で、性能遅延の問題を実質的に解決した。
その圧倒的実行速度により、Miles は内部サービスとして開放され、多様なシナリオで広く利用されるようになった。私が去る頃には、Miles サービスは世界中で少なくとも 30 台のサーバー上で稼働し、ファイル検索を超えた多様なニーズを大規模デプロイで満たしていた。
ライアン： 実装詳細を多く語ってくれたが（多くの職場では LeetCode クラス問題は扱わないが）、入出力構造の実装方法が今一つ理解できない。try 節などを使っているのか？
マイケル： try は確かに強力だ。我々の方式では 2 つの並列配列を使用した。一つはファイル内容用、もう一つは恐らくインデックスを指す整数用だったと記憶している（定かでない）。さらに 64 ビットのマスクを設定し、小文字 26 文字、大文字 26 文字、数字 10 桁、ハイフンなどを含めた。検索ファイル内にその文字が現れれば、対応する文字ビットを立てる。
これにより、無効な項目を大量に除外する高速スキャンと、高度な並列設計の両方を実現した。全配列を並列レイアウトとし、キャッシュ効率の観点から、CPU がメモリを線形に読み取る際に極めて優れた性能を発揮する。この構造は配列のパーティション並列処理に本来的に適している。
ライアン： Eden や Miles プロジェクトへの関与がさらなる昇進につながったと聞くが、昇進前には個人的影響力向上や意見の対立処理に関する経験を蓄積していたようだな？
マイケル： その通りだ。これも E8 クラスの管理職として直面した課題だった。それまでコード作成が主だったが、同レベルあるいは上位の同僚の多くは既にコードを書いていない。彼らは専ら影響力向上や他チームとの連携（プロジェクト文書作成や関係者間の調整など）に注力している。
つまり E8 として期待される影響力レベルに達するには、コード執筆だけでは不十分だ。他者に影響を及ぼす時間を割く必要があり、それは私自身のためでもあり、上司を満足させるためでもあった。
もちろん時には自説に固執しすぎ、少なくとも当時の私は態度が強硬になりすぎ、大損を被った。その時期、昇進が遅延し、やり方の調整を促された。
背景として、マイクロソフトによる GitHub 買収後、私は非常に焦慮していた。「New Clyde」プロジェクトは GitHub エコシステムに大きく依存していた。「これは終わりだ。VS Code がその独立した地位を喰らうに違いない」と考え、現実にその通りになった。プロジェクトが重大なリスクに陥っていると感じ、私は皆に方向転換を強要したが、チームメンバーの多くは現状の仕事に満足しており、突然の変更に動揺したくなかった。
後に上司に厳しく叱責され、指導を受け、この種の状況をより適切に処理する方法を学ぶことになった。
ライアン： その中で最も重要な教訓は何か？
マイケル： 現在では、どの状況が自身の感情反応（特定の技術的決定への興奮など）を誘発するかがより明確だ。そのような状況に陥った際、すぐに「冷静になれ、衝動するな」と自分に言い聞かせる。あるいは、正常な対話ができない、あるいは情緒が安定していないと自覚した際は、エンジニアの席に直接乗り込んで「俺に考えがあるんだ、こうだ…」と叫ぶのではなく、相手の上司とコミュニケーションを取るよう心がけている。
多くの場合、「この件について少し興奮気味で、伝え方がまずかったかもしれない。どう進めるのが適切か一緒に考えてくれないか？」と切り出すほうが、遥かに効果的だ。
ライアン： 興味深いのは、VS Code の台頭と New Clyde 基盤の陳腐化を予見しながら、判断を巡る主張が原因で昇進が遅れた点だ。事後的には正しかったことが証明され、正当な主張を貫いたにもかかわらず「冷静になれ」と言われたわけだが、その時の気持ちは？
マイケル： 約 1 年後、関係者とこの件について話し合い、一種の振り返りを行った。以前はかなり気まずい状況だったが、結果としてはうまく解決できた。
ライアン： 重要なのは立場そのものではなく、その処理の仕方だったわけだ。
マイケル： その通りだ。
AI が開発様式を再構築：Codex がもたらす真の変化
ライアン： Meta では概ね楽しく働いていたようだが、最終的に去った。何が OpenAI への移籍を促したのか？
マイケル： いくつか要因がある。最初に OpenAI の面接を受けたのは 2023 年末で、当時は Meta で大規模モデルベースの開発者ツールプロジェクトを担当し、独自ライセンス版の Metamate（GitHub Copilot の軽量版）をリリースし、Code Compose といったプロジェクトで論文発表や共有も行っていた。
しかし現実として、「なぜ GPT-4 を使わないのか？」というフィードバックを頻繁に受けた。Llama 2 を使っていると説明するも、両者の差は明白だった。私はモデル研究の専門家ではなく、これらの能力をプロダクトや体験として形にしたいと考えていた。であれば、最良のモデルがある場所に行くべきだと自然に思った。
2 点目は、OpenAI に「かつて Google が持っていたトップ人材への重視」を感じた点だ。彼らの選択が間違うはずがない。事実その通りで、OpenAI では Meta のレベル 8 や 9 に相当する専門家らを含む资深なチームと共に仕事ができ、自らの価値を存分に発揮できた。
3 点目は、このタイミングと OpenAI そのものの特殊性だ。多くの人に話しているが、OpenAI への参加は「2000 年の Google への参加」に似ている。1998 年ではなく 2000 年だ。この時期、企業は足場を固め、プロダクトマーケットフィットも見え始め、個人にとって極めて魅力的な段階にある。
もう一つ個人的な理由がある。Facebook を選んだ際、その巨大な消費者市場に注目した。私は消費者向けプロダクトを専門とし、カレンダーツールも広くユーザーに歓迎された。しかし Facebook に来てみれば消費者事業に触れる機会は全くなく、後に行っていた開発者ツールも社内の約 2 万人のエンジニア向けのものだった。
OpenAI へ行きたいと思ったのは、再び消費者領域、少なくとも膨大なユーザーベースを持つ機会を掴むためだ。現在担当する Codex プロジェクトの週間アクティブユーザーは 100 万を突破している（正確な数字は覚えていないが、成長曲線は極めて急勾配だ）。このサービス規模は、Meta 内部の 2〜4 万人の開発者の影響範囲を遥かに凌駕している。
ライアン： その通りだ。業界の開発ツールでも概ねその規模までが限界だろう。
マイケル： ああ。
ライアン： 私の見立てでは、Meta はエンジニアリング駆動の企業で、エンジニアが中核であり、多くのことがボトムアップで推進される。一方、多くの AI 研究所は研究駆動型で、研究が最優先される。モデル自体が重要だからだ。研究者ではなくエンジニアであるあなたは、研究主導型文化とエンジニアリング主導型文化の差異をどう見るか？
マイケル： これは適応を要する変化だ。この 2 つの文化を円滑に行き来できると主張する者がいれば、それは嘘だろう。ただし確実な点として、FAANG などの大企業で働いた経験のある者には、自らの影響力育成に注視するという良い習慣がある。これは極めて重要で、私も心から追求している。Codex や Harness プロジェクトでの作業は有意義で尊敬に値する成果だが、モデル自体が優れていなければ、Harness 側でいかに最適化を重ねても意味は限定的だ。
だからこそ OpenAI に来て心地よい。研究チームと緊密に連携し、席も近く、多くのことを共に推進している。これが Meta を去った重要な理由の一つだ。モデルを作る同僚と共にプロダクトを創り、新たな技術のフロンティアを探求したかった。
Meta でも類似の模式は実現可能だっただろうが、実際の効果は比較するべくもなかった。
ライアン： 加入当初から Codex プロジェクトの立ち上げに関わったと聞く。Codex CLI 公開時の市場の反応は必ずしも期待通りではなかったが、その後徐々に軌道に乗った経緯を共有してほしい。
マイケル： もちろんだ。波乱万丈の旅だった。2025 年 4 月、Codex CLI をリリースした。宣伝ライブ配信のラストでサプライズデモを行い、当時の Core3Pro プロジェクトをオープンソース化したところ、多くの者が積極的に試用した。新しいプログラミングアシスタントへの期待は高く、出来も悪くなかったが、リリース自体はやや慌ただしかった。
総じてプロジェクトの注目集めには有効だった。オープンソース化後、大量の PR を受け取った。1〜2 週間で 1 万〜2 万スターを獲得した記憶がある。興味深い経験で、多くのユーザーから心からの支持も得た。しかし問題として、当時のチームにはプロジェクトを推進する総合力がまだ欠けていた。企業として複数の業務を並行推進する必要があったからだ。
その 1 ヶ月後、7 名のエンジニアと数名の研究者（正確な人数は記憶していない）が Codex の Web バージョンをリリースした。ユーザーがコンテナ内で直接 Codex を使用でき、スマホから新規プロジェクトを起動さえできる。非常にクールだった。投入人員はより充足し、このプロジェクトの長期的ビジョンに確信を抱いた。しかし結果として、これは「ユーザーの先を行きすぎていた」。ユーザー側の準備が整っていなかったのだ。
対照的に、当時はローカルプログラミングエージェントへの志向が強かった。Web バージョンは一時的な成長は得たものの、定着度は期待以下だった。
夏季の間も 2 つのプロダクトラインを推進し続けた。真夏になっても、ローカルエージェントの方がプロダクトマーケットフィットは高かった。しかし個人的には、ローカル案は当面のしのぎに過ぎないと常々考えていた。エージェントの稼働にはより多くのデバイスが必要で、ノート PC だけで支えられるものではないからだ。
そこで夏に大規模な調整を行った。プログラミングチームを拡充し、より多くの開発者を導入した。GPT-5 のリリースが近づき、市場の見通しも極めて良好だった。個人的にも興奮を覚えた。CLI インターフェースの他にも数度のプロトタイプテストを行っており、今回は人員も十分に揃った。VS Code 拡張の開発も同時に開始した。ターミナルは多くのシナリオで有用だが、対話面では依然として多くの限界があると考えていたからだ。ターミナルでの美しい UI 構築には多くの妥協を伴うが、IDE 内であればより自然で完全な実装が可能だ。
8 月は爆発的な月だった。GPT-5 が登場し、我々も新しいターミナルインターフェースをリリースした。同時に GPT オープンソースモデルも発表され、TUI 上でもこれをサポートした。オープンウェイトモデルとオープントレーニングフレームワークの設計は驚異的だった。同月下旬には VS Code 拡張をリリースし、ここから狂信的なイテレーションの新段階に入った。
これら諸要素の交わりが、垂直的成長の転換点を乗り越える原動力となった。興奮すべき旅で、関連データもコードリポジトリで確認できる。参加人数やコミット数など、あらゆる通常指標がこの変化を直感的に示している。振り返れば、実に素晴らしい旅だった。
ライアン： プログラミングエージェントのローカル版とクラウド版の 2 形態に言及し、長期的には希望がローカルではなくクラウドにあると確信しているようだが、なぜそう判断するのか？
マイケル： 現在、人々が「手放せない」と感じる使用シナリオは概ねこうだ。例えば、新しい GitHub イシューや Linear タスクが来るたびに、自動的にエージェントをトリガーして処理させるといったものだ。コスト問題や乱用の懸念はあるにせよ、企業内部のプライベートリポジトリであれば、これは極めて自然な用法だ。
この場合、エージェントはローカルで対話するだけのツールというより、自動化パイプラインの一部となる。つまり、これらのタスクは全てノート PC 上で実行されるわけではない。
この観点からすれば、個人開発者としてローカルでエージェントと対話する時間は多いかもしれないが、「エージェントが実際に消費する計算量」で見れば、大部分はクラウドで発生すると考える。初期のデプロイはやや手がかかるかもしれないが、一度構築してしまえば体験は極めて良好だ。
ライアン： わかった。ローカル形態が消滅するわけではなく、業界全体としてエージェントの消費する計算リソースが主にクラウドへ移行するという意味だな。
マイケル： その通りだ。Freeze Code 拡張が初めてリリースされた際、核機能の一つは、ユーザーが対話する際、ボタン一つで対話内容をクラウドへ転送できる点だった（設定済みであることが前提だ）。将来的には、ローカルで開始したことをクラウドに投げ、完了後に受け取るといったシナリオがさらに増えるだろう。
ライアン： 今年に入り、Codex の使用量は 5 倍に増加し、ユーザー規模は 100 万を超えた。新版 Codex を使い始めてから、あなた自身の AI ワークフローに大きな変化はあったか？
マイケル： 確かに変化した。現在、Codex を使う頻度は想像を遥かに超えている。これまでは VS Code 拡張に強く依存し、サイドバーに全コードを表示させていた。「これら要素を統合すべきだ」と感じていた。コード内容自体に関心があるからだ。もっとも、一度きりのプロトタイプ実験プロジェクトであれば、コードを読むこともあまりないが。
この選択の自由は素晴らしく、興奮に値する。しかし Codex プロジェクト本体のコードについては、依然として私が最終確認を行う必要がある。これは極めて重要だ。なぜならこのプロジェクトは多くの人に影響するからだ。次第に「どの変更をモデルに任せられ、どこを監視（あるいは「見張りながら」）する必要があるか」という判断が形成されてきた。現在のアプローチは、最初に要件をより完璧に記述し、モデルに実行させるというものだ。
同時に、ローカルでは Codex リポジトリのコピーを 4〜5 個開き、Codex App と連携してマルチタスク処理を行っている。この方式は私にとって効率向上に著しく寄与している。基本的に 1 つのウィンドウに留まったまま、複数のタスクを同時進行できるからだ。ある意味「ゲーム」をしている感覚に近い。現在のスループットは？いくつのボールを空中に投げたままキャッチできているか？と無意識に考えてしまう。
もちろん、コンテキストスイッチが頻繁な際は少し混乱することもあるが、アウトプットの向上は明らかに実感できる。時には手書きでコードを書くことに「罪悪感」を覚えることさえある。「最初にもっと明確に問題記述をモデルに渡せば、もっと速かったのに」と思ってしまうからだ。
「たった 3 行の修正をするだけ」のつもりが 30 分経っても終わらない、といった経験は誰にでもあるだろうが、現在では多くの場合、これを回避可能だ。
ライアン： 現在、あなたが書くコードのうち、自分で書いている割合とモデルが生成している割合はどの程度か？
マイケル： さて、現在ではコードの 80%〜90% はモデル生成だろう。冗談ではない。特にデバッグテストや継続的インテグレーション（CI）などの作業で顕著だ。私はよく大規模モデルにプリントデバッグ用コードなどを生成させる。本当に素晴らしく、膨大な人的リソースを解放してくれる。
ライアン： では、どの問題が大規模言語モデルに適し、どれが適さないかについて議論しよう。どのタスクを自ら書くべきか、どう判断するのか？つまり、その 10〜20% と、残りの 80〜90% は何か？
マイケル： 良い質問だ。座ってプログラミングする際、毎回「これを自ら書く必要があるか？」と自問する。答えはほぼ「No」だ。
一つは基盤部分の仕事で、Codex の harness レイヤーなどは主に Rust で記述している。ここには OS レベルの詳細が多く含まれる。
実務では、多くの時間をサンドボックス機構に費やした。これが我々の作業の安全性と完全性を保証し、モデルが設定された境界を逸脱しないようにする。こうした仕事は手動で記述する傾向が強い。万全を期する必要があるからだ。
テストカバレッジを十分に確保するため、初期化だけは自ら行い、基盤フレームワーク（例えば私が熟考を重ねたモジュールなど）が構築された後、残りは AI に自動充填させることもある。
しかしそれ以外は、コードのリファクタリングや PR の分割など、かつては多くの時間を要した作業の多くをモデルに任せられる。例えば巨大な PR を作成した際、それが大きすぎると自覚していれば、モデルに「レビューしやすい複数のコミットに分割してくれ」と指示する。これで節約できる時間は極めて多い。
ライアン： コードレビューについては？OpenAI ではどの程度のコードが人間によってレビューされているのか？それともエージェントが一部を処理しているのか？テストケースなどは人間によるレビュー不要だろう？
マイケル： 私は一つの方式を支持している。エージェントに複数回の自己レビューを行わせ、十分な自信を持ってから人間に回すというやり方だ。しかし最終的にコードがマージされる前には、人間によるレビューは必ず行う。これは省かない。
実情として、他チーム同様、エージェントの設定ファイルなどもあるが、モデルの知識が不完全な箇所や、補足が必要なコンテキスト、あるいはシステムに明記されていない経験則（人間は覚えていてもモデルは知らない類のもの）に遭遇することはある。そのため、レビュー段階で問題が発覚することは依然としてある。
もう一つの顕著な変化は、AI を使った PR サマリーの作成が一般化した点だ。これによりチーム全体の記述品質が向上した。私がレビューする際、コードは既に Codex が一度目を通しており、構造化された要約（変更理由と内容が明記されたもの）が添付されている。これにより PR レビュープロセスは著しく加速し、本来の膨大なタスクレビュー圧力は解消された。
ライアン： 素晴らしい。diff ファイルの半分が空欄で、テストプランに「arc build」などの曖昧な記述しかない、一体何なのか分からない、といったことが減るわけだ。
マイケル： 本当に、不可解なことが多い。
ライアン： なぜ Codex CLI のオープンソース化を決断したのか？
マイケル： 理由は単純だ。これはローカルで動作し、かつ高い権限を持つツールだからであり、それこそがオープンソースの意味するところだ。私は極端なオープンソース推進派ではないが、この考えはよく理解できる。「自分のマシンで動作するものなら、その仕組みがどうなっているか関心を持つのは当然だ」と。特に AI プログラミング領域では、ユーザーがコードを閲覧し、その振る舞いを理解できることが極めて重要だ。AI エージェントのような新生事物については多くの疑問が残っている。ゆえにオープンソースは必須の一歩だと考える。
加えて、これにより多数の貴重なコントリビュートやバグレポートを得られ、見落としていた問題を発見できる。さらに、いかにしてコードで機能を実装しているか、その実装方法を世界に示すこともできる。前にエージェントループの仕組みに関するブログを投稿したが、もっと書きたいことは山ほどある。ただ時間がないだけだ。
面白い小話がある。2 人の候補者が面接に来た際、その内の 1 人が「自分が書いた」と持ってきたコードが、私が書いたものだと即座にわかった。もう一方は素晴らしく、私が自らコードを書いていることを評価・称賛してくれ、内心嬉しかった。
ライアン： 言及したブログで Codex の仕組みが紹介されていたが、Codex はいかにして環境内の利用可能リソースを発見するのか？ツール実行時、自律的に思考し、ターミナル内で各種リソースを見つけ出すのを見て驚嘆した。これはどのように実現されているのか？
マイケル： ここには複数の手法を用いている。例えば Codex の基盤トレーニングメカニズムにより、RIP grep などを活用した各種情報の検索が特に得意となっている。さらに、エージェント内の MD ファイルや README ファイルに「このリポジトリのこれらのツールは重要だ」と注記されていれば、それを優先的に使用しようとする。
また、MCP を使用し、これらの MCP サーバーを現在のプロジェクトに関連付けている場合、これらのツールの定義は対話の初期段階でコンテキストに注入される。厳密に言えば、この部分はモデルが「自ら発見」したのではなく、直接提供されたものだ。
ライアン： わかった。一部は Harness 内で明示的にコンテキストを注入し、もう一部はモデル自身が探索・呼び出すという理解でよいか？
マイケル： その通りだ。
AI がコードの 80% を作成可能になった今、エンジニアの中核能力とは
ライアン： あなたのキャリアを振り返ると、フロントエンドや JavaScript からビルドシステム、仮想ファイルシステム、そして現在の Codex まで、技術的跨度は極めて大きい。この過程で絶えず学習を続けてきたと思うが、影響を受けた技術書はあるか？
マイケル： 1 冊、アディソン・ウェズレイ（Addison Wesley）出版の OS に関する本がある。約 1000 ページの大作で、著者名はすぐに出てこないが。当時、仮想ファイルシステムプロジェクトに携わっており、それまでキャリアで C を本格的に書いたことはなく、学部時代は理論寄りで、低層部まで深く潜ることはなかった。
それが突然、極めて低層のシステムを構築することになった。だから冗談で「自分がプロジェクトで最も弱いエンジニアだ」と言ったのだ。誰かが何かを言い、私には全く理解できず気まずい思いをし、「何を読むべきか」と尋ねたところ、当時のマネージャーがこの本を勧めてくれた。
即座に購入し、最初から最後まで通読した。どこに行くのも持ち歩き、読み終えるまで手放さなかった。興味深いことに、多くの者がソフトウェアエンジニアリングで遠くまで進めるが、コンピュータが実際にどのように動作しているかを真には理解していない。中間に抽象化レイヤーが多すぎるからだ。
一方では生産性を解放するが、他方では限界も生む。後に、積極的に低層部へ潜ることで、多くの問題を再理解し、あるいは「解体」できることに気づいた。例えば、あるレイヤー間に冗長なオーバーヘッドがあることに気づき、それを除去するだけで、性能が桁違いに向上するといったケースだ。
だからこそ、積極的に低層部を理解することを勧める。問題解決能力の向上に著しい効果がある。加えて、O'Reilly 出版の Rust 関連書籍も気に入っている。堅実で体系的に書かれている。
本というほどのアドバイスではないが、自身にとって収穫が大きかったのが CTF（Capture The Flag）などのセキュリティコンテストへの参加だ。これは一種の「コンピュータ十種競技」に似ており、多岐にわたる分野を網羅する。ある問題はアセンブリの知識を求め、あるものは酷い PHP 管理画面の分析を要求する。
この方式は異なったレイヤーの知識への接触を強要し、ゲーム性もあり、単なる読書より楽しく、継続しやすい。
ライアン： CTF について少し説明してもらえないか？
マイケル： CTF には様々な形態があるが、通常は情報セキュリティ分野の競技だ。最も一般的なのは「Jeopardy」モードで、設計された一連の問題が出題され、各問題に点数が設定されている。制限時間内に可能な限り多くの問題を解くもので、個人参加もチーム参加も可能だ。
各問題には通常「フラグ」と呼ばれる特定の形式を持つ文字列が隠されている。逆解析や脆弱性攻撃、あるいはその他の解法ステップを真に完了して初めてこの文字列を取得でき、それを提出することで問題解決を証明する。
つまり「ターミナル内の脱出ゲーム」のようなものだ。コンピュータそのものを頼りに問題を解決する。この種の練習は、通常業務では触れない内容、例えば低層プログラムのデバッグ、バイナリ解析、システム挙動の理解などに触れざるを得なくする。
能力向上の観点からは、技術的広さを鍛えるだけでなく、「対抗的」な思考様式を形成するのにも役立つ。これは多くの複雑な問題において極めて有益だ。
ライアン： つまり、より優れたエンジニアになりたいなら、CTF のような練習を行うべきだということか？それが多様な問題解決を強いるからか？
マイケル： その通りだ。その過程で、普段は触れにくいスキル、例えば低層プログラムのデバッグやシステム挙動の分析などを習得できる。
また、異なった技術分野間の切り替えを強いる。この広さは通常業務では得難い。毎日 React を書いているだけでは、GDB を開いたり、逆解析を行ったり、低層部の動作を真に理解したりすることはないだろう。しかしこれらの能力は、多くの重要課題において極めて価値がある。
ある意味では、これもまた「抽象化レイヤーを下へ突き抜ける」訓練の一形態だ。ツールの使い方だけでなく、その背後で何が起こっているかを知ることを可能にする。
ライアン： キャリア初期の多くの者は、Codex がターミナル内ですべてを処理するのを見ると、「GDB を学ぶ必要はない。Codex が全て知っているのだから」と感慨を深める。AI ツールが急速に発展する現在、エンジニアリング能力の構築についてどう考えるべきか、アドバイスは？
マイケル： その通りで、多くの人がこの問題に悩んでいる。私も多くを考えたが、完璧な答えは見出せていない。個人的には、依然として素直な判断に戻るべきだと考える。すなわち、積極的に「下へ潜り」、これらの抽象化レイヤーを突き抜け、システムが低層でいかに動作しているかを理解することは、依然として極めて重要だ。
もちろん、この判断は将来的に変わるかもしれない。しかし少なくとも現在、エージェントに問う「問いの質」が、最終的に得られる結果に直接影響する。間違った問いを投げれば、良好なエンジニアリング的解決策は得られないだろう。さらに先ではこのレイヤーもさらに抽象化されるかもしれないが、今はまだだ。
全体的な趨勢は間違いなく「より高次の抽象」へ向かっている。問題は、私たちがいつその段階に真に到達するかで、現時点では不明だ。進展は多くの予想より速いが、正しい問いを立てる能力を掌握することが最も重要だと考える。
この能力が新人にとって何を意味するかについては、私自身も完全には整理しきれていない。私が判断を下せるのは、過去の経験の蓄積により「直感」や「品味」を形成し、いかに問うべきかを知っているからだ。しかしスタートしたばかりの若者に対し、確定的な答えを出すことはできない。未来の行方を 100% 予測することなどできず、全ては未定の間にある。
ライアン： あなたのキャリアを振り返ると、これらのハイレベルなポストの要件は並外れている。多くの者にとって E7 やシニアスタッフでさえ到達困難なレベルだが、あなたはさらに 2 ランク上だ。日常業務において、この「高い期待」をどう見ているか？プレッシャーを感じるか？
マイケル： 私にとって、プレッシャーが消えたことはない。誰もがパフォーマンス評価を経験するだろう？この職位に就けば、他者の職級や影響力を査定するのと同様、自らの頭脳内にも可能な限り公平で公正な評価体系を構築したくなる。異なる職級には対応する基準と影響力の幅が必要だ。
「この職級にはこの基準、あの職級にはあの基準」といった具合だ。その際、私の頭脳内では絶えず推演が行われる。「もし他者が私の評価席に座って基準を議論するとしたら、彼らもまた公平でなければならない」と。これは巨大なプレッシャーだ。例えば E8 クラスになると、突然 D1 レベルのディレクターと対峙することになる。「百人規模のチームを管理する重役と、いかにして影響力で渡り合えばよいのか？」と考える。
これは確かに困難だ。多くの個人貢献者は「間接管理」とも言える別の方法で目標を達成する。仕様文書の作成やチーム間調整などだ。彼らが直接マネージャーにならずこの方法を選ぶのは、技術的信頼性を有しているか、あるいは現在のプロジェクトを実際に構築した経緯があるため、チームとコミュニケーションを取る際の影響力が、通常のエンジニアリングマネージャーなどを遥かに凌駕するからだ。
これは稀なことではない。シニアな貢献者が数十人、数百人に影響を及ぼすことができれば、それは D1 クラスの影響力に相当する。普通のプログラマーとして、我々はプロジェクトを慎重に選択する必要がある。「このプロジェクトは楽しいから」という理由で選んではいけない。職を失ったり、トップに全体会議で吊るし上げられたりしたい者はいない。
実際、私がプロジェクトを立ち上げる際も、常に熟考を重ねる。「ある機能について、楽しみのために自ら手を下したい」と思うこともある。しかし真剣に考慮した結果、他者に任せることを選ぶ。例えば現在の Codex プロジェクトでは、自らの影響力を最大限拡大するために、どのコードを自ら記述すべきかを考慮する。他者に任せて 80% の効果が得られるなら、他者に任せるべきだ。
しかしそれでも、5 名規模のプロジェクトを率いて E8、E9 クラスの貢献期待値に達するのは困難だ。重要なのは、乗数効果を生むプロジェクトを見つけることだ。仮想ファイルシステムはその好例で、その出現が無数の可能性を解放し、チームが性能ボトルネックで立ち往生するのを防ぐことは周知の事実だ。
もう一つの重要点は、私の上司がかつて強調していたことだ。「我々は高次管理者の価値を過小評価しがちだ」と。彼らこそが、シニアな中核エンジニアと適切なプロジェクトをマッチングさせる存在だ。シニアエンジニアの中には優れた問題解決者でコードの名手でも、創意の源ではない者もいる。彼らこそが高難度技術プロジェクトを処理する理想的な人材だ。具体的な名は出さないが、意図は理解してもらえるだろう。多くの場合、当事者自身は気づいていないが、管理者が「このプロジェクトはあの人間にやらせるべきだ」と決断しているのだ。
ライアン： あなたの元同僚であるアダム・アーネスト（Adam Ernst）に、特に称賛するエンジニアがいるか、その理由は？と尋ねたことがある。その際、彼はあなたの名を挙げ、「プロジェクト起動能力が極めて優れている」と強調していた。数多くの優れたプロジェクトをあなたが一手に牽引してきたことは想像に難くない。アイデアを思いつけば即座にプロトタイプを構築するこの実行力は並大抵ではない。
さらに、あなたの案が最適解であることを極めて強力に説得してみせる。問題を見つけ、初步的な思路を有し、ゼロからプロジェクトを構築したいと考える他のエンジニアへ、何かアドバイスはあるか？
マイケル： 実際、多くの優れたプロジェクトの着想は、「現状へのささやかな不満」から生まれると感じている。「ある事が現在あるべき姿ではない」という感覚自体が、強力な出発点になる。
興味深いことに、私の最大の特徴は「突き進む勢い」だ。我を忘れて苦干し、先々のことを考えず、あるべき最適実装方法さえ考慮しない。古典的例が Google カレンダーの初期バージョンだ。ふと「天候機能を追加しよう」と思いつき、カレンダー上に天気アイコンを直接表示させることにした。そして即座に取り掛かった。
当時は JS が専門で、バックエンドには触れたことがなかった。無理やりコードを継ぎ合わせて機能を完成させたところ、技術リーダーから「待て、その天気データはどう保存している？」と問われた。「適当に XML データを放り込んである」と答えると、「プロトコルバッファ方案について議論する必要がある」と指摘された。そこで初めて、バイナリ形式ならスペースを節約できると悟った。
とにかく私は、機能実装のことしか考えず、より良い方案があるかどうかなど他者に尋ねもしない。「取りあえず動けばよい」主義だ。
ライアン： まさにその独特の属性が、問題の根源を掘り下げ自主解決するのに適しているのだろう。ほぼ全プロジェクトがそうだ。「現実はなぜこうなのか？機能を現実化して解決するしかない…」そしてあなたは手を付け始める。
マイケル： ああ、まさに我を忘れて突き進むだけだ。
ライアン： もう一つの特徴として、多くの人はコンフォートゾーンに留まることに慣れている点が挙げられる。先に挙げた Buck プロジェクトも、多くの者がビルド速度の異常な遅さに気づいていたはずだ。しかし彼らの考えは「まあいっか、カフェで何か食べて戻ってこよう」といったものだが、あなたは何故、性能を劇的に最適化できると信じられたのか？
マイケル： あの時は Google での経験が役立った。Blaze チームに所属したことも、プロジェクトの具体的実装原理も、関連コードにも触れたこともなかったが、「世界にはより良い解決策が存在する」ことは明確に知っていた。この「存在証明」が重要だ。それが存在することを知っていれば、自らに実現できるか不確かでも、試すだけの支えになる。
また、過去の技術的成果の多くが自信を蓄積してくれた。私は自らを「プログラミングマシン」と自負している。現在 Codex が現れ、皆がプログラミングマシンになったとしても、この自信は保ち続けている。迅速なプロトタイプ構築は疑問に答えるか、思想的に基本仮説（私が本来存在すべきだと考えるもの）に実現可能性があるかを検証できる。
簡単に言えば、決意が固ければ、往々にして解決策は見つかるものだ。
ライアン： よくある現象として、多くの者が大企業で世界クラスのインフラを目にした後、他社へ移ると「これがない、あれがない」と感じ、これらを一から作り直すことがある。また、あなたの多くの記事を読んだが、その文章は極めて明晰で、技術文章の規範と言える。文章力を向上させたいエンジニアへ、何かアドバイスは？
マイケル： 鍵はやはり「多読」だ。読書は文章力向上への最良の入り口だ。意識的か無意識的かを問わず、読書プロセスで文章の型、作品の構造特徴などを掴むことができる。さらに、より巨視的な思考を育むのにも役立つ。「私たちが真に伝えたいのは何か？読者が真に知る必要があるのは何か？」を問うことができる。加えて、詳細なアウトラインの事前準備が必須だ。多くの人がこれを強調するが、その重要性は往々にして過小評価されている。
具体的な執筆においては、「内容間に線形の論理連鎖が形成されているか」が鍵となる。常に自問する必要がある。「この点からあの点への飛躍が大きすぎないか？読者が見落としがちだが、実際には極めて重要な环节はないか？」これらの疑問を解決できれば、論理の断絶を明確に予測でき、「読み手に理解されない」という問題を回避しやすくなる。
この状況を予測した後、巧妙に例を挿入し、読者の論理的飛躍を誘導・支援する必要がある。少なくとも技術文章の領域では、これも極めて重要だ。
ライアン： あなたが以前書いたキャリア発展に関するノートが非常に気に入っている。冒頭で「影響力を拡大する 3 ステップ計画」を提示していたが、これを具体的に説明してほしい。キャリア開発において誰もが参照すべきだと思う。
マイケル： 第一歩は「自分が真に何をしたいか」を明確にすることだ。先に述べたように、興味範囲を拡大するのは結構だが、自らの内面と誠実に向き合うことも重要だ。これは容易な問いではない。私が経験した多くの「英雄の旅」が失敗したように、私の行った事の多くは熱愛によるものではなかった。第二歩は、「雇用主が真に何を重視しているか、何が最も価値あるか」を明確にすることだ。
ライアン： これは極めて重要だ。
マイケル： 例えば Google 時代、私はこれができていなかった。自分の熱愛する事はやっていたが、それは Google の広告事業の中核ではなかった。
第三歩は、この 2 つの交差点を見つけ、可能な限りその交差点に精力を集中させることだ。これができればできるほど、通常はより影響力のある成果を出しやすくなる。
もっとも、現実問題として、この交差点が存在しない場合もある。その際は環境を変え、それが成立する場所を見つけることを検討する必要がある。
ライアン： 最後の質問だ。もし今、これらの経験を携えてキャリアの起点に戻るとしたら、若き自分へどんなアドバイスをしたいか？
マイケル： もっと早期に心を開き、より多くの事を学ぶべきだった。また、自分自身にもっと厳しくあるべきだった。多くの友人が共感してくれると思うが、スタート段階では学ぶべき事があまりにも多い。そのため、最初のプログラミング言語に触れ、特にそれを習得すると、その言語への愛着が湧き、「これが最高だ」と証明する口実を探したくなる。「どんなシナリオでも、この言語自体に全く問題ない」と言ってしまう。
それは私たちが真に物事に取り掛かり、問題を解決し始める起点を象徴し、「ようやく何かを成し遂げられる」という素晴らしい爽快感と密接に結びついている。しかしこれが罠となり、その仕事にしがみつく原因となる。ようやく足場を固め、効率的に仕事ができるようになったと思ったら、新たな転身と突破のために再び学習し直さなければならない。誰が耐えられるか？
私自身もそうで、JS への没頭が深すぎたと感じている。もし当時、他のプロジェクトタイプや学習内容により多くの好奇心と柔軟性を保っていれば、結果はより良だっただろう。最終的には達成したが、能動的にコンフォートゾーンを離れることで、より早期にブレークスルーを達成できていただろう。
ライアン： 過去の経験から、あなたは Xcode 時代、Objective-C を極めて憎悪し、後には Objective-C を Java へコンパイルし、再度コンパイルし戻すという方法まで考え出した。C 言語の習得への執着も、ある種の刺激を受けたためだろうが、とにかく理解するまで自分を追い込んでいた。もっとも Codex は成熟し、学習ハードルを劇的に下げてくれる。将来は JS、Rust、あるいは任意の言語形式のコードを自由に出力させることも可能になるかもしれない。
マイケル： 本当に、Codex の発展と成熟は、より多くの可能性を開いた。
ライアン： 素晴らしい。貴重な時間をありがとう。大変勉強になった。
マイケル： こちらこそ、ライアン。招待に感謝する。
原文：https://www.developing.dev/p/openai-codex-tech-lead-on-how-his
（注：記事末尾の広告および関連リンクは、本記事の本題と無関係なため、翻訳の完全性と内容の純粋性を保つため省略しました。）