SpaceXAIのエンジニア：いかにしてAIの「人間の伝言係」を脱し、単月2,500件の高品質なPRマージを実現するか？

技術ブロガーの Matt Pocock と Lauren Tan（ネット上の名義は Poteto、オープンソースプロジェクト pstack の作者、現 SpaceX AI／Cursor 所属）が掘り下げた対談を行った。

Lauren によると、自身は現在 Grok Bot という Agent アプリケーションのエンジニアリングに携わっており、先月は 2,500 件の PR をマージしたという。（PRとは、コードベースへのレビューとマージのために提出される一連の変更のこと）二人が中心となって議論したのは、いかにして AI の「人間の伝言係」から抜け出し、Agent とツールチェーンの力を借りて、コードの作成から自律的な検証・マージまで完結させ、彼女が語るようなデリバリースケールを達成するかという点だ。

インタビューの中で Lauren が語った作業スタイルは、プロンプトをいかに素早く入力するかといった話にはほとんど触れていない。彼女は膨大な時間を別のことに費やしている。それは、「なぜ Agent は依然として自分の介入を必要としているのか」を突き止め、その作業をシステム側で肩代わりできるようにすることだ。

pstack は、彼女の開発手法を Agent が利用できるスキルやワークフローとして体系化したスキルプラグインである。彼女が共有した PR の件数には多数のコード保守・メンテナンスに伴う変更が含まれており、数千個の新機能と同等視することはできない。だが、この数字で注目すべきなのは、継続的デリバリーにおいて彼女自身がすべての作業を立ち上げ、指示し、検査する必要がもはやなくなったという点である。

これはまさに、多くの AI 開発者が直面しているジレンマを突いている。コード生成は高速化したものの、人間の1日は依然として「ちょっと確認してあげる」「背景情報を補足してあげる」「規約をもう一度注意する」といった作業で埋め尽くされている。Agent は人間の代わりに作業を実行してくれるが、一連の仕事は依然として人間の注意力を軸に回っている。タスクを同時にいくつか増やせば、人間の回答を待つ質問もそれにつれて増えていく。

この状況を打開するには、エンジニアリングの知見や経験の置き場所を変える必要がある。これまで自分しか知らなかった検証手法、設計上の習慣、プロジェクトの背景情報を、ツール、コードベース、情報パイプラインの中へと徐々に移行させなければならない。そうして初めて、Agent は必要なときにそれらの知見を取得できるようになり、毎回作業を止めて人間を待つ必要がなくなるのだ。

人の手による介入箇所から、システムに不足している能力を見出す

Lauren の最初の試みは、大規模なチームの中で始まったわけではない。Meta を退職した後、しばらく休養を取り、個人プロジェクトを始めた。AI を使ってコーディングしていたとき、彼女は個々の Agent をマイクロマネジメントすることに多くの時間を浪費していることに気づき、自身の仕事の進め方をスキルとして記述し始めた。単に動くコードを生成させるだけでなく、Agent が自分自身の問題解決手法により近い形で課題に対処できるようにしたいと考えたのだ。

ここには見落とされがちなディテールがある。当時、彼女自身もスキルがどれほどの改善をもたらしたのかを測定するのが困難だったということだ。ワークフローのドキュメントを作成することと、Agent が本当に自律して仕事を完遂できると証明することとは、まったく別の話である。

その後 Cursor に入社した彼女は、Agent ウィンドウのパフォーマンス最適化に携わった。インターフェースがなぜカクつくのかを解明するには、パフォーマンスのフレイムグラフを確認して時間がどの操作に費やされているかを把握し、さらにメモリスナップショットを調査してメモリ使用量に異常がないかを判断した上で、コード上の問題箇所を探し出す必要がある。当初、こうした観察作業は主に彼女の手で行われていた。彼女がツールを確認し、発見した内容を Agent に伝え、Agent がコードを修正し、彼女が再び確認しに戻る、というサイクルだ。

この一連のチェーンにおいて真に希少な能力とは、コードを入力することではなく、結果を取得し、その結果を解釈することだった。この工程に常に人間を介在させる必要がある限り、Agent の次のアクションは常に人間に依存し続けることになる。

