0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@sugiyama404(sugi 404)Team Tea & Water

REST API・GraphQL・gRPCのトレードオフ~大規模システムにおける技術選定と設計判断~

0
Posted at

1. はじめに

APIアーキテクチャの選定は、システム設計の中でも特に長期的な影響を持つ意思決定の一つである。適切なAPIスタイルを選べば、開発速度・保守性・運用コストのすべてにおいて恩恵を受けられる。一方で選定を誤れば、数年後に技術負債として返ってくる。それも、容易にリファクタリングできない形で。

なぜAPIアーキテクチャの選定が重要なのか

APIはシステムの「境界面」である。フロントエンドとバックエンド、マイクロサービス間、外部パートナーとのインテグレーション——どこにも必ずAPIが存在する。その境界面の設計が、次の要素を決定する。

  • チーム間の協調コスト（フロントとバックが独立して動けるか）
  • パフォーマンスのボトルネック（通信量・レイテンシ）
  • スキーマ変更時の影響範囲
  • 可観測性と障害対応の難易度

RESTだけでは解決できない課題の出現

REST APIは2000年代初頭から広く普及し、現在も多くのシステムで主流となっている。しかし、システムの複雑化とともに、RESTでは対処しきれない課題が浮き彫りになってきた。

モバイルアプリの台頭がその代表例だ。モバイル端末はPC比で通信帯域が限られ、バッテリー消費も考慮しなければならない。しかし従来のREST設計では、1画面を表示するために複数エンドポイントを叩く必要があり（Under Fetching）、逆に不要なフィールドまで返ってくる（Over Fetching）という問題が常態化していた。

マイクロサービスアーキテクチャの普及も課題を加速させた。数十・数百のサービスが互いに通信するシステムでは、JSON over HTTPの非効率さが無視できないレベルになる。シリアライズ/デシリアライズのコスト、テキストベースのペイロードサイズ、型情報の欠如——これらは小規模システムでは些細だが、1秒間に数万リクエストが飛び交う内部通信では深刻なボトルネックになる。

GraphQLとgRPCが登場した背景

GraphQLは2015年にFacebookが公開した仕様で、「クライアントが必要なデータを必要な形で取得できる」ことを主眼に設計された。巨大なソーシャルグラフを持つFacebookにとって、クライアントごとに最適なデータを返すことは生存戦略に近い課題だった。

gRPCはGoogleが2015年に公開したRPCフレームワークで、内部的に長年使われてきたStubbyと呼ばれる仕組みをオープン化したものだ。Protocol BuffersとHTTP/2を組み合わせることで、高速・型安全・双方向ストリーミングを実現している。大規模分散システムの内部通信を想定して設計されており、その設計思想はRESTとは根本的に異なる。

技術選定を誤った場合のコスト

技術選定ミスの典型的なシナリオを挙げると：

  • 内部マイクロサービス間にRESTを選択 → サービス数増加とともに通信オーバーヘッドが無視できなくなり、最終的にgRPC移行を迫られる
  • 公開APIにgRPCを選択 → ブラウザクライアントからの直接アクセスができず、grpc-webのプロキシ層を急遽導入
  • 小規模スタートアップにGraphQLを導入 → スキーマ設計とDataLoader実装の学習コストで立ち上がりが遅延、チームのリソースを消耗

いずれも「技術として優れているから選んだ」という動機が共通している。問題は技術の優劣ではなく、そのシステムと組織に対する適合性の評価が欠けていた点にある。

2. REST APIとは何か

RESTの特徴

REST（Representational State Transfer）はRoy Fieldingが2000年の博士論文で提唱したアーキテクチャスタイルである。特定のプロトコルやフォーマットを規定するものではなく、設計原則の集合体として定義されている。

リソース指向
RESTの中心にあるのは「リソース」という概念だ。/users/123というURIはユーザーというリソースを表現し、HTTPメソッド（GET/POST/PUT/DELETE）によってそのリソースへの操作を表現する。

