GitHub公開・ドネート導入前リスク棚卸し

MusicVideoCreator を GitHub で配布し、「もし役に立ったらコーヒーを一杯」型の任意支援を受ける前提で、公開前に問題になりそうな点を優先度順に整理した資料です。 結論だけ先に言うと、寄付導線そのものは大きな問題ではありません。現時点の主な公開ブロッカーは、ライセンス未設定、同梱資産の権利・出所の未整理、Remotion の別ライセンス条件、TypeScript 検証失敗、wheel 配布時の UI 欠落です。

対象: G:\Projects\Codex\MusicVideoCreator 調査日: 2026-05-15 想定: public GitHub repository + 任意ドネート 法務・税務助言ではなく公開リスク棚卸し

短い結論

このまま public にするのは勧めません。 コードの方向性ではなく、公開時の説明責任と配布物の整合性が足りません。 最低限、P0 を潰してから公開するのが妥当です。

一番安全な初回公開案は、コードと小さな自動生成デモだけを公開し、キャラクター画像・APNG・参照 GIF はいったん同梱しない構成です。 資産も配るなら、各素材の出所、生成手段、利用許諾、再配布可否を manifest と README に明記してからにした方がいいです。

5 P0: 公開前に必ず処理したい項目
5 P1: 初回公開前に強く推奨
208.53MB public/assets、reference、examples の資産量
NG npm run typecheck は現状失敗

優先度の定義

優先度 意味 今回の判断基準
P0 公開前に必ず処理 公開後に取り返しがつきにくい、利用者に誤解を与える、または「動く配布物」として破綻する問題。
P1 初回公開前に強く推奨 即炎上・即停止ではないが、公開後すぐに信用や安全性を削る問題。
P2 公開直後でも可 品質、保守性、導線の問題。公開後のロードマップとして扱えるもの。
P3 余裕があれば 印象や運用の改善。初回公開を止めるほどではないもの。

調査で確認した事実

項目 結果 見方
Python tests OK: python -m unittest discover -s tests -t . は 83 tests 成功 Python 側の単体テストは公開判断のプラス材料。
TypeScript FAIL: ui_preview/App.tsx(810,80) と (811,61) で selection.id の型エラー この状態で「ビルド可能」とは言いにくい。
npm audit FAIL: production 依存に high 1件、moderate 4件 fast-uri high と Remotion/PostCSS 系 moderate。Remotion 4.0.461 への非メジャー更新で解消可能と audit が示した。
LICENSE / FUNDING / SECURITY なし: root の LICENSE、.github/FUNDING.yml、SECURITY.md は未検出 公開・寄付・脆弱性報告の最低限の入口が未整備。
配布 wheel 不完全: wheel には ui_static/*.html は入るが ui_static/generated/.../app.js は入らない pyproject.toml の package-data が ui_static/* のみなので、pip 配布時に UI が壊れる可能性が高い。
資産量 228 files / 208.53MB。内訳は PNG 151.45MB、APNG 45.78MB、GIF 11.08MB 1ファイル 25MB 超は見つからないが、通常 Git に同梱するには重め。
未コミット変更 11 files modified 公開前は clean working tree で検証し直すべき。

P0: 公開前に必ず潰す

優先度 問題 根拠 リスク 推奨対応
P0-1
プロジェクト本体のライセンスが未設定

GitHub で public にするだけでは、他人が自由に利用・改変・再配布できる状態にはなりません。

 LICENSE なし。pyproject.toml に license なし。package.json に license なし、かつ "private": true。 利用者が合法的に使ってよい範囲を判断できない。寄付を受ける場合、「公開しているが使ってよいのか分からない」状態は信用を落とす。 コード用のライセンスを決めて root に LICENSE を追加する。資産は別ライセンスにするなら LICENSE-CODE、LICENSE-ASSETS、THIRD_PARTY_NOTICES.md に分ける。
P0-2
同梱画像・GIF・APNG の権利と出所が未整理

このリポジトリはコードだけではなく、キャラクター素材・生成画像・参照 GIF を大量に含みます。

 public/assets、reference、examples 合計 208.53MB。 gptimage 名の source 画像が多数。 reference/teto-kasane-teto.gif と reference/black-swan-evernight-dance.gif も tracked。 既存メモにも「素材、フォント、音楽、AI 生成画像は license/provenance tracking が必要」とある。 再配布権が曖昧な素材を public repo に置くと、削除依頼、DMCA、信用低下の原因になる。ドネート導線を置くと、営利色が増して見える。 初回公開は「コード + 自動生成デモ素材」に絞るのが安全。資産を残すなら assets-provenance.json などで、出所、作者、生成サービス、生成日、許諾、再配布可否、商用可否、元プロンプトまたは制作メモを記録する。第三者 IP 由来・出所不明の参照 GIF は除外する。
P0-3
Remotion の別ライセンス条件を利用者へ明記していない

このプロジェクト自体を MIT 等にしても、Remotion の利用条件は別に残ります。

 package.json は Remotion 4.0.451 系に依存。 package-lock.json には Remotion License、SEE LICENSE IN LICENSE.md、UNLICENSED の Remotion 関連 package がある。 生成済み UI bundle には Remotion の license warning 文言も含まれる。 4人以上の営利組織などが、プロジェクトの LICENSE だけを見て Remotion も同条件だと誤認する可能性がある。これは利用者側にも作者側にも良くない。 README と THIRD_PARTY_NOTICES.md に「Remotion は別ライセンス。利用者は Remotion の条件を確認すること」と明記する。 Remotion の warning を隠す場合も、条件を理解した上で acknowledgeRemotionLicense を扱う。
P0-4
TypeScript 検証が失敗している

公開前の最低限の品質ゲートとして、npm run typecheck は通したいです。

 ui_preview/App.tsx(810,80)、ui_preview/App.tsx(811,61): Property 'id' does not exist on type '{ kind: "lyrics"; } | { kind: "image"; id: string; }' 「clone して検証したら即失敗」になる。寄付を置く以前に、利用者の信頼を削る。 selection.kind の narrowing を修正し、npm run typecheck、npm run build:ui、必要なら Remotion smoke を通す。
P0-5
pip / wheel 配布時に UI bundle が欠落する

GitHub 配布でも pip install git+... を案内するなら実害があります。

 実際に wheel を作ると、music_video_creator/ui_static/full-preview.html 等は含まれる一方、music_video_creator/ui_static/generated/ui-preview/app.js 等は含まれなかった。 pyproject.toml の指定は music_video_creator = ["ui_static/*"]。 mvc ui 起動後、React bundle が 404 になり、Full Preview / Lyrics Timing / Shorts Preview が壊れる。 package-data を再帰指定にする。例: ui_static/*.html、ui_static/generated/**/*.js を含める。修正後に wheel を作り直して python -m zipfile -l で確認する。

