生成AIの操作ログを設計する方法──何を残し、誰が見て、いつ消すか

生成AIを社内へ入れて数か月、「先月あの部署が何を入力したか分かるか」と聞かれて答えられない。逆に、心配だからと入力と出力をすべて保存し、そのlog自体が社内で最も機微な情報の集積になっている。どちらも起こり得る形です。本稿は生成AIの操作logを「何を残し、誰が見て、いつ消すか」という設計の問題として扱い、目的の定義から保護・保持・廃棄までを一枚の表へつなげる手順を整理します。

対象は、情報securityの担当者、AI運用の担当者、内部監査、system owner、事故の窓口となる方です。対象のuse case、利用者、許可された操作、守る情報の概略が決まっていることを前提とします（use case の把握そのものは生成AIの利用台帳を作る方法──目的・責任者・データ・見直し条件を管理するで扱っています）。SIEM製品の比較、特定serviceのlog仕様、法定の保存期間、全promptの恒久保存、監視による従業員評価は扱いません。社内ルールの本文は小さな会社のAI利用ルールの作り方が引き受けます。本稿は記録の設計だけを扱います。

• 1 目的：このlogで後から答えたい問いを先に書く。security、操作の追跡、承認の確認、品質、事故対応、運用改善のどれに使うのかを分ける
• 2 event選択：目的ごとに、記録するevent種別と記録しないevent種別を決め、そう選んだ理由を併記する
• 3 record生成：各eventについて、いつ・誰が・どのserviceで・何を・何に対して行い、結果はどうだったかを、どのfieldで表すかを決める
• 4 保護／access：logを読める人と権限、改変からの保護、時刻の合わせ方、記録が欠けたときの気づき方を決める
• 5 利用：誰がどう検索し、どう取り出し、事故のとき何を証拠として渡すかを決める
• 6 保持／廃棄：どれだけ保持し、どこへ移し、いつ消すか。契約や社内規程の確認先も併せて決める

矢印は工程の順序を表します。この6段は本記事の編集上の整理であり、公的機関が定めたlifecycleの定義ではありません。NIST『Guide to Computer Security Log Management』（SP 800-92、2006年9月）がlog managementに与える定義は「生成し、転送し、保存し、分析し、廃棄する」であり、本記事の6段とは切り分けが異なります。以降の各節が、この6段に対応します。ただし本文では、保持と廃棄（節7）を、取り出しと証拠への引継ぎ（節8）より先に置いています。

1. 「全部保存する」と「何も残さない」の二択を避ける

logの話は、両端のどちらかから始まることがあります。追えないと困るから全部残そう、という側と、機微な情報が混じるのだから残さないほうが安全だ、という側。どちらも一理あり、そしてどちらも設計ではありません。

SP 800-92は、量を増やすことを安全側として扱っていません。「Recording more data is not necessarily better」（より多くのデータを記録することが必ずしも良いわけではない）として、同書は一般論として、最も重要なdataの記録と分析のみを必須とし、それ以外は時間と資源が許せば行う非必須の推奨として持つべきだ、と述べています。理由も明示されています。「過剰な記録は、log dataの喪失に加え、systemの速度低下、さらにはサービス停止といった運用上の問題を引き起こし得る」という記述です。増やした結果、残したかったものまで失われ得るという向きの記述です。

SP 800-53のAU-2（Event Logging）のdiscussionも同じ方向を向いています。監視・監査の要件をsystemの他の必要と釣り合わせるため、event loggingには「identifying the subset of event types that are logged at a given point in time」（ある時点で記録するevent種別の部分集合を特定すること）が要る、とあります。全件でも零件でもなく、選ぶことが作業の中身になります。

2. 目的からeventを選ぶ

「何を記録すべきか」から始めると決まりません。記録し得る操作は際限なくあり、優先順位が出てこないためです。先に決めるのはこのlogで後から答えたい問いです。

AU-2は、この順序を項目の並びとして持っています。a. はsystemが記録し得るevent種別の特定、b. は監査関連情報を必要とする他部門との調整、c. は実際に記録するevent種別の指定、d. が「Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents」（記録対象として選定したevent種別が、事故の事後調査を支えるうえで十分だと判断される理由を示す）、e. が選定の見直しです。

