永遠の誓約：プログラマ排除への試みの歴史

Japanese Translation:

ソフトウェア作成ツールは、1959年のCOBOLから今日の大型言語モデル（LLM）まで、何度もプログラマを置き換えると約束してきました。しかし、各波—COBOL、初期AIおよびエキスパートシステム、第四世代言語（FOCUS、PowerBuilder、Microsoft Access）、CASEツール、ノーコード/ローコードプラットフォーム、ウェブビルダー（Dreamweaver、WordPress、Wix）、MDA/UML、およびLLM—は最終的に熟練した開発者の必要性を残しました。
歴史的なサイクルは、新技術が参入障壁を下げる一方で、隠れた複雑さや非効率性をもたらすことを示しています。COBOLは新しいプログラマ層を創出しました；初期AIの楽観主義（1965–1973）は、Lighthill報告書がハイプと実際の能力とのギャップを露呈した後にAIウィンターへ終わりました；4GLはユーザー主導開発を約束しましたが、複雑なロジックには専門的な開発者が必要でした；CASEツールは膨大なコードを生成し、エキスパートシステムは脆弱なルールベースに苦しみました；ウェブビルダーはJavaScriptフレームワークとモバイルデザインの層を追加し、専門知識を要求しました；MDA/UMLは同期化と保守の問題に直面しました。
LLMは自然言語から機能的なコードを生成でき、日常生産性を向上させますが、それでも正確性、安全性、性能、および複雑な統合で苦労します—これにより、意図を信頼性の高い効率的なソフトウェアへ翻訳するという核心課題は、自動化だけでは解決されていないことが明らかになります。
したがって、エンドユーザーは簡単にアプリを作成しプロトタイピングを高速化できますが、企業は品質の高いシステムを維持するために熟練した開発者に投資する必要があります。企業は統合・ガバナンスと自動化と建築判断を組み合わせたハイブリッド役割へリソースを移行し、深い専門知識への需要が安定していることを確保するでしょう。

ソフトウェアの歴史を振り返ると、驚くほど一貫して現れるパターンがあります。それは「ソフトウェア作成を簡素化し、コストを削減し、最終的にはプログラマ自体を不要にする」という約束です。これは新しい考えではありません。1960年代から業界の推進力となってきました。そして各世代が前例のないものを目撃していると信じている一方で、実際には過去60年以上繰り返されてきたサイクルに参加しているのです。

今日、大規模言語モデルがコードを書き、AIアシスタントが開発者とペアプログラミングを行う中で、私たちは同じフレーズを耳にします。すなわち「従来のプログラミングは終焉を迎える」「ソフトウェア開発は民主化される」「まもなく誰でも1行コードを書かずに複雑なシステムを構築できる」というものです。これらの主張は完全に誤っているわけではありませんが、1959年、1973年、1985年、2015年に語られた約束と同じリフレインを鳴らしています。この歴史を理解することは、現在私たちがどこにいて、将来どこへ向かうのかを把握しようとする人々にとって不可欠です。

1. 原罪：COBOL とビジネスユーザーの夢

1950年代後半、プログラミングは本当に奥深く、アセンブリ言語や機械語でレジスタやメモリアドレスを直接操作していました。企業はソフトウェアが必要でしたが、ビジネス問題を理解する人々はコンピュータをほとんど知らず、その逆もまた同様でした。

そこでグレース・ホッパーとCODASYL委員会が登場しました。1959年に彼らは COBOL（Common Business-Oriented Language）を創造しました。明確な目標は革命的でした：英語に極めて近いプログラミング言語を作り、ビジネスマネージャーが読み取り、理解し、最終的には自ら書けるようにすること。構文は意図的に冗長で、暗号化された記号の代わりに MOVE、ADD、MULTIPLY、PERFORM といった語を使用しました。プログラムは事務メモのように読めました。

マーケティングは明白でした：COBOL は専門的なプログラマというボトルネックを排除し、ビジネスアナリストが自らプログラムを書けると宣言しました。技術者の聖職者集団は解散され、ソフトウェア作成は民主化されるはずでした。

しかし実際にはそうなりませんでした。COBOL は驚異的に成功し、銀行・保険・政府システムの基盤となりました。何十億行もの COBOL コードが今日も稼働し、数兆ドルの取引を処理しています。しかし COBOL はプログラマを排除せず、新たな職業「COBOL プログラマ」を生み出しました。読みやすさはあっても、正しく効率的で保守可能なコードを書くには専門知識が必要でした。

