結論: AI利用ログは「使ったかどうか」ではなく「後から誰が何をどう使ったかを再現できるか」を担保するための業務記録です。
AI利用ログがないと何が困るのか
所内のスタッフが顧問先からの問い合わせを生成AIで下書きして送信し、後から顧問先に「回答の根拠」を確認された場合を想定してみます。誰がどのモデルにどんなプロンプトで作らせたかを、所として一元的に追える形で残していなければ、その場で説明できません。プロンプトの履歴が各人のアカウント側に散らばったままだと、後から集めようとしても収集自体が困難になります。
この構造は税務シミュレーション、契約レビュー、申請書のドラフト作成など、士業の日常業務の各所に潜んでいます。AIの出力をそのまま顧客成果物に反映している場合、「何を根拠にこの数字を出したのか」「どこで誤りが混入したのか」を後から再現できないと、説明責任の場面で詰まりやすいと考えられます。
論点は「AIを使ったこと」ではなく、「AIを使った痕跡が再現可能な形で残っていないこと」のほうにあります。
ログ不在の運用が招く再現性の喪失
ログ運用の不在は、現場で次のような形で表面化する傾向があります。
- 個々のスタッフが個人アカウントのChatGPTなどを業務利用し、履歴は個人のブラウザ側にしか残らない
- 「履歴を共有ドライブに保存する」という運用ルールを決めていても、保存の徹底状況や改変の有無を後から検知する仕組みは、多くの場合セットになっていません
- 顧客名や案件番号をプロンプトに直書きしているものの、誰がいつ何を入力したかの記録が事務所側にない
- 出力を成果物に取り込んだ後、元のプロンプトと出力をクリアしてしまう
個別には小さなショートカットですが、まとめると「問題が起きたときに何が起きたかを再現できない」状態が成立してしまいます。士業の場合、説明責任の向き先は依頼者だけでなく、監督官庁・税務調査・訴訟など複数方向に分岐しうるところが厄介です。再現性の欠落は、修正コストの大きい設計上の見直し対象になります。
AI利用ログが必要になる4つの場面
AI利用ログ(プロンプト・モデル・パラメータ・出力・操作者・時刻のセット)の価値は、平時にはほとんど見えません。何かが起きたときに初めて、次の4つの場面で仕事をします。
- 説明責任: 顧客や監督機関から「どのように結論に至ったか」を問われたとき、根拠を時系列で示せます
- 監査: 内部監査・第三者監査において、AI利用が業務ルール(守秘義務・個人情報・利益相反)に沿っていたかを点検できます
- 再現と原因究明: 誤情報・情報漏えい・誤送信が起きたとき、原因となったプロンプトと条件を特定できます
- 学習資料: 良いプロンプト・避けるべきプロンプトを所内で共有し、品質を底上げできます
逆に、この4つをいずれも捨ててよい業務であればログは不要となります。士業実務で4つともゼロにできる場面は、観察上は少ないと考えられます。
AI利用ログと既存の法令・ガイドラインの関係
日本国内の文脈では、個人情報保護委員会が2023年6月に発出した生成AI利用に関する注意喚起が、出発点としてよく参照されています。同注意喚起では、個人情報取扱事業者が生成AIにプロンプトとして個人情報を入力する場合の留意点や、利用目的の範囲を超えた取扱いをしないことが整理されています。
経済産業省・総務省が2026年3月に公表した「AI事業者ガイドライン」(第1.2版)は、この点をより具体的に示しています。共通指針の「透明性」の項目では、AIシステム・サービスの開発過程や利用時の入出力等について、データ量・データ内容に照らして合理的な範囲でログを記録・保存することを求めています。「アカウンタビリティ」の項目でも、開発・提供・利用の各段階について追跡・遡及が可能な状態を確保するトレーサビリティの確保が挙げられています。士業事務所のように「AI利用者」としてAIを業務に組み込む立場でも、この延長線上でログ管理体制を整えることが期待される内容です。ただし同ガイドラインは法的拘束力を持たないソフトローであり、罰則を伴う義務ではない点には留意が必要です。
国際的な情報セキュリティ管理規格との関係でも、ISO/IEC 27001:2022附属書Aの管理策8.15(ログ取得)、米国NIST SP 800-53 Rev.5のAU系統制(AU-2イベントロギング等)は、「重要な業務操作のログを取り、保護し、見直す」という考え方を共有しています。AI利用も業務操作のひとつである以上、この延長線上で扱うのが実務的だと考えられます。
ログをどう設計するか — 法人プランか、自作ロギングか
主要な生成AIサービスは、個人向けプランと法人向けプランで、管理者が触れるログの粒度が大きく異なります。個人向けプランで残るのは「ログインしたアカウント自身の会話履歴」だけで、所属組織の管理者が横断的に取得・監査する機能は提供されない傾向がある一方、法人向けプランでは監査ログ・データ保持コントロール・利用分析といった機能が用意されているケースが多くなっています(共有IDでこの断絶がどう表面化するかは、共有IDが危険な理由という記事で別途詳しく扱っています)。
法人プランの監査ログだけで自所の要件を満たせない場合は、自作ロギングを併用する選択肢もあります。API経由でAIを呼び出して業務システム側にプロンプトと応答を保存する方式、社内チャットUIを用意してユーザー操作ごとにDBに保存する方式、既存の業務システムにAI呼び出しを組み込む方式などが候補です。ただし、ログ自体が個人情報・守秘義務情報の塊になるため、保管場所・暗号化・アクセス権の設計が前提となります。「全部のプロンプトを永久保存」は実務的に成り立たず、保存期間ポリシーの設計が必要です。法人プランの監査ログと併存する場合は、どちらを正本とするかをあらかじめ決めておかないと、調査時に齟齬が出やすくなります。
「いつまで・どこに・誰がアクセスできるか」を決め切る
ログを取ると決めたら、次に決めるべきは保存期間・暗号化・アクセス権です。最低限、次の論点を所として合意しておくと、運用上の判断ブレが減らせます。
- 保存期間: 案件ごとの法定保存期間(税務関係書類なら原則7年等)に揃えるか、AIログ独自のポリシーにするか
- 暗号化: 保管時(at-rest)と転送時(in-transit)の暗号化の有無、鍵管理の責任者
- アクセス権: 誰がログを閲覧できるか、ログ閲覧自体がさらにログ化されているか
- 退職者対応: 退職者のアカウントで残ったログをどう扱うか(凍結 / 引継ぎ / 削除)
- 顧客への説明: ログを取っていること自体を顧客にどう開示するか(契約・プライバシーポリシー上の整理)
ここを曖昧にしたままログだけ集めると、「ログがあるから安全」ではなく「ログがあるから漏えい時の被害が大きい」状態に振れてしまいます。集めること自体より、運用設計のほうが先に来ると考えるのが現実的です。
事務所間で広がりつつある差
ガートナージャパンが2026年6月に公表した国内企業向け調査では、組織内の生成AI利用実態を「把握できていない」と回答した企業が43%、「把握しているが有効な対策を取れていない」が30%で、合計73%が実質的に利用実態を管理できていません。「把握し、有効な対策を取れている」と回答した企業はわずか24%にとどまります(業種は士業に限定されていません、出典)。ログ・監査証跡の有無は、この「把握できているかどうか」の土台にあたる部分です。士業に限定した同種の統計は現時点で見当たりませんが、一般企業でこの水準であれば、士業事務所でも同様かそれ以上にログ整備が後回しになっている事務所と、法人プランやAPIベースの記録基盤に早期に乗せ替えた事務所とで、差が広がっている可能性は十分に考えられます。
短期では生産性に差は出にくいものの、インシデント対応・監査対応・新人引き継ぎといった「後から見返す場面」で差が顕在化すると考えられます。AI利用ログは、事故が起きてから慌てて整えるものではなく、業務に組み込む前から再現性を確保しておくための設計対象として位置付け直すと、後からの手戻りを小さくできます。
押さえておきたいポイント
AI利用ログの保存は法律で義務付けられていますか。
AI利用ログそのものを一律に義務付ける法律は、現時点では日本国内に存在しません。ただし税務関係書類の法定保存期間や、個人情報保護法上の安全管理措置義務、業界ごとの監督官庁のガイドラインを経由して、実質的にログの保存・管理が求められる場面があります。個人情報保護委員会の注意喚起やAI事業者ガイドラインも、直接ログ保存を義務付けるものではなく、透明性・アカウンタビリティの観点から「後から検証できる状態」を求める内容です。
AI利用ログはどのくらいの期間保存すればよいですか。
記事内で述べた通り、案件の法定保存期間(税務関係書類なら原則7年等)に揃える方法と、AIログ独自のポリシーを別に定める方法があります。どちらか一方が正解というより、所内でどちらを正本とするか、法人プランの監査ログと自作ロギングが併存する場合にどちらを優先するかを、事前に合意しておくことが重要です。
個人プランのままAI利用ログを残すことはできますか。
個人向けプランでは、管理者が組織横断でログを取得・監査する機能が提供されない傾向があります。個人の会話履歴として残るだけなので、所として説明責任を負う業務に組み込むなら、法人向けプランの監査ログ機能か、API経由で業務システム側にプロンプトと応答を保存する自作ロギングの併用を検討する余地があります。
ログを取得するとかえって情報漏えいリスクが増えませんか。
ログ自体が個人情報・守秘義務情報の塊になるため、保管場所・暗号化・アクセス権の設計を伴わないままログだけ集めると、記事内で触れた通り「ログがあるから安全」ではなく「ログがあるから漏えい時の被害が大きい」状態に振れます。保存期間・暗号化・アクセス権・退職者対応をセットで設計することが前提になります。
参考
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」(2023年6月2日発出) https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- 経済産業省・総務省「AI事業者ガイドライン」(Ver1.2、2026年3月31日公表) https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
- ISO/IEC 27001:2022附属書A管理策8.15(ログ取得)
- NIST SP 800-53 Rev.5「AU - Audit and Accountability」統制ファミリ
- ガートナージャパン「国内企業の『シャドーAI』対応における新たな指針を発表」(2026年6月18日公表) https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20260618-aibs-shadow-ai