プラグインを入れすぎてコンテキストが膨らむ、というのは Claude Code を使い込むと必ずぶつかる壁だ。入れた後で「重い」と気づいても遅い。/plugin の marketplace browse 画面が、インストール前に投影コンテキストコストを見せてくれるようになった。前日のストックから消化する。
結論を先に
ブラウズ画面で、各プラグインが会話に乗せてくるトークン量の見積もりが出る。per-turn(毎ターン載る固定コスト)と per-invocation(呼び出したときだけ載るコスト)が分かれて表示される。だから「常駐で重いやつ」と「使うときだけ重いやつ」を、入れる前に区別できる。
これが効くのは、コンテキストの予算管理を「事後」から「事前」に動かせる点だ。私は今まで、入れて重くなってから外す、を繰り返していた。その往復が消えた。
per-turn と per-invocation の違いがキモ
ここを混同すると判断を誤る。per-turn は、そのプラグインを入れているだけで毎ターンのプロンプトに載るコスト。システムプロンプトに常駐するツール定義やスキルの説明文がここに来る。per-invocation は、実際にそのツールを呼んだターンだけ載るコスト。
つまり、per-turn が大きいプラグインは「使わなくても重い」。これが一番たちが悪い。逆に per-invocation 中心なら、入れておいても普段は軽く、使うときだけ膨らむ。常駐させるか、必要なときだけ有効化するか、の判断材料になる。
実際に見た手順
/plugin
# Browse / Discover に入り、各プラグインの詳細を開く詳細ペインに、コマンド・エージェント・スキル・hooks・MCP/LSPサーバーの一覧と並んで、投影トークンコストが出る。私はマーケットプレイスの上位20個ほどを片端から開いて、per-turn の数字をメモしていった。
実測結果(数値)
手元で見えた範囲の傾向を出す。数字はプラグインの構成で変わるので、あくまで一例だ。
- 軽量なスラッシュコマンド系: per-turn 約120〜400トークン。常駐させても誤差。
- MCPサーバーを複数束ねた統合系: per-turn 約2,800トークン。ツール定義が丸ごと載るため重い。これを3つ入れると、何もしなくても毎ターン8千トークン超が消える計算になる。
- スキル中心の大型プラグイン: per-turn は約600トークンと意外に軽く、per-invocation 側に約4,500トークン寄っていた。使うときだけ重いタイプ。
この3つ目のような分布が、まさに事前表示の価値だ。per-turn だけ見れば軽いので常駐候補。重さは使った瞬間にだけ来る。逆に2つ目は、常駐ではなく必要なときだけ有効化する運用に回したくなる。数字を見てから決められる、これに尽きる。
限界と注意点
表示はあくまで見積もりだ。実際の消費は、ツールが返すデータ量や会話の長さで上下する。MCPサーバーが大量の検索結果を返せば、見積もりを軽く超える。だから「per-invocation 4,500」と出ていても、それは下限に近いと考えたほうがいい。
それと、見積もりが出るのは対応したマーケットプレイス経由のプラグインに限られる。手元で野良管理しているプラグインや、古いマーケットプレイスでは数字が出ないこともあった。全プラグインを横並びで比較できるわけではない、という点は頭に置いておきたい。
私見
これは、npmで bundlephobia を見てから依存を入れるかどうか決める文化に近い。サイズを見ずに入れて、後でバンドルが太って気づく。あの不毛さを、Claude Code のコンテキスト管理でも繰り返していた。事前にコストが見えるだけで、判断の質が変わる。
個人的には、per-turn の合計に自分なりの上限を決めておくのを勧めたい。私は常駐プラグインの per-turn 合計を5千トークン以内に収める、という線を引いた。これを超えそうなら、新しく入れるときに何かを外す。コンテキストは有限の予算だ。予算管理は、入れる前にしかできない。
次に試すこと
この per-turn 合計を定期的に棚卸しする運用に乗せたい。月に一度、入れているプラグインのコストを並べて、使っていない常駐を外す。バンドルの定期ダイエットと同じ発想だ。数字が見えるようになった今なら、棚卸しもただの作業に落とせる。
