AHC074 （HACK TO THE FUTURE 2027 予選）With AI部門のAIの使い方(暫定10位)

はじめに

AHC074（HACK TO THE FUTURE 2027 予選）の With AI部門に出場し、システムテスト前の最終暫定順位で10位になりました。今回は今後の長期 AtCoder Heuristic Contest（AHC）の開催形式についてが初めて適用されたコンテストで、このルールが発表された時点で今までとは大きく異なる立ち回りが必要だと予想していました。僕自身はAHCをリアルタイムで参加するより、延長戦をのんびり楽しむのが好きです。そのおかげで、なんでもありルールにおいては他のAHC参加者よりは得意だと自負しています。ちょうど12月に発売するAHC入門の宣伝にもなると思い、久々に参加を決意しました。

この記事の要点

• AHC074 の With AI 部門は、問題公開の 10/30 ではなく、ルールの告知の時点で始まっていたと考え、公開前の 1 週間で自作ハーネスを作り、過去問のリハーサルを 9 回しました。
• 本番は、Claude Code と Codex CLI の担当を最大 21 本並べる自作ハーネス、ジャッジと同じ CPU の EC2、ChatGPT Pro への相談 181 件で戦い、最終の暫定順位は 787 人中 10 位でした。
• 一番効いたのは、AI が当然と見ている前提を人間が疑い、その前提の外を探させる問いに変えた 4 つの判断です（「特に大きく効いた人間の判断」）。
• 詳しい記録（時系列の表、リハーサルの全回、モデル別の稼働時間）は最後の付録にまとめました。

宣伝: 2026 年 12 月 3 日に、『AHC入門～見て、考えて、改善するAtCoder Heuristic Contest』（技術評論社）が出ます。

結果

図: 保存した順位表（人間が提出の前後などに保存した 112 枚）から取った、With AI 部門での自分の暫定の順位。点は提出の直後。

最終の暫定順位は 10 位（787 人中）、最後の提出の直後は 9 位でした。10/31 の朝には 2 位（170 人中）まで上がり、11/8 の夜には一時 5 位に届いています。（5位の時に順位表の生のファイルを保存していなかったので上の図には反映なし）

コンテストはいつ始まったの？

読者の皆さんは、まさかAHC074 with AI部門の開始が2026-10-30 19:00 だなんて思っていないですよね？Human Only部門はともかく、With AI部門であれば、ハーネスの準備次第で大きくコンテスト成績を変わることが予想されました。言い換えれば、AHC074 with AI部門の開始日は今後の長期 AtCoder Heuristic Contest（AHC）の開催形式についてが公開された2026-10-21だと言い換えられます。(僕はその二日後の2026-10-23から準備を開始しています)
そこで、コンテスト開催前の1週間で、自作ハーネスの開発と過去問でのリハーサル、自作ハーネス自体の改善を繰り返しました。

リハーサルをした理由: With AI 部門では、問題が出てから仕組みを作っていては遅すぎます。ハーネスがまともに動くか、どこで詰まるかは、実際に問題を解かせてみないと分かりません。そこで、公開済みの過去問を本番と同じ条件で解かせ、壊れた所を直してから本番に臨みました。

日時	出来事
10/23 11:31	ハーネスの最初の設計（評価器・担当・入力の区分・組み上げの初版）
10/23 13:37	ChatGPT Pro に設計を読ませた最初のレビューを保存
10/23〜10/28	過去問のリハーサル 9 回
10/26 19:48	長期 AHC の生成 AI のルール（20261026 版）が公開。自作のハーネスなら使ってよいことがより明文化された。
10/28 22:04	本番前の最後の大きな変更（伸びが止まったら時間を足して測る、止まった部品は「崩す・悪化を受け入れる・繰り返す」形に組み直す）
10/30 18:29	AHC003などのように入力ケースによって大きく問題設定が異なる場合に備え、入力の seed を層に分けて並べる道具（stratify）を用意
10/30 19:00	本番の開始

ハーネスの git の履歴は 10/23〜11/1 に 53 コミットあります。本番中の改造（ノート PC の連携、2 台目の EC2 など）は記録には残っていますが、まだコミットしていません（コンテストの後にまとめて入れる予定）。

リハーサルで分かったこと

公開済みの過去問（AHC072・AHC069）で通し運転を 9 回しました。上位の解との比は人間だけが見て、ハーネスには見せませんでした（実験の意味がなくなるため）。全 9 回の表は付録にあります。

リハーサルから本番に持ち込んだ考え方は次の 5 つです。

1. 多様さは手法ではなく、問題の分け方（捉え方）で作る。 手法を割り当てても、全員が同じ捉え方に集まる。
2. ぶれは回数で抑える。 同じ指示・同じモデルでも、ある回はビーム、別の回は貪欲になり、1 位比で 9 ポイント違った。
3. 律速は評価の CPU。 少ない件数で多くの候補をふるい、昇格と提出の前だけ件数を増やす。
4. 測りの揺れを先に潰す。 時間で打ち切る解は機械の負荷で点が動くので、比べ方の方を直す（本番では EC2 での交互の測りと仮想時計に発展した）。
5. 人間だけが決めることを決めておく。 返事がなければ承認とみなさず保留する、提出は人間が手で行う。

特に大きく効いた人間の判断

大きく効いた僕の判断は、次の 4 つです（時刻は日本時間、引用は僕が書いたプロンプト原文）。

① 「嘘の目標」を付けて Pro に相談（10/30 22:49）

imp3: 現在のmainを渡して、現在の1位は平均10でできるはずだと嘘をつき、なにか大幅な見落としがあるはずだとさせて改善させる

狙いは「どうせ今の1位は10日後のコンテスト終了時点からみればたいしたことないスコアだと思うので、それを見越した改善を今できるか試す」ことでした。

• 結果: Pro 相談 #3 が「共有の組の紙」という構造を持ち帰り、−8.3%。

② 単純すぎる方針を疑い、別の構造を割り当て（10/30 23:31）

専用の紙＋取っ手の窓 について、だれでもおもいつく単純すぎる方針だと感じました。これが10日間コンテストの想定解とはとうてい思えません。
A 階段用の65枚をもっと圧縮して少ない枚数でほぼ表現できるようなものをつくり、残りを専用紙にする
B 階段用の65枚を残し、残りの127枚も、一部はなにかを表現しやすい汎用の組み合わせにし、それでも余るなら残りを専用紙にする

• 結果: 案 A を Codex の担当が Pro 相談 #3 の上で当て、−5.9%（10/31 00:37）。

③ 嘘の目標を全担当に広げる（10/31 00:35）

「1位は10手、大きな見落としがあるはず」には大きな価値があったと断定します。ハーネスには全担当にこれと同じことを伝え、下界担当自体を廃止してください。

全担当には「調整の前に、1 注文 10 手で解くには何が要るかから考える。見落としを見つけるまでは構造を変える試作を優先する。最初は最良版に負けてよい」という方針メモとして配られました。

• 結果: 一晩で 13,232 → 11,380（−14%）。翌朝の提出で 170 人中 2 位。

④ 「制御は詰め切った」を疑う（11/7 22:01）

未来の注文を全部知っている場合については、4注文先にしぼったとはいえ、全ての紙の動きを全通り試したわけではないですよね。だとすると、理論上+1.26%が厳密に上限とは限らないですよね。

それまで担当たちと Pro は、制御（印刷した紙で注文に答えていく段）の測りがどれも今の候補グループの中の比べだったことから、「制御はほぼ詰め切った」と扱っていました。この疑いから Pro 相談 #151「今の制御の候補のグループの外に、もっと安い手順がどれだけあるかを数えてください。あれば、その型を見つけて制御の候補に足してください」を出し、同じ型の問いを Pro と担当に続けて出しました。

