かつての夢、そして挫折
「Programming is Dead. Long Live Programming ー プログラミングは死なず。ただ老兵は去るのみ」では、生成AIによる自然言語プログラミングの登場が、プログラミングの歴史からも必然であることを説明した。そして、プログラミングがより抽象化され、コンピューターから遠ざかり、ビジネスに近づいていること、今後さらにその流れが進む可能性があることを述べた。
さて、今回は、そこからさらに踏み込み、「誰もがプログラムを作れる世界」という夢が一度挫折し、今ふたたび新たな形で蘇ろうとしていることを見ていこう。
1959年、COBOLは「ビジネス担当者でも読める、書けるプログラミング」を実現するために誕生した。当初のプログラミングはアセンブリ言語が主流であり、ハードウェアに近い複雑な命令を扱う必要があった。その後に誕生した世界初の本格的プログラミング言語であるFORTRANが科学技術計算のために設計されたのに対し、COBOLは事務処理――給与計算、請求処理、在庫管理、社員名筆管理――を人間にわかりやすく表現することを目的とした。
1960年代、企業は大量の事務処理を抱え、人手では対応しきれなくなっていた。そこで、事務処理を自動化するためにCOBOLが注目された。当時の情報システム部門はまだ企業内で確立されておらず、プログラマーは技術者というよりも、業務に精通した事務員が兼任している例も多くあった。COBOLは、そのような人々でも扱えるよう、英語に近い構文を採用していた。
私はCOBOLを実際に使ったことはない。だが、改定前のIPA情報処理技術者試験を受験した経験から、言語の雰囲気は知っている。当時の試験で使用できたプログラミング言語はFORTRAN、COBOL、そしてCASL*1だった。大学でFORTRANを使っていた私はFORTRANを選んだが、試験勉強のために買った参考書で初めてCOBOLの記述を目にした。FORTRANが計算式中心で、いかにも「プログラミング」らしい構成だったのに対し、COBOLは業務手続きを追うような文章的構成をしており、「えっ、これがプログラミング？」と戸惑ったことを今も記憶している。
それもそのはずだ。COBOLの設計に深く関わったグレース・ホッパーは、「コンピューターに話しかけるのではなく、人間に話しかけるプログラムを書くべきだ」とする思想を提唱していた。COBOLはまさにその思想を体現し、ビジネスロジックをプログラムにするために抽象度を高めようとする挑戦だったのである。これは、コンピューター中心だった従来の発想から、人間中心へと視点を切り替える革新的な考え方だった。COBOLはまさにこの思想を体現し、ビジネスロジックをプログラムにするための抽象度を引き上げる挑戦だったのである。
しかし、そのような当初の目的にもかかわらず、COBOLは非専門家による言語ではなく、深い知識を要する専門家の言語へと変形していった。プログラムの規模と複雑さが急速に増大するなかで、COBOLは単純な業務処理を超えた高度な業務ロジックを扱う必要に迫られた。さらに、COBOL自体が自然言語に近づける工夫を施していたものの、構文が冗長かつ複雑になり、可読性や保守性が低下していった。結果として、非専門家が手軽に扱えるものではなくなり、専門的な知識と経験を持つ開発者が不可欠な存在となっていった。
また、当初は簡易な事務処理に利用されていたが、1960年代後半から1970年代にかけて、コンピュータの性能向上とともに、銀行の勘導系システムや行政機関の住民情報管理システムといった、より複雑で大規模なシステムに適用範囲が広がっていった。こうした大規模システムでは、オンライン処理やリアルタイム性、高信頼性が求められるようになり、COBOLプログラマーの専門性も高まっていった。
このように、COBOLが専門家の領域となっていった背景には、大きく二つの側面があった。技術面と組織面、それぞれに限界が存在した。技術と組織の両面で限界があった。技術面では、コンピュータの性能が十分とは言えず、プログラムが巨大化する中で、最適化やエラー対応など高度なスキルが要求されるようになった。さらに、開発ツールやデバッグ環境も未成熟で、非専門家が自力で扱うにはあまりに難易度が高かった。
組織面では、システム開発と業務運用が厳格に分離され、プログラミングを担当する情報システム部門と現場業務の間に大きな距離があった。プログラミングはあくまで専門職であり、現場担当者が手を出せる領域とは見なされなかったのである。
「誰でもプログラムできる」という夢は、結局のところ、こうした技術的・組織的な限界の中で、専門家たちの手に委ねられていった。プログラミングは再び、限られた者たちの営みとなったのである。
市民開発とノーコードの復活劇
しかし、COBOLの夢が完全に途絶えたわけではなかった。
時代は流れ、テクノロジーは進化した。近年、ノーコードツールの登場によって、かつてCOBOLが目指した「誰もがプログラムできる」世界が新たな形で現実味を帯び始めている。
ノーコードツールは、2010年代前半から登場し始めた。Webサイト構築向けのツールとしては「Wix」や「Webflow」などが登場し、業務アプリケーション向けでは「Glide」や「AppSheet」などが普及してきた。これらのツールは、専門的なプログラミングスキルを持たないユーザーでも、ドラッグ＆ドロップやGUI操作によってWebサイトや業務アプリケーションを作成できる環境を提供した。これにより、ビジネス部門が自ら課題解決に乗り出す「市民開発（Citizen Development）」の流れが加速した。
この「市民開発」という言葉は、従来、IT部門など限られた人々だけが担ってきた開発活動に、業務現場に近い人たちも参加できるようにし、より多くの人が自らの課題を自ら解決できる世界を目指す動きである。この概念は2010年代中頃から湧き始め、ノーコードツールの普及と共に広がっていった。
ここで注目すべきは、プログラムを書く際の抽象度が着実に上がり続けていることである。ノーコードツールは、コンピューターという存在を限りなく隠蔽し、人間が普段使う言語や思考のレベルで、業務プロセスやビジネスロジックを記述できるようになった。この進化は「誰でもプログラムできる」という理想を現実に近づけている。
ただし、課題も存在する。ノーコードツールによる開発は、手軽さゆえに次のような問題を抱える。
第一に、開発されたアプリケーションの内部構造がブラックボックス化しやすく、何がどのように動いているかが分かりづらくなるという問題がある。例えば、ノーコードツールで作成した顧客管理システムにおいて、複雑な条件分岐やデータ連携を実装した場合、システムが正常に動作しなくなった際に原因を特定することが非常に困難になる。結果として、システム全体の改修が必要になり、フルスクラッチで作り直すよりも時間とコストがかかるケースも考えられる。
第二に、特定ベンダーへの依存性が高まり（ベンダーロックインリスク）、別プラットフォームへの移行が難しくなるだけでなく、そのベンダーがツールの提供を停止したり、更新が滞ったりすると大きな問題となるという問題がある。実際には、AWSが提供していたノーコードツール「Honeycode」が2024年にサービス終了を発表したように、大手企業でもサービス終了は起こりうるという事例がある。
さらに、開発の専門性が高まり、作成者の不在と共に運用が終結するリスク（属人性リスク）も存在する。これらはノーコードツール特有の落とし穴であり、安易な利用が将来の大きなコストにつながる可能性があることを意識する必要がある。
それでもなお、ノーコードは、市民開発という形で「誰でもプログラムできる世界」というかつての夢を実現させつつある。
そして、その流れをさらに拡張する技術が現れようとしている。
生成AIという「人間を拡張する力」
ノーコードが広げた可能性を、さらに加速させた存在がある。それが生成AIだ。
生成AIは、もはやノーコードツールのようにGUIでプログラミングする必要すらなく、自然言語での指示によってコードを生成できる領域に到達した。これにより、ユーザーはコンピュータの細かな命令体系を理解することなく、自らの意図を自然な言葉で表現するだけで、必要な機能を備えたアプリケーションやプログラムを生み出せるようになっている。
この動きは、非技術者の間にも広がりつつある。たとえば自治体では、議事録の自動作成、問い合わせ対応のチャットボット、文章の要約・翻訳といった業務自動化ツールが、生成AIを使って開発され始めている。これにより、職員の業務負担が軽減され、市民サービスの向上にもつながっている。
従来のノーコードツールは「用意されたコンポーネントを組み合わせる」ことで開発を行っていた。この構造は、従来のノーコードツールだけでなく、「SaaS is Dead. Long Live SaaS ― SaaSは本当に終わるのか？進化の本質を読み解く」で説明したように、SaaSも同様であった。SaaSは業務の「ベストプラクティス」を標準化して提供することで効率化を実現したが、個別の要件や独自の業務フローへの柔軟な対応は難しかった。ノーコードツールも、ツール側が想定した枠の中でしか開発できないという限界を抱えていた。これらの制約を打破するのが生成AIである。生成AIは「ゼロからコードを生み出す」ことを可能にし、原理的には制約を持たない。ただし、自由度が高い分、意図の正確性を高めることや、生成物の課題を採用前に評価することなど別の管理能力を要求する。生成AIは、プログラミングの抽象度を一気に拡張し、コンピューターとの距離を一層広げる進化を実現したと言える。
しかし、生成AIを活用する上でも、ノーコードツールと同様の課題が残る。すなわち、生成されたコードの内部構造がブラックボックス化しやすく、特定のプラットフォームへの依存が高まる。また、生成された成果物の理解が困難になり、開発が属人化しやすい。これらは、専門知識がなくてもプログラムを作成できる代償として、長期的には新たなリスクを生み出す要因となり得る。
生成AIを活用する動きは、非技術者の間にも広がりつつある。たとえば自治体では、議事録の自動作成、問い合わせ対応のチャットボット、文章の要約・翻訳といった業務自動化ツールが、生成AIを使って開発され始めている。これにより、職員の業務負担が軽減され、市民サービスの向上にもつながっている。
それでもなお、生成AIは「人間を拡張する力」として私たちを支えてくれる存在であり、その方向を定め、走り続けるのはあくまでも人間である。
プログラミングの新しい意味とこれから
ここまで見てきたように、COBOLが夢見た「誰もがプログラムできる世界」は一度挫折したものの、ノーコードツールと市民開発という形で再び現実味を帯び始めた。そして、生成AIによってさらに加速しようとしている。
一方で、ソフトウェア開発の進化は非技術者だけの話ではなかった。技術者（エンジニア）たちの世界にも、また別の流れが存在していた。
1980年代末から1990年代にかけて、クライアント／サーバーシステムやGUIが登場し、ソフトウェア開発は大きな変化を迎えていた。その変化に対応するために注目されたのが「RAD（Rapid Application Development）」の試みである。
RADは、プロトタイプを簡易に作成し、ユーザーのフィードバックを反映しながら開発を進める手法として披露された。ここでも「より早く、より柔軟に作る」ことが重視された。
しかし、当時の技術的な制約やプロジェクトマネジメントの難しさから、RADは大規模システムには向かず、文書化が不足しがちといった課題も抱えていた。その結果、RADは一部のプロジェクトでしか採用されず、より大規模で持続的な作り込みを支えるために、ローコード開発へと進化していくことになった。
RADが提唱した「素早く作る」という思想を一部受け継ぎながら、さらに企業向けシステム開発にも耐えうる拡張性を備えて進化したのが「ローコード開発」である。ローコードツールは、GUIを活用して開発スピードを高めつつ、必要に応じてコードを追加できる柔軟性を持つ。OutSystemsやMendix、Microsoft Power Appsなどがその代表例であり、当初から技術者だけでなく非技術者も視野に入れた開発支援ツールとして登場した。それらは、高速なアプリケーション開発を支援する手段として企業現場に広がり、専門性の有無にかかわらず開発に参加できる環境を広げていった。
つまり、ここまで整理すると、
- 非技術者向けにはノーコードと市民開発の流れがあり、
- 技術者向けにはRADからローコードへの流れがあった、
という二つの並行する進化があったことがわかる。
ところが、近年ではこの二つの流れの境界が曖昧になりつつある。ノーコードツールの高度化により、非技術者でもかなり複雑なアプリケーションを作成できるようになってきた。一方で、技術者がノーコードツールを使うケースも増えている。たとえば、社内業務アプリなど、重要度が高くない部分を素早く作る際には、ノーコードツールを用いて開発負荷を軽減する。また、ノーコードでカバーできない部分に対しては、自らコードを追加することで柔軟に対応している。さらに、新機能の仮説検証やプロトタイプ開発、社内管理システムや短期間だけ使うツールの作成といった場面でも、ノーコードやローコードが積極的に活用されている。
また、ローコードツールも非技術者が利用できるようにインターフェースが進化してきた。たとえば、ビジネス部門の担当者が簡単なフォーム入力系アプリを作成する際に、ローコードツールを利用するケースが見られるようになった。
さらに、ツールベンダー自身も、ノーコードとローコードを明確に区別せず、利用者に合わせて自由に使い切れるような設計思想を取り入れている。このように、もはや「ノーコードかローコードか」という明確な線引き自体が大きな意味を持たなくなりつつあるのだ。
私自身、以前あるイベントでの対談の際、ノーコード／ローコードとスラッシュで区切って話したところ、対談相手から「ノーコードとローコードは違う」と指摘された経験がある。相手の企業のノーコードツールはスマホから開発を行うスタイルであり、確かに非技術者を主なターゲットとしていたため、そのときは納得し、それ以降しばらくは両者を意識して使い分けていた。しかし現在、これらのツールは融合が進み、境界はますます曖昧になっていると感じている。
これまでノーコードやローコードツールは、GUIを用いてデータを視覚的に組み立てることで、抽象度を高める方向で進化してきた。しかし現在、生成AIを製品の中心に組み込むことで、自然言語が新たな抽象化の手段として活用される時代が到来しつつある。これにより、ユーザーはより直感的に、自らの意図を表現できるようになった。
この流れの中で、二つのタイプのツールが現れている。ひとつは、既存のノーコードやローコードツールに生成AIを組み込む動きである。たとえば、MicrosoftのPower AppsではCopilotを搭載し、ユーザーが自然言語でアプリの意図を指示するだけで、データ構造の設計やアプリの基本組織を自動生成できるようになっている。
もうひとつは、初めから生成AIを前提に設計されたツールだ。たとえばDifyは、大規模言語モデルを駆使し、チャットボットやデータ要約ツールを自然言語で指示するだけで簡単に作れるようにしている。AWS App Studioも、ユーザーの意図を自然言語で受け取り、バックエンドでデータベースを構築し、アプリを生成することを目指している。
さらに、今後はこれらのツールが単なる人間の操作対象にとどまらず、AIエージェントからも操作される存在になるかもしれない。ツール自体がMCPサーバーのような機能を持ち、別のAIが自然言語で指示を出してプログラムを生成・修正する、といった世界が現実になる可能性がある。ノーコード／ローコードツールは、GUIに始まり、自然言語という新たな武器を手に入れ、そして人間以外のエージェントからもアクセスされる未来へと進化しつつあるのだ。
こうした未来像については、「SaaS is Dead. Long Live SaaS ― SaaSは本当に終わるのか？進化の本質を読み解く」でも触れた。そこでは、人間がSaaSのUIを操作するのではなく、AIエージェントが目的に応じてSaaSを操作・連携する未来が訪れると予測した。ノーコード／ローコードツールについても、同じような変化が起こるだろう。すなわち、ツール自体が人間によるGUI操作だけでなく、AIエージェントによる指示を受け取る前提で設計されるようになり、MCPサーバーのような機能を持つ存在へと進化していく。その結果、開発や業務プロセスの自動化はさらに進み、人間とAIが共にツールを活用する新しい時代が到来するはずだ。
とはいえ、この未来にも課題は残る。ノーコード時代に指摘されていたブラックボックス化、ベンダーロックイン、属人性といった問題は、生成AI時代にも形を変えて引き継がれるだろう。すでに説明しているが、これらの課題は次のようなものだ。
ブラックボックス化は、開発プロセスや生成物が外部から理解しにくくなるリスクであり、透明性を損なう。一方、ベンダーロックインは、特定のプラットフォームやツールに依存することで、移行や柔軟な選択が困難になる問題である。そして属人性とは、特定の個人に依存してシステムやツールが成り立つことで、維持・発展が個人の在籍や知識に左右されるリスクを指す。
属人性が放置された結果、ツールやシステムの移行が困難になるケースもある。たとえば、私自身、過去に、Lotus DominoからMicrosoft Exchangeへの移行を検討していた企業で、かつて退職した社員が作成したDominoアプリが障壁となり、完全な移行ができなかった事例を見たことがある。個人依存が解消されないまま開発されたアプリケーションは、後々になって組織の柔軟性を大きく損なうリスクを孕んでいるのだ。
これに備えるためには、以下が重要である。
- プログラミング言語による出力を残し、透明性を確保すること
生成AIやノーコードツールが生成するソースコードが存在しても、それが完全に柔軟で、かつ人間による管理なしに長期間運用できるわけではない点に注意が必要だ。たとえば、MATLABのSimulinkから自動生成されるCコードのように、モデルの変更とコードの整合性を保つため、生成後のコードを直接編集することは推奨されない場合がある。 - 依存リスクの低いツールを選定すること
COBOLは、誕生当初からベンダー依存を排除する標準化言語として設計され、のちに国際標準にもなった。この理念を完全に追求するのは難しいが、極力参考にすべき基本姿勢である。特に生成AI関連ツールは変化が非常に速く、今使っているツールを来年以降も継続利用できるとは限らないと心得るべきだ。 - チーム開発の中に組み込み、市民開発＝野良開発にならないようガバナンスを強化すること
属人化を防ぎ、開発された成果物が組織全体で運用・改善できるようにする体制づくりが不可欠だ。
こうした備えを怠らずに向き合っていけば、ノーコード／ローコードと生成AIが切り拓いた新しいプログラミングの未来は、確実に拓かれていくだろう。
プログラミングはもはや、言語を習得して命令を書く作業にとどまらない。人間の意図を自然言語で示し、生成AIやAIエージェントがそれを形にする時代が始まった。COBOLから始まったこの挑戦は、ノーコード、ローコード、生成AIを経て、今、AIエージェントの時代へと進化しようとしている。開発手法もツールも、そして人間自身も、この変化にどう向き合い、アップデートできるかが問われるだろう。
そんなことをこのイベントで話す予定。
*1:教育用に作られた仮想的な簡易アセンブリ言語
