本日の流れ（25分）

中間発表で説明した背景・ペルソナ・デザイン選定は要点だけに絞り、追加実装と学びに時間を使います。

中間発表で「最終に向けて」と言ったこと、その結果

「定義が固まっていない」として一度は見送った企業マッチングを、条件と重み付けを決めきったうえで追加した。

数字で見る到達点

• 中間発表時点：バックエンド 91 ／ フロント 75 ／ 画面 4
• 実測（pytest -q 289 passed ／ vitest run 196 passed ／ tsc --noEmit エラー0）
• API エンドポイント 28本、テストファイル 34本（バックエンド18・フロント16）

テストは「動くこと」ではなく「壊れ方」を決めるために書いた（AI が落ちても止まらない、同期を2回押しても増えない等）。

ペルソナ：佐々木 拓海（22歳・修士1年）

全体像：3タブ ＋ 機能パネル7項目

• 上部タブは3つ固定（今日 / カレンダー / 受信箱）。残りは ☰ 機能 パネルの7項目から遷移
• 全項目が実ページを持つ（中間時点は9項目中2つだけが遷移可能だった）
• 開かなくても状況が分かるよう、各項目にサブテキスト（充実度・準備率・メモ件数は実データ）

① 今日（ホーム）

• 開いたら今日の動きだけが分かる（4指標・今日やること・返すべきメール・タイムライン）
• 空き時間に締切が最も近いタスクを1つずつ差し込む（空き 2h ― 説明会予習 をここに）

② カレンダー ＋ Google 連携

③ メールの自動振り分け（受信箱）

④ プロフィール・自己分析

⑤ 想定問答

⑥ タスク・締め切り

⑦ 選考ステータス管理ボード

⑧ 企業の発見・マッチング（追加実装）

なぜマッチ率に AI を使わなかったか

• 「なぜ 78% なのか」をその場で説明できることを優先した（ユーザーにも発表でも）
• 年収・休日は AI に生成させない。
  企業に保存した値だけを使い、画面に並記して照合できるようにした
• 企業側が未登録の項目は合致しない扱い（推測で埋めない）

⑨ 企業研究（情報収集）

「規約に違反しないか」を先に調べた

「動くから良い」ではなく「使ってよいか」を先に確かめる、という進め方をした。法的な最終判断は人が行う前提で書いている。

⑩ ナレッジ蓄積

機能はつながって初めて効く

• 手で転記する場面をなくすのが狙い（分からない項目は空のままにして推測で埋めない）
• プロフィールの就活軸は、マッチングと想定問答の両方が入力元として使う
• どの画面でも最上部の指標は共通。手間を減らすと研究時間が増えるが一貫して見える

全員が未経験だった2つの技術

どちらも「動いた」で終わらせず、失敗した理由と選び直した理由を docs/decisions.md に残した。ほかに FullCalendar・TanStack Query・Marp も今回初めて使った。

技術スタックと、やらなかったこと

やらないと決めたこと：ユーザー認証・ログイン、Docker 化・CI・デプロイ、
UI ライブラリの導入（デザインモックのクラス語彙をそのまま移植するため素の CSS を選んだ）

AI は3箇所だけ。落ちても止まらない

メール分類に本文は渡さない（件名と送信元のみ）。AI に渡す情報も最小限にしている。

テストの考え方

• AI と Google は必ずモックする。テストで実 API を叩かない（結果が毎回変わるため）
• 検証するのは壊れ方：同期を2回押しても増えない／キーが無くても落ちない／
  トークンを応答に含めない／条件0個なら企業を出さない
• 緑にするために期待値を実挙動へ書き換えないをチームのルールにした

デモの流れ

（1）同じ骨組みを2人で作った

• Git は置き場所が違うと衝突として検知しない。マージは成功するのに中身が二重になった
• 原因は「機能の担当は決めたが、共通の土台の担当を決めていなかった」こと
• 対策：着手前に git ls-tree origin/main で既存ファイルを確認する手順をルール文書に明記した

（2）AI 基盤を途中で差し替えた

• Chat Completions 形式では response_format が使えず 400 エラー → Responses API に変更
• 想像で書かず、SDK の実際の定義を確認してから実装し、実キーで疎通も確認した
• 学び：外部サービスの差し替えは起きる前提で、呼び出しを1箇所に閉じ込めておく

（3）仕様書と実装のズレは必ず起きる

• 画面の「気になるに追加」が押しても何も起きない不具合も、この確認で見つかった
  （選考段階と登録フラグという別の意味の項目を取り違えていた）
• 直したうえで「押したら何を送るか」のテストを足し、修正前のコードで赤くなることまで確認した
• 学び：仕様書が正であり続けるように、実装を変えたら同じコミットで仕様書も直す

AI 駆動開発をやってみて

残っている課題

「できていないこと」を隠さずに残すことも、仕様書とチームのルールに含めた。