11月11日、AWSが「How CTBC Bank modernizes mainframe reverse engineering with a multi-agent pipeline on Amazon Bedrock AgentCore」と題した記事を公開した。台湾のCTBC銀行がCOBOLコードのリバースエンジニアリングをAmazon Bedrock AgentCore上のマルチエージェントパイプラインで自動化し、作業工数を約4倍削減した取り組みを詳しく紹介している。「LLMを導入すれば解決する」という発想ではなく、分解と品質ゲートの設計こそが効率向上の主因だという点が、この事例の核心だ。
COBOLリバースエンジニアリングの何が難しいのか
金融機関のコアシステム近代化において、コードを移行すること自体より「そのコードが何をしているか」を理解する工程がボトルネックになる。これはCTBC銀行も同様だった。
CTBC銀行（台湾のCTBCフィナンシャルホールディングの銀行子会社）は、「Project NAVI」と呼ばれるコアシステム全体の刷新を進めている。障壁となっているのは、数千本のCOBOLプログラムが生成する規制報告書・内部レポート・システム間転送だ。1本のレポートを追跡するだけで、3〜5本のCOBOLプログラムとコピーブック（共有ソースフラグメント）をまたぎ、4〜5個の中間ステージングファイルを経由する。これを人手で追うと、アナリスト1人あたり約8人日かかっていた。
さらに厳しい制約がある。規制当局や監査人が依存するロジックがCOBOL内に埋め込まれており、解釈ミスが規制違反申告につながりかねない。自動コード変換だけでは不十分で、「元のビジネス意図」を正確に復元する必要がある。
単一エージェントで壁にぶつかった
最初の試みは、約1,000行のプロンプトを持つ単一の分析エージェントをベースにしたものだった。4か月で1,000件超の分析ドキュメントを生成できたが、次の問題が露呈した。
- 100種類以上のレポートタイプにまたがってプロンプトを使い回した結果、エッジケースで出力が不安定になった
- 品質がオペレーターのスキルに依存。COBOLに詳しいエンジニアは全出力を検証したが、データエンジニアはAI出力の約70%を未検証のまま承認していた
- プログラム間の依存関係を自動でたどる仕組みがなく、アナリストが手動でリンクを追う必要があった
- Markdown→Word→Excel→SQLの変換時にロジックとフォーマットが失われるハンドオフ問題
- 1回の実行で使われるプロンプト指示は30〜40%にすぎず、トークンを無駄に消費
バックログは縮まらず、別のアーキテクチャが必要と判断された。
マルチエージェントパイプラインへの転換
新アーキテクチャはAmazon Bedrock AgentCore上に構築された。AgentCoreは、AIエージェントを安全にスケールして構築・デプロイ・運用するためのマネージドプラットフォームだ。
設計の核心は「Supervisorエージェント＋7つの単一責任サブエージェント＋各ステージ間の品質ゲート」という構造にある。
パイプラインの流れ
- Scanner — ユーザーが入力するのはファイル名1つだけ。COBOL/JCLをオフラインでインデックス化した依存グラフを参照し、1秒以内に依存関係を解決（従来は2〜3回の手動検索が必要だった）
- Lineage / Logic（並列実行） — データの流れとビジネスルールを並行解析し、壁時計時間を短縮
- Bridge — LineageとLogicの結果をマージし、ターゲットモデルへのマッピングを埋める
- FSD Writer — ビジネス担当者が読める機能仕様書（FSD）を生成
- SQLエージェント — FSDとBridgeマッピングからOracle SQLおよびETLスクリプトを生成
- Unit Testエージェント — フィクスチャテーブルを作成し、各ケースをセーブポイント内で実行して検証
品質ゲートはLLMの自己採点に頼らない
各ステージの間には定量的な閾値を持つ自動ゲートが置かれている。「LLMに自分の出力を採点させると満点を付けた」という実際の失敗から、すべてのゲートメトリクスはコードで計算する設計に変更された。
| ゲート | 条件 |
|---|---|
| G1 | クリティカルコンポーネントの欠損ゼロ（ハードストップ） |
| G2 | 系譜カバレッジ80%以上 |
| G3 | マッピング完全性80%以上 |
| G4 | OracleによるSQL構文検証をパス |
| G5 | テスト実行カバレッジ80%以上 |
G2〜G5は最大2回リトライし、修正ガイダンスを次のプロンプトに注入する。ステップモードでは各ステージ後にレビュアーが承認・却下・差し戻しを選択できる。
規制対応のガバナンス設計
銀行として監査証跡は必須要件だ。すべてのリクエストはガバナンスコントロールプレーンを経由し、エージェント呼び出し・プロンプトバージョン・実行状態がAmazon DynamoDBに記録される。プロンプトのバージョン管理には作成者・タイムスタンプ・変更メモが紐付き、変更はデプロイなしで次回実行から反映される。
また、AgentCore Memoryによりエージェントは実行をまたいで知識を蓄積する。たとえばSQLゲートが失敗した際、OracleのエラーがSQLエージェントにフィードバックされ、その修正内容が長期メモリに保存される。以降の実行ではセマンティック検索でその教訓を引き出し、同じミスを繰り返さない。
PoC結果：作業工数が8人日→2人日に
| アプローチ | 1アーティファクトあたりの工数 |
|---|---|
| 人手のみ | 約8人日 |
| 単一エージェント | 約6人日（約1.3倍） |
| マルチエージェントパイプライン | 約2人日（約4倍） |
これはPoC段階の数値であり、プロンプト改善やツール変更など複合的な要因が含まれる点に留意が必要だ。ただし、効率向上の大部分は「LLMの導入」よりも「分解と品質ゲートの設計」によるものだと記事は指摘している。
実装上の知見：5つの教訓
記事はPoC構築から得た教訓として以下を挙げている。最初の2点は特に重要だ。単一エージェントが一定の成果を出したとしても、スケールと品質の壁はアーキテクチャの再設計でしか越えられないという点と、品質ゲートはLLMではなくコードで計算するという点は、同様のパイプラインを設計する際の根幹となる判断だ。LLMが自分の出力に高得点を付けることは今回の実運用で確認された現象であり、定量的なゲートをコードで実装することが信頼性の鍵となる。
残る3点も実装上の具体的な指針となる。ガバナンスは後付けではなく最初から設計に組み込むこと、メモリで知識を蓄積させて同じミスを繰り返さない仕組みを作ること、そしてコスト管理のためタスク複雑度に応じてモデルをルーティングすることだ。PoC時点ではほとんどのエージェントがClaude Opusを使用したが、単純な分類・整形タスクはClaude Sonnetへの切り替えを計画しているという。
なお、記事で言及されているAI-DLCプラットフォーム自体はAWSとCTBC銀行が共同で構築した内部プロトタイプであり、一般公開サービスではない。ただし、基盤となる「Supervisorと単一責任サブエージェント＋品質ゲート」のパターンは、AgentCoreとStrands Agents SDK（オープンソース）を使って再現可能だとされている。
詳細はHow CTBC Bank modernizes mainframe reverse engineering with a multi-agent pipeline on Amazon Bedrock AgentCoreを参照していただきたい。
