GraphQLでの開発を外注しようとするとき、あるいはベンダーからGraphQLを提案されたとき、発注側がまず整えるべきなのがRFP（提案依頼書）と要件定義です。ところが「GraphQLで作りたい」という技術ありきの依頼書は、しばしば失敗の入り口になります。本来定義すべきは「自社のどんな事業要件に対して、GraphQL・REST・gRPCのどれが最適か」という技術選定の判断軸であり、それを言語化できていないRFPは、提案の妥当性を比較できないまま発注に進んでしまうからです。
本記事は、GraphQL開発のRFP・要件定義書・提案依頼書を、発注企業の視点から実務的に解説します。REST・GraphQL・gRPCを使い分けるための判断フレーム、要件定義書に必ず盛り込むべき非機能要件、Dataloaderによる性能担保やスキーマ規約といった取り決め事項まで、enechain社の運用知見やBotoi社のREST採用判断、具体的なレイテンシ数値を交えて整理します。読み終えるころには、技術に振り回されないRFPの作り方と、提案の妥当性を見抜く目が身につくはずです。なお、GraphQL開発の全体像をまだ把握していない方は、まずGraphQL開発の完全ガイドから読むことをおすすめします。
REST・GraphQL・gRPCを使い分ける判断フレーム
RFPの核心は、API設計のパラダイムをどう選ぶかにあります。GraphQL・REST・gRPCはそれぞれ得意分野が異なり、自社の要件に対してどれが最適かを判断するフレームを持つことが、要件定義の出発点です。ここでは、発注側が技術選定の妥当性を評価するための判断軸を整理します。これを理解すれば、ベンダー提案を鵜呑みにせず、自社の言葉で技術選定の是非を問えるようになります。
選定を分ける3つの問いと判断基準
API設計の選定は、突き詰めると3つの問いに集約されます。第一に「クライアントは多様か」。Web・iOS・Androidなど複数の異なるクライアントが、それぞれ少しずつ違うデータの組み合わせを必要とするなら、GraphQLが有力です。一つのスキーマから各クライアントが必要な分だけ取得でき、オーバーフェッチ（不要なデータまで取得）もアンダーフェッチ（足りずに何度も取得）も避けられます。
第二に「キャッシュ可能性は最優先か」。コンテンツ配信中心で、同じデータを大量のユーザーに高速に返すことが最優先なら、RESTが適します。Botoi社は150以上のエンドポイントを抱えながらキャッシュ最重視のためあえてRESTを採用し、CDNキャッシュで20ms未満を達成しました（出典：Botoi）。RESTはURLごとにリソースが定まるためHTTPキャッシュやCDNとの相性が抜群です。第三に「内部通信が主目的か」。マイクロサービス間の高速な内部通信が主眼なら、低レイテンシのgRPCが向きます。
この3つの問いに自社の状況を当てはめれば、どのパラダイムが要件に合うかの輪郭が見えます。要件定義書には、この判断の根拠となる「クライアントの構成」「キャッシュ要件」「内部通信の有無」を必ず明記すべきです。技術名を指定する前に、これらの事業要件を言語化しておけば、ベンダーは根拠を持って技術を提案でき、発注側もその妥当性を検証できます。
レイテンシ要件を数値で定義する
要件定義書では、性能要件を感覚ではなく数値で定義することが重要です。API設計ごとのレイテンシ目安は、REST 50〜200ms、GraphQL 50〜300ms、gRPC 10〜50msとされています。GraphQLの上限がやや大きいのは、柔軟なクエリゆえにN+1問題のような非効率が起きやすいことの裏返しです。自社サービスが許容できる応答時間を数値で定めておけば、選定したパラダイムが要件を満たせるかを客観的に評価できます。
ただし、これらの数値はあくまで素の目安であり、キャッシュ戦略やアーキテクチャ全体で大きく変わります。Botoi社がRESTとCDNで20ms未満を達成したのは、プロトコル単体の数値ではなくキャッシュを効かせた結果です。要件定義では「どんな条件下でのレイテンシか」まで踏み込み、キャッシュ可能なデータと不可能なデータを分けて性能目標を設定することが、現実的な要件になります。
発注企業がここで注意すべきは、ベンダーが示すベンチマークの最大値を鵜呑みにしないことです。「GraphQLだから速い」「gRPCだから速い」といった単純な主張ではなく、自社のユースケースに近い条件での性能をどう担保するかを問うべきです。要件定義書にレイテンシ要件を数値で明記しておけば、この検証の土台ができます。
要件定義書に盛り込むべき非機能要件
GraphQLを採用すると決めた場合、機能要件だけでなく、運用フェーズを左右する非機能要件を要件定義書に盛り込むことが極めて重要です。GraphQLには固有の落とし穴があり、それらへの対策を発注時に取り決めておかないと、運用フェーズで性能やセキュリティのトラブルに苦しみます。ここでは、enechain社の運用知見を踏まえて、要件定義書に必須の非機能要件を整理します。
性能・セキュリティの取り決め事項
性能面では、N+1問題への対策をDataloaderでどう実装するかを要件として明記すべきです。enechain社の事例が示す通り、DataloaderにはキーをリクエストされたものとレスポンスをDBから取得した結果を「キーの順序通りに返す」制約があり、明示的な並べ替え実装が必要です（出典：enechain Tech Blog）。これを怠ると性能問題やデータ不整合が起きます。要件定義書で「N+1対策をどう講じ、どう検証するか」を取り決めておくことが、運用フェーズの安定を左右します。
セキュリティ面では、GraphQL固有のDoS（サービス妨害）リスクへの対策を要件化することが重要です。GraphQLは柔軟なクエリが書けるため、深くネストした重いクエリを大量に投げられると、サーバーが過負荷に陥ります。クエリの深さ制限や複雑度の上限設定、レート制限といった対策を要件に含めるべきです。インジェクション対策には機械学習を用いる研究もあり、SQLi検知でAccuracy 0.9678、XSS検知でAccuracy 0.9938という高精度が報告されています（出典：arXiv）。
ただし、このML検知には現実的なトレードオフがあります。静的チェックなら数10msで済む応答が、ML推論を挟むと数千msに跳ね上がるボトルネックが報告されているのです。要件定義では「セキュリティと性能の両立をどう図るか」まで踏み込み、全クエリへのML適用ではなく、静的チェックとの組み合わせやリスクの高い経路への限定適用といった現実的な落としどころを取り決めるべきです。これを曖昧にすると、過剰なセキュリティ施策で性能を破綻させかねません。
スキーマ規約とエラー設計の取り決め
GraphQLはスキーマが仕様書を兼ねるため、スキーマの品質を保つ規約を要件として取り決めることが、長期保守性の鍵になります。enechain社は、各フィールドのデータ取得処理であるResolverに「description（説明文）」を必ず記述するルールを、ESLintプラグインで機械的に強制しています（出典：enechain Tech Blog）。説明文が充実していればフロントエンド開発者が自己解決でき、引き継ぎ性も高まります。要件定義書で「スキーマ規約をLintツールで自動強制すること」を求めれば、属人化を防げます。
エラー設計も重要な取り決め事項です。enechain社は、クライアント側の入力ミスに起因する4XX系のエラーを専用スキーマとして型定義し、クライアントが型補完を効かせて堅牢にエラー処理できるようにしました。一方、サーバー内部障害である5XX系はGraphQLのSpec通りに扱うという使い分けを採用しています。要件定義書で、エラーの性質に応じた表現方法を取り決めておけば、開発者体験と堅牢性を両立した実装が期待できます。
これらの非機能要件は、機能要件に比べて見落とされがちですが、運用フェーズの安定と長期保守性を決定づけます。発注側がこれらをRFP・要件定義書で明示できれば、ベンダーは運用まで見据えた提案をせざるを得ず、提案の質が上がります。riplaは、フルスクラッチ受託と国内開発の知見をもって、こうした非機能要件まで含めた要件定義を支援しています。
提案依頼書（RFP）の書き方と評価のポイント
要件が固まったら、それをRFP（提案依頼書）に落とし込み、複数のベンダーから提案を受けて比較します。RFPの書き方一つで、得られる提案の質と比較のしやすさが大きく変わります。ここでは、GraphQL開発のRFPで押さえるべき書き方と、受け取った提案を評価するポイントを整理します。技術に詳しくない発注担当者でも、提案の妥当性を見抜くための実務的な視点です。
技術名ではなく要件で依頼する
RFPでもっとも避けるべきが、「GraphQLで開発してください」と技術名を指定して依頼することです。技術を指定してしまうと、その技術が本当に自社要件に最適かを検証する機会を失い、ベンダー間で提案を比較する余地もなくなります。代わりに、「Web・iOS・Androidの3クライアントが異なるデータを必要とする」「コンテンツ配信が中心でキャッシュ性能を重視する」といった事業要件を記述し、最適なAPI設計はベンダーに提案させるべきです。
要件で依頼するメリットは二つあります。第一に、複数ベンダーの提案を「同じ要件への異なる解」として横並びで比較でき、各社の技術力や思考の深さが見えます。第二に、GraphQL以外がより適切な場合に、ベンダーが正直にRESTやgRPCを提案する余地を残せます。Botoi社のようにキャッシュ最重視であえてRESTを選ぶのが正解の場合もあり、技術指定はこうした最適解を排除してしまいます。
もちろん、既存システムとの整合や社内の技術方針からGraphQLを前提とする合理的な理由があるなら、その背景を含めてRFPに記載すればよいでしょう。重要なのは「なぜその技術なのか」の理由を要件として言語化することです。理由なき技術指定こそが、提案の妥当性検証を妨げる最大の落とし穴になります。
提案の妥当性を見抜く評価基準
受け取った提案を評価する際、技術力を見抜く格好の試金石があります。第一に、GraphQLを提案するなら、N+1問題への対策（Dataloaderの実装とキー順序制約への対処）に言及しているか。これに触れない提案は、運用フェーズの落とし穴を理解していない可能性があります。第二に、キャッシュ要件への回答です。GraphQLはHTTPキャッシュが効きにくい弱点があり、それをどう補うかを説明できるベンダーは信頼できます。
第三に、スキーマ規約やドキュメント納品、保守契約をどう設計するかです。ESLintによるスキーマ規約の自動強制や、設計ドキュメントの納品範囲、バージョンアップ保守の体制まで提案に含まれているかは、長期保守性と引き継ぎ性を左右します。第四に、セキュリティと性能のトレードオフを理解しているか。ML検知の数千msボトルネックのような現実を踏まえ、現実的なセキュリティ設計を示せるベンダーは、技術の表層だけでなく運用まで理解しています。
これらの評価基準は、技術に詳しくない発注担当者でも、提案書のなかに該当する記述があるかをチェックリスト的に確認できます。提案の華やかさや見積金額の安さだけでなく、運用フェーズの落とし穴にどこまで踏み込んでいるかで判断することが、後悔しない発注につながります。riplaは、こうした運用まで見据えた提案と要件定義を一貫して支援しています。GraphQLの技術的機能・特性の詳細は、後述の関連記事もあわせてご覧ください。
まとめ
GraphQL開発のRFP・要件定義を振り返ると、核心は「技術名ではなく事業要件で依頼する」という原則に集約されます。クライアントの多様性・キャッシュ要件・内部通信か外部公開かという3つの問いで、GraphQL・REST・gRPCの使い分けを判断フレームとして言語化し、レイテンシ要件は数値（REST 50〜200ms・GraphQL 50〜300ms・gRPC 10〜50ms）で定義する。これが提案比較を可能にする土台です。
そして、Dataloaderによる N+1対策、スキーマ規約のESLint強制、エラー設計、セキュリティと性能の両立といった非機能要件まで取り決めることが、運用フェーズの安定と長期保守性を決めます。enechain社の運用知見やBotoi社のREST採用判断は、こうした要件の重要性を実例で裏付けてくれます。提案の妥当性をチェックリストで見抜き、要件定義から伴走できるパートナーと組んでください。riplaはフルスクラッチ受託と国内開発を組み合わせ、事業要件から逆算した要件定義を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。