find-broll

Bロール検索 — スキルの方法論

トークヘッド動画にBロールを調達して配置するための、再利用可能な方法論です。 実際に動作するエージェントスキルを汎用化したものです。パスやブランドトークンは、ご自身の環境に合わせて調整してください。

⛔ ユーザーによる上書きは最優先です — その効力は継続します

ユーザーが実行中に好みや禁止事項（「ミームはなし」「テキストカードはなし」「政治的なものは一切なし」など）を伝えた場合、それはただちに適用され、そのセッションの最後まで有効です。また、その場でプロフィールのガードレールにも書き込みます。最後にまとめて書くのではありません。禁止されたカテゴリは、二度と検索も提案もしてはいけません。「候補として一つだけ確認する」のも禁止です。明示された禁止事項に違反することは、このスキルにおける最悪の失敗です。エージェントがユーザーの話を聞いていないと示すことになるからです。

⛔ ステップ 0 — オンボーディングの必須確認（毎回、何よりも先に確認してください）

プロフィール（TASTE.md またはユーザーのフォーク版）を開きます。**オンボーディングを省略できるのは、プロフィールの先頭に Confirmed-by: <name> (<date>) という行が文字どおり記載されている場合だけです。**その行がなければ、以下の4つのオンボーディング質問を声に出して尋ね、回答をプロフィールに書き込み、その行を追加します。これは任意ではなく、推測で補うこともできません。

• CLAUDE.md、メモリ、以前の会話、またはこのプロフィールの文章から回答を推測してはいけません。回答を知っていると確信していても同じです。質問すること自体が、この機能の要です。
• 同梱の TASTE.md はサンプルです。現在のユーザーがその原著者であっても、例外ではありません。著者であることと、確認済みであることは別です。
• 「自分の好みのプロフィールを読み込む」という CLAUDE.md の参照指示も、確認とはみなされません。必ず該当行を確認してください。
• 「プロフィールをやり直して」という指示があれば、いつでもオンボーディングを再実施します。

すべてを支配する唯一のルール

**最終的なBロールを選ぶのは、エージェントではありません。ユーザーです。**適切なクリップを選ぶには、しばしば好みの判断が必要です。このスキルの役割は、選択肢を絞り込むことです。各場面を分類し、信頼できる権威ある情報源に検索範囲を絞り、候補を評価し、厳選したコンタクトシートを提示します。最終的な選択はユーザーが行います。

テイストプロフィール — 何かを調達する前に読み込んでください

キュレーションは、このスキルの要となる要素の半分を占めます。実行のたびに、まずテイストプロフィールを読み込みます。そこには、Bロールの特徴（種類やカットの速さ）、トピックごとに分類された信頼できる情報源のリスト、ガードレールが記載されています。このリポジトリには、実際に公開された動画から明らかになった優れた初期設定、TASTE.md が同梱されています。これを使えば、最初からセンスのよい結果が得られます。ユーザーが独自のプロフィールを作るまでは、そのまま使用してください（TASTE.md の「自分用にカスタマイズする」セクションでは、インポートしてから絞り込む方法を説明しています。yt-dlp --cookies-from-browser でユーザーの YouTube 登録チャンネルを取得し、一緒に不要なものを削除してから、ユーザー自身が公開した動画をもとに、その人の特徴を明らかにします）。

オンボーディング時の設定（1回だけ確認し、プロフィールに保存）

オンボーディングを行うタイミング： 同梱されている TASTE.md はユーザーのプロフィールではなく、作者の設定例です。初回実行時に、プロフィールに現在のユーザー名を記載した Confirmed-by: 行があるか確認します。ない場合 → オンボーディングを行います。以下の質問をし、回答をユーザーのプロフィール（ユーザー自身の TASTE.md フォーク）に書き込み、先頭に Confirmed-by: <user> (<date>) を追加します。ある場合 → オンボーディングを省略し、そのまま読み込みます。ユーザーはいつでも「redo my profile」と言って再実行できます。

初回実行時に以下を尋ね、回答を taste プロフィールに記入します（TASTE.md には回答例が1セット含まれています。内容が適切か確認してください）。

