ニュース動画をAIに毎日作らせる｜全自動パイプラインの設計と、直し続けた事故

朝、できあがったばかりのニュース動画を再生しました。ナレーションは落ち着いた声で「新しいAIモデルが発表されました」と読み上げているのに、画面下の字幕には、どこにも存在しない一文が猛スピードで流れていきます。台本にはない、AIが勝手に書いた実在しない単語の羅列——数えてみると、128個。音声は正しいのに、字幕だけが完全な別世界を語っている。これは他社のトラブル事例ではなく、AIにニュース動画を毎日作らせている私たち自身が、2026年に実際に起こした事故です。

AI Lab OISHIでは、AI・テック・ロボットの最新ニュースをまとめた10分ほどの動画を、ネタ集めから台本づくり、事実確認、AI音声、字幕、動画の描画、YouTubeへのアップロードまで、人の手をほとんど介さずに生成しています。チャンネルを開いたのは2026年3月30日。以来これまでに26本の動画を描画し、試作を含めれば台本のデータは102本を生み出してきました。この記事は、その全自動パイプラインの内側で実際に何が壊れ、それをどうやって二度と壊れない形に作り替えていったかを、成功談ではなく事故の記録として包み隠さず公開する運用録です。AIで動画やコンテンツを回したい実務者・経営者の方に、いちばん役に立つはずの「つまずきと、その後始末」をお届けします。

なぜ、AIに動画を丸投げすると事故が起きるのか

まず、この仕組みが何をしているのかを整理します。中心にあるのは1本のプログラムで、24のニュースサイトの更新情報を集めるところから始まり、直近の動画と話題がかぶっていないかをふるいにかけ、最新の出来事だけを選び、AIに台本を書かせ、その台本を元記事と照合し、AI音声で読み上げ、字幕を合わせ、動画として描画し、サムネイルを付けて、YouTubeへ投稿するまでを一気通貫でこなします。毎回6つのニュースを選び、一般の視聴者向けと業界の実務者向けを組み合わせて、10分前後の1本にまとめます。ほぼすべての処理を手元のMacで動かしているため、毎日作り続けても外部サービスに支払う費用は月におよそ3ドルに収まっています。

ここで多くの人が期待するのが、「賢いAIに任せれば、品質も正確さも勝手についてくる」という筋書きです。実際は、その真逆でした。AIは驚くほど自然な台本を書き、驚くほど滑らかにニュースを読み上げます。ところが同じくらい平気で、聞き取れなかった空白を作り話で埋めたり、原文の金額を別の数字にすり替えたり、固有名詞を勝手に読み替えたりします。賢さと正確さは別物で、賢いAIほど、止める仕組みがないと事故のスケールも大きくなる。私たちがこの数ヶ月で本当に投資したのは、良い台本を書かせる工夫ではなく、悪い出力を機械が出口で自動的に止める検査の設計でした。

全体像は、下の図のように「7つの工程が直列に流れ、人間が触れるのはたった2か所」という形になっています。工場のベルトコンベアを思い浮かべてください。素材が左から右へ流れ、各工程で組み立てられていく。無人で流れる区間を長く取るほど運用は楽になりますが、その分どこか1か所が壊れると、そのまま最後まで事故が流れ着いてしまう。だからこそ、工程のつなぎ目ごとに機械の検問所を置いています。似た発想で複数の自動化を束ねた話は、AI自動化システムをまとめた記事でも整理しています。

ここから先は、そのつなぎ目でどんな事故が起き、どう塞いだかを、痛い順に5つ紹介します。先に全体を一覧にすると、下の表のとおりです。どれも「起きた1例を直す」のでなく「同じ種類の事故が入り込めない仕組みを足す」で締めているのが、共通の作法です。

人間がどこを握り、どこを機械に任せるかという線引きの発想は、初心者向けに噛み砕いたAI半自動化を7ステップで始めるガイドもあわせて読むと、最初の一歩がつかみやすいはずです。

事故で学ぶ①：字幕が丸ごと崩れ、AIが128個の嘘を書いた

冒頭の128個の嘘に戻ります。当初、私たちは字幕の表示タイミングを、AIの音声認識に頼って割り出していました。できあがった音声をAIに聞かせ、「何秒の時点で何を話しているか」を書き起こしてもらう方式です。ところが、台本のなかに鉤括弧でくくった短い言葉を畳みかける箇所を入れたところ、その部分で音声認識が暴走しました。聞き取れなかった空白を、それらしい別の単語で埋め始めたのです。結果、台本には一言も無い128個の単語が字幕に湧き出し、以降の表示が総崩れになりました。

