JSON-RPC は、JSON を使ってリクエストとレスポンスをやり取りするためのシンプルな RPC 方式です。
どの関数や機能を呼ぶか、どんな引数を渡すか、結果をどう返すかを、JSON の形で整理して通信できます。
まず押さえたいポイント
- JSON 形式でメッセージをやり取りする
- リクエスト、レスポンス、通知の考え方がある
- MCP では通信の土台として使われている
どんな場面で使うか
- アプリ間の機能呼び出し
- ツールやサーバーとのやり取り
- 標準化されたメッセージ形式がほしいとき
どんなふうに理解するとよいか
このメソッドを、この引数で呼ぶ を JSON で表す決まりと考えると分かりやすいです。
MCP では、初期化、一覧取得、ツール呼び出し、通知などのやり取りがこの形式で行われます。
メッセージの形は4種類しかない
JSON-RPC が軽いと言われるのは、覚えることが少ないからです。やり取りは実質この4つです。
| 種類 | 特徴 | 返事 |
|---|---|---|
| リクエスト | id を付けて呼ぶ |
結果かエラーが返る |
| 通知（notification） | id を付けずに呼ぶ |
返事は来ない |
| 成功レスポンス | result を持つ |
— |
| エラーレスポンス | code と message を持つ |
— |
id を付けるかどうかだけで「返事が要る呼び出し」と「投げっぱなしの通知」を切り替えられるのが、この方式の分かりやすいところです。
REST との違いは「どこに意味を持たせるか」
REST は URL とHTTPメソッドに意味を持たせます。JSON-RPC はメソッド名を本文の中に書くので、通信路そのものには意味を持たせません。
- REST: 「どの資源に」「何をするか」を URL とメソッドで表す
- JSON-RPC: 「どの手続きを呼ぶか」を本文の
methodで表す
この違いのおかげで、JSON-RPC は HTTP でも標準入出力でもそのまま載せられます。通信路を選ばない設計なので、ローカルのプロセス間連携でも同じ形が使えます。
押さえておきたい注意点
JSON-RPC はメッセージ形式の話なので、認証や権限管理まで自動で面倒を見てくれるわけではありません。
そのため、実運用では transport や認証の設計も合わせて考える必要があります。
実務で見るポイント
- メソッド名と引数の設計が分かりやすいか
- 通知とレスポンスありの要求を混同しないか
- 上位のプロトコルでどこまでを責任範囲にするか