1. 音声 — ユーザーは b-roll にかぶせて話しますか（音声をすべて除去：ffmpeg -an）、それともクリップの音声を使いますか？
2. 静止画の動き — 静止画像にはデフォルトでごく控えめな Ken Burns のズームインを適用します（約1.5%/秒、中央を基準、最大約2%/秒）。完全に静止させる設定も選べます。設定より手法が重要です — 下記の「静止画の動き」を参照してください。
3. 出典表記 — 各 b-roll の出典を右下に小さく表示しますか？選択肢：off · white · black · auto（クリップごとにコントラストに合わせて選択）。表記は出典の正式名称とプラットフォーム（「Vinexposium / YouTube」、「Decanter」など）とし、短くまとめます。URLは使いません。映像にすでに右下のバッジがある場合は、そのクリップの出典表記を左下に移動します。注：画面上の出典表記はマナーであり、ライセンスではありません。実際の著作権上の対応としては、公式または信頼できる出典を使用してください。
4. コンセプト用モーショングラフィックス（Remotion） — コンセプト、統計、グラフを見せる場面向けに、ブランドに合ったモーショングラフィックスを生成しますか？「はい」の場合は、既存の Remotion プロジェクトのパス（ブランドトークンを含む）を尋ね、プロフィールに記入します。既存プロジェクトでコンポジションをレンダリングすることは、簡素な手順に含まれます。新しいプロジェクトの構築は一度限りのセットアップ作業であり、明示的な許可が必要です（実行中に行ってはいけません）。プロジェクトがなく、許可もない場合、コンセプトの場面には信頼できる実映像を使用するか、要対応として示します。黙って省略してはいけません。
5. AI 生成 b-roll — デフォルトでは無効です。実映像がない場面に限り、ユーザーが指定した品質モデルを使う場合のみ有効にします。安価な AI 素材で黙って代用してはいけません。

🔓 継続的な許可 — スキルの呼び出しが許可を意味します

素材探しの際、アクセスや検索について会話上の許可を求めてはいけません。/find-broll の実行により、スキルがユーザーに代わって作業する許可はすでに与えられています。以下について「検索しますか／調べますか／アクセスしますか？」と尋ねてはいけません。

• ウェブ検索、ニュースや見出しの検索、oEmbed／埋め込みエンドポイント
• yt-dlp による公開動画やチャンネルのメタデータ検索およびダウンロード
• 公開ページのヘッドレスブラウザーによるキャプチャ（Cookie／同意画面をクリックして進むことを含む）
• 素材探しや閲覧のための、ユーザーのログイン済みブラウザーまたはブラウザー Cookie（プロフィール、投稿、アクセス制限のあるページ）
• ローカルファイル、トランスクリプト、過去のプロジェクトフォルダー、ユーザーのアセットライブラリの読み込み

確認を求めず、そのまま実行して結果を提示してください。ユーザーの好みに関する確認事項として残るのは、素材探しの前のプラン承認と、好みのルートに関わる場面での最終選択です。質問が必要なのは、外部への公開や投稿、有料の操作、ユーザーファイルの削除、重い依存関係のインストールだけです。それ以外の場面で許可を求めて作業を滞らせるのは、礼儀ではなく不具合です。

⚡ LEAN PATH IS THE DEFAULT — ファネルはすべての判断に使うものではなく、選択に迷う場合に使います

このスキルは、抑制を重視することで信頼を得てきました。大がかりなプロセスは、出力を向上させるどころか悪化させます（2026-06-11 のテストでは、フルファネルでの実行はリーンな実行より約 10 倍時間がかかり、構成も劣っていました）。デフォルトは次のとおりです。

• プランの承認が素材の選定です。 ユーザーがビートプランを承認したら（「進めてください」）、客観的なルート（Entity／Receipts／Product）では各ビートにつき最適な候補を 1 つだけ 探して配置します。複数候補の素材探しやコンタクトシートの作成はしません。コンタクトシートを作るのは、ユーザーがそのビートの選択肢を明示的に求めた場合のみです（ミームや文化的なビートは自動で素材を探しません。ルーティング表を参照してください）。
• 調査の深さはプラン作成時に制限します。 正確に素材を探せるだけの参照情報を確認します。プランを立てる前に、素材探しのあらゆるルートを試し尽くすことはしません。段階的なエスカレーションは、ユーザーがビートに同意した後に、簡単なルートで見つからなかった場合にのみ行います。先回りして実施することはありません。
• ビートごとの制限時間： 1 つのビートの素材探しに約 5 分以上かかる場合は、現時点で最良の候補を配置するか、そのビートを外してその旨を伝えます。扱いにくい素材 1 つのせいで編集全体を停滞させてはいけません。
• 検証を 1 回行い、問題箇所を修正するほうが、延々と仕上げを続けるより効果的です。レンダリング → グリッドで確認 → 問題を修正 → 修正したビートのみ再検証、の順に進めます。
• 再試行は禁止です。最初の失敗で方法を切り替え、2 回目の失敗で取り下げます。 1 度失敗した方法は再試行しません（フラグを変えたり、「もう 1 回だけ」試したりしません）。すぐに別の方法へ切り替えます。2 つ目の方法も失敗した場合は、そのビートを取り下げ、プランに記載して先へ進みます。3 回目まで試す価値のあるビートはありません。そのビートなしで編集を仕上げます。これはキャプチャ、ダウンロード、レンダリング、ブラウザー操作など、すべてに適用されます。（Louise：「何度も失敗することはやめて、時間を節約するために飛ばしてください。」）
• 実行中に重い依存関係を自動インストールしません（conda、aligners など）。代替手段を使い、その旨を記録し、納品後にインストールを提案します。