不気味だったのは、症状が片側にしか出なかったことです。はっきりした発声で始まる動画では暴走せず、特定の言い回しのときだけ崩れる。まるで居眠り交じりの書記のように、聞き取れなかった箇所を「たぶんこう言ったはず」と自信満々に埋めてしまうのです。しかも、この音声認識は同じ音声を渡しても毎回わずかに違う結果を返すため、字幕がじわじわとずれる問題も慢性的に起きていました。

直し方：推定をやめ、正解の台本を音声に突き合わせる

私たちが選んだのは、暴走した部分だけを打ち消す小手先の修正ではありませんでした。それをやっても、次の未知の言い回しでまた別の暴走が出ます。代わりに、字幕の作り方そのものを根本から変えました。すでに手元にある台本を「正解」として、その一文一文が音声のどこで話されているかを機械的に突き合わせる、フォーストアライメントという方式へ移行したのです。答えを先に渡してから、どこで何を言ったかの時刻だけを照合する。いわば、写経の答え合わせのように、書き起こす必要がそもそも無い。この考え方は、Montreal Forced Aligner の公式ドキュメントで説明されている、既知のテキストと音声を時間的に対応づける手法にあたります。

音声認識ではなくなったので、聞き間違いも、作り話も、毎回ぶれる非決定性も、原理的に入り込む余地がなくなりました。あわせて、「字幕の位置は文字数から推定して均等に割り振ってよい」というやり方を明確に禁止し、必ず実測した時刻だけを使うルールをコードに固定しました。ここに、この記事を貫く1つ目の教訓がはっきり出ています。入ってくるものを見張って直そうとするのでなく、そもそも間違いが入らない作り方に変える。音声認識のクセを検出して補正し続けるより、推定を捨てて実測に置き換えるほうが、はるかに確実だったのです。

事故で学ぶ②：AIが固有名詞を読み違え、声がぶれた

2つ目は、AI音声にまつわる話です。この動画のナレーションは合成音声で、これまでに読み上げエンジンを4回も乗り換えてきました。最初のエンジンから、より自然な別のエンジンへ、さらに海外製の声へ、そして現在のGemini系の落ち着いた声へ。乗り換えるたびに、新しいクセと事故が待っていました。

いちばん厄介だったのが、漢字の読み違いです。あるエンジンは「刑事」を「デカ」と読むなど、同じ言葉を確率的に別の読みで発音してしまいました。ニュースの本文でこれが起きると、意味が通らなくなります。さらに深刻だったのは、決まった読みしか持たない辞書型の音声エンジンでは、ClaudeやGrok、Perplexityといった新しい固有名詞をそもそも読めなかったことです。毎日、生まれたばかりの製品名が飛び交うAIニュースを読ませるのに、たとえるなら、古い辞書しか持たないアナウンサーを雇うようなもので、これは構造的に相性が悪いと結論づけました。加えて、あるエンジンは1文が60字を超えると処理そのものを拒否し、別のエンジンでは以前の設定が残って不自然な間が空き、動画が30秒も長くなる、といった副作用も次々に出ました。

直し方：エンジンごとに設定を封じ込め、コード側で長さを削る

ここでの学びは2つあります。1つは、新しい固有名詞を読める生成AI系の音声へ寄せること。もう1つが、より本質的で、「1文を短く」といった指示をAIへのお願いに委ねず、コード側で機械的に強制することです。プロンプトで「1文は60字以内で」と頼むだけでは、AIは平気で守りません。だから、生成された台本を検査し、長すぎる文を自動で分割する処理をコードに組み込みました。お願いは破られる前提で、破れない仕組みを別に置く。ここでも1つ目と同じ、出力を検証して締める発想が効いています。

あわせて、エンジンごとの間の取り方や読み上げ設定を1か所にまとめて管理し、乗り換えたら必ず1区切りだけ試聴してから本番に流す手順も固定しました。過去には、以前のエンジン用の設定が残ったまま新しいエンジンで走り、不自然な沈黙が生まれたことがあったからです。設定を引き継がず封じ込めるのは、いわば料理のたびにコンロを一度ゼロに戻してから火を入れるようなもの。前の火加減を残さないことが、事故を防ぎます。

事故で学ぶ③：AIが金額を勝手に盛り、5兆円と報じた

