はじめに
こんにちは！
株式会社オズビジョン ハピタス事業部 開発グループ所属の天野です。
普段はインフラ領域の開発を担当していませんが、CDK（TypeScript）を使うことで身近な運用課題を自動化できました。具体的には、Google Calendar と AWS のマネージドサービスを組み合わせ、テスト環境運用の負荷やミスを減らす自動化を実装しました。本記事では、その背景と要件、アーキテクチャ、CDK/TypeScript の実装方針、そして運用と通知の流れまでを紹介します。
解決したい課題
ハピタスの開発にはテスト環境が用意されていますが、環境数に限りがあります。
そのためエンジニアは同時刻に他メンバーと利用が重複しないよう、事前に Google カレンダーへ予約を登録します。カレンダー上で予約が取れた場合、CodePipeline の設定でデプロイ対象ブランチを必要なブランチへ切り替えてデプロイします。
テスト環境の利用後は、手動でブランチをデフォルトに戻す運用でした（デフォルトブランチは本番と同期）。
しかし戻し忘れが発生し、「本番と同期した機能を動作確認できない」、「開発途中機能が表示されたまま」 といった不具合につながりました。そこで、この「デフォルトブランチに戻す」作業を自動化しました。
現状の運用フロー（As-Is）
現状の手順とリスクを図示します。
自動化後の理想フロー（To-Be）
自動化後の流れ（目標）を図示します。
リリースしたもの
機能の概要
- Google Calendar の予約状況を参照し、未予約の環境に対して CodePipeline の参照ブランチをデフォルト(
release)に戻す- カレンダーに予約がない場合は、本番と同期したデフォルトブランチに戻す必要がある
- スケジュール実行（EventBridge）で定期チェックし、条件に合致するパイプラインのみ更新する
- 更新後はパイプラインを起動し、最終的に CodeDeploy でデフォルトブランチ(
release)の内容をデプロイする - Slack に成功/失敗の通知を送信する
Slack に通知される様子
Slack 通知の例_1
Slack 通知の例_2
システムの詳細
処理フロー（概要）
- ① EventBridge が 5 分おきに Lambda を起動
- ② Lambda が Secrets Manager から Google 認証情報/Slack Webhook を取得
- ③ Google Calendar のイベントから未予約環境を判定
- ④ 対象の CodePipeline の Source アクションの
BranchNameをreleaseに更新 - ⑤ パイプラインを即時起動
- ⑥ CodeDeploy で反映
- ⑦ 成否を Slack へ通知
全体構成（データフロー ①〜⑦ に対応）
技術スタックと設計方針
- CDK v2 / TypeScript、L2 優先の設計、最小権限の原則
- 背景：TypeScript を選択: チームの知見があり、型安全により保守性を担保できるため
- ランタイム: Node.js 22.x
- 背景：Lambda とローカルの整合性を取り、デバッグ容易性を高めるため
- 依存:
@aws-sdk/client-codepipeline,googleapis,inversifyほか- 背景：Source アクションの
BranchName更新など、最小権限でのピンポイント制御が必要なため
- 背景：Source アクションの
- DI:
inversifyによるテスト容易性・責務分離- 背景：テスタビリティと責務分離を優先し、モジュール単位で差し替え可能にするため
- CloudWatch Logs : ログを 1 週間保持
- 背景：直近の障害解析に十分な期間を確保しつつ、過剰な長期保存を避けてコストを最適化するため
- 障害時: 例外を Slack へ通知・再実行は次スケジュールまたは手動
- 背景：失敗の早期検知と運用状況の可視化を行うため
- CDK Pipelines でインフラ自体も自動デプロイ
- 背景：詳細は以下に記載しました
「CDK Pipelines でインフラ自体も自動デプロイ」についての説明
インフラの CDK スタックは CDK Pipelines で継続的デリバリーしています。
パイプラインは aws-cdk-lib/pipelines の CodePipeline を採用し、synth で cdk synth を実行し、addStage で対象スタックを段階的にデプロイしています。
また、パイプラインの定義自体もソース管理しており、差分がある場合は self-mutation（セルフアップデート）でパイプライン自身を更新します。
なお、初回のみローカルからの cdk deploy（必要に応じて cdk bootstrap）で初期化し、その後は PR ベースで自動反映されます。
こうすることで、手動デプロイを省くことができ再現性が担保できます。またパイプライン差分もセルフアップデートで安全に適用できます。
参考
開発する中で苦労した点
各リソースに必要最小限の権限を付与すること、テスト環境ごとに異なるパイプライン名や Google Calendar の環境名に合わせて設定を整えることに苦労しました。これらは SRE チームのメンバーとペアプロで設計・検証を重ね、順次解消しました。
機能リリース後の反応
リリース後の反応
検証環境の不整合が改善できてとてもいいという声もいただきました。
(なお、リリース直後にいくつか不具合が見つかったため、すぐに修正しました 🫣)
おわりに
本記事では、CDK と Lambda（TypeScript）を用いて身近な運用課題を自動化した取り組みの全体像を紹介しました。普段はあまり触れないインフラ領域でしたが、実際に課題解決に結びつく手応えがありました。TypeScript で CDK を実装したことで、アプリケーション開発に近い感覚でスムーズに進められたのも収穫です。今後も運用で得た学びを反映し、より安全で使いやすい仕組みへ継続的に改善していきたいです。
Discussion