HTTP標準との親和性
RESTはHTTPの意味論を最大限に活用する。ステータスコード、キャッシュヘッダ（Cache-Control, ETag）、コンテンツネゴシエーション——これらはHTTPがすでに定義している仕組みであり、RESTはそれを再利用する。

シンプルさと学習コスト
cURLやブラウザのDevToolsで即座に確認できる。テストも容易で、APIクライアントライブラリの選択肢も豊富だ。新しいエンジニアがチームに加わったとき、REST APIのエンドポイント一覧があれば概ね理解できる。この「説明コストの低さ」は実務上の大きなメリットである。

RESTのメリット

エコシステムの成熟
REST用のツールは圧倒的に充実している。API Gatewayのサポート、CDNによるキャッシュ、OpenAPI/Swagger によるスキーマ定義、モックサーバー生成、テストフレームワーク——あらゆる場面でREST向けのソリューションがファーストクラスとして提供されている。

HTTPキャッシュとの相性
GETリクエストはHTTPのキャッシュ機構と自然に連携する。CDNレベルでのキャッシュが容易に機能し、これは高トラフィックシステムにおいて非常に有効だ。/products/featuredのようなエンドポイントをCDNでキャッシュすれば、バックエンドへの負荷を劇的に削減できる。

外部公開APIとしての標準性
外部パートナーや顧客向けに公開するAPIとして、RESTは事実上の標準である。ドキュメントの書き方・認証パターン（OAuth/APIキー）・バージョニング戦略——すべてに確立した慣習があり、API利用者にとっての認知コストが最も低い。

RESTのデメリット

Over Fetching
/users/123を叩くと、表示に必要なのはname・avatarの2フィールドだけなのに、30フィールドすべてが返ってくる。これはモバイル環境では通信量の無駄であり、帯域制限の厳しい環境では体験劣化に直結する。

Under Fetching（N+1問題の源泉）
一覧画面で10件の記事と各記事の著者名を表示したい場合、REST設計では/articles（1回）＋/users/{id}×10回のリクエストが発生しやすい。これを回避するために専用エンドポイントを作り続けると、APIが肥大化し、「何のためのエンドポイントか」の管理が困難になる。

マイクロサービス環境での課題
複数のバックエンドサービスからデータを集約する場合、BFF（Backend for Frontend）を挟まないと、クライアントは複数のサービスに直接リクエストを送ることになる。BFFを設けたとしても、そのBFF自体が複数のサービスへREST APIを叩くロジックを内包することになり、コードの複雑さが増す。

型安全性の弱さ
REST APIのレスポンスはJSONであり、型情報はスキーマ定義（OpenAPIなど）に別途記述する。しかしこの定義とサーバーの実装が乖離することは珍しくなく、コンパイル時に検出できないバグの原因となる。型安全性はコードジェネレーターで補完できるが、ツールチェーンの維持コストが発生する。

API契約管理の難しさ
/v1/usersから/v2/usersへのバージョンアップ時、古いクライアントとの後方互換性をどこまで維持するか、いつ廃止するかの管理は実務上の頭痛の種だ。特に外部公開APIでは廃止のタイミングをコントロールできず、長期間にわたって旧バージョンを維持する必要が生じる。

3. GraphQLとは何か

GraphQLの特徴

GraphQLはクエリ言語とランタイムの仕様である。クライアントは単一のエンドポイント（通常/graphql）に対して、取得したいデータの「形」をクエリとして送信する。サーバーはそのクエリに従って過不足のないレスポンスを返す。

スキーマはサーバーとクライアントの契約として機能する。スキーマはSDL（Schema Definition Language）で記述され、型定義・クエリ・ミューテーション・サブスクリプションをすべて含む。

GraphQLのメリット

必要なデータのみ取得
クライアントがクエリで取得フィールドを指定するため、Over FetchingとUnder Fetchingの両方を同時に解消できる。