皮肉なことに、プログラマ不要という目的で作られた言語が、コンピューティング史上最も長く続く雇用創出源の一つとなりました。今日、COBOL プログラマは希少性とシステムの重要性から高需要にあります。

2. 第一の AI ウィンター：専門家システムと1970年代のハイプサイクル

1960年代から70年代初頭にかけて、人工知能への楽観が爆発し、現在の予測はそれを比べると控えめでした。1965年にヘルバー・サイモンは20年以内に機械が人間が行えるあらゆる仕事をできると予言し、1967年にはマーヴィン・ミンスキーが世代内で AI の問題が大幅に解決すると予測しました。DARPA などから資金が流れ込みました。

ソフトウェア開発への影響は革命的と考えられていました。機械が思考できれば、自らプログラムを作れると信じられ、自然言語仕様を動くコードに変換する自動プログラミングや専門家システムが研究されました。専門家システムはルールベースのエンジンで人間の知識を捉え、人の介入なしに意思決定と問題解決を行うことを約束しました。

しかし1973年のリトウィル報告により、英国では AI 資金が打撃を受けました。実際の複雑さに対して理論的な期待は大きくずれ、AI ウィンター（資金崩壊・研究プログラム停止）が訪れ、「人工知能」という言葉自体が一部で恥ずかしいものとなりました。

教訓は明確でした：人間の意図を動くソフトウェアに変換することは根本的に難しい。自然言語仕様と正確な実装とのギャップは、人間コミュニケーションとソフトウェア複雑性について深い真理を示しています。

3. 第四世代言語：1980年代の約束

1980年代初頭、第四世代言語（4GL）が新たな希望として登場しました。第一世代はアセンブリ、第二世代は FORTRAN と COBOL、第三世代は Pascal や C のような構造化言語でした。第四世代はさらに複雑さを抽象化し、非プログラマが高レベル宣言でアプリケーションを作成できると主張しました。

FOCUS、NOMAD、Ramis、PowerBuilder、Microsoft Access といった製品はソフトウェア開発の革命を約束しました。コードを書かずにデータ構造を定義し、ビジネスルールを指定し、グラフィカルインターフェースで画面を設計することで、基盤となるコードが自動生成されます。マーケティングは今日のノーコードプラットフォームと驚くほど似ており、「エンドユーザーが自身のアプリを構築し、IT 部門はボトルネックではなく支援者になる」というものでした。

4GL は報告生成や単純なデータベースアプリケーションなど特定領域で真に成功しました。Microsoft Access は数百万人が従来のプログラミングなしで機能的なアプリを作ることを可能にしました。しかし、複雑なアプリは依然として高度な思考を必要とし、パフォーマンスや統合が重要になると 4GL の限界が明らかになりました。生成コードは非効率でカスタマイズが困難でした。

再び同じパターン：プログラマを排除すると約束したツールは、新たなカテゴリのプログラミング作業を生み出しました。

4. CASE ツールと「大聖堂ビルダー」

1980年代後半から1990年代初頭にかけて、Computer‑Aided Software Engineering（CASE）ツールが台頭しました。全体像を図や仕様でモデル化し、ツールが完全な動作アプリケーションを生成するという包括的ビジョンでした。企業は数百万ドルを CASE スイートに投資し、会議が開催され、メソッド論が開発されました。

プロジェクトは数か月間モデリングフェーズで膨大な文書化を行い、すべての要件と設計決定を捉えることを目指しました。コード生成はこれらのモデルから動作システムへ変換されました。しかし実際には生成されたコードは肥大し非効率で、要求変更に伴うモデル保守が困難でした。また仕様を正しく得ること自体が直接コードを書くのと同じくらい難しかったです。図表やモデルはテキストではなくボックスと矢印という別の「プログラミング言語」になりました。

1990年代半ばになると CASE ツールは徐々に影を潜めました。一部の概念は Rational Rose のようなオブジェクト指向分析・設計ツールに残りましたが、仕様から自動コード生成という大きなビジョンは幻滅しました。

5. 第二の AI ウェーブ：専門家システム再来

