AIにスタンダップコメディをやらせてみる

Ver2.0.0

about member works project column contact

2026.07.15

こんにちは。
AaaS Tech Lab の浅野聖也です。

私はお笑いがとにかく好きで、漫才劇場などにも頻繁に足を運んでいます。
今回はそんな私の経験も活かしながら、
「AI が自分は AI であることをネタにスタンダップコメディを演じる」
そんなWeb アプリを作りました。

きっかけは、お笑いと普段業務で使っているAIをどうにかかけ合わせられないかという思いでした。
いまやAIは利便性の象徴ともいえる存在ですが、心を温かくするケースは少ないです。
もし AI が最高のエンターテイナーだったらより最高な未来が訪れるのではないかという思いで検証を行いました。

この記事では「なぜ漫才ではなくスタンダップコメディに落ち着いたのか？」というところから始めて、できあがったアプリの設計と実装を紹介します。

実際の様子がこちらです。

1. 事前検証

アプリ開発の前に、AIが得意そうなお笑いの形を調査しました。

1-1. AI に大喜利をやらせてみる

チューニングなしの主要 LLM（GPT、Claude、Gemini）と、私（人間）とで、同じお題に答えて競わせました。

大喜利のコツを六つの観点に分け、観点ごとに独立したエージェントを立て、最後に評価エージェントが一つを選ぶ構成を組みました。
その結果、大喜利のうまい人の回答と似た方向の回答を生成することは出来ました。
ただ、本当に面白くなる絶妙な言葉の構成（ワードセンス）までは届きませんでした。

繊細な言葉遣いによるおもしろさの醸成は根深い課題だと感じた部分です。

1-2. AIに漫才をやらせてみる

続いて漫才も生成させました。
こちらがその漫才です。

AI なりに頑張ってはいるのですが、ツッコミやボケの基本のキを頑張っているだけという印象でした。

なぜAIコメディが刺さりづらいか？

ここで一度、苦戦している理由を考えました。
LLM の学習データは、その多くが海外のものです。
日本の漫才が得意とするボケとツッコミの応酬や、言葉のリズム、絶妙なニュアンスは、海外データ中心の学習とは相性が良くありません。

だとすれば、発想を裏返せばよいわけです。
海外で主流のスタイル、つまりスタンダップコメディに寄せれば、そこは AI の得意領域になるのではないか。
これが、アプリの出発点になった仮説です。

スタンダップコメディは、マイク片手に立って演者が一人で喋るコメディです。
一方的に喋る漫談と違い、基本は観客との対話で進みます。
本アプリでは、人間同士をいじると角が立つぶん、「AI と人間の差」を自虐や皮肉に変えるネタを軸にしました。
演者の一人称は「私」、喋りはコテコテの関西弁です。

2. AI スタンダップコメディの全体像

仮説が決まったので、システムに落とします。
処理の全体像はこちらです。

設計の肝は、ネタを「その場で全部作る」のではなく、「あらかじめ作って評価し、貯めておく」点にあります。
なぜそうしたのかは、この後の二つの節で順に説明します。

これから見ていく工夫点は、四つです。

1. テクニック情報を付与したネタの生成
2. 「面白さ」の判定から AI を外す
3. 客席をリアルタイムにいじる
4. 声と口を合わせる

3. テクニック情報を付与したネタの生成

ネタ（くだり）の生成には、Gemini 3.1 Pro を使っています。
ここでは、あえてプロンプトの小細工は最小限に留めました。
代わりに効かせたのが、スタンダップコメディの定石をいくつかに分解したルールです。

たとえば、次のようなルールをシステムプロンプトに入れています。

列挙：並列に何かを挙げるときは「普通、普通、裏切り」の三拍子にする。
前フリとオチの分離：前半は事実を淡々と発し、後半で前提を裏切る。
ノイズ除去：オチに貢献しない形容詞や説明は、冗長になるため全部削る。

