COBOLからC#への移行: UK企業向けガイド2026

COBOLは今なお、英国の銀行、保険会社、公共機関、大手小売業者で稼働する膨大なソフトウェアの土台を支えています。その多くは金銭を処理しており、今日それを保守している開発者が入社するはるか以前から動き続けているものも少なくありません。COBOLの専門知識が退職とともに現場から失われていくなか、モダナイゼーションへの圧力は年々高まっており、COBOLからC#への移行は、英国の組織が最も頻繁に検討する選択肢のひとつです。

すでにMicrosoftスタックに投資している組織にとって、.NET上のC#は利用可能な移行先のなかでも最も有力なもののひとつです。C#はモダンで静的型付けのオブジェクト指向言語であり、.NET 8以降でクロスプラットフォームに動作し、そしてCOBOLに特に適した特長をひとつ備えています。それは、正確な金融計算のために作られたネイティブのdecimal型です。

本ガイドでは、COBOLからC#への移行が実際に何を伴うのか、英国企業が取りうるアプローチ、そのコスト、そしてリスクの管理方法を解説します。

TL;DR

• C#は、すでに.NETまたはAzureを採用している組織にとって最も適したCOBOL移行先であり、そのネイティブな128ビットdecimal型は、サードパーティ製ライブラリなしにCOBOLのパックド10進フィールドへ直接マッピングされます
• 3つの主要なアプローチ(自動変換、並行リライト、そして段階的な「ストラングラーフィグ」移行)はそれぞれ異なるリスクとコストのプロファイルを持ち、多くの英国企業はハイブリッドを採用します
• 中規模の移行は通常200,000ポンドから800,000ポンドのコストがかかり、1年から2年を要します。スコープの過小評価が最も一般的な失敗要因です
• 自動変換ツールは構造的に正しいC#を生成しますが、完成したシステムを生成するわけではありません。データアクセス層、テスト、業務検証はツールの有無にかかわらず手作業として残ります

なぜC#はCOBOL移行の有力な移行先なのか

C#はCOBOLの唯一の合理的な移行先ではありません。Python、Java、Go、C++、Rustはいずれも文脈次第で妥当です。C#が際立つのには具体的な理由があります。

ネイティブなdecimal精度。 これはC#を選ぶ最も強力な技術的論拠です。COBOLの金融フィールドは、正確な10進値を表すパックド10進(COMP-3)と数値PIC 9句を使用します。C#の組み込みdecimal型は、金融および金銭計算のために特別に設計された、基数10の128ビット固定精度型です。COBOLの10進フィールドはこれに直接マッピングされ、丸めの意外な結果もなく、外部ライブラリも不要で、正確な演算を保持します。JavaはBigDecimalで同じ正確さを実現できますが、より冗長なオブジェクトAPIを介する必要があります。バイナリ浮動小数点に依存する言語(Javaのdouble、Goのfloat64、Rustのf64)は、追加の作業なしには金額の扱いに向きません。

.NETエコシステム。 多くの英国企業はすでにWindows Server、SQL Server、Active Directory、Azureを運用しています。こうした組織にとって、COBOLからC#への移行は、モダナイズされたシステムを、チームがすでに運用・監視・保護しているスタックの内側にとどめます。データアクセスはADO.NET、Entity Framework Core、Dapperへきれいにマッピングされます。

クロスプラットフォームでモダンなランタイム。 モダンな.NETはWindows専用ではありません。C# 12のコードは.NET 8以降 (長期サポートリリース)上でWindows、Linux、macOSにわたってコンパイル・実行され、Azure、AWS、GCP上に自然にコンテナとしてデプロイされます。C#への移行は、もはや単一のオペレーティングシステムに縛られることはありません。

静的型付けとツール。 C#の強力な静的型付けは、コンパイル時にエラーのカテゴリ全体を捕捉します。これは数十年前の業務ロジックを翻訳する際に重要です。Visual Studio、Rider、.NET CLIは、成熟したデバッグ、プロファイリング、リファクタリングのサポートを提供します。

開発者の確保しやすさ。 C#は英国で最も広く使われている企業向け言語のひとつであり続けており、長期的な採用と保守の人材プールは厚みがあります。

何から移行しようとしているのかを理解する

英国企業の文脈におけるCOBOLシステムは、通常いくつかのカテゴリに分類され、それぞれで移行の性格が変わります。

バッチ処理システム。 典型的なCOBOLのワークロードです。ファイルから大量のレコードを読み込み、逐次処理して書き戻します。これらは通常、最も移行しやすく、C#のバックグラウンドサービスやストリーミングI/Oへうまくマッピングされます。

トランザクション処理システム。 オンライントランザクション処理で、IBMメインフレーム上のCICSやIMSによって駆動されることが多いものです。これらは最も大きなリスクを抱えます。トランザクション境界、ロールバック動作、接続管理のすべてを、.NETの同等物へ慎重にマッピングする必要があるためです。

帳票生成システム。 COBOLの帳票処理は、一般にPDF、Excel、Webダッシュボードといったモダンな形式を出力するC#パイプラインへ移行されます。

