ci-cd-architecture

CI/CD とデプロイ

概要

CI/CD パイプラインの設計、デプロイ先の選定、本番環境のインフラストラクチャを扱います。セキュリティを強化した GitHub Actions（OIDC、権限のスコープ設定、アクションのピン留め）、Bun を優先したビルド最適化、MVP からエンタープライズ規模までのデプロイパターンに重点を置いています。

使用する場面： GitHub Actions のワークフローの設定、デプロイ先の選定、クラウドプロバイダー向け OIDC の設定、CI のパフォーマンス最適化、複数環境のパイプラインの計画。

使用しない場面： アプリケーションレベルのアーキテクチャに関する判断（フレームワーク固有のスキルを使用してください）、Kubernetes クラスターの管理（専用の IaC ツールを使用してください）、クラウドプロバイダーのコンソール設定。

クイックリファレンス

ニーズ	解決策
MVP のデプロイ（ユーザー数 1,000 人未満）	Vercel、Netlify、Railway、Cloudflare Pages
成長中のプロダクト（1,000～100,000 人）	AWS Amplify、Cloud Run、Fly.io、Render
エンタープライズ（100,000 人以上）	AWS ECS/EKS、GKE、DigitalOcean App Platform
静的サイト	Vercel、Netlify、Cloudflare Pages
フルスタック＋DB	Railway、Render、AWS Amplify
グローバルな低レイテンシ	Cloudflare Workers、Vercel Edge、Fly.io
コンプライアンス（HIPAA、SOC 2）	AWS、GCP、Azure
CI からのクラウド認証	OIDC ロール（有効期間の長いキーは使用しない）
アクションのピン留め	タグではなくコミット SHA にピン留めする
Bun CI キャッシュ	~/.bun/install/cache をロックファイルに基づくキーでキャッシュ
パイプラインのセキュリティ	外向き通信の制御に StepSecurity Harden-Runner を使用
コンテナーのビルド	マルチステージ Dockerfile：ビルダー＋ランタイムステージ
Docker レイヤーキャッシュ	buildx では --cache-from と actions/cache を使用
マルチプラットフォームビルド	linux/amd64,linux/arm64 を対象に docker buildx を使用
イメージスキャン	プッシュ前のパイプラインで Trivy または Snyk を使用
レジストリへのプッシュ	GHCR（ghcr.io）、ECR、Docker Hub
パイプラインのステージ	ビルド → テスト → セキュリティスキャン → デプロイ
DORA：デプロイ頻度	サービスごとの日次／週次デプロイ数を追跡
DORA：リードタイム	コミットから本番環境までの時間。目標は 1 時間未満
DORA：変更失敗率	インシデントを引き起こしたデプロイの割合。目標は 5% 未満
DORA：MTTR	復旧までの平均時間。目標は 1 時間未満

よくある間違い

間違い	正しいパターン
長期間有効な AWS/GCP/Azure キーを GitHub シークレットに保存する	ゼロトラストのクラウド認証には、id-token: write 権限を持つ OIDC ロールを使用します
GitHub Actions をコミット SHA ではなくタグに固定する	サプライチェーン攻撃を防ぐため、サードパーティ製アクションは完全なコミット SHA に固定します
ワークフローの permissions をデフォルト（広範な権限）のままにする	ジョブレベルで権限を明示的に制限し、デフォルトを contents: read にします
ブランチへのプッシュごとに CI 全体を実行する	無駄なコンピューティングを避けるため、on.pull_request のフィルターとパスベースのトリガーを使用します
プロダクト・マーケット・フィット前にインフラを過剰に設計する	マネージドプラットフォーム（Vercel、Railway）から始め、必要になった段階でのみ AWS/GKE に拡張します
古いアクションのバージョン（v3 以前）を使用する	現行のメジャーバージョンを使用します：checkout@v6、cache@v5、configure-aws-credentials@v5
bun.lock を考慮せず、bun.lockb のみをキャッシュする	Bun 1.2 以降ではテキスト形式の bun.lock を使用します。プロジェクトで使われているロックファイル形式に応じてハッシュを計算します
PR のプレビューデプロイを省略する	マージ前にテストできるよう、すべての PR にプレビュー URL を用意します

他のスキルとの関係

github-actions スキルを利用できる場合は、詳細なワークフローの作成、マトリックス戦略、複合アクションについてはそちらに委任してください。このスキルでは CI/CD アーキテクチャとプラットフォームの選定を扱い、github-actions ではワークフロー構文を詳しく扱います。 deployment-strategy スキルを利用できる場合は、デプロイパターン（ブルーグリーン、カナリア、ローリング）の選定についてはそちらに委任してください。このスキルではプラットフォームの選定と CI パイプラインの仕組みを扱います。

委任

• 既存の CI ワークフローのセキュリティと権限を監査する：Explore エージェントを使い、ワークフローの YAML ファイルを調べて、広範な権限、固定されていないアクション、露出したシークレットを確認します
• 複数環境に対応したデプロイパイプラインを設定する：Task エージェントを使い、環境保護ルールを備えた dev/staging/prod ワークフローを作成します
• マネージドプラットフォームからコンテナ化インフラへの移行を計画する：Plan エージェントを使い、現在のデプロイを評価して、移行手順を定義し、移行先のアーキテクチャを選定します

参考資料

• GitHub Actions のワークフロー、OIDC、マトリックスビルド、セキュリティ強化
• デプロイパターン：Jamstack、サーバーレス、従来型、マイクロサービス
• プラットフォーム選定フレームワーク、データベースの要件、コスト最適化
• モニタリング、可観測性のレベル、デプロイチェックリスト
• コンテナビルド：マルチステージ Dockerfile、レイヤーキャッシュ、buildx、イメージスキャン、レジストリへのプッシュ