ログ管理ツールの選び方：検索・保持と運用コスト

今のログ基盤が安定して取り込み、必要な検索にも答えられているなら、私は移行より先にクエリと保持方針を見直します。費用の原因は索引の作りすぎかもしれませんし、長期間のスキャン、滞留データの処理、基盤チームが維持している周辺サービスかもしれません。GB 単価だけを下げても、解決できる範囲は限られます。

ログ管理ツールを選ぶ際は、エンジニアが日々行う作業から考える方が分かりやすいでしょう。リクエスト ID を探す、初めて見るエラーを検索する、サービスとリリース別に失敗を集計する。それぞれが異なるデータ経路を使います。書き込みのピークや複数人の障害調査でも、その作業を続けられるか。運用を継続できるかが重要です。

専任のログ基盤担当者がおらず、検索、アラート、アプリケーション調査を早く使えるようにしたいなら、Guance のようなマネージドサービスを先に検討します。Elastic や Loki の運用が成熟し、クエリも構成に合っているチームなら、既存環境の改善に価値があります。以下では収集、検索、保持、継続運用から、その判断を具体化します。

Guance 編集部 · 2026 年 10 月 28 日。公式資料に基づく比較です。発行者の Guance も比較対象に含まれます。容量例は明示した仮定による計算であり、同一負荷での性能測定は行っていません。

エンジニアが実行するクエリから考える

「検索に対応」という機能名だけでは、処理の違いは見えてきません。

Elasticsearch の転置索引は検索中心の用途に向いていますが、フィールドをどう解析するかはマッピングで決まります。message の単語検索と keyword フィールドの完全一致は同じではありません。ここを変えると、移行後の検索結果も変わり得ます。容量に苦しむ既存クラスターでは、動的フィールド、シャード、レプリカ、ライフサイクルを先に確認できます。Elasticsearch のマッピング

採用する配布物と機能のライセンスも確認します。Elastic は対象となる無料ソースコードに AGPLv3 の選択肢を追加しましたが、すべてのバイナリ配布物や商用機能が同じ条件になるわけではありません。Elastic のライセンス

Loki はラベルでストリームを特定し、本文をチャンクに保存します。サービス、環境、クラスターなど安定したラベルで先に絞り込む構成です。変化し続けるリクエスト ID やユーザー ID をストリームラベルにすると、ストリームが増えます。こうした属性は構造化メタデータとして保持できます。本文のフィルタリングは可能ですが、全体を対象にした長期間の文字列検索と、既知のサービス内のリクエスト検索では、必要なスキャン量が違います。Loki の構造化メタデータ

高速化にも適用範囲があります。現在の Bloom クエリ高速化は、条件を満たす構造化メタデータのフィルターを対象にします。Loki と GEL では実験的機能、Grafana Cloud では対象顧客を限定した公開プレビューです。あらゆる LogQL 式を高速化する前提にはできません。クエリ高速化

ClickHouse は列指向の読み取りと集計に加え、26.2 以降では text index が一般提供されています。集計しかできず全文検索はできない、という説明は古くなっています。索引を使えるかは、トークナイザー、索引定義、検索式に依存します。バージョン、テーブル設計、検索の意味を揃えてから、過去データの初回検索と繰り返し検索を比較します。ClickHouse のテキスト索引

これらの仕組みから一律の性能順位は決まりません。いずれもログサービスの基盤になりますが、実行したいクエリによって索引、計算資源、保守の負担が変わります。

処理の場所によって、データが通る経路が変わる

収集側でのフィルタリングと、バックエンドでの破棄は、料金とデータの境界に異なる影響を与えます。送信前に不要なログを除けば、その後の転送と取り込みを減らせます。元のストアに入ってから除いても、発生済みの取り込みと保存は取り消せません。

