FORTRANのシステム開発の完全ガイド - ブログ

FORTRANのシステム開発では、言語を新しいものへ置き換えることよりも、長年使われてきた計算ロジックの精度と再現性を守りながら、実行環境・画面・連携先を段階的に更新することが重要です。

本記事では、FORTRANのシステムが使われる領域、構成、種類、開発・移行の進め方、費用相場、クラウドやHPCの選び方、開発会社・サービスの選定ポイント、FAQまでをまとめて解説します。既存のFORTRAN 77資産をどう扱うべきか迷っている方も、全面刷新だけに限定せず、自社に合う現実的な選択肢を比較できます。

FORTRANのシステムとは何ですか？全体像を理解する

FORTRANのシステムとは、入力された条件をもとに数値計算やシミュレーションを実行し、結果を業務判断や設計、研究開発に利用する仕組みです。一般的な画面中心の業務アプリとは異なり、計算エンジンの正確さ、同じ条件で同じ結果を得られる再現性、長時間のバッチ処理、結果の説明可能性が価値の中心になります。

計算エンジンを中心に構成されます

典型的な構成は、入力画面やExcel、CSVなどのファイル取込、FORTRANで実装された計算エンジン、数値計算ライブラリ、結果を表示する帳票・グラフ、データベース、バッチ実行やジョブ管理から成ります。業務によっては、CAD・PLM・ERP・MESなどから条件を受け取り、計算結果を設計情報や製造指示へ戻す連携も必要です。認証、権限、監査ログ、バックアップ、障害時の再実行まで含めて初めて業務システムとして運用できます。

科学技術計算やシミュレーションで使われます

主な用途は、製造業の設計計算、構造・流体・熱解析、気象・地震・エネルギー計算、研究開発、制御、設備保全などです。計算量が大きく、数値アルゴリズムや配列処理を効率よく実行したい領域で長く利用されています。入力値の単位、丸め、境界条件、収束判定などの業務知識がソースコードや設定ファイルに埋め込まれていることも多く、単純な画面の作り直しとは異なる進め方が必要です。

FORTRANのシステムにはどのような種類がありますか？

FORTRANのシステムは、利用目的だけでなく、実行環境と更新方針によっても分類できます。種類を先に整理すると、既存資産を残す範囲、必要な周辺開発、性能要件、保守体制を比較しやすくなります。

レガシー資産を活用する計算システム

FORTRAN 77や固定形式ソース、暗黙の型宣言、COMMONブロック、独自拡張、古い入出力形式を含むシステムです。メインフレームやUNIX上で稼働し、周辺にC、COBOL、シェル、専用のジョブ管理が組み合わされていることもあります。仕様書が不足していても、実際の入力ファイル、出力帳票、担当者の判断基準、過去の計算結果を調べることで、暗黙の要件を可視化できます。

現行環境で運用するFortranシステム

現行規格に対応したFortranと、LinuxやWindowsなどの標準的な環境、数値計算ライブラリ、テスト自動化を組み合わせたシステムです。既存の計算ロジックを保ちながら、ビルド手順を標準化したり、Web画面やAPIを追加したりできます。計算部分を無理に別言語へ書き換えず、利用者が触れる部分だけを更新することで、リスクと効果のバランスを取りやすくなります。

HPC・並列計算を組み込むシステム

処理時間を短縮するため、OpenMPやMPIによる並列処理、CPUのベクトル化、GPUへのオフロード、HPCクラスタやクラウド計算基盤を組み合わせる種類です。並列化は速くなる一方で、実行順序による浮動小数点の差や、メモリ・通信のボトルネックが発生します。したがって、性能値だけでなく、許容誤差、再実行時の挙動、障害時のログ、計算ノードの確保方法まで要件に含める必要があります。

FORTRANシステムの老朽化で起きる問題

FORTRANが古いから問題なのではなく、実行環境や知識が特定の人・製品・手順に依存していることが問題になります。現状を把握しないまま全面的に書き換えると、動く画面は完成しても、計算結果の意味や過去データとの連続性を失う恐れがあります。

