sunabalog

【エピソード概要】

今回のスナバログ定例会では、活動の根幹をなす「宣言」について深く掘り下げました。LLM時代におけるエンジニアの価値、ソフトウェアにおける職人技の真髄、そして「物語」がプロダクトに与える影響を熱く議論。さらに、「効率化への抵抗」や「身体性の回復」といった現代社会への問いかけを通じて、スナバログが目指す「生き様」を模索します。メンバーそれぞれの信条をぶつけ合い、共通のビジョンを言語化していく過程に注目です。その他、電脳ビジョン体験やウェブサイトの技術課題についても触れています。

【目次】

0:00 チケット購入とイベント参加の検討

0:30 メガネブランドと体験予約に関する情報共有

2:00 スナバログウェブサイトの現状とポッドキャスト運用上の課題

3:00 スナバログの「宣言」に関する議論の開始

4:00 宣言の「概要」読み上げと「存在意義の再定義」

6:00 ソフトウェアにおける職人技の価値と将来性に関する考察

9:00 「物語」がソフトウェアの価値に与える影響

11:00 「効率化への抵抗」と「身体性の回復」の意義

14:00 宣言に込める「生き様」と共通の信条の模索

16:00 今後のアクション：宣言のブラッシュアップ

【関連情報】

- GitHub: https://github.com/sunaba-log

- 技術スタック:

- Discord

- GitHub Pages

- RSSフィード

- HTMLエスケープ

- LLM

- VR/AR

- キーワード:

- 電脳ビジョン体験

- 虎ノ門ヒルズ

- 純銀座の眼鏡店

- イブンジー2

- ハリーデイ

- 鯖江

- Zoff

- JINS

- ポッドキャスト

- アートワーク

- 宣言

- 存在意義の再定義

- ドメイン知識

- 構想力

- 職人技

- 物語

- コンテキスト

- Apple

- 効率化への抵抗

- 身体性の回復

- 生き様

- 信条

【about us】

sunaba log: 友人同士で週次で雑談しながら「30 days to build」プロジェクトを進行する、雑談発想型プロトタイピング会議録。

【エピソード概要】今回の砂場logでは、AIエージェント時代におけるシステムエンジニアの「生存戦略」として、私たち独自の「砂場log宣言」を作成する意義と具体的な進め方について深く議論しました。効率性だけではない「雑談」から生まれる価値を再認識し、アジャイル宣言のように「宣言」と「原則」で構成するアイデアも飛び出します。さらに、小野が購入した最新スマートグラス「EVEN G2」を徹底レビュー！リアルタイム翻訳、ナビ、AIアシスタントなど驚きの機能と、会議や移動中の具体的な活用事例をご紹介。未来の働き方を変える可能性を秘めたスマートグラスの魅力に迫ります。攻殻機動隊展との連携企画も進行中！

【目次】

0:00 導入・議題の確認

0:16 小野からの話題提供と雑談の価値

1:50 砂場logの「宣言」作成の提案

5:00 「宣言」と「憲法」「原則」の構造に関する議論

12:54 宣言作成のアクションプラン（PRベースでの執筆）

17:11 スマートグラス「EVEN G2」の使用感と機能紹介

23:50 スマートグラスの具体的な機能（翻訳、ナビなど）

27:10 スマートグラスに関する質疑応答（度付き、用途、翻訳精度）33:00 スマートグラスの活用事例と将来性

36:55 「攻殻機動隊展」との連携と今後の調整

38:20 締めの挨拶

【関連情報】

- GitHub: https://github.com/sunaba-log

- 技術スタック:

- AIエージェント

- Chat GPT

- Discord

- プルリクエスト (GitHubの機)

- LINE

- XREAL (比較対象として言及されたスマートグラス)

- キーワード:

- 砂場log宣言

- スマートグラス

- EVEN G2

- 雑談

- 生存戦略

- アジャイルソフトウェア開発宣言

- リアルタイム翻訳

- ナビゲーション

- 攻殻機動隊展

- ROI至上主義

【about us】sunaba log: 友人同士で週次で雑談しながら「30 days to build」プロジェクトを進行する、雑談発想型プロトタイピング会議録

【番組紹介】

sunaba log: 友人同士で週次で雑談しながら「30 days to build」プロジェクトを進行する、雑談発想型プロトタイピング会議録。

