Alibaba Cloudのシステム開発の発注/外注/依頼/委託方法について

Alibaba Cloudのシステム開発を発注・外注するなら、クラウド料金の安さだけで委託先を決めず、利用地域、データの扱い、業務要件、運用責任まで含めてRFPと契約に落とし込むことが重要です。

Alibaba CloudはECSやRDS、OSS、VPC、SLB、WAF、ACKなどを組み合わせて業務システムを構築する基盤です。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の比較方法、見積書の読み方、発注後の進め方まで、外注前に判断しておきたいポイントを順番に解説します。

▼全体ガイドの記事
・Alibaba Cloudのシステム開発の完全ガイド

Alibaba Cloudのシステムを発注する前に知るべき全体像

Alibaba Cloudのシステムは、業務アプリケーションとクラウドサービスを組み合わせて作る仕組みです。クラウド事業者にすべてを任せれば完成するものではなく、どの業務を、どの地域で、どの水準の可用性と安全性で動かすかを発注側が決める必要があります。

Alibaba Cloudのシステムとは、Alibaba Cloudのクラウド基盤上に業務アプリケーション、データベース、ネットワーク、認証、監視、バックアップなどを組み合わせて構築する業務システムです。たとえば、利用者からのアクセスをCDNやWAFで受け、SLBで振り分け、ECSやACK、Function Computeでアプリケーションを動かし、RDSやApsaraDBにデータを保存し、OSSにファイルやバックアップを保管する構成が考えられます。したがって、発注時に「Alibaba Cloudで作ってください」とだけ伝えても、必要な機能や運用範囲は確定しません。

まず、目的を中国・東南アジア向けサービスの展開、既存システムの海外連携、高負荷サイトの安定化、データ分析基盤の整備などに分けます。そのうえで、ユーザー数、同時接続数、データ量、許容停止時間、バックアップの保持期間、障害から復旧する目標時間を数値化することが、委託先から比較可能な提案を得る近道です。

外注の主な理由は、Alibaba Cloudのサービス知識だけでなく、日中間のネットワーク、リージョンごとの機能差、移行、監視、障害対応まで経験できる人材を社内だけでそろえることが難しいためです。特に中国本土を含む構成では、通信品質やデータの保管場所がアプリケーション設計に影響し、後から変更すると作り直しが発生する場合があります。

一方、外注しても発注側の責任がなくなるわけではありません。Alibaba Cloud公式のECS共有責任モデルでは、基盤側の安全性はAlibaba Cloudが担う一方、OSの更新、セキュリティグループ、アプリケーション、アクセス権限、データ暗号化などは利用者側の責任とされています（出典: Alibaba Cloud「ECS shared security responsibility model」、2026年5月更新）。委託先との責任分界を決め、社内の承認者と運用担当も明確にすることが大切です。

Alibaba Cloudのシステム開発はどの発注形態が適していますか？

Alibaba Cloudの発注形態は、パッケージやSaaSを活用する方法、クラウド上の業務アプリを個別開発する方法、既存システムを移行・連携する方法に大きく分けられます。最初からスクラッチ開発に決めるのではなく、業務の標準化と独自性のバランス、納期、将来の保守体制で選ぶことが重要です。

会計、販売管理、顧客管理、ワークフローなど、すでに標準化された業務はSaaSやパッケージを中心にし、Alibaba Cloudはデータ連携や独自画面の基盤として使う方法があります。初期開発を抑えやすく、導入期間も短くなりやすい一方、パッケージの仕様に業務を合わせる必要があります。発注前に、APIの有無、データのエクスポート方法、認証連携、利用リージョン、サービス終了時のデータ返却を確認します。

この形態に向くのは、業務を大きく変えずに短期間で使い始めたい企業です。ただし、SaaS事業者、Alibaba Cloudの構築会社、自社の三者に責任が分かれるため、障害時の一次窓口を契約書に記載します。どの会社がログを確認し、どの会社が復旧判断をし、どの会社が利用者へ説明するかまで決めておくことが必要です。

自社独自の受注、在庫、会員、決済、審査、承認などを実装する場合は、Alibaba Cloud上に業務アプリを個別開発します。ECSとRDSを使う一般的な構成から、ACKによるコンテナ運用、Function Computeによるイベント処理まで選択肢があります。重要なのは、サービス名を先に固定することではなく、性能、可用性、運用者のスキル、将来の移行可能性から構成を決めることです。

