Claudeに長時間の科学計算を任せる — 照合するテスト・進捗メモ・役割分担

Claudeに数日がかりの数値計算コードを任せられるかどうかは、モデルの賢さより先に、正解をどう測るかで決まります。Anthropicの研究者が公開した事例では、Claude Opus 4.6が宇宙論の数値ソルバーを数日かけて一から実装し、参照実装との差をサブパーセントまで詰めました。支えていたのは、参照実装と照合するテスト、進捗メモ、コミットの習慣という地味な3点です。

この記事では、その事例を材料に、Claude Codeで長時間タスクを放置運転するときの設計を手順にします。

どんな課題なら放置運転に向くか

放置運転に向くのは、数値ソルバーの再実装、古いFortran方言で書かれた科学ソフトの現代的な言語への移植、参照実装との突き合わせによる大規模コードのデバッグです。共通点は、作業範囲が絞れていて、成功基準がはっきりしており、人間の確認が連続でなく時々で済むことです。

逆に言えば、成功基準が曖昧な課題は放置運転に向きません。ゴールを測る物差しがないと、エージェントは「できたように見える」ところで止まります。Claude Codeの公式ベストプラクティスも同じ指摘をしています。テストやビルドなど実行できる確認手段を渡すと、Claudeが作業し、確認を走らせ、結果を読み、通るまで繰り返す閉じたループになる、という説明です。

事例は何を示したのか

題材は、宇宙マイクロ波背景放射(CMB)の統計的性質を予測するボルツマンソルバーを、JAXで微分可能に作り直すことでした。CLASSやCAMBのような既存のソルバーは、光子・バリオン・ニュートリノ・暗黒物質の連立方程式を初期宇宙を通して時間発展させます。微分可能にすると勾配を使った推論が使え、パラメータ推定が大きく速くなります。

目標は、CLASSと同等の機能を持たせ、主要な科学的出力でCLASSとの差を0.1%以内にすることでした。0.1%は、CLASSとCAMBという二大コードの間の典型的な一致度にあたります。筆者はこの分野が専門ではなく、高水準の知識はあるものの、自力では現実的な時間で完成させられない状態だったと書いています。

結果は次のとおりです。

製品水準でないと筆者自身が明記している点は大事です。この事例が示したのは「完成品が出る」ことではなく、数か月から数年かかる作業を数日に圧縮できる、という見込みです。

照合先のテストを先に決める

長時間の自律作業で最も効くのは、エージェントが「いま前進しているか」を自分で判定できることです。事例ではこれをテストオラクルと呼んでいます。科学計算なら、参照実装、定量化できる目的関数、既存のテストスイートのどれかが該当します。

事例では、CLASSのCソースを参照実装として、ユニットテストを作らせ、作業中ずっと走らせ続けました。回帰を防ぐため、テストスイート自体も育てさせます。

事例には弱点も記録されています。しばらくの間、基準となる1つのパラメータ点でしかテストしておらず、バグを捕まえる面積が大きく減っていたというものです。ここから、照合テストは複数の点で回すように最初から指示しておく、という運用が引き出せます。次は、その考え方を書いたテストの一例です(事例の実コードではなく、考え方を示す例示です)。

# tests/test_vs_reference.py  (例示)
import numpy as np
import pytest
from mysolver import compute_spectrum
from reference import load_reference  # 参照実装が出力した値
 
# 基準点だけでなく、パラメータ範囲の端も含める
PARAM_POINTS = ["fiducial", "low_omega_b", "high_omega_b", "high_h"]
 
@pytest.mark.parametrize("name", PARAM_POINTS)
def test_matches_reference(name):
    ref = load_reference(name)
    got = compute_spectrum(ref.params)
    np.testing.assert_allclose(got, ref.spectrum, rtol=1e-3)  # 0.1%

許容誤差の rtol=1e-3 は、事例の目標精度0.1%に合わせた値です。自分の課題では、参照実装同士の一致度などから許容幅の根拠を決めます。

進捗メモに失敗した方法まで残す

Claudeのセッションは終わるたびに記憶が切れます。事例では、進捗ファイルをエージェントの持ち運べる長期記憶、いわば実験ノートとして使い、慣例としてCHANGELOG.mdと呼んでいます。CLAUDE.mdで「進捗はこのファイルに記録する」と指示しておく形です。

良い進捗ファイルに入れる項目は次のとおりです。

• 現在の状態
• 完了したタスク
• 失敗した方法と、うまくいかなかった理由
• 主要な地点での精度の表
• 既知の制限

とくに失敗した方法が重要です。残しておかないと、次のセッションが同じ行き止まりに再び入ります。事例の記入例は「摂動ODEにTsit5を試したが系が硬すぎる。Kvaerno5に切り替えた」というものでした。

状態の持ち方をJSONとテキストに分けて、より形式化する方法はClaudeの長時間タスクをtests.jsonとprogress.txtで管理するで扱っています。事例のCHANGELOG.mdは、それより軽い自由記述の形です。

役割分担は並列にするか逐次にするか

エージェントを何本走らせるかは、課題の構造で決まります。事例の筆者は、Anthropicが行ったCコンパイラの開発と対比しています。コンパイラは多数のエージェントに仕事を分けられましたが、ボルツマンソルバーは密に結合したパイプラインです。再結合の扱いにほんの少しの数値誤差や雑な近似があると、下流のすべてが微妙にずれます。

そのため、デバッグは因果をチェーン全体にわたってたどり、領域知識を引き出す作業になります。向くのは、1本のエージェントが逐次に進め、必要に応じてサブエージェントを呼び、参照実装を使って食い違いを二分探索で絞り込む構成かもしれません。これは筆者の仮説で、検証済みの結論ではありません。

