東大ら、大気モデルをClaude Codeで移植し1.71倍速【2026年11月】
「20年以上育ててきた研究用のコードを、AI に丸ごと移し替えられるのか?」——その実例が論文として出ました。
2026年10月30日、東京大学 情報基盤センターと国立環境研究所の研究者が、大気モデル NICAM を Claude Code で Fortran から C++/Kokkos に移植した論文を arXiv で公開しました。約14万行の Fortran を約3万5千行の C++ に置き換え、同じ GPU での実行時間は1.71倍速になったと報告しています。

論文が強調しているのは速さだけではありません。進み方を決めたのは人間のレビューの速さとサブスクリプションの5時間の利用上限だった——という、AI に大きな仕事を任せるときの現実的な教訓を示した事例と言えます。
この記事はこんな人向けです
- Claude Code で、大きな古いコードの移植や書き換えを任せられるか知りたい
- 話題の「東大・国環研の大気モデル移植で1.71倍」が何の数字なのか、一次情報で確かめたい
- 研究用・業務用の Fortran などのコードを保守していて、AI での移行を考えている
何が発表された?一言でまとめると
長く使われてきた気候・大気モデルを、人が指示とレビューを担当し、Claude Code がコードを書く形で別の言語に移し替えたという研究報告です。論文の要点をまとめます。
| 項目 | 内容 |
|---|---|
| 公開 | 2026年10月30日(arXiv:2610.41313) |
| 著者 | 東京大学 情報基盤センターの2人、国立環境研究所の1人 |
| 対象 | 大気モデル NICAM(力学コア+7つの物理パッケージ) |
| 移植 | Fortran(OpenACC)→ C++/Kokkos |
| 規模 | 約14万行を解析し、約3万5千行に |
| 使ったツール | Claude Code(主に Fable 5 モデル) |
| 速さ | 同じ GH200 で実行時間が 1.71倍速(81.0秒 → 47.3秒) |
| 正しさ | 100メンバーのアンサンブル比較で元のモデルと統計的に一致 |
なお、2026年11月7日時点で、東京大学・国立環境研究所のプレスリリースや、Anthropic の公式発表は見つかりませんでした。この記事は論文の記述をもとにしています。

NICAMとは?20年以上続く大気モデル
NICAM(Nonhydrostatic ICosahedral Atmospheric Model)は、地球全体の大気を計算する全球の大気モデルです。地球を正二十面体をもとにした格子で覆い、細かい解像度では積乱雲のような深い対流まで直接表せるのが特徴です。
論文によると、NICAM は20年以上の開発の中で、そのときどきのスパコンに合わせて手を入れられてきました。
- TSUBAME2.5:力学コアを OpenACC(GPU で動かすための指示文)で GPU 対応
- 富岳:NICAM を使った大規模なアンサンブルデータ同化
こうした長い歴史を持つ本番で使われる構成を、NVIDIA と AMD の両方の GPU で動かせるようにするのが今回の目的です。
何をどう移植した?Fortran から C++/Kokkos へ
Kokkos は、同じ C++ のコードを NVIDIA(CUDA)や AMD(HIP) などの GPU で動かすためのライブラリです。Fortran から移すには、言語の翻訳だけでなく、データの持ち方や並列の書き方まで置き換える必要があります。
① 人が決めて、Claude Code が計画を立てる
最初に人が短い指示書(目的・最初の作業・守るルール)を渡しました。Claude Code の plan mode でエージェントがコードを調べ、次の3点を人に確認したうえで計画を作っています。
- 最初に動かすのは物理を切った「乾燥した力学コア」
- Fortran と混ぜず、C++/Kokkos だけで独立したコードにする
- 設定ファイルは Fortran の namelist から YAML に変える
計画は 2026年7月6日に Porting_Progress.md として作られ、進めながら更新されました。
② モジュールごとに移して、テストを通す
移植はモジュール・物理パッケージを1つずつ進めました。エージェントが翻訳 → ビルド → テストを回し、通ったら人がテスト結果と構造(ファイルの分け方・呼び出しの順番)をレビューして、次へ進む流れです。