個別開発は業務に合わせやすい反面、画面やAPIだけでなく、認証、監査ログ、バックアップ、監視、権限管理、障害復旧まで作り込む必要があります。発注時は機能一覧だけでなく、非機能要件と納品ドキュメントを見積の対象に含めます。ソースコード、Infrastructure as Code、アカウント、設計書を誰が所有し、契約終了時にどの形式で引き渡すかも明記します。

既存のオンプレミス、AWS、Azure、国産クラウドからAlibaba Cloudへ移行する案件では、移行計画と業務連携を分けて整理します。現行データの形式、文字コード、個人情報の有無、データ量、停止可能な時間、切り戻し方法を調査し、移行テストを複数回実施します。既存環境を残したまま段階移行するなら、VPNや専用線、API、バッチの実行順序も設計対象です。

移行案件では「構築費は安いがデータ整合性の確認が別料金」「移行当日の立会いや切り戻しが含まれていない」といった見積の抜けが起きやすいです。RFPには、移行対象のテーブル数、ファイル容量、データクレンジングの担当、リハーサル回数、業務停止の上限、移行後の照合方法を記載します。開発会社が既存ベンダーと調整する場合の窓口も決めておくと、責任の押し付け合いを防げます。

発注前の要件整理とRFPはどこまで準備しますか？

RFPは、委託先に作ってほしいシステムの仕様書だけではなく、背景、目的、制約、期待する成果、提案してほしい範囲を伝える文書です。細部を決め切れない段階でも、比較に必要な条件はそろえます。特にAlibaba Cloudでは、リージョンとデータの扱いが構成や費用に影響するため、曖昧なまま見積だけを依頼しないことが重要です。

最初に、誰が、どの業務で、何を判断するためのシステムかを整理します。利用者の部署、権限、承認経路、入力項目、検索条件、帳票、外部システムとの連携、例外処理を業務フローに落とし込みます。「担当者が登録する」だけでなく、「重複データが来た場合」「承認者が不在の場合」「通信が切れた場合」まで書き出すことが、後の追加費用を減らします。

中国・アジア向けに提供する場合は、言語、タイムゾーン、通貨、税、決済、現地の商習慣も要件に含めます。日本本社と海外拠点でマスタや権限を共有するのか、リージョンごとに分離するのかも決めます。AIや分析機能を使う場合も、先にマスタの品質とデータ更新責任を確認し、入力が整っていない状態で高機能だけを発注しないことが大切です。

非機能要件は、処理速度、同時接続数、稼働時間、障害時の復旧時間、データ損失の許容範囲、バックアップ頻度、ログ保存期間、セキュリティ基準などです。たとえば「速い」「止まらない」ではなく、ピーク時の同時接続数、主要画面の応答時間、RTO、RPO、月間稼働率の目標を記載します。数値が決められない場合は、現状値を測り、PoCで確定する工程をRFPに入れます。

リージョンについては、対象ユーザーとの距離、既存ネットワーク、データ保管場所、利用可能なサービス、料金を比較します。Alibaba Cloud公式のリージョンガイドでは、東京リージョンに5つのゾーンが示されています。また、リージョンはリソース作成時に選択し、作成後に変更できないと説明されています（出典: Alibaba Cloud「Regions and zones」、2026年7月更新）。本番構成を決める前に、必要なRDS、SLB、WAF、ACKなどが選択したリージョンで提供されているかを委託先に確認します。

RFPには、必須機能、できれば欲しい機能、対象外の機能を分けて記載します。あわせて、提案書に求める項目を指定します。具体的には、構成図、採用サービスの理由、リージョン選定の根拠、移行方式、テスト計画、運用体制、障害対応、開発スケジュール、前提条件、除外事項、費用内訳、見積の有効期限を求めます。

候補会社には同じ資料を渡し、同じ前提で見積を作ってもらいます。会社ごとに前提が違うと、安い見積が機能や運用を含んでいないだけかもしれません。提案の自由度を残したい場合でも、クラウド利用料、開発費、移行費、保守費、追加変更の単価を分けて提示するよう依頼すると、後から比較しやすくなります。

Alibaba Cloudの外注契約は準委任と請負をどう使い分けますか？

