社内の研修動画や採用コンテンツを編集するとき、「この映像をクラウドに上げていいのか」と迷った経験はないでしょうか。
NDA案件の素材、未公開の製品映像、社内インタビュー——そういった映像を CapCut に読み込ませた瞬間、ByteDance 傘下のサーバーにデータが渡ることになります。
そんな背景から生まれたのが OpenCut です。
GitHub スターが急増し、「CapCut の OSS 代替」として話題になっているこのプロジェクトを、実際にセルフホストして社内動画制作に使えるか検証しました。
結論から言うと「条件次第では今すぐ使える、ただし正直に言って荒削り」です。
動かすまでの手順・機能の実態・社内展開の注意点を順に整理していきます。
OpenCut とは何か――67,000 スターと現実のギャップ
2025年、CapCut の利用規約改定が話題になりました。
アップロードしたコンテンツに対して永続的・取消不能なライセンスを CapCut 側が取得できる内容で、クライアントワークや NDA 案件を抱えるエンジニアや制作チームが「これはまずい」と感じた事例が相次ぎました。
その改定からわずか10日後に OpenCut は誕生しています。
GitHub スターは公開から約1年で 67,000 を超えました。
「データが自分のマシンから出ない動画エディタ」への需要の大きさを示す数字ですが、ここで少し立ち止まる必要があります。
スターの数と完成度は別物です。
公式ブログには「This is super early alpha. Expect bugs, missing features, and rough edges.」とはっきり書かれています。
これは免罪符ではなく、現実として受け止めるべき一文です。
もう一つ、把握しておきたい複雑な事情があります。
リポジトリが事実上2つ存在しているという点です。
現在 opencut.app で動いているのは classic 版（opencut-app/opencut-classic）で、これは最初に公開されたコードベースです。
一方、メインリポジトリ（OpenCut-app/OpenCut）は ground-up からの書き直しが進行中で、こちらが今後の本流になります。
どちらを触るかで手順も完成度も変わるため、「OpenCut を試した」という情報を読むときは、どちらのリポジトリを対象にしているかを確認する必要があります。
技術スタックは Next.js / TypeScript / Bun / Postgres / Redis に加え、パフォーマンスクリティカルな処理を Rust WASM で担う構成です。
この構成がセルフホストの手間に直結するので、次節で詳しく見ていきます。
ローカルで動かすまで――最小手順と詰まりどころ
ここではメインリポジトリ（rewrite 版）を対象にします。
公式ドキュメントに沿った最小手順は以下のとおりです。
# 1. リポジトリをクローン
git clone https://github.com/OpenCut-app/OpenCut.git
cd OpenCut
# 2. 環境変数をコピー（デフォルト値が Docker Compose の設定と合っている）
cp .env.example .env
# 3. DB・Redis を起動
docker compose up -d db redis serverless-redis-http
# 4. 依存関係インストールと dev サーバー起動
bun install
bun dev:web
.env.example は Docker Compose のデフォルト設定と合わせて作られているため、ローカル検証であればそのままコピーするだけで動きます。
アプリは localhost:3000 で起動します。
WASM 周りについては、フロントエンドだけ触るなら気にしなくて大丈夫です。
Rust ツールチェーンが必要になるのは WASM パッケージ自体を改変するときだけで、通常の開発は bun dev:web だけで完結します。
WASM を触る場合は以下の追加手順が必要です。
# Rust ツールチェーンのインストール（初回のみ）
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# WASM パッケージをビルド
bun run build:wasm
ここまで読んで「思ったより簡単そう」と感じた方、ちょっと待ってください。
GitHub の Issue #280 には「Bun + Docker + Postgres + Redis の組み合わせは依存関係の沼で、初回セットアップに45分以上かかる」という報告があります。
Dev Container 対応が提案されていますが、2025年7月時点ではまだマージされていません。
実際に詰まりやすいのは、Bun のバージョン（v1.2.18 以上が必要）と Docker の起動順序です。
DB と Redis が完全に立ち上がる前に bun install を走らせると接続エラーが出ることがあるので、docker compose up -d の後に少し待つか、ヘルスチェックが通ったことを確認してから次のステップに進むのが無難です。
実際に触ってわかった機能の実態
公式アルファブログに記載されている「今動くもの」と「これから来るもの」を整理すると、現時点の実力がよくわかります。
現時点で動く機能
- 動画のインポート
- タイムライン編集（マルチトラック）
- カット・トリム
- テキスト挿入
- 透かしなしエクスポート（完全無料）
- リアルタイムプレビュー
まだない・荒削りな機能
- エフェクト・トランジション
- 音声編集
- AI 自動字幕・AI 機能全般
- 高度なエクスポートオプション
- 安定したレンダリング品質
CapCut Web 版と並べると、差は正直かなり大きいです。
CapCut にはキーフレームアニメーション、クロマキー、スローモーション、モーショントラッキング、自動キャプション、テキスト読み上げといった機能が揃っています。
OpenCut は現時点でそのほとんどを持っていません。
「α版だから仕方ない」は事実ですが、実務で使おうとすると具体的に何が困るかを把握しておく必要があります。
もう一つ、社内ツールとして展開するうえで見落としがちなリスクがあります。
プロジェクトデータがブラウザのローカルストレージに依存している という点です。
公式の ToS には「Projects are stored in your browser and may be lost if you clear browser data」と明記されています。
ブラウザのキャッシュをクリアしたり、別のブラウザやマシンで開いたりすると、編集中のプロジェクトが消えます。
非エンジニアのスタッフが日常的に使う環境でこれが起きると、かなり痛いです。
社内展開するなら何を考えるか――ストレージ・認証・更新追従
ローカルで動いたら次は「社内の誰でも使える状態」にしたくなります。
プロダクション起動自体は一行です。
docker compose up -d
ただし、ここで重要な注意点があります。
公式の Docker イメージが存在しません。
Railway のデプロイテンプレートには「⚠️ OpenCut does not currently offer an official image. The image used by this template is a fork made by the template author」と明記されています。
つまり、Railway テンプレートや有志のフォークに頼らざるを得ない状況です。
サードパーティフォークはメンテナンスが止まるリスクがあるため、本番環境に使う場合はその点を理解した上で判断してください。
最低限設定すべき .env の項目は以下のとおりです。
# データベース接続
DATABASE_URL=postgresql://user:password@localhost:5432/opencut
# Redis
REDIS_URL=http://localhost:8079
# 認証シークレット（BetterAuth）
BETTER_AUTH_SECRET=your-secret-here
BETTER_AUTH_URL=https://your-domain.example.com
認証については、BetterAuth が組み込まれているため基本的なログイン機能は動きます。
ただし、社内 IdP（SAML や OIDC）との連携は自前実装が必要です。
「社内の特定メンバーだけがアクセスできる」状態にするには、ネットワーク層での制限（VPN 必須化など）か、認証周りのカスタマイズが現実的な選択肢になります。
もう一つ正直に伝えておきたいのが、 更新追従のコスト です。
rewrite がいつ完了するかは現時点で不明で、破壊的変更が入るリスクがあります。
フォークして特定バージョンに固定して運用するか、本家を追い続けるかは、チームの保守体制と相談して決める必要があります。
α段階のプロジェクトを本番に入れるということは、そのコストを引き受けることでもあります。
「今すぐ使えるか、様子見か」――用途別の判断基準
検証を踏まえて、判断軸を整理します。
今すぐ使える条件
- 社内検証・PoC など、壊れても困らない用途
- カット・トリム・テキスト挿入だけで完結するシンプルな編集
- エンジニアが自分で保守・トラブルシュートできる体制がある
- NDA 案件や未公開製品映像など「データをクラウドに出したくない」動機が、機能の荒削りを上回る場面
まだ待ったほうがいい条件
- 非エンジニアが日常的に使う社内ツールとして展開したい
- 対外向け動画でクオリティの高い仕上げが必要
- エフェクト・トランジション・AI 字幕などの機能が前提になっている
- マルチユーザーで素材を共有するワークフローが必要
- 安定稼働の保証が求められる本番環境
「OSS だから無料で素晴らしい」という話ではありません。
セルフホストには初期構築コスト・保守コスト・アップデート追従コストが伴います。
それを天秤にかけた上で、「データをクラウドに出さない」という価値がコストを上回るかどうかが判断の核心です。
rewrite が完了して安定したタイミングで再評価する、という「様子見」も十分に合理的な技術判断です。
GitHub の動向を Watch しておいて、破壊的変更が落ち着いたタイミングで本格検討する——そのスタンスは現時点では賢い選択だと思います。
株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援・DX 推進に取り組んでいます。
OpenCut のようなセルフホスト型ツールの導入検討や、社内動画制作フローのシステム化についてご相談があれば、お気軽にどうぞ。
詳しくは お問い合わせページ からご連絡ください。