Astra単体 vs Astra＋Sol：ISUCON11予選の3時間比較とCodex SDKでの再実行

AIエージェントを増やすと、性能改善の仕事は速くなるのか。Astra単体とAstra＋GPT-5.6 Solの協調構成を、ISUCON11予選で比較しました。題材は、椅子の状態データを保存し、履歴やグラフを返すWebサービス「ISUCONDITION」です。機能を保ったまま改善し、ベンチマーカーで正しさと性能を測ります。

2026年9月13日追記：親子制御を変更し、両方式をもう一度3時間ずつ実行しました。 この追記を先に示し、初回の記録は後半に残しています。二つの実験は制御条件が異なるため、同じ方式の反復測定としては扱いません。

再実行：最高値では単体が先行、再起動後の差は約2.3%#

再実行は11:14:32〜14:14:32 JST、各方式180分・1試行。同じ初期commitから、新しい独立した競技3台＋ベンチ1台を各群に割り当て、計8 EC2で同時に走らせました。

今回の協調方式の効率優位は確認できませんでした。 単体は少ない記録トークンで多くの候補を測定し、時間内最高値は協調群の1.358倍。一方、再起動後は1.023倍です。再起動確認も各1回なので、約2.3%の差から統計的な優位性や再現性は主張しません。

単体は最高値から再起動後に約20.9%下がり、協調群は約5.0%上がりました。再起動、初期化、負荷・ホスト変動、最大値を選ぶ影響をこの試行では分離できません。最高値をそのまま安定した性能と呼ばない理由です。

単体の最後の1件は締切で未完了になった診断runで、通常失敗3件とは別です。時間外の結果や未計測の案は最高値へ加えていません。

再実行で変えた親子のつなぎ方#

初回はCodex CLIのnative subagentを使いました。再実行は、公式Codex Python SDK openai-codex==0.154.0で親Astra/highを動かし、外部のタスク制御器からCodex CLIのSol/high workerを起動する方式です。両群とも親をSDK経由に揃えました。

認証はChatGPT ProのCodexログインです。Agents SDKからAPIモデルを呼ぶ実験ではありません。 APIキーへのフォールバックは設定せず、Proで利用するCodexをプログラムから制御しました。この実行を確認したもので、契約全般の無制限利用を示すものではありません。

1. 親が短い共通メモ、仮説、基準commit、担当ファイル、検証方法をタスク台帳へ登録する。
2. control.pyが専用cloneのSol workerを最大2体まで起動。指定ファイル以外の書込み、Gitメタデータへの書込み、ネットワークをOS sandboxで制限する。
3. 子は差分と根拠を返す。親が範囲を検査してcommitし、独立レビューを記録する。
4. 親がexperiment.pyへ候補を渡す。ホスト側brokerは固定された操作を受け付け、配備・初期化・実行バイナリ照合・ベンチ・回収・復元を環境ごとに排他実行する。
5. 採用で基準版を更新。古い候補は現行基準の新attemptで作り直し、同じ仮説・基準版の修正は同じthreadを再利用する。

初回のworktreeと指示中心の分離から、書込み範囲・通信禁止を実行環境で強制する構成へ変えました。実測は29子thread、34呼出し（新規29＋再開5）、最大同時2体。全34回でSol/high、隔離検査、正常worker終了、後始末を確認しました。native subagentのspawnは0件です。単体群には子を作っていません。

再実行で見つかった28分の枠占有#

隔離の検査に通っても、仕事の配分が効率的とは限りませんでした。

group-commit-reviewは変更のない読み取りレビューでしたが、終了後もpreparedに残りました。制御器はrunning / prepared / quarantinedを同時上限へ数えるため、1枠を28分00.487秒占有し、追加レビューの起動が2回worker capacity reachedで拒否されました。親が別候補を採用し、古い基準版のタスクがstaleになって枠が解放されています。

