フックは、WordPressの決まった場面に自分の処理を差し込む仕組みです。
独自プラグインや子テーマに登録すれば、親テーマの更新で追加コードが消えるのを避けられます。
ただし、種類が2,000以上あります。
全部覚える必要はありません。
実際に使うのは20個ほどで、大事なのは「どの順番で走るか」です。
この記事では、実行される順番と、場面別によく使うものをまとめました。
アクションフックとフィルターフックの違い
先にここを押さえておくと、迷いません。
| アクションフック | フィルターフック | |
|---|---|---|
| 役割 | その場面で処理を実行する | 値を受け取って、書き換えて返す |
| 登録 | add_action() | add_filter() |
| 戻り値 | 要らない | 必ず返す。返さないと値が消える |
| 例 | 読み込みが終わったらCSSを足す | 記事の本文の末尾に一文を足す |
「何かをする」ならアクション、「何かを変える」ならフィルターです。
// アクション:処理を走らせるだけ。返さない
add_action( 'wp_enqueue_scripts', function () {
wp_enqueue_style( 'my-style', get_stylesheet_uri() );
} );
// フィルター:受け取って、変えて、必ず返す
add_filter( 'the_content', function ( $content ) {
if ( is_admin() || ! is_singular( 'post' ) || ! in_the_loop() || ! is_main_query() ) return $content;
return $content . '<p>最後まで読んでいただきありがとうございました。</p>';
} );フィルターで return を忘れると、本文がまるごと消えます。
真っ白になったら、まずここを疑ってください。
実行される順番
順番を外すと、動かない・エラーになる、のどちらかです。
代表的なものを、走る順に並べます。
| 順 | フック | この時点でできること |
|---|---|---|
| 1 | muplugins_loaded | 必須プラグインだけ読み込み済み。この時点までに読み込まれたAPIのみ使える |
| 2 | plugins_loaded | プラグインが揃う。テーマはまだ |
| 3 | after_setup_theme | テーマの機能を宣言する場所(アイキャッチ対応など) |
| 4 | init | いちばん使う。投稿タイプ・タクソノミーの登録 |
| 5 | wp_loaded | 全部の読み込みが終わった直後 |
| 6 | template_redirect | どのテンプレートを使うか決まる直前。リダイレクトはここ |
| 7 | wp_enqueue_scripts | CSSとJSを読み込む場所。条件分岐が使える |
| 8 | wp_head | <head> の中に出力する |
| 9 | wp_body_open | <body> の直後。計測タグはここ |
| 10 | wp_footer | ページの末尾。フッター出力(JSはenqueueで依存関係を指定) |
用途に対応するフックを選び、メインクエリに依存する条件分岐をinitで判定しないでください。
ただし init は管理画面でも Ajax でも走ります。
次の例は管理画面のリクエストを除外します。is_admin()がfalseでもREST APIやCLIなどから実行される場合があるため、通常の公開画面だけで処理する条件とは区別してください。表示するページに応じた処理には、メインクエリの確定後に使えるフックを選びます。
add_action( 'init', function () {
if ( is_admin() ) {
return; // 管理画面では何もしない
}
// ここにフロント向けの処理
} );場面別によく使うフック
CSSとJSを足す
| フック | 使いどころ |
|---|---|
wp_enqueue_scripts | フロント。名前はscriptsだがCSSもここ |
admin_enqueue_scripts | 管理画面 |
enqueue_block_editor_assets | ブロックエディタの中だけ |
login_enqueue_scripts | ログイン画面 |
enqueue_block_editor_assetsはツールバーやサイドバーなどの編集UI用です。本文のiframe内へブロック用のCSS・JSを読み込む場合は、enqueue_block_assetsやblock.jsonの設定を使います。対象の違いはWordPress公式のエディター資産読込ガイドを参照してください。
wp_head に直接 <style> を書くより、wp_enqueue_scripts を使ってください。
読み込み順とキャッシュをWordPressが面倒を見てくれます。
記事の保存に合わせて動かす
| フック | いつ走るか |
|---|---|
save_post | 投稿の保存時。自動保存とリビジョンでも走るので除外が要る |
save_post_{投稿タイプ} | その投稿タイプだけ。こちらのほうが安全 |
transition_post_status | 状態の遷移処理時(同じ状態での更新でも発火) |
publish_post | 公開投稿の保存時(公開済み投稿の更新でも発火) |
before_delete_post | 完全に削除される直前 |
save_post は、そのまま書くと保存のたびに何度も走ります。
add_action( 'save_post_post', function ( $post_id, $post, $update ) {
// 自動保存は親の下書きIDで保存される場合もある
if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
return;
}
// 自動保存リビジョンと通常のリビジョンも除外する
if ( wp_is_post_autosave( $post_id ) || wp_is_post_revision( $post_id ) ) {
return;
}
// 権限の確認も入れる
if ( ! current_user_can( 'edit_post', $post_id ) ) {
return;
}
// ここに処理
}, 10, 3 );管理画面をいじる
| フック | 使いどころ |
|---|---|
admin_menu | メニューの追加・削除 |
admin_init | 管理画面の初期化。設定の登録 |
admin_notices | 管理画面に通知を出す |
add_meta_boxes | 編集画面に入力欄を足す |
admin_bar_menu | 上部のツールバーをいじる |
リダイレクトと表示の分岐
| フック | 使いどころ |
|---|---|
template_redirect | 条件を見て別のURLへ飛ばす。出力前なので安全 |
pre_get_posts | 表示する記事の絞り込みを変える。フィルターではなくアクション |
wp | クエリが決まった直後 |
pre_get_posts は名前からフィルターに見えますが、アクションです。
渡されたクエリのオブジェクトを直接書き換えます。
add_action( 'pre_get_posts', function ( $query ) {
// 管理画面とサブクエリは触らない
if ( is_admin() || ! $query->is_main_query() ) {
return;
}
if ( $query->is_category() ) {
$query->set( 'posts_per_page', 20 );
}
} );下書きの自動保存は親の記事IDでも起こる
wp_is_post_autosave()は渡されたIDが自動保存リビジョンかを調べます。
本人のロックされていない下書きは、WordPressのwp_autosave()が親の下書きを直接保存するため、この確認だけでは自動保存を除外できません。
保存の例にはDOING_AUTOSAVEの判定も加えています。
WordPress 7.1.2の隔離環境で、wp_autosave()から下書きを保存しても、掲載例の処理位置は実行されないことを確認しました。
通常の投稿作成・更新は各1回、固定ページと権限のないユーザーによる保存では0回であることも確認しています。
実行回数を調べるため、例中の「ここに処理」だけを検証用カウンターへ置き換えました。
この例は処理を置く骨組みです。
フォーム独自の値を保存する場合は、フォームに対応したnonce、入力値の検証、保存先を別途実装します。
REST APIやCLIなどの保存経路すべてを自動保存扱いにする機能ではありません。
WordPress公式のwp_autosave()で保存先の分岐を確認できます。
同じsave_post_postの処理を重複登録しないでください。解除時は追加した登録全体を外します。
優先度と引数の数
add_action() の3つめと4つめが、つまずきどころです。
add_action( 'フック名', '関数名', 優先度, 受け取る引数の数 );| 引数 | 既定 | 意味 |
|---|---|---|
| 優先度 | 10 | 小さいほど先に走る。あとから上書きしたいなら大きくする |
| 引数の数 | 1 | 2つ以上受け取るなら必ず書く。書かないと2つめ以降が渡らない |
2つ目以降の引数を使う場合は、フックの呼び出し元がその値を渡しているかと、登録時の第4引数の両方を確認してください。
必要な引数の数が合わないと、nullになるとは限らず、引数不足のエラーになる場合もあります。
他のプラグインの処理より後に走らせたいときは、優先度を大きくします。
// 他のプラグインが 10 で書き換えたあとに、こちらで上書きする
add_action( 'wp_enqueue_scripts', function () {
// 後から実行したい読み込み処理をここに置きます。
}, 99 );フックを探すときは
全部を覚えるより、探し方を知っておくほうが早いです。
- 公式のリファレンスで名前を引く(
developer.wordpress.org/reference/hooks/) - テーマやプラグインのファイルを
do_actionで検索する。そこが差し込める場所 - 使っているテーマの一覧記事を見る(下にまとめています)
自作のフックは、処理を先にadd_actionで登録し、実行したい場所でdo_actionを呼び出します。
掲載例は登録側と呼び出し側の2つの置き場所を示しています。
// functions.phpや独自プラグインで先に登録する
add_action( 'my_theme_before_footer', function ( $args ) {
echo '<p>フッターの直前です</p>';
} );
// 自分が管理するテーマのテンプレートで、フッター直前に呼び出す
$args = array(); // フックで渡すデータ
do_action( 'my_theme_before_footer', $args );
テーマ別のフック一覧は、それぞれまとめています。



