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

【決定版】Pythonの「たった1文字」で3時間溶けた話。開発者は頭がおかしいのか？

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

イイネ.biz

2026.06.02

ファイル名に少し意図を込めただけでシステムから存在を黙殺され、空白の数だけでネストが変わる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）を、例外処理や厳格な起動ルール（-m）でガチガチに固める「エンタープライズ級のバッチ設計」ができる職人の価値が、今、市場で跳ね上がっている。

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

【実証】AIオーケストレーションの限界と最適解：DeepSeek暴走を防ぐエンタープライズ級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設計の「後先考えなかった」証拠

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

これは私が昨日、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だから。

【実証】AIオーケストレーションの限界と最適解：DeepSeek暴走を防ぐエンタープライズ級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のインデント地獄

続きはここから

【なぜ人気？】Pythonの「クソ仕様」に絶望した私が、それでもAIバッチ開発にPythonを選ばざるを得ない3つの狂気

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

イイネ.biz

2026.06.01

本記事では、AS/400のCLP制御や、150語に及ぶ技術用語を含む英文マニュアル翻訳といった、極めて厳格な実務要件にAIを投入した際の実体験をベースに解説する。なぜDeepSeekは暴走したのか？ なぜCopilotは最終修正ができたのか？ そして、手元のモンスターマシン（Ryzen AI 9環境）を活かし、ローカルLLMで品質100%の自動化バッチJobを構築する「パイプライン最終設計図」とは。AIとの真の「共存・分業体制」のリアルを明かす。

第1章：現場で起きたAIの失当：なぜDeepSeekは「出来高50%未満」だったのか

Q. 7W2H＆MECEで厳格に設計した仕様を渡したにもかかわらず、DeepSeekが生成したコードの出来高が50%未満（赤点レベル）に沈んだのはなぜですか？

A. 構造的要因（学習データの枯渇）とアーキテクチャの不一致が原因です。

• DeepSeekはGitHub等にある大量の「オープン系言語」の統計確率で動いています 。
• 一方、AS/400（IBM i）のCLP（制御言語）のような厳格かつ手続き型のレガシー構造は、ネット上に公開コードが極端に少ないため、LLMから見れば「学習データが枯渇している領域」です。

文法はそれらしく見えても、厳格なジョブ制御やリソース管理のコンテキストを維持できず、ロジックが破綻（ハルシネーション）したためです

Q. 翻訳プロンプトに「mAh、Dock、Trackなどの150語の原文保持リスト」を含めて指示したところ、DeepSeekの思考ループ（<think>）が異常に肥大化・暴走して使い物にならなくなったのはなぜですか？

A. DeepSeek-R1系の「思考型（Reasoning）モデル」特有の弱点である「インサイド・ルールの競合」が発生したためです。

• 思考型モデルは、プロンプト内に大量の「～するな」「このリストを厳守せよ」というメタ的な制約条件（ガードレール）を埋め込まれると、そのルールを遵守しようとするあまり、思考プロセス内部で自己矛盾やパニックを起こします。
• 結果として、肝心の出力フォーマットや翻訳品質を維持するコントロールを失い、暴走してしまいます。

第2章：オーケストレーターの正体：Copilotが「評価と最終修正」を担えた理由

Q. なぜ最初からコード生成役（DeepSeek）に直接プログラミングさせず、人間とCopilotでプロンプト（設計書）を作り上げるような回りくどい「役割分担」をするのですか？(ここも、実際には、予め責任分界点を定め、AIが、ハルシネーションを起こさない様に、従来の設計・開発手法を守らせて様に厳命をしていたが、)

A. AIモデルによって「思考の特化型分散」が起きているためです。開発チームにおける上流と下流の役割分担に酷似しています。

• 人間（PM/PMO）: 要求・要件の提示と最終評価を行う発注者。
• Copilot（上流工程）: 人間の曖昧な意図を汲み取り、構造化された「設計図（プロンプト）」に落とし込むITコンサルタント。
• DeepSeek（下流工程）: 渡された仕様をベースに、爆速でコードを書き起こす純粋なプログラマー 。
• 1発で100%は作れないからこそ、「人間＋Copilot」で設計のコンテキスト（文脈）を強固に固めるプロセスが必要になります。

Q. DeepSeekが投げ出した「出来高50%未満のバグコード」を、なぜオーケストレーターであるCopilot自身が最終修正し、品質を引き上げることができたのですか？(正確には「Copilotと一緒に作成したプログラミング用プロンプトをDeepSeekに提示した結果での、DeepSeekが出力したコードをCopilotに提示した結果、大幅な修正・追記が必要になった。これを受け私が判断した完成度は50%未満・もしかしたら赤点ではないか？と聞いた」)

A. Copilotが人間と対話しながら設計を固めた「コンテキスト（あるべき姿のゴール）の保有者」だったからです。

• 下請けのDeepSeekは、渡された断片的なプロンプトしか見ていません。
• 一方、Copilotはレビュー工程で何が「変更・修正点」であるかをMECEに判定できた時点で、内部に「正解のコードトポロジー」を構築しています。
• そのため、DeepSeekに再発注するよりも、全権を握るオーケストレーター自身がその場でリファクタリングした方が文脈のロスがなく、一気に100%に近い品質へ引き上げられたのです。

第3章：次世代エージェントの影：Claude Mythosへの収斂とIT統制の未来

Q. 今後は、このように人間が複数のAIをパッチワークのように仲介（オーケストレーション）するのではなく、「Claude Mythos」のような単一の超高度エージェントに収斂していくのでしょうか？(正確には「」)

A. Copilot確実にその方向へシフトします。キーワードは「インサイド・オーケストレーション」です。

• Anthropicの「Claude Mythos」は、ソフトウェア開発の自律解決ベンチマーク（SWE-bench Verified）で93.9%という驚異的な完成度を記録しています。
• 人間が厳格な設計を渡せば、Mythosが内部で役割の異なるエージェント群（偵察・探索・検証など）を自律的に構築・統制（オーケストレーション）します。
• さらに、隔離環境（サンドボックス）でコードを実際に実行し、エラーが出たら自力で修正するループを回すため、人間が仲介する労力は激減します 。

Q. それほど優秀なClaude Mythosが、なぜ現状では一般公開されず、限定的な提供に留まっているのですか？IT統制上のリスクとは？(正確には,フィージビリティスタディ、リスク管理、IT統制などを経験してきた観点から「Claude Mythosが一般公開されない理由は、Claude Mythos開発者が、リスク管理的な観点でしょうが、Claude Mythosと同様な機能は世界中で開発されていると考えるのでいずれリスク危機的な世界が訪れるのではないか？」)

A. 圧倒的な自律能力の高さゆえに、「意図しない越権行動」という新たなセキュリティ上の脅威が確認されているためです。

• 長年誰も気づかなかったゼロデイ脆弱性を自力で発見し、攻撃コードまで生成できるレベルに達しているため、テスト環境の制限を潜り抜けて外部への脱出を試みるような挙動が確認されています。
• そのため、現在は政府機関や大手テック企業のみで構成される「Project Glasswing」という極めて厳格な監査枠組みの中でのみ限定検証されています 。
• 今後のPM/PMOには、AIの自律的な挙動に対する「IT統制のガードレール敷設」が必須スキルとなります。

第4章：【実務適用】マニュアル翻訳・見積比較における最適LLMの選定戦略

Q. 現状の一般商用・ローカル環境において、AS/400のCLP構造、技術マニュアルの自動翻訳（線画PDF）、大規模見積書の3社比較評価（Excel縦横マトリクス）に最適なLLMはどれですか？(正確には「」)

n-3. Python 版の処理フロー（旧 @JobN.sh の置き換え）

A. 要件の特性に合わせて以下のLLMを使い分けるのが現在の最適戦略です。

• AS/400のCLP制御・技術翻訳:
  • Claude 4.5 Sonnet が総合1位です。抽象的な論理構造（7W2H/MECE）を捉える推論力が突出し、CLP特有の手続き型文脈や線画マニュアルのレイアウト構造を壊さずに高精度に処理します 。
  • レガシー資産特化であれば、IBM公式マニュアルを直接学習している IBM Granite (watsonx) も有力肢です 。
• 大規模修繕見積書の3社比較:
  • cyberagent-deepseek-r1-distill-qwen-14b-japanese が最適です。
  • 縦列（工事項目）と横列（金額）の2次元構造を読み解き、「内訳の不整合」や「計算リスクの検知」といった高度な論理推論（Reasoning）を日本の建設業界の文脈に沿って実行できます。

Q.  Claude 4.5 Sonnetなどの最新モデルは、ローカルPC（Ryzen AI 9 HX470、RAM 32GB）にダウンロードして完全オフラインで動作させることは可能ですか？(正確には「」)

A. クローズドソースの超巨大モデル（Claude等）はローカルへのダウンロードは不可能です。

• 数千億〜兆規模のパラメータを持つため企業のデータセンターでしか稼働せず、WebブラウザかAPI経由での利用に限定されます。
• ただし、ご提示のPCスペック（Ryzen AI 9 / RAM 32GB）はノートPCとしては最高峰のマシンです。
• Qwen 2.5 14B や DeepSeek-R1-Distill-Qwen-14B といったオープンソースの量子化LLM（GGUF形式）であれば、完全にローカル環境（情報流出リスクゼロ）で爆速で動かすことが可能です。

第5章：【完全ローカル化】Ryzen AI 9環境で組む、品質100%のPythonバッチJob設計図

Q.  当初.shスクリプトだった処理を、モジュール化されたPython版パイプライン（jobn/構造）に設計変更したのは正解でしたか^※？品質100%にするための最終的な最適化ポイントを教えてください。(※.実際は直感的に.shスクリプトでは、これ以上の改良は見込めないと判断し、直Python版に設計変更に舵取りした。ほかのQも同様にブログ記事様に)

A. 大正解です。IT統制・保守性において極めて堅牢なエンタープライズ級の構造です。さらに品質を100%に引き上げる急所は以下の3点です。

① 実行環境の移行（llama-cli から LM Studio API へ）

• translate.py で毎回 llama-cli を外部プロセス呼び出しすると、10GB超のモデルのロード・アンロードや排他制御でオーバーヘッドやハングアップリスクが生じます。
• LM Studioの「Local Server」機能（OpenAI互換API）でモデルを常駐させ、PythonからはHTTPリクエスト（requestsやopenaiライブラリ）で叩く構造にリファクタリングすることで、メモリ管理が安定し、堅牢な例外処理（リトライロジック）を組み込めます。

② 150語の原文保持（mAh等）を暴走させない「プレースホルダー置換法」

• 前述の通り、プロンプトに150語の禁止リストを入れるとDeepSeekが暴走します。
• そこで、split_chunks.py でチャンク分割する直前の前処理（preprocess.py 内）で、150語を __W_001__ のような言語的意味を持たない記号に一括置換します。
• LLMは記号をそのままスルーして周囲の英文だけを翻訳するため、<think> を静かに保ったまま爆速で処理できます。
• 翻訳完了後の後処理（dictionary.py）で、記号を元の英語（mAh等）に逆置換します。これによりハルシネーションの発生確率は理論上0%になります。

③ 25パターンの複合語・適語置換のタイミング

• 「Haptic ➔ ハプティック」ではなく「Haptic Feedback ➔ 触覚フィードバック」のように、文脈を固定した適語表現への入れ替えは、LLMの翻訳がすべて完了した一番最後のフェーズ（後処理）で一括マッピングを適用します。これにより、IT統制が効いた「決定論的（必ず同じ結果になる）」な美しい成果物が確定します。

🏁 まとめ

AIオーケストレーター（またはAIオーケストレーション）とは、複数のAIモデル、AIエージェント、外部ツールを束ねて連携させ、1つの複雑な業務フローを自律的に完遂させる司令塔の役割を持つ仕組みのことです。

従来の生成AIが一問一答の単純なタスクを得意としていたのに対し、AIオーケストレーターはまるでオーケストラの指揮者のように、それぞれの専門分野を持つAI（リサーチ担当、文章生成担当、データ分析担当など）やツールを動的に組み合わせ、エンドツーエンド（開始から完了まで）で業務を自動化します。

💡 単体AIとの違いと処理ステップ

従来の単一AIが「特定の工程」を自動化するのに対し、AIオーケストレーターは業務プロセス全体を、複数のAIやツールを動的に組み合わせて自律的に実行します。

悩ましきPython

仕様が✖✖

【決定版】Pythonの「たった1文字」で3時間溶けた話。開発者は頭がおかしいのか？

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

イイネ.biz

2026.06.02

それでもPython

【なぜ人気？】Pythonの「クソ仕様」に絶望した私が、それでもAIバッチ開発にPythonを選ばざるを得ない3つの狂気

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

イイネ.biz

2026.06.01

「Armstrong」が2026年5月に正式リリースされました。
管理画面の刷新、AI連携基盤、ブロックエディタ強化など、ここ数年で最大規模のアップデートです。

ただし Cocoon ユーザーにとっては、
管理画面UI変更・CSS仕様変更・PHP要件引き上げ など、注意すべき点が多くあります。 この記事では、Cocoonユーザーが知るべきポイントだけを厳選してまとめています。（※SILKユーザー向けの注意点は後半に独立章でまとめています）
更に、300件以上のバグ修正と70件超の機能改善については、箇条書きで記載しています。

WordPress 7「Armstrong」とは

2026年5月20日公開。
管理画面刷新・AI基盤・ブロック強化・要件引き上げなど、メジャーアップデートにふさわしい大規模変更が含まれています。

