CI/CDとは？継続的インテグレーションとデリバリーをわかりやすく解説

CI/CDは、コードを変更するたびに、自動でビルドし、テストし、合格したものを公開できる状態にする（または実際に公開する）ソフトウェアの提供方法です。**CI（継続的インテグレーション）**とは、変更を頻繁に取り込み、そのたびに自動テストで確認することを意味します。**CD（継続的デリバリーまたはデプロイメント）**とは、合格した変更を、手作業をほとんど使わずにパッケージ化し、利用者に向けて届けることを意味します。

ポイントはシンプルです。ミスは、数週間後に顧客が見つけるのではなく、作られてから数分以内に見つけることです。

AIでアプリを作るときにCI/CDが重要な理由

AIビルダーは、コードの変更をとても速く行います。1つのプロンプトで10個のファイルが変わることもあります。その速さは、決済ページへの変更が、気づかないうちにログインページを壊してしまうまでは、とても便利です。利用者からメールが届くまで、誰も気づかないのです。

CI/CDは、まさにこの問題に対する安全網です。それぞれの変更が問題ないと信じるのではなく、パイプラインが毎回同じチェックを実行します。

• アプリはまだエラーなくビルドできるか？
• 自動テストはまだ合格するか？
• コードはプロジェクトのルール（型、整形、セキュリティチェック）に従っているか？

いずれかのチェックが失敗すると、変更は利用者に届く前に止められます。コードの変更が速いほど、疲れることなく、手順を省略することもないチェックの価値は高まります。

身近なたとえ

毎朝、店にパンを卸しているパン屋を考えてみてください。

• CI/CDがない場合、各パン職人は1週間、自分のレシピを少しずつ変えて作業します。そして金曜の夜にみんなの変更を合わせて、パンがちゃんと膨らむことを祈ります。膨らまなければ、誰の変更が原因かは誰にも分かりません。
• CIがある場合、小さなレシピの変更はすぐにテスト用のパンとして焼かれ、味、重さ、形がチェックされます。問題のある変更はその日のうちに見つかり、どの変更が原因かがはっきり分かります。
• CDがある場合、検査に合格したパンは、毎回同じように包装されてラベルが貼られ、すぐに配達のバンに積まれます。朝5時に誰かが手作業で箱詰めする必要はありません。

検査によってパン職人が上達するわけではありません。検査によって、ミスのコストが小さくなるのです。

CI/CDパイプラインの仕組み

パイプラインとは、何かが起きたときにCI/CDのサービスが自動で実行する一連の手順です。通常は、誰かがGitHubのようなリポジトリにコードをプッシュしたときに実行されます。典型的なパイプラインは次のようになります。

それぞれの手順は、誰かのノートパソコンではなく、まっさらなマシン上で実行されます。そのため「自分のパソコンでは動いた」は言い訳になりません。手順が失敗すると、パイプラインは止まり、変更をした人に知らせます。

手順は、コードと一緒に置かれた設定ファイルで定義されます。たとえば、GitHub Actionsでは、リポジトリの .github/workflows フォルダーにあるYAMLファイルです。

継続的デリバリーと継続的デプロイメントの違い

「CD」は曖昧な言葉で、どちらの意味でも使われます。

継続的デプロイメントがうまく機能するのは、テストが十分にある場合だけです。決済のテストがなければ、継続的デプロイメントは壊れた決済ページを、喜んで公開してしまいます。

具体例：パイプラインのある予約アプリ

サロンの予約アプリがあり、そのコードがGitHubのリポジトリにあるとします。AIビルダーに「初回の顧客に10%の割引を追加して」と頼みます。

1. 変更は新しいブランチにプッシュされ、プルリクエストが作られます。
2. パイプラインが始まります。パッケージをインストールし、アプリをビルドします。これは合格します。
3. テストが実行されます。「リピーターの顧客は定価を払う」というテストが失敗します。割引が全員に適用されてしまっているのです。
4. プルリクエストに赤い×印が表示されます。この変更はマージできません。
5. AIに修正を頼みます。AIが修正をプッシュし、パイプラインが再び実行され、すべてが合格します。
6. 変更がマージされます。パイプラインがそれを**ステージング環境**にデプロイし、そこでテスト予約を試します。
7. 承認すると、本番にデプロイされます。

パイプラインがなければ、手順3で起きた問題は、顧客が支払うときに起きていたでしょう。

主な用語

よくある誤解

• 「CI/CDがあれば、アプリはテストされている」。 パイプラインが実行するのは、あなたが用意したテストだけです。テストがなければ、CIが証明するのはアプリがビルドできることだけです。重要な流れのテストを書くよう、AIに頼んでください。
• 「CI/CDは大企業だけのもの」。 GitHub Actionsのようなホスト型のツールは、短い設定ファイルで設定でき、小さなチームでも日常的に使われています。手間がかかるのは、ツールではなくテストの方です。
• 「自動デプロイは、誰も何も確認しないということ」。 良いパイプラインは、チェックを減らすのではなく、増やします。多くのチームは、本番の前に人による承認の手順を残しています。
• 「パイプラインが緑なら、アプリは動く」。 それは自動チェックに合格したという意味にすぎません。それでも、変更は自分で試すべきです。できればプレビューかステージングで。
• 「CI/CDがあれば、バックアップは不要」。 そうではありません。テストに合格しても、データベースの問題のある移行が実データを壊すことがあります。バックアップと、ロールバックの方法を用意しておいてください。

AIビルダーに頼むときの依頼例

• 「会員登録、ログイン、決済のための自動テストを書いて、実行方法を見せて。」
• 「依存関係をインストールし、アプリをビルドして、すべてのプルリクエストでテストを実行するGitHub Actionsのワークフローを設定して。」
• 「型チェックとリンターをパイプラインに追加して、エラーがあれば失敗させて。」
• 「パイプラインの各手順が何をするのか、やさしい日本語で説明して。」
• 「デプロイが途中で失敗したらどうなる？どうやってロールバックすればいい？」
• 「リポジトリに秘密情報が直接書かれていないか、パイプラインのログに出力されていないかを確認して。」

アプリがAPIキーを使っているなら、パイプラインにもそれが必要です。CIツールの中で暗号化された秘密情報として保存し、設定ファイルには決して書かないでください。環境変数と秘密情報をご覧ください。

CI/CDとMythex

MythexはあなたのためにCIパイプラインを実行するわけではありませんが、同じニーズのいくつかを独自の方法でカバーしています。

• チェックポイント。 エージェントが成功するたびに、Mythexはgitのチェックポイントを保存します。変更がうまくいかなかったときは、この時点に戻すを使うと、プロジェクトを巻き戻せます。チャットをご覧ください。
• アプリのテスト。 /test と入力すると、エージェントがライブプレビューを利用者のように操作し、壊れた流れを報告します。公開のたびに役立ちます。アプリのテストをご覧ください。
• 公開は意図的な手順です。 変更はまず非公開のプレビューに表示されます。公開中のアプリは、もう一度公開したときにだけ更新されます。継続的デプロイメントというより、継続的デリバリーに近い形です。
• GitHubとの同期（Proプラン）。 プロジェクトをGitHubリポジトリに同期すると、独自のGitHub Actionsのワークフローを追加して、プッシュのたびにテストを実行できます。GitHubとエクスポートをご覧ください。

公開前に手作業で確認すべきことのチェックリストは、公開前にアプリをテストする方法をご覧ください。バージョン管理の扱い方については、AIで作ったアプリでGitを使う方法をご覧ください。

よくある質問