NAW / BUSINESS 05
IMAGE: AI生成ビジュアル
BUSINESS / BUSINESS
Mistral、Fortran 77約4万行のC++移行事例を公開 — エージェントの自律度を3段階で検証
Mistralは2026年9月9日、欧州エネルギー事業者の物理集約型貯留層シミュレータ(Fortran 77、テストなし・文書なし)をC++へ移行した事例を公開した。完全自律・多エージェント構成・人間運用の3段階を試し、検証ハーネスを先行整備した人間+エージェントのモジュール単位移行に落ち着いた過程をまとめている。
Mistralは2026年9月9日、欧州のエネルギー事業者向けに、Fortran 77で書かれた約4万行のコードをC++へ移行した事例を公式ブログで公開した。対象は物理計算が中心の貯留層シミュレータで、テストスイートも集中的な文書もない状態だったという。初回スプリントでは全体約30万行のうちコア機能にあたる4万行を扱い、コードベース自体は自己完結して実行可能だったとしている。本稿は公式記事の一次情報に絞って整理する。
なぜ単なる構文翻訳ではないのか — Fortran 77の制約と再設計
- 構文翻訳は解決済みとの見立て: スニペット単位の言語間翻訳は最近のモデルなら数回の反復で収束する「ほぼ解かれた課題」と位置づけている。
- 本質は構造リファクタ: 手続き型からオブジェクト指向C++への移行ではアーキテクチャの作り替えが必要になる。Fortran 77にはモジュール・名前空間・構造化型がなく、状態はプログラム全体で共有されるCOMMONブロックのグローバルメモリに存在し、変数は先頭文字で暗黙に型付けされる(綴り間違いが新規変数を黙って生む)。変数名は6文字制限で暗号的になりがちと説明されている。
- 検証の難しさ: 記事の例では、Fortran側のグローバル変数への書き込みと、C++側の値を返す設計・オブジェクト引数では行対応の照合ができず、移行の正しさを示す別の手段が必要になる。加えてPetScなど現代の科学技術計算基盤への統合も要件だったという。
エージェントの自律度を3段階で検証 — 人間運用に着地
- 第1段階(完全自律): Fortranサブルーチンごとにエージェントを割り当て、約1週間かけて各自が独立にC++へ翻訳。動作はするものの、COMMONブロックはグローバル構造体に1対1対応し、GOTO駆動の制御フローも残存する「FortranをC++構文で打ち直した」状態で、モダナイゼーションとは呼べなかったという。
- 第2段階(構造化した多エージェント): プランナー・コーダー・テスター・コード品質レビューがモジュールごとに協働する構成にし、品質は大幅に改善した。一方、複雑さに直面するとバグ修正を数回試して停止し、介入できる人間がいないことが課題になったという。
- 第3段階(人間が運用する方式): 人間がコーダー・テスター・レビューのエージェント群を運用し、コードベースをモジュール単位で移行。第2段階の品質を保ちつつ、行き詰まりを人間が解消できる配置とした。
- モジュール分割: 担当の貯留層技術者とともにcaller-callee木を使い、経験上約1万行以下の自己完結したサブツリーを独立モジュールとして切り出し、カスタムパーサで木を生成して各モジュールに同一ワークフローを適用したという。
検証ハーネスを先に作る — 数値パリティを移行完了の根拠に
- 3点セット: Fortranコードベースの状態を書き出すサブルーチン、チェックポイントをC++側に読み込むテスト基盤、エージェントに正しい使い方を指示するSkill.mdファイル。
- 数値パリティの例: Fortran側に1行挿入して変数RHOGの値(実行例では42.71834)をダンプし、移行後のC++モジュールのテストで同じ値を参照チェックポイントとして使った例が示されている。
- 位置づけ: 長時間のエージェント実行を安全にし、検証しやすく説得力のある移行完了の根拠になるため、「あらゆるコードモダナイゼーション案件の最初の手順にすべき」と記事は述べている。ハーネス構築への先行投資は正味プラスだったとしている。

出典: Modernizing complex legacy code with AI agents.
なお、成果の定量評価(工数・欠陥率など)や顧客名は公式記事に記載がなく、本稿では扱わない。記事自体も、実行可能なベースラインがない案件や物理仕様が文書化されていない案件では別の困難が加わると断っている。