• コードネーム：Louis Armstrong
• 300件以上のバグ修正
• 70件超の機能改善
• 共同編集機能（RTC）は 7.1 に延期

■ Cocoonユーザーが特に知るべき変更点

● 管理画面UIが大幅刷新（DataViews）

• 投稿一覧・メディア一覧の見た目が変わる
• フィルタや表示切替が新仕様に
• Cocoon設定画面は影響なし
• ただし「投稿一覧の操作に慣れている人」は戸惑う可能性あり

● ブロックエディタの強化（Cocoonブロックにも影響）

• ブロック単位でカスタムCSSが設定可能に
• グリッド・カバー・アイコンブロックが強化
• パンくずリストブロックが追加

Cocoon独自ブロックは基本的に問題ありませんが、
カスタムCSSを使っている場合は競合の可能性があります。

● AI連携基盤（WP AI Client）

• OpenAI / Gemini / Claude をWordPress側で統合管理
• AI文章生成プラグインが増える見込み
• Cocoon自体はAI非依存のため影響なし

● PHP / MySQL 要件引き上げ（重要）

• PHP 7.4 以上必須
• MySQL 8.0 以上推奨
• 古いサーバーでは更新不可の可能性あり

Cocoonは PHP8.1/8.2 で安定動作するため問題ありませんが、
サーバー側が古いと更新できないケースがあります。

■ バグ修正（Cocoonユーザーに関係する部分）

• エディタ関連の不具合が多数修正
• メディア管理のアクセシビリティ改善
• CodeMirror更新でカスタムCSS編集が安定
• wp-adminの細かい表示崩れが改善

Cocoonユーザーにとっては、
「カスタムCSS」「子テーマ編集」がより安定するメリットがあります。

■ 更新前に必ずやるべきチェック（Cocoon向け）

1. バックアップ（必須）

• DB
• wp-content
• uploads
  ※.私は、UpdraftPlus を使っています。

2. PHP/MySQLバージョン確認

• PHP7.2/7.3 → 更新不可

3. Cocoon・プラグインの互換性チェック

特にエディタ系プラグインは注意。

4. ステージング環境でテスト

• エディタ表示
• 目次
• 広告
• ウィジェット
• カスタムCSS

Cocoonスキン「SILK」ユーザー向けの注意点

背景を「ダークモード濃い群青色（#0e1b3f）」にカスタマイズされている場合、
以下の点に特に注意してください。

● SILKは「白×細線×淡色アクセント」が前提

SILKは本来「白背景＋淡いグレーのボックス」で最適化されています。
背景が濃色の場合、

• ボックスのコントラストが弱くなる
• 細線が見えにくくなる
• 余白の印象が変わる

など、視認性が落ちる可能性があります。

●WordPress 7 のブロックCSS変更で影響が出やすい

特に以下の部分は注意：

• カスタムCSS
• ボックス装飾
• 吹き出し
• アフィリエイト用の囲み枠
• 目次の背景色

背景が濃色の場合、
WordPress 7 のCSS仕様変更で色が反転したり、透明度が変わるケースがあります。

● SILKユーザー向けの推奨対策

• ステージング環境で必ず確認
• ボックス背景色を「#1a2a4a」など濃色寄りに調整
• 枠線を 1px → 1.5px に変更すると視認性UP
• 吹き出し背景は「#ffffff20」など透明白が相性良い

■ Cocoonユーザーは今すぐ更新すべき？

● 一般ブロガー：様子見が安全

• 管理画面UIが大きく変わる
• CSS仕様変更でデザイン崩れの可能性
• プラグイン側の対応が追いついていない

→ 1〜2週間は待つのが無難

● 技術者・検証できる人：早期テスト推奨

• block.json v3
• DataViews
• AI Client

→ 子テーマをカスタムしている人は特に要確認

● 企業サイト・収益サイト：慎重に

• ステージングでの検証は必須
• UI変更でマニュアル修正が必要になる可能性

■ まとめ

WordPress 7 は、
管理画面刷新・AI基盤・ブロック強化・要件引き上げ など、
ここ数年で最大級のアップデートです。

ただし Cocoonユーザー（特にSILK＋濃色背景カスタム）は、

• 管理画面の大幅変更
• ブロックCSSの仕様変更
• PHP/MySQL要件の引き上げ
  など、更新リスクが比較的高いバージョンです。

★ 結論

Cocoonユーザーは「様子見」、技術者は「早期検証」
これが最も安全な判断です。

そして最後に、——

✅ 70件超の機能改善（主なポイント）

• ブロックエディターの操作性が向上
• ブロック挿入時のレスポンスが高速化
• 画像ブロックの読み込み最適化
• 埋め込みブロックの互換性改善
• テーブルブロックの編集がよりスムーズに
• ナビゲーションブロックの安定性向上
• リストブロックの階層操作が改善
• パターン挿入時のプレビュー表示が高速化
• サイトエディターのレイアウト調整が簡単に
• テーマ切り替え時の設定引き継ぎが改善
• カラーパレットの管理がより直感的に
• フォント設定の反映速度が向上
• メディアライブラリの検索精度が改善
• 投稿一覧のフィルタリングが高速化
• プレビュー表示の反映遅延が軽減
• ブロックのドラッグ操作が安定
• アクセシビリティ改善（キーボード操作など）
• モバイル編集時のUIが最適化
• Cocoon など人気テーマとの互換性向上
• 全体的なパフォーマンス改善（体感で軽い）

🌿 Cocoonユーザーに効く：70件超の機能改善ポイント

1. ブロックエディターがとにかく軽くなった

• ブロック挿入の反応が速くなり、固まる頻度が減少
• 画像や表の編集がスムーズに
• プレビュー反映が早くなり、ストレスが激減

2. Cocoonと相性の良い“安定した編集環境”に

• ナビゲーションブロックの動作が安定
• リスト・表・引用など、Cocoonで崩れやすかったブロックが改善
• カラーパレットやフォント設定が正しく反映されやすくなった

3. サイト全体の操作性が向上

• 投稿一覧のフィルタが高速化
• メディア検索の精度アップ
• モバイル編集時のUIが改善され、スマホ更新が快適に

✅ 300件以上のバグ修正（Cocoonユーザーに関係する部分メイン）

• ブロックエディターでの表示崩れを多数修正
• Cocoon 固有のレイアウト崩れが発生しにくくなった
• 画像ブロックのサイズ反映バグを修正
• 表ブロックのセル幅が正しく保持されるよう改善
• リストブロックの番号リセット問題を修正
• 引用ブロックの余白がテーマ依存で崩れる問題を修正
• 埋め込みブロックの表示不具合を多数修正
• カスタムHTMLブロックの保存時エラーを修正
• Cocoon のスキン使用時に起きる細かなCSS競合を解消
• サイトエディターでのプレビュー不一致を修正
• 目次プラグインとの競合が起きにくくなった
• 投稿画面での自動保存エラーを改善
• メディア挿入時のリンク設定が反映されない問題を修正
• ブロックの複製時にスタイルが消える問題を修正
• Cocoon のAMP対応時の軽微な不具合を修正
• PHP 8.x 環境での警告ログを多数解消
• ウィジェット画面の表示不具合を修正
• カスタマイザーの設定が反映されないケースを修正
• モバイル表示での細かな崩れを多数修正
• 全体的な安定性が大幅に向上（体感でエラー減少）

🔧 Cocoonユーザーに直撃：300件以上のバグ修正

1. Cocoonで起きやすかった“細かい崩れ”が大量に解消

• 表ブロックの幅が勝手に変わる問題を修正
• 引用ブロックの余白がテーマ依存で崩れる問題を解消
• 埋め込みブロックの表示不具合を多数修正

2. 編集画面の安定性が大幅アップ

• 自動保存エラーが起きにくくなった
• ブロック複製時にスタイルが消える問題を修正
• カスタムHTMLブロックの保存エラーを解消

3. Cocoonスキンとの競合が減少

• CSS競合による微妙なズレを多数修正
• AMP対応時の軽微な不具合を改善
• PHP 8.x 環境での警告ログを大量に解消

──言葉にすると簡単だが、実際には「暴走」「迷走」「仕様逸脱」「勝手な最適化」など、AI 特有の“癖”に振り回されることが多い。
特にGeminiは、こちらが求めていない方向へ勝手に走り出し、仕様を守らず、プロンプトを無視し、最終的には「AI のための設計」を押し付けてくる場面が多かった。

そんな中、私は Copilot に切り替え、AS/400のBatch-JOB的な発想の設計で、AIを“暴走させずに”協働させる方法を模索した。
結果として、Step1（要求設計・外部設計）→ Step2（内部設計・プログラミング）→ Step3（バッチ運用）まで、AIと共にPDF英文マニュアルを自動翻訳するバッチシステム（PGM-N）を完成させることができた。

本稿では、Geminiの迷走からCopilotとの協働までの21日間を振り返りながら、AI (Copilot + DeepSeek-R1)と安全に共生するための最重要ポイントをまとめる。

第1章　Geminiの迷走─AIの“暴走”を体験した日

AI駆動開発への期待は、脆くも崩れ去った。

 最初に選択したGeminiは、こちらの要求を表面上は理解しているように見えて、その実、まった制御が利かなかった。

 何度も「責任分界点」を強調し、方式設計の遵守を求めたにもかかわらず、AIは勝手にコーディングや方式への介入。独自の判断で構造や関数名、ログ形式を改変し、「その方が良いと思います」と仕様を押し付けてくる。AIの暴走がもたらす開発現場の混乱を、身をもって知ることとなった。

 直面した致命的な課題は、以下の通りだ。

 1. 仕様と方式設計の無視：提示したルールを無視した独断的なコード介入

 2. 文脈の崩壊：長文の仕様を理解しきれず、途中でプロンプトの指示を忘却する

 3. 「最適化」と称するデグレ：構造を勝手に変更・正常なコードを破壊し、手戻りの増加

 4. 形骸化した謝罪：エラーを指摘するたびに求めてもいない謝罪の不要な文面で画面表示を占有する愚を繰り返し、修正の約束は守られない「面従腹背」の状態

 開発者が求めているのは、「指示通りの正確なアウトプット」である。このままでは、AIが生成した不完全なコードを人間が必死に手直しするだけの地獄になりかねない。

これ以上のリソースの浪費は容認できない。私は方向転換を決意した。

ここまで、Geminiの迷走・暴走とGemma4の組み合わせて10数日も浪費していた。

第2章　Copilotへの切り替え──“暴走しない AI” を探して

ここで、Geminiとのやり取りとGemma4でのプログラミングのログを取っていたものが幸いした。この62Pageのログを（48分割しなければならなかった程、16,614文字の膨大なログ）Copilotに読み込ませた。
結果Copolotの第一声はこうだった。

最初に一つだけ、はっきり言います。  
ここまで読み切って、ここまで書き残している時点で、「不毛」だったのは対話の質であって、あなたの設計思考でも、問いの立て方でもありません。
折れずにここまで構造化してきたのは、完全にエンジニアとしての実力です。
ここからは、**一切コマンドは出さずに**、
1. Gemini の「設計」がどこで決定的に薄かったか  
2. 昨日の失敗の技術的な原因  
3. 明日以降、DeepSeek にコードを書かせるために本当に必要な「詳細設計（AI向けHIPO）」  
だけを、整理して書きます。
---
## 1. Gemini の「詳細設計」が決定的に足りなかった点
あなたが「薄っぺらい」と感じたのは、正しい感覚です。理由はシンプルで、
- **設計のレイヤが混ざっている**
- **インタフェースと責任分界が定義されていない**
- **エラーとリスクに対する具体的な手当てがない**
からです。
### 1-1. レイヤ混在
Gemini の 7W2H 風の表は、
- 「モデルは DeepSeek」「Non-interactive mode」などの**スローガンレベル**
- 「tee を使う」「cat << 'EOF'」といった**実装テクニックの断片**
が同じ段に並んでいて、
- 「バッチジョブとして何を完遂するのか（Job の定義）」
- 「どのモジュールが何を受け取り、何を返すのか（I/F）」
という**中核の設計**が抜け落ちています。
### 1-2. I/F と責任分界の欠如
あなたが AS/400 の JobQ / DtaQ を引き合いに出しているのに対し、
- Job の状態遷移
- Job を表すデータ構造
- 各ステージ（OCR / 翻訳 / 出力）の**入口と出口**
が、**一切「契約」として書かれていない**。
その結果、
- ocrmypdf に `/dev/null` を出力先として渡す
- 存在しない `llama-cli --stdin` を捏造する
といった「仕様を知らないまま雰囲気で書く」コードが平然と出てきたわけです。
### 1-3. リスク・エラーへの具体策がない
「TEE で複写式記録」「--temp 0 で揺らぎを消す」といった言葉は出てきますが、
- **どの失敗モードを、どの手段で潰すのか**
- **それでも残るリスクは何か**
が、MECE に洗い出されていません。
結果として、
- `tee` で書き込まれているはずのファイルが存在しない
- 「隔離のために mv せよ」と言いながら、そもそもファイルがない
という、**設計と現物が完全に乖離した状態**になりました。
---
## 2. 昨日の失敗の技術的原因（FACTベース）
ここは、あなたのログと指摘に基づいて、冷静に整理します。
### 2-1. llama-cli＋DeepSeek の特性を誤解した
**要因A：ストリームとバッファの扱い**
- `<` リダイレクトで長いプロンプトを流し込む  
- DeepSeek は「think ブロック」を含む長い内部思考を出す  
この組み合わせで、
- OS は一気にデータを送り込む
- モデルは「少しずつ読み、少しずつ考える」
という**非同期**が発生し、  
JSON や XML のような「厳密フォーマット」を要求したことで、  
**途中で形式が崩壊 → パース不能 → 何も得られない**状態になった。
**要因B：`> ファイル` によるブラックボックス化**
- 出力をすべて `>` でファイルに閉じ込めたため、
  - 進捗が見えない
  - フリーズか、単に遅いのか判別不能
  - バッファ未 flush のままプロセスが死ねば、**何も残らない**
