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

Google Pub/Subのシステム開発を外注する流れは、業務イベントと要件を整理するところから始まります。そのうえで発注形態を選び、契約と開発を工程ごとに分けて段階的に進め、運用まで担える委託先を選びます。

全体像は、完全ガイドでも解説しています。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

発注前に知るべきGoogle Pub/Subの全体像

処理先ごとにSubscriptionを分ける構成です。

Google Cloud Pub/Subは、イベントの発生元であるPublisherと、処理を担うSubscriberを非同期に切り離すフルマネージドのメッセージングサービスです。

発注費はPub/Subの設定だけで決まりません。業務イベントの発行元や、複数回受信しても安全に動く処理の設計も、発注の対象に入ります。

発注対象は業務イベント連携という範囲

たとえば、受注システムが「注文受付」イベントをTopicへ発行する構成が考えられます。

在庫更新：Subscriptionでイベントを受けて、在庫数を更新する処理。
請求・顧客通知：別のSubscriptionで処理を分けて行う、請求と顧客への通知。
分析基盤：同じTopicから配信を受けて、分析に使う基盤。

1つのTopicから複数のSubscriptionへ配信する方式は、ファンアウトと呼ばれます。処理を分けやすい一方で、処理ごとの完了条件や失敗時の再実行方法は別途設計が必要です。

購読側の実行環境も、発注範囲に含まれることが多くあります。その候補には、Cloud Run、Cloud Functions、GKE、Dataflow、BigQueryなどがあります。

プロジェクトの成否を左右する配信保証と運用設計

配信保証と障害時の運用では、委託先と次の3点を設計します。

再配信への備え：標準配信は少なくとも1回届き、タイムアウトやNACKで再配信されます。
重複処理の防止：イベントIDや業務キーを確認して、二重登録や二重請求を避ける冪等性の実装。
障害監視と再処理：Retry PolicyとDead-letter Topicを含めた障害対応の取り決め。

保持期間を決めたうえで、未ACK数と最古の未ACK経過時間を監視します。

障害時に再処理を担う人も、あらかじめ決めておきます。

Google Pub/Subの発注形態の選び方

発注形態は、要件がどこまで固まっているかと、社内にクラウドの人材がどれだけいるかで決まります。

要件が曖昧：伴走型で、要件定義から始める発注。
仕様が確定：受入条件を決めた範囲の請負。
継続的な改善・運用：工程を分けて進める準委任。

すべてを一つの契約にすると、要件変更時の費用と責任の所在が不明確になりやすいため、工程ごとに契約を分けます。

要件が曖昧な場合の伴走型・要件定義からの発注

要件定義から委託する場合は、業務イベントと成功条件を整理したうえで、次の内容を依頼します。

相談の背景：「受注システムを止めず、在庫と通知を非同期化したい」など、業務上の希望。
調査と検証：Topic名やSubscription数を決める前の、ヒアリング、現行構成調査、イベントストーミング、PoC、概算見積。
成果物：イベント一覧、現行課題、候補構成、非機能要件、次フェーズのRFP。

成果物があれば、実装会社を変更する場合にも、候補を比較しやすくなります。

仕様が固まった範囲の一括請負

Topic、Subscription、Schemaが確定している範囲は、一括請負が候補になります。

Publisher、Subscriber、監視まで確定させておく必要もあります。あわせて、テストケースと受入基準も固めます。

納品物は、Pub/Subの構成だけにせず、次の内容まで含めます。

インフラの定義：TerraformなどのIaC。
配備の仕組み：CI/CD設定。
監視：ダッシュボードとアラート。
障害への備え：DLQの再処理手順と障害訓練の記録。

これらを納品物に含めておくと、本番運用後に特定の人しか分からない状態を防げます。

改善運用や段階導入の準委任・アジャイル

段階導入や改善を続ける案件では、準委任・アジャイルが候補になります。

適する状況：イベントを増やしながら利用状況を見たい場合、既存サービスの改修と新Subscriberの開発を並行する場合。
進め方：月単位・スプリント単位で、発注側が優先順位を決め、委託先が設計・実装・検証を繰り返す。
文書化：作業範囲、稼働時間、レビュー、成果物、情報セキュリティ、障害対応を定め、責任の線引きを明確にする。

