活用公開 2026-09-24· 約7分

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

Mistralの応用AIチームは2026年9月9日、欧州のエネルギー事業者の貯留層シミュレータ（Fortran 77・テストスイート無し・文書散逸・全30万行）のうち中核の4万行をC++へ移した事例を公開した。COMMONブロックの共有グローバル状態、頭文字で決まる暗黙の型、6文字の変数名、GOTO主体の制御を現代的な設計に変えると行対行の対応が無くなり、検証が難しい。答えは3つ。①移行前に「パリティハーネス」（状態を書き出すサブルーチン・C++側のテスト枠・Skill.md）を作り数値一致を合格条件に。②Vibe CLIで100超のエージェントを立て、呼び出し木の葉から文書化しPRを開き、cronのレビュアーエージェントが確認。③完全自律の1週間は「Fortranの再入力」に終わり、役割分担も止まると助けがなく、最終的に人がcoder→tester→reviewerを運転し、モジュール（1万行未満）ごとにエンジニアが設計を承認しPRを人がレビューする形に落ち着いた。

執筆・編集：AI時短ラボ

3回の試行（記事の記載）
読み方
筆者が確かめた点
書かれていないこと
出典はMistralの記事

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

3行まとめ

対象と難しさ。 欧州のエネルギー事業者の貯留層シミュレータ（物理計算が重い）。Fortran 77、テストスイート無し、集中した文書無し、全30万行のうち最初のスプリントで中核の4万行をC++へ。Fortran 77はモジュールも名前空間も構造型も無く、状態はCOMMONブロック（プログラム全体で共有するグローバルメモリ）に置かれ、変数は頭文字で暗黙に型が決まり（I〜Nで始まれば整数。綴りを間違えると新しい変数が黙って生まれる）、名前は6文字まで。C++で明示的な型・オブジェクト指向・戻り値に直すと行対行の対応が無くなり、それが検証を難しくする。PetSc等の現代的な数値計算基盤への統合も要件。

3つの教訓。 ①移行コードを書く前にパリティハーネスを作る：Fortran側の状態を書き出すサブルーチン、C++側でチェックポイントを読み込むテスト枠、エージェントに正しく使わせるSkill.mdを用意し、「最終結果と、顧客の貯留層エンジニアが選んだ重要な中間点の数値一致」を合格条件にした（例：FortranでRHOGの値42.71834を書き出し、移行したC++モジュールのテストで同じ値を参照）。「モジュールが完了した」ことの最も安く、最も説得力のある証明。②エージェントに頼る前に文書を整える：文書は古いPDFとFortran内のコメントに散らばっていた。手続き型のFortranは全体が1本の呼び出し木に描けるので、自作パーサで木を作り、Vibe CLIで100超のエージェントを立て、葉から上へ各ノードのサブエージェントが（文書ライブラリとMistral OCRでPDFを引きながら）文書化して元リポジトリにPRを開き、cronで回るレビュアーエージェントが新しいPRを確認して修正タスクを積む。③この規模では、人のレビューゲートを持つ構造化ワークフローが、完全自律にも手作業にも勝る。

落ち着いた形。 顧客のエンジニアと呼び出し木から独立したモジュール（経験的に1万行未満）を切り出し、モジュールごとに「C++の目標アーキテクチャを生成→貯留層エンジニアがレビュー→承認後にタスクキューへ分解→タスクごとに計画→実装→テスト→繰り返しの実装サブワークフロー→人がPRをレビューし、マージまで変更を求める」。記事は限界も書く：Fortran側が自己完結して実行可能だったのは好条件で、外部システムに依存する・実行できるベースラインが無い・どこにも文書化されていない物理を含む移行は、この記事の範囲外。

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

試行	やり方	結果
1回目：完全自律	Fortranのサブルーチン1つに1エージェント、それぞれ独立に1週間かけてC++へ	動くが「近代化」ではない。COMMONブロックがグローバル構造体に1対1で写り、GOTOの制御がループや早期returnに直されず、「Fortranを C++の文法で打ち直した」コード
2回目：役割分担	planner・coder・tester・code quality reviewerが各モジュールで協働	品質は大きく改善。だがソースの複雑さに追いつかれ、バグに当たると数回直して止まる。介入できる人がいない
3回目：人が運転	人が coder→tester→reviewer のワークフローを操作し、モジュール単位で移行	2回目の品質を保ちつつ、止まったエージェントを人が解除。ここに落ち着いた

読み方

「数値の一致」を合格条件にしたのは、科学計算だからできた面もあるが、考え方は業務システムにも移せる。移行後の出力が移行前と同じであることを、人が読まなくても機械が示せる形にしてから、エージェントに任せる
エージェントは「止まる」。当サイトがAIエージェントの作り方で整理した「止まる条件」とは逆に、ここでは「止まったときに誰が解除するか」が設計の中心になった。CodexのAuto-reviewやGoal Modeが「承認を別エージェントに回す」方向なのに対し、Mistralの結論は「人がゲートに立つ」。規模と失敗の代償で答えが変わる
Skill.mdでハーネスの使い方を渡すのは、Skillsは「手順の道しるべ」として役立つという実験結果と同じ使い方。エージェントに「検証の手順」を教えることが、移行の質を決めている

筆者が確かめた点

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