AIがコードを書くなら、なぜPythonを使うのか？

 (medium.com/@NMitchem)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • AI支援開発により、言語選択の基準が人間の記述速度からAIの修正能力とランタイム性能へ移行している
  • 2026年には Claude Opus 4.7、GPT-5.5、Gemini 3.1、DeepSeek V4 が**SWE-bench Verified 80%**を超えた
  • RustはコンパイラのフィードバックループがAIの自己修正を助け、GoやSwiftも高速な型チェックによってエージェントに有利である
  • TypeScriptコンパイラのGo移植、Rust製Cコンパイラ、Rue、Ladybird JSエンジン移植のように、大規模な移行がすでに進んでいる
  • Python・JavaScriptのエコシステムもRustツールやラッパーへの依存が強まっている一方、Prisma、PyTorch、小規模言語のような例外も残っている

AI支援開発が変えた言語選択の基準

  • 新規プロジェクトの標準選択肢は長らくPythonやTypeScriptだった
    • エコシステムが大きく、採用プールが広く、素早くデモを作れたため
    • Rust、Go、C++は10〜100倍の性能をもたらし得たが、学習期間、小さな人材市場、厄介なビルドシステムがコストとして作用した
    • そのため、まずPython版を出して「後で性能改善する」と言いながら、実際にはそのまま維持されることが多かった
  • AIが難しい言語を扱い始めることで、このトレードオフが揺らぎ始めた
    • 言語選択において「人間が素早く書けるか」よりも、「AIがうまく書いて修正できるか」とランタイム性能の比重が増している

難しい言語がAIにとって先に易しくなる

  • 2年前のGPT-4は、Rust関数を書いている最中に存在しないcrate名をでっち上げる程度だった
  • 2026年4月にはClaude Opus 4.7、GPT-5.5、Gemini 3.1、DeepSeek V4が数週間おきにSWE-bench Verifiedで80%を超えた
  • 研究所はシステム作業を明示的に最適化している
    • 並行性バグ
    • 競合状態
    • 計画段階で見つかるアーキテクチャ上の欠陥
  • CtrlAltDwayneは、Rustが2026年に強い理由をメモリ安全性や性能ではなくコンパイラのフィードバックループに見ている
    • AIはC++よりRustをうまく書く
    • Rustのコンパイラエラーメッセージが、モデルのリアルタイムな自己修正を助ける信号になる
    • RustはAI支援開発向けに10年早く「偶然設計されていた」言語のように機能する
  • 同じ論理は程度の差こそあれGoやSwiftにも当てはまる
    • 強い型システムと高速なコンパイル・検査ループが、エージェントに密な反復サイクルを提供する
    • 人間には難しかったシステム言語が、エージェントにとってはむしろ扱いやすい対象になり得る

実際にリリースされた事例

  • MicrosoftのTypeScriptコンパイラGo移植

    • MicrosoftはTypeScript 7.0 betaを公開し、10年物のTypeScriptコードベースをGoへ移植した
    • TypeScript 7.0 betaは6.0よりおよそ10倍高速である
    • Anders Hejlsbergの判断によれば、Goはエンジニアリングコストの一部で性能向上の大半を実現できる
    • 最大級のJS/TS組織の1つが、代表的ツールに対してより難しく高速な言語を選ぶほど、費用対効果の計算が変わってきている

  • Claudeエージェント16体で作られたRust製Cコンパイラ

    • Anthropicの研究者 Nicholas Carlini は、16体のClaudeエージェントを並列に調整し、Rustで本番用Cコンパイラを書いた
    • 規模は10万行で、x86・ARM・RISC-V上でLinux 6.9を起動する
    • QEMU、FFmpeg、SQLite、PostgreSQL、Redisをコンパイルし、Doomも動作させた
    • 総コストは約2,000回のClaude Codeセッションを通じて2万ドル未満だった
    • Rustで書かれたCコンパイラは、かつては大学院論文級の仕事だったが、もはや例外的な仕事だけではなくなっている

  • Steve KlabnikのRue

    • The Rust Programming Language の共同著者であり、13年のRust経験を持つ Steve Klabnik は、ClaudeとともにRueという新しいシステム言語を2週間で作った
    • 成果物はおよそ7万行のRustだった
    • 彼は、今回の2週間の作業は、以前1〜2か月かけた試みよりも先まで進めたと述べている

  • Ladybird JavaScriptエンジンのRust移植

    • Ladybirdブラウザの創設者でありC++エンジニアでもある Andreas Kling は、Claude Code と Codex に数百の小さなプロンプトを与えながら、Ladybird の JavaScript エンジンをC++からRustへ2週間で移植した
    • 結果はおよそ2万5千行のRustで、C++の原版とバイト単位の等価性を達成した
    • test262とLadybirdテストを合わせた6万5千件超で回帰はなかった
    • 同じ作業を手作業で行えば数か月はかかったはずだと述べている

