「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の「クソ仕様」で0件虚無。20万行のXML解析でエラーすら出さずに人間をサイレントに騙す ElementTree の罠

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にコードを相談し、返ってきた答えをエディタに貼り付ける。

この一連の作業をボタン一つで自動化できる技術、それが「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