Podcast Parser

@pipeworx/podcast-parser

追跡対象のポッドキャスト162番組で繰り返し語られる内容をまとめています。10,000件を超えるエピソードから抽出した主張を、それぞれのステータスの根拠となる測定値とともに掲載しています。測定値は、その主張を繰り返した独立したポッドキャストと話者の数を示し、発案者は除外しています。

Pipeworx の一部です。AI エージェントを1683以上の稼働中データソースに接続する MCP ゲートウェイです。

稼働中、BYO 専用。 Bruce のパートナーキーが用意され、エクスポートされた8つのツールすべてが実際の API に対して空でないペイロードを返すことを確認できたため、2026-09-14（フリート #1958）に _incubator から昇格し、ゲートウェイに接続しました。

**Pipeworx のプラットフォームキーが存在するにもかかわらず、BYO 専用で出荷しています。**これは見落としではなく、意図的な選択です。ゲートウェイは Cloudflare のテキストバインディング上限である250個に達しているため、wrangler secret put PLATFORM_CANONCANNON_KEY は 「Too many text bindings, found a total of 251, they exceed the limit of 250」（コード 10055）というエラーで拒否されます。シークレットが実際には存在しないまま platformKeyEnv を宣言すると、ルーティングでこのパックが「利用不可」扱いされなくなり、ポッドキャストのコンセンサスに関する質問が、拒否しかできないツールに送られてしまいます。これは正直な no_match より明らかに悪い対応です。fda-inspections の前例（フリート #617）を参照してください。そのため、このパックでは platformKeyEnv を宣言せず、keyBlockedTools() によって ask_pipeworx の検索対象から除外しています。独自の CanonCannon キーを持つ呼び出し元は、引き続き _apiKey を使って直接呼び出せます。

完了するには: ゲートウェイのテキストバインディングを1つ空けてから、wrangler secret put と platformKeyEnv: 'PLATFORM_CANONCANNON_KEY' を同じ変更に含めて反映してください。キーはすでに発行済みで、正規チェックアウトの Git 管理対象外 .env に保存され、実際の環境での動作も確認済みです。canon_citations は別途保留中です。整合性ゲートを参照してください。

ツール

8つのツールをエクスポートしています。canon_citations は実装済みですが、意図的に保留しています。整合性ゲートを参照してください。

• canon_search(query?, tier?, label?, limit?, cursor?) — 繰り返し登場するアイデアを検索します。各行には tier とその測定値が含まれます。
• canon_get(slug) — 主張、根拠、補足、ギャップ、関連項目、書籍に加えて、測定値を1文で説明した完全なエントリーを取得します。
• canon_episode_search(query?, podcast?, since?, limit?, cursor?) — エピソードコーパスを検索します。
• canon_episode_get(slug) — 抽出されたアイデア、ゲスト、書籍を含む1つのエピソードを取得します。
• canon_person_get(slug) — ある人物が番組をまたいで実際に語った内容を取得します。
• canon_podcast_list(limit?, cursor?) — 追跡対象番組の一覧、つまりカノンの基準値となる分母を取得します。
• canon_podcast_get(slug) — 追跡対象の番組を1つ取得します。
• canon_corpus_stats() — コーパスの件数と、現在適用されている基準値を取得します。
• canon_citations(slug) — 保留中。 話者と発案者の関与状況を含む、あるアイデアを引用しているすべてのエピソードを取得します。

認証

現在は BYO 専用です。_apiKey（Authorization: Bearer cc_live_...）を指定してください。すべての /api/v1 エンドポイントは、キーがなければリクエストを拒否します。キーなしの GET /stats は、401 {"error":"Missing or malformed API key. Send Authorization: Bearer cc_live_..."} を明確に返します。そのため、認証情報がない場合に障害のように見えることはありません。

キーを保持していないため、platformKeyEnv はありません。Bruce がパートナーキーを発行したら、MCP_PACKS エントリーを追加するのと同じ変更で、ゲートウェイに PLATFORM_CANONCANNON_KEY を設定してください（fda-inspections の前例、フリート #617）。宣言済みでも未設定のプラットフォームキーは、キーのルールによりパック内のすべてのツールを利用不可にし、資金がないパックではなく壊れたパックのように呼び出し元に見えてしまいます。

さらに、引用エンドポイントは internal-tier のキーに制限されているため、パートナーキーでは 403 が返ります。これは上流のポリシーであり、こちら側の制限ではありません。

測定エンベロープ — 契約全体

tier は、次の2つの形のいずれかで、必ず measurement とともに返されます。

{ "available": true, "measured_at": "…", "independent_podcasts": 23,
  "independent_speakers": 41, "independent_episodes": 36,
  "threshold": 9, "tracked_podcasts": 162 }

