AI がコードを書くなら、なぜ Python なのか — 検証コストが言語を選び直す

Python が過去 10 年間トップでいられた理由は「人間が速く書き、速く読める」ことだった。人間がほとんどコードを書かなくなり、レビューするときにコンパイラが横に居るかどうかが時間あたりコストを決めるとしたら、その「トップの根拠」はそのまま残るのか。

導入 — ふたたび始まった言語戦争

2026 年 5 月 1 日、Medium に投稿された一本の短い記事が Hacker News のフロントページを占めた。タイトルは「AI が君のコードを書くなら、なぜ Python を使うのか(If AI writes your code, why use Python?)」。記事自体の分量は長くない。核となる主張はわずか一行で要約できる。「過去 10 年間、速く出荷すること(fast-to-ship)が速く実行すること(fast-to-run)に勝った。もうそうではない(For the last decade, fast-to-ship beat fast-to-run. Not anymore)。」しかしコメントは 922 件付き、総合スコアは 868 点に達した。単一のブログ記事への反応としては異例の規模である。

この記事が神経を逆撫でした地点は単純である。Python という言語がこれまで受けてきたあらゆる弁護 — 可読性、表現力、学習曲線、豊富なライブラリ — は、実は「人間がコードを書く」という前提の上でだけ成立する、という事実を正面から突きつけたからだ。もしその前提が揺らぐなら、つまり ChatGPT Codex や Claude Code、Cursor のようなエージェントが新規コードの 70〜90% を生み出すことが当たり前になったら、Python の優位はどこに残るのか。

問題の原文記事が、Microsoft の TypeScript コンパイラの Go 移行や Discord の Rust 採用、そして Python エコシステム全般の Rust 依存(uv、ruff、polars、pydantic-core など)といった事例を根拠に挙げたのは偶然ではない。それらはすべて同じ方向を指すデータポイントである。「エンジニア一人を一週間長く幸せにするコスト」よりも「一度据え付けたシステムを 5 年運用するコスト」の方が、再び重くなったということ。そしてその 5 年コストには今や「AI が生成したコードを検証するコスト」という項目が追加されたということ。

興味深いのは、この主張自体は新しくない、という事実である。静的型 vs 動的型の論争は 30 年来の論争であり、「Python は本物の production ではない」という主張も新しくない。新しいのは、それが遠隔のユーザー 922 人のキーボードを同時に叩かせた文脈である。その文脈は一行で要約される。AI が時間あたりコード量を一桁増やしたため、コード一行あたりの検証コストがシステムコストの支配的項目になった。そして検証コストは言語が決める。

本文 1 — 原文が言ったこと:トレードオフの軸が変わった

原文の論旨を正確に整理しよう。書き手 NMitchem は三つの観察から出発する。

第一に、Python の正体はすでに Rust に着替えている。uv は Rust で書かれたパッケージマネージャである。ruff は Rust で書かれたリンター・フォーマッタである。polars は Rust で書かれたデータフレームライブラリである。pydantic-core は Rust で書かれた検証コアである。ML 推論エンジンも次第に Rust へ移っている。つまり「Python エコシステムはますます Python の帽子を被った Rust エコシステムになりつつある(The Python ecosystem is increasingly a Rust ecosystem wearing a Python hat)」のだ。

第二に、TypeScript 陣営も同じ方向を向いている。Microsoft は 2025 年に TypeScript コンパイラを Go で書き直し始めたと発表した。世界最大の TypeScript ユーザーが、自社のコンパイラを別の、より難しい言語へ移した。理由は明白だ。コンパイル速度が型対応ツールチェーン全体の速度を決めるが、JS/TS で書かれたコンパイラではその速度をこれ以上上げる余地がなかった。トレードオフの算術が変わったというシグナルである。

第三に、Discord の事例。Discord は 2020 年に自社の Read States サービスを Go から Rust へ移行し、GC 停止(GC pause)をほぼゼロに近づけた。これは古い話だが、同じ会社が 2024 年以降ますます多くの新サービスを Rust で建てている、というのが原文のポイントである。「エンジニアが Rust を学ぶコスト」が一度払えば終わる一回限りの投資なら、「GC が毎リクエスト 50ms ずつ食いつぶすコスト」はトラフィックが増えるほど複利で膨らむ慢性支出である。

