Webリリースフローの全面刷新 - 頻度を上げて改善を回しやすく

クラスターでWebフロントエンドをメインに担当しているmt_blue81です。週次リリースから日次リリースへ移行を進め、GitHub Actionsのワークフローを全面的に見直しました。この記事ではその知見と今後の展望を紹介します。

1. なぜ変えたのか

自動化されていたが、さらなる加速を目指して

clusterは、iOS・Androidなどのモバイルアプリ・PCアプリ（Windows・Mac）・VR等マルチデバイスに対応したアプリであり、毎週アプリのアップデートを行っています。
WebのリリースフローはすでにGitHub Actionsで自動化されていました。しかし、Android・iOSなどマルチプラットフォームのウィークリーリリースに同期しているという制約がありました。

各プラットフォームでリリースタイミングを揃えることで、ユーザー体験の一貫性を保ち、リリースノートの管理も簡素化できます。QAフェーズも共通化でき、品質保証の効率が高められていました。しかしその一方で、Web特有の課題も生まれていました。

Webプラットフォームの特性はデプロイの柔軟性にあります。モバイルアプリのようなストア審査も不要で、サーバーへのデプロイだけで即座にユーザーに届けられます。にもかかわらず、週1回のリリースサイクルに縛られていたため、以下のような状況が発生していました。

軽微な改善が1週間待機状態になる
バグ修正の反映が遅れる¹
A/Bテストや施策の高速なイテレーションが困難

「改善サイクルを回しやすくする」。これが今回のリリースフロー刷新の最大の目的でした。²

「加速していく」カルチャーが後押し

クラスターは 「加速していく」 を大切な価値観として掲げています。この文化が、既存のやり方を変える挑戦を後押ししました。

2025年8月中旬、Design Doc ³ の作成を始めました。そこからおよそ1ヶ月の検討期間を経て、9月中旬に新しいデイリーリリースフローの運用を開始することになります。

2. どう変えたのか

Design Docから始める段階的アプローチ

リリースフローの刷新という大きな変更を進めるにあたり、まずDesign Docの作成から始めました。これは思考実験として全体像を整理し、関係者との合意形成を図るためです。

Design Docを作成後、GitHub Actions有識者やバックエンドエンジニアにレビューを依頼しました。このレビュープロセスを通じて、以下のような課題や懸念点が明らかになりました。

他プラットフォームとのバージョン管理の整合性
リリースノートの扱い方
ロールバック手順の明確化
セキュリティ面での考慮事項

Design Docという形で一度立ち止まって検討することで、実装前に多くの問題を洗い出すことができました。

安全に進めるためのアプローチ

リリースフローの変更は、ビジネスに直結する重要な変更です。安全に進めるため、以下のようなアプローチを取りました。

関係者との密なコミュニケーション

特にPM（プロダクトマネージャー）とは、リリース方針について密に調整しました。

リリースノートの運用方針
- ウィークリー単位でまとめるのか、デイリーで細かく出すのか
- 他プラットフォームとの整合性をどう保つか
リリース情報の整理タイミング
- どのタイミングでステークホルダーに情報を共有するか
- リリース内容の優先度判断

段階的な検証プロセス

実装から運用開始まで、以下のステップを踏みました。

思考実験: Design Docでの全体設計
細分化: 機能ごとに小さなPRに分割
レビュー: 各PRで丁寧なコードレビューを実施
dev検証: 開発環境での疎通確認

特に開発環境での検証では、予想どおりではありますがいくつか問題が見つかりました。条件分岐や情報の受け渡し、slack通知まわりなど、試しながら完成させていきました。

実際の改善内容

では、具体的にどう変わったのでしょうか。

Before: ウィークリーリリース（全PF同期） - 水曜日: 動作確認用のビルド作成開始 - 木曜日: すべてのプラットフォームで動作確認 -> ストア申請 - 月曜日: すべてのプラットフォームを一斉リリース - リリース対象: 前週の開発内容すべて - サイクル: 週1回固定

After: デイリーリリース（Web独立） - 月曜日: 他プラットフォームとのバージョン合わせ - 月-金曜日: Web単独でデイリーリリース可能 - サイクル: 基本的に毎日（必要に応じて）

改善の前後を比較すると、以下のようになります。

Before: ウィークリーリリース（全PF同期）

After: デイリーリリース（Web独立）

AIを活用したGitHub Actions構築の実践

GitHub Actionsのワークフロー構築では、Claude CodeやGitHub Copilotを活用しました。AIに雛形を生成させることで、初期実装の時間を大幅に短縮できました。普段あまり触れることのないシェルスクリプトについても、AIの支援により効率的に学習しながら実装を進められました。

具体的には以下のような流れで進めました。

AIで基本的なワークフローの雛形を生成
- デプロイフロー、ロールバックフロー、通知フローの基本構造
- 既存フローからの移行を考慮した設計
- Design Doc作成と並行して行い、Design Docのインプット、補足資料としても活用
社内のGitHub Actions有識者によるレビュー
- セキュリティベストプラクティスの確認
- エラーハンドリングの改善提案
- 保守性を高めるための構造化
Reusable Actionによるモジュール化
- 共通処理を再利用可能なコンポーネントとして切り出し
- 単体テストが容易になり、品質を担保しやすく
- 他のワークフローでも活用でき、チーム全体の効率化に貢献

AIツールの活用により初期実装の時間を大幅に短縮しつつ、専門家のレビューを通じて品質を担保する、という流れで進めることができました。

3. 何を得たのか

改善が回しやすくなった成果

リリースサイクルの変更により以下のような成果が得られました。

バグ修正を即座にユーザーに届けられるようになった
新機能のリリース後、ユーザーフィードバックに基づく改善を翌日には反映可能に
A/Bテストや施策の高速なイテレーションの土台を実現

実際、運用開始後すぐにその効果を感じる場面がありました。トップページの不具合を発見した際、以前であれば最大1週間ユーザーに影響が出ていたところを、対応完了翌日には修正版をリリースできました。現在は毎日手動でリリースを実行していますが、スケジュール実行による自動化も今後の検討事項です。

Web固有の改善を迅速に反映

他プラットフォームとの同期から解放されたことで、Web特有の改善を提案・推進しやすくなりました。

CSSアニメーションの微調整
パフォーマンス改善の段階的な適用
ブラウザ固有の問題への迅速な対応

これらは以前であれば「週次リリースまで待つ」必要があったものが、必要なタイミングで投入できるようになりました。

今後の展望

この取り組みは、ゴールではなくスタート地点です。以下、今後取り組んでいきたい内容を紹介します。

nx差分デプロイによる更なる効率化

クラスターのWebプラットフォームでは、nxというモノレポ管理ツールを使用しています。nxでは変更のあったパッケージだけをデプロイする「差分デプロイ」も可能でしたが、今回はまず全体リリースで新フローの確実性を確保することを優先しました。将来的にはnxによる差分デプロイで、さらなる効率化を図る予定です。

また、今回の取り組みで構造化できた部分も多く、フロー自体をさらに改善しやすくなったと考えています。