生成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種類など

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

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

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

イイネ.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.”

生成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は強力なツールとして活用できる。

「AIとの共生」をテーマに掲げ、Geminiとの対話を重ねてきた本連載。しかし、企業の機密情報や法的なリスクが絡む「翻訳プロジェクト」において、クラウドAI依存の限界と、プロジェクトとん挫という現実に直面した。

膨大な知見が詰まった「198のスレッド」を、外部クラウドに委ねたままで良いのか？ 情報の主権は誰にあるのか？

　本記事では、元ITC・セキュリティプレゼンターである筆者が、その最終回答として到達した「ローカルAI（プライベート・インテリジェンス）」の構築プロセスを公開する。最先端のハイスペックPC「Ryzen AI 9」を土台に、Google系「Gemma 2」と東工大系「Llama-3-Swallow」という「二つの脳」を使い分け、PL法リスクに完全オフラインで立ち向かう──。クラウドAI（GEMINI）との「壁打ち」を超えた、真のAI共生の姿がここにある。

第1章：クラウドAIの「とん挫」と、突きつけられた「情報の主権」

• Geminiとの対話の限界: 翻訳プロジェクトにおける稚拙な記述と、とん挫の現実。
• 198スレッドという資産: 外部クラウド（Gemini）上に蓄積された膨大な知見を、どう守り、どう活かすか。（198のスレッド間には、スレッド分断という限界（壁：セキュリティとプライバシーというの名の下の））
  Googleには要望書として送ってはいるものの：彼らが「スレッドを完璧に紐付ける」機能を全ユーザーに開放するのは、サーバー負荷とプライバシーの観点からまだ時間がかかる･･･これがクラウド依存の限界。
  GEMINIを使ったことがある方ならわかる、あれ！これさっき言ったよね？この間言ったよね？といったことが、使えば使うほどでてくる。
• 元ITCの決断: クラウドへの依存を脱却し、ローカル環境で「情報の主権」を取り戻すことの必要性。

第2章：最強の土台（ハードウェア）と、二つの「ローカル脳」の選定

• Ryzen AI 9 HX 470の導入: 55 TOPSのNPUと32GBメモリという、ローカルAIを爆速で動かすための強力な土台。
• 「使い分け」の戦略:
  • Gemma 2 (Google系): GeminiのDNAを受け継ぐ、自然で滑らかな日本語による「清書」役。
  • Llama-3-Swallow (東工大系): 技術的な日本語や法規制を深く理解する、「技術・PL法分析」役。
• コストの現実: 初期投資（PC代）のみ、運用は電気代のみ。API課金からの解放。（実はこのPCの入手にも、入手過程の話(実質30K￥未満の出費だけ)がある･･･この話はまた別の機会で）

第3章：実践：Ryzen AI 9を「最強のAIワークステーション」へ最適化する

• 内蔵SSDとUSB4外付けSSDの使い分け: システムを汚さず、巨大なモデルファイルを外付けSSDへ保存する設定（LM Studio）。
• NPU最優先割り当て: AI Engineの設定で「GPU Offload」を「Max」にし、Ryzen AI 9のパワーをLM Studioにフルコミットさせる。
• 「量子化（Quantization）」の正体: 量子コンピュータではない。精度を維持したままモデルを圧縮し、32GBメモリでの高速動作を実現する技術。

第4章：198スレッドをAIが迷わない「法的に強固なナレッジ資産」へ昇華させる

• マークダウンテンプレートの作成: AIが瞬時に検索・理解できる構造データの構築。
• ポゴピン・リチウムイオン電池のリスク具体化: ハードウェア製品で最も事故リスクが高いコンポーネントの追加。
• 国際法規制への準拠: 日本のPL法に加え、米国法（ANSI Z535）やEU法（GPSR）を意識した分析軸の組み込み。外部クラウドでは不可能な、完全オフラインでの法的リスク分析へ。

第5章：結論：翻訳PRJ再開に向けた、情報の主権の確立

• 正常な管理の下で再開されたら: その時こそ、今回構築した「完全プライベート・インテリジェンス」が、とん挫の原因を排除する最強の武器になる。
• 当面の「宿題」: 198スレッドの棚卸しとマークダウン化（情報の主権確保）、ローカルRAGの環境構築、セキュリティ運用ルールの策定。

課題

本当の、0章から始まる198スレッドに跨る文書の整理・統合、そして公開
（実は、この概説公開前に、既に0章からの記事はWord文書上には存在している）

GEMINIにブログのアイキャッチ画像を頼んだら「パスタ」だった……カオス!!! /// 生成AIとの向き合い方

Windows 11のアプデ検証中に起きた、生成AI（Gemini）との爆笑＆困惑の格闘記。アイキャッチを頼んだらなぜか「パスタ」が出現？謎の中国語、欧米人の顔写真……カオスなやり取りから見えてきた、AIを「有能な秘書」にするための生存戦略を公開。

イイネ.biz

2026.02.16

「効率」を急がない。File System Access APIを前に、私が「悩む時間」を捨てない理由

File System Access APIの基本（メリット・デメリット・使い方）を解説しつつ、AIとの対話から得た「作業の自動化 vs 人間の思考時間」の重要性について深掘りします。効率化だけが正解ではない、納得の作業フローを見つけるためのヒントをまとめました。

イイネ.biz

2026.02.23