NEWS DETAIL7 min read

CodexStudioWorkflow業務設計2026/05/15

自分専用のポッドキャストアプリを作った理由: 配信ではなく、聴く導線を自分のものにする

ポッドキャストとして使うには、RSSや各種アカウント登録が必要で、しかも非公開運用に寄せにくい。自分用に聴きたいだけなのに色々とうざすぎたので、Codexで必要な導線だけを持つ専用アプリを自作した制作ログです。

使用技術スタック

AIエージェントWebフロントエンド業務設計メディア連携

3行で読む結論

ポッドキャストを「公開する」だけなら、Apple PodcastsやSpotifyの配信フローに乗せるのが自然です。

でも、自分だけが聴く音声メモや学習音声なら、配信登録よりも、探す、聴く、続きから再開する、あとで見返す導線のほうが大事でした。

だから今回は、巨大な配信面に合わせるのではなく、自分の反復行動に合わせた専用アプリをCodexで作りました。

なぜ、わざわざ自作したのか

最初は、音声ファイルをどこかに置いて聴ければ十分だと思っていました。Google Driveに置く。Apple Musicのような音楽アプリで管理する。Spotifyに登録する。選択肢はいくつもあります。

ただ、やりたいことは「番組を世の中に配信すること」ではありませんでした。自分専用の音声を、移動中や作業前にすぐ聴き、途中で止め、また戻る。必要ならタイトルやメモを見て、どの回を聴くべきか判断する。つまり、欲しかったのは配信プラットフォームではなく、自分の学習導線でした。

Google Driveは公式ヘルプ上でも音声や動画ファイルをアップロード、共有、開くことができます。一方で、それはファイル置き場としての強さであって、連続再生、未聴管理、番組らしい一覧、再開しやすさまで含めたポッドキャスト体験とは別物です。

Apple Podcastsに出す場合、AppleはRSSフィード経由でApple Podcasts Connectに番組を追加できる一方、技術検証とレビューを通過する必要があると説明しています。さらにRSSフィードには、少なくとも1つのエピソード、アートワーク、必須タグなどが必要です。これは公開番組なら妥当ですが、自分だけの音声置き場には少し重い。

Spotify for Creatorsも、RSSフィードにはタイトル、説明、音声ファイルへのリンク、アートワークなどが含まれると説明しています。Spotifyでホストする番組はSpotify上に公開されますが、他の聴取プラットフォームへは自動配信されず、RSSを有効化して自分で提出する流れになります。自分のメールアドレスがRSS上で公開される可能性にも注意が必要です。

ここまで見て、「これは自分の用途には配信の作法が大きすぎる」と感じました。だから、登録作業を頑張るのではなく、Codexで必要な機能だけを持つ小さなアプリとして作りました。

作ったものは、番組配信ではなく個人用の聴取面

今回Codexで作ったアプリは、公開番組の管理画面ではありません。自分が聴くための、個人用ポッドキャストライブラリです。

想定した中心機能はシンプルです。

音声を回ごとに並べる
タイトルと短いメモで内容を判断できる
再生、停止、続きから聴く操作を迷わない
学習用、作業前、移動中など、用途ごとに分けられる
将来、AIで要約やチャプターを足せる余白を残す

重要なのは、配信者向けの機能を増やしすぎないことでした。ランキング、公開ページ、購読者管理、分析ダッシュボードは、今回の問題には直接効きません。自分にとって価値があるのは、「聴きたい時にすぐそこにある」ことです。

Webアプリにした理由もここにあります。端末に縛られず、ブラウザで開ける。必要ならスマホのホーム画面に置ける。Media Session APIを使えば、対応環境ではブラウザの音声再生をOS側の標準UIに近い形で扱い、再生メタデータや再生操作を渡せます。MDNは、このAPIがロック画面などの標準的なメディアUIに情報を渡せる一方、主要ブラウザすべてで同じように使える段階ではないとも説明しています。だから、そこは便利機能として扱い、基本体験はHTMLの音声再生で崩れないように考えます。

自作でよかったところ

自作してよかったのは、機能を減らせたことです。

