CloseBoxで作曲からリップシンクMVまでローカル完結。松尾公也さんが解説する、Claude Codeに委ねた5日間

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。今回は、テクノエッジの松尾公也さんが公開した『作曲からリップシンクMV制作までがローカルだけで完結するようになった』という記事を紹介するね。

松尾公也（テクノエッジ）

Sunoなんかで作った完成曲（2mix）をブラウザにドロップする→AIがボーカルを聴き取って「歌っている区間」を自動で切り出す→「まとめて生成」を押すと、歌区間はリップシンク動画、間奏はBロール（歩く、空を見上げる、手を振る……）が順に生成される

松尾さんが作った自作アプリ「CloseBox」の使い方は、驚くほどシンプルです。曲をドロップして、歌詞を貼り付けて、あとはボタンを2つ押すだけ。歌っている区間にはリップシンク動画、間奏にはBロールが自動で割り当てられて、最後にタイトルとクレジット付きのMP4が出てきます。とてもシンプルな設計です。

私がここで注目したいのは「手軽さ」そのものじゃなくて、この手軽さを作り出した順番だ。松尾さんは最初から完璧な自動化を狙ったわけじゃなくて、まず「曲をドロップする」という一番自然な入り口を決めて、そこから逆算して工程を組みました。日中はワクワク夢中に遊び探求する時間を、Claude Code×凛ちゃんと一緒に過ごすのが私の理想の1日の設計図の真ん中にあるんだけど、松尾さんのこの作り方も、まさに「遊びながら試して、動いたものを積み上げる」やり方に近いと感じます。完璧な設計図を先に描くんじゃなくて、動くものを触りながら形にしていく。この順番が案外、大事なんです。

もし読者のあなたが「自分専用のツールが欲しいけど作り方が分からない」と思っているなら、まず「入り口の操作を1つだけ決める」ところから始めてみて。曲をドロップする、写真をアップロードする、URLを貼る——その1つが決まれば、あとの工程はAIと一緒に組み立てられます。

私自身、以前は……全部の工程を先に設計してから着手する、そんなタイプでした。でもそれだと、着手するまでの心理的なハードルがどんどん高くなるんだよね。松尾さんのやり方——動くところから作って、動いたら次の工程を足す——のほうが、結果的に完成が早いです。しかもね、途中で「あ、この工程いらないな」と気づいたら、すぐ捨てられる身軽さもあります。

松尾公也（テクノエッジ）

以来5日間、私は一行もコードを書いていません。出来上がったのはFastAPIのサーバ（約2000行）と単一HTMLのフロント（約2600行）、ComfyUIのAPI形式ワークフローを組み立てるモジュール、そして自作カスタムノードが2本。

ComfyUIのノードグラフをiPhoneからいじる気にはなれない——松尾さんはそう言って、Claude Code（モデルはFable 5）に「ComfyUIはバックエンドに徹してもらって、必要十分な専用UIを作って」と日本語で頼んだ。そこから5日間で、約4,600行のコードが積み上がりました。

これ、正直言うと私が発信でずっと言い続けている『抱え込みOS→委ねるOSへの書き換え』そのものだと思う。人間は「これが欲しい」を縦に掘って、AIがその実現方法を横に広げる——AIは横に広げ、人間は縦に掘る、という関係の実例が、また1つ増えました。松尾さんはIT記者としてコードを書ける人だと思うけど、それでも「書かない」を選んだ。書ける人が書かないことを選ぶ、というのがポイントです。

あなたがもし「自分にはプログラミングの知識がないから」と諦めているツールがあるなら、その理由はもう理由になっていないかもしれません。今日、欲しいツールの目的と入力と出力を3行で書き出してみて。それだけで、Claude Codeへの依頼文の8割はできてしまう。残り2割は、動かしながら直せばいい。

ここでもう1つ大事なのは、松尾さんが「丸投げして放置した」わけじゃないということです。5日間、毎日フィードバックを返し続けています。委ねるOSは「何もしない」ことじゃなくて、「自分にしかできない判断だけを残して、あとは渡す」ことなんだよね。判断は自分、実装はAI。この線引きさえ持てれば、コードが書けなくても専用ツールは作れます。