query {
  user(id: "123") {
    name
    avatar
    recentPosts(limit: 3) {
      title
      publishedAt
    }
  }
}

このクエリ一つで、ユーザー情報と直近の投稿3件が1リクエストで取得できる。

フロントエンド開発効率の向上
バックエンドAPIの変更を待たずに、スキーマが定義されていれば型付きのクライアントコードを生成できる。フロントエンドとバックエンドの並行開発が現実的になり、チームの独立性が高まる。TypeScriptと組み合わせると、APIレスポンスの型安全性がコンパイル時に保証される。

BFF（Backend for Frontend）との相性
GraphQLはBFF層として機能するのに適している。バックエンドの複数RESTサービスを統合したGraphQLスキーマを設計し、それをモバイルアプリ・Webアプリ・管理画面がそれぞれ必要なフィールドのみ取得する構成は、多くのサービスで採用されている設計パターンだ。

モバイル環境での利点
通信量の最適化が直接的にモバイルアプリのパフォーマンスと電池消費に影響する環境では、GraphQLのネットワーク効率が実感しやすい。Persistened Queryと組み合わせることで、送受信するデータ量をさらに削減できる。

GraphQLのデメリット

N+1問題
GraphQLは設計上、リゾルバーが再帰的に呼ばれる構造を持つ。著者付き記事一覧を返すクエリでは、記事リゾルバーが10回実行され、各記事の著者リゾルバーがさらに10回実行される——これがN+1問題だ。DataLoaderパターンを使えばバッチ処理でこれを回避できるが、DataLoaderの実装・管理はそれ自体が一定の開発コストを伴う。

HTTPキャッシュ戦略の複雑化
RESTはGETリクエストをURLをキャッシュキーとしてCDNキャッシュできる。しかしGraphQLはほとんどの場合POSTを使い、クエリボディが異なる。CDNレベルでのキャッシュが機能しないため、ApolloのクライアントサイドキャッシュやサーバーサイドのPersisted Queryキャッシュなど、個別のキャッシュ戦略が必要になる。

スキーマ管理の難易度
スキーマはサービス成長とともに肥大化する。フィールドの廃止（Deprecation）、型の変更、スキーマのフェデレーション（Apollo Federationなど）——これらを適切に管理しなければ、長期的にスキーマが「触れないもの」になる。

運用・モニタリング難易度
全リクエストが同一エンドポイントに集中するため、「どのクエリがパフォーマンスを劣化させているか」の特定がRESTより難しい。APMツールでの識別、クエリコストの計算と制限（Query Depth Limiting, Query Complexity Analysis）、レート制限の設計——いずれもGraphQL固有の運用知識が求められる。

4. gRPCとは何か

gRPCの特徴

Protocol Buffers（protobuf）
gRPCのメッセージフォーマットはProtocol Buffersだ。.protoファイルにスキーマを定義し、それから各言語のコードを自動生成する。バイナリフォーマットであるためJSONより圧縮効率が高く、シリアライズ/デシリアライズが高速だ。

HTTP/2
gRPCはHTTP/2上で動作する。単一TCP接続での多重化、ヘッダー圧縮、サーバープッシュ——これらがgRPCのパフォーマンス特性を支える基盤だ。

ストリーミング
gRPCは4種類の通信パターンをサポートする。

パターン 説明
Unary 通常のリクエスト/レスポンス
Server Streaming 1リクエストに対して複数レスポンス
Client Streaming 複数リクエストに対して1レスポンス
Bidirectional Streaming 双方向ストリーム

型安全
.protoファイルが単一の信頼できるスキーマ定義として機能し、サーバー/クライアント双方のコードが自動生成される。実行時の型不一致がコンパイル段階で検出される。

gRPCのメリット

