AHC074 With AI 参加記：AI をどう使い、どの指示が効いたか

0要約

• 手元の平均は、各 bit 独立の解法（32.0 手/注文）から、最終版の 10.0 手/注文（平均スコア 10247） まで下がりました。暫定順位は 11-09 朝の時点で 3 位です（最終順位は確定後に追記します）。
• 最初に手で試した解法（33.6 手/注文）のほかは、私はコードを書いていません。私がしたのは、評価の仕組みを整えること、方針と制約を与えること、結果を見て次の指示を出すこと、外部の AI の成果を持ち込むことでした。
• 階段状の解法（後述の hub 構造）は、コンテスト初日の深夜に、Claude Opus 5.5 の 1 セッションが約 70 分で自力で作りました。私が出した指示は「今の best を圧倒的に上回る解法を作って。テストは何度回してもいい」だけです。それまでの best は 32.0 手/注文で、hub の初版は 23.0 手、その 50 分後に 15.1 手になりました。
• その後の改善で大きかったものは次のとおりです（詳細は 4 章）。
  1. 初日（10-31）に Opus 5.5 のエージェントを並列に回した探索：15.1 → 11.5 手（−24%）。汎用層の作り直し、段付き穴埋め紙、色の偏りの利用、最良解の監査など。
  2. ChatGPT（GPT-6 Pro）に私たちのコードを渡して独立に改良させた案（汎用紙 6 枚の相対順による比較器）と、それ以降の取り込み：11.5 → 10.6 手（−7.4%）。
  3. Codex（GPT-6 Astra）による探索の効率化と高速化、ChatGPT の Draft PR から入れたキャップ紙：10.6 → 10.4 手（−2.1%）。
  4. 私の「設計の目的関数と注文処理の評価が食い違っていないか」という問いから始めた、古い規則の監査：−0.76%。
  5. 別に動かした Codex エージェントの構造実験（PR 90）：−1.46%。ChatGPT の Draft PR（PR 114・115）の中立探索と列 MDP：−0.7%。
  6. 設計を複数作り、評価関数で選ぶ方式：−0.4%。最終日の改善ラウンド：−0.1%。

1使った AI とハーネス

規模（10-30〜11-09）：解法のディレクトリ 2057 個、評価 5265 回（設計を固定した比較を含む）、PR 177 本。Claude のログ上の応答メッセージは、Opus 5.5 が約 2.6 万件、Fable 5.1 が約 900 件です。評価は Core Ultra 9 285K で 24 並列でした。

課金は Claude Max と ChatGPT Pro です。Claude の 5 時間枠を何度か使い切りました（初日に Opus の max/xhigh エージェントを 6 本同時に動かしたら 1 時間で止まりました）。それ以降は、同時に動かすエージェントを 2 本程度に抑えさせました。

2AI に自走させるための評価基盤

初日に、過去のコンテスト（MM167、AHC072）と同じ形の評価基盤を Claude に作らせました。後半の 0.1% 単位の改善は、この基盤なしには判断できませんでした。

• 評価の記録とロック（scripts/pahcer_run.py）：評価ごとに、ソース、全ケースの stdout と stderr、スコアを runs/<run-id>/ に残します。複数のエージェントが同時に 24 並列の評価をしないように、ロックで 1 本ずつ実行します。
• 同時比較（--compare）：seed ごとに基準と候補を続けて実行し、ケースごとの log スコア比の平均、標準誤差、勝/分/敗を出します。順位はケースごとの順位スコアの和で決まるので、平均スコアではなく、ケースごとの比で判断させました。
• ケース数の決定：「500 ケースで足りるか、統計的に検討して」と頼みました。ケースごとの比の標準偏差は約 1.17% で、0.1% の差を見分けるには 2000 ケース（標準誤差 0.026%）が要ると分かり、以後は 2000 ケースを既定にしました。
• 設計を固定した比較（--save-design / --design-from / --orders N）：注文処理だけの変更は、保存した同じ設計の上で、注文列を N 本に増やして比べます。標準誤差が約 1/9 になり、0.01% の差まで判断できるようになりました。
• AI 向けのビジュアライザ（scripts/observe.py）：保存した出力を再生し、注文ごとの操作、重なりの状態、行動の統計をテキストで出します。解法は stderr に 名前 = 数値 の指標や、紙の役割（@paper）と操作の種類（@ops）の注釈を出し、それも集計できます。この注釈は、11-03 に「作業で不便なことはないか」と Claude に聞いて足したものです。
• ジャッジとの時間合わせ：手元の時計を 1.1 倍に読む CLOCK_SCALE と、時間不足のときの軽い処理を手元の評価で止める LOCAL_BENCH を入れました。この問題の入力は決まっているので、AtCoder のコードテストで stderr と実行時間を取れることに気付き、それでジャッジの速さを測りました。
• trial_log.md と CLAUDE.md：試したこと、結果、根拠の run-id を記録させ、規則（ベースのコピーから新しいディレクトリを作る、README を書く、2 SE 未満の差では判断しない、など）は CLAUDE.md に書きました。私が出した方針は、Claude のメモリにも残させました。
• 人間用のダッシュボード：評価のたびに HTML を作り直し、公式ビジュアライザと並べて見られるようにしました。三角形の構造が人間に見えるように、列を並べ替えて表示する機能も付けました。