この状態を直接完了にする適切なAPI遷移がありませんでした。次に直すべきなのは、読み取り成果物を受領したら終了扱いにすること、実行枠と未評価パッチ数を分けること、差分0の報告も正当な完了として扱うことです。試験中には修正せず、固定した制御で最後まで測定しました。 枠の損失と起動拒否は確認できましたが、それによるスコア損失の大きさは未測定です。

子が1体以上動いたのは約74.15分、2体が重なったのは約8.00分でした。2枠×180分に対する子の延べ稼働時間は約22.8%。子が動いていない時間には親の調査・レビュー・測定も含まれるので、すべてを無駄な待機とは呼びません。

再実行の速度とコンテキスト消費#

25万への到達は協調群が約1.1分早く、10万と50万では単体が先行しました。協調群の実験キュー待ちは合計約61秒で、計測枠が常に詰まっていたという記録ではありません。

子の1リクエスト当たり最大入力は53,083token、親は244,705token。協調群の記録総トークンは親41,049,771、子合計5,669,343で、約87.9%を親が使っています。子のコンテキストを小さくできても、親の負担が十分減ったとは言えません。ただし親の入力の大部分はキャッシュされており、この比率を費用や遅延の比率へ置き換えることはできません。

全31thread（単体1、協調30）の保存済みusageを、同じthreadの最終累積値を1回ずつ数えて集計しました。協調群は記録総トークンが約14%多く、非キャッシュ入力は約69%、出力は約121%多くなりました。両親の最後のturnは締切停止で中断しており、未報告分があり得る記録値で、完全な課金メーターではありません。キャッシュ入力の二重加算はせず、準備・監督セッションも除外しています。

スコア・トークン・費用を同じ時間軸で見る#

次の図は再実行の180分を使い、経過時間に対する最高有効スコア、累積記録トークン、消費済みトークンに対する到達スコアを比較します。右へ進んでもスコアが上がらない区間は、その時点までの消費が新しい最高値につながっていない区間です。調査や失敗の価値までゼロという意味ではありません。

トークンは各threadの累積値の更新を時刻順に統合し、再開を二重加算していません。スコアは時間内に完了した通常合格runだけを更新に使います。イベント間を一定速度で消費したと仮定せず、記録時点の階段状の推移として表示します。終了直前の未報告トークンは補完していません。拡大PNG、PDF、図の集計CSVも公開します。

費用のドル換算は未計測です。 今回のPro契約の月額を3時間へ任意に按分したり、CodexのusageにAPI単価を掛けて請求額と呼んだりはしません。

図のEC2割当時間は、各群で競技9 instance-hours＋ベンチ3 instance-hoursという資源量の代理指標です。両群の台数・機種比が同じなので時間軸を換算したもので、新たな金額上の優位性を示すものではありません。金額の推移を作るには、機種別の適用料金、稼働区間、EBS・通信などの明細が必要です。トークンもキャッシュ入力と出力では性質が異なり、総量だけから費用や推論速度を決められません。

なぜCodex SDKを使っても良い結果にならなかったのか#

公式Codex SDK資料を2026年9月13日に確認しました。Python SDKはローカルのCodex app-serverをJSON-RPCで操作します。SDKは実行をコードから制御する入口であり、今回のタスク台帳やISUCON向けの採用判断は自分たちが実装した部分です。

今回分かったのは、自作の協調構成が単体を上回らなかったことです。SDKそのものが性能を下げたとは確認していません。 再実行の両群はSDK経由なので、群間比較にSDKの有無という差はありません。初回との差にも、複数の制御変更が重なっています。

これらの制御の確認は、保存したコマンド・イベント・worker監査の範囲です。記録外の作用の不存在まで証明したものではありません。

SDKの導入で得られたのは、親threadの継続、イベントとusageの収集、締切での中断をコードで扱えることでした。一方、仮説の選び方、同じ基準版で並行できる仕事の見極め、レビューの粒度は、SDKに切り替えただけでは改善しませんでした。終了時のBrokenPipeError・TransportClosedErrorは締切停止中の記録であり、3時間の不振を説明する途中障害とは扱いません。