パフォーマンス
公開されているベンチマークでは、JSONシリアライズに比べてprotobufは数倍から十数倍高速なシリアライズを実現する場合がある（データ構造による）。HTTP/2による多重化でコネクション管理コストも低く、大量のRPCが飛び交うマイクロサービス間通信では顕著なパフォーマンス差が出る。

通信量削減
バイナリフォーマットによるペイロード圧縮は、ネットワーク帯域の制約がある環境（クラウドのデータ転送コスト、低帯域環境）で実際のコスト削減につながる。

内部API最適化
「サービス間の契約を厳格に定義し、コード生成で実装する」というワークフローは、大規模なマイクロサービス環境で特に効果を発揮する。スキーマドリフト（実装とドキュメントの乖離）が構造的に発生しにくい。

大規模分散システムとの相性
KubernetesのAPIサーバーもgRPCを使う。GoogleやNetflixなどの大規模分散システムが実績を持ち、ロードバランシング・サービスディスカバリー・タイムアウト管理などのインフラ機能との統合も成熟している。

gRPCのデメリット

学習コスト
.protoファイルの記述、コード生成ツールチェーンの設定、バイナリプロトコルへの慣れ——RESTに慣れたエンジニアにとって学習のステップが多い。組織全体に浸透させるにはドキュメント整備と教育コストがかかる。

デバッグ難易度
バイナリプロトコルはcURLで叩けない。grpcurlやevansなどのツールが存在するが、RESTのようにブラウザのDevToolsで直接確認できる開発体験とは差がある。通信内容を確認するためにWiresharkやプロキシでのデコードが必要になる場面もある。

ブラウザとの相性
ブラウザからgRPCを直接呼び出すことはできない（HTTP/2の使い方がブラウザの制約に抵触する）。gRPC-Webという仕様と対応プロキシ（Envoyなど）を介すことで解決できるが、直接のネイティブサポートではなく、アーキテクチャに余分なレイヤーが加わる。

外部公開APIとしての課題
外部パートナーや一般開発者向けにgRPC APIを公開することは現実的に難しい。ドキュメント作成ツール、SDKの提供、エコシステムの整備——すべてにおいてRESTに比べてサポートが薄い。外部向けAPIをgRPCのみで設計することはほぼ推奨されない。

5. REST vs GraphQL vs gRPC 比較

多角比較表

評価軸 REST GraphQL gRPC
開発速度（初期） ◎ 最も早い △ スキーマ設計に時間 △ proto定義とビルド設定
開発速度（長期） △ エンドポイント増加で低下 ◎ スキーマ拡張が容易 ○ 型安全で安定
学習コスト ◎ 最低 ○ 中程度 △ 最高
運用容易性 ◎ 標準ツール豊富 △ 専用知識必要 △ バイナリ解析難
可観測性 ◎ URLベースで分析容易 △ 単一エンドポイントで難 ○ メタデータ活用で可能
パフォーマンス ○ 標準的 ○ HTTP/1.1依存の場合あり ◎ 最高
スケーラビリティ ○ 水平スケール容易 ○ 適切な設計が必要 ◎ 大規模向け設計
型安全性 △ スキーマ外定義が必要 ○ スキーマ定義あり ◎ コンパイル時保証
API契約管理 △ OpenAPIとの乖離リスク ○ スキーマファースト ◎ proto単一ソース
クラウドコスト ○ 標準的 ○ クエリ最適化で削減可能 ◎ 通信量少なく安価
チーム拡大耐性 △ エンドポイント管理が煩雑 ○ スキーマで境界明確 ○ protで契約明確
ブラウザ対応 ◎ ネイティブ ◎ ネイティブ △ gRPC-Web必要
外部公開API ◎ 標準 ○ 増加傾向 × 非推奨
内部通信 ○ 可能だが非効率 ○ 中程度 ◎ 最適

比較の読み方

開発速度について
初期開発速度はRESTが最も高い。しかし長期的には、エンドポイントが増えるにつれてRESTの管理コストが上昇する。GraphQLはスキーマ設計の初期投資が大きいが、長期的にはフロントエンドとバックエンドの協調コストが下がる傾向にある。