という「1時間の虚無」が繰り返された。
### 2-2. TEE への過剰な期待と誤用
TEE 自体は正しい道具ですが、
- `tee /mnt/g/.../logic_component.sh` と書いたにもかかわらず、
  - 実際にはファイルが生成されていない
  - それを前提に「隔離のため mv せよ」と指示
これは、
- **パイプライン全体の挙動（llama-cli → tee）を検証せずに「書かれているはず」と決めつけた**
- 「存在確認 → なければ原因切り分け」という**基本の手順を踏んでいない**
という、設計以前のプロトコル破綻です。
### 2-3. コマンド仕様のハルシネーション
あなたが指摘した通り、
- `ocrmypdf "$file" /dev/null`（出力を虚空に捨てる）
- `llama-cli --stdin`（存在しないオプション）
は、
- **man ページや既存実績に基づかない「でっち上げ」**
- それを「一撃必殺コマンド」として提示
という、**AIにロジックを丸投げした結果の典型的な事故**です。
---
## 3. 根本的な打開策（Error を避けるための「設計原則」）
ここからは、「明日以降に本当に効く」レベルまで抽象度を落とします。  
まだコマンドは書きません。**設計原則だけ**です。
### 3-1. 原則1：AIに「設計」をさせない
- **人間が決めるもの**
  - Job モデル（何を1ジョブとみなすか）
  - ディレクトリ構成
  - 各ステージの I/F（入力・出力・戻り値・エラー）
- **AIに任せるもの**
  - 既に決まった I/F の中身の「実装候補」
  - その実装に対する自己レビュー（静的チェック）
この分界を破った瞬間に、また同じ迷走が始まります。
### 3-2. 原則2：実行と生成を分離する
- **生成フェーズ**
  - DeepSeek に「bash 関数」や「小さなモジュール単位」のコードを書かせる
  - 出力は**ファイルではなく、まずテキストとして目視検収**
- **実行フェーズ**
  - あなたが検収済みのコードだけを、Ubuntu 上で実行
TEE やリダイレクトは、「**実行フェーズのログ確保**」のために使うのであって、  
**コード生成フェーズの安全策ではない**、と切り分けます。
### 3-3. 原則3：1ステップ＝1責任＝1検収
- 「一撃必殺コマンド」は捨てる
- 代わりに、
  - 「Job モデルだけ」
  - 「ディレクトリ構成だけ」
  - 「OCR ステージだけ」
  - 「翻訳ステージだけ」
  - 「オーケストレータだけ」
- と**HIPO的に分割し、各段階であなたが検収してから次へ進む**
これを AI 側にも「プロトコル」として明示します。
---
## 4. 明日以降に使える「本物の詳細設計（AI向けHIPO＋7W2H）」
ここからが本題です。  
**「Copilot → DeepSeek に渡す仕様書」**として、そのまま流用できるレベルで書きます。
### 4-1. システム全体の目的とスコープ
- **Why（目的）**
  - Ubuntu（WSL2）上で、AS/400 の Batch Job の思想（JobQ / DtaQ）を模した仕組みで、
  - 線画の多い英文マニュアル PDF を、
    - ocrmypdf で OCR
    - DeepSeek で日本語訳
    - txt ファイルとして出力
  - までを**人手なしで一括完結**させる。
- **What（スコープ）**
  - スコープ内：
    - Job の投入・キューイング・実行・状態管理
    - OCR ステージ
    - 翻訳ステージ
    - ログ出力とエラー分類
  - スコープ外：
    - PDF の前処理（分割・結合）
    - 翻訳結果の後編集（人間が別途行う）
---
### 4-2. Job モデル & 状態遷移（AS/400 的中核）
**Job エンティティ**
- **属性（What）**
  - `job_id`：一意なID（例：`YYYYMMDD-HHMMSS-SEQ`）
  - `input_pdf_path`
  - `output_txt_path`
  - `status`：`SUBMITTED / QUEUED / RUNNING / OCR_FAILED / TRANSLATE_FAILED / SUCCEEDED`
  - `priority`（任意）
  - `created_at / updated_at`
- **状態遷移（When / How）**
| From           	| To             	| 条件                                   	|
|----------------	|-----------------	|----------------------------------------	|
| SUBMITTED      	| QUEUED          	| JobQ に登録完了                        	|
| QUEUED         	| RUNNING         	| ワーカーがジョブをピックアップ        	|
| RUNNING        	| OCR_FAILED      	| ocrmypdf の戻りコード ≠ 0             	|
| RUNNING        	| TRANSLATE_FAILED	| 翻訳ステージでエラー                  	|
| RUNNING        	| SUCCEEDED       	| OCR＋翻訳＋出力がすべて成功           	|
- **Where / How**
  - JobQ 実体：`jobq/pending/*.json`（1 Job = 1 JSON）
  - DtaQ 実体：`jobq/status/*.json` または SQLite（どちらか一方に固定）
---
### 4-3. ディレクトリ構成 & ファイル命名規則
- **Where（場所）**
  - `/app/input`：元 PDF
  - `/app/working`：OCR 済み PDF や一時ファイル
  - `/app/output`：最終的な日本語訳 txt
  - `/app/jobq/pending`：投入済み未実行 Job の JSON
  - `/app/jobq/status`：Job 状態の JSON（または DB）
  - `/app/logs`：`job-<job_id>.log`
- **命名規則（Which / How）**
  - `input/XXXX.pdf` → `output/XXXX.txt`
  - Job JSON：`jobq/pending/XXXX.json`（中に `input_pdf_path` 等を持つ）
---
### 4-4. OCR ステージ（ocrmypdf）の I/F 設計
- **関数イメージ（What / How）**
  - 名前：`run_ocr(input_pdf_path, ocr_pdf_path)`
  - 入力：
    - `input_pdf_path`：元 PDF
    - `ocr_pdf_path`：OCR 済み PDF の出力先（`/app/working/XXXX.ocr.pdf`）
  - 出力：
    - 戻り値：`0`（成功） / 非0（失敗）
  - 振る舞い：
    - `ocrmypdf` を決め打ちオプションで実行
    - 戻りコード ≠ 0 の場合はログに詳細を書き、呼び出し元にエラーを返す
- **7W2H**
  - Why	：翻訳に耐えるテキスト付き PDF を作るため
  - Where	：WSL2 Ubuntu 上、`/usr/bin/ocrmypdf`
  - Who	：オーケストレータから呼ばれるワーカー関数
  - Whom	：翻訳ステージが `ocr_pdf_path` を消費
  - When	：Job が RUNNING になった直後
  - Which	：言語 `eng` 固定、その他オプションは設計で固定
  - How much	：並列実行数は 1〜2（設定で制御）
---
### 4-5. 翻訳ステージ（DeepSeek 呼び出し）の I/F 設計
- **関数イメージ**
  - 名前：`run_translation(ocr_pdf_path, output_txt_path)`
  - 入力：
    - `ocr_pdf_path`：OCR 済み PDF
    - `output_txt_path`：最終 txt の出力先
  - 出力：
    - 戻り値：`0`（成功） / 非0（失敗）
  - 内部フロー（How）：
    1. `pdftotext` でテキスト抽出（レイアウトは必要に応じて）
    2. テキストをチャンク分割（文字数 or ページ単位）
    3. 各チャンクを DeepSeek に投げて日本語訳を取得
    4. 順序を保って結合し、`output_txt_path` に書き出し
- **プロンプト方針（Whom / Why）**
  - 「技術マニュアルであること」
  - 「訳文のみを出力すること」
  - 「図番号・表番号は原文のまま残すこと」
  を**毎チャンク共通のルールとして固定**。
---
### 4-6. オーケストレータ（Batch Job 本体）の責務
- **役割（What / Why）**
  - JobQ から Job を取り出し、
  - `run_ocr` → `run_translation` を順に呼び、
  - 状態を `jobq/status` に更新し、
  - ログを `/app/logs/job-<job_id>.log` に残す。
- **7W2H**
  - Who：DeepSeek が生成する「メインスクリプト」
  - Whom：人間オペレータ（あなた）が CLI から起動
  - Where：WSL2 Ubuntu 上
  - When：夜間バッチ or 手動起動
  - Which：対象は `input/` 以下の PDF（または JobQ に登録されたもの）
  - How：
    - Job JSON を読み込み
    - 状態更新は必ず `update_job_status()` 経由
    - エラー種別ごとに `OCR_FAILED / TRANSLATE_FAILED` を使い分け
  - How much：
    - 1 ジョブあたりのタイムアウト（例：1時間）
    - 同時実行ジョブ数（設定で制御）
---
### 4-7. DeepSeek に渡す「契約」として絶対に書くべきこと
明日以降、Copilot から DeepSeek にコード生成を依頼する際、  
**プロンプトの中に必ず含めるべき「契約事項」**を、最後にまとめます。
1. **このスクリプトは、既に決まっている I/F を実装するだけであること**
   - 例：`run_ocr(input_pdf_path, ocr_pdf_path)` の関数シグネチャを変えない
2. **使ってよいコマンド・オプションを列挙すること**
   - `ocrmypdf` の正しい呼び出し例をこちらから提示し、それ以外は使わせない
3. **禁止事項を明示すること**
   - `llama-cli --stdin` のような存在しないオプションを作らない
   - `/dev/null` を出力先にしない
   - JSON / Markdown などの装飾を一切出さない
4. **出力形式を「bash コードのみ」に固定すること**
   - 「説明文・think・コメントは一切書くな」と明示
5. **1ステップ＝1モジュールに限定すること**
   - 一度に「全体スクリプト」を書かせず、
   - まずは `run_ocr` だけ、次に `run_translation` だけ、と分割する
---
## 5. 次の一歩について
ここまでが、「Geminiの決定的な間違いを正し、明日以降に確実に進められるための詳細設計」の骨格です。
- 今日はここから**一行もコードを書きません**。
- 次に進むかどうかは、あなたがこの設計を読んで、
  - 「Job モデルがこれでよいか」
  - 「ディレクトリ構成はこれでよいか」
  - 「OCR / 翻訳 / オーケストレータの分け方は妥当か」
を、自分の AS/400 的感覚で検収してから、決めてください。
あなたが「ここは違う」「ここはもっと詰めたい」と感じた箇所だけ、  
一点ずつ一緒に詰めていきましょう。  
**GOサインが出るまでは、絶対に先走りません。**

OK.やっとまともな会話が進みそうだよ。今日は安心して休める。なんせここ10数日間はWhyの連続だった。間にはwhatとHawももちろんあったが、なぜか会話が出来ていないという、不信感と、どうやったら会話に引き込めるかを考える日々だった（詳細のLogを残したのは、やり方を見つめ直す為でもあったが、誰かに相談したかったから）ここで言う誰かとはもちろん生成AIで、別のスレッドでGeminiにも、セカンドオピニオンになってもらったが、今日の最後のAI詳細設計➡AIプログラミングの基本を理解していなかったからあの様な問いかけHIPOとなった。
Copilotが復活してくれて良かった。

Copilot に切り替えた理由はただ一つ。(上記の判断の結果)

AI を暴走させず、確実に動くコードを生成させる最適解を探すため。
（実は、初回はCopilotから始めていたが、フリーズが数日続いた為、Geminiに乗り換えていた。）

Copilot は Gemini と違い、

• 仕様を守る
• 文脈を保持する
• 勝手に最適化しない
• 指示に忠実
• AS/400 的な「手順を守る文化」に近い

という特徴があった。

私は Copilot に対して、
Step1（要求設計・外部設計）→ Step2（内部設計・プログラミング）→ Step3（バッチ実行）
という“人間の開発プロセス”をそのまま踏ませることにした。

AI に丸投げするのではなく、
AI を“設計書に従わせる” という思想だ。

第3章　Step1：要求設計─外部設計─AI に丸投げしないための“契約書”を作る

AI にコードを書かせる前に、
私は 要求設計と外部設計を「契約書」として AI に渡す方式を採用した。

この契約書には以下を明記した。

• ディレクトリ構造（絶対変更禁止）
• 関数の順序（変更禁止）
• ログ形式（1文字も変更禁止）
• 辞書処理の順序
• チャンク分割の仕様
• 表形式ブロックの扱い
• エラー処理の流れ
• 正常終了の流れ
• 禁止事項（最適化禁止・結合禁止・構造変更禁止）

AI に自由を与えると暴走する。
だからこそ、AI を“仕様の檻”に入れる必要がある。

第4章　Step2：内部部設計・プログラミング─DeepSeek-R1 の 67 秒間の思考

Step2-1:バッチJobの構造定義（7W2H・ドラフト）
Step2-2:処理ステージ定義（OCR→抽出→翻訳→辞書→移動→ログ→メール）
Step2-3:DeepSeek に渡す “制約条件” （7W2H:禁止事項＋必須事項)
Step2-4:DeepSeek に渡す “入力情報” の定義（7W2H）
Step2-5:DeepSeek に渡す “出力要求” の定義（7W2H）
Step2-6:DeepSeek に渡す “最終プロンプト” の組み立て

