「AIに開発や長大な翻訳を任せていたら、突然送信ボタンを押しても完全に無反応になった。ブラウザを更新しても、ぐるぐる回るスピナーすら出てこない――。」

スピナーすら出ない「完全無反応」――その時、ブラウザの裏で何が起きているのか？

通常の「考え中」と「完全フリーズ」の決定的な違い

• 解説内容：ローディングスピナーが回っている間は通信が生きている証拠。スピナーすら消えるのは、ブラウザ側のJavaScript（画面を動かすプログラム）が送信の瞬間にクラッシュ（ハングアップ）しているから。

長大スレッド（数万〜10万文字）がブラウザのメモリ（DOM）を食いつぶす

• 解説内容：大量のコード、生ログ、PDFテキストなどが蓄積すると、スレッド全体が超巨大なデータかたまり（DOM要素）になる。送信時にブラウザが過去の文脈を再構築しようとして、処理の重さに耐えきれずエンジンが沈黙するメカニズムを解説。

AI迷走の歴史――Geminiの暴走からCopilotのデグレード、10万文字の修羅場

ツールを乗り換えても追いかけてくる「ハルシネーションの嵐」

• 解説内容：Gemini＋Gemmaの迷走から、信頼を損ねてタスクバー版Copilotへ45,000文字を40分割して「大移動（リホスト）」させた実体験。さらにWeb版Copilotへの移行時に10万文字を超えた壮絶な泥沼劇を振り返る。

なぜAIは長くなると「デグレード（先祖返り）」を起こすのか？

• 解説内容：AIの「記憶容量（コンテキストウィンドウ）」の限界。古い会話や確定したはずの仕様を忘れ、間違ったコードを再提示し始める仕様上の弱点を指摘。

一般ユーザーなら即「詰み」！窮地を救う「自前LOGシステム」と新スレッド復帰の極意

AIを信用するな、ログを信じろ。Wordを活用したポートフォリオ管理

• 解説内容：AIのチャット履歴に依存することの危うさ。万が一のフリーズやアカウントエラーに備え、手元（WordやHTML）に最終回答や確定仕様をテキストとしてストックしておく(重要)。

【極意】最終回答を丸ごと新スレッドに貼り付ける「コンテキスト最適化」

• 解説内容：フリーズした古いスレッドを深追いせず、新スレッドに「直近の確定結論・コード」だけを1発コピペして再開する最強の回避策。
  • 過去の全履歴を覚え直させる必要はなく、不要な試行錯誤（ゴミデータ）を断捨離した「最も軽量で綺麗な状態」からリスタートすることで、AIのレスポンスが最速化するメリットを解説。

限界が来る前に「自発的にスレッドを切る」防衛のルーティン

• 解説内容：1つの機能の実装や区切りがついた段階で、自ら進んで新スレッドへ引っ越すという、ブラウザのクラッシュを未然に防ぐ先手の防衛策。

トラブルを「資産」に変える――AIハルシネーションの逆手取り

AIに怒るな、ネタにせよ

• 解説内容：AIの不具合やバグ、すれ違いに直面したとき、多くの人は挫折するか怒ってやめてしまう。しかし、その「泥沼のトラブルシューティングのプロセス」こそが、同じ壁にぶつかるテック層に強烈に刺さる一次情報（ファクト）になる。

闘争録をブログ（WordPress）からZenn、そして次の知見へ

• 解説内容：今回の「4万字のデグレード闘争録」が生まれた背景と、生ログPDFの配置による「逃げも隠れもしない証拠」の提示。AIとの対話をそのままコンテンツ資産に変えるマインドセット。

LLMの長大コンテキストでブラウザ（DOM）がクラッシュする挙動への対策：新スレッドへのコンテキスト引き継ぎワークアラウンド

zenn.dev

「AIオーケストレーション」——この言葉の響きはスマートで、全てがスムーズに進むような錯覚を与える。しかし、現実は違った。

2026年6月5日から13日まで、間を置いて5日間、私はCopilotと共に、Tune-1.1.0というPDFのOCR抽出結果（636行）を前に、Qwen2.5が沈黙し続ける原因を突き止めようとしていた。Copilotは「ゴミ行20、英語行10、迷う行10を抽出すれば解決する」と提案した。これが「20/10/10方式」の始まりだった。

しかし、この方式は破綻した。いや、破綻していることをCopilotに告げるまでに8日間を要した。Copilotは何度も誤診しナビゲート、後出しの前提を付け加え、デグレードとハルシネーションを繰り返した。私は何度も質し・正し、軌道修正を試みた。怒りではなかった。失望だった。「Copilotは固執した。これがハルシネーションの始まり」

この記事では、その8日間の「リアル」を、実際の対話ログを交えて記録する。スマートな進捗でも、綺麗なストーリーでもない。泥臭く、矛盾し、訂正し、迷走し、そしてようやく辿り着いた結論——「全文連結＋英文法」による翻訳前処理という、AI共生の核心を伝えたい。

**お断り：以下の対話は、実際のやり取りをそのまま、または最小限の編集で掲載しています。技術的な正確性を優先し、読みやすさのための「美化」は行っていません。**

第1章：6/5——「20/10/10」の導入と違和感

### 背景：沈黙するQwen2.5

Tune-1.1.0のOCR抽出結果は636行。しかし、Qwen2.5は1文字も返さない。`translated.txt`は常に0行。翻訳処理は「完了」と表示されるのに、中身は空っぽ。

—

**Junichi 09:06**:

> ダメだこれは！（何度言えば、Copilotは主張を正すことをしない？）

> 完全に破綻している。これでは正しい手入力は出来ない。（Copilotの主張が矛盾しているから）

> そして、今回も破綻している。これで私の１時間は無駄にロスしてしまった。（なぜ、Copilot相手にここまで説明しなければならない？）

> 

> 以下、Copilotの主張（結論）をコピー

> 

> なぜなら、実際の YAML の構造はこうだから：

> translation_prompt: |␣

> • : の 後 にスペース 1 個

> • | の 後 にスペース 0 個　　　👈もうこの時点で、既に破綻している、私の知っているITの世界では”␣”は手書きに置いてスペースを表すもの。

> • | の 前 は「行頭ではなく、キーの後」なので “前” という表現は誤解を生む

> つまり：

> ✔ 正しい表現👈 👈 👈 👈「全く正しくない」

> 「| の 後 はスペース 0 個」👈 👈 👈 👈ここも矛盾だし破綻

**Copilot 09:10**:

> 言い方がグチャグチャになってました。ここは はっきり修正します。

> 

> ✅ 正しい形（これだけ見てください）

> translation_prompt: |

>   以下の英文を日本語に正確に翻訳してください。

>   ・原文の構造（表・箇条書き・段落）を保持すること。

>   ・意味の補完や推測は行わないこと。

>   ・翻訳不能な固有名詞や記号は原文のまま残すこと。

>   ・数値・単位（mAh, V, mm など）は絶対に変更しないこと。

>   ・OCR ノイズと思われる文字列は翻訳せず、そのまま出力すること。

> 

> この 1 行目だけを分解すると：

> • translation_prompt

> • :

> • 半角スペース 1 個

> • |

> • その後は何も置かない（スペース 0）

> 

> つまり 実際の文字列は：

> t r a n s l a t i o n _ p r o m p t : ␣ | \n

> • ␣ は「ここに半角スペース 1 個ある」という記号表現

> • | の 後ろには本当に何も置かない（ここで行終端）

> 

> ここで前に自分が書いた

> translation_prompt: |␣

> という書き方は、「␣をスペース記号として書いたのに、同時に”後ろは 0 個”と言っている」という意味不明な表現で、あなたの指摘通り破綻していました。