1980年代もまた、専門家システムへの第二波の熱狂を見せました。Inference Corporation、Intellicorp、Teknowledge といった企業が医療診断や金融分析、機器設定、自動プログラミングなどでルールベースシステムに人間の知識を集約すると主張しました。日本の第五世代コンピュータプロジェクト（1982年開始）は論理プログラミングを用いた推論可能なコンピュータ作成を目指しました。

1990 年までに第五世代プロジェクトはほぼ失敗し、専門家システムは脆弱で予期せぬ状況で失敗し、ルールベースの保守が難しくなりました。知識取得――人間の専門家から機械が利用できる形で知識を抽出する―という根本的課題は想定以上に困難でした。

1990 年代初頭に第二の AI ウィンターが訪れ、資金は再び崩壊し、研究者は仕事をリブランドしました。機械が自らプログラムできるという約束は未来へと沈みました。

6. インターネット時代：ウェブ開発と民主化の夢

1990 年代中頃に World Wide Web が登場し、ソフトウェア作成の簡素化への新たな希望が生まれました。HTML は誰でもウェブページを作れるほど単純だとされ、多くの人がテキストエディタと決意だけで基本的なサイトを構築しました。しかしウェブはすぐに複雑化し、JavaScript がインタラクティビティを、CSS がスタイリングを、サーバー側プログラミングやデータベースがコンテンツの裏付けを必要としました。セキュリティとパフォーマンスも重要になりました。

Dreamweaver、FrontPage、WordPress、Wix といったツールは「誰でもコードを書かずにプロフェッショナルなウェブサイトを構築できる」と約束しました。コンテンツ管理システムは多くの複雑さを抽象化しましたが、専門的なウェブ開発はむしろより複雑になりました。単一ページアプリケーション、モバイルファースト設計、プログレッシブウェブアプリ、現代 JavaScript エコシステムの台頭により、新しい専門家層が必要となりました。

パターンは続きます：基本タスクを簡素化するツールはより野心的なプロジェクトを可能にし、それにはさらに高度なスキルが求められ、結果として特定の専門家への需要が増加します。

7. モデル駆動アーキテクチャと UML の夢

2000 年代初頭、Model‑Driven Architecture（MDA）が再び自動コード生成を試みました。Object Management Group はプラットフォーム非依存モデルを提案し、ツールでそれらをプラットフォーム固有実装へ変換できると主張しました。UML が標準表記となり、Rational Rose、Together、Enterprise Architect といったツールは UML 図から完全なアプリケーションを生成すると約束しました。

MDA はモデルからコードへのマッピングが十分に理解されている特定領域で成功を収めました。しかしほとんどのアプリでは、モデルとコードの同期を保つことが難しく、モデル自体が複雑になり専門的スキルが必要でした。2010 年代には MDA は主流から退きましたが、その概念は現代のコード生成やドメイン固有言語に影響を与え続けています。

8. ノーコード・ローコードの復興

2015 年頃から Bubble、Webflow、Airtable、Zapier、Microsoft Power Platform といったノーコード／ローコードプラットフォームが登場しました。マーケティングは過去世代の約束を鏡写ししており、「ビジネスユーザー自身がアプリを構築できる」「IT のバックログが消える」「デジタルトランスフォーメーションが加速する」「プログラマは不要になる」などと宣言しました。

ノーコードツールは自らの領域で真に成功しています。単純なアプリ、ワークフロー自動化、基本的なウェブサイト、社内ツールを従来より高速に構築できます。しかしパターンは続きます：複雑なアプリは依然として高度な思考を必要とし、要件がプラットフォームの範囲を超えると壁に直面します。既存システムとの統合も困難であり、大規模展開時のパフォーマンス問題もあります。最も洗練されたユーザーは、多くの場合元々の開発者で、基盤となる原理を理解しています。

重要なのは、ノーコードが従来型の開発者需要を減らしていないことです。むしろデジタルアプリケーションの爆発的増加により需要は拡大しています。ソフトウェア開発者市場は成長し続けています。

9. 大規模言語モデル：現在の波

GPT‑4、Claude、Gemini のような大型言語モデル（LLM）は自然言語記述から機能的コードを生成できます。GitHub Copilot や類似ツールはリアルタイムで開発者を支援し、補完やボイラープレート生成を提案します。改善は実際に顕著です。