3つ目は、この運用でもっともヒヤリとした事故です。あるニュースで、原文に「500億ドル」と書かれた金額を、AIは日本円に直して「5兆円」と台本に書きました。一見、親切な換算に見えます。ところが当時の為替で計算すれば、500億ドルはおよそ8兆円。AIは実額より4割近くも少ない数字を、さも事実のように語り、その動画は公開されてしまいました。

問題を根深くしていたのは、公開前の事実確認をすり抜けていた点です。当時の事実確認は、この「5兆円」を原文の「言い換え」として黙認していました。数字が違うのに、通貨をまたいだ変換だからと見逃してしまった。ここで小手先の対処をするなら、「通貨の換算だけを特別にチェックする」でしょう。しかし、それは典型的なモグラ叩きです。次は割合で、その次は件数で、同じ種類の捏造が形を変えて出てきます。

直し方：あらゆる数量を、出典と1つずつ照合する

そこで新設したのが、数値の出所検証という専用の検査工程です。台本に登場する金額・件数・割合・パーセントといった、ありとあらゆる数量を機械的に抜き出し、元記事の出典と1つずつ突き合わせます。まるで1円単位で帳簿と照合する経理担当のように、台本の数字を1つ残らず検分するわけです。原文にその数字が文字どおり存在せず、換算によっても導き出せない数量が1つでも見つかれば、そこでパイプライン全体を強制的に停止します。通貨だけを見張るのではなく、数量という数量をすべて対象にしたのが肝で、これが「1例だけ潰さない」というモグラ叩き禁止の実装です。

この検査は飾りではありません。導入後、実際に3日連続でAIの作り話をつかまえ、公開の手前で止めました。生成AIは、それらしい数字を自信満々に差し込む常習犯です。だからこそ、賢いAIの善意に頼るのをやめ、出典に無い数字は1つも通さないという境界を、機械の側に引きました。書いたAIとは別のAIに検証を任せる考え方は、サブエージェント実践ガイドでも扱っています。作る担当と確かめる担当を分けるのが、品質保証の背骨です。

事故で学ぶ④：承認待ちで、夜間に5時間半も止まった

4つ目は、AIの賢さではなく、人間との境界線の引き方でつまずいた話です。動画を無人で作らせるといっても、「公開してよいか」の最終判断は人間が握ります。ところがある夜、その承認の設計が裏目に出ました。動画の描画そのものは夜の21時58分に終わっていたのに、実際に公開されたのは、翌日未明の3時26分。差し引き5時間半近く、パイプラインは何もせず、ただ人間の承認を待って止まっていたのです。

原因は、承認の仕組みが「危ない操作をするたびに人間へ確認を求める」形になっていたことでした。「もう逐一の承認はいらない」と伝えたつもりでも、夜間に確認のプロンプトが立ち上がり、誰も見ていない画面の前で処理が凍りつく。これは、無人で走らせたいという狙いと、実装が真っ向から矛盾している状態でした。口約束で「夜は止めないで」と頼んでも、コードがそう書かれていない限り、機械は律儀に止まり続けます。

直し方：承認を1回に絞り、GOをコードで縛る

ここで立てた原則が、「自分の行動で守れない約束は、口でせずコードで縛る」です。私たちは承認の仕組みを、「操作ごとの許可」から「GOという合言葉をコードの内側で検証する」形へ作り替えました。人間が出す承認は、最初のGO1回だけ。いったんGOが通れば、あとは公開まで機械が一気に走り抜けます。改札を一度通れば、目的地まで乗り換え自由の切符のようなものです。さらに、AIが選んだ候補の一覧を必ず人間に提示し、その一覧の指紋をGOに結びつけることで、「候補を見せないと1歩も進めない」状態を仕組みとして強制しました。承認を軽くするのではなく、承認の意味を1点に凝縮したわけです。こうした「入口と出口に門を置く」設計の作り方そのものは、フックの実装ガイド記事で詳しく扱っています。

事故で学ぶ⑤：サムネの文字が、キャラクターの脚に重なった

5つ目は、目に見える形で表に出た事故です。動画のサムネイルを自動生成したところ、下部に置いた小さな文字帯が、キャラクターの脚と重なって読めなくなっていました。パッと見の完成度は高く、「ほぼ完璧だから、今回はこのまま許容してもいいのでは」という誘惑もありました。しかし、それを認めれば、次のニュースでは別の文字数、別の構図で、また同じ被りが起きます。1回きりの「今回だけ短くする」は、結局その場しのぎにしかなりません。

