週末でデモできるハッカソン・プロジェクト案20選

最良のハッカソン案は、ひとりの特定の人の、ひとつの具体的な課題を解決するものです。3分以内にライブで動くところまで見せられるものが理想です。通常は、メインの流れが一つだけあるWebアプリになります。フォーム、簡単なロジックやAPI呼び出し、画面上の明確な結果、という構成です。以下では、よくあるハッカソンのテーマごとに20のアイデアを紹介します。それぞれに、対象ユーザー、24〜48時間で作るデモ、イベント後にビジネスになりうる点、正直な難しさを書きました。一つ選んで小さくし、イベントの最後の4分の1はデモに使ってください。

イベント後も続けられるアイデアが欲しい場合は、AIで作れる副業プロジェクトのアイデアやAIスタートアップのアイデアが役立ちます。このリストは週末で作ることを前提にしています。

イベントに合うアイデアを選ぶ

テーマに関わらず、まずイベントのルールと審査基準を確認してください。それらは、テーマ以上に重要です。

コミュニティと市民

1. キャンパスや会場の落とし物掲示板

• 対象: 学生、フェスの来場者、ジムの会員。
• デモ: 写真と場所付きで拾った物を投稿し、カテゴリで検索。「これは自分の物です」と申し出ると、拾った人に通知が届く流れを見せる。
• その後: 会場がブランド付きの掲示板に料金を払う可能性がある。多くは無料サービスとして見られるでしょう。
• 難しい点: 虚偽の申し出を防ぐこと。持ち主しか答えられない質問（「スマホケースの色は？」など）を入れると、デモで分かりやすい見せ場になります。

2. ボランティアのシフトマッチャー

• 対象: 紙の当番表を使っている食料支援団体、シェルター、慈善団体。
• デモ: 運営者が枠付きのシフトを作成し、ボランティアがスマホで申し込み、ダッシュボードで空き枠を表示。スケジュール用ビルダーが基本部分をカバーします。
• 難しい点: 実際の団体に見てもらうこと。ピッチには、見積もりか、実際の紙の当番表の写真を持っていきましょう。

3. ひとつの町のバリアフリー施設マップ

• 対象: 車いすの方、ベビーカーの親、感覚過敏のある方。
• デモ: 段差のない入口、バリアフリートイレ、静かな時間帯のある場所をマップで表示し、場所を追加・修正するフォームを用意。
• 難しい点: 信頼できるデータ。各情報の出典と最終確認日を表示しましょう。

4. 市議会の決定をわかりやすく

• 対象: 議事録を読まない住民。
• デモ: 公開されている議題を貼り付けるかアップロードすると、何が、いつ決まるのかを短く平易に要約。「このテーマをフォロー」ボタン付き。
• 難しい点: 正確さ。元の文章を要約の横に表示し、誰でも確認できるようにしましょう。

教育

5. 1つの授業の勉強会ファインダー

• 対象: 大人数の授業で知り合いがいない学生。
• デモ: 授業と空いている時間を選ぶと、合う勉強会が表示され、参加できる。ディレクトリ用ビルダーが良い土台になります。
• 難しい点: 安全性とプライバシー。ログインは大学のメールアドレスを使い、個人の電話番号は表示しないこと。

6. 即時採点つきの過去問練習

• 対象: 特定の試験に向けて復習する学生。
• デモ: 分野別の択一問題、即時のフィードバック、苦手分野のグラフ。クイズアプリの作り方もご覧ください。
• その後: 問題数を増やす有料プランが成り立つ可能性がある。ただし、問題は自分で作ること。
• 難しい点: 著作権。自分で作った問題か、試験団体が使用を認めている問題を使いましょう。

7. 授業の終わりの理解度チェックツール

• 対象: 授業の最後に「理解できたか」をすばやく確認したい教師。
• デモ: 教師が2問のチェックを作成し、生徒はコードを使ってスマホで回答。教師は数秒で集計を確認する。
• 難しい点: 実際の教室で使えること。13歳未満はログイン不要にし、学校のWi-Fiが不安定でも速く動くこと。

8. 読解レベル変換ツール

• 対象: 年齢より読解力が低い、または高い子どもを持つ教師や保護者。
• デモ: 文章を貼り付け、読解レベルを選ぶと、AIモデルが書き直し、難しい語に定義を付けて強調表示する。
• 難しい点: 意味を正しく保つこと。元の文章と書き直し版を並べて表示し、教師が編集できるようにしましょう。

気候とサステナビリティ

9. 修理カフェの予約と記録

• 対象: 地域の修理イベント。
• デモ: 来場者が物の修理枠を予約し、ボランティアが修理内容を記録。ページには、ごみとして捨てずに済んだ物の数が集計される。イベント用ビルダーが合います。
• 難しい点: 誠実な影響データ。修理した件数を数え、根拠のないCO2の数字は作らないこと。

10. オフィスや学校のエネルギーダッシュボード

• 対象: 施設管理の担当者とエコ委員会。
• デモ: メーターの検針データ（またはサンプルファイル）をアップロードし、日別・部屋別の使用量を表示、急増を知らせる。出発点はダッシュボード用ビルダーです。
• 難しい点: 実データ。ライブのメーターが用意できない場合はそう伝え、明確にサンプルと分かる形でデモしましょう。

11. 建物内の余った食べ物のシェア

• 対象: オフィス、学生寮、地域のフードシェア冷蔵庫。
• デモ: 余った食べ物を写真と受け取り時間付きで投稿し、通知を受け取って取り置きを申し込む。期限切れの品は自動で非表示になる。
• 難しい点: 食品衛生のルール。密封された食品、またはラベルがはっきりした食品だけに限定し、短いガイドラインのページを用意しましょう。

