GPT ActionsとMCPの技術比較

OpenAIのGPT ActionsとAnthropicのModel Context Protocol (MCP)は、同じ基本的な問題を解決します。会話中にAIモデルが外部ツールやAPIを呼び出せるようにすることです。ただし、その解決方法は大きく異なります。

この記事では、両方のアプローチを技術的に比較します。アーキテクチャ、プロトコルの仕組み、認証、ツール検出、それぞれを選ぶ際に重要になるトレードオフ、または両方を使う場合の考慮点を扱います。

GPT Actionsとは

GPT Actionsは、Custom GPT、より広くはOpenAI APIで構築されたアシスタントが外部HTTP APIを呼び出すためのOpenAIの仕組みです。この概念は2023年後半にGPT Storeとともに提供され、以前のChatGPT Pluginsシステムから発展しました。

中心となる考え方は、自社APIのエンドポイント、パラメータ、レスポンススキーマを記述したOpenAPI仕様 (バージョン3.0または3.1)を提供することです。OpenAIのシステムはこの仕様を解析し、エンドポイントをモデルが呼び出せるツールとして提示します。モデルがいずれかを呼び出すと判断すると、OpenAIのサーバーがユーザーに代わってHTTPリクエストを実行します。

以下は、メールアドレスで顧客を検索する単一のアクションを定義する最小限のOpenAPIスキーマです。

openapi: "3.1.0"
info:
  title: "顧客検索API"
  version: "1.0.0"
servers:
  - url: "https://api.example.com"
paths:
  /customers/search:
    get:
      operationId: "searchCustomer"
      summary: "メールアドレスで顧客を検索する"
      parameters:
        - name: "email"
          in: "query"
          required: true
          schema:
            type: "string"
            format: "email"
          description: "顧客のメールアドレス"
      responses:
        "200":
          description: "顧客が見つかりました"
          content:
            application/json:
              schema:
                type: "object"
                properties:
                  id:
                    type: "string"
                  name:
                    type: "string"
                  email:
                    type: "string"
                  plan:
                    type: "string"

このスキーマをGPT Builderに貼り付けるかアップロードし、またはURLで参照し、認証を設定すると、Custom GPTはモデルが関連性があると判断したときにGET /customers/search?email=...を呼び出せるようになります。(仕様を作成する部分は自動化できます。たとえばQuickchat AIは、APIの実際のドキュメントを根拠に、1文の説明から同等のアクションを生成します。)

GPT Actionsの主なアーキテクチャ上の特性は次のとおりです。

サーバーサイド実行: OpenAIのインフラストラクチャが外向きのHTTP呼び出しを実行します。APIが受信するリクエストは、エンドユーザーのブラウザではなくOpenAIのIP範囲から届きます。
スキーマ形式としてのOpenAPI: モデルは、OpenAPI仕様内のoperationId、summary、descriptionフィールドを使って、各エンドポイントをいつ、どのように呼び出すかを理解します。
REST/HTTPのみ: Actionsは、HTTPS上の標準HTTPメソッド (GET、POST、PUT、DELETE、PATCH)に限定されます。
認証オプション: OAuth 2.0、APIキー (ヘッダーまたはクエリパラメータとして送信)、または認証なし。OpenAIがユーザーに代わってOAuthトークン交換フローを処理します。
静的なツール定義: 利用可能なアクションの集合は設定時に固定されます。モデルは実行時に新しいエンドポイントを検出できません。

MCPとは

Model Context Protocol (MCP)は、AIアプリケーションが外部ツールやデータソースと通信する方法を標準化するオープンプロトコルで、2024年後半にAnthropicによって公開されました。特定のモデルやベンダーに結び付いたものではありません。

当社は、プロトコルを基礎から説明するMCPの仕組みに関する完全ガイドを書いています。短く言うと、MCPはクライアント、サーバー型のアーキテクチャを定義します。AIアプリケーション (MCPクライアント)が1つ以上のMCPサーバーに接続し、tools/listリクエストで利用可能なツールを検出し、tools/callメッセージでそれらを呼び出します。通信にはJSON-RPC 2.0を使用します。

同じ顧客検索ツールをMCPツール定義として表すと、次のようになります。

{
  "name": "search_customer",
  "description": "メールアドレスで顧客を検索する",
  "inputSchema": {
    "type": "object",
    "properties": {
      "email": {
        "type": "string",
        "description": "顧客のメールアドレス"
      }
    },
    "required": ["email"]
  }
}

