現場で「全部禁止か全部許可か」の二択で迷走していませんか。現場はChatGPTや外部のコード支援ツール（例：Claude Code）を使いたがり、セキュリティ部門は一律禁止に傾きがちです。その結果、導入停止、過剰な運用、非公式ツールの勝手運用といった監査で説明できないリスクが生じます。
冒頭まとめ（one-line thesis）
AI利用者権限は「業務フロー×データ感度×実行形態（＋必要ならユーザー属性）」で定義し、各交点に「権限レベル・必須ログ・監査トリガー」を紐づけて最小化する。これだけで現場で運用可能になり、監査負荷を減らせます。本稿は現場で使える権限テンプレ、場面別チェックリスト、PoC→本番の最小手順を提示します。
誤解を壊す：中央一律制と全開放はどちらも失敗する
中央での一律禁止は説明責任を肥大化させ、全開放は非公式運用とログ欠如を生みます。判断は必ず業務機能とデータ感度の交点で行い、現場で説明できる根拠（証跡）を残すことが必須です。
- 中央一律は監査での差し戻しを増やす
- 現場ごとに業務フローとデータ感度で分けるのが現実解
- 許可は原則ログあり。ログと監査要件をセットで決める
判断軸とテンプレ：権限・ログ・監査を定型化する
主要判断軸を明確にしておくと、承認会議や現場での即断がぶれません。本文で使う軸は次のとおりです。
- データ感度：公開／社内限定／機密／個人情報
- 業務機能：問い合わせ／画面確認／帳票確認／コード生成
- ユーザー属性：現場担当／監督者／開発者（必要時）
- 実行形態：画面操作／バッチ／社内モデル／外部API
権限テンプレ（そのまま利用可）
- A：全許可（社内モデル限定、ログ保存、定期監査）
- B：画面のみ（入力・出力のログ、担当者による確認と署名）
- C：管理者承認（利用申請と承認後に限定的許可、追加ログ）
- D：禁止（外部送信・保存不可）
必須ログ（最低限）
- 入力ログ（誰が、いつ、どのデータを入れたか。顧客IDはマスク可）
- 出力ログ（AI応答のスナップショット／差分）
- 操作履歴（編集・送信・保存の追跡）
- 保存先の記録（オンプレ/クラウド/外部サービス）
監査頻度（例）
- 高感度：月次抜き取り＋インシデント時の全件レビュー
- 中感度：四半期抜き取りレビュー
- 公開情報：年次レビュー
場面別運用案（現場で即使えるチェックリスト）
以下は問い合わせ対応・画面確認・PDF/帳票確認・コード生成の典型場面ごとの最小運用案です。各項目は「許可条件」「必須ログ」「監査トリガー」「現場ルール」を明示しています。
問い合わせ対応（顧客データを扱うチャット支援）
- 許可条件：顧客個人情報を含む場合は「画面操作のみ」＋入力ログ・出力ログ必須。外部API送信は原則禁止（社内モデルまたはプロキシ経由のみ許可）。
- 必須ログ：入力（顧客IDはマスク可）、出力スナップショット、担当者ID、回答編集履歴。
- 監査トリガー：個人情報の外部送信が疑われる場合、コンプラ違反の報告、抜き取りでの誤回答頻度超過。
- 現場ルール：AI出力をそのまま送信禁止。要約→担当者編集→送信のワークフローを必ず踏む。即断が必要なときは上長へエスカレーション。
画面確認（AIが要約を作り担当者が編集する場面）
- 許可条件：Bレベル（画面のみ）。会議やレビューで編集前後の差分を提示できること。
- 必須ログ：要約の編集前後差分ログ、担当者の承認（IDとタイムスタンプ）。
- 監査トリガー：編集差分が大きい、または編集なしで外部送信された場合。
PDF・帳票確認（機密帳票の要約/解析）
- 許可条件：機密帳票は社内モデル／オンプレ解析のみ。外部利用は管理者承認＋メタデータ除去を必須とする。
- 必須ログ：原本ID、解析対象ページ、要約結果、アクセス者ID、解析時刻。
- 監査トリガー：機密タグ付き帳票の外部送信があれば即停止・全記録提出。
コード生成（開発支援）
- 許可条件：開発者は限定的に外部モデルを利用可。ただし機密情報（APIキー・顧客データ）を含む入力は禁止。社内リポジトリへの自動コミットは禁止、レビュー必須。（Claude CodeやChatGPTのコーディング機能を利用する場合も同様）
- 必須ログ：入力プロンプト、生成コードのスナップショット、生成物の静的解析結果、レビュー記録。
- 監査トリガー：生成物にライセンス違反や機密要素が含まれる疑いがある場合は即エスカレーション。
PoCでのよくある失敗と防止策
PoC段階でログ定義と承認ルートを設計しておかないと、本番化で必ず手戻りが発生します。機能評価だけで証跡を残さないと、承認時に「誰が何をしたか」を説明できません。
- PoCで必ず決めること：ログ項目、保存場所、保有期間、アクセス権
- 承認フロー設計：利用申請→権限付与→監査対象化を明文化し、承認者を議事録に残す
- 監査トリガーを明確化：インシデント時の追加ログ収集権限、説明資料テンプレの用意
チェックリスト（PoC前に必須）：ログ定義書、簡易監査資料テンプレ、承認者リストと再評価期限（付与後90日でレビューなど）。
最小手順で本番化する順番（テンプレ）
- ステップ0：候補業務の選定（3つ以内）とリスクラベリング（データ感度を明記）
- ステップ1：PoC実施（機能評価＋ログ取得）→成果物：ログ定義書、操作チェックリスト、簡易監査資料
- ステップ2：承認（利用申請フォーム提出。目的・データ感度・想定ユーザー・実行形態を記載）→権限付与ルールの確定
- ステップ3：本番化→付与後90日で初回レビュー、半年ごとに監査レポート自動生成
承認申請フォームの最低項目
- 利用目的と想定業務フロー
- 扱うデータの感度と具体例（顧客ID／氏名等）
- 想定ユーザー属性（現場担当/監督者/開発者）
- 実行形態（画面/外部API/社内モデル）
- ログ保存方針（保存先、期間、アクセス権）
- 再評価期限と監査頻度
短いFAQ（現場でよく聞かれる質問）
- 現場担当がツールをローカルで動かせば監査は不要か？：ローカル運用でも入力/出力/操作の記録を定義しない限り監査は不要になりません。証跡の有無を問われます。
- 外部サービスを使う場合に残すべきログは？：入力（プロンプト）、出力（応答スナップショット）、送信先情報、担当者IDとタイムスタンプが最低限です。送信前のマスク処理もログに残すこと。
- PoCでログを取ると本番移行が遅くなるがどこまで省けるか？：最小限は入力/出力/担当者のタイムスタンプ。この3つがあれば多くの監査要件を満たしますが、省きすぎると手戻りが発生します。
まとめ（導入判断と最初の一歩）
- 結論：権限は「業務フロー×データ感度×実行形態」で定義し、ログ／監査要件と紐づける。中央一律の禁止／全開放は避ける。
- 優先事項：最重要業務フローを3つに絞る（まずは顧客問い合わせ、次に帳票確認、最後にコード生成）
最初の一歩（即実行）：1) 候補業務の選定とデータ感度ラベル付け、2) PoCでの機能評価と同時にログ定義書作成、3) 承認申請フォーム提出→権限付与、4) 本番化→90日後レビュー。業務フロー×データ感度×実行形態を判断軸にし、各交点に権限・必須ログ・監査頻度をテンプレ化して会議で回してください。
コメント