内部統制の予備調査や税務調査の場面で、「業務のどの工程でAIを使いましたか」「その時のやり取りは残っていますか」と尋ねられる場面が、少しずつ増えてきているようです。スタッフの方の個人アカウントに散らばった会話履歴を、一件ずつスクリーンショットで提出する形をとっている事務所もありますが、提出する側にとっても受け取る側にとっても、後から検証しづらい運用になりがちです。
業務の一部にAIを入れる場面では、「誰が・いつ・どんな入力で・どんな出力を得たか」を後から振り返れる状態を作っておくと、調査や監査の場面で説明しやすくなります。これはAIに固有の話というよりは、業務上の重要な操作の記録を残す既存の流れを、AIを使う場面にも当てはめておく、という整理に近いです。
AIを使った場面で記録を残すこと自体については、関連記事「AI利用ログを残すべき理由」で扱っています。本稿はそこから一歩進めて、「実際にどう残すか」を、具体的なツールや運用パターンに沿ってご紹介します。
記録として残しておきたい4つの要素
「ログを取る」という言葉でも、取り方によって後から使えるかどうかが変わってきます。実務で見ていると、次の4つがそろっていないと、後追いでの説明が難しくなる場面が出てきます。
- 入力プロンプト (システムプロンプト・ユーザープロンプト・添付ファイル名)
- 出力 (モデル名・パラメータ・生成テキスト)
- 操作者 (どのアカウントから・どの端末から)
- 時刻 (生成時刻・利用したセッションID)
成果物に取り込んだ場合は、「どの案件・どの成果物に紐づいたか」も一緒に残しておくと、「この記述の根拠は何か」を後で逆引きしやすくなります。逆に、このうちのどれかが欠けると、たとえば「出力はあるけれどプロンプトが残っていない」「プロンプトはあるけれど誰が打ったか分からない」という状態になり、調査の現場では「ログが残っている」とは扱われにくいことがあります。
法人プランで標準的に取れる記録
主要なAIサービスの法人プランでは、管理者の方が触れる監査機能が整備されてきています。詳細は各社の最新仕様に依存しますが、2026-08-18確認時点で公式情報から確認できる範囲では、次のような形になっています。
Anthropic Claude Enterpriseでは、公式の料金ページでSSO・SCIM・ロールベース権限・Audit logs・Compliance API・データ保持コントロール・利用分析 (Usage analytics) といった管理機能が列挙されています (Anthropic, Claude Enterprise pricing)。HIPAA対応のオファリングも提供されていると記載があります。
OpenAI ChatGPT Enterpriseでは、Trust Portalで「Audit Logging」が製品セキュリティ機能として明示されていて、SOC 2 Type 2 (2025年1〜6月期)・ISO/IEC 27001:2022等の認証が維持されていると公表されています (OpenAI, trust.openai.com)。
注意したいのは、法人プランを契約しただけで、自動的に監査の要件が満たされるわけではない点です。プランで「取れる」ことと、事務所として「実際に取って、保管して、必要なときに提出できる」ことの間には、運用設計の工程があります。誰がAdmin Consoleにアクセスするか、Audit logs / Compliance APIを月次でエクスポートするか、エクスポート先のストレージは誰がアクセスできるか、といった事務所内ルールを別途決めておく必要があります。
自作ロギングを組み合わせる場合のパターン
法人プランの監査ログだけでは粒度が足りない場面や、複数のAIサービスを横断してログを取りたい場面では、自作のロギング基盤を併用する選択肢もあります。実装の形は大きく3つに分けて見ることができます。
| パターン | 利用者の摩擦 | ログ網羅性 | 導入・運用コスト | 退職者対応 |
|---|---|---|---|---|
| APIプロキシ型 | 大 (UI変更) | 高 (全APIを補足) | 中〜高 | しやすい (アカウント側で遮断) |
| ラッパー UI型 | 中 (専用UI) | 高 (業務文脈も付与) | 高 (UI開発) | しやすい |
| ブラウザ拡張型 | 小 (既存UI継続) | 中 (端末依存) | 中 | 難しい (端末側に依存) |
APIプロキシ型
スタッフの方がAIサービスのUIではなく、事務所内に立てたプロキシ経由でAPIを呼ぶ構成です。プロキシ側で全てのリクエスト・レスポンスを記録できるため、先ほどの4要素を確実に押さえやすい形になります。一方で、利用者にとっては「いつものChatGPTが使えない」摩擦が出てきます。LLM Gatewayと呼ばれる種類のOSSや商用製品も登場していて、選択肢は少しずつ増えてきています。
ラッパー UI型
事務所内向けに専用のチャットUIを用意して、スタッフの方はそちらから操作する形です。UI側のデータベースに会話を保存するため、案件番号やクライアントタグを必須項目にできるなど、業務の文脈を一緒に残せる利点があります。一方で、UIの開発・運用コストが乗ってきます。
ブラウザ拡張型
各スタッフの方のブラウザに拡張機能を入れて、ChatGPT等の画面操作をキャプチャして事務所のログ基盤に飛ばす形です。導入の摩擦は小さくなる一方で、スタッフの方のプライベート利用との分離や、端末ごとの管理が難しくなりやすく、退職時の対応も込み入ってきます。
どのパターンも一長一短で、事務所の規模・扱う情報の機微度・既存の業務システムによって、なじむ形が変わってきます。特に小規模の事務所が最初からプロキシ型を自作するのは費用対効果が合いにくい場面が多く、まずは法人プランの監査ログと手動運用を起点に考える形になっている事務所もあります。
保存期間・暗号化・改ざん防止
ログを残すと決めた時点で、ログ自体が個人情報・守秘義務情報の塊になります。設計の段階で詰めておきたい論点が、いくつかあります。
- 保存期間 (案件ごとの法定保存期間 — 税理士法・行政書士法・弁護士法等で求められる帳簿・関係書類の保存期間 — と揃えるか、AIログ独自の期間にするか)
- 暗号化 (保管時at-restと転送時in-transitの暗号化方式、鍵管理の責任者、鍵ローテーションの頻度)
- 改ざん防止 (WORMストレージや、ログのハッシュ値を別系統に記録する仕組み)
- アクセス制御 (ログ閲覧権限を持つ方の最小化、ログ閲覧自体がさらにログ化されているか)
- 削除運用 (保存期間経過後の削除手順と、削除した事実の記録の保持)
「とりあえずスプレッドシートに貼る」運用は入り口としては機能しますが、改ざん検知・アクセス権・退職者対応まで踏まえると、長期の運用には少し厳しくなる場面が出てきやすいです。
取り出し方 (CSV / JSONエクスポート)
ログは「取れている」だけでは使いどころが限られます。必要なときに、特定の期間・特定の方・特定の案件で抽出できる状態になっていないと、調査の現場では機能しづらくなります。設計の段階で確認しておきたい点をいくつか挙げます。
- 法人プランのAudit logs / Compliance APIが対応しているエクスポート形式 (CSV / JSON / SIEM連携)
- エクスポートの頻度・自動化 (月次バッチ・SIEMへの逐次連携)
- 抽出キー (ユーザー単位・期間単位・キーワード単位) の網羅性
- エクスポートしたファイルの保管先・暗号化・改ざん防止
「2025年10月の特定スタッフのプロンプト一覧をすぐに出せるか」が、実務的な目安になることがあります。出せない場合は、ログ基盤の設計の側に見直しの余地が残っている可能性があります。
既存の統制との接続
監査証跡の設計は、既存の情報セキュリティ管理の枠組みとの接続を意識しておくと、内部統制ドキュメントを書くときの手戻りが減りやすくなります。
- ISO/IEC 27001 (情報セキュリティマネジメントシステム) はイベントログの取得・保護・レビューの一般的な要求事項を置いています
- NIST SP 800-53 AU系統制 (Audit and Accountability) はAU-2「Event Logging」をはじめ、組織として監査対象イベントを定義・レビューすることを求める統制群です
国内では、個人情報保護委員会が2023年6月2日に発出した「生成AIサービスの利用に関する注意喚起等について」が、生成AIを業務で使う場面の個人情報取扱いの出発点としてよく参照されます。経済産業省・総務省の「AI事業者ガイドライン」も、透明性・アカウンタビリティ・トレーサビリティに関連する観点を扱っていて、内部統制ドキュメントの参照元として置いておきやすい形になっています。
抜けやすい場面
監査証跡の設計で、後から問題になりやすい場面をいくつか並べておきます。
- 法人プランを契約したことで安心してしまう場面 (Audit logs / Compliance APIを月次でレビューする担当が決まっていないと、ログは取れているだけで形骸化しやすくなります)
- 個人アカウントの並行利用が止まらない場面 (シャドー AIで個人ChatGPTを使い続けているスタッフの方がいると、組織側のログには現れない経路が残り続けます)
- 退職者ログの扱いが決まっていない場面 (退職した方が残したログを凍結するのか、引き継ぎ用に閲覧可能にしておくのか、削除するのか、方針が決まらずに置かれやすくなります)
- ログ閲覧自体のログがない場面 (監査ログを閲覧できる管理者の操作履歴を取っていないと、内部統制上の二重統制が成立しにくくなります)
- 特定期間・特定スタッフでの抽出を試したことがない場面 (必要なときに5分で出せるかどうかは、平時に一度試しておかないと確認できません)
監査証跡は「取れている」と「取り出せて、改ざんを検知できる」の間に、運用設計の差があります。最初から完璧を目指すよりも、いまの運用でどの要素がどこで欠けているかの棚卸しから始めるほうが、判断のブレが減る出発点になりやすいです。
関連記事
- AI利用ログを残すべき理由
参考
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」 (2023年6月2日発出): https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- 経済産業省・総務省「AI事業者ガイドライン」関連ページ: https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
- Anthropic「Claude Enterprise pricing」 (Audit logs / Compliance API / SSO / SCIM / HIPAA-ready等の管理機能を列挙): https://claude.com/pricing/enterprise
- OpenAI Trust Portal (ChatGPT EnterpriseのAudit Logging / SOC 2 Type 2 / ISO/IEC 27001:2022等): https://trust.openai.com/