01システム概要
名刺画像のデータ化とWeb自動収集による企業情報の強化を土台に、AIが参加者間のビジネス親和性を解析する。展開軸は2つ — オフラインイベントでのリアルタイムマッチング／席替え案内（LINE連携）と、オンラインのスワイプ型マッチングプラットフォーム。
軸 A — オフライン
イベント × LINE連携
QRエントリーで参加者を判定し、会場内のペアローテーション（3回）をAIが算出。結果はLINEでプッシュ配信、その場で印刷レポートも出力。
軸 B — オンライン
スワイプ型マッチング
登録済みの名刺・企業プロフィールをカードUIで右/左スワイプ。相互マッチ成立で1対1チャットが解放される。
02機能要件
6つの機能ブロックで構成。①②が全体のデータ基盤、③④がオフライン軸、⑤⑥がオンライン軸を支える。
| ID | 機能名 | 主な要件 |
|---|---|---|
| F1 | 名刺OCR・DB化＋企業情報補完 | 写メ／スキャナ画像から氏名・会社名・役職・連絡先を自動抽出。会社名をキーにWeb検索・スクレイピングし、事業概要やプレスリリースをDBへ自動統合。 |
| F2 | AIマッチング＆レポート生成 | 補完済みDBを基にAIが親和性・協業可能性を解析し、スコア（0〜100%）とワンポイント提案を生成。画面表示に加えPDF／印刷用フォーマットを出力。 |
| F3 | イベントリアルタイムローテーション | 会場内で相手が重複せず、かつ相性の良い組み合わせとなる3回分のペアリングを自動算出し、席次シートを生成。 |
| F4 | 公式LINE連携＆QRエントリー | エリア×日時判定型QR。既存ユーザーはQR読取のみで入場、新規ユーザーはLINEでフルネーム送信→OCRデータと照合→アカウント自動作成。通知は全てLINE配信。 |
| F5 | 会員マイページ | ID/PW認証（LINEログイン考慮）。過去イベント・マッチング結果の閲覧、参加者プロフィール閲覧、ダイレクト連絡機能。 |
| F6 | スワイプ型マッチング | カードUIでの右/左スワイプ分類。相互「興味あり」成立時のみ1対1チャットを解放。 |
03非機能・技術要件（推奨案）
Frontend
Webブラウザベース／レスポンシブ／PWA対応
LINE連携
LINE Messaging API, LIFF
OCR
Google Cloud Vision API または Amazon Textract
AI解析・検索
OpenAI API (GPT-4等) + Web Search / RAG構成
インフラ／DB
AWS または GCP（セキュリティ・拡張性を確保）
04システム構成図
中核は単一のデータパイプライン ―「撮影 → OCR抽出 → Web企業情報補完 → 名刺DB → AIマッチング」。ここから2つの配信チャネル（LINE / Web）へ分岐する構造が、オフライン軸とオンライン軸を1つのDBで両立させる仕組みそのもの。
05DB主要テーブル定義
中心となるのは users / business_cards / companies / events / event_entries / matches の6テーブル。PK は主キー、FK は外部キーを示す。
users会員アカウント
| id (PK) | UUID |
| line_user_id | UNIQUE / LINE連携キー |
| full_name / email | 基本プロフィール |
| password_hash | Web直接ログイン用 |
| primary_card_id (FK) | → business_cards.id |
| created_at |
business_cardsOCR結果
| id (PK) | UUID |
| owner_user_id (FK) | → users.id／未紐付け時はnull |
| source_image_url | 元画像 |
| name / title / dept / tel / addr | OCR抽出項目 |
| company_id (FK) | → companies.id |
| ocr_confidence | 信頼度スコア |
companies企業情報補完
| id (PK) | UUID |
| name | UNIQUE / 会社名 |
| website_url | |
| business_summary | 事業概要（スクレイピング） |
| press_releases | JSON配列 |
| last_enriched_at | 最終補完日時 |
eventsイベント定義
| id (PK) | UUID |
| name / venue | |
| area | 例: 銀座／新宿 |
| qr_code_value | UNIQUE |
| start_at / end_at | 日時判定に使用 |
event_entries参加登録
| id (PK) | UUID |
| event_id (FK) | → events.id |
| user_id (FK) | → users.id |
| entry_method | qr_existing / qr_new_line |
| entered_at |
matchesAIマッチング結果
| id (PK) | UUID |
| entry_a_id / entry_b_id (FK) | → event_entries.id |
| score | 0〜100（数値化された親和性） |
| ai_comment | 協業提案メッセージ |
| generated_at |
event_pairings会場ローテーション
| id (PK) | UUID |
| event_id (FK) | → events.id |
| round_no | 1〜3 |
| match_id (FK) | → matches.id |
| seat_no | 席次 |
swipes / mutual_matchesオンライン軸
| swiper_id / target_id | FK → users.id |
| direction | like / skip |
| mutual_matches | 双方likeで生成、chat解放 |
| messages | event_match / mutual_match 両対応 |
06開発フェーズ（MVP開発ステップ）
MVPはオフライン軸のコア体験（F1・F2・F5の一部）から着手し、LINE連携／リアルタイムローテーション、最後にオンライン軸のスワイプ機能を積み上げる。
PHASE 0
要件確定・DB設計・API仕様・外部API選定（Vision/Textract, OpenAI）
PHASE 1 · MVP
OCR取込、名刺DB、簡易マイページ、手動での企業情報登録から着手
PHASE 2
Web自動収集の自動化、AIマッチングスコア算出、レポート画面／PDF出力
PHASE 3
LIFF／QRエントリー、新規ユーザー紐付けフロー、3回ローテーション算出、LINE通知
PHASE 4
スワイプUI、相互マッチング、1対1チャット（LINE／Web両対応）
PHASE 5
負荷対策、監視・分析基盤、AIプロンプト／RAG精度チューニング