AI利用ログはどこまで残すべきか？生成AI監査と説明責任の基本

ログは残しています。でも、監査で何を説明できる状態なのかと聞かれると、正直まだ答えきれません

これは、生成AIの社内展開を進める企業で、情シス、セキュリティ、監査、DX推進の各担当者が直面しやすい悩みです。以前は、AIチャットや要約機能を「便利に使えるか」が主な論点でした。しかし現在は、誰が、いつ、どの業務目的で、どの情報を入力し、どの出力を利用したのかを、後から説明できるかが問われるようになっています。

たとえば想定例として、全社トライアル開始後3か月・対象300名・AI利用1,200件を振り返る場合、単に利用件数を集計するだけでは不十分です。情シスはアクセス権を、セキュリティは機密情報の混入を、監査担当は証跡の完全性を、DX推進責任者は現場が萎縮しない運用を見ます。AIガバナンスは、リスクを正しく認識し、AIのライフサイクル全体で必要な対策を実行する考え方として、経済産業省「AI事業者ガイドライン」などでも整理されています。

弊社が提供するKanataのように、プロジェクト単位でメンバーや権限を管理し、AIチャット・AI要約・eラーニングなどを業務単位で使えるサービスを利用する場合も、ログ設計そのものは各社の業務、規程、監査方針に合わせて決める必要があります。Kanataの操作情報では、プロジェクトごとに利用者・データ・アプリを整理する考え方が示されています。また、社内専用スペースでの情報取り扱いや、人によるレビューの重要性も運用上の注意として整理されています。

この記事では、AI利用ログを「残す／残さない」の二択ではなく、目的、項目、保存期間、アクセス権、監査対応、説明責任の関係から設計する方法を整理します。目指すのは、必要な証跡を残しながら、現場が安心してAIを活用できる状態です。ただし、ログだけではガバナンスは完成しません。入力ルール、教育、権限管理、定期的な見直しと組み合わせて初めて、説明可能なAI活用に近づきます。自社のログ設計を点検するつもりで読み進めてください。

AI利用ログは「監視」ではなく説明責任のために設計する

open_in_full

AI利用ログという言葉を聞くと、「社員の利用状況を監視するもの」と受け取られることがあります。しかし、企業が生成AIを業務で使うときに本当に必要なのは、利用者を萎縮させるための記録ではありません。

必要なのは、後から次の問いに答えられる状態です。

• 誰が、どの業務でAIを使ったのか
• どのような情報を入力したのか
• AIの出力を、業務判断や社外向け資料に使ったのか
• 人による確認は行われたのか
• 問題が起きたとき、原因を追えるのか

これらに答えられなければ、生成AIの活用は「便利だが説明できない業務」になってしまいます。

一方で、すべての会話内容を無条件に保存すればよいわけでもありません。ログを取りすぎると、個人情報や機密情報を長期間抱え込むことになり、かえって管理リスクが増えます。さらに、社員が「何を聞いても見られている」と感じれば、AI活用そのものが進まなくなる可能性もあります。

そのため、AI利用ログは「できるだけ多く残す」ものではなく、「目的に対して必要十分に残す」ものとして設計する必要があります。

AI利用ログを残す目的は4つに分けて考える

open_in_full

ログ設計で最初に決めるべきことは、保存項目ではありません。まず決めるべきなのは、何のためにログを残すのかです。

目的が曖昧なまま項目だけを増やすと、後から見返しても使いにくいログになります。逆に、目的が明確であれば、保存すべき項目、保存期間、閲覧権限を決めやすくなります。

セキュリティのため

最も分かりやすい目的は、情報漏えいや不適切利用の検知です。

たとえば、個人情報、顧客の機密情報、未公開の財務情報、契約条件などをAIに入力していないかを確認するためにログを使います。個人情報保護委員会も、「生成AIサービスの利用に関する注意喚起等について」の中で、生成AIサービスの利用に関して、個人情報の適正な取扱いとイノベーション促進のバランスに留意する必要性を示しています。

