Claude Codeに「正しそうなのに動かない」コードを書かれて、1時間溶かしたことがあります。
見た目は完璧。
読んでも正しそう。
でも走らせると落ちる。このタイプのバグが一番キツい。
Context7というMCPを入れてから、その頻度が体感で減りました。
3回やり直していたのが、1〜2回で通るようになった、というくらいの温度感です。
この記事は「Context7が神ツール」という話ではありません。
使ってみて気づいたのは、Context7は精度を上げるツールではなく、前提のズレを消すツールだったということです。
期待値の置き方を間違えると、ただトークンを食うだけになります。
体験ログとして、効いた場面、効かなかった場面、落とし穴をそのまま書いておきます。
目次
- Context7に出会う前、Claude Codeの「正しそうなのに動かない」に消耗していた
- 一番キツかった日 — VuetifyでハルシネーションにClaude Codeと1時間溶かした話
- Context7を知った瞬間 — 「またそれ系か」から「これは違う」へ
- Context7の使い方 — `use context7` を付けるだけ
- Context7導入後に起きた静かな変化 — 修正ループが減った
- Context7が効く場面・効かない場面
- Context7の落とし穴 — トークン増加と過信
- Context7は誰に効いて、誰には不要か
- 結論 — Context7はClaude Codeの精度ではなくハルシネーションの「ズレ」を消すツール
- 参考文献
Context7に出会う前、Claude Codeの「正しそうなのに動かない」に消耗していた
Claude Codeは普段使いのメインで、ツール選定の文脈では以前Claude CodeとOpenAI Codexを両方使った比較も書きました。
一方で、どうしても解消できない痛みがありました。それが「ライブラリのバージョン違いハルシネーション」です。
- 存在しないAPIメソッドを普通に書いてくる
- 古いpropsを平気で出してくる
- 最新仕様になっていないライブラリ記述で「一見正しそう」なコードを書く
- 特にフロント（Vue、Tailwind、UIライブラリ）で微妙にズレる
Anthropicの公式ヘルプにも書いてありますが、Claudeモデルにはトレーニングカットオフがあります。
その日以降の仕様変更は学習されていません。
フレームワーク側は週次で動いているのに、AI側の知識は数ヶ月前で止まっている。
ズレが生まれるのは構造的に当たり前です。
ただ、理由がわかっても、実務では毎回コストが発生します。
公式ドキュメントを手動で開いて確認し、StackOverflowを覗き、Claudeに「これ違うよね？」と詰めて再生成させる。
私の運用では、ライブラリが絡む作業では「3回やり直して通る」が実質デフォルトになっていました。
一番キツかった日 — VuetifyでハルシネーションにClaude Codeと1時間溶かした話
一番印象に残っている日があります。
Vuetify系のUIライブラリで画面を組んでいて、Claude Codeが出してきたコードが「見た目は正しい」のに動かない。
調べてみたら、古いバージョンのpropsを使っていました。
私が触っていたのは新しめのバージョンで、propsの名前と挙動が変わっていた。
Claudeは古い知識で、それっぽくコードを書いていたわけです。
ここからが地獄でした。
- 一度読み直しても、コード自体に変な点がない
- ClaudeにURLを貼って「この仕様で書き直して」と言っても、また別の古い書き方が混じる
- 「Vuetify + Tailwind v4の組み合わせに注意」など、公式ブログがわざわざ連携ガイドを出すほど事故りやすい組み合わせだった
気づいたら30分、1時間と溶けていました。
感情としては、バグを踏むより「正しそうなのに間違ってる」ほうがキツい。
自分のコードの読み方まで疑い始めるからです。この種の疲弊は、Claude Codeで踏みがちな失敗パターンとしても以前書きましたが、ライブラリの世代ズレは特に気づきにくい。
これはあくまで私のケースですが、Vuetify公式が「Vite + TailwindCSS v4」専用の連携ガイドを出している事実からも、似た沼に落ちる人は少なくないのだと思います。
Context7を知った瞬間 — 「またそれ系か」から「これは違う」へ
Context7は、Xのタイムラインで海外の開発者が話題にしていたところから知りました。
正直、第一印象は「またMCP系のやつか」でした。
AI界隈、ツールの出現スピードが異常に速いので、正直「これで変わる」というツールが毎週流れてきます。
ただ、調べていくうちに少し引っかかる点がありました。
- 「コンテキストを固定できる」という発想
- 「ライブラリ前提で動く」という設計思想
- Upstash（Redisの会社）が提供元
「精度を上げます」ではなく、「前提を合わせます」という方向性。
これは他のAIコーディング補助とはポジションが違う、と感じました。
Upstashの公式アナウンスを読むと、仕組み自体はシンプルで、「①プロンプトからライブラリ名を検出 → ②公式ドキュメントとコード例を最新版からpull → ③トピックでフィルタ → ④LLMのコンテキストに注入」の4ステップだと説明されています。
つまり、Claudeを賢くしようとしているのではない。
Claudeに渡す前提資料を差し替えているだけ。
この発想が、既存のツールと明確に違いました。
Context7の使い方 — `use context7` を付けるだけ
Claude Codeへの追加は1行で終わります。
claude mcp add context7 -- npx -y @upstash/context7-mcp@latestこれだけです。登録後は、プロンプトの末尾に `use context7` と書き足すと発火します。
Next.js middleware でJWTを検証するコードを書いて。
use context7これで、Context7が該当ライブラリの公式ドキュメントを取りに行き、最新の書き方を前提としてコンテキストに差し込んでくれます。
プロジェクト単位で「ライブラリが絡むときは必ずon」というルールをCLAUDE.mdに書いておく運用も可能です。
ここはObsidianと組み合わせたClaude Codeのナレッジ管理と相性が良い部分で、プロジェクトごとにMCPの使い分けを設定しておくと運用が楽になります。
料金は、2026年4月時点で以下の通りです。
- Free: 月1,000 API calls、公開リポジトリのみ対応
- Pro: $10/seat/月、月5,000 calls、プライベートリポ対応
一点、注意点として書いておきます。Context7の無料枠は、2026年1月に月6,000コールから1,000コールへ縮小されました。以前の感覚で入ると、すぐ上限に当たります。
個人で本気で回すならProが現実的という温度感です。
Context7導入後に起きた静かな変化 — 修正ループが減った
導入後、すぐに派手な変化が起きたわけではありません。
どちらかというと、「あれ、最近やり直し少なくない？」という静かな変化でした。
私の体感ベースで、before/afterを書くとこうです。
- before: UIライブラリが絡むタスクは3回やり直しが常態化
- after: 1〜2回で通ることが増えた
- 感覚値: 「正しそうなのに動かない」に遭遇する頻度が下がった
数字はあくまで私のケースです。「劇的に」「完全に」と書けるほど魔法ではありません。
それでも、1日の中で1〜2回あった「なんで動かないんだよ…」のモヤモヤが、週に数回レベルに落ちるのは、体感として大きい。
そして導入してわかったことがあります。
「Claude Codeは頭が悪い」と思っていた瞬間の大半は、前提がズレていただけでした。
これは雰囲気で書かせるバイブコーディングの限界を考える上でも大事な視点だと思っています。
AIに任せきりの開発は、前提が噛み合っている間はものすごく速い。
でも前提が少しでもズレると、そこから全部が崩れる。
Context7は、その一番下のレイヤーを抑えるツールです。
Context7が効く場面・効かない場面
使い込んでみると、効く場面と効きにくい場面がはっきり分かれます。
効く場面
- UIライブラリ（Vuetify、Tailwind、shadcn/ui など仕様変更が多いもの）
- 新しいフレームワーク（直近で大きくアップデートされたもの）
- API仕様があるもの（外部SDK、REST/GraphQLクライアント）
- npm系のライブラリ全般
- 一言でいうと、「外部仕様への依存が強い」タスクほど効く
効きにくい場面
- 純粋なアルゴリズム・ロジックだけのコード
- 数十行で終わる小さなスクリプト
- 自作モジュール内の処理
- 既存コードのリファクタだけで外部仕様が絡まないもの
この切り分けは大事です。「入れたんだから全部use context7で回そう」は逆効果だと感じています。
外部仕様が絡まないタスクにも注入すると、余計なドキュメントがコンテキストを埋めて、トークンだけ食って効きが出ない、ということが起きます。
私の運用ルールはシンプルで、「外部仕様が絡むときだけON」にしています。
これだけで、効果と消費のバランスが取れます。
Context7の落とし穴 — トークン増加と過信
良い話だけ書くのはフェアじゃないので、痛い部分も書きます。
トークン消費は確実に増える
Context7の仕組み上、ライブラリの公式ドキュメントやコード例をコンテキストに注入するため、プロンプトあたりのトークンは増えます。
具体的な増加量は公式には明記されておらず、ライブラリと質問の規模次第です。
感覚値としては「1質問あたり数百〜数千トークン上乗せされる」くらいのイメージで見ておくのが安全です。
過信すると逆に遅くなる
Context7を入れても、完璧にはなりません。library-idの自動検出があいまいな場合、意図したライブラリとは別の同名ライブラリのドキュメントが差し込まれてしまうこともあります。
「Context7入れてるから大丈夫」と思考停止すると、変なドキュメントで埋まったコンテキストを鵜呑みにして、別のハルシネーションを踏みます。
無料プランの上限が以前より厳しい
前述の通り、2026年1月に無料枠が6,000→1,000に縮小されています。
副業レベルで使うなら月1,000で足りる可能性はありますが、
本業で1日何時間もClaude Codeを回す人は、すぐ上限に当たります。
ロジックだけのコードには効きにくい
繰り返しになりますが、外部仕様が絡まないタスクではほぼ効果が出ません。
「全部につければ良い」ではなく、「効くタスクだけONにする」運用が前提です。
この辺りはAI自動化ツール比較で取り上げた他のMCP系ツールと同じで、万能ではなく、役割が分かれているツールだと思ったほうが運用が安定します。
Context7は誰に効いて、誰には不要か
体験ベースで、向き不向きを整理しておきます。
効く人
- Claude CodeまたはCursorをメインで使っている人
- フロントエンドエンジニア（特にVue / React周り）
- UIライブラリをよく使う人（Vuetify、MUI、shadcn、Tailwindなど）
- npmライブラリを多用する人
- 「正しそうなのに微妙に動かない」に悩まされている人
不要（または優先度が低い）人
- 純粋なアルゴリズム・競技プログラミング中心の人
- 小さなスクリプトだけを書く人
- 外部仕様にほとんど依存しないコードベースで働いている人
- すでに社内ドキュメント検索MCPなどで代替できている人
判断軸は「自分の書くコードで、外部仕様に依存する割合はどれくらいか？」という1点です。
仕様依存が大きい人ほど効きます。
結論 — Context7はClaude Codeの精度ではなくハルシネーションの「ズレ」を消すツール
最後にもう一度、一番伝えたいことを書きます。
Context7を「精度を上げてくれるツール」として期待すると、裏切られます。Claude自体が賢くなるわけではないからです。
Context7がやっているのは、「Claudeに渡す前提資料を、最新のものに差し替える」こと。
これだけです。でも、私が時間を溶かしていたハルシネーションの多くは、Claudeの知能の問題ではなく、前提資料の古さが原因でした。
前提が合っていないから、どれだけ賢く推論してもズレる。それを入口で直してくれるのがContext7です。
- 効くのは「外部仕様が絡むタスク」だけ
- 全部に使うとトークンだけ食う
- 無料枠は以前より厳しくなっている
- 魔法ではない。でも、毎日使うツールで修正ループが減るなら、価値はある
私の運用は「Claude Code + Context7 + プロジェクトごとのナレッジ（Obsidian、CLAUDE.md）」の組み合わせに落ち着きました。
その先の理想像は、「外部仕様の最新性（Context7）＋ 自分のドメイン知識（ローカルナレッジ）＋ ツール連携（MCP）」を自然に組み合わせる状態です。
「Claude Codeに微妙に動かないコードを書かれて1時間溶かしている」という人は、試してみる価値があると思います。
Claudeが急に天才になるわけではありません。
でも「なんで動かないんだよ…」の頻度が減る、という変化は、日々の開発の疲労度にそのまま効いてきます。
Context7は、精度ではなく「ズレ」を消すツール。
期待値をそこに置いたときから、Claude Codeとの距離感が少し変わりました。