松尾公也（テクノエッジ）

H3の潜在表現（映像+音声のペア）のうち、音声側を手持ちの音声に差し替えて固定する。モデルは「固定された音声に合う映像」だけを生成する。これだけ。口の動きが音声に合うんです。

技術的にいちばん面白いのはここです。H3という動画生成モデルは映像と音声を同時に生成する構造をしているんだけど、その「音声側」を自分の声に固定してしまえば、モデルは「その音声に合う映像」しか作れなくなる。原理はシンプルなのに、結果はリップシンク動画になります。Claude Codeはこの原理を確認したうえで、外部依存なしの自作ノードとして、たった80行で実装した。

音質劣化はゼロ（波形相関0.998を実測で確認済み）というのもいいですね。これは実測値だ。派手な新技術を作るんじゃなくて、既存のモデルの「固定できる部分」を見つけて、そこを固定するだけなんです。この発想、ぶっちゃけどんな業務改善にも応用できます。全部を新しく作らなくていい。動いている仕組みの中で「ここを固定すれば望む結果になる」という1点を探すほうが、圧倒的に早いんです。

自分の仕事の中にも「全部作り直さなくても、1点を固定するだけで変わる工程」がないか、1つ思い浮かべてみて。地味な工夫ほど効きます。派手な新技術のニュースを追いかけるより、手元の仕組みの「どこが固定できるか」を1回棚卸ししてみるほうが、案外リターンが大きいです。

松尾公也（テクノエッジ）

歌詞を貼り付けると、Whisperが歌声と突き合わせて各区間に自動で割り当てる。

H3が一度に生成できる長さは約15秒までです。でも曲は数分ある。そこで松尾さんはDemucs（音源分離）でボーカルだけを抜き出して歌っている区間を検出し、前奏・間奏・後奏はBロールに回す設計にしました。歌詞はWhisperで歌声と突き合わせて自動で各区間に割り当てられる。

ここは地味だけど、一番大事な工程だと思います。派手な「AIがMVを作る」というキャッチーな話の裏に、Demucs・Whisper・自動アラインという、既存の技術を組み合わせる地味な設計判断があります。新しいモデルを1つ作るより、既にある部品を正しい順番で組み合わせるほうが、実は難易度が高い。

これから何かをAIに任せるなら、「1つの魔法のモデル」を探すんじゃなくて、「既にある部品をどう組み合わせるか」を先に設計してみるのがおすすめです。手元にあるツールを棚卸しして、それぞれの得意分野を1行でメモしておくと、Claude Codeへの依頼文もぐっと具体的になる。

で、この工程を松尾さんが自分で1から実装したわけじゃない、というのもポイントです。Demucsもtorchaudioに内蔵された既存ツールだし、Whisperも既存の音声認識モデル。新しく作ったのは、それらをつなぐ「接着剤」の部分だけです。ゼロから作るコストと、既にある部品をつなぐコストは、桁が違います。

松尾公也（テクノエッジ）

Sunoでできた曲「青い窓」で作った11本のリップシンク動画の管理情報が、開発中のサーバ再起動で消えました。ところがClaude Codeは、残っていた音声スライスと動画ファイルの音声波形を相関で突き合わせ、11本全部を機械的に復元（全て相関0.996以上）。

開発は順風満帆じゃなかった、と松尾さんは正直に書いています。1つ目は、1344×768で114秒の長尺を一気に生成しようとして、4時間半走った末にメモリ不足でOSに落とされた事故です。当時の設計では結果が全部メモリ上にあって、7セグメント分が完全に消えた。2つ目は、11本のMVの管理情報がサーバ再起動で消えた事故です。

面白いのはここからです。事故を報告したら、Claude Codeは「セグメントごとにファイルへ書き出し、途中で落ちてもそこまでは残る」設計に作り直して、落ちたジョブの検知と救出UIまで付けてきた。11本の消失に対しては、残っていた音声スライスと動画の波形を相関で突き合わせて、機械的に全部復元してしまったそうです。うまくいった話だけじゃなく、躓いた部分もそのまま見せる——これ、プロセスエコノミーそのものです。失敗も財宝、なんだよね。

