「ノーコードで完成」という幻想 ― WordPressを縛る3つの依存
結論
WordPressは「ノーコードで完成するツール」ではありません。正確には、ノーコードで“始められる”ツールです。この違いを見落とすと、サイトは静かに3つの依存——ノーコード依存・テーマ依存・ベンダーロックイン——に縛られていきます。怖いのは、それが「便利」の顔をしてやってくることです。ブロックエディタもページビルダーも有料テーマも、それ自体は優れた道具です。問題は道具ではなく、「コードを書かずに完成させた」という言葉が、構造への意識を眠らせてしまうことにあります。
俯瞰でWordPressを捉え直すと、本当に問うべきは一つです。「あなたのサイトは、テーマを着替えても壊れないか」。この問いに自信を持って「はい」と言えないなら、あなたのサイトは見た目以上に特定の道具へ依存しています。本記事は、その依存を見えるようにし、向き合い方を整理するためのものです。
この記事はこんな人へ
- WordPressは一通り使えるが、「拡張性」「移植性」を意識したことがない
- 有料テーマやページビルダーで制作しているが、乗り換えを考えると不安がある
functions.phpに少しずつ機能を足してきた自覚がある- 「ノーコードでここまでできた」という成功体験の“次”を探している
- 自分のWordPress理解を、一度俯瞰から点検し直したい
よくある認識（近視眼モデル）
- WordPress = 「テーマを選んでブロックを並べれば完成するツール」
- ノーコード = 「コードを書かないから、技術的負債とは無縁」
- 有料テーマ = 「機能もデザインも全部入りだから、これ一つで安心」
- ページビルダー = 「自由にレイアウトできる＝拡張性が高い」
- 「動いている」=「正しく設計されている」
これらは間違いではありません。むしろ、立ち上げ段階では正しい判断です。問題は、この認識がサイトの“その後”を語っていないことです。近視眼モデルは「今、表示されているか」しか見ていません。俯瞰モデルは「3年後、道具を替えても残るか」を見ます。
「ノーコード」は本当にノーコードか
「ノーコード」という言葉は、しばしば「コードが存在しない」と誤読されます。実際には、コードを“あなたが書かない”だけで、コードは確実に存在しています。ページビルダーが吐き出すHTML、テーマ独自ブロックが生成するマークアップ、設定画面の裏で動くPHP——それらはすべてコードです。あなたが直接触れないだけで、消えてはいません。
そして重要なのは、そのコードの“仕様”を決めているのは、あなたではなくツールのベンダーだという点です。独自ブロックが生成するクラス名、ショートコードの記法、ビルダー固有のラッパー構造。これらはツールが定義したルールであり、ツールを外せば意味を失います。つまり「ノーコード」とは、「コードを書かない自由」と引き換えに、「コードの仕様を他者に委ねる」状態でもあるのです。
念のため明確にしておきます。これはノーコードを否定する話ではありません。撃つべきは「ノーコードだから後腐れなく完成する」という売り文句のほうであって、ツールでも、それを使う人でもありません。
WordPressを縛る3つの依存
WordPressを長く運用すると、次の3つの依存が重なって効いてきます。それぞれ単独では小さくても、絡み合うと「動いているのに身動きが取れない」状態を生みます。
| 依存 | よくある状態 | 俯瞰で見えるリスク |
|---|---|---|
| ノーコード依存 | ビルダー・独自ブロックで本文を組み、記法がツール固有になっている | ツールを外すと本文の構造（マークアップ）が壊れる。コンテンツとツールが癒着 |
| テーマ依存 | 機能を functions.php や独自ブロックに置き、テーマがサイトの“中身”を握っている | テーマを替える＝機能が消える。テーマ更新も怖くて止まる |
| ベンダーロックイン | 特定の有料テーマ／ビルダー前提でサイト全体が成立している | 提供終了・方針変更・互換性切れで、サイトごと人質に取られる |
テーマ依存の具体例
「見た目はテーマ、機能はプラグイン」というのがWordPressの設計原則です。テーマは“着せ替え”を前提に作られています。ところが実運用では、この境界が次のように崩れがちです。
functions.phpに機能を置いている：問い合わせ後の処理、カスタム投稿タイプの定義、独自ショートコード登録などを書いている。これらは「機能」なので本来プラグイン（または mu-plugin）の領分。テーマを替えた瞬間、まとめて消えます。- 独自ショートコード・独自ブロックで本文を作っている：テーマを外すと、ショートコードはただの文字列として露出し、独自ブロックは「無効なブロック」になります。
- 子テーマ無しで親テーマを直接改変している：テーマ更新で上書きされ、変更が消える。結果、「更新できないテーマ」が出来上がります。
- マルチパーパステーマの肥大：スライダー・ポートフォリオ・独自ブロック・SEO機能まで内蔵し、テーマ＝サイトという不可分の塊になります。
ベンダーロックインの実例（WEB先案内メモ）
これは当サイト自身の経験です。WEB先案内ITブログは、以前テーマ「JIN:R」を使っていました。JIN:Rは優れたテーマで、独自ブロックによってデザイン性の高い記事を素早く作れました。ここに不満はありません。
問題は、テーマを別のものへ移行したときに起きました。JIN:Rの独自ブロックで作っていた装飾要素（ボックスやボタンなど）が、テーマを外した途端に崩れたのです。理由は明快で、それらの見た目はJIN:Rが提供するCSSとブロック定義に依存していたから。テーマがなくなれば、その見た目を支える土台ごと消えます。
これはJIN:Rの欠陥ではありません。独自ブロックという仕組みの性質であり、どの「独自ブロックを持つテーマ」でも同じことが起こり得ます。私たちはこの一件で、「テーマに依存した本文は、テーマと運命を共にする」という原則を、身をもって学びました。
具体シナリオ① ビルダー製サイトをテーマ移行したら本文レイアウトが崩壊した
何が起きたか：ある制作会社が、ページビルダーで全ページを組んだコーポレートサイトを納品。数年後、デザイン刷新のためテーマを入れ替えようとしたところ、本文がレイアウトを再現できず崩れました。
なぜ起きたか：ビルダーは、レイアウト情報を独自のラッパー構造やショートコード、メタデータとして保存します。その見た目を成立させるCSS・JSはビルダー側が供給しています。ビルダーを外す＝レイアウトの“設計図と部品”を同時に失う、ということです。
俯瞰での教訓：レイアウトの自由度と移植性は、しばしばトレードオフの関係にあります。長期運用するサイトでは、「このレイアウトは、ツールを外しても意味のあるマークアップとして残るか」を制作時に問うべきでした。
具体シナリオ② functions.php に機能を盛り続けてテーマ更新できなくなった
何が起きたか：運用しながら少しずつ便利機能を functions.php に書き足した結果、テーマにセキュリティ更新が来たとき「更新したら何が壊れるか分からない」と更新を止めてしまいました。
なぜ起きたか：functions.php は本来テーマの一部であり、テーマの寿命に縛られます。そこへ「機能」を集積させた結果、テーマと機能が分離不能になりました。
俯瞰での教訓：機能は mu-plugin か通常プラグインに置く——これだけで、テーマと機能は独立して更新・交換できます。functions.php は「このテーマ固有の見た目調整」に留めるのが、関心の分離にかなった使い方です。
判断軸チェック：あなたのサイトは「着替え可能」か
頭の中でいいので、テーマを一時的にデフォルトテーマへ切り替えたと想像してください。
- 本文が崩れる → 独自記法（独自ブロック・ショートコード・ビルダー）への依存があります。
- 機能が消える（フォーム処理・カスタム投稿・独自処理が動かない） → 機能がテーマに紛れています。
- どちらも無事（見た目だけ素朴になる） → 移植性◎。正しく「着替え可能」に設計されています。
俯瞰で見ると：関心の分離・標準・移植性
ここまで見てきた依存は、突き詰めると一つの設計原則の欠如に行き着きます。関心の分離です。見た目（テーマ）・機能（プラグイン）・コンテンツ（投稿データ）は、それぞれ独立して交換できるべきもの。これらが癒着するほど、サイトは硬直し、特定の道具に縛られます。
テーマは着替え可能でなければならない。着替えたら機能や本文が壊れるなら、それは設計が間違っている。
標準（コアブロック、標準のフック、テーマとプラグインの役割分担）に寄せるほど、サイトは特定ベンダーから自由になり、移植性が上がります。
では、どう向き合うか（3つの判断軸）
- 移植性：「このサイトは、テーマを替えても本文と機能が生き残るか」を常に問う。本文はできるだけコアブロックで、独自記法は“崩れても惜しくない装飾”に限定する。
- 関心の分離：見た目はテーマ、機能はプラグイン（または mu-plugin）。
functions.phpに機能を溜めない。 - 標準：迷ったらWordPress標準に寄せる。標準は「最も多くの環境で動き、最も長く生き残る」選択肢です。
ノーコード・有料テーマの正当な価値も忘れない
公平に言います。ノーコードと有料テーマには、明確で正当な価値があります。立ち上げの速度、非エンジニアの自走、受託の納期、デザイン自由度——これらは本物の価値です。本記事の主張は「ノーコードを使うな」ではなく、「ノーコードで“完成”したと思い込むな」です。便利さを享受しながら、同時に「いま自分はどの依存を選んでいるか」を俯瞰で把握している——それが、道具を使いこなす中級者から、構造を理解する上級者への分岐点です。
次に読む・関連記事
- 次の講義 → 講義2：性能を“構造”で見る
- 全体像 → WordPressはどう動いている？全体図／最新のWordPressの全体像（ハブ）
- 事例 → 更新して不具合が！でも大丈夫
- 実装 → 上級者ガイド 第8回 壊さないWordPress／第5回 DB事故と移転
不安なときは
「自分のサイトが着替え可能かどうか、正直よく分からない」——それで構いません。依存は悪ではなく、把握していないことだけがリスクです。テーマ更新が怖い・乗り換えに踏み切れない・独自ブロックだらけで身動きが取れない、といった不安があるなら、WordPress保守・更新サポートで現状を一緒に点検できます。まず「いま、どこに縛られているか」を知るところから始めましょう。
情報確認日：2026年5月29日
