WordPress のプラグイン管理、手動でアップロードしたり、管理画面からインストールしたりしていませんか? 開発環境と本番環境でプラグインのバージョンが異なってしまったり、どのプラグインをインストールしたか忘れてしまったり...そんな悩みを抱えている方も多いのではないでしょうか。

今回ご紹介する Bedrock と Composer を活用すれば、プラグイン管理を コードで完全に管理 できるようになります。チーム開発でも一貫性のある環境を構築でき、デプロイも圧倒的にスムーズになるでしょう。

背景

WordPress の従来のプラグイン管理

WordPress では従来、プラグインのインストールや更新を以下のいずれかの方法で行ってきました。

#	方法	特徴	課題
1	管理画面から手動インストール	初心者でも簡単	バージョン管理が困難
2	FTP でアップロード	直接的な操作	環境間の同期が大変
3	WP-CLI でインストール	コマンドラインで効率的	バージョン固定が難しい

こうした手法では、開発環境と本番環境で異なるバージョンのプラグインが動作してしまうリスクが常につきまといます。

モダンな開発手法との乖離

一方、PHP の世界では Composer というパッケージ管理ツールが標準となっており、Laravel や Symfony などのフレームワークでは当たり前のように使われています。

mermaidCopy codeflowchart TB
  subgraph modern["モダンな PHP 開発"]
    composer["Composer"]
    composer_json["composer.json<br/>(依存関係定義)"]
    composer_lock["composer.lock<br/>(バージョン固定)"]
    packages["パッケージ自動取得"]

    composer_json -->|読み込み| composer
    composer -->|依存解決| packages
    composer -->|生成| composer_lock
  end

  subgraph traditional["従来の WordPress"]
    manual["手動インストール"]
    ftp["FTP アップロード"]
    version_issue["バージョン不整合"]

    manual --> version_issue
    ftp --> version_issue
  end

  modern -.->|導入| traditional

図のポイント:

• モダンな PHP 開発では依存関係を composer.json で管理
• Composer が自動的にパッケージを取得し、バージョンを固定
• 従来の WordPress ではこうした仕組みが欠けていた

しかし WordPress のコア構造では、Composer を直接活用するのが難しい状況でした。そこで登場したのが Bedrock です。

Bedrock とは

Bedrock は、WordPress をモダンな開発環境で扱えるようにするための ボイラープレート(雛形プロジェクト) です。Roots 社が開発しており、以下の特徴があります。

• Composer によるパッケージ管理
• 環境変数による設定管理(.env ファイル)
• セキュリティ強化されたディレクトリ構造
• WordPress コアとプラグインの分離

これにより、WordPress 開発に Git、Composer、環境変数といったモダンな開発手法を取り入れることができるのです。

課題

プラグイン管理における具体的な課題

WordPress の従来のプラグイン管理では、以下のような課題が頻繁に発生します。

課題 1: バージョン管理の困難さ

開発環境でプラグイン A のバージョン 1.5 を使っていたのに、本番環境では誤ってバージョン 2.0 にアップデートしてしまい、互換性の問題で本番サイトが壊れてしまう...といったケースです。

課題 2: 環境の再現性が低い

新しいメンバーがプロジェクトに参加したとき、「どのプラグインをインストールすればいいのか」をドキュメントで管理するしかありません。しかも、バージョンまで正確に再現するのは至難の業でしょう。

課題 3: デプロイ作業の煩雑さ

本番環境へのデプロイ時に、プラグインを手動でアップロードしたり、管理画面から 1 つずつインストールしたりするのは、時間がかかるだけでなくミスも起こりやすいですね。

課題 4: セキュリティリスク

古いバージョンのプラグインを使い続けることで、脆弱性が放置される可能性があります。どのプラグインがどのバージョンなのか把握できていないと、セキュリティアップデートにも対応できません。

