社内AI利用ログの必須項目と保存期間｜監査証跡の残し方を情シス実務で整理

社内で生成AIを使い始めると、情シスに最初に来る相談は「どのAIを許可するか」です。ただ、運用が始まってから問題になるのはそこではなく、「なぜその利用を許可したのか」「誰が何を入力したのか」「AIの出力を人が確認したのか」を後から説明できるかどうかです。

社内AI利用の監査証跡は、AIツールの全ログを丸ごと保存することではありません。申請、承認、利用、出力、人による確認、最終利用を、同じ業務記録として追える状態にしておくことが中身になります。

顧客対応、契約、請求、人事、障害対応、法務確認などにAI出力を使う場合はなおさらで、AIが出した文面だけでなく、「その利用は許可されていたか」「何を根拠に使ったか」「最後は誰が判断したか」まで説明できる形にしておきます。

経済産業省は「AI事業者ガイドライン（第1.2版）」を公表しています。社内AI利用の証跡設計でも、こうしたガイドラインを参照しながら、自社の業務リスク、個人情報の取扱い、契約条件に合わせて記録の粒度を決めていきます。

AIログは「全部残す」より「後から説明できる」ことを優先する

AI利用ログを設計すると、「何かあったときのために全部残しておこう」と考えがちです。ただ、プロンプトや出力、添付ファイル名には、顧客名、メールアドレス、問い合わせ内容、契約情報、人事情報、社内未公開情報などが含まれる可能性があります。

保存すれば安心、とはいきません。保存したログ自体が、今度は守るべき情報になります。

そこで、まずログを目的別に分けます。

さらに、業務のリスクによって保存する粒度を変えます。

個人情報保護委員会のガイドラインでも、安全管理措置は取り扱う個人データや事業の性質、リスクに応じて必要かつ適切な内容とする考え方が示されています。AIログも同じで、「とりあえず全部」より、目的とリスクに応じて残す情報を決めたほうが運用は続きます。

監査で説明しやすい証跡は「6点セット」で考える

AI監査で確認したいのは、AIが何を答えたかだけではありません。

実務で聞かれるのは、「そのAI利用が承認範囲内だったか」「入力してはいけない情報を入れていないか」「AI出力を人が確認したか」「最終成果物にどう反映したか」あたりです。

証跡は次の6点セットで考えると整理しやすくなります。

AI利用ログで最低限残したい項目

6点セットを業務上の証跡として置いたうえで、システム側のAI利用ログには、後から「誰が、いつ、どのAI機能を、どの権限で、どの目的に使い、どのような結果になったか」を追える項目を残します。

ただし、入力文・出力文を常に全文保存するわけではありません。

共通IDを付けると、申請・ログ・成果物が一気に追いやすくなる

たとえば次のように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

すべてを同じシステムに保存しなくても構いません。申請はワークフロー、利用ログはAI管理画面、成果物はSharePointという構成でも、共通IDで検索できれば1件の業務として追えます。

ChatGPTの監査ログは「ベンダー側」と「自社側」を分けて考える

ChatGPTを社内利用する場合、OpenAI側で取得できるログだけで監査証跡が完成するわけではありません。

見落としやすいのは保持期間です。ベンダー側のログはいつでも遡れるものではなく、多くが30日で消えます。監査対応を前提にするなら、自社側へ取り込む仕組みまで含めて設計しないと足りません。

プラン・機能ごとの保持期間

「30日」を前提に運用を組む

ここが実務上の分かれ目です。Compliance Logs Platform の保持期間は30日なので、四半期に一度まとめて取得する運用にすると確実に取りこぼします。

社内規程で「AI利用ログは1年保存」と決めたなら、それを満たすのはベンダー側ではなく自社側の仕組みです。決めるのは次の3点になります。

• 取り込みの間隔（日次か週次か。30日に対して余裕を持たせる）
• 取り込んだログの置き場所と、そこでの保存期間
• 取り込みが失敗したときに気づく方法

3つ目が抜けやすい部分です。ログ取得のバッチは、止まっても業務に影響が出ないため、誰も気づかないまま数か月経つことがあります。監査で提示を求められた時点で欠落が判明する、というのが最悪のパターンです。

仕様変更に追随する前提を持つ

OpenAI側の仕様は動きます。実際、2026年3月5日に新しい会話ログの仕組みが公開され、従来のstatefulルートは非推奨となりました。そのルートは同年6月5日に削除されています。