したがって、「どこでまた自分の手助けが必要になったのか」は、具体的なエンジニアリング上の課題として捉えることができる。それは、Agent に実行結果を観察するためのツールがないことを意味しているのかもしれない。あるいは、最新の要件を把握していないか、どのような実装手法が受け入れられないかがコードベース上で明確に表現されていないのかもしれない。欠落しているのがどの能力なのかを突き止めてこそ、何を補うべきかを判断できる。プロンプトに指示をもう1行追加するだけでは、同じ問題を次のラウンドへと先送りするだけに終わる場合があるのだ。

結果が見えてこそ、Agent は実行から改善へと進める

パフォーマンスの最適化は非常にわかりやすい例だ。Agent にカクつきの改善を求めた場合、修正を完了した後に、アプリケーションを再起動し、関連する操作を再現し、新たなパフォーマンスデータを読み取れなければならない。そうでなければ、コードが見た目上最適化されているように見えるかどうかしか判断できず、ユーザー体験が本当に改善されたかどうかは判断できない。

Lauren が重視する検証能力とは、まさにこのフィードバックループを接続することである。Playwright や Chrome DevTools Protocol などのツールを通じて、Agent はアプリケーションを実行し、UI を操作し、トレースやスナップショットを取得して、その結果をもとに次のステップを決定できる。彼女が強調する「目と手」とは、実際の稼働状態へのアクセスを指している。

再現性のある検証があって初めて、タスクは「修正、実行、結果の比較、アプローチの維持または調整」という継続的な改善プロセスへと変わる。彼女はこのアプローチを「山登り（hill climbing）」に例えている。進捗を判断できる客観的な基準があってこそ、Agent は自分が目標に近づいているかどうかを把握できるのだ。ループの価値はフィードバックからもたらされるものであり、単に何ラウンドも多く実行すること自体にあるのではない。

しかし、「Agent に自律検証させる」ことには新たなムダも潜んでいる。固定化されたツールがないと、Agent は検証用のスクリプトを毎回ゼロから書き直してしまいがちであることに Lauren は気づいた。前の Agent がすでに解決した問題を後の Agent が再び再実装し、作業に着手する前から検証用ツールのデバッグに時間を空費してしまうことさえあった。

そのため彼女は、環境の起動、ブラウザとの通信、診断データの収集といった重複する操作手順をコマンドラインツール化し、同一の実装を再利用できるようにした。明確なコードパターンのバッチ変更も、スクリプトに任せることができる。Agent は、方針の選択、結果の理解、そして次にどこを調査すべきかの判断に専念する。

これは極めて実践的な役割分担である。プログラムとして明確に表現できるステップは、一元管理して繰り返し利用する。コンテキストを踏まえた判断が必要な部分は、モデルに委ねる。スキル用のドキュメントは作業をどう進めるかの説明を担い、タスクのたびにツールを再発明させる必要をなくす。

この機能群は彼女1人だけのためのものではない。Lauren によると、チームではすでに各アプリケーション向けに自動メンテナンスされる検証スキルを構築し、全員で共有しているという。1人がアプリケーションの検証手順を整備すれば、他のメンバーの Agent もそれをそのまま再利用でき、各自が手探りで車輪を再発明する必要がなくなる。これにより検証はチームのインフラとなる。アプリケーションの進化に合わせて継続的なメンテナンスが必要となるが、その価値は多様なタスクにおいて繰り返し発揮される。

検証方法そのものには、依然としてエンジニアリング上の判断が求められる。二人は、Agent が「実装と同じ理屈を繰り返すだけのテスト」を書いてしまう問題について語り合った。一見すると機能を検証しているように見えて、実際には実装ロジックをなぞっているだけで、有意義な検証になっていないテストのことだ。テストの実行を Agent に委ねたとしても、「このテストは一体どんなバグを検出できるのか」という人間による判断を省くことはできない。真に再利用可能な能力とは、有効な受け入れ基準（アクセプタンスクライテリア）そのものなのだ。

コードベースは、エラーが発生したまさにその瞬間に経験を機能させるべきである

結果の観察が「変更に効果があったか」を解決するのに対し、コードベースの制約は「どのような実装手法を最終結果に含めるべきでないか」を解決する。両者は互いを補完し合う関係にある。

