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

Google App Engineのシステム開発を発注・外注するなら、App Engineを使える会社を探すだけでは不十分で、業務要件と非機能要件を整理し、App Engine・Cloud Runなどを比較したうえで委託範囲と運用責任まで契約に落とし込むことが重要です。

本記事では、Google App Engineのシステムを外部の開発会社へ依頼する方法を、発注形態の選び方、RFPと要件整理、契約形態、費用相場、見積書の比較、委託先の選定、リリース後の保守まで順番に解説します。Google Cloudの利用料と開発会社への委託費を分けて考え、発注後に追加費用や責任分界で迷わないための確認項目も紹介します。

▼全体ガイドの記事
・Google App Engineのシステム開発の完全ガイド

Google App Engineのシステムを発注する前に知っておきたい全体像

App Engineは、アプリケーションをGoogle Cloud上で動かすフルマネージド型のPaaSです。仮想マシンの構築やOSパッチの作業を減らせますが、業務要件、データ設計、認証、監視、バックアップ、障害時の判断まで自動化されるわけではありません。発注では「何を作るか」と同時に「誰がどこまで運用するか」を決める必要があります。

App Engineは、会員管理、販売管理、社内申請、予約、業務ポータル、外部向けWebサービス、API基盤などに利用できます。実際の業務システムでは、App Engineだけで完結させず、トランザクションデータをCloud SQL、ファイルをCloud Storage、非同期処理をCloud TasksやPub/Sub、秘密情報をSecret Manager、ログと監視をCloud LoggingやCloud Monitoringに分ける構成が一般的です。

この構成にすると役割分担が明確になりますが、サービスごとの権限、障害時の復旧方法、バックアップの保存期間、通信量による課金を設計しなければなりません。開発会社には「App Engineへデプロイできますか」だけでなく、「Cloud SQLの復旧試験をどのように行いますか」「監視アラートを誰が受けますか」と確認することが大切です。

既存のApp Engine資産を活用する案件や、迅速にWebアプリケーションを公開したい案件ではApp Engineが有力です。一方、コンテナを標準化したい、実行環境を細かく制御したい、将来複数サービスへ分割したい、GPUなどの新しい実行要件がある場合はCloud Runも候補になります。Google Cloud公式ドキュメントは、2026年時点で新規利用者にCloud Runを優先候補として評価するよう案内しています（出典: Google Cloud「Choose an App Engine environment」、2026年確認）。

したがってRFPには「App Engineで構築すること」と固定して書くよりも、「業務要件と非機能要件を満たす構成を提案すること」と書き、App Engine標準環境、フレキシブル環境、Cloud Runを比較させる方法が適しています。どうしてもApp Engineを採用する場合も、採用理由と将来の移行方針を提案書に記載してもらうと、技術選定の説明責任を果たしやすくなります。

発注形態はどのように選べばよいですか？

結論として、業務や予算が固まっていない段階では企画・要件定義を先に委託し、要件と成果物が明確になった段階で開発を発注する分割型が使いやすいです。仕様を自社で整理でき、納期と成果物を明確に定義できる場合は一括請負、継続的な改善や要件変更が多い場合は準委任やアジャイル型が適しています。

一括請負は、決められた成果物を決められた期限までに納品してもらう発注形態です。画面一覧、機能一覧、外部連携、性能、セキュリティ、テスト、移行、操作教育までを仕様書に書けるなら、予算を計画しやすいメリットがあります。販売管理や申請システムのように、初回リリースの範囲が比較的明確な場合に向いています。

ただし、要件が曖昧なまま請負契約を結ぶと、仕様変更が追加請求や納期延長に変わりやすいです。特にデータ移行件数、帳票の例外、権限の組み合わせ、ピーク時の同時接続数は後から膨らみやすいため、請負の前に短期間の要件定義やPoCを置くと安全です。

準委任は、業務に必要な専門人材やチームの稼働に対して報酬を支払う形態です。利用者の反応を見ながら画面を改善する、既存システムとの連携仕様を調査しながら進める、運用開始後も毎月機能を追加するといった案件に向いています。月ごとの稼働時間、参加する役割、定例会、成果物、品質評価の方法を契約書や個別発注書に定めておくことが重要です。

準委任は柔軟な反面、完成責任が一括請負と同じではありません。発注者側にプロダクトオーナーや意思決定者がいないと、会議ばかり増えて開発が進まないことがあります。要件の優先順位を決める責任者、受入基準、月次で確認するKPI、予算上限を先に決めておくと、柔軟性と統制を両立できます。

App Engineを初めて使う場合や、Cloud Runとの適性が分からない場合は、技術検証を先に発注する方法があります。認証、主要画面、Cloud SQL接続、CI/CD、ログ監視、負荷の簡易確認までをPoCの成果物にし、実測した処理時間と運用手順を本開発の見積条件へ反映します。

