カスタムフィールドの値が出てこないとき、詰まっている場所は 2 つあります。編集画面に入力欄が出てこない場合と、値は保存できているのに公開ページに出てこない場合です。この記事では、その切り分けから始めて、ブロックテーマで値を表示する 3 つの手段を「更新で消えないか」「引き渡した後に壊れにくいか」「ライセンス上、案件に持ち込めるか」の 3 軸で比べます。自分の案件ではどれを選ぶべきかを決められる状態を目指します。本文の仕様は 2026 年 9 月時点のものです（WordPress の最新版は 7.1.2）。
まず切り分ける — カスタムフィールドが表示されない 2 つの原因
「表示されない」には別の 2 つの状態が混ざっています。対処も別なので、最初にどちらなのかをはっきりさせてください。
編集画面にカスタムフィールド欄が見当たらない
ブロックエディターでは、カスタムフィールドの入力欄は初期状態で隠れています。WordPress 公式ドキュメントの Assign custom fields は、一度も使われていない場合は初期状態で非表示になると説明しています。表示させる手順は次の 4 ステップです。
- 画面右上のツールバーにある「オプション」ボタン（3 点のアイコン）を押す
- 「設定」（Preferences）を選ぶ
- 「一般」タブの「詳細」セクションにある「カスタムフィールド」をオンにする
- 「有効にして再読み込み」ボタンを押す
この操作ではページの再読み込みが起きるため、同ドキュメントは切り替える前に内容を保存しておくよう注意しています。切り替え後、入力欄はエディターの下部に出ます。
押さえておきたいのは、これはエディターの表示設定にすぎないことです。オンにしても公開ページの見た目は変わりません。クラシックエディターの「表示オプション」が見つからなかった場合も、ブロックエディターではこの「設定」パネル側に移っていると考えてください。
値は入っているのに、公開ページに出てこない
こちらは設定の問題ではなく、仕様どおりの挙動です。同じ公式ドキュメントは、各投稿のカスタムフィールドを公開ページに表示するにはテンプレートタグが必要だと、節を分けて説明しています。つまりカスタムフィールドは、保存しただけでは公開ページに出ません。出力する場所をこちらで用意する必要があります。
そしてその置き場所が、ブロックテーマとクラシックテーマで変わります。ブロックテーマはサイトのすべての部分をブロックで組み立て、テンプレートをサイトエディターで編集します。公式ドキュメントの Block themes は、クラシックテーマはサイトエディターでは動かないと明記しています。ブロックテーマとクラシックテーマで、カスタマイズの置き場所がどう変わるかは、別の記事で詳しく整理しています。「テンプレートファイルに PHP を 1 行足す」という対処が、そのままの形では使えないのはこのためです。以降は、この公開ページに出てこない側を扱います。
ブロックテーマでカスタムフィールドを表示する 3 つの手段
選択肢はおおまかに 3 つです。ここでは優劣を付けず、何を書く必要があるのかという前提だけを並べます。
手段 A — Block Bindings API（コアの機能だけで完結）
ブロックの属性と投稿メタの値を接続する、WordPress コアの仕組みです。Block Bindings API のリファレンスによれば、使えるのは WordPress 6.5 以降です。段落や見出しのブロックに「この投稿メタの値を表示する」と指定する形なので、ブロックを自作する必要がありません。書くのは投稿メタの登録とマークアップへの指定の 2 か所だけで、プラグインは要りません。
手段 B — 自作ブロックまたはショートコードで出力する
get_post_meta() などで値を取り出し、自分で出力する方法です。出し方は、動的ブロックを自作する、ショートコードを登録する、ブロックのバリエーションを作る、などいくつかあります。自由度はもっとも高く、値を整形する、条件によって出し分けるといった処理も書けます。その代わり、書く量とメンテナンスの対象が増えます。
手段 C — カスタムフィールド系プラグインの表示機能を使う
カスタムフィールドを管理するプラグインには、値を画面に出す機能が付いていることがあります（プラグインディレクトリの一覧）。コードを書かずに済む場合が多い一方、出力の形式はその製品固有のものになります。どれを選ぶかで前提が大きく変わるため、ここでは手段としての説明にとどめます。
どれを選ぶべきか — 3 つの判断軸で比べる
案件の条件によって答えは変わります。ひとつに決めつけず、3 つの軸で並べます。
| 判断軸 | A：Block Bindings API | B：自作ブロック／ショートコード | C：プラグインの表示機能 |
|---|---|---|---|
| 更新で消えるか | 消えない。コア機能とブロックのマークアップに残る | 置き場所しだい。テーマ直下ならテーマ更新で消え、プラグイン化すれば残る | そのプラグインを外すと出力も止まる |
| 引き渡し後に壊れにくいか | 指定を消すと表示も消える。入力欄は WordPress 標準のまま | 出力処理が画面から見えないため触られにくい | 管理画面が分かりやすい製品が多い。設定が増える分、変更の余地も増える |
| ライセンス上、持ち込めるか | コア機能なので追加のライセンスが発生しない | 自分で書いたコードなので制約がない | 製品ごとに異なる。持ち込む前に確認が必要 |
選び方の目安は次のとおりです。
- 値をそのまま文字として出したいだけなら A。 段落・見出し・画像・ボタンに差し込む用途なら、依存を増やさずに済みます。後述の対応表に収まるかどうかが分かれ目です
- 値を加工する、複数の値を組み合わせる、繰り返して出すなら B。 A の範囲を外れる要件は、早めに B へ寄せたほうが結果的に短く済みます
- 入力側の管理画面を作り込みたい、かつライセンス条件が案件に合うなら C。 将来そのプラグインを外す可能性も一緒に考えておくと安全です
長期運用の引き渡し案件では、表示は A、加工が必要な箇所だけ B、という組み合わせに落ち着くことが多い構成です。
Block Bindings API でカスタムフィールドを表示する最小の手順
手順は 2 つだけです。なお、ブロックの HTML を触らずにエディターの画面操作だけでバインディングを設定できるかどうかは、公式ドキュメントに記載を確認できませんでした。そのため本記事では、ブロックの HTML を直接編集する方法で説明します。
手順 1：投稿メタを登録する
register_meta() で投稿メタを登録します。プラグイン、またはテーマの functions.php に置いてください。
register_meta(
'post',
'my_custom_field',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
)
);show_in_rest は必須で、リファレンスも Block Bindings API から参照する条件として挙げています。特定の投稿タイプにだけ登録したい場合は register_post_meta() を使います。
手順 2：ブロックの属性に接続する
エディターでブロックを選び、オプションから「HTML として編集」に切り替えて、ブロックのコメントに metadata.bindings を書き足します。段落ブロックの content 属性に接続する例です。
<!-- wp:paragraph {
"metadata":{
"bindings":{
"content":{
"source":"core/post-meta",
"args":{"key":"my_custom_field"}
}
}
}
} -->
<p>フォールバックとして表示されるテキスト</p>
<!-- /wp:paragraph -->source に core/post-meta、args.key に手順 1 のキーを指定します。ブロックの中身に書いたテキストは、値が取得できなかったときに表示されます。テンプレートに置く場合は、サイトエディターで対象のテンプレート（投稿なら single）を開いて同じ操作をします。
Block Bindings API が使えないケースと、そのときの代替
A はどこにでも使えるわけではありません。先に制約を知っておくと、B へ切り替える判断が早くなります。
接続できるブロックと属性が決まっている
2026 年 9 月時点でコア標準で接続できるのは、次の範囲です（出典は前掲の Block Bindings API のリファレンス）。
| ブロック | 接続できる属性 |
|---|---|
core/image | id / url / title / alt / caption |
core/heading | content |
core/paragraph | content |
core/button | url / text / linkTarget / rel |
core/navigation-link | url |
core/navigation-submenu | url |
core/post-date | datetime |
リスト、テーブル、カバーの背景画像などは入っていません。この表にない場所へ値を出したい場合は、手段 B を検討してください。
一覧は WordPress 6.9 以降、block_bindings_supported_attributes フィルターで広げられますが、リファレンスは、このフィルターがパターンオーバーライドで使えるブロックと属性にも影響し、両機能が同じ設定を共有していると注意書きしています。パターンオーバーライドを併用しているサイトでは、片方のつもりで広げた設定がもう片方にも効きます。
投稿メタ側の 2 つの条件
core/post-meta を使う条件は 2 つです。投稿メタが show_in_rest => true で登録されていることと、キーの先頭がアンダースコアでないこと。リファレンスは _example_key のようなキーは保護されていて使用できないとしています。_ 始まりのキーで値を保存している既存サイトでは、A はそのままでは使えません。キーを作り直すか、手段 B に切り替えることになります。
知っておくと選択肢が広がる 2 点
- 値の加工は 6.7 以降のフィルターでできます。 WordPress 6.7 以降、
get_value_callbackが返す値をblock_bindings_source_valueフィルターで加工できます。日付の書式を変える程度の整形なら、B に移らずに済みます - 投稿メタ以外のソースが 6.9 で増えました。
core/post-data（date/modified/link）とcore/term-dataが、WordPress 6.9 以降のコア標準ソースとして追加されています。公開日やパーマリンクを出したいだけなら、カスタムフィールドを作らずに済む場合があります
カスタムフィールドを増やす前に、テーマ側で済む範囲を見直す
最後に、ひとつ手前の話を。「カスタムフィールドで持つべき値かどうか」は、作り始める前に立ち止まる価値があります。
見出しの大きさ、余白、色といった見た目に関する値は、カスタムフィールドではなく theme.json のプリセットで持つほうが、あとの運用が楽になります。プリセットの値はサイト全体で共有され、エディターの選択肢としても出るため、投稿ごとに入力してもらう必要がありません（グローバル設定とスタイル（theme.json））。ページごとに繰り返す構造も、パターンやテンプレートで持てます。カスタムフィールドに向いているのは、投稿ごとに実際に変わる内容のほうです。
この整理が効きやすいのは、テーマ側がプリセット駆動で設計されている場合です。たとえば shitate は、コアブロックだけで完結すること、theme.json のプリセットで文字サイズと余白を連動させることを設計方針にしたブロックテーマで、独自の CSS を書き足さなくても見た目が揃います。テーマがどこまで受け持つかによって、カスタムフィールドで持つべき値の範囲は変わります。使っているテーマの設定とプリセットを先に見てから、足す値を決めてください。
カスタムフィールドの「表示されない」は、編集画面の設定の話と、公開ページへの出力の話に分かれます。後者は、A・B・C のどれを選ぶかという設計の判断です。更新で消えないか、引き渡し後に壊れにくいか、ライセンスが案件に合うか。この 3 つを当てはめれば、迷う時間はかなり短くなります。
shitate は 100% GPL のブロックテーマで、WordPress 公式ディレクトリから無料で試せます。詳細は公式サイトをご覧ください。