この目的では、入力内容、利用者、利用日時、利用したプロジェクトやアプリ、取り扱った情報区分が重要になります。

監査のため

監査では、「AIを使ったかどうか」だけでなく、「その利用が業務上妥当だったか」「出力をどのように確認したか」が問われます。

たとえば、顧客提案書、契約書レビュー、社内規程の確認、議事録の要約などにAIを使った場合、後から判断の根拠を追える状態が必要です。

この目的では、入力内容、出力内容、参照した資料、レビューした人、最終的に出力を採用したかどうかが重要になります。

品質改善のため

ログは、リスク管理だけでなく、AI活用の改善にも使えます。

どの部署がよく使っているのか。どの業務で利用頻度が高いのか。どのプロンプトが繰り返し使われているのか。どの領域で「要確認」や出力の手戻りが多いのか。こうした情報を見れば、教育すべきテーマや、テンプレート化すべき業務が見えてきます。

Kanataでは、プロンプトライブラリや学習データライブラリを使って、よく使う指示文や社内資料を再利用する考え方が示されています。このような機能は、ログレビューで見つかった「よい使い方」を組織内で共有する際にも役立ちます。

この目的では、詳細な全文ログよりも、利用目的、業務カテゴリ、利用頻度、成功・失敗の分類が役立つことがあります。

教育と定着のため

AI利用ログは、社員を取り締まるためだけではなく、よい使い方を広げるためにも使えます。

たとえば、よくできたプロンプトを社内テンプレートにする。危険な入力例を研修で共有する。AI出力をそのまま社外に提出しそうになった事例をもとに、レビュー手順を整える。こうした使い方をすれば、ログは現場を縛るものではなく、AI活用の再現性を高める材料になります。

AI利用ログで残すべき基本項目

open_in_full

AI利用ログの項目は、業務やリスクに応じて変わります。ただし、多くの企業で共通して検討すべき基本項目があります。

最低限残したい項目

まずは、次のような基本情報を残します。

Kanataは、AIチャット、AI要約、eラーニングなどのアプリをプロジェクト単位で利用する設計になっています。そのため、ログ設計でも「どのプロジェクトで、どのアプリを使ったか」を追えるようにしておくと、運用単位とログ単位がそろいやすくなります。

監査で重要になる項目

監査や説明責任の観点では、基本項目だけでは足りないことがあります。特に重要なのは、AIの出力が業務上どのように使われたかです。

ここで重要なのは、「入力と出力の全文を常に残すべき」と決めつけないことです。全文保存が必要な業務もあれば、要約やメタデータだけで十分な業務もあります。

たとえば、社内FAQのような比較的低リスクな利用であれば、質問カテゴリと回答ログだけで十分な場合があります。一方で、顧客提案、契約、監査、法務、人事評価に関わる利用では、より詳細なログが必要になることがあります。

残さない、またはマスキングすべき情報を決める

open_in_full

ログ設計では、「何を残すか」と同じくらい、「何を残さないか」が重要です。

生成AIの利用ログには、プロンプトや出力文が含まれることがあります。そこに個人情報、顧客情報、契約条件、財務情報などが入っていると、ログそのものが高リスクな情報資産になります。

ログ保存時に注意すべき情報

Kanataのベストプラクティスでも、個人情報は原則NG、必要時はマスキング、機微情報や未公開財務情報は禁止という整理がされています。

マスキングの例

マスキングで大切なのは、単に名前を伏せることではありません。複数の情報を組み合わせれば、個人や企業を再特定できる場合があります。特に少人数の部署、特定業界の大口顧客、特殊な契約条件などは、匿名化しても推測できることがあります。

そのため、マスキングは「置換」ではなく、「再特定リスクを下げる処理」として考える必要があります。

保存期間は一律ではなく、業務リスクで分ける

open_in_full

AI利用ログの保存期間は、すべて一律にする必要はありません。むしろ、業務の性質やリスクに応じて分けるほうが現実的です。

保存期間を決めるときは、次の3つの軸で考えます。