ポイント

発注形態は、要件の固まり具合と社内のクラウド人材の有無で選びます。要件が曖昧な部分と固まった部分を分けて発注すると、変更時の費用と責任の線引きがしやすくなります。

RFPと要件整理で決めておく項目

各項目を同じ前提で提案依頼に含めます。

RFPには製品名だけでなく、解決したい業務課題を書きます。対象範囲と処理量、品質条件を明記し、納品物と運用条件も書き添えます。

発注側は、候補会社が同じ前提で提案できるよう、現在のシステム構成図と業務フローも簡略版で添付します。

未確定の項目は、その旨を書いておきます。

提案時には、前提、選択肢、追加費用を分けて示してもらいます。

イベント一覧と処理責任の整理

イベント一覧には、発行元から再処理の可否までを記録します。少なくとも次の3項目を揃えます。

イベントと接続先：イベント名、発行元、Topic、購読先。
データと業務キー：必須属性、業務キー、個人情報の有無。
処理と障害対応：締切、失敗時の扱い、再処理の可否。

たとえば、注文受付では注文IDを重複排除キーにします。在庫引当も、注文IDごとに一度だけ成立させます。

通知は、再送されても同じメールを二重に送信しない設計にします。

発行元と購読先それぞれの責任者も、あらかじめ決めておきます。

責任者を決めておくと、障害が起きたときにPub/Subと処理アプリのどちらに原因があるかを切り分けられます。

配信保証・性能・セキュリティの数値定義

「リアルタイム」や「高可用性」といった言葉だけでは、会社ごとに解釈が変わってしまいます。そこで、可能な範囲で品質条件を数字で示します。

処理量と速度：平常時・ピーク時のメッセージ数、許容遅延、処理完了時間、同時実行数。
保持と復旧：メッセージ保持期間、障害時の復旧目標、監査ログの保存期間。
配信方式：標準配信、ordering key、Pull・Push、Exactly-once deliveryの要否。

Google Cloudの公式説明では、Exactly-once deliveryはPull Subscriptionに対応しています。保証範囲は同一リージョン内です。そのため、複数リージョンで受信する設計では、機能名だけに重複排除を任せない要件にします。

RFPの提案範囲と納品物の明記

RFPでは、構成・開発・運用の各成果物をどこまで含めるかを、発注側から示します。

設計：クラウド構成図、Topic・Subscription一覧、Schema定義、IAM設計。
開発と検証：アプリケーションコード、IaC、テスト計画と結果。
運用：監視ダッシュボード、アラート、運用Runbook、教育資料。

ソースコードやリポジトリ、Google Cloudプロジェクトの管理主体も明記します。サービスアカウントや秘密情報は、誰が管理するかを明らかにしておきます。

提案会社には、標準機能、追加開発、将来拡張のために保留する部分を分けて書いてもらいます。そうすると、見積を比べやすくなります。

ポイント

RFPには製品名より先に、解決したい業務課題と前提を書き、候補会社が同じ前提で提案できるようにします。未確定の項目は、前提と選択肢、追加費用を分けて示してもらいます。

契約形態と開発の進め方

検証内容を工程ごとに切り分けています。

契約では、要件が変わる工程と、成果物を確定できる工程を分けて考えます。

要件定義を準委任、基本設計以降を請負にする方法があります。また、全体を準委任にして、スプリントごとに成果を確認する方法もあります。

どちらの形でも、変更管理や受入条件、知的財産、瑕疵・障害対応を、契約書と個別仕様書に定めます。さらに、再委託と契約終了後の引き継ぎも、同じ書類で取り決めます。

要件定義と実装で分ける契約

要件定義の段階では、「注文受付」イベントが「支払確定」と「注文確定」に分かれることがあります。そこで、変更を見込む段階と実装段階とで、契約を分けておきます。

固定価格の注意：初期から全機能を請負にすると、変更のたびに追加見積が生じ、双方の認識が対立しやすくなります。
契約を分ける：現状調査とPoCは準委任で行い、要件が固まってからの本開発を請負にする。

