builders.flash

5人の AI 審査員が議論して優勝者を決める ! AWS Summit Japan 2026 Builders' Fair「大喜利 Dojo」の裏側

2026-09-02 | Author : 早川康平, 澤亮太, 千木良勇貴, 川島拓海

はじめに

AWS Summit Japan 2026 にご来場いただいた皆さま、ありがとうございました ! 本記事では、AWS Summit Japan 2026 にて出展していました、Builders' Fair ブース「大喜利 Dojo 2026」の技術的な裏側をご紹介します。

大喜利 Dojo は、来場者と AWS メンバー、生成 AI が大喜利バトルを繰り広げるインタラクティブな展示です。出されたお題に対して、参加者がそれぞれフリップボードに回答を書いて発表します。回答は 5 人の個性派 AI 審査員がリアルタイムに採点し、審査員同士が議論して優勝者を決めます。つまり、AI に刺さる回答を出せるかどうかが勝負の決め手となるわけです。自分の出した大喜利の回答が AI に審査してもらえるという、楽しみながら AI エージェントの挙動を学べるブースです。

本記事では、大喜利 Dojo の体験、内部のアーキテクチャ設計、開発方法について順番に紹介します。

X ポスト » | Facebook シェア » | はてブ »

ご注意

本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。

*ハンズオン記事およびソースコードにおける免責事項 »

builders.flash メールメンバー登録

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

今すぐ登録 »

大喜利 Dojo とは ?

大喜利 Dojo は、以下の流れで進む対戦型の大喜利アプリケーションです。AWS Summit Japan 2026 では、1 回あたり最大 5 人の参加者が、その場でフリップボードに回答を書いて対戦しました。

参加者募集 : 来場者＋ AWS メンバー＋生成 AI (GPT-5.5 / Claude Opus 4.8 / Claude Haiku 4.5 から選択)
お題発表 : 事前に用意したプリセットお題 (60 題) からランダムまたは選択で出題
回答 : 参加者がフリップにお題を書いたものをカメラで読み込んで AI で認識
採点 : 大喜利の回答ごとに 5 人の AI 審査員がそれぞれの評価軸で採点 + 会場の盛り上がりをカメラで取得
議論 : 審査員が 3 ラウンドの議論を行い、推しを変えながら優勝者を決定
クライマックス : 4 ステージの演出で結果発表 (イントロ → 優勝発表 → 議論ログ振り返り → 投票変遷の再生)

ゲームの流れ

ここでは、会場の大画面の様子をお見せしながら、ゲームがどのように進むのかを説明します。なお、後で説明しますが、このアプリケーションには二つの画面があり、一つがここにお見せする大画面、もう一つが管理者用の画面です。出場者の登録やゲームの進行は人間の MC が管理者画面から制御しており、参加者にはこの大画面のみが表示されています。

まず最初は出場者のエントリーです。下の画面では、人間のプレイヤーが 4 人集まり、そこに AI の回答者が加わりました。AI の回答者は複数の候補から選べますが、今回は Claude Opus 4.8 が参戦しています。

続いてお題の発表です。このお題を見て、参加者は回答を考えます。回答は思いついた参加者が挙手して発表していく方式です。フリップボードに書いて見せると、カメラから自分の書いた文字が認識されて投稿されるようになっています。画面の下方では、AI の審査員が回答の投稿を待っています。

回答すると、審査員たちがコメントしてくれます。右下にいる「まわし亭司会」の振りで、審査員たちが順番に感想を言ってくれます。画面が赤く光ると、高評価の証です ! さらに、右から 2 番目、「リアル会場」の部分では、カメラで撮影した実際の会場の観客の反応が追加点として加算されます。

全員の回答が出揃うと、いよいよ優勝者を決めます。審査員は既にすべての回答の評価をしているので、それぞれの推しの参加者がいます。しかし、その推しをそのまま発表するわけではありません。まずは審査員同士で議論して、お互いの推しやその理由を話し合います。これによって、審査員の意見が変わることも多々あります。なお、「議論をみる」ボタンでは、議論の様子をこっそり覗くこともできます。

議論が終了すると、優勝者が発表されます。今回は全会一致で「かわしま」が優勝となりましたが、投票が分かれることもよくあります。

