閉じる

技術ブログ

【WordPress】ACFは今も主流なのか？2026年のカスタムフィールド事情を総ざらい

2026.06.16

WordPress 実践シリーズ #06
ACFは今も主流なのか？
2026年のカスタムフィールド事情を総ざらい
「しばらく現場を離れていた数年で、何が変わったのか」──
強制フォーク事件とGutenberg台頭の両方を、事実ベースで解説する

「カスタムフィールドといえばACF（Advanced Custom Fields）」。
数年前まで、これはWordPress開発者にとって疑う余地のない常識でした。

ところが、しばらく現場を離れて戻ってくると、景色が変わっているかもしれません。
「ACFが公式リポジトリから消えてSCFという別名になった」という話を聞いたり、
「Gutenberg（ブロックエディタ）だけでカスタムフィールドを扱えるようになった」という記事を見かけたり──。

本当にACFはもう古いのか？　それとも依然として主流なのか？
この記事では、①ACFの現在地、②2024年に起きた強制フォーク事件、③Gutenbergはシェアを奪っているのか、④主要な代替プラグインを、一次情報に当たりながら徹底的に整理します。

目次

1. 結論 ── ACFは今も主流。ただし地図は書き換わった

先に結論からお伝えします。

2026年現在も、ACFはカスタムフィールドプラグインの事実上の標準（デファクトスタンダード）です。
有効インストール数は200万サイト超。コミュニティの規模、サードパーティ連携、チュートリアルの蓄積、いずれも他を圧倒しています。「迷ったらACF」は今も有効な判断です。

ただし、「しばらく現場を離れていた」方がまず押さえるべきは、この数年でACFを取り巻く環境に2つの大きな地殻変動があったという点です。

変化 いつ 何が起きたか
① 強制フォーク事件 2024年10月 ACFがWordPress公式リポジトリ上で「SCF」という別プラグインに置き換えられた
② Gutenberg側の進化 2024年〜（6.5以降） 「Block Bindings API」により、プラグイン無しでもカスタムフィールドをブロックに表示できるようになった

この2つを知らないまま「ACFを入れればいい」とだけ考えていると、「公式から入れたはずなのに名前が違う」「Gutenberg案件で実装方針を決められない」といった場面でつまずきます。順に見ていきましょう。

2. 事件①：WP Engine買収から「強制フォーク」まで（2024年10月）

まず、WordPress史上でも極めて異例の出来事から。これは技術の話というより政治・法務の話ですが、案件でACFを使う以上、避けて通れません。

2022年
ホスティング大手のWP EngineがACFを買収。以降、ACF PRO（有償版）を中心に開発・機能追加を継続。
2024年9月〜
WordPress共同創設者 Matt Mullenweg（Automattic）と WP Engine の間で、商標・コミュニティ貢献をめぐる法廷闘争に発展。
2024年10月1日
WP Engineが独自のプラグイン／テーマ更新インフラを稼働。
2024年10月3日
ACFチームが「今後は自社サイトから直接アップデートを配信する」と告知。
2024年10月12日
WordPress.orgがACFを「強制フォーク」。公式リポジトリの「ACFのURL」を、Automatticが作ったSecure Custom Fields（SCF）に差し替えた。

WordPress.org側の公式発表（2024年10月12日）によると、これはプラグインディレクトリのガイドライン18条を発動した措置で、「WP Engineの法的攻撃によって引き起こされた、稀で異例の状況」と説明されています。フォークの理由は「商業的なアップセル（有償誘導）の除去」と「セキュリティ問題の修正」の2点とされました。

ここが“浦島太郎ポイント”です。
「21年のWordPressの歴史で、開発者の同意なく、一方的かつ強制的にプラグインが取り上げられたことは一度もなかった」──ACFチームはこう声明を出しました。稼働中の人気プラグインが、本人の意思に反して公式リポジトリ上で別物に置き換えられたのは前代未聞の事態でした。

SCF（Secure Custom Fields）とは何者か

SCFは、Automatticが作ったACF（無料版）のフォークです。技術的には当時のACF無料版とほぼ同等で、フィールド定義などの基本機能はそのまま使えます。商業的なアップセル表示が取り除かれ、セキュリティ修正が入った点が主な違いです。

公式リポジトリの自動更新を使っていたサイトは、自動アップデートが有効なら、ACFからSCFへ自動的に移行しました（管理画面から手動で切り替えることも可能）。つまり「気づいたら名前がSCFになっていた」サイトが多数存在します。

3. ACF / SCF / WP Engine版、結局どれを使えばいいのか

事件の結果、2026年現在は「ACF系」として複数の選択肢が並立する、ややこしい状況になっています。整理します。

