概要
severityと「消してよいか」は別の軸
INFOの中に無条件で消してよいノイズと規程上消してはいけない監査ログが混在している。severityという一次元の基準だけで取捨選択すると両方を巻き込む。
「消す」以外に「安価な場所へ転送する」
Cloud Loggingへの取り込みを避けたいログでも、BigQueryシンクへルーティングすれば従量課金は避けつつ保持要件は満たせる。
フィルタで隠すのではなく根本原因を直す
本番で常時DEBUG出力が有効なままという設定ミスを、Cloud Logging側のフィルタだけで対処しようとすると根本原因が温存される。
金額差が僅かならリスクの質で選ぶ
Bad案とGood案の月額差はわずか900円。このレベルの差であれば、コンプライアンス・可観測性を満たす側を選ばない理由がない。
問題
ECサイト MOps チームのシニアエンジニアとして、注文連携サービス（order-sync-service、GKE上で常時稼働）の Cloud Logging コストレビューを任された。後輩エンジニアが「Cloud Loggingへの取り込みをERROR以上のみに絞れば、コストはほぼゼロにできる」という Bad コスト比較メモを作成し、来週のインフラ定例でこのまま提案する予定だという。
以下の Bad メモから 試算・設計上の問題（7点）を洗い出し、現行コストの再検証・Bad案の実質評価（コンプライアンスリスク込み）・ログ種別ごとの対処方針を分けたGood案設計・現状/Bad案/Good案の3案比較・実装工数とROI・インフラ定例への推奨文までを一気通貫で回答してください。
制約・前提条件
- Cloud Logging 料金前提（東京リージョン想定、本問固有の単純化ルール）: 無料枠50GiB/プロジェクト/月 / 超過分$0.50/GiB / 為替1USD=150円 / BigQueryアクティブストレージ$0.02/GiB/月 / Log Router除外フィルタ設定・BigQueryへのログシンク自体（ルーティング）はいずれも無料
- order-sync-service の過去30日のログ内訳（合計2,400GiB/月）: ヘルスチェック/readinessアクセスログ(INFO) 1,050GiB(43.75%) / DEBUGペイロード全文ダンプ(本番常時有効) 900GiB(37.5%) / 注文ステータス遷移ログ(INFO、財務監査・カスタマーサポート照会のため保持が社内規程で必須) 300GiB(12.5%) / WARN/ERRORログ(DataDogアラート連携) 150GiB(6.25%)
- エンジニア単価: 80万円/月（160時間=5,000円/時間、人日換算4万円/人日）。実装工数(除外フィルタ設定・ログレベル切替・BigQueryシンク設定・コンプライアンス確認): 4人日
期待する回答形式: 問題点の列挙（番号付き） + 現行コスト再検証 + Bad案の実質評価(表面上のコスト試算＋見落としているコンプライアンスリスク) + ログ種別ごとの対処方針を分けたGood案設計とコスト試算 + 現状/Bad案/Good案の3案比較 + 実装工数とROI + インフラ定例への推奨文
悪いコスト比較メモ (Before)
このメモには 7つの問題 が隠れています。見つけてみてください。
Bad メモ — severity一律除外、コンプライアンスリスク未検討
件名: order-sync-service Cloud Loggingコスト削減のご提案
現状: 過去30日のCloud Logging取り込み量は月間2,400GiBあり、
無料枠(50GiB/月)を大幅に超過してコストが発生している。
← 問題④: 「INFO以下を消せばほぼゼロ円」試算が甘い
改善案: severityフィルタでERROR以上のみを取り込む設定に変更する
現状のログはほとんどがINFO/DEBUGレベルであり、これらを
Cloud Loggingへ取り込まないようにすれば、取り込み量は
ほぼゼロに近づき、コストもほぼゼロにできる。
← 問題①②③: severityと「消してよいか」が別の軸であることを
考慮せず、監査ログ・ノイズ・DEBUGを一緒くたに扱う
よってseverityフィルタでINFO以下を一律除外する設定へ
アプリケーションコードを変更することを提案します。
← 問題⑤⑥⑦: 転送という選択肢・低リスクな除外フィルタ・
コンプライアンスリスクの金額比較がいずれも欠如問題点サマリー（7点）
1severityによる一律除外で、監査要件必須の注文ステータス遷移ログ(300GiB)も一緒に消える
2ヘルスチェックログ(1,050GiB)は内容(パス)で判別すべきノイズであり、severityだけでは狙って除外できない
3DEBUGペイロード全文ダンプ(900GiB)が常時有効のまま放置されている根本原因を見直していない
4「INFO以下を消せばほぼゼロ円」の試算が甘く、WARN/ERRORだけで無料枠50GiBを超えコストは発生する
5「消す」以外に「安価な場所(BigQuery)へ転送する」という選択肢を検討していない
6コード一括変更を前提にし、無料・即日・低リスクなLog Router除外フィルタを検討していない
7コスト削減額のみに着目し、コンプライアンスリスク・可観測性低下という定性的コストを比較していない
ヒント（段階的開示）
ヒント1 — 方向性
Bad メモの罠は3系統。(1) severityという単一の粗い基準だけで「消すログ」を決めており、severityと「消してよいかどうか」が一致しない——INFOレベルの中に、無条件に消してよいノイズ（ヘルスチェックログ）と、社内規程上消してはいけない監査ログ（注文ステータス遷移ログ）が混在している。(2) 「消す」以外の選択肢を検討していない——Cloud Loggingへの取り込みを避けたいログでも、安価な別の保存先（BigQueryなど）へルーティングすれば、コストを抑えつつ保持要件は満たせる。(3) コンプライアンスリスクを金額換算していない——監査ログの喪失は将来の法務対応・監査対応で顕在化する潜在コストであり、目先の削減額だけで判断してはいけない。
ヒント2 — アプローチ
- 問題①: severityで一律除外すると、監査要件で保持必須の注文ステータス遷移ログ（INFO、300GiB）も一緒に消えてしまう
- 問題②: ヘルスチェックログ（1,050GiB）は内容（パス）で判別すべきノイズであり、severityという基準だけでは狙って除外できない
- 問題③: DEBUGペイロード全文ダンプ（900GiB）が本番で常時有効のまま放置されている根本原因（ログレベル設定）を見直していない
- 問題④: 「INFO以下を消せばほぼゼロ円になる」という試算が甘く、WARN/ERRORだけで150GiBあり無料枠50GiBを超えるため、実際にはコストがゼロにはならないことを見落としている
- 問題⑤: Cloud Loggingへの取り込みを避けたいログについて、「消す」以外に「安価な場所へ転送する」という選択肢を検討していない
- 問題⑥: アプリケーションコードの一括変更（severityフィルタ実装）を前提にしており、コード変更不要で即日・低リスクに適用できるLog Router除外フィルタという選択肢を検討していない
- 問題⑦: コスト削減額のみに着目し、監査ログ喪失によるコンプライアンスリスク・インシデント調査時の可観測性低下という定性的なコストを比較していない
ヒント3 — 誘導
【現行コスト再検証】
billable = 2,400GiB − 50GiB(無料枠)
cost = billable × $0.50 × 150円/USD
【Bad案の表面上のコスト】
残すログ = WARN/ERRORのみ(150GiB)
billable = max(0, 150 − 50)
cost = billable × $0.50 × 150円/USD
→ ゼロ円ではない。かつ300GiBの監査ログが消失する
【Good案: ログ種別ごとに対処を分ける】
ヘルスチェック(1,050GiB) → 除外フィルタで完全除外(コード変更不要)
DEBUGダンプ(900GiB) → 本番ログレベルをINFOに変更(常時出力を停止)
監査ログ(300GiB) → Cloud Loggingからは除外しBigQueryシンクへ転送
WARN/ERROR(150GiB) → そのままCloud Loggingに残す問題点分析（7点）
| # | 問題点 | 分類 | 改善方法 |
|---|---|---|---|
| 1 | severity一律除外で監査要件必須ログ(300GiB)も消える | コンプライアンスリスク | 監査ログはBigQueryシンクへ転送して保持 |
| 2 | ヘルスチェックノイズ(1,050GiB)をseverityで判別しようとする | 設計不足 | 内容(パス)ベースの除外フィルタで対処 |
| 3 | DEBUG常時出力(900GiB)の根本原因を放置 | 設計不足 | 本番のデフォルトログレベルをINFOへ変更 |
| 4 | 「ほぼゼロ円」試算が無料枠超過を見落とす | 試算欠如 | WARN/ERRORのみでも無料枠超過分を計算 |
| 5 | 消す以外の選択肢(BigQueryへの転送)を未検討 | 試算欠如 | ログシンクでの低コスト長期保存を比較 |
| 6 | コード一括変更を前提にしLog Router除外フィルタを未検討 | 運用リスク | 無料・即日・低リスクな除外フィルタを優先 |
| 7 | 削減額のみでコンプライアンスリスクと比較せず | 意思決定プロセス | 金額換算した削減額とリスクを同一通貨で比較 |
ログ種別ごとの対処フロー — severity一律除外 vs 種別ごとの個別対処
模範解答
修正④: 現行コスト再検証
| 項目 | 計算式 | 値 |
|---|---|---|
| 月間取り込み量 | 1,050+900+300+150 GiB | 2,400GiB |
| 無料枠控除後 | 2,400 − 50 | 2,350GiB |
| Cloud Logging費 | 2,350 × $0.50 | $1,175 |
| 合計（月額） | $1,175 × 150円/USD | 176,250円 |
内訳の43.75%（1,050GiB）がヘルスチェックの純粋なノイズであり、37.5%（900GiB）が本番で放置されたDEBUG出力である点が、そもそもの最大の改善余地である。
修正①④: Bad案の実質評価
表面上の主張
| 項目 | 計算式 | 値 |
|---|---|---|
| 残るログ（WARN/ERROR） | 150GiB | 150GiB |
| 無料枠控除後 | max(0, 150 − 50) | 100GiB |
| Cloud Logging費 | 100 × $0.50 | $50 |
| 合計（月額） | $50 × 150円/USD | 7,500円（95.7%削減） |
「ほぼゼロ円になる」という主張自体が試算として甘く、実際には無料枠を超える分だけ必ず7,500円/月が発生する。さらにこの案は注文ステータス遷移ログ（300GiB）をCloud Loggingから消してしまう——財務監査・カスタマーサポート照会のため保持が社内規程で必須のログである。severityフィルタでINFOを一律除外すると、この監査ログもろとも失われる。表面上は95.7%削減に見えるが、実際にはコンプライアンス違反（監査要件の未充足）というリスクを、削減額と引き換えに抱え込んでいる。
修正②③⑤: ログ種別ごとの対処方針とROI
| ログ種別 | 月間量 | 対処方針 | 根拠 |
|---|---|---|---|
| ヘルスチェックアクセスログ | 1,050GiB | Log Router除外フィルタで完全除外 | パスベースの純粋なノイズ。K8sのprobe結果は別途イベントとして記録される |
| DEBUGペイロード全文ダンプ | 900GiB | 本番デフォルトログレベルをINFOへ変更 | 常時DEBUG出力は根本原因であり、出力側を直す |
| 注文ステータス遷移ログ | 300GiB | 除外しBigQueryへのログシンクで長期保存 | 保持要件を満たしつつ従量課金対象から外せる |
| WARN/ERRORログ | 150GiB | 変更なし | 障害検知に直結するため取り込み継続 |
| 項目 | 計算式 | 値 |
|---|---|---|
| Cloud Logging取り込み量 | 150GiB(WARN/ERRORのみ) | 150GiB |
| Cloud Logging費 | max(0,150−50)×$0.50 | $50 ≒ 7,500円 |
| BigQueryストレージ費 | 300 × $0.02 | $6 ≒ 900円 |
| 合計（月額） | 7,500円+900円 | 8,400円（現行比95.2%削減） |
- 実装工数（Log Router除外フィルタ設定・ログレベル切替・BigQueryシンク設定・コンプライアンス確認）: 4人日 × 4万円/人日 = 16万円
- 月次削減額（現状比）: 176,250円 − 8,400円 = 167,850円/月
- ペイバック期間: 160,000円 ÷ 167,850円/月 ≒ 0.95ヶ月（約29日）
Bad案と比較した場合の追加コストはわずか900円/月であり、監査要件を満たすための必要経費として無視できる水準である。
現状・Bad案・Good案の3案比較
| 案 | 月額コスト | 監査要件 | 可観測性(DEBUG調査) | 判定 |
|---|---|---|---|---|
| 現状（フィルタなし） | 176,250円 | 満たす | 満たす（常時DEBUG） | コストが過大 |
| Bad案（severity一律除外） | 7,500円 | 満たさない | 満たさない | 表面上最安だがコンプライアンス違反リスク |
| Good案（種別ごとに対処） | 8,400円 | 満たす | 満たす | 最適 |
Bad案とGood案の月額差はわずか900円——このコストで「監査要件の充足」と「障害調査時のログ復元性」の両方を買っていることになる。金額のインパクトがほぼ同等である以上、コンプライアンスリスクを抱えるBad案を選ぶ理由は存在しない。
インフラ定例への推奨文
order-sync-service のCloud Loggingコストは月176,250円発生
しており、内訳の43.75%（1,050GiB）はヘルスチェックの純粋な
ノイズ、37.5%（900GiB）は本番で放置されたDEBUG出力です。
severityフィルタでINFO以下を一律除外する提案（Bad案）は
月7,500円まで削減できますが、同時に財務監査・カスタマー
サポート照会のため保持が社内規程で必須の注文ステータス
遷移ログ（300GiB）も消えてしまい、コンプライアンス違反の
リスクを抱えます。
代わりに、ログ種別ごとに対処方針を分ける設計を提案します：
ヘルスチェックログはLog Router除外フィルタで完全除外
（コード変更不要）、DEBUGペイロードダンプは本番ログレベル
をINFOに変更して常時出力を停止、監査要件のある注文
ステータス遷移ログはBigQueryへのログシンクで低コストに
長期保存します。実装工数16万円に対し、月次コストを
176,250円→8,400円（95.2%削減）にでき、Bad案との差額は
わずか900円/月です。この900円で監査要件の充足と
インシデント調査時の可観測性を両立できるため、
Good案を推奨します。ポイント解説
1severity（ログレベル）と「消してよいかどうか」は別の軸である — INFOの中にも「無条件に消してよいノイズ」と「規程上消してはいけない監査ログ」が混在する。単一の粗い基準（severity）だけで取捨選択すると、両方を巻き込んでしまう。
2「取り込みを避けたいログ」に対する選択肢は「消す」だけではない — 安価な別の保存先（BigQueryシンク）へルーティングすれば、Cloud Loggingの従量課金は避けつつ保持要件は満たせる。
3フィルタで隠すのではなく、根本原因（ログ出力設定）を直す — 本番で常時DEBUG出力が有効なままという設定ミスを、Cloud Logging側のフィルタだけで対処しようとすると、根本原因は温存されたまま複雑さだけが増える。
4コード変更を伴う対応と、設定変更だけで済む対応は、リスクと即応性が全く違う — Log Router除外フィルタは無料・即日・コード変更不要で適用できる一方、severityフィルタのコード実装は全サービス一斉変更というリスクを伴う。
5金額のインパクトがほぼ同等な選択肢が並んだときは、削減額ではなくリスクの質で比較する — 今回はBad案とGood案の差額がわずか900円/月であり、この水準の差であれば迷わずコンプライアンス・可観測性を満たす側を選ぶべきである。
実務への応用
MOpsチームのようにマイクロサービスが多数存在する環境では、ログコストの削減が「取り込み量を減らす」という一次元の問題として捉えられがちである。しかし実務では、ログの内訳（ノイズ／デバッグ用／監査要件のある証跡／アラート用）をまず分解し、それぞれに適した対処方針（除外・出力停止・転送・維持）を個別に決める設計が必要になる。Cloud LoggingのLog Router除外フィルタはTerraformで宣言的に管理でき、google_logging_project_exclusion リソースを使えば、どのログをどんな条件で除外しているかをコードとしてレビュー可能な形で残せる。
証券会社経験との接続: 証券会社の業務では、取引記録・注文記録の保存義務が金融商品取引法等の規制で明確に定められており、「コストがかかるから」という理由だけで記録を安易に廃棄することは許されない。ログを消すという行為は、システムにおける「証跡の消滅」に相当する。今回のBad案のように、コスト削減のためにseverityという粗い基準で監査要件のあるログまで一律に消してしまう判断は、規制業種で証跡管理を経験した感覚からすると典型的な「見えないリスクを金額換算せずに切り捨てる」判断であり、同じ視点をエンジニアリングのコスト最適化にも持ち込む必要がある。
今日のまとめ
ログコスト削減は「取り込み量を一律に減らす」ではなく、ログの内訳（ノイズ／デバッグ用／監査要件のある証跡／アラート用）ごとに対処方針を分けて設計する。今回のケースでは、severityフィルタで一律除外するBad案が表面上95.7%削減（176,250円→7,500円）に見えたが、同時に監査要件のある注文ステータス遷移ログを消失させるコンプライアンスリスクを抱えていた。ログ種別ごとに除外・出力停止・転送・維持を使い分けたGood案は、Bad案とわずか900円/月の差（月8,400円、95.2%削減）で監査要件と可観測性の両方を満たせる。
次のステップ
- 発展問題: Good案の運用開始後、BigQueryへ転送した監査ログ（月300GiB）が半年で1.8TBまで積み上がり、監査ログ専用データセットのストレージコストとクエリコストが無視できない規模になってきたとする。(1) BigQueryのアクティブストレージ（$0.02/GiB）と長期保存ストレージ（90日以上未更新で自動的に安くなる料金階層）をどう使い分けるか、(2) 監査ログの参照頻度（法務からの照会は稀だが、いざという時に高速に検索できる必要がある）を踏まえたパーティショニング・クラスタリング設計をどうするか、(3) 保存期間そのものに社内規程上の上限（例: 7年）がある場合、Cloud Storageへのアーカイブ移行とBigQueryの使い分けをどう設計するか、を踏まえた長期運用方針を提案せよ。
- 参考: Cloud Logging pricing / Log Router exclusion filter / BigQuery sink / ログレベル設計 / structured logging / 監査ログ保持要件