
WordPressでショートコードが表示されず文字列だけ出る時の直し方
WordPress 7.0 でショートコードが表示されず、角括弧付きの文字列がそのまま画面に出る場合、プラグインの停止・テーマの出力フィルタ不足・ブロックエディタとの相性が主な原因だ。直すにはプラグインの更新や有効化確認から始め、テーマ側で処理されていないときは強制実行のコードを functions.php に追加する。
なぜショートコードが表示されず文字列だけ出るのか

ショートコードは [example] のような角括弧で囲まれた短い文字列で、WordPress が表示の瞬間に対応する PHP 処理や HTML に置き換える仕組みだ。この置き換えが行われず、角括弧付きのまま表示される場合、大きく分けて三つの原因が考えられる。
原因1 ショートコードを登録しているプラグインが停止している
プラグインが無効化されているか、WordPress 7.0 への更新後に互換性の問題で停止しているケースが最も多い。更新直後にサイトが「このサイトで重大なエラーが発生しました」という表示になった場合、WordPress は自動で問題のプラグインを停止する。この自動停止によってショートコードの登録処理が丸ごと抜け落ち、文字列だけが残る。
また、プラグインは有効に見えても、特定のページタイプ(固定ページ・投稿・カスタム投稿タイプ)で意図的にショートコードの置換を制限している設計もある。管理画面のプラグイン一覧で有効化状態を確認しても原因がわからないときは、プラグインの内部ロジックまで疑う必要がある。
原因2 テーマが本文中のショートコードを処理していない
ショートコードの置換は do_shortcode() という関数を通じて実行される。WordPress の標準ループやウィジェットエリアでは自動で処理されるが、テーマがカスタマイズされたテンプレートで直接 get_post_meta() や the_content() を独自に加工している場合、この関数が呼ばれずショートコードが展開されない。とくに自作テーマや子テーマでカスタムフィールドの値を表示する箇所で起きやすい。
原因3 ブロックエディタの「ショートコードブロック」未使用
WordPress のブロックエディタ(Gutenberg)でショートコードを機能させるには、専用の「ショートコード」ブロックの中に記述する必要がある。段落ブロックや見出しブロックに直接 [example] と打ち込んだ場合、ブロックの保存・出力の仕様によってはテキストとしてそのまま表示されることがある。クラシックエディタに慣れていると見落としがちなポイントだ。
上図の三方向から原因を絞り込めば、ほとんどのケースで該当箇所が見つかる。次項からは実際の対処手順を具体的に解説する。
ショートコードが機能しないときの具体的な対処手順

手順1 プラグインの有効化と更新を確認する
管理画面の「プラグイン」→「インストール済みプラグイン」を開き、該当プラグインが有効化されているかを確認する。無効化されていれば「有効化」をクリックするだけで解決することが多い。有効化されているのに直らない場合は、プラグインの最新バージョンがリリースされていないか更新画面を確認する。WordPress 7.0 へのメジャーアップデート直後は、プラグイン開発者が緊急の互換性アップデートを出している可能性が高い。
管理画面にアクセスできないほどサイトが壊れている場合は、WordPress の「リカバリモード」を利用する。サイトで致命的エラーが発生すると、管理者メールアドレス宛に「このサイトで重大なエラーが発生しました」という件名のメールが届き、その中にリカバリモード用の特別なログインリンクが記載されている。このリンクからログインすると、問題のプラグインだけが停止した状態で管理画面に入れる。
手順2 テーマ側で do_shortcode() を明示的に実行する
プラグインが正常に動作しているのにショートコードが展開されない場合、テーマのテンプレートが原因だ。該当のショートコードを表示したい箇所がカスタムフィールドやウィジェットエリア内であれば、テンプレートファイル内の出力部分に do_shortcode() を追加する。
// カスタムフィールドの値をショートコード展開して出力
echo do_shortcode( get_post_meta( get_the_ID(), 'my_custom_field', true ) );
// 本文中のショートコードを意図的に再実行(通常は不要だが保険として)
echo do_shortcode( get_the_content() );上記は functions.php ではなく、該当のテンプレート(single.php や page.php など)の出力箇所に追記するコードだ。子テーマを使っていない場合は必ず子テーマを用意してから編集し、テーマのアップデートで変更が失われないようにする。子テーマの作り方は後述の FAQ で扱う。
手順3 ブロックエディタで「ショートコード」ブロックを使う
ブロックエディタでページを編集している場合、ブロック挿入ツール(+ボタン)から「ショートコード」ブロックを検索して追加する。既存の段落ブロックに直接ショートコードを打ち込んでいる場合は、そのブロックを削除して新しくショートコードブロックを追加し、中にショートコード文字列だけを入力する。
この手順でブロックエディタ上の問題は解決するが、テーマ側の出力処理に起因する問題はこれだけでは直らない。手順2も併せて確認するのが確実だ。
WordPress 7.0 特有の注意点と想定外のエラーへの備え

