API方式の違いは、誰が会話を始め、誰が中身を決めるかの違い

RESTの次に来るのはどの方式か、という問いは、たぶん立て方を間違えています。APIの方式の違いの大半は、流行の新旧ではなく、会話を始めるのはどちらか、返す中身を決めるのはどちらか、やり取りの単位は何か、という三つの問いへの答え方の違いだからです。この記事では、REST APIを基準に、RPC、GraphQL、gRPC、イベント駆動型、ファイルベースの五つの方式をこの三つの問いで並べ直し、GPTsのアクションがどこに位置するかを考えます。

基準のRESTは、頼む側が始め、応える側が形を決め、リソース単位でやり取りします

REST APIは、リソースと呼ばれるデータの単位を、GET、POST、PUT、DELETEなどのHTTPメソッドで操作します。サーバーは前のやり取りを覚えていない（ステートレス）ので、一回ごとの処理は独立しています。シンプルで汎用性が高く、歴史も長いのが強みです。

三つの問いで言えば、RESTでは、会話を始めるのはいつもクライアントで、返す中身の形はサーバーが決め、やり取りの単位はリソースです。この答え方が合わない場面で、弱点が出ます。欲しいデータを集めるのに何度もリクエストが要る、サーバー側の変化を知るために定期的に問い合わせる（ポーリング）必要がある、といった場面です。

三つの問いの答えを変えると、ほかの方式になります

方式	会話を始めるのは	返す中身を決めるのは	やり取りの単位
REST	クライアント	サーバー	リソース
イベント駆動型（WebSockets、SSEなど）	出来事が起きたらサーバーから	サーバー	出来事の通知
GraphQL	クライアント	クライアントが欲しい形を書く	データの関係への問い合わせ
RPC（XML-RPC、SOAPなど）	クライアント	サーバー	名前の付いた手続き
gRPC	クライアント	サーバー	Protobufで定義した手続き
ファイルベース	クライアント	サーバー	ファイル

一つ目の問いの答えを変えたのが、イベント駆動型です。RESTでポーリングを続けるのは、荷物が届いたかを五分おきに玄関まで見に行くようなものです。頼む側からしか会話を始められない限り、確かめに行く回数を減らす方法がないからです。イベント駆動型は、届いたら呼び鈴を鳴らしてもらう形に向きを変え、リアルタイム性の高い用途に向きます。

二つ目の問いの答えを変えたのが、GraphQLです。必要なデータの形をクライアントが書いて送るので、RESTでは何度もリクエストが要る場面でも、一回で必要な分だけを取れます。代わりに、問い合わせの書き方を覚える手間と、サーバーの側の作り込みが増えます。

三つ目の問いの答えを変えたのが、RPCとgRPC、ファイルベースです。RPCはリソースではなく手続きを名前で呼び、gRPCはその手続きと受け渡すデータの形をProtobufで定義して、効率のよい形式で速く通信します。マイクロサービスどうしの通信と相性がよいとされます。ファイルベースは単位をファイルにして、大容量のデータの受け渡しに向きます。

ただし、三つの問いで見えないものもあります。どれだけの速さが要るか、扱う情報にどこまでの守りが要るか、使う人や周りのツールが慣れているか、といった物差しは、この表には入っていません。三つの問いは方式の性格をつかむためのもので、選ぶ物差しのすべてではありません。

GPTsのアクションは、GPTが始め、一回で終わるやり取りです

ChatGPTを自分用にカスタマイズするGPTsのアクションは、2024年時点では、OpenAPIの形式で書いたAPIを、会話の途中でGPTが一回ずつ呼び出して答えを受け取る仕組みでした。三つの問いで言えば、会話を始めるのはGPTで、やり取りは一回ごとに閉じます。RESTの形で用意されたAPIがいちばん素直につながるのはこのためです。

この位置からは、できないことも見えます。GPTに、何か変化があったら教えて、と頼んでも、アクションでは自分から呼びに行くことしかできないので、向こうから知らせが届く日は来ません。使いたいサービスがイベント駆動型やGraphQLを主にしているなら、REST形式の窓口も用意されていないかを、まずドキュメントで確かめます。

どの方式がこの先広まるか、GPTsのアクションの仕組みがどう変わるかは、2024年時点の情報からは言えません。言えるのは、どの方式を選ぶにしても、三つの問いへの自分の答えを先に持っておけば、新しい方式が出てきたときにも同じ問いで比べられる、ということまでです。

あなたがつなごうとしているサービスで、会話を始めてほしいのは、本当はどちら側でしょうか。今の方式は、その答えと合っているでしょうか。

この記事の背景にある考え方は、拙著『GoogleのAI NotebookLM 意思決定の強化書』の5章2節「選択肢表を作る」に書きました。選択肢は粒度をそろえ、抜け漏れなく並べてはじめて比べられる、という節で、「選択肢が1つだけでは、評価して選ぶという意味での意思決定にはなりません。」とあります。この節を読むと、次に来る方式はどれかという一本道の問いを、自分の用途の前提から候補を並べ直す問いに置き換えられるようになります。