生成AIストリーム
AI時代のWindows業務開発の過去未来（1） 『ニンゲツを終わらせろ！』
30年前の『COBOLのおじさま』に、俺は、なる！
2026年10月26日 18:47
窓の杜30周年、おめでとうございます。古いシステムに未来はあるのか。私は、あると考えています。ただし、人間が同じ手作業を何か月も繰り返すことを、未来とは呼びたくありません。今回は、AI技術の進化により度重なるセキュリティ攻撃「AIセキュリティストーム」のその真っただ中に迎えた窓の杜30周年に合わせて、私自身が1990年代から経験してきた業務システム開発を振り返りながら、生成AIが、その仕事をどう変えていくのかを全3回で考えてみたいと思います。
登場するのは、COBOL、巨大なホストコンピューター、ポケベル、Windows、UNIX、ASP、そしてJava。懐かしい名前が並びますが、昔話だけをするつもりはありません。かつて新しい技術に夢中だった若者が、いつの間にか、その技術を若いエンジニアに説明する側になっていた。そんな立場の逆転から、AI時代の開発を見つめ直す話です。
もう一つ、シリーズを貫く言葉があります。『付喪神』です。ここでは、長く使われた道具に何かが宿る、というイメージを業務システムに重ねています。最初から厄介者だったのではありません。誰かの役に立ち、工夫を重ねられ、なくてはならないものになった。その結果、簡単には手放せなくなった道具たちです。
最近『業務システムの付喪神を、AIコーディングで解体して欲しい』というコンサルティング依頼を受けることが多くなってきました。ただ、そう簡単にはいきません。必要なのは、最新の道具を揃えることだけでなく、古い道具が守ってきた仕事を読めること、そして解体速度です。全部が揃わないと終わりません。物語の始まりは、1999年の福島です。
ゲームを作るはずが、工場でCOBOLを書いていた
今でこそ生成AIクリエイティブメディア企業を日米で展開し、複数の大学で大学教員などもする“ハッカー作家”なのですが、1998年。大学院を出る頃、私はゲーム開発者になるつもりでした。大学ではCやC++で計測器を制御したり、画像処理や3DCGのプログラムを書いたり、DirectXやOpenGLを使ったリアルタイムCGに取り組んでいました。
ところが、教授の推薦で就職したメーカーで、情報通信システム本部の本部長に気に入られたこともあり、なぜか福島県の工場にある「事務管理課」へ配属されてしまいました。名前は事務ですが、実態は工場の業務IT部門。生産管理、部品の入出庫、在庫管理など、工場を動かすシステムを守る仕事です。これが産業というものなのですね。
時代はWindows95から98に移り変わる時代で、ちょっといいパソコンが25万円ぐらいしていた頃です。会社の経理部の隣には冷蔵庫よりも大きなホストコンピューターがあり、轟音を立てていました。オペレーターさんたちが専用端末や水平プリンターを操作し、決められた手順でホストコンピューターと共に業務を動かしていました。パンチカードといったデバイスもまだ現場に遺産として残っている時代です。私の仕事は『業務』を学びながら、部品庫に走って在庫管理システムを設計したり、ユーザーさんである生産管理部門のみなさんのお話を聞き、COBOLで書かれたプログラムをWindowsの「VDT」と呼ばれるターミナルから修正し、ジョブを投入し、夜間バッチが正しく動くかを確認することでした。
言語はCOBOLです。1950年代に生まれた事務処理向けの言語ですから、1999年にはすでに約40年の歴史がありました。私が小学生の頃に覚えたBASICより古い言語を、社会人になってから学ぶことになったのです。そして周囲には、そのCOBOLとホストコンピューターを長年守ってきた先輩エンジニアたちがいました。今回は親しみと敬意を込めて、『COBOLのおじさま』と呼ぶことにします。
当時の私は、正直に言えば『どうしてこんなに古いものを使っているんだろう』と思っていました。ゲームやCGの世界では、新しい技術を覚えることが、そのまま表現できる世界の広がりにつながっていたからです。しかし工場では、昨日まで動いていたものを、今日も明日も動かすことに大きな価値がありました。
『ニンゲツ』という不思議な単位
企業の情報システム部門に入って驚いたのが、『人月（ニンゲツ）』でした。『この改修は10人月です』と言われる。1人で10か月分の作業量、ということなのでしょう。しかし、それなら10人集めれば1か月で終わるのでしょうか。
みんな同じ速度でプログラムを書くわけではありません。書く前に問題を解いてしまう人もいれば、そもそも書かなくて済む方法を見つける人もいます。コードの行数と人月で開発の大きさを語る世界に、私は戸惑いました。
もちろん、仕事はプログラミングだけではありません。仕様を確認し、関係部署と調整し、テストを行い、承認を得て、運用手順を整える。予算や工程を管理するために工数が必要なことも、仕事を通じて学びました。それでも、『人がどれだけ働いたか』と『どれだけ問題を解決したか』は同じではない、という違和感は残りました。
興味深いことに、その職場にはコードを生成する仕組みもありました。CASE、Computer-Aided Software Engineeringと呼ばれる開発支援の世界です。私が見たものでは、業務の定義を登録すると、そこからCOBOLのプログラムが生成されていました。方眼紙の資料とExcelの資料が混在する現場で、人間がすべてのコードを手書きしない仕組みが動いていたのです。
生成AIとは原理が違います。しかし、上位の定義からプログラムを作るという発想は、すでにありました。2026年のAI駆動開発を見ていると、この光景を思い出します。人間は昔から、もっと少ない手作業で、自分たちの仕事をコンピューターに伝えようとしていたのです。
早く解いた人の時間にも価値がある
同じ問題を、ある人は1週間で解き、別の人は半日で解く。その差を生んだのが、長年の経験と、自分で作り込んだ道具だったらどうでしょう。半日で終わった人の仕事は、1週間かかった人より安いのでしょうか。
AI駆動開発では、この問いがさらに切実になります。調査のためのスクリプトを作る。繰り返し現れる構造を見つける。変更前後を比較する仕組みを組む。その結果として短くなった時間は、技術者が何もしていなかった時間ではありません。仕事の進め方を変えた成果です。
ところが、速くできた分だけ別の作業を積み、予定よりも大幅に前倒して付喪神の解体に成功したとしても、次の契約では『AIなら半分の時間でできますよね』と言われてしまう。なんなら、同じチームの別の方がそのプロンプトや開発手法を利用する。全く同じにはならないけど、なんとなく進行はする。つまりアーキテクチャーを改善した人ほど、自分の稼働枠と知識を安く提供することになります。これでは誰も『自分の仕事を速くおわらせて、付喪神を解体して新たな価値を生む仕組み』に投資できません。
もちろん『ニンゲツ（人月）』にもいいところはあります。毎月就職活動や契約や営業をし続けなければならない環境では大きな技術は育ちません。『今月はそんなに忙しくないけど、勉強しておいてね』という時間がシステムエンジニアには必要なのです。私が問いたいのは、何時間座っていたかに加えて、何を解明し、何を減らし、次の変更をどこまで容易にしたか、そしてそのエンジニア組織が育ったか？を評価できるか、ということです。人の時間を大切にするなら、短くできた理由にも対価を払いたい。その方が、次の改善に踏み出せると思うのです。当たり前のことかもしれませんが。このAIセキュリティストームが続くなか、IT業界の若きエンジニアたちが良い学びをしてくれることを祈ってこれを書いています。
Y2Kとポケベルが教えてくれたこと
1999年の大仕事が『Y2K』、2000年問題でした。西暦を下2桁で扱うシステムでは、『99』の次の『00』をどう解釈するのかが問題になります。『年を4桁にすればいいじゃないか』と思うでしょう。ところが日付は、画面だけでなく、固定長ファイル、データベース、帳票、夜間バッチ、他システムとのデータ交換に埋め込まれていました。
固定長ファイルの項目を2文字増やせば、その後ろに並ぶ項目の位置も変わるかもしれません。年号を比較する処理や、過去と未来を判定する条件も調べなければなりません。『たった2桁』を直すために、業務のつながりを追い直す必要があったのです。
多くの人が改修と検証を行い、世紀の変わり目を迎えました。米国の会計検査院GAOも、2000年1月の報告で『対策を経た年越しの混乱が限定的だった』と報告しています。歴史上『何も起きなかった』ことは『何もしなくてよかった』ことの証明にはなりません。多くのIT戦士たちが、家族に『ごめん！』を言って、年末年始を捨てて戦ったのです。
私の毎日は、もっと身近な『止められない仕事』とつながっていました。夜間バッチに問題が起きると、ポケットベル、通称ポケベルで呼び出されます。冬の福島で雪が降っていても、工場へ駆けつける。分厚いマニュアルを開いても、目の前の障害の答えが書いてあるとは限りません。
私自身、呼び出しに気づかず寝過ごし、障害対応を遅らせたことがあります。部品庫の着荷処理が止まり、トラックが滞り、工場周辺の道路にまで影響が広がりました。画面の中のエラーが、現実の物流を止める。そのことを、痛いほど思い知らされました。映画『サマーウォーズ』のような事態は、実際に起きるのです。
一方、職場にはLinuxを熱心に触る先輩もいました。窓のないサーバー室の古いPCにこっそりインストールし、フォーマットして、またインストールする。『あのUNIXがタダなんやで』と新人が30年前の業務システムを運用している横で、ずいぶん楽しそうです。『いいなあ。こっちも面白いことをやりたいのに』と、夜間処理の合間に使える機材で別の技術を学んでいました。新しいOSを試したい人と、今夜のバッチを止められない人。いまのAIコーディングを業務の傍で楽しんでいる先輩と新人でも同じ景色がありそうです。同じ職場で、違う未来を見ていました。
『Webで作ればいいじゃん！』という革命
そんな私が夢中になっていたのが、Windowsで動く「ASP」（Active Server Pages）でした。現在では「ASP.NET」と区別するため、「Classic ASP」とも呼ばれています。1996年12月、Windows NT Server 4.0向けの「IIS 3.0」とともに登場した技術です。2026年には、こちらも30歳になります。HTMLにVBScriptなどのスクリプトを埋め込み、サーバー側で処理してWebページを作る。大学時代にPerlでCGIを書いていた私には、WindowsのデータベースやコンポーネントとつながるASPが、とても魅力的に見えました。
Windows NT Serverでは「IIS」を使い、Windows 98では「PWS」（Personal Web Server）を導入して試すことができました。そうです。夜間処理のスキマ時間に手元のWindowsで本格的なWebアプリケーションを作り始められることには、大きな意味がありました。
当時は『クラサバ』、クライアントサーバー型の専用アプリケーションを、それぞれのPCに配布する開発が本格的な業務アプリケーションの主役でした。もちろん専用アプリケーションが適した用途はあります。しかし、データベースの一覧を表示する、条件を指定して検索する、申請を入力する。その程度の画面なら、Webブラウザーで十分なのではないか……。
サーバー側を直せば、利用者は同じURLから変更後の画面を使える。ブラウザーの互換性という別の課題は残りますが、端末ごとに専用ソフトを配り直す手間は減らせます。『Webで作ればいいじゃん！』。私には、それが革命に思えました。
「BASP21 DLL」のような個人の開発者が作った便利なCOMコンポーネントもありました。メール送信やファイル操作などを部品に任せ、短いスクリプトを組み合わせてゲームやツールを作っていく。私は「ASP」に夢中になるあまり、解説書まで書き始めました。初めての商業書籍企画です。出版社と話を進め、かなりの量を書いたものの、結局その本は出版されませんでしたが。
それでも、身につけた知識は残りました。その後ゲーム開発の世界へ戻ってからも、Webで画面とデータをつなぎ、人の仕事を道具にする経験は役に立ちました。未刊の原稿は本棚に並びませんでしたが、地方工場での修行時代から脱出し、再びゲーム開発者として東京に戻ってくるモチベーションを維持できたのは、「ASP」のおかげです。学び続けて、業務を改善する。そのマインド、スピリッツ、そして学ぶ姿勢はいまでもずっと現役です。
『EUC』といえば、どっちの『EUC』？
当時の業務システムを振り返るなら、もう一つ忘れられない言葉があります。『EUC』です。業務の現場でいう『EUC』は、エンドユーザーコンピューティング（End User Computing）。現場の利用者自身がコンピューターを使い、「Excel」や「Access」などで、自分たちに必要な集計や小さな業務ツールを作る考え方です。専門部署に何でも依頼するのではなく、自分たちの仕事を自分たちでも改善していく。
ところが、UNIXを触る技術者にとっての『EUC』は、Extended Unix Code。日本語ならEUC-JPという文字コードの話です。同じ『EUC』なのに、片方は推進するもの、もう片方は変換するもの。『EUCを進めよう』『そうですね！』と言われて、業務改善の相談なのか、文字コード変換の相談なのか、一瞬考えてしまいます。
そして、この2つは意外なところでつながりつづけています。現場の工夫で作り込んだ業務ツールを引き継ごうとすると、そこには仕事のルールがあり、巨大なデータベースがあり、さらにUnicodeやSHIFT-JISといった文字コードがあります。仮に「Claude Code」を使いこなす若者が業務やアルゴリズムやフロントエンドだけわかっても、データベースが重くてうまく引き継げない。システムはどんどん大規模になる。AI時代のエンドユーザーコンピューティングも同じ問題を抱えていて、良くも悪くもベンダーロックインを生んでおり、最近では『SaaS不要問題』へつながっています。
クラウドに引っ越した付喪神もいる
2026年、長く使われてきた業務システムを考えるとき、例えばこんなものを想像してください。従業員管理システムや取引先マスタ。1990年代に完成し、その後も改修されてきた部品庫管理システム。医療機器や計測機器に付随するデータ管理・解析ソフトウェア。学校の卒業生の名簿。Accessで作られ、少しずつ機能が増えてきたデータベース。ユーザー部門が少ない、特殊業務、すごく稼ぐわけではない、でもなくなると困る。
そういえば「Access 2021」は2026年10月13日にメインストリームサポート終了しました。延長サポートは提供されないので「Access 2024」（Office LTSC 2024）の契約が必要です。そんな大規模な業務じゃないし、そんな大規模な会社なら他のデータベースシステムを使っています。そのためにサポートが終わったWindowsマシンやクラウド内にひっそりと古いWindowsサーバーのリモートデスクトップが動いているかもしれません。機器が動いていても、データを取り出せなければ仕事にならない。そんな道具は、画面の古さだけを理由に捨てられません。懐かしい懐古の道具をさわれる『令和版COBOLのおじさま』に仕事はあります。
しかも、付喪神の住まいは古いWindowsだけではありません。サーバーサイドJavaやPHPもAWSやGCP、Azureに引っ越しをして、仮想マシンやマネージドサービスといったクラウドに棲みついています。サーバーは新しくなった。でも、仕事のルールは古いままかもしれない。付喪神もクラウドへ引っ越すのです。
1999年、私はCOBOLを見て『なぜこんなに古いものを』と思いました。ASPやPHPに引っ越しました。いま、若いエンジニアがASPや古いJavaのコードを見て、同じことを考えているかもしれません。ようやく、COBOLのおじさまたちの立っていた場所が見えてきました。
そして今、猛烈なAIセキュリティストームが、このレガシーの森を焼き払っています。
ニンゲツの神話、そして伝説へ。
「Claude Mythos」「Claude Fable」という神話と寓話の時代の後、予言通り『AIセキュリティストーム』がやってきました。
ついに首相がPHPの脆弱性注意喚起をする時代です。それぐらい深刻です。
皆様に、今夜に対応して頂きたい大至急のお願いです。
多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。
公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。
修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。
国家サイバー統括室のXアカウントでも関係する情報を発信していますので、そちらも参考にして下さい。
— 高市早苗 (@takaichi_sanae)October 21, 2026
国家サイバー統括室(注意・警戒情報)（@cyber_forecast） / X
PHPやWordPressは私が業務IT部門で奮闘していた頃よりもちょっとあとの2003年以降の話ですが、便利な道具には付喪神がつくという法則は変わりません。この豊穣な日本の『ITの杜』に棲んできた付喪神にも火の手が迫っています。解体にも、お金と時間がかかります。古いコードを読み、依存関係を調べ、仕様を整理し、動作を確かめる。そこで再び、『何人月かかりますか』という話になります。1999年の私が戸惑った『ニンゲツ』への問いは、2026年にも健在です。
この問題を、半世紀も前に指摘した人がいます。フレデリック・P・ブルックス Jr.。1975年に初版が刊行された『人月の神話（The Mythical Man-Month: Essays on Software Engineering）』の著者です。同書には、後に『ブルックスの法則』として知られる一節があります。
Adding manpower to a late software project makes it later.遅れているソフトウェア開発プロジェクトに人員を追加すると、さらに遅れる。（筆者訳）
『人月の神話』より引用
人を増やせば、それまでの事情を説明する時間が必要になります。仕事を分け直し、担当者同士で調整し、最後に組み合わせて確かめる仕事も増える。人数と月数は、掛け算の上では交換できても、実際の開発ではそう簡単に交換できません。
では『AI駆動開発時代』、人間の代わりにAIを増やせば、この問題は解決するのでしょうか。「Claude Code」のようなAIコーディングツールは、コードを読み、ファイルを編集し、コマンドを実行し、テストを動かすところまで開発に参加します。私自身、仕事で日常的に使っています。しかし、AIが書いたものを人間が一つずつ読み、同じ事情を何度も説明し、食い違いを直し続けるなら、人間の側に仕事が積み上がります。『ニンゲツ』を『AIの稼働時間』に置き換えただけでは、解けない問題があるのです。
まずは単純にClaudeのトークンが跳ね上がります。1人月の開発者が1人月以上のAI予算を使うようになりますが、そのハンドルは誰が持つのでしょうか。優秀なAI時代のアーキテクトやオフィサーが必要ですが、それはAIには務められません。業務を知らないからです。AIに業務を伝え、何を守り、何を変えるかを判断する人が必要です。
私はここに大きな可能性を感じています。1999年の工場にも、業務の定義からCOBOLを生成する仕組みがありました。人間がすべてを手書きする以外の方法を、先輩たちはすでに持っていた。いまは、その仕組みを作るところからAIと一緒に考えられます。何時間かけたかに加えて、次に同じ仕事をしなくて済むよう、何を残したか。どんなトラブルが起きるのか（起きてきたのか）そこまで含めて技術者の仕事をアサインしたり評価できれば、早く解いた人やAIが、次の改善にも取り組めるはずです。私が『ニンゲツを終わらせろ！』と言いたいのは、そんな開発へ進みたいからです。
ただし、その前にやることがあります。目の前の古いシステムにも、火の手が迫っています。まだまだ成長し続けるAI技術の攻撃に対して先を見て適切に鎮火し、場合によっては伐採することで延焼を止め、その現場検証を手早く進め、何をしているのかを組織全体が知ることです。画面の古さや「Microsoft Edge」のIEモード限定といったUXはユーザーの印象を悪くします。
せめてデジタル庁のデザインシステムを使いましょう。移植先の開発言語で迷ったらTypeScriptやPythonを選んでおけば大丈夫でしょう。コードの書き方はもはや本質ではありません。ソースコードが残っていればドキュメントは操作マニュアル以外は不要かもしれません。いや、AI開発ホワイトハッカーからすれば、ソースコードが残っていなくても、できることはいっぱいあるのです。作ればいいのですから。このあたりのテクニックは次回以降で紹介していきたいと思います。
30年前のCOBOLのおじさまへ。あなたたちが守っていたのは、COBOLという言語ではなく、明日の朝も工場が動くという約束だったのですね。あの頃、私が未来だと思っていたASPやPHPやJava、ExcelのVBAにも、いつの間にか付喪神が宿っていました。今度は、私がその付喪神を解体して、TypeScriptやPythonやMarkdownやHTMLに書き換える番です。隣には、AIという新しい相棒がいます。まずはセキュリティ攻撃の嵐の中、若手と一緒に、古いシステムを開いてみましょう。そこにはきっと、当時の私にもあなたにも見えていなかった仕事が残っています。
※本稿と挿絵は筆者の回想をもとにした再現イメージです。会話・情景には筆者の主観と、機密保持に配慮した最小限の演出を含みます。
