「COBOLシステムの仕様書がなく、コードを読まないと何をしているか分からない」「移行ベンダーに見積もりを依頼したら『ソースコードを解析してから正式見積もりを出す』と言われた」「COBOL担当者が退職したが、後継者がコードを読んでも理解できない」——ドキュメントが存在しないCOBOL資産を持つ企業から、こうした悩みが届きます。COBOLソースコード解析（リバースエンジニアリング）は、埋もれた業務知識を取り戻す唯一の手段です。本記事では、解析の具体的な4ステップ、AIツールの活用法、設計書再生成のアプローチを整理します。

『COBOLのコードはあるが、何をしているか誰も分からない』とお悩みですか？ 25 年の経験で解析・可視化の方法を一緒に整理します。 無料相談 ＞

COBOLソースコード解析が必要なケース

まず、COBOLソースコード解析が必要な状況を確認します。以下のいずれかに当てはまる場合は、解析を検討すべき時期です。

  • COBOL担当者が退職・引退し、コードの内容を説明できる人間がいない
  • 設計書・仕様書が存在しない、または20年以上更新されていない
  • 移行プロジェクトを開始するにあたり、現行システムの業務ロジックを把握する必要がある
  • 法改正・機能追加の影響範囲を特定できない（「どこを修正すると他のどこに影響するか分からない」）
  • 移行ベンダーから「ソースコード解析フェーズを設けたい」と提案されている

COBOLソースコード解析の4ステップ

COBOLソースコード解析には、以下の4ステップが標準的なアプローチです。

ステップ 1：プログラム一覧の作成と優先度付け

最初に「どのCOBOLプログラムが存在するか」を把握します。COBOLシステムは数十～数百のプログラムで構成されていることが多く、全プログラムを同時に解析しようとすると工数が膨大になります。

  • プログラム名・ファイル名の一覧を作成
  • 各プログラムのコード行数・最終更新日・呼び出し関係を整理
  • 業務重要度（日次バッチ・月次バッチ・リアルタイム処理など）でプログラムに優先度をつける
  • 優先度の高いプログラムから解析着手することで、限られた工数で最大の効果を得る

ステップ 2：静的解析による構造把握

COBOLコードを実行せずにコード自体を読んで（静的解析）、プログラムの構造を把握します。

  • データ定義（WORKING-STORAGE・FILE SECTION）の洗い出し：どんなデータ項目が定義されているか
  • 処理フロー（PROCEDURE DIVISION）の把握：プログラムが「何をどの順番でしているか」の流れ図作成
  • 外部連携の確認：どのファイル・データベース・他プログラムと連携しているか
  • 計算ロジックの抽出：金額計算・日付計算・条件分岐の内容を文書化

ステップ 3：業務担当者へのクロスチェック

ステップ2で把握した処理内容を、業務担当者（経理・営業・製造など）に確認します。コードから読み取れる「何をしているか」と、業務担当者が知っている「なぜそうなっているか」を突き合わせることで、ブラックボックスの業務ロジックが明らかになります。

特に以下の点は、業務担当者への確認が不可欠です：

  • 独特な計算式の意味（「この係数はどこから来ているか」）
  • 例外処理の背景（「このフラグが立ったときの特別処理は何のためか」）
  • 過去の法改正・取引先対応で追加された処理の内容

ステップ 4：設計書・業務仕様書の再生成

ステップ2・3の成果をもとに、設計書・業務仕様書を新たに作成します。作成する文書の標準セットは次の通りです。

文書種別内容主な用途
業務フロー図 業務プロセスの開始から終わりまでの流れ 移行要件定義・新システムの業務設計の基礎
データ定義一覧 システムで扱うデータ項目・型・制約の一覧 データ移行設計・新DBスキーマ設計の基礎
業務ロジック仕様書 計算式・条件分岐・例外処理のルール 移行後システムへの業務ロジック実装の根拠
プログラム間連携図 どのプログラムがどのプログラムを呼び出すか 影響範囲の把握・移行順序の決定

AIツールを活用したCOBOL解析の効率化

近年、大規模言語モデル（LLM）を活用したCOBOLコード解析ツールが登場し、ステップ2の静的解析の工数を大幅に削減できるようになっています。

AIツールでできること

  • COBOLコードの日本語説明生成：「このPERFORM文は何をしているか」の説明を自動生成
  • 処理フロー図の自動生成：コードの構造から処理フローのドラフトを生成
  • データ項目の意味推定：変数名・使われ方から「この変数は何を表しているか」を推定
  • 類似処理のパターン検出：同一・類似のロジックがどこに存在するかを検索

AIツールの限界

  • 業務的な背景は推定できない：「なぜこの計算式か」の理由はコードから読み取れない
  • 複雑なネスト処理・GOTO文が多いコードは精度が下がる
  • AIの出力は必ず人間が確認：誤解析のリスクがあるため、業務担当者との照合が必須

AIツールは「人間の解析工数を削減するアシスタント」であり、完全自動化の手段ではありません。AIによる解析工数削減（30～50%）と、業務担当者との確認（クロスチェック）を組み合わせることが現実的なアプローチです。

自社のCOBOLコード、解析にどれくらい費用・期間がかかるか把握できていますか？ コード規模・ドキュメント状況をもとに、解析の費用と段取りを一緒に整理します。
無料相談はこちら ＞

