更新：2026年8月。
20年間、「どの言語を選ぶべきか」という問いは、常に「キーボードを打つ人」の視点から答えられてきた。つまり、どの言語が速く書けて、読みやすく、人材の確保が容易で、ライブラリが豊富か、という観点だ。2026年初頭から、その問いは根本から変わることになる。 プロジェクトのコードの大部分がもはや人間の手によって記述されなくなるにつれ、「書き心地の良さ」という基準の重要性は大幅に低下する。その代わりとなるのは、はるかに異質な基準だ。すなわち、その言語が、コードがどれほど正確か、どれほど高速か、そしてどれほど低コストかを、機械が自ら証明できるかどうかである。
これは「どの言語が優れているか」を競うコンテストではありません。これは、ソフトウェア業界のボトルネックが別の場所へと移り変わり、その周囲のあらゆるもの――コンパイラ、ツール、さらには言語の人気度を測る方法に至るまで――が、その新しい位置に合わせて再編成されつつあるという状況なのです。
ボトルネックが解消された：生コードの価格は下がったが、ニュースコードの価格は変わらない
形式的に妥当なコードを作成するためのコストは、電気代とほぼ同水準まで低下した。そのコードが正しく機能することを確認するためのコストは、ほとんど低下していない――なぜなら、それは依然として、十分な文脈を理解しているエンジニアによる読み込み時間に依存しており、それがこの業界で最も高価かつ再現が最も難しい要素だからである。
その結果は極めて直接的なものです。かつては、「緩い」言語こそが効率的な言語とされていました。記述する文字数が少なく、テストの実行も速く、そしてコードを書く側であるあなたは、そのコードがどのような前提に基づいているかというモデルを頭の中に保持し続けることができたのです。 しかし今では、コードは機械によって生成され、機械はその頭の中にあるモデルを私たちに引き渡してはくれない。引き渡されるのはテキストだけだ。もしその言語が、そうした前提を検証可能な形として明示するよう強制しなければ、それらは消えてしまう――そして3週間後、午前2時の障害という形で再び現れることになる。
言い換えれば、希少なのはもはやコードそのものではない。希少なのは、そのコードが正しいという根拠のある確信である。そして、その確信を数秒で実行可能な命令に変換できる言語こそが、勝者となる。
なぜ、気難しいコンパイラが突然強みになったのか
エージェントは、提案 — テスト実行 — エラーの読み取り — 修正 — 繰り返し、というループに従って動作します。 このループの出力品質は、研究者の間で「オラクル」と呼ばれるものの品質にほぼ完全に依存しています。オラクルとは、「間違っている」ことを自動的に判定するソースであり、さらに言えば「どこが、なぜ間違っているのか」を教えてくれるものです。
優れたオラクルを決定づける3つの特徴：
- 早期発見。コンパイル時にエラーが見つかる方が、実行時に見つかるよりも数十倍安く済み、本番環境で発見されるよりも数千倍も安上がりです。
- 構造化された診断。ファイル、行、列、エラーコード、修正のヒントを明確に示したメッセージは、エージェントが即座に処理できる。スタックの最下層にある「Segmentation fault」や「TypeError」といった一行のメッセージは、ほとんど役に立たない――エージェントは推測するしかなくなる。
- 有効なプログラムの範囲を絞り込む。これはあまり語られることのない点だが、最も重要である。厳格なデータ型、徹底的なパターンマッチング、明確に処理されるエラー、所有権のルール――それぞれの制約が、誤ったプログラムのファミリーそのものを事前に排除する。 モデルは確率に基づいてテキストを生成します。制約が厳格であればあるほど、「一見妥当だが間違っている」部分は、誰かがそれを実行する前に排除されていきます。
そのため、2026年には、研究者の間ではコンパイラや言語サーバーが人間のためのツールではなく、機械のための監視信号源であると見なされるようになった： コンパイラや言語サーバーからのフィードバックを直接報酬として用いる学習手法が登場し、NeurIPS 2026では、エージェントが定理証明システム、モデルチェッカー、SMTソルバーと連携して動作する「検証可能なコード生成」というテーマに特化したワークショップが開催された。 かつて「プログラマーの体験」と呼ばれていたものは、今やマシン間インターフェースとなっている。
しかし、ランキングは逆の結果を示している
もし上記の主張が正しければ、静的型付け言語が急成長しているはずだ。しかし、2026年の実情はもっと複雑で、Pythonが依然として圧倒的な強さを示している。 2026年半ばのTIOBE指数によると、Pythonのシェアは20％前後——ここ数年、どの言語も到達できなかった水準——に達しており、わずか1年で数パーセントポイントも急上昇している。 別の方法で測定を行っているRedMonkの2026年1月のランキングでは、依然としてJavaScriptが1位、Pythonが2位、Javaが3位となっており、トップ20の順位はほぼ横ばい状態だった。
二つの力が互いに逆方向に引き合っており、どちらも真実である：
- Pythonを牽引しているのはAIインフラです。 モデルに関連するあらゆるもの――トレーニング、サーブ、評価、エージェントの構築――は、すべてPythonを経由するのが最短の道です。さらに、モデル生成において最も優れた言語は、公開データが最も豊富な言語であり、そのリストのトップにはPythonとJavaScriptが名を連ねています。これは自己強化的な好循環です。
- 静的型付けへの牽引力は、前述の検証ニーズによるものです。 これは言語のランキングとして現れるのではなく、その言語がどのように実行されるかという形で現れます。つまり、生のJavaScriptの代わりにstrictモードのTypeScriptが使用されたり、「動けばいい」というPythonの代わりに、完全な型注釈とCIでの強制的な型チェックが導入されたりするということです。
RedMonk自らが警告していることを率直に述べておくべきでしょう。従来の指標は次第に機能しなくなっているのです。 Stack Overflow上の質問数は、プログラマーがモデルについて直接質問するようになった今、利用状況を反映しなくなっている。GitHub上のプルリクエスト数は、コード生成のペースが加速しているにもかかわらず、変更の集計方法が以前とは異なるため、奇妙な変動を見せている。つまり、現段階における言語のランキング数値は、正確な測定値ではなく、あくまでトレンドの指標として捉えるべきである。
和解の分野：動的な言語に検証メカニズムを組み込む
2026年の最も興味深い点は、Pythonが敗北したとかRustが勝利したということではなく、業界が第三の道を選んだことにある。つまり、動的言語を維持しつつ、エージェントのループ内に収まるほど高速な検証層をその周りに構築したのである。具体的な節目は以下の通りである：
- TypeScript 7は2026年半ばに正式リリースされる予定で、Goで一から書き直されたコンパイラ（コードネーム「Corsa」のプロジェクト）を搭載しており、プロジェクト全体の型チェックにおいて、旧バージョンよりも約1桁高速化されている。 これは単なる利便性の問題ではありません。モノレポ全体の型チェックに10分かかる場合、エージェントは修正のたびにそれをオラクルとして利用できませんが、数秒で済むようになれば可能になります。 公平を期して付け加えると、最初のバージョン7.0にはまだ安定したプログラミングAPIが備わっていないため、一連の関連ツール（typescript-eslint、Vue、Svelte、Astroの型チェッカー）はすぐには動作せず、移行は段階的に行う必要があります。
- Pythonには、Rustで書かれた新世代の型チェッカーがあります。Astralの「ty」とMetaの「pyrefly」です。どちらも、毎晩実行するのではなく、継続的に実行できるほど遅延が小さいことを目指しています。 uvやruffも加わり、2026年のPythonツールチェーンはコア部分をほぼRustに置き換えた状態となった。そして2026年3月、OpenAIがAstralを買収したことは、Pythonのツールインフラが単なる付随的なユーティリティではなく、「エージェント時代」における戦略的資産と見なされていることを示す、かなり明確なシグナルである。
- Python自体も実行環境を変更した。バージョン3.14から、GILなし版は実験段階から正式サポートに移行し、実験段階のJITも併せて提供された。 フリースレッド版のシングルスレッドあたりのオーバーヘッドは前世代に比べて大幅に低減しましたが、互換性が宣言されていないCライブラリによってGILが再び有効になってしまうため、これはスイッチを切り替えるような一朝一夕の作業ではなく、数年を要する移行プロセスとなります。
これら3つの共通点：型チェックツールの処理速度は、構文と同等に、言語の機能の一つとなっている。正確ではあるが処理が遅い型チェッカーは、エージェントの世界では事実上存在しない。なぜなら、ループ内に収まるだけの速度がないからだ。
検証の階段――そして、私たちは今、どの段に立っているのか
すべてを段階別に整理してみると、より明確になります。段階が上がるごとに、エラーが1つ増え、コストも少し高くなります――仕様書の作成にかかる労力と、マシンの稼働時間の両方の面で。
最高レベル――形式証明を伴うコード生成（vibe codingと区別するため、暫定的にvericodingと呼ぶ）――は、2026年の研究において最も活気のある分野である。 コンセプト：開発者が仕様を記述し、機械が実装部分と証明部分を生成し、独立した検証システムがプログラムが仕様に準拠していることを確認する。 Dafny、Verus（Rust）、Lean向けのベンチマークセットがすでに存在し、証明を容易にするために設定の修正を反復するモデルを含む閉ループプロセスも確立されている。結果は十分に興味深いものであり、場合によっては、書き手によるコードのバグを発見することさえある。
しかし、その限界については正直でなければならない。このレベルは依然として狭い。 これには形式仕様書が必要となるが、正しい仕様書を書くことは、正しいプログラムを書くことと同じくらい難しい。また、かなりのマシン時間を要する。そして、これには固有の落とし穴がある。誤った仕様書に基づいて正しく動作するソフトウェアであっても、それは依然として誤ったソフトウェアであり、単に「非常に正式な形で」誤っているだけなのである。 2026年8月現在、実戦部隊の大部分はレベル2から4に位置している――静的型付け、厳格な型付け、そしてプラットフォームシステムにおいてはRustの所有権モデルが加わる。
Rust：予想した人が少なかった点で勝利した
2026年、Rustは「人気の言語」という段階を終え、「必須の言語」という段階に入った。 その圧力はコミュニティからではなく、規制当局から生じている。サイバーセキュリティ当局は、インフラソフトウェアプロバイダーに対し、メモリ安全な言語への移行ロードマップを策定するよう義務付けており、その期限は2026年初頭に設定されている。 さらに、LinuxカーネルにおけるRust製ドライバーが試験運用段階を終え、本番環境でRustを採用する企業の割合も増加し続けている。
しかし、もっと興味深い論点は別のところにある。Rustの最大の障壁は、昔からずっと、学習コストとborrow checkerとの格闘にかかるコスト――つまり、人間の苛立ちという形で支払われるコストだ。 そのコストは、機械には苛立ちがないため、大幅に削減された。借用チェッカーに20回拒否されたエージェントでさえ、エラーメッセージを読み、初回と同じ熱意を持って再試行する。 かつて人間にとってRustの最大の欠点だったものが、実はエージェントにとって最も必要なものだったのだ。つまり、容赦なく、理由を明確に説明し、常に同じ答えを出す審判である。
言い換えれば、同じ言語的特性であっても、ユーザーが変わればその難しさも変わる。人間にとっては難しく、機械にとっては簡単だ。
経済コーナー：ループが1回失敗するたびに、実際の金銭的損失となる
この件は、3つの経路を通じて金銭に結びついており、そのすべてが測定可能です。
第一に、1ループあたりのコストです。エージェントが誤った予測をして修正を余儀なくされるたびに、1回の推論が行われます。つまり、トークンの入力、トークンの出力、CIの実行時間です。 コンパイル段階でエラーが検出される言語――実行も、環境構築も、実データも不要――であれば、その後のコストのかかるループのほとんどを削減できます。毎週数千ものエージェントタスクを実行するチームにとって、タスクごとに数ループの差は、請求額に明確に表れる差となります。
第二に、そしてはるかに大きな問題として、人間によるレビューのコストがあります。型チェック1回にかかるコストは数セント程度ですが、上級エンジニアが1時間コードを読むには数十ドルかかり、そのリソースは伸縮性がありません。レビューが必要なコード量が数倍に増えたにもかかわらず、レビュー担当者の人数が変わらない場合、人間が新たなボトルネックとなります。 したがって、プログラミング言語を選択する基準は、金融用語で言えば、「エラー総数に占める、機械によって検出されたエラーの割合」となります。機械側に1パーセントポイントが移行するごとに、人間は1パーセントポイント分の時間を解放され、人間にしかできないこと――つまり、構築中のものが本当に構築すべきものかどうかを判断すること――に充てることができるようになります。
第三に、インシデントのコストです。本番環境に漏れ出したバグは、CI段階で阻止されたバグよりも数段コストが高くなります――サービス障害、データの破損、セキュリティ上の脆弱性などを含めてです。 これは、保険会社や規制当局が注目し始めている点でもあります。機械生成コードの割合が増加するにつれ、「自分のコードについて何を証明できるか」という問いは、技術的な問題から法的責任の問題へと移行しつつあります。 機械による検証が可能な言語やツールは、リスクの観点からより安価であり、それは最終的に損益計算書に反映されるのです。
混同しやすい箇所
- 静的型付けは、意図の誤りを検出できない。 あるプログラムは型に合致し、コンパイルも問題なく、スムーズに動作しても、顧客が求めていることを完全に間違っている可能性がある。コンパイラはそれ自体に対して一貫性のある型チェックを行うが、問題を正しく解決しているかどうかはチェックしない。これが、エンジニアの最も重要な仕事が、要件の明確化とシステム境界の設計へと移行しつつある理由である。
- データが少ない言語は二重の不利益を被る。新しい言語は、その設計がどれほど優れていても、モデルがそれをあまり認識しないため不利になり、その結果、生成されるコードの質が低下する。逆説的だが、AIの時代は、人間にとって新しい言語を学ぶことを容易にする一方で、新しい言語を普及させることをより困難にしている。
- その逆の側面は意外なものです。レガシー言語が救われているのです。エージェントがCOBOLやFortranをかなり高いレベルで読み込み、修正できるからこそ、古いシステムの維持・近代化コストは大幅に削減され——かつてそれらを書き換える理由そのものが弱体化しているのです。すべての言語が生き残るために「勝つ」必要はありません。
- 「型付き」と「厳格な型」を混同してはいけない。anyを至る所に散りばめたTypeScriptプロジェクトは、JavaScriptとほぼ同等の弱いオラクルしか持たない。価値は「厳格モード」と、CIでツールがゲートを閉ざすことにあるのであって、言語名にあるのではない。
予測
- 分岐は言語間ではなく、言語内部で生じている。PythonとJavaScriptは使用数ではトップを維持しているが、真剣に扱われるバリエーションでは、CIにおいて型チェックが必須となるのがデフォルトとなっている。「型注釈のないPython」は、次第に使い捨てのスクリプト専用なものになりつつある。
- ツールチェーンの速度が言語選択の基準となっている。TypeScriptがGoで書き直され、PythonのツールセットがRustで実装された後、同様の取り組みを行うエコシステムがさらに増えるだろう――その暗黙の目標は、プロジェクト全体の検証時間を数十秒以下に抑えることにある。
- Rustは引き続きインフラ分野でシェアを拡大しており、その一因は技術的ではない理由にある。メモリ安全性の規制圧力に加え、エージェントループにおける優位性により、Rustは新しい基盤層のデフォルトとなっている。とはいえ、CやC++は今後数十年にわたり、依然として膨大な量のコードを占め続けるだろう。
- Vericodingは実験室の段階を脱したが、最もコストのかかる分野にのみ導入されている。暗号、OSカーネル、決済システム、医療・航空ソフトウェア――ここでの1つのエラーのコストは、形式仕様書の作成費用を十分に賄えるほど大きい。業界のその他の分野は、依然として静的型付けとテストの段階にとどまっている。
- 高価値なスキルは変化している。「言語Xの構文を知っている」ことではなく、検証フレームワークを構築できるかどうかが重要だ。つまり、仕様書を作成し、不正な状態が表現されないようにデータ型を設計し、不変条件を設定し、プロパティテストを作成し、エージェントのループをどこで停止させるかを知っていることである。
- 人気の尺度も再定義されることになるだろう。プログラミングの議論がモデルとのプライベートな対話へと移行し、コードの大部分が機械生成されるようになると、公開フォーラムやコミット数に基づく指標は次第に意味を失っていく。おそらく、実際に実行されているコードに基づいた新しい測定方法が生まれるだろう。
要するに、2026年の言語競争は、美しい構文や豊富なライブラリによって決まるのではなく、ある淡々とした問いによって決まるのだ。すなわち、「1秒の間に、この言語は生成されたコードについてどれだけのことを証明できるか？」という問いである。 多くのことを答えられる言語であれば、エージェントの収束は早くなり、レビュー担当者の負担は軽減され、節約されたコストは実質的な利益となります。答えられることが少ない言語でも生き残ることはできますが、他から「鎧」を借りなければならず、実際、業界全体が今まさにその「鎧」を借りることに忙殺されています。
Thảo luận