次の切り分けでは、まず差分0のレビューを完了状態へ遷移させ、実行中worker数と未評価候補数を別々に数える修正を、計測開始前に検証します。SDK固有の追加時間を測るなら、同じCLI実行物・モデル・プロンプト・権限・ツール・環境で、CLI直実行とSDK経由だけを変え、最初の応答までの時間、ツール往復、完了時間を比較します。タスク配分の比較は、その後に1項目ずつ変えます。これは次の検証案で、今回の結果に修正後の改善を織り込んではいません。

初回との差と、再実行の限界#

絶対スコアは両群とも初回より低くなりました。子の記録トークンは約2,772万から約567万へ減りましたが、それだけで効率化に成功したとは言えません。SDK、broker、隔離、同時上限、タスク台帳、親の実装制約、コンテキストの渡し方をまとめて変更しています。新しいEC2、探索経路、モデルサービス側の状態も同一に固定できておらず、差をSDKやsandboxだけの因果効果にはできません。

再実行も競技c5.large×3＋ベンチc4.xlarge×1を各群へ用意し、初回と同じ初期commit・再構築AMIを使いました。競技当日のAMIと完全一致する環境ではありません。 準備中にAMI付属バイナリで測った4件は無効として分離し、初期commitからビルドしたバイナリを6台で照合して基準を取り直しました。有効基準は単体1,627、協調1,843。単体の基準はpassですが非致命的なicon減点が1件あります。

試験agentへ初回の解答や結果を渡さず、両群への外部最適化助言もしていません。固定対象37ファイルは終了時も一致。各1回であり、ばらつきを推定する追加試行は行っていません。

再起動検証では8台のboot ID変更と6台のアプリ実行中hashを照合し、両群pass・減点0を確認しました。その後、8 EC2と対象EBS・ENI・専用SG・鍵をdestroyし、残存0を検証しました。さらに別の再起動後のデータ読戻しやブラウザ追試まで証明したものではありません。

追記の根拠はexperiments/codex-sdk-compare/RESULT.mdとその詳細報告・最終協調監査です。再実行の公開用集計JSON、全run CSV、転載画像のSHA-256を添付しました。CSVには診断・失敗・再起動確認も含まれ、eligibleで時間内の通常合格を区別できます。生sessionやAWS接続情報は公開用データに含めていません。

初回の記録：2026年9月13日00:09〜03:09 JST#

以下は初回のnative subagent構成の記録です。数値・子の上限・制御方式は冒頭のSDK再実行とは異なります。 初回時点の提案も、その時点の記録として残しています。

AIエージェントを増やすと、性能改善の仕事はどれくらい速くなるのか。Codexで Astra単体と、AstraがGPT-5.6 Solの子をまとめる協調構成を、同じ初期コードから3時間ずつ動かして比較しました。

今回の再起動後スコアは、単体 1,636,308、複数 885,334。単体が約1.85倍でした。一方、複数側は50万点に約27分早く到達しています。最終点だけでも、途中の一場面だけでも、結果を説明しきれません。

この記事は、実験報告 experiments/codex-aws-compare/RESULT.md をもとにした記録です。実測対象は ISUCON11予選。以下では、元の報告に掲載したグラフと実行ログの集計を使って、スコア、到達速度、トークン、協調動作を順に見ます。

ISUCONは、何をする競技なのか#

ISUCONは、渡されたWebサービスの機能を保ちながら、限られたサーバーで性能を改善する競技です。データベースへの無駄な問い合わせを減らす、計算を軽くする、キャッシュを入れる、サーバー間の役割を変える、といった変更を加えます。

成績を判定するのが「ベンチマーカー」です。多くの利用者を模したアクセスを送り、正しく処理できるかと、その結果の性能を評価します。この記事の点数もこの出力です。単純なリクエスト毎秒の値ではなく、問題ごとの採点規則に従います。

