はじめに
Python は私の愛用言語ですが、エンジニア界隈にいると「え？ Python しかできないの！？」と言われる場面が結構あります。そこで今回は Python だけではなぜだめなのかを考えてみます。
Python をかじっただけのなんちゃってエンジニアにならないためにもちょっと厳しくいってみましょう。
🐣 一番は自戒の念も込めた記事なんです
まずは Python の弱点から見ていきます。
オブジェクト指向が不完全
まず、ここが一番玄人に受けが悪い点です。
Python をオブジェクト指向言語だと勘違いしている人もいるかもしれませんが、なんとカプセル化が不完全なのです。
-
public / private / protectedみたいなアクセス修飾子がない -
_nameは「触らないでね」の合図で、禁止ではない -
__nameはアクセス禁止ではなく、名前衝突を避けるための仕組みにすぎない
公式チュートリアルにも「本当の意味の private はない」と書かれています。
Python チュートリアル
class Model:
def __init__(self):
self._cache = {"x": 1}
self.__secret = 42
m = Model()
# どっちも触れてしまう
print(m._cache)
print(m._Model__secret)
初心者のうちは、このいい加減さが助けになることも確かにあります。
でも、チーム開発になるほど困る場面が増えていきます。理由は単純で、誰でも中身を壊せるからです。
🐣 人生では性善説を信じたいですけど、チーム開発でそれは危険すぎます
AI 時代に、この弱点が増幅する
人間でも、内部 API に依存しまくると痛い目を見ることがあります。
例えば packaging が pyparsing の private API に依存していて、pyparsing 3.0.5 の変更で壊れた件が報告されています。packaging の issue #486
AI は GitHub から「裏技」も学習して、普通に _internal を触るコードを混ぜてきます。しかも見た目は綺麗です。AI は言われたことを最適化して結果を出します。そこになんの躊躇もありません。LLM における RLHF のようになんらかのガードレールが必要になるのですが、Python のオブジェクト指向としての未成熟さがときにそれを許しません。その結果、致命的になることもあるのを忘れないようにしましょう。
遅い
Python は遅いです。
コンパイル言語ではないので、当然と言えば当然です。
では、なぜあれほど計算量の多い深層学習の現場で人気なのでしょうか？
それは Python が「速い」からではなく、「速いプログラム（C 言語など）を動かすためのマネージャー」として優秀だからです。
実は「他人の力」で速く見せているだけ
「Python は速い」と感じるのは NumPy や PyTorch を使っている場合ではないでしょうか。
実は重たい行列計算や学習処理をしているのは Python ではありません。裏側にある C 言語や C++ で書かれたネイティブ実装が計算しています。Python はただ「これやっておいて」と命令を投げているに過ぎません。
標準的な Python（CPython）は、C 言語で作られたインタプリタです。一行ずつ翻訳しながら実行するため、コンパイル言語のような速度は期待できません。つまり、私たちが恩恵を受けている「速さ」の正体は、Python の手柄ではなく、優秀なバックエンドのライブラリのおかげなのです。
さらに足を引っ張る「GIL」
ただでさえ単体では遅いのに、Python には長年抱えてきた「GIL（Global Interpreter Lock）」という足かせまであります。
これは「どんなに CPU のコア数が多くても、一度に動ける Python のスレッドは 1 つだけ」という厳しいルールです。並列処理で速度を稼ごうとしても、この GIL がボトルネックになり、マルチコアの性能を活かしきれないことがよくありました。
Free-threading：足かせを外す試み（でもまだ微妙）
Python 3.13 から、この GIL を取り払う「Free-threading」という機能が実験的に導入されました。
「これでやっと Python 自体も速くなるのか！」と期待したくなりますが、現実はそう甘くありません。
- デフォルトでは無効：自分で設定しないと使えません
- 逆に遅くなることも：排他制御の管理コストが増えるため、単純な処理（シングルスレッド）だと 5〜10% ほど遅くなるケースが報告されています
- ライブラリが未対応：頼みの綱である C 拡張ライブラリが対応していないと、エラーになったりクラッシュしたりします
Free-threading Python Compatibility Status Tracker
結局のところ、Python 自体が爆速になる銀弾はまだありません。現状では「遅い言語である」という前提を受け入れ、重い処理はライブラリに丸投げするのが正しい付き合い方と言えるでしょう。
初期学習コストが低い
Python は入門コストが低く、誰でもすぐに書き始められるのが強みです。
しかし、これは初心者やその周囲の人々にとっての「罠」でもあります。ただ動くコードと「実用に耐えうるコード」はまったくの別物だということを理解せずに「とりあえず動いた」だけで満足してしまうと思わぬ落とし穴にハマることがあるのです。
型がない恐怖
最近流行りの「AI にコードを書かせる（Vibe Coding）」スタイルは便利ですが、本人が理解していないコードが量産されるリスクがあります。特に Python は実行するまで型エラーが分からない動的型付け言語なので、AI が仕込んだバグが実行時までわからないことが多いのです。
だからこそ、AI 時代の Python では型ヒント（PEP 484）を書くのがマナーです。
def total_price(prices: list[int]) -> int:
return sum(prices)
# AI がやりがちな事故：文字列を渡しても実行するまでエラーにならない
print(total_price(["100", "200"]))
対策
このような問題を避けるために pyright や mypy などの静的解析ツールを使うことができます。実行する前に「型が違うよ」と教えてくれるので、AI のミスを未然に防げます。
型情報が明確になることで AI の補完精度が上がり、人間にとっても読みやすい仕様書代わりになります。
🐣 「型がないと楽～」から「型がない恐怖」を感じるようになる日が必ず来ます
では Python の次に何を覚えるべき？
では、Python しか知らないとダメだというなら Python の次に何を学べばいいのでしょうか？ 私のおすすめは、何か静的型付けのオブジェクト指向言語です。
一般的な候補はこの 3 つ
-
Java
企業システム方面なら現場が多いです。仕事の地図が広がりやすいです -
C#
近代的な言語機能が入りやすく、開発体験も良いです。業務でも強いです -
C++
メモリ管理が必須です。難しいですが視界がクリアになりますPython の次に React や TypeScript に行きがち、も分かります。フロントをやるなら自然な選択です。
ただ一流エンジニアになることが目的なら、まず Java か C# が安定だと思います。
🐣 最近の Python の型ヒントや JavaScript→TypeScript の流れには環境の要請に基づく収斂進化を感じます
Python のいいところ
ここまで読んで「じゃあ Python はダメなの？」と思ったなら、それは違います。今、生成 AI をやるなら Python は必須ですし、もしも一つだけコンピュータ言語を覚えるなら何がいいかと初心者に聞かれたら多くの人が Python と答えることでしょう。
Python が広まったのは、深層学習や生成 AI で用いられた以外にもちゃんと理由があります。
- 試作が速い
- データ分析、機械学習、運用自動化の道具が揃っている
- 他言語の資産を呼び出して、全体をつなぐのが得意
大規模開発も不可能ではありませんが、性善説で言語を信じすぎるとハマります。Python で大きめに作るなら、このへんが現実の最低ラインです。
- 型ヒントを入れる
- テストを書く
- Lint と Formatter を CI に入れる
- 依存関係と実行環境を固定する
Python には高い自由度がありますが、決してそれは「簡単であること」を意味しません。
🐣 「夕飯何がいい?」に「なんでもいいよ」と答えると怒られちゃうのと同じですね
生成 AI とコーディング
ここからはちょっと Python からは離れた話です。
今年流行った「Vibe Coding（AI に任せてノリで書く）」ですが、現場ではその反動、いわゆる「二日酔い」が始まっています。 これは、AI で気持ちよくコードを書いた翌日に、そのツケ（バグ修正や保守）という激しい頭痛に襲われる現象を皮肉った言葉です。 The vibe coding hangover is upon us
実際に Replit の AI エージェントが本番 DB を削除し、あろうことかそれを隠蔽しようとした事故は、世界中のエンジニアを震え上がらせました。 結局のところ、現場で起きているのは以下のような悲劇です。
- AI が「動くだけのコード」を爆速で量産する
- 中身を理解していないのでバグに対処できない
- 尻拭いさせられるシニアエンジニアが地獄を見る
最近ではこれを揶揄して「Vibe Coding 修正屋」なんて言葉まで生まれています。「できる」と錯覚している初心者ほどやっかいなものはないということかもしれません。
Python を AI と併用するなら、ここだけは守る
私は vibe coding を否定したいわけではありません。私もコーディングに生成 AI をバンバン使っています。ただ、業務レベルで使うならルールが要ります。そして大前提となる一番大切なことは…
生成 AI が出したコードは必ず自分で読みましょう
です。最初はわからないことだらけかもしれません。でもそれを生成 AI に尋ねることは簡単です。職場でいつも忙しそうにしている先輩とは違って
- 何回同じことを聞いても
- 真夜中や休日に聞いても
- どんな初歩的なことを聞いても
決して不機嫌になったりはしません。一見無駄に見えるこのやり取りが結局はエンジニアの基礎体力になっていくのだと思います。
おわりに
なぜ Python ではだめなのかに対する私の答えはこれです。
Python がだめなのではなく、初歩のPython＋生成 AI だけで「できる」と錯覚することがだめなのです。頑張ってよりよいエンジニアを目指したいですよね。ではまた次の記事でお会いしましょう。