新規の受託案件で「インフラ構成はどう組むか、クラウドは何を使うか、データベースは何を選ぶか」を自分が提案・決定する立場に回ったとき、多くのエンジニアが同じ壁にぶつかります。AWS・GCP・Azure を比較した記事は山ほど読んだのに、いざ「この案件はこの構成でいきます」と決めようとすると手が止まる、という壁です。
理由はシンプルで、世の中のクラウド・DB比較記事のほとんどが「自社サービスを運用する事業会社」か「大規模トラフィックをさばくサービス」を前提に書かれているからです。受託開発はそれとは前提が違います。納期も予算も外から固定され、案件が終わったら運用を顧客や別ベンダーに引き継ぐかもしれず、過剰なマネージド構成や冗長化はそのまま自社の利益を削ります。一般論の「ベストプラクティス」をそのまま当てはめると、むしろ案件が炎上します。
そこで本記事では、受託開発のインフラ・DB選定を「技術的な理想」ではなく「受託特有の制約からの逆算」として整理します。具体的には、受託でこそ優先順位が上がる5つの判断軸を示し、社内業務システム・toC Webサービス・短期PoC・既存環境連携という案件タイプ別に「なぜこのクラウド・このDBを選んだか」を実例で解説します。最後に、その選定理由を提案書・構成図・見積もりにそのまま書ける形に言語化する型まで落とし込みます。
なお、技術選定のうち「言語・フレームワークをどう選ぶか」という軸については、別記事の受託開発の技術選定実例で詳しく扱っています。本記事はインフラ・クラウド・DB軸に絞って解説しますので、技術選定全体を検討する際は両方を合わせてご覧ください。
受託開発のインフラ選定が「自社サービス」と決定的に違う理由
クラウド・DBの一般的な比較記事が受託案件でそのまま使えないのは、受託には自社サービスにはない3つの制約があるからです。まずはこの制約を言語化しておくと、後の判断軸がすべて腑に落ちます。
納期・予算が「与件」になる
自社サービスであれば、インフラに多少時間と費用をかけても、その投資は将来の自社資産になります。しかし受託案件では、納期も予算も提案・見積もりの段階で外から固定されます。3ヶ月でリリースする、予算はこの金額、という与件がまず先にあり、インフラ構成はその枠の中で組まなければなりません。
つまり受託では「技術的に理想の構成」より「与えられた制約に適合する構成」が優先されます。可用性を極限まで高めた美しいアーキテクチャを描いても、納期に間に合わず予算を超えれば、それは正しい選定ではありません。制約適合を最優先に置く、という発想の転換が出発点になります。
「作って終わり」ではない｜運用を誰が引き継ぐかで構成が変わる
受託開発でもっとも見落とされやすいのが、案件終了後に誰がそのシステムを運用するのか、という視点です。自社サービスなら作った自分たちがそのまま運用しますが、受託では運用主体が次の3パターンに分かれます。
- 自社で継続保守する: リリース後も保守契約を結び、自社のエンジニアが運用を続けるケース
- 顧客側が運用する: 納品後は顧客の情報システム部門などが運用を引き継ぐケース
- 別ベンダーが引き継ぐ: 開発と運用で発注先が分かれ、まったく別の会社が運用するケース
この運用主体によって、選ぶべき構成は大きく変わります。顧客や別ベンダーが運用するなら、属人的な独自構成は引き継ぎ不能のリスクになります。提案の段階で「このシステムは誰が運用するのか」を確認できているかどうかが、構成判断の前提になります。
利益率に直結する｜過剰なマネージド・冗長化が利益を削る構造
受託案件は、見積もり金額から実際にかかったコストを引いた差分が利益になります。インフラのランニングコストや構築工数が膨らめば、その分だけ利益が削られます。
ここが自社サービスと決定的に違う点です。自社サービスでマネージドサービスを手厚く使うのは「運用工数を将来にわたって減らす投資」ですが、受託で過剰なマネージド構成や冗長化を入れると、それが直接「利益を削るコスト」になります。要件に見合わない高可用性構成を入れた結果、利益がほとんど残らなかった、という話は珍しくありません。受託では「必要十分」を見極める目が、そのまま利益を守る目になります。
受託開発のインフラ・DB選定で優先順位が高い5つの判断軸
一般的なクラウド比較記事では、性能・スケーラビリティ・料金・将来性といった軸が並列に並べられます。受託ではこれらを並列ではなく、優先順位をつけて並べ替えることが重要です。ここでは受託案件で優先度が上がる5つの軸を、順番に説明します。
運用引き継ぎのしやすさ｜マネージドサービスで属人運用を減らす
受託でもっとも優先度が高いのが、運用の引き継ぎやすさです。先述のとおり、運用主体は自社・顧客・別ベンダーのいずれかに分かれ、引き継ぎが発生する可能性が常にあります。
ここで効くのがマネージドサービスの活用です。たとえばデータベースを自前で EC2 上に構築すると、バックアップ・パッチ適用・冗長化をすべて運用者が手動で管理することになり、独自の運用ノウハウが属人化します。一方、Amazon RDS のようなマネージドデータベースを使えば、バックアップや障害時のフェイルオーバーがサービス側に任されるため、引き継ぐ相手が変わっても運用手順が標準化されます。
ただし注意点があります。顧客側が運用する場合、その顧客にマネージドサービスを運用する体制やスキルがあるかを確認する必要があります。引き継ぎ先の運用能力に構成を合わせる、という視点を最初に置きます。
顧客の指定環境・既存資産への適合｜「ゼロから選べない」前提
受託案件では、クラウドをゼロから自由に選べるとは限りません。顧客がすでに AWS のアカウントを持っている、既存のオンプレミス環境と連携する必要がある、社内ポリシーで使えるクラウドが決まっている、といった制約が先にあるケースが大半です。
この場合、技術的な優劣以前に「顧客の指定環境・既存資産に適合するか」が最優先の軸になります。顧客が AWS で全社統一しているなら、GCP の方がデータ解析に強いと提案しても通りません。既存資産との連携コスト、顧客側の運用統制、契約上の制約を踏まえて、現実に選べる選択肢を見極めることが先決です。
コスト予測可能性｜従量課金が運用フェーズで膨らむリスク
受託では見積もりの段階でインフラのランニングコストを提示することが多く、そのコストが予測可能かどうかが重要になります。
ここで悩ましいのが従量課金です。Aurora Serverless v2 のように、使った分だけ自動でスケールして課金されるサービスは、アイドル時にコストを抑えられる一方、料金体系を理解せずに使い始めると想定外のコストが発生することがあります（Amazon Aurora の料金）。データベースの料金モデルも、RDS や Cloud SQL のようにサーバーが起動している時間だけ課金されるものと、DynamoDB のように容量と通信量に対して課金されるサーバーレス型のものとで、コストの読みやすさが変わります。
受託で予算が固定されている案件では、想定負荷に対してコストがどう動くかをある程度読める構成を選ぶことが、後の利益を守ります。負荷が読みにくい案件ほど、上限が見える固定費型の構成を検討する価値があります。
構築初速｜短期案件で効く「枯れた構成」
納期が短い案件では、構築にどれだけ早く着手して安定させられるか、という初速が効いてきます。
ここで重要なのが、新しいサービスより「枯れた構成」を選ぶ判断です。登場して間もないマネージドサービスは魅力的に見えますが、社内に運用知見がなく、ハマったときに参照できる情報も少ないため、短期案件では工数のリスクになります。チームが慣れていて、トラブル時の対処パターンが確立している構成を選ぶ方が、結果として早く安全に組み上がります。短期案件ほど「新しさ」より「確実さ」を優先します。
スケール要件の現実性｜想定負荷に見合わない過剰設計を避ける
最後の軸が、スケール要件の現実性です。大規模事業者の運用記事を読むと、スパイクアクセスへの対応や大規模スケールを前提にした構成が紹介されますが、受託案件の多くは小〜中規模で、想定負荷もある程度限定されています。
その案件で本当に必要な負荷を見極めず、念のためと大規模前提の冗長構成を入れると、それは過剰設計になり、構築工数とランニングコストの両方で利益を削ります。想定ユーザー数・想定アクセスを顧客とすり合わせ、それに見合った構成にとどめる。スケールが必要になったときに段階的に拡張できる余地を残しておけば十分なケースがほとんどです。
案件タイプ別 インフラ・DB選定の実例｜なぜこのクラウド・データベースを選んだか
ここからが本記事の核です。受託でよくある案件タイプごとに、一般に選ばれやすいインフラ・DB・構成と、その選定理由を見ていきます。各ケースは「案件の特徴 → 効いた判断軸 → 選ばれやすい構成 → やりがちな地雷」の順で整理します。なお、ここで挙げる構成はあくまで一般的に選ばれやすい例であり、特定の実績として断定するものではありません。実際の選定は案件ごとの要件で変わります。
社内業務システム｜運用引き継ぎとコスト予測を最優先
社内の管理画面や基幹業務を支えるシステムは、アクセスするユーザーが社内に限られ、負荷の変動も読みやすいのが特徴です。一方で、長期間使われ、納品後に顧客の情報システム部門が運用を引き継ぐケースも多くあります。
このタイプで効く判断軸は、運用引き継ぎのしやすさとコスト予測可能性です。選ばれやすいのは、コンテナまたは仮想サーバー（ECS や EC2）の上にアプリケーションを置き、データベースは RDS や Aurora のマネージドなリレーショナルデータベースを使うシンプルな構成です。トランザクションが中心の業務データはリレーショナルデータベースと相性がよく、引き継ぐ相手にとっても理解しやすい構成になります。可用性については、業務が止まると困る度合いに応じてマルチAZを検討し、要件が許せばシングル構成でコストを抑えます。
やりがちな地雷は、念のためと最初からマルチAZや高可用性構成を盛り込み、社内利用には過剰なコストをかけてしまうことです。誰がいつ使うシステムなのかを確認し、必要十分にとどめます。
一般向けWebサービス受託｜マネージドとスケールのバランスを取る
不特定多数の利用者が使う toC 向け Web サービスを受託する場合、アクセスが時間帯やキャンペーンで変動し、社内システムよりスケールへの配慮が必要になります。
このタイプでは、スケール要件の現実性と運用引き継ぎのしやすさのバランスを取ります。選ばれやすいのは、Fargate や Cloud Run のようなコンテナを動かすマネージドサービスにアプリケーションを載せ、データベースはマネージドなリレーショナルデータベースを基本に、必要に応じてキャッシュやオブジェクトストレージ（S3 等）、CDN を組み合わせる構成です。Cloud Run は未使用時にインスタンスをゼロまで縮小できるため、アクセスの少ない時間帯のコストを抑えやすいという特性があります（Cloud Run と Fargate の比較）。
やりがちな地雷は、将来の大規模化を見込んで最初からマイクロサービスや複雑なスケール構成を組み、初期の負荷に見合わない複雑さを抱え込むことです。まずは想定負荷に見合うシンプルな構成で始め、スケールの余地だけ残しておく方が、受託では現実的です。
短期PoC・MVP開発｜早く安く動かすことが目的
新規事業の検証や試作として、短期間で動くものを作る PoC・MVP 開発では、とにかく早く安く動かすことが目的になります。長期運用を前提にしないため、構築工数をいかに減らすかが勝負になります。
このタイプで効く判断軸は、構築初速とコスト予測可能性です。選ばれやすいのは、Lambda のようなサーバーレス関数と DynamoDB のようなサーバーレスデータベースを組み合わせ、サーバーの構築・管理を最小化する構成です。アクセスがないときは課金されないため、検証段階のコストも抑えられます。
ただし注意したい落とし穴があります。PoC でサーバーレス中心に作ったものを、そのまま本番サービスに育てようとすると、データモデルの制約やコスト構造が本番の要件に合わなくなることがあります。DynamoDB のようなサーバーレスデータベースは容量と通信量で課金されるため、アクセスが増えると料金体系が変わってきます。PoC は「検証して捨てる前提」か「本番に育てる前提」かを最初に握り、後者なら本番移行時の作り直しを見込んでおきます。
既存環境連携・移行案件｜指定クラウド・オンプレ・既存DBがある制約下の現実解
顧客がすでに持っているシステムを刷新する、既存のオンプレミス環境をクラウドへ移行する、といった案件では、ゼロから選べる自由がほとんどありません。
このタイプで最優先になるのは、顧客の指定環境・既存資産への適合です。顧客が使っているクラウド、連携が必要な既存システム、移行元のデータベースといった制約が先にあり、それに適合する範囲で現実解を組みます。一気に理想構成へ作り替えるのではなく、まずは既存環境をそのままクラウドに移す（リホスト）、その後で一部をマネージドサービスに置き換える、という段階的な移行が選ばれやすくなります。
やりがちな地雷は、移行案件なのに最新のベストプラクティス構成への全面刷新を提案し、移行リスクと工数を膨らませてしまうことです。既存資産を尊重し、段階的に改善する現実路線が、受託では炎上を避ける選択になります。
インフラ・DB選定でやりがちな失敗と回避の判断軸
受託のインフラ・DB選定では、繰り返し起きる失敗パターンがあります。ここでは代表的な失敗を、先ほどの判断軸に紐づけて回避策とセットで整理します。失敗を脅しで終わらせず「どの軸を見れば防げたか」に変換するのがポイントです。
過剰構成でコスト・利益を削る｜スケール要件の現実性の軸で止める
もっとも多いのが、要件に見合わない高可用性・マネージド構成を入れて、コストと利益を削ってしまう失敗です。念のためのマルチAZ、念のための冗長化、念のための大規模前提の構成が積み重なり、見積もりに対して利益がほとんど残らなくなります。
これを防ぐのが、スケール要件の現実性の軸です。提案の段階で「この案件で本当に必要な可用性・負荷はどこまでか」を顧客とすり合わせ、必要十分の線を引きます。過剰だと感じたら、その構成を入れる理由を説明できるか自問します。説明できないなら、それは過剰設計の可能性が高いと判断できます。
引き継げない構成｜IaC・運用ドキュメントを選定段階で効かせる
次に多いのが、構築した本人にしか分からない属人的な構成にしてしまい、運用を引き継げなくなる失敗です。手作業でコンソールから構築したインフラは、何がどう設定されているかが記録に残らず、引き継ぎ時に再現できません。
ここで効くのが、運用引き継ぎのしやすさの軸を選定段階から効かせることです。インフラ構成をコードで管理する仕組み（IaC）を導入し、構成の意図を運用ドキュメントに残しておけば、引き継ぐ相手が変わっても再現と理解ができます。引き継ぎを前提にするかどうかは、構成を選ぶ時点で決まります。納品時にあわてて整えるのではなく、最初から引き継げる形で作ることが回避策です。
コスト見積もりの甘さ｜コスト予測可能性の軸で従量リスクを事前に潰す
3つめが、従量課金サービスのコスト見積もりが甘く、運用フェーズでコストが想定を超える失敗です。アイドル時に安くなることだけを見て採用し、実際の負荷でコストが跳ね上がる、というパターンです。
これを防ぐのが、コスト予測可能性の軸です。従量課金サービスを使う場合は、想定負荷でのコストを事前に試算し、負荷が増えたときにどこまで膨らむかの上限を把握しておきます。コストが読みにくい案件では、上限が見える固定費型の構成を検討するのも有効です。料金体系を理解せずに使い始めると想定外のコストが発生する、という点はサービス提供側も注意を促しています（Amazon Aurora の料金）。
選定理由を提案書・構成図・見積もりに書く｜意思決定を言語化する型
ここまでの判断軸と実例を、最後に「提案書・構成図・見積もりに書ける形」に落とし込みます。選定理由を言語化できて初めて、その構成は顧客と社内に説明でき、意思決定の根拠になります。
選定理由テンプレート｜制約→軸→採用構成→コスト・リスク対策
選定理由は、次の4ステップで書くと過不足なく整理できます。
- 案件制約: この案件の納期・予算・運用主体・既存環境はどうか
- 重視した判断軸: その制約から、5つの軸のうちどれを優先したか
- 採用構成: 重視した軸に基づいて、どのクラウド・DB・構成を選んだか
- 想定コストとリスク対策: その構成のランニングコスト見込みと、想定されるリスクへの対策
たとえば「運用は顧客の情報システム部門が引き継ぐ（制約）→ 運用引き継ぎのしやすさを最優先（軸）→ マネージドなリレーショナルデータベースとコンテナのシンプル構成を採用（構成）→ 月額のランニングコストは固定費中心で予測可能、IaCで構成を残し引き継ぎリスクを抑える（コスト・リスク対策）」という流れです。この型に沿って書けば、なぜこの構成にしたのかが一読で伝わります。
顧客が非エンジニアの場合の伝え方｜技術用語をコスト・運用負荷・リスクの言葉に翻訳する
提案を受け取る顧客がエンジニアとは限りません。非エンジニアの担当者に「マネージドデータベースを使います」と言っても判断材料になりません。
このときは、技術用語をコスト・運用負荷・リスクの言葉に翻訳します。「マネージドデータベースを使う」は「バックアップや障害対応をクラウド側に任せるので、運用の手間とトラブルのリスクが下がります」と言い換えます。「シングル構成にする」は「この利用規模なら冗長化のコストをかけない方が費用対効果が高いと判断しました」と伝えます。技術的な選択を、相手が判断できる経済性とリスクの言葉に置き換えることが、提案を通す鍵になります。
なお、ここで扱ったのはインフラ・クラウド・DBの選定です。技術選定全体としては、言語・フレームワークの選定軸も合わせて検討する必要があります。その観点は受託開発の技術選定実例で詳しく解説していますので、提案書を組み立てる際は両方を参照してください。
まとめ｜受託のインフラ選定は「運用引き継ぎとコストから逆算する」
受託開発のインフラ・DB選定は、技術的な理想からではなく、受託特有の制約からの逆算で決まります。本記事の要点を振り返ります。
- 受託には「納期・予算が与件になる」「運用を誰が引き継ぐか読めない」「過剰構成が利益を削る」という、自社サービスにはない3つの制約がある
- 受託で優先度が上がる判断軸は、運用引き継ぎのしやすさ・顧客の指定環境への適合・コスト予測可能性・構築初速・スケール要件の現実性の5つ
- 案件タイプ（社内業務システム／toC Webサービス／短期PoC・MVP／既存環境連携）ごとに、効く判断軸と選ばれやすい構成は変わる
- やりがちな失敗（過剰構成・引き継ぎ不能・コスト見積もりの甘さ）は、判断軸を選定段階から効かせることで防げる
- 選定理由は「制約→軸→採用構成→コスト・リスク対策」の型で言語化し、提案書・構成図・見積もりの根拠にする
とくに受託で効いてくるのは、運用引き継ぎとコスト予測可能性の2軸です。この2つを最初に押さえれば、後から運用が破綻したりコストが膨らんだりする地雷の多くを避けられます。次の案件でインフラ構成を提案するときは、まず「誰が運用するのか」「コストは読めるのか」を確認することから始めてみてください。技術選定全体としては、言語・フレームワークの軸と合わせて検討することで、説得力のある提案に仕上がります。
