2026年のBencher開発：オープンソース、自己資金、そしてエージェント沼
Everett Pompeii
このエッセイは、もともと2026年10月4日にThe Pragmatic Engineer’s How Software Engineering is Changing Essay Challengeへ応募したものです。
今年、私のソフトウェアの作り方は根本から変わりました。私はスタッフソフトウェアエンジニアです。この6年間、YCとa16zが出資するユニコーン企業と、Fortune 500企業の両方で、仕事としてRustを書いてきました。C++からのリハビリ中の開発者として、Rustが求める奥深さと技量に惹かれていきました。リアルタイムシステムソフトウェアを手作業で彫り上げる熟練の職人になっていたのです。しかしこの10か月で、私はそのアイデンティティを葬らなければなりませんでした。肩書きは今も「ソフトウェアエンジニア」ですが、私の仕事は今や「コンテキストエンジニア」のそれです。
この4年間、私は夜と週末を使って、オープンソースで自己資金のビジネス、Bencherを作ってきました。Bencherは、システムソフトウェアエンジニアがパフォーマンス回帰をマージ前に検出できるようにする継続的ベンチマーキングプラットフォームです。これを実現するには一連のツールが必要です。CLI、APIサーバー、そしてフロントエンドのWebコンソールUIです。これらのコンポーネントはどれも、誤差の範囲で、すべて私が書きました。長年の間に何人か注目すべきオープンソースコントリビューターがいましたが、オープンソースプロジェクトとしてのBencherの大部分と、ビジネスとしてのBencherの100%は、私自身が設計し実装したものです。
この4年間、私はただ浮世離れした暮らしをしていたわけではありません。婚約し、結婚し、第一子が生まれました。大きな機能を実装してリリースするまでに、数週間、時には数か月かかりました。開発とサポートを両立させなければなりませんでした。Bencherにはすでに多くのユーザーがいたので、質問に答えたり、たまに出てくるバグを直したりすることにかなりの時間を費やしていました。
2022年当時、私のLLMの使い方といえば、TabNineのRust向けフリーウェア版くらいでした。TabNineは、Codexという名のちょっと変わった小さなプロジェクトに取り組んでいたOpenAIの初期インターンでもある学生が作った、Tabキーで補完する開発者ツールです。GitHub Copilotがローンチされ、非公式にRustをサポートし始めると、私は奮発して月10ドルの個人ライセンスを購入しました。
荒削りでした。それでも、ちょっとした魔法のように感じられました。GitHub CopilotのVSCode拡張機能にチャットが追加されて間もない頃、Rustの手続き的マクロを作るのがあまりにも上手くて驚かされたのを覚えています。たいていは出力を多少手直しする必要がありましたが、何度かは一発で完璧に書き上げてくれました。ヤバすぎる！これはクールでしたし、多少の時間短縮にもなったのでしょうが、私の仕事の進め方は基本的に以前と変わりませんでした。
それ以来、私は「MicrosoftはGitHub Copilotで最先端を走っている」という考えを持つようになりました。新興のAIラボが「エージェント」なるものを世に出していても、価値のあるものならGitHub Copilotがちゃんと追いつくだろうと信じていられました。Lenny’s PodcastでDan Shipperのような人たちの話を聞いても、彼らが語るモデルの能力は、私の経験とも品質基準とも噛み合いませんでした。
昨年の初め、私はBencher開発の3年間を振り返る記事、エンジニアリングレビュー：2025年版を書きました。その記事では、フロントエンド、バックエンド、開発環境、CIなど、Bencherを作るうえで下したエンジニアリング上の主要な決定をすべて取り上げました。2年前にCUE langを理解しようとしてどれだけ苦労したかの愚痴に、丸々1段落を費やしたほどです。それなのに、3,500語に及ぶあの記事のどこにも、AIやLLM、さらにはCopilotについてさえ、一言も触れていないのです。
それから1年も経たない今、私はWe mourn our craftに共感し、一緒に嘆いています。
Claude、クリスマスを救うのに一役買う
多くの人と同じように、2025年の冬休みに私はClaude Opus 4.5をじっくり使う機会がありました。私は妻と子どもと一緒に、ロンドンにいる妹の家族を訪ねていました。妹は双子を出産したばかりだったので、私は手伝いに行っていたはずでした。ところが実際には、2階にこもって、Bencherに対するスパムメールやDDoS攻撃と戦っていたのです。何が起きているのかを診断し、解決策のアイデアを出すうえで、Claudeは非常に頼りになりました。
最終的に、BencherをCloudflareの背後に移行し、reCAPTCHAを導入しました。作業の大部分はまだ私自身がやっていましたが、多くの相反する設計上の制約をまたいで問題を解決する能力において、Opus 4.5ははっきりと一段上でした。とはいえ、Opus 4.5が提案した変更のせいで、Bencher CLIをインストールするための便利スクリプトが半日ほど使えなくなったこともありました。おっと。
新年、新ハーネス
今年の1月の時点で、Claude Codeがいかにすごいかという話を、私はもう何か月も聞かされていました。それまで試すのを控えていたのは、Opus 4がその仕事を信頼できるほど私の品質基準を満たしていなかったからです。Opus 4.5がその基準をクリアした今、Claude Codeも試してみたくなりました。ハーネスとしてCopilotからClaude Codeに乗り換えたときに感じた進歩の大きさは、モデルとしてOpus 4/GPT-5.2/Gemini 2.5 ProからOpus 4.5に乗り換えたときの飛躍とまったく同じくらいでした。
Claude Codeを使い始めた最初の週末、私はCopilotを相手に、あまり統制の取れていない比較テストをしました。CopilotにはPDFをオーディオブックに変換させようとしました。「Agent Mode」でさえ、Copilotは5、6ステップ進んだところで止まってしまい、私がもう一度つつくまで動きませんでした。同じ頃、Claude Codeは入念なPlan modeを経たうえで、独自のハイパーバイザーを作ろうと猛烈に作業を続けていました。抽象化のレベルはモデルからハーネスへと移ったのであり、Copilotが再び追いつくことはもうないだろうと、私は完全に確信しました。
Bencher Bare Metalを夢見て
Bencherのごく初期の頃から、私はベアメタルのベンチマーキングフリートを作ることを夢見ていました。従来のCIランナーは、仮想マシンであるがゆえにノイズが多すぎて、一貫したベンチマーク結果を得られません。たとえばレイテンシの200%増加なら検出できるかもしれませんが、20%の増加を確実に検出することは決してできないでしょう。CIでベンチマークを行う方法の1つとして、命令数があります。命令数はほぼ決定的です。しかし、命令数はあなたが本当に気にしているもの、つまり実時間の代理指標にすぎません。「CPUシミュレーション」の中で実行して命令数を出力するものは、どれも速度と相関するだけです。問題は、実際にベアメタル上で測定しない限り、それがどれだけずれているのか、あるいはずれていないのかが決してわからないことです。
Bencherの最初期のユーザーの1つが、Rustlsプロジェクトでした。私も彼らのRustlsベンチランナーにコントリビュートしました。しかし、これはベアメタルのベンチマーキングフリートを構築する土台としては良いものではありませんでした。単一のホスト上で動いており、すべてのベンチマークワークロードを信頼済みとして扱っていたのです。つまり、フォークからのPRは受け付けられず、マルチテナンシーもありません。それに、ほとんどのチームは、ベアメタルのベンチマーキングサーバー1台につき月100ドル以上も払いたくはありません。
オーケストレーション層にGitHub Actionsを使うことも検討しましたが、このアプローチにはいくつかの根本的な欠点がありました。まず、GitHub Actions RunnerはC#で書かれています。つまり、実行の途中でガベージコレクタが動き出し、ベンチマーク結果を歪めてしまう可能性があります。ああ、それから実行中に動き出さないよう自動アップデーターは必ずオフにしておきましょう。でも、オフにしたまま放っておきすぎるのも禁物です。さもないとジョブが動かなくなりますから！
仮にGitHub Actions Runnerが静かで行儀の良いRustバイナリだったとしても、より根本的な問題は、それがGitHub Actionsに縛られていることでした。Bencherは最初からCLIファーストです。良くも悪くも、私はBencherを特定のCIプロバイダーに深く結びつけたくありませんでした。Bencher CLI GitHub Actionはありますが、それがやるのはCLIをインストールすることだけです。Bencher Bare Metalは、GitHub Actionsからだけでなく、CLIが動く場所ならどこからでも使えるようにしたかったのです。
私が思いついたアイデアは、OCIイメージを使ってベンチマークのワークロードをまとめ、オプションのごく小さなサンドボックスを使って、特定のベアメタルホスト上では常に一度に1つのジョブだけを実行するというものでした。これを夜と週末だけで一人で作り上げることを考えると、気が遠くなりました。本業と家族を抱えながら一人でコツコツ進めていたら、少なくとも1年はかかったでしょう。
Bencher Bare Metalを作る
今年の1月、Opus 4.5とClaude Codeを手にして、ようやくBencher Bare Metalを作り上げるための現実的な道筋が見えたように感じました。私はまたしても奮発し、今度はClaude Max 20xプランに月200ドルを払いました。おそらく史上最高の経費です。
私は猛烈に作業を始め、毎週Claudeプランの使用量を使い切ろうと全力を尽くしました。Bencherでも本業でも、手でコードを書くのをやめました。この時点ではまだ、かなり短いループで反復しており、Plan modeを使い、出力をすべて読み、Accept editsモードで実行していました。この頃はまだエージェントにgit/jjを触らせるほど信頼していなかったので、バージョン管理はすべて自分でやっていました。自分のことを、人間が介在するRalph Loopだと思っていました。エージェントを5つほど並列で動かすと、脳がとろけ始めるのでした。
耳にした提案の1つに、実装とレビューを別々のエージェントにやらせるというものがあったので、敵対的レビューを別に行うようにしました。この敵対的レビューは、出力の品質向上に本当に役立っているように見えました。私は自分のClaude CodeサブスクリプションのAPIキーを使うGitHub Actionsのレビューボットを自作しました。そしてローカルのエージェントにこのCIレビュアーとやり取りしながら反復させ、ローカルマシンの負荷を節約しました。
その途中のある時点で、私はベンチマーキング用サンドボックスのためにClaudeに独自のハイパーバイザーを作らせようと考えていました。そこでClaudeに、Linus Torvaldsとしてその計画を敵対的にレビューするよう頼んだところ、お前はバカだ、これはとてつもなく、とてつもなく、とてつもなくアホなアイデアだと言われました。コンテキストにLinusがいれば、おべっかは一切なし！というわけでその計画は破棄し、Firecrackerを採用しました。
良いベンチマーキングの敵は、速度そのものではなく、ばらつきです。ですから、Firecrackerはハイパーバイザーとしてオーバーヘッドを加えるものの、そのオーバーヘッドは非常に一貫しています。特に、常に一度に1つのmicroVMしか動かさない場合はなおさらです。これにより、共有のBencher Bare Metalランナーは、マルチテナンシーと非常に一貫したベンチマーク結果の両方を実現できます。また、Plan modeを使ってClaudeと一緒に、サンドボックスをオプションにする設計にしました。ユーザーがすべてのワークロードを信頼できる自前の専用サーバーで実行したい場合は、Firecrackerなしで、ほぼゼロのオーバーヘッドで実行できます。
Bare Metalのrunnerの開発は、エージェントにとって短いフィードバックループがいかに重要かを学ぶ大きな教訓になりました。Opus 4.6が出た後でさえ、Claudeはすべてを安定して動かすのに苦労しているようでした。KVMが有効な開発環境（Firecrackerの実行に必要です）へのアクセスを与えると、物事が本当にうまく回り始めました。これらのエージェントは全知ではありません。ただ、ものすごく粘り強いだけなのです。
Claudeの仕事をどれだけ厳しく精査するかは、コードベースのどの部分を扱っているかによって変えていました。OCIレジストリやrunnerバイナリのように、純粋にBare Metalのためだけのコードは、軽くレビューする程度でした。敵対的レビューを通過し、エンドツーエンドテストが通り、見た目がそれほどひどくなければ、マージしていました。既存のコア、つまりジョブのキューイングやレポート処理に触れるコードについては、相変わらず細かいところまで口うるさくチェックしました。
今年の3月末、私はBencher Bare Metalをv0.6.0の一部としてリリースしました。公開ベアメタルフリートには、AWS EC2 Bare Metalの利用を検討していました。しかし、これらのマシンは巨大なうえにARMのみです。現実世界のほとんどのワークロードに合わせるため、私は庶民派のIntel x86マシンが欲しかったのです。設計上の制約を満たすフリートの最適な置き場所を、Claudeと一緒にリサーチしました。その結果、Bencher Cloudでintel-v1 Specを提供できるようになりました。4 vCPU、48 GBのメモリ、128 GBのディスクを分単位の課金で使えます。うまく構成されたベンチマークでは、フリート全体で実行間のばらつきは一貫して<2%でした。
エージェントの認証
Bencher Bare Metalまでは、認証はすべてJWTでした。大きくて、美しくて、理解不能なJWTです。Bare Metalランナーの認証には、名前のプレフィックスが付いたAPIキー、たとえばbencher_runner_abc123...を使いました。
クライアント側では、ユーザー自身のAPIトークンであるJWT以外に、エージェントが扱えるものを用意したいと考えました。そこで私が落とし所として選んだのが、長く要望されていた機能、プロジェクトスコープの認証をついに実装することでした。Claudeの助けを借りて、安全な、プロジェクトスコープでプレフィックス付きのAPIキーを作りました。これらのAPIキーの権限は、bencher run CLIコマンドが行う操作と同等のもの、つまりプロジェクトスコープの読み取りと非破壊的な書き込みに限定されています。これにより、これらのAPIキーは継続的ベンチマーキングのCIワークフローで使うのにもぴったりなものになっています。
その後、Bencher MCPを追加した際にも、これらのプロジェクトスコープのAPIキーをそこでの認証に使いました。MCPの標準はOAuth 2.1を指定していますが、OAuth 2.1はまだドラフト段階なので、今はまだ実装したくありませんでした。正直なところ、私はちょっとしたMCP懐疑派です。サービスをエージェントに公開するなら、良いCLIとスキルの組み合わせのほうが、より効果的でポータブルな方法だと今でも思っています。とはいえ、CLIの最大の問題は、標準的な認証の仕組みがないことです。ですから、OAuth 2.1がまだドラフトだとしても、少なくともMCPはその点をカバーしています。そして、優れた認証の仕組みはエンタープライズにとって本当に重要なのです。
多言語使いのClaude
2023年、私はBencherのドキュメントを9つの言語で提供することに決めました。英語、中国語、スペイン語、ブラジルポルトガル語、ロシア語、日本語、フランス語、ドイツ語、韓国語です。どうやってこの9言語を選んだのか？GitHubのドキュメントが対応していた言語だったので、それで十分な目安になるだろうと考えたのです。唯一の問題は、私が流暢に話せるのは英語だけだということでした。そこで、GPT-4にドキュメントを翻訳してもらいました。当時のGPT-4のコンテキストウィンドウはわずか8kトークンでした。つまり、ドキュメントのページをすべて、8kトークン未満の「チャンク」に分割しなければなりませんでした。さらに、チャンクの翻訳と、更新後のチャンクの（非常に頻繁な）再翻訳を処理するためのCLIツールを作らなければなりませんでした。
これは非常に面倒で、ミスの起きやすいプロセスでした。システムプロンプトでかなり明示的に指示しても、モデルはインポートパスを台無しにしたり、すべてをもう一層のMarkdownブロックの中に入れてしまったりしたので、翻訳されたファイルを手で編集しなければなりませんでした。なぜか特に日本語でよく起きました。
Opus 4.5でClaude Codeを使い始めると、こうした問題はすべて消えました。今ではエージェントがただやってくれます。何をチャンクとするかの規約はコードベースの中にあり、Claudeはそれにただ従います。Bencher Bare Metalの技術ドキュメントを書いていたときも、チャンク分けと翻訳のオーケストレーションはClaudeがそのまま処理してくれました。今やコンテキストサイズはページ全体を扱えるほど十分に大きくなりましたが、私はチャンクがあるのが気に入っています。変更を局所化しやすいので、改訂の際にはページの関連するセクションだけが再翻訳されるのです。
2026年にハーネスを作らなかった人なんている？
Bencher Bare Metalを作りながら、私はClaudeに、フリートを管理するための自分用のツールも作らせました。これは2つの部分から成ります。日常的なタスクのためのbencherリポジトリ内のCLIと、新しいメタリポジトリ（メタリポ）です。このメタリポには、製品としてのBencherに関するすべてのドキュメントとコンテキストが入っています。bencherdev GitHub組織の他のすべてのリポジトリは、このメタリポのサブモジュールになっています。メタリポのおかげで、エージェントは複数のリポジトリにまたがるかもしれないタスクにも簡単に取り組めますし、私が公開したくないドキュメント（製品戦略、インシデントレポートなど）も書けます。
私はClaude Code CLIの上に自分のエージェントを作り、このメタリポを単なる成果物から、開発サイクルの能動的な一部へと変えたいと考えました。Fable 5が使えるようになると、私はこのエージェントの開発に多くの力を注ぎました。このエージェントを信頼して自律的に動かせるようにしたかったのです。その大きな部分を占めたのがセキュリティ（つまりプロンプトインジェクションの緩和）でした。ワーカーエージェントが一切シークレットを保持しないように設計しました。すべてのシークレットはネットワークプロキシによって注入され、許可リストに載ったエンドポイントに制限されます。エージェント自体は、さらに別のFirecracker microVMの中で動かしました。今回は並列実行ありです。エージェントのコントロールボックスと、ネットワークプロキシとサンドボックスは、まったく別のホストで動いていました。
私の壮大なビジョンは、インターフェースをタスクの優先度順に並んだキューにすることでした。つまり、このエージェントの目標は、その瞬間に最も重要なタスクを私に示すことです。Facebook/Instagram/Twitter/X/TikTokのフィードがエンゲージメントに最適化されているのに対して、このフィードは私にとっての重要度に最適化されます。
私は、自分自身をAPIの下に置くツールを作りたかったのです。私は、自分の時間の大半をコンテキストスイッチとスレッド間の行き来に費やしていることに気づいていました。エージェントが物事の優先順位を付けてくれれば、このジャグリングを軽減できるのではないかと期待していました。Redditのようなアップボート/ダウンボートの仕組みを使えば、新しく届いたSlackのメッセージが本当に私が今最も注意を払うべきものなのかどうかを、エージェントに学習させられます。
また、今の私の仕事の多くは、エージェントにとってのRubeus Hagrid、つまり「鍵の番人」であることだと気づきました。許可エンドポイントを制限したネットワークプロキシのレベルで注入するというのが、エージェントにシークレットへのアクセスを一切与えず、それでいてgh CLIのようなツールをそのまま使えるようにするために、Claudeと私が考えついた最善の方法でした。
もう1つの主要な目標は、エージェントのインターフェースから決して離れないことでした。どんな理由であれ、エージェントから離れて他の場所に移動しなければならないなら、それはハーネスの失敗と見なされます。私は手続き的なUIコンポーネントシステムを作り、タスクに取り組むエージェントが、その場で新しいインターフェースを組み立てたり、目の前のタスクに応じてライブラリ内の既存のコンポーネントから選んだりできるようにしました。コード、メール、Slack、カレンダー、本番環境のテレメトリデータ、エラー監視、そのすべてが1つのインターフェースに、1つの優先順位付きキューにまとまるのです。
これらすべての最小限のバージョンは動くようになりました。しかし、まだ粗削りな部分がたくさんあります。今のところは、Claudeデスクトップアプリを使うだけのほうがずっと生産的です。そして今この瞬間、需要に追いつくためには、すぐに得られる生産性ができる限り必要なのです。
開発者の数が100倍になったら何が起きるのか？
2022年、私は新しいサイドプロジェクトを探していました。それより前の起業家気取りの挑戦は、2020年にたたんでいました。ライフハック：Jason Cohenの言うことを聞きましょう。マーケットプレイスを自己資金で立ち上げようとしてはいけません。
本業ではRustで静的なbashパーサー兼アナライザーを作っていたのですが、ベンチマーク結果を追跡するのにスプレッドシートを使わなければならないことに気づきました。Rustプロジェクトには、コンパイラ自体のパフォーマンスを追跡するためのrustc-perfがあります。それなのに、自分のコードで同じことをするための良いツールはありませんでした。
私はこの分野の先行事例をかなり調べました。数か月かけて、継続的ベンチマーキングツールを自作した、あるいは作るべきだと提唱していた何人もの開発者と通話しました。誰もが車輪の再発明をしていました。私は、市場という川の流れの中に、静かで居心地の良い淀みを見つけたと思いました。明らかで、継続的なニーズがありました。多くのチームが、自前のベアメタルランナーにすでに月100ドル以上を払っていました。つまり、お金を払う意思はあったのです。とはいえ、ユースケースはニッチでした。現代のソフトウェアのほとんどはサービスとしてデプロイされるので、パフォーマンステストをシフトレフトすることは、ほとんどのチームにとってそれほど優先度が高くありませんでした。デプロイ後にGrafanaでアラートを設定して、すり抜けたものを事後に捕まえるだけで済ませていたのです。
しかし、非常に有能なエージェントが登場したことで、2つの要因がBencherの利用を大きく押し上げました：
- エージェントの出力を決定的にテストするために、ソフトウェアエンジニアリングのベストプラクティスを採用する必要性
- エージェントの助けによって、ソフトウェアエンジニアリングのベストプラクティスを採用するのが容易になったこと
LLM、そしてその延長としてのエージェントは、非決定的で確率的なシステムです。人間の開発者と同じように、コード品質を維持するためにはガードレールが必要です。そのための方法は新しいものではありません。堅牢な型システム、標準のフォーマッター、目盛りを11まで振り切ったリンター、そしてテスト、テスト、さらにテスト。すべてCIで実行します。パフォーマンスが重要なワークロードでは、こうしたテストに、追跡されるベンチマークも含まれます。ソフトウェアのパフォーマンスを時系列で追跡すれば、CIでパフォーマンス回帰を検出できます。これを継続的ベンチマーキングと呼びます。継続的ベンチマーキングの導入は、昔から少々面倒な作業でした。パフォーマンスを本当に、本当に気にかけているチームだけがそれをやっていて、そういうチームは素晴らしいBencherユーザーになってくれました！
しかし、エージェントの登場によって、Bencherを使って継続的ベンチマーキングをワークフローに追加する手間は、短いプロンプト1つで済むものになりました。完全に追跡するのは難しいのですが、今ではBencherへのインバウンドのサインアップの大部分が、エージェントの推薦か、エージェント自身による登録から来ていると私は踏んでいます。より多くの開発者がエージェントを採用し、エージェント型コマースで権限を与えるようになるにつれて、この傾向はますます強まるでしょう。それがx402プロトコルになるかどうかはわかりませんが、将来の開発者ツールへの支出の多くはエージェントを介して行われるようになると思います。まだであれば、Cloudflare WalletとStripe Walletを確保しておくことをおすすめします。
エージェント時代には、ほぼすべての開発者ツールが従量課金制に移行する必要があるでしょう。サービスを使うのがエージェントであるなら、シート単位の課金は意味をなしません。Bencherは昔から従量課金制です。しかし最近、Claudeの助けを借りて、料金モデルをさらにエージェントフレンドリーなものに刷新しました。以前、Bencherはメトリック単位で課金していました。メトリックとは、ある単一時点でのベンチマーク結果です。たとえば、1つのベンチマークを5回実行すると、5つのメトリックが作られます。Claudeは、ユーザーのフィードバックと利用パターンの分析を手伝ってくれました。その結果、従量課金モデルで使っていた単位を変える必要があるという結論に至りました。現在、Bencherはベンチマークシリーズ単位で課金しています。ベンチマークシリーズとは、時系列で追跡されるベンチマークのことです。先ほどの例に戻ると、1つのベンチマークを5回実行した場合、それは1つのベンチマークシリーズです。この新しい料金モデルにより、ユーザーはコストをはるかに予測しやすくなります。エージェントに最適化問題を渡せば、追加コストを一切かけずに、過去のベンチマークに対して山登り法で改善を重ねていけます。
この1年で変わらなかったと感じることの1つが、オープンソースへのコントリビューションです。Bencherには、AIスロップなPRがいくつか届きました。これらのPRの主な問題は、作業の途中でたまたま見つけた、無関係なバグをあれこれ修正していたことでした。とはいえ、それらは本物のバグでした！なので私は、まあいいかと肩をすくめて、もちろん自分のエージェントにレビューさせたうえで、それらのPRをマージしました。少し寂しいことですが、もはやオープンソースのコントリビューターを呼び込むことに大きなメリットは感じていません。彼らのトークンであれ私のトークンであれ、コードのレビューにかける労力は同じだけ必要です。今では、コントリビューターのPRをレビューするほうが、自分でClaudeと反復するよりもはるかに多くのエネルギーを使うのです。
継続的ベンチマーキングの未来とは？
未来に何が待っているのかを占おうとするとき、どうやらフロンティアラボ自身が何をしているのかを見るべき、というのがお決まりのパターンのようです。6か月から12か月もすれば、私たちも皆そこにたどり着いているようですから。The Pragmatic EngineerのInside OpenAI’s agentic software factoryは、継続的ベンチマーキングの観点からこの点に興味深い光を当てています：
新登場：「perfハーネス」：エージェントはperfハーネスも使い、 問題のあるPRをSynthetics A/Bフレームワークに送ってパフォーマンスへの影響を評価する。 前述のとおり、CIシステムへの負荷はこの6か月で大幅に増加している。
OpenAIの「perfハーネス」は、相対的継続的ベンチマーキングという確立された手法とよく似ているように見えます。AIならではの新しい部分は、A/Bフレームワークの合成（Synthetics）の部分です。合成テストデータ自体は新しいものではありません。しかし、目の前の変更セットのパフォーマンスを評価するために、その合成データを自律的に形作れるというのは、間違いなく新しいことです！開発者に実際にベンチマークを書いてもらうことは、昔からずっと苦労の種でした。それが今や自動化されています。エージェントが機能テストのカバレッジを劇的に高めてきたのと同じように、パフォーマンステストのカバレッジも劇的に高められるようになりつつあるのです。
この取り組みをしているのはOpenAIだけではありません。そのすぐ後に、AnthropicもHow we made claude.ai 3x faster in two weeksを公開しました。その中で彼らも、その場でベンチマークを作ることについて述べています。重要な違いの1つは、Anthropicがパフォーマンスと相関する決定的なカウントを見つけたことです。命令数、インタラクションあたりのコミット数、関数呼び出し、スタイルの再計算、DOMミューテーションです。そしてClaudeは、アプリのパフォーマンスを最適化するために、これらのカウントを山登り法で改善していきました。最適化パスの最後には、カウントに基づく最適化が実際に現実世界の実時間の改善につながったことを確認していました。
これらの手法は、私がBencherの開発で個人的に経験してきたことと一致しています。とはいえ、私のA/Bパフォーマンステストはすべて、CIループの中ではなく、ローカルかエージェントの作業マシン上で実行してきました。クエリに大きな変更を加えたり、意味のあるスキーママイグレーションを行ったりしようとするときは、毎回Claudeにその変更の徹底的なパフォーマンス評価をさせています。これには必ず実時間が含まれ、ときにはそれに付随する決定的なカウント（例：SQLite仮想マシンの命令数）も含まれます。
ノイジーネイバー問題のせいで、こうしたエージェント主導のパフォーマンス最適化パスには、かなり広いエラーバーが付いていました。私は、Bencher Bare Metalにフィクスチャ（追加のベンチマーク入力）とアーティファクト（追加のベンチマーク出力）を追加して、エージェントがこうしたパフォーマンス最適化タスクをより高い信頼性で実行できるようにしようとしています。エージェントは引き続き最適化作業の大部分をローカルで行い、実時間や決定的なカウントについて、できる限り山登り法で改善していきます。そのうえで、一種の実時間を測るノギスとしてBencher Bare Metalを使い、自分の仕事を検証するのです。
1年かそこらでBencherの「ユーザー」のほとんどはエージェントになると思っていますが、それでも人間の多くは、様子を確認するときに視覚的なインターフェースを求めるだろうと思っています。私は今、Claudeの助けを借りて、Bencher UIの全面的な再設計にどっぷり浸かっています。GitHub CopilotのTab補完の時代にAnyscriptを書いていたRustエンジニアとしては、現在のUIには改善の余地がたくさんあります。とはいえ、UIの書き直しは、さらに野心的な別の大改修、つまりBencher Metric Format (BMF)の新バージョン待ちになっています。
BMFは、Bencher内でベンチマーク結果が正規化される中核のフォーマットです。BMFはすべてに関わっています。この新しいバージョンのBMFでは、ベンチマークをパラメーター化できるようになります。my_benchmark_16_mbとmy_benchmark_32_mbという2つの別々のベンチマークを持つ代わりに、パラメーターsize: 16 MBとsize: 32 MBを持つmy_benchmarkと表現できるようになります。新しいバージョンのBMFでは、任意のメトリック名も使えるようになります。meanだけを持つか、Latency (mean)、Latency (p95)、Latency (p99)を別々の測定として作る必要がある代わりに、Latencyの測定に対してmean、p95、p99のメトリックを提供できるようになります。
この新しいBMFバージョンのサポートは、Bencherのコアに対する大規模な改修です。Fable 5より前のモデルでは、この作業を安心して任せることはできなかったでしょう。前述のとおり、Bare Metalの作業のほとんどは、Bencherのコア、つまり時系列でのパフォーマンス追跡と回帰に対するアラートとは直交するものでした。BMFは、そのコアとなる価値提案の中心にあります。Fable 5への、そしてそれ以上にFable 5.1とOpus 5.5への信頼のおかげで、私はまたしても、夜と週末だけでは何年もかかったであろうプロジェクトに着手できています。以前は、BencherのためのSQLite最適化にかなりの時間を費やさなければなりませんでした。今では、データモデルを進化させるたびに、Claudeにエージェントを立ち上げてもらい、すべてが引き続き高性能であることを確かめる徹底的なパフォーマンス調査をさせるだけです。将来的には、頼む必要さえなくなると思っています。
私の今のコーディング
GitHub Copilotを使っていた頃、それはVSCodeの拡張機能でした。Claude Codeに乗り換えた当初は、CLIを使っていました。3つのターミナルウィンドウを、それぞれ別のmacOSのSpaceに置いていました。各ターミナルウィンドウにはタブが2つありました。1つのタブはClaude用、もう1つはJujutsu（jj）用です。バージョン管理とjjワークスペースは、まだ自分で管理していました。
今では、Claude Codeのデスクトップアプリを使うだけです。新しいセッションはすべて、worktreeチェックボックスを有効にした状態で、自分のメタリポから始めます。Plan modeは数か月前に使わなくなりました。Matt Pocockの/grill-meスキルはインストールしませんでした。プロンプトでClaudeに「すべての設計判断について私を問い詰めて」と頼むだけで、今ではモデルがどうすればいいかわかっています。私の CLAUDE.mdAGENTS.mdは、モデルにどう振る舞ってほしいかに合わせてかなりうまく調整されています。
Claude ReviewのCIワークフローは、ほぼ廃止しました。今ではエージェントが、私が頼むまでもなく、ローカルで敵対的レビュアーを立ち上げてくれます。そして両者は収束するまで反復し、ときには6ラウンドほどになることもあります。開発作業を外部の作業用マシンにオフロードし、ローカルマシンはオーケストレーターとしてだけ残すという実験も始めました。
私が自分でバージョン管理に触るのは、自分で何かをテストするためにビルドをチェックアウトしようとするときか、Bencherのタグ付きのバージョンリリースを作るときだけです。それぞれ週に1回程度、月に1回程度です。それ以外は、今ではすべてClaudeに任せています。ドラフトPRをたっぷり活用していますし、GitHubで使えるようになった今では、スタックPRも活用しています。PRが開かれるまでコードは見ません。Bencherのコードには今でも一通り目を通しますが、今では本当のコードレビューというより、ざっと妥当性を確かめるサニティチェックに近いものです。
1年後に振り返って、ここに書いたことを読み返したとき、私はまた「AIについて一言も触れてないじゃないか‽」と思うのでしょうか？半分の私は、そうなったらどんなに素晴らしいだろうと思っています。もう半分の私は、心底怯えています。
Bencher: 連続ベンチマーキング
Bencherは、継続的ベンチマーキングツールのスイートです。 パフォーマンスの後退があなたのユーザーに影響を与えたことはありますか？ Bencherなら、それが起こるのを防げた可能性があります。 Bencherは、パフォーマンスの低下が_マージされる_前に検出し、防止することを可能にします。
- 実行: _まったく同じ_ベアメタルランナーとお気に入りのベンチマーキングツールを使用して、ベンチマークをローカルまたはCIで実行します。
bencherCLIはベアメタル上でのベンチマークの実行をオーケストレーションし、その結果を保存します。 - 追跡: ベンチマークの結果を時間と共に追跡します。ソースブランチ、テストベッド、測定基準に基づいてBencherのWebコンソールを使用して結果を監視、クエリ、グラフ化します。
- キャッチ: _まったく同じ_ベアメタルハードウェアを使用して、ローカルまたはCIでパフォーマンスの後退をキャッチします。Bencherは最先端のカスタマイズ可能な分析を使用して、パフォーマンスの後退がマージされる前にそれを検出します。
機能の後退を防ぐためにユニットテストが実行されるのと同じ理由で、Bencherを使用してベンチマークを実行してパフォーマンスの後退を防ぐべきです。パフォーマンスのバグはバグです！
パフォーマンスの回帰を捉えるのを開始してください - Bencher Cloudを無料で試す。