Remix 本番運用チェックリスト：ビルド・監視・バックアップ・脆弱性対応

2025年11月4日

Remix

Remix アプリケーションを本番環境にデプロイした後、安定した運用を続けるためには、ビルドプロセスの最適化、適切な監視体制、確実なバックアップ戦略、そして脆弱性への迅速な対応が欠かせません。

この記事では、Remix を本番運用する際に押さえておくべきチェックポイントを体系的にまとめ、実践的なコード例とともにご紹介します。開発から運用へとスムーズに移行し、安心してサービスを提供し続けるための道しるべとなれば幸いです。

背景

Remix 本番運用の重要性

Remix は、React ベースのフルスタックフレームワークとして、優れた開発体験とパフォーマンスを提供してくれますね。しかし、本番環境では開発時とは異なる課題に直面することになります。

突然のトラフィック増加、予期しないエラー、セキュリティの脅威など、さまざまなリスクが存在します。これらに備えるためには、体系的な運用チェックリストが必要です。

本番環境特有の要求事項

本番環境では、以下のような要求事項が求められます。

可用性: サービスが常に利用可能であること
パフォーマンス: 高速なレスポンスタイムを維持すること
セキュリティ: 脆弱性から保護されていること
監視: 問題を早期に発見できること
復旧: 障害時に迅速に復旧できること

以下の図は、本番運用で考慮すべき主要な要素の関係性を示しています。

mermaidflowchart TB
    dev["開発環境"] -->|デプロイ| prod["本番環境"]
    prod --> build["ビルド最適化"]
    prod --> monitor["監視・ログ"]
    prod --> backup["バックアップ"]
    prod --> security["脆弱性対応"]

    build -->|高速化| performance["パフォーマンス"]
    monitor -->|早期発見| incident["インシデント対応"]
    backup -->|迅速復旧| recovery["障害復旧"]
    security -->|保護| safety["安全性"]

    performance --> service["安定サービス"]
    incident --> service
    recovery --> service
    safety --> service

この図から分かるように、各要素が相互に連携し、最終的に安定したサービス提供につながります。

課題

本番運用で直面する典型的な問題

Remix アプリケーションの本番運用では、以下のような課題に直面することが多いです。

ビルドに関する課題として、ビルド時間が長くデプロイが遅延したり、バンドルサイズが大きくページ読み込みが遅くなったりします。環境変数の管理も煩雑になりがちですね。

監視に関する課題では、エラーの発生に気付くのが遅れたり、パフォーマンスの劣化を検知できなかったり、ログが散在して分析が困難になることがあります。

バックアップに関する課題としては、データベースのバックアップ戦略が不十分だったり、静的アセットの管理が疎かになったり、復旧手順が明確でないことが挙げられます。

脆弱性に関する課題では、依存パッケージの脆弱性を見逃したり、セキュリティパッチの適用が遅れたり、脆弱性スキャンが自動化されていないことが問題となります。

以下の図は、これらの課題がどのように連鎖して影響を与えるかを示しています。

mermaidflowchart LR
    issue1["ビルド遅延"] -->|デプロイ遅延| impact1["復旧時間延長"]
    issue2["監視不足"] -->|発見遅延| impact2["障害影響拡大"]
    issue3["バックアップ不備"] -->|復旧失敗| impact3["データ損失"]
    issue4["脆弱性放置"] -->|攻撃成功| impact4["セキュリティ事故"]

    impact1 --> result["サービス品質低下"]
    impact2 --> result
    impact3 --> result
    impact4 --> result

これらの課題を放置すると、最終的にサービス品質の低下につながってしまいます。

解決策

体系的なチェックリストアプローチ

これらの課題に対処するため、4 つの主要な領域に分けてチェックリストを整備することが効果的です。各領域で具体的な対策を実施することで、堅牢な運用体制を構築できます。

以下の図は、解決策の全体像を示しています。

mermaidflowchart TB
    checklist["本番運用<br/>チェックリスト"] --> area1["① ビルド最適化"]
    checklist --> area2["② 監視・ログ"]
    checklist --> area3["③ バックアップ"]
    checklist --> area4["④ 脆弱性対応"]

    area1 --> action1["・ビルド時間短縮<br/>・バンドルサイズ削減<br/>・環境変数管理"]
    area2 --> action2["・エラー追跡<br/>・パフォーマンス監視<br/>・ログ集約"]
    area3 --> action3["・DB バックアップ<br/>・アセット管理<br/>・復旧手順"]
    area4 --> action4["・依存関係スキャン<br/>・自動更新<br/>・セキュリティ監査"]

