Built with Claude: Japan 2026、完走しましたー！
11/2〜11/8 のハッカソンに1人で出てました。
結果は250名中、ファイナリスト（上位6チーム）に残りましたが入賞できませんでした！残念😭
んで、どんなの作ってたかをちょと公開。
EVAC LAYER
すべての画面を、命を守るインフラへ
警報が届いた瞬間、スクリーンは、その場所に合った避難案内に変わります。
既存のサイネージに、災害時の緊急案内のレイヤーを自動で追加するっていうハッキング目線でのオープンソースプロジェクトを作りました。
- 動画（2:51）https://youtu.be/W_wwWq_1ob8
- simulator https://rettuce.github.io/evac-layer/
- GitHub（AGPL-3.0）https://github.com/rettuce/evac-layer
動画はあくまで過去の実際の警報を再現したシミュレーションです。この駅も実在しなくて、Blenderで組んだ3Dのコンコースに、実際に発表された気象庁の電文から作った画面を貼ったシュミレータです。（1週間の限界😂）
僕はこれまで色んな所のいわゆるサイネージみたいな仕組みからコンテンツまで色々と作ってきたんですが、中には常設稼働で毎日多くの人が目にする設置箇所のものも多く、もし災害が起こった際にここが災害・避難情報の自動配信の場になれば、というアイデアから今回のプロジェクトができました。
駅や商業施設など公共空間のサイネージは10年以上作ってきていて、渋谷駅新南口を出たらすぐに見える様々な形状で同期した巨大なLEDのファサードのサクラステージとか、東急田園都市線 駒沢大学駅のホームのサイネージとか、大丸心斎橋店のエスカレーター横の10フロア吹き抜け空間のLED+造形とか。
で、それらは災害のときに自分から能動的には情報を出せない。広告を流し続けるか、黒く消えるか。しかも担当者が手動で配信をかけなければならない。
2024年1月の能登半島地震の津波のあと、新潟県上越市の検証に「外国人や市外からの来訪者が、どこに避難すればよいかを判断することが難しかった」と書かれていて。警報自体は届いていたけどその次の どこに？やどのように？ の具体的な一言があれば良いのかなーとか考えた。
スクリーンはもう街中にあって、緯度経度も向きも分かってる（少なくとも僕の設計したサイネージには全て緯度経度も付与されてる）。
であればその位置情報からスクリーン毎に適切な避難情報を自動で配信できる仕組みが作れないか？
一人では到底できない物量
まず防災の案内を準備するには、一人では到底できない物量がありました。
自治体ごとのハザードマップ、実際に記録した膨大な電文、場所ごとに違う避難先や経路、千差万別のスクリーンサイズにレイアウト。それを仕組みとAIの並列処理で解いていきました。
同じ警報でも、市区町村や置き場所が変われば避難先も方向も距離も、伝える言葉も変わり、画一的な解決策では答えが出ない問いを、場所の数だけ解くことになる。
それを駅前の柱、壁、天井の帯、正方形のモニター、と千差万別のスクリーンに合わせて、10言語で組む。全国でやるなら自治体×場所×画面の形×言語の掛け算です。
人がやろうとすると、時間も労力もコストも膨大にかかるので、そこを一気にシステム・アルゴリズムの力とAIの並列処理で解決しよう、というのが今回の設計でした。
ハッカソンのルール上、コードは期間中に書く必要があるので、10/14〜11/1はコードを書かず、調べものと「時間がたたないと溜まらないもの」の準備だけしてました。（この時点では参加できるか分からなかったけどそもそもこの仕組みを思いついた以上自分のプロジェクトに追加しようと思っていたのでスタートした）
国内・海外の事例やデザイン、技術の調査を並列で5本、8自治体21本のハザードマップPDFを落としてテキストが取れるかの実測、データの利用条件の確認（ISO 7010の図記号はネット掲載不可だったので、Material Symbolsと自作に切り替え）、あと気象庁のフィードの自前記録をlaunchdで開始。
最後のやつが結果的にいちばん効きました。気象庁のXMLは過去の電文のアーカイブが無いので、実際の警報を使いたければ自分で溜めておくしかない。本番の時点で20,592本文が溜まっていて、その中に10/21の秋田県由利本荘市、子吉川の氾濫でレベル2 → 3 → 4 → 5と上がっていく実電文の列がありました。動画の警報の場面は、ほとんどがこの電文です（架空の電文は作らないって縛り）。
んで10/30に採択の連絡。5,500件の応募から250だったらしく、ここはただのラッキー。（まーやるならハッカソン内でやる方が第三者視点の意見ももらえるしいいよね）
由利本荘市のレベル4の警報を、市内の4か所に置いたスクリーンで組むと、南西へ570m・東へ160m・南東へ210m・北へ80m（上の地図の4枚）。スクリーンの緯度経度と向きから最寄りの指定緊急避難場所を選んで、見る人から見た方向と距離を出しています。
資料のほうも自治体ごとに作りがばらばらで、膨大な資料を実際に読ませてみると、公式のサンプル電文だけで作っていたら出なかった問題がいくつも出てきました。
- 輪島市では、国土地理院のデータと市のPDFで施設名が20件食い違っていた。2012年の地図の旧施設名や、国土地理院側の誤記（GYMがGIMになっていた）など、どれも実在の食い違いでした
- 輪島市の津波ハザードマップPDFで、テキストを抜くと「最大津波」が「最 津波」になる。文字の対応表を持たないフォントで描かれた字が欠けていて、文字数や文字種の比率では検出できない。疑わしいものは止めて、人が許可したらページを画像としてClaudeに読み直させる経路にしました（欠けていた「最大津波高 8.3m」がVisionで戻ってきた）
- 由利本荘市のレベル5（氾濫発生情報）で、レベルがnullになる。地区が水位の観測所ではなく堤防が切れる地点で書かれていたため。分からないレベルを黙って「基準未満」扱いにせず、理由を書いて止めるように
- 最初の一括処理で、出していない警報の「解除」の画面が出てくる
Reader のモデルも同じ輪島市の資料で比べてます。Haikuは$0.009で施設19件・津波高なし、Sonnetは$0.257で施設113件・欠字のPDFから津波高まで復元。ここは迷わずSonnetでした。5自治体を読ませた費用は合計$2.88。人が読んだら何日かかるかは考えたくねー。笑
画面の形は16:9・9:16・32:9・1:1・柱に巻くLEDの5つを基準のグリッドとして持ち、どんな縦横比を渡しても、いちばん近いグリッドを選んで組み直します。全画面を全形状・全画角で描く確認が440枚。
ここは自動化だけでは届かなかった部分でもあって、グリッドの規則から組み直した案が出てきたときに、行間は重なってるし図記号ははみ出てるしで文字通り「めちゃくちゃすぎる…」となり。。規則化して比率で展開する方式が3回続けてクオリティチェック通らなかったので、先に9:16だけ自分でFigma上で組みました。部品を全部Figmaに並べてもらって、自分が配置して、その数値どおりに実装してもらう。
これは一発で通って、そこから他の形状に展開してもらいました。構図の芯だけ人が置いて、物量はシステムに持ってもらう、という分け方になった。（結局親レイアウト4種類くらいは全部自分で組んだかな？）
検査のほうは、Visionが最初に25件の指摘を出して、5回の実行で25 → 8 → 4 → 4 → 0。中身は「浸水に警戒」に雨雲の図記号、みたいな意味のずれが多くて、図記号は行動だけを表すことにしました。
因みにこの件数、最初にセッションが口頭で報告してきたのは「25 → 3 → 0」で、ファイルを見ると「25 → 4 → 2」、数え直した実数が上の値でした。並列で回すと数字の出どころが散らばるので、数字は判定器とファイルから取る、を初日に覚えた（覚えさせられた）。
あと途中から作ってたブラウザで触れるシミュレーターは、最初22面のスクリーンを全部iframeで3D空間に埋め込んでいて。重い。。
実装どうなってんねんと気付いたときに「iframe埋め込みとか普通やらんやろ。オフスクリーンのFBOに描いて、Meshごとの固定UVで切り出しーや。警報は静止画だしテクスチャ切替で済むやろ。」とFB返して、作り直し指示。（人相手じゃないと気にせず好き勝手言えるよね）
最終的に平常時の映像は1本の動画を22面で共有して、面ごとにUVで切り出す形になってます。（three.jsの3Dシミュレーターは作り方から指示しないとまだまだ下手でした😂）
逆にClaude側が粘って見つけたものもあって、録画のフレームが255段階中64ずれる問題。何回撮っても9回中2〜3回だけ違う絵になる。
録画側の待ちを延ばしたり、ブラウザの描画を毎回同じにするフラグを足したり色々やって全部効かず、最後に原因が描画側のコードにあると分かった。Promise.allの中でawaitした結果をオブジェクトのキーに入れていたので、キーの順番が通信の完了順になって、非表示レイヤーのDOM順が毎回変わっていた。
こういう1行の原因を、9回分の矩形とスクショの対応まで取って詰めてくるのは人だとやらないなと思う。（自分は多分途中で閾値を緩める）
80点を1万個
Claude Code の並列セッションは9つ。最近の個人的なトレンドとしては80点のものを1万個作ってブラッシュアップしながら同時に進める。
時間をかけて120点を作る工程も大好きなんだけど、個人的にここの80点は時間が解決すると思っているし、それまでにこうした自分のワークフローや可能性を探っておきたいなって思いから色々試してる最中です。
自分一人の見聞きした経験・知見では、作れるものの方向は固まってしまって、どうしても同じような表現であったりアイディアばかりになると思っていて。あと単純に自分の表現に飽きてくる。
そこでAIに自分の趣味思考の部分を学習させながら、そこから一歩外に広がったアイディアを100本ノックのように日々作り続けてもらって、それに対してフィードバックをすべて返しながら、80点のものを1万個作る。（前に書いた制作時におけるAI利用についての続きみたいな話）
記事では、AIは80点を広い範囲で取るプレイヤーだと書いたけど、それを範囲じゃなく数のほうに振ってみてる最近、というのが今の感覚に近いかな？
一つ一つの作り込みは、手でやっていた頃より断然浅い。その代わり、バリエーションや方向性の数はAIナシでは全く届かなかった水準まで来ていて、何を選びブラッシュアップをしながら表現として出していくかのジャッジを自分が持つ。って感じ。
9つの内訳は、全体のまとめ役（仕様を書く・取り込む・検収する）が1つと、実装のセッションが最終的に8つ（agents・render・demo・layout・sim・brand・copy・bgm）。それぞれ git worktree とブランチを持って並行で動いていて、自分は全部のタブを見ながら判断して指示してって係。
初日はagents（電文の判定とReader以降の処理）・render（画面の描画）・demo（3Dと映像）の3つから始めて、途中でlayout・sim・copy・bgmを足しました。最後に人が決める領域（文言・音・レイアウト）は、早めに専用のセッションに切り出してファイルの持ち主ごと移すほうが楽でした。
1ターンの型はほぼ固定で、セッションがpush → まとめ役がmainにmergeしてテストと型チェック → push → 検収して次の指示。初日だけでcommitが約60。
ここ1年くらいずっと言ってる「人間が一番のボトルネック」、今回もまさにこれ。自分の手が止まると全部止まるので、自分はコード書くより体制組んで回すほうに全振り。GUIとかマジでいらん。←
並列で回すうえでいちばん効いたのは、取り決めを先に固めたことかなと思ってます。layoutのJSONが全員の依存先で、Composerが書いて、Rendererが描いて、Verifierが検査する。
初日の午後、render側のテンプレートの構造を変えたらagents側のテストが5本落ちて、そこからは「セッションをまたぐ参照は関数の契約で固定する（データ構造を直接たどらせない）」をルール化。
もう1つは返却の型。各セッションの報告は必ず「結論・変更したファイル・どう確かめたか・確かめられなかったこと・未解決の点」で終わる。最後の2行に、まとめ役から見えない前提や走らせられなかった検査が出てくるので、そこを1つずつ決めてから次に進む。
止まり方もいろいろありました。アカウントの切り替えで「Not logged in」、5時間制限、入力欄に未送信のまま約8時間黙ってる、など。結局、一定時間報告が無いセッションはtmuxを巡回して起こす、という地味な運用に落ち着いてます。この辺りはAnthropicさんに頑張ってもろて😌
で、80点を1万個のほうは、今回は判断の量として出ました。結局作業の記録712項目のうち、222項目が自分の決めたことだったそうです。やり方は毎回同じで、案を何本も並べた比較ページを出してもらって、自分は見て選ぶかFBいれて突き返すか。（最近はOK/NGボタンとFB入力フォーム同時に入れてもらってる）
カメラアングル、キービジュアル、ロゴ、効果音、平常時の環境映像のパターン、キーワードの候補などなど。
3Dのコンコースも初日はこんな感じで、柱の画面は吊り下げのモニターでした。（これは何も指示せずに出させた初稿くらいかな）
ここから「全部壁面埋め込みでベゼルレスにして、ディスプレイパターンごとに1枚じゃなく複数枚設置OK、柱は9:16にこだわらずLEDで巻いて、下がり壁の下マージンいらね」などなど言って、序盤はレンダリング画像に直接赤入れて返したりしてました。（ほんと最初だけ）
FBした失敗例も。初日の夕方、「警戒レベルが何段階あって現状どのくらいの危険度なのかが分からない」と言ったら、帯の隅に小さな箱が5つ並んだ案が出てきて、思わず「5段階レベルのデザインが酷すぎる」と書いてしまった🤦♂️（原文ママ）
そのあと縦のラダーや丸バッジまで本実装してもらったのだけど、迷走感が半端なかったのでその夜のうちに全撤去しました。😂
この辺りは自分の指示やリファレンス提示ができてない自分のミスっすね。
音も同じで、場面転換の効果音を10本出してもらったのを聞いて「全部長いし電子音サンプルみたいでボツ」を繰り返し、作り直しの20本くらいから合成音を1個採用したけど結局使わず。警報の切替音のビープのみ。Jアラートに似た音は最初から使わないってルール。BGMは直近SunoMCPの話題が流れてきたのでSunoMCPで作りました。（これも結局過去に作ってたものをremixしたからあんまり意味なかった）
ナレーションも途中で迷走。TTSはmacOSのsayが使用許諾で公開できない、VOICEVOXのキャラクターも提出の利用許諾と両立しない。んで一度「ナレーション無し、字幕とテロップだけ」と決めたものの、過去の受賞者セッションで「声が大事」「音声が悪いと通用しない」という話が出てきて、ナレーション有無で審査評価にも関わるとの主催者コメントもあり、うぅ、、となって結局自分の声で録りました。（自分の声って聴き慣れてないからマジ嫌い😇）
台本と場面静止画が出ていて、REC、Start/Stop、Saveボタン、秒数カウントなどが付いた録音用ツール作ってもらって、使える秒数を見ながら録音2巡した。このナレーションRECツール結構よく出来てたので単品WebAppにしようと思ってる。
動画は2日目の深夜に通しのv1（179秒）が出て、そこからv9.3まで10版以上。これをVコンとして下敷きにして最終の編集は自分でDaVinciで。Vコン自然言語で作れるのクソ楽すぎる…🥹
1万個には全然届いてないけど、1週間でこの量の案を見ながらFBループ回せるてのは、やっぱ今ならではって感じの作り方で楽しいかな。
提出前日の夜中には、審査員・SNS・ブランディング・開発者・批判役の5つの視点と、IE3のブランディングを相談していたセッションの計6つに、同時にレビューしてもらいました。
「公開文書が古い（失格のリスク）」「Lv5の扱いが矛盾して見える」「再現であることの断りが足りない」「READMEの手順どおりに動かしても警報が出ない」などなど。画像にSIMULATIONの印を入れたり、手順を実測し直したり微調整してもらた。
数字
- 期間: 11/2 12:00〜。それより前にコードは無し
- commit 854（うち統合261）、コード約2.3万行、テスト209件（11/8の提出時点）
- 気象庁の電文206本（5自治体・3週間の記録）→ レイアウト110、10言語
- APIの費用（11/5までのデータ処理）: Reader $2.88、Writer約$7.08、Visionの検査$11.34、合計約$21.30。運用時の見込みは1自治体あたり年に約$13
んで、上の金額に入っていない、いちばん使ったところ。
開発中のClaude Codeはサブスクの枠で、今回はUltra Planでの個人アカウントの1週間制限を全体70%・Fable 100%、IE3でのチームアカウントを2アカウント分（どちらも1週間制限を全体80%・Fable 100%）と、めちゃくちゃサブスク枠使いまくってる。（先月も別件でUltra2席とか使ってた）
正直、個人アカウントの他にチームアカウントを2アカウント分使ってるのとかは結構チートだと思う。こういう背景もあって、API料金の支援ではなくて、開発に使うサブスク代金や週間制限撤廃の支援があっても良いのでは？という意見を、提出フォームの感想にも書きました😂
オープンソースにした理由
今回はハッカソンというフィーがない舞台で、提出条件は公開リポジトリ。普段は private ばかりなので、どうせならオープンソースにして、誰もが使える未来として提案するほうが健全かな、と。
普段の創作活動に社会的意義を付与できれば、活動も持続可能性が上がる。そんなちょっと打算的な部分もありつつ、社会にある既存リソースをハックして社会意義を付与するみたいなアイデアが好きで結構気に入ってます。
動画の途中に、こういうテロップを入れました。
街中にあるスクリーン。
それらが自分の位置を知り、災害時に適切な避難情報を出す。
そんなハックができないか？
ハックと言っても、やってることは既存システムに1枚レイヤーを足すだけなのだけど。
平常時の環境演出や施設の広告運用は、IE3 で作っている環境演出システムMOJUR（MOJURについてはまた今度ゆっくり😌）の役目で、EVAC LAYER は災害のときだけ、その上のレイヤーをハックする仕組みです。MOJURにも、この EVAC LAYER を組み込む形で開発を進めています。
ライセンスは AGPL-3.0 で誰でも使えます。AGPL の条件で公開できない製品への組み込みには、別のライセンスも用意します。
できること
- スクリーンの緯度経度から、最寄りの避難場所と方向・距離を出す
- やさしい日本語を含む 10 言語と図記号
- どんな縦横比にもレイアウトを組み直す
- 何を出すかは平常時に人が承認して、警報が来たら承認済みの画面だけ出る
仕組みは2層。平常時に、自治体のハザードマップPDFと国土地理院の指定緊急避難場所のデータをClaudeが読んでおく（Reader）。電文が届いたら、気象庁のXMLを判定して、その施設とその電文のための案内文を10言語で書き（Writer）、5つの基準の形に組んで描き（Composer / Renderer）、規則・ブラウザ・Visionの3段で検査する（Verifier）。
画面に出すものは事前に人が承認しておきます。電文が届いた瞬間に新しく生成して出す、はやらない。承認済みの画面だけが出て、止めるのも運営者です。
めちゃくちゃ自分の声が嫌なのでハッカソン審査終えたらナレーションだけ消したバージョンに差し替えようかなと思ってるんだけど笑、詳細見たい人は3分動画を見てもらえると嬉しいです！
以前「絵を描き続ける為の仕組みづくりで一生を終えそう」と書いていたことがあって、たぶん今もその途中なんだけど
今回の取り組みは、その絵を描き続ける仕組みにどう社会性を乗せて正当化するか？という問いかけの答えの一つなのかもしれない。
作ったものはこのままpublicで続けます。
施設などのサイネージメディア媒体を持っている方や、自治体の方、一緒に実証実験をパートナーとして行って頂ける方は https://ie3.jp/contact/ からぜひぜひお声がけください☺️
因みに1週間の作業は時刻つきで全部ログっていて、この記事もそこから書きました。（記録厨）
お疲れちゃんでした！
you