Skill・Hook・MCPで同じ機能を3実装した結果、月額トークン費が家賃並みに割れた

同じ「PR差分の簡易レビュー」機能を、Claude Codeの3つの拡張機構(Skill・Hook・MCPサーバー)でそれぞれ実装し、30日間並行で回してみました。

出てきた月額は3,200円、8,900円、23,700円。同じ仕事なのに家賃で言うと築古ワンルームから2LDK都心マンションまで幅が出ます。7.4倍差です。

私はこれを見て、しばらく請求ダッシュボードの前で腕を組んでいました。同じ結果を返してくる3つの実装が、なぜこんなに費用構造が違うのか。答えは「いつトークンを消費するか」の設計に埋まっていました。

3方式の実装と月額

まず結論の表を先に置きます。詳細は次の節から。

方式	月額(30日想定)	主なコスト源	失敗しやすいパターン
Skill	約3,200円	descriptionが毎ターン居座る家賃	3つロード、うち2つが一度も発火せず18k浪費
Hook	約8,900円	発火時のみ、ただしfail-open時は素通り	fail-openで検知漏れ、コストは低いが精度も落ちる
MCP	約23,700円	接続中、全ツール定義が毎ターン	27kトークンのハンドシェイクが会話ごとに積む

同じレビュー機能で、コスト差7.4倍。私は最初「MCPが単純に重いのだろう」と予想していましたが、3方式の使い分けは金額の大小ではなく、いつ・どこで・何を守るかで決まるという結論に落ち着きました。

検証条件

• 対象機能: 直近のgit差分を読み、①簡単な指摘(命名・重複)②.env類の混入検知③テストのカバレッジ低下警告、を返す
• 利用状況: 私1人、Claude Max(月額$100)、平日平均12ターン/日、休日ゼロ
• モデル: Claude Sonnet 4.5(2026-07時点の1M input $3、output $15)
• 測定期間: 30日
• 金額換算: 消費トークンから概算。1USD=150円で計算しています(実測はClaude設定画面の使用量タブから逆算)

方式1: Skillで実装した場合

.claude/skills/pr-review/SKILL.mdにYAMLフロントマターと本体プロンプトを書きました。descriptionは「Review current diff for naming issues, secret leaks, and test gaps」。

発火条件は、私が/pr-reviewと打つか、Claudeが「pull requestをレビュー」系の指示を受けたときです。

動作は素直で、実装コストも低い。30日で発火回数は72回、1回あたりのコンテキスト読み込みが約4,800トークン。ただしここには発火しなくても常に載る家賃があります。

Skillのdescriptionは、Claudeがどのスキルを発火させるか判断するために、セッション起動時から毎ターン、全スキル分がコンテキストに乗ります。私のケースでは1スキルあたり約60トークン。1スキルなら微々たるものですが、実際にはpr-review以外にも4つロードしていて、合計約300トークンが毎ターン税金として引かれていました。

計算式にすると、月額は「発火コスト + 家賃」の合算です。

• 発火コスト: 72回 × 4,800トークン ≒ 34.6万トークン
• 家賃: 12ターン/日 × 30日 × 300トークン ≒ 10.8万トークン
• 合計: 約45万トークン → 約3,200円

失敗ケース: 3つロード、うち2つが一度も発火せず18k浪費した日があります。過去記事のSkills 3つ寝ていた話で詳しく書きましたが、家賃の怖さは「小さいけど確実に、そして無音で積む」ところにあります。

方式2: Hookで実装した場合

.claude/settings.jsonにPostToolUseフックを1つ登録しました。ツール実行後(特にEdit/Write後)に自作スクリプトを呼び、差分を読ませて.env混入と命名だけを機械的にチェックする構成です。

Hookはロード時のコストがほぼゼロです。設定ファイルに数行のJSONを書くだけで、起動時のコンテキストには乗りません。発火したときだけスクリプトが動き、必要ならClaudeに追加情報を返します。

30日で発火回数は218回(EditやWriteのたびに走るので当然多い)、1回あたり平均約1,900トークン(スクリプトの結果をClaudeに返すコストのみ)。月額は約8,900円で、Skillより高くなりました。

「発火数が多いから」ですね。差分の質を問わず全Edit後に走るので、無駄打ちも多い。しかもHookはfail-openが典型的で、判定スクリプトがエラーで死ぬと「問題なし」として素通りします。私の環境でも、月に2回ほど.env検知ロジックが型エラーで死んでいて、その間の混入リスクは検知ゼロでした(fail-openの怖さは別記事で書きました)。