それぞれの領域について、具体的な実装方法を見ていきましょう。

具体例

① ビルド最適化チェックリスト

ビルド設定の最適化

まず、Remix のビルド設定を本番環境向けに最適化します。以下は remix.config.js の推奨設定です。

typescript// remix.config.js - ビルド最適化設定
/** @type {import('@remix-run/dev').AppConfig} */
module.exports = {
  // サーバービルドパス（本番環境用）
  serverBuildPath: 'build/index.js',

  // 開発時のソースマップは無効化
  sourcemap: false,

  // 本番ビルド時の圧縮を有効化
  serverModuleFormat: 'cjs',

  // キャッシュディレクトリの設定
  cacheDirectory: './node_modules/.cache/remix',
};

この設定により、ビルド時間の短縮とバンドルサイズの削減が期待できます。

バンドルサイズの最適化

次に、バンドルアナライザーを導入して、不要な依存関係を特定しましょう。

json{
  "scripts": {
    "build": "remix build",
    "build:analyze": "ANALYZE=true remix build",
    "postbuild": "yarn bundle-size-check"
  },
  "devDependencies": {
    "@remix-run/dev": "^2.0.0",
    "bundle-analyzer": "^1.0.0"
  }
}

build:analyze スクリプトを実行することで、バンドルサイズの内訳を視覚的に確認できます。

環境変数の安全な管理

環境変数を安全に管理するため、.env ファイルと型定義を整備します。

typescript// app/env.server.ts - サーバー側環境変数
import { z } from 'zod';

// 環境変数のスキーマ定義
const envSchema = z.object({
  NODE_ENV: z.enum(['development', 'production', 'test']),
  DATABASE_URL: z.string().url(),
  SESSION_SECRET: z.string().min(32),
  API_KEY: z.string(),
});

// 環境変数の検証と型安全な取得
export function getEnv() {
  const parsed = envSchema.safeParse(process.env);

  if (!parsed.success) {
    console.error('❌ 環境変数の検証に失敗しました:');
    console.error(parsed.error.flatten().fieldErrors);
    throw new Error('環境変数が正しく設定されていません');
  }

  return parsed.data;
}

この実装により、起動時に環境変数の妥当性を検証し、型安全にアクセスできます。

typescript// 環境変数の使用例
import { getEnv } from '~/env.server';

export async function loader() {
  const env = getEnv();

  // 型安全に環境変数を使用
  const dbUrl = env.DATABASE_URL;
  const apiKey = env.API_KEY;

  // ... データベース接続やAPI呼び出し
}

ビルドキャッシュの活用

CI/CD パイプラインでビルドキャッシュを活用し、ビルド時間を短縮します。

yaml# .github/workflows/deploy.yml - GitHub Actions でのキャッシュ設定
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      # Node.js のセットアップ
      - uses: actions/setup-node@v3
        with:
          node-version: '18'

      # Yarn キャッシュの設定
      - name: Get yarn cache directory path
        id: yarn-cache-dir-path
        run: echo "dir=$(yarn cache dir)" >> $GITHUB_OUTPUT

      - uses: actions/cache@v3
        with:
          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

キャッシュを活用することで、2 回目以降のビルドが大幅に高速化されます。

② 監視・ログチェックリスト

エラー追跡システムの導入

本番環境でのエラーを確実に捕捉するため、Sentry などのエラー追跡システムを導入します。

typescript// app/entry.server.tsx - Sentry の初期化
import * as Sentry from '@sentry/remix';

// Sentry の初期化（サーバー側）
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,

  // トレースサンプリングレート（本番は10%程度に抑える）
  tracesSampleRate:
    process.env.NODE_ENV === 'production' ? 0.1 : 1.0,

  // リリース情報を含める
  release: process.env.COMMIT_SHA,

  // パフォーマンス監視の有効化
  integrations: [
    new Sentry.Integrations.Http({ tracing: true }),
  ],
});

クライアント側でも同様に Sentry を初期化します。

