Gemini 3 ハッカソン東京 2026 に参加して、7時間で「AI密室ミステリーゲーム」を作って提出した話

未分類

2026年の Gemini 3 ハッカソン東京 に参加してきました。
結論から言うと、入賞はできませんでした。でも、7時間の制限時間内に動くものを作って提出まで完了できたので、個人的にはかなり価値のある経験になりました。

今回作ったのは、Gemini をゲームマスター(GM)にした密室ミステリー推理ゲームです。

この記事では、当日の流れ・作ったもの・技術構成・入賞できなかった自己分析・次に改善したい点まで、現実ベースでまとめます。

ハッカソンの前提

今回のハッカソンは、単に「AIを使えばOK」ではなく、かなり明確にルールがありました。

特に重要だったのはこのあたりです。

  • 制限時間は実質 10:00〜17:00(提出締切 17:00)
  • デモで見せる機能は、ハッカソン期間中に作ったものに限る
  • 事前作成の作品をそのまま出すのはNG(DQ対象)
  • 最大4人チーム
  • 禁止テーマ例が明示されている(基本的なRAG、Streamlit、画像分析ツール、教育AIチャットボットなど)

つまり、ポイントは「AIを使った」だけではなく、短時間で、ルールに沿って、審査で伝わる形に落とし込めるかでした。

この前提を踏まえると、今回のハッカソンはかなり「プロダクト設計」と「デモ設計」の比重が高かったです。

今回作ったもの:AI密室ミステリーゲーム(Locked-Room Mystery)

今回作ったのは、AIがゲームマスターとして推理ゲームを進行するインタラクティブゲームです。READMEにもある通り、毎回異なる事件を生成して、プレイヤーが証人や証拠に質問しながら真相を推理していく構成です。

ざっくり遊び方

  1. 新しい事件を生成
  2. 事件の導入を読む
  3. 証人・証拠に質問する(最大12回)
  4. 嘘つきNPCの矛盾を見抜く
  5. 犯人・動機・手口・トリックを提出
  6. 採点とフィードバックを受ける

README上でも以下の要素が整理されていて、ハッカソン作品としての軸がわかりやすい形になっています。

  • 動的事件生成(毎回新しい事件)
  • AIゲームマスター
  • 嘘つきNPC(1人は必ず嘘をつく)
  • 質問回数制限(12回)
  • 採点(S/A/B/C)+推理の弱点フィードバック
  • 日英対応

個人的に、今回の肝は「AIチャットをゲームにした」ではなく、推理として成立する制約(回数制限・嘘つき・採点)を入れたことです。
これを入れないと、ただの会話デモで終わりやすいので工夫しました。

技術構成

リポジトリ構成と依存関係を見ると、今回の実装はかなり堅実にしました。
Frontend/Backend を分離しつつ、Docker Compose で起動できるようにしています。

フロントエンド

  • React 18
  • TypeScript
  • Vite

バックエンド

  • FastAPI
  • SQLAlchemy
  • Pydantic / pydantic-settings
  • google-genai
  • pytest

実行環境

  • Docker Compose
  • Backend / Frontend の2サービス構成
  • 環境変数で LLM プロバイダやモデルを切り替え可能

ハッカソン特有の「API不調・レイテンシ・デモ事故」への備えを強化して、事故らないようにしました。

実装してよかった点(ハッカソン目線)

1) 「動くデモ」の単位が明確だった

FastAPI 側では、ゲーム生成・質問・会話要約・推理提出・言語切替・背景画像取得など、ゲーム進行に必要なAPIが分かれていて、わかりやすい構成になっています。

例えば以下のような流れがAPIとして成立しています。

  • /api/game/new で新規事件生成
  • /api/game/{id}/ask で質問
  • /api/game/{id}/summarize で会話要約
  • /api/game/{id}/guess で推理提出

ハッカソンでは「すごい設計」よりも、2分〜3分のデモで破綻しないことが重要なので、この実装はかなり正解だったと思います。

2) フロント側のUXが“ゲーム”寄りになっている

React 側は、単なるテキスト入力だけでなく、

  • 質問テンプレート
  • サジェスト質問
  • 推理フォーム
  • 推理文の自動下書き
  • 会話サマリー表示
  • メモ保存(localStorage)
  • 日英切替

など、プレイしやすさを上げる工夫を入れました。

短時間開発でもここを入れたのは、我ながら良い判断だったと思います(笑)
審査のために、プレイヤーが遊べる形になっているかの印象を強く与えるために入れました。

7時間でやるなら、何を捨てるかが勝負だった

今回あらためて感じたのは、ハッカソンは「何を作るか」以上に、何を切るかが勝負だということです。

7時間だと、やろうと思えばいくらでも広がります。

  • キャラクター演出
  • アニメーション
  • 複雑なゲームルール
  • 高度なプロンプト最適化
  • ランキング機能
  • マルチプレイ

