AIでポッドキャストを定性・定量分析して改善する

はじめに

「信州プルリクエスト」という Podcast をやっています。長野で働くエンジニア 2 人が、ゆるく雑談する番組です。

フォーマットはシンプルで、どちらかが「PR（プルリクエスト）」として提案を持ち込み、もう一方が「レビューアー」として受け取ります。最後に approve か reject かを決める。まだ 8 エピソード目の、駆け出しの番組です。

ただ、公開してみると、すぐに困ったことがありました。

「今回は面白かったカモ...。」
「今回はちょっとイマイチだっただろう...。」

収録のたびに、そういう感覚は残りました。でも感覚だけでは、何がどう良かったのか／悪かったのかを言語化できません。次回に活かせないのです。「なんとなく良かった」を繰り返しているだけでは、改善に再現性がありませんでした。

エンジニアであれば、こういうときソフトウェアの品質をどう管理するか知っていますよね。Lint で機械的にチェックできることは機械に任せ、テストで壊れていないかを毎回確認し、CI で同じ基準を毎回同じように適用する。そういう基盤を当たり前のように作ります。

Podcast にも同じことができないか。そう考えて、Claude Code に毎回の編集後音声を渡すと「4 つの価値」「笑いの量」「テンポ」「対話の質」などをスコアリングしてくれる仕組みを作りました。

この記事では、その設計と、実際に 8 エピソード分運用してみて分かってきたことを書きます。

1. 面白さをレビュー項目へ分解する

出発点になったのは、野村高文さんの『プロ目線の Podcast のつくり方』で紹介されている「面白い Podcast を構成する 4 つの価値」という考え方でした。

価値	問い
発見	聴き手が知らなかったことを知れる瞬間があるか
理解	聞いたことはあるがよく分からなかったことが腑に落ちる瞬間があるか
共感	「ああ、わかる」と思える場面があるか
空間設計	2 人の会話空間にリスナーが同席しているような没入感があるか

ただ、この 4 つをそのまま「今回は発見があってよかった」で終わらせても、次に何を変えればいいのか分かりません。抽象的すぎて、改善のアクションに落とせないと思いました。

エンジニアリングという行為は、何かを「実現」することです。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移していく過程に行うすべてのことです。

広木大地著『エンジニアリング組織論への招待』でも、エンジニアリングという行為を、こう定義しています。

「面白い Podcast を作る」は、まさに不確実性の高い状態です。

何が面白さを生んでいるのか、次に何を変えれば良くなるのか、感覚だけでは分かりません。4 つの価値についても、「聴いていてどう感じるか」を評価できる具体的な観点まで分解して、不確実性を下げていく必要があると思いました。

実際に運用しているルーブリックの一部を抜粋します（review-episode-content スキルより）。

### 4. 飽きてこないか（テンポ分析）

エピソードを前半・中盤・後半に分けて、それぞれの密度を評価する。

- 前半: 話題の「引き」が早い段階で提示されているか。背景説明が長すぎないか
- 中盤: 情報量が多すぎて説明的になっていないか
- 後半: 具体的な話・2 人の意見交換

**テンポが落ちているサイン**:

- 一方が長く話し続けて、もう一方が「そうなんですね」を繰り返している
- 資料読み上げ・実績紹介・展示紹介のような一方的な説明区間

本の 4 要素に加えて、番組独自の観点も足しました。信州ネタが機能しているか、対話に摩擦や深掘りがあるか、テーマからどれだけ逸脱したか。最終的に、次の 10 軸のルーブリックにまとまりました。

• 発見
• 理解
• 共感
• 空間設計
• 笑い
• キャラクター
• テンポ
• 信州ネタ
• 対話の質
• 逸脱度

スコア	意味
1	ほとんど感じられない
2	弱い
3	普通にある
4	強く感じられる
5	エピソードの核になっている

2. AI にレビュー担当になってもらう

Claude をこの仕組みの中でどう使っているかというと、台本を書かせたり要約させたりする「制作アシスタント」としてではありません。品質保証(QA)担当として使っています。

