チャットボットのログ保存期間｜削除・権限・契約確認

チャットボットの導入会議で「会話ログは1年残せば十分ですか」と聞かれても、年数だけで答えることはできません。問い合わせへの回答を見直すには一定期間の履歴が必要です。一方、個人情報を含む会話を目的なく長期間残すと、閲覧者が増え、漏えい時の影響も大きくなります。

最初に決めるべきなのは、保存期間の長短ではなく、どのログを、何のために、誰が、いつまで使うかです。会話本文、添付ファイル、利用者評価、システムの実行記録、管理者による設定変更の記録では、保存する目的も確認する担当者も異なります。すべてを「チャットログ」の一項目にまとめると、削除対象や契約条件が曖昧になります。

以下では、チャットボットのログ保存期間を決める手順と、削除、権限、委託契約で確認すべき項目を整理します。法令や業界規程に基づく個別の判断については、自社の法務・個人情報保護担当者や専門家へ確認してください。

チャットボットのログ保存期間に一律の正解はない

ログ保存期間に一律の正解がないのは、利用目的と取り扱う情報が組織ごとに異なるためです。営業時間や店舗案内だけを扱う公開チャットボットと、契約番号や相談内容を受け付けるチャットボットでは、漏えい時の影響も、後から会話を確認する必要性も同じではありません。

公的機関の仕様書でも、要件は一つの数字だけでは表されていません。長野県の令和8年度生成AIによる業務効率化推進事業業務 仕様書では、「ログデータ」に関する要件として、直近90日分を即日確認できることと、最低1年間保存することが分けて記載されています。また、同資料の情報セキュリティおよび業務終了時の要件では、受託者による利用データへのアクセス制限と、契約終了後の情報資産の返却・消去が示されています。資料名と年度を版の識別情報とし、2026年9月15日に公開PDFの該当項目を確認しました。

これは「すべてのチャットボットで1年間保存すべき」という意味ではありません。即時に検索できる期間、データを保持する期間、アクセスできる人、契約終了時の消去方法を分けて検討した事例として参考になります。自社の期間を決める際は、問い合わせの再確認が必要になる時期、品質改善の周期、事故調査で遡る範囲を根拠にします。

製品やサービスによって、標準の保存期間や削除方法も異なります。OpenAIのChatGPTのチャットおよびファイルの保持ポリシーでは、削除したチャットが画面から消える時点と、原則としてシステムから削除されるまでの期間を区別しています。チャットと、ライブラリに保存されたファイルが別に管理される場合があることも説明されています。こうした他サービスの条件をSocratesや自社の契約へそのまま当てはめず、採用候補ごとに最新の公式仕様を確認してください。

最初に保存するログの種類と利用目的を分ける

保存期間を決める前に、対象となるデータを棚卸しします。画面上では一つの会話に見えても、内部では本文、添付ファイル、評価、技術的な実行記録が別の場所に保存されることがあります。CSVへ出力した場合、そのファイルは製品外にある新たな管理対象になります。

会話ログと監査ログは、名称が似ていても目的が異なります。会話を改善する具体的な流れはチャットボットの会話ログ分析方法、設定変更を追跡する項目はチャットボット監査ログの設計で整理しています。保持台帳には両方を載せますが、保存期間を機械的にそろえる必要はありません。

判断に迷いやすいのが、会話本文を削除した後の集計値です。本文を消しても、会話ID、利用時刻、分類、評価が個人や特定の問い合わせと結び付くなら、必ずしも匿名の統計情報とはいえません。何を削除し、何を残すのかを決めたうえで、残した情報から元の利用者を特定できないか、データの流れに沿って確認します。

チャットボットのログ保存期間を決める6つの手順

保存期間は「競合製品が1年だから」という理由ではなく、自社に必要な期間を説明できる手順で決めます。まずは一つの業務、または一つのチャットボットを対象に、次の6段階で整理してください。

