すでにツールをお持ちでしょう。
ここに違いがあります。
圧縮ツールはワイヤー経由で送信するデータを縮小します。LeanCTX もそれを行いますが、さらに最初から何が読み込まれるかを決定し、それを保護し、記憶し、証明します。何が優れているか、同じことをするか、そして全く必要ない場合があるのかを簡潔に見ていきます。
あなたのエージェント 有無の比較。
エージェントもリポジトリも同じです。変えられるのは、その間のレイヤーだけです。
| Feature | ツールなし | 手動ルール | LeanCTX |
|---|---|---|---|
| トークン節約 | なし | 低い（静的ルール） | 60–95%（キャッシュ時：99%） |
| セットアップの手間 | なし | プロジェクトごと手動設定 | ワンコマンド |
| エージェントのサポート | 該当なし | 単一のエージェントのみ | 29以上のエージェント |
| Caching | なし | なし | 自動 + 差分 |
| シェル圧縮 | なし | なし | 95以上のパターン |
| コード解析 | なし | なし | Tree-sitter AST |
| メンテナンス | なし | 手動更新 | 自動 |
| セキュリティとガバナンス | 強制なし | 基本的なファイルACL | OWASP準拠：PathJail、シェル許可リスト、シークレットのマスキング、OSサンドボックス化されたコード実行（ctx_execute）、監査証跡 |
| Compliance & Evidence | Screenshots | 手動での証拠収集 | 署名付きエビデンスバンドル + オフラインleanctx-verify、EU AI Act / ISO 42001 / SOC 2対応、CGB + ポリシーカバレッジ |
| SDKと拡張性 | なし | カスタムの接着コード | Python + TypeScript SDK (14チェック準拠)、/v1 OpenAPI + 機能、ctx_toolsゲートウェイ、WASMおよびプラグイン拡張 |
The cached figure (99%) is a repeat read served from cache at ~13 tokens; a first read never returns more tokens than the raw file, and every saving is measured net of injection (the tokens lean-ctx itself adds), so the number reconciles to your provider bill.
LeanCTXと～の比較 他のツール
RTK、Context+、MemGPT/Letta、Headroomといった最も一般的に参照される代替品との機能ごとの比較。公開ドキュメントに基づいた事実情報です。
| Feature | RTK | Context+ | MemGPT / Letta | Headroom | lean-ctx |
|---|---|---|---|---|---|
| 読み取りモード | 単一モード | 基本フィルタリング | N/A (メモリ特化) | 読み取り後に圧縮する | 10モード（auto, map, signatures, diff, entropy...） |
| シェル圧縮 | なし | なし | なし | いいえ | 95以上のパターン、自動検出 |
| セッションメモリ | 基本ステート | 会話履歴 | コア機能（階層型メモリ） | デデュープ化されたクロスエージェントストア | エピソード的 + 手続き的 + 知識グラフ |
| Multi-Agent | なし | なし | 限定的（単一エージェントに焦点） | 共有ストア | ハンドオフ、共有セッション、コンテキストバス |
| コードグラフ / AST | 基本インデックス化 | なし | なし | いいえ | Tree-sitter AST、26言語対応、シンボル解決機能 |
| Governance & Budgets | なし | なし | なし | いいえ | ロールベースの予算、SLO、監査証跡 |
| Local-First / Privacy | クラウド依存型 | ローカル | サーバーベース | Pythonパッケージ + プロキシ | 100%ローカル、テレメトリーなし |
| MCPツール | 限定的 | MCP非対応 | MCP非対応 | 外部ツールをラップする | 81個の粒度の高いMCPツール |
| Security Hardening | None | None | Basic auth | None | Sandboxing, signed bundles, audit reports |
2026年6月時点の公開ドキュメントおよびソースコードに基づく。RTK (github.com/rtk-ai/rtk)、Context+ (github.com/ForLoopCodes/contextplus)、MemGPT/Letta (arxiv.org/abs/2310.08560)、Headroom (github.com/chopratejas/headroom)。すべてのツールが実用的な問題を解決する。LeanCTXは、コンテキストの問題のより多くのレイヤーを単一バイナリでカバーする。
圧縮は読み込まれたものを縮小する。 context engineeringが何が読み込まれるかを決定する。
Headroomのようなツールは、ワイヤー上のリクエストを圧縮します。LeanCTXにはすでにそのレイヤーが搭載されています—オプションのローカルプロキシがすべてのリクエストをプロンプトキャッシュセーフに圧縮し—さらに根本的な層で機能します：何が読み込まれるかを決定する。Headroomと互換性がありますが、通常は追加する必要はありません。ここに正直な違いがあります。
| Dimension | 圧縮レイヤー（例：Headroom） | LeanCTX |
|---|---|---|
| 配置場所 | メッセージパス：エージェントがすでに読み込んだものを圧縮する | ソース：何とどのように読み込むかを決定する（10モード、意図ルーティング、~13トークンのキャッシュ再読み込み） |
| Memory | 重複排除付きのクロスエージェントストア | 永続的な知識：プロパティグラフ、セッション、ハンドオフ、証拠台帳 |
| Governance | — | PathJail、シェル許可リスト、シークレット赤入れ、予算、インジェクション検出 |
| 証明 | 統計エンドポイント | Ed25519署名、ハッシュチェーン化された台帳 + 再現可能なベンチマーク |
| 可逆性 | 参照検索ストア | それも可逆: 元のデータはすべて保持される ctx_retrieve する |
| Form | Pythonパッケージ + プロキシ | Rustバイナリ1つ、30以上のツールを自動検出、設定不要 |
注: 一部のサードパーティの比較表では、lean-ctxが「可逆性：なし」と記載されていますが、これは誤りです。LeanCTXで読み込まれたすべての圧縮データはローカルにアーカイブされ、ctx_retrieve経由で取得可能です。圧縮はLeanCTXの5つのサブシステムの一つです。2つのツールを同時に実行することもでき、Headroomはlean-ctxを互換性のあるコンテキストツールとしてリストしています。
あなたのスタックはすでにこれの一部を行っている。 しかし、それはできていない。
LeanCTXはgrepやエディタを置き換えるものではありません。AIにとって何が注目に値するかを判断するレイヤーです。
なぜ単にgrepを使わないのか？
grepはテキストを見つけます。LeanCTXは適切なシンボルを見つけ、関連性でランク付けし、読む必要がありフィルタリングする必要がある500件の生のマッチではなく、予算化され構造化されたコンテキストを返します。
なぜ単にファイルを読むだけではダメなのか？
生の読み込みは4,200トークンをダンプしますが、シグナルを持つのは約920トークンです。LeanCTXはシグナルを保持しノイズを排除し、キャッシュされた再読み込みにかかるコストは、ファイル全体を再度読むよりも約13トークンに抑えられます。
なぜ単にコンパクションを頻繁に行わないのか？
コンパクションは、必要かもしれない履歴を破棄します。LeanCTXでは行き止まりがありません。すべてのオリジナルデータはディスクにアーカイブされ、エージェントが必要に応じてそれを取得できます。何も静かに失われることはありません。
なぜ別のMCPサーバーを使わないのか？
ほとんどのMCPサーバーはツール定義のオーバーヘッドを追加し、生の出力を返します。LeanCTXは完全な認知コンテキストレイヤーです：キャッシング、永続メモリ、シェルフック、ガバナンスレイヤーをすべて単一のローカルバイナリに統合しています。
lean-ctxが輝く場面 Shines
LeanCTXは、これらのシナリオで最大の価値を提供します。
大規模なコードベース
数百から数千のファイルを持つプロジェクトで最も恩恵を受けます。管理すべきコンテキストが多いほど、節約効果が大きくなります。
マルチエージェントワークフロー
複数のAIエージェントが同じプロジェクトに取り組む際、LeanCTXはそれらに共通の知性（共有されたコンテキスト）を提供します。すべてのエージェントに一貫性のあるガバナンスされたコンテキストを。
反復的な開発
ファイル読み込みが繰り返される長いコーディングセッションはキャッシュに負荷をかけます。再読み込みにかかるコストは、数千トークンではなく、わずか〜13トークンです。
～の場合 不要な場合
私たちは正直なツールを信じています。LeanCTXは大規模なコードベースを持つプロジェクト向けに設計されており、全てではありません。
- 単一ファイルのスクリプトや小規模なユーティリティ
- 50ファイル未満のプロジェクト
- ファイルコンテキストを伴わない一時的なプロンプト
これらのケースでは、context layerのオーバーヘッドは正当化されません。LeanCTXが真価を発揮するのは、プロジェクトが成長し、コンテキスト管理がボトルネックになる場合です。
比較に関する質問への回答。
LeanCTXは手動のプロンプトエンジニアリングと比較してどうですか？
手動のプロンプトエンジニアリングでは、すべてのコンテキストウィンドウを手作業で作成する必要があります。LeanCTXは、10種類の読み取りモード、AST対応の圧縮、セッションメモリによりこれを自動化し、手動での労力ゼロで88%+のトークンを節約します。
LeanCTXは他のMCPコンテキストツールより優れていますか？
LeanCTXは単なるMCPサーバーではなく、完全な認知コンテキストレイヤーです：CLI統合、シェルフック、81のMCPツール、永続メモリ、コードインテリジェンスグラフ、ロールと予算を備えたガバナンスレイヤーがあります。
LeanCTXは私のAIコーディングツールと連携しますか？
はい。LeanCTXは、Cursor、Claude Code、GitHub Copilot、Windsurf、Gemini CLI、Codex、JetBrains IDEsなど30以上のAIツールをサポートしています。自動設定のため、lean-ctx setupを実行してください。
LeanCTXはHeadroomのような圧縮ツールとどう違いますか？
Headroomのようなツールは、ワイヤー上のリクエスト（プロキシ層）を圧縮します。LeanCTXにはすでにそのレイヤーが搭載されています：オプションのローカルプロキシ（lean-ctx proxy enable）がすべてのリクエスト—システムプロンプト、履歴、およびツールの結果—をプロンプトキャッシュセーフに圧縮し、実際に節約されるドル額を計測するため、通常は別途リクエスト圧縮プロキシを追加する必要はありません。さらにLeanCTXは、より根本的な層で機能します：何が読み込まれるかを決定する（10の読み取りモード、~13トークンのキャッシュ再読み込み）、セッションをまたいだ知識を記憶し、ファイルおよびシェルへのアクセスを保護し、すべての保存を検証可能な台帳に署名します。圧縮—読み取り側とワイヤー側—は5つのサブシステムの一つであり、完全に可逆的です：元のデータはすべてctx_retrieveから取得できます。
LeanCTXの圧縮は可逆ですか？
はい。すべての圧縮された読み取りはローカルにアーカイブされ、完全なオリジナルはオンデマンドでctx_retrieve経由で取得可能です。何もサイレントに失われることはありません。LeanCTXはエージェントにいつフルコンテンツを要求すべきかを通知することさえあります。
LeanCTXは、SlackやClickUp Brainのようなベンダーエージェントのメモリとどう違いますか？
それらはAIベンダーにあなたの会社を記憶させます—タグ付けし、スレッドでフォローアップすれば、メモリが構築されます。しかし、そのメモリは彼らのブラックボックス内に存在します：どこにあるか、移動できるか、または下のモデルを交換できるかが見えません。それはコンテキストのログインであり、モデルのログインではありません—結局、あなた自身の会社の知識をレンタルすることになります。LeanCTXは堀をあなたの側に保ちます：セッション、ナレッジグラフ、およびポータブルな.ctxpkgパッケージがローカルで検査可能であり続け、OpenAI、Anthropic、Geminiにまたがってモデル非依存です。エージェントをチームメイトとして扱うワークフローは同じです。コンテキストはあなた自身が保持します。