1. 業務リスク。社内のちょっとした文章作成と、顧客提案や契約書レビューでは、後から説明すべき重さが違います。
2. 扱う情報の機密度。公開情報に近い内容と、顧客機密や個人情報に近い内容では、保存によるリスクが違います。
3. 後から説明が必要になる期間。契約や監査に関わるものは、数年後に確認が必要になる場合があります。一方で、日常的な壁打ちや文章の言い換えは、長期保存の必要性が低い場合もあります。

保存期間の想定例

以下はあくまで想定例です。実際には、自社の文書管理規程、契約条件、法令、監査方針に合わせて決める必要があります。

保存期間を長くすれば安心、というわけではありません。不要なログを長く残すほど、漏えい時の影響範囲は広がります。古いログは文脈が失われ、誤解を生むこともあります。

重要なのは、「なぜその期間残すのか」を説明できることです。

アクセス権は「見られる人」を最小限にする

open_in_full

AI利用ログには、業務上の相談内容、社内資料、顧客情報、個人に関わる情報が含まれる可能性があります。そのため、ログは保存するだけでなく、誰が見られるのかを設計する必要があります。

ログ閲覧権限の基本

避けたいのは、「管理者ならすべて見られる」という状態です。管理者権限は便利ですが、強すぎる権限は内部不正や不要な閲覧のリスクになります。

ログ閲覧そのものにも、閲覧者、閲覧日時、閲覧理由を記録することが望まれます。特に個人情報や顧客情報に近いログでは、「誰がログを見たか」を追えない状態は避けるべきです。

プロジェクト単位の権限設計と合わせる

Kanataは、スペース、プロジェクト、アプリという概念で業務を整理します。スペースは組織全体の入れ物、プロジェクトは業務単位のグループ、アプリはAIチャット・AI要約・eラーニングなどの機能単位として説明されています。

この構造を前提にすると、ログ設計もプロジェクト単位で考えやすくなります。

たとえば、営業部の提案書作成プロジェクト、人事部の問い合わせ対応プロジェクト、経営会議の議事録要約プロジェクトでは、参加者も情報の機密度も違います。ログ閲覧権限も同じでよいはずがありません。

Kanataのベストプラクティスでは、プロジェクトは「関係者が同じ情報を見てよいか」で切るという考え方が示されています。AI利用ログも、この単位に合わせて閲覧範囲を設計すると、現場運用とセキュリティ管理を両立しやすくなります。

監査で問われるのは「ログがあるか」ではなく「説明できるか」

open_in_full

生成AIの監査対応で重要なのは、ログが存在することそのものではありません。ログを使って、業務上の判断や運用の妥当性を説明できるかです。

たとえば、監査では次のような問いが出る可能性があります。

• この部門では、どの業務に生成AIを使っていますか
• 個人情報や機密情報を入力しないルールはありますか
• ルール違反が起きたとき、検知できますか
• AIの出力をそのまま社外に出していませんか
• 人によるレビューはどこで行われていますか
• 古い学習データや誤ったプロンプトを使っていませんか
• 退職者や異動者のアクセス権は見直されていますか

これらの問いに答えるためには、単なるアクセスログだけでは足りません。利用目的、入力情報、出力利用、レビュー履歴、権限管理、教育状況まで含めて、運用全体を説明する必要があります。

監査対応のためのログレビュー手順

月次または四半期で、次のようなレビュー手順を設けると実務に落とし込みやすくなります。

1. 対象期間を決める
2. 対象部門・プロジェクトを決める
3. 高リスク利用を抽出する
4. 入力情報と出力利用の妥当性を確認する
5. 人によるレビューの有無を確認する
6. 是正事項を記録する
7. 教育・ルール改定に反映する

月次レビューの想定例

ここでも目的は、個人を責めることではありません。むしろ、同じミスが起きないように、ルール、テンプレート、教育、権限を改善することです。

説明責任を果たすには、人のレビュー履歴が欠かせない

open_in_full