連携ツールやスクリプトでログを取り込んでいる場合、こうした変更で取得が止まります。年に一度は公式ドキュメントを読み直す、あるいは前項の「失敗に気づく方法」を用意しておく、のどちらかは要ります。

アクセス権の設計

Compliance Platform を使うには、ワークスペースにスコープされたAdminキーが必要です。ログの種別ごとに権限を分けられますが、会話メッセージだけは扱いが違います。

本文の「ログの閲覧権限は一次対応と特権調査を分ける」という考え方と、この仕様は相性がいいです。一次対応の担当者には監査ログ・認証ログまで、会話の中身は特権調査時のみ、という切り分けが製品側の権限モデルでそのまま表現できます。

ベンダー側と自社側の分担

ベンダー側のログには、自社の業務ID、申請理由、承認条件、最終成果物までは自動で入りません。ここが分担の線引きになります。

なお、API Platform の監査ログが記録するのは、ユーザー・プロジェクト・APIキー・サービスアカウント・組織設定といった管理操作の履歴です。APIのリクエストとレスポンスの中身は含まれません。ChatGPTワークスペースの会話ログとは別物なので、混同しないよう注意してください。

プロンプトと出力を全文保存するかは3段階で判断する

AI利用ログで判断が難しいのが、プロンプトと出力を全文保存するかどうかです。

私は次の3点で整理しています。

1. 後から業務を再現する必要があるか。
   顧客回答、審査、契約、帳票作成、社外提出など、説明責任が大きい業務では入力・出力の保存を検討します。
2. 個人情報や機密情報が含まれる可能性があるか。
   高感度情報が含まれる場合は、全文保存よりマスク、要約、参照ID保存を優先します。
3. 全文ログの閲覧者を限定できるか。
   全文保存しても、多数の利用者が閲覧できるのであれば新たなリスクになります。閲覧者・エクスポート権限・閲覧履歴まで先に決めます。

社内ルール例：
AI利用ログの入力本文および出力本文は、業務上の再現、監査、法令・契約対応に必要な場合に限り保存する。個人情報、顧客秘密、営業秘密等を含む可能性がある場合は、マスク処理、要約保存、参照ID保存を優先する。全文ログの閲覧は承認された担当者に限定し、閲覧・検索・エクスポート履歴を記録する。

個人情報を含む問い合わせなどをAIで扱う場合も、原文をそのまま保存するのではなく、個人を識別できる情報をマスクした入力要約を残す方法があります。

出典：

生成AIサービスの利用に関する注意喚起等について ｜個人情報保護委員会

個人情報保護委員会のホームページです。生成AIサービスの利用に関する注意喚起等について掲載しています。

www.ppc.go.jp

保存期間は「AIログだから何年」ではなく用途から決める

AI利用ログに全国共通の一律保存年限があるわけではありません。保存期間は、対象業務の性質から整理します。

たとえば会計・税務に関係する成果物をAIで作成・確認した場合でも、「AIを使ったから7年保存」ではありません。その成果物や関連記録が、もともとの法令上どの文書に当たるのかで判断します。

出典：
https://www.nta.go.jp/taxes/shiraberu/taxanswer/hojin/5930.htm
https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/

個人情報の保護に関する法律についてのガイドライン（第三者提供時の確認・記録義務編） ｜個人情報保護委員会

個人情報委員会（PPC)のホームページです。個人情報の保護に関する法律についてのガイドラインの第三者提供時の確認・記録義務編を掲載しています。

www.ppc.go.jp

ログの閲覧権限は「一次対応」と「特権調査」を分ける

AI利用ログは監査証跡である一方、顧客情報や社内機密を含む可能性があります。

「情シスなら誰でも全文ログを見られる」という設計にはしないほうが安全です。

ログの閲覧やエクスポート自体も記録しておきます。監査ログを調査のために出力したものの、共有フォルダに置きっぱなしになる、といった状態も避けます。

申請台帳は「後からつながる項目」に絞る

申請台帳を細かくしすぎると、今度は現場が入力しなくなります。

最初は、監査や問い合わせで聞かれやすい項目と、他のログにつなぐためのIDに絞るのが現実的です。

【AI利用申請台帳】
申請ID：
申請日：
申請部署：
利用者：
業務オーナー：
利用目的：
対象業務：
AIツール・契約プラン：
入力してよいデータ：
入力禁止データ：
添付ファイル可否：
社外利用可否：
レビュー担当者：
ログ保存先：
保存期間：
承認者：
承認日：
利用期限：
備考：

