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

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 における改善点（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は欠損した情報を補完し、もっともらしい文章を生成する。以前の記事でも触れたように、存在しない製品の型番や仕様を提示するケースが確認されてい...

イイネ.biz

2026.04.05

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

上記モデルは、入れ替え予定：
✔ Q5_K_M があるなら、必ず Q5_K_M を選ぶ
✔ Q5 が無い場合 → Q4_K_M を選ぶ（_S は避ける）

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

✔ DeepSeek R1 系の _S は入れ替え（精度が落ちる）
✔ CyberAgent DeepSeek R1 の Q5_K_S も入れ替え（S は弱い）

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

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

2026年3月、WordPress コミュニティに小さくない衝撃が走りました。
6.9.2 → 6.9.3 → 6.9.4 と、わずか 48 時間の間に 3 回のマイナーアップデートが連続リリースされたのです。

「自動更新が続いて怖かった」「何が起きていたの？」
そんな声が世界中で上がりました。

この記事では、この異例の連続リリースの背景を、一般ユーザーにも分かりやすく整理して解説します。

第1章：6.9.2（3/10）— 大規模なセキュリティ修正が一気に投入された日

6.9.2 は、合計10件の重要な脆弱性を修正するセキュリティアップデートでした。

🔐 修正された主な脆弱性

• XSS（クロスサイトスクリプティング）
• 権限昇格の可能性
• PclZip のパストラバーサル
• Notes 機能の権限バイパス
• getID3 ライブラリの XXE（XML 外部実体参照）

いずれも放置すれば攻撃に悪用される可能性があるため、
WordPress チームは迅速にパッチを公開しました。

しかし、このスピードが後の混乱につながります。

第2章：6.9.3（3/10）— 6.9.2 適用後に一部サイトが“真っ白”に

6.9.2 を適用した直後、世界中のユーザーから次々と報告が上がりました。

❗ 典型的な症状

• サイトが真っ白になる（Fatal error）
• 管理画面にアクセスできない
• 特定テーマのテンプレート読み込みでエラー発生

原因は、
一部テーマの非標準テンプレート処理と WordPress コアの変更が衝突したこと。

WordPress.org は 6.9.2 を一時撤回し、
緊急修正版として 6.9.3 を数時間以内にリリースしました。

第3章：6.9.4（3/11）— セキュリティ修正の“未適用”が発覚し、再修正へ

6.9.3 でクラッシュ問題は解決しましたが、
WordPress セキュリティチームが調査を進める中で、
6.9.2 で修正したはずの脆弱性の一部が実は適用されていなかったことが判明。

🔍 未適用だった修正

• PclZip のパストラバーサル
• Notes 機能の権限バイパス
• getID3 の XXE

これらはセキュリティ上重要な修正であるため、
翌日 6.9.4 として完全版パッチがリリースされました。

まとめ：なぜこんな異常事態になったのか？

🟦 原因1：修正規模が大きすぎた

10件の脆弱性を一度に修正する大規模パッチだった。

🟥 原因2：テーマ側の非標準コードとの衝突

6.9.2 の変更が一部テーマと噛み合わず、サイトがクラッシュ。

🟨 原因3：セキュリティ修正の一部が未適用

内部 QA の見落としにより、修正が完全に反映されていなかった。

Cocoon ユーザー（あなたの読者）へのアドバイス

• Cocoon は標準準拠なので影響は比較的軽微
• 6.9.4 に更新しておけば安全性は確保される
• 今回の件は「WordPress の裏側」を知る良い機会
• ブログ運営者は自動更新のログを確認しておくと安心

2026年3月の Windows 11 累積更新「KB5079473」が公開されました。Secure Boot 証明書更新・WDAC の安定化・Explorer 検索改善など、OS の基盤に関わる重要な内容が含まれています。特に Copilot+ PC（Ryzen AI / Snapdragon X）を利用しているユーザーにとっては、AI ワークロードの安定性に間接的に影響する部分もあり、見逃せないアップデートです。

KB5079473 の概要

主な改善点

– Secure Boot 証明書更新の対象拡大 – Explorer 検索の信頼性向上 – WDAC（Application Control）の COM 許可処理改善 – Emoji 16 対応、ネット速度テスト機能追加

不具合対応

– 検索インデックス破損の修正 – WDAC の過剰ブロック修正 – Windows Update の段階的配布ロジック安定化