PoCを本開発と混同しないことも大切です。PoCのコードをそのまま本番利用するのか、作り直すのか、検証で発生した費用を本開発費から控除するのかを、発注書に記載します。段階発注にすると初期リスクは下げられますが、各段階の終了条件と次段階へ進む判断基準が必要になります。

RFPと要件整理は何をどこまで準備すればよいですか？

RFPは、開発会社へ提案を依頼するための資料です。細かな画面仕様をすべて完成させる必要はありませんが、背景、目的、対象業務、利用者、希望時期、予算の考え方、候補の技術、提案してほしい範囲を揃えると、各社の見積条件が近づきます。会社ごとに前提が異なる状態で金額だけを比べると、安い提案が後から高くなるため注意が必要です。

まず、現状の業務フローを「誰が、いつ、何を入力し、誰が承認し、どのデータを次の業務へ渡すか」で整理します。対象部署、利用者数、権限の種類、月間処理件数、繁忙期のピーク、保存年限、既存データの件数を記載すると、画面数やデータベース容量だけでなく、負荷試験と移行作業の見積にもつながります。

個人情報、給与情報、取引情報、機密ファイルを扱う場合は、データ分類とアクセス範囲をRFPに含めます。個人情報保護委員会の通則ガイドラインでは、委託先の安全管理措置が委託元に求められる水準と同等かを事前に確認することが示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

App Engineの発注で抜けやすいのが非機能要件です。目標応答時間、同時接続数、月間稼働率、障害時の復旧目標、バックアップの世代数、ログの保存期間、メンテナンス可能時間、許容するデータ損失量を、できる限り数値で示します。「高速」「安全」「止まらない」だけでは、見積の前提にも受入基準にもならないためです。

セキュリティでは、IAMの役割分担、管理者の多要素認証、秘密情報の保管、監査ログ、脆弱性対応、IP制限、外部公開範囲を確認します。App Engine標準環境では、Google Cloud公式が2025年3月からTLS 1.1以前を非推奨とし、2026年3月以降は古いTLS接続への対応をより厳格化すると案内しています（出典: Google Cloud「Secure your app with minimum TLS」、2026年確認）。既存端末や連携先が古い場合は、発注前に接続可否を検証します。

RFPには、発注予定日と希望リリース日、予算の上限または想定レンジ、利用部門、社内の責任者、既存システムの資料、利用可能なGoogle Cloudプロジェクト、データ移行の担当、社内で用意できる作業時間を記載します。発注者が担うマスタ整備、受入テスト、ユーザー教育、契約審査が曖昧なままだと、開発会社が見積に含めない作業が発生しやすくなります。

提案依頼時には、構成図、工程表、体制表、前提条件、除外事項、リスク、費用内訳、保守プラン、成果物一覧を同じ形式で提出してもらいます。さらに、App Engine標準環境・フレキシブル環境・Cloud Runを採用しなかった場合の理由も求めると、単なる技術名の比較から、事業に合う構成の比較へ進められます。

契約形態と責任分界はどこを確認すべきですか？

契約書では、作業内容だけでなく、成果物、検収方法、変更管理、知的財産権、再委託、秘密保持、個人情報、障害時の連絡、契約終了時の引き渡しを確認します。クラウドを使うとインフラの責任がGoogleへ移る部分はありますが、アプリケーションの欠陥、誤ったIAM設定、データ移行ミス、監視設定の不足までGoogleが解決してくれるわけではありません。

請負契約を採用する場合は、完成の定義を曖昧にしないことが重要です。要件定義書、基本設計書、詳細設計書、ソースコード、インフラ設定、テスト結果、操作マニュアル、移行結果、運用手順書など、納品物を一覧化します。検収期間、指摘を直す期限、重大度の判定、再検収の条件を決めておくと、リリース直前の認識違いを減らせます。

仕様変更は、変更依頼の起票、影響範囲の確認、追加費用と納期の提示、発注者の承認という流れにします。口頭やチャットだけで変更を進めると、後から「当初仕様に含まれていた」と争いになりやすいです。特に帳票のレイアウト、外部APIの仕様変更、データ移行の例外処理は、変更管理の対象として契約書と見積書を連動させます。

保守契約では、受付時間、一次回答の時間、障害の優先度、復旧目標、連絡方法、月次報告、ログ確認、脆弱性対応、ランタイムや依存ライブラリの更新、Google Cloudの仕様変更への対応を定めます。24時間365日の監視を依頼するのか、営業時間内の問い合わせ対応だけにするのかで費用も体制も大きく変わります。

アプリケーションの保守とGoogle Cloud利用料の支払いを別会社にする場合は、障害の切り分け窓口を一本化できるか確認します。クラウドアカウント、請求先、ドメイン、リポジトリ、CI/CD、監視通知を発注者が管理し、開発会社へ必要な権限だけ付与する方式にすると、契約終了後の引き継ぎとベンダー変更がしやすくなります。