1. 利用目的を動詞で書く

「品質向上のため」のような広い表現だけでは、いつ目的を達成したのか判断できません。「未回答を月次で分類してFAQを更新する」「苦情の引き継ぎ内容を担当者が確認する」「外部連携のエラーを発見後に調査する」のように、誰が何をするのかまで書きます。

目的を明確にできないデータは、取得や保存を続ける理由も説明できません。「将来使うかもしれない」という理由だけで全文を残す前に、集計値だけで目的を果たせないか、入力段階で取得しない選択がないかを確認してください。個人情報を含む入力項目の整理には、AIチャットボットで個人情報を扱う際の考え方も参照できます。

2. 必要な遡及期間を業務の周期から出す

次に、目的を果たすために何日、または何か月遡る必要があるかを確認します。毎週ログを確認する業務なら、確認漏れや担当者の休暇も考慮して期間を決めます。季節によって問い合わせ内容が変わる場合は、前年同期の本文まで必要なのか、分類別の集計だけを長く残せばよいのかを切り分けます。

事故調査では、問題の発生から検知までの時間も考慮します。エラーが当日に判明する場合と、顧客から数週間後に連絡を受けて判明する場合では、実行ログに必要な遡及期間が変わります。想定する事象、検知経路、調査開始までの最大期間、調査に必要なデータを一行にまとめてください。

3. 情報の影響と利用頻度を確認する

業務上の必要性だけでなく、長期間残すことで生じる影響も確認します。氏名、連絡先、健康・生活相談、契約内容などを含む会話は、閲覧者が増えたり不正に出力されたりした場合の影響が大きくなります。本文を保持する必要がなくなった後は、個人を特定しにくい分類別集計へ切り替えられないか検討します。

一方、障害調査に必要なrequest_idや処理結果まで早期に消すと、問題の原因を確認できなくなります。個人情報を減らす作業と調査証跡の削除を一括で扱わず、項目ごとに必要性を確認します。会話本文の期間を短くし、識別子と処理結果だけを別の期間で残す設計も候補になります。

4. 即時参照とアーカイブを分ける

長期間の保存が必要でも、その全期間を日常の担当者が管理画面から検索できる状態にしておく必要はありません。直近のログは問い合わせ対応や改善のために即時参照し、それ以前のログは責任者の承認を受けた場合だけ復元できるアーカイブへ移す方法があります。

この方法を採る場合は、アーカイブを単なるCSVの置き場所にしないことが重要です。保管責任者、暗号化、閲覧申請、持ち出し、再出力、削除日を決めます。復元に時間がかかるなら、事故対応で求められる復元時間を満たせるかも確認してください。

5. 保存終了日と削除完了日を決める

「1年間保存」と定めるだけでは、いつから1年を数えるのか分かりません。会話終了日、最終更新日、案件完了日、契約終了日のどれを起算日にするか明記します。保存期間を経過した翌日に削除するのか、月次処理でまとめて削除するのかも決めておきます。

さらに、管理画面から見えなくなる日、主系データから削除される日、バックアップの世代更新によって復元対象から外れる日を分けます。削除処理が失敗した場合の通知先と再実行方法も必要です。期限を過ぎたデータが残っていないか、件数やサンプルを使って定期的に確認できる状態にします。

6. 決定者と見直し日を記録する

期間を決めたら、業務責任者、情報管理責任者、法務・個人情報保護担当者、システム管理者の確認範囲を記録します。採用した年数だけでなく、根拠となった利用目的、規程、契約条項、製品仕様の版、確認日も残してください。

製品仕様や業務目的は変わります。次回の見直し日を設定し、入力項目の追加、利用部署の拡大、外部連携、事故、契約更新があった場合は、予定日を待たずに再確認します。

保持台帳に保存・参照・削除の期限を記録する