健康とアクセシビリティ

このテーマは慎重に扱ってください。ハッカソンのデモで診断や医療アドバイスをしてはいけませんし、実際の患者データを使ってもいけません。

12. 介護者向けの服薬リマインダー

• 対象: 複数の薬を服用する親や子どもの介護をしている人。
• デモ: 薬と時間を登録してリマインダーを受け取り、服用を記録する。兄弟姉妹と読み取り専用の表示を共有する。
• 難しい点: 信頼性。リマインダーを逃すことは重大です。ピッチでは、デモは医療機器ではないと正直に伝えましょう。

13. クリニックの待合室キュー

• 対象: 予約なしで受診するクリニック、薬局、相談窓口。
• デモ: コードを読み取って列に並び、自分の順番を確認。順番が近づくとメッセージが届く。
• 難しい点: スマホを持たない人。スタッフが手動で人を追加する方法も見せましょう。

14. ひとつの問題に絞ったWebアクセシビリティチェッカー

• 対象: 小規模サイトのオーナー。
• デモ: URLを入力し、一つの項目をしっかり確認する（画像の代替テキストがない、色のコントラストが低い など）。修正方法も表示する。
• 難しい点: 広く浅くより、一つを深く。きちんとした一つのチェックは、浅い20のチェックより価値があります。Webサイトをアクセシブルにする方法に基本がまとまっています。

開発者ツール

15. 例からAPIレスポンスを返すモックサーバー

• 対象: バックエンドの完成を待つフロントエンド開発者。
• デモ: JSONのレスポンス例を貼り付けると、それを返すライブURLが得られる。任意で遅延やエラーも設定できる。
• その後: 同じことができるツールは多くあるため、ビジネスというより学習用のプロジェクトになりやすい。
• 難しい点: 差別化。例から現実的な架空データを生成するなど、一つ独自の工夫を入れましょう。

16. 非エンジニア向けのプルリクエスト要約

• 対象: 今週何が変わったかを知りたいプロダクトマネージャー。
• デモ: 公開リポジトリを接続（または差分を貼り付け）すると、機能ごとにまとめた平易な変更要約が得られる。GitHubとはで基本を解説しています。
• 難しい点: 権限。デモでは公開リポジトリを使い、アクセストークンをフロントエンドに絶対に貼り付けないこと。

17. 環境変数チェッカー

• 対象: 設定の不足でデプロイを壊してしまうチーム。
• デモ: 設定例のファイルと実際の設定ファイル（値は非表示）を比較し、不足している項目と使われていない項目を表示する。
• 難しい点: 秘密の値を決して表示しないこと。APIキーを安全に保つ方法で理由を説明しています。

AIとAPIのプロジェクト

人気のテーマなので、基準は高めです。モデルの上にチャットボックスを置くだけでは不十分です。特定の仕事をより良くこなす様子を見せてください。

18. レシート割り勘アプリ

• 対象: レストランの会計を分けたい友人たち。
• デモ: レシートを写真に撮ると、アプリが品目を読み取り、各自が自分の注文をタップ。誰がいくら払うかを表示する。
• 難しい点: 読みにくいレシートの読み取り。誤りをすばやく修正できるようにしましょう。それもデモの一部です。

19. 議事メモからアクションリストへ

• 対象: 学生団体や小規模チーム。
• デモ: メモや文字起こしを貼り付けると、担当者と期限付きのアクションが生成され、それぞれの担当者に送信される。
• 難しい点: 担当者の取り違えや、存在しない期限の捏造。各アクションの元になった文を表示しましょう。

20. 音声入力のフォーム入力アプリ

• 対象: 長いフォームが苦手な人。高齢のユーザー、ディスレクシアや弱視のある人など。
• デモ: フォームの質問に一問ずつ声で答えると、アプリが項目を埋め、確認のために読み上げる。
• 難しい点: 同意を適切に取ること。最終的に人間が確認するまで、決して送信しないこと。

AIのアイデアには、APIキーが必要で、リクエストには費用がかかります。LLM APIの使い方で、キー、費用、制限を説明しています。

勝つ（少なくとも完走する）ためのコツ

1. まずデモの台本を書く。 3文で十分です。ユーザーが誰か、何をするか、何が見えるか。台本に必要なものだけを作ります。
2. 折り返し地点までにメインの流れを動かす。 ログイン、フォーム、データベースといった地味な部分には、テンプレート、スターターキット、AIアプリビルダーを使いましょう。Mythexのようなツールを使えば、データベース付きの動くWebアプリを作ってリンクで公開できるため、チームは独自の見せ場に時間を使えます。イベントのルールでツールが使えるか、先に確認してください。
3. 現実的なサンプルデータを使う。 信じられるデータが10件あるだけで、デモは本物らしく見えます。「test test 123」では伝わりません。
4. バックアップの動画を録る。 ハッカソンではWi-Fiが途切れます。2分の録画があればピッチを救えます。
5. 実在の人の課題を見せる。 話を聞いた人の言葉、あるいは置き換えようとしている紙の手続きの写真を見せましょう。
6. 制限については正直に。 「これはサンプルデータです」と言う方が、審査員に見抜かれる主張よりも信頼されます。

週末でMVPを作る方法で、範囲を絞る方法を詳しく解説しています。イベント後にプロジェクトが軌道に乗ったら、アプリのアイデアを検証する方法が次のステップです。

よくある質問