[58hack] ハッカソン・デベロッパー

https://github.com/2509-democracy/democracy-next

TypeScript

AWS

DynamoDB

繰り返すハッカソンの中で、己のアプリを創り出せ───。

yotu

zatunohito

warisuno

thirdlf03

fe01

推しアイデア

「オートチェス x ハッカソン」なところ

作った背景

このハッカソンが今週3つめのハッカソンだから

推し技術

cloudflare ベースの構成にチャレンジしているとこ

プロジェクト詳細

概要

「ハッカソン・デベロッパー」は、「オートチェス」に「ハッカソン」要素を組み合わせた、リアルタイム対戦型カードゲームです。

※オートチェス:チェスでいうところの「コマ」をショップから取り合い、同じ駒を集めたりして強化し、自由に並べて競うゲームジャンル。始まりは「Dota Auto Chess」といわれており、近年タイトルが増加している。

参照:近年最も成功したと言われるゲーム「オートチェス 」とは?|エガオヲミセテ@オートチェス日記

ゲームシステム

このゲームでの目的は、「自分なりの技術を育て、ハッカソンで高い順位を取り続けてハイスコアを目指す」ことが目的のゲームになっています!

以下の「技術カード」を集め(もしくは奪い合って)、自分なりの技術を育てていきます。 image

ゲームの流れ

基本的には「1ターン=1ハッカソン」として、全10ターンのハッカソンをこなしていくことになります。

各ターンの準備フェーズでは

  1. 技術カードの購入
  2. 今回のハッカソンで使う技術の選択
  3. アイデアの決定

45秒で 行う必要があります。 つまり、

  • 自分の欲しいコマをショップから買い込んで
  • 自分のコマを選択し
  • テーマに沿ったアイデアを出す

必要があります!(むずい!)

image

リポジトリ

フロント https://github.com/2509-democracy/democracy-next

インフラ https://github.com/2509-democracy/democracy-infra

採点用のAI Agent https://github.com/2509-democracy/scoring-agent.git

画像生成のworker https://github.com/2509-democracy/create-image-worker

技術

image

  • Next.js (app)
  • AWS API Gateway WebSocket + Lambda + DynamoDB Streams (realtime)
  • Cloudflare
    • Pages (app hosting)
    • Workers AI / Agents SDK
      • nano-banana (img gen)

技術チャレンジ部分

  • Palumi + C# (IaC)
  • Cloudflare 中心の構成
    • Workers AI
    • Cloudflare Agents
  • OpenNext

技術的な推しポイント

採点用のAI Agents構築

image

CloudflareのAgents SDKを使って、採点用のAI Agentsを作成

Agentsのフローとしては、全てを統括するオーケストレーターが各項目の採点官(ワーカー)に向けてタスクを生成する。 各ワーカーがそれぞれの採点タスクをこなし、その結果を全てオーケストレーターが統括して返す。

採点する項目によって、使用するLLMのモデルを変えることでモデルの強みを活かした賢い採点をすることができている。

AI活用

Copilot を限界まで活用する

昨今、スペック駆動の AI Agent が出てきたりして「設計」のフェーズに踏み込んだツールが増えつつあります。 これ自体はうれしいことですが、ハッカソンではとても速いスピードでのデバッグ能力が求められることがあります。そうした際、人間がコードベースのことを理解していない という状況は忌避すべきです。

そのため、私は copilot を推しています。人間の判断の余地を残すことで、開発の一員として人間が取り残されないように開発しています。

...といっても普通に使うだけでは他の Agent と大して変わらないので、以下のようなカスタムプロンプトで制御しています。

