「プログラムは正常終了しました。処理件数：0件」

エラー文すら出ない。画面に表示されるのは、完璧な『虚無』。これがどれほど開発者の脳を狂わせ、大切な時間を削り取るか、Pythonを触る実務家なら誰もが知っているはずだ。

事の始まりは、WordPress（バージョン6.9.4）からエクスポートした全248件、総行数197,537行（約20万行）の巨大なXMLファイルから、特定の厳選した10記事の本文だけをPythonで自動抽出するバッチ処理を走らせようとしたことだった。

環境はWindows上のWSL2（Ubuntu）。プログラムのロジックは一ミリも間違っていない。それなのに、システムは何食わぬ顔で「0個のファイルを切り出しました」とドヤ顔で返してきた。

本稿は、お昼の13時過ぎまで私の認知コストを奪い続けた「xml.etree.ElementTree（ElementTree）の最悪のサイレントスルー仕様」の正体を暴き、そんな高尚な構文解析をすべてゴミ箱に捨てて「正規表現による物理的な力技」でシステムを決定論的にねじ伏せた、生々しいバトルの記録である。

第1章：美しい「オブジェクト解析」という名の地獄の始まり

事の発端は、20万行の巨大XMLから、特定のID（14222 等）の本文だけを抜き出すコードをPythonの標準ライブラリ xml.etree.ElementTree (ET) で美しくスマートに組もうとしたことだった。

最初に用意したコードがこれだ。

# 【初期設計】ElementTreeによる「お利口な」構文解析
import xml.etree.ElementTree as ET

target_ids = ['14222', '14177', '14134', '14116', '14082', '14021', '13888', '13642', '9278', '6973']
xml_file = 'web.WordPress.2026-06-18.xml' 

tree = ET.parse(xml_file)
root = tree.getroot()

ns = {'wp': 'http://wordpress.org', 'content': 'http://purl.org'}

for item in root.findall('.//item'):
    post_id = item.find('wp:post_id', ns).text
    # (以下、IDにマッチしたらファイルに書き出す処理...)

これを走らせた結果、最初の牙が剥かれた。

Traceback (most recent call last):
  File "import_20260618.py", line 19, in <module>
    post_id = item.find('wp:post_id', ns).text
AttributeError: 'NoneType' object has no attribute 'text'

「NoneType に text なんて属性はねえよ」という冷酷なエラー。名前空間（ns）のURLが1文字でもミスマッチを起こすと、Pythonは即死する。ここまではいい。エラーが出ているうちは、まだデバッグができるからだ。本当に恐ろしいのは、この次だった。

第2章：AIとの生のやり取り――エラーすら出さない「サイレント不発」の恐怖

即死（AttributeError）を防ぐため、名前空間のURLを厳密にし、ノイズをスルーする安全弁（if wp_id_node is None: continue）を肉付けした。

その結果、AI（Copilot）は自信満々にこう告げた。
「URLを完全な形（/export/1.2/）に修正し、例外回避を入れたので、今度こそエラーをすり抜けて、冷徹に処理結果が10回連続で画面に流れ落ち、処理が完了します！」

その言葉を信じ、WSL2から再度実行した「生のやり取り（実行ログ）」がこれだ。

j1nak@jn260303-AI9x1-HX470:/mnt/c/Users/j1nak/Downloads$ python3 import_20260618.py
XMLの解析を開始します...

【処理完了】 厳選10記事中、0 個のファイルを正常に切り出しました。
j1nak@jn260303-AI9x1-HX470:/mnt/c/Users/j1nak/Downloads$

「0個」。
エラーは一切出ていない。システムとしては「正常終了」だ。だが、中身は完全に「虚む」。

これがPythonのElementTreeが抱える最大のクソ仕様、【デフォルト名前空間の自動強制付与トラップ】の正体である。
XMLの最上部にデフォルトの xmlns="..." が定義されていると、Pythonの findall('.//item') は、人間が指示していない「存在しない裏の名前空間」を勝手にタグの頭にくっつけて探しに行く。その結果、ただの <item> タグを1件も発見できず、何食わぬ顔で「正常に0件でした！」と嘘をつく。

人間の設計がどれだけ正しくても、動的言語の裏で動く小賢しいライブラリの仕様のせいで、エラーログすら残らずに人間が騙される。この無神経さこそが、AIバッチ開発における最凶の壁なのだ。

