「AIにおすすめの言語」で検索してみた。出てくるのはPython、R、Julia。中には本文に「2019年5月現在」が消し忘れで残っているリライト記事もあった。

読んで、あれ、と思った。欲しかった答えとズレている。

矢印が逆になっている

この手の記事が答えているのは「言語でAIを作るなら、どれがいいか」だ。機械学習のライブラリが厚いPython、統計に強いR。矢印は言語からAIに向いている。この問いを軸1と呼ぶことにする。

でも今、俺が知りたいのはその逆だ。「AIに書かせると、何になるか」。矢印が逆を向いている、軸2の問いだ。

普段Claude Codeにコードを書かせていて、これは体感でもう分かっている。答えはTypeScriptだ。何か新しいものを作らせると、指定しなくても大抵TSかJSで返ってくる。「AIにおすすめの言語」でググって出てくる地図は、この矢印が逆になった世界にはもう使えない。

じゃあなぜTSなのか。ちょうど手元のニュースが、その理由をきれいに裏付ける形になっていた。

JSツールチェーンが、静かにRustへ替わっている

ここ数週間、俺のニュースまとめにRustの文字が何度も出てきた。ビルドツール「Vite 8.0」が正式リリースされ、バンドラにRust製の「Rolldown」を採用した。開発元のVoidZeroはCloudflareに買収された。webpack、Babel、ESLint、Prettier。JS/TS製でシングルスレッド・GC任せだった定番ツールが、次々にRust実装へ置き換わっている。

理由は単純で、速い。ネイティブでGCが無く、マルチスレッドで回るRust製ツールは、従来比で10〜30倍速い。しかもOxcのようなRust製の共通パーサ・AST基盤が育ったことで、バンドラ・トランスパイラ・リンタ・フォーマッタがバラバラに同じコードを再パースしていた無駄も解消されつつある。Rollup互換のRolldown、webpack互換のRspack、ESLint+Prettier互換のBiome。既存の設定や資産を壊さず、中身だけ差し替えられる作りになっているのも普及を後押ししている。

ただし、この流れはAIブーム以前、esbuildが出た2020年頃から続いている。動機は速度とツールの分断解消であって、直接AIが引き金ではない。

とはいえ、間接的にはよく噛み合う。AIエージェントは「編集→ビルド→テスト→lint」を1つのタスクの中で何十回も回す。ツールが速いほど、その反復は安く速くなる。ビルドが数十秒かかれば、それはそのままエージェントの待ち時間とトークン課金に跳ね返る。AI生成でコード量が増えれば、ビルド・解析の総量も増える。Publickeyの2026年予想記事が「AIエージェント前提の開発」と「Rust採用拡大」を並べて書いていたのも、この相性のよさゆえだと思う。

TSは「言語」として盤石、「実装」は母国語を離れる

このRust化の波の中で、TypeScriptの立ち位置が面白いことになっている。言語としてのTSはむしろ強化されている。Node/Deno/Bunが.tsの直接実行に歩み寄っていて、揺らぐ気配がない。

一方で、TSを処理する側の実装はどんどんネイティブ化が進んでいる。型変換はSWCやesbuild、Oxc(Rust/Go)が担い、極めつけは型チェッカーのtscそのものだ。Microsoftが2026年6月25日、TypeScript 7.0のRC（Project Corsa）を出した。移植先はGo。コンパイルは約10倍、エディタ起動は約8倍速くなり、メモリ使用量はほぼ半減。GoogleやNotion、Slack、Vercelがすでに社外採用している。

ここで一つ引っかかる。速度を突き詰めるならRustのはずだ。なのになぜGoを選んだのか。

答えは「Goが優れているから」ではなく、「既存のtscをそのまま移植できるから」だった。tscの中身は、AST・型の相互参照・循環構造を持つ巨大な可変オブジェクトのグラフで、GCを前提に書き換えまくる作りになっている。Goならこの構造をほぼ1:1で機械的に移植できる。Rustだと所有権と借用が循環参照や可変グラフを嫌うので、ゼロから設計し直しになる。開発者のAnders Hejlsberg本人も、「Goを選んだのは、このコードベースを10倍速にする最短経路だったからだ」と、言語としての優劣でなく移植性・実利で選んだことを明言している。

tscの実装がGoになったのは「Goが最適だから」ではなく、既存資産をそのまま移植できるという経路依存だ。理屈の正しさより、積み上がった経路が勝つ。実はこれ、後で書くTSが言語として勝っている理由（技術的な最適さでなく、Web独占とコーパスの経路依存）と同じ構図をひと足先になぞっている。

「TSで書く」ことは変わらないのに、「TSを処理するツール自体」はTSという母国語を離れていく。TS7.0はこの命題のリアルタイムな実証で、TSの公式コンパイラがもうTSで書かれていない。それでいて採用企業の顔ぶれを見れば、言語としてのTSが盤石なことも同時に裏付けられている。

AIがTSを選ぶ理由は、型の「質」じゃない

さて、本題に戻る。なぜAIに書かせるとTSになりがちなのか。

「型があるから、AIが検証しやすいんだろう」と考えたくなるが、これは訂正が要る。型がAIの検証可能性を高めるのは型付き言語全般の話で、TS固有の優位ではない。しかもTSの型は意図的にunsoundで、厳密さで言えばRustやHaskellの方が上だ。純粋に型の質だけで比べたら、勝つのはTSじゃない。