論文は、C++/Kokkos のモデルのコードはすべて Claude Code が書き、人は作業を指示して結果をレビューしたと書いています。
③ 人が止めた場面もある
人のレビューが効いた例も載っています。
- 富士通のスパコン向けの指示文(
!$OCL)に反応して、エージェントがプリフェッチのコードを入れようとした。人が元に戻し、最初の移植ではそうした最適化を持ち込まないよう指示した - エージェントには変数名を短くする傾向があり、元のコードとの対応が分かりにくくなる部分は構造のレビューで注意が必要だった
「1.71倍」の条件:何と何を比べた数字か
1.71倍は、1つの GPU で約56km の格子を120ステップ計算したときの、アプリ全体の実行時間(入出力を除く)の比較です。基準は同じ GH200 で動かした元の Fortran/OpenACC 版です。
| 構成 | 実行時間(120ステップ) | 元の版との比較 |
|---|---|---|
| 元の Fortran/OpenACC(NVIDIA GH200) | 81.0秒 | 基準 |
| 移植版 Kokkos/CUDA(NVIDIA GH200) | 47.3秒 | 1.71倍速 |
| 移植版 Kokkos/HIP(AMD MI300A) | 52.6秒 | 1.54倍速 |

条件は、倍精度・7つの物理パッケージあり・30秒の時間刻み・鉛直78層です。GPU で計算している時間(カーネル時間)だけを見ると、速さは 1.38倍(GH200)・1.27倍(MI300A)と、全体より小さくなります。
論文の説明では、全体の差が大きいのは、元の版が領域ごとにデータを詰め替えて待ち合わせていたのに対し、移植版は全体の配列をそのまま GPU 上で扱うようにしたためです。一方で、放射の計算は 41.9ms → 46.3ms と遅くなっており、改善は一様ではありません。
また、MI300A はメモリ帯域の性能が GH200 より高いのに、移植版は GH200 より遅い結果でした。帯域の差をならすと、MI300A のカーネル性能は元の版の0.96倍です。論文は、GH200 向けの設定をそのまま使っていることを理由の一つに挙げ、AMD 向けの調整は今後の課題としています。
正しく動いているかの確かめ方:3段階の検証
気象の計算は小さな数値の違いがすぐに広がるため、1回の計算結果を元の版と見比べるだけでは正しさを判断できません。論文は3段階で確かめています。
| 段階 | 内容 |
|---|---|
| ① ルーチン単位のテスト | Fortran 版から入出力をファイルに書き出し、移植したルーチンに同じ入力を与えて結果を比べる |
| ② 短い実行の比較(人がレビュー) | 30〜60ステップの計算で、場の値とエネルギー・質量の収支を元の版と比べる |
| ③ アンサンブル比較 | 初期値を少しずつ変えた100通りの計算(10日分)を両方で行い、59項目の分布を比べる |
③では、5,900のスコアのうち95.3%が、両方の版で同じ範囲(|z|≤2)に収まりました。論文は、評価した項目については元のモデルと統計的に一致しているとしています。
②の人のレビューで見つかった不具合もあります。物理パッケージは単体テストを通っていたのに、つないで動かすと地表に届く長波放射がずれていました。原因は地表温度を作る初期化の処理の移植漏れで、単体テストでは参照データを直接与えていたため見つからなかったと説明されています。
かかった期間・作業量・コスト
論文には、作業量とトークンの量も載っています。人の作業時間は記録していないため、代わりにエージェントへの指示の回数を数えています。
| 項目 | 内容 |
|---|---|
| 作業した日 | 23日(出力トークンの記録がある日。レビューやスパコンでの作業だけの日は含まない) |
| 人の指示 | 797回 |
| アシスタントのメッセージ | 6,007件(指示1回あたり平均7.5件) |
| 出力トークン | 約1,213万(サブエージェントが約848万) |
| トークン合計 | 約40億(96.5%はキャッシュの読み込み) |
| API の定価での換算 | 約5,589ドル |
| 実際の使い方 | サブスクリプションのプラン(プラン名の記載なし) |
約5,589ドルは、記録されたトークンを API の定価で計算した場合の目安です。研究チームは Claude Code をサブスクリプションのプランで使っていたので、実際にこの金額を払ったわけではありません。図を作るスクリプトやデータ分析の分も含みます。
進行を制約したもの:人間のレビューと5時間の利用上限
論文の振り返りで目を引くのが、進み方を縛ったのは AI の能力ではなく「人のレビュー」と「サブスクリプションの5時間の利用上限」だったという記述です。
- 人のレビュー:エージェントは人が確かめるより速くコードを書けた。数値のロジックや、部品をつないだときの細部のレビューにかなりの時間がかかった
- 5時間の利用上限:マイルストーンごとのトークンの使い方が読みにくく、上限に達するたびに開発が中断した。中断のあと、十分な文脈で再開できるかも心配の種だった
Claude の公式ヘルプ(2026年11月7日時点)によると、Pro と Max には5時間のセッション上限と週の上限があり、Claude と Claude Code で共通です。認証済みの Ultra アカウントには5時間の上限がありません(週の上限はあります)。論文には、どのプランを使ったかは書かれていません。
Max 20x が「Ultra」になり、5時間の上限がなくなった件はこちらで整理しています。