自分の課題がどちら寄りかは、「1か所の小さな誤差が全体に伝わるか」で見分けられます。Anthropicのエンジニアリングブログが示した複数エージェントのハーネス構成はAnthropicのハーネス設計に、長時間稼働で起きる失敗モードは長時間稼働エージェントのハーネス設計にあります。

CLAUDE.mdとコミットの規則を最初に書く

事例では、作業を始める前に、筆者がClaudeと相談しながら計画と指示を練り込む時間を最も長く取っています。指示はルートディレクトリのCLAUDE.mdに置き、Claudeは作業中にこれを編集して、次回以降のために更新もできます。

コミットの規則も、CLAUDE.mdに書いておきます。

Commit and push after every meaningful unit of work.
Run `pytest tests/ -x -q` before every commit.
Never commit code that breaks existing passing tests.

こうしておくと、何かが壊れても戻れる履歴が残り、進捗が手元から見え、計算資源の割り当てが途中で尽きても作業が失われません。放置中の様子を見るにもgitが使えます。筆者は、コーヒーの列に並びながらスマートフォンでGitHubを確認していたそうです。

止まったら続きを蹴る

モデルは複雑な複数部分のタスクを頼まれると、全部終える前に理由をつけて止まることがあります。事例ではこれをagentic laziness(エージェントの怠け)と呼び、対策として「Ralphループ」を挙げています。完了を宣言したエージェントを、本当に終わったかを問い直して文脈に戻す、いわばforループです。

事例の呼び出し例は次のとおりです。

/ralph-loop:ralph-loop "Please keep working on the task until the success criterion of 0.1% accuracy across the entire parameter range is achieved." --max-iterations 20 --completion-promise "DONE"

最大20回まで繰り返し、完了を表す「DONE」の合言葉が出るまで続けます。プラグインの引数や仕組みはClaude Code ralph loopに詳しくまとめています。

同じ目的に使える仕組みは、Claude Code本体にもあります。

/goal は、完了条件を1つ指定すると、毎ターン後に別のモデルが条件を満たしたか判定する仕組みです。作業するモデルとは別のモデルが完了を決めるため、自己申告で止まるのを防げます。条件は4,000文字まで書けます。事例の成功基準に合わせるなら、次のような書き方になります(例示です)。

/goal pytest tests/ -x -q が全件通り、CHANGELOG.md の精度表で全パラメータ点が0.1%以内になっている。または20ターンで止める

公式の説明では、評価モデルは自分でコマンドを走らせたりファイルを読んだりせず、会話に現れた内容で判定します。そのため、条件は「Claudeが出したテスト結果を見れば成立が分かる」書き方にします。ターン数や時間の上限は、条件の中に節として入れると、Claudeが毎ターン進み具合を報告します。

放置運転では、権限確認で止まらない設定も要ります。/goal は権限モードを変えないため、手動モードのままだと、設定で許可していないツール呼び出しのたびにClaudeが確認を求めます。無人で回すなら、/goal をauto modeの中で実行します。auto modeはツール呼び出しの承認を外し、/goal は毎ターンの確認を外す、補い合う関係です。

非対話モードでも使えます。claude -p "/goal ..." で目標を設定すると、1回の起動で条件が成立するまでループが走ります。止めたいときはCtrl+Cです。セッションを再開した場合、条件は引き継がれますが、ターン数・タイマー・トークン消費の基準はリセットされます。たとえば「20ターンで止める」という上限は、再開のたびに数え直しになります。

計算機で放置するときの環境

事例の環境は、SLURMのジョブスケジューラを使うHPCクラスタです。ただし、進捗ファイル、テストオラクル、規則を明確にしたエージェント用プロンプトという中核は、Claude Codeを動かす場所に関係なく使えます。

流れは次のとおりです。

事例のジョブスクリプトは、48時間の枠を取り、tmuxセッションを裏で立てて claude を動かすものです。tmuxを使う理由は、ノートパソコンを閉じてもセッションが生き続けるからです。手元のClaude Codeに、SSH経由でクラスタ上のコマンドを実行させる使い方も、より楽な方法です。

tmuxの設定上の注意はClaude Code tmux設定に、Claude ScienceからのHPC接続の仕組みはClaude ScienceのHPC接続にあります。

事例から割り引いて読む点

事例を自分の仕事に当てはめるときは、次の点を割り引いて読む必要があります。

• 製品水準ではありません。全領域でCLASSと許容精度では一致しておらず、成果物は「できた」のでなく「ここまで来た」です
• 開発の軌跡はぎこちなく、ゲージの規約でつまずく、宇宙論研究者なら一目で見抜けるバグを何時間も追うといった初歩的な誤りも起きました
• 弱い点を補ったのは、持続的に進み続ける性質でした。人間の目が時々入ることが前提です

筆者は副産物として、gitのコミット履歴を追うことで、専門外のボルツマンソルバーとその物理をかなり学べたとも書いています。コミットログは「速くて文字どおりに動くポスドクの実験ノート」のように読める、という比喩です。

最後に、事例は、評価軸のある課題で夜間にエージェントを動かさないことにも機会費用がある、と述べています。一般論としては強い主張ですが、前提は「計算資源があり、成功基準の明確な課題がある」ことです。

まとめ

数日がかりの科学計算をClaude Codeに任せる設計は、3つの問いに答えられるかで決まります。何と照合するのか。失敗した方法を含め、何を次のセッションに引き継ぐのか。課題は並列に分けられるのか、逐次なのか。ここが決まっていれば、あとは /goal やRalphループで止まる癖を抑え、tmuxで切り離せば運転できます。

決まっていない課題は、先に照合先を作る作業そのものを最初のタスクにするほうが、結果的に早く着きます。