GIFTech ハッカソン2025春に参加した

GIFTech ハッカソン2025春に参加した

ハッカソンの概要としては、「プロの"エンターテイナー"と共に、生成AIで創作の可能性を広げるプロダクトを開発」することでした。

https://giftech.io/giftech2025spring/

参加目的としては、アプリケーションにおける生成AIの使い所を把握したいと思ったからです。

AIをエージェントとして使ってはいるものの、プロダクトに組み込んだことはなく、どういう用途で組み込めるのかという観点に興味を持っていました。

ハッカソンの流れ

1. プロダクト作成全般に関する講座を受ける

MVP設計のワークショップやデザインの講座などで、印象に残ったのは、MVP設計のワークショップです。

最初に動画にて、エンターテイナーさんから、欲しいプロダクトに対するざっくりとした要望を聞いてイメージを膨らませていきます。

その後、MVP設計のワークショップで、各エンターテイナーの課題を解決するためのサンプルのステップが紹介されました。

その際に、AI生成漫画アプリの「コミ単」というプロダクトの開発事例を踏まえつつ話が進んでいきました。

https://giftech.io/comitan/

生成AIを利用する線引きを明確にするのは大事だなと聞きながら思いました。

2. チームで担当させてもらうエンターテイナーを決める

各チームごとに生成AIを組み込んだプロダクトを提供させてもらうエンターテイナーを決めていきます。

私たちのチームは、漫才芸人のにぼしいわしさんを担当させていただくことになりました。

THE W 2024年で優勝された漫才芸人の方です。

https://niboshiiwashi.localinfo.jp/

これはTHE W決勝1本目のネタ「CHANNEL」ですが、面白いのでよかったら。

https://www.youtube.com/watch?v=dbDayb8urpA

3. エンターテイナーの課題をチームで深掘り

ここが一番時間を要しました。

まず、そもそも課題はなんだろうというところで議論が紛糾します。

議論が紛糾しては、にぼしいわしさんにもヒアリングを行い課題の深掘りを行うサイクルを回していきました。

ただ、ここは一番重要な部分ではあるので時間をかける妥当性はあったかなと思います。

私のチームは、課題が最も抽象的だったので。漫才というまだDXの余地が大きい性質もあると思います。

1ヶ月のうち、約1.5週間くらい時間をかけた覚えがあります。

最終的に、漫才の素材を提供するプロダクトというコンセプトに決まりました。

4. 作るプロダクトの方向性を決める

課題の深掘り後は、優先順位を決めてプロダクトで何を実現するのかを決めていきました。

何を捨てるのか、どういう機能を実装するのか、など...

チームメンバー1人ずつ思い思いの機能を考えてFigmaでプロトタイプを作り、にぼしいわしさんに反応を伺いながら取捨選択していきました。

欲を言えば、もう少しフィードバックサイクルを回したかったです。

5. 実際に開発

1ヶ月という期間、さらに課題の深掘りに時間を要したので、開発の時間はほとんどなかったです。

私は、主にインフラ構築とバックエンドの一部を開発していました。

SupabaseでのDB構築、Cloud Runへのコンテナデプロイ、Vercelへのホスティング、ローカルコンテナ化、HonoのBEでエンドポイントを生やしたり、など...

Jiraでチケット管理しつつ進めていきました。

6. ユーザー体験会

ユーザー体験会当日は、にぼしいわしさんが私たちのプロダクトを使って作ってもらったネタを披露する時間がありました。

個人的には面白いネタが出来上がっていて、会場からも笑いが起きていたので、満足したのを覚えています。

自分たちが作ったプロダクトで漫才を作ってもらうという体験は、今後もなかなかできない貴重な体験ができました。

最優秀賞は獲得できなかったのですが、エンターテイナーの方に価値を感じてもらうプロダクトは作れたと思います。

実際に作成したプロダクトの紹介ページ

https://turquoise-mitten-3bc.notion.site/AI-1e077f38346280f3897afd1767326615#1e077f38346280dfa578f215c3d35c71

Good & More

Good

1. にぼしいわしさんの課題解決にフォーカスできたこと

ユーザー体験会で一般の方に触っていただく機会があったので、にぼしいわしさん向けに尖らせるかどうかは議論しましたが、結局エンターテイナーの課題解決が重要なので、尖らせる決断をしました。

結果として、一般ユーザーには分かりづらいプロダクトになったと思います(笑)

ただ、にぼしいわしさんにはちゃんと使っていただいており、「段は1日2日は必ずかかるネタ作りが、2時間かからずに1本できた」という声をいただきました。

結果として、解くべき課題には明確にアプローチできたと思っています。

ユーザーからの評価も加味してプロダクトを作っていたら、ここまで尖っておらず誰にも刺さらなかったと思っています。