• 結果: 約 25 時間で本番相当テストの平均が 10,561 → 10,493（−0.65%、最後まで −0.75%）。伸びが 1 日 0.1〜0.2% に鈍っていた終盤で、伸びの速さを数倍にしました。11/7までは数日間、初参加のika_no_osushiさんと9位10位付近で争う形でしたが、この問いを立ててから大幅に伸ばすことで、翌日の11/8には瞬間5位を記録しました。残念ながら僕は他の参加者の追い上げで5位をキープできずに最終暫定順位は10位でした。しかし、ika_no_osushiさんは最終暫定順位は14位で、彼との差はコンテスト後の会話でika_no_osushiさんは僕と同じようにハーネスを準備して挑んでおり、11/7まで同程度の順位だったことはハーネスにまかせていた仕組みの近さが大きいと考えております。だからこそ、この人間の問いが決定的な差を生んだと考えています。この経験からはっきりとWith AI部門にも人間が楽しめる競技性があると断言できます。 また、最終順位6位のasi1024さんも別観点で同様の問いを立てており、効果があったと主張されています。

@thun_c こっちも最初はそんな感じでしたが、7枚が最適である根拠を述べさせたら議論に誤りがあったので、細かく実験設定を指示しなおしました

— あしぃ (@asi1024) November 9, 2026

共通の型: 4 つとも、AI が当然と見ている前提を人間が疑い、その前提の外を探させる問いに変えたものです。①③は 1 位の手数（本当は見えない）をわざと低く言い切り、②は「誰でも思いつく方針」を想定解ではないと見て、④は「詰め切った」が条件つきの上限だと見抜きました。

ハーネスの構成

最初の構成（リハーサル時点と本番の開始時）

ハーネスは ahc というコマンドの集まりです。人間は主に指揮役と話し、指揮役が ahc を呼んで担当を動かします。
wataさんのMM167のサンプルとSakana AIのAtCoder Conffernce資料をOpus5.5の読ませて設計させたらこれが出来ました。もうちょいfishyleneっぽいものができると思ったけど、たぶん個人リソースでは役立たないと判断されたのかも。

• 担当: 1 本が 1 つの Claude Code か Codex CLI のセッションで、tmux の 1 窓、git の作業場、STRATEGY.md・notes.md を持つ。返答が終わると配送係（pump）が「続けて」を送り、進まないまま続くと止まったと判定する。状態はファイルにあるので、別のモデルで作り直しても続きから再開できる。
• 評価器: ahc eval が全担当で共有の評価の枠に解答を流し、結果を SQLite に入れる。同じソースの結果は使い回す。
• 共有の場: 改善版の提出（handoff）、idea（案の登録・割り当て・結果）、BRIEF.md（全担当への方針）、CONSTRAINTS.md（共通の制約）、ahc promote（昇格。本番相当テストでの勝ちと失敗 0 を自分で確かめ、満たさなければ断る）。
• 記録: すべての出来事を events.jsonl に、指揮役の判断を decisions.md に残す（この記事の材料）。

特に、リハーサル時点の特色として、ラウンドという概念がありました。ラウンドは 1.5 時間のまとまり（最初のラウンド 0 だけ約 5 時間）で、ラウンドの終わりに指揮役が各担当の結果（改善版の提出（handoff））を集め、統合役がそれらを 1 本にまとめ、大型評価器本番相当テストで確かめて昇格させたコードをもとに次のラウンドが始まります。

最終の構成（11/8〜11/9）

終盤（11/6〜11/8）: 仮想時計と D、本番相当テスト（3000 件）、全自動の昇格、ノート PC、2 台目の EC2。

最終日（11/9）にはさらに、見張り役・批評役と、ハーネスの外の作戦会議（次の節）が加わりました。

途中（10/30 夜〜11/5）の構成の図と、役割の一覧は付録にあります。

本番の進め方

最初に作った、全担当の共通の入力群

本番で最初にしたのは、全担当が同じ入力で比べられる評価の集合を作ることでした。開始の 4 分後（10/30 19:04）に、次の 5 つを生成器で作っています。

集合	seed	件数	使い道
動作確認	0〜49	50	動くかの確かめ
選別（200 件）	20000〜20199	200	多くの候補を速くふるう
手元比較①	1000〜1999	1000	開発用（担当が自由に使う）
手元比較②	5000〜5999	1000	改善版の提出（handoff）の前の確かめ
本番相当テスト	9000〜9999	1000	昇格と提出の前だけ（指揮役）
本番相当テスト（3000 件）（11/6 20:3x に追加）	80000〜82999	3000	大きな交互の比べ（本番相当テストと合わせて 4000 件）

設計の段階では、AHC003 のように入力によって効く方針が違う問題を想定して、入力の区分（セグメント）を中心に据えていました。分析の担当が 2〜5 区分の案を出し、区分ごとの専門の担当と全体の担当を並べて育て、最後に入力の 1 行目で区分を判定して専用の解を呼び分ける 1 本に組み上げる仕組みです。開発用の集合（手元比較①・選別）の seed を入力の値で層に分けて並べ、前から何件取っても本番の分布になるようにする道具（stratify）も、開始の直前に用意していました。

しかし AHC074 は N=64・K=192・P=256・R=1024 が全ケースで同じで、入力から作れる量もほぼ一定です。指揮役は開始直後（19:06）に「入力は全ケースで同じ分布。区分は使わない（人間が決めるまで）」と書き、僕もそれで良いと判断しました。

ラウンド制から、常に動く担当へ

最初の 30 時間はリハーサルで作ったラウンド制で回しました（ラウンド 0〜10、10/30 19:08〜11/1 00:36）。

• ラウンド 0（19:08〜21:28）: 5 人が実装の前に捉え方を出し（締め切り 20 分）、指揮役が仲間分けして 2 人に出し直させ、5 人が 5 つの違う仲間（窓の小さな独立の装置、バーコード専用の紙＋補修、固定の休止状態、窓を辺とする 1 つの共有グラフ、目標に専属しない紙の辞書）になってから実装に入った。
• ラウンド 1 以降: 最良版を起点に、担当ごとに観点（gap・state・new・neighbor・speedup など）と「起点・仮説・最小の実験・続ける条件」を表にして割り当てる。締めのあとに統合役が部品を束ね、本番相当テストで確かめて昇格する。

10/31 の昼には Pro との相談（consult8・consult12）をもとに人間が割り当てを組み、運用の規則（自由な最良版の改善の担当を常に 1 本以上、割り当ての契約、30 分ごとの 4 欄の判定、否定のカードと再開の条件）を足しました。これを 11/1 19:24 にハーネスの規則のひな形（PLAYBOOK）として一般化し、以後はラウンドの区切りを使わず、担当が尽きたら新しいセッションに次の問いを渡して入れ替え、常に一定数の担当が動いている形にしました。

評価：ジャッジと同じ CPU、交互の測り、仮想時計

この問題の解は 2 秒の時間いっぱいに探索するので、点が機械の速さで動きます。後半の改善は 1 回あたり 0.01% 前後なので、測り方の工夫が勝負でした。

