MCP か CLI か API 直叩きか — 個人開発でエージェント連携を設計する判断基準 2026

API 直叩きで 3 プロジェクトを超えたあたりから、毎回同じコードを書いている

個人開発で Claude Code や自作エージェントを使い始めると、最初は「API を直接叩けばいい」で十分機能します。ところがプロジェクトが 2〜3 本を超えたあたりから、同じ Supabase や Notion への接続コードをコピペしている自分に気づきます。認証、エラーハンドリング、ツール定義、返り値の整形 — プロジェクトごとに微妙に違う実装が積み重なり、どれが最新かわからなくなる。これは M×N 問題（M 個のエージェント × N 個のサービスぶんの統合コード）と呼ばれる典型です。

この問題に対して、Anthropic が 2026 年 4 月に「Building Agents That Reach Production Systems with MCP」という設計ガイドを公開しました。本記事はその内容を、複数の SaaS と副業プロダクトを 1 人で回す個人開発者の視点で解読し、いつ MCP に切り替えるべきか の判断基準に落とし込みます。

この記事でわかること:

• MCP・CLI・API 直叩きの現実的な使い分け（個人開発スケールでの判断軸）
• MCP に切り替えるタイミングの見極め方（プロジェクト本数・クラウド移行・再利用頻度）
• Anthropic が推奨する MCP サーバー設計 5 原則を、個人開発で実用化する視点で翻訳
• クライアント側のトークン効率化（tool search、programmatic tool calling）
• Skills と MCP を組み合わせて「専門家エージェント」を作るパターン

3 つの選択肢 — どこに共通層を置くか

Anthropic のガイドが最初に整理するのは、「エージェントとサービスの間に共通層を置くか、置かないか」の話です。これを表にすると次のようになります。

アプローチ	共通層	向いている場面	個人開発での目安
API 直叩き	なし（毎回自前）	エージェント 1 つ、サービス少数	プロジェクト 1〜2 本まで
CLI	薄い（シェル前提）	ローカル・コンテナ環境	手元で完結する作業、Playwright など既存 CLI の活用
MCP	プロトコルとして標準化	リモート・クラウド・複数クライアント横断	プロジェクト 3 本以上、モバイル・Web 対応、認証必須のサービス

個人開発で見落としがちなのは、API 直叩きの「後で困る」コスト です。最初は圧倒的に速く動きますが、次に同じサービスを別プロジェクトで使うとき、また最初からラッパーを書くことになります。CLI は手元作業では依然として有効で、私自身 note.com への自動投稿は Playwright MCP 経由のブラウザ操作で回していますが、Web・モバイル・クラウドで動くエージェントには届きません。

MCP は初期投資が少し重いものの、一度作れば Claude、ChatGPT、Cursor、VS Code すべてから使える 点で、個人開発者こそ真価が出ます。ひとりで複数プラットフォームに対応するリソースはないので、標準化に乗るのが最もコスパが良い選択になります。

MCP に切り替えるべきタイミング 3 つの兆候

「全員 MCP にすべき」ではありません。個人開発での判断軸を 3 つに絞ると次のとおりです。

1. 同じサービス（Supabase、Notion、Stripe など）を 2 プロジェクト以上で使っている — 統合コードの重複が発生している段階
2. ローカル以外で動かしたい — Vercel Cron、GitHub Actions、クラウドホスト型エージェントから同じ接続を使いたい
3. 認証付きの外部サービスに繰り返しアクセスしている — OAuth を毎回手書きするのが辛い

逆に、単発のスクリプトや 1 プロジェクト限定の自動化 は API 直叩きで十分です。判断を間違えると、MCP サーバーの実装に数時間使って、結局使わないということになります。

私自身の経験でいうと、Playwright MCP は note.com 投稿の自動化で使っており、これは「複数のプロジェクトから同じブラウザ操作を呼びたい」という条件に合致したから MCP 化する意味がありました。一方、recipe-ai の YouTube からのレシピ抽出は、recipe-ai 内部でしか使わないので API 直叩きで完結させています。

良い MCP サーバーの設計 5 原則（Anthropic ガイドの要点）

Anthropic が公開している約 200 の MCP サーバーから抽出された設計パターンです。個人開発者が自作するときに直接効く 5 つだけに絞ります。

1. リモートサーバーにする — 配布範囲が全部変わる

ローカル MCP はその開発マシンでしか動きません。リモート MCP にすれば Web・モバイル・クラウド型エージェントから全部使えるようになります。自分だけで使う段階ではローカルで十分ですが、「記事のコード例として配布したい」「Claude.ai の接続に追加したい」となった瞬間、リモートが前提になります。

2. エンドポイントではなく意図でツールをまとめる

API をそのままラップして get_thread、parse_messages、create_issue、link_attachment と並べるより、create_issue_from_thread 1 つにまとめたほうが、エージェントは少ない呼び出しで仕事を終わらせられます。ツール数が多いほどコンテキストを食い、選択ミスも増えます。