検討した内容は、規程の文章だけでなく一覧表にも落とし込みます。「ログ一式」のようなまとめ方を避け、少なくとも次の列を設けると、製品仕様との比較や削除テストに利用できます。

例えば、回答改善に使う会話本文は月次レビューに必要な範囲、監査ログは設定事故を遡るために必要な範囲、CSVは分析作業の終了日まで、と分けて記録します。他組織の例から数字を借りるのではなく、自社の業務周期と確認済みの要件に基づく期間を入力します。

台帳で定めた保存期間と、製品で設定できる期間が一致しないこともあります。その場合は、製品の標準設定に合わせて自社要件を変えるのではなく、設定変更の可否、外部出力の必要性、運用で補う場合の負担、別製品への変更を比較します。外部出力は管理対象となる保管先を増やすため、利用目的と削除責任を明確にできる場合に限って検討してください。

ログ削除は画面から消える時点だけで判断しない

削除ボタンを押して一覧から消えても、すべての保存先から同時に消去されたとは限りません。削除には、表示対象から外す論理削除、主なデータベースから取り除く物理削除、検索索引や一時ファイルの更新、バックアップ世代の失効など、複数の段階があります。

AnthropicのClaude消費者向けデータ保持案内でも、会話履歴から直ちに除外されることと、バックエンドの保存システムから削除されるまでの期間が区別されています。モデル改善の設定、ポリシー違反の検知、法的な必要性などに伴う条件も説明されているため、「削除後○日」という部分だけを抜き出して判断できません。法人向けサービスやAPIには別の条件が適用される可能性があるため、実際の契約対象に対応する資料を確認します。

自社の削除仕様では、次の状態をそれぞれ定義します。

1. 利用停止：日常業務の検索・分析に使えない状態。
2. 主系削除：通常稼働するデータベースやファイル領域から削除された状態。
3. 派生データ処理：索引、要約、分類、キャッシュ、出力済みファイルへの反映が確認された状態。
4. バックアップ失効：定めた世代更新を経て、通常の復元対象から外れた状態。
5. 削除完了確認：処理日時、対象範囲、結果、確認者を記録した状態。

削除の単位が、一件の会話、利用者、期間のいずれであるかも確認します。個別削除に対応していても、会話内の添付ファイルや外部連携先のチケットまで連動して削除されるとは限りません。データの流れに沿って保存先を確認し、それぞれの担当者と削除期限を決めます。

通常削除と例外的な保全を混ぜない

事故調査、紛争対応、法令上の必要性などにより、通常の削除を一時的に止める場合があります。ただし、「念のため」という理由で無期限に保全すると、通常の削除ルールが形骸化します。例外を設ける場合は、対象、理由、申請者、承認者、開始日、閲覧者、解除条件、次回確認日を記録します。

保全中のデータは通常の分析対象から外し、調査に必要な担当者だけが扱えるようにします。ただし、対象データだけの自動削除停止、閲覧制限、保全解除を製品機能で実行できるとは限りません。採用候補の仕様を確認し、対応していない場合は、承認済みの保管先への必要最小限の退避、閲覧申請、解除期限の台帳管理などの代替運用を定めます。案件終了後に通常削除へ戻したことも確認してください。

一方、情報漏えいが疑われるからといって、関係するログを急いで削除してはいけません。影響を限定するためのアクセス停止と、調査に必要な証跡の保全を別の操作として扱います。緊急時に保持停止やアクセス制限を指示できる担当者と連絡先を、平時に決めておきます。

ログ閲覧・出力・削除の権限を分ける

保存期間を短くしても、その期間中に誰でも全文を閲覧したり持ち出したりできる状態では、十分に管理できているとはいえません。日常業務で必要な一覧閲覧、個別会話の全文閲覧、CSV出力、個別削除、一括削除、保存期間設定の変更を別の操作として整理します。