本開発へ進む前には、イベントモデル、非機能要件、受入基準を固めておきます。

この順序なら、予算と責任の線引きを段階ごとに決められます。

PoC・本開発・移行・運用の4段階

工程ごとに検証内容を分けておくと、PoCを単なる疎通確認で終わらせずに済みます。

PoC：重要なイベントを1つか2つに絞り、PublisherからSubscriberまでの正常系と失敗系の検証。
本開発：対象業務を広げ、環境分離とIaCの整備を進める段階。
移行：旧連携から新連携への段階的な切り替え。
運用：バックログ、ack latency、エラー率、再処理件数を見ながらの改善。

PoCでは、認証、Schema、ackのタイミングを実測します。PullかPushか、重複排除やDLQも確かめます。監視と負荷も、PoCの中で測っておきます。

工程ごとの受入条件と責任の線引き

受入テストでは、到達確認に加えて、障害時の復旧と業務結果も検証します。

重複時の結果：メッセージが重複しても、業務結果が一つになるかの確認。
停止後の復旧：処理側の停止後に再開でき、DLQから安全に戻せるかの検証。
役割と説明：発注側は業務上の正解とデータ受入条件を持ち、委託先は構成・コード・テスト・運用手順を説明する。
費用負担：Google Cloud利用料、アプリ稼働費、監視費、障害対応費の負担者を決めること。

Google Pub/Subのシステム発注費用の相場

Google Pub/Sub受託開発について、国内を横断した統計はほとんどありません。そのため、ここで示すのは、業務システム開発の一般的な工程と、Pub/Sub周辺の設計・実装・テストに基づく推定レンジです。

実際の見積では、接続するシステム数やメッセージ量、既存APIやDBの改修、セキュリティ要件を確かめることになります。

負荷試験や移行、運用時間も見積の確認対象になります。また、Google Cloud利用料は、開発会社への初期費用とは別に計算します。

規模別の初期開発費レンジ

規模別の費用と期間は、次の推定レンジで見ておきます。

小規模PoC：300万〜700万円程度、期間は3〜4か月。
中規模案件：700万〜1,500万円程度、期間は5〜8か月。
大規模案件：1,500万〜5,000万円超となる場合があります。
大規模刷新：5,000万〜1億円以上、8〜12か月以上となる場合もあります。

小規模PoCでは、1〜2システムを接続します。Topic・Subscriptionや簡単なPullまたはPush、認証、最低限の監視と検証が含まれます。

小規模PoCの金額は、本番の全機能を完成させる費用ではありません。メッセージ仕様、再送、冪等性、処理性能、障害時の挙動を見極めることが目的です。

中規模では、受注・在庫・通知など3〜6系統を連携します。さらに、SchemaやDLQ、Cloud RunまたはGKEを含みます。既存DB・APIとの連携、監視、結合テストも対象になります。

大規模案件は、複数リージョンや基幹連携、厳格な監査を求める場合の目安です。データ移行、負荷試験、24時間運用を求める場合も、この区分に含めて考えます。

いずれも、リサーチノートをもとにした発注計画用の参考値で、個別見積ではありません。

要件定義・実装・テスト・運用に分けた見積の内訳

費用の比率は案件ごとに異なります。ただし、リサーチノートでは次の内訳を目安としています。

工程別の比率：要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%。
保守運用費：初期開発費の年15〜25%程度が目安です。

実装の比率を下げるより、イベント境界や順序、再送、データ保持、障害復旧を決める要件定義と結合テストを削らないことが大切です。

「設計一式」「テスト一式」とだけ書かれた見積は、作業項目、成果物、担当者、期間に分解してもらいます。

保守運用費は、24時間監視やSRE、障害訓練、セキュリティパッチ、月次レポート、再処理代行の有無によって変わります。

このレンジは、サービスレベルや対応時間を比べるための目安として使います。

メッセージ量と購読数から見るGoogle Cloud利用料

Google公式の料金説明では、Pub/SubのPublishとSubscribeのthroughputが課金対象になります。加えて、リージョンやゾーン間の転送、メッセージ保持ストレージも対象です。

料金の水準と利用量を見積もるには、公式料金の条件を確かめておきます。

