この記事で押さえたいこと
- ログインの確認と、データへのアクセス権限の確認を分ける。
- 一覧画面だけでなく、添付・出力・外部連携も確認する。
- 担当変更や退職時に、権限とログイン状態を見直す。
ログインとアクセス権限は別に設計する
ログインは利用者を確認する仕組みです。一方、アクセス権限は、その人が特定の情報を見たり変更したりしてよいかを決めます。社員としてログインできても、すべての応募者情報や別部署の顧客情報を見られる必要はありません。
たとえば、担当者は自分の担当する顧客だけ、責任者は担当部署だけ、といった単位を決めます。複数の会社が使うサービスなら、会社の境界も必要です。画面で情報を隠すだけでなく、サーバー側の処理で利用者と対象データの関係を確認します。
OWASPの認可ガイドも、認証と認可を区別し、必要最小限の権限とリクエストごとの権限確認を推奨しています。公式資料を読む ↗
添付ファイル・CSV・録音にも同じ境界を設ける
一覧や詳細画面の確認だけでは、別の取り出し口を見落とすことがあります。履歴書の添付、CSV出力、通話録音の再生などは、利用者が直接データを受け取る機能です。ファイルのURLを知っていれば誰でも開ける状態になっていないかも確認します。
- 添付ファイル:本人や担当者だけが取得できるか。
- CSV出力:画面で許可した範囲を超えて出力しないか。
- 録音・文字起こし:必要な担当者だけが閲覧できるか。
- 共有リンク:期限や公開範囲が業務に合っているか。
テストには、ダミーデータと役割の違うテスト用アカウントを使います。自社が管理し、検証を許可した環境で、別の担当者の情報を取得できないことを確かめましょう。
担当変更と退職後のアクセスまで決める
権限は、作成時だけ決めればよいものではありません。異動、担当変更、退職に応じて見直す運用が必要です。アカウントを停止した後、すでにログインしている端末からアクセスが続かないかも確認項目になります。
| 場面 | 見直す項目 |
|---|---|
| 担当変更 | 顧客・応募者への担当権限、共有ファイル |
| 部署異動 | 部署の閲覧範囲、承認や出力の権限 |
| 退職・利用停止 | アカウント停止、既存ログインの失効、連携権限 |
| 外部委託の終了 | 期限付き権限、共有先、認証情報の取り扱い |
AIに渡す情報と、保存する情報を絞る
応募対応の要約や営業記録の分析にAIを使う場合も、目的に必要な情報を選びます。氏名や連絡先を渡さなくても要約できるのなら、送信前に除く設計を検討できます。入力と出力のどちらに個人情報が残るか、履歴をどれだけ保存するかも整理します。
AIの出力を社内へ共有する前には、誤った内容や不要な個人情報が含まれていないか確認する工程を設けます。漏えい等が疑われる場合には、個人情報保護委員会の公式案内を参照し、事実確認、被害拡大防止、報告・本人通知の要否を適切な担当者と検討してください。
役割別の権限表を、画面とAPIの共通ルールにする
権限の打ち合わせでは、「管理者なら何でもできる」とまとめず、閲覧・編集・出力・担当変更を分けて考えます。とくに個人情報を含むCSVや添付の取得は、一覧を見る権限と同じでよいかを業務責任者と確認しましょう。一括出力を許可する人数を絞るだけでなく、何を出力したかを後で確認できる記録も検討します。
| 操作 | 担当者 | 責任者 |
|---|---|---|
| 詳細の閲覧 | 自分の担当分 | 担当部署の範囲 |
| 連絡履歴の編集 | 担当分の許可された項目 | 部署の許可された項目 |
| CSV出力 | 業務上必要な場合のみ | 承認した範囲のみ |
| 担当の変更 | 原則として申請 | 部署内で変更 |
表は採用・顧客管理の設計を説明するための例です。担当者が全件を扱う業務もあれば、項目ごとに閲覧範囲を変える業務もあります。職種名だけで決めず、実際の担当関係と承認の流れに合わせて調整します。確定したルールを画面とAPIへ反映し、新しい機能にも同じ境界を適用します。
確認では、担当者A、担当者B、責任者、別組織の利用者など、役割の異なるテスト用アカウントを用意します。許可する操作が成功することと、許可しない操作が拒否されることの両方が必要です。担当変更後に旧担当者のアクセスが止まるかも、時間の変化を含めて確かめます。
保存期間と共有の終了を、運用ルールに含める
個人情報漏洩対策では、アクセスを制限することに加え、業務で不要になった情報を持ち続けない仕組みも考えます。応募書類、顧客の連絡先、録音、AIの要約で、必要な保存期間が同じとは限りません。法令や契約、社内ルールを担当者と確認し、データの種類ごとに保存と削除の方針を決めます。
画面で非表示にしたデータが、添付の保存先や出力済みファイル、バックアップに残ることもあります。削除方法を決めるときは、利用者が操作できる範囲と、管理担当者が処理する範囲を分けて把握します。共有リンクについても、案件終了や担当変更を契機に利用を止められるかを確認してください。
社内システムなら、部署ごとの権限は不要ですか?
必要性は扱う情報と業務で決まります。社員だけが使うシステムでも、人事情報や特定顧客の情報を全員が見る必要があるとは限りません。社内で使うことを前提に、誰にどこまで必要かを整理します。
ログを残せば個人情報漏洩を防げますか?
ログは状況の確認に役立ちますが、権限確認の代わりにはなりません。また、本文や連絡先をログへ大量に記録すると、ログ側に保護対象が増えます。確認に必要な操作情報を選び、閲覧できる担当者と保存期間も決めることが大切です。
N2iは業務とデータの流れを一緒に確認します
N2iは、採用・人材領域の業務ツールや、顧客情報を扱うWebシステム、AIによる業務自動化を支援しています。利用者ごとの権限、データを取り出す処理、外部サービスへ送る情報を、業務の流れと合わせて整理できます。
名古屋・愛知の企業で「AIで作った顧客管理を社内に公開したい」「情シスから権限の説明を求められた」といった場合は、画面とデータの種類をもとにご相談ください。確認対象と残るリスクを明確にし、必要な作業をご案内します。
参考・関連資料
本記事はN2iが開発・公開支援の観点からまとめた解説です。記載した業務例・表は説明用で、特定の顧客案件を紹介するものではありません。公式資料は2026年10月9日に確認しました。個別の対応範囲は、システムの構成に応じて確認します。
CONSULT WITH N2i
公開前の不安を、開発会社に相談。
AIで作ったシステムや、個人情報を扱う業務Webシステムの公開に迷っている方へ。名古屋のN2iが現在の構成を伺い、必要な確認と作業を整理します。
30分の無料相談を予約コード共有前のNDA対応可。作業費は要見積。初回予約にAPIキー・パスワード・実際の顧客データを送る必要はありません。


