sunabalog

Sunaba Log
  • 5.0（1）
  • テクノロジー
  • アップデート：毎週

「妄想」から「現実」へ繋がるアイディエーション番組。 「1ヶ月で何かは作る」という具体的な目標を掲げ、アイデアの生成から実装までを追います。前半で自由なアイデアを議論し、後半ではそれを現実に引き戻す形で、実際に物を作ったり、作らなかったりする過程を配信します。

エピソード

  1. #7 「作りたい」を貫くプロダクトアウト宣言／アニメ・映画から未来を逆算する新企画／ポッドキャスト自動化基盤、ついに本番リリースへ

    2日前

    #7 「作りたい」を貫くプロダクトアウト宣言／アニメ・映画から未来を逆算する新企画／ポッドキャスト自動化基盤、ついに本番リリースへ

    【エピソード概要】  「雑談が楽しい」から始まった僕らのポッドキャスト。しかし、回を重ねる中で「本当に作りたいもの」「僕らならではの価値」とは何かという問いに直面しました。今回は、メンバーそれぞれがプロジェクトに何を求めているのか（サービス開発？技術探求？それともアイデアを出すこと自体？）、その根源的な動機を率直に語り合います。 議論は、いつもの雑談からアイデアが生まれるスタイルから一歩踏み込み、「僕らだけのアイディエーション手法をデザインできないか？」という壮大なテーマへと発展。市場調査や課題解決からスタートする一般的なプロダクト開発（マーケットイン）とは一線を画し、利益や需要よりも「自分たちが心の底から面白いと思えるか」を追求する「プロダクトアウト」の精神こそが、僕らの原動力であると再確認します。その精神は、かつて『ニコニコ技術部』で見たような、利益度外視でアニメのガジェットを本気で再現するような純粋な探求心に近いのかもしれません。 その具体的なアプローチとして浮上したのが、「SFプロトタイピング」や「スペキュラティブデザイン」という考え方。未来の社会やテクノロジーを空想し、そこから逆算して「今作るべきサービス」を考えるこの手法は、まさに僕らの探求心に火をつけるものでした。 もちろん、この「趣味としての探求」は、サーバー代などの現実的なコストという壁にいずれ直面するかもしれません。利益を追求し始めると、僕らが大切にしたい「面白い」という純粋な動機が揺らいでしまうのではないか――そんなジレンマも率直に語りながら、それでも今は純粋な好奇心を優先することに。 次回の活動として、各々が好きなSF作品を持ち寄り、その世界観からプロダクトを妄想してみることに。アニメや映画の”あのガジェット”をただ再現するのではなく、「その本質は何か」をエンジニアの視点で突き詰め、核となる要素を現実世界に実装してみる。技術的な制約や収益性を一旦脇に置き、純粋な「面白い」を追求する僕らの知的冒険が、ここから始まります。 【目次】  5:00 雑談が楽しい理由と、僕らの目的  12:00 僕らだけの「アイデア発想法」をデザインする  18:00 SFプロトタイピングとは？未来から逆算するサービス開発  35:00 次回予告：「好きなSF作品からプロダクトを考えよう！」の前にPodcast 管理システムの要件定義をします。 【about us】

    43分
  2. #6 開発のモチベーションはどこにある？/「バイブコーディング」と「堅実な設計」の溝／なぜ動画全盛期にあえてポッドキャストを選ぶのか？

    1月7日

    #6 開発のモチベーションはどこにある？/「バイブコーディング」と「堅実な設計」の溝／なぜ動画全盛期にあえてポッドキャストを選ぶのか？

    今回はかずもりが体調不良で欠席のため、2人での雑談回をお届けします。 【前半：エンジニアの「バイブス」と「規律」】前半のテーマは、エンジニアが何に興味を持ち、どこにモチベーションを感じるかについて。個人で勢いのままにコードを書く「バイブスコーディング」と、組織開発で求められる「保守性・テスト・CI/CD」を意識した開発には大きな溝があります。その文脈で、不在のかずもりが実装した音声合成・配信フローの完全自動化や、テストコードの堅実な設計思想について触れ、彼の「効率化への執念」とエンジニアとしての在り方を再評価しました。 【後半：なぜ我々はポッドキャストをやるのか？】後半は「YouTubeなどの動画配信が容易な時代に、なぜ音声のみのメディアを選ぶのか？」という議論へ。- 制作側のメリット： 寝転がりながらでも収録できる気軽さと、「余白」を楽しむラジオ的文化。 - 社会人にとっての効能： 目的がないと集まりにくい社会人が、友人と定期的に深い話をするための「装置」としてのポッドキャストの価値。【トピック】00:00 開発者のモチベーションはどこにある？05:00 セキュリティスペシャリストとしてのバックグラウンド07:10 個人開発では見えにくい「運用・保守」の視点18:20 かずもりの「自動化」はレベルが違う話21:00 なぜポッドキャスト？YouTubeじゃダメな理由32:00 音声コンテンツは「小説」に似ている？37:00 ポッドキャストを「やる側」の大きなメリット39:45 今後の活動と、社会人が雑談を続けるための仕組み40:20 飯田商店のラーメンと予約のハードルかずもりへの業務連絡（生存確認）も兼ねた、ゆるくも熱い開発＆メディア論です。ぜひお聴きください。

    44分
  3. #5 Apple初売り・Nothing福袋の勝者は？ / 音声配信をCI/CDで完全自動化する『Podcast Automator』の全貌

    2025/12/31

    #5 Apple初売り・Nothing福袋の勝者は？ / 音声配信をCI/CDで完全自動化する『Podcast Automator』の全貌

    【エピソード概要】 今回は年末年始の恒例行事である「ガジェット商戦」の振り返りと、現在開発中のポッドキャスト配信自動化システム『Podcast Automator』の技術的な裏側についてお話ししました。 【トピック】 1. 年末商戦とガジェットトレンド分析 テクノロジー愛好家にとって重要な「散財」のシーズンを振り返ります。 主要ブランドの戦略: Appleの初売りギフトカード戦略、自動購入スクリプトが動くほど競争率が高いNothingの福袋、Shokzの実質2-for-1キャンペーンなど、各社のプロモーションを分析。 ホビイスト向け市場: KeychronやNuPhyなどの高性能キーボードや、価格破壊が進む3Dプリンター市場の動向。 消費者の二極化: 最新ガジェットを追いかける層と、一つの製品を長く愛用する実用主義層の対比について。 2. 開発プロジェクト：Podcast Automator 音声ファイルのアップロードをトリガーに、公開までの全工程を無人化する社内プロジェクトの進捗報告です。 アーキテクチャ: GitHub Actions、Google Cloud Run、GCS、Cloudflare R2を組み合わせたCI/CDパイプラインの構成。 AIによる自動化: アップロードされた音声から、AIがタイトルと要約（Description）を自動生成し、RSSフィードを書き換える仕組み。 今後の展望: コンソール操作の手間を省くための管理用Webアプリ開発と、Discord録音ボット『Craig』との連携による「ゼロタッチ」配信構想。 3. クリエイティブ エピソードごとのカバーアート設定と、脳波×サイバーパンクなデザインコンセプトについて。 【関連リンク】 sunabalog GitHubリポジトリ: https://github.com/sunaba-log/podcast-automator.git 今回の技術スタック: Vertex AI, Google Cloud (Cloud Jobs, Workflows, Eventarc), Terraform, Cloudflare R2, Python

    45分
  4. #4 TerraformによるIaC化完了！GCPとCloudflareで作る、ポッドキャスト完全自動化アーキテクチャの全貌

    2025/12/24

    #4 TerraformによるIaC化完了！GCPとCloudflareで作る、ポッドキャスト完全自動化アーキテクチャの全貌

    「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

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

    2025/12/17

    #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

    53分
  6. #2 再生数8回からの挑戦！GCP×Geminiでポッドキャスト配信を全自動化する計画、始動。

    2025/12/10

    #2 再生数8回からの挑戦！GCP×Geminiでポッドキャスト配信を全自動化する計画、始動。

    今回のスナバログは、記念すべき第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でタスク管理しながら進めていく様子も共有していきますので、開発の裏側にご興味ある方もぜひお聴きください！

    50分

  7. 2025/12/04

    #1 チャンネル名「Sunaba log」ついに決定！「妄想と実装」を掲げるアイディエーション型ポッドキャストのコンセプトを詰める

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

    34分
  • 7話のエピソード

番組について

「妄想」から「現実」へ繋がるアイディエーション番組。 「1ヶ月で何かは作る」という具体的な目標を掲げ、アイデアの生成から実装までを追います。前半で自由なアイデアを議論し、後半ではそれを現実に引き戻す形で、実際に物を作ったり、作らなかったりする過程を配信します。

情報

  • クリエイター
    Sunaba Log
  • 配信期間
    25年 - 26年
  • エピソード
    7
  • 制限指定
    不適切な内容を含まない
  • Copyright
    © Sunaba Log
  • 番組のWebサイト
    sunabalog