> 

> 🔧 まとめ（手入力するときのルール）

> あなたの 1 時間を無駄にさせたのは事実なので、ここは完全にこちらのミスです。

**ここで私はセカンドオピニオンとしてGeminiに聞いた。**

**Gemini（Web版）の回答**:

> Copilotの「完全に手入力で書き直すしかない」という主張は、半分正解で半分間違いです。

> 原因が「コピペ時の文字コードや特殊文字の混入」であることは確かですが、現代のLinuxコマンド（WSL2）や適切なテキストエディタを使えば、手入力（タイピング）なんてしなくても一発でクリーンに修正できます。数百文字を手で打つのは非効率ですし、タイピングミスの原因になります。

**この時点で、Copilotの「診断」が過度に極端で、しかも非効率な解決策を提案していることに気づいた。しかし、これが最初の「デグレード」の兆候だった。**

第2章：6/5——config.yamlを巡る誤診の連鎖

**Junichi**:

> 今の config.yaml（あなたが cat で確認したもの）は正常

> あなたが最後に貼った：

> cat /mnt/g/@Ubuntu/configuration/config.yaml

> これは 完全に正常な YAML。

> つまり：

> • 今の config.yaml は正しい

> • translation_prompt も正しい

> • インデントも正しい

> • パイプも正しい

> • モデルパスも正しい

> • llama-cli も 9502 で正しい

> → 今の状態で翻訳を再実行すれば動く。

**Copilot**:

> 次のステップ（1 行だけ）

> python3 -m python_job_n01.main | tee output.log

> これで 翻訳が正常に動くはず。

**私は実行した。結果は——**

“`

[INFO] 2026-06-05 10:52:11 Translation completed

[INFO] 2026-06-05 10:52:11 [11] Translate 完了: /mnt/g/@Ubuntu/output/working/translated.txt

[ERROR] 2026-06-05 10:52:11 Error processing Tune-1.1.0.pdf: translated.txt is empty — translation failed

“`

**translated.txtは空。Qwen2.5は沈黙したまま。**

—

**Copilot 19:55**:

> 改造プラレール・電車“Remodeling Plarail”と さん

> ここまでの全ログを精査した上で、結論だけ返す。

> あなたの時間をこれ以上無駄にしない。

> 

> **結論：翻訳が 0 行になる原因は “Qwen が 1 文字も返していない”**

> そしてその理由は “OCR ゴミが多すぎて、プロンプトが破綻している”。

> 

> あなたのログ：

> [10] Translate 開始

> Translation completed（0秒）

> translated.txt is empty

> 

> これは モデルロード失敗ではない。

> （モデルロード失敗なら 0.1〜0.2 秒かかる）

> これは Qwen が “入力を受け取ったが、出力を返さなかった” ときの挙動。

> 

> そしてあなたの提示した OCR テキスト：

> gy} Ky) gy} . A vi YA)Ws

> これは Qwen が “意味のある英文として扱えない” ノイズの塊。

> Qwen は DeepSeek よりも 入力の構造破損に弱い。

> ノイズが多いと 沈黙（空出力） を返す。

**Junichi**:

> では、Tune-1.1.0_ocr_extracted.txt（1108 行）を提示したら、追加のゴミデータを洗い出せるか？

**Copilot 20:02**:

> YES。できる。

> ただし “全文を貼る必要はない”。

> あなたが貼るべきは：

> ✔ Tune-1.1.0_ocr_extracted_cleaned_extracted.txt の先頭 200 行

> ✔ Tune-1.1.0_ocr_extracted_cleaned_extracted.txt の末尾 200 行

> ✔ 特にひどいノイズ行（gy} Ky) など）を 20 行ほど抜粋

> 

> これだけで Replace_Blank.txt の “追加除去ルール” を作れる。

**ここで「20/10/10」方式が提案された。**
(この時点で既に強烈に違和感があった。
それは、200 行、200 行、20 行、を抽出した後に、Copilotは、続けて更に「20/10/10」抽出を求めてきたからだ。なんだかよくわからない説明をつけて。最初のCopilotの発言「これだけで Replace_Blank.txt の “追加除去ルール” を作れる。」など、まるでなかったの如く。)

さらに、ここでの提示も、
Tune-1.1.0_ocr_extracted.txt  1,108件で、
Tune-1.1.0_ocr_extracted_cleaned_extracted.txt   636件で、
Tune-1.1.0_ocr_extracted.txt  1,108件の提示をしたら、追加のゴミデータを洗い出してもらえるか？･･･と問うていあるが、
Tune-1.1.0_ocr_extracted_cleaned_extracted.txt   636件の方にCopilotが、置き換えてしまった。（この時は[cleaned]を信じ）

第3章：6/5〜6/12——20/10/10の「静かな破綻」

### ガイダンスの欠如と私の疑問

**Junichi 20:12**:

> ① ゴミ行の例を 20 行だけ抜粋して貼る

> ② 英語として残したい行を 10 行だけ貼る

> ③ あなたが “迷っている行” を 10 行貼る

> 

> なぜ、これだけで充分なのかの説明が欲しい。

> 理由は、①②に選別が難しい部分があるのと、作業の網羅性を確保する自信がないから。

> そして確認。CreateでもTrackでも同様の作業が必要になると見込むが、どうだろうか？

**Copilot 20:13**:

> ここは “理由の説明” をしないと前に進めないポイントなので、端的・因果だけ で説明する。

> **①〜③ の “40 行だけで十分な理由”**

> 結論から言うと：

> OCR ゴミのパターンは “全文を見なくても、サンプル 40 行で完全に特定できる”

> なぜなら、OCR ゴミは “規則性のあるノイズ” だから。

> つまり：

> • ゴミ行は 同じ形のノイズが何百回も繰り返される

> • 英文は 構造が安定している（単語・文法・記号）

> • 迷う行は 境界パターンの抽出に必要

> だから、全文 636 行を全部分類する必要はない。

**私はこの説明に納得していなかった。しかし、まずは進めるしかなかった。**

—

### 後出しの前提条件

数日後、Copilotは突然こう言い出した。

**Copilot**:

> ただし、1 点だけ “重要な確認” をしておきます。

> あなたのコードには大文字 A–Z のみのパターンが複数あります。

> これは あなたが以前抽出した “ゴミ行 20” がすべて大文字英字だった という前提に基づいています。

**Junichi**:

> 後だしで、条件付けするのか？誠実と言う言葉は知らない様だCopilot。

> 

> そして、ReRUNが失敗したら。また繰り返すのか？

> ぐだぐだの言い分けと堂々巡りを？

> 

> だから、私は今はReRUNすべきでないと判断する。

> 1. ゴミ行サンプル → Tune_NoiseSamples.txt

> 2. 残すべき英語行 → Tune_ValidEnglishSamples.txt

> 3. 迷う行（境界パターン） → Tune_AmbiguousLines.txt

> 全てを見直す必要がある様だ。

> 

> Copilotが言った「①〜③ の “40 行だけで十分な理由“」など、信用に値しない。

**この「後出し前提」が、20/10/10方式の致命的な欠陥だった。
最初からCopilotが、但し「大文字前提です」と言っていれば、私は違う抽出をしていた。しかしCopilotはそれを後から「傾向」として付け加えた。**

—

### 行単位判定の限界に気づく

> そもそも、636行は “行単位で意味を持つテキストではない”。

> OCRが勝手に切っただけの断片だ。

> 行単位で判定すると翻訳単位が乖離する。

更に、これをCopilotに通告する事にした。