効くのはd. です。選定理由を書けと言われた時点で、目的を先に決めていなければ書けません。なおa.、c.、e. の三か所はorganization-defined parameter、つまり組織が埋める空欄です。何を記録するかも、どの頻度で見直すかも、catalog側には書かれていません。

AU-2のdiscussionは、記録を要するeventを「systemのsecurityと個人のprivacyにとって重要かつ関連するevent」と述べています。ここで挙がっているのはsecurityとprivacyです。下表のうち品質と運用改善は、本記事が実務の必要から足した目的であり、この文が名指ししたものではありません。

誰がこの選択を変えられるのかも決めておきます。AU-12（Audit Record Generation）のb. は、systemの特定の構成要素で記録されるevent種別を選択できるようにすることを求め、その主体を組織が定める空欄にしています。設定を変えられる人が決まっていない状態では、記録の範囲は静かに変わり得ます。

3. 最低 field の候補

event種別が決まったら、各eventで何を残すかを決めます。手掛かりはAU-3（Content of Audit Records）ですが、読み方に注意が要ります。AU-3の本文は「audit recordが以下を確立する情報を含むようにする」として、a. どの種類のeventが起きたか、b. いつ起きたか、c. どこで起きたか、d. eventの出所、e. eventの結果、f. eventに関係する個人・主体・対象の識別、を挙げています。

これはfield名の一覧ではありません。「以下を確立する情報を含む」という書き方であり、どのfieldでそれを表すかは書かれていません。field名らしきものはdiscussion側に、event descriptions、time stamps、source and destination addresses、user or process identifiers、success or fail indications といった形で例示されますが、そちらは「may be necessary」（必要になり得る）という限定つきです。

右列に「対応なし」と記した四つは、実務であると助かる、という理由で本記事が足した候補です。この一覧は「最低限の必須項目」ではなく出発点の候補として扱ってください。生成AIのlogについてNISTが定めた公式なschemaは、本稿の確認範囲では見当たりません。

それでもservice／model versionを候補に残すのは、どの版で処理されたかが残っていないrecordは、後から条件をそろえて読み直せないためです。版がいつ、なぜ変わったのかを記録する側の設計は生成AIの変更管理──モデル・プロンプト・参照データの更新を再評価するで扱っています。

4. prompt／outputの本文、要約、digest、参照ID

ここが生成AIのlog設計で最も判断が要る箇所です。promptとoutputの本文には業務の中身がそのまま入ります。残せば追跡できますが、logそのものが機微な情報の集積になります。入力してよい情報の区分そのものはAIに渡す情報の管理と権限設計で扱っています。

AU-3のdiscussionは、この形をほぼそのまま述べています。「there is the potential to reveal personally identifiable information in the audit trail, especially if the trail records inputs or is based on patterns or time of usage」（とりわけtrailが入力を記録している場合や、利用の傾向・時間に基づく場合、audit trailの中で個人を識別し得る情報が露見する可能性がある）。ただしこの文は生成AIについて書かれたものではありません。汎用のaudit trailの記述であり、promptを「入力」として当てはめるのは本記事の読み替えです。

SP 800-92も記録側の原則を置いています。「Avoid recording unneeded sensitive data.」（不要な機微データの記録は避ける）とし、実行可能な場合は、必要でなく、かつ権限のない者にaccessされれば相当のriskとなる情報を記録しないようloggingを設定すべきだ、と述べています。同書はpolicyの項目として、logに記録された機微情報の意図しない開示をどう扱うかも挙げています。記録した以上、漏れたときの手順を決める側の問題になります。

digestは語の意味を狭く保ってください。SP 800-92が log file の integrity checking に与えている定義は「log fileの現在のmessage digestを元のものと比較し、当該fileが変更されたかを判定する」です。対象はlog file単位の改変検知であり、内容が正しいことの証明でも、匿名化でも、復元可能な参照でもありません。prompt単位でdigestを取る使い方は本記事の応用であり、同書がそう述べているわけではありません。

もうひとつ、logを残すこと自体が扱いの対象になる点を押さえます。NIST Privacy Framework Version 1.0（2020年1月16日）はdata actionを「A data life cycle operation, including, but not limited to collection, retention, logging, generation, transformation, use, disclosure, sharing, transmission, and disposal.」と定義し、loggingを列挙のなかに置いています（including, but not limited to、すなわち例示です）。同書はまた「While managing cybersecurity risk contributes to managing privacy risk, it is not sufficient, as privacy risks can also arise by means unrelated to cybersecurity incidents」（cybersecurity riskの管理はprivacy riskの管理に寄与するが、それだけでは十分ではない。privacy riskはcybersecurityの事故と無関係な経路でも生じ得るからである）と述べます。暗号化して権限を絞ればprivacyの問題も片づく、とは書かれていません。

