ISUNARABE 合同演習 2026に参加して9位でした (5,176,800点)
ISUNARABE合同演習2026に、overcached! チームで参加してきました。
ISUNARABE合同演習2026は、ISUCON形式の模擬大会です。今回の特徴は、AIを活用してWebアプリケーションのパフォーマンス改善に取り組む、という点にありました。
結果は 5,176,800点で9位 でした。 Claude CodeのMax 5xプランの5時間制限分くらいのトークンを使っています。
過去参加したISUCONでは, Goを使っていましたが, 今回は参考実装のRustをベースに改善を進めました。
序盤はClaude Codeだけで100万点まで到達できた
競技開始直後は、まずデプロイ環境と計測環境の整備から入りました。
ISUCON形式の大会では、アプリケーションの処理を速くするだけでなく、変更をすばやく反映するためのデプロイ手順や、どの処理が遅いのかを調べるための計測環境が重要になります。
このあたりの土台づくりは、主に人間側で進めていました。ベンチマークを回し、アクセスログやスロークエリログを取り、変更をデプロイして結果を見る、という最低限のサイクルをまず作りました。
そのうえで、Claude Codeにはアプリケーション側の典型的な改善を任せました。
- N+1クエリの改善
- DBインデックスの追加
- MySQL設定の調整
- nginx設定の変更
- release buildへの切り替え
このあたりは、かなり高い精度でワンショット実装してくれました。
13時台にはrelease buildへの切り替え、DBインデックス追加、MySQL設定の調整、nginx設定の変更、N+1改善などが一気に入りました。その後、14時台前半で100万点台のスコアに乗せることができました。
改善方針も実装もすべてClaudeCodeに任せる、という進め方で問題なく改善が積み上がっていきました。 アプリのコード/変更/分析結果を人間が読む間もなく、Claude Codeが次々と改善を実装してくれる、という状態でした。
100万点台以降は自走が難しくなった
一方で、2回目以降の改善では、Claude Codeにまとめて実装を依頼しても、なかなかスコアが伸びなくなりました。
17時頃までは200万点台をうろうろしており、序盤ほど素直には改善が積み上がりませんでした。
そこからは進め方を変え、人間がアクセスログやスロークエリログを見て、ボトルネックを分析し、改善方針を立てる。そのうえで、実装はClaude Codeに依頼するようにしました。
この進め方に切り替えてから、17時台に参加処理のロック削減や、キャンペーン一覧取得の改善などが入り、200万点台、300万点台と段階的に改善できました。最終的には5,176,800点まで伸ばすことができました。
改善アイデアを実装すること自体は、Claude Codeがかなりやってくれます。しかし、100万点台以降では、アクセスログやスロークエリログを渡すだけで、効果の高い改善施策を自律的に出し続けてもらうのは難しい印象でした。
ISUCON特有の割り切りをAIにどう伝えるか
今回難しいと感じたのは、ISUCON特有の割り切りをどこまでAIに判断させるか、という点です。
たとえば、DBロックをアプリケーション側のmutexに置き換えるような改善があります。単一アプリケーションサーバーであれば効果が出る可能性がありますが、アプリケーションを複数台構成にすると破綻します。
通常のプロダクション開発であれば、かなり慎重に扱うべき変更です。一方で、ISUCONでは競技時間内にスコアを伸ばすことが目的なので、構成や制約によっては割り切って採用する判断もありえます。
このような判断を、Claude Codeだけで行うのは難しそうでした。このあたりはCLAUDE.mdにコンテキストを入れて、判断基準を伝える必要があると感じました。
理想としては、計測、分析、改善のサイクルを自律的に回せる環境を整えれば、AIが継続的にスコアを伸ばしてくれる状態です。しかし今回の感触では、100万点台から200万点台に入ったあたりで、Claude Code自体もかなり沼にはまっていたように見えました。
ボトルネックはDB CPUと一部の重い処理
途中からサーバーを役割ごとに分ける構成に切り替えました。
最終的なサーバー構成は以下のようになりました。
- s1: nginx
- s2: app, memcached
- s3: db
律速になっていたのはDBのCPU使用率でした。
特に重かったのは、キャンペーンへの参加処理と、キャンペーン一覧を表示する処理です。
参加処理では、同時に多くのリクエストが来たときに、定員を超えて参加できないようにする必要があります。今回はDBロックで詰まっていた部分をアプリケーション側のmutexに寄せ、timeoutを5秒にすることで待ち時間を抑える方針にしました。
キャンペーン一覧については、終盤のalpを見て判断しました。
GET /campaigns?sort=new と GET /campaigns?sort=active の累積時間が大きく、ここを潰せばスコアに効くと考えました。
タグフィルタがない一覧は、多くのユーザーに同じレスポンスを返せます。そこで campaigns:list:active と campaigns:list:new の2つの固定キーで、memcachedに1秒TTLでキャッシュしました。更新時は、キャッシュは削除するだけにしました。
チームワークが難しい
3人チームでAIを使いながら進めるのは、難しい部分がありました。
まず、改善すべきわかりやすいポイントは, AIがワンショットで一括で実装してしまいます。 作業分担がしづらく、同時に複数のAgentが入ると競合が起きやすい状況でした。
またサーバーを複数台構成にしてからは、Claude Codeがデプロイや動作検証を始めるタイミングを、人間側がうまく制御する必要がありました。その結果、チームメンバーがベンチマークを回している途中に、別の作業者のClaude Codeがデプロイを始めてしまうといったことが何度か発生しました。
これまではデプロイ前に声をかける、次にベンチを回したい人が意思表示する、といった人間同士のコミュニケーションでなんとかなっていました。
今後は、以下のような仕組みを整えておく必要がありそうです。
- デプロイ/ベンチマーク実行中のロック
- AIエージェントに守らせる運用ルール
AIを使うことで実装速度は上がりますが、チーム開発としての調整コストがなくなるわけではありません。むしろ、AIが高速に作業するぶん、衝突を防ぐ仕組みはより重要になると感じました。
まとめ
1000万点台に届こうと思って競技中試行錯誤していましたが、到達することができず悔しかったです。 AIの活用の仕方の課題というよりも, 解法を見つけるための経験の差が大きかったように思います。
今回の大会で面白かったのは, 日々AIを活用している人たちの工夫を見ることができたことでした。 競技者のレポジトリを見ていると, 単にAIにコードを書かせるだけではなく、作業ログを残したり、計測結果をAIに渡しやすくしたり、改善サイクルを回しやすい形に整えているチームが多いことがわかります。
楽しい大会でした。ありがとうございました。