可観測性について
RESTはGET /orders/statusとPOST /paymentsのようにURLでオペレーションが識別でき、ログ・APM・アラートの設定が直感的だ。GraphQLは全リクエストがPOST /graphqlに集中するため、クエリ名やオペレーション名での識別設定が必要になる。gRPCはメタデータとサービス名/メソッド名の組み合わせで識別が可能だが、対応したオブザーバビリティツールの設定が前提となる。

クラウドコストについて
パブリッククラウドのデータ転送コストは、リージョン間・可用性ゾーン間・インターネット向けそれぞれに料金が発生する。マイクロサービスが多く、サービス間通信が頻繁なシステムでは、gRPCのバイナリ圧縮による転送量削減がコスト面で実際に有効になる。

6. システム規模ごとの最適解

小規模システム（社内システム・PoC・スタートアップ）

推奨構成：REST（シンプルに）

小規模システムの最大の制約は「人と時間」だ。技術的洗練よりも、チームが素早く実装・修正・廃棄できる構成が優先される。

  • エンジニア2〜5名のスタートアップがGraphQLのDataLoaderとスキーマフェデレーションを設計する時間的余裕はない
  • PoCは数週間で完成させ、仮説を検証することが目的だ
  • REST + OpenAPIで十分な設計品質と契約管理が可能

例外として、フロントエンドエンジニアが複数いてUIの変化が激しいスタートアップでは、GraphQLを選択するトレードオフが成立する場合もある。しかしその場合もスキーマシンプルに保つ規律が重要だ。

中規模システム（SaaS・BtoBサービス）

推奨構成：REST + GraphQL（BFF層）または REST のみ

SaaSやBtoBサービスは、外部公開APIと内部フロントエンドAPIの2種類の境界面を持つことが多い。

  • 外部公開API（パートナー向け）：REST + OpenAPIが最適。外部開発者にとっての使いやすさと標準性を優先
  • フロントエンドAPI（自社Web/モバイル）：GraphQLのBFFを導入することで、フロントエンドの変化に柔軟に対応できる

この構成では、RESTがバックエンドサービスの土台となり、GraphQL BFFがフロントエンドの複雑さを吸収するレイヤーとして機能する。サービス間通信はまだREST（またはHTTPベース）でも許容範囲内であることが多い。

大規模システム（EC・FinTech・プラットフォーム事業）

推奨構成：GraphQL + gRPC（内部通信）+ REST（外部公開）

大規模プラットフォームでは、複数のドメインサービス（商品・在庫・注文・ユーザー・決済）が高頻度で通信する。ここでのボトルネックは技術の「選択」よりも「組み合わせ」にある。

  • 内部サービス間通信（同期）：gRPCで型安全・高速な通信を実現。proto定義がサービス間契約の単一ソースになる
  • フロントエンド向けAPI：GraphQL BFFを設けてフロントエンドの多様な要求を吸収
  • 外部公開API（パートナー・SDKユーザー）：REST APIを維持し、外部エコシステムとの整合性を保つ

FinTechでは特に「監査ログ」と「トレーサビリティ」が重要になる。gRPCのメタデータとトレーシング（OpenTelemetry）の統合、GraphQLのオペレーション識別ログ——これらを設計段階から組み込む必要がある。

AIシステム（推論API・MLOps基盤）

推奨構成：ケースバイケースだが、gRPC + REST の組み合わせが有効

AI推論APIには独特の要件がある。

  • ストリーミング推論（LLMのtokenストリーミングなど）：Server Sent Events（SSE）over HTTPかgRPCのサーバーストリーミングが適する。レイテンシ要件次第でgRPCが有利
  • 外部向け推論API：RESTまたはSSEが標準。SDKの提供しやすさと外部開発者の利便性を優先
  • MLパイプライン内部通信（Feature Store・モデルサーバー間）：gRPCが効果的。TensorFlow ServingやTriton Inference Serverは既にgRPCをサポートしている
  • 実験管理・MLOpsプラットフォームのAPI：REST + OpenAPIで十分。データサイエンティストがcurlやPythonクライアントで直接触れる使いやすさが重要

