引越し先の問題を解決するために真の意味でひとりハッカソンをする

この記事は、ABEJAアドベントカレンダー2025の11日目の記事です。

こんにちは。株式会社ABEJAのシステム開発部でエンジニアをしている鈴木です。

他のメンバーががっつり技術に触れている中、今回はひたすらにバイブコーディングする話になります。今年のアドベントカレンダーもバラエティに富んだラインナップになっているので他の記事もぜひご一読いただければと思います！

今回は以下の目次でお届けいたします！

新居が決まった！
熊が街にやってくる！
バイブコーディングについて
ここでタイトル回収
ここから本編
まとめ
We are hiring!

新居が決まった！

長野に住むのが、夫婦の長年の夢だったのですが、夏にとうとう物件が決まり、引越しも間近に迫ってきました！

引越し周りで忙殺されながらも、新生活へのワクワク感が高まる今日この頃ではありますが、とある問題が発生しました。

※ 転勤や転職でなく、自己都合での引越しです。ABEJAではリモートで働き続けます！

熊が街にやってくる！

引越し先である長野は昨今、市街地でも熊の目撃情報が寄せられている地域です。新居は少し小高いところにありますが、「まあ、なんとなるだろう」くらいに思っていました。

ところが、とうとう新居の近くでの目撃情報が寄せられました。自宅までの距離を調べてみると・・・

・・・笑えませんね

ツキノワグマは時速40-50kmで走れるので30秒もかかりません、まさに目と鼻の先です。早急に対策を打たないといけないものの、引っ越しで忙しく、じっくり時間もとれない、そんな窮地に追い込まれてしまいました。

自身で手を動かす時間もあまり取れないので、テクノロジーの力でこの課題を解決していきたいと思います。テクノロジーの力で課題解決というのは、課題解決の方法自体がテクノロジーを駆使していること、課題解決方法の検討にあたってテクノロジーの力をふんだんに使うことを意図しています。

バイブコーディングについて

昨今の生成AI技術の発展で高速にコーディングが可能になりました。バイブコーディングもそんな中生まれた開発ノウハウの一つですが、t-wadaさんもおっしゃっている通り、自分のためのソフトウェアをだれでも作れるのがバイブコーディングの真骨頂です。

Vibe Coding は「自分だけが使う、自分がいちばん欲しいソフトウェアをだれでも作れるようになった」ことが革命的かつ真骨頂なのであって、他の人が使うソフトウェアを作ることには（少なくともまだ）向いてないと思います
— Takuto Wada (@t_wada) 2025年7月25日

品質のコントロールには様々な工夫が必要になりますが、今回みたいなものはおあつらえ向きなケースになります。なので、今回はバイブコーディングを駆使して、ひとりハッカソンをやっていきたいと思います。

ここでタイトル回収

タイトルにもある「真の意味」とは何か説明したいと思います。（あくまで持論です。）

「ひとりハッカソン」という言葉ですが、大概が個人開発を短期間でめちゃくちゃ頑張るという文脈で使われることが多いように見えます。短期間での高速開発自体は間違っていないと思うのですが、昔たくさん参加していた身としてはホストとゲストがいて、ハッカソンははじめて成り立つと思っています。

ホストはそのハッカソンを通して解決したい課題や、盛り上げたい技術領域を提起し、ゲストは決められたレギュレーション、期間の中で実装していくという構図が肝かと思っています。ホスト、ゲストに分かれる必要がある時点でひとりでの開催は難しいようにも思えますが、生成AIの台頭により、それも可能となってきました。

今回は私の生活課題を解決するハッカソンを題材に以下のロールプレイを実施していきます。ホストとゲストの両方にGeminiがいるのが若干微妙な気もしますが、Geminiアプリとコーディングエージェント（Cursor）上で動かす差分はあるのと、Geminiが出力したSolutionをみたい意図があるのでご容赦いただければと思います。

