2026年7月25日（土）、越前町の「あさひ祭り」で、来場者がスマホから送った写真をAIが「ねぶた」風のあんどん山車に変え、会場の大型スクリーンに巡行させる企画を実施しました。当日は150〜200枚の写真が寄せられ、本物のあんどん山車の巡行と並べて投影しました。
会場に貼ったQRコードを読んで写真を送ると、数分後にはその写真が和紙と光でできた山車になり、スクリーンを横切っていきます。届いたのはペットの犬や猫、バイク、工事現場の重機、家族の写真。
本物の隣に置いたときが一番だった
反応が最も良かったのは、本物のあんどん山車が目の前を通るのと同時に、スクリーンにも山車を流したときでした。AIが作ったものを単体で見せるより、本物との対比になったときに価値が出る。これが今回いちばんの発見です。
もうひとつは、動く山車への反応の良さでした。静止したままより、光が明滅したり尻尾やはさみが動いたりするほうが、明確に足を止めてもらえます。
題材にねぶたを選んだのは、内部から発光して見える造形だからです。プロジェクタの投影は、暗い場所で光っているものを映すのが最も映えます。あさひ祭りにはもともと地元のあんどん山車があり、その隣に並べても浮かないモチーフでもありました。
スクリーンは単管足場に白い布を張った自前のものです。
仕組み
ここからは技術的な話です。
投稿の経路は運営の手元PCを通りません。投稿ページはCloudflare Pages上の静的HTML1枚で、来場者のブラウザからCloudinaryへ直接アップロードします。会場のPCが落ちても投稿の受付だけは生き続ける。イベント会場という不安定な環境で、止まってはいけないものと止まってもいいものを分けた判断です。
生成は3段構成で、画像AIでねぶた化し、ビジョンLLMで動画プロンプトを最適化し、動画AIでループ動画にします。
ビジョンLLMが何をしているか
動画生成のベースプロンプトには「山車の可動部が機械的に動く」という記述があります。しかし、どの部位が動くかは画像ごとに違います。龍なら尻尾・背鰭・顎、カニならはさみと脚。ベースプロンプトのままでは動画AIは何を動かせばいいか分からず、無難な微動に逃げます。
そこで、生成した山車画像をビジョンLLM（Claude Sonnet 5）に見せ、「何が動くか」の記述だけを、その画像に実在する部位へ書き換えさせています。
一方で、カメラ固定・背景は完全な黒・始点と終点を一致させる、といった制約文はLLMに触らせません。これらは投影の成立条件そのものだからです。動くものだけをLLMに任せ、守るべき制約は人間が書いたまま通す、という切り分けにしています。
運営画面
投稿を選んでパイプラインを回す生成タブと、山車を行列に並べて巡航速度や提灯の明滅を調整するプレイリストタブの2画面です。パラメータ調整はAPIを一切呼びません。生成済みの動画を固定して見え方だけを詰めるので、現地でのチューニングにコストがかからないようにしています。
反省
現地で最も求められたのは「投稿した人が、自分の写真の山車をその場で見つけられること」でした。これに対して、設計が遅すぎました。
原因は3つ重なっていました。取り込みループが1件ごとに画像生成の完了を直列で待つため、投稿がまとまって届くと詰まる。しかも処理順が古い順なので、今まさに投稿した人ほど後回しになる。さらに巡回が単純なラウンドロビンで追加が末尾なので、新しい山車は最大でプレイリスト一周分待たされる。
そして、自分の山車が出てこないので繰り返し投稿する人が増え、それがさらに詰まりを悪化させました。遅延が投稿を呼び、投稿が遅延を生む状態です。
もうひとつ痛かったのは、動画化が手動操作だったことです。反応が一番良かった「動く山車」を、当日はほとんど出せませんでした。
次回は取り込みと生成を分けてキュー化し、処理順を新しい順にし、再生回数の少ない山車を優先して出す。ここから設計し直します。
なお費用は事前検証込みで約$60、投稿画像の生成は1枚あたり約$0.05なので、当日分の実費は$10に届きません。ボトルネックはコストではなく時間でした。
おわりに
弊社は普段、アウトドアショップ ON BOARD の運営と、飲食店・小売店向けのシステム開発を行っています。今回のような企画は、自社で手を動かして技術を検証する場として続けているものです。
写真を送ってくださった皆様、ご協力いただいた祭りの関係者の皆様、ありがとうございました。次回はもっと速く、もっと動く山車をお見せします。