© Recruit Co., Ltd. All Rights Reserved AI 時代の Platform Engineering 攻めと守りの開発手法を両立するガードレール設計のプラクティス 株式会社リクルート データ推進室 菅沼 孝二 2026/05/15 

© Recruit Co., Ltd. All Rights Reserved Agenda Section 1：Platform Engineering の役割と 10 年間の取り組み Section 2：AI による変更主体の拡張と Guardrails 拡張・深化の必要性 Section 3：実践プラクティス — 3 つの Guardrails ピラー Section 4：銀の弾丸の否定 + Platform as a Product 思想 Section 5：普遍性の再認識 — 何が変わり、何が変わらないか Wrap-up：今日から問うべき 3 つの問い 2 [本日の中心の問い] AI が変更の主体になる時代、Platform に求められる役割は本質的にどう変わり、何が不変か? AI Coding の時代、 Platform Engineering の本質は変わるのか 

© Recruit Co., Ltd. All Rights Reserved 菅沼 孝二 Koji Suganuma Profile 3 2017 年 株式会社リクルートライフスタイル（現 株式会社リクルート） 入社。リクルート データ組織におけるソフトウェアエンジニア。 データ アプリケーション開発を効率化するデータ プロダクト（Internal Developer Platform）の開発運用に従事。 2025 年 Google Cloud Champion Innovators (Modern Architecture) 認定。現 Google Developer Experts (Google Cloud）。 

© Recruit Co., Ltd. All Rights Reserved Platform Engineering の役割と10 年間 の取り組み Section 1 

© Recruit Co., Ltd. All Rights Reserved Platform Engineering の役割とは何か 5 Platform = 利用者の生産性をスケールさせる仕組み 「生産性」= 個々の利用者の創出力 × 組織横断の規模 ■ その手段の中核アプローチ ・認知負荷の削減 — 利用者が本質に価値創出に集中できる状態をつくる ・標準化 / 自動化 — 反復作業や手戻りを排除する ・境界設計 — 何を見せ、何を見せないかを設計する 

© Recruit Co., Ltd. All Rights Reserved 我々の 10 年の取り組み — Golden Paths を中心とした生 産性のスケール 6 Platform の役割 (= 利用者の生産性をスケールさせる ) を実現するため、 利用者の生産性を最大化させるべく取り組んできた ■ 当時、生産性スケールを阻害していた「人手不足」は、 2 つの視点で立ち現れていた ・プラットフォームエンジニア（ PE）視点: 利用者数の増加に対し、PE 工数が常にボトルネックになる ・利用者視点 : 個々の利用者の創出力が認知負荷によって総創出量は限定的になる ■ Golden Paths を中心とした設計プラクティスで対応 ・開発体験 (DevEx) / セルフサービス化 → 利用者の自律性を高めて PE 依存を減らす (PE 視点への対応) ・認知負荷の削減 (抽象化レイヤ・標準化 ) → 利用者が本質に集中できる状態を作り、創出力を引き上げる (利用者 視点への対応) 

© Recruit Co., Ltd. All Rights Reserved 10 年で達成したこと — 人間主体時代の生産性律速は解決 7 ■ 成果 Golden Paths を導入したプラットフォームの提供により、 プラットフォームエンジニアの運用負荷を変えずに、 利用者組織全体の生産性 を 劇的に引き上げた ■ 「人手不足」の 2 視点は、Golden Paths を中心とした取り組みで両方とも解決された ・PE 工数のボトルネック化 → セルフサービス化 + 開発体験で解決 ・個々の利用者の認知負荷による制約 → 抽象化レイヤ + 標準化で解決 つまり、人間主体時代の生産性律速は、 Golden Paths を中心とした取り組みで解決されていた 「人間主体時代の生産性律速は解決した。しかし、利用者の主体が変わりつつあります」 

© Recruit Co., Ltd. All Rights Reserved AI による変更主体の拡張と Guardrails 拡張・深化の必要性 Section 2 

© Recruit Co., Ltd. All Rights Reserved 利用者の主体が、人間から Agent に拡張されつつある 9 AI Coding の登場で、変更を起こす主体に Agent が加わってきた ■ Agent は、人間の生産性のスケール制約に制限されない ・人間: 認知容量・物理的時間で律速される ・Agent: 並列・高頻度・大規模・持続的に動ける ■ つまり、利用者組織全体の生産性はさらに大幅に拡大していく ・Golden Paths を整備した組織は、Agent の登場で更にスケールできる ── しかし、ここから新しい問題が立ち上がる。 

© Recruit Co., Ltd. All Rights Reserved 主体の拡張が、変更生成量と人間の認知範囲のギャップを 生む 10 [過去 / 人間中心] [AI 時代 / 人間 + Agent] ───────────────────────────────────────── 変更生成量 ▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ 桁違いに拡張 ↑↑↑↑↑↑↑↑↑↑↑↑↑ ここがギャップ 人間の認知範囲 ▮▮▮▮ ▮▮▮▮▮▮ = レビュー・ AI 補助でやや拡張するが生成量の拡張ペース 認知できる範囲 には追いつかない ───────────────────────────────────────── 生成量 ≦ 認知範囲 生成量 >> 認知範囲 基本的にカバー可能 認知範囲を超えた領域が構造的に発生 人間の認知範囲は AI 補助で拡張する可能性はあるが、変更生成量の桁違いの拡張ペースには追いつかない。 結果、生成物と認知範囲の間に構造的なギャップが生まれる 

© Recruit Co., Ltd. All Rights Reserved 認知範囲を超えた領域は、既存 Guardrails では追いつか ない 11 ■ 前提 既存の Guardrails は生成物が「人間による認知範囲内にある」 という前提の下で設計されてきた ■ 課題 AI 時代では 変更生成量 >> 認知範囲 → 認知範囲を超える領域が構造的に発生 ■ 帰結 既存 Guardrails では品質担保が構造的に不十分（＝その発生頻度・確率が構造的に上昇） 例: Agent が大量に生成する PR を人間がレビューしきれず、ハルシネーション・わずかなバグを見逃した本番反映 → Guardrails の役割範囲をより広く、設計深さをより深く拡張する必要がある 

© Recruit Co., Ltd. All Rights Reserved AI 時代の Platform 中核機能 — Guardrails の拡張・深 化 12 ■ もう一つの論点 ─ 変更プロセスの圧縮・喪失 ・人間時代: 変更実装前からのチーム内議論プロセスを通じて事前に変更実装に関する暗黙の認知が形成 ・AI 時代: Agent との対話で個人に閉じた変更実装生成 → レビュアーは「初対面の変更」を大量処理 ・これは認知範囲ギャップ (量の問題) とは 別軸の論点 (プロセスの問題 ) 　─ 認知範囲を超えた領域をさらに増幅させる構造的要因 ■ 結論 Guardrails の役割範囲・深さの大幅な拡張・深化 が AI 時代の Platform 中核 Golden Paths は AI 時代でも土台として継承 (ただし本登壇では Guardrails の拡張・深化に焦点を当てて紹介 ) 

© Recruit Co., Ltd. All Rights Reserved 実践プラクティス — 3 つの Guardrails ピラー Section 3 

© Recruit Co., Ltd. All Rights Reserved Pillar 1 / Repo・CI/CD ─ 影響範囲の異なる変更を、同 じ厳しさでは扱えない 14 ■ 課題: 変更の「影響範囲」で要求される厳しさが二分される 軸 1: 局所変更(アプリ層) ・影響範囲が単一サービスに閉じるが、AI を含む多 数の利用者による変更が高頻度かつ大量に発生 ・1件ごとに重い承認・厳格な事前検証を強制する と、AI の速度を殺してしまう 軸 2: 広域変更(基盤層) ・影響範囲が多数のサービスに及び、1 件の事故が 連鎖的に波及 ・軽量レビュー・速いデリバリーをそのまま適用す ると、誤った変更が一気に拡散 → 影響範囲に応じて、Repo の構造と CI/CD の厳格性を非対称に設計する必要がある 

© Recruit Co., Ltd. All Rights Reserved Pillar 1 / 設計原則 ─ 影響範囲に応じて「構造」と「プ ロセス」を非対称にする 影響範囲の異なる変更を、同じパイプラインで処理しない ─ Repo で物理的に隔離し、CI/CD で厳格性の置き場所を差し替える 原則 1: Repo の物理的分離(構造) 変更の「重さ」を Repo そのもので表現する ・影響範囲の多寡に応じて別リポジトリを用意 ・局所変更は軽量なレビュー、広域変更は複数承認を強 制 原則 2: CI/CD パイプラインの非対称(プロセ ス) 厳格性を「どこに置くか」を層ごとに変える ・局所変更: CI を軽量に、CD の並行性とスケーラビリ ティを優先 ・広域変更: CI で事前検証を厳格化し、Apply 前にリス クを認知 ※ 前提 変更経路は人間・AI を問わず IaC / IaD のみ。コンソール直操作などの抜け道は構造的に塞ぐ → 構造(Repo)とプロセス(CI/CD)の両輪で、影響範囲の非対称性を吸収する 

© Recruit Co., Ltd. All Rights Reserved Pillar 1 / アプリ層の実装 ─ 高並行デリバリー AI を用いた高頻度・大量の変更が発生する領域。 ■ 実装 ・リポジトリ: 物理分離 + 軽量ブランチ保護 影響範囲の小さい変更を、軽量レビューで素早く取り込む構造に ・CI/CD: ArgoCD + k8s CRD / Custom Controller による GitOps (pull 型) 大量の並行デプロイを Kubernetes ネイティブに捌き、Custom Controller がアプリ運用の不変条件を抽象化 本番と意図の乖離(drift)を ArgoCD が継続的に検出・収束 ・Agent の関与範囲 PR 発行までは Agent が自律実行を許容。 マージ前レビューは任意としているが、自律マージは未導入(将来検討中) ■ 効果 ・AI による大量の局所変更を、人間レビューも CI/CD パイプラインもボトルネック化せずスケール ・ドリフト検出による継続的な収束で、本番と意図の乖離をゼロ化 

© Recruit Co., Ltd. All Rights Reserved Pillar 1 / 基盤層の実装 ─ 厳格な事前検証 1 件の事故が広範囲に波及する領域。CI による事前検証の厳格性を最優先に設計 ■ 実装 ・リポジトリ: 物理分離 + 厳格ブランチ保護 複数承認の強制と CODEOWNERS によるレビュアー限定で、広域変更を構造的にゲート ・CI/CD: 2 系統 Terraform, k8s Manifest の宣言的デリバリー Terraform: plan / apply 分離による事前検証、段階的 Apply k8s Manifest (CIOps push 型): CI で Pluto / Polaris / KubeLinter / Manifest 差分確認を厳格に実行 どちらも「Apply 前にリスクを認知できる」状態を担保 ・Agent の関与範囲 PR 発行までは人間 + Agent マージ・適用は人間ゲートを必須 ■ 効果 ・人間判断ゲートと CI の厳格チェックが構造的に強制され、AI 起因の連鎖事故を防止 ・同じ宣言的デリバリーでも層ごとに最適化することで、早期検査による速度の担保 

© Recruit Co., Ltd. All Rights Reserved Pillar 2 / Test ─ 人間の認知範囲を前提にしたテストは AI 時代に構造的に不足 18 ■ 課題: AI 時代に「人間の認知範囲外」が二軸で広がる 軸 1: 流入する変更(フロー) ・AI が生成する変更は大量・高速で、実装者・レ ビュアーの認知範囲を超える ・追加変更に対し必要十分なテストが実装されてい るかも保証できない 軸 2: 既存コードベース(ストック) ・AI 起源コードが運用資産として蓄積し、「誰も完 全には把握していない領域」が単調増加 ・新規変更 × 既存コードベース × 本番トラフィック の組み合わせ衝突は、事前に予見不可能 → 人間の認知範囲を前提にしたテストでは、量・確率・カバレッジの三面で構造的に埋まらない 

© Recruit Co., Ltd. All Rights Reserved Pillar 2 / 設計原則 ─ Shift Left × Shift Right の二刀 流 19 事前に予防できる欠陥は事前に止め、事前に書けない衝突は本番で観測する ─ 検証タイミングを二層化し、認知範囲外の二軸に対応する 原則 1: Shift Left 事前に予防できる欠陥は、事前に機械的に止める ・流入する変更の既知パターンを機械検証で弾く ・振る舞いの仕様を先に固定し、AI の暗黙的逸脱を検出 可能に ・テスト網を階層化し、構造的に品質安定化 原則 2: Shift Right 事前に書けないものは、本番実トラフィックで検証 する ・実環境を検証環境として活用し、未知エッジと衝突を 観測 ・本番影響を限定(部分流入・並列実行)して安全に運用 ・効果と副作用を実データで判定し、想定との乖離を早 期把握 ⚠ Shift Left だけでは不足 ・テストカバレッジは「人間が認知できた振る舞い」に限 定され、認知外はそもそも検証対象にならない ・既存コードベース側の認知範囲外との衝突は、事前検証 では踏めない ⚠ Shift Right だけでも不足 ・事前に防げる欠陥まで本番に流すのは過剰リスク ・検出が事後 = ユーザー影響発生後 → インシデント前提 の運用 → 二刀流の統合で、流入 × 既存コードベース の二軸を多層的にカバー 

© Recruit Co., Ltd. All Rights Reserved Pillar 2 / 実装例と効果 ■ 実装例 Shift Left: 事前の機械検証 ・静的解析(CI で即時検出) Linter / Formatter, Manifest, Type, Vulnerability, Import layer ・テストファースト 振る舞いの仕様をテストで先に固定 ・階層的テスト Unit / Component / Product / E2E / Load / Performance Shift Right: 本番実トラフィックでの検証 ・カナリアリリース 一部トラフィックで先行検証し、影響を限定 ・A/B テスト 効果と副作用を実データで判定 ・シンセティックテスト 本番環境に対する継続的な動作監視 ・シャドウデプロイ [導入検討中] 本番影響なく実トラフィックで振る舞いを検証 ■ 効果 ・人間の認知範囲を超えた領域の問題を、テスト側で構造的にキャッチ ・「速度を出しても怖くない」状態を作り、Agent 主導の変更を安全に受容できる 

© Recruit Co., Ltd. All Rights Reserved Pillar 3 / Observability ─ AI が生み出す副作用は人間 の認知範囲を超える 21 ■ 課題: 副作用の監視が人間の認知範囲を構造的に超える 軸 1: 副作用の量 ・AI による高頻度変更で、副作用の絶対量が指数的 に増加 ・人間の監視帯域(目視・アラート確認)は変わら ず、認知範囲を超えた信号が取りこぼされる 軸 2: 因果の追跡可能性 ・変更が多すぎて「どの変更がどの異常を起こした か」が判別困難に ・原因不明のまま「とりあえず様子見」が常態化 し、問題が累積するリスク → Full-stack / End-to-end の Observability で、副作用の発生箇所と影響範囲を構造的に追跡可能 にする 

© Recruit Co., Ltd. All Rights Reserved Pillar 3 /設計原則 ─ Full-stack × End-to-end Observability 22 「どこに副作用が出るか分からない」前提で、観測の網を構造的に広げる ─ 縦方向(レイヤー)と横方向(パイプライン)の二軸で、認知範囲外をカバー 原則 1: Full-stack(縦串) レイヤーを縦に貫いて副作用を観測 ・インフラ / ミドルウェア / アプリ / データを 1 本の文 脈で繋ぐ ・ログ / メトリクス / トレース / SLO / コストでレイ ヤーごとの可視性を確保 ・どのレイヤーで副作用が起きたかを断面で特定可能に 原則 2: End-to-end(横串) パイプラインを横に貫いて副作用を観測 ・収集 / 蓄積 / 加工 / デリバリーの各工程を横に繋ぐ ・上流のデータ異常が下流に伝播する経路を追跡可能に ・データの流れの中で「どこで品質が崩れたか」を特定 可能に → 縦 × 横の網で、人間の認知範囲を超えた副作用も観測・追跡可能に 

© Recruit Co., Ltd. All Rights Reserved Pillar 3 / 実装例と効果 23 ■ 実装例 Full-stack: 副作用を断面で観測 ・インフラ / ミドルウェア / アプリ / データの縦断観測 各レイヤーでログ・メトリクス・トレース等を取得し、副 作用が起きたレイヤーを断面で特定 ・SLO ベースの異常検知 サービスレベルの逸脱を早期に検出し、調査の起点を提供 ・コスト観測 AI が生成するリソース消費を可視化し、副作用としてのコ ストを把握 End-to-end: パイプライン全体で因果を追跡 ・横断ダッシュボード パイプライン全体を 1 画面で俯瞰し、どの段で異常が起き たかを切り分け ・障害影響の追跡 ダッシュボードから伝播経路を絞り込み、影響範囲を手繰 れる(自動化は今後の課題) ■ 効果 ・人間の認知範囲を超えた副作用も、縦 × 横の観測網で検知時間を構造的に短縮 ・将来の AI / Agent 駆動の運用に対し、必要十分な可観測性を提供できる土台に 

© Recruit Co., Ltd. All Rights Reserved 3 つの Guardrails が体現する「攻めと守りの両立」 24 ■ 3 Guardrails が応える二軸 ・Pillar 1 / Repo・CI/CD ─ 影響範囲: 局所 × 広域 ・Pillar 2 / Test 　 ─ 認知範囲外: フロー × ストック ・Pillar 3 / Observability ─ 副作用: 量 × 因果 ■ 共通する設計方針 ・AI を弾くのではなく、AI が量と速度を出す前提で受け止める ・単一の厳しさではなく、軸に応じて非対称 / 多層に組む 本質: 守りが攻めを enabling する 拡張・深化された Guardrails (質) が、Agent の生産性を 真の生産性 に変換する 

© Recruit Co., Ltd. All Rights Reserved 銀の弾丸の否定 + Platform as a Product 思想 Section 4 

© Recruit Co., Ltd. All Rights Reserved Guardrails を整備しても障害は起きる ─ 当時捕捉できな かった死角 26 ■ 事例: 基盤リアーキテクチャに伴うアプリケーション移管時の障害 ・基盤チームが全アプリケーションの移管を実施した際、特定 API で障害が発生 ・基盤チームが AI Agent をフル活用して移管実施 ・移管時にエラーが出ず、正常完了と誤認 ・実は移管前後で該当 API のレスポンスボディが空になっていた ・後日、アプリケーション施策担当者が異常に気づき、エスカレーションで検知 ■ 当時の Guardrails では捕捉できなかった ・Test ・想定範囲内のリクエストには正しく応答することは確認できていた ・実際には想定範囲外のリクエストで発生 → エンドツーエンドのテストが不足 ・Observability ・エラーレート / レイテンシ / RPS / CPU / Mem は監視できていた ・レスポンスボディのバイトサイズの変化に関する監視項目が不足 ※ いずれも現在の Guardrails(Section 3 で述べた仕組み)では捕捉できる機能にアップデート済み 

© Recruit Co., Ltd. All Rights Reserved ガードレールの継続的改善ループ 27 ■ 障害から学び、ガードレール自体を継続的に改善する 4 ステップのループ: 障害発生 (Incident) → 学習 / 振り返り (Learn) → ガードレール改善 (Improve) → 運用知見をプロダクトに還元 (Feedback) 完璧な統制を最初から目指すのではなく、 運用知見をプロダクトに還元し続ける営み ■ 問いかけ: では、この改善ループを支えているのは何か ? 

© Recruit Co., Ltd. All Rights Reserved 継続的改善を支えるのは Platform as a Product 思想 28 「Platform as a Product 思想」 ■ 中身 ・プロダクトとして利用者と対話し、フィードバックで進化させ続ける運営マインド ・「最初から完璧を目指す」のではなく、「使われ続けながら磨かれる」ことを前提に設計する ■ 時代を通じて不変の運営マインド ・AI 時代でも、これが継続的改善を支える基盤 ・主体が人間でも Agent でも、運営の構え方は同じ → Platform Engineering の最重要思想が AI 時代でも不変 

© Recruit Co., Ltd. All Rights Reserved 普遍性の再認識 — 何が変わり、何が変わ らないか Section 5 

© Recruit Co., Ltd. All Rights Reserved ここまで「変化」を語ってきた 30 ■ サマリ：何が変わったのか ・変更発生主体 : 　　　　人間中心 　　　　　　　 → 人間 + Agent 協働 ・変更生成量と認知負荷 : 人間の認知範囲内 　　 　　→ 認知範囲を超える領域が発生 ・中核機能の重み : 　　　Golden Paths への注力中心 → Guardrails の役割範囲・深さの大幅拡張 → だが、これによって Platform Engineering の「すべて」が変わったのか ? 答えは NO! 

© Recruit Co., Ltd. All Rights Reserved 最も深いレイヤを見ると… 目的の本質が見えてくる 31 ■ Slide 3 で語った Platform の 機能 「利用者の生産性をスケールさせる仕組み」「認知負荷の削減・標準化・境界設計」 ■ Platform Engineering の目的 「利用者が価値創出に集中できる状態を、組織横断でスケールさせる」 ・我々の Platform を 10 年運営してきた一貫した目的 ・業界(CNCF)が示す Platform Engineering の本質(flow of value の改善)とも一致 ■ AI 時代でも、この目的は変わらない ・変更主体が AI に拡張されても、「価値創出に集中できる状態を組織横断で実現する」という目的は不変 

© Recruit Co., Ltd. All Rights Reserved 構造も変わっていない — 「境界設計」という営みは不変 32 認知負荷削減の本質は 「何を見せ、何を見せないかを設計する」 こと = 「境界設計」 の営み ■ 境界設計の 2 つのモード ・誘導の境界 ─ Golden Paths: 進むべき道を提示する (認知負荷を下げる) ・制約の境界 ─ Guardrails: 逸脱を防ぐ (質を担保 / 認知範囲を超えた事態を抑止) ■ 変わるのは 境界設計の対象 ・人間向け : 抽象化レイヤの境界 ・Agent 向け: コンテキストレイヤの境界 人間向け 複雑性を 設計（抽象化・隠蔽）する (抽象化レイヤの設計 ) Agent 向け 探索空間を 設計（境界付け）する (コンテキストレイヤの設計 ) Platform Engineering の「最適な境界設計を選び続けるという営み」は不変 

© Recruit Co., Ltd. All Rights Reserved 人間の役割の中身は変わる。しかし人間が果たすべき機能 は引き続き重要 33 10 年間の運営においても技術・組織変化により 人間の役割の中身は変わってきた 。 しかし人間の果たすべき機能は変わらず重要だった ■ Agent には委ねられない 3 つの機能 ・意思決定と価値判断 : 何を解くべきか、何が良い解か (AI は与えられた問題を解くが問題選択は人間の領域) ・コンテキスト解釈と提供 : ビジネス・組織・ドメインの文脈を解釈し、AI へ提供。出力の解釈も人間が担う ・最終責任の所在 : Agent には負わせられない倫理的判断と最終責任を人間が保持する AI 時代でも、これら 3 機能は変わらない ─ 人間の希少資源は 「Agent には委ねられない判断」に再配置することを繰り返していく 

© Recruit Co., Ltd. All Rights Reserved 最後に 

© Recruit Co., Ltd. All Rights Reserved 実は同じ思想構造が、複数の場所で語られてきた 35 ■ 時代を通じて反復されている同型構造 ・和田卓人（t_wada）氏「質とスピード」 ── 質を犠牲にしてもスピードは出ない、質への投資がスピードを支える ・SRE 「エラーバジェット」 ── 信頼性予算が技術的なチャレンジを可能にする ・本登壇の「攻めと守りの両立」 ── 拡張・深化された Guardrails (質) が Agent 主導の生産性を真の生産性に変換する これらはすべて 「質への投資が、速度の真価を発揮させる」 という同じ思想構造 

© Recruit Co., Ltd. All Rights Reserved 今日から問うべき 3 つの問い 36 AI 時代に「何を変え、何を変えないべきか」は対峙している問題、組織、段階によって異なるはず Q1 変えていくべきものを認識できているか ? AI 時代に、自社の Platform で「変えていくべきもの」を明確に認識できているか? → 本登壇の例では「 Guardrails の役割範囲・深さ、境界設計の対象 」 Q2 変わらないもの・変えてはいけないものを言語化できているか ? 同時に「変わらないもの」「変えてはいけないもの」は何かを言語化できているか? → 本登壇の例では「 (本質的な目的、提供機能の構造、人間が担う機能、運営マインド )」 Q3 両立する仕組みをどのように実現できるか ? 変化を取り込みつつ不変を保つ仕組みを実現するには何をどうすればいいのか? → 本登壇の例では「（ Guardrails の）質への投資が、（ Agent の）速度の真価を発揮させる」 

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

© Recruit Co., Ltd. All Rights Reserved データ推進室に関する以下ページもぜひご覧ください 38 データ推進室　特設採用サイト https://www.recruit.co.jp/employment/mid-career/data_lp/ データ推進室　X（旧Twitter）アカウント https://twitter.com/Recruit_Data データ推進室　ブログ https://blog.recruit.co.jp/data/ テック職種イベント情報（開催日程、アーカイブ） https://www.recruit.co.jp/special/tech-info/ 

© Recruit Co., Ltd. All Rights Reserved ご清聴ありがとうございました