Connect（connectrpc）とは？gRPC・RESTとの違いと使い方をわかりやすく解説

Connect（connectrpc）は、Protocol Buffers開発で知られるBufが公開しているRPCフレームワークです。公式サイトはconnectrpc.comで、名前だけ見ると多くの同名サービスと紛らわしいものの、本記事で扱うのはこのRPC用のConnectを指します。最大の特徴は、1つのサーバー実装がConnectプロトコルとgRPC、gRPC-Webの3つを同時に話せる点です。これにより、ブラウザからは普通のHTTPリクエストで、既存のgRPCクライアントからはgRPCで、同じエンドポイントを呼び分けられます。ここでは定義とgRPC・RESTとの違い、Go・TypeScript・Pythonでの使い方までをまとめます。

まとめ：Connectの要点

• Connect＝BufのRPCフレームワーク。Protocol BuffersでAPIを定義し、HTTP/1.1・HTTP/2上で動く。
• 1サーバーで3プロトコル対応（Connect／gRPC／gRPC-Web）。ブラウザからcurlやfetchで直接呼べるのが最大の差別点。
• gRPCとの違い：gRPC-Webのプロキシ（Envoy等）が不要。JSONでも叩けるためデバッグが容易。純粋な通信性能ではgRPCが有利。
• Goはconnectrpc.com/connect（connect-go）、TypeScriptはconnect-es＋connect-query、Pythonは公式のconnect-py（ベータ）が使える。
• gRPCの複雑な配線を避けつつ型安全なAPIを作りたい、Webフロントから直接RPCしたい場面に向く。

Connectの定義とRPCフレームワークとしての位置づけ

RPC（Remote Procedure Call）は、離れたサーバー上の関数をローカル関数のように呼び出す通信方式です。gRPCはその代表格ですが、Connectは「gRPCの資産（Protocol Buffers・型安全なスキーマ）を活かしつつ、Web標準のHTTPに素直に載せる」ことを狙って設計されました。gRPC自体の位置づけはgRPCとは？仕組み・RESTとの違い・UDP/TCPの扱いを実装例つきで解説で整理しています。

gRPCの課題を解くために生まれた背景

gRPCは高速ですが、ブラウザから直接は呼べません。ブラウザで使うにはgRPC-Web対応のプロキシ（Envoyなど）を挟む構成が必要で、フロントエンド連携のハードルになっていました。Connectはこのプロキシを不要にし、Web開発者が慣れたHTTPのまま型安全なAPIを扱えるようにするために作られています。バイナリのProtocol BuffersだけでなくJSONでもリクエストを送れるため、ブラウザの開発者ツールやcurlでそのまま動作確認できます。

Connectプロトコルと3プロトコル同時対応

Connectの核心は、生成した1つのハンドラがConnectプロトコル・gRPC・gRPC-Webの3方式を同時に受け付けることです。Connectプロトコルはunary（1リクエスト1レスポンス）呼び出しを普通のHTTP POSTとして表現し、ボディはJSONかProtocol Buffersを選べます。一方で同じサーバーが従来のgRPCクライアントからのバイナリ通信も処理できるため、「社内サービス間はgRPC、ブラウザ向けは同じAPIをConnectで」といった使い分けを追加実装なしで実現できます。

ConnectとgRPC・RESTの違い

3者はいずれもクライアントとサーバーをつなぎますが、想定する通信環境と開発体験が異なります。

整理すると、純粋な性能とストリーミングを突き詰めるならgRPC、手早く型安全にしたいならREST、その中間でブラウザ連携と型安全を両立したいならConnectという関係です。ConnectはgRPCの上位互換ではなく、gRPCと同居できる薄い選択肢と捉えると判断しやすくなります。

Protocol Buffersを持ち込まずにRPC的な呼び出し口だけがほしい場合は、JSONのまま単一エンドポイントへPOSTするJSON-RPC 2.0という選択肢もあります。PHPでの実装はLaravel Sajyaとは？JSON-RPC 2.0サーバーの実装手順とエラー処理を参照してください。

connect-goによるConnectサーバー実装

