松葉/ Matsuba
クラウド基盤構築レポート
松葉 / Matsuba（社外取引先と社内ユーザの業務ファイル共有を Web アプリで完結させるための社内基盤）の本番クラウド環境を、Google Cloud + Supabase + Resend + GitHub の組み合わせで構築しました。本資料は、その構築内容（11 個の操作手順）を、図と表で 1 ページずつ可視化したものです。
今回構築した構成要素の規模感By the numbers
手順 00〜10 で実際に作成・設定したクラウドリソースの内訳です。一つひとつは小さくても、相互に紐付けて動かす必要があり、漏れがあると本番では即障害になります。
Cloud Run
4 + 1サービス / ジョブ
Web / API / Drive 同期 / ウイルススキャン の 4 サービスに加え、定期処理用の Cloud Run Jobs（コンテナをスケジュール起動するサーバレス基盤）を 1 個。
Service Accounts
7個
用途別にサービスアカウント（アプリが Google Cloud にアクセスする際の身分証）を分離。鍵ファイル（JSON）は 1 つも発行していません。
Pub/Sub Topics
13 + 13主 / DLQ
業務イベント（アップロード完了 / スキャン結果 等）を流すトピックを 13 種類と、配信失敗時の退避先（Dead Letter Queue、DLQ）を同数。
Buckets & Secrets
5 + 7バケット / シークレット
Cloud Storage（ファイル置き場）のバケットを役割別に 5 種、Secret Manager（パスワード金庫）に登録した接続情報・API キーを 7 種。
11 個の構築手順Eleven steps we completed
各手順を 1 ページずつにまとめました。順番に読むと、外側（プロジェクト枠 / 認証）→ 中（実行基盤 / ストレージ / メッセージング）→ 入口・監視 という流れで全体像が掴めます。
Google Cloud プロジェクトProject & APIs
本番プロジェクト Matsuba（ID: <project-id>）を東京リージョンに作成し、Cloud Run / Storage 等の API（外部からクラウドを操作するための窓口）を 19 種類有効化しました。
Supabase PostgresDatabase backbone
データベースは Supabase（マネージド PostgreSQL）の Pro プラン（東京）。毎日バックアップ + PITR（任意時点に巻き戻せる機能）が有効。アプリ用と移行用の 2 つの接続文字列を取得しました。
読む 02 · MailResend ドメイン認証Outbound email
招待 / OTP / 共有リンク等のメール送信は Resend（メール配信 SaaS）。社内共用ドメイン mail.example.com を再利用しつつ、件名・送信者名・本文ロゴで「松葉から」と分かるよう整えました。
Google 共有ドライブと SA 7 種Identities
Drive 同期先の共有ドライブ「社内アーカイブ」を確保し、用途別に 7 種類のサービスアカウントを作成。Drive 同期 SA だけが共有ドライブの「コンテンツ管理者」になります。
読む 04 · OAuthGoogle OAuth クライアントSign-in with Google
Google ログイン用の OAuth クライアント ID を発行し、同意画面に 松葉のブランド（アプリ名・ロゴ・利用規約 URL）を設定。社内（@example.com）と社外で同じクライアントを共用します。
GitHub Actions + WIFKeyless deploy
GitHub Actions（CI/CD = ソースコード変更時の自動デプロイ）から GCP へは Workload Identity Federation（WIF）でキーレス認証。鍵ファイルを発行せず、リポジトリ単位で身元を限定しました。
読む 06 · Runtime + SecretCloud Run + Artifact Registry + Secret ManagerRun, store, secret
Cloud Run（コンテナをリクエスト都度起動するサーバレス）に 4 サービスを空デプロイ（後続手順が URL を必要とするため）。同時に Secret Manager に 7 個のシークレットを SA 単位の最小権限で配置。
読む 07 · StorageCloud Storage バケット 5 種Defense-in-depth storage
役割別に 5 種類のバケット（未検査 / 検査済み / 隔離 / ミラー（ウイルス定義） / 共有 ZIP）に分離。誤動作で隔離ファイルが復活しないよう、API 用 SA には隔離バケットへのアクセス権限を与えていません。
読む 08 · MessagingPub/Sub + Eventarc + Cloud TasksAsync backbone
業務イベント用に 26 トピック（主 13 + DLQ 13）、22 サブスクリプション、ストレージ変更を即座にスキャナに連携する Eventarc トリガを 1 個。配信失敗を取りこぼさない設計です。
読む 09 · EdgeLoad Balancer + Cloud Armor + DNSPublic entrance
本体 portal.example.com と共有リンク受取 inbox.portal.example.com の 2 ホストを 1 つの LB で配信。Cloud Armor（WAF）で OWASP 6 種 + IP レート制限を多層適用しました。
Monitoring + Alert + BillingObservability
Cloud Monitoring（GCP 標準の監視基盤）でメール通知チャネルとアラートを設定し、Cloud Billing（請求）の月予算も設定し、予算に近づいたとき・達したとき・超えたときの 4 段階で通知が飛びます。
読む Overview全体クラウド構成図One-page architecture
11 個の手順で作ったリソースが、本番でどう連動するかを 1 枚の SVG 構成図にまとめました。「個別の手順を読む前に俯瞰したい」「読み終わってから整理したい」のどちらでも使えます。
図で見る本構築で意識した 4 つの設計方針Four design principles
手順の細部に入る前に、全体を貫いている設計の考え方をお示しします。「なぜこれだけ手数が要るのか」が腹落ちする補助線として読んでください。
鍵を 1 つも発行しない
GitHub Actions → GCP は Workload Identity Federation でキーレス。Cloud Run はサービスアカウントを直接アタッチ。Drive 同期も SA をメンバー追加するだけ。JSON 鍵ファイルが 1 つも社内 PC に残らない構成です。
多層で守る
外側から順に Cloud Armor（WAF + IP レート制限） → Load Balancer → アプリ層の認証ミドルウェア → データベースの行レベルセキュリティ（RLS） の 4 層。1 層でも抜けても次の層が止めます。
イベントを取りこぼさない
Pub/Sub（メッセージング基盤）は配送保証が「最低 1 回」のため、受信側で重複排除し、失敗は DLQ（退避キュー）へ。13 トピック全てに DLQ を 1 対 1 で用意し、後で手動再投入できる構成です。
異常コストは即気付ける
月予算に対して、近づいたとき・達したとき・超えたときの 4 段階で通知。min=0 のスケール（ジョブ系はアイドル時 0 円）とレート制限の組み合わせで、攻撃・暴走による課金事故を構造的に抑えます。
本資料の読み方How to read
推奨の読み順: まず「全体構成」を見て俯瞰 → 関心のある手順ページを開く、の順がおすすめです。手順 00〜10 は依存関係順に並んでいます。
専門用語について: 本文中で初めて登場する専門用語には括弧で日本語の補足を添えています（例: Cloud Run（コンテナを HTTP リクエスト毎に起動するサーバレス基盤））。kintone / GAS で言うところの「テーブル」「フォーム」「アクセス権」に近い概念は、できるだけ対応関係も示しました。
次のページ: 全体クラウド構成図（11 手順で作ったリソースの繋がりを 1 枚に圧縮しました）