xn--ecka7j.biz
なぜ人気？Pythonの「クソ仕様」に絶望した私が、それでもAIバッチ開発にPythonを選ぶ
前回の記事で私は、
Pythonの“たった1文字”に3時間を溶かされた地獄体験を書いた。
ファイル名に少し意図を込めただけで無視され、
空白の数だけでネストが変わり、
「未来を一切考えていないクソ仕様」に本気で机を叩いた。
でも、ここで誰もが思うはず。
「そんな欠陥だらけの言語が、なぜ“世界人気No.1”なの？」
JavaもC言語もRustもあるのに、
なぜ私たちは“あの”Pythonを、
文句を言いながらも使い続けているのか。
結論はシンプル。
Pythonは「美しい言語」だから愛されているんじゃない。
“最強の武器を持った、最高に都合のいいおバカ”だからだ。
今回は、
線画だらけの英文マニュアルを OCR（ocrmypdf）で文字起こしし、
ローカルLLM（Qwen2.5）でバッチ翻訳するという
泥臭い現場の最前線から、
Pythonが世界を制した狂気のパラドックスを語る。
第1章：数学者たちが「お堅い言語」を全員で拒絶した歴史
■ AIの生みの親はエンジニアではない
AIやデータ解析の基礎を作ったのは、
コードの美しさを競うプログラマーではなく、
数式を証明したい数学者・科学者たちだった。
■ 型定義や“おまじない”にうんざり
C言語やJavaの厳格なルールは、
彼らにとって「本業（数式）の邪魔」でしかない。
■ ノートに数式を書く感覚で動く“ユルさ”
型も不要、適当に書いても動く。
この“ガバガバさ”こそが、
天才たちにとって最高の実験場になった。
第2章：裏で「C言語の筋肉」を操る“命令役”というチート特性
■ 遅すぎるPython × 速すぎるC言語
Python単体の処理速度は正直ゴミ。
だが内部構造がシンプルすぎて、
「重たい部分だけC言語に丸投げ」
が異常に簡単だった。
■ 私たちが触っているのは“拡声器”だけ
ocrmypdfの画像解析も、
Qwen2.5-14BのAI推論も、
実際に動いているのはPythonではなく
裏側のC言語の筋肉。
■ 書くのはラク（Python）× 実行は爆速（C）
import 1行で世界最強の計算資源を操れる。
この“接着剤（グルー言語）”としての強さに、
全人類がひれ伏した。
第3章：泥臭い「ゴミ掃除（テキスト加工）」を最短で片付ける無類の強さ
■ OCRの宿命「線画ノイズ」地獄
図面の斜線や網掛けが
「___」「|||」のようなノイズに化けてテキストを汚染する。
これを放置するとAIは確実に暴走する。
■ 他言語なら“お作法コード”だけで日が暮れる
ファイルを開いて、メモリ確保して、文字コード判定して…
ノイズ1つ弾くのに数十行。
■ Pythonなら“ゴミ辞書”を直感的に作れる
構造が単純だからこそ、
職人が集中したい
- 正規表現でのノイズ除去
- ゴミ辞書の構築
を最小限の行数で書ける。
第4章：誰も抜け出せない、先行投資の「雪だるま効果」
■ 「人が人を呼ぶ」無敵ループ
- AI研究にはPythonが楽
- 大学がPythonでコード公開
- BigTechもPython向けに最新AIを提供
結果、
Pythonを使うのが最も効率的という世界が完成した。
■ 仕様はクソだが、武器がここにしかない
他言語エンジニアがどれだけ正論を言っても、
最先端のAI・OCRの武器はPythonの畑にしか落ちていない。
だから全員、
渋々Pythonを手なずけるしかない。
【まとめ】
Pythonが人気な理由はただ一つ。
器用な秀才より、
“世界最強の武器（AI）を最速で振り回せるおバカ”の方が
時代のスピードに勝ったから。
だからこそ、
暴走しがちなPythonを
例外処理や起動ルール（-m）でガチガチに固める
エンタープライズ級のバッチ設計ができる職人の価値が
今、爆上がりしている。
今日もPythonのワガママ（インデントエラー）に愚痴りながら、
世界最強のAI翻訳バッチを作っていこう。
詳しく知りたい方はこちら
👉 https://xn--ecka7j.biz/efficiency-vs-thought-ai-symbiosis/ai-verification-mindset/14134/
必要なら、
https://xn--ecka7j.biz/efficiency-vs-thought-ai-symbiosis/ai-verification-mindset/14134/
【決定版】Pythonの「たった1文字」で3時間溶けた話。開発者は正気なのか？
「なんで . がついただけで動かなくなるんだよ…」
昨日、WSL2でPythonバッチを動かしていて、思わずこう叫びました。
DeepSeek-R1を制御するために、シェルスクリプトからPythonへ移行したばかり。
Python歴はまだ1週間。
そして――この“地獄仕様”を知ったのが昨日。
結論だけ言うと、先頭の . たった1文字で挙動が変わる設計は、どう考えても後先を考えていない。
目が悪いとか、初心者だからとか、そういう問題じゃない。
これはもう「仕様が人間を殴ってくる」タイプの言語です。
今回は、私が3時間溶かした“相対インポート地獄”を、できるだけ分かりやすくまとめました。
◆ 第1章：たった1文字で3時間消えた話
ディレクトリはこんな感じ。
main.py logger.py split_chunks.py ← ここで死亡 ...
split_chunks.py から logger.py を呼びたくて、こう書いた。
from logger import log_info
すると――
ModuleNotFoundError: No module named 'logger'
正解はこれ。
from .logger import log_info
ドット1個。たったそれだけ。
しかも main.py ではドットなしで動く。
from logger import log_info
同じフォルダなのに、呼び出す場所でルールが変わる。
いや、ほんとに頭おかしい。
◆ 第2章：なぜこんな仕様になったのか？
理由はシンプルで、そして深刻。
● Pythonは「小さなスクリプト用」に生まれた
1991年当時、巨大プロジェクトなんて想定していなかった。
全部同じフォルダに置くのが普通。
インポートも“適当に探すだけ”。
つまり、後先を考えていなかった。
● その後、世界中で巨大プロジェクトが増えた
同名ファイルが大量に出現。
衝突しまくり。
そこで後付けで「相対インポート」が追加された。
● 既存コードを壊せない → 最小限の変更
だから、
from logger importはそのままfrom .logger importを追加
という“最小の妥協”が生まれた。
結果、たった1文字で挙動が変わる地獄仕様が誕生。
中略（第３章～第７章）
◆ おわりに
Pythonを触って1週間で「この仕様おかしい」と気づいたあなた。
その感覚は100％正しい。
同じ罠にはまった者として、あなたのバッチ処理が無事に動くことを願っています。
🔗 本Blogで“完全版”を公開中（アメブロ中は、文字数制限の為、第２章までも管力表現にしています。）
この記事はアメブロ向けに短くまとめています。
より深い解説・歴史的背景・AS/400比較の詳細は本Blogに掲載しています。
👉 完全版はこちら
https://xn--ecka7j.biz/efficiency-vs-thought-ai-symbiosis/ai-verification-mindset/14116/
AIオーケストレーションの限界と最適解：AI暴走を防ぐエンタープライズ級Pythonバッチ設計
プロンプト 「AIに仕様を渡せば、完璧なプログラムを書き上げてくれる」･･･そんな幻想を抱いてはいないだろうか。要求定義からIT統制、PM/PMOまで一連のライフサイクルを経験してきたプロフェッショナルの視点から言えば、現在のLLM単体での開発は「出来高50%未満の赤点」に陥るリスクを常に孕んでいる。