5. 4種のrecordを混同しない

「logを見れば分かる」と言うとき、実際には出所の違う記録が混ざっています。生成AIの利用では、少なくとも次の4種が別物です。この4分類は本記事の整理です。

SP 800-92は、出所ごとに設定の自由度が違うことを述べています。「some log sources offer very granular configuration options, while some offer no granularity at all--logging is simply enabled or disabled, with no control over what is logged」（細かな設定を提供するlog sourceもあれば、粒度が一切なく、記録の有無を切り替えられるだけで何を記録するかは制御できないものもある）。これはAU-12の読み方にも関わります。AU-12は「audit recordを生成する能力を提供せよ」という要求であって、外部serviceがそれを満たしているという保証ではありません。provider側が何を記録し、どれだけ保持し、どう取り出せるのかは、service側の仕様として個別に確認する事項です。

同書は「entryの意味は周囲の文脈に依存することが多い」とし、その文脈は別のlogのentryや、logではない情報源——例として構成管理の記録——から定めることになる、とも述べます。logだけで完結しないことが前提です。承認recordと業務判断recordを別枠で持つのは、この補完のためです。

6. access、改変保護、時刻同期、欠損の検知

記録した先の設計です。AU-9（Protection of Audit Information）は、a. で audit 情報と audit logging tool を権限のない access・改変・削除から保護すること、b. で不正な access・改変・削除を検知した際の通知を求めています。通知先は組織が定める空欄です。なお、AI 側の権限を誰にどこまで与えるかはAIエージェントを最小権限で使うための権限設計で扱っています。本節が扱うのは、logそのものへのaccessです。

discussionが保護の範囲を広げます。audit informationには「audit records, audit log settings, audit reports, and personally identifiable information」が含まれ、audit logging toolsは監査と記録の活動に用いるprogramやdeviceを指す、とあります。logの設定、監査の報告、個人を識別し得る情報、そしてtool本体まで保護対象です。log fileだけ守れば足りる範囲ではありません。

accessの具体はSP 800-92が述べています。「Limit access to log files.」——log entryを作成するために必要な場合を除き、利用者はほとんどのlog fileへaccessを持つべきではなく、必要な場合も可能であればappend-only（追記のみ）の権限とし読み取り権限は与えないべきである、改名・削除その他のfile単位の操作ができないようにすべきである、という書き方です。保管したものについては「Protect archived log files.」とし、message digestの作成と保全、log fileの暗号化、保管媒体への十分な物理的保護が「could include」（含まれ得る）と述べます。選択肢の列挙であって、暗号化や改変不能な保管を必須とする文ではありません。

誰が見てよいのかは、policyに書く項目として挙がっています。そこには「そのaccessをどう記録すべきか」まで含まれています。

時刻は崩れやすい箇所です。同書は、hostの時計が不正確ならそのlogのtimestampも不正確になり、複数hostのlogを併せて分析するときに解析を難しくする、と述べ、実際には後に起きたeventが先に起きたように見える例を挙げています。provider logとapplication logを突き合わせる設計では、この点が直接効きます。

欠損も設計項目です。「When the size limit is reached, the log might overwrite old data with new data or stop logging altogether, both of which would cause a loss of log data availability.」（上限に達すると、logは古いdataを新しいdataで上書きするか、記録そのものを停止することがある。いずれもlog dataの可用性を失わせる）。上限に達したことに誰も気づかない状態が最も困ります。欠損と失敗の検知を独立した欄に立てるのは本記事の整理ですが、この記述がその足場になります。

7. retention、archive、disposal、契約の確認

保持期間を決めるとき、「基準はどこかにあるはずだ」と探すことになります。AU-11（Audit Record Retention）を開くと、こうあります。「Retain audit records for ［組織が定める期間］ to provide support for after-the-fact investigations of incidents and to meet regulatory and organizational information retention requirements.」角括弧の部分は、原文ではorganization-defined parameterの差し込みです。