Goの実装ライブラリはconnect-goで、モジュールパスはconnectrpc.com/connectです（以前のbufbuild配下から移管済み。旧記事にあるbuf.build/gen/go/...系のパスはコード生成物向けで、ライブラリ本体の取得先ではありません）。

インストールと最小サーバー

ライブラリの取得は次のコマンドです。

go get connectrpc.com/connect

Protocol Buffersからサービスコードを生成したうえで、生成されたNewXxxServiceHandlerを標準のnet/httpに登録します。以下はGreetサービスの最小例です。

package main

import (
    "context"
    "net/http"

    "connectrpc.com/connect"
    "golang.org/x/net/http2"
    "golang.org/x/net/http2/h2c"
    greetv1 "example/gen/greet/v1"
    "example/gen/greet/v1/greetv1connect"
)

type GreetServer struct{}

func (s *GreetServer) Greet(
    ctx context.Context,
    req *connect.Request[greetv1.GreetRequest],
) (*connect.Response[greetv1.GreetResponse], error) {
    res := connect.NewResponse(&greetv1.GreetResponse{
        Greeting: "Hello, " + req.Msg.Name,
    })
    return res, nil
}

func main() {
    mux := http.NewServeMux()
    path, handler := greetv1connect.NewGreetServiceHandler(&GreetServer{})
    mux.Handle(path, handler)
    // h2cでラップするとTLS無しでもHTTP/2が有効になり、ネイティブgRPCも受けられる
    http.ListenAndServe("localhost:8080", h2c.NewHandler(mux, &http2.Server{}))
}

ポイントは、生成コードが返すpathとhandlerをmux.Handleに登録することです。旧来の解説ではhttp.NewServeMux()を作っただけでハンドラを登録せずに起動する例が見られますが、それではエンドポイントに何も応答しません。ConnectとgRPC-WebはHTTP/1.1でも動きますが、ネイティブのgRPCクライアントはHTTP/2を要求します。そのため上記のようにTLSを使うか、平文ならh2cでラップしてHTTP/2を有効にすると、同じサーバーが3プロトコルすべてを受け付けられます。

エラーコード体系（gRPC共通）での返却

Connectはエラーを、gRPCと共通のコード体系で表現します。HTTPステータスに丸めず、connect.CodeInvalidArgumentのような意味のあるコードを付けて返すのが基本です。

if req.Msg.Name == "" {
    return nil, connect.NewError(
        connect.CodeInvalidArgument,
        errors.New("name is required"),
    )
}

クライアントはconnect.CodeOf(err)でコードを取り出し、リトライすべきか入力を直すべきかを機械的に判断できます。JSONで叩いた場合もこのコードがレスポンスに乗るため、ブラウザからのデバッグでも原因を特定しやすくなります。

connect-query（TypeScript／React）でのフロント連携

TypeScript実装はconnect-es、Reactでのデータ取得はconnect-queryが担当します。connect-queryはTanStack Query（旧React Query）の拡張で、GraphQLクライアントに近い型安全なデータ取得フックを、ProtobufスキーマからそのままReactに持ち込めます。GraphQL自体との比較はGraphQLとは？REST APIとの違い・メリット・デメリットをわかりやすく解説を参照してください。

導入するランタイムは次のとおりです（コード生成には@connectrpc/protoc-gen-connect-queryと@bufbuild/protoc-gen-esをdev依存に追加します）。

npm install @connectrpc/connect-query @connectrpc/connect-web @bufbuild/protobuf @tanstack/react-query

旧記事にあるreact-query単体の指定は現行のパッケージ構成と異なります。実際の取得は、生成されたクエリ定義をuseQueryに渡す形になります。

import { useQuery } from "@connectrpc/connect-query";
// 生成ファイル名はprotoに応じて変わる（一例）
import { getUser } from "../gen/user_connectquery";

const { data, error, isLoading } = useQuery(getUser, { id: "1" });

Transport（createConnectTransport）をProviderに渡しておけば、あとはRESTを書くのと変わらない感覚で、型の付いたレスポンスを受け取れます。

Python版Connect（connect-py）の現状

「PythonにはConnectの公式ライブラリが無い」という説明は現在は当てはまりません。Bufは公式実装connect-pyを公開しており、PyPIパッケージconnectrpcとして入手できます（2026年時点でベータ）。

