非エンジニア2人が、AIと一緒に「混雑と暑熱の予報」を作ってハッカソンに出た話 — CROWD WEATHER（AI HACK 2026）

イベントの混雑を「予報」して、
混雑緩和・事故防止・理想的な運営を実現するサービスです。

0. AIハッカソンに出るきっかけ

普段、イベント制作の仕事をしています。エンジニアではありません。

夏の野外イベントの準備で、毎回やっているのが、
運営計画書・人員配置図づくりです。

どこに誘導を置くか、給水と救護をどこに構えるか。
この現代で、それに頼るのは、紙とPowerPointと経験者の勘です。

　
人件費が上がっている中で、AIがある中で、
手作業でやっていることは、何とかならないか！

オープンソースで、各イベント会社が共通でできるようなSAASがあれば、
もっと各社がイベントクリエイティブに、集中できるのではないか！！

というか、夏の気温上がりまくっていて、
運営も危険リスク上がっていて、対策求められている！！！🌡

　
ずっとそんなことを思っていた、
元会計士・元広告代理店勤務のプロデューサーです。
（何度も言いますが、非エンジニア）

そんな中で、最近AIも勉強し始めたし、いくつかAIハッカソンに出る中で、
「これはAIで解決できるのでは？」と思いました。

そして、たまたま賞金が出るAIハッカソンを発見して、
MENSAの友人を誘って参加することにしました。
（勝ったら、メンバーでで最高のお寿司に行きます！！！）

https://aihackathon.jp
総額100万円！

1. AIハッカソンのテーマ

AI HACK 2026のテーマ、「本番で通用する次世代のAI Productを作る」
私はこう定義しました。

• 本番で通用する
  　= デモ用のハリボテではなく、実際に動いてAPIが繋がっている
• 次世代のAI Product
  　= AIを使うこと自体に意味がある
  　イベントの現場で、現実の課題を解決するようなものを目指しました。

最初は「イベント制作まるごとAI化」を考えましたが、
1週間では無理だと思い、訴求機能を絞り込んで、
毎夏いちばん怖い「暑熱」と「混雑」のリスク管理に絞りました。
日本の夏の高温化対策が、自分にとってもあったらいいと思いました。

危険な密度は当日突然生まれるのではなく、
動線・時間帯・天候・来場規模の掛け算で事前にほぼ決まっている。
それなら予報できるはずだ、というのがこのプロダクトの出発点です。

そしてもうひとつ。
チームは2人とも非エンジニア。
私はCodex、相方はClaude Codeという、
それぞれAIコーディングエージェントと組んで、開発しました。

今年のAI HACKは非エンジニアでも参加できる建て付けだったので、
「現場の人間がAIと組んだらどこまで作れるか」の実験でもありました
（後半で、Gitで盛大につまずいた話も正直に書きます）

　

2. CROWD WEATHERは30秒で何をするか

CROWD WEATHER
= 混雑と暑熱を「事前予測予報」し、イベントを安全に進めるプラットフォームです。
イベントをする主催者全員が、ターゲットです。

やることはシンプルにしました。

1. 開催日・天候・気温・チケット販売数を、スライダーで入れる
   （うち、天候・気温はＡＰＩで自動取得、販売数は手動で調整）
2. 会場図の上に「何時にどこが危なくなるか」が色で出る
   （混雑×暑熱×日陰が、色付きで分かりやすく）
3. 「指示を出力」を押すと、予報値から運用計画書・指示などをAIが起草する
   （それぞれの立場に合わせて、現場ですぐ活用できるようアウトプット）
4. 計画書は配置図・暑熱日陰図つきでPDF保存できる
   （事前の制作に活用して、現場の予算最適化につながる）

既存の混雑可視化サービスが教えてくれるのは、「いま混んでいる場所」。
競合は、eagle eyeさんなどがあります。

でも、運営計画に本当に必要なのは、「これから危なくなる場所」。
天気予報が傘を持たせるように、混雑予報は誘導員を先に立たせる。
そして人流さえも、予報にもとづいて誘導していく。

それが、今回のプロダクトの新規性になります。
花火大会で、1分の早く帰りたい人。
音楽フェスで、誘導したいブースがある人。
そんなニーズまで満たすものを作っています。

運営に関しては、
現場の役にも立つような「現場の勘」の再現可能化、
経験者の暗黙知をチームの共有物にする運営コパイロットを想定しています。

ちなみに、この企画のたたき台自体も、
AIエージェントに壁打ちして、固めました。

プロダクトの中でAIを使っているだけでなく、
企画を作る段階から、AIをフル活用して、二人三脚で作っています。

　
　

3. 設計思想: AIに「計算」はさせない

最初に決めた、このプロダクトで一番大事な設計判断です。

