Grok Build 101: ビルドパイプラインとガードレールの構築

手動デプロイの問題点

前回の記事では、Grok BuildをVisual Studioから操作し、簡単なアプリを構築し、それをvercelコマンドを使ってVercelにデプロイしました。

実際の開発ではこれで終わりということはなく、ユーザーからのフィードバックや発覚したバグに対処していく必要があります。前回同様、Grok Buildで改善版を構築し、テストした後にvercelコマンドでデプロイすることも可能ですが、以下のような課題が発生します。

• テストする項目が増大し、テストに時間がかかるようになる。
• テストする項目が増大し、テスト漏れの可能性も高まる。
• 結果、不具合を含んだバージョンをデプロイする可能性が高まる。

これらのリスクを抑えるための仕組みとして、デプロイパイプラインを構築します。

ビルドパイプラインとは

前回の記事ではGrok Buildがコード生成した後に、vercelコマンドを叩いてVercelにデプロイしていました。この一連の作業を自動化するのがビルドパイプラインです。

ここではGithubを使います。

Githubにmasterとfeature/devという２つのブランチを用意し、feature/devへのコミットやマージでvercelのpreview(内部レビュー用)にデプロイ、masterへのマスターやマージでVercelのproduction(公開バージョン)にデプロイするようにします。

クリックで拡大

CIによる品質担保

もちろん、デプロイを単に自動化しても肝心のコードが動かないと意味はありません。コードがgithubにコミットされてから、予め定義されたテストを実行し、それに合格しない場合はデプロイを中止する仕組みを導入します。これがCI(Continuous Integration: 継続的統合)です。

クリックで拡大

ガードレールによる安全確保

Grok Buildはエージェントです。つまり、利用者が叩けるコマンドはすべて実行可能です。もちろん、プロンプトから「masterブランチを操作するな」と指示することは可能ですが、なんらかの拍子でmasterブランチに勝手にコミットする可能性はゼロとは言い切れません。もしかしたら、masterブランチごと消し去る可能性も排除できません。

このような「事故」の可能性を排除するために、以下のような策をとります。

• gitコマンドによるmasterブランチの操作禁止
  • GithubのWeb画面からPRを作成し、Merge PRで対応

複数人数で開発するのなら、ここにレビュー必須などのルールを追加しても良いでしょう。

クリックで拡大

Github/Vercel設定

では前回構築したプロジェクトをもとに作業をしてみましょう。

前提

• Githubアカウントが必要です。まだの人は取得してください。
• Vercelアカウントが必要です。前回記事を参照のこと。

手順

以下は手作業で実行します。

1 githubリポジトリを作成。

1. 中身は空で。
   1. Add a README = off
   2. .gitignore = off
   3. license = off
2. VisibilityはPrivate
3. 名称は自由。筆者は powerball_fortune という名前にしています。

2 .gitignore ファイルを作成

# Dependencies
node_modules/

# Environment & secrets
.env
.env.*
!.env.example

# Vercel CLI link (local project binding)
.vercel/

# Playwright
/test-results/
/playwright-report/
/blob-report/
/playwright/.cache/

# Logs & debug
logs/
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# Coverage / tooling
coverage/
.nyc_output/

# OS
.DS_Store
Thumbs.db
Desktop.ini

