AIが生成したアプリにとってCI/CDが重要な理由

AIツールがアプリケーションコードを生成したとしても、本番環境を壊さずにアップデートを確実にリリースする仕組みは必要です。CI/CDパイプライン（継続的インテグレーション/継続的デプロイ）は、Gitリポジトリへのプッシュごとに自動チェックを実行し、コードをデプロイします。AIが生成したアプリの場合、プロンプトでの改善に合わせてコードが急速に変化するため、この仕組みはとりわけ重要になります。

考え方はシンプルです。リポジトリへのプッシュをトリガーとして、ワークフローがアプリをビルドし、テストを実行し、すべてが通ればホスティングプラットフォーム（Vercel、Netlify、AWSなど）にデプロイします。手動デプロイも、壊れたコードをユーザーに届けることも、もう必要ありません。

GitHub Actionsとは

GitHub ActionsはGitHubに組み込まれた自動化ツールです。リポジトリの`.github/workflows`フォルダに保存されるYAMLファイルでワークフローを定義します。各ワークフローはイベント（プッシュなど）によってトリガーされ、仮想マシン上で一連のステップを実行します。

ワークフローファイルには主に3つの構成要素があります。トリガー（実行タイミング）、ランナー（使用マシン）、ジョブ（実行内容）です。Node.jsアプリの最小限の例は次のとおりです。

name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npm run build
      - run: npm test

このファイルは`.github/workflows/deploy.yml`に置かれます。mainブランチにプッシュすると、GitHubがUbuntuマシンを起動し、コードをチェックアウトし、依存関係をインストールし、プロジェクトをビルドして、テストを実行します。

自動デプロイの追加

上記のビルドジョブはコードが動作するかの確認だけです。実際にリリースするには、デプロイステップを追加します。主要なホスティングプロバイダーは組み込みのActionsを用意しているので、簡単に組み込めます。Vercelの場合は次のとおりです。

name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npm run build
      - uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

Secretsの参照に注目してください。APIトークンなどの機密値は、ワークフローファイルに直接書かず、GitHubリポジトリ設定のSecrets and Environment variablesに保存します。`${{ secrets.NAME }}`という構文により、ログに値を表示せずに実行時にSecretsを取得できます。

AI生成コード特有の課題に対応する

AI生成コードには特有の懸念点があります。依存関係リストが肥大化していたり、未使用のパッケージが含まれていたりします。ローカルでは動作しても、環境ファイルの欠落でクリーンな環境では失敗することもあります。パイプラインを堅牢化するために、以下の手順を推奨します。

ビルドの前にリンティングステップを追加し、初期段階で一般的なエラーを検出します。Node.jsなどランタイムのバージョンは明示的に固定します。`actions/cache`を使って依存関係をキャッシュし、再インストールを高速化します。実行時にアプリが必要とする環境変数も同様にSecretsに追加します。

- uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
      - run: npm ci

CI環境では`npm install`ではなく`npm ci`を使用してください。`ci`はロックファイルを厳格に読み取り、再現性のあるインストールを行うため、AI生成のpackage.jsonがpackage-lock.jsonからずれているケースを検出できます。

よくある落とし穴とその修正

よくある間違いは、ワークフローファイルはコミットしたものの、リポジトリ設定でSecretsを追加し忘れるケースです。そうすると「secret not found」エラーでワークフローが失敗します。Settings → Secrets and variables → Actionsで必要なSecretsを1つずつ追加してください。

もう一つの落とし穴は、main以外のブランチへのプッシュでも含めて、すべてのプッシュでデプロイしてしまうことです。`on`ブロックでブランチフィルターを使いmainだけに制限するか、プルリクエスト用のプレビューデプロイジョブを別途追加してください。

最後に、フォークからのプルリクエストで動作するワークフローにも注意が必要です。セキュリティ上の理由から、これらはデフォルトではSecretsにアクセスできません。対応が必要な場合は、慎重に`pull_request_target`を使うか、Secretsを必要としない無料枠のプレビュー環境を活用してください。

まとめ

AI生成のWebアプリ向けCI/CDパイプラインを堅牢にするには、リポジトリ内のYAMLファイル1つで済み、プッシュごとに依存関係をクリーンにインストールし、ビルドとテストを行い、保存したSecretsを使ってホスティング先にデプロイします。まずは基本的なビルド＆テストのワークフローから始め、ホスティングの認証情報が整ったらデプロイステップを追加してください。ユーザーへ届ける内容を制御しているのはパイプライン自体ですので、それ自体を本番インフラの一部として扱いましょう。