担当者の退職と仕様書不足

長年の運用で、入力値の妥当性や異常時の判断が担当者の経験に依存しやすくなります。ソースコードに残っていない業務ルールが、手作業の前処理や結果の補正に含まれている場合もあります。担当者への聞き取りだけでなく、通常・境界・異常の入力と、過去に承認された出力を一緒に記録し、業務知識をテストケースへ変換することが重要です。

コンパイラ・OS・ライブラリの制約

古いコンパイラやOSのサポート終了、商用ライセンスの変更、数値計算ライブラリの入手困難化は、障害時の復旧時間を長くします。主要な開発環境では、2025年の公式ドキュメントで従来型コンパイラの終了とLLVMベースの後継コンパイラへの移行が案内されています（出典: Fortran Compiler Developer Guide and Reference、2025年）。移行先で警告が増える、リンク方法が変わる、COMMONブロックや非標準拡張の挙動が変わる可能性があるため、単にコンパイルが通るだけで完了とはいえません。

計算結果の再現性を証明しにくい問題

コンパイラ、CPU、最適化オプション、丸めモード、乱数の初期値、並列処理の順番が変わると、見た目には小さくても数値差が生じることがあります。設計安全率や規制対応に関わる計算では、結果が完全一致するのか、工学的に許容できる誤差でよいのかを先に決める必要があります。許容誤差の根拠、使用した入力、実行環境、ログ、判定者を保存しておくと、監査や引き継ぎにも対応しやすくなります。

FORTRANのシステム開発・移行の進め方

開発や移行は、現状調査、比較検証、方式決定、実装、テスト、運用移行の順で進めます。最初から全機能を作り直すのではなく、代表的な計算ケースで技術的・業務的な成立性を確かめてから範囲を広げると、見積りの精度と社内合意を高められます。

▶ 詳細はこちら：FORTRANのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 資産棚卸しと要件定義を行います

ソース、実行ファイル、コンパイラ、OS、ライブラリ、ジョブ、入力データ、出力帳票、外部連携、利用者、障害履歴を一覧化します。固定形式、暗黙型、COMMONブロック、非標準拡張、文字コード、ファイルの桁・区切り、日付や単位の扱いも確認対象です。さらに、誰が何の判断に使う計算なのか、停止できる時間はどの程度か、結果の保存期間は何年かを業務部門と合意します。

2. ゴールデンデータを決めてPoCを行います

旧環境で承認済みの入力と出力を、代表ケースとして複数用意します。通常値だけでなく、境界値、異常値、欠損値、最大規模のデータを含め、旧新の結果差、処理時間、エラー時の挙動を比較します。PoCは3〜10人月、約300万〜1,500万円、1〜3か月が一つの目安ですが、資産の複雑さと検証範囲で変動します。最終的には「完全一致」「許容誤差内」「利用者承認」のどの基準で受け入れるかを決めます。

3. 実装・テスト・リリースを段階化します

方式を決めたら、計算エンジン、入出力、画面、データベース、帳票、バッチ、認証の順序と依存関係を整理して実装します。単体テストだけでなく、旧新比較、境界値、異常値、性能、並列実行、再実行、障害復旧、権限、ログ、バックアップ、利用者受入試験を行います。リリース後も一定期間は旧環境を参照できるようにし、差異が出たときに入力・ビルド・環境のどこに原因があるか追跡できる体制を残します。

進め方の詳細を、要件整理からテストまでの実務手順として確認したい場合は、まず現行資産とゴールデンデータを準備し、PoCを独立した工程として見積もることが出発点になります。

FORTRANシステムの移行方式は4種類あります

移行方式は、延命、再コンパイル・リホスト、ラッパー化、全面再構築の4種類に整理できます。どれか一つが常に正解ではなく、計算ロジックの重要度、現行環境の寿命、利用者体験、性能、予算、将来の保守人材で選びます。

延命は短期の安定を優先する方式です

