mcpField
E
explainer-vertical-noticias

explainer-vertical-noticias

github.com/guillebeその他07 回インストール1 日前に更新
リポジトリ

explainer-vertical-noticias について

Explainer vertical noticiasは、3つのチェックポイントで人が確認する、20秒の縦型ニュース解説動画を制作するスキルです。情報源の記録、時間配分付き台本、絵コンテ、レンダリング、批判的レビューを案内し、編集判断は人に委ねます。

主な機能

  1. 01情報源の記録と変動する数値の確認
  2. 02時間配分付き台本の作成と承認
  3. 03絵コンテの作成とバージョン確認
  4. 04レンダリングと音声・可読性の確認
  5. 05修正内容とレビュー結果の記録

活用シーン

  1. 01ニュース記事から縦型短編解説を制作する
  2. 02報道された数値の変更に合わせて動画を更新する
  3. 03公開前にレンダリング済み解説を確認する

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/guillebe/explainer-vertical-noticias --skill explainer-vertical-noticias

インストール後、Claude Code で/explainer-vertical-noticiasを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
critico.md
footage.md
sonido.md
scripts/
buscar_commons.py
medir_nivel.py

詳細

ニュース解説ショート

エージェントが作る20秒のニュースショートです。人間は3つのチェックポイントで進行を管理します。Media Party Buenos Aires 2026のワークショップで、2つの解説動画を繰り返し改善して完成させます。対象はパナマ地震(v4からv12)と、トレド県ウルダの列車衝突事故(v1からv7)です。

基本的な考え方は、エージェントが制作とチェックを何度も行い、人間が編集上の判断を下してチェックポイントで決定する、というものです。自動チェックでは内容の誤りを検出できないため、レンダリング結果には必ず敵対的な批評を加えます。

始める前に

  • hyperframes スキルを読み込みます(構成とレンダリングに必須の入口です)。HTMLを書く前に hyperframes-core も読みます。
  • プロジェクトでHyperFramesのバージョンが指定されている場合は、そのバージョンを使います。
  • プロジェクト独自のガイドライン(スタイル、品質の参考資料)がある場合は、台本を書く前に読みます。

ワークフロー

0. 記事とデータ(source.md)

サンプルのフォルダーに source.md を作成、または更新します。記事のリンク、日付、著者、画面に表示する各データの引用文(言い換えず、ページのHTMLからコピーしたもの)、公式データ、情報源ごとの相違点を記載します。批評者が数値を照合する資料になるため、台本を書く前に用意しておく必要があります。

日付を確認します。発表から数日経っている場合は、ショート動画内にいつ時点の情報かを明記します(「Sinaproc、第2報(10/10)」)。日付のない古い発表を表示すると、フックで誤解を招きます。

  • 作業中にデータは変わります。 発表内容は時間単位で更新されることがあり、公式報告が翌日に届くこともあります(列車衝突事故では、調査機関の初報が速度を訂正しました。v7の2回後のことです)。レンダリングのたびに数値を再確認します。変更があれば新しいバージョンに反映し、それ以前のバージョンには当時のデータを残します。
  • 署名を確認します。 著者名は <meta name="author"> または画面上の署名にあります。JSON-LDでは写真のクレジットが著者として記載されていることがあります。
  • 推定値には出典を付けます(「約200 km/h・大臣の推定」)。後からより信頼性の高い情報源が見つかった場合は差し替えます。
  • 同じ単位でも、異なる概念を混ぜてはいけません。 規則上の上限(40 km/h)と、その区間の最高速度(80 km/h)は別のものです。
A. 時間ごとの台本(チェックポイントA)

時間 · 画面に映るもの · テキスト の表を提案し、コードを書く前に承認を待ちます。これまでの批評から得られたルールは次のとおりです。

  • 伝える内容は1つに絞ります。 v5では20秒に9つのデータを入れたため、どれも伝わりませんでした。日付、規模または中心となる事実、場所、影響をまとめたブロックがあれば十分です。
  • ストーリーを形作るデータを探します。 対比が重要な場合もあります。「規則では40 km/h。AVEは約200 km/hで走行」は、規則だけを示すよりも多くを伝えます。
  • フックにはデータと日付を入れ、最初のフレームから全文を表示します。 テキストがないと、映像の最初の0.5秒は別のものと解釈される可能性があります。
  • 読了時間: テキストごとに最低でも0.5秒+単語1つにつき0.3秒必要です。20秒なら、合計で約50語が目安です。
  • 同じ図表内で単位や項目を混ぜないでください(「被害を受けた住宅」「住居」「一部損壊」は合算も比較もできません)。記事にない合計値を作ってはいけません。
  • 記事の強調点に従います。 記事がある州を強調しているなら、図表でその州を最後にしてはいけません。
  • 記事が答えを示している質問で締めくくり、記事へのリンクを付けます。
映像素材と資料

references/footage.md を読みます。要点は、scripts/buscar_commons.py で検索すること(素材情報にあるライセンス、日付、場所、著者を確認)、記事に書かれている内容が映っているショットだけを使うこと、場所と日付を確認できないショットは使わないことです。ユーザーが内部利用に限り権利のある素材を使うと決めた場合は、その旨を source.md に記録し、リポジトリを公開する前に知らせます。ダウンロードするたびに、ファイル、出典、サイズを提示して許可を求めます。

B. ストーリーボード(チェックポイント B)