Message Delivery Basic：請求アカウントあたり月10GiBまで無料で、その後は40ドル/TiBです。
保持ストレージ：0.27ドル/GiB-monthが目安です（出典: Google Cloud「Pub/Sub pricing」、2026年確認）。
10MiB/s：北米で購読1本は月2,000ドル、2本は3,000ドル（出典: Google Cloud「Pub/Sub pricing」、2026年確認）。
100MiB/s：Subscription数に応じて料金が変わります（出典: Google Cloud「Pub/Sub pricing」、2026年確認）。

北米の例では、Publish throughputが100MiB/sの場合の料金も示されています。Subscriptionが1本なら月額19,760ドル、2本なら29,640ドルです。

小さなメッセージでも、リクエストごとに最低1KBで計算されます。そのため、送信単位や属性の持たせ方も見積条件に含めます。

ここで挙げた例は、日本リージョンの請求額ではありません。為替、無料枠、転送、Cloud Run、BigQuery、Dataflow、監視は含まれていません。

発注時には、平均とピークのメッセージ量、Subscription数、保持日数、リージョン、周辺サービスを入力したうえで、月額の試算を依頼します。

ポイント

費用は、初期開発費、Google Cloud利用料、保守運用費に分け、同じ条件で比べることが判断材料になります。規模別の数字は参考値なので、個別見積で確かめます。

委託先の選定と見積比較の確認項目

「GCP対応」「Pub/Sub構築可能」といった営業文句より、イベント設計、失敗系の実装、運用への引き継ぎができるかを確かめて委託先を選びます。

候補会社には同じRFPを渡し、初期費用、Google Cloud利用料、保守費、追加変更費を分けて提示してもらいます。

会社の規模や認定資格は、参考情報にとどまります。一方で、担当者の経験、提案の具体性、障害時の説明力、納品後の体制は、比べる材料になります。

Pub/Sub固有の質問への回答力

候補会社には、配信の重複や処理失敗、順序、性能についての設計を質問します。

重複・失敗：二重処理の防止、ackのタイミング、Retry、DLQからの再処理。
順序・負荷：順序保証キーの設計、ホットキー対策。
配信保証：Exactly-once delivery、PushとPullの違い、複数リージョンで残る保証。

Google Cloud公式は、ordering keyやExactly-once deliveryの調整が、可用性やレイテンシに影響し得ると説明しています（出典: Google Cloud「Troubleshooting a pull subscription」、2026年確認）。

「機能を有効化すれば解決する」とだけ答える会社は、慎重に比べます。

見積の評価軸としてのセキュリティと引き継ぎ

セキュリティと引き継ぎについては、次の観点をRFPや見積で確かめます。

データの扱い：個人情報は直接載せず、必要なデータを参照するIDだけにする設計を検討する。
クラウドの保護：Topic・Subscription単位の最小権限IAM、サービスアカウント、監査ログ、Secret管理、環境分離、リージョン制約の評価。
追加の制御：必要に応じて、CMEKやVPC Service Controlsの確認。
運用の引き継ぎ：Google Cloudプロジェクト、リポジトリ、Terraform等のIaC、監視、Runbook、テストデータの引き渡し。
契約終了：再委託先の開示と、契約終了時に別会社へ移管できるかの確認。

障害訓練の記録も、引き渡しの対象に含めるかを確かめます。

個人情報保護委員会も、クラウド環境の責任共有モデルと委託先の管理を確認するよう、注意を呼びかけています（出典: 個人情報保護委員会、2024年）。

法令に適合しているかの最終判断は、自社の法務・情報セキュリティ部門と行います。

Google公式の料金ページでは、Pub/Sub Liteの終了日が2026年3月18日と案内されています。そのため、新規案件ではLiteを前提にしません。

発注側は、Pub/SubやGoogle Cloud Managed Service for Apache Kafkaなどを、要件に沿って比べます（出典: Google Cloud「Pub/Sub pricing」、2026年確認）。

安さより前提の揃った見積

総額だけでなく、見積に含まれる作業の差を確かめます。

たとえば、A社は300万円でTopicとSubscriptionの作成のみ、B社は600万円で既存API改修なども含む例があります。

