AIは、長年使われてきたCOBOLのプログラムをどこまで理解できるのか。レガシーシステムの刷新にAIを活用する上で、その能力をどう評価すべきかは重要な課題だ。とはいえAIの読解力が高くても、システム全体を正しく理解できるとは言えない。AI活用の可能性を見極めるために、企業は何を検証すべきなのか。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
現場で必ず出る問いがある。AIは「COBOL」を読めるのか――。読めるか読めないかの答えは人によって割れ、どちらの側も数字を持っていない。第4回が扱うのは、この問いを数字にする測り方の設計である。筆者自身が測った数字は出さない。何が測れて何が測れないのかを、先に整理しておきたい。
国産メインフレームベンダーの撤退表明が相次ぐ中、COBOLなどで構築されたレガシーシステムの刷新は先送りできない課題になっている。一方、AIによってシステムの解析やコード変換は大幅に速くなりつつあるが、移行方針の選択や仕様の判断など、人が決めなければならない仕事は残る。
本連載では、2035年までのレガシーモダナイゼーションを見据え、「AIに何を任せ、人は何を決めるのか」という視点から、アセスメント、仕様復元、移行、テスト、保守までの実務と判断軸を全20回で解説する。
「AIはCOBOLを読めますか」と、よく聞かれる。
返ってくる答えは二通りに割れる。実際に使っている人は「かなり読める」と言い、慎重な人は「うちのコードは特殊だから無理でしょう」と言う。どちらも実感としては正しい。だが、どちらも数字を持っていない。
先日も、ある会議でこのような場面があった。若手が「試しにAIに読ませたら、うちのバッチをかなり正確に説明してくれました」と言う。長くそのシステムを見てきた隣の席の課長が「たまたま素直なところを見ただけでしょう」と返す。二人ともいい加減なことは言っていないが、根拠は自分が見た数本だけだった。
数字がないと議論が前に進まない。移行の方式を決めるとき「AIがどこまでできるか」が前提条件になるにもかかわらず、それが印象で決まる。会議のたびに同じ議論になる。
では、どうすれば根拠になる数字を出せるのか。ここから先は測り方の話をする。断っておくと、この回で出すのはあくまで測り方の設計であって、筆者自身が測った数字ではない。設計が固まらないまま数字だけを出しても、それが何を意味するのかを読者が確かめられないからだ。
何で測るかを決めるのは、何を測ったことにするかを決めることでもある。曖昧なまま数字を出せばそれが一人歩きするので、素材の選び方から説明する。
自社が関わった案件のコードを使えば実態には近い。だが公開できないので、誰も検証できない。数年後には条件を思い出せる人もいなくなる。
そこで候補になるのが、情報処理技術者試験の過去問題である(図1)。
基本情報技術者試験の午後の試験には、長らくCOBOLの問題があった。プログラムを読んで空欄に入る処理を選んだり、実行結果を答えたりする形式だ。だが2019年度秋期を最後に出題されなくなり、代わりに「Python」が加わった。過去問題は情報処理推進機構(IPA)が2009年度分から公開している。つまり2009年度春期から2019年度秋期までが、誰でも入手できる共通の問題だ。
共通の問題を使う利点は3つある。誰でも同じ条件で追試でき、正解が公式に確定していて、人間である受験者と数字を比較できるという点だ。
筆者にも失敗がある。この手の測定を最初にしたとき、手近だという理由で支援中の案件のコードを題材にした。数字は出た。だが社外には出せず、他と比べることも誰かが同じ条件で確かめ直すこともできない。測ったつもりで、何も測っていなかった。題材を公開されたものに変えたのは、その後だ。
測り方もそろえておく。複数のモデルを並べ、設問ごとに独立して解かせる。渡すのは問題文とソースと選択肢だけで、年度や出典は伏せる。解答は記号だけにして採点の揺れを消し、生成条件も統一する。地味だが、書き残さないと自分の数字すら再現できない。
先に試験問題をAIに読ませることの限界を書いておく。一つは、選択式の設問が含まれることだ。選択肢が4つなら4問に1問、8つなら8問に1問は当てずっぽうでも当たる。正答率そのままを能力として見積もらず、偶然正解した分を差し引いて読むのが公平だろう。
もう一つが厄介だ。公開された過去問題は、モデルの学習データに含まれている可能性がある。解いたのではなく、覚えていただけかもしれない。完全に否定する方法はない。覚えていて間違えるはずのないところで間違えていれば、丸暗記ではなさそうだとは言える。
そして最大の限界は、試験問題で測れるのが読解力の一部に過ぎないことだ。実務で必要なのは、読んで、直して、動かして、結果が同じだと確かめるところまでだ。試験は最初の一歩しか見ない。
それでも意味はある。「COBOLは学習データが少ないから、AIには読めない」ということが、いまも成り立つのかどうか。丸暗記ではないと確かめた上でなら、その問いに近づく手掛かりになる。印象で語られる前提を、確かめられる形にする。目的はそこにある。
もっと大きな距離の話をしたい。
試験問題のCOBOLは、よく書かれている。1本で閉じていて、せいぜい数十行から百数十行、変数名も意味が分かる。出題する側が解けるように作っているのだから、当然だ。
40年物のCOBOLは、そういうわけにはいかない。1本読むだけでも、取り込まれたコピー句をたどり、実行時にしか決まらない呼び出し先を推し量り、独自のデータベースの構造を調べ、JCL(バッチ処理の手順を書いた定義体)の前後関係まで押さえる。正解は、公式解答集ではなく本番の出力そのものだ。
これが実務では厄介だ。試験なら解答と違えば間違いだと分かる。だが移行では、新の出力が旧と違ったとき、どちらが正しいのかは決まらない。第1回の1円の丸め処理がそれだ。AIがどれだけ正確に読んでも、この判断は人に残る。
AIが「読める」ことと「移行できる」ことを隔てているのは、文脈の量である。図2の左右の差がその距離だ。
試験問題を解けることは必要条件だが、十分条件ではない。読解の力は試験問題で確かめられる。だが、その力を発揮させられるかどうかは、渡す文脈にかかる。前回紹介したAIに読ませられるかどうかを測る6項目(ソースの欠損、コーディング世代の混在、動的呼び出し、非COBOL資産、独自技術への依存、テストデータ)は、それを測るものだった。
メインフレームで「AIに実行まで任せる」が32%→23%に後退、なぜ慎重姿勢に?
富士通も日立も去る、日本での「メインフレーム脱却」が一筋縄ではいかない理由
JFEスチールが「脱メインフレーム」、全製鉄所の“基幹系オープン化”を2年前倒しCopyright © ITmedia, Inc. All Rights Reserved.