構成を書き、hyperframes check を実行して(エラー 0 件)、各シーンのフレームを hyperframes snapshot --at … で取得します。storyboard/vN-escena-K.png として保存します(以前のバージョンのファイルが入っているため、フォルダーは絶対に削除しないでください)。それらを見せ、自分で気になる点を指摘してから、フィードバックを待ちます。ワークショップのコメント形式は t=… · dónde · problema → cambio です。

試行錯誤から得られた構成上のルール:

  • 数値は最終的な値で表示します(スケールまたは不透明度)。カウントアップするカウンターは、ほとんどの時間に誤った数値を表示するため、キャプチャのタイミングによってどの数値も写り得ます。
  • 全国的なデータを特定の場所の写真に重ねてはいけません。その場所に関するデータだと受け取られてしまいます。
  • リズムは各シーンの中に持たせます(1~2 秒ごとに何かが登場する、描かれる、または動くようにします)。カットやデータを増やしてリズムを作るのではありません。
  • グラフはナレーションのリズムに合わせて描画し、固定のシステムに従わせます。無地の背景、アクセントライン、単位を含むタイトル、下部の出典で構成します。
  • クレジットと出典は 30 px 以上にし、安全領域内に配置します(テキストは上から 260 px、下から 480 px、右から 180 px の範囲内に配置します)。
  • 横向きの映像を縦向きで使う場合は、デザインされたバーの間に全体を表示します。9:16 にトリミングすると(ピクセルが粗くなり)、ぼかした背景に重ねると(安っぽく見えます)。チャンネルのウォーターマークはトリミングしてください。
  • 装飾要素を実際の記録のように見せてはいけません。地震計の波形や、軸も値もなく、実際の記録のように見えない説明用のグラフを使います。
  • 図解は、図解として描くか、写実的に描くかのどちらかにします。中途半端にしないでください。列車衝突のケースでは、信号図のような図解が効果的でした。線路は線、列車は番号付きの線、信号は赤で示します。ラベルは注釈に記載されたものだけにし、「概略図・位置はおおよそのもの」と明記します。
  • 動きはデータと矛盾しないようにします。衝突直前に列車が加速すると、速度記録と食い違います。車両がシーン間で突然別の位置に現れるのも同様です。
  • 同じ背景が続く箇所でカットしないでください。次のデータも同じ図解に含められるなら、別の画面に切り替えるのではなく、図解の中に加えます(たとえば、線路上に速度標識を表示します)。
  • 安全領域は公開先によって異なります。SNS 向けならすべて安全領域内に配置します。SNS 向けでない場合は、出典やクレジットをフレーム下部に配置できます。
音声

references/sonido.md を読んでください。事故の実際の音声を前面に出し、その下に音楽を小さく流し、全体を −14 LUFS にノーマライズします。約 110 Hz 未満の低音は携帯電話では聞こえません。ラウドネスだけでなく、聞こえる周波数帯域を測定してください。

メディアが事故の音声(録音や通話)を公開している場合は、ダウンロードする前に許可を求め、出典を明記し、話者が分かるように文字起こしを画面に表示します。フレーズ全体が収まるようにシーンを延長してください。クリップが 20 秒を超えてもかまいません。

C. レンダリング、レベル確認、批評(チェックポイント C)
  1. 新しい番号を付けて <ejemplo>-vN.mp4 にレンダリングします。レンダリングではフレームがディスクに保存されます(20 秒で 1.2~1.4 GB)。容量不足で失敗する場合は、キャプチャと並行してエンコードする --workers 1 を使用します。
  2. レベル確認を実行します:
    python3 scripts/medir_nivel.py <ejemplo>-vN.mp4 --html index.html
    
    何かが 2 秒を超えて静止している場合、テキストの表示時間が読み上げに必要な時間より短い場合、ラウドネスが −14 LUFS から大きく外れている場合、または携帯電話で聞こえる音声信号がない秒がある場合は失敗します。カット箇所は報告しますが、必須とはしません。地震を扱った v5 では、カットを増やそうとしたことで読みやすさが損なわれました。
  3. 動画を作成していない新しいエージェントを使い、敵対的な視点から批評させます。ブリーフは references/critico.md にあります。
  4. 動画、前のバージョンとの指標の比較、批評担当者の P0、P1、P2 をユーザーに見せます。P0 は修正し、P1 と P2 はユーザーが判断します。
バージョンと記録
  • 変更のたびに新しいバージョンを作成します。index.html は作業コピーです。ひとつ前のバージョンは versiones/index-vN.html(パスは ../)に保存し、レンダリング結果は <ejemplo>-vN.mp4 に出力して、source.md の「バージョン」に1行追加します。-vN を上書きしたり、番号のない MP4 を残したりしないでください。
  • source.md には、ライセンス、日付、場所、URL を添えて新しい素材も記録してください。また、各批評で見つかった点と学びも記録してください。こうしておけば、ほかの人やエージェントが同じ間違いを繰り返さずに作業を引き継げます。
  • ユーザーの承認なしにコミットやプッシュをしないでください。キャッシュ(.media/)をアップロードしないでください。

このスキルが行わないこと

編集上の判断に代わるものではありません。何を伝えるかを決め、台本と P1 を承認するのは担当者です。また、元記事の内容は検証しません。動画が記事と同じ内容を伝えているかを検証します。

コメント