考慮点

– Secure Boot 証明書更新は段階的配布 – WDAC を独自運用している環境では検証推奨 – 複数ドライブ構成ユーザーは検索改善の恩恵大

Copilot+ PC への影響

AI 基盤への間接的効果

– Secure Boot 証明書更新 → AI ランタイムの署名チェック安定 – WDAC COM 許可改善 → ローカル LLM の初期化安定 – Explorer 検索改善 → モデル配置が複数ドライブでも快適

不具合対応

– WDAC の過剰ブロック減少 – Secure Boot 証明書更新による DLL 読み込み安定化

考慮点

– NPU/GPU の AI 機能は今回の KB では更新なし – LM Studio などローカル LLM を使うユーザーは恩恵大 – 最新 UEFI 実装により証明書適用が早い傾向

「概説最終章」Ai共生：クラウドAIのとん挫をローカルAIで救え！ Gemma 2×Llama-3-Swallowで構築する、最強のプライベート・インテリジェンス

AI共生をテーマに、Geminiとの対話を続けてきた元ITC・セキュリティプレゼンターが到達した、クラウドAI依存の限界とローカルAIへの移行プロセスを公開。Ryzen AI 9という強力な土台に、Gemma 2とLlama-3-Swallowという「二つの脳」を使い分け、198スレッドの機密情報を完全オフラインでPL法リスク分析へと昇華させる──。情報の主権を取り戻す、真のAI共生の最終回答。

イイネ.biz

2026.03.09

一般PC への影響

新機能

– Emoji 16 – ネット速度テスト – Explorer 改善（Copilot+ PC と同様）

不具合対応

– WDAC COM 許可改善 – 検索インデックス破損修正 – Windows Update 安定化

考慮点

– 古い UEFI の PC では証明書適用が遅れる可能性 – WDAC 非使用環境では影響小

編集後記：TPM Event ID:1801 の本質

読者へのメッセージ

これまで Secure Boot 証明書更新や TPM Event ID:1801 に関連するKB5077241、KB5077181、KB5074105で記事を 5本にわたり書いてきました（1202PV, 106PV, 617PV, 290PV, 54PV）。多くの方が同じ問題に悩み、故障かもしれないと不安を抱えながら情報を探していることを知りました。（私自身もまた被害者でした。）

今回の記事が、Microsoft や OEM にも届き、ユーザーが不必要な不安を抱えない世界に近づくことを願っています。

「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

「さあ休もう」と思ったその瞬間、Windows Updateが牙を剥きました。

今回ターゲットとなったのは、本ブログの検証機Aとして不具合を追い続けている Ryzen 9 8945HS搭載のGEEKOM AE8 です。

シャットダウン時に表示された「更新して再起動（4分）」という言葉を信じて選択した結果、待っていたのは10分経っても、15分経っても電源ランプが消えない絶望的な沈黙でした。17分が経過し、ついに耐えかねて「電源ボタン長押し」による強制終了を断行。

しかし、悪夢はそこでは終わりませんでした。再起動後、ログインまでに立ちはだかったのは2回にわたるBIOS画面と執拗な「更新中」の表示。

一体、何のための「更新」なのか。なぜ実機ユーザーがここまでリスクを負わなければならないのか。

本記事では、最新ビルド 26200.7922 (KB5077241) がAE8環境で引き起こした凄惨な挙動を、一切の妥協なしに晒します。

導入：Intel機（x360）の陰で、Ryzen機（AE8）を襲う悪夢

• 繰り返される悲劇: これまでKB5077181で「ブラックアウト」を繰り返してきた検証機A（AE8）が、またしても最新パッチで牙を剥きました。
• 「4分」の嘘に翻弄: 平穏なシャットダウンを奪った「更新して再起動」の17分※間に及ぶフリーズ状態を記録します。（「更新して再起動（4分）」を選択後、OS側からの反応が一切消失。 ※17分間にわたり電源LEDは点灯しているものの、ディスクI/Oや画面出力に変化がない「完全なフリーズ状態」となったため、ハードウェア破損のリスクを冒してユーザーが手動で電源ボタン長押しによる強制終了を断行しました。
• この強制介入なしには、更新プロセスは永久に完了しなかったと推測されます。強制終了後もBIOS画面への遷移＆更新を2回繰り返すなど、システムの整合性が著しく脅かされました。）

