AIに最後まで置き換わらないのは、20年前に「これからはオープン系」と言われたメインフレームだった

生成AIがコードを書く時代になって、私は逆のことを確信するようになりました。

世の中の情報量が多い領域ほど、AIは速く・うまくなります。Web開発がいい例です。世界中のオープンソースとQ&Aを学習しているから、AIはWebアプリのコードを驚くほど自然に書きます。

ならば、その理屈を裏返すとどうなるか。情報が世に出ていない領域ほど、AIは弱い。そして金融や保険の基幹を支えるメインフレーム、COBOLの世界こそ、最後までAIに置き換わらない場所になる。これが今回の私の主張です。

面白いのは、これが20年前に言われていたことの真逆だということです。

2001年、「これからはオープン系」という空気だった

私が新卒で入った2001年は、ちょうどインターネットが爆発的に普及し始めた時期でした。誰もがWebサイトを作り、オープン系の開発が一気に盛り上がっていました。会社も「これからはオープン系人材を増やすんだ」と力を入れていた。

そんな中、私が配属されたのはCOBOLとメインフレームの職場でした。

当時の雰囲気は、「COBOLが終わる」というより、「これからのエンジニアはJavaやWebといったオープン系をやった方が将来のためになる」というものでした。COBOLは古くからある言語で、新しく学ぶならオープン系だよね、という空気です。

ぶっちゃけ、当時の私自身もその空気を感じていました。周りがオープン系で盛り上がっているのに、私は大型機の前にいる。少し時代から外れたところにいる感覚は、確かにありました。

それから20年以上が経ちました。AIがコードを書く時代になって、改めて考えると、結論は当時の予想と真逆です。メインフレームは「これからのエンジニアが離れていく領域」ではなく、「AIが最後まで手を出せない領域」として、むしろ強固に残る。私はそう考えるようになりました。

私が金融の基幹系で見てきた世界

なぜそう言い切れるのか。私自身がその現場で開発をしてきたからです。

私が担当していたのは、ある大手生命保険会社の基幹系でした。契約を維持・管理する業務、保険料を集める業務、保険金を支払う業務、お金を請求する業務。生活と直結する、お金そのものを動かすシステムです。

しかも私は、出来上がったものをただ運用していたわけではありません。新しい処理が必要になれば、要件定義からテスト、本番への移行まで一通り手を動かしてきました。事務の流れそのものを大きく作り変える、そういう開発をずっとやってきました。

障害が起きれば即日対応です。お金の計算が1日止まれば、何万人もの人の生活に直接響く。深夜だろうが月末だろうが、止めるという選択肢がない。これは、肌で覚えています。

24時間365日、一度も止まらず、絶対に間違えずに動き続ける。これがメインフレームの世界の大前提です。便利だから使う、速いから使う、という次元の話ではありません。

なぜ「学習データが少ない」とAIは弱いのか

ここで技術的な裏付けを一つ。

生成AIは、世の中にある大量のコードを学習して賢くなっています。だからPythonやJavaScriptのような、オープンソースとして公開され、世界中で議論されている言語が得意です。情報量が多いほど、AIの出力は正確になる。これはAIの仕組みそのものから来る性質です。

ところがCOBOLは事情がまったく違います。

COBOLのコードは、その大半が企業の中に閉じています。公開されているものはほとんどありません。実際、オープンソースのCOBOLを集めようという有志のプロジェクト（Open Mainframe Project の COBOL データセット）がわざわざ立ち上がっているほど、世の中に出回っているCOBOLは少ないのです。研究の世界でも、COBOLの学習データが足りないことが、AI活用の大きな壁として指摘されています（XMainframe 論文）。

つまり、AIにとってCOBOLは「教科書がほとんど手に入らない言語」です。情報量がAIの得意・不得意を決めるという原則からすれば、AIがCOBOLを苦手とするのは当然のことです。

それでもAIはメインフレームに入り始めている

ここで誤解されないように、調べて分かった事実を正直に書いておきます。

「AIはメインフレームに一切関係ない」というのは、もう正確ではありません。実際、IBMは自社のAIをCOBOLとメインフレーム業務で訓練し、メインフレーム近代化を支援する製品を出しています（IBM watsonx Code Assistant for Z）。世に出ているCOBOLが少ないなら、企業の中に眠っている自社のCOBOL資産そのものを学習に使う、という発想です。

ただ、ここが肝心なところです。

そのAIの主な役割は「新しく一からコードを書く」ことではありません。誰も中身が分からなくなった古いCOBOLを読んで説明する、別の言語へ移行する下書きを作る、テストを用意する。この方向です。

例えるなら、AIは新しい橋を一から設計して架ける技師として呼ばれているのではなく、設計図が失われた古い橋を解読する考古学者として呼ばれている。金融機関の本当の痛みは「COBOLを書ける人がもういない」「中身が誰も分からない」ことであって、新しい開発ではないからです。

だから私の主張はこう整理できます。AIは「書く係」ではなく「解読・移行係」として入ってくる。新しい処理を一から書かせて、そのまま本番で動かす世界は、当面来ません。