ここまでが原文の事実ベースである。その上に NMitchem が乗せた結論は二つに分かれる。(1) Python と TypeScript の旧い弁護 — 「開発者体験が良いから」 — は、実は「人間が直接書くときだけ良い」という意味であり、AI がキーボードを握れば効力を失う。(2) したがって新規プロジェクトは、特に長期運用を前提とする新規プロジェクトは、Rust や Go のような言語で始めるのが合理的である。記事末尾のエピソードはその結論をミニチュアで示している。書き手は、自分が Rust を知らないチームと共に AI に Rust コードを書かせ、同じ機能を Electron で書いたときの 1/10 のサイズで、より速いランタイムを持つアプリをリリースしたと記した。「人間は Rust を学ぶ必要すらなかった(The humans never had to learn Rust to get there)」。

この結末のエピソードがコメント欄で最も激しい反応を引き出した。j_w はこう切り返す。「ああ、そして誰もそのアプリを知らないし使わない、だからどうでもいい。誰も使わない製品をエピソードとして引くのは記事を締める良い方法ではない(Yeah and nobody knows or cares about the app, so it doesn’t matter)」。vhantz はもっと短く切った。「いいだろう。遠くない未来にこれを振り返ろう(Let’s look back on this not too far in the future)」。二つのコメントは同じ疑念を指している。AI は「見知らぬ言語で動くコード」を作ることはできるが、そのコードを 5 年後にデバッグするのは依然として人間の仕事であり、その人間が言語を知らなければ、そのコードは結局「廃棄コスト」として残る。

原文の主張はだから二つに切り分けて評価すべきだ。「Python の旧い弁護が弱まった」という命題はほぼ全てのコメントが同意する。「ゆえに Rust で新規に始めるのが正解」という処方は、意見が割れる。

本文 2 — HN の流れ:三つの答え

HN コメント欄 922 件を単純化すると、AI 時代の言語選択に関する答えは三つに分かれる。それぞれの合理性と限界を正確に押さえてみよう。

第一の流れ:「Python は依然として正解だ — 学習データと可読性ゆえに」

bryanrasmussen は LLM を使うときの三つのルールをこう整理する。(1) 自分がよく知っている言語を使え、読みやすくなければ追加作業ができない。(2) 学習データが大きい言語を使え、LLM がより効率的だ。(3) 読みやすい言語を使え。「Python は学習データが大きく、読みやすい(python has a large training set and it is easy to read)」という結論である。boffin も同じ文脈を短く述べる。「AI で brainfuck も書けるが、Python と同じ結果は出ないだろう(I could write in brainfuck with ai, but I presume, wouldn’t get the same results than if going with python)」。この流れの核心は、AI モデル自体がインターネット上のコードを学習した結果物であり、その絶対量で Python が圧倒的、という点にある。

この流れの最も強力な弁護は luodaint がコメントで整理した。「エージェントが 90% のコードを作っても、すべての diff は結局僕のレビューキューに入ってくる。Python の可読性は書くときの利点ではなく、レビューするときの利点である。僕がコードを読み、理解し、意図通り動くか判断しなければならない。それが残りの 10% であり、決定的な 10% である(Code readability of Python isn’t an advantage during write; it’s an advantage while reviewing)」。つまり、原文が「人間はキーボードから手を離す」と仮定したのに対し、この流れは「人間はレビュアーの席に移るだけだ」と見る。そしてレビュアー席では可読性への依存は減らず、むしろ増す。

第二の流れ:「これからは静的型が勝つ — コンパイラが検証を引き受けるから」

pshirshov のコメントがこの流れの精髄である。「コンパイラや型システムにより多く押し付けられるほど、フィードバックループが短くなり、エージェントがよりよく動く。厳格に強制される静的型がない点が、Python でエージェントが早く失敗する原因である。私の意見では Rust と Scala がエージェント的ワークフローの最良のターゲットだ(Rust and Scala are the best targets for agentic flows)」。slashdev はもっと断定的だ。「静的 vs 動的言語論争は決定的に終わり、静的が勝った(The static vs dynamic language debate is decisively over and static has won)」。彼は自社で 50 人のエンジニアがほぼ 100% Rust で働いており、自分はもはや手でコードを書かないと記している。AI が昨年までは borrow checker をうまく扱えなかったが、今では自分より厄介な lifetime 問題をうまく扱う、という観察も添えている。

bob1029 は同じ論理を .NET の事例へ移す。「私が持つ約 50MB 分の .NET コードベース群では、C# の強力な型がすべてをレールに乗せる中核の背骨として機能している。コード編集は数か月間無欠で、一度に 20 ファイルを触る apply_patch が成功的に動いた。LLM のコード編集性能は、型システムの厳格さを補正してしまえばほぼ言語非依存に見える。より正確には、コンパイル時にどれだけ有用な情報が返ってくるかの問題だ(LLM code editing performance might be mostly language agnostic once we compensate for the strictness of the type system)」。これは非常に重要な洞察だ。モデル自体の能力差ではなく、「エージェントが自分の仕事を検証できるシグナルの量」が結果を分けるということ。コンパイルエラーメッセージは単体テストより速く、単体テストより安い。p4bl0 の表現を借りれば「人間が 100% 校正しないコードを自動生成するなら、コンパイラが可能な限り多くの誤りを捕まえられる最も安全な言語を使う方が常によい(it’s always better to use the safest possible language so that the compiler can catch most of the errors)」。