契約形態は、成果物と仕様が固まっているか、発注後に一緒に要件を詰めるかで選びます。契約名だけで安全性が決まるわけではなく、作業範囲、成果物、検収条件、変更手続き、責任分界、知的財産、再委託、秘密保持、契約終了時の引き継ぎを具体化することが重要です。法務・税務上の判断は自社の専門家に確認します。

準委任契約は、要件定義、アーキテクチャ検討、PoC、移行計画、運用支援など、専門家の作業や助言を受ける段階に向きます。発注側が委託先と相談しながらリージョンやサービスを決める場合、最初から完成品の仕様を固定するよりも、作業期間、体制、稼働時間、報告内容を合意しやすくなります。

ただし、準委任だから成果を確認しなくてよいわけではありません。月次の成果報告、設計レビュー、課題一覧、意思決定ログ、次月の計画を提出物に含め、作業の進み具合を評価します。開発工程に入る前に、準委任で要件定義を行い、その結果をもとに請負または別契約へ移る段階分けも有効です。

請負契約は、完成させるシステムの範囲、成果物、検収条件が明確な開発に向きます。画面、API、データベース、インフラ設定、テスト仕様書、操作マニュアルなどを成果物として列挙し、検収日と不具合修正の扱いを決めます。クラウド環境の構築では、構築作業だけを納品するのか、監視や運用手順まで納品するのかで内容が大きく変わります。

請負で注意したいのは、要件の変更を無償対応として扱う範囲です。仕様追加、リージョン変更、外部システム側の仕様変更、データ移行量の増加、性能要件の引き上げなど、見積の前提が変わった場合は、変更要求書で費用と納期を合意します。検収を曖昧にすると、使える状態になっても支払いと修正の交渉が長引くため、受入テストの観点を事前に共有します。

本番稼働後は、開発契約と保守・運用契約を分けて考えます。監視対象、受付時間、一次切り分け、障害の重大度、連絡手段、復旧目標、定期報告、脆弱性対応、OSパッチ、バックアップ確認、費用上限を定めます。24時間監視を依頼する場合も、監視するだけなのか、アラートを受けて復旧まで行うのかを明確にします。

また、Alibaba Cloudのアカウントを委託先の所有にしないことが重要です。原則として発注側が契約主体と管理者権限を持ち、委託先にはRAMなどで必要最小限の権限を付与します。退職者や再委託先の権限をいつ無効化するか、契約終了時にログや設定、データをどの形式で返却・消去するかまで、運用手順と契約書の両方に残します。

Alibaba Cloudのシステム開発費用と月額相場はいくらですか？

Alibaba Cloudの費用は、クラウド利用料と、システムの企画・設計・開発・移行・保守にかかる委託費を分けて考えます。クラウド利用料は、ECSだけでなく、RDS、ディスク、パブリック帯域、SLB、WAF、OSS、バックアップ、監視、ログ、通信、冗長化の有無で変わります。以下は企画段階の目安であり、リージョン、為替、割引、利用量、契約期間、運用範囲によって変動します。

小規模な検証や社内ポータルであれば、ECS、RDS、OSS、最低限のバックアップを組み合わせ、月額1万〜10万円程度が初期検討のレンジです。中小規模の業務Webシステムでは、冗長化、WAF、監視、ステージング、バックアップを含めて月額10万〜50万円程度を想定します。中国・日本をまたぐECや会員・受発注システムでは、通信、複数リージョン、データ連携、負荷変動を含めて月額50万〜300万円程度、大規模な基幹・分析・AI基盤では月額300万円〜数千万円となる可能性があります。いずれも個別見積の前段階の推定です。

Alibaba Cloud公式の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円ですが、これは特定のECS構成の表示例です。RDS、ディスク、通信、ロードバランサー、WAF、バックアップ、2台構成、検証環境、保守費は別途必要になるため、単価だけで本番の月額を判断してはいけません。

小規模な検証や社内ポータルの構築は、初期の設計・設定・監視設計を含めて50万〜300万円程度、中小規模の業務Webシステムは300万〜1,500万円程度が目安です。認証、管理画面、帳票、外部API、データベース、テストまで含めると工数が増えます。中国・日本をまたぐEC、会員、受発注システムは、1,500万〜8,000万円程度、大規模基幹・データ分析・AI基盤は8,000万円〜数億円になる場合があります。これらは一般的な業務システムの工程相場とAlibaba Cloud固有の設計要素を組み合わせた推定で、特定企業の見積金額ではありません。

