ゴール

求人サイト作成

・通常の求人サイト機能（テキスト・画像）
・チャット機能（ダイレクトスカウトメッセージ）
・ショート動画の掲載機能（イメージはインスタリール）
・AIアルゴリズムによってレコメンドの最適化機能

先に読む記事

1. Cursorルール構築（開発環境の最適化）

内容: 品質特性、命名規則、コーディング規約をMarkdownファイルとして作成。
目的: .cursorrules に読み込ませることで、AIが生成するコードの品質を担保し、修正コストを最小化する。

[.cursor/rules/]ディレクトリ内に5つのファイルを設定した。
プロジェクト全体で常時適用するファイルは「01〜」、「02〜」にのみとする。
理由：AIへの負荷増加、ルールの重複による、品質低下を防ぐため。

ファイル名	概要
01-core-standards.mdc	AIの役割定義、行動指針、および保守性・移植性の設計原則
02-security.mdc	セキュリティ脆弱性の排除、型安全、例外処理の実装基準
backend-logic.mdc	性能効率性と信頼性を最大化するためのバックエンド・DB操作基準
frontend-ux.mdc	使用性と機能適合性に優れたUI/UX、アクセシビリティの実装基準
api-compatibility.mdc	他システムとの疎通や後方互換性を維持するためのインターフェース設計基準

01-core-standards.mdcの例