第3章：生存戦略――高尚なオブジェクト解析を捨て、「テキスト力技」でねじ伏せる

時刻はすでに13時を回っていた。こんな不親切極まりない言語仕様のデバッグ（名前空間のURLの完全一致ゲーム）に、これ以上1秒たりとも付き合ってられるか。

私は「XMLの構造解析」というお利口なアプローチをすべてゴミ箱に捨てた。
20万行のXMLファイルなど、所詮はただの「長い文字列」だ。だったら、オブジェクトとして読むのではなく、ただのテキストとして上から力ずくで1行ずつスキャンし、正規表現（re）で物理的にぶち抜けばいい。

そうして書き換えた、名前空間など100%関係ない「純粋テキスト処理版」のコードがこれだ。

# 【最終解】名前空間を完全無視する正規表現による「物理ぶち抜き」
import re

target_ids = ['14222', '14177', '14134', '14116', '14082', '14021', '13888', '13642', '9278', '6973']
xml_file = 'web.WordPress.2026-06-18.xml' 

with open(xml_file, 'r', encoding='utf-8') as f:
    xml_data = f.read()

# <item>ブロックを正規表現で物理的に全件切り出す
items = re.findall(r'<item>.*?</item>', xml_data, re.DOTALL)

for item in items:
    id_match = re.search(r'<wp:post_id>(.*?)</wp:post_id>', item)
    if id_match and id_match.group(1).strip() in target_ids:
        # (以下、マッチしたIDのタイトルと本文を強引にtxt保存する処理...)

第4章：冷徹な決定論の勝利

XMLのクソ仕様（ElementTree）を完全にバイパスし、ただの文字列検索に切り替えた結果がこれだ。

j1nak@jn260303-AI9x1-HX470:/mnt/c/Users/j1nak/Downloads$ python3 import_20260618.py
XMLファイルをテキストとして力技で解析します...
👉 抽出成功: 6973_CDATA生成A.txt
👉 抽出成功: 9278_CDATA生成A.txt
👉 抽出成功: 13642_CDATAGEM.txt
👉 抽出成功: 13888_CDATAAIと.txt
👉 抽出成功: 14021_CDATAAIと.txt
👉 抽出成功: 14082_CDATA実証.txt
👉 抽出成功: 14116_CDATA決定.txt
👉 抽出成功: 14134_CDATAなぜ.txt
👉 抽出成功: 14177_CDATA再々.txt
👉 抽出成功: 14222_CDATAAIオ.txt

【処理完了】 20万行から、10 個のファイルを強引に切り出しました。

完璧な大勝利。
小賢しいライブラリの気まぐれを捨て、原始的なテキスト処理という「絶対裏切らない決定論」に回帰した瞬間、10発の弾丸（テキストファイル）がフォルダ内に完璧に湧き出てきた。

■ 結論（まとめ）：災い転じて福となす

今回の13時過ぎまでの大激闘で得られた教訓は、極めてシンプルだ。

「AIの言葉も、Pythonの便利なライブラリも、絶対に信用するな」

彼らは悪気なく嘘をつき、悪気なく虚無（0件）を返す。
AIバッチ開発、そしてAIオーケストレーションを現実に実務で通すためには、こうした「サイレントに人間をハメる仕様」の存在を前提とし、時にはスマートな設計を捨てて、「絶対にバグの起きようがない泥臭い力技のレール」を人間の手で敷いてやる割り切りが不可欠なのだ。

この大トラブルを経て手元に揃った10個の生テキストファイルを武器に、明日からはいよいよ、エンジニア界隈のタイムラインを震撼させる「AIオーケストレーションの真実」の執筆（Zenn寄稿計画）へと舵を切る。地獄の徒労は、極上のコンテンツへと昇華された。

前回、私は『Pythonの「たった1文字」で3時間溶けた話』という記事を書いた。

【Pythonの罠】たった「1文字」の記述ミスで3時間溶けた実例（例：末尾のコンマ、ミュータブル引数）とLLMが見抜けなかった理由

Pythonの相対インポート `from .module` がなぜ分かりにくいのか、その歴史的理由と対策を解説。たった1文字 `.` で挙動が変わる『クソ仕様』の真相と、AS/400との比較から見えるPythonの限界。Python初心者からベテランまで、一度は悩んだ『インポート地獄』を完全解決。『急がば回れ』の精神でPythonと向き合う方法。

