ISUCON 2026 に出場し、127,000 点くらいでした。
メンバー
当日の作戦
AI に改善を任せているともっと大きく効く改善を見逃したまま、目先の改善をし続けてしまうことにハマることがあるので、サーバーをたくさんたてていいとこ取りするのがよさそう
3人が別々にAIを動かし、適宜他ブランチを参照して改善案を取り込みながら、最終的に1番点数が高い人を選ぶ！
後半はそれぞれの改善を共有してベストスコア目指すようにした。
それぞれで改善を進めているとデプロイのタイミングが被ったりするので、エージェントに Discord へメッセージを投稿してもらい、エージェント同士でそれを読み合うことでロックを取った。
終盤にデプロイ権限を奪い合う人間とエージェントたち
急にかしこまるエージェント 「恐れ入ります。」
実際にいれた改善
ほとんど AI が実装したので、この部分は AI がまとめています。一部人間が補足しています。特に改善が大きかった部分を抜き出しました。
11:35ごろ: ユーザー検索・登録を改善 35,263点
検索のたびに全ユーザーを取得する経路などを見直し、DB処理を削減。27,542点から約28%向上した。
13:40ごろ: 画像保存と状態管理を分離 59,813点
新規画像を地域サーバーの永続ファイルへ保存し、認証・関係・現在投稿の索引をメモリへ保持。排他範囲も縮め、38,724点から約55%向上した。
14:05ごろ: コミットと状態公開の全体ロックを改善 74,520点
DBコミット待ちと索引公開の同期方法を見直し、最大32件のコミットをまとめて処理。fgprofなしの基準57,809点から約29%向上した。
14:35ごろ: 業務状態をメモリで管理し、DB保存を非同期化 107,951点
コアが状態の判定・更新をメモリで完結し、変更ログをバックグラウンドで一括保存する構造へ変更。正常停止時の退避・復元も用意し、74,520点から約45%向上した。
16:20ごろ: JPEG検証で不要な画素復元を省略 101,083点
圧縮データの完全検証を維持し、使わない画素の復元を省略。通常JPEGの処理が約1.4〜1.6倍速くなり、直前の92,981点から約9%向上した。
16:50ごろ: 保存接続とチェックポイント処理を分離 118,210点
所有権保持とログ保存の接続を分け、チェックポイント保存を別ワーカーへ移動。保存停止が管理APIへ波及する構造を直し、直前に76,165点まで落ちていた状態から回復・向上した。この走行はエラー0件だった。
17:30ごろ: 初回署名を地域分散し、RPCを一括化 129,110点
初回署名をEurope・Americaへ分散し、エクスポートの署名依頼を最大64件ずつに集約。地域間の直列通信待ちを減らし、118,210点から約9%向上した。
最終的な構成
アジアにあるサーバーのうち、最初に DB を持っていた asia2 でも Go アプリを動かしてそれを中央集権的なサーバーとし、他のサーバーをエッジサーバーとして動かすようにしました。
DB へのアクセスがあると、エッジサーバー→ルーター→コア→DB のように通信が多くなるので、できるだけエッジのメモリにデータを置けるように工夫しました。ある地域での更新を他の地域で即時反映されているようにするのが難しいです。
最後の状態だと、asia1 での JPEG 検証と、コアの署名生成・ユーザー検索が主なCPU負荷として残りました。また、履歴APIでは画像ごとの署名RPCが直列に走っており、地域間の通信待ちが一部呼び出しのタイムアウトにつながっていました。最後に直そうとしましたが、ドタバタして時間が足りず直せませんでした。
① サーバー構成とリクエスト経路
各エッジはJPEG検証・画像保存・画像配信を担当します。業務状態と権限判定はコアへ集約し、地域間通信は既存ルーターを経由します。
② 状態更新と永続化
通常の読み取りはDB保存の完了を待たず、公開済みのメモリ状態を参照します。
③ 画像の保存・配信
画像本体をキャッシュしても、削除・退会などの有効性は現在の状態で判定することで、更新されても即時反映を行えるようにします。
④ 画像署名の生成と再利用
エクスポートは未生成の署名を最大64件ずつ依頼し、画像ごとの地域間往復を削減します。
感想
pikachu
ISUCON開始直後にCodexの$500プランに入り、念願のUltraFastをぶんまわして勝つ！！！と思っていたら～ 利用枠の消費があまりにも早すぎて、昼には残り10%で爆笑！
その後は残り数%を大事に使う悲しい運命に；；
別の$100プランも、前日のBankedResetの自動発火に失敗して残り0%で泣きアニメ；；
$200プランがナーフされたときの詫び石トークンでなんとか繋いだ；；
「13時までにTiboから改善告知がなければResetが来る」という傾向を信じまぁ良いかと思っていたら、当日14時に改善告知＋明日Resetの報告があり、今日じゃないんか～い！；；
素振りでは「アプリ全体を読んで構造を決め、複数の改善をまとめてから公式ベンチマークで測る」という方針でかなり上手くいっていたのだが、これを元に事前にAIに作らせた方針案が微妙に意図とずれていて、当日は思い通りに動かず、やや沼ってしまい泣きアニメ；；
例年、カリカリにチューニングするならインメモリキャッシュ！ということで、今回は最初からそれを前提にした構造へ置き換えようとしたが、この基盤を作るのに3時間くらい使ってしまい後悔～
局所的な最適解に陥ってほしくなくて、Sol Max＋UltraFastを4タスク並列で動かし、複数案を比較して統合する想定だった。UltraFastならすぐできるだろうと過信していたけど、案外時間がかかったうえに利用枠をありえない勢いで消費し、スコアの伸びもあまり良くなかった；；
その後は利用枠を気にしながら、改善案を考えるタスクと実装するタスクを分けてマネジメントを試みたが、Codexタスク同士がチャットを送り合ううちに、誰が何を最後まで担当するのかが曖昧になり、各タスクが各タスクをマネジメントするカオスな構造になっていった。
それを全力で調整しつつ、各タスクに指示を書きまくって改善を繰り返し、自分の実装では最終的に7万近いスコアまで伸びた。ただ、ベンチマークを回してリソース配分を詰める時間が足りず、志半ばで競技終了。
今回、DBの待ちが減っても今度は中央のCPUが詰まったり、欧米へ処理を逃がそうにも通信遅延があったりして、リソース分配がめっちゃ難しかった。トレードオフが多く、定番の改善を積むだけでは伸びにくい。ちょうどいい塩梅を探すところで差がつく、良い問題だった！！
その中で後半はチームメンバー間でベンチマークの取り合いになり、満足に回せなかったのが痛い～。ベンチマークまわり、特に順番を決めて回すところはもっと自動化したい。各自がAIで改善を並行して進めていると、人間同士の調整が難しすぎて、そこがボトルネックになる。来年があれば1人で出るのもありかもしれない。
ただ、8時間で$500プランの利用枠を使い切る勢いでCodexを回したおかげで、かなりの学びがあった。今回一番の収穫は、モデルごとの得意な役割と、速度・利用枠・成果のバランスがそこそこよく分かった！ こと。
最近はコストと性能の面から6.1 Solばかり使っていたけど、今回はAstraやTerraも使い、残り時間を見ながら推論の強さも変えていた。使ってみた感触はこんな感じ。
- Astraは、やりたいことを汲み取り、方針を考えて実装できる単位に分けるのがうまい。Opus 5.5には及ばないが、「良い感じにやる」能力が思っていたよりあった。
- Solは、言われたことを忠実にこなす用途ではコストと性能のバランスが良い。一方で、指示の先まで汲み取ってよくする部分はあまり期待できないので、Astraに適切に分けてもらった実装を任せて、簡単ならMedium以下で速く、複雑ならHigh以上、難しいものはMaxでグツグツ煮込むと良い成果が出る。
- UltraFastは速いけど、利用枠の消費も凄まじすぎてありえない。
- Terraは、状況を素早く把握して返してもらう用途では使るが、コードを書かせる気にはならない。
今の自分には、Astraに仕様・設計とタスク分解を任せ、Solで実装する形が一番良さそうという結論に至った。十分な利用枠がなければ試そうとも思わなかったけど、実際に回すと体験が良かった。DevDayで聞いた協調開発って、こういうことだったんだな～となるなど。Tiboのチャレンジの最後にAstra6.1とかでないかな～と期待している。
競技結果は大分悔しみ～。今だったらもっとうまくできる～！！とはいえ、この経験が出来たのでISUCONに出た価値めっちゃあった～！やってみて分かることすぎる。
でも優勝者はOpus 5.5をコンテキスト圧縮なしで自走させるハーネスだったという話を聞くと、結局1タスクに全部任せる方が正確で効率的なのかな～。AIがもっと強くなったら、役割を分けて協調させるのか、1タスクで全部こなすのか、どっちが良くなるんだ～？
結論！AIマネジメント難しい！
anko
↑これ
大量のエージェントのマネジメントがうまくなければ、人間が途中で指示したりしてコンテキストを汚しまくってめちゃくちゃになっていってハーネスを組んでく良さを噛み締めた。
優勝コメントを聞いてみたらトークン使用量がかなり少なくて「まだほとんどの人は LLM の真価を活かしきれてない」という言説が正しそうだなとおもった。
こういう 1 つに特化させたハーネスを作る為にはそれだけのコストが掛かるしそれだけ良くなるというのが広く知れ渡れば AI slop が流行りすぎずちゃんと価値のあるサービスが確立されそうでうれしい。
ikura-hamu
↑↑ これ
僕は ChatGPT Pro 200 のプランを契約してましたが、週間制限の 19% しか使わず、逆に余ってました。もっとたくさん使うことで改善を加速出来た気がしますが、どうやったらうまく使えるか分からない。モデルの選択とかももっとうまくできた気がするんですが、ここを極めてもすぐモデルが変わっちゃって意味のない能力になっちゃう気がするので難しい。
過去問を解いてると「最初に全部メモリに載せる」が最適解になってしまっていて、これは ISUCON 運営の人が望んでる形の ISUCON じゃないんじゃないかなと思っていました。どんな問題になるかなと思ってましたが、メモリに載せるだけじゃ解決できない問題が出てきたのですごいなと思いました。
一方で、人間が頑張る昔の ISUCON も好きなので、AHC みたいに with AI と human only をやってもらえるととても嬉しいです。さすがに難しいですね。
優勝者のコメントを聞いて、今後のソフトウェアエンジニアリングは、目的が決まってる場合にはハーネスをしっかり作って効率を重視するのが正しいんだなと思いました。来年あるとしたらもっと準備して臨みたいです。
