9月10日、The Pragmatic Engineerが「Building Codex with Tibo Sottiaux」と題した記事を公開した。この記事では、OpenAI CodexのコアエンジニアであるTibo Sottiaux氏へのポッドキャストインタビューを通じて、Codexの設計思想・開発体制・技術的判断の裏側について詳しく紹介されている。

CodexをRustで書いた理由

AIコーディングエージェントのCLIツールとして知られるOpenAI Codex。その実装言語として、チームはRustを選択した。

一見すると奇妙な決断に見える。当時、AIモデルはPythonやTypeScriptのコードを生成する能力の方がRustより格段に高かったからだ。なぜRustだったのか。

Tibo氏によると、Codexチームは当初から「数百万のクラウドマシン上でCodexインスタンスを動かす」というビジョンを持っていた。そのため設計の第一原則として、パフォーマンス・セキュリティ・スケール効率を置いた。後からの書き直しを避けるために、最初から高性能な言語を選ぶという判断だ。

この点はThe Pragmatic Engineerが以前取り上げたCasey Muratoriとの対談での「パフォーマンスは最初からアーキテクチャに組み込む必要がある」という主張とも重なる。

オープンソース化と、競合との非対称な戦い

Codexはオープンソースとして公開されている。最大の競合であるClaude Codeがクローズドソースである点と対照的だ。

オープンソースの恩恵として、Tibo氏はコミュニティからの貢献とユーザーからの信頼を挙げる。一方で、あまり語られないデメリットもある。Codexチームの実装が他のツールに先にコピーされてリリースされることがあるという点だ。「悔しいが、オープンに作る代償だ」とTibo氏は述べた。

さらに、オープンソースであることがモデルの多様対応にも直結している。Claude CodeはAnthropicのモデル専用だが、CodexはOpenAI以外のモデルでも動作する。仮に特定モデルに縛ったとしても、誰でもフォークして数行変えれば別モデルに対応できてしまうため、最初から開放しているという論理だ。Codexチーム自身も同じハーネス上で他社モデルを試している。

「ハーネス」とは何か

Codexの技術的な核心として登場するのが「ハーネス」という概念だ。これはCodex固有の用語であり、一般的なソフトウェア開発における「テストハーネス（テスト実行基盤）」とは異なる。Codexにおけるハーネスとは、モデルに与えるガードレール・安全性・操作性・各ターン冒頭に挿入される開発者メッセージなどをまとめた制御層全体を指す。

重要なのはその進化の方向性だ。ハーネスは常にOpenAIの最新モデルより少し先を走っている。モデルが賢くなるにつれて「補助輪」が不要になり、ハーネスは縮小していく。これがCodexとモデル開発の間で繰り返されているサイクルだという。

コードレビュー・保守・リアーキテクチャが変わる

Tibo氏が語る開発プロセスへのインパクトは具体的だ。

• 依存関係のアップグレードなどの保守タスクは、モデルがコードベースを数時間で処理して完了できる
• リアーキテクチャ（設計の大幅な変更）は、かつて数年かかっていたものが今や数日で完了できる
• ただし、品質の高いコード・適切な抽象化・充実したテストスイートがあることが前提条件になる

コードレビューについても変化がある。Tibo氏の見解では、コードの意図についての議論はコードレビューの場でなくても（むしろコードを書く前に）行われるべきであり、AI主導のコードレビューではコードの正確性チェックとセキュリティレビューが自動化されていく、としている。

Codexは社内の「全知」システムになっている

OpenAI社内でのCodexの使われ方も興味深い。Tibo氏によると、CodexはSlack・社内ドキュメント・全コードベースにデフォルトで接続されており、新入社員は「誰が何を担当しているか」「なぜこの設計判断が下されたか」を含め、何でも質問できる状態になっている。

新入社員へのアドバイスを聞かれたTibo氏の答えは端的だった。「まずCodexに聞いてみましたか？」

これを実現するために、チームは意図的にパブリックチャンネルで作業し、広い権限のオープンドキュメントで作業している。

Googleで「ChatGPT的なもの」を1年早く作っていた

インタビューでは、Tibo氏の経歴も明かされている。Google在籍時、DeepMindチームの一部が「LLMとチャットする」プロジェクト「LMChat」を社内で開発していた。社内では爆発的に広まったが、製品としてリリースされることはなかった。

X（旧Twitter）へのTibo氏の投稿が当時の状況を率直に伝えている：

@_chenglou I was part of that team. Basically ChatGPT one year before it came out. Called LMChat and then another codename. Google was too nervous to release it and DeepMind was blocked from shipping products that could disrupt Google. I think about this a lot.
— Tibo (@thsottiaux)

要約すると、「自分もそのチームにいた。ChatGPTが世に出る1年前、社内ではほぼ同等のものを作っていた。LMChatと呼ばれ、その後別のコードネームに変わった。Googleはリリースに踏み切れず、DeepMindはGoogleの事業を脅かす製品を出すことを禁じられていた。今もよく考えることだ」という内容だ。

2022年のOpenAIによるChatGPT公開より1年前にGoogleが社内で類似システムを持っていたという事実は、AIチャットボット覇権争いの経緯を別の角度から照らすものだ。技術的優位が必ずしも市場での勝利に結びつかないことを示す事例として、業界関係者の間でも広く語られている。

「ゾーン」に入る時代の終わり

最後にTibo氏が語ったのは、自身の働き方の変化だ。かつてのような「深夜まで集中してコードを書き続ける」体験は薄れた。今はエージェントを走らせれば1分以内にデータが得られるため、勘に頼る代わりにデータで意思決定できる。エディタを開いてコードを少し書くことは今でもあるが、それは「気持ちいいから」だという。

エンジニアリングの醍醐味とされてきた「ゾーンに入る」感覚が変質しつつある一方で、設計判断の質・コードベースの整理状態・テストの充実度といった「AIが活きる土台」を整える能力の重要性は増している。Tibo氏のインタビューは、AIエージェント時代においてエンジニアに求められるものが何かを改めて問い直す内容といえる。

詳細はBuilding Codex with Tibo Sottiauxを参照していただきたい。