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

Google Pub/Subのシステム開発を発注・外注するなら、業務イベントと障害時の動きまで設計できる委託先を選ぶことが重要です。発注費用の目安は、検証用の小規模PoCで300万〜700万円程度、中規模の業務連携で700万〜1,500万円程度ですが、接続する業務数や可用性、運用体制によって変わります。

この記事では、Google Pub/Subのシステムを発注するときの発注形態の選び方、RFPと要件の整理方法、請負・準委任などの契約形態、開発費とGoogle Cloud利用料の見方、委託先の選定と見積比較のポイントを解説します。親記事の基礎解説を読んだうえで、実際に社内稟議やベンダーへの相談へ進みたい方に向けた内容です。

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

Google Pub/Subのシステムを発注する前に知るべき全体像

Google Cloud Pub/Subは、イベントを発生させるPublisherと、イベントを処理するSubscriberを非同期に分離するフルマネージドのメッセージングサービスです。発注時に重要なのは、Pub/Sub自体の設定費ではなく、どの業務イベントを誰が発行し、どの処理が何回受け取っても安全に動くかまでを含めたシステム全体の設計費です。

例えば受注システムが「注文受付」イベントをTopicへ発行し、在庫更新、請求処理、顧客通知、分析基盤がそれぞれ別のSubscriptionで受け取る構成が考えられます。1つのTopicから複数のSubscriptionへ配信するファンアウトによって、処理を分離しやすくなりますが、各処理の完了条件や失敗時の再実行方法は別途設計が必要です。Cloud Run、Cloud Functions、GKE、Dataflow、BigQueryなど、購読側の実行環境までが発注範囲になることが多いです。

Pub/Subの標準配信は少なくとも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では「Google Pub/Subを導入したい」という製品名だけでなく、解決したい業務課題、対象範囲、処理量、品質条件、納品物、運用条件を明記します。候補会社が同じ前提で提案できるように、現在のシステム構成図と業務フローを簡略版でも添付します。仕様を決め切れない項目は未確定と書き、提案時に前提・選択肢・追加費用を分けて提示するよう依頼します。

最低限、「イベント名」「発行元」「Topic」「購読先」「必須属性」「業務キー」「個人情報の有無」「処理の締切」「失敗時の扱い」「再処理の可否」を一覧にします。例えば注文受付イベントなら、注文IDを重複排除キーにし、在庫引当は注文ID単位で一度だけ成立させ、通知は再送されても同じメールを二重送信しない設計を依頼します。発行元と購読先の責任者も決めておくと、障害時に「Pub/Subの問題か、処理アプリの問題か」を切り分けやすくなります。

「リアルタイム」「高可用性」だけでは会社ごとに解釈が変わります。平常時とピーク時のメッセージ数、許容遅延、処理完了までの時間、同時実行数、保持期間、障害時の復旧目標、監査ログの保存期間を、可能な範囲で数値化します。標準配信でよいのか、ordering keyが必要なのか、PullとPushのどちらにするのか、Exactly-once deliveryを使うのかも決めます。Google Cloud公式ドキュメントではExactly-once deliveryはPull Subscriptionに対応し、同一リージョン内の保証として説明されています。複数リージョンで受信する設計では、機能名だけで重複排除を任せない要件にします。

RFPの納品物には、クラウド構成図、Topic・Subscription一覧、Schema定義、IAM設計、アプリケーションコード、IaC、テスト計画と結果、監視ダッシュボード、アラート定義、運用Runbook、教育資料を含めるか確認します。さらに、ソースコードとGoogle Cloudプロジェクトの所有者、リポジトリ、サービスアカウント、秘密情報の管理主体を発注側に置くのかも明記します。提案会社には、標準機能で対応する部分、追加開発する部分、将来拡張のために保留する部分を分けて書いてもらうと、見積比較が容易になります。

契約形態と開発の進め方はどう設計しますか？

契約では、要件の変動がある工程と、成果物を確定できる工程を分けて考えます。要件定義を準委任、基本設計以降を請負にする方法もありますし、全体を準委任で進めてスプリントごとに成果を確認する方法もあります。どちらを選んでも、変更管理、受入条件、知的財産、瑕疵や障害対応、再委託、契約終了後の引き継ぎを契約書と個別仕様書に落とし込むことが大切です。

Pub/Sub案件では、要件定義の段階で「注文受付」と呼んでいたイベントが、業務部門との議論で「支払確定」と「注文確定」に分かれることがあります。初期段階から全機能を固定価格で請負にすると、変更のたびに追加見積が発生し、発注側と受注側の認識が対立しやすくなります。まず現状調査とPoCを準委任で実施し、イベントモデル、非機能要件、受入基準が固まった後に本開発を請負で発注すると、予算と責任の線引きを行いやすいです。

