転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。
使うのは自分1人です。
それでも、データベースに行レベルセキュリティ（RLS）を入れると決めました。
理由は「権限設計を語れるようにするため」です。
就職活動の題材なので、1人用の構造にすると権限の話ができなくなります。
この判断自体は、今も正しかったと思っています。
そこからRLSのポリシーを何本も足しました。
「誰に何を許すか」は自分が決め、初期のテーブルは手順書を見て自分で書き、公開後に足した分は判断だけ自分がしてAIに書いてもらいました。
どのテーブルも「ログイン中の人が持ち主なら許可」という1行で済み、意味も分かっているつもりでした。
「RLSはそういうものだ」と思っていました。
3週間ほど経って、2つのことが続けて起きました。
1つ目: 理解していないことが、3週間表に出なかった
判断したのは7月30日です。
「SQL難しいな。正直まだ理解できないところがある」と自分が言ったのは、8月20日でした。
その間ずっと動いていて、実装は完成し、公開もされ、テストも通っていました。
表に出たきっかけは、AIが「3問に口で答えてください」という関門を作ったことです。
自分がコードを読まないまま本番のポリシーが変わる工程だったので、その手当てでした。
1問目で外しました。
必要がないものを入れると、必要がないぶん、理解が後回しになります。
1人しか使わないので、間違っていても誰も困りません。
困らないから、確かめる場面が来ませんでした。
2つ目: 新しいテーブルを足したら、1行で書けなくなった
これまでのテーブルは、どれも「持ち主」の列を自分で持っていました。
だからポリシーは「ログイン中の人＝持ち主」という1行で済んでいました。
今回のテーブルは、持ち主の列を持っていません。
親を見に行かないと、誰のものか分かりません。
しかも公開ページに出すので、「持ち主か」ではなく「そのカードが公開されているか」で判定が要ります。
さらに親を辿ります。
結果、2段辿るポリシーになりました。
手順書に書き方は示してあり、事前の3問にも答えられていました。
それでも貼る直前にAIから「この文を説明できますか」と聞かれて、答えられませんでした。
この論点は、設計のときに「持ち越し」として残していました。
当時のテーブルでは論点が発生しなかったので、判断を先送りできていました。
「書けている」と「分かっている」は別だった
1行のポリシーは、意味を追えていたので書けていました。
でも「なぜ1行で済むのか」までは考えていませんでした。
難しさが出てこなかったのは、難しくなる形をまだ作っていなかったからです。
形が揃っているあいだは、そこまで理解していなくても書けて、動きました。
正しい判断にも、支払いがあります。
「だからやめよう」ではありません。
実際、その場で説明を受けて理解は進みました。
支払う時期が選べただけです。
先送りにしてあった論点は、先送りできる形のうちは正しく先送りできます。
形が変わった瞬間に、返ってきます。
