AI時代に新しいプログラミング言語はいくつ生まれるのか──2035年を3層で予測する【言語史・AI】

1. 結論：新言語は増える。ただし、主流の席はほとんど増えない

新しいプログラミング言語の誕生は止まらない。むしろ、個人の実験、企業内言語、特定用途向け言語の数は、AIによって増える可能性が高い。一方で、人間が日常的に名前を挙げ、企業が本番採用し、求人票の必須要件にまで入る汎用言語は、それほど増えないだろう。

これから起きそうなのは、少数の有力言語への集中と、その周囲にある小さな言語の爆発的な多様化である。森にたとえれば、見渡す限りの新芽が出る一方、空まで届く大樹の本数はほとんど変わらない。

理由は、言語を「作る費用」と、言語を「社会に定着させる費用」がまったく違うからだ。文法を決め、構文解析器を書き、簡単なプログラムを動かすだけなら、2020年代後半のAIを使って個人でも短期間に到達できる。しかし、標準ライブラリ、パッケージ管理、デバッガー、エディター支援、セキュリティ監査、長期互換性、教材、求人、熟練者の共同体までそろえるには、依然として年単位の蓄積がいる。

したがって、未来を予測するときは「発明された数」「公開され、ある程度使われた数」「企業が本番採用する主流言語の数」を分けなければならない。本記事ではこの3層を分け、2035年までを次のように予測する。

この予測で最も重要なのは数字そのものではない。未来の主戦場は、新しい記号を発明することより、人間の意図を曖昧さの少ない仕様へ変え、AIの生成物を機械的に検証することへ移る、という点である。

2. 70年の言語史：新しい言語は「次の問題」が見えたときに生まれた

コンピューターがプログラムで動く原理は、長い翻訳の階段として説明できる。人間が書いた文字列は、字句解析で単語や記号へ分かれ、構文解析で命令の木構造へ変わる。さらに中間表現を経て、足し算、比較、メモリーからの読み出しといった機械命令へ落ちる。中央処理装置は命令を取り出し、意味を解読し、実行する。その最下層を支えるのは、電圧の高低を0と1として扱うトランジスターと論理回路だ。画面上の一行と半導体内の電気的変化の間には多くの層があるが、最後は物理現象に到達する。

初期のプログラマーは、数値で表された機械命令をほぼ直接扱った。機種ごとに命令番号や記憶位置が異なり、別のコンピューターへ移すだけでも書き直しが必要だった。1940年代末から1950年代初頭に広がったアセンブリ言語は、数値の命令を加算や転送を表す短い記号へ置き換え、記憶場所にも名前を付けた。アセンブラという別のプログラムが、それを機械語へ直す。これは単なる表記の改善ではない。人間が機械の数値を覚える仕事を、別のプログラムへ委ねた大きな抽象化だった。

現在もアセンブリは、CPUの起動部分、組み込み機器、暗号処理、極端な性能最適化で使われる。ただし、多くの開発者はその上にある言語を使う。高水準言語の歴史とは、機械の詳細を隠し、人間が問題そのものを記述できる範囲を広げてきた歴史でもある。

FORTRAN、LISP、COBOL、BASICが利用者を増やした

1957年、IBMでジョン・バッカスが率いたチームはFORTRANを実用化した。当時は、コンパイラーが人間の手書きアセンブリほど効率のよい機械語を生成できるのか疑う技術者が多かった。バッカス自身も、1954〜1957年ごろには自動プログラミングが手書きに匹敵するコードを作れないという信念が広く存在したと振り返っている。FORTRANはその疑いを実用品で崩した。翻訳器を一度改善すれば、多数の利用者のプログラムをまとめて高速化できる構造が生まれたのである。^[1]

