AI初心者向けガイドを公開中｜ChatGPTからブログ活用までやさしく解説
WordPressクラシックエディタのショートコード活用法｜便利な使い方を解説
WordPressクラシックエディタでショートコードを使うなら、提供元のコードを記事本文に入力し、プレビューで正常に変換されるか確認するのが基本だ。
ショートコードは、`[example]`のような短い記述から、登録された処理を呼び出せるWordPressの仕組みだ。
フォームやギャラリーなどの機能を呼び出したり、複数の記事で使う共通パーツを部品化したりできるため、クラシックエディタを使っているサイトでは今でも役立つ場面がある。
ただし、ショートコードなら何でも便利というわけではない。
テーマやプラグインに依存するコードを大量に使うと、テーマ変更やプラグイン停止、サイト移行の際に問題になることもある。
この記事では、WordPressクラシックエディタでショートコードを使う基本手順から、自己完結型・囲み型・属性（パラメータ）の違い、表示されないときの原因、自作方法、共通パーツの管理、ブロックとの使い分けまで、初心者にも分かるように整理する。
WordPressクラシックエディタでショートコードを使う方法は？
クラシックエディタでショートコードを使う基本的な流れは、「コードを確認する→本文へ入力する→表示を確認する」の3ステップだ。
たとえば、利用している機能が`[my_shortcode]`というショートコードを提供しているなら、記事本文の表示したい場所へ次のように入力する。
`[my_shortcode]`
WordPress側に`my_shortcode`というショートコードが登録されていれば、ページを表示するときに登録された処理が実行される。
つまり、記事本文へ入力した文字列そのものを読者へ見せるのではなく、WordPressがその記述を処理して、別の内容へ置き換える仕組みだ。
ここで初心者が最初に覚えておきたいのは、ショートコード名を自分で適当に作って入力しても動かないということだ。
`[my_shortcode]`を例として挙げたが、これは説明用の名前にすぎない。
実際に利用する場合は、使っているテーマ、プラグイン、自作機能などが提供している正確なショートコードを確認する必要がある。
クラシックエディタのどこへ入力する？
基本的には、ショートコードを表示したい位置に記事本文として入力すればいい。
たとえば、記事の途中にフォームを表示したいなら、フォームを呼び出すショートコードをその位置へ配置する。
文章の後に共通の案内パーツを表示したいなら、その直前または直後にショートコードを置く。
クラシックエディタには「ビジュアル」と「テキスト」の編集画面がある。
単純にショートコードを入力するだけなら、基本的には記事本文へ記述すればよい。
ただし、利用しているテーマやプラグインによって推奨される操作が異なる場合もあるため、提供元のマニュアルがあるなら、その方法を優先しよう。
ショートコードを入力したら何を確認する？
いきなり公開するのではなく、まずプレビューで確認したい。
チェックするポイントは次のとおりだ。
- ショートコードが意図した内容へ変換されているか
- `[my_shortcode]`のようなコード文字列がそのまま残っていないか
- 表示位置が想定どおりか
- レイアウトが崩れていないか
- パラメータの指定が反映されているか
- スマートフォンでも読みやすく表示されるか
特に重要なのが、「コードを入力できた」ことと「正常に表示された」ことは別だという点だ。
ショートコードは数文字しかないため、スペルミスや属性の指定ミスに気付きにくい。
だからこそ、記事編集画面だけで判断せず、実際の表示まで確認する習慣をつけたい。
WordPressのショートコードとは？
WordPressのショートコードは、角括弧で囲んだ短い記述を使って、登録済みの処理を呼び出す仕組みだ。
代表的な形は次のようになる。
`[my_shortcode]`
この`my_shortcode`という名前の処理がWordPressへ登録されていれば、ページ表示時にその処理が実行される。
ショートコードの魅力は、記事本文に複雑な処理を毎回書かなくても、短い呼び出しだけで同じ機能を利用できることにある。
たとえば、複数の記事で同じ案内ボックスを表示したいとする。
HTMLを記事ごとに直接書いてしまうと、案内文を変更するたびに、それぞれの記事を探して修正しなければならない。
一方、共通パーツをショートコードから呼び出す仕組みにしておけば、記事本文には短いコードだけを置き、表示する内容を別の場所で管理できる設計が可能になる。
ここがショートコードの本当の価値だ。
ショートコードは「入力を短くする道具」であると同時に、「コンテンツを部品として管理する道具」でもある。
ブログの記事数が少ないうちは、この違いを実感しにくい。
しかし記事が増えてくると、同じ情報を何度も修正する作業が重くなる。
だから長期的なサイト運営では、「書く速さ」だけでなく「後から直す速さ」にも注目したい。
自己完結型ショートコードとは？
自己完結型は、コードだけで処理が完結するタイプだ。
基本形は次のようになる。
`[my_shortcode]`
属性を指定する場合は、
`[my_shortcode id=”358″]`
のように書くこともある。
このタイプでは、開始タグと終了タグの間へ別の文章を入れる必要がない。
WordPressでは、ギャラリーなどの機能でショートコードが使われてきた。
たとえば、ギャラリーのショートコードとして次のような記述が使われる場合がある。
`ここでは、画像のIDや列数、サイズなどを属性として指定している。
ただし、現在のWordPressでは画像、ギャラリー、動画などを扱うためのブロックも用意されている。
そのため、「ショートコードで実現できるか」だけではなく、「現在の編集環境で何が最も管理しやすいか」まで考えることが重要だ。
既存サイトでプラグインがショートコードを提供しているなら、そのまま使う合理性がある。
一方、新しい仕組みを作る場合は、標準ブロックなどで代替できないか確認してから判断したい。
囲み型ショートコードとは？
囲み型ショートコードは、開始タグと終了タグの間にコンテンツを入れて使うタイプだ。
基本形は次のとおりだ。
`[my_shortcode]ここに文章[/my_shortcode]`
たとえば、
`[highlight]重要な文章[/highlight]`
という記述なら、「重要な文章」がショートコードの処理対象になる。
囲み型は、文章を特定のデザインで囲んだり、入力した内容へ一定の処理を加えたりするときに使いやすい。
クラシックエディタで毎回HTMLを書いて装飾するのが面倒なら、囲み型ショートコードによって本文を簡潔にできる場合がある。
ただし、ここでも重要なのは、そのショートコードが実際に囲み型へ対応しているかを確認することだ。
自己完結型として登録されたショートコードに、勝手に終了タグを付けても期待どおりに動くとは限らない。
ショートコードは見た目が似ていても、提供元によって仕様が違う。
「この書き方なら動くだろう」と推測せず、仕様を確認することがトラブル回避につながる。
ショートコードの属性・パラメータとは？
ショートコードの属性は、呼び出す処理へ追加の情報を渡すためのものだ。
たとえば、
`[my_shortcode id=”358″]`
なら、`id=”358″`が属性にあたる。
同じショートコードでも、指定する値によって表示内容を変えられるのがメリットだ。
複数の属性を使う設計なら、
`[my_shortcode id=”358″ name=”名前” url=”example.com”]`
のように記述することもできる。
囲み型でも、
`[my_shortcode id=”358″ name=”名前”]テキスト[/my_shortcode]`
のように属性と本文を組み合わせられる。
ただし、属性名はショートコードごとに決まっている。
`id`や`name`という名前を勝手に追加しても、それを処理する側が受け取る仕組みを持っていなければ意味がない。
したがって既存ショートコードを利用するときは、属性名、指定できる値、必須項目、省略時の動作を提供元の説明で確認することが大切だ。
WordPressのショートコードが表示されないのはなぜ？
ショートコードを入力したのに期待した内容が表示されない場合、まず「そのショートコードを処理する仕組みが現在も存在するか」を確認しよう。
チェックしたいポイントは次のとおりだ。
- ショートコード名のスペルが正しいか
- `[ ]`を含めた書式が正しいか
- 必要な属性を指定しているか
- ショートコードを提供するプラグインが有効になっているか
- テーマを変更していないか
- 関連する機能を停止していないか
- ショートコードの使える場所へ入力しているか
- 提供元の仕様が変更されていないか
たとえば、以前は正常に表示されていたショートコードが突然そのまま表示されるようになったとする。
この場合、単純な入力ミスだけでなく、プラグインを停止した、テーマを変更した、関連機能を削除した、といった環境側の変化も疑う必要がある。
ここで覚えておきたい考え方がある。
ショートコードの不具合は、コードだけを見ていても解決できないことがある。
そのコードを登録しているのは誰なのか。
どのテーマやプラグインが処理しているのか。
いつから表示されなくなったのか。
この3点を順番に追うと、原因を絞り込みやすくなる。
ショートコードの最大のメリットは共通コンテンツの再利用
ショートコードを活用する大きなメリットの一つが、同じコンテンツを複数の記事から利用しやすくなることだ。
たとえば20記事に同じ案内文を掲載しているとする。
記事本文へ直接コピーしているなら、案内文を変更するときに20記事を確認する必要がある。
しかも、人間が一つずつ修正する以上、修正漏れが起きる可能性もある。
一方、共通部分を部品として管理し、ショートコードから呼び出す設計なら、共通部分を一か所で管理できる場合がある。
メリットを整理すると、次のとおりだ。
- 長いHTMLや文章を何度も入力しなくてよい
- 複数の記事で同じコンテンツを利用しやすい
- 共通部分をまとめて管理しやすい
- 修正箇所を減らせる
- 記事本文をすっきり保ちやすい
筆者が特に注目したいのは、「記事を書く時間」ではなく「記事を直す時間」を減らせることだ。
ブログは公開した瞬間に終わるものではない。
情報が古くなれば更新する。
表現を見直す。
サイト全体の方針が変われば共通部分も修正する。
記事数が増えるほど、この更新作業がサイト運営の負担になる。
だからショートコードは、執筆効率を上げるためだけではなく、長期的な運用負担を減らすための仕組みとして考えると分かりやすい。
共通パーツをショートコードで呼び出す方法
共通パーツを再利用する仕組みとして、別途保存したコンテンツをショートコードから呼び出す設計も考えられる。
たとえば、ブログパーツ用のコンテンツを用意し、それを識別するスラッグを`test`とする。
記事本文には、
`[blogparts slug=”test”]`
のようなショートコードを置く。
ショートコード側で`test`に対応するコンテンツを取得する処理を作っておけば、複数の記事から同じパーツを呼び出せる。
この方式のポイントは、記事本文と共通パーツを分離できることだ。
たとえばサイト全体で共通して使う案内文があるなら、その内容を一か所で管理し、必要な記事から呼び出す設計が考えられる。
ただし、ここから先は単純なショートコード入力とは違う。
カスタム投稿タイプやPHPなどを使った実装が必要になる場合があるため、初心者が最初に覚えるべき機能ではない。
まずは既存ショートコードを使う。
次に、どのような仕組みで表示されているのか理解する。
それでも管理負担が大きくなったら、共通パーツ化を検討する。
この順番で十分だ。
共通部分と記事ごとの差分を分ける方法
ショートコードをさらに活用すると、完全に同じ文章だけではなく、共通部分と記事ごとの差分を分離する設計もできる。
たとえば、全国共通の説明文があり、地域名や一部の案内だけを記事ごとに変えるケースを考えてみよう。
すべての文章を記事ごとにコピーすると、共通部分を変更するたびに多くの記事を修正しなければならない。
そこで、
- 共通する文章
- 記事ごとに変わる情報
を別々に管理する方法がある。
カスタムフィールドなどを使って必要な値を保存し、ショートコードから取得して表示する仕組みもその一つだ。
たとえば共通の文章の中に、決められた置換用の目印を用意しておき、そこへ記事ごとの値を差し込む設計が考えられる。
ただし、単純な文字列置換には注意が必要だ。
同じ文字列が別の場所にも存在すると、意図しない箇所まで置き換えてしまう可能性がある。
したがって、差分管理をする場合は、「どの情報をどこで管理し、どこへ表示するのか」を先に決めることが重要だ。
便利な仕組みほど、最初の設計が後々の使いやすさを左右する。
ACFとショートコードを組み合わせると何ができる？
ACF（Advanced Custom Fields）のようなカスタムフィールドを扱う仕組みとショートコードを組み合わせると、記事本文とは別にデータを管理し、その値を必要な場所へ表示する設計も可能になる。
たとえば、共通パーツ側に複数の情報を登録しておき、
`[blogparts slug=”test” field=”nara”]`
のようにスラッグとフィールド名を指定して表示する仕組みを考えられる。
別のフィールドなら、
`[blogparts slug=”test” field=”osaka”]`
のように呼び出す。
こうした設計のメリットは、文章とデータの役割を分けやすいことだ。
ただし、ここで機能を増やしすぎないことが重要になる。
ショートコードだけで十分なのに、さらにカスタムフィールド、独自PHP、複数の管理画面を追加すれば、サイトの仕組みそのものが複雑になる。
便利な機能を増やすことと、管理しやすいサイトを作ることは同じではない。
筆者としては、ACFなどを使うかどうかは「できるから」ではなく、記事数や更新頻度、管理するデータの種類から逆算して判断することをおすすめする。
ショートコードとブロックはどう使い分ける？
現在のWordPressでは、ブロックエディターを使って文章、画像、ギャラリーなどを組み立てられる。
そのため、新しくサイトを作る場合は「ショートコードでできるか」だけを基準にしないほうがいい。
判断の目安は次のようになる。
やりたいこと 方法の目安
普通の文章や画像を配置する ブロック
標準ブロックで実現できる表示を作る ブロック
既存プラグインがショートコードを提供している そのショートコード
クラシックエディタで共通パーツを呼び出す ショートコード
複数ページから同じ動的コンテンツを呼び出す ショートコードなどの部品化
記事とは別に情報を管理する カスタムフィールドなども検討
テーマ変更後も使いたい独自機能 テーマへの依存を避ける設計も検討
これは絶対的なルールではない。
既存サイトがクラシックエディタ中心なら、すでに動いているショートコードを活用するほうが合理的な場合もある。
逆に、新規サイトで標準ブロックだけで十分なら、わざわざ独自ショートコードを作る必要がないケースもある。
重要なのは、「今の編集方法」と「将来の管理方法」を一緒に考えることだ。
どんな場合にショートコードを使うべき？
筆者としては、次の条件に当てはまるほどショートコードを検討する価値が高いと考えている。
複数の記事で同じ内容を使い、その内容を将来変更する可能性がある場合だ。
たとえば、次のようなコンテンツが候補になる。
- 共通の案内文
- 複数記事で利用する注意事項
- 共通の問い合わせ案内
- 独自の案内ボックス
- プラグインが提供するフォーム
- 動的に内容を切り替えるパーツ
- サイト全体で繰り返し使う独自コンテンツ
逆に、1記事で一度しか使わない単純な文章までショートコードにする必要はない。
「何でも部品化」すると、今度は記事編集時にコードの意味を確認する手間が増えるからだ。
おすすめしたい判断基準は、「半年後にこの内容を変更するとしたら、何ページを修正することになるか」である。
変更対象が1ページなら、そのまま本文へ書くほうが簡単かもしれない。
何十ページ、何百ページにも及ぶなら、共通パーツ化を検討する価値が高くなる。
ショートコードを使わないほうがいいケースは？
ショートコードが向いていないケースもある。
たとえば、一度しか使わない文章や、記事ごとに完全に内容が違うパーツだ。
こうしたものまで部品化すると、記事本文を読むだけでは内容が分からなくなり、編集のたびに別の管理画面を確認しなければならなくなる。
また、テーマや特定プラグインへの依存が強いショートコードを大量に使う場合も注意したい。
そのテーマを変更したり、プラグインを停止したりしたとき、記事本文にショートコードだけが残る可能性があるからだ。
つまりショートコードには、
現在の管理を楽にする代わりに、将来の移行時に確認すべきことが増える場合がある
という側面がある。
便利さだけで判断せず、「このサイトを別のテーマへ移すときにどうなるか」まで考えておくことが大切だ。
WordPressのショートコードを自作する方法
ここからは自作編だ。
WordPressでは、`add_shortcode()`を使ってショートコードと、それが呼び出されたときに実行する処理を登録できる。
基本形は次のとおりだ。
`add_shortcode( $tag, $callback );`
`$tag`にはショートコード名を指定し、`$callback`には呼び出されたときの処理を指定する。
たとえば、次のような処理を登録する方法がある。
`add_shortcode( ‘my_shortcode’, function(){ return ‘これはショートコードのサンプルです。’; } );`
この場合、記事本文に、
`[my_shortcode]`
と入力すると、登録した処理の戻り値がショートコードの出力として利用される。
仕組みだけを見るとシンプルだ。
登録する→本文から呼び出す→処理が実行される。
これが自作ショートコードの基本構造になる。
ただし、PHPコードを編集する必要があるため、IT初心者が本番サイトでいきなり試すのはおすすめしない。
コードのミスによってサイトの表示や動作に影響する可能性がある。
まずはテスト環境やバックアップを用意し、仕組みを理解したうえで試したい。
属性付きショートコードを自作するには？
属性付きショートコードでは、記事本文から渡された値を処理側で受け取る。
たとえば、
`[my_shortcode first_name=”太郎” last_name=”山田”]`
のような記述を考えられる。
処理側では、`first_name`や`last_name`の値を利用して表示内容を組み立てられる。
このとき、属性が省略された場合の初期値を設定する方法として`shortcode_atts()`が利用される。
自作するなら、単に値を受け取るだけでなく、次のことまで考えておきたい。
- 必須の属性は何か
- 属性が省略されたらどうするか
- 想定外の値が入ったらどうするか
- URLを受け取る場合はどう扱うか
- HTML属性として出力する値をどう処理するか
- テキストとして表示する値をどう処理するか
ショートコードは短い記述でも、裏側ではPHP処理が動いている。
だからこそ、「表示できた」だけでは完成ではない。
長く運用するなら、入力ミスや想定外の値まで考えた設計が必要になる。
囲み型ショートコードを自作するには？
囲み型ショートコードでは、開始タグと終了タグの間に入力されたコンテンツを処理する。
たとえば、
`[my_shortcode]ここが本文です[/my_shortcode]`
と記述する。
この場合、「ここが本文です」が処理対象になる。
属性を組み合わせれば、
`[my_shortcode type=”notice”]ここが本文です[/my_shortcode]`
のように、種類を指定する設計もできる。
ただし、自作するときに忘れてはいけないのが安全な出力だ。
属性や本文をそのままHTMLへ埋め込むのではなく、出力する場所に応じて適切なエスケープやサニタイズを検討する必要がある。
たとえば、通常のテキストとして出力する場合と、HTML属性として出力する場合では適切な扱いが異なる。
URLを扱う場合も同じだ。
「動くショートコード」を作るだけでなく、「安全に運用できるショートコード」を作ることが重要だ。
PHPに慣れていないなら、この部分は公式ドキュメントや信頼できる技術資料を確認しながら進めたい。
`do_shortcode()`は何に使う？
`do_shortcode()`は、PHP側からショートコードを実行したい場合などに使える関数だ。
たとえば、PHP側でショートコード文字列を処理する場合に、
`echo do_shortcode( ‘[my_shortcode id=”358″]’ );`
のような形を使える。
囲み型なら、
`echo do_shortcode( ‘[my_shortcode type=”notice”]重要なお知らせ[/my_shortcode]’ );`
のような書き方も考えられる。
ただし、ここは初心者が混乱しやすいところだ。
クラシックエディタの記事本文にショートコードを入力するだけなら、PHP側で`do_shortcode()`を書く必要はない。
まずは記事本文でショートコードを使う方法を理解すれば十分だ。
その後、テーマや独自機能の開発などで「PHPからショートコードを実行したい」という場面が出てきたら、`do_shortcode()`を学べばいい。
ショートコードを自作するときは`functions.php`への依存に注意
ショートコードの登録場所としてテーマの`functions.php`が使われることはある。
しかし、「独自機能だから、とりあえず現在のテーマへ書けばいい」と考えるのは危険だ。
テーマに依存したショートコードは、そのテーマを変更したときに使えなくなる可能性がある。
たとえば旧テーマで、
`[my_shortcode]`
を大量の記事で利用していたとする。
新しいテーマへ変更した結果、そのショートコードを登録していた処理がなくなれば、記事本文にはコードだけが残ってしまう可能性がある。
サイト固有の機能として長く使うなら、テーマから独立した仕組みとして管理する方法を検討したほうがよい場合もある。
大切なのは、「どこへコードを書いたか」だけではない。
そのショートコードを提供している処理が、テーマ変更後も存在するのかを把握しておくことだ。
ショートコードのテーマ依存・プラグイン依存に注意
ショートコードを長期間使うなら、「誰がそのショートコードを提供しているのか」を必ず把握しておこう。
たとえばテーマ独自のショートコードを大量に利用しているとする。
そのテーマを変更すれば、旧テーマのショートコードを処理できなくなる可能性がある。
プラグインも同じだ。
フォームを提供するプラグインのショートコードを多数の記事で使っているなら、そのプラグインを停止・削除する前に利用箇所を確認する必要がある。
ショートコードの特徴は、記事本文に書かれているコードと、それを処理する仕組みが別々に存在することだ。
だから記事本文だけを見ていても、その機能の全体像は分からない。
サイトを長く運営するなら、使用しているショートコードについて、
- ショートコード名
- 提供元
- 利用目的
- 利用している記事
- テーマ変更時の影響
- プラグイン停止時の影響
を把握しておくと安心だ。
これは地味だが、記事数が増えたサイトほど効いてくる管理方法だ。
サイト移行でショートコードが問題になる理由
サイトのリニューアルやテーマ変更では、ショートコードが思わぬ作業を生むことがある。
たとえば、旧テーマ独自のショートコードを数百記事で使っていた場合、新しいテーマではその処理が存在しない可能性がある。
記事数が少なければ手作業で修正できる。
しかし、数百記事、数千記事へ広がっていれば話は変わる。
だからショートコードを導入するときは、「今どう使うか」だけでなく「将来どう外すか」まで考えることをおすすめしたい。
最低限、次の3点は記録しておこう。
- どのショートコードを使っているか
- 何がそのショートコードを提供しているか
- 提供元を変更した場合、記事本文をどう移行するか
この情報が残っていれば、将来のサイト移行で原因不明のコードが大量に残る事態を避けやすくなる。
ショートコードを使う前に確認したい5つの判断基準
ショートコードは便利だ。
だからこそ、「便利そうだから使う」ではなく、導入前に一度立ち止まって判断したい。
1．何記事で使うのか？
1記事だけなら、普通に本文へ書いたほうが簡単なことが多い。
複数の記事で同じものを使うなら、ショートコードによる部品化のメリットが大きくなる。
2．将来変更する可能性はあるか？
今後ほとんど変わらない内容なら、共通パーツ化の優先度は低い。
一方、定期的に修正する案内や情報なら、一か所で管理できる仕組みを検討する価値がある。
3．誰が提供しているか？
テーマ、プラグイン、自作コードのどれなのかを確認する。
提供元が分からないショートコードを大量に使うのは避けたい。
4．サイト移行時にどうなるか？
テーマ変更やプラグイン停止によって使えなくなる可能性があるか確認する。
長期運営するサイトでは、この視点が非常に重要だ。
5．ブロックで代替できないか？
新しく仕組みを作るなら、標準ブロックや現在のWordPress環境に合った方法で実現できないかを確認する。
ショートコードを使うこと自体が目的になってはいけない。
目的は、サイトを分かりやすく、更新しやすく管理することだ。
初心者はショートコードを自作する前に既存機能を使おう
IT初心者なら、最初からPHPを書く必要はない。
まずは既存のテーマやプラグインが提供するショートコードを使ってみよう。
たとえばフォーム作成機能を持つプラグインでは、フォームを作った後、記事へ貼り付けるためのショートコードが表示される場合がある。
そのコードをクラシックエディタへ入力し、プレビューで確認する。
これだけでも、
「記事本文には短いコードを書く」
「WordPress側に登録された処理が動く」
「読者には処理結果が表示される」
という基本構造を体験できる。
そのうえで、
「自分でも共通パーツを作りたい」
「属性を指定して表示内容を変えたい」
となったら、`add_shortcode()`やPHPを学べばいい。
おすすめの順番は、
使う→仕組みを理解する→属性を使う→必要になったら自作する
だ。
いきなり難しいコードへ飛び込む必要はない。
IT初心者にとって大切なのは、最初から全部理解することではなく、目の前の小さな仕組みを一つずつ動かしてみることだ。
ショートコードを使うときの注意点
ショートコードを便利に使う一方で、いくつか注意しておきたいことがある。
まず、テーマやプラグインに依存しているショートコードを大量に使わないことだ。
提供元がなくなれば、記事本文に残ったショートコードの扱いを考えなければならない。
次に、自作ショートコードでは安全な入力処理と出力処理を意識する。
特に外部から値を受け取ったり、HTMLとして出力したりする場合は、値をそのまま扱わない設計が必要になる。
さらに、ショートコードの仕様を記録しておくことも重要だ。
数年後に自分が記事を編集するとき、「このコードは何をしているのか」が分からなければ、それだけで管理コストになる。
だから、コードを使うときは「未来の自分への説明」も残しておきたい。
これは技術的には小さな工夫だが、長期運営では大きな差になる。
考察：ショートコードの本当の価値は「書く速さ」より「直す速さ」にある
ここからは筆者の考察だ。
ショートコードというと、「HTMLを短く書ける便利な機能」という印象を持つ人も多いだろう。
しかし、ブログを長く運営する立場から見ると、もっと重要なのは更新管理だ。
10記事程度なら、同じ文章を複数の記事へコピーしても、それほど大きな負担にはならない。
ところが記事が100、300、500と増えていけば、同じ文章を一つずつ修正する作業が重くなる。
しかも、手作業には修正漏れのリスクがある。
だから私は、ショートコードの価値を「短く書けること」より、共通コンテンツを一つの部品として管理しやすくすることに置いている。
検索流入を狙うブログなら、なおさらだ。
検索向けの記事は、公開したら終わりではない。
情報が古くなれば更新する。
表現を見直す。
共通の案内を変更する。
サイト全体のルールに合わせて修正する。
こうした作業が積み重なると、記事を書く時間以上に「記事を直す時間」が問題になる。
ショートコードは、その負担を減らすための選択肢になり得る。
ただし、すべてをショートコード化すればいいわけではない。
部品化しすぎると、今度は記事の内容を理解するために複数の場所を確認する必要が出てくる。
つまり重要なのは、ショートコードを増やすことではなく、変更が集中する場所を適切にまとめることだ。
考察：ショートコードを使うかは「半年後」で判断する
もう一つ、実際にサイトを設計するときに使いやすい判断基準がある。
それは、「半年後にこの情報を変更するとしたらどうなるか」だ。
半年後も変更する可能性が低く、1記事でしか使わないなら、普通に本文へ書いても問題ないだろう。
一方、複数記事で使っていて、将来も修正する可能性が高いなら、共通パーツ化する価値がある。
この考え方は、ショートコードに限らない。
ブロック、カスタムフィールド、独自プラグインなどを選ぶときも同じだ。
便利な仕組みは、増やせば増やすほど良いわけではない。
管理を簡単にするための仕組みが、管理を複雑にしてはいけない。
ここを見失わなければ、初心者でも必要以上に技術を増やさずに済む。
考察：クラシックエディタは「古いからダメ」ではなく「今のサイトで管理できるか」で判断する
現在のWordPressでは、ブロックエディターを中心とした編集環境が整備されている。
だからといって、クラシックエディタを使っている既存サイトでショートコードをすべて否定する必要はない。
すでに大量の記事があり、現在の編集環境が安定しているなら、無理に仕組みを変えることがかえって大きな負担になる場合もある。
筆者としては、「新しいから正解」「古いから間違い」という判断は避けるべきだと考えている。
見るべきなのは、
安全に更新できるか、誰が管理しても理解できるか、将来変更するときの影響を把握できるか。
この3点だ。
クラシックエディタとショートコードの組み合わせが現在のサイトにとって扱いやすいなら、そのまま活用する意味は十分にある。
ただし、新しく仕組みを作る場合は、標準ブロックなど現在のWordPressで利用できる方法も比較してから決めたい。
WordPressクラシックエディタのショートコードを安全に使うポイント
最後に、安全に運用するためのチェックポイントを整理しておこう。
- 作業前にバックアップを取る
- 可能ならテスト環境で確認する
- ショートコードの提供元を記録する
- テーマやプラグインとの依存関係を把握する
- 自作コードの保存場所を把握する
- 属性や本文を適切に処理する
- HTMLへ出力するときは適切なエスケープを検討する
- テーマ変更時の影響を確認する
- プラグイン停止時の影響を確認する
- 使用しているショートコードを一覧化しておく
特に覚えておきたいのが、「短いコードだから影響も小さい」とは限らないということだ。
記事本文には一行しか書かれていなくても、その一行が100記事で使われていれば、変更時の影響は100記事分になる。
ショートコードは、小さな入口から大きな処理を呼び出せる仕組みだ。
だからこそ、便利さだけではなく、依存関係と将来の更新まで考えて使うことが重要になる。
まとめ：WordPressクラシックエディタではショートコードを管理の道具として使おう
WordPressクラシックエディタでショートコードを使う基本は、提供元の正しいコードを確認し、記事本文の表示したい位置へ入力し、プレビューで結果を確認することだ。
ショートコードには、単独で使う自己完結型と、文章などを挟んで使う囲み型がある。
属性を指定できるショートコードなら、同じ処理でもIDや種類などの値によって表示内容を変えられる。
特に大きなメリットを発揮するのは、複数の記事で共通コンテンツを利用するケースだ。
共通パーツとして管理できれば、記事数が増えたときの更新作業を減らせる可能性がある。
一方で、テーマやプラグインに依存したショートコードを大量に使うと、テーマ変更、プラグイン停止、サイト移行などで問題が起きる可能性がある。
だからこそ、
「何記事で使うのか」
「将来変更するのか」
「誰が提供しているのか」
「移行するときにどうなるのか」
を考えてから導入したい。
自作する場合は、`add_shortcode()`などを使ってPHPで処理を登録できる。
ただし、初心者が最初から自作する必要はない。
まずは既存のショートコードを使って仕組みを理解し、その後に必要になった段階で自作へ進めばいい。
ショートコードは、単なる「短いコード」ではない。
増えていく記事をどう部品化し、どう更新し、どう安全に管理するかを考えるための道具だ。
クラシックエディタを使っているなら、まず一つだけ、何度もコピーしている共通パーツを見つけてみよう。
「毎回同じ文章を貼り付けている」という小さな手間を一つ減らす。
そこから、ブログ運営の仕組みは変わっていく。
よくある質問
WordPressクラシックエディタでショートコードを使うにはどうすればいい？
利用しているテーマやプラグインが提供しているショートコードを確認し、クラシックエディタの記事本文の表示したい位置へ入力する。
その後、プレビューでショートコードが意図した内容へ変換されているか確認すればいい。
ショートコードを入力してもコードがそのまま表示されるのはなぜ？
ショートコードを提供するプラグインが無効になっている、テーマ変更によって登録処理がなくなった、ショートコード名や属性の書式が間違っている、といった原因が考えられる。
まず「そのショートコードを誰が提供しているのか」を確認しよう。
WordPressのショートコードは自作できますか？
自作できる。
WordPressでは`add_shortcode()`を使ってショートコードを登録し、PHPで呼び出されたときの処理を定義できる。
ただし、自作にはPHPの知識が必要になるため、初心者は既存のショートコードを利用するところから始めるのがおすすめだ。
ショートコードとブロックはどちらを使えばいい？
目的によって変わる。
標準ブロックで十分実現できる内容なら、ブロックを使うほうが分かりやすい場合がある。
一方、クラシックエディタで既存の共通パーツを呼び出したい場合や、利用中のプラグインがショートコードを提供している場合は、ショートコードが適した選択肢になる。
ショートコードをたくさん使っても大丈夫？
ショートコードの数だけで判断するのではなく、提供元と依存関係を確認することが重要だ。
特にテーマやプラグインに依存したショートコードを大量に使う場合は、テーマ変更やプラグイン停止、サイト移行の際に修正作業が発生する可能性がある。
ショートコードを自作するときに注意することは？
PHPコードの安全性だけでなく、属性や本文として受け取った値をどのように処理して出力するかまで考える必要がある。
また、テーマの`functions.php`など特定の環境に強く依存すると、将来のテーマ変更で機能が失われる可能性があるため、長期運用を前提に管理場所を考えたい。
新開猛（しんかい たける）
YOMIPO編集長
