金融機関のレガシーコードをJiteraで解析する

金融機関では、長年稼働しているCOBOLやPL/SQL、SQLバッチ、ジョブ定義が業務を支えています。一方で、設計書が古い、処理の意図を知る担当者がいない、変更時の影響範囲を把握しにくいといった課題も起こりやすくなっています。

開発AIエージェント Jiteraを活用すると、利用が認められたソースコードや設計資料をもとに、処理の概要、データの流れ、依存関係、改修時の確認ポイントを整理する草案作成を支援できます。本記事では、金融機関の閉域環境や厳格なセキュリティ要件を想定し、レガシー資産を段階的に解析する手順を解説します。対象言語、接続方式、利用できる構成や機能は、契約内容・環境条件・権限によって異なるため、導入前に確認してください。

生成された設計書や分析結果は、コードや業務資料と照合してレビューする前提の草案です。そのまま本番変更、移行、リリース、業務判断の根拠にせず、開発・運用・業務・セキュリティの担当者による確認と必要なテストを行ってください。

金融機関のレガシーコードがブラックボックス化する理由

レガシーコードがブラックボックス化する原因は、古い言語で書かれていることだけではありません。次のような要因が重なることで、処理の全体像を把握しにくくなります。

• 業務変更のたびに部分改修が重ねられ、設計書と実装の内容が一致しなくなる
• 共通サブルーチンや外部プログラムが多く、1つの処理だけでは完結しない
• PL/SQLのストアドプロシージャ、テーブル、ビュー、トリガーが複雑に連携している
• 夜間バッチや月次バッチが複数のジョブから構成され、実行順序が分散している
• ジョブスケジューラの定義、シェル、SQL、アプリケーションの関係が一元管理されていない
• 例外処理や手動リカバリの手順が、コードではなく担当者の経験に依存している

たとえば、口座振替データを作成する処理を変更する場合、対象プログラムだけでなく、入力ファイル、作業テーブル、集計処理、後続の連携ジョブまで確認が必要になることがあります。処理の入口と出口が見えないまま改修すると、別の業務や帳票に影響する可能性があります。

ベテラン担当者の退職・異動による知識継承の課題

金融システムでは、次のような情報が正式な設計書に残っていない場合があります。

• 特定のコードやフラグが示す業務上の意味
• 例外的な顧客や商品だけに適用される分岐条件
• 障害発生時に最初に確認するジョブやテーブル
• 再実行してよい処理と、再実行してはいけない処理
• 法改正や商品改定の際に、過去の経緯から残されている処理

これらを理解している担当者が退職・異動すると、後任者がソースコード、過去の障害記録、議事録、口頭説明を突き合わせる必要があります。引き継ぎ期間が短い場合は、保守対応の遅延や調査品質のばらつきにつながる可能性があります。

導入前に確認するセキュリティとデータ境界

金融機関のソースコードには、業務ロジック、データ構造、接続先、運用手順などの機密情報が含まれることがあります。一般的な生成AIサービスへコードを貼り付けることが、社内規程や委託先管理の要件に合わない場合もあります。

導入時には、少なくとも次の項目を確認します。

• ソースコードや設計資料をどの環境に保存するか
• 外部のモデルやサービスへデータが送信されるか
• 入力データの保持や追加学習への利用に関する契約・設定
• 操作履歴やアクセスログを取得・監査できる範囲
• 部門、プロジェクト、担当者ごとの閲覧権限
• 閉域網、プロキシ、ファイアウォール、認証基盤との接続条件
• Jitera、利用するLLM、ストレージ、ログの責任分界

セルフホスト、オンプレミス、社内VPC、プライベートクラウド、完全閉域環境などの利用可否や詳細仕様は、提供範囲、構成、契約条件によって異なります。「社内に置くから安全」と判断せず、データフロー図と運用ルールを作成し、最新の公式資料、契約書、セキュリティチェックシートと照合してから社内のセキュリティ確認を進めてください。

Jiteraでレガシー資産を解析する手順

Step 1：導入方針と解析環境を決める

コードを社外に出せない場合は、セルフホストなどの構成を候補として検討します。ただし、利用可能な構成や必要なコンポーネントは案件ごとに確認が必要です。自社のクラウドVPCやオンプレミス環境に配置する場合も、コード、生成結果、ログ、モデルとの通信経路を整理し、境界を明確にします。

情シス、セキュリティ部門、開発部門、運用部門で次の項目を確認します。

Step 2：解析対象を小さく区切る

最初から基幹システム全体を登録するのではなく、業務単位、プログラム群、またはバッチ単位で対象を区切ります。対象範囲を決めたら、次の資料をそろえます。

• COBOL、PL/SQL、SQL、シェルなどのソースコード
• COPY句や共通部品などの参照ファイル
• テーブル、ビュー、インデックス、ストアドプロシージャの定義
• ジョブスケジューラのジョブ名、実行順序、実行条件
• 入出力ファイルの定義
• 現行の設計書、運用手順書、障害対応記録
• 業務用語、コード値、フラグの定義