SWELLでフックを使ってコンテンツを差し込む場所は、こちらです。

登録と呼び出しを置く場所を分ける
| コードの役割 | 置き場所 |
|---|---|
| add_actionによる登録 | 子テーマのfunctions.phpまたは独自プラグイン |
| do_actionによる呼び出し | 自分が管理するテンプレート内の、実行したい位置 |
| 既存のSWELLフックを使う | テーマ側の呼び出しへ登録するだけ |
掲載例はadd_actionによる登録を先に置き、その後でdo_actionを呼び出します。WordPress 7.1.2の実行環境で「フッターの直前です」の段落が出力されることを確認しました。
実際にフッター直前へ入れるときは、登録部分と呼び出し部分をそれぞれ表の位置へ置き、全体をfunctions.phpへ貼り付けないでください。
SWELLに既存の呼び出しがある場合は、親テーマのテンプレートを編集せず、SWELLのフック一覧から選びます。
pre_get_postsの掲載例では、カテゴリーのメインクエリだけが20件になり、カテゴリーのサブクエリとカテゴリー以外のメインクエリは元の5件のままであることも確認しました。
本文フィルターの例は実Pjaxで2つの投稿へ移動しても追加段落が1回だけ出力され、固定ページには追加されませんでした。
戻すときは登録した処理と自作の呼び出しを一組で取り除き、ほかのフックや本文を残します。

