--- title: [AI共創]で解決 #1：長文対話でのAIの忘却・サボりを防ぐプロトコル設計 tags: #プロトコルエンジニアリング #生成ai #プロンプトエンジニアrング #コンテキストエンジニアリング #ハーネスエンジニアリング author: [田栄人](https://docswell.com/user/eitoatsuta) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/P7XQRDZ1EX.jpg?width=480 description: 「AI共創」を実務レベル（要件定義、開発、ブレスト等）で導入した際、長文の対話を重ねるうちにAIが初期指示を忘れてしまったり、回答の粒度が粗くなって当たり障りのない一般論（AIポエム）ばかりを返す「文脈崩壊（Context Drift）」に直面していませんか？ 本スライド資料では、世間に溢れる耳障りの良い「お気持ち重視のAIファンタジー（プロンプトポエム）」を冷徹に否定し、スタンフォード大学の研究などで明かされているLLMの演算特性「Lost in the Middle（中央での注意の減衰）」の数理モデルを踏まえ、人間側の「ハンドリング（操縦力）」によってAI共創の手戻りを最小化する「プロトコルエンジニアリング（PE）」の手法を解説します。 ▼ スライドの目次（タイムライン） ・導入：AI共創における「静かな崩壊」（ルールの忘却とサボりの実態） ・第一章：長距離走になった途端、対話が破綻する技術的背景 ・第二章：巷の「劣化サマリーの入力」や「スレッドコピペ」が進化に逆行する理由 ・第三章：なぜ文字数が増えるとAIはサボるのか？（Lost in the MiddleのU字曲線） ・第四章：プロトコルエンジニアリングによる制御 - ① 対話状態の同期（ステート管理とメタ対話の挟み方） - ② 構造による制御（TOMLやMermaidなどのデータブロックによるアテンションの強制確保） ・結論：共創の質を決めるのは、AIの賢さではなく人間の「設計能力（プロトコル設計力）」 --- ━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📌 [AI共創]で解決：1ソース・マルチメディア・ショーケース━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 同じテーマを、あなたの好むスタイル（読む・見渡す・聴く・観る）で体験できます。すべてのコンテンツが同期・一元管理された 「本家マニフェストページ」はこちら：👉 https://atsutaeito.github.io/protocol-engineering-manifesto/2026/07/15/pains01-context-drift.html 【各メディアへの直接リンク】📖 読む（Note記事）：https://note.com/8fieldsplanning/n/n56bde65ba241 📊 目で見渡す（Docswellスライド）：https://www.docswell.com/s/eitoatsuta/K27WG7-01-context-drift 🎧 耳で聴く（AI音声・YouTubeポッドキャスト）：https://youtu.be/6ZgtbVK2yqw 📺 観る（AIスライド解説動画）：https://youtu.be/M5nCb8TLokk 🔗 プロトコルエンジニアリング公式サイト：https://atsutaeito.github.io/protocol-engineering/about_ja.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━ published: July 15, 26 canonical: https://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... # 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ポエム」へ劣化。 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/LJ3W8522J5.jpg) 誤った処方箋：巷の「対策」が効かない理由 ① AIによる自己要約 (Auto-Summary) AI再解釈による情報の劣化 ■ 長大な履歴の要約をAI自身に委ねるアプローチの罠。 ■ AIのフィルターを通ることで、人間の熱量や意図のニュアンスが削ぎ落とされる。 ■ 結果として重要な条件が欠落し、AIが得意な「無難な一般論」で上書きされる。 ② 新規スレッドへのコピペ (Thread Reset) 対話資産の破棄と技術進化への逆行 ■ バグを回避するためにスレッドをリセットし、前提指示を入力し直す手作業。 ■ 議論で積み上げた「対話資産」を引き継ぐ心理的・実務的コストの増大。 ■ 数百万トークンを扱える最新アーキテクチャの進化に対する明白な逆行。 # 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] # 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: 思考の分断・手戻り ③ Protocol Engineering 制御アプローチ / Control Method: 論理的なシステムハンドリング データ形式 / Data Format: 構造化データ (TOML / Mermaid) AIの注意の所在 / AI Attention Locus: 末尾（アテンション最高地点） 最終的な出力 / Resulting Output: 設定の完全順守と資産の継承 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/27VVRLGM7Q.jpg) 実装①：対話状態の同期 (State Managementとメタ対話) [Meta-Dialogue Checkpoint] [Meta-Dialogue Checkpoint] [State 1: アイデア出し] -> [State 2: 要件定義] -> [State 3: 構造化] ■ ロードマップの事前定義: 対話開始時にプロセス (State) を定義し、現在地をシステムに読み込ませる。 ■ メタ対話（対話についての対話）の強制: 数ターンごとに、現在の処理コンテキストをAI自身に確認・出力させる。 > いま私たちはどのStateにいますか。 > 次のStateに進むための前提条件は満たされていますか。 > 現在の状況をシステム観点から出力してください。 # 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 = "State 2: 要件定義" [confirmed_rules] format = "JSON" tone = "プロフェッショナル" # 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% # 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