WordPress 7.0 は内部のエラーハンドリングが強化され、従来は警告レベルで済んでいた処理が致命的エラーとして扱われるケースが増えている。プラグインが最新でも、内部の非推奨関数の呼び出しや PHP バージョンとの不一致があると、サイト全体がダウンし管理画面からも締め出される。
こうした状況では、FTP またはサーバーのファイルマネージャーで /wp-content/plugins/問題のプラグインフォルダ/ を一時的にリネームする方法が最も確実な緊急回避策になる。フォルダ名を「custom-profile-picture」から「custom-profile-picture_temp」などに変更すれば、WordPress はそのプラグインを検出できなくなり、サイトが正常に表示される状態まで復帰する。その後、プラグインの互換性情報を確認してから正式な対処を取る。
よくある質問
ショートコードを使うプラグインをアップデートしたらサイトが真っ白になった
WordPress 7.0 とプラグインの互換性が取れていない可能性が高い。リカバリモードのリンクがメールで届いていればそこからログインし、問題のプラグインを停止する。メールが届いていない場合は FTP で対象プラグインのフォルダをリネームし、管理画面にアクセスできる状態に戻してから代替プラグインを検討する。
子テーマの functions.php に追記する方法がわからない
子テーマとは、親テーマの機能を引き継ぎつつ安全にカスタマイズするための仕組みだ。まず親テーマと同じディレクトリに子テーマ用フォルダを作成し、style.css と functions.php の2ファイルを設置する。functions.php には親テーマのスタイルを読み込むコードと、do_shortcode() を含むカスタマイズコードを記述する。詳細な手順は WordPress 公式の子テーマ作成ガイドが役立つ。
ショートコードブロックを使っても特定のページだけ表示されない
キャッシュ系プラグインや CDN が原因のことが多い。キャッシュを全削除し、CDN を使用している場合は一時的に開発モードにしてから表示を確認する。また、該当ページがカスタム投稿タイプで、テンプレートが専用の出力処理をしている場合も同様に do_shortcode() の追加が必要になる。
プラグインを更新したが問題が再発した
更新で一度直っても、WordPress の自動エラーハンドリングが再度働いて同じプラグインを停止することがある。サーバーのエラーログを確認し、PHP のメモリ不足や実行時間制限が原因であれば、wp-config.php で WP_MEMORY_LIMIT を 256M 以上に設定する。根本的にはプラグイン開発者の対応を待つ必要があるケースもある。
この記事のポイント
- ショートコードが文字列のまま表示される主因はプラグイン停止・テーマの処理不足・ブロック選択ミスの3つ
- 管理画面に入れない場合はリカバリモードか FTP でプラグインフォルダをリネームして復旧させる
- テーマ側で do_shortcode() が呼ばれていない箇所は子テーマのテンプレートに追記する
- ブロックエディタでは必ず「ショートコード」専用ブロックの中に記述する
- WordPress 7.0 はエラーハンドリングが強化され互換性問題が表面化しやすい

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