1958年にはMITのジョン・マッカーシーがLISPを提案し、記号処理、再帰、リストを前面に出した。1960年ごろに整えられたCOBOLは、企業の事務処理と機種をまたぐ移植性を重視した。科学計算、人工知能研究、業務処理という異なる課題が、それぞれ異なる言語を生んだ。新言語は既存言語の長所を全部混ぜるより、ある時代の切実な問題へ意図的に偏った回答として生まれることが多い。コンピューター歴史博物館の年表でも、この時期の言語は計算、記号処理、教育、事務という利用者層の拡張と並んで記録されている。^[2]

1964年5月1日午前4時、ダートマス大学のタイムシェアリング環境で最初のBASICプログラムが走った、という有名な記録がある。トーマス・カーツ本人は後年、当人たちはその場にいなかったため「よい神話」として支持している、と笑いながら語っている。確実なのは、ジョン・ケメニーとカーツが専門家だけでなく全学生へコンピューターを開こうとしたことだ。簡潔な言語と、入力後すぐ結果が返る対話環境は一体の発明だった。後に家庭用コンピューターへBASICが搭載され、文法だけでなく配布経路が普及を決めることも示した。^[3]

新しい言語は古い言語を全滅させるためではなく、次の利用者と次の問題へ届くために、翻訳の階段を一段ずつ足してきた。

構造化、オブジェクト指向、移植性が複雑さを受け止めた

プログラムが巨大になると、次の問題は命令を書くことではなく、複雑さを管理することへ移った。1960年代半ば、ノルウェー計算センターのオーレヨハン・ダールとクリステン・ニゴールはSimulaで、データと手続きをオブジェクトとしてまとめた。1972年にはゼロックスPARCで、アラン・ケイ、ダン・インガルス、アデル・ゴールドバーグらがSmalltalkを形にした。オブジェクト指向は突然の思いつきではなく、シミュレーション、対話的画面、巨大なソフトウェアを扱う過程で育った。^[2]

同じ1970年代、ベル研究所のデニス・リッチーが開発したCは、機械に近い制御と移植性を両立させた。リッチー自身の記録では、現代的なCの要点は1973年初めまでに整い、その年の夏にUnixカーネルがCで書き直された。OSという実用品が言語の有効性を証明し、OSが別の機械へ移ることで言語も広がった。^[4] この関係は、後のブラウザーとJavaScript、スマートフォンとSwiftやKotlin、クラウド基盤とGoにも繰り返される。

1980年代から1990年代には、C++、Python、Java、JavaScript、PHP、Rubyなどが登場した。特に1995年前後にJava、JavaScript、PHP、Rubyが集中したのは偶然だけではない。パソコンの普及、インターネットの商用化、グラフィカルな画面、サーバーとブラウザーを結ぶ必要が、移植性と開発速度への需要を一気に高めた。Javaは仮想マシンで機種差を吸収し、JavaScriptはブラウザーという配布済みの実行環境を得た。PHPはWebページを動的にする低い入口を提供し、RubyとPythonは人間の作業時間を減らす方向を強く押し出した。

2000年代以降は、安全性、並行処理、異種ハードウェアが焦点になった

Googleでロバート・グリースマー、ロブ・パイク、ケン・トンプソンがGoの構想を始めたのは2007年9月21日である。公式FAQによると、巨大なC++やJavaプロジェクトの複雑さ、マルチコア化、並行処理を扱う難しさが出発点だった。2008年1月に作られた初期コンパイラーはGoを直接機械語にせず、いったんCへ変換した。新言語でも最初からすべてを自作する必要はないという好例である。Goは2009年に公開され、2012年に安定版となった。^[5]

Rustは、CやC++の性能を保ちながら、解放済みメモリーへのアクセスやデータ競合を型の仕組みで防ぐ方向へ進んだ。2015年5月の1.0公開時、Rustチームは、ガベージコレクターや専用ランタイムなしで低水準の制御と安全性を両立する目標を明示した。^[6] 2025年Stack Overflow調査では、実際に使った人のうち継続利用したい割合を示す「admired」でRustは72％と調査対象言語の首位だった。安全性という思想が、パッケージ管理、エラー表示、文書化まで含む利用体験と結びついて定着したのである。^[7]

