AIエージェントを信頼できるものにする：検証、強制的な制約、規約ベースのアーキテクチャ

ひとこと要約：AIエージェントに安心してコードを書かせるには、まずエージェント自身が成果を実際に検証できるようにし、そのうえでCIやlintなどの強制的な制約と規約ベースのアーキテクチャで人手のレビューを置き換える必要があり、そうして信頼を少しずつ積み上げれば、エージェントによるPRの自動マージまで到達できる。

重要なポイント

信頼が講演全体の軸だ。信頼が足りないうちは少数のエージェントを張り付いて見るしかなく、並列化できず、クラウドエージェントを一度に大量に起動してもtokenを無駄にするだけだ。彼女は5か月かけて信頼曲線を登り、エージェントによる自動マージと、目覚めると20個のPRがメインラインに入っている状態にたどり着いた。
検証が信頼の出発点だ。検証スキルがなければ人間がボトルネックになるため、まずエージェントにアプリを実際に操作させ(control glassスキルと機能マップ)、evalをスキルの単体テストとして使って改善を続け、その後にクラウド上のBennyによるバグ報告の自動再現へ広げた。
エンジニアの役割はシェフに近い。もはやすべての料理を自分で作るのではなく、環境を設計し仕事を割り振る。出発点はローカルで、エージェントの操作を目で確認できるからだ。信頼ができてからクラウドや自動マージへ拡大する。
制約は強制的に実行できてこそ信頼できる。Duneはシステムとして、useEffectとコードコメントを禁止し、CIでmainとrendererのインポート境界を検査し、「最短経路が最良の経路」という規約ベースのアーキテクチャでエージェントを導く。rules、skills、bugbotはあくまで緩い補助にすぎず、人手のレビューで初めて見つかった問題はすべてlintやCIのルールに変えるべきだ。
tokenの支出は投資対効果の問題だ。事前のリファクタリング(600個超のPR)には大量のtokenがかかったが、最も賢くないエージェントでもうまくこなせるようになり、PMやデザイナーまで安全に貢献できる。ただし彼女の所属するラボはtokenに制限がなく、全員に同じことを求めることはできない。

2026年9月15日Vision Sabbat再生時間 55:04

▶ YouTubeで元動画を見る

セクション別要約