費用・期間の目安

解析規模 プログラム数 費用目安 期間目安
小規模 ～50本 100万～300万円 1～2ヶ月
中規模 50～200本 300万～1,000万円 2～4ヶ月
大規模 200本以上 1,000万～3,000万円 4～8ヶ月

AIツールを活用することで費用・期間を30～50%削減できるケースがあります。ただし、業務担当者へのヒアリング・クロスチェックの工数は削減できません。解析費用は移行プロジェクト全体費用の10～20%程度が標準です。

ソースコード解析でよくある失敗パターン2つ

失敗 1：解析結果を確認せずに移行要件定義に使った

AIツールや外注による解析結果を、業務担当者が確認せずにそのまま移行要件定義に使ってしまうケースです。コードから読み取れる処理と、実際の業務意図が一致しないことがあるため、必ず業務担当者によるクロスチェックを経てから要件定義に反映することが重要です。

失敗 2：全プログラムを均等に解析しようとした

プログラム数が多い場合に「全部均等に解析しよう」とすると、重要でない処理に工数を取られ、本当に重要な業務ロジックの解析が中途半端になります。業務重要度と移行優先度に基づいてプログラムに優先度をつけ、重要なものから深く解析するアプローチが費用対効果を高めます。

『COBOLのコードはあるが、移行のためにどう解析すればいいか分からない』とお困りの方へ
クオンツでは、COBOLソースコード解析の段取り・費用試算から、解析後の移行計画立案まで、無料でご相談をお受けしています。
無料相談 ＞

まとめ｜ソースコード解析は「移行の前提条件」

COBOLソースコード解析は、ドキュメントのないCOBOL資産から「何をしているか」を取り戻す唯一の手段であり、移行プロジェクトの前提条件です。

  • 解析の4ステップ：プログラム一覧・優先度付け → 静的解析 → 業務担当者クロスチェック → 設計書再生成
  • AIツールで工数を30～50%削減できるが、業務担当者との確認は省略不可
  • 費用目安：100万～3,000万円（プログラム数次第）、移行費用全体の10～20%程度
  • 最大の失敗回避策：解析結果を業務担当者が必ず確認してから移行要件定義に使う

COBOL業務知識の継承とドキュメント化については、COBOL業務知識の継承・可視化ガイドをご参照ください。COBOL移行プロジェクト全体の進め方については、COBOLマイグレーションの費用相場ガイドも合わせてご覧ください。

株式会社クオンツでは、『COBOLソースコード解析の費用試算』『AIツールを活用した解析支援』『解析結果をもとにした移行要件定義の支援』のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社のCOBOLコード規模・ドキュメント状況・予算感に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。

FAQ｜

よくあるご質問

COBOLソースコード解析とは何ですか？
COBOLで書かれたプログラムのソースコードを読み解き、処理フロー・データ定義・業務ロジック・外部連携を文書化する作業です。リバースエンジニアリングとも呼ばれます。仕様書・設計書がないCOBOL資産から「何をしているか」を明らかにするための唯一の手段であり、移行プロジェクトの前提条件です。
COBOLのリバースエンジニアリングはどのくらい費用がかかりますか？
プログラム数によって異なります。50本未満の小規模なら100万～300万円・1～2ヶ月、50～200本の中規模なら300万～1,000万円・2～4ヶ月、200本以上の大規模なら1,000万～3,000万円・4～8ヶ月が目安です。AIツールを活用することで費用・期間を30～50%削減できるケースがあります。
AIでCOBOLソースコードを解析できますか？
はい、近年のLLM（大規模言語モデル）を活用したツールで、COBOLコードの説明生成・処理フロー図の自動作成・データ項目の意味推定が可能です。解析工数を30～50%削減できるケースがありますが、業務的な背景（なぜそのロジックか）の推定には限界があり、業務担当者によるクロスチェックが必須です。
COBOLソースコード解析で設計書を再生成できますか？
はい、コード解析と業務担当者へのヒアリングを組み合わせることで、業務フロー図・データ定義一覧・業務ロジック仕様書・プログラム間連携図を再生成できます。これらは移行プロジェクトの要件定義・新システムの設計に直接活用できます。
COBOLコードが何十万行もある場合、全部解析する必要がありますか？
必ずしも全量解析する必要はありません。業務重要度と移行優先度に基づいてプログラムに優先度をつけ、重要なものから深く解析するアプローチが費用対効果を高めます。重要でないプログラム（廃止予定・利用頻度が低い）は解析の深さを浅くするか、スコープから除外することも選択肢です。
ソースコード解析は社内でもできますか？外注すべきですか？
COBOLの読み書きができる社内担当者がいれば、社内解析も可能です。ただし、体系的な解析方法・AIツールの活用・設計書再生成のノウハウを持つ外注ベンダーを活用する方が、品質と効率の両方が高くなるケースが多いです。特に、解析結果を移行要件定義に直接活用する場合は、外注による第三者視点が有効です。
COBOLソースコード解析はいつ実施するのが最適ですか？
COBOL担当者がまだ在籍しているうちに実施するのが最も効率的です。担当者が在籍していれば、コードから読み取れない部分の解釈を直接確認できます。担当者退職後は解析工数が1.5～2倍になる可能性があります。移行プロジェクトの着手を検討し始めた段階で、並行して解析に着手することをお勧めします。