近年も誕生は続く。Erlang仮想マシンとJavaScriptを対象にする静的型付き言語Gleamは2024年3月に1.0へ達し、同じ2025年調査でadmired 70％となった。^[8][7] 2023年に公開されたMoonBitはWebAssembly、JavaScript、ネイティブ実行を対象とし、2025年6月にベータ版へ進んだ。当初は2026年前半の1.0を目指したが、2026年8月19日時点ではv0.10.9で、1.0前の改良が続いている。新言語ではロードマップより安定化を優先すること自体が健全な選択である。^[9][10]

さらにLLVM系のMLIRは、異なる抽象度の中間表現を再利用し、異種ハードウェア向け・特定用途向けコンパイラーの構築費を下げる。現代の新言語は、ゼロから機械語生成器を作らず、LLVM、MLIR、WebAssembly、既存の仮想マシンを足場にできる。^[11]

3. 生データが示す「拡大」と「集中」の同時進行

言語が増えているかを測る完全な統計は存在しない。大学の実験言語、企業内の専用言語、一人だけが使う作品をすべて登録する戸籍がないからだ。ただし、GitHubがファイルの種類を判定するために管理するLinguistの履歴は、一つの観測窓になる。

Linguistの languages.yml で type: programming に分類された項目を、各年末時点の最後のコミットから同じ方法で数え直すと、2015年末298、2020年末395、2022年末455、2025年末530、2026年8月28日時点560だった。2015年末から2025年末までの純増は232、単純年平均は23.2項目である。2022年は前年末から42、2025年は32増えており、少なくとも認識対象の多様性が停滞した形跡はない。^[12]

種類の数が増えることと、利用が少数へ集中することは矛盾しない。生物の種が豊富でも、都市の街路樹は限られた品種へ集中するのと似ている。

ただし、これは発明年の統計ではない。昔からある言語が後から追加されることもあり、方言、テンプレート言語、ハードウェア記述言語も含まれる。さらにLinguistは、新しい拡張子やファイル名の採用に、公開GitHub上の過去1年で原則2,000ファイル以上、複数の利用者・リポジトリへの分散などを求めている。ごく小さな趣味言語は入りにくい。したがって、この増加は新言語の出生数ではなく、現実にある程度使われ、観測可能になった言語の裾野と読むべきである。^[13]

一方、GitHubの2025年Octoverseは強い集中も示した。2024年9月から2025年8月に作られた新規リポジトリの約80％は、Python、JavaScript、TypeScript、Java、C++、C#の6言語を使っていた。TypeScriptは2025年8月に月間コントリビューター260万人超となり、前年比約67％増で初めて首位に立った。新しい選択肢は増えているのに、実務の中心は既存の巨大生態系へ集まっている。^[14]

同じ報告では、GitHubの開発者は1億8,000万人を超え、1年間に3,600万人以上増えた。毎分230を超えるリポジトリが作られ、コードプッシュは約9億8,600万件で前年比25.1％増。LLM用SDKを利用する公開リポジトリは110万を超え、前年比178％増だった。ただしGitHub自身も、AI普及と活動量の間に見えるものは相関であり、単純な因果を証明するものではないと注意している。AIが増加の全量を生んだとは断定できないが、AI時代にソフトウェア活動が停滞しているとも言いにくい。^[14]

4. AIは新言語の試作を加速し、同時に既存言語をさらに強くする

2025年Stack Overflow開発者調査は、177か国から49,009件の回答を分析した。回答者の84％が開発でAIを使っているか使う予定で、職業開発者の51％は毎日利用していた。しかし、AI出力の正確さを信頼する割合は33％、不信頼は46％だった。「ほぼ正しいが、完全には正しくない」回答は66％が最大の不満として挙げた。利用の急増と信頼の低さが同居している。^[15][16]

