社内で生成AIを使い始めると、情シスに最初に来る相談は「どのAIを許可するか」です。しかし、運用が始まった後に問題になるのは「なぜその利用を許可したのか」「誰が何を入力したのか」「AIの出力を人が確認したのか」を後から説明できるかです。
AI利用の監査証跡は、AIツールの全ログを丸ごと保存することではありません。必要なのは、申請、承認、入力、出力、人による確認、最終利用を同じ業務記録として追える状態にすることです。特に、顧客対応、契約、請求、人事、障害対応、法務確認にAI出力を使う場合は、AIが出した文面そのものよりも「最終判断を人が行った」と説明できる記録が重要になります。
経済産業省は、AI事業者ガイドライン検討会で「AI事業者ガイドライン（第1.2版）」を取りまとめ、最新版として本編・別添・チェックリスト等を公表しています。社内AI利用の証跡設計では、このようなガイドラインを参照しつつ、自社の業務リスク、個人情報の取扱い、契約条件に合わせて記録の粒度を決める必要があります。
https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html
まず決めるべきは「全件保存」ではなくリスク別の証跡レベル
AI利用のログをすべて詳細に残す運用は、一見すると安全に見えます。しかし、プロンプトや添付ファイル名には、顧客名、メールアドレス、問い合わせ内容、社内未公開情報、契約条件、人事情報が含まれることがあります。保存しすぎると、ログ保管先そのものが新しい情報漏えいリスクになります。
個人情報保護委員会のガイドラインでも、安全管理措置は個人データの内容、事業の規模・性質、取扱状況等に起因するリスクに応じて必要かつ適切な内容とすべきであり、例示された内容のすべてを必ず講じなければならないわけではないと示されています。AIログも同じく、業務リスクに応じて「残す情報」と「残さない情報」を分けるべきです。
https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
| リスク区分 | 該当しやすい利用例 | 最低限残す証跡 | プロンプト・出力全文の扱い |
|---|---|---|---|
| 低リスク | 公開情報だけを使った文章校正、社内向け一般文書の言い換え、アイデア出し | 利用者、日時、ツール名、利用目的、申請IDまたは部署ルール | 原則として全文保存しない。必要なら要約メモで足りる |
| 中リスク | 社内資料の要約、FAQ案の作成、ナレッジ検索、問い合わせ下書き | 申請記録、承認範囲、入力データ区分、出力の利用先、レビュー担当者 | 全文保存は業務ごとに判断。個人情報や機密情報はマスキングする |
| 高リスク | 顧客回答、契約・請求・人事・障害対応、社外提出資料、法務判断に影響する利用 | 申請、承認、入力、出力、添付有無、レビュー結果、修正差分、最終成果物、承認者 | 保存する場合はアクセス制限、保存期間、削除手順、閲覧ログをセットで決める |
監査で説明しやすい証跡は「6点セット」で考える
私は承認をメールではなく、AgileWorksのワークフローで回しています。ワークフローにすると、「誰が・いつ・どの条件で承認したか」がそのまま履歴として残ります。監査や問い合わせで「なぜこの利用を許可したのか」を聞かれたときも、承認履歴を出すだけで説明できます。メール承認だと後から探しにくくなりますが、ワークフローなら証跡が自動でそろいます。
AI監査で見られるのは、AIが何を答えたかだけではありません。実務では「そのAI利用が承認範囲内だったか」「入力してはいけない情報を入れていないか」「AI出力を人が確認したか」「最終成果物にどう反映したか」が問われます。したがって、証跡は次の6点セットで設計します。
| 証跡 | 残す内容 | 監査・調査で答えられること |
|---|---|---|
| 1. 申請記録 | 部署、利用者、対象業務、利用目的、使うAIツール、入力予定データ、禁止データ、利用期限 | そもそも許可された利用だったか |
| 2. 承認記録 | 承認者、承認日時、承認条件、例外の有無、レビュー担当者 | 誰がどの範囲で利用を認めたか |
| 3. 利用記録 | 利用日時、ユーザーID、ツール名、機能名、添付ファイル有無、入力データ区分 | 実際の利用が承認範囲に収まっていたか |
| 4. 出力記録 | AI出力の要約または全文、出力ID、再生成の有無、参照した資料 | どの出力を業務判断に使ったか |
| 5. 確認記録 | レビュー担当者、確認日時、修正内容、差し戻し理由、最終判断 | 人による確認が行われたか |
| 6. 最終利用記録 | 送信文、公開資料、チケットID、ファイルURL、顧客回答履歴 | AI出力が最終成果物にどう反映されたか |
共通IDを付けるだけで、証跡はかなり追いやすくなる
証跡管理で失敗しやすいのは、申請書はフォーム、承認はメール、利用ログはAI管理画面、成果物は共有フォルダ、問い合わせはチケット管理というように、記録が別々に散らばることです。これを防ぐには、最初から共通IDを発行します。
AI利用申請ID：AI-REQ-2026-001
業務チケットID：CS-45821
承認記録ID：APP-2026-001
AI出力記録ID：AI-OUT-2026-001
成果物ファイル名：AI-REQ-2026-001_customer-reply-draft.docx
Microsoft 365環境では、Microsoft ListsやSharePointのリストを申請台帳として使い、リストまたはドキュメントライブラリ上で承認依頼・承認履歴を管理する方法があります。Microsoft公式ドキュメントでは、Listsやドキュメントライブラリで承認依頼を作成し、Approvals app in Teamsから応答できることが説明されています。ただし、実際に自社テナントで使える機能、監査ログの保持期間、ライセンス条件は契約内容に依存します。
https://support.microsoft.com/en-us/office/approvals-in-lists-document-libraries-2bd0954d-5797-4be3-b78a-846f26338e17
https://support.microsoft.com/en-us/office/introduction-to-lists-0a1c3ace-def0-44af-b225-cfa8d92c52d7
ChatGPT Business、ChatGPT Enterprise、ChatGPT Eduなどの業務向けサービスでは、事業者側のデータ取り扱い方針や管理機能を確認する必要があります。OpenAIは、業務向けデータについて、対象サービスの入力・出力を含むbusiness dataに関する説明を公開しており、ChatGPT Enterprise等ではデータ保持期間を制御できる旨を示しています。ただし、どの保持期間を選べるか、自社契約でどの機能が有効かは公開情報だけでは確定できません。
https://openai.com/enterprise-privacy/
https://openai.com/business-data/
申請台帳に入れる項目：このままコピーして使える最小セット
申請台帳は、細かすぎると現場が入力しなくなります。最初は、監査で聞かれやすい項目に絞るのが現実的です。
【AI利用申請台帳の項目】
申請ID：
申請日：
申請部署：
利用者：
業務オーナー：
利用目的：
対象業務：
利用するAIツール・プラン：正式サービス名、契約プラン名、利用環境を記録する。
入力してよいデータ：
入力禁止データ：
添付ファイル可否：
社外利用可否：
レビュー担当者：
保存先URL：
保存期間：社内規程、契約条件、監査要件に合わせて、申請内容と承認記録を保存する期間を記録する。
承認者：
承認日：
利用期限：
備考：
利用するAIツールや保存期間が未確定の場合は、仮承認として扱い、正式な契約プラン名と保存期間が確認できてから本番利用を開始します。
現場手順は「入力前」「出力後」「保存時」で分ける
AI利用ルールを作っても、現場が迷うのは「その場で何を確認すればよいか」です。問い合わせ対応を例にすると、次の流れにすると証跡が残りやすくなります。
- チケットIDを発行し、AI利用申請IDと紐付ける。
- 入力前に、個人情報・契約情報・未公開情報が含まれていないか確認する。
- 入力してよい範囲を超える場合は、マスキングまたは利用停止を選ぶ。
- AIの出力をそのまま送らず、担当者が事実確認・表現確認・禁止表現確認を行う。
- 修正した箇所と、採用しなかったAI出力を簡単に記録する。
- 社外送信前に、承認が必要な業務か確認する。
- 最終送信文、確認者、送信日時、証跡フォルダURLを台帳に残す。
インシデントが疑われるときは、削除より一次保全を優先する
AIに入力してはいけない情報を入れた可能性がある、誤った回答を顧客へ送った、権限外の人がAIログを見た可能性がある。このような場合、現場判断でチャット履歴やスクリーンショットを削除すると、後から事実確認が難しくなります。通常運用とは別に、一次保全の手順を用意しておきます。
【AI利用インシデント一次保全メモ】
発生日・発見日：
発見者：
関係部署：
AIツール名・プラン：正式サービス名、契約プラン名、利用環境を記録する。
ユーザーID：
利用日時：
申請ID・チケットID：
入力した可能性のある情報：
AI出力の概要：
添付ファイルの有無：
社外送信・共有の有無：
保全した証跡：プロンプト、出力、添付ファイル名、画面、送信文、承認記録
保全先：アクセス制限、更新履歴、削除制限を設定できる保管場所に保存する。
初動判断者：
次アクション：
一次保全後は、関係者以外の閲覧を制限し、証跡の削除や上書きを行わず、情シス・法務・業務部門で影響範囲を確認します。
保存期間は「監査に必要」と「持ちすぎリスク」の両方で決める
AI監査証跡の保存期間は、公開情報だけで一律に決められるものではありません。社内規程、取引先契約、個人情報の取扱い、会計・契約関連文書の保存ルール、利用するAIサービスの契約条件によって変わります。したがって、記事やテンプレートで「必ず何年保存」と断定せず、自社で確認すべき項目を明示します。
| 証跡 | 保存期間を決めるときの確認先 | 注意点 |
|---|---|---|
| 利用サマリ | 社内AI利用規程、内部監査方針 | 低リスク利用は全文ログではなくサマリ保存でもよい場合がある |
| プロンプト・出力全文 | 情報セキュリティ規程、個人情報取扱規程、契約条件 | 保存するほど検索・閲覧・漏えいリスクが増える |
| 顧客回答・契約・請求に関わる記録 | 社内文書管理規程、取引先契約、関連法令 | AIログ単体ではなく、最終成果物と一緒に管理する |
| AIサービス側のログ | 管理画面、契約書、DPA、公式ドキュメント | 公開情報だけでは自社の実保持期間を確定できないことがある |
月次点検で見るべきチェックリスト
小規模な情シスでは、最初からSIEM連携や専用監査基盤を作るより、月1回の台帳点検を確実に回すほうが効果的です。以下を確認すれば、承認されていないAI利用や、保存先不明の証跡を早めに見つけられます。
- 利用期限が切れた申請が残っていないか
- 承認者が空欄のまま利用されていないか
- 入力禁止データを扱う可能性がある業務が低リスク扱いになっていないか
- 証跡フォルダURLが台帳に記録されているか
- 退職者・異動者がAIツールや証跡フォルダにアクセスできない状態になっているか
- 保存期間を過ぎた証跡を削除またはアーカイブしているか
- 高リスク利用で、人によるレビュー記録が残っているか
まとめ：AI監査証跡は、AI活用を止めるためではなく守るために残す
AI監査証跡の目的は、現場を縛ることではありません。むしろ、正しく使っていたことを後から説明できるようにし、AI活用を継続するための土台を作ることです。
最初から完璧なログ基盤を作る必要はありません。まずは、リスク区分を決め、申請IDを発行し、申請・承認・利用・確認・最終成果物を同じIDでつなげるところから始めます。そのうえで、個人情報や機密情報を含む可能性がある高リスク業務だけ、プロンプト・出力・レビュー記録を詳しく残します。
AI利用の監査対応で一番困るのは、ログがないことではなく、ログはあるのに業務判断とつながらないことです。情シスは「全ログ保存」ではなく、「説明できる最小限の証跡」を設計しましょう。
コメント