AU-11は保持期間そのものを空欄にしています。parameterの説明も「time period」「記録の保持方針と整合する期間」であって、値は与えられていません。本稿が期間の数値を書かないのはこのためです。

判断の向きだけはdiscussionにあります。「管理上、法的、監査上、その他運用上の目的にとって当該recordがもはや不要だと判断されるまで保持する」。期間ではなく、必要でなくなったと誰がどう判断するかを決める形です。なお同discussionには米国連邦機関に固有の制度への言及がありますが、日本の読者へそのまま当てはまるものではないため本稿では扱いません。

保管についてSP 800-92は、保持の要件を満たすため「元のlog sourceが支えられる期間より長く」log fileの複製を保つ必要が生じ得るとし、そのためlogの保管過程を確立することが必要になる、と述べています。生成AIのserviceでは、この「元のlog sourceが支えられる期間」がservice側の仕様に依存します。仕様として公開されていない場合もあります。自社が決めた期間より短ければ、複製を取る仕組みが要ります。

同書はretentionとpreservationも分けています。retentionは運用の一部としての定期的な保管、preservationは通常なら破棄されるlogを、特に関心のある活動の記録が含まれるという理由で残すことで、事故対応や調査の文脈で行われます。policyの項目にも、改変と破棄を止める要求の扱いが挙がっています。廃棄の仕組みを作るときは、廃棄を止める仕組みも同時に決めることになります。

• 保持期間：event種別ごとに分けて決める。全種別を同じ期間にする必要はない
• 廃棄：何をもって不要と判断するか、誰が判断するか、どう消すか
• 停止条件：調査などのために廃棄を止める場合の、要求の受け方と対象の特定方法

8. 検索、export、事故時の証拠への引継ぎ

残っていても取り出せなければ、無いのと大きくは変わりません。AU-11が保持の理由に挙げるのは「after-the-fact investigations of incidents」（事故の事後調査）ですが、AU-11自身はRetain——保持することしか述べていません。取り出せる状態にすることは、このcontrolに書かれていない別の設計です。

取り出しで最初に詰まるのは、記録同士がつながらないことです。SP 800-92は「共通して記録されている値が無いために、異なるlog sourceが記録したeventを結びつけることが難しくなり得る」と述べています。節3でcorrelation IDを候補に挙げたのはこのためです。ただし前述のとおり、その項目名も、そうしたIDを意図的に発行するという設計も、同書が述べているものではありません。

証拠として渡す場合は扱いが一段変わります。同書は、logが証拠として必要になり得る場合、複製と解釈の過程の忠実性に疑義が生じたときに備えて、元のlog file、集約されたlog file、解釈されたlog data の複製を取得することが望ましい場合がある、とし、証拠のための保持は別の形式の保存や別の過程——recordへのaccessの追加的な制限など——を伴い得る、と続けます。

実務に落とすと、加工した結果だけを渡さないということになります。集約や整形の過程で落ちた情報は、後から足せません。exportの形式、取り出す担当、渡し先を、事故が起きる前に決めておく欄です。事故そのものの初動——停止、連絡、影響評価——は生成AIインシデントの初動対応が引き受けます。本稿は、そこへ渡す材料の側だけを扱います。

9. logが証明できること／できないこと

ここが本稿で最も落としたくない節です。logはあると安心する道具である分、できることを過大に語られやすい記録でもあります。

SP 800-92は読み取りの限界を率直に書いています。「In some cases, it might not be possible to gain a full understanding of a log entry.」（場合によっては、あるlog entryを完全に理解できないこともある）。そして「Context is needed to validate unreliable log entries」——信頼性の低いentryを妥当だと確かめるには文脈が要る、その例としてsecurity softwareがしばしば誤検知を生むことが挙げられています。改変についても、保存中または転送中に適切に保護されていないlogは「意図的・非意図的な改変や破壊」を受け得る、と述べています。

この対比のうち右列を書いておくことが設計の一部です。「logがあるから大丈夫」という言い方は、右列を見ないことで成り立ちます。privacyの側からも一つ足せます（節4）。logの保護を固めたことは、logを残したこと自体が生むprivacy上の問いへの答えにはなりません。

10. 一枚で残すログ設計表

ここまでの欄を一枚へ落とすと、そのままlog設計の記録になります。この様式は本記事の編集上の整理であり、公的機関が定めた様式ではありません。