期間は、小規模な検証で1〜2か月、中小規模で3〜6か月、複数国・複数システムをまたぐ案件で6〜12か月、大規模案件で12か月以上が一つの目安です。要件定義、設計、開発、テスト、移行、リリースを並行できるか、発注側の意思決定が早いか、既存データの品質が保たれているかで前後します。短納期を求める場合は、機能を削るだけでなく、PoCと本番導入を段階に分けます。

保守費は、初期開発費の年10〜20％程度を初期レンジとして検討できます。ただし、問い合わせ受付だけか、平日日中の監視か、24時間365日の障害対応かで金額は変わります。軽微な改修、OSパッチ、脆弱性対応、クラウド費用の見直し、月次レポート、バックアップ復元テストまで含めると、保守の範囲は広がります。

見積書では、固定の保守費と従量課金のクラウド利用料を分離します。さらに、利用料の予算アラート、停止忘れの防止、リザーブドやSavings Planなどの割引施策を誰が判断するかを決めます。月額の上限を設ける場合は、アクセス急増時の自動拡張を止めるのか、事業継続を優先して上限超過を許可するのか、承認手順も定めておく必要があります。

Alibaba Cloudの委託先選定と見積比較のポイント

委託先は、会社の知名度やクラウド資格の数だけでなく、今回の業務に必要な経験で選びます。Alibaba Cloud公式の導入事例には、ゲームのグローバル展開、日中をつなぐ訪日向けサービス、海外小売、生成AIなどの事例が掲載されています。事例があることは参考になりますが、自社と同じ規模、データ分類、運用時間、障害許容度を満たすとは限らないため、提案内容に落とし込んで確認します。

候補会社には、Alibaba Cloudの認定資格者数、公式パートナーとしての現行ステータス、東京・中国本土・香港・シンガポールなどの設計経験、RDSやACKの運用経験、データ移行の実績を質問します。公式パートナー掲載や過去の事例は有力な確認材料ですが、掲載時点や地域、契約条件が変わることもあるため、提案時点の体制と担当者を確認します。

実績の説明では、顧客名だけでなく、課題、採用した構成、移行の難所、運用後の改善、障害時の対応範囲を聞きます。日本語の窓口があっても、夜間や中国側リージョンの障害時に誰が対応するかは別の論点です。一次受付、技術判断、Alibaba Cloudへのエスカレーション、顧客報告を時間帯別に確認します。

見積比較では、総額の安さよりも内訳の粒度を見ます。要件定義、基本設計、詳細設計、開発、テスト、移行、リリース、プロジェクト管理、ドキュメント、保守を分け、各工程の人月や作業時間を確認します。クラウド利用料は、ECSの台数、スペック、稼働時間、RDSの容量、バックアップ、通信量、環境数、冗長化の前提を記載してもらいます。

特に確認したいのは、見積に含まれない項目です。データクレンジング、外部サービスの契約、現行ベンダーとの調整、セキュリティ診断、負荷試験、利用者研修、リリース立会い、障害対応、追加リージョン、英語・中国語対応が除外されていないか確認します。除外項目が多い見積は安く見えても、後から追加発注が増える可能性があります。

中国本土や海外のリージョンを使う場合は、個人情報、決済情報、機密情報、ログ、バックアップをどこに保存するかをデータフロー図にします。日本の個人情報保護委員会は、外国にある第三者への個人データ提供について、本人への情報提供や同意、移転先での保護措置などを確認する考え方を示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」、2025年12月版）。Alibaba Cloudを使えば自動的に法令対応できるという意味ではないため、法務部門や専門家と確認します。

委託先には、暗号化、鍵の管理者、RAM権限、MFA、監査ログ、脆弱性対応、再委託先、サポート担当者のアクセス、バックアップの保管場所を質問します。契約終了時は、データの返却形式、アカウントと権限の引き渡し、ログの保存、バックアップの消去証明、DNSや証明書の移管まで確認します。出口を決めずに発注すると、別会社へ切り替える際に高額な再構築費用が発生しやすくなります。

発注後のAlibaba Cloud開発を成功させる進め方

委託先を決めた後は、要件定義、設計、構築、テスト、移行、リリース、運用引き継ぎを段階的に進めます。発注側の担当者が現場の判断を委託先へ丸投げすると、業務上は不要な機能や、運用できない構成が残りやすくなります。発注側は優先順位と業務上の受入基準を持ち、委託先は技術上の選択肢とリスクを説明する役割に分けます。

