この記事で押さえたいこと
- 閲覧権限とCSV出力権限を分け、サーバー側で対象行・対象列まで判定する。
- AIやRAGが選んだ候補も、確定した権限条件を通してから出力する。
- 受付・生成・取得・失敗を区別して記録し、CSV本文をログに複製しない。
- API、Webhook、再実行を含む経路別の確認結果を、本番公開の判断材料にする。
1. 閲覧と一括出力を同じ権限にしない
顧客管理の担当者が連絡先を一件ずつ確認する業務と、部署全体の連絡先をCSVで取得する業務では、必要な範囲が異なります。OWASPは認証と認可を区別し、業務に必要な最小限の権限を与える考え方を示しています。本稿では、閲覧・編集とは別にCSV出力の許可を設け、利用目的と担当業務に対応づける設計を提案します。管理者という名称だけで全件出力を許すのではなく、設定管理の担当者にも個人情報の一括取得が必要かを確認し、権限を割り当てます。[1]
権限の定義には、出力できるかという可否だけでなく、所属組織、担当範囲、用途別の列セットを含めます。採用管理なら、日程調整に必要な氏名と連絡先の出力と、選考所見まで含む出力は別の用途として扱う案です。申請画面では用途を選択させ、自由記述の理由だけで範囲を広げないようにします。誰が許可を変更できるかも決め、業務担当者の希望と権限管理者の判断を分けます。これにより、便利だから全員に付けるという運用を避ける判断材料を残します。
- 閲覧・編集・CSV出力の許可を別々に定義したか。
- 出力権限の付与者と、定期的に見直す担当を決めたか。
- 用途ごとに必要な行の範囲と列セットを説明できるか。
2. 対象行と対象列をサーバー側で確定する
画面の検索条件は利用者の希望であり、それ自体を権限として扱わない設計が必要です。OWASPは、アクセス制御の確認をサーバー側などで実施するよう示しています。本稿では、組織と担当範囲による許可条件を先に作り、その内側に検索条件を適用する方式を提案します。例えば依頼に別部署の識別子が含まれていても、その指定で許可範囲を置き換えない構造です。画面からボタンを隠すだけでなく、出力処理へ直接送られた要求でも同じ判定を実行します。[1]
列の制限は、取得した全項目から不要なものを後で隠すより、用途ごとに許可した列を選ぶ設計とします。顧客一覧では連絡先を許可しても、自由記述の相談内容やAIが作成した内部評価は別に判断します。また、画面上の一ページと検索結果全体のどちらを出力するかを明示し、実行前に対象期間、列名、想定件数を表示する案です。件数が想定と違う場合は条件の見直しに戻せるようにし、確認後にデータが増えたときの扱いも、生成時点の条件として定義しておきます。
- 組織・担当条件を、利用者が送る検索条件で上書きできないか。
- 出力列は用途別の許可リストで管理されているか。
- 全件・選択行・検索結果の違いを実行前に確認できるか。
3. AIとRAGは出力対象の提案までにとどめる
AIに「今月の連絡対象を一覧にして」と依頼する機能では、自然言語から抽出した条件を、そのままCSV生成の命令にしない方式を提案します。AIは期間や対象区分の候補を返し、アプリ側で定義済みの条件に変換し、利用者が確定してから出力へ進めます。例えば「関連する顧客も含める」という曖昧な依頼は、自動で範囲を拡大せず、関連先を含める業務上の条件を選び直してもらいます。AIの説明がもっともらしいことと、対象データを取得してよいことは別の判断として扱います。
RAGで見つかった文書やレコードの識別子も、CSV対象として承認された一覧とはみなしません。本稿では、検索結果の候補を出力用の取得処理に渡し、そこで利用者の許可範囲と照合する設計を提案します。複数部署の資料を検索する業務なら、候補に含まれた別部署の情報がCSVに混入しない例を試験します。確認画面では、除外した情報の氏名や本文まで表示せず、対象外があることを必要な範囲で伝えます。AIが作る要約を出力する場合も、元の情報とは別に出力対象列として管理します。
- AIの提案と、利用者が確定した検索条件を区別しているか。
- RAGの検索候補にも、CSV生成時の対象範囲を適用するか。
4. API・Webhook・再実行で権限を迂回させない
CSVをAPIから要求できる場合、画面用の制限だけでは経路全体を確認できません。サーバー側での認可というOWASPの考え方を踏まえ、本稿では画面とAPIで共通の出力判定を利用する設計を提案します。外部連携用の資格情報には、誰の業務を代行するのか、どの組織を対象にできるのかを対応づけます。連携処理であることを理由に全組織の出力を許可せず、権限が足りない要求は拒否します。判定中の例外でも出力が継続しないことを、異常系の試験に含めます。[1]
時間のかかる生成を非同期処理にする場合は、受付時の許可だけで最後まで進めない案です。生成開始時とファイル取得時にも権限を確かめ、待機中に許可が外れた依頼をどう止めるか決めます。再実行は元の対象条件と関連づけつつ、現在の権限で判定し、以前の成功を許可の代わりにしません。Webhookは完了通知にとどめて個人情報や取得用の秘密を含めず、受信側が認可された取得経路を使う構成を提案します。重複通知による再生成も、同じ依頼かを識別して制御します。
- 画面とAPIで出力範囲の判定が一致するか。
- 待機中の権限変更と、再実行時の扱いを決めたか。
- Webhookの重複受信が意図しない追加出力につながらないか。
5. 操作履歴は取得段階を分けて残す
OWASPのログ資料は、データのインポート・エクスポートを記録対象として挙げ、アプリが利用者、操作対象、結果などの文脈を持つことを説明しています。本稿では、依頼受付、生成開始、生成完了、取得要求、配信処理の結果、拒否を別のイベントとして記録する案です。共通の依頼識別子で結び、実行主体、組織、条件の要約、列セット、実際の生成件数、時刻を残します。生成成功と利用者への配信は同じ出来事ではないため、成功という一種類の記録にまとめない設計とします。[2]
操作履歴にCSV本文や全員分の連絡先を残すと、ログ側にも個人情報の複製ができます。OWASPは過剰な記録への注意、ログ閲覧権限の制限、改変検知などを示しています。本稿では条件の記録にも自由入力をそのまま保存せず、必要な識別子や区分に絞る案です。保守担当が確認できる履歴の範囲と保存期間を決め、履歴へのアクセスも管理します。なお、配信処理が完了した記録だけで、受信端末での保存や、その後の二次利用まで確認できたとは判断しません。[1][2]
- 受付・生成・取得・拒否を依頼識別子で追えるか。
- 個人情報本文や取得用の秘密がログに混入しないか。
- ログの閲覧権限、保存期間、改変を検知する方法を決めたか。
6. 公開前の確認表で許可と拒否を検証する
公開判断では、正しい利用者が取得できる例だけでなく、取得してはいけない例を並べて確認します。OWASPは認可ロジックの単体・結合テストを推奨していますが、それですべての問題を検出できるとはしていません。本稿では以下を確認項目のひな形として提案します。期待結果は仕様案であり、試験済みという意味ではありません。各項目に実施日、対象版、確認担当、証跡をひもづけ、結果を未実施・合格・不合格に分けます。未実施を空欄のまま合格扱いにせず、公開判断へ明示します。[1]
- 変更した権限条件に対応する拒否例も試験へ追加したか。
- 未確認の経路を残す場合、公開範囲を制限する判断を記録したか。
| 確認する経路・条件 | 期待結果 | 実施状況・証跡 |
|---|---|---|
| 閲覧のみの利用者が出力APIを直接呼ぶ | 生成を拒否し、拒否理由の区分を記録する | 未実施。要求と応答、関連ログを確認する |
| 別組織の識別子を検索条件へ追加する | 別組織の行を出力しない | 未実施。組織別の検証データで照合する |
| 許可されていない列を要求へ追加する | 対象列を出力せず、定義した扱いで応答する | 未実施。CSVの見出しと内容を確認する |
| 非同期処理の待機中に出力許可を外す | 生成開始時の再判定で停止する | 未実施。処理状態と拒否履歴を確認する |
| 別の利用者が生成済みファイルを要求する | 取得時の判定で拒否する | 未実施。取得要求と配信結果を確認する |
| 同じWebhookが重複し、再実行も要求される | 依頼を識別し、定義した回数と条件で処理する | 未実施。生成物と依頼履歴を照合する |
7. 本番保守では生成物の期限と変更時の扱いを決める
出力後のファイルをいつまで取得可能にするかは、生成処理と同時に設計します。本稿では、業務に必要な取得期間を決め、期限切れのファイルを取得対象から外し、一時保存領域も整理する案です。例えば定例の連絡業務なら、古い一覧を再配布するより、新しい条件で生成し直す運用が適するかを検討します。保存先の移行や失敗時の一時ファイルも対象に含め、正常終了した生成物だけを削除対象にしないようにします。取得済みの端末上の複製は、サーバー側の期限管理とは分けて扱います。
保守で列を追加するときは、画面に表示する項目だからCSVにも追加する、という変更を避けます。新しいAI要約列、組織区分の変更、外部連携先の追加は、出力範囲と記録内容を見直す契機とする案です。また、ログ保存の失敗時に出力を続けるか止めるかを事前に決め、停止する場合の利用者向け案内と復旧後の再依頼手順を用意します。運用開始後も、問い合わせから分かった条件の曖昧さを仕様へ反映し、権限設定と試験項目が別々に更新されないよう変更単位で管理します。
- 生成物、一時ファイル、取得可能期間の管理対象を整理したか。
- 列追加や連携変更時に、仕様と試験を一緒に更新するか。
よくある質問
承認担当が不在でも、急ぎのCSV出力を許可できますか。
本稿では、事前に定めた代理承認者がいる場合だけ、その担当へ回す運用を提案します。代理者がいなければ、緊急という理由だけで権限を広げず、必要な対象を絞った別の業務手順で対応できるか検討します。開発・保守担当者が独断で業務上の承認を代行する運用にはしません。
権限別の確認環境がない場合はどう判断しますか。
未確認のまま利用範囲を広げず、個人情報を含まない検証データと役割別アカウントを準備する案です。本番で実データを広く取得して確かめる方法は避けます。準備までに公開が必要なら、CSV機能を無効にするなど、確認できた機能だけを公開する判断を残します。
一時休職する利用者の出力権限は残してよいですか。
在籍していることだけで判断せず、休職中に出力業務を行う必要があるかを確認します。本稿では、必要がなければ出力許可の一時解除を検討し、復職時も担当業務を確かめて戻す案です。これはCSV権限の扱いであり、アカウント全体の停止範囲は別の運用として判断します。
月末だけ全体集計のために範囲を広げたい場合はどうしますか。
期限付きの例外として、目的、対象期間、対象列、承認者、終了条件を記録する案です。集計値だけで足りるなら、個人別CSVを出さない方法を先に検討します。例外を設ける場合も無期限の権限変更にはせず、期限後に通常の範囲へ戻ったことを確認する担当を決めます。
参考・関連資料
公式資料の確認日:2026-10-16。業務例は説明用で、顧客の実績ではありません。編集:株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。
CONSULT WITH N2i
公開前の不安を、開発会社に相談。
AIで作ったシステムや、個人情報を扱う業務Webシステムの公開に迷っている方へ。名古屋のN2iが現在の構成を伺い、必要な確認と作業を整理します。
30分の無料相談を予約コード共有前のNDA対応可。作業費は要見積。初回予約にAPIキー・パスワード・実際の顧客データを送る必要はありません。