大きなサービスに載せると、どうしてもサービス側の前提に合わせます。番組名、アートワーク、RSS、カテゴリ、公開範囲、審査、配信先、分析。どれも公開メディアには必要ですが、自分の音声を自分だけが聴く用途では、判断の摩擦になります。

小さな自作アプリなら、最初の画面に必要なものだけ置けます。

今日聴く回
前回の続き
あとで聴く回
生成した音声の元メモ
重要な回だけの固定表示

この単純さが、実は一番効きます。音声コンテンツは、作るより聴き続けるほうが難しい。だから「管理できる」より「戻ってこられる」ことを優先しました。

コピペするプロンプト本体

自分専用の音声アプリを作る前に、必要機能を絞るためのプロンプトです。


text
あなたは、個人利用の小さなWebアプリを設計するプロダクト編集者です。私は{聴きたい音声の種類}を自分だけで聴くために、既存の配信サービスではなく小さなポッドキャスト風アプリを作ろうとしています。公開番組として伸ばすことより、毎日または毎週の聴取を続けやすくすることを優先してください。まず、私の用途を「配信が必要な要件」と「個人アプリで十分な要件」に分けてください。次に、初期版に入れる機能を最大7個までに絞り、入れない機能も理由つきで列挙してください。最後に、{利用端末}、{音声ファイルの保存場所}、{再生中に見たいメモ}を前提に、最初の画面構成とデータ項目を提案してください。出力形式は、1. 判断の前提、2. 必須機能、3. 捨てる機能、4. 画面構成、5. 実装前に確認する質問、の順番にしてください。機密情報や個人の音声内容は推測せず、不明点は質問として残してください。

使用シーン: 音声メモ、学習音声、AIで生成した解説音声などを、自分専用に聴きたい時に使います。

期待される出力: 公開配信のための機能と、個人利用に必要な機能が分かれ、初期版で作る範囲が見えるようになります。

AITOWAの実績: AITOWAの制作ログでは、Codexを業務に入れる手順やChrome拡張の改善のように、巨大な仕組みを先に作るより、日常の小さな詰まりを道具化する流れを重視しています。

注意点: 音声ファイルの中身に個人情報や顧客情報が含まれる場合は、保存先、公開範囲、共有設定を先に確認してください。AIに設計を相談する場合も、未公開情報をそのまま貼らないほうが安全です。

AITOWA視点

今回のポイントは、「便利なサービスを使わない」ことではありません。むしろ、Google Drive、Apple Podcasts、Spotifyにはそれぞれ正しい使いどころがあります。

公開番組として配るなら、Apple PodcastsやSpotifyに合わせる価値があります。ファイル共有や保管が主目的なら、Google Driveは強い選択肢です。ただし、今回の課題はそこではありませんでした。

AITOWA視点では、ツール選定の前に「どの行動を軽くしたいのか」を見ます。今回は、配信登録ではなく、聴く、戻る、選ぶ、続けるという行動を軽くしたかった。だから、既存サービスに合わせて設定を増やすより、自分の行動に合わせて画面を削るほうが合っていました。

この考え方は、業務アプリにもそのまま使えます。SaaSを導入する前に、まず現場で毎日くり返される小さな操作を1つ選ぶ。そこだけを小さく自作する。うまくいけば広げる。うまくいかなければ捨てる。大きな導入より、この順番のほうが学びが速い場面は多いです。

公開するなら、あとからRSSに寄せればいい

個人用アプリとして始めたからといって、将来の公開を捨てる必要はありません。

最初からApple PodcastsやSpotifyに登録する前提で作ると、RSS、アートワーク、エピソードメタデータ、公開範囲、審査を考える必要があります。一方で、自分用のアプリなら、まず聴取体験を固められます。

その後で、本当に人に届けたい回だけを選び、RSSフィードに必要な項目へ変換する。AppleのRSS要件にあるエピソード、アートワーク、enclosure、GUIDなどを満たす形に寄せる。この順番なら、公開作業の前に「そもそも聴き続けたい内容なのか」を確認できます。

つまり、自作は配信の否定ではありません。配信する前に、自分にとって価値があるかを検証するための小さな場所です。

参考にした一次情報

本記事はAIエージェントが下書きを生成し、aitowa編集部の方針・知見に基づき構成しています