{ "available": false, "reason": "not_yet_measured" | "not_yet_persisted" }

トップレベルの nullable フィールドに平坦化せず、このネスト構造をそのまま再現しています。 これにより、呼び出し側は 「未計算」 と 「計算済みで、答えはゼロ」 を見分けられます。独立した話者がゼロというのは、エントリーに関する強い主張です。利用不可は何も主張しません。null は両方の意味に読めて、値が設定された tier の隣にあると、「これは無視して、tier を信頼してください」 と受け取られます。

利用不可の理由は異なる主張であり、決してひとまとめにしません。

理由	意味	発生頻度
not_yet_measured	このエントリーは、最後の夜間再計算より新しい	行ごと、設計上恒久的 — 今日追加されたすべてのエントリーに当てはまります
not_yet_persisted	現時点では件数がまったく保存されていない	コーパス全体に関わる、実在するものの一時的な上流の不備

どちらも一般的な「測定値は利用できません」と表示すると、問題のないものを呼び出し側が 故障している と読み取り、健全なパイプラインに関する誤った不具合報告を生みます。誤ったコンセンサス数を生み出さないようにここまで注意を払った直後に、同じことをしてしまうのです。

measured_at は単なるメタデータではなく、不可欠な項目です。CanonCannon の基準は 双方向 です。コーパスがその周囲で拡大するだけで、支持がひとつも減っていなくても、エントリーが正典のステータスを失う可能性があります（基準は ceil(5% of tracked_podcasts) です）。また、システムの外部から not_yet_measured を検出できるのは、行ごとの measured_at だけです。

threshold は、tracked_podcasts なしでは報告されません。「162件中9件」は主張ですが、「9」だけでは単なる数値です。

canon_citations の整合性ゲート

src/index.ts の CITATIONS_VERIFICATION_LANDED = false により、このツールはエクスポートされる tools 配列に含まれず、callTool は理由を添えて呼び出しを拒否します。

CanonCannon の抽出処理は、正典エントリーを分類ラベルとして使用していたため、エントリー自身の要約テキストが、そのエントリー自身への支持として数えられる可能性がありました。canon_citations が返すのはコンセンサス数であり、呼び出し側が最も検証しにくい種類の値です。そのため、汚染されたリンクを通じて公開すると、Pipeworx の名のもとに、これを呼び出すすべてのエージェントに、自信に満ちた誤った数値を示すことになります。4,218件のリンクを対象とした検証作業が上流で進行中です。

フラグを切り替える前に：

1. 検証作業が完了していることを確認してください。「API が稼働中」であることは、検証の完了を意味しません。検証は独自のスケジュールで実行される別のパイプラインジョブです。
2. 行の verified: true を確認してください。エンドポイントは行ごとにフラグを返すため、誰かが覚えているかどうかに頼らず、上流でゲートが適用されます。
3. 除外ルールをハードコードしないでください。修正によってルールの形が変わるのか、入力だけが変わるのかは、これを記述した時点では未確定でした。そのため、このツールは想定されるルールではなく、API が示すルールを報告します。

すべてのツールに canon_ を付ける理由

episode_get、person_get、podcast_list、corpus_stats は、CanonCannon 自身の API-PLAN.md §3 に記載されていた名前で、現在、mcps/* 全体でも稼働中のゲートウェイでも明確に識別できます（2026-09-14 に確認）。また、次に誰かが作るポッドキャスト用パック（Listen Notes、Podcast Index、トランスクリプトのソースなど）でも、この4つの名前は汎用的に使いたくなるものです。

これは、ゲートウェイが名前だけの tools/call を解決する仕組みに関係します。ある名前が1つのパックだけで使われている間は 名前だけで公開 されますが、2つ目のパックが同じ名前をエクスポートした瞬間、両方とも <pack>_<name> としてしか呼び出せなくなります。つまり、将来のパックによってこのパックの稼働中のツール名が何の予告もなく変わり、tool-examples.json のキーや、名前だけの呼び出しを覚えたすべての呼び出し元が壊れてしまいます。9つの中央銀行パックがすべて exchange_rates をエクスポートしていたのが、実際に起きた先例です。整理される前には、「日本銀行の政策金利」を尋ねるとイスラエルの数値が回答されていました。

今なら canon_ のプレフィックスを付けてもコストはなく、後から追加すると互換性を損なう名前変更になります。昇格時には、念のためチェックを再実行してください。すぐ終わります。

for n in canon_search canon_get canon_citations canon_episode_search          canon_episode_get canon_person_get canon_podcast_list          canon_podcast_get canon_corpus_stats; do
  grep -rl "name: '$n'" mcps/*/src/ | head -3
done
scripts/pwcall.sh names canon_          # and against the live gateway

