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

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

なぜ「自信満々に」間違えるのか

　人間の技術者なら自信のないところで手が止まる。もしくは「ここが分からないので確認させてください」と言う。この一言が品質を支えている。

　AIはそうは言わない。分からないところでも同じ調子で答えを返す。しかも文法的に正しく、体裁も整う。確信の度合いが、出力の見た目に現れない。

　これがレビューを擦り抜ける理由だ。人のレビューは、書き手の迷いを手掛かりにしている。コメントが不自然に多い、変数名が投げやり、処理が回りくどい。そのような兆候があれば「ここはあやしい」と当たりをつける。AIの出力にはその痕跡がない。

　もう一つ厄介なのは、同じことを2回尋ねると違う答えが返ることだ。人が相手なら「さっきと違う」とすぐ気付く。だが数千本が相手だと、その比較すら難しい。ばらつきに気付けないまま紛れ込む。

　これは、AIの出来が悪いという話ではない。人間の側が「迷い」という信号に頼っていたということだ。その信号がない以上、勘に頼ったレビューは効かない。効くのは機械的な突き合わせである。

対策は、境界を先に引くこと

　では、どうすればいいのか。結論は、AIに任せる領域と機械的に固定する領域を着手前に分けておくことだ（図2）。

図2　着手前に、3つの領域へ切り分けておく（提供：アクセンチュア）

　図2の左側にある「機械的に固定する」は、決定論的に処理できるところだ。「構文の変換」「データ項目の対応付け」「桁と型の扱い」「呼び出し関係の解決」「文字コードの変換」――。ここはルールで書ける。書けるならAIに推測させる理由はない。同じ入力から必ず同じ出力が出る方が検証も楽だ。

　第3回では、独自の文字コード体系も動的呼び出しも、AIが苦手とする難物として挙げた。一見すると話が食い違うと思われたかもしれないが、前提が変わったのではない。AIにとって難しいことと、ルールで書けることは別だ、というだけである。推測させれば間違えるが、変換表や呼び出し関係の一覧があれば機械的に決まる。だからAIによる誤りが偏る場所は、図2の左側に寄せる。

　パック10進の扱いも、REDEFINESの解釈も、独自データベースの入出力も、ルールとして固定すればAIが間違えようがない。固定するとは、REDEFINESなら、どの区分値のときにどちらの見方をするのかを一覧にして変換の入力に与えることだ。一覧が作れないものは、人が調べるまで変換に回さない。先の3件のうち1件目の「数値の型の誤り」と3件目の「データの解釈の誤り」は、ルールを定めて機械的に処理すれば起きず、2件目の「条件分岐の見落とし」は到達可能性の解析をツールに任せれば防げた。

　図2の真ん中がAIの領分だ。意図の説明、命名の提案、ドキュメントの生成、テストケースの候補出し、差異の原因の推定。どれも正解が1つに決まらず、間違えても取り返しがつく。

　人の領分は図2の右側だ。「旧と新のどちらを正とするか」「どこまでの差異を許容するか」「何をもって受け入れとするか」――。本連載の第1回から書いている通り、こうした判断はAIに委ねるのではなく、人が責任を持って下す必要がある。

　もっとも、この切り分けは一度決めて終わりではない。ルールに基づいて機械的に処理できると思っていたものが実際にはできなかったり、AIに任せて十分な領域が見つかったりする。大事なのは、境界を引くこととそれを見直す場を持つことだ。境界がないまま進むと、誰が何を確認すべきか分からなくなる。

　何でも機械的に処理すればよい、という単純な話でもない。何もかもルールにすれば手に負えなくなる。ルール化の労力と、検証の労力を比べて天秤（てんびん）にかけるしかない。間違えたときに気付けるかどうかの勘所が必要だ。気付けない誤りが出る領域は、多少高くついてもルールで固める。気付ける領域ならAIに任せて検証で拾えばいい。

