Mistral、AIエージェントによる複雑なレガシーコード刷新の手法を解説 Fortran 77からC++への移行事例

対象は、テストスイートも集中管理されたドキュメントもない、物理計算中心の貯留層シミュレータである。Fortran 77にはモジュールや名前空間、構造化型がなく、状態はCOMMONブロックのグローバルメモリに置かれ、変数の型は頭文字で暗黙に決まる。構文の翻訳自体は難しくないが、手続き型からオブジェクト指向のC++へ移るにはアーキテクチャの再設計が必要で、行単位の対応がないため移行の検証が難しいという。

最初に作ったのが検証基盤（parity harness）である。Fortran側に状態をエクスポートするサブルーチンを加え、C++側にチェックポイントを読み込むテストフレームワークを用意し、エージェントを正しく誘導するSkill.mdファイルも整えた。比較するのは最終結果と、顧客の貯留層エンジニアが指定した重要な中間点の数値である。エージェントはFortranに出力行を挿入して状態を取得し、そのチェックポイントでC++モジュールを検証した。長時間のエージェント実行が安全になったと述べている。

ドキュメントは古いPDFやコード内コメントに散らばっていた。呼び出し元と呼び出し先の木構造をカスタムパーサで生成し、Vibe CLIで100を超えるエージェントを起動して文書化した。各エージェントはドキュメントライブラリやMistral OCRでPDFを参照し、木の葉から上へ向かってサブエージェントがPRを作成した。レビュー担当エージェントがcronで新しいPRを巡回し、必要に応じて修正タスクを割り当てた。

移行では3通りを試している。サブルーチンごとに1エージェントを置いた完全自律型は約1週間で動作したが、COMMONブロックがそのままグローバル構造体になり、GOTO制御も残るなど、刷新とは言えない出来だった。計画役、実装役、テスト役、品質レビュー役を組んだ構造化型は品質が上がったが、バグで停止しても介入できる人がいなかった。最終的に、人間がコーダー、テスター、レビュアーのエージェント群を運用してモジュール単位で進める形に落ち着いた。

モジュールは、経験的に約10,000行未満のFortranで自己完結する部分木として切り出す。目標のC++アーキテクチャを生成してエンジニアが確認し、承認後にタスクキューへ分解、計画、実装、テストを繰り返し、人間がPRをレビューして統合する。今回の条件は自己完結して実行可能なコードベースであり、外部システム依存や実行可能な基準がない移行、文書化されていない物理を含む移行は対象外と明記している。