ブロックCRUDをどう育てるか——AIと人間が往復する設計の実際｜第3話

前回の話で、ブロックCRUDとは何か、なぜ必要なのかを書いた。

今回は「作ったあと、どう育てるか」の話をする。

一度作っただけでは、荒削りなまま

100を超える処理工程（ステップ）が連なる巨大な夜間バッチを相手にするとき、AIに大量の資料を一度に読み込ませると、後半の品質が落ちる。これはすでに経験済みだ。

だから「育てる」という発想が必要になる。AIが草案を作り、人間が補正し、またAIに問いかける。その往復の中で、ブロックCRUDはだんだん本物になっていく。

ただし往復を始める前に、必ず固めておくべきことがある。

3つの言葉の違いを固める

レガシーを知っているベテランと話すとき、AIに説明するとき、設計者と議論するとき——どの場面でも「中間」「ワーク」「履歴」の3つの言葉は必ず混乱を生む。ここが曖昧なまま進めると、表の精度は上がらない。

「中間」と「ワーク」はどう違うか

たとえば、夜間バッチの途中で「請求対象の候補リスト」というファイルを作ったとする。

このファイルが「請求対象として扱う候補を選んだ」という業務上の意味を持つなら、それは中間だ。業務の状態が一歩前に進んだことを記録している。

一方で、処理の都合でデータを並び替えただけ、あるいは次の計算のために一時的に形を変えただけなら、それはワークだ。業務的な意味はなく、処理が終われば用済みになる。

迷ったときの判断の目安はこうなる。

後続の処理がそのデータを「業務の結果」として読むなら中間。消して作り直しても業務判断に影響しないなら、ワーク。障害が起きたとき、そのファイルが残っていたら確認が必要になるなら、中間寄りだ。

「履歴」は別物として扱う

消込処理（請求と入金を突き合わせて帳消しにする処理）を例にすると、3つの区別はこうなる。

正本は、今現在の債権残高だ。処理のたびに書き換えられる。
履歴は、いつ、どの入金で、どの請求を消し込んだか、という過去の記録だ。消してはいけない。
中間は、今回の消込処理のために一時的に作った候補ファイルだ。処理が終われば役目を終える。

この3つを混同すると、システム移行後の設計で深刻な問題が起きる。

履歴を中間と間違えると「消して作り直せる」と誤解される。中間を履歴と間違えると、消してはいけないデータとして扱われ、不要なデータが永続的に積み上がる。正本と履歴を混同すると、更新すべきところに追記が、追記すべきところに上書きが走り、データの整合性が崩れる。

この3つの区別は、早い段階で固めるべきだ。

AIとの往復——4回の機会

ブロックCRUDは、以下の4つのタイミングで人間とAIが往復しながら育てていく。

1回目は、ブロックCRUDを最初に作るとき。
JCLやプログラムの情報、人間のメモをもとにAIが草案を作る。ただしAIが出してくる草案には、必ず人間が補正を入れる。業務的な意味の判定、「これが正式なデータか」という判断、やり直しがきくかどうかの確認は、資料を読んだだけではわからない。ここは人間の仕事だ。

2回目は、処理のまとまりを設計するとき。
ブロックCRUDをもとに、処理のかたまり（ブロック）の設計を作る。AIに「粒度がそろっているか、矛盾はないか、抜け漏れはないか」を確認させる。

3回目は、新しいシステムへの対応表を作るとき。
レガシーの処理ステップを、移行先の新しいシステム（ここではSpring Batchという技術）の構造に写し替える。AIに構成案を出させ、人間が「やり直しがきくか」「正式なデータへの更新は正しいか」を確認する。

4回目は、コードが生成されたあと。
AIが書いたコードを、ブロックCRUD・処理設計・再実行の設計・テスト観点表と照合する。コードだけを読んで正しいと判断してはいけない。これが最も重要な原則だ。

抜け漏れを早めに炙り出す——テスト観点案

育てる作業と並行して、「テスト観点案」を要件定義の段階で一度作っておくことを勧めたい。

テスト観点案は、テスト項目そのものではない。「何を確認すべきか」を人間とAIで前もって合意するための資料だ。これを早めに作ることで、ブロックCRUDの設計漏れが浮かび上がってくる。

AIへの依頼はこう書く。

「ブロックCRUDと処理設計をもとに、この処理のかたまりごとに確認すべきテスト観点を一覧にしてください。正常に動く場合、入力が欠けている場合、マスタデータに一致しない場合、同じデータが重複した場合、境界値、やり直し処理、締め処理後、異常終了時、状態の遷移、帳票とログの確認、に分けてください。判断できない点は未確認事項として出してください。」

返ってくる観点の表は、テスト設計の見出しになる。テスト項目はここから人間が書く。

人間とAIの役割

4回の往復を通じて、役割の基本は変わらない。

AIは草案を作り、粒度を揃え、矛盾を指摘し、構成案を出す。

人間は、正式なデータかどうかの判定、業務的な意味づけ、やり直し設計、締め処理の確認、運用判断を担う。

前回の話で書いた「AIには渡せない判断がある」は、4回の往復を経ても変わらない。

最後に——コードは最後だ

この工程を経ると、最終的に以下の成果物が揃っていく。

JCLステップ単位の詳細、ブロックCRUD、処理ブロック設計書、データ責務と正本の定義、状態遷移設計書、再実行と異常時の設計書、新システムへの対応表、テスト観点表、未確認事項と判断のログ、そしてAIへのコード生成指示書。

指示書が最後に来ることに注目してほしい。

コードは最後だ。その前に、これだけの地図を人間とAIで共同で作り上げる。それが、巨大なレガシーバッチと向き合うときの、今のところ一番まともなやり方だと思っている。