中級⑤ テストと公開前チェックの型を作る

サービスが育ってくると、新しい怖さが出てきます——「ここを直したら、別の場所が壊れるんじゃないか」。今日はその怖さを消す回。テストという見張り番を雇って、「壊れていないこと」を機械に確認させる型を作ります。

STEP1：実は、もう1つテストを持っている

Vercelにデプロイするたびに走っているビルド。あれは「文法ミスがないか」「ファイル同士のつながりが切れていないか」を全ページ分チェックする、立派な検査です。ビルドが赤くなったら公開されない＝壊れた状態が世に出ない仕組みが、もう動いている。今日はこの上に検査を重ねていきます。

STEP2：AIにテストを書いてもらう

テストとは「この関数に〇〇を入れたら△△が返るはず」を確かめる小さなプログラムのこと。書くのはもちろんAIです。まずは“壊れたら一番困る部分”から守ります。

このプロジェクトにVitestを導入して、テストを書いて。対象：①お問い合わせフォームの入力チェック（空欄・長すぎる入力・メール形式）②メモの文字数チェックなど、壊れたら困るロジック。npm test で全部走るようにして。UIの細かい見た目のテストは今回は不要。まず計画を見せて。

1. 1計画OK→実行→mainに反映。
2. 2「npm test を実行して結果を見せて」と頼む（ローカル環境がある人は自分で npm test でもOK）。
3. 3全部緑（パス）を確認。これが「いまは壊れていない」の証明書です。

STEP3：壊してみる（見張り番の動作確認）

せっかくなので見張り番が機能するか試しましょう。「入力チェックの文字数上限をわざと間違った値に変えて、npm test がちゃんと失敗するか確認して。確認できたら元に戻して」と頼んでみてください。赤くなる→直すと緑に戻るを一度見ておくと、テストへの信頼が体感に変わります。

STEP4：公開前チェックを“型”にする

中級①で作った /release-check スキルに、今日の装備を組み込んで完全体にします。

release-check スキルを更新して。チェック項目：①npm run build が通る ②npm test が全部パスする ③秘密情報（APIキー等）がコードに混ざっていない ④スマホ表示が崩れていない ⑤変な入力（空・長すぎ・記号だらけ）で壊れない ⑥SupabaseのRLS設定に漏れがない。結果を表形式で報告して、問題があれば修正案も出すように。

STEP5：仕上げの習慣——AIレビュー

もう1つ、コストゼロで効く習慣を。大きめの変更を頼んだあと、最後に「いまの変更に、バグ・セキュリティの穴・消し忘れがないかレビューして」と頼む。書いたAI自身に再点検させるだけで、見落としがかなり減ります。人間のプロの現場の「コードレビュー」を、AIとの開発に持ち込む習慣です。

おさらい：今日使った“言葉”

ビルド

文法とつながりの全ページ検査。赤なら公開されない＝最初の安全装置。

テスト（Vitest）

「これを入れたらこれが返るはず」を確かめる見張り番。npm test で実行。

公開前チェックの型

毎回同じ項目を機械的に。スキル化して1コマンドで呼ぶ。

AIレビュー

変更のあとに「バグや穴がないかレビューして」。仕上げの儀式。