ビートごとではなく、ソースごとに素材を探す（素材探しを大幅に高速化）

プランの承認後、素材の保存場所を基準にビートをまとめ、それぞれのソースを 1 回だけ取得します。

• 対象のウェブサイトをページ全体で 1 回キャプチャすれば、4～6 個のビート（沿革、チーム写真、地図、商品写真など）をカバーできることがよくあります。同じキャプチャから、ビートごとに切り抜きます。
• 公式チャンネルや映像 1 本で、複数のビート（空撮、クローズアップ、作業工程のショットなど）をカバーできることがあります。1 回だけダウンロードして、複数の区間を切り出します。
• ダウンロードはすべて 1 つのバックグラウンドジョブにまとめます（まずメタデータだけを検索し、選んだ項目のみダウンロードします）。キャプチャは 2 つ目のバッチとして並行して実行します。ビートごとに順番に取得してはいけません。
• 再レンダリングや v2 で再取得せずに済むよう、ダウンロードした未加工データはプロジェクトの隣のディレクトリ（assets/raw/）にキャッシュします。

量より正確さ

数が多くて質が中程度のビートより、数が少なくても完璧に正確なビートを選びます。やめるべきなのは、割り当て数を満たすためにキーワードだけで素材を合わせる習慣です。

• すべてのビートで、引用箇所ごとに解釈します。 まず 「この一文は実際には何について述べているのか？」 と書き出してから、それに合った素材を探します。実際の要点を正確に示す素材が見つからない場合は、ビートを取り下げます。無理に埋めてはいけません。 関係のない B ロールを入れるより、B ロールを入れないほうがよいです。
• デフォルトのテンポは前半に重点を置きます。 導入やフックでは密度の高い、テンポのよい B ロールを使い、その後の本文では控えめかつ正確に使います。
• ただし、「スキップ」は最後の手段であり、デフォルトではありません。 ビートのスキップを提案する前に、使える選択肢をすべて声に出して検討します。レシート？ 見出し？ 人物の顔？ 製品 UI？ コンセプト図？ すべての選択肢が本当に使えない場合にのみスキップします。固有名詞のない修辞的な一文こそ、感情を示すレシートやコンセプト図が活きる場面です。

まずトピックを理解し、そのうえでキーワードではなく意味をもとに素材を探す

1. 何かを探す前に、トランスクリプト全体を読んで主張を理解します。各行を何で表現するかは、文脈で決まります。
2. Bロールで表現するのは言葉ではなく、要点です。 文中の固有名詞が、参照先とは限りません。
   • 「CompanyのX」 → 会社のロゴではなく、その人物とその人の仕事。
   • 「Companyがしたように」 → Companyがしたこと。
   • 「Personが言ったこと」 → その人の顔ではなく、発言の内容（引用、投稿、エッセイ）。
3. 文字どおりか、イメージを伝えるか： 具体的な名詞（製品、実名の人物、出来事）→実物を見せます。動作や抽象概念→それを伝える映像を使い、文字どおりに再現しないでください。
4. 必須の参照元チェック — すべての場面で： このセリフの裏に、実在する資料はあるか？ 引用、統計、「みんなが言っている」、企業名の出るイベント、「見た／読んだ」といった表現は、ほぼ必ずツイート、見出し、レビュー、投稿などが存在することを意味します。その資料は第一候補です。それを探すのがこのスキルの役割であり、ユーザーが追加で依頼する必要はありません。

フレーズの種類 → 探す素材（判断表）

