ISUNARABE合同演習2026に参加しました(INUCON チーム)
@KOBA789 さん主催のISUNARABE 合同演習 2026 に参加しました。
チーム名は INUCON(以下略)で、結果としては参加者唯一の fail でした…
そのざっくり参加記です。
前提
自分の場合、以前から Grafana を中心とした対 ISUCON 用のツール群を整備していました。
ざっくり説明すると、ローカルで Grafana・Prometheus・Pyroscope・Loki を docker により構築し、サーバーに fluentbit と自作の自動計装ツールで各種メトリクスを仕込むことで1発で完全な計測環境ができるというものです[1]。
そのため、これをコーディングエージェントに適応させる方向で環境を用意しました。
と言っても、今回は準備が当日朝までできず、準備時間は 2 時間程度です…
そのため、環境整備として大きくできたのは Grafana MCP を用意して繋ぎこむ程度です。
また、そもそも対 ISUCON ツール群が Go 実装が存在しない状況を想定しておらず、Rust 実装のままだと過去資産を強制的に捨てることになるので、初手 Go 移植を決行するのも決めており、Go 移植用の Agent Skill も用意していました。
ただ、これも準備が不完全で、そもそも対 ISUCON ツール群の土台となる ansible 実行時に Go 実装が前提として置かれているので、ansible 実行前に移植をさせる必要がありました。
そのため、その場しのぎで mutagen でリモートとローカルをつないで移植を行った結果、リポジトリ内に「従来の git 管理された実装」 と「移植に使った実装」の二つがある状態となっていました。
当然、コーディングエージェントがめっちゃ迷子になるとは思いましたが、ansible 改築が間に合わず…
それ以外には、分析が重要な ISUCON という競技の性質上、一度しっかり AI に考察させたうえで実装に入らせるべきでは？と思い、以下のようなフローを組んでいました。
- 全体の計測結果分析
- 改善案整理 & サブエージェント作成
- 並列でサブエージェント発火
他には Claude Code Web で適当に作らせた、Grafana MCP の使い方を教え込んだり、ISUCON という競技を教え込む Agent Skill を用意して使用していました。
当日
12:00~13:30 Go 移植 & 環境整備
mutagen をつないで、Claude Code に Go 移植を指示しました。
こちらも、方針分析→エンドポイントごとにサブエージェント用意→一斉発火、で進めていたのですが、結果的には1発で Rust と同等にベンチ通る実装が出てきました。
また、ansible の依存として Nginx もあり、今回は Nginx のない環境だったため、Claude Code に Nginx 導入を指せたりしていました。こちらもこの時点では問題なく終わりよかったです。
その後、サーバーへの ansible を実行しました。ここで、ローカル PC で長らく Docker を使用しておらず Docker 環境が壊れており、修復作業を実施するという大幅な時間のロスをしました。
結果、開始から1時間半たってやっと計測できました…
その他、マニュアルの Agent Skill 化をしたりしていました。
13:30~18:50 Claude Code に放り投げる
ここからは、計測分析→修正をひたすら 事前準備した Agent Skill で回すだけです。
Grafana を見て「ここ改善しないと点伸びないよなぁ」と思うと、だいたい先に Calude Code が気づいて修正していました。
人間はブラウザでベンチを回す機械になっていました。
あとは、2重のアプリのうち別のディレクトリを弄っていたら「そっちじゃないよ」という程度です。
18:50~19:55 DB 経由 fanout に人間が気が付く
以下のエラーで soft-counted error が発生する問題を Claude Code がいつまでも解消できず、2時間程度苦しんでいたので人間がコードを確認します(もっと早くに人間が入るべきだった)。
[SOFT] join send: timeout (per-req 10s)
audited.active[audited-active-455]: join: soft-counted error: join send
その結果、DB 経由でバッチ job を fanout している(初期からだったのか、Claude がやらかしたかは不明)のを見つけ「絶対これじゃん！」となります。
修正を指示し何とかベンチが通るようになりました。
なお、この実装過程で Claude Code が DB に確認のため重いクエリでも投げたのか、MySQL 用サーバーが落ちており、いつまでもベンチが通らない状態になります。
自分はそれを知らないため、原因調査を別セッションで命じ、何も知らないセッションが一から調査して「これ、サーバー落ちているよ」と指摘するまでに 30分くらいかかるという茶番もしていました…
この修正で最終スコアの 14,753,000 がでます。
反省
一番良くなかったのは、リポジトリ中に 2重でアプリケーション実装がいたことですね…
これが終始コーディングエージェントの動きを阻害していました…
(本番は Go 実装がありそうな気もしつつ) Go 実装がない場合にはちゃんと正攻法なフローに移植を組み込みたいとは思います。
もしくは、正直アプリケーション関連部分は既存ツール群がなくても Claude Code の動きが大して変わらなかったとは思っており、アプリケーションは ansible の管理対象外にするのが良い気もしてきています。
また、メイン実装フェーズのフローは改善の余地ありという印象でした。
改善案を md としてまとめ出力する部分で時間をとっており、これを削れるだけでかなり改善が早くなりそうでした。
改善の精度面では明確な優位性はあるので、そこを残しつつセッション間のやり取りを削り落とすことで高速にするのが良さそうという印象です。
fail については、改善の過程で静的ファイルの Nginx 配信が入っており、そこでディレクトリの権限不足に気づかずスルーしていたっぽいです(エラーログ見たら Permission denied がめっちゃ出ていました…)。
動作確認用のスクリプトを先に整備させて、レギュ落ちに気づける体制をしっかり作るのも重要とは感じました。
一方で、Grafana MCP はかなり良い仕事していました。
大半の修正は Grafana MCP で勝手に気が付きやってくれました。
その代わり、改善が Grafana MCP で気づきやすい(not 気づける)ものに寄ってしまう側面もあるとは思いました。
DB fanout については、少なくとも Pyroscope 上では問題になりづらく、それに引っ張られていつまでも原因に気づかなかったように見えています。
slow query(Grafana MCP で見れるが、INSERT・UPDATE に押されて少し順位が低い) やコード(当然見れる)を重点的に見ていれば、即座に気が付いていそうです。
そういう意味では、あえて観点を制限したエージェントを作成し、複数観点でレビューしあう形がベストなのかも？と感じています。
感想
もともと予想はしていましたが、完全にこれまでの ISUCON とは別のゲームになっていると感じています。
チューニング対象がアプリケーションコードからそれを改善するコーディングエージェントに移っている感覚です。
できるだけエージェントにとって障壁の少ない環境を作ってあげて、そのうえで状況を見極め適切なプロンプトを投げ込んであげるコンテストになっている感覚です。
一方で「状況を見極め」の部分がある程度技術面でしっかりした知識がないとできない状況であるのも事実で、「エンジニアの総合格闘技」であるのは変わらず、含む領域がさらに増えたというのが正しい気もします。
それはそれとして、勝ちたかったという気持ちは大きいので、今年あるはずの ISUCON 本番ではしっかり準備して頑張りたいです。
また、主催してくださった KOBA789 さんには本当に感謝しかないです！
-
もともとは自作 AI アシスト VSCode 拡張とセットだったのですが、もはや汎用コーディングエージェントの方が圧倒的に優秀なので、今回は捨てています。本当はその他にも Unix Domain Socket に勝手に対応したり、カーネルパラメーター・Nginx・MySQL に秘伝のタレ流したりいろいろしてくれます。 ↩︎
Discussion