sunabalog

「30 days to build」プロジェクト：ポッドキャスト自動化システム構築編 第4回進捗報告今回は、私たち3人が1ヶ月でITプロジェクトのプロトタイピングを行う企画「30 days to build」の進捗報告回です。現在取り組んでいるのは、このポッドキャスト「sunabalog」自体の制作・配信ワークフローを完全自動化するシステムの構築。第4回となる今回は、AIによるコンテンツ生成、GCP上のインフラ構築、そしてアプリケーション実装のすべてにおいて、実装レベルでの大きなブレイクスルーがありました。Gemini 1.5 Proの実力、Cloud Jobsを採用したサーバーレス構成、そして開発プロセスの透明化など、技術的な詳細を余すところなく語ります。1. プロジェクト管理と「思考の痕跡」開発を円滑に進めるため、GitHub Organizationへの移行を行いました。これにより、リポジトリや権限の管理が柔軟になり、チーム開発の基盤が整いました。特に注目したいのはGitHub Projects（カンバンボード）の活用法です。単なるタスク消化のチェックリストとしてではなく、開発プロセスや試行錯誤の「思考の痕跡」を残すナレッジベースとしてイシューを活用しています。これはリスナーの皆さんが私たちの開発を追体験できるようにするための工夫でもあります。2. 新カバーアート公開：「三人寄れば文殊の知恵」ポッドキャストの顔となるカバーアートを刷新しました。「3つの脳」をメインビジュアルに据え、背景には「砂場」の画像をドットパターン化したデザインを採用。生成AI任せにするのではなく、意図を込めたデザインプロセスを経て、「sunabalog」のアイデンティティを視覚化しました。3. AI実装：Gemini 1.5 Proの衝撃（担当：高島）音声ファイルから議事録、タイトル、概要文を生成するモジュールにおいて、Vertex AIの「gemini-1.5-pro-preview」モデルを採用しました。特筆すべきはその「話者分離能力」です。プロンプトで名前を指定していないにもかかわらず、音声の特徴だけで「高島」「かず森」といった話者を漢字表記まで正確に認識しました。gemini-1.0-proやNotebookLMでは難しかったこの精度は、実用化に向けた大きな一歩です。一方で、生成される目次（タイムスタンプ）が実際の音声時間とズレるという「ハルシネーション」の課題も浮き彫りになり、プロンプトエンジニアリングによる解決を模索しています。4. インフラ構築：Cloud FunctionsからCloud Jobsへ（担当：かず森）GCP上のインフラストラクチャは、Terraformによってコード化（IaC）され、dev/prod環境の構築が完了しました。アーキテクチャ上の大きな決断として、実行環境を当初予定していたCloud Functionsから「Cloud Jobs」へ変更しました。GCSへのファイルアップロードをトリガーにEventarcが発火し、WorkflowsがCloud Jobsを制御する構成です。これにより、ジョブをキックするためだけの無駄なコントローラー（HTTPサーバー）を排除し、真にサーバーレスで効率的なパイプラインを実現しました。今後はCI/CDの整備と、外部APIキーなどのクレデンシャル管理の強化が課題となります。5. アプリケーション実装：モジュールの完成（担当：自分）システムのコアとなる機能モジュールの実装が進みました。コストパフォーマンスに優れたCloudflare R2をストレージとして採用し、GCSとの連携を確認。また、RSSフィード生成機能や、長文対応したDiscord通知機能なども個別のモジュールとして完成しています。現在は各パーツが独立して動いている状態ですが、これらを一本のパイプラインとして繋ぎ込む結合テストが次なるステップです。今後の展望個々の技術要素は出揃いました。残るはこれらを結合し、実際に音声を投入してRSSが配信されるまでのエンドツーエンド（E2E）テストを成功させること。そして、継続的な開発のためのCI/CDパイプラインの確立です。自動化されたシステムが初めてエピソードを吐き出す瞬間を目指し、ラストスパートに入ります。【目次】※タイムスタンプは議論の区切りを示す目安です。0:00 オープニングトークとプロジェクト管理手法5:10 新しいカバーアートお披露目！デザインに込めた想い9:30 進捗共有①：Gemini 1.5 Proはどこまで使える？AIコンテンツ生成のリアル18:45 進捗共有②：GCPインフラ構築完了！TerraformによるIaCの勘所35:12 進捗共有③：Cloudflare R2とドメイン導入、バックエンド実装状況48:20 全体の振り返りと次回の予定（大晦日配信！？）関連リンク:sunabalog GitHubリポジトリ: https://github.com/sunaba-log/podcast-automator.git今回の技術スタック: Vertex AI, Google Cloud (Cloud Jobs, Workflows, Eventarc), Terraform, Cloudflare R2, Python

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

