レガシーコード変換AI実装ガイド【2026年版】— FortranからC言語への自動変換・I/O観察・検証ループの本番アーキテクチャ | 記事

レガシーコード変換AIとは、Fortran・COBOL・C言語で書かれた古いコードを、現代的な言語(C/Java/Rust/Python等)に自動変換するAIシステムである。2026年現在、米国の「Great Refactor」構想によりC/C++やCOBOLをRustやJavaに変換する取り組みが加速し、日本でも「脱COBOL」の動きが本格化している。本記事では、AIによるFortran→C言語変換の本番実装パターンを、renueの自社プロダクト「Fortran-to-C変換システム」の実装知見をもとに解説する。

レガシーコード変換AIの難しさ

「LLMにコードを投げれば変換できるのでは?」と思われがちだが、本番品質の変換には以下の課題がある。

課題	内容
1. データ形式の曖昧さ	Fortranのfscanf形式は実際のデータを見ないと特定不可能
2. 入出力の検証	変換後のコードが元と同じ出力を返すか確認が必要
3. 依存ライブラリ	古いFortranコードは32ビット専用ライブラリに依存することが多い
4. コンパイラ互換性	Intel ifort classic vs ifx、32ビット対応の廃止
5. 隠れた仕様	コードには書かれていない、実行時の暗黙の動作

これらを解決するため、単純な「LLMに翻訳させる」だけでなく、「実行環境での観察→仕様化→生成→検証」の**5段階パイプライン**が必要となる。

5段階変換パイプラインの全体像

┌────────────────────────────────────────────────┐
│ Stage 0.5: Fortran実行 & I/O観察                │
│  - 入力データファイル自動検出                  │
│  - Dockerコンテナ内でifortコンパイル&実行       │
│  - 入出力ファイルと標準出力を記録              │
│  - データ形式を分析(カンマ/空白/タブ区切り)    │
└────────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────────┐
│ Stage 1: 仕様書生成                             │
│  - I/O観察結果を使用(実際のデータ形式含む)     │
│  - 詳細な日本語仕様書を生成                    │
└────────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────────┐
│ Stage 2: C言語コード生成                        │
│  - 仕様書に基づいて正確なfscanf形式を生成      │
│  - 完全なC言語コードを出力                     │
└────────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────────┐
│ Stage 3-5: コンパイル・実行・検証               │
│  - Fortran: ifortでコンパイル                  │
│  - C: gccでコンパイル                          │
│  - 入出力を比較検証                            │
│  - 不一致の場合は最大3回自動リトライ           │
└────────────────────────────────────────────────┘

Stage 0.5: Fortran実行とI/O観察 — 最重要フェーズ

多くの変換ツールがスキップするが、本番品質を出すには**実際にコードを動かして観察する**ことが不可欠である。renueの実装では、このStageを「Stage 0.5」として独立させている。

なぜI/O観察が重要か

Fortranコードの以下の特徴は、ソースを読むだけでは判断できない。

入力ファイルの区切り文字(カンマ/タブ/空白)
数値の精度(整数/単精度/倍精度)
改行コード(LF/CRLF)
エンディアン(リトル/ビッグ)
固定長レコードのバイト数

これらは実際にサンプルデータで動かして、入出力を観察するしかない。renueの実装では`fortran_execution_service.py`(40,539文字)でこれを自動化している。

Docker + Intel Fortran環境

Fortranを実行するにはコンパイラが必要。Intel oneAPI HPC Kit(約4.14GB)を使うのが本格的である。

FROM intel/oneapi-hpckit:latest

# ifortまたはifxが利用可能
# 32ビット対応が必要な場合は2024.x系を選択

実行結果のデータ構造

@dataclass
class FortranExecutionResult:
    success: bool
    stdout: str | None
    stderr: str | None
    exit_code: int | None
    input_files: list[FileEntry]
    output_files: list[FileEntry]
    error_message: str | None
    error_code: str | None
    compilation_output: str | None
    execution_time: int | None  # ms

@dataclass
class FileEntry:
    path: str
    content: str
    sample: str  # 冒頭の数行サンプル

