Platform Engineering Unit Application Platformグループ 辻⽥ 美咲 実録・Platform Engineering 失敗から学び、AI 時代の波を乗りこなす技術 Sansan Tech Talk @関⻄ 

辻⽥ 美咲 Sansan株式会社 Platform Engineering Unit Application Platform Group 新卒でバックエンドエンジニアとしてキャリアをスタート。 フロントエンド、クラウドインフラ領域などの経験を積み、 2021年にSansanに⼊社。 現在は関⻄⽀店でPlatformエンジニアとして全社横断 Platform Orbitの開発およびプロダクトマネジメントに 従事している。 

アジェンダ 1.Orbitとは 2.Platform Engineeringの成功と失敗 3.Platform Engineering × AIのこれから 

Orbitとは 

Orbitとは？ 開発者が本質的な課題（エンドユーザーに 価値を提供するための開発作業）に 取り組む時間を最⼤化することを⽬的として 構築された、コンテナアプリケーションの 実⾏基盤。 Google Kubernetes Engine (GKE) Autopilot を中核技術として採⽤しており、CI/CD、 監視、セキュリティ、ネットワーク設定などを 「Golden Path（舗装された道路）」として 統合的に提供する。 

「インフラ専任エンジニアの不在」が招いた運⽤の限界 幅広い領域の専⾨知識が必要となり、認知負荷が増⼤ Orbit誕⽣の背景 ✕ 乖離 実環境と Terraform の定義に乖離 ✕ 意識の希薄化 セキュリティやコストへの意識不⾜ ✕ 管理不⾜ 監視ダッシュボードが疎かになる ✕ 属⼈化 CI/CD パイプラインの ブラックボックス化 詳細:「その開発、認知負荷⾼すぎませんか？」Platform Engineering で始める開発者体験カイゼン術 

これまでのタイムライン 2024/08 2024/09 2025/01 2025/02 2024 2025/01 2026 Platform Engineering Jump Start に参加 Platform 開発開始 実運⽤開始 利⽤チーム数 1→7へ成⻑ 

Platform Engineeringの成功と失敗 

Success 1: 抽象化とテンプレート Webアプリ Template K8sのベストプラクティス を内包したHelm Chart。 複雑なマニフェスト管理 を隠蔽。 10個ほどのマニフェスト ファイル 1つのvalues.yaml CI/CD Template セキュリティスキャン、 ビルド、デプロイの フローをGitHub Actions のReusable workflowsで 共通化。 Terraform Modules IAMやアラート設定を抽象 化。数百⾏のHCL 数⼗⾏のmodule呼び 出し 成果: デプロイ頻度の向上、リードタイムの削減、セキュリティレベルの均⼀化 

“社内エンジニアを「顧客」として定義する” 1. ユーザの声を聞く a. インタビュー、アンケート、オフィスアワーの徹底 b. Embedded SRE i. 個別チームに深く⼊り込んで直接⽀援 2. 論理的な優先順位 a. 専任 PdM を置き、全体最適に基づいたロードマップ策定 b. ビジョンステートメントの策定 3. エンゲージメント強化 a. ランチ会やフォローアップ定例による信頼関係 Success 2: Platform as a Product 3.5 X 利⽤チーム数の伸び（FY18 -> FY19） Google Cloud 利⽤時の デファクトスタンダード化を 推進 

Failure 1: 技術的制約 Autopilot 特有の制限 特権コンテナ（privileged: true）が 利⽤できない、動的リソース割り当て （DRA）が使えない、など Googleがノード管理を完全に引き受ける が、その引き換えに様々な制約が存在。 対策: 1. 特権モードが必要な特殊ワークロードはGKE 外で実⾏。GKE 上で動作しているかどうかは、 ユーザの関⼼事ではない。 2. MIG（multi-instance GPUs）でGPUを効率的に 使⽤し、カスタムComputeClassでSpot インスタンスの優先利⽤することでコスト効率 的を最適化 Gateway Controllerでの IAP 権限設定が不便 IAPの有効化⾃体はマニフェストで 可能だが、Backend Serviceの名前が ⽣成されるまで不明なため、IAM権限を 事前に定義できない。これにより、 リソース作成後にIAM設定を⾏う必要が ⽣じ、作業のタイムラグが発⽣。 対策: Google Cloud さんに機能リクエストは出しつつ、 ⾃分たちでカスタムコントローラーを実装すること を検討中。 

Failure 2: 初期構築の複雑さ ⾼度な機能統合により、 設定が複数リポジトリに分散 - Google Cloud プロジェクト管理 - リポジトリ管理 - Argo CD Application 管理 - アプリケーション⽤ k8s マニフェスト管理 開発者の声 Q. Orbitは使いやすいですか？ 50%以上 :「どちらともいえない」 

Platform Engineering × AIのこれから 

Platform Engineering × AI AI Agent による “⾃⼰解決” → セルフサービスの推進 開発チーム Orbit ⼤量のドキュメント&⼿作業 やりたいこと / 知りたいこと を伝えるだけ Orbit AI Agent 開発チーム Orbit 

① ⾃⼰解決の促進 Orbit AI Agentの導⼊ 

② 作業代⾏ Orbit AI Agentの導⼊ 

アーキテクチャ 

マルチエージェントの仕組み Orbit Coordinator (親) ユーザの意図を判断し振り分け Onboarding Agent 作業代⾏・ツール実⾏ - Git 操作 - PR 作成 Docs Search Agent 知識検索・回答 - ドキュメント検索 - 回答⽣成 

導⼊効果 開発者の声（定性評価） 「前に作成したリソース名、namespace名を忘れた時に聞くと教えてくれるのは素敵」 「チャットベースで聞けるので、プラットフォーム管理者に都度聞かなくていい。 気兼ねなく使えるのが良かった（⼼理的ハードルの低下）」 今後計測する指標 - オンボーディング完了までの平均時間 - プラットフォームチームへの問い合わせ件数 

まとめ: AI時代の技術戦略 "Problem-First Strategy" 課題を特定し、「認知負荷」を極限まで下げることが、 これからのPlatform Engineeringの鍵となる。 そのために必要な技術を選択する。 学び 失敗こそが本質への道を 切り開いた 未来 最適な技術で実現する 真のセルフサービス 

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/ 

No content