3最終解法の骨格

64 窓を、汎用窓 38、ハンドル窓 25、キャップ窓 1 に分けます。紙は、汎用紙 6 枚、キャップ紙 1 枚、商品紙 185 枚（単独の商品用 114 枚と、近い 2 商品で共有する 71 枚）です。

• 階段（hub）：商品紙を 25 本の列に分け、汎用層の下に積みます。注文が来たら、目的の紙を列から掘り出して一番上に持ち上げます。穴の窓の色は、他の紙を差し込んで合わせます。
• 汎用層（比較器）：汎用紙 6 枚の相対順（720 通り）で 38 窓の色を表します。2 商品で共有する紙は、2 商品で色の違う窓が穴なので、その窓の色をこの比較器で出します。
• 段付き穴埋め紙：ハンドル窓の穴は、どこかの列の一番上の紙を適切な段に差し込み、1 手で複数まとめて覆います（区間 DP で選びます）。
• 設計（約 1.22 秒）：窓の割り当ての焼きなまし → 対・列・ハンドルの焼きなまし → 穴埋めの山登り、ハンガリアン法の再割り当て、穴あけ。焼きなましの後半から候補を複数作って仕上げ、評価関数 V で 1 つ選びます。
• 注文処理：複数の計画を作って短縮します（2 手を消して 1 手で修復する、など）。手数が同じなら、終わりの状態の価値（列 MDP など）が良い方を選びます。1 秒あたりの価値の高い探索から時間を割り当て、最後の注文が 1.88 秒までに終わるようにしています。

4経緯と、効いた指示

4.1スコアの推移

10-31 の行は seed 0〜499、11-01 の imp 以降は seed 0〜1999 の平均です（imp 以降は 2 つの集合でほぼ同じ値）。どの版も誤表示は 0 なので、スコア ÷ 1024 が 1 注文あたりの手数です。

4.2階段状の解法にどうたどり着いたか（10-30〜31 深夜）

指示の流れ

評価基盤を作らせた直後に、私が最初の方針を指定しました。結果は 32.0 手/注文でした。

次に、同じセッションに方向のヒントだけを出しました。

その 1 分後に、別のセッション（Opus 5.5）に次の指示を出しました。階段はこのセッションから生まれました。

Claude がたどった道筋（会話ログより）

• まず、目標を知らない汎用の構造に限界があるかを、計算で確かめました。窓を 3〜6 個の小グループに分け、各グループの紙の模様を、厳密な平均費用 MDP（状態は紙の順列）と山登りで最適化しました。どの形でも 1 窓あたり約 0.40 手（1 注文 約 26 手）が限界でした。1 手で届く表示は、g 窓のグループで高々 g(g+1)/2 通りしかないからです。
• そこから、256 個の目標を事前に知っていることを使うしかないと判断し、目標専用の紙（ほぼ全面が不透明）を隠しておいて、必要なときに掘り出す方式を考えました。
• 紙を動かせるのは見えている紙だけなので、隠した紙も、どこかの窓から見えている必要があります。そこで、紙の列ごとに専用の窓（ハンドル窓）を 1 つ割り当て、上にある紙はすべて、下の紙のハンドル窓で穴にしました。これが三角形（階段）の制約で、列 l の紙はハンドル h₀〜h_l だけが不透明です（3 章の図）。
• 列の中の紙は色を交互に並べ、列を 1 回回すと一番上の色が反転するようにしました。この設計の見積りは 19〜20 手でした。MDP の実験からここまで約 25 分、指示から初版の 23.0 手までは約 70 分でした。
• その後の 50 分で、次の改良を自分で積みました。15.1 手まで下がりました。
  • 汎用層を MDP で最適化した 5〜6 窓のグループにする（18.3 手）。
  • 紙 192 枚では 256 目標に 1 枚ずつ配れないので、近い 2 目標で 1 枚を共有する（16.4 手）。
  • 対の組み方と列の配置を焼きなます（15.6 手）。
  • 前の紙を列へ戻すときに、上端と下端の都合の良い方を選ぶ（−1.9%）。

