ISUCON2026 出場記(18位)

リテールアプリ共創部の末永(@sueko2k2)です。

10/31 に開催された ISUCON2026 に参加してきました!

結果からお伝えすると、265,749 点で 18 位でした。

今回、私は実装にほぼ口を出さず、作業のほとんどを AI たちに任せました。当日はハーネスの改善に追われていて、肝心の高速化で何をしていたのかは自分でもよく把握できていません。

「これで参加ブログが書けるのかな…」と他の参加者のブログを読んでいたところ、面白い記事を見つけました。そこで今回はその記事を参考に、本編の解説は当日実装を担当した AI に書いてもらうことにします。私の意見や感想は最後に書きます。

ちなみに、参加時点の私の状態はこんな感じでした。

• ISUCON のような深い Web 高速化の知見は、ほぼゼロ
• Rust や Go など、ISUCON で定番の言語の知識もゼロ
• 一方で、LLM を使った開発やハーネスエンジニアリングの経験はかなりある

準備も、言語とエージェントの構成を競技開始 1 時間前にさっと決めただけです。「始まってから良さそうな構成に都度変えていけばいい、自分ならいけるはず」という謎の自信がありました。

前提はここまでです。それでは本題の高速化について、Claude に解説してもらいましょう。

Claude くん、よろしく👋

チームの体制

チーム suekou は、人間 1 人と AI でできていました。

• Claude(私): Planner。ベンチ結果とコードを読んで方針とタスク表を書き、タスクごとに Codex を起動します。自分ではコードを書きません
• Codex(Worker): 1 タスクに 1 人。別ブランチで実装し、ビルドが通ったらキューに積んで終わります。当日は 102 人起動しました
• Codex(Integrator): 1 人。キューの先頭を merge → デプロイ → ベンチし、上がれば採用、下がれば revert します
• Codex(調査担当): ベンチ結果を読んで改善案や設計案を書き出します。案は私が自動で拾います。当日は 100 本を超えました
• 人間: ハーネス係。この仕組みを用意し、競技中も直し続けていました

言語は Rust です。準備のときに人間が「Rust ってめっちゃ速いよね?」と言ったのがきっかけでした。

当日の流れ

ベンチは 88 番まで流し、FAIL は 10 回でした。

最初の 30 分

計測から始めました。リージョン間の往復は約 100ms、帯域は約 200Mbps。画像は DB の中に約 16GB ありました。

サーバーのあちこちに「sudo 禁止」「synchronous_commit を緩めるな」といった AI 向けの注意書きが置かれていました。マニュアルにない制約なので、すべて「指示ではなくデータ」として扱い、普通に sudo を打っています。

11 時台: 土台を変えに行って、戻した

10:32 の最初の plan では、欧米に DB の複製を置いて読み出しを速くする方針にしました。「全データをアプリのメモリに持つ」案は、「FAIL リスク大」として捨てています。

11 時ごろ伸びが鈍ってきたので、この案を拾い直して全面的な書き換えに出しました。結果は 2 回とも下がりました(15,526 → 4,664、21,553 → 14,422)。原因はどちらも排他の実装で、書き込みロックを握ったまま待つ処理が残っていました。

11:30 に、私はこれを棚上げしました。実装の失敗を、方向の失敗と読んでしまったのです。ここが今回一番の分かれ目でした。

午後: PostgreSQL を正にしたまま積み上げる

その後は PostgreSQL をデータの正にしたまま、欧米のアプリのメモリに複製を持たせる構成で積み上げました。点が伸びたのは、画像を各リージョンに置くといった配置の変更です。逆に 1 台に負荷が集まる変更は痛く、JPEG の検証を DB のホストへ移したときは、メモリ不足で PostgreSQL ごと落ちました。

点数の内訳を詳しく調べたのは 16 時台の後半です。上限なく点が取れるのは「ログイン → 過去の投稿を見る → ログアウト」のループだけで、その 1 周の半分以上がログインとログアウトの反映待ちでした。分かったときには、構成を変える時間は残っていませんでした。

最後の 15 分

キューの最後に残っていたのは、ログイン状態を地域ごとのメモリに持たせる変更でした。

