「最高のコンテキストエンジニアリングツール」系のリストの多くは、RAGフレームワークのまとめ記事に新しいラベルを貼っただけのものだ。コンテキストエンジニアリングは実際にはマルチレイヤーのスタックであり、1つの層だけのツールを選ぶと、本番環境でハルシネーション、コストの暴走、2ターン前の出来事を忘れるエージェントといった問題として表面化するギャップが生じる。
コンテキストエンジニアリングが初めての方は、まず完全ガイドから読んでほしい。この記事は、コンセプトを理解した上で、実際にツールを選定する必要がある方を対象としている。
ベストコンテキストエンジニアリングツール8選 一覧
以下が私たちのランキングだ。各ツールは、本番環境での実用性、開発者体験、コンテキストパイプライン全体への影響度の観点から選定している。
| 順位 | ツール | スタック層 | 選定理由 |
|---|---|---|---|
| 1 | Langfuse | オブザーバビリティ | 見えないものは改善できない |
| 2 | Claude Prompt Caching | キャッシュ | 明示的コントロールで90%削減 |
| 3 | LlamaIndex | 検索 / RAG | 160以上のコネクタ、データファースト設計 |
| 4 | Mem0 | エージェントメモリ | 数週間ではなく数時間で本番メモリを実現 |
| 5 | LLMLingua | 圧縮 | 2〜5倍の圧縮率、競合がカバーしていない領域 |
| 6 | Gemini Context Caching | キャッシュ | 長文コンテキストで最大の割引率 |
| 7 | CLAUDE.md + Cursor Rules | コーディングエージェントのコンテキスト | コーディングエージェントのためのコンテキストエンジニアリング |
| 8 | LangChain / LangGraph | オーケストレーション | すべてをつなぐ接着剤 |
それでは、各ツールを詳しく見ていこう。
1. Langfuse — 最初に導入すべきオブザーバビリティ層
1位に検索フレームワークやキャッシュAPIを期待した人もいるかもしれない。なぜオブザーバビリティが最初に来るのか。それは、測定できないコンテキストパイプラインは最適化できないからだ。オブザーバビリティをスキップしたチームは、1本のトレースで数分で説明できたはずのハルシネーションのデバッグに数週間を費やすことになる。
Langfuseは、GitHubで19,000以上のスターを獲得しているオープンソースのLLMオブザーバビリティプラットフォームだ。パイプライン内のすべてのLLMコールをトレースし、どのコンテキストが入力され、何が出力され、コストはいくらかかり、どこで品質が低下したかを記録する。
優れている点
- オープンソースかつMITライセンス。 セルフホストで無制限に使うことも、クラウド版を使うこともできる。ベンダーロックインなし。
- ClickHouseによるスケーラビリティ。 大規模な本番ワークロードでも処理が詰まらない。
- OpenTelemetryネイティブ。 既存のオブザーバビリティスタックに、別途計装レイヤーを設けずに組み込める。
- フレームワーク非依存のインテグレーション。 LlamaIndex、LangChain、OpenAI SDK、Anthropic SDK、Vercel AI SDKなど、主要なフレームワークすべてに対応。
- プロンプト管理を内蔵。 トレースと並行してプロンプトのバージョン管理とテストができ、プロンプトの変更と品質変化の相関を確認できる。
物足りない点
- セルフホスト環境の構築にはClickHouseが必要で、大規模運用は容易ではない。
- UIは機能するものの、チェーントレースのデバッグ体験という点ではLangSmithほど洗練されていない。
- 評価機能は比較的新しく、専用評価プラットフォームほど成熟していない。
料金
| プラン | 費用 | 月間オブザベーション数 |
|---|---|---|
| Free（クラウド） | $0 | 50,000 |
| Pro（クラウド） | 従量課金 | 無制限 |
| セルフホスト | $0（インフラ費用は別途） | 無制限 |
誰に向いているか
本番環境でLLMコールを実行しているすべてのチーム。正直なところ、Claude、GPT、GeminiにAPIコールを送っていてオブザーバビリティがないなら、目隠しで飛んでいるようなものだ。他のツールを何を選ぶかに関係なく、Langfuseは最初に導入すべきツールだ。
結論
Langfuseが1位に選ばれたのは、このリストの他のすべてのツールの効果を高めるからだ。 各コールの内部で何が起きているか見えなければ、検索のチューニングも、キャッシュの最適化も、メモリ層のデバッグもできない。まずはここから始めよう。
2. Claude Prompt Caching — 完全なコントロールで90%のコスト削減
コンテキストキャッシュは、最小の労力で最大の効果が得られる最適化手法だが、まだ多くのチームが活用していない。Claudeの実装は、どのプロバイダーよりもきめ細かなコントロールが可能だ。
メッセージ配列に明示的なcache_controlブレークポイントを設定する。Anthropicのドキュメントによると、キャッシュ読み取りのコストは基本入力トークン価格のわずか10%だ。キャッシュ書き込みは基本価格より25%高いが、これはキャッシュエントリごとの一回限りのコストだ。5分のTTLはヒットするたびに更新されるため、アクティブな会話はキャッシュされたまま維持される。
優れている点
- キャッシュ読み取りで90%割引。 計算は単純で、同じシステムプロンプトやFew-shot例を繰り返し送信している場合、それらのトークンコストが90%削減される。
- 明示的ブレークポイントによるコントロール。 OpenAIの自動方式とは異なり、何をキャッシュするかを正確に指定できる。
- 更新される5分TTL。 アクティブなセッションはキャッシュが維持され、アイドル状態のものは自然に期限切れになる。
- Claude 3.5 Sonnet、Haiku、Opusすべてに対応。 単一のモデルティアに限定されない。
物足りない点
- バッチ処理ワークロードには5分のTTLは短い。コールの間隔が5分以上空く場合、キャッシュの効果は得られない。
- 明示的な
cache_controlマーカーが必要で、OpenAIの自動キャッシュより実装の手間がかかる。 - Anthropicエコシステムにロックインされる。プロバイダー間のキャッシュ共有はできない。
料金
| アクション | 基本価格との比較 |
|---|---|
| キャッシュ書き込み | 基本入力価格の+25%（一回限り） |
| キャッシュ読み取り | 基本入力価格の10%（90%削減） |
| TTL | 5分、ヒットごとに更新 |
誰に向いているか
システムプロンプト、Few-shot例、大規模なドキュメントコンテキストを繰り返し使用するClaude APIを利用しているチーム。同じコンテンツが5分以内に複数のコールで使われるなら、今すぐキャッシュを有効にしよう。
結論
Claude Prompt Cachingは、コンテキストエンジニアリングスタック全体で最も手軽なコスト最適化だ。 Claudeを使っているなら、今日にでも有効にしよう。投資対効果は即座に現れる。
3. LlamaIndex — 実用的な検索レイヤー
検索レイヤーはほとんどのチームが出発点とする場所であり、LangChain vs LlamaIndexの議論が尽きない場所でもある。2026年、その答えは人々が思っているよりも明確だ。LlamaIndexはデータファーストのフレームワーク、LangChain/LangGraphはオーケストレーション層。それぞれ異なる問題を解決する。
LlamaIndexは、データから正しい情報を取り出すことに長けている。ドキュメントの取り込み、構造化データの処理、関連するコンテキストを返す検索パイプラインの構築——これがLlamaIndexの中核的な役割だ。
優れている点
- LlamaHub経由で160以上のデータコネクタ。 PDF、データベース、API、Notion、Slack、Google Drive——データが存在する場所には、おそらくコネクタがある。
- 複数のインデックスタイプ。 ベクトル、キーワード、ツリー、ナレッジグラフインデックス。データに合った検索戦略を選べる。
- データファーストの設計思想。 LlamaIndexは汎用フレームワークを目指すのではなく、検索を高い品質で行うことに明確な方針を持っている。
- LangGraphとのネイティブ統合。 両者はクリーンに連携し、LlamaIndexがデータの取り込みと検索を担当し、LangGraphがエージェントの結果に対する処理を担当する。
- MITライセンスのオープンソース。 ライセンスの心配なし。
物足りない点
- APIの表面積が大きく、ドキュメントは初心者には圧倒的に感じられることがある。
- 単純なベクトル検索だけが必要なら、LlamaIndexは過剰かもしれない。QdrantやPineconeのクライアントを直接使う方がシンプルだ。
- メジャーバージョン間で破壊的変更が頻繁にある。
料金
| プラン | 費用 |
|---|---|
| オープンソース | 無料（MITライセンス） |
| LlamaCloud（マネージド） | 従量課金、$0から |
誰に向いているか
複数のソースからデータを取り込み、正確にコンテキストを検索する必要があるRAGパイプラインを構築しているチーム。特にデータが「PDFのフォルダ」だけではない場合——構造化データベース、API、混在フォーマットのデータ——にLlamaIndexは真価を発揮する。
静的な検索を超えたツール連携や動的なコンテキストソースについては、MCPガイドを参照してほしい。
結論
LlamaIndexは、2026年の本番RAGにおける最高の検索フレームワークだ。 LangGraphと組み合わせてオーケストレーションを担わせれば、最も強力なコンテキストパイプラインが完成する。
4. Mem0 — インフラの頭痛なしで本番エージェントメモリを実現
メモリがなければ、エージェントはすべての会話を初回のように扱う。Mem0 vs Zepの選択は、本番環境への到達速度と、エンタープライズ向けの時系列の複雑さのどちらを重視するかで決まる。
Mem0は、実際に機能するエージェントメモリへの最速ルートだ。マネージドAPIはグラフ検索とベクトル検索を1回のコールで組み合わせ、メモリの保存と後からの取得を可能にする。ハイブリッドアプローチにより、意味的類似性と関係ベースの検索の両方に対応する。
優れている点
- マネージドAPIでインフラ構築不要。 ベクトルデータベースのプロビジョニングも、グラフストアのメンテナンスも不要。
- グラフ＋ベクトルのハイブリッド検索。 純粋なベクトル検索より高い再現率。Mem0のベンチマークによると、メモリ検索タスクにおいてシンプルなRAGと比較して26%高い精度を記録。
- 極めてシンプルなAPI。 1回のコールでメモリを保存し、別のコールで取得する。複雑さはクリーンなインターフェースの裏に隠されている。
- オープンソース版も利用可能。 データ主権が必要な場合は、Mem0 OSSでセルフホストできる。
物足りない点
- ベンダー公表のベンチマークは鵜呑みにせず、自社で評価を行うべきだ。
- マネージドAPIを使う場合、エージェントのメモリはMem0のサーバーに保存される。エンタープライズのコンプライアンスチームから懸念が出る可能性がある。
- 時系列ナレッジグラフに関してはZepほど成熟していない。「3ヶ月前の顧客の住所は？」といったニーズにはZepの方が適している。
料金
| プラン | 費用 |
|---|---|
| Free | 1,000メモリ |
| Pro | 従量課金 |
| セルフホスト（OSS） | 無料（インフラ費用は別途） |
知っておくべき代替ツール
- Zep — エンタープライズ向け時系列ナレッジグラフ。ビジネスデータ検索で90%のレイテンシ削減を謳う。事実が時間とともに変化し、その変化を追跡する必要があるアプリに最適。
- Letta（旧MemGPT）— エージェントが自己編集操作で自身のメモリを管理するオープンソースのエージェントランタイム。メモリ層というよりフルフレームワークに近い。
- LangMem — すでにLangGraphを深く使っているチーム向けの軽量オプション。機能は少ないが、依存関係を増やさずに済む。
結論
Mem0は本番環境への到達速度で勝る。 数週間ではなく数時間で、動作するエージェントメモリが手に入る。時系列の追跡が中核要件ならZepを、エージェントランタイムを完全にオープンソースでコントロールしたいならLettaを選ぼう。
5. LLMLingua — 誰も語らない圧縮レイヤー
これはコンテキストエンジニアリングスタック全体で最も注目されていないレイヤーだ。圧縮ツールは品質を大きく損なうことなくトークンコストを2〜5倍削減できるのに、ツールガイドで言及されることはほぼない。
Microsoft ResearchのLLMLinguaは、LLMの出力を意味的に変えないトークンを特定して除去することでプロンプトを圧縮する。要約ではなく、小型モデルのパープレキシティスコアに基づいた外科的なトークン除去だ。
優れている点
- 品質劣化を最小限に抑えた2〜5倍の圧縮。 実際には、4,000トークンのコンテキストを1,500トークンまで削減しても、ほぼ同一の出力が得られることが多い。
- Microsoft Researchの裏付け。 週末プロジェクトではなく、ピアレビュー済みの公開研究だ。
- オープンソース。 ライセンスの懸念なく、あらゆるパイプラインに統合できる。
- キャッシュとの相乗効果。 まず圧縮し、圧縮版をキャッシュすることで二重の削減効果が得られる。
物足りない点
- レイテンシが追加される。圧縮ステップでは、メインのLLMコールの前に小型モデルを実行してトークンをスコアリングする。
- 品質劣化は平均的には「最小限」だが、個別のエッジケースでは重要なコンテキストが失われる可能性がある。評価が不可欠だ。
- 検索ツールやメモリツールと比べてエコシステムが未成熟。ドキュメントも薄い。
料金
| プラン | 費用 |
|---|---|
| オープンソース | 無料 |
知っておくべき代替ツール
- Selective Context — 圧縮ではなくフィルタリングアプローチを採用。取得したコンテキストのうち、現在のクエリに対して実際に情報量が多いものを評価し、残りを破棄する。コンテンツ処理容量は約2倍、メモリは40%削減。
- context-engineering-toolkit（GitHub）— コンテキストの優先順位付けとベンチマークのための新しいオープンソースプロジェクト。パイプラインの性能測定に有用。
結論
LLMLinguaは現時点で最高の圧縮ツールであり、しかも無料だ。 課題は成熟度で、これらのツールはまだ発展途上にある。本番環境に投入する前に、自社パイプラインで十分にテストしよう。
6. Gemini Context Caching — 長文コンテキストで最大の割引率
アプリケーションが非常に長いコンテキストを扱い、Googleのモデルを使用している場合、GeminiのキャッシュAPIは市場で最も深い割引を提供する。Googleのキャッシュドキュメントによると、Gemini 2.5モデルではキャッシュトークンに最大90%の割引が適用される。
優れている点
- Gemini 2.5で最大90%、2.0で75%の割引。 全プロバイダー中で最も高いキャッシュ読み取り割引率。
- 設定可能なTTL。 Claudeの固定5分ウィンドウとは異なり、キャッシュの保持時間を自分で設定できる。
- 長文コンテキストアプリに最適。 変更が少ないコードベース全体やドキュメントコレクションをキャッシュする場合、時間ごとのストレージコストは読み取り割引の効果に見合う。
物足りない点
- キャッシュの最小要件は32,768トークン。 キャッシュ可能なコンテンツが約25ページ未満の場合、この機能は使えない。
- 時間単位のストレージコスト。 キャッシュ作成費用、時間ごとのストレージ費用、（割引された）読み取り費用がかかる。長期キャッシュでは予想外のコストになることがある。
- Geminiエコシステムへのロックイン。 当然ながらGoogleのモデルでしか使えない。
料金
| アクション | 費用 |
|---|---|
| キャッシュ読み取り（2.5） | 基本価格から90%割引 |
| キャッシュ読み取り（2.0） | 基本価格から75%割引 |
| キャッシュ書き込み | 作成費用（一回限り） |
| ストレージ | 時間単位の課金 |
| 最小サイズ | 32,768トークン |
プロバイダー比較
| プロバイダー | キャッシュ読み取り割引 | キャッシュ書き込みコスト | TTL | 設定方法 |
|---|---|---|---|---|
| Claude | 基本価格から90%割引 | 基本価格+25%（一回限り） | 5分（更新あり） | 明示的ブレークポイント |
| Gemini | 基本価格から75〜90%割引 | 作成費用+時間あたりストレージ | 設定可能 | APIベース |
| OpenAI | 基本価格から50%割引 | なし（自動） | 約1時間 | 自動 |
結論
Geminiのキャッシュは、32kの最小要件が問題にならない長文コンテキストアプリケーションで最強だ。 より短く高頻度のキャッシュには、2位のClaudeのアプローチの方が実用的。OpenAIの自動キャッシュ（50%割引、設定不要）は、手間をかけずにコスト削減したいチームに次点として推奨する。
7. CLAUDE.md + Cursor Rules — コーディングエージェントのためのコンテキストエンジニアリング
多くのツールガイドが完全に見落としていることがある。CLAUDE.mdやCursor Rulesのような設定ファイルは、コーディングエージェントのためのコンテキストエンジニアリングそのものだ。これらは、エージェントがコードを1行も書く前に、プロジェクトについて何を理解しているかを定義する。
優れている点
- CLAUDE.md + /initが最もシンプルな入口。 Claude Codeはプロジェクトの
CLAUDE.mdから指示、コーディング規約、アーキテクチャの決定事項、よく使うコマンドを読み取る。/initコマンドはプロジェクト構造をスキャンして自動的に生成する。 - 3つのメモリレベル。 プロジェクトレベル（CLAUDE.md）、ユーザーレベル（~/.claude/CLAUDE.md）、セッションレベルにより、各インタラクションに与えるコンテキストをきめ細かく制御できる。
- AGENTS.mdはツール横断で動作。 Builder.ioの標準規格で、Cursor、Copilot、その他のコーディングエージェントがサポート。異なるエディタを使うチームでも1つの設定ファイルで済む。
- Awesome Skills（Antigravity） はGitHubで22,000以上のスターを獲得し、Claude Code、Cursor、Gemini CLI向けの1,234以上のビルド済みコンテキストパッケージを提供。コミュニティがメンテナンスするスキルファイルにより、プロジェクトコンテキストをゼロから書く手間が省ける。
物足りない点
- CLAUDE.mdはClaude Codeでしか動作しない。チームが複数のAIコーディングツールを使う場合、AGENTS.mdも必要になる。
- ツール間で標準フォーマットがなく、各エージェントはそれぞれ異なる方法で設定ファイルを読み取る。
- メンテナンスのオーバーヘッド。プロジェクトの進化とともにこれらのファイルは古くなり、古いコンテキストはコンテキストがないより有害だ。
料金
| ツール | 費用 |
|---|---|
| CLAUDE.md / /init | 無料（Claude Codeの一部） |
| AGENTS.md | 無料（オープン標準） |
| agents-md-generator | 無料（オープンソース） |
| Awesome Skills | 無料（オープンソース） |
Claude Code、Cursor、Copilotのプロジェクトコンテキスト処理の詳しい比較は、AIコーディングツール比較を参照。
結論
Claude Codeを使っているなら、まずCLAUDE.md + /initから始めよう。複数ツールを使うチームはAGENTS.mdを追加しよう。 このレイヤーは見落とされがちだが、適切に設定されたコーディングエージェントのコンテキストは、コード生成の品質を劇的に向上させる。
8. LangChain / LangGraph — オーケストレーションの接着剤
LangGraphが8位なのは、重要度が低いからではなく、オーケストレーション層だからだ。LangGraph自体が特定のコンテキストエンジニアリングの問題を解決するのではなく、他のツールをつなぐ役割を担う。このリストで上位にランクされているツールとほぼ確実に併用することになる。
優れている点
- ステートフルなエージェントグラフ。 LangGraphは、マルチステップの推論チェーン、ツール使用の調整、シンプルなフレームワークでは管理できない複雑な制御フローを処理する。
- LlamaIndexとのネイティブ統合。 2026年の推奨パターン：検索はLlamaIndex、オーケストレーションはLangGraph。
- 巨大なエコシステム。 どの代替ツールよりも多くのインテグレーション、チュートリアル、コミュニティサポート。
- LangSmithとの統合。 オブザーバビリティにLangfuseではなくLangSmithを選ぶ場合、デバッグ体験は非常に優れている。
物足りない点
- LangChainの抽象化レイヤーは重く感じることがある。シンプルなユースケースが不要な複雑さに埋もれてしまう。
- APIが頻繁に変更される。半年前のチュートリアルが動かないことがある。
- LangGraph + LlamaIndexを組み合わせるのではなく、単一で方針が明確なフレームワークを求めるなら、Haystackの方がクリーンだ。
料金
| プラン | 費用 |
|---|---|
| オープンソース | 無料（MITライセンス） |
| LangSmith（オブザーバビリティ） | 無料プラン：月5,000トレース |
結論
LangGraphは、複雑なエージェントパイプラインのための最高のオーケストレーションフレームワークだ。 検索にはLlamaIndex（3位）、オブザーバビリティにはLangfuse（1位）を組み合わせよう。よりシンプルな単一フレームワークのアプローチを求めるなら、Haystackを検討しよう。
なぜTechsyはLangfuseを1位に選んだのか
オブザーバビリティツールを検索フレームワークやキャッシュAPIより上位にランクするのは直感に反するかもしれない。理由はこうだ。私たちが関わったチームで、オブザーバビリティをスキップしたチームはすべて、後から導入することになった。不可解なハルシネーションや説明のつかないコスト急増のデバッグに数週間費やした後に、だ。
Langfuseは、各LLMコールにどのコンテキストが入力され、コストがいくらかかり、何が返ってきたかを正確に示す。その可視性が、他のすべての最適化を可能にする。どのドキュメントが実際に取得されているか見えなければ、LlamaIndexの検索をチューニングできない。キャッシュのヒットとミスをトレースできなければ、キャッシュによる削減効果を測定できない。出力を比較できなければ、LLMLinguaの圧縮を評価できない。
まずオブザーバビリティから始めよう。その上で、アプリケーションに必要なレイヤーを追加していこう。
コンテキストエンジニアリングスタックの選び方
適切なツールは、何を構築するかによって異なる。以下の判断フレームワークは、一般的なプロジェクトタイプと具体的なツールの対応を示している。
| ユースケース | 検索 | メモリ | キャッシュ | オブザーバビリティ |
|---|---|---|---|---|
| 会話型AI | LlamaIndex + LangGraph | Mem0 | Claudeキャッシュ | Langfuse |
| コーディングエージェント | 該当なし | CLAUDE.md | Claudeキャッシュ | LangSmith |
| エンタープライズRAG | LlamaIndex + LangGraph | Zep | Geminiキャッシュ | LangSmith |
| マルチエージェントシステム | LangGraph | Letta | Claudeキャッシュ | Langfuse |
| コスト重視のプロトタイプ | LlamaIndex | なし | OpenAI自動キャッシュ | Phoenix |
すべてのレイヤーをカバーする単一のツールは存在しない。最高のコンテキストエンジニアリングスタックとは、具体的なユースケースに合わせて組み立てられたものだ。
Techsyでは、AIを活用したアプリケーションのためのコンテキストエンジニアリングスタックの設計を、検索アーキテクチャからエージェントメモリまで支援している。無料相談はこちら。
カスタム対応が必要ですか？
上記の判断フレームワークにプロジェクトがきれいに当てはまらない場合——たとえば、ドメイン固有のメモリ要件と厳格なレイテンシ予算を持つマルチモーダルエージェントパイプラインを構築している場合——汎用的なツール推奨では不十分だ。
それはまさにTechsyが解決する種類の問題だ。私たちは会話型AI、コーディングエージェント、エンタープライズRAGにわたる本番コンテキストパイプラインを構築してきた経験があり、具体的な制約に合ったツール選定を支援できる。AIインテグレーションサービスを見る。AIエンジニアリングチームに相談する。
よくある質問
コンテキストエンジニアリングにはどんなツールが使われますか？
コンテキストエンジニアリングは複数のスタック層にまたがり、各層に専用ツールがある。検索（LlamaIndex、LangGraph）、メモリ（Mem0、Zep）、圧縮（LLMLingua）、キャッシュ（Claude/Gemini/OpenAI API）、オブザーバビリティ（Langfuse、LangSmith）、コーディングエージェントのコンテキスト（CLAUDE.md、AGENTS.md）。すべてのレイヤーをカバーする単一のツールはない。
2026年のベストRAGフレームワークは？
データの取り込みと検索にはLlamaIndex、オーケストレーションにはLangGraph。2026年の本番パターンは両者を併用することで、LlamaIndexが正しいドキュメントの取得を担当し、LangGraphがエージェントの処理を担当する。
最高のAIエージェントメモリツールは？
最速で本番環境に到達したいなら、マネージドのグラフ＋ベクトルAPIを持つMem0。時系列ナレッジグラフが必要なエンタープライズアプリケーションにはZep。エージェントランタイムとメモリ層を完全にオープンソースでコントロールしたいチームにはLetta。
Claudeのプロンプトキャッシュの仕組みは？
メッセージ配列内でcache_controlを使ってキャッシュブレークポイントを指定する。キャッシュされたコンテンツは5分間保持され、ヒットするたびに更新される。キャッシュ読み取りは基本入力価格の10%で、90%の削減になる。キャッシュ書き込みは基本価格より25%高いが、キャッシュエントリごとの一回限りのコストだ。
Geminiのコンテキストキャッシュの仕組みは？
API経由で設定可能なTTL付きのキャッシュを作成する。キャッシュトークンはモデルに応じて75〜90%の割引が適用される（Gemini 2.5では90%）。キャッシュ作成費用、時間単位のストレージ費用、割引された読み取り費用がかかる。最小キャッシュサイズは32,768トークン。
CLAUDE.mdファイルとは？
Claude Codeがすべてのインタラクションの前に読み取る、プロジェクトレベルの指示ファイルだ。コーディング規約、アーキテクチャのコンテキスト、よく使うコマンド、プロジェクト固有のルールが含まれる。/initコマンドはリポジトリをスキャンして自動生成する。コーディングエージェントのためのコンテキストエンジニアリングと考えるとよい。
LangChainとLlamaIndexは併用できますか？
可能であり、むしろ推奨される。LlamaIndexがデータの取り込みと検索（160以上のコネクタ、複数のインデックスタイプ）を担当し、LangGraph（LangChainのエージェントフレームワーク）がオーケストレーション、ツールルーティング、マルチステップ推論を担当する。ネイティブに統合されている。
最高のオープンソースコンテキストエンジニアリングツールは？
オブザーバビリティにはLangfuse（MITライセンス、GitHub 19,000以上のスター）、検索にはLlamaIndex（MIT）、エージェントメモリにはLetta（オープンソースランタイム）、圧縮にはLLMLingua（Microsoft Research）、クリーンな単一フレームワークのRAGパイプラインにはHaystack。
LLMのコンテキストウィンドウコストを削減するには？
3つのアプローチが相乗的に機能する。プロンプトを2〜5倍に圧縮するLLMLinguaなどの圧縮ツール、繰り返しコンテキストのコストを削減するキャッシュAPI（Claudeで90%、Geminiで75〜90%、OpenAIで50%の削減）、そして関連するコンテキストのみをモデルに送信するRAGによる選択的検索だ。
LLMモニタリングにはLangSmithとLangfuseのどちらが良いですか？
ほとんどのチームにはLangfuseが最適だ。オープンソースでMITライセンス、月50,000オブザベーションの無料プランがあり、主要なフレームワークすべてと統合できる。LangChain/LangGraphエコシステムに完全にコミットしていて、チェーンデバッグとの最も密な統合を求めるなら、LangSmithの方が適している。