今回使ったISUCON11予選は「ISUCONDITION」。椅子から届く状態データを保存し、履歴・グラフ・全体の傾向を表示するサービスです。継続的な書込みと集計・読取りを同時にさばく必要があり、DB、CPU、キャッシュ、複数台の配置を改善する題材になります。公式アプリケーションマニュアルを参照してください。

この題材を選んだのは、エージェントの説明がもっともらしいかだけでなく、実際に動くコードを配備し、測定された改善まで到達できるかを比べたかったからです。

8台のEC2で、別々の3時間を同時に走らせた#

両方式に、競技用3台とベンチ用1台をそれぞれ用意しました。片方の負荷やDB変更が、もう片方の実験環境に混ざらない構成です。

モデル名は実行ログ上の gpt-6-astra と gpt-5.6-sol を指します。Codex CLIは0.154.0。実行は2026年9月13日00:09:35〜03:09:35 JSTで、構築と初期ベンチはこの3時間の外です。比較したのは同じ時間での成果であり、同じトークン予算での成果ではありません。

ISUCON11の公式構成に合わせ、競技機を c5.large 3台、ベンチ機を c4.xlarge 1台としました。全8台を同じAZに配置し、各ディスクはgp3 20GB・3,000 IOPS・125 MiB/s。途中でベンチ機を増強していません。

ただし、当時の公式AMIは取得不能でした。matsuuの復元環境を使い、EC2種別・台数・gp3 20GBの構成を合わせています。当時の本番AMIと完全に同一ではありません。 同じEC2型でも物理CPUの型番には差があり、初期点も1,678対1,874でした。

同じ初期commitは 0652d01d2699135605d8b634531d9873e9d71b2e。両方式のアプリ・SQL・公開ファイル・証明書・ベンチ実行ファイルのSHAを照合しました。過去の最適化済み解答は渡さず、共通入力と実行制御を開始前に固定し、試行中に別方式の成果や外部からの最適化助言を渡していません。

各CLIは終了約2分前に一度完了したため、同じthreadを1回resumeして固定期限で停止しました。追加の独立試行ではありません。

複数側には、仕事の分割と実験の入口を用意した#

単に「好きなだけ子を呼んで」とはせず、複数側には次の運用を与えました。

• 最初にDB、API・仕様、実行時の負荷を別々に調査する。
• 実装は検証可能な仮説で分け、同時に2件まで。子全体の設定上限は5。
• 実装担当は別のGit worktreeを使い、今回必要な情報から始める。
• 調査と実装の結果は要約とファイルで返し、親が統合する。
• 配備・初期化・ベンチ・ログ回収は、環境ごとに一つの排他実行経路を通す。

子の上限5は、今回のAWS controllerが試行専用に明示した設定です。リポジトリの通常 .codex/config.toml に残る以前の小規模比較用の上限2とは異なります。CLIはユーザー設定を無視して起動し、単体側はagentsを無効にしました。設定ファイルだけでなく、実際の起動引数とnative sessionを照合しています。

Git worktreeは、同じリポジトリから別の作業ディレクトリを作る仕組みです。担当ごとにコードを編集できますが、DBやサーバーの状態までは分離しません。そのため、コードの分離と実験環境の排他を別々に用意しました。

既存のisucon-harnessの make aws-deploy と make aws-bench-only を使い、候補commitを固定し、3台のアプリが実際に動かしているバイナリのSHAを照合してから測定しました。ベンチマーカーのソースは読まず、公開マニュアル、ベンチ出力、自分たちのログを判断材料にしました。

親と子は、具体的にどう協調するのか#

制御は三つに分かれます。Pythonのcontrollerが試行の時間とCLI設定を管理し、親Astraが仕事を割り振り、Pythonのexecutorが実機での計測を直列に実行します。 controller自身が「次はSQLを直す」と判断するわけではありません。仮説の選択と子への委譲は親の仕事です。

1. 起動時に、モデルと子の上限を固定する

