LM Studio x gpt-oss x MCP 第2弾企画─ Context7
前回の記事では、LM Studio に Web Search MCP を組み込み、ローカルLLMがインターネット検索を勝手に実行してくれる様子を検証しました。検索結果をそのまま回答に活かせるのは非常に便利で、多少トークン消費が増えても「使った分だけ情報が新鮮になる」という納得感がありました。
今回はその第2弾として、Context7 MCP を対象に実験します。Context7 は公式ドキュメントや GitHub リポジトリを参照しながら回答を補強する仕組みです。つまり「最新の仕様を踏まえたコード例を出してほしい」という場面で威力を発揮するわけです。
ただし、ここでひとつ注意すべき点が見えてきました。Web Search の場合は発火しても 1,500 トークン前後の消費で収まっていたのに対し、Context7 は わずかな質問でも 5,000 トークン規模に膨らむことがあるのです。しかも「use context7」と明示しなくても、質問内容次第で勝手に発火してしまう。
この挙動は「便利」と同時に「コンテキストを一気に消費してしまうリスク」でもあります。本稿では、Tailwind CSS と Next.js の二つの題材を使い、Context7 MCP の挙動とそのメリット・デメリットを具体的に検証していきます。
Context7とは
Context7 MCP は、LM Studio などの LLM 環境に追加できる拡張モジュールのひとつです。役割はシンプルで、公式ドキュメントや GitHub リポジトリを直接参照し、そこから得た断片をモデルに注入するというもの。
これにより、通常の LLM では曖昧になりがちな「最新仕様」や「正確な引数名」といった部分を、ドキュメント準拠の形で補強できるようになります。たとえば Next.js の middleware 記述や Tailwind CSS のユーティリティクラスなど、バージョンによる微妙な違いを吸収できるのが強みです。
イメージとしては「軽量なRAG（Retrieval Augmented Generation）の代替」。ただし専用のベクトルDBや検索インデックスを用意する必要はなく、Context7 MCP を有効化しておくだけで、対象ライブラリの公式リソースから断片を取ってきてくれます。
サポートされているのは、Next.js や Tailwind CSS といった主要フレームワークのほか、React、Vercel関連ツール、さらには一部の GitHub リポジトリ。仕組み自体が「ライブラリID」と「トピック指定」で柔軟に動くため、公式ドキュメントが GitHub 上で公開されていれば、新しいライブラリでも比較的簡単にフック可能です。
一方で、強力であるがゆえに注意点もあります。必要以上に広い範囲を読み込んでしまうと、回答は冗長になるうえにトークン消費も跳ね上がるのです。この「便利さ」と「重さ」の両面を踏まえ、以降で具体的に検証していきます。
Context7 MCP のセットアップ手順
Context7 を使うには、LM Studio 側で MCP サーバーを登録します。settings.json の mcpServers に追記してください。
設定方法はこの記事あたりを参考に。
1. npx で都度取得する方式（公式推奨・常に最新版）
{
"mcpServers": {
"context7": {
"command": "npx",
"args": [
"-y",
"@upstash/context7-mcp@latest"
],
"autoApprove": true
}
}
}- 常に最新を取ってきたい場合はこちら。
- ただし毎回
npx経由になるので、初回起動がやや遅い。
2. グローバルインストール済みバイナリを直接呼ぶ方式（安定運用向け）
{
"mcpServers": {
"context7": {
"command": "context7-mcp",
"args": []
}
}
}npm install -g @upstash/context7-mcpを事前に実行しておく必要があります。- 一度入れてしまえば
npx不要で、毎回素早く起動できる。 - プロジェクト環境を固定したい場合や、CI など安定運用にはこちらが便利。
どちらの方法でも、LM Studio を再起動すると Integrations に context7 が現れます。Allow を有効にすると、use context7 と明示した場合や質問内容によって自動的に発火するようになります。
context7 が現れ、有効/無効の設定が可能に初回発火時にApprovalの確認が入りますが、すべて Allow で問題ないでしょう。
実験① Tailwind CSS（ライト枠）
まずは軽い題材として、Tailwind CSS を使った「段落テキストを中央寄せする最小クラス」を尋ねてみました。答え自体は単純に text-center なのですが、Context7 の有無でどのように変化するかを観察します。
Context7なし
- 消費トークン：273
- 回答：
<p class="text-center">…</p> - 補足：推定根拠として「Tailwind の公式ドキュメントでは text-center と記載されている」と述べるのみ。
→ 回答は正しいが、根拠は曖昧。
Context7あり（topicを絞った場合）
- 消費トークン：799
- 回答：
text-centerに加え、注意点を整理（レスポンシブ時の挙動や垂直整列との違いなど）。 - 根拠：最後に「Typography」「Text Alignment」といった 公式セクション名を明示。
→ 正確さと裏付けが増し、信頼性が高まった。
Context7自動発火（topic未指定）
- 消費トークン：5088
- 回答：内容は結局
text-centerと同じ。 - 挙動：
use context7と明示していないにもかかわらず、MCPが勝手に発火して公式ドキュメントを読み込みに行った。
→ わずかな質問でも5K規模のコンテキストを消費してしまうことが判明。
考察
この実験で分かったのは、Context7は使い方次第で軽くも重くもなるという点です。
- topicをきちんと絞れば、数百トークン程度の追加で「公式準拠の根拠付き回答」が得られる。
- 一方で、topicを指定せずに放置すると、自動で大規模なドキュメントを読み込み、数千トークンを浪費してしまう。
つまり「回答は同じでも、使い方を誤ると会話の先行きが一気に曇る」──これが Context7 のライト検証から得られた結論です。
実験② Next.js JWT（ガチ枠）
続いては、より実践的な題材として Next.js の middleware による JWT 検証を取り上げます。ここでは「Edge Runtime で動かすこと」「Node 専用ライブラリは禁止」「jose を使って署名を検証すること」という条件を課しました。
Context7なし
- 消費トークン：230
- 回答：
jwtVerify（jose）を使ったサンプルコードを生成。 - 問題点：
matcherが未設定 → 全リクエストに適用されてしまう。- リダイレクト先 URL が
http://example.com/loginと直書き。 - 参照セクションや根拠が提示されない。
→ 軽快で即答だが、公式準拠の精度には欠ける。
Context7あり（topicを指定）
- 消費トークン：数千規模
- 回答：
export const config = { matcher: ['/protected/:path*'] }を明示。- リダイレクトは
new URL('/login', req.url)と公式準拠の書き方に。 - Edge Runtime 向けの非同期検証が強調されている。
- 根拠：最後に「Middleware constraints」「Matcher設定」など 公式セクション名を列挙。
→ トークン消費は重いが、内容は本番でそのまま使える水準に。
考察
- なし：軽い質問なら素早く答えてくれるが、細部は自己流になりがち。
- あり：消費は重いが、公式ドキュメントに沿った正確なコードが得られる。
Tailwind のライト検証では「根拠の有無」で差が見えましたが、Next.js のような複雑な題材では「コードの品質そのもの」が改善されることが確認できました。
使いこなし編
Context7 MCP は便利ですが、使い方を誤ると「ただの質問でも数千トークンを食う」結果になりかねません。ここでは、効率よく活用するためのコツを整理します。
topicの書き方講座
Context7 に渡す topic の指定方法ひとつで、消費トークン量が大きく変わります。
1. 未指定（最も重い）
You
Tailwind CSSで段落テキストを中央寄せにする方法を教えて。
- 消費：5000トークン級
- 挙動：関連しそうな全ドキュメントを読み込む
2. 章名だけ（中程度）
You
use context7
Context7 args:{
"context7CompatibleLibraryID": "/tailwindlabs/tailwindcss",
"topic": "Typography"
}
段落テキストを中央寄せにする方法を教えて。
- 消費：1000トークン前後
- 挙動：Typography章全体を参照する
3. 章名 > 小項目; minimal（軽量）
You
use context7
Context7 args:{
"context7CompatibleLibraryID": "/tailwindlabs/tailwindcss",
"topic": "Typography > Text alignment; minimal example"
}
段落テキストを中央寄せにする最小クラスを答えて。
- 消費：500〜800トークン程度
- 挙動：Text alignment の小節だけに絞って参照
このように「どこまで topic を狭めるか」で、消費トークン量をコントロールできます。カギです。質問に直結する章や小項目を指定することで、過剰なドキュメント注入を避けられます。
ログ挙動の豆知識
MCPを噛ませると、LM Studio のログ出力にも違いが出ます。
- 通常：トークン/秒、総トークン数、応答開始までの時間などが表示される。
- MCPあり：
get-library-docsなどのフェッチログが挟まり、トークン/秒は表示されず、スレッド全体の総トークン消費だけが出る。
これは Context7が裏でドキュメントを注入している証拠とも言えます。数値を正確に比較するのは難しいですが、「なしに比べてどの程度跳ね上がったか」を相対的に見れば十分です。
自動発火のリスク
use context7 と書かなくても、MCPがONになっていると質問内容次第で勝手に発火することがあります。Tailwind の「text-center」の例でも、わずか1行の質問が 5Kトークン消費に化けました。
use context7”を書かなくても自然発火することがあるこのため、
- ライトな使い方 → MCP OFF
- 正確さを求めるとき → ON＋topic指定
という切り替え運用が現実的です。
まとめ
今回の検証で見えてきたのは、Context7 MCP の二面性です。
- 精度と根拠の補強
- Tailwind のシンプルな質問でも「公式セクション名」を添えて答えられる。
- Next.js のような複雑な題材では、コード品質そのものが公式準拠に改善される。
- コンテキスト消費の重さ
- topicを絞れば数百トークンで済む。
- しかし未指定や自動発火では、同じ質問が一気に5Kトークン規模へ。
- その結果、会話コンテキストが急速に曇り、長いやり取りでは不利になる。
- ログの違い
- MCPありでは「トークン/秒」が表示されず、総消費だけが積算される。
- これは裏でドキュメント注入が行われているサインであり、挙動を理解して使う必要がある。
結論
Context7 MCP は、「軽い質問に確実な根拠を添える」、あるいは 「本番コードを公式仕様に沿って生成させる」 場面で強い力を発揮します。
ただし、自動発火による過剰消費のリスクがあるため、実運用では MCPのON/OFF切り替え や topicの適切な指定 が欠かせません。
Web Search MCP が「気軽に便利さを足せる」存在だったのに対し、Context7 MCP は 「強力だが扱いを間違えると会話が破綻しかねない両刃の剣」。その性質を理解した上で、場面に応じた使い分けをしていくのが賢明です。
