「ノーコード」「ローコード」という言葉を、最近よく目や耳にするようになりました。「プログラミングの知識がゼロでも、ドラッグ＆ドロップだけでアプリが作れる」「コードを一行も書かずに本格的なWebサービスが開発できる」「これでエンジニアは不要になる」――そんな言葉を見聞きした方も多いのではないでしょうか。しかし、歴史を見るとノーコードやローコードは突然生まれた流行ではないことがわかります。むしろ、コンピュータが誕生した1940年代から現在に至るまで、人類は一貫して「機械の言葉ではなく、人間に近い言葉でシステムを作りたい」つまり、ノーコードの夢を追い続けています。そこで今回は、AI時代を迎えた今、過去に何度も繰り返された「エンジニア不要論」とは何かを考え、ノーコードの歴史をたどってみたいと思います。
- もくじ
1.1950年代から続く「コードを書きたくない」考えの流れ
1-1.機械語から高級言語へ
コンピュータ誕生の頃、プログラムを書くとは、「0」と「1」の数字の羅列である「機械語（マシン語）」を直接入力することを意味しました。ENIAC（1945年）の時代には、配線を物理的に差し替えることで動作を変えるほど原始的な作業でした。1950年代に入るとアセンブリ言語が登場し、記号を使って命令を表現できるようになりましたが、依然としてハードウェアに直結したレベルの世界でした。
転機となったのが「高級言語」の登場です。1957年にFortran（フォートラン）が誕生し、数式をそのままプログラムとして書けるようになったのです。「X = Y + Z」のような数学的な表現で、機械語なら数百行分におよぶかもしれない処理がたった数行に圧縮できたのです。人間にとって意味不明な暗号から、少しだけ「人間の言葉」に近づいた高級言語への進化こそが、ノーコード思想の出発点といってよいと思います。
考えてみてください。「01010000............」の機械語が「コード」だとしたら「X = Y + Z」は見方によっては立派な"ノーコード"ではないかと思えます。コンピュータの都合に人間が合わせるのではなく、コンピュータを人間に歩み寄らせるという考え方がノーコードの基本ではないかと思うからです。そしてこの流れは現代まで脈々と受け継がれています。
1-2.1959年RPGとCOBOL
1959年は、ノーコードの歴史において特別な意味を持つ年です。この年、IBMがビジネス帳票の作成に特化した「RPG（Report Program Generator）」をIBM 1401向けにリリースしました。RPGは、列指向の固定形式で条件を記述するだけで、パンチカード処理を置き換え、会計業務を劇的に効率化した言語です。ゲーム（Role-Playing Game）と略表記が同じなので注意が必要です。そのため、IBM RPGと記述されることも多いようです。
同じ1959年、グレース・ホッパーらがCODASYLに参加し、「COBOL（Common Business Oriented Language）」の策定に取り組みました。COBOLは「ADD A TO B GIVING C（AとBを足してCにする）」のように英語の構文に近い形でプログラムを書けるよう設計されており、国防総省の支援を受けて標準化が進み、銀行や保険業界で爆発的に普及しました。
さらに1964年には、Dartmouthのジョン・ケメニーとトーマス・カーツが学生向けに「BASIC」を開発しました。「10 PRINT X」「20 GOTO 10」のようにシンプルな記述で、家庭用PCの入門言語として広く普及し、日本でもNECのパソコン「PC-8801」などにROMで搭載され、爆発的にヒット。「マイコンブーム」「BASICブーム」を起こします。このブームでBASICに触れ、エンジニアとなった人も多く、世界のIT技術の基盤を築くことに直接・間接的に貢献しました。
ここで見てきた言語はどれも「英語でプログラムを書く夢」を体現した、ノーコード思想の先駆けといえるでしょう。
1-3.第4世代言語とレポートジェネレータ
1970年代から1980年代にかけて、プログラミングの世界には「第4世代言語（4GL：Fourth-Generation Language）」という考え方が広がります。それまでの言語が「どうやって処理するか（How）」という細かい手順を一つひとつ記述するものだったのに対し、4GLは「何をしてほしいか（What）」という結果を高い抽象度で記述するアプローチをとっていました。
代表例はSQLです。「SELECT ＊ FROM TABLE WHERE CONDITION」のように、欲しいデータの条件を書き並べるだけで、コンピュータが裏側で処理手順を考えて実行してくれます。また、Oracle FormsやFocusといったレポートジェネレータは、画面上でドラッグしてレポートを作成できる環境を提供し、データベースクエリが会話のように書けるようになりました。ビジネス処理を「記述（宣言）」で作るというこの発想は、現代のノーコードツールにも明確につながる画期的なものだったといわれています。
1-4.「プログラマ不要論」の最初の波
比較的早い時代から、新しい開発技術が登場すると、ほぼ必ず「これでプログラマは不要になる」という言説が飛び交うようになります。最初の大きな波は、高級言語や4GLが普及しはじめた1960〜70年代といわれています。COBOLの発表時、海外の新聞は「ビジネスパーソンが自分でプログラムを書く時代が来た」と報じ、非専門家がコンピュータを扱えるようになったと報じられたようです。
しかし実際にはプログラマは消えませんでした。それどころか、作れるものが増えたことでソフトウェアの需要は拡大し、エンジニアはより多く必要とされるようになりました。簡単なデータ抽出や定型レポートは自動化できても、複雑な業務ロジックや大規模なシステム設計には、やはり専門知識と論理的思考を持つエンジニアの存在が不可欠だったのです。道具が簡単になると仕事がなくなるのではなく、「もっと作りたいもの」が増える――このパターンは、以後のノーコードの歴史で何度も繰り返されることになります。
2.ノーコードが進化した、表計算・GUI・Webツールの時代
2-1.「表で処理する」革命
プログラマ不要論が一度は頓挫した後も、「現場の人々が自らシステムを作る」という夢は、まったく別の形で大成功を収めます。その立役者が「表計算ソフト（スプレッドシート）」です。
1979年、ハーバード・ビジネス・スクールの学生だったダン・ブリックリンと、友人のボブ・フランクストンが世界初の電子表計算プログラム「VisiCalc（ビジカルク）」をApple II向けに開発しました。セルに数式を入れ、どこかの数字を変更すれば全体が瞬時に再計算される。たったそれだけのことが、ビジネス界に革命をもたらしました。プログラミングの複雑な概念を一切知らなくても、画面上の直感的な操作だけで高度なビジネスロジックが構築できることが世に示され、当時は「簡易言語」と呼ばれることもありました。
その後、Lotus 1-2-3（1983年）、Microsoft Excel（1985年）へと続くこの系譜は、現代においても最も普及した「究極のノーコード環境」といえるでしょう。現場では売上集計、在庫管理、勤務表、簡易データベースまで、Excelで数多くの業務ツールが作られ続けています。これも、ある意味、ノーコードの一つの進化系だととらえられます。
業界に痕跡を残して消えたメーカー 表計算ソフト「VisiCalc」で世界を震撼させたVisiCorp（ASCII.jp）
2-2.GUIとビジュアルプログラミングの登場
1980年代以降、パソコンの操作画面は黒い背景に文字を打ち込むCUI（コマンドライン）から、マウスでアイコンやウィンドウをクリックするGUI（グラフィカルユーザーインターフェース）へと移行していきます。これに伴い、「画面の見た目をそのまま操作してプログラムを作る」ビジュアルプログラミングの概念が生まれました。
先駆的な存在が、1987年にAppleがMacintosh向けに発表した「HyperCard（ハイパーカード）」です。カードとスタックという直感的な比喩を用いて、ユーザーが画面や情報を組み合わせられる環境を提供し、専門知識がなくても自分だけのデータベースやインタラクティブなソフトウェアを作ることができました。当時、1万以上のスタックが生み出されたといわれます。ただし、スタックが増えるにつれてメモリを大量に消費してクラッシュが頻発するなど、大規模化には限界があり、結局コードとの併用が常道となりました。
その後、1990年代にはMicrosoftの「Visual Basic」やBorlandの「Delphi」などに代表されるRAD（Rapid Application Development）ツールが登場します。マウスのドラッグ＆ドロップでボタンやテキストボックスを画面に配置し、その裏側にほんの少しのコードを書くだけでWindowsアプリが完成するスタイルは、ノーコードというよりも、現在のローコードツールの画面構成に近いものといえます。
2-3.CMSとWeb制作ツール
インターネットが世界中に普及しはじめた1990年代後半から2000年代にかけては、Web開発の領域でノーコード化が進みました。当初、Webサイトを作るにはHTMLをテキストエディタで手入力しなければならず、発信できる人は限られていました。そこに「Dreamweaver」や「FrontPage」といった視覚的なWeb制作ツールが登場し、ワープロ感覚で文字や画像を配置するだけで、裏側でHTMLやCSSを自動生成してくれるようになりました。
そして、2003年に登場した「WordPress」がWeb開発の常識を大きく変えることになります。WordPressではノーコード的な活用が可能で、管理画面からブログのように記事を投稿するだけで、データベースと連動した本格的なWebメディアを作成できます。2026年春の時点で、全Webサイトの42.2%でWordPressが使用されているというデータもあります。
ただし、ここでもまた同じ構図が見えます。記事の投稿やテーマの選択といった基本操作ならノーコードで進められますが、独自性やセキュリティ、パフォーマンスを突き詰めようとすると、PHPのコードやサーバー運用の知識が必要になり、エンジニアやWebデザイナーの出番が戻ってくるのです。
2-4.2010年代のノーコード・ローコード
2010年代、ついに現代に続くノーコード、ローコードという言葉が定着しはじめます。クラウドとWebブラウザ技術の進歩によって、Webブラウザ上の操作だけで本格的なWebアプリやスマートフォンアプリを構築できる強力なプラットフォームが次々と誕生しました。
まず、2001年創業のOutSystemsはローコード開発基盤として企業向けに成長し、Mendixも2005年からローコードプラットフォームを提供しています。
Meet Mendix - The Low-Code Platform for the Enterprise（Mendix）
Microsoftが提供する「Power Apps」は、アプリ・サービス・コネクタ・データ基盤を組み合わせてビジネスニーズに合わせたカスタムアプリを迅速に構築できる環境として知られています。BubbleやWebflowといったプラットフォームも続き、市場規模は拡大を続けています。
これらのプラットフォームは、単に画面の見た目を作るだけでなく、ユーザー認証、データベース設計、外部サービスとのAPI連携まで視覚的な操作で完結できます。「アイデアさえあれば誰でも数日でビジネスモデルを形にできる」という現代のノーコード革命は、この時期に本格的な幕を開けたといってよいでしょう。
3.ではなぜ毎回「ノーコード革命」は止まるのか？
3-1.「90%の壁」がある
これまで、ノーコード・ローコード関連の技術は絶えず進化してきました。そして、進化のたびに「エンジニア不要」といわれても、世の中からプログラマは消えず、むしろ世界中でエンジニア不足が続いています。それは、ノーコードツールが普及し、システムの規模が大きくなるたびに、似たような「3つの壁」にぶつかる歴史を繰り返してきたからです。
ノーコード・ローコードツールの最大の強みは、システム全体の90%を驚くほどのスピードで作り上げられることです。フォームの作成、一覧画面の表示、承認フローの自動化、通知の送信――こうした定型的な処理は、テンプレートや部品の組み合わせで次々と完成します。
問題は残りの「10%」です。「ここだけ例外ルールがある」「ここだけ締め日が違う」と、現実の業務は、テンプレート通りではありません。そのような独自要件（カスタマイズ）が発生した途端、ノーコードツールは手間がかかるようになることがあります。標準機能では対応できないカスタムコードやAPI連携が必要になり、「ノーコードで始めたはずなのにコードが必要」という状況に遭遇することがあるわけです。この「90%の壁」を経験値として得ているエンジニアも多いと思います。
3-2.「ブラックボックスの壁」
次に「ブラックボックスの壁」です。ノーコードツールは複雑な処理を直感的に扱えるようにしています。しかしコードが見えないことで、逆にエンジニアがシステムの内部で何が起きているかを把握できにくくなっています。
データ量が増えてくると、画面表示や処理が重くなるパフォーマンスの問題が必ず発生します。通常の開発であれば、エンジニアがコードやデータベースを分析してチューニングできます。しかしノーコードの場合、インフラ環境や裏側の処理はベンダー管理下にあるため、ユーザー側では直接手を出せません。
例として、データ量が増えるとレスポンスが遅延することがありますが、原因がクエリなのかキャッシュなのか判断しにくく、チューニングできないことがほとんどです。つまり、「重い理由がわからないし、直せない」という状況に陥るのです。
上で紹介したHyperCardもスタックが増えるほどメモリを消費してクラッシュが頻発してしまい、ユーザーからすると「お手上げ」になってしまうことがありました。
3-3.「曖昧さの壁」
3つ目が、コンピュータの性質に根ざした「曖昧さの壁」です。
日常の業務指示は、人間同士なら文脈を読んで柔軟に対応する「曖昧さ」があり、とくに不自由しないことがほとんどです。「急ぎの案件は優先する、そうでない場合は通常で」といわれても、「何が急ぎ」か、「どれだけ急ぐ」か、「どれが通常」かは、曖昧でも人間にはだいたい理解できています。しかし、これは、システムにとっては正確な条件分岐が必要になるケースです。
ノーコードのビジュアル画面でこういった条件分岐を組み立てようとすると、無数の線や箱が絡み合う「ビジュアル・スパゲッティ」状態になりがちです。そのため、分岐動作が手動になることもあり得ます。また、誰でも作れるようになるほど、曖昧なまま作られた小さなシステムが現場に乱立し、作った本人が異動した途端に誰も直せないという事態も生まれます。
この「曖昧さの壁」は最終的には作り直すか、作った本人に聞く以外に突破方法がないことがため、地味ですがかなり強固な壁といってよいでしょう。
3-4.AIでこれらの「壁」は越えられる？
歴史上のあらゆるノーコード革命は「90%の壁」「ブラックボックスの壁」「曖昧さの壁」に阻まれてきました。しかし現在、ChatGPTに代表される生成AIの爆発的な進化により、この歴史が変わろうとしています。
AIは「90%の壁」に対し、自然言語で「この機能を追加するカスタムコードを書いて」と指示するだけで瞬時にコードを生成してくれます。「ブラックボックスの壁」についても、パフォーマンス低下の原因をAIが推測し解決策を提示する技術が登場しています。「曖昧さの壁」に対しても、AIが対話形式で「この条件が抜けていますが、例外処理はどうしますか？」と問い返しながら、人間の曖昧な要望を厳密なシステム論理へと昇華してくれます。
ならば、今度こそエンジニアは不要なのでしょうか？
それは無理筋でしょう。エンジニアが不要になるわけではありません。AIはハルシネーション（もっともらしい誤情報の生成）というリスクを持ちます。AIが生成したシステムがセキュリティ上安全かどうか、業務的に正しいかどうか、将来保守できるかどうかを判断するのは、最終的には人間です。エンジニアは「コードを書く人」から、「AIが作ったものを評価し、設計し直し、チームや組織が安全に使える形へ整える人」「AIを作る人」へと役割が広がっていくだけです。そこに技術がある限り、エンジニアは絶対に必要なのです。
まとめ
ノーコードの歴史は1950年代の機械語から高級言語への進化に始まり、現在のノーコード・ローコードに至ります。その背景には一貫して「人間の言葉でコンピュータを動かしたい」という欲望があったのだと思います。そして、これらのツールが人気になるたびに「エンジニア不要論」が飛び出してきました。しかし「90%の壁」「ブラックボックスの壁」「曖昧さの壁」という3つの壁によって抑えられてきました。生成AIがこれらの壁を低くするかもしれませんが、エンジニアは不要にはなりません。正直、「エンジニア不要論が不要論」といったところだと思います。
