権限の一覧を書き出した紙を前に、抜けているところがないか落ち着いて考えている開発者
設計・レビューでのAI活用約15分

AIに認証・認可の設計を相談する｜権限モデルの穴を潰す詰め方

権限まわりの設計をひとりで任されると、少し身構えますよね。機能の実装なら、間違えても直せばいい。でも認可を間違えると、直したときにはもう、見えてはいけないデータが誰かに見えたあとかもしれない——そう思うと、決めるのが怖くなります。

だからAIに相談する。これはとてもいい判断だと思います。実際、AIに「この業務の権限モデルを設計して」と頼むと、役割と操作がきれいに並んだ立派な表が返ってきます。読むと、なんだか安心してしまう。

ただ、ここで少しだけ立ち止まりたいのです。認可の事故は、その表の中では起きません。表の外側で起きます。 この記事では、いま何が起きているのかを共有したうえで、AIを「権限表を書く相手」ではなく「穴を探させる相手」として使う手順を整理します。

結論：AIに認証・認可を相談するときの要点は3つです。①先に自分で「誰が・何を・どのデータに・どんな条件で」の4点セットを3行だけ書く——AIに案を出させるのは、そのあとです。②AIには「設計して」ではなく「この表で許してしまう、意図しない操作を挙げて」と反証を頼む。とくに「他人のIDを入れたら」「一覧ではなく1件取得なら」「状態が変わったあとなら」の3つを名指しで聞きます。③実装前に、通ることではなく〈弾かれること〉のテストを先に並べる。認可のテストは、異常系のほうが本体です。

AIが得意なのは、それらしく整合した権限表を作ることです。苦手なのは、その表に書かれていない操作を想像することです。そこだけ人が持てば、あとは大いに頼れます。

いきなり全部は要りません。まずは①の3行からで大丈夫です。

何が起きているのか——穴は「表の外」に空く

入口での本人確認と、1件ごとの持ち主確認の違い、そして他人の分に手が届いてしまう場面を並べた図
入口を通せたかどうかが認証、1件ごとに「それはあなたのものか」を見るのが認可。抜けやすいのは、いちばん右です

まず、なぜここだけ気を張る必要があるのかを共有させてください。理由は3つあります。

1つ目は、「認証」と「認可」が混ざりやすいこと。認証は「あなたが誰か」を確かめること。ログインがこれにあたります。認可は「その人が、その操作をしてよいか」を判断することです。図の左と中央の違いですね。ログインを通ったこと自体は、「入口を通れた」という以上の意味を持ちません。ところが会話の中では両方まとめて「権限」と呼びがちで、AIに相談するときもここが混ざったまま渡ってしまいます。混ざったまま設計すると、「ログインしていれば見られる」に近い作りが、誰も意図しないまま残ることがあります。

2つ目は、AIが「一覧」までは守るのに「1件」で抜けやすいこと。これがいちばん多い型です。「自分の担当分だけ表示する」という一覧の実装は、AIもきちんと書きます。ところが、その一覧から開く1件取得のほうで、渡されたIDが本当にその人のものかを確かめる処理が抜ける。画面上は自分の分しか出ないので、テストでも気づきません。でも、URLやリクエストのIDを別の番号に書き換えれば、他人の1件が返ってきます。図のいちばん右がこれです。

この型には名前がついていて、オブジェクトレベル認可の不備（BOLA、古くはIDORとも呼ばれます）といいます。OWASPが公開しているAPIのセキュリティリスクの一覧でも、長く筆頭に置かれ続けている類型です。珍しい失敗ではなく、慣れたチームでも出るものとして扱われている、と考えておくと気が楽になります。

3つ目は、画面で隠すことが認可ではないこと。ボタンを非表示にする、メニューから消す——これは親切さの話であって、防御ではありません。APIは直接呼べます。ここも、AIに「管理者以外にはこの操作を出さない」と頼むと、画面側だけ直して満足のいく答えが返ってくることがあります。AIが手を抜いたわけではなく、頼み方が画面の話に見えていただけです。

