書き手が去っても、40,000行の古いコードは数字を頼りに引っ越せる

1. Mistralが見せた、古いコードの引っ越し術

Mistral AIが公開したのは、新しいAIモデルではなく、ひとつの現場の記録です。欧州のエネルギー事業者が抱えていたFortran 77の貯留層シミュレーターのうち、中核となる40,000行をC++へ移しました。テストも、一か所にまとまった資料もない状態からの出発です。書かれているのは成功談よりも、どう確かめ、どこでつまずいたかでした。

01 1977年の作法で書かれたコード

Fortran 77は、その名のとおり1977年に標準化された言語です。モジュールも名前空間も構造体もありません。データはCOMMONブロックと呼ばれる、プログラム全体で共有する大きな引き出しに置かれます。どこで誰が書き換えたのかを追いかけにくい設計です。

さらに、変数の型は名前の頭文字で決まります。綴りを1文字間違えると、エラーにならないまま別の変数が静かに生まれてしまう。名前は最長6文字なので、中身も想像しにくい。作者が去ったあと、コードに埋め込まれた知識は取り出しにくくなります。Mistralが最初に向き合ったのは、この読みにくさでした。

02 翻訳ではなく、住み替えだった

Mistralによれば、ある言語の文法を別の言語へ置き換える作業は、もうおおむね片づいた仕事です。難しいのは、手続き型のFortranをオブジェクト指向のC++へ組み替えることでした。散らばっていたCOMMONの配列はGasPropertiesというひとつの引数にまとまり、ループは呼び出す側へ移ります。

こうなると、元のコードと新しいコードを1行ずつ見比べることはできません。そのうえ、PetScのような現代の科学計算の枠組みともつなぐ必要がありました。言葉を訳すのは簡単でも、暮らし方ごと変えるのは難しい。古い家の荷物を、間取りの違う新居に収め直す仕事に近いものです。

2. 数字が合えば、書き手がいなくても信じられる

KPEがこの事例でいちばん生活に近いと見たのは、正しさを数字で確かめる仕組みを先に作るという教えです。人の記憶には頼らず、古いプログラムと新しいプログラムの出す値が一致するかで判断する。そのうえで、散らばった資料をAIに読ませ、コードの隣に置き直しました。移す前に、まず読めるようにしておく。この順番が効いています。

01 移す前に、答え合わせの道具を作る

Mistralが「パリティ・ハーネス」と呼ぶのは、新旧のコードが同じ答えを出すかを確かめる仕組みです。ここで言う一致とは、最終結果だけの話ではありません。顧客の貯留層エンジニアが指定した重要な途中経過まで、数値が等しいことを指します。

用意したのは、Fortran側の状態を書き出すサブルーチン、その記録をC++に読み込むテストの枠組み、そしてエージェントに正しい使い方を教えるSkill.mdの3つです。たとえばRHOGという変数の値42.71834を書き出し、移行後のC++の基準値にしました。書いた人の代わりに、数字が証言してくれます。

02 百を超えるAIが、埋もれた資料を読み直す

資料は古いPDFと、Fortranの中に埋もれたコメントに散らばっていました。そこでMistralは独自のパーサーでコードを解析し、どの処理がどの処理を呼ぶかを一本の木として描き出します。手続き型のコードには、全体をこうした呼び出しの木で表せるという便利な性質があるからです。

その木をもとに、Vibe CLIで百を超えるエージェントを起動しました。各エージェントは文書ライブラリとMistral OCRで関連するPDFを読み、木の葉から幹へ向かって説明を書き、プルリクエスト（変更の提案）を出します。定期的に動くレビュー役のエージェントがそれを確かめ、必要なら修正を指示しました。資料が整ったことは、この取り組みの大きな副産物になっています。

3. AIに任せきりでも、人が抱え込むのでもなく

