Mistralは9月9日、欧州のエネルギー事業者が持つリザーバーシミュレーターをFortran 77からC++へ、自社のAIエージェントを使って移行した顧客事例を公開した。コードベース全体は30万行で、今回手を入れたのはそのうち4万行。プロジェクト開始時点ではテストスイートもなく、ドキュメントも一箇所にまとまっていなかった。
レポートはFortran 77の扱いにくさを具体的に挙げている。モジュールも名前空間も構造化型も存在せず、プログラムの状態はCOMMONブロック――プログラム全体で共有されるグローバルメモリのようなもの――に保持されている。変数は先頭の文字によって暗黙的に型が決まり、変数名は最大6文字までしか使えないため、コードを読むにはほぼ推測に頼るしかない。
最初の試みはタスクをまるごとエージェントに任せるやり方だったが、1週間かけても成功しなかった。そこで人が間に入り、モジュール単位で作業を分割する方式に切り替えた。各モジュールは計画、実装、テスト、コード品質レビューの4つの役割に分けられ、「計画→実装→テスト→再実行」というループで進める。人がプロセスに残った主な役割は、エージェントが行き詰まったときに解きほぐすことだった。
先にドキュメント、その後にコード
ドキュメント作業はVibe CLI上で、100体を超えるエージェントを並列に起動して行った。各エージェントはドキュメントライブラリとMistral OCRを通じて関連するPDFを取り込んで読むことができる。産業用ソフトウェアの物理的な前提は紙の報告書やスキャンされた資料にしか書かれていないことが多く、一元化されたドキュメントがないプロジェクトではここが最も手間のかかる部分になる。
モジュール分割は経験則で決めた。Fortranコードは1モジュールあたり約1万行以内に収める。
数値の一致を合格基準にする
このプロジェクトを支えていたのは、3つの要素からなる整合性検証の仕組みだ。Fortranコードベースの実行時状態を書き出すサブルーチン群、そのチェックポイントをC++に読み込むテストフレームワーク、そして両者を正しく使うようエージェントを導くいくつかのSkill.mdファイル。
レポートにある具体例はこうだ。あるエージェントがFortranコードに1行を挿入し、変数RHOGの値を出力させたところ、その実行では42.71834という値が得られた。次に同じ数値を参照チェックポイントとして使い、移行後のC++モジュールをテストした。
"Numerical agreement is the cheapest, most convincing proof that a module is done."
数値が一致することは、あるモジュールの移行が完了した証拠として最も安く、最も説得力がある。
ここでの本質的な教訓は、Mistralがどのモデルを使ったかとはあまり関係がないのかもしれない。電力、石油、気象、航空といった分野の基幹計算コードには、1970~80年代に書かれたFortranコードが今も大量に残っている。テストもドキュメントもなく、開発した本人はとうに退職しているというのも同じ構図だ。この十数年、「書き直す」という話は承認の段階でたいてい止まってきた。基準となる比較対象がなければ、書き直した成果物に誰も判を押せないからだ。Mistralのやり方は、その承認権を数値チェックポイントに渡した点にある。この部分はどのエージェントを使うかとは無関係で、動くレガシーコードさえあれば自前でも組める。
前提条件についてもレポートは率直だ。Mistral自身、今回の出発点は好条件だったと認めている――Fortranコードベースは自己完結していて、実際に動作した。レポートでは、これより明らかに難しくなる3つのケースを挙げている。外部システムに依存しているケース、動作する基準となるコードがそもそもないケース、物理的な前提がまったく文書化されていないケースだ。手作業での書き直しに比べてどれだけ速いかについては、数値は示されていない。
参考資料：Mistral公式ブログ、CocoLoop；コード行数、モジュール分割のしきい値、エージェントの役割分担、RHOGチェックポイントの数値は公式の事例報告で確認。