クラウドインフラ構築委託— AWS/GCPの発注

1. 構築委託のスコープと契約形態

1-1. 設計・構築・移行の範囲

アーキテクチャ設計・環境構築・データ移行・負荷試験のうち、今回の発注に含む工程を別紙に列挙します。
PoC 環境と本番環境を同一契約に含めるか、契約分割するかを発注前に決めます。

1-2. 請負と役務の整理

完成引渡し型の固定報酬か、工数ベースの準委任かで、検収・変更管理の設計が変わります。
適用判定と書面は発注コンプライアンスのチェックリストと発注書面の3条書面で整えます。

1-3. クラウド利用料の扱い

AWS 等の従量課金は構築報酬とは別勘定です。発注者名義のアカウントで契約し、請求は直接または立替精算で処理します。
構築中の検証環境コストの上限も事前に合意します。

2. 段階検収とマイルストーン

2-1. 設計レビュー・構築・本番移行

設計書承認・ステージング構築完了・本番切替・移行完了など、マイルストーンごとに検収・支払を分けます。
各段階の完了定義（Terraform apply 成功、ヘルスチェック通過等）をチェックリストにします。

2-2. 受領日の記録

設計書承認日・環境引き渡し日・本番 Go-Live 日のどれを受領日とするか段階ごとに決め、台帳に記録します。
60 日起算は支払60日ルールの起算点を参照します。

2-3. 検収基準

可用性・バックアップ・監視・アラート・セキュリティグループ等を検収項目に含めます。
検収基準の決め方に沿って、客観的に判定できる条件にします。

3. IaC・ドキュメント・権限移譲

3-1. Terraform 等の納品物

IaC リポジトリ・状態ファイルの保管場所・実行手順書を引き渡し物一覧に含めます。
ソースの著作権・利用許諾も契約に明記します。

3-2. AWS/GCP アカウント権限

構築作業用の IAM ロールは最小権限とし、完了時に不要な権限を削除します。
ルートアカウント・請求管理者は発注者が保持し、受託者に長期共有しない方針を契約に書きます。
構築完了チェックリストに「外部 IAM ユーザー削除済み」を項目として含めると、引き渡し漏れを防げます。

3-3. 運用引き継ぎ

構築完了後の監視・障害対応は、別契約の SLA 付き保守として切り出すのが一般的です。
引き継ぎ研修・runbook 納品を構築契約に含めるかも明記します。

4. 仕様変更・追加リソース・セキュリティ

4-1. アーキテクチャ変更

構築途中の可用性要件変更・リージョン追加等は、追加発注として見積もり・承認を取ります。
口頭依頼後は変更依頼書で追認し、台帳に紐づけます。

4-2. コスト超過の管理

構築中のクラウド費用が見積もりを超えそうな場合、事前アラートと承認フローを決めます。
従量課金の超過は構築報酬とは別問題として、誰が負担するか合意します。

4-3. 再委託と孫請け

受託者が別 SIer やフリーランスに再委託する場合、契約で可否・届出・責任分界を定めます。
クラウドパートナープログラム経由の支援も、発注者への開示範囲を確認します。

5. 実務シナリオとチェックリスト

5-1. 本番移行直前に DB スペック変更

例えば移行1週間前に、RDS インスタンスサイズの変更が必要になったとします。
追加コストと作業工数を変更依頼書で合意し、Go-Live 日程への影響を台帳メモに残します。
承認なしに変更した場合、検収・費用負担で争点になります。
変更後の負荷試験結果を検収資料に添付し、性能要件を満たした時点を段階受領日とするかも合意します。

5-2. マルチクラウド構成

AWS と GCP を組み合わせる場合、環境ごとに発注書面・台帳を分けるか、1契約の別紙で定義するかを決めます。
受領日も環境ごとに記録し、支払期日を個別に計算します。
クロスクラウドのネットワーク接続や ID 連携は、どちらのマイルストーンに含むかを設計書承認段階で確定します。

5-3. 発注前チェック（クラウド構築向け）

工程範囲・マイルストーン・IaC 納品・権限移譲・クラウド費用負担・保守切り出し・再委託を書面に含めるか確認します。
段階ごとの受領日記録担当を決め、記載事項のテンプレートに沿って記載漏れがないか見直します。

よくある質問

Q. クラウド利用料は構築費に含められますか

含める設計も可能ですが、従量課金の変動リスクを誰が負うか契約に明記します。
多くの場合、利用料は別勘定とする方が管理しやすいです。

Q. ステージングだけ先に検収できますか

マイルストーンを分けていれば可能です。本番移行を別段階の検収とし、受領日を分けて記録します。

Q. 受託者のアカウントで構築した場合

移行・権限移譲・解約時のデータ持ち出しでリスクが生じます。発注者名義アカウントでの構築を推奨します。

Q. PoC と本番は契約を分けますか

スコープと報酬が異なるため、分けると検収・変更管理がしやすいです。PoC 成果の本番流用条件も書面に残します。

Q. 構築後の運用は同じベンダーに任せますか

可能ですが、SLA・月次報酬・解除条件は保守契約として別途整えます。構築契約に無償運用期間を含める場合は期間と範囲を明記します。
構築時に作成した IaC と runbook が、そのまま保守契約の引き継ぎ資料になるよう命名規則を揃えておきます。

まとめ

• 構築工程・IaC 納品・権限移譲を書面で固定し、クラウド利用料は報酬と分ける
• マイルストーンごとに検収・受領日を記録し、60日起算で支払期日を管理する
• アーキテクチャ変更・コスト超過は追加合意と台帳記録で対応する
• 構築後の運用保守は SLA 付き別契約として切り出す

6. クラウドインフラ構築の発注前チェックリスト

• 設計・構築・移行の工程範囲とマイルストーンを書面に書いたか
• クラウド利用料の負担主体と上限アラートを決めたか
• IaC・runbook・権限移譲手順を引き渡し物に含めたか
• 発注者名義アカウントでの構築を合意したか
• 再委託・変更管理のフローを契約に含めたか
• 構築後保守を別契約に切り出すか決めたか

本番移行直前の変更は争点になりやすいです。着手前に変更依頼書で合意してください。
受託者アカウント構築は移行リスクが高いため、可能な限り発注者名義で進めます。
Terraform リポジトリの引き渡し日を台帳の受領日とし、runbook 納品とセットで検収メモに記録します。
構築完了後1ヶ月以内に不要 IAM が残っていないか、セキュリティ観点でも再確認してください。

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
個別の契約内容・取引実態については専門家にご確認ください。