はじめに

こんにちは。株式会社リクルートデータ推進室の菅沼と鈴木です。私たちは、プラットフォームチームとして、社内のデータアプリケーション開発プラットフォーム Knile の開発・運用を担当しています。

2025年10月17日に開催された Google Cloud Modern Infra & App Summit ‘25 Fall にて、「事業の財務責任に向き合うリクルートデータプラットフォームの FinOps」と題して発表を行いました。

本記事では、その登壇の中でお話しした Knile における FinOps の実践、特にコスト最適化の取り組みと、その過程で直面した課題と決断に関する内容をご紹介します。

発表スライド

発表に使用したスライドを公開していますので、ご覧ください。

Knile の歴史

リクルートのデータ組織は、各事業領域に対応する「事業データ組織」と、事業を横断して利用可能なシステム（横断プロダクト）を提供する「横断データ組織」で構成されています。

Knile は横断プロダクトの一つです。2015年に事業領域内のデータ活用チーム向けに開発が始まり、その後提供範囲が拡大し、2021年の組織再編を経て横断プロダクトとして提供されるようになりました。

発表時点で、6つの事業領域で250以上のデータ活用施策が実施され、300人以上のデータアプリケーション開発者に利用されているプラットフォームです。これを 5人以下のプラットフォームチームで開発・運用しています。

利用拡大にともなって顕在化した課題

複数の事業領域に提供範囲が拡大する中で、以下の課題が顕在化しました。

1. コスト増・不透明性
   Knile はマルチテナント構成を採用していたため、どの事業施策にどれだけのコストがかかっているのか、利用者もプラットフォームチームも把握できていない状態でした。

2. 費用負担の不公平さ
   当初は全社コストとして賄われていたため、利用組織のコスト意識が低い状態でした。その後、利用組織へのコスト請求が導入されましたが、内訳が不明なため固定費として請求せざるを得ず、利用量の増減と請求額が連動していませんでした。

また、全社的な経営方針により横断プロダクトのコスト効率がより重要なテーマとして位置付けられた時期でもありました。これらの背景から、Knile では FinOps の導入に取り組み始めました。

Knile における FinOps の導入

FinOps とは

FinOps の定義は以下の通りです。

FinOps is an operational framework and cultural practice which maximizes the business value of cloud and technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.

— FinOps Foundation “What is FinOps?"

（FinOps とは、クラウドのビジネス価値を最大化し、タイムリーなデータ主導の意思決定を可能にし、エンジニアリング・財務・ビジネス チームの連携を通じて財務責任を生み出す運用フレームワークおよび文化的実践です。）

3つのフェーズに基づく取り組み

FinOps Foundation が提唱する3つの実行フェーズに基づき、Knile では以下の取り組みを実施しました。

• Inform フェーズ: クラウド利用料を含む全ツールの利用変動費や固定費を様々な粒度で集計し、導入組織やデータ活用施策単位で従量に基づいたコスト可視化・レポーティング、課金請求が可能な仕組みを構築
• Optimize フェーズ: 可視化された情報とリソース Usage 情報に基づいて浪費を特定し、コスト削減の優先度を決めて実行計画を推進
• Operate フェーズ: Low effort, low savings の取り組みから着手し、徐々に利用者も巻き込んだ High effort, high savings の取り組みへと展開

※導入時の設計・実装の詳細は Cloud Next Tokyo ‘24 登壇資料参照: マルチテナントな Internal Developer Platform における FinOps の設計と導入 | Speaker Deck

FinOps 導入の成果

これらの取り組みにより、既存の品質を維持したまま、2024年1月 → 2025年1月の比較で Knile 全体のコストを 40.5% 削減できました。

さらに、Inform フェーズで得られた詳細なコスト情報により、Knile で発生するコストに対する解像度が飛躍的に上がり、事業領域側はより高い水準でコスト効率化の目標を設定できるようになりました。これは FinOps が定義する「組織文化の変革」のキッカケとなる重要な変化と言えます。

新たに見えてきた課題

コストの可視化によって事業領域側がより高い水準のコスト効率化を目標として設定できるようになった結果、さらなるコスト削減が求められるようになりました。しかし、横断プロダクトとしての Knile では、以下の課題により、これ以上の効率化を進めることが難しい状況でした。

1. コスト最適化の取り組みが全ての事業に影響するため、検証・承認に時間がかかる
2. 横断プロダクトとして運営するための要件（課金請求機能、厳格な権限分離など）の実現・運用に工数がかかり、コスト最適化のための工数を確保しにくい

横断プロダクトからの脱却

これらの課題を踏まえ、「そもそも横断プロダクトでなければ発生しない課題では？」という仮説を立てました。