AIが下げるのは、最初の処理系とテスト群を作る費用だ。互換性と信頼を10年維持する費用まで自動的に消えるわけではない。

能力指標は急速に伸びている。スタンフォード大学の2026年AI Indexは、SWE-bench Verifiedの上位性能が1年で約60％から人間基準のほぼ100％へ上がったと整理した。^[17] ただし、この数字をそのまま現場の生産性と読んではいけない。OpenAIは2026年2月、Verifiedの失敗例138件を監査し、59.4％に機能的に正しい提出を拒むテストや記述上の問題があったとして、最先端モデルの評価には使わない方針を示した。さらに同年7月には後継SWE-Bench Proにも約30％の壊れた課題があると報告した。ベンチマークの飽和は、能力向上だけでなく、物差しの限界も意味する。^[18][19]

現場での効果も単純ではない。METRが2025年前半に行った無作為化比較実験では、16人の熟練オープンソース開発者が、平均約5年間関わったプロジェクトの246課題に取り組んだ。AIを使える条件では完了時間が平均19％長くなった。それでも参加者は事前に24％、事後にも20％ほど速くなったと見積もっていた。^[20]

METRの2026年2月更新では、元参加者の一部について18％短縮という推定が出たが、信頼区間は38％の短縮から9％の悪化までと広い。さらに、AIなしで働きたくない人が実験参加を避け、AI向きの課題も提出されにくくなり、並列エージェント利用では作業時間の計測自体が難しくなった。METRはこのデータを現在の効果を測る信頼できる信号として扱えないと明記している。ここから言えるのは、加速が自明なのではなく、AIが工程へ深く入った結果、従来型の測定設計さえ作り直しを迫られているということだ。^[21]

それでもAIは、新言語の試作費を確実に下げる方向へ働く。文法案、パーサー、型検査器、テスト、標準ライブラリ、エディター拡張を並行して作り、既存言語の設計上の失敗も調べられるからだ。その一方、学習例が多く、コンパイラーのエラーが明確で、ライブラリが豊富な既存言語をさらに有利にする。AIはPython、TypeScript、Java、Goのコードを大量に扱えるため、無名の新言語より安定した出力を作りやすい。

つまりAIは、多様化のエンジンであると同時に、人気言語への集中を強めるエンジンでもある。

5. AIだけが書く時代でも、人間が読めるコードは消えない

AIだけがコードを書くなら、人間に読みやすい文法を捨て、短く圧縮されたAI専用表現を使えばよいように見える。しかし実務では、コードは命令であると同時に責任の記録である。障害の原因を調べ、仕様との差を確認し、悪意ある処理が混ざっていないか監査し、数年後に変更する人が内容を理解しなければならない。AIが生成しても、最終的な損害を引き受ける組織は、人間が検証できる形を必要とする。

LLMにとっても、読みやすさは無関係ではない。明確な名前、型、関数境界、テスト、文書は、次の記号を予測し、誤りを発見する手掛かりになる。GitHubが2025年のTypeScript急伸の背景として挙げたのも、型がAI生成コードの契約違反を早期に見つけやすくする点だった。型は人間向けの説明であると同時に、コンパイラーが機械的に検査できる契約である。^[14]

未来のAI向け言語は、人間に読めない暗号より、型、事前条件、事後条件、権限、失敗時の挙動を明示する方向へ進む可能性が高い。自然言語は目的を伝える入口として残るが、そのまま実行すれば曖昧さが危険になる。AIが日本語の要求を、形式的な仕様、テスト、型付き中間表現へ変換し、コンパイラーや検証器が確認してから既存言語や機械語へ落とす。人間は一行ずつ処理を書く割合を減らし、意図、制約、評価基準を書く割合を増やす。

自然言語は入口、形式仕様とテストは検問所、既存の実行基盤は道路になる。AI時代の新しい「言語」は、この全体をつなぐ層かもしれない。

コンパイルとインタープリターの境界も薄くなる