この定義は、MCPサーバー、つまりビジネスロジックをラップする小さなプログラムの中にあります。MCPクライアントがname: "search_customer"とarguments: {"email": "user@example.com"}を含むtools/callリクエストを送信すると、サーバーはそのツールの背後にある任意のコード、たとえばAPI呼び出し、データベースクエリ、ファイル読み取りを実行し、結果を返します。公開したいものが生のビジネスロジックではなくAIアシスタントである場合は、サーバーをまったく書かずに済ませることもできます。Quickchat AI AgentをMCPツールとして公開し、ホストされたURLで利用できます。

アーキテクチャ比較

2つのアプローチは、コードが実行される場所、通信の流れ、公開する抽象化が異なります。

GPT Actions: 集中型、HTTPネイティブ

User <-> ChatGPT (OpenAI servers) --HTTPS--> Your API server

モデルとアクション実行基盤は、どちらもOpenAI側にあります。モデルがアクションを呼び出すと判断すると、OpenAIのバックエンドがOpenAPI仕様に基づいてHTTPリクエストを組み立て、APIに送信し、レスポンスを受け取り、その結果をモデルに戻します。ユーザーのクライアント (ブラウザ、モバイルアプリ)がAPIと直接通信することはありません。

つまり、次のことを意味します。

APIはHTTPSで公開されている、または少なくともOpenAIのインフラストラクチャから到達可能である必要があります。
レイテンシには、OpenAIからサーバーまでの往復時間が含まれます。
すべてのリクエスト、レスポンスデータはOpenAIのサーバーを通過します。

MCP: 分散型、プロトコルネイティブ

User <-> AI Application (MCP Client) <--JSON-RPC--> MCP Server <-> Your API / DB / service

MCPクライアントは、AIアプリケーションが実行される場所で実行されます。Claude Desktopの場合は、ユーザーのマシン上です。Quickchat AIのようなクラウドホスト型AIエージェントの場合、MCPクライアントはエージェントのバックエンドで実行されます。MCPサーバーはローカルで実行でき、stdioで通信できます。また、同じネットワーク上、またはServer-Sent Events (SSE)や新しいStreamable HTTPトランスポートを使ってHTTP経由でリモート実行することもできます。

つまり、次のことを意味します。

MCPサーバーは、公開インターネットに露出していないローカルリソース (ファイル、データベース、localhostサービス)にアクセスできます。
通信は双方向です。サーバーはクライアントに通知を送信できます (例: リソースが変更された場合)。
プロトコルはトランスポートに依存しません。stdioパイプ、SSE、通常のHTTPで動作します。

比較表

Dimension	GPT Actions	MCP
ベンダーロックイン	OpenAIのみ。ChatGPTとOpenAI API内でのみ動作します。	ベンダー非依存。Claude、Cursor、VS Code、Windsurf、Quickchat AI、その他でサポートされています。
プロトコル	REST/HTTP上のOpenAPI 3.x。	設定可能なトランスポート上のJSON-RPC 2.0。
トランスポート	HTTPSのみ。APIは公開到達可能である必要があります。	stdio (ローカル)、SSE (リモート)、Streamable HTTP (リモート)。ローカルサーバーに公開エンドポイントは不要です。
認証	OAuth 2.0、APIキー (ヘッダーまたはクエリパラメータ)、またはなし。OpenAIが管理します。	トークンベース (ヘッダー内のBearerトークン)、カスタムヘッダー、またはなし。クライアントアプリケーションが管理します。
ツール検出	静的です。設定時にOpenAPIスキーマをアップロードするかリンクします。モデルは仕様に含まれる内容を見ます。	動的です。クライアントは実行時に`tools/list`を送信し、サーバーは現在利用可能なツールを返します。ツールはセッション間で変化できます。
ツールスキーマ形式	OpenAPIの操作定義 (パス、メソッド、パラメータ、リクエストボディ、レスポンススキーマ)。	入力パラメータ用のJSON Schema。ツール定義には名前、説明、`inputSchema`が含まれます。
実行場所	OpenAIのサーバーがHTTP呼び出しを実行します。	MCPクライアント (またはサーバー)が呼び出しを実行します。場所はクライアントとサーバーがどこで実行されるかによって決まります。
双方向性	一方向です。モデルがAPIを呼び出します。APIはHTTPレスポンス以外でデータをプッシュバックできません。	双方向です。サーバーは通知やリソース変更イベントをクライアントに送信できます。
状態管理	ステートレスなHTTPリクエストです。呼び出し間に永続接続はありません。	ステートフルなセッションです。クライアント、サーバー間の接続は、セッション内の複数のツール呼び出しをまたいで維持されます。
エコシステム	クローズドです。仕様形式 (OpenAPI)はオープンですが、実行環境はプロプライエタリです。	オープンです。プロトコル仕様は公開されています。誰でもクライアントとサーバーを構築できます。
レスポンス形式	OpenAIが解析する標準HTTPレスポンス (JSON、テキストなど)。	構造化されたMCPコンテンツブロック (テキスト、画像、埋め込みリソース)。