最初のPoCでは、重要なイベントを1つか2つに絞り、PublisherからSubscriberまでの正常系と失敗系を確認します。認証、Schema、PullまたはPush、ackのタイミング、重複排除、DLQ、監視、負荷の実測を行い、単なる疎通確認で終えないことが重要です。本開発では対象業務を広げ、環境分離とIaCを整えます。移行では段階的に旧連携と新連携を切り替え、運用ではバックログ、ack latency、エラー率、再処理件数を見ながら改善します。

受入テストでは、メッセージが届いたかだけでなく、重複しても業務結果が一つになるか、処理側が停止しても再開できるか、DLQから安全に戻せるかを確認します。発注側は業務上の正解とデータの受入条件を持ち、委託先は構成・コード・テスト・運用手順を説明できる状態にします。Google Cloudの利用料、アプリケーションの稼働費、監視費、障害対応費を誰が負担するかも、開発費とは別に確認しておく必要があります。

Google Pub/Subのシステム発注費用と相場はいくらですか？

Google Pub/Subの受託開発費に関する国内横断統計はほとんどないため、次の金額は業務システム開発の一般的な工程と、Pub/Sub周辺に必要な設計・実装・テストをもとにした推定レンジです。実際の見積では、接続システム数、メッセージ量、既存APIやDBの改修、セキュリティ要件、負荷試験、移行、運用時間を確認します。Google Cloudの利用料は開発会社への初期費用とは別に計算します。

小規模PoCは、1〜2システムを接続し、Topic・Subscription、簡単なPullまたはPush、認証、最低限の監視と検証を行う範囲で、300万〜700万円程度、期間は3〜4か月が一つの目安です。これは本番の全機能を完成させる金額ではなく、メッセージ仕様、再送、冪等性、処理性能、障害時の挙動を見極めるための費用です。

受注・在庫・通知など3〜6系統を連携し、Schema、DLQ、Cloud RunまたはGKE、既存DB/API連携、監視、結合テストまで含める中規模案件は、700万〜1,500万円程度、5〜8か月が推定レンジです。複数リージョン、基幹連携、厳格な監査、データ移行、負荷試験、24時間運用まで求める大規模案件は、1,500万〜5,000万円超となることがあり、大規模刷新では5,000万〜1億円以上、8〜12か月以上の計画になる場合もあります。いずれも個別見積ではなく、リサーチノートに基づく発注計画用の参考値です。

費用の比率は案件によって変わりますが、リサーチノートでは要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%が一つの内訳目安です。Pub/Sub案件では実装の比率だけを下げるより、イベント境界、順序、再送、データ保持、障害復旧を決める要件定義と結合テストを削らないことが重要です。見積書に「設計一式」「テスト一式」とだけある場合は、作業項目と成果物、担当者、期間を分解してもらいます。

保守運用費は、一般的な業務システムの目安として初期開発費の年15〜25%程度、または月額で初期費用の5〜15%程度とされることがあります。ただし、24時間監視、SRE、障害訓練、セキュリティパッチ、月次レポート、再処理代行を含むかで大きく変わります。この数字も一律料金ではなく、サービスレベルと対応時間を比較するためのレンジとして扱います。

Google公式の料金説明では、Pub/Subの課金要素はメッセージのPublish・Subscribe throughput、リージョンやゾーンをまたぐデータ転送、メッセージ保持ストレージの3つです。Message Delivery Basicは請求アカウントあたり月10GiBまで無料で、その後は40ドル/TiBと説明されています。メッセージを保持するストレージは0.27ドル/GiB-monthが目安です（出典: Google Cloud「Pub/Sub pricing」、2026年確認）。小さなメッセージでもリクエストごとに最低1KBで計算されるため、送信単位や属性の持たせ方も見積条件になります。

Google公式の北米サンプルでは、Publish throughputが10MiB/s、Subscriptionが1本の場合のPub/Sub月額を2,000ドル、2本の場合を3,000ドルとしています。100MiB/sでは1本19,760ドル、2本29,640ドルという例です（出典: Google Cloud「Pub/Sub pricing」、2026年確認）。これは日本リージョンの請求額や為替、無料枠、転送、Cloud Run、BigQuery、Dataflow、監視を含まないサンプルです。発注時は、平均とピークのメッセージ量、Subscription数、保持日数、リージョン、周辺サービスを入力した月額試算を提出してもらいます。

委託先の選定と見積比較では何を確認しますか？

委託先は「GCP対応」「Pub/Sub構築可能」という営業文句だけで決めず、業務イベントを設計し、失敗系を実装し、運用へ引き継げるかを確かめます。候補会社には同じRFPを渡し、初期費用、Google Cloud利用料、保守費、追加変更費を分けて提示してもらいます。会社の規模や認定資格は参考になりますが、最終的には担当者の経験、提案の具体性、障害時の説明力、納品後の体制を比較することが重要です。