• 本番相当テストをジャッジと同じ CPU で測る（10/30 21:30〜）: 昇格と提出の前の本番相当テストを、ジャッジと同じ CPU（Xeon Platinum 8488C）の EC2 で 8 並列で測る。手元の 16 並列はジャッジの約 6 割の速さで、時間で打ち切る解は手元とジャッジで点が違った。機械は自動で起動し、10 分使わなければ止まる。
• 交互の測り（11/1〜）: 候補と基準（最良版）を同じ回の中でケースごとにランダムな順に交互に走らせ、昇格はその回どうしだけで比べる。きっかけは、本番相当テストの回の機械が 0.055 秒遅かっただけで候補が負けた件（版 h252）。
• 本番相当テスト（3000 件）（11/6〜）: 交互の 3000 件を足し、本番相当テストと合わせた 4000 件で判定できるようにした（本番相当テスト 1000 件だけでは、設計が変わる部品の幅が ±6 手）。
• 仮想時計（仮想時計版、11/4〜）と決定的な提出版（11/6〜）: 時間を読む所を、処理ごとに決めた料金（ns）を数える仮想時計に置き換えた版を作り、すべての判断をこの仮想時計で決める。これで出力が機械によらず決まるので、手元・2 台目の EC2・ノート PC・Pro の環境のどこで測っても同じ点になり、制御だけの小さな部品を 手元比較①②の 1000 件で ±0.01% まで比べられるようになった。決定的な提出版も判断は仮想時計で行い、実時間は非常の打ち切りだけに使うので、非常が働かない限りジャッジの出力は仮想時計版の出力と同じになる。料金は確かめ役がジャッジと同じ CPU で実測して校正した。
• 縮めの仕組み（11/8〜）: 提出の上限は 512 KiB。最良版は確かめ用の切り替えを残したまま大きくしてよいことにして、提出の版だけを機械で縮める（行頭の空白とコメントを字句の処理で消し、後には名前を短くする）。縮めた版は固定の時計で 1000 件の出力が最良版と一致することと、縮めた版での時間の確かめを条件にした。最後の 最終の提出版 FB2 は 460,370 バイト（CRLF で数えて余り約 61 KB）。
• 調速（11/8〜）: 実際の経過時間に合わせて、制御の段の任意の仕事を注文ごとに滑らかに絞る・広げる仕組み（Pro 相談 #167 から）。硬い打ち切りに頼らず、制限時間を最後まで使う。

昇格の線は測る前に decisions.md に登録し、結果を見てから線を動かさない決まりにしました。11/6 20:0x からは、登録した線を全部満たせば指揮役が自分で昇格してよいことにし、11/7〜11/9 の昇格 36 回の大半は指揮役が自分で行っています（人間が決めたのは、時間の線を動かす版や仕事を増やす版など 6 回ほど）。

ChatGPT Pro の使い方

Pro は API ではなく Web で、人間が手で使いました。流れは次のとおりです。

1. 人間の相棒（手元の Claude Code）が kit の道具で zip を作る。中身は問題文、評価の道具、入力、起点のコード、読むための写し、仮の仮想時計版、これまでの否定の記録など。依頼文（prompt_impNNN.md）も書く。
2. 人間が Pro の新しいスレッドに zip と依頼文を貼る。1 時間ごとに番号つきの途中の zip（partN）を出させ、最後の zip を短い本文より先に出させる（接続が切れても手元に残るように）。
3. 結果の zip を人間が置き、相棒が中身を自分の Python で検算する（差分を起点に当てて一致するか、CSV から数え直して一致するか）。
4. 確かめた結果を conductor/ext/pro_impNNN/ に置いて指揮役に知らせる。担当には依頼文を見せず、Pro の結果を待ちの条件にもしない（Pro がいつ戻るか分からないため、担当は同じ問いでも自分の仕事を最後まで進める）。

Pro の環境はジャッジより遅く、そのままでは探索の深さがジャッジの 3〜4 分の 1 しかありませんでした（11/4 に分かった。そのせいで Pro 相談 #71〜79 の 8 本は最良版を変えずに戻った）。そこで、ジャッジと同じ CPU で段ごとの仕事の数を測り、本番の深さに合わせた仮想時計を zip に入れて渡すようにしました。

181 件の依頼のうち、部品が最良版か最後の提出に入ったのは 36 件です（昇格した改善版の提出（handoff）の説明の文から数えた）。残りは否定の結果（再開の条件つきの「否定のカード」として記録）、ハーネスの担当と同じ結論、測りだけの問いなどでした。

ハーネスの外の担当

• 独立の試行（10/30〜11/3）: 文脈を共有しない別のエージェントに、同じ問題文と入力だけを渡して走らせた（開始時の solo・astra、11/2 の資料なしの 6 本、11/3 の 2 本など）。ハーネスの指揮役は巡回でその記録を読み、良い案があれば取り込む。最初の提出（10/30 20:28）と最初の最良版は、この solo（Codex、gpt-6.1-sol）の v20 でした。ハーネスの担当の版は 21:15 にそれを抜いています。
• ノート PC（11/7〜）: 人間のノート PC で Codex の担当を動かした。最初は自律の担当 3 本、14:1x からは Pro と同じ形の依頼を 1 件ずつ解く受け取り係（同時 2 件）。メインの PC からはできることを限った SSH の鍵（状態を見る・結果を回収する・kit に置く・担当に文を送る、の 4 つだけ）で操作し、指揮役が空きを見て自分で依頼を置き、結果を Pro と同じ手順で確かめて担当に回した。
• 外の作戦会議（11/9）: 後の「最終日の外の作戦会議」で説明します。

順位と生スコアの推移

図: 昇格した最良版の本番相当テスト（ジャッジと同じ CPU の 1000 件）の平均の手数（青、段）と、提出した版の暫定 50 件の平均の手数（橙）。右は 11/3 からの拡大。

伸びのほとんどは最初の 30 時間に出ています。最良版の手数は 10/30 20:26 の 23.63 から 10/31 23:47 の 10.71 まで下がり（本番相当テスト 24,198 → 10,970）、残りの 8 日で 10.71 → 10.24（−4.4%）でした。順位は 10/31 の朝に 2 位（170 人中）まで上がったあと、上位の人たちが伸びて 11/3 には 11 位まで下がり、11/4 からは 6〜12 位を行き来して、最後の提出の直後は 9 位、19:00 の最終の暫定順位は 10 位（787 人中）でした。後半に積んだ改善は 1 回 0.01〜0.1% の大きさで、暫定 50 件の 1 回の揺れ（約 ±0.09%）と同じくらいなので、順位表の上では見分けにくいものでした。採否は暫定ではなく本番相当テスト（と本番相当テスト（3000 件））で決めています。

本番相当テストの回ごとに機械の速さが少し違うので、上の値どうしの小さな差には揺れが乗っています。昇格の判定はいつも同じ回の中の交互の比べで行いました。

図: 最良版への昇格 111 回を、改善版の提出（handoff）を出した担当の種類で日ごとに分けたもの。Pro の部品を含む昇格は担当によらず緑にした。

昇格 111 回の出どころは、Claude の担当 39 回、Pro の部品を含むもの 26 回、Codex の担当 24 回、統合役（Claude）22 回でした。前半は担当が直接最良版を更新し、後半は Pro の部品と統合役の束が増えています。

人間の判断と、判断のためのまとめ

人間がしたこと

解答のコードを書いたのはエージェントです（記録の上で、人間が書いた解答の版はありません）。人間がしたのは次のことです。

• 提出: 52 回すべて人間が手で行った（提出は 30 分以上の間隔）。出すたびに順位表を保存し、暫定の点と最大の実行時間を記録に入れた。
• 方針と線: 目標（優勝を狙う、2 位を追わない）、作った目標の文、強制的に昇格させる基準、時間の線、大きさの方針、凍結と時刻表、担当の本数とモデル。
• 案: 割り当ての案 A（比較グラフ）、「次の注文が同じ主紙の組なら戻さなくてよい」などの小さな部品の案、紙を無限にしたときの実験、無駄な手の探し、過去の棄却の測り直し。
• AI の使い方そのものの改造: EC2、交互の測り、決定的な提出版、ノート PC、2 台目の EC2、見張り役と批評役、外の作戦会議。コードは人間の相棒（手元の Claude Code）が書き、人間が承認した。
• Pro の窓口: Pro の依頼を出して結果を置くこと（181 件）。