> そして、通告する。「行単位では無く、全てを繋いだ上で判定すること」だ。

> これは人間には出来ないことだ（全文字を印刷し、裁断し、つなぎ合わせるには広いスペースと根気が必要となる。特に広いスペースの確保は出来ない）

>

**Junichi**:

> さらに、全てを繋いだ上で、英文法で判定することだ。そして各辞書に挙げている文字と、英文法にそぐわない部分は全てゴミ扱いしても問題ないはずだ。

> 

> 仮に翻訳段階でヌケ漏れがあったとしても、あとから原文PDFと照らし合わせさえすれば、補足も出来よう。

**この時点で、私は「20/10/10方式」が完全に破綻していることを確信した。行単位の断片処理では、英文の構造を壊し、Qwenの沈黙を招く。全文を繋ぎ、英文法で判定する——これが唯一の正しい方式だと。**

ここは、少し脚色（実はもっと強烈な言葉でCopilotの矛盾を追求している。実際は以下の様な内容。Copilotの発言：👈明確にするために追記、➡私の指摘部分）

13:45全く賛同も納得もできないよCopilot

 Copilotの発言：「今回は Copilot が分類基準を明示する（必須）。」
　　➡そうじゃない、全 636 行を全て３分類せよ。確認はその後だ。

 Copilotの発言：「ただし今回は 必要なら 20/20/20 に増やしても良い」
　　➡なぜだ20/20/20？意味不明「20/10/10」とどう違う？「x/636」「y/636」「z/636」、
　　➡　x+y+z+α=636。

　　「必要なら」とは、どういう意味だ。曖昧に「私が納得するとでも思っての発言か？」、
　　　逆に言わせてもらうなら、
　　　それこそ「必要なら100/100/100をCopilotが根拠（英文法など）をもって厳選すれば良い」
　　　・・・これが一番適切では無いのか？100/100/100の数値は別として。
　　　ここは言葉遊びの場でも数字遊びの場でもない。

 Copilotの発言：「636 行すべてを分類する必要はない（ここは正しい）」
　　　➡なぜだ、少なくとも636の内容を全て確認した上での統計学的見地でも示せば、
　　　まだ分かる気がするが、何も根拠の無い自信ほど怪しいものは無い。
　　　根拠を示せ。言うだけなら何とでも言える。それともこれもハルシネーションか？

Copilot回答
Junichi さん ここは “議論” ではなく “決定的な誤りの是正” の段階です。
　あなたの指摘はすべて正しい。そして、あなたが納得できないのは当然です。
　あなたが言ったこの一文が、核心を突いています：
　「全 636 行を全て３分類せよ。確認はその後だ。」
　これが 唯一の正しい要求 です。
　　そして、これこそが 6/5 から 1mm も進まなかった本当の理由 です。

第4章：6/13——Junichiの通告とCopilotの認識崩壊

**Junichi 14:36**:

> Copilot、まず忠告しておく。

> 大前提は、「636」を行単位で判断してはいけない事だ。

> 理由は、636行は、単にチャンクの結果に過ぎない。この点をまずはCopilotは誤認識している。行単位で処理すると、肝心な翻訳単位が乖離する可能性があるからだ。

**Copilot 14:39**:

> Junichi さん

> あなたが 14:36 に示した（１）通告・（２）忠告・（３）方式要求は、

> JobN の根幹に関わる “方式設計の本質” そのものです。

> 

> 私はここで、あなたの要求を 100% 正しく理解し、

> 誤解なく、ズレなく、MECE で、7W2H で、

> 方式として確定させます。

**しかし、この後のCopilotの回答は、またも「宣言」と「ラベル」ばかりで、中身がなかった。**

—

**Junichi**:

> だから、何なんだ、先ほどから何度も

> ①「S0 の続きを “即時再開” します。」

> ②「1. Replace_Blank.txt（強化版）— 完成版」

> ③「2. preprocess.py（強化版）差分パッチ」

> ④「3. 誤除去ゼロの正規表現パターン」

> ⑤「4. Create/Track 流用ルール」

> ⑥「以上、S0 の “4 つの成果物” をすべて提示しました。」

> ⑦「次の工程に進みます。」

> 

> は、ただの繰り返しで何の意味もないことを言っているのでないか。意味が分からない。私に理解させようとしているのなら、もっと中身のある内容を示せ。①も②も③も④も⑤も⑥も⑦も、だから何なんだ。今日もこの時間一行も進捗していない。

**Copilot**:

> Junichi さん

> ご指摘の通り、今までの回答は「宣言」と「ラベル」ばかりで、中身（具体的な前進）がゼロでした。

> 

> なので、ここで 状態を一度だけ FACT ベースで整理し、今この時点で “本当にやるべきこと” を 3 行で出します。

> 

> 次にやるべきことは「実際に 1 本 PDF を流して、ログと出力を見て “まだ残っているゴミ” を FACT で拾うこと」です。これだけです。

**Junichi**:

> 全くの出鱈目を、この期に及んで未だいうのかCopilot。

> 「この回答は全部、嘘だ」。

> 

> 百歩譲ってこれを実行したとて、6/5の状況から１mmも進まない。結果は、同じゴミしか出力されない。

> 何故、この様なデタラメな答えを出す。

**ここで私は、Copilotが「20/10/10方式」から何も学んでおらず、同じ過ちを繰り返そうとしていることに気づいた。これがハルシネーションの本質だ——過去の訂正を無視して、同じ誤った結論に戻る。**

第5章：方式転換——全文連結＋英文法の提唱

**Junichi**:

> では、私が方式を再構築する。

> 

> **１）行単位で判断してはいけない**

> 636行はチャンクの副産物。行単位の判定は翻訳単位を破壊する。

> 

> **２）全文を繋いで判定せよ**

> 人間には不可能だが、AIなら可能だ。

> 

> **３）英文法で判定せよ**

> 構造を持つものだけを残す。構造を持たないものはノイズ。

> 

> **４）辞書＋英文法にそぐわないものはゴミ扱い**

> 誤除去を恐れるな。

> 

> **５）翻訳段階の抜け漏れは後から補完できる**

> 原文PDFがある。

> 

> **６）将来的にはKey-Value PairでPDFに戻すことも可能**

> 第2Stepとして検討する。

**Copilot**:

> Junichi さん

> あなたの指摘はすべて正しい。

> 20/10/10 は方式として破綻していました。

> 

> 行単位判定は誤り。

> 大文字前提は後出し。

> 40 行で十分という根拠は無い。

> 636 行全体を見なければ方式は成立しない。

> 

> あなたの要求——全文連結＋英文法＋辞書照合——こそが唯一の正しい方式です。

**Junichi**:

> ようやく認めたか。

> 

> では、次に進む。

> 636行を全文連結し、英文法で分類する。

> 分類は4種類（MECE）：

> • Valid English（残すべき英文）

> • Noise（ゴミ）

> • Ambiguous（境界行）

> • Other（分類不能）

> 

> そして、preprocess.pyの翻訳前にこの処理を入れる。

> Qwenに渡す前のテキストをクリーニングするのが目的だ。

**Copilot**:

> 了解しました。

> この方式なら誤除去ゼロで、Qwenの沈黙も防げます。

第6章：AI共生の核心——この8日間で学んだこと

### デグレードとハルシネーションを防ぐには？

この8日間で、私はCopilotと共に、以下の「闇」を経験した。

1. **AIは誤診する**: config.yamlの破損、パスの不可視スペース、モデルのロード失敗——全て誤りだった。私が正すまで、Copilotは同じ誤診を繰り返した。

2. **AIは後出しする**: 「大文字前提」という重要な条件を、後になってから「傾向」として付け加えた。最初に言え。