Lauren によれば、Grok Bot の初期バージョンは約8つの1万行を超える巨大ファイルで構成されていた。そうした構造の中で Agent が機能を追加し続けようとすると、一番手っ取り早い方法は往々にして新たなロジックをそのまま詰め込むことになってしまう。人間がいくら「モジュール化せよ」と繰り返し求めても、ディレクトリ構造やエントリーポイントに関する明確な規約がなければ、機能を追加するたびにアーキテクチャの選択をゼロから迫られることになる。

彼女が紹介した社内製デスクトップアプリフレームワーク Dune は、機能の体系化に対して明快な道筋を提供している。各機能は独立したディレクトリを持ち、規約化された登録・ディスカバリー機構を介して接続され、不適切な書き方はリントルールによって制約される。新機能をどこに書き、どう接続するかは、すでに開発環境の中に織り込み済みとなっている。

これは彼女が慣れ親しんだ「型の絞り込み（type narrowing）」の考え方と通底している。取りうる選択肢の幅を狭め、現時点で許容されるアプローチを明確にするのだ。その目的はあらゆる判断を固定化することではなく、すでに合意が形成されているエンジニアリング上の選択について、毎回蒸し返して議論する手間を省くことにある。

プロンプトは基準を説明できるが、リントルールは基準に違反した際に具体的なエラーを返すことができる。不適切な修正がその場でブロックされれば、Agent は現在のタスクのコンテキスト内で直ちに自己修正できる。これにより人間の経験は、「誰かが覚えていて口頭で指摘しなければならないもの」から、「作業がそこを通過すれば必然的に遭遇する客観的条件」へと昇華する。

このような環境は人間の同僚にとっても有益だ。Lauren は特に新しくチームに加わったエンジニアについて触れ、明確な規約があればチームの慣習を理解するためのコストを削減できると述べている。チームの仕事の進め方はより明瞭になり、遵守しやすくなる。

複数 Agent の難所：いかにして同一の全体像を共有するか

個々の Agent が自律的に実行・観察・修正を行えるようになった後も、依然として人間に跳ね返ってきやすい仕事がある。それは、「最新の情報を Agent に届ける」ことだ。

タスク開始時に受け取った要件は、あくまでその時点でのスナップショットに過ぎない。ユーザーからは継続して問題が報告され、同僚から制約事項が追加され、優先度が変わることもある。もしこうした情報が Slack、Linear、メール、あるいは X の中に留まったままであれば、Agent は時代遅れになった目標に向かって懸命に作業を完了させてしまう可能性がある。そして人間は、再びツール間を伝言して回るメッセンジャーに逆戻りしてしまう。

Lauren が語る「外側のループ」と「内側のループ」は、まさにこの両者を繋ぐためのものである。外側のループが外部ツールから絶え間なく変化するコンテキストを取得し、内側のループの Agent がその背景情報を活用してコードの作業を進める。彼女は Grok Bot のコネクタを使って関連情報を収集し、それを Cursor Projects へと流し込んでいる。肝心なのは、コンテキストが不足している中で Agent に当て推量させるのではなく、実際の生きた情報を Agent が入手できるようにすることだ。

彼女が挙げた例は、Agent に特定の Slack チャンネルを購読させ、障害報告を受信した際にまず調査と再現を行わせるというものだ。ここで先ほど構築した検証スキルが威力を発揮する。問題が現在のメインブランチに依然として存在しているかを確認し、ユーザー固有の環境、データ、依存関係の不足なども考慮に入れる。メッセージを受信することは始まりに過ぎない。何が問題なのか、コードの修正が必要なのかをまず見極めてこそ、どう対処すべきかを判断できる。情報パイプラインと検証ツールが結びついて初めて、人間がフィードバックを伝達し、かつ Agent に代わってフィードバックを判断するという二重の負担を軽減できるのだ。

情報が届いた後も、「1つの報告につき1つの Agent を機械的に割り当てる」べきではない。彼女と Matt は、一連の関連するパフォーマンス問題について議論した。報告内容にわずかな差異があることこそが、共通の原因を見出す手がかりになることがある。もし個別に処理してしまうと、各 Agent が目の前の対症療法に終始したり、まったく同じ作業を重複して行ってしまったりするおそれがある。

