- Tech
CI/CDを使い、AI時代の人間の仕事「確認する」の精度を上げよう
AI時代の人間の仕事
「人間がコードを書く時代は終わった」というNode.js創始者のRyan Dahlの発言など、コードを書く事は人間の仕事ではなくなるかもしれないと言われたりしている世の中ですが、これはAIだけで行うのは難しいだろうという事があります。
それは、「成果物に対して責任を取る（≒確認をする）」という事です。
そして、人間のレビューが間に合わないスピードで生成された成果物に対して、スムーズに確認をする際に活きてくる仕組みがCI/CDです。
CI と CD のおさらい
CI (Continuous Integration)
コードを変更するたびに、自動でテスト・ビルドを実行する仕組み
- push / PR をトリガーに自動実行
- 「壊れていないこと」を常に保証する
- 問題を早期発見し、統合コストを最小化する
CD（Continuous Delivery）
テスト・ビルドを通過したコードを、いつでも本番環境へリリースできる状態に保つ仕組み
- CI 通過後、自動的にステージング環境へデプロイ
- 本番へのリリースは人間が確認・承認してから実行
- 「いつでも出せる」状態を常に維持し、リリースリスクを最小化
| CI | CD | |
|---|---|---|
| 何をする？ | コードの統合・テスト・ビルドを自動化 | テスト済みコードのデプロイを自動化 |
| ゴール | 「壊れていないこと」を常に保証 | 「いつでもリリースできる状態」を保証 |
| タイミング | push / PR のたびに実行 | CI 通過後に自動 or ワンクリックで実行 |
CD のメリット
1. リリースサイクルの短縮
- CI 通過後すぐにステージング環境で動作確認できる
- 本番リリースの判断・実行が迅速になり、「金曜デプロイ怖い問題」が消える
2. ヒューマンエラーの排除
- 手順書ベースの手動デプロイ → 手順ミス・抜け漏れが発生しがち
- CD なら毎回まったく同じプロセスで実行される
CD があることで、人間は「確認する」というまだAIでは出来ない仕事に集中できる
CI/CDを実際に設定してみる
実際に、GitHub で管理された Sveltekit製アプリケーションをCloudflare Workers 上にデプロイし、CI/CDがどのようなものか見てみましょう。
ちなみに Cloudflare Workers にした理由は、無料で利用出来るのと CI/CD の設定が簡単だからです。
Cloudflare Workers でないとこういった CI/CD の設定が出来ないというわけではありません。
ただ、 本番環境でAWSを使い、 CI/CD では Cloudflare Workers を使う、といった事は可能なので、 プレビュー環境のデプロイ先としては非常におすすめです。
Sveltekitプロジェクト作成
Svelte公式より用意された、以下のコマンドでSveltekitプロジェクトを作成する事が出来ます。
npx sv create blog_cicd
これを実行すると、以下のように対話形式で開発に便利なツールやライブラリの設定を行うか聞いてくれます。
| 日本語訳 |
|---|
| どのテンプレートを使用しますか？
SvelteKit minimal（最小構成） |
| TypeScript による型チェックを追加しますか？
はい、TypeScript 構文を使用します |
| プロジェクトに何を追加しますか？
prettier, eslint, vitest, playwright, sveltekit-adapter, mcp |
| vitest: 何のために vitest を使用しますか？
ユニットテスト、コンポーネントテスト |
| sveltekit-adapter: どの SvelteKit アダプターを使用しますか？
Cloudflare |
| sveltekit-adapter: Workers (assets) と Pages のどちらにデプロイしますか？
Workers |
| mcp: どのクライアントを使用しますか？
VSCode |
| mcp: どのセットアップを使用しますか？
Local（ローカル） |
| プロジェクトが作成されました |
| アドオンのセットアップに成功しました：prettier, eslint, vitest, playwright, sveltekit-adapter, mcp |
| どのパッケージマネージャーで依存関係をインストールしますか？
bun |
CI の設定をする
上記の設定により、 Unit Test(demo.spec.ts), Component Test(page.svelte.spec.ts), E2E テスト(demo.test.ts) がそれぞれ１件ずつ作成されています。
これが CI 上で働くようにします。
GitHub Actions ワークフローの作成
.github/workflows/ci.yml を
を以下の内容で作成します。
ワークフローの解説
| ステップ | 説明 |
|---|---|
actions/checkout |
リポジトリのコードを取得 |
oven-sh/setup-bun |
bun ランタイムをセットアップ |
bun install |
依存関係のインストール |
playwright install |
ブラウザテストに必要な Chromium をインストール |
test:unit -- --run |
Unit Test (demo.spec.ts) + Component Test (page.svelte.spec.ts) を実行 |
test:e2e |
E2E Test (demo.test.ts) を実行 |
push（main ブランチ）と pull_request をトリガーに、3種類のテストが自動実行されます。
CD の設定をする
CI で品質を担保したら、次は Cloudflare Workers にデプロイする CD を設定します。 Cloudflare Workers Builds を使えば、GitHub リポジトリと連携して自動デプロイが可能です。
GitHub リポジトリを Cloudflare に接続する
- Cloudflare ダッシュボード にログイン
- Workers & Pages → 対象の Worker を選択
- Settings → Builds → Connect を選択
- GitHub アカウントを認証し、リポジトリを選択
CI/CDの動作を確認する
設定が終わったので、早速 develop ブランチから main に向けてPRを作成します。 すると、以下のようにPR上でプレビューURLが発行されるので、実装者もレビュワーもシームレスにプレビュー上で動作の確認が出来ます。
ちなみに、プッシュしたら再デプロイされるようにもなっています。
また、Cloudflareへのデプロイが終わったら以下のようにSlackなどに通知を送るようにすることも出来ます。
Slack通知から直接動作の確認が出来るので、便利ですね。
余談
今回はソースコードの変更をCI/CDによりプレビュー環境にデプロイする方法を書きました。
ただそれ以外にも、DBスキーマの変更なども含めて確認が必要な場合があるでしょう。
そういった場合にも同じ事は出来るのでしょうか？
実は、それも可能です。
Cloudflareではプレビュー環境用のDBがあったり、PlanetScaleやNeonといったサーバーレスDBでは、DBにもブランチの仕組みが用意されているので、DBスキーマの変更などがあってもプレビュー環境用にデプロイする事が可能なようです。
まとめ
CI/CD自体はここ最近の概念ではありませんが、AIでの開発スピードにおいつくには、適切にCI/CDを設定してスムーズに確認するための基盤づくりが不可欠です。
最後に改めてCI/CDの特徴とメリットをまとめます。
- CD = CI通過後に自動でステージングへ届け、いつでも本番にリリースできる状態を保つ仕組み
- ヒューマンエラー排除・リリース高速化・心理的安全性 UP
- AI 時代だからこそ、CD で「確認する」の精度を上げよう！
ドコドア エンジニア部
このブログでは、アプリ開発の現場で培ったフロントエンド、バックエンド、インフラ構築の知識から生成AI活用のノウハウまで、実践的な情報をアプリ開発に悩む皆様へ向けて発信しています！
【主な技術スタック】 Flutter / Firebase / Svelte / AWS / GCP / OpenAI API