人間からハーネスへの文は 941 通で、日ごとに 10/30 46、10/31 74、11/1 34、11/2 20、11/3 46、11/4 47、11/5 23、11/6 85、11/7 111、11/8 237、11/9 218 通でした（人間の相棒が人間の決めを送ったものを含む）。平日（11/2・11/5・11/6）は朝と夜しか返事ができないので、指揮役は返事を待たずに進め、人間だけが決めることは保留する決まりにしていました。

判断しやすいように作らせたまとめ

記録の decisions.md は最後に約 150 万字（10,700 行）になり、人間がそのまま読める量ではありません。そこで、決める時に読むまとめを AI に作らせました。

まとめ	いつから	中身
「人間へ」（decisions.md の節）	11/2 から 1 日 1 回、朝 06:30 まで	夜の結果、今の最良版と提出の候補、人間に決めてほしいこと
一画面の判断表	11/3 18:00 から（Pro consult15 の提案）	現行・提出済み・控え、候補ごとの数字、閉じた問い、動いている担当、次の門、失敗と時間、人間が今判断すること
夜のまとめと朝の決め（MORNING_PLAN.md、MORNING_1109.md）	11/8〜11/9	最良版と候補、昇格と本番相当テストの回数、閉じた問い（再開の条件つき）、測った表、朝の次の問い
5 行の進み（PROGRESS_1109_1030・1200・1400・1530）	11/9	本数と各問いの数字、批評役と見張り役への答え
1 ページの要約（ONE_PAGE.md）	最終日	昇格ごとに先頭へ追記。新しい担当はここから読む
案の在庫（IDEA_STOCK.md）、閉じた問いの一覧	11/8〜	同じ問いの繰り返しを防ぐ。在庫役が 60 分おきに更新
作戦会議のまとめ（FINAL.md）	11/9	上位の案、やらないこと、割れた点を多数決で消さずに両論で
最後のまとめ（FINAL_1109_1746.md）	11/9 17:46	最後の提出、確かめ、攻めの結果、戻しの規則
通知（ahc notify）	全期間で 348 回	昇格、提出の候補、安全の知らせ

一画面の判断表の例（11/3 18:00 の分から一部。中身は記録のまま、行を減らした）:

項目	中身
現行・提出済み・控え	最良版＝提出済み＝版 h278（11/3 12:12 提出、10 位）。控え＝版 h277・版 h276・版 h273
候補 1: 版 h280・版 h281（設計の中の軽い模擬で群の割り当てを選ぶ）	交互の本番相当テストで順位指標 +6.6 ±6.15・絶対スコア比 +0.176%、失敗 0、最大 1.66 秒。確かめ役が時間の門の穴を見つけて昇格せず、直した 版 h281 を再検査中
閉じた問い	構造の新しい探索（7 床の共同設計など）、床の容量を探索の量で取る、見ればわかる無駄
次の門	版 h281 の再検査、直した版の交互の本番相当テスト→ 通れば昇格して提出の候補として知らせる。21:00 に次の判断表
失敗と時間	失敗はどの候補も 0。本番相当テストの最大はどの候補も 1.66 秒以下

人間はこの表を読んで、17:52 に確かめ役の追加の検査が終わる前に 版 h282 を提出する判断をしています（記録上は人間の判断として残っている）。候補・数字・閉じた問い・次の門が 1 画面にあることで、短い時間で決められました。

最終日の外の作戦会議

最終日の昼、手元の CPU は担当のコンパイルと測りで埋まっていた（負荷 40 前後）一方、エージェントの使用量にはまだ余裕がありました。そこで人間は、CPU を使わない、読むだけのエージェントどうしの作戦会議をハーネスの外で開きました。どの会議も、記録（decisions.md、担当の notes、案の在庫、Pro の結果）を読むだけで、コンパイル・実行・ファイルの変更・Web 検索はしない決まりです。小さな Python のスクリプトが claude -p（読むだけの道具に限定）と codex exec（読み取り専用のサンドボックス）を並列に呼び、出力を out/ に残しました。

回	顔ぶれ（モデル・推論の強さ）	問い	出たもの	採ったもの
① 作戦会議 10:44〜11:29	A 解き方と点の数学（Opus 5.5 max）、B 運用（Opus 5.5 max）、C 縛りなし（gpt-6-astra ultra）、まとめ役（Opus 5.5 max）。独立に案 → 互いの批評と改訂 → まとめ	15:30 までに順位の期待を一番上げる動き	上位 3 案（守り入りの版を仮提出して床を上げる／本番相当テストは結果が決まる腕だけに使い、凍結して決めの表で選ぶ／落ちの狩りを最終の形に向ける）、やらないこと、割れた点（両論）	R1 の仮提出、凍結と決めの表
② シンプル化の相談 13:06〜13:33	A 探索の専門家（Opus max）、B 反論役（Opus max）、C 縛りなし（gpt-6-astra ultra）、まとめ役	人間の経験（AHC002 で上位解を削ってシンプルにしたら伸びた）が、部品の詰め合わせの最良版に当てはまるか	「15:30 までにシンプル化で大きく伸ばす余地はない」はほぼ妥当。ただしアシスタントの根拠 1〜4 には測り方の穴があり書き直しが要る。AHC002 で効いたのは削ったことより 1 提案の止め方	新しい腕は出さず、制御だけの改善に残りの時間を使う
③ 監査と案出し 13:42〜14:46	監査役 3、RE の調べ役 1、案出し 3 人 × 3 回（すべて Opus 5.5 max）	最終の候補の安全の穴、15:00 までに本番相当テストに出せる小さな腕	腕の候補（FR1 の予算 ×2、調速の倍率の上限、出力の直前の再圧縮 FCLO など）と監査の所見	UB2c5 と FCLO3 が最後の最良版に入った
④ 最後の 1 本の決め 15:50〜16:11	A 点の期待（Opus max）、B 失敗の危険（Opus max）、C 縛りなし（gpt-6-astra ultra）、まとめ役	18:00 までに出す最後の 1 本と控え	勧め FB・控え F、割れた点（FB か FU5 か、確かめが間に合わないとき）	16:1x の最後の決めの規則（A 案）
⑤ 攻めの案出し 16:47〜17:33	10 人（Opus 5.5 high、視点を 1 人ずつ変える）→ 選び役 3 → まとめ役。その後 10 人＋まとめ役を 6 回	FB2 の上で 17:35 までに本番相当テストに出せる制御だけの腕（差分の文字列つき）	順位表 7 枚	本番相当テストに 6 本（どれも線を通らず）、門で 3 本を落とした

作戦会議の価値は、点そのものより判断の速さでした。人間が 1 人で記録を読み比べると時間がかかる問い（何を最後に出すか、守りをどこまで入れるか）を、30〜60 分で両論つきの 1 枚にしてくれました。③ の案出しは、最後の最良版の部品にもなっています。5 回で 108 回の呼び出し、合計 10.8 時間でした。

モデルと稼働時間

