Alibaba Cloudのシステム開発は、発注形態を選び、業務要件とRFPを整えたうえで、委託先と契約を決める流れで進めます。
契約と見積を比べてPoCへ進むと、予算超過や稼働後のトラブルを抑えやすくなります。
▼全体ガイドの記事
・Alibaba Cloudのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Alibaba Cloudのシステムを発注する前に知るべき全体像
Alibaba Cloudのシステムは、業務アプリケーションとクラウドサービスを組み合わせて作るため、クラウド事業者に任せれば完成するものではありません。発注側は、対象業務、利用地域、可用性、安全性を決めておきます。
Alibaba Cloudのシステムの構成要素
Alibaba Cloudのシステムは、業務アプリやDB、ネットワーク、認証、監視、バックアップを組み合わせて作ります。組み合わせ方は導入目的と要件で変わるため、発注前に次の4点を整理しておきます。
- 構成要素：業務アプリ、DB、ネットワーク、認証、監視、バックアップ
- 処理と保存：アクセスを振り分け、アプリで処理してDB・ストレージに保存
- 導入目的：中国・東南アジア展開、海外連携、高負荷対策、データ分析など
- 要件：ユーザー・同時接続数、データ量、停止許容時間、バックアップ保持期間、障害時の復旧目標
具体的には、CDNとWAFでアクセスを受けたあと、SLBで振り分けます。そのうえで、ECS、ACK、Function Computeでアプリを動かします。データはRDSやApsaraDBに保存し、ファイルやバックアップはOSSに保管します。
「Alibaba Cloudで作る」と伝えても、機能や運用範囲は決まりません。そのため、要件を数値にして渡すと、委託先の提案を比べやすくなります。
Alibaba Cloudのシステム開発を外注する理由
社内だけでは専門人材をそろえにくいため、外注で補うことになります。その理由は、次の2点です。
- クラウド知識：Alibaba Cloudのサービスとリージョンごとの違い
- 運用経験：日中間ネットワーク、移行、監視、障害対応
特に、中国本土を含む構成では、通信品質とデータの保管場所が設計に影響します。これらは後から変更すると、作り直しが発生する場合があります。
外注した後も、発注側の責任は残ります。ECSの共有責任モデルでは、基盤側の安全性をAlibaba Cloudが担います（出典: Alibaba Cloud「ECS shared security responsibility model」、2026年5月更新）。
一方で、OS更新、セキュリティグループ、アプリは利用者側の責任です。権限やデータ暗号化なども、利用者側で受け持ちます。
そのうえで、どこまでを委託先が受け持ち、どこからを社内が受け持つかを決めます。社内の承認者と運用担当も、あらかじめ決めておきます。
Alibaba Cloudのシステム開発の発注形態の選び方
発注形態は、業務の標準化と独自性、納期、将来の保守体制をもとに選びます。標準的な業務ならSaaSやパッケージ、独自の業務なら個別開発、既存環境がある場合は移行や連携が候補になります。
SaaS・パッケージを組み合わせて発注する方法
会計や販売管理、顧客管理などは、標準化しやすい業務です。そのため、SaaSやパッケージを使い、Alibaba Cloudをデータ連携や独自画面の基盤にできます。
- 連携仕様：API、データ出力、認証連携の可否
- 利用条件：利用リージョンとサービス終了時のデータ返却
- 運用分担：SaaS事業者・構築会社・自社の障害窓口と復旧・顧客説明の担当
初期開発を抑えやすく、導入期間も短くなりやすい一方で、業務をパッケージの仕様に合わせる必要があります。この形態が合うのは、業務を大きく変えずに短期間で使いたい企業です。
また、障害が起きた場合に備えて、誰がログを確認し、復旧を判断し、利用者へ説明するかを契約書に書いておきます。
Alibaba Cloud上で個別開発する方法
独自の業務は、Alibaba Cloud上に個別開発します。その際、業務に合う機能と運用要件を見積もります。
- 対象業務：受注、在庫、会員、決済、審査、承認
- 構成候補：ECS・RDS、ACKのコンテナ運用、Function Computeのイベント処理
- 構成の選定軸：性能、可用性、運用者スキル、将来の移行可能性
- 必要な実装：認証、監査ログ、バックアップ、監視、権限、障害復旧
機能一覧に加えて、非機能要件と納品ドキュメントも見積もりの対象にします。
ソースコードとInfrastructure as Code、アカウントの所有者を明記します。また、設計書の所有者と、終了時の引き渡し形式も書いておきます。
移行・連携を中心に発注する方法
移行元は、オンプレミスのほか、AWS、Azure、国産クラウドの場合があります。移行では、移行計画と業務連携を分けて整理します。
- 事前調査：データ形式・文字コード、個人情報の有無、データ量、停止可能時間、切り戻し方法
- 段階移行：既存環境を残す場合、VPN・専用線、API、バッチの実行順を設計し、テストを複数回実施
- RFP記載：テーブル数、ファイル容量、データ整備担当、リハーサル回数、停止上限、移行後の照合方法
- 責任分担：既存ベンダーとの窓口と調整範囲を決める
構築費に、整合性の確認や当日の立会い、切り戻しが含まれない場合があります。そのため、見積もりの範囲も確かめておきます。
発注前の要件整理とRFPの準備範囲
RFPは、仕様書に加えて、背景や目的、制約を伝える文書です。期待する成果と提案範囲も、ここに書きます。
細部まで決め切れなくても、比較に必要な条件はそろえておきます。特に、Alibaba Cloudでは、リージョンとデータの扱いが構成や費用に影響します。そのため、条件が曖昧なまま見積だけを依頼しないよう注意します。
業務要件と利用者像の整理
業務要件では、利用者と業務の流れ、海外展開の条件、データの準備状況を押さえます。
- 業務フロー：部署、権限、承認経路、入力・検索、帳票、外部連携、例外処理
- 例外条件：重複データ、承認者不在、通信断の洗い出し（追加費用を抑えるため）
- 海外利用：言語、時差、通貨、税、決済、商習慣、拠点間のマスタ・権限共有
- AI・分析：マスタ品質とデータ更新責任を確かめてから、機能を発注
数値で示す非機能要件
非機能要件とリージョンは、測定できる条件にしたうえで、提案依頼に含めます。
- 性能・可用性：処理速度、同時接続数、稼働時間、応答時間、月間稼働率
- 復旧・保全：復旧時間（RTO）、許容データ損失（RPO）、バックアップ頻度、ログ保存期間、セキュリティ基準
- 未確定の数値：現状値を測り、PoCで確定する工程をRFPに入れる
- リージョン：利用者との距離、ネットワーク、データ保管場所、提供サービス、料金で比較
公式ガイドでは、東京リージョンに5つのゾーンがあります。さらに、リージョンは作成時に選び、後から変更できません（出典: Alibaba Cloud「Regions and zones」、2026年7月更新）。
本番前には、RDSとSLBが選んだリージョンで提供されるかを確認します。WAFとACKについても、同じ条件で確かめます。
提案と見積を比べるためのRFP
必須機能と、できれば欲しい機能、対象外の機能を分けて示し、提案書に求める情報も指定します。
- 技術提案：構成図、採用サービスの理由、リージョン選定の根拠
- 実行計画：移行方式、テスト計画、運用体制、障害対応、開発日程
- 見積条件：前提、除外事項、費用内訳、有効期限
候補の会社には、同じ資料と前提をそろえて渡します。前提が違うと、安く見える見積が、機能や運用を含んでいないことがあります。
クラウド利用料と開発費、移行費を分けてもらうと、自由提案を残しながら比べられます。保守費と追加変更の単価も、あわせて示してもらいます。
Alibaba Cloudの外注契約（準委任と請負）の使い分け
契約形態は、作るものと仕様が固まっているか、発注後に要件を詰めるかで選びます。安全性を決めるのは、契約名よりも中身です。
そのため、作業範囲と納品物、検収条件を、契約書で具体化します。変更手続きや、委託先が受け持つ範囲も、契約書に書いておきます。
知的財産と再委託は、契約書で決めておきます。秘密保持や終了時の引き継ぎも、同じ契約書に含めます。法務や税務の判断は、自社の専門家に確認します。
準委任契約が向くケース
準委任は、専門家と相談しながら決める段階に適しています。作業条件と成果確認の方法も、事前に合意しておきます。
- 対象業務：要件定義、構成検討、PoC、移行計画、運用支援
- 契約条件：作業期間、体制、稼働時間、報告内容
- 成果確認：月次報告、設計レビュー、課題一覧、意思決定記録、翌月計画
- 段階移行：要件定義後に請負または別契約へ移る形も有効
請負契約が向くケース
請負は、完成範囲と受け入れ条件が明確な開発に適しています。変更が出たときの合意手順も、あらかじめ定めておきます。
- 成果物：画面、API、DB、インフラ設定、テスト仕様書、操作マニュアル
- 検収条件：検収日、不具合修正、監視や運用手順の納品有無
- 前提変更：仕様・リージョン、外部仕様、移行量、性能要件の変更を管理
見積の前提が変わる場合は、変更要求書で費用と納期を合意します。検収の条件が曖昧だと交渉が長引くため、受入テストの観点を共有します。
保守・運用契約で決める事項
保守・運用契約では、稼働後の対応範囲とアカウント管理、契約終了時の処理を決めておきます。
- 運用範囲：監視、受付、一次切り分け、重大度、連絡、復旧目標、報告、脆弱性、パッチ、バックアップ、費用上限
- 24時間監視：監視だけか、アラート後の復旧まで行うかを明記
- アカウント：発注側が契約主体・管理者となり、RAMで必要最小限の権限を付与
- 終了時：退職者・再委託先の権限停止、ログ・設定・データの返却・消去
終了時の扱いは、運用手順と契約書の両方に残しておきます。
Alibaba Cloudのシステム開発費用と月額相場の目安
費用は、クラウド利用料と、企画・設計・開発・移行・保守の委託費に分けて考えます。利用料は、ECS、RDS、ディスク、帯域で変わります。
さらに、SLBやWAF、OSSの構成も利用料に影響します。バックアップや監視、ログ、通信、冗長化の範囲によっても、金額は変わります。
以下は、企画段階の目安です。ただし、リージョンや為替、割引で変わります。利用量、契約期間、運用範囲でも変動します。
クラウド利用料の相場
規模別の月額利用料は、構成と運用条件を含めて、次の幅が初期検討の目安です。
- 小規模な検証・社内ポータル：1万〜10万円程度
- 中小規模の業務Web：10万〜50万円程度
- 日中をまたぐEC・会員・受発注：50万〜300万円程度
- 大規模な基幹・分析・AI基盤：300万円〜数千万円となる可能性
小規模構成は、ECSとRDS、OSSを想定します。最低限のバックアップも、含めて考えます。一方で、中小規模では、冗長化やWAF、監視を含みます。ステージングやバックアップも、構成に入ります。
日中をまたぐ構成では、通信や複数リージョンを含めます。データ連携や負荷変動も、想定に入れます。いずれも、個別見積の前の推定です。
公式のECS第8世代のページでは、2 vCPU・8GBのg8iは月額72.32米ドルから、g8aは61.28米ドルからと表示されています（出典: Alibaba Cloud「8th-generation ECS」、2026年8月確認）。
1ドル150円で単純換算すると、約9,200〜1万1,000円です。ただし、これは特定構成の表示例です。
RDS、ディスク、通信、ロードバランサー、WAF、バックアップは、別途かかります。2台構成や検証環境、保守費も、この表示には含まれません。
開発・移行費用の相場
初期の設計や設定、監視設計を含む開発費は、規模によって次の幅が目安です。
- 小規模な検証・社内ポータル：50万〜300万円程度
- 中小規模の業務Web：300万〜1,500万円程度
- 日中をまたぐEC・会員・受発注：1,500万〜8,000万円程度
- 大規模な基幹・分析・AI基盤：8,000万円〜数億円の場合
認証や管理画面、帳票を含めると、工数が増えます。外部API、DB、テストも、工数を増やす要素になります。
上記は、一般的な工程相場とAlibaba Cloud固有の設計要素を合わせた推定です。特定企業の見積ではありません。
期間の目安は、小規模な検証で1〜2か月、中小規模で3〜6か月です。複数国・複数システムの案件では6〜12か月、大規模案件では12か月以上が目安です。
工程を並行できるかどうか、発注側の意思決定、既存データの品質によって、期間は前後します。短納期では、機能を絞るとともに、PoCと本番導入を段階に分けます。
保守・運用費用の相場
保守費は、初期開発費の年10〜20％程度が初期の目安です。対応時間や作業範囲によって、金額は変わります。
- 対応時間：受付のみ、平日日中の監視、24時間365日の障害対応
- 保守作業：軽微な改修、OSパッチ、脆弱性対応、費用見直し、月次報告、復元テスト
- 費用管理：固定費と従量利用料を分け、予算アラートや停止忘れ防止、割引施策の判断者を決める
- 上限超過：急増時に拡張を止めるか、事業継続を優先するか承認手順を定める
Alibaba Cloudの委託先選定と見積比較のポイント
委託先は、知名度や資格数よりも、今回の業務に必要な経験で選びます。公式の導入事例には、たとえば、ゲームのグローバル展開や日中をつなぐ訪日サービスがあります。ほかに、海外小売や生成AIの事例もあります。
事例があっても、自社と同じ規模やデータ分類を満たすとは限りません。運用時間や障害許容度も、事例の条件と照らして確かめます。そのため、提案に反映された内容を確認します。
認定・実績・運用体制の確認
掲載時点や地域、契約条件は変わることがあるため、提案時点の体制と担当者を確認します。
候補の会社には、資格と設計経験、運用実績を確認します。障害時の対応体制も、あわせて見ます。
- 認定：認定資格者数と公式パートナーの現行ステータス
- 設計経験：東京・中国本土・香港・シンガポールなどの地域
- 技術実績：RDS・ACKの運用とデータ移行
- 導入事例：顧客名だけでなく、課題、構成、移行の難所、運用後の改善
- 障害対応：時間帯ごとの一次受付、技術判断、Alibaba Cloudへのエスカレーション、顧客報告
日本語の窓口があっても、夜間や中国側リージョンの障害対応は、別に確認しておきます。
見積の内訳と前提条件の比較
総額よりも、内訳の細かさを見ます。要件定義、基本・詳細設計、開発、テストは、工程ごとに分けてもらいます。移行、リリース、管理、ドキュメント、保守の工程も、分けて示してもらい、人月や作業時間を確かめます。
クラウド利用料は、ECSの台数やスペック、稼働時間の前提を記載してもらいます。RDSの容量やバックアップ、通信量、環境数、冗長化の前提も、あわせて書いてもらいます。
見積の除外欄では、移行や関係者対応、稼働後の対応が含まれているかを確かめます。確認したい作業は、次の3分野に分けられます。
- 移行・検証：データクレンジング、セキュリティ診断、負荷試験
- 関係者対応：外部サービス契約、現行ベンダー調整、利用者研修
- 稼働・地域：リリース立会い、障害対応、追加リージョン、英語・中国語対応
除外項目が多い見積は、安く見えても、あとから追加発注が増える可能性があります。
データ・セキュリティ・契約終了時の確認
中国本土や海外リージョンでは、データフロー図を作ります。図には、個人・決済・機密情報の保管場所を書き込みます。ログとバックアップの保管場所も、あわせて描きます。
個人情報保護委員会は、外国の第三者へ提供する場合に、本人への情報提供や同意、移転先の保護措置を確認する考え方を示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」、2025年12月版）。
法令への対応では、Alibaba Cloudの機能を使うことに加えて、法務や専門家への確認が必要です。
- 委託先への確認：暗号化、鍵管理者、RAM権限、MFA、監査ログ、脆弱性、再委託先、担当者アクセス、バックアップ場所
- 契約終了時：データ返却、アカウント・権限移管、ログ保存、消去証明、DNS・証明書移管
出口を決めておかないと、他社へ切り替える際に、高額な再構築費がかかる場合があります。
発注後のAlibaba Cloud開発を成功させる進め方
進め方は、要件定義と設計、構築から始まります。テストや移行、リリースを経て、最後に運用の引き継ぎを行います。発注側が判断を任せきりにすると、不要な機能や運用できない構成が残りやすくなります。
発注側は、優先順位と受入基準を持ちます。一方で、委託先は、技術上の選択肢とリスクを説明します。
PoCと設計レビューによる不確実性の低減
不確実な技術は、小さく検証しておきます。そのうえで、設計レビューにより、本番時の動作と運用条件を確かめます。
- PoC対象：新リージョン、DB、コンテナ、AI連携、日中間通信
- 検証項目：認証、主要API、移行データの一部、監視、バックアップ復元、負荷再現
- 実施条件：成功条件とPoCで確認しない項目を、契約前に決める
- 設計レビュー：複数ゾーン、RDS復元時間、WAF調整者、ログ保存日数
結果は本番の設計に反映します。あわせて、レビューの記録と未解決の課題を残します。重要な判断も、口頭で済ませず書面にします。
テスト・移行・リリースを分けた確認
工程ごとに完了条件を確かめ、移行後に社内で運用できるよう、情報をつなぎます。
- テスト：受入可否の判断
- 移行・リリース：本番環境への切り替えと稼働
- 運用引き継ぎ：社内担当者への必要な運用情報の共有
テストでは、性能や障害復旧、権限、ログを確認します。バックアップやセキュリティ、端末、日中間の通信品質も、確かめます。
受入テストでは、利用者が業務を最後まで行えるかを検証します。合格条件と未対応事項は、記録しておきます。重大な不具合を残す場合は、承認者が回避策と対応期限を判断します。
移行では、本番データをバックアップしたうえで、手順を決めておきます。リハーサルや差分同期、切り替え、照合、切り戻しは、その手順にまとめます。
リリース後は、監視アラートと問い合わせ窓口、障害連絡網を確認します。一定期間は、監視を強化します。
引き継ぎでは、設計書に加えて、障害例やログの見方、権限申請を共有します。バックアップ復元や月次費用の確認方法も、あわせて伝えます。
よくある質問
料金、技術、契約、法務、運用は、分けて判断します。まとめて考えると、判断を誤りやすくなります。外注の前によくある質問に、順に答えます。
Alibaba Cloudは他のクラウドより安く発注できますか？
必ず安くなるとは限りません。比べるときは、ECSの単価だけでなく、総保有コストで見ます。
総保有コストには、RDSや通信、バックアップ、監視が含まれます。サポートや為替、運用人材も、含めて考えます。中国・アジア向けの通信品質や、既存サービスとの親和性に価値がある案件では、単価以外の効果も含めて判断します。
日本企業でもAlibaba Cloudのシステムを発注できますか？
発注できます。ただし、日本語の窓口や請求方法、サポート時間を確認します。加えて、日中間ネットワークや中国本土リージョンの利用条件、データ保管場所も見ます。
日本国内で完結する小規模システムなら、AWSやAzure、Google Cloud、国内クラウドも、同じRFPで比べます。そのうえで、Alibaba Cloudを選ぶ理由を明確にします。
Alibaba Cloudの開発会社はどう選べばよいですか？
資格や公式パートナーの実績に加えて、自社と同じ業務や規模、利用地域、移行方式、運用時間の経験がある会社を選びます。
委託先には、リージョン選定の理由やRTO・RPO、見積前提を質問します。障害連絡体制や納品物、アカウント所有権、終了時のデータ返却についても、確かめます。具体的に回答し、リスクと追加費用の条件を示す会社が、比較の対象になります。
中国リージョンに個人情報を保存しても問題ありませんか？
一律に問題ないとも、問題があるとも言い切れません。まず、情報の種類や目的、データの流れを確認します。そのうえで、委託先と再委託先、保管場所、アクセス担当者、適用法令と契約を見ます。
必要な同意や情報提供、保護措置を検討します。さらに、発注前にデータフロー図と責任分界表を作り、法務や専門家の確認を受けます。
まとめ
Alibaba Cloudの発注では、何をどの地域で、どのデータをどの水準で動かし、誰が運用するかを決めます。そのうえで、発注形態を比べ、要件定義とPoCによって不確実性を減らします。
比較可能なRFPと見積の作成
RFPには、業務と非機能の要件、リージョン、データ分類を記載します。移行範囲やテスト、運用、終了時の引き継ぎも、書いておきます。
見積では、利用料や開発・移行費、保守費を分けて比べます。作業範囲と除外事項も、あわせて見ます。価格のほかに、障害対応や権限管理、設計書とソースコードの帰属を確かめます。そのうえで、自社で長期に管理できる委託先を選びます。
小さく検証してからの本番発注
自社に合うか迷う場合は、主要API、移行データの一部、監視、バックアップ復元を対象にPoCを行います。結果をもとに、契約や費用、体制、日程を見直し、本番の範囲を決めます。
発注側の判断事項を整理し、技術と運用を説明できるパートナーと進めることで、予算超過や稼働後のトラブルを抑えられます。
▼全体ガイドの記事
・Alibaba Cloudのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。