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