エンジニアリング的 Podcast 運用 ──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)担当として使っています。

編集後の音声ファイルを渡して「対応して」と言うと、次のようなアウトプットが返ってきます。

### 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 を目指しているわけではありません。だからこそ、笑いの量は指標として出しています。

普通の AI 活用記事なら「文字起こし → 要約 →SNS 投稿文生成」で終わります。作業の効率化です。今回作ったのは、そこにレビューとスコアリングという「品質保証」の工程を挟んでいるところが違います。

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	転換は良い脱線

現在は、この数字を見て自分の直感と合っているか、自分の中でまだ直したいところがあるかを意識することだけにしています。母数が少ないうちから、この数字だけを根拠に方向を修正するつもりはありません。参考程度に見ています。

おわりに

この評価軸が本当に「面白さ」を表しているのか、正直まだ分かりません。
30、40、50 本とエピソードを重ねながら、自分が「今回は良かった」と感じた回と AI の評価が一致していくのかを見ていきたいと思っています。もし一致しなければ、疑うべきは AI ではなく評価軸の方かなと思っています。
項目を見直し、重み付けを変え、また評価する。その繰り返しをしていきたいです。

参考