Block Bindings API＝ブロック属性へ外部データを結び付ける標準機構

こんにちは、投稿者のKuboです。
WordPress 6.5以降で利用できるBlock Bindings API＝ブロック属性へ外部データ（例：ポストメタ）を結び付ける標準機構を、Advanced Custom Fields（ACF）と組み合わせて安全に運用する手順を示します。結論はシンプルで、既存のコアブロックをそのまま動的化しつつ、許可リスト（ホワイトリスト）／読み取り専用／ロールバック容易の3点を徹底することです。

何ができるのか（Block Bindings APIの要点）

結論先出し：カスタムブロック不要で既存ブロックを動的化

Block Bindings APIは、段落や見出しなど既存のコアブロックの属性（例：content、url）に外部ソースの値を結び付けて、フロント出力に反映します。PHPの独自レンダラーや複雑なカスタムブロックを用意せず、UIはそのまま／コードは最小で運用できます。

採用前提と制約

要点：WP 6.5+、コード指定中心、読み取り専用で堅実に

要件：WordPress 6.5以上。ブロックテーマ環境が望ましい。
指定方法：ブロックのmetadata.bindingsに「ソース」と「引数（例：meta_key）」を記述。
データソース：ポストメタ（ACF含む）や関数結果などを独自ソースとして登録可能。
制約：現状は読み取り専用の運用が安全。UIによる完全編集は段階的整備中。

今日すぐやる実装手順

要点：ソース登録 → バインド指定 → ACF準備 → 安全設定

小規模プラグインを作成（例：kb-bindings）。無効化＝即ロールバックできる形に。

独自データソースを登録（ACFのメタ値を返す）。

add_action( 'init', function () { if ( ! function_exists( 'register_block_bindings_source' ) ) { return; } register_block_bindings_source( 'kb/meta', array( 'label' => __( 'Post Meta (ACF)', 'kb' ), 'uses_context' => array( 'postId' ), 'get_value_callback' => function( $source_attrs, $block ) { $allowed = array( 'price', 'stock_status', 'owner', 'contact_url' ); // 許可リスト $key = isset( $source_attrs['key'] ) ? sanitize_key( $source_attrs['key'] ) : ''; if ( ! in_array( $key, $allowed, true ) ) { return ''; } $post_id = $block->context['postId'] ?? get_the_ID(); if ( ! $post_id ) { return ''; } $value = get_post_meta( $post_id, $key, true ); return is_scalar( $value ) ? (string) $value : ''; }, ) ); } );

ブロックにバインド指定（例：段落のcontentに価格を結び付け）。

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

ACF側の準備：価格（price）、在庫（stock_status）、担当者（owner）などを投稿に割り当て。meta_keyは「フィールド名」を使います。
安全設定：許可リスト／読み取り専用／返値の文字列化／本番キャッシュ整合の確認。

実例：ACFの値を見出し・段落・ボタンに連携

要点：編集者はACFを更新、表示は自動反映

<!-- 見出し：担当者名 -->
<!-- wp:heading {"metadata":{"bindings":{"content":{"source":"kb/meta","args":{"key":"owner"}}}}} -->
<h2></h2>
<!-- /wp:heading -->

<!-- 段落：価格 -->
<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"kb/meta","args":{"key":"price"}}}}} -->
<p></p>
<!-- /wp:paragraph -->

<!-- ボタン：URLをメタで差し替え -->
<!-- wp:button {"metadata":{"bindings":{"url":{"source":"kb/meta","args":{"key":"contact_url"}}}}} -->
<div class="wp-block-button"><a class="wp-block-button__link">在庫のお問い合わせ</a></div>
<!-- /wp:button -->

移行時のチェックポイント

要点：postIdコンテキスト／キャッシュ／キーの一致

postIdコンテキスト：テンプレートやループによってはpostIdが渡らない場合があるため確認。
キャッシュ整合：静的化・オブジェクトキャッシュ併用時は反映遅延の切り分けを実施。
ACFキー：値の取得はフィールド名（meta_key）。_フィールド名はフィールドキー格納用で別物。

長期運用と安全設計（再発防止）

要点：最小権限・最小構成・検知速度の確保

許可リスト管理：参照可能なmeta_keyを配列で固定し、運用変更はPRで審査。
読み取り専用：値の編集はACF画面に限定。ブロック側の書き込み機能は入れない。
ロールバック容易：プラグイン化＋Git管理。障害時は無効化で影響を局所化。
テストと監視：ステージングE2E・本番ログ監視・キャッシュの整合チェックを定例化。

参考リンク

Block Editor Handbook：Bindings（仕様と例）
Make/Core：Block Bindings APIの紹介
Developer Resources：Interactivity API（将来拡張）
ACFドキュメント：meta_keyと保存仕様

よくある質問

Q1：カスタムブロックを作るより何が得ですか？

既存のコアブロックを再利用できるため、作成・保守範囲が小さく、編集者の学習コストも抑えられます。

Q2：ACFのどのキーを使えばいいですか？

フィールド名（meta_key）を指定します。_フィールド名はフィールドキー格納用で、値そのものではありません。

Q3：プレビューは可能ですか？

構成次第ですが、現状はコード指定が堅実です。要件によってはACF Blocksや専用ブロックを併用します。

Q4：部分更新や双方向UIは？

Interactivity APIと併用すると、リロードなしの表示更新などを段階的に付与できます。

目次