名前のチェックが適用されるようになりました。このパックは mcps/podcast-parser/ にあり、pnpm check:collisions と check:error-body-leak の対象になります。昇格時に、9つすべての canon_* 名が mcps/*/src 全体で一意であることを確認しました。

データソース

• https://canoncannon.com/api/v1/openapi — API の仕様です。キーは不要です。説明文ではなく、この成果物からツールのスキーマを作成してください。
• https://canoncannon.com/api/v1/canon、/canon/{slug}、/canon/{slug}/citations、/episodes、/episodes/{slug}、/people/{slug}、/podcasts、/podcasts/{slug}、/stats — 8つのツールと1つのツールがラップするエンドポイントです。

上流の仕様にはありますが、意図的にまだラップしていないもの：GET /people（一覧）、GET /search（コーパス横断検索）、GET /changes?since=（低コストのポーリング）。呼び出し元から要望があればツールを追加してください。各ツールには、実際に行を返した呼び出しから記録した tool-examples.json のエントリーが必要ですが、現時点では記録できません。

次の担当者があらためて調べることになりそうな事項

• オフセットではなく、カーソルページネーションを使います。 ?cursor= はキーセット方式です。next_cursor: null または空のページで終了してください。ページが短いという理由で終了してはいけません。短いページは、気づかないうちに切り詰められたときの状態だからです。この方式が採用されたのは、私たちも痛い目に遭った、PostgREST の 1,000 行制限と同じ問題があったためです。docs/postgrest-row-cap.md を参照してください。このパックではツール呼び出しごとに上流リクエストを 1 回だけ行い、カーソルを返すため、呼び出し元に、完全に見える切り詰め済みのリストが渡ることはありません。
• HTTP 経由の /api/v1 を利用するのは、私たちだけです。 CanonCannon のページはプロセス内でレンダリングされるため（Worker が自身のゾーンにアクセスすると、再びその Worker に入ります）、本番環境のトラフィックがこれらのルートを通ることはありません。そのため、API のバグを見つけるのは私たちです。OpenAPI の成果物は意図として、稼働中のエンドポイントは真実として扱ってください。これが、すべてのレスポンスに contract_warnings が含まれる可能性があり、警告が握りつぶされずに呼び出し元へ返される理由です。
• ここでは、契約上のバグがすでに 20 件のテストを通過しています（canon_related には canon への外部キーが 2 つあり、埋め込みが曖昧になっていたため、本番環境ではすべての詳細リクエストが 500 を返していましたが、スタブを使ったテストはすべて通っていました）。詳細エンドポイントには宣言済みのレスポンススキーマがありません。そのため、このパックでは、ここで誰も確認していないフィールドを手作業でマッピングせず、ペイロードをそのまま通します。
• citation_count は公開されておらず、再導入してはいけません。 これは数値の名前を付けられた、モデルの文章が入るテキスト列でした。
• Supabase に直接アクセスしてはいけません。例外はありません。 canon-cannon の Supabase プロジェクト（admbyodxaxsikiczgfjf）は別のプロジェクトです。Pipeworx のマイグレーション、データ取り込み、データパイプラインの Worker を、そこに向けてはいけません。HTTP 経由にすることで、基準が変更されたときに私たちもその変更に追従でき、基準からずれていくことを防げます。これを直接読み取りに「最適化」してはいけません。また、彼らのコーパスを Pipeworx のテーブルに取り込んではいけません。
• 彼らの api_keys テーブルでは、一時期 RLS が無効になっていました（anon で読み取りと書き込みが可能でした。1 時間以内に検知して閉鎖し、別途再確認しています）。私たちが保持するキーが、このテーブルから発行されるため、記録しています。

テスト

src/index.test.ts — 公開済み OpenAPI 成果物のフィクスチャを使った 25 件のアサーションです。宣言された契約への対応を検証します。利用不可の理由を区別したまま保つこと、tier を単独で渡さないこと、null を転送せずフラグを付けること、ページ件数を総件数として示さないこと、拒否時に 「requires an API key」 という文言をそのまま使うことを検証します。

これらのテストでは、稼働中の API がこの形式のレスポンスを返すことは検証していません。ここでは、稼働中の API を呼び出していません。キーが届いたら、誰かがこのパックを検証済みとする前に、フィクスチャのペイロードを、稼働中の API から記録したものに置き換えてください。

プロモーションで判明したこと（2026-09-14）

エクスポートされた8つのツールすべてについて、ゲートウェイへの接続を組み込む前に実際の API に対してライブテストを行い、ライブ呼び出しでしか発見できない2つの不具合が見つかりました。

1. canon_corpus_stats は、2つの数値がペイロードに含まれているにもかかわらず、すべての呼び出し元に基準値は報告されていないと伝えていました。 /stats は基準値を { corpus: {...}, bar: { threshold, tracked_podcasts, computed_at, rule } } にネストして返しますが、パックはトップレベルから threshold と tracked_podcasts を読み取ろうとして、どちらも見つけられず、"CanonCannon did not report both the threshold and the tracked-podcast count" を出力していました。現在はネストされた形式を優先して読み取り、フラット形式はフォールバックとして保持しています。これは、このパック独自のヘッダールール——OpenAPI アーティファクトは意図（INTENT）、ライブエンドポイントは真実（TRUTH）として扱う——が、確認すべきキーがまだ存在しなかった期間に機能していなかった事例です。
2. ドキュメントに記載された8つの例のうち3つは、404 を返すスラッグを指定していました。 zone-2-base-training、huberman-lab-sleep-toolkit、the-drive はすべて架空のスラッグです。実際のスラッグは circadian-rhythm-health-foundation、pa-392-sleep-apnea、peter-attia-drive です。また、canon_search({query: "zone 2 training"}) は結果を0件返しました。上流の q はトークンの AND 検索ではなく、フレーズ一致だからです。"zone 2" は一致しますが、"zone 2 training" は一致しません。ツールの説明と tool-examples.json にあるすべての例は、実際に結果が返された呼び出しになりました。

保留中の項目

canon_citations はエクスポートされないままです（CITATIONS_VERIFICATION_LANDED = false）。ゲートは上流でもここでも適用されています。2026-09-14 時点で、GET /canon/{slug}/citations は HTTP 403 を返します——"Citations are not yet public: the underlying links are pending a verification pass. This endpoint currently requires an internal key." 確認作業が完了したことを CanonCannon に確認し、verified: true の行が返されることを確かめてから、フラグを切り替え、結果が返された呼び出しの例を記録してください。

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf など）に追加します。

{
  "mcpServers": {
    "podcast-parser": {
      "url": "https://gateway.pipeworx.io/podcast-parser/mcp"
    }
  }
}

このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/podcast-parser/mcp の tools/list は、上記の表にあるツールに加えて、共有 Pipeworx メタツール——ask_pipeworx、discover_tools、search_within、remember／recall などのゲートウェイ全体で利用できるツール一式——を返します。そのため、表示されるツール数はこの表の数より多くなります。現在、単一パックのエンドポイントには、パック固有のツールに加えて共有ツールが約30個表示されます。接続の initialize レスポンスに正確な範囲が記載されており、その日の状況についてはそれが正式な情報源です。

これは意図的な動作であり、誤って多重化しているわけではありません。メタツールがあることで、このパックでは扱えない質問にも、カタログ全体を横断してルーティングする ask_pipeworx を通じて回答できます。MCP サーバーをもう1つ追加する必要はありません。現在、メタツールなしでパックのエンドポイントをマウントする方法はありません。追加のスキーマによるコンテキストコストがルーティングの利点を上回る場合は、複数のパックエンドポイントに接続するのではなく、フルゲートウェイに一度接続してください。

または、Pipeworx のフルゲートウェイに接続すると、このパックだけではなく、各パックのすべてのツールを直接一覧表示できます。

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

どちらの URL も同じゲートウェイと、同じ1683以上のデータソースに接続します。異なるのは、どのパックのツールが直接一覧表示されるかだけです。ask_pipeworx を使えば、どちらからでもすべてのツールにアクセスできます。

MCP クライアントがない場合：HTTP 経由で呼び出す

このパックには独自の API キー（_apiKey）が必要です。こちらでキーを用意していないため、キーなしで実行できる curl の例はありません。ツールを確認するには、GET https://gateway.pipeworx.io/v1/tools/canon_search を実行してください。ツールを探すには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行してください。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージは、ローカルの stdio MCP サーバーとしても実行できます。Pipeworx アカウントも、ゲートウェイ経由の往復通信も不要です。

{
  "mcpServers": {
    "podcast-parser": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-podcast-parser"]
    }
  }
}

または、直接実行して起動を確認できます。

npx -y @pipeworx/mcp-podcast-parser

stdin/stdout 経由で MCP を使用し、initialize／tools/list／tools/call に応答します。ただし対象はこのパックのツールのみで、上記のゲートウェイ接続で追加される共有メタツールは含まれません。同じソース、同じツールを使用し、ask_pipeworx によるルーティングはありません。

ask_pipeworx の使用

ツールを直接呼び出す代わりに、平易な英語で質問できます。これは、上記のパックエンドポイントでもフルゲートウェイでも機能します。

ask_pipeworx({ question: "your question about Podcast Parser data" })

ゲートウェイが適切なツールを選択し、引数を自動的に入力します。

詳細

• ドキュメントとガイド
• pipeworx.io

ライセンス

MIT