Claude Code: 公式MCPを補完するSkills設計パターン

1 はじめに
2 TL;DR
3 こんな人に読んでほしい
4 公式MCPをSkillsで補完する汎用パターンの発見
5 システム利用者による技術選択
- 5.1 選択肢A：利用者が複数（社内共有レベル）→ アプリ化
- 5.2 選択肢B：利用者が個人〜チーム → 小さいワークフロー
6 判断：個人開発 → Skills採用
7 さらなる選択：公式MCP vs 自作MCP vs Skill
- 7.1 比較表（2025年版）
- 7.2 判断プロセス（2025年版）
8 実装例：Supabase公式MCPを補完【700行、30+コマンド】
- 8.1 汎用的な実装アプローチ（3ステップ）
9 成果：UI開発工数の大幅削減
10 汎用性：公式MCPを補完する展開
- 10.1 補完パターンの適用例
- 10.2 実装パターンは全て同じ
11 まとめ
12 参考リンク
- 12.1 公式ドキュメント
- 12.2 関連ブログ

はじめに

ども！Claude Codeにべったりな龍ちゃんです。

2025年、Claude CodeのMCP対応が進み、GitHub、Slack、Supabase、Firebase等、多くのサービスで公式MCPサーバーが利用可能になりました。

しかし実際のプロジェクトでは、公式MCPだけでは不十分なケースが多々あります：

カスタムビジネスロジック: 重複検出、データ検証、複数テーブル統合、マイグレーション処理
トークン最適化: MCPは4サーバーで55.7k (27.9%)消費（※1）
独自要件: 社内システム固有の処理、セキュリティ要件

本記事では、公式MCPを基盤として、不足部分をSkillsで補完する汎用的なパターンを、Supabaseの実例（700行Skill、30+コマンド）で解説します。しかも、フロントエンド開発を一切スキップして実現できました。

※1: 実測データによると、MCPサーバーは大量のトークンを消費する傾向があります。
よく使ってたMCPはNotionだったんですけど、こいつトークンバカ食いするんですよね。

普通、カスタムビジネスロジックを人間が使えるようにしようと思ったら、Reactでフロントエンド開発して、デザインシステム作って、UX設計して…って、2〜3週間は覚悟しますよね？（AIを活用することで開発の工数を抑えてもそれでも大変！）

でも、こう考えれば良いと気づいたんです：

公式SDK/APIをラップして自作Clientを作成（カスタムビジネスロジック実装）
自作ClientをCLIツールでラップ
CLIツールの使い方をSkillsとして定義
Claude Codeが「UIとして機能」する

この汎用的なパターンを使えば、公式MCPで不十分な場合でも、カスタムビジネスロジックをClaude Codeと統合できます。

Supabase、Firebase、社内API等…全て同じ4層構造（公式SDK → 自作Client → CLI → Skill）のアプローチです。この発想で、全てが変わりました。

TL;DR

この記事で分かること：

公式MCPを補完する3つのユースケース（2025年版）
1. カスタムビジネスロジック: 重複検出、データ検証、複数テーブル統合（700行Skillの実例）
2. トークン最適化: MCP 55.7k (27.9%) vs Skills Progressive Disclosure
3. 独自要件: 社内システム、セキュリティ要件、レガシーシステム
汎用的な補完パターン: 公式SDK → 自作Client → CLI → Skill の4層構造
- 対象: 公式MCPでカバーされないカスタムロジック
- 実装例: Supabase（公式MCP + 700行Skill）
利用者数による技術選択の判断基準
- 社内共有レベル: アプリ化（Streamable HTTP/WebSocket + Function Calling/MCP自作）
- 個人〜チーム: Claude Code + Skills
実装パターン: 短時間で完成
- Step 1: カスタムビジネスロジックを自作Clientに実装
- Step 2: CLI化（Click等）
- Step 3: Skill登録（Markdown）
アプリ化をスキップすることで工数を大幅削減
- アプリ化（一般的見積）: 128-192時間（16-24日）
- Skills化（実測例）: 数時間〜1日
- 削減の理由: UI開発をスキップし、Claude Codeを操作インターフェースとして活用
MCP vs Skillの判断基準を実例で解説