でも、これを全部触ると確実に間に合いません。
なので今回は、(結果的に)以下を優先したのがよかったです。

  • コア体験を先に完成
    • 事件生成 → 質問 → 推理 → 採点
  • 日英対応
  • デモしやすいUI
  • 提出可能な形(起動方法・README含む)

入賞できなかったとしても、ここを最後までやり切れたのは大きいです。
ハッカソンは「未完成の壮大な構想」より、締切時点で触れる完成物のほうが強いので。

入賞できなかった理由(自己分析)

ここは正直に書きます。
審査員から公式フィードバックを細かくもらったわけではないので、以下はあくまで自分の推測・自己分析です。

ただ、審査基準(インパクト / デモ / 創造性 / ピッチ)を踏まえると、かなり筋のいい反省点だと思っています。

1) 「面白い」から「勝てるデモ」への変換がまだ弱かった

コンセプトは面白いけど、ハッカソン審査では

  • 一目で伝わるか
  • その場で驚きがあるか
  • 競合作品と並んだ時に差が出るか

が重要です。

今回の作品は、遊ぶほど良さがわかるタイプで、短いピッチ時間だと価値が伝わり切る前に終わるリスクがあったと思います。

2) Geminiらしさの見せ方をもっと尖らせられた

「AIを使っている」だけだと、ハッカソンでは埋もれます。
特に Gemini 系ハッカソンだと、“Geminiの何を活かしたか” を強く見せたほうがよかったはずです。

今回も十分使ってはいるのですが、審査員視点で見ると、

  • 「このゲームでないと成立しないAI体験」
  • 「Geminiの能力を使った決定的なデモ瞬間」

をさらに強く演出できたのではと考えています。

3) ピッチ最適化(見せる順番)に改善余地

ハッカソンのピッチは、技術説明を丁寧にするほど不利になることがあります。

本来は、

  1. 30秒で面白さを見せる
  2. 30秒でAIの価値を示す
  3. 残りで技術・実装の堅さ
    くらいの順序が強いです。

自分はどうしても実装面まで説明したくなるので、“審査で勝つ順番” に寄せるのが次回の課題です。

それでも今回かなり良かったと思う点

とは言っても、入賞できなかった=ダメ、ではなかったです。むしろ今回の収穫は大きかったです。

1) 制限時間内に提出まで完了できた

これが一番大きいです。
ハッカソンは提出して初めて土俵に立てるので、締切内に完成品を提出する実力を示すことができました。

2) 企画・実装・デモの一連を短時間で回せた

「思いついたものをその場で形にして、動くものとして出す」経験は、普通の開発では得にくいです。
この経験値は、研究・個人開発・インターン・仕事の全部に効くと考えています。

3) リポジトリとして公開できる形に整理できた

README、起動方法、環境変数、Docker構成まで含めてまとまっているので、あとで改善を続けやすい構成です。
ハッカソン後に死蔵しない形にできたのは良かったです。

次に改善したい点(本気で伸ばすならここ)

個人的に、この作品は正直まだ伸びると確信しています。次やるなら、以下を優先します。

1) デモ映えの強化(最優先)

  • 初回事件生成の演出強化
  • キャラクター/証拠の見せ方強化
  • 「嘘つきNPCを見抜いた瞬間」の演出
  • 結果画面の納得感・気持ちよさ向上

2) 推理体験の深掘り

  • 証拠同士の関連可視化(ノート/関係図)
  • 時系列整理UI
  • プレイヤーの推理過程に応じた追加ヒント
  • 難易度選択(初心者向け / 上級者向け)

3) LLM出力の安定化

  • 構造化出力の強化
  • ケース整合性の検証
  • リトライ戦略の調整
  • 「面白さ」と「矛盾の少なさ」の両立

ハッカソン中はまず成立させるのが優先ですが、継続開発するならここが品質差になるでしょう。

ハッカソン参加を通しての学び(次回の自分向けメモ)

最後に、今回の経験からの学びを3つに絞るとこうです。

1. ハッカソンは「完成度」より「伝達設計」

技術力は大事。でも審査付きハッカソンでは、何をどう見せるかが同じくらい重要。

2. 7時間なら“1つの勝ち筋”に集中する

機能を増やすより、一番刺さる体験を確実に動かすほうが強い。

3. 入賞しなくても、提出までやり切れば次につながる

これは綺麗事じゃなく本当です。
完成・提出まで行ったプロジェクトは、改善も再利用もできます。

おわりに

今回は入賞は逃しましたが、制限時間内に提出まで完了し、AIゲームとして成立するところまで持っていけたのはかなり良い経験でした。

Gemini系のハッカソンは、単なるチャットアプリでは勝ちにくく、体験設計・デモ設計・AIの使いどころが問われる場だと実感しました。
次回はそこをさらに尖らせて、ちゃんと勝ちにいきたいです。

もし興味がある人は、リポジトリも見てみてください。
ハッカソン作品としては、今後の改善余地も含めてかなり面白い土台になったと思っています。

コメント

タイトルとURLをコピーしました