AWS構築代行の依頼範囲と費用｜内製との比較とベンダー選定の判断軸

AWS構築代行の見積りが会社によって10倍近く開くのは、各社が「構築」と呼ぶ作業範囲がそろっていないからです。設計と環境構築だけを指す会社もあれば、要件定義から移行・運用監視までを一括で含める会社もあります。この記事では依頼できる作業を四工程に分け、請負と準委任で納品物の責任がどう動くか、見積書のどこを内訳として割らせるか、AWSのサービスパートナーティアをどう読むかを発注者の視点で整理しました。アカウントの名義という、契約時にしか決められない論点も扱います。

まとめ：AWS構築代行に出す範囲と自社に残す責任の切り分け

AWS構築代行で炎上が起きる原因は、技術力の差より先に、作業範囲と成果物の定義があいまいなまま発注している点にあります。最初に決めるのは、設計・構築・移行・運用の四工程のうちどこまでを外に出すか。次がAWSアカウントの名義とIaCコードの引き渡し条件で、この二つは契約書に書かなければ後から取り返せません。

費用は代行会社への委託費とAWSに払う利用料の二本立てです。比較メディアの相場帯ではスポット構築が20万〜50万円、構築と移行支援で50万〜200万円。相見積りでは合計金額ではなく、人日単価と工数、運用保守の対応時間帯を並べて比べてください。

ベンダー選定はAWSサービスパートナーティア（セレクト・アドバンスト・プレミアの3段階）を足切りに使います。ティアは認定保有者数とローンチ実績数で決まる数値要件のため、営業資料の実績数より客観的です。ただし小規模構成・要件が固まらない段階・運用を引き取る担当者の不在という三条件のどれかに当てはまるなら、発注しても投資は回収できません。

AWS構築代行サービスの依頼範囲と請負・準委任で変わる納品成果物

「AWS構築代行」に業界共通の定義はなく、同じ名前でも含まれる作業は会社ごとに違います。AWSの仕組みや料金モデルを前提から確認したい場合は、クラウドとは何か・AWSとは何かの解説を先に読むと判断がしやすくなります。

AWS構築代行に含まれる作業範囲＝設計・構築・移行・運用の四工程

依頼できる作業は四つの工程に分かれます。設計はネットワーク構成・可用性要件・セキュリティ要件からAWS上の構成図を起こす工程。構築はVPC・サブネット・EC2やコンテナ基盤・データベース・IAMの権限設計を実際に作る工程です。移行はオンプレミスや他社クラウドから既存システムとデータを持ち込む工程、運用保守は監視・バックアップ・障害一次対応・セキュリティ更新を継続する工程を指します。

見積書に必ず含まれるのは設計と構築の二つ。移行は対象システムの数と種類で金額が跳ねるため別見積りになることが多く、運用保守は月額の別契約に切り出されます。三つの契約が並走するため、どの工程の話をしているのかを毎回そろえてから金額を比較してください。構築まで内製する場合の作業順序は、VPC・EC2・IAMの初期設計をまとめたAWS環境構築の手順で確認できます。

請負契約と準委任契約の違いと、代行に出せない自社側の作業の範囲

請負契約は仕事の完成を目的とし、受託側が完成した成果物を引き渡す義務を負います。準委任契約が目的とするのは業務の遂行で、受託側が負うのは善管注意義務。成果の完成そのものは約束しません。IPAが2020年12月22日に公開した「情報システム・モデル取引・契約書（第二版）」も、請負契約と準委任契約における報酬請求権や中途解除時の報酬の扱いを論点として整理しています。完成の定義が書ける構築工程は請負、要件が動くコンサルティングや継続的な運用保守は準委任で結ぶのが実務上の使い分けです。

一方、代行会社が引き受けられない領域もあります。アプリケーションの業務要件、移行するデータの選別と名寄せ、利用部門側の運用ルールの三つ。特にデータは、代行会社が「移す仕組み」を作れても「何を移すか」は決められません。ここを曖昧にしたまま着手すると、移行当日に判断待ちが発生して切り替えが延びます。

AWS構築代行の費用相場と、見積書で必ず内訳を割らせる三つの費目

