2026年8月2日

AWS CodePipelineでCI/CDを構築する方法｜GitHub連携・CodeBuild・CodeDeployでWordPressのテーマを自動デプロイ

VPS・クラウド

AWS CodePipelineでCI/CDを組むには、「ソース（GitHubなど）→ビルドとテスト（CodeBuild）→デプロイ（CodeDeploy）」の3つのステージをパイプラインとしてつなぎ、ブランチへのプッシュをきっかけに自動で流れるようにします。この記事では、EC2で動くWordPressのテーマを例に、GitHubとの接続、buildspec.yml と appspec.yml の書き方、本番の前に承認を挟む方法、失敗したときの調べ方と切り戻しまでを説明します。

CodePipelineまわりの画面やサービス名は、ここ数年で何度か変わっています。ここでの説明は執筆時点（2026年10月現在）の情報をもとにしているので、画面の項目名は公式ドキュメントでも確認してください。

全体の構成と、何を自動化するか

今回作るパイプラインの流れは次のとおりです。

Source：GitHubの main ブランチにプッシュされたら、リポジトリの内容を取得する
Build：CodeBuildで依存パッケージを入れ、コーディング規約のチェックとCSS/JSのビルドを行い、デプロイする一式をまとめる
Approval（任意）：本番に出す前に、担当者が承認する
Deploy：CodeDeployでEC2のテーマのディレクトリにファイルを配置し、表示の確認をする

自動化の対象は「Gitで管理しているコード」だけにします。wp-config.php、wp-content/uploads、データベースの中身はパイプラインに含めません。これらをデプロイで上書きすると、本番の設定や利用者がアップロードしたファイルを失うおそれがあるためです。WordPress本体やプラグインの更新も、テーマのデプロイとは分けて扱うほうが、問題が起きたときに原因を切り分けやすくなります。

事前に用意するもの

成果物用のS3バケット：パイプラインのステージ間でファイルを受け渡すために使います。パイプラインの作成画面で既定のものを作らせることもできます。
EC2インスタンス側の準備：CodeDeployエージェントをインストールし、インスタンスプロファイル（IAMロール）に成果物のバケットを読み取る権限を付けます。エージェントの導入手順はOSによって違うため、公式の手順に従ってください。
CodeDeployのアプリケーションとデプロイグループ：デプロイ先のEC2を、タグ（例: Role=wp-web）で指定します。デプロイグループにはCodeDeploy用のサービスロールを設定します。

本番環境に対していきなり試すのではなく、ステージング用のEC2とデプロイグループを先に作り、そちらで一通り流れることを確認してください。

ステップ1：GitHubと接続する

GitHubのリポジトリをソースにするには、AWS側で「接続（Connection）」を作ります。この仕組みは以前 CodeStar Connections と呼ばれ、現在は CodeConnections という名前になっています。

接続を作成した直後は「保留中」の状態で、まだ使えません。コンソールで接続を開き、GitHub側でAWSのアプリをインストールして対象のリポジトリへのアクセスを許可すると「利用可能」になります。CLIやTerraformで接続を作った場合も、この承認だけはコンソールで行う必要がある点がつまずきやすいところです。GitHubのアプリに許可するリポジトリは、必要なものだけに絞っておきます。

ステップ2：パイプラインを作る

コンソールでパイプラインを新規作成し、パイプラインのタイプは「V2」を選びます。V2では、ブランチ名やタグ、変更されたファイルのパスで起動の条件（トリガー）を絞り込めます。たとえば「main ブランチで、wp-content/themes/my-theme/ 以下が変わったときだけ動かす」といった指定ができ、関係のない変更で毎回デプロイが走るのを防げます。

ソースステージでは先ほどの接続とリポジトリ・ブランチを選び、ビルドステージでCodeBuildのプロジェクトを新しく作ります。CodeBuildのイメージには、AWSが用意しているマネージドイメージ（Amazon LinuxやUbuntuの標準イメージ）を選びます。

ステップ3：buildspec.yml を書く

CodeBuildが何をするかは、リポジトリの直下に置く buildspec.yml に書きます。

version: 0.2

phases:
  install:
    runtime-versions:
      php: 8.3
      nodejs: 20
  pre_build:
    commands:
      - composer install --no-interaction --prefer-dist
      - vendor/bin/phpcs --standard=phpcs.xml.dist wp-content/themes/my-theme
  build:
    commands:
      - cd wp-content/themes/my-theme && npm ci && npm run build && cd -
      - composer install --no-dev --optimize-autoloader --no-interaction

artifacts:
  files:
    - appspec.yml
    - scripts/**/*
    - wp-content/themes/my-theme/**/*
  exclude-paths:
    - wp-content/themes/my-theme/node_modules/**/*

ポイントは次のとおりです。