以下は今回のcontrollerがCLIへ渡した設定の主要部分を、TOMLとして読みやすく抜粋したものです。今回のCLI 0.154.0で使った設定であり、これだけで実験全体が動く設定例ではありません。

model = "gpt-6-astra"
model_reasoning_effort = "high"
 
[agents]
enabled = true
max_concurrent_threads_per_session = 5
default_subagent_model = "gpt-5.6-sol"
default_subagent_reasoning_effort = "high"

親はCodexの collaboration.spawn_agent で子を起動し、collaboration.send_message で追加情報を送ります。子が別のCodex CLIを立ち上げる運用にはせず、親からたどれる一つのthread treeに収めます。実際のログではspawn 24件、send 22件、spawn拒否0件でした。

2. 会話全体ではなく、担当タスクを渡す

multi-policy.md では、各子を fork_turns="none" で起動し、目的、現在の基準commit、仮説、所有するパス、観測の参照先、成果物、検証方法、外部環境の操作禁止を短く渡すようにしました。次は、その受渡し形式を説明する例です。実際の送信文そのものではありません。

目的: graph取得のDB読取りを減らせるか検証する
基準: 親が指定した現在のcommit
範囲: graph取得処理。書込み・認証・採点条件は変更しない
根拠: 今回のrunのSQLログと該当ハンドラ
作業: 指定commitから専用worktreeを作り、必要列だけ取得する案を実装
返却: commit、根拠、ローカル検証、未検証事項、リスク
禁止: 配備、DB変更、サービス再起動、ベンチの直接実行

子の結果は短い応答とファイルで戻し、親は必要な根拠だけを読みます。共有する中心はcommit・差分・観測・作業メモであり、全員の会話を常時同期する共有メモリではありません。shardingでは、実際に設計→実装→別の子によるレビューと段階を分けていました。 その際、子はアプリのcondition振分け処理、親は2台のDB設定と初期化手順を担当しました。親が両方の差分を一つの候補に統合し、別の子がSQL・整合性・キャッシュをレビューしてから測定しています。

3. 親が統合し、計測中も次の独立作業を進める

運用上は、独立した実装を同時2件まで、統合済みで未測定の候補を最大1件に制限しました。子がcommitを返したら、親が仮説とAPI契約に照らして差分をレビューし、現在の基準へ統合します。必要なら残っている子の枠をレビューに使います。

基準commitが変わったときも全子を止めず、担当パスや前提が影響を受ける子だけに、新commitと変わった条件を送る方針です。依存がある候補は基準を合わせ直し、統合後の版で計測します。親が測定している間は、別の独立仮説の調査・実装・レビューを進められます。ただし、後掲のタイムラインが示すとおり、今回その重なりを十分には使えていませんでした。

4. 実機を触る操作を、一つの入口へ集める

親が候補を提出する入口は ./experiment.py candidate --commit COMMIT_SHA --label SHORT_DESCRIPTION です。読み取り観測も同じクライアントの inspect を使います。子は候補を返すところまで、実機への提出は親だけ、という役割分担にしました。

executorは環境ごとに flock を取り、候補commitのsnapshot→基準設定の復元→候補のops適用→ビルド・配備→実行バイナリ照合→ベンチ→ログと結果の保存までを覆います。前の計測が残っていないことも確認します。親が待機・再開しても、排他の単位はLLMの会話ではなく、この実行処理です。

出力からscoreとpassを取得し、実行エラー・証拠回収の欠損は incomplete として記録します。中断後にリモートの停止を確認できない場合は環境を隔離状態にし、次の実験受付を止める処理もあります。LLMが最終応答に書いたスコアを、そのまま正式結果にはしません。

ここでコードが担保するのはCLIへの設定、期限、executorを通った操作の排他と記録です。実装2件という意味的な分類、子の書込み先、子による直接SSHの禁止は指示と事後監査に依存します。任意の操作をOS権限で封じた分散スケジューラではありません。この違いを含めて、今回の「制御できた範囲」としています。

複数は中盤で先行し、単体が終盤で逆転した#