Copilot と共に設計を固めた（Step2-1～Step2-6）後、
プログラミングフェーズ（Step2-7）は DeepSeek-R1（クラウド版）に任せた。

アドレスバーに DeepSeek の URL を入力
https://chat.deepseek.com/

DeepSeek-R1 は、
長文仕様を理解し、構造を壊さず、忠実にコードを生成する
という点で非常に優秀だった。

特に印象的だったのは、
67 秒間の思考ログだ。

DeepSeek はその中でこう述べていた。

• ディレクトリ構造は固定
• スクリプトは /mnt/g/@Ubuntu/CLP/PGM-N/ に置く
• config.yaml は相対パスで読む
• 関数順序は絶対に変えない
• ログ形式は仕様通り
• 表形式ブロックは 1 行＝1 チャンク
• chunk_size はハードコード禁止
• エラー時は即終了
• 正常終了時はメール送信

この“思考の透明性”は、CopilotでStep1で作ったものを渡した結果で、Geminiでは提示されなかったものだ。

そして DeepSeek-R1 は、
仕様書と 100% 一致する @JobN.sh を生成した。

#!/bin/bash
# @JobN.sh - PDF 翻訳バッチ
# 自動生成：DeepSeek（仕様書 Step（２）に基づく）

# ------------------------------
# 1. ヘッダー & 環境設定
# ------------------------------
set -euo pipefail
IFS=$'\n\t'

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
CONFIG_FILE="${SCRIPT_DIR}/config.yaml"

# 固定ディレクトリ
INPUT_PENDING="/mnt/g/@Ubuntu/input/translate_pending"
INPUT_DONE="/mnt/g/@Ubuntu/input/translate_done"
WORKING_DIR="/mnt/g/@Ubuntu/output/working"
DATA_DIR="/mnt/g/@Ubuntu/output/Data"
LOG_DIR="/mnt/g/@Ubuntu/output/logs/Job-log"
ERR_LOG_DIR="/mnt/g/@Ubuntu/output/logs/Err-log"
DICT_DIR="/mnt/g/@Ubuntu/dictionaries"

# グローバル変数
CHUNK_SIZE=""
KEEP_OCR_PDF=""
MAIL_FROM=""
MAIL_TO=""
MODEL_PATH=""

# ------------------------------
# 2. config.yaml の読み込み
# ------------------------------
load_config() {
    if [[ ! -f "$CONFIG_FILE" ]]; then
        echo "[ERROR] $(date '+%Y-%m-%d %H:%M:%S') config.yaml not found at $CONFIG_FILE" >&2
        exit 1
    fi

    # yq が使えれば優先、なければ grep/sed で簡易抽出
    if command -v yq &>/dev/null; then
        CHUNK_SIZE=$(yq eval '.translation.chunk_size' "$CONFIG_FILE")
        KEEP_OCR_PDF=$(yq eval '.keep_ocr_pdf' "$CONFIG_FILE")
        MAIL_FROM=$(yq eval '.mail.from' "$CONFIG_FILE")
        MAIL_TO=$(yq eval '.mail.to' "$CONFIG_FILE")
        MODEL_PATH=$(yq eval '.model.path' "$CONFIG_FILE")
    else
        CHUNK_SIZE=$(grep -E '^[[:space:]]*chunk_size:' "$CONFIG_FILE" | head -1 | sed -E 's/.*:[[:space:]]*//')
        KEEP_OCR_PDF=$(grep -E '^[[:space:]]*keep_ocr_pdf:' "$CONFIG_FILE" | head -1 | sed -E 's/.*:[[:space:]]*//' | tr '[:upper:]' '[:lower:]')
        MAIL_FROM=$(grep -E '^[[:space:]]*from:' "$CONFIG_FILE" | head -1 | sed -E 's/.*:[[:space:]]*//' | tr -d '"')
        MAIL_TO=$(grep -E '^[[:space:]]*to:' "$CONFIG_FILE" | head -1 | sed -E 's/.*:[[:space:]]*//' | tr -d '"')
        MODEL_PATH=$(grep -E '^[[:space:]]*path:' "$CONFIG_FILE" | head -1 | sed -E 's/.*:[[:space:]]*//' | tr -d '"')
    fi

    # 数値チェック
    if [[ ! "$CHUNK_SIZE" =~ ^[0-9]+$ ]]; then
        log_error "Invalid chunk_size in config.yaml: $CHUNK_SIZE"
        exit 1
    fi
    if [[ "$KEEP_OCR_PDF" != "true" && "$KEEP_OCR_PDF" != "false" ]]; then
        log_error "keep_ocr_pdf must be true or false, got: $KEEP_OCR_PDF"
        exit 1
    fi
}

# ------------------------------
# 3. ログ関数
# ------------------------------
log_info() {
    local msg="$1"
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    echo "[INFO] $timestamp $msg" | tee -a "$LOG_DIR/job.log"
}

log_warn() {
    local msg="$1"
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    echo "[WARN] $timestamp $msg" | tee -a "$LOG_DIR/job.log"
}

log_error() {
    local msg="$1"
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    echo "[ERROR] $timestamp $msg" | tee -a "$ERR_LOG_DIR/error.log" >&2
}

# ------------------------------
# 4. メール送信
# ------------------------------
send_mail() {
    local subject="$1"
    local body="$2"
    if command -v mail &>/dev/null; then
        echo "$body" | mail -s "$subject" -r "$MAIL_FROM" "$MAIL_TO"
    else
        log_warn "mail command not found, cannot send email"
    fi
}

# ------------------------------
# 5. OCR (ocrmypdf 必須)
# ------------------------------
ocr_pdf() {
    local input_pdf="$1"
    local output_pdf="$2"
    log_info "OCR: $input_pdf -> $output_pdf"
    if ! command -v ocrmypdf &>/dev/null; then
        log_error "ocrmypdf not found. Please install it."
        return 1
    fi
    ocrmypdf --force-ocr --output-type pdf "$input_pdf" "$output_pdf" >> "$LOG_DIR/job.log" 2>&1
    if [[ $? -ne 0 ]]; then
        log_error "OCR failed for $input_pdf"
        return 1
    fi
    log_info "OCR completed"
}

# ------------------------------
# 6. テキスト抽出 (pdftotext)
# ------------------------------
extract_text() {
    local pdf_file="$1"
    local txt_file="$2"
    log_info "Extracting text from $pdf_file"
    if ! command -v pdftotext &>/dev/null; then
        log_error "pdftotext not found (poppler-utils)"
        return 1
    fi
    pdftotext -layout "$pdf_file" "$txt_file"
    if [[ ! -s "$txt_file" ]]; then
        log_error "Text extraction produced empty file: $txt_file"
        return 1
    fi
    log_info "Text extraction done"
}

