動画ダウンロードをターミナルで行うOSS「yoinks」の仕組みと特徴

動画を手元に残したいだけなのに、Web の動画ダウンロードサイトを開くと広告・偽のダウンロードボタン・見慣れないリダイレクトに囲まれます。安全そうな経路を探すだけで時間が溶けていく、という感覚を持つ方は少なくないはずです。

では、ターミナルに戻って yt-dlp を使えばよいのかというと、こちらにも別の面倒さがあります。まず -F でフォーマット一覧を出力し、その出力を読み解いて -f に渡す ID を決める、という手順から始まります。月に数回しか使わない作業のために、毎回オプションを調べ直すのは気が進みません。

この「安全な経路がほしい」と「オプションを覚えたくない」の両方に答えようとしているのが、本記事で取り上げる yoinks です。URL を貼ると解像度の一覧がターミナル内に表示され、選ぶだけで保存が終わります。ダウンロード処理そのものは自前で実装せず、yt-dlp に委譲する構成です。

はじめにお伝えしておくと、本記事は公開されている README・package.json・GitHub のリポジトリメタデータ・npm registry の記載に基づく整理であり、動作検証は行っていません。インストールや実行、スクリーンショットの取得も行っていないため、使用感の評価は含みません。

本記事では、yoinks が何をするツールなのか、yt-dlp と Ink をどう組み合わせて成り立っているのか、類似リポジトリとどこが違うのか、そして採用を判断する前に確認しておきたい開発状況とライセンス上の制約を順に整理します。

yoinksとは｜ターミナルで動画ダウンロードを完結させるOSS

yoinks は、ターミナル内の対話 UI で動画のダウンロードを完結させる Node.js 製の CLI ツールです。リポジトリは pablostanley/yoinks（GitHub） で公開されており、GitHub の説明文は「yoink any video from your terminal. no shady ads.」とされています。「怪しい広告のない経路」を掲げている点が、このツールの出発点を表しています。

README のキャッチコピーは「paste. yoink. done.」で、URL を貼る → 解像度を選ぶ → 保存する、という 3 手に操作を圧縮する設計です。対応サイトは YouTube・X（Twitter）・Instagram・Threads・TikTok ほか 1,800 以上とされていますが、これは yoinks 独自のサイト対応ではなく、内部で利用するダウンロードエンジン yt-dlp の対応サイト群に由来します。

リポジトリ基本情報

数値はいずれも GitHub API から取得したリポジトリメタデータの値です。Issue と PR の件数は、API の open_issues_count が両者の合算値を返す仕様のため、Issue 検索（is:issue is:open）と PR 検索（is:pr is:open）で分けて取得しています。また、ここで「最終更新」として採用しているのは pushed_at（コードが push された日時）で、スターや Issue のメタ更新でも動く updated_at は使っていません。これらの違いが採用判断で意味を持つ理由は、開発状況の章で改めて整理します。

yoinksの使い方｜npxで試す手順とターミナルUIの操作

README によれば、必要な前提は Node 18 以上のみです。ダウンロードに使う yt-dlp と、ストリーム結合に使う ffmpeg は、自動で取得されるかパッケージに同梱されるかのいずれかで用意されるとされています。

インストールは npm のグローバルインストールで行います。

npm install -g yoinks

インストールせずに試す場合は npx 経由で起動できます。

npx yoinks

いずれも出典は README（インストールと使い方） で、上記は原文からの抜粋です。評価のためにグローバル環境へ何かを常設する必要がない点は、採用を検討する段階でのコストを下げる要素になります。

起動の3パターン

README には起動方法として次の 3 パターンが示されています。

$ yoinks https://youtu.be/dQw4w9WgXcQ    # straight to the format picker
$ yoinks                                 # prompts for a url
$ yoinks --theme light                   # force the light palette

出典: README（インストールと使い方）（原文からの抜粋）

URL を引数で渡すとフォーマット選択画面に直行し、引数なしで起動すると URL の入力を求められます。--theme では配色を起動時に指定できます。

