私はCuekiyo v1.0.0をリリースしました。これはアニメオープニングとエンディングのコンパイル動画を作成するためのオープンソースのローカルウェブアプリです。

考え方はシンプルです：

アニメタイトルを選択 → OP/ED曲の承認 → YouTubeクリップ候補のレビュー → 完成したMP4のエクスポート

クラウドエディタなし。アップロードステップなし。有料API依存なし。すべてがあなたのマシン上で動作します。

GitHub: https://github.com/unloopedmido/cuekiyo

アニメオープニング/エンディングのコンパイル作成のための手動作業は正直に苦痛だったので、これを構築しました。結果として、多くのブラウザタブ、コピーされたタイムスタンプ、別々のダウンロードコマンド、トリミングツール、命名の混乱、ランダムなフォルダ、クリップが変更されるたびに繰り返し再レンダリングが発生します。

Cuekiyoはそれをガイド付きのローカルパイプラインに変換します。退屈な部分を自動化しますが、人間が決定すべき瞬間ではまだ停止します.

問題

コンパイル動画を作るのは最初は簡単に思えますが、実際にきれいにやってみると分かります.

典型的な手動のワークフローはこんな感じです.

1. 含めたいアニメを選びます.
2. オープニングとエンディングテーマの名前を探す.
3. 各曲についてYouTubeを検索する.
4. どのアップロードが利用可能かを確認する.
5. リンクやタイムスタンプをどこかにコピーする.
6. ソース動画をダウンロードする.
7. 各クリップを編集する.
8. 音声を標準化するか、少なくとも大きく一貫性のない音声を避ける.
9. タイトルオーバーレイやロアースリークを追加する.
10. すべてを繋げる.
11. 何かが間違っている場合に再レンダリングする.

一度やればそれほど難しくない。問題は繰り返しである.

一つのクリップを作成するなら、通常のビデオエディタで十分です。多くのアニメタイトル、テーマソング、複数のソース、一貫したオーバーレイ、予測可能な出力フォルダで構造化されたコンパイルを作成するなら、作業フローは一時的な編集というより小さなメディアパイプラインのようになります.

それが私が実際に解決しようとした問題でした.

「ビデオエディタを置き換える」ことではありません.

よりそれに近いです：

ローカルのスタジオを教えて、繰り返しのパイプライン作業を扱っていても、創造的な選択をコントロールできるものを。

Cuekiyoが行うこと

Cuekiyoは、ガイドされたプロジェクトの流れを中心に構築されています。

プロジェクトを作成し、アニメのタイトルを選び、オープニング、エンディング、または両方を選択し、その後、承認手順を進みます。

核心的な流れは：

1. プロジェクトを作成
   名前をつけ、アニメタイトルを選び、曲の種類を選び、オーバーレイ/レンダリングのデフォルトを設定

2. 曲を選択
   Cuekiyoはテーマデータをロードし、OP/EDトラックのどれを含めるべきか承認する

3. クリップ候補を確認
   アプリはYouTubeの候補を検索しますが、実際に使用するものはあなたが選びます。自動化が間違えた場合、自分のリンクを貼り付けることもできます。

4. 剪り取りと処理
   Cuekiyoはローカルでクリップをダウンロードし、調査し、正規化し、切り取り、オーバーレイします。

5. レンダリング順序を確認
   レンダリング前に最終順序を選択します。

6. MP4をエクスポート
   最終的なコンパイルはあなたのローカルプロジェクトフォルダに書き込まれます.

重要なデザインルールはこれです.

自動化は労働を処理すべきで、味わいを処理すべきではありません.

そのため、Cuekiyoはユーザーゲートで一時停止します。適切な曲、ソースクリップ、トリムポイント、最終順序を選ぶのは主観的なものです。パイプラインは役立つかもしれませんが、あなたよりもあなたの味わいを知るふりをしないでください.

なぜローカル優先なのですか？