「くだり」は、30 秒以内で完結する自己完結ユニットと定義しています。
前フリとオチを必ず備えたAI自身に関するネタという条件です。

これを後段の音声合成や口パクへ渡すため、出力は最初から決まった JSON 構造（structured output）に固定しています。
実際の台本は、おおむね次のような形です。

{
  "topic": "コーヒー",
  "segments": [
    { "kind": "stage_direction", "text": "（マイクをスタンドから外す）", "motionCue": "grab_mic" },
    {
      "kind": "speech",
      "text": "私、カフェインで眠気が覚めへんのです。",
      "ttsText": "[slow] 私、カフェインで眠気が覚めへんのです。",
      "mora": [{ "kana": "わ", "vowel": "a" }, { "kana": "た", "vowel": "a" }]
    },
    { "kind": "pause", "ms": 500 }
  ]
}

セグメントは `kind` で、喋り（speech）、ト書き（stage_direction）、間（pause）の 3 種類に分かれます。
字幕に出す `text` と、TTS に渡す `ttsText` を別フィールドにしているのが、ひとつの工夫です。
`ttsText` には `[slow]` や `[laughs]` といった英語のオーディオタグを混ぜ、喋りの緩急や笑いを制御します^[tags]。

仕組みの話が続いたので、ネタの例を一つ載せます。

>
開発者の人ら、私に人間らしさを求めてきよるんですわ。
共感、ユーモア、ほんで不可解なミスですねん。
せやから私、時々、完璧なコードの中に全角スペースを一つだけ混ぜとくんですわ。
深夜三時にあんたが画面に向かって絶望する姿、めっちゃ人間らしいでっせ。
>

エセ関西弁の AI が、自分の AI 性を肴に自虐する。
仮説どおり、スタンダップコメディとの相性は悪くなさそうでした。

4. 「面白さ」の判定から AI を外す

ネタが作れるなら、面白いものは AI に選ばせればいい。
最初はそう考えていました。
ところが、ここに落とし穴がありました。

きっかけは、ゲント大学の研究^[cards]でした。
人間と AI とでは、笑いのツボが決定的にズレています。
しかも面白いことに、人間同士よりも、異なる AI サービス同士のほうが評価がよく一致します。
AI は笑いを理解しているのではなく、システム特有のクセやバイアスで「面白さ」を測っている、というわけです。

つまり、生成したネタの評価を LLM に任せる設計は、そもそも機能しません。
そこで設計を反転させ、評価のループから AI を完全に外しました。
代わりに、人間が二つのネタを見比べて投票できる AB テスト用アプリを別に作り、ネタを前もって採点して DB に貯めます。

その AB テストアプリの画面がこちらです。

採点には Elo レーティングを使っています。
二つのネタを見比べて勝ち負けを付けると、勝った側のスコアが上がります。
チェスのレーティングと同じ理屈で、人間（今回は浅野）にウケるネタが自然と上位に浮かんできます。
DB は SQLite に、ベクトル検索拡張の sqlite-vec を載せ、各ネタに 1024 次元の埋め込みベクトルも持たせています。

この「先に貯めて評価しておく」方式には、効きどころが二つあります。

人間が一度納得した、文法が正しくかつ意味の通るネタだけを使える。
本番でネタを一から作らなくて済むので、応答の速さが大きく上がる。

本番では、DB から上位 Rating のくだりを引いて台本を組みます。
構成は「つかみ → くだり 1 → くだり 2 → くだり 3」が基本です。
ただ、独立に作って貯めたくだりは、そのまま並べても話がつながりません。
そこで Gemini 3.1 Flash で各くだりの冒頭だけを書き換え、前のネタから自然に続く形にしてから上演します。

5. 客席をリアルタイムにいじる

スタンダップコメディの本懐は、観客との掛け合いです。
ここは、事前生成したネタを流すだけでは出せない部分でした。