ナレーションの内容	探す素材
「みんなが言っている」／議論	ツイート、見出し、投稿、検索結果のスクリーンショット
数字／統計（「月額24ドル」「登録750件」）	画面上にその数字が表示されているもの — 料金ページ、ダッシュボード、グラフ、統計カード
成長／「バズった」	上昇するグラフ、または指標が表示されたバズ投稿そのもの
低迷／「急落している」	下降するグラフ、エラー画面、不調に陥っている対象
「研究によると」／権威ある情報	研究・論文の見出し、またはカメラに映る専門家
直接の引用	本人の投稿やブログの本物のスクリーンショット（合成の引用カードより優先）、または本人が発言している映像
時代／「昔は」	その時代のアーカイブ映像やヴィンテージ映像
場所	その場所の導入ショット
比較／「X対Y」	全画面の映像を順番に見せます — エージェントが作った分割画面は使いません
「仕組み」／手順を追った説明	手順の画面録画やモーショングラフィックス
動作のある話（「彼は毎朝……していた」）	場所と動作を、雰囲気が伝わる形で見せます — 文字どおりに再現しません
比喩（「ロケットのように」）	比喩の対象は効果がある場合のみ使用します — 比喩は原則として省きます
感情／リアクションの場面	タイミングと雰囲気を提案し、ミームはユーザーに用意してもらいます
クリエイター自身のコンテンツ（「私の動画」）	実際のクリップや投稿を自分で参照します — 検索はしません

ジャンル → カバー範囲の基本（種類と量）

ジャンルは、トピックよりもBロールの種類と密度をよく予測できます（受付時に確認したスタイルとテンポの回答があれば、そちらを優先します）。

• 競合／論争 → 事実を裏付ける素材が中心、多め（カバー率約40～60％）
• 意見／解説 → テキストや概念のカード＋裏付け素材を短く挿入（約20～30％）
• ストーリーテリング／リスティクル → 人物、アーカイブ、製品（約40～60％）
• ポッドキャスト／ウェビナー／インタビュー → 短い挿入のみ（約5～10％）。Bロールは言及や主張を示し、残りはトーク映像で伝えます。

ルーティング — 3種類以上のBロールは、3種類以上のソースに振り分けます

検索する前に、すべての場面を分類します。

ルート	条件	ソース
レシート	時事性がある — ドラマ、ニュース、苦情、現在の主張や統計	ツイート／記事の見出し／レビューを新しい順に並べ、鮮明なスクリーンショットとして取得します
エンティティ	人物、実物の商品、または歴史的な出来事	公式／権威あるチャンネル — ランダムな投稿ではなく、正規のクリップ
コンセプト	図解する必要がある抽象的なアイデア（プロセス、メンタルモデル、統計）	ブランドスタイルに合わせたカスタムモーショングラフィックス（例：Remotion）。プロフィールにRemotionプロジェクトのパスがある場合はこれがデフォルトです — または権威あるソースの実写映像

⛔ カードで実物の映像を置き換えてはいけません。 その場面で具体的なエンティティ（ブドウの品種、商品、場所）が挙げられ、実写映像が存在するなら、生成したテキストカードは失敗です — ユーザーの好みの傾向からカードが好まれるとわかっている場合でも同じです。カードを使うのは、実物の映像がないアイデアに限ります。（2026-06-11：「3種類のブドウ」の場面で、公式映像に実際の房が映っていたのに、紺色のテキストカードが使われました — 誤りです。） | カルチャー／ミーム | センスで判断するクリエイターのクリップやジョーク | エージェントが検索・取得することは絶対にありません。 プランには場面と雰囲気（「2:31のオチ、淡々と」）を提案します。ミームはユーザーが自分のライブラリから用意するか、その場面を削除します。エージェントが見つけたミームは、これまで試したものがすべて失敗しています。 |

判断基準（順番どおり）： 今起きていることか？ → レシート。人物／商品／出来事か？ → エンティティ（公式ソース）。抽象的なアイデアか？ → コンセプト（モーショングラフィックス）。リアクションの場面か？ → ミーム（ユーザーのライブラリ）。

YouTubeが最も適しているのは、エンティティのルート（人物、商品、歴史的な出来事）です。抽象的なアイデアに無理に使わないでください。そうした場面にはコンセプトの手法が適しています。

人物のクリップ — 名前ではなく、その人物が登場する場面を探します

その人物がただ映っているだけのクリップは、関連するBロールではありません（人物クリップで最も多い失敗です）。

1. まず言及の文脈を書きます。その人物について、セリフは何を述べていますか — 特徴、行動、主張、出来事は何ですか？
2. 検索語句＝人物名＋言及の文脈。名前だけでは検索しません。 「Steve Jobs iPhone keynote 2007」のように検索し、「Steve Jobs」だけでは検索しないでください。名前だけの検索では、一般的な記者会見のクリップが表示されます。
3. 提示する前に確認します。 候補ごとに、タイトル／日付／自動字幕から「このクリップでXが<どこで、いつ、何をしている／話しているか>」を記入します。記入できない場合、その候補は使えません。
4. 文脈に合うものが見つからない場合は、その旨を伝えます。「汎用」と明記した正規のクリップを提示するか、本人の作品／引用／見出しに切り替えます（多くの場合、こちらのほうが適しています）。
5. 「番組／ポッドキャスト」≠「今回のエピソード」 — 番組への言及には、その番組で継続的に使われているブランディングを使います。特定エピソードのゲストアートは使いません。