この様式で効くのは、埋まらない欄が目に見える点です。「誰がaccessできるか」が空欄のまま運用が始まっている、と分かること自体が、次の作業を決めます。

まとめ

生成AIの操作logを設計する作業は、量の調整ではなく選択の連続です。何のために残すのかを決め（節2）、各eventで何を残すかを決め（節3）、本文をどう扱うかを決め（節4）、出所の違う記録を分け（節5）、誰が見られるかと欠けたときの気づき方を決め（節6）、いつまで持ちいつ消すかを決める（節7）。取り出し方（節8）と、答えられない問い（節9）まで書いて、ようやく一枚になります。

まだ何も決めていないなら、節2の目的の表を一行だけ埋めてみてください。すでにlogを取っているなら、節9の右列——このlogでは示せないこと——を書き出してみてください。そこに出てくるものが、logの外側で決めておくべき事項です。

---

引用元・参考文献

公的機関・一次情報

• NIST『Security and Privacy Controls for Information Systems and Organizations』SP 800-53 Rev. 5（Release 5.2.0。AU-2／AU-3／AU-9／AU-11／AU-12の statement および discussion。本稿はOSCAL版catalogで確認。確認日：2026年8月27日）：https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• NIST『Guide to Computer Security Log Management』SP 800-92、2006年9月（log managementの定義、記録量に関する記述、機微データの記録回避、accessの制限、保管したlogの保護、時刻の不整合、上限到達時の可用性喪失、log sourceの粒度と文脈、retentionとpreservationの区別、証拠としての保持、log fileのintegrity checkingの定義／確認日：2026年8月27日）：https://csrc.nist.gov/pubs/sp/800/92/final
• NIST『Cybersecurity Log Management Planning Guide』SP 800-92 Revision 1、初期公開ドラフト、2023年10月11日公開（コメント締切2023年11月29日。2026年8月27日時点で最終版は未公表）：https://csrc.nist.gov/pubs/sp/800/92/r1/ipd
• NIST『NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0』2020年1月16日（data actionの定義、cybersecurity riskとprivacy riskの関係／確認日：2026年8月27日）：https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf
• NIST『AI RMF Playbook』GOVERN 6.1（Transparency & Documentation の問い、およびPlaybook自身の位置づけ／確認日：2026年8月27日）：https://airc.nist.gov/airmf-resources/playbook/govern/

※ 次のものは本記事による編集上の整理であり、引用した資料が定めたものではありません。(1) 節3のfield候補のうちrole、service／model version、approval、correlation IDの四つは、本稿が引いた資料に対応する記述がありません。対象resource は、AU-3 c. の本文（どこで起きたか）ではなく discussion の filenames involved に部分的に対応します。AU-3のa〜fは「audit recordが確立すべき情報」であってfield名の一覧ではなく、discussion側の例示は「may be necessary」という限定つきです。(2) 節5の4分類（provider log／application log／承認record／業務判断record）。(3) 図と本文の6段（目的→event選択→record生成→保護・access→利用→保持・廃棄）。(4) 節10の設計表の様式。(5) 節2の目的の類型のうち品質と運用改善——AU-2のdiscussionが記録対象の基準として挙げるのはsystemのsecurityと個人のprivacyです。(6) prompt単位でdigestを取る用法——SP 800-92のmessage digestはlog file単位の改変検知です。SP 800-92は2006年9月のFinalと、2023年10月11日公開のRevision 1初期公開ドラフトが別物です。本稿の本文は2006年Finalを引き、Rev.1ドラフト由来の語（第4要素をaccessingとする定義）は節6の囲みでドラフトとして明示しています。2006年Finalにsupersededの表示はなく、Rev.1の最終版は2026年8月27日時点で未公表です。AU-11は保持期間そのものをorganization-defined parameter（組織が定める空欄）にしています。本稿に保存期間、件数、頻度、容量の数値を置いていないのは、参照した資料にそれらの指定がないためです。SP 800-53は米国連邦政府のsystemを対象としたcontrol catalogであり、日本の企業に課された法的義務ではありません。AI RMF Playbookは自主的なもので、義務ではありません。SP 800-53はRelease 5.2.0より新しい版が本稿の確認範囲では見つからなかった、という状態です。Privacy Frameworkの現行版は1.0で、1.1は初期公開ドラフトの段階にあります。