# Editors / IDE
.idea/
.vscode/*
!.vscode/extensions.json
!.vscode/settings.json
*.swp
*.swo
*~

# Optional local notes
*.local

3 Grok Build環境から以下を実行

git init
git branch -M master

git add .
git commit -m "Initial commit"

git checkout -b feature/dev
git checkout master

git remote add origin https://github.com/<user>/<repo>.git
git push -u origin master
git push -u origin feature/dev

4 Githubのデフォルトブランチを確認

1. GitHub → 対象リポジトリ → Settings → General → Default branch
2. master になっていることを確認（違う場合は master に変更）

5 既存 Vercel プロジェクトと GitHub を接続

CLI で既にデプロイしているプロジェクトを、同じ GitHub リポジトリに紐付けます。

5-1 リポジトリを接続

1. Vercel Dashboard → 既存プロジェクトを開く
2. Settings → Git
3. Connect Git Repository（または Connect）
4. GitHub を選び、権限を求められたら 対象リポジトリ（または Organization）へのアクセス を許可
5. 作成したリポジトリを選択して接続

   1. 一覧に出ない場合: GitHub の Settings → Applications → Installed GitHub Apps → Vercel で、リポジトリアクセスに当該 repo が含まれているか確認。

5-2 Production Branch

1. 同じ Settings → Git（または Environments / プロジェクトの Git 設定）
2. Production Branch を master に設定
   1. デフォルトが main のことがあるので必ず確認
      

5-3 ビルド設定（静的サイト）

• Settings → General（または Build & Development Settings）:

6 デプロイ動作の確認

6-1 Preview（feature/dev）

git checkout feature/dev
# 何か小さな変更（例: README に1行）を入れてコミット
git add .
git commit -m "chore: verify preview deploy"
git push origin feature/dev

1. Vercel ダッシュボード → Deployments
2. feature/dev のデプロイが Preview として成功していること
3. Preview URL をブラウザで開き、アプリが表示されること

6-2 Production（master）

1. GitHub で feature/dev → master の Pull Request を作成
2. Vercel が PR に Preview コメント / チェックを付けることを確認
3. あなた自身が PR を Merge
4. Vercel で Production デプロイが走り、本番 URL が更新されること

実践編

Preview

ではこのビルドパイプラインを使って、実際に前回開発したアプリを改造してみましょう。以下のプロンプトをPlanモードで実行してください。

# 20260730

## 以下の改造を加えたい。

1. Powerballだけでなく、Megamillionも占えるようにする
    - タブ切り替えで充分
1. 言語は日本語と英語を切り替えられるように
    - 画面右上に日本国旗とアメリカ国旗を配置し、スイッチに使う

## CIの追加

1. Unit Testを実行
    - Mockしやすいよう、依存性注入を活用したデザイン
    - 各テストに何をテストするのかを英語でコメント

1. e2e Testを実行
    - Playwrightを利用
    - Selector指定が容易になるよう、実装側で留意
    - 各テストに何をテストするのかを英語でコメント

1. github workflowに上記テストをCIとして追加

1. ローカルでのe2e Test合格の場合、feature/devにコミット

    
これで計画を立てて

問題なければVercelのPreviewに新しいバージョンのアプリがデプロイされるはずです。

Production

Preview版が一通り動くか確認し、問題なければ本番(Production)にデプロイします。

1. Githubで当該リポジトリを開く
2. ヘッダメニューの Pull requests をクリック
3. 緑色の New pull request ボタンをクリック
4. base: master <- compare: feature/dev に設定
5. 緑色の Create pull request をクリック
6. Titleを「First Production」にして、緑色の Create pull request をクリック
7. CIテストが走るので完了するのを待つ
8. 緑色の Merge pull request をクリック
9. 緑色の Confirm merge をクリック

これでVercelの本番環境にて新しいバージョンが公開されているはずです。

継続的改善

実際に動かしてみると不具合が発生するはずです。筆者の場合は「iPhoneで動作させたら、数字がずれて表示される」という問題が発生しました。

クリックで拡大

このような場合は、Grokチャット窓の+アイコンをクリックしてスクリーンショットをアップロードし「携帯から実行すると、数字がずれていて読めない場合がある。この原因を特定し、改善する計画を立てて。E2E結果に問題なければ、　feature/dev にコミットして。」というプロンプトをPlanモードで実行します。

筆者の環境では５分ほどで改善版がfeature/devブランチにコミットされ、不具合がなおったことが確認できました。

クリックで拡大

Playwrightを使ったe2eテストでは、画面の崩れのようなバグは見落とします。それを防ぐのは、現状では人間による目視確認が今のところは一番速いです。もちろん、画面数が増えてきたらこの部分もLLMで実行することになるはずです。

次にやること

例えば以下のような改善を皆さんで試してみてください。

• 対応言語を増やす
• 対応のLotteryを増やす
  • Superlotto Plus
  • Fantasy 5
  • Daily 4
  • Daily 3
  • Daily Derby
  • Hot Spot