そこから様々な選択肢を検討し、各事業データ組織との議論を重ねた結果、横断プロダクト Knile で実現していたものを、事業ごとの専有プラットフォームとして作りかえるという決断をしました。

横断プロダクトとしての Knile の利用が最も多い事業には Knile をプロダクトごと移管し、その事業専有のプラットフォームにすることにしました。他の事業に対しては、事業ごとの規模や特性を踏まえて機能を最適化した独自の事業専有プラットフォームを新たに設計し、横断組織が全面的に事業専有プラットフォームへの移管を支援・サポートしています。

決断による変化

Knile を事業専有のプラットフォームに作りかえたことで、以下の変化がありました。

• ✅ 一つの事業への影響だけを考えれば良いので、変更しやすい
• ✅ 事業戦略に沿った目標設定・コスト最適化をしやすい
• ✅ コスト最適化に対する財務責任/オーナーシップを持てるようになった

プラットフォームチームの考え方も変わり、明らかに不要な浪費を削るだけでなく、「これまで維持してきた品質は本当にこのコストに見合う？」「そもそも維持しなければならないと思い込んでいただけでは？」と考えるようになり、コストと品質のトレードオフを考えてちょうど良いバランスを探るという視点を持てるようになりました¹。

コスト vs. 品質で考える最適化

コストと品質のトレードオフを考えて最適化を進めてきた事例をご紹介します。

トレードオフ① 開発生産性 vs. コスト

Cloud Logging のコストが Google Cloud コスト全体の15%を占めていました。我々のユースケースにおいてはその価値がコストに見合っていないと判断し、重要度の低いログの Cloud Logging への連携を停止しました。ただし、障害対応に必要なクリティカルなログは引き続き Cloud Logging で確認でき、全てのログは BigQuery に sink して長期的な調査・分析も可能です。また、kubectl logs コマンドなどによってリアルタイムにコンテナログを調査できるため、開発生産性を著しく低下させることはありません。

トレードオフ② 信頼性 vs. コスト

社内向けに SLO を定めて公開しています。All Green を維持しているのは良いことなのですが、エラーバジェットがかなり余っている状態が続いていました。これは、下記の課題を抱えていることを意味します²。

• エラーバジェット分のチャレンジができていない
• ハイラムの法則³により、利用者が SLO に設定されている性能ではなく、直近のパフォーマンスに依存し始めてしまう可能性がある

そこで、エラーバジェットを有効活用するための技術的なチャレンジとして、GKE の Nodepool に Spot VM を本番導入しています。Graceful Shutdown を実装していることもあり、エラーバジェットの範囲内で使用できています。一方で、エラーバジェットを消費しすぎた機能（例：Bigtable の autoscaling ）は本番導入しないようにしています。

トレードオフ③ 性能 vs. コスト

BigQuery の Reservation サイズを効率の悪いクエリにあわせて高めに設定していたため、多くの時間帯でスロットの消費状況に余裕があり、効率の悪いクエリが放置されていました。そこで、Reservation サイズを減らすことで、クエリチューニングの動機を生み出すことにしました。プラットフォームが Gemini を活用して効率の悪いクエリをチューニングし、変更後の Reservation サイズに収まるようにしています。

コスト最適化の成果

こういったトレードオフを考えた取り組みも含め、さまざまな工夫を重ねた結果、昨年のコスト削減効果に加えて、2025年1月 → 2025年7月の比較で35.8%のコスト削減を実現しました。さらに、2025年1月 → 2026年1月の比較で44.5%の削減が見込まれており、事業の要求に応えることができる水準になっています。

まとめ

コスト効率の要求レベルが高まるにつれ、横断プロダクト Knile では各事業が求める要求に応えられないという課題に直面し、以下の新たな取り組みを実施しました。

• “横断” プロダクト Knile を事業ごとに “専有” 化
• 当たり前とされた品質にメスを入れるコスト削減

その結果、変更容易性と財務責任/オーナーシップを獲得し、Knile は事業が求める高い水準のコスト効率を達成することができました。

ただし、今回の決断はあくまでプロダクトが螺旋状に進化する中での通過点であり、これからも事業の成熟度や組織の特性にあわせて変わり続けることになると思います。Knile がこれからも事業に貢献できるプロダクトであり続けるために、変化を厭わず、前例や慣習を乗り越えて、歩みを進めていきたいと考えています。

References

• FinOps Foundation
• Maximize Business Value with Cloud FinOps | Google Cloud
• マルチテナントな Internal Developer Platform における FinOps の設計と導入 | Speaker Deck
• 『SRE サイトリライアビリティエンジニアリング』
• 『Google のソフトウェアエンジニアリング』