本当の壁は「データの少なさ」だけではない

学習データが少ないという技術的な話は、実は半分でしかありません。現場をやってきた人間として、もっと根本的な理由があります。

メインフレームの開発は、とにかく安定して動くことが最優先されます。レビューとテストに、信じられないほどの工数をかけます。開発全体の半分以上がテスト工程になることも珍しくありません。

しかも対象は、数千行という規模ではありません。何十万行、何百万行というCOBOLのソースを、既存の動いている資産を壊さないように直していくのです。

これだけの規模を、一切のミスが許されない前提で開発してきた人間からすると、推論で、つまり「たぶんこうだろう」という確率でコードを書くAIに、この仕事をそのまま任せるのは、とてもできる気がしません。それができる人がいたら、勇者だと思います。

新しく書いたコードのレビューや、その責任までAIに丸ごと預けて、いきなり本番稼働させる。そんな運用は、金融の基幹系では絶対に起きません。これは技術の進歩の問題ではなく、扱っているものの重さの問題です。

一文字の間違いが、金融庁への報告になる世界

なぜそこまで慎重なのか。間違いの代償が桁違いだからです。

金額の計算を一つ間違えれば、それは即座に金融庁への報告ものになります。顧客の個人情報を取り違えれば、信頼そのものが崩れます。保険金の支払いを一件間違えれば、その向こうには困っている人の生活があります。

ここでは「とりあえず動かして、間違ったら直す」が通用しません。間違ってからでは遅い領域があるのです。

AIは賢い。マジで賢い。でも、確率で答えを出す道具です。99%正しくても、残りの1%が誰かの保険金や個人情報だとしたら、その1%を許容できる経営者はいません。

メインフレームがAIに最後まで置き換わらない本質は、ここにあります。技術が追いつかないからではなく、間違いが許されない領域だからです。世の中の「AIが仕事を奪う」という話は、この区別を抜きに語られがちです。奪われる仕事と、最後まで人が責任を持ち続ける仕事は、はっきり分かれます。そしてその境目は、業界や言語ではなく、間違いの代償の大きさで決まります。

金融の「ベリファイ入力」で、AIのレビューを考えてみる

ここで一つ、金融の事務処理から学んだ知恵を紹介します。「ベリファイ入力」です。

同じ伝票を2人が別々に入力し、結果がぴったり一致したら正しいとみなす。昔からある二重チェックの仕組みです。私もずっと、この考え方が前提の現場で仕事をしてきました。

これをAIに移せないか、という発想が出てきます。AIはいくらでも増やせます。なら、コードのレビューもAIを10体、100体用意して、全員の結果が一致したら本番に上げる。人間より正確になるのではないか。実際これは今、研究の世界でも真剣に検討されているテーマです（複数AIの合議によるコード品質チェックの研究）。

ただ、ここに肝心な落とし穴があります。ベリファイ入力が効くのは「一致したから」ではありません。2人のミスが、互いに無関係だからです。人間の打ち間違いはバラバラで、同じ場所で同じ間違いを2人がそろってやることは、まずありません。だから一致すれば、ほぼ正解だと言えるのです。

ところが、同じAIを100体並べても、ミスは無関係になりません。同じ学習をしているので、同じ間違いをそろってやります。全員が、自信を持って、同じ方向に間違える。これでは100体が一致しても、実質「1体に100回聞いた」のと変わりません。一致しているのに全員間違っている、が起こり得るのです。

もう一つ大事な点があります。ベリファイ入力が効いたのは、2人が「元帳」という動かない正解に照らしていたからです。意見が合ったから正しいのではなく、事実と一致したから正しい。AIでやるなら、本当に効くのは「AIが良さそうと投票する」ことではなく、「テストや実行結果という、動かない事実にぶつける」ことです。

だから、こう整理できます。癖の違うAIを組み合わせ、かつテストで客観的に確かめられる仕事なら、AIの多重チェックは人間のレビューを超えることもあります。ここは前向きに使える領域です。

一方、基幹系の本番をいきなり任せるのは、今はまだ無理です。AIが揃って同じ間違いをする問題に加えて、正解そのものが元帳のように書き残されていない、という別の壁があるからです。40年分の、誰も明文化していない業務ルールが正解です。100体が「コードとしては正しい」と一致しても、ベテランしか知らない例外をそろって見落とす。だから現時点では、ここで最終責任をAIに渡す線は越えられません。

ただ、私はこれを「未来永劫むり」だとは考えていません。むしろ逆です。

今のAIの弱点は、要するに「みんな似すぎている」ことです。同じようなデータで学び、同じような癖を持つ。だから揃って間違える。けれど人間のレビューが成り立つのは、一人ひとりが違う経験をして、違う間違い方をするからです。だとすれば、本当に多様なAI、つまり違う作られ方をして違う癖を持つAIが揃ってくれば、ベリファイ入力がAIの世界でも成立する日は来ます。AIにどう多様性を持たせるかは、今まさに研究が進んでいるところです。

