本当に興味深いし、絶対に試してみるよ、ありがとう！点をつなげると（ちゃんとつながってるか確認してほしいんだけど）、コンテキストモードはMCPのコンテキスト使用には全く関係ないってことだよね？代わりに、MCPツールをリファクタリングしたり排除したり、可能な限りMCPにコンテキストモードに似た概念を適用することを提案してるのかな？コンテキストモードは「いいえ」だとしても、非常に価値があると思うし、理解できてるか確認したい。上記についての考えも聞きたいな。私はすべてのClaudeの表面で動作するいくつかのMCPを書いてるから、通常の「CLI！」はあまり有効な答えではないんだ（ただし、コード実行があるときは時々そうなるけど）... 編集：タイプミス

あなたのテクニックはキャッシュを壊すの？ 編集：ありがとう。

そうだね、基本的にはプレ圧縮だよ。重要な違いは、何も捨てられないこと。フル出力が検索可能なFTS5インデックスに保存されるから、モデルが要約で見逃した詳細が必要だと気づいたら、それを検索できるんだ。最初から「何が関連してるかを決める」んじゃなくて、「今は要約をくれ、後で具体的なことを聞きに戻るから」って感じだね。

90年代後半を思い出すけど、htmlやsqlの代わりにコーディングエージェントが登場した感じ。今回は、多くの人がソフトウェアエンジニアリングに慣れてるから、claudeのコードを使って最適化を見つけるのが簡単なんだよね。アイデアが浮かんだら、AIと一緒に詳細な設計を作ってもらって、それを開発させるって感じ。

同意する。コンテキストと圧縮の細かい制御がもっと欲しいな。セッションの途中でデバッグに時間をかけたら、バグを修正した後は、それに関連するものをコンテキストから削除して、以前のように続けられるべきだよね。（今のところ、IDEによっては手動でやるのがかなり面倒だし、その後他のタスクでエージェントと作業した場合にそれを切り取ることができるものは知らない。）エージェント自身も自分のコンテキストを管理すべきだと思う。例えば、たくさんのログ情報をコンテキストにダンプするツールを使っている場合、そのログは1、2回のプロンプトの後に削除されるべきだよね。コンテキストは自由に操作できるものとして考えるべきで、単にスタックのように追加や削除しかできないものではないと思う。

もしかしたら「両方ともあり」ってのが正しい答えかもしれないけど、サブエージェントもその問題に使えるよね。つまり、何かが予想通りに進まないときに、サブエージェントをフォークして問題を解決し、答えを持って戻ってくるって感じ。自分自身のメモリを消去して、過去のバージョンに戻るモデルを想像するのは面白いけど、その時には厄介な問題の答えも持ってるっていう。

完全に同意する。正しい道が見つかれば、失敗した試みはただのノイズだよね。リトライパターンを自動検出して、最終的な動作バージョンに絞り込むのは、特にlintやコンパイルの修正みたいな明確なケースでは、かなり実現可能に感じる。

ありがとう、そう言ってもらえると嬉しいよ！君のチームにうまくいってるみたいでよかった。

いいアプローチだね。コンテキストモードと同じ基本的なアイデアだけど、ビルドドメインに特化してる。キーワード検索付きのYAMLルールファイルを使って、SQLiteを構造化された知識キャッシュとして利用してるんだ。コンテキストモードも似たようなことをしてるけど、ドメインに依存しない形でFTS5を使ってBM25ランキングを適用してるから、事前に定義されたスキーマなしでツールの出力が検索できるんだ。全然違うユースケースから独立してこのパターンが出てきたのは面白いね。

理論的にはそうだし、実際にも成立してるよ。コンテキストが70%生ログやスナップショットだと、モデルは実際のタスクを見失い始める。回答の質について正式なベンチマークはまだやってないけど、トークンの節約を測ることに主に集中してた。でも、経験的には一番の利点は、圧縮が始まる前にセッションが長く続くことなんだ。つまり、モデルはフルの会話履歴を保持して、失われたコンテキストからのミスが少なくなるってこと。

rtkを詳しく見たことはないけど、説明からするとCLI出力レベルで動作して、モデルに届く前にstdoutをトリムするみたいだね。コンテキストモードはもう少し進んでて、フル出力を検索可能なFTS5データベースにインデックス化するから、モデルは後で特定の部分をクエリできるんだ。単に失うのではなくてね。トリミングよりも、生のダンプを要約とオンデマンドの取得に置き換える感じだね。

どれがより理にかなっているか見極めようとしてるところだよ。rtkについての議論が今日始まったよ。https://news.ycombinator.com/item?id=47189599

それは確かにそうだね、Claude Codeは大きな出力を切り詰めるようになった。でも、25kトークンはまだ多いよね。特に複数のツールを連続で使うときは。Playwrightのスナップショットを3つか4つ取ったり、GitHubのイシューを一気に処理したりすると、必要だったのは数行だけなのに、100kトークンも使っちゃう。コンテキストモードだと、必要なときにフル出力を検索できる状態を保ちながら、1-2kに抑えられるんだ。

確かにその通りで、理想的なアプローチだと思う。でも実際にはほとんどの人がタスクごとにMCPサーバーリストを手動で整備することはないんだよね。5〜6台のサーバーをインストールしたら、いつの間にかデフォルトで80個のツールが読み込まれてる。コンテキストモードはツール定義の膨張を解決するわけじゃない、それは入力側の問題なんだ。実際にツールが動いてデータを返すときの出力側を扱ってる。集中したツールセットでも、Playwrightのスナップショットやgitログ1つで50kトークン使っちゃうことがある。それがサンドボックス化されるんだ。