同じソースコードが、状況に応じてコンパイル実行と逐次解釈を切り替える発想は、すでに一部で実現している。言語は意味を定める規則であり、コンパイルか解釈かは主に処理系の選択である。Java仮想マシンやJavaScriptエンジンは、まず素早く実行を始め、頻繁に通る部分を実行時コンパイラーで最適化する。型の実測や利用頻度に応じ、最適化を取り消すことさえある。一つのプログラムの中で、解釈とコンパイルを段階的に使い分けている。

将来はこの適応がさらに上位へ広がるだろう。開発中は応答速度を優先して解釈し、本番では事前コンパイルする。端末では省電力版、サーバーでは並列版、GPUでは行列演算版を同じ中間表現から生成する。MoonBitの複数バックエンドやMLIRの多段階表現は、その方向を示す。^[9][11]

ただし、自動で何でも切り替えると、性能の再現性、デバッグ、課金予測が難しくなる。「最強の言語」が全方式を無条件に混ぜるのではなく、意味は固定し、実行戦略だけを測定可能な範囲で変える形が現実的である。

6. 2035年までに何言語出るのか：予測は3層で読む

第一層は、個人の実験、企業内言語、特定用途向け言語である。AIによって完成までの最低費用が急落するため、年間数百から数千作られても不思議ではない。ただし公開されないもの、既存言語の設定やAPIと区別できないもの、数日で捨てられるものも多い。出生数を正確に数えることはできず、ここに固定値を置くのは見せかけの精密さになる。

第二層は、公開GitHub上で十分に使われ、Linguistのような判定基盤へ登録される言語である。2015〜2025年の年平均23.2項目という純増を基準にすると、今後も年20〜35程度、2026年から2035年の10年間で約200〜350項目の追加を中心シナリオと見る。2026年から2030年末だけなら、おおむね100〜175項目である。AIが試作を増やす上振れと、登録には公開利用の蓄積がいる遅延を考えた幅だ。これをそのまま新発明数とは呼べない。

第三層は、主要調査へ継続して登場し、企業が本番採用する新しい汎用言語である。2026〜2035年の10年間で3〜8程度、その中で世界上位の一角へ入るものは1〜3程度と予測する。約80％の新規リポジトリが6言語へ集中する現状、既存資産との互換性、採用・教育費を考えると、数十の新言語が同時に主流化する可能性は低い。^[14]

この3〜8、1〜3という数字は統計モデルの出力ではない。過去の集中度、エコシステム構築の時間、移行費用から置いた条件付きシナリオである。景気、規制、教育、巨大プラットフォームの採用で外れる可能性はある。成功する新顔も、TypeScriptがJavaScriptを捨てずに拡張したように、Python、JavaScript、WebAssembly、Java仮想マシンなど巨大な生態系へ接続する形が有利だろう。

最も大きな変化は、プログラミング言語という名前で数えられないかもしれない。AIエージェントへの指示、データの型定義、権限規則、業務手順、テスト、評価指標を束ねた仕様言語が増え、その裏でAIが既存言語を生成する。人間から見れば日本語で依頼していても、システム内部では曖昧さを除いた構造化表現が新しい言語として働く。未来のパラダイムシフトは、新文法が旧文法を一斉に置き換える出来事ではなく、コードを書く層の上に、意図を記述して検証する層が加わることだろう。

7. 個人が新しい言語を作る5段階：最初からCPUを狙わなくていい

言語を作ることと、普及する言語を作ることは別である。まずは一つの問題を解く小さな処理系から始めればよい。

第1段階：解決したい不満を一つに絞る

日本語で命令できる、データ処理だけを安全に書ける、子どもが理解できる、GPUを簡単に使える、と対象を限定する。最初からPHP、Java、Ruby、JavaScript、Go、Pythonの全長所を集めようとすると、長所同士が衝突する。実行速度と実装の単純さ、自由度と安全性、暗黙の便利さと予測可能性には交換条件がある。

第2段階：言語の意味を小さく固定する