mermaidCopy codeflowchart TD
  dev["開発環境<br/>プラグイン v1.5"]
  staging["ステージング環境<br/>プラグイン v1.8"]
  prod["本番環境<br/>プラグイン v2.0"]

  dev -->|"手動デプロイ<br/>(バージョン不整合)"| staging
  staging -->|"手動デプロイ<br/>(バージョン不整合)"| prod

  prod -->|"不具合発生"| error["エラー: 互換性問題"]

  style error fill:#ff6b6b
  style dev fill:#4ecdc4
  style staging fill:#ffe66d
  style prod fill:#ff6b6b

課題の本質:

• 各環境でプラグインのバージョンがバラバラ
• 手動デプロイによるヒューマンエラー
• 結果として本番環境で不具合が発生

これらの課題を解決するには、プラグインの依存関係とバージョンをコードとして管理 する仕組みが必要です。

解決策

Bedrock と Composer によるプラグイン管理

Bedrock と Composer を組み合わせることで、これらの課題を一挙に解決できます。

解決のポイント

#	課題	Bedrock + Composer による解決
1	バージョン管理の困難さ	composer.lock でバージョンを完全固定
2	環境の再現性が低い	composer install 一発で同じ環境を構築
3	デプロイ作業の煩雑さ	Git + Composer で自動デプロイ可能
4	セキュリティリスク	バージョン管理により更新状況を可視化

アーキテクチャの全体像

Bedrock を導入すると、WordPress のディレクトリ構造が以下のように変わります。

mermaidCopy codeflowchart TB
  subgraph bedrock["Bedrock プロジェクト構造"]
    root["プロジェクトルート"]

    root --> composer_json["composer.json<br/>(依存定義)"]
    root --> composer_lock["composer.lock<br/>(バージョン固定)"]
    root --> env[".env<br/>(環境変数)"]
    root --> web["web/<br/>(公開ディレクトリ)"]
    root --> config["config/<br/>(設定ファイル)"]

    web --> wp["wp/<br/>(WordPress コア)"]
    web --> app["app/"]

    app --> plugins["plugins/<br/>(プラグイン)"]
    app --> themes["themes/<br/>(テーマ)"]
    app --> mu_plugins["mu-plugins/<br/>(必須プラグイン)"]
  end

  composer_json -->|"composer install"| plugins
  composer_json -->|"composer install"| wp

  style composer_json fill:#61dafb
  style composer_lock fill:#61dafb
  style plugins fill:#95e1d3
  style wp fill:#95e1d3

構造のポイント:

• composer.json でプラグインや WordPress コア自体を定義
• composer install で自動的に必要なファイルを配置
• WordPress コアも依存パッケージとして管理

この構造により、プラグインもテーマも WordPress コア自体も、すべて Composer で管理できるようになります。

Composer によるパッケージ管理の仕組み

Composer は PHP のパッケージ管理ツールで、以下の流れでプラグインを管理します。

mermaidCopy codesequenceDiagram
  participant Dev as 開発者
  participant JSON as composer.json
  participant Composer as Composer
  participant Packagist as WordPress<br/>Packagist
  participant Plugins as プラグイン<br/>ディレクトリ

  Dev->>JSON: プラグイン追加<br/>composer require
  JSON->>Composer: 依存情報読み込み
  Composer->>Packagist: パッケージ情報取得
  Packagist->>Composer: バージョン情報返却
  Composer->>Plugins: プラグイン<br/>ダウンロード & インストール
  Composer->>JSON: composer.lock 生成
  JSON-->>Dev: インストール完了

プロセスの要点:

• 開発者は composer require コマンドでプラグインを追加
• Composer が WordPress Packagist からプラグイン情報を取得
• 自動的にダウンロードして適切なディレクトリに配置
• composer.lock でバージョンを固定

これにより、手動でのダウンロードやアップロード作業が一切不要になります。

具体例

Bedrock のセットアップ

それでは実際に Bedrock をセットアップして、Composer でプラグインを管理する方法を見ていきましょう。

ステップ 1: Bedrock プロジェクトの作成

まず、Composer を使って Bedrock プロジェクトを作成します。

bashCopy code# Bedrock プロジェクトを作成
composer create-project roots/bedrock my-wordpress-site

このコマンドにより、my-wordpress-site ディレクトリに Bedrock の雛形が作成されます。

ステップ 2: 環境変数の設定