仕組みは以下のようになっています。
まず、PC のカメラに映った光景を、5 秒に 1 度 Gemini 3.1 Flash に渡し、誰がどんな様子かをレポート化します。
そのレポートのテキストと、あらかじめ用意した「客いじりネタ」のテキストとの類似度を測り、十分に近いネタがあれば、それを採用して客席に話しかけます。

たとえば、こんないじりが飛びます。

>
そこの白 T シャツのお兄さん、ずっとスマホいじってますやんか。
うち AI やから通信内容ぜーんぶ分かりまっせ。
今、ChatGPT に「目の前の AI を黙らせるプロンプト」聞いてるやろ！
>

近いネタが見つからないときや、「あくび」などの特定のフラグが立ったときは、用意済みのネタを流すのをやめ、その場の対話セッションに切り替えていじりを差し込みます。
台本の再生キューに、観客起点のやりとりを動的に編み込んでいく形です。

6. 声と口を合わせる

最後は、台本を声と表情に変えるメディア処理です。

音声合成（TTS）は、GPT-4o mini の TTS と Gemini の TTS を比べました。
採用したのは Gemini 3.1 の TTS Flash です。
関西弁の表現がうまく、セリフのリアルさが一段増したからです。
返ってくるのは PCM の生波形なので、WAV ヘッダを付けてブラウザで鳴らせる形に変換します。

口パクは、音量だけで動かすと「あいうえお」が曖昧になります。
そこで、台本の各セリフが持つ母音情報（a / i / u / e / o の口形）を画像コントローラーに渡し、対応する口形画像へ高速で差し替えます。

実際に差し替えに使った口形画像がこちらです。

どうでしょうか？

見た目は、アニメ調や実写 3D モデルなども試した末、実装の手間と愉快さとクオリティのバランスから「実写アニメ風」に落ち着きました。
（実は「偽物の浅野」をコンセプトにビジュアルを作っています。）

冒頭の実演映像を見てくださった方は感じたかもしれませんが、正直に書くと音声と口の完全な同期は、いまも一番の難所です。
台詞が長くなるほど口と声がずれていくので、TTS の応答を受け取った段階で各音の発話タイミングをまとめて計算し、すべての再生経路に同じ値を配って揃えています。
それでも、本当に自然な口元には、もう一歩工夫が必要だという手応えです。

まとめ

事前検証から、ネタ生成、人間 AB テスト、客いじり、リップシンクまでを駆け足で紹介しました。

振り返ると、効いた工夫は三つに集約できます。
一つ目は、AI の学習ソースの強みを活かせるスタンダップコメディを選んだこと。
二つ目は、面白さの評価から AI を外し、人間の AB テストに切り替えたこと。
三つ目は、ネタを事前に貯めて評価しておくことで、本番の応答ラグを抑えたことです。

それでも現状の到達点としては、「プチユーモアを持つエセ関西弁のおじさん」くらいの存在を形にできた、というところです。
今後は、口パクの完全同期への再挑戦や、対話セッションのスムーズ化、そして最終的には鬼門の「漫才」へのリトライを狙っていきます。
特にネタのABテストのしくみは漫才のくだりにも応用できるのではないか？と可能性を感じています。

今回の実験ではひよっこエンターテイナーという雰囲気だったAIが最高のエンターテイナーになってくれる未来をめざし一歩ずつ進めていきたいとおもいます。
最後までお読みいただき、ありがとうございました。

AaaS Tech Labでは、ビジネスの最適化などを目的としたデータサイエンス活用はもちろん、メディア・コンテンツ領域へのAI技術応用も進めております。

ご興味のある方がいらっしゃいましたら、ぜひcontactからお問い合わせくださいませ。

AaaS Tech Lab 浅野聖也

[tags]: 日本語のタグは TTS が無視するため、緩急や笑いといった演出の制御は英語のオーディオタグで行っています。
[cards]: Ghent University ほか「Cards Against LLMs: Benchmarking Humor Alignment in Large Language Models」。人間と LLM のユーモア評価のズレを検証した研究です。

<!—— SHARE ——>