WordPressの画像管理はアップロード前に決まる：メディアライブラリ、代替テキスト、API更新の基本
WordPressで画像を安全に扱う基本は、アップロードしてから考えることではありません。公開してよいファイルだけを入れ、用途に合うサイズを選び、代替テキストを画像の役割に合わせて書く。この3つで、表示崩れ、読み上げの不親切さ、不要なファイル公開の多くを避けられます。
メディアライブラリは、画像を置いておく倉庫ではなく、記事や固定ページで使う画像の情報を管理する場所です。WordPress公式ドキュメントでも、メディアライブラリではアップロード済みメディアの編集、表示、削除、検索、絞り込みができると説明されています。
この記事では、WordPress管理画面で画像を扱う初心者から実務初級者向けに、次の点を整理します。
- 画像アップロード前に確認すること
- メディアライブラリで見るべき項目
- 代替テキスト、キャプション、タイトルの違い
- ブロックエディターで画像サイズを選ぶ考え方
- REST APIで
alt_textを確認・更新する最小例 - よくある失敗と代替手段
対象環境は、通常のWordPress管理画面とブロックエディターです。API例はWordPress REST APIを使い、認証にはアプリケーションパスワードなどの安全な方法を使う前提で説明します。
画像を安全に扱う第一歩は「公開できるか」を先に見ること
WordPressにアップロードした画像は、記事本文に表示しなくても、ファイルURLとして参照できる場合があります。だから最初に見るべきなのは、画質やSEOよりも「その画像を公開してよいか」です。
チェックする順番はシンプルです。
- 個人情報、顧客名、社内資料、管理画面のURLが写っていないか
- ファイル名に案件名、氏名、内部コードが入っていないか
- スクリーンショットにメールアドレス、APIキー、トークンが含まれていないか
- 画像のサイズが大きすぎて、ページ表示を重くしないか
- 画像の意味を本文か代替テキストで説明できるか
特にスクリーンショットは危険です。ブラウザ上部のタブ名、管理画面の通知、サイドバーのユーザー名など、本文の主題と関係ない情報まで写り込みます。アップロード後にWordPress上でトリミングするより、先に画像編集ツールで不要部分を隠すほうが安全です。
ここがポイント: WordPressに入れる前に「公開してよい画像か」「説明できる画像か」を決める。メディアライブラリは、その判断を後から補助する場所です。
メディアライブラリでは「画像そのもの」と「画像情報」を分けて見る
メディアライブラリで管理するのは、画像ファイルだけではありません。ファイル名、ファイルタイプ、ファイルサイズ、寸法、代替テキスト、タイトル、キャプション、説明、ファイルURLなども確認できます。
WordPress公式のMedia Library screenでは、画像の添付ファイル詳細でこれらの属性を確認・編集できることが示されています。
実務で見るべき項目
画像を1枚追加したら、最低限この項目を見ます。
- File name:
client-a-secret-plan.pngのような内部情報を含まないか - File size: 不必要に大きい画像をそのまま使っていないか
- Dimensions: 横幅4000pxなど、表示サイズに対して大きすぎないか
- Alt Text: 画像が表示されない場合や読み上げ時に意味が伝わるか
- Caption: 読者に見せる補足説明が必要か
- File URL: 直接アクセスされても問題ないファイルか
ここで混同しやすいのが、代替テキスト、キャプション、タイトルです。
| 項目 | 主な役割 | 例 |
|---|---|---|
| 代替テキスト | 画像の意味や機能を伝える | 注文履歴CSVをアップロードする画面 |
| キャプション | 読者に見える補足説明を付ける | CSVアップロード画面の例 |
| タイトル | 管理上の名前やテーマ側の表示に使われることがある | csv-upload-screen |
| 説明 | メディア詳細で長めの説明を残す | 操作手順記事で使うスクリーンショット |
代替テキストは、画像の見た目を細かく描写する欄ではありません。その画像が記事内で何を伝えるために置かれているかを書く欄です。
代替テキストは「画像の役割」から決める
代替テキストで迷ったら、画像の種類ではなく、記事内での役割を見ます。W3C WAIのImages Tutorialでは、情報を伝える画像、装飾画像、リンクやボタンとして機能する画像、複雑なグラフなど、目的ごとにテキスト代替を考える必要があると整理されています。
書き方の基本
実務では、次のように判断すると迷いにくくなります。
- 操作手順のスクリーンショット: 何の画面で、どの操作を示すかを書く
- 製品写真: 写真が本文の判断材料なら、対象と状態を書く
- グラフや表の画像: 重要な数値や結論は本文にも書く
- アイコン画像のリンク: 見た目ではなく、リンク先や操作を書く
- 装飾だけの画像: 空の代替テキストにする選択肢を検討する
W3C WAIのalt Decision Treeも、画像が意味を持つか、リンクやボタンとして使われるか、装飾だけかを順に判断する流れを示しています。
NG例と改善例
同じ画像でも、記事の文脈によってよい代替テキストは変わります。
NG例:
<img src="media-library.png" alt="画像">
これでは、読者は何の画像なのか分かりません。
改善例:
<img src="media-library.png" alt="WordPressのメディアライブラリで画像の代替テキストを編集している画面">
操作説明の記事なら、画面名と操作内容が分かるほうが役に立ちます。
ただし、画像の直前に「次に、メディアライブラリで代替テキスト欄を開きます」と本文で説明している場合は、代替テキストを短くしても意味は通ります。
<img src="alt-text-field.png" alt="代替テキスト欄">
代替テキストは長ければよいわけではありません。本文と合わせて読んだときに、画像が担っている意味が欠けないことが重要です。
ブロックエディターでは「デフォルトのalt」と「記事ごとのalt」を区別する
WordPressの画像ブロックでは、メディアライブラリ側に登録した代替テキストが、画像を挿入したときに引き継がれます。一方で、ブロック設定側で後から変更した代替テキストは、その投稿や固定ページ内の画像にだけ適用されます。これはImage blockの公式ドキュメントでも説明されています。
つまり、同じ画像を複数の記事で使う場合は、次のように分けます。
- メディアライブラリの代替テキスト: 画像そのものの標準説明
- 記事内の画像ブロックの代替テキスト: その記事での役割に合わせた説明
たとえば同じ管理画面スクリーンショットでも、記事Aでは「画像のアップロード手順」を説明し、記事Bでは「代替テキスト欄の位置」を説明するかもしれません。この場合、記事ごとの代替テキストを変えるほうが自然です。
サイズ指定は見た目だけでなく読み込みにも関係する
画像ブロックでは、テーマや元画像のサイズに応じて、Full Size、Large、Medium、Thumbnailなどの解像度を選べます。公式ドキュメントも、画像のResolutionとしてこれらの選択肢が表示される場合があると説明しています。
実務では、次の使い分けで十分です。
- 記事本文の通常画像: Largeまたはテーマに合う中間サイズ
- 小さな一覧やプロフィール画像: ThumbnailまたはMedium
- 図表や細かい文字を読ませる画像: 表示幅と可読性を確認して選ぶ
- 画面いっぱいのビジュアル: Full Sizeを使う前に容量を確認する
画像の見た目だけをドラッグで小さくしても、元ファイルが大きいままだと読み込みが重くなることがあります。アップロード前の圧縮と、ブロック側の適切な解像度選択をセットで考えます。
REST APIで画像のalt_textを確認・更新する
複数の記事や外部ツールから画像情報を管理するなら、WordPress REST APIのMediaエンドポイントを使えます。公式のMedia REST API referenceでは、メディア項目に alt_text、caption、description、source_url などのフィールドがあることが示されています。
入力例: メディア情報を取得する
画像IDが 123 のメディア情報を取得する例です。
curl https://example.com/wp-json/wp/v2/media/123
出力例の一部は次のような形です。
{
"id": 123,
"media_type": "image",
"mime_type": "image/png",
"alt_text": "WordPressのメディアライブラリで画像を選択している画面",
"source_url": "https://example.com/wp-content/uploads/2026/07/media-library.png"
}
ここで見るべきなのは、alt_text が空かどうかだけではありません。記事の文脈に合っているか、ファイルURLを直接開かれても問題ない画像かも確認します。
更新例: alt_textをAPIで変更する
認証済みユーザーで、メディアID 123 の代替テキストを更新する例です。
curl -X POST https://example.com/wp-json/wp/v2/media/123 \
-u "user:APPLICATION_PASSWORD" \
-H "Content-Type: application/json" \
-d '{"alt_text":"請求書CSVをアップロードする管理画面"}'
APPLICATION_PASSWORD には実際の認証情報が入ります。記事や共有メモにそのまま貼らないでください。実務では、環境変数やCIのシークレット管理に置き、ログに出力しない運用にします。
よくある失敗と直し方
画像まわりのトラブルは、アップロード時、本文挿入時、公開後の3段階で起きます。原因を切り分けると対応しやすくなります。
失敗1: 代替テキストにキーワードだけ詰める
検索対策のつもりで、次のように書くケースがあります。
<img src="screen.png" alt="WordPress 画像 SEO メディアライブラリ 代替テキスト">
これは読者にも読み上げにも不自然です。画像が何を示すかに戻します。
<img src="screen.png" alt="画像ブロックの設定画面で代替テキストを入力している状態">
失敗2: キャプションに書いたからaltを空にする
キャプションが画像の意味を十分に説明していて、画像がその説明を繰り返すだけなら、空の代替テキストが適切な場合もあります。ただし、操作説明のスクリーンショットのように、画像を見ないと手順が分からない場合は、代替テキストにも最低限の説明を入れます。
判断に迷ったら、「画像が読み込まれなくても本文の意味が通るか」を確認します。
失敗3: 外部画像を貼ったままにする
他のドキュメントや外部サイトから画像をコピーして貼った場合、WordPressがメディアライブラリに保存していないことがあります。Image blockの公式ドキュメントでは、コピーした画像について、ブロックツールバーに「Upload to Media Library」が出る場合は保存しておくと将来のリンク切れを防げると説明されています。
外部画像を使う場合は、権利、リンク切れ、表示速度の3点を確認します。自社で管理する記事なら、利用許諾を確認したうえでメディアライブラリに保存する運用のほうが管理しやすくなります。
画像形式はJPEG、PNG、WebP、AVIFを目的で使い分ける
画像形式は「新しい形式が常に正解」ではありません。写真、透過画像、スクリーンショット、対応ブラウザ、サーバーの画像処理ライブラリで選択が変わります。
WordPress 6.5以降ではAVIF画像をアップロードして使えるようになりました。Make WordPress CoreのWordPress 6.5 adds AVIF supportでは、AVIFはJPEGより小さくできる場合があり、利用にはホスティング環境のAVIF対応も関係すると説明されています。
実務での目安は次の通りです。
- JPEG: 写真に向く。互換性を優先しやすい
- PNG: 透過や文字の多いスクリーンショットに使いやすいが、容量が大きくなりやすい
- WebP: 写真にも図にも使いやすい現代的な形式
- AVIF: 容量削減を狙えるが、サーバー側の対応確認が必要
AVIFを使うなら、管理画面の「ツール」からサイトヘルスを開き、メディア処理の対応形式を確認します。対応していないサーバーでは、サムネイル生成や編集で問題が出ることがあります。
実務で使う確認チェックリスト
公開前に、画像ごとに次の点を確認します。
- 公開してはいけない情報が写っていない
- ファイル名に内部情報がない
- 画像サイズと容量が用途に対して大きすぎない
- 代替テキストが画像の役割を説明している
- キャプションが必要な画像には読者向けの補足がある
- 装飾画像は本文の意味を邪魔しない扱いになっている
- APIや自動化で更新する場合、認証情報をコードやログに残していない
- AVIFなど新しい形式は、サーバーと閲覧環境の対応を確認している
WordPressの画像管理で次に見るべき分岐点は、自動化です。記事数や画像数が増えると、管理画面で1枚ずつ確認するだけでは追いつきません。まずはメディアライブラリで安全な入力ルールを作り、その後でREST APIやWP-CLIによる一括確認へ進むと、運用を壊さずに整えられます。