AWS構築代行の費用は、代行会社に払う委託費とAWSに払うクラウド利用料の二本立てです。この二つを混ぜた「月額◯万円」という提示を受けたら、必ず分けさせてください。

初期構築費用の目安と、人日単価と工数で金額が決まる見積りの構造

初期構築費は人日単価と工数の掛け算で決まります。比較メディアが2026年8月時点で公開している相場帯では、スポットの小規模構築が20万〜50万円、構築と移行支援を合わせた案件が50万〜200万円、要件定義から運用設計までを含む包括的な導入支援が200万円以上。技術系メディアの提示では、構築・ソフトウェアの導入・動作確認まで含めて4〜10人日規模なら30万〜70万円、単一のWebサーバーとデータベースだけの構成なら15万〜30万円という水準も出ています。

表の相場帯は比較メディアの公開値で、AWS公式の価格ではありません。金額が跳ねる要因は三つ。使うAWSサービスの数、可用性要件（マルチAZ構成や自動復旧の有無）、セキュリティ要件（監査ログ保管・暗号化・閉域接続）です。見積りが高いと感じたら、どれが効いているかを聞けば削れる要件かを判断できます。

月額の運用保守費・AWS利用料・請求代行を分けて比較する費用の見方

運用保守の月額は対応時間帯で桁が変わります。平日日中のみの監視と一次対応なら月数万円に収まる一方、24時間365日の有人監視と障害時の駆けつけまで含めると月20万〜50万円の水準。提示レンジが月5,000円から50万円まで広いのは、この差がそのまま出ているからです。もう一方のAWS利用料は代行会社の技量ではなく構成と稼働時間で決まるため、見積り段階で自社でも試算しておくと過大な提案を見抜けます。試算の手順はAWSの見積もりと料金計算ツールの使い方をまとめた解説にまとめました。

三つ目の費目が請求代行です。AWSのソリューションプロバイダープログラムに基づきパートナーが請求を直接管理する仕組みで、発注者は日本円建ての請求書払いに対応できます。比較メディアの公開値では手数料がAWS利用料の3〜10%程度ですが、AWS公式ページに料率の記載はなく個別交渉。契約前に「解約時にアカウントと請求をどう自社へ戻すか」を書面で確認してください。

AWS構築を内製する場合と外部に委託する場合の損益分岐の見極め

外注か内製かは金額だけでは決まりません。判断材料は、必要な技術の厚み、案件の継続性、運用フェーズを誰が担うかの三つです。

内製に必要な人員と資格の水準｜AWS認定の4区分が示す技術の厚み

AWS認定はファウンデーショナル・アソシエイト・プロフェッショナル・スペシャルティの4区分で構成されます。本番環境の設計を任せられる水準はプロフェッショナル相当。ネットワークやセキュリティの個別領域まで踏み込むなら、スペシャルティ資格の保有者が必要になります。

見落とされがちなのが人数です。一人だけがAWSを分かっている状態は、その一人が離職した瞬間に運用が止まります。内製に踏み切るなら、設計できる人と手を動かせる人を最低2名ずつ、計4名規模で確保できるかが目安。この人数を採用・育成で埋められないなら、構築工程は外に出したほうが早く安く済みます。

委託費と人件費の損益分岐点｜構築だけ外注し運用は内製へ戻す設計

損益分岐は、委託費の総額とインフラ担当者の人件費を並べれば概算できます。運用保守を月20万円で委託した場合の年額は240万円。同等の対応を内製でまかなうにはAWSの実務経験者を最低1名は専任で置く必要があり、人件費は年額でそれを上回るのが通例です。案件が単発なら委託、複数システムを継続して抱えるなら内製に寄せる、というのが基本線になります。

実務でよく取る折衷案は、初回の構築だけを代行に出し、運用保守は自社に戻す形です。一括委託の代償は社内に知見が残らないことで、障害の原因を自分で追えず構成変更のたびに発注が発生します。構築フェーズへの自社エンジニアの同席、設計判断の理由の文書化、引き渡し後のハンズオン説明会。この三点は相見積りの段階で条件に入れてください。

AWS構築代行のベンダー選定基準｜パートナーティアと実績の読み方

