COBOLの母と呼ばれるグレース・ホッパーが、いま生きていたら、何と言うだろう。
生成AIに曖昧な指示を投げれば、それらしく動くコードが返ってくる。いわゆるバイブコーディング、あるいはエージェンティックコーディングの様子を眺めていると、ふと、そんなことを考えてしまう。というのも、これがまさに、彼女が60年以上前に望んでいたことなのではないか、と思うからだ。
COBOLという最初の民主化
なぜそう思うのか。それを説明するには、時計を1950年代まで巻き戻す必要がある。
当時のコンピューターは、部屋を丸ごと占有するほど巨大で、しかも非常に高価だった。持てるのは軍や政府、ごく一部の大企業だけ。軍は弾道計算に、政府は国勢調査の集計に、そして企業も給与計算や在庫管理にと、この巨大な機械を使い始めていた。ただし、どの会社でも、というわけではない。プログラムを書けるのは、数学と電気工学を修めた一握りの専門家だけ。当時のプログラミングは、機械語やアセンブリ、つまりメモリの番地やレジスタを一つずつ指定して、コンピューターに直接命令する作業で、そういう書き手を抱えられる組織しか、機械の恩恵にあずかれなかった。会計や給与の担当者が、自分の手で、とはいかない。需要は膨らむのに、書ける人間が足りない。それが当時のボトルネックだった。
これを変えようとしたのが、のちに「COBOLの母」と呼ばれるホッパー*1である。それまでプログラミングとは、人間のやりたいことを、コンピューターに分かる数式や記号の列へと、人手で書き換える作業だった。いわば、人間の意図を機械の言葉に翻訳する仕事だ。彼女の発想はシンプルだった。その翻訳こそ、機械自身にやらせればいい。人間は、やりたいことを自分の言葉で書く。英語に近い言葉でコンピューターに指示を出せるようにして、専門家でなくてもプログラミングを扱えるよう、門戸を開こうとしたのだ。
自然言語でコンピューターに意図を伝える。彼女が60年以上前に目指したのは、つまり、いま私たちがAIにやらせていることそのものだった。こうして生まれた、英語をベースに事務処理を記述する言語の原型*2が、やがてCOBOLになる。
ここで起きたのは、確かに民主化だった。専門家にしか触れられなかった道具が、英語を読み書きできる人々へと開かれた。
少なくとも、そう見えた。
二つの反発
COBOLの民主化に対する反発には、性質の違う二つがあった。
一つは、事実に根ざした反発だ。手書きのアセンブリで機械を限界まで使い切っていた熟練の技術者たちにしてみれば、コンパイラの吐くコードは、自分たちの手書きより無駄が多く、遅い。これは言いがかりではなく、本当のことだった。1965年にハネウェルという計算機メーカーがまとめた社内報告書でさえ、熟練者の手書きのほうがコンパイラの出力より効率的だと認めている。ただし同じ報告書は、こうも問い返している。では、それほど腕の立つ書き手が、現場に何人いるのか、と*3。
もう一つは、やや感情的な反発だ。英語もどきの言語など本物のプログラミングではない、という考え。機械の言葉への翻訳は、長い年月をかけた者だけが担える難しい技で、その自負は、いつしか選民意識のようなものになっていたとも言えよう。自分たちの聖域が、あっさり開け放たれていく。面白いはずがない。
実を言うと、私自身にも、この感覚に覚えがある。正直に言うと、私はCOBOLでプログラミングをしたことがない。学生時代は科学技術計算をやっていて、IPAの情報処理技術者試験（今とは全然違う、シンプルな体系だった）でも、COBOLではなくFORTRANを選んだ口だ*4。その頃の私は、英語の文章のようなCOBOLの見た目を、どこかで「これはプログラミングっぽくないな」と見下していた。いま思えば、その「プログラミングっぽくなさ」こそ、ホッパーが狙ったものだった。少しプログラミングをかじっただけの私ですら、そう感じた。腕に覚えのある当時の熟練者なら、その反発はなおさら強かったはずだ。
この二つは、いまの生成AIをめぐる議論の中にも同じ匂いを感じる。一つ目のコード品質は、そのまま当てはまる。AIの吐くコードにはまだ穴が多く、「検証せずに任せるな」という指摘は、技術的にはたいてい正しい。検証していないコードが、いつか事故を起こす。これは本当のことだ。
二つ目のほうは、やや微妙で、否定されることも多いだろう。声に出して言うのが憚られる、センシティブなトピックだ。もちろん、生成AIに慎重な人がみな選民意識から反対しているわけではない。純粋に品質や安全性を心配している人のほうが、多数派だろう。でも、長い時間をかけて身につけたものが、こうもあっさり機械に肩代わりされていくのを、すんなり認めたくないという気持ちがまったくないかと問われると、ないとは言い切れないのではないか。そして、その手の感情は、技術的な正論にひっそりと紛れ込む。AIの課題を議論していたつもりが、いつのまにかAIのある未来そのものに後ろ向きになっている。自分自身では、そうならないように気をつけてはいるが、感情の問題なので、なかなか客観的には判断しづらい。私自身も、気を抜くとそうなりかねない。自戒を込めて書いている。
言語そのものの弱点
ここまでは、人々の反発の話だった。だが、COBOLが抱えていた問題は、それだけではない。言語そのもの、つまり手段の側にも、はっきりした弱点があった。
その代表が、再利用だ。「一度書いたものを使い回す」という発想を最初に形にしたのは、ほかならぬホッパーだった。彼女がCOBOLより前に作ったA-0という仕組みは、よく使う処理をテープに蓄え、必要なときに呼び出して組み合わせる、いまでいうライブラリの原型である。毎回ゼロから書くのではなく、出来合いの部品を組む。それまで何週間もかかった作業が、けた違いに速くなったという*5。
COBOLもこの志を受け継ぎ、データの定義と処理のロジックを分けて書く構造を入れた。ところが、肝心なところが抜けていた。プログラムを部品に分けても、その部品どうしで値を受け渡す仕組みがなかったのだ。実際に文法を設計した中心メンバーの一人、ジーン・サメットは、後年これを委員会最大の失敗だったと振り返っている*6。値を渡せなければ、データはプログラム全体で共有するしかない。どの部品からでも自由に書き換えられる、巨大なグローバル変数の山だ。どこか一か所をいじると、まったく無関係なところが壊れる。部品に分けたつもりが、境界が境界として効いていない。便利なはずのCOBOLで作ったシステムが、巨大なスパゲッティへと化けていった技術的な理由の一つが、この「グローバル変数地獄」だ。この欠陥がきちんと直るのは、ずっとあと、1985年の大改訂（COBOL-85）を待つことになる。部品の内側に、外から勝手に触られない自分専用のデータを持てる*7ようになり、部品どうしで値を受け渡す道もついた。
もっとも、こうした弱点が、そのまま放置されたわけでもない。COBOLが各社に広まると、メーカーは自社の機械に都合よく独自の拡張を加えはじめ、同じCOBOLのはずが、互いに通じない「方言」へと枝分かれしかけた。ホッパーはこれを食い止めるため、規格を定め、その規格どおりに動くかをテストし、合格しないコンパイラは政府も買わない、という仕組みまで作りあげた。さらに、まだ誰も書いていなかった分厚い操作マニュアルも、自分の手で書いている*8。再利用、標準化、検証、ドキュメント。どれも派手さはないが、放っておけば壊れていくものを支えるための地道な規律だ。民主化された道具がいずれ負債に変わることを、彼女は誰よりもよく知っていた。
そして、この弱点は、いまのAIにそっくり当てはまる。AIがもっとも得意なのは、似たようなコードを、その都度すごい速さで作り出すことだ。同じような処理が必要になるたびに、似て非なるコードを、一から何度でも生成する。だが再利用は、その逆を行く。同じ処理なら、同じ部品を使い回す。二度と書かずに済むよう、共通する部分を一か所にくくり出してライブラリにまとめ、どこで切るかという境界を引く。いわば「何を書かないか」を決める仕事で、ここはこちらが指示しなければ、AIはまず手をつけない。そして、境界を引かないままAIにコードを吐かせ続けると、コードはどんどん絡まり合っていく。どこに触れれば何が壊れるのか、誰にも分からない塊。これは、さきほどのCOBOLのグローバル変数地獄と、同じ景色だ。
アスベスト化した負債
弱点を抱えたまま、それでもCOBOLは爆発的に広まった。便利なものは、とにかく大量に作られる。英語に近くてとっつきやすいぶん、専門の設計教育を受けていない人でも手を出せた。だから、業務アプリが次々に書かれていった。小さいうちはよかった。だが、コードが数万行に膨れ、仕様書は失われ、書いた本人も引退し、やがて誰も全体像を把握できなくなる。
英語圏のメディアは、いまのCOBOLを「デジタル・アスベスト」と呼ぶことがある*9。かつてはどこにでも使われたのに、いまや安全に取り除くのが極めて難しい、という意味で、建材のアスベストになぞらえた言い方だ。日本でいえば、経済産業省が「2025年の崖」として警告してきたレガシー刷新の問題が、ほぼ同じことを指す。基幹システムの約6割が、稼働から21年以上を経た老朽システムになると見積もられていた*10。
安く便利に大量導入され、負債となり、撤去は難しく、後始末をする人が割を食う。導入された当時は未来を予測できていなかったというのも同じだ。アスベストの構図そのままだ。ここまでは、よくある「歴史は繰り返す」という話でもある。だが、本当に考えたいのは、この先だ。
ねじれ
アスベストには、それを建材として使う工事と、あとから取り除く工事がある。両者はまったく別の仕事だ。使って固めるのは簡単で安い。だが、あとから安全に取り除くのは、難しく、費用もかかる。だからこそ、負債になる。
ところが、いまそこに、新しい撤去の担い手が現れた。AIだ。古いコードを読み解き、別の言語へ作り直す。実際、2026年2月にAnthropicがClaudeでCOBOLを解析・変換できると発表しただけで、IBMの株価が一日で約13%も下落する一幕もあった*11。市場が一瞬、「AIがCOBOL問題を解決した」と早合点したわけだ。
いまあるCOBOLは、人間が何十年も前に書いたものだ。だが、これから書くコードなら、作るのもAI、直すのもAIになる。アスベストと違って、持ち込む側と片づける側が、同じ道具になるわけだ。だとすれば、もう負債は怖くない。作ったそばから片づけられるのだから。そう言いたくなる。
だが、そう簡単ではない。
試しにAIへ「このCOBOLを別の言語に変換してほしい」とそのまま頼むと、たいていうまくいかない。これはAIに始まった話ではなく、行単位で機械的にJavaへ置き換える変換ツールは昔からあって、その失敗には名前までついている。「JOBOL」だ。見た目はJavaなのに、中身はCOBOLの構造を引きずったまま。結局それを保守できるのは元のCOBOL技術者だけ、という本末転倒があちこちで報告されている*12。新しい言語に引っ越したつもりが、古い家から家具を丸ごと運び込んでしまう。
なぜそうなるのか。古いコードは、単体では動いていないからだ。画面制御やデータベース、夜間バッチが複雑に絡み、断片だけ直しても全体は動かない。同じメモリ領域を複数の意味で使い回すようなCOBOL特有のデータの持ち方は、現代の言語にそのまま移せず、移すにはそのデータが何を表すのかを人間が分かっていないといけない。おまけに、企業の基幹コードは社外に出ない資産だから、世の中のAIはその方言や社内の慣習を学んでおらず、知らないところをそれらしく埋めてしまう。
ここで念を押しておきたいのは、これが、AIが賢くなれば消える種類の問題ではない、ということだ。あるデータが業務上なにを表すのか、なぜこの順で動かしているのか。その答えは、そもそもコードのなかに書かれていない。当時の担当者の頭のなかか、とうに失われた仕様書のなかにしかない。書かれていないものは、どれだけAIが賢くなっても、読み取りようがないのだ。
では、どう進めればいいのか。実際、うまくいっている移行は、手順がだいたい決まっている。まず、もとのコードを解析して、それが何をしているかを洗い出す。次に、その振る舞いを守るためのテストを用意して、「これさえ通れば正しい」という基準を固める。そのうえで、AIに少しずつ書き換えさせ、テストを通るかを確かめながら、一区画ずつ置き換えていく。
この手順を眺めると、あることに気づく。AIが受け持つのは、最後の「書き換え」のところだけだ。その前の、何をしているのかを突き止め、隠れた依存をほどき、データの意味を確定させ、新しい構造を決める、といういちばん難しいところは、ぜんぶ人間がやっている。つまり、古いコードを別の言語へ作り直す作業の正体は、ほとんど設計のやり直しなのだ。設計と判断は人間、書き換えの手数はAI。この核心は、AIには丸投げできない。
だから「AIなら直せる」という言い方は、半分しか当たっていない。たしかに、書き換えの速さはAIのものだ。だが、何をどう直すかを決め、正しさを見張るのは人間で、そここそが設計の本体なのだ。丸投げが失敗するのは、AIの力不足ではなく、その設計を省いてしまうからだ。
しかも、これは古いCOBOLにかぎった話ではない。AIがすごい速さで書いていく新しいコードも、設計を抜きにして積み上げれば、やがて誰も全体をつかめない塊になる。作るのがAIで、直すのもAIだとしても、その「直す」に設計が要る以上、AIが書いたコードだって、放っておけば現代版のレガシーになりうる。「作ったそばから片づけられるから、負債は怖くない」という、さっきの期待。それは幻想の可能性が高い。
民主化が移すもの
ここまでは、道具やコードの話をしてきた。最後に、人の話をしたい。COBOLからいまのAIまで眺めてきて、改めて思うことがある。民主化が進んでも、専門性そのものは消えてなくならない。ただ、それを必要とする場所が、移っていくだけだ。
COBOLを思い出してほしい。英語で書けるようになっても、結局、現場の事務担当者が自分でシステムを作るようにはならなかった。仕事はむしろ、二つの層に分かれていった。一つは、込み入ったCOBOLのコードを書きこなす、専門の技術者の層*13。もう一つは、システムを全体としてどう作るかを決める、アナリストと呼ばれる設計側の層だ。プログラミングが易しくなったはずなのに、専門性は消えるどころか、一段上へとせり上がった。
同じことが、いま自分の身にも起きている。AIが日々のコードを引き受けるぶん、人間に回ってくるのは、何を作るかを決め、出てきたものを検証し、全体の整合を設計する役割だ。かつてのアナリスト、いまで言えばアーキテクトや検証者にあたる。「これからはコーダーよりアーキテクトだ」という話は、すでに多くの人が語っているし、この、プログラミングの重心がコードを書くことから設計・意図の定義へ移っていく、という話は、私自身、以前のブログ記事「Programming is Dead. Long Live Programming ー プログラミングは死なず。ただ老兵は去るのみ - Nothing ventured, nothing gained.」でも書いた。半ば定説になりつつあるのは承知のうえで、それでも書いておきたい。60年前にCOBOLが起こした職種の再編と、ほとんど同じことが、いままさに私たちのキャリアのなかで進んでいると言える。
ただ、一つだけ、引っかかることがある。その設計の力は、たいてい、自分で書いてはバグにやられ、なんとか抜け出す、その繰り返しのなかで身についてきた。だとすれば、その入口をAIが先に引き受けてしまったとき、次の世代の設計者は、どこで育つのだろう。
ホッパーならどう言うだろう
冒頭で、ホッパーの話をした。もし彼女がいまの光景を見たら、何と言うだろう。
彼女が夢見たかたちの民主化は、振り返れば半分しか実現しなかった。英語で書けるようにしても新しい専門家が必要になり、コードの多くは、彼女の死後、誰も触れない負債へと変わっていった。だが彼女は、その不完全さを誰よりも近くで見て、嘆く代わりに手を動かした人だ。さきに書いた標準化や検証、ドキュメント、そして再利用は、いま振り返れば、生成AIの時代にこそ効いてくる規律ばかりだった。
その彼女が、生前くり返した言葉がある。「言葉のなかでもっとも危険なのは、『これまでずっと、このやり方でやってきた』だ」*14。
だから、彼女ならきっと、いまのAIを誰よりも面白がって使い倒すだろう。古いやり方にしがみつくな、新しい道具を恐れるな、と。
ただ、彼女のことだから、こうも付け加える気がする。新しい道具に飛びつくことと、それを支える規律を引き受けること──その両方を、私はずっとやってきた、と。民主化されたあとに残る仕事とは、たぶん、そういうことだ。彼女が60年前にやっていたことを、こんどは私たちが、自分の番として引き受けることになるのだろう。
*1:「COBOLの母」と呼ばれるが、実際の文法を設計したのはホッパー本人ではない。軍と民間メーカーから集まったCODASYL短期委員会である（中心は6名、その中で中心的だったのがジーン・サメットだ。）。サメット自身、ホッパーはCOBOLの「母でも創造者でも開発者でもない」と述べている。とはいえ、ホッパーの思想と前身のFLOW-MATICがなければ言語は生まれなかった。
*2:ホッパーが英語ベースの事務処理言語の原型としたFLOW-MATIC（当初はB-0）は、1955年ごろに着手され、1950年代後半に完成したとされる。完成年は資料により幅があるため、単年での断定は避ける。
*3:1965年のハネウェルの社内報告書は、熟練アセンブリ技術者の書くコードのほうが当時のCOBOLコンパイラの出力より効率的だと認めつつ、そうした技術者を現場で確保できるのかを問い返している。
*4:私が受けた頃の情報処理技術者試験では、プログラミング言語をFORTRAN、COBOL、CASL（教育用の仮想計算機COMET向けのアセンブリ言語）の三つから選べた。CASLは実機ではなく試験用の仮想マシン向けで、そのままでは実務に使えない。私は研究で使っていたFORTRANを選んだ。
*5:ホッパーが1951〜52年にUNIVAC I向けに作ったA-0は、しばしば「世界初のコンパイラ」と呼ばれる（この称号には異説もある）。よく使う処理を「サブルーチン」としてテープに蓄え、呼び出し番号で取り出して組み合わせる仕組みで、コードを書き写さずに再利用する最初期の実装だった。
*6:初期COBOLには手続き間でパラメータを受け渡す方法がなく、サメットはこれを委員会の最大の誤りと評した。データへのアクセスを制限する仕組みもなく、事実上すべての手続きがグローバル変数を介してデータを読み書きした。
*7:ローカルなデータを持てる入れ子サブプログラムが導入され、この欠陥が解消された。
*8:ホッパーは1967〜77年に海軍プログラミング言語グループのディレクターとして、COBOLの標準化と、コンパイラが規格に適合しているかを検証するソフトウェアの整備を主導した。これによりメーカーごとの独自拡張（方言）の乱立は標準へ収束した。初期にはMark I用に詳細な操作マニュアルを自ら執筆するなど、ドキュメント文化の確立にも力を注いでいる。
*9:「デジタル・アスベスト（digital asbestos）」は英語圏メディアの言い回しだ。たとえば Wired の特集（2026年）が「かつて遍在し、いまや除去が極めて困難」という意味で用いている。日本語で定着した呼称ではない点には留保が必要。
*10:「2025年の崖」は経済産業省「DXレポート」（2018年9月）で言及されている。同レポートは、2025年に基幹システムの約6割が稼働から21年以上の老朽システムになると見積もった。普及率の数字は出典によって異なるが、世界の金融取引のかなりの部分がいまもCOBOLの上で動いているのは多くのレポートでも指摘されている
*11:2026年2月、AnthropicがClaudeでCOBOLコードを解析・変換できると発表した直後、IBM株が約13%下落した（2000年以来の下げ幅、月間では約27%下落）。
*12:「JOBOL」はJavaとCOBOLを掛けた蔑称で、COBOLを行単位でJavaに機械変換した結果、Javaの文法をまといながらCOBOLの手続き的構造をそのまま残してしまったコードを指す。オブジェクト指向の利点は得られず、保守には結局COBOLの知識が要るため「本末転倒」と評されている。
*13:COBOLは英語に近い構文を持ったが、コンパイラを動かすための厳密な形式は依然として要求した。結果として非専門家が自分でシステムを作ることはなく、冗長なコードを専門に扱う書き手の層が生まれた。
*14:ホッパーが好んで用いたとされる警句。「The most dangerous phrase in the language is, 'We've always done it this way.'」。変化を拒む組織の慣性を戒める文脈でくり返し語った
