実務者必見：AIエージェントのログ設計、全部取ると高くつく

AIエージェント（依頼を受けて複数の処理を自動でこなすAI）は、普通のWebアプリよりログがはるかに膨らみやすい仕組みです。ログを取らないのは論外ですが、「とりあえず全部取っておこう」も同じくらい危険です。保存・検索・監視のコストが膨らみ、機密情報がログという第二の置き場に溜まっていくからです。

ログ設計は、単なる技術論ではありません。監査、セキュリティ、費用対効果、業務改善のすべてに関わる設計です。導入後に慌てて考えるのではなく、PoC（本格導入前の小規模検証）の段階から最低限のルールを決めておく必要があります。この記事では、ログを3層に分類し、「あとで説明できる状態」を最小コストで作る方法を、会議アジェンダとKPI（効果を測る指標）まで含めて整理します。

なぜAIエージェントのログは膨らみやすいのか

普通のWebアプリで残るのはアクセス記録と処理結果くらいですが、AIエージェントは1回の依頼の裏側で複数のステップが動きます。LLM（大規模言語モデル。生成AIの本体）への問い合わせが何度も発生し、RAG（社内文書を検索してAIに読ませる仕組み）の検索結果、ツールの実行結果、参照したファイルの内容までがログに混ざり込みます。エラー時は再試行の記録も積み上がり、中間判断まで残すとログ量は一気に跳ね上がります。

たとえば「営業資料を作って」と依頼しただけでも、裏側では過去資料の検索、顧客情報の取得、社内規程の確認、ドラフト生成、レビュー、修正、出力保存が順に走ります。それぞれの入力・出力・参照情報をすべて保存すれば、1回の依頼とは思えない量のログが発生します。

高くつくのは「保存」ではなく、その後の処理

保存するだけなら比較的安く済む場合もあります。高くつくのは、取り込み、全文検索のためのインデックス化（検索できるよう整理する処理）、長期保存、監視基盤、分析クエリ、個人情報のマスキング（伏せ字化）といった周辺コストです。さらに、ログをLLMに読み込ませて品質を再評価する設計では、再処理の費用が保存の費用を上回ることさえあります。

危険なのは「すべてのログをリアルタイム監視の対象にし、全文検索可能にし、長期保持し、さらにLLMで再処理する」という全部盛りの設計です。LLMの利用料はtoken（AIが文章を処理する単位。文字数に近い感覚）の量で決まります。概算は次の3つの式で考えます。

月間ログ量 ＝ 1実行あたりのログサイズ × 1日あたりの実行回数 × 稼働日数
月間LLM費用 ＝ 1実行あたりのtoken数 × 月間実行回数 × モデル単価
ログ再評価コスト ＝ 再評価対象ログのtoken数 × 評価回数 × モデル単価

単価は頻繁に改定されるため、金額は最新の料金表で確認してください。コストを決めるのは実行回数、「1実行あたりに残す量」、「残したログを何回読み直すか」の3つです。ログは保存時だけでなく、検索・分析・再評価のたびに費用を生みます。

設計の前に決めるべき5つの問い

ツール選定より先に、次の5つに答えを出します。

• 1. 何のためにログを取るのか――監査か、障害調査か、品質改善か、費用管理か、セキュリティ監視か
• 2. どの粒度で残すのか――実行単位か、ステップ単位か、ツール呼び出し単位か。プロンプト（AIへの指示文）全文まで残すのか、成果物だけか
• 3. 何日残すのか――メタデータ（本文ではなく実行の概要情報）は長期、詳細ログは短期、機密情報は原則残さない、が基本線です
• 4. 誰が見られるのか――利用部門、情シス、セキュリティ部門、管理者、外部委託先
• 5. どのコストをKPIとして見るのか――部署別利用回数、モデル別token数、成功率、人手修正率、削減時間など

目的が違えば残す項目も期間も変わります。答えられないまま進めると必ず手戻りが起きます。

ログは3層に分ける

ログは「必ず残す」「短期間だけ残す」「原則残さない」の3層に分けます。

A. 必ず残すログ（長期保存）

監査・費用管理・KPI分析のためのメタデータです。実行ID、実行日時、利用部署、タスク種別、使用モデル、入出力のtoken数、実行時間、成功・失敗、エラー種別、承認者、概算コスト。ここで残すのは本文ではなく、あくまでメタデータです。この層は軽く、1年以上残しても負担は小さいうえ、「AIで何が改善したのか」を説明する土台になります。この論点は姉妹記事AIエージェントの行動記録で経営目線からも整理しています。

B. 短期間だけ残すログ（7〜30日）

障害調査・品質改善のためのログです。プロンプト全文、エージェントの中間応答、ツール呼び出しの詳細、RAG検索結果、エラー時の詳細記録、再試行ログなど。機密が混ざりやすい層のため、全文保存にはマスキングとアクセス制御を必ずセットにし、7日・14日・30日など短期で自動削除します。

C. 原則残さない、またはマスキングするログ

個人情報、顧客情報、契約書・メール・添付ファイルの本文、社内規程の全文、APIキー・パスワード・認証情報、人事評価、医療・金融などのセンシティブ情報。コスト以上に危険なのは、ログが第二の情報漏えい経路になることです。本体を固めても、ログに全文が残っていればそこが狙われます。

そのまま使えるログ設計テンプレート

