#3 脱・エグレス破産！音声ホスティングの救世主「Cloudflare R2」採用と、爆速MVP開発への技術的決断

GCPアカウント作成は「Googleグループ」ではできない/静かなるコスト爆弾：「エグレス破産」の恐怖/AIも教えてくれなかった救世主：Cloudflare R2と「出口料金ゼロ」という革命/便利さとのトレードオフ：自前でRSSフィードを育てる覚悟/未来のためのアーキテクチャ：なぜ「モノリシック」な設計を避けたのか1. インフラ基盤の確立と独自ドメインの導入開発の足がかりとして、まずはGoogle Cloud Platform (GCP) のアカウント運用体制が整備されました。当初の想定とは異なり、GCPの組織アカウント作成には独自ドメインが必須であることが判明したため、急遽「sunabalog.com」を取得。Google Workspace経由で正式な管理体制を構築しました。 特筆すべきは、今後のアカウント管理方針についての議論です。「すべてのサービスを独自ドメインのアカウントに紐付けるべきか」という点について検討されましたが、プロジェクトの立ち上げスピードを優先し、過度な管理ルールで縛ることは避け、GCPの利用が本格化するまでは現状維持とする柔軟な判断が下されました。2. 技術的ブレイクスルー：Cloudflare R2の採用本会議のハイライトと言えるのが、音声ファイルのホスティング先選定です。ポッドキャスト配信において、音声データの保管場所はコストと利便性を左右する最重要課題です。 調査の結果、主要な配信先であるSpotifyのAPIには音声ファイルアップロード機能がないことが判明し、自前でのホスティングが不可避となりました。しかし、ここで以下の3つの壁に直面しました。i. GCP (Google Cloud Storage) の壁: 利便性は高いが、ポッドキャストの再生（ダウンロード）ごとにデータ転送量（エグレス）課金が発生するため、人気が出れば出るほどコストが跳ね上がる「エグレス破産」のリスクがある。ii. SaaS (Transistor.fm等) の壁: 機能は豊富だが、月額固定費がかさみ、収益化前の初期プロジェクトには負担が大きい。iii. 解決策としての「Cloudflare R2」: チームは一般的なAI検索等の提案に留まらず、「データ転送量無料」という観点で独自調査を深堀りしました。その結果、AWS S3互換でありながらエグレス料金が完全無料である「Cloudflare R2」を発見しました。これにより、将来的にどれだけ再生数が増えても配信コストをほぼゼロに抑えられるという、プロジェクトの持続可能性を劇的に高める決定がなされました。この選定は、コスト要件に対する解像度の高い技術的勝利と言えます。iv. MVPアーキテクチャ：理想より速度を優先システム構成に関しては、「拡張性」と「開発速度」のトレードオフについて熱い議論が交わされました。 当初案として提示されたのは、Cloud Run Jobsを活用し、処理ごとにコンテナを分割するマイクロサービス的な構成でした。これは将来的なメンテナンス性や並列処理には優れていますが、初期構築の工数が膨らむ懸念がありました。 議論の結果、今回はあくまでMVP（実用最小限の製品）であることを再確認。「まずは動くものを作り、価値を検証する」ことを最優先し、単一のCloud Functions内にすべてのロジック（GCSトリガー検知、Gemini 1.5 Proによる文字起こし・要約、R2アップロード、RSS更新、Discord通知）を集約するシンプルなアーキテクチャを採用しました。将来的なリファクタリング（Cloud Runへの移行）を見据えつつも、まずはプロトタイピングの速度を最大化する戦略的撤退を選択しました。4. 次回へのアクションと展望技術的な方針がすべて固まったことで、開発タスクは以下の3名に明確に割り振られました。- かずもり氏: Terraformを用いたインフラコード化（GCPおよびCloudflare R2の連携）。- 高島氏: Gemini 1.5 Proへの指示出しとなるプロンプトエンジニアリングおよび、各プラットフォームに対応したHTMLタグの仕様調査。- おの氏: Cloud Functionsで動作するアプリケーションロジックの実装。本会議により、プロジェクトは「何をどう作るか」という机上の空論から、「誰がいつまでに作るか」という実行フェーズへと完全に切り替わりました。次回会議では、これら3つのピースが統合され、実際にポッドキャストが自動生成されるプロトタイプが披露される予定です。[Github]: https://github.com/sunabalog/podcast-automator.git