2026年7月25日（土）、越前町の「あさひまつり」で、来場者がスマホから送った写真をAIであんどん山車に変え、会場の大型スクリーンに巡行させる企画を実施しました。当日は150〜200枚の写真が寄せられ、本物のあんどん山車の巡行と並べて投影しました。
会場に貼ったQRコードを読んで写真を送ると、早ければ数分後にはその写真が和紙と光でできた山車になり、スクリーンを横切っていきます。届いたのはペットの犬や猫、バイク、工事現場の乗り物、まつりの風景、家族の写真。
本物の隣に置いたときが一番だった
反応が最も良かったのは、本物のあんどん山車が目の前を通るのと同時に、スクリーンにも山車を流したときでした。AIが作ったものを単体で見せるより、本物との対比になったときに価値が出る。これが今回いちばんの発見です。
自分が送った写真が山車になって映し出されたときや、思わぬ山車が現れたときには歓声が上がりました。
もうひとつは、動く山車への反応の良さでした。静止したままより、光が明滅したり、手足や尻尾、はさみが動いたりするほうが、明確に足を止めてもらえました。
実際に生成した動くあんどん山車
数秒のループ動画として作り、始点と終点をつないでスクリーン上を巡行させています。
突貫工事で作ったスクリーン
地元の看板屋さんに急遽協力してもらい、足場に看板を取り付け、そこに障子紙を張った自前のスクリーンです。
サイズは3.6m×2.7m、対角にすると約177インチ。家庭用の100インチプロジェクタースクリーンの3倍以上の面積です。
障子紙にすることで実際の山車のようなざらざらとした光のテイストが出てとても良い雰囲気になりました。
仕組み
ここからは技術的な話です。
大前提として予算に上限があるので、従量課金が積み上がる構成を避け、無料枠に収まるサービスで組む方針で設計しました。
投稿ページはCloudflare Pages上の静的HTML1枚で、来場者のブラウザからCloudinaryへ直接アップロードします。フロントエンドもバックエンドも自前のサーバーを持たない構成なので、会場のPCが落ちても、通信が不安定でも、投稿の受付だけは生き続けます。
無料枠に収まること、サーバーを持たないこと、投稿だけは落ちないこと。イベント会場という不安定な環境で、止まってはいけないものと止まってもいいものを分けた結果の構成です。
生成は、VLM（画像を読めるAIモデル）による写真の解析 → 画像生成 → 生成物の解析 → 動画生成 → ループ整形 → ループ検証という6工程で動きます。実際の1件では、投稿写真がこう変わります。
01投稿された写真
02image to image LLM であんどん山車風に変換
03image to video LLM でループ化
AI山車の生成方法
6工程のうちAIモデルを呼ぶのは1〜4です。写真をVLMで解析してから画像を作り、その画像をもう一度VLMに見せてから動画にする。
モデル選定では、VLMはGPT-5.6シリーズ・Gemini・Qwen系を比較し、速度と画像の理解度でClaude Sonnet 5を選びました。動画生成はSeedance・Klingなどと比較し、価格と安定感でVeo 3.1を採用しています。
生成に入る前に「何を作るか」を必ず言葉にしておくのがこのフローの要点で、なかでも効いているのが工程3です。
動画生成のベースプロンプトには「山車の可動部が機械的に動く」という記述があります。しかし、どの部位が動くかは画像ごとに違います。龍なら尻尾・背鰭・顎、カニならはさみと脚。ベースプロンプトのままでは動画AIは何を動かせばいいか分からず、無難な微動に逃げます。
そこで、生成した山車画像をVLM（Claude Sonnet 5）に見せ、「何が動くか」の記述だけを、その画像に実在する部位へ書き換えさせています。
また、動画AIはモデルごとにプロンプトの流儀が違います。この書き換え工程で差を吸収しているので、モデルを差し替えても同じ設計のまま動かせます。
一方で、カメラ固定・背景は完全な黒・始点と終点を一致させる、といった制約文はLLMに触らせません。これらは投影の成立条件そのものだからです。動くものだけをLLMに任せ、守るべき制約は人間が書いたまま通す、という切り分けにしています。
運営画面
投稿を選んでパイプラインを回す生成タブと、山車を行列に並べて巡行速度や提灯の明滅を調整するプレイリストタブの2画面です。パラメータ調整はAPIを一切呼びません。生成済みの動画を固定して見え方だけを詰めるので、現地でのチューニングにコストがかからないようにしています。
費用はAIの利用料が事前検証込みで約$80程度でした。
反省
現地で最も求められたのは「投稿した人が、自分の写真の山車をその場で見つけられること」でした。これに対して、処理が遅すぎました。VLMの解析は高速なのですが、画像生成と動画生成に時間がかかります。当日は動画化まで回すのを一部にとどめ、多くは山車風の画像だけを投影して回しました。
再生順の設計も足りませんでした。再生順が単純な追加順の繰り返し（ラウンドロビン）で、できあがった山車はプレイリストの末尾に足されます。そのため新しく投稿した人ほど後回しになり、最大でプレイリスト一周分待たされる状態でした。
そして、自分の山車が出てこないので繰り返し投稿する人が増え、それがさらに詰まりを悪化させました。遅延が投稿を呼び、投稿が遅延を生む状態です。
次回は取り込みと生成を分けてキュー化し、処理順を新しい順にし、再生回数の少ない山車を優先して出す。ここから設計し直します。
おわりに
この企画は、要件の整理から生成パイプラインの実装、運営画面、当日のオペレーションまで私と実行委員会だけで作りました。
弊社は、生成AIを組み込んだシステムの開発を得意としています。単発のプロンプトで終わらせず、
- どのモデルをどの順に並べるか（今回はVLM → 画像生成 → VLM → 動画生成）
- AIに任せる範囲と、人間が固定する制約の切り分け
- 一部が落ちても全体が止まらない構成
- 専門知識がなくても操作できる管理画面
まで含めて設計・実装します。飲食店・小売店の業務改善から、今回のようなイベント企画まで対応可能です。「AIで何かできないか」という段階のご相談も歓迎します。
最後になりましたが、写真を送ってくださった皆様、ご協力いただいたまつりの関係者の皆様、看板屋さん、ありがとうございました。次回はもっと速く、もっと動く山車をお見せします。
