家族用の記録アプリを作ったとき、機能よりも時間をかけたことがあります。

セキュリティです。

非エンジニアの私がセキュリティと言うと、大げさに聞こえるかもしれません。 でも、考えてみてください。

そのアプリに入っているのは、家族の名前と、日々の記録です。 便利さのために作ったもので家族の情報が漏れたら、本末転倒どころの話ではありません。

専門家のような高度な対策はできません。 それでも、非エンジニアなりに「ここだけは」と決めて守った基本があります。 今日はその記録です。

この記事で分かること
1

家族アプリで最低限守るセキュリティ3原則

2

APIキーなど「秘密の鍵」の置き場所のルール

3

非エンジニアがAIにセキュリティを確認させる方法

原則1：誰でも見られる場所に置かない

最初に決めたのは、入口の話です。

URLを知っていれば誰でも見られる状態にはしない。

「URLは家族しか知らないから大丈夫」と思いたくなりますが、URLは秘密の鍵にはなりません。 ブラウザの履歴、共有した時のリンク、思わぬところから人の目に触れます。

だから、ログインを必須にしました。 家族それぞれにアカウントを作り、ログインしないと何も見えない設計です。

AIに頼むときは、最初の要件にこう入れました。

ログインした人だけが使えるアプリにしてください。 ログインしていない状態では、データが一切見えないようにしてください。

この一文を最初に言うのが大事です。 あとからログインを足すのは、最初から組み込むより、ずっと面倒になります。

家族用アプリの入口設計を示した図。URLを知っていれば見られる状態はNG、ログインした家族だけが見られる状態がOK

原則2：秘密の鍵はコードに書かない

開発を進めると、APIキーという「秘密の鍵」がいくつか手元に増えます。 データベースにつなぐ鍵、サービスを呼び出す鍵。

これをコードの中に直接書くと、どうなるか。

コードをAIに見せた瞬間、鍵もAIに渡ります。 コードをGitHubに置いた瞬間、設定を間違えれば鍵ごと公開されます。

家に例えると、合鍵を玄関ドアにテープで貼っている状態です。

ルールは1つだけにしました。

鍵は .env というファイルに入れる。コードには書かない。

.env は「秘密のメモ帳」のようなファイルで、コードからは「メモ帳のあれを見て」という形で参照します。 そして .env 自体は、GitHubに上がらないように除外設定（.gitignore）に入れておく。

AIへの頼み方も決まり文句にしています。

APIキーやパスワードは.envファイルに入れて、コードには直接書かないでください。 .envは.gitignoreに追加してください。

意味が完全に分からなくても、この2行を言えれば守れます。 私も最初は呪文として唱えていました。今は意味も分かります。順番はそれでいいんです。

APIキーの管理ルールを示した図。コードに直接書くと共有や公開で鍵ごと漏れる。.envファイルに分けて、.gitignoreで公開対象から除外するのが基本

原則3：見える範囲を「本人の分だけ」にする

ログインを付けて安心しがちですが、もう一段あります。

ログインした人が、他の人のデータまで見えてしまわないかです。

家族用アプリならまだ笑い話で済むかもしれません。 でも、設計の癖として「ログインした本人のデータだけが見える」を最初から当たり前にしておくと、あとで何を作っても安全側に倒れます。

データベース側にも、この制御の仕組みがあります（Supabaseなら行レベルのアクセス制御）。 仕組みの名前を覚える必要はなくて、AIにこう聞けば十分です。

このアプリは、ログインした本人のデータしか見えない設計になっていますか？ なっていない場合、どこを直せばいいですか？

仕上げに、AIに「攻撃側」をやらせる

ひと通り作ったあと、最後にやったことがあります。

AIに、自分のアプリの粗探しをさせました。

このアプリのセキュリティ上の弱点を、思いつく限り挙げてください。 非エンジニアにも分かる言葉で、危険度の高い順にお願いします。

出てきた指摘のいくつかは対応済みのものでしたが、「ログイン試行の回数制限がない」など、考えてもいなかった指摘もありました。

作るのを手伝ったAIに、今度は疑う側をやらせる。 非エンジニアのセキュリティチェックとして、これが一番現実的な方法だと思います。

AIにセキュリティチェックをさせる流れを示した図。作る相手としてのAIと、弱点を探す監査役としてのAIを使い分け、指摘に危険度順で対応する

それでも、専門家のチェックには敵いません。 だから私は、守れる自信がない情報はそもそも入れないことも、対策の1つに数えています。 このアプリを一般公開しないと決めた理由も、根っこは同じです。

→ 非エンジニアがAIでWebアプリを作ったあと、一般公開しないと決めた理由

まとめ：家族の情報を扱う資格は「基本を守ること」

非エンジニアの私が守ったのは、結局この4つだけです。

  • ログイン必須にする（URLを鍵代わりにしない）
  • 秘密の鍵は.envに入れて、コードに書かない
  • 本人のデータだけ見える設計にする
  • 最後にAIへ「弱点を挙げて」と聞く

高度なことは何もしていません。 でも、この基本だけで、家族用アプリとしては安心して使える状態になりました。

アプリを作った経緯はこちらに書いています。

→ AIと一緒に家族用の記録アプリを作ってみた話

AIが書いたコードを鵜呑みにしない話は、こちらもどうぞ。

→ AIにコードを書いてもらうとき、丸投げすると危ない理由

SupabaseやVercelといった道具の役割を先に押さえておきたい人は、こちらから。

→ SupabaseやVercelを使う前に、非エンジニアが理解しておきたいこと

便利なものを作る力と、それを安全に保つ責任は、セットです。 家族の「ありがとう」を守るためにも、基本の4つだけは最初から組み込んでください。

よくある質問

家族しか使わないアプリでも、ログインは必要ですか？
必要です。URLは秘密の鍵の代わりになりません。履歴や共有リンクから思わぬ形で人の目に触れる可能性があるので、ログインした人だけが見られる設計を最初から入れましょう。
APIキーをコードに書いてしまいました。どうすればいいですか？
.envファイルに移動させた上で、書いてしまったキーはサービスの管理画面から再発行（無効化）するのが安全です。AIに「このキーをローテーションする手順を教えて」と聞けば案内してくれます。
非エンジニアにセキュリティ対策は無理ではないですか？
専門家レベルは無理でも、ログイン必須・鍵の分離・本人のデータだけ見える設計、という基本は決まり文句で守れます。さらに「守れない情報は入れない」という判断も立派な対策です。
AIにセキュリティチェックを頼むときのコツはありますか？
「弱点を危険度の高い順に、非エンジニアにも分かる言葉で挙げて」と頼むことです。作らせたAIに疑う側もやらせると、自分では気づけない穴が見つかります。
健康情報など、センシティブな記録を入れても大丈夫ですか？
扱いの難易度が一段上がります。基本対策に加えて、本当にアプリに入れる必要があるか、漏れたときの影響はどの程度かを先に考え、自信がなければ入れない判断も検討してください。