AIとの会話はどこまで残すべきか――業務ログの保存設計

たとえば、社内の生成AIが作った要約に誤りが見つかり、運用担当者が調査を依頼される場面を考えます。会話を残していなければ、何を入力したのか分かりません。一方、入力も出力も共通のログへ保存していたなら、相談内容や添付資料を誰が読める状態なのか、別の確認が必要になります。

本稿は、通常の運用記録と、内容を詳しく調べるための記録を分ける設計を勧めます。まず、どの問い合わせに答えるために何を残すのかを決めます。そのうえで、本文が必要な調査に限り、対象・閲覧者・保存期限を絞って扱う方針です。

利用環境の整備と、会話の保存は別の判断です

国内でも、社内利用と情報管理を併せて進める取り組みがあります。LINEヤフーは、社内専用の対話型AIアシスタントなどを業務で利用し、AIの活用可否を法務、プライバシー、セキュリティ、知財などの部門が連携して判断すると説明しています。[1]

この事例を、同社が本稿のログ設計を採っている根拠としては扱いません。自社で考えたいのは、AIを利用してよいという判断に、入力や出力を別の場所へ保存してよいという判断まで含めていないか、という点です。利用環境の承認とは別に、ログの収集先と閲覧者を確認してください。

保存方法には、会話を残さない、全会話を残す、通常記録と調査用記録を分ける、という選択肢があります。会話を残さない案では、過去の出力内容を検証する手掛かりを別に用意する必要があります。全会話を残す案を採るなら、記録する量と機密性に見合う管理が前提です。調査の必要性が案件ごとに異なる業務には、第三の案が妥当だと考えます。

調査したい問いから、通常記録の項目を決める

最初に、運用担当へ寄せられる問い合わせを想定してください。「処理が失敗した」「返答が遅い」「内容が不適切だった」では、必要な材料が異なります。本稿では、前二者は処理の経過を追う記録、最後は内容を確認する記録として設計を分けます。

通常記録の候補は、処理を結び付ける識別子、実行時刻、利用部門、モデルとアプリケーションの版、処理時間、成否、エラーの種類です。氏名やメールアドレスを識別子の代わりに入れず、調査に必要なときにだけ別の管理先で対応を確認する方法を検討します。識別子に置き換えた情報も、無条件に公開できる扱いにはしません。

製品が何を記録するかも、項目ごとに確かめます。Amazon Bedrockのモデル呼び出しログは初期状態では無効で、有効にすると対応する呼び出しの要求・応答データやメタデータを収集できます。保存先としてCloudWatch LogsとAmazon S3を指定できると公式文書に記載されています。[2]

したがって、ログ機能を有効にする前に、実際に出力される一件を検査するべきです。「利用量を把握したい」という目的なら、会話本文まで含む設定が必要かを問い直します。入力本文を省く設計でも、エラー詳細や文書名に相談内容が入り込まないか、テストで確認しましょう。

文書検索を伴うAIでは、本文の代わりに参照文書の識別子と版を残す案もあります。ただし、文書名や識別子自体に案件名が含まれるなら、その値も保存範囲の検討対象です。情報の置き換えだけで検討を終えず、誰が元の情報へたどれるかまで一覧にします。

マスキングで隠すことと、保存しないことを分ける

OWASPのログ設計ガイドは、アクセストークン、認証パスワード、機微な個人情報などを、通常はログへ直接記録せず、除去やマスキングなどの処理を行う対象として挙げています。[3]

ただし、マスキングという名前の機能が、元の値を消すとは限りません。CloudWatch Logsのデータ保護機能では、選んだ識別子に合致する情報を表示時などに隠しますが、マスキングを解除する権限を持つ利用者は、元のデータを閲覧できます。また、保護ポリシーの設定前に取り込まれたログはマスキングされません。[4]

この仕様からも、収集前に不要な情報を取り除く処理と、収集後の閲覧を制御する処理は、別々に確認する必要があります。たとえば、顧客名を削った要約だけを保存する場面では、削る前の本文がアプリケーションの例外ログへ出ていないかも試験対象にします。