コーディネーターの責務はまさにここにある。タスクを統括し、コンテキストを伝達し、実行を委譲することで、関連する問題群を俯瞰して理解する機会を作り出す。Lauren はこのアプローチを、Netflix でチームを率いていた自身の経験と重ね合わせている。コンテキストを提供し、実行者が自ら判断できるようにして初めて、細かな指示出しを減らすことができる。Agent にとっても同様に、目標を伝えるだけでなく、判断を下すために必要な情報を見つけ出せるようにしてやる必要があるのだ。並列処理に価値が生まれる前提として、まず作業同士の関係性を整理しなければならない。タスクの数をただ増やしたからといって、自動的に有効なアウトプットが増えるわけではない。

コードの定期パトロールは、この点をさらに明確に示している。Lauren は、React 内のアンチパターンを継続的に探索する Agent を運用しているが、問題を発見しても直ちにすべてを修正させるのではなく、まずはドキュメントに追記させている。彼女が数日おきに蓄積された発見事項を確認することで、同種の問題をパターンとして特定できる。共通のルールや設計を一度に改善する方が、個別に対症療法を繰り返すよりもはるかに価値が高い場合があるのだ。

これは、スピード重視の実行に不可欠な「一時停止」をもたらす。まず発見を蓄積し、その上でパターンを観察するのだ。コーディネーターとパトロールログの双方が、システムが個別のタスクを超えた関連性を捉えるのを支援し、「忙しく処理していること」を「適切に解決されたこと」と見誤る事態を防いでいる。

これらを総合すると、人間が担うべき仕組みづくりの作業がより明確に見えてくる：

これらの能力を一挙にすべて揃える必要はない。この表の目的は、自身の注意力が具体的にどの工程で滞っているのかを明確にすることだ。Lauren は「さらに多くのレストランを出店する前に、まずは1つの厨房を整えるべきだ」という比喩を用いて、スケールアップの前提条件を説明している。まずは1つのプロジェクトにおいて、ツール、規約、検証が自律的な作業を支えるに足る状態を作り上げ、その上でその能力を他のプロジェクトへと広げていくのだ。Agent のウィンドウを単に複数開くだけでは、こうしたインフラの構築を代替することはできない。

人間は直接の実行を減らせても、システム全体の仕事に対する責任は負い続ける

Lauren によれば、彼女は「いかにして Agent 自身にコードをマージさせるか」という問いから逆算して考えたという。最終的に自分自身が1件ずつコードレビューを行わなければならないのであれば、デリバリーの規模は自分がどれだけのコードを読めるかという上限に縛られてしまう。前述した検証ツール、エンジニアリング上の制約、コンテキストパイプラインはすべて、作業の各ステップで Agent が立ち止まって彼女を待つ必要をなくすためのものだった。

この環境が徐々に成熟した後の運用の様子として、Lauren は Agent を夜間に自律稼働させてコードをマージさせ、翌朝自分はコミット履歴を確認するだけ、というスタイルを説明している。ただし彼女は、この領域に到達するには多大な時間と労力が必要であり、単に pstack を導入すれば手軽に実現できるようなものでは決してない、とも明言している。

彼女の全自動モードでは追加の検証用 Agent が立ち上がり、アプリケーションを実行し、ユーザー操作をシミュレートし、リグレッションや実装の不具合を探し出し、修正と再検証を繰り返す。こうした検証は少なからぬトークンを消費するが、検証用 Agent の数は調整可能である。人間による個別の手作業を省くには、ツールのメンテナンスとコンピュートリソースというコストを支払う必要があるのだ。

同時に、彼女は現在でもコードのサンプリングによる確認を行っている。サンプリングによる確認の目的は、単に個別の不具合を発見することだけではない。システムが同じようなアンチパターンを繰り返し生み出していないかを見極めることにある。単発の問題であれば局所的に修正できるが、複数の Agent が揃って望ましくない近道を選んでいるとすれば、スキル、型の制約、リントルール、あるいはツールの設計に立ち戻って見直す必要がある。

これにより、人間の責務は目の前の各ステップに対処することから、以降のすべてのタスクが通過する開発環境そのものを改善することへと拡張される。人間による1回の判断がチャットの中に留まるだけであれば、次回も同じことを繰り返すことになりかねない。しかし、それが適切なツールやルールとして定着すれば、後続の作業は持続的にその恩恵を享受できる。

