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

Ubuntu と CLI で始めるローカルLLM運用

Thank you for reading this post, don't forget to subscribe!

生成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：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．Gemma-4-26B-A4B-it-Q4_K_M.ggufがBatch一括処理Jobのコーデイングを受け持つ

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