選定で最初に使う足切りは、AWSパートナー認定です。認定は自己申告ではなくAWS側が要件を審査して付与するため、営業資料に並ぶ実績数より客観性があります。

AWSサービスパートナーティア三段階と認定数・実績数の実際の要件

AWS公式のサービスパートナーティアは、セレクト・アドバンスト・プレミアの3段階です。要件は数値で公開されています。セレクトは技術系認定2名・ビジネス系認定2名に加えてローンチ実績3件（合計月次経常収益1,500ドル以上）。アドバンストは技術系認定4名・テクニカル認定6名（うち3名以上が専門資格）とローンチ実績20件（同10,000ドル以上）。プレミアは技術系認定10名・テクニカル認定25名（うち10名以上が専門資格）とローンチ実績50件（同50,000ドル以上）が求められます。

この数値が示すのは、ティアが「AWS案件をどれだけ量として回してきたか」の指標だという点です。プレミアなら安心、という話ではありません。ティアと別に専門領域を示す認定もあり、運用まで任せたいならMSPプログラム、既存構成の見直しならWell-Architectedパートナープログラム、特定サービス中心の案件ならサービスデリバリープログラムの指定を見ます。ティアは足切りに使い、決め手には専門領域の一致を使ってください。

相見積りで比較すべき項目｜構成図・監視要件・障害時の一次対応窓口

相見積りは3社が実務上の上限です。それ以上増やすと比較の粒度が落ち、社内の意思決定が遅れます。比較する項目は次の通り。

• 提案構成図の粒度（サービス名だけか、サブネット構成・冗長化方式まで書かれているか）
• 人日単価と想定工数の内訳（合計額だけの提示は比較不能）
• 監視の対象項目と通知経路（何を検知して誰に飛ぶか）
• 障害時の一次対応窓口と対応時間帯、応答時間の目安
• 納品物の一覧（構成図・IaCコード・パラメータシート・運用手順書）
• AWS利用料の支払い経路（直接契約か請求代行か）

金額差の説明がつかないときは、たいてい監視要件と納品物の定義がずれています。安い見積りは監視が死活監視のみ、納品物が「動く環境」だけということが少なくありません。当社でもAWS・Google Cloud・Azureのインフラ構築を請け負っており、初回のヒアリングでこの6項目を先に埋めてから金額を出しています。

AWS構築代行の進め方と、発注前に自社側で決めておく要件の粒度

発注してから決めればよいと考えると工程が止まります。代行会社が着手できる状態を作るのは発注者側の仕事です。

発注前に自社側で固める三点｜対象システム・非機能要件・移行期限

相談前に固めておく情報は三つです。第一に対象システムの範囲で、どのアプリケーションをどのサーバーからどこまで移すのかをリストにします。第二に非機能要件。許容できる停止時間、データ保持期間、想定同時接続数、監査ログの保管年数といった数値です。第三が移行期限とその理由で、ハードウェアの保守切れなのか既存契約の更新日なのかによって選べる移行方式が変わります。

三点が埋まらないまま相談すると、代行会社は前提を広く取った安全側の見積りを出し、金額が膨らんで比較もできません。固まっていれば、同じ前提で複数社の見積りを並べられます。

相談から本番切り替えまでの工程と、各工程で発注者側が決める事項

典型的な進行は次の順序になります。

1. ヒアリングと現状調査（既存構成図とサーバー一覧を提供）
2. 要件定義と構成提案（非機能要件と予算上限を確定）
3. 見積り提示と契約（契約類型・納品物・アカウント名義を確定）
4. 環境構築とIaC実装（権限設計とネットワーク接続先を承認）
5. 移行リハーサルと検証（業務観点の受け入れテストを実施）
6. 本番切り替えと引き渡し（切り替え日と切り戻し条件を決定）
7. 運用保守の開始（障害時の社内連絡経路を整備）

括弧内が発注者側の宿題です。特に第5の受け入れテストは代行会社が肩代わりできません。業務が回るかを判定できるのは利用部門だけだからです。移行方式の選び方や切り替え手順そのものはクラウド移行の進め方をまとめた解説で確認できます。なおオンプレミスからの大規模移行なら、AWSのMigration Acceleration Program（評価・モビライズ・移行とモダナイズの3フェーズ）の対象になり得るかを相談時に確認してください。初期コストを相殺する支援が使えます。移行方式そのものの割り当てとAWS純正ツールの使い分けは、AWS移行の7R戦略と移行ツールの選び方で扱っています。