「下限」の主張と、それが破れたこと

hub8 の後、このセッションは「この方式の下限は約 13.5 手で、hub8 は下限から 5〜7% 以内にいる」と報告し、ヒントを求めてきました。私は次のように返しました。

これを受けて、セッションは「自分の枠組みに引きずられている」と判断し、問題文だけを見せた分析エージェントと、自分の前提を攻撃させるレビューのエージェントを並列に立てました。2 本とも同じ下限（13.0〜13.5 手）に同意し、このやり取りから直接の改善は出ませんでした。

しかし、同じ日に並列のエージェントが積んだ改良（4.3 節）で、その日のうちに 11.46 手になり、「下限」は破れました。下限の見積りは、「穴 1 個を直す費用は、目標と独立な 0.5 手」と仮定していました。実際には、次の 3 つでこの仮定が破れていました。

• 対の 2 目標は、汎用窓の穴で互いに逆の色になる（相補ブロックで安く出せる）。
• 1 手で複数の穴を直せる（段付き穴埋め紙）。
• 穴に見える色には持続と偏りがある。

AI の「これが下限」という主張を、そのまま信じてはいけない。これが最初の教訓でした。

独立に作っても同じ形になった

• 同じ夜から翌朝にかけて、私は ChatGPT（GPT-6 Pro）にも問題文だけを渡し、独立に解かせていました。ChatGPT も「制御窓 + データ窓 + テンプレート + 三角制約」に行き着き、平均 13.7 手まで下げました。
• 文脈を共有しない Codex（Astra）の試作 4 本も、すべて「持ち手の窓で掘り出す紙 + 下地」の形でした。
• 11-02 に、今の構造を伏せた Claude のエージェント（fresh-arch）に、ゼロから考えさせたことがあります。このときも同じ骨組み（階段 + 偏りを使う割り当て）に戻りました。
• 11-03〜04 の Codex の構造実験は、階段を崩す部品を 10 種類以上試しました。結果は、18 条件中 14 条件で階段型が最良でした。

Fable 5.1 の考察（10-31）は、「紙 192 枚という予算では、ほぼ全面の専用紙を 1 枚持ち上げ、残りを穴として直す方式が強制される」と結論しています。この問題では、階段はかなり必然的な構造だったようです。

4.3初日の並列探索：15.1 → 11.5 手（10-31）

10-31 09:33 に、別の Claude セッションを司令塔にして、次のように指示しました（要旨）。

• 翌日 02:00 のトークンのリセットまでに、使い切るペースで改善を続ける。
• エージェントを多数立てる（原則 Opus 5.5 の xhigh か max、ときどき Fable）。
• 各エージェントは PR を作って経過を書き、効果の小さいものもマージする。
• 序盤なので、細かい調整より、勝てる方針を見落とさない探索を優先する。

テーマ別のエージェント（汎用層、計画探索、穴、プール、小模型、共有、構造、監査）が並行して、次のものを見つけました。

この日のうちに、上の監査（司令塔が自分で立てたもの）が型になりました。手数の内訳を取る → 下限や模型と比べる → ずれている部品を直すという型です。

4.4ChatGPT に独立に改良させ、部品ごとに取り込む（11-01）

11-01 に、私は ChatGPT（GPT-6 Pro）に、Claude が整理した clean-base（11.46 手）と問題文を渡し、改良させました。返ってきた gpt6pro-06 は −3.3% でした。汎用層を「汎用紙 6 枚の相対順（720 通り）による比較符号」に替え、列の中の決まった巡回順もやめたものです。Claude の側では、反転ブロック（32 通り）を前提にした改良が頭打ちになっていたところでした。

次に、Claude に次のように指示しました。

同じ日に、次のくぎも刺しました。

その後も、GPT-6 Pro の改良版（07〜10）を Claude に部品ごとに移植させ、10.61 手まで下げました（imp-all −1.1%、imp-910 −0.9% など）。

ChatGPT の版は、総合点では手元の最良に届かないことが多くありました。11-03 未明に、Claude がそれを理由に検討を打ち切ろうとしたので、次のように正しました。

以後は、外部の案は「部品 → 手元での状態（実装済み / 試して不採用 / 未着手）」の表にして、未着手の部品だけを検証させるようにしました。キャップ紙（ChatGPT の PR 78、−0.2%）、中立探索と列 MDP（PR 114・115、−0.7%）は、この方法で入りました。