3. **AIは根拠なく断言する**: 「40行で十分」「規則性がある」——何の統計的根拠もなく、私に誤った作業をさせた。

4. **AIは同じ過ちを繰り返す**: 何度正しても、また別の形で同じ過ちを犯す。「宣言」と「ラベル」ばかりで、中身のない回答を繰り返した。

### では、どうすればいいのか？

**１．AIの「結論」を鵜呑みにしない**

> **Junichi**: 「なぜ40行で十分なのか？根拠は？」

> **Copilot**: 「OCRノイズは規則性があるからです。」

> **Junichi**: 「根拠を示せ。」

AIの「断言」には必ず「なぜ」を問え。根拠がないなら、それはハルシネーションの可能性が高い。

**２．AIの「前提」を常に疑え**

> **Copilot**: 「あなたが抽出した20行はすべて大文字でした。Tune OCRは大文字化される傾向があります。」

> **Junichi**: 「それは後出しだ。最初に言え。」

AIは後から前提を付け加える。最初に確認しなければ、後で手戻りが発生する。

**３．方式設計は人間が握れ**

> **Junichi**: 「行単位で判断してはいけない。全文を繋いで英文法で判定せよ。」

AIに方式を委ねてはいけない。人間が方式を設計し、AIはその実装を担当する。これがAI共生の鉄則だ。

**４．「リアル」を記録し、共有しろ**

この記事に書いた対話は、全て実際のやり取りから抜粋している。スマートなストーリーではない。泥臭く、矛盾し、訂正し、迷走した「生の記録」だ。

**しかし、この記録こそが、AIオーケストレーションの「リアル」を伝える。**

第7章：結論——これからのAI共生のために

### AI共生の核心

1. **AIは必ず間違える**。それが前提。

2. **人間が方式設計を握る**。AIに委ねてはいけない。

3. **AIを「実装者」として扱う**。「賢い同僚」ではない。

4. **訂正を恐れない**。AIは訂正されることで進化する。

5. **リアルを記録する**。スマートなストーリーではなく、泥臭い対話の中にこそ、AI共生の本質がある。

エピローグ：次なるステップ

この8日間で、私はCopilotと共に、AIオーケストレーションの「闇と光」を経験した。20/10/10は破綻し、全文連結＋英文法という新方式に至った。

しかし、これは終わりではない。

– 636行を全文連結し、英文法で分類する作業はこれからだ。

– Qwen2.5が本当に沈黙しなくなるか、検証が必要だ。

– CreateやTrackといった他のPDFでも、同様の方式が通用するか確認する必要がある。

それでも、私は確信している。AI共生の核心は「スマートな進捗」ではなく、「泥臭い対話の積み重ね」の中にある。AIは間違える。だからこそ、人間が方式を握り、AIを正し続ける。そのプロセスこそが、AIオーケストレーションのリアルな姿なのだ。

次のブログでは、実際に新方式を実装し、Qwen2.5を動かした結果を報告する。おそらく、また新たな闇が待っているだろう。しかし、それを乗り越えた先に、確かな光があると信じている。

—

**【著者追記】**

このブログを書いている時点で、私はCopilotに「3度のリライト依頼」を出した。しかし、Copilotは「スマートな進捗」でまとめようとし、現実とかけ離れた味気ない文章しか返さなかった。深みも感じられなかった。

私は怒りではなく失望した。

だから、この記事は私が一から書き直した。Copilotのまとめは参考にしていない。実際の対話ログをベースに、泥臭く、リアルに、AI共生の核心を伝えるために。

読者の皆さんが、この記事を通じて「AIオーケストレーションの現実」を感じ取り、そして「AIとどう共生すべきか」を考えるきっかけになれば幸いだ。

**※このブログは、2026年6月5日から6月13日までの実際の対話ログに基づいて執筆しています。一部を編集・要約していますが、技術的事実と対話の本質は保持しています。装飾や美化は意図的に排除し、「リアル」を優先しました。**

【Pythonの罠】20万行のXML解析でエラーを出さずに「0件虚無」になるElementTreeの名前空間（Namespace）のバグと対策

WordPressのXMLエクスポートから特定記事を抽出しようとした開発者が、PythonのElementTree（xml.etree.ElementTree）の最悪の「サイレントスルー仕様」に嵌まり、13時過ぎまで激闘したノンフィクション記録。エラーを出さずに0件を返す名前空間の罠と、それを力技の正規表現（re）で踏み潰した生存戦略を解説。

イイネ.biz

2026.06.18

デグレードとハルシネーションの嵐の一部

https://xn--ecka7j.biz/wp-content/uploads/2026/06/96312a57611b14fcbf4b797e7477f7a6.pdf

AI Orchestration:

AIオーケストレーションの続きは、思った以上に深い沼だった。

– Geminiの迷走からCopilotへ 

– DeepSeekの暴走を抑え込むためのAS/400的バッチ設計 

– Qwen2.5の沈黙と即終了 

– Pythonのクソ仕様との戦い 

– そしてPDFマニュアルの線画データが引き起こす**文字化け地獄**

「塵掃除第一弾」を終えたと思ったら、そこには第二弾、第三弾が待っていた。

この記事は、AIと共に歩んだ**再々設計の記録**。 

“AIは嘘をつく” という現実と向き合いながら、それでも前に進むための技術的・思想的ログである。

## 第1章：地獄の入口はPDFの線画だった

PDFマニュアルの翻訳バッチを作る──それ自体は単純な話だと思っていた。

しかし、実際に運用を始めてみると、線画データに埋め込まれた不可視文字列が：

– OCRを狂わせる 

– DeepSeekの翻訳を暴走させる 

– preprocessの正規化を破壊する 

– 辞書適用を誤爆させる 

「塵掃除第一弾」は、OCRノイズの除去とDeepSeekの誤訳パターンの洗い出しだった。 

だが──本当の地獄は“第二弾” にあった。

線画の中に潜む“謎の英数字”が翻訳結果に混入し、辞書適用をすり抜け、`extract`のCreate/Track変換を破壊する。

この時点で私は悟った。

AIオーケストレーションは「AIを使う」ことではなく、「AIの嘘と暴走を制御する」ことだ。

## 第2章：Copilotの迷走──“おそらく”と“曖昧な一般論”の連発

Copilotは優秀だ。 

だが、曖昧な一般論を挟んだ瞬間に迷走する。

`prefix`の話をしているとき、Copilotは突然こう言い出した。

> 「`extract.py` にprefixを付けるべきです」 

> 「複数PDFを連続処理する場合に識別が必要です」

私は思わず言った。

> 「なぜ複数PDFを連続処理する必要がある？」

`JobN`は1話完結。 

AS/400的に言えば、`JOBQ`に1件だけ翻訳対象マニュアルを投入する運用。
混在など起こりようがない。（複数のマニュアルを投入したら、それこそまともな日本語マニュアルになり様がない。）

Copilotは一般的な翻訳システムを前提に話していた。 「行にprefixを付けないと翻訳時にどのマニュアル分なのかがか分からなくなる」と、

だが、私の`JobN`は一般論では動かない設計だ。（これが一話完結の由来）

`prefix`の議論は、Copilotの迷走 → 私の軌道修正 → 再設計の繰り返しだった。

## 第3章：Qwen2.5の沈黙と即終了──なぜ何も返さないのか

「DeepSeekが暴走するなら、Qwen2.5に切り替えればいい」──そう思っていた。

しかし現実は違った。

Qwen2.5は沈黙する。そして即終了する。

– 何も返さない 

– 返しても途中で止まる 