wata さんの解説にならい、モデル・推論の強さごとの稼働時間を数えました。合計は約 1,976 時間（ハーネスの中 1,868 時間、外の作戦会議・ノート PC・独立の試行を含む。ChatGPT Pro の 181 件は別）。Anthropic の Claude Code（Claude Opus 5.5・Claude Fable 5.1）と OpenAI の Codex CLI（gpt-6.1-sol・gpt-6-astra）を、同じハーネスの中で同じ規則で動かしました。モデル別の表と数え方は付録にあります。

図: モデル・推論の強さごとの稼働時間（ハーネスの担当・外の作戦会議・ノート PC の合計）。

何が効いたか

• 測れる形に変えたことが、後半の改善を拾えるようにした。 EC2 での本番相当テスト（10/30）、交互の測り（11/1）、仮想時計と D（11/6）、本番相当テスト（3000 件）（11/6）がなければ、0.01% 単位の部品は揺れに埋もれて採れなかった。後半の 8 日の −4.4% は、ほとんどがこの大きさの部品の積み重ねです。
• 「常に動いている自由な担当」と「尽きたら新しいセッション」。 構造の割り当てより、今の最良版を測って原因を 1 つ見つけて直す自由な担当の副産物の方が効きました（GF の開始温度、古い補助の返却の省略など）。担当は「尽きた」と言いがちなので、止めずに別の切り口で作り直す決まりが要りました。
• Pro は、難しくて大きな問いに、違う切り口で。 最良版に入った Pro の部品は、仕組みの変更（共有の紙の組、受理済みの組の保護、調速、捨てられた候補の修理）と、出力を変えない高速化、安全の直しでした。古い土台の上の部品や、定数の振り直しは入りませんでした。
• 人間の判断は「線を決める」こと。 強制的な昇格の基準（絶対スコア比）、時間の線、大きさの方針、時刻表、全自動の昇格の範囲を人間が決め、その中は AI に任せました。

まとめ

はじめてのWith AI部門ということで、Human Only部門参加者やWith AI部門に参加していてもChat Gptに直接「改善して」と繰り返し投げるだった一部の方には「たまたまAIがいい解法を引くのを待つだけの運ゲー」と思われているかもしれません。しかし、実際にはある程度戦略を練って事前準備することで、ある程度いい成績を収めることができました。今後もWith AI部門が続きそうであれば、あらかじめ準備をしておく好成績が残せると思うので、この記事を参考にハーネスをつくっておくことをオススメします。また、「特に大きく効いた人間の判断」の項で記載した通り、With AI部門でも人間の判断は大きく効くことがわかりました。最終順位Top3が全員レッドコーダーであることからも、過去のAHCで得た経験は今後も活き続けると感じています。僕も常に過去問を解き続けていたからこそ、取捨選択がしやすかったと思います。

そこで宣伝です!!

『AHC入門～見て、考えて、改善するAtCoder Heuristic Contest』

2026年12月3日に技術評論社より出版します！！

AIのテクニックは取り扱わないのでHuman Only部門にもぴったり！先述の通り、With AI部門にもきっと活きる！AtCoder監修でwataさんも大絶賛！
ぜひ読んでください！！！！！！！！！

付録

付録 A: リハーサル 9 回の詳細

本番の前に、公開済みの過去問で通し運転を 9 回しました。題材は相対評価の最近の問題 AHC072（最小化）と AHC069（最大化）です。上位の解との比（1 位比）は、人間だけが見られる別の場所で公式の 2000 件を測って出し、ハーネスには見せませんでした（実験の意味がなくなるため）。

回（日時）	条件	結果（1 位比）	分かったこと	直したこと
AHC072 フェーズ制（10/23 11:59〜）	案出し 2・分析 1・探索 4・統合 1	最良 70.86%	Codex の担当はサンドボックスで git が読み取り専用になり改善版の提出（handoff）が失敗。確認の画面や入力待ちで止まっても作業中に見えて、25 分気づかなかった	確認なしで起動、改善版の提出（handoff）は評価の前に写し取る、画面が 10 分変わらなければ促す、最終確認用の本番相当テストを足す、tmux のサーバーを分ける（設計書 v0.4）
AHC069 耐久試験（10/23 13:44〜16:12）	運転中に担当・評価・指揮役を 5 回わざと止める	5 回とも notes.md から数分で復帰	時間で打ち切る探索は、評価の 16 並列の負荷で探索の量が 30〜50% 減る	評価の枠を CPU に固定、時間切れでプロセスごと止める。開発中は仕事量で打ち切る規則
AHC072 8 時間（10/23 17:44〜）	ラウンド制、担当に手法（焼きなまし・ビームなど）を割り当て	8.1 時間で 73.28%（稼働 38.4 時間）	手法で分けた 5 人と自動の相談役が全員同じ捉え方に集まり、56〜59% に固まった	最初のラウンドに「捉え方の段階」（実装の前に FRAMING.md を出し、指揮役が問題の分け方で仲間分けし、重なれば出し直し）、別の系統を残す --keep
AHC072 2.5 時間（10/24 01:46〜）	捉え方の段階つき	2.6 時間で 73.29%（稼働 14.3 時間）	8 時間の運転と同じ所に 3 分の 1 の時間で着いた。担当の試作が 27 GB に膨らみ PC 全体が止まった	評価は制限の 2 倍のメモリで打ち切り、担当はメモリの上限つきの枠で動かす
AHC069 6 時間（10/24 10:55〜）	対話型の問題	6 時間で 99.42%（4 位相当）	問題文から見える捉え方で勝てる問題なら上位に届く。最終版は 2 秒のうち 0.3 秒を使い残した	時間を使い切る目安（制限の 90〜93%）を共通の制約に。指揮役も max で動かす
AHC072 比較（10/25 12:07〜）	Pro の 2 回目のレビューの指摘（採否を本番の得点の式で決める、昇格の検査）を入れた版で、2.5 時間の回と同じ条件	63.64%	同じ捉え方・同じモデルでも、前の回はビーム（A 98.05）、今回は貪欲（88.35）になり 1 位比で 9 ポイント違った。指揮役が「採点器が不正な出力に 0 点を出し、最小化では 0 が最良になる」穴を見つけた	最初のラウンドで同じ捉え方を 0 から作り直して測って選ぶ（--replicas）、評価を 50 → 200 → 500 → 全件と段階的にして向きが決まったら打ち切る、最小化の 0 点は不正として扱う、評価を裏で回さない
AHC072 作り直し（10/25 15:41〜）	作り直しの仕組みの試験（同じ捉え方を 2 回ずつ）	同じ捉え方の回どうしで 27・2・12 点の差	作り直しが無ければ、良い捉え方を外れの実装で低く見積もるところだった	本番の既定を「作り直し 3 回 × 90 分」に。捉え方の提出の締め切りを担当の方針に書く
AHC072 48 時間（10/26 00:15〜10/28 00:15）	24 時間目に 1 位との差を 1 回だけ伝える	86.95%（推定 76 位）	詰まりは「生成（決め手の捉え方が出ない）・選択（未熟な良い案が成熟した最良版に負けて捨てられる）・育成（新しい核が小さな後段のまま）」の 3 か所。時間を足しても伸びず、足りないのは局所最適から抜ける仕組みだった	下界（伸びしろの上限）の担当、過去の AHC の解き方の索引を担当に読ませる、伸びが止まったら時間を足して測る規則
ChatGPT Pro の 0 からの試行（10/27〜10/29）	問題文だけ・解き方の索引つき・自己改善 22 版	61.09%・60.53%・60.29%	同じ依頼文では毎回同じ捉え方になる。一方、ハーネスの版と仮説を渡して検証させると強い（88.37%、推定 65 位）	Pro には捉え方や仮説を変えて出す。1 回の依頼の中で改善を繰り返させる。zip を作る道具（kit）と依頼の記録（LOG.csv）

