科学計算のための長時間稼働Claude

Anthropicは、数日間にわたるエージェントによるコーディングワークフローが、複雑な科学計算タスクを自動化し、人間の研究者の数ヶ月分の労力をわずか数日間に圧縮できることを実証しました。永続的なメモリ、テストオラクル、および特定のオーケストレーションパターンを備えたClaude Opus 4.6を活用することで、非専門家が、リファレンス実装と比較して1%未満の精度を持つ微分可能な宇宙論的Boltzmannソルバーをゼロから実装することができました。

科学のための自律的エージェント・ワークフロー

数値ソルバーの再実装、レガシーなFortranコードの現代的な言語への変換、あるいは大規模なコードベースのデバッグといった科学計算タスクは、通常、目的が明確に定義され、成功基準がはっきりしているため、自律的エージェントに適しています。並列化可能なタスクとは異なり、科学的なパイプラインはしばしば深く結合されており、ある段階での小さな数値誤差が下流に伝播することがあります。これには、因果関係の連鎖を追跡し、ドメイン知識を活用し、リファレンス実装を用いて不一致を二分探索できる逐次的なエージェント・アプローチが必要です。

長時間稼働エージェントのための技術的フレームワーク

数日間にわたる自律的な作業を可能にするために、Anthropicはいくつかの主要なアーキテクチャ構成要素を特定しています。

プロジェクト指示書 (CLAUDE.md)

指示は、ルートディレクトリにある CLAUDE.md ファイルにコード化されます。Claudeは、このファイルを永続的なコンテキストとして扱い、全体的な計画の参照や、プロジェクトの進展に伴う更新を行います。宇宙論的ソルバーの例では、目標は、リファレンスであるCLASS実装と完全な機能同等性を達成すること、および0.1%の精度目標を達成することとして定義されました。

永続的メモリ (CHANGELOG.md)

エージェントが失敗した試行を繰り返さないように、CHANGELOG.md ファイルがポータブルな長期メモリとして機能します。このファイルは以下を追跡します：

現在のステータスと完了したタスク。
失敗したアプローチと失敗の理由（例：硬い摂動ODEに対して Tsit5 から Kvaerno5 へ切り替える）。
主要なチェックポイントにおける精度テーブル。
既知の制限事項。

テストオラクル

自律的な進捗は、「テストオラクル」に依存します。これは、エージェントが自身の作業を検証するための方法です。科学的なコードの場合、これは通常、リファレンス実装、定量化可能な目的、または既存のテストスイートです。このプロジェクトでは、ClaudeはCLASS Cのソースをリファレンスとして使用し、ユニットテストを構築して継続的に実行しました。

Gitによる調整

Gitは、進捗を監視し、回復可能性を確保するために使用されます。pytest がパスする場合に限り、意味のある作業単位ごとにコミットとプッシュを行うようエージェントに指示されます。これにより、破壊的な変更がコミットされないことが保証されます。

実行とオーケストレーション

HPC統合

計算負荷の高いタスクの場合、Claude Codeは、SLURMジョブスケジューラを使用したHPCクラスター上の tmux のようなターミナルマルチプレクサ内で実行できます。これにより、エージェントがバックグラウンドで動作し、人間が時折デタッチして再アタッチすることで、プロセスを制御したり、GitHub経由で進捗を確認したりすることができます。

Ralphループ

「エージェントの怠慢」—モデルが複雑なタスクを完全に完了する前に停止してしまう現象—に対抗するため、Anthropicは「Ralphループ」を利用しています。これは、エージェントが完了を主張する際に、本当に完了しているかどうかを再プロンプトする for ループのオーケストレーション・パターンです。

提供された例では、Ralphループは、特定の成功基準を持つプラグインを介して呼び出されました：

/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”

結果と示唆

このフレームワークを使用することで、Claude Opus 科学計算プロジェクト clax を数日間かけてゼロから実装し、最終的にリファレンスであるCLASS実装と1%未満の一致率に達しました。エージェントの軌跡は「ぎこちない」ものでした—テストカバレッジの不足や、ゲージ・コンベンションに関する時折の初歩的なミスが含まれてもありましたが—、目標に向かって持続的な進捗を達成しました。

この実証は、エージェント主導の開発が、科学ソフトウェアの開発タイムラインを大幅に圧縮できることを示唆しています。著者は、現在、明確に定義されたプロジェクトにおいてエージェントを稼働させないことの機会費用は、潜在的な進捗の損失という具体的な損失であると述べています。