月1回のFinOps習慣 チームで進める不要リソース削除活動

クラウドコストは放置すると静かに増え続けます。検証用インスタンスや消し忘れたスナップショットなど、小さな放置の積み重ねが大きな無駄になります。四半期や年次のまとめレビューでは、気づいたときには数十万円規模になっていることも少なくありません。そこで、月1回・15分でチームが不要リソースを見直す活動を提案します。目的は単発の削減ではなく、日常の「習慣」にすることです。

月次なら差分が小さく負担も軽いため、自然と日常業務の一部になっていきます。

見直し対象は、放置されたインスタンスや検証環境、未アタッチのディスク、古いスナップショットやバックアップ、未使用の固定IPやロードバランサー、期限切れの一時リソースなどです。

進め方は、コストレポートで増加項目を確認し、未使用リソースをリストアップ、持ち主に確認のうえ反応がなければ削除します。削減額や件数は記録し、翌月以降の比較に使います。

担当者任せは形骸化しやすいため、チームで取り組むことが重要です。作った本人が最も正確に要・不要を判断できるため、全員が当事者になることで削減と発生防止の両方につながります。成果の共有は継続のモチベーションにもなります。

継続すれば無駄の積み上がりを防ぎ、棚卸しの負担も分散できます。チームのコスト意識も高まり、FinOps文化として定着していきます。運用のコツは、チェックリストのテンプレート化、削除前の持ち主確認の徹底、そして完璧を求めず「気づいて話題にする」ことを優先する姿勢です。

Transcript