研究チームの振り返り(論文の記述)
論文の著者たちは、うまく進んだ理由と反省点も書いています。
- うまく進んだ理由:LLM とエージェントの力に加えて、NICAM のデータ構造が一貫していたこと、Fortran のコードがよく整理されていたこと、OpenACC・OpenMP の指示文がエージェントの手がかりになったこと
- コードの大きさ:規模の大きさは、エージェントの翻訳よりも人のレビューにとって大きな課題だった
- 反省点:初めての大規模な移植だったため頻繁に確認を求めた。振り返ると省けたやりとりもあった
- テストの課題:単体テストの入力が限られ、境界のケースを体系的には試せていない
今後は、移植の対象を広げることや、今回の手順を再利用できるエージェントのスキルにして、より自動化した流れを作る予定だとしています。
IT Picks的な所感
今回の論文は、「AI が書く速さ」より「人が確かめる速さ」が全体の速さを決めることを、具体的な数字で示した点に価値があると考えています。14万行を移せたこと以上に、人がどこで止め、何を確かめたかまで書かれているのは、同じことを考えている開発者にとって参考になるはずです。
一方で、論文自身が書いているように、元のコードがよく整理されていたことも成功の理由です。どのコードでも同じように進むとは限りません。テストの基準になる元の版があり、結果を数値で比べられることが前提になっている点も押さえておきたいところです。
利用上限で作業が何度も止まったという話は、大きな仕事を Claude Code に任せる人にとって身近な課題です。AI エージェントが人の手を借りずに競技を勝ち抜いた例とあわせて読むと、任せ方の違いが見えてきます。

まとめ
大気モデル NICAM を Claude Code で移植した研究のポイントをまとめます。
- 公開日:2026年10月30日(arXiv:2610.41313)
- 研究者:東京大学 情報基盤センター、国立環境研究所
- 移植:Fortran(OpenACC)→ C++/Kokkos、約14万行 → 約3万5千行
- 使ったツール:Claude Code(主に Fable 5、サブスクリプションのプラン)
- 速さ:同じ GH200 で実行時間が1.71倍速(AMD MI300A では1.54倍速)
- 正しさ:100通りのアンサンブル比較で元のモデルと統計的に一致
- 作業量:作業した日23日、人の指示797回、API の定価換算で約5,589ドル
- 制約:人間のレビューの速さと、5時間の利用上限
Claude Code に大きな移植を任せたい人は、元のコードと結果を比べるテストを先に用意し、人がレビューする時間を見込んでおくのが近道になりそうです。