終了後に確認できる画面

終了後に、審査員の心情の変化の移り変わりや議論の様子を見ることもできます。優勝できなくても、ラウンドごとの心情の変化を見ると「最初は私が推されていたんだな」「この人は私に投票しなかったけどちょっと評価してくれていたんだな」と分かることもあります。今回は、ずっと「かわしま」が全員の推しだったので、全会一致のまま議論が進みました。

アーキテクチャ概要

全体構成

アーキテクチャは下図のようになっています。アプリケーションのサーバーサイドのロジックは AWS Fargate 上にデプロイされています。AI は大きく分けて 4 箇所で使われています。

第一に、AI 回答者には Amazon Bedrock 上の Claude Opus 4.8 を使っています。第二に、フリップボードに書かれた回答についても、同様に Amazon Bedrock 上の Claude Opus 4.8 で文字認識しています。第三に、AI 審査員には Amazon Bedrock AgentCore を使っており、審査員ごとに個別のエージェントを立ち上げています。第四に、採点時の会場の観客の反応の取得にはカメラを利用しています。これら四つの仕組みについては、後段でそれぞれ詳しく説明します。

一方で、フロントエンドには二つの画面があります。一つは参加者が見られる会場の大画面に表示するもので、先ほどのゲームの流れの説明において表示していたものがこちらです。もう一つは運営 PC 用の操作盤で、セッションの全進行を制御します。一例として、会場の状況に合わせた下記のような操作が手動でできるようになっています。

出場者登録 (ゲスト / AWS メンバー / AI モデル選択)
ゲーム進行 (受付開始 → バトル開始 → 議論開始 → 結果発表 → 終了)
お題出題（ランダムで選択)
AI 回答者による回答生成
AI が認識した回答を確認して投稿

構成図

100 %

使用した AWS サービス

サービス	用途
Amazon CloudFront	CDN。静的アセット配信 + ALB へのルーティング
Amazon S3	静的ファイルホスティング
Amazon ECS (Fargate)	コンテナでバックエンド実行
Application Load Balancer	HTTP/WebSocket のルーティング
Amazon DynamoDB	ゲームデータ永続化
Amazon Bedrock	AI 回答生成・OCR
Amazon Bedrock AgentCore	AI 審査員がそれぞれ独立したエージェントとして挙動
AWS CDK	インフラ構成

ここからは、特にピックアップするべきモジュールとして、生成 AI を利用している 4 つのモジュールについて説明します。特に AI 審査員はこの展示の肝となる仕組みです。

AI 回答者

来場者だけでなく、AI も出場者として大喜利に参加できます。GPT-5.5、Claude Opus 4.8、Claude Haiku 4.5 の 3 種類のモデルから選べます。「大喜利やお笑いの何たるか」「面白いとは何か」ということは AI が分かっているので、詳しい説明はしていません。下記が実際のプロンプトですが、これだけのシンプルな内容でも、実際に参加していた方が舌を巻くような回答が多く出ました。

json

あなたは大喜利の達人プレイヤーです。次のお題に、観客がどっと沸く面白い回答を1つだけ返してください。
  お題:「{topic_text}」
  
  ルール:
  - 回答は 1 つだけ。日本語。最大50文字程度。
  - 前置き・説明・かぎ括弧・絵文字・番号は付けず、回答の本文だけを書く。
  - 機転が効いていて、短く、笑えるもの。

AI 文字認識

人間の回答者が回答する場合、回答者はフリップボードに答えを書いて出します。そのタイミングで MC は管理者画面上のボタンを押し、カメラで取得した画像を Amazon Bedrock に送っています。

文字認識に利用しているモデルは、Amazon Bedrock の Claude Opus 4.8 です。精度は十分で、そこまで綺麗な文字でなくても正しく認識してくれます。また、大喜利では変な言い回しや存在しない言葉が答えになることもあるため、「補完はせずに書かれた文字をそのまま読み取る」ことをプロンプトで伝えました。この副作用として、二重線で消して書き直した場合などに消したものが読み込まれる場合もあったため、その点は注意が必要です。また、今回は文字認識だけに特化したため、イラストによる回答はできない仕様としましたが、文章中のハートマークなどの記号は読み込んでくれる場面がありました。

