Vercel plugin×Codex CLIでAIデプロイ自動化

「Vercel pluginとCodex CLIを触ってみたいけど、GitHub Actionsまでつなぐと急に難しくなる」と感じている人に向けて書きました。この記事を読むと、deployment:falseの意味からJST cronの実装、事故を減らす運用ルールまで一気に整理できます。僕は福祉事業のIT全般を担当しつつ、複業でAI×SaaS開発をしているので、非ITのチームでも回る形に落とし込んで解説していきます。

Vercel plugin×Codex CLI×GitHub Actionsの全体像

2026年3月17日に、Vercelはコーディングエージェント向けVercel pluginを公開しました。さらに2026年3月26日には、OpenAI CodexとCodex CLI対応が追加されています。つまり今は、Codex CLIを使った開発フローとVercel運用を同じレーンに載せやすい時期です。

設計のイメージとしては、「AIが考える層」と「デプロイを実行する層」を分けると安定します。自動化の成功率は、役割分担を先に決めるだけで大きく上がります。ここを曖昧にすると、AIが便利なのに運用はむしろ不安定になります。

• 知識レイヤー — Vercel pluginで環境知識を読み込む
• 実行レイヤー — openai/codex-actionでCodex CLIを安全に実行する
• 配信レイヤー — vercel build と vercel deploy --prebuilt で本番反映する

Vercel公式の説明では、plugin経由で39以上のプラットフォームスキルと3つの専門エージェントが使えます。GitHub Actions側はCodex Actionがworkspace-write/read-onlyなどの実行モードを持っているので、レビュー中心か修正まで許可するかをジョブ単位で制御できます。つまり「AIを入れる」ではなく、「AIの権限を設計する」ということです。

GitHub Actions deployment:false設計の核心

まず用語を揃えます。現場では「deployment:falseにする」と言いがちですが、Vercel設定の正確なキーはgit.deploymentEnabled: falseです。ここをfalseにすると、Git pushだけで勝手にデプロイされる流れを止められます。デプロイ責任をGitHub Actionsに集約したいときは、ここが起点です。

「とりあえず自動化」より「どこで止められるか」まで決めるほうが実運用で助かります。特に非ITメンバーが関わるチームだと、意図しない公開が一番説明コストを増やします。だから最初にdeploymentEnabledを整理して、公開の最終トリガーをGitHub Actions側に寄せるのがおすすめです。

実践手順：JST cronでAIデプロイを自動化する

ここからは、今日そのまま試せる最小構成です。Vercel公式もGitHub Actionsでvercel pull→vercel build→vercel deploy --prebuiltの流れを案内しています。加えて、GitHub公式ではscheduleの最短間隔が5分、デフォルトがUTC、必要に応じてtimezone指定が可能とされています。

1. Git自動デプロイを停止 — git.deploymentEnabled: false を設定
2. Codex Actionで差分チェック — まずはread-onlyで開始
3. Vercel CLIでビルド/配信 — --prebuiltでビルド責務をCIへ集約
4. JST cronを設定 — timezone: Asia/Tokyo またはUTC換算で指定
5. 同時実行を止める — concurrency.cancel-in-progress: true を設定

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "git": {
    "deploymentEnabled": false
  }
}

name: ai-deploy
on:
  workflow_dispatch:
  schedule:
    - cron: '3 12 * * 1-5'
      timezone: 'Asia/Tokyo'

concurrency:
  group: ai-deploy-${{ github.ref }}
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v5

      - name: Run Codex check
        uses: openai/codex-action@v1
        with:
        openai-api-key: ${{ secrets.OPENAI_API_KEY }}
        prompt: "変更差分を確認し、デプロイ前チェック項目を短く出力してください。"
        sandbox: read-only
        safety-strategy: drop-sudo

      - name: Install Vercel CLI
        run: npm install --global vercel@latest

      - name: Pull env
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}

      - name: Build
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}

      - name: Deploy (staged)
        run: vercel deploy --prebuilt --prod --skip-domain --token=${{ secrets.VERCEL_TOKEN }} > deployment-url.txt

      - name: Print URL
        run: cat deployment-url.txt

補足として、GitHub公式には「毎時ちょうどは混雑しやすく遅延やドロップが起きることがある」とあります。なので0分を避けて3分や7分にずらすのが現実的です。この細かい調整だけで、定時実行の体感安定度はかなり変わります。実装途中で詰まったら、まず直近3回のrun時刻・失敗率・Vercel deployment URLを表にして、cron起因かビルド起因かを分けて確認してください。

運用で詰まりやすいポイントと回避ルール

自動化は作って終わりではありません。運用でハマる場所はほぼ決まっているので、最初からルール化しておくと楽です。特にGitHubのscheduleは「default branchのみ実行」「公開リポジトリは60日活動なしで無効化」の条件があるので、知らないまま放置すると急に止まります。

• default branch限定 — 本番workflowはmainに配置してworkflow_dispatchも併用します
• 60日無活動停止 — 月1回の手動実行か定期コミットで死活監視します
• 毎時0分の混雑 — cronを3,7,13分などにずらします
• 権限過多のまま運用 — Codex Actionはread-onlyから始めて段階的に拡張します

技術より先に運用ルールを決めると、後からの修正コストが下がります。CI/CD整備では、誰が承認し、どのログを見て、どの条件なら本番aliasを付けるかまで先に決めておくのが安全です。

手動デプロイを続けた先に起きやすい現実

deployment:false設計やcron運用を知らないままだと、担当者依存のリリースが残り続ける可能性があります。すると、担当が不在の日に公開が止まったり、確認漏れで本番に反映してしまったりします。これは「誰かの努力不足」ではなく、仕組み不足で起きます。だからこそ、早めに自動化へ寄せるだけで、チームの心理的コストまで下げられますよね。

この記事を書いている理由

僕自身、SESから人材育成、そして福祉領域のIT担当へ移ってきて、「技術をわかる人だけが得する構造」を何度も見てきました。業務効率化ツールで月80時間分の工数を削減した経験や、550名以上のキャリア面談をした経験から、結局いちばん効率が出るのは“わかる仕組みを先に作ること”だと感じています。だから今回も、難しい話を実装まで落として共有したかったんです。

次のアクション

まずはgit.deploymentEnabled: falseを設定し、workflow_dispatchで1回だけ手動実行してみてください。動いたらcronを足す順番で進めると安全です。最後に、deployment URL、承認者、alias付与条件をリリースメモに残してください。