試験には、実在しない氏名や架空の案件情報を含む入力を用意します。正常終了だけでなく、入力形式の不備、外部サービスの失敗、処理の中断も起こし、収集先を順に調べてください。確認結果は「対策済み」の一語で済ませず、どの入力がどの保存先に残ったかを記録します。

詳細な本文は、調査案件にひも付けて扱う

内容に問題があるときは、本文なしでは調べきれない場合を受け入れなければなりません。記録を減らす設計には、過去のやり取りを完全には検証できないという代償があります。調査依頼を受けてから詳細記録を有効にしても、保存していなかった過去の本文は取り戻せません。

そのため、調査用の記録を開始する手順を、通常運用の前に決めておきます。対象業務、調査する問い、必要な入力と出力、閲覧担当者、開始と終了の条件を一件の調査票へまとめます。利用者から過去の会話を提供してもらう案も含め、取り扱える情報の範囲を業務側と確認してください。

調査用の本文を通常のログと分けて保管し、共通の識別子で対応を付ける方法が考えられます。運用担当は通常記録から対象を絞り、内容を調べる担当だけが本文へ進む分担です。問い合わせ票やチャットへ全文を貼り付ける運用まで許してしまわないよう、共有方法も指定します。

全件保存には管理負担がある一方、限定した記録には選び漏れが伴います。一定の割合で会話を抽出する方法も、必要な事象が必ず含まれる保証にはなりません。出力の逐語的な説明が欠かせない業務では、後から対象を絞る方針だけでは不足します。必要な記録を継続して保存する案も、閲覧の制限や保管費用と併せて比較すべきです。

保存期限は、コピー先まで含めて確かめる

保存期間を決めるときは、通常記録と調査用本文を同じ期限にそろえる必要はありません。問い合わせが届くまでの期間、業務上の確認期間、調査の継続状況を踏まえ、目的ごとに決めることを勧めます。業種を問わず使える日数を一律に置くのは避けましょう。

OWASPのガイドは、ログ本体だけでなく、一時的なデバッグログ、バックアップ、コピー、抽出物も、必要な保存期間の管理対象としています。[3]

実装時には、主要な保存先だけでなく、監視サービスへの転送、調査担当のダウンロード、検証環境への複製も一覧にします。期限を設定した後は、架空の入力を使い、期限後にどこへアクセスできなくなるか、残る複製は何かを確認してください。調査のために保存を延長する場合も、判断者、理由、次の見直し日を残します。

適用範囲を決めてから運用へ渡す

すべてのやり取りを原文のまま保存する要件があり、本文の収集を限定できないという場合には向きません。その場合は要件を優先し、本文を保持する前提で、閲覧・複製・廃棄の管理を設計します。反対に、公開情報だけを使う短期の試作なら、二種類の保管基盤まで作る前に、調査の必要性と運用費を比較してください。

顧客と企画から試作、実装、定着まで進めるForward Deployed Engineering（FDE）の進め方を採るなら、ログの仕様も引き継ぎ成果物に含めるべきです。項目名だけでなく、調べられる問いと調べられない問い、本文を収集する条件、削除を確認する担当を、業務側と開発側で合意します。

実務への示唆

提言1：ログを有効にする前に、調査目的と保存項目を対応させてください。 各項目の用途を説明できなければ、収集の必要性を再検討します。

提言2：通常記録と調査用本文を分け、収集から共有までを試験してください。 表示上のマスキングだけで判断せず、元の値が残る場所と閲覧できる人を確かめます。

提言3：保存を減らした結果、調べられない範囲も運用へ渡してください。 調査の限界、詳細記録を開始する手順、複製を含む保存期限を、担当者が判断できる形で残します。

参考資料

1. LINEヤフー「責任あるAIへの取り組み」（公開・更新日不明、現行HTML、確認日：2026-09-23）
2. AWS, Monitor model invocation using CloudWatch Logs and Amazon S3（公開・更新日不明、現行HTML、確認日：2026-09-23）
3. OWASP, Logging Cheat Sheet（公開・更新日不明、現行HTML、確認日：2026-09-23）
4. AWS, Help protect sensitive log data with masking（公開・更新日不明、現行HTML、確認日：2026-09-23）

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-09-23。