あれから2週間。予告どおり、認証と掲示板を追加して、本番公開までこぎ着けた。今回はその記録だ。
Contents
何を足したのか
これまでの tensho-portal は、Phase 3（AIによる予測）まで動いてはいたが、「誰でも全部見られる」状態だった。実際に会社で使うなら、それでは困る。今回のヤマは2つだった。
① ログイン機能 ── 立場で見える画面を変える
管理する人、現場で動く人、入居している人。立場によって、見せるべきもの・できることは違う。そこで「ロール」という役割をユーザーごとに持たせて、ログインした後の画面を切り替える仕組みを入れた。
管理者だけがユーザーを追加できる。現場の人は状態の更新ができる。入居者は読むのが中心。こうした分担を、コードの中の「権限の表」として一枚にまとめてから実装した。表を先に作ったことで、AIに伝えるときの迷いがほぼ消えた。
② 掲示板機能
「設備のこと」「住人どうしの交流」「その他」というカテゴリを作り、スレッドを立てて返信できる、よくある掲示板だ。誰が書いたか・誰が消せるかがきちんと制御できるのは、①のログインという土台があってこそだった。順番を間違えなくてよかったと思う。
つまずいた話 ── 環境変数で本番だけ動かない
本番公開（デプロイ）の作業で、見事に詰まった。原因は「環境変数」、つまりAPIキーなどの秘密情報の設定だ。
厄介なのは、この設定が「自分のPC（ローカル）」と「本番のサーバー」の2か所にあること。手元では動くのに、本番だけエラーで止まる。よく調べたら、本番側に必要な鍵を1つ設定し忘れていた。
ここで改めて感じたのは、AIに開発を手伝ってもらうとき、一番ハマるのは「AIからは見えない場所」のトラブルだということ。コードの中身なら貼り付けて直してもらえる。でも本番サーバーの設定画面は、AIには見えない。自分の手で確認するしかない。
この2週間で学んだこと
振り返ると、学びは2つに集約される。
1つは 「土台を先に作る」。掲示板より先にログインを作ったから、誰の投稿かを管理できた。順番が逆だったら作り直しだった。
もう1つは 「AIに見えない領域は、自分が見る」。環境変数のような外側の設定は、結局のところ人間の仕事として残る。ここを面倒くさがらないことが、本番公開の関門だった。
会社のExcelと電話で回していた仕組みを、自分の手で「ログインして使えるWebシステム」にできた。地味だが、半年前の自分には想像できなかった景色だ。次はこれを、もし他社にも使ってもらうなら何が必要か、要件を整理してみたい。
Next.js / Supabase / Claude API / Vercel
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