重要な前提条件:

対象サービスのAPI/SDKが存在する
Python等のプログラミング基本知識
Claude Codeの基本操作を理解している

こんな人に読んでほしい

✅ 公式MCPでは不十分なカスタムビジネスロジックを実装したい開発者
✅ データ検証、重複検出、複数テーブル統合等の独自処理が必要な人
✅ 社内APIやレガシーシステムをClaude Code対応したい開発者
✅ MCPのトークン消費を最適化したい人（4サーバーで27.9%消費に悩んでいる）
✅ 個人〜チームレベルでツールを使いたい人（大規模なアプリ化は不要）
✅ ビジネスロジックが固まっていない段階で、小さく検証しながら開発したい人
✅ リモートMCP vs 自作MCP vs Skillで迷っている人

公式MCPをSkillsで補完する汎用パターンの発見

ある日、私はこんな課題に直面しました：

課題:

Supabaseに公式MCPサーバーが存在するが、カスタムビジネスロジック（重複検出、データ検証、複数テーブル統合）は提供されない
でも、フロントエンド開発で専用UIを作るのは時間がかかりすぎる
自作MCPサーバーを立てるのもインフラ管理が面倒

まず確認すべきこと（2025年版）:

公式MCPサーバーで十分か？
- GitHub、Slack、Notion、Supabase、Firebase等は公開MCPサーバーが存在
- → 基本操作なら公式MCP使用（2024年11月のMCP発表以降、リモートMCPサーバーが順次展開）
- 参考: MCP Servers Directory
公式MCPで不十分な場合:
- カスタムビジネスロジック: 重複検出、データ検証、複数テーブル統合、マイグレーション
- トークン最適化: MCP 4サーバーで55.7k (27.9%)消費を回避したい
- 独自要件: 社内API、レガシーシステム、セキュリティ要件
- → 本記事の汎用パターン（Skillsで補完）

発見した汎用パターン（公式MCPを補完する場合）:

公式SDK/APIをラップして自作Clientを作成（カスタムビジネスロジック実装）
自作ClientをCLIツールでラップ
Skillsとして使い方を定義

→ この3ステップで公式MCPを補完し、カスタムロジックをClaude Codeと統合可能

今回の実例：Supabase公式MCPを700行Skillで補完:

公式Supabase MCPでは提供されないカスタムロジックを実装
Supabase Python SDK（公式）をラップして自作Supabase Clientを作成
重複検出（find-duplicates）、データマイグレーション（merge –dry-run）、統計分析（stats）等を実装
別プロジェクトでの知見を活かして関数ベースのインターフェースで実装
自作ClientをCLIツールでラップ
Skillsとして提供（700行、30+コマンド）

✅ フロントエンド開発なし
✅ MCPサーバー構築なし
✅ 短時間で運用開始

読者への問いかけ: あなたが実装したいカスタムビジネスロジック、ありませんか？この汎用パターンなら、公式MCPを補完できます。

システム利用者による技術選択

さて、外部サービスやシステムに人間がアクセスできるようにするには、どんな選択肢があるでしょうか？

これは、Supabaseだけでなく、GitHub、Slack、AWS、社内API…あらゆるサービスとの接続で共通する判断です。

選択肢A：利用者が複数（社内共有レベル）→ アプリ化

想定シナリオ: 複数チームで使う、社内の共通ツールにする

技術スタック:

フロントエンド：React等でWebアプリ開発
バックエンド：Streamable HTTP/WebSocket + Function Calling or MCP
デプロイ：Azure/AWS等

※MCP仕様では2025年3月にSSEトランスポートが非推奨化され、Streamable HTTPに置き換えられました。

開発工数（一般的な見積もり）: 16-24日（128-192時間）

※フルスタックWebアプリケーション開発（React + MCP統合）の一般的な工数。プロジェクトの複雑性により変動します。

要件定義: 2-3日
UI設計・フロントエンド開発: 10-13日（デザインシステム構築含む）
バックエンド統合: 2-3日
テスト・デバッグ: 2-3日

問題点:

