AI料理アシスタント開発記～人生2回目のハッカソンにでてみて～
AI料理アシスタント開発記～人生2回目のハッカソンに出てみて～
はじめに
2025年4月26日～27日に開催されたProgate主催のハッカソンに参加し、「AI料理アシスタント」というWebアプリケーションを開発しました！
この記事では、開発の背景から工夫した点、そしてハッカソンを通して得られた学びや反省を共有します。
参加したハッカソン
名称: Progateハッカソン
開催日時: 2025年4月26日（土）～ 4月27日（日）
主催: Progate
参加のきっかけ・目的
正直かなり勢いで参加しました。過去の自分が軽い気持ちで応募していたのですが、蓋を開けてみると大学院入学直後かつ、インターンの選考が嵐のように忙しい時期で、よく乗り切ったなと思っています。
チームについて
野良チームで、最終的に二人のチームになりました。自分はバックエンドを担当しながら、適宜Notionによる情報共有、技術指導等を行いました。チームメイトはWeb開発初心者ながら、某フランス発エンジニア養成機関に合格しており、飲み込みが早く、かつ学習への熱意が半端なかったことを覚えています。
- 自分：バックエンド開発全般、プロジェクトマネジメント、技術指導など
- チームメイト：Web開発初心者（主にフロントエンドを担当）・春から入学
開発したプロダクト：「AI料理アシスタント」
何を解決したのか？
世の中のレシピは自分の今の手持ちの材料を考慮していない
→ レシピに合わせて材料を集める必要があり、美味しいご飯を作るには「買い出し」の段階から考えないといけない。
→ 買い出しには行けない、けれどレシピがないと適当になってしまう
→ 材料の撮影からレシピを生成
料理中にレシピを操作するのに都度手を拭く必要がある
→料理スタート後は全ての操作を音声で行えるようにしました
概要
手持ちの食材をスマートフォンなどで撮影すると、AIが最適なレシピを提案。調理開始後は音声対話によって調理完了までアシストするWebアプリケーションです。リアルタイムな質問応答や調理タイマー機能も搭載し、手が塞がりがちな調理中でも声だけで操作できることを目指しました。
使用技術
- フロントエンド: Next.js (App Router), TypeScript, Tailwind CSS
- 認証・データベース: Supabase
- AI連携: OpenAI API (画像認識, レシピ生成)
- UI設計支援: v0
- その他: Web Speech API, Lottieアニメーション, Lucideアイコン
技術的工夫
エッジでの処理
遅延の解消やOpenAI APIの節約のために、全てをOpenAI APIに渡すのではなく、ある程度はキーワードマッチングにより、エッジで処理するようにしました（タイマー、レシピステップの操作など）。
具体的には、「タイマー開始」「次のステップ」などの基本的な操作コマンドはJavaScriptの文字列マッチングで判定し、複雑な質問や料理に関する相談のみをOpenAI APIに送信するようにしました。これにより、レスポンス速度の向上とコスト削減を両立できました。
コードの保守性
APIルート→各ドメインサービス→DB操作というように、コードの保守性もある程度意識しました。短期間の開発でしたが、将来的な機能拡張を見据えた設計を心がけました。
音声認識の工夫
音声認識についてはエコー問題や誤動作に対応するために、ウェイクワードによる操作を採用しました。「シェフ！○○して！」のように動かすことができます。
ウェイクワード実装では、Web Speech APIの継続的なリスニングによるバッテリー消費を抑えるため、音声検出の間隔を調整し、また料理中の雑音を考慮したマッチング精度の調整を行いました。
AI活用について
コーディング
コーディング補助ツールとしてGitHub CopilotやClineを活用しました。
v0の利用
UIの構成や画面イメージの検討段階ではv0を利用し、プロトタイピングを高速化しました。この部分は主にチームメイトにやってもらいました。AIの便利さ、そして可能性を共有したかったという面もあります。
ドキュメントの生成
ClineにAPIの仕様書やデータベース構造、アプリケーション全体のフローチャートなどをmermaidで生成させ、人間がファクトチェックを行った上で共有しました。余計な学習コストや人間側の推論のコストを節約できました。
ハッカソンでの成果
チームとして「AI料理アシスタント」を期間内にデプロイまで持っていくことができました！
また、後からこっそり聞いたところ全体2位とのことでした！
この結果は、当時としては悔しいよりも圧倒的に嬉しかったのを覚えています。
やってよかったこと
マネジメント面
技術選定
チームメイトの成長を最優先に考え、技術選定において、他プロジェクトでも応用可能な汎用的な経験が得られるように配慮しました（開発効率のためにNext.jsを採用しつつ、初学者が理解しやすい一般的なAPIフェッチの方法を選択）。
タスクの割り振り
開発初期に心理的なハードルを感じやすいが、操作自体は意外と単純なタスクを積極的に割り振りました。GitHubでのコンフリクト解消やVercelへのデプロイ作業など、実際のプロジェクトで必要となるスキルを体験してもらうことを重視しました。
技術面
fetchの利用
今までのNext.js開発ではServer Actionsを使用していましたが、今回はfetchを使った経験を積むことができました。各層での責務の切り分け、関心の分離など、Webアプリケーション開発の基本的な設計思想について改めて考える良い機会となりました。
反省
マネジメント面
介入のしすぎ
自分自身に「教えすぎる癖」があることに気づき、将来マネージャーなどの立場になった際には注意が必要だと学びました。
ハッカソン当日までの2週間ほど、学んでほしいことを次々にNotionにまとめて共有していました。今回はチームメイトが勉強熱心で成長意欲の高いタイプかつ、人の指摘を受け入れやすいタイプだったためいい方向に作用しましたが、将来的にこのような介入をプレッシャーに感じるメンバーがいた場合を考えると、情報共有そのものにもより配慮が必要なのかもしれないという気づきがありました。
今後は、相手の学習スタイルやペースをより注意深く観察し、必要な時に必要な分だけサポートする姿勢を心がけたいと思います。
技術面
アーキテクチャ
ハッカソンという特性上、優先度は下げましたが、UI → APIフェッチ → APIルート → 各ドメインサービス → DBアクセス or 他社API呼び出しという構成にしたものの、明確な設計指針を立てられませんでした。今後の学習のためにも、「このアーキテクチャで行こう」と名前のある設計パターンを採用し、それになるべく沿うように開発できたらもっとよかったなと思います。
音声認識
ユーザーの入力に常時反応する理想形には至らず、ウェイクワードでの起動に留まりました。料理中という性質上、騒音が多いため現状の設計が最適である可能性はありますが、より自然な音声インタラクションの実現は今後の課題です。
モバイル音声処理
主要ユースケースであるスマートフォン環境で、音声処理が期待通りに動作しませんでした。おそらく、特定の動作がブラウザに依存していることが原因だと考えています。
PWAと音声処理
当初想定していたPWAの実装が完了しませんでした。音声処理機能との両立については、さらなる技術調査が必要だと考えています。
発表でのアピール不足と評価軸の意識
今回の大きな反省点として、最後の発表で「技術的な工夫」が評価軸に入っていたにも関わらず、そこを十分にアピールしきれなかったことがあります。特に、音声周りの処理やOpenAI API連携の部分では、それなりに工夫を凝らしたにも関わらず、発表では触れませんでした。
以下の記事でも触れられているように、ハッカソンで勝つために評価軸は絶対に意識すべきであると痛感しました。
技術的工夫をもっと前面に押し出し、実装の難しさや工夫した点を具体的にアピールできていれば、さらに良い結果に繋がったかもしれません。
今後の展望
この経験を活かし、以下の点について取り組んでいきたいと考えています：
技術的改善
- PWA対応によるネイティブアプリのような操作性の実現
- モバイル環境での音声処理の最適化
- より自然な音声対話の実装
プロダクト改善
- ユーザビリティテストによる使いやすさの向上
- レシピ提案精度の改善
- 栄養情報の表示機能追加
おわりに
今回のハッカソンは、2位という結果ももちろん嬉しかったですが、それ以上に技術的な挑戦、チームマネジメント、そしてコンペの戦い方といった面で多くの学びがある貴重な経験となりました。
特に「教えすぎる癖」という自分自身の課題や、「評価軸を意識したアピールの重要性」に気づけたのは大きな収穫です。
反省点として挙げたPWAの実装や音声認識の改善など、今後もこのプロダクトを育てていけたら面白いなと思っています！
関連リンク
GitHubリポジトリ
公開URL
Topazプロジェクトページ
この記事が、これからハッカソンに参加する方や、AI・音声技術を使った開発に興味がある方の参考になれば幸いです！
Discussion