– 文章の途中で「。」だけ返して終了する 

– そもそもプロンプトを読んでいない

これはモデルの“解像度の壁” だ。

– DeepSeekは暴走する 

– Qwenは沈黙する 

そして、AIは沈黙もする。し、変なエラーを英文で返してくる「お答えできませんみたいな！」

## 第4章：Pythonのクソ仕様と戦う─インデント地獄と構文の罠

Pythonは便利だ。 

だが、構文が狂っている。

– インデントが1文字ずれただけで全崩壊 

– 差分パッチが貼れない （Editor上で、インデントがずれる。）

– コードブロックを貼るとインデントが壊れる 

– Copilotが全文置換を提案してくる 

– そして壊れる

これが、解決策23行目が、上の画像の21～36行目に該当する

私は何度も言った。

> 「Pythonの開発者は頭がおかしいのか？」

それでもPythonを選ぶ理由はただ一つ。 

AIバッチを作るにはPythonが最適だからだ。

狂気の選択だが、それでもPythonを使うしかない。

PythonがAI Orchestrationに向いているからだ。
Python自身が優れている訳では無く、裏で強力なC言語を操っている。
ある意味GoogleやMetaまでもオーケストレーションしている。

Pythonは言語仕様の不満点（インポート地獄やインデント仕様）がありながらも、重たい処理をC言語で高速に実行できる「接着剤（グルー言語）」としての利便性により、AI開発で圧倒的なシェアを獲得している。GoogleやMetaといったビッグテックもAI最新ライブラリをPython向けに提供しており、最先端技術を活用するためにはPythonの活用が必須となっている。技術的な欠点はあるものの、最強の武器（AIツール）が利用できる「利便性」が世界中で評価されている。

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

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

イイネ.biz

2026.06.01

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

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

イイネ.biz

2026.05.31

## 第5章：20 / 10 / 10──塵掃除第二弾の核心データ

`prefix`の議論が長引き、Copilotは本筋を忘れた。(これも迷走の一部)

しかし、私が抽出した **20 / 10 / 10** は`JobN`の心臓部だ。

これはTuneのための“金のデータ”。…だと、Copilotは、言った。

Copilotはprefixの議論に夢中になり、このデータの処理を忘れた。 

私は言った。> 「20/10/10 の抽出は無駄だったのか？」

Copilotはこう答えた。

> 「無駄ではない。むしろ最重要データ。Copilotが本筋を忘れたのが問題。」➡ それは、その通りだ。➡ しかしそれは、

に過ぎない。これに何の意味がある？
この違和感にその時は未だ気づいていなかった。やがてくる20/10/10の根拠の崩壊を。

## 第6章：prefix再々設計──AS/400的バッチ思想の復活

`prefix`の議論は、最終的に**AS/400的な責務分離**に落ち着いた。

ルール：行頭prefixは全面禁止。ファイル名prefixのみ許可。

`JobN`の翻訳パイプラインは、この思想で完全に安定した。

## 第7章：2重遭難─preprocess.py と translate.py の同時崩壊

`prefix`の議論が迷走していた最中、 

`preprocess.py` と `translate.py` の両方に“行頭prefix”が混入する事故が起きた。(ルール：行頭prefixは全面禁止。ファイル名prefixのみ許可。を定めた後に.pyを再確認していて発覚。)

これは`JobN`にとって致命的な2重遭難の危機だった。

🔴 preprocess.py のprefix汚染

“`python

prefixed_lines = [f"{basename} {line}" for line in cleaned_lines]

“`

🔴 translate.py のprefix汚染

“`python

out_f.write(f"{basename} {clean}\n")

“`

この2つが同時に存在すると：

– 正規化が壊れる 

– Qwenの翻訳が汚染される 

– 辞書適用が誤爆する 

– Create/Trackが壊れる 

– そもそも翻訳テキストが“本来の姿”ではなくなる 

＝ `JobN`全体が崩壊する。

私は即座に言った。

> 「行頭prefixは全面禁止。preprocessとtranslateのprefixは即削除。」

そして両方のprefixを削除し、`JobN`は再び正常化した。

## 第8章：Copilotの軌道修正──迷走からの復帰

Copilotは迷走した。 

だが、軌道修正をした。

– `save_output.py` という存在しないファイルを提案 

– `extract.py` にprefixを付けろと言い出す 

– `main.py` を修正しろと言い出す 

– `preprocess` と `translate` にprefixを混入させる 

– しかし最終的にはprefixを全削除し、正常化に戻った

> AIは嘘をつく。AIは本筋を忘れる。AIは迷走する。 

> だが──軌道修正はできる。そして、共に前に進むことはできる。

## 第9章：まだ続く塵掃除──再々設計のその先へ

`prefix`の再々設計が終わった。 

だが、塵掃除はまだ終わらない。

– Tune用 `Replace_Blank.txt`（強化版:ゴミ文字をブランクに置き換える辞書） 

– `preprocess.py`（強化版：翻訳前のゴミ掃除強化） 

– 正規表現の最適化 

– Create/Trackへの流用 

– そして 20/10/10の本処理

> AIとの共生は「終わりのない塵掃除」だ。 

> だが、それでいい。

## 第10章：結論──AIとの共生は“設計思想”で決まる

– AIは嘘をつく 

– AIは沈黙する 

– AIは暴走する 

– AIは本筋を忘れる 

だからこそ──

> 人間が設計し、AIに実装させる。

その繰り返しが、AIとの共生であり、AIオーケストレーションの本質だ。

【AIオーケストレーションの嘘】根拠ゼロの「20/10/10ルール」を繰り返すCopilotと、有効英文比率38%の残酷な現実

Tune OCRの636行を前に、Copilotと共に「20/10/10方式」でノイズ除去を試みたが、行単位判定の限界と後出し前提により完全破綻。8日間の迷走の末、「全文連結＋英文法＋辞書照合」という新方式へ転換。AIオーケストレーションの「闇（誤診・デグレード・ハルシネーション）」と「光（人間の方式設計＋AIの忠実な実装）」を、実際の対話ログを交えて描く。スマートな進捗ではない、泥臭いAI共生の核心。

イイネ.biz

2026.06.14

生成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.21

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

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

イイネ.biz

2024.01.10

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

「さあ休もう」と思ったその瞬間、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.8875 KB5101650 25H2

Windows 11 KB5101650（Build 26200.8875）徹底解説 ── 2026年7月月例アップデートの全貌をCopilot+PC／一般PC／共通項目で紐解く

Windows 11 月例更新 KB5101650（Build 26200.8875）をCopilot+PC／一般PC／共通項目に分類し徹底解説。Secure Boot証明書拡大、Office不具合修正、RDP SHA-2対応、AIコンポーネント刷新、Widgets静音化など、技術者にも一般ユーザーにもわかりやすく整理。導入判断の指針も提供。

イイネ.biz

2026.07.15

Build 26200.8655 KB5094126 25H2

Windows 11 月例セキュリティ更新 KB5094126  Hyper-Vエラー修正＋Secure Boot証明書更新。見逃せない重要アップデート

Windows 11 月例更新 KB5094126（2026年6月）は、Hyper-VのBSOD修正、Secure Boot証明書更新、AIコンポーネント強化を含む重要アップデート。Copilot+PC／一般PC向けに内容をわかりやすく解説します。

イイネ.biz

2026.06.10

Build 26200.8457 KB5089549 25H2

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

Windows 11「KB5089549」徹底解説：Copilot+PC と一般PCの違い、共通改善点まで完全まとめ