しかし、権限の委譲には常にその結果に対する配慮が求められる。Matt は、容易にロールバック可能な「ツーウェイドア（可逆の扉）」と、データ損失を引き起こしかねない「ワンウェイドア（不可逆の扉）」について問いかけた。Lauren は回答の重点を「検証可能性」に置いた。プログラムによる自動検査が容易な領域ほど、自律的なデリバリーに対する確信を持ちやすい。一方で、検証が困難な領域について、彼女は万能な解決策を示していない。

「検証可能であること」と「取り消し可能であること」は切り離して評価しなければならない。テストが通過したということは、検査された条件が満たされたことを示すだけであり、すでに失われたデータを取り戻してくれるわけではない。チームがどれだけの自律権限を委譲できるかは、検査が十分であるかだけでなく、判断を誤った際に何が起きるかにも左右される。インタビューの後半で触れられた形式手法による証明や Agent 向け言語の模索も、より強固な検証能力に対する期待の表明であり、現状のすべての PR が数学的に証明されているという意味ではない。

これこそが、「ミシュランの厨房」という比喩が真に示唆に富んでいる理由だ。総料理長はすべての調理工程を自らこなす必要はないが、作業を組織化し、調理器具を整え、料理の品質基準を策定し、客に提供される料理が合格点に達しているかを判断しなければならない。直接手を下す作業が減ったからといって、最終的な成果物に対する責任が軽くなるわけではないのだ。

ドメインの知見や経験は、こうしてより高度な場面で発揮されることになる。ユーザーが真に何を求めているのか、どの実装を残すべきか、どのようなテストが無意味であるかを見抜くには、いずれも深い経験が必要だ。モデルが実装を得意になればなるほど、人間はそうした判断基準を明確に言語化し、モデルが活用できる作業環境へと組み込んでいく必要がある。

対談の冒頭で、Lauren はボトルネックを「意図の伝達」であると呼んだ。すなわち、自分が頭の中で求めているプロダクトを明確に言語化できているか、という点だ。Matt は TDD（テスト駆動開発）を例に挙げた。期待される振る舞いをまずテストとして記述し、その後に実装を行う手法である。このアプローチを提示することで、Agent はテストと期待される振る舞いを優先して考慮するようになり、作業の段取りの組み立て方が変わる。専門的な経験の価値は、何を強調し、何を排除すべきかを熟知し、Agent の解釈がずれていないかを見極められることにある。もし自分自身の考えがまだ固まっていない場合でも、Agent からの逆質問を通じて思考を整理できると二人は語る。明確な目標は対話の中で形成できるが、「これこそが自分の求めていたものだ」と判断するのは、やはり人間でなければならない。

対談の最後に、二人は Agent との過去の対話履歴を振り返ることを勧めている。何度も繰り返された修正、背景情報の補足、作業手順の再説明といった記録は、日々の仕事が実際にどのように進行しているかを克明に映し出している。Lauren の recall スキルも、具体的な困りごとから生まれたものだ。Cursor の仮想化問題を処理する際、新しい対話セッションに前回の対話のコンテキストを引き継ぐ必要があった。このプロセスをスキル化したことで、毎回長大な説明を書き直す負担が軽減された。

こうした知見の蓄積は非常に属人的なものだ。Lauren はこのインタビューを告知した元の投稿において、自身と Matt のスキルプラグインを組み合わせて使い、各自のワークフローに合った部分を取捨選択することを勧めている。真に磨き上げるべきツールとは、自分自身の経験を受け止められる仕組みのことだ。さらに Lauren は、モデルの能力が向上するにつれて、スキルはワークフローの骨格に焦点を当て、冗長な実装の詳細を削ぎ落としていけることにも気づいた。スキルとして残すべきなのは、作業をいかに進め、いつ検証し、次に何を基準として判断するかである。モデルが自力で処理できるようになった詳細事項については、毎回長文の説明を書く必要はない。自身の働き方を変えたいと願う人にとって、その出発点は「直近で Agent の作業を中断して手助けせざるを得なかった瞬間」にある。その手助けを、次回は Agent が自律的に獲得できる能力へと変えられないだろうか？

出典：Matt Pocock と Lauren Tan の対談全編、Lauren による対談告知の元ポスト。