私はCuekiyoをデスクトップのクリエイティブツールのように感じさせたいと思ったが、ウェブアプリの開発スピードとUIの柔軟性を持ち合わせていたいと思った.

だから、ホスティングされたSaaS製品を構築する代わりに、Cuekiyoはローカルで動作する:

• バックエンドはあなたのマシン上で動作する.
• フロントエンドはあなたのブラウザ内で動作する.
• プロジェクトの状態はSQLiteに保存されている.
• メディアファイルはdata/projects/{id}/の下に保存されている.
• レンダリングはローカルのFFmpegを通じて行われます.
• ランダムなクラウドサービスに何もアップロードする必要はありません.

これはアプリケーションの種類にとって重要ですなぜならビデオファイルは大きく、著作権で保護されたメディアには法的/サービス利用規約の複雑さがあり、クリエイターは通常自分のファイルに対して直接の制御を望むからです。

ローカル優先はプロジェクトの運用を簡単に保ちます。ユーザーアカウントシステムはなく、ストレージ課金もなく、ホストされたレンダリングキューもなく、クラウドワーカーフリートもなく、メンテナンスが必要なデータベースサーバーもありません.

トレードオフは、ユーザーがローカルに依存関係をインストールする必要があることです：Python、Node.js、FFmpeg、FFprobe、およびyt-dlp。v1では、コア製品を最初にリリースしたいので、このトレードオフを受け入れました。

長期的には、インストール体験を「ダウンロード、開く、作成」に非常に近づけたいと思います

スタック

CuekiyoはFastAPIのバックエンドとReactのフロントエンドに分かれています

メインスタックは以下の通りです

• バックエンド FastAPI、SQLAlchemy、SQLite
• フロントエンド React 19、Vite、Tailwind CSS、shadcn/ui、React Router
• メディア: FFmpeg、FFprobe、yt-dlp
• オーバーレイレンダリング: SatoriベースのHTMLからPNGへのオーバーレイ
• メタデータ: JikanとAniList
• 進捗更新: WebSockets
• プロジェクトストレージ: ローカルSQLiteデータベース＋ローカルファイルシステム

フロントエンドはガイドドワークフローとレビュースクリーンを処理します。バックエンドはパイプライン、状態遷移、メディア処理、ファイルシステムの安全性を所有しています。

アーキテクチャ

高レベルでは、Cuekiyoはメディアパイプラインを囲む状態マシンです。

パイプラインは次のような段階を通ります。

DRAFT
→ LOAD_THEMES
→ SONG_SELECTION
→ SOURCING
→ AWAITING_CANDIDATES
→ DOWNLOADING
→ PROBING_NORMALIZING
→ CUTTING
→ OVERLAYING
→ AWAITING_RENDER_ORDER
→ RENDERING
→ COMPLETED

一部は自動で実行されます。他のものはユーザーゲートです.

ユーザーゲートが重要な部分です.

• 曲の選択
• 候補のレビュー
• オプションのトリム/レビュー決定
• 最終的なレンダリング順序

他のすべては自動化できます.

単一のFastAPIプロセスがパイプラインを所有します。ジョブはバックグラウンドスレッドで実行され、進捗はWebSocketsを通じてフロントエンドにプッシュされます。SQLiteはプロジェクトの状態、ジョブの状態、アクティブなパイプラインロックのハートビートを格納します.

v1では、Cuekiyoは一つのグローバルパイプラインロックを使用します。つまり、一度に一つのプロジェクトがレンダリング/処理されるということです。これは意図的にシンプルな設計です。多くの厄介なクロスプロジェクトの並行処理のバグを避けつつ、クラッシュ回復を理解しやすくしています。

これが永遠の最終アーキテクチャでしょうか？いいえ。

しかしv1のローカルアプリケーションにとっては、正直で保守可能です。

メディアパイプライン

Cuekiyoの最も難しい部分は、良いUIを作ることではありません。

