WordPressのカスタムフィールド入門｜記事データを整理して再利用しやすくする基本

2026年5月15日

WordPressのカスタムフィールド入門｜記事データを整理して再利用しやすくする基本

記事ごとに「価格」「開催日」「外部リンク」「商品コード」のような情報を持たせたいなら、本文に直接書くよりカスタムフィールドで分けたほうが管理しやすくなります。あとで一覧表示したい項目、検索や並び替えに使いたい項目は、最初から本文と分離しておくのが基本です。

WordPressのカスタムフィールドは、投稿にひもづく追加データです。単なるメモではなく、テンプレート表示、REST API、ブロック連携まで視野に入る仕組みなので、使い方を最初に整理しておくと後で効きます。

できること: 投稿本文とは別に、価格・日付・URL・担当者名などを保存できる
向いている場面: 商品紹介、イベント告知、求人情報、店舗情報、比較記事のスペック整理
最初の結論: まずは標準のカスタムフィールドで試し、継続運用する項目はキー名と型を先に決める
さらに広げる方法: コードで register_post_meta() を使うか、必要なら専用プラグインを使う

ここがポイント: カスタムフィールドは「後から使い回したい情報」を本文から切り出すための箱です。本文の飾りではなく、データ設計として考えると失敗しにくくなります。

カスタムフィールドで何を分けるべきか

最初に迷いやすいのは、「何でもカスタムフィールドに入れるべきか」という点です。結論から言うと、本文に自然に書くべき情報と、項目として管理すべき情報は分けたほうが運用しやすくなります。

本文に置くもの

文章として読ませる説明
見出しごとに構成が変わる内容
記事ごとに形が揃わない補足

カスタムフィールドに置くもの

価格
発売日や開催日
会社名、担当者名、監修者名
外部リンクURL
SKU、型番、キャンペーンコード
評価点や在庫状態のような定型値

たとえば商品レビュー記事で「価格」を本文だけに書くと、一覧ページで価格順に並べたり、カードUIに価格だけ再利用したりしづらくなります。逆に、感想や使い勝手までカスタムフィールドに押し込むと、編集画面が窮屈になります。

まずは標準機能で試す手順

WordPress公式ドキュメントでは、ブロックエディタのカスタムフィールド欄は初期状態で非表示のことがあります。2026年4月時点では、投稿編集画面の右上メニューから Preferences を開き、Advanced 内の Custom fields を有効にして再読み込みする流れが案内されています。

追加の流れ

投稿編集画面を開く
Custom fields を表示する
Name にキー名、Value に値を入力する
保存して投稿にひも付ける

例

入力例:

event_date : 2026-05-20
event_place : 東京国際フォーラム
event_price : 3500

この形にしておくと、本文にはイベントの紹介を書きつつ、日付や会場だけを一覧やカード表示に流用できます。

実務で崩れにくいキー名の決め方

カスタムフィールドは使い始めより、増えてからの整理が難しくなります。先に命名ルールを決めておくと、後で困りません。

避けたい例

Price
price1
データ1
link

後から見ると、何の値か判断しにくいからです。特に複数人で運用するサイトでは、キー名の揺れがそのままデータの散らかりになります。

コードで型を決める基本

標準のカスタムフィールドは手軽ですが、継続利用する項目はコードで登録したほうが安定します。register_post_meta() を使うと、どの投稿タイプに対して、どんな型で、REST APIに出すかを明示できます。

以下は通常の投稿 post に価格フィールドを登録する最小例です。

add_action( 'init', function () {
    register_post_meta(
        'post',
        'product_price',
        array(
            'type'              => 'integer',
            'single'            => true,
            'show_in_rest'      => true,
            'sanitize_callback' => 'absint',
            'default'           => 0,
        )
    );
} );

この設定で押さえたいのは次の点です。

type: 値の種類を決める
single: 1投稿につき1つの値かどうかを決める
show_in_rest: REST APIやブロック連携で扱いやすくする
sanitize_callback: 保存前の値を整える
default: 未入力時の扱いを揃える