そこで私たちは、「今回だけ許容」という判断を却下しました。かわりに、サムネイルの設計図そのものに構造的なガードを入れました。文字が置ける実効的な幅をあらかじめ予算として決め、その幅を超えそうなら文字を自動で2行に逃がし、それでも収まらなければ文字サイズを段階的に縮める。毎回その場で裾上げするのでなく、最初から収まる型を決めておく発想です。いわば既製服のサイズ表を先に用意しておくようなもので、着るたびに仕立て直す必要がありません。ここでも一貫しているのは、起きた1例を消すのでなく、同じ種類の事故が二度と起きない構造をつくる、というモグラ叩き禁止の姿勢です。

出力検証の多層防御｜一つの門で守らない

ここまでの5つの事故は、バラバラに見えて、後始末の作法が完全に共通しています。どれも「起きた1例を直す」のでなく「同じ種類の事故が入り込めない層を足す」で締めています。私たちの品質担保は、たった1枚の門で守るのではなく、性格の違う検問所を何重にも重ねた多層防御です。台本のすべての参照元が概要欄に載っているかを確かめる層、事実確認が全ての区切りを網羅しているかを見る層、数量を出典と照合する層、いきなり本編を全部描画せず、テストの静止画を数枚だけ先に描いて目視で確かめる層。推測で全部を描き切ってから間違いに気づくのがいちばん高くつくので、軽いプレビューで先に検分する関所を置いているわけです。

そして最後に、機械では埋められない穴が1つだけ残ります。数字は数値の検査で止められますが、意味の取り違えは止められません。実際、AIが実在しない製品名を、実在する別の名前のように書いてしまった事故がありました。数字ではないので、数値のゲートはすり抜けます。ここだけは、公開前に人間が最終フレームを1枚ずつ自分の目で開き、文字の被り、はみ出し、固有名詞、日付を確かめるほかありません。ちょうど工場の最終ラインに立つ検品員のように、意味の誤りに対しては人間の目視が唯一の防波堤なのです。合格したら、その動画ファイルの指紋を承認の記録に転記し、以降ファイルが少しでも変わったら公開を拒否する——改ざん検知まで含めて、人間の一度の目視を仕組みで固定しています。この「作る担当と確かめる担当を分ける」考え方は、Claude Codeの構成要素を整理した記事の役割分担の発想とも重なります。

毎日AIに作らせて、権利とルールをどう守るか

AIに毎日ニュース動画を作らせると聞くと、「権利面は大丈夫なのか」と身構える方も多いはずです。ここは設計の段階から、きれいになるよう組んでいます。まずニュースの扱いです。著作権法のもとでは、出来事という事実そのものは保護されない一方で、記事の表現は保護されます。そこで台本は、AIが元記事を素材に自分の言葉で要約・解説し、見出しやリード文をそのまま読み上げたり字幕に転用したりはしません。概要欄には参照元のURLを明記し、事実確認の工程が元記事との照合を担います。事実は借りても、表現は借りない。この線引きが、ニュースを扱ううえでの生命線です。

動画を構成する素材も、権利がクリーンになるよう選んでいます。背景やロボットのキャラクター、サムネイルの素材はすべてAI生成か自作で、第三者の著作物は混ぜていません。画面に使う日本語フォントは、商用利用が明示的に許可されたオープンライセンスのものを採用しています。ナレーションの合成音声も、規約の範囲内で使える生成AIの声で、声優の音源を無断で使うようなことはしていません。BGMについては、フリーで配布されている楽曲を規約の範囲で使う方針にとどめ、権利関係を断定的に語ることは避けています。ここは慎重すぎるくらいでちょうどよい、と考えています。

最後に、AI開示です。この動画は、アップロードのたびに「AIによる合成コンテンツを含む」という開示ラベルを自動で付けています。YouTube Data APIの該当項目を通じて機械的に設定し、過去にさかのぼって公開済みの動画にも一括で反映しました。YouTubeの公式ヘルプでも、現実的に見える合成・改変コンテンツには開示が求められています。私たちは、これを健全な訴求点だと捉えています。ただし、正直に開示したからといって収益化が保証されるわけではない、という点は事実として押さえておく必要があります。開示は義務を果たすためのものであって、見返りを約束するものではないからです。

まとめ｜「作らせる」より「止める場所を決める」

AIで動画を回すというと、多くの人は「AIに何を作らせるか」を考えます。でも、毎日1本を作り続けて分かったのは、本当に効くのは逆の問いだということです。「AIが吐き出した悪いものを、どこで機械が止めるか」。この問いに答え続けた結果が、推定をやめて実測で固定した字幕であり、出典に無い数字を通さない数値ゲートであり、承認をGO1回に凝縮したワンGOであり、モグラ叩きをやめた多層防御でした。