**runtime-versions の値は、選んだイメージが対応している版から選ぶ**：対応していない版を書くとビルドの最初で失敗します。対応表はCodeBuildのドキュメントにイメージごとに載っています。
チェックはビルドより前に：phpcs で規約違反が見つかるとコマンドが0以外の終了コードを返し、ビルドが失敗してデプロイに進みません。問題のあるコードが本番に出る前に止まる、というのがCIの役割です。
成果物は必要なものだけ：node_modules やテスト用のファイルを本番に送らないよう、files と exclude-paths で絞ります。
秘密情報はbuildspecに直接書かない：APIキーなどが必要な場合は、env の parameter-store や secrets-manager でSystems Manager パラメータストアやSecrets Managerから読み込みます。ログに値を出力しないことにも注意します。

ステップ4：appspec.yml とデプロイ用スクリプト

CodeDeployがEC2の上で何をするかは appspec.yml に書きます。

version: 0.0
os: linux
files:
  - source: wp-content/themes/my-theme
    destination: /var/www/html/wp-content/themes/my-theme
file_exists_behavior: OVERWRITE
hooks:
  AfterInstall:
    - location: scripts/after_install.sh
      timeout: 120
      runas: root
  ValidateService:
    - location: scripts/validate.sh
      timeout: 60
      runas: root

#!/bin/bash
# scripts/after_install.sh
set -euo pipefail
chown -R www-data:www-data /var/www/html/wp-content/themes/my-theme
sudo -u www-data wp --path=/var/www/html cache flush

#!/bin/bash
# scripts/validate.sh
set -euo pipefail
curl -fsS -o /dev/null https://example.com/

file_exists_behavior: OVERWRITE を指定しないと、配置先に同じ名前のファイルがあるときにデプロイが失敗します。ValidateService のスクリプトは、トップページがエラーを返したら0以外で終了し、デプロイを失敗扱いにするためのものです。after_install.sh はサーバーにWP-CLIが入っている前提で、オブジェクトキャッシュを使っていない環境なら cache flush の行は省けます。ユーザー名（www-data）やパス、URLは環境に合わせてください。また、例の phpcs は composer.json の開発用の依存として入れておく想定です。

この方法は配置中のごく短い間、新旧のファイルが混ざった状態になります。アクセスの多いサイトでは、リリースごとに別のディレクトリへ配置してシンボリックリンクを切り替える方式のほうが安全です。

ステップ5：本番の前に承認を挟む

ステージングと本番の2段構成にする場合は、ステージングへのDeployステージのあとに「手動承認」のアクションを置き、その後に本番へのDeployステージを置きます。承認の依頼はSNSのトピックで通知でき、担当者はステージングで表示を確かめてから承認します。誰がいつ承認したかが記録に残るので、変更の管理にも役立ちます。

失敗したときの調べ方

パイプラインのどのステージで止まったかによって、見る場所が変わります。

Sourceで失敗：接続が「利用可能」になっているか、GitHub側でアプリにリポジトリへのアクセスを許可しているかを確認します。
Buildで失敗：CodeBuildのビルドログ（CloudWatch Logs）を開き、最後に失敗したコマンドを探します。多いのは runtime-versions の指定ミス、依存パッケージの取得失敗、規約チェックの違反です。
Deployで失敗：CodeDeployのデプロイの詳細で、どのライフサイクルイベント（AfterInstall など）で止まったかを見ます。さらに詳しくは、EC2の上のCodeDeployエージェントのログに、スクリプトの出力が残っています。エージェントが停止している、インスタンスプロファイルにS3の読み取り権限が無い、スクリプトに実行権限が無い、といった原因がよくあります。

切り戻し（ロールバック）

デプロイグループで「失敗時に自動でロールバックする」設定を有効にしておくと、ValidateService などで失敗したときに、直前に成功した版が再びデプロイされます。手動で戻す場合は、CodeDeployで以前のリビジョンを選んで再デプロイするか、Gitでコミットを打ち消して（revert）からパイプラインを流し直します。

注意したいのは、戻るのはファイルだけだという点です。テーマの更新でデータベースの設定値を書き換えるような処理を入れている場合、それは自動では元に戻りません。データベースに影響する変更を含むリリースの前には、バックアップを取っておいてください。

まとめ

CodePipelineは「Source → Build → Deploy」をつなぐ仕組み。V2のパイプラインならブランチやパスで起動条件を絞れる。
GitHubとの接続（CodeConnections）は、作成後にコンソールでの承認が必要。
buildspec.yml でチェックとビルドを行い、失敗したらデプロイに進まないようにする。秘密情報はパラメータストアなどから読み込む。
appspec.yml では file_exists_behavior と ValidateService を設定し、表示の確認に失敗したら自動でロールバックさせる。
wp-config.php、アップロードファイル、データベースはパイプラインの対象外にし、ステージングで流れを確認してから本番に使う。