AE8（Ryzen 9）特有の執拗な再起動プロセス

• BIOS三重苦: 強制終了後の2回にわたるBIOS画面と、終わらない「更新中」の表示。x360（Intel）では見られない、Ryzen機特有の不安定な更新挙動を晒します。
• 無意味な「成功」通知: 命からがらログインした後に表示された「正しくインストールされました」という文字の空虚さを追求します。

結論：RyzenユーザーはKB5077241を避けるべきか

• 実機検証の結果: 本日の事象（Build 26200.7922への更新）により、AE8環境における最新Windows 11 25H2の危険性がさらに増したことを警告します。
• MSへの抗議: フィードバックHubだけでは足りない、実機ユーザーの「時間の損失」をブログという公共の場で強く主張します。

SlimStatのログでも「AE8 25H2 不具合」といった特定の組み合わせで探しているユーザーが見受けられます。今回の件は、その層にとって決定的な回避シグナルになります。

【実機比較】MSはRyzenを放置しているのか？

今回の KB5077241 適用時における、Intel機（sz6）とRyzen機（AE8）の挙動の差をまとめました。

分析：AE8ユーザーへの警告

「正しくインストールされました」という通知とは裏腹に、Ryzen環境におけるアップデート・プロセスの崩壊は明らかです。
x360で培った「安定への知恵」が、このAE8というハイエンド機においては、MSの最適化不足によってことごとく打ち砕かれています。

Feedback Hub に追記

【問題の詳細】
Ryzen 9 8945HSを搭載したGEEKOM AE8において、KB5077241 (Build 26200.7922) の適用中に重大なハングアップが発生しました。

「更新して再起動（4分）」を選択後、OS側からの反応が一切消失。
17分間にわたり電源LEDは点灯しているものの、ディスクI/Oや画面出力に変化がない「完全なフリーズ状態」となったため、ハードウェア破損のリスクを冒してユーザーが手動で電源ボタン長押しによる強制終了を断行しました。

この強制介入なしには、更新プロセスは永久に完了しなかったと推測されます。強制終了後もBIOS画面への遷移を2回繰り返すなど、システムの整合性が著しく脅かされました。

同様のビルドを適用したIntel機（i7-1165G7）では数分で正常終了しており、本件は明らかにRyzen環境における更新プロセスの致命的なバグです。早期の調査と修正を強く求めます。

## 追加の技術補足（MSへの強い抗議用）
フィードバックのコメント欄や追記できる場所があれば、以下の「事実」も添えてください。

「4分」という虚偽の予測表示: ユーザーに安全な更新を誤信させ、結果として17分以上のフリーズを強いるUXの欠陥。

ログ上の「成功」判定: 強制終了という異常な手段でしか復旧できなかったにもかかわらず、OS履歴上では「正しくインストールされました」と記録される不整合。

追記情報

AE8の「沈黙」を多角的に検証する

【比較】Ryzen 9 8945HS機・三者三様の挙動

まずは、同等スペックの他社機と比較して、AE8がいかに「極端な」状態にあるかを可視化します。

※。リスク含みの強制終了までの時間であり。何も操作を行わなかった場合、ずっとブラックアウト状態だった可能性は否めない。

考察

こうして並べると、AE8のスタイリッシュな金属筐体と超小型設計が、Ryzen 9の高負荷時（Windows Update時）の熱処理や電力管理において、他社よりもシビアな挙動を招いている可能性が浮上します。

Amazonレビューに記された「救済措置」の先行事例
調査の過程で、Amazonのカスタマーレビューに重要な記述を見つけました。

• 事例： 購入4ヶ月でスリープ復帰不可（画面真っ暗）が発生。
• 対応： 販売店（GEEKOMストア）へ連絡後、迅速に代替PCとして上位機へ交換されたとのこと。

　私のAE8で起きている「3回連続のアップデート失敗と17分間^※のフリーズ」も、単なるOSのバグではなく、ハードウェア（個体）の限界や設計上の不備である可能性を裏付ける内容です。（最初にMSへの怒りをぶつけたのは間違い？でも、３回連続でKB*を当てたことが引き金になっていることは確かなことだし。リスキーなことの連続だし）

3年保証の行使？

これまでの実録データ（長時間の沈黙（ブラックアウト）、BIOSループ、強制終了の記録）をすべて揃え、GEEKOMストアへ「3年保証」に基づく点検・交換の相談をAmazon経由で送付しました。

