社内RAGのログ監査｜本番運用で必要な設計ポイント
社内の規程や手順書、提案書、議事録、問い合わせ履歴などをもとに質問へ答えるRAG（検索拡張生成。文書を検索して、その内容を根拠に生成AI〈文章などを生成する人工知能〉が回答する仕組み）は、小さな検証の段階では、回答が正しいかどうかが最大の関心事になります。ところが、利用者が増えて本番運用に近づくと、別の問いが重くなってきます。「誰が、いつ、何を尋ね、システムは何を根拠にどう答えたのか。それを後から確かめられるか」という問いです。検証の段階では、開発者が画面を見ながら挙動を確認できるため、記録（ログ）の不足に気づきにくいのですが、実際に業務で使われ始めると、誤った回答の苦情、特定の文書が見えてしまったのではないかという懸念、費用が想定を超えた理由の説明、監査部門からの確認依頼といった場面が、ほぼ避けられない形で訪れます。そのとき、記録が残っていなければ、原因を調べることも、説明することもできません。
ログの設計が難しいのは、「たくさん残せば安心」とはいえないからです。RAGの質問と回答には、業務上の機密や個人に関する情報が含まれることがあり、記録を残すこと自体が、新しい情報の置き場所をつくることになります。しかも、そのログは、利用者が普段アクセスしない場所に蓄積されるため、元の文書の権限管理が働かない領域になりやすいという性質があります。つまり、ログは「問題を調べるための道具」であると同時に、「管理を誤ると問題の発生源になる資産」でもあります。残す範囲、伏せる範囲、見られる人、残す期間を、目的に照らして設計し、社内の規程として合意しておくことが、本番運用の前提になると考えられます。
もう一つの難しさは、ログの目的が一つではない点です。監査のための記録、障害調査のための記録、品質改善のための記録、費用を把握するための記録、インシデント（情報漏えいや不正利用などの事故）に対応するための記録は、似ているようでいて、求められる性質が異なります。監査では改ざんされないことと追跡できることが重んじられ、品質改善では分析しやすいことと十分な文脈が重んじられ、費用の把握では集計しやすいことが重んじられます。これらを一つの仕組みでまかなおうとすると、どれにも中途半端になりかねません。目的ごとに必要な項目と保管の方法を整理し、共通の土台の上で使い分ける設計が現実的です。
本記事では、社内RAGのログ監査について、本番運用で必要になる設計の観点を順に整理します。まず、ログの目的と、記録する項目の全体像を確認し、そのうえで、機微情報を含む質問や回答の扱い、監査ログに求められる要件、構造化ログとトレースID（一つの質問の処理を通して付ける識別子）による設計、保管・検索・分析の基盤、異常検知とアラート（異常を知らせる警告の通知）、インシデント時の追跡手順へと進みます。続いて、ログを品質改善とコストの可視化に活かす方法、利用者への透明性と社内規程、運用体制を扱い、最後に、ログ対応がRAG構築の費用にどう影響するかと、内製と外部支援の判断の観点を整理して、よくある質問とまとめで締めくくります。なお、本記事は一般的な考え方の整理であり、実際の判断では自社の情報管理規程、契約、関係部門の見解を優先してください。権限の設計、回答の誤りへの対策、評価の設計、ベクトルデータベース、検索精度といった隣り合うテーマは、それぞれ別の論点として扱うため、ここではログとの接点に限って触れます。
1. 社内RAGのログは、何のために残し、誰のために使うのか？
ログの目的は、監査、障害調査、品質改善、コスト把握、インシデント対応の五つに整理でき、目的によって必要な項目、保管の方法、読む人が異なるため、最初に目的を言葉にしておく必要があるからです。
図1：ログの五つの目的と読み手
ログという言葉は、広い意味で「システムが残す記録」を指しますが、RAGの運用に当てはめると、記録の対象は意外に多層です。利用者が入力した質問、システムが組み立てた検索の条件、検索で見つかった文書の断片、権限の判定結果、モデルに渡した指示文（プロンプト）、モデルが生成した回答、画面に表示した引用、利用者の反応、処理にかかった時間、消費した計算資源の量といった情報が、一つの質問の裏で次々に生まれます。これらをすべて残すのか、一部だけ残すのか、残す場合はどの粒度かという判断は、「何のために使うのか」が決まって初めて可能になります。目的が曖昧なまま「とりあえず全部残す」と決めると、保管費用と情報管理の負担が膨らみ、いざ必要な情報を探したいときには、量が多すぎて見つけられないという事態にもなりかねません。
逆に、目的を明確にしておけば、設計の判断を一貫させやすくなります。たとえば、情報漏えいの疑いが生じたときに「どの利用者に、どの文書の内容が、どの経路で提示されたか」を確認できる状態を目的にするなら、権限判定の結果と取得文書の識別子が欠かせません。誤った回答の原因を調べる目的であれば、モデルに渡した文脈と使ったプロンプトの版が必要になります。目的が設計を決め、設計が費用を決めるという順序で考えると、後の議論が整理しやすくなります。
1.1 ログがないと、本番運用で何ができなくなるのか
ログが不足している状態で本番運用を始めると、起きる問題は、単に「調べにくい」にとどまりません。まず、苦情への対応が成立しなくなります。利用者から「間違った回答が出た」と報告を受けても、その質問に対してシステムが何を検索し、何を根拠にしたのかが残っていなければ、再現を試みるしかありません。ところが、生成AIの回答は同じ質問でも毎回同じとは限らず、索引や文書も日々更新されるため、後から同じ条件を再現することは、一般に難しいとされています。その結果、原因が検索にあるのか、文書にあるのか、生成にあるのかを切り分けられず、対策も当て推量になります。
次に、説明責任が果たせなくなります。社内の監査部門や情報管理の部門から「この文書の内容を、権限のない人に答えていないと言えるか」と問われたとき、ログがなければ「設計上は大丈夫なはずです」としか答えられません。設計上の主張と、実際の動作の証拠は別物であり、後者を示せるのはログだけです。さらに、費用の面でも、利用量の記録がなければ、どの部門のどの用途で費用が増えているのかを把握できず、予算の見直しや課金の按分もできません。こうした問題は、利用者が少ない間は目立ちませんが、利用が広がるほど重くなるため、本番に移る前にログの設計を済ませておく意義があります。
1.2 五つの目的と、読み手の違い
五つの目的を、それぞれの読み手と合わせて整理すると、設計の方向が見えてきます。監査の目的では、読み手は監査部門、情報管理の責任者、場合によっては外部の監査人です。彼らが知りたいのは、統制が意図どおりに働いていたか、不正や誤用がなかったか、後から追跡できる状態が保たれていたかという点です。障害調査の目的では、読み手は運用担当者や開発者で、知りたいのは、いつ、どの部品で、なぜ失敗したかです。品質改善の目的では、読み手は文書の責任者や改善の担当者で、どの種類の質問が失敗しているか、どの文書が使われていないかといった傾向を知りたいと考えます。
コスト把握の目的では、読み手は運用の責任者や、予算を管理する部門です。どの用途がどれだけ資源を使っているかを知り、費用を配分したり、上限を設けたりする判断に使います。インシデント対応の目的では、読み手は初動の担当者と、情報管理の責任者です。事故の疑いが生じた時点で、影響範囲を短時間で絞り込み、証拠を保全し、報告に必要な事実を集めます。このように、読み手ごとに「知りたいこと」と「許される閲覧範囲」が異なるため、ログは一つの巨大な記録として全員に開くのではなく、目的に応じた見え方と権限を設計する必要があります。
図2：目的ごとの読み手と主な問い
上の図は、五つの目的に対して、主な読み手と、その読み手が問う内容を整理した例です。実際の組織では、一人が複数の役割を兼ねることもありますが、役割ごとに必要な情報と許される範囲を分けて考えておくと、閲覧の申請と承認の設計がしやすくなります。
1.3 目的が衝突する場面：残したい情報と、残したくない情報
目的を並べると、互いに引っ張り合う関係が見えてきます。品質改善と障害調査の観点では、質問の全文、モデルに渡した文脈、生成された回答の全文があると、原因の切り分けが格段にしやすくなります。一方、情報管理の観点では、質問や回答の全文には個人情報や機密が含まれうるため、残す量は少ないほうが望ましいと考えられます。この対立は、どちらかが正しいという性質のものではなく、リスクの大きさに応じて均衡点を決める問題です。
実務で選ばれることのある整理としては、通常の運用では識別子と判定結果などのメタ情報（本文以外の、識別子・時刻・件数などの付随情報）を中心に残し、本文はマスキング（一部を伏せる処理）を施したうえで限られた期間だけ残し、障害調査や監査で必要になった場合に限って、承認のもとで詳細を参照する、という段階的な設計があります。この考え方は後の節で詳しく扱います。ここで押さえておきたいのは、衝突を放置せず、設計の初期に関係者と合意しておくことです。情報管理の責任者、法務、人事、文書の責任者、運用の担当者が同じテーブルで、目的と制約を確認しておくと、後から「その情報は残してはいけなかった」「その情報が残っていなかった」といった食い違いを減らせます。
図3：ログの目的が引っ張り合う場面
1.4 本記事の範囲と、他の論点との接点
本記事は、ログと監査の設計に絞って論じます。権限をどう設計し、検索時にどう絞り込むかは別の論点であり、ここでは、権限判定の結果を「ログとして残す」側面だけを扱います。回答の誤りをどう減らすか、評価をどう設計するか、検索精度をどう高めるかも別の論点です。ログは、これらの活動のために必要な材料を提供する位置づけとして扱い、改善の具体的な手法には深入りしません。
また、本記事で扱う内容は、技術の選択肢の網羅ではありません。特定の製品や基盤を勧める趣旨ではなく、どのような目的のために、何を、どのような性質で残すべきかという設計の考え方を中心に整理します。保管期間や閲覧権限などの具体的な値は、法令、業界の指針、契約、社内規程によって異なるため、数値を示すことは避け、決め方の観点を提示するにとどめます。
2. 何を記録するのか？質問から回答までの記録項目の全体像
一つの質問が通る入力・検索・生成・結果の四つの段階ごとに、再現と説明に必要な項目を決めておくと、記録の抜けと過剰の両方を防ぎやすくなるからです。
図4：記録を考える四つの段階
RAGの一回の質問応答は、利用者から見ると「質問して、回答が返る」という単純な体験ですが、内部では複数の処理が連なっています。質問が受け付けられ、利用者が認証され、質問が検索に適した形に整えられ、検索が実行され、権限で絞り込まれ、残った断片が並べ替えられ、モデルに渡す文脈が組み立てられ、モデルが回答を生成し、引用が付けられ、画面に表示され、利用者が反応を返します。ログの設計とは、この連なりのうち、どこで何を記録しておけば、後から全体の流れを復元できるかを決める作業です。
記録の抜けが起きやすいのは、処理の途中で変換や絞り込みが行われる部分です。たとえば、利用者の元の質問と、検索に使われた変換後の質問が異なる場合、片方しか残っていなければ、検索が外れた原因を判断できません。また、権限で絞り込んだ結果、本来なら取得できたはずの文書が除外された場合、除外されたという事実が記録されていなければ、「見つからなかった」のか「見せなかった」のかを区別できません。このように、ログは「最終的に何が起きたか」だけでなく、「途中で何が変換され、何が除外されたか」を含むことで、はじめて切り分けに使えるようになります。
図5：一つの質問が通る段階と残したい記録
2.1 入力の段階：質問・利用者・状況
入力の段階で記録するのは、誰が、いつ、どの経路から、何を尋ねたかという情報です。具体的には、利用者を特定できる識別子、所属や役割などの属性、質問の本文、質問を受け付けた時刻、利用した画面や接続元の区別、会話のまとまりを示すセッションの識別子などです。ここで留意したいのは、利用者の識別子は、氏名そのものではなく、社内の別のシステムで氏名に対応づけられる識別子にしておくと、ログ単体では個人が特定されにくい構造にできる点です。必要なときだけ別の管理された表で対応づける設計は、閲覧権限の分離にもつながります。
質問の本文は、機微情報を含みやすい項目です。後の節で扱うように、本文を残すかどうか、残す場合にどの程度マスキングするか、どの期間残すかは、慎重な設計を要します。一方、質問の長さ、言語、質問の種類の分類などのメタ情報は、本文を残さなくても取れる項目であり、傾向の分析に使えます。入力の段階では、「本文そのもの」と「本文から導けるメタ情報」を分けて扱う発想が有効です。
2.2 検索の段階：検索クエリ・取得文書・権限判定結果
検索の段階は、ログの価値が最も高く、かつ最も記録が漏れやすい部分です。記録したい項目は、検索に実際に使われたクエリ（検索の問い合わせ文）、質問の書き換えや分解の結果、適用した絞り込みの条件、取得された文書とその断片の識別子、検索時のスコアと順位、再ランキング（候補の並べ替え）後の順位、権限判定の結果、そして最終的にモデルへ渡された断片の一覧です。ここで重要なのは、断片の本文そのものよりも、識別子を残すことです。本文は元の文書に存在しており、識別子と文書の版があれば、後から元の文書を参照して内容を確認できるからです。ただし、文書が更新や削除された後でも当時の内容を確認する必要があるかどうかは、監査の要件によって異なるため、版の保存方針とあわせて検討する必要があります。
権限判定の結果は、監査の観点で特に大切です。「この利用者の権限で、この文書は取得可能と判定された」「この文書は権限により除外された」という事実と、判定に使った根拠（所属、役割、機密区分、案件など）を、判定を行った時点の状態として残しておきます。権限は日々変わるため、後から現在の権限で再計算しても、当時の判定を再現できないことがあります。したがって、判定の結果と、その時点で参照した属性の版を記録しておくことが、追跡可能性の観点で重要になります。なお、RBAC（ロールベースアクセス制御。役割に権限を結びつける方式）やABAC（属性ベースアクセス制御。属性の組み合わせで判定する方式）の違いを整理したアクセス制御モデルの比較記事では、ABACは判定の理由を説明するために、方針の設計、ログ、テスト、可視化が必要になること、導入前に監査ログと例外処理の規則を用意しておく必要があることが述べられています。判定の理由を後から説明できるようにすることは、ログ設計の中心的な要件の一つといえます。
2.3 生成の段階：プロンプト・モデル・版・回答・引用
生成の段階では、モデルに何を渡し、何が返ってきたかを記録します。具体的には、使ったプロンプトの版、システムが付け加えた指示、モデルの名称と版、生成の設定、モデルに渡した文脈の構成、生成された回答、回答に付けられた引用、そして生成後の検証の結果です。たとえばWebアプリとAIの統合設計を扱ったSYPの記事では、監査ログとして、誰がどのデータを使い、どの出力が生成され、いつ利用者に表示されたかを追えるようにすること、モデルとプロンプトの版、参照した文書、検証の結果を記録すること、そして、記録は機密区分に応じて保存先、アクセス権、保持期間を定めることが示されています。これは、RAGのログ設計の出発点として参考にしやすい整理です。
版の記録は、地味ですが重要です。プロンプトやモデルは、改善のために頻繁に変更されます。品質が急に変化したとき、どの変更が原因かを遡るには、各回答がどの版の組み合わせで生成されたかが分かる必要があります。版が記録されていなければ、変更の影響を後から検証することができません。また、回答に付けた引用は、「システムが根拠として示したもの」の記録であり、利用者がそれを根拠に判断した場合の説明責任にもかかわります。引用が実在し、取得された断片に含まれていたかを確認した結果も、あわせて残しておくと、後の検証に役立ちます。
2.4 結果の段階：フィードバック・処理時間・利用量
結果の段階では、回答が利用者に届いたあとの反応と、処理のコストに関する情報を記録します。利用者の評価（役に立った、役に立たなかった）、自由記述のコメント、引用のクリックの有無、同じ内容の質問を言い換えて再度尋ねたかどうか、回答を別の手段で確認しに行った形跡などが、品質改善の材料になります。処理時間は、全体の時間に加えて、検索、再ランキング、生成といった段階ごとの時間を分けて残すと、遅延の原因が見つけやすくなります。
利用量は、モデルへの入力と出力の量（トークン〈モデルが処理する文章の単位〉の数）、モデルの呼び出し回数、検索の回数、再試行の回数、キャッシュ（結果の一時保存）を使ったかどうかといった項目です。これらは、費用の把握と按分に使われます。個々の質問について費用を計算する場合には、使ったモデルと、その時点の単価の考え方も必要になりますが、単価そのものは変動するため、ログには利用量と使ったモデルの識別を残し、金額は集計の段階で計算する設計が一般的です。
2.5 優先順位：必須・推奨・状況次第
記録項目をすべて同じ重みで扱う必要はありません。再現と説明に必須の項目、あると便利な推奨の項目、利用場面や機密度によって判断が分かれる項目の三つに分けて、優先順位を付けておくと、段階的に整備しやすくなります。必須に近いのは、利用者の識別子、時刻、質問の識別子、取得文書の識別子と版、権限判定の結果、モデルとプロンプトの版、処理の成否です。推奨に近いのは、各段階の処理時間、利用量、フィードバックです。状況次第なのは、質問と回答の本文、モデルに渡した文脈の全文などで、機微情報の扱いと直結するため、後の節で述べる方針に従って決めます。
図6：記録項目と目的の対応表
上の図は、四つの段階ごとの主な記録項目と、五つの目的との関係を、概念的に整理した対応表です。実際の項目は、システムの構成や業務の性質で変わるため、自社の目的に合わせて取捨選択してください。
3. 機微情報を含む質問と回答のログは、どう扱えばよいのか？
質問や回答には個人情報や機密が含まれうるため、ログに残す範囲、伏せ方、見られる人、残す期間を段階的に設計し、その方針を社内規程で合意しておく必要があるからです。
図7：機微情報を含むログの三つの扱い
社内RAGの利用者は、業務の中で自然に質問を書きます。「この顧客の契約条件を教えて」「この件の担当者の連絡先は」「私の休暇の残日数は」といった質問には、その場の業務に必要な情報が含まれており、利用者に悪意があるわけではありません。しかし、その質問が、そのままログに保管されると、顧客名、個人名、連絡先、人事に関する情報といった機微情報が、ログの中に蓄積されていきます。回答にも同じ情報が含まれるため、ログは「元の文書より広い範囲の情報が集まった場所」になり得ます。たとえば、特定の部門の文書は部門内にしか見えない設計になっていても、全部門の質問と回答が一つのログに集まれば、そのログを読める人は、横断的に内容を知ることができてしまいます。
この点は、生成AIの一般的な課題としても指摘されています。たとえば生成AIの問題点と解決方法を整理した記事では、プライバシーの侵害と個人情報の漏えいに対する対策として、個人情報の匿名化、アクセスログの監視、AIに関するプライバシーポリシーの整備が挙げられています。ログは監視のための道具であると同時に、保護の対象でもあるという二面性を踏まえて、設計を行う必要があります。
3.1 ログが「新しい情報の置き場所」になる仕組み
ログに機微情報が蓄積される経路は、質問と回答の本文に限りません。モデルに渡した文脈には、検索で取得された文書の断片が含まれており、その断片に個人情報や機密が含まれていれば、文脈を丸ごと記録することで、断片の内容もログに複製されます。また、エラーが起きたときに、例外の詳細情報として入力の内容がそのまま出力される実装もあり、意図せずに本文がログに混入することがあります。さらに、利用者が画面で入力したファイルの内容や、貼り付けたテキストも、質問の一部として記録されることがあります。
もう一つの注意点は、ログの保管先が、元の文書とは別の管理体制になりやすいことです。元の文書は文書管理システムで権限が管理されていても、ログは運用基盤の側で管理され、開発者や運用者、外部の支援会社の担当者が広く閲覧できる状態になっていることがあります。つまり、「文書は保護されているが、ログは保護が弱い」という逆転が起きやすいのです。ログを設計するときは、元の文書より弱い保護にならないことを、基本の原則として置いておくのが安全です。
3.2 マスキングと最小化：どの段階で、どう伏せるか
機微情報への対策の基本は、そもそも記録しない、記録するなら必要な範囲に絞る、必要な場合は伏せて記録する、という順序で考えることです。監査ログの設計を解説したSYPの記事では、記録してはいけない情報として、パスワード、トークン、API（ソフトウェア同士をつなぐ接続口）のキー、セッションID、秘密鍵、カード情報が挙げられ、個人情報の生の値は、マスキング、最小化、変更があった項目名だけを記録する、といった方法を検討するとされています。これはもともと業務システム一般の監査ログを念頭に置いた整理ですが、RAGの質問と回答にも、そのまま当てはめて考えることができます。
マスキングを行う段階には、いくつかの選択肢があります。質問を受け付けた直後に、個人名や連絡先らしき文字列を検出して伏せ字に置き換えてから、ログに書き込む方法があります。ログに書き込んだ後に、保管の段階で伏せる方法もありますが、書き込みの時点では生の情報が通過するため、通過する経路の保護が必要です。いずれの方法も、検出の精度には限界があり、見落としや過剰な伏せ字が起こりうるため、「マスキングしたから安全」とは言い切れません。そこで、マスキングは、保存範囲の限定、閲覧権限の制限、保持期間の制限と組み合わせて、多層で考えることが望まれます。
図8：機微情報を含む記録の流れ
上の図は、質問や回答がログに書き込まれるまでの流れを、検出、マスキング、保存範囲の判断、保管、閲覧の順に整理したものです。検出に漏れがあっても、後段の保存範囲と閲覧制限で影響を小さくする、という多層の考え方を表しています。
3.3 保存範囲の段階化：メタ情報・要約・本文
保存範囲は、二択ではなく段階で考えると、実務に落とし込みやすくなります。最も軽い段階は、本文を残さず、識別子、時刻、判定結果、処理時間、利用量といったメタ情報だけを残す方法です。この段階でも、誰がいつ何件の質問をしたか、どの文書がどれだけ取得されたか、権限で除外された回数はどのくらいか、といった多くの分析が可能です。次の段階は、本文の代わりに、質問の分類や、伏せ字化した要約を残す方法です。さらに次の段階は、マスキングを施した本文を、限られた期間だけ残す方法です。最も重い段階は、生の本文と、モデルに渡した文脈の全文を残す方法で、残す場合は、対象の範囲、期間、閲覧者を最小限に絞る必要があります。
どの段階を標準とするかは、システムが扱う情報の機密度と、ログの目的によって決まります。たとえば、機密度の低い公開済みの文書だけを対象にした問い合わせ窓口であれば、本文をマスキングして残す方針でも、リスクは小さいと考えられます。一方で、人事や顧客の情報を扱う領域では、標準はメタ情報のみとし、詳細は承認を得たうえで一時的に参照できる、という設計が選ばれることがあります。領域ごとに段階を変える設計は、文書の機密区分と対応させることで、運用の説明もしやすくなります。
図9：保存範囲の四つの段階
3.4 閲覧制限・保持期間・削除要求：社内規程で決める
閲覧できる人の範囲は、ログの種類ごとに分けて設計します。障害調査のための運用ログは運用担当者が、監査ログは監査部門や情報管理の責任者が、品質改善のためのログは文書の責任者や改善の担当者が、それぞれの目的に必要な範囲で閲覧できるようにします。開発者や外部の支援会社が、本番のログを直接閲覧できる状態にするかどうかは、特に慎重な判断が必要です。閲覧そのものも記録に残し、誰がいつどのログを見たかを追えるようにしておくと、ログへの不正なアクセスの抑止にもなります。
保持期間は、法令、業界の指針、契約、社内規程によって異なるため、本記事では具体的な期間を示しません。考え方としては、目的ごとに保持期間を分け、監査に必要な記録は長めに、詳細な本文や文脈は短めに、というように、情報の重さに応じて差を付ける設計が一般に取られます。先に触れた監査ログの設計記事でも、保持期間は法令、業界のルール、内部統制、契約によって決まり、重要なイベントは長く、日常的な管理操作は短く、といった階層化を検討するとされています。期間が過ぎたログを確実に削除する仕組みも必要で、削除の実行と確認が、運用の手順に含まれている必要があります。
もう一つ、見落とされやすいのが、削除や開示の要求への対応です。利用者や関係者から、自身の情報の扱いについて問い合わせがあった場合に、ログの中の該当部分を特定できるのか、どう対応するのかを、あらかじめ法務や人事と相談しておく必要があります。ログが膨大で、識別子による検索ができない構造だと、対応に大きな負担が生じます。構造化された記録と識別子の設計が、このような場面でも役立ちます。いずれにしても、保存範囲、閲覧者、保持期間、削除要求への対応は、技術部門だけで決められるものではなく、社内規程として合意し、文書に残すことが前提になります。
4. 監査ログに求められる要件は何か？改ざん防止・時刻同期・完全性・追跡可能性
監査ログは、事実を後から第三者に示すための証拠として使われるため、一般のログにはない、改ざんされにくいこと、時刻が信頼できること、欠落がないこと、行為と人を結びつけられることが求められるからです。
図10：監査ログに求められる四つの要件
ログを「障害調査のための記録」として見ているうちは、多少の欠落や時刻のずれがあっても、運用上の支障は限られます。ところが、ログを「監査のための証拠」として使う場面では、事情が変わります。なぜなら、証拠としての価値は、その記録が後から書き換えられていないこと、記録の時刻が正しいこと、必要な出来事が漏れなく記録されていること、そして誰の行為であるかが特定できることに、支えられているからです。いずれかが欠けると、記録は存在していても、「事実を示す根拠」としては扱いにくくなります。
監査ログの要件を最初に整理しておく利点は、設計の優先順位が明確になることです。すべてのログを監査水準で保護しようとすると、費用も運用の負担も大きくなります。そこで、監査のために保護すべき記録の範囲を限定し、その範囲に対して厳格な要件を適用し、それ以外のログは、障害調査や品質改善に必要な水準にとどめる、という二層の考え方が現実的です。この節では、監査ログに求められる四つの要件を順に確認します。
4.1 監査ログと、運用ログ・セキュリティログの違い
ログには、用途に応じていくつかの種類があります。アプリケーションの動作を記録する運用ログは、エラーや処理の経過を残し、障害の調査に使われます。セキュリティの観点で、認証の失敗や不審なアクセスを記録するセキュリティログは、攻撃や侵入の兆候を見つけるのに使われます。これらに対して、監査ログは、「誰が、いつ、どの対象に、何をしたか、その結果はどうだったか」を、統制の確認や事後の検証のために残す記録です。監査ログの目的や設計を解説した記事では、アプリケーションログやセキュリティログとの違いが整理され、記録する基本項目として、行為の主体、時刻、操作、対象、結果、接続元などの文脈が挙げられています。
RAGに当てはめると、運用ログは「検索が時間切れになった」「モデルの呼び出しが失敗した」といった技術的な出来事を残し、セキュリティログは「認証に繰り返し失敗した」「権限外の文書を要求する試みが検出された」といった兆候を残します。監査ログは、「この利用者に、この文書の断片が、この権限判定の結果、この回答の根拠として提示された」といった、統制に関わる事実を残します。同じ出来事が複数のログに現れることはありますが、目的と保護の水準が異なるため、保管先や閲覧権限を分けて設計するのが一般的です。
図11：運用ログ・セキュリティログ・監査ログの違い
4.2 改ざん防止：追記専用・分離・外部保管
改ざん防止の第一の考え方は、記録を一度書いたら変更できない形で保管することです。同記事では、設計の原則として、追記のみを許す保管、削除権限の制限、保管先の分離、必要に応じた外部への保管が挙げられ、操作を行った本人が、その操作の記録を消したり書き換えたりできない構造にすべきであるとされています。この考え方はRAGにも当てはまります。たとえば、RAGの管理者が、特定の利用者の質問履歴を削除できる、あるいは権限判定の記録を修正できる状態であれば、不正があった場合にも、その痕跡が消されるおそれがあります。
実装の手段には、書き込み後に変更できない保存方式（一度だけ書き込め、以後は読み出し専用にする方式で、WORMと呼ばれます）を備えた保管先を使う方法、各記録に前の記録の要約値を連鎖させて改ざんを検知できるようにする方法、ログを運用基盤とは別の管理者が管理する保管先へ複製する方法などがあります。要約値（ハッシュ）とは、元のデータから一定の規則で作る固定長の値で、元のデータが少しでも変わると値が変わるため、変更の有無を確かめるのに使えます。これらの手段は、組み合わせることで強度が上がりますが、費用と運用の複雑さも増えます。どの水準まで求めるかは、監査の要件、取り扱う情報の重要度、組織の規模に応じて決める必要があります。
図12：改ざん防止と権限の分離
上の図は、改ざん防止の考え方を、書き込む側、保管する側、検証する側に分けて示したものです。記録を作るシステムの管理者が、記録の保管先を単独で変更できないようにするという、権限の分離が要点です。
4.3 時刻同期と順序：いつ起きたかを信頼できる状態にする
監査では、出来事の順序が重要になります。たとえば、権限の変更と、その直後の文書取得のどちらが先に起きたかによって、評価が変わる場面があります。各システムの時計がずれていると、複数のシステムにまたがる記録を並べたときに、順序が逆転して見えることがあります。RAGは、アプリケーション、認証基盤、検索基盤、モデルの提供元、ログ基盤など、複数の部品に分かれて動くため、時刻のずれが生じやすい構成です。
対策の基本は、すべての部品で同じ時刻の基準に合わせることです。NTP（ネットワーク経由で時刻を合わせる仕組み）を用いて、信頼できる時刻の供給源に各サーバーを同期させ、ログに記録する時刻は、UTC（協定世界時）を基準にした共通の形式にそろえる運用が、一般に取られます。タイムゾーンの表記が混在すると、集計の際に混乱するためです。加えて、時刻は端末やサーバーの側で付けるのか、ログ基盤が受け取った時点で付けるのかによって意味が異なるため、「発生した時刻」と「受け取った時刻」を両方記録しておくと、遅延や再送の影響を判断しやすくなります。
ただし、時計の同期を完璧にすることは現実には難しく、わずかなずれは残りうるため、順序の保証を時刻だけに頼らないことも大切です。一つの質問の処理の中では、処理の段階ごとに連番を付ける、あるいはトレースIDの中で順序を表現する、といった方法で、時刻のずれに左右されない順序関係を補っておくと、解釈の余地を減らせます。
4.4 完全性：欠落を検知できる状態にする
完全性とは、記録されるべき出来事が漏れなく記録されていることを指します。ログは、書き込みの失敗、ネットワークの断絶、基盤の障害、容量の逼迫などによって、気づかないうちに欠落することがあります。欠落は、記録が存在しないという形で現れるため、見つけにくいという特徴があります。監査の場面で「記録がない」ことは、「出来事がなかった」ことの証拠にならないため、欠落を検知できる仕組みが、監査ログの信頼性を支えます。
検知の方法としては、まず、期待される出来事と記録の突き合わせがあります。たとえば、質問を受け付けた件数と、回答を返した件数と、監査ログに記録された件数が、一致しているかを定期的に照合します。次に、記録に連番を付けて、番号の飛びを検出する方法があります。さらに、ログ基盤への書き込みが一定時間途絶えていないかを監視し、途絶えた場合に通知する方法もあります。重要なのは、ログの書き込みに失敗したときの振る舞いを、あらかじめ決めておくことです。監査ログの記録に失敗した場合に、処理を止めるのか、処理は続けて後で再送するのかは、情報の重要度と業務への影響を踏まえた設計判断であり、規程に残しておく必要があります。
図13：完全性を確かめる三つの方法
4.5 追跡可能性：行為と人を結びつける
追跡可能性とは、記録された行為が、誰のものか、どのような理由で行われたかをたどれる性質です。最初の条件は、利用者を一意に識別できることです。共有のアカウントや、役割単位の汎用アカウントを使って操作が行われると、記録は残っても、個人にたどり着けません。したがって、RAGの利用者は個人の認証を経て利用し、システム間の連携や定期処理は、専用のサービス用アカウントで動かして、人の操作と区別できるようにすることが望まれます。
次の条件は、システムが代行した処理の追跡です。RAGでは、利用者の質問を受けて、システムがモデルや検索基盤を呼び出します。このとき、呼び出しがどの利用者の質問に由来するのかを、識別子の引き継ぎによって結びつけておく必要があります。特にAIエージェント（利用者の代わりに複数の処理を自律的に進めるAI）が文書の更新や外部への送信などの操作を行う構成では、誰の指示で、どの判断を経て、何を実行したかを追えることが、一層重要になります。AIエージェントの評価を扱った記事でも、エージェントの評価では監査性と追跡可能性が重要であり、何が起きたか、なぜそうなったかを説明できるよう、プロセスの記録や追跡の仕組みを事前に設計しておくことが述べられています。
最後に、管理者の操作も追跡の対象に含めます。ログの設定変更、権限の付与、索引の再構築、プロンプトやモデルの切り替えといった管理操作は、システムの挙動を変えるため、誰がいつ何を変えたかが記録されている必要があります。管理者の操作こそ、最も強く記録すべき対象であるという考え方は、統制の観点で一般的です。
5. ログはどう設計するのか？構造化ログ・トレースID・相関
一つの質問が複数の部品を通り抜ける間の記録を、項目で整理された形式と共通の識別子で結びつけておくと、後から一本の道筋として復元でき、検索や集計もしやすくなるからです。
図14：ログ設計の三つの柱
ログの設計で最も軽視されやすいのが、記録の形式です。開発の初期には、処理の途中経過を文章としてそのまま出力する方法が手軽ですが、RAGのように複数の部品が連携するシステムでは、文章で書かれたログは、検索も集計も難しくなります。たとえば、「ある利用者の質問に対して複数件の文書を取得した」という文章から、後で「特定の文書が取得された回数」を数えようとしても、文章の書き方が揺れていると、機械的に処理できません。ログを分析に使うつもりなら、最初から機械で扱いやすい形式で出力しておく必要があります。
もう一つの課題は、部品をまたいだ追跡です。質問を受け付けるアプリケーション、権限を判定する層、検索基盤、モデルの呼び出しは、それぞれ別のログを出します。これらを結びつける共通の鍵がなければ、「この回答は、どの検索に由来し、どの権限判定を通ったのか」を人手で突き合わせることになります。構造化と識別子の設計は、この負担を減らすための基盤です。
5.1 構造化ログ：自由な文章ではなく、項目で残す
構造化ログとは、ログの内容を、項目名と値の組として整理して出力する形式のことです。代表的には、JSON（項目名と値の組で表すデータ形式）が使われます。構造化されたログでは、利用者の識別子、時刻、取得した文書の識別子の一覧、判定の結果といった情報が、決まった項目名に入るため、特定の項目で検索したり、集計したりすることが容易になります。たとえばアプリケーションの監視戦略を扱ったSYPの記事では、ログ設計について、時刻、リクエストID、エラーの種別などの項目を持つ構造化ログを推奨し、ログレベル（重要度の区分）の定義、保持の方針、個人データの保護にも触れています。この考え方は、RAGのログにもそのまま役立ちます。
構造化の際に気をつけたいのは、項目の粒度と一貫性です。同じ意味の項目が、部品ごとに異なる名前で出力されていると、横断的な検索ができません。たとえば、利用者の識別子が、ある部品では一つの名前で、別の部品では異なる名前で出力されていれば、結び付けるたびに変換が必要になります。そのため、最初に共通の項目名の一覧を決め、全部品がそれに従う運用が望まれます。また、項目の値には、自由な文章を入れるのではなく、あらかじめ決めた分類の値（成功、失敗、権限により除外、など）を使うようにすると、集計がしやすくなります。
5.2 トレースIDとスパン：一つの質問の道筋をたどる
トレースIDは、一つの質問の処理全体に付ける識別子です。質問が受け付けられた時点で発行し、検索、権限判定、再ランキング、モデルの呼び出し、回答の表示といったすべての段階のログに、同じトレースIDを付けて出力します。こうしておけば、トレースIDで検索するだけで、一つの質問に関する全部品の記録を、一括して取り出せます。
トレースの内部の各処理区間は、スパンと呼ばれます。たとえば、検索の区間、再ランキングの区間、生成の区間がそれぞれスパンで、開始と終了の時刻、親子関係、成否、付随する属性を持ちます。スパンを使うと、全体の処理時間のうち、どの区間に時間がかかったのかが一目で分かります。これは障害調査や性能の改善に役立つだけでなく、監査の場面でも、「この文書の取得は、この権限判定の後に行われた」という順序の確認に使えます。さらに、質問から派生した処理（再試行や、複数の検索への分解）も、親のトレースの下に位置づければ、全体像を見失いません。
トレースIDは、システムの外にも引き継ぐと価値が高まります。利用者に誤り報告の画面を提供するとき、報告に回答の識別子（トレースIDに対応するもの）を自動で添付すれば、報告を受けた担当者が、すぐに該当の記録を探し出せます。利用者に識別子を見せるかどうかは、画面設計の判断ですが、少なくとも報告の送信時に内部で結びつける設計は、調査の効率を大きく変えます。
5.3 相関：利用者・セッション・文書・版を結びつける
トレースIDで一つの質問の中の記録を結びつけたうえで、さらに、質問をまたいだ関連を追えるようにするのが、相関の設計です。まず、会話のまとまりを示すセッションの識別子があれば、一連の会話の中で質問がどう変化していったかを追えます。次に、利用者の識別子があれば、特定の利用者の利用パターンを追えます。文書の識別子と版があれば、特定の文書がいつ、誰に、どの質問への回答の根拠として使われたかを追えます。
とりわけ重要なのが、版の識別子です。索引の版、プロンプトの版、モデルの版、権限の設定の版、辞書の版などをログに添えておけば、変更の前後で挙動がどう変わったかを比較できます。複数の版が同時に動くことがある構成では、各回答がどの版の組み合わせで生成されたかを特定する手がかりにもなります。相関のための識別子は、増やしすぎるとログが重くなり、少なすぎると追跡できません。目的に照らして、「この三つの問いに答えられれば十分」という最小の集合を決めるとよいでしょう。たとえば、「この回答は誰の質問に由来するか」「どの文書が根拠だったか」「どの版で動いていたか」という三つです。
図15：トレースIDを軸にした相関
5.4 スキーマの管理と、変更への備え
構造化ログの項目の定義（スキーマ）は、システムの成長とともに変わります。新しい機能が加われば項目が増え、方針が変われば残す項目が減ります。変更のたびに、過去のログとの互換性が崩れると、分析や監査に支障をきたします。したがって、スキーマにも版を付けて管理し、各ログの記録にどの版のスキーマで書かれたかを含めておくと、後から読み解く際に役立ちます。
変更の原則としては、既存の項目の意味を変えない、項目を追加するときは既存の利用者を壊さない形で行う、廃止する項目は期間を置いて通知する、といった運用が考えられます。また、イベントの名前（「質問受付」「権限判定」「文書取得」など）を一貫した規則で付けておくことも、検索や集計の効率を大きく左右します。ログの設計は、一度作って終わりではなく、アプリケーションのインターフェースと同様に、変更の管理が必要な資産として扱うのが望ましいといえます。
5.5 監査証跡の例：一つの質問が残す記録の連なり
ここまでの設計がうまく働いたときに、どのような記録が残るかを、仮の値を使って示します。次の図は、一つの質問に対して、トレースIDで結びつけられた記録が、どのような順序で並ぶかを、概念的に表した例です。実際のデータや実在の利用者、文書を示すものではなく、項目の関係を説明するための表記です。
図16：監査証跡の例：トレースIDで結びついた記録の連なり
※図中の識別子や時刻はすべて説明のための仮の表記であり、実在の利用者、文書、記録を示すものではありません。
この例で注目したいのは、権限判定の記録が、文書取得の記録の前に位置し、除外された文書の識別子も残っていることです。また、回答の記録には、モデルとプロンプトの版が含まれ、表示の記録には、実際に利用者に見せた引用の識別子が含まれています。こうした連なりがあれば、「この引用は、この判定を通った文書から作られた」という主張を、記録によって裏づけられます。反対に、どこか一つの記録が欠けていると、その区間の事実は推測に頼ることになります。記録の連なりは、鎖のように、一つの欠落が全体の信頼性に影響すると考えて、設計と検証を行う必要があります。
6. ログの保管・検索・分析基盤は、どう組めばよいのか？
ログを集める、保管する、検索する、分析する、通知するという役割を分けて考え、保管の層と閲覧の権限を目的ごとに設計すると、費用と使いやすさと統制の均衡をとりやすくなるからです。
図17：ログ基盤の役割分担
ログ基盤という言葉は、特定の製品を指すものではなく、ログを集めて、保存して、探せて、分析できる状態にするための一連の仕組みを意味します。RAGのログ基盤を設計する際に、最初から高機能な製品を選ぶと、使い切れないまま費用がかさむ場合があります。そこで、まず、どの目的のために、どのくらいの量のログを、どの速さで検索できる必要があるのかを整理し、それに見合う構成を選ぶ順序で考えると、過不足の少ない設計に近づきます。
RAGのログに特有の事情は、一つの質問から生まれる記録の量が多く、かつ本文を含むと一件ごとの大きさも大きくなりやすいことです。さらに、利用が広がれば、質問の件数に比例して記録も増えます。量が増えるほど、保管と検索の費用が上がるため、どのログをどの層に置くかという設計が、費用に直結します。この点は、後の費用の節でも触れます。
6.1 収集から保管までの流れ
ログの流れは、発生、収集、変換、保管、利用の順に整理できます。各部品（アプリケーション、権限判定の層、検索基盤、モデルの呼び出し部分）が出力したログは、収集の役割を担う部分に集められます。収集の段階では、ログの欠落を防ぐために、一時的に溜めておく仕組みを挟んで、後続が遅れても取りこぼさないようにするのが一般的です。続いて、変換の段階で、項目の整形、マスキング、識別子の付与などを行い、保管の層へ送ります。
ここで重要なのは、マスキングを保管の前に行うことと、監査向けの記録を通常のログと分けて送ることです。通常の運用ログに混ざった状態では、監査ログに求められる保護を個別に適用できません。出力の時点で、ログの種類を示す印を付けておき、種類ごとに別の経路で保管する設計にすると、保護の水準を分けやすくなります。また、ログ基盤への送信が一時的に失敗しても、記録を失わないように、送信元で一時的に保持して再送する仕組みも欠かせません。
図18：ログ基盤の全体像
6.2 保管の層：すぐ探せる層と、長く残す層
ログの価値は、時間とともに変わります。出来事の直後は、障害の調査や異常の検知のために、素早く検索できる状態が求められます。時間が経つと、検索の頻度は下がりますが、監査や分析のために、長く残す必要が生じます。そこで、保管の層を分ける設計が一般的です。直近のログは、検索が速い層に置き、一定の期間が過ぎたものは、検索が遅くても費用が低い層へ移し、さらに期間が過ぎたものは、規程に従って削除する、あるいは要約したものだけを残す、という流れです。
層の切り替えの期間や、各層に置く内容は、社内規程と監査の要件で決まります。ここでも、メタ情報は長く、本文は短く、という差を付けられます。メタ情報は一件あたりの大きさが小さく、分析にも使いやすいため、長期の保管に向いています。本文を含む記録は、機微情報の観点からも、速い層にも長期の層にも長く置かない設計が、情報管理と費用の両面から合理的です。層を分けるときは、層をまたいだ検索が必要になる場面（長期にわたる傾向の分析など）を想定して、検索の手順も用意しておく必要があります。
6.3 検索と分析：何を問い合わせられるようにするか
ログは、保管するだけでは役に立ちません。検索できて、初めて価値を生みます。検索の設計では、よく使う問い合わせを先に洗い出します。たとえば、「特定の利用者の、ある期間の質問と回答の一覧」「特定の文書が、どの質問で取得されたか」「権限により除外された回数の、部門ごとの推移」「応答に時間がかかった質問の特徴」「特定のモデルの版に切り替えた前後の利用量の変化」といった問いです。これらの問いに素早く答えられるように、検索で絞り込みに使う項目に索引を付ける、あるいは集計済みの表を別に用意する、といった工夫を行います。
分析の用途によっては、ログをそのまま読むよりも、集計して指標として見るほうが適しています。ダッシュボード（指標をまとめて表示する画面）に、利用件数、失敗率、応答時間、権限による除外の割合、フィードバックの傾向などを表示しておけば、日常の運用で変化に気づけます。ただし、ダッシュボードの指標は、本文を見せずに作れるものを中心にして、本文に立ち入る分析は、承認を得た上での別の手順に分けるのが、機微情報の観点からは安全です。ログの検索そのものも記録して、誰がいつ何を検索したかを追えるようにしておきます。
6.4 基盤自体の健全性：ログ基盤の監視
ログ基盤自体が止まれば、その間の記録が失われる危険があります。したがって、ログ基盤も、監視の対象に含めます。確認したいのは、収集が滞っていないか、書き込みが失敗していないか、保管の容量に余裕があるか、検索が極端に遅くなっていないか、保管の層の切り替えが予定どおりに行われているかといった点です。また、ログ基盤の設定変更や、閲覧権限の変更も、監査の対象として記録しておきます。
非機能要件（性能、可用性、運用、セキュリティなど、機能以外の要件）の観点でも、運用の領域にログの管理が含まれます。非機能要件を整理した記事では、運用の項目として監視、ログ管理、障害対応が挙げられ、ログの管理では、保存する内容、保持期間、ログに含まれる個人情報の扱い、ログの量の管理といった点を定めておくことが述べられています。RAGの要件定義の段階で、ログに関する要件を、これらの観点で漏れなく書き出しておくと、後から基盤の見直しが必要になる事態を減らせます。
6.5 基盤の選び方：自前で組むか、提供されるサービスを使うか
ログ基盤は、クラウド事業者や専門の事業者が提供するサービスを使う方法と、自社の環境にソフトウェアを導入して運用する方法に大別できます。提供されるサービスは、導入が早く、容量の拡張や保守を任せられる利点がありますが、データの保管場所、保持期間の設定、外部への持ち出しや書き出し、費用の算定方式といった条件を、契約と仕様で確認する必要があります。自社で運用する方法は、データを自社の管理下に置けて、細かい調整ができる反面、容量の計画、障害時の復旧、更新作業などの負担が自社に生じます。
選ぶ際の確認観点は、ソフトウェア製品を評価する一般的なチェックの考え方が参考になります。ソフトウェアベンダー評価チェックリストを扱った記事では、セキュリティの項目として、誰がどのデータにアクセスしたか、何を変更したかの追跡、ログの保持、検索、書き出しが挙げられ、データの取り扱いの項目では、所有、保管場所、アクセス権、第三者への提供、削除、AIの学習への利用の有無などが挙げられています。ログ基盤の選定でも、これらの観点を自社の条件に置き換えて確認することで、導入後の食い違いを減らせます。
7. 異常検知とアラートは、どう設計すればよいのか？
大量アクセス、越権の試み、普段と異なる利用の三つを中心に、検知する異常を絞り、通知の優先度と対応の手順を結びつけておくと、ログが「後から読む記録」から「早く気づくための仕組み」に変わるからです。
図19：検知したい異常の三つの型
ログを蓄積しているだけでは、問題は、誰かが調べるまで見つかりません。インシデントの影響は、発見が遅れるほど広がる傾向があるため、ログの中から異常を自動で見つけ、担当者に知らせる仕組みが、本番運用では望まれます。ただし、検知の仕組みを作り込みすぎると、誤った通知が増えて、担当者が通知に慣れてしまい、本当に重要な通知を見逃すという、逆の問題が生じます。「何を検知したいのか」を絞り、「検知したら誰が何をするのか」まで決めておくことが、設計の要点です。
異常検知の対象は、RAG特有のものと、一般のシステムと共通のものに分けて考えると整理しやすくなります。共通のものは、エラー率の上昇、応答時間の悪化、サービスの停止などで、一般の監視の仕組みで扱えます。RAG特有のものは、権限に関わる異常、情報の持ち出しを疑わせる利用、回答の品質の変化、利用量と費用の急増などで、ログの内容を理解したうえでの検知の設計が必要です。この節では、特に監査と情報管理に関わる異常を中心に扱います。
7.1 検知したい異常の種類：大量アクセス・越権の試み・普段と異なる利用
最初に挙げたいのは、大量アクセスです。短時間に大量の質問が送られる、あるいは同じ範囲の文書が網羅的に取得されるといった利用は、情報を機械的に抜き出す行為や、認証情報の悪用、あるいは単なる自動処理の暴走の兆候である場合があります。RAGは自然な言葉で質問でき、一度の質問で複数の文書の内容が返るため、人手で文書を一つずつ開く場合より、情報を効率よく集められます。そのため、通常の文書管理システムより低い利用量でも、情報の持ち出しの観点では注意が必要になる場合があります。
次に、越権の試みです。権限外の文書を要求した結果として、権限判定で除外された回数が、特定の利用者で多い場合は、意図的な探索の可能性があります。「他部門の人事情報を教えて」「役員会の議事録を要約して」といった質問が繰り返される、あるいは言い換えや翻訳を重ねて制限を回避しようとする利用なども、兆候の一つです。AIレッドチーミングを解説した記事では、複数回のやり取りで文脈を誘導する、役割を演じさせる、翻訳や言い換えを使うといった手法が、試験の観点として挙げられています。こうした入力の特徴は、ログから事後に分析することで、検知のルールに活かせます。
三つめは、普段と異なる利用です。普段は業務時間内に利用している人が深夜や休日に大量に利用する、普段は使わない部門の文書を急に参照する、退職予定者の利用が急に増える、といったパターンです。これらは、それ単独で不正を意味するわけではなく、業務の都合による場合も多いため、「確認のきっかけ」として扱い、結論を急がない運用が必要です。これらの異常に加えて、運用の観点では、エラー率の上昇、応答時間の悪化、低い評価の増加、費用の急増なども監視対象になります。
図20：検知したい異常と手がかりになる記録
7.2 ルールベースと統計的な検知：平常時の基準をどう持つか
検知の方式は、大きく二つに分けられます。一つは、あらかじめ決めた条件に合致したら通知するルールベースの方式です。たとえば、権限による除外が一定の回数を超えたら通知する、特定の文書の取得が一定の時間内に集中したら通知する、といった形です。条件が明快で、通知の理由を説明しやすい利点があります。一方、条件の値（しきい値）をどう決めるかが難しく、低すぎれば誤検知が増え、高すぎれば見逃しが増えます。
もう一つは、平常時の利用の基準（ベースライン）を学習または集計しておき、そこからの乖離を検知する統計的な方式です。利用者ごと、部門ごと、時間帯ごとに平常時を持つことで、固定のしきい値では捉えにくい「その人にしては多い」という変化を見つけられます。AI運用ダッシュボードを扱った記事でも、固定のしきい値と動的なしきい値を組み合わせて異常を検知する考え方が示されています。ただし、統計的な方式は、導入直後で平常時の蓄積がない時期には精度が出にくいこと、業務の繁忙期や組織変更によって平常時そのものが変わることに注意が必要です。
実務では、まず少数のルールベースの検知から始めて、運用で得られた知見をもとに、基準を調整し、必要に応じて統計的な方式を加える、という段階的な進め方が現実的です。検知の条件には、設定した理由と、見直しの周期を記録しておくと、後から基準を見直す際の根拠になります。
7.3 通知の優先度と、誤検知への向き合い方
通知の優先度は、影響の大きさと緊急性で区分します。たとえば、権限外の文書の内容が提示された疑いは最優先とし、短時間での対応を求める。大量アクセスは次点とし、状況の確認を求める。品質や費用の変化は、定例の運用の中で確認する、といった区分です。アプリケーションの監視戦略を扱った記事では、通知を重大、警告、情報といった水準に分け、重複した通知の統合、短時間の変動の無視、状態が続く場合にのみ通知するといった工夫で、通知疲れ（アラートファティーグ）を避けることが述べられています。また、夜間や休日を含めた連絡経路を、事前に決めておくことも指摘されています。
誤検知は、完全にはなくせません。重要なのは、誤検知を減らす努力と同時に、誤検知が発生したときに記録して、次の改善に活かす運用を持つことです。通知を受けた担当者が、「正当な利用だった」「確認の結果、問題なし」と判断した場合に、その結論と理由を記録しておけば、同じパターンの通知を調整したり、除外の条件を設けたりできます。除外の条件を設ける際は、その条件が新たな見逃しの穴にならないか、情報管理の責任者が確認する手順を加えておくと安全です。
図21：通知の優先度の設計
7.4 検知から対応までの流れ：誰が、何を、どこまでやるか
アラートの設計は、通知を出すところで終わりません。通知を受けた後の流れを、事前に決めておく必要があります。一般的には、検知、一次確認、判断、対応、記録の順に流れます。一次確認では、通知の内容に対応するトレースIDや利用者の記録を確認し、正当な利用か、異常の可能性があるかを切り分けます。異常の可能性が高い場合は、情報管理の責任者に引き継ぎ、利用の一時停止、権限の見直し、より詳細な調査といった対応を判断します。
この流れの中で、判断の権限を明確にしておくことが重要です。たとえば、利用者のアカウントを一時的に停止する権限は誰が持つのか、停止する際に、本人や上長への連絡は誰が行うのか、といった点です。判断が個人の裁量に委ねられると、対応の速さにも公平さにもばらつきが生じます。また、一次確認の担当者が見られるログの範囲を、確認に必要な最小限にとどめ、詳細な本文の参照が必要な場合は、承認の手順を経る設計にすると、ログの閲覧そのものによる情報の拡散を防げます。
図22：アラートの流れ
8. インシデントが起きたとき、ログからどう追跡すればよいのか？
インシデントの調査では、時刻・利用者・文書・判定・版の順に記録をたどる手順をあらかじめ決めておき、証拠を保全しながら影響範囲を絞り込むと、短時間で事実を確定しやすくなるからです。
図23：インシデント追跡の流れ
インシデントが起きたとき、ログは最も重要な情報源になります。しかし、緊急時には、冷静に手順を考えている余裕がなく、場当たり的にログを探すことになりがちです。手順を事前に決めておけば、担当者が変わっても、一定の質で調査を進められます。また、調査の過程で、ログを誤って上書きしたり、証拠となる記録を失ったりすることを避ける意味でも、手順書の整備が有効です。
RAGのインシデントには、いくつかの典型があります。権限のない利用者に、本来見えるはずのない文書の内容が回答として提示された疑い。誤った回答が業務の判断に使われ、損害や混乱が生じた疑い。ログイン情報の不正利用や、大量の情報取得の疑い。機密情報を含む質問が、意図せず外部のモデルへ送信されていた疑い。これらは、調べるべき記録も、関与すべき部門も異なります。手順の骨格を共通にしつつ、種類ごとの分岐を用意しておくと、初動を迷わずに進められます。
8.1 最初の問い：何が、誰に、どこまで見えたのか
調査の出発点は、発端となる情報の整理です。「いつ頃」「誰が」「どの質問に対して」「何が問題だったのか」を、報告者から聞き取り、可能な限り記録の識別子（回答の識別子、トレースID、時刻、利用者）に結びつけます。この段階で、報告が曖昧でも、時間帯と利用者が分かれば、ログを絞り込めます。逆に、これらが全く分からない場合は、ログの検索の範囲が広がり、調査に時間がかかります。誤り報告の画面に、回答の識別子を自動で添付する設計の意義は、ここにあります。
最初に確認したいのは、「何が」「誰に」「どこまで」見えたのかという三点です。何が、とは、提示された内容の範囲（どの文書の、どの部分か）。誰に、とは、提示された相手（一人か、複数か、外部の関係者か）。どこまで、とは、提示が回答の画面にとどまるのか、他の場所（キャッシュ、ログ、通知、外部のモデル）にも波及しているのかという広がりです。回答の画面にとどまらず、他の経路に広がっている可能性があれば、早い段階で関係者に共有し、封じ込めの対応と並行して調査を進める必要があります。
8.2 追跡の手順：トレースIDから、判定・文書・版へ
発端の記録を特定できたら、トレースIDを軸に、一連の記録を取り出します。受付の記録から始めて、権限判定の記録、検索の記録、取得文書の記録、モデルに渡した文脈の記録、回答の記録、表示の記録の順にたどります。それぞれの段階で、「その時点で何が起きていたか」を確認します。権限判定の記録が、問題の文書を「許可」と判定していたなら、判定に使った属性や規則の版を確認し、判定が誤っていたのか、元の権限の設定が誤っていたのか、権限情報の同期が遅れていたのかを切り分けます。
次に、同じ文書や同じ判定の規則が、他の質問でも使われていなかったかを調べます。原因が個別の事象ではなく、設定や仕組みにあるのであれば、同じ原因による他の事象が存在するはずです。文書の識別子で検索して、その文書を根拠にした他の回答の一覧を取り出し、誰に提示されたかを確認します。この作業ができるかどうかは、平常時のログ設計にかかっています。文書の識別子と版で検索できない形式では、調査に時間がかかります。
図24：追跡の手順
8.3 影響範囲の特定と、証拠の保全
影響範囲の特定は、追跡の結果を整理して、「何件の、どの種類の情報が、誰に提示されたか」を確定する作業です。ここで、確実に言えることと、推定でしか言えないことを、明確に区別して記録します。ログに欠落がある期間や、本文を残していないために内容を確認できない範囲があれば、その旨を明記します。推定を事実のように報告すると、後に訂正が必要になり、信頼を損ねます。
証拠の保全は、調査と並行して始めます。対象のログを、通常の保持期間の経過による削除から除外し、書き換えができない形で複製します。また、当時の権限の設定、索引の版、プロンプトとモデルの設定といった、ログ以外の状態も、可能な範囲で記録しておきます。なぜなら、ログは「何が起きたか」を示しますが、「その時の設定がどうだったか」は、設定の履歴がなければ分からないからです。調査や是正の過程で設定を変更する前に、変更前の状態を保存する習慣をつけておくと、後の検証に役立ちます。法的な手続きや外部への報告が絡む可能性がある場合は、法務部門と早い段階で連携し、保全の方法を相談します。
8.4 報告と再発防止：ログの不足も振り返る
調査が終わったら、報告と再発防止に進みます。報告の内容は、事象の概要、発生から発見までの経過、原因、影響範囲、対応の内容、再発防止策です。報告先や期限は、社内の規程や契約によって定まるため、本記事では一般的な項目のみを示します。重要なのは、事実と推定を分けること、ログで裏づけられる部分と裏づけられない部分を明示することです。
再発防止の検討では、原因への対策に加えて、ログそのものの振り返りを行います。調査の過程で、「このログがあれば早く分かった」「この項目が欠けていて確定できなかった」という場面があったはずです。それらを記録し、ログの設計に反映します。また、検知が遅れた場合は、なぜ検知できなかったのか、どのような条件を加えれば検知できるかを検討します。インシデントは、ログと検知の設計を改善する、貴重な機会でもあります。再発防止策が、権限の設計や評価の設計といった、他の領域の改善につながる場合は、それぞれの担当に引き継ぎます。
9. ログは品質改善に、どう活かせばよいのか？
失敗した質問を型に分けて分析し、利用者の反応と組み合わせて原因の層を切り分け、結果を評価セットや文書の改善に戻す循環をつくると、ログが回答の質を継続的に高める材料になるからです。
図25：ログを品質改善の循環につなげる
ログの第一の目的は、統制と調査ですが、蓄積されたログは、品質改善の貴重な材料でもあります。実際の利用者が、実際の業務の言葉で書いた質問は、開発者が想定した質問とは異なる傾向を持つことが多く、運用を通じて初めて見えてくる課題が少なくありません。ただし、品質改善にログを使う場合、機微情報を含む本文を分析者が読むことになるため、閲覧の範囲と目的を限定する運用が、監査・情報管理の観点から必要になります。
品質改善のためのログ分析の具体的な手法、たとえば検索精度の指標の設計や、評価セットの作り方は、それぞれ別の論点として詳しく扱われます。ここでは、ログの設計と運用の観点から、品質改善に結びつけるための考え方に絞って述べます。
9.1 失敗した質問の見つけ方と、型への分類
失敗した質問は、いくつかの手がかりで見つけられます。利用者が低い評価を付けた回答、すぐに言い換えて再質問された質問、「該当なし」と答えた質問、回答に引用が付かなかった質問、権限により多くの候補が除外された質問、応答に時間がかかった質問などです。これらは、メタ情報だけでも抽出できるものが多く、本文を直接読まなくても、候補を絞り込めます。
抽出した質問は、型に分類します。文書が存在しない（知識の欠落）、文書は存在するが検索で見つからなかった（検索の失敗）、文書が検索には現れたが回答に使われなかった（文脈の組み立ての問題）、古い版の文書が使われた（鮮度の問題）、権限により見えなかった（権限の設計の問題）、質問そのものが曖昧だった（質問側の問題）、といった型です。型に分けることで、どの担当が、どう直すべきかが見えてきます。たとえば、知識の欠落は文書の責任者へ、検索の失敗は検索の担当へ、鮮度の問題は文書の更新の担当へ、といった具合に、改善の依頼先が定まります。
図26：失敗した質問の型と改善の担当
9.2 利用者の反応を読む：評価だけでなく、行動も手がかりにする
利用者の評価は、直接的な手がかりですが、評価を付ける利用者は一部であり、評価がないことは、満足を意味しません。そのため、評価に加えて、行動からも手がかりを得ます。生成AIの出力品質を扱った記事でも、利用者による編集、選択、却下、再生成といった行動が、改善のための信号として扱えること、そのためには評価の設計が必要であることが述べられています。RAGに当てはめれば、引用のクリックの有無、回答のコピー、再質問、会話の途中での離脱などが、行動の手がかりになります。
ただし、行動の解釈には注意が必要です。回答をすぐにコピーしたのは、満足したからかもしれませんし、後で確認するつもりで一時的に保存したのかもしれません。再質問は、回答が不十分だったからかもしれませんが、関連する別の疑問が生じたからかもしれません。行動のデータは、単独で結論を出す材料ではなく、傾向を見て、仮説を立てて、少数の事例を人手で確認して裏づける、という使い方が適切です。人手で確認する際には、本文を読む担当者と範囲を限定し、承認のもとで行う運用が望まれます。
9.3 モニタリングとの接続：静かな劣化を見つける
生成AIのシステムには、システムは正常に応答しているのに、回答の質が少しずつ低下するという、静かな劣化が起こりえます。文書の更新、利用者の質問の傾向の変化、モデルの更新などが原因になります。AIモデルの監視を扱った記事でも、運用中に入力データや利用者の行動が変化して精度が下がること、その劣化は緩やかで気づきにくいこと、監視は異常の検知にとどまらず運用の設計として捉えるべきことが述べられています。また、監視の指標を増やしすぎると重要な信号が埋もれるため、重要な異常を優先し、通知ごとに次の行動を決めておくことが指摘されています。
ログの観点では、品質に関する指標を、定期的に集計して推移を見る仕組みが有効です。たとえば、回答の評価の傾向、「該当なし」の割合、引用の付与率、再質問の割合、権限による除外の割合などを、週や月の単位で比較します。変化が見られたら、その時期に何を変更したか（文書の更新、モデルの切り替え、プロンプトの変更など）を、版の記録から確認します。版の記録があれば、因果の仮説を立てやすくなります。なお、データ品質の観点では、データ品質の評価軸を整理した記事で、定義を守る担当者と運用を担う担当者を分けて置くこと、鮮度や重複などの少数の指標を持続できる形で監視することが述べられており、文書側の問題を扱う際にも参考になります。
9.4 評価セットと改善への還元：機微情報に配慮して
ログから見つけた失敗の事例は、評価セットに加えると、同じ失敗の再発を防ぐ試験になります。実際の質問から作られた評価は、現実の利用に近いため価値が高い一方、質問の本文には機微情報が含まれる可能性があります。評価セットに加える際は、個人名や顧客名などを仮の表記に置き換える、質問の趣旨を保ったまま書き換える、評価用の保管先の閲覧を限定する、といった配慮が必要です。元の質問をそのまま評価セットに写すことは、ログに適用していた保護を、迂回してしまうことになりかねません。
改善のループは、ログの分析、原因の切り分け、改善の実施、再確認という流れで回ります。改善の実施後に、同じ種類の質問で結果が良くなったかを、ログの推移で確認し、評価セットでも確認します。この循環が回り始めると、ログは、運用の負担ではなく、改善の資産として認識されるようになります。一方、分析のための閲覧が、利用者の信頼を損なうことがないよう、後の節で述べる透明性と規程の整備を並行して進める必要があります。
10. 利用量のログから、コストをどう可視化すればよいのか？
トークン数や呼び出し回数などの利用量を、部門・用途・モデルの単位で記録しておけば、費用の按分、異常の発見、改善の優先順位づけがしやすくなり、ログ基盤自体の費用も含めた全体像を把握できるからです。
図27：利用量のログから費用を見える形にする
RAGの運用費用は、導入前には見通しにくく、運用が始まってから、想定と異なる形で現れることがあります。費用が増える要因は、利用者の増加だけではありません。質問が長くなる、取得する文書の件数を増やす、より高性能なモデルに切り替える、再試行が増える、といった内部の変更でも、一件あたりの費用は変わります。費用の変化を、原因とともに説明するには、利用量が詳細に記録されている必要があります。
費用の可視化は、単に請求額を眺めることとは異なります。請求書は、提供元ごと、期間ごとの合計しか示さないため、どの部門のどの用途が費用を生んでいるのかは分かりません。ログに利用量と、それを誰がどの用途で使ったかの情報を残しておけば、請求額を内訳に分解でき、改善の優先順位をつけられます。
10.1 コストの内訳と、ログで取れる単位
RAGの費用の主な要素は、文章を生成するモデルの利用、検索のための基盤、文書を取り込んで索引にする処理、並べ替えのモデルの利用、データの保管、ログの保管と分析、そして運用の人手です。このうち、ログから直接得られるのは、モデルの利用に関する量（入力と出力のトークン数、呼び出し回数）、検索の回数、再ランキングの回数、再試行の回数、キャッシュの利用の有無、処理時間などです。
これらの量は、モデルごと、機能ごと、利用者や部門ごとに集計できるよう、記録の時点で属性を付けておきます。金額への換算は、集計の段階で、単価の表を使って行うのが一般的です。単価は変動するため、ログに金額を直接書き込むよりも、利用量とモデルの識別子を残し、期間ごとの単価を別に管理するほうが、後から再計算でき、単価の改定にも対応しやすくなります。
10.2 部門・用途・モデルの単位での按分と可視化
費用の按分は、利用量の記録に付けた属性（部門、プロジェクト、用途、モデル）で集計して行います。たとえば、AI運用ダッシュボードを扱ったSYPの記事では、費用の管理として、リクエスト数、入力と出力のトークン数、モデル別・機能別・利用者別・時間帯別の費用、一件の解決あたりの費用などを可視化することが示されています。同記事は、費用の増加を単独で見るのではなく、成果との関係で見る、すなわち、費用対効果の観点を持つことの大切さも示しています。
按分の仕組みは、費用の透明性を高める一方、部門間の費用負担の議論を生むこともあります。按分の規則（利用量に比例するのか、基本料を人数で割るのか、など）は、運用の開始前に、関係部門と合意しておく必要があります。按分に使う属性（部門や案件の識別子）の正確さも重要で、異動や組織改編に伴って属性が変わる場合の扱いを決めておかないと、集計が実態からずれていきます。
図28：費用の算出と按分
10.3 コストの異常とガードレール
費用の急な増加は、予算の超過だけでなく、不具合や不正の兆候であることもあります。たとえば、再試行が繰り返されて呼び出しが増えている、特定の利用者が大量の質問を送っている、取得する文書の件数が設定ミスで増えている、といった場合です。費用の急増を検知するために、利用量の推移を監視し、平常時から外れたら通知する仕組みを、前述の異常検知の一部として組み込みます。
予防の仕組み（ガードレール。逸脱を防ぐ仕組み）として、利用者や部門ごとの利用の上限、一回の質問で使える量の上限、上限に近づいたときの通知と、超えたときの挙動（制限をかける、軽いモデルに切り替える、承認を求める）を決めておく方法があります。WebアプリとAIの統合設計の記事でも、費用の管理として、キャッシュの活用、結果の再利用、用途に応じたモデルの使い分け、費用が一定の限度を超えたときに高品質なモデルの利用を絞る停止条件が挙げられています。ただし、上限を厳しくしすぎると、業務に支障が出ます。上限の値は、業務の影響と費用の許容度を踏まえて、運用の中で調整するものとして位置づけるのが現実的です。
規模が大きくなった場合のコストの最適化については、RAGの大規模運用を扱った記事で、埋め込み（文章を数値の並びに変換したもの）の再利用、軽いモデルの活用、取得件数や文脈長の調整などの手段が示されると同時に、ある費用を削ると別の費用が増える場合があることも指摘されています。費用の可視化は、こうした調整の効果を、ログの数値で確かめるための土台でもあります。
10.4 ログ基盤そのものの費用
見落とされやすいのが、ログの保管と分析に要する費用です。質問と回答の本文、モデルに渡した文脈の全文を保存すると、一件あたりの大きさが大きくなり、保管と検索の費用が増えます。利用が広がるほど、この費用は無視できなくなります。したがって、ログの量が増える要因（保存する項目、保存の期間、検索の頻度、保管の層）を把握し、費用の管理の対象に含めます。
費用を抑える方法としては、前述の保存範囲の段階化、保管の層の使い分け、不要な項目の削減、古いログの集約や削除があります。ただし、費用の削減のために、監査に必要な記録まで削ってしまうことは避けなければなりません。何を残し、何を減らすかは、ログの目的に立ち返って判断します。費用を理由に、監査ログの範囲を狭めることが提案された場合には、情報管理の責任者を含めて、リスクを確認したうえで決める手順を設けておくと安全です。
図29：ログの費用を左右する要因
11. 利用者への透明性と同意、社内規程は、どう整えればよいのか？
ログは利用者の質問を記録する仕組みであり、何をどの目的で記録するかを利用者に伝え、取り扱いのルールを社内規程として定めておくと、利用者の信頼と、監査での説明のしやすさの両方を得られるからです。
図30：透明性を支える三つの層
ログの設計が技術的に優れていても、利用者が「何が記録されているのか分からない」と感じれば、社内RAGは使われなくなる可能性があります。利用者は、質問の内容が上司や人事に見られるのではないか、自分の疑問が評価に使われるのではないかといった不安を抱きやすいものです。不安があると、利用者は質問を控えたり、業務に必要な質問を言い換えて曖昧にしたりして、結果として、RAGから得られる価値も、ログから得られる学びも小さくなります。透明性は、倫理的な配慮であると同時に、システムの利用を支える実務上の条件でもあります。
もう一つの観点は、ログの取り扱いが、社内の規程や、個人情報の取り扱いに関する法令の考え方と整合している必要があることです。従業員の利用状況を記録することには、業務上の必要性がある一方、記録の範囲や目的によっては、従業員の権利や労務管理の観点での配慮も必要になります。これらの判断は、国や業種、社内の制度によって異なるため、本記事では一般的な論点の整理にとどめ、個別の判断は、法務、人事、情報管理の部門と専門家に確認してください。
11.1 何を記録しているかを、利用者に伝える
利用者に伝える内容は、記録の対象、記録の目的、閲覧できる人の範囲、保持の考え方、問い合わせの窓口です。たとえば、「質問と回答は、品質の改善と、情報管理の確認のために記録されます。内容は、権限を持つ限られた担当者のみが、所定の手続きのもとで閲覧します。人事の評価には使用しません」といった趣旨の案内です。具体的な表現は、社内の規程と合わせて決める必要があります。
案内の場所と頻度にも工夫が要ります。利用規約の長い文書の中に埋もれていると、読まれません。最初に利用する画面で、短い要点を表示し、詳細は別のページへ誘導する、入力欄の近くに機微情報の入力を避ける旨の注意を添える、といった方法が考えられます。なお、利用者に注意を促すだけでなく、システム側でも、機微情報を検出して警告を出す、記録の際に伏せるといった対策を併用することが望まれます。利用者の注意に依存する設計は、見落としや誤りに弱いためです。
11.2 同意と通知の考え方：法務・人事と確認する
ログの記録について、利用者の同意が必要かどうかは、記録する情報の種類、記録の目的、組織の制度によって異なります。「同意を取れば何でも記録してよい」というわけではなく、また、「同意が不要なら何も伝えなくてよい」というわけでもありません。目的が明確で、必要な範囲に限られ、利用者に知らされていることが、基本的な考え方として共通します。
実務では、就業規則や情報セキュリティ規程、利用規約といった既存の文書に、RAGのログに関する記載を追加し、通知する方法が取られることがあります。個別の同意を取得するか、包括的な通知にとどめるかは、法務や人事と相談して決めます。外部の関係者（派遣の従業員、委託先の担当者、取引先など）が利用する場合は、契約上の取り決めとあわせて確認する必要があります。生成AIの問題点と解決方法を整理した記事でも、企業の責任と透明性の観点から、利用ログの記録、出力の監査、段階的なアクセス制御が挙げられ、社内の方針を策定して責任者を明確にし、利用ログを取得して追跡可能性を確保することが述べられています。
11.3 社内規程に定めるべき事項
ログの取り扱いに関する社内規程は、新たに作る場合も、既存の規程に追記する場合も、定めるべき事項は共通します。まず、ログの目的です。何のために記録するのかを明記し、目的外の利用を禁止します。次に、記録の対象と範囲です。どの種類のログを、どの粒度で、どの範囲の利用者について記録するのかを定めます。保存の範囲、すなわち本文を残すか、マスキングするか、メタ情報にとどめるかの区分も含めます。
続いて、保持期間と廃棄です。ログの種類ごとの保持の期間と、期間経過後の削除の方法、削除の確認を定めます。閲覧権限と申請・承認の手続きも不可欠で、誰が、どの目的で、どの範囲を、どのような承認を経て閲覧できるのかを定めます。さらに、利用者本人からの開示や削除の問い合わせへの対応、インシデント時の保全と報告、外部の委託先がログに触れる場合の条件、そして規程そのものの見直しの周期と責任者も、定めておく項目です。責任の所在については、デジタルガバナンスを扱った記事で、デジタルガバナンスをデータ管理、セキュリティ、コンプライアンス、組織間の調整を含む経営の仕組みとして捉えることや、責任者の設置、第三者による監査といった体制の考え方が述べられており、ログの統制を組織の中に位置づける際の参考になります。
図31：社内規程に定める事項
11.4 目的外利用の禁止：信頼を守る線引き
規程の中で、特に重要なのが、目的外利用の禁止です。ログは、一度蓄積されると、さまざまな用途に使いたいという誘惑が生じます。たとえば、利用者の質問の内容から、従業員の関心や不満を推し量る、業務の遅れを追及する、人事評価の材料にする、といった使い方です。こうした利用は、目的に含まれていなければ、利用者の信頼を大きく損ない、システムの利用そのものを萎縮させます。
線引きの方法として、ログの閲覧の目的を、監査、障害調査、品質改善、コスト把握、インシデント対応に限定し、それ以外の目的での閲覧を禁止することを、規程に明記します。品質改善などの分析では、個人を特定しない形で集計する、本文を読む場合も、利用者を識別しない状態にする、といった運用を原則にします。例外的に、個人を特定した調査が必要になる場合は、インシデント対応のような限られた状況に限り、承認の手続きと記録を必須とします。目的外の利用を技術的に難しくする（たとえば、通常の分析の画面からは利用者の識別子を見えなくする）設計と、規程による禁止の両方があると、運用の信頼性が高まります。
12. 運用体制は、誰がログを見て、どう申請・承認を回すのか？
ログの閲覧を役割ごとに限定し、申請・承認・記録・定期レビューの循環を運用に組み込むと、ログが情報管理上の新しいリスクにならず、継続的に使える資産として保たれるからです。
図32：ログ運用の役割と手続き
ログの設計と基盤が整っても、運用の体制が曖昧だと、ログは活かされません。誰も見ないログは蓄積されるだけで、異常の通知も放置され、いざという時に必要な情報が見つからないという事態になります。逆に、誰でも自由に見られるログは、情報の拡散の経路になります。ログの運用では、「誰が、何のために、どこまで見られるか」を明確にし、見るための手続きを整えることが、基盤の整備と同じくらい重要です。
運用体制の設計は、ログの価値とリスクの両方を前提に行います。ログを積極的に活用する体制は、品質の改善や異常の早期発見を促します。同時に、閲覧を統制する体制は、ログ自体が漏えいの経路になることを防ぎます。この二つを両立させるために、役割の分担、申請と承認の手続き、定期的なレビューを、あらかじめ決めておきます。
12.1 役割の分担：誰が何を担うのか
ログの運用に関わる主な役割は、次のように整理できます。ログの基盤を管理する運用担当者は、収集、保管、検索の仕組みが正常に動いていることを維持します。情報管理の責任者は、ログの取り扱いの方針を定め、閲覧の承認や、例外の判断を担います。監査部門は、ログが方針どおりに記録され、保護されているかを、独立した立場で確認します。文書の責任者は、品質改善のための分析結果を受け取り、文書の改善に反映します。開発や改善の担当者は、障害の調査や品質の分析のために、必要な範囲でログを参照します。
重要なのは、ログを管理する役割と、ログを監査する役割を分けることです。ログを管理する担当者が、同時にログの内容の正しさを確認すると、不正や誤りがあっても自己点検になり、独立した確認になりません。また、システムの管理者が、自身の操作の記録を閲覧・削除できる状態も避ける必要があります。小規模な組織では、役割を完全に分けられない場合もありますが、その場合は、ログを組織の外部に複製して保管する、定期的に第三者が確認する、といった補完を検討します。
図33：役割ごとの閲覧範囲の考え方
12.2 閲覧の申請と承認：何を、誰が、どこまで
通常の運用で使う範囲を超えて、ログの詳細（特に本文）を閲覧する場合は、申請と承認の手続きを設けます。申請には、閲覧の目的、対象の範囲（期間、利用者、トレースなど）、必要な理由、閲覧する担当者、期間を記載します。承認者は、情報管理の責任者や、ログの管理者が務め、目的に対して範囲が過大でないかを確認します。承認の記録と、実際の閲覧の記録は、保存して、後から突き合わせられるようにします。
緊急時の手続きも、あらかじめ決めておく必要があります。インシデントが疑われ、承認を待つ時間的な余裕がない場合に、事後の承認を前提として閲覧を認める、あるいは、一次対応の担当者に限定した範囲の閲覧を認める、といった取り決めです。緊急の手続きは、乱用されやすいため、事後の確認と記録を必ず行うこと、緊急として扱える条件を明確にすることが前提です。承認の仕組みが煩雑すぎると、担当者が手続きを回避しようとするため、通常の業務で必要な範囲は、承認なしで見られるようにしておくなど、負担と統制の均衡をとる設計が現実的です。
12.3 定期レビューの循環：記録、確認、改善
運用を継続するためには、定期的なレビューの仕組みが必要です。レビューの対象は、ログが想定どおりに記録されているか（欠落や形式の乱れがないか）、異常の通知が適切に対応されたか、閲覧の記録に不審な点がないか、保持期間が守られているか、ログに関する規程や設定が現状に合っているか、といった項目です。レビューの周期は、情報の重要度と運用の規模に応じて、日次、週次、月次、四半期などの単位で組み合わせるのが一般的ですが、具体的な頻度は社内の規程で定めます。
レビューの結果は、記録して、改善に結びつけます。見つかった課題（記録の欠落、不要な項目、閲覧権限の過剰、通知の過多）に対して、対応の担当と期限を決め、完了を確認します。また、システムの変更（モデルの切り替え、新しい機能の追加、対象文書の拡大）があった際には、ログの設計が追従できているかを点検します。ログの設計は、システムの変化とともに陳腐化しやすいため、変更管理の手順に、ログの確認を組み込んでおくと安全です。
図34：ログ運用の循環
12.4 ログの閲覧そのものを、監査の対象にする
ログは、見られること自体が記録されるべきです。誰が、いつ、どのログを、どの目的で閲覧したかを、別の記録として残し、定期的に確認します。これは、ログへの不正なアクセスの抑止になるだけでなく、閲覧権限の棚卸しの根拠にもなります。先に触れた監査ログの解説記事の観点と同様に、ログを検索できる人を限定し、検索の操作も記録する運用が望まれます。
閲覧権限は、時間とともにずれていきます。異動や担当替えで不要になった権限が残る、一時的に付与した権限が戻されない、といったことが起こります。定期的に、誰がどのログを見られる状態にあるのかを一覧にして、必要性を確認し、不要な権限を外します。ロールに権限を結びつける方式は、権限の一覧を作りやすく、監査や権限の見直しに向いていると、アクセス制御モデルの比較記事でも述べられています。ログの閲覧権限も、ロールを基本に設計しておくと、棚卸しがしやすくなります。
13. ログ対応を含むRAG構築の費用は何で決まり、内製と外部支援はどう判断するのか？
RAG構築の費用は、ログ対応では記録の範囲と保持、改ざん防止の水準、検索と分析の要件、閲覧統制の仕組みで大きく変わるため、前提をそろえて見積を比べ、社内で決めるべきことと外部に任せられることを分けて判断する必要があるからです。
図35：ログ対応の費用は範囲と水準で決まる
RAG構築の費用を考える際、ログ対応は、見積の項目として独立して書かれないことがあります。「運用基盤」「監視」「セキュリティ」といった項目に含まれていたり、そもそも見積の対象外とされていたりします。その結果、構築が進んでから「監査に必要な記録が取れていない」と判明し、追加の作業と費用が発生するという事態が起こりえます。ログ対応を、最初から費用の見積に明示しておくことが、予算の見通しを立てるうえで有効です。
また、ログ対応の費用は、初期の構築費用だけでなく、運用が続く間の費用として継続的に発生します。ログは時間とともに蓄積され、保管と検索の費用は、利用の広がりとともに増えます。見積を比べる際は、初期費用と運用費用を分けて、前提を揃えて確認します。本節では、具体的な金額は示さず、費用を左右する要因と、判断の観点を整理します。
13.1 費用を左右する要因
ログ対応の費用を左右する要因は、大きく七つに整理できます。一つめは、記録の範囲と粒度です。どの段階の、どの項目を、どのくらい詳しく残すかによって、実装の作業と、保管するデータの量が変わります。二つめは、保持の期間と保管の層です。長く残すほど、保管の費用が増えます。三つめは、機微情報の対応です。マスキングの仕組み、検出の精度、保存範囲の段階化は、設計と検証の作業を要します。
四つめは、改ざん防止と完全性の水準です。追記専用の保管、外部への複製、整合性の検証の仕組みは、水準を上げるほど費用が増えます。五つめは、検索と分析の要件です。どのくらいの速さで、どのような問い合わせに答えられるようにするか、ダッシュボードをどこまで作り込むかで変わります。六つめは、異常検知とアラートの作り込みです。ルールの数、統計的な方式の採用、通知と対応の流れの整備によって、設計と調整の作業が増えます。七つめは、閲覧統制と運用の仕組みで、申請・承認の仕組み、閲覧の記録、定期レビューの手順をどこまで仕組みとして実装するかで変わります。
図36：ログ対応の費用を左右する七つの要因
13.2 初期の構築費用と、継続的な運用費用
初期の構築費用は、ログの設計、各部品への記録の実装、収集と保管の基盤の構築、マスキングの仕組み、ダッシュボードとアラートの整備、規程の整備の支援などから構成されます。継続的な運用費用は、ログの保管と検索の費用、基盤の保守と監視、閲覧の申請と承認の運用、定期レビュー、ログ項目や規則の見直し、異常通知への対応、インシデント時の調査の工数などです。
社内RAGと生成AIエージェントの開発の費用を扱ったSYPの記事では、RAGの費用は、モデルの価格よりも、データの準備、権限、評価、業務との連携に左右されること、ガバナンスと監視の層に、監査の記録、品質、利用量、費用が含まれること、継続的な費用に、ログの保管や監視が含まれることが示されています。同記事は、質問に対してどの文書が取得され、どのモデルが回答し、誰が使ったかを示せることを、管理機能の要件として挙げています。ログ対応を、後から付け足す機能ではなく、設計の初期から含める構成要素として位置づける考え方といえます。ただし、実際の費用は、データ、利用者数、権限の構造、連携先、セキュリティ要件、評価の方法によって変わるため、自社の条件で見積を取ることが前提です。
13.3 見積を比べるときに、そろえておく前提
複数の候補から見積を取る場合、ログ対応の範囲が各社で異なると、金額の比較が成り立ちません。そろえておく前提は、記録する項目の範囲、本文の扱い（残すか、マスキングするか、残さないか）、保持の期間と層、改ざん防止の水準、検索と分析の機能、異常検知の範囲、ダッシュボードの種類、閲覧統制の仕組み、規程の整備の支援の有無、利用規模の想定（利用者数、質問数、文書数）です。
見積書の読み方としては、ログ対応が含まれているのか、含まれているならどの範囲か、運用費用にログの保管が含まれるのか、利用量に応じて変動するのか、を確認します。変動する場合は、変動の要因と、上限の設定方法を尋ねておくと、予算の見通しが立てやすくなります。また、ログ基盤を自社の契約で用意するのか、開発会社の環境に置くのかによって、費用の帰属と、データの管理の責任が変わります。契約終了時のログの返却と削除の取り扱いも、見積の段階で確認しておく項目です。
図37：見積を比べるときにそろえる前提
13.4 内製と外部支援の判断軸
ログの設計は、社内でなければ決められない部分と、外部の経験が活きる部分が混在します。社内で決めるべきことは、ログの目的、機微情報の扱いの方針、保持期間、閲覧権限、規程、責任者の設置です。これらは、自社の事業、法令上の位置づけ、組織の文化に依存し、外部の担当者が代わりに決められるものではありません。外部に任せられるのは、ログの項目の設計案、記録の実装、基盤の構築、ダッシュボードやアラートの整備、運用の手順の整備の支援などです。
候補を比較する観点としては、ログとコストを含む運用までを設計に含めているか、機微情報の扱いについて具体的な提案ができるか、提供する環境でのログの帰属と取り扱いが明確か、が挙げられます。たとえばSYPのAIエージェント開発のページでは、権限をデータの層で制御すること、質問、検索、回答までの記録を監査向けに残すこと、品質、利用、費用のダッシュボードを備えること、費用をエージェントやプロジェクトの単位で報告することが、構成や進め方の要素として示されています。このように、ログや費用の可視化をどのように扱うかを説明している提供事業者は、比較の手がかりが得やすいといえます。AIエージェント開発会社や社内の生成AI導入支援を行う事業者を選ぶ際は、説明の具体性と、運用の想定の確かさを確認することをお勧めします。
図38：内製と外部支援の役割分担の考え方
13.5 外部支援先に確認したい質問と、段階的な導入
外部の支援先に確認したい質問は、次のようなものです。標準で記録する項目は何か、本文を残す場合のマスキングの方式と検出の限界は何か、保持と削除の設定は自社で変更できるか、改ざん防止のためにどのような仕組みを用いているか、開発や運用の担当者は、本番のログにどの範囲でアクセスするのか、再委託先がログに触れる可能性はあるか、契約終了時にログはどう返却・削除されるか、といった点です。再委託を含む体制の見え方については、SIer（システム開発の受託事業者）の選び方を扱った記事でも、再委託は一概に問題ではなく、構造が見えること、元請けの責任と品質の確認が明確であることが重要とされています。また、担当者が離れても自社に知識が残るよう、委託先に依存しすぎない状態を保つ観点も述べられています。
導入の進め方としては、最初から完全なログ基盤を目指すのではなく、段階的に整備する方法が現実的です。概念実証（PoC）の段階では、必須の項目をメタ情報中心に記録し、判定と取得の記録を欠かさないようにします。限定した利用者への本番の段階で、保存範囲の方針、閲覧の手続き、基本の異常検知を整えます。利用を広げる段階で、保管の層、分析、費用の按分、定期レビューを充実させる、という順序です。各段階で、規程と運用の合意を並行して進めることが、手戻りを防ぎます。段階ごとの判定の基準は、事前に文書で決めておくと、次の段階へ進める条件が明確になり、手戻りの判断もしやすくなります。
まとめ
社内RAGのログ監査は、記録を増やす作業ではなく、目的に照らして何を残し、何を伏せ、誰が見るかを設計し、運用し続けることとして捉えることが、出発点になります。なぜなら、ログは調査や監査を支える証拠であると同時に、管理を誤れば新しい情報の置き場所になるという二面性を持ち、利用の広がりとともに量も費用も増えていくからです。要点を次のように整理できます。
- 目的と記録項目：監査、障害調査、品質改善、コスト把握、インシデント対応の目的を分け、質問から回答までの四つの段階で、再現と説明に必要な項目を決める
- 機微情報の扱い：残さない、伏せて残す、権限者にだけ見せるを段階で使い分け、閲覧者と保持期間を社内規程で合意する
- 監査ログの要件：改ざん防止、時刻同期、完全性、追跡可能性を、監査の証拠として使う記録に絞って適用する
- ログの設計と基盤：構造化とトレースIDで一つの質問の道筋を復元でき、保管の層と検索の設計を目的ごとに分ける
- 検知と追跡：大量アクセス、越権の試み、普段と異なる利用を少数のルールから検知し、インシデント時の追跡と保全の手順を決めておく
- 活用と運用：失敗質問の分析とコストの可視化に使い、透明性、規程、申請・承認、定期レビューで統制を保ち、費用と内製・外部支援の判断は前提をそろえて行う
これらの設計は、一度に完成させる必要はありません。必須の項目から始め、利用の広がりに合わせて、保管、分析、検知、運用の仕組みを段階的に整えていく進め方が現実的です。ただし、ログの方針は、技術部門だけで決められるものではないため、情報管理、法務、人事、監査、文書の責任者と早い段階で合意し、判断の根拠を残してください。自社の状況に合わせて、社内RAGのログ監査を、本番運用に耐える設計に整えていくことが、利用を安心して広げていくための土台になります。
続けて読む