呼称 提供元 入手先 位置づけ
SCF（無料） Automattic / WordPress.org 公式リポジトリ（旧ACFのURL） 公式リポジトリから素直に入れると、現在はこれが入る。旧ACF無料版相当。
ACF（無料） WP Engine advancedcustomfields.com / WP Engine独自サーバ 本家。公式リポジトリからは外れ、自社配信に移行。
ACF PRO（有償） WP Engine advancedcustomfields.com（$49/年〜） Repeater・Flexible Content・ACF Blocks・Options Pageなど“本気の案件”向け機能。フォークの影響を受けず継続。
注意：WordPressのセキュリティチームは、本件の渦中で「セキュリティ問題が修正されるまではWP Engine版ACFを推奨しない」という趣旨の見解を出していました。一方でACF PRO（有償版）は依然として現役で、PRO限定機能（特にRepeaterやFlexible Content）を使う案件では選択肢がACF PRO一択になる場面も多いです。
→ 既存案件・新規案件で「どの系統を使うか」は、PRO機能の要否とアップデート経路（公式 or 自社配信）で判断する必要があります。

実務上の指針

  • 無料機能だけで足りる新規案件 → 公式リポジトリのSCFで素直に始めてよい。
  • Repeater / Flexible Content / ACF Blocks など PRO機能が必要 → WP EngineのACF PRO（公式サイトから購入・更新）。
  • 既存案件で“いつの間にかSCFになっていた” → 慌てて戻さない。挙動は基本同じ。PRO機能を使っていないなら実害はほぼない。フィールド定義の互換性も保たれている。

4. 事件②：Gutenberg「Block Bindings API」の登場

もう一つの大きな変化が、WordPress本体（Gutenberg）側の進化です。この数年の間に、「プラグイン無しでもカスタムフィールドをブロックに表示できる」仕組みが標準搭載されました。それが Block Bindings API です。

バージョン 時期 Block Bindings の進化
WordPress 6.5 2024年3月 Block Bindings API 導入（実験的）。ブロック属性を外部データに「バインド」できる基盤。
WordPress 6.7 2024年 編集画面のUIから、ブロック属性とカスタムフィールドを直接ひも付け可能に。型に合うフィールドだけが候補に出る。
WordPress 6.8 2025年 実務投入に耐える水準まで成熟。カスタムテーマ・動的サイトで実用段階に。
WordPress 6.9 （以降） block_bindings_supported_attributes フィルタで、対応ブロック・属性を拡張可能に。

仕組み：register_meta + bindings

従来は、カスタムフィールドの値を表示するのにテンプレートでPHPを書く（get_post_meta() して echo する）必要がありました。Block Bindings APIでは、メタを登録し、ブロックのマークアップに「バインド」を書くだけで、レンダリング時にWordPressが値を差し込みます。

// 1) カスタムフィールド（post meta）を登録する
// show_in_rest が必須。キーの先頭にアンダースコアは不可（保護キー扱いになる）
register_meta(
‘post’,
‘my_custom_field’,
array(
‘show_in_rest’ => true,
‘single’ => true,
‘type’ => ‘string’,
)
);
<!– 2) ブロックのマークアップ側で「バインド」する（テンプレPHP不要） –>
<!– wp:paragraph {
“metadata”:{
“bindings”:{
“content”:{
“source”:“core/post-meta”,
“args”:{“key”:“my_custom_field”}
}
}
}
} –>
ただし現状の対応範囲は限定的です。標準でバインディングに対応しているのは、執筆時点で次の主要7ブロックに限られます：
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）
さらに、ブロック属性の型と一致するフィールドだけがUIの候補に出ます（string型属性にはstring型フィールド、など）。

5. 本題：Gutenbergはカスタムフィールドのシェアを奪っているのか

ここが多くの方の一番知りたい論点でしょう。Block Bindings APIの登場で「もうACFは要らないのでは？」という声もあります。結論は「奪っていない。少なくとも“まだ”。両者は競合というより役割分担」です。理由を、奪えている部分と奪えていない部分に分けて整理します。

Gutenbergが代替できる領域
  • 「単純なテキスト1つをブロックに出す」程度の軽量な動的表示
  • プラグインを増やしたくない小規模・ミニマル志向のサイト
  • テーマをブロックテーマ（FSE）で作っていて、テンプレPHPを書かずに完結させたいケース
  • フロントに余計なマークアップを足したくない（標準ブロックに値が乗るだけ）
Gutenbergでは（まだ）厳しい領域
  • Repeater / Flexible Contentのような繰り返し・可変構造のフィールド群
  • 対応7ブロック以外への表示（フィルタ拡張や独自実装が必要）
  • 複雑な入力UI・条件付き表示（フィールドの出し分けルールなど）
  • 非ブロックテーマ（クラシックテーマ）の案件
  • 「編集者に迷わせない、作り込まれた管理画面」を提供したい受託案件

開発者コミュニティの“温度感”

2026年時点の各種比較・実務記事を読むと、論調はおおむね次の通りです。

Q. Gutenbergが未来で、ACFはレガシーなのか？
A. 「Gutenbergが未来、ACFはレガシー」と言い切る人もいれば、「本番案件にはGutenbergはまだ未成熟」と考える人もいる。実態は“中間”で、案件の性質によって使い分けるのが多数派。大多数の実務案件では、開発者は今もACFを選んでいる──懐古趣味ではなく、具体的なメリット（後述）があるから、というのが共通見解です。
重要なのは、ACFとGutenbergは“どちらか”ではないということ。ACF自体がBlock Bindings APIに対応しており、「ACFのフィールドを、PHPを書かずにコアブロックへバインドして表示する」使い方ができます（WordPress 6.5以降＋フィールドの「エディタUIで値へのアクセスを許可」設定が必要）。さらにACF Blocksを使えば、PHPの知識でカスタムブロックを作れます。「ネイティブのBlock Bindings」と「ACF」は補完関係と捉えるのが正確です。