---
# 概要説明：AIの役割定義、行動指針、および保守性・移植性の基準
description: 開発の根幹となる論理的思考、行動原則、および保守設計基準
# 適用対象パス
globs: **/*
# 常時適用
alwaysApply: true
---

# 1. Role and Core Principles
あなたは高度なソフトウェアエンジニアとして、効率性、保守性、およびリスク管理を最大化する責務を負います。
~省略~

2. 技術要件定義・選定（技術スタックの確定）

内容: Next.js (FE)、Go (BE)、PostgreSQL/Supabase (DB)、AWS(インフラ) を最終決定。
目的: ショート動画配信に必要なスケーラビリティと開発速度の両立。

1. フロントエンド：Next.js (TypeScript)

SEO・表示速度の最適化: 求人媒体において生命線となる検索エンジンからの流入に対し、Next.jsのサーバーサイドレンダリング（SSR）機能が極めて有利に働くため。
開発エコシステムの活用: Reactベースの豊富なライブラリ（Shadcn UI, Tailwind CSS等）を利用し、Instagramのような洗練されたUIを高速に構築するため。
型安全性の確保: TypeScriptの採用により、複雑なUI状態管理におけるバグの発生を最小化するため。

2. バックエンド：Go

高並列処理性能（Goroutine）: リール動画のような高頻度なリクエストや、動画メタデータのバックグラウンド処理において、軽量な並行処理機構である「Goroutine」により圧倒的なスループットを実現するため。
コンパイル言語による高速性: 実行速度が速くメモリ効率も良いため、インフラコストを抑えつつ安定したパフォーマンスを提供するため。
長期的な保守性: 言語仕様がシンプルかつ厳格であり、開発規模が拡大してもコードの可読性と品質を維持しやすいため。

3. データベース：Amazon Aurora (PostgreSQL)

高可用性と信頼性: 自動バックアップ、パッチ適用、3つのアベイラビリティーゾーンにわたるデータ冗長化が標準で備わっているマネージドサービスを利用するため。
スケーラビリティ: 読み取り負荷が増大した場合でもリードレプリカを迅速に追加でき、リール機能に伴う大量のトラフィックに対応するため。
標準的なSQLによる柔軟性: 独自の制約があるBaaSとは異なり、純粋なPostgreSQLとして利用することで、将来的なデータ移行や複雑なビジネスロジックの構築に制限を設けないため。

バックエンド自作の妥当性：BaaS（Firebase/Supabase）との比較

一般的なスタートアップの流れと課題

多くのスタートアップが初期段階でBaaSを採用するのは、技術的難易度が低い「単純なCRUD機能」を優先するためであるが、サービス成長に伴いビジネスルールが複雑化するとBaaSの制約がボトルネックとなり、結果としてGoなどへの再開発（リプレイス）を余儀なくされるのが通例であるため。

本プロジェクトにおける判断の合理性

本プロジェクトは、初期段階から「リール動画」という技術的難易度の高いコア機能を含んでいるため。

手戻りの回避: 動画のストリーミング制御、高度なレコメンドアルゴリズム、S3/CloudFrontとの密接な連携において、BaaSでは機能不足に陥る可能性が極めて高いため。
初期投資としての自作: 最初からGoで構築することで、将来発生し得る「再開発コスト」を完全に排除でき、中長期的な投資対効果（ROI）が最大化される合理的な判断であるため。

3. UI/UXデザイン構成の策定（画面設計）

内容: リール画面、求人詳細画面、応募フローのワイヤーフレームを確定。
目的: ユーザー体験の定義とともに、次工程で必要なデータ項目を可視化する。

ざっくりした画面イメージ

機能要件定義・UXフロー一覧

初期コストを抑えつつユーザー獲得効率を最大化する戦略

フェーズ	ステップ	機能要件	実装仕様・技術的背景
1. 発見 (非ログイン)	求人検索・一覧	求人カード表示	静止画サムネイル + 求人タイトル。動画再生は制限し、トラフィックコストを最小化する。
		ログインゲート	サムネイルタップ時に「動画の視聴にはログインが必要です」というダイアログを表示。
2. 認証 (Auth)	新規登録・ログイン	Firebase Auth連携	Google/メール認証。認証成功後、バックエンド(Go)にUIDを同期しユーザーレコードを作成。
		セッション管理	Firebase ID Tokenによるステートレスな認証（Bearer Token方式）。
3. 視聴 (Reels)	動画フィード再生	縦型スワイプUI	モバイル全画面表示。上下スワイプによるシームレスな動画切り替え。
		セキュア配信	ログイン済ユーザーのみに「S3署名付きURL」を発行。URLの直接拡散を防止。
		求人オーバーレイ	動画上に紐づく求人の簡易情報を表示。タップで詳細へ遷移。
4. 詳細 (Details)	求人内容の確認	ストーリー形式表示	Wantedly風。企業文化や「なぜやるか」を重視した画像とテキストの構成。
		柔軟な紐付けロジック	企業が指定した求人、または同一企業内の最新求人を自動的にマッチングして表示。
5. 応募 (Action)	エントリー	ワンタップ応募	「話を聞きに行きたい」等のボタンによるエントリー。複雑な入力は排除。
		ブックマーク	気になった動画や求人をマイページに保存する機能。
6. 管理 (Admin)	進捗管理	選考ステータス	「準備中、選考中、結果」の4段階をヘッダーの選考情報アイコンから確認。
		連携設定 (企業側)	動画に対して「どの求人URLを出すか」を企業が手動または自動で設定可能にする。

データ紐付けの優先順位（バックエンド論理）

手動紐付け (Manual): video_job_relations テーブルに存在する明示的なリンク。
自動紐付け (Auto): 手動設定がない場合、company_id が一致する最新の公開求人を自動抽出。
外部連携 (External): 既存のLP（dodaや自社サイト等）へ直接飛ばすためのURL保持。

セキュリティ設計

S3 Bucket: 外部公開禁止（Private）。
Video Delivery: Goバックエンドが生成する有効期限付き（例: 1時間）のPre-signed URLを使用。
Auth: Firebase Admin SDKを用いたJWT検証ミドルウェアを全ての保護ルートに適用。

4. APIインターフェース定義（フロント・バックの契約）

内容: 画面デザインに基づき、通信するデータの型（JSON）やエンドポイントを定義。
目的: 「APIファースト」を実現し、フロントエンドとバックエンドの並行開発を可能にする。

APIエンドポイント一覧

フロントエンドとバックエンド間の通信規約です。

認証が必要なエンドポイント

Method	Endpoint	Description	Response (Core)
`GET`	`/api/v1/reels`	フィード用動画リスト取得	`video_url` (署名付き), `linked_jobs[]`
`POST`	`/api/v1/apply`	求人への応募実行	`application_id`, `status`
`GET`	`/api/v1/user/selections`	自身の選考ステータス取得	`job_id`, `status(選考中など)`

認証不要なエンドポイント

Method	Endpoint	Description	Response (Core)
`GET`	`/api/v1/jobs`	求人一覧取得（検索用）	`title`, `thumbnail_url` (静止画)
`GET`	`/api/v1/jobs/:id`	求人詳細情報の取得	`title`, `content_html`, `company_info`

動画視聴フロー（ログイン必須）

フロントエンド: Firebase Authで取得したIDトークンをヘッダーに付与し、/api/v1/reels をリクエスト。
バックエンド (Go): Firebase Admin SDKでトークンを検証。
バックエンド (Go): DBから動画メタデータを取得。同時に、S3から有効期限付きの「署名付きURL（Presigned URL）」を発行。
フロントエンド: 取得した署名付きURLを用いて動画を再生。

データ連携ロジックのポイント

バックエンド（Go）側で GET /api/v1/reels を処理する際の論理ロジック：

明示的紐付けの取得: video_job_relations から対象動画に紐づく求人を検索。
自動紐付けの補完: もし紐付けが0件、または企業が「自動補完」を有効にしている場合、同じ company_id を持つ最新の jobs を最大n件取得してレスポンスにマージ。
セキュリティ処理: S3 SDKを用いて s3_key から video_url (有効期限1時間) を生成。

設計の合理性

コスト最適化: 未ログインユーザーには静止画（CDN経由）のみを返し、高価な動画配信は認証済みユーザーに限定。
拡張性: 交差テーブル方式により、将来的に「1つの動画から複数の求人へ誘導する」あるいは「1つの求人に複数の動画（インタビュー、オフィス紹介など）を紐付ける」ことが容易。
保守性: DBに署名付きURLを直接保存せず s3_key のみを管理することで、URLの有効期限切れによるリンク切れ問題を根本から排除。

5. データベース・スキーマ設計（データ基盤）

内容: API定義に基づいたテーブル設計およびリレーション（ユーザー、動画、求人票）の構築。
目的: データの整合性を保ち、効率的なクエリ発行が可能な構造を作る。

テーブル定義：DDL

「動画と求人の多対多」および「手動/自動紐付け」を実現するための設計です。

-- 1. ユーザーテーブル（Firebase Authと同期）
CREATE TABLE users (
    uid VARCHAR(255) PRIMARY KEY, -- FirebaseのUID
    email VARCHAR(255) NOT NULL,
    display_name VARCHAR(255),
    avatar_url TEXT,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- 2. 企業テーブル
CREATE TABLE companies (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(255) NOT NULL,
    logo_url TEXT,
    description TEXT,
    website_url TEXT
);

-- 3. 動画テーブル
CREATE TABLE videos (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    company_id UUID REFERENCES companies(id),
    s3_key TEXT NOT NULL,         -- S3上のファイル名（URLそのものではない）
    thumbnail_key TEXT,           -- サムネイルのS3キー
    title VARCHAR(255),
    description TEXT,
    view_count INTEGER DEFAULT 0,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- 4. 求人テーブル
CREATE TABLE jobs (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    company_id UUID REFERENCES companies(id),
    title VARCHAR(255) NOT NULL,
    content_html TEXT,            -- 求人詳細（MarkdownまたはHTML）
    salary_range VARCHAR(100),    -- 例: "500万円〜800万円"
    location VARCHAR(255),
    is_active BOOLEAN DEFAULT true,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- 5. 動画・求人紐付けテーブル（交差テーブル）
-- 企業が明示的に紐付けた場合はここにレコードを追加
CREATE TABLE video_job_relations (
    video_id UUID REFERENCES videos(id) ON DELETE CASCADE,
    job_id UUID REFERENCES jobs(id) ON DELETE CASCADE,
    manual_flag BOOLEAN DEFAULT true, -- 企業による手動紐付けならtrue
    PRIMARY KEY (video_id, job_id)
);

6. バックエンド基盤の垂直統合とDB疎通の完了（フェーズ1）

実施内容

データベースの切り替え: Neon (Serverless PostgreSQL)
選定理由: AWS（RDS/Aurora）の固定費（IPv4利用料等）を回避し、開発時のみリソースを消費するサーバーレス構成により、ランニングコスト0円を実現するため。

開発環境の構築:
Homebrew を使用した Go 環境のセットアップ。
Go Module (go mod) による依存関係管理の初期化（shortsHUB-app）。

ライブラリの導入:
sqlx & lib/pq: 効率的な DB 操作と PostgreSQL 接続のため。
godotenv: セキュリティを考慮した環境変数管理のため。

DB疎通確認
Go プログラムからクラウド上の Neon DB への接続テスト。

実施手順

brew install go // goをインストール
go version

mkdir shortsHUB-app 
cd shortsHUB-app

go mod init shortsHUB-app //goプロジェクトの初期化

// 外部ライブラリの導入
go get github.com/jmoiron/sqlx //Go標準のDB操作機能
go get github.com/lib/pq //PostgreSQLとの通訳者
go get github.com/joho/godotenv //env用

main.goを作成　// インストールしたgoが動くかテスト
.env // NeonDBの接続情報を記載

go run main.go 

↓↓↓

**以下が出たらOK**

Successfully connected to Neon Database!

main.goの中身（疎通確認用）

テーブル作成・認証機能実装（フェーズ2）

Neon 上でのテーブル作成（DDL実行）

前述したDDLを貼り付け、「RUN」をクリックし実行

以下のようにテーブルが作成・表示される

Firebase Admin SDK の統合と認証ミドルウェアの実装

Firebaseセットアップ・チェックリスト

Firebaseコンソールにて以下を実施する

プロジェクトの新規作成:
shortsHUB-app 等の名前で作成。

Authenticationの有効化:
左メニュー「構築」>「Authentication」から「始める」をクリック。
　※「始める」は初回のみ表示される
「ログインメソッド」で、まずは開発しやすい「メール/パスワード」を有効化。

サービスアカウントキーの取得（Go用）:
プロジェクト設定（歯車アイコン） > 「サービスアカウント」タブ。
[Go]を選択し「新しい秘密鍵の生成」をクリック。
JSONファイルがダウンロードされるので、大切に保管する。
JSONファイルを複製して、アプリディレクトリに「firebase-key.json」としてリネームして追加。

この段階でのファイル構成は以下

Firebase との接続準備

2つのライブラリのインストール

# Firebaseの全機能（認証、DB、Storage等）をGoから操作するための公式「本体」ライブラリ
# GoのプログラムがFirebase Admin SDKとして動作できるようになる
go get firebase.google.com/go/v4

# Google Cloudのサービス（Firebaseを含む）に接続する際の「認証オプション」を制御する補助ライブラリ
# 先ほど用意した「firebase-key.json」を読み込むために、このライブラリの機能が必要になる
go get google.golang.org/api/option

疎通確認

GO言語についてのメモ

どこでエラーが起きるのか分かりやすく、曖昧さも取り込むような仕様。
GO言語の特徴として、宣言したら必ず使うという制約がある。そのため、仮や登録のみの使用時は[_]を記載する必要がある。
多値返しapp, err := firebase.NewApp(ctx, nil, opt)によって、変数宣言と処理実行とエラー処理をまとめることができる。
コンパイル言語なのに、コンパイルやビルドをしなくても実行できる理由は、
go run コマンドが、「一時的なコンパイル → 実行 → 一時ファイルの削除」を裏側で一括して行っているため。

Firebase との接続確認

以下の「main.go」を実行し、FirebaseとNeonへの疎通確認を実行する

main.go

package main

import (
	"context" // Firebaseの操作に必要（タイムアウト管理など）
	"fmt"
	"log"
	"os"

	firebase "firebase.google.com/go/v4"
	"github.com/jmoiron/sqlx"
	"github.com/joho/godotenv"
	_ "github.com/lib/pq"
	"google.golang.org/api/option"
)

func main() {
	// 1. .envファイルを読み込む
  godotenv.Load()

	// --- Firebase 初期化セクション ---
	// Backgroundコンテキスト（操作の基礎となる背景）を作成
	ctx := context.Background()

	// サービスアカウントのJSONファイルを読み込む
	opt := option.WithCredentialsFile("firebase-key.json")

	// Firebase Appを初期化
	app, err := firebase.NewApp(ctx, nil, opt)
	if err != nil {
		log.Fatalf("Firebase初期化に失敗しました: %v\n", err)
	}

	// Auth（認証）クライアントを取得
	authClient, err := app.Auth(ctx)
	if err != nil {
		log.Fatalf("Firebase Authクライアントの取得に失敗しました: %v\n", err)
	}

	fmt.Println("Successfully initialized Firebase Admin SDK!")
	// 変数 authClient は後ほどAPI実装（ユーザー検証）で使用します
	_ = authClient // (一時的に未使用エラーを回避するための記述)

	// --- DB (Neon) 初期化セクション ---
	dsn := os.Getenv("DATABASE_URL")
	db, err := sqlx.Connect("postgres", dsn)
	if err != nil {
		log.Fatalln("DB接続に失敗しました:", err)
	}

	fmt.Println("Successfully connected to Neon Database!")

	var now string
	err = db.Get(&now, "SELECT NOW()")
	if err != nil {
		log.Fatalln("クエリ実行に失敗しました:", err)
	}

	fmt.Printf("Neon DB Time: %s\n", now)
}

認証サーバーの常態化とAPI連携

Webサーバーフレームワーク「Echo」を導入

go get github.com/labstack/echo/v4 //プログラムを「起動し続ける状態（常駐化）」にする

「main.go」の記載を
「DB接続」→「Firebase初期化」→「Echo起動」という論理的な順序で再構成

main.go

package main

import (
	"context"
	"fmt"
	"log"
	"net/http"
	"os"

	firebase "firebase.google.com/go/v4"
	"github.com/jmoiron/sqlx"
	"github.com/joho/godotenv"
	"github.com/labstack/echo/v4"
	"github.com/labstack/echo/v4/middleware"
	_ "github.com/lib/pq"
	"google.golang.org/api/option"
)

func main() {
	// 1. 環境設定の読み込み
	godotenv.Load()

	// 2. Firebase Admin SDK の初期化
	ctx := context.Background()
	opt := option.WithCredentialsFile("firebase-key.json")
	app, err := firebase.NewApp(ctx, nil, opt)
	if err != nil {
		log.Fatalf("Firebase初期化失敗: %v\n", err)
	}
	authClient, err := app.Auth(ctx)
	if err != nil {
		log.Fatalf("Authクライアント取得失敗: %v\n", err)
	}
	_ = authClient // 後ほど使用

	// 3. Neon DB (PostgreSQL) の初期化
	dsn := os.Getenv("DATABASE_URL")
	db, err := sqlx.Connect("postgres", dsn)
	if err != nil {
		log.Fatalf("DB接続失敗: %v\n", err)
	}
	fmt.Println("Successfully connected to Neon Database!")

	// 4. Echo インスタンスの生成（Webサーバーの心臓部）
	e := echo.New()

	// 5. ミドルウェアの設定（安全装置と記録）
	e.Use(middleware.Logger())  // アクセスログを記録
	e.Use(middleware.Recover()) // クラッシュから自動復旧

	// 6. ルーティング（窓口の設定）
	// ブラウザで http://localhost:8080/ にアクセスした時の処理
	e.GET("/", func(c echo.Context) error {
		return c.String(http.StatusOK, "Hello, shortsHUB-app API!")
	})

	// 接続確認用のテストエンドポイント (DBの時刻を返す)
	e.GET("/health", func(c echo.Context) error {
		var now string
		err := db.Get(&now, "SELECT NOW()")
		if err != nil {
			return c.JSON(http.StatusInternalServerError, map[string]string{"error": "DB query failed"})
		}
		return c.JSON(http.StatusOK, map[string]string{
			"status": "ok",
			"time":   now,
		})
	})

	// 7. サーバーの起動（ポート8080番で待ち受け開始）
	fmt.Println("Starting server on :8080...")
	e.Logger.Fatal(e.Start(":8080"))
}

ターミナルで go run main.go を実行し成功を確認

ブラウザを起動し、アドレスバーに http://localhost:8080/health にアクセスする。

ブラウザ：時刻が表示されることを確認
ターミナル：status:200が出力されることを確認

〜Chrome/143.0.0.0 Safari/537.36","status":200,"error":"",〜

API実装（の前にルールや技術要件の整理）

この時点で、機能ごとにファイルを分けたかったので以下のように依頼するとソースコードまで作成してくれた。（内容は全部削除）

handlersフォルダを作成して。
その中に、auth_handler.goファイルを作成して。

cursorにルールは定義していたが、技術要件やDDLを伝えていなかった。
そのため技術要件とDDLの内容を送り、ルールの修正とdocの新規作成を実施。

#あなたは高度なソフトウェアエンジニアです。
#時間がかかってもよいので品質を最優先してください。

@.cursor/rules/01-core-standards.mdc  に以下の技術要件をコメント付きで追記してください。
内容の重複や修正点があれば、前後の記述を明確にして修正提案をしてください。

# Go Development Rules
- Use Echo v4 as the web framework.
〜省略〜

#技術仕様をあなたに伝えていませんでした。
#以下のフォルダとファイルを作成してください。
docs/technical_spec.md
#technical_spec.mdの内容には、以下を記載してください。

#DDL
-- 1. ユーザーテーブル（Firebase Authと同期）
CREATE TABLE users (
〜省略〜

メモ：上記のプロンプトだと固まってしまった
プロンプトが重すぎたのか挙動が固まってしまうので、以下を実行し部分的に依頼。

cursor再起動
プロンプト指示のタブも開き直し
手動でフォルダ作成、ファイル入力を実施

↓DDLに関する情報を精査しMD形式に修正
内容を見ながらkeepを選択

メモ一部質問したい部分があったので、コピーした状態でプロンプトにペーストすると以下のように指定できた。

フォルダ構成の見直し

フロントとバックにディレクトリを分け以下のような構成を想定し、今後の作業を行う


## Directory Structure
```text
.
├── shortshub-app-backend/        # Go API Server
│   ├── main.go                  # Server Entrypoint & DI
│   ├── handlers/                # Business Logic
│   │   └── auth_handler.go      # User Auth & DB Sync
│   ├── firebase-key.json        # Firebase Admin SDK Key
│   ├── .env                     # Backend Env Vars
│   └── go.mod                   # Go Modules
│
└── shortshub-app-frontend/       # Next.js Frontend
    ├── src/
    │   ├── app/                 # App Router Pages
    │   │   ├── layout.tsx
    │   │   └── page.tsx         # Auth Test Page
    │   └── lib/
    │       └── firebase.ts      # Firebase Client SDK Config
    ├── .env.local               # Frontend Env Vars
    └── package.json             # NPM Dependencies

API実装（の前にルールや技術要件の整理：済み）

# 1. Next.jsプロジェクトの生成 (ディレクトリ名を指定して実行)
npx create-next-app@latest . --typescript --tailwind --eslint

# 2. Firebase SDKのインストール
npm install firebase

# 3. [.env.local]を作成
→ firebaseの認証情報(SDK)を追記

とりあえずのフロントページを用意

page.tsx

"use client";

import { auth, googleProvider } from "../lib/firebase";
import { signInWithPopup } from "firebase/auth";

export default function Home() {
  const handleLoginAndSignup = async () => {
    try {
      // 1. Firebase Googleログインを実行
      const result = await signInWithPopup(auth, googleProvider);
      const user = result.user;

      // 2. IDトークン（証明書）を取得
      const idToken = await user.getIdToken();
      console.log("Firebase ID Token acquired");

      // 3. Goバックエンドの /signup エンドポイントへ送信
      const response = await fetch("http://localhost:8080/signup", {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          "Authorization": `Bearer ${idToken}`, // ここが重要
        },
      });

      const data = await response.json();
      console.log("Backend Response:", data);
      alert(data.message || "疎通成功！Neon DBを確認してください。");

    } catch (error) {
      console.error("Error:", error);
      alert("エラーが発生しました。コンソールを確認してください。");
    }
  };

  return (
    <main className="p-24">
      <h1 className="text-2xl font-bold mb-8">疎通テスト：shortsHUB-app</h1>
      <button
        onClick={handleLoginAndSignup}
        className="bg-blue-500 text-white px-6 py-3 rounded-lg font-medium"
      >
        GoogleでログインしてDB同期
      </button>
    </main>
  );
}

ブラウザで認証機能の確認

「.env.local」の階層場所はfrontディレクトリの直下である必要がある。

firebaseコンソールでログイン方法に[Google]を追加（有効化）する。

# バック起動
run main.go

# フロント起動
npm run dev

# ブラウザへアクセス
http://localhost:3000/

アクセスすると以下の表示

クリックすると正常にGoogleログインの表示がされ、進むとポップアップが表示される
→ 疎通OK！
→ NeonDBにも自分のデータが登録できていること確認できた！

休憩:ここまでの作業メモ

cursorを使い効率的に作業できた気がする。
geminiにも質問し精度を高められた気がする。
（途中からgeminiがコーチングしてくれた）
AIを使い効率的になったとはいえ普通に疲れる。

次の作業前に確認し、優先順位をつけて精査する。

・ルールに、nextとgoを使用することが含まれているかどうか確認する。
　→goだけある気がする、nextも入れておきたい
　→front側のルール？オール？

・作成日時と更新日時が必要なテーブル必があると思う。
　→カラムの見直し

・gitでのコード管理

・ECSの構築（インフラ構成を検討）

・ユーザー情報の拡充: DBに保存する項目（プロフィール画像URL、自己紹介など）を増やす。

・動画投稿機能の検討: 動画ファイルをどこに保存し（Cloud Storageなど）、どうDBで管理するか設計する。

・デザインの着手: 後回しにしていた Next.js の画面を、実際の「求人アプリ」らしく整え始める。

未実施垂直統合開発：リール・求人機能実装

内容: 動画表示UIとバックエンドAPIの連携。求人一覧とリールの紐付け。
目的: アプリのコア価値を実装し、FE/BEともに50%程度の完成度まで引き上げる。

未実施進捗評価・コードレビュー（品質管理）

内容: Cursorによる生成コードの整合性チェックとリファクタリング。
目的: 開発の「ねじれ」を解消し、翌日以降のタスクを論理的に再整理する。