技術的な詳細: サンプル統合

違いを具体的にするために、よくあるタスクを考えます。PostgreSQLデータベースに顧客注文を問い合わせ、その結果をユーザーに返すタスクです。

GPT Actionsのアプローチ

データベースの前段にHTTP APIを構築し、ホストする必要があります。

# Flask APIサーバー (簡略版)
from flask import Flask, request, jsonify
import psycopg2

app = Flask(__name__)

@app.route("/orders", methods=["GET"])
def get_orders():
    customer_email = request.args.get("email")
    conn = psycopg2.connect("dbname=mydb user=myuser")
    cur = conn.cursor()
    cur.execute(
        "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
        (customer_email,)
    )
    rows = cur.fetchall()
    cur.close()
    conn.close()
    return jsonify([
        {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
        for r in rows
    ])

次に、このエンドポイント用のOpenAPI仕様を書き、TLS付きでAPIをデプロイし、認証を設定して、その仕様をGPT Builderに貼り付けます。残りはOpenAIが処理します。仕様を読み取り、利用可能な操作をモデルに示し、必要なときにHTTP呼び出しを実行します。

全体のセットアップには、実行中のAPIサーバー、公開HTTPSエンドポイント、OpenAPI仕様、OpenAIのUI内でのGPT Action設定が含まれます。

MCPのアプローチ

同じデータベースクエリをラップするMCPサーバーを書きます。

# mcp Python SDKを使用するMCPサーバー
from mcp.server import Server
from mcp.types import Tool, TextContent
import psycopg2
import json

server = Server("orders-server")

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_orders",
            description="メールアドレスで顧客の注文を検索する",
            inputSchema={
                "type": "object",
                "properties": {
                    "email": {
                        "type": "string",
                        "description": "顧客のメールアドレス"
                    }
                },
                "required": ["email"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_orders":
        conn = psycopg2.connect("dbname=mydb user=myuser")
        cur = conn.cursor()
        cur.execute(
            "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
            (arguments["email"],)
        )
        rows = cur.fetchall()
        cur.close()
        conn.close()
        results = [
            {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
            for r in rows
        ]
        return [TextContent(type="text", text=json.dumps(results, indent=2))]

MCPサーバーがローカルで実行される場合 (stdio経由)、localhostまたはローカルネットワーク上のデータベースに直接接続できます。公開エンドポイントは不要です。サーバーがリモートで実行される場合はHTTPエンドポイントが必要ですが、生のRESTではなく、SSEまたはStreamable HTTP上のJSON-RPCを使って通信します。

ローカル利用の全体セットアップには、MCPサーバースクリプト、サーバーのコマンドを指すMCPクライアント設定、データベース接続が含まれます。OpenAPI仕様、TLS証明書、公開APIは不要です。

実務上の主な違い

GPT Actionsの経路は、より多くのインフラストラクチャ、つまりデプロイ済みHTTPサービスを必要としますが、ほとんどのチームがすでに知っている既存のREST APIパターンを活用できます。すでにREST APIがある場合、GPT Actionの追加は主にOpenAPI仕様を書く作業です。

MCPの経路は、ローカル利用のケースでは必要なインフラストラクチャが少なくなりますが、チームが新しいプロトコルを学ぶ必要があります。リモートデプロイでは、インフラストラクチャ要件はGPT Actionsに近くなりますが、通信モデルが異なります (永続接続、JSON-RPCフレーミング、双方向通知)。

Quickchat AIが両方のアプローチを扱う方法

Quickchat AIのAI Actions systemは、これら2つのパラダイムに対応する2種類のアクションタイプ、HTTP Request ActionsとRemote MCP Actionsをサポートしています。

HTTP Request Actions

HTTP Request Actionsは、概念的にはGPT Actionsに似ています。HTTPエンドポイント、メソッド、ヘッダー、クエリパラメータ、JSONボディテンプレートを設定します。AI Agentが会話からパラメータ値を収集し、QuickchatのバックエンドがサーバーサイドでHTTPリクエストを実行します。

HTTP Request Actionは次の要素で構成されます。

{{parameter}}プレースホルダーを含むエンドポイントURL (例: https://api.hubapi.com/crm/v3/objects/contacts)
HTTPメソッド (GET、POST、PATCH、PUT、DELETE)
ヘッダー (サーバーサイドで置換される認可トークンを含む)
パラメータプレースホルダーを含むJSONボディテンプレート
プレースホルダーを含むクエリパラメータ
説明、必須フラグ、デフォルト値を持つ型付きパラメータ (string、number、boolean、float)の集合

実行時、AIは会話のコンテキストに基づいて、どのパラメータを埋めるかを判断します。バックエンドはパラメータ値をURL、ヘッダー、ボディ、クエリ文字列に注入し、{{param_name}}プレースホルダーを置換します。その後HTTPリクエストを実行し、解釈用にレスポンスをAIに返します。

詳細な例については、HubSpot AI Actionsガイドを参照してください。

Remote MCP Actions

Remote MCP Actionsは、AI Agentを外部MCPサーバーに接続します。個別のHTTPエンドポイントを定義する代わりに、MCPサーバーのURLと任意の認証情報 (ベアラートークン、および、またはカスタムヘッダー)を指定します。QuickchatバックエンドはMCPクライアントとして動作します。リモートサーバーに接続し、標準のtools/listプロトコル呼び出しで利用可能なツールを検出し、それらをAIモデルに提示します。

設定には次が必要です。

MCPサーバーURL (MCP Streamable HTTPまたはSSEトランスポートを提供するHTTPSエンドポイント)
任意の認証トークン
任意のカスタムヘッダー
個別の有効、無効切り替えを持つ検出済みツールのリスト
デフォルトのツール有効化設定 (新しく検出されたツールをデフォルトで有効にするかどうか)

接続後、MCPサーバーが公開する各ツールは、会話中にAI Agentから利用可能になります。AIは、MCPサーバーのtools/listレスポンスに含まれるツール名と説明を確認し、必要に応じて呼び出せます。ツール選択はallowed_tools設定で絞り込めます。これにより、サーバー上の特定のツールを有効または無効にできます。

このアプローチは、ShopifyのMCPのように、すでにMCPサーバーを公開しているサービスと統合する場合に特に有用です。各エンドポイントに対して個別のHTTPアクションを構築する代わりに、既存のサーバーに接続できるためです。

Quickchatでどちらを使うべきか

次の場合はHTTP Request Actionsを使います。

特定のREST APIエンドポイントと統合する場合
リクエスト形式 (ヘッダー、ボディ構造、クエリパラメータ)を細かく制御したい場合
APIが公開済みのMCPサーバーを持たない場合
サーバーサイドで認証情報を注入する必要がある場合 (HubSpot、ZendeskなどのOAuthトークンなど)

次の場合はRemote MCP Actionsを使います。

サービスがMCPサーバーを公開している場合
1つのアクションで単一サービスの複数ツールに接続したい場合
動的なツール検出を使いたい場合 (MCPサーバーの更新に応じて、AIが利用できるツールが変化する)
あるAIがMCP経由で別のAIに委任するマルチエージェントシステムを構築している場合

長所と短所

GPT Actions

長所:

なじみのある技術です。既存のREST APIがある場合、必要なものの大部分はすでにそろっています。OpenAPI仕様の作成は十分に文書化されており、ツールも成熟しています。
OpenAPI形式は広く採用されています。多くのWebフレームワーク (FastAPI、swagger-jsdocを使うExpress、springdocを使うSpring Boot)から仕様を自動生成できます。
OpenAIは、自社インフラストラクチャ上でHTTPリクエスト実行、TLS終端、エラー処理を扱います。
OAuth 2.0サポートが組み込まれており、自動トークン更新に対応しています。

短所:

OpenAIのエコシステムに固定されます。Custom GPT向けに構築したアクションは、再実装なしにClaude、Gemini、その他のモデルプロバイダーで再利用できません。
APIは公開アクセス可能である必要があります。ローカルまたはプライベートネットワークリソースはサポートされません。
動的なツール検出はありません。新しいエンドポイントを追加するには、OpenAPI仕様を更新し、GPTを再設定する必要があります。
一方向のみです。APIは、HTTPレスポンス以外でモデルに更新や通知をプッシュできません。
すべてのデータがOpenAIのサーバーを通過します。機密性の高いワークロードでは懸念事項になる場合があります。
レート制限と実行タイムアウトはOpenAIが制御し、利用者側では制御できません。

MCP

長所:

ベンダー非依存です。同じMCPサーバーがClaude、Cursor、Quickchat AI、その他プロトコルを実装する任意のクライアントで動作します。
ローカルリソースをサポートします。stdio上で実行されるMCPサーバーは、インターネットに何も公開せずに、ローカルマシン上のファイル、データベース、サービスにアクセスできます。
動的なツール検出が可能です。AIは実行時に利用可能なツールをサーバーへ問い合わせられます。クライアントを再設定せずに、ツールを追加、削除、更新できます。
双方向通信が可能です。サーバーは変更をクライアントに通知できます (例: ファイルが変更された、新しいレコードが作成された)。
ステートフルなセッションです。会話内の複数のツール呼び出しをまたいで接続が維持されるため、以前の呼び出しのコンテキストを必要とするワークフローを実現できます。
オープン仕様です。誰でもプロトコルを調査、実装、拡張できます。

短所:

エコシステムがまだ若いです。このプロトコルは2024年後半に公開されたため、OpenAPIと比べると、ツール、ドキュメント、コミュニティ知識はまだ発展中です。
MCPサーバーの実行が必要です。リモートデプロイでは、追加サービスをホストすることを意味します。ただし、軽量にできます。
標準化された認証仕様はありません (2026年初頭時点)。実装は、トークンベース認証、カスタムヘッダー、OAuth拡張の間でばらつきがあります。MCP Authorization仕様はまだ進化中です。
JSON-RPCフレーミングは抽象化レイヤーを追加するため、RESTに慣れたチームにはなじみにくく感じられる場合があります。
クライアントサポートには差があります。すべてのAIアプリケーションが、すべてのMCPトランスポートや機能をサポートしているわけではありません。

どちらを使うべきか

選択は制約によって決まります。

GPT Actionsを選ぶべき場合:

ChatGPTまたはOpenAI API専用に構築している場合。
OpenAPI仕様を持つ公開REST APIがすでにある場合。
OAuth 2.0をプラットフォーム側で処理してほしい場合。
「既存API」から「AIが呼び出せるツール」までの最も単純な経路を求める場合。

MCPを選ぶべき場合:

ツールを複数のAIプロバイダー間で動作させる必要がある場合。
ローカルまたはプライベートネットワーク上のリソースを、公開せずにAIへ公開したい場合。
動的なツール検出、双方向通信、またはステートフルなセッションが必要な場合。
異なるAIシステムが連携する必要があるマルチエージェントアーキテクチャを構築している場合。

両方を使うべき場合:

既存のREST APIをChatGPTユーザー向けにGPT Actionとして公開したい一方で、Claude、Cursor、その他のクライアント向けにMCPサーバーも公開したい場合。基礎となるビジネスロジックは共有でき、プロトコルアダプターはその上に置かれる薄いレイヤーです。

収束の傾向

GPT ActionsとMCPは異なる設計思想、つまりHTTPネイティブとプロトコルネイティブから始まりましたが、その差は縮まりつつあります。

OpenAIは2025年3月にAgents SDKへMCPサポートを追加し、OpenAIを利用するエージェントが従来のfunction callingと並行してMCPサーバーへ接続できるようにしました。これはGPT Actionsを置き換えるものではありません。GPT Actionsは、ChatGPTのCustom GPTにツール呼び出しを追加する方法として残っています。ただし、OpenAIがMCPをエージェント、ツール間通信の有力な標準として認識していることを示しています。

MCP側では、プロトコルがStreamable HTTP transportをサポートするようになり、リモートMCPサーバーは従来のHTTPサービスに近く見えるようになりました。Streamable HTTPエンドポイントの背後にあるMCPサーバーは、アーキテクチャ上REST APIからそれほど遠くありません。ただし内部では、RESTの慣例ではなくJSON-RPCを使用します。

おそらく、両方のパターンが共存することになります。OpenAPIスキーマはREST APIを記述する標準的な方法であり続け、GPT Actions、または類似の仕組みは、OpenAIのエコシステム内でそれらのAPIとAIモデルをつなぐ最も単純な橋渡しであり続けます。MCPは、特にエージェント型およびマルチモデルのアーキテクチャで、ツール統合のクロスベンダー標準として成長します。HTTP Request ActionsとRemote MCP Actionsの両方をサポートするQuickchat AIのようなプラットフォームは、具体的な統合に合うアプローチを選べる柔軟性を提供します。