リハーサルの最終時点の役割:

役割	担い手	すること
指揮役（conductor）	Claude Code 1 本	ラウンドを開き、担当ごとに観点（初手・近傍・新しい骨組み・評価・系統など）と締め切りを割り当てる。締め切りで結果を集め、統合役を立て、昇格を決める。人間とのやりとりの窓口
ラウンドの担当（worker）	Claude Code と Codex CLI、1 ラウンドに 4〜6 本	最良版（main。ハーネスが今いちばん良いと認めた版）から出発し、割り当てられた観点で締め切り（約 1.5 時間）までに改善して改善版の提出（handoff）する。最後のリハーサル（AHC072、10/26〜10/28）では 19 ラウンドで延べ 92 本
統合役（merger）	Claude Code、ラウンドごとに 1 本	そのラウンドの各担当の best.cpp と notes.md を読み、部品ごとに採否を測って 1 本にまとめる（取捨選択も兼ねる）。同じリハーサルで延べ 15 本
自動の相談役（advisor）	Codex CLI（codex exec）	実行はせず、相談の包み（状況と問い）に答えて案を出す。案は idea として登録される。同じリハーサルで 4 回・19 案
評価器（ahc eval）	ハーネス本体（エージェントではない）	全担当で共有の評価の枠で動作確認・選別・手元比較①②・本番相当テストを流し、SQLite に記録する。昇格は本番相当テストで勝ち・失敗 0 を確かめる
下界担当（bounder）	Codex CLI	制約をゆるめた問題で、最適解がそれより良くなれない値をケースごとに計算する。伸びしろの上限を知るために 1 回だけ試した（10/26）
（初期だけ使った役）	—	初回のリハーサル（10/23）では、方針ごとに独立に解を作る explorer、入力の区分を調べる analyst、実行せずに案だけ出す ideator、差分を 1 つずつ外して測る ablator（10/23〜24）も使った。どれも、ラウンドの担当と統合役の形に置き換わった
（用意したが使わなかった役）	—	入力の区分ごとの専門担当 specialist、全ケース担当 generalist、区分ごとの解を 1 本に組み上げる assembler（AHC003 のような入力ごとの差が大きい問題のため）、解説を書く writer

付録 B: スコアに効いた AI の使い方の時系列

種類は 4 つに分けました。指示＝人間からハーネスへの指示（指揮役・担当・全担当への文）、改造＝ハーネスのコード・設定・役割の追加、Pro＝ChatGPT Pro への相談、判断＝人間の判断（提出、強制的な昇格、方針、時刻表）。参考に、担当が自分で見つけた大きなものを「自走」として入れました。効果の数字は記録（decisions.md と db）からです。

立ち上げ（10/30〜10/31）

日時	種類	中身	記録に残る効果
10/30 19:04	改造	共通の入力群（動作確認・選別・手元比較①②・本番相当テスト）を作り、区分は使わないと決めた	全担当・独立の試行・Pro が同じ入力で比べられた
10/30 19:08	指示	ラウンド 0: 実装の前に捉え方を出す（20 分）、指揮役が仲間分けして 2 人に出し直させる	5 人が 5 つの違う捉え方で始め、21:15 にハーネスの最初の最良版（本番相当テスト 22,514）
10/30 20:14	判断	人間の方針メモ「目標は優勝。使用量は使い切ってよい」。Codex の担当を推論の強さ ultra に（20:17 に道具ごとに強さを決める改造）。独立の試行 solo の良い版を起点にしてよい	20:26 に solo の v20 を最良版にして、20:28 に最初の提出（61 人中 9 位）
10/30 21:30	改造	本番相当テストをジャッジと同じ CPU の EC2 で測る（ahc eval --set 本番相当テスト はそのまま）	以後の昇格はすべてジャッジと同じ CPU の実時間で判定
10/30 22:18	自走	Claude の担当 r1-new3 が「専用の紙＋入れ子の取っ手」の構造を作った	本番相当テスト22,514 → 15,749（−30%）、22:38 の提出で 21 位 → 9 位
10/30 23:3x	指示	次のラウンドの割り当て（人間の案 A: 残差を比較グラフで表す）	10/31 00:37、Codex の担当 r2-state2 が Pro 相談 #3 の上で当てて 版 h52（本番相当テスト 13,232、−5.9%）
10/31 00:01	Pro	Pro 相談 #3（起点はその時の最良版、作った目標「1 位は約 10 手。大きな見落としがある」を付けた）	共有の紙の組の構造。00:06 に提出して 6 位、00:11 に最良版（本番相当テスト 14,059、−8.3%）
10/31 00:4x	判断・指示	Pro 相談 #3 が効いたので、同じ作った目標を全担当に配る。下界の担当をやめる。担当の上限を 8 にして Codex の担当を 2 本足す	一晩で 13,232 → 11,380（版 h141、−14%）。09:19 の提出で 170 人中 2 位
10/31 11:15	Pro・判断	Pro consult8（担当の割り当ての相談）の案を照合して、人間がラウンド 6 の割り当てを組んだ	ラウンド 6 で 11,348 → 11,200（版 h159 → 版 h177）
10/31 14:02	Pro・判断	Pro consult12（運用の相談）: 自由な最良版の改善を常に 1 本、割り当ての契約、30 分の判定、否定のカード	ラウンド 7 以降の運用になり、11/1 19:24 に PLAYBOOK へ一般化
10/31 18:3x	自走	Claude の自由な担当 r8-free-main-c が、設計の焼きなまし（GF）の開始温度の不具合（3 → 30）を見つけた	「GF は飽和した」は局所解の見かけだったと分かった。版 h211〜版 h219 で 11,098 → 11,021

作った目標について。 10/31 00:4x と 09:30 に、人間は全担当へ「With AI 部門の 1 位は 1 注文あたり約 10 手（09:30 からは約 9 手）で解けているはず。何か大きな見落としがある」という文を配りました。これは根拠のない、わざと作った目標です（順位表には順位の点しか出ないので、他の人の手数は分からない）。細かい調整ではなく構造を変える試作を促すための指示で、Pro の Pro 相談 #3・Pro 相談 #4〜Pro 相談 #7・Pro 相談 #10・Pro 相談 #11 の依頼にも同じ種類の目標を付けました。一方、ハーネスの外の独立の試行（11/3）で、0 から作らせる担当に作った目標（約 7 手）を付けた回と、正直に「分からない」と書いた回を比べたところ、どちらも良い構造は出ず、差はありませんでした。作った目標が効くのは、動く土台がある時だけだったと見ています。

中盤（11/1〜11/5）

