ハルシネーションには法則がある “COBOL変換”で「AIが自信満々に間違える」場所とその理由：2035年へのレガシーモダナイゼーション実務論（5）（1/2 ページ）

AIによるレガシーシステムの刷新で懸念されるハルシネーションだが、AIが誤りを起こしやすい場所には一定の傾向がある。実際にあった例を基に、AIがもっともらしい間違いを犯す原因と対策を解説する。

[中野恭秀（アクセンチュア）, 編集：遠藤文康，＠IT]

　プログラミング言語「COBOL」などで構築されたレガシーシステムの解析やコード変換は、AIの進化によって急速に効率化しつつある。その一方で課題となるのが、AIが生成するコードに潜む誤りをどう見つけ、防ぐかだ。

　AIは間違える。それは誰でも知っている。だが「間違えることがある」という認識のままでは、対策が打てない。誤りは一様には起きず、偏って起きるからだ。AIと人間の役割分担を軸に、レガシーシステム刷新の実務を考える本連載。今回はAIによる誤りがどこに現れやすいのかを解剖する。

「AIが間違える」だけでは対策が打てない

　AIを使ったモダナイゼーションの話をすると、必ず「ハルシネーションが怖い」という声が出る。もっともな懸念だ。

　ただ、ハルシネーションを恐れるだけでは次の一手が出ない。「間違えるかもしれないから全部人が確認する」という結論にしかならず、それではAIを使う意味がなくなる。

　工数で考えてみる。5000本のCOBOLプログラムをAIで変換し、その結果を人が全数レビューする場合、1本当たり30分で済んだとしても2500時間かかる。この30分は、変換の前後を並べて差分を目で追う程度の時間だ。コピー句や呼び出し先までたどるなら足りない。それでも5人がかりで3カ月かかる。AIで実装を安くした意味の大半が、検証側で消える。

　実務で必要なのは、AIがどこで間違えるのかを知ることだ。誤りが全体に均等にばらまかれるなら、全数確認しか方法はない。だが実際は、間違いは偏って起きる。偏っているなら、そこを重点的に見ればいい。

「AIによる誤り」は3つの場所に偏る

　AIによるレガシーシステムの解析やコード変換では、どこで誤りが生じやすいのか。筆者の経験を基に整理すると、主に3つの場所に集中している（図1）。

図1　AIの誤りは、3つの場所に偏る（提供：アクセンチュア）

1．作法の断層

　1つ目は、書き方の世代が変わる継ぎ目だ。

　40年にわたって改修を重ねてきたプログラムには、世代ごとに異なるコーディング作法が層を成して混在している。1980年代前半は、処理を別の場所へ無条件に飛ばす「GOTO文」が多用されていた。1980年代半ばに登場した「COBOL-85」では、構造化プログラミングの書き方が用意され、以降はGOTO文の使用が避けられるようになった。さらに後年の改修でも別の作法が重ねられていった。

　厄介なのは層と層の間だ。GOTO文で飛んだ先が、構造化された手続きの途中ということもある。人が読んでも「なぜここに来るのか」と止まる場所で、AIも同じように迷う。ただし人は止まるが、AIは止まらずにもっともらしい解釈を示す。

2．学習の空白

　2つ目は、学習の空白である。

　「国産メインフレーム固有のデータベース」「通信を制御する仕組み」「独自の文字コード体系」「アセンブラ」などは、公開情報が圧倒的に少ない領域だ。これは過去の記事でも触れた、日本のメインフレームの特殊事情そのものだ。

　ここでのAIの振る舞いには特徴がある。国産独自のデータベースの操作を、一般的なリレーショナルデータベースの仕組みに当てはめて説明する。筋は通るので、その領域に詳しくない人は、AIのもっともらしい説明に納得してしまう。

3．暗黙の前提

　3つ目が、暗黙の前提だ。これが一番見つけにくい。

　「桁が溢れたときにどうするか」「丸めは切り捨てか四捨五入か」「符号をどう持つか」「初期値は何か」「ファイルの終わりをどう判定するか」「年度をまたぐ日付をどう扱うか」――。こうした処理のルールはコードに書かれていないか、書かれていても意図が残っていない。当時の現場では当たり前の約束事として共有され、記録されなかったためだ。

　第2回で取り上げた、レガシーシステムの仕様や背景を知る人が現場を去っていく「人の期限」の問題にもつながる。約束事を知る人がいなくなれば、人もAIも同じように推測するしかない。

実際にこう間違えた

　具体例を3つ挙げる。細部はフィクションだが、起きたことの構造はそのままだ。

　1件目。変換されたコードは、読む限り正しかった。ところがテストを流すと、集計金額が数円ずれる。元のCOBOLでは「パック10進」という形式で持っていた数値を、変換先では「double」、つまり2進の浮動小数点数に置き換えていた。パック10進は10進の桁をそのまま詰めて持ち、小数点の位置は宣言で固定される。丸めは宣言した桁でしか起きない。一方のdoubleは0.1を正確に持てないので、計算のたびに近似が入り、桁をそろえるところでもう一度丸める。この1回が余分だった。「Java」で受けるなら10進数を正確に扱える「BigDecimal」を使い、桁数と丸め方を明示するのが本来の方法だ。読めば正しく、動かすと違う。この型の誤りが一番怖い。

　2件目。条件分岐が1本消えていた。GOTO文で飛ばされた先に、一見すると到達しないように見える判定が置かれていた。実際には別のGOTO文からそこへ入る経路がある。AIはその経路を見落とし、到達しないコードとして扱った。これは、先に挙げたAIの誤りが起きやすい3つの場所のうち、1つ目の「書き方の世代が変わる継ぎ目」に当たる。

　3件目。1つの記憶領域を2通りの見方で使い分ける書き方を取り違えた。COBOLで「REDEFINES」と呼ぶ。同じ場所を、あるときは日付、あるときは連番として読む。どちらで解釈するかは、たいてい別の項目の区分値で決まる。レコード種別が「1」なら日付、「2」なら連番、という具合だ。ただし、その対応がコードに書かれているとは限らない。呼ばれた経路で暗黙のうちに決まる場合もある。そうなると読んだだけでは判定できず、AIが片方に決め打ちしたのも無理はない。

　3件に共通するのは、出力がもっともらしかったことだ。明らかにおかしければレビューで止まるが、止まらなかったのでテストまで進んだ。

　もう一つ共通点がある。3件とも最終的にはテストで見つかった。裏を返せば、テストがなければ本番で見つかっていた。本連載の後半でテストの話に2回を割くのはそのためだ。

この連載「AIに任せる、人が決める──2035年へのレガシーモダナイゼーション実務論」について

　国産メインフレームベンダーの撤退表明が相次ぐ中、COBOLなどで構築されたレガシーシステムの刷新は先送りできない課題になっている。一方、AIによってシステムの解析やコード変換は大幅に速くなりつつあるが、移行方針の選択や仕様の判断など、人が決めなければならない仕事は残る。

　本連載では、2035年までのレガシーモダナイゼーションを見据え、「AIに何を任せ、人は何を決めるのか」という視点から、アセスメント、仕様復元、移行、テスト、保守までの実務と判断軸を全20回で解説する。