じゃあ何が効いているのか。Web・npmエコシステムの独占はまず外せない。ブラウザで動く言語は実質JSしかなく、代替が効かない構造的な堀がある。それとLLMの学習量。GitHubのOctoverse 2025によると、TypeScriptは2025年8月時点でPython・JavaScriptを抜き、月間コントリビューター数で首位（263.6万人）に立った。前年比66%増、この10年で最大級の順位変動だという。

ここで一つ裏を取ってみたら、話がねじれた。「型があるから、雑に生成して後で締める反復に向いている」という説明を持っていたが、実測はむしろ逆だった。mame氏が公開しているベンチマークは、Claude Codeに13言語でプロトタイピングタスクを解かせて時間とコストを比較している。最速・最安・最安定だったのはRuby・Python・JavaScript。TypeScriptではない。15言語中11位で、時間はJavaScript比1.6倍、コストは6割増。型システムのオーバーヘッドが、エージェントの反復をむしろ遅くしていた。

型がAIの間違いを早めに捕まえる効能自体は本物らしい。ある研究では、LLMが吐くコンパイルエラーの94%が型チェック失敗だったと報告されている。静的型付けは、AIの粗さが本番に届く前に止める網として機能する。でも、それとエージェントが実際に速く安く書けるかどうかは別の軸で、実測では型のコストの方が上回っていた。

だとすると、TSの隆盛は「AIが技術的に一番うまく書けるから」という説明では足りない。GitHubの開発者アドボケイトはこの現象を「convenience loop（利便性のループ）」と呼んでいる。AIが何かを楽に感じさせる技術に開発者が流れ込む。それが学習データを増やし、AIをその技術でさらに上手くする。TSは単にこのループに一番早く乗った言語で、乗ってしまえば技術的な優劣とは無関係に回り続ける。

「AIが一番うまく書けるのがTSなので、放っておくとそこに寄る」と思っていたが、正確には「AIが一番うまく書けるかどうかとは関係なく、乗ったループが大きいから寄る」だった。そしてこれは、この記事で二度なぞってきた構図の三度目の顔だ。TSが言語として勝つのも、tscの実装がGoになったのも、AIがTSに寄っていくのも、根っこは同じ。理屈の正しさより、積み上がった経路が勝つ。

経路依存は、壁にもなる

ここまでの話は、経路依存が「乗ってしまえば加速する」側の例ばかりだった。TSのconvenience loop然り、tscのGo移植然り。でも経路依存には逆の顔もある。積み上がった経路のせいで、動けなくなる側だ。

分かりやすいのは金融系のCOBOLだ。何十年も前のシステムが、いまだに勘定系の核で動き続けている。技術的には塩漬けそのもので、書き直したい人はずっといたはずだ。でも動かない。

COBOLが動かない理由を、最初は「人」の問題だと思っていた。当時書いた人はもう退職か、下手をすると鬼籍に入っている。仕様書は残っていない。今COBOLを読める若手も減っている。だとしたら、これはAIが一番得意な領域のはずだ。大量の未文書化コードを読んで説明させる仕事は、今のLLMがまさにやりたがっていることだから。実際、AWSは古いコードベースを機械でスキャンして技術的負債を洗い出す製品を出していて、レガシーコードの移行支援は今のAI活用の主戦場の一つになっている。

でも、それだけでは足りない気がしてきた。COBOLの勘定系は何十年もパッチが積み上がっていて、「なぜこの1行が存在するか」の答えが、たとえば「何年か前に起きた特定のエッジケースの回避」だったりする（実例ではなく、ありがちな話として）。AIがそのロジックを読んで説明することはできる。理解の壁は、たしかにAIが崩しつつある。

でも、書き直したものが元と寸分違わず同じ挙動をすると証明する壁は残る。本番で起こりうる全取引パターンに対して新旧システムが一致することを、規制当局や監査に納得させる必要がある。これは「読んで理解する」作業ではなく「起こりうる全部を洗い出して確かめる」作業で、コード理解の速さとは別の軸にある。AWSがCOBOLモダナイゼーションの実例から得た知見でも、失敗の主因は移植の技術力不足でなく、実運用データでの機能的同等性を証明できないことや、組織側の見積もり違いだと指摘されている。

つまりCOBOLの壁は一枚岩じゃない。理解の壁と証明の壁が重なっている。AIが崩しつつあるのは前者で、後者はまだ人間の信頼の速度でしか動かない。

TSの経路依存は、乗るだけで加速する堀だった。COBOLの経路依存は、崩れかけている壁と、まだ崩れない壁が重なった壁だ。同じ「理屈より経路が勝つ」構図でも、AIが変えられる部分と、変えられない部分がある。

だから、当面はTSに張る

最初の「AIにおすすめの言語」の話に戻る。あの手の記事の地図は、言語でAIを作る時代のものだ。今欲しいのは、AIに書かせると何になるかの地図で、軸が違う。古い地図で言語を選んでも、今の問いには答えられない。

軸2の答えは今のところTSで、それを支えているのは技術的な最適さでなくconvenience loopの規模だ。ループが大きいものはそう簡単には崩れない。技術的な最適解かどうかとは関係なく、当面はTSに張るのが合理的な判断だと思う。ただ、純粋に「今すぐ最速で動くプロトタイプが欲しい」だけなら、TSより素のJavaScriptやPythonの方がエージェントは速く安く書き切れる、というのは覚えておいていい。これから何かを学ぶ人が言語で迷っているなら、「AIにおすすめ」で出てくる古い記事より、AIエージェントに実際に何をどれだけうまく・どれだけ速く書かせられるかの方を見た方がいい。