複数のLLMの間でAI対話の文脈をつなぐ方法
AIを一つだけ使う人はますます減っています。
アイデアを素早く整理する時はChatGPTを使い、複雑な構造を深く検討する時はClaudeを使えます。最新の資料を探したり複数の出所を比較する時はGeminiやPerplexityがより適している可能性があり、別の視点が必要な時はGrok、Copilot、DeepSeek、Mistralのようなツールを選ぶこともできます。
各LLMは互いに異なる強みを持ちます。
ユーザーは一つのAIにすべての作業を任せるよりも、状況に応じてより適したAIを選ぶようになります。
問題はユーザーの思考は一つの流れとしてつながりますが、AIの対話はサービスごとに分離されるという点です。
思考はつながりますが対話ウィンドウは互いにつながりません
一つのプロジェクトを複数のAIで進める状況を考えてみます。
- ChatGPTで問題を定義し方向を定めます。
- Claudeで構造と例外条件を深く検討します。
- Geminiで関連資料と別の視点を探します。
- Perplexityで根拠と出所を確認します。
- Copilotや別のツールで実際の実装を進めます。
ユーザーの立場ではすべて同じ作業です。
しかしそれぞれのAIは別の対話ウィンドウと別のサービスの中に存在します。ChatGPTで決定した基準をClaudeは知らず、Claudeで整理した例外条件をGeminiは引き継げません。
AIを変えるたびにユーザーは以前の状況を再び説明する必要があります。
コピーして貼り付けるだけでは不十分です
最も単純な方法は以前の対話をコピーして新しいAIに貼り付けることです。
短い対話ではこの方法が機能する可能性があります。しかし作業が長くなるほど問題が生じます。
- どの部分をコピーすべきか再び判断する必要があります。
- 長い原文の中で重要な決定と仮のアイデアが混ざります。
- すでに破棄した選択肢が新しいAIに再び伝達される可能性があります。
- ユーザーが最終的に採用した基準が何か明確ではありません。
- 対話が長いと新しいAIの入力限度を不必要に消費します。
- 新しい対話を始めるたびに同じ整理作業を繰り返す必要があります。
原文をすべて移しても思考の流れが正確に伝わるわけではありません。
必要なのは以前の対話全体ではなく、これまでどのような問題を扱い何を決定しどこから引き継ぐべきかについての文脈です。
要約だけ伝えても重要な文脈が消える可能性があります
長い対話を短く要約して伝達する方法もあります。
しかし単純な要約には次の情報が抜けやすいです。
- なぜこの問題を始めたか
- どのような選択肢を比較したか
- どのような条件のため特定の方向を除外したか
- 最終判断の基準は何だったか
- まだ解決されていない問題は何か
- 次の対話で直接引き継ぐべき地点はどこか
結論だけ伝えれば新しいAIは結果は知れてもその判断が作られた過程を理解しにくいです。
その結果すでに検討した選択肢を再び提案したり、ユーザーが確定した基準を揺るがす回答が出る可能性があります。
複数のLLMを使うほどユーザーが文脈管理者になります
AIサービスが分離されているためユーザーが直接文脈を管理する必要があります。
ユーザーは新しい対話を始めるたびに次を繰り返します。
- 現在進行中の作業を説明します。
- 以前に決定した内容を再び整理します。
- 除外した方向とその理由を伝えます。
- 現在残っている問題を伝達します。
- 新しいAIが文脈を正しく理解したか確認します。
AIを変える理由はより良い助けを受けるためですが、実際にはAIの間の文脈をつなぐのに多くの時間を使うことになります。
複数のAIを使う能力よりも複数のAIの間で思考を失わない能力がより重要になっています。
5BYがつなごうとするのはアカウントではなく思考の流れです
5BYは複数のAIサービスを一つの画面にまとめようとするツールではありません。
各AIは既存のサービスと対話ウィンドウでそのまま使います。ユーザーは作業に適したAIを自由に選択できます。
5BYがつなごうとするのはAIサービスそのものではなく、その中で形成されたユーザーの思考です。
このために重要な役割をするのがAnchorとHandoffです。
Anchorはこれまでの流れを残す基準点です
Anchorは一つの対話で形成された重要な文脈をユーザーが直接基準点として残す機能です。
Anchorには単純な最後の回答ではなく次の対話で必要な流れが含まれる必要があります。
- 現在解決しようとする問題
- これまで確認した事実
- ユーザーが選んだ方向
- 守るべき基準と条件
- 除外した選択肢と理由
- まだ解決されていない問題
- 次に引き継ぐ地点
ユーザーは対話全体をコピーする代わりに、これまでの思考をつなぐための座標を残せます。
Handoffはその基準点を別のAIの新しい対話につなぎます
HandoffはAnchorに残された文脈を新しい対話で使えるように伝達する過程です。
例えばChatGPTでプロジェクトの方向と基準を整理した後Claudeでより深い検討をつなげられます。
新しいAIに最初からすべての内容を再び説明する代わりに、以前の対話で確定された文脈を出発点として提供することです。
Handoffの目的は回答をそのまま複製することではありません。
新しいAIが次の内容を理解した状態で作業を始めるように支援することです。
- ユーザーが何をしようとしているか
- これまでどのような判断をしたか
- 何を変えてはいけないか
- どの問題から引き継いで扱うべきか
AIが異なってもユーザーの基準は維持される必要があります
複数のAIを使う過程で最も危険なのは回答の表現が変わることではありません。
ユーザーがすでに定めた基準が対話が変わるたびに消えることです。
一つのAIでは単純さを優先すると決めたが、別のAIが複雑な構造を提案する可能性があります。以前の対話では特定の機能を除外すると決めたが、新しい対話ではその機能が再び核心的な提案として登場する可能性があります。
新しいAIが間違っているのではなく以前の判断を伝達されていないために生じる問題です。
Handoffが適切に機能するには単純な主題要約よりもユーザーの決定と保存すべき基準が明確に伝達される必要があります。
各AIの強みを使いながらも同じ作業をつなげられる必要があります
複数のAIを使う目的は一つのAIを別のAIに完全に置き換えることではありません。
各AIの強みを必要な瞬間に活用することです。
- アイデアが必要な時は発想に強いAIを使います。
- 複雑な論理が必要な時は分析に強いAIを使います。
- 最新の根拠が必要な時は検索に強いAIを使います。
- 実装が必要な時はコード作業に適したAIを使います。
ツールは変わってもユーザーのプロジェクトと思考は継続してつながる必要があります。
5BYはユーザーがAIを変えるたびに再び最初に戻らないように、以前の対話で作られた基準点を新しい対話の出発点につなごうとします。
つながるべきなのは対話原文ではなく判断の文脈です
すべての対話内容をそのまま伝達するのは効率的ではありません。
重要なのは次のAIが作業をつなぐのに必要な文脈です。
- どのような問題が重要か
- 何がすでに決定されたか
- どのような制約を必ず守るべきか
- 何はまだ確定していないか
- 次の作業はどこから始めるべきか
この情報が維持されればAIが変わってもユーザーは同じ思考を継続的に発展させられます。
逆にこの文脈が消えれば対話原文がどれだけ多く残っていても新しいAIと再び最初から始めることになります。
複数のAIを使う時代に必要な基盤
今後AIモデルはより多様になり各自の強みもより明確になるでしょう。
ユーザーは一つのAIに留まるよりも複数のAIを往来しながら作業する可能性が高いです。
その時に必要なのはすべてのAIを一つにすることではありません。
AIが変わってもユーザーの思考と決定が切れないようにすることです。
5BYのHandoffはChatGPT、Claude、Geminiまたは別のAIのどれを使っても以前の対話の重要な文脈から再び始められるように支援することを目指します。
AIは変わる可能性があります。
対話ウィンドウも変わる可能性があります。
しかしユーザーが蓄積してきた思考の流れまで毎回最初に戻るべきではありません。