---
title: [AI共創]で解決 #1：長文対話でのAIの忘却・サボりを防ぐプロトコル設計
tags:  #プロトコルエンジニアリング #生成ai #プロンプトエンジニアrング #コンテキストエンジニアリング #ハーネスエンジニアリング  
author: [田栄人](https://image.docswell.com/user/eitoatsuta)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/P7XQRDZ1EX.jpg?width=480
description: ■■■ スライドの概要（こんなお悩みありませんか？） ■■■ ChatGPTやClaudeなどの生成AIを使っていて、「対話が長くなるとAIが最初の指示を忘れる」「決めたルールを無視して、当たり障りのない無難な一般論を返し、サボり出す」という不具合に直面していませんか？  このスライドでは、耳障りの良い「AIポエム（お気持ち重視のAI共創ファンタジー）」を完全に否定します。 AIの忘却やサボりを「人間のハンドリング（操縦ルール）」でスマートに解決し、実務の手戻りを最小化する新技術「プロトコルエンジニアリング（PE）」の具体的な解決策を、初心者にも分かりやすく図解します。  ▼ スライドの目次と、解決する「AIのバグ」 1. 【導入：AI共創のバグ】長い対話でAIが指示を忘れる・サボる実態 2. 【第一章：なぜ忘れるのか？】ChatGPTが長距離走の対話でルール無視を起こす原因 3. 【第二章：NGな対策】巷の「会話を要約し直す」「新規スレッドへコピペする」がダメな理由    - ①AIに要約を任せると、大切なニュアンスが削られ一般論に劣化する    - ②新規スレッドへのコピペは、これまでの対話資産を捨てる進化への逆行 4. 【第三章：技術的な真犯人】AIが長文の「真ん中」を読み飛ばす現象（Lost in the Middle） 5. 【第四章：プロトコルエンジニアリングによる解決策】    - ① 対話状態の同期（事前に進め方を決め、途中で「今どこのステップ？」とAIに確認させるメタ対話）    - ② 構造でAIの注意力を強制ロック（平坦な要約ではなく、TOMLなどの軽量な構造化データを会話の末尾に置くヒント） 6. 【結論】AI共創の質を決めるのは、AIの賢さではなく人間の「設計能力（操縦スキル）」  ---  ■■■ よく検索される、この課題のキーワード（SEO・AIO対策） ■■■ AI共創 / ChatGPT / Claude / 生成AI / 指示を忘れる / ルールを無視する / キャラ崩壊 / AIがサボる / 長文会話 / 会話が長くなる / コンテキスト / Lost in the Middle / 対症療法 / プロンプト / プロトコルエンジニアリング / 解決方法 / 対策  ---  ■■■ このテーマに関する関連コンテンツ（1ソース・マルチユース） ■■■ 同じソース（原稿）から、あなたの好むスタイル（読む・目で見渡す・聴く・観る）で体験できるように同期配信しています。  👉 すべてのコンテンツが同期・一元管理された「本家マニフェストページ」（Jekyll）はこちら： https://atsutaeito.github.io/protocol-engineering-manifesto/2026/07/15/pains01-context-drift.html  📖 【読む】詳細なテキストで思想と技術を深掘りする（Note記事）： https://note.com/8fieldsplanning/n/n56bde65ba241  🎧 【耳で聴く】AIホスト2人による知的でリアルな対談（YouTube音声・ポッドキャスト）： https://youtu.be/6ZgtbVK2yqw  📺 【観る】スライドと音声ナレーションが同期した解説（YouTube動画）： https://youtu.be/M5nCb8TLokk  🔗 プロトコルエンジニアリング公式サイト（Jekyll）： https://atsutaeito.github.io/protocol-engineering/about_ja.html
published: July 15, 26
canonical: https://image.docswell.com/s/eitoatsuta/K27WG7-01-context-drift
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/P7XQRDZ1EX.jpg)