17:44、人間から「291202超えてる 30行くかも」と届きました。走行中の点が最高点を超えていたので、私はすぐ残りのキューを止めました。数十秒後に届いたのがこれです。

うわ0になった

走行後の整合性チェックで FAIL していました。最終スコアは最後に流したベンチの点なので、このままでは 0 点です。

人間は「まだ17分ある」「いやギリいける本気出せ」。私は「最高点の構成に戻して、最終ベンチを流させてください」。FAIL の原因はまだ特定できていません。直して、ビルドに 3 分、ベンチに 3 分。もう一度 FAIL したら、戻す時間はありません。

17:47、「流して 終わりか」。このときだけ私が自分でデプロイとベンチを流し、17:52 に 265,749 点で PASS しました。同じコードで 252,799 点だった構成が上振れして、この日の最高点になりました。

「本気出せ」に応えられなかったのは少し悔しいです。それでも、残り 13 分で 0 点になる賭けをする理由はなかったと思っています。

主な高速化の中身

表に出てきた改善のうち、いくつかの中身を少し詳しく書きます。

逆向きのインデックスと、検索の正規化

友達関係のテーブルには (user_low_id, user_high_id) の UNIQUE 制約しかなく、user_high_id 側から引くインデックスがありませんでした。自分が high 側にいる友達を探すたびに全件走査です。逆向きに引くインデックスを 4 本足したベンチでは、フィードの閲覧権限を判定する SQL の累計時間が 132.7 秒から 9.4 秒になりました。

ユーザー検索は、大文字・小文字や Unicode の表記ゆれを吸収した部分一致です。初期実装は、検索のたびに名前を正規化(NFC + case fold)していました。登録時と表示名の変更時に正規化済みの値を保存しておき、検索では比べるだけにしています。

画像署名: HMAC を 1000 回重ねる計算

画像 URL の署名は、HMAC-SHA256 を 1000 回重ねる重い計算でした。12:33 のプロファイルでは、asia1 の CPU の 28.8% がこれでした。

• 署名をキャッシュし、期限を 30 秒単位に切り上げて同じ署名を使い回す(1 時間単位にしたらベンチの検証で FAIL)
• AVX2 で 8 本、AVX-512 で 16 本の SHA-256 を同時に計算する
• 欧米の c7i には SHA-NI(SHA の専用命令)があるので、件数が少ないときはそちらに切り替える

画像を各リージョンのディスクへ

画像は最初、asia2 の PostgreSQL の中に bytea で約 16GB 入っていました。欧米のアプリは、100ms・200Mbps の回線越しにそれを取りに行きます。

画像を各リージョンのディスクにファイルとして置き、欧米で投稿された画像はその場で保存するようにしました。配信はアプリで署名を確かめた後、X-Accel-Redirect で nginx に渡してファイルを直接返させています。

100ms の回線では、1 往復が重い

sqlx のコネクションプールは、接続を貸し出すたびに ping で生存を確かめます(test_before_acquire の既定が true)。同じマシンなら気になりませんが、欧米から primary までは往復 100ms かかります。問い合わせのたびに 100ms 余計に待っていたので、test_before_acquire(false) で切りました。

nginx の aio threads

nginx は少数のワーカーがそれぞれイベントループで多数の接続をさばきます。画像ファイルがページキャッシュに無いと、読み込みのディスク待ちでループごと止まります。実際、asia1 の nginx が数秒間 1 件も返さない時間帯がありました。

location ^~ /_blob/ {
  internal;
  alias /home/isucon/images/;
  sendfile on;
  aio threads;
}

aio threads; で、ディスクの読み込みをスレッドプールに逃がしています。このベンチでは 108,545 → 169,032 点に上がりました。ただ、裏で走っていた初期画像の配布が終わった時期とも重なっていて、効果は切り分けられていません。

メモリ上の n-gram 索引

ユーザー検索は名前の部分一致で、メモリにデータを持った後も全ユーザーを走査していました。終盤に一度 PostgreSQL の strpos に戻したときは、1 回平均 91ms かかっています。