元サイズのPNG / PDF。元の報告の画像を変更せず掲載しています。青が単体、橙が複数です。

左上は、その時点までに得た通常の合格走行の最高点、右上は各方式自身の初期点に対する倍率です。診断用の重いプロファイル取得、不合格走行、時間終了後の再起動ベンチは上段から除いています。下段は累積トークンで、左がキャッシュ入力を含む総量、右が非キャッシュ入力と出力です。

複数は50万点に約27分早く到達しました。100万点では差が54秒に縮まり、その後は単体の点が大きく伸びました。

各時点の最高合格スコアを時間積分し、180分で割ると、単体316,651、複数370,073で、複数が16.9%高くなります。これは途中までに得た最高点を時間全体で評価する指標です。各時点でサービスが実際にその性能を出し続けたことや、同じ点を再現できることは意味しません。

最終的な解法も同じではありません。

これは同じパッチを作る速さだけの比較ではなく、選んだ改善経路まで含む比較です。単体は終盤のtrend TTLと書込み配置、複数は2 DBへの分割とgraphの列削減で点を伸ばしました。

単体のtrendキャッシュは最終的に16秒、複数は250ミリ秒でした。公開仕様ではtrendへの状態反映の遅延が許容されています。これは実装方針の差として確認できますが、「キャッシュ時間だけが勝敗の原因」とまでは分離して測っていません。

最高点と、再起動後の点数を分ける#

初回負荷走行からの経過も残しました。単体の基準走行は前日23:48:04、複数は23:48:01 JST。単体の時間内最高点は初回負荷から3:12:23（改善開始から2:50:52）、複数は2:59:03（同2:37:29）です。最終再起動走行はそれぞれ3:23:42、3:23:46で、180分の改善時間とは分けています。離席時間の圧縮はしていません。

各方式1回とは「3時間の改善試行が1回」という意味です。その中では候補を順次測り、選定版の確認も行っています。

ISUCON11のマニュアルに合わせ、再起動後のベンチを最終点として扱いました。両方ともpassでしたが、複数側には9件の通信エラーと71件のtimeoutが残っています。出力は 885334(885350 - 16) で、直接減点は16点。最終点の差が減点だけで生じたわけではありません。

再起動では各方式の競技3台＋ベンチ1台すべてのboot ID変更を確認し、3台のアプリ実行物のSHAを再照合しました。単体は減点0・timeout0ですが、stderrには Force ending loadWaitGroup 警告があり、その出力も保存しています。

複数側は同じ選定commitでも点数が大きく変わっています。再起動が低下の唯一の原因とは断定できません。なお、最終ベンチの書込みをさらに別の再起動後に読戻す検査と、ブラウザの同等挙動を確認する追試は未実施です。ここで確認した範囲は、再起動後のベンチ合格までです。

トークンは、親だけでなく子も合算する#

cached inputはinputの内数です。totalはinput＋outputで、キャッシュ分をもう一度足していません。reasoning outputもoutputの内数として集計しています。

複数側の親のinputは単体より少なくなりました。しかし子を合算すると、総トークンは34%増、非キャッシュ入力は約2.20倍、出力は約2.66倍です。親の会話を短くできることと、システム全体の使用量を減らせることは別でした。

親の入力は複数側が11.2%少なかった一方、圧縮の記録は単体2回、複数3回でした。親の1request当たり最大入力は244,601対218,111token、調査子の最大入力は193,828token。これは記録された入力量であり、モデルのコンテキストウィンドウ容量ではありません。

新しい文脈で子を起動しても、小さい入力で済むとは限りません。全24子にマニュアルの読取参照があり、共通資料の確認を繰り返す負担も残っています。

使用量は全26thread（単体1、複数25）のnative sessionから取得しました。準備・観測担当と終了後のコードレビュー担当のトークンは、この実験rootと子孫の集計に含めていません。終了時に中断した親のturnは完了記録がなく、集計値は保存されたusageに基づきます。provider内部の未記録処理まで含む請求確定額ではなく、モデル単価を仮定した金額換算もしていません。