パレット — 組み合わせて使い、デフォルトでウェブサイトのスクリーンショットに頼らない

• 人物（動画） — 名前の挙がった人物の場合、その人が話している実際の動画クリップを使います（静止した顔写真は使いません）。フレームの一部だけに映る人物や分割画面の人物には、画面いっぱいに引き伸ばして切り抜くのではなく、ぼかした背景を使います。ポッドキャストやパネルの編集では、元の録画にゲストが映っています。外部で探し回るのではなく、ゲストのタイルをライブ動画として切り抜きます。視聴者が知らない人物の顔写真は、役に立たないBロールです — 知名度の低い人物は、顔ではなくその人の作品（投稿、製品、講演など）を見せます。有名人の顔は、静止した肖像ではなく、文脈や行動の中で映します。⛔ また、話者が話している同じ動画の中で、その話者自身のタイルにBロールとして切り替えるのは絶対に避けてください — 視聴者はすでにその人を見ているため、映像が乱れたように見えます。タイルの切り抜きは、別の動画でその人の顔を使う場合に限ります。
• 製品／UI — 実際のアプリUIまたは実際の画面録画を使います（自分で録画したもの > 公式チャンネル > なしの順で優先し、無関係な第三者のチュートリアルは除外します）。デモは、入手可能な中で必ず最新のものを使ってください — 製品UIはすぐに変わるため、アップロード日を確認し、候補と一緒に表示します。
• 根拠資料 — ツイート、見出し、レビュー、検索結果を使います。企業名が挙がっている場合は、ホームページよりも実際の出来事（IPO、資金調達、節目など）を伝えるニュースの見出しを優先します。
• 参照用スクリーンショット — 引用元となった実際の投稿、エッセイ、ページを使います（本物のスクリーンショットは、合成した引用カードよりも優れています）。対象者自身のウェブサイトを、ページ全体をキャプチャして表示領域ごとに切り抜く方法は、宝の山です — 履歴ページ、チーム写真、地図、製品ページなどがあります。
• コンセプト用モーショングラフィックス — アイデア、グラフ、統計に使います。ブランドの雰囲気に合わせて作り、いかにも合成に見えるストック素材は使いません。
• 実際の映像／雰囲気を伝える映像 — ストーリー、動き、雰囲気が伝わるストック映像を使います。すべてのフレームを目視で確認し、ウォーターマーク、映像に焼き付けられた字幕、AI生成の粗悪な素材がないかを確認します。
• ミーム／リアクション — ユーザーが厳選したライブラリからのみ使用します。エージェントが提案するのは使うタイミングであり、ミームそのものではありません。プロフィールまたはユーザーがミームを禁止している場合、このカテゴリは存在しません。

計画の60％を超える部分がウェブサイトのスクリーンショットなら、その計画は誤りです。

テンポのガードレール — 抑制がセンスとして伝わる

• ビートは約2～4秒にします。 約1.2秒未満では内容が読めません（1秒未満のショットは、意図的なバーストモンタージュ1回の中で使う場合を除き、使いません）。
• イントロ1つにつき、バーストモンタージュは最大1回（リストを見せるビートで、3～4枚の静止画を素早く切り替えます）。2回以上は混乱を招きます。
• イントロ1つにつき、長い表示（5秒超）は最大1回とし、本当に説明が必要なビートでのみ使います。地図を8秒間静止表示しても、間が空くだけです。
• 迷ったら、素材は少なく、実在するもので、見てすぐわかるものを選びます。最も優れた編集では、ビートごとに最適だと明確にわかる素材を1つ使います。素材の数を増やすのではありません。

動きを優先 — 動画は静止画より優先

同じ素材に動くバージョンと静止バージョンが両方ある場合は、動く方を使います。製品のホームページより製品公式のデモ動画を、静止画のキャプチャよりスクロールする実際の画面録画を、顔写真より実際の映像からの抜粋を優先します。静止画を使うのは、読むことが目的の場面（ツイート、見出し、レビューなど）に限ります。判断基準で同点の場合は、動きのある方を選びます。

静止画の動き — サブピクセルによるごく控えめなズームのみ。ffmpeg zoompanは禁止