この3つが重なると、「権限表はきれいに揃っているのに、1件取得だけ素通り」という状態ができあがります。逆に言えば、認証と認可を分けて書き、1件ごとの持ち主確認を明示し、画面ではなくサーバ側で判断する——これだけで、かなりの部分は防げるということです。

具体例——AIの権限表が、こう抜ける

実際に起きやすいのは、次のような形です。一つでも心当たりがあれば、この記事はそのまま使えます。

どれも、注意力が足りなかったから起きるわけではありません。認可の抜けは「何も起きない」という形で現れるので、動かして確かめる普段のやり方では見つからないというだけです。見つけにくいものを見つけようとしている——そう捉えるほうが、実態に近いと思います。

影響——気づくのが、外から言われたとき

認可の抜けが厄介なのは、失敗として自分から現れてくれないところです。

ただ、ここは強調しておきたいところなのですが、この種の抜けは、設計の段階なら本当に安く塞げます。実装前に「他人のIDを入れたらどうなるか」を一度声に出して確かめるだけで、多くは事前に見つかります。あとから探すのは大変ですが、先に問うのは1分で済む。いま設計の手前でこの記事を読んでいるなら、それはいちばん安いタイミングにいるということです。

なお、権限の判断が実際にデータの絞り込みまで届いているかは、SQLまで見ないと分からないことがあります。生成されたクエリの確かめ方はAIに書かせたSQLを本番前に確かめる｜見落としやすい確認点にまとめてあります。

明日からやること（3ステップ）

大きな設計変更は要りません。この順番で、今日から小さく始められます。

1. AIに聞く前に、自分で3行書く

いきなり「権限モデルを設計して」と頼まないほうが、結果はよくなります。先に、4点セットで3行だけ書きます。

誰が・何をする・どのデータに対して・どんな条件のとき

例：

書いてみると分かるのですが、難しいのは3つ目の「どのデータに対して」です。ここが「案件を閲覧できる」で止まっているうちは、それは役割の話であって、認可の設計にはなっていません。3つ目を必ず埋める、それだけを守ってください。この3行が、このあとAIに渡す素材そのものになります。

なお、この段階で実際の顧客名や社内の権限データを貼る必要はありません。役割名は仮名で十分です。何をAIに渡してよいかの線引きはAIに機密情報を入力する前に｜業務で守りたい境界の引き方を下敷きにしてください。

2. 「設計して」ではなく「穴を挙げて」と頼む

3行を渡したうえで、反証を頼みます。案を出させるのではなく、自分の案を攻めさせる、という向きです。設計を相談するときの問いの立て方そのものはAIを設計の壁打ち相手にする問いの立て方と同じ考え方です。

そのまま使える頼み方の例：

以下は、あるシステムの権限ルールです。設計案は出さなくて結構です。 このルールで許可されてしまう、意図しない操作を挙げてください。とくに次の3つの観点から、それぞれ具体的な操作の手順として書いてください。

1. 他人のIDを直接指定した場合（一覧ではなく、1件の取得・更新・削除・添付ファイルの取得）
2. 一覧・詳細以外の出口（検索、CSV出力、一括操作、印刷用画面、通知メールの本文、外部連携）
3. 状態や時間が変わった場合（担当を外れたあと、退職・異動のあと、案件が終了したあと、代理権限の期限が切れたあと）

それぞれについて「どのルールが足りないからそうなるのか」を1行で添えてください。

ルール：
（ここに3行）

ポイントは、「設計案は出さなくて結構です」と先に伝えることです。これがないと、AIは指摘のあとに親切な改善案を並べてくれて、そちらに目が行ってしまいます。いま欲しいのは案ではなく、自分が見落としている操作の一覧です。