迷ったら優先順位で考えます。最優先は実行ID・日時・利用部署・タスク種別・使用モデル・token数・成功／失敗・エラー種別・概算コスト。次が実行時間・ツール呼び出し回数・承認有無・人手修正の有無・再実行回数。プロンプト全文・生成結果・RAG検索結果・中間出力は「条件付き」で、ログ量と漏えいリスクを増やすため、本番では短期保存・マスキング・アクセス制限・サンプリング（一部だけ抜き出して詳細に残す方法）が前提です。

フェーズで設計を変える ― PoC・部門導入・全社展開

ログ設計は固定ではなく、導入フェーズごとに変えるものです。

PoC段階の目的は「動くか、価値があるか」の見極めです。対象業務と利用者を限定し、本番データは使わないかマスキングし、詳細ログは短期保存で構いません。ただし、token数と処理時間だけは必ず記録してください。ここが無いと本番展開の費用を見積もれません。成功・失敗の理由は人が分類します。

部門導入段階では、部署別コストの見える化、タスク別成功率と人手修正率の記録を始め、承認が必要な処理を分類し、詳細ログの保存期間とアクセス権限を正式に決めます。

全社展開段階では、ログポリシーを社内規程にし、監査ログと開発ログを分離します。高リスク業務は詳細ログを強化し、低リスク業務はサンプリングに切り替え、コスト上限アラートと経営向けKPIダッシュボードを整えます。

サンプリングという選択肢

「全部取るか、取らないか」の二択ではありません。通常の成功ログは5〜10%だけ詳細保存し、失敗ログ・高額実行・セキュリティ警告が出たログは100%残す。リリース直後だけ詳細ログを増やし、安定稼働後は絞り、障害時だけ一時的に粒度を上げる。運用フェーズに応じてログの粒度を変えることが、コストと安全性を両立させる現実解です。

運用ルール例と、やってはいけない設計

社内ルールのたたき台にできる例を挙げます。メタデータログは1年以上保存する。プロンプト全文は原則30日以内に削除する。顧客情報を含むログは自動でマスキングする。APIキー・パスワード・認証トークンは保存禁止にする。本文ログの閲覧は管理者と調査担当者に限定する。月次で部署別のAI利用コストを確認し、高額利用・異常利用・失敗率の上昇にアラートを設定する。

逆に、やってはいけない設計の典型は次のとおりです。

• 全プロンプトを永久保存する
• RAGで参照した文書の本文をすべてログにコピーする
• 監視サービスに全量の詳細ログをそのまま流し込む
• 本番データを使ったPoCなのにログ方針を決めていない
• token数を記録せず、後から費用分析ができない
• セキュリティ目的と品質改善目的のログを同じ場所に混ぜる
• ログを取っているのに、誰も見ていない

見る人と見る頻度が決まっていないログは、コストだけを生み続けます。

導入前の会議で決めること、PoCで測ること

ここまでの内容は、そのまま社内会議の議題になります。

• 1. 対象業務の確認――どの業務で使うか、顧客情報・個人情報・契約情報を扱うか、外部システム連携はあるか
• 2. ログ取得の目的確認――監査・障害調査・品質改善・費用管理・セキュリティ監視のどれを重視するか
• 3. 必ず残すメタデータの決定――実行ID、利用部署、タスク種別、使用モデル、token数、成功・失敗、概算コストなど10項目
• 4. 保存してはいけない情報の確認――APIキー、パスワード、認証トークン、顧客名、個人情報、契約書・メール・添付ファイルの本文
• 5. 保存期間の決定――メタデータは1年以上、詳細ログは7〜30日、機密を含み得るログは原則保存しない、調査用ログは調査完了後に削除
• 6. 閲覧権限の決定――メタデータと詳細ログをそれぞれ誰が見られるか、誰が削除できるか、委託先に見せる範囲
• 7. 月次レビュー項目の決定――部署別の利用回数とコスト、タスク別成功率、失敗率、人手修正率、高額利用やセキュリティアラートの有無

PoCでは、精度だけを見てはいけません。「できた・できない」ではなく、業務として成立するかを次のKPIで測ります。

本番展開の判断材料は、成功率・修正率・token数・エラー率・承認率です。この数字が揃って初めて、費用対効果を議論できます。

まず何から手を付けるか ― 行動リスト

明日やること

• AIエージェントで扱う業務を低・中・高リスクの3つに分類する
• それぞれで保存してよいログ・いけないログを決める
• メタデータとして必ず残す項目を10個決める
• 詳細ログの保存期間を仮決めする
• ログを見られる人を決める

今月やること

• PoC用のログ設計表を作る
• token数と概算コストを集計する
• 失敗ログを分類する
• プロンプト全文の保存可否を法務・セキュリティ部門と確認する
• 本番導入前のログレビュー会を設定する

本番導入前にやること

• ログポリシーを文書化し、マスキングルール・保存期間・アクセス権限を決める
• コスト上限アラートを設定する
• 月次レビューの担当者を決める

AIエージェントのログは、取らないと危険です。しかし、全部取れば安心というものでもありません。本当に必要なのは、あとから説明できる最低限の情報を残すことです。誰が使ったのか。何の業務に使ったのか。どのモデルを使い、いくらかかったのか。成功したのか、失敗したなら原因は何か。人間の承認は必要だったのか。機密情報は残していないか。この問いに答えられる状態を作ることが、AIエージェント時代のログ設計です。ログはただの記録ではなく、AI活用を安全に広げるための、管理・改善・説明責任の土台です。

DSB Consultingでは、AIエージェント導入に向けたログ設計・コスト管理・監査対応の体制づくりをPoCの段階から支援しています。自社のログ設計をどこから始めるべきか迷ったら、無料相談をご利用ください。