気温33.5℃・湿度64%・チケット18,000枚・日陰率10%
        ↓ TypeScriptの決定的計算（LLM不使用）
混雑指数・WBGT（暑さ指数）・日陰率・危険時刻を算出
        ↓ LLMは「翻訳」で利用・重い処理にせず、分かりやすくデータ統合
「17:30までに西ゲートへ誘導2名を追加」という人間の言葉に変換

混雑指数もWBGTも、入力が決まれば答えが1つに決まる計算です。

ここをLLMにやらせると、
①原価が乗る ②毎回答えが変わる ③根拠を説明できない、
の3つを同時に損します。

セキュリティーや、反応の速さの観点から、判断の軸は1本にしました。

• 人間の承認を経ずに数値・指示として使われるもの
  → 決定的計算（LLM禁止）。混雑・WBGT・日陰・リスク判定・経路探索
  　
• 人間が読んで承認する「案」と「文章」
  → LLMを活用。計画書の起草・現場指示・配置の提案
  　
• 配信を実行できるのは人間の明示操作だけ。
  → AIが直接配信を叩ける経路は作らない

　

4. 予報がそのまま計画書になる

予報値から運営計画書の総括をAIが起草し、
配置図・暑熱日陰図と一緒に、印刷/PDF保存まで、できます。
実際の制作に直結する、アウトプットの形も実装しました。

プロンプトには「入力にない数値を作らない」を明示して、
質の担保もしています。
　

◆特に力を入れたところ
制作スタッフ向け、現場ディレクター向け、参加者向けの3画面を構成して、
リアルタイムで、互いのデータを参照して反映できるようにしました。

特に現場ディレクター向けには、時間帯別に行動指示が出て、
忙しくても分かるように、端的な行動指示になるように組んでいます。
一種のシーバー機能の一部の代わりになるようなものを目指しています。

　
また、来場者向けにも、スマホで見れるような、
暑熱・混雑状況に応じて、快適な過ごし方をできるような通知を出します。

人流分析だけでなく、この通知を工夫することで、
特定箇所への誘導といった、
出展社などのプロモーション目的にも、活用できます。
（ビジネス性 プラスアルファ）
　
人流分析でなく、予報にもとづく人流の誘導。
そして、それを運営計画や現場指示にリアルタイム反映する。
より過ごしやすいイベントが実現できるよう、
こうした部分を、実際のデータの入力から進めていきます。

ここからは技術的な話です。

　

5. 技術スタックと構成

分類	技術
Framework	Next.js (App Router) / React / TypeScript
AI Gateway	OrcaRouter（OpenAI互換・base_url差し替えで3社のモデルを横断）
検証	TypeScript strict＋AI出力専用の正規化層（座標クランプ・実在検証）
テスト	Vitest 331件
Hosting	Vercel

構成の要点は、予測層と判断層をフォルダで分けたことです。
実線が今回の画面で動いているところ、点線がまだ画面に繋げていないところです。

点線の2つは、裏側の計算とAPIは書けているのに、画面に載せる時間が足りませんでした。
会場の写真からゾーンを起こす読解も、配置をAIに起草させる提案も、
「AIでなければできない」と思っていた場所です。次の版で繋ぎます。

基準としている数値（今後製品版では変更可能性あり）:
太陽位置はNOAA式の実計算、影は建物×太陽ベクトルの凸包投影、
WBGTはStull(2011)の湿球近似、密度はFruin基準の人/m²実単位です。

意図的に作らなかったもの:
Database（1イベント完結のデモに不要。複数イベント継続運用の段階の話）、ML需要予測（「呼ばない設計」という⑥の方針そのものに反する）、
ログイン/マルチテナント、Push通知など。

6. LLMコストは実測でいくらだったか

1イベントあたりのAI原価は、約14.6円でした。

実測したのは1件あたりのトークン数で、
そこに各社の公表単価を掛けたのが下の単価です。
回数のほうは、想定運用（1イベントで39回）での前提になります。

用途	モデル	単価	回数	合計
会場資料の読解（画像→ゾーン）	openai/gpt-4.1	¥5.5/件	1	¥5.50
計画書・総括の起草	anthropic/claude-sonnet-4.6	¥2.03/件	3	¥6.09
自由文の解釈（What-if等）	openai/gpt-4.1	¥0.46/件	5	¥2.30
現場指示・運営判断	google/gemini-2.5-flash-lite	¥0.033/件	10	¥0.33
来場者への経路説明	google/gemini-2.5-flash-lite	¥0.018/件	20	¥0.36
合計			39	¥14.58

トークン数は実測・単価は各社公表値（OrcaRouterは上乗せなし）
1ドル150円換算。