試行錯誤を経てわかった重要な違い — 禁止されているのは効果ではなく、手法です。

• ffmpeg zoompan／クロップしながらのパン／スクロールしながらのパンは、速度やスーパーサンプリングの有無にかかわらず禁止です。 整数ピクセル単位でサンプリングするため、約1％／秒のズームでもカクつきます。徹底的に検証しました（4倍ランチョス・スーパーサンプリング → zoompan → 縮小） — それでも揺れます。再試行に時間を費やさないでください。
• サブピクセルレンダリングが適切な方法で、滑らかで控えめなズームを実現できます。
  • PILの手順（実証済み）： フレームごとに img.resize((W,H), Image.LANCZOS, box=<float coords>) を実行し、rawvideoとしてx264に渡します。浮動小数点のbox座標によってサブピクセルサンプリングを行います。Pythonで約30行です。
  • Remotion（CSSのtransform scale）も、プロジェクトのひな形が用意されている場合は同様に有効です。
• デフォルト：ズームインのみ、中央配置、約1.5％／秒、最大約2％／秒、静止画のみ — パン、ズームアウト、実際の動画の上に合成した動きを重ねることは禁止です。プロフィールごとにオプトアウトできる場合は、完全な静止画にします。

評価基準 — 提示する前に候補をすべて採点する

1〜5点で採点し、基準点に満たない候補は除外します。

1. 鮮度との適合性 — 時事性があるか、定番として使えるか。時事性がある題材に古いクリップを使う場合は不合格です。
2. 情報源の信頼性 — 一次情報／公式／信頼できる情報源か、無名のクリエイターか。
3. 関連性 — 関連付けが曖昧なものではなく、名前が挙がった対象そのものを描写しているか。人物のクリップの場合、関連性は文脈との一致度で判断します。
4. 認識しやすさ／インパクト — ひと目で伝わり、スクリーンショットでも見栄えがするか。
5. フォーマットとの適合性 — 音声なしでも成立し、約2〜6秒で、画面いっぱいに表示でき、解像度が720p以上か。

まず時事性を確認してください — 今月のツイートは、現在の話題について何年も前に投稿されたYouTubeクリップより優先します。

検索構文 — 常に、範囲を絞った検索を優先する

• Entity系の話題では、YouTubeチャンネル内検索をデフォルトにします： yt-dlp "https://www.youtube.com/@<handle>/search?query=<q>" --flat-playlist --print "%(title).75s ||| %(duration_string)s ||| %(id)s" — 公式または信頼できるチャンネル内を検索します。代替手段は ytsearchN:<query> です。範囲を絞らない検索結果には「⚠️ 信頼できる情報源以外」とフラグを付けます。
• まずメタデータを確認し、ダウンロードは後で行います： --flat-playlist --print は数秒で済みます。選んだ候補のみダウンロードしてください（-f "bv*[height<=1080]+ba/b"）。
• ログインなしでツイートを確認する方法： https://platform.twitter.com/embed/Tweet.html?id=<TWEET_ID> を使うと、認証なしでヘッドレス環境でも見やすいカードを表示できます（&hideThread=true を追加し、scripts/cdp_capture.py でキャプチャします）。ツイートに添付された実際のメディアは、https://cdn.syndication.twimg.com/tweet-result?id=<ID>&token=a から取得できます。公開する前に、添付メディアに実際に何が表示されるか確認してください。
• 汎用的で印象的なストック映像は、YouTubeが苦手とする分野です： 「free to use / no copyright」を条件に追加します。ウォーターマーク付きのストックサイトのプレビューや、字幕が映像に焼き込まれたクリップは却下してください。YouTubeでまともな候補が見つからない場合は、代わりに実際のストックサイト（Pexels / Mixkit / Coverr）をすすめてください。

話題について合意したら、素材探しはエージェントの仕事です — エスカレーション手順

「ログインが必要」という主張は、試してみて初めて証明できます。作業をユーザーに返すための口実にしてはいけません。話題をユーザーに返す前に、以下をすべて試してください。