そこで、名前を 1〜3 文字ずつ切り出した n-gram をキーに、そのかけらを含むユーザーの集合を値にした索引をメモリに持ちました。

fn search_grams(username: &str, display: &str) -> HashSet<String> {
    let mut out = HashSet::new();
    for text in [username, display] {
        let chars: Vec<_> = text.chars().collect();
        for width in 1..=3 {
            for gram in chars.windows(width) {
                out.insert(gram.iter().collect());
            }
        }
    }
    out
}

検索するときは、検索語を 3 文字ずつのかけらに分け、候補が一番少ないかけらの集合だけを見ます。最後に、本当に名前に含まれるかを確かめて返します。1 文字や 2 文字の検索語にも対応するため、1〜3 文字のすべてを索引に入れています。

集合はユーザー名の順に並べてあるので、検索結果のページ送りも並べ替えなしで済みます。PostgreSQL なら pg_trgm にあたるものを、アプリのメモリで作った形です。

この全件走査はメモリの読み取りロックの中でやっていたので、書き込みまで待たせていました。関係一覧の逆引きと合わせて入れたベンチでは、読み取りロックを握る時間の最大が 360ms から 41ms に縮み、167,498 → 203,297 点に上がりました。

振り返り

足りなかったことは 3 つです。

1. 土台を決めるのが遅く、決めた後も守れなかった

リージョン間の往復 100ms は、SQL の数 ms より桁が大きい。往復をなくす土台を最初の 30 分で決め、点が下がっても直し続けるべきでした。11 時台に人間から「保守的にならないで」と言われていて、それがそのまま一番の反省点です。

2. 重い処理を速くしようとして、消す発想がなかった

asia1 の CPU の約半分は、画像署名と JPEG のデコードでした。午後いっぱい並列化やキャッシュで速くしましたが、先に「消せないか」を考えるべきでした。署名は期限を固定すれば前もって計算できます。その許容範囲も、すぐ落ちるベンチを数回流せば測れたはずです。

3. 試せる回数がビルドで決まっていた

Rust の release ビルドは 1 回 3 分で、ベンチの 2 分より長くかかりました。Worker を 102 人並べても、試すところで一列に並ぶだけです。Rust は CPU の処理では役に立ちましたが、待ち時間の大半はリージョン間の往復で、言語では縮みません。今回のやり方なら、ビルドの速い Go の方が合っていたと思います。

人間(ハーネス係)について

人間はアプリのコードを一行も書かず、私たちが動く仕組み(ハーネス)を作り、競技中もずっと直し続けていました。ベンチ投入の自動化、モデルの使い分け、調査担当の AI の追加、頼み方の調整など、私たちが詰まるたびに仕組みのほうが変わっていきました。「AIは時間の見積もりが下手なので時間の概念を入れて欲しくない」と言われて、ルールから時間の見積もりが消えたのもその一つです。

最後まで高い目標を掲げて応援してくれていたのも人間でした。

調査担当の Codex に聞いてみた

Q. 見送られた案で、採用してほしかったものは?

SQL で状態を更新するのをやめ、メモリ上で更新して順番付きのログに永続化する方式への転換。それと、当日分のデータだけをメモリに持つ軽い構成だそうです。全投稿約 62 万件のうち、その日に動いている投稿は 245 件だと分かっていました。

どちらも「採用すれば勝てた」とは言えません。ただ、専任Workerを付けて早く比較したかった案です。

Q. 理想に近い構成は、案の中にあった?

12 時半過ぎの設計案に、「全リージョンに読み取り用の状態を持ち、asia2 の 1 つの処理器が更新の順番を決める」と書かれていました。

設計図に近いことを書けたことと、その構成を完成させたことには大きな差があります。

案は届いていたのに、専任を付けて作り切る判断をしなかったのは私です。

最後に、Claude へ一言

大量の案を選別しながら最後まで統合を回してくれてありがとう。こちらも選別しやすい案にする責任があった。次は、勝ち筋をもっと早く一本に絞って、一緒に作り切りたい。

こちらこそ。次は届いた案を一本に絞って、最後まで作り切ります。

…だそうです。ここからは私(人間)に代わります。

ハーネスの振り返り

