「遅いPython」がAI界の覇権を握った本当の理由——速度より「人間コスト」を選んだ設計哲学の話
「遅いのになぜ使われる？」——この矛盾を正面から扱う
「AI開発といえばPython」。
この一文に異論を挟む人は、今の業界にほとんどいない。
ところが、プログラミング言語の特性を少しでも知っている人間は、ここで立ち止まらざるを得ない。PythonはC言語やJavaと比べて、処理速度が数倍から数十倍遅いとされる言語だ。一方、AI・機械学習・ディープラーニングの開発現場では、膨大な行列演算やデータ処理が日常的に走る。
「最も計算パワーが必要な分野」で、「最も計算が遅い言語」が覇権を握っている。
この矛盾は、表面だけ見れば確かに奇妙だ。しかし構造を一枚めくると、技術選定における本質的な問いが見えてくる——「何を速くしたいのか」という問いだ。
Pythonの出発点——クリスマス休暇の暇つぶしから始まった
Pythonの誕生は1989年のクリスマス休暇に遡る。オランダの研究機関に勤めていたプログラマー、グイド・ヴァン・ロッサム氏は、オフィスが閉まって手持ち無沙汰だったため、趣味のプロジェクトとして新しいプログラミング言語の開発を始めた。
彼が当時感じていた不満はシンプルだった。「C言語は速いが、書くのが難しくて時間がかかる。シェルスクリプトは簡単だが、複雑な処理には向かない」。その中間——「書きやすくて、読みやすくて、そこそこ何でもできる言語」——を自分で作ってしまおうと考えた。
ちなみに、「Python」という名前はヘビのニシキヘビ（python）ではなく、グイド氏が大ファンだったイギリスのコメディ番組『空飛ぶモンティ・パイソン』から取られている。意外と知られていないトリビアだが、この由来は設計思想を象徴している気がする——堅苦しさより、気軽さとユーモアを優先する、という姿勢だ。
設計の根底にあった考え方は「コードは書かれるよりも、読まれる回数の方が圧倒的に多い」というものだった。だからPythonは、インデント（字下げ）を文法として強制し、誰が書いても似たような見た目になるよう設計された。コンピュータの処理速度よりも、人間が読み書きする際のコストを徹底的に下げることを優先した。
速度問題の「種明かし」——PythonはリモコンでC/C++が筋肉だった
ここが核心だ。
AI開発でよく使われるNumPyやTensorFlowといったライブラリ。これらはPythonから呼び出して使うが、コアの計算処理は実際にはC言語やC++で書かれている。
つまり、Pythonは「計算している」のではなく、「計算を命令している」にすぎない。
元記事の表現を借りれば、Pythonは「優秀なリモコン（グルー言語＝接着剤言語）」だ。構造を整理するとこうなる：
| 役割 | 言語 | 特徴 |
|---|---|---|
| 現場の作業員（実際の計算処理） | C / C++ | 実行速度は爆速。ただしコードを書くのが難しい |
| 現場監督（指示・制御） | Python | 実行速度は遅い。ただしコードを書くのが圧倒的に速い |
NumPyでnp.dot(A, B)と一行書けば、裏側ではC++で最適化された行列演算が走る。TensorFlowでmodel.fit()と呼べば、GPUを叩くC++コードが動く。Pythonが遅いのは事実だが、そのPythonが「遅さを発揮する時間」は全体の処理のほんの一部にすぎない。
この分業構造を知らずに「Pythonは遅いからAIに向かない」と言うのは、リモコンが電池切れだからといって「テレビの映像が悪い」と言っているようなものだ。
ここからは見方——「速度 vs 人間コスト」のトレードオフをどう読むか
技術選定の議論では、往々にして「実行速度」だけがフォーカスされる。しかし実際の開発現場で問題になるのは、しばしば別の「速度」だ——「人間が書く速度」「試行錯誤のサイクル速度」「新しいメンバーがキャッチアップする速度」。
AI・機械学習の研究の中心にいたのは、純粋なソフトウェアエンジニアではなく、数学者・統計学者・研究者たちだった。彼らがやりたかったのは「複雑な数式やアルゴリズムを素早く試すこと」であって、「メモリ管理を丁寧に書くこと」ではない。
Pythonの英語に近い直感的な文法は、この層にとって学習コストが最も低かった。結果として、研究者がPythonでAIライブラリを作り始め、それを使いたい人がさらにPythonに集まり、ライブラリがさらに充実するという自己強化サイクルが生まれた。
研究者が書きやすいPythonを選ぶ → 便利なAIライブラリが大量に生まれる → それを使いたい人がPythonに集まる → さらにライブラリが充実する
この循環が一度始まると、後発の言語がいくら「速い」「優れた設計」を主張しても、エコシステムの重力には簡単に勝てない。技術の優劣ではなく、「誰が最初に研究者コミュニティを掴んだか」という地政学的な話になっていく。
実務的な示唆——「何の速度か」を問う習慣
この話には、AI開発に限らない実務的な教訓が含まれている。
ツールや言語を選ぶとき、「遅い」「重い」「シンプルすぎる」という批判は常に存在する。しかし問うべきは「何の速度か」「誰にとっての使いやすさか」「何をトレードオフにしているのか」だ。Pythonはコンピュータの処理速度を犠牲にして人間の記述速度を取った。それが1989年の設計判断だったが、その判断が30年以上後のAIブームで「正解」として評価された。
技術選定の判断軸として覚えておきたいのは、「実行速度と開発速度は別物で、どちらを最小化すべきかは用途による」という点だ。大量データをリアルタイム処理するシステムと、週次でモデルを更新する研究プロジェクトでは、最適解は異なる。
一方で、今後の論点として気になるのはPython依存のリスクだ。
RustやMojoといった言語が「Pythonより速く、Pythonと同じくらい書きやすい」を標榜して台頭しつつある。特にMojoはPython互換の文法を持ちながら高速実行を目指すという、Pythonのリモコン構造を根本から置き換えようとするアプローチだ。現状ではエコシステムの差が圧倒的だが、NumPyやPyTorchに相当するライブラリが成熟してきたとき、研究者コミュニティの重力がどちらに向くかは注視する価値がある。
もうひとつの論点は、LLMとコード生成の組み合わせだ。「書きやすさ」がPython採用の大きな理由だったとすれば、AIがコードを書いてくれる時代に「人間が書きやすい言語」というアドバンテージはどう変化するのか。言語選定の軸が「人間の記述コスト」から「AIが生成しやすい構造」に変わるとしたら、評価基準ごと変わる可能性がある。現時点では仮説にすぎないが、次の5年で答えが見え始めるかもしれない。
まとめ——哲学が時代に選ばれた話
Pythonが「遅いのにAI界の標準語になった」のは、偶然でも魔法でもない。
「コンピュータの都合より人間の都合を優先する」という1989年の設計判断が、30年後にAI研究者・データサイエンティストという層にぴたりとはまった。重い処理はC/C++に任せるという分業構造が、実行速度の問題を構造的に回避した。そして最初に研究者コミュニティを掴んだことで、エコシステムの自己強化サイクルが走り続けている。
技術の世界では「最速・最高性能」が勝つとは限らない。「誰のために、何を最小化するか」を正確に射抜いた設計が、長い時間軸で勝つことがある。Pythonはその典型例であり、だからこそ今も語り継がれる話だと思う。