リアルタイムシステム（システムトレード・IoT・ゲーム）

推奨構成：gRPCのBidirectional Streaming または WebSocket（REST/GraphQLはサブシステムで補完）

リアルタイム性が最優先の要件では、REST/GraphQLの「リクエスト/レスポンス」パラダイム自体が制約になる。

  • システムトレード：マイクロ秒〜ミリ秒のレイテンシ要件では、gRPCのストリーミングが有効。ただし超低レイテンシが必要な場合はTCPの直接利用やカスタムプロトコルも検討対象になる
  • IoT：デバイスからサーバーへのデータ収集にはMQTTやgRPCのクライアントストリーミング。管理APIはREST
  • ゲーム（リアルタイムマルチプレイヤー）：WebSocketまたはgRPC Bidirectional Streamingでゲーム状態を同期。ロビー・ユーザー管理などのサービスはREST

7. アーキテクチャパターン比較

パターン1：RESTのみ

Client
  └── REST API Server
        ├── Database
        └── External Services

メリット

  • 最もシンプルな構成で、全員が理解しやすい
  • ツールとエコシステムが豊富
  • オンコールエンジニアが深夜でも障害対応できる

デメリット

  • フロントエンドのデータ要求の変化のたびにバックエンド修正が発生
  • マイクロサービス化が進むとBFF不在でクライアントへの負担が増加

向いている組織：小規模チーム、フルスタックエンジニア中心、初期フェーズのプロダクト
向いているシステム：社内ツール、PoC、CRUD中心の管理システム

パターン2：REST + BFF

Mobile App ─┐
Web App  ───┤──> BFF (REST) ──> Backend REST Services
Admin    ───┘

メリット

  • クライアント種別ごとに最適化したレスポンスを提供できる
  • バックエンドサービスへの変更をBFF層で吸収できる

デメリット

  • BFFがボトルネック兼単障害点になりやすい
  • クライアント種別が増えるたびにBFFが肥大化する

向いている組織：フロントエンドとバックエンドのチームが分離している、中規模以上
向いているシステム：Webとモバイルの両方をサポートするSaaS

パターン3：GraphQL + REST

Client ──> GraphQL API (BFF) ──> REST Service A
                              ──> REST Service B
                              ──> REST Service C

メリット

  • フロントエンドはGraphQLの柔軟性を享受できる
  • バックエンドサービスは既存のREST APIを維持できる
  • フロントエンドとバックエンドの独立性が高い

デメリット

  • GraphQL→REST変換レイヤーにN+1問題が発生しやすい
  • DataLoaderとリゾルバーの設計が複雑になる
  • GraphQLスキーマとバックエンドRESTスキーマの二重管理

向いている組織：フロントエンドチームが独立してAPIを組み合わせたい、既存RESTを捨てられない
向いているシステム：フロントエンドの変化が激しいSaaS、複数クライアントを持つプラットフォーム

パターン4：REST + gRPC

External Client ──> REST API Gateway ──> gRPC Service A
                                      ──> gRPC Service B
                                      ──> gRPC Service C

メリット

  • 外部向けはRESTの標準性を維持
  • 内部サービス間はgRPCの高パフォーマンスを享受
  • 契約管理が外部（OpenAPI）と内部（proto）で明確に分離される

デメリット

  • REST→gRPCのトランスコーディングレイヤーの管理が必要（grpc-gateway等）
  • 2種類のAPIスタイルをチームが習得する必要がある

向いている組織：マイクロサービスが成熟しているチーム、SRE・インフラが整っている
向いているシステム：大規模EC、FinTech、内部マイクロサービスが多いプラットフォーム