typescript// app/entry.client.tsx - クライアント側の Sentry 初期化
import * as Sentry from '@sentry/remix';

Sentry.init({
  dsn: window.ENV.SENTRY_DSN,
  environment: window.ENV.NODE_ENV,

  // ユーザー情報の記録
  beforeSend(event, hint) {
    // エラー情報を加工・フィルタリング
    return event;
  },

  // パンくずリストの記録
  integrations: [new Sentry.BrowserTracing()],
});

グローバルエラーハンドラーの実装

Remix のエラーバウンダリーを活用し、エラーを適切にハンドリングします。

typescript// app/root.tsx - グローバルエラーバウンダリー
import { captureRemixErrorBoundaryError } from '@sentry/remix';

export function ErrorBoundary({ error }: { error: Error }) {
  // Sentry にエラーを送信
  captureRemixErrorBoundaryError(error);

  return (
    <html lang='ja'>
      <head>
        <title>エラーが発生しました</title>
      </head>
      <body>
        <div className='error-container'>
          <h1>申し訳ございません</h1>
          <p>予期しないエラーが発生しました。</p>

          {/* 開発環境でのみエラー詳細を表示 */}
          {process.env.NODE_ENV === 'development' && (
            <pre>{error.stack}</pre>
          )}

          <a href='/'>トップページに戻る</a>
        </div>
      </body>
    </html>
  );
}

この実装により、エラーが発生しても適切なメッセージを表示し、Sentry に記録されます。

パフォーマンス監視の実装

Web Vitals を計測し、パフォーマンスの劣化を早期に検知します。

typescript// app/utils/monitoring.client.ts - Web Vitals の計測
import {
  onCLS,
  onFID,
  onLCP,
  onFCP,
  onTTFB,
} from 'web-vitals';

// メトリクスを送信する関数
function sendToAnalytics(metric: any) {
  // Google Analytics や独自の分析基盤に送信
  if (window.gtag) {
    window.gtag('event', metric.name, {
      value: Math.round(metric.value),
      metric_id: metric.id,
      metric_delta: metric.delta,
    });
  }

  // Sentry のパフォーマンス監視にも送信
  if (window.Sentry) {
    window.Sentry.captureEvent({
      type: 'transaction',
      transaction: metric.name,
      start_timestamp: metric.startTime,
      timestamp: metric.startTime + metric.value,
    });
  }
}

// Web Vitals の計測開始
export function initPerformanceMonitoring() {
  onCLS(sendToAnalytics); // Cumulative Layout Shift
  onFID(sendToAnalytics); // First Input Delay
  onLCP(sendToAnalytics); // Largest Contentful Paint
  onFCP(sendToAnalytics); // First Contentful Paint
  onTTFB(sendToAnalytics); // Time to First Byte
}

typescript// app/entry.client.tsx - 監視の開始
import { initPerformanceMonitoring } from '~/utils/monitoring.client';

// アプリケーション起動時に監視を開始
initPerformanceMonitoring();

構造化ログの実装

ログを構造化し、検索・分析しやすくします。

typescript// app/utils/logger.server.ts - 構造化ロガー
import pino from 'pino';

// Pino ロガーの設定
export const logger = pino({
  level: process.env.LOG_LEVEL || 'info',

  // 本番環境では JSON 形式で出力
  ...(process.env.NODE_ENV === 'production'
    ? {
        formatters: {
          level: (label) => {
            return { level: label };
          },
        },
      }
    : {
        transport: {
          target: 'pino-pretty',
          options: {
            colorize: true,
          },
        },
      }),
});

// コンテキスト付きロガーの作成
export function createLogger(context: string) {
  return logger.child({ context });
}

typescript// ロガーの使用例
import { createLogger } from '~/utils/logger.server';

const log = createLogger('user-service');

export async function loader({
  request,
}: LoaderFunctionArgs) {
  const userId = await getUserId(request);

  log.info(
    { userId, path: request.url },
    'ユーザーがページにアクセスしました'
  );

  try {
    const data = await fetchUserData(userId);
    log.debug(
      { userId, dataSize: data.length },
      'ユーザーデータを取得しました'
    );
    return json(data);
  } catch (error) {
    log.error(
      { userId, error },
      'ユーザーデータの取得に失敗しました'
    );
    throw error;
  }
}