なぜ型指定が重要か

WordPress公式の get_post_meta() ドキュメントでは、スカラー値は文字列として返る点が案内されています。つまり、数字を入れても取得時には文字列として受ける場面があります。

そのため、表示時は「保存の型」と「出力時の整形」を分けて考えると安全です。

表示側の最小サンプル

投稿テンプレートやテーマ側で値を出す例です。

<?php
$price = get_post_meta( get_the_ID(), 'product_price', true );
$sku   = get_post_meta( get_the_ID(), 'product_sku', true );

if ( $price !== '' || $sku !== '' ) :
?>
    <ul class="product-meta">
        <?php if ( $price !== '' ) : ?>
            <li>価格: <?php echo esc_html( number_format_i18n( (int) $price ) ); ?>円</li>
        <?php endif; ?>

        <?php if ( $sku !== '' ) : ?>
            <li>SKU: <?php echo esc_html( $sku ); ?></li>
        <?php endif; ?>
    </ul>
<?php endif; ?>

入力例:

product_price : 2980
product_sku : WB-2401

出力例:

価格: 2,980円
SKU: WB-2401

ここでは esc_html() で表示をエスケープし、価格だけ整数に変換しています。URLなら esc_url()、HTML属性なら esc_attr() のように、出力先に合わせるのが基本です。

どんな記事データに向いているか

カスタムフィールドは、本文の補助ではなく「表示の素材」と考えると使いどころが見えます。

商品紹介

価格
型番
購入先URL
ブランド名

イベント記事

開催日
会場
申込URL
定員

店舗・施設ページ

住所
営業時間
電話番号
地図URL

比較記事やレビュー

評価点
対応OS
料金プラン
無料トライアル有無

これらは本文の中にも書けますが、一覧、カード、絞り込み、別テンプレートで再利用したいなら、カスタムフィールドに分けておく意味があります。

ブロックエディタと連携したいとき

WordPressの Block Bindings API は、WordPress 6.5以降で使える仕組みです。登録済みの投稿メタをブロック属性に結びつけられるので、固定パターンの表示をブロックベースで組みやすくなります。

たとえば、段落ブロックの内容を product_summary というメタに結びつけるイメージです。

<!-- wp:paragraph {
  "metadata": {
    "bindings": {
      "content": {
        "source": "core/post-meta",
        "args": {
          "key": "product_summary"
        }
      }
    }
  }
} -->
<p></p>
<!-- /wp:paragraph -->

ただし、公式ハンドブックでは次の条件が示されています。

Block Bindings APIは WordPress 6.5 以上が前提
対象メタは show_in_rest => true で登録する
先頭が _ の保護されたメタキーは使えない

「本文とデータをきっちり分けたいが、表示はブロックで組みたい」という場合に相性が良い方法です。

よくある失敗と対処

ここは初心者がつまずきやすい部分です。

1. キー名が毎回ぶれる

price、Price、product_price が混在すると、取得コードも一覧表示も崩れます。

対処:

先に命名規則を決める
用途ごとに接頭辞を揃える
一度決めたキーは途中で変えない

2. 本文とカスタムフィールドに同じ情報を書く

価格や日付を本文にも固定文で書くと、更新漏れが起きます。

対処:

正とする場所を1か所に決める
本文では自動表示の値を参照する構成に寄せる

3. 先頭を `_` にしたキーを普通の編集用として使う

WordPress公式のメタデータ管理ドキュメントでは、_ で始まる meta_key は編集画面のカスタムフィールド一覧や the_meta() で表示されないと説明されています。内部用途や保護された値として扱われやすいので、通常の運用項目には向きません。

対処:

編集者が触る項目は _ なしで命名する
内部管理用だけ _internal_flag のように分ける

4. カスタム投稿タイプで保存や取得がうまくいかない

REST APIやブロックエディタ連携を使う場合、公式ドキュメントでは対象のカスタム投稿タイプに custom-fields サポートが必要です。