そうそう、当日の内容がニュースになったんですよね。

https://news.yahoo.co.jp/articles/551a71dbecac85f66e1d8810065b8e79a42ee900

2. 誰一人欠けずにやり切る雰囲気の醸成ができていたこと

私のチームは皆さん個性的でしたが、しっかりまとまって最後までやり切れました。

要因としては、初対面の後に居酒屋で互いに変なあだ名をつけたことがきっかけだったように思います。

初対面であだ名を付け合うことになろうとは(笑)

結果として、砕けたコミュニケーションができるようになったり、励ましあったり、モチベーションを高めたりと"チーム"として最後までやり切れる基盤が醸成されていたように思います。

3. AIのチューニングを尖らせたこと

今回のプロダクトでは生成AIが面白い返しをしてくれるところがコンセプトです。

生成AIのレスポンスなんて漫才に使えるほどの面白さはないだろうと自分は思っていたのですが、今の生成AIはすごいですね、ちゃんと面白い返しをしてくれます。

チームメンバーが、そのレスポンスの精度を高めてくれて、機能として出せるレベルの品質に持っていけました。

にぼしいわしさんに刺さったのはこのチューニングのおかげだと思います。

4. サーバーをモックして最初にFE側でMVPを作れたこと

サーバー実装を待っていたら到底間に合わないので、サーバーのレスポンスをモックしてFE実装を進めました。

その過程で、私の方でVercelにFEだけホスティングしておき、FEの変更があれば自動でデプロイをかけるようにCIを調整しました。

FE実装を進めながらフィードバックをもらいながら細かい調整をしつつ、BEを追従させる動きはMVP的に動くものを作って認識をそろえる上で有効でした。

この短い期間の動きとしてはベストだったのではないかと考えています。

More

1. UXが分かりづらいこと

やはりにぼしいわしさんに特化したことで、一般の方には分かりづらいプロダクトになっています。

ウェイトは分かりませんが、一般の方からのプロダクトに対する人気投票も採点基準の一つでした。

漫才の素材を提供するプロダクトなので、ネタづくりをしたことがない方にはイマイチ刺さりづらいと思っています。

漫才の作り方って大まかなイメージはあるものの、言語化が難しい要素が多いので、一度体験したことがないと価値を見出しづらいのだと思います。

その分他のチームは作り方のフローが体系化しやすく、プロダクトの体験も一方向であるため、分かりやすさはあったように思います。

ただ、私たちのチームは不要に機能を設けすぎた印象はあります。

AIレスポンスの精度はかなり高い水準にまで持っていけていたので、そこの見せ方次第だったなと思っています。

一般の方から「ネタってどうやって作るんですか?」という質問をいただいたので、そう見えているんだなと思いました。

そこはトレードオフだったので仕方のない部分ではありますが、インプットに対してアウトプットの流れを分かりやすくすることはできたのかなとは思います。

2. UIをもう少しユーザーフレンドリーにできたこと

メイン機能として、インプットに対してAIからのアウトプットがマインドマップのように広がっていくUIを採用しています。

このプロダクトでは"ネットワークUI"という呼称をしています。ネットワークのようにアイディアが広がる様を表現しています。

このUIはアイディアの広がりを無数に生み出せる一方、何を元にアイディアが生まれたのか逆探知がしづらくなります。

つまり、使い込めば使い込むほど、ユーザー自身でアイディアに至るストーリーを想起するのが難しくなります。

1つのインプットには1つのアウトプットが出て、それに至るプロセスが宣言的であれば、ユーザー自身でストーリーを想起しやすい状態になります。

3. サーバーを2つに分けてしまったこと

これは開発プロセスの話ですが、今回AIといってもAPIコールしているだけなので全部一つのサーバーに載せて良かったなとは思いました。

AI用のサーバーをPythonで動かしていて、BEサーバーはHonoです。

チューニングなどもあるし、AI用の処理は分けて開発しようというチームの意思決定でしたが、途中でAPIコールしているだけだなと気づき直した時にはすでに遅し。

ここのデプロイや開発の進め方で認識齟齬が生まれてしまっていたので、明確に改善の余地はありました。

おわりに

1ヶ月という短い期間でしたが、意見の衝突があったり、協力して機能を作ったり、遅くまでMTGで話したりと色濃い期間を過ごしてきました。

一般的にハッカソンって途中離脱される方も多いと思いますが、私のチームは誰1人欠けることなく最後まで価値提供をしてくれていたと思っています。

変なあだ名をつけるという謎ムーブがありましたが、チームビルディングだなあという懐かしい気持ちを思い出しました。

同じチームメンバーの皆さんには本当に感謝をしています。