AIツールの契約プランや保存期間が未確認の場合は、PoC・仮承認の段階と本番利用を分け、本番移行前に確認済みにする運用も考えられます。

現場手順は「入力前・出力後・保存時」で分ける

AI利用ルールを作っても、現場では「今この画面で何を確認するのか」が分からないと運用されません。

問い合わせ対応を例にすると、次の流れにすると証跡を残しやすくなります。

1. チケットIDを発行し、AI利用申請IDと紐付ける。
2. 入力前に個人情報、契約情報、未公開情報が含まれていないか確認する。
3. 入力可能範囲を超える場合は、マスキングするかAI利用をやめる。
4. AI出力をそのまま使わず、担当者が事実・表現・禁止事項を確認する。
5. 業務判断に利用した出力と、必要に応じて修正内容を記録する。
6. 社外送信前に追加承認が必要な業務か確認する。
7. 最終成果物、確認者、日時、証跡保存先を台帳に残す。

インシデント時は、慌ててログを消さず一次保全する

入力してはいけない情報をAIへ入力した可能性がある、誤った回答を顧客へ送った、権限外の利用者がログを閲覧した可能性がある。このような場合は、通常の削除ルールとは別に一次保全を行います。

現場判断でチャット履歴やスクリーンショットを削除すると、後から事実確認ができなくなる場合があります。

【AI利用インシデント一次保全メモ】
発生日・発見日：
発見者：
関係部署：
AIツール・プラン：
ユーザーID：
利用日時：
申請ID・チケットID：
入力した可能性のある情報：
AI出力の概要：
添付ファイル有無：
社外送信・共有有無：
保全した証跡：
保全先：
初動判断者：
次アクション：

一次保全後は閲覧範囲を限定し、証跡の上書き・削除を避けたうえで、情シス、業務部門、必要に応じて法務・セキュリティ担当で影響範囲を確認します。

PoCでは「AIが便利か」だけでなく「1件を最後まで追えるか」を確認する

PoCでAIの回答精度だけを確認して、本番移行の直前にログ設計を考えると、後から不足項目が見つかりやすくなります。

PoC開始前には、少なくとも次を決めます。

• 対象業務と利用者
• 入力禁止情報
• プロンプト・出力全文を保存する条件
• AI出力を業務判断に使う条件
• ログ保存先
• ログ閲覧者と承認者
• PoC中の暫定保存期間と、本番時の保存期間を決める方法
• 退職者・異動者のアクセス削除方法
• インシデント時の連絡先

PoC中は、実際の1件を選び、申請から承認、AI利用、ログ、レビュー、最終成果物まで追跡します。

運用開始後は月1回でも台帳を点検する

小規模な情シスでは、最初から大規模なSIEM連携や専用監査基盤を作るより、月1回でも申請台帳と権限を確実に確認するほうが現実的な場合があります。

• 利用期限が切れた申請が残っていないか
• 承認者が空欄のまま利用されていないか
• 入力禁止データを扱う業務が低リスク扱いになっていないか
• 証跡保存先が台帳に登録されているか
• 退職者・異動者がAIツールや証跡へアクセスできない状態になっているか
• 保存期間を過ぎたログを削除・アーカイブしているか
• 高リスク利用で人によるレビュー記録が残っているか
• ログの閲覧・エクスポート権限が増えすぎていないか

まとめ：AI監査証跡は「ログを残す」ではなく「業務を説明できる」状態を作る

AI監査証跡の目的は、すべての入力と出力を長期間保存することではありません。「誰が使ったか」というAI側のログに、「なぜ使ったか」という申請、「誰が許可したか」という承認、「何に使ったか」という成果物をつなげて、後から1件の業務として説明できるようにすることです。

まずリスク区分を決め、AI利用申請IDやチケットIDを発行し、申請・承認・利用・確認・最終成果物を同じIDでたどれるようにする。そのうえで、残すログ項目、全文保存する条件、保存期間、閲覧権限、削除・保全手順を決めます。ChatGPTなど外部AIサービスを使う場合は、ベンダー側のログが30日で消えることを前提に、自社の業務記録と組み合わせます。

実務で困るのは、ログがまったくないケースだけではありません。申請も承認もログも成果物も残っているのに、それぞれがつながっておらず、後から一件の業務として説明できない状態もかなり厄介です。「全部残す」ではなく「後から必要なことを説明できる最小限の証跡」を設計する。生成AIを業務で使い続けるうえでは、これが現実的な落としどころだと考えています。