見積条件：メッセージ量、Subscription数、環境数、テスト範囲、稼働時間を揃えること。
追加の比較軸：レビュー回数、クラウド利用料、保守時間帯を、同じ書式で比べること。
抜けの補完：不足項目を加えた再見積の依頼。

B社の例には、Schema、DLQ、負荷試験、監視、運用訓練も含まれます。作業範囲が違うため、A社の方が安いと単純には言えません。

ポイント

委託先は、失敗系の設計や運用への引き継ぎができるかで選びます。見積は作業範囲をそろえて比べ、総額の安さだけで決めないようにします。

よくある質問（FAQ）

発注時は、費用だけでなく、既存業務との接続方法と運用後の責任の線引きも確かめます。相談の前によく聞かれる点を、質問ごとに整理しました。

Google Pub/Subのシステム発注は最低いくらからできますか？

小規模PoCの場合は、300万〜700万円程度が一つの推定レンジです。

これは、接続先が1〜2システムで、認証や再送、冪等性、最低限の監視と検証に絞った場合の目安です。本番運用の24時間監視や複数リージョンは含みません。

要件定義だけを先に依頼すると、実装の前により精度の高い見積を出してもらえます。

自社開発と外注ではどちらが向いていますか？

社内の人員と案件の条件によって、内製、外注、分担のどれを選ぶかが決まります。

自社開発：Google Cloud運用、イベント駆動設計、既存改修、障害対応の人員が揃う場合に可能です。
専門会社へ相談：Pub/Subが初めて、基幹システムを止められない、個人情報や監査要件がある場合は、要件定義やPoCを外注できます。
役割を分担：業務知識は自社、クラウド設計と初期実装は委託先とし、運用を社内へ移管する方法もあります。

RFPがなくてもGoogle Pub/Subの開発を相談できますか？

RFPがなくても相談はできます。現在の業務フローや困っている処理、接続したいシステムを、分かる範囲で伝えます。

あわせて、月間とピーク時の処理量、希望時期、予算上限、セキュリティ制約も共有します。

まずは現状調査・要件定義・PoCの進め方と、その後の概算レンジを分けて提案してもらいます。本開発の確定額は、この段階を経てから求めます。

開発費とGoogle Cloud利用料は別に見積もるべきですか？

まず、課金項目と試算条件を確かめます。

見積を分ける：Google Cloud利用料は初期費用・保守費とは別に見積もります。利用料が発生する場合があります。
Pub/Subの課金対象：Publish・Subscribe throughput、保持ストレージ、リージョン間転送。
周辺サービス：Cloud Run、BigQuery、Dataflow、ログ、監視も利用料が発生する場合があります。
試算条件：平均・ピークのメッセージ量、Subscription数、保持期間を使った試算。
請求差の確認：無料枠や為替の変動を含め、実請求との差が出る条件を確かめる。

まとめ

Google Pub/Subの発注では、設定作業だけでなく、業務イベントを安全に流し続ける仕組みを委託します。

要件が固まらない段階には伴走型やPoCを、確定した範囲には請負を、改善と運用には準委任を組み合わせます。そうすることで、変更に対応しながら責任を整理できます。

発注前に押さえる3つの要点

イベント一覧と非機能要件を作り、重複・順不同・遅延・障害時の扱いをRFPに記載します。

開発費、Google Cloud利用料、保守費は分けて考えます。そのうえで、メッセージ量、Subscription数、保持期間、テスト範囲を揃え、見積を比べます。

委託先は、IAM、監査、個人情報、IaC、Runbookの扱いまで評価します。障害訓練の記録や契約終了後の引き継ぎも確かめ、安さだけで決めないことが大切です。

重要な1イベントのPoCから始める進め方

最初の検証では、対象と委託先を次の2つの観点で決めます。

PoCの対象：全社連携を一度に移さず、受注・在庫・通知など効果とリスクを測りやすい1イベントを選ぶ。
検証と会社選び：正常系・失敗系を試し、複数社の技術説明、業務理解、見積、運用体制、成果物の引き渡しを比べること。

▼全体ガイドの記事
・Google Pub/Subのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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