1. FinOps 月1回のFinOps習慣 チームで進める不要リソース削除活動 2026
2. アジェンダ 2
3. A G E N D A 目次 01 02 03 自己紹介 FinOpsとは 現状の課題 04 05 06 自動通知の仕組み 文化醸成 活動全体 07 まとめ 3
4. 自己紹介 2
5. 自己紹介 発表者のバックグラウンドと本日のテーマ T.REX X：@ukrock1996 主な業務 自動化ツールの開発 AI エージェントの設計・開発 FinOps の技術文化醸成 5
6. Fin Opsライフサイクル 2
7. 01 / POSITIONING 位置づけ：FinOpsライフサイクルの「Operate」フェーズ Inform（可視化）→ Optimize（最適化）に続く3つ目のフェーズ。仕組みを日々の運用に定着させる段階 Operate フェーズとは コスト最適化を「一度きりの施策」で終わらせず、継続的なプロセスとして日々の運 用に組み込む段階。自動化・定例化・体制づくりがテーマになる 本活動の位置づけ 「月1回、不要リソースを棚卸し・削除する」仕組みは、Operateフェーズを体現する 継続的改善サイクル。Informで得た可視化データを、実際の削減アクションへ定着さ せる • Inform ／ • Optimize ／ • Operate ← 今回の活動 Inform・Optimize の成果を、Operate として毎月の運用に定着させる取り組みです 4
8. 現状の課題 2
9. 02 / CHALLENGE 課題①：最適化以前に眠る、大量のスナップショット・検証リソース レートや使用量を最適化する以前に、そもそも「使われていないリソース」が積み上がっている実態がある スナップショットの放置 検証環境の作りっぱなし 重複・世代管理の欠如 検証・移行のために取得したEBS/RDS等の スナップショットが、取得目的を終えて も残り続ける 開発・検証用に立てたインスタンスやDB 環境が、検証終了後も停止・削除されな いまま残る 同じ用途のバックアップや複製が世代を 重ねて溜まり、どれが必要か誰も把握し ていない レート最適化や使用量の見直しは、「使っていないものが放置されていない」状態が前提になる だからこそ、Optimizeの前段として、Operateフェーズで「棚卸し→削除」を仕組み化する必要がある 6
10. 02 / CHALLENGE 課題②：ツールの推奨をそのまま削除すると、整合性が崩れることがある コスト管理ツールは「クラウド上でデタッチ済み」を根拠に推奨するが、上位のオーケストレーション層ではまだ管理されている場合がある Cost Optimization Hub 側の見え方 Kubernetes 側の実態 ≠ EBSボリュームが EC2 から「デタッチ済み（available）」→ 未使 用と判定し、削除を推奨 PV／PVCとしてはまだ Bound。Pod が一時的にスケジュールされ ていないだけで、K8s 上は「使用中」の扱い AWS のAPI上は削除できてしまうが、K8s 側のPV／PVCオブジェクトは残ったまま。次回のPod起動でエラーになったり、データを失う リスクがある 対応策 削除前に PVC／PV の Bound 状態と Reclaim Policy を確認する 可能な限り K8s 側（PVC 削除）から解放し、結果として EBS を削除させる ツールの推奨は「一次候補」とし、機械的に全削除しない 7
11. 自動検知の仕組み 2
12. 03 / ARCHITECTURE 自動検知の仕組み：Kubernetes上の構成 CronJobがCUR・Cost Optimization Hub・Rancher・各種APIを参照し、未使用リソースを自動判定してJiraへ起票する Amazon Athena（CUR） Kubernetes Namespace： finops-tools コスト使用データを SQL で照会 CronJob 毎日 1 回 起動（スケジュール実行） Cost Optimization Hub API EBS 等の削除推奨候補を取得 棚卸しスクリプト（Job Pod） CUR／Cost Optimizer／Rancher／各種API を参照し、削除候補 を判定 ⇅ すり合わせて特定 Rancher API ④ 自動起票 PVC／PV 状態を確認し、推奨結果とすり合わせ 参照 全条件を満たした削除候補だけを ConfigMap Secret クエリ・閾値等の設 定 認証情報（各APIトー クン） CloudWatch API 、チケットとして自動起票（Week2 チケット化へ） メトリクスの利用実績を確認 CloudTrail API API 操作履歴を確認 8
13. 巻き込み方 2
14. 04 / ENABLEMENT 巻き込み方：プロダクトオーナーを介して現場を動かす FinOpsオーナーが棚卸しはするが、削除を直接指示はしない。プロダクトオーナーを巻き込み、現場が自律的に動ける体制にする ① 検出結果を共有・相談 プロダクトオーナー FinOpsオーナー ② チームとして対応を依頼 チームを巻き込み、対応を依頼 支援・情報提供 未使用・不要リソースを棚卸し 開発者・運用者 （クラウド利用者）要否を判断し、自ら削 除 9
15. 05 / OVERVIEW 活動の全体像：月1回、4つのステップで回すサイクル 検出 → チケット化 → 削減実施 → アナウンス。毎月このサイクルを止めずに回す Week 1 検出 FinOpsオーナーが未使用・不 要リソースを洗い出す Week 2 › チケット化 Jiraで起票し、作成者・担当 者へアサインする 月初 Week 3-4 › 削減実施 担当者が要否を判断し、削除 ・整理する › アナウンス 前月の削除金額をチームへ共 有する 毎月このサイクルを繰り返すことで、不要リソースを溜め込まないチームをつくる 10
16. 06 / WEEK 1 Week1：FinOpsオーナーが未使用・不要リソースを検出 コスト管理ツールとタグ情報をもとに、削除候補をリストアップする 検出の観点 担当：FinOpsオーナー 直近30日以上アクセス・稼働がないリソース 未使用・不要リソースの一次検出リストを作成し、 Week2のチケット化へ引き継ぐ タグ（Owner／用途）が未設定のリソース ・対象リソース一覧（種別・作成者・推定月額） ・検出日・最終利用日 停止中インスタンスや未アタッチのボリューム／IP ・削減候補としての優先度 検証・一時利用目的で作成されたリソース 11
17. 07 / WEEK 2 Week2：Jiraでチケットを起票し、担当者へ依頼 検出結果を1リソース＝1チケットで登録し、作成者へ判断を依頼する チケット起票 担当者アサイン 対応期限の設定 リソースID・種別・推定月額コスト・検 出理由を記載して1件ずつ登録 タグやCloudTrail等の作成者情報から担当 者を特定し、チケットを割り当て Week3-4末までの対応期限を設定し、削 除 or 継続利用の判断を依頼 チケット記載例：「[FinOps] EC2インスタンス i-0xxxx（月額 ¥8,200）／最終利用 45日前／2/28までに要否をご回答ください」 12
18. 08 / WEEK 3-4 Week3-4：担当者が要否を判断し、削減を実施 作成者本人が「使うか・消すか」を判断し、責任を持って対応する 継続利用と判断 用途を明確化し、Owner タグを更新。次回以降の棚卸し対象か ら一時除外 不要と判断 担当者自身が削除を実施。削除内容と削減見込み額をチケット に記録 ポイント：削除するのはFinOpsオーナーではなく、リソースを作った本人。「自分ごと」として扱うことで削減が定着す る 13
19. 09 / MONTHLY REPORT 月初：前月の削除金額をチームへアナウンス 成果を可視化し、次のサイクルへのモチベーションにつなげる 削減金額のハイライト 前月の削除総額と、累計削減額の推移をあわせて共有 前月の削減実績 チーム別・貢献の紹介 ¥◦◦◦,◦◦◦ 対応が早かったチームや担当者を称賛し、活動を前向きに定着 削減リソース数：◦◦件 ／ 対応チーム数：◦◦チ ーム 未対応チケットの棚卸し 期限を過ぎたチケットを翌サイクルへ引き継ぎ、対応を継続 ※実績値はダッシュボードから月初に自動集計 14
20. 10 / KEEP GOING 毎月止めない：サイクルを継続させる3つのポイント 仕組みとして定着させ、「気づいたときだけ」の棚卸しにしない 固定サイクルで動かす 責任範囲を明確にする 結果を毎回可視化する 曜日・週番号をあらかじめ決め、 検出はFinOpsオーナー、削除は作成 削減額を月初に必ず共有し、活動 毎月同じリズムで検出〜削除まで 者本人と役割を分け、迷いなく動 の効果を全員が実感できるように を回す ける状態にする する 15
21. A G E N D A まとめ 検出 チケット化 削減実施 アナウンス FinOpsオーナーが月1回、未使 用・不要リソースを洗い出す Jiraで担当者へ依頼し、対応期 限を明確にする 作った本人が判断し、自ら削除 ・整理する 月初に前月の削減額を共有し、 次月へつなげる 不要リソースの削除を「特別な棚卸し」ではなく、毎月あたりの行動として回るチームの習慣にする 16