DoDoneを作る過程で、予想以上に長く考えた疑問があります：チャットウィンドウで会話の文脈をどう引き継ぐか。AIエージェント製品を作ると、最初はこれを単純に考えがちです。過去のメッセージをすべてコンテキストに入れればいいのでは？と。
モデルのコンテキストウィンドウはどんどん大きくなっています。何十万トークン、今や百万トークンをサポートするモデルもあります。ですから、モデルにユーザーの会話をできるだけ多く入力するのが最善に見えます。しかし私がDoDoneを作る中で出した結論は少し異なりました。
AIの記憶は、どれだけ詰め込めるかではなく、今何を記憶しておくべきかを決めることが重要です。
長い会話を扱う上で最も直感的な方法です。
Claude Code や Hermes のようなエージェントは、長期タスクを継続するために compaction（圧縮）という手法を使います。Anthropic も、長時間動作するエージェントのコンテキスト管理の中核手段として compaction を説明しています。会話が膨らんだとき、すべての古いメッセージを保持する代わりに、重要な部分を要約して最近のやり取りと並べて新しいコンテキストを作る、というやり方です。Claude Code も同様に、過去のメッセージや作業を圧縮しつつ、主要な設計判断、未解決の問題、実装の詳細は残すようにしています。
Hermesの実装はより具体的です。メッセージ数ではなくトークンの予算に基づいて圧縮を行います。現在のAPIコールで実際に使われているプロンプトトークンがコンテキストウィンドウの設定された割合に達すると、自動的にコンパクションが発動します。デフォルトの閾値は50%で、ウィンドウが512K未満のモデルでは早く圧縮しすぎないように少なくとも75%に引き上げられます。直近のいくつかのメッセージはそのまま残し、中央の部分を要約する仕組みです。
それは非常に合理的な構造です。特に単一の目標が長期にわたる場合、例えば一つのコーディング作業や一つの研究テーマにはよく合います。しかしDoDoneが抱えていた問題は少し違っていました。
なぜDoDoneが会話全体をそのまま渡し続けないのか、理由があります。
DoDoneはAIの同僚が働く仮想オフィスです。ひとつのAIとひとつのトピックを何時間も深掘りするだけではありません。ユーザーはマーケティングの同僚と話した後に開発者に仕事を渡し、プロジェクトチャンネルで会議を開き、その後特定の同僚にフォローアップを戻し、翌日にその同僚をまた呼び出すこともあります。
つまり、DoDoneのチャットは単なる会話ウィンドウではありません。仕事が行われるインターフェースなのです。その違いがコンテキスト設計を変えました。会話が増えるたびに過去の全メッセージをモデルに渡し続ければ、多くを記憶できますが、同時に三つの問題が現れます。
まずコストの問題です。LLMは各リクエストでコンテキストを再読します。会話が長くなるほど、同じ古いメッセージを何度も送り続けることになります。特にウィンドウが非常に大きいモデルでは、圧縮が遅れて行われるとセッション全体のコストが急増することがあります。Hermesでも、1Mモデルでデフォルトの50%しきい値だと、最初の圧縮が50万トークンまで発動しない可能性があるという議論があります。
次に速度の問題です。入力トークンが増えるほどモデルが処理する情報量は増えます。現在の質問に関係のない数週間前の会話を再読させる必要はありません。
しかし私が最も重く見たのは三つ目、コンテキストの汚染でした。
コンテキストが多ければ多いほど良いわけではありません
Anthropicはコンテキストエンジニアリングを説明する中で、関連性とコンテキストの汚染が長いコンテキストでも問題であり続けると指摘しています。これは重要なポイントです。百万トークンのウィンドウがあるからといって、それを埋め尽くすのが最適とは限りません。
例えばユーザーがマーケティングの同僚と次のようなやり取りをしていたとします。先週は新サービスのブランディング、数日前はInstagramの広告文、昨日は商品の価格方針、そして今日プレスリリースを頼む、といった具合です。技術的にはそれらすべてをモデルに渡すことはできます。しかし今日の仕事がプレスリリースであるなら、数週間前に編集したInstagramのやり取りを逐語で引きずり出すことは本当に助けになるでしょうか？そうした過去の生のやり取りが、現在のタスクに無関係な情報をモデルの判断に侵入させる余地を作るだけかもしれません。
だから最初からDoDoneは「どれだけの会話を含めるか」よりも「どれだけ最近の会話を完全に残すか」を重視してきました。
DoDoneの方針 — 最近のやり取りは鮮明に、古いものは圧縮して保持します
現在、DoDoneは直近8件のタスクを詳細なコンテキストとして保持しています。同僚との会話は約20K文字の詳細コンテキスト予算を使い、マスター・チャンネルは約16Kです。直近8件まではできるだけ詳細を保ち、それより古いものは圧縮されて以前の文脈を引き継ぐローリングサマリーになります。
単純化すると構成はこうです：過去のタスク1–12はローリングサマリーになり、最近のタスク13–20は詳細なコンテキストとして残り、今やっていることが現在のミッションです。
肝心なのは、古い会話が削除されるわけではなく、解像度が下がることです。最近のターンは高解像度で記憶され、古いものは低解像度になります。これは人間の記憶の仕組みにかなり近いと思います。1週間前の会話を文章ごとに覚えているわけではありませんが、重要な文脈は残ります：『あのプロジェクトで価格を$29にした』、『ターゲットはソロプレナーにした』、『次のタスクはランディングページの作成だった』といったことです。長いAIとの会話はこの構造のままのほうが自然に感じられると判断しました。
とはいえ、要約にも限界があります
もちろん、ローリングサマリーが万能薬というわけではありません。要約は圧縮であり、圧縮すればするほど避けられない細部の喪失があります。そして20、30、50のタスクが一つの会話に積み重なると別の問題が現れます：ユーザーが本当に同じことをしているのかどうかが不明瞭になるのです。
マーケティング戦略を話し合い、途中でホームページを作り、そのあと採用の話をして、またコンテンツ作成を始める──といった流れが起きるかもしれません。技術的にはすべてを1つのセッションでつなげておけますが、「技術的に可能」と「良いUX」は別物です。そこでDoDoneは最近、小さくて楽しい仕組みを追加しました。
AIの方が先に「新しい会話を始めてみてください」と言うことがあります。
現在のセッションのミッションが20に達すると、DoDoneがまずユーザーに知らせます。これは詳細な直近8件と、残りのおおよそ12件がローリングサマリーに折りたたまれて蓄積されたタイミングです。その瞬間、このメッセージが表示されます：
「💡 この会話、だいぶ長くなっています。トピックが変わっているなら、新しいセッションを始めることをおすすめします — レスポンスの精度が上がり、AIのコストも下がります。続ける場合でも、以前の流れは要約として保持されます。」
重要なのは、セッションを強制的に終了させないことです。同じプロジェクトを続けるなら、そのまま進めてください。ただしトピックがすでに変わっている場合は、新しいセッションを始めるほうがずっと良いです — それでも必要な以前の流れは要約として引き継がれます。最終的な選択はユーザーに委ねられます。
その通知をどこに表示するかも重要でした。
単にメッセージ数で長い会話の通知を出すことには満足しませんでした。DoDoneはそれを二箇所でチェックします。
最初のポイントはタスク指示が入った瞬間です。1:1のやり取り、マスター・チャンネル、全員用チャンネル、会議のフォローアップ、プロジェクト経由などで指示が来たとき、指示を受け取った直後に非同期でセッション長がチェックされます。条件が満たされていれば、通知はユーザーが送った指示のすぐ下に自然に表示されます。
次に、ユーザーがチャンネルに入った瞬間です。オフィスで同僚をクリックしてチャットを開くときや、プロジェクトチャンネルに入るときに、現在のセッション状態がチェックされます。既に長すぎる場合は、新しいメッセージを送る前に通知が見られます。同じセッション内では一度だけ通知され、新しいセッションを始めると再度対象になります。UXとしては小さな違いですが、エージェント製品ではこうした点がかなり重要です。
AIエージェントでは、記憶とコンテキストは同じものではありません
DoDoneを作る中でますます明らかになってきたことが一つあります：記憶とコンテキストは同じ扱いをすべきではありません。
メモリとは、同僚が長期的に知っておく必要があることです。ユーザーの好み、会社の情報、働き方、繰り返しのルール、過去プロジェクトで決まった重要な事実。これらは数日後や数か月後に必要になることがあります。一方でコンテキストは違います—今このタスクを正しくこなすための作業記憶に近いものです。直前のリクエスト、作業中のファイル、今決まったこと、解くべき問題。両方をチャット履歴に詰め込もうとすると、システムはすぐに重くなってしまいます。
良いエージェントシステムは結局いくつかの層の記憶を持つべきだと考えています：現在のミッション（今やっていること）、最近のコンテキスト（直近の数回の詳細なやり取り）、ローリングサマリー（過去の作業の圧縮された流れ）、そして長期記憶（セッションに関係なく保持すべき事実やルール）。モデルのコンテキストウィンドウは、その場で必要なものを組み立てるためのスペースに過ぎません。
コンテキストウィンドウが大きくなるほど、コンテキストエンジニアリングの重要性は増します。
ここには皮肉があります。コンテキストウィンドウが小さかったころ、開発者は情報を切り捨てるしかありませんでした。ウィンドウが128K、200K、1Mと大きくなるにつれて多くを収められるようになりました。そして新たな問題が生まれました：何を含めないかを決めなければならないのです。
良いAIエージェントは、必ずしもすべてを記憶するものではありません。今必要なのは、現在を鮮明に覚え、古い情報は適切に圧縮し、重要なものを長期記憶に移し、話題が変われば新しい作業領域を作るAIです。結局のところ、エージェントを作る過程でますます多くやることになるのは、プロンプトエンジニアリングではなく、コンテキストエンジニアリングなのです。
核心となる問いも変わってきています。以前は「モデルに何を伝えるべきか？」でしたが、今は「この瞬間にモデルはどれだけのことを実際に知っているべきか？」に近づいています。
これこそが私がDoDoneの構築で最も時間をかけてきた点です。AIにより多くを覚えさせるのではなく、適切な瞬間に適切なものを覚えさせることです。今後のAIエージェントの品質を決定する差は、まさにそこに生まれると信じています。
— Seungwon Go、DoDoneを作っているソロプレナー