AIにコードを相談し、返ってきた答えをエディタに貼り付ける。

この一連の作業をボタン一つで自動化できる技術、それが「File System Access API」です。

しかし、この便利なAPIを知ったとき、私は立ち止まりました。

AIが「無駄な手間」と呼ぶその数秒間、私は「次はどう動かそうか」と構成を練り、コードの行き先に悩んでいたからです。

一見すると非効率な「コピペ」や「ファイルを探す手間」の中にこそ、実は納得のいくものづくりに欠かせない、大切な時間が隠れていました。今回は、AI（Gemini）との対話を通じて再発見した、「あえて自動化しないことで守られる、試行錯誤の価値」についてお話しします。

ブラウザとPCの境界線に立つ技術

WebブラウザからPC内のファイルに直接アクセスし、上書き保存まで可能にする「File System Access API」。

この技術を知ったとき、私は一つの期待を抱くと同時に、大きな疑問にぶつかりました。果たしてこれは、私の今の作業を本当に豊かにしてくれるものなのだろうか？

今回は、AI（Gemini）との対話を通じて見えてきた、この技術の正体と「効率化の先にある大切な時間」についてお話しします。

対話セクション

すべては「素朴な疑問」から始まった

この記事の出発点は、私がGeminiに投げかけた、あるシンプルな質問でした。

私：

File System Access APIの
メリット、デメリット、セットアップ方法や使い方を教えて。

Gemini：

File System Access APIを使えば、ローカルファイルを直接上書きできるので、AIが生成したコードをボタン一つで手元のファイルに反映できる。コピペの手間がゼロになり、爆速で開発できる･･･

そして、ここから更に突っ込んだ問いかけをしたのですが、････

「中略:･･･「単に便利だと言われるほど、自分の手が離れていく感覚に違和感を覚えたのです。そこで、私はこんな疑問をぶつけました。」

ここからは、Geminiとの会話に於いて、私の問いから始まる対話の一部・途中から載せています。

効率化という言葉への違和感

AIが提示した「爆速」というメリットに対し、自分の実感をぶつけてみました。

AIが「不要な手間」と呼んだものは、私にとっては「新しいアイデアを熟成させるための、かけがえのない時間」だったのです。

私：

1.「GEMINI」などのAIにコードを書いてもらう。
2.コードを「コピー」する。
3.自分のエディタ（VS Codeなど）を開く。
4.該当箇所を探して「貼り付け」して「保存」する。
・・ここまではよく利用しています。

Gemini：

なるほど、非常にクリアな作業フローですね！現在の「コピー＆ペースト」というスタイルが確立されている場合、確かに「わざわざ新しいAPIを使うメリット」が見えにくいのは当然です。

結論から言うと、あなたの使い方は**「今のままでも十分に正しい」です。ただ、File System Access APIを使うと、その「動作確認・検証」までの往復回数が多い場合に、劇的なスピードアップ**を感じられるようになります。

「メリットを感じられるかどうか」の分かれ道は、以下の3つのポイントにあるかもしれません。

1. 「コピペ」の回数が10倍、20倍になったら？

今のフローでは「1回AIに聞いて、1回コピペして終わり」なら苦になりません。しかし、以下のような場面ではどうでしょうか。

• 試行錯誤（トライ＆エラー）: 「ここを赤くして」「やっぱり青にして」「角を丸くして」と、AIと10回やり取りする場合。
• メリット: API連携があれば、AIの回答画面にある「適用ボタン」を押すだけで、**裏側のVS Codeで開いているファイルが瞬時に書き換わり、隣のブラウザタブ（プレビュー）が自動更新（ライブリロード）**されます。
• 感覚の差: 「手動で5ステップ」かかる作業が「0ステップ」になり、思考を止めずに検証に集中できます。

2. 「特定の箇所」を探す手間がゼロになる

「Test用HTML内の特定の箇所に追記する」際、ファイルが長くなってくると、該当箇所をスクロールして探す手間が発生します。

• APIの強み: プログラム（スクリプト）側で「から の間を書き換える」といった指定が可能です。
• メリット: あなたがエディタで場所を探す必要すらなく、AIと「ここ直しておいて」と話すだけで、正確な位置にコードが差し込まれます。

3. 「Webサイトへの移行」もシームレスに