個人情報を扱うシステムでは、委託先の選定基準、アクセスできる担当者、保存場所、目的外利用の禁止、事故発生時の報告、契約終了後の返却・消去、監査や報告の方法を確認します。個人情報保護委員会は、委託先の選定、必要な契約、安全管理の実施状況の把握を委託元の監督に含めています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

再委託を認めるときは、再委託先の会社名、担当業務、データへのアクセス範囲、委託先と同等の安全管理義務、事故時の連絡、定期報告の方法を契約に書きます。特定個人情報を扱う場合は、個人情報保護委員会のガイドラインが示すように、再委託の許諾や状況確認を含めて、より厳格に管理する必要があります。安さだけで海外や別会社への再委託を許可しないことが大切です。

Google App Engineのシステム開発費用と利用料の相場

費用は、開発会社へ支払う初期開発費、Google Cloudの利用料、公開後の保守運用費に分けて考えます。App Engineを使うから開発費が一律に安くなるわけではなく、画面数、権限、外部連携、データ移行、テスト、運用設計によって大きく変わります。以下はApp Engine固有の定価ではなく、業務Webシステムの一般的な工数と、リサーチノートに整理した相場をもとにした発注予算の目安です。

技術検証やPoCは100万〜300万円程度、認証や主要画面、API、CI/CDを含む小規模な業務Webシステムは500万〜1,500万円程度が一つの目安です。複数部門、外部API、データ移行、バッチ、負荷試験まで含む中規模案件は1,500万〜5,000万円程度、ERPなど基幹システムとの複雑な連携や段階移行を伴う大規模案件は5,000万〜2億円以上になる可能性があります（出典: リサーチノート「Google・App・Engineのシステム」、業務システムの一般的な工数整理、2026年）。

期間は、PoCで1〜2か月、小規模で2〜4か月、中規模で4〜9か月、大規模で9〜18か月以上が目安です。ただし、これは要件が決まり、発注者がレビューやデータ準備に参加できる場合のレンジです。社内の意思決定が遅い、既存データが不整備、外部システムの仕様が不明、受入テストを後回しにする、といった条件では期間が延びます。

Google Cloudの利用料は、App Engineの環境、インスタンス数とクラス、稼働時間、通信量、Cloud SQL、Cloud Storage、ログ、バックアップなどの合計です。Google Cloud公式料金表では、標準環境は無料枠を超えた後にインスタンスクラスごとの課金が発生し、例としてF1は1インスタンス時間あたり0.05米ドル、F2は0.10米ドル、F4は0.20米ドルです。フレキシブル環境は無料枠がなく、例としてvCPUが0.0526米ドル／時間、メモリが0.0071米ドル／GiB・時間です（出典: Google Cloud「App Engine pricing」、2026年確認）。

たとえば、標準環境のF1相当を2インスタンスで月730時間稼働させる単純計算では、無料枠を差し引いた課金対象が約620時間となり、App Engine部分は約31米ドル、1米ドル=150円と仮置きすると約4,650円です。ただし、これはインスタンス部分だけの試算で、Cloud SQL、外向き通信、ログ、バックアップは含みません。請求額を断定せず、Google Cloudの料金計算ツールと実際の負荷試験で再見積もりします。

保守運用費は、初期開発費の年15〜20%程度を置くことがあります。たとえば初期開発費が3,000万円の場合、年450万〜600万円、月37.5万〜50万円程度が一つの予算検討レンジです。ただし、これは一般的な目安であり、監視時間、SLA、問い合わせ件数、追加開発、データベース保守、セキュリティ対応の有無で変わります（出典: リサーチノート「Google・App・Engineのシステム」、業務システム保守費の整理、2026年）。

見積書では、初年度に含まれる保守と2年目以降の保守を分け、Google Cloud利用料、ドメインや証明書、監視ツール、バックアップ、脆弱性診断、機能追加を別項目にします。料金の上限アラート、予算通知、不要なログやリソースの削減、開発・検証環境の停止ルールも、発注時に運用設計へ含めると予算超過を管理しやすくなります。

委託先の選定と見積比較で失敗しないポイント

委託先は、Google Cloudの資格やパートナー表示だけでなく、業務理解、データ移行、非機能要件、アプリケーション保守を含めて評価します。App Engineのデプロイ経験があっても、Cloud SQLの設計や障害対応、既存システムとの連携ができるとは限りません。候補会社には、類似案件の規模、担当者が実際に設計・開発する範囲、リリース後の体制を具体的に聞きます。

