2026年6月22日

WordPressのメディアをAmazon S3へオフロードする設定手順とつまずきどころ

メディア・画像

WordPressのメディアをAmazon S3へ逃がす（オフロードする）なら、S3バケットとIAMの権限をAWS側で用意し、オフロード用プラグインで「アップロード時にS3へコピーし、配信URLをS3またはCloudFrontに書き換える」構成にするのが現実的です。この記事では、バケットの作り方、最小権限のIAM設定、プラグインの設定、既存メディアの扱い、動作確認までを順に説明します。

オフロードで何が変わるのか

通常、メディアは wp-content/uploads/ に保存され、Webサーバーから配信されます。オフロードすると、アップロードされたファイル（サムネイルなどの派生サイズを含む）がS3にコピーされ、記事中の画像URLがS3やCDNのURLに置き換わります。

得られるものは主に3つです。サーバーのディスク容量を圧迫しにくくなること、画像配信の負荷をWebサーバーから外せること、複数台構成のサーバーでメディアを共有しやすくなることです。一方で、AWSの利用料（保存量・リクエスト数・転送量）が発生し、トラブル時の切り分け箇所が増えます。料金体系は変わるため、事前にAWSの料金ページで確認してください。

作業前の準備

本番で試す前に、ステージング環境で一通り動かすことを勧めます。オフロードはURLの書き換えを伴うため、設定を誤ると画像が一斉に表示されなくなるからです。

データベースと wp-content/uploads/ のバックアップを取る
使うAWSリージョンを決める（日本の読者が中心なら東京リージョン ap-northeast-1 が一般的です）
配信に独自ドメイン（例: cdn.example.com）を使うかどうかを決める

ステップ1：S3バケットを作成する

AWSマネジメントコンソールのS3でバケットを作成します。バケット名は世界で一意なので、サイト名を含めた分かりやすい名前にします。

公開設定は、現在のAWSの推奨に沿って「パブリックアクセスをすべてブロック」を有効にしたままにし、配信はCloudFront経由にする構成が安全です。新規バケットは既定でACLが無効（オブジェクト所有者の強制）になっているため、ACLで個別ファイルを公開する古い手順は、そのままでは通りません。プラグイン側にもこの状態に合わせる設定があるので、後のステップで合わせます。

S3から直接配信したい場合はパブリック読み取りを許可するバケットポリシーが必要になりますが、バケット全体が外部から見える状態になるため、CloudFront経由の構成と比較したうえで選んでください。

ステップ2：最小権限のIAMを用意する

WordPressがS3へ書き込むための認証情報を用意します。管理者権限のアクセスキーを使い回すのは避け、対象バケットだけを操作できる専用の権限にします。

WordPressがEC2上で動いているなら、アクセスキーを発行せずにIAMロールをインスタンスに割り当てる方法が安全です。それ以外のサーバーでは専用のIAMユーザーを作り、次のようなポリシーを付けます。your-bucket-name は実際のバケット名に置き換えてください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::your-bucket-name"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

プラグインによっては、バケット一覧の取得やACLの設定など追加の権限を求めることがあります。エラーが出たら、プラグインのドキュメントに載っている必要権限と突き合わせて足りないものだけを追加します。

アクセスキーはプラグインの設定画面に入力するより、wp-config.php の定数で渡す方法が推奨されることが多いです。データベースに保存されず、画面からも見えなくなるためです。wp-config.php はGitにコミットしないでください。

ステップ3：オフロード用プラグインを設定する

代表的なのは「WP Offload Media Lite」（旧名 WP Offload S3 Lite）です。無料版では新規アップロードのオフロードとURL書き換えができ、既存メディアの一括オフロードなどは有料版の機能という構成です（2026年10月現在。機能の分け方は変わることがあるため、公式の説明で確認してください）。

WP Offload Media の場合、認証情報は wp-config.php に次のような定数で書けます。定数名やキーの名前は製品のドキュメントに従ってください。

// wp-config.php（"That's all, stop editing!" の行より上に書く）
define( 'AS3CF_SETTINGS', serialize( array(
    'provider'          => 'aws',
    'access-key-id'     => 'your-access-key-id',
    'secret-access-key' => 'your-secret-access-key',
) ) );