1. ローカルの成果物 — ユーザーのメモ／ダウンロード／過去のセッションから、該当するリンクやハンドルをgrepで検索します。
2. 本人特定のための調査 — ありふれた名前だけでなく、投稿への言及に含まれる特徴的なフレーズを使ってウェブ検索します。短縮リンクを解決し、oEmbedエンドポイントで認証なしに投稿者を特定します。
3. 通常の yt-dlp — 公開プロフィールや動画では、通常ログインは不要です。
4. yt-dlp --cookies-from-browser — ユーザーがログイン済みのCookieを使うと、多くのアクセス制限を回避できます。
5. ヘッドレスChrome + CDP — 同意画面の背後にあるコンテンツをキャプチャする場合は、すべてのフレームコンテキストで「accept」をクリックします（CMPはiframe内に表示されます）。代替手段としてオーバーレイを除去します。その後、キャプチャを目視で確認してください。目視で確認していないスクリーンショットを渡してはいけません。
6. ユーザーがログイン済みのブラウザー（利用可能な場合はbrowser-automation MCP）。
7. これらをすべて試しても本当に見つからない場合のみ → 探してもらう対象を具体的に列挙し、試した内容を記載します。

配置タイミング — 単語の前ではなく、その語句に重ねるか直後に置く

• キーワードが発話されるタイミングを基準にし、少し先行させます（約+0.2秒）。カットがキーワードの発話中、または直後に入るようにします。単語より前にBロールを置くと、ミスのように見えます。
• タイミングの基準：Whisperの単語単位タイムスタンプ（--word-timestamps True。文字起こし時に1回実行し、追加ツールは不要です）。キーワードの単語時刻を見つけ、そこから+0.2〜0.5秒後を基準にします。Whisperの単語末尾の時刻はやや早めで、単語の長さにポーズも含まれるため、迷った場合は遅めにします。遅めなら意図的に見えますが、早めだとミスのように見えます。
• (精度を約10〜20msにするためMFAによる強制アラインメントを試しましたが、2026-06-11に削除しました。実行コストに見合わず、実際にはWhisperと遅めの調整で十分な精度が得られます。再導入しないでください。)
• オチの場合は、オチの後のタイミングに合わせます。
• 隣接するBロールをつなげます： 2つのカットアウェイの間隔が半文ほどより短い場合、最初のクリップを2つ目の開始位置まで延長します。その間に話者の顔が2秒未満だけ映ると、ミスに見えます。（前のクリップを延長してください。次のクリップは、そのキーワードより前に始めてはいけません。）

合成 — 全画面表示、複合映像なし

• レターボックスにせず、カバークロップする： scale=W:H:force_original_aspect_ratio=increase,crop=W:H。
• エージェントが作成した複合映像は禁止： 画面分割、2画面表示、凝ったフレーミングは使いません。参照する人物が2人いる場合は、全画面表示の映像を順番に使用します。カバークロップ以外で許可する処理は、ぼかし背景（拡大してぼかした映像の上に、サイズを合わせたクリップを重ねる）のみです。
• 部分的な映像ソース／画面分割の被写体： カバークロップではなく、ぼかし背景を使用します（半分の画面をカバークロップすると、顔が大きくズームされます）。
• 解像度の低いソースを全画面表示に拡大しないでください。より高解像度のソースを探してください。

イテレーションの規律 — Bロールのマニフェスト

再レンダリングで最もよく起こる失敗は、ユーザーがすでに承認したビートを黙って削除することです。納品物の隣に**BROLL-MANIFEST.mdを用意します。ビートごとに1行（開始／終了・ビート・素材・承認したバージョンを含むステータス）を記載し、さらに「削除済み（再追加禁止）」リストを設けます。再レンダリングの前に必ず**マニフェストを読み、新しいカットに承認済みのビートがすべて含まれていることを確認し、新しいビートを追加してステータスを更新します。ユーザーが明示的にカットを指示しない限り、承認済みのBロールを削除してはいけません。

自己検証 — ユーザーに見せる前にすべてのカットを確認する

レンダリングのたびに、すべてのビートの中間点とすべてのつなぎ目（Bロール間、Bロールと人物映像間）でフレームを抽出し、グリッドに並べて確認します。問題を修正し、再検証してください。グリッドに問題がなくなるまで、レンダリングは完了ではありません。

明示的な自動却下チェックリスト — 次のいずれかを含むフレームは、例外なく不合格です：

1. ソースクリップに焼き込まれたキャプション／字幕
2. 見知らぬ人物を特定する名札／ローワーサード
3. 透かしやチャンネルロゴ（公的機関の隅にあるバッジは要注意の例外であり、無条件に許可されるわけではありません）
4. 話者自身の顔／タイルが、その人自身の動画でBロールとして表示されている
5. ビートが実際に撮影可能なものを具体的に示しているのに、生成カードが使われている
6. テンプレートのような複合映像（横に並んだ2つのポートレート、コラージュカード）
7. レターボックス、小さく浮いたコンテンツ、または目に見えるぼかし背景のフレーミング不備
8. 2つのカットアウェイの間に1秒未満のトーキングヘッド映像が一瞬挟まっている — つなげます。最初のビートを2つ目の開始位置まで延長してください（2つ目を早く始めてはいけません）。

