“8文字の流儀”が生んだ「COBOL・謎の略語」 失われた40年分の意味を掘り出す:2035年へのレガシーモダナイゼーション実務論(6)(2/2 ページ)
AIを使えば、長年使われてきたCOBOLのコードを解析することはできる。しかし、そこに記されたデータ項目名が業務上何を意味するのかまで、正しく読み解けるわけではない。レガシーシステムの移行を阻む、長年の運用の中で失われてきた「意味」をどう取り戻せばよいのか。
いちばん厄介なのは、同じ言葉が別物を指すこと
ある保険会社の案件で、「契約」という言葉が3通り使われていた。営業部門にとっての契約は、申し込みが成立した時点のものだ。計理部門は保険数理を担当する部門で、経理とは別だが、計理にとっての契約は責任準備金、つまり将来の保険金支払いに備えて積み立てた額が支払われた時点である。経理部門にとっては、収入を計上する時点だった。
問題は、システムもその3つを別々に持っていたことだ。それぞれ別のファイルに、別の項目名で、別の粒度だった。長年それで回っていた。各部門は自分の「契約」しか見ないからである。
システム移行時に、こうした部門間の定義の違いが問題として表面化する。「『契約』は1つにまとめられませんか」という話に必ずなる。技術的にはできるが、まとめた瞬間にどこかの部門の帳票の数字が変わる。
こうした「同じ言葉でも部門によって意味が異なる用語」は、探せば必ず出てくる。「顧客」「取引」「残高」「締め日」。どれも複数の意味を持っている可能性がある。
AIはその違いに気付けない。文脈から推測はするが、部門ごとの定義の差までは分からない。むしろ、もっともらしく1つに統合した説明をしてくる。前回紹介した、AIが学習していない情報を推測で補ってしまう「学習の空白」とは別の型の誤りで、こちらは「組織の空白」と呼ぶべきものだ。
先ほどの保険会社の事例で筆者は、3つを1つにまとめるのは諦めた。代わりに3つが別の概念であることを明示し、どのような関係にあるのかを書き下した。営業の契約が成立してから計理の契約になるまでに何が起きるのか。その対応関係を定義した。統合はしていない。だが人にもAIにも読める形にはなった。
これがオントロジーと呼ばれているもの
ここまで書いてきた作業には名前が付いている。「オントロジー」だ。
言葉の響きに身構える必要はない。もともとは「存在論」を指す哲学の用語だが、情報技術の分野では30年以上前から使われている。「共有される概念を、明示的に書き下したもの」といった意味だ。
実務の言葉に置き換えれば、AIと人が同じ言葉で話すための辞書、と考えればいい。「掛金元金は掛金の一部である」「営業の契約と計理の契約は別物である」といった関係を、曖昧にせず書き下す。それだけのことだ。
なぜこのオントロジーが、AIによるレガシーシステムの解析に効くのか。定義があれば、AIは項目名から業務概念へ橋を架けられるからだ。逆に定義がなければAIは推測する。その推測は、いつももっともらしい。
用語のリストを作るだけでは足りない。用語と用語の関係まで書いて、初めて役に立つ。リストだけなら、辞書というより単語帳である。AIが推論に使えるのは、関係の方だ。
では、具体的にどのような情報を記録すればいいのか。具体例を1項目分、示しておく。
用語=掛金元金/定義=毎月の掛金のうち、元本に充当される額/上位概念=掛金/関連する用語=掛金利息、掛金累計/対応する項目名=W-KKN-GK/決めた理由=商品規程の記載に合わせた/決めた人と日付=商品部、2026年4月
1項目がこれで終わりだ。表計算ソフトウェアの1行でいい。
作ったものはAIに渡して初めて効く。数十語ならそのままプロンプトに貼れば足りる。数百語を超えたら1つのファイルにまとめて置き、参照させる形にする。
業務用語のオントロジーを作る4つの手順
業務用語の語彙を整理する作業は、4つの段取りに分けられる(図2)。
1つ目は集めること。データ辞書、コピー句、帳票の見出し、画面のラベル、業務マニュアル。散らばってはいるが、探すと意外に残っている。
2つ目はAIに下書きさせること。項目名から候補を出し、表記の揺れを見つけ、同じものを指す別名を洗い出す。量が勝負の作業なのでAIの得意分野である。
3つ目が人の仕事だ。多義語を裁定する。部門ごとの違いを残すのか、統合するのか。技術判断ではなく業務の判断である。
4つ目が既存の語彙資産につなぐこと。ゼロから作らない方がいい。日本には経済産業省とIPA(独立行政法人 情報処理推進機構)が整備してきた共通語彙基盤(略称がIMI)があり、デジタル庁の政府相互運用性フレームワークも、その最下層にIMIのコア語彙を置いている。線引きははっきりしている。氏名、住所、日付、金額といった汎用(はんよう)の語は定義ごと使える。「掛金元金」のような商品固有の語は、自前で定義するしかない。土台だけ借りて、その上は自分で建てる。業界標準がある分野なら、その語彙も使える。
これは筆者自身の失敗でもあるが、ある案件でせっかくだからと全社の用語まで洗い出すところまで作業を広げた。部門をまたいだ突き合わせは始めると際限がない。数カ月かけて気付いたのは、移行の判断に必要な分の整理が一歩も進んでいないことだった。
最大の落とし穴は、範囲を決めなかったことである。全社の用語を完璧に整理しようとすれば終わらない。必要なのは、移行の判断に使う範囲だけだ。着手前でも線は引ける。現新比較で突き合わせる帳票と外部インタフェースに載る項目、それと部門をまたいで使われている項目。この2つに絞れば、整理を始める前に対象を数えられる。ここを最初に線引きできるかどうかで、この作業が数カ月で終わるか、何年もかかって頓挫するかが決まる。
次回は、この語彙をコードの実体に結び付ける話をする。プログラム、ファイル、ジョブ、業務用語を、点と線でつないだ地図を作る。知識グラフと呼ばれるものだ。
〜AIだけでは分からない業務の意味をどう明らかにするか〜
短い項目名を業務概念へ結び直すには、コード解析だけでなく、データ、帳票、規程、現場知識を横断する必要がある。アクセンチュアの「MAJALIS」は資産・データ分析を通じて、プログラムとデータの可視化を移行の初期工程に組み込む。これは、どの項目がどこで使われ、どのデータへ流れるかを、語彙を確定するための材料として提示する土台になる。その上で、Anthropicの「Claude」が持つ長文・複雑文書の処理能力に、業務・業界知見を組み合わせることで、候補の抽出や資料横断をAIで支援できるようにする。最終的な意味と責任主体はユーザー企業が決める。
著者紹介
中野恭秀(なかの・やすひで)
アクセンチュア株式会社 デジタルコア シニア・プリンシパル
レガシーシステムを、新基盤・システムに移行するマイグレーションを中心としたAMO(Application Modernization and Optimization)を手掛ける。アクセンチュア入社以前は、メーカー系SIerや複数のベンダーで約40年にわたりコンバージョンやメインフレームのオープン系プラットフォームへのリホスト業務などを経験。COBOLコンソーシアムの設立にも従事した。
参考文献・一次情報
・「オントロジー」の情報技術分野における定義(第5節)
※オントロジーを「概念化の明示的な仕様」と定義した論文。著者による公開版はこちら
※現在広く流通している「共有された概念化の、形式的かつ明示的な仕様」という定義の出典。
・企業の業務用語をオントロジーとして整理する試みが1990年代からあること
※エディンバラ大学AIAI(Artificial Intelligence Applications Institute)によるプロジェクト
・日本の公的な共通語彙資産(第6節・図2)
※旧ドメイン(imi.go.jp)は2027年1月中旬で運営終了が告知されている。参照は新ドメインで統一した。
デジタル庁「政府相互運用性フレームワーク(GIF)」
※コア語彙を最下層に置き、その上にコアデータモデル語彙およびコアデータパーツ、コアデータモデル、分野別の実装データモデルを積む構造。IMI共通語彙基盤を土台として活用することが明記されている。
・ドキュメント欠落が移行・再構築時の支障になっていること(第1節の前提)
経済産業省 商務情報政策局 情報産業課 情報処理基盤産業室「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」2025年5月28日(委員会の事務局はIPA・経済産業省・デジタル庁。掲載はIPAサイト)
・「学習の空白」(本文中の参照)
本連載第5回「ハルシネーションには法則がある “COBOL変換”で『AIが自信満々に間違える』場所とその理由」を参照。
・図版について
※図1・図2はいずれも筆者が作成した概念図である。図1の項目名 W-KKN-GK は説明のために作った例であり、特定の案件のものではない。第5節に示した語彙1項目分の記載例(掛金元金)も、同じく説明のために作った架空のものである。用語名・定義・上位概念・関連する用語・対応する項目名・決めた理由・決めた人と日付という項目立ては、筆者が実務で使っている型に沿っている。図1の「AIの寄与」を示す帯は、寄与の大小の関係を示すための模式であり、実測値ではない。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
「AIで数週間に短縮」のはずが進まない コードモダナイゼーション、真のボトルネックと6ステップ
Anthropicは、AI駆動の大規模なコードモダナイゼーションプロジェクトに向けた準備の進め方をまとめたブログ記事を公開した。
レガシー移行を「AIに丸投げ」してはいけない 標準RAGではダメな理由と「5分割」のアプローチ
SiemensとGoogle Cloudは、レガシーコードの理解とモダナイゼーションを自動化するAIシステム「Knowledge Fabric」を構築した。数億行規模の産業用ソフトウェアを複数の専門エージェントで分割処理し、開発工数を削減するという。
メインフレームに眠る「年代物のCOBOLコード」、AIでも苦戦する"読みにくさ"の正体
複数の国産メインフレームベンダーが撤退方針を明らかにする中で、レガシーシステムの刷新は喫緊の課題だ。一方ではAIエージェントの存在がモダナイズの在り方にも影響を及ぼし始めている。40年物のシステムにどう向き合うべきか。アクセンチュアの中野氏に聞いた。