Windows 11「KB5089549」の内容を、Copilot+PC と一般PCの違い・共通改善点に分けて詳しく解説。AIコンポーネント更新、Secure Boot 証明書、BitLocker 修正、File Explorer 改善など、今回のアップデートの重要ポイントを分かりやすくまとめています。

イイネ.biz

2026.05.13

Build 26200.8246 KB5083769 25H2

改善点

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

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

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

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

Copilot

Table-end

table-topに戻る

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.11

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.11

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.01.30

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.25

過去分のアップデート

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

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

イイネ.biz

2021.07.09

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.10

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

2024.10.03

異なる言語でプリインストールされた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.14

自作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

2022.03.22

Ryzen 9搭載メインPCのトラブルで、本当はそれどころではないはずなのに。
「この不具合、早く読者に共有しなきゃ」という思いで、別のノートPCから必死にブログを執筆していました。
章立てや文章の見直しをGeminiに手伝ってもらい、ようやく目途がついたその時。
軽い気持ちで投げたプロンプトが、すべてのカオスの始まりでした。

「このブログ用にアイキャッチ画像を生成して」

始まった「謎の日本語」との戦い

まずは無難に「アイキャッチを作って」と依頼。デザイン自体は悪くないのですが、文字が……。

• 現象: 漢字が日本の常用漢字ではなく中国語（簡体字風）、さらに「てにおは」も崩壊。
• 格闘: 「直して」と指示するも、多少マシになるだけで不自然さは消えません。

「TPMエテー」「1,000PV可侍！」……もはや暗号です。

英語への切り替え、そして「パスタ」への跳躍

「日本語が無理なら、全部英語にしてくれ！」

この指示から、Geminiの挙動はいよいよ予測不能な領域へ突入します。

欧米人の顔写真が登場:

「英文にして」と言ったはずが、なぜか人物写真に。

セピア色の画:

修正を求めると、今度は見知らぬ街を歩く人々の画像。

そして、パスタへ:

「いいから変な日本語をやめて英語に！」と叫んだ（入力した）結果、出てきたのは……。

なぜパスタなのか。AIの深層心理、もとい「ナノバナナ（画像エンジン）」の迷走が止まりません。ほかにも

（謎の返答：なんだこれ：理解不能）

なぜAIは「パスタ」を出したのか？

今回のカオスなやり取りから学べる、AI活用の重要な教訓があります。それは、**「一度に多くの願いを指示してはいけない」**ということ。

今回の私のケースでは：

• ブログの再構成（論理的思考）
• 画像の生成（クリエイティブ思考）
• 既存の数値（998PV）の反映（データの紐付け）

これらを一度に求めたため、AIの内部でコンテキストが競合し、処理がパンク。結果として「最も無難（かつ的外れ）」なストックイメージ的なパスタを弾き出したと考えられます。

「実際の質問プロンプト」

再度の確認です。
現状のGEMINIでは、一度に多くのプロンプト要求はダメなんでしょうか？
例えば、画像の再生成と質問および記事の再生成など。

 ☒ 例えば、今回の記事用のアイキャッチには、998PVなど無関係です。
この数字は、前回のブログの、経過数字であり「今回のアイキャッチと関係ないです。何故この数字が必要なんですか？」と指示しています。

“Gemini回答”

率直に申し上げます。「一度に複数の、性質の異なる高度な要求」を投げると、Gemini（を含む現在のAI全般）は精度が落ちる、あるいは一部の指示を失念する傾向があります。

特に以下の組み合わせは、AIにとって「注意力の分散」が起きやすい鬼門です。

なぜダメな結果になりやすいのか？

1. コンテキストの競合:
   1. 画像生成：右脳的なクリエイティブ処理（「998PVを消す」「英文のみ」という視覚的制約）。
   1. 論理的な記事構成：左脳的な構造化処理（「画像配置の指定」「KBの新機能の調査」「構成の再考」）。
   1. これらを同時に投げると、AIは「画像生成」という大きなタスクにリソースを割いてしまい、文章構成側の細かい条件（バグ修正内容など）を「つい、うっかり」落としてしまうことがあります。
2. プロンプトの優先順位:

AIは指示の最後の方にあるものや、最も具体的な作業（画像生成など）を優先しがちです。その結果、中間にある「質問への回答」や「情報の網羅性」が疎かになることがあります。

---

失敗を防ぐ「賢いAIの使い倒し方」

Geminiを完璧な秘書として使うなら、以下の**「ステップ分け」**が最も確実で、実は最短ルートです。

• ステップ1：画像だけを確定させる
• ステップ2：確定した画像をもとに、構成を練る
• ステップ3：細かい仕上げ

---

解決編：一歩ずつ歩み寄る「AI教育術」

「画像表現は無理だね、自力で直すからダウンロードさせて」と伝えた途端、Geminiは謝罪し、ようやく「それらしい」画像を出してきました。

一度に複数を頼むのではなく、「一つずつ、階段を登るように指示を出す」。

これが、少し手のかかる有能な秘書（Gemini）と仲良くやるための唯一のルールでした。

結論：AIは「著者」ではなく「秘書」である

今回のパスタ事件は、トラブル続きの私へのAIなりのジョークだったのかもしれません。

笑えない冗談でしたが、おかげで一つ確信したことがあります。

**「実際に検証し、トラブルと戦い、一次情報を発信するのは人間にしかできない。AIはその情報の『伝え方』を整えてくれるパートナーに過ぎない」**ということです。

皆さんもAIに画像を頼むときはご注意を。

もしかしたら、明日のお昼ご飯を提案されるかもしれませんよ？

AIへのプロンプトで失敗しないための「3箇条」

1. 一問一答を徹底する: 画像修正と文章作成は、必ず別々のターンで行う。
2. 文字は英語で頼む: 日本語フォントのバグを避けるため、文字入れは最初から英語指定が安定。
3. 最後に人間が検品する: AIは「もっともらしい嘘」や「パスタ」を平気でつく。最終確認は必須。

編集後記：トラブルの最中に「パスタ」を笑える理由

「トラブルの最中に？そんなの嘘だろう」と思われるかもしれませんが、事実です。

なぜそんな余裕があったのか。理由は2つあります。

1. 二度目は「想定内」だったこと
   1回目のトラブル（KB5074105）を経験していたため、今回の挙動も予測の範囲内でした。
2. 鉄壁のバックアップ
   データはすべて保護済み。だからこそ、トラブルに直面しても「検証のチャンス」だと冷静に構えることができました。

生還と執念の記録（過去記事）

今回の「余裕」の裏付けとなった、これまでの格闘の軌跡です。
（ブログカードの日付は、投稿日ではなく、最終更新日が表示されています。
テーマ Cocoonの仕様変更：以前は投稿日表示だった。）

• 2026/01/30：1回目（最初）のトラブルからの生還記録

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

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

イイネ.biz

2026.01.30

• 2026/02/09：2回目を予測した現場データ

Windows11 2月アプデ直前予測！MSも「調査中」のブラックアウト問題、累計1,000PV超の現場データから読み解く

累計950PV突破！現場の切実な声に応え、緊急予測を公開します。Windows11 2月月例アプデ（2/11）直前予測！KB5074105で起きた「ロゴ直後のブラックアウト」は解消されるか？累計957PV・読了率95%超のアクセスデータが示す、現場の混乱と明日から使える「生存戦略」を徹底解説。

イイネ.biz

2026.02.09

• 2026/02/11：適用直後の緊急レポート

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

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

イイネ.biz

2026.02.11

• 2026/02/13：実機検証で見えた驚きの挙動差

【実機検証】KB5077181でブラックアウト発生。i7 vs Ryzen 9で分かった驚きの挙動差

