AIアプリを本番公開するための認証設計｜ログインと権限を分ける理由

1. ログインが通ることと、資料を見られることは別の確認

認証は利用者の本人性を確認すること、認可は要求された操作を許可してよいかを判断することです。OWASPは両者を区別し、認証済みの利用者にもアクセスできない資源があると説明しています。ログイン画面を付けただけで、全員に同じ資料や機能を見せてよいとは限りません。（参考資料[1]）

説明用に、社内文書を探して要約するAIアプリを考えます。営業担当者がログインできても、人事担当者だけが扱う文書を読める必要はありません。この例で先に決めるのは、ログイン方式の名前ではなく、どの人に、どの資料の、どの操作を許すかです。試作段階で便利だった『全員が全件を検索できる』という設定を、業務上必要な範囲へ置き換える判断が求められます。これは特定企業の実績ではなく、要件整理のための架空の業務例です。

• 本人確認と、個々の資料への許可を別の項目として記録する。
• アプリ全体の安全性を、ログイン画面の有無だけで判断しない。

2. 役割だけでなく、対象と操作を言葉にする

権限表を作るときは、『管理者』『一般利用者』という役割名の横に、閲覧・編集・出力などの操作と、その操作を許すデータの範囲を書きます。例えば『担当者は自分の組織の案件を閲覧できる』『承認者は所属組織の案件を更新できる』というように、対象を含めて合意する方法が考えられます。役割名が同じでも、所属組織が違えば扱える案件も違うという前提を、画面の説明と開発側の実装条件の両方へ渡すためです。

OWASPの業務ロジックに関する資料は、対象の所有関係を要求のたびに確認し、利用者が送ってきたユーザーID・組織ID・役割を無条件に信頼しないよう示しています。（参考資料[4]）この考え方を上の業務例に当てはめるなら、入力欄で選ばれた組織名をそのまま許可の根拠にせず、アプリ側で確認した所属や許可範囲と照合する設計を検討します。担当者の兼務や代理操作がある場合は、誰の権限で実行した扱いにするかも要件に残します。

• 利用者・対象データ・操作を一組で説明できるようにする。
• 兼務や代理操作を、例外という名前だけで済ませない。

3. ボタンを隠すだけで終わらせず、実際の操作を守る

画面のボタン表示は利用者を案内するために役立ちますが、データへの操作を許す判断と混同しないことが必要です。OWASPの認可パターンは、保護する資源に近い場所で、操作・対象・組織を確認し、要求ごとに許可を検査する考え方を示しています。（参考資料[3]）開発時の確認では、一覧画面だけでなく、個別の詳細表示や出力機能も同じ要件で守られているかを見ます。

例えば案件一覧から別組織の案件が消えていても、詳細表示を担当する処理で同じ条件が使われているかは別に確認します。この例の受け入れ条件は、『一覧で見えなかった』に加え、『その利用者には許されない対象を指定しても内容が返らなかった』まで書くと具体的です。また、権限の確認に必要な情報が欠けている場合の扱いも決めます。OWASPは、認可の結果が欠けていることや確認失敗を、制限なしの許可として扱わないよう説明しています。（参考資料[5]）

• 一覧・詳細・更新・出力を、同じ権限表で確認する。
• 確認に必要な情報がない場合の処理を決める。

4. アカウントを止めた後のログイン状態も確認する

利用を終えた人への対応では、アカウントの状態と、すでに成立しているログイン状態の両方を確認します。OWASPのセッション管理資料は、セッションの有効期限や失効をサーバー側で扱い、ログアウトや期限切れの際にセッションを無効化する必要性を説明しています。（参考資料[2]）ブラウザを閉じたことだけを、確実にログアウトした証拠として扱う設計は避けます。

情シスの確認表には、『新たなログインができない』『開いたままの画面から再度操作するとどうなるか』『役割変更後にどの許可が適用されるか』を分けて残す方法が考えられます。何分で失効させるかは、扱う情報と利用のしやすさを含めて決める項目です。特定の時間を全アプリ共通の正解として当てはめるのではなく、業務側と開発側が、停止させる対象と確認手順を共有します。外部連携のトークンがある場合は、利用者のログイン状態とは別の管理対象として一覧に加えます。

• 利用停止後の新規ログインと、既存のログイン状態を分けて試す。
• 役割変更・ログアウト・期限切れの期待結果を記録する。

5. AIに渡す資料の範囲を、権限表からたどれるようにする

AIを使う文書検索では、回答の見た目だけを確認するのではなく、どの資料を処理対象にする設計なのかを整理します。ここでは『利用者に許された資料の範囲を決め、その範囲で検索・要約する』という設計案を考えます。これは任意のAI製品が自動で実現する機能を断定したものではありません。利用する検索基盤やAIサービスごとに、権限条件をどこで適用できるかを開発担当者と確認する前提です。

