Google Pub/Subのシステム開発は、業務イベントの定義、方式の選定、障害時の設計、段階的な検証の順に進めると、安定したデータ連携につながります。
要件整理から定着まで6フェーズに分け、各段階で決めることと成果物を示します。費用と見積もりの取り方もあわせて説明します。
▼全体ガイドの記事
・Google Pub/Subのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Google Pub/Subのシステムの全体像
Google Pub/Subは、発行側と処理側を非同期に分けるフルマネージドのメッセージングサービスです。Google Cloud「What is Pub/Sub?」は、典型的な遅延をおおむね100ミリ秒単位と説明しています。出典資料は2026年7月に確認しました。
実際の業務の性能は、Subscriberの処理能力やデータベース、ネットワーク、再送設計によって変わります。
TopicとSubscriptionの使い分け
Publisherは、注文受付や決済サービスなどの発行元で、MessageをTopicへ送ります。
Topicに紐づくSubscriptionは配送先ごとの受け皿で、在庫更新、請求、通知、分析といった用途のSubscriberへ、同じイベントを配信できます。
注文確定イベントは1つのTopicにまとめ、購読先の用途ごとに別のSubscriptionで受けます。
- 在庫用：在庫更新を担当するSubscriber。
- 顧客通知用：顧客への通知を担当するSubscriber。
- BigQuery連携用：分析用のSubscriberへ届けます。
- 処理の分離：通知の停止が在庫処理まで止めてしまう事態を避けられます。
- Message設計：注文IDや発生時刻を持たせ、形式はSchemaで管理します。
設計では、Messageに個人情報や決済情報を直接含めず、必要なデータは安全なデータベースから参照する形にすると、再送・保持・監査のリスクを抑えられます。
Reitan Convenience Swedenでは、Pub/SubとCloud Functionsで分析イベントをBigQueryへストリーミングしています。在庫、マーケティング、顧客体験のデータは、同じイベント源から活用しています。
この事例は、業務処理と分析連携を分け、Subscriptionを展開する考え方の参考になります。ただし、効果は自社へそのまま当てはめず、イベント量と業務KPIを置き換えて検証します（出典：Google Cloud「Reitan Convenience Sweden Case Study」、2026年8月確認）。
重複配信と順不同を前提にする理由
標準配信は少なくとも1回で、Subscriberが期限内にackを返せない場合、同じMessageが再配信される可能性があります。
再配信による二重処理を避けるには、注文IDを使った冪等性の実装が必要です。
- 注文イベントを1件受けたら、注文IDが処理済みかを確認してから在庫を減らします。
- 処理結果とMessage IDまたは業務上の一意キーを同じトランザクションで記録すると、二重登録や二重請求を防ぎやすくなります。
Ordering keyは同じキーの順序を保つ機能です。ただし、特定キーにイベントが集中するホットキーは、滞留や遅延の原因になります。
Exactly-once deliveryは、Pull Subscription向けの機能です。Google Cloudは同一リージョン内の保証と説明しています。なお、PushやExport Subscriptionには対応しません（出典：Google Cloud「Exactly-once delivery」、2026年7月更新）。
重要な処理では、業務キーによる冪等性を決めたうえで、Retry PolicyとDead-letter Topicによる再送の設計と、再処理手順をまとめて設計します。
Google Pub/Subのシステムの進め方
Google Pub/Subの開発は、Topicを作る前に業務イベントと処理責任を定義し、そのうえで構成へ落とし込みます。6フェーズの成果物は、次の段階へ引き継いで使います。
PoCでは、正常系に加えて、重複、遅延、権限エラー、Subscriber停止も検証します。
フェーズ1：要件整理と業務イベントの決定
まず、業務部門と開発会社が、リアルタイム化する処理を決めます。そのうえで、発生条件と後続処理からイベント候補を選びます。
- 候補：受注受付、支払確定、在庫引当、出荷完了など。
- イベント一覧：イベント名、発行元、購読先、必須属性、発生頻度、ピーク件数。
- 運用条件：許容遅延、再処理可否、個人情報の有無、保存期間。
同期処理を残す業務と非同期化する業務は、分けて考えます。たとえば、決済結果の即時表示と、メール通知や分析データ作成を、同じ応答に含める必要はありません。
成果物は、イベントカタログと現行システムの連携図です。加えて、非機能要件と優先順位、PoCの合否基準を用意します。1秒以内や5分以内といった時間、障害時に許容する遅延も、具体的に決めます。
フェーズ2：方式と周辺サービスの選定
処理方式と実行基盤は、Pub/Subと組み合わせる処理の特性に応じて選びます。
- Pull：Subscriberが取得し、処理量を見ながらワーカーを調整します。
- Push：Pub/SubからHTTPSへ送信し、Cloud RunやCloud Functionsで小さな処理を始めやすい方式です。
- Cloud Run：短い処理を、アクセス量に応じて自動でスケールさせる構成です。
- GKE：常時稼働や複雑なネットワーク、細かな制御に向きます。
- Dataflowなど：ストリーム変換やウィンドウ集計に使い、集計先ごとに比べます。
PushはExactly-once deliveryの対象外です。そのため、重複防止が必要な場合は、アプリ側の冪等性を確認します。
集計先の作りを簡素にしたい場合は、BigQuery SubscriptionやCloud Storage Subscriptionも比較の対象になります。
提案書では、Google Cloudに対応しているかだけでなく、選定理由や代替案、クォータ、リージョン、運用担当者まで確認します。
フェーズ3：設計・開発と失敗時の動作の作り込み
設計・開発では、メッセージ形式、処理失敗時の扱い、環境設定を一貫させます。
- メッセージ設計：Message Schemaで形式を定めたうえで、TopicとSubscriptionの命名、属性、最大サイズ、保持期間、ack時点を決めます。
- 再処理設計：一時障害はRetry Policy、恒久的な不備はDead-letter Topicへ振り分けます。
- 環境管理：TerraformなどのIaCで、Topic、Subscription、IAM、監視設定をコードにまとめ、開発・検証・本番を分けます。
- 納品物：ソースコード、IaC、Schema、環境変数一覧、運用手順の提出を求めます。
開発会社は、注文IDなどの冪等キーをどこで発行するかを決めたうえで、処理済み記録を保存するテーブルと、業務データ更新の確定方法を図にまとめます。
SubscriberがDB更新後、ack前に停止した場合も、同じMessageが再配信されたときに更新を二重に行わない仕組みが必要です。
DLQへ移したあとの再処理について、担当者、条件、順序をRunbookに記しておきます。加えて、IaCでコード化しておくと、手作業による設定漏れを減らせます。
フェーズ4：テストによる重複・遅延・障害の再現
本番前の検証では、処理性能と障害時の復旧動作をそれぞれ確かめます。
- 正常系：処理完了までの遅延、ピーク時スループット、Subscriptionの独立性。
- 異常系：再送、ack期限超過、Subscriber停止、DB更新後の停止、権限解除、DLQ移動。
- 監視：未処理数、最古の未ack経過時間、ack latency、再配信数、DLQ件数。
Google Cloudの配信レイテンシ健全性指標では、ack latencyが一貫して30秒未満であることなどが、低遅延の条件とされています（出典：Google Cloud「Monitor Pub/Sub in Cloud Monitoring」、2026年7月確認）。
負荷試験では、平均値だけでなく、ピーク時の95パーセンタイルや復旧時間にも合格値を設けておくと、本番稼働の判断がしやすくなります。
フェーズ5：稼働と段階的な本番切り替え
本番への切り替えは、影響を抑えながら段階的に進め、事前条件と当日の判断を決めておきます。
- 段階稼働：遅延を許容しやすい通知や分析から始め、在庫や受注連携へ広げます。
- 切り替え条件：旧連携との二重発行防止フラグ、ロールバック条件、再送停止条件、窓口、変更時間帯を決めます。
- 当日の確認：発行数と処理数、未ack数、エラー率、DLQ、下流DB更新件数を監視します。
障害時はRunbookに沿い、新規発行を止めるか、Subscriberを止めるか、DLQへ隔離するかを判断します。再処理を急ぐと二重更新を招くため、再処理は手順どおりに進めます。
稼働判定では、技術担当だけでなく業務部門も、注文・在庫・通知の整合性を確認します。
フェーズ6：定着と運用・改善
稼働後は、利用状況の確認、運用教育、導入効果の評価を継続します。
- 月次確認：イベント量、Subscription数、未ack時間、再配信、DLQ、周辺サービス利用量。
- 運用準備：再処理、DLQ、IAM申請、障害連絡、コスト確認の手順書と教育。
- 改善評価：業務KPIとシステム指標を結び、導入効果を説明できる状態にします。
そのうえで、メッセージ増加にSubscriptionが足りない状況や、処理側を増強してもDBがボトルネックになる状況を見える化します。保持期間やOrdering keyも、運用結果から見直します。
少なくとも一度は障害訓練を行い、復旧時間やデータの重複、連絡先の不明点を確かめます。
Google Pub/Subのシステムの費用相場とコストの内訳
費用は、初期開発費とGoogle Cloudの従量課金に分けて考えます。そのうえで、周辺サービス費と保守運用費も加えます。
周辺費用には、Cloud RunやGKE、BigQueryのほか、監視などがあります。Pub/Sub単体で見積もると、処理アプリや転送、監視の費用を見落としやすくなります。
ここに示す金額は、業務システム開発の一般的な工程とPub/Sub周辺の実装範囲から整理した推定レンジです。公開統計ではありません。
初期開発費の目安
費用と期間は、接続する系統の数と周辺システムの工数で規模が変わります。下の区分は、要件や周辺システムの工数を反映した推定レンジで、公表統計ではありません（出典：NotebookLMリサーチノート「Google・Pub・Subのシステム」、2026年8月作成）。
- 小規模PoC：300万〜700万円、3〜4か月程度。
- 中規模：700万〜1,500万円、5〜8か月程度。
- 大規模案件：1,500万〜5,000万円超となる可能性があります。
- 大規模刷新：5,000万〜1億円以上、8〜12か月または1年以上の場合もあります。
小規模PoCは、1〜2システムを接続し、Topic、Subscription、簡単なPullまたはPush、最低限の監視までを行う想定です。
中規模は受注・在庫・通知など3〜6系統を連携し、Schema、DLQ、Cloud RunまたはGKE、既存DB/API連携、監視まで含みます。
大規模案件では、複数リージョンや基幹連携、厳格な監査を含む場合があります。データ移行、負荷試験、24時間運用を含むこともあります。この目安は個別見積もりの代わりにはならないため、連携範囲や運用条件をそろえて確認します。
Google Cloud利用料の変動要因
利用料は、どの料金要素がどの程度使われるかで変わります。公式料金と北米サンプルの条件は、分けて確認します。
- 課金要素：Publish・Subscribeのスループット、リージョン間転送、保持ストレージ。
- 基本単価：Message Delivery Basicは請求アカウントあたり月10GiBまで無料で、超過分は全リージョンで40ドル/TiB。
- 保持料金：0.27ドル/GiB-month。
- 北米サンプル・10MiB/s：Subscription 1本は月2,000ドル、2本は月3,000ドル。
- 北米サンプル・100MiB/s：1本は月19,760ドル、2本は月29,640ドル。
小さなメッセージは、リクエスト単位で最低1KBとして計算されるため、バッチ送信が有効です。単価は、Google Cloud「Pub/Sub pricing」に基づき、2026年8月時点で確認しています。
北米サンプルは、日本リージョンの実請求、無料枠、為替、周辺サービス、ネットワーク転送を含む確定見積もりではありません。
公式資料には、Pub/Sub Liteの非推奨と2026年3月18日の停止が記載されています。そのため、2026年時点の新規案件では、Liteを前提とするのは避けます。
保守運用費に含める範囲
保守費は、作業範囲と対応水準をそろえて見積もります。比較の際は、次の項目を確認します。
- 運用範囲：監視、アラート、DLQ再処理、障害調査、更新、IAM変更、コストレビュー、月次報告。
- 保守費の目安：初期開発費の年15〜25％程度、または初期費用の月額5〜15％程度。
- 見積もり条件：監視指標、通知・一次対応時間、復旧目標、再処理担当、作業時間、追加単価。
24時間監視やSRE、障害訓練の有無で保守費は変わります（出典: NotebookLMリサーチノート「Google・Pub・Subのシステム」、2026年8月作成）。
開発費とクラウド利用料は、分けて試算します。試算表には、月間メッセージ量、平均Messageサイズ、Subscription数を入力します。
試算に保持日数、リージョン、ピーク倍率も加えると、予算の変動要因が明確になります。
Google Pub/Subのシステムの見積もりを取る際のポイント
Pub/Sub案件の見積もりは、TopicやSubscriptionの数だけでは比べられません。そのため、業務イベントや整合性、既存システム接続の条件を各社でそろえます。再処理、セキュリティ、運用引き継ぎについても、同じ条件で提示してもらいます。
RFPや依頼書には、要件、開発会社の実務設計力、セキュリティと契約を具体的に書きます。
要件明確化と仕様書の記載項目
見積もり条件は、データ量や接続先、処理ルール、運用条件といったまとまりで提示します。
- イベントと量：一覧、連携図、想定量、平均・ピークサイズ、発行元、購読先。
- 処理条件：許容遅延、重複ルール、順序保証、保持期間、個人情報、Pull・Push。
- 環境条件：Cloud Run・GKE・Dataflowなどの候補、既存DB/API、リージョン、開発・本番の環境数、テストデータ準備者。
- エラー時：再送、最大試行回数、DLQ条件、手動再処理権限、データ修正、監査ログ保持。
これらが未確定のまま初期見積もりの安さで選ぶと、後から追加開発が発生し、費用と期間が膨らみやすくなります。
複数社比較での開発会社への確認事項
同じイベントを題材に提案を依頼し、設計と運用の実務力を次の観点で比べます。
- 設計質問：重複時の処理、Ordering key、DLQ承認者、Subscriber停止の検知時間。
- 納品範囲：IaC、Runbook、内製化支援、契約後の保守体制。
- 担当実績：類似案件の範囲、周辺サービス、障害対応、担当者の継続性。
- 実績確認：公開情報で判断できない場合は、提案時に対象範囲と担当者を確認。
会社の規模やGoogle Cloudの認定ランクだけで順位をつける必要はありません。Pub/Subの設定経験に加えて、実務設計も比べます。
セキュリティ・契約・リスクの確認項目
セキュリティ要件と責任分界は、将来の引き継ぎも見据えて、明確にしておきます。
- アクセス管理：最小権限、サービスアカウント、Secret、監査ログ、環境分離、Push認証。
- 個人情報：扱う場合は、保存場所、リージョン、保持期間、暗号化鍵、委託先、アクセス記録、削除、再処理を確認します。
- 契約・納品：コード、IaC、Schema、設定、テスト結果、Runbook、再委託、障害連絡、SLA、返却、著作権。
- 移行への備え：代替案やKafkaなどへ移る際に、データ形式を話し合っておきます。
個人情報保護委員会は、クラウド利用時の委託関係や安全管理措置に注意を促しています。
発注側は、クラウド事業者に任せきりにせず、自社の責任分界を契約書に反映します（出典：個人情報保護委員会「クラウドサービス提供事業者が個人情報取扱事業者に該当する場合の留意点」、2024年）。
よくある質問（FAQ）
Google Pub/Subの開発を検討する際によく出る疑問に答えます。費用や方式は、要件によって変わります。
Google Pub/Subのシステム開発は何から始めればよいですか？
まず、受注や在庫などのイベントについて、発行元や購読先、許容遅延、重複時のルールを一覧にします。そのうえで、重要なイベントを1つ選び、小規模なPoCで検証します。
PoCには、Schema、IAM、PullまたはPush、再送、DLQ、監視を含めます。
PullとPushはどちらを選べばよいですか？
処理量に応じてワーカーを制御したい場合はPull、HTTPSエンドポイントへの配信を簡潔に始めたい場合はPushが候補です。
Exactly-once deliveryはPull向けで、Pushでは使えません。そのため、決済や在庫など重複の影響が大きい処理では、冪等キーと処理済み記録も比較対象に入れます。
Google Pub/Subのシステムは月額いくらかかりますか？
料金は、Publish・Subscribeのデータ量、Subscription数、保持期間、リージョン間転送によって変わります。
Cloud RunやGKE、BigQueryなどの周辺サービスと、監視、ログ、保守も合算して考えます。
平均月とピーク月の2パターンで試算します。初期開発費については、小規模PoCで300万〜700万円程度という推定帯がありますが、これは公表統計ではなく、要件に基づく概算です。
開発会社を選ぶときに最も重要な確認事項は何ですか？
開発会社が、業務イベント設計や重複配信への冪等性、Ordering key、RetryとDLQを説明できるかを確認します。障害復旧、IAM、IaC、監視、運用引き継ぎについても、一貫して説明できるかを見ます。
同じサンプルイベントを使って、複数社に提案を求めます。設計の前提、除外範囲、追加費用、保守体制を比べると、見積金額に差が出る理由を判断しやすくなります。
まとめ
Google Pub/Subの開発では、TopicやSubscriptionの作成をゴールにしません。イベントと整合性を定義し、Pull・PushやCloud Run・GKE・Dataflowを選びます。
設計にはSchema、冪等性、Retry、DLQを含め、IAMとIaCも整えます。重複・遅延・障害をテストし、段階稼働と運用改善へつなげます。
進め方で外せないチェックポイント
イベント一覧とPoCの合否基準を作り、重複配信でも二重登録・二重請求を起こさない業務キーを決めます。
費用は初期開発費とGoogle Cloudの従量課金を分け、周辺サービス、保守、障害訓練を含むTCOで比較します。
開発会社にはDLQ再処理、監視、IaC、Runbook、引き継ぎの範囲を確認します。
最初の一歩：対象イベントの絞り込み
全社のデータ連携を一度に作り込まず、受注通知や分析連携など、効果と検証範囲が見えやすいイベントを1つ選びます。
小さな検証で重複、再送、監視、費用を確かめてから対象を広げると、Google Pub/Subを業務に定着させやすくなります。
▼全体ガイドの記事
・Google Pub/Subのシステム開発の完全ガイド
▼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を創業。