WordPress Core チームが開発している機能プラグイン「Presence API」について、2026年10月2日に make.wordpress.org/core で「What’s new」の投稿が公開されました。現在のバージョンは0.14.0で、WordPress 7.0以上とPHP 7.4以上が必要です。管理画面で「誰がオンラインか」「誰がどの投稿を編集しているか」を見えるようにする仕組みで、将来のコア統合を目指して開発が続いています。この記事では、4月以降の変更点のうち、テーマ・プラグインを作る開発者に関係するものを整理します。
ニュースの概要
Presence APIは、2026年4月27日の告知投稿で紹介された実験的な機能プラグインです。当初の説明では、ログイン中のユーザー、開いている管理画面、編集中の投稿を可視化するもので、データは既存のHeartbeat APIを通じてやり取りされ、一時データの有効期間（TTL）は60秒とされていました。
10月2日の「What’s new」では、そこから半年弱の間に入った変更がまとめられています。記録の既定がオンであること、投稿ロックの保存先の変更、すべての投稿タイプへの対応、閲覧権限の新設、マルチサイトでの集計、AIエージェントの表示、そして開発者向けの新しい関数が主な内容です。公式の投稿では、議論はWordPress Slackの #feature-presence-api チャンネル、不具合報告はGitHub Issuesで受け付けるとされています。
なお、Presence APIは現時点では機能プラグインで、WordPress本体にはまだ入っていません。本文で「できるようになった」と書く内容は、プラグインの0.14.0時点の話です。
何が変わるのか
記録の既定はオン、止め方も用意されている
在席情報の記録は既定で有効です。サイト単位では「設定 > 一般」で、ネットワーク全体では「ネットワーク管理 > 設定」で無効にできます。どちらかが無効なら記録は止まります（ネットワーク側がオフなら、各サイトの設定にかかわらず全サイトで止まります）。ただし、記録を止めても投稿のロックは引き続き動きます。WP-CLIでは wp presence recording set off で止められ、ネットワーク全体に適用するときは --network を付けます。プライバシーポリシーの項目、データのエクスポーターとイレイサーにもプレゼンスデータが含まれるようになりました。
投稿ロックの保存先が変わった
投稿ロックは、postmetaではなくプレゼンス用のテーブルに保存されるようになりました。公式の説明では、永続オブジェクトキャッシュを使うサイトで、キャッシュ済みの投稿クエリが無効化されなくなります。4月の告知で触れられていた、高頻度の一時データを共有テーブルに置くとキャッシュが無効化される問題への対応と読めます（10月の投稿自体はこの問題に触れていません）。
対象が広がり、権限が分かれた
- 編集画面（エディター）を持つすべての投稿タイプで利用でき、サイトエディターで開いている内容も対象です。
- ページやカスタム投稿タイプだけを編集できるロールにも、プレゼンスが表示されます。
- オンラインのユーザーは管理バーに表示されますが、「どこにいるか」という居場所の情報は、新しい権限
view_presence_locationで制限されます。既定ではlist_usersに対応します。自分自身の居場所は常に見えます。
マルチサイトとAIエージェント
ネットワーク管理画面で、ネットワーク内の全サイトのオンラインユーザーを見られるようになりました。wp_is_large_network() の判定で大規模でないネットワークでは既定で有効で、フィルター wp_presence_network_aggregation_enabled で切り替えられます。各サイトが要約行を書き込むため、ネットワーク管理画面は全サイトのテーブルではなく1つのテーブルを読むだけで済みます。
バージョン0.13.0からは、REST APIやMCP経由で投稿を編集するAIエージェントの保存ごとに、その投稿のルームへプレゼンス行が書かれます。Heartbeatを送らないエージェントでも表示でき、行は既定で最後の保存から約75秒で期限切れになります。管理バーと「Editors」列に「Agent」バッジが出ます。エージェントかどうかの判定は、Agent Usersプラグインの wpai_is_agent_user() が読み込まれていればそこに問い合わせ、どのプラグインでもフィルター wp_presence_is_agent_user で判定できます。どちらもなければバッジは付きません。
開発者向けの変更
- 0.14.0で、RESTのプレゼンスエントリーから色の情報が削除されました。
wp_presence_get_user_color()は保存された色ではなく、ブロックエディターでそのユーザーIDに使われている色を返します。 - 新しい関数として
wp_presence_exchange()、wp_presence_leave()、wp_presence_is_available()が加わりました。 - 各行が個別の有効期限を持ち、読み取りはSQLでクライアントIDのプレフィックスによって絞り込まれます。
- SQLiteでも書き込みが動作します。
- 0.12.2で、各プレゼンス問い合わせは、テーブルが変わるまで1リクエストにつき1回だけ読まれるようになり、ユーザー一覧画面のHeartbeatでの読み取りは6回から2回に減りました。
- 管理バーのデバッガーはWP_DEBUGが有効なときだけ読み込まれ、WordPress.orgのパッケージには含まれません。
読者への影響
影響が大きいのは、次の3つの立場の人です。
- プラグイン・テーマの開発者: 投稿ロックを
_edit_lockのpostmetaで直接読み書きしているコードがある場合は注意が要ります。4月の告知には既存の_edit_lockの動作と共存するとありますが、10月の投稿は_edit_lockがどうなったかには触れておらず、現時点では確認できません。自分のコードがロックを直接扱っているなら、プラグインを入れた検証環境で挙動を確かめてください。 - 複数人で運用するサイトの管理者: 同じ投稿を誰かが編集中かどうかが一覧で分かる点は、編集の衝突を避けるのに役立ちます。一方、居場所は既定で
list_usersを持つユーザー（通常は管理者）にだけ見え、編集者には誰がオンラインかしか見えないため、運用ルールの確認が要ります。 - 個人情報の取り扱いを気にする運営者: 記録が既定でオンなので、利用者への説明（プライバシーポリシー）の更新が必要かどうかを検討する場面が出てきます。
プラグインを入れていないサイトには、現時点では何の変化もありません。コア統合の時期も、公式の投稿では示されていません。
確認すること
- 公式の投稿（出典1）を読み、自分のサイトが使うWordPressとPHPのバージョンが要件（WordPress 7.0以上、PHP 7.4以上）を満たすか確認する。
- 投稿ロックを扱うコードがあるなら、テスト環境でPresence APIプラグインを有効にして動作を確かめる。本番サイトで先に試さない。
- 記録を使わない方針なら、「設定 > 一般」の設定、またはWP-CLIの
wp presence recording set offを確認する。 - フィードバックがあれば、Slackの #feature-presence-api かGitHub Issuesに送る。
筆者の見解
私見では、今回いちばん実務に効くのは機能の数よりも、投稿ロックがpostmetaからプレゼンス用テーブルへ移り、記録をオフにしても動き続ける「ロックの土台」になった点です。4月の告知は既存の _edit_lock と共存するとしていましたが、10月の投稿は _edit_lock 側の扱いに触れていません。ロックを直接読むコードを持つ開発者は、キャッシュ面の利点と互換性の確認をセットで考える必要があると考えます。
見落としやすいのはAIエージェントの表示です。行は保存のたびに書かれて約75秒で期限切れになるため、保存せずに長く作業するエージェントは画面に出にくい設計だと読めます。また、居場所は既定で list_users を持つ人にだけ見えるので、管理者からは見えても編集者からは見えない非対称が生まれます。記録が既定でオンであることと合わせて、導入前に運営側で説明を用意しておくのが無難だと考えます。
出典（一次情報）
- Presence API: What’s new（Make WordPress Core、2026年10月2日）
- Presence API Feature Plugin（Make WordPress Core、2026年4月27日）
2026年10月12日時点の情報です。
コメント