弱まりつつある「エコシステム」の論理

  • PythonとJavaScriptの最も強い論拠は、言語そのものよりエコシステムだった
    • FastAPI、Django、PyTorch、React、Next.js、npmの400万パッケージといった基盤があった
    • チームが数日で機能を出せたのは、エコシステムが問題の90%をすでに解決していたからだ
  • この強みは過去10年間決定的だったが、ここ2年で弱まりつつある
  • Pythonエコシステムの内部も、徐々にRust製コンポーネントへ依存している
    • pydanticの検証コア全体はRustライブラリである
    • pandasの代替であるPolarsはRustで書かれている
    • Hugging Face tokenizers と orjson も Rust である
    • JetBrains 2025 Python surveyによれば、Pythonバイナリ拡張でのRust利用率は1年で**27%から33%**へ増加した
  • 開発ツール基盤も同じ方向へ動いている
    • Charlie Marsh が2022年に設立した Astral は、Rust製の ruff、uv、ty を公開し、3ツールの月間ダウンロード数は0から数億回へ増えた
    • 2026年3月19日にOpenAIはAstralを買収し、uvがCodexの計算時間を週あたり約100万分節約すると見ている
    • 10週間前にはAnthropicがBunを買収した
    • Bunは月間ダウンロード700万、GitHubスター8万9千を記録し、「AI主導ソフトウェアエンジニアリングに不可欠なインフラ」と呼ばれている
    • Evan You の VoidZero は Rolldown-Vite を公開した
    • このRust製バンドラはGitLabの2.5分ビルドを40秒へ短縮し、メモリ使用量を100分の1に減らす
  • Vercelプロダクト担当VPの Lee Robinson は、「JSでは最適化の頂点に達した」と語っている
  • PythonやJavaScriptで取り込んで使うパッケージは、ますます、直接リリースするのは難しいと見なされていた言語で書かれたコードのラッパーになっている
    • そうした言語で今や直接リリースできるなら、ラッパーはオーバーヘッドに見え始める

パッチよりポーティングが容易になる変化

  • 既存オープンソースエコシステムの好循環はパッチ中心だった
    • Pythonが簡単だから選ぶ
    • 依存関係のバグを見つける
    • 修正してupstreamに反映する
    • エコシステムがより健全になる
  • エージェントは、貢献の単位をパッチからポーティングへ移しつつある
  • Flaskの創設者 Armin Ronacher は、1月にエージェントを使ってRustライブラリ MiniJinja をGoへ移植した
    • 総実行時間は10時間だった
    • このうち3時間は監督し、7時間は無人で進んだ
    • 実際の人間の作業時間は45分だった
    • APIコストは60ドルだった
  • ライブラリを言語間で移植する作業が45分で済むなら、他人のライブラリに修正を送る論理は弱まる
    • 「パッチできるのになぜフォークしないのか」ではなく、「フォークできるのになぜパッチするのか」になる
  • Armin Ronacher は、価値がコードからテストとドキュメントへ移りつつあると見ている
    • 良いテストスイートは、コードそのものより価値があるかもしれない
  • PyPIやnpmを生んだループは今も機能しているが、2028年にもそのまま機能しているかは明らかではない

なお残る例外

  • すべての変化が一方向にだけ進むわけではない
  • 場合によっては依然として従来の選択が正しい
    • PrismaはRust query engineを削除し、TypeScript/WASMコアへ移行した
    • バンドルサイズは85%削減され、クエリは最大3.4倍高速化した
    • ネイティブRustバイナリはサーバーレスランタイムに不利である
  • PyTorchはディープラーニング研究の約**85%**を依然として占めている
    • モデルの重みはどの言語でラップするかの影響を受けないため、この地位は簡単には変わらない
  • AIがすべてのシステム言語を同じようにうまく扱えるわけではない
    • Zig、Haskell、Gleamのような小規模言語では、現時点でのAI生成品質はRustやGoと同等ではない
    • 学習データが、モデルが支援できる範囲を決める
    • RustとGoはGitHub上に十分多く存在するため有利な立場にある
    • Zig、Haskell、Gleamはまだその曲線の不利な側にある

