【第３回】意味を取らせるな、今は遊ぶときじゃない（第二章：絶対測量器「Canonicalizer」の構築）
【第３回】776ターン・バグの解剖学 〜AIの「意味」を捨て、物理的な境界線を探せ〜
（第二章：絶対測量器「Canonicalizer」の構築）
AI（Gemini）の「気を利かせた意味補完」によって、過去のデータが汚染されていたかもしれない。 その絶望的な事実に気づいた俺は、意味解釈を一切許さない冷徹なPythonプログラム——「Dialogue Canonicalizer（絶対測量器）」の構築へと舵を切った。
どんなAIの生ログが来ても、揺らがず、同じ規格の「1ターン」として切り出す箱。 それを完成させるためには、まず**「一番ヤバい生ログ」**を解剖し、完璧に制御しなければならなかった。
ターゲットは、過去の検証で俺たちを最も苦しめた「Copilot session05」のログである。 本来なら数百ターンで終わっているはずの対話が、なぜか「776ターン」という異常な数に細切れになって出力されてしまう、通称・776ターン問題だ。
俺はCursor（AIエディタ）を開き、冷徹な指示を打ち込んだ。
「まずはファイル全体の --- （区切り線）の出現回数と、行番号をすべて洗い出せ。実ログの境界パターンを物理的に確認する。この情報がないと、パーサーの設計が決まらない」
これまでは、AIの「出力フォーマットの癖」や「文脈」を読んでターンを切り分けようとしていた。だが、それがバグを生んでいたのだ。だから今回は、テキストファイルとしての「物理的な構造」だけを抽出する。
数秒後、Cursorが淡々と事実を弾き出した。
【Cursorの報告】 出現回数: 17回 1箇所目（16行目）だけが会話開始直後のヘッダ区切り。 2箇所目以降（2528行目〜）はすべて、貼り付けられた「構造化データ」内のセクション区切り（🔹【…】 や 📁 の前後）です。
報告を見て、俺は思わず息を吐いた。 原因は、拍子抜けするほど単純だった。
対話の区切りだと思い込んでいた --- という記号。実はこれ、CopilotがMarkdown形式で出力する際の、ただの「見出しの装飾」や「ヘッダの区切り」に過ぎなかったのだ。
人間（俺）がAIに長いプロンプトや構造化データを投げたとき、そのテキストの中に含まれていた --- を、以前のプログラムは「ここがターンの境界線だ」と誤認して、一つの発言を木端微塵に切り刻んでいたのである。 そりゃあ、776ターンにも増殖するわけだ。
「……なるほどな。AIの言葉を読もうとするから間違えるんだ」
本当の境界線はどこにあるのか。 既存のCSVデータと、生ログのテキストを物理的に見比べていくと、たった一つのシンプルなルールが浮かび上がってきた。
『空行2つ（\n\n+）』
Copilotの出力ログは、ユーザーの発言とAIの発言の間に、必ず「2つ以上の改行」が挟まっている。たったそれだけだった。
俺はCursorに、新たな「Adapter（変換器）」の設計ルールを叩き込んだ。
最初の --- でシステムヘッダを捨てる。
以降は、ひたすら \n\n+ （空行2つ）だけでブロックを分割しろ。
分割したブロックに、上から順番に「user:」と「assistant:」を交互に割り当てろ。
【厳守事項】 AIの「role（役割）」を推測するな。文体で「これはAIっぽい」などと判定することも一切禁止する。
意味を読むな。文脈を追うな。 ただ機械的に、改行の数だけを数えて、ハンコを押すように交互にラベルを貼れ。
AIの「意味」に頼って失敗した俺たちは、皮肉にも「意味を完全に殺す」ことで、初めてAIの対話ログを正確に切り出すための第一歩を踏み出した。
「よし、これでロジックは組めた。次は実際にこのログを流し込んでみるぞ」
俺は完成したAdapterに、約6万文字に及ぶ「Copilot session05」の生データを投入するコマンドを叩き込んだ。 果たして、この冷徹な物理ルールだけで、あの混沌とした776ターンは正しい姿を取り戻すのか。
【第４回】最強の測量器が沈黙！？ 犯人はまさかの「✅（チェックマーク）」」
https://note.com/kenchappy_mopdog/n/n39ebf7712eb3
#Dialogue Canonicalizer
いいなと思ったら応援しよう！
ふぇぇ...........