構築代行で見落とされるAWSアカウント所有権とIaCコードの引き渡し

次の三つは契約時にしか決められず、後から交渉しても取り返せない論点です。

AWSアカウントを誰の名義で作るかで決まる移管性と交渉力の差異

AWSアカウントを代行会社の名義で開設し、その配下に自社の環境を作る形態があります。請求代行とセットで提案されることが多く、導入時の事務負担は確かに軽くなる。ただしこの構成では、自社の環境が代行会社の管理下に置かれます。

問題が出るのは委託先を変えるときです。アカウント名義が代行会社のままだと環境の移管には相手方の協力が要り、移管作業自体が有償になることもあります。値上げ交渉を受けたときに乗り換えの選択肢が実質的に消えるため、交渉力は落ちる。推奨は自社名義での開設です。ルートアカウントの認証情報とメールアドレスは自社が保持し、代行会社にはIAMロールで必要な権限だけを渡します。請求代行を使う場合でも、アカウントの所有と請求経路は別の話として整理できます。

IaCコード・構成図・パラメータシートを納品物に明記させる契約

構築代行の成果物を「動くAWS環境」だけで定義すると、環境の作り方が代行会社の中に閉じます。再現も監査も自社ではできません。契約書の納品物一覧に、次のものを明記させてください。

• IaCコード一式（AWS CloudFormationテンプレートまたはTerraform構成ファイル）
• ネットワークとサービス構成を示した構成図（論理構成・物理構成の両方）
• パラメータシート（インスタンスタイプ・容量・保持期間などの設定値一覧）
• IAMの権限設計書（誰がどのロールで何をできるか）
• 運用手順書（バックアップ・復旧・監視項目・エスカレーション経路）

IaCコードは著作権の帰属も併せて決めます。納品はするが著作権は受託側に残す、という条件だと他社に引き継いで改変することができません。構築費を払う以上、成果物の利用範囲を自社に制限なく帰属させる条項を入れるのが筋です。

責任共有モデルで代行後も発注者側に残る権限管理とデータの責任

AWSの責任共有モデルでは、AWSが「クラウドのセキュリティ」を管理し、顧客が「クラウド内のセキュリティ」に責任を負います。AWS公式ドキュメントは、顧客が自身のコンテンツ・プラットフォーム・アプリケーション・システム・ネットワークを保護するために実装する統制について、オンサイトのデータセンターの場合とまったく同じように顧客が維持すると明記しています。

押さえるべきは、構築を委託してもこの顧客側の責任は移らないという点です。移るのは作業であって責任ではありません。IAMユーザーの棚卸し、退職者のアクセスキー失効、S3バケットの公開設定の点検、保存データの暗号化方針。これらは発注者側で誰が見るかを決めておきます。運用保守契約に「セキュリティ監視」とあっても中身は死活監視とパッチ適用までのことが多く、権限の棚卸しまでは含まれません。移行に伴うリスク全般はクラウド移行の課題と失敗パターンで整理しています。

AWS構築代行を見送るべき条件と、依頼しても失敗する三つの発注状況

AWS構築代行は、すべての企業に有効な手段ではありません。

代行を見送るべき三条件｜小規模構成・要件流動・社内に運用者不在

第一に、単一のEC2インスタンスとマネージドデータベースだけで足りる構成なら、代行は過剰です。この規模なら公式ドキュメントとハンズオン教材で数日あれば立ち上がり、20万〜50万円の構築費を払う理由がありません。委託するなら初期設計のレビューだけをスポットで買うほうが費用対効果は高くなります。

第二に、アプリケーションの要件がまだ固まっていない段階では発注しないでください。インフラ構成はアプリの要件から逆算して決まります。要件が動けば構成も作り直しになり、請負なら追加費用、準委任なら工数がそのまま積み上がる。第三に、社内に運用を引き取る担当者が一人もいない状態での構築のみ発注は、構築完了と同時に塩漬けになります。この三条件のいずれかに当てはまるなら、今は発注のタイミングではありません。