このデータを次のStageに渡すことで、AIは「実際のデータ形式」を踏まえた変換を行える。

Stage 1: 仕様書生成

I/O観察結果とソースコードをLLMに渡し、詳細な仕様書を日本語で生成する。

仕様書に含める要素

処理概要: コードの目的、入出力の役割
入力仕様: ファイル名、形式、区切り文字、列定義、データ型
処理ロジック: 各ステップで何をしているか
出力仕様: ファイル名、形式、カラム構成
エッジケース: エラーハンドリング、空ファイル対応
外部依存: 呼び出している関数、サブルーチン

日本語仕様書にする理由

LLMは英語と日本語の両方で生成できるが、**保守性**の観点で日本語が推奨される。変換後のコードをレビューする人間が日本の開発者である場合、日本語仕様書があればレビューが容易になる。また、将来別の言語に再変換する際も、日本語仕様書が中間表現として機能する。

Stage 2: C言語コード生成

Stage 1で生成した仕様書を入力としてC言語コードを生成する。ここでLLMは「Fortranのソースを読む」のではなく「仕様書を読む」のがポイントである。

仕様書ベース生成のメリット

曖昧な仕様が既に仕様書で言語化されているため、LLMが推測する余地が少ない
fscanf等の入力処理が仕様書の情報で確定的に生成できる
レビューワが「仕様書通りか」を確認するだけで良く、2言語の知識が不要

fscanf形式の生成

Fortranの`read(10, *)`は「カンマ/空白/タブ区切りの数値を読む」と曖昧だが、仕様書には実際の区切り文字が書かれている。これを元に正確な`fscanf("%d,%f,%f", ...)`を生成できる。

Stage 3-5: コンパイル・実行・検証ループ

変換後のCコードを実際にコンパイル・実行し、元のFortranコードと同じ出力を返すか検証する。

検証の流れ

Fortranコンパイル(ifort)
Cコンパイル(gcc)
同じ入力ファイルで両方を実行
出力ファイルをバイト単位で比較
不一致なら差分をLLMに渡して再生成
最大3回までリトライ

検証の実装ポイント

浮動小数点誤差: Fortranとgcc Cで微小な差が出る。許容誤差(epsilon)を設定
数値フォーマット: "1.0000" vs "1.0" のような表記揺れを吸収
エンディアン: バイナリ出力の場合は特に注意
改行コード: LF vs CRLF の統一

Dockerランタイムチェックの重要性

renueの実装では`docker_runtime_check.py`と`detect_docker_runtime_error`でDocker環境の問題を事前に検知する。

よくあるDocker関連エラー

コンテナが起動していない
Intel Fortranコンパイラがインストールされていない
ワークスペースディレクトリがマウントされていない
ネットワーク設定で外部APIにアクセスできない

これらを事前検知することで、ユーザーに分かりやすいエラーメッセージを返せる。

32ビットライブラリ問題(実運用での罠)

古いFortranコードは**32ビット専用ライブラリ**に依存していることが多い。これは現代の64ビット環境では大きな問題となる。

問題の構造

Makefileの要求: `FC = ifort`、`-m32` フラグ、libeigyolib.a/libsublib.a/libsyscover.a/libtcalib.a
Intel oneAPI 2025.x: ifort classic廃止、ifx のみ、32ビット非対応
Intel oneAPI 2024.x: ifort classic含む(32ビット対応)だが一般ダウンロード不可
Intel公式方針: 2025.0以降、32ビットサポート完全廃止

解決アプローチ

古いoneAPIバージョンを保持: 2024.x系のDockerイメージをビルドして保存
32ビットライブラリのソース再ビルド: ソースが残っていれば64ビット版を作成
ライブラリごと置き換え: ないバリュー関数は C言語で再実装
段階的移行: まずライブラリ依存のない部分だけを変換

OpenAI Agents SDK + Next.jsでのUI実装

renueの実装では、UIは`code-agent-nextjs-feature-fortran-2nd`というNext.jsプロジェクトで構築されている。OpenAI Agents SDKを使った対話型UIで、以下の機能を提供する。