役割	主なタスク	担当者
ホスト	ハッカソンの企画と運営	筆者、Gemini 3.0 Pro
ゲスト	実施要領に沿ったソリューションの実装	Composer 1、Claude Opus 4.5、GPT-5.1 Codex、Groq Code、Gemini 3 Pro

ここから本編

ここからハッカソンの企画・運営を実施していきます！実施した結果は以下のリポジトリにまとめていきます。 github.com

企画

Geminiと壁打ちしながら、ハッカソンの実施要項をまとめていきます。できるだけ私の方で前提条件は指定しながらその穴埋めをGeminiにやってもらうという形で進めていきました。できあがったのが以下になります。

# New Life Guardian Hackathon 実施要項

## 1. ハッカソン開催の背景と目的
**「恐怖を安心へ、技術で家族を守る」**

2週間後に引越しを控えた主催者家族の新居付近（徒歩4分）で熊の目撃情報がありました。
主催者は多忙ですが、ITエンジニアとしてのスキルを持っています。
本ハッカソンでは、**「引越し初日から使える、家族の安全と安心を守るための具体的なソリューション」**を開発することを目的とします。

## 2. ターゲットユーザー（主催者家族）

* **構成:** 夫婦（30代、スマホ所持）、子供（1名）
* **状況:**
    * **居住地:** 長野市内（以前から住んでたことがあり、ある程度の地理勘はある）。
    * **ライフスタイル:**
        * **夫:** 自宅でリモートワークに従事（ITエンジニア）。
        * **妻・子供:** 幼稚園の送迎や買い物などで日常的に外出する機会が多い。
* **心理状態:**
    * 「いつ熊が出るかわからない」という漠然とした恐怖感が強い。
    * 地理勘があるため、日常の行動範囲と危険エリアが重なることに敏感になっている。
* **技術リテラシー:**
    * **夫は現役のITエンジニア。**
    * 環境構築やデータ加工（ETL）の手順が明確であれば、実装・運用が可能。

## 3. 開発要件・制約事項

### ソリューションの方向性（自由提案）
必須機能の指定はありません。「在宅の夫が、外出する家族の安全をどう守るか」という観点から、最適な解決策を提案・実装してください。

### 技術的制約
* **デプロイ/起動:**
    * エンジニアが再現可能な手順であること（Docker, npm, python script等）。