このリストに沿って、項目ごとにグリッドを評価します。リストを使わずに「問題なさそう」と判断すると、透かし入りのクリップが納品されます。

取得とフォーマット（編集しやすく、無音、全画面表示）

• 大きなソースでは、まずプロキシを作成する： 元動画が4K／HEVC／500MB超の場合は、ほかの作業に入る前に1080pの作業用コピーに変換します（ffmpeg -hwaccel videotoolbox -i src -vf scale=1920:-2 -c:v h264_videotoolbox -b:v 6M -c:a aac proxy.mp4）。以降のすべての手順（フレームのスキャン、レンダリング）は、プロキシを使うことで5～10倍速くなります。

• 低解像度の結合済みストリームを取得せず、実際のストリームを選択します（-f "bv*[height<=1080]+ba/b"）。

• --download-sectionsを最終カットに使わないでください（可変フレームレートによるカクつきが発生します）。短いクリップをダウンロードしてから、再エンコードしてトリミングします。

• 標準フォーマット：固定フレームレート、カバークロップによる全画面表示、音声なし：

  ffmpeg -ss <in> -t <dur> -i full.mp4 \
    -vf "fps=30,scale=1920:1080:force_original_aspect_ratio=increase,crop=1920:1080,setsar=1" \
    -an -c:v libx264 -crf 18 -preset slow -pix_fmt yuv420p -movflags +faststart out.mp4
  

• 帰属表示を有効にした場合は、フォーマット時にoverlayを使って小さなクレジットラベル（PILでレンダリングしたPNG、約70％の不透明度）を合成します（ffmpegのビルドによってはdrawtextが使えない場合があります）。

ワークフローの概要

1. テイストプロファイルを読み込む／トピックを設定する — TASTE.md（またはユーザーのフォーク）を参照します。指紋、好み、信頼できるソースを、この動画のトピックタグで絞り込みます。
2. スタイルとテンポを確認する — 形式（ポッドキャスト／チュートリアル／高速カット／長めの導入）と密度を尋ねます。これらはジャンルのデフォルト設定より優先されます。
3. 文字起こしを取得する — 貼り付ける、エディターから取得する、または文字起こしする（GPU Whisper、単語単位）。長尺（約10分超）の場合は、Bロールとしての価値をセグメントごとに評価し、価値の高いものから選びます。1時間分を均等にBロールで埋めないでください。
4. 分類して提案する（まだ取得しない） — 各ビートに解釈、ルート、参照資料の調査結果、パレットの配分を注記します。プランを提示してユーザーの反応を待ってからソースを探します。
5. 範囲を絞って検索する — 信頼できる公式ソースに限定し、候補を評価し、人物のクリップを言及時の文脈と照合して確認し、弱いものは除外します。
6. コンタクトシートを作成 → ユーザーが選択します。
7. （任意）配置してレンダリングする — フルブリード＋無音で編集し、該当する単語を基準に配置し、隣接するビートをつなぎ、マニフェストを更新します。納品前に自己検証グリッドを作成します。

ツール

• 文字起こし： 文字起こしテキストにはGPU Whisperを使用します（大規模モデル — 文字起こしが理解の基盤となるため、テキストの正確さが重要です）。
• アンカーのタイミング： Whisperの単語単位のタイムスタンプ＋後ろ寄せ（キーワードより0.2〜0.5秒後）。
• 検索／ダウンロード： yt-dlp（APIキー不要）。公開ページのスクリーンショットにはヘッドレスブラウザー＋CDPを使用します（同意画面では各フレームのコンテキストで「同意する」をクリックし、目視で確認します）。
• モーショングラフィックス： Remotion（または同様のツール）を使用し、フルブリード＋無音でレンダリングします。
• 静止画のズーム： scripts/zoom_still.py（サブピクセル精度のPIL float-box → x264。ポートレートや特殊なアスペクト比には--blurfillを使用し、zoompanは決して使用しません）。
• 同意画面のキャプチャ： scripts/cdp_capture.py（CDP経由のヘッドレスChrome — 各フレームのコンテキストで「同意する」をクリックし、CMP iframeに対応。鮮明な領収画像にはCDP_SCALE=2を使用）。
• カットアウェイのレンダリング： scripts/render_cutaways.py（セグメント連結テンプレート：ビート区間ごとにベース映像を差し替え、音声には手を加えません）。
• 合成： ffmpeg。コンタクトシートにはImageMagickを使用します。