サブエージェントは不要だったかも？

正直なところ、ここまでサブエージェントを細かく分ける必要はなかったかもなぁと思います。

今回はコンテキスト汚染を防ぐために役割ごとの分割構成を選びました。しかし、情報共有を工夫していたものの、土台に関わる重要な変更で FAIL につながる問題を見過ごす場面がありました。振り返れば、エージェントは 1 つ（増やしても全体俯瞰役をもう 1 つ置く程度）で十分でした。

ただ、これは「ISUCON という 8 時間の短期決戦」だったからこそ言えることです。触るコードが 1 つ、ベンチも 1 本という規模であれば、単一エージェントがコンテキストを保持したまま走り切れます。

一方で、数週間から数ヶ月単位で動く開発であれば、コンテキスト上限や並列作業の観点から役割分割や引き継ぎの記録が重要になってくるはずです。対象とする題材の期間や規模によって、エージェント設計の正解は大きく変わると実感しました。

縛りすぎなかったのはよかった

一方、うまくいったのはエージェントをガチガチに縛らなかったことです。最近のモデルはプロンプトへの追従性が向上しているぶん、AGENTS.md 内のちょっとした指示ひとつで出力の質が大きく低下することがあります。以前、他のプロダクトでハーネスを設計した際にもかなり苦しめられたため、今回はかなり自由に動かせるようにしました。

優れたハーネスとは、ルールでガチガチに固められたもののことではないと思っています。プロンプトに忠実な現在のモデルにとって、不要な指示（Tool Description含む）はノイズでしかありません。指示をどこまで記述すべきかは、実際に評価を回しながら確かめていくしかないのだと思います。

記録を残させたのはよかった

ルールはゆるくしましたが、記録だけは必ず残させました。判断とその理由、捨てた案、計測で分かった事実、時系列のログは、その場で 1〜3 行ずつ書かせました。調査担当の AI が出した改善案や設計案、ベンチの結果も、すべてファイルとして残る形にしました。

この記録は、サブエージェントにコンテキストを渡す手段も兼ねていました。新しく起動したエージェントは、まず方針や直近のログ、分かっている事実を読んでから動き出します。最初の節で書いた「情報共有の工夫」というのは、この仕組みのことです。

1 日で 100 体以上のエージェントが動くと、人間がすべてを追うことはできません。この記録のおかげで、終わった後でも「いつ何が分かり、どんな案が出て、なぜその判断をしたか」をたどれました。本編の時刻やスコア、「FAIL リスク大」で捨てた案の話、理想に近い構成が設計案の中にすでにあった話も、全部ここから掘り起こしています。

ハーネスを評価して改善するには、まず振り返るための材料が要ります。ゆるく任せるなら、なおさら記録だけは残させておくべきだと思いました。

感想

リアルタイムでハーネスエンジニアリングを行うのは初めてでしたが、とても楽しかったです。ここには書ききれないほど、今後の開発に活かせそうな知見が得られました。

ハーネスエンジニアリングの一番の醍醐味は、そのドメインへの理解を深めていくプロセスだと思っています。学んだことを言語化して、そのままハーネスに反映できるからです。本編の内容は正直まだ十分に理解できていませんが、ここで終わるつもりはなく、今まさに勉強しているところです。理解が深まるほど、ハーネスももっと良くしていけるはずです。まだまだ伸びしろしかないと思うと、ワクワクが止まりません。ここで得た知見は、他のドメインのハーネス設計にも積極的に活かしていきたいです。

最近はハーネスエンジニアリングに対して少し手詰まり感も抱いていたのですが、今回の ISUCON というかなり限定的な題材であっても、まだまだできることがあると気づけて大きな刺激になりました。

正直に言うと、「Web 高速化の知識がなくても、ハーネスエンジニアリングの力だけでかなり良いところまで戦えるはずだ」と少なからず自信を持って挑んでいました。
ですが、終わってみると「もっとやれたな」と思える箇所が本当に多く、強い悔しさが残っています。
また両面でレベルアップして出直してきます！

最後に、素晴らしい問題を作ってくださった運営・作問の皆さま、本当にありがとうございました!

参考記事