MuAPI 依存かローカル完結か、AI-Youtube-Shorts-Generator の二重構造を読む

解こうとしている問題は「切り抜き作業の外注費」ではなく「選定基準の非公開」

このリポジトリが名指しで対置しているのは Opus Clip、Vidyo.ai、Klap、SubMagic、2short.ai といったクリッピング SaaS である。README の比較表で最初に挙げられる差分は価格帯（月 20 ドルから 300 ドル）と分単位の上限だが、技術者にとって本質的な差分はその次に書かれている。ハイライト選定アルゴリズムが「Fully editable virality framework」と表現され、ブラックボックスではないと主張されている点だ。どの区間が切り出されるかの判断基準を自分で書き換えられること、そして選定結果を JSON として受け取れることが、この道具の中心にある。対象読者は README いわく creators、agencies、developers の三種だが、実際に効くのは「切り抜きの選定ロジックを自社の基準に合わせたい」層である。単にショートが量産できればよいだけなら、SaaS のほうが設定項目は少ない。

パイプラインは 4 段で、各段の実行場所がモードによって入れ替わる

処理の流れは README の記述から次のように読み取れる。動画の取得、文字起こし、ハイライト選定、縦型への cropping という 4 段である。既定の API モードではこの 4 段すべてを MuAPI が担い、必要な依存は MUAPI_API_KEY ひとつになる。一方 --mode local では、取得を yt-dlp、文字起こしを faster-whisper、cropping を ffmpeg と opencv が担当し、OpenCV による顔追跡と動きの平滑化で縦位置を決める。リモートに残るのはハイライト選定の LLM 呼び出しだけで、ここに OPENAI_API_KEY か GEMINI_API_KEY を使う。つまり local モードは完全オフラインではなく「LLM 以外を自前で回す」構成だと理解するのが正確だ。文字起こしの出力形状はクラウド版とローカル版で共通だと README は説明しており、下流の処理を書き分けずに済む設計になっている。

30 分超の動画を落とさないためのチャンク分割と重複排除

長尺動画への対処として README が挙げるのは 2 つの仕組みである。ひとつは 30 分を超える動画を overlap 付きで自動的に分割する処理。境界で文脈が切れ、本来拾うべき山場が落ちるのを避けるための重なりだ。もうひとつは Smart Dedupe と呼ばれる重複排除で、重なり合うハイライトをスコア順に collapse し、似たクリップが 2 本出るのを防ぐ。この 2 つはセットで意味を持つ。分割だけでは境界付近に候補が二重に立つし、重複排除だけでは長尺の後半が視野に入らない。ただし README には overlap の幅やスコアの算出式までは書かれていない。分割幅と重なりの量を変えたい場合、コードを読む以外に方法がない可能性がある。ここは導入前に確認しておきたい不透明さだ。

セットアップはモードで必要なファイルが分かれる

手順は README に明示されている。git clone のあと python3.10 -m venv venv で仮想環境を作り、pip install -r requirements.txt を実行する。local モードを使う場合のみ pip install -r requirements-local.txt を追加する。環境変数はプロジェクト直下の .env に置く。API モードなら MUAPI_API_KEY のみ。local モードでは LLM_PROVIDER に openai か gemini を指定し、対応する OPENAI_API_KEY または GEMINI_API_KEY を設定する。モデルは OPENAI_MODEL（既定 gpt-4o-mini）と GEMINI_MODEL（既定 gemini-2.5-flash）で差し替えられる。文字起こしは LOCAL_WHISPER_MODEL が tiny、base、small、medium、large-v3 から選べ、LOCAL_WHISPER_DEVICE は auto、cpu、cuda を取る。出力先は LOCAL_OUTPUT_DIR で、既定は output ディレクトリ。実行は python main.py "URL" で、local モードなら末尾に --mode local を付ける。生成物は ./output/short_01.mp4 のように連番で並ぶ。バッチ処理は URL リストを xargs に渡す形が README で示されている。

local モードが向かない場面は、GPU と ffmpeg の運用を引き受けたくない場合

local モードの前提条件として README が挙げるのは Python 3.10 以上、PATH の通った ffmpeg、そして LLM の API キーである。faster-whisper を CPU で回すことも cuda で回すこともできると書かれているが、動画の長さと LOCAL_WHISPER_MODEL の選択によって所要時間が大きく変わることは想像に難くない。README には具体的な処理時間の記載がないため、large-v3 を選んだときに実用水準に収まるかは自分の環境で測るしかない。もう一点、local モードでもハイライト選定はリモートの LLM に投げる。文字起こしテキストは外部に送られる。映像そのものを外に出したくないという動機で local モードを選ぶ場合、テキストの送信は残ることを把握しておく必要がある。加えて API モードは MuAPI の可用性と料金体系に処理全体が従属する。README は「pay only for API usage」と書くが、単価には触れていない。

代替としての MuAPI 直接呼び出しは、同じパイプラインを 1 回の HTTP リクエストに畳む

README 自身がもうひとつの選択肢を提示している。AI Clipping API と Auto-Crop API で、前者はクリップ選定からレンダリングまでを end-to-end で、後者は縦型への reframing だけを担う。違いは明確である。このリポジトリは CLI と Python ライブラリとして手元に置くコードであり、ハイライトの選定基準を書き換えたり、generate_shorts(...) を自分のパイプラインに import したり、--output-json で候補ハイライトと最終クリップのパスをまとめて取り出したりできる。API を直接叩く構成では、その自由度と引き換えに Python も依存関係も持たずに済む。判断軸は「選定ロジックを触るかどうか」の一点に絞られる。触らないなら、このリポジトリを self-host する理由は薄い。

ライセンスと保守の見通しで、README の記述とリポジトリの表示が食い違う

README の比較表には MIT licensed と書かれ、Python ライブラリとして import できることも白ラベル利用も可能だと主張されている。しかしリポジトリのメタデータではライセンスが unknown として返っており、LICENSE ファイルの有無も提供された情報からは確認できない。MIT を前提に自社製品へ組み込む判断をするなら、README の一文ではなくリポジトリ内のライセンスファイルそのものを確認する必要がある。保守面では、リポジトリは archived ではなく、最終 push は 2026-09-08、リリースは取得できていない。バージョン番号による固定ができないため、依存を固定したい場合はコミットハッシュを指定することになる。requirements.txt と requirements-local.txt の 2 系統を抱える構成も、片方だけを更新したときに差分が生まれやすい。

編集部の結論

自前のサーバーやワークステーションで動画を処理し、外部に映像を預けたくないチームに向く。逆に、GPU も ffmpeg の運用も持ちたくない個人は、既定の API モードで MuAPI のキーを 1 つ用意するほうが現実的だ。導入前に確認すべきは 3 点で、リポジトリのライセンス表記が README 内の MIT 主張と一致しているか、requirements-local.txt が自分の環境で通るか、そして LOCAL_WHISPER_MODEL を base から上げたときに処理時間が許容範囲に収まるかである。ここが確認できないまま本番のパイプラインに組み込むのは勧めない。

公式情報源

1. Anil-matcha/AI-Youtube-Shorts-Generator on GitHub
2. Issues
3. Project website
4. README