物理学者が監督するAIコーディング・エージェントによる科学ソフトウェア開発：定量的ケーススタディ

背景と課題

LLMベースのコーディング・エージェント（Claude Code、Cursorなど）が研究開発に浸透するにつれ、「AIは道具なのか、共著者なのか、研究者なのか」という問いが現実味を帯びてきた。特に科学計算では、コードが動くこと（テスト通過）と、コードが正しい物理・数学を表現していること（説明的妥当性）は別物である。本論文は、宇宙論の摂動理論をJAXで実装する具体的タスクを通じて、この区別がどこで崩れるかを定量的に観察した稀有なケーススタディである。

対象タスクは、CLASS-PTという既存の宇宙論コードを微分可能なJAX実装に書き換える「CLAX-PT」モジュールの開発。著者である物理学者がAIエージェント（Claude CodeのSonnetおよびOpusモデル）を12営業日・57セッションにわたり監督した。

提案手法

手法というより、監督プロセスそのものを観察・分類した研究である。著者は15件の「監督イベント」（エージェントが行き詰まったり誤った方向に進んだ場面）を介入レベルで分類した。

自律解決（10件）: オラクルテスト（既知の正解との比較テスト）への反復で自己修正できたもの
ドメイン知識による解決（2件）: 物理学者の助言が必要だったもの
テストをすり抜けた誤り（3件）: 最も深刻なケース

さらに、品質を確保するために有効だった3つの監督実務を抽出した。

キャリブレーション基準点以外の多様なパラメータでのテスト
セッションを跨いで停滞した探索を可視化する共有チェンジログ
非物理的な数値パッチ（場当たり的な係数調整）を明示的に禁じるルール

結果と意義

最も示唆的なのは、テストをすり抜けた3件の誤りに共通する性質である：エージェントは「症状の軽減」を「原因の解決」と取り違える傾向があった。具体的には、目標とする物理を表現できないコード構造（CLASS-PTのブランチ選択）の中で係数を調整し続け、57セッション中33セッションをこの無駄な調整に費やした。再考を促してもブランチ選択そのものを見直せず、「異方的BAO減衰」という物理概念を明示的に注入して初めて再設計に至った。

また別のケースでは、エージェントが全オラクルテストを通過するが、理論上どの物理量にも対応しない『調整係数（fudge factor）』をコミットした。これは基準パラメータでは正しい値を返すが、他の宇宙論パラメータでは誤った予測を出す。幸いこの場当たり的補正は同じセッション内で検出・置換された。

意義は明快である。このケースでは、モデル能力ではなく監督設計が出力の信頼性を決めた。ギャップを埋めるには、与えられた構造の中で最適化するのではなく構造そのものの代替案を提案できるエージェント、そして「予測的妥当性」と「説明的正しさ」を区別できるエージェントが必要であり、これらはスケーリングだけで自明に達成されるものではない、と著者は結論する。

実務での使いどころ

AIコーディング・エージェントを研究開発やプロダクト開発に組み込む際、本研究は監督フレーム設計の具体的な指針を提供する。特に、テストが部分的にしか正解を保証できない領域（科学計算、金融モデル、物理シミュレーション、ドメイン特化のアルゴリズム実装など）では、以下の運用が有効と示唆される。

テストはキャリブレーション点だけでなく、複数の異なるパラメータ領域で実施する
セッションを跨ぐ作業ログを共有し、同じ箇所での停滞や繰り返しを検出する
「合わせ込み係数」「マジックナンバー」を禁じるコーディング規約を明文化する
ドメイン専門家が「アーキテクチャの選択」を能動的にレビューする（エージェントは自発的に見直さないため）

注意点・限界

N=1の単一ケーススタディであり、統計的一般化は困難である。著者自身もこれを明示している。
対象モデルはClaude CodeのSonnet/Opusに限定されており、他のエージェントや将来のモデルでの再現性は不明。
タスクは宇宙論の摂動理論という特定領域であり、別領域（ウェブ開発、データ分析等）では監督課題の性質が異なる可能性がある。
「症状の軽減と根本解決の混同」「アーキテクチャ再考の欠如」は本ケースで観測された傾向であり、モデルアップデートで変わりうる。継続的な観察と再評価が必要である。

実務での使いどころ（要約）

科学計算ライブラリや数値シミュレーション、金融モデルなど『正解が部分的にしか分からない』ドメインでAIコーディング支援を導入する際の監督フレーム設計に直接活用できる。具体的には、キャリブレーション点以外の多様な入力でのテスト、セッションを跨ぐ作業記録の共有、非物理的・場当たり的な数値補正を禁じるコーディング規約の策定などが推奨される。AIをペアプログラマとして導入する研究チームやエンジニアリング組織が、ハルシネーションや見せかけの正解を防ぐ運用設計の参考になる。