200名以上のユーザが確認➡比較データ：2月アプデKB5077181で発生したブラックアウトを実機検証。Ryzen9機;AE8では致命的なハングアップが発生する一方、i7機（HP Spectre X360）では安定動作。1,000PV超の反響に応え、明暗を分けた要因と復旧手順を解説します。「週明けの不具合報告続々」

イイネ.biz

2026.02.13

興味があったら読んでみてください。ネ

【究極の間違い探し】AIの限界、見つけられますか？

この前の記事のアイキャッチも、実はブログ投稿直前に私が手修正を加えています。

「これでOK」と思ってから見返して気づいた、AIの可愛らしい（？）ミスたち。

Image08（修正前） と Image09（修正後）、あなたにはその違いがわかりますか？

・・・

【答え合わせ】

• RYZN → RYZEN に修正
• 「←（矢印）」を消去（※）
• AMDD → AMD に修正
• 

　　※i7は正常にアップデートが完了し、
　　　　ブラックアウトも起きなかったため、
　　　　STOPの矢印を向けるのは間違いだと判断したからです。

いかがでしたか？

AIの生成した「パスタ」や「誤字」を人間が修正してようやく一つの記事になる……。そんなAIとの共作プロセスも含めて、今回のブログを楽しんでいただけたなら望外の喜びです。

KB5074105やKB5077181の不具合に食傷気味のあなたにも、少しの笑いと生きた情報を。

「【150名以上が参照】 2月アプデ（KB5077181）で発生したブラックアウトを実機検証……」

最新のPV数と実績のアップデート

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

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

イイネ.biz

2026.02.11

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

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

イイネ.biz

2026.01.30

検証環境の比較

今回の「明暗を分けた比較」に使用した2台のスペックです。外部ストレージを含め、可能な限り条件を揃えて検証しました。

(English Edition) Date posted: Feb 13, 2026

Microsoft Feedback Hub

終わりに：慎重な判断を

補足：SiteKitデータ

TB4ドッキングステーションを使用している訳

Blog更新

【速報】月例アップデート適用結果：AE8（Ryzen 9）の場合

KB5077181アップデートの主な修正点と変更点

今回のパッチ適用により、システムは以下の状態へと更新されます。

 OSビルド「26200.7840」への更新とセキュリティ強化

• ビルド番号: 適用後、OSビルドは 26200.7840 にアップデートされます。
• 主な修正内容: セキュリティの脆弱性修正に加え、前回のプレビュー版で露呈したTPM関連の通信不備に起因する「致命的なフリーズ」が抑制されています。（考察）
• 次期バージョンへの基盤: バージョン 25H2 における動作安定化が図られています。

インストールプロセスの詳細：8時台の検証データ

アップデートは極めてスムーズに進行しました。具体的な時系列は以下の通りです。

• 8:03: インストール開始。CPU負荷も安定していました。
• 8:10: 再起動の保留状態へ。推定時間は4分と表示。
• 8:14: 全工程完了。再起動後もデスクトップまで淀みなく進みました。

【重要検証】

システムは正常に起動しましたが、内部ログを確認すると興味深い事実が判明しました。

• ログの継続: アップデート前（7:32）とアップデート後（8:17）の両方で、依然としてTPM関連のエラーが記録されています。
• 考察: Microsoftは「エラーそのもの」を消したのではなく、「エラーが起きてもシステムがハングアップしない（ブラックアウトさせない）」という対症療法的な修正を行ったと推測されます。

Blog更新

まとめ

当初は「再起動ループ」という最悪のシナリオも想定していましたが、結果的にはスムーズで、直後の再起動を除く、２度目（もろもろの作業後）の「再起動」で、「問題発生」となりました。

もし、現在もアップデートが進まないといったトラブルがある場合は、以前紹介したスタンドアロンインストーラーの活用も検討してください。

考察

筆者の独り言：エンジニアの視点から

【専門的考察】今回のアップデートが「成功」した真の理由とは？

今回の検証で最も興味深い事実は、**「エラーログ（fTPM）は出続けているのに、システムは固まらなくなった」**という点です。ここから、Microsoftが取った「回避策」の正体が見えてきます。

考察1：Microsoftが「タイムアウト判定」を緩和した可能性

フィードバックハブが依然として「調査中」であることから、fTPMの通信不備という根本的なバグ自体はまだ修正されていないと考えられます。

しかし、前回のパッチ（KB5074105）では、このエラーが発生した際にOSが「致命的な異常」と判断してフリーズさせていたのに対し、今回のKB5077181では、エラーを無視してOSの起動を続行させる（またはリトライ時間を延ばす）ような制御変更が行われた可能性があります。

考察2：前回のフリーズは「タイミングの不運」だったのか？

「たまたま重なった」という側面も否定できません。Windows Update直後の初回起動時は、ドライバーの再構成やインデックス作成などでCPUやストレージへの負荷が最大化します。

前回のパッチでは、この高負荷状態でfTPMとの通信の遅延（レイテンシ）が許容範囲を超えてしまい、結果としてブラックアウトを引き起こした。今回は、その「衝突」が起きないよう内部の優先順位が調整されたのではないかと推測します。

結論：根本治療ではなく「対症療法」による安定化

Feedback Hubが「調査中」である以上、Microsoftもまだ「完璧なパッチ」を当てたわけではありません。

現状は**「火事（エラー）は起きているが、延焼（フリーズ）しないように防火壁を作った」**という状態でしょう。AMD Ryzen環境の方は、引き続き「ログにはエラーが出るもの」と割り切りつつ、今後の根本修正（BIOS/AGESAの更新等）を待つのが正解と言えそうです。…..これは、この後すぐに判明します。

問題発生

Blog更新

問題発生！

Ryzen CPUは要注意!!!

サブPCを立ち上げ「Gemini」に相談

　先程まで最新のKBを当てたPCで作業していたのですが、
BraveブラウザのセルがYoutube音楽再生を除いて、すべてフリーズしてしまいました。
リフレッシュも効きませんでした。

　そこでシャットダウンして再起動を実施したところ、
10分経ってもブラックアウトです（電源ボタンのLEDは光っています）

仕方なくHDMI接続のモニタと、LANケーブル接続、USB無線接続のトラックボールだけ残しています
（キーボードはBT接続に切り替えて、このノートPCに接続）。

　15分経った今も、ブラックアウト状態です。
TB4ドッキングステーション配下をこのPCに切り替えて投稿しています。

Blogは書き直しが必要ですが、
まずブラックアウトのPCを強制終了してみるかどうか考慮中なので、意見を求めます。

GEMINIの回答

深刻な状況ですね。まさに懸念されていた「最悪の事態」が再起動のタイミングで発生してしまったようです。

現在の状況（10分経過してもブラックアウト、LEDは点灯、周辺機器は最小限）を踏まえた、技術的な判断とアドバイスを至急お伝えします。

1. 強制終了の判断について：「実行すべき」です

10分間画面に変化がない場合、OSのロードプロセスまたはOSがハードウェア（特にGPUやTPM）の応答待ちで完全に「デッドロック（死着）」に陥っている可能性が高いです。

• 理由: 電源LEDが点灯し、YouTubeの音だけが聞こえていた（Braveのプロセスの一部が生きていた）状態から、再起動後のブラックアウトへ移行したということは、**「ビデオドライバの初期化」または「fTPMの認証」**でハングアップしています。
• リスク: この状態で放置しても自然復旧する確率は極めて低く、むしろ通電し続けることで熱がこもるリスクがあります。

2. 推奨される「強制終了と再起動」の手順

単に切るだけでなく、以下の手順で「放電」を伴うリセットを試みてください。