0:25AIへの圧力と、仕様優先の最初の実験
彼女は、AIの最良の使い方は一緒にコードを書く相棒として使うことであり、コーディングの代替や思考の外注ではないと考える。多くのエンジニアはAIを使いこなしていると見られたくて、毎週100個のPRを出すという圧力を受けている。彼女自身の経験では、AIでコードを書く時間は減るものの、レビューと修正にかえって多くの時間がかかった。先にAIに仕様を書かせ、仕様をレビューしてから開発するという流行の手法も試した。
▶ ここから見る
1:25信頼、長年の蓄積による見解と曲線
軸は信頼だ。シニアエンジニアは多くの見解を積み重ねており、エージェントが当て推量をしたり幻覚を起こしたりし、さらに根本原因を見つけたと断言するのを見ると信頼が失われる。信頼が足りなければエージェントの価値を引き出せず、部下を信頼できないマネージャーがマイクロマネジメントに陥るのと同じだ。約1年前、まだエージェントでコードを書く人がほとんどいなかった頃は、少数のエージェントに張り付くしかなく、並列化できなかった。過去5か月で信頼曲線を登り、今ではエージェントがPRを自動マージし、目覚めると20個のPRがすでにメインラインに入っていて品質も悪くない。彼女のコントリビューショングラフはこの曲線と対応している。1か月目は成果が低く、先月マージしたPRの数は驚くほどで、今月は12日までにすでに800個近い。
▶ ここから見る
5:55検証が最も重要な能力
エージェントのワークフローで最も重要なスキルは検証だと彼女は考える。エージェントはコードを実際に実行し、CPUトレースやheap snapshotを取得し、iOSシミュレーターを開き、ユーザーのように実際に操作してテストできなければならない。これでループが閉じる。良いコードを書く保証にはならないが、少なくとも正しいコードは書ける。信頼を築くうえで大きな一歩だ。
▶ ここから見る
7:25Cursorでの経歴と、エージェントに画面を見せる方法
彼女は5か月前にCursorに入社した。当初はクラウドエージェントのチームに入る予定だったが、React経験があったため、同じくReactアプリであるagents windowの支援に回された。最初の週、Chrome DevToolsのフレームグラフは彼女自身にも読めず、エージェントにも読めず、自信満々に原因を適当に指摘するだけだった。検証スキルがなければ人間がボトルネックになり、スクリーンショットやエラーメッセージを自分でコピーしてエージェントに渡すことになる。そこで彼女はcontrol glassスキル(Glassはagents windowの社内コードネーム)を作り、Chrome DevTools ProtocolやAppleのシミュレーターツールを通じてアプリを操作することをエージェントに教えた。しかしエージェントは操作はできても、ウィンドウ内にどんな機能があるかを知らないため、追加で機能マップが必要になった。
▶ ここから見る
11:40機能マップ、Pstack、スキルの評価
機能マップには、各機能への到達方法、キーボードショートカット、CDPで使う選択用の属性が並んでいる。これにより、エージェントはスクリーンショットに疑問符だけという品質の非常に悪い報告でも、機能と結び付けられる。Pstackプラグインには、検証スキルを作成・保守する機能が付いている。Pstackという名前は、Y Combinator CEOのGary TanのGStackをからかったもので(二人は同姓だが無関係)、事前に計画したものではなく、エージェントの失敗パターンを観察し、一つずつスキルとして書き起こして積み上げた結果だ。スキルの実体はmarkdownで、予備知識のない新人に教えているのと同じだ。スキルの保守にはevalを使う。つまりエージェントの単体テストだ。調整役のエージェントが採点基準を決め、複数のサブエージェントを送り出し(評価されていることを意図的に知らせない)、さらに別のモデルの審判エージェントがクロスチェックし、満点の10点になるまでループを回し続けることもできる。ただし彼女は、スキルの保守は難しく、センスと観察が必要だと率直に認めている。
▶ ここから見る
22:35シェフの比喩：ローカル導入からクラウドエージェントへ
彼女はシェフの比喩で役割の変化を説明する。エンジニアはもはやすべての料理を自分で作るのではなく、キッチンの環境を設計し、チームに仕事を割り振る。導入はローカルから始める。エージェントがCLIやデスクトップアプリを起動し、どうインターフェースを呼び出して操作するかを見られるからだ。彼女自身は主にクラウドエージェントに賭けており、Bennyという名のエージェントがすべてのバグ報告を引き受け、クラウド上のデスクトップでCursorを実行し、同じ制御スキルで問題を再現する。たとえば表示エラーの報告について、再現はできるがメインラインでは修正済みで、新バージョンを出せばよいだけだ、といった具合だ。これでチーム全体が恩恵を受けるが、まず信頼を築く必要があり、クラウドエージェントを一度に大量に起動してtokenを無駄にしてはならない。
▶ ここから見る
27:15振り返りと、盲目的に信頼しないこと
インタビュアーは道筋を振り返る。まず検証スキルを作ってコードが少なくとも正しいことを確認し、ローカルで信頼を築いてからクラウドに広げ、エージェント自身に報告を引き取らせてPRを提出させ、最後に自動マージ、さらにメインラインでのレビューへ進む。彼女はこれに同意し、この道に近道はないと言う。信頼は個人の基準によるからで、誰にも自分を盲目的に信頼してほしくないとも述べた。プラグインで立ち上がりは早くなるが、各自が自分のスキルセットに作り変え、自分のエンジニアリング基準をスキルに書き込み、エージェントが確かに守っているかを検証することを勧めている。
▶ ここから見る
29:35書き直しをめぐる論争とコードのドリフト
彼女は、書き直しは検討に値すると主張する。既存プロジェクトにすでにフレームワーク、規約、ガードレールがあれば、エージェントはかなりうまくこなせる。大企業は能力が最も低いエンジニアを支えるため、こうした制約をとうに整えているからだ。新規プロジェクトこそ最大のリスクであり、最大のチャンスでもある。ゼロから開発したGrockbotを例に挙げると、完全にvibe codingで、人がコードを読んでいない状態ではガードレールが一切なく、エージェントは最も手軽な方法でタスクを片付けるため、コードは時間がたつと制御不能になる。そこで彼女は600個を超えるPRをかけてGrockbotを新しいアーキテクチャにリファクタリングし、今ではほとんどコードを見ていない。これには大量のtokenがかかったが、デザイナーやPMなど非エンジニアも安心して機能を追加できるようになった。CIに多くの制約があり、エージェントがコーディングの面倒を引き受けているからだ。
▶ ここから見る
35:25大規模な強制実行とPRの大きさ
CIとPRの大きさについて問われると、彼女は厳格な上限はないと答える。大きさは約50行から始まり、内容次第でもっと大きくなってよい。たとえば大量のファイルを削除するPRは、ほとんどが削除だ。それでもエージェントには作業を複数のPRに分けさせ、各PRには単純な小さな変更だけを記述させる。こうすればgit履歴が豊かな文脈になり、元に戻すのも容易で、40000行のPRに何が詰め込まれているか分からないという事態も起きない。ちなみに、GrockbotとCursorの仮想化は新しいライブラリPretextで動いている。
▶ ここから見る
38:15Duneと規約ベースのアーキテクチャ
DuneはGrockbotのアーキテクチャの社内コードネームで、Electronアプリ向けのNext.jsのようなものと考えられ、エージェントのコーディング用に設計されている。そのCIのチェックは煩わしいほど多い。useEffectを禁止し、コードコメントも禁止する。彼女が気づいたところ、エージェントが書くコメントは99%の時間、プログラムと無関係な経緯の説明だったからだ。Electronのrendererは60 fpsを維持する必要があり、1フレームを16ミリ秒以内に終えなければならない。うっかり重い計算をrendererに持ち込むとカクつくため、こうした経験をフレームワークに書き込み、強制的な失敗とした。electron mainとelectron rendererのディレクトリを分け、CIで依存グラフを検査し、ディレクトリをまたぐインポートを禁止する。彼女は、最も強力な強制層は規約ベースのアーキテクチャだと考える。エージェントは既存のパターンを真似るのが好きだからだ。たとえば一つの機能のコードをすべて同じディレクトリに置けば、約80%の作業がおおむねその中に収まる。
▶ ここから見る
43:35最短経路、境界、緩い規範
彼女の第一原則は、最短経路が最良の経路であることだ。エージェントは近道を取りたがるので、最も速いやり方が最良のやり方になるようにするほうがよい。このフレームワークは一連の考え方と原則にすぎず、オープンソース化はしない。強制は複数の層に分かれる。CIのチェック、観察した悪いパターンに対して書いたlint、コンパイラ診断はいずれもCIを赤くするため、強制的な制約だ。rules、skills、bugbotは緩く、エージェントが忘れる可能性があるため、重ねて使うしかなく、それだけに頼ってはならない。さもなければコードはいずれゴミになる。技術選択も重要で、たとえばRustのコンパイラは厳格なので、unsafeブロックを禁止すれば、コンパイルが通ることである程度の自信が持てる。毎回、人がコードレビューで制約を指摘しているなら、それは悪臭であり、lintルールやCI失敗に変えるか、問題を根本から取り除くべきだ。
▶ ここから見る
49:45tokenの投資対効果と、プロダクトとの歩調合わせ
エンジニアリングマネージャーにとって、tokenは投資対効果の問題だ。事前にコードをリファクタリングし制約を整えるには大量のtokenがかかるが、エージェントがコードを書くなら、10000人のエンジニア組織に育てる必要はない。これらはエージェント時代以前なら、彼女が一人でやれば何年もかかったことで、そのため取捨選択は、人を雇うか、tokenを使って最も賢くないエージェントでもうまくこなせるようにするか、になる。彼女は、自分の所属するAIラボはtokenに制限がなく、全員に同じことを求めることはできないとも率直に認めた。プロダクトなどの部門がどう追いつくかと問われ、彼女はGrockbotが鍵だと答える。インターフェースがiMessageのようで、非技術者でも気軽にエージェントを使え、PMやデザイナーが修正を直接提出することさえある。彼女がレビューして完璧だと思えばそのまま承認しており、Duneアーキテクチャの厳格な制約によって、専門家でない人も高い水準で貢献できることを示している。
▶ ここから見る