予測は大胆です：プログラミング職は消滅し、ソフトウェア開発は民主化され、誰でも英語で説明すれば複雑なシステムを構築できると主張します。1959 年の COBOL、1973 年の専門家システム、1985 年の 4GL、1995 年の CASE ツール、2015 年のノーコードに似たパターンが再び登場しています。

ただし現在の波は完全に同一ではありません。LLM は前例のない実力を示しており、生成されるコードは正確で有用な場合が多いです。生産性向上は現実的です。しかし根本的課題――人間の意図を正しく、効率的に、保守可能かつ安全に実装すること――は変わりません。

10. なぜ約束は常に外れるのか

ソフトウェアは単なるコードではなく、すべての条件下での振る舞いを正確に定義した仕様です。たとえば「シンプルな e‑commerce アプリ」を要求すると、暗黙的に数千の決定（認証、支払処理、在庫管理、配送計算、税金処理、エラー復旧、アクセシビリティ、負荷時パフォーマンス、攻撃対策など）が含まれます。

コーディングそのものが難しいわけではなく、「ソフトウェアは何をすべきか」を正確に把握し、全条件下でそれを実行することが課題です。したがって仕様言語や自動生成ツールはコードから複雑さを移動させるだけであり、仕様自体の難易度は同等かそれ以上です。

ソフトウェアはエコシステム内に存在します：他のソフトウェアと統合し、要件変更に適応し、進化するプラットフォーム上で動作し、変化するユーザー要求を満たす必要があります。長期的な保守・進化には仕様言語や生成ツールを超えた理解が不可欠です。

最後に、ソフトウェアはパフォーマンス対保守性、セキュリティ対使いやすさなどのトレードオフを反映します。これらは文脈・優先順位・価値観によって左右される判断であり、自動化できません。

11. 実際に変わるもの

各波が約束したことと実際の違いは次の通りです。

波	約束	実際
COBOL	プログラマ不要	ビジネスプログラミングを容易にし、巨大な職業市場を創出
4GL	従来言語代替	特定領域で迅速開発を可能にしたが、複雑化では限界
ノーコード	開発者不要	非専門家がツールを使えるようになったが、熟練開発者は依然必要

パターンは一貫しています：簡素化ツールは単純タスクの壁を下げることで総ソフトウェア量を増やし、その結果としてより高度なソフトウェアとより高度な開発者への需要が生まれます。失敗ではなく、技術進化の典型です。

12. 歴史から学ぶべきこと

極端な予測に対する懐疑：プログラミングの消滅という主張は過去数十年で何度も繰り返され、実際より変化を過大評価しています。
実質的改善は存在：LLM は開発者の生産性向上に寄与します。過去のバズと混同して無視するべきではありません。
プログラミング作業は進化し続ける：将来の開発者は現在とは異なる仕事を行いますが、消えることはありません。
人間のスキルは不可欠：要件理解・設計判断・デバッグ・保守・ステークホルダーとのコミュニケーションは自動化できません。
基礎知識は価値あるまま：アルゴリズム、データ構造、システム設計、ソフトウェアアーキテクチャは世代を超えて重要です。

13. 結論

最も重要な教訓は「理解に置き換わるものはない」ということです。COBOL の成功にはビジネスプロセスの理解が不可欠でしたし、4GL でもデータベースとアプリケーション設計を知っていなければなりませんでした。ノーコードプラットフォームでもワークフロー設計やシステム統合を把握する必要があります。AI コード生成でもソフトウェア原理、コード品質、システム設計を理解しないと不具合が増えます。

ツールは変わり、言語は進化します。プラットフォームは更新され続けます。しかし「何を作っているのか」「なぜそれを作る必要があるのか」を深く理解できる人材への需要は常に残ります。ソフトウェアは凝縮された思考です。良いソフトウェアを生み出すには優れた思考力が不可欠であり、どんなツールもそれを代替することはできません。

14. 未来への視点

歴史から得られる洞察：

AI ツールはますます強力になります。
革命的変化の約束は多く存在しますが、しばしば外れます。
ソフトウェア作成の根本課題――信頼性・効率・安全性を確保する――は変わりません。

この挑戦はコードを書くことではなく、クリアに考え、正確に伝え、不確実性下で良い判断を下すことです。これらは人間のスキルとして長期的に価値があります。プログラマが消滅したという報告は過去 60 年以上にわたり大げさに語られてきました。この回も例外ではありません。深い理解を持つ者は、どんなツールが登場しても常に需要があるでしょう。