推しアイデア
オーナーとして「自分の作物」を「農家ともに育てる」体験設計がイチ推しです！ 既存サービスが「ただ買って届ける」のに対し、大きな負担なく農業を体験できることが差別化になっています！ さらに、オーナーの所有欲・承認欲求をあおるUXにもご注目ください！
AgriOwner
農家と消費者をつなぐ体験型オーナー制度プラットフォーム
作った背景
僕のおじいちゃん（農家）は、「農業したい人が気軽に始められない」ことに悩んできました。実際、幅広い年代で「農業したい」と思う人は存在します。 AgriOwnerを使うことで、先払いオーナー制度で農家の収益を安定させて障壁を低くし、体験を通じて消費者との距離を縮められると考えます！
推し技術
Gemini APIのマルチモーダル機能で作物写真を解析し、AIによる成長日記文の生成も可能に。データはSupabaseので管理し、Next.js App RouterのServer Componentsで高速表示。GitHub ActionsでCI/CDも構築。
プロジェクト詳細
AgriOwner（体験型農業オーナープラットフォーム）
「農家と、共に育てる。」 買うのではなく、育てて、収穫する。農家と消費者をつなぐ体験型オーナー制度プラットフォーム。
新しく農業を始めたい農家が抱える「育成期間中に収益が得られない」「消費者との距離が遠い」という課題と、消費者が持つ「農業体験をしたい」「特別な所有体験がほしい」というニーズを、オーナー制度という仕組みで同時に解決します。
チーム開発・役割分担
- 開発チーム（フロント・バック）
- 非開発チーム（ドキュメント作成）
このアプリでできること
農家側
- オーナー枠の登録・管理（作物・枠数・価格・期間を自由に設定）
- 育成日誌の投稿（写真・テキスト）
- Gemini APIによる成長日記文の自動生成
- オーナーからの「いいね」をタイムラインで確認
消費者（オーナー）側
- 農家が出品したオーナー枠を一覧から選んで登録
- マイページで自分の作物をカード形式で管理
- タイムラインで農家の最新投稿を確認・いいね
ターゲットと解決する課題
農家（生産者側）
ターゲット： 新しく農業を始めたい人・就農したての農家
| 課題・悩み | AgriOwnerによる解決 |
|---|---|
| 農業を始めたくても、収穫まで収入がゼロで生活が成り立たない | 先払いのオーナー制度により、育成期間中にも収益を確保できる |
| 販路がなく、最初の消費者をどう獲得すればいいかわからない | プラットフォームに登録するだけで消費者と直接つながれる |
| 消費者の顔が見えず、誰に向けて作っているかわからない | オーナーが農地に定期的に訪れることで、顔の見える関係が生まれる |
| 育成作業を一人でこなすのが大変 | オーナーが訪問時に作業参加できる仕組みがある |
消費者（オーナー側）
ターゲット： 承認欲求が強めで、特別な体験や所有感を求める富裕層
| 要望・ニーズ | AgriOwnerによる解決 |
|---|---|
| 「自分だけの特別なもの」を所有したい | 特定の農家の特定の作物を「自分のもの」としてオーナー登録できる |
| 体験や経験にお金を使いたい | 育成期間中の農地訪問・自分の手での収穫という非日常体験を提供 |
| SNSで映える・シェアできるコンテンツがほしい | AIが自動生成するオーナー証明書でSNSシェアを促進 |
| 顔の見える生産者から、安心できる食材を得たい | 農家と直接つながり、育成過程を見守りながら食材を受け取れる |
CSV（共有価値の創造）との整合性
売り手（農家）よし → JAより手取りが増え、育成期間中にも収益が生まれる 買い手（消費者）よし → 自分で育てて収穫する、お金では買えない体験を得られる 世間よし → 農村への人流創出・農家の収入安定・都市農村交流という社会課題の解決
消費者がオーナーとして先払いすることで農家の収益が安定し（社会価値）、 その取引からプラットフォームが手数料を得る（経済価値）。 両者が対立せず、同じ一つの取引の中で共存しています。
今後の展望
- LINE連携による農家の出品フロー簡略化
- オーナーと農家のメッセージ機能
- 農業体験ツーリズムとの連携
- 将来的な収益源：農業関連企業への広告・生産データ提供
オーナー枠マーケット — リポジトリ概要
システム構成
- フロントエンド・バックエンドともに Next.js で一元管理（Vercel にデプロイ）
- バックエンドサーバーは存在せず、
/app/api/以下の API Routes が DB アクセスを担う - DB・認証は Supabase に委譲
ページ構成
データフロー
枠購入フロー
枠出品フロー
DB スキーマ
API Routes
デプロイフロー
技術スタック
技術スタック / 選定 Q&A
Q1. なぜ Next.js を選んだのか？
フロントとAPIを1プロジェクトに統合できるから。Next.js の Route Handlers を使うと /api/listings のようなエンドポイントをそのまま書けるため、別途 Express サーバーを立てる必要がない。ハッカソンの時間制約の中でインフラを最小化できた。
Q2. なぜ Supabase を選んだのか？
PostgreSQL DB・ファイルストレージ・認証が1サービスで揃うから。今回は DB（出品情報・支援記録・いいね・コメント）と Storage（出品画像・成長記録画像）を使った。ゼロから API サーバー + RDS を構築する時間がなく、クライアントライブラリで即日つなぎ込めた。
Q3. AI はどう使っているか？
生産者が成長記録の写真を投稿する際、Gemini に画像を渡して農家目線のコメントを自動生成する機能を実装した。gemini-3.5-flash に base64 画像と作物名を送り、支援者向けの 2〜3 文を返させている。生産者の投稿負担を下げる目的。
Q4. 認証はどうしているか？
デモ用に cookie ベースの簡易認証にしている。本番想定では Supabase Auth のメール認証を使う設計だが、今回はデモ時間内に動かすことを優先してシンプルな cookie セッションに置き換えた。
Q5. TypeScript を使った理由は？
Supabase のレスポンス型をフロントとAPIで共有できるから。型エラーで実装ミスを早期に検知でき、特に API レスポンスをそのままコンポーネントの props に使う場面で恩恵が大きかった。
Q6. バックエンドは別に立てていないのか？
今回は Next.js の Route Handlers のみ。/api/producers POST で Supabase に書き込む処理など全て Route Handler 内に実装した。スケールする場合は FastAPI 等の別サービスに分離する選択肢もあるが、ハッカソンのスコープでは不要と判断した。
