Locker.aiは、遺失物の登録、検索、本人確認、返還を、LLMとスマートロッカーでつなぐチーム開発です。私は茨城工業高等専門学校のチーム「明日のDCON楽しみだね」の一員として、主にWebフロントエンド、AIとの対話UI、API接続を担当しました。ハードウェア、機械学習、事業設計、発表はメンバーと分担し、DCONでの結果はチームとして得たものです。
2024年3月の情報処理学会 インタラクション2024で研究発表とデモを行った後も開発を続け、2025年5月の第6回全国高等専門学校ディープラーニングコンテスト2025（以下、DCON2025）本選へ進みました。このページでは、当日のプレゼンテーション、実装した技術、会場での審査を一つの記録としてまとめます。
プロダクトプレゼン概要
私たちが出発点に置いたのは、落とし物を拾った人、保管する施設、探している人の全員に待ち時間と手作業が発生することでした。Locker.aiでは、拾得者がWebから遺失物を登録して最寄りのロッカーへ預け、遺失者がチャットで候補を絞り、本人確認を経て指定されたロッカーから受け取る流れを設計しました。
【茨城工業高等専門学校】Locker.ai：LLM×スマートロッカーによる自動応対遺失物管理サービス学校名茨城工業高等専門学校 チーム名明日のDCON楽しみだね 作品名Locker.ai：LLM×スマートロッカーによる自動応対遺失物管理サービス メンター折茂 美保氏（ボストン コンサルティング グループ マネージdcon.ai
課題整理では、国営ひたち海浜公園、JR東日本勝田駅、茨城県警にもアンケートへ協力いただきました。拾得者の届出、施設での保管、遺失者からの照会という三者の流れを分けて捉え、ロッカーとWebを組み合わせたときに、どの手作業を減らせるかを検討しました。
本選の39枚のスライドは、従来の遺失物管理で拾得者・施設占有者・遺失者が抱える課題から始まります。その後、遺失物登録と対話による照会、LLM・独自モデル・多言語対応、モジュール式スマートロッカーを順に紹介し、最後にBtoBtoC・BtoGtoCの事業モデルと導入ロードマップを提示しました。技術だけを単独で見せるのではなく、誰の作業をどこで置き換え、施設規模に応じてどう導入するかまでを一本のストーリーにしています。
スライドでは「落とし物の管理業務を遺失者と拾得者で完結すること」を目標に置きました。ただし、これは施設占有者を完全に不要にしたという意味ではありません。保管物の回収、例外対応、誤返還を止める運用は残ります。プレゼンテーションでは自動化の価値を示しつつ、実装では検索結果と受け取り可能な状態を分離しました。
事業モデルでは、導入する施設や地方公共団体を契約主体とし、拾得者と遺失者がWebとロッカーを利用するBtoBtoC・BtoGtoCを想定しました。ロッカーは必要な口数を組み合わせられるモジュール式とし、施設の規模や既存の管理体制に応じて導入範囲を変える提案です。
技術
チーム全体のシステム構成
DCON2025本選時点の公開リポジトリと発表資料では、次の構成を採用していました。
- Web: Next.js 14、React 18、TypeScript、next-intl、Vercel AI SDK 4、GPT-4.1
- API: NestJS 10、Apollo GraphQL、Prisma、GraphQL Code Generator
- データと認証: Supabase Auth、Storage、Postgres、pgvector
- 類似度推論: FastAPI、PyTorchで構成した遺失物マッチングAI
- ハードウェア: Raspberry Pi 5の制御サーバー、Raspberry Pi Picoの鍵制御、ソレノイドロック、QRコードリーダー
- 開発基盤: pnpm workspace、Turborepo、Jest、Storybook、Chromatic
- 配備: WebはVercel、APIと推論サービスはRailway
この一覧はチーム全体の技術スタックです。私はすべての選定・実装を単独で担当したわけではありません。
公開モノレポは、利用者向けのwebsite、ロッカーに表示するlocker-dashboard、NestJSのapi、UIカタログを分け、pnpm workspaceとTurborepoで管理していました。2025年5月9日の本選直前コミットを基準にすると、主要な処理境界は次のようになります。
届出写真を検索できるデータへ変換する
拾得者が写真を登録すると、APIは画像をSupabase Storageへ保存し、同じ画像をGPT-4.1へ渡して、色、形、材質、ブランド、型番、表面の文字などを含む英語の特徴記述を生成します。その記述を日本語へ翻訳して表示用データを作る一方、検索用にはtext-embedding-3-smallでベクトル化し、Postgresのvector列へ保存します。
遺失者の入力も検索前に英語へ変換して同じ埋め込みモデルへ渡します。公開実装ではpgvectorのコサイン距離演算子<=>から類似度を計算し、所有者がまだ決まっていない遺失物から候補を取得していました。
SELECT
id,
1 - (embedded_description <=> ${embeddedDescription}::vector) AS similarity
FROM public.lost_items
WHERE owner_id IS NULL
LIMIT 10ここでテキストの近さだけを最終判定にしません。NestJS APIは各候補の類似度と、遺失日・届出日の差を識別NN APIへ送り、一致側と棄却側の確率を受け取ります。公開モノレポにはFastAPI・PyTorch側の学習コードは含まれていませんが、APIクライアントから入力がsimilarityとdate_difference、出力が2確率の組であることを確認できます。
LLMに検索を任せきらない対話UI
私が担当した検索チャットでは、LLMの文章生成とデータベース検索を分けました。Next.jsのRoute HandlerはVercel AI SDKのstreamTextでGPT-4.1から応答をストリーミングし、モデルがsearchLostItemを呼び出したときだけ、GraphQL経由で類似候補を問い合わせます。
const result = streamText({
model: openai("gpt-4.1"),
system: `${SYSTEM_PROMPT}\n\n${languageInstructions[locale]}`,
messages,
tools,
})
return result.toDataStreamResponse()検索ツールへ渡す説明は内部データに合わせて英語へ変換し、利用者への応答は入力言語に合わせます。曖昧な説明なら追加の特徴を尋ね、日付が相対表現なら絶対日付へ変換してから照合します。ここで会話を見せるUI、ツール呼び出し、GraphQLの問い合わせを明確な境界に分けたことで、LLMが候補を創作するのではなく、検索結果を使って次の質問を組み立てる構造にしました。
候補には承認側と棄却側の確率が返ります。本選時点の実装では、棄却側が0.4以上なら候補画像や詳細を開示せず、追加情報を求める表示に切り替えていました。誤返還を防ぐには、この閾値だけでなく、本人しか知らない特徴、認証、管理者の介入条件を組み合わせる必要があります。
Webから物理ロッカーまで状態をつなぐ
検索で候補が見つかることと、ロッカーを開けて受け取れることは別の状態です。私はQRコード認証ダイアログ、認証状態を反映するヘッダー、ロッカーの設置場所を示す画面、検索結果から受け取り申請へ進む導線を実装しました。
WebとNestJS APIはGraphQLで接続し、型はGraphQL Code Generatorで同期しました。本選前にはWebとAPIをまたぐ国際化、関連するGraphQL mutation、データベースmigrationも更新しています。利用者に見える文言、APIの型、保存データ、物理ロッカーの状態がずれないよう、画面だけで完結させずモノレポ全体の変更として扱いました。
遺失物にはreportedAt、deliveredAt、ownedAt、retrievedAtを持たせ、誰が何をしている途中かは利用者のlostAndFoundStateで管理しました。拾得者が届出を作るとDELIVERINGとなり、空きドロワーへ格納するとNONEへ戻ります。遺失者が受取申請を行うとRETRIEVINGとなり、ドロワーから取り出した時点で完了します。
ロッカー側では、端末からNestJSのHTTPエンドポイントへ状態と指紋認証のchallengeを送り、APIがGraphQL Subscriptionでダッシュボードへ配信します。未連携の指紋が読み取られた場合は、ダッシュボードにlockerIdとハッシュ化した指紋IDを含むQRコードを表示し、Supabaseでログイン済みの利用者が読み取ることでアカウントと指紋を関連付ける構成でした。
情報処理学会 インタラクション2024の論文では、VLMが生成した特徴記述は人手記述との差が小さい事例が多かった一方、劣る事例も報告されています。モデルを追加するだけで安全になるのではなく、候補提示と本人確認を分け、失敗時に返還を止められることが重要だと考えています。
interaction-ipsj.orginteraction-ipsj.orgDCONの様子
DCONは、ものづくりとディープラーニングを使った作品の技術だけでなく、社会課題への効果と事業性までを企業評価額で競うコンテストです。本選前日の技術審査では、実機とシステムを動かしながら、AIの構成、スマートロッカーとの接続、実運用での安全性を説明しました。
みんなの高専チャンネルの密着動画では、12分47秒から私たちの技術審査会の様子が紹介されています。完成したデモだけでなく、審査員の前で技術を説明する距離感や、会場でのチームの動きも分かる記録です。
メンターと事業提案を磨く
DCONでは本選出場10チームにメンターが割り当てられます。Locker.aiを担当してくださったのは、ボストン コンサルティング グループのマネージング・ディレクター＆パートナーで、社会貢献グループ日本リーダーを務める折茂美保氏です。折茂氏はパブリックセクター、教育、気候変動・サステナビリティを専門領域とし、中央官庁、大学、自治体の戦略実行や、企業の新規事業立ち上げを支援してきました。
ものづくりの完成度だけでなく、誰が費用を負担し、どの施設から導入し、どのように事業を広げるかまで問われる本選に向けて、折茂氏に伴走いただきました。チーム代表のコメントでも、アンケートに協力いただいた施設・行政機関とともに、折茂氏への感謝が述べられています。
本選プレゼンテーションでは、メンター紹介、5分間のチーム発表、技術講評、審査員との質疑、投資意思表示までが続きます。公式アーカイブは3時間32分7秒からLocker.aiのパートを再生できます。スライドだけでは伝わりにくい、実機を前提とした提案と質疑の緊張感まで残っています。
DCON2025には42高専・95チームが応募し、Locker.aiは最終審査で5位、企業評価額5,000万円となりました。あわせて、トピー工業賞、日立産業制御ソリューションズ賞、QUICK賞の3賞を受賞しました。これはWeb実装だけではなく、ハードウェア、AI、検証、事業提案、プレゼンテーションを統合したチーム全体への評価です。
本選まで開発したことで、モデルの精度だけではプロダクトの安全性を説明できないと学びました。誤った候補を出したときに返還を止められるか、候補情報を必要以上に見せないか、AIや通信が失敗したときに安全な状態へ戻れるか。Web、API、AI、ロッカーをまたぐ受け入れ条件として考えることが、次に残った課題です。