生成AIの出力は便利ですが、そのまま正しいとは限りません。AIは、誤った内容を自然な文章で出すことがあります。数字、固有名詞、日付、引用、契約条件などは特に注意が必要です。

Kanataのベストプラクティスでも、AIは「もっともらしい嘘」をつく可能性があるため、社外に出る文書、数字、引用は必ず人が裏取りすると整理されています。

つまり、AI利用ログだけでなく、人がどのように確認したかの履歴も重要になります。

レビュー履歴として残したい項目

特に、社外向け提案書、契約関連文書、採用・人事評価、法務・監査資料などでは、「AIが出したから」では説明になりません。最終的に人が確認し、判断したことを残す必要があります。

AI利用ログ設計テンプレート

open_in_full

ここからは、実際にログ設計を進めるためのテンプレートを示します。すべての業務で同じ項目を埋める必要はありません。まずは、情報漏えい、法務・監査、顧客対応、社外提出物などに関わる高リスク業務から整理するのが現実的です。

ログ設計シート

業務別の設計例

保存期間はあくまで想定例です。実際には、自社の文書管理規程、契約、法令、監査方針に合わせて調整してください。

Kanataを使う場合に押さえたい運用ポイント

open_in_full

Kanataは、AIチャット、AI要約、eラーニングなどを業務に使うためのプラットフォームとして設計されています。操作マニュアルでは、プロジェクトごとに利用者、データ、アプリを整理し、安全に共同作業する考え方が示されています。

そのため、Kanataを使う場合も、ログ設計は単独で考えるのではなく、プロジェクト設計、権限設計、学習データ管理、プロンプト管理と合わせて考えることが重要です。

プロジェクト単位で利用範囲を分ける

まず、情報の見せ方に応じてプロジェクトを分けます。

部署単位で分ける方法もあります。営業、人事、経理、情報システムなど、扱う情報が大きく異なる場合に向いています。

業務単位で分ける方法もあります。議事録要約、社内FAQ、提案書作成、研修コンテンツなど、横断的に使う場合に向いています。

顧客・案件単位で分ける方法もあります。特定顧客の情報や契約条件を扱う場合は、関係者を限定しやすくなります。

Kanataのベストプラクティスでも、プロジェクトは「関係者が同じ情報を見てよいか」で切るという考え方が示されています。AI利用ログも、この考え方に合わせると、閲覧範囲や管理責任を整理しやすくなります。

学習データとプロンプトも管理対象にする

AI利用ログというと、利用者の入力とAIの出力だけに注目しがちです。しかし、AIがどの資料を参照したか、どのプロンプトテンプレートを使ったかも重要です。

たとえば、古い規程を参照して回答していた。営業資料の旧版をもとに提案文を作っていた。禁止表現を含む古いプロンプトが残っていた。こうした状態では、入力と出力のログが残っていても、説明責任は十分に果たせません。

Kanataでは、プロジェクトライブラリにAI設定、プロンプト、学習データを登録して再利用する考え方が示されています。そのため、月次棚卸しや版管理を行い、古い資料や不要なプロンプトを放置しないことが重要です。

Kanataだけでログ設計が完了するわけではない

Kanataは、AI活用を業務単位で整理し、利用者やプロジェクトを管理するための基盤になります。ただし、ログの保存期間、監査方針、閲覧権限、社外利用時の承認ルールは、各社の規程や契約、監査基準に合わせて設計する必要があります。

つまり、Kanataを導入すれば自動的に説明責任が完成するわけではありません。プラットフォームの機能と、自社の運用ルールを組み合わせることが必要です。

AI利用ログ設計のチェックリスト

open_in_full

自社のAI利用ログ設計を確認するためのチェックリストです。

目的設計

• AI利用ログを残す目的を明文化しているか
• セキュリティ、監査、品質改善、教育のどれに使うかを分けているか
• ログを社員監視のためだけに使わない方針を示しているか

項目設計

