トークン最適化

概要 thedotmack/claude-mem は Claude Code にセッションをまたいだ記憶を持たせる MCP（Model Context Protocol）ベースのオープンソースプラグイン。公開から48時間で46,000スターを獲得し、「トークン消費95%削減」「コンテキスト上限に到達しない」「前回の続きから再開できる」という特徴が開発者の注目を集めた。 主な特徴 特徴 内容 トークン削減 セッションあたり約95% ストレージ ローカル SQLite + Chroma インストール npx claude-mem install（1コマンド） ライセンス オープンソース・完全無料 3層検索フロー 関連する記憶を効率よく取り出すために、以下の段階的なフィルタリングを採用する: キーワード検索 (search) — テキストマッチで候補を絞り込む タイムライン確認 (timeline) — 時系列で文脈を絞り込む 詳細取得 (get_observations) — 必要な記憶だけを取得する 先に絞り込んでから詳細取得することで不要なトークン消費を防ぐ。この仕組みが「95%削減」の源泉。 記憶の保存と圧縮 Claude Code のセッション中の操作を自動キャプチャ AI を使って記憶を圧縮・要約（Claude Agent SDK を使用） ローカルの SQLite データベースに永続化 Chroma によるベクトル埋め込み検索で意味的に類似した記憶を検索 インストール 1 npx claude-mem install 特別な API キーや外部サービスの登録は不要。完全ローカルで動作する。 MemPalace との比較 観点 claude-mem MemPalace 対象 Claude Code 専用 複数 AI ツール対応 インストール 1コマンド Python セットアップ 公表スコア トークン95%削減 LongMemEval 96.6%（論争あり） アーキテクチャ 3層検索 宮殿構造（Wing/Hall/Room） 関連ページ MemPalace — 別アプローチの AI メモリシステム エージェントメモリのロックイン — メモリ管理の設計上の課題 Claude Code — claude-mem の動作環境 MCP — プラグインの接続プロトコル ソース記事 claude-mem: Claude Code に永続的な記憶を追加し、48 時間で 46,000 スター — 2026-04-13

Claude Code を使い続けると、トークン消費が思いのほか速く、使用制限に達してしまうことがある。その主な原因のひとつが、ターミナルコマンドの出力だ。git status や npm install が吐き出すプログレスバー・警告・ログといったノイズが、そのままコンテキストに流れ込んでいる。 この問題を解決するツールが RTK（Rust Token Killer） だ。 RTK とは RTK は Claude Code とターミナルの間に挟む「CLI プロキシ」ツール。Rust 製の単一バイナリで、依存関係ゼロのオープンソースプロジェクトだ。 GitHub: rtk-ai/rtk 公式サイト: https://www.rtk-ai.app/ コマンドを透過的にラップして出力をフィルタリングし、LLM のコンテキストに送る情報量を大幅に削減する。実測で 60〜90% のトークン削減、1,000 万トークン以上の削減（89% 削減）を達成した事例も報告されている。 4 つの最適化戦略 RTK は以下の戦略でターミナル出力を圧縮する: 戦略 内容 スマートフィルタリング ANSI エスケープコード、スピナー、プログレスバーを除去 グルーピング 関連する出力をまとめて集約 重複除去 繰り返しパターンを排除 トランケーション エラーは保持しつつ、冗長な成功出力を切り詰め オーバーヘッドは 1 コマンドあたり 10ms 未満で、100 以上の開発コマンドに対応している。 セットアップ 1 rtk init -g -g フラグでグローバルインストール。Claude Code / GitHub Copilot との統合も自動で設定される。 インストール後、RTK はコマンドを透過的に書き換える。たとえば git status は内部で rtk git status として実行され、Claude には圧縮済みの出力が渡される。ユーザーが意識する必要はない。 ...

Claude Code を使っていて「なんかコストかかるな…」と思ったことはないでしょうか。以前、デフォルト設定のまま使い続けると推定 2 億 6,400 万トークンもの無駄が発生するという事例が話題になりました。 その後 Claude Code 自体が大幅に改善されましたが、トークン消費を意識した使い方は今でも重要です。本記事では、現在のバージョン（2026年4月時点）で有効な最適化ポイントを整理します。 ツール検索の遅延ロード（Deferred Tools） 以前の Claude Code では、すべてのツール定義がセッション開始時にコンテキストに読み込まれ、大量のトークンを消費していました。ENABLE_TOOL_SEARCH を明示設定することで改善できるという報告もありました。 現在のバージョンでは、この問題はビルトインで解決されています。 ツール定義は「遅延ロード（Deferred Tools）」方式に変わり、ツール名だけがコンテキストに載り、実際のスキーマは必要になった時点で初めてロードされます。ENABLE_TOOL_SEARCH を手動で設定する必要はありません。 プロンプトキャッシュの 5 分 TTL — 今も最大の落とし穴 Claude のプロンプトキャッシュは 5 分で期限切れになる。これは現在も変わっておらず、トークンコストに最も影響する要素だ。 5 分休憩しただけで、会話全体が再処理され、コストが 10 倍以上に跳ね上がることがある。 つまり: 長時間セッションの途中で離席する ちょっと休憩してから作業再開する 別の作業をしてから Claude Code に戻ってくる といった行動がすべて、想定外のコスト増につながる。「休憩明けの最初のメッセージが一番高い」というのは、このキャッシュ再処理が原因だ。 キャッシュを意識した作業フロー 5 分以内に次の操作を行う — キャッシュが維持される 長い離席の前にセッションを終了する — 戻ってきたら /resume で再開した方が、コンテキストが圧縮されて効率的 タスクの区切りで /compact を実行する — 手動でコンテキストを圧縮し、次のキャッシュミス時のコストを下げる コンテキスト自動圧縮を活かす Claude Code はコンテキストウィンドウの上限に近づくと、過去の会話を自動的に圧縮する。この仕組みのおかげで、長時間セッションでも会話が途切れることはない。 ただし、圧縮時にはトークンが消費される。不要にコンテキストを膨らませないことが、結果的にコスト削減になる。 コンテキストを膨らませない工夫 やりがちなこと 改善策 大きなファイルを全行読む 必要な範囲だけ offset / limit 指定で読む ビルドログをそのまま流す エラー時だけ出力を確認する 試行錯誤を同一セッションで続ける 方針が変わったら新しいセッションで仕切り直す CLAUDE.md に大量の指示を詰め込む 必要最小限に保つ（毎ターンのコンテキストに載る） 現在のビルトイン最適化機能 2026年4月時点で Claude Code に組み込まれている主なトークン最適化機能: ...