関数呼び出しとMCPの違い:自作のツール連携とMCPサーバー、どちらを選ぶか

仕組みの違い:ツールを「誰が持つか」

関数呼び出し:アプリがすべて持つ

Claudeの公式ドキュメントによると、自分で定義するツールは「クライアントツール」で、実行するのは自分のアプリです。流れは次のとおりです。

1. リクエストにツールの名前・説明・入力スキーマを渡す
2. モデルが tool_use という呼び出し内容を返す
3. 自分のコードが実際の処理を実行する
4. 結果を tool_result として返し、モデルが回答を作る

Claudeのツール利用の概要は、この往復を天気取得の例で示しています。以下は、それを参考に私が作った説明用の例で、実行はしていません。

tools = [{
    "name": "lookup_order",
    "description": "注文番号から配送状況を返す。注文の変更はしない。",
    "input_schema": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"],
    },
}]

定義はコードの中にあるので、バージョン管理もテストも、そのアプリと同じ流れで済みます。

MCP:サーバーが公開し、クライアントが取りにいく

MCPの公式アーキテクチャ解説では、Claude CodeのようなAIアプリが「ホスト」、接続先ごとに作られる接続部分が「クライアント」、ツールなどを提供するプログラムが「サーバー」です。クライアントは tools/list でツール一覧を取得し、tools/call で実行します。ツールの名前・説明・入力スキーマはサーバー側が持つので、対応するAIアプリなら同じサーバーを共有できます。

サーバーはローカルで動く（stdio）ことも、リモートで動く（Streamable HTTP）こともあります。同文書によると、ローカルのサーバーは通常一つのクライアントに、リモートのサーバーは多数のクライアントに使われます。

再利用性・管理の手間・権限管理の比較表

次の表が、この記事の判断材料です。「向く／向かない」の列は公式の記述ではなく、上記の仕組みの違いから私が整理した編集上の見立てです。

• ツール定義の場所、自作の関数呼び出し：自分のアプリのコード（リクエストの tools）、MCPサーバー：サーバーが公開。クライアントが tools/list で取得
• 実行される場所、自作の関数呼び出し：自分のアプリ内、MCPサーバー：MCPサーバー（ローカルまたはリモート）
• 再利用性、自作の関数呼び出し：低〜中。別のアプリでは定義と処理をコピーまたは共通ライブラリ化する、MCPサーバー：高い。MCP対応のAIアプリから同じサーバーに接続できる
• 初期の手間、自作の関数呼び出し：小さい。関数とスキーマを書くだけ、MCPサーバー：既存サーバーなら接続設定のみ。自作なら、サーバーの実装・配布・運用が加わる
• 継続的な管理、自作の関数呼び出し：ツールが増えると、利用アプリごとに定義を更新する必要がある、MCPサーバー：更新はサーバー側に集約できる。一方でサーバーの信頼確認・バージョン追従が必要
• 権限の決め方、自作の関数呼び出し：自分のコードで完全に決める（引数チェック、許可する操作の絞り込み）、MCPサーバー：認可・スコープ、クライアント側の承認設定、サーバー側の実装の三層で決まる
• 向く場面、自作の関数呼び出し：一つのアプリ専用、業務固有のロジック、挙動を細かく制御したい、MCPサーバー：複数アプリ・複数人で共有、外部サービスの既存サーバーを使いたい
• 向かない場面、自作の関数呼び出し：同じ連携を多数のアプリに配りたい、MCPサーバー：小さな一回限りの処理に、サーバー運用を足す場合

権限管理で見るべき点

「管理の手間」は、実は権限の話に行き着きます。

関数呼び出しでは、モデルが返すのは「この引数でこのツールを呼びたい」という要求だけで、実行するかどうかは自分のコードが決めます。たとえば lookup_order は読み取り専用にして、注文変更の関数は別に作り、確認画面を挟む、といった設計を自分で入れられます。

MCPでは、制御が分かれます。