P1: 初回公開前に強く推奨

優先度 問題 根拠 推奨対応
P1-1 production 依存に npm audit 脆弱性がある npm audit --omit=dev --json で high 1件、moderate 4件。fast-uri の path traversal / host confusion と Remotion/PostCSS 系。 Remotion を audit が示す修正版へ上げ、lockfile を更新。更新後に typecheck、UI build、Remotion smoke を再実行。
P1-2 ドネート導線のファイルと文言が未整備 .github/FUNDING.yml がない。GitHub は Buy Me a Coffee を buy_me_a_coffee キーで扱える。 .github/FUNDING.yml を追加し、README には「任意支援であり、機能追加・優先対応・第三者ライセンス付与を約束しない」と明記する。
P1-3 ローカル UI の安全境界を README に明記していない UI は既定 127.0.0.1 だが、--host を受け取り、ローカルファイルパス、ffmpeg、Remotion render、PowerShell の file picker を扱う。 「この UI はローカル制作用。LAN やインターネットに公開しない」と明記。必要なら loopback 以外は --unsafe-host 的な明示フラグを要求する。
P1-4 第三者ライセンス表が不足している Node 依存は MIT 181件以外に MPL-2.0、CC-BY-4.0、Remotion License、SEE LICENSE、UNLICENSED が混在。Python optional 依存は stable-ts MIT、openai-whisper MIT、torch BSD-3-Clause、torchaudio は pip metadata 上 license 空欄。 THIRD_PARTY_NOTICES.md を作り、Node / Python / FFmpeg / Remotion / AI生成素材を分けて記載する。FFmpeg は利用者の build option 依存で LGPL/GPL/nonfree の差があるため、同梱しないなら「ユーザー環境の ffmpeg を使う」と明記。
P1-5 公開直前の working tree が clean ではない 調査時点で remotion/src/components/presets/FullLandscapeSong.tsx、ui_preview/App.tsx、src/music_video_creator/ui.py など 11 files modified。 公開用ブランチを切り、不要な差分を除外し、検証コマンドを通した状態で tag / release を作る。

P2: 公開後でもよいが早めに直す

