Contents
まず結論
AIにコードを書かせて開発を進める「バイブコーディング」の落とし穴について書かれた記事を読み、その視点で自分の開発中アプリ（自社向けのビル管理ポータル）を見直したところ、「一般ユーザーが自分の権限を”管理者”に書き換えられてしまうかもしれない」という設計の穴が見つかりました。
まだ実装前、設計書の段階です。だからこそ、直すコストがほぼゼロで済みます。この「実装前に見つかった」こと自体が、今回の一番の学びでした。
読んだ記事の核心：「AIの出力品質は、指示する人の知識量に比例する」
記事の主張を初学者向けに言い換えると、こうなります。
AIはコードを書くことは代替できる。でも「何を確認すべきか」の判断は代替できない。知らないことについては、質問すら生まれない。
耳が痛い話です。私は非エンジニアで、AIの力を借りて開発しています。つまり「AIが書いたものの妥当性を、自分がどこまで疑えるか」が、そのまま自分のアプリの品質の上限になります。
その視点で設計書を見直したら、穴が見つかった
私のポータルには、管理者・一般利用者など複数の役割（ロール）があり、「誰が何をできるか」を一覧にした権限マトリクスを、実装前に設計書としてまとめてあります。データベース側にも、行単位でアクセスを制御する仕組み（RLS）を設計済みです。
問題はその中の1行でした。ユーザー情報のテーブルに「更新は自分自身のみ可」というルールを書いていたのです。一見、安全に見えます。自分の情報しか触れないのだから。
でも、ユーザー情報のテーブルには「ロール」の列も入っています。つまりこのルールのままだと、一般利用者が「自分自身の情報の更新」として、自分のロールを管理者に書き換えられてしまう可能性がある。いわゆる「自己昇格」の穴です。
対策自体はシンプルで、「自分の情報は更新できるが、ロール列だけは変更不可」という条件を足すか、ロール変更をサーバー側の処理に限定するかです。難しいのは対策ではなく、「そこを疑う」という発想を持てるかどうかのほうでした。まさに「知らないと質問すら生まれない」の実例です。
なぜ「今」見つかったことに価値があるのか
認証や権限まわりは、後から直すコストが最も高い部分です。ログイン画面や画面の出し分けなど、すべての機能が権限設計の上に乗るので、土台を後から変えると影響が全部に連鎖します。読んだ記事の筆者も、認証基盤を作り直したら被害が連鎖した、と書いていました。
私の場合、まだテーブルにデータが入る前、設計書の段階です。設計書の1行を直すだけで済む。同じ穴でも、見つかるタイミングで修理費がまったく違うわけです。
「設計書を先に書く」は、初学者にこそ効く
今回の発見ができた理由を考えると、権限マトリクスやポリシーを実装前に文書として書き出してあったことに尽きます。文書になっていたから、記事の視点を当てて「この行、怪しくないか」と点検できた。頭の中やAIとのチャットログの中にしか無かったら、点検のしようがありませんでした。
合わせて、記事からもうひとつ持ち帰ったことがあります。「コードの外」の作業──プライバシーポリシーや個人情報の扱い、バックアップ方針など──は、初学者が存在自体を見落としやすい、という指摘です。実装はまだしなくていいので、箇条書きのメモだけ設計書の隣に置いておくことにしました。
おわりに
今週、このアプリのコードは1行も進んでいません。でも「実装してから気づいた」と「実装する前に気づいた」の差を考えると、進捗としてはむしろ大きい週だったと思っています。
AIと開発する時代に自分がやるべきことは、コードを書く速さではなく、設計を文書にして、疑いの目で点検すること。それなら非エンジニアの自分にも積み上げられる、と少しだけ自信になった話でした。
Supabase / RLS / 設計 / 個人開発
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