新しいリージョン、データベース、コンテナ、AI連携、日中間通信などに不確実性がある場合は、最初に小さなPoCを実施します。認証、主要API、データ移行の一部、監視、バックアップ復元、負荷の再現を短期間で検証し、結果を本番設計へ反映します。PoCの成功条件と、PoCで確認しない項目を契約前に決めると、実験が終わらない問題を防げます。

設計レビューでは、構成図だけでなく、障害時の動作と運用手順を確認します。ECSを複数ゾーンに分けるのか、RDSのバックアップから何分で復元するのか、WAFの誤検知を誰が調整するのか、ログを何日保存するのかを説明してもらいます。レビュー記録と未解決の課題を残し、重要な判断を口頭だけで終わらせないことが大切です。

テストは、機能テストだけでなく、性能、障害復旧、権限、ログ、バックアップ、セキュリティ、ブラウザや端末、日中間の通信品質まで確認します。受入テストでは、実際の利用者が業務を最初から最後まで通せるかを検証し、合格条件と未対応事項を記録します。重大な不具合を残したままリリースする場合は、回避策と対応期限を承認者が判断します。

移行では、本番データのバックアップ、リハーサル、差分同期、切り替え、照合、切り戻しを手順化します。リリース後は、監視のアラート、問い合わせ窓口、障害時の連絡網を確認し、一定期間は強化監視を行います。引き継ぎでは、設計書だけでなく、よくある障害、ログの見方、権限申請、バックアップ復元、月次費用の確認方法まで社内担当者に共有します。

よくある質問

Alibaba Cloudの発注では、料金、技術、契約、法務、運用を別々に考えると判断を誤りやすくなります。ここでは、外注前によく寄せられる質問に直接回答します。

必ず安くなるとは限りません。ECSなど一部サービスの単価だけでなく、RDS、通信、バックアップ、監視、サポート、為替、運用人材まで含めた総保有コストで比較する必要があります。中国・アジア向けの通信品質や既存サービスとの親和性に価値がある案件では、単価以外の効果も含めて判断します。

発注できます。ただし、日本語の窓口、請求方法、サポート時間、日中間ネットワーク、中国本土リージョンの利用条件、データの保管場所を事前に確認します。日本国内だけで完結する小規模システムであれば、AWS、Azure、Google Cloud、国内クラウドも同じRFPで比較し、Alibaba Cloudを選ぶ理由を明確にします。

Alibaba Cloudの資格や公式パートナー実績だけでなく、自社と同じ業務、規模、利用地域、移行方式、運用時間の経験がある会社を選びます。提案時には、リージョンの選定理由、RTO・RPO、見積の前提、障害時の連絡体制、納品物、アカウントの所有権、契約終了時のデータ返却を質問します。回答が具体的で、リスクと追加費用の条件を隠さない会社が比較対象になります。

一律に問題ないとも、問題があるとも判断できません。個人情報の種類、利用目的、データの流れ、委託先や再委託先、保管場所、アクセスする担当者、適用される法令と契約を確認し、必要な同意や情報提供、保護措置を検討します。発注前にデータフロー図と責任分界表を作り、法務・専門家の確認を受けることが安全です。

まとめ

Alibaba Cloudのシステムを発注・外注するときは、まず「何を作るか」だけでなく、「どの地域で、どのデータを、どの水準で動かし、誰が運用するか」を決めます。SaaS・パッケージ、個別開発、移行・連携のどれが適するかを比較し、要件定義とPoCで不確実性を減らします。

RFPには、業務要件、非機能要件、リージョン、データ分類、移行範囲、テスト、運用、契約終了時の引き継ぎを記載します。見積はクラウド利用料、開発・移行費、保守費を分け、作業範囲と除外事項を比較します。価格だけでなく、障害対応、権限管理、設計書やソースコードの帰属まで確認して、長期的に自社で管理できる委託先を選びます。

Alibaba Cloudが自社に向くか迷う場合は、主要APIやデータ移行の一部、監視、バックアップ復元を対象にしたPoCから始めます。検証結果をもとに、契約形態、費用、体制、スケジュールを見直し、本番の発注範囲を決めます。発注側が判断すべき事項を整理し、技術と運用の両面を説明できるパートナーと進めることが、予算超過と稼働後のトラブルを抑える方法です。

▼全体ガイドの記事
・Alibaba Cloudのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。