pip install connectrpc

protocプラグインでクライアントのスタブとサーバーのインターフェースを生成し、同期・非同期の両クライアント、ASGI／WSGIサーバー、ストリーミング、インターセプターに対応します。gRPCプロトコルでの通信もカバーするため、既存のPythonバックエンドからConnect／gRPC双方のサービスへ接続できます。ベータのため仕様変更があり得るので、最新の導入手順は公式ドキュメント（connectrpc.com/docs/python/）で確認してください。なお歴史的経緯から、非公式のconnecpyなど別実装も存在するため、パッケージ名を取り違えないよう注意が必要です。

対応言語のサポート状況

Connectは複数言語に公式実装があり、同じProtocol Buffers定義を共有できます。2026年時点の主な実装は次のとおりです。

JavaやC#の専用公式実装は用意されていませんが、これらの言語はConnectサーバーが同時に話すgRPCプロトコルへ既存のgRPCクライアントで接続できます。つまり「サーバーはConnect、Java側は標準のgRPCクライアント」という組み合わせが成立します。バージョンは更新が速いため、採用前に各リポジトリの最新リリースを確認してください。

Connectを選ぶべき場面・避けるべき場面

Connectは万能ではなく、向く場面がはっきりしています。次の条件に当てはまるなら有力候補です。

• ブラウザから型安全にAPIを呼びたい：gRPC-Web用プロキシを立てずに済み、構成がシンプルになる。
• 既にProtocol Buffersでスキーマを管理している：定義を流用でき、gRPCと同居させながら段階的に導入できる。
• JSONで手軽にデバッグしたい：curlやfetchでそのまま叩けるため、動作確認と外部連携が楽になる。

一方、次の場合はConnectを主軸に据えない方が無難です。ミリ秒単位の通信性能や高頻度の双方向ストリーミングを最優先するなら、素のgRPCが適します。また、社内にProtocol Buffersを扱う土台がなく、公開APIをJSONだけで完結させたいなら、素直にREST（＋OpenAPI）の方が学習コストは低く済みます。Connectの利点はあくまで「gRPCの型安全とWebの手軽さの両立」であり、どちらか一方だけが目的なら専用手段に劣ることがあります。

よくある質問

Connectの読み方は？

「コネクト」と読みます。RPCフレームワークであることを明示する場合はconnectrpc（コネクトアールピーシー）と表記され、パッケージ名やドメインconnectrpc.comもこの綴りです。

Connectはどのプロトコルに対応していますか？

Connectプロトコル、gRPC、gRPC-Webの3つです。1つのサーバー実装がこれらを同時に受け付けるため、クライアント側の事情に合わせてプロトコルを選べます。

gRPCとConnectはどちらを選ぶべきですか？

ブラウザ連携やJSONでのデバッグを重視するならConnect、純粋な通信性能と高度なストリーミングを重視するならgRPCが向きます。両者は同じサーバーで併用できるため、二択で悩むより「ブラウザ向けだけConnectを足す」判断も可能です。

PythonでConnectは使えますか？

使えます。公式のconnect-py（PyPIパッケージconnectrpc、2026年時点でベータ）が提供され、protocプラグインでスタブを生成し、ASGI／WSGIサーバーやストリーミングに対応します。

導入にBufやProtocol Buffersは必須ですか？

APIスキーマはProtocol Buffersで定義するため実質必須です。コード生成にはBuf CLIを使うのが一般的ですが、protocでも生成できます。既存のgRPC用.proto定義があればそのまま流用できます。.protoの書き方とフィールド番号の運用もあわせて確認してください。

関連記事

• gRPCとは？仕組み・RESTとの違い・UDP/TCPの扱いを実装例つきで解説
• GraphQLとは？REST APIとの違い・メリット・デメリットをわかりやすく解説
• マイクロサービスとは？モノリスとの違い・メリット・デメリットと選び方、モジュラモノリスまで整理
• gRPCとConnectをRemix環境で扱う背景とその重要性について
• Laravel Sajyaとは？JSON-RPC 2.0サーバーの実装手順とエラー処理