Guance のローカル Pipeline は DataKit の収集時、中央 Pipeline はデータを中央に送った後で実行されます。時刻解析、型変換、マスキング、フィルターはこの位置を踏まえて設定します。機密情報を元環境から出す前に処理するなら、対象入力をカバーするローカル経路が必要です。元ファイル、バッファー、異常入力も含めて考えます。中央処理は共通ルールの運用に便利ですが、過去の送信を元に戻すものではありません。Pipeline の実行場所

SLS のデータ変換ジョブは、元の Logstore から読み、処理した結果を送信先 Logstore に書きます。現行の新バージョン資料も、ジョブ内のフィルタリングでは元 Logstore の課金対象取り込み量が減らないと説明しています。この量を減らすには、収集段階のフィルターを使います。Guance と比較する際も、処理の場所、通過する入力、失敗した記録の行き先まで追うと違いを理解できます。SLS データ変換

フィールドの整理は調査にも影響します。時間を表す値が文字列なら、文字列の並び順を数値比較の代わりにはできません。イベント時刻を正しく解析しなければ、遅れて届くログが別の時間帯に現れることもあります。正常値、欠損、多行、異常な時刻を含む少数のサンプルを残すと、形式変更の影響を追いやすくなります。この業務上の約束事は、マネージドサービスでも維持が必要です。

アクセス方法で保持期間を分けてから容量を計算する

すべてのログを同じ期間残す設定は、始めるには簡単です。ただし、監査、日常のデバッグ、頻繁な障害調査で、同じ検索履歴が必要とは限りません。

毎日 200 GB の生ログが発生し、80% は 3 日、20% は 30 日必要とします。継続して書き込み、定常状態になったときの保持量は次のとおりです。

すべてを 30 日保持：200 × 30 = 6,000 GB
必要な期間で分割：200 × (80% × 3 + 20% × 30) = 1,680 GB

これは生データに相当する保持量です。圧縮、索引、レプリカ、作業領域、アーカイブ料金を含まず、製品の見積もりでもありません。保持要件を整理した後でバックエンドを比べると、購入する容量自体が変わることを示しています。あるエンジンの圧縮率を、他のサービスの請求にそのまま適用することはできません。

Guance の通常ログ索引は順番に条件を評価し、最初に一致した索引が使われます。保持とアクセスの要件による振り分けに利用できます。現在の通常索引の上限は default を含めて 6 個で、追加作成には有効化の申請が必要です。アプリごとに索引を増やすより、ソース、サービス、環境はフィールドに残す方が扱いやすくなります。ログ索引

長期保持の利用方法も重要です。Guance の標準保存期間内は任意の時間範囲を検索できますが、長期保存の一回の検索は最大 24 時間です。一日の監査記録を時々取り出す用途と、毎月全体を集計する用途では、選ぶ保存方法も変わります。データ保存方針

取り込む GB と索引に残すイベント数を分ける

商用 SaaS とクラウドのログサービスはバックエンド運用を減らしますが、同じ単位では課金しません。取り込み、索引イベント、スキャン、アーカイブ復元、処理、通信は別料金になることがあります。Elastic Cloud Hosted と Serverless の購入方法も異なります。提案されたサービス形態を決めてから料金表を使います。Elastic の料金

Datadog はログの取り込みと索引を区別します。「毎日 50 GB」だけでは計算できません。各イベントが 1 KB（10³ バイト）なら約 5,000 万件、4 KB なら約 1,250 万件です。同じバイト量でも件数は 4 倍違い、索引に残す割合と期間で費用がさらに変わります。この例では GB = 10⁹ バイト、KB = 10³ バイトとし、実際にはイベントサイズの分布を使います。Datadog のログ課金・ログの計量と料金

Datadog Standard 索引のイベントを減らしても、取り込みは取り消されません。対象外のログを後から探せるかは、別途設定したアーカイブなどの経路次第です。復元時間と料金も利用要件に合わせます。ログ索引とフィルター

Flex は保存と検索の別の選択肢で、計算資源と保存を分けて設定できますが、現在はモニターのクエリに対応していません。履歴を Flex に残しても、Standard のログ監視の動作がそのまま保たれるわけではありません。索引費用とともに、検索できる記録と実行できるルールを考えます。Flex Logs の範囲