賢いAIは、あなたの会社でも素晴らしい台本と音声を作ってくれます。同時に、止める仕組みがなければ、素晴らしい速度で作り話も量産します。だからこそ、良い出力を期待する前に、悪い出力を機械が出口で自動的に止める門を先に置く。入力を見張るのでなく出力を検証する、1例だけ潰さず多層で塞ぐ——この2つの原則さえ握っておけば、事故の大半は公開の手前で消えます。AIで動画を回す難しさは、実は技術ではなく、どこを人間が握り、どこを機械に止めさせるかという線引きの設計にあります。AI導入がつまずく典型は、AI導入でつまずく5つのパターンの記事でも整理していますが、突き詰めればどれも「仕組みでなく気合いで守ろうとした」ことに行き着きます。

よくある質問

AIに動画を全部作らせて、字幕やナレーションのズレはどう防ぐのですか？

ズレを後から直すのではなく、そもそもズレない作り方に変えて防ぎます。当初はAIの音声認識で字幕の表示時刻を推定していましたが、認識が毎回ぶれて字幕がずれ、ときには聞き取れなかった空白を無関係な単語で埋める誤作動まで起きました。そこで、すでに手元にある台本を正として、その一文一文が音声のどこで話されているかを機械的に突き合わせる方式に切り替えました。台本という正解を先に渡すので、聞き間違いも創作も原理的に入りません。字幕の位置は文字数からの推定で計算することを禁止し、必ず実測した時刻だけを使うルールをコードで固定しています。

AIが数字や事実を間違えたまま公開されない仕組みはありますか？

あります。一度、AIが原文の「500億ドル」を「5兆円」と書き換え、実額よりおよそ4割少ない金額のまま公開してしまう事故を起こしました。そこで、台本に出てくる金額・件数・割合といったすべての数量を抜き出し、元記事の出典と1つずつ照合する専用の検査工程を追加しました。原文にその数字が見当たらず、換算でも導き出せない数量が1つでもあれば、そこで処理を強制的に止めます。通貨だけを見張るのではなく、あらゆる数量を対象にしているのがポイントで、この検査は実際に何度もAIの作り話をつかまえています。

AIが作った動画をYouTubeに出すとき、著作権やAI開示は大丈夫ですか？

設計の段階から、権利面がきれいになるように組んでいます。ニュースは、事実そのものは著作権で保護されない一方で、記事の表現は保護されます。そこで台本はAIが自分の言葉で要約・解説し、見出しやリード文をそのまま読み上げたり字幕に転用したりはせず、概要欄に参照元のURLを明記しています。動画に使う背景やキャラクター、サムネイルの素材はすべてAI生成か自作で、第三者の著作物は混ぜていません。さらに、アップロード時にAI生成であることの開示ラベルを毎回自動で付けています。ただし、開示すれば収益化が保証されるわけではない点は、事実として押さえておく必要があります。

専任の開発チームがなくても、動画の自動生成は始められますか？

始められます。私たち自身、コードを自分で書くのではなく、AIに指示して作らせ、壊れたらAIに直させるという進め方でこのパイプラインを組み上げてきました。大切なのは自分でプログラムを書く力ではなく、どこを人間が握り、どこを機械に止めさせるかという線引きを設計する力です。最初から全自動を狙わず、いちばん時間のかかる1工程をAIに任せるところから始め、動くようになってから、失敗しても被害が広がらない保護機構を1つずつ足していくのが、遠回りに見えて確実な順序です。

参照元・出典

• Montreal Forced Aligner Documentation — 既知のテキストと音声を時間的に対応づける、フォーストアライメントの手法と仕組みの公式解説。
• OpenAI Whisper（GitHub 公式リポジトリ） — 汎用の音声認識モデル。書き起こしを推定する方式そのものの一次情報。
• Remotion Documentation — React で動画をプログラムとして描画するツールの公式ドキュメント。動画の自動描画工程の基盤。
• Disclosing use of GenAI content（YouTube ヘルプ） — 現実的に見える合成・改変コンテンツにAI開示を求める、YouTube公式の方針。
• Videos（YouTube Data API 公式ドキュメント） — 合成メディアを含む旨を機械的に設定するための、アップロードAPIの一次情報。
• 著作権法（e-Gov 法令検索） — 著作物を「思想又は感情を創作的に表現したもの」と定める、事実と表現の線引きの一次法源。