集客AI · 使い方・仕様・設計の理由
集客AI ｜ 仕組みと技術
中で何が起きているか、なぜこの作りにしたか、どれだけ時間がかかったかの記録です。 操作方法はハンドブックにあります。
2026-08-19 時点の実装にもとづきます。数値はすべて実測です。
仕組み
何が起きているか・何が残るか6. 全体は「1本の製造ライン」です
素材を入れると、下の順に流れます。止まるのは2か所だけで、あとは自動です。 途中で人が手を入れると、その先の工程は作り直しが必要になります（どの版が古いかは画面が教えます）。
7. 工程ごとの入力・処理・出力
左が「何を受け取るか」、中央が「何をするか（誰が）」、右が「何が出て、どこに残るか」です。
コード表記は保存先の名前で、打ち合わせでは読み飛ばして構いません。
受け取る
人が決める- スマホの動画 1〜15本（合計90秒まで）
- 店舗（辞書とNGワードが紐づく）
- 事実メモ（任意）
- 対象言語（ONの言語すべて）
この時点では何も処理していません（受付だけ）。
- 依頼1件（実行待ち）
jobs／倉庫 videos/uploads/…事実メモがここでの分かれ道です。 空でも作れますが、その場合AIは映像から見て取れることしか書けません。 味・創業・こだわり・受賞歴は根拠が無いので書けず、画面にもその旨が出ます。
解析（AIが動画を見る）
機械- 連結前の動画
- 解析の型
analyze@v2
- 文字起こし／要約
- 日本語の下書き
- 字幕A の候補
裏取り（事実の確認）
機械止まることがある- 文字起こし・事実メモ
- 店舗の辞書
- 発話の量（この後の音の扱いを決める）
- 根拠あり／なし／取り違え
取り違えを見つけたら、ここでジョブを止めます。 実例＝別の店舗（鰻店）の解析が混じったとき、「この動画には店名もメニューも出てきません」と出して停止しました（2026-08-13）。
構成（どの画をどの順で使うか）
機械が下書き人が決める- 素材ごとの静止画と長さ
- 構成（並び・取捨・冒頭の狙い）
- 足りない画の指摘
jobs.plan_json連結（映像を1本にする）
機械止まることがある- 確定した構成
- 素材の動画
- 1本になった映像
- 時間割＝何番目の素材が何秒〜何秒に映るか
plan_json.built.timeline横向きの素材は左右が切れます（中央を切り出すため）。警告は出ますが止めません。 この「時間割」が、あとでテロップを画に合わせる土台になります。
文章（投稿文・字幕A・ハッシュタグ）
機械後から直せる- 解析の結果
- 店舗の辞書・NGワード
- 事実メモ
- 投稿キャプション
- 字幕A＝元の声に付ける字幕
- ハッシュタグ（3個以上）
outputs.caption_text / subtitle_srt / hashtags_json読み上げ原稿（字幕B）
機械後から直せる- 解析の結果
- 動画の長さ
- 言語ごとの読む速さ
- 読み上げ原稿
- 字幕B＝新しい声に付ける字幕
outputs.narration_text / narration_srt字幕が2種類あるのはこのためです。 元の声のまま出すなら字幕A、声を差し替えた動画なら字幕B。取り違えると声と字幕が食い違います。
声にする
機械声を選ぶ・肉声を使う- 読み上げ原稿
- 声（5種から選択）
- または、録った肉声
肉声を使う場合は前後の無音を落とし・音量をそろえ・動画の長さに合わせてから載せます。
- 音声ファイル（言語ごと）
- 実測の秒数
audio/<依頼>/<言語>.wav映像に音を重ねる
機械- 連結した映像
- 作った音声
- 元動画に入っている音
このとき元の音をどれだけ残すかが自動で決まります（次の章で詳しく）。
- 音声付き動画（言語ごとに1本）
renders/<依頼>/<言語>.mp4テロップ（画面に出す文字）
機械人が直せる- 映像の時間割（05で作ったもの）
- 素材ごとに何が映っているか
- 辞書・NGワード
- テロップ（文言・時間・出る画・見た目）
outputs.telop_json人が直せるのはここが一番多い所です。 文言・表示時間・出る画・色・背景・位置（つまんで動かす）・大きさ・縦書き。 直した内容は作り直しても消えません。
焼き込み／BGM
押したときだけ- 音声付き動画
- 確定したテロップ
- 曲調の指示（任意）
BGMはAIが曲を作って重ねます。元の版は消さずに残すので、やり直せます。
- テロップ入り動画
- BGM入り動画
renders/…_telop.mp4 / …_bgm.mp4出す前の確認
機械最後は人が決める- 出力の一式
- 映像の時間割
- 合格／要確認／要修正
- 打つ手（どのボタンを押すか）
outputs.quality_json赤が出ても処理は止めません。 文章も音声も出来ているので捨てるのは損で、人が見て決めるほうが安いためです。 ただし赤のまま公開しないでください。
8. 元動画に入っている音は、いまどう扱われるか
ご質問の点です。いまは自動で決まり、選べません。判定の分かれ道は「元動画に人の声があるか」の1つだけです。
そのため、いまはこうなります
歌・演奏・お客様の声など「その場の音が主役」の動画でも、消えます。 実例＝8/13にお作りいただいた「経営者パーティー」（ステージの歌が入った22秒）は、 歌が発話と判定されて完全に消え、英語ナレーションに置き換わりました（実測で確認済み）。
回避する道がいまはありません。 元の音の量を画面から変えることも、ナレーション無しで文字だけ焼くことも、 連結後の映像だけを取り出すこともできません。
9. 実際に3つ作って比べました
お預かりしている「経営者パーティー」の素材（22秒・ステージの歌入り）で、同じ映像・同じ文字のまま音だけを変えて試作しました。 データは書き換えていません。どれも既にある部品だけで作れています。
| 版 | 元の歌 | ナレーション | 画面の文字 | 状態 |
|---|---|---|---|---|
| A いまの出力 | 消える（0倍） | あり（英語・AIの声） | まだ焼いていない | いま自動でこうなります |
| B 元の音を残す | そのまま（1.0倍） | あり（重なって鳴る） | まだ焼いていない | 試作OK。ただし歌と声が同時に鳴ります |
| C 元の音のまま文字だけ | そのまま（ステレオのまま） | 載せない | 9枚を焼き込み済み | 試作OK。歌が主役の動画はこの形 |
試作して分かったこと
C は、いまある部品だけでそのまま作れました。 焼き込みの処理は「どの動画に文字を焼くか」を受け取る作りなので、 声を重ねる前の映像を渡せば、元の音のまま文字だけが乗ります（実測22.29秒・元の音はステレオのまま）。
足りないのは画面にその選択肢が無いことだけです。
足すとしたら、この3つ
- 元の音を消す／小さく残す／そのままを画面で選ぶ
- ナレーションを載せないを選べるようにする（＝C の形）
- 元の音とナレーションの音量バランス
いずれも工程09の1か所です。先に決めていただきたいのは「この店舗ではどれを既定にするか」で、 店舗ごとに持たせれば毎回選ばずに済みます。
いま（実装前）に元の音を活かすなら
この仕組みを通さず、お手元の素材をそのまま投稿することになります。 その際は字幕A（元の声に付ける字幕・多言語）をダウンロードしてお使いいただけます。 ただし構成・テロップ・BGMは付きません。
10. 出てくる4つの版と、その依存関係
成果物は別々のファイルとして併存します。上書きしないので、いつでも前の版に戻れます。 ただし後ろの版は前の版から作るので、前を直したら後ろは作り直しが必要です。
11. データはどこに、どう残っているか
帳簿（表）は4つだけ、倉庫（ファイル置き場）は3つだけです。 言語や型はコードに書かず、表の行として持っていますので、言語を増やすときはプログラムを触りません。
| 置き場 | 何が入っているか | 1件の単位 |
|---|---|---|
| shops（店舗） | 店名／固有名詞の辞書（表記・読み・訳・出典）／使ってはいけない言葉／テロップの型 | 店舗1つ |
| languages（言語） | 言語コード・表示名・ON/OFF・基準言語か・字幕の最大字数・声・読む速さ | 言語1つ |
| jobs（依頼） | 素材の場所／状態／事実メモ／構成と時間割／所要時間／API回数／費用 | 依頼1件 |
| outputs（出力） | 投稿文・字幕A・字幕B・ハッシュタグ・読み上げ原稿・テロップ・音声と動画の場所・品質判定・来歴 | 依頼×言語 |
videos（倉庫） | お預かりした素材と、連結した映像 | ファイル |
audio（倉庫） | 作った音声・録っていただいた肉声 | ファイル |
renders（倉庫） | 音声付き動画・テロップ入り・BGM入り | ファイル |
来歴（あとから辿れること）
1件ごとにどの素材・どの型（版つき）・いつ・何回APIを呼んだかを残しています。 「なぜこの文になったか」を後から説明できます。
人が直した所は上書きしません
テロップ・投稿文・原稿など人が手を入れたものは、作り直しても消えません。 ただし時間と並びだけは映像に合わせ直します（何枚動かしたかを画面に出します）。
12. いまできないこと（聞かれる前に）
実装から確認できている範囲で、正直に並べます。
| できないこと | いまの状態 |
|---|---|
| 元動画の音を活かす | 人の声・歌があると自動で消えます。選べません。ただし試作では作れました（3-2章） |
| ナレーション無しの動画 | 4つの版すべてが声を載せる前提です。試作では作れました（3-2章のC） |
| 音の大きさ | 実測 -26.5 LUFS。SNSの目安（-14前後）より12dB以上小さいです。次に直します |
| ナレーション中にBGMを下げる | 喋っている間も同じ音量で鳴ります |
| 表紙（カバー）の指定 | 先頭のコマ任せです |
| カットを音楽に合わせる | カットの長さは素材都合で決まり、BGMは最後に載せるだけです |
| 横向き素材 | 左右が切れます（縦での撮影をお願いしています） |
| 文言が画に合っているか | どの画に出すかは機械が確かめますが、言葉と映像の中身が合っているかは人が見ます |
なぜこう作ったか
技術の選定理由と、かかった時間13. 全体の方針 — 先に決めた4つ
個々の技術より先に、この4つを決めてから部品を選びました。 どれも「あとで変えられるようにする」ための決めごとです。
① 質より先に、導管を通す
最初にやったのは「動画1本を入れて、全言語のテキストが出る」を1回通すことだけです。 質を上げる工夫は後回しにしました。
なぜ＝通してみないと、どこが本当の詰まりかが分からないためです。実際、詰まったのは 生成の質ではなく音の扱い・文字と画の対応でした。先に質を作り込んでいたら、そこは触れていません。
② 変わるものはデータで持つ
言語・プロンプト・声・テロップの型・辞書は、コードに書かず表の行として持ちます。
なぜ＝言語を1つ増やすのに開発が要る作りだと、増やすたびに費用と時間がかかるためです。 いまは表に1行足すだけで、プログラムは触りません。
③ 鍵はブラウザに出さない
AIの鍵を持つのは実行サーバだけ。画面にできるのは「依頼を出す」「結果を読む」だけです。
なぜ＝ブラウザの中身は誰でも見られます。鍵を置くと、リンクを知った第三者がAIを使い放題になり、 請求だけがこちらに来ます。1日の実行本数にも上限を付けています。
④ 人が直せる口を最初から通す
自動で出したものを、そのまま公開しない作りにしました。あとから足すのではなく、最初から通してあります。
なぜ＝生成物は必ず外します。外したときに直せないと、作り直すしかない＝そのぶん費用と時間がかかるためです。
14. 技術スタックと、選んだ理由
各カードは「何のために・なぜそれか・代わりに何を見送ったか」の3点セットです。 見送った案も残してあるので、前提が変われば戻せます。
Supabase
動画の倉庫＋作業の帳簿（PostgreSQL）- 数百MBの動画を預かる置き場
- 進捗と結果を書く台帳（4つの表）
- 画面と実行サーバが同じものを見るための共通の置き場
管理も請求も3つに増え、つなぎ込みの手間も3倍になります。
選んだ理由＝倉庫・帳簿・権限が最初から1つに揃っていること。 加えて、処理に数分かかるので途中経過を書く場所が必須でした。画面を閉じても処理が続き、 あとで開くと終わっているのは、進捗が帳簿に書かれているからです。
Cloudflare Workers
受付（画面を配る・合言葉・依頼の取り次ぎ）- 操作画面を配る
- 合言葉（ID・パスワード）で入口を守る
- 「実行して」の依頼を、内部だけで実行サーバへ渡す
公開URLを持つと、鍵の管理と攻撃対策を自前で背負うことになります。
選んだ理由＝実行サーバに公開URLを持たせないため。 受付を通らないと触れない形にすると、③（鍵を出さない）が構造として守られます。
Cloudflare Containers ＋ Docker
実行サーバ（AIの鍵を持つ唯一の場所）- 動画を取り出し、AIに渡し、結果を帳簿に書く
- ffmpeg を積んでおくため（音を重ねる・文字を焼く）
- 弊社のPCを不要にする
Supabase Edge Functions（Deno）はffmpeg を起動できないため、動画処理には使えません。
選んだ理由＝新規アカウントも鍵の貼り付けも要らず、既に使っている道具だけで完結すること。 コードは1行も変えずに置き場所だけ移しました（Macでもコンテナでも同じ出力になることを実測で確認）。 設定の意図＝同時に2つ動かさない（同じ依頼を二重に処理してAPI枠を倍使うため）／使わない間は寝かせる（課金を止めるため）。
Gemini（Google）
動画を見る・訳す・声にする・曲を作る- 動画をそのまま渡して内容を理解させる
- 言語ごとの翻訳と清書
- 読み上げ音声（5種の声）
- BGMの生成
（動画解析＋翻訳＋音声合成＋音楽生成＝契約4つ・鍵4つ・請求4つ）
選んだ理由＝この4役を1つの鍵で賄えること。 特に「動画をそのまま渡して理解させられる」点が大きく、音声を書き起こしてから解析する2段構えが要りません。 差し替えは想定しています＝プロンプトは外部ファイル、言語は表の行なので、 別のAIに替えても土台（倉庫・帳簿・工場・受付）は作り直しになりません。
ffmpeg
映像と音の加工（重ねる・繋ぐ・焼く）- 素材を縦9:16に揃えて繋ぐ
- ナレーションを映像に重ねる
- テロップを映像に焼き込む
1本ごとに費用がかかり、細かい制御（元音の量・文字の位置）が効きません。
選んだ理由＝これ以外に現実的な手段が無いため。 工夫として映像は作り直さず、音のトラックだけ差し替えます。 小さい箱（1/4 vCPU）でも実時間の何分の一かで終わり、画質も落ちません。
React ＋ Vite（既存モックの流用）
操作画面- アップロード・実行の依頼・進捗表示・結果の編集
先にお見せしたモックがあり、作り直すと同じ画面をもう一度作ることになります。
選んだ理由＝既にあるものを流用し、足したのは4つのやり取りだけ （アップロード／実行の依頼／進捗の表示／結果の表示）。 画面を描き直さないと決めたことで、P1の作業を土台づくりに集中できました。
依存ライブラリを増やさない
方針（技術そのものではない）- 資料のMarkdown変換・時間の割り当て・検査などは自前の短いコードで書く
動く範囲は広がりますが、更新・脆弱性・仕様変更を抱え込みます。
選んだ理由＝後から読む人の負担。 使う機能が限られている所にライブラリを入れると、読む対象が増えるだけです。 いま本体が使っている外部の部品は4つだけです（AI・Supabase・React・アイコン）。
15. 途中で変えた判断（変えた理由つき）
やってみて分かったことで、方針を変えた所です。変えた事実と理由を残しておくと、 同じ議論を二度しなくて済みます。
| 日付 | 変えたこと | なぜ変えたか |
|---|---|---|
| 08-02 | 弊社PCでの実行 → クラウドへ移設 | 「こちらがPCを開いていないと御社が実行できない」形だと、御社だけで完結しません。 着手前に「誰がいつ触るか」を確認していれば避けられた手戻りです（実測1.6H） |
| 08-08 | 元の声を一律15%残す → 発話があれば消す | 元の声が残ったまま新しいナレーションが乗り、2人が別のことを喋る状態になっていました。 外国語版では日本語の声が鳴り続けて使えません |
| 08-08 | 字幕1種類 → 2種類（元の声用／差し替え用） | 「元の音のまま出す」のと「声を差し替える」のとでは、合う字幕が違います。 取り違えると聞こえる声と字幕が食い違います |
| 08-08 | 目視での確認 → 機械が12項目を判定 | 見つかった不具合がどれも「出来上がった」と保存されてから人が気づいたものでした。 基準を資料に書くだけでは同じことが起きます |
| 08-11 | 第4段階「3案から選ぶ」 → 1本を直せるようにする | 3案を出しても良いものが無ければ選べません。同じ素材から3本作るより、 1本を直すほうが速く、費用も少なくて済みます |
| 08-13 | テロップを全体の要約から作る → 画ごとに作る | 文字と映っているものが食い違っていました（チキンの文字が冷麺の画に）。 時間だけを文字数で割っていたのが原因で、画の切り替わりとは無関係でした |
| 08-14 | 元の音の扱い（これから） | 歌・演奏が主役の動画でも、いまは自動で消えます。 選べるようにする必要があります（試作では既存の部品だけで作れました） |
16. なぜこれだけの時間がかかったのか
まず数字を出します。AIと対話していた時間はログから実測できます（2026-07-19〜08-15）。
実測
AI対話 38.7 H
セッション58回 ／ 人が打った指示 179件
この数字に入っていないもの
一次情報の裏取り・生成物の目視確認・エラーの再現・外部サービスの設定と課金・テスト待ち・技術選択の判断。 8/5 までの実測では、この「外側」が 13.9H あり、AI対話（14.1H）とほぼ同じでした。
8/5以降は打刻が途切れており、正確な数字がありません（推定値は出しません）。
1） 何に使ったか（段階別・実測）
いちばん大きいのは「運用に載せる」13.4Hで、機能を増やした時間ではありません。 弊社PCを外してクラウドへ移す・自動で復帰する・事実の裏取りを機械にやらせる・辞書を自動で作る、 といった毎回発生する人手を先に潰すための時間です。
2） 時間の正体は3つ
① AIが短縮するのは「書く時間」だけ
渡す前（何を作るか決める・素材と事実を揃える）と、受け取った後（見て・直して・確かめる）は減りません。 8/5の実測では、この外側がAI対話と同じ量ありました。
「AIなら3時間」という見立てはコードを書く時間としては正しく、実測でも 第1段階のコア実装は4.7Hでした。差が出るのは外側です。
② 指示の半分は「人が動いた結果」を渡す作業
179件の内訳です。
- 純粋な実装依頼 … 91件（51%）
- 生成物・画面を見た結果 … 29件
- 仕様・方針の判断 … 20件
- 外部サービスの設定・課金 … 19件
- エラーの報告（動かして踏んだもの） … 15件
- 事実の訂正（一次情報にもとづく） … 5件
③ 実物を作らないと分からない欠陥
下の6つはすべて「出来た」と保存されてから、人が実物を見て気づいたものです。 設計段階では見つけようがありませんでした。
- 声が二重に鳴る
- 音が尺の3割で終わる
- 字幕と声が別物
- 並べ替えが動画に反映されない
- 文字が1カットぶんずれる
- 元の音が消える（対応中）
3） 削れたはずの時間（こちらから出します）
| 何が | 実測 | どうすれば防げたか |
|---|---|---|
| 手戻り（共有リンクを作った翌日にクラウドへ作り直し） | 1.6H | 着手前に「誰が・いつ・どこから触るか」を確認する |
| API無料枠による分断（1日3本しか検証できず、修正の確認が翌日へ） | 1〜2H | 制約に気づいた日に課金する（気づいた7/31から有料化8/3まで3日空けた） |
| 資料の作り込み過多（同時期に公開資料を4種類） | 1〜2H | 実装が確定してから1本だけ作る |
この期間に何を作っていたか（規模ではなく、目的で）
コア実装以外の大半は、上の「外側13.9H」を次回から機械にやらせるための実装でした。 辞書の自動生成（一次情報からの裏取りを削る）・事実の機械検査（目視を削る）・ 失敗の自動切り分けと再試行（エラー再現を削る）・出す前の12項目判定（見落としを止める）。
店舗が増えるほど、この差は効きます。手間のかかる確認（辞書づくり）は新店1回きりで、 2本目以降の動画には自動で適用されます。
17. 聞かれたときの答え方（3行）
| 質問 | 答え |
|---|---|
| なぜこの技術か | 鍵を1つに、契約を1つに、置き場を1つに寄せるため。差し替えられる形にしてあるので、 前提が変われば土台を作り直さずに替えられます |
| なぜ時間がかかったか | AIが短縮するのは書く時間だけで、実測ではその外側が同じ量ありました。 いちばん大きい13.4Hはその外側を機械に肩代わりさせるための実装です |
| 次はもっと速くなるか | 2店舗目以降は速くなります。辞書づくりは新店1回きり、 土台（倉庫・帳簿・工場・受付）は作り済みで、増えるのは工程だけだからです |