【目次】

0:00 SFと理想の世界

0:40 マルチバースの解釈

1:50 ディストピアとしてのマルチバースと社会の階層

3:50 SFの進化と異世界転生

5:10 SF小説「幼年期の終わり」と考察

8:30 ホラーと精神疾患の視点

10:00 異世界転生批判と「不合理な孫の手」

14:00 AIとシナリオ作成・ナロー小説

16:30 AR技術の可能性とニコニコ動画の文化

20:00 未来と過去、そしてLの世界

24:00 開発進捗報告とポッドキャストの今後

【概要】

今回のsunaba logでは、SF作品が描く理想の世界やマルチバースの解釈から議論がスタート。マルチバースがディストピアに繋がる可能性や、SFの進化として異世界転生が流行する背景を深掘りします。名作『幼年期の終わり』の普遍的なテーマに触れつつ、ホラー作品における精神疾患の視点や、異世界転生作品への批判的考察も展開。さらに、AIによるシナリオ作成の未来、AR技術がもたらす現実世界の変革、ニコニコ動画文化が日本のインターネットに与える影響など、多岐にわたるテーマで白熱した議論が交わされました。終盤では、ポッドキャスト自動化ツールの開発進捗が報告され、M4AからMP3への変換対応やCMS開発の課題についても言及。未来の技術と創作、そして開発のリアルが詰まったエピソードです。

【関連情報】

- GitHub: https://github.com/sunaba-log

- 技術スタック:

<br>- M4A<br>- MP3<br>- RSS<br>- Amazon Music<br>- Spotifyキット<br>- CMS- キーワード: <br>- SF<br>- マルチバース<br>- ディストピア<br>- 異世界転生<br>- 幼年期の終わり<br>- ホラー<br>- 精神疾患<br>- AI<br>- シナリオ作成<br>- ナロー小説<br>- AR技術<br>- ニコニコ動画<br>- 電脳コイル<br>- X (旧Twitter)<br>- 攻殻機動隊<br>- Lの世界<br>- ポッドキャスト自動化]]>

【目次】

0:00 ARグラスの多様性と小野さんの使用経験

0:16 EVen G2の驚くべき機能とユースケース

5:00 ARグラス市場の「バブル」と技術的進化の背景

12:54 ARグラス開発の展望とSpec KItの可能性

17:11 ポッドキャストオートメーターの進捗とSpec KItによるマネージャー開発

20:00 Spec KItの基本的な開発プロセスと生成物

25:00 Spec KIt導入の課題とチーム運用モデル

30:00 オートメーターとマネージャーの連携、今後の開発方針

【概要】今回は、ARグラスの最前線とAI駆動開発ツール「Spec KIt」の活用に迫ります。小野さんが使用するARグラス「EVen G2」の多様な機能や、Google Glassの失敗から学んだ市場の進化、LLMがもたらすARグラスの実用性向上について深掘り。さらに、Spec KItを使ったポッドキャストマネージャーの初期開発プロセスを共有し、AIによるコード生成のメリットと、ドキュメント肥大化やチーム運用における課題を議論します。未来の技術と開発手法が交錯する、刺激的なプロトタイピング会議の記録です。

【関連情報】

- sunabalog GitHubリポジトリ: https://github.com/sunaba-log/podcast-automator.git

- 技術スタック:

- Python

- GCS (Google Cloud Storage)

- Next.js

- TypeScript

キーワード: - ARグラス - EVen G2 - Spec KIt - ポッドキャストオートメーター - ポッドキャストマネージャー - LLM - XR - DDD - Next.js - TypeScript - GCS

【概要】今回は、2026年時点での「Copilot」などのAIアシスタントの実用性や、ドキュメントツールとしてのNotionの立ち位置について議論しました。後半では、番組の配信システムを「SpecKit」を用いた仕様書駆動開発で自動化する新たなプロジェクトについて話しています。

【目次】0:00 CopilotとAgentic AIの現在地2:45 AI作成資料のクオリティと日本人の職人気質6:20 資料作成は本当に必要なのか？12:10 Notion vs M365：ツールの使い分けと現状18:20 ポッドキャスト配信システムの自動化計画20:45 新たな開発手法「SpecKit」とAIコーディング25:30 来週へのアクションアイテム

【エピソード概要】 

