2026.08.26 2026.08.27

作業ログ：くろおび兄さんのうたⅠ ダウンロードページ制作（思考過程の記録）

ヤギハシ

ショーガック（正覚）

こんにちは！黒帯兄さんこと八木橋ショーガック（正覚）です。

TCD TREEテーマの固定ページに、ブロックエディターだけで特設ダウンロードページを作った時の記録です。今回は「きれいに完成しました！」だけでは終わらせず、実際にハマった失敗と、その原因究明の過程をそのまま記事にしました。同じTREEテーマや、同じような「ブロックエディターでLPを作る」場面で困っている方の参考になればと思います。

そもそもの発端

「くろおび兄さんのうたⅠ」というCDのダウンロードページを、固定ページ1枚で作ることになりました。デザインはヒーローセクション＋楽曲一覧＋ダウンロードボタンという、よくあるLP構成です。

普通に考えれば「カスタムHTMLブロックにHTML/CSSを流し込めば終わり」のはずでした。実際はそう単純にはいきませんでした。

第1のつまずき：ブロックの選び方

作業を始めてすぐ、「TinyMCE Advancedの『クラシック版の段落』はサポート終了に向けて移行中だから、『クラシック』ブロックの方がいいのでは」という声がありました。もっともな指摘だったので、素直に「クラシック」ブロック（TinyMCEのフルエディター）に切り替えました。

ところが保存してプレビューすると、<style>タグの中身がそのまま画面にテキストとして表示されているという、見るからにおかしな状態に。中身を調べてみると、<style>内の改行がすべて<br>タグに変換されていました。これでは当然CSSとして機能しません。

原因は単純で、クラシックブロックはコンテンツ全体がWordPressの自動整形処理（wpautop）を通ってしまうため、生のCSSやHTMLを書く用途にはそもそも向いていなかったのです。

そこで「カスタムHTML」ブロック（Gutenbergのコア機能。TinyMCE Advancedとは別物）に戻すことにしました。

TinyMCE Advanced（Advanced Editor Tools）

第2のつまずき：「カスタムHTMLだから安全」の思い込み

ところが話はそれで終わりませんでした。カスタムHTMLブロックに戻しても、まったく同じ混入によるCSS破壊が再発したのです。

「カスタムHTMLブロックはwpautopの影響を受けないはず」という一般的な理解が、このサイトでは通用しませんでした。編集画面に表示されていたページビルダー系プラグイン（Brizy、WPBakery）が怪しいと判断し、いったんそちらの設定確認をお願いすることにしました。

その後、別サイト（TCD TREEテーマ）で同じページを作り直すことになったのですが、そちらのサイトにはBrizyもWPBakeryも入っていないのに、まったく同じ現象が再発しました。つまり「ページビルダーが原因」という最初の仮説は的外れだったわけです。

実際に効いた対策

サーバー側の設定をいじれない以上、こちらでできることは一つ。<style>タグの中身の改行をすべて取り除いて1行に圧縮（minify）することでした。改行がなければ、そもそも<br>に変換されるものがない。これで初めてCSSが正しく機能するようになりました。

第3のつまずき：テンプレート選び

TREEテーマには「デザインページ1」「デザインページ2」といった専用テンプレートが用意されています。LP的なページなので試しに選んでみたところ、タイトル文字だけが小さく表示され、本文コンテンツが一切描画されないという状態に。

これは、これらのテンプレートが独自の表示エンジンを持っていて、通常のブロックエディターの中身（the_content()）を素通りしてしまう仕様だったためでした。結局、「デフォルトテンプレート」を選ぶのが正解でした。

第4のつまずき：フルブリード（画面幅いっぱい）表示

「本文を100%のワイド幅にしたい」というリクエストに対して、最初はCSSの定番テクニック（width:100vw; left:50%; margin-left:-50vw;）を使いました。ある画面幅では確かにうまくいったのですが、ウィンドウ幅を変えて確認すると、要素が右にずれて左側に大きな白い余白ができるという不具合が発生。

このテクニックは「親要素が画面中央に配置されている」という前提に依存しており、レスポンシブの境目でその前提が崩れていたのが原因でした。

そこで、getBoundingClientRect()で実際の位置を測定し、JavaScriptで動的に余白を調整する方式に切り替えました。エディターのプレビュー上では問題なく動いているように見えました。

第5のつまずき、そして真犯人の発覚

ページを公開する段階で、「Array」という謎の文字列が画面上部に表示されていることに気づきました。

最初は「テキストノードをJSで探して消せばいい」と考え、対策スクリプトを追加しましたが、まったく効果がありませんでした。

改めてDOM構造を調べたところ、驚くべきことが判明します。そもそも自分が追加した<script>タグが、ページのどこにも存在しなかったのです。

このサイトは、セキュリティ対策などの理由で<script>タグをサーバー側で自動的に除去する仕様になっており、しかもその除去処理自体にバグがあって、PHPの配列を文字列に変換した際によく起きる「Array」という文字列がその場に残されていたのでした。

そしてこれは同時に、もう一つの重大な事実を意味していました。第4のつまずきで「うまくいった」と思っていたJavaScriptによる幅100%化も、<script>ごと消されていたので、実は一度も実行されていなかったのです。実際に測定し直すと、ページはとっくに元の狭い幅に戻っていました。

最終的な対策

<script>タグを完全に廃止し、幅100%化は、実際にDOM調査で特定した本文ラッパー要素のID（#main_contents、#page_content）に対して、直接width:100%!importantを当てるという、CSSのみの方法に全面的に書き換えました。これで「Array」問題と幅の問題を同時に解決し、無事に公開できました。

おまけのつまずき：`!important`同士の競合

公開後、スマホの実機で確認すると「ダウンロード方法」の3カラムのステップ表示が、スマホなのに横に3つ並んだまま崩れている、という指摘をもらいました。

原因を辿ると、実は別の不具合（余分なタグがグリッドの子要素としてカウントされ、PCで3カラムが崩れる問題）を直すために追加した!importantが犯人でした。この!important付きの指定が、スマホ用メディアクエリ内の!importantなしの指定より常に優先されてしまい、スマホでも強制的に3カラムのままになっていたのです。

対策はシンプルで、モバイル用メディアクエリ側の同じプロパティにも!importantを追加して優先順位を揃えることでした。

この作業から得られた教訓

「直したはずの箇所」が、後の変更や別の環境要因で再発することがある。一度直っても油断しない。
エディター内プレビューでの見た目確認だけでは不十分。実際の公開URLで、実機相当の画面幅も含めて確認して初めて、「JavaScriptが実は一度も実行されていなかった」という重大な見落としに気づけた。
原因の当たりを一度つけても、別環境で再現しないことで仮説が誤りだと判明することがある。思い込みで進めず、都度DOM構造を直接調査し直す姿勢が最終的な解決につながった。
!importantを使うときは、対応するすべてのメディアクエリ側にも忘れずに揃えて付ける。片方だけに付けると、PCとスマホでどちらかが必ず壊れる。

同じTCD TREEテーマや、似たような環境でブロックエディターにHTML/CSSを直書きする方の、何かの参考になれば幸いです。