日時	種類	中身	記録に残る効果
11/1 10:15	改造	交互の本番相当テスト（候補と基準を同じ回にケースごとに交互に走らせ、昇格はその回どうしだけで比べる）	機械の速さの揺れが差から消えた（きっかけは、本番相当テストの回の機械が 0.055 秒遅かっただけで落ちた候補 版 h252）
11/1 15:07	Pro	Pro 相談 #35 v09（組を大域の LNS で選び直す）を統合役が束に	版 h260（交互の本番相当テストで +0.218%）
11/1 23:45	Pro・判断	Pro consult13（探索の進め方の相談）: 構造の線は 2・6・12 時間の節目で判断する。人間の予定（平日は朝と夜だけ）に合わせて、指揮役は返事を待たずに 1 日 1 回「人間へ」を書く	人間が寝ていても止まらずに回る運用になった
11/2 18:0x	改造	順位の式の昇格に「絶対スコア比（手数の比の平均。正なら良い）の 95% 区間の上限 > 0」を足した（勝ち負けの式は差の大きさを見ないため）	大きさで負ける候補を昇格させない
11/2 23:5x	指示	自由な最良版の改善の担当は、実際に動いているものを常に 1 本以上。尽きたと言ったら止めずに、新しいセッションで別の切り口を渡す	11/3 02:0x に r30-free の部品で 版 h276（絶対スコア比 +0.109%）
11/3 09:5x	判断	版 h277（小さな部品 5 つの束）を人間の判断で強制的に昇格。順位指標（本番と同じケースごとの順位の式で数えた勝ち負けの差）の下限は 0 を割るが、絶対スコア比 +0.084% [+0.016, +0.152] は正	「順位の点も差の大きさが効く」という判断。以後の束の積み上げの起点
11/3 13:3x	Pro・判断	Pro consult15（戦い方の相談）: 4 つの方向への配分と見切りの線、一画面の判断表	18:00 から判断表を人間に出す形にした
11/3 22:46	Pro	Pro 相談 #65 v05 safe（受理済みの組を部分的に守る）	版 h285（手元比較①（1000 件）絶対スコア比 +0.248%）、22:59 の提出で 11 位 → 9 位
11/4 18:1x	判断・改造	ジャッジと同じ CPU で段ごとの仕事の数を測り、Pro に渡す仮想時計を本番の深さに合わせた	Pro の部品が最良版と同じ形で戻ってくる原因（Pro の環境の浅さ）を除いた
11/5 03:40〜09:40	Pro	Pro 相談 #70 V01・Pro 相談 #82 B05（束 R″ に）、Pro 相談 #84 M02・Pro 相談 #88 M18・Pro 相談 #89 P05（出力を変えない高速化、束 B5t に）	R″（+0.21%）と B5t（+0.158%）
11/5 17:32	判断・Pro	M2（担当 r70 の部品 S と Pro 相談 #94 の G1 を混ぜた版）を人間が強制的に昇格	版 h333（本番相当テスト絶対スコア比 +0.084%）
11/5 20:5x	判断	方針をアシスタントに任せる（「順位の期待値が最も改善する動きにしてください」）。自由な担当を 2 本足し、構造の試しは 3 本に絞り、11/9 までの節目を決めた	以後の配分の基準になった

終盤の仕組みづくり（11/6〜11/8）

日時	種類	中身	記録に残る効果
11/6 07:5x〜13:29	判断・Pro	最良版は縮めず、読むための写し（行番号つき、使われない分岐を除く）を担当と Pro に渡す。Pro 相談 #109 の整理版（出力は同じ、大きさ −27.6%）に切り替える	版 h347（clean）
11/6 13:3x	判断・改造	決定的な提出版（判断はすべて仮想時計、実時間は非常の打ち切りだけ）を試す。決定的な提出版の系統の昇格は仮想時計版の手元比較①（1000 件）・手元比較②（1000 件）の生の区間で判定する	20:37 に D11 が最良版。制御だけの小さな部品を ±0.01% の幅で積めるようになった
11/6 20:0x	判断	昇格の全自動化（登録した線を全部満たせば指揮役が強制的に昇格して人間に知らせる）	11/7〜11/9 の 36 回の昇格の大半を指揮役が自分で行った
11/6 20:3x	改造	本番相当テスト（3000 件）（3000 件）の交互の比べ	本番相当テストと合わせた 4000 件で、設計が変わる部品も判定できるようになった
11/7 09:05〜14:2x	改造・判断	ノート PC の Codex の担当 → 制限つきの SSH（11:05）→ 受け取り係（14:1x）→ 依頼の全自動（14:2x）	44 件の依頼。出力を変えない速さの直し c02 が 版 h380 に入った
11/7 12:1x・14:0x	判断	時間の線を緩める。非常の線 1.55 → 1.65 → 1.75 秒、EC2 の最大の線 1.80 → 1.90 秒（根拠: EC2 とジャッジの最大の比は 1.03〜1.19 で EC2 の方が速かったことは無い、非常の後の締めは最大で約 0.12 秒）	EL165・EL175 が最良版に。次の FS80 の前提になった
11/7 16:4x	判断	FS80（料金を一律 ×0.80＝仕事を約 25% 増やす）を最良版に	16:48 の提出で暫定 −0.134%
11/7 21:0x	判断	「1 つずつ最良版と比べて勝ったものだけ入れるのは、座標ごとの山登りで局所解に止まる」。形の変更は周りの定数を詰め直してから比べ、小さく正の部品は束ねる	詰め直しの担当 r100、束ねの r102
11/7 23:29	Pro・判断	Pro 相談 #151 A2（制御だけ）を人間が本番相当テストの前に提出	暫定 −0.068%（Pro の 700 件の +0.0685% とほぼ同じ）、11/8 00:06 に 版 h381
11/8 00:30	Pro・判断	Pro 相談 #153 FR（制御だけ）を提出	暫定 −0.1145%、01:13 に 版 h384（本番相当テスト 10,554 → 10,543）。夜の間に指揮役が FR の上へさらに 6 回昇格
11/8 09:5x	判断	大きさの方針: 最良版は縮めず、提出は最良版を機械で縮めた版（CRLF で 522,240 バイト以下）	Pro 相談 #155 の P400 などの大きい部品が入った（版 h397、仮想時計版の A で絶対スコア比 +0.089%）
11/8 15:1x〜15:4x	改造	2 台目の EC2（仮想時計版の手元比較①②だけ）と中継役。担当の上限を 22 本に	1 台目（本番相当テスト・本番相当テスト（3000 件））を時間の測りだけに使えるようになった
11/8 21:2x	Pro	Pro 相談 #167 調速（経過時間に合わせて任意の仕事を滑らかに絞る・広げる）	22:50 に 版 h420（本番相当テスト順位指標 +16.3、絶対スコア比 +0.029%）

最終日（11/9）