パターン5：GraphQL + gRPC

Client ──> GraphQL Gateway ──> gRPC Service A
                            ──> gRPC Service B
                            ──> gRPC Service C

メリット

  • フロントエンドの柔軟性（GraphQL）と内部通信の効率性（gRPC）を両立
  • 型安全性がフロントエンドからバックエンドまで一貫している
  • Apollo Federationなどで大規模なグラフをスキーマ分散管理できる

デメリット

  • 学習コストが最も高い構成の一つ
  • GraphQLリゾルバーからgRPCクライアント呼び出しのN+1問題に特に注意が必要
  • スキーマ管理・DataLoader・proto管理の三重の複雑さ
  • 小規模チームには過剰設計になる可能性が高い

向いている組織：APIプラットフォームチームが存在する、GraphQL/gRPC双方の習熟者がいる
向いているシステム：大規模プラットフォーム事業、マイクロサービス数が20以上の分散システム

パターン6：GraphQL + gRPC + Event Driven

Client ──> GraphQL Gateway ──> gRPC Service A ──> Message Queue (Kafka/Pub-Sub)
                            ──> gRPC Service B ──>       │
                            ──> gRPC Service C <─── Event Consumer
                                                         └── gRPC Service D

メリット

  • 同期（gRPC）と非同期（イベント）の責務を明確に分離できる
  • 高トラフィック下でのバックプレッシャー制御が可能
  • サービス間の疎結合が最も高いパターン

デメリット

  • 複雑性が最も高く、デバッグが非常に困難
  • イベントスキーマの管理（Schema Registry）が別途必要
  • 分散トレーシングが必須で、observabilityへの投資が大きい
  • チームが成熟していない状態で導入すると運用不能になるリスク

向いている組織：大規模エンジニア組織、プラットフォームエンジニアリングチームが存在する
向いているシステム：EC（注文・在庫・決済の非同期連携）、FinTech（イベントソーシング）、大規模IoTプラットフォーム

8. 技術選定における重要な考え方

「最新・高性能だから採用する」という誤謬

技術選定の失敗パターンの多くは、「技術の優劣」への注目から始まる。「gRPCはRESTより速い」「GraphQLは柔軟性が高い」——これらは事実であっても、それだけでは採用理由として不十分だ。

問うべき問いは「この技術は、このシステムと組織の制約の中で、最もコストパフォーマンスが高いか」である。

組織規模とチーム成熟度

技術選定は技術の評価である前に、組織の評価である。

評価項目 問うべき問い
チームサイズ gRPCの学習コストを吸収できるエンジニアが何名いるか
スキルセット GraphQLのリゾルバー設計とDataLoaderを実装・レビューできるエンジニアがいるか
採用計画 新規参画者がオンボーディング時に習得できる難易度か
チームの分割方針 フロントとバックが独立したチームか、フルスタックチームか

5名のチームにGraphQL + gRPC + Event Drivenを導入することは、技術的には「最適解」であっても組織的には自殺行為になりうる。

運用体制と障害対応能力

システムはリリースして終わりではない。障害が起きたとき、深夜に対応できるエンジニアが理解できる技術スタックであることは、非機能要件の一つとして扱うべきだ。

  • gRPCのバイナリプロトコルを復号してトラブルシューティングできるか
  • GraphQLのクエリコストが急増した場合に即時対応できる知識があるか
  • イベントドリブンシステムでのゴーストメッセージやべき等性の問題を解決できるか

運用体制が薄い組織では、運用の複雑さが低い技術を選ぶことが責任ある設計判断である。

将来の拡張性と撤退コスト

拡張性は「この技術で将来の要件に対応できるか」だけでなく、「この技術が不適合だと判明したときに撤退できるか」も含む。

  • 外部公開APIをgRPCで設計した場合、外部クライアントへの影響を考えると撤退コストは極めて高い
  • GraphQLを内部マイクロサービス間通信に使っていた場合、gRPCへの移行は比較的局所的に行える
  • RESTから始めれば、要件が明確になった後でGraphQLやgRPCへ段階的に移行できる