インターフェースおよびミドルウェア層。 古いシステムとデータベースの間に位置するCOBOLプログラムは、モダナイズされたアーキテクチャではしばしばC#サービスになります。

真の翻訳を要するCOBOL構文

安全な移行は、行ごとのテキスト置換ではなく、COBOLのセマンティクスを翻訳できるかにかかっています。真のマッピングを要する構文には次のものが含まれます。

• PERFORM範囲はC#のメソッド呼び出しになり、段落(paragraph)とセクション(section)はメソッドへ分解されます。
• **EVALUATE / WHEN**はC#のswitch文またはパターンマッチングへマッピングされます。
• 88-level条件名はブール型のプロパティまたはヘルパーメソッドになります。
• **MOVE CORRESPONDING、REDEFINES、OCCURS**は、型付きフィールド、意図のユニオン、配列やコレクションへの慎重なマッピングを要します。
• PIC句は適切なC#型へマッピングされます。英数字にはstring、サイズ指定の整数にはshort / int / long、精度を保持したパックド10進フィールドにはdecimalです。
• COPYおよびREPLACEディレクティブ(コピーブック)は、ネストされたコピーブックを含め、パースの前または最中に解決される必要があります。
• EXEC SQL(DB2)、EXEC CICS、VSAMファイルアクセスにはそのまま置き換えられるC#の同等物がなく、ADO.NET / Entity Framework Coreやモダンなサービスパターンへの意図的な再設計を最も必要とする部分です。
• EBCDICエンコーディングと固定長レコードレイアウトは、Unicodeと型付きモデルへの明示的な変換を要します。

移行アプローチ

主要なアプローチは3つあり、それぞれ異なるリスクとコストのプロファイルを持ちます。

1. 自動変換

ツールがCOBOLをパースし、同等のC#を生成します。うまく行えば、出力は名前空間、クラス、正しいdecimalマッピングを備えた構造的に正しいC# 12になります。安易に行えば、静的メソッドを詰め込んだ単一のクラスが生成され、元のCOBOLよりも保守が難しくなります。

最適な用途: COBOL依存を素早く排除することが優先で、その後に段階的なリファクタリングを行う大規模なコードベース。

リスク: どのツールも完成した本番運用可能なシステムを生成しません。埋め込みSQL、CICSとのやり取り、動的呼び出しは依然として人間の判断を要します。

Mecanik COBOLからC#への移行ツール は、優れた自動変換がどのようなものかを示しています。テキスト置換ではなく完全なコンパイラパイプライン(字句解析器、パーサー、意味解析器、コードジェネレーター)を実行し、COBOLのセクションと段落をC#のメソッドへ分解し、COMP-3フィールドをネイティブのdecimalへマッピングし、ネストされたコピーブックを含むCOPY / REPLACEディレクティブを解決し、手作業での対応を要するすべてのEXEC SQL、EXEC CICS、動的CALLを明示するMigration Reportを生成します。また、C#の予約語と衝突する識別子への接頭辞付与や、ACCOUNT-RECORD形式の名前をPascalCaseへ変換するといった実務的な細部も扱います。

2. 並行リライト

C#システムを既存のCOBOLシステムと並行して構築します。両者を同じ入力に対して実行し、C#システムが合格するまで出力を相互に検証します。合格した時点でCOBOLを退役させます。

最適な用途: 決済、給与計算、給付金など、継続性を危険にさらせないミッションクリティカルなシステム。

リスク: 2つのシステムを並行して運用することは、移行期間中の運用コストを倍増させ、規律ある突合を要求します。

3. 段階的移行(ストラングラーフィグ)

個々のCOBOLプログラムを、一度にひとつずつC#の同等物へ置き換えます。システムはハイブリッドになり、最終的には純粋なC#になります。

最適な用途: 完全なリライトが現実的でない、大規模なモノリシックCOBOLシステム。業務を稼働させ続けながら、チームが学習し反復できるようにします。

リスク: ハイブリッド状態が計画より長く続くことがあり、COBOLとC#のコンポーネント間の慎重なインターフェース設計を要求します。

大半の英国企業の移行では、ストラングラーフィグのアプローチを、定型的な部分の多いセクションに対する選択的な自動変換と組み合わせることが、リスクと速度の最良のバランスをもたらします。

英国におけるCOBOLからC#への移行コスト

コストはコードベースの規模、複雑さ、アプローチに大きく左右されます。英国企業プロジェクトの目安となる範囲は次のとおりです。

これらの数字は、分析、移行、テスト、本番稼働支援を対象とします。継続的な運用コスト、トレーニング、そしてプロジェクトの途中でしばしば表面化する下流の統合作業は含みません。

Mecanik COBOLからC#への移行サービス は英国企業の移行に特化しており、評価、変換、Entity Frameworkによるデータアクセス層の実装、出力の同一性テストをカバーします。複数の移行先言語を比較検討している組織には、COBOL移行の概要 がPython、Java、Go、C++、Rustを含む選択肢の全体像を示しており、COBOLからPythonへの移行ガイド は最も人気の高い代替の移行先を本ガイドと同じ深さで扱っています。