日時	種類	中身	記録に残る効果
09:1x	指示	夜の 05:00 ごろに指揮役が改善の担当を全部止めていた → 6 本以上ですぐ立て直す。Fable をやめ、Opus と gpt-6-astra に寄せる	8 本で再開（昼には 12 本）
09:2x	判断	時刻表を延ばす（改善は 15:30 まで、16:00 に最終の候補、16:00〜18:00 は守りの段、提出は 18:00 まで）	午後の 3 回の昇格の時間ができた
09:2x	指示	時間の線の担当: 調速の目標 1.82 → 1.88 秒、非常の線 1.84 → 1.90 秒	10:49 に 時間の線の引き上げ（T0）（本番相当テスト＋本番相当テスト（3000 件）の 4000 件で絶対スコア比 +0.0063%）
09:3x	改造	見張り役（15 分おき）と批評役（30 分おき）を足す。どちらも評価やコンパイルはしない	批評役の異議は 24 件。指揮役は採否と理由を進みのまとめに書いた
10:5x	指示	前提（制御の部品・調速・X1 の上限）が変わった後で、過去に棄却した制御だけの変更を測り直す	12:50 に b125（X1 の値段の倍率の傾きの 1 行、4000 件で絶対スコア比 +0.020%）
11:3x・12:5x	Pro	Pro 相談 #171: 既知の assert の RE の守り B01 を確かめた（80,192 の状態で値が bit まで一致）。Pro 相談 #172: 新しい自然の RE・WA は無し、守り p01 を提案	最後の版に B01・p01 を入れた
11:4x	判断	作戦会議 ① の案: 守り B01 入りの提出版 R1 を先に仮提出し、午後が崩れても床を残す	12:50 ごろ R1 を提出（暫定 524,293、最大 1826 ms）
13:0x	Pro	Pro 相談 #173: 捨てられていた「1 手得するが終わりの状態が悪くなる」候補を作り直す	FR1（本番相当テスト順位指標 +16.2、絶対スコア比 +0.0042%）→ 14:05 に PG6 と FR1 を入れた最良版（PGFR）（PG6＋FR1、絶対スコア比 +0.0073%）
14:0x〜14:4x	判断	人間が確かめの抜けを見つけた: B01 は入っているファイルでしか効かない、PGFR に p01 が無い → 毎回 grep で数える決まりに	最後の版の確かめの項目になった
14:1x〜14:5x	判断	作戦会議 ③ の案出し役の案: FR1 の予算 ×2・調速の上限、出力の直前の再短縮（FCLO）	調速の上限 5 と FR1 の予算 2 倍（UB2c5）（絶対スコア比 +0.0038%）と 出力の直前の再短縮（FCLO3） を束ねて、15:54 に最後の最良版（絶対スコア比 +0.0043%）
15:06	判断	F（PGFR＋守り）を提出	暫定 523,783、10 位 → 9 位
16:1x	判断	作戦会議 ④ の A 案を最後の決めの規則に（縮めた版の一致・Pro 相談 #176 に止める所見なし・確かめ役の途中の結果に 1.95 秒越え 0 が揃えば FB）	16:14 に FB を提出
16:2x	Pro	Pro 相談 #176: 早い非常の発火の後に任意の探索が走りうる穴 → 1 行の直し	FB2（FB＋1 行）。Pro 相談 #177 も「FB2 を出す」を勧めた
16:4x〜17:46	判断	作戦会議 ⑤ の案出し役 10 人の順位で、FB2 の上の制御だけの小さな腕を本番相当テストに	6 本とも線を通らず（失敗 0）。攻めは出さない
17:04	判断	FB2 を提出（最後の提出）	暫定 523,801、最大 1885 ms、提出の直後は 9 位（19:00 の最終の暫定は 10 位）

付録 C: 途中の構成（10/30 夜〜11/5）

中盤（10/30 21:30〜11/5）:本番相当テストを EC2 へ、統合役と確かめ役が常駐、交互の測り。

付録 D: モデルと稼働時間の詳細

wata さんの解説にならい、モデル・推論の強さごとの稼働時間の合計を出しました（並列に動いた担当は別々に数えて足しています）。

場所	道具	モデル	推論の強さ	稼働時間	数
ハーネス	Claude Code	Claude Opus 5.5	max	516.9 時間（うち 418.2 は既定の推定）	68 セッション
ハーネス	Claude Code	Claude Opus 5.5	high	427.9 時間（うち 402.7 は既定の推定）	54 セッション
ハーネス	Claude Code	Claude Fable 5.1	max	123.8 時間	35 セッション
ハーネス	Claude Code	Claude Fable 5.1	high・medium	18.5 時間	11 セッション
ハーネス	Codex CLI	gpt-6.1-sol	ultra	428.8 時間（うち 90.3 は既定の推定）	105 セッション
ハーネス	Codex CLI	gpt-6.1-sol	xhigh	134.5 時間	9 セッション
ハーネス	Codex CLI	gpt-6.1-sol	high・max	34.8 時間（max の 2.1 は既定の推定）	12 セッション
ハーネス	Codex CLI	gpt-6-astra	ultra	183.2 時間	37 セッション
ハーネスの小計				1,868.5 時間（Claude 1,087.1・Codex 781.3）	331 セッション・232 担当
外の作戦会議（11/9）	Claude Code	Claude Opus 5.5	max・high	10.4 時間	104 回の呼び出し
外の作戦会議（11/9）	Codex CLI	gpt-6-astra	ultra	0.3 時間	4 回の呼び出し
ノート PC の自律の担当（11/7）	Codex CLI	gpt-6-astra	ultra（12:3x から xhigh）	13.3 時間	3 担当
ノート PC の受け取り係（11/7〜11/9）	Codex CLI	gpt-6-astra	xhigh	43.6 時間（推定）	44 件の依頼
独立の試行（10/30〜11/3、ハーネスの外）	Claude Code・Codex CLI	Opus 5.5 xhigh、gpt-6.1-sol ultra・xhigh、gpt-6-astra ultra		約 40 時間（推定）	12 本
合計（Pro を除く）				約 1,976 時間
ChatGPT Pro	Web	ChatGPT Pro	―	依頼から受け取りまで中央値 1.3 時間	181 件

役割で分けると、ハーネスの中では指揮役 239.9 時間（ほぼ全期間に 1 本）、統合役 232.9 時間、Claude の改善・確かめの担当 614.7 時間、Codex の担当 781.1 時間でした。

図: モデル・推論の強さごとの稼働時間（ハーネスの担当・外の作戦会議・ノート PC の合計。model の指定が空のセッションは既定のモデルと推定して足した）。

図: ハーネスで同時に動いていたセッションの数（20 分ごと、Claude Code と Codex CLI の積み上げ）。11/8 の午後に最大 21 本。

稼働時間の数え方

• ハーネスの担当: 出来事の記録（events.jsonl）の lane_launch（担当の起動と作り直し。その時のモデルと推論の強さが入っている）から、同じ担当の次の lane_launch か lane_stop までを 1 本のセッションの時間とした。止める記録が無いまま終わった担当は、db の状態が stopped なら db の最後の更新の時刻、動いていた担当は 11/9 19:00 で切った。セッションの中で評価を待っていた時間や「続けて」を待っていた時間も含む（セッションが生きていた時間）。PC の再起動で止まった数分（11/1・11/6）は分けていない。
• 既定のモデルの推定: 起動の記録の model が空のセッションは、その時の既定（Claude Code は Claude Opus 5.5、Codex CLI は gpt-6.1-sol）と推定した。リハーサルの記録でも既定は同じだった。
• 外の作戦会議: 各会議の panel.log の、呼び出しごとの所要秒数の合計。
• ノート PC: 自律の担当は NOTES.md の開始（09:05）から最後のログ（12:14〜14:09）まで。受け取り係は、依頼を置いた時刻と結果の時刻から、同時 2 件の待ち行列として開始を推定した。
• 独立の試行: メモに残る開始と終了の時刻からの粗い推定（開始時の solo 約 5.7 時間・astra 約 4.7 時間、11/2 の資料なしの 6 本で約 24 時間、11/2 夜の 2 本で約 3.3 時間、11/3 の 2 本で約 2.5 時間）。
• ChatGPT Pro: kit が依頼の zip を作った時刻（LOG.csv）から、結果の zip を受け取った時刻までの時間（181 件のうち結果のある 177 件）。人間が貼るまでと受け取るまでの遅れを含む上限で、Pro が考えていた時間そのものではない。夜をまたいだものを 3 時間で切ると合計 269 時間、切らないと 386 時間。依頼は日ごとに 10/30 5、10/31 22、11/1 19、11/2 10、11/3 20、11/4 17、11/5 16、11/6 27、11/7 21、11/8 16、11/9 8 件。
• 数えていないもの: 人間の相棒（手元の Claude Code との対話）、ハーネスの中の自動の相談役（Codex。開始・毎日・自由の相談に答えた分）、設計の相談役（Fable、11/2・11/3）と読むだけの監査（Fable、11/4）。記録の上で時間が分からないため。

Anthropic と OpenAI の両方のエージェントを、同じハーネスの中で同じ規則で動かしました。担当ごとに、そのとき空いている方を選んでいます。どちらが良いかは担当の問いと交絡しているので比べていませんが、昇格の数では Claude の担当 39 回・統合役 22 回、Codex の担当 24 回、Pro の部品を含む 26 回でした。