4万行のFortran 77をAIエージェントでC++に移した記録Mistralが公開した3つの教訓：①移行コードを書く前に「数値の一致」を証明するパリティハーネスを作る、②100超のエージェントでまず文書化、③完全自律は「Fortranを C++の文法で書き直しただけ」になり、人がゲートに立つ構造化ワークフローに落ち着いた

2026年9月18日・日本時間時点の情報です。 Mistralの応用AIチームの9月9日の記事（約7分）を読んだ。「AIでレガシーコードを移す」話は多いが、この記事は何がうまくいかなかったか（完全自律で1週間放置した結果）と、どこに落ち着いたか（人がゲートに立つワークフロー）を具体的に書いている。OpenAIがPythonのストレージ基盤をエンジニア2人＋CodexでRustに書き換えた話と並べて読むと、「移行そのもの」より「検証と文書化」に工数が寄っていることが共通している。

3行まとめ

1. 対象と難しさ。 欧州のエネルギー事業者の貯留層シミュレータ（物理計算が重い）。Fortran 77、テストスイート無し、集中した文書無し、全30万行のうち最初のスプリントで中核の4万行をC++へ。Fortran 77はモジュールも名前空間も構造型も無く、状態はCOMMONブロック（プログラム全体で共有するグローバルメモリ）に置かれ、変数は頭文字で暗黙に型が決まり（I〜Nで始まれば整数。綴りを間違えると新しい変数が黙って生まれる）、名前は6文字まで。C++で明示的な型・オブジェクト指向・戻り値に直すと行対行の対応が無くなり、それが検証を難しくする。PetSc等の現代的な数値計算基盤への統合も要件。
2. 3つの教訓。 ①移行コードを書く前にパリティハーネスを作る：Fortran側の状態を書き出すサブルーチン、C++側でチェックポイントを読み込むテスト枠、エージェントに正しく使わせるSkill.mdを用意し、「最終結果と、顧客の貯留層エンジニアが選んだ重要な中間点の数値一致」を合格条件にした（例：FortranでRHOGの値42.71834を書き出し、移行したC++モジュールのテストで同じ値を参照）。「モジュールが完了した」ことの最も安く、最も説得力のある証明。②エージェントに頼る前に文書を整える：文書は古いPDFとFortran内のコメントに散らばっていた。手続き型のFortranは全体が1本の呼び出し木に描けるので、自作パーサで木を作り、Vibe CLIで100超のエージェントを立て、葉から上へ各ノードのサブエージェントが（文書ライブラリとMistral OCRでPDFを引きながら）文書化して元リポジトリにPRを開き、cronで回るレビュアーエージェントが新しいPRを確認して修正タスクを積む。③この規模では、人のレビューゲートを持つ構造化ワークフローが、完全自律にも手作業にも勝る。
3. 落ち着いた形。 顧客のエンジニアと呼び出し木から独立したモジュール（経験的に1万行未満）を切り出し、モジュールごとに「C++の目標アーキテクチャを生成→貯留層エンジニアがレビュー→承認後にタスクキューへ分解→タスクごとに計画→実装→テスト→繰り返しの実装サブワークフロー→人がPRをレビューし、マージまで変更を求める」。記事は限界も書く：Fortran側が自己完結して実行可能だったのは好条件で、外部システムに依存する・実行できるベースラインが無い・どこにも文書化されていない物理を含む移行は、この記事の範囲外。

3回の試行（記事の記載）

検証と停止設計をどう応用するか

• 「数値の一致」を合格条件にしたのは、科学計算だからできた面もあるが、考え方は業務システムにも移せる。移行後の出力が移行前と同じであることを、人が読まなくても機械が示せる形にしてから、エージェントに任せる
• エージェントは「止まる」。当サイトがAIエージェントの作り方で整理した「止まる条件」とは逆に、ここでは「止まったときに誰が解除するか」が設計の中心になった。CodexのAuto-reviewやGoal Modeが「承認を別エージェントに回す」方向なのに対し、Mistralの結論は「人がゲートに立つ」。規模と失敗の代償で答えが変わる
• Skill.mdでハーネスの使い方を渡すのは、Skillsは「手順の道しるべ」として役立つという実験結果と同じ使い方。エージェントに「検証の手順」を教えることが、移行の質を決めている
• 「機械が確かめられる形にしてから任せる」のは、エージェント以外の自動化にも使える。当サイト（Next.js）の毎朝の自動デプロイも、ビルド後に本番URLをcurlで叩いて200を数えるところまでを仕組みに含めている（Mac1台のlaunchdとVercel CLIでの実装）

原文取得日と確認できた範囲

この記事の下調べで、筆者は9月18日にMistralの記事を取得し、対象の規模・Fortran 77の制約の説明・3回の試行と結果・ワークフローの手順・3つの教訓・限界の記述がその原文にあることを確認した。顧客名と使われたMistralのモデル名は記事に無く、筆者はFortranのコードベースを扱った経験を持たない。

原文に無い顧客名・費用・誤差許容

• 顧客名、使ったモデル、費用と期間（「最初のスプリント」とのみ）
• 残る26万行の移行計画
• パリティハーネスで許容した数値誤差の大きさ

出典はMistralの記事

• Mistral AI「Modernizing complex legacy code with AI agents. Lessons from 40,000 lines of Fortran.」（2026年9月9日）
• 本記事は続報（残りの移行やモデル名）が出たら追記する