現在はローカルで検証したあと、手動でWebサイト（サーバー）へ移行されているかと思います。

• 将来的なイメージ: 検証が終わった瞬間に、ブラウザ上のボタン一つで「ローカルの修正済みファイル」を読み取り、そのまま「本番サーバー」へアップロード（デプロイ）する、といった一連の流れがブラウザ内で完結します。

私：

……AIにプログラムを書いてもらい、
コピペして、エディタの特定の箇所に追記し、検証する。
その間、
私は『次はどうしようか』とアイディアを練る時間も取っています。

ただ組み込むだけじゃなく、常に新たな思考が伴う。
行き詰まったらまた相談し、
最終的な形になるまで試行錯誤を繰り返す。

この『悩む時間』こそが自分にとって大事な作業工程なんです。

だから、File System Access APIの機能が素晴らしくても、
便利な機能でも、使い道？･･･として、「ピン」と来ません。
これだとAPIのメリットを感じられません。私の考えは間違いでしょうか？

Gemini：

全く「間違い」ではありません。むしろ、あなたの作業スタイルは**「エンジニアとしての極めて健全で、深い思考を伴うプロセス」**です。

お話を伺って、なぜ File System Access API のメリットが響かなかったのかが完全に見えました。あなたはAIを「自動コード生成機」としてではなく、**「思考を深めるための相談パートナー（壁打ち相手）」**として使い、そのアウトプットを自分の手で組み立てるプロセスを大切にされているからですね。

そのスタイルにおいて、このAPI（自動化）がなぜ「余計なお世話」に感じるのか、そして逆に「こういう時なら役立つかも？」という視点を整理しました。

あなたのスタイルで「自動化」が不要な理由

今の作業フローには、単なる「作業」以上の意味が含まれています。

1. 「思考の同期」としてのコピペ:

AIのコードを自分の手でエディタに貼り付け、場所を探すプロセスそのものが、**「コードの構造を理解し、自分の頭にインストールする時間」**になっています。ここを自動化してしまうと、自分のコントロールを離れて勝手に中身が変わる「ブラックボックス」になってしまいます。

• 「熟成」の時間:

「次はどうしようか」と練る時間は、クリエイティブな作業において最も重要なフェーズです。効率化して時間を短縮することだけが正解ではありません。

---

逆に「もし」このAPIを使うメリットがあるとしたら？

今の「思考中心のスタイル」を維持しつつ、もし将来的にメリットを感じるとすれば、以下のような**「思考を邪魔する雑務」**が発生した時かもしれません。

① 「1つの変更」が「10個のファイル」に影響する場合

例えば、サイト全体のデザイン（CSS）を微調整したいとき、AIから「この5つのファイルの、この部分を全部書き換えて」と言われたらどうでしょう？

• 手動: 5つのファイルを開き、場所を探し、5回コピペする。（これは「思考」ではなく「単純な移動作業」になりがちです）
• API利用: ボタン一つで5ファイルが更新され、あなたは即座にブラウザで「全体の雰囲気」を確認する思考に戻れます。

② 「画像」や「音声」などのバイナリデータを扱う場合

コード（テキスト）はコピペできますが、AIが生成した「画像」や「最適化されたアイコン」をローカルに反映させるのは面倒です。

• 手動: 右クリックで保存 ＞ フォルダを選択 ＞ 名前を付けて保存 ＞ エディタでパスを確認。
• API利用: AIが生成した画像を、そのままローカルの assets/images/ フォルダに適切な名前で「ガチャン」とはめ込んでくれます。

---

結論：このAPIは「道具」であって「目的」ではない

File System Access API は、**「PCの中とWebを繋ぐ土管（パイプ）」**を作れるようになる技術に過ぎません。

今のあなたのように「自分の手で、考えながら一歩ずつ組み立てる」のが最もミスが少なく、理解が深まるのであれば、無理にこのAPIを使ったツールを導入する必要はありません。

結びに：自分にとっての「最適解」を見極める

File System Access APIを巡る対話を通じて見えてきたのは、「効率」を優先してツールに任せる部分と、「納得」のために自分の手を動かす部分を自分自身で選ぶことの重要性でした。

「効率」とは、単に時間を短縮することだけではありません。

納得がいくまで悩み、アイディアを練り上げるための時間を、いかに確保するか。