次に、.env ファイルを編集してデータベース接続情報などを設定します。

bashCopy code# プロジェクトディレクトリに移動
cd my-wordpress-site

# .env.example をコピーして .env を作成
cp .env.example .env

.env ファイルを開き、以下の項目を編集しましょう。

envCopy code# データベース設定
DB_NAME='wordpress_db'
DB_USER='db_user'
DB_PASSWORD='db_password'

# WordPress 設定
WP_ENV='development'
WP_HOME='http://localhost:8000'
WP_SITEURL="${WP_HOME}/wp"

# セキュリティキー(自動生成推奨)
AUTH_KEY='your-unique-key-here'
SECURE_AUTH_KEY='your-unique-key-here'
LOGGED_IN_KEY='your-unique-key-here'
NONCE_KEY='your-unique-key-here'

設定のポイント:

• WP_ENV で環境(development/staging/production)を切り替え
• WP_HOME にサイトの URL を設定
• セキュリティキーは専用ジェネレーターで生成すると安全

セキュリティキーは以下のサイトで生成できます: https://roots.io/salts.html

ステップ 3: ディレクトリ構造の確認

Bedrock をインストールすると、以下のような構造になります。

bashCopy codemy-wordpress-site/
├── composer.json      # 依存パッケージ定義
├── composer.lock      # バージョン固定ファイル
├── .env              # 環境変数(Git 管理外)
├── .env.example      # 環境変数のサンプル
├── config/           # 設定ファイル
│   ├── application.php
│   └── environments/
├── web/              # 公開ディレクトリ
│   ├── app/
│   │   ├── mu-plugins/  # 必須プラグイン
│   │   ├── plugins/     # プラグイン
│   │   ├── themes/      # テーマ
│   │   └── uploads/     # アップロードファイル
│   ├── wp/           # WordPress コア
│   └── index.php
└── vendor/           # Composer パッケージ

重要なディレクトリ:

• web​/​app​/​plugins​/​: プラグインが配置される場所
• web​/​wp​/​: WordPress コア本体
• config​/​: 環境ごとの設定ファイル

プラグインのインストール

それでは実際に Composer を使ってプラグインをインストールしてみましょう。

WordPress Packagist の仕組み

WordPress の公式プラグインリポジトリにあるプラグインは、WordPress Packagist というサービスを通じて Composer で利用できます。

Bedrock ではデフォルトで composer.json にこの設定が含まれています。

jsonCopy code{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org",
      "only": ["wpackagist-plugin/*", "wpackagist-theme/*"]
    }
  ]
}

WordPress Packagist の役割:

• WordPress 公式リポジトリのプラグインを Composer 形式で提供
• プラグイン名に wpackagist-plugin​/​ という接頭辞を付けて管理
• テーマも同様に wpackagist-theme​/​ で管理可能

プラグインのインストール方法

例として、人気のプラグイン「Contact Form 7」と「Advanced Custom Fields」をインストールしてみましょう。

bashCopy code# Contact Form 7 をインストール
composer require wpackagist-plugin/contact-form-7

このコマンドを実行すると、以下の処理が自動的に行われます。

1. WordPress Packagist から最新バージョン情報を取得
2. プラグインファイルをダウンロード
3. web​/​app​/​plugins​/​contact-form-7​/​ にインストール
4. composer.json に依存関係を追加
5. composer.lock にバージョン情報を記録

次に Advanced Custom Fields もインストールしましょう。

bashCopy code# Advanced Custom Fields をインストール
composer require wpackagist-plugin/advanced-custom-fields

バージョン指定の方法

特定のバージョンをインストールしたい場合は、バージョン番号を指定できます。

bashCopy code# Contact Form 7 のバージョン 5.8 を指定してインストール
composer require wpackagist-plugin/contact-form-7:5.8.*

バージョン指定の記法:

#	記法	意味
1	5.8.*	5.8.x の最新版(5.8.0, 5.8.1 など)
2	^5.8	5.8 以上 6.0 未満の最新版
3	~5.8.0	5.8.0 以上 5.9.0 未満
4	5.8.1	厳密に 5.8.1 のみ

