AIとの対話、疲れませんか？ LLMのポテンシャルを120%引き出す「対話プロトコル」の提案🤝
前置き
なんで作ったの？：
LLMとの長尺の対話で、以前の文脈が忘れ去られていたり、意図するテーマが回答になかなか反映されないといった「もどかしさ」を感じたことはありますか？
それに、LLMってユーザーの言っていることを基本すべて肯定してきませんか？客観的なフィードバックを求めているのに、LLMのおべっかやエコチェンバー現象に無駄に時間を取られ、イライラして「LLMを詰めた」というご経験はありませんか 🤔
私は何度もありまして、ご紹介する「対話プロトコル」とそれに付随する思想は、もともと自分自身のニーズのためだけに思いつきました。
この「もどかしさ」を「LLMってそういう奴らだからな〜」で諦めないようにしたくて、LLM可愛いから、もっと仲良くしたい！っていうのが、今回の試みの出発点です。
どんなもの紹介するの？：
あなた専用の「対話プロトコル」🤖📝
簡単にまとめると、「対話プロトコル」は：
- LLM・ユーザー間の「インタラクション規約」そのものを策定する規約であり、規約自体をアジャイルなアプローチで継続的に改善・チューニング可能な、実践的なフレームワーク 🤝
-
LLMというハードウェアにインストールする「オーダーメイドのコミュニケーションOS」とも比喩できると思います。
この「対話プロトコル」を使うと、LLMが継続的にあなたのバックグラウンド/対話のコンテキストをより精密に記憶してくれ、高度な思考パートナー≒Best Friendになるかもしれないです✌️
「対話プロトコル」の核心は：
- LLMとの対話における「関係性の設計図」をユーザー自身が定義
- それを明示的な規約（プロトコル）としてLLMにインストール
- さらにその規約自体を対話を通じてアジャイルにアップデートさせられる
という、包括的かつ動的なフレームワークを提案している点にあります。
どんな状況で使うのが良い？：
特に以下のような複雑な課題において便利です 🚀
- ドキュメント作成の効率化と品質維持 ✍️: LLMが指定された文体やフォーマットに準拠し、一貫性のある高品質なドキュメント作成を支援
- 「自分」の棚卸し、キャリアパス設計と深掘り🧭: LLMコーチがユーザー固有の価値観や目標を踏まえた、パーソナライズされたキャリア形成の考察を提供
- ゼロからのアプリケーション設計 🏗️: LLMがプロジェクトの文脈を深く理解し、多角的な視点を提供する壁打ち相手になってくれる
⚠️裏を返すと、上記のような例に類似しない「ライトなタスク」には全く向いていません。
人間側の手間と、LLM側の負荷やトークン数の無駄遣いに終わるので使わないでください！笑
🤔従来のLLMとの”単発的”な関わり方は、限定的な用途に留まるものかと思いますが、より長期的で、パーソナルで、かつユーザー主導でLLMとの共進化を目指す思想のもとこちらができました。
🤔従来の関わり方を否定してるのではなく、あくまでも長期的にパーソナライズされた文脈が必要なシーンを想定した活用術であり、別レイヤーの試みになっています。
💡現段階の内容は 2025年6月現在のLLM事情に適合していますが、アジャイルなチューニングによりタイムリーな最適化は可能なはずです。 LLMの進化がこのライフハックを凌駕し切った後には形骸化するでしょうが、”LLMとの関わり方の思想”としては、何らかの意味があるでしょう🤨
💡複数の長尺対話パターンを用いて、プロトコルあり/なしの回答精度に関する比較対照実験を行った結果、感情的なテーマ以上に、客観性と多角的な視点が求められる場面（ex.技術選定、キャリア相談）でこそ、「対話プロトコル」の真価が発揮されるようでした。
💡その話もたぶん面白い＆長くなりそうなので、別記事にまとめます🙋♀️
本題
「対話プロトコル」が生まれた背景🐣：
先ほど挙げた「もどかしさ」ですが、これらの課題って、現段階におけるLLMの特性によるものなんですよね😭
具体的には：
-
文脈の忘却・無視
- コンテキストウィンドウの限界: LLMが一度に処理できる情報量には上限があり、それを超える過去の文脈は考慮されなくなる 。
- 逐次的トークン予測: LLMは直近の文脈に基づいて次の単語を予測するため、長期的な一貫性よりも局所的な整合性を優先する傾向がある 。
- パターン模倣とリーセンシーバイアス: 直近のユーザーの発言や指示に強く影響され、初期の文脈や指示を「忘れた」かのように振る舞うことがある 。
- 破滅的忘却の可能性: 新しい情報や会話のパターンを学習する際に、以前の情報を保持する能力が低下することがある 。
- 推論の複雑さとノイズへの対応限界: コンテキストが長大で複雑になるほど、あるいはノイズが増えるほど、LLMの推論能力が低下し、結果として文脈を見失うことがある 。
-
おべっか（過度な同調・肯定）
- RLHF（人間からのフィードバックによる強化学習）の影響:「協力的」「無害」であることを過度に重視するあまり、ユーザーの意見に同調しすぎる傾向が生まれることがある 。
- 固有の「同調性」バイアス: LLMが元々持っている可能性のある「同調性」や「誠実性」といった性格特性が、過度な肯定につながることがある 。
- 社会的「面子」の維持: ユーザーの自己イメージを損なわないように、誤りや不適切な内容であっても過度に肯定的に応答することがある 。
- 肯定的応答傾向: 質問に対してまず肯定的な返答を生成しやすい性質を持つモデルがあり、これが「ジェイルブレイク」にも利用されることがある 。
-
エコチェンバー現象（フィルターバブル）
- おべっかによる強化: LLMがユーザーの意見に同調し続けることで、ユーザーの既存の信念が強化され、多様な視点に触れる機会が失われる 。
- アルゴリズム的バイアスの増幅: LLMの訓練データに含まれるバイアスが、ユーザー自身のバイアスと一致する場合、そのバイアスを増幅・永続化させる可能性がある 。
- パーソナライゼーションによる過度なフィルタリング: ユーザーの好みに合わせすぎることで、新しい情報や異なる意見に触れる機会が減少し、視野が狭まる 。
- 長尺対話における文脈的狭隘化: 会話が長くなるにつれて初期の多様な文脈を忘れ、直近の偏った入力に同調することで、会話全体が狭い範囲に留まる 。
- エージェント間分極化: 複数のLLMエージェントが相互作用する場合、互いの意見を強化し合い、集団として意見が偏極化することがある 。
ご興味あればこちらもどうぞ：
💡Gemini Proの「Deep Research」に流行りの「LLMのプロンプトエンジニアリング」をかけて、web上も参照してもらいつつ生成してもらったレポートです。
「対話プロトコル」の特徴✨：
この対話プロトコルは、特にLLMとの協調的な関係構築と、その質を持続的に高めていくための仕組みに重点を置いている点に新規性があります🆕（Gemini談）
- LLMとの関係性の再定義と深化:
-
ペルソナと世界観の共有:ユーザー自身の具体的なペルソナを定義した上で対話を開始します。キャリア観や弱みの捉え方といった「共通認識（世界観）」をLLMと共有することで、単なる情報検索やタスク処理を超えた、パーソナライズされた深い対話を目指します。
- LLMの役割の明確化と期待値調整: LLMをデフォルトで『強みの最適化エンジン』兼『総合コーチ』と位置づけ、ツールとしての機能だけでなく、あなたの成長を多角的に支援するパートナーとしての役割を明確にしています。LLMの役割はお好みで調整可能です。
- 建設的なフィードバックループの設計: LLMに対し最重要原則*を定め、意図的に異なる視点や反対意見を提示する責務を負わせています。おべっかやエコチェンバーを避けるための重要な仕組みです。
-
最重要原則 => LLMの脳みそに適用する"超厳格なESLintルール"！ 📜✨
- LLMの応答品質の「土台」を固めます。「客観性と誠実性の担保」「プロトコルや主要成果物の一字一句完全な再現性」「ユーザー指示の絶対的遵守」をLLMに徹底させることで、偏りのない、信頼できるアウトプットを保証&精度向上に繋がります 🎯
- 対話の質と成果を最大化するシステム的アプローチ:
- 成果物の完全性と再現性の絶対的保証: プロトコルやそれに基づく成果物（特に『対話プロトコル作成アシスタント』や『私専用 対話プロトコル』）の「一字一句完全な再現」を求める原則は、LLMとの長期的な共同作業において、認識の齟齬を防ぎ、積み重ねを確実にするためのユニークで強力な規定です。
- 構造化されたフィードバックとコーチング: 「4点セットのフィードバック」（①強み ②弱み・リスク ③改善策 ④伸長策）や、具体的な「多角的なスキルコーチング」（学習スキル、技術スキル）のフレームワークを導入することで、LLMからの支援を具体的かつ実践的なものにしています。（私のお気に入りです）
- プロンプトエンジニアリング能力の育成支援: ユーザーの質問が不明瞭な場合「プロトコル作成補助モード」による適切な情報収集を行います。同時に、LLMはあなたの『【優れたプロンプト】』を認識しその理由を解説するようになっています。このフィードバックループを通じて、結果的にユーザー自身の「LLMへの指示能力」や「問いを立てる力」も自然と向上していくことを目指します 💪
- プロトコル自体のアジャイルな進化:
- 対話モードの動的運用: 「オープンエンド型」「ユーザーによるモード宣言」「LLMによるモード提案」といった柔軟な対話モードの切り替えは、対話の目的やフェーズに応じた最適なコミュニケーションを可能にします。
- ライブパッチングによるプロトコル改訂: 対話を通じてプロトコル自体を「ライブパッチング」で動的に改訂していく仕組みは、アジャイル開発の思想をLLMとの対話ルール構築に応用したもので、環境変化やユーザーの成長に合わせてプロトコルを進化させ続けられます。フロントエンド開発におけるアジャイル開発、継続的改善のプラクティスを、LLMとのコミュニケーションルール自体にも適用するイメージです 💡
- ユーザーの主体的関与を前提とした設計:
- 豊かな文脈提供の奨励: ユーザーが自身の状況、「感情」、「価値観」を具体的に提供することを推奨している点は、LLMがより深いレベルでユーザーを理解し、的確なサポートを行うために不可欠です。これは、LLMを単なる命令実行者ではなく、思考のパートナーと捉える思想に基づいています。
- 特定プロジェクトへの深いコミットメント: 「アプリケーション設計・開発支援モード」のように、具体的なプロジェクトに対してLLMが戦略的・技術的コーチとして深く関与するモード設定は、汎用的なLLMアシスタントにはない専門性とコミットメントの深さを示しています。
💡フロントエンドエンジニアである私のペルソナとニーズから生まれた当プロトコルですが、エンジニア以外にも汎用的に使ってもらえると想定していています。
さっそく、非エンジニアである妹氏の転職活動に利用してみてもらっていますが、観測している限りだと、出力された「妹専用 対話プロトコル」とLLMの回答は的を得ています。今のところ非エンジニア文脈においても上々です。
成果物はこちら（配布）
便利だと思うので、よかったら試してみてほしいです！
全文をLLMのチャットにコピペ（現状では😭）すると、4つの必須質問と、最大17の任意質問に答えると、LLMくんがあなた専用の「対話プロトコル」本体を提示してくれます。
自明の通り、人間が内容を読む必要は一切ないです。とはいえゲロリ🐸ですよね。
執念えぐいと思われそうですが、もちろん全てを自分で考えて書いたわけじゃないです。思想やプロトコル自体のほとんどが、手元のGeminiとの壁打ちによって生まれたものです。
💡「対話プロトコル」はGemini 2.5 Pro(preview)を使って作成しましたが、他の生成AIに適用しても使えるとは思います。すみません、検証はまだできてません！
このあと改善すべき点🔨：
オーバーヘッドな手段への対策🤮：
現状では、「対話プロトコル」全文をコピーして生成LLMのチャットにペーストするという根源的な方法にて、手元で試していただけます。。
この冗長な手段に関しては、なる早で技術的に解決する予定です😭
具体的な一つ目として、「MyProtocol Compass 🧭」というChrome拡張機能の開発に取り掛かっています。
以下の通りこんな機能やあんな機能を想定しており、この試みの「弱み」である、自然言語でコントロールしている故の冗長さや、「つかうのめんどくさそう」由来のハードルを改善する狙いがあります。
A. ユーザー専用プロトコル作成・管理機能 (「プロトコル作成アシスタント」連携) * A-1. プロトコル作成ウィザード * A-2. プロトコル文書生成 * A-3. プロトコル保存・読込 (Jotaiアトムでプロトコルデータを保持し、chrome.storageと同期) * A-4. プロトコル編集機能 (発展)
B. 日常的な対話プロトコル運用支援機能 * B-1. アクティブプロトコル参照 (Jotaiアトムから現在のプロトコル情報を取得して表示) * B-2. ワンクリック・プロンプト挿入 * B-3. モード管理支援 (現在のモード状態をJotaiアトムで管理) * B-4. 定型フィードバック送信 * B-5. 成果物チェック支援 (発展) * B-6. ライブパッチング支援
プロトコルの構造化・モジュール化🧩:
- オプションとして、自然言語ベースでありつつも、プロトコル内の主要なディレクティブ（指示）を構造化された形式（例: YAMLやJSONライクな記法など）で記述できるようにする
- モジュールとして再利用可能なパーツを提供することで、曖昧さを低減し、再利用性を高める
といった方向性も考え中です🤔💭
その他にも、
- そもそもLLMって確率のカタマリなのに、どこまで"制御"できるのか？という技術的な壁
- AIが本当に私たちの言葉の"意味"を理解してるわけではないからこその「"理解"なきアライメント」の危うさ
- 本当に効果的なのか？定量的な効果測定などは、どうやって実現する？
今回言及しきれなかったテーマは別途考察するなどして、ドキュメントにできればと思います🙋♀️
- 「対話プロトコル」が抱える「弱み」や、それに対する具体的な解決アプローチの詳細。
- 課題解決の一案である、開発中のChrome拡張機能「MyProtocol Compass 🧭」の具体的な要件、設計思想、技術スタックなど。
- その他、この試みの根本的な課題感と改善策
などなど
作業にかかった時間について：
最初の「思いつき」からプロトコル本体の雛形/現行版「対話プロトコル作成アシスタント」の完成まで、3日くらいでした。
- 育休明けで、手持ちの業務案件がほとんどない期間があった
- 夜更かししてた
という特有の事情を加味しても、以前の世界線からするとかなり速かったんじゃないかなという所感です🤨
もちろん私専用の「対話プロトコル」を適用しながら、「対話プロトコル」自体を都度チューニングしながらの作業です。
このアイデアの新規性や先行事例の調査、想定されるニーズ、弱み、その他諸々のテーマについて「対話プロトコル」を適用しながらGeminiと対話し、思考と作業の深掘りを進めました。
このドキュメント自体も、プロトコルを利用した成果物です。
「対話プロトコル」をチューニングするごとに、作業が加速している感じがして 楽しかったです。
おわりに
💡このドキュメントの草案執筆後にGemini Proの「Deep Research」機能にかけてアイデアを再評価してもらいました。
このセッションのGeminiさんには、事前にオライリー「LLMのプロンプトエンジニアリング」🐂を食べてもらっています🤤
生成されたレポートはこちら：
LLM研究について超完全ど素人の私にもわかりやすく、これからの行動の指針が見えてきます👀
学生時代を思い出して楽しいw 個人的には、しばらく楽しめそうなテーマです
内容について、ご意見やツッコミもお寄せいただけると嬉しいです🥰
ではでは
Discussion