Contact Form 7のPDF出力で条件分岐ショートコードが効かない時の直し方
Contact Form 7 から出力する PDF に条件分岐のショートコード([if] や [hide-*] など)が反映されないとき、最も多い原因は Send PDF for Contact Form 7 プラグインが、Conditional Fields のような他プラグインのショートコードを PDF 生成時に評価しないことだ。この問題は、PDF テンプレート内で直接条件分岐を記述する代わりに [_mail_body] タグを使ってメール本文を丸ごと流し込むか、出力直前にショートコードを再評価するフィルターフックで解決できる
なぜ PDF 出力で条件分岐ショートコードが効かなくなるのか

Send PDF for Contact Form 7 は、フォーム送信時に生成されたデータを PDF テンプレートに差し込んで出力する。このとき、[text-123] のような Contact Form 7 の標準タグは正しく展開されるが、Conditional Fields が提供する [group] や [if] といった条件分岐用のショートコードは、PDF 生成のコンテキストでは実行されないことが多い
理由は主に2つある。ひとつは、これらのショートコードが WordPress の do_shortcode フックに登録されていても、PDF プラグインがテンプレートを処理する段階では、フォームの送信データや条件判定に必要なコンテキストが不足しているケースだ。もうひとつは、Conditional Fields のショートコードが「メール送信時」にのみ動作するように設計されており、PDF 作成時にはそもそも処理の対象外になっているパターンだ
[if kosten-an-arbeitgeber]この見積は雇用主向けです[/if]
※条件にかかわらずショートコードがそのまま表示される
この見積は雇用主向けです
※条件に合致したテキストだけが PDF に出力される
このデモのように、PDF テンプレート内に [if] や [hide-*] を直書きしても、Send PDF 側で解釈されずに終わってしまう。以前は偶然動いていたとしても、プラグインのバージョンアップで処理順序が変わると即座に壊れる原因になる
プラグイン更新後に突然動かなくなったのはなぜか