個人開発で作る MCP は「ユーザー（＝自分）が最終的にやりたい作業単位」で関数を切ると、コンテキスト効率と使いやすさの両方が上がります。

3. 大規模サービスは「コードを受け取るツール」で薄くする

Cloudflare の MCP サーバーは約 2,500 のエンドポイントを、わずか 2 つのツール（search と execute）、合計約 1,000 トークンで提供しています。エージェントが短いスクリプトを書き、サーバーがサンドボックスで実行し、結果だけ返す設計です。

個人開発で 2,500 エンドポイントを扱うことはまずありませんが、「社内の広い API を扱うとき」「Supabase のクエリを直接書かせたいとき」にはこのパターンが使えます。

4. リッチなセマンティクス（MCP Apps / Elicitation）を活用

• MCP Apps: ツールの返り値としてチャート、フォーム、ダッシュボードなどのインタラクティブ UI をチャット内で表示できる拡張
• Elicitation: ツール呼び出しの途中でユーザーに入力を求めたり、確認ダイアログを出したりできる機能

個人開発のプロダクトで「ユーザーに買ってもらう」「申し込みボタンを押してもらう」場面を、エージェント経由でも実現できる選択肢が増えました。従来は設定画面へ飛ばすしかなかった操作が、チャット内で完結します。

5. 標準化された認証（CIMD）に乗る

MCP の最新仕様は CIMD（Client ID Metadata Documents）による OAuth クライアント登録をサポートしています。これに乗れば、初回認証が速く、再認証プロンプトもほぼ出ない という体験が得られます。自前で認証を作り込むより、SDK と Claude.ai / Claude Code の既存実装に寄せたほうが工数も UX も得です。

クライアント側のトークン節約 — 個人開発こそ効いてくる

MCP サーバーを作る側だけでなく、使う側の設計でもトークン消費が大きく変わります。Anthropic が公開している 2 つのパターンを紹介します。

Tool Search — ツール定義を必要なときだけロード

通常、エージェントは起動時にすべてのツール定義をコンテキストにロードします。10 個の MCP サーバーに合計 100 ツールがあると、それだけで数万トークンを食います。Tool Search を使うと、エージェントが必要に応じてツールカタログを検索する形になり、ツール定義のトークンを 85% 以上削減 できるとの報告があります。

Programmatic Tool Calling — 結果を生で返さずコードで処理

複数の API 呼び出しの結果をいったんサンドボックスの中で JavaScript 処理し、最終結果だけをモデルに返す パターンです。複雑なワークフローで約 37% のトークン削減。API コストに敏感な個人開発（私は複数プロダクトの固定費を月 ¥5,000 以下に抑えて運用しているので、ここは特に効く）では、積み重なると月単位で差が出ます。

Skills と MCP は相補関係 — 両方入れて初めて「専門家」になる

Skills は「どう使うか の手順知識」、MCP は「何ができるか の機能」。個人開発でプラグインとしてまとめると、Claude が特定ドメインの専門家のように振る舞います。

私が運用している例でいうと、Claude Crew で使う note-publisher 相当の構成は次の形です。

• MCP: Playwright MCP（ブラウザ自動化の機能提供）
• Skills: note.com の HTML 組み立てルール、insertHTML の正しい呼び方、サムネ配置の手順

MCP だけだと「ブラウザを開いて操作できる」だけですが、Skills が加わると「note.com で H2・H3・箇条書きを正しく組んで公開できる」エージェントになります。機能と手順を分離しておくと、サーバー側の API 変更には Skills の更新だけで追従できます。

Anthropic の方向性としては、MCP サーバーから Skills を配信する拡張 がコミュニティで進行中で、安定すれば「サーバーを接続すれば専門知識も自動で入る」形になります。

個人開発で明日から取れる 3 つのアクション

1. 今 API 直叩きしている箇所を棚卸し — 2 プロジェクト以上で同じサービスを使っているなら MCP 化の候補
2. 公式 MCP サーバーを先に探す — Supabase、Notion、Vercel、Stripe などは公式または準公式 MCP がある。まず既存を接続してから自作を検討
3. 自作する場合はリモート MCP + 意図ベースのツール設計 — ローカル専用で作り始めると、後から配布したくなったときに書き直しになる

「API を直接叩けばいい」という発想から「共通層を持つ」という発想に切り替える。これだけで、複数プロダクトを 1 人で回すときの保守コストが大きく変わります。私自身、過去に複数の Supabase ラッパーをプロジェクトごとに書いて後悔したので、3 本目の前に MCP 化 を目安にしています。

関連記事

【第2回】Claude Code MCP サーバー構築ガイド

MCP サーバーをゼロから作る手順を、実コード付きで解説した実装編

→

【第1回】Claude Code Skills 入門

Skills と MCP の違い・組み合わせ方を具体例で理解する

→

【第6回】Claude Code で SaaS を開発するフロー

MCP を活用した個人開発者の実際の開発サイクル

→