第三の流れ:「人間の慣れがすべてに勝つ」

fbrncci のコメントがこの流れの象徴だ。「なぜ Python か。10 年以上書いてきて、デバッグの仕方を知っており、エージェントが巨大な踏み外しに終わる何かを書いたとき 10 秒以内に匂いを嗅ぎ取れるからだ。他の言語ではそうはいかない — また多くを学び直す必要がある。だから僕は Python を好む。AI がコードを吐き出す速度の中でも、ある程度のコントロール感覚が残る。Go や Rust でやっていたら、それは『AI 補助プログラミング』というよりむしろ『vibecoding』に近かっただろう(then it would feel more like ‘vibecoding’ than AI assisted programming, just yolo the whole product)」。この視点は第一の流れと似て見えるが、強調点が異なる。Python の客観的優位ではなく、個人の累積経験が検証コストを左右する、という主張だ。fxj の表現を借りれば「LLM が作ったものを理解しようとするとき、自分の人生を最も複雑にしない言語を使うべきだ(use the language that you know best to make your life as uncomplicated as possible)」。

この第三の流れはしばしば無視されるが、最も現実的だ。一人の開発者が同じ仕様の Rust コードと Python コードをレビューするとき、Rust が客観的に安全であっても、その人が lifetime を初めて見るなら、レビュー時間は 10 倍になる。その時間、別の仕事ができない。検証コストは言語の属性ではなく、言語と人間の積である。

三つの流れを総合すると、AI 時代の言語選択に単一の正解はない。ただし評価軸が三つあることは明らかだ。(1) AI がその言語をどれだけうまく書けるか — 学習データ量とモデルのドメイン慣熟度。(2) その言語が AI の出力をどれだけうまく検証してくれるか — 型システム、コンパイラ、静的解析の量。(3) その言語を人間がどれだけうまく読みデバッグできるか — チームの累積経験。Python は (1) で圧倒的、(3) で非常に強力、(2) で弱い。Rust は (2) で圧倒的、(1) でますます強くなりつつあり、(3) はチームによって 0〜100。Go は三軸とも 7〜8 点ぐらい。TypeScript は (1) が強く (2) は中くらい、しかしランタイムエラー面が依然として広い。

本文 3 — ドメインが決める:新規プロジェクトは何で始めるか

三つの評価軸を受け入れたとしても、新規プロジェクトを始める際にどの言語を選ぶかという意思決定はなお必要だ。ドメインごとに整理するのが最も実用的である。

ML / データドメイン — Python の圧倒は短期間では崩れない。rchowe のコメントが正確だ。「Python は特に AI/ML 周りで Rust よりはるかに成熟したエコシステムを持つ。ある ML アルゴリズムをするという Rust crate を見つけたが正しく動かなかった。Claude で代替を作ることはできたが(Python has a much more mature ecosystem than Rust, especially for AI/ML stuff)」。ライブラリの lock-in は言語優位ではなく、データの重さの問題だ。Hugging Face、scikit-learn、PyTorch、JAX、polars、ray、mlflow といった道具群の互換性表面は Python である。新しいデータパイプラインが Rust で始まっても、二つ目のコンポーネントが Python を呼んだ瞬間に境界ができ、境界はコストである。このドメインでは「Python で始め、hot path だけ Rust に切り出す」というパターンが依然優勢だ。polars と pydantic-core は正にそのパターンである。

システム / インフラドメイン — Rust または Go がデフォルトになりつつある。新たに書かれるデータベース、ランタイム、プロキシ、オーケストレータのほぼすべてが Rust か Go で始まる。Cloudflare の Pingora、ScyllaDB の新モジュール、Tigerbeetle、Materialize、Restate、dragonfly に至るまで。このドメインの特徴は「エラー一件のコストが非常に大きい」ことであり、これはコンパイラ検証の価値が最大になるドメインということだ。AI がインフラコードを書く比重が増えれば、このドメインの Rust 占有率はさらに加速するだろう。slashdev の会社の事例 — 50 人がほぼ 100% Rust で作業、手でコードを書かない — はシステムドメインの先取りに近い。