# copilot-instructions.md 各作業を以下のように定義する。 - 「調査」と指示された場合、都度 docs/reports に記載すること - 「計画」と指示した場合、docs/tasks.md に計画を記載する - 前回の内容が残っている場合は、読まずに消して構わない - コードベース / docs を読み込み、要件に関連性のあるファイルパスをすべて記載すること - 不明な点については、fetch mcp を使用して検索すること - 必要最小限の要件のみを記載すること - このフェーズで、コードを書いては絶対にいけない - ユーザが「実装」と指示した場合、docs/tasks.md に記載された内容に基づいて実装を行う - 記載されている以上の実装を絶対に行わない - 実装が終了したあと、`coderabbit --plain` を使用して、コードの説明と次にユーザが取れる行動を説明する - 「デバッグ」と指示された場合、直前のタスクのデバッグ「手順」のみを示す

たとえば何も知らない Terraform を使って AWS のリソースを立てる場合、

  • 「調査」で確かなソースから情報収集をおこなってもらい、知識をつける
  • 「計画」で↑をもとにした正確性の高い計画を立ててもらい、人間がレビューする
  • 「実装」で実際にコードに起こしてもらう

...のように、人間と AI がほどよいペースでキャッチボールを行うように開発することで、AI に丸投げしないような開発スタイルをじつげんしてます。

documentation MCP

↑に付随しますが、copilot と documentation MCP を使うことでソースをより信用できるものにしています。 今回は

  • Terraform MCP Server
  • AWS Documentation MCP Server
  • Cloudflare Documentation MCP Server
  • Supabase MCP Server

あたりを使用しています。

Code Rabbit CLIを使って、手元でレビューしてもらう

最近登場したCode Rabbit CLIを使って、Pull Req作る前や自分の任意のタイミングでCode Rabbitにレビューしてもらうことができる。 そのフィードバックをもとに、質の高いコードをPull Reqに乗っけられる

Pulumi Neoを使い、IaCコードのベースを書いてもらう

Pulumi Neoは、おそらく回答を作成する際にPulumiのドキュメントを読んで返してくれるので、かなり精度の高いコードが生成されていた。 Pulumi Neoを使うことで、慣れていないC#でのIaCもなんとかなった

MCPを使ったContext Enginnering

ただ要件を投げるだけでなく、MCPを使って要件に必要なContextを与えるようにしたり、デバッグの手段を生成AIに与えることで、無駄なデバッグの手間を省くことができた

その他

使用したAIたちツールたち

  • Pulumi Neo
  • GitHub Copitlot
  • Code Rabbit CLI
  • Claude Code
  • Gemini CLI
  • Cursor CLI
  • Gemini Code Assistant

MCP

Context Enginneringのために使ったMCPたち

  • Terraform MCP Server
  • AWS Documentation MCP Server
  • Cloudflare Documentation MCP Server
  • Supabase MCP Server
  • Cloudflare
  • Context7
  • Serena

苦労した点

アプリまわり

当初、リアルタイムは supabase realtime を使用して初心者2人に任せる予定...でした。 ところが夜中まで作業してもランダムマッチング処理が動作せず、仕方なく AWS 構成に変更しました。簡単に実装できるだろうと思っていた部分で6時間程度潰してしまい、胃が痛いです.......

採点Agentsまわり

  • そもそもモデルによって回答の癖があった → Deepseek R1などの試行モデルは、試行内容まで飛んできてしまうため処理に困った
  • 本当はgpt-oss-120bとか使いたかったが、回答が返ってこないためワーカーやオーケストレーターとして使用できなかった(悲しい)
  • Agents SDKを使ったAgent作成の情報が公式のドキュメントくらいしかなかった → Cloudflare Document MCPを活用しながら、理想のエージェントの挙動になるように調整

インフラまわり

  • 元々、OpenNext + Cloudflare Workersの構成を取る予定が、そもそもOpenNextが使えなかった (悲しいね
  • PalumiでPagesProjectsはあったが、WorkersProjectsがなかったため、GitHubのリポジトリと連動してWorkers更新ができない → デプロイの方式を、next-on-pagesを使う方針に変えたため
  • PalumiがC#対応してたので、ノリでC# でIaCやってみたが、C#が全然わからんかった
  • .NETのバージョン問題がずっと起こってた → 最新すぎて怒られたり、古すぎて怒られたり...どっちなの - Preview環境と本番環境の差異

yotu

@yotu