* **データ:**
    * 長野市の熊出没情報（PDF等）の活用を推奨。
    * [長野市 令和7年度クマ目撃等情報](https://www.city.nagano.nagano.jp/documents/3071/kuma20251031.pdf)
    * 必要に応じてPDFからのデータ抽出や、構造化したモックデータ（JSON/CSV）の使用を許可する。

## 4. 提出物規定

以下の成果物を含むリポジトリ構造を出力してください。

### A. ソースコード一式
* プロトタイプとして動作するもの。

### B. `README.md`
* **Prerequisites:** 必要なランタイム、APIキー等。
* **Setup & Installation:** 環境構築手順。
* **Data Pipeline:** データの取り込み・更新手順。
* **Usage:** アプリケーションの操作方法。

### C. `SOLUTION.md` (ピッチ資料)
1.  **解決したい課題:** ユーザーの生活スタイルに即した課題設定。
2.  **課題の解決方法:** アプローチの詳細。
3.  **利用した技術スタック:** 選定理由。
4.  **実運用にあたって必要なランニングコスト:** 概算費用。

### 5. 評価基準

1.  **課題解決の適合性:** リモートワークの夫と外出する家族の「安心」に繋がるか。
2.  **技術的実現性:** 実データ（PDF等）の更新に対応できる設計になっているか。
3.  **エンジニアリング:** データの取得から可視化/通知までのフローが論理的か。
4.  **動物愛護・共存の視点（重要）:**
    * クマを過度に傷つけたり、生態系に悪影響を与える攻撃的な手法（駆除・捕獲前提）ではないこと。
    * 「出会わないための回避」「傷つけずに遠ざける追い払い」など、共存を前提としたソリューションであること。

それっぽい感じのキービジュアルも作ってもらいました。

運営

Geminiが作成した案をベースにコーディングエージェントに投げるプロンプトを以下の通り整理しました。

あなたは高度な技術力を持つソリューションアーキテクト兼エンジニアです。
@HACKATHON.md  の内容に基づき、ハッカソン参加者として以下のタスクを実行してください。

1.  **アイデア出し:** ユーザーの状況と評価基準（特に共存の視点）に合致するソリューションを考案する。
2.  **プロトタイプ実装:** 考案したソリューションのMVP（Minimum Viable Product）を実装する。
3.  **ドキュメント作成:** `README.md` および `SOLUTION.md` を作成する。

**ゴール:** エンジニアであるユーザーが「このアーキテクチャなら運用できる」「技術的に信頼でき、かつ倫理的にも納得できる」と思えるプロダクトを提示すること。

実施にあたっては`solutions` 配下に自身のモデル名のディレクトリを作成し、その配下で作業してください。

今回、コーディングにはCursorを使用しています。 Cursorは2.0からマルチエージェント機能が実装されており、一つのプロンプトで複数のコーディングエージェントに対して指示を出すことができます。 ~~（今回これで遊んでみたかったのが本音だったり・・・）~~

以下みたいな感じで実装を進めてもらっていました。 5つのモデルの中でComposer 1がダントツで早かったです。普段の開発でもよく使うモデルなのですが、とにかく生成速度が早いので軽微な開発タスクはこれで良いなと思ってます。

各モデルの成果物

各モデルが出力した成果物は以下のような感じでした。オープンデータの指定の仕方が良くなかったのか、位置情報を使わないといけないバイアスが強くかかってしまったようで、今回はどのモデルも似通ったソリューションが出力されました。各モデルが出したSolutionを全て説明すると長いので、Geminiにグラレコを生成させています。

Composer 1

Composer 1はBearGuardianという「情報の可視化とリアルタイム監視による予防的安全システム」を開発しました。熊の出現情報をMapに可視化すると同時に、家族のGPS情報と突き合わせをしアラートを飛ばすシステムでした。リテイクなしで一発で終わらせたのはこのモデルとGeminiだけになりました。

Opus 4.5

Opus 4.5は指定した座標や現在地について、目撃情報と突き合わせして安全性を確認するアプリを開発しました。主観にはなりますが、単体で動く完成度としてはこれが一番高かったです。

GPT-5.1 Codex

GPT-5.1 Codexは熊の目撃情報から、出現情報を可視化したHTMLを生成するパイプラインを構築していました。アプリではなくHTML生成のパイプラインというところで他のモデルよりも簡素なソリューションとなっていました。

Gemini 3 Pro

こちらも地図上に熊の目撃情報を可視化するアプリでした・・・ここまで4連チャンで同じソリューションですね。

OpusやCodexと同じようにWebアプリではあるのですが、PlaneなHTMLとVanilla JS、静的ファイルをPythonで更新するというめちゃくちゃ簡素な構成で実装していました。こちらもComposer 1と同じリテイクなしで終わらせていました。

Grok Code

わかってました・・・地図アプリですよね。このアプリだけ、Streamlitでフロントエンドを作成してました。

総評

~~正直似たり寄ったりなソリューションだなという感じですが、~~実装した機能のバリエーションやアプリの完成度でOpusが一番良かったです。

次点はComposer 1でした。 CodexやGemini 3.0もいる中で結構検討したなという感想ですが、この辺りはCursor上で動かしているというアドバンテージが大きい気がしています。（CursorもブログでCursor上でCodexをうまく動かすのにかなり工夫していると言及していました。）

今回はいろんなモデルをサクっと動かしたかったのでCursorを使いましたが、Codex CLIやClaude Codeも使うことで結果は変わりそうだなという気がしています。