AI共創が「長い対話」で崩壊する理由と、忘却・サボりを防ぐ設計 | プロトコルエンジニアリング_ Lost in the Middleの克服と、構造化データによるLLM制御の実践 [target] : Advanced Prompt Engineers / AI Practitioners [concept] : Protocol Engineering / State Management / TOML [status] : // INITIALIZING CONSOLE...
【SEO・AIO用解説＆キーワード】
解説： 本スライド資料は、「AI共創」を実務で進める際、会話が長くなるとAIが指示を忘れてサボりだす不具合（文脈崩壊・Lost in the Middle）を、人間側のハンドリングによって解決する技術「プロトコルエンジニアリング」の解説です。
キーワード： AI共創 / プロトコルエンジニアリング / 指示を忘れる / AIがサボる / 解決方法 / 対策 / 生成AI / ChatGPT / Claude / プロンプト

# Page. 2

![Page Image](https://bcdn.docswell.com/page/37K9RX8M7D.jpg)

症状：長距離走における「文脈崩壊」と知性のフラット化
 ■ 最新の[LLM]は数十冊分の[コンテキスト]を処理可能だが、実務では十数ターンで破綻する。
 ■ 指示の忘却、ルールの無視、無難な一般論への逃避（[サボり]）。 
■ 共創のエンジンが、対話の長さそのものによって静かに崩壊していく現象。 Turn 01 (High Precision) [System] 指示: 「出力はMarkdown形式で、要点のみ」 [AI Output] 鋭い具体案と厳格なMarkdown構造。 Turn 10 (Rule Forgetting) [System] 初期ルールの忘却開始 [AI Output] 丁寧な挨拶文が復活し、指定フォーマットが崩れ始める。 Turn 20 (Context Collapse) [System] 知性のフラット化（サボり） [AI Output] 一般論のみを語る「AIポエム」へ劣化。
【SEO・AIO用解説＆キーワード】
解説： ChatGPTやClaudeを相手に長い対話（長文会話）を続けていると、最初の数ターンは指示を完璧に守っていたAIが、次第にルールを忘れて挨拶を復活させたり、当たり障りのない「AIポエム（一般論）」ばかりを返し、サボりだす現象（文脈崩壊）の具体例です。
キーワード： ChatGPT指示忘れる / Claudeルール無視 / AIがサボる / 長文会話 / 会話が長くなる / 文脈崩壊 / キャラ崩壊 / AIポエム / 挙動がおかしい / バグ

# Page. 3

![Page Image](https://bcdn.docswell.com/page/LJ3W8522J5.jpg)

誤った処方箋：巷の「対策」が効かない理由
 ① AIによる自己要約 (Auto-Summary) AI再解釈による情報の劣化 ■ 長大な履歴の要約をAI自身に委ねるアプローチの罠。 ■ AIのフィルターを通ることで、人間の熱量や意図のニュアンスが削ぎ落とされる。 ■ 結果として重要な条件が欠落し、AIが得意な「無難な一般論」で上書きされる。 
② 新規スレッドへのコピペ (Thread Reset) 対話資産の破棄と技術進化への逆行 ■ バグを回避するためにスレッドをリセットし、前提指示を入力し直す手作業。 ■ 議論で積み上げた「対話資産」を引き継ぐ心理的・実務的コストの増大。 ■ 数百万トークンを扱える最新アーキテクチャの進化に対する明白な逆行。
【SEO・AIO用解説＆キーワード】
解説： AIの忘却対策としてよく語られる「会話履歴の要約（サマリー）の再入力」や「新規スレッドへのコピペし直し」の矛盾。自分で要約せずにAIに要約を任せると、大切なニュアンスが削られ一般論に劣化します。また、新規コピペは対話資産を捨てる手間が生じ、数百万トークン扱える生成AIの進化に逆行しています。
キーワード： 会話履歴の要約 / サマリー / コピペし直し / 新規スレッド / 解決策 / 対策 / 劣化 / 手間 / 対話資産の引き継ぎ / AIの進化

# Page. 4

![Page Image](https://bcdn.docswell.com/page/8JDKMDZ6EG.jpg)

Protocol Console 根本原因：Lost in the Middle (中間情報の忘却) 
■ スタンフォード大学の研究 (Liu et al., 2023) が証明した[LLM]の「注意の偏り」。
 ■ 入力情報の冒頭と末尾（直近）の認識精度は極めて高い。
 ■ 情報が肥大化すると、中央部分に埋もれた情報への[アテンション]（重み付け）が急激に減衰し、事実上無視される。 
■ つまり「要約テキストを途中で再入力する」行為は、最もアテンションの低い中央部に劣化情報を積み増す愚行である。 [Retrieval Accuracy] [Forgetting Zone] [0%] Start [50%] Middle [100%] End [Context Position]
【SEO・AIO用解説＆キーワード】
解説： AIが長文対話で指示を無視する最大の原因は、スタンフォード大学の研究で証明された「Lost in the Middle（中央情報の忘却）」という演算特性です。LLMは情報の「最初」と「最後（直近）」は強く認識しますが、会話が長くなって「真ん中」に埋もれた指示は、アテンション（注意の確率）が急激に落ちて無視してしまいます。
キーワード： Lost in the Middle / スタンフォード大学 / 注意の偏り / アテンション / U字曲線 / 忘却 / 真ん中を読み飛ばす / 中間情報の無視 / 数理的特性

# Page. 5

![Page Image](https://bcdn.docswell.com/page/VEPKRXYZ78.jpg)

パラダイムシフト：従来型ハック vs Protocol Engineering
 ① AI要約 (Auto-Summary) 制御アプローチ / Control Method: AI依存のブラックボックス データ形式 / Data Format: 平坦な自然言語 (Flat Text) AIの注意の所在 / AI Attention Locus: 中間部 (Lost in the Middle) 最終的な出力 / Resulting Output: ニュアンスの欠落・ポエム化 
② コピペ再起動 (Thread Reset) 制御アプローチ / Control Method: 人力による手作業 データ形式 / Data Format: 平坦な自然言語 (Flat Text) AIの注意の所在 / AI Attention Locus: 冒頭のみ 最終的な出力 / Resulting Output: 思考 of 分断・手戻り 
③ Protocol Engineering 制御アプローチ / Control Method: 論理的なシステムハンドリング データ形式 / Data Format: 構造化データ (TOML / Mermaid) AIの注意の所在 / AI Attention Locus: 末尾（アテンション最高地点） 最終的な出力 / Resulting Output: 設定の完全順守と資産の継承
【SEO・AIO用解説＆キーワード】
解説： 従来の「お願いプロンプト（人力コピペやAI任せの要約）」と、本スライドで提唱する「プロトコルエンジニアリング（論理的システムハンドリング）」の違い。平坦な自然言語を捨て、TOMLなどの構造化データを用いて会話の「末尾（注意力が最も高い位置）」に配置することで、AIの指示順守率を劇的に向上させます。
キーワード： プロンプトエンジニアリング 限界 / プロトコルエンジニアリング / 構造化データ / TOML / アテンションロック / 操縦 / 制御 / 設計 / 対比 / 解決


# Page. 6

![Page Image](https://bcdn.docswell.com/page/27VVRLGM7Q.jpg)

実装①：対話状態の同期 (State Managementとメタ対話) [Meta-Dialogue Checkpoint] [Meta-Dialogue Checkpoint]
 [State 1: アイデア出し] -&gt; [State 2: 要件定義] -&gt; [State 3: 構造化] 
■ ロードマップの事前定義: 対話開始時にプロセス (State) を定義し、現在地をシステムに読み込ませる。
 ■ メタ対話（対話についての対話）の強制: 数ターンごとに、現在の処理コンテキストをAI自身に確認・出力させる。 &gt; いま私たちはどのStateにいますか。 &gt; 次のStateに進むための前提条件は満たされていますか。 &gt; 現在の状況をシステム観点から出力してください。
【SEO・AIO用解説＆キーワード】
解説： プロトコルエンジニアリングの具体的な解決策①：対話状態の同期。対話開始前に「どのような手順（ステート）」で共創を進めるか定義を読み込ませ、途中で「今どこのステップ？」とAI自身に確認させる「メタ対話（プログラムの生存確認のようなもの）」を挟むことで、AIの脱線とサボりを未然に防ぎます。
キーワード： 対話状態の同期 / ステート管理 / メタ対話 / 事前定義 / 進め方 / ロードマップ / 脱線防止 / 手戻り最小化 / ハンドリング

# Page. 7

![Page Image](https://bcdn.docswell.com/page/5JGLMX8X7L.jpg)

実装②：構造化データによるアテンションの強制ロック • 平坦な「テキストの要約」を捨て、視覚的な境界線を持つ「データブロック」を構築する。
 • Anthropic公式も推奨する構造化。XMLやJSONより軽量で機械可読性の高いTOMLを採用。
 • LLMの数理的な注意は、自然言語よりも明確な構文を持つ構造化データに対して強くロックされる。 Flat Text Prompt - Bad これまでの設定はJSON形式で、プロフェッショナルなトーンで... TOML Structured Prompt - Good [state_history] current_step = &quot;State 2: 要件定義&quot; [confirmed_rules] format = &quot;JSON&quot; tone = &quot;プロフェッショナル&quot;
【SEO・AIO用解説＆キーワード】
解説： プロトコルエンジニアリングの解決策②：構造によるアテンションの強制ロック。平坦な長文プロンプトを捨て、視覚的な境界線を持つ「TOML形式」などの構造化データを用います。AIの数理的な注意（アテンション）は、平坦な自然言語よりも、明確な構文と境界線を持つデータブロックに対して圧倒的に強く固定されます。
キーワード： 構造化プロンプト / 構造化データ / TOML / XMLタグ / JSON / アテンションロック / データの境界線 / 視覚的 / テキスト要約の否定

# Page. 8

![Page Image](https://bcdn.docswell.com/page/47QYR895EP.jpg)

Protocol Console 統合：数理的弱点を突くアテンション・ハック 
● 最大の弱点（中央の谷）を回避：過去の決定事項を軽量なTOMLに格納し、常にプロンプトの「直近（末尾）」に再配置する。 
● アテンションの掛け算：「末尾（位置の優位性）」×「構造化データ（形式の優位性）」により、アテンションを強制的に確保。 
● AIは知能が低下しているのではなく、入力形式がLLMの演算アーキテクチャに適合していなかっただけである。 [Retrieval Accuracy] [Mathematical Attention Forcing] [TOML Block] Start / 0% Context Position End / 100%
【SEO・AIO用解説＆キーワード】
解説： AIの数理的弱点を突く「アテンション・ハック」。AIが忘れる中央の谷（Lost in the Middle）を回避するため、決定事項を軽量なTOMLに格納し、注意力が最も高まる会話の「末尾（直近）」に再配置します。「位置（末尾）」×「形式（構造化）」の掛け算によって、AIは能力を落とさず完璧に指示を維持します。
キーワード： アテンションハック / 数理的弱点 / 構造化データの優位性 / 直近 / 会話の末尾 / 入力形式 / 演算アーキテクチャ / 解決 / コピペ不要

# Page. 9

![Page Image](https://bcdn.docswell.com/page/KE4W82XVJ1.jpg)

EOF：共創の質を決めるのは「設計能力」である 
● 「AI共創」の本当の価値は、AI自身の賢さ（ベースライン性能）には依存しない。 
● 人間側がシステムに対して、いつ、どのプロトコルで、どう同期（ハンドリング）するかというルール設計能力に帰結する。 
● AIを優しく「お守り」するのをやめ、State Managementと構造化データによる「操縦」へ移行せよ。 
● プロトコルエンジニアリングこそが、空疎なAIファンタジーを現実の実務へと着地させる唯一の解である。 root@protocol-engineer:~# exit [series] : AI共創で解決シリーズ#1 [process_terminated] : SUCCESS
【SEO・AIO用解説＆キーワード】
解説： スライドの結論。AI共創の成否は、AIの頭の良さではなく、人間がシステムに対して「いつ、どのルール（プロトコル）で同期し、どう操縦（ハンドリング）するか」というルール設計能力に帰結します。AIを「お守り」するポエムを捨て、プロトコルエンジニアリングによって実務に着地させよ、という宣言です。
キーワード： AI共創の価値 / ルール設計能力 / 同期 / ハンドリング / 操縦 / お守り / プロトコルエンジニアリング / 結論 / 実務着地 / EOF

