AI orchestration
Thank you for reading this post, don't forget to subscribe!「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」方式が提案された。**
第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の沈黙を招く。全文を繋ぎ、英文法で判定する——これが唯一の正しい方式だと。**
第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共生のために
### 20/10/10が破綻した理由
| 問題点 | 具体的な内容 |
|——–|————–|
| 行単位判定 | 636行はOCRが勝手に切った断片。英文構造が破壊される |
| 後出し前提 | 「大文字傾向」を最初に言わなかった |
| 根拠のない断言 | 「40行で十分」に統計的根拠はなかった |
| MECE破綻 | 抜け、重複、矛盾、後出し、誤前提のオンパレード |
### 新方式（全文連結＋英文法）の正当性
| 利点 | 具体的な内容 |
|——|————–|
| 英文構造を保持 | 行単位ではなく、文単位・段落単位で処理 |
| OCR依存からの解放 | 英文法という普遍的なルールを使用 |
| 誤除去の最小化 | 辞書＋英文法の二軸で安全に判定 |
| Qwen沈黙の防止 | 翻訳前テキストを「英文として認識可能」に |
### 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日までの実際の対話ログに基づいて執筆されています。一部を編集・要約していますが、技術的事実と対話の本質は保持しています。装飾や美化は意図的に排除し、「リアル」を優先しました。**