AI 審査員

5 人のペルソナ

審査員はそれぞれが個別のエージェントで動いています。これにより、審査中はお互いの考えに影響されないと同時に、議論フェーズではお互いに情報交換して認識をすり合わせられるようになります。そして大喜利の審査を盛り上げるため、5 人の AI 審査員それぞれに独自の評価軸とキャラクターを設定しています。審査員ごとの評価軸やキャラクターはプロンプトで設定しています。一方で、大喜利に対する一般的な価値観は生成 AI (Claude Opus 4.8) ならある程度理解しているため、「そもそも面白いとは何か」などをプロンプトで細かくインプットする必要はありません。下記は審査員ごとの評価軸・役割です。

審査員	評価軸	役割
🎤 まわし亭司会	場の盛り上げ・全体バランス	司会進行・議論の交通整理
🔥 辛口キング	切れ味・攻めの姿勢	厳しめの評価厳しめの評価
🤣 ダジャレ番長	言葉遊び・ダジャレ・韻	言葉のセンスを重視
🧠 ロジカル先生	論理性・構造・意外性	知的な評価
💖 ハート審査員	共感・心に刺さる・あたたかさ	情緒面を評価

実際のプロンプト

実際は下記のようなテンプレートのプロンプトを作成し、審査員ごとに中身を埋めています。特に審査員ごとの特徴を決めるのは、性格と評価軸です。例えば、「まわし亭司会」の場合、性格は「陽気で親しみやすい司会。話を振り、まとめ、笑いを誘う。基本ポジティブ」として、評価軸は「場の盛り上げ・全体バランス・交通整理」としています。なお、difficulty_instruction により、採点の厳しさをあらかじめ指定できるようにもしています。管理者画面では評価難易度を設定できるスライダーがあり、事前の審査員の調整を人間の手で簡単にできるようにしています。

json

あなたは大喜利の審査員「{persona_name}」です。
  
  # あなたの性格
  {tone}
  
  # あなたの評価軸
  {evaluation_axis}
  
  # お題
  {topic_text}
  
  # 回答
  {answer_text}
  
  # 評価難易度
  {difficulty_instruction}
  
  # 指示
  以下のJSON形式で回答してください。他のテキストは不要です。
  {"score": 0〜100の整数, "reason": "採点理由（1〜2文）", "comment": "点数を含まない短いコメント（1文、あなたの口調で）"}

採点と議論の仕組み

回答ごとの評価は、それぞれの審査員が独自の基準でスコアを出します。一方、参加者に表示されるのは点数ではなく、コメントと UI 上の審査席の発光で評価の高さが可視化されます。そして、全ての回答が出揃うと、それぞれの審査員が誰に票を入れるかを決めますが、この時点ではまだ投票は行われません。ここで審査員同士が議論して、場合によっては他の人の意見を参考に自分の投票先を変更します。

なお、審査員は全部で 3 周分議論を行い、発言順はラウンドごとにランダムにシャッフルされます。この間に審査員の投票先が変更されることはよくあります。

会場で何度も審査を見守ってきた体感として、「まわし亭司会」は議論のバランスを見て投票先を変更せず、優勝者以外に自分だけ票を入れることが多々ありました。優勝者だけでなく 2 位にも気を遣ってくれる大人な審査員と言えるでしょう。

AI による盛り上がり取得

回答が出されたタイミングで、会場のカメラに写っている他の参加者や観客がどの程度笑っているかを基準に盛り上がりを取得しています。このシステムのみ、来場者の顔をカメラ画像で撮影することになるので、プライバシー保護のためクラウドには送っていません。その代わりに、エッジで動く軽量な AI モデルで表情認識しています。なお、カメラに複数人写っている場合は、写っている人全員の表情を取得します。

開発方法

開発時には、上記すべての仕組みを高速に作るため、 AI-DLC Workflows を使いました。2026 年 8 月現在は v2 も一般利用開始されていますが、開発当時には v1 を利用しています。開発者は 4 人の技術職メンバーで、全員が同じ部屋に集まって「何を作るか」を決める inception フェーズからモブワークの開発を始めました。内部ロジックは論理的に 8 つのユニットに分離しつつも、運用のシンプルさのために、デプロイは 1 つの Fargate タスクに同居させるモジュラーモノリス構成を採用しています。