Web バックエンド — TypeScript と Go の競争がやり直される。Microsoft が TypeScript コンパイラを Go へ移した出来事は象徴である。fulafel のコメントはそのシグナルを正確に読む。「私の経験では Go が TS や JS より難しいと見る人はほとんどいない。TS はかなり複雑で、JS は踏み外しの宝庫だ(Go is absolutely an easier/simpler language than JS/TS)」。同時に、フロントとバックエンドを同じ言語で書ける、という TypeScript の旧い弁護は依然強力だ。したがってこのドメインでは「チーム内でフロントエンドとバックエンドのコード共有比率がどれだけあるか」が決定変数になる。それが大きければ TypeScript、小さければ Go。新規スタートならどちらも合理的である。

CLI / デスクトップ / 組み込み — Rust が次第にデフォルト。ripgrep、fd、bat のような CLI はすでに Rust 標準となり、Tauri は Electron の座を徐々に奪っている。原文の最後のエピソードはこのドメインで最も当てはまる。メモリ、バイナリサイズ、起動時間がユーザー体験に直接触れるドメインだからだ。AI が苦手な部分(例:unsafe Rust、複雑な lifetime)は依然小さな表面で、一般的な CLI コード領域ではモデルが十分こなす。

スクリプト / 一回限りの自動化 — Python が永続的に一位。このドメインの特徴は「検証コストがほぼゼロ」であることだ。一度回して捨てるコードにコンパイラの保護は要らない。AI が 30 秒で作ってすぐ実行してみれば終わる。scotty79 が「Rust を試したが開発が遅すぎると感じた(I tried using Rust but the development just seemed too slow)」と言った領域がまさにここだ。一回限り領域での Python の位置は揺らがない。

このドメインマッピングが示唆するのは、原文が提示した「Rust が新しいデフォルト」という命題が半分しか当たらない、ということだ。システム・CLI・組み込みではその言葉は速やかに真実になりつつある。しかし ML と一回限りスクリプトでは、その言葉は今後 5 年でも偽である可能性が高い。Web バックエンドとデスクトップは移行中である。つまり AI 時代の言語選択は「Python か Rust か」ではなく、「言語ポリグロット(polyglot)がより速く、より深く進む」ということである。一人の開発者が 5 年前は Python+JavaScript の二言語で働いていたなら、今は Python+TypeScript+Go+Rust の四言語を同時に扱うのが当たり前になる。それが可能な理由はまさに、AI が言語切り替えコストを下げるからだ。fxj の冗談 — 「面白半分に LISP、COBOL、FORTRAN、APL、J のようなものを学ぶのもよい」 — はまったく冗談でないかもしれない。モデルがそれら全てを知っているなら、人間が深く知るべき言語の数は増えるのではなく減るかもしれない。

結論

リードの問いに戻ろう。Python の一位はそのまま維持されるか。答えは「維持されるが、狭くなる」である。

Python が一位を守る領域は今も二つある。第一に、ML とデータドメイン。ライブラリの重さが言語自体より重い場所で Python の lock-in は崩れない。第二に、一回限りの自動化とスクリプト。検証コストがほぼゼロの領域でコンパイラの保護は贅沢である。この二領域で Python は今後 10 年も一位だろう。

しかしそれ以外のすべての領域 — システム、インフラ、CLI、組み込み、新規 Web バックエンド — で Python のシェアは縮む。その席を埋めるのは Rust(検証優位)または Go(単純さとコンパイル速度の優位)である。TypeScript はフロントエンドを守るが、バックエンドでは Go に次第に押される。この変化の動力は一つだ。AI がコード出荷量を一桁増やしたために、システムコストにおける検証コストの比重が一桁増え、検証コストはコンパイラが決める。

原文が見落とした一つは人間の役割である。luodaint が正確に指摘したように、人間はキーボードから手を離すのではなく、レビュアー席へ移る。そしてレビュアー席では可読性は減るのではなく増す。だから未来の言語は「AI が上手く書きつつ、同時に人間が上手く読む」言語が優勢になるだろう。その二つの条件をともに満たす候補 — 学習データが豊富で、コンパイラが強力で、文法が単純な言語 — は、現状では Go が最も近く、Rust が二番目で、Python は可読性項目でだけ依然強力だ。

したがって AI 時代の言語選択を一行で要約すると、こうなる。新規プロジェクトはまずドメインを見て、ドメインがシステム・インフラ・CLI なら Rust か Go を、ML・データ・自動化なら Python を、Web ならチーム構成を見て TypeScript か Go を選べ。そしてどんな選択をするにせよ、コンパイラが検証の半分を引き受けてくれる言語が、5 年運用コストで有利だ、という事実を忘れるな。Python が一位だった理由は、人間が速く書くためだった。これからは人間が速くレビューしなければならない。そしてレビューは、コンパイラが横にいるとき最も速い。