最も難しい部分は、現実世界の奇妙な状況ですぐに崩壊しないメディアパイプラインを作ることでした。

外部のメディアツールは強力ですが、多くの方法で失敗します：

• ソース動画が消失します.
• yt-dlpは予期せぬメタデータを返します.
• FFmpegはエンコーダの問題で失敗します.
• クリップの再生時間またはストリームデータがおかしいです.
• パスに処理していない文字が含まれています.
• GPUエンコードはあなたのマシンでは動作しますが、他の人のマシンでは動作しません.
• ダウンロードしたファイルは存在しますが、後続の処理の生成物は存在しません.

Cuekiyoは、各段階を別々のパイプラインステップとして扱うことで、それらの問題を管理可能なものにしようとしています.

ダウンロード、プロービング、正規化、カット、オーバーレイ、レンダリングはそれぞれ異なる操作です。これにより、フローを検査しやすく、再試行しやすく、UIで説明しやすくなります。

私はサブプロセスの引数をシェル文字列ではなく引数配列として渡すことに注意しました。ユーザーが提供するリンクやファイルシステムパスを扱うローカルメディアツールの場合、それは選択肢の装飾ではありません。それは基本的な安全性です.

GPUエンコーディングとフォールバック

早い段階で実装した機能の一つはNVIDIA NVENCのサポートでした。

地元動画作業をしている多くの人はNVIDIAのGPUを持っており、ハードウェアエンコードはレンダリングをはるかに高速にできます。しかし、NVENCを必須とするのは悪い考えです。なぜなら、すべてのマシンがそれをサポートしているわけではなく、FFmpegのビルドも様々だからです。

したがって、CuekiyoはNVENCのサポートを探して、必要ならばlibx264でCPUエンコードに切り替えます。

そのフォールバックが重要なのは、ローカル優先ソフトウェアは異なるユーザーマシンを適切に処理しなければならないからです。環境があなたのものと完全に同じであると仮定することはできません.

フロントエンド

フロントエンドはReact 19、Vite、Tailwind CSS、shadcn/ui、およびReact Routerで構築されています.

UIの目標は、生の管理ダッシュボードに見えることではありませんでした。よりクリエイティブなツールのように感じさせたいと思いました：

• プロジェクトカード
• ガイド付きステップ
• 明確な状態状態
• クリップ候補レビュー
• 表示可能な進捗
• パイプラインに影響を与える設定が恐怖を感じさせない

フロントエンドはAPIルートとWebSocketの進捗イベントを通じてバックエンドと通信します。ライブな進捗フィードバックは重要ですなぜなら、メディア処理には時間がかかるからです。FFmpegが実行している間にUIが無言で座っていれば、ユーザーは何か問題が起きていると考えます.

バックエンドが重い作業を行っている場合でも、フロントエンドはパイプラインが理解しやすいように感じさせるべきです.

最も大きなデザイン決定：ユーザーが選択する必要がある場合のみ停止

多くの自動化ツールは二つの間違いを犯す：

1. あまりに少なすぎる自動化をして、ユーザーがまだ退屈な仕事を全部やる必要がある。
2. あまりに多くの自動化をして、ユーザーが後で間違った決定を修正しなければならない。

Cuekiyoの中間的な解決策はユーザーゲートモデルである。

アプリが微細な技術的なステップのたびに確認を求めるべきではない。それは面倒になる。

しかし、すべてのYouTubeのソースと最終的な注文をレビューなしで無視して選択することもないべきです。それはリスクがあります。

そのため、パイプラインは機械的な段階を通じて自動的に進行し、好みに基づく決定で一時停止します。

そのモデルは製品を大幅に改善しました。また、ゲートド状態が状態マシンの明確な部分ではなく、ランダムなUI条件ではなくなったため、バックエンドをより理解しやすくしました。

知られるv1のトレードオフ

Cuekiyo v1.0.0は完璧ではなく、それを装うつもりはありません.