まとめ
- 「何かをする」はアクション、「何かを変える」はフィルター
- フィルターは
returnを忘れない。忘れると値が消える - 順番は after_setup_theme → init → template_redirect → wp_enqueue_scripts → wp_head の流れ
- 用途に応じたフックを選ぶ。ただし管理画面でも走るので条件を添える
save_postは自動保存とリビジョンを除外する- 引数を2つ以上受け取るなら、4つめの数を必ず書く
この記事は2026年9月16日時点の公式リファレンスで確認しました。
公式の一覧はこちらです。
WordPressのカスタマイズ全体は、こちらにまとめています。

この記事で紹介しているコードは、GitHubのMOTOKI-LLC/WAZA-codeにもまとめています。
wp_enqueue_scriptsは通常、wp_headアクションの優先度1に登録された処理から呼ばれるため、wp_head全体より前に独立して完了するわけではありません。
例は子テーマのfunctions.phpまたは独自プラグインへ用途ごとに追加し、戻す場合は追加した登録と関数を取り除きます。
公開への切り替えだけを処理する場合は、transition_post_statusで新状態がpublish、旧状態がpublish以外であることを確認してください。
保存フックの処理が実行される入口を確認する
| 入口 | 今回確認した動作 | 実装側の確認 |
|---|---|---|
| 認証済みREST更新・正しいnonce | 投稿保存後に処理位置が実行される | 対象投稿・処理の重複を確認 |
| 認証済みREST更新・不正nonce | 403で拒否され、処理位置は実行されない | REST側の拒否と保存フックの条件を分ける |
| RESTの自動保存 | 自動保存は成功し、例の処理位置は実行されない | DOING_AUTOSAVEと自動保存・リビジョン判定を残す |
WordPress 7.1.2の隔離環境で、自分が所有する下書きだけをHTTP更新し、例の「ここに処理」の位置を記録して確認しました。
REST認証用nonceはWordPress側が検証します。
この保存フック例に独自フォームのnonce検証が含まれるわけではありません。
独自フォームから処理する場合は、そのフォームの送信入口でnonceと権限を検証してください。
また、投稿を保存した回数と処理の実行回数は同じとは限りません。
課金や外部通知など重複できない処理を、条件のないsave_postへ置かないでください。



