PR単位で使い捨てるカイポケコネクトのpreview環境の設計と運用/ ephemeral preview environments per pr

SRE NEXT2026 にて登壇する資料です。
https://sre-next.dev/2026/schedule/#slot063

弊社のプロジェクト（カイポケコネクト）で品質保証や検証作業のボトルネックを解消するために、PR/ブランチ単位でDBごと使い捨てできるpreview環境を構築・運用してきました。本発表では、その設計と運用のリアルをお伝えします。技術スタックは、フロントエンドにCloudFront + S3、バックエンドにmirage-ecs、DBにNeon、インターフェースにGitHub Actionsを採用しています。
使い方はシンプルで、PRに preview ラベルを付けるだけで環境が立ち上がり、ラベルを外すかPRをcloseすると自動で環境が削除されます。
開発者がPRから離れずに操作を行い、品質保証担当者にスムーズに検証作業を移譲できる体験を重視して設計しました。
導入当時は不確実性が高い状況の中で仮説ベースでシステムの要件を決めて設計・導入しました。仮説の中にはうまく機能したものもあればそうでないものもありました。引き続き課題として残っているものもあります。
実際に仕組みを導入してから一年ほど経過して得られた運用知見や実施した改善施策、今後の課題について紹介します。

Transcript

1. PR単位で使い捨てる カイポケコネクトの preview環境の設計と運用 SRE NEXT 2026/07/10 小笠原翔太 @shotaogasawara 株式会社エス・エム・エス 1
2. 自己紹介 • 小笠原翔太 • 介護/障害福祉事業者向けSaaS「カイポケ」のSRE （開発推進チーム所属） • クラウドサービスやツールを組み合わせて効果的 なソリューションを考えるのが好きです 2
3. 今日の話 既存プロダクトにpreview環境を導入して 1年運用した 話です 3
4. 目次 1. なぜpreview環境を作ったか 2. どう設計したか 3. アーキテクチャ 4. 運用してどうだったか 5. わかったこと・気づき 6. まとめ 4
5. 1. なぜpreview環境を作ったか 5
6. プロダクトと開発フェーズ PRODUCT INFO 介護・障害福祉経営支援領域における、 業務効率化と持続可能な事業運営を支え るSaaSプロダクト SYSTEM ARCH ドメインで分割されたシステム 拡張性と独立性を保つため、ドメインごとに アプリとDBを分割して設計 技術スタック & 構成 • フロント: React/Next.jsを利用した SPA。CloudFront+S3で配信 • バックエンド: Kotlin/SpringBoot/GraphQLを利用し た5サービスで構成される API。ECS Fargateで運用 • DB: PostgreSQLのDBをバックエンド ごとに用意。RDSで運用 • 連携: 複数の社内サービスと連携 DEVELOPMENT PHASE 機能追加・サービス拡大期へ 初期開発フェーズが完了し、プロダクトの 価値を拡大する「機能追加・サービス拡大 フェーズ」に移行 6 → 機能開発を加速 させる必要があった
7. 背景: 当時のリリースフロー → いわゆるリリーストレイン方式を採用していた 7
8. リリーストレインの課題 CYCLE & SPEED リリース周期が長い このプロジェクトのリリースサイクルは2 週間に一度。開発スピードに対して提 供までの遅延が大きく、価値提供のボト ルネックに。 差分肥大化のリスク 2週間分の変更が一度に本番へ行くた め、デプロイ時の事故確率が上昇。問 題発生時のトラブルシュートも極めて困 難な状態 QA BOTTLENECK QA環境の占有 品質保証（検証作業）のためにQA環境 を長期間「占有」せざるを得ない構造 検証の長期化 検証・テストのために約1週間の期間を 確保。その間、他の機能の検証やデプ ロイがブロックされていた HUMAN COST 担当者の負担が大きい リリース担当やリリースマネジャーに運 用作業とリスク管理の負荷が集中して いました 運用の属人化と重厚化 • 差分把握が困難： コード変更内 容の全体像を追うのが困難 • 重厚な手順書： ミスを防ぐため の手動プロセス・手順書が増大 • その他： 調整コスト等の付帯業 務 8
9. 解決策: リリースフローから検証作業を分離して並列化 9
10. リリースフロー改善で得られる効果 CYCLE & SPEED リリースが毎日できる 隔週から毎日リリース へと頻度が上 がり、顧客への価値提供が高速化 変更差分が小さくなるため、問題発 生時の原因特定が容易 に QA PROCESS QAのシフトレフト＆並列化 開発フェーズの中で 本番系適用前に QAを実施 するプロセスへと移行 QAプロセスをチームや機能（ feature） ごとに並列化して ボトルネックを解消 FLEXIBILITY プロセスの軽量化とタイミ ング制御 重厚なリリース手順を廃止 し、リリー スフロー軽量化 リリースフラグ導入 により、デプロイ と新機能有効化を分離。 POが任意の タイミングで新機能をリリース可能 10
11. そのために必要だったのがpreview環境 11
12. 2. どう設計したか 12
13. 必須要件 QAプロセスで必須となる要件 ・十分な数の環境を 容易に 作れる ・利用チームが 任意のバージョン をデプロイできる ・DBは使い捨てできる — データが汚れることを気にせず占有して利用できる 13
14. インターフェース設計 DEVELOPER EXPERIENCE SaaSの開発者体験を参考に設計 • GitHubイベント(ラベル)をトリガー にpreview環境を自 動で構築・更新・破棄 • PRのコメントに自動でアクセス情報を付与 設計の狙い • 開発者・QA間のスムーズな連携 : 開発者がPRに実装 をまとめ、それを担当者へ渡すことでスムーズに検証 作業に移ることができる • ライフサイクル管理のしやすさ : 環境がPRに紐づくた め、不要な環境の消し忘れを防いだり、クリーンな環境 管理が可能 14
15. インターフェース設計 DEVELOPER EXPERIENCE SaaSの開発者体験を参考に設計 • GitHubイベント(ラベル)をトリガー にpreview環境を自 動で構築・更新・破棄 • PRのコメントに自動でアクセス情報を付与 設計の狙い • 開発者・QA間のスムーズな連携 : 開発者がPRに実装 をまとめ、それを担当者へ渡すことでスムーズに検証 作業に移ることができる • ライフサイクル管理のしやすさ : 環境がPRに紐づくた め、不要な環境の消し忘れを防いだり、クリーンな環境 管理が可能 15
16. 3. アーキテクチャ 16
18. 設計時に考えたこと PRINCIPLE 01 基本方針 要件が不明確なうちから作り 込まない 初期段階での過剰な設計や実装を 避ける PRINCIPLE 02 技術スタック選定 なるべく開発や運用の負担が 少ない技術スタックを選定 当時、開発チームのリソースが逼 迫していたため開発負担を極力抑 制 PRINCIPLE 03 アプローチ 最初から完璧を目指さず、継 続的に提供価値を高めていく プロダクトの最終形が見えなかった ため、段階的な改善を積み重ねな がらシステムの完成度を高めるこ とに 18
19. 4. 運用してどうだったか 19
20. 狙い通りリリース頻度を高めることができた 20 → （他の施策と合わせて）サービス拡大期の開発効率向上に貢献
21. preview環境は導入後に要件を見直しながら段階的に改善 21 → PR総数は200件超とタスク総量は多かったが、段階的対応で少人数（導入から運 用初期は担当一人）でも早期導入でき、機能改善を進めることができた
22. 結果的にpreview環境利用数が伸びた 22 → 当初想定していた用途以外で利用が伸びた（後述）
23. 5. わかったこと・気づき 23
24. ① 複製機構の利用技術についてわかったこと BACKEND mirage-ecs ▪ 既存の ECS Fargate 構成 + ecspresso デプロイの仕組みにアドオンする形で導入可能 ★ 親和性が高く、デプロイの仕組みをそのまま維持 ▪ 学習コスト・メンテナンス性 学習コストがほぼ増えず、メンテナンスが簡単 ★ 開発チームの追加負担を最小限に抑制 ▪ 運用の安定性 現在まで、他ソリューションへの置き換え検討が必要となる問題も なく安定して運用できている DATABASE Neon ▪ 直感的で扱いやすい Web UI 高速なブランチ機能、各種管理機能が充実 ★ 初期導入の工数を大幅に削減できた ▪ サーバ配置先の制約による性能課題 DB配置先が最寄りで Singaporeリージョンのため ▼ 接続時のレイテンシーによるパフォーマンス低下がボトルネッ クになっていた ▪ 現在は別方式を主に利用 Aurora Serverless v2 (RDS) 構成をメインに運用 24
25. ② 複製「できない」外部サービスの扱いが難しい ▼ 本体の複製よりも難しいのは複製「できない」外部サービスとの付き合い方 認証基盤 契約プランの制約により新環境用テナントを 作成できなかったため、既存テナントに相乗 りする形で対応 ▶結果的に（特に不便なく運用できているも のの）dev環境のDBをコピーする方式を選 択せざるを得なくなった 社内サービス D アーキテクチャ上の制約により、環境複製の 難易度が高くすぐには実現できなかった ▶既存環境に相乗りし、 preview環境向けの データを識別できるようにアプリを改修して もらい、運用でカバーする形になった 社内サービス S 契約プランや予算管理上の制限があり、環 境複製を行うのが困難だった ▶特定のpreview環境にのみ、期間を決めて 連携を許可する限定的な運用となった 共通の課題 • 外部サービスとの連携が増えるたびに個別に運用の取り決めや調整を行う必要があり、対応コストがかかる • 自チームだけでコントロール・解決できない他部署・他チームの仕様や予算制約が絡むことが多く、難易度を引き上げている 25
26. ③ preview環境の想定外な需要が見えた ▪ 開発現場における想定外の需要 当初はQAプロセスでの利用を想定していたが、実際は全体の 8割 が開発チームの自主的な動作確認・検証目的で利用された QA引き渡しでの利用は全体の 20%にとどまる ▪ 開発者のユースケース 以下のようなユースケースで利用されていた • リスク回避： dev環境デプロイ前の早期のリスク検知 • DB migrationの動作確認： DB migrationの安全な事前検証 • AI並列開発： 複数PRを同時に互いに影響を及ぼさず検証 • ローカル代替： ローカル起動失敗時の一時的な代替・逃げ先 preview環境の 想定外の価値 「容易に立てられる検証環境」が開発体験（ DX）にとって大きな価値となっていた 80% 開発動作確認 QA検証: 20% 26
27. まとめ 01 / FEASIBILITY 環境運用の実現性 今回採用した技術スタックでも中規 模システムのpreview環境は十分に 運用可能 ★少人数で運用でき、かつ開発負担を小 さくできた 02 / CHALLENGE 外部連携の課題 連携サービスをどう運用するかが大 きな課題になりえる ▼本体の複製以上に、複製「できない」外 部サービスとの適切な連携設計が必要 03 / EVOLUTION 導入後の進化が重要 （小さく作る場合は）運用に乗ってか らの継続的な改善が本番 •プロダクトの成長の中で明らかになる 要望に合わせた継続的な進化が必要 27 既存プロダクトにpreview環境を導入・運用して見えてきたこと
28. ご清聴ありがとうございました！ 28