現行環境を保ち、障害対応や最小限の画面改修だけを行う方式です。初期費用を抑えやすく、計算結果の連続性も守りやすい一方、古いOS・コンパイラ・ハードウェアへの依存と、担当者不足は残ります。延命を選ぶ場合は、最低限でもソース、ビルド手順、ライセンス、バックアップ、復旧手順を文書化し、いつ次の方式へ移るか判断する期限を設定します。

再コンパイル・リホストは計算資産を活かしやすい方式です

ソースコードを大きく書き換えず、OSやコンパイラ、実行基盤を更新する方式です。アルゴリズムを守りやすく、既存の結果比較を行いやすいことが利点です。ただし、固定形式、非標準拡張、古い入出力、リンク設定、文字コード、暗黙の初期化が障壁になります。コンパイル警告を放置せず、警告の分類と対応方針を記録することが品質確保につながります。

ラッパー化は段階的な使い勝手の改善に向きます

FORTRANの計算エンジンをAPIやバッチとして呼び出し、Web画面、データベース、認証、帳票などを別の技術で整える方式です。計算の中核を再実装せずに、入力ミスの防止、進捗表示、結果検索、権限管理を改善できます。呼び出し時の単位、桁、エラーコード、タイムアウト、同時実行数を明確にしないと、周辺の改善が新しい障害点になるため、インターフェース契約を先に定めます。

全面再構築は長期保守と標準化を重視する方式です

計算ロジックを別の言語や新しい構成で再実装し、業務要件、画面、データモデル、運用も見直す方式です。保守しやすさや人材確保を改善しやすい反面、暗黙の仕様を取りこぼしたり、結果差の原因を特定できなくなったりするリスクがあります。全面再構築を選ぶ場合も、旧システムを正解データの生成装置として一定期間残し、ケース単位の比較を繰り返すことが重要です。

FORTRANのシステム開発費用相場と内訳

FORTRAN移行だけを対象にした公開価格は限られているため、費用は人月単価と必要工数を分けて考えます。JUAS「ソフトウェア・メトリクス調査2025」では、スクラッチ開発の加重平均単価が96万円/人月、パッケージ利用開発とSaaS利用開発が144万円/人月とされています（出典: JUAS「ソフトウェア・メトリクス調査2025」、2025年）。これはFORTRAN固有の定価ではなく、概算の基準として利用する数字です。

▶ 詳細はこちら：FORTRANのシステム開発の見積相場や費用/コスト/値段について

規模別の費用と期間の目安

現状調査・資産棚卸し・PoCは3〜10人月、約300万〜1,500万円、1〜3か月が目安です。小規模な再コンパイルやPC・Linux移植は10〜30人月、約1,000万〜4,300万円、3〜8か月程度です。画面、データベース、帳票、認証、バッチ、外部連携まで含む中規模刷新は30〜100人月、約3,000万〜1億4,400万円、6〜18か月が目安になります。

複数言語、メインフレーム、複数工場、リアルタイム連携、厳格な精度保証、24時間運用を含む大規模案件は100〜500人月、約9,600万〜7億2,000万円、1〜3年以上になる可能性があります。いずれも「人月単価×工数」で算出した推定レンジであり、コード行数だけで決めた価格ではありません。実際の見積りでは、調査、移植、再構築、検証、データ移行、運用設計を分けて提示してもらいます。

見落としやすい追加費用

計算エンジンの開発費だけでなく、GPU・HPCサーバー、ストレージ、バックアップ、商用コンパイラ、数値計算ライブラリ、クラウド利用料、データ転送、監視、セキュリティ対策、現地試験が発生します。移行期間中に旧環境と新環境を並行稼働させる場合は、二重のインフラ費用や運用担当者の負荷も見込む必要があります。

運用保守費は、障害対応だけでなく、OS・コンパイラ更新、脆弱性対応、ライブラリ更新、計算結果の監査、利用者追加、性能チューニングまで含めて定義します。初期開発費の15〜20%程度を年間保守費の一般的な目安にすることがありますが、FORTRANの専門人材を専任確保する場合は上振れするため、対応時間と対象範囲を契約で明確にします。

クラウド・HPC・セキュリティの選び方