便利すぎる最新技術を前にして、あなたはあえて「自分の手を動かす時間」を、どこに残しておきたいですか？

最後のひとこと

（一言と言っておきながら、３つあります。）

• 「効率化が奪うのは『手間』だけじゃない。構成を練る『時間』も奪っているのかもしれない。」
• 「AIとのコピペ作業は、私にとっての『思考の同期』だった。」
• 「技術に従うのではなく、自分の作業リズムを守るために技術を吟味する。」

技術的な「余白」

「今回、あえて手動を選んだ私ですが、もし自動化を試してみたい人のために、最小限のコード(JavaScript)を置いておきます」

➡ Codeエリアのマウスホバーで アイコンが表示されます。
この アイコン　クリックでSource Codeをクリップボードにコピーできます。

async function overWriteFile() {
  try {
    const [handle] = await window.showOpenFilePicker(); // ファイル選択
    const writable = await handle.createWritable(); // 書き込み準備
    await writable.write("/* AIが生成した新しいコード */"); // 書き込み
    await writable.close(); // 完了
    alert("保存しました");
  } catch (err) {
    console.error("キャンセルまたはエラー:", err);
  }
}

ご参考

試行錯誤の実態

私の試行錯誤の実態については、こちらの記事もその一端です。👇

ハマった！Webサイト公開直前の落とし穴 - Geminiと挑んだ原因不明エラー解決記

Webサイト公開直前に遭遇した、原因不明のConsoleエラーとの壮絶な格闘記。頼れるはずの生成AI「Gemini」に助けを求めるも、その道のりは困難の連続。最終的に問題解決へと導いたのは、意外な場所へのコード移動というアナログな方法だった。AIの可能性と限界、そしてWeb開発における予期せぬトラブルの面白さを描いた、エンジニア必読の顛末。

イイネ.biz

2025.05.28

ターゲットは、名機 Let’s note SZ6 (Core i5-7200U)。そして、同じく「Windows 11公式サポート対象外」の壁に直面しているIntel第7世代プロセッサ搭載機のユーザーです。

【特にこの記事を参考にしていただきたい方】

• Let’s note SZ6 シリーズを愛用している方
  • Core i5-7200U / i5-7300U 搭載モデル
• 「公式非対応」のIntel 第7世代CPU搭載機をWindows 11で運用中の方
  • ノートPC（モバイル用Uシリーズ）: * Core i7-7500U, i5-7200U, i3-7100U 等
  • デスクトップPC（S/Kシリーズ）: * Core i7-7700 / 7700K, i5-7500, i3-7100 等
• Windows 11 バージョン 25H2 へのアップデートに不安がある方
  • 「古いPCでも最新の25H2は動くのか？」
  • 「累積更新プログラム（KB番号付きパッチ）がエラーで止まらないか？」
  • 「動作が重くなったり、特定の不具合が起きたりしないか？」
• 4万PV超の前回記事（1800番）のその後の経過を知りたい方
• TPM 2.0は持っているがCPU要件で弾かれているマシンのオーナー

「非対応PCでも累積更新プログラム（KB5078127以降）は正常に適用できるのか？」「OSの進化に伴い、動作は重くなっていないか？」

4万件以上（26/02/21現在：40,897pv）のアクセスと、検証記事（1800番）で100名を超える（161：同）ユーザーフィードバックから得られた知見を基に、SZ6が2026年現在も「現役」で戦えるのか、その限界と安定運用のための全記録を公開します。

今後も、SZ6のWindows Update、eKBによる更新、場合によっては.isoファイルによるアップデートを継続してまいります。（Windows11要件でsz6に不備なのはCPU世代だけで、一番肝心のTPM2.0は備えています。）

Windows Update

Build 26200.8246 KB5083769 25H2

改善点

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

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

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

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

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

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

KB5083769（Build 26200.8246）徹底解説：Copilot+ PC と一般PCで何が変わったのか

AI時代のWindowsアップデート：Copilot+ PC と非NPU PCの違いを技術的に整理する2026/04、Windows 11 25H2 に適用された KB5083769（Build 26200.8246） は、単なる不具合修正...

イイネ.biz

2026.04.15

Build 26200.8037 KB5079473 25H2

Windows 11 KB5079473 徹底解説：共通改善点・Copilot+ PC への影響・一般PCとの違い、そして Secure Boot 証明書問題の本質

