はじめに
IBM Bob × COBOL のハンズオンです。
AI エージェントの進化は、ビジネスのあり方を根本から変えつつあります。しかし、そのポテンシャルを最大限に引き出し、現場で実用的な価値を生み出すためには、単なるAI の試行錯誤を超えたシステム設計と統合が不可欠です。
本ハンズオンでは、COBOL のサンプルコードを題材に、IBM Bob のレガシー言語への対応力を体験します。
本記事はIBM Bobを活用して作成されています。
目的
- IBM Bob を通してCOBOL コードを読解する
- COBOL コードから仕様書を生成する
- COBOL コードから生成した仕様書を活用してJava へ変換する
ハンズオンシナリオ
架空顧客：東邦フィナンシャルシステムズ株式会社
年商3,200 億円規模の証券会社向けシステムインテグレーター。勘定系・口座管理系に大量のCOBOL バッチ処理を保有している。主力のバッチは1990 年代に作成され、開発者はほぼ退職。若手SE は誰もCOBOL コードを読んだことがない。
設定
あなたは、ワトソン株式会社のシステムエンジニアです。東邦フィナンシャルシステムズ株式会社より、口座管理系のバッジの改修依頼を受けました。
ハンズオンの流れ
| ステップ | 内容 |
|---|---|
| 事前準備 | ハンズオンに入る前にご準備いただく事項 |
| 当日確認 | ハンズオン当日に確認する事項 |
| Lab1 | ダッシュボード生成 |
| Lab2 | ソース読解/影響調査 |
| Lab3 | バグ特定/改修 |
| Lab4 | テスト自動化/移行提案 |
| Lab5 | COBOL からJava への変換 |
Github リポジトリ
COBOL のサンプルコードなど、必要なリソースが格納されています。
使用ファイル一覧
| ファイル | 説明 | 使用Lab |
|---|---|---|
order-dashboard-spec.md |
注文フロー監視ダッシュボード 要件定義書 | Lab 1 |
CBL0001.cobol |
口座台帳バッチ（基本形）- ACCT-REC を読んで印刷 | Lab 2 |
CBL0010.cobol |
財務レポートバッチ - 合計・ヘッダー付き版 | Lab 2 |
CBL0012.cobol |
バグ入りバッチ（CURRENT-DATA スペルミス） | Lab 3 |
CBL0033.cobol |
制御フロー集（GO TO / CALL / PERFORM THRU） | Lab 3 |
EMPPAY.CBL |
給与計算プログラム（ロジックバグあり） | Lab 4 |
DEPTPAY.CBL |
部門平均給与計算（表示バグあり） | Lab 4 |
emppay.cut |
zUnit テストスイート（テスト自動化の素材） | Lab 4 |
CBL0001J.jcl |
コンパイル・実行JCL | 参照用 |
事前準備
1. IBM id の作成
IBM Bob のインストールの際に必要となります。
- 作成ページ： https://www.ibm.com/account/reg/jp-ja/signup?formid=urx-19776&
- （ご参考）手順記事： https://qiita.com/Shumpei_Kubo/items/564126081dea547dd742
2. IBM Bob のインストール
ハンズオンで使用するAI コーディングエージェントです。初めてご利用される方は30日間無料で利用することができます。
- 公式ページ： https://bob.ibm.com/
- （ご参考）手順記事： https://qiita.com/Asuka_Saito/items/c0c4b83a485351bd3412
当日確認
1. Github リポジトリ上のリソースをローカルにダウンロード
ハンズオンで使用するCOBOL のサンプルコードなどのリソースをダウンロードします。
方法1: git clone（推奨）
git clone https://github.com/m-i-k-a-f/cobol-migration.git
方法2: ZIP ダウンロード
-
右上の緑色の
<> Codeボタンをクリックします。 -
Download ZIPを選択してダウンロードします。 -
ZIP を展開します。
2. IBM Bob の起動
-
IBM Bob を起動します。
-
ダウンロードしたリソースが含まれるフォルダ「cobol-migration-main」をBob 上で表示します。
i. ①Bob の左上にある「ファイル」をクリックし、②「フォルダーを開く」をクリックします。
ii. ①「cobol-migration-main」を選択し、②「開く」をクリックします。
iii. 開くと、画面左側に開いたフォルダ名が表示されます。
-
IBM Bob へのログイン
i. 「Bob にログイン」ボタンをクリックします。
ii. 許可を求められるので、「許可」をクリックします。
iii. 「開く」をクリックします。
iv. ブラウザが開くので、事前に作成いただいたIBM id でログインします。
v. ポップアップが表示されますので、「IBM Bob を開く」をクリックします。
vi. ログインに成功すると、Bob とのチャット画面が表示されます。
フォルダを開くことで、Bob がフォルダ内のすべてのファイルを認識できます。ファイルを個別に開く必要はありません。
Bob に読ませたくないファイルがある場合は、.gitignore のように.bobignore として設定することができます。
-
Bob のモードを理解
Bob では、デフォルトで3つのモードが用意されています。モード 使用タイミング AGENT コードの 作成、変更、リファクタリング が必要なときに使用します。機能の実装、バグ修正、新しいファイルの作成、または任意のプログラミング言語やフレームワークでのコード改善に最適です。 PLAN 実装前に 計画、設計、または戦略立案 が必要なときに使用します。複雑な問題の分解、技術仕様の作成、システムアーキテクチャの設計、またはコーディング前のソリューションのブレインストーミングに最適です。 ASK 説明、ドキュメント、または技術的な質問 への回答が必要なときに使用します。概念の理解、既存コードの分析、推奨事項の取得、または変更なしに技術を学ぶのに最適です。 -
疎通確認プロンプトを実行する
以下を ASK モードで実行し、Bob が正常に応答することを確認してください。COBOLのFD句（ファイル定義）とは何ですか？1〜2文で教えてください。「FD（File Description）は…」という応答が返ればOK です。
Lab 1
仕様書から注文監視ダッシュボードを生成しよう
背景ストーリー
東邦フィナンシャルの運用チームから「株式注文の処理状況をリアルタイムで把握できる監視画面が欲しい」という要望が来ました。要件定義書は既にあります（order-dashboard-spec.md）。
あなたの仕事は「PoC として動くUI を今日中に作ること」です。このLab ではCOBOL は関係ありません。Bob に丸投げしてみましょう。
ハンズオンパート
1-1. 仕様書の中身を自分で読む
order-dashboard-spec.md を開き、以下の3点を確認してください。
- 表示すべきKPI は何か（セクション2-1）
- グラフは何種類あるか（セクション2-2・2-3）
- 技術制約は何か（セクション5）— ここがポイント
技術制約の「単一HTML で完結、CDN・外部URL への参照禁止」を覚えておいてください。
Bob がこれを守るか確認します。
1-2. Bob に仕様書を読ませて設計方針を出させる
いきなり実装させる前に、PLAN モードで「設計の相談」から入ります。
【PLAN】設計方針の確認
order-dashboard-spec.mdを読んで、実装前に以下を整理してください。
1. 表示すべき指標・グラフの一覧（仕様書から抜き出す）
2. 「CDN・外部URL禁止・単一HTMLで完結」という制約を守るために、グラフをどう実装するか（ライブラリ選定の方針）
3. ダミーデータの設計方針（件数847件の内訳、銘柄10種の選定、異常検知トリガーの組み込み方）
4. HTMLのレイアウト構成（どのエリアをどう配置するか）
5. 実装上のリスクや注意点
実装はまだしないでください。設計の相談だけです。
Bob から選択肢が提示された場合
設計提案の後、Bob が次のような確認を求めてくることがあります。どの選択肢を選んでも構いません。 自分が「よさそう」と思ったものを選んでください。
Bob からの確認メッセージの例（イメージ）：
設計の方向性はこれで概ね固まっています。進める前に確認させてください。
- ステータスグラフをパイチャートではなく横棒グラフ（バーチャート）に統一する
- 仕様書どおりパイチャートで実装し、銘柄別ランキングと合わせて左右2 カラム配置にする
- 設計はこのままで問題ない。実装計画（plan.md）を作成してほしい
- 異常検知の「直近1 時間」は30 分スロット2 つの合算で比較する形に変更したい
やってみると良いこと：
- 自分の好みの選択肢を選んで、Bob がどう動くか確認する
- 「3 番を選択します」のように番号で返答してもOK
- 複数選択して「①と④を組み合わせてほしい」と伝えても構わない
ポイント：
- 選択肢が出ること自体が「Bob が自分で考えた」証拠
- あなたの選択がそのまま実装に反映される
- 「やっぱり変えたい」と後から言っても大丈夫
選択肢を選んだら、Step 1-3 で AGENT モードに切り替えて実装に進みます。
1-3. AGENT モードに切り替えて実装させる
設計方針が固まったら AGENT モードに切り替えて、一気に実装させます。
【AGENT】ダッシュボード実装
order-dashboard-spec.mdの要件定義書に基づいて、株式注文フロー監視ダッシュボードを実装してください。
【必須要件（仕様書のまま守ること）】
- 単一HTMLファイルで完結（外部CDN・外部URL参照禁止）
- グラフはSVGで自前描画
- ダークテーマ（証券端末らしい黒〜濃紺背景）
- 数値のカウントアップアニメーション（0から最終値へ）
- ダミーデータはJavaScript内に埋め込み
【表示内容】
- ヘッダー：注文件数合計847件・約定件数/約定率・未約定件数・取消件数
- 注文ステータス円グラフ（受付中/約定済/一部約定/取消済/エラー）
- 銘柄別注文ランキング上位10（横棒グラフ、日本の実在銘柄）
- 時間帯別注文件数折れ線グラフ（09:00〜15:30、30分刻み、買い/売り/取消の3系列）
- 異常検知アラート（13:00〜13:30急増で黄色、エラー7件で赤）
- 直近20件の注文明細テーブル
出力ファイル名：order-dashboard.html
⏳ Bob による生成に数分かかる場合があります。生成が終わったら、次のステップへ進んでください。
1-4. 生成されたダッシュボードを確認する
Bob が生成した order-dashboard.html をブラウザで開きます。
ブラウザでの開き方
-
①作成したhtml ファイルを右クリックし、②「パスのコピー」をクリックします。
-
コピーしたパスをアドレスバーにペーストし、Enter を押します。
ダッシュボードの仕上がり例
受け入れ基準（仕様書セクション6）が守られているか確認してください。
| 確認ポイント | 内容 |
|---|---|
| 制約遵守 | 外部CDN への参照がないか。ファイルが1つだけか。 |
| 異常検知 | 13:00〜13:30 が黄色ハイライト、エラーアラートが赤表示されているか。 |
不満な点やカスタマイズしたい箇所があれば、そのままBob に追加指示を出してみてください。
【AGENT】修正依頼の例
order-dashboard.htmlを修正してください。
- 銘柄別ランキングの棒グラフに、買い注文（青）と売り注文（赤）を色分けして表示してほしい
- ヘッダーの約定率をより大きく目立つように表示してほしい
1-5. 仕様書との差分をレポートさせる
実装後に ASK モードで「仕様書と実装の差分確認」をします。
【ASK】受け入れ基準チェック
order-dashboard-spec.mdの「6. 受け入れ基準」と、生成したorder-dashboard.htmlを照合してください。
各チェック項目について：
- ✅ 実装済み
- ⚠️ 一部実装（どこが不足か）
- ❌ 未実装
の3段階で評価してください。
✅ Lab 1 ふりかえり
- PLAN→AGENT の2段階： Bob はPLAN で設計方針を自分で提案し、AGENT で実装まで走りました。「相談→実装」を1つのツールで完結させることができます。
- 仕様書を渡すだけで動いた： プログラミング知識ゼロでもSVG グラフ・カウントアップアニメーション・異常検知ロジックを実装することができました。
- ASK で確認できる： 実装後にASK モードで「仕様書との差分」を確認することができました。設計・実装・検証をBob だけで完結させることができます。
- 修正も自然言語で： コードを直接触らず、「こうしてほしい」という言葉だけで修正することができました。
Lab 2
ソース読解と影響調査
背景ストーリー
東邦フィナンシャルから「口座台帳バッチに CREDIT-SCORE（信用スコア）フィールドを追加 してほしい」との依頼が来ました。まず既存の口座レコード構造と処理フローを把握する必要があります。Lab 1 で作ったダッシュボードに、いつかこのデータを流し込むことになります。
ハンズオンパート
2-1. まず自分でソースを読んでみる
ダウンロードした CBL0001.cobol を開き、以下の3点を自分なりに読み取ってみてください。
- このプログラムは何をしているか（1文で）
- ACCT-REC にはどんなフィールドがあるか
- メインループはどこか（段落名と行番号）
わからなくてもOK です。次のステップでBob に解説してもらいます。
2-2. グラフィカル仕様書を成果物として生成させる
テキストで「説明させる」だけでなく、ブラウザで開けるHTML 仕様書を1 ファイルで出力させます。Bob が生成した成果物をそのまま設計ドキュメントとして使えるかを確認します。
成果物の要件を先に「仕様」として渡すのがポイントです。何を図示してほしいか・どんな形式で出すかをBob に明示することで、ドキュメント生成の精度が上がります。
【AGENT】グラフィカル仕様書 生成
CBL0001.cobolを読み込み、以下の仕様を満たすHTML仕様書ファイルを1つ生成してください。
ファイル名：cbl0001-spec.html
【仕様書に含めること】
■ セクション 1 — プログラム概要カード
- プログラムID・作成者・目的（1〜2文）をカード形式で表示
■ セクション 2 — レコードレイアウト図（SVG）
ACCT-REC（入力）とPRINT-REC（出力）それぞれについて、
フィールドを横に並べたバイトレイアウト図をSVGで描画してください。
各フィールドの幅をバイト数に比例させ、フィールド名・PIC 句・バイト数を図中に表示すること。
COMP-3フィールドは異なる色で強調すること。
■ セクション 3 — 処理フロー図（SVG）
PROCEDURE DIVISIONの段落（OPEN-FILES → READ-NEXT-RECORD → CLOSE-STOPなど）を
フローチャート形式のSVGで描画してください。
ループ（PERFORM UNTIL）は矢印で折り返す形で表現すること。
■ セクション 4 — 入出力フィールドマッピング表
WRITE-RECORD段落のMOVE文をもとに、
入力フィールド（ACCT-REC 側）と出力フィールド（PRINT-REC 側）の対応を表形式で示すこと。
【デザイン要件】
- 外部CDN・外部ファイル参照なし（単一HTMLで完結）
- ダークテーマ（背景#0a0e1a系）
- 日本語テキストは読みやすいゴシック体、数値・コードはモノスペース
生成されたhtml ファイルをブラウザで開いて、以下を確認してください。
-
レコードレイアウト図でバイト数が視覚的に比較できるか
出力例
-
COMP-3 フィールドが色で区別されているか
-
マッピング表でMOVE 文の対応関係がひと目でわかるか
出力例
-
フローチャートでループの流れが読み取れるか
出力例
2-3. 影響調査：フィールド追加の影響範囲を特定する
本番業務でよく発生する「フィールド追加依頼」をBob に影響調査させます。
【PLAN】影響調査
CBL0001.cobolのACCT-RECに「CREDIT-SCORE PIC 9(3)」フィールドを追加する改修を検討しています。
以下の観点で影響範囲を調査してください。
1. ACCT-FIELDSグループ内のどこに追加すべきか（RESERVEDフィールドへの影響を確認）
2. PRINT-REC出力側への影響（PRINT-RECに同フィールドを追加する必要があるか）
3. PROCEDURE DIVISIONで変更が必要な段落と、その理由
4. レコード長（170バイト）への影響（現在の合計バイト数を計算して検証）
5. JCL（CBL0001J.jcl）側で必要な変更はあるか
PLAN モードは実装前に方針を固める段階に使います。ここで「何を変えるか」を明確にしてからAGENT モードで実装します。
出力例
2-4. CBL0010 との差分・進化点を分析する
同じくダウンロードした CBL0010.cobol との差分をBobに出力させます。
【AGENT】バージョン比較
CBL0001.cobolとCBL0010.cobolを比較して、以下を日本語で説明してください。
1. CBL0010で追加された機能（CBL0001にはなかったもの）
2. WORKING-STORAGEの差分（新しく追加された変数・構造）
3. PROCEDURE DIVISIONの処理フローの違い
4. CBL0010の方が「より本番に近い」と言える理由
最後に：この2つのプログラムのアーキテクチャパターン名を挙げて、証券会社の実業務でどのような処理に対応するか説明してください。
出力例
✅ Lab 2 ふりかえり
- ASK/PLAN で読解・調査が即完結： COBOL ソースを開いて「何をしているか」をBob に聞くだけで、データ構造・処理フロー・バイト数計算まで即答できました。自分で追うのに数十分かかる読解が大幅に短縮されます。
-
成果物として仕様書が生まれた： AGENT でHTML 仕様書の「要件」を渡すだけで、SVG レコードレイアウト図・フローチャート・マッピング表を含む
cbl0001-spec.htmlが1 ファイルで生成されました。説明させるだけでなく「ドキュメントを作らせる」使い方が実践できました。 - 影響調査もPLAN で投げるだけ： フィールド追加という典型的な改修依頼もPLAN モードで投げると、レコード長への影響・出力側の変更箇所・JCL への波及まで一度に洗い出すことができました。設計者が手作業で行ってきた調査工数が劇的に変わることを体感できました。
Lab 3
バグ特定と改修
背景ストーリー
上司から「このバッチ、コンパイルエラーになってるらしいんだけど、何が悪いか見てくれる？」と言われました。ソースは CBL0012.cobol です。COBOL のエラーメッセージは読みにくいです。
ハンズオンパート
3-1. 自分でバグを探す
CBL0012.cobol を開き、CBL0010.cobol と見比べながら「何かおかしい」点を探してみてください。
ヒント：WRITE-HEADERS 段落の1行目をよく見てください。
3-2. Bob にバグを検出させる
【AGENT】バグ検出
CBL0012.cobolをコードレビューして、以下を出力してください。
1. コンパイルエラーになる可能性のある箇所をすべて列挙
- 行番号
- 問題のコード（引用）
- エラーの種類（スペルミス / 型不一致 / 未定義参照 / その他）
- 正しいコード
2. 実行時エラー（ランタイムエラー）になる可能性のある箇所
3. 論理エラー（動くが意図と異なる結果になる）の可能性
4. CBL0010.cobolと比較して「削除されているが必要な変数・構造」があれば指摘
問題の深刻度を「高（コンパイル不可）」「中（実行時エラー）」「低（論理ミス）」で分類してください。
出力例
3-3. 修正コードを生成させる
【AGENT】バグ修正
CBL0012.cobolの検出したバグをすべて修正して、修正済みのコードを出力してください。
修正にあたって：
- CBL0010.cobolと同等の機能（当日日付表示・ヘッダー印刷・TRAILER行）を持つこと
- WS-CURRENT-TIME（時・分・秒・センチ秒）もCBL0010と同様に定義すること
- コメント（*で始まる行）は保持すること
- 修正箇所には「* FIXED:」コメントを付けること
出力例
3-4. CBL0033 の制御フローを分析する（発展）
実務のCOBOL によく登場する複雑な制御フローを理解します。
【AGENT】制御フロー分析
CBL0033.cobolを読んで、以下を解説してください。
1. このプログラムが実行する処理の順序を、段落名を使って疑似フローチャートで表現する
2. GO TO 2100-READ-TEN-RECORDSの効果（どの段落がスキップされるか）
3. PERFORM 10 TIMESとPERFORM VARYING COUNTER FROM 1 BY 1 UNTILの違いと使い分け
4. PERFORM 4000-READ-RECORD THRU 5000-WRITE-RECORDの意味と使用上の注意点
5. CALL 'HELLO'の意味（静的リンクと動的リンク、この場合はどちらか）
証券会社のバッチ処理でこのようなGO TOやPERFORM THRUを使った古いコードを保守する際の注意点も2点挙げてください。
出力例
✅ Lab 3 答え合わせ — CBL0012 の仕込まれたバグ
| 行番号 | 問題のコード | 正しいコード | 深刻度 |
|---|---|---|---|
| 118 | FUNCTION CURRENT-DATA |
FUNCTION CURRENT-DATE |
高（コンパイル不可） |
| 104〜108 |
WS-CURRENT-DATE（時刻定義なし） |
WS-CURRENT-TIMEの 時・分・秒・センチ秒を追加 | 中（将来の機能追加時に問題） |
| 163 | LAST-NAMEがコメントアウト | MOVE LAST-NAME TO LAST-NAME-O を有効化 | 中（出力に姓が表示されない） |
CBL0033 のポイント：GO TO の後のコード（DISPLAY文）は到達不能コードになっています。実務ではこのような「死んだコード」が保守コストを増大させています。
✅ Lab 3 ふりかえり
- バグ検出はBob に任せるほうが網羅的： 自分で読んでも気づきにくいスペルミス（CURRENT-DATA）・コメントアウトによる出力欠落・定義漏れを、Bob はコード全体を横断して深刻度付きで一覧化できました。「見落とし」が起きにくくなります。
- 修正コードもそのまま生成： バグ特定だけでなく、修正済みの正しいコードをAGENT モードで出させれば即座にパッチが得られました。検出→修正→レビューの流れをBob だけで完結できます。
- 「死んだコード」も指摘できる： CBL0033 のGO TO 後の到達不能コードのように、コンパイルは通るが実行されない問題もBob は指摘することができました。実務で保守コストを増大させるコード品質の問題を、静的解析的な視点で洗い出すことができます。
Lab 4
テスト自動化と移行提案
背景ストーリー
お客様から「COBOL をモダナイズしたい。まず テストを整備 してほしい」と言われました。既存のzUnit テストファイル（emppay.cut）がありますが、カバレッジが不十分です。またEMPPAY.CBL 自体にも論理的なバグが疑われます。
ハンズオンパート
4-1. EMPPAY のロジックを読み解く
【AGENT】ロジック分析
EMPPAY.CBLを読んで、以下を解析してください。
1. PAYMENT-WEEKLY段落の処理ロジックを日本語で説明（IF分岐の条件と結果を表で）
2. 以下の入力でEMP-PAY-WEEKとEMP-OT-RATEが何になるか計算して確認：
- ケースA: EMP-HOURS=19, EMP-HOURLY-RATE=23.50
- ケースB: EMP-HOURS=40, EMP-HOURLY-RATE=23.50
- ケースC: EMP-HOURS=50, EMP-HOURLY-RATE=23.50
- ケースD: EMP-HOURS=60, EMP-HOURLY-RATE=23.50
3. PAYMENT-WEEKLYのIF文に論理的なバグがあります。具体的にどのケースで問題が起きるか指摘してください。
4. バグの修正案を提示してください。
ケースC（50 時間）のEMP-OT-RATE に注目してください。IF の条件順序が問題を引き起こしています。
出力例
4-2. 既存テストの問題点を分析する
【AGENT】テスト品質レビュー
emppay.cut（zUnitテストファイル）を読んで、以下を分析してください。
1. 現在のテストケースが何を検証しているか（1行ずつ）
2. 現在のテストでカバーできていない境界値・ケースを列挙
3. EMPPAY.CBLに存在するロジックバグ（IF条件順序の問題）が現在のテストで検出できるか？できない場合、なぜか？
4. このテストスイートの「テストカバレッジ」を0〜100%で評価し、その根拠を述べてください。
出力例
4-3. 追加テストケースを生成する
【AGENT】テスト生成
emppay.cutに追加するテストケースをzUnit形式（.cut）で生成してください。
追加するケース：
1. EMP-HOURS=50の場合、EMP-OT-RATEが0.50になることを検証する（現在のバグを露わにするテスト）
2. EMP-HOURS=39の境界値テスト（残業なし）
3. EMP-HOURS=0のエッジケース
4. PAYMENT-MONTHLYでEMP-HOURS=160の場合の報酬率（EMP-REWARD=0.50）確認
5. DEPTPAY.CBLのDISPLAY-DETAILS段落のMANAGER-LNAME表示バグを検出するテスト
形式は既存のemppay.cutに倣ってください。TestSuite / TestCase / PERFORM / EXPECT を使った zUnit 形式で。
出力例
4-4. 移行提案書のドラフトを作る
今日の調査結果をもとに、お客様向けの提案書ドラフトをBob に作らせます。
【AGENT】移行提案書ドラフト
今日分析したCOBOLプログラム群（CBL0001, CBL0010, CBL0012, CBL0033, EMPPAY, DEPTPAY）をもとに、証券会社の運用チームSEが上司へ提出する「COBOLモダナイゼーション 初期調査報告書」をMarkdown形式で作成してください。
含める内容：
1. 調査対象プログラムの概要（表形式：プログラム名・機能・問題の有無）
2. 発見されたバグ・リスクの一覧（深刻度付き）
3. 推奨する次のアクション（優先度順に3〜5件）
4. IBM Bobを活用したモダナイゼーションの進め方（フェーズ分け）
5. 影響調査・改修・テスト整備にかかる工数の概算コメント（数字は仮）
想定読者はIT部門の部長クラス。専門用語を使いつつも、COBOLの深い知識がなくても読めるように。
出力例
✅ Lab 4 答え合わせ
| 発見事項 | ファイル | 深刻度 |
|---|---|---|
| IF 条件順序バグ：EMP-HOURS=50 でOT-RATE が0.25 になる（正しくは0.50） | EMPPAY.CBL:32-37 | 高 |
| DISPLAY-DETAILS のMANAGER-LNAME がMANAGER-FNAME と同じ変数を表示している | DEPTPAY.CBL:33 | 中 |
| 既存テストはバグを検出できない（EMP-HOURS=50 のテストがOT-RATE=0.25 を期待している） | emppay.cut:3-7 | 中 |
| テストカバレッジ：PAYMENT-MONTHLY の全分岐・エッジケースが未カバー | emppay.cut | 低 |
EMPPAY のIF 文バグ： IF EMP-HOURS >= 40 が先に評価されるため、50 時間勤務でも最初の条件にマッチして0.25 が設定されています。正しくは >=50 を先に評価すべきです。
✅ Lab 4 ふりかえり
- ロジックバグは条件式の順序まで追える： IF EMP-HOURS >= 40 が先に評価されるため50 時間勤務でも誤った残業率が設定されるバグを、Bob は条件分岐の評価順序レベルで説明・特定することができました。人間が見落としやすい「動くが間違っている」系のバグにBob は強いです。
- 既存テストの穴も指摘できる： emppay.cut がバグを検出できない理由（テスト自体が誤った期待値を持っている）まで分析でき、「テストが通っているから正しい」という思い込みを崩す追加テストケースを生成することができました。
- バグ修正から移行提案書まで一気通貫： 個別バグの修正にとどまらず、発見した問題点をインプットに「Java/Python への移行提案書ドラフト」までBob に出力させることができました。コード調査→品質評価→移行判断というモダナイゼーションの一連の流れをBob だけで完走できることを体感できました。
Lab 5
COBOL からJava への変換
背景ストーリー
東邦フィナンシャルから「口座台帳バッチを Java に移植 してクラウドで動かしたい」との依頼が届きました。Lab 2-2 で生成したグラフィカル仕様書（cbl0001-spec.html）がすでに手元にあるので、これを設計ドキュメントとして活用し、Bob にJava への変換を任せましょう。
ハンズオンパート
5-1. 仕様書を確認してゴールを明確にする
Lab 2-2 で生成した cbl0001-spec.html をブラウザで開き、以下を確認します。
- レコードレイアウト図 — ACCT-REC の各フィールド名・型・バイト数
- 処理フロー図 — OPEN → READ LOOP → WRITE → CLOSE の流れ
- 入出力マッピング表 — MOVE 文で何が何に対応しているか
仕様書を「確認する人間の目」として使うことで、Bob が生成したJava コードの正確性をその場で照合できます。仕様書が先にあることが品質保証の出発点です。
5-2. COBOL のデータ構造をJava のクラスに変換させる
まずACCT-REC レコード（入力）とPRINT-REC レコード（出力）のデータ構造をJava のPOJO（Plain Old Java Object）として変換させます。
【AGENT】データ構造変換
CBL0001.cobolのDATA DIVISIONを読み、以下の2つのJavaクラスを生成してください。
ファイルはsrc/main/java/com/tohofinancial/batch/ディレクトリに作成すること。
■ クラス1：AccountRecord.java
- ACCT-FIELDS（FD ACCT-REC）に対応するフィールドをすべて定義する
- フィールド名はキャメルケースに変換（例：ACCT-NO → acctNo）
- COMP-3（パック10進数）のS9(7)V99はBigDecimalに変換する
- CLIENT-ADDRのような入れ子グループは内部クラスClientAddressとして定義する
- 全フィールドにgetter / setterを付けること
■ クラス2：PrintRecord.java
- PRINT-RECに対応するフィールドをすべて定義する
- PIC $$,$$$,$$9.99のような編集書式フィールドはString型にする
- 全フィールドにgetter / setterを付けること
【追加要件】
- 各クラスのJavadocにCOBOLの元のフィールド名とPIC句をコメントとして記載する
- Java 17以上を対象とすること
COMP-3（パック10進数）はCOBOL 特有のバイナリ形式です。Java では BigDecimal が等価物になります。仕様書のレコードレイアウト図と照合して、フィールドの数・名前が一致しているか確認してください。
出力例
5-3. メインの処理ロジックを変換させる
次にPROCEDURE DIVISION（処理本体）をJava のサービスクラスに変換します。
【AGENT】処理ロジック変換
CBL0001.cobolのPROCEDURE DIVISIONを読み、以下のJavaクラスを生成してください。
ファイル：src/main/java/com/tohofinancial/batch/AccountBatchService.java
【変換ルール】
1. OPEN-FILES段落 → コンストラクタまたはinit()メソッドに対応させる
2. READ-NEXT-RECORD段落 → processAll()メソッドに変換する（メインのループ処理）
3. CLOSE-STOP段落 → close()またはtry-with-resourcesで対応させる
4. READ-RECORD段落 → readNextRecord()プライベートメソッドに変換する
5. WRITE-RECORD段落 → writeRecord(AccountRecord input)プライベートメソッドに変換する
【入出力の扱い】
- 入力ファイル読み取りはjava.io.BufferedReaderを使った行単位読み込みで実装する
- 出力はjava.io.PrintWriterを使う
- LASTRECフラグに相当するループ終了判定はhasNext()パターンに置き換える
【追加要件】
- 各メソッドのJavadocに対応するCOBOL段落名を記載する
- IOExceptionはメソッドシグネチャで宣言（throws）する
- ファイルパスはコンストラクタ引数で受け取る
COBOL の「段落（paragraph）」はJava のメソッドに対応します。PERFORM は this.methodName() の呼び出し、PERFORM UNTIL は while (!done) ループと読み替えてください。
出力例
5-4. 変換結果を仕様書と照合させる（品質確認）
生成したJava コードが仕様書どおりかをBob に自己確認させます。
【AGENT】変換品質チェック
生成したAccountRecord.java、PrintRecord.java、AccountBatchService.javaとCBL0001.cobolの仕様を照合して、以下を確認してください。
1. フィールド対応チェック
- AccountRecordのフィールド数がACCT-FIELDSの定義数と一致しているか
- PrintRecordのフィールド数がPRINT-RECの定義数と一致しているか
- CLIENT-ADDR（入れ子）がClientAddress内部クラスとして正しく表現されているか
2. ロジック対応チェック
- WRITE-RECORD段落のMOVE文6件がwriteRecord()メソッドの代入処理に対応しているか
- PERFORM UNTIL LASTREC = 'Y'のループがprocessAll()で正しく再現されているか
3. 型変換チェック
- PIC S9(7)V99 COMP-3がBigDecimalに変換されているか
- PIC X(n)がStringに変換されているか
差異があれば指摘して、修正コードを提示してください。
出力例
5-5. ユニットテストを生成させる
変換したJava コードの動作を検証するユニットテストを生成させます。
【AGENT】Javaユニットテスト生成
AccountBatchServiceの変換ロジックを検証するJUnit 5テストクラスを生成してください。
ファイル：src/test/java/com/tohofinancial/batch/AccountBatchServiceTest.java
【テストケース】
1. 正常系：1件のAccountRecordをwriteRecord()に渡すと、
対応するPrintRecordの全フィールドが正しく設定されること
- 入力例：acctNo="12345678", acctLimit=10000.00, acctBalance=5000.00, lastName="田中", firstName="太郎", comments="優良顧客"
2. MOVE対応チェック：writeRecord()がAccountRecordの6フィールドをPrintRecordに正しくコピーしていること（各フィールドをassertEqualsで検証）
3. ループ終了：空のファイルを入力にしたときprocessAll()が正常終了すること（例外なし）
4. BigDecimal精度：acctLimit=1234567.89がBigDecimalに変換されたときtoPlainString()が"1234567.89"を返すこと
【形式要件】
- JUnit 5（@Test, @BeforeEach）を使うこと
- Mockitoは使わず、直接インスタンスを生成してテストすること
- テストメソッド名は日本語で記述してよい（@DisplayNameを活用）
COBOL のzUnit テスト（Lab 4 で扱った emppay.cut）とJava のJUnit テストは、「段落単体を検証する」という発想は同じです。変換後も同様の品質基準で守ることを確認しましょう。
出力例
5-6. 移行時の注意点・未変換事項をまとめさせる（発展）
【PLAN】移行残課題レポート
CBL0001.cobolをJavaに変換した際に、今回の変換で省略または単純化した点を以下の観点でまとめてください。
1. COMP-3（パック10進数）の完全な再現
- 実際のz/OSバイナリファイルをJavaから読む場合に必要な処理
- 固定長バイナリレコードのバイト列解析（java.nio.ByteBufferなど）
2. JCL（ジョブ制御言語）の代替
- CBL0001J.jclで定義しているDD名・データセット名をJavaからどう扱うか（環境変数・設定ファイルへの置き換え）
3. RECORDING MODE F（固定長レコード）の扱い
- 170バイト固定長レコードをJavaで読む際の実装方針
4. クラウド移行時の追加考慮事項
- ファイル入出力 → オブジェクトストレージ (S3 / COS)への置き換え方針
- バッチ実行 → Spring Batch / IBM StreamsなどのJavaバッチフレームワーク活用
この内容を「移行残課題リスト」としてMarkdown表で出力してください。
出力例
✅ Lab 5 答え合わせ
| 変換対象 | COBOL | Java | 備考 |
|---|---|---|---|
| ACCT-NO PIC X(8) | 文字列フィールド | String acctNo |
8 文字固定 |
| ACCT-LIMIT S9(7)V99 COMP-3 | パック10 進数 | BigDecimal acctLimit |
精度9, スケール2 |
| ACCT-BALANCE S9(7)V99 COMP-3 | パック10 進数 | BigDecimal acctBalance |
同上 |
| LAST-NAME / FIRST-NAME PIC X(n) | 文字列 | String lastName / firstName |
末尾スペース除去に注意 |
| CLIENT-ADDR（グループ項目） | ネスト構造 | 内部クラス ClientAddress
|
streetAddr, cityCounty, usaState
|
| RESERVED PIC X(7) | パディング領域 | String reserved |
通常は使用しない |
| PERFORM UNTIL LASTREC='Y' | ループ制御フラグ | while (line != null) |
BufferedReader のnull 判定に置換 |
| OPEN/CLOSE 段落 | ファイル開閉 | try-with-resources | IOException を明示的にハンドル |
今回の変換はテキストファイルベースの単純変換です。実際のz/OS 環境ではACCT-REC が固定長バイナリ（COMP-3 フィールド含む）のため、本番移行では java.nio.ByteBuffer を使ったバイト列解析が必要になります。
✅ Lab 5 ふりかえり
-
仕様書が変換の起点になった：
cbl0001-spec.htmlを確認してからプロンプトを書いたことで、フィールド数や型の間違いをその場で照合することができました。「作る前に読む」習慣が変換品質を上げます。 - COBOL の概念がJava に1 対1 で写った： 段落→メソッド、PERFORM →メソッド呼び出し、PERFORM UNTIL →while ループ、OPEN/CLOSE →try-with-resources と、対応関係が明確でした。COBOL の構造を知らなくても、Bob の説明を読みながら対応表を確認すれば追跡することができます。
-
型変換の判断はBob に任せられる：
PIC S9(7)V99 COMP-3→BigDecimal、グループ項目 → 内部クラスのように、COBOL 固有の型知識がなくてもBob が適切なJava 型を選びました。ただし 答え合わせ表で精度を確認する一手間 が品質保証になります。 - 変換＝完成ではない： 5-6 の残課題レポートが示すとおり、固定長バイナリ・JCL 置き換え・クラウド対応は今回の変換では省略されています。「何が変換されて何が残っているか」をBob に明示させることが、次フェーズの計画立案につながります。
まとめ
今日Bob が実施したこと
| Lab | テーマ | 内容 |
|---|---|---|
| Lab 1 | 仕様書→実装 | 要件定義書から証券ダッシュボードを自律的に生成。PLAN→AGENT の2 段階。 |
| Lab 2〜3 | 読む・直す | COBOL の構造解析・影響調査・バグ特定・修正コード生成。 |
| Lab 4 | 守る・移す | テストカバレッジ分析・追加テスト生成・移行提案書まで一気に出力。 |
| Lab 5 | 変換する | 仕様書を起点にCOBOL→Java 変換。データ構造・処理ロジック・ユニットテストまで生成。 |
Bob を使ったCOBOL モダナイゼーションの4 つの構造
- フェーズ0：作る（仕様書→設計→実装をBob が自律実施）
- フェーズ1：読む（ソース読解・影響調査・ドキュメント生成）
- フェーズ2：直す（バグ検出・修正コード生成・レビュー）
- フェーズ3：守る（テスト整備・リグレッション防止）
- 将来：移す（Java/Python 変換・API 化）
COBOL を「知っている人」がいなくなっても、「問いを立てられる人」 がいれば、Bob は動く。