⚠️ 時間がかかる: 16-24日の開発期間
⚠️ 柔軟性がない: UIを作った後のビジネスロジック変更が大変
ビジネスロジックを変更 → UIも変更 → 再設計・再実装
小さい単位での試行錯誤ができない
使いながら要件を整理する、ということができない

選択肢B：利用者が個人〜チーム → 小さいワークフロー

想定シナリオ: 自分だけ、またはチーム内での共有（Skillsファイル共有）

技術スタック:

CLI：Click等でコマンドラインツール作成
Skills：Claude Code Skillsで使い方を定義
共有：.claude/skills/ディレクトリを共有

開発工数: 数時間〜1日

利点:

✅ 即座に使い始められる
✅ ビジネスロジックだけを柔軟に変更できる
✅ 小さく試行錯誤、使いながら要件を整理

判断：個人開発 → Skills採用

私の状況はこうでした：

判断基準:

利用者：自分だけ
要件：まだ固まっていない（使いながら整理したい）
ビジネスロジック：頻繁に変更する可能性
デモ：操作を見せたいが、フロントエンド開発は避けたい

→ 選択肢B（Claude Code + Skills）を採用

特に、ビジネスロジックが固まっていない段階でUIに投資するリスクを避けたかったんです。

さらなる選択：公式MCP vs 自作MCP vs Skill

選択肢B（Claude Code + ワークフロー）の中でも、実は技術選択肢が3つあります（2025年版）：

公式MCP (Remote MCP): 既存の公開MCPサーバーを利用（2024年11月〜順次展開）
自作MCP (Model Context Protocol): 自分でMCPサーバーを実装
Skill: Claude Code専用のツール統合（Markdownファイル）

公式MCPサーバーが存在し、基本操作で十分な場合は、公式MCPが最も簡単です。本記事のパターンは、公式MCPで不十分な場合（カスタムビジネスロジック、トークン最適化等）の選択です。

比較表（2025年版）

項目	公式MCP	自作MCP	Skill
前提条件	公開MCPサーバーが存在	MCPサーバーを自作	公式MCPで不十分 or MCPが存在しない
実装難易度	最低（OAuth認証のみ）	高（Pythonライブラリ、サーバー起動）	低（Markdown 1ファイル）
学習コスト	最低	高	低
所要時間	数分	1-2日	数時間
対応環境	Claude Desktop統合	Claude Desktop統合	Claude Code専用
型安全性	高	高	–
デバッグ	易	難	易
適用範囲	公開MCPがあるサービスの基本操作	外部システム連携	カスタムビジネスロジック、プロジェクト固有ツール
運用コスト	$0（リモート）	高（サーバー稼働）	$0（ローカル）
トークン消費	多い（※）	多い（※）	少ない（Progressive Disclosure）

（※）MCPのトークン消費問題: 4つのMCPサーバーで55.7k トークン（27.9%）消費という実測例が報告されています。1つのMCPサーバーにつき10-20個のツール定義があるが、実際に使うのは1-2個だけという無駄が発生します。SkillsはProgressive Disclosure（段階的開示）により、この問題を回避できます。起動時にスキルの名前と説明のみを読み込み、必要に応じて完全な内容を段階的にロードします。

判断プロセス（2025年版）

ステップ1: 公式MCPサーバーの確認
→ Supabase公式MCPサーバーが存在（https://mcp.supabase.com/mcp）、基本CRUDは対応可能

ステップ2: 公式MCPで十分か？
→ カスタムロジック（find-duplicates、merge –dry-run、stats、validate）は公式MCPにない → 不十分

ステップ3: 自作MCP vs Skill
→ 使用者1人、ビジネスロジック検証、スピード重視、運用コスト$0 → Skill採用

実装例：Supabase公式MCPを補完【700行、30+コマンド】

それでは、公式MCPを補完する汎用パターンを具体例で見てみましょう。

今回の実装対象: Supabase（公式MCP + カスタムビジネスロジック）
所要時間: 数時間〜1日（実測値の一例として参考）
公式MCPの状況: 基本CRUD操作は公式MCPサーバー（https://mcp.supabase.com/mcp）で対応可能
Skillで補完する内容: 重複検出（find-duplicates）、データマイグレーション（merge –dry-run）、統計分析（stats）、整合性チェック（validate）等
成果物: 5テーブル、30+コマンド、約700行Skill