FORTRANをクラウドへ移せるかどうかは、言語ではなく、データの機密性、計算量、利用頻度、通信量、ライセンス、運用要件で決まります。計算需要が月ごとに変わるなら、必要なときだけ計算ノードを起動できるクラウドが有効です。一方、常時稼働、機密データ、特殊な接続、厳しい遅延要件がある場合は、オンプレミスや専用環境を含めて比較します。

性能はベンチマークと費用をセットで評価します

HPCでは、CPUのコア数を増やせば必ず速くなるとは限りません。計算の並列化率、メモリ帯域、ノード間通信、I/O、ジョブ待ち時間、ライセンス制約が結果を左右します。代表ケースで1件あたりの処理時間、同時実行数、月間実行回数、1回あたりの費用を測り、現行環境との総保有コストで比較します。GPUを使う場合は、計算部分のオフロード可否と、結果差の検証もPoCに含めます。

計算データと開発工程の安全性を確保します

個人情報や設計情報を扱う場合は、保存場所、暗号化、アクセス権限、秘密情報の管理、監査ログ、バックアップ、復旧目標、委託先の再委託を要件に入れます。2026年3月に公表された経済産業省などの「サイバーインフラ事業者に求められる役割等に関するガイドライン」は、ソフトウェアの開発・供給・運用者と顧客が、サプライチェーン全体で責任を分担する考え方を示しています。出典は経済産業省「サイバーインフラ事業者に求められる役割等に関するガイドライン」（2026年）です。

FORTRAN固有のセキュリティだけを考えるのではなく、ビルド環境、ソース管理、依存ライブラリ、実行ノード、データ連携、運用担当者まで一つのシステムとして確認します。開発会社やサービス提供者に任せる場合も、脆弱性の報告窓口、修正の期限、ログの保管者、契約終了時のデータ返却を決めておくと、将来の引き継ぎが容易になります。

2026年時点の注目動向

2025年以降は、従来型コンパイラからLLVMベースの環境への移行、OpenMPによるCPU・GPU活用、HPCクラウド、生成AIを使ったコード解析やリファクタリングが注目されています。ただし、生成AIに計算ロジックを一括変換させるだけでは、丸め、境界条件、暗黙の初期化、例外処理を正しく再現できるとは限りません。AIは資産の分類、依存関係の抽出、コメント生成、テスト候補の作成に活用し、結果の承認は計算業務を理解する担当者が行う体制が現実的です。

FORTRANの開発会社/ベンダーの選び方

「FORTRANを書ける」という一点だけでなく、計算結果を保証しながら業務システムを移行できるかを見極めます。候補先には、匿名化した資産概要、代表ケース、現行環境、希望時期、困っている点を提示し、調査・PoC・本開発を分けた提案を依頼します。

計算領域と移行実績を確認します

確認すべき実績は、単なるプログラミング経験ではありません。FORTRAN 77や固定形式の解析、コンパイラ変更、メインフレームやUNIXからの移行、数値結果の旧新比較、並列化、Web・API連携、運用保守の経験を分けて聞きます。公開事例がある場合も、対象資産、移行範囲、精度基準、期間、移行後の保守範囲まで確認し、自社案件へそのまま当てはめられるかを判断します。

技術検証と品質保証の方法を質問します

「旧新で結果が違ったとき、どのように原因を切り分けますか」「許容誤差は誰が決め、どの証跡を納品しますか」「コンパイラやライブラリを更新したとき、どのテストを再実行しますか」と質問します。回答が、テストを実施するという抽象的なものにとどまらず、ゴールデンデータ、比較レポート、実行環境の固定、レビュー担当者、受入基準まで具体化されているかを見ます。

契約・納品物・引き継ぎ条件を明確にします

見積りには、ソース解析、環境構築、設計、実装、テスト、データ移行、教育、運用保守を分けて記載してもらいます。納品物には、ソース、ビルド手順、依存ライブラリ一覧、テストデータ、結果比較表、設計書、運用手順、障害時の連絡先、ライセンス一覧を含めます。将来別の担当者や別の開発会社へ引き継げる権利と形式になっているかも、契約前に確認します。

