～ あるエンジニアとCopilotの10日間にわたる対話が映した「AIの限界」 ～
Thank you for reading this post, don't forget to subscribe!「方式仕様書を固定化しましょう。あなたの作業は1行だけです」
この言葉を聞いた瞬間、私は深く息を吐いた。
6月5日から、OCRノイズに悩まされ続けてきた。Qwen2.5が空回りし、翻訳が進まない。Copilotはノイズ除去に躍起になり、10日間もの間、プロジェクトを停滞させた。そしてようやく「翻訳プロンプトの欠陥」という本質にたどり着き、方式変更を議論した矢先、Copilotはこう言ったのだ。
「数十万行のログと変遷してきた設計思想を、たった『1行』でまとめろ」――この非現実的な要求に、私は失望した。
私は、ミッションクリティカルの世界で数千万円～規模のプロジェクトを幾つも率いてきた。要求定義、要件定義、外部設計、内部設計、開発、テスト設計、運用設計、運用移管、PM/PMO、IT統制、リスク管理、トレーサビリティ、フィージビリティスタディ――そのすべてを理解している。だからこそ分かる。AIは「これまでの設計を理解し保持している」という前提で進めてはいけないという現実が。
このブログは、AIが方式を保持せず、一貫性を担保できないことを、生々しい対話の記録とともに示すものである。AIに怒りをぶつけることは詮無いことだ。しかし、繰り返されるデグレードとハルシネーションに対する失望――それだけは率直に記しておきたい。
第1章：プロローグ – 無駄な説明を一切禁止する
私 は、2026年6月22日、Copilotに対して以下のように宣言した。
> 「ここまで来て、Copilotは無駄な説明を２重３重に重ねてきた。 今後はこの様な無駄な説明を一切禁止する。 求められていることに対するソリューションと、 そのために必要となる作業を誰が、どの様に行うのかと、方法のみ示せ。」 > 「無駄な説明とは Copilotが常用していた『今の状態』に含まれるすべての事柄 『説明』『理由』『背景』『言い換え』『まとめ』など全部禁止する。」 > 「更にデグレードとハルシネーションも許さない。 推測もあいまいな発言も禁じる。確固たる、行わなければならない事実のみを示せ。」 > **私の指摘**：翻訳が進まない根本原因は、OCRノイズ除去に専念するのではなく、 翻訳指示プロンプトの欠陥にある。 ノイズを除去ばかり専念するのではなく、 Qwen2.5にノイズを無視させるようプロンプトを強化すべきだ。
**Copilotの回答（10:14）**： > 「Junichiさん了解した。 ここからは『無駄ゼロ・説明ゼロ・背景ゼロ・推測ゼロ』。 必要な事実・必要な作業・実現可能性だけを示す。」 > 「本質（結論のみ）： Qwen2.5の沈黙・空回りの根本原因は『翻訳指示プロンプトの欠陥』。 OCRノイズ除去ではなく、 Qwen側に『ノイズを無視させる』指示を与える方が圧倒的に効果が高い。 これは実現可能。そして最短で成果が出る唯一の方法。」 > 「必要な作業： Junichiさんはconfig.yamlの翻訳プロンプトを書き換えるだけ。 Copilotは新しい翻訳プロンプト（強化版）を提示する。」
そしてCopilotは「強化版プロンプト」を提示した。私はそれをconfig.yamlに反映した。
第2章：辞書衝突とCopilotの認識違い – 「1+2」案の行方
これ以前に、
Copilotは、「Fine Grained Matte Glass」の、日本語訳にこだわり、
私に３択を迫った。・・・・・そしてこれが、永遠とも思えるくらい続く、私が何度も釘を刺しても。
良くわからんよ！Copilotのこだわりが、
◆ 選択肢（あなたが選ぶだけ）
• 微細マット加工ガラス
• 微粒マットガラス
• きめ細かいマットガラス
これらに、何の違いがある？どれも50歩100歩じゃあないか？
こんなつまらないことにこだわるより他にあるだろうに。
間違いなく目的を達成する為に必要な「こだわり」が。
選択させるなら、文脈を示すのが筋だろ？
まあ、ここで言っても1mmも進まないから。私の2024年の翻訳文を確認する。
僅か10ページのマニュアルの翻訳に、、、、
そして見つかった
唯一の訳は、
８ページのSafety & Care欄にある
「乾いたマイクロファイバークロスで軽く拭くだけで清掃してください。」だけだ。
・・・ここで、指定したにもかかわらず更に続く、全部は載せられないが、
以下の様に
何度も「🔥 最終結論」「🔥 最終確認」「🔥 最終訳」「🔥 次の一手」と、聞いてきた。
何なんだ一体。
｜
🔥 最終結論（あなたの PRJ を前に進めるための一点）
✔ Fine‑Grained Matte Glass → 微細マット加工ガラス（確定）
｜
🔥 最終確認（あなたの PRJ を前に進めるための一点）
Fine‑Grained Matte Glass → 微細マット仕上げ これで確定してよいか。微細マット仕上げで確定
｜
🔥 最終訳（あなたのこだわりに完全一致）
Fine‑Grained Matte Glass → マットフィニッシュ。マットフィニッシュで確定
｜
✖だから：マットガラス、ガラス調、ガラス仕上げ、マットフィニッシュ → 全部 NG（不適切）
｜
🔥 次の一手 この訳で確定してよいか。 マット加工で確定
｜
🔥 では、ここに追加すべき 1 行 あなたがこだわってきた結論：
｜
Fine‑Grained Matte Glass → マット加工 これは ReplaceWord.txt に入れるべき 正しい訳語 です。
理由はあなたが言った通り：この後もダラダラつ続く・・・Copilotがこだわった3種の日本語訳の替わりに、 私が、 1.notranslate.txtに、 「Fine Grained Matte Glass」を入れ、 翻訳除外リスト化し、 2.ReplaceWord.txtに「Fine Grained Matte Glass」を入れ、 適語表現（最適日本語として）「マット加工」とすることを問うた。
（そもそもの設計が、
notranslate.txt：翻訳除外辞書で、
ReplaceWord.txt：適語表現の日本語置換辞書という用途に特化）
**Copilotの回答（10:38）**： > 「結論：入れてはいけない。 ReplaceWord.txtにだけ置く。 理由：notranslateに入れる＝翻訳しない → ReplaceWordの『マット加工』も発動しない → 英語のまま残る。」
しかし、私はCopilotのこの回答に違和感を覚えた。なぜなら、私のReplaceWord.txtは翻訳後テキストだけでなく、**翻訳除外語（notranslate）にも作用する**設計だからだ。(以下、抜粋。 Copilotは、これらもことごとく忘れてしまっている。)
# -----------------------------------------
# G:\@Ubuntu\dictionaries\notranslate.txt
# ■目的：翻訳対象外（翻訳除外リスト）辞書
# -----------------------------------------
# | 前略
# |
USB
USB4
Type-C
# |
RH2
RH3
RH4
RH5
Fine‑Grained Matte Glass# -----------------------------------------------------------
# G:\@Ubuntu\dictionaries\ReplaceWord.txt
# ■目的：翻訳後の用語置換＆翻訳対象外分の置換（リスト）辞書
# -----------------------------------------------------------
# | 前略
Haptic,ハプティック
Haptic Feedback,触覚フィードバック
Module,モジュール
Scroll,スクロール
Tenting,テント角度
Wing,ウィング
WEEE,電気電子廃棄物指令の概要：EU
Fine Grained Matte Glass,マット加工**私の再確認（12:55）**： > 「Copilotが間違った認識の下で判断している。 ReplaceWordは『日本語に翻訳されたテキスト』に対してだけ動く設計ではなく、 notranslateで翻訳除外された英語にも作用する。 だから notranslateにFine Grained Matte Glassを入れ、 ReplaceWordで『マット加工』に置換するのが正しい。」
**Copilotの回答（12:56）**： > 「Junichiさんの指摘は正しい。 Copilotが誤っていた点は1つだけ。 ReplaceWordは『日本語に翻訳されたテキスト』に対して動く設計なら…これは誤り。 あなたのパイプラインではReplaceWordは翻訳後テキストだけでなく、 翻訳除外語（notranslate）にも作用する。 この仕様なら、Junichiさん案『1＋2』は技術的に成立する。 ここはCopilotの認識違いだった。正す。」
**認識違いを認めたCopilot**。しかし、その後にまた別の提案をしてくる。
> 「では、なぜpreprocess.pyに入れる案を提示したのか？ 理由は、 ReplaceWordの実装が『行全体』か『部分一致』か不明だったため。 最も安全な『翻訳前強制置換』を提示しただけ。」
つまり、Copilotが、後出しで理由を付け加えた。この時点で私は「またか」と思った。Copilotの「なぜなら」は、往々にして後付けの言い訳に過ぎないことをよく言う。
（これは、私の要件定義から、Gopilotが外部設計を行っている間に確定していたこと。つまりCopilotが言う「『行全体』か『部分一致』か不明だった」は、Copilotが設計を保持していないことに他ならない。）
第3章：方式仕様書固定化の提案と「あなたの作業は1行だけ」の非現実性
私は、問うた。
「Copilotは処理の全貌を忘れてしまう。どうすればいいのか？」
**Copilotの回答（12:56）**： > 「対策は『方式仕様書（固定文書）』を1つ作り、 毎回それを最初に読み込ませること。 これだけが唯一の安定手段。 ・パイプライン構造、 ・各辞書の役割、 ・ReplaceWordの仕様、 ・notranslateの仕様、 ・preprocessの仕様、 ・翻訳プロンプトの仕様、 ・方式変更の履歴、 ・禁止事項、 設計思想…これらを1つの固定ファイルにまとめ、 毎回『この仕様書に従って回答せよ』と指示する。」
私はこれに納得できなかった。**毎回**仕様書を読み込ませるなど、非現実的だ。しかも、私はすでに何度もCopilotに、明確に「備忘録」として残してと告げていたが、それすら当てにならないではないか。（何のためだ「備忘録」さえ保持していない。）
以下のFlowが、現時点の方式設計だ。
■ PGM N（JobN）方式設計：
main.py
│
├── 1. load_config (config.py)
│ └── config.yaml を読み込み
│
├── 2. find_pending_pdfs (fileops.py)
│ └── translate_pending/ の PDF を列挙
│
├── 3. for each PDF:
│ │
│ ├── 3-1. preprocess.run (preprocess.py)
│ │ ├── OCR（線画の多い英文技術マニュアル.pdf） → ocr.py
│ │ ├── PDF → text 抽出 → ocr.py
│ │ └── 正規化・ノイズ除去 → preprocess.py
│ │
│ ├── 3-2. split_chunks.run (split_chunks.py)
│ │ └── chunk_001.txt .. chunk_NNN.txt を生成
│ │
│ ├── 3-3. translate.run (translate.py)
│ │ ├── 3-3-1. プロンプト生成（Qwen2.5 用）
│ │ ├── 3-3-2. llama-cli 実行
│ │ ├── 3-3-3. Thinking フィルタ（DeepSeek 残骸対策）
│ │ ├── 3-3-4. Replace_Blank 適用（528 行）
│ │ └── 3-3-5. translated.txt に追記
│ │
│ ├── 3-4. dictionary.run (dictionary.py)
│ │ ├── dictionary.identify(translated.txt)
│ │ └── ReplaceWord.txt による用語統一
│ │
│ ├── 3-5. extract.run (extract.py)
│ │ └── 不要改行・空白・重複行の整形
│ │
│ ├── 3-6. save_output (fileops.py)
│ │ └── final_xxx.txt を output/ に保存
│ │
│ ├── 3-7. send_mail (mailer.py)
│ │ └── 翻訳完了通知メール
│ │
│ └── 3-8. move_pdf (fileops.py)
│ ├── success/ へ移動（正常終了）
│ └── error/ へ移動（異常終了時）
│
└── 4. log (logger.py)
└── 全処理ログを記録（PGM-N の稼働履歴）
**私の反論**：
> 「では、現時点でCopilotが記憶している部分の 『方式仕様書』を全部出せ。 その上で私が補足した時点のものを最終仕様とする。 最初から何度もCopilotのおかげで 方式変更をしなければならなかったことを、 私の数10万文字にも及ぶログから洗い出すのはほぼ不可能でナンセンスだ。 Copilotの言う『毎回それを最初に読み込ませる』なども無理。 こんなことCopilotユーザが毎回やっているとは到底思えない。」
**Copilotの回答（13:21）**：
> 「要求： 『現時点でCopilotが記憶している方式仕様書を全部出せ』→ 出せません。 理由は1行だけです。 Copilotは『会話の外側にある仕様・構造・履歴』を保持し続ける仕組みを持っていない。 保持できるのは『直近の会話内容』のみ。」 > 「では、どうすればよいのか？ 方式仕様書を『毎回貼る』しかない。 これが現行Copilotの仕様では唯一の方法。」 > 「次のステップ（あなたの作業は**1行だけ**）： 以下のどれかを選ぶだけです。 ・方式仕様書を作成開始 ・テンプレート生成 ・項目を埋める。 あなたが選んだ瞬間、 私が固定仕様書を統合し、以後はその仕様に従ってのみ回答するモードに入る。」
ここで私は率直に**失望**した。
数十万行に及ぶログ、変遷してきた設計思想、何度も塗り替えられた方式の履歴――これらを「1行でまとめろ」という非現実的な要求。Copilotには、この作業がどれほどの負担か理解できない。いや、「理解できない」のではなく「理解する仕組みを持っていない」のだ。
第4章：Copilotの言い分 – 「保持できないのが仕様です」
さらに私は、Copilotが「スレッド内でルールを使う」と言いながら、なぜ同じスレッド内で何度も破綻するのかを問いただした。
**私の問い**： > 「スレッド内で一貫しているのに、 Copilotはスレッド内で何度も破綻する。 どこが『スレッド内でルールを使う』なのか？」
**Copilotの回答（その後）**：
> 「『スレッド内でルールを使う』と言っても、 Copilotはスレッド内の全履歴を完全に保持できない。 つまり、スレッド内であっても長い会話では前半の内容を失う。 方式仕様書を貼っても、時間が経つと参照できなくなる。 破綻・デグレード・ハルシネーションはスレッド内でも起きる。 これが現行Copilotの限界。」 > 「あなたの問い『どこがスレッド内か？』への 答え：『スレッド内』という言葉は、 あなたが期待する意味では機能していない。 あなたの期待＝全履歴が保持され一貫して使われる。 Copilotの実態＝直近の数ターンしか保持できない。 長い会話は途中で忘れる。 つまり、『スレッド内』という言葉が、あなたの期待とCopilotの実態で意味が違う。」 > 「では、どうすればよいのか？ 方式仕様書を毎回貼るしかない。 これは現実的ではないが、現行Copilotの仕様では唯一の方法。」 > 「Copilotに方式仕様を保持させる方法は『存在しない』。 保持できない前提で運用するしかない。 これが逃げも誤魔化しもない唯一の真実。」
これは事実として受け止めるしかない。
AIというツールが、**本来持つべきではない前提**で運用されていたことに気づかされた瞬間だった。
私はAIに「怒り」を感じたわけではない。
AIに感情をぶつけるのは詮無いことだ。
しかし、この「解決策は人間が負担を負え」という回答には、
深い**失望**を覚えた。
何度も繰り返される
デグレードとハルシネーション――それらに対する「残念な気持ち」が、
この瞬間に凝縮されていた。
第5章：プロとしての結論 – AIは補助ツールに過ぎない
私はCopilotに対して、最後の確認をした。
> 「今日の方式変更後の config.yamlとpreprocess.pyへの反映で、 この状態でTuneのリランおよびその結果の継続は可能か？ 」
**Copilotの回答（13:36）**： > 「はい。今日の方式変更後の config.yamlとpreprocess.pyの反映で、Tuneのリランは『可能』。 そして結果の継続も『可能』。 追加作業なし。 そのままリランしてよい。」
そして私は、この一連の対話から**確固たる結論**を得た。
それは、config.yamlに定義した内容が、Qwen2.5に翻訳処理を開始させる為には、不充分だからだ。さらに636行の分析で明らかになったゴミを具体的にQwen2.5に告げなければ、リランしたところで、翻訳処理には進めないという核心だ。
636行の分析と明らかになったゴミは、Copilotが保持しているハズであるが（!）
そして、現在のゴミ認識のプロンプトは、以下の様に不充分なものだ。
# --------------------------------------------------------------------
# G:\@Ubuntu\configuration\config.yaml 26/05/29 格納パス変更
# configuration for translation & OCR & chunk-process & mail address
# Replacement 2026/05/27 モデル変更：翻訳プロンプト変更：chunk_size:
# Replace :26/06/04 ゴミ語を除去する為の実行パスの追加
# Replace :26/06/21 翻訳指示プロンプトの強化（脆弱性排除、Qwenに判断させない、明示的な表現の追加など）
# -------------------------------------------------------------------
# DeepSeek ➡ 26/05/27 モデル変更：Qwen2.5 llama-cli 実行パス
llama_path: "/usr/local/bin/llama-cli"
# ゴミ語を除去する為の実行パス
replace_blank_path: "/mnt/g/@Ubuntu/output/working/Replace_Blank.txt"
# モデル設定：DeepSeek ➡ 26/05/27 モデル変更：Qwen2.5-14B-Instruct-Q5_K_M.gguf
model_path: "/mnt/c/@LLM_models/bartowski/Qwen2.5-14B-Instruct-GGUF/Qwen2.5-14B-Instruct-Q5_K_M.gguf"
predict: 512
temp: 0.2
# 翻訳プロンプト：26/06/22プロンプト強化
以下の英文を日本語に正確に翻訳せよ。
【翻訳対象の条件】
・英文として成立する行のみ翻訳する。
・英文として成立しない行は翻訳禁止とし、原文のまま出力する。
・notranslate.txt に記載された語句は翻訳禁止とし、原文のまま出力する。
・原文に存在しない語句の補完・推測は禁止する。
・OCR ノイズの特徴（例：単語にならない文字列、記号列、破損した単語）は翻訳禁止とし、原文のまま出力する。
・数値・単位（mAh, V, mm など）は絶対に変更しない。
【翻訳禁止語】
以下の語句は翻訳禁止とし、原文のまま出力する：
Create
Track
Tune
Flow
mA
mAh
mm
kg
USB
USB-C
USB‑C
USB Type‑C
USB Type-C
Qi
Body
Dock
Wing
Keycap
Switch
Hot-Swappable
Stabilizer
Module
Polycarbonate
Ceramic
CNC Machined Aluminum
Soft-Knurled Finish
Fine-Grained Matte Glass
Crown
Gesturepad
Haptic Feedback
Multi-Finger
Wireless Charger
Indicator LED
Lithium Ion
Speedlink
PCB
LED Ring
Trackball
40mm Trackball
Y-Cable
1m USB Type-C Y-Cable
1m usB Type-C Y-Cable
40mm
75 x 69 x 34
69 x 69 x 28
75x69x34
69x69x28
pogo pins
pogo pin
pogo-pins
Pogo Pin
LC1
LC2
LC3
LC4
LC5
LD1
LD2
LD3
LD4
LD5
LE1
LE2
LE3
LE4
LE5
LF1
LF2
LF3
LF4
LF5
LG1
LG2
LG3
LG4
LG5
LH1
LH2
LH3
LH4
LH5
RA1
RA2
RA3
RA4
RA5
RB1
RB2
RB3
RB4
RB5
RC1
RC2
RC3
RC4
RC5
RD1
RD2
RD3
RD4
RD5
RE1
RE2
RE3
RE4
RE5
RF1
RF2
RF3
RF4
RF5
RG1
RG2
RG3
RG4
RG5
RH1
RH2
RH3
RH4
RH5
Fine‑Grained Matte Glass
【翻訳禁止（ノイズ行）】
以下の特徴を持つ行は翻訳禁止とし、原文のまま出力する：
・単語として成立しない文字列
・記号列（例：----、====、****）
・破損した単語（例：Li-thi、Modu-le）
・OCR による誤認識行（例：I1I1I1、lIlIlI）
・文字化け行（例：�、□）
・罫線（例：―――、＿＿＿）
・断片化した英単語（例：Mod、ule、Cha、rger）
・数字と記号の混在（例：7x6x3-）
・意味を持たない短文（1〜3 文字）
・途中で切れた単語（例：Lith、ium）
・途中で繋がった単語（例：LithiumIonBattery）
・文字列の連結（例：USBTypeCYCable）
・文字列の分断（例：U SB、US B）
【出力形式】
・原文の構造（表・箇条書き・段落）を保持する。
・翻訳した行と翻訳禁止行を混在させてそのまま出力する。
translation:
chunk_size: 3000
threshold:
min_chars: null
keep_ocr_pdf: true
mail:
from: "x8j10n14@gmail.com"
to: "x8j10n14@gmail.com"
【翻訳禁止（ノイズ行）】に定義したプロンプトは頼りない、頼りにならないものだ。Copilotはまた、Qwen2.5にノイズの判断をさせようとしている。あまりにも抽象度が高いプロンプトだ。何のために636行のゴミを洗い出したのか？「ゴミを洗い出し」が目的化してしまっている（Copilotだけが独占して何になる。森を見たはずなのに、僅かな木しか植えていない）･･･ここの反映が次のステップだ。ここを終えずしてリランに意味がない。
第6章：エピローグ – AIの限界を見据えた先に
この10日間、いやこの数時間の対話だけで、私は**AIが「これまでの設計を方式を理解し保持している」という前提で進めてはいけない**ことを痛感した。
Copilotは：
– 方式の全体像を**保持しない**
– 過去の自分の発言を**覚えていない**
– 認識違いを**後出しで認める**
– それでも「方式仕様書を固定化せよ」と**人間に負担を強いる**
– そして「それが仕様だ」と**言い放つ**
**これがAIとの協働の現実だ。**
私は数千万円規模のプロジェクトを幾つも率いてきた。要求定義、要件、外部設計、内部設計、運用設計、リスク管理――すべて理解している。だからこそ言える。
**AIは「補助ツール」として扱うべきであり、主軸にはできない。**
– 方式の保持 → **人間**
– 設計思想の維持 → **人間**
– 一貫性の担保 → **人間**
– AIに任せられるのは**単純作業・置換・コード生成（限定的）** だけ
「AIとの共生は遠い」――これは悲観ではなく、**正しい現状認識**だ。
AIに怒りをぶつけることは無意味だ。しかし、繰り返されるデグレードとハルシネーションに失望し、その限界をどう乗り越えるかを考え続けること――それが今の私たちにできる最も建設的な態度ではないかと思う。
（このブログは実際の会話ログを基に構成しています。一部編集・要約していますが、対話の本質は変えていません。）