　では、このルールは誰が書くのか。標準的な部分は移行ツールのベンダーが持っている。だが自社固有の約束事（桁溢れの扱い、独自データベースの入出力、外字の対応）は案件ごとに作るしかない。手を動かすのはSIerやツールのベンダーだが、何を機械的な処理に任せるかを決めるのは発注側の仕事だ。

　だから筆者は提案を受けるときに2つのことを聞く。決定論的に固定する範囲はどこまでか。そのルールは誰が書き、どこに残るのか。その答えが返らない提案は、機械的な処理、AI、人の役割分担の境界を引けていない。

　以前の取材で、筆者はJavaへの変換を「ガードレール」と表現した。あのときは言葉が足りなかった。ガードレールとは、AIに自由に走らせない区間を先に決めておくことである。

〜AIの「もっともらしい誤り」をどう見抜くか〜

　ハルシネーション対策は、注意喚起ではなく、AIが推測してよい範囲を工程として限定することで実効性を持つ。アクセンチュアの「MAJALIS」では、現行COBOLの処理を機械変換で再現し、変換漏れ、命令網羅、分岐網羅を確認した上で、AIによる“Pure Java”との実行結果を比較する。この手法では、生成AIの出力をそのまま正解とせず、決定論的な基準と自動比較をガードレールとして組み込む。AIによる変換の速度を生かしながら、実行結果の差分を手掛かりに、もっともらしい誤りを検出できるようにする設計だ。

---

　次回は、その境界を引く手前でつまずく話をする。現場で最初に詰まるのは構文ではなく語彙（ごい）だ。“8文字の項目名”が何を指すのか、誰も答えられない。

著者紹介

中野恭秀（なかの・やすひで）

アクセンチュア株式会社 デジタルコア シニア・プリンシパル

レガシーシステムを、新基盤・システムに移行するマイグレーションを中心としたAMO（Application Modernization and Optimization）を手掛ける。アクセンチュア入社以前は、メーカー系SIerや複数のベンダーで約40年にわたりコンバージョンやメインフレームのオープン系プラットフォームへのリホスト業務などを経験。COBOLコンソーシアムの設立にも従事した。

参考文献・一次情報

・「1本のプログラムに複数世代の作法が層を成す」こと（1つ目の偏り）

メインフレームに眠る「年代物のCOBOLコード」、AIでも苦戦する“読みにくさ”の正体　＠IT、2026年7月29日

※「40年、50年物のレガシーシステムだと3世代ほどのコーディングパターンにまたがるのが一般的」「そうした異なる作法が混在するコードだと、いかにAIの進化が著しくても一定のハルシネーションを引き起こす可能性がある」との言及がある。

・「公開情報の少なさが誤りにつながる」こと（2つ目の偏り）

富士通も日立も去る、日本での「メインフレーム脱却」が一筋縄ではいかない理由　＠IT、2026年7月22日

※日本のメインフレーム固有のミドルウェア・データベースについて「それに関する公開情報はJavaに比べて圧倒的に少なく、AIが十分に学習できていない」との指摘がある。

・「決定論的に固定できるところは固定する」という設計思想（第5節）

V. Chakaravarthy 他, “Enterprise-Scale COBOL-to-Java Translation: LLMs Augmented with Program Analysis,” ICSE 2026.

※静的プログラム解析でJavaのクラス・メソッド構造を先に決め、その枠内でLLMに変換させる方式。結果のばらつきが減ることが報告されている。

・「ガードレール」としてのJava変換（本文中の参照）

メインフレームに眠る「年代物のCOBOLコード」、AIでも苦戦する“読みにくさ”の正体　＠IT、2026年7月29日

※「Javaへのリライトは単に言語を変換するということではなく、『ガードレール、安全装置のような位置付け』に変わってくる」との言及がある。

・「人の期限」（本文中の参照）

本連載第2回「2035年から逆算すると、締め切りは『来年』になる」を参照。

・図版について

図1・図2はいずれも筆者が作成した概念図である。図1の「公開情報の量」を示す帯は、量の大小の関係を示すための模式であり、実測値ではない。