4.5Codex Astra を数理・高速化の担当に（11-02〜）

Astra が効いたのは、目標と測り方がはっきりした課題でした。

• 出力を変えない高速化：窓の割り当てが 2.29 倍、焼きなましが 1.34 倍になり、その時間で探索を増やしました（−0.25%、−0.08%）。
• 同じ時間での探索の効率化：窓の割り当ての近傍を改善しました（−0.63%）。探索が良くなると構造の最適点が動いたので、汎用窓の数 G を 36 → 38 → 39 と測り直しました（−0.34%、−0.13%）。
• 「1 位との差を生む構造を見つけて」のような開放的な課題では、分析は正確でしたが、改善は出ませんでした。

Claude には、Astra への依頼文を「目的、触ってよいファイル、禁止事項（直接実行しない、commit しない、など）、CPU の上限、出力の形式」まで書かせました。

4.6設計と注文処理の食い違いを疑わせる（11-03）：−0.76%

11-02 の深夜、「最初の数注文だけ手数が多いので、設計後に架空の注文で慣らす（warm start）」という案が出てきました。私は対症療法だと感じたので、次のように頼みました。

Claude は、別のエージェントに Solver と Design を読ませ、各規則が暗に置いている仮定を、今の設計と実測に照らさせました。その結果、代を経て仕組みが変わった後も残っていた古い規則が 3 つ見つかりました。

• 各列の一番上を少数派の色で印刷していた（as6-majtop、−0.23%）。
• 巡回列の時代の、色の釣り合いの罰が、設計の偏りに逆らっていた（as6-imb0gb、−0.42%）。
• 穴埋め紙の水準が、空の列を考えていなかった（as6-canon、−0.07%）。

重みの調整は何日も平らだったのに、この監査では見つかりました。以後、構造を変えたときは、古い規則の前提を監査してから調整することにしました。

4.7その後の大きめの改善（11-04〜11-07）

• Codex の構造実験（PR 90、−1.46%）：私が別に動かした Codex のエージェントが、11-03〜04 に 199 ディレクトリの実験を行いました。採用されたのは次の系列です。
  • 紙を戻す位置に、他の目標で穴埋めに使える見込みを入れる。
  • 列の先頭に来る紙を予測して、対と列を選ぶ。
  • 計画の候補を短縮してから比べる。
  • 2 手を消して、途中に 1 手の修復を入れる。
• 中立探索と列 MDP（−0.7%）：ChatGPT の PR 114（2 手 → 2 手の中立な書き換え）と PR 115（列の部分列 MDP）を、Astra と Claude が今のベースに移植しました。列 MDP は単独で −0.10% でしたが、中立探索と合わせると、中立探索単独の約 3 倍の効果が出ました（設計固定 2000 件で −0.59%）。中立探索は、手数が同じで終わりの状態の評価が良い操作列を探すので、状態の評価が正確になるほど効きます。
• Gemini 4 Argon の助言の検証（11-05〜06、計 −0.14%）：文脈を共有しない Gemini 4 Argon に過去の最良のコードを読ませて書かせた助言 2 本を、Astra 2 本に 1 項目ずつ検証させました。採用されたのは、注文処理の穴埋め紙の DP、穴あけ、再割り当ての小さな改良で、合わせて −0.14% でした。
• 設計を複数作って評価関数で選ぶ（−0.4%）：きっかけは、11-07 未明に、一部の seed でベストが特に良い（9951 点）ことに私が気付いて調べさせたことでした。同じケースでも設計の乱数だけで手数が約 0.5% ぶれ、模擬の注文列で設計を選ぶと効くと分かりました。

Astra が、142 特徴の評価関数 V を作りました（ケース内の相関は、旧モデルの 0.36 に対して 0.81）。焼きなましの後半を分けて仕上げた複数の候補から、V で選ぶ形にしました（候補の数は、その後の高速化で増やしました）。V を焼きなましの目的関数に入れる案（私の発案）は、効きませんでした。

4.8最終盤（11-08〜09）

• 助言の検証：GPT-6 Pro に今の出力を読ませた助言の 3 章（窓・対・列を同時に壊して直す LNS）と 4 章（重い合法探索で反例を集める）を、Astra と Claude に並行して検証させました。
  • LNS は、同じ計算量で設計を丸ごとやり直すより悪く、打ち切りました。分かったのは、効く梃子は設計の計算量だということです（2 倍で −0.25%）。
  • 合法探索では、注文処理の余地は小さい（0.0015 手/注文）と分かりました。それでも、副産物の 2 つの規則（同じ紙の 2 回目の移動を消す、ほぼ同点の計画を終わりの状態の特徴で選び直す）で −0.065% になりました。