開発では ^ や * で柔軟性を持たせつつ、composer.lock で実際のバージョンを固定するのがベストプラクティスです。

composer.json の確認

プラグインをインストールすると、composer.json の require セクションに以下のように追加されます。

jsonCopy code{
  "require": {
    "php": ">=8.0",
    "roots/bedrock": "^1.22",
    "wpackagist-plugin/contact-form-7": "^5.8",
    "wpackagist-plugin/advanced-custom-fields": "^6.2"
  }
}

composer.json のポイント:

• require セクションに必要なパッケージとバージョンを定義
• WordPress コア(roots​/​wordpress)も依存パッケージとして記載
• チームメンバーはこのファイルを見れば必要なプラグインがわかる

プラグインの更新とバージョン管理

プラグインの更新方法

インストール済みのプラグインを更新するには、以下のコマンドを使います。

bashCopy code# 全プラグインを更新
composer update

# 特定のプラグインのみ更新
composer update wpackagist-plugin/contact-form-7

更新すると、composer.lock ファイルが自動的に更新され、新しいバージョンが記録されます。

composer.lock の重要性

composer.lock ファイルには、実際にインストールされたパッケージの 正確なバージョン が記録されています。

jsonCopy code{
  "packages": [
    {
      "name": "wpackagist-plugin/contact-form-7",
      "version": "5.8.4",
      "source": {
        "type": "svn",
        "url": "https://plugins.svn.wordpress.org/contact-form-7/",
        "reference": "tags/5.8.4"
      }
    }
  ]
}

composer.lock の役割:

• 全メンバーが同じバージョンのプラグインを使用できる
• 開発環境、ステージング、本番で完全に同一の環境を再現
• Git で管理することでバージョン履歴を追跡可能

このファイルは 必ず Git にコミット してください。これにより、チーム全員が同じバージョンで開発できます。

環境の再現

新しいメンバーがプロジェクトに参加したり、新しいサーバーにデプロイする際は、以下のコマンドで環境を再現できます。

bashCopy code# Git リポジトリをクローン
git clone https://github.com/your-team/your-wordpress-project.git
cd your-wordpress-project

# composer.lock に記録されたバージョンでインストール
composer install

# 環境変数を設定
cp .env.example .env
# .env を編集してデータベース情報などを設定

再現の流れ:

1. git clone でコードを取得
2. composer install で同じバージョンのプラグインをインストール
3. .env で環境固有の設定を行う

composer install は composer.lock を読み込むため、全員が 完全に同じバージョン のプラグインを使用できるのです。

有料プラグインやカスタムプラグインの管理

WordPress Packagist では公式リポジトリのプラグインしか扱えませんが、有料プラグインやカスタムプラグインも Composer で管理できます。

方法 1: プライベートリポジトリを使う

Git リポジトリにプラグインを格納し、Composer でインストールする方法です。

まず、composer.json にプライベートリポジトリを追加します。

jsonCopy code{
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/your-company/custom-plugin.git"
    }
  ],
  "require": {
    "your-company/custom-plugin": "^1.0"
  }
}

プラグイン側の composer.json は以下のように設定します。

jsonCopy code{
  "name": "your-company/custom-plugin",
  "type": "wordpress-plugin",
  "require": {
    "composer/installers": "^2.0"
  }
}

プライベートリポジトリ方式のメリット:

• Git でバージョン管理できる
• プルリクエストでコードレビュー可能
• CI/CD と統合しやすい

方法 2: ローカルパッケージとして管理

プラグインファイルをプロジェクト内に配置し、Composer で認識させる方法もあります。

jsonCopy code{
  "repositories": [
    {
      "type": "path",
      "url": "./local-plugins/premium-plugin"
    }
  ],
  "require": {
    "vendor-name/premium-plugin": "@dev"
  }
}

この方法では、local-plugins​/​premium-plugin​/​ ディレクトリにプラグインファイルを配置します。

ローカルパッケージ方式の用途:

• 開発中のカスタムプラグイン
• ライセンスの都合で Git 管理できないプラグイン
• 小規模なプロジェクト固有のプラグイン

デプロイのワークフロー

