はじめに
みなさんこんにちは。Platform 開発チーム SREでサブマネージャーの安達（@adachin0817）です。この記事は、ファインディエンジニア Advent Calendar 2025の5日目の記事です。今回は2025年のSREチームの成果や課題などを振り返りたいと思います。
Platform SREチーム ビジョンの再定義
「SREの文化を組織全体に根付かせ、開発チームが自律的にSREを実践できるように支援する」
このビジョンを元に、Platform開発チーム SRE(以下、Platform SRE)チームの方向性を再定義しました。これまでもビジョン自体は存在していたものの、メンバーの役割や責任範囲など曖昧で、チームとしてどう実現していくのかが十分に描き切れていませんでした。そのため、2025年に向けてビジョンをブラッシュアップし、具体的な行動指針へと落とし込みました。
また、ミッションは半期ごとに見直す運用へと変更しました。従来は年間を通して固定したミッションで動いており、課題や状況など大きく変化することが分かりました。そのため、より柔軟な意思決定と、チームメンバーの意志を反映できる仕組みにアップデートしました。
次は、2025年 Platform SRE ロードマップを解説します。
2025年のPlatform SREロードマップ
- AI活用
- DevinやAI補助による運用・構築の自動化
- Observability
- SLI/SLOの見直し
- Datadog RUMの検証
- Cost
- パフォーマンス予測モデル導入
- MCPによるコスト最適化
- Security
- アプリケーション脆弱性対応
- Takumi導入
- Shisho Cloud棚卸し
- Infrastructure
- Team+ 本番DBクローン ワークフロー作成
- Tools/Conference 本番DBのためのStgマスキングワークフロー作成
- 負荷試験環境
- ログ基盤の設計
- WordPressをShifterに移行
- Terraform汎用モジュールの拡充
- aws-nukeによる不要リソースの自動削除
- Findy Team+ マーケットプレイス対応
- CI/CD
- デプロイの共通化
- GitHub Actionsのテンプレート化
- ecspressoの導入
- デプロイの共通化
- Automation
- 社内ツール実装(Go)
- 新規AWSアカウント作成業務の自動化
- Onboarding
- 新規ジュニアメンバー教育
- Culture
- SRE文化醸成
2025年のPlatform SREチームは、開発チームが自律的にSREを実践できる組織を目指し、8つの領域にフォーカスしてロードマップを策定しました。単なる改善タスクではなく、SREを仕組みと文化としてチームに埋め込むことを重視しています。
次は特に注力した取り組みについてまとめていきます。
主に取り組んできたこと
Devinの活用
SREチームでは、新サービスが追加されるたびに、Shisho CloudとAmazon Security LakeをTerraformで連携しています。しかし、この設定手順は非常にシンプルでありながら毎回人手で作業することがトイルとなっていました。
そこで、Devinを活用した自動化に取り組み、Terraform連携を含む一連の作業をワークフロー化しました。さらに、GitHubアカウントの発行、AWSアカウントの作成、WordPressの軽微な修正などもDevin化し、SREのトイルを大きく削減できています。今後は、これらの仕組みを横展開し、より広く標準化していく予定です。
Terraform汎用モジュールとtestの拡充
今年からは、新サービスをより高速に構築するため、Terraformによる汎用モジュールの整備に本格的に取り組みました。 これまでは既存コードの流用をベースに構築していたため、設定の漏れや環境差異を適切に把握できない状態が続いていました。
その課題に対し、Terraformの汎用モジュール化と Terraform Test の拡充することで、Apply前に失敗や設定ミスを検知できる仕組みを構築しました。これにより、信頼性を担保しながらもスピード感のあるインフラ構築が実現できるようになったと感じています。
Findy Team+ 本番DBクローン ワークフロー化
これまでは、Embedded SREが手動で本番DBのスナップショットを取得し、開発チームがそれを基にバッチテストや検証していました。しかし、テスト環境の構築に時間がかかるだけでなく、実際の運用に近い再現性が担保しづらいという課題がありました。
そこで、2025年からは 本番DBクローンを自動で生成できるワークフローを実装しました。この仕組みにより、バッチ処理を含むパフォーマンステストや検証作業を誰でも再現性高く実施できる環境が整備されました。安全性の確保にも配慮し、クローンDBは本番DBと隔離された環境で動作、アクセス制御を厳格に適用、本番相当のデータでテスト可能という形で、リスクを防ぎつつ、実運用に近いテスト環境を実現しています。
クローンDBの作成および削除は、すべてAWS CLIによるワークフローとして自動化しています。また、バッチのパフォーマンステストについては、Operationコンテナ上でAPIと同等の環境を再現しており、本番に近い条件での検証を行えるようになりました。
Findy Team+ AWSマーケットプレイス対応
Findy Team+では、AWSマーケットプレイスへの掲載準備が本格的に始まりました。これまでの直契約モデルから、AWS経由で利用できるモデルという選択肢が増えます。特にエンタープライズ企業では、調達プロセス・セキュリティ基準・契約形態・監査プロセスなどのハードルが高く、SaaS導入の初動でつまずくケースが少なくありません。その中で、AWSマーケットプレイス経由の契約であれば調達がスムーズになるため、AWS経由で使えることが導入条件になる企業でもTeam+導入の壁がさがることを期待しています。
今回の対応により、Findy Team+はエンタープライズ向けのSaaSとしての提供価値をより明確にしていくフェーズに入ったと考えています。
Takumi SAST/DASTの導入
Shisho Cloudを運用していく中で、アプリケーション層の脆弱性も同じ仕組みで検知・可視化したいという課題が生まれました。そこで、コード診断に特化した Takumi（SAST / DAST）を全サービスへ導入し、セキュリティ領域の基盤整備を進めました。
SASTによる静的解析ではコードの脆弱性を早期検知できるようになり、DASTによる動的解析では実行可能な攻撃パターンの再現・検証ができるようになりました。その結果、「診断 → 可視化 → 修正 → 再検証」 というサイクルが開発メンバーの中で自然と回り始め、SREチームによる支援型セキュリティの形が実際に機能し始めています。
また、DASTによるブラックボックス診断については、来年のSRE Kaigi 2026でもGMO Flatt Security CTO 米内さんと発表予定です。セッションではAI時代におけるセキュリティ戦略や、その実践的な導入アプローチについて具体的にお話しますので、ぜひご参加いただき、これからのセキュリティの在り方を一緒に考える機会にできれば嬉しいです。
／#srekaigi 協賛します！
— GMO Flatt Security株式会社 (@flatt_security) 2025年11月12日
＼
GMO Flatt SecurityはSRE Kaigi 2026にダイヤモンドスポンサーとして協賛いたします！
ファインディSRE 安達様 @adachin0817 と弊社CTO 米内 @lmt_swallow によるスポンサーセッションも予定しています！
ぜひお越しください💁🏻♂️https://t.co/HvZtuL7rBL
2026年に向けた展望と課題
来年はSREチームとして、今年の取り組みを「仕組みを作る段階」から「仕組みを運用し、継続的に改善していく段階」へ移行していく予定です。単にSREの知識を展開するだけではなく、開発チーム自身が自律的にSREの判断・運用ができる状態を、より強く推進し、Enablingしていきたいと考えています。
おわりに
2025年は、SREチームにとって仕組みづくりと文化づくりの両輪で走り続けた1年でした。振り返ってみると、改善することよりも、なぜ改善するのか？どうあるべきなのか？を問い続ける1年だったように感じます。
まだまだロードマップは対応できていないものもたくさんあるのと、来年は今年つくった仕組みを本格運用フェーズへ進めつつ、開発チームが自律的にSREを実践できる組織づくりに挑戦していきます。
明日はjiskanuloさんになります！見ていただきありがとうございました。