返ってきたら、そのまま信じずに1つずつ「これは実際に起こせるか」を確かめてください。AIは、存在しない画面や使っていない機能を前提にした指摘も混ぜてきます。指摘の選り分け方はAIレビューの指摘を取捨選択する｜直す・直さないの判断軸が使えます。全部に対応する必要はありません。 自分たちのシステムで実際に起こせるものだけを拾えば十分です。

役割の数が増えすぎて苦しくなってきたら、もう一段だけ聞いてみる価値があります。「役割を増やさずに、データの属性や関係で表現できないか」という問いです。担当者かどうか・所属部署が一致するか、といった条件で判断する考え方（属性ベース、関係ベースと呼ばれます）や、権限のルールをコードとは別のファイルで管理するやり方があります。小さいうちに導入する必要はまったくありませんが、「役割を足す以外の道もある」と知っているだけで、20個目の役割を作る前に立ち止まれます。

3. 実装前に「弾かれること」のテストを並べる

認可のテストは、できることより、できないことのほうが本体です。ここもAIが手伝えます。

上で挙がった意図しない操作について、それが拒否されることを確かめるテストケースの一覧を表にしてください。列は「操作」「実行する人」「対象データ」「期待する結果（拒否 or 許可）」の4つでお願いします。許可されるべきケースも、同じ数だけ入れてください。

拒否だけ並べると、締めすぎて正当な利用者まで弾く作りになりがちです。両方を同じ数だけ並べるのがコツです。境界のケースを洗う考え方はAIに境界値・異常系を考えさせて漏れを減らす手順がそのまま応用できます。

このとき、実装側で1つだけ決めておくと後がずっと楽になります。判断を1か所に集めて、既定を「拒否」にすることです。処理ごとに書くのではなく、共通の場所で「明示的に許可されていなければ通さない」としておけば、新しい処理を足した人が書き忘れても、素通りではなく拒否になります。書き忘れが「見えてしまう」ではなく「使えない」として現れる——この差はとても大きいです。使えなければ、すぐ誰かが言ってきますから。

おまけ：AIエージェントが人の代わりに操作するとき

最近は、AIが自分でAPIを呼んで作業を進める形も増えてきました。このとき認可には、もうひとつの問いが増えます。「それは、誰の権限で動いているのか」です。

運用を楽にしようとして、エージェントに強い共通の権限を1つ持たせると、依頼した人が本来触れないデータにまで手が届く経路ができます。エージェントの権限は、依頼した人の権限を超えないところから始めるのが素直です。加えて、誰の依頼で何をしたかが後から追えるように記録を残しておくと、困ったときに助かります。この線引きの考え方はAIエージェントにどこまで任せるか｜暴走させないガードレールの引き方にまとめてあります。

3つとも今日やる必要はありません。ステップ1の3行を書くだけでも、次の相談の返りがはっきり変わります。

認証・認可の設計チェックリスト

全部に○が要るわけではありません。気になった行だけで十分です。

① AIに相談する前に

② AIへの問いかけで

③ 実装に移る前に

この記事のまとめ

AIは権限モデルの相談相手として、とても優秀です。ただ、得意なのは「整合した権限表を作ること」であって、「その表に書かれていない操作を想像すること」ではありません。書かれていないものは、渡していない情報だからです。

やることは3つだけです。①「誰が・何を・どのデータに・どんな条件で」を自分で3行書く／②「設計して」ではなく「この表で許してしまう操作を挙げて」と反証を頼む／③実装前に、弾かれることのテストを並べる。この3つがあると、認可の設計は「祈りながら実装する作業」から、「決めて確かめる作業」に変わります。

権限の抜けをひととおり洗い出し終えて、安心した表情で顔を上げている開発者

権限の設計を怖いと感じるのは、それが誰かの信頼を預かる場所だと分かっているからだと思います。その感覚は、設計者としてかなり正確なものです。今日ひとつ「他人のIDを入れたらどうなるか」を問えたなら、それだけで、あとから誰かが青ざめる夜をひとつ減らしています。

よければ、こちらも

関連用語