依頼しても失敗する発注状況と、委託と内製を見直す再検討のトリガー

条件を満たしていても失敗する発注の形があります。ひとつ目は金額だけで選んだ場合。監視要件と納品物の定義を落として安く見せた見積りは、運用開始後の追加請求で逆転します。ふたつ目は社内の意思決定者が構築工程に一度も出てこない場合で、承認待ちで工程が止まり待機コストが上乗せされます。三つ目が、既存システムの資料が残っていない状態での移行依頼です。構成図もパラメータも失われた環境は現状調査だけで工数が倍増するため、作り直す前提で組み直したほうが調査費を設計に回せます。

一度決めた委託・内製の線引きも固定するものではありません。運用保守の月額が社内エンジニア1名の人件費に近づいたとき、AWS上のシステムが3つ以上に増えたとき、契約更新が近づいたとき。この三つが見直しのタイミングです。切り替えられるかどうかは、自社名義のアカウントとIaCコードが手元にあるかで決まります。

よくある質問

AWS構築代行の検討で実際に多く寄せられる質問を、発注実務の観点でまとめました。

AWS構築代行の費用はどれくらいかかりますか？

比較メディアが2026年8月時点で公開している相場帯では、スポットの小規模構築が20万〜50万円、構築と移行支援を合わせた案件が50万〜200万円、包括的な導入支援が200万円以上です。単一のWebサーバーとデータベースだけの構成なら15万〜30万円という水準も示されています。これとは別にAWS利用料が毎月かかり、運用保守は対応時間帯に応じて月5,000円から50万円の幅で発生。金額を比較するときは、人日単価と想定工数の内訳を出させてください。

AWS構築代行とAWS導入支援は何が違いますか？

明確な業界定義はなく、会社によって使い分けが異なります。傾向としては、構築代行が設計と環境構築の実作業を指し、導入支援はその手前の要件整理・構成方針の策定といったコンサルティング寄りの工程まで含む呼び方です。ただし逆の使い方をする会社もあるため、名称ではなく提案書の作業一覧で判断してください。設計・構築・移行・運用の四工程のうちどこが含まれるかを確認すれば、名称の違いに惑わされずに比較できます。

構築を頼んだあと、運用も同じ会社に任せるべきですか？

構築を担当した会社は設計判断の経緯を把握しているため、運用の立ち上がりは速くなります。一方で一括委託は社内に知見が残らず、構成変更のたびに費用が発生する構造を固定します。システムが1つで専任者を置けないなら運用も委託、複数システムを継続して抱えるなら構築だけ委託して運用は社内に戻す設計が現実的です。いずれの場合も、IaCコードと運用手順書の納品を条件に入れておいてください。

AWSアカウントは代行会社と自社のどちらで作るべきですか？

自社名義での開設を推奨します。代行会社名義のアカウント配下に環境を作る形態は導入時の事務負担が軽い反面、委託先を変更するときに環境の移管が相手方の協力なしには進まず、移管作業が有償になることもあります。自社でアカウントを開設し、ルートアカウントの認証情報とメールアドレスは自社が保持したうえで、代行会社にはIAMロールで必要な権限だけを付与してください。

AWSパートナー認定がない会社に依頼しても問題ありませんか？

認定がなくても技術力の高い会社は存在しますが、外部から検証できる材料が減ります。AWSのサービスパートナーティアは認定資格の保有者数とローンチ実績数という数値要件をAWS側が審査して付与するもので、セレクトは技術系認定2名と実績3件、プレミアは技術系認定10名と実績50件が要件です。営業資料の実績数より客観性があるため、初めて依頼する会社の足切りとして使えます。ティアが同じ会社が並んだら、コンピテンシー認定やMSP認定の領域が自社の要件と重なるかで絞ってください。

関連記事

• クラウドとは？AWSとは何か：仕組みと料金モデルという発注前の前提整理
• AWS環境構築の手順：内製する場合のVPC・EC2・IAMの初期設計
• AWSの見積もりと料金計算ツールの使い方：AWS利用料そのものの試算方法
• クラウド移行の進め方：計画から移行方式・切り替えまでの工程の全体像
• クラウド移行の課題と失敗パターン：移行前に潰しておくリスクと見送り判断