Mistralは、エージェントにどこまで任せるかを3回試しています。全部任せると、動くけれど中身は古いままのコードになった。役割を分けると質は上がったものの、難所で止まった。最後に落ち着いたのは、人がワークフローを動かし、AIが詰まったところをほどく形です。自律と監督のあいだに、ちょうどいい場所がありました。

01 全部任せたら、Fortranの着ぐるみになった

最初は、Fortranのサブルーチンごとに1体のエージェントを割り当て、1週間かけてそれぞれ独立にC++へ移させました。できあがったコードは動きます。ただ、COMMONブロックはそのままグローバルな構造体になり、GOTOで飛び回る流れも、ループや早期リターンに組み直されていませんでした。

Mistral自身、それは「C++の文法で打ち直したFortran」で、近代化とは呼べないと書いています。速く訳せることと、住みやすいコードになることは別の話です。任せきりの自由は、古い癖まで丁寧に写し取ってしまう。

02 役割を分けたら、今度は立ち止まった

2回目は、計画する係、書く係、テストする係、品質を見る係の4つのエージェントを、モジュールごとに組ませました。自由の代わりに段取りを与えたことで、コードの質ははっきり良くなったといいます。ひとりの万能選手から、チームで働く形へ移したわけです。

ところが、元のコードの複雑さに、やがてエージェントが追いつかれます。バグにぶつかると何度か直そうとして、そのまま止まってしまう。そばで手を貸す人がいなかったからです。段取りだけでは、行き止まりは越えられませんでした。

03 人がハンドルを握る、5段階の流れ

最終的にMistralが選んだのは、書く・テストする・レビューするエージェントの流れを人が動かし、モジュール単位で移していく方法です。移す単位は、呼び出しの木の中から、貯留層エンジニアと一緒に切り出しました。どれも、おおむね10,000行未満の独立したまとまりです。

流れは5段階あります。C++の設計を生成する。エンジニアが確認する。承認されたらタスクに分ける。タスクごとに計画・実装・テストを繰り返す。最後に人がプルリクエストを見て、修正を重ねながらマージまで運ぶ。AIが手を動かし、人が道を示す。この役割の分け方が、コードの質を支えています。

4. 職場の古い仕組み、いまから決めておくこと

これは大企業だけの話ではありません。前任者のマクロ、誰も触らない社内ツール、古い計算シートを抱える職場なら、同じ順番を借りられます。まず答え合わせの方法を決め、次に資料を集め、AIに任せる範囲と人が確かめる関所を先に決めておく。道具より先に段取りを決めた人ほど、引っ越しを楽しめるはずです。

01 向いているのは、いま動いている仕組み

Mistralによれば、今回の元コードはそれだけで完結していて、実際に動かすこともできました。これは恵まれた条件だったといいます。動く古いシステムがあれば、その出力をそのまま正解として使えるからです。一方で、外部のシステムに頼っているもの、基準として動かせないもの、どこにも書かれていない物理を含むものには、この記事では扱っていない難しさがあると断っています。

しかも今回の40,000行は、全体300,000行のうち、最初のスプリントで扱った中核部分です。これは完成の報告ではなく、長い道のりの始まりの記録と言えます。職場の古い仕組みが「まだ動いているか」を確かめることが、最初の分かれ道になります。

02 明日から始められる、3つの下ごしらえ

Mistralが挙げた3つの教訓を職場の言葉にすると、こうなります。ひとつめは、新しくする前に「今の答え」を記録しておくこと。ふたつめは、AIに頼る前に、散らばった資料を一か所に集めること。読めないものは移せません。みっつめは、AIに全部は任せず、人が確認する関所を工程に組み込むことです。

この3つは、どれもお金をかけずに今日から始められます。古いExcelの計算結果を保存しておく。手順書のPDFを1つのフォルダにまとめる。それだけで、次の引っ越しの足場になります。AIは頼もしい引っ越し業者です。でも、どの箱に何を入れるかを決めるのは、そこに住んでいる人なんです。

5. よくある質問

6. まとめ