コーディングタスクのストリーミング実行
ワークスペース(セッション)ごとのGitリポジトリ管理
組み込みツール(bash / git_clone / str_replace_editor)
NextAuth.jsによる認証
Prisma(MySQL)でのデータ永続化
Azure OpenAI切替対応(`LLM_PROVIDER=azure`)

renueの実装特徴 — Stage 4-5の「Pipeline Insights」

renueの実装では、変換パイプラインの実行履歴を分析して改善提案を生成する「Pipeline Insights」機能も実装予定である(Phase 4/5)。

analyzedRunCount: 分析対象の実行回数
trend: 成功率の推移
categoryStats: エラーカテゴリ別統計
suggestions: 改善提案
autonomyTaskProposals: 自動タスク提案

これにより、同じ種類のエラーが繰り返される場合、プロンプトや処理ロジックの改善を自動的に提案できる。

業界別の適用パターン

業界	主なレガシー言語	変換先候補
金融・保険	COBOL	Java / Kotlin
製造業(科学計算)	Fortran	C / C++ / Python
公共インフラ	C / C++	Rust
行政システム	COBOL	Java / Python
ゲーム業界	C / C++	Rust

世界的な動向

米国の「Great Refactor」構想は、C/C++やCOBOLをRustやJavaに自動変換するAIエージェントの大規模プロジェクトである。重要インフラを支えるレガシーシステムのセキュリティ脆弱性を解消することが目的で、メモリ安全な言語(Rust)への移行が主眼となっている。

日本でも「脱COBOL」の動きが活発で、金融機関ではCOBOLからJavaへの移行プロジェクトが進んでおり、生成AIの導入により従来の半分の期間で完了した事例も報告されている。

導入時のよくある失敗パターン

I/O観察をスキップする: データ形式が曖昧なまま生成され、動作しないコードが出来上がる
検証ループを省略する: 変換後のコードが本当に同じ結果を返すか確認しない
仕様書生成を飛ばす: LLMが推測でコード生成するため品質が不安定
32ビットライブラリ問題を軽視する: 古いFortranコードで後から詰まる
Dockerランタイムチェックを実装しない: ユーザーがエラー原因を特定できない
リトライ回数を無制限にする: 永久ループでコストが爆発する

renueのアプローチ — Self-DX First

renueは「Self-DX First」の方針のもと、レガシーコード変換のプロダクトを自社で実装・運用している。社内12業務を553のAIツールで自動化済み(2026年1月時点)であり、Fortran→C変換システムもその一つである(全て公開情報)。

公開されている技術スタック

バックエンド: FastAPI + Python
フロントエンド: Next.js + OpenAI Agents SDK
LLM: OpenAI / Azure OpenAI 切替対応
実行環境: Docker + Intel oneAPI HPC Kit (ifort/ifx)
データ永続化: MySQL + Prisma
認証: NextAuth.js

よくある質問

LLMだけで変換できないの?

単純なコードなら可能だが、本番品質を出すには「I/O観察→仕様書生成→コード生成→検証ループ」の5段階が必要。LLMだけでは実際のデータ形式やエッジケースを把握できず、本番で動かない可能性が高い。

変換時間はどれくらい?

1ファイル(500〜1,000行)あたり数分〜数十分。I/O観察とコンパイル・実行・検証のループが律速となる。一方、手動で変換する場合は数日〜数週間かかることが多く、AI導入の効果は大きい。

どのLLMを使うべき?

コード生成性能が高いLLMが必要。OpenAI GPT-4o、Anthropic Claude Opus、Azure OpenAIなどが選択肢。renueの実装ではAzure OpenAI切替対応になっており、セキュリティ要件に応じて選べる。

変換後のコードは本当に動くの?

検証ループで実際にコンパイル・実行・入出力比較しているため、少なくとも「同じ入力で同じ出力が得られる」ことは保証できる。ただし、性能特性(実行時間、メモリ使用量)は変換前後で変わる可能性があるため、本番運用前にベンチマークが必要。

どんなコードが変換しやすい?

数値計算中心で外部依存が少なく、サンプルデータが揃っているコードが最も変換しやすい。逆に、複雑な外部ライブラリ依存、GUI連携、OS固有機能を使うコードは難易度が高い。