概要

なぜこのアプリを作ったのか
- 使いたい技術をまずは出し合った
  - 青柳がGo, gRPCを使ったマイクロサービスアーキテクチャ
  - 秋穂がMLOps
  - 中町がMLOpsでセジメーカーかEC2を使いたい
- 何を作るか話し合った
  - コンビニという存在について考えたところ、コンビニはみんながコンスタントに通い、店舗数が桁違いに多く、商品数もかなり多く、レジ上にモニターがあるところなどに着目した
  - 話し合ってる中で、身近に感じてる課題だったり困難を解決していこう方向に
  - 過去マッチングアプリで数万円とかしたが成立しなかった人とかいて….
  - 任天堂の宮本さん「アイデアというのは複数の問題を一気に解決するものである」
  - この発言のもと、マッチングアプリは食品廃棄物問題やパーソナライズド広告問題に取り組め、かつ僕たちの技術的な欲求を満たすということから決まりました
開発体制
- メンバーは、みんな自走でき、だいたいフルスタックに扱えるということで、各自やりたいことに取り組みました
- フロントエンド：中町、青柳。バックエンド：中町、青柳。インフラ：中町。MLOps：秋穂
- AI時代のソフトウェア開発で重要なことは、ソースコードの質を担保しつつ作って壊す速度を上げることだと考え、依存を抑えられるクリーンアーキテクチャを採用
- コーディングエージェントとして、ClaudeCode, Codex, Cursorを使用
- ツールとして、https://github.com/obra/superpowers を使用し、TDDで計画・実装・レビュー・テスト・デバッグの工程を大幅に高速かつシステマチックに取り組むことができた

機能紹介

基本的なマッチングアプリとしての機能
- いいね、マッチング、メッセージ
今回独自の機能として
- コンビニ × マッチング機能
  - いつも定期的に利用するコンビニに、まさかのマッチング機能を搭載
    - コンビニだから安心・安全に利用できる
  - コンビニと今回のアプリを利用すると、運命の人に出会える機能を搭載
    - すれ違い通信
    - 知らない二人がコンビニに同時に入った時、お互いにマッチングします！
      - 安全性のため、同じコンビニではなく、東京都のどこかのコンビニの誰かとマッチングします
      - 同じ東京都に限らず、東京と福岡の設定も可能
- コンビニの商品を買うことで、ユーザーはポイントを取得でき、いいねするにはそのポイントを消費する必要がある
- この仕組みによって、コンビニは商品につけるポイントを操作することで、購買行動を操作することができ、それによって食料廃棄物などの問題にアプローチすることができる
- 店内モニター
  - フィーバータイム
    - マッチングする機会

アーキテクチャ図

こだわり技術ポイント

位置情報を使ったマッチング

コンセプト

従来のマッチングアプリは「プロフィールだけ」で相手を選びます。Auroraは**「同じ時間帯に近くのコンビニにいた」**という偶然の接点をきっかけにマッチングする、新しい出会いの形を提案します。

仕組み

Google Maps Places API (New) で現在地周辺5km圏内のコンビニを検索・距離順に表示
ユーザーがコンビニを選んでチェックイン
前後1分以内に半径5km以内の別のコンビニにチェックインした人を「ニアバイ」として表示
同じ店舗の人は除外 → 近くにいたけど別の店にいた人と出会える
ニアバイの相手にいいねを送り、相互いいねでマッチ → チャット開始

技術的なポイント

Haversine公式による正確な球面距離計算（バックエンド/フロントエンド両方）
Google Maps Static API + Maps JavaScript API による地図表示（WebView経由でインタラクティブ操作）
expo-location による実機での現在地取得
コンビニブランド（セブン/ファミマ/ローソン/ミニストップ/デイリーヤマザキ）のアイコン自動判別

ECSを使ったコンテナ開発

インフラ構成

CloudFront (CDN)
    ↓
ALB (public subnet)
    ↓
ECS Fargate (private subnet)
  ├── Go API コンテナ
  └── Next.js 管理画面コンテナ
    ↓
