2026年8月14日から16日に開催された「AIAU Craft Day」に、2人チームで参加した。
AIAU Craft Dayは、AIエージェントユーザー会（AIAU）が主催した3日間のオフラインハッカソンだ。CognitionのAIコーディングエージェント「Devin」と、Postgresを中心に認証、Storage、Realtimeなどをまとめて使える「Supabase」がスポンサーになっており、3日間で動くプロダクトを形にする。
三日間開発し続ける…！！
— オータニ@AI駆動開発 (@otani_ai_memo) August 14, 2026
#AIAUCraftDay pic.twitter.com/kJ1bwz22Ef
最終日は事前選考を通過した10チームがファイナルで発表する形式だった。
私たちが作ったのは、EC販売者向けの画像加工PoC「matuge-change」。実際のつけまつげの商品画像をできるだけ維持したまま、着用している人物だけをAIモデルへ変える仕組みだ。
結果はファイナルまで残ったものの、受賞には届かなかった。
3.team-matuge
— オータニ@AI駆動開発 (@otani_ai_memo) August 16, 2026
撮影した写真からツケまつ毛を反映したイメージ画像から瞬き動画まで作れる販売員向けツール
あえてAI生成を使わず画像解析ロジックにする事で本当の反映イメージを作ってる👀
#AIAUCraftDay pic.twitter.com/Vu6h0NAZhT
振り返ると、技術そのものよりも「何が難しいのか」を伝え切れなかったこと、UIを複雑に見せてしまったこと、そして本番デモで失敗したことが大きかったと思う。
出発点は、つけまつげを実際に売っている人の困りごとだった
今回のチームは私と、ECショップでつけまつげを専門に販売しているもう1名の2人だった。
アイデアの出発点は、そのメンバーが普段の商品販売で感じていた問題にある。
つけまつげは、商品単体の写真だけでは着用したときの印象が伝わりにくい。
毛の長さや束感、カール、目尻側の広がりは、実際に目元へ付けて初めて分かる部分が大きい。そのため、ECの商品ページでも着用画像や動画を用意したい。
ところが、それを継続して作るのが難しい。
目元の撮影ができるモデルへ依頼すれば費用がかかる。一般のモデルを探す場合も、日程調整、撮影場所、照明、撮影そのものの手間が発生する。
商品をモデルへ送り、自宅で撮ってもらう方法もある。この場合は費用を下げられるが、今度は照明、顔の角度、カメラとの距離、ピントなどが人によってばらつく。
商品が増えるたびに、同じ問題が繰り返される。
そこで考えたのが、
「販売者自身が商品を着けてスマートフォンで撮影し、人だけ生成AIでモデルに変えればよいのではないか」
という方法だった。
生成AIは人だけでなく、商品まで描き直してしまった
実際に試すと、人をAIモデルへ変えること自体は難しくなかった。
問題は目元だった。
「つけまつげは変更せず、人物だけ変えてください」と指示しても、生成後の画像ではまつげの長さ、毛束の数、密度、カールなどが変わることがある。
見た目は自然でも、元の商品とは別物になってしまう。
普通の人物画像なら、それでも問題にならないかもしれない。しかしECの商品画像では困る。
購入者が見ているのは「それらしいつけまつげ」ではなく、実際に販売されている商品だからだ。
この問題を説明すると、ファイナルでも「AIを使えばすぐできるのでは」という趣旨の質問を受けた。
この質問自体が、私たちの説明不足をよく表していたと思う。
AIで「つけまつげを着けたモデル画像」を作るのは難しくない。
今回やりたかったのは、特定の商品を着けた実写を基準にして、その商品の特徴をできるだけ変えずに人物だけを差し替えることだった。
この違いを、短いプレゼンの中でうまく伝えられなかった。
商品を生成AIの処理対象から外すことにした
matuge-changeでは、生成AIに商品を正確に描かせる方向を取らなかった。
元画像に写っているつけまつげを画像処理で抽出・保持し、人物をAIモデルへ変更した後で商品側を戻す。
静止画では、MediaPipeで目元の位置を取り、OpenCVで位置合わせを行う。そのうえで、装着前後の差分やエッジなどから商品候補を推定し、PyMattingを使ったAlpha Mattingで細いまつげを半透明情報ごと抜き出すようにした。
自動抽出が完全に当たるわけではないので、人が「商品」「背景」「判断を任せる領域」をブラシで補正できるUIも用意した。
動画は別方式にした。
フレームごとに細い毛を切り抜くとちらつきやすい。そのため、元動画の目元領域そのものを残し、AI加工した人物画像のほうを元動画へ合わせる。
まばたきも元動画側に残るので、商品を無理に変形して追従させなくてよい。
ここがmatuge-changeで一番時間を使った部分だった。
Devinは「自分のPCの外にいる開発者」として使いやすかった
実装にはDevinをかなり使った。
画像処理のコードだけでなく、FastAPIのAPI、フロントエンド、テストなどもタスクを分けて依頼した。
リポジトリに残した記録では、約1.5日の開発で66コミット、17PR。そのうち16本が devin/* ブランチだった。
完成した仕様を渡して一気に作らせるというより、1セッション1トピック程度に区切り、結果を見て次の指示を出す使い方が多かった。
特に気に入ったのは、Webから依頼したときの作業環境だ。
Devinの公式ドキュメントでは、Devinが作業する環境はLinuxベースの仮想マシンと説明されている。リポジトリや依存関係を用意した環境はスナップショットとして保存され、各セッションはそこから起動する。
Webからタスクを渡すと、Devinの専用ワークスペースでリポジトリを触り、依存関係を入れ、テストやブラウザ確認まで進められる。組み込みのShell、IDE、Browserも用意されている。
ローカルPC上でAIエージェントを動かす方式とは、少し使い勝手が違った。
3日間のハッカソンでは、この分離がかなり楽だった。自分のPCでは別の作業をしながら、Devinには別タスクを進めてもらえる。
一方、設計まで丸ごと任せればよいとは感じなかった。
今回のテーマでは、「まつげをどう切り抜くか」より先に、「どこまで生成AIに触らせるか」を決める必要があった。
動画についても、全フレームでAlpha Mattingする案、1枚のまつげ画像を追従させる案、目元全体を元動画から残す案を比較した。
こうした境界の判断は、人間側で目的を持っていないと決めにくい。
Devinは実装速度を上げてくれたが、何を作るべきかまで自動で決まるわけではなかった。
Supabaseは使った。ただ、Supabaseでなければ成立しない作品ではなかった
Supabaseでは、抽出した商品のメタデータと画像の保存、Matting処理のジョブ管理、Realtimeによる進捗通知、補正用ブラシデータの保存などを実装した。
pgvectorを使った、つけまつげ形状の類似検索も試している。
機能としてはかなり使ったと思う。
ただ、今回のプロダクトの中心は画像処理だった。
商品を保持したまま人物を差し替えるという価値は、Supabaseがなくても成立する。
実際、リポジトリもSupabaseを設定していない場合はローカルのJSONやPNG、インメモリ処理へ切り替わるように作っている。
これはソフトウェア設計としては扱いやすい。
ハッカソンの審査という意味では、「Supabaseである必然性が薄い」ことの裏返しでもあった。
AIAU Craft Dayでは「Supabase・Devinを効果的に使えているか」が100点中25点の審査項目だった。
そこを考えると、Supabaseを使った機能数ではなく、
「なぜこのプロダクトにSupabaseが必要なのか」
まで設計できていなかったのは弱かった。
ハッカソン後に振り返ると、かなり分かりやすい反省点だ。
ファイナルには残ったが、見せ方でかなり損をした
事前選考を通過してファイナル10チームには残ったが、受賞はできなかった。
敗因は一つではないと思う。
少なくとも、自分たちで明確に失敗したと感じている点がある。
まずUIだ。
開発中は画像処理の状態を確認する必要があったため、ROI、マスク、Alpha、ブラシ補正、位置合わせなど、多くの操作を画面へ出していた。
作っている側には必要な機能だったが、初めて見る人には「操作が多くて難しそうなツール」に見えたと思う。
本来伝えたかった体験はもっと単純だった。
商品を着けて撮る。
人物をAIで加工する。
元の商品を戻す。
それなのに、発表では内部の調整機能まで前面に見せてしまった。
本番のデモでも失敗した。
短い発表の中で、最も見せたかった処理をスムーズに通せなかった。UIが複雑に見える状態でデモまで崩れたので、「これは何を解決するものなのか」という理解に時間を使わせてしまった。
そこで「AIですぐできそう」という質問が来た。
技術的に反論することはできる。
でも、発表を聞いた人がそう感じた時点で、プレゼンとしては負けている。
「生成AIでは商品そのものが変わる」という比較画像を最初に見せ、その一点から説明を始めるべきだった。
「UIが複雑」というフィードバックを受け、後から簡易モードを作った
ハッカソン後、UIについてのフィードバックを受けて静止画画面を作り直した。
現在の版では、最初に見える入力は「装着画像」と「AI加工済み画像」の2つだけだ。
2枚を選んで「処理を実行」を押せば、目元検出、まつげ抽出、合成までをまとめて実行する。
途中のAlphaやTrimapを触りたい人だけ「詳細調整」を開く。
内部でやっている画像処理はほぼ同じでも、利用者が最初に理解しなければならないことはかなり減った。
これはファイナルで指摘されなければ、後回しにしていたと思う。
ハッカソン中は「動くものを作る」ことに意識が向き、開発者向けの確認画面と利用者向けの画面を分けられていなかった。
技術的な機能を増やすことと、プロダクトとして分かりやすくすることは別だった。
AIエージェントで、ハッカソンの空気まで変わった
今回、一番驚いたのは作品の技術ではなく、最終日の会場の雰囲気だった。
私が見た限り、参加チームはどこも何かしら動くものを完成させていた。そして最終日なのに、みんな顔色がよかった。
私はAIが普及する以前にも、ゲームジャムやハッカソンへ参加したことがある。
当時は、締め切りが近づくにつれて徹夜組が増え、最終日の発表前になると疲れた参加者が黙々とキーボードを叩いている。会話も減りどこか殺伐とした空気になる。
それも含めてハッカソンだと思っていた。
AIAU Craft Dayは、かなり違った。
DevinのようなAIエージェントに実装を任せている間、人間には少し時間ができる。その時間に別の設計を考えたり、他のチームの人と話したりできる。
会場を見ても「コードを書き終わらない」という焦りより、「こんなものを作っています」「そこはどうやったんですか」と話している時間が多かったように感じた。
3日間の開発イベントなのに、最後まで和気あいあいとした雰囲気だったのが印象に残っている。
参加者の幅も広かった。
会場には小学6年生や中学生、高校生の参加者もいた。
特に印象に残ったのが、小学生の参加者が作っていた「昨日の自分と戦う」ゲームだ。自分の過去の記録を相手にして、昨日の自分を超えていく。
アイデアもよかったし、それを実際に遊べるところまで形にしていた。
以前なら「プログラミングを覚えてから作る」必要があったものが、今は「作りたいものがある」ことを出発点にできるようになりつつある。
もちろん、AIエージェントがあれば誰でも良いプロダクトを作れる、という話ではない。
今回の私たち自身がそうだった。
動くところまでは短期間で持っていけた。一方で、UIの設計や課題の伝え方、デモ、Supabaseを使う必然性といった部分では課題を残した。
コードを書くハードルが下がるほど、何を作るのか、誰の問題を解くのか、どう見せるのかの比重は大きくなる。
それでも、年齢やプログラミング経験にかかわらず、アイデアを「動くもの」まで持っていける人が増えていることは、今回かなり実感した。
「開発の民主化」という言葉は以前からある。
AIAU Craft Dayでは、それを言葉ではなく、会場の風景として見た気がした。
【御礼＆結果発表】
— AIエージェントユーザー会(AIAU) (@ai_agent_ug) August 16, 2026
3日間のハッカソン「AIAU Craft Day」が無事終了しました！
Devin×Supabaseを駆使した熱い開発と挑戦、皆様本当にありがとうございました！🎉#AIAUCraftDay @supabase @DevinAI @cognition @madyagi @dshukertjr pic.twitter.com/UxCoEB4mE4