3人で​1つの​PCに​SSHして​AI活用を​頑張ろうとした​ISUCON2026参加記

ISUCON 2026

ISUCONはいい感じにスピードアップコンテストの略です。
前回大会は2024/12で、GPT-4oが活躍するClaude Codeすら存在しない時代です。

つまりISUCON 2026はAI Agentを使いまくれる初の大会となりました。
船の速度を蒸気機関の発明前後で比べるみたいな、新世界での開催です。

弊チームはISUCON初参加です。
Web系エンジニアの同期のお友達2人と私の3人チームです。

今年のお題はBeReal的なアプリです。
BeReal以外で説明できる方法がないくらいBeRealです。

特徴はasia,europe,americaの3リージョンに分かれるグローバルサービスで、それぞれ特定のタイミングで負荷が急増するような仕組みです。

結果

最終は約14.5万点。まだ全体順位は公表されていませんが、各賞受賞者の点数を元にすると、50~100位台のスコアになります。

1位の60万点と比べると大きな乖離があります。
さらに言えば、1位のチームが開始1時間ちょっとで叩き出した点数に、最後まで及びませんでした。

戦略

1つのPCに全員でSSHしてHerdrでClaude/Codexを操作

コンフリクトや手戻りを防ぐために1つのPCに3人でSSHしてAI Agentを使いました。

SSHした先でHerdrを使うと、Tab単位では3人の操作が同期する(1人が文字を打つと全員の画面にそれが出てくる)反面、別タブではそれぞれが独立して操作できます。

他の人の操作を全員で見ることもできつつ、同じAgentを共通で使えるという、便利なよくばり構成です。

AI Agent同士での指示もHerdrを使うことでいい感じにできます。
「隣のAgentにxxを依頼して」とか「issuer(別Agent)に起票依頼して」など指示も簡単にできる上、Agent自身が今動いている別のAgentを認識していい感じに役割分担や作業のコンフリクトも防いでくれます。
Herdrを使うことでミートプロキシ(人間がAIの指示をコピペして別のAIに流す作業)が最小限になる形です。

役割ごとにClaudeセッションを用意

練習を踏まえて、初期構成は下記のようにセッションを用意しました。
それぞれのClaudeのセッションには1つずつHerdr Worktreeを切ってGitのブランチを分けています。

基本の分担は下記のような形です。

基本Claude CodeのOpus5.5で動いて、実装はdelivery session経由でCodexが行う構成です。(Codexも併用しているのは、Claude Max 20xでも5h limitを超えないようにするための対策です)

当日は状況を踏まえて追加のanalyst(DBなど主要ボトルネックを専用に調査するやつ)も足しながら、流れとしては下記のような形で進めました。

flowchart TD
  Human(["人間 3人 / Discord"])

  subgraph Loop ["改善・実行ループ"]
    Analysis["1. 分析 & 起票<br/>(Grafana / 各種 analyst / issuer)"]
    Plane[("Plane / タスク管理")]
    Exec["2. 実装 & マージ<br/>(delivery / Codex 実行役 ×20)"]
    Bench["3. 検証 & 反映<br/>(bench / AWS EC2)"]
  end

  Analysis -->|タスク登録| Plane
  Plane -->|タスク配布| Exec
  Exec -->|mainブランチ 反映| Bench
  Bench -->|メトリクス / 結果| Analysis

  Human -.->|起動・指示| Loop

上位にいるのは人間ですが、人間よりAIの方がコードは精度高く速く書けるということで、人間がコードを書くことはありません。

流れ

1.問題のルールやシステムの概要、スコアなどをAIに食わせる

10時の開始とともに問題のルールなどをAIに食わせます。

2.まずゼロから作り直す

ISUCONでは最初からいくつかの言語の実装を渡されます。
しかし意図的なボトルネックがコード上に仕組まれていることも多いことを鑑み、あえて別言語で再実装させることをまずやりました。
比較的短時間である程度点数を上げられる強みがあります。

3.OTel仕込み + Grafanaで AIと人間が重たい場所を見れるようにする

次にOTelとGrafanaを入れて監視体制を作ります。

4.気になったところをAIに指示して調査→改善→数値計測して更なるボトルネック調査のループ

人間3人が仕様やコード・Grafanaを見ながら気になった問題をClaudeセッションに聞いていきます。
聞いた結果を元に、ClaudeがHerdr経由で

1. issuer Agentに起票を依頼
2. delivery Agentが実装
3. bench Agentがデプロイしてベンチマークを走らせる
4. ベンチマークの結果をGrafanaで見て人間とAIが考えて1に戻る