SLS、CloudWatch Logs、Azure Monitor Logs、CLS も経路全体で計算します。単一クラウドを中心にするチームは、既存の ID 管理、リソース収集、対応手順を利用できるため、導入作業を減らせます。他クラウドやオンプレミスのソースも取り込める場合がありますが、ネットワーク、認証情報、外部転送、アカウントをまたぐアクセスには追加の費用と運用が伴います。

ログを見つけた後の調査までつなぐ

ログ監視ツールでは、保存と検索に加え、検出結果を当番の対応に渡す必要があります。サービス、環境、状態で分類するルールは安定したフィールドに依存し、評価窓と遅延データの関係は通知時刻に影響します。アラート件数だけを減らし、必要な証拠が別の時刻に散ったままでは、作業は完了しません。

Guance では共通の trace_id によってログとトレースを関連付け、関連ホスト、コンテナ、Pod へ調査を進められます。必要な信号がすでに収集され、ID と時刻が揃い、遷移先のデータが保持されていることが前提です。既存の画面遷移は、自作リンクや複数の権限体系をつなぐ作業を減らします。アプリケーション側では引き続き業務の文脈を残します。ログとトレースの関連付け・トレース詳細

Elastic、Loki、ClickHouse で同じ流れを作ることも可能です。収集、クエリ画面、通知、ID と認可、更新、復旧をどう組み合わせ、誰が維持するかまで費用に含めます。基盤チームに成熟した構成があるなら、追加作業は小さいかもしれません。業務運用の担当者が新たに引き受けるなら、ゼロとしては扱えません。

AI 支援は証拠の整理や記録を読む負担を減らせますが、説明には元イベントが必要です。セキュリティ検知も共通ストレージだけでは完成せず、ルール、脅威情報、ケース対応、応答連携に独自の範囲があります。外部への自動操作には権限、失敗処理、復旧方法が必要です。データを再利用しても、求める成果はそれぞれ定義します。

移行の価値は、やめられる運用で判断する

まず、現在のシステムで解決できる問題はそこで解きます。Elasticsearch のマッピングとライフサイクル、Loki のラベル、収集側フィルター、保持方針は、移行の前に改善する価値があります。必要なクエリが安定して動き、月額差では変更作業を回収できないなら、現状維持も合理的です。

基盤を管理したいチームが容量、更新、復旧を継続して担えるなら、自社運用には価値があります。データと対応手順が一つのクラウドに集まる場合は、そのクラウドのログサービスが簡単かもしれません。専任のバックエンド担当者なしで、ログ、アラート、信号をまたぐ調査を早く提供したいなら、Guance を一つの完成したサービスとして比較します。 実際に省けるバックエンド運用と接続作業が、その価値です。

ログを自社環境に置く必要がある場合は、そこで提供できる配備方法を先に選びます。Guance の Deployment Plan も自社運用のエンジンも、顧客側の資源と運用分担を計算する必要があります。SaaS 単価はプライベート配備の見積もりにはなりません。バックアップ、サポート担当者のアクセス、外部呼び出しもデータ経路に含めます。Guance の配備方法

同じ範囲で費用を整理します。

月間運用費 = 製品の使用料 + 継続するインフラ + 運用・サポート
           + 追加のクエリ・復元・ネットワーク費用
初年度費用 = 12 × 月間運用費 + 一度限りの移行・並行稼働費用

工数と現金支出は分け、既存投資を新たな購入費として二重に数えません。残る収集機構、業務フィールド、クエリ、アラート、過去データへのアクセスを差し引いて移行効果を見ます。標準プロトコルは取り込みを助けますが、これらの資産までは自動で移しません。

Guance、商用 SaaS、自社運用、クラウドサービスのいずれも、必要なクエリ、保持、提供範囲で見積もります。同じ仕事を満たしたうえで、継続的な負担を減らし、予算とデータの配置要件に合うものが、採用する価値のあるログ基盤です。