そうなれば、残る壁は「正解が明文化されていない」ことだけになります。これも、企業の中に眠る業務知識をAIが少しずつ吸収していけば、年々小さくなっていくはずです。2つの壁が下がっていけば、基幹系の景色が変わる日も十分にあり得る。AIに長く関わってきた人間として、私はその未来が来てほしいと考えています。

今すぐではない。でも、方向としては開いている。これが私の見立てです。

そして現時点での線引きは、結局、次に話す「影響範囲」の問題に行き着きます。

AIに任せていい仕事、任せてはいけない仕事の分かれ目

ここまで読んで、「では自社はどう考えればいいのか」と思った経営者の方へ。ここからが本題です。

これは実はCOBOLやメインフレームに限った話ではありません。オープン系のシステムでも、Webアプリでも、まったく同じ判断軸が使えます。

任せてはいけないのは、シンプルに言えば、顧客情報を扱い、かつ100点が求められるシステムです。

一つの不具合が、何万人・何百万人に迷惑をかけてしまう。お金の計算を間違えれば取り返しがつかない。個人情報を間違えてはいけない。こういう領域は、COBOLかどうかに関係なく、AIを100%信用して導入してはいけません。そこだけははっきり言えます。

逆に、不具合が出てもすぐに気づいて直せる領域なら、どんどんAIを使えばいい。社内向けの業務システム、社内の情報整理、下書きの作成、調べ物。こういうところは、多少間違えても影響が限定的で、すぐに拾い直せます。ここでAIを使わない手はありません。

たとえば、見積書のたたき台をAIに作らせる。これは間違っていても、人が最後に目を通して直せます。問い合わせメールの返信案を下書きさせる。これも送る前に確認すれば済みます。社内資料を要約させる、過去のやり取りから必要な情報を探させる。どれも「間違えてもその場で気づける」仕事です。

一方、お客様の口座から自動で金額を引き落とす処理を、AIに最終判断まで任せる。これは話が別です。同じ会社の中でも、この線引きは業務ごとに変わります。会社単位で「AIを入れる・入れない」を決めるのではなく、業務単位で影響範囲を測るのが正解です。

影響範囲という、たった一つの判断軸

整理すると、判断の軸は一つです。「その仕事が間違えたとき、どれだけの人に、どれだけの影響が出るか」。

影響範囲が大きく、間違いが許されないものは、AIに最終判断を委ねない。影響範囲が限定的で、間違ってもすぐ拾えるものは、AIに任せて加速する。この線引きさえ持っていれば、「AIをどこに使うべきか」で大きく間違えることはありません。

念のため付け加えると、影響範囲が大きいシステムなら絶対に安全、という話でもありません。世界中で使われている大手のクラウドでさえ、不具合で止まることはあります。完璧なシステムは存在しません。だからこそ、間違いが起きたときに誰が・どう責任を取れるのかまで含めて、影響範囲を見る必要があります。

この判断は、流行や雰囲気で決めるものではありません。自社の業務を一つずつ、影響範囲という物差しで測っていく作業です。

私が「AIで刷新できないか」と相談されたら最初に見ること

もし私が技術顧問として「うちのシステム、AIで刷新できないか」と相談されたら、いきなり「できます」「できません」とは答えません。

最初に見るのは、そのシステムの影響範囲です。

間違えたとき、何人に、どんな影響が出るのか。お金や個人情報に直結するのか。不具合が起きたとき、すぐに気づいて直せる仕組みがあるのか。それとも一発で取り返しがつかないのか。

ここを整理しないまま「AIで効率化しましょう」と進めるのは、危険です。逆に、影響範囲が限定的な業務が見つかれば、そこは小さく試して大きな成果を出せる、AI活用の絶好の入口になります。

「AIで何ができるか」ではなく「自社のどこにAIを使うべきか」。この順番を間違えないことが、遠回りに見えて一番の近道です。

まとめ

情報量が多い領域ほどAIは得意になる。だから世に出ていないCOBOL・メインフレームは、AIが最後まで苦手とする領域として残る。
20年前は「これからのエンジニアはオープン系」という空気だった。AI時代に、その評価は逆転した。
AIはメインフレームに「書く係」ではなく「解読・移行係」として入ってきている。新規開発をAIに委ねて本番稼働させる世界は当面来ない。
任せてはいけないのは、顧客情報を扱い100点が求められ、影響範囲が大きい仕事。判断軸は「間違えたとき、どれだけの人にどれだけの影響が出るか」のひとつに尽きる。

「うちの業務、どこまでAIに任せていいんだろうか」と迷っている方は、無料の30分オンライン診断で、影響範囲という物差しを使って一緒に整理できます。AIを使う前のこの仕分けが、その後の遠回りを防ぎます。

この記事の内容について、現場で整理したい方へ

AI×IoTの技術顧問として、月額契約で継続伴走しています。PoC設計・技術判断・組織設計・ベンダー管理・実装支援まで、現場で動くまで一緒に進めます。受託開発（請負）ではありません。

→ AI技術顧問サービスの詳細／無料30分オンライン診断／料金一覧