EC2のIAMロールを使う場合は、アクセスキーの代わりにサーバーロールを使う設定にします。

プラグインの設定画面では、おおむね次の項目を目的に沿って決めます。画面の表記はバージョンによって変わります。

使用するバケット: ステップ1で作ったバケットを選ぶ
オフロードの有効化: 新しくアップロードしたファイルをS3へコピーする
URLの書き換え: 配信URLをS3またはCDNのものに置き換える
独自ドメインの配信: CloudFrontのドメインや cdn.example.com を指定する
ローカルファイルの削除: S3へコピーした後にサーバー上のファイルを消すかどうか

最後の「ローカルファイルの削除」は、最初は無効のままにしておくのが無難です。消してしまうと、プラグインを停止したときにURLが元のローカルパスに戻り、画像が表示されなくなります。運用が安定し、バックアップの方法を決めてから有効にしてください。

ステップ4：CloudFrontで配信する

パブリックアクセスをブロックしたバケットから配信するには、CloudFrontのディストリビューションを作成し、オリジンにS3バケットを指定して、オリジンアクセスコントロール（OAC）でCloudFrontからだけ読めるようにします。コンソールの案内に従うと、必要なバケットポリシーの雛形が表示されます。

独自ドメインを使う場合、CloudFront用のSSL証明書はAWS Certificate Managerの米国東部（バージニア北部、us-east-1）リージョンで発行する決まりがあります。東京リージョンで発行した証明書は選択肢に出てこないので注意してください。DNSには cdn.example.com をCloudFrontのドメインへ向けるCNAMEを追加します。

既存メディアの扱い

オフロードを有効にしても、それ以前にアップロードされたファイルは自動では移りません。既存分をどうするかは次のどちらかです。

プラグインの一括オフロード機能を使う（製品や版によっては有料）
AWS CLIで wp-content/uploads/ をS3へ同期し、プラグイン側でそのファイルを認識させる

後者はプラグインがファイルとS3の対応をデータベースで管理している場合、ファイルを置いただけではURLが書き換わりません。手作業で進めるより、プラグインの公式手順に沿うほうがトラブルは少なくなります。

動作確認のしかた

設定が終わったら、次の順で確認します。

テスト画像を1枚アップロードし、メディアライブラリでそのファイルのURLがS3またはCDNのドメインになっているかを見る
S3コンソールで、元画像とサムネイルなどの派生サイズがバケットに入っているかを見る
記事に貼った画像が表示されるか、ブラウザの開発者ツールのネットワークタブで配信元のドメインとステータスコードを確認する

コマンドで確かめるなら、次のようにヘッダーを見ます。403が返る場合はバケットポリシーかOACの設定、404ならオブジェクトのキー（パス）がずれていることが多いです。

curl -I https://cdn.example.com/wp-content/uploads/2026/10/sample.jpg

よくあるつまずき

アップロード時に権限エラーが出る: IAMポリシーのリソース指定（バケット名と /* の有無）を見直す
画像が403になる: バケットが非公開なのにS3のURLで直接配信しようとしている。CloudFront経由にするか、配信設定を見直す
混在コンテンツの警告が出る: 配信URLが http:// になっていないかを確認する
プラグイン停止後に画像が消えた: ローカルファイル削除を有効にしていた。S3からファイルを戻すか、プラグインを再度有効にする

また、ローカルからファイルを消す運用にした場合、サーバー側のバックアップにはメディアが含まれなくなります。S3のバージョニングを有効にするなど、メディアを別途守る方法を決めておいてください。

まとめ

S3はパブリックアクセスをブロックしたまま、CloudFront（OAC）経由で配信する構成が安全
IAMは対象バケットだけを操作できる最小権限にし、EC2ならIAMロールを使う
認証情報は wp-config.php の定数で渡し、Gitに含めない
「ローカルファイルの削除」は運用が安定してから有効にする
既存メディアの移行はプラグインの公式手順に沿い、バックアップを先に取る