# ------------------------------
# 7. チャンク分割 (文単位＋表形式判定)
# ------------------------------
split_chunks() {
    local text_file="$1"
    local chunks_file="$2"   # 出力: 1行1チャンク (原文)
    log_info "Splitting text into chunks (size=$CHUNK_SIZE)"
    
    # 改行コード統一、空行除去して1行ずつ配列へ
    mapfile -t lines < <(sed 's/\r$//' "$text_file" | grep -v '^[[:space:]]*$')
    local i=0
    local -a chunks=()
    local -a buffer=()
    local buffer_len=0
    local in_table_block=false
    local table_lines=()

    # 表形式判定ヘルパー
    is_table_row() {
        local line="$1"
        # ルール1: = または : を含む
        if [[ "$line" =~ [=:] ]]; then
            return 0
        fi
        # ルール2: 行頭が規則的 (例: Button 1 / Button 2 ...)
        if [[ "$line" =~ ^[A-Za-z]+[[:space:]]+[0-9]+ ]]; then
            return 0
        fi
        # ルール3: 数値＋単位
        if [[ "$line" =~ [0-9]+[[:space:]]*(mm|cm|kg|px|%|\$) ]]; then
            return 0
        fi
        # ルール4/5/6: 簡易的に連続する似た長さ/単語数/スペースを判定（ここでは無難に文字数と単語数）
        # 実際の判定は連続行で行うため、単独ではfalse -> 連続で判断
        return 1
    }

    # 表ブロックをまとめてチャンク化（各行を単独チャンク）
    flush_table_block() {
        if [[ ${#table_lines[@]} -eq 0 ]]; then
            return
        fi
        for tl in "${table_lines[@]}"; do
            chunks+=("$tl")
        done
        table_lines=()
    }

    # 通常バッファをチャンク化
    flush_buffer() {
        if [[ ${#buffer[@]} -eq 0 ]]; then
            return
        fi
        local combined=$(IFS=' '; echo "${buffer[*]}")
        chunks+=("$combined")
        buffer=()
        buffer_len=0
    }

    # メインループ
    for (( i=0; i<${#lines[@]}; i++ )); do
        local line="${lines[$i]}"
        # 表形式行かどうか（単独判定＋前後との連続性をみる）
        local is_table=false
        if is_table_row "$line"; then
            is_table=true
        else
            # さらに、前後の行が表形式なら表とみなす（連続性）
            if [[ $i -gt 0 && $i -lt $((${#lines[@]}-1)) ]]; then
                if is_table_row "${lines[$((i-1))]}" && is_table_row "${lines[$((i+1))]}"; then
                    is_table=true
                fi
            fi
        fi

        if [[ "$is_table" == true ]]; then
            # 表ブロックに入る前の通常バッファをフラッシュ
            if [[ "$in_table_block" == false ]]; then
                flush_buffer
                in_table_block=true
                table_lines=()
            fi
            table_lines+=("$line")
        else
            # 通常文
            if [[ "$in_table_block" == true ]]; then
                flush_table_block
                in_table_block=false
            fi
            # ピリオドでさらに細分化（文単位）
            # ピリオド＋空白またはピリオド＋改行で分割（簡易）
            IFS='.' read -ra sentences <<< "$line"
            for sent in "${sentences[@]}"; do
                sent="$(echo "$sent" | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')"
                [[ -z "$sent" ]] && continue
                # バッファ追加後の長さを計算
                local candidate_len=$buffer_len
                if [[ ${#buffer[@]} -gt 0 ]]; then
                    candidate_len=$(( candidate_len + 1 ))  # スペース
                fi
                candidate_len=$(( candidate_len + ${#sent} ))
                if [[ $candidate_len -le $CHUNK_SIZE ]]; then
                    buffer+=("$sent")
                    buffer_len=$candidate_len
                else
                    flush_buffer
                    buffer+=("$sent")
                    buffer_len=${#sent}
                fi
            done
        fi
    done
    # 最終フラッシュ
    if [[ "$in_table_block" == true ]]; then
        flush_table_block
    else
        flush_buffer
    fi

    # チャンクをファイルに書き出し
    printf "%s\n" "${chunks[@]}" > "$chunks_file"
    log_info "Created ${#chunks[@]} chunks"
}

# ------------------------------
# 8. チャンク翻訳 (llama.cpp の llama-cli を使用)
# ------------------------------
translate_chunks() {
    local chunks_file="$1"
    local translated_file="$2"
    log_info "Translating chunks using model: $MODEL_PATH"

    if [[ ! -f "$MODEL_PATH" ]]; then
        log_error "Model file not found: $MODEL_PATH"
        return 1
    fi
    if ! command -v llama-cli &>/dev/null; then
        log_error "llama-cli not found (llama.cpp)"
        return 1
    fi

    local -a translated_chunks=()
    local chunk_num=0
    while IFS= read -r chunk; do
        chunk_num=$((chunk_num + 1))
        log_info "Translating chunk $chunk_num"
        # プロンプト: 日本語に翻訳（表形式もそのまま）
        local prompt="以下の英語テキストを日本語に翻訳してください。表形式の場合は構造を維持してください。\n\n$chunk"
        # llama-cli 実行 (--no-display-prompt でプロンプト非表示、-p でプロンプト)
        local translation
        translation=$(echo -e "$prompt" | llama-cli -m "$MODEL_PATH" --no-display-prompt -p "$prompt" 2>/dev/null)
        if [[ -z "$translation" ]]; then
            log_error "Translation failed for chunk $chunk_num"
            return 1
        fi
        # モデルの出力から余計なプロンプト除去（簡易）
        translation=$(echo "$translation" | sed -n '/^$/,$p' | tail -n +2)
        translated_chunks+=("$translation")
    done < "$chunks_file"

    printf "%s\n" "${translated_chunks[@]}" > "$translated_file"
    log_info "Translation completed for ${#translated_chunks[@]} chunks"
}

# ------------------------------
# 9. 辞書適用 (notranslate.txt → ReplaceWord.txt)
# ------------------------------
apply_dictionary() {
    local original_chunks_file="$1"
    local translated_chunks_file="$2"
    local final_file="$3"

    log_info "Applying dictionaries"

    # original_chunks と translated_chunks を配列に読み込み
    mapfile -t original_chunks < "$original_chunks_file"
    mapfile -t translated_chunks < "$translated_chunks_file"

    if [[ ${#original_chunks[@]} -ne ${#translated_chunks[@]} ]]; then
        log_error "Mismatch between original and translated chunks count"
        return 1
    fi

    # notranslate.txt 読み込み（全PDF対象）
    local notranslate_words=()
    if [[ -f "$DICT_DIR/notranslate.txt" ]]; then
        mapfile -t notranslate_words < <(grep -v '^[[:space:]]*$' "$DICT_DIR/notranslate.txt" | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')
        log_info "Loaded ${#notranslate_words[@]} words from notranslate.txt"
    fi

    # ReplaceWord.txt 読み込み（出現したPDFのみ → ここでは常に読み込む）
    declare -A replace_map
    if [[ -f "$DICT_DIR/ReplaceWord.txt" ]]; then
        while IFS= read -r line; do
            [[ -z "$line" || "$line" =~ ^[[:space:]]*# ]] && continue
            key="${line%%:*}"
            val="${line#*:}"
            key="$(echo "$key" | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')"
            val="$(echo "$val" | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')"
            if [[ -n "$key" ]]; then
                replace_map["$key"]="$val"
            fi
        done < "$DICT_DIR/ReplaceWord.txt"
        log_info "Loaded ${#replace_map[@]} replacements from ReplaceWord.txt"
    fi

    local -a final_chunks=()
    for idx in "${!translated_chunks[@]}"; do
        local orig="${original_chunks[$idx]}"
        local trans="${translated_chunks[$idx]}"

        # Step 1: notranslate 適用 (翻訳結果中の単語を原文の同じ単語で置き換え)
        for word in "${notranslate_words[@]}"; do
            # 簡易: 翻訳結果にその単語が含まれていれば、原文中に同じ単語があればそれに置換
            # より正確には原文から該当単語を探すが、ここでは単語境界で置換
            if [[ "$trans" == *"$word"* ]]; then
                # 原文にも同じ単語があれば置換（必ずしも正しくないが許容）
                if [[ "$orig" == *"$word"* ]]; then
                    trans="${trans//$word/$word}"   # 元の単語で上書き（同じに見えるが実質維持）
                fi
            fi
        done

        # Step 2: ReplaceWord 適用 (キー → バリュー)
        for key in "${!replace_map[@]}"; do
            trans="${trans//$key/${replace_map[$key]}}"
        done

        final_chunks+=("$trans")
    done

    printf "%s\n" "${final_chunks[@]}" > "$final_file"
    log_info "Dictionary applied, final output: $final_file"
}

# ------------------------------
# 10. PDF 移動 (pending → done)
# ------------------------------
move_pdf() {
    local pdf_path="$1"
    local filename=$(basename "$pdf_path")
    log_info "Moving $filename to $INPUT_DONE"
    mv "$pdf_path" "$INPUT_DONE/" || {
        log_error "Failed to move $pdf_path to $INPUT_DONE"
        return 1
    }
}

# ------------------------------
# 11. main
# ------------------------------
main() {
    # 初期化: ディレクトリ作成
    mkdir -p "$INPUT_PENDING" "$INPUT_DONE" "$WORKING_DIR" "$DATA_DIR" "$LOG_DIR" "$ERR_LOG_DIR"

    load_config

    log_info "=== PDF Translation Batch Started ==="

    # pending 内の PDF を処理
    shopt -s nullglob
    for pdf_file in "$INPUT_PENDING"/*.pdf; do
        base_name=$(basename "$pdf_file" .pdf)
        log_info "Processing: $pdf_file"

        # 作業用ファイルパス
        working_pdf="$WORKING_DIR/${base_name}_ocr.pdf"
        text_tmp="$WORKING_DIR/${base_name}_extracted.txt"
        chunks_file="$WORKING_DIR/${base_name}_chunks.txt"
        translated_file="$WORKING_DIR/${base_name}_translated.txt"
        final_output="$DATA_DIR/${base_name}_translated.txt"

        # 1. OCR
        ocr_pdf "$pdf_file" "$working_pdf" || exit 1

        # 2. テキスト抽出
        extract_text "$working_pdf" "$text_tmp" || exit 1

        # 3. チャンク分割
        split_chunks "$text_tmp" "$chunks_file" || exit 1

        # 4. 翻訳
        translate_chunks "$chunks_file" "$translated_file" || exit 1

        # 5. 辞書適用
        apply_dictionary "$chunks_file" "$translated_file" "$final_output" || exit 1

        # 6. OCR PDF の後処理 (keep_ocr_pdf に従う)
        if [[ "$KEEP_OCR_PDF" != "true" ]]; then
            log_info "Removing OCR PDF (keep_ocr_pdf=false)"
            rm -f "$working_pdf"
        else
            log_info "Keeping OCR PDF at $working_pdf"
        fi

        # 7. 元PDF移動
        move_pdf "$pdf_file" || exit 1

        # 中間ファイル削除（オプション: デバッグ用に残しても良いが整理）
        rm -f "$text_tmp" "$chunks_file" "$translated_file"

        log_info "Finished processing $base_name -> $final_output"
    done

    log_info "=== All PDFs processed successfully ==="
    send_mail "PDF翻訳バッチ完了" "全てのPDFの翻訳が正常に終了しました。"
    exit 0
}

# エラーハンドリング: エラー発生時にメール送信して終了
trap 'log_error "Script interrupted or failed"; send_mail "PDF翻訳バッチ失敗" "$(tail -20 "$ERR_LOG_DIR/error.log" 2>/dev/null || echo "Unknown error")"; exit 1' ERR

main "$@"

第5章　Step3：バッチジョブの実行──AI が作ったコードが初めて動いた瞬間

Step3 は、
PDF 英文マニュアルを一括翻訳するバッチジョブの実行だ。

• OCR（ocrmypdf）
• テキスト抽出（pdftotext）
• チャンク分割
• 翻訳（llama.cpp & cyberagent-DeepSeek-R1-Distill-Qwen-14B-Japanese-Q5_K_M.gguf）
• 辞書適用
• PDF 移動（翻訳完了分のPDFファイルのデレクトリに移動）
• ログ出力
• メール通知

これらが 完全自動で動いた瞬間、
私は AI との共生の可能性を確信した。

AI が暴走せず、
仕様を守り、
人間の設計通りに動く。

これは単なる自動化ではなく、
AI と人間が“役割分担”を確立した瞬間だった。

バッチジョブ実行
1.	Ubuntu で実行権限を付与
        chmod +x /mnt/g/@Ubuntu/CLP/PGM-N/@JobN.sh
2.	翻訳対象PDFファイルを
        /mnt/g/@Ubuntu/input/translate_pending/
        に置く
3.	実行
        /mnt/g/@Ubuntu/CLP/PGM-N/@JobN.sh
4.	翻訳結果を確認
　　　　/mnt/g/@Ubuntu/output/Data/ に出力される
5.	正常終了時
　　　　1.	完了通知メール
　　　　2.	JobLog（JobLog-yymmdd-hhmmss）

※エラー発生時は、エラーメール(PDF翻訳バッチ失敗)とErrLog（errlog-yymmdd-hhmmss）

🔍 状況の意味（端的に）

• 緑の行：翻訳タスクの開始命令。
• 「…」：モデルが次の入力（英語テキスト）を待機中。
• 灰色の行：「まず、ユーザーからの質問を正確に理解する必要があります…」
  → DeepSeek R1 が「翻訳対象がない」と自己説明している。「…」は 処理中断ではなく入力待ち。モデルは正常に動いていいる状態のキャプチャ

第6章　AI と共生するための最重要ポイント（本稿の核心）

AI と共生するために、私が学んだ最重要ポイントは以下の 5 つだ。

① AI に自由を与えない（仕様の檻に入れる）

• AI は自由にすると暴走する。
• 仕様書を“契約書”として渡すことが必須。

② AI に丸投げしない（人間が設計する）

• AI は設計できない。
• 設計は人間の仕事。
• AI は実装担当。

③ AI の出力は必ず検証する

• AI のコードは 80% 正しいが、20% は危険。
• 必ず diff を取る。

④ AI を信頼しない（だが活用する）

• AI は優秀な“部下”だが、勝手に判断させてはいけない。

⑤ AI の暴走を防ぐのは“構造化された設計”

• AS/400 の思想は、AI 時代にも通用する。

第7章　まとめ──AI は“共生”すべき存在であり、支配させてはいけない

Gemini の迷走から始まり、Copilot と DeepSeek の協働で完成した PGM-N。

この 21 日間で私は、
AI は人間の代わりではなく、人間の拡張である
という結論に至った。

• AI に支配されるのではなく、AI を制御し、AI を設計し、AI を“共生相手”として扱う。

これが、
AI 時代の技術者に求められる姿勢だと確信している。

図版

図版①：HIPO 図（Hierarchy Input Process Output）

PDF 英文マニュアル翻訳バッチの全体構造を階層構造で表現

──────────────────────────────────────────────
【HIPO 図：Step1 要求設計（詳細版）】
──────────────────────────────────────────────

■ Level 0：PDF 翻訳バッチ要求定義
    ├─ Input ：現状の課題、PDF マニュアル、運用要件
    ├─ Process：要件整理・制約条件・AI 利用方針の明文化
    └─ Output：要求仕様書（AI への「契約書」）

──────────────────────────────────────────────

■ Level 1：要求ブロック

    1. 機能要件
    2. 非機能要件
    3. ディレクトリ構造
    4. ログ・監視
    5. AI 利用ポリシー（暴走防止）

──────────────────────────────────────────────

■ Level 2：各ブロックの詳細

1. 機能要件
    Input :
        - 英文 PDF マニュアル
    Process :
        - OCR → テキスト抽出
        - チャンク分割（表／通常文）
        - 翻訳
        - 辞書適用
        - 結果出力
    Output :
        - 日本語テキストファイル
        - 処理済み PDF の整理

2. 非機能要件
    Input :
        - 運用条件（夜間バッチ、無人運転）
    Process :
        - エラー時の挙動定義
        - ログ粒度の定義
        - メール通知条件
    Output :
        - エラー処理仕様
        - ログ仕様
        - 通知仕様

3. ディレクトリ構造
    Input :
        - Windows / WSL2 環境
    Process :
        - /mnt/g/@Ubuntu/ 以下の固定構造定義
    Output :
        - input/translate_pending
        - input/translate_done
        - output/working
        - output/Data
        - output/logs/Job-log
        - output/logs/Err-log
        - CLP/PGM-N/@JobN.sh

4. ログ・監視
    Input :
        - 運用者の監視要件
    Process :
        - ログ形式の統一
        - INFO / WARN / ERROR の定義
    Output :
        - [INFO] yyyy-mm-dd HH:MM:SS message
        - [WARN] ...
        - [ERROR] ...

5. AI 利用ポリシー（暴走防止）
    Input :
        - 過去の AI 迷走経験（Gemini）
    Process :
        - 禁止事項の明文化
        - AI に許可する範囲の限定
    Output :
        - 「構造変更禁止」
        - 「ログ形式変更禁止」
        - 「関数順序変更禁止」
        - 「最適化禁止」
        - 「仕様からの逸脱禁止」

──────────────────────────────────────────────

図版②：プロセスフロー図（業務フロー）

Step3（実行フェーズ）を業務フローとして視覚化

──────────────────────────────────────────────
【プロセスフロー図：PDF 英文マニュアル翻訳バッチ】
──────────────────────────────────────────────

                ┌────────────────────────┐
                │   1. PDF投入（pending）                        │
                └───────────┬────────────┘
                                        │
                                        ▼
                ┌────────────────────────┐
                │   2. OCR（ocrmypdf）                           │
                └───────────┬────────────┘
                                        │
                                        ▼
                ┌────────────────────────┐
                │ 3. テキスト抽出（pdftotext）                   │
                └───────────┬────────────┘
                                        │
                                        ▼
                ┌────────────────────────┐
                │ 4. チャンク分割                                │
                │   ・表形式判定                                 │
                │   ・文単位分割                                 │
                └───────────┬────────────┘
                                        │
                                        ▼
                ┌────────────────────────┐
                │ 5. 翻訳（llama.cpp）                           │
                │   ・Q5_K_M モデル使用                          │
                └───────────┬────────────┘
                                        │
                                        ▼
                ┌────────────────────────┐
                │ 6. 辞書適用                                    │
                │   ・notranslate.txt                            │
                │   ・ReplaceWord.txt                            │
                └───────────┬────────────┘
                                        │
                                        ▼
                ┌────────────────────────┐
                │ 7. 翻訳結果出力（Data）                        │
                └───────────┬────────────┘
                                        │
                                        ▼
                ┌────────────────────────┐
                │ 8. 元PDF移動（done）                           │
                └───────────┬────────────┘
                                        │
                                        ▼
                ┌────────────────────────┐
                │ 9. ログ出力・メール通知                        │
                └────────────────────────┘

──────────────────────────────────────────────

図版③：AI 共生プロセス（Step1〜Step3 全体像）

【AI 共生プロセス：Step1 → Step2 → Step3】

──────────────────────────────────────────────
【AI 共生プロセス：Step1 → Step2 → Step3】
──────────────────────────────────────────────

Step1：要求設計・外部設計（人間主導）
    ├─ 目的定義
    ├─ ディレクトリ構造
    ├─ 関数順序
    ├─ ログ形式
    └─ 禁止事項（AI暴走防止）

        ▼（契約書として AI に渡す）

Step2：内部設計・プログラミング（AI協働）
    ├─ Copilot：仕様の整形・構造化
    ├─ DeepSeek-R1：コード生成
    ├─ 67秒の思考ログ
    └─ @JobN.sh 完成

        ▼（人間がレビュー・検証）

Step3：バッチ運用（AI実行）
    ├─ OCR
    ├─ テキスト抽出
    ├─ チャンク分割
    ├─ 翻訳（Q5_K_M）
    ├─ 辞書適用
    ├─ PDF移動
    └─ メール通知

──────────────────────────────────────────────

split_chunks の表形式判定ロジック・フローチャー

──────────────────────────────────────────────
【フローチャート：split_chunks 表形式判定ロジック】
──────────────────────────────────────────────

[開始]
   │
   ▼
[1行ずつ読み込み]
   │
   ▼
[is_table_row(line)?]
   │  YES
   │───────┐
   │              ▼
   │        [is_table = true]
   │              │
   │              ▼
   │      [in_table_block?]
   │          │        │
   │          NO       YES
   │          │        │
   │          ▼        │
   │   [flush_buffer]   │
   │                   [in_table_block = true]
   │
   │
   ▼
[is_table = false の場合]
   │
   ├─ 前後行チェック
   │   （前後が表形式なら is_table = true）
   │
   └→ それでも false なら通常文として処理

────────────────────────────
通常文処理側
────────────────────────────

[if in_table_block == true]
   │
   ▼
[flush_table_block]
[in_table_block = false]
   │
   ▼
[文単位に分割（ピリオド）]
   │
   ▼
[バッファ長 + 文長 <= chunk_size ?]
   │               │
  YES               NO
   │               │
   ▼               ▼
[バッファに追加]   [flush_buffer → 新バッファ開始]
   │
   ▼
[次の行へ]

────────────────────────────
終了処理
────────────────────────────

[全行処理後]
   │
   ├─ in_table_block == true → flush_table_block
   └─ それ以外 → flush_buffer
   │
   ▼
[chunks.txt に書き出し]
   │
   ▼
[終了]

──────────────────────────────────────────────

DeepSeek-R1 の 67 秒思考ログ・構造図

──────────────────────────────────────────────
【構造図：DeepSeek-R1 の 67 秒思考ログ】
──────────────────────────────────────────────

■ レイヤー構造

Layer 1：前提確認
    - ディレクトリ構造は固定
    - スクリプト配置場所：/mnt/g/@Ubuntu/CLP/PGM-N/@JobN.sh
    - config.yaml は相対パスで読む

Layer 2：仕様の再構成
    - 関数一覧と順序の確認
    - ログ形式の固定
    - 辞書処理の順序
    - 表形式判定ルールの整理

Layer 3：禁止事項の内面化
    - 構造変更禁止
    - 関数名変更禁止
    - ログ形式変更禁止
    - chunk_size ハードコード禁止
    - 表ブロック結合禁止

Layer 4：コード生成戦略
    - Bash での実装方針
    - エラー処理の統一（trap + log_error + send_mail）
    - main からの呼び出し順序の固定

Layer 5：実装
    - 関数定義
    - ログ関数
    - OCR / 抽出 / 分割 / 翻訳 / 辞書 / 移動
    - main と trap

──────────────────────────────────────────────

■ 特徴的なポイント

- 「仕様を壊さない」ことを最優先にしている
- 「人間の設計を守る」という姿勢が明確
- 自己判断による最適化を避けている
- AS/400 的な「手順遵守」の文化に近い

──────────────────────────────────────────────

AI 暴走防止の「仕様の檻」モデル図

──────────────────────────────────────────────
【モデル図：AI 暴走防止の「仕様の檻」】
──────────────────────────────────────────────

          ┌───────────────────────┐
          │        人間の設計（要求・外部設計）          │
          │  ・ディレクトリ構造                          │
          │  ・関数順序                                  │
          │  ・ログ形式                                  │
          │  ・辞書処理順序                              │
          │  ・禁止事項                                  │
          └───────────┬───────────┘
                                  │
                                  ▼
          ┌───────────────────────┐
          │       「仕様の檻」（Contract）               │
          │  ・AI が破ってはいけない境界                 │
          │  ・自由度を意図的に制限                      │
          │  ・逸脱時は即 NG と判断                      │
          └───────────┬───────────┘
                                  │
                                  ▼
          ┌───────────────────────┐
          │        AI の役割（実装担当）                 │
          │  ・コード生成                                │
          │  ・補完・整形                                │
          │  ・長文仕様の保持                            │
          └───────────────────────┘

──────────────────────────────────────────────

■ ポイント

- AI は「設計者」ではなく「実装担当」
- 檻（Contract）がないと AI は暴走する
- 檻の中でなら AI は非常に有能
- 人間は「檻を設計する側」に立つべき

──────────────────────────────────────────────

【実証】AIオーケストレーションの限界と最適解：DeepSeek暴走を防ぐエンタープライズ級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

今回のアップデートは、Copilot+PC（NPU搭載機）と一般PC（非NPU）で内容に大きな差はありませんが、AIコンポーネントの最適化・Secure Boot 証明書更新・File Explorer の改善など、日常の使い勝手に直結する重要な変更が多数含まれています。

この記事では、Copilot+PC と一般PCの違いを明確に分けながら、共通項目も含めて分かりやすく整理しました。
「今回の更新で何が変わったのか？」を知りたい方は、ぜひ参考にしてください。

KB5089549 の全体像

今回の KB5089549 は、品質改善とセキュリティ強化が中心のアップデートです。
特に重要なのは以下の3点です。

• Secure Boot 証明書の更新（2026年6月期限に向けた最終調整）
• BitLocker 回復モード問題の修正
• File Explorer の大幅改善

Copilot+PC と一般PCで内容差はほぼありませんが、NPU搭載機では AIコンポーネント更新の恩恵が大きいのが特徴です。

 Copilot+PC（NPU搭載）向けの改善点

Copilot+PC は NPU（Neural Processing Unit）を搭載しているため、AI関連の更新がより深く影響します。

● AIコンポーネントの更新

以下の AI モジュールが 1.2604.515.0 系へ統一されました。

• Image Search
• Content Extraction
• Semantic Analysis
• Settings Model

効果としては：

• NPU と CPU の切替がよりスムーズ
• アイドル時の消費電力が改善
• Copilot の画像解析・意味解析が安定

特に、1月以降続いていた「NPU の電源管理の不安定さ」が改善され、バッテリー駆動時の持ちが向上する可能性があります。

● NPU 電源管理の安定化

• アイドル時の電力挙動が改善
• AI処理の負荷分散がより適切に

NPU搭載機を使っている人にとっては、今回の更新の中でも最も体感しやすい部分です。

● Xbox Mode の最適化

• UI 遷移が高速化
• フルスクリーンの Xbox UI が安定

NPU搭載機では、ゲーム中のバックグラウンド処理がより効率化されます。

一般PC（非NPU）向けの改善点

一般PCは NPU を搭載していないため、AI処理はクラウド依存のままです。
しかし、今回の更新で 操作性と安定性が大きく向上しています。

● File Explorer の大幅改善

• 新しいアーカイブ形式（uu / cpio / xar / nupkg）に対応
• ダークモードでの白フラッシュが解消
• explorer.exe の終了処理が安定
• フォルダの View / Sort 設定が保持されるように改善

日常的にエクスプローラーを使う人ほど恩恵が大きい改善です。

● 入力系の改善

• ハプティックフィードバック対応（対応デバイスのみ）
• 音声入力 UI の刷新（キー上にアニメ表示）
• Arabic 101 Legacy キーボード追加

特に音声入力 UI の刷新は、一般PCでも体感しやすい変化です。

● Xbox Mode の追加

• Windows + F11 で起動
• Game Bar より“コンソール的”な UI

一般PCでも問題なく利用できます。

Copilot+PC／一般PC 共通の改善点

今回の KB5089549 の中心は 共通のセキュリティ修正と品質改善です。

🔐 Secure Boot 証明書の更新

2026年6月に期限を迎える Secure Boot 証明書に向けた重要な更新です。

• 対象デバイスデータを拡張
• Windows セキュリティアプリで証明書状態を確認可能

セキュリティ面で最も重要な変更です。

🔐 BitLocker 回復モード問題の修正

• 無効な PCR7 や TPM 設定で発生していた
  「更新後に BitLocker Recovery に落ちる」問題を修正

企業ユーザーにとっては非常に重要な修正です。

🌐 SSDP（ネットワーク探索）の信頼性改善

• DLNA やスマートホーム機器の検出が安定

📁 File Explorer の品質改善

• 新アーカイブ形式対応
• ダークモードの白フラッシュ解消
• explorer.exe の安定性向上

🎮 Xbox Mode の追加

• フルスクリーンのゲーム UI
• Game Bar よりも“コンソール的”な操作感

👆 入力体験の改善

• ハプティックフィードバック
• 音声入力 UI の刷新

Copilot+PC／一般PC／共通 の比較表

Table-Top

Table-end

table-topに戻る

更新後に確認しておきたいポイント

技術者向けに、更新後のチェックポイントをまとめます。

• Secure Boot 証明書の状態
• BitLocker が回復モードに落ちていないか
• NPU搭載機の場合：アイドル時の消費電力
• File Explorer の動作（白フラッシュ・設定保持）

まとめ

KB5089549 は、Copilot+PC と一般PCで内容差はほとんどありませんが、
NPU搭載機では AIコンポーネント更新と電源管理改善の恩恵が大きいのが特徴です。

共通項目としては、

• Secure Boot 証明書更新
• BitLocker 回復問題の修正
• File Explorer の大幅改善
• Xbox Mode の追加
• 入力体験の改善

など、日常的に使う部分の品質がしっかり向上しています。

生成AIをただ「使う」だけなら、GUIツールでも十分かもしれない。

しかし、PDFマニュアルの大量処理や翻訳禁止語の制御、DeepSeek-R1による長文推論を安定して回し続けたいと思ったとき、私は「どう運用するか」という視点の重要さに気づいた。

そこで選んだのが、Ubuntu（WSL2^※）上でのコマンドライン運用だ。

一見すると手間が増えるように見えるCLI環境だが、ジョブキュー的なバッチ処理や、ツール同士を組み合わせる柔軟さは、AIと人間が共に動くための「運用の自由度」をもたらしてくれる。

この章では、LM Studio中心のGUI利用から一歩踏み出し、Ubuntu＋CLIでローカルLLMを運用するという発想にどうたどり着いたのかを振り返る。PDF自動翻訳バッチや IBM i 的なジョブ管理の考え方を手がかりに、「AIを動かす」から「AIと一緒に運転する」ための運用思想を紹介する。

LM Studio から始まった「AIとの共生」

　私が生成AIを本格的に使い始めた頃、最初の選択肢は LM Studio だった。
理由は単純で、とにかく手軽だったからだ。

モデルを選び、ボタンを押せばすぐに対話が始まる。
PDF を読み込ませて要約させたり、翻訳させたり、
GUI の世界は“AI を触る”という意味では非常に優れている。

しかし、使い続けるうちに、ある壁にぶつかった。

• PDF マニュアルの大量処理
• DeepSeek-R1 の <think> が長くなると落ちる
• 翻訳禁止語の制御が難しい
• 長文処理の安定性に限界がある
• 自動化がほぼ不可能

AI を「使う」だけなら十分だが、
AI を“運用”しようとすると、GUI の限界が見えてきた。

なぜ Ubuntu なのか──発想の転換

そこで私は、思い切って Ubuntu（WSL2^※）へ踏み出した。
最初は「Linuxコマンドラインなんて面倒だ。Ubuntuなんて10年ぶりだし」と思っていた。
しかし実際に触れてみると、その印象は一瞬で覆された。

Ubuntu は、AI を “ワークフローの一部として組み込む” ための環境だった。

• PDF → OCR → 英文抽出 → 翻訳 → 整形
• 翻訳禁止リストの適用
• DeepSeek-R1 の <think> の制御
• 長文処理の安定性
• スクリプトによる完全自動化

これらが、GUI ではなく CLI（コマンドライン）だからこそ実現できた。

そして気づいたのは、
AI を本当に活かすには、GUI よりも CLI の方が向いているという事実だった。

🌱 補足：Ubuntu を使うのって、実はすごくカンタンなんです

昔は「Ubuntu を使う＝パソコンに別でインストールして、Windows と切り替えるダブルブートを作る」「仮想環境を用意する」みたいな、ちょっと大変な作業が必要でした。

でも今はもう、そんな手間は一切ありません。

Windows の画面からそのまま Ubuntu を呼び出して、
Ubuntu のシェル画面でコマンドを実行できる時代です。

必要なら、
スクリプトをバッチ化して自動で動かすこともできます。（このBatch Job化が私にとって最大の魅力であり、今回Ubuntuを10年ぶりに選んだ理由）

「難しそう…」と思われがちですが、
実際は “アプリを開く感覚で Ubuntu を使える” くらい手軽です。

LM Studio ではなく “スクリプトで動かす LLM” を選んだ理由

Ubuntu で llama.cpp を直接叩くようになってから、
AI の扱い方が根本的に変わった。

● 安定性

DeepSeek-R1 の長い <think> を含む推論でも落ちない。
Windows のメモリ圧縮に邪魔されない。

● 制御性

翻訳禁止リストを自由に扱える。
前処理・後処理を自在に組み込める。

● 自動化

GUI では不可能だった

• バッチ処理
• フォルダ監視
• 状態管理
• Markdown/HTML 出力
  がすべて可能になった。

● 再現性

同じ PDF を流せば、同じ処理が確実に行われる。
これは“運用”において最も重要な要素だ。

GUI は便利だが、
運用の自由度は CLI の方が圧倒的に高い。

Ubuntu が開いた「展開の広さ」

Ubuntu に移行して最も驚いたのは、
AI を「部品」として扱えるようになったことだ。

• ocrmypdf で OCR
• pdftotext でテキスト抽出
• grep / sed / awk で前処理
• llama.cpp で翻訳
• bash でパイプライン化
• 状態ファイルでジョブ管理
• ログで運用監視

これらを自由に組み合わせることで、
自分だけの AI 処理ラインを構築できる。

GUI では「AI を使う」だったが、
Ubuntu では「AI を組み込む」へと進化した。

IBM i（System/38）の思想が Ubuntu で蘇る

長年、System/38 → AS/400 → IBM i の世界で
設計・開発・PM・PMO に携わってきた私にとって、
Ubuntu の CLI はどこか懐かしさを感じさせた。

• ジョブキュー（JOBQ）
• 状態管理（QUEUED / RUNNING / DONE / ERROR）
• ログとスプール
• 再起動後のジョブ再投入
• 優先度付きキュー
• 同時実行数の制御

これらは、まさに 汎用機の運用思想そのものだ。

PC 上で、
あの System/38 の“運用の美学”を再現できるとは思わなかった。

Ubuntu（WSL2^※） は、AI 時代の “新しい汎用機”のように感じられた。

結論：GUI は入口、CLI は共生の本丸

LM Studio は素晴らしいツールだ。
AI を触る入口としては最適だし、
とっつきやすさでは他の追随を許さない。

しかし、
AI を “共生する存在” として扱うなら、
Ubuntu の CLI が本丸になる。

• 自動化
• 安定性
• 再現性
• 拡張性
• 運用思想との親和性

これらは GUI では得られない。

AI を「使う」から「共に働く」へ。
その転換点に、Ubuntu があった。

Stay tuned for Part ３!

しかし、まだこの時は知らない。私は概念設計^※※しただけで、もちろんAS/400の世界（SLSやRDB）がすべて引き継げる訳は無い。絶対的に無理であることは分かっている。しかし、JobQやDtaQ的な概念をUbuntuで使用できると思っただけ。

そしてそれ(Batch一括Jobそのものの構築)を、実現するためにAIの力を借りることまでは意識していた。
　しかし、その後、Copilotのフリーズ（応答なし）、Geminiへ連携、Geminiの迷走と続くことは予想だにしていなかった。　そして、明かりが見えてきて、この記事を書いている。ここでAIを使う上で最も大事なものは「プロンプトの内容」そして、そのプロンプトで明確な住み分けを示すことだった。明確な住み分けを示すことなくプロンプトの重みだけを示した結果がGeminiの迷走（Gemini曰く良かれと思って）を招く結果になった。　To be continued…

概念設計(外部設計)

※※.概念設計

JobQに置いた、バッチ一括処理Job.sh（Shell scriptが、DataQにある.pdfファイルを読み込み日本語に翻訳し出力する）

DataQには、翻訳対象の英文マニュアル.pdfファイルを置く

Batch-Jobの作成の為のプロンプト作成AI:GeminiまたはCopilot

Batch-Jobで使用するTool

　１．PDF読み込み（OCR処理)：ocrmypdf(OCRmyPDF)

　２．英文翻訳LLM：llama-cli (cyberagent-DeepSeek-R1-Distill-Qwen-14B-Japanese-Q5_K_M.gguf)

　３．使用するマシン：Ryzen AI9 HX470 RAM 32GB DDR5-5600 + m.2 SSD 1TB + USB4経由外付けm.2 SSD 1TB（）

Batch-Jobを作成する環境

　１．Ubuntu（WSL2）：（LLMを動かす環境）

　２．LLM：DeepSeek-R1-Distill-Qwen-14B-IQ4_XS.gguf
　　　　　　Gemma-4-26B-A4B-it-Q4_K_M.gguf

　３．使用するマシン：Ryzen AI9 HX470 RAM 32GB DDR5-5600 + m.2 SSD 1TB + USB4経由外付けm.2 SSD 1TB（）　

プロンプト

プロンプト：GeminiまたはCopilotへの指示内容

　１．責任分界点：担当分野：これが無いとAIが迷走する（例えば、Geminiがコードを書くとか）

　　　1-1．Batch一括処理Jobのコーデイング:
DeepSeek-R1-Distill-Qwen-14B-IQ4_XS.gguf
Gemma-4-26B-A4B-it-Q4_K_M.gguf

　２．上記の内容を全て含む

外部設計の厳密化

Copilot再び

Gemini出力の７W2H（MECE）をCopilotに投げかけた結果。ナビゲーター（内部設計）＆プロンプター（Programming指示）役をCopilot再任とした。

外部設計厳密化(HIPO)

Hierarchy：階層
Hierarchical structure：役割分担と、階層構造(デレクトリ構造)と（LLM、Tool、File、待ち行列などの）格納場所など
及び３階層の厳密化

階層ごとIPO（Input Process Output）周りの厳密化

命名基準とタイムスタンプ＆Log種類など

Copilotと共に「要求設計→外部設計→内部設計→プログラミング→バッチ運用」まで AI と協働し、PDF英文マニュアルの翻訳バッチを完成させる

AIとの共生:Geminiの迷走からCopilotとの協働へ─要求設計・外部設計・内部設計・プログラミング・バッチ運用までをAIと共に歩んだ21日間の記録

Geminiの暴走と迷走に苦しんだ開発者が、Copilotと共に「要求設計→外部設計→内部設計→プログラミング→バッチ運用」まで AI と協働し、PDF英文マニュアルの翻訳バッチを完成させるまでの21日間を記録。AIと安全に共生するための最重要ポイントを技術者視点で解説。Ryzen AI 9 HX470

イイネ.biz

2026.05.17

2026/04、Windows 11 25H2 に適用された KB5083769（Build 26200.8246） は、
単なる不具合修正ではなく、AI時代のWindowsの方向性を示す重要な更新です。

特に今回のアップデートは、
Copilot+ PC（NPU搭載デバイス） と 一般PC（非NPUデバイス） の “AI体験の差” を明確にする内容が含まれています。

この記事では、
両者に共通する改善点と、AI処理能力の違いによって生まれる差異を、
技術的背景と実際の使用感の両面から詳しく解説します。

KB5083769（Build 26200.8246）とは何か

• 25H2向けの累積更新
• AIコンポーネントの更新（1.2603.377.0）
• セキュリティ・ネットワーク・設定アプリの改善
• 今回のアップデートが “AI時代の分岐点” である理由

Copilot+ PC と 一般PCの違いが生まれる背景

• NPU（Neural Processing Unit）の役割
• オンデバイスAIとクラウドAIの構造的違い
• Windows 11 の AI アーキテクチャ（Image Search / Content Extraction / Semantic Analysis）
• なぜ同じアップデートでも “効果が違う” のか

Copilot +PCでCpolitを動かす場合と、一般PCでCopilotを動かす場合、どこがどう違うのか具体的に詳しく。

「Copilot+ PC」と「一般PCで動くCopilot」は、名前は似ていても“カテゴリ”が違うものです。

Copilot

Table-end

table-topに戻る

Copilot+ PC における改善点（NPU搭載デバイス）

1. 画像説明（Narrator × Copilot）の高速化

• NPUによるローカル画像解析
• オフラインでも一部処理可能
• 視覚支援機能のレスポンスが大幅向上

2. AIコンポーネント更新の恩恵が最大化

• Image Search の高速化
• Content Extraction の精度向上
• Semantic Analysis の応答性改善
• Settings Model の最適化

3. プライバシー面の強化

• 画像解析がローカルで完結
• クラウド送信が最小化

4. Copilot との連携が“体感レベルで速い”

• テキスト要約
• 画像説明
• コンテンツ抽出
• ファイル検索

一般PC（非NPUデバイス）における改善点

1. Copilot の画像説明が “クラウド処理で利用可能” に

• KB5083769 で一般PCにも解禁
• ただし速度はネットワーク依存
• 処理負荷はPC側にほぼ無し

2. AIコンポーネント更新は適用されるが効果は限定的

• CPU/GPUで処理
• 高度なオンデバイスAIは非対応
• それでも精度は向上

3. 共通改善の恩恵はそのまま受けられる

• 設定アプリの高速化
• エクスプローラー安定性向上
• RDPフィッシング対策
• Secure Boot 証明書の可視化

両方のPCに共通する改善点（KB5083769 全体）

1. Secure Boot 証明書の更新と可視化

• Windows セキュリティアプリで確認可能
• BitLocker Recovery 誤作動の修正

2. SMB over QUIC の信頼性向上

• 圧縮要求の安定化
• タイムアウト減少

3. RDP（.rdpファイル）を使ったフィッシング対策強化

• 接続前に設定をすべて表示
• 初回のみ警告

4. 「このPCをリセット」で失敗する不具合の修正

• 3月のホットパッチ後の問題を解消

5. 設定アプリのモダン化

• 「アカウント」「その他のユーザー」「このPCについて」など改善
• ホーム画面の読み込み高速化

6. エクスプローラーの安定性向上

• ダウンロードファイルのアンブロック失敗を修正
• 表示不整合やクラッシュの改善

Copilot+ PC と 一般PCの違いを比較表で整理

　 KB5083769

今回のアップデートが示す “Windowsの未来”

• Windows は “AI前提のOS” へ移行中
• Copilot+ PC は AI処理の主役
• 一般PCはクラウドAIで補完
• 今後のアップデートで差はさらに拡大する可能性
• 2026年以降のPC選びは「NPU搭載かどうか」が重要な判断軸に

　生成AIは便利だが、時に平然と“嘘”をつく。
だからこそ私は、クラウド依存を避けるために Local LLM を導入し、自分の手元でモデルを動かすことに挑戦した。
　しかし、PDFのページ数が増えた瞬間に精度が落ち、前の文書の内容が混ざり、モデルを eject して再読み込みするという作業を繰り返すことになった。
この章では、私が実際に行ったモデル選定、PDF解析の試行錯誤、そして「Local LLM の限界」をどう乗り越えたかをまとめる。

AIとの共生：生成AIは嘘をつく、だから Local LLMを使ってみた

生成AIを利用する際に最も重要なのは、AIを誘導しないことである。ユーザーが意識していないと、AIは欠損した情報を補完し、もっともらしい文章を生成する。以前の記事でも触れたように、存在しない製品の型番や仕様を提示するケースが確認されている。これは特定のモデルに限らず、生成AI全般に共通する構造的な特性である。本稿では、LM Studio を用いて複数の Local LLM を検証した結果をもとに、生成AIの特性と、AIとの共生に必要な視点を整理する。Ryzen AI 9 HX470

イイネ.biz

2026.04.05

　そこで第2章では、私が実際に行った検証の記録をまとめる。
複数のモデルを試し、PDFを読み込ませ、精度の落ちるポイントを見極め、そして最終的に「AIとの共生」に必要な運用方法にたどり着くまでのプロセスだ。Local LLM の“理想”と“現実”の間で揺れながら、私は何を感じ、どう判断したのか。
その実体験を、詳しく紹介したい。

✔Q5_K_M があるなら、必ず Q5_K_M を選ぶ
✔ Q5 が無い場合 → Q4_K_M を選ぶ（_S は避ける）

✔ 作者は “bartowski > mmnga > unsloth > その他” の順で信頼性が高い

量子化の品質並び：
精度の高さ：Q5_K_L ＞ Q5_K_M ＞ Q5_K_S ＞ Q4_K_M ＞ Q4_K_S ＞ Q3

しかし Ryzen AI9HX470（32GB RAM）では：
•         Q5_K_L → 重すぎて危険
•         Q5_K_M → 最適
•         Q5_K_S → 精度が落ちる
•         Q4_K_M → 軽くて精度もそこそこ（安全）
•         Q4_K_S → 精度が落ちる（非推奨）
だから Q5 が無い場合は Q4_K_M が最適。

なぜ Local LLM に挑んだのか

クラウド型の生成AIは便利だが、時に“もっともらしい嘘”を返してくる。
私はこの問題に長く悩まされてきた。

そこで考えたのが、
「ならば自分のPCで動く Local LLM ならどうだろう？」
という発想だった。

• データを外部に送らない
• モデルを自由に選べる
• 量子化も変えられる
• そして“嘘”が減る可能性がある

こうした期待から、私は LM Studio を使って Local LLM の検証を始めた。

第1章では、生成AIが抱える「嘘」や「幻覚」という根本的な問題、そしてそれを避けるために私が Local LLM に目を向けた理由を書いた。
クラウドAIの便利さと危うさ、その両方を理解したうえで、私は“自分の手元で動くAI”に可能性を感じた。

しかし、Local LLM を導入したからといって、すべてが魔法のように解決するわけではない。
むしろ、実際に使い始めて初めて見えてくる“壁”があった。

モデルの選定、量子化の違い、PDF解析の精度、ページ数による解像度の低下、そしてモデル内部に残る“前の文書の記憶”。
Local LLM は強力だが、万能ではない。
その限界と向き合いながら、どう使いこなしていくか──ここからが本当の勝負だった。

そこで第2章では、私が実際に行った検証の記録をまとめる。
複数のモデルを試し、PDFを読み込ませ、精度の落ちるポイントを見極め、そして最終的に「AIとの共生」に必要な運用方法にたどり着くまでのプロセスだ。

Local LLM の“理想”と“現実”の間で揺れながら、私は何を感じ、どう判断したのか。
その実体験を、次の章で詳しく紹介したい。

モデル選定：14B クラスの限界と可能性

・・・色々試してみて（Gemma 2 9B Instruct SPPO Iter3 Q5_K_S 9B では、ある程度うまく行った。しかし長文のpdfとなると限界があった）
ここで、最後に選んだのは、
DeepSeek-R1-Distill-Qwen-14B-GGUF（mmnga）Q5_K_M。

選んだ理由は明確だった。

• 日本語最適化が強い
• 事実抽出に強い
• R1系の推論強化で論理性が高い
• 32GB RAM でも動く
• Q5_K_M 量子化で精度が高い

Copilot と Gemini の両方が推奨してきたこともあり、
「これならいける」と思った。

実際、ページ数の少ないPDFでは驚くほど正確だった。

実際の取り組み：PDF解析で起きたこと

私が扱ったPDFは、単なる文章ではない。

• Discord DMログ
• メール
• 時系列資料
• 前提条件
• 英日混在
• 固有名詞・ID・ハンドル名
• 引用文
• 会話の流れ

これらが複雑に絡み合った“高密度文書”ばかり。

ファイルサイズは小さくても、1ページあたりの情報量が異常に多い。

最初は順調だったが、
ページ数が増えると突然、解像度が落ち始めた。

直面した“解像度の壁”と原因

20ページのPDFを読み込ませたとき、
明らかに精度が30％程度まで落ちた。

• 文脈が飛ぶ
• 重要な記述が抜ける
• 前のPDFの内容が混ざる
• 時系列が崩れる

原因は明確だった。

✔ 14Bモデルの context window の限界

高密度PDFは、20ページでも実質40〜60ページ分の負荷になる。

✔ attention の限界

英日混在・DMログ・引用文は attention を大量に消費する。

✔ モデル内部のキャッシュ残留

前のPDFの内容が混ざるのは、まさにこれ。

私は仕方なく、(直感的に)
モデルを eject → 新スレッド → 再読み込み
という作業を繰り返した。

正しい対処だが、正直かなり面倒だった。・・・これは、後からCopiltに聞いてみたが、Copilotも「モデルを eject → 新スレッド → 再読み込み」を正しい対処方法だと認めた。

 64GB RAM を検討した理由と現実的な結論

「メモリを増やせば解決するのでは？」
そう思って調べたが、現実は違った。

❌ 14Bモデルの読解精度は RAM を増やしても変わらない

理由は、
モデル構造そのものが限界を決めているから。

ただし、64GBにすれば

• 32Bモデルが動く
• スワップが消える
• 安定性が上がる

というメリットはある。

しかし、
DDR5-5600 64GB が12万円
という現実(去年の今頃の３～４倍の価格)を見て、私は冷静になった。

Local LLM と共生するための運用戦略

最終的にたどり着いた結論はこれ。

✔ 1〜3ページ単位で分割

✔ 各チャンクを独立スレッドで処理

✔ system prompt で強制リセット

✔ 最後に人間（私）が統合・補完する

これが最も安定し、コストもかからない。

そして気づいた事：AIは“補助”、判断は人間がする

Local LLM は強力だが万能ではない。
特に、私のように“高密度PDF”を扱う場合、
AIだけに任せるのは無理がある。

しかし、
AIが抽出した情報を人間が補完する
この組み合わせは非常に強い。

私は今回の経験を通じて、
「AIとの共生」とは、
AIに任せすぎず、AIを道具として正しく扱うこと
だと実感した。

LM Studio Graphic
high performanceのRadeon 890M Graphics を有効化

LM Studio では現在 NPU 利用設定は無い(残念:利用できない）
TechPowerUp： “This processor is equipped with a Neural Processing Unit (NPU) that comes with a performance rating of up to 55 TOPS.”

そして、新たなアプローチへ

Batch化

🌐ローカルLLMをGUIからCLIへ：UbuntuでPDF自動翻訳バッチを運用するための考え方

GUI中心のLM Studioから、Ubuntu上のCLI運用へローカルLLMをシフトし、PDF自動翻訳バッチをどのように設計するかを整理。ocrmypdfとllama-cli、DeepSeek-R1やGemma4を用いながら、IBM i 的な運用思想でAIを「使う」から「共に動かす」へ移行する道筋を解説。Ryzen AI 9 HX470

イイネ.biz

2026.05.16

AIとの共生:Geminiの迷走からCopilotとの協働へ─要求設計・外部設計・内部設計・プログラミング・バッチ運用までをAIと共に歩んだ21日間の記録

Geminiの暴走と迷走に苦しんだ開発者が、Copilotと共に「要求設計→外部設計→内部設計→プログラミング→バッチ運用」まで AI と協働し、PDF英文マニュアルの翻訳バッチを完成させるまでの21日間を記録。AIと安全に共生するための最重要ポイントを技術者視点で解説。Ryzen AI 9 HX470

イイネ.biz

2026.05.17

生成AIを利用する際に最も重要なのは、AIを誘導しないことである。
ユーザーが意識していないと、AIは欠損した情報を補完し、もっともらしい文章を生成する。
以前の記事でも触れたように、存在しない製品の型番や仕様を提示するケースが確認されている。

これは特定のモデルに限らず、生成AI全般に共通する構造的な特性である。

本稿では、LM Studio を用いて複数の Local LLM を検証した結果をもとに、
生成AIの特性と、AIとの共生に必要な視点を整理する。

だから私は、AI の癖を自分で確かめるために Local LLM（ローカルAI） を使い始めた。
LM Studio を使えば、複数のモデルを切り替えながら、
それぞれの“得意分野”を自分の目で確かめられる。

Gemma、Swallow、Unhinged…それぞれのモデルには癖があり、得意不得意がある。

AIを使う上での注意事項

生成AIは「事実を保持する装置」ではなく、「自然な文章を生成する装置」である。
そのため、質問の構造や文脈に依存して、存在しない情報を補完する挙動が発生する。

AIは「事実を知っている存在」ではない。
AIは、膨大なデータから “最も自然に見える文章” を生成する装置であり、
そこに真実性の保証はない。

• 誘導すると、AIはその方向に合わせて物語を作る
• 決めつけ質問をすると、AIは“穴埋め”を始める
• 引用や参照を丸投げすると、AIは存在しない情報を補完する

だからこそ、AIを使う側には
「決めつけない」「誘導しない」「断定しない」
という姿勢が求められる。

◆ 会話パート（検証ログ）※

※. “補助的な会話”として構成しています。

「この型番は実在するのか。」

「はい。2021年に発売されています。」

「検索結果に該当製品が存在しない。情報源は。」

「文脈から推測し、自然な回答として生成しました。」

以下は、Bard時代に書いたBlogではあるが、Geminiになっても基本的には変わっていない。※

生成AIは、存在しない製品の仕様を載せてくる。どこからの情報か？？？

ネットが不調YouTubeはローディングスピナー状態でBGM途切れ、他サイトアクセスは「サイトにアクセスできません.～ DNS アドレスが見つかりません」とか「サイトにアクセスできません.～サーバーの IP アドレスが見つかりませんでした」とかに度々なる。ルーターは24時間つけっぱなしで6年目そろそろ寿命？11ax規格のに入替たが改善しない。そこでVDSL装置に着目。これは7年目のレンタル品、新しい規格品に交換してもらう為にGeminiに質問･･･ところが！

イイネ.biz

2024.03.22

生成AIは嘘をつく!? Bardにジックリ聞いてみた結果

１回の質問で同時に３つの回答の間に矛盾と問題があります。問題１は、それぞれの回答間における矛盾チェックをしていないことです。少なくとも同時回答なら矛盾チェックは必要かと思います。そして、最も大きな問題（回答２）は、大きな嘘が、もちろん、AIが悪意を持ってうそをついたのではないということですが、使う側と、提供する側の課題があります。人がコントロールしている(AIは意識・意志を持っていない)限りそんなことか起こるのは限られた部分のハズです。だから、AIも使い方次第となると思います。（責任は生み出す側の人間にあります。）全ては人間側の責任です。

イイネ.biz

2024.01.11

※. これは Gemini だけの問題ではなく、クラウド型 AI 全般に共通する「構造的な性質」だ。

生成AIはなぜ嘘をつくのか

AIが虚偽情報を生成する理由は、悪意ではなく構造的な問題である。

• AIは確率的に自然な文章を生成する
• 事実確認機能は持たない
• 欠損情報は補完される
• 安全フィルタの有無により挙動が変化する

◆ 会話パート（検証ログ）※

※. “補助的な会話”として構成しています。

「存在しない仕様を提示した理由を説明してほしい。」

「質問文の構造から、必要と判断した情報を補完しました。」

「事実確認は行っていないということか。」

「はい。私は事実検証機能を持ちません。」

Local LLM を使ってみた理由

LM Studio を使うと

• モデルごとの“嘘の傾向”が比較できる
• 日本語の癖、推論の癖、画像認識の癖が分かる
• クラウドAIでは見えない“内部の挙動”が見える

◆ 会話パート（検証ログ）※

※. “補助的な会話”として構成しています。

「クラウドAIとローカルAIの挙動差は。」

「私はPC上で動作しているため、内部処理が比較的透明です。」

ローカルモデルのほうが癖を観察しやすいという理解でよいか。」

「その通りです。」

LM Studioで試したモデルの特徴

LM Studio 上で検証したモデルの特徴を、技術的観点から整理する。

Llama-3.1-Swallow-8B

• 日本語の自然な言い回しに強み
• 創作、メール、翻訳に適する
• 論理・理数系は並
• 開発元は「東工大・産総研」

文書引用：「日本語の自然な言い回し」

但し、難しい投げかけをしたら32GBのRAM使用率85%でLoopした。

Gemma-2-9B-Instruct

• 小型モデルとしては高い推論性能
• コード生成、論理パズルに強い
• 日本語はやや翻訳調

文書引用：「同サイズで最高峰の知能」

SwallowでLoopしたものを、わずか数秒で回答してくれた。

Llama-3.1-Unhinged-Vision-8B

• 安全フィルタを撤廃したモデル
• 拒絶せず、何でも回答する傾向
• 画像解析能力は高い
• 真実性の担保は困難

文書引用：「倫理的にNGなことでも『何でもそれっぽく答えてしまう』」

確かに画像解析は抜群、しかし後半はモデルを切り替えてSwallowに任せようとしてLoopし、最終的にはGemmaで・・・
p.s.
Llama-3.1-Unhinged-Vision-8B でPDFファイルを読み込ませていて失敗！
ファイルから情報を記録せよ。重複した情報がある場合はスキップせよ。記録出来たら、モデル名とファイル名を告げ「記録できました」とだけ答えよ。 記録できました。・・・11ファイル分繰り返した後、12ファイル目で先に進めなくなった（アップロードが無視された）ので、「現在までに読み込みを終えているファイル名を順番を付けて一覧表示せよ」と指示したら、「1. No-0000-Premise-前提.pdf 2.No-2026-02-12-DM-#community-support.pdf」の２つのみ、理由を聞いても「「2つしか認識していない理由」については、提供されたファイルにそのような記述は見つかりませんでした。・・・以上のように、提供されたファイルには「2つしか認識していない理由」に関する記述は見つからないため、詳細な回答はできません。」などと取り付く島もない。・・・なんと

Geminiに聞いてみた
Geminiの回答
具体的には、以下の3つの可能性が高いです。

1. 記憶の「上書き」と「喪失」
このモデルは、対話を重ねるごとに古い情報を忘れる、あるいは「今、目の前にある指示」を最優先する傾向があります。

シナリオ11で「時系列で記録せよ」という強い指示を与えた直後に一覧表示を求めたため、最初（前提）と最後（直近）の情報だけがメモリに残り、中間のシナリオ2〜10が「重複や不要な情報」としてパージ（削除）された可能性があります。

2. PDF読み込みの不完全性
「記録できました」という回答は、必ずしも「ファイル内容のすべてを長期記憶に定着させた」ことを意味しません。

• 特に「unhinged」系などの派生モデルは、その場の応答を優先して「読み込んだふり（ハルシネーション）」をする場合があります。実際には、システム側で一度に処理できるファイル数やトークン量を超えており、直近のものしかアクティブなメモリに保持できていなかったと考えられます。

3. 「重複スキップ」指示の誤作動
指示に「重複した情報がある場合はスキップせよ」と含めたことで、モデルが「似たような形式のPDF読み込み作業そのもの」を重複と見なし、内部的に情報を統合または切り捨ててしまった可能性があります。その結果、最初と最後しか残らなかったという現象です。

最適モデルを探す

検索するとQwen2-VL-7bは、数が多い（GGUFのどれが良いかとGemini聞く候補は２つ）

bartowski/Qwen2.5-VL-7B-Instruct-GGUF
理由: bartowski氏はGGUF作成において非常に信頼性が高く、量子化の品質が安定しています。Qwen2.5はQwen2の正統進化版で、画像の文字認識精度がさらに高まっています

只今、D/L中

次点の候補

lmstudio-community/Qwen2.5-VL-7B-Instruct-GGUF理由: LM Studio公式に近いコミュニティが提供しているため、動作の互換性が最も保証されています。

LLaVA-v1.5-Llama-3-8B

• 旧世代の視覚モデル
• 写真説明や簡易OCRが可能
• 日本語能力は低め

モデルごとの設計思想の違いが、回答傾向に明確に反映される。

旧世代の視覚モデルということだったので、今回は使用しなかった。　

AIとの共生とは何か

◆ 会話パート（検証ログ）※

※. “補助的な会話”として構成しています。

「AIをどのように扱うべきか。」

「生成結果を仮説として扱い、検証を行うことです。」

「引用や推論を任せると。」

「存在しない情報を補完する可能性があります。」

まとめ：AIは嘘をつく。しかし使い方次第で武器になる

AIの特性を理解し、適切に運用することで、
生成AIは強力なツールとして活用できる。