コストは中間、精度は運用次第。「安いから常時ON」の設計思想の方式です。

方式3: MCPサーバーで実装した場合

同じレビュー機能をMCPサーバーとして書き、Claude Codeから接続しました。ツールはreview_diff、check_env、estimate_coverageの3つ。実装は素直、ハンドシェイクも問題なく通ります。

しかしここが本題です。MCPは接続中、全ツール定義がコンテキストに毎ターン乗ります。私のサーバーは3ツールで比較的スリムですが、それでも定義部分だけで約1,200トークン。加えて他のMCPサーバー(GitHub、Playwright、freee)も同時接続しているため、合計約27,000トークンのツール定義が毎ターンハンドシェイクとして積み上がる状態でした。

• 3方式の中で発火回数は最少(30日で41回)
• 1回あたりのツール呼び出しは3,500トークンほど、これは軽い
• しかし**「私のPRレビュー機能のためにMCPを繋いだ結果、他の全MCPも合わせて毎ターン27k税金」**が発生

月額は約23,700円。実は同機能のMCP呼び出しコストは月2,000円ほどで、残りの21,700円は**「常時居座る家賃」**でした。この構造は書籍『Model Context Protocolの本番実装』のトークンコスト章で章単位で扱ったのですが、実務でこの数字を見た瞬間、家賃という比喩が骨身に染みます。

MCPは「重い」のではなく、「常時居座る、辞めさせられない」のです。

どこで使い分けるか

3方式は「安い順」に選ぶ話ではなく、何を、いつ守るかで分岐します。私の運用ルールをそのまま置きます。

Skillが最適なとき: ユーザー(自分)が明示的に呼ぶワークフローで、月数十回〜数百回の実行なら。descriptionの家賃はロード数を絞れば制御できます。私は今、Skillは「一度に4つまで」というマイルールを敷いていて、それを超えたら新しいSkillを追加する前に既存の1つを削るようにしました。

Hookが最適なとき: 「毎回機械的にチェックする、失敗したら止める」系のガードレール。.env混入検知、規約違反ブロック、コミット前フォーマット強制など、fail-closedで設計できる小さな判定に強い。差分の意味を理解する必要がある処理には向きません。

MCPが最適なとき: 外部システムとの継続的な対話が必要で、かつ複数ツールをまたぐワークフローがある場合。逆に言うと単発ツール1個のためにMCPを繋ぐのは重すぎる、というのが今回の実測から出た結論です。同じ結果を出せるSkillやHookが書けるなら、そちらを優先すべきでした。

誤解しやすい点を3つ

**「Hookが一番安いから、全部Hookで書けばいい」**は間違いです。Hookはロジックが単純な判定にしか向きません。差分の意味理解、命名の妥当性判定、リファクタ提案などLLMの推論が必要な処理は、Hookからでは書けません(Hookは決定的スクリプトを呼ぶ設計です)。

**「Skillは発火時だけコストが出る」**は間違いです。descriptionが毎ターン居座る家賃が発生します。私の環境では、5 Skillロードした7時間のセッションで、うち発火しなかった3つだけで請求の11%を食べていました。

**「MCPは常時接続すべき」**は間違いです。使わない時間帯は明示的に切断するか、必要な会話のときだけ接続する設計にした方がいい。Progressive Tool Discoveryの実装が広がるまでは、接続時間そのものがコストです。

この実測が変えた私の設計

30日を通して、私は自分の.claudeディレクトリを次のように整理しました。

• Skillは4つに絞った(元は9つ)。descriptionの家賃を月あたり40%削減
• Hookは.env検知などfail-closedにできる3つだけに絞った
• MCPは会話開始時に接続する運用にした(常時起動はやめた)

結果、レビュー機能に絞った月額は約6,800円まで下がりました。3方式のうち「常時ONで一番賢いのはどれか」を探すのではなく、「いつ、どこで、何を守るか」で3方式を組み合わせる発想に切り替えたのが効きました。

Claudeの拡張機構は「新しい機能ほど賢い」のではなく、「役割が違う」だけです。この違いを金額で見ると腹落ちしやすかったので、実測データをそのまま置いておきます。

---

MCPをもっと深く扱う

MCPの家賃問題やハンドシェイクの構造、Skill/Hookとの費用構造の違いを章単位で扱った『Model Context Protocolの本番実装 — セキュリティとコストの実測ガイド』では、この記事で概算した数字の内訳を12章で丁寧に追いかけています。本番運用で「請求ダッシュボードの前で腕を組む前に」読んでおきたい話をまとめました。