「雑談が楽しい」から始まった僕らのポッドキャスト。しかし、回を重ねる中で「本当に作りたいもの」「僕らならではの価値」とは何かという問いに直面しました。今回は、メンバーそれぞれがプロジェクトに何を求めているのか（サービス開発？技術探求？それともアイデアを出すこと自体？）、その根源的な動機を率直に語り合います。

議論は、いつもの雑談からアイデアが生まれるスタイルから一歩踏み込み、「僕らだけのアイディエーション手法をデザインできないか？」という壮大なテーマへと発展。市場調査や課題解決からスタートする一般的なプロダクト開発（マーケットイン）とは一線を画し、利益や需要よりも「自分たちが心の底から面白いと思えるか」を追求する「プロダクトアウト」の精神こそが、僕らの原動力であると再確認します。その精神は、かつて『ニコニコ技術部』で見たような、利益度外視でアニメのガジェットを本気で再現するような純粋な探求心に近いのかもしれません。

その具体的なアプローチとして浮上したのが、「SFプロトタイピング」や「スペキュラティブデザイン」という考え方。未来の社会やテクノロジーを空想し、そこから逆算して「今作るべきサービス」を考えるこの手法は、まさに僕らの探求心に火をつけるものでした。

もちろん、この「趣味としての探求」は、サーバー代などの現実的なコストという壁にいずれ直面するかもしれません。利益を追求し始めると、僕らが大切にしたい「面白い」という純粋な動機が揺らいでしまうのではないか――そんなジレンマも率直に語りながら、それでも今は純粋な好奇心を優先することに。

次回の活動として、各々が好きなSF作品を持ち寄り、その世界観からプロダクトを妄想してみることに。アニメや映画の”あのガジェット”をただ再現するのではなく、「その本質は何か」をエンジニアの視点で突き詰め、核となる要素を現実世界に実装してみる。技術的な制約や収益性を一旦脇に置き、純粋な「面白い」を追求する僕らの知的冒険が、ここから始まります。

【目次】 

5:00 雑談が楽しい理由と、僕らの目的 

12:00 僕らだけの「アイデア発想法」をデザインする 

18:00 SFプロトタイピングとは？未来から逆算するサービス開発 

35:00 次回予告：「好きなSF作品からプロダクトを考えよう！」の前にPodcast 管理システムの要件定義をします。

【about us】

今回はかずもりが体調不良で欠席のため、2人での雑談回をお届けします。

【前半：エンジニアの「バイブス」と「規律」】
前半のテーマは、エンジニアが何に興味を持ち、どこにモチベーションを感じるかについて。個人で勢いのままにコードを書く「バイブスコーディング」と、組織開発で求められる「保守性・テスト・CI/CD」を意識した開発には大きな溝があります。その文脈で、不在のかずもりが実装した音声合成・配信フローの完全自動化や、テストコードの堅実な設計思想について触れ、彼の「効率化への執念」とエンジニアとしての在り方を再評価しました。

【後半：なぜ我々はポッドキャストをやるのか？】
後半は「YouTubeなどの動画配信が容易な時代に、なぜ音声のみのメディアを選ぶのか？」という議論へ。
- 制作側のメリット： 寝転がりながらでも収録できる気軽さと、「余白」を楽しむラジオ的文化。 - 社会人にとっての効能： 目的がないと集まりにくい社会人が、友人と定期的に深い話をするための「装置」としてのポッドキャストの価値。
【トピック】
00:00 開発者のモチベーションはどこにある？
05:00 セキュリティスペシャリストとしてのバックグラウンド
07:10 個人開発では見えにくい「運用・保守」の視点
18:20 かずもりの「自動化」はレベルが違う話
21:00 なぜポッドキャスト？YouTubeじゃダメな理由
32:00 音声コンテンツは「小説」に似ている？
37:00 ポッドキャストを「やる側」の大きなメリット
39:45 今後の活動と、社会人が雑談を続けるための仕組み
40:20 飯田商店のラーメンと予約のハードル
かずもりへの業務連絡（生存確認）も兼ねた、ゆるくも熱い開発＆メディア論です。ぜひお聴きください。

【エピソード概要】 今回は年末年始の恒例行事である「ガジェット商戦」の振り返りと、現在開発中のポッドキャスト配信自動化システム『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

「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