操作体系と保存先

README の記載によると、起動するとターミナルを全画面で占有し、中央寄せの UI が描画され、終了時にはスクロールバックが復元されるとされています。フォーマットの選択は上下キー・j/k・数字キーに対応し、esc で前の画面に戻り、^c で終了します。さらに yoink ボタンやフォーマット一覧はマウスクリックにも対応するとされています。保存先は ~/Downloads に固定で、終了時に保存パスがターミナルへ出力されます。

テーマの既定値は auto で、ターミナル自身の前景色・背景色を利用します。^t で auto → light → dark と巡回できます。TUI は利用者のターミナル設定が多様なため、独自配色を固定すると背景と文字色がぶつかって読めなくなることがあります。既定を auto に置く設計は、その衝突を避ける現実的な選択といえます。

yoinksの仕組み｜yt-dlpへの委譲とInkによるUI実装

ダウンロードエンジンはyt-dlp

README の「How it works」によると、ダウンロード処理は yt-dlp/yt-dlp に委譲されています。つまり yoinks の正体は、yt-dlp の TUI ラッパーとして組み立てられたフロントエンドです。本体が担うのは「どのフォーマットを取るかを選ばせる UI」であり、サイトを解析してストリームを取得する部分そのものは yt-dlp が担っています。

ここで注目したいのが、package.json の dependencies に yt-dlp が含まれていない点です。記載されているのは ffmpeg-static / ink / ink-select-input / ink-spinner / react だけで、npm の依存ツリーを辿ってもダウンロード機能の実体には到達できません。実行時に外部バイナリとして取得する設計のためです。依存関係からツールの実態を把握しようとすると、この構造を知らないまま読み違える可能性があります。

Python不要を成立させるバイナリ取得の設計

yt-dlp は Python で実装されたツールですが、yoinks の利用に Python 環境は不要とされています。README によれば、初回実行時にスタンドアロンの yt-dlp バイナリを ~/.yoinks/bin へ取得する仕組みで、すでに yt-dlp がインストールされている環境ではそれを使うとされています。

この設計には両面があります。利点は、Node だけ用意すれば動く状態を作れることと、エンジン側のバイナリを本体の更新とは独立に扱える余地が生まれることです。一方で README の Roadmap には「同梱 yt-dlp の自己更新（yt-dlp -U）」が未実装項目として残っており、エンジンの更新が自動で行われる状態にはまだ到達していないと読み取れます。

ffmpegの二段構え

高解像度ストリームの結合と mp3 抽出には ffmpeg が必要になります。README の記載では、まず PATH 上の ffmpeg を探索し、見つからない場合は同梱の ffmpeg-static にフォールバックするとされています。dependencies に ffmpeg-static が含まれているのは、このフォールバック経路を担保するためと整合します。YouTube の高解像度配信では映像と音声が別ストリームで提供されるため結合処理は避けられず、その準備を利用者に求めない点が「URL を貼るだけ」という体験の前提になっています。

Ink + React 19によるターミナルUI

UI は vadimdemedes/ink で実装されています。Ink は「React for interactive command-line apps」を掲げるライブラリで、React のコンポーネントと状態管理の作法をそのままターミナル UI の記述に使えます。

package.json を見ると、ink ^7.1.0 と react ^19.2.7 に加えて、選択リストの ink-select-input と読み込み表示の ink-spinner が並んでいます。先に挙げた全画面占有・中央寄せ・フェーズ間の画面遷移・テーマ巡回といった挙動は、この基盤上でコンポーネントと状態として構成された結果として説明できます。

公開されているコミット履歴を見ると、公開直後の修正は「フェーズ間のレイアウトシフトをなくす」「auto テーマでのボタンの明度を合わせる」といった UI 調整が中心でした。Web フロントエンドで扱う関心事とほぼ同じものがターミナル上でも課題になっており、React の知識を CLI ツール開発に転用する実例として読む価値のあるコードベースだといえます。