数値、文字列、変数、足し算、条件分岐、繰り返し、関数だけでもプログラムは作れる。日本語、英語、アラビア語のどれを表面に使ってもよい。Unicodeのおかげで文字自体は大きな障害ではない。ただし、同じ文が必ず同じ意味になる文法と、エラー時の規則を決める必要がある。

たとえば最初の言語が次の一行しか扱えなくても、入力、意味、出力が決まれば立派な出発点になる。

足す 2 3

第3段階：入力を構文木へ変える

「足す 2 3」を、足すという命令と二つの数値に分け、加算を根に持つ木構造へする。手書きの構文解析器でもよく、ANTLRやTree-sitterのような既存の道具も使える。AIには、文法、テスト、正常例、異常例のたたき台を並行して作らせるとよい。ただし、AIが作った文法と実装が食い違っていないかは、同じ入力に対する期待値で固定する。

第4段階：既存の実行環境を借りる

構文木をその場で評価するインタープリターにするか、JavaScript、Python、C、WebAssemblyのいずれかへ変換する。最初からCPUごとの機械語を生成する必要はない。Goの初期処理系がCへ変換したように、コンセプトの正しさを既存基盤で確かめる方が速い。性能が必要になってからLLVMやMLIRへ接続すればよい。^[5][11]

第5段階：言語ではなく利用環境を作る

標準ライブラリ、パッケージ管理、フォーマッター、エラー表示、デバッガー、エディター補完、文書、互換性方針、セキュリティ検査が必要になる。小さな実用品をその言語自身で作り、第三者が説明なしで導入できるかを確かめる。この段階を越えて初めて、面白い処理系が、他人の時間を預かれるプログラミング言語になる。

成功判定は「コンパイラーが動いた」ではなく、次の5問で行うとよい。

1. 初めて触る人が30分で実行できるか。
2. 間違えたとき、エラーが原因と修正位置を示すか。
3. 一年前のコードを新しい処理系で動かせるか。
4. パッケージの出所と権限を追跡できるか。
5. 作者が一週間不在でも、他人が問題を切り分けられるか。

AIは最初の実装を速くする。しかし、これらの問いに答えるのは、設計、運用、共同体の仕事である。

8. 未来に残るのは、文法の派手さより検証可能性である

過去70年以上の歴史を見ると、新言語は、機械の都合を隠すためだけに生まれたのではない。科学者、事務担当者、学生、巨大システムの開発者、Web制作者、分散システムの運用者が、今の道具では扱いにくい問題へ直面したときに生まれてきた。AIエージェントの時代にも、その構造は変わらない。変わるのは、試作品を作る速度と、最初の利用者が人間だけでなくAIにもなることである。

ぽちょ研究所として未来を一文でまとめるなら、こうなる。

新言語は数の上では活性化する。表面では既存言語への集中が進む。その間に、AIが理解する仕様と、人間・機械が検証する層が新設される。

人がコードを一文字ずつ書かなくなっても、何を許し、何を禁止し、正しさをどう判定するかは記述しなければならない。その記述体系も、広い意味ではプログラミング言語である。

電気が光る仕組みを知ることと、自分で発電所を建てることが別であるように、コンパイラーを完成させなくても、文字が構文木、中間表現、機械命令、電気信号へ変わる流れを知る価値はある。AIが実装を代行するほど、人間に残る仕事は、問題を分解し、意味を固定し、出力を検証することへ移る。

未来の最強言語は、すべての機能を詰め込んだ一つの文法ではない。人間の意図、AIの生成、機械的な検証、既存の巨大な実行基盤を、最短かつ監査可能な経路で結ぶ仕組みになる可能性が高い。

注記：本記事の2035年予測は、公開データと歴史的傾向に基づくシナリオであり、確定的な予言ではありません。Linguist項目数は言語の発明数や利用者数を直接表すものではなく、GitHub・Stack Overflow・ベンチマークの数値も、それぞれの母集団と測定方法に依存します。