開発会社/ベンダーの候補を比較するときは、実績、数値計算の専門性、移行方式の提案力、検証体制、クラウド・オンプレミス対応、運用保守、引き継ぎ条件を同じ質問票で確認すると、価格だけに引きずられにくくなります。

▶ 詳細はこちら：FORTRANのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：FORTRANのシステム開発の発注/外注/依頼/委託方法について

FORTRANのシステムに関するよくある質問（FAQ）

ここでは、FORTRANのシステム開発や移行を検討する際によくある疑問に答えます。判断の軸は、言語の新旧だけではなく、計算結果、業務継続、セキュリティ、将来の保守性です。

FORTRANのシステムは別の言語へ移行すべきですか？

必ずしも移行すべきではありません。計算ロジックが安定していて、現行環境を維持できるなら延命や再コンパイルが合理的です。人材、OS、コンパイラ、連携、画面、監査要件に課題がある場合は、ラッパー化や段階移行を比較し、全面再構築はゴールデンデータで結果を検証できる体制を整えてから選びます。

FORTRANのシステムをクラウドで動かせますか？

動かせますが、現行のOS、コンパイラ、ライブラリ、ファイル入出力、ライセンス、データ機密性を確認する必要があります。計算ノードを必要なときだけ使える点はクラウドの利点ですが、データ転送費、起動時間、利用上限、障害復旧、GPUや商用ライセンスの条件を含めて総額を比較します。小さな代表ケースをクラウドで実行し、性能と結果差を確認してから本番化します。

FORTRANの移行費用はどのくらいかかりますか？

小規模な調査・PoCなら約300万〜1,500万円、再コンパイルや小規模移植なら約1,000万〜4,300万円が目安です。画面、データベース、外部連携、性能・精度試験まで含むと、30〜100人月規模で約3,000万〜1億4,400万円程度になる可能性があります。公開価格ではなく、人月単価、資産の複雑さ、検証件数、周辺システム、HPC・ライセンス費用で変わるため、まず診断とPoCを分けて見積もります。

開発会社には何を準備して相談すればよいですか？

ソースコード、実行ファイル、コンパイラとOSの情報、入出力サンプル、過去の正解データ、外部連携一覧、処理時間、障害履歴、利用者数、希望時期を準備します。機密情報は匿名化し、まず資産概要と代表ケースだけを共有する方法もあります。相談時には、移行後の結果差をどう判定するか、納品物と将来の引き継ぎをどうするかも質問します。

まとめ：FORTRANのシステムは精度を守る段階移行が重要です

全面刷新の前に計算資産を評価します

最初に確認するのは、FORTRANという言語の古さではなく、計算ロジックが現在の業務でどれほど重要か、現行環境を何年維持できるか、結果の差異をどの程度許容できるかです。評価結果によっては、延命や再コンパイルで十分な場合もあれば、ラッパー化や全面再構築が必要な場合もあります。

まず現状調査とPoCの範囲を決めます

ソース、実行環境、入出力、正解データ、外部連携、利用者、運用条件をそろえ、代表ケースで旧新比較を行います。調査とPoCの成果物、許容誤差、処理時間、見積りの前提を文書化すれば、関係者が同じ基準で移行方式と予算を判断できます。

FORTRANのシステムは、科学技術計算、設計、解析、研究開発、制御など、計算結果そのものが業務価値になる領域で今も重要な役割を担っています。刷新では、古い言語を使っていることだけを理由に全面再構築へ進むのではなく、計算ロジック、入力・出力、依存環境、担当者の知識、セキュリティ、将来の保守を一体で調べます。

最初に3〜10人月程度の現状調査・PoCを行い、代表ケースのゴールデンデータ、許容誤差、処理時間、障害復旧、運用負荷を確認します。その結果をもとに、延命、再コンパイル、ラッパー化、全面再構築を比較し、調査・移行・検証・保守を分けた見積りと契約を整えます。判断の基準を「画面が動くか」だけでなく、「正しい結果を再現でき、説明でき、将来引き継げるか」に置くことが、FORTRANのシステム開発を成功させる近道です。