Windows 11 KB5079473 の最新情報を徹底解説。共通改善点、Copilot+ PC への影響、一般PCとの違い、Secure Boot 証明書更新、WDAC 安定化、Explorer 検索改善などを技術者視点で詳しくまとめました。TPM Event ID:1801 の本質と Microsoft・OEM の対応問題にも触れます。

イイネ.biz

2026.03.18

Build 26200.7840  KB5077181  25H2

「更新には78分ほど要しましたが、バックグラウンドでの処理が終われば、ブラウジングや事務作業においてメモリ8GBでも目立った遅延はなく、実用範囲内であることを確認しました。最新機と比較すれば更新時間はかかりますが、名機SZ6の安定感は健在です。」･･･デバイス名にある様に2018/03/03に新古品(新品未使用品)で買った、2016/10/04発売モデルです。(なんと、後数カ月で10年前のモデルになってしまうものです。)

KB5077181（Build 26200.7840）リリース。セキュリティの脆弱性修正に加え、前回のプレビュー版で露呈したTPM関連の通信不備に起因する「致命的なフリーズ」が抑制されています　26/02/11

　　詳細は以下のブログカードのクリックで、ご覧いただけます。

【要注意】Windows 11 KB5077181適用レポート：ブラックアウトの懸念は？

月例アップデート検証報告。前回のブラックアウト不具合を経て迎えた運命の日、Ryzen 9搭載 AE8での結果は「生還」。しかし、Intel機との比較検証で浮かび上がったのは、依然として残るTPMエラーとRyzen特有の不安定な挙動でした。実機ログを基に徹底解説。

イイネ.biz

2026.02.20

Build 26200.7705  KB5074105  25H2

KB5074105（Build 26200.7705）リリース。このパッチは、先日話題になったクラウドストレージのフリーズ問題（KB5078127）を完全に飲み込んだ「全部入り」のアップデートです。　26/01/30

　　詳細は以下のブログカードのクリックで、ご覧いただけます。

Windows 11 パッチ KB5074105 徹底解説：進化と「再起動トラブル」からの生還記 1,111PV突破

ブラックアウト🔛強制遮断、3度目の再起動でログインそして、イベントビューアー＆システムケアWindows 11 バージョン 25H2/24H2 向けの最新プレビュー更新プログラム KB5074105 がリリースされました。このパッチは、先日...

イイネ.biz

2026.02.17

Build 26200.7628  KB5078127  25H2

KB5078127 (Build 26200.7628)　 日々の業務でOneDriveやDropboxなどのクラウドストレージを活用している方にとって「待望の修正」となります。ファイル保存時のイライラを解消し、システムの安定性を大幅に高める内容です。　26/01/25

　　詳細は以下のブログカードのクリックで、ご覧いただけます。

【緊急更新】Windows 11 KB5078127配信開始！クラウド利用時の「フリーズ問題」を解消

24H2/25H2 : 最新の更新プログラム KB5078127 (Build 26200.7628) が配信されました。今回のアップデートは、日々の業務でOneDriveやDropboxなどのクラウドストレージを活用している方にとって「待...

イイネ.biz

2026.01.26

過去分のアップデート

５年以上前のパソコンでもWindows11は動くのか？ Let's note sz6 Core i5-7200U 21H2 ➡ 25H2