OWASPの認可結果と出力の扱いに関する資料は、一覧などのデータ経路でも許可条件を保ち、判定不能の対象を許可済みとして扱わないよう示しています。（参考資料[5]）その原則をこの設計案へ当てはめ、検索結果の候補・AIへ渡す資料・利用者へ返す回答という段階を確認項目に分けます。確認する業務例は、『別組織の利用者が似た質問をしたときに、どの資料が候補になるか』です。回答だけでは判断できない場合は、検証環境のダミー資料で処理対象を追えるようにしてから受け入れを確認します。

• AIへ渡す資料の範囲を、利用者の許可範囲と対応させる。
• 回答の印象だけで判断せず、検証用資料で対象を確かめる。

6. 成功する操作と、拒否する操作を対にして試す

受け入れ確認では、まず業務担当者と開発担当者が同じ表を見ることを目標にします。表の列は、利用者の役割、所属、対象データ、操作、期待結果、確認結果という形が考えられます。実在する従業員や顧客の情報を使わず、組織A・組織Bと検証用の案件を用意します。『閲覧者が自組織の案件を読む』『閲覧者が案件を更新する』『閲覧者が別組織の案件を読む』を別の行にすると、許可と拒否の両方を説明できます。

OWASPは、認可の単体・結合テストが権限処理の不備を見つける助けになる一方、それだけで専門的なセキュリティ検証を置き換えるものではないと説明しています。（参考資料[1]）この確認表も、認証と認可の受け入れ観点に限るものです。アプリ全体の安全性や本番公開の適否を保証する表ではありません。確認に失敗した行は、担当者と期待結果を見直して再確認します。画面が表示された、APIが応答したという結果だけで、その行の権限条件まで合格した扱いにはしません。

確認表を公開時だけの資料にしないことも、運用上の工夫として考えられます。新しい検索条件や出力機能を追加したら、どの行の期待結果が変わるかを担当者と確認し、変更前に合格した結果と区別して残します。例えば添付資料の一括出力を追加する場合は、一覧の閲覧確認をそのまま流用せず、出力対象と出力を許す役割の行を増やします。表の更新日と確認担当を残しておくと、後から仕様の判断と実際の確認をたどりやすくなります。

• 同じ役割で、自組織と別組織の対象を分けて試す。
• 閲覧できる場合でも、更新・出力の許可は別に確認する。
• 未確認や失敗の行を、合格の行と混ぜない。

7. 情シスから開発担当者へ渡す情報をそろえる

開発相談を具体的にするには、最初から認証方式の専門用語をそろえるより、業務上の違いを整理する方が進めやすい場合があります。誰が利用するか、どの組織に所属するか、何を見せるか、何を変更できるか、利用を止める場面はいつか。この五つを、匿名化した業務例とともに用意します。まだ決めていない項目は、仮の許可を事実のように書くのではなく、未確定の論点として残します。担当者の変更や組織再編も、運用時の確認対象に加える案が考えられます。

N2i AIアプリリリースの相談に持ち込む場合も、最初に共有するのはこの権限表や画面の想定で構いません。顧客情報の入った資料、実際のログイン情報、APIキーを説明資料へ貼る必要はありません。共有してよい範囲を決めてから、現在の試作で確認できた点と、本番向けに追加確認したい点を分けます。相談の内容や費用、対応範囲は個別に確認するもので、この記事のチェック項目を満たしたことだけをもって、特定の提供条件や成果を保証するものではありません。

• 匿名化した役割・対象・操作の表を用意する。
• 確認済み・未確認・未確定を分けて伝える。

よくある質問

試作アプリにログイン画面があれば、そのまま本番公開できますか？

ログイン画面だけでは判断できません。本人確認に加えて、各利用者がアクセスできる対象と操作を確認します。この記事は認証・認可の確認観点に限っており、アプリ全体の公開可否を保証するものではありません。

管理者と一般利用者の二種類だけでも権限表は作れますか？

役割が二種類でも、対象の組織や担当案件、閲覧・編集・出力を組み合わせて記録できます。まず実際の業務で異なる扱いが必要な場面を挙げ、役割名だけで説明しきれない条件がないかを確認する方法が考えられます。

AIが回答に資料を出さなければ、アクセス制御はできていますか？

回答だけでは、処理対象になった資料の範囲まで確かめられない場合があります。設計上どこで許可条件を適用するかを整理し、ダミーの資料を使って候補・入力・回答を確認する手順を、開発担当者と決めます。

情シスが最初の相談に用意するとよいものは何ですか？

利用者の役割、所属、対象データ、許可する操作、利用停止の場面をまとめた表が役立ちます。実際の個人情報や秘密値を含めず、試作で確認できたことと未確認の点を分けて共有します。

参考・関連資料

• [1] OWASP 認証と認可・権限検査 ↗
• [2] OWASP セッション管理と失効 ↗
• [3] OWASP リソースに近い場所での認可 ↗
• [4] OWASP 所有関係・本人と所属の検査 ↗
• [5] OWASP 一覧・キャッシュ・認可結果の扱い ↗

公式資料の確認日：2026-10-09。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。