AIに手伝ってもらいながら、業務用のアプリをつくる。画面ができて、ログイン画面もちゃんとあって、「よし、これで安全」と思う。
私は最初、そう思っていました。でも、あるとき気づいたんです。「ログインできる」ことと「この情報を見ていい」ことは、まったく別の話だということに。
この記事では、その2つの違いを、日常の例えと図で整理します。専門用語は「認証」と「認可」の2つだけ。覚えるのはそこだけで大丈夫です。
まず、ひとことで
- 認証：あなたは誰？（本人確認）
- 認可：あなたは何をしていい？（権限の決定）
ビルの受付で考えてみる
オフィスビルを想像してください。
① 受付で本人確認（認証） 社員証や顔、パスワードなどで、「この人は確かに◯◯さんだ」と確かめる。確認できたら、入館証をもらえます。
② 入れる場所を決める（認可） 入館証を持っていても、全部の部屋に入れるわけではありません。
- 1階ロビー：誰でもOK
- 営業部フロア：営業の人だけ
- 経理部フロア：経理の人だけ
- 社長室：社長だけ
「入館証を持っている（認証済み）」ことと、「経理部フロアに入っていい（認可）」ことは、別のルールで決まっています。
アプリも同じです。
アプリで起きること：同じ画面、違う見え方
取引先ごとの請求書を管理するアプリを考えます。A社の経理の人も、B社の経理の人も、同じ画面からログインします。
| だれ | ログイン（認証） | 見ていい範囲（認可） |
|---|---|---|
| Aliceさん（A社の経理） | ○ できた | A社の請求書だけ |
| Bobさん（B社の経理） | ○ できた | B社の請求書だけ |
| ログインしていない人 | × できない | 何も見えない |
AliceさんもBobさんも「ログインできる」。でも見ていいのは、自分の会社の分だけ。
もし、認可がうまくできていないと、どうなるでしょう？ ログインさえできれば、他社の請求書も見えてしまう。 場合によっては、ログインしていない人にも見えてしまう。
ちょっと怖い話：私が試したときのこと
私は、小さなデモアプリで、わざと「見ていい人のルール」を入れないで試してみました。ログインしていない人の目線で、請求書の一覧を見てみたところ…。
A社の請求書も、B社の請求書も、4件ぜんぶ見えてしまいました。
ログイン画面があっても、その奥のデータの守りがなければ、誰でも見えてしまうことがある。ここは、実際に見て、ヒヤッとしたところです。
そのあと、「自分の会社の分だけ見える」ルールを入れました。同じ操作をもう一度やると、
- ログインしていない人：0件
- Aliceさん：A社の2件だけ
- Bobさん：B社の2件だけ
になりました。同じ質問なのに、人によって答えが変わる。これが、認可の役割です。
さらに、AliceさんがB社の請求書を書き込もうとしたら、きちんと拒否されました。「見る」だけでなく「書く」側も、認可の対象です。
「エラーが出ない」は安全の証拠ではない
もうひとつ、私が勘違いしたことがあります。
AliceさんがB社の請求書を追加しようとしたとき、最初はエラーが出ませんでした。「通っちゃった？」とあわてました。
実際は、「AliceさんにはB社そのものが見えない」ので、「B社の請求書を追加する」という操作が、対象が見つからず、何も起きなかっただけでした。
つまり、エラーが出ない＝安全が確かめられた、ではない。見えないものは、「ない」ことになるので、静かに何も起きないことがある。だから、「ちゃんと拒否されるか」を、わざと試してみることが大切だと感じました。
認証と認可、アプリのどこで出会う？
認証（あなたは誰？）に出会う場所 – ログイン画面 – 「Googleでログイン」 – パスワードのリセット – 二段階認証のコード入力 – 「このメールアドレスは確認済みです」
認可（何をしていい？）に出会う場所 – 管理者だけが見る設定画面 – 「閲覧のみ」と「編集できる」の違い – 他社のデータは見えない – 承認ボタンを押せる人は課長以上 – 有料プランだけ使える機能
困りごとが「入れない」なら認証、「見えすぎ・見えない」なら認可、であることが多いです。AIに相談するときも、この区別をしておくと、話が早くなります。
「お客さまごとにデータを分ける」2つの考え方
お客さまが増えると、「データをどう分けるか」を考えることになります。大きく2つあります。
A. 1つの建物に、部屋ごとの鍵（マンション型） – 管理は1か所。更新も1回で済む – ただし、「どの鍵で、どの部屋に入れるか」のルールを、きちんと設計する必要がある – ルールの書き間違いがあると、他の部屋が見えてしまう
B. お客さまごとに、別の建物（一戸建て型） – 完全に別々なので、とても安全 – ただし、建物の数だけ、管理・更新・お金がかかる
私は両方、小さく試してみました。Bは、実際にお客さま用の「別の建物」を1つ増やしてみて、作業が建物の数だけ増える感覚をつかみました。一方でAは、ルールを一度ちゃんと書けば、お客さまが増えても同じ建物で済む。ただし、そのルールが本当に効いているかは、自分で確かめる必要がありました。
どちらが正解ではなく、お客さまの数・求められる安全度・運用できる人数で決まります。たとえば、
- お客さまが多くて、機能は共通 → マンション型が向きそう
- 数は少ないけれど、契約で「完全に別」が必須の大口 → 一戸建て型が向きそう
AIに頼むときの言葉
AIアシスタントと一緒にアプリをつくるとき、こんな聞き方ができます。
- 「ログインしているユーザーごとに、見られるデータを分けたい。そのルールを作ってほしい」
- 「ログインしていない人が、データを見られないか確認してほしい」
- 「A社の人がB社のデータを書き込もうとしたら、拒否されるか試してほしい」
- 「お客さまは何社くらいになりそう？ マンション型と一戸建て型、どちらが向いている？」
ポイントは、「認証」と「認可」を別々に確認してもらうこと。「ログインできた」だけで終わらせず、「ログインした後、何が見える？」まで確認することです。
私が確かめられていないこと
正直に書いておきます。
- 実際のアプリ（ブラウザ）からログインして確かめたわけではなく、ログイン済みの状態を再現して確認しました
- お客さまが何百社・何千社になったときの、速度や運用の負担
- 一戸建て型の、データの移行や日々の運用の大変さ（数を増やしてみただけで、運用は測っていません）
- 「管理者」「閲覧のみ」など、より細かい役割分担
まとめ
- 認証＝あなたは誰？（本人確認）、認可＝何をしていい？（権限）
- 「ログインできる」と「見ていい」は別の話
- 認可がないと、ログインしていない人にも見えてしまうことがある
- 「エラーが出ない」は「安全」とは限らない。わざと拒否されるか試す
- お客さまごとのデータの分け方には、マンション型と一戸建て型がある。どちらが正解かは、状況しだい
「ログイン画面があるから大丈夫」と思ったとき、一度だけ、「ログインした後、誰に何が見える？」と聞いてみてください。それだけで、見落としはぐっと減ると思います。
もっと詳しく知りたい方へ（技術編・Qiita）
実際に手を動かした記録を、Qiitaに書きました。
Leave a Reply