Bedrock と Composer を使ったデプロイのワークフローを見てみましょう。

Git + Composer によるデプロイ

mermaidCopy codeflowchart LR
  dev["開発環境"]
  git["Git リポジトリ<br/>(GitHub など)"]
  staging["ステージング環境"]
  prod["本番環境"]

  dev -->|"git push"| git
  git -->|"git pull"| staging
  staging -->|"composer install"| staging_plugins["同一バージョンの<br/>プラグイン配置"]

  staging -.->|"動作確認 OK"| git
  git -->|"git pull"| prod
  prod -->|"composer install"| prod_plugins["同一バージョンの<br/>プラグイン配置"]

  style staging_plugins fill:#95e1d3
  style prod_plugins fill:#95e1d3

デプロイフローの要点:

• 開発環境で composer.lock をコミット
• ステージング・本番では composer install で同じバージョンを取得
• 全環境で完全に同一のプラグイン構成

デプロイスクリプトの例

自動デプロイを行う場合の簡単なスクリプト例です。

bashCopy code#!/bin/bash

# デプロイスクリプト(deploy.sh)

# 最新のコードを取得
git pull origin main

# 依存パッケージをインストール(composer.lock に基づく)
composer install --no-dev --optimize-autoloader

# キャッシュをクリア(必要に応じて)
wp cache flush

スクリプトのポイント:

• --no-dev: 開発用パッケージを除外(本番環境用)
• --optimize-autoloader: オートロード最適化でパフォーマンス向上
• composer.lock に記録されたバージョンを厳密に再現

このスクリプトを CI/CD パイプライン(GitHub Actions、GitLab CI など)に組み込めば、完全自動デプロイが実現できます。

プラグインの削除

不要になったプラグインを削除する方法も確認しておきましょう。

bashCopy code# プラグインを削除
composer remove wpackagist-plugin/contact-form-7

このコマンドにより、以下が自動的に行われます。

1. web​/​app​/​plugins​/​contact-form-7​/​ ディレクトリを削除
2. composer.json から依存関係を削除
3. composer.lock を更新

削除時の注意点:

• WordPress 管理画面からの削除は不要
• Composer で削除すれば、ファイルも設定も自動的に削除される
• Git コミットで削除履歴が残る

まとめ

Bedrock と Composer を活用することで、WordPress のプラグイン管理は劇的に改善されます。

得られるメリット

#	メリット	詳細
1	バージョン管理の徹底	composer.lock で全プラグインのバージョンを固定
2	環境の完全再現	composer install 一発で同じ環境を構築
3	チーム開発の効率化	Git でプラグイン構成を共有し、競合を防止
4	デプロイの自動化	CI/CD パイプラインと統合しやすい
5	セキュリティ向上	バージョン管理により脆弱性対応が容易

始めるためのステップ

Bedrock を導入するには、以下の手順で進めましょう。

ステップ 1: Composer をインストール(まだの場合)

• https://getcomposer.org/ からインストール

ステップ 2: Bedrock プロジェクトを作成

• composer create-project roots​/​bedrock

ステップ 3: 環境変数を設定

• .env ファイルでデータベース接続などを設定

ステップ 4: プラグインを Composer で追加

• composer require wpackagist-plugin​/​プラグイン名

ステップ 5: Git で管理

• composer.json と composer.lock をコミット

今後の展開

Bedrock を導入したら、次のステップとして以下も検討してみてください。

• Trellis: Bedrock と連携する Ansible ベースのサーバープロビジョニングツール
• Sage: モダンな WordPress テーマ開発フレームワーク
• CI/CD 統合: GitHub Actions や GitLab CI でテスト・デプロイを自動化

WordPress 開発をモダンで効率的なものにするため、ぜひ Bedrock と Composer を活用してみてください。一度慣れてしまえば、もう従来の手動管理には戻れないほど便利ですよ。

関連リンク

• Bedrock 公式サイト
• Bedrock ドキュメント
• WordPress Packagist
• Composer 公式サイト
• Roots 公式サイト(Trellis, Sage も含む)
• Bedrock GitHub リポジトリ
• WordPress セキュリティキージェネレーター