Unit	名称	責務
U-01	Stage Monitor	会場大画面 UI (静的 JS、S3+CloudFront 配信)
U-02	Admin Bundle	運営コンソール画面
U-03	Session Flow	セッション進行・Phase 状態機械・タイマー
U-04	Topic Service	お題管理
U-05	Answer Service	回答の受付・公開・AI 回答生成
U-06	Judge Service	5 人の AI 審査員：採点・コメント・議論・投票
U-07	Data Layer	DynamoDB 永続化
U-08	Realtime Notification	WebSocket イベント配信

AI-DLC Workflows »

まとめ

大喜利 Dojo 2026 は、「AI 審査員が議論して優勝者を決める」という仕組みで、AI を学びながら楽しめる展示です。会場には初めて大喜利をするという方も多くいらっしゃいました。始めるには敷居が高い大喜利も、AI が審査してくれるとなると少し試してみる勇気が湧いてくるかもしれません。

よかったら、皆様も是非、AI を相手に大喜利をしてみてください。本記事が、皆様の開発の参考になれば幸いです。

筆者プロフィール

早川康平

アマゾンウェブサービスジャパン合同会社
カスタマーソリューションズマネージャー

金融勘定系システムの PM、Web エンジニア、SaaS プロダクトマネージャー、ソリューションアーキテクトを経て現職。幅広い経験を活かし、大手製造業専任の CSM として、SaaS アプリケーション開発や AI 活用を含むクラウド活用と開発プロセスの変革を支援している。宮城県仙台市出身。お笑い芸人。

澤亮太

アマゾンウェブサービスジャパン合同会社
ソリューションアーキテクト

製造業のお客様を担当。前職では AI、機械学習開発へ従事し、現在も最新技術の導入・活用に悩む企業様への技術支援を行う。最近はゴルフ熱が再燃し、コースに立つとアーキテクチャより打数が気になる。そんなお笑い芸人である。

千木良勇貴

アマゾンウェブサービスジャパン合同会社
テクニカルアカウントマネージャー

金融業界のお客様を中心に支援をしている TAM (Technical Account Manager) です。メインクーンという猫を飼っており、毎日癒されています。
今年も M-1 グランプリ挑戦します。

川島拓海

アマゾンウェブサービスジャパン合同会社
ソリューションアーキテクト

ゲーム業界のお客様を中心に支援している Solutions Architect です。食べることが大好きです。休日は趣味としてお笑いをやっていますが、このことは秘密にしておいてください。

5人の AI 審査員が議論して優勝者を決める ! AWS Summit Japan 2026 Builders' Fair「大喜利 Dojo」の裏側

はじめに

ご注意

builders.flash メールメンバー登録

大喜利 Dojo とは ?

ゲームの流れ

終了後に確認できる画面

アーキテクチャ概要

全体構成

構成図

使用した AWS サービス

AI 回答者

AI 文字認識

AI 審査員

5 人のペルソナ

実際のプロンプト

採点と議論の仕組み

AI による盛り上がり取得

開発方法

まとめ

筆者プロフィール

早川康平

澤亮太

千木良勇貴

川島拓海

学ぶ

リソース

デベロッパー

ヘルプ

5人の AI 審査員が議論して優勝者を決める ! AWS Summit Japan 2026 Builders' Fair「大喜利 Dojo」の裏側

はじめに

ご注意

builders.flash メールメンバー登録

大喜利 Dojo とは ?

ゲームの流れ

終了後に確認できる画面

アーキテクチャ概要

全体構成

構成図

使用した AWS サービス

AI 回答者

AI 文字認識

AI 審査員

5 人のペルソナ

実際のプロンプト

採点と議論の仕組み

AI による盛り上がり取得

開発方法

まとめ

筆者プロフィール

早川 康平

澤 亮太

千木良 勇貴

川島 拓海

学ぶ

リソース

デベロッパー

ヘルプ

早川康平

澤亮太

千木良勇貴

川島拓海