「迅速なリリース」という妥協の終焉：なぜAIが言語選択をシステム言語へとシフトさせているのか

過去10年間、ソフトウェアエンジニアリングにおける支配的な考え方は、「実行速度よりも、リリース速度が勝る」というものでした。開発者はPythonやTypeScriptをデフォルトとして選択してきました。その理由は、エコシステムが広大であり、採用の母集団が深く、アイデアから動作するデモまでの摩擦が最小限だったからです。Rust、Go、あるいはC++のようなシステム言語は、桁違いに優れたパフォーマンスを提供してきましたが、その代償は高く、学習曲線が急峻で、開発サイクルが遅く、ビルドシステムがしばしば敵対的に感じられるものでした。

その妥協は終わりました。高機能なAIエージェントの出現は、言語選択の計算式を根本的に変えました。コーディングの「困難な部分」——メモリ安全性、並行性、厳格な型システムの管理——がエージェントによって処理されるようになると、システム言語のランタイム上の利点が、スクリプト言語の人間工学的な利点（使いやすさ）を上回り始めます。

フィードバックループ：なぜAIは「難しい」言語を好むのか

直感に反して、人間にとって習得が最も困難であった言語が、AIエージェントにとって最もターゲットにしやすい言語になりつつあります。これは主に、強力な型システムと厳格なコンパイラが提供する密接なフィードバックループによるものです。

業界の観察者が指摘するように、RustはAI支援開発に特に適しています。Rustのコンパイラは非常に明示的であり、エラーメッセージも非常に正確であるため、高品質なトレーニングシグナルを継続的に提供します。エージェントがコンパイルに失敗するコードを生成した場合、コンパイラのフィードバックによってモデルはリアルタイムで自己修正を行うことができます。この環境において、コンパイラはPythonの動的な性質では不可能な方法で、正しさを保証するガードレールとして機能します。

シフトの証拠：論文からプロダクションへ

AIによるオーケストレーションにより、以前必要だった時間のわずかな一部で、高複雑度なプロジェクトが完了する急増が見られます。

TypeScript Compiler: Microsoftは最近、TypeScript compilerをGoに移植しました。これにより、10倍のパフォーマンス向上を達成しました。この決定は、Goが従来のエンジニアリングコストのわずかな一部で、必要なパフォーマンス向上を提供したという事実に基づいています。
C Compilers in Rust: 研究者たちは、並列化されたClaudeエージェントを使用して、RustでプロダクショングレードのC compilerを書き上げました。これはかつて大学院の論文テーマであったタスクですが、比較的低いAPIコストで、わずか数週間で完了しました。
Engine Porting: LadybirdブラウザのJavaScript engineは、AIの指示によってC++からRustへ2週間で移植されました。これにより、数万件のテストにおいて、回帰なしでバイト単位での一致を達成しました。

「エコシステム」論争の侵食

歴史的に、Pythonの最強の論拠は、そのエコシステム（FastAPI, PyTorch, pandas）でした。しかし、Pythonエコシステムの基盤となる「配管（plumbing）」がRustで書き直されているため、この利点は侵食されつつあります。

Polars, Pydantic, そしてHugging Face tokenizersのようなライブラリは、ますますRustベースになっています。Pythonエコシステムは「Pythonの帽子を被ったRustエコシステム」になりつつあります。コアロジックがすでにシステム言語で書かれている場合、Pythonのラッパーは不要なオーバーヘッドのように見え始めます。この傾向は、Astral（uvとruffの作成者）がOpenAIによって買収され、BunがAnthropicによって買収されたことによってさらに裏付けられています。これは、AIラボが、高性能なツールキットをAI主導のエンジニアリングにおける不可欠なインフラストラクチャと見なしていることを示しています。

パッチ適用から移植へのシフト

AIエージェントは、オープンソースにおける貢献の単位を変えつつあります。従来のモデルでは、開発者が依存関係内のバグを見つけ、パッチを提出していました。現在、ライブラリ全体を別の言語へ移植するコストは急落しています。

"For me, the value is shifting from the code to the tests and documentation. A good test suite might actually be worth more than the code."

もしライブラリの言語間移植が、数ヶ月の労働ではなく、数分間の人間の監督によるタスクになれば、レガシーな依存関係を維持するインセンティブは弱まります。「フォークして移植する」能力が、「パッチを当ててアップストリームへ送る」必要性を取って代わります。

反論と制約

このシフトは、しかし、絶対的なものではありません。いくつかの重要な制約が残っています。

1. Human-in-the-Loop

批判的な意見として、チームが知らない言語での「vibe-coding」は、災難へのレシピであると主張されています。AIがパフォーマンスの高いRustアプリを生成することはできますが、人間は依然として正しさを判断する審判として機能しなければなりません。もしプロダクション環境で重大なバグ（例えば、高負荷時のみ発生する$O(N^2)$の計算量問題など）が発生した場合、その言語を読めないチームは、迅速に修正することができず、無力になるでしょう。

2. Training Data Bias

AIの習熟度は、トレーニングデータの量に依存します。RustやGoはGitHub上での人気により恩恵を受けていますが、Zig, Haskell, または Gleamのようなニッチな、あるいは高度に専門化された言語は、エージェントが効果的に機能するための十分なデータ量がいまだに不足しています。言語の固有の論理に関わらず、言語のデータ量に不足がある状態です。

3. Domain Dominance

ディープラーニングの研究分野において、PyTorchの支配力は変わらないでしょう。モデルの重みは、ラップする言語に依存しません。研究コミュニティは、実行効率よりも反復速度を優先します。

結論：新しい体制

過去20年間の言語選択は、「人間は低レベル言語の扱いに時間がかかる」という制約によって形作られてきました。その制約は消えつつあります。人間の役割は、「コードを書くこと」から「システムのアーキテクチャを設計し、出力をレビューする」ことへとシフトしています。

この新しい体制において、Pythonの人間工学的な利点は重要性を失い、一方でシステム言語のランタイム上の利点は複利的に増大していきます。私たちは、最も成功する言語は、人間にとって書きやすい言語ではなく、エージェントがターゲットにしやすく、検証しやすい言語となる時代に入っています。