面談では、「標準環境とフレキシブル環境をどう使い分けますか」「Cloud Runを含めると判断は変わりますか」「Cloud SQLのバックアップ復元をどの環境で試しますか」「負荷試験のシナリオと合格基準は何ですか」「障害時に何分以内に誰が連絡しますか」と質問します。回答がサービス名の羅列ではなく、自社の業務・データ・利用量に結び付いているかを確認します。

実績は、会社のロゴや公開事例の数よりも、案件の担当範囲を確認することが大切です。要件定義だけを担当したのか、アプリとインフラを一緒に構築したのか、移行後も保守したのかで評価は変わります。可能であれば、提案時点でプロジェクトマネージャー、アプリ担当、クラウド担当、保守担当の役割と稼働時期を示してもらいます。

相見積もりでは、総額の安い会社をすぐに選ばず、要件定義、設計、実装、テスト、移行、教育、管理の費用がどこに含まれるかを確認します。一般的な工数配分の目安は、要件定義10〜15%、設計25〜35%、実装30〜40%、テスト15〜20%、移行・教育5〜10%程度です。各社がこの分類で内訳を出せば、安い理由と高い理由を比較しやすくなります。

見積の比較表には、金額のほか、納期、対象機能、画面数、API数、データ移行件数、負荷試験の条件、成果物、検収条件、保守範囲、追加変更の単価、除外事項を並べます。特に「要件定義一式」「クラウド構築一式」「テスト一式」のような一式表記は、含まれる作業を質問します。見積の前提が回答されない場合は、金額が安くても発注リスクが高い提案です。

発注時には、ソースコード、設計書、テストコード、IaC、CI/CD設定、監視設定、アカウント情報、運用手順書を誰が所有し、どの形式で納品するかを明記します。開発会社の個人アカウントで本番環境を構築したり、発注者がリポジトリへアクセスできなかったりすると、契約終了時に移行できません。Google Cloudプロジェクトと請求アカウントは、原則として発注者の管理下に置く方法を検討します。

契約終了時の引き継ぎ期間、質問対応の単価、データのエクスポート方法、秘密情報の返却・削除、第三者への移管支援も決めておきます。App Engine固有の設定や組み込み機能に依存する部分を一覧にしておけば、将来Cloud Runや別の基盤へ移行する際の調査費用も見積もりやすくなります。

Google App Engineのシステム発注でよくある質問

最後に、Google App Engineのシステムを外注するときに多く寄せられる疑問へ回答します。費用、期間、技術選定、保守責任を分けて考えると、見積書や提案書の読み違いを防げます。

最低額を一律に決めることはできませんが、認証や主要画面を含む技術検証は100万〜300万円程度、小規模な業務Webシステムは500万〜1,500万円程度が発注予算の検討レンジです。実際の費用は機能数、連携、データ移行、非機能要件、テスト、教育で変わるため、RFPを渡して同じ前提で見積もりを比較します。

App Engineのデプロイ実績だけで決めるのではなく、業務要件、Cloud SQL、データ移行、監視、障害対応、保守体制まで確認して選びます。新規案件ではCloud Runを含めた比較が必要な場合もあるため、App Engineを採用する理由を説明でき、発注者の業務に近い実績を持つ会社が候補になります。

通常は分けて考えます。開発会社への設計・実装・テスト費用とは別に、App Engine、Cloud SQL、通信、ストレージ、ログ、バックアップなどのGoogle Cloud利用料が発生します。開発会社が利用料を立て替える契約では、請求明細、上限アラート、契約終了後の請求先変更、予算超過時の連絡方法まで確認します。

発注できますが、最初から本開発の請負契約にせず、企画整理、要件定義、技術検証を準委任や段階発注で依頼する方法が適しています。業務フロー、優先機能、データ、非機能要件、採用基盤の判断材料を成果物として受け取り、その内容をもとに本開発の請負またはアジャイル契約へ進みます。

まとめ

Google App Engineのシステムを発注・外注するときは、App Engineを使えるかだけでなく、業務要件、データ移行、非機能要件、セキュリティ、Cloud SQLや監視を含む全体設計を評価します。新規案件ではCloud Runも比較し、App Engineを採用する理由を提案書に残しておくと、将来の技術変更にも対応しやすくなります。

まずは、対象業務と利用者、データの種類と件数、ピーク負荷、希望時期、予算レンジ、社内の担当者、既存システムとの連携を整理します。次に、要件定義やPoCを先行させるか、本開発を一括で依頼するかを決め、RFPへ成果物・非機能要件・運用範囲・見積の内訳・除外事項を記載します。

候補会社には同じRFPを渡し、費用だけでなく、採用アーキテクチャ、体制、工程、受入基準、保守、再委託、納品後の引き継ぎを比較します。金額の根拠が明確で、発注者側の作業も含めて説明でき、運用開始後の責任分界まで一緒に設計できる会社を選ぶことが、Google App Engineのシステム開発を成功させる近道です。

▼全体ガイドの記事
・Google App Engineのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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