Context7：MCPだけでなくSkillとサブエージェントを活用せよ

多くの開発者がContext7をMCP経由で接続し、最新のライブラリドキュメントを参照しています。確かに動きます。コーディングセッションの中で最新のドキュメントがそのまま手に入る。でも代償があります。取得したドキュメントがすべてメインのコンテキストウィンドウに直接流れ込むのです。いくつかのライブラリを調べただけで、コンテキストはあっという間に埋まります。長時間のコーディングセッションでは、パフォーマンスの低下やセッション途中の情報の忘却につながります。

Claude CodeのSkillとサブエージェントを使えばこの問題を解決できないか、ずっと考えていました。実際に試してみると、その差は歴然でした。

素のMCP接続の限界

Context7をMCP経由で直接呼び出すと、ドキュメントの全文がメインコンテキストにそのまま流れ込みます。一回限りのちょっとした確認なら問題ありません。でも実際の作業では、一つだけ調べて終わることなんてほとんどないですよね。

ReactのHookのドキュメントを確認する。次にTailwindのユーティリティ。そしてAstroのAPI。それぞれのレスポンスが前のものの上に積み重なっていきます。コンテキストウィンドウが埋まると、モデルはそれまでの会話内容 - 実際のコード、要件、3つ前のやり取りで決めたアーキテクチャの方針 - を見失い始めます。

Manusチームがアーキテクチャノートで強調していたように、巨大な単一コンテキストは答えではありません。核心は、すべてが同じコンテキストウィンドウに存在する必要はないという点です。

Skillとサブエージェント：分離されたコンテキストでのクエリ

Context7プラグインには、ドキュメント検索をメインコンテキストの外で処理する2つの仕組みがあります。

• Skill：ライブラリやAPIについて質問すると、Context7が自動的に起動します。最新のドキュメントを取得し、特別なプロンプトを書く必要なく回答を返してくれます。検索処理はバックグラウンドで行われます。
• docs-researcherエージェント：これがアーキテクチャの核です。ドキュメントのクエリは分離されたコンテキスト、つまり別のサブエージェント内で実行されます。サブエージェントが検索を行い、関連する情報を抽出し、回答だけを返します。メインコンテキストが生のドキュメントに触れることは一切ありません。

明示的にドキュメントを検索したいときは、以下のコマンドが使えます：

/context7:docs <library> [query]

重い処理をメインコンテキストの外に保ちつつ、直接的なコントロールも可能にしてくれます。

インストール方法

Claude CodeにContext7プラグインをインストールするには：

/plugin marketplace add upstash/context7
/plugin install context7-plugin@context7-marketplace

設計思想の違い

同じContext7バックエンドを使いながら、2つのアプローチは実際の使用感がまったく異なります。

素のMCP：ドキュメントを調べるたびにメインコンテキストが膨らみます。3回検索すれば、コンテキストウィンドウのかなりの部分を消費しています。セッション中盤には、プロジェクトの実際の状態に対するモデルの記憶力が明らかに低下します。

Skill＋サブエージェント：ドキュメント検索は分離されたコンテキストで行われます。メインコンテキストに返されるのは抽出された回答だけ - 特定の関数シグネチャ、設定オプション、使用例 - です。生のドキュメントがメインコンテキストに入ることはありません。

このパターンは2つの問題を同時に解決します。最新のドキュメントを取得することでナレッジカットオフの問題に対処し、しかもそれを長時間のコーディングセッションを不安定にすることなく実現します。コンテキストのコストを払わずに、最新の情報が手に入るわけです。

この原則はContext7に限った話ではありません。AIセッションに大量の外部コンテンツを取り込む場面では常に、それがメインコンテキストに存在すべきなのか、それとも分離して処理し要約だけを返せるのかを考えるべきです。「分離して要約する」というたった一つのアーキテクチャ上の判断が、何時間もシャープに使えるセッションと、途中で何を作っていたか忘れ始めるセッションの分かれ目なのです。