AIインフラにおける言語論争は、普段は宗教戦争のように語られる。Python派はエコシステムの規模を引き合いに出し、Rust派はベンチマークを掲げ、Go派は開発者の生産性を主張する。誰もが自分のポジションを裏付けるデータを都合よく選んでいる。
ここでは代わりに、正直に語ってみよう。
現在の状況
PythonはAI開発のデフォルト言語であり続けている。最良のランタイム言語だからではない——それは明らかに違う——AIエコシステムがPythonで構築されたからだ。PyTorch、TensorFlow、LangChain、Hugging Face、そしてほぼすべてのモデルトレーニングフレームワークがPythonファーストだ。これらのツールの上に構築するとき、Pythonを使えば統合の摩擦がなくなる。
GoはAIインフラ（AIモデルではなく）で本格的な牽引力を得ている。Kubernetes自体がGoで書かれており、AIエージェントとクラウドインフラの交差点が拡大するにつれ、Goはエージェントオーケストレーションの自然な選択肢となった。GoogleのGo + AIツーリングへの投資（kagentフレームワークを含む）がこのトレンドを後押ししている。
Rustはパフォーマンス層を占めている。Pythonが遅すぎる、メモリを食いすぎる、またはセキュリティが不十分なユースケースで選ばれる言語だ。ZeroClaw、AutoAgents、そして増え続ける推論ランタイムがRustで書かれている。Red Hatチームの「一部のエージェンティックAI開発者がPythonからRustにコードを移行している」という観察は、ハイプではなく実際のトレンドを反映している。
数字で見る
以下のベンチマークは、同一ハードウェア上で3つの言語すべてで実装された同じエージェントタスク（ツール使用を伴うマルチステップQ&A）を比較している：
- •Rust（ZeroClaw）：12ms
- •Go（kagent）：45ms
- •Python（LangChain）：320ms
- •Rust：4.8MB
- •Go：35MB
- •Python：180-400MB（フレームワークにより変動）
- •Rust：8ms
- •Go：120ms
- •Python：2-4秒
- •Rust：1,600以上
- •Go：220インスタンス
- •Python：20-40インスタンス
比率はベンチマーク全体で一貫している：RustはGoの5-25倍効率的で、GoはPythonの5-10倍効率的だ。これらはパーセンテージレベルの改善ではない——桁違いの差だ。
Pythonが正解なとき
パフォーマンス差にもかかわらず、以下の場合はPythonが正しい選択だ：
プロトタイピング。 Pythonの反復速度は他の追随を許さない。午後にエージェントを書き、テストし、捨て、書き直す。LangChainエコシステムのおかげで、ほとんどの統合がpipパッケージとして既に存在する。
チームがPythonを知っている。 2週間で出荷されるPythonエージェントは、2ヶ月かかるRustエージェントに勝る。開発者の利用可能性は重要だ——Python開発者はRust開発者のおよそ20倍存在する。
モデルのトレーニングやファインチューニング。 これはPythonの領域だ。PyTorchとTensorFlowはPythonライブラリだ。Rustでモデルトレーニングをしようとするのは、エコシステムと戦うことだ。
パフォーマンスが重要でない。 64GB RAMのサーバーでは、4.8MBと400MBの差は無関係だ。デプロイターゲットに十分なリソースがあり、エージェントがレイテンシに敏感でないなら、Pythonのオーバーヘッドは見えなくなる。
Goが正解なとき
Goが優れているのは：
Kubernetesネイティブのインフラを構築している場合。 エージェントをK8sリソースとして管理するなら、Goが自然な選択だ。Kubernetesクライアントライブラリ、controller-runtime、Operator SDKはGoネイティブだ。
高速コンパイルとシンプルなデプロイメントが欲しい場合。 GoはRustのようにシングルバイナリにコンパイルされるが、学習曲線ははるかに緩やかだ。コンパイル-デプロイサイクルはPythonのパッケージ管理より速く、Rustに匹敵する。
チームがバックエンドサービスを構築している場合。 Goの並行モデル（goroutine）は、複数の会話を同時に処理するエージェントアーキテクチャに自然にマッピングされる。チームが既にGoサービスを構築しているなら、Goのエージェントフレームワークは自然にフィットする。
Rustのデプロイメントのシンプルさの95%を、学習曲線の20%で実現したい場合。 これが多くの組織にとってのGoのスイートスポットだ。
Rustが正解なとき
Rustが正しい選択なのは：
リソース制約が実在する場合。 Raspberry Pi、512MB RAMのVPS、または数百の同時実行エージェントがあるデプロイメントでは、Rustの効率性が「動く」と「収まらない」の分かれ目になる。
セキュリティが主要要件の場合。 Rustの所有権モデルはコンパイル時にメモリ安全性の脆弱性を排除する。認証情報を扱い、システムコマンドを実行し、昇格した権限で動作するAIエージェントにとって、これは重要だ。
レイテンシが重要な場合。 12msで応答するエージェントは、320msで応答するものとは体感が違う。音声ベースのエージェント、リアルタイムアプリケーション、高スループットのバッチ処理では、Rustのレイテンシプロファイルは譲れない。
アプリケーションではなくインフラを構築している場合。 エージェントランタイム、モデルサービングフレームワーク、エンベディングエンジンはインフラだ。何ヶ月も動作し、何百万ものリクエストを処理し、信頼性が求められる。Rustの保証はこのプロファイル向けに設計されている。
重要なトレンド
興味深いトレンドはPython vs Rust vs Goではない。専門化だ。
Pythonはプロトタイピングとトレーニングの言語になりつつある。Pythonでエージェントロジックを構築し、テストし、アプローチを検証する。そして本番環境が要求するパフォーマンス、セキュリティ、リソース効率を提供するRustまたはGoで書かれたランタイムにデプロイする。
これはまさにWeb開発が進化した道と同じだ：Ruby/Pythonでアプリケーションロジック、Nginx/CでWebサーバー、PostgreSQL/Cでデータベース。（もはや）誰もWebサーバーをPythonで書かない。同じ分離がAIエージェントでも起きている。
ZeroClawのアプローチ——設定ファイルで定義されたエージェントロジックを実行するRustランタイム——はこのパターンの一例だ。ZeroClawを使うためにRustを書く必要はない。TOMLで設定し、自然言語でプロンプトを書き、Rustランタイムに実行を任せる。言語論争はエンドユーザーにとって無関係になる。
正直な評価
今日AIエージェントプロジェクトを始めるなら：
- •Pythonで最初のバージョンを作る。動くようにする。コンセプトを検証する。
- •Goに切り替えるのは、より良いデプロイメントエルゴノミクスが必要で、インフラがKubernetes中心の場合。
- •Rustに切り替えるのは、エッジデプロイメント、最大限のセキュリティが必要な場合、またはスケールがPythonのオーバーヘッドを許容できなくする場合。
- •もしくは切り替えをスキップして、ユースケースが明らかに「制約が重要」カテゴリに該当するなら、最初からRustベースのランタイム（ZeroClawなど）を使う。
正しい言語はエージェントを出荷できる言語だ。正しいランタイムは本番環境で効率的に動かし続けるものだ。両者が同じである必要はない。