RDS PostgreSQL (private subnet)
    ↓
S3 (プロフィール画像・アセット)
    ↓
Bedrock Claude (レシートOCR)

CI/CD パイプライン

GitHub Actions で main マージ時に自動デプロイ
ECR へのDockerイメージpush → ECSタスク定義更新 → ローリングデプロイ
デプロイ後にECS run-task でDBマイグレーション自動実行
GitHub OIDC による安全なAWS認証（シークレットキー不要）

Terraform によるインフラ管理

VPC / ALB / ECS / RDS / S3 / CloudFront / ECR / IAM を全てコード管理
モジュール化された構成で、環境（dev / hackathon）の切り替えが容易
terraform apply 一発で環境構築完了

クリーンアーキテクチャを使った高速で綺麗な開発

アーキテクチャ

Handler (HTTP)  →  Usecase (ビジネスロジック)  →  Repository (DB)  →  Entity (ドメインモデル)

各レイヤーがインターフェースで疎結合になっており、テスト・変更・拡張が容易。

具体的な設計判断

Dependencies構造体パターン

type Dependencies struct {
    UserUsecase     usecase.UserUsecase
    ProfileUsecase  usecase.ProfileUsecase
    SwipeUsecase    usecase.SwipeUsecase
    MatchUsecase    usecase.MatchUsecase
    CheckinUsecase  usecase.CheckinUsecase
    // ... 機能追加時も引数の順序を気にせず拡張可能
}

TDD（テスト駆動開発）

全Usecaseにユニットテスト（function fieldモック）
全Repositoryに統合テスト（テスト専用スキーマ）
全Handlerにhttptestによるテスト
go test ./... で全テスト一括実行

レイヤーごとの責務分離

レイヤー	責務	テスト方法
Entity	ドメインモデル定義	-
Usecase	バリデーション・ビジネスロジック	モックrepoでユニットテスト
Repository	DB操作・SQL	統合テスト（実DB）
Handler	HTTP ↔ Usecase変換	httptestでユニットテスト

開発スピードの実績

バックエンド全API（Users / Profiles / Swipes / Matches / Messages / Checkins / Receipt OCR）をTDD で実装
フロントエンド全画面（検索 / マップ / いいね / トーク / チャット / マイページ / プロフィール編集）をAPI接続込みで実装
Clean Architectureのおかげで複数人が同時に異なる機能を開発しても衝突が最小限

Bedrock Claude を活用したAIマッチング

レシートOCR: レシート画像をClaude Sonnet 4.5に送信 → 商品名抽出
あいまい商品マッチング: OCR結果とDB登録商品をClaudeが照合（「からあげ棒(税込)」→「から揚げ棒」のような表記揺れを吸収）
ポイント付与: マッチした商品のpoint_valueを合計してユーザーに付与

MLOpsを使った機械学習パイプラインの構築と独自MLモデル開発

特徴

レスポンスが0.1秒ぐらいで爆速
リアルタイム推論
Optunaを使ったブラックボックス最適化
サービス運営に必要なMLOpsの各コンポーネントをフルスクラッチ実装した
- 特徴量ストア、モデルレジストリなども自作
要件
- 時間帯によるリクエスト量の変化への対応→AWS ECS Cluster Auto Scaling
- 時間帯予測リクエストの低レイテンシの維持→LightGBM
- ML開発者のスキルセットに依存しない運用体制の構築→ECS採用
採用技術
- LightGBM（Light Gradient Boosting Machine）
  - 高速かつ高性能な勾配ブースティングフレームワーク
- ハイパーパラメータ最適化
  - Optuna を利用し、LogLoss 最小化で確率の妥当性（校正）を重視した探索を実行

本番主軸は online_time_band（LightGBM）で、sgd_classifier_ctr は代替/実験系の構成です。

MLに使われているアルゴリズム一覧（カテゴリ別）