• 利用者、日時、プロジェクト、アプリ、操作種別を残しているか
• 入力内容と出力内容をどの粒度で残すか決めているか
• 参照資料やプロンプトテンプレートを追えるか
• 出力を業務利用したかどうかを記録できるか

保存期間

• 業務リスク別に保存期間を分けているか
• 保存期間の根拠を説明できるか
• 不要なログを長期間残していないか
• 削除・延長条件を決めているか

アクセス権

• ログ閲覧者を最小限にしているか
• プロジェクト単位で閲覧範囲を分けているか
• ログ閲覧の履歴を残しているか
• 退職者・異動者の権限を見直しているか

監査・レビュー

• 月次または四半期のログレビューを行っているか
• 高リスク利用を抽出できるか
• AI出力を人がレビューした履歴を残しているか
• 監査時に提出する形式を決めているか

教育・改善

• よくあるNG入力を研修に反映しているか
• よいプロンプトをテンプレート化しているか
• 古い学習データを棚卸ししているか
• インシデントやヒヤリハットをルール改定に反映しているか

まとめ：AI利用ログは、後から説明できる業務設計である

open_in_full

AI利用ログは、単なる技術ログではありません。生成AIを業務で使う以上、誰が、何のために、どの情報を使い、どのように出力を確認したのかを説明するための業務設計そのものです。

重要なのは、すべてを残すことではありません。目的に応じて、必要な項目を、必要な期間だけ、必要な人だけが見られる形で残すことです。

AI利用ログの設計では、次の点を押さえる必要があります。

• ログは監視ではなく、説明責任のために設計する
• 目的をセキュリティ、監査、品質改善、教育に分ける
• 入力、出力、参照資料、レビュー履歴を必要に応じて残す
• 保存期間は業務リスクごとに分ける
• 閲覧権限は最小限にする
• ログだけでなく、教育、権限管理、定期レビューと組み合わせる
• Kanataのような業務単位のAI活用基盤を使う場合も、自社ルールとの接続が必要になる

生成AIの利用が広がるほど、「使ってよいか」だけではなく、「後から説明できるか」が重要になります。ログ設計は、AI活用を止めるためのものではありません。現場が安心して使い続けるための土台です。

まずは、自社の高リスク業務を3つ選び、ログ設計シートを埋めるところから始めるとよいでしょう。

Q&A：AI利用ログ設計でよくある質問

必ずしも全文で残す必要はありません。顧客提案、契約、監査、法務など説明責任が重い業務では全文保存が必要になる場合があります。一方、日常的な壁打ちや文章の言い換えでは、利用目的やカテゴリ、日時、利用者などのメタデータだけで足りる場合もあります。業務リスクに応じて、全文保存、要約保存、メタデータ保存を分けることが重要です。

一律の正解はありません。保存期間は、自社の文書管理規程、契約条件、法令、監査方針に合わせて決める必要があります。想定例としては、日常的な文章作成は90日〜180日、社内FAQは1年、顧客提案や契約関連は3年〜5年などが考えられます。ただし、これは一般的な設計例であり、実際には各社のリスク評価に基づく確認が必要です。

原則は最小権限です。利用者本人、所管プロジェクトの管理者、情シス、セキュリティ、監査担当など、目的に応じて閲覧範囲を分けます。「管理者ならすべて見られる」という設計は避けたほうが安全です。特に、顧客情報や個人情報を含む可能性があるログでは、閲覧履歴も残すことが望まれます。

ログだけでは十分ではありません。監査で問われるのは、ログの有無ではなく、業務上の判断や運用の妥当性を説明できるかです。そのため、入力ルール、禁止情報の定義、人によるレビュー、承認フロー、教育、定期的な棚卸しと組み合わせる必要があります。

自動で完了するわけではありません。Kanataは、プロジェクト単位でAIチャット、AI要約、学習データ、プロンプトなどを整理しやすい業務基盤として活用できます。一方で、ログの保存期間、監査方針、閲覧権限、レビュー手順は、各社の規程や契約、監査基準に合わせて設計する必要があります。ツールの機能と社内ルールを接続することが重要です。