「後から変えられる設計」を意識することは、不確実性の高い初期フェーズにおける最も合理的な設計戦略の一つである。

技術選定フレームワーク

以下のフレームワークを意思決定の補助として活用できる。

1. システム要件の明確化
   - 外部公開 or 内部通信 or 両方
   - リアルタイム性の要件
   - スキーマ変更頻度
   - パフォーマンス/レイテンシ要件

2. 組織制約の評価
   - チームサイズと成熟度
   - 既存スキルセット
   - オンコール体制

3. 選択肢の候補出し
   - 要件に適合する技術パターンを列挙

4. トレードオフの比較
   - 各候補の「得るもの」と「失うもの」を明示
   - コスト（開発・運用・学習）を定量的に見積もれる範囲で見積もる

5. 撤退シナリオの検討
   - 選択した技術が不適合と判明した場合の移行難易度を評価

6. 意思決定とドキュメント化
   - ADR（Architecture Decision Record）として記録
   - 「なぜ選ばなかったか」も記録する

9. 結論

RESTは今でも有力な選択肢である

REST APIは「古い技術」ではない。シンプルで、エコシステムが成熟していて、エンジニアの認知コストが低く、HTTPのキャッシュと親和性が高い。多くのシステムにおいて、今もなお最初の選択肢として合理性を持つ。

GraphQLはフロントエンドの課題を解決する技術である

GraphQLの本質的な価値は「フロントエンドとバックエンドの協調コストを下げること」にある。Over/Under Fetchingの解消、型安全なAPIクライアントの自動生成、複数クライアントへの一元対応——これらはフロントエンドの開発効率に直結する。しかしDataLoaderの設計、スキーマ管理、キャッシュ戦略——これらの運用コストを見過ごしてはならない。

gRPCは内部通信最適化の技術である

gRPCは内部マイクロサービス間通信のために設計されている。型安全性、高パフォーマンス、ストリーミングサポート——これらは内部通信の要件に強くマッチする。しかし外部公開APIとしての使用や、ブラウザからの直接アクセスが必要な場面では、その恩恵よりも制約のほうが大きくなる。

GraphQL + gRPCは万能ではない

この組み合わせは技術的に優れたアーキテクチャパターンだが、それが有効なのは「組織がその複雑さを吸収できる状態にある」という前提が満たされているときに限られる。複雑なアーキテクチャを維持できる組織を育てることなしに、複雑な設計だけを先行させることは、長期的な機能停滞やエンジニアの離脱につながりうる。

最適解はシステム要件と組織状況によって変わる

技術選定に普遍的な正解はない。同じ「ECシステム」であっても、5名のスタートアップと5000名のメガベンチャーでは最適な選択が異なる。同じ「マイクロサービス」であっても、SRE組織が充実しているかどうかで許容できる複雑さのレベルが変わる。

技術選定とはトレードオフを選ぶことである

最後に強調したいのは、技術選定の本質は「技術の優劣を決めること」ではなく、「制約条件の中で最適なトレードオフを選ぶこと」だという点だ。

REST、GraphQL、gRPC——いずれも設計者が特定の課題を解決するために設計した技術であり、それぞれに明確な強みと弱みがある。それらを客観的に評価し、システムの要件と組織の状況に照らして最も合理的な選択をする。その判断の質こそが、アーキテクトとしての最も重要な貢献である。

技術選定の意思決定をADRとして記録し、「なぜこの技術を選んだか」「なぜ他を選ばなかったか」を言語化する習慣は、組織の設計品質を長期的に高める最も効果的な実践の一つだ。数年後にシステムを引き継いだエンジニアが、その意思決定の文脈を理解できるように——それが技術選定ドキュメントの最終的な目的である。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?