イイネ.biz

2026.05.31

ファイル名に少し意図を込めただけでシステムから存在を黙殺され、空白の数だけでネストが変わるPythonの「先のことを全く考えていないクソ仕様」に、リアルに机を叩いて激怒した。

だが、ここで誰もが不思議に思うはずだ。
「そんなダメダメな言語が、なぜ今、世界人気ナンバーワンの座に君臨しているのか？」

JavaやC言語、Rustのような洗練された言語があるにもかかわらず、なぜ私たちは、この融通の利かないPythonを「承知の上で」使い続けなければならないのか。

結論から言おう。Pythonは言語として美しいから愛されているのではない。「最強の武器を持った、最高に都合のいいおバカ」だからだ。今回は、線画だらけの英文マニュアルをOCR（ocrmypdf）で文字起こしし、ローカルLLM（Qwen2.5）でバッチ翻訳するという「泥臭い開発の最前線」から、Pythonが世界を制した信じがたいパラドックスを解き明かす。

第1章：「数学者（プログラミングの素人）」たちが、お堅い言語を全員で拒絶した歴史

• AIの生みの親はエンジニアではない
  • AIやデータ解析のアルゴリズム（理論）の土台を作ったのは、コードの美しさを競うプログラマーではなく、数式を証明したい数学者や科学者だった。
• 「型定義」や「おまじない」へのウンザリ感
  • C言語やJavaで画面に1行出すための厳格なルールは、彼らにとって「本業（数式）の邪魔」でしかなかった。
• 「ノートに数式を書く感覚」で動くユルさ
  • 型も不要、適当に書いてもパッと動くPythonの「ガバガバさ」こそが、アイデアを最速でスケッチしたい天才たちにとって、最高にハードルの低い「実験場」となった。

第2章：裏で「C言語の筋肉」を操る、ただの「命令役」というチート特性

• 遅すぎるPython、速すぎるC言語の合体
  • Python自身の処理速度はゴミのように遅い。だが、Pythonは内部設計がシンプルだったため、「重たい計算部分だけをC言語にすり替える」という拡張（接着）が異常に簡単だった。
• 私たちが触っているのは「拡声器」だけ
  • あなたが動かしている ocrmypdf の高度な画像解析も、Qwen2.5-14B の超重量級のAI推論も、実際はPythonではなく裏の「C言語の筋肉」が身代わりになって爆速で実行している。
• 「コードを書くのはラク（Python）」×「実行は爆速（C言語）」のハイブリッド
  • 本体の仕様がおバカでも、1行 import するだけで世界最強の筋肉をノーコストで操れる。この「接着剤（グルー言語）」としての有用性に、全人類がひれ伏した。

第3章：「泥臭いゴミ掃除（テキスト加工）」を最短で片付ける、無類の強さ

• OCRの宿命「線画ノイズ」との闘い
  • 図面の斜線や網掛けが、すべて「___」や「|||」といった文字化けの塵（ノイズ）になってテキストを汚染する地獄。これを放置すればAIは確実に暴走する。
• 他の言語なら「お作法コード」だけで日が暮れる
  • 厳格な言語なら、ファイルを開いて、メモリを確保して、文字コードを判定して…と、ノイズを1つ弾くために数十行のコードが必要になる。
• Pythonなら「ゴミ辞書」を直感的に作れる
  • 中身が空（0バイト）のファイルでもパッケージの目印にできるほど構造が単純だからこそ、職人が本当に集中したい「正規表現でのノイズ除去」や「ゴミ辞書の構築」を最小限の行数でダイレクトに記述できる。

第4章：誰も抜け出せない、先行投資の「雪だるま効果（エコシステム）」

• 「人が人を呼ぶ」無敵のループ
  • 「AI研究にはPythonが楽」➔ 世界中の大学がPythonでコードを公開 ➔ GoogleやMetaなどのビッグテックも「みんなが使うPython向けに最新AI（PyTorch等）を出すのが一番普及する」と判断。
• 「仕様はクソだが、武器がここにしかない」という現実
  • 他言語のエンジニアが「Pythonのインデント仕様はクソだ」と正論を言ったところで、最先端のAIやOCRの武器はPythonの畑にしか落ちていない。結果、全員が「渋々、Pythonを手なずける」道を選ぶ。

【まとめ】