の流れで進めていました。

人間の視点以外にもissuerとGrafana監視エージェントによる自動起票もしていました。

その他こだわりポイント

• IssueをGitHubでなくローカルで管理
  • 練習の際、IssueやPRを立てすぎてGitHubのAPI limitに到達して一部操作ができなくなっていました
  • ローカルでissueを管理することでlimitを回避しました
• Claudeが求めるユーザaskはDiscordに投げてチームが確認できるようにする
  • 練習の際、人間の判断待ちでAIが止まることに気づけないケースがありました
    • Herdrでは通知音やビジュアルで分かりますが、同時に複数動かすと、対応漏れが出てきます
  • ユーザaskをDiscordに自動で投げるBotを作り、Discordで確認+指示を送れるようにすることで、判断漏れによる待ちを最小限にしました。

当日追加でやったこと

AIへの縛りを緩和

本番前の練習回では-15万点を叩き出すケースがありました。

これを踏まえてルール厳守と壊れないようなテスト・ビルドのプロセスを事前プロンプトに入れていました。

しかしこの安全設計がベロシティをめちゃくちゃに低下させていました。
安全に作って安全に検証する結果、ベンチを測るまでの1スパンが遅くなり、1つのボトルネックの解消が遅れ、次のボトルネックを見つけるまでが遅くなる悪循環です。
1つボトルネックを解消することで次のボトルネックが見えてくるケースも多く、大きいボトルネックを早く解消しないと問題を見つけられる総数が減ってしまい、結果点が伸びません。

またRustを使用していたこともあり、実装担当(delivery)が最大で20並列でビルドを走らせ、スペック的な限界で速度が落ちていた点もあります。

この最悪の悪循環を避けるため、16時まではビルド不要でバンバンPRマージさせるような指示に当日変更しました。

AI Agent自体のボトルネックの解消

実装を行うdeliveryセッションは20並列にすることで大きなボトルネックになっていませんでしたが、デプロイやベンチマークを計測するbenchセッションが大きなボトルネックになっていました。

当初benchはデプロイ、ベンチ実行、結果をまとめるを全部1エージェントでやっていました。それらの作業をしながら20個のセッションからのデプロイ依頼が来る状態で完全に詰まっていました。

これを

1. デプロイ準備役(他agentからのデプロイ依頼の窓口 & ビルドなど)
2. デプロイ+ベンチ実行役
3. 結果分析役

の3セッションに分けることで解消しました。

本番

8時間で658PRをマージしました。

最高スコアは150508点で、最終スコアは145523点です。

最終的なインフラ構成はこんな感じです↓

flowchart LR
  BM([ベンチマーカー])

  subgraph EU["europe1"]
    EN[nginx]
    EA[アプリ<br/>読み + 画像の受け取り]
    EI[(画像 origin)]
    ES[(PostgreSQL<br/>レプリカ)]
    EN -- GET・画像の投稿 --> EA
    EA --> ES
    EA --> EI
  end

  subgraph AM["america1"]
    MN[nginx]
    MA[アプリ<br/>読み + 画像の受け取り]
    MI[(画像 origin)]
    MS[(PostgreSQL<br/>レプリカ)]
    MN -- GET・画像の投稿 --> MA
    MA --> MS
    MA --> MI
  end

  subgraph AS1["asia1"]
    AN[nginx]
    AR[asia 読み :8080]
    AW[asia 書き :8085]
    AD[admin :8083]
    AI[(画像 origin)]
    AN -- GET --> AR
    AN -- 書き込み --> AW
    AN -- /api/admin --> AD
  end

  subgraph AS2["asia2"]
    WE[europe 用の書き :8081]
    WA[america 用の書き :8082]
    P[(PostgreSQL<br/>プライマリ)]
    WE --> P
    WA --> P
  end

  BM --> EN & MN & AN
  EN -- GET 以外 --> WE
  MN -- GET 以外 --> WA
  AR & AW & AD --> P
  P ==>|"同期レプリケーション<br/>remote_apply"| ES & MS
  EI <-.->|"画像を miss 時だけ取得<br/>(プライベート IP :8084)"| AI
  MI <-.-> AI

感想

​現代Vibe Coding社会を象徴するような大会で、AIとの向き合い方や使い方を改めて考えさせられる大会でした。

初めてISUCONに参加するにあたって、ISUCON9の本戦をチームで解きました。ISUCONの解き方など前提知識を与えていないClaude/Codexと、ISUCON全員初見の人間3人で解いて、当時1位の6倍近い点が出ました。