yt-dlp直叩き・GUI・Webサービスとの違い｜類似リポジトリ比較

動画ダウンロードの選択肢は yoinks 以外にも複数あります。提供形態が違えば向く用途も変わるため、主要な類似リポジトリと軸ごとに比較します。各数値は GitHub API から取得した値です。

yt-dlp/yt-dlp は yoinks の内部エンジンそのものです。したがって「yoinks でできることは yt-dlp でもできる」という関係が基本にあり、違いは操作体系に現れます。yoinks は対話 UI を足す代わりに、引数で細かく指示する自由度を手放しています。言い換えると、yoinks が効くのは「毎回違う動画を、毎回違う解像度で、手で選んで取る」場面であり、同じ処理を繰り返す場面では yt-dlp を直接呼ぶ方が素直です。

imputnet/cobalt は Web アプリと API として提供され、ローカルに実行環境を置かずに使える点が大きく異なります。API 経由の自動化も可能です。ただしライセンスが AGPL-3.0 であるため、ネットワーク越しにサービスとして提供する場合のソース開示義務を確認する必要があります。

aandrew-me/ytDownloader は yoinks と同じく yt-dlp をエンジンに使いながら、Electron のデスクトップアプリとして配布されています。ターミナルを使わない相手にも渡せる一方、依存は重くなります。対照的なのが dsymbol/yt-dlp-gui で、こちらはアーカイブ済み（archived）のリポジトリです。スター 1,457、最終 push は 2026-03-02 で開発は終了しています。yt-dlp のラッパーは個人開発で始まりやすく、同時に止まりやすいカテゴリであることを示す実例です。

yoinksを採用する前に確認すべき開発状況とライセンス

ここまでは設計の話でしたが、採用判断に最も効くのは開発状況です。結論を先に述べると、yoinks は人気指標とメンテナンス継続性が大きく乖離しているリポジトリです。

人気指標とメンテナンス継続性の乖離

スター 5,990・フォーク 507 という数字だけを見れば十分に支持を集めたプロジェクトに見えますが、開発側の指標は別の姿を示します。

• リポジトリの作成は 2026-07-16、最終 push は 2026-07-17 で、集中的な開発期間は約 1 日です
• 本記事の調査時点（2026 年 10 月）で、最終 push から約 3 か月が経過しています
• その間に オープン Issue が 17 件、レビューもマージもされていない オープン PR が 16 件、それぞれ滞留しています（GitHub API の open_issues_count が返す 33 件は、この両者の合算値です）
• GitHub の Releases は 0 件で、存在するのはタグ（v0.1.1 / v0.2.0 / v0.3.0 / v0.3.1）のみです
• npm パッケージ yoinks も 0.3.1（2026-07-17 公開）以降、新バージョンの公開がありません

特に注目したいのは PR が 16 件未処理で残っている点です。Issue の滞留は「要望や不具合報告が処理されていない」ことしか示しませんが、未マージの PR は「修正コードが提出済みでありながらメンテナ側で止まっている」ことを意味します。外部の貢献意欲があっても取り込まれない状態であり、メンテナンスの停滞を裏づける材料として Issue 件数より強く効きます。

スター数は「公開時にどれだけ注目されたか」を表す指標であり、「今も保守されているか」を保証するものではありません。初見のリポジトリを評価するときは、人気指標と更新指標を別々に確認する必要があります。

pushed_atとupdated_atの違い

このリポジトリは、確認するフィールドを間違えると判断を誤る例でもあります。GitHub API が返す updated_at は 2026-10-17、pushed_at は 2026-07-17 です。前者はスターや Issue などのメタ情報の更新でも動くため、コードが更新されたかどうかの指標にはなりません。採用判断の材料にするのは pushed_at、またはコミット履歴の最新日付です。

yt-dlp系ツール特有のリスク