COBOLがIBM z/OSや類似のインフラ上で稼働している移行については、Mecanikレガシーメインフレーム移行サービス が、コード移行に加えてインフラの退役までをカバーします。

主要なリスクとその管理方法

COBOLからC#への移行は、予測可能な理由で予算を超過したり失敗したりします。

ドキュメント化されていない業務ロジック。 COBOLシステムは、外部ドキュメントを一切持たずにコードへ埋め込まれた30年から40年分の業務ルールを抱えていることがよくあります。そのロジックを発見して文書化することは、あらゆる移行のなかで最も時間がかかり、リスクの高い部分です。

データ形式への依存。 パックド10進(COMP-3)、EBCDICエンコーディング、固定長レイアウトには、自動的なC#の同等物がありません。C#のdecimal型は演算の側面をきれいに解決しますが、切り替えの前に、すべてのフィールドを実データでマッピングしテストする必要があります。

データアクセス層。 COBOLロジックの変換は、そのデータアクセスの置き換えよりも容易であることが多いものです。DB2に対するEXEC SQLとVSAMファイル処理は、ADO.NET、Entity Framework Core、Dapperへ再設計する必要があり、これがしばしば単一で最大の作業項目になります。

パフォーマンスへの期待。 一晩で1000万件のレコードを処理するCOBOLバッチジョブは、安易なC#リライトでは満たせないかもしれない基準を設定します。プロファイリング、最適化、そして場合によってはアーキテクチャの変更が必要になります。

回帰テストのカバレッジ。 C#の出力がCOBOLと一致することを証明する唯一の信頼できる方法は、実データ(必要に応じて匿名化したもの)を用いた包括的な回帰テストです。そのテストスイートを移行開始前に構築することは、任意ではありません。

切り替えのリスク。 本番でC#へ切り替える瞬間は、最もリスクの高い局面です。ロールバック手順と突合チェックを備えた詳細な切り替え計画が必須です。

要点

• C#は.NETまたはAzureスタックを採用する組織にとって最も有力なCOBOL移行先です。主にそのネイティブな128ビットdecimal型が、COBOLのパックド10進フィールドを正確な精度で、外部ライブラリなしに直接マッピングするためです。
• 3つの主要なアプローチは自動変換、並行リライト、段階的移行であり、大半の英国企業プロジェクトは選択的な自動化を伴うストラングラーフィグのアプローチを用います。
• コストは小規模システムの約80,000ポンドから、メインフレームの全面退役に及ぶ数百万ポンド規模のプログラムまで幅があります。
• 最大のリスクは、ドキュメント化されていない業務ロジック、データ形式への依存、そしてデータアクセス層の再設計です。この3つすべてに移行開始前に対処することが不可欠です。

よくある質問(FAQ)

なぜJavaやPythonではなくCOBOLからC#へ移行するのですか。 組織が.NETエコシステム、またはWindowsとAzureのインフラ上で稼働している場合はC#を選びます。そのネイティブなdecimal型は、COBOLの金融フィールドに特に適しています。JavaはJVM上のチームにとって自然な選択であり、Pythonは可読性とAI統合を優先する組織に向いています。

C#のdecimal型がCOBOL移行に優れているのはなぜですか。 C#のdecimalは金融計算のために作られた基数10の128ビット固定精度型であり、COBOLのCOMP-3およびPIC 9の10進フィールドが、正確な演算とサードパーティ製ライブラリなしに直接マッピングされます。数値にバイナリ浮動小数点を使う言語は、COBOLの10進動作を再現するために追加の作業を要します。

移行後のC#コードはLinuxで動作しますか、それともWindows専用ですか。 両方で動作します。C# 12は.NET 8以降を対象としており、Windows、Linux、macOSにわたってクロスプラットフォームで、Azure、AWS、GCP上に標準アプリケーションまたはコンテナとしてデプロイされます。

COBOLロジックはC#へ自動変換できますか。 はい、ツールを使えば可能です。優れたコンバーターは、適切なクラス構造とdecimalマッピングを備えた構造的に正しいC#を生成しますが、埋め込みSQL、CICSとのやり取り、動的呼び出しについては推測せずに手作業用として明示します。データアクセス層と業務検証は人間の作業として残ります。

COMP-3やEBCDICのようなCOBOLのデータ形式はどうなりますか。 COMP-3フィールドはC#のdecimalへきれいにマッピングされます。EBCDICのテキストと固定長レイアウトは、Unicodeと型付きモデルへの明示的な変換を要し、すべての構造は本番利用の前に実データに対してテストすべきです。

COBOLからC#への移行にはどれくらいの期間がかかりますか。 小規模でよく文書化されたシステムは3か月から9か月かかります。中規模の企業システムは12か月から24か月を要します。大規模なメインフレームプログラムは、全面退役に3年から5年かかることがあります。