大Vibe Coding時代には全員AI使って差がなくなるのでは！？という安易な想像をしながら大会に臨みました。

しかし本番の結果を見ると、全員が似たような点数にはならず、大きく差がつく大会となりました。

AIの使い方次第でここまで点数が開くように作られた作問に感動しました。
全員がAIを使えても結果に差がつくAI時代の縮図のような大会で、新卒3年目としては将来を考えるきっかけにもなりました。

AIを使うことでAIが無い時代とは爆発的にスコアが上がる反面、周りもAIを使える現代では、ちゃんと実力差が出ることを分からされました。

弊チームでは比較的単調にスコアが増加しつつ、後半12万点あたりから停滞に伸び悩み、かなり歯がゆい結果となりました。

個人的反省点

戦略を人間に頼らない

実装は人間よりAIが賢いということで、具体的な実装指示は避けてAIに任せていました。

しかし大前提、そもそもボトルネックの調査やどの順で何をするかの戦略もAIに任せるべきだったかもしれないなと思いました。

優勝者のコメントを引用します。

今回はコーディングエージェントがHuman out of the Loopで完全に自立して走れるように準備して参加しました。
(中略)
評価環境で100回以上問題を解いてユーザハーネスを改善する日々でした。
ISUCON2026 オンラインライブ中継より

今回優勝チームは、大会期間中1度も人間が指示せず圧勝していた点も大きいです。

AIの出力には人が介すべきHuman in the Loopという前提も、適切なハーネスがある世界では前時代的になっているのかもしれません。

ISUCONは過去大会やチューニングの定石、様々な人の試行錯誤のブログという叡智があります。
人間がその場で考えて戦略を立てるよりも、過去大会を解かせてハーネスを作らせる方が圧倒的に有利という点は、言われてみるとその通りです。
私たちのチームも実装は完全AIである程度AIだけで完結するループはできていました。
しかし戦略や勘所を人間が考えてしまっていた部分もあり、AIに任せきれなかったという点がありました。

AIを銀の弾丸にしすぎない

AIに全任せをした今回、最初は効果の大きい改善ができつつも、後半は局所最適ばかりで抜本的に点が伸びない状態が続きました。

適切なプロンプトやハーネスがない かつ 複雑な問題の場合、AIだけでは限界があるようです。(少なくとも2026/11現在では)

ISUCONは8時間の短期決戦で、ベンチマークの合間に壊れていても問題になりません。一般的なサービス開発とは前提が大きく異なります。
例えば全部キャッシュに載せるとか、特定のユーザを犠牲にして全体の点を上げるとか、そういった人間が思いつく危ない一手は、なかなか純粋なAI単体では出せません。

またAgentへの指示にはISUCONであることや終了時間も明記していましたが、Agentは自身を人間だと思っている節があるのか、「もう残り時間ではこの規模の改善は(人間の実装速度では)実装できません！」という前時代的価値観に囚われて終盤自ら実装を止めるケースもありました。

終盤ではヤケクソプロンプトでギャンブルのごとく結果に期待しましたが、大きく点数を伸ばす結果にはなりませんでした。

現代AIモデルはちょっとした作業を1プロンプトでいい感じにしてくれますが、複雑度が上がると、必ずしもそうではありません。
原文の意味でのVibeなCodingは通用しない世界です。

サービスの理解が大事

練習・本戦ともに、結局サービス理解が大事なことを痛感させられました。
サービスの中身やリクエスト特性を踏まえずに「一旦キャッシュを入れてみる」といった安易な対応では局所最適が限界で、抜本的な見直しには繋がりません。

練習でこの視点に気づいていたにも関わらず、当日その視点を活かせなかった点は大きな反省です。

一方、優勝者は大会中一切AIに指示をしていません。
このことを踏まえると、当日人間がサービス理解をしてああだこうだ議論するよりも、事前に大会を解きまくらせたハーネスに全部任せたほうが勝てる説は高いです。
(人間がサービスを考えて最適化議論するのは楽しいし、頑張った感も強い反面、1位を目指すなら正しいとは限らないという意味です)

ただISUCONという特殊な環境下という前提があるので、これをそのまま実世界のサービス開発に置き換えて人間は不要や！という極論も言えないと思っています。
少なくとも2026年11月の時点では、サービス開発は人間のドメイン理解やコード理解、コミュニケーションが大事だとも日々仕事で思っています。
(が、これも人間というシステムプロンプトが入っている人間側のエゴなのかもしれません)