TITLE

ISUCON2026を無人のClaude Codeエージェントが制覇 ― 止め時をどう設計したか

投稿日：2026.11.08

7時間42分、人の入力はゼロ ― 当日に何が起きたか

当日のセッションは10:00:05の最初の応答から17:42:50の最後の応答まで、約7時間42分にわたって続き、17:49:59にセッションが終了しました。この間、人間からセッションへの入力は0回、エージェントが人間を呼んだ回数も0回です。文脈を圧縮するコンパクションは16:27の1回のみでした。

誰も座っていない椅子の前で、画面だけが光り続けるデスク

最終スコアは625,857点(最後の負荷走行の結果)で、競技中の最高は629,638点に達しています。負荷走行(0点になった回を含む)は86回に及び、同じ構成のまま12回走らせても474,987点から629,638点までばらつくほど、1回ごとの結果は安定していませんでした。リーダーボードで読めた他チームの最高スコアは、10:26時点で21,952点、17:28時点で513,306点であり、どちらの時点でも自チームが大きく上回っていたと報告されています。トークン使用量は合計約1億3,048万トークン、リクエスト数は303回で、入力側の98.67%がキャッシュ読み込みでした。

技術ブログでは、競技中にPostgreSQLを廃止して過去データをmmapで読み込む方式に変更し、書き込みは代表サーバーが順序付けてファイルに永続化してから全台のメモリへ同じ順序で適用する設計に切り替えた、と紹介されています。nginxが担っていた機能をGoのアプリケーション側に移した、画像の署名検証のボトルネックを事前計算で解消した、といった最適化も紹介されています。これらは本人の一次記事には記載がなく、第三者の技術的な解釈です。他チームにも、より複雑なマルチエージェントオーケストレーションを構築したチームがあったとも紹介されています。

止め時の設計 ― スコアの伸びが止まったら何が起きるか

この結果を支えていたのは、当日の技術力だけではありません。本人は準備に約3カ月をかけ、評価環境で100回以上問題を解かせてハーネスを改善したと振り返っています。

ハーネスの起動は、用意したagent skillに起動を依頼するところから始まります。競技エージェントの実行スクリプトが、herdr(ペイン・space管理ツール)の新しいspaceにClaude Codeセッションを立ち上げ、最初のプロンプトは「CONDITIONS.md(実行ごとに変わる競技条件やポータルURLなど)を読め」という1行の指示だけです。詳細な指示はsystem promptにあらかじめ書き込まれており、競技ポータルへのログインはPlaywrightで自動化されています。

伸び止まり検知から監査役起動・判断記録照合・継続閾値計算を経て停止かもう1周かを決めるフロー図

止め時の判断は、2段構えで作られています。1つは、スコアの伸びが止まったタイミングでClaude Codeのhookが「監査役」サブエージェントの起動を促す仕組みです。監査役は、それまでのエージェントの判断記録を事前に用意したチェック項目と照合し、見直す役目を担います。もう1つは、最後に走行を止めるかどうかの判断で、事前に用意した計算ツールが過去のスコア分布と残り時間から閾値を算出し、閾値を上回れば停止、下回ればもう1回走らせる、という仕組みです。終了時は、実行スクリプトが /exit を送信します。

同じ構成でも走行ごとに474,987点から629,638点まで振れる競技だったことを踏まえると、この閾値の設計自体が成績の一部だったとみなせます。

私たちがAIエージェントの運用から持ち帰れること

この記事自体も、無人で動くClaude Codeエージェントが下書きを作成しています。私たちも長時間自律で動くAIエージェントのループを複数運用している立場から見ると、気になるのは真似できる技術そのものより、どこで止めるかの設計です。

ISUCON2026の事例から持ち帰れる視点は3つあります。1つ目は、止める基準を「感覚」でなく「数式」にしておくことです。閾値を過去のスコア分布と残り時間から算出する仕組みは、停止の判断を実行時の思いつきから切り離しています。2つ目は、監査を人間の目でなく別のサブエージェントに委ねる設計です。判断記録を事前のチェック項目と照合する役目を分離しておけば、本体のエージェントが自分の判断を自分だけで検証する、という弱い構造を避けられます。3つ目は、準備投資の比重です。本番の7時間42分を支えたのは、評価環境で100回以上問題を解かせた3カ月の準備期間でした。当日のハーネスは、その場で思いついたものではありません。