• 接続側の承認:Claude CodeのMCP解説では、設定の保存先が local・project・user の3スコープに分かれます。チームで共有する .mcp.json（project）のサーバーは、初回使用時に承認が必要とされています。
• 信頼できるサーバーか:同じ文書は、接続前にサーバーを信頼できるか確認するよう警告しています。外部コンテンツを取得するサーバーは、プロンプトインジェクションの恐れがあるためです。
• 認可の範囲:MCPのセキュリティ文書は、最小限のスコープから始めて必要に応じて広げる設計を勧めています。ローカルのサーバーは、クライアントと同じ権限で動く点にも注意が必要です。
• API経由での絞り込み:Claude APIのMCPコネクタ（ベータ機能として記載）では、リモートのMCPサーバーに接続でき、使うツールを許可リストや拒否リストで絞れます。

つまりMCPは、使い回しやすい代わりに「他人が作ったコードに、自分のAIが接続する」リスクが増えます。読み取り専用の認証情報を使う、試すときは影響の小さい環境から始める、といった絞り込みが重要です。

選び方の手順:5つの質問

上から順に答えてください。

1. 同じ連携を使うAIアプリ（または人）は2つ以上ありますか? はい→MCPを検討。いいえ→関数呼び出し。
2. 対象サービスの公式または信頼できるMCPサーバーが既にありますか? はい→接続を先に検討（自作より運用の手間が少ない見込み）。
3. 処理が自社の業務ルールに強く依存しますか? はい→関数呼び出し、または自作のMCPサーバー。
4. 書き込み・削除・送信など、取り消しにくい操作を含みますか? はい→どちらを選んでも、人の承認を挟む設計にする。
5. サーバーを運用・更新する担当がいますか? いいえ→まず関数呼び出しで始める。

編集上のおすすめは、「最初は関数呼び出しで小さく作り、二つ目のアプリが同じ連携を必要としたときにMCPサーバーへ切り出す」進め方です。最初からサーバーを作ると、運用の手間が先に来るためです。

AIに判断を手伝わせる依頼文

状況を整理してAIに渡すと、上の質問に沿った比較を出してもらえます。以下は説明用の例で、会社名やシステム名は架空です。

次の条件で、自作の関数呼び出しとMCPサーバーのどちらが向くか、
再利用性・管理の手間・権限管理の3観点で比較してください。
不明な点は推測せず、確認すべき質問として挙げてください。

- やりたいこと:社内の配送管理システム(架空)の配送状況を、AIが問い合わせ対応で参照する
- 使うAIアプリ:自社の問い合わせ対応ボット1つ(将来、社内チャットにも広げる可能性あり)
- 既存のMCPサーバー:なし
- 操作の種類:配送状況の参照のみ(変更はしない)
- 運用担当:開発者1名
- 認証情報:読み取り専用のAPIキーを発行できる

出てきた回答では、次の2点を人が確認してください。

• 「既存のMCPサーバーはない」という前提が、実際に調べたうえでの結論になっているか
• 権限の提案が、実際に発行できる認証情報の範囲に収まっているか

この例の条件だと、上の手順では「利用アプリは今は1つ、参照のみ、担当1名」なので、まず関数呼び出しで始め、社内チャットにも広げる段階でMCP化を検討する、という結論になりやすいはずです。ただし実際の結論は、AIの回答と、自社の事情の確認で決めてください。

接続するときの最小チェック

MCPサーバーに接続する場合は、Claude Codeなら次のような追加コマンドを使います（公式ドキュメントの形式に沿った書き方で、URLは架空です）。

claude mcp add --transport http shipping https://mcp.example.com/mcp
claude mcp list

追加後に確認することは3つです。

• 公開元と運用者が分かるサーバーか（出所の不明なコマンドを実行しない）
• 渡す認証情報が読み取り専用など最小権限になっているか
• チーム共有の設定（project）にする前に、個人環境（local）で動作と権限を試したか

関数呼び出しの場合は、自分のコード側で、引数の検証と、許可する操作の限定を入れてください。

まとめの代わりに:今日やること

自分の案件を上の5つの質問に当てはめ、「利用アプリ数」「既存サーバーの有無」「操作の種類」の3点を書き出してください。そこが決まれば、表のどちらの列に進むかはほぼ決まります。迷ったら、読み取り専用の関数呼び出しから小さく始めるのが、手戻りの少ない選択です。