編集後の音声ファイルを渡してskillを呼び出すと、次のようなアウトプットが返ってきます。

### 4 つの価値

各価値について 1〜2 行で評価

### 笑いの量とタイミング

- 笑えそうな場面のリスト（行番号付き）
- 前後半の偏りコメント

### キャラクターの見え方

提案者・レビューアーそれぞれ 2〜3 行、共通の個性コメント 1 行

### テンポ分析

前半 / 中盤 / 後半ごとに 1〜2 行

### 対話の質

1〜2 行で評価

### 逸脱度

1〜2 行で評価（脱線があれば良い脱線/悪い脱線の判断も）

### スコア

10 軸それぞれについて 1〜5 のスコアと一言の根拠

### 改善提案

具体的なカット候補や「ここで掘り下げるともっとよかった」を 1〜3 点

音量正規化や文字起こしも含めると、実際には次のようなことをまとめて任せています。

• 音量の確認・正規化
• 文字起こし
• 笑い声の検出（YAMNet による音声分類で自動カウント）
• 上記のルーブリックに基づくレビューとスコアリング
• エピソードのタイトル・概要文の生成
• X 投稿文の生成

10 軸のうち「笑い」だけは、Claude の主観的な判断ではなく、YAMNet による音声分類で笑い声を自動検出してカウントしています。他の 9 軸は文字起こしと音声を Claude に渡して判断してもらっていますが、笑いの量だけは音声解析の結果を土台にしている、という違いがあります。

笑いをわざわざ数値化しているのは、笑いがないと空気感がつまらなそうに聞こえてしまうからです。「信州プルリクエスト」は、マッチョなテック系 IT Podcast を目指しているわけではありません。だからこそ、笑いの量は指標として出しています。

3. フィードバックループを作る

このスキルを毎回のワークフローに組み込むと、番組づくりのサイクルは次のようになります。

企画
 ↓
収録
 ↓
編集
 ↓
Claudeレビュー
 ↓
スコア・改善提案・音声修正
 ↓
公開
 ↓
次回の企画へ

ソフトウェア開発の CI/CD と同じように、毎回同じ観点でレビューすることで、感覚に頼らず品質を継続的に改善できる仕組みにしています。

4. 実際のレビュー例

ここまでに公開した 8 エピソードのうち、このスキルでレビューした直近 5 本のスコアがこちらです。

エピソード	発見	理解	共感	空間設計	笑い	キャラクター	テンポ	信州ネタ	対話の質	逸脱度	一言コメント
ep004	4	4	3	3	4	4	3	3	4	2	良い脱線のみ
ep005	4	3	2	4	3	4	3	3	4	2	制度説明約 8 分で失速
ep006	3	3	4	4	3	4	2	5	3	3	54 分の長尺とテンポ課題
ep007	4	3	4	3	4	4	3	5	2	3	掘り下げの薄さ
ep008	4	4	3	4	4	4	3	4	4	3	転換は良い脱線

現在は、再生数などの数字を見て自分の直感と合っているか、自分の中でまだ直したいところがあるかを意識することだけにしています。

母数が少ないうちから、この数字だけを根拠に方向を修正するつもりはありません。参考程度に見ています。

5. 測れないものもある

ポッドキャスト分析専門の番組「ポッドキャスト研究室」で、サイエントークのレンさんが次のように話していました。

「関係性とか多分測るのは無理だと思うんだよね」

自分たちが大事にしているリアルな会話や関係性も、結局はここに近い部分だと思っています。

難しさは重々承知の上で、それでも配信と収録を続けながら、言葉にできる範囲を探っていきたいと思っています。

おわりに

この評価軸が本当に「面白さ」を表しているのか、正直まだ分かりません。

30、40、50 本とエピソードを重ねながら、自分が「今回は良かった」と感じた回と AI の評価が一致していくのかを見ていきたいと思っています。

もし一致しなければ、疑うべきは AI ではなく評価軸の方かなと思っています。
項目を見直し、重み付けを変え、また評価する。その繰り返しをしていきたいです。

参考