多くの大企業は、自社システムが生成するログデータの大半を意図的に破棄しています。コスト削減が主な目的です。Dynatraceが大企業450社のITシニアリーダーを対象に実施した調査によると、半数の組織がフィルタリングや集約処理を行った後でも、平均86%のログを収集していないか、または破棄していることが明らかになりました。また、保持するログの保存期間を制限している企業も多数あります。
しかし、こうした判断はそれ自体がセキュリティ上のコストをもたらします。
インシデント調査におけるログの役割
ログとは、アプリケーションやインフラ内部で起きたことの記録です。エラー、イベント、アクションを時系列で記録するため、脅威ハンティング、インシデント対応、フォレンジックの基礎資料となります。組織がサイバーフォレンジックを実施したりセキュリティ調査を行ったりする際、最初に参照するのがログデータです。調査対象の企業においても、セキュリティ調査はログの最も一般的な用途の一つとして挙げられています。
こうしたデータの大半を削除したり、短期間で消去したりするという判断は、この作業に直接影響を及ぼします。侵害は、誰かが気づくまでに数週間から数ヶ月にわたって検知されないことがあります。アラートがようやく届き、調査担当者が証跡を追い始めた時点で、関連するログエントリはすでにサンプリング除外や削除によって失われている可能性があります。証拠は消え去り、削除を決定したコスト管理担当者は、しばしば異なるチームに属し、異なる目標のもとで動いていたのです。
意思決定はセキュリティ部門の外で行われる
ログの保持と収集の管理は、通常オブザーバビリティ、プラットフォームエンジニアリング、あるいはコスト管理部門が担当しています。これらのチームは支出目標に対して責任を負っています。今回の調査では、3分の2の組織がログ管理にかかるコストが得られる価値を上回っていると回答しており、ほとんどの組織が過去1年でログコストが増加したと報告しています。大企業1社あたりのロギングツールへの支出は年間平均250万ドル近くに達し、オブザーバビリティおよびモニタリング予算のおよそ半分を占めています。
このような費用を前にすると、各チームは削減に動きます。ストレージの保存期間を制限し、一般的なログの一部をサンプリングし、繰り返しと判断したデータカテゴリの収集を停止するのです。こうした措置のたびにコストは下がります。そして同時に、インシデント発生後にセキュリティチームが頼るべき視界も狭まります。
AIがコスト圧力をさらに高める
このコスト圧力には明確な要因があります。AIワークロードを運用している組織では、過去1年でログとテレメトリのデータ量が急増しているという報告が相次いでいます。データが増えれば収集・保存・クエリのコストも上昇し、コスト削減の圧力はさらに強まります。AIはすでに存在していたコスト問題を悪化させ、削除につながる状況を加速させています。
同時に、これらのワークロードが増えることで、失われる可視性の影響はより深刻になります。AIシステムの挙動は予測が難しく、ある出力がなぜ生成されたかを理解するには、入力、実行した呼び出し、アクセスしたサービスの詳細な記録が不可欠です。多くの組織はすでに、自社のAIアプリケーション内部で起きていることの一部しかログに記録されていないと認識しています。さらに多くの記録を破棄すれば、手元に残る情報はいっそう少なくなります。
ログを読み書きするAIエージェント
今回の調査には、コスト削減の議論に埋もれがちなセキュリティ上の問題を示す点があります。AIエージェントはログを書き込み、かつ読み込みます。これにより、ログデータはソフトウェアとその運用者の間で共有される「共通言語」となります。ログを消費してその内容に基づいて行動するエージェントは、攻撃の標的になり得ます。
改ざんされたログエントリや不正に挿入されたログエントリは、自動化されたシステムを誤った行動へと誘導する可能性があります。調査ではトレーニングデータへのポイズニングが一部の回答者の懸念事項として挙げられていますが、エージェントが消費するログとの関連性については踏み込んでいません。セキュリティチームが自ら掘り下げるべき課題として残されています。
誰が意思決定するかという問題
実務上の問題はガバナンスにあります。ログを削除する担当者と、インシデント発生時にそのログを必要とする担当者は、しばしば別々の人物であり、異なる目標のもとで評価されています。組織がインシデント調査に必要なテレメトリを保持していると思い込んでいるセキュリティリーダーは、実際に何が収集・削除され、保存期間がどのくらいかを確認しておくべきでしょう。多くの企業では、その答えは想定よりはるかに少ないはずです。
翻訳元: https://www.helpnetsecurity.com/2026/06/19/report-log-management-security-risk/