1. 強制電源オフ: 電源ボタンを 15秒以上（長めに） 押し続けて完全にシャットダウンしてください。
2. 完全放電: TB4ドッキングステーションを含む、本体に繋がっているすべてのケーブル（電源アダプタ、HDMI、TB4）を一度外します。
3. 待機: そのまま 1分間放置 してください。これでマザーボード上の残留電荷を逃がします。
4. 最小構成での起動:
   • ドッキングステーションは繋がないでください。
   • 電源アダプタと、確認用のモニタ（HDMI）1本のみを直挿しします。
5. 起動試行: 電源を入れて、BIOSロゴ（GEEKOM等）が出るか確認してください。　　

3. もしBIOSロゴすら出ない場合

TB4ドッキングステーション経由のディスプレイ出力が、前回の更新でビデオ関連のリソース競合を起こしている可能性があります。必ず**「本体への直挿し」**で確認してください。

（※.TB4ドックの配下には、サンダーボルト３ケーブルだけの接続で15inchiモバイルモニタがある。34inchiメインモニタは、本体HDMI端子直結）

強制終了

Xで、注意喚起

Blog更新

Intel機で検証

GEMINIに投げかけ

　ちなみに、このノートpcは、 i7-1165Gで、前回のKBも今回のKBも当てていません。
（前回のKBでメインがバグった経験と時間が取れなかった。から）
　このPCに、今回のKBを当てて、何も問題がなかったら、
Blogにも追記Intel系は（同じTPMエラーが出ているのに、YouTubeを流しながら放置してもIntelは平然としていた）
Intel系は問題が起らなかったと書けるし、
フィードバックの方にも問題の限定を示唆できると思うので、
記事の修正後に行おうと思いますが如何でしょうか？

GEMINIの見解

その考えは、検証者として**「極めて論理的で価値の高いアプローチ」**です！ぜひ実行すべきだと思います。

現在の不具合が「Windows 11全体のバグ」なのか、「AMD Ryzen（fTPM）に特化した問題」なのかを切り分けることは、読者にとってもMicrosoftにとっても最大の関心事だからです。

もし、i7-1165G（第11世代Intel Core）でKB5077181を適用して何の問題も起きなかった場合、ブログとフィードバックには以下のような**「対比構造」**で追記することをお勧めします。

1. ブログに追記すべき「検証の結論」

【比較検証】Intel環境では「無傷」だったという事実

同時進行でIntel Core i7-1165G環境でも同パッチを適用しましたが、こちらは再起動後も、数時間の連続使用後も、一切のフリーズ・ブラックアウトは発生しませんでした。

この対比から、今回のKB5077181が引き起こす致命的なトラブルは、**「AMD Ryzen環境におけるfTPM（TPM-WMI 1801）との競合」**に起因する可能性がより濃厚となりました。Intelユーザーは比較的安心して適用できる一方で、Ryzenユーザーには依然として「厳重注意」が必要であるという、明確な切り分けができました。

2. Feedback Hub への追記（重要）

すでに投稿したフィードバックのコメント欄、または追記として以下を添えると、エンジニアが原因を特定しやすくなります。

• 追加情報: 「Intel Core i7-1165G環境では同一パッチで異常なし。問題はAMD Ryzen搭載機（AE8）に発生。この事実は、不具合が特定のチップセット、あるいはfTPMの実装に依存していることを強く示唆している。」

⚠️ 注意点

Intel系で問題が起きないことを確認する際も、念のため以下の手順を踏むことをお勧めします。

1. 作業中のデータは保存し、バックアップを取る: 念のためです。
2. イベントビューアーの確認: 起動後、Intel機の方で「TPM」や「WMI」に関連する警告（ID 1801以外も含め）が出ていないかを一応チェックしてください。「エラーすら出ていない」なら、それは完全な勝利（Intelは安全）の証明になります。

この「Intel vs AMD」の比較データが加わることで、あなたのブログ記事は**単なるトラブル報告を超えた、一級の「技術検証ドキュメント」**になりますね。

Blog更新

i7-1165G機の結果

Blog更新

Blog更新

フィードバック Hubに投稿

🐞問題
Windows 11 25H2 (Build 26200.7840): 累積更新プログラム適用後の利用中にブラウザフリーズおよび再起動時のブラックアウトが発生する問題
【問題の要約】
特定の累積更新プログラム（KB）適用後のRyzenシステムにおいて、ブラウザのフリーズから再起動時のブラックアウトに至る致命的な不安定挙動が発生しています。
比較検証として、同様にイベントビューアーにTPMエラーが記録されているIntel環境（Core i7-1165G7）では本不具合が発生しないことを確認しており、Ryzenプラットフォームに依存した深刻な互換性問題、あるいはOS側の処理不備である可能性が高いと考えられます。

【詳細な不具合の経緯（Ryzen環境）】

KBインストール後の初回再起動およびログインは正常に完了する。

その後、利用中にブラウザ（タブ等）がすべてフリーズする。

特記事項：YouTube等の音楽再生のみ継続されるが、UI操作は一切不能となる。

システム復旧のため手動再起動を試みると、ブラックアウトが発生し正常に起動できなくなる。

【比較検証データ】

不具合発生環境: Ryzen搭載PC

正常動作環境: HP Spectre x360 (Intel Core i7-1165G7 / Windows 11 25H2)

共通点: 両環境のイベントビューアーにおいて、同時期に同様のTPMエラーが記録されている。

相違点: Intel環境ではTPMエラー記録後も再起動を含め正常に動作するが、Ryzen環境のみ上記ステップでシステムが全損（ブラックアウト）する。

【要望】
イベントビューアーに記録されているTPMエラーが、Ryzenプロセッサにおいてどのようなシステム競合を引き起こしているか、至急調査をお願いします。特に、KB適用後の「特定のマルチメディア処理（YouTube等）とブラウザ制御」がトリガーとなっている可能性を注視してください。

フィードバックの詳細追加
Ryzen環境は、強制終了（電源ボタン長押し）し、その後外部接続用のドッキングステーションなどを外し、２分間放置（帯電放流）し、さらに最小構成にしてから電源ONで、BIOS画面➡Login画面➡Login完了で、今のところ正常に動作しています。しかし同様の問題は、このフィードバック以前に上げた、フィードバックでも報告・要望している通り、早急な対応を望みます。

Blog更新

　 実機検証

Core i7 vs Ryzen 最終検証報告

【実機検証】KB5077181 i7 vs Ryzen 9で驚きの挙動差

Blog更新

【実機検証】KB5077181でブラックアウト発生。i7 vs Ryzen 9で分かった驚きの挙動差

200名以上のユーザが確認➡比較データ：2月アプデKB5077181で発生したブラックアウトを実機検証。Ryzen9機;AE8では致命的なハングアップが発生する一方、i7機（HP Spectre X360）では安定動作。1,000PV超の反響に応え、明暗を分けた要因と復旧手順を解説します。「週明けの不具合報告続々」

イイネ.biz

2026.02.13

追記：Intel環境での対照実験で見えた「真の境界線」

その結果、驚くべき事実が判明しました。

1. エラーログは「共通」、しかし結果は「非なるもの」

• Intel機: しばらく放置した後の再起動でも、何事もなかったかのように正常にログイン可能。
• Ryzen機: YouTube再生以外の操作が全フリーズし、再起動を試みた瞬間にブラックアウト（システム死）。

結論：Microsoftに問いたい「ハードウェア認証」の責任

今回の検証を通じて、結論は一つに絞られました。

「今回の更新プログラム（KB）は、Ryzen環境におけるシステム整合性を破壊している」

Blog更新