あなたはWindows11で新しいパソコン買いますか？ここでは5年前(執筆時）Intel 7世代CPU:sz6:2016年10月モデルにWin11インサイダープレビューから動作検証、以降順次・最新版へアップデートし、経過チェックし詳細にLog記録いくもので最新は23H2･･･

イイネ.biz

2026.02.19

eKB アップデート

（Enablement Package：イネーブルメント パッケージによる更新）

25H2化

KB5065789が適用される前の状態であるため、一部の洗練度や安定性において後のビルドに劣る可能性がありますが、中核となる25H2の新機能はここで既に有効化されます実際の新機能のコードは、eKBを適用する前の累積アップデートに既に含まれeKB(KB5054156)は、それらの機能フラグを「オン」にする役割を果たし、Build 26200.6584の特性は、25H2の中核機能を有効化しているが、後続の累積アップデート（KB5065789）で提供される追加の安定性向上やバグ修正は含まれていない初期の状態。　25/10/10

　　詳細は以下のブログカードのクリックで、ご覧いただけます。

一足先に、25H2 Let’s note sz6 Core i5-7200U Windows 11 #25H2

このビルドは、将来のWindows 11の主要な進化方向、特にAI機能の統合とパフォーマンス向上の初期段階を示唆しています。KB5065789が適用される前の状態であるため、一部の洗練度や安定性において後のビルドに劣る可能性がありますが、中...

イイネ.biz

2025.10.11

23H2化

EKB KB5027397 は、Windows Update よりも迅速な更新: 単一の再起動でバージョン 22H2 から 23H2 へ直接アップグレードできます。　24/06/12

　　詳細は以下のブログカードのクリックで、ご覧いただけます。

23H2化 には イネーブルメントパッケージを使うWindows11 Core i5-7200U Let's Note sz6

重要Windows 11 バージョン 22H2 のホーム エディションと Pro エディションは、2024 年 10 月 8 日にサービスが終了します。 それまで、これらのエディションはセキュリティ更新プログラムのみを受け取ります。 セキュリティ以外のプレビュー更新プログラムは受け取りません。 2024 年 10 月 8 日以降もセキュリティ更新プログラムとセキュリティ以外の更新プログラムを受け取り続けるには、最新バージョンの Windows に更新することをお勧めします。

イイネ.biz

2024.06.12

.iso アップデート

（.ISOファイル適用による更新）

24H2化

Let’s note SZ6

24/10/01にMicrsoftが24H2を公開、Win11対応PCには順次24H2更新の案内が届く。しかしCF-sz6はその対象ではないので、.isoファイルによるアップデートを試み、手順を共有　24/10/03

　　詳細は以下のブログカードのクリックで、ご覧いただけます。

一足先に、24H2：Let’s note sz6 Core i5-7200U Windows 11

Core i5-7200Uの24H2アップデートLet’s note sz6は、Windows 11インサイダープレビュー以来、順調にアップデートを重ね、先日も22H2から23H2へのアップデートを済ませ、24/10/09の次回月例更新を待...

イイネ.biz

2025.10.12

異なる言語でプリインストールされたPC

AE8

AE８は、英語版Windows11でプリインストールされていた為、

• 通常のWindows Updateが失敗した。
• さらに、Win11_24H2_Japanese_x64.isoの日本が版では、引き継ぐ項目で、　
  〇「ファイル、設定、アプリを保持する」が選べない　
  ◎「個人用ファイルのみを引き継ぐ」となっていた。
  （クリーンインストールのみ可能）移行過程で、「ファイル、設定、アプリを保持する」が選択できないとアプリの再インストール・設定が必要となる。
• そこでWin11_24H2_English_x64.iso英語版でのアップグレードを実施した。
  24/12/24

　　詳細は以下のブログカードのクリックで、ご覧いただけます。

異なる言語でプリインストールされた23H2は、Win11_24H2_Japanese_x64.isoでは24H2化できなかったけど･･･

異なる言語でプリインストールされたWindows 11 23H2、初期設定時の日本語キーボード対応設定が必要なだけじゃない。24H2化で必要なこと。Win11_24H2_Japanese_x64.isoからのアップグレードは失敗するので対策が必要です。

イイネ.biz

2024.12.15

自作PC

i7-4770K

i7-4770K 自作機は第四世代CPUでWindows 11対象ではないため、Win11_24H2_Japanese_x64.isoによるWindows 10からのアップグレードを行った。　24/10/06

　　詳細は以下のブログカードのクリックで、ご覧いただけます。

10年前の古い第四世代CPUに24H2 Windows 11　i7-4770K 自作PC

24/10/01発表の24H2では、CPUの世代、ファームウェア：UEFI、セキュア ブート対応ストレージ、 TPM 2.0、グラフィックス DirectX12以上などの条件をチェックせずにUpgradeできるという情報を得た。i7-4770K Windows 11 24H2へUpgrade

イイネ.biz

2024.10.06

When the update doesn’t proceed

Windows Update:いつまで経っても進まないとき ➡

Windows Update いつまで経っても進まない時のたった一つの対処方法　25,000PV超(累計)

累計25,000超PVあなたは、ウィンドウズアップデートが出来ない。いつまで待ってもダウンロードが一向に進まないなどという経験はありませんか？➡今回はその対処方法をお届けしたいと思います。その方歩は➡スタンドアロンインストーラーを使って手動でアップデートする

イイネ.biz

2025.08.13