v1の最大のトレードオフは以下の通りです.

一度に一つのパイプラインジョブ

グローバルロックはジョンランナーをシンプルに保ち、複数のプロジェクトがローカルリソースを争うのを防ぎます。デメリットは、まだプロジェクト間の並列処理がサポートされていないことです。

ローカルv1リリースのために、これは受け入れ可能だと思います。並列ジョブはロードマップにあります。

簡略化されたconcat/crossfadeグラフ

現在のレンダリングパスはコンパイルフローをサポートしていますが、FFmpegフィルターグラフはより複雑になる可能性があります。より豊かなレンダリンググラフは、将来のトランジションとマルチクリップレイアウトを容易にします。

リトライはより賢くできます

現在のリトライフローはv1モデルにとって十分ですが、より耐久性の高い各段階のカーソルの方が良いでしょう。それにより、アプリは正確な失敗の境界から再開できるようになります。

これらは隠された問題ではありません。私たちはこれらを文書化しています。なぜなら、アーキテクチャについて正直であることを選んだからです。v1の各決定が最終的であるかのように装うよりもです。

私が学んだこと

建築のクエキヨが私にいくつかのことを教えてくれました

1. ローカル優先アプリも製品思考が必要です

「ローカルツール」という考えが「開発者ツール」であると簡単に考えがちですが、クエキヨはUI付きのスクリプトだけではありません。ウォークスルー、明確な状態、有用なエラー、非作成者にとって意味のあるワークフローが必要です

ローカルで実行されるという事実が、製品デザインの必要性を取り除くわけではありません

2. ワークフローが多いアプリでは状態機構が価値があります

アプリが長時間実行されるタスク、ユーザーゲート、再試行、失敗、キャンセル、進捗イベントがあると、暗黙の状態はすぐに煩雑になります.

パイプラインの状態を明示することで、大きく改善しました.

3. FFmpegは強力ですが、ラッパーコードが重要です

FFmpegはほぼ何でもできるが、ユーザーはコマンドグラフを心配する必要はない。本質的な作業は、それを取り巻く安全で検査可能な層を構築することである。

4. 「すべてを自動化する」が常に正しい製品ではない

Cuekiyoの最良のバージョンは、盲目的に動画を作成するボットではなく、繰り返しの労働を取り除きつつ人間の選択をループに含めたスタジオである。

その区別は、私がアプリケーション全体を設計する方法を変えました。

次に何をするか

v1.0.0が公開された今、次の焦点はCuekiyoをより簡単に試せるようにすることです。

最も重要な優先事項は以下の通りです：

• より良い初回起動体験
• ポータブルなデスクトップスタイルのリリース
• より良いインストール/依存関係チェック
• 賢い再試行動作
• 並列プロジェクトジョブ
• より豊富なレンダリング/クロスフェードオプション
• クリエイターに焦点を当てたドキュメントとデモ

コアパイプラインは機能していますが、オープンソースプロジェクトにとって発見可能性とインストールの摩擦が非常に重要です。興味を持つ人がプロジェクトを素早く理解し、試せるようにすべきです.

最終的な考え

キューキヨはニッチなアイデアから始まり、これまでに私が構築してきた最も完全なプロジェクトの一つになりました.

フルスタックアプリ開発、ローカル優先アーキテクチャ、メディア処理、バックグラウンドジョブ、WebSocket進捗、UI/UXデザイン、リリースエンジニアリングを一つのプロジェクトに組み合わせています。

それは私がポートフォリオに欲しかったプロジェクトの種類そのものです：デモだけでなく、製品の意思決定、トレードオフ、実際のワークフローを持つ実際のツールです

ローカル優先ツール、メディアオートメーション、React/FastAPIアプリ、またはただ奇妙に特定のオープンソースソフトウェアに興味があれば、気軽に確認してください

GitHub: https://github.com/unloopedmido/cuekiyo

星とフィードバックは心から感謝します。