混雑・暑熱・日陰・経路探索の計算には、LLMを使っていないので、
毎秒動いている画面のAI原価は0円です。
上の39回は「人間が承認する文章を作る瞬間」だけの回数なので、
来場者が何万人に増えても、この部分についてはコストは増えません。

規模が大きくなると、差額はいくらになるか（ここからは試算）

来場者向けの通知や案内を全来場者に届けると、
そこはチケット売上人数に比例して、上昇します。

上の単価はそのまま使い、
件数だけをチケット数から見積もったのが下の試算です。

チケット18,000枚なら、来場者案内14,400件（チケット×0.8）・
アナウンス43,200件（同×2.4）・文書6件になります。

　

処理のしかた	金額
全件を計画書と同じモデル（¥2.03/件）で処理した場合	¥116,940
用途別に振り分けた場合	¥7,414（-94%）

内訳:
来場者案内14,400件×¥0.46 ＋ アナウンス43,200件×¥0.018 ＋ 文書6件×¥2.03

　
コスト最適化により、できた差額は約11万円です。

チケット数を動かしたら金額は変わりますが、
比率はほぼ-94%のままでした。
ここは試算です。実測なのは上の単価（トークン数）のほうだけ。

モデル選定も実測で決めました。
実際に比較したベンチの抜粋です。

モデル	秒	出力トークン	本文
google/gemini-2.5-flash-lite	2.48	342	562字 ✅採用
anthropic/claude-sonnet-4.6	18.73	700	760字 ✅計画書用に採用
openai/gpt-5-mini	7.92	700	0字 ❌
orcarouter/auto（最安自動選択）	45.96	2,620	462字 ❌不採用

学びが2つありました。

①トークン単価が最安であることと、1リクエストの総コストが最安であることは違う。
自動最安選択は思考型モデルを引いてしまい、
同じ質問に18倍の時間と7.7倍のトークンを使いました。

②エラーを出さずに本文0字で返るモデルがある
HTTPは200なのに中身が空。
いまは打ち切りを検出して明示的にエラーにしています（無言の空振り課金を防ぐ）。

APIには、OrcaRouterを使っています。
1つのキーで複数社のモデルを横断でき、個人情報マスク（PII Shield）や
AIのツール呼び出し検査（Agent Firewall）といったガードレールが用意されています
（ただし標準設定のままでは日本の携帯番号が素通りしました。詳細は次章）。
https://www.orcarouter.ai/ja

フォールバックはサイト側で実装しました。
第一候補が落ちたら次の候補へ、
最終的には別会社のモデルまで自動で切り替わります（わざと壊すテストで実測2.71秒）。

ダッシュボード側では、
実測で確認済みの3モデル（gemini-2.5-flash-lite / gpt-4o-mini / claude-haiku-4.5）だけに絞った専用ルーターを組んでいて、
autoまかせにして45秒待つような事故を防いでいます。

本日（8/15）も3回再実測し、問題なく動作することを確認済みです。

　

7. セキュリティ: 運営計画は、漏れると攻撃側に利する情報

「運営がどこに何人いるか」の文書は、裏返せばどこが手薄かのリストです。
とくにVIP来場などの際には、計画書のデータも一部機密になります。
個人情報保護だけでなく、扱う題材そのものが守るべき情報でした。

打った手を、強い順に並べます。
同じ図に4つ並べると全部同じ強さに見えてしまうので、
「誰が保証しているのか」も一緒に書きました。

守るもの	手段	誰が保証するか	コントロール
AIの出力	サーバー側で実在	自分たちのコード	効いている
APIキー	サーバー側だけで実在	自分たちのコード	効いている
LLMにかかる個人情報	PII Shield	OrcaRouter	効いている
AIツール呼出	Agent Firewall	OrcaRouter	監視モード
デモへのアクセス	合言葉ゲート	自分たちのコード	本番ではID・パス

表の最下段にある合言葉ゲートは、
デモを限定公開するための措置で、本番の認証機構ではありません。
あくまでデモ期間の,簡易閲覧の運用上の入口として置いています。

また、AIが返してきた名前やコードを、
そのまま画面に出したり配信したりはしません。

名簿や実在するゾーンの一覧から必ず引き直して、
存在しない項目・重複している項目はサーバー側で棄却し、
何件落としたかを返します。

人員配置へのAI提案で実測したところ、
AIの19件の提案のうち2件がこの検証層で棄却されました。

選択肢を実在するものだけに絞って渡しても、AIは無効な項目を出してきます。
「AIの出力をコードで再検証する」は、
理論上の備えではなく実際に働いている、ということです。

APIキーはサーバー側だけに置いていて、ブラウザ側のコードには一切出していません
（LLM呼び出し層と課金API確認用の2ファイルだけ。grep で確認できます）。
開発の途中でブラウザから直接AIのAPIを叩いていた実装が見つかり、
サーバー経由に直しました。