動画ダウンロードツールは、対応サイト側の仕様変更で動かなくなりやすいカテゴリです。そのためエンジンとなる yt-dlp は高頻度で更新されており、ラッパー側がその更新に追従できるかが実用性を左右します。

yoinks はこの点で両面の性質を持ちます。yt-dlp をバイナリとして実行時に取得する設計のため、エンジン側の更新を本体の更新を待たずに取り込める可能性があります。一方で Roadmap の「同梱 yt-dlp の自己更新（yt-dlp -U）」は未実装のままで、取得済みバイナリを入れ替える手段が本体機能として用意されているわけではありません。ローカルの yt-dlp を使う構成であれば、そちらを更新することで対処できる可能性はありますが、これは README の記載から読み取れる範囲の推測です。

適用範囲の見極め

README の Roadmap に残る未実装項目は、そのまま現時点の適用範囲の輪郭になります。未チェックのまま残っているのは、--best / --mp3 によるピッカー省略、-o <dir> での出力先指定、プレイリストや複数動画を含むスレッドへの対応、クリップボード検出、同梱 yt-dlp の自己更新、curl 経由のインストーラです。

ここから読み取れる線引きは明確です。yoinks は対話的な単発作業に向き、自動化や一括処理には向きません。CI に組み込む、cron で定期取得する、プレイリストをまとめて落とす、保存先をプロジェクトごとに切り替える、といった用途は現時点では想定の外にあります。「使えるか・使えないか」ではなく「どの用途なら今でも使えるか」で評価する対象です。

ライセンスと利用上の制約

ライセンスは MIT で、組み込みや改変の自由度は高い部類です。TUI の実装を参考にする、自分用に改変して使う、といった用途で制約になる要素は少なく、比較表で挙げた cobalt の AGPL-3.0 や ytDownloader の GPL-3.0 と比べれば、この寛容さは yoinks を選ぶ理由のひとつになり得ます。

ただしライセンスとは別に、README には利用面での注記があります。README は、yoinks が個人的なアーカイブ用途のツールであり、コンテンツのダウンロードはプラットフォームの利用規約に違反する可能性があるため、保持する権利があるものだけをダウンロードすべきである旨を明記しています。業務の文脈で使う場合は、ツールのライセンスと対象コンテンツの権利・各サービスの利用規約を切り分けて確認してください。

まとめ｜yoinksが向く場面と向かない場面

yoinks は、yt-dlp のオプション指定という手間を対話 UI で置き換え、Python 環境の準備という前提も実行時のバイナリ取得で回避したツールです。設計は素直で、Ink と React によるターミナル UI の実装例としても読み応えがあります。一方で、公開直後に集中的に開発された後は約 3 か月コミットが止まり、オープン Issue 17 件と未マージの PR 16 件が滞留している状態です。

向く場面

• 手元で単発の動画を保存したい（npx yoinks で導入なしに試行できる）
• yt-dlp のフォーマット指定を毎回調べ直したくない
• Python 環境を増やしたくない
• Ink による TUI 実装の参考コードを読みたい

向かない場面

• 定期実行・一括取得・保存先の指定が必要（いずれも Roadmap 未実装）
• 長期運用を前提に、継続的なメンテナンスを期待したい
• チームの非エンジニアに配布したい（GUI アプリの方が適切）

そして本記事で最も持ち帰っていただきたいのは、個別の判断より手前にある確認手順です。スター数は注目度の記録であって保守の保証ではありません。初見のリポジトリを評価するときは、pushed_at（またはコミット履歴の最新日付）、オープン Issue と未マージ PR の滞留状況、リリース・パッケージ公開の履歴、Roadmap の未実装項目を並べて確認してください。この 4 点を見れば、yoinks のように「人気はあるが止まっている」リポジトリを、過大にも過小にも評価せずに扱えるようになります。

関連情報

OSS の採用判断や、社内ツール・業務システムの設計についてご相談先をお探しの場合は、お問い合わせフォームよりご連絡いただけます。技術選定の整理段階からのご相談も承っています。