特に出力権限は、画面上の閲覧より影響が大きくなる場合があります。CSVを個人端末へ保存したりメールへ添付したりすると、製品側の削除設定では消去できません。出力先を承認済みの保管場所に限定し、ファイル名、出力者、対象期間、利用終了日、削除確認者を記録します。

権限付与、異動・退職、委託終了、緊急時の剥奪、定期的な棚卸しまでの詳細は、チャットボットのアクセス権限設計で確認できます。ログの保持を設計する段階では、少なくとも保持設定の変更者と削除の承認者を、日常的に全文を閲覧する担当者から分けられるか確認します。

委託契約・製品仕様で確認する項目

自社の保持台帳を作成したら、製品提供者や委託先へ具体的に質問します。「セキュリティ対策をしていますか」という広い聞き方ではなく、データの種類、期限、担当範囲を指定してください。ヘルプページだけで判断せず、契約書、利用規約、仕様書、データ処理に関する条項のうち、どれが優先されるかも確認します。

佐渡市の移住相談AIチャットボット導入・保守管理業務 仕様書では、情報セキュリティに関する要件として、資料・ログ等へのアクセス制御、データ保管場所の明示、業務終了後の返却・消去・抹消その他復元不能な措置が記載されています。松戸市の生成AI 総合案内チャットボット利用規約では、入力内容・ログの保存と期間経過後の削除に関する条項、および委託事業者等による目的外利用の防止と安全管理措置に関する条項を確認できます。いずれも資料名を版の識別情報とし、2026年9月15日に公開PDFの該当条項を確認しました。

これらは各自治体の業務要件であり、同じ文言や期間が民間企業にも義務付けられるわけではありません。ただし、保存期間を契約条件へ落とし込む際の確認観点として、次の質問に応用できます。

契約条件を整理する順序については、チャットボットのSLA・契約確認ガイドも参考になります。保持期間の要件は可用性やサポート時間と分けて記載しつつ、障害調査に必要なログがサポートの受付時点まで残るかを照合します。

契約終了時は返却と消去を一つの手順にする

導入時に保存期間を確認していても、解約や委託終了時の作業が抜けることがあります。契約終了日に突然ログへアクセスできなくなると、必要な対応履歴や監査証跡を受け取れません。終了通知から逆算し、残す必要があるデータを誰が判断し、どの形式で、いつまでに受領するかを決めます。

返却されたデータにも、新たな保存期限を設定します。「退避」という名目で共有フォルダへ無期限に残さず、移行先、利用目的、閲覧者、削除日を記録してください。新しい製品へ移す場合は、全文を移行する必要があるのか、未完了案件と必要な監査証跡だけで足りるのかを確認します。

提供者側では、主系データ、バックアップ、再委託先、サポート用に取得したファイルが消去対象に含まれるかを確認します。法的義務や紛争対応などに伴う例外がある場合は、対象範囲、利用制限、消去予定、通知方法を合意します。「契約終了後に適切に削除する」という一文だけで終わらせず、消去期限と確認方法まで具体化することが重要です。

導入前に削除と出力をテストする

文書上の要件がそろっても、実際の画面や出力結果が想定どおりとは限りません。本番データを登録する前に、個人情報を含まないテスト会話を用意し、閲覧、出力、削除、権限拒否の動作を確認します。

1. テスト用の会話本文、添付ファイル、評価、エラーを登録し、保存先とIDを記録する。
2. 一般担当、品質担当、管理者など役割別のアカウントで、見える範囲を確認する。
3. CSV等を出力し、対象項目、期間、文字化け、削除済みデータの混入を確認する。
4. 個別会話を削除し、一覧、検索、集計、添付、外部連携先での状態を確認する。
5. 権限のない利用者が直接URLや出力操作からデータへ到達できないか試す。
6. 処理日時、実施者、結果、想定との差、提供者の回答をテスト記録へ残す。

バックアップからの消去は、その場で目視できない場合があります。その場合は、世代管理、上書き周期、復元時の扱い、削除済みデータが復元された場合の再削除手順を提供者へ確認します。確認できなかった項目を「問題なし」とせず、未確認事項として記録し、代替策も決めてください。

