事業の財務責任に向き合う リクルートデータプラット フォームの FinOps October 17, 2025 株式会社リクルート データ推進室 データソリューション 3 ユニット & データプラットフォームユニット 菅沼 孝二 / Koji Suganuma, 鈴木 理紗 / Lisa Suzuki 

これは 10 年間にわたってリクルート内の データ アプリケーション開発を支えてきた内部 開発者向けプラットフォーム (= Internal Developer Platform) の物語 2 

自己紹介 2017 年 株式会社リクルートライフスタイル（現 株式会社リクルート）入社。リク ルート データ組織におけるデータ エンジニア。 データ アプリケーション開発を効率化するデータ プロダクト（Internal Developer Platform）のプロダクト テックリード。 2025 年 Google Cloud Champion Innovators (Modern Architecture) 認 定。現 Google Developer Experts (Google Cloud）。 菅沼 孝二 データ エンジニア 3 

自己紹介 2021 年 株式会社リクルートに入社し、検索エンジニアとして検索システムの開 発に従事。 2023 年より、データ エンジニアとして、データ アプリケーション開発の効率化を 目的とした Internal Developer Platform の開発を担当。 鈴木 理紗 データ エンジニア 4 

Google Cloud 05 利用拡大にともなって顕在化した課題 コスト最適化の壁　前に進むための決断 コスト vs OO性 で考える最適化 06 総括 リクルートのビジネスモデルを支える データとテクノロジー 01 02 03 04 目次 5 横断プロダクト Knile における FinOps の導入 

01 リクルートのビジネスモデルを支 えるデータとテクノロジー 6 

© Recruit Co., Ltd. All Rights Reserved 7 リクルートグループの事業内容 マーケティング・マッチング・テクノロジー SBU HR テクノロジー SBU 人材派遣 SBU 国内派遣 海外派遣 選択・意思決定を支援する情報サービスを提供し、 「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」 を実現する ※一部サービスのみを記載 

© Recruit Co., Ltd. All Rights Reserved リクルートのビジネスモデル リクルート マッチングプラットフォーム クライアントとカスタマーを結びつける 対価としてクライアントからフィーを受領 カスタマー クライアント ● リクルートにはカスタマーとクライアントという 2 つのお客様が存在 ● 「企業と人（B to C）」 「企業と企業（B to B）」 「人と人（C to C）」のすべての間に立ち、双方にとって最適な マッチングを図る「場」を提供 8 カスタマーとクライアントを新しい接点で結び、 「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」 の場を創造する 

© Recruit Co., Ltd. All Rights Reserved 最適なマッチング実現のためにデータ活用先は多岐に渡る 9 [引用] データ推進室 リクルートのビジネスモデル | 株式会社リクルート キャリア採用特設ページ 

© Recruit Co., Ltd. All Rights Reserved リクルートにおけるデータ活用事例 10 複数領域でデータ活用施策が実施されており、下記はその一例。 リクルート カスタマー向け施策、クライアント向け施策、社内向け施策など、施策種別は多種多様。 機械学習モデル予測値を用いて、新ジャンルの予約数と 配信に伴う利用金額を予測。ギフト券配信の予算の制約 がある中、新ジャンルの利用者数を全てのジャンルにお いて増やす、最適な配信を実現。 『Airレジ オーダー』から定常取得される業務データを活 用することで提供遅れ時間の最小化を実現し、調理遅れ の件数を削減。 分析に適したデータ モデリングを実施し複雑さを解消す ると共に、モジュール分割・テストされたデータ パイプライ ンを導入し、データマート開発時の保守工数を削減。 [引用] データ推進室 事例紹介 | 株式会社リクルート キャリア採用特設ページ 

各事業でのデータ利活用と横断プロダクト 11 本日、事例として取り上げる Knile Platform リクルートのデータ組織は、各事業領域に対応する「事業データ組織」と、事業や案件 を横断して利用可能なシステム（横断プロダクト）を提供する「横断データ組織」で構 成。各事業データ組織は、横断プロダクトと事業領域独自に運用するデータプロダクト と組み合わせながら、データ利活用施策を実現。 事業 A データ組織 事業 B データ組織 事業 C データ組織 横断プロダクト Knile 横断プロダクト X 横断プロダクト Y … 事 業 横 断 プロダクト利用 事業領域 B 各事業領域のデータ利活用へのコミットメント 事業領域 A 事業領域 C … … 独自 独自 

様々な横断プロダクトを利用することで End-to-end なデータ パイプラインを実現 12 複数の横断プロダクトを利用したデータ パイプラインの例 施策要件に応じて他の横断プロダクトや事業独自のプロダクトなどを組み合わせて実現される Crois 

複雑な実装詳細を適切に抽象化することで アプリケーション開発の Golden Path を提供 13 横断プロダクトにおける Google Cloud の構成例 横断プロダクトによって採用される技術スタックは様々だが、利用者はそれを意識せずに開発可能 Crois 

実は Knile は元々横断プロダクトではな かった 14 

販促事業領域の中のいちデータ活用グループ内で利用開始 2015 Data Management G Data Engineering G Data Science G ※所属組織および対向組織のみ記載しています（他組織は記載していません） ※簡略化のため、実際の組織名 /組織構成とは異なる部分があります 所属組織 対向組織 同一部門のグループ内 での利用開始 15 株式会社リクルートライフスタイル (現 体制の販促事業領域相当) 2012 Knile 提供範囲 当時の販促事業領域におけるデータ エンジニアリング グループは、 ● ビジネス課題解決のための企画を立案・推進する人材 ● データ分析・モデリング・機械学習コードを実装する人材 ● データ プロダクトを開発・運用する人材 が所属し、ワンチームで様々なデータ活用施策を進める体制。 そのグループに閉じたデータ アプリケーション開発の効率化のための データ プロダクト として誕生。 データ 組織 データ活用組織 の組閣 プランナー / ML エンジニア / データ エンジニア 等が同一グループ 

データ組織の拡大とともに Knile 提供範囲も拡大 2015 2025 2021 Data Management G Data Engineering G Data Solution 1G Data Solution 2G Data Management G Data Engineering G … Data Solution 1G Data Solution 2G Data Management G Data Engineering G … Data Platform G ソリューション別組織 の編成 データ活用先・手段の多様化により それぞれのソリューション別に組織分割 事業A Unit Data Solution 1G / 2G /… 事業A Unit Data Engineering 1G / 2G /… 事業A Unit Data Management G 事業B Unit Data Solution 1G / 2G /… 事業B Unit Data Engineering 1G / 2G /… 事業B Unit Data Management G プラットフォーム開発組織 の編成 複雑なパイプライン構築を担う Engineering G とプ ラットフォーム層を担う Platform G を分割 Data Product Engineering 1G / 2G /… 横断データ プロダクト運営組織 の編成 データ プラットフォームをプロダクトとして運営 プロダクト特性別に複数グループを編成 Data Science G Data Science G … データ活用組織 の組閣 プランナー / ML エンジニア / データ エンジニア 等が同一グループ ※所属組織および対向組織のみ記載しています（他組織は記載していません） ※簡略化のため、実際の組織名 /組織構成とは異なる部分があります 所属組織 対向組織 同一部門のグループ内 での利用開始 部門を跨ぐ複数グループ への提供 特定事業領域全体 への提供 複数事業領域へ の提供（＝横断化！） 16 株式会社リクルートライフスタイル (現 体制の販促事業領域相当) 株式会社リクルート (リクルート統合) 2012 Knile 提供範囲 データ 組織 

Knile の提供範囲の拡大にともなって、急速に利用拡大 17 ※ 2023 / 07 以降も拡大継続 

Knile の利用規模 300+ developers, users 250+ data projects 5- platform maintainers 6,000+ developers’ releases per year 400+ maintainer’s releases per year 6+ business units 様々な事業領域にて多くのデータ利活用施策を実施 多くのデータ アプリケーション開発者 / 利用者を小さいチームでサポート アプリケーション・プラットフォームともに多く・素早いリリースでデータ利活用を改善 18 

利用拡大はプロダクト運営としては順調 に見えたが... 19 

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

想定以上のコスト増・不透明性 21 Knile 本番環境 Google Cloud Project の利用額推移 Knile がマルチテナント構成となっていることもあり、どの施策に・どれだ けのコストがかかっているのか、どこがコスト増の主要因なのか、利用者 も Platform Team もわからない状態... 

費用負担構造の不平等性 22 歴史的経緯により横断プロダクトの費用負担の構造は歪なものに。。。 ● 全社コスト時代 ○ 横断プロダクトのコストは全社コストとして賄われていた ○ 利用組織に支払い義務はなく、コスト意識が低い状態 ● 固定費請求時代 ○ 上記課題を踏まえ、利用組織に請求する形をとった ○ ただし、コストの内訳が不明だったため固定費請求の形 となった ○ 利用増減で実態と請求が乖離するため、利用組織としては納得感がなく、 コスト削減の動機も発生しづらい 利用組織が利用した分だけ支払う「受益者負担の原則」の実装が求められた 

23 横断プロダクトのコスト効率化要求 の高まり 全社経営方針に基づき、横断プロダクト の運営組織が所属するデータ推進室全 体でもコストに対する意識が高まり、横 断プロダクトへの効率化要求に対する優 先度も急速に高まった →「コスト周りをどうにかしないといけな い！ FinOps の導入だ！ 」 株式会社リクルートホールディングス 2024年3月期通期決算決算説明動画プレゼンテーション資料 より引用 

03 横断プロダクト Knile における FinOps の導入 24 

FinOps Framework & Phases “技術、財務、ビジネスを一体化する運用フレームワークであり、組織文化を変革するものです。クラ ウド変革を通じて財務アカウンタビリティを高め、ビジネス価値の実現を推進します。 ” 25 [引用] Maximize Business Value with Cloud FinOps | Google Cloud 

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

Phase: Inform クラウド利用料を含む全ツール利用変動費や減価償却費を含む固定費な ど、プロダクトを構成する全ての費用を日次・従量で集計し、 導入組織・施 策・リソース単位でのコスト可視化・レポーティング・課金請求が可能な 仕組みを構築。 27 (例) 組織・施策・リソース単位のコスト可視化 一部抜粋 

これまでも可視化できていたリソースの Usage & Rate に加えて、コストも可 視化されたことにより、 どこで浪費（ cloud waste）が発生しているのかが 特定可能 となったことで、コスト削減に向けた実行計画や優先度決定、実 際の取り組み後の振り返り分析が容易 となった。 Phase: Inform & Optimize 28 [図 引用] Maximize Business Value with Cloud FinOps | Google Cloud (例) サンプル施策用のリソース Usage & Rate ダッシュボード 一部抜粋 

Phase: Optimize & Operate [図 引用] Maximize Business Value with Cloud FinOps | Google Cloud 浪費（cloud waste）を徹底的に削減 するための Low effort // low savings な取り組みから始めて、 High effort // high savings な取り組みも実施中。 最 適化実施と効果振り返りを繰り返し ながら、全体の成果を高めていった。 適用済 適用中 未検討 29 未適用 

30 -40.5% これらの取り組みにより、既存の品質を維持したまま、 Knile Platform 全体で一定のコスト削減効果を実現！ → YEAH ! 2024 / 01 => 2025 / 01 比で 40.5 % 減！ ※実績に基づく社内評価 

Inform フェーズの取り組みにより コスト効率化はさらに高い目標へ Inform した内容を根拠に、事業領域側は Knile で発生するコストに対する解 像度が上がったことで、より高い水準でコスト効率化の目標を設定できるよう になった → Inform フェーズがもたらしたのは単なる「可視化」だけではなく、　 「コスト 最適化に対する意識変化 」 →「より高いコスト効率を目指すぞ！ 」 31 

04 コスト最適化の壁 前に進むための決断 32 

Knile でより高いコスト効率を目指そうと したが思うように効果を出せなかった ● 検証・承認に時間がかかる ○ コスト最適化の取り組みが全事業に影響するため ● 横断プロダクトを運営するために必要な要件の実現・運用に工数がかかる ○ 例：課金請求機能、厳格な権限分離など 33 

Knile でより高いコスト効率を目指そうと したが思うように効果を出せなかった ● 検証・承認に時間がかかる ○ コスト最適化の取り組みが全事業に影響するため ● 横断プロダクトを運営するために必要な要件の実現・運用に工数がかかる ○ 例：課金請求機能、厳格な権限分離など 34 

35 [仮説] 横断プロダクトでなければ 発生しない課題では？ Knile でより高いコスト効率を目指そうと したが思うように効果を出せなかった ● 検証・承認に時間がかかる ○ コスト最適化の取り組みが全事業に影響するため ● 横断プロダクトを運営するために必要な要件の実現・運用に工数がかかる ○ 例：課金請求機能、厳格な権限分離など 

横断プロダクト Knile で実現していたものを 事業独自プラットフォームに作りかえる ● 横断組織が、事業独自プラットフォーム構築を全面的にサポート ● 事業ごとの規模や特性を踏まえた設計（必要な機能だけに絞るなど） 36 事業 A データ組織 事業 B データ組織 横断プロダクト Knile 事業 C データ組織 移管 事 業 横 断 横断プロダクト X 横断プロダクト Y 事業領域 A 事業領域 B 事業領域 C 各事業領域のデータ利活用への コミットメント 独自 独自 支援 プロダクト利用 

横断プロダクト Knile で実現していたものを 事業独自プラットフォームに作りかえる ● 横断組織が、事業独自プラットフォーム構築を全面的にサポート ● 事業ごとの規模や特性を踏まえた設計（必要な機能だけに絞るなど） 37 事業 A データ組織 事業 B データ組織 横断プロダクト Knile 事業 C データ組織 移管 事 業 横 断 横断プロダクト X 横断プロダクト Y 事業領域 A 事業領域 B 事業領域 C 各事業領域のデータ利活用への コミットメント 独自 独自 支援 プロダクト利用 

Knile のコスト最適化をしやすくなった ✅ 一つの事業への影響だけを考えれば良いので、変更しやすい ✅ 事業戦略に沿った目標設定・コスト最適化をしやすい 38 

デメリットもあるが、 今ならメリットが上回ると予想して検証中 ✅ 一つの事業への影響だけを考えれば良いので、変更しやすい ✅ 事業戦略に沿った目標設定・コスト最適化をしやすい ❌ 知見のサイロ化 ❌ プラットフォーム開発 / 運用工数を事業側が負担する ❌ 独自プラットフォーム間で品質格差 39 ただし、クラウドの進化・ AI Coding の発展により 以前よりこれらのデメリットは緩和している！ 

デメリットもあるが、 今ならメリットが上回ると予想して検証中 40 ただし、クラウドの進化・ AI Coding の発展により 以前よりこれらのデメリットは緩和している！ ✅ 一つの事業への影響だけを考えれば良いので、変更しやすい ✅ 事業戦略に沿った目標設定・コスト最適化をしやすい ❌ 知見のサイロ化 ❌ プラットフォーム開発 / 運用工数を事業側が負担する ❌ 独自プラットフォーム間で品質格差 

支出 = 収入(利益 = 0) になるように各事業に按分して請求するだけだった → 事業戦略に沿った目標を設定し、その目標を達成しなければならない立場になったこ とにより、コスト最適化に対する財務責任 / オーナーシップ が生まれた すると、これまで浪費 (cloud waste) を削るのが主だったのが、もう一歩踏み込み 　「これまで維持してきた品質は本当にこのコストに見合う？」 　「そもそも維持しなければならないと思い込んでいただけでは？」 と考え、品質を変えることも選択肢に入れられるように なった 41 Platform team の考え方も変わった 

42 Platform team の考え方も変わった 支出 = 収入(利益 = 0) になるように各事業に按分して請求するだけだった → 事業戦略に沿った目標を設定し、その目標を達成しなければならない立場になったこ とにより、コスト最適化に対する財務責任 / オーナーシップ が生まれた すると、これまで浪費 (cloud waste) を削るのが主だったのが、もう一歩踏み込み 　「これまで維持してきた品質は本当にこのコストに見合う？」 　「そもそも維持しなければならないと思い込んでいただけでは？」 と考え、品質を変えることも選択肢に入れられるように なった 

コスト 43 OO性 つまり、コストと品質のトレードオフを考えたコスト最適化ができる ように 

05 コスト vs OO性 で考える最適化 44 

トレードオフ① 開発生産性 vs コスト ロギングは、オブザーバビリティの重要な要素の 1 つ 45 しかし、 Cloud Logging のコストが全体の 15 % (第 3 位) → 我々のユースケースではログ全量を Cloud Logging 　 に連携する価値は、そのコストに見合っていない 

トレードオフ① 開発生産性 vs コスト 46 重要度の低いログの連携を停止 ただし、 ● 障害対応に必要なクリティカルなログの Cloud Logging 連携は残す ○ 障害発生時の分析・調査および共有は可能 ● 重要度の低いログも含めてログ全量を BigQuery にシンク ○ 過去長期データの調査・分析（傾向変化など）は可能 ● 開発生産性を著しく低下させないための代替手段は残っている ○ $ kubectl logs でリアルタイムにコンテナログを調査可能 

トレードオフ② 信頼性 vs コスト 47 SLO を達成しているのは良いが、エラーバジェットを大きく余らせ続けていた ● チャレンジができていない ● ハイラムの法則により、利用者が過剰な性能に依存 し始める 

チャレンジ！ ● Google Kubernetes Engine Node に Spot VM を本番導入 ○ Spot VM は ■ 安価なマシン ■ サービスレベルがなく、提供・shut down のタイミング・頻度が不明 ただし、エラーバジェットを消費しすぎる機能は本番導入を見送り ● Bigtable の auto-scaling は本番反映を断念 トレードオフ② 信頼性 vs コスト 48 

49 チャレンジ！ ● Google Kubernetes Engine Node に Spot VM を本番導入 ○ Spot VM は ■ 安価なマシン ■ サービスレベルがなく、提供・shut down のタイミング・頻度が不明 ただし、エラーバジェットを消費しすぎる機能は本番導入を見送り ● Bigtable の auto-scaling は本番反映を断念 トレードオフ② 信頼性 vs コスト 

トレードオフ③ 性能 vs コスト 50 事前に確保されていた BigQuery Reservation に対し スロットの消費状況に余裕があり、効率の悪いクエリが放置されていた BQ Slot Reservation usage_time slot usage 

BQ Slot Reservation BQ Slot Reservation (new!!) トレードオフ③ 性能 vs コスト 51 クエリ チューニングの動機を生む 特に効率の悪いクエリは、Platform チームが Gemini を活用しチューニング usage_time slot usage 

52 コスト最適化取り組み例（一部のみ抜粋） 

トレードオフを加味したコスト最適化の成果 53 直近半年の効果実績 2025 / 01 => 2025 / 07 比で 35.8 % 減！ 今年の効果見立て 2025 / 01 => 2026 / 01 比で 44.5 % 減 見込み！ 昨年 今年 2026 年 1 月 (見 立 て ) 既存 品質・構成 でのコスト削減 - 35.8 % - 44.5 % 見込み トレードオフを加味したコス ト削減 ※実績に基づく社内評価 

06 総括 54 

総括 リクルート データ推進室では、事業領域やプロジェクトを越えて活用可能なシステ ムを「横断プロダクト」と認定した上で、各領域への展開。 コスト効率の要求レベルが高まるにつれ、横断プロダクト Knile では各事業が求 める要求に応えられないという課題に直面し、新たな取り組みを実施。 1. “横断” プロダクト Knile を特定事業に “専有” 化 2. 当たり前とされた品質にメスを入れるコスト削減 変更容易性 と 財務責任 / オーナーシップ を獲得し、Knile は事業が求める高い 水準のコスト効率を達成。 55 

総括 56 リクルート データ推進室では、事業領域やプロジェクトを越えて活用可能なシステ ムを「横断プロダクト」と認定した上で、各領域への展開。 コスト効率の要求レベルが高まるにつれ、横断プロダクト Knile では各事業が求 める要求に応えられないという課題に直面し、新たな取り組みを実施。 1. “横断” プロダクト Knile を特定事業に “専有” 化 2. 当たり前とされた品質にメスを入れるコスト削減 変更容易性 と 財務責任 / オーナーシップ を獲得し、Knile は事業が求める高い 水準のコスト効率を達成。 

これが最終的な形とは限らない 2025 年 特定事業に専有化 2015 年 事業専有プラットフォームとして誕生 2021 年 ~ 横断化 あくまで らせん状に進化する 過程の一部 事業の成熟度や 組織の特性にあわせ てこれからも変わり続 ける 57 

© Recruit Co., Ltd. All Rights Reserved 58 We are hiring! カジュアル面談はこちらより お申し込みください データサイエンティスト 機械学習エンジニア データエンジニア アナリティクスエンジニア R&Dエンジニア データアプリケーションエンジニア クラウドエンジニア 

Thank you 59