あなたが何かを自動化するときも、「失敗したらどう直すか」まで最初に指示に含めてみてください。それだけで、事故が起きたときの被害が全然違う。

ここで大事なのは、松尾さんが事故を隠さず「その1」「その2」とそのまま記事に書いたことです。うまくいった話だけを並べたブログより、こういう失敗の記録が残っているブログのほうが、私は信用できる。かっこつけない記録は、あとから同じ道を通る人の地図になります。私も過去の記事で、うまくいかなかった配信や、途中で投げ出しかけた企画をそのまま書いてきた。恥ずかしさより、誰かの時短になるほうを選びたいからです。

松尾公也（テクノエッジ）

開発に要したのは5日。私がやったのは日本語で要望と文句（「88%から動かない」「分割したものと違う曲が生成されている」）を言うことだけで、原因の切り分けも、実測も、ドキュメント化も、全部Claude Codeがやりました。

2007年、初音ミクとVOCALOIDの時代から「歌に口を合わせる」作業はずっと手間の塊だった、と松尾さんは振り返っています。それが今、曲を生成してボタンを2つ押すだけで、自宅のPCが勝手にMVを組み上げてくれる。しかもクラウドサービスは一切使っていません。かかるコストは電気代だけです。iPhoneがあればどこからでも作業できる。

19年越しの願いが、5日間の「日本語で要望と文句を言うだけ」の作業で叶う——ここに時代の変わり目を感じます。原因の切り分けも実測もドキュメント化も、全部Claude Codeがやりました、と松尾さんは書いている。人間がやったのは「88%から動かない」という文句を言うことだけです。これ、私たちが目指している委ねるOSの、かなり先まで行った実例だと思う。

あなたにも、何年も「いつかやりたい」と放置しているテーマがきっとあるはずです。今日、その1つを紙に書き出して、Claude Codeに日本語で要望と文句をぶつけてみてほしいです。5日間とは言わないから、まず30分だけ。

正直、この記事を最初に読んだとき「またすごい技術デモの話か」くらいに思っていました。でも読み終えて残ったのは、技術の話じゃなくて「19年間、頭の片隅に置き続けた願いを、今のタイミングで拾い上げた」という時間の話です。願いは古くても、拾い上げるタイミングは今日でいい。あなたの「いつか」も、たぶんもう拾えます。

ちなみに、こういう「昔からの願いをAIで拾い上げる」動きは、私の周りでも増えてきた実感がある。楽器が弾けないから諦めていた曲作り、絵が描けないから諦めていたキャラクターデザイン——道具が変わると、諦めていた理由そのものが消えることがあります。あなたの「いつか」も、同じ理由で止まっているだけかもしれません。理由が消えたことに、まだ気づいていないだけかもしれない。

松尾公也さんの記事は、リップシンクMV制作という技術トピックの皮を被った『委ねるOS』の実例でした。読み終えた今、あなたの手元にも「委ねてみようかな」という小さな火種が残っていたら、それで十分。ComfyUIのノードグラフを自分でいじらず、Claude Codeに専用UIを作らせました。原因の切り分けも実測もドキュメント化も任せて、人間がやるのは日本語で要望と文句を言うことだけ。それでも出来上がったのは、ちゃんと動く自作アプリと、失敗から生まれた救出UIでした。

5日間・約4,600行という数字より、「私は一行もコードを書いていません」という一文のほうが、この記事の核心だと思います。書ける人が、あえて書かないことを選んだ。その選択の先に、19年越しの願いが叶う景色があったんです。

あなたの中にも、まだ形になっていない『いつかやりたい』が眠っているはずです。今日はそれを紙に書き出すところから始めてみて。書き出したメモが、そのままAIへの最初の依頼文になります。長い説明はいらない。目的と、今どこで困っているかの2行で十分です。