勾配ブースティング決定木（GBDT, 二値分類）
- LightGBM (LGBMClassifier): 目的変数は online_flag（オンライン有無の0/1）。多数の弱学習器（決定木）を勾配方向に逐次追加して損失（logloss）を下げる方式。非線形性・特徴量相互作用を自動で拾えるのが強み。
- 使いどころ: time_band_enc や prev_7d_* のような時系列由来特徴量の非線形境界学習。
線形オンライン学習（確率出力のロジスティック損失）
- SGDClassifier (loss=log_loss): 実質ロジスティック回帰をSGDで最適化。大規模・高次元で軽量に回せる。
- 使いどころ: CTR系（sgd_classifier_ctr）のベースライン/高速学習用途。
ハッシュトリック（高次元カテゴリ特徴の圧縮）
- FeatureHasher: col=value 文字列を固定次元（2**18）に写像。One-Hotを明示的に作らず疎→密変換で扱う。
- 技術ポイント: 衝突はあるがメモリ効率と速度を優先する設計。
時系列分割（リーク防止）
- Chronological Split: 学習/検証/テストを時系列順（shuffle=False、または「最後N日をテスト」）で分離。
- 狙い: 将来情報混入（data leakage）を防いでオンライン運用に近い評価にする。
履歴特徴量エンジニアリング（ローリング統計）
- ラグ特徴: prev_1d_same_band_online
- 移動平均: prev_3d_same_band_online_rate, prev_7d_same_band_online_rate, prev_7d_any_online_rate
- 活動量指標: active_days_last_7d
- 効果: 短期/中期の行動慣性を分離してモデルに入力。
評価アルゴリズム
- Log Loss: 確率予測の鋭さを評価（小さいほど良い）。
- ROC-AUC: 閾値非依存の順位性能。
- Calibration（独自指標）: sum(y_pred)/sum(y_true) を1に近づける判定。確率総量の過大/過小を監視。
- 採用判定ロジック: 新モデルが baseline に対して logloss改善かつ calibration改善 のとき更新。
ハイパーパラメータ最適化
- Optuna + 3-fold CV: alpha, learning_rate, eta0 を探索し、neg_log_loss を最大化（= logloss最小化）。
- 探索戦略: 対数スケール探索（log=True）で広い範囲を効率探索。
合成データ生成（デモ/検証用）
- Poisson発生モデル + ペルソナ重み: 日次イベント数をポアソンで生成し、時間帯分布を persona ごとに変化。
- 使いどころ: Athena未接続でも再現可能な学習データを作るためのシミュレーション。

ライブラリ一覧（カテゴリ別）

モデル学習
- lightgbm: 本番主力の二値分類器。木ベースで前処理負荷が比較的低い。
- scikit-learn: SGDClassifier、train/test split、CV、各種メトリクス、calibration curve。
最適化・AutoML寄り
- optuna: SGD系モデルのハイパーパラメータ探索。試行管理とベスト探索を担う。
データ処理・特徴量計算
- pandas: join/groupby/rolling/日時処理で特徴量作成の中核。
- numpy: ベクトル演算、確率計算、クリッピング、乱数生成。
データ品質保証
- pandera: OnlineEventSchema などで列型・NULL・制約を厳格検証。入力ドリフト/破損検知に有効。
可視化・解析
- matplotlib, seaborn: ROCやcalibration可視化、探索分析に利用。
モデル永続化
- joblib: 学習済みモデルやハッシャーを pkl 保存/読込（推論時再利用）。
推論サービング
- fastapi: /predict API提供、入力バリデーション、レスポンス整形。
- uvicorn: ASGIランタイムとしてFastAPIを本番実行。
AWS連携（MLOps基盤）
- awswrangler: Athena SQL実行結果をDataFrameとして取得。
- boto3: S3/DynamoDB/ECS周辺のAWS操作（artifact保存、model registry参照など）。
開発補助（品質/運用）
- pydantic: APIリクエストモデル定義。
- tqdm, psutil: 進捗・リソース監視系の補助。
- pytest, mypy, ruff: テスト・型安全・静的品質の維持。!

あなたとコンビに！恋AIマート

コンビニでマッチングができてしまうマッチングアプリです！

推しアイデア

作った背景

推し技術

プロジェクト詳細

概要