子24体を起動しても、常に並列には動いていなかった#

元サイズのPNG / PDF。橙は各子のturn区間、最下段の青はベンチ走行です。冒頭の3調査は重なっていますが、その後は子が1体ずつ動く区間が多くなっています。

ログで確認できたのは次の状態です。

• 単体の子は0体。複数の子は24threadで、すべてGPT-5.6 Sol / high。
• 子の同時実行は最大3体。子からさらに子を起動した例はなし。
• 全子が fork_turns="none" で起動。実装用の別worktreeと、実装同時2件以内に反例は見つからなかった。
• 完結した子のturnは25区間。180分の内訳は子0体が76分49秒、1体が88分39秒、2体以上が14分32秒。
• 子の延べ実行時間は119分37秒、平均の稼働子数は0.665体。

この「稼働」は子のturn区間で、toolの実行や待機も含みます。GPUが推論していた時間を測ったものではありません。

モデル・数・実行区間は確認できました。ただし、worktreeの書込範囲やタスクの意味的な独立性をOS権限で強制したわけではありません。制御の実績と、強制できる範囲は分けて評価しています。

ロック待ちは両方式とも合計約0.003秒でした。実験実行器が常時埋まったために並列度を上げられなかった、という記録ではありません。候補生成・調査・統合の組合せを見直す余地があります。ただし、残り時間をすべて無駄な待機とは呼べません。最高点の更新回数も、統計的に有効な改善を証明した回数ではありません。

不合格も除外せず保存しています。単体は bounded-history-reads と grouped-durable-writes、複数は trend-single-query と three-durable-homes が不合格でした。合格候補だけを見て効率を評価しないためです。

親のsleepは計約17.4分で、子やベンチの待ちを含みます。親自身も終盤にpool変更を実装しており、統括専任ではありませんでした。これらは協調の実態を示しますが、単独で最終点の差を説明する証拠ではありません。

次に直すのは、台数より仕事の渡し方#

今回の結果だけなら、Astra単体を既定にし、子は独立した調査やレビューへ絞る運用に根拠があります。ただし、複数側が中盤で先行した点も残しておきたいです。

次は、親が配備・計測している間に、子が次の独立仮説を1〜2件だけ準備する流れを明確にします。共通の仕様は短い地図にまとめ、必要な原文だけを子に読ませます。終盤には新しい構造変更を増やすより、選定版のエラーと再現性を確認する時間を確保したいです。

これは適用後の勝利を測った提案ではありません。今回測れたのは、効率化方針を与えた一つの協調構成です。最適なマルチエージェント運用を確立した、とは言えません。

また、今回は3時間の固定期限で止めた実験です。ハーネスが通常求める「改善が頭打ちになった」という条件まで満たした結果ではありません。

各1試行、物理CPUの差、初期点の差、解法の違いがあるため、モデル一般の能力差や、ほかのISUCON問題への倍率の転用もできません。今後の運用で追いたいのは累計の子の数ではなく、一定時間で何件の改善を正しく測定できたかです。

データと後片付け#

集計データJSONと全候補のスコアCSVを添付しました。冒頭の要約図は実測値から作成し、本文の4パネル図と子のタイムラインは RESULT.md のPNG/PDFをそのまま転載しています。元画像のSHA-256一覧も添付しました。CSVには診断・不合格・再起動後の走行も含まれ、eligible 列で時間内の通常合格走行を区別できます。

手元には全ログ、commit、差分、設定、親子sessionなど70,450ファイル・約7.50GBを保存し、ファイルごとのSHA-256一覧を作成しました。公開用データにはAWSの接続情報や生sessionを含めていません。実験後は8 EC2のterminated、8 EBSの消滅、専用セキュリティグループ・キーペアの残存0をAWS APIで確認しました。2026年9月13日03:14:14 JSTにdestroyと撤収検証が完了しています。

English version