「以前は PDF で条件分岐が効いていたのに、更新したら動かなくなった」という声は非常に多い。これは、Send PDF for Contact Form 7 または Conditional Fields for Contact Form 7 の内部実装が変更され、テンプレートの評価タイミングやショートコードの登録順が変わったためだ
具体的には、Send PDF プラグインの旧バージョンでは、PDF テンプレート全体を do_shortcode で処理していたが、パフォーマンスやセキュリティの改善に伴ってその処理が省略されたり、独自の置換処理に切り替わったりすることがある。結果として、Conditional Fields のショートコードが一切処理されなくなる
また、Conditional Fields 側のアップデートで、[if] タグの内部実装が変わり、PDF 出力時に必要なデータが揃わなくなった可能性もある。どちらにせよ、PDF テンプレート内で直接条件分岐を記述する方式は、プラグインのバージョンに依存しやすく、根本的に不安定と言える
[_mail_body] タグでメール本文をそのまま PDF に流し込む
![[_mail_body] タグでメール本文をそのまま PDF に流し込む](https://www.aandgweb.co.jp/wp-content/uploads/2026/06/2026-06-19_pain_001_h2_003.webp)
最も簡単で安全な解決策は、PDF テンプレート内に [_mail_body] を記述することだ。このタグは、Contact Form 7 が送信する「メール本文」をそのまま PDF 内に差し込む。メール本文のほうでは、Conditional Fields の条件分岐が正常に評価されているため、結果的に PDF にも正しい内容が出力される
この方法を使えば、Conditional Fields に限らず、メール本文で動作するあらゆるショートコードが PDF に反映される。ただし、PDF 独自のレイアウトや追加情報(会社ロゴや利用者に合わせた細かな差し込み)が必要な場合は、[_mail_body] の前後に固定の HTML を加えることで対応できる
注意点として、[_mail_body] はメール本文をそのままコピーするため、メール用の改行やスタイルが PDF に持ち込まれる。どうしてもレイアウトを細かく制御したい場合は、次に紹介するフィルターフックを使った方法を選ぶ
functions.php で PDF 生成前に条件分岐を再評価させる

Send PDF for Contact Form 7 には、PDF の最終的な内容を上書きできるフィルターフックが用意されている。これを利用すれば、テンプレート内の [if] や [hide-*] を手動で再評価できる。テーマの functions.php に次のようなコードを追加すると、Conditional Fields のショートコードが PDF 出力時に正しく展開される
add_filter( 'cf7_send_pdf_template_html', function( $html, $form_id ) {
// フォームの送信データを取得し、ショートコードを再評価する
$submission = WPCF7_Submission::get_instance();
if ( $submission ) {
$posted_data = $submission->get_posted_data();
// 一時的に do_shortcode を再度適用
$html = do_shortcode( $html );
}
return $html;
}, 10, 2 );このコードは、PDF テンプレートが組み立てられた直後に do_shortcode を実行し、[if] や [group] といったショートコードをその場で評価する。投稿データが揃っているため、Conditional Fields の条件判定も正しく動く
ただし、[hide-*] のように独自のショートコードを使っている場合は、そのショートコードがどのプラグインで定義されているかを確認し、該当のプラグインが有効でなければ動作しない。もし自作のショートコードであれば、あらかじめ add_shortcode で登録しておく必要がある
さらに、Send PDF プラグインのバージョンによってはフック名が異なる可能性もあるため、公式ドキュメントを参照し、cf7_send_pdf_template_html の部分を適切なフックに置き換える。このフックが利用できない場合は、wpcf7_before_send_mail などのアクションを使って PDF 生成前にデータを補完する方法もある
よくある質問
[_mail_body] を使うとメールの HTML タグがそのまま PDF に出てしまうのでは?
はい、メールフォーマットが HTML の場合、その HTML が PDF に適用される。多くは問題にならないが、シンプルなテキスト PDF を望むなら、メール設定を「テキスト形式」に切り替えるか、フィルターフックで HTML タグを strip_tags で除去するといった工夫が必要になる
Conditional Fields の [group] ショートコードも [_mail_body] で有効になるのか?
なる。[_mail_body] は、メール送信時に CF7 が最終的に組み立てた本文をそのまま埋め込むため、[group] の条件判定もすでに解決された状態で出力される
functions.php にコードを追加しても PDF が変わらないのはなぜ?
フック名が正しいか、また対象のショートコードが本当に do_shortcode で評価可能な形式かを確認する。Conditional Fields の [if] が内部で別のロジックを使っているレアケースでは、CF7 のメールテンプレート用のフィルター(wpcf7_mail_components など)を利用してメール本文を直接 PDF に渡すほうが確実だ
独自の [hide-*] ショートコードを PDF で動かすにはどうすればいい?
該当のショートコードを定義しているコードがテーマの functions.php にあるなら、そのまま do_shortcode で評価される。もし別のプラグインに依存しているのであれば、そのプラグインが常に有効でなければならない。動作が不安定な場合は、[_mail_body] 方式に切り替えるのが無難だ
この記事のポイント
- PDF テンプレート内で [if] や [hide-*] が効かないのは、Send PDF がそれらのショートコードを処理しないため
- [_mail_body] タグを使えば、メール本文ですでに展開された条件分岐結果をそのまま PDF に流し込める
- functions.php のフックで do_shortcode を再実行すれば、PDF 出力直前に任意のショートコードを動かせる
- プラグイン更新後に動かなくなったのは、ショートコード処理のタイミングが変わったのが原因
- 安定運用には[_mail_body]方式を推奨。細かいレイアウトが必要ならフィルターフック方式を使う

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