候補会社には、同じメッセージが2回届いた場合の二重処理防止、ackのタイミング、処理失敗時のRetry、DLQからの再処理、順序を保証するキーの設計、ホットキー対策を質問します。Exactly-once deliveryを使えばすべての重複が消えるのか、PushとPullで何が変わるのか、複数リージョンでどの保証が残るのかも説明してもらいます。Google Cloud公式は、ordering keyやExactly-once deliveryのための調整が可用性やレイテンシに影響し得ると説明しています（出典: Google Cloud「Troubleshooting a pull subscription」、2026年確認）。「機能を有効化すれば解決します」という回答だけの会社は慎重に比較します。

個人情報や決済に関係するイベントでは、メッセージに個人情報を直接載せず、必要なデータを参照するIDだけにする設計を検討します。Topic・Subscription単位の最小権限IAM、サービスアカウント、監査ログ、Secret管理、環境ごとのプロジェクト分離、リージョン制約、必要に応じたCMEKやVPC Service ControlsをRFPの評価項目にします。個人情報保護委員会も、クラウド環境では責任共有モデルや委託先の管理を確認するよう注意喚起しています（出典: 個人情報保護委員会、2024年）。法令適合の最終判断は自社の法務・情報セキュリティ部門と行います。

見積比較では、納品後に自社が運用できるかも確認します。Google Cloudプロジェクト、リポジトリ、Terraform等のIaC、監視設定、Runbook、テストデータ、障害訓練の記録を引き渡すか、再委託先を開示するか、契約終了時に別会社へ移管できるかを確認します。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改修、Schema、DLQ、負荷試験、監視、運用訓練まで含むなら、単純にA社が安いとは言えません。見積の前提メッセージ量、Subscription数、環境数、テスト範囲、稼働時間、レビュー回数、クラウド利用料、保守の時間帯を同じ書式で並べ、抜けている項目を追加した再見積を依頼します。

よくある質問（FAQ）

Google Pub/Subの発注では、費用だけでなく、既存業務との接続方法と運用後の責任分界を確認することが重要です。ここでは、相談前に特に質問されやすいポイントを整理します。

小規模PoCとして依頼する場合は、300万〜700万円程度が一つの推定レンジです。ただし、接続先が1〜2システムで、認証、再送、冪等性、最低限の監視と検証に絞った場合の目安であり、本番運用の24時間監視や複数リージョンを含む金額ではありません。要件定義だけを先に依頼すれば、実装前により精度の高い見積を作成しやすくなります。

Google Cloudの運用経験、イベント駆動設計、既存システムの改修力、障害対応の人員が社内に揃っていれば自社開発も可能です。一方、Pub/Subを初めて使う、基幹システムを止められない、個人情報や監査要件がある場合は、専門会社に要件定義やPoCを外注し、運用を社内へ移管する進め方が現実的です。全面外注か全面内製かの二択ではなく、業務知識は自社、クラウド設計と初期実装は委託先という分担も選べます。

相談できます。RFPがない場合は、現在の業務フロー、困っている処理、接続したいシステム、月間とピーク時の処理量、希望時期、予算の上限、セキュリティ制約を分かる範囲で伝えます。委託先には、いきなり本開発の確定額を出してもらうのではなく、現状調査・要件定義・PoCの進め方と、その後の概算レンジを分けて提案してもらうと安全です。

別に見積もるべきです。開発会社への初期費用や保守費に加え、Pub/SubのPublish・Subscribe throughput、保持ストレージ、リージョン間転送、Cloud Run、BigQuery、Dataflow、ログと監視の利用料が発生する可能性があります。平均とピークのメッセージ量、Subscription数、保持期間を前提にした月額試算を作成し、無料枠や為替の変動を含めて、実請求との差が出る条件も確認します。

まとめ

Google Pub/Subのシステムを発注するときは、サービスの設定作業ではなく、業務イベントを安全に流し続ける仕組みを委託する意識が重要です。要件が固まっていない段階では伴走型やPoC、仕様が固まった範囲では請負、改善と運用では準委任を組み合わせると、変更に対応しながら責任を整理できます。

第一に、イベント一覧と非機能要件を作り、重複・順不同・遅延・障害時の扱いをRFPへ入れます。第二に、開発費とGoogle Cloud利用料、保守費を分け、メッセージ量、Subscription数、保持期間、テスト範囲が揃った見積を比較します。第三に、IAM、監査、個人情報、IaC、Runbook、障害訓練、契約終了後の引き継ぎを評価し、安さだけで委託先を決めないことが大切です。

いきなり全社の連携を移行するのではなく、受注・在庫・通知など、効果とリスクを測りやすい1イベントを選び、正常系と失敗系を検証することをおすすめします。PoCの提案を複数社から取り、技術説明だけでなく、業務理解、見積の透明性、運用後の体制、成果物の引き渡し方まで比較すると、自社に合う委託先を選びやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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