AIエージェントを増やすと、性能改善の仕事はどれくらい速くなるのか。Codexで Astra単体と、AstraがGPT-5.6 Solの子をまとめる協調構成を、同じ初期コードから3時間ずつ動かして比較しました。
今回の再起動後スコアは、単体 1,636,308、複数 885,334。単体が約1.85倍でした。一方、複数側は50万点に約27分早く到達しています。最終点だけでも、途中の一場面だけでも、結果を説明しきれません。
この記事で測った問題は ISUCON11予選です。ISUCON14も検討しましたが、両者の問題や結果は分けて扱います。まず、ISUCONを知らない方向けに背景を説明します。
ISUCONは、何をする競技なのか
ISUCONは、渡されたWebサービスの機能を保ちながら、限られたサーバーで性能を改善する競技です。データベースへの無駄な問い合わせを減らす、計算を軽くする、キャッシュを入れる、サーバー間の役割を変える、といった変更を加えます。
成績を判定するのが「ベンチマーカー」です。多くの利用者を模したアクセスを送り、正しく処理できるかと、その結果の性能を評価します。この記事の点数もこの出力です。単純なリクエスト毎秒の値ではなく、問題ごとの採点規則に従います。
今回使ったISUCON11予選は「ISUCONDITION」。椅子から届く状態データを保存し、履歴・グラフ・全体の傾向を表示するサービスです。継続的な書込みと集計・読取りを同時にさばく必要があり、DB、CPU、キャッシュ、複数台の配置を改善する題材になります。公式アプリケーションマニュアルを参照してください。
補足すると、ISUCON14の「ISURIDE」は、自動運転の椅子を呼ぶ配車サービスで、マッチングや位置更新などを扱う別の問題です。公式の説明はありますが、今回の比較では実行していません。
この題材を選んだのは、エージェントの説明がもっともらしいかだけでなく、実際に動くコードを配備し、測定された改善まで到達できるかを比べたかったからです。
8台のEC2で、別々の3時間を同時に走らせた
両方式に、競技用3台とベンチ用1台をそれぞれ用意しました。片方の負荷やDB変更が、もう片方の実験環境に混ざらない構成です。
| 条件 | 単体 | 複数協調 |
|---|---|---|
| 親モデル | Astra / high | Astra / high |
| 子モデル | なし | GPT-5.6 Sol / high |
| 時間 | 180分 | 180分 |
| 独立した試行 | 1回 | 1回 |
| 競技用EC2 | c5.large ×3 | c5.large ×3 |
| ベンチ用EC2 | c4.xlarge ×1 | c4.xlarge ×1 |
| 初期コード | 同じcommit | 同じcommit |
モデル名は実行ログ上の gpt-6-astra と gpt-5.6-sol を指します。Codex CLIは0.154.0。実行は2026年9月13日00:09:35〜03:09:35 JSTで、構築と初期ベンチはこの3時間の外です。比較したのは同じ時間での成果であり、同じトークン予算での成果ではありません。
ISUCON14の当時のベンチ環境はECS Fargateの8 vCPU・8 GBでした。今回は「競技3台＋ベンチ1台をEC2で揃える」条件に沿い、ISUCON11の公式構成を使いました。ISUCON14の環境仕様とは別です。
ただし、当時の公式AMIは取得不能でした。matsuuの復元環境を使い、EC2種別・台数・gp3 20GBの構成を合わせています。当時の本番AMIと完全に同一ではありません。 同じEC2型でも物理CPUの型番には差があり、初期点も1,678対1,874でした。
複数側には、仕事の分割と実験の入口を用意した
単に「好きなだけ子を呼んで」とはせず、複数側には次の運用を与えました。
- 最初にDB、API・仕様、実行時の負荷を別々に調査する。
- 実装は検証可能な仮説で分け、同時に2件まで。子全体の設定上限は5。
- 実装担当は別のGit worktreeを使い、今回必要な情報から始める。
- 調査と実装の結果は要約とファイルで返し、親が統合する。
- 配備・初期化・ベンチ・ログ回収は、環境ごとに一つの排他実行経路を通す。
Git worktreeは、同じリポジトリから別の作業ディレクトリを作る仕組みです。担当ごとにコードを編集できますが、DBやサーバーの状態までは分離しません。そのため、コードの分離と実験環境の排他を別々に用意しました。
既存のisucon-harnessの make aws-deploy と make aws-bench-only を使い、候補commitを固定し、3台のアプリが実際に動かしているバイナリのSHAを照合してから測定しました。ベンチマーカーのソースは読まず、公開マニュアル、ベンチ出力、自分たちのログを判断材料にしました。
複数は中盤で先行し、単体が終盤で逆転した
図は、その時点までに得た通常の合格走行の最高点です。診断用の重いプロファイル取得、不合格走行、時間終了後の再起動ベンチは除いています。
| 到達点 | 単体 | 複数 |
|---|---|---|
| 10万点 | 1:06:47 | 1:16:09 |
| 25万点 | 2:17:10 | 1:58:54 |
| 50万点 | 2:31:05 | 2:04:05 |
| 100万点 | 2:38:23 | 2:37:29 |
複数は50万点に約27分早く到達しました。100万点では差が54秒に縮まり、その後は単体の点が大きく伸びました。
解法も同じではありません。単体は書込みをまとめて処理し、DB・取込み・表示の役割を3台に分け、終盤にtrendのキャッシュ時間を調整しました。複数は状態データを2台のDBに分け、グラフ取得の列削減などで中盤に先行しました。
単体のtrendキャッシュは最終的に16秒、複数は250ミリ秒でした。公開仕様ではtrendへの状態反映の遅延が許容されています。これは実装方針の差として確認できますが、「キャッシュ時間だけが勝敗の原因」とまでは分離して測っていません。
最高点と、再起動後の点数を分ける
| 走行 | 単体 | 複数 |
|---|---|---|
| 3時間内の最高通常点 | 1,621,980 | 1,114,247 |
| 同じ選定commitの終了前確認 | 1,608,134 | 654,392 |
| 再起動後の最終点 | 1,636,308 | 885,334 |
各方式1回とは「3時間の改善試行が1回」という意味です。その中では候補を順次測り、選定版の確認も行っています。
ISUCON11のマニュアルに合わせ、再起動後のベンチを最終点として扱いました。両方ともpassでしたが、複数側には9件の通信エラーと71件のtimeoutが残っています。出力は 885334(885350 - 16) で、直接減点は16点。最終点の差が減点だけで生じたわけではありません。
複数側は同じ選定commitでも点数が大きく変わっています。再起動が低下の唯一の原因とは断定できません。なお、最終ベンチの書込みをさらに別の再起動後に読戻す検査と、ブラウザの同等挙動を確認する追試は未実施です。ここで確認した範囲は、再起動後のベンチ合格までです。
トークンは、親だけでなく子も合算する
| 使用量 | 単体 | 複数の親Astra | 子Sol合計 | 複数全体 |
|---|---|---|---|---|
| input | 61,273,760 | 54,406,272 | 27,412,204 | 81,818,476 |
| cached input | 60,027,392 | 53,330,048 | 25,752,320 | 79,082,368 |
| uncached input | 1,246,368 | 1,076,224 | 1,659,884 | 2,736,108 |
| output | 193,901 | 208,014 | 308,477 | 516,491 |
| total | 61,467,661 | 54,614,286 | 27,720,681 | 82,334,967 |
cached inputはinputの内数です。totalはinput＋outputで、キャッシュ分をもう一度足していません。reasoning outputもoutputの内数として集計しています。
複数側の親のinputは単体より少なくなりました。しかし子を合算すると、総トークンは34%増、非キャッシュ入力は約2.20倍、出力は約2.66倍です。親の会話を短くできることと、システム全体の使用量を減らせることは別でした。
新しい文脈で子を起動しても、小さい入力で済むとは限りません。調査子の1request当たり最大入力は約19.4万tokenでした。全24子にマニュアルの読取参照があり、共通資料の確認を繰り返す負担も残っています。
使用量は実験rootと子孫のnative sessionから取得しました。終了時に中断した親のturnは完了記録がなく、集計値は保存されたusageに基づきます。provider内部の未記録処理まで含む請求確定額ではなく、モデル単価を仮定した金額換算もしていません。
子24体を起動しても、常に並列には動いていなかった
ログで確認できたのは次の状態です。
- 単体の子は0体。複数の子は24threadで、すべてGPT-5.6 Sol / high。
- 子の同時実行は最大3体。子からさらに子を起動した例はなし。
- 全子が
fork_turns="none"で起動。実装用の別worktreeと、実装同時2件以内に反例は見つからなかった。 - 子2体以上が動いた時間は約14分半。平均の稼働子数は0.665体。
この「稼働」は子のturn区間で、toolの実行や待機も含みます。GPUが推論していた時間を測ったものではありません。
モデル・数・実行区間は確認できました。ただし、worktreeの書込範囲やタスクの意味的な独立性をOS権限で強制したわけではありません。制御の実績と、強制できる範囲は分けて評価しています。
さらに、通常の合格走行は単体50回、複数46回でした。複数側は診断が8回、単体は4回。実験実行器の使用時間はそれぞれ約86分と87分で、ロック待ちはほぼありません。子を増やした効果が、測定済みの候補数の増加にはつながらなかったことが分かります。
次に直すのは、台数より仕事の渡し方
今回の結果だけなら、Astra単体を既定にし、子は独立した調査やレビューへ絞る運用に根拠があります。ただし、複数側が中盤で先行した点も残しておきたいです。
次は、親が配備・計測している間に、子が次の独立仮説を1〜2件だけ準備する流れを明確にします。共通の仕様は短い地図にまとめ、必要な原文だけを子に読ませます。終盤には新しい構造変更を増やすより、選定版のエラーと再現性を確認する時間を確保したいです。
これは適用後の勝利を測った提案ではありません。今回測れたのは、効率化方針を与えた一つの協調構成です。最適なマルチエージェント運用を確立した、とは言えません。
各1試行、物理CPUの差、初期点の差、解法の違いがあるため、モデル一般の能力差や、ほかのISUCON問題への倍率の転用もできません。今後の運用で追いたいのは累計の子の数ではなく、一定時間で何件の改善を正しく測定できたかです。
データと後片付け
集計データJSONと全候補のスコアCSVを添付しました。図は保存された実測値から作成しています。CSVには診断・不合格・再起動後の走行も含まれ、eligible 列で時間内の通常合格走行を区別できます。
手元には全ログ、commit、差分、設定、親子sessionなど約7.50GBを保存しました。公開用データにはAWSの接続情報や生sessionを含めていません。実験後は8 EC2と関連EBS・専用セキュリティグループ・キーペアをdestroyし、削除を確認しました。