今回のスナバログは、記念すべき第1回配信の「振り返り」と、エンジニアらしく「配信作業を技術で解決しよう」という自動化プロジェクトの立ち上げについてお話ししています。------------------------------------------前回の反省会：意外と好評？でも課題も山積み まずは恐る恐る公開した第1回配信のフィードバックからスタート。- 「早口な語り口がAIっぽくなくて逆に良い」という嬉しい評価- BGMがないことによる「無音の緊張感」問題- 自分の声を聞いた時のなんとも言えない違和感など、リアルな感想を共有しました。とりあえず、編集の手間を増やさないためにBGMはまだ見送りますが、「タイトルコール」くらいは入れて番組っぽくしよう！という結論になりました。ちなみに初回のユニークリスナーは6名でした。聞いてくれた方、本当にありがとうございます！------------------------------------------現状の泥臭い作業工程（As-Is） 実は今の配信、裏側ではかなり手作業なんです。音声を録音して、NotebookLMに食わせて文字起こしして、タイトルと説明文を考えて、Spotify for Podcastersに入稿して…というフローを回しています。「エンジニアなら、ここも自動化したいよね？」ということで、プロジェクトが動き出しました。------------------------------------------GCP × Gemini で目指す「完全自動化」（To-Be） 目指すは「音声ファイルをアップロードするだけ」で、文字起こしから配信公開まで完了する世界。 技術選定の結果、AWSやAzureではなく、Google Cloud Platform (GCP) を採用することに決定しました！- Gemini APIとの親和性が高い- チームとしての新しい技術習得（リスキリング）これらを理由に、GCP上に自動化パイプラインを構築していきます。次回からはいよいよ開発フェーズへ。GitHubでタスク管理しながら進めていく様子も共有していきますので、開発の裏側にご興味ある方もぜひお聴きください！

私たちが目指すポッドキャストの核となるコンセプトを改めて議論し、ついにチャンネル名を決定しました。1. 番組コンセプトの最終決定前回のエピソードで残っていたコアコンセプトは、「妄想と実装」でした。これは、「ノリと現実」という表現でも試されましたが、本質的な構造は変わらないと認識されています。• 構造：楽しげな雰囲気を漂わせるA（妄想/ノリ）と、必ず現実に返してくるB（実装/現実）という対比で構成されています。• 形式：「アイディエーション型ポッドキャスト」であり、目標は「1ヶ月で何かは作る」こと。前半でアイデアを断（議論）し、後半で実際に作ったり作らなかったりするプロセスを追います。このコンセプトをより分かりやすく砕けた表現にする試みとして、「口だけと手だけ」という案も出ましたが、「逆だろ」となり不採用となりました。また、「実装」という言葉がエンジニア以外には馴染みが薄い（「実装って何？」と聞かれる可能性がある）という問題意識も共有されました。2. チャンネル名の選定と「スナバログ」の意味コンセプトと方向性（テックからあまり離れていない系）に合致し、かつ自分たちのテンションが上がるような単語を模索しました。検討されたチャンネル名候補：• WPラジオやRebuildなどの既存のテック系チャンネル名や、サンドボックス（Sandbox）、月刊サンドボックス、ローカルサンドボックス など、実験環境を示す単語が多く挙がりました。• 「月刊」という単語は、毎週やるが4週分で1巻（1プロダクト）分ぐらいの内容になるというコンセプト表現に繋がるとして評価されました。• 冗談交じりの案として「スナバカレー」 や「デンジャラス兄さんズ」 も出ましたが、前者は「カレー」が意味不明であること、後者は世代が限定されすぎるとして見送られました。決定したチャンネル名：「Sunaba log」（スナバログ）最終的に、「スナバログ」が採用されました。• 「スナバ」の意味：「砂場」はサンドボックスを連想させ、本番環境ではなく、作ったり壊したりするのが容易にできる実験環境を意味します。• 「ログ」の意味：ブログやVログにも通じる現代的な「記録」であり、コンピューター用語の「ロギング」の意味合いも込めています。• 雰囲気：小文字の「sunaba log」というローマ字表記 にすることで、モダンで新鮮な印象を与えつつ、「大人が砂場で遊んでいる」ような、テック寄りの内容を少し砕けた雰囲気で展開する意図が込められています。3. 今後の展望と次回予告チャンネル名が「スナバログ」に決定したことを受け、今後の技術的な取り組みについても議論しました。• プロセス重視：一般的に「成果物（生物）」に興味があるリスナーが多い中で、「サンドボックス」を名に冠することで、プロセスの試行錯誤に興味があるエンジニア層などにも訴求したいと考えています。• 技術的な検討：音声ファイルの形式（WAV、AAC、FLAC、MP4など）や、アップロード先での互換性について確認を行い、リスナーに最適な形でコンテンツを届ける準備を進めます。• 次回予告：次回は、今回決定したチャンネル名でアップロードした音声を聞き返し、音質の確認、および文字起こしの精度確認を行う予定です。コンセプト「妄想と実装」を掲げ、「Sunaba log」として歩み始める私たちの記録を、ぜひお楽しみください。