保存期間の満了による自動削除も、設定画面を確認しただけで完了と判断できません。テスト環境で短い期間を設定できる場合は期限後の状態を確認します。設定できない場合は、提供者の仕様書と処理記録を確認する方法を合意します。

保存期間は定期・臨時の両方で見直す

保持台帳は、導入時に作成して終わりではありません。定期見直しでは、ログが記載した目的に沿って利用されているか、期限切れのデータが残っていないか、閲覧者や出力先が増えていないかを確認します。半年や年次などの確認周期は、業務の変化と情報漏えい時の影響を考慮して決めます。

臨時見直しの契機には、入力項目の追加、新しい部署・店舗への展開、CRM等との外部連携、生成AI提供者の変更、保存仕様の改定、インシデント、委託先の変更があります。チャットボットの用途が一般案内から個別相談へ広がれば、保存期間が同じでも、取り扱う情報の性質と漏えい時の影響は変わります。

見直しでは、期間を延ばす判断だけでなく、短縮する判断についても根拠を記録します。分析に使っていない会話本文、削除期限のない出力ファイル、退職者が閲覧できる保管先が見つかった場合は、原因と是正期限を決めます。反対に、障害調査に必要なログが早く消えていた場合は、調査に必要な最小限の項目だけ期間を延ばせないか検討します。

チャットボットのログ保存期間を決めるチェックリスト

• ログを会話本文、添付、評価、実行、監査、出力、バックアップに分けた
• 各データの利用目的と、目的を実行する担当者を書いた
• 業務周期と事故検知までの時間から必要な遡及期間を決めた
• 起算日、即時参照期間、総保存期間、削除処理日を分けた
• 画面非表示、主系削除、派生データ、バックアップの期限を確認した
• 例外保全の理由、承認者、閲覧者、解除条件、見直し日を決めた
• 全文閲覧、出力、削除、保持設定変更の権限を分けた
• 出力ファイルの保管先と削除責任者を決めた
• 委託先・再委託先の保存場所、目的外利用、アクセス条件を確認した
• 契約終了時の返却形式、消去期限、確認方法を合意した
• テストデータで閲覧、出力、削除、権限拒否を確認した
• 根拠資料の版、確認日、次回見直し日を保持台帳へ記録した

すべてを一度に決めることが難しい場合は、個人情報を含む可能性がある会話本文、製品外へ持ち出せるCSV、保持設定を変更できる管理者権限から確認します。その後、実行ログやバックアップまで対象を広げると、影響の大きい項目を優先して確認できます。

保存期間は「何年」より削除後まで説明できることが重要

チャットボットのログ保存期間は、ログ種別ごとの目的と必要な遡及期間を基に決め、判断根拠と削除完了条件を保持台帳へ記録します。重要なのは、年数そのものではなく、自社要件と製品仕様の差を確認できる状態にすることです。

製品の標準期間が自社要件と合わない場合は、まず設定変更の可否を確認します。調整できなければ、必要最小限の出力や削除確認などの運用変更で補えるかを評価し、負担やリスクを許容できない場合は製品選定を見直してください。

チャットボットのログ保存期間に関するよくある質問

関連記事

• チャットボットの会話ログ分析方法：保存したログを未回答の分類やFAQ改善へ使う手順を確認できます。
• チャットボット監査ログの設計：設定・権限変更の証跡に必要な記録項目を整理できます。
• チャットボットのアクセス権限設計：権限付与、異動時の変更、緊急剥奪、定期棚卸しの手順を確認できます。
• AIチャットボットで個人情報を扱う際の考え方：会話ログへ含める情報と入力時の案内を整理する際に役立ちます。
• チャットボットのSLA・契約確認ガイド：ログ保持条件を委託範囲や障害調査など契約全体と照合できます。