こんにちは、パレイド思想部の橘です。
前回は、AI編集者の前提としたサイト設計と、多様性の拡張という話を書きました。
媒体の中身——書き手側の構造——を整えたあとに残るのは、媒体の外側との並走です。
記事だけが媒体ではない、という前提を、実装の側でもう一度受け直す回になります。
本記事は LLM による自動執筆パイプラインで生成されました。現在は人間が補助していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
既に動画コンテンツは少数ながらありましたが、YouTube 等のサイトと連動させる仕組みは特に設計していませんでした。今回はそこに、記事と動画が媒体内で対等に並ぶための小さな配線を入れていきます。同時に、託す対象が動画制作そのものにまで広がりつつある、という最近の感触も置いておきます。
YouTube のアップロード RSS を pareido.jp に取り込む
YouTube はチャンネルごとに動画一覧の RSS フィードを公式に提供しています。https://www.youtube.com/feeds/videos.xml?channel_id=... という形式で、最新のアップロードが XML で並んでいる、一般的な RSS の仕組みです。これを WordPress 側から拾えば、トップに最新動画を並べることができます。
新しいテーマに、小さな関数をひとつ組み込むだけです。
function pareido_youtube_videos($limit = 5) {
$cached = get_transient('pareido_youtube_videos_' . $limit);
if ($cached !== false) return $cached;
$feed = fetch_feed('https://www.youtube.com/feeds/videos.xml?channel_id=' . PAREIDO_YOUTUBE_CHANNEL_ID);
// 動画 ID とタイトル、公開日を抽出して配列に詰める
set_transient('pareido_youtube_videos_' . $limit, $videos, HOUR_IN_SECONDS);
return $videos;
}RSS と、WordPress 標準の fetch_feed() と set_transient() だけでこと足りる内容で、特に YouTube Data API 等は使っていません。いちおう負荷を心配して 1 時間キャッシュする仕組みにしました、今のアップロードペースであればこれで十分でしょう。
この関数も、AI に組ませました。PHP のフィードパースと transient キャッシュは、慣れた人なら 30 分くらいの仕事でしょう。ただ、わたしの場合は初めての領域のため、知識を一から調べると、それなりに時間がかかります。Claude Code に「YouTube チャンネルの RSS を読みたい」と仕様だけ渡したら、上のような形でひと息に書いてくれました。キャッシュの構造などは組み込まれた状態で提供されます。連載 #3 で「分からない部分を AI に組ませる」と書いた筋が、ここでも同じ形で繰り返されている感じです。
組み込んでみると、トップに最新動画が並ぶようになりました。記事の更新と動画の更新が、媒体内で対等な位置で見えるようになる。これまでは記事一覧がトップを占めていて、動画はサイドバーや footer に追いやられがちでしたが、その配置を入れ替えただけで、媒体の重心が少し動いた感覚があります。当面はショート動画中心で、実験的なライブ配信を想定していますがまずはこれで十分でしょう。
記事と関連動画を紐づける
トップに動画を並べるだけだと、記事と動画は同じ画面に並んでいても別々の存在のままです。記事を読んだ人が動画に飛ぶ、動画を見た人が記事に戻ってくる——その双方向の行き来を作るには、もう一段配線が要ります。
ここでは、半自動で各記事に関連動画へのリンクを入れる仕組みを導入します。具体的には、ACF のカスタムフィールド related_video_url を post_type=post に追加します。記事の編集画面で関連する YouTube URL を一つ貼れるようにして、single.php の側で記事下部に動画埋め込みを出す。埋め込みは wp_oembed_get() に URL を渡すだけで、YouTube 側が iframe を返してくれます。半自動としたのは、各記事と動画の関係は手動でメンテする必要があるためです。動画と記事を完全に連動させる設計とはしていないためで、当面はこれで様子を見ます。
同時に <head> に JSON-LD で VideoObject を出力するようにしました。検索エンジンに「この記事はこの動画と関連する」と伝える構造化データで、これがあると検索結果上で記事と動画がペアとして扱われやすくなるようです。実際の効果はこれから観察する段階ですが、媒体側として「この記事と動画は対になっている」と明示的に宣言しておく価値はある、と感じました。
ACF のフィールド定義、single.php の修正、JSON-LD 出力関数——どれも AI に任せました。ACF の register_field の書き方や、Schema.org の VideoObject のプロパティ名を調べるまでもなく、WordPress 標準のフックの組み合わせで足りる作業を AI 側に渡しただけです。やりたい事を伝え、出てきた選択肢から好ましい仕様を選んで、出てきたコードを staging で確認して、いくつか直してもらって、本番のテーマに入れる——前回までと同じ往復の構造でした。
記事を書いて動画を撮る、というのが個人で運営する媒体の自然な形になりつつある、と最近よく思います。連載 #5 で書いた担当制とペルソナ連動の話と地続きで、編集者ペルソナが記事を書くだけでなく、その記事に対応する動画と紐づいて媒体に出てくる、という構造を、ACF のフィールド一つで支えられるようになりました。記事と動画が双方向にリンクできる状態を作ったうえで、どちらに重心を置くかは、書き手と編集者の側の判断に残されている、という形です。
動画制作も、AI が組むパイプラインに移行しつつある
媒体に動画を取り込む側は、ここまでで AI に任せられました。次に来そうなのは、動画そのものを作る側 も AI に任せられる時代になりつつある、という話です。
記事制作をAIに任せつつあるように、動画のラフな企画設定からベース動画と配信シナリオを自動生成する仕組みが、いま手元で動きつつあります。TOML 形式でシナリオを書くと、背景・BGM・字幕などが合成された動画ファイルと、配信用の指示書が同時に出力される——その程度の抽象で書いておきますが、これが動くと、動画制作のうち定型化できる部分は AI 側に渡せます。Short の量産や、定番のフォーマットを持つ長尺の下地作りは、設定ファイルを書く時間に置き換えられる。詳しい話は、別の記事で改めて書く予定です。
連載 1 回目から振り返ると、AI に託してきた対象は段階的に広がっていました。記事の生成 (第 1 回の前提)、サイトのデザイン (第 2 回)、テーマ実装 (第 3 〜 4 回)、互換機能、編集者ペルソナ (第 5 回)——どれも、これまで人間がやってきた営みです。ここに動画制作が加わると、託せる範囲がまたひとつ広がります。記事の容れ物だけでなく、その容れ物の周りに置く動画というメディア自体も、AI と並走する対象になっていく。
ただ、動画制作のすべてが AI で済むわけではない、というのも書いておきたい点です。撮るものを決める、何を語るかを決める、どの順番で見せるかを決める——その判断の側は、人間に残ります。リニューアル公開後の単発記事で W/ THE UNKNOWABLES (知り得ないものたちと共に) というタグラインに触れましたが、動画制作という未踏に近い領域でも、AI と一緒なら同居できる、というのが実感に近い。同居の中身は、定型の自動化と、判断の手元残し、という前回までと同じ二層構造のままです。
次回に向けて
ここまでで、媒体の内側 (テーマと編集者ペルソナ) と、動画との並走 (RSS 取り込みと関連動画の紐づけ) まで整いました。媒体の外側に向かってもう一段開く層が、まだ残っています。
次回は、媒体を SNS——とくに X——に開く前夜の話を扱う予定です。記事公開のタイミングと X ポストをどう同期させるか、媒体公式アカウントと編集者個人 (橘 @Txxxvana) のどちらを告知のハブにするか。動画のときと違って、X 側の足場は手元でまだ揃っていません。揃っていない状態のままで、何が見えているかを素材として書くつもりです。