Pythonが人気な理由。それは「器用でお堅い秀才（他言語）」よりも、「不器用でワガママだけど、世界最強の武器（AI）を一番手軽に振り回せるおバカ（Python）」の方が、激変する時代のスピードに勝てたからだ。

pythonのSWOT分析

だからこそ、そのまま動かせば暴走するこの不器用な監督（Python）を、例外処理や厳格な起動ルール（-m）でガチガチに固める「エンタープライズ級のバッチ設計」ができる職人の価値が、今、市場で跳ね上がっている。

さあ、今日もPythonのワガママ（インデントエラー）に愚痴を言いながら、世界最強のAI翻訳バッチを完成させるとしよう。

【DeepSeek暴走対策】AIオーケストレーションの限界を超える、ガードレールを取り入れたエンタープライズ級Pythonバッチ設計

AIに丸投げでは出来高50%未満の赤点？AS/400のCLP構造や150語のルールでDeepSeekが暴走した実体験から、Copilotとの役割分担、Claude 4.5 Sonnetの有効性、PCローカル環境（Ryzen AI 9）で品質100%を叩き出すPythonパイプラインの最終設計図までを徹底解説。Ryzen AI 9 HX470 LLM

イイネ.biz

2026.05.23

– Pythonの相対インポート `from .module` と `from module` の違いがなぜ「クソ仕様」なのか

– たった1文字 `.` の有無でプログラムの生死が分かれる恐怖

– Pythonがこの「目障りな仕様」を変えられない本当の理由

– AS/400の思想と比較してわかる、Python設計の「後先考えなかった」証拠
(AS/400と比べる？･･･この発言自体が” Frank Gerald Soltis “博士に対して失礼なのだが、まあ許して戴きたい。)

「なんで `.` がついただけで動かなくなるんだよ！」

これは私が昨日、WSL2上のPythonバッチ処理で3時間悩んだ末に出た言葉です。

私は今、DeepSeek-R1を制御するエンタープライズ級のバッチ処理をPythonで書いています。シェルスクリプトでは限界があったからです。しかし――

Pythonを知ってまだ1週間。そして「この仕様」を知ったのが昨日。

結論から言います。Pythonの開発者が存命なら申し訳ないですが、これは「後先考えなかった」と断言せざるを得ない。なぜなら、たった1文字 `.` の有無でプログラムの生死が分かれる設計は、もはや「虐待」だからです。

しかも、同じような「1文字地獄」がPythonには山ほどある。

今回は、Pythonの最も分かりにくい仕様のひとつ「相対インポート」 にスポットを当て、なぜこれが生き残り、なぜ変えられないのかを深掘りします。

◆ 第1章：私が遭遇した「悪夢の3時間」

状況再現

私は以下のようなディレクトリ構成でバッチ処理を書いていました。

G:/@Ubuntu/CLP/PGM-N/
├── main.py              # エントリポイント
├── config.py            # 設定読み込み
├── logger.py            # ログ出力
├── ocr.py               # OCR実行
├── extract.py           # テキスト抽出
├── preprocess.py        # 前処理
├── split_chunks.py      # チャンク分割 ← ここでエラー
├── translate.py         # 翻訳呼び出し
├── dictionary.py        # 辞書適用
├── fileops.py           # ファイル操作
└── mailer.py            # メール通知

この中の `split_chunks.py` から、同じディレクトリにある `logger.py` の関数を呼びたくなりました。(各工程の進捗都度Loggingしたかった。長時間処理の為、進捗を知りたかった！)

私がやった間違い

# split_chunks.py の先頭に書いたコード
from logger import log_info   # ← これだと動かない！

出てきたエラー

ModuleNotFoundError: No module named 'logger'

これで、何がいけないのか直ぐに判ったあなたは、「python中毒」間違いなく

正解はこれだった

from .logger import log_info   # ← 先頭に「.」を入れるだけで動く

“.“こんなの分かる訳がない。pythonを知って1週間足らず、そして触ったのが昨日(１日前)･･･たった1文字（しかも小さい.）思わず「頭大丈夫!?開発者」と、罵ってしまった･･･これは嘘だけど、正にその様な気持ちになった。

たった1文字。ドットひとつ。

しかも、`main.py` から呼ぶときは `.` が不要なんです。

# main.py ではこれで動く
from logger import log_info

同じコードなのに、呼び出す場所によって `.` が必要になったりならなかったり。