機密区分、版、適用期間、作成者、確認者も記録しておくと、生成結果の根拠を追跡しやすくなります。

Step 3：ソースコードと関連資料をコンテキストとして整理する

登録する前に、対象範囲と参照してよい資料を明示します。

旧版と現行版が混在する場合は、適用期間や「正式版・参考資料」の区別を付けます。個人情報、決済情報、認証情報、秘密鍵などは、社内規程と環境の取扱条件に従い、登録範囲を慎重に決めてください。

Step 4：解析結果を段階的に作成する

次の順序で、草案を段階的に作成します。Jiteraの出力だけで確認できない事項は、推測で補わず「要確認」として分けます。

1. プログラム概要：目的、入力、出力、主な分岐
2. 処理フロー：開始条件から終了条件までの処理順序
3. データ項目一覧：入力・出力項目、更新項目、参照テーブル
4. 詳細設計書の草案：処理単位、条件分岐、エラー処理、外部呼び出し
5. DB依存関係：テーブル、ビュー、プロシージャ、入出力の関係
6. 影響範囲一覧：変更対象と、その変更を参照する処理

プロンプト例

株式会社○○の契約管理システムについて、登録済みのソースコードと設計資料だけを参照してください。

対象範囲：
- 月次保険料計上処理
- 入力ファイル manual-v1.md に記載された業務条件
- 関連するCOBOLプログラムとPL/SQLプロシージャ

次の形式で整理してください。
1. 処理の目的
2. 起動条件と入力
3. 処理手順
4. 条件分岐と例外処理
5. 更新されるテーブル
6. 後続処理への出力
7. コードから確認できない事項

推測で補わず、根拠となるプログラム名や処理箇所を併記してください。

Step 5：生成物を現行資産と照合する

生成された詳細設計書や処理フローを、次の観点でレビューします。

• 正常系だけでなく、入力不備や異常終了時の処理が含まれているか
• 共通部品や外部プログラムの呼び出しが抜けていないか
• コード上の条件と、業務資料に記載された条件が一致しているか
• 更新対象のテーブルと、実際のDB定義が一致しているか
• 日次、月次、締め処理などの実行タイミングが正しいか
• 「推定」「要確認」とされた箇所に確認担当者が割り当てられているか
• コードにない手作業、例外運用、リカバリ手順が別途確認されているか

バッチ処理の依存関係と影響範囲を整理する

ジョブ定義、スクリプト、ソースコードの命名規則が異なる場合は、対応表を作って参照資料に含めます。たとえば、ジョブ名「JOB-DAILY-01」がプログラム「BILLING-MAIN」を起動し、テーブル「T_CONTRACT_MONTHLY」を更新する、といった関係を明記します。

影響範囲を調べる際は、直接参照だけでなく、後続ジョブ、外部連携、帳票、運用手順まで確認します。根拠が確認できない項目は「要確認」と明記し、変更可否をAIの整理結果だけで判断しないでください。

効果を限定した検証で評価する

金融業界向けの資料では、レガシー資産解析、影響範囲調査、設計書生成、テスト観点整理などの活用テーマが示されています。ただし、解析工数の削減率、開発期間、テスト工数、ROIなどの数値は、対象システム、資料の整備状況、レビュー体制、契約・環境条件によって変わります。特定の削減率や投資対効果を一般化せず、対象を限定した検証で評価してください。

検証では、導入前後で条件をそろえ、次の指標を記録します。

• 解析にかかった時間
• 生成物の修正回数とレビュー時間
• 未確認事項や誤りの件数
• 影響範囲調査に含まれた対象の妥当性
• テスト観点の追加・修正件数
• セキュリティ審査で発生した課題
• 担当者の確認負荷と引き継ぎへの有用性

効果の数値だけでなく、根拠の追跡しやすさ、レビューのしやすさ、現行資産との整合性、情報管理のしやすさも含めて継続判断を行います。

まとめ

金融機関のレガシーコード解析では、次の順序で進めると、ブラックボックス解消とセキュリティ確認を両立しやすくなります。

1. セルフホストを含む配置、データ保護、ネットワーク構成を確認する
2. 対象業務と解析範囲を小さく区切る
3. ソースコード、DB定義、ジョブ定義、業務資料を整理する
4. プログラム概要、処理フロー、詳細設計、依存関係の草案を順に作成する
5. 開発・運用・業務・セキュリティ担当者がレビューする
6. 要確認事項を解消し、必要なテストや承認を行う
7. 効果を測定し、妥当性を確認したうえで対象業務を段階的に広げる

Jiteraは、レガシー資産の整理、設計書や処理フローの草案作成、影響範囲調査、テスト観点の整理を支援します。正確性、網羅性、工数削減、投資対効果を保証するものではありません。重要な変更や正式な成果物への利用にあたっては、参照元との照合、必要な修正、担当者によるレビューと承認を行ってください。