優先度 問題 見解 推奨対応
P2-1 リポジトリが資産で重い GitHub の通常 Git は 50MiB 超で警告、100MiB 超でブロックだが、今回は単体 25MiB 超は見つからない。ただし合計 208MB は clone 体験として重い。 コード repo と asset pack を分離。大きな素材は GitHub Releases、LFS、または外部ストレージへ。公開 repo には最小デモだけ置く。
P2-2 実曲・手元環境前提の npm scripts が多い musics/RISE_RISE、Electric Sheep Little Girl 前提の scripts は、新規利用者には失敗する。 public README の Quick Start は demo:assets から通る導線を主にし、実曲 scripts は local: prefix や docs の private workflow に寄せる。
P2-3 CI が見当たらない .github ディレクトリがなく、public repo で最低限見たい自動検証がない。 GitHub Actions で Python tests、npm typecheck、UI build、wheel contents check、npm audit の少なくとも一部を回す。
P2-4 履歴資料に個人環境パスが残っている G:\Projects\...、C:\Users\owner\... などが docs / examples に残る。秘密情報ではないが、公開資料としては粗い。 現行 docs からは個人パスを消し、履歴資料は docs/archive に寄せるか、公開対象から外す。
P2-5 community health files がない 小規模個人プロジェクトなら必須ではないが、Issue / PR を受けるなら必要になる。 SECURITY.md、CONTRIBUTING.md、CODE_OF_CONDUCT.md、Issue templates を最小で用意する。
P2-6 npm package metadata が private 前提 GitHub 配布だけなら "private": true は致命的ではないが、npm publish や package metadata としては未整備。 npm 公開しないなら README に明記。将来 npm に出すなら license、repository、bugs、homepage、funding を追加し、private を外す。

推奨公開パターン

A. コード中心で先に公開

最も現実的。資産は最小デモだけにし、キャラクター素材や参照 GIF は外す。P0 を処理すれば、比較的短時間で public にできる。

推奨度: 高

B. 資産込みで公開

見栄えは良いが、素材ごとの出所・許諾・再配布可否が必要。今の状態では一番事故りやすい。

推奨度: 低。やるなら asset manifest が先。

C. Private beta / 招待制

人に触ってもらう目的なら妥当。公開前に UI や配布導線の不具合を見つけやすい。

推奨度: 中。公開前テストとして有効。

D. GitHub Releases で asset pack 配布

コード repo を軽く保ち、サンプル素材は release asset として分ける。素材ライセンスも release notes に書ける。

推奨度: 中から高。資産を配るならこの形が無難。

ドネート導線の扱い

「もしよかったらコーヒーを一杯」は、プロジェクトへの任意支援としてなら自然です。 問題になるのは、支援が機能提供、サポート契約、商用利用許諾、Remotion のライセンス代替のように見えることです。 ここは文言で切り分けるべきです。

README に置くならこのくらいが安全

このプロジェクトが役に立った場合は、任意で支援できます。
支援は開発継続の助けとして受け取りますが、機能追加、優先対応、個別サポート、第三者ライセンスの付与を約束するものではありません。

.github/FUNDING.yml の例

buy_me_a_coffee: your_username

Buy Me a Coffee の username は実アカウントに置き換えてください。税務・会計処理は受け取り主体の国・形態で変わるので、そこは別途確認が必要です。

公開前チェックリスト

  1. コードのライセンスを決め、root LICENSE、pyproject.toml、package.json に反映する。
  2. 資産を「公開する」「外す」「release asset に分ける」に分類し、公開するものだけ provenance と license を書く。
  3. Remotion の別ライセンス条件を README と THIRD_PARTY_NOTICES.md に明記する。
  4. npm run typecheck の失敗を直す。
  5. Remotion / npm 依存を更新し、npm audit --omit=dev の high を潰す。
  6. wheel に ui_static/generated/**/*.js が入るよう pyproject.toml を直し、wheel contents を確認する。
  7. README の Quick Start を、手元の実曲なしで通る demo-first 導線にする。
  8. ローカル UI の安全注意を README に書く。
  9. .github/FUNDING.yml を追加し、任意支援の文言を明確にする。
  10. clean working tree で python -m unittest discover -s tests -t .、npm run typecheck、npm run build:ui、必要なら npm run smoke:remotion を通す。

参照した公式情報

公式情報は 2026-05-15 時点で確認。ライセンス、税務、寄付プラットフォーム規約は変わる可能性があるため、公開直前に再確認してください。