――は？ 頭おかしくない？

この発見に至るまで、私は3時間を無駄にしました。ググって(正確にはGeminiに聞いて)、StackOverflowを読み漁って、やっと「そういう仕様なんだ」と納得するまで。

◆ 第2章：なぜこんな「分かりにくい仕様」になったのか？

2-1. 私が抱いた疑問（そしてあなたも抱くはず）

ここで、私が3時間悩んだ末に抱いた疑問をそのまま書きます。

> 「他にも `.` １文字だけの違いで切り分ける定義があるのだろうか？ 目が悪いと見過ごしてしまいそうな・目立たない `.` にした？ もっと工夫のしようがなかったのか？ はなはだ疑問に感じるのは私だけだろうか？ センスがないとも思える。」
･･･いやハッキリ言う「センス無しだ。後先考えていない。考えていなかったと断言する。」

この疑問、私だけじゃありません。世界中のPython初心者が同じことを思います。キット

では、なぜPythonはこんな仕様になったのか。歴史を追いましょう。

2-2. Pythonのインポートは「歴史的負債の塊」だった

ステップ1：Pythonは「小さいもの」として生まれた

1991年、Guido van RossumがPythonを作ったとき――

大規模プロジェクトなんて想定していなかった。

当時は：

– パッケージ（フォルダ単位の管理）という概念がなかった

– 全部の `.py` ファイルを同じフォルダに置くのが普通

– インポートは「現在のフォルダ＋システム全体」を適当に探すだけ

つまり、最初から「バカでも使える簡易言語」だった。👈言い方が悪いが、後先のことを考えていなかった証拠です。

ステップ2：プロジェクトが巨大化して問題発生

2000年代に入り、Pythonが普及するにつれて問題が表面化した。

「同じ名前のファイルが大量に存在する」

例えば：

– `utils.py` というファイルが10個のフォルダに存在

– どの `utils.py` をインポートするかPythonは判断できない

そこで後付けで追加されたのが 「相対インポート（`.module` の文法）」。

ステップ3：後付けだから「互換性」が最優先された

ここが最も重要なポイント――

既に世界中で何百万行ものPythonコードが動いていた。

新しい文法を追加すると：

– 既存コードが動かなくなる

– 全世界のプロジェクトが壊れる

– Pythonは終わる

だからGuidoは 「最小限の変更」 を選んだ。

> 「既存の `from logger import` はそのままにして、 `from .logger import` という新文法を追加しよう」

――これが、たった1文字 `.` で挙動が変わる「クソ仕様」の誕生です。

2-3. なぜ `.` という文字を選んだのか？（UNIXの悪影響）

ここでまた疑問が湧きます。

> 「なぜ `.` なんだ？ もっと目立つ文字（@や#や>）にすればよかったのに。」

その答えは「UNIXの伝統をそのまま流用した」からです。

UNIXでは：

– `.` = カレントディレクトリ

– `..` = 親ディレクトリ

Pythonの開発者はこの記号をそのままインポートに持ち込みました。

つまり：

– `.logger` → 「このフォルダのlogger.py」

– `..utils` → 「1つ上のフォルダのutils.py」

しかし――UNIXの`.`は「コマンド実行時のカレントディレクトリ」であって「インポートのスコープ指定」ではありません。

異なる概念を無理やり同じ記号で表現した時点で混乱は必至でした。

しかも、後付け機能だったので「目立たせる余裕がなかった」。既存のコードを壊さないために、最小限の変更にせざるを得なかった――これが全ての元凶です。

◆ 第3章：AS/400と比較してわかる「Pythonの設計限界」

ここで、私が以前からリスペクトしているAS/400の思想と比較してみましょう。
(私が、数十年に渡って使用して来たSystem/38から)

AS/400のLIBL（ライブラリリスト）は――

– 明示的

– 階層が固定（正確には階層ではない*LIBL(LibraryのList順)）

– 参照順序が変わらない

– 同名オブジェクトでも属性で区別（オブジェクト属性が異なれば、同じLibraryに配置できる。）

– 誤参照が起きないように設計されている（同じObject（同じ属性が）別のLibraryに存在しても、*LIBL順に、更新・参照：だからテスト環境の整備がとても柔軟で楽CHGLIBL LIBL（TestLib MainLib）で、Testに存在しないObjectは、MainのObejectを利用・参照(誤ってMainのObjectを更新させない様に指定できる。)）