なぜこの変化は続き得るのか

  • PythonとTypeScriptの従来の防衛線は、実のところ開発者体験の防衛だった
    • 人間のアイデアとリリース製品の間の摩擦を最小化するから選ばれていた
    • Rustはランタイムで遅い言語ではなく、深夜2時にリリースしなければならないときに遅い言語だった
  • 今やエージェントが難しい部分を担い始めている
    • 人間の役割は「コードを書くこと」から「システム設計と出力レビュー」へ移っていく
    • この流れでは、Pythonの文法上の手軽さは分岐ごとにそれほど重要でなくなる
    • より難しい言語のランタイム上の利点は、サービスが本番で動く毎日ごとに積み上がる
  • Armin Ronacher は2月の記事 A Language For Agents で、コーディングコストが急落することでエコシステムの広さの重要性が薄れると見ている
  • この20年間の言語選択は、「人間がコードを書き、人間は低水準言語では遅い」という制約を中心に形作られてきた
    • この制約が消え始めている
  • Stack Overflow 2025調査では、Rustは10年連続で最も称賛される言語となり**72%**を記録した
    • Gleamは70%
    • Elixirは66%
    • Zigは64%
    • 好みはすでに存在しており、ツールが今それに追いつきつつある

エージェントにとって易しい言語への次の段階

  • Karpathy は2月に、LLMがソフトウェアの制約地形全体を変えると述べた
    • CからRustへの移植の流れにその兆候が見えるとしている
    • Rustでさえ、LLMの対象言語としては最適に近いだけで、最終形ではないと付け加えた
  • 現在の勝者は出発点に過ぎず、最終形はさらに先にあるかもしれない
  • @RealRichomie は4月24日に、プログラミングの未来は人間にとって最も易しい言語ではなく、エージェントにとって最も易しい言語へ向かうと述べた
    • エンジニアたちはRustやTauriをまったく知らない状態からMacアプリをリリースした
    • 成果物はElectron版の約10分の1のサイズで、ランタイム性能も高かった
    • 人間はRustを学ばなくても、その結果に到達できる
  • 次のプロジェクトが必ずしもPythonをデフォルトにする必要はない

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsのコメント

  • LLMコーディングツールを非決定的コンパイラのようなものだと見る主張に同意するなら、できるだけ性能の良い言語を選ぶのはかなり理にかなっている
    もちろんライブラリや言語ごとのネイティブな強みといった例外は多いが、この1か月ほどC++で作業してみた限り、言語選択のせいで遅くなったのはコンパイル時間だけだった

  • 冒頭のコメント群を読んでも学習データの話が出てこないのが意外だった。Pythonのコードは学習データに圧倒的に多い
    AIでBrainfuckを書くことはできるだろうが、Pythonを使うときと同じ結果にはならないと思う
    続く問いはこれだ。今やAIがあるのなら、必要になるまではなぜ言語を気にする必要があるのか？

    • 5年ぶりにPerlをまた書きたくなって、Goで作っていたプロキシを立ち上げ、いくつもの統合テストを書くためのごく単純な方法が必要だった
      その大半をClaude Codeで書いたが、ClaudeはPerlを本当によく扱えた。CPANには触れずPerlの標準ライブラリだけを使うようにと言ったところ、HTTPクライアント、TLS、JSONまで全部標準でそろっていて、普段ならシェルスクリプトで実装していたようなことを、非常に堅牢で簡単なやり方で置き換えられた
      Perlは大きく変わっておらず学習データも多いので、Claudeはシェルスクリプトを使いたくなるような場面でPerlをかなりうまく使えるようだ
    • 驚くべきことに、LLMはエージェント的なコーディング作業において、他の一般的なプログラミング言語よりPythonの推論がずっと苦手だ
      データはこちら: https://gertlabs.com/rankings?mode=agentic_coding
    • 単にGoを使えばいい。LLMはGoを大量に見ていて、うまく書けるし、ほぼ即座にコンパイルでき、型付きコンパイル言語の利点も一通り持っている
      AIで大きなPythonコードベースを作ったことがあるが、LLMは引数や辞書の形をずっと誤って推測していた。単体テストやpydanticのようなツールは役に立つが、そうした種類のランタイムエラー自体を避けるほうがよい
    • 学習データだけでは答えにならない。LLMは別のプログラミング言語へ翻訳するのが本当に得意だ。テキスト翻訳システムから派生したことを考えれば自然だ
      公開コードが比較的少ない言語でも結果は見事だった。より大きな障害は、LLMが対象言語のありがちなイディオムをまねる点で、JavaやC#のような「エンタープライズっぽい」言語では、役に立たないボイラープレートコードが一気に増殖しかねない。そうなると成果物が使えるコンテキストウィンドウの大きさを超え、品質が落ちる危険が高まる
    • AIにオープンループでコード生成をさせるなら、学習データは重要かもしれない。Pythonには、求めたものに近いコードを誰かがすでに書いている可能性が高いからだ
      ただし、エージェントがコードを書き、コンパイルを試し、詳細なエラーメッセージを見て、そのメッセージをもとにコードを磨いていけるなら、より高品質な結果になる。rustcの診断は非常に優れているし、PythonやJavaScript/TypeScriptのほうがはるかに多いとはいえ、いまではオンライン上にRustのコードも十分ある

  • Pythonなのは、10年以上使ってきていてデバッグの仕方も分かっており、エージェントがコードを書いて10秒以内に大事故につながりそうなことをしているかを勘で見抜けるからだ
    他の言語ではそうはいかず、多くを学び直さなければならない。AIが高速でコードを吐き出しても、ある程度は自分がコントロールしている感覚を持てるPythonを好むようになる。GoやRustだったら、AI支援プログラミングというより、製品全体をYOLOで突っ走る「バイブコーディング」に近く感じただろう

    • エージェント時代にRustを使い始めたが、他言語で積んだ経験はそのまま生きていて、コードの臭いや悪いアーキテクチャを見抜く助けになった
      メモリ安全性の部分は何が「正しい」のか分からず学ぶ必要があったが、それ以外は順調だった
      文法は次第に背景へ退き、より高いレベルのことに集中して新しい道を探れるようになる。一度試せば、どれほど多くの経験が移転可能かに気持ちよく驚くかもしれない
    • 自分も似たようなものだった。AI生成のPythonコードは数行見ればデタラメかどうか嗅ぎ分けられるので、ほとんどのプロジェクトで引き続きPythonを使っている

  • AIが文章を書いてくれるなら、なぜ脳を使うのか？

    • 笑い話ではない。モデルは先月よりはるかに良くなっていて、トークンコストも下がっている。LLMは脳のためのコンパイラのようなものだ
      /s

  • AIにRustを書かせるところで、なぜ止まるのか？ すべてがバイブコーディングで、コードレビューももうしないのなら、LLMにトークン使用量の最小化と速度だけを目的にした超簡潔・超高密度な言語を設計させればいい
    このコメントの末尾には、半分だけ本気の /s が付く

    • なぜコードを書くところで止まるのか？ みんなでカスタムASICチップを作るべきで、チップファブがなければせめてFPGAくらいはやるべきだ

  • 少し本題から外れるが、いったいなぜ今でも人々がMediumに記事を載せるのか分からない
    読書体験がひどすぎる。全画面ポップアップが、読んでいた文章を文字通り覆い隠すので、この記事も最後まで読めなかった
    自分には見えていない何かしらのインセンティブがあるのだろうか？

    • ブラウザで読むものが、誰にとっても究極にすばらしく、しかも断トツで最高の読書体験を同じように提供できることはない。現代のWebのモデル自体がそれと衝突している
      CSSのない素のHTMLページは、ほぼ完璧な読書体験だ。問題は、ほとんど誰もそんな形で配信しないことだ。Webが、著者たちが関心を持って競い合う出版プラットフォームになってしまったからだ。ユーザーの管理下にあるプレーンテキストのプロトコルのほうが、「誰にとっても最高の読書体験」により近い。Webにもそれはできたはずだが、大半はそうなっていない
      ブラウザで長文を読もうとするのはやめた。関連するプレーンテキスト、さらには構造化テキストまで簡単に取り出して自分のエディタで読めるのに、なぜブラウザで読む必要があるのか？ フォント、色、ナビゲーションなどを自分で制御できる。ブラウザは配信手段であって、読書環境ではない。そう扱うのは習慣であって必然ではない
      ずっと前から、3語を超えるものはエディタの外で書かなくなった。スペルチェック、類語辞典、語源の参照、翻訳、自分のすべてのノートへのアクセス、LLM連携まで、必要なものはすでに全部ある。いつか試してみれば、ものすごく解放感があるはずだ。そうなれば長文をブラウザで読むのもやめられる

    • Mediumは書き手にお金を払おうという、かなり本気の取り組みをしてきた。Substackとは異なるモデルだが、それが理由だ
      新聞のペイウォールを見るのと似た見方をしている。好きではないが、なぜ存在するのかは理解できる

    • いちばんもっともらしい推測は惰性だ。ブランドへの忠誠心が非常に強く、周囲が何をどうしているかに合わせて動く人もいる
      実際にはどこに投稿されたかは重要ではなく、URLだけ渡せばよいのだが、誰もがそう振る舞うわけではない

    • 書き手に優しいブログプラットフォームの最新の進化形に見える。WordPressよりニュースレター形式で束ねやすく、有料ティアで収益化するのも簡単だ

    • Mediumの代替フロントエンドであるScribeを使うと、ずっと良い:
      https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code...

      https://sr.ht/~edwardloveall/Scribe/
      https://libredirect.github.io/

  • PythonはRustよりはるかに成熟したエコシステムを持っていて、特にAI/機械学習ではそうだ
    ある機械学習アルゴリズムを実装していると主張するRustクレートに出会ったが、まともに動かなかった。それでもClaudeで代替実装を書くことはできた
    AIと組み合わせるなら、型システムのレベルで正しさを強制するのは良い考えだと思うので、PythonよりC#やRustのような言語を選ぶことが多い。ただ、何をするかによってはPythonが明らかに適切な道具でもある

    • ほぼ常にRustを選ぶ。最近はGoで書かれた何かのプラグインを作った
      Rustを使うこともできたが、成果物がうまくいった場合、他の人にとっては1つのツールチェーンを使えることのほうが価値が高いだろうと考えて、Goが適切だと感じた
      根本的な理由は、必要になったときに読めることが大切だからだ。そして受け手側のエコシステムには期待される言語がある。データサイエンス界隈の一部がR、MatLab、Julia、Python、Mojoを選ぶのも、技術的に何が優れているかではなく、仲間が何を使っているかに左右される
    • 唯一の用途は、機械学習ライブラリのような低レベルC++ライブラリをラップする場合だと思う。そういうものを再現するのは本当に難しい
    • AIと一緒に使う際に型システムによる強制が良い理由はいくつかある
      推測だが、型付き言語はより高速で優れた言語サーバーを持つことが多く、ツール利用によるコード修正をより効率的に行える
      人間が途中で入ってコードを調査・修正しなければならないときも、強い型のおかげでスパゲッティコードの中でもはるかに方向をつかみやすい
    • AI/機械学習のライブラリサポートについては、確かに一理ある。それでも最近はバックエンド作業でRust/TypeScriptへ向かうことが多い。Djangoが本当に好きでもそうだ
    • Pythonのエコシステムを離れて、AIに依存関係管理やポリフィルまでさせるつもりなら、Rustではなく、むしろOCaml/F#まで行ったほうがいい
      そうすればガベージコレクションと強い型の利点を得られる

  • 現時点では、人間が自分で書くときにPythonを使う理由とまったく同じだ。Zigのような言語よりPythonを知っている人のほうが多いので、人間がコードを読み、修正しやすいからだ
    記事の主旨は分かるが、まだそこまでの段階ではないと思う

    • 自動化が人間の理解できない言語で書かれる世界は、完全に真っ暗な中国の自動化工場を連想させる。人間は道に迷って混乱するが、ロボットにとっては快適な場所だ

  • 「チームの誰も知らない言語で出荷されたアプリ」、いいね。そう遠くない未来にこの出来事を振り返ることになるだろう

    • AI以前にも、こういうことはあった。10年前、ある人がランダムな言語で重要なツールを書き、残りの人たちがそれを保守しなければならなかった。それでも何とかやれた
    • たぶん、彼らが置き換えていたElectronアプリより恐ろしいかもしれない、この世で唯一の代物だろう
    • 12〜18か月後に転職すればいい。そうすればそれは他人の問題だ

  • 「Anthropicの研究者Nicholas Carliniが16個の並列Claudeエージェントを統率し、Rustで本番用のCコンパイラを書いた」というのは事実ではない
    そのコンパイラはgcc/clangよりはるかに劣るコードしか生成できず、実質的に役に立たない