「Programming is Dead」──この挑発的な言葉を公の場で語ったのは、NVIDIAのCEO、ジェンスン・フアンだった*1。
彼は、「AIの進化により、誰もが自然言語でプログラムを作れるようになる」「もはや子どもたちにコーディングを教える必要はない」とまで言い切った。この発言は、ソフトウェア開発の現場だけでなく、教育界にも波紋を広げた。
そしてこの発言は、彼ひとりのものではない。例えば元Googleエンジニアで、現Fixie.aiの創業者であるマット・ウェルシュは、「AIの台頭によって、プログラミングのやり方そのものが根本から変わる」と述べており、自身の論考『The End of Programming』の中で、プログラミングの終焉ではなく“変容”を論じている。
たしかに、生成AIが提示するコードは、十分に実用レベルに達しつつある。ノーコードツールも進化し、「コードを書かない開発」はすでに現実のものだ。では、本当に「プログラミングは終わった」のだろうか？
生成AIと自然言語プログラミングの未来
「プログラミングが終わる」と言われるとき、真っ先に挙がるのが生成AIによるコードの自動生成だ。GitHub Copilot や Cursor、Cline、Devin などに代表されるAI搭載型開発ツールは、自然言語の指示から瞬時にソースコードを出力し、実際に動くアプリやスクリプトを“雰囲気”で書ける時代をもたらした。
このような開発手法を、元OpenAIの研究者であるアンドレイ・カーパシーは「Vibe Coding（バイブ・コーディング）」と名付けた。これは、構造や仕様を厳密に記述しなくても、意図や雰囲気（vibe）を自然言語で伝えることで、AIがコードを補完・生成するという考え方に由来する。従来の“文法を覚える”というプログラミングの前提が崩れつつある。
だが、“それっぽく見える”ことと“本当に正しい”ことは違う。
AIは過去のパターンから統計的にもっともらしいコードを出しているに過ぎず、整合性や安全性には注意が必要だ。開発者はその限界を理解し、検証し、必要なら修正する力が求められる。
とはいえ、AIの進化スピードを考えると、こうした懸念が近い将来ほとんどのプログラミング分野で解消される可能性も高い。単に“もっともらしい”だけでなく、実用的かつ信頼性の高いコードを出力するAIが一般的になる未来も十分に想定される。
それゆえ、この技術が示している未来は明るい。
そもそも、プログラミング言語とは本質的に“人間がコンピューターに命令を与える手段”だ。
そしてその命令の伝達手段は、かつてはコンピューターの“母語”である機械語で行われていたが、そこから抽象化が進み、アセンブリ、FORTRAN、C、Pythonといった高級言語へ、つまり人間の自然言語により近い形へと進化してきた。
その流れを極限まで進めた結果が、「自然言語でプログラムを書く」という発想だ。
したがって、生成AIによる自然言語プログラミングは、決して“異端”ではない。
むしろ、これまでのプログラミング言語進化の延長線上にある「歴史的必然」なのだ。
これからのプログラミングは上流工程を指向する
AIによってコードを書くという行為が代替されつつある今、プログラマーに残される役割は何だろうか？
その答えは「上流工程」であると予測する専門家も多い。すなわち、顧客理解を起点とし、要求定義、要件定義、設計、プロダクトの市場投入計画の策定、さらには事業戦略への統合といった一連のプロセス――そのすべてが、依然として人間の判断を必要としている。
「このユーザーの解決すべき問題は何か」「この業務のどこに課題があり、どう要求定義すべきか」といった問題設定そのものは、人間の中からしか出てこない。生成されたコードが「意図に沿っているか」を判断するのも人間だ。AIは命令に従うが、その命令を設計するのは依然として人間である。
だが、こうした上流の作業を「プログラミング」と呼ぶことに、違和感を持つ人もいるだろう。コードを書かないのに、なぜ“プログラミング”なのか？と。正直、自分もそう感じていた。
その問いに答えるには、もう一度プログラミングの歴史を振り返る必要がある。
そもそもプログラミングには、二つの大きな流れがある。
一つは「計算」を扱う流れである。そもそもコンピューターは“計算機”として誕生し、その用途に合わせてプログラミング言語も発展してきた。初期には機械語やアセンブリー言語が用いられていたが、1957年に誕生したFORTRAN（Formula Translation）はその抽象化の大きな飛躍だった。FORTRANはIBMのジョン・バッカスによって開発され、科学技術計算を効率よく記述するための高級言語として広く普及した。数値解析、シミュレーション、工学計算などの分野で重宝され、「コンピューターを用いた科学研究」の基盤を築いた。
もう一つは「ビジネスロジック」を扱う流れである。こちらは、計算処理ではなく、業務手順や帳票処理など、ビジネス実務の表現が求められた。COBOL（Common Business Oriented Language）は1959年、アメリカ国防総省主導のもとに開発された言語で、グレース・ホッパーらの働きかけにより、英語に近い構文を採用した。これは専門技術者以外の業務担当者でも読み書きできることを意図して設計されており、大規模な企業システムにおいて標準化された言語として広く使われた。
このように、計算と業務処理という二つの異なるニーズから、それぞれのプログラミング言語が進化してきたのである。
ビジネスロジックを扱うプログラミングは、そもそも現実の仕組みをどう表現するか、どう整理し、どうルール化するかを考えるところから始まる。これは、単なる実装ではなく、業務構造そのものをコードに落とし込むプロセスである。
実際、エンタープライズ向けに広く利用されているJavaやその周辺の各種フレームワーク、オブジェクト指向という概念そのものも、ビジネスロジックの複雑性をプログラムに組み込むための工夫と言える。たとえばドメイン駆動設計（DDD）やクリーンアーキテクチャのような実践は、現実世界の業務ルールや意思決定構造を、保守可能かつ再利用可能なソフトウェア構造に変換することを目的としている*2。
このように、プログラミングの目的が「ビジネスロジックの構造化」にあるのだとすれば、その関心は当然、上流工程――すなわち顧客理解を出発点とした要求定義、要件定義、設計、さらには戦略との整合性――へとシフトしていくことになる。上流工程における意思決定そのものが、最も本質的な“プログラミング”と言える時代になりつつあるのだ。
現代のAI時代においても、役割の重心は実装（下流）から設計・意図定義（上流）へと移っていく。プログラミングとは、単なる記法ではなく、「どう動かしたいか」という意思の構造化であり、それはますます人間の役割になる。
だから、コードを書く人だけがプログラマーなのではない。目的を定め、構造を設計し、AIに指示を与える人もまた、新しい形のプログラマーなのだ。
COBOLの再発見 ― 読めること、誤解されないこと
FORTRANが「計算」のための言語であったなら、COBOLは「ビジネス」のための言語だった。
COBOLの設計思想で特に注目すべきなのが、「読みやすさ」と「誤解されにくさ」だ。グレース・ホッパーらによって、誰でも読めて意味が通じることを重視して設計された。
COBOLは、文法そのものが英語に近く、人間にとっての可読性を最優先している。 たとえば：
IF CUSTOMER-BALANCE IS GREATER THAN 1000
THEN DISPLAY "OVERDUE".
これはほぼ英語の文章そのものであり、業務担当者が読んでも意味が理解できる
COBOLの特徴はまさに、「誰が読んでも意味が通る」「曖昧さが少ない」ことである。
COBOLのこの思想は、今日の“自然言語によるプログラミング”にも通じる。AIに自然言語で指示を出し、コードを書かせるという行為は、ある意味ではCOBOLの再来ともいえる。ただし、大きな違いは、今日の生成AIで用いる制約のない自然言語には本来的に“曖昧さ”がつきまとうという点である。そもそもプログラミング言語はコンピューターとの対話のために設計されているが、自然言語は人間同士の対話に最適化されてきた。だからこそ、そのままではコンピューターに正確な命令を与えるには不向きなこともある。
この点で興味深いのは、アメリカ連邦政府が採用している“プレーン・ランゲージ（Plain Language）”の考え方だ。多様な言語背景を持つ国民に向けて、法律や行政文書を誰にでも理解できるように、簡潔で明快な表現に限定する取り組みである。
これは、まさに曖昧さを排し、意図を誤解なく伝えるという目的において、コンピューターとの対話と似た構造を持っている。コンテクストに依存しない“ローコンテクスト”な人間同士のコミュニケーションは、むしろコンピューターとの対話に近い。だからこそ、自然言語を使ってAIに命令する際にも、このような“制約付き”の明確な言語スタイルが求められるのではないだろうか。
こうした背景をふまえると、今後必要になるのは、「読みやすく、曖昧さがなく、AIにも伝わる」中間的な記述形式、すなわち“制約付き自然言語”のようなものかもしれない。たとえば、特定の語彙や構文パターンに制限をかけた半構造的な記述スタイルが考えられる。自然言語の柔軟さとプログラミング言語の正確さをどう両立させるかという問いに対して、COBOLやプレーン・ランゲージの発想は一つのヒントになるだろう。
特にCOBOLは、特定の記述スタイルと限定された語彙、厳格な構文を通じて、業務ロジックの正確な伝達を可能にした。このような設計の発想は、AI時代のプログラミングにおいても一つの参考になるかもしれない。
もちろん、現代のプログラミング言語や開発手法も、別のアプローチで可読性や保守性を高める進化を遂げている。型システムや関数型パラダイム、オブジェクト指向、リファクタリング、ドメイン駆動設計といった実践もまた、「曖昧さを減らし、意図を明確にする」ことに取り組んでいる。
COBOLの思想を持ち上げすぎるのではなく、こうした多様な進化の中で、言語や設計における“人間中心のわかりやすさ”という観点を改めて見直すヒントになると捉えるのが妥当だろう。
プログラミングがコードを書くことから「構造を伝えること」へと変わるならば、その構造を正しく・簡潔に・誤解なく伝える記述形式の設計は、AI時代における新しいプログラミングの重要なテーマとなる。
COBOLは、もしかするとその先駆けだったのかもしれない。
新しいプログラマーたちへ
AIがコードを生成するようになった今、プログラマーとは誰のことを指すのだろうか。
コードを書くスキルだけでなく、要件定義、構造設計、検証、フィードバックといった上流的かつ対話的な能力が求められるようになってきている。もはや、プログラミングとは「構造を設計し、意図を明確にし、AIに伝えること」と定義し直す必要があるかもしれない。
こうした変化に、違和感を覚える人もいるだろう。プログラミングとは本来、自分で手を動かしてコードを書くことではなかったか？という声は、実際に現場で経験を積んできた人たちにとって当然のものだ。
だが、歴史はこうした違和感が繰り返し塗り替えられてきたことも示している。
たとえばCOBOLの登場後、大量の“COBOLプログラマー”が誕生した。彼らは従来のアセンブリー言語やFORTRANでプログラミングしていたエンジニアたちとは異なり、多くが業務知識をもとにCOBOLを新たに習得してプログラミングを始めた人々だった。COBOLは英語に近く、非技術者にも扱いやすい言語であり、それまでプログラマーではなかった人たちが、プログラマーになった。
それと同じことが、いま起ころうとしているのではないだろうか。
生成AI時代のプログラマーは、必ずしも従来のプログラマーの延長線上にいるとは限らない。ビジネスの構造を理解し、意図を明確に定義し、AIと対話できる人間――そうした新しいタイプのプログラマーが生まれてくる。
それはもしかすると、これまでコードを書いてこなかったビジネスサイドの人かもしれない。
そして、彼らが手にするのは従来の開発ツールではなく、生成AIという対話的な開発ツールだ。
プログラマーの定義が拡張され、領域をまたいでいく未来。 違和感を覚えるのも自然なことだ。けれど、過去にCOBOLが起こしたことが再び起きるのだとすれば、それはむしろ時代の流れとして当然なのかもしれない。
時代が変われば、使う道具も、求められるスキルも、担う役割も変わる。
今後のプログラミングの現場では、コードそのものよりも、意図の伝達や構造の設計といった“コミュニケーションとしてのプログラミング”がより重視されるようになるだろう。
説明してきたように、そもそもプログラミング言語の進化とは、1つは抽象化──人間にとって自然な言語に近づける方向へ、もう1つはビジネスロジックを表現・組み込みやすくする方向への歩みだった。生成AIはこの両方の流れを加速させ、まったく新しい種類のプログラマーを生み出しつつある。
その変化を柔軟に受け止め、新たな視点で技術と向き合っていくこと。それこそが、これからの“プログラマー”に求められる姿勢なのかもしれない。
※ タイトルにある「老兵は去るのみ」とは、かつてのスキルや役割にとどまることなく、変化を受け入れて学び続ける姿勢の大切さを表した。プログラマーに限らず、すべての技術者に向けた自戒でもある。