対処:

register_post_type(
    'book',
    array(
        'label'    => 'Books',
        'public'   => true,
        'supports' => array( 'title', 'editor', 'thumbnail', 'custom-fields' ),
    )
);

5. 数字や真偽値のつもりで文字列のまま扱う

get_post_meta() は取得時の扱いで迷いやすい関数です。数字比較や条件分岐の前に、必要な型へ変換したほうが安全です。

対処:

数値は (int) や (float) で変換する
URLは esc_url() で出す
真偽値は保存時の設計を先に決める

専用プラグインを使うべき場面

標準機能だけでも始められますが、運用項目が増えると入力UIが物足りなくなります。そんなときは、フィールド定義用のプラグインを使う判断が現実的です。

WordPress.org 公式の Secure Custom Fields では、投稿や固定ページだけでなく、ユーザー、タクソノミー、メディア、オプション画面などにもフィールドを追加できます。

標準機能で足りるケース

テキストやURLを数個だけ持たせたい
まずは仕組みを理解したい
コードで管理したい

専用プラグインが向くケース

日付、画像、選択肢、繰り返し項目などを使いたい
編集者に入力しやすいUIを渡したい
投稿タイプごとに入力項目を切り替えたい

重要なのは、プラグインを入れること自体ではなく、どのデータを構造化するかを先に決めることです。設計が曖昧なままフィールドだけ増やすと、管理画面がすぐ散らかります。

最初に作っておくと楽な設計メモ

運用前に、最低でも次の4点はメモしておくと後で助かります。

どの投稿タイプで使うか
1件につき1値か、複数値か
文字列、数値、真偽値、配列のどれか
どこで表示するか: 記事本文、一覧、REST API、ブロック、外部連携

例:

event_date: 文字列ではなく日付として扱いたい
event_price: 数値として保存し、一覧でも使いたい
event_entry_url: URLとして保存し、CTAボタンに出したい
event_status: open / closed のように値を限定したい

ここまで決めてから作ると、後から「一覧に出したいのに本文にしかない」「キー名がバラバラで取得できない」といったやり直しを減らせます。

まとめ

WordPressのカスタムフィールドは、投稿に追加情報を付ける機能というだけではありません。記事データを本文から切り出し、一覧、テンプレート、REST API、ブロック表示に再利用しやすくするための土台です。

最初は次の順で考えると進めやすいです。

本文に置く情報と、項目として管理する情報を分ける
キー名の命名規則を決める
継続利用する項目は register_post_meta() で型を決める
入力項目が増えたら専用プラグインを検討する

次に見るべきポイントは、自分のサイトで「一覧に出したい情報」が何かです。その1項目が見えれば、カスタムフィールド設計はかなり具体的になります。

参照リンク

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

WordPressのカスタムフィールド入門｜記事データを整理して再利用しやすくする基本

WordPressのカスタムフィールド入門｜記事データを整理して再利用しやすくする基本

カスタムフィールドで何を分けるべきか

本文に置くもの

カスタムフィールドに置くもの

まずは標準機能で試す手順

追加の流れ

例

実務で崩れにくいキー名の決め方

おすすめのルール

避けたい例

コードで型を決める基本

なぜ型指定が重要か

表示側の最小サンプル

どんな記事データに向いているか

商品紹介

イベント記事

店舗・施設ページ

比較記事やレビュー

ブロックエディタと連携したいとき

よくある失敗と対処

1. キー名が毎回ぶれる

2. 本文とカスタムフィールドに同じ情報を書く

3. 先頭を _ にしたキーを普通の編集用として使う

4. カスタム投稿タイプで保存や取得がうまくいかない

5. 数字や真偽値のつもりで文字列のまま扱う

専用プラグインを使うべき場面

標準機能で足りるケース

専用プラグインが向くケース

最初に作っておくと楽な設計メモ

まとめ

参照リンク

3. 先頭を `_` にしたキーを普通の編集用として使う