この構造化ログにより、ログ管理ツール（CloudWatch Logs、Datadog など）での検索が容易になります。

③ バックアップチェックリスト

データベースバックアップの自動化

データベースの定期バックアップを自動化し、データ損失を防ぎます。

typescript// scripts/backup-db.ts - データベースバックアップスクリプト
import { exec } from 'child_process';
import { promisify } from 'util';
import { format } from 'date-fns';

const execAsync = promisify(exec);

// バックアップ設定
const BACKUP_CONFIG = {
  dbUrl: process.env.DATABASE_URL!,
  s3Bucket: process.env.BACKUP_S3_BUCKET!,
  retentionDays: 30,
};

async function backupDatabase() {
  const timestamp = format(
    new Date(),
    'yyyy-MM-dd-HH-mm-ss'
  );
  const backupFileName = `backup-${timestamp}.sql`;

  console.log(
    `📦 データベースバックアップを開始: ${backupFileName}`
  );

  try {
    // PostgreSQL のバックアップコマンド（pg_dump）
    const dumpCommand = `pg_dump ${BACKUP_CONFIG.dbUrl} > /tmp/${backupFileName}`;
    await execAsync(dumpCommand);

    console.log('✅ データベースダンプが完了しました');

    // S3 へアップロード
    const uploadCommand = `aws s3 cp /tmp/${backupFileName} s3://${BACKUP_CONFIG.s3Bucket}/backups/${backupFileName}`;
    await execAsync(uploadCommand);

    console.log('✅ S3 へのアップロードが完了しました');

    // ローカルファイルの削除
    await execAsync(`rm /tmp/${backupFileName}`);

    // 古いバックアップの削除
    await deleteOldBackups();

    return { success: true, fileName: backupFileName };
  } catch (error) {
    console.error('❌ バックアップに失敗しました:', error);
    throw error;
  }
}

typescript// 古いバックアップの削除処理
async function deleteOldBackups() {
  const cutoffDate = new Date();
  cutoffDate.setDate(
    cutoffDate.getDate() - BACKUP_CONFIG.retentionDays
  );

  const listCommand = `aws s3 ls s3://${BACKUP_CONFIG.s3Bucket}/backups/ --recursive`;
  const { stdout } = await execAsync(listCommand);

  const files = stdout.split('\n').filter(Boolean);

  for (const file of files) {
    const parts = file.split(/\s+/);
    const dateStr = parts[0];
    const fileName = parts[3];

    const fileDate = new Date(dateStr);

    // 保持期間を過ぎたファイルを削除
    if (fileDate < cutoffDate) {
      const deleteCommand = `aws s3 rm s3://${BACKUP_CONFIG.s3Bucket}/${fileName}`;
      await execAsync(deleteCommand);
      console.log(
        `🗑️  古いバックアップを削除: ${fileName}`
      );
    }
  }
}

// バックアップの実行
backupDatabase()
  .then((result) => {
    console.log(
      '✨ バックアップが正常に完了しました',
      result
    );
    process.exit(0);
  })
  .catch((error) => {
    console.error('💥 バックアップが失敗しました', error);
    process.exit(1);
  });

バックアップの定期実行設定

cron ジョブでバックアップを定期実行します。

bash# crontab 設定例 - 毎日午前 3 時にバックアップを実行
0 3 * * * cd /app && node scripts/backup-db.js >> /var/log/backup.log 2>&1

GitHub Actions を使った定期バックアップも可能です。

yaml# .github/workflows/backup.yml - GitHub Actions でのバックアップ
name: Database Backup

on:
  # 毎日午前 3 時（UTC）に実行
  schedule:
    - cron: '0 3 * * *'

  # 手動実行も可能
  workflow_dispatch:

jobs:
  backup:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: yarn install --frozen-lockfile

      - name: Run backup
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
          BACKUP_S3_BUCKET: ${{ secrets.BACKUP_S3_BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run: node scripts/backup-db.js

      - name: Notify on failure
        if: failure()
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
          text: 'データベースバックアップが失敗しました'
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}

復旧手順の文書化

バックアップからの復旧手順を明確に文書化しておきます。

markdown<!-- docs/recovery-procedure.md - 復旧手順書 -->

# データベース復旧手順

# 前提条件

- AWS CLI がインストールされていること
- 適切な権限で S3 バケットにアクセスできること
- PostgreSQL クライアントツールがインストールされていること

# 復旧手順

## 1. バックアップファイルの確認

```bash
# 利用可能なバックアップファイルを一覧表示
aws s3 ls s3://your-backup-bucket/backups/

# 最新のバックアップファイル名を確認
BACKUP_FILE=$(aws s3 ls s3://your-backup-bucket/backups/ | sort | tail -n 1 | awk '{print $4}')
echo "復旧対象: $BACKUP_FILE"
```

## 2. バックアップファイルのダウンロード

```bash
# S3 からバックアップファイルをダウンロード
aws s3 cp s3://your-backup-bucket/backups/$BACKUP_FILE /tmp/restore.sql
```

## 3. データベースの復元

```bash
# 既存のデータベースを削除（注意！）
dropdb your_database_name

# 新しいデータベースを作成
createdb your_database_name

# バックアップから復元
psql your_database_name < /tmp/restore.sql
```

## 4. 復旧の検証

```bash
# データベース接続確認
psql your_database_name -c "SELECT COUNT(*) FROM users;"

# アプリケーションの動作確認
yarn test:integration
```

④ 脆弱性対応チェックリスト

依存パッケージの自動スキャン

依存パッケージの脆弱性を定期的にスキャンします。

json{
  "scripts": {
    "security:check": "yarn audit",
    "security:fix": "yarn audit --fix",
    "security:snyk": "snyk test",
    "security:monitor": "snyk monitor"
  },
  "devDependencies": {
    "snyk": "^1.1200.0"
  }
}

GitHub の Dependabot を活用した自動更新も設定しましょう。

yaml# .github/dependabot.yml - Dependabot の設定
version: 2
updates:
  # npm パッケージの更新
  - package-ecosystem: 'npm'
    directory: '/'
    schedule:
      interval: 'weekly'
      day: 'monday'
      time: '09:00'
      timezone: 'Asia/Tokyo'

    # 自動マージの設定（パッチバージョンのみ）
    open-pull-requests-limit: 10

    # ラベルの設定
    labels:
      - 'dependencies'
      - 'security'

    # バージョニング戦略
    versioning-strategy: increase

セキュリティヘッダーの設定

セキュリティヘッダーを適切に設定し、XSS や CSRF などの攻撃を防ぎます。

typescript// app/entry.server.tsx - セキュリティヘッダーの設定
import type { EntryContext } from '@remix-run/node';

export default function handleRequest(
  request: Request,
  responseStatusCode: number,
  responseHeaders: Headers,
  remixContext: EntryContext
) {
  // セキュリティヘッダーの追加
  responseHeaders.set('X-Content-Type-Options', 'nosniff');

  responseHeaders.set('X-Frame-Options', 'SAMEORIGIN');

  responseHeaders.set('X-XSS-Protection', '1; mode=block');

  responseHeaders.set(
    'Referrer-Policy',
    'strict-origin-when-cross-origin'
  );

  // Content Security Policy の設定
  responseHeaders.set(
    'Content-Security-Policy',
    [
      "default-src 'self'",
      "script-src 'self' 'unsafe-inline' 'unsafe-eval' https://trusted-cdn.com",
      "style-src 'self' 'unsafe-inline' https://fonts.googleapis.com",
      "font-src 'self' https://fonts.gstatic.com",
      "img-src 'self' data: https:",
      "connect-src 'self' https://api.example.com",
    ].join('; ')
  );

  // HSTS ヘッダー（本番環境のみ）
  if (process.env.NODE_ENV === 'production') {
    responseHeaders.set(
      'Strict-Transport-Security',
      'max-age=31536000; includeSubDomains; preload'
    );
  }

  return new Response(/* ... */);
}

環境変数とシークレットの保護

機密情報を安全に管理するため、環境変数の暗号化と適切なアクセス制御を行います。

typescript// app/utils/secrets.server.ts - シークレット管理
import { SecretsManager } from '@aws-sdk/client-secrets-manager';

const client = new SecretsManager({
  region: process.env.AWS_REGION || 'ap-northeast-1',
});

// AWS Secrets Manager からシークレットを取得
export async function getSecret(
  secretName: string
): Promise<string> {
  try {
    const response = await client.getSecretValue({
      SecretId: secretName,
    });

    if (response.SecretString) {
      return response.SecretString;
    }

    throw new Error('シークレットが見つかりません');
  } catch (error) {
    console.error(
      `シークレット取得エラー: ${secretName}`,
      error
    );
    throw error;
  }
}

// 複数のシークレットをキャッシュ付きで取得
const secretCache = new Map<
  string,
  { value: string; expires: number }
>();

export async function getCachedSecret(
  secretName: string,
  ttl: number = 300000 // デフォルト5分
): Promise<string> {
  const cached = secretCache.get(secretName);

  if (cached && cached.expires > Date.now()) {
    return cached.value;
  }

  const value = await getSecret(secretName);
  secretCache.set(secretName, {
    value,
    expires: Date.now() + ttl,
  });

  return value;
}

typescript// シークレットの使用例
import { getCachedSecret } from '~/utils/secrets.server';

export async function loader() {
  // API キーを Secrets Manager から取得
  const apiKey = await getCachedSecret(
    'THIRD_PARTY_API_KEY'
  );

  const response = await fetch(
    'https://api.example.com/data',
    {
      headers: {
        Authorization: `Bearer ${apiKey}`,
      },
    }
  );

  return json(await response.json());
}

セキュリティ監査の自動化

定期的なセキュリティ監査を自動化します。

yaml# .github/workflows/security-audit.yml - セキュリティ監査の自動実行
name: Security Audit

on:
  # 毎週月曜日に実行
  schedule:
    - cron: '0 9 * * 1'

  # プルリクエスト時にも実行
  pull_request:
    branches: [main]

  # 手動実行も可能
  workflow_dispatch:

jobs:
  audit:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-node@v3
        with:
          node-version: '18'

      # Yarn audit の実行
      - name: Run Yarn Audit
        run: |
          yarn audit --level moderate --groups dependencies

      # Snyk によるスキャン
      - name: Run Snyk Security Scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

      # OWASP Dependency Check
      - name: OWASP Dependency Check
        uses: dependency-check/Dependency-Check_Action@main
        with:
          project: 'remix-app'
          path: '.'
          format: 'HTML'

      # 結果のアップロード
      - name: Upload Security Report
        if: always()
        uses: actions/upload-artifact@v3
        with:
          name: security-report
          path: |
            dependency-check-report.html
            snyk-report.json

以下の図は、脆弱性対応のワークフローを示しています。

mermaidflowchart TB
    scan["定期スキャン<br/>（週1回）"] --> detect["脆弱性検出"]
    pr["PR作成"] --> detect

    detect --> severity{"重要度評価"}

    severity -->|Critical/High| urgent["緊急対応<br/>（24時間以内）"]
    severity -->|Medium| normal["通常対応<br/>（1週間以内）"]
    severity -->|Low| planned["計画対応<br/>（次回リリース）"]

    urgent --> fix["パッチ適用"]
    normal --> fix
    planned --> fix

    fix --> test["テスト実行"]
    test --> deploy["デプロイ"]
    deploy --> verify["脆弱性<br/>解消確認"]

重要度に応じて対応期限を設定し、確実に脆弱性を解消していきます。

運用チェックリスト一覧表

最後に、日々の運用で確認すべき項目を一覧表にまとめます。

#	カテゴリ	チェック項目	頻度	担当
1	ビルド	ビルド時間が 5 分以内か	毎デプロイ	Dev
2	ビルド	バンドルサイズが肥大化していないか	週次	Dev
3	ビルド	環境変数が正しく設定されているか	毎デプロイ	DevOps
4	監視	エラー率が 1% 以下か	日次	DevOps
5	監視	レスポンスタイムが 500ms 以下か	日次	DevOps
6	監視	ログが正しく記録されているか	日次	DevOps
7	監視	アラートが適切に通知されているか	週次	DevOps
8	バックアップ	データベースバックアップが成功しているか	日次	DevOps
9	バックアップ	バックアップからの復旧テストを実施したか	月次	DevOps
10	バックアップ	古いバックアップが削除されているか	週次	DevOps
11	脆弱性	依存パッケージに脆弱性がないか	週次	Dev
12	脆弱性	セキュリティパッチが適用されているか	月次	DevOps
13	脆弱性	セキュリティヘッダーが設定されているか	四半期	Dev
14	脆弱性	シークレットが適切に管理されているか	月次	DevOps