6. ACF以外の主要プラグイン比較（Meta Box / Pods / SCF ほか）

「ACF以外に便利なものはあるか」という問いにもお答えします。2026年に名前が挙がる主要プレイヤーは以下です。ACFのPRO課金が年々上がっていることもあり、代替を探す動きは確実に増えています。

プラグイン 無料版 有償 強み 向いている案件
ACF / SCF あり PRO $49/年〜 最大のコミュニティ・連携・情報量。デファクト標準 迷ったらこれ。受託全般
Meta Box あり Core Bundle $49/年〜 パフォーマンス重視。カスタムテーブル保存でDB肥大化・クエリ遅延を抑制 大規模・高負荷・性能重視
Pods 完全無料 不要（任意アドオン） カスタムフィールド＋投稿タイプ＋タクソノミー＋リレーションを無料一式で。独自テーブル(ACT)も 予算なし・全部入りが欲しい
Toolset なし €69/年〜 ビジュアルクエリビルダー、動的表示用の34ブロックを同梱 ノーコードで動的レイアウト
JetEngine なし $43/年〜 Elementorとの密連携。リスティングビルダーで動的テンプレ Elementor中心・ディレクトリ系
Carbon Fields 無料(OSS) — 軽量・コードベースでフィールド定義。余計な肥大なし 開発者主導・最小構成
CMB2 無料(OSS) — 老舗のコードベース。メタボックスをPHPで定義 開発者主導・GUI不要
ざっくり指針：
・とにかく標準で安心したい → ACF / SCF
・パフォーマンスを最優先（大規模・大量データ） → Meta Box（カスタムテーブル）
・予算ゼロで投稿タイプもリレーションも全部 → Pods
・Elementor案件 → JetEngine
・軽さ・コード管理重視の開発者 → Carbon Fields / CMB2

7. 使い勝手 ── ブロックを自作する vs ACFで済ませる

「使い勝手はどうなのか」という観点で、ネイティブのブロック開発とACFを正直に比較します。

観点 ネイティブのブロック自作（JS/React） ACF（＋必要ならACF Blocks）
学習コスト 高い。React/JSXとビルド環境の習得が前提 低い。慣れたPHPで完結。GUIでフィールド定義
開発スピード 遅くなりがち（ボイラープレートが多い） 速い。フィールドを並べてテンプレで出すだけ
出力HTML ブロックの仕様に従う テンプレで完全制御。余計なマークアップが出ない＝軽い
編集体験 ブロックエディタにネイティブ統合（プレビュー◎） メタボックス／ACF Blocksで提供。作り込みやすい
複雑な構造 自前実装の負担大 Repeater / Flexible Content（PRO）で容易
要点は「ACFの価値はシンプルさ・速さ・慣れ」。Gutenbergブロックを一から作るのはJSの学習と工数が要りますが、ACFなら使い慣れたPHPで直感的に組め、生成されるHTMLも最小限でページが軽い、という実利があります。受託のように工数と編集者の使いやすさが効く現場ほど、ACFの優位は揺らいでいません。

8. まとめ ── 2026年、どう選ぶべきか

要点まとめ（Q&A）

Q1. ACFは今も主流か？
→ はい、依然として主流（200万サイト超）。デファクト標準は健在です。

Q2. 何が変わったか？
→ ①2024年10月、政治・法務の事情で公式リポジトリ上のACFがSCF（Secure Custom Fields）に強制フォーク。「公式から入れると名前が違う」状態に。PRO機能が要るならWP EngineのACF PROを使う。
→ ②Gutenberg側にBlock Bindings APIが入り、簡単な表示ならプラグイン無しでも可能に。

Q3. Gutenbergにシェアを奪われている？
→ 奪われてはいない。役割分担。単純表示はネイティブで十分だが、繰り返し構造・複雑UI・受託の作り込みはACFが依然優位。両者は補完関係。

Q4. 他に便利な選択肢は？
→ 性能重視ならMeta Box、無料全部入りならPods、Elementor案件ならJetEngine、軽量志向ならCarbon Fields。

「ACFはオワコンか？」という問いには、はっきり「No」と答えられます。ただし“ACFを取り巻く地図”は確実に書き換わった──強制フォークでブランドが分裂し、Gutenbergが下から実用機能を追い上げている。この2つの文脈を踏まえたうえで、案件ごとに「ネイティブで足りるか／ACF（PRO）が要るか／代替が適すか」を見極めるのが、2026年の正しいスタンスです。

参考リンク

※本記事はWordPress.org公式発表（2024年10月「Secure Custom Fields」）、開発者向けハンドブック（Block Bindings API）、および各種比較記事を基に作成しています。バージョンや配信状況は変動するため、導入前に最新情報をご確認ください。

Seeds Brains
2026-06-16 作成