ガードレールを入れてみて、分かったことが2つあります。

遮断は、段階を踏んで入れる。
Agent Firewallは遮断できること自体を実測で確認したうえで、
本番は監視モードで稼働させています。

提案データが配列構造なので、
条件を precise に組まないと正常な提案まで弾いてしまう。

公式も observe → shadow → enforce の段階的展開を薦めていて、
安全側に倒すならまず観測から、という判断です。
遮断の有効化は次の段階に置いています。

8. これからさらに進めたいこと

技術的には、AIをもっと活用できる余地がまだ残っています。
（ここは先行の技術企業と提携想定で作ります。お声がけお待ちしてます！）

• カメラ映像からのリアルタイム人流把握:
  現状の混雑指数は、チケット販売数と時間帯モデルから算出する予測値です。
  ここに会場カメラ・センシング機器のデータをAIの画像認識で解析。
  「実際にいま何人がどこにいるか」を重ねられれば、
  予報の精度はもう一段上がります。
  　
• スタッフ・来場者の口コミ情報の統合:
  「このエリア体感より混んでる」「日陰が思ったより少ない」といった、
  音声など、数字に出ない現場の一次情報をAIに拾わせる。
  現在も「自由文の解釈」で、
  スタッフのWhat-if質問には答えていますが、さらに拡張。
  　
• 人員配置エディタ:
  スタッフを会場図上に配置し、ドラッグで入れ替え、
  確定すると全員へ一斉通知が飛び、
  誰がどこに行くべきかか瞬時に分かる仕組み。
  　
  そのほか、構想段階のものとして、
  ・PLATEAU等の3D都市モデル連携による日陰・ヒートマップの高精度化
  （現在は建物矩形の凸包投影という2D幾何で代替）
  ・チケット販売サイトの実データ（販売数・入退場・人流）との連携
  これらもあり、予測精度の向上も考えています。

9. 非エンジニア2人の共同開発で、実際に起きたこと

ここからは技術ではなく、正直な失敗談です。

　
Gitがちゃんと使えませんでした。（超初歩）
共有リポジトリからVercelへのデプロイがなぜか通らず、
「じゃあ自分のVercelに上げます」をやった結果、
気づいたらリポジトリが2つ、デプロイ先も2つになっていました。

　
極めつけは、
同じバグを、2人が別々の日に、別々の方法で直していました。
「AI生成が実は動いていないのに、バッジは常に『AI生成』と表示される」という不具合を、私は自分のリポジトリにサーバー関数を新設して直し、
相方は共有リポジトリの既存APIに繋ぎ直して直していました。

お互い直したつもりでいて、
diffを取って初めて「これ、直し方が2通りある」と気づく。
最後は2人の変更を1行ずつ突き合わせて、11箇所を手作業でマージしました。

pushひとつにも「これを押したら相手の作業が消えるのでは」とビビり、
メッセンジャーで「push していい？」と確認し合う。
エンジニアのチームなら発生しない時間の使い方だったと思います。

　

ただ、面白い発見もありました。
私はCodex、相方はClaude Codeに書かせて、
人間はレビューと判断に回る——という開発体制は、
プロダクト本体の設計思想（AIは提案まで、決定は人間）とまったく同じ。

　

10. おわりに — AIハッカソンで、AIに計算させなかった

この開発でいちばん「次世代」だったのは、
派手なAI機能ではなく、
AIを目的に合わせて、どこに使い、どこに使わないかを決めたこと
だったと思っています。

安全に関わる数字は、聞くたびに答えが変わってはいけない。

だから混雑もWBGTも経路も、決定的計算にして、
AIは「非構造の資料を読む」「人間が承認する文章を書く」という、
AIにしかできない場所に集中させる。
「AIで全部やる」から「AIをどこに使うか、効果的に使うか」。

イベント制作の現場には、
経験豊富なあの人にしかできない判断がまだたくさんあります。

そうしたビジネス面と照らし合わせて、
属人化させず、チームの共有物にするイベントのツールを、
現場の人間自身が作れる時代になりました。

非エンジニア2人でも、ここまで来られました。
また、これからも色々作っていきたいと思っています。
　

ご興味お持ちの方がいらしたら、お気軽にご連絡ください！
https://www.linkedin.com/in/takamitsu-baba-4a02bb312/?locale=en

---

本プロダクトは AI HACK 2026 への応募作品です。
LLMゲートウェイには、
参加者特典で提供された OrcaRouter を使用しています
（3社のモデル横断・実測ベースのルーティングは本文§6のとおり）。

デモ: https://crowd-weather-six.vercel.app/ （合言葉 crowdweather2026）
*Youtube: https://www.youtube.com/watch?v=-EHbLAhGEv8&feature=youtu.be