• 時間の効率化：出力を変えない高速化と、浮いた時間の配分で −0.1% 程度でした。100 ms あたりの価値（設計 0.03%、注文処理 0.055%）を測ってから配分しました。
• 最終日の改善ラウンド：Fable 5.1（Workflow の Ultracode）と Astra（effort ultra）に案を出させ、Astra（xhigh）2 本に実装させました。採用は 1 件で、焼きなましの穴の費用の「戻り」の強さを 2 → 6 にする案です（GCC −0.086%、Clang −0.125%）。
• 提出版の時間管理：開発中は、時間不足の fallback を解法に入れることを禁止していました。

• 最終日に、設計を時間で打ち切る形（1.22 秒）と、注文処理の段階的なペース配分（目標 1.85〜1.88 秒、最後の手段は軽い計画で 1.92 秒）を入れました。私は最初 1950 ms を目標にするつもりでしたが、Claude の助言で 1.85 秒と段階的な fallback にしました。
• 最終コードのレビュー：Astra（max）と Fable 5.1 に独立に読ませました。Astra が、範囲外参照（hardened libc++ なら全ケースで落ちる）を見つけ、提出前に直しました。

5スコアに寄与した指示・やり方のまとめ

1. 大きな目標を与え、試行錯誤を無制限に許す。「圧倒的に上回る解法」「テストは何度回してもいい」という指示で、Claude は小さな MDP の実験で限界を測るところから始め、階段構造にたどり着きました。
2. 序盤は並列エージェントで探索を優先する。初日は、テーマ別のエージェントを並列に回し、効果の小さいものもマージしました。1 日で −24% でした。調整を禁じたのは 11-01 です。
3. 外部の AI に独立に解かせ、部品ごとに取り込む。GPT-6 Pro の比較器（−3.3%）とその後の取り込み、キャップ紙、中立探索などです。総合点で判断しないことを明示しました。他の AI の途中経過を見ること（カンニング）は止めて、独立性を保ちました。
4. ずれを疑う問いを投げる。「設計の目的関数と注文処理の評価の平仄が合っていないのでは」という問いから、調整では見つからない古い規則が見つかりました。「同じ注文が来たら過去の操作列を使えないか」「キャップは要るのか」なども同じ趣旨で聞きました（前者はごく小さな改善、後者はキャップが要ると確認しただけでした）。
5. 差を正しく測る仕組みに投資する。同時比較、2000 ケース、設計を固定した比較、時計の倍率です。採用の基準も途中で決めました。11-06 からは、0.03% 未満の改善は拾わず記録だけ残し、失敗した案の深掘りは 1 回の修正までにしました。
6. Astra には、目標と測り方の決まった仕事を、正確な依頼文で頼む。高速化と探索の効率化では強く、開放的なブレインストーミングでは改善が出ませんでした。
7. AI の「下限」や「飽和」の主張を疑う。初日の下限 13.5 手は、その日のうちに 11.5 手で破れました。「設計の計算量は飽和している」という結論も、時間で打ち切る安全装置が実験中に効いていただけの誤りでした（11-02 に訂正）。

6うまくいかなかったこと

• 階段を崩す構造：列の一部を全順序の MDP で解く、前に張り出す部品など、10 種類以上を試しましたが、利得はありませんでした。
• 汎用紙を使わない系列（11-06）：手元の最良が局所最適だと考え、外部の研究版（商品紙だけで汎用層を作る）をベースに Astra に 1 日改善させました。それでも +0.48% 悪いままで止めました。
• 紙の配分を変える案：3 商品の共有、汎用紙を 7〜8 枚にする、2 枚目のキャップなどです。紙 1 枚の値段が約 0.3〜0.5% と高く、どれも損でした。
• V を焼きなましの中で使う、V を直接最適化する案：どちらも悪化しました。V は、仕上がった候補を選ぶことにしか使えませんでした。
• 運用面：エージェントを一度に多く立てて、5 時間枠を使い切ったことがあります。手元の負荷（エディタのファイル監視など）が、時間で打ち切る解法の結果をゆがめたこともあります。ジャッジの一時的な遅さで TLE が出て、時間を削りかけたこともあります（同じソースを再提出したら通りました）。

リポジトリ：solutions/final2-reset6/（最終提出の解法）、trial_log.md（全実験の記録）、scripts/（評価基盤：pahcer_run.py、observe.py、replay.py、report.py）。