汎用的な実装アプローチ（3ステップ）

Step 1: 自作ServiceClient作成

公式SDK/APIをラップして、カスタムビジネスロジックを実装
例: Supabase Python SDK → 自作Supabase Client（重複検出、統計分析等）
他サービス: PyGitHub/slack-sdk/boto3等をラップ

Step 2: CLI作成

自作ClientをClick等でCLIツール化
例: db posts list、db hashtags merge --to ID --from IDs
レイヤー構造: Skill → CLI → 自作Client → 公式SDK → 外部サービス

Step 3: Skill登録

Markdownファイルでコマンド使用方法を定義
Progressive Disclosure（段階的開示）で効率化：起動時にスキル名と説明のみ読み込み
例: .claude/skills/x-posts-manager.md（700行）

なぜClientレイヤーを作るのか？

公式SDKを直接使わず、自作Clientを挟むことで：
カスタムビジネスロジックをカプセル化
プロジェクト固有の処理を統一的に管理
関数ベースのインターフェース等の独自実装を追加可能

詳しい実装方法は、Claude Code Skills 実装ガイドを参照してください。

成果：UI開発工数の大幅削減

選択肢A vs 選択肢Bを比較してみましょう。

選択肢A：アプリ化（社内共有レベル）- 一般的な工数

要件定義（2-3日） → UI設計（3-5日） → フロントエンド開発（7-10日）
→ バックエンド統合（2-3日） → テスト（2-3日）
└─────────────── 16-24日（128-192時間） ──────────────┘

※フルスタックWebアプリケーション開発の一般的な工数見積もり

選択肢B：Skills化（個人〜チーム）- 実測例

CLI実装 → Skill化 → テスト
└──────── 数時間〜1日 ────────┘

※プロジェクトの複雑性により変動。Supabaseプロジェクトでは約8時間（1日）の実測例あり

削減効果の比較

項目	選択肢A（アプリ化）※一般的見積	選択肢B（Skills化）※実測例	削減内容
開発時間	128-192時間	数時間〜1日	UI開発をスキップ
工数	16-24人日	0.5-1人日	大幅削減
フロントエンド開発	7-10日	0日	スキップ
UI設計	3-5日	0日	スキップ
運用開始	16-24日後	即日〜1日	迅速な立ち上げ

削減の理由:

✅ React等のフロントエンド開発をスキップ
✅ デザインシステム構築が不要
✅ UX設計・テストが不要
✅ Claude Codeが「人間が使うUI」として機能

得られた柔軟性:

🔄 ビジネスロジックだけを変更できる（UIの再設計不要）
🔄 小さい単位で試行錯誤できる
🔄 使いながら要件を整理できる

重要: この削減は「AIツールによる開発速度向上」ではなく、「UI開発というアプローチ自体を変えたこと」による効果です。

フロントエンド開発をスキップして、短時間で運用開始できるんです。そして、後から自由に改善できる柔軟性も手に入れました。

汎用性：公式MCPを補完する展開

この汎用パターンの最大の価値は、公式MCPが存在するサービスでも、カスタムビジネスロジックで補完できることです。

補完パターンの適用例

公開MCPが存在するサービス（カスタムロジックで補完）:

Supabase: 基本CRUD（公式MCP）+ 重複検出・統計分析・整合性チェック（Skill）
Firebase: Firestore基本操作（公式MCP）+ 複数コレクション横断・セキュリティルール検証（Skill）
GitHub: Issue/PR操作（公式MCP）+ カスタムラベル付け・複数リポジトリ横断分析（Skill）
Slack: メッセージ送信（公式MCP）+ メッセージ集計分析・カスタム通知ロジック（Skill）

公開MCPが存在しないサービス（Skillで全て実装）:

社内API、レガシーシステム、管理ツール、独自開発サービス

補完が必要な4つの理由:

カスタムビジネスロジック（公式MCPで提供されない独自処理）
トークン最適化（MCP 55.7k消費を回避）
セキュリティ要件（社内ネットワーク内でのみ動作）
小さく検証（ビジネスロジック固まっていない段階での試行錯誤）

参考: MCP Servers Directoryで公式MCPサーバーの有無を確認できます