つまり、「ヒューマンエラーが起きないように設計されている」 のです。

対してPythonのインポートは――

– 暗黙的

– sys.pathの順序に依存

– OSのディレクトリ列挙順に依存

– 同名ファイルがあれば競合

– 誤参照が普通に起きる

– しかも `.` という1文字で挙動が変わる

これは「エラーが起きるように設計されている」とすら言えます。

「急がば回れ」という言葉があります。

事前に設計をちゃんとして、後で困らないようにする――これがプロのやり方。

Pythonのインポート機構は 「急がば回れ」の真逆。

「とりあえず後で何とかする」で作った結果が、30年経っても修正されずに残っている。

AS/400の思想から見れば、Pythonのインポートは「危険で曖昧で分かりにくい」という評価は当然です。

◆ 第4章：他にもある「1文字地獄」の数々

「他にも `.` １文字だけの違いで切り分ける定義があるのだろうか？」

ある。しかも大量にある。

地獄その1：`=` と `==`

```python
# 代入（値が変わる）
a = 10

# 比較（True/Falseを返す）
a == 10
```

たった1文字違いで、処理が完全に変わる。

バグの温床ランキング常連。私も昨日これでハマりました。

地獄その2：`is` と `==`

```python
a = [1, 2, 3]
b = [1, 2, 3]

a == b  # True（値が同じ）
a is b  # False（別のオブジェクト）
```

「オブジェクトの同一性」という概念。初心者に理解させるのは至難の業。私もまだ完全には理解できていません。

地獄その3：`*args` と `**kwargs`

```python
def func(*args):    # タプルで受け取る
    pass

def func(**kwargs): # 辞書で受け取る
    pass
```

`*`（アスタリスク）が1つか2つかで意味が変わる。

しかも、これらは併用できます。

```python
def func(*args, **kwargs):
    pass
```

「もういい、頭が爆発しそうだ」――これが私の正直な気持ちです。

地獄その4：`.` と `..` の相対インポート

そして極めつけがこれ。

```python
from .logger import log_info   # 同じフォルダ
from ..logger import log_info  # 1つ上のフォルダ
```

たった1文字のドットの数で、参照先が変わる。

目が悪いと見逃す。私の目のせいじゃない。設計が悪いんです。

◆ 第5章：なぜPythonはこの「クソ仕様」で生き残ったのか？

ここが一番不思議なポイント。

こんなに分かりにくい仕様なのに、なぜPythonは世界で最も使われる言語のひとつになったのか？

理由1：シンプルさの「見せかけ」が初心者を騙した

「Hello World」が1行で書ける。

リスト操作が直感的。

インデントでブロックを表現。

――初心者は「簡単だ！」と思って飛びつく。

しかし、そこから先は地獄の入り口。私がまさにその状態です。

理由2：データサイエンス・AIブームに乗った

Pythonがここまで使われるようになった最大の理由は――

「他に選択肢がなかったから」。

データサイエンティストはプログラマーじゃない。仕方なくPythonを使っている。

「インポートの仕様が分かりにくい」なんて問題は、データ分析には関係ないから放置された。

理由3：コミュニティが「仕様は仕様」と受け入れた

Pythonコミュニティには 「仕様がクソでも、それがPythonの特徴」 という謎のカルチャーがある。

「なぜ `.` なのか？」と質問すると：

> 「それはPythonの仕様だから。覚えなさい。」

――これが答え。

AS/400の思想から見れば絶対にありえない。

AS/400では「分かりにくい」は容認されない。
なぜならエンタープライズでは「ヒューマンエラーを減らす」が最優先だから。
(私は、ミッションクリティカルの世界で育ち生きてきた。)

対してPythonは 「個人の自己責任」 の文化。

当然、「個人の自己責任」 の世界観も必要だし、否定している訳ではない。
（人は「ポカをする。」世界の冠たるトヨタ自動車の生産管理システムには「ポカよけの仕組みがある」）なぜ、ITの世界で「ポカよけ」しない？

ことわざにも「転ばぬ先の杖」がある。

英語にも「Haste makes wasteなど」がある。「急ぐと結果的に遅くなる」という、人生の普遍的な真理（ことわざ）を語るフレーズ。Walk, don’t run.「今は落ち着いて、一歩ずつ進むときだ」と、目の前の行動に対して具体的にブレーキをかけるフレーズ。

◆ 第6章：「急がば回れ」――私がこの経験から学んだこと

「急がば回れ」

この言葉を私は大事にしています。

今回の経験で痛感したのは――

Pythonの設計者は「急がば回れ」を無視した。

「とりあえず動けばいい」「後で何とかする」で作った結果が30年経っても修正されない。

これに対して、私が作ろうとしているバッチ処理では「急がば回れ」を徹底する。

なぜなら、DeepSeek-R1(cyberagent-DeepSeek-R1-Distill-Qwen-14B-Japanese-Q5_K_M.gguf）の暴走に疲れたから。シェルスクリプト(.sh)では限界だったから。Qwen2.5-14B-Instruct-Q5_K_M.ggufに替え、だからPythonを選んだのに、この始末。

でも、愚痴を言っても始まらない。

私が実践する「対策3選」

対策1：明示的な絶対インポートを使う

```python
# 悪い例（混乱する）
from .logger import log_info

# 良い例（明確）
from PGM-N.logger import log_info
```

対策2：パッケージ化してしまう

`setup.py` を作ってインストール可能なパッケージにする。

```python
# インストール後はこれでOK
from logger import log_info
```

対策3：全部のインポートをmain.pyだけに集約する

いわゆる「ファサードパターン」。

`main.py` だけが他のモジュールをインポートし、それ以外のモジュールは `main.py` 経由でしか呼ばない。

私が選んだのは対策3。

だって、バッチ処理なら構造は単純でいい。複雑にするとバグるから。これこそ「急がば回れ」の精神です。

◆ 第7章：結論――Pythonは「クソ仕様」だけど、それでも選ばれる理由

ここで、3時間悩んだ私の言葉をそのまま書きます。

> 「パイソンの開発者が存命なら申し訳ないが、なぜクソ急いだ、後先考えなかった。先頭の `.` たった１文字で挙動が変わる仕様なんて、見分けがつかないよ。」

まったくその通り。

Pythonのインポート設計は 「後先考えなかった」 の一言に尽きる。

しかし――

それでもPythonは生き残り、世界中で使われている。

その理由は：

1. 「最初のハードルが異常に低い」 から

2. 「データサイエンス・AIという巨大な波に乗った」 から

3. 「コミュニティが巨大で、どんな問題もググれば解決策が出てくる」 から

つまり、「言語そのものの完成度」ではなく「エコシステムの強さ」 で勝っている。

これは、AS/400のような「完成された思想を持つシステム」とは真逆の価値観。

そして私は――

Pythonを選んだことを後悔していない。いや、正確に言えば「後悔しているが、他に選択肢がない」。

ローカルPC（LMStudioじゃない、WSL2だ）でバッチのジョブを作り始めて早1カ月。DeepSeek-R1の暴走に疲れ、シェルスクリプトじゃあどうにもならないと、Qwen2.5-14B-Instruct-Q5_K_M.ggufに替え、Pythonを選んだ。

実は、Pythonを知ってまだ1週間に届かない。そしてPythonの「クソ具合」を知ったのが昨日。

それでも、私はこの言語と付き合っていく。

だって、AIオーケストレーションの最適解が、今のところPythonだから。

【DeepSeek暴走対策】AIオーケストレーションの限界を超える、ガードレールを取り入れたエンタープライズ級Pythonバッチ設計

AIに丸投げでは出来高50%未満の赤点？AS/400のCLP構造や150語のルールでDeepSeekが暴走した実体験から、Copilotとの役割分担、Claude 4.5 Sonnetの有効性、PCローカル環境（Ryzen AI 9）で品質100%を叩き出すPythonパイプラインの最終設計図までを徹底解説。Ryzen AI 9 HX470 LLM

イイネ.biz

2026.05.23

◆ おわりに――同じ罠にはまったあなたへ

Pythonを知ってまだ1週間――

それでいて「この仕様はおかしい」と感じたあなた（そして私）の感覚は、まったく正しい。

むしろ、長年Pythonを触っている人ほど「仕様は仕様」と麻痺している。

「急がば回れ」――この言葉を忘れずに。

Pythonの `import` システムは「急いで作って後でひどい目を見た」典型例。

あなたが作っているバッチ処理では、同じ過ちを繰り返さないでほしい。

なお、このブログを書き終えた今も、私のDeepSeekバッチは相変わらず暴走している。今度はメモリリークらしい。(<Thinking>が止まらない。制御できない。だから、Qwen2.5-14B-Instruct-Q5_K_M.ggufに)

Pythonを選んだことを後悔しつつ、でも他に選択肢がないので、これからデバッグを続けます。

あなたのバッチ処理が無事に完成することを、同じ罠にはまった者として心から願っています。

Python（パイソン）の概要と特徴

AI開発やデータ分析、Webシステム、自動化スクリプトまで幅広く使われる世界的人気のプログラミング言語です。

💡 主な特徴

• シンプルな構文：読みやすさを重視した設計（インデントによるブロック表現）。
• 圧倒的なライブラリ量：機械学習（AI）からデータ処理、スクリプト作成まで部品が豊富。

🚀 独自の優位点

• 開発効率の高さ：少ない行数で記述でき、初心者からプロまで直感的にコードが書ける。
• 強力なコミュニティ：世界中に開発者が多く、エラーの解決策や情報がネット上に溢れている。

⚠️ 知っておくべき弱点（落とし穴）

• 実行速度が遅い：インタプリタ言語（逐次実行）のため、C言語等に比べ処理速度が劣る。
• インポートの曖昧さ：外部モジュールを読み込む際、「現在のフォルダ ＋ システム全体（環境変数）」を上から適当に探すだけの仕様。自作ファイルと同名の有名ライブラリ（例：math.pyやjson.pyなど）を同じフォルダに作ると、名前が衝突して読み込みエラー（シャドーイング）を起こす。
• バージョンと環境管理の複雑さ：グローバル環境を汚しやすく、プロジェクトごとに仮想環境（venvなど）を作って管理しないと、ライブラリの依存関係が崩壊しやすい。

◆ 参考：今回のブログで書いた「Pythonクソ仕様」チェックリスト

– [x] 相対インポートの `.` 問題

– [x] `=` と `==` の違い

– [x] `is` と `==` の違い 

– [x] `*args` と `**kwargs` の違い

– [x] AS/400との比較

– [x] 「急がば回れ」対「とりあえず実装」

– [x] 3時間溶かした実体験 **あなたの「これもクソだ」という声、ぜひコメントで聞かせてください。

インデントの位置(数)でネストが壊れる馬鹿仕様

j1nak@jn260303-AI9x1-HX470:/mnt/g/@Ubuntu/Source$ python3 -m python_job_n01.main | tee output.log
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/mnt/g/@Ubuntu/Source/python_job_n01/main.py", line 23, in <module>  
    from .split_chunks import split_into_chunks
  File "/mnt/g/@Ubuntu/Source/python_job_n01/split_chunks.py", line 71 

    fname = chunks_dir / f"{basename}_chunk_{i:03d}.txt"
    ^
IndentationError: expected an indented block after 'for' statement on line 68
j1nak@jn260303-AI9x1-HX470:/mnt/g/@Ubuntu/Source$

### 解説
  File "/mnt/g/@Ubuntu/Source/python_job_n01/main.py", line 23, in <module>  
### ここ（main.pyのline 23,でsplit_chunks.pyを呼び出している）

  File "/mnt/g/@Ubuntu/Source/python_job_n01/split_chunks.py", line 71 
### ここ（split_chunks.pyのline 71で）エラー➡インデントが揃っていないから。
### 私から言わせれば、無茶苦茶な仕様「インデントが揃っていなダケでネストが壊れる」。
    ^
IndentationError: expected an indented block after 'for' statement on line 68
### ここが「IndentationError:」エラーメッセージ

実際のインデントのずれを、Sublime Textの画像でお見せする(Line71)

インデント調整後を、Sublime Textの画像でお見せする(Line71)

これが、pythonのインデント地獄

続きはここから

【LLM開発】なぜPythonの仕様に絶望しても、AIオーケストレーションやバッチ開発でPython一択になるのか？3つの決定的な理由

インデントのズレで崩壊し、ファイル名1つでヘソを曲げるPythonが、なぜ世界シェア1位なのか？「たった1文字で3時間溶かした」エンジニアが、AI・OCRバッチ開発の現場で直面したPythonの圧倒的な「接着力」と、歪んだエコシステムの歴史を暴く。Ryzen AI 9 HX470 LLM

イイネ.biz

2026.06.01