実装パターンは全て同じ

どのサービスでも：

公式SDK/APIをラップ → 自作ServiceClient作成（ビジネスロジック実装）
CLI化 → 自作ClientをClick等でラップ
Skill登録 → Markdownで使い方定義

→ Claude Codeから操作可能に

レイヤー構造の利点:

公式SDK: サービス通信の実装を提供（変更不要）
自作Client: プロジェクト固有のビジネスロジックを実装
CLI: コマンドラインインターフェースを提供
Skill: Claude Codeとの統合を提供

フロントエンド開発をスキップしつつ、あらゆるサービスをClaude Code経由で操作できるようになります。しかも、自作Clientレイヤーでビジネスロジックをカプセル化できるため、柔軟性も高いです。これは、個人開発〜チームレベルの開発において、強力なアプローチです。

まとめ

今回は、公式MCPを補完するSkills活用パターンを紹介しました。

核心的な発見

✅ 2025年版の判断フロー:

公式MCPで十分か確認 → 基本操作なら公式MCP使用（最も簡単）
公式MCPで不十分な場合 → 本記事の補完パターン（Skillsで拡張）

✅ 3つの補完ユースケース:

カスタムビジネスロジック: 重複検出、データ検証、複数テーブル統合
トークン最適化: MCP 55.7k (27.9%)消費を回避
独自要件: 社内システム、セキュリティ要件

✅ 汎用的な補完パターン: 公式SDK → 自作Client → CLI → Skill の4層構造

✅ レイヤーの役割:

公式SDK: サービス通信を提供
自作Client: カスタムビジネスロジックをカプセル化（関数ベースのインターフェース等）
CLI: コマンドラインインターフェース提供
Skill: Claude Code統合、Progressive Disclosure（段階的開示）

✅ 実装例（Supabase）: 公式MCP + 700行Skill、フロントエンド開発なし

公式MCP: 基本CRUD操作
Skill: find-duplicates、merge –dry-run、stats、validate等
実装時間: 数時間〜1日（実測例として参考）

✅ Skillの優位性:

Progressive Disclosure（段階的開示）によりトークン消費を大幅削減（MCP: 55.7k vs Skill: 起動時は名前と説明のみ）
運用コスト $0（ローカル完結）
実装時間数時間〜1日（自作MCP: 1-2日）

✅ UI開発工数削減: アプリ化（一般的見積: 128-192時間）→ Skills化（実測例: 数時間〜1日）

✅ 柔軟性: UIがないので、ビジネスロジックだけを小さく検証・変更できる

既存ブログとの違い

以前書いたClaude Code Skills 実装ガイドでは、「Skillの作り方（How to）」を解説しました。

今回は、「公式MCPを補完する汎用パターン（What you can achieve）」と「Skillに至った経緯（Why & 判断プロセス）」を中心に語りました。

今すぐできること

実装したいカスタムビジネスロジックを明確にする: 重複検出、データ検証、複数テーブル統合、統計分析…等
公式MCPサーバーの有無と機能を確認:
- MCP Servers Directoryで検索
- 公式MCPで十分 → 公式MCP使用（最も簡単）
- 公式MCPで不十分 → 次のステップへ（カスタムロジック補完）
- MCPがない → 次のステップへ（全て実装）
SDK/APIを確認: 対象サービスのPython SDK、REST APIドキュメントをチェック
4層構造で実装（数時間〜1日目安）:
- 公式SDK: 既存のライブラリを利用（Supabase SDK、firebase-admin等）
- 自作Client: 公式SDKをラップしてカスタムビジネスロジック実装
- CLI: 自作ClientをClickでラップ
- Skill: Markdownで使い方定義（Progressive Disclosure対応）
公式MCP vs 自作MCP vs Skillで迷っている人: この記事の判断フローを参考に
フロントエンド開発を避けたい人: Skills化で即座に運用開始

この汎用パターンを覚えておけば、公式MCPを補完し、カスタムビジネスロジックをClaude Codeと統合できます。

皆さんも、実装したいカスタムロジックがあったら、まず公式MCPサーバーの有無と機能を確認し、不十分ならこの補完パターンを試してみてください！