SWELLをカスタマイズする前に｜購入テーマを活かす改修と独自制作の選び方

「SWELLだから、このカスタマイズはできないのでしょうか」。改修を考えるとき、テーマの名前によってできることの範囲が決まっているように感じるかもしれません。grandworkでは、まずテーマの構成と、実現したい内容を確認するところから始めます。標準の設定に項目がなくても、開発すれば対応できることはあります。

SWELLでも、Welcart向けのテーマでも、構成や設計の考え方を理解したうえで手を入れるなら、改修の選択肢は広がります。ただ、そこで考えておきたいのが、「できるか」だけでなく、「そのテーマを使って、そこまで作り込むべきか」という点です。実装する人の技術や理解度だけでなく、初期費用、制作期間、公開後の更新まで含めて判断します。

購入テーマを使う利点は、制作の手間や時間を減らせること

テーマを買う意味は、デザインや編集機能など、すでに作り込まれた部分をそのまま使えることにあります。ゼロから作る範囲が減れば、費用だけでなく、必要な人手や公開までの時間も抑えやすくなります。広く使われているテーマの中には、デザインから編集のしやすさまで、よく考えて作られているものがある。当社でもそう感じています。

反対に、元のレイアウトや編集方法をほとんど使わず、主要な処理まで置き換えるのであれば、テーマを買って省ける部分はあまり残りません。見た目を合わせるための追加コードに加えて、元の機能との調整や、アップデートのたびの修正が必要になることもあります。

譲れない要件と、テーマに合わせられる部分を決める

たとえば、問い合わせで受け取る情報や業務システムとの連携は、見た目の好みのようには妥協できません。一方で、見出しの装飾や細かな動きなら、テーマの標準に合わせても目的は果たせることがあります。サイトの目的に関わる機能は譲らない。テーマに合わせても困らない部分はどこか。これを先に決めておくと、制作が進めやすくなります。

独自制作は、自社で行っても外注しても構いません。当社では、テーマの標準機能を使わないようにするための改修が増えていくなら、初期費用が多少上がっても、必要なものを独自に作ったほうが長い目で見てよい、と判断することがあります。どちらが安く済むかは、テーマの購入価格だけでは決まりません。

テーマを活かして作る方向で考えている場合は、当社のテンプレートプランも見てみてください。業種別のデモを見ながら、そのまま使いたい部分と変えたい部分を考えておくと、ご相談の際に希望を伝えやすくなります。

カスタマイズの前に、テーマの仕組みを把握する

カスタマイズに必要なのは、見た目を変える技術だけではありません。どこで画面が組み立てられ、機能同士がどう関わっているのかを、コードから読み取る力も要ります。テーマ名だけで限界を決めつけず、対象のバージョンと実際の構成を調べます。

• テーマの構成と設計思想テンプレート、ブロック、設定がどう関係しているかを確認し、テーマが用意している拡張方法を使えるかを調べます。
• キャッシュと表示の更新テーマやプラグインのキャッシュが何を保存し、どんな変更で作り直されるのかを確認します。管理画面で保存した変更が、訪問者の画面にも反映されているかも見ます。
• 必要なプラグインと依存関係それぞれ何のために入っていて、止めると何が変わるのかを整理します。本数の多い少ないではなく、本当に必要な機能か、動作を重くしていないかで見ます。
• 管理画面と更新への影響公開画面だけでなく、編集画面での操作や保存も確認します。テーマを更新したときに影響を受ける箇所と、それを確認する担当者を決めておきます。

これまで見てきた中では、見栄えのよい購入テーマでも、管理画面が重くなったり、目的に対して不要なプラグインをたくさん抱えた構成になっていたりすることがありました。そのため当社では、ThemeForestで販売されているテーマを、見た目だけで選ぶ候補として積極的には勧めていません。もちろん、販売されているテーマすべてに同じ問題があるわけではないので、採用する前に、個々のテーマと実際に使う機能を確かめるようにしています。

AIエージェントと協働しても、設計を判断する知識は必要

カスタマイズといっても、すべて一人でコードを書く必要はありません。今は、既存コードの調査や修正案づくり、テストの実行をAIエージェントに手伝ってもらう方法もあります。当社でもAIと一緒に作業するようになってから、改修案を試したり、別のやり方と比べたりするのが以前より楽になったと感じています。どれくらい作業を短縮できるかは、サイトの構成や、AIにどこまで情報を渡せるかによって変わります。

ただ、希望どおりの画面になってエラーも出ていないからといって、よい改修だとは限りません。既存の仕組みを使わずに似た処理を増やしていたり、データが少ないうちは問題がなくても、件数が増えると扱いにくい構成になっていたりすることがあります。「間違ってはいないが、このサイトには適していない」案を見分けることも必要になります。

• テーマに用意された仕組みを活かしているかテーマ側の仕組みを使っているか、同じ処理を二重に持っていないか、キャッシュやテーマの更新とぶつからないかを確認します。
• DB設計が、使い方とデータ量に合うかデータをどう保存し、どう関連付けて、どう検索するのかを確認します。たとえば顧客情報を複数の場所に重ねて保存する案なら、変更したときに同期が必要か、同じ顧客だと見分けられるかまで考えます。既存の投稿やメタ情報で足りるのか、専用のテーブルが必要なのかも、要件から判断します。
• 必要な操作までテストしているか「テストが通った」という結果だけでなく、何を試したのかを確かめます。権限の違い、入力ミス、実際に近いデータ量、既存機能への影響など、必要な条件がテストに入っているかを見ます。

たとえば、データを保存できることを確かめるテストが通っても、検索の使い勝手や、削除したときに関連データがどうなるかまで確かめたことにはなりません。AIには判断の理由や別の案、検証の結果を説明してもらい、それをコードや実際の動作と突き合わせます。AIが「問題ありません」と答えていても、最後はコードと動作を見て判断します。

GitHubも公式の説明で、Copilotのエージェントが出した結果は、正確で適切かどうかを利用者がレビュー・検証する必要があるとしています。公式説明の要約：GitHub「Application card: GitHub Copilot Agents」（2026年9月14日確認）。

すべての実装を覚えている必要はありません。求められるのは、提案の前提を質問できること、何を確認すべきかが分かること、どこから先は専門家に判断を任せるべきかを見分けられること。そのための基礎知識です。自分では判断が難しい部分は、詳しい担当者に確認してもらってください。AIを使えば作る速さは上がりますが、そのぶん、どの設計を採用し、どう確かめるかを選ぶ力が問われます。

「何を変えるか」を、画面と動作で説明する

たとえば「サービス紹介をもっと目立たせたい」という要望にも、文字を大きくするほか、掲載位置を上げる、説明を短くする、ボタンの行き先を分かりやすくする、といったやり方があります。要望をそのままCSSの修正に置き換える前に、読む人にどこを見てほしいのかを確認します。

1. 対象の画面を示す対象ページのURLと、変更したい箇所を示した画面を用意します。
2. 現在と希望の状態を書く今どうなっていて、どうしたいのかを短い文章で添えます。「スマートフォンでサービス名が3行になってしまうので、文字を削らずに読みやすくしたい」と書いてあれば、文字の大きさだけでなく、列数や余白を変える案も考えられます。

参考にしたいサイトがある場合も、「このページ」と全体を指定するより、どこを参考にしたいのかを絞ったほうが伝わります。写真の雰囲気なのか、メニューの動きなのかによって、調べることが変わるからです。なお、参考にするのは見せ方や動きで、他社の文章や画像をそのまま使うわけではありません。

標準設定とブロックで済むかを先に確かめる

SWELLには、サイト全体に効く共通設定と、投稿・固定ページごとの表示設定があります。公式マニュアルには、共通設定の表示をページごとに上書きできる項目が載っています。全ページを変えたいのか、一つのページだけ変えたいのかがはっきりすれば、調べる場所を絞れます。

公式設定の要約：SWELL「記事・固定ページごとに表示・非表示を設定できるパーツ一覧」。設定できる範囲は項目ごとに違うので、個別のページですべての設定を変えられるわけではありません。

本文内の紹介枠や案内は、既存のブロックを組み合わせて実現できる場合があります。公式の専用機能一覧を見て、実際の原稿を入れて試してから、足りない部分を整理します。使う機能は多ければよいというものではありません。日々編集する担当者にとって使いやすいかどうかも、同じくらい大事です。

この表は、改修の方法を考えるときの出発点にすぎず、ここに載せた方法でカスタマイズできる範囲が決まるわけではありません。会員機能や予約、外部システムとの連携などが必要なら、テーマ選びとは別に、機能と運用を検討します。

CSSの変更が、ほかのページにも影響しないか確かめる

一つの見出しの余白を直すつもりでも、すべての見出しに効く指定を書けば、ほかの記事の見出しまで変わってしまいます。対象のページやパーツを絞る、PCとスマートフォンで条件を分ける、変更前の状態を残しておく。この三つを押さえておく必要があります。

たとえば会社概要の表だけ列幅を調整したいのに、サイト内のすべての表に同じ指定を足すと、料金表や比較表まで崩れるかもしれません。対象の表だけを指定できる書き方を選び、同じパーツを使っている別のページも確認します。

WordPressには追加CSSを扱う仕組みがあり、公式の説明（要約）では、テーマのファイルを直接書き換えずにCSSを追加する方法として案内されています。ただし、CSSをどこに保存するかで影響範囲が限定されるわけではありません。書いた指定の中身は、やはり確認が必要です。参考：WordPress公式「CSS」。

変更履歴には「なぜ」を一緒に残す

• 変更の目的「余白を20pxに変更」とだけ書くより、「長いサービス名でもボタンと重ならないよう調整」と目的まで書いてあるほうが、あとで修正するときに判断しやすくなります。
• 対象と保存場所対象URLと、変更した設定やファイルを記録します。
• 確認条件と戻す方法確認した画面幅と、元へ戻す方法を残します。

この記録は、制作会社のためだけのものではありません。担当者が替わったとき、もう要らなくなったCSSを残しておくのか、標準設定に戻すのかを考える材料になります。小さな改修でも、どこに保存したのか分からない状態は避けてください。

子テーマを使っても、更新後の確認は必要になる

親テーマのファイルを直接編集すると、テーマを更新したときに変更が上書きされてしまうおそれがあります。WordPress公式も、元のテーマに手を加えずに拡張する方法として子テーマを紹介しています。参考：WordPress公式「Themes」。

制作会社から「子テーマで対応します」と説明されたら、何を変更するのか、更新のときにどのページを確認するのか、修正が必要になったらどう対応するのかも聞いておくと安心です。設定を変えるだけで済む部分まで、子テーマで作り込む必要があるとは限りません。

カスタム投稿は、入力と検索の要件から考える

事例や採用情報を、お知らせとは別の管理画面で登録したい。事例を地域や業種で探せるようにしたい。こうした要望では、見た目だけでなく、情報をどう保存するかも考える必要があります。

事例を数件載せるだけなら、通常の投稿とカテゴリーで十分に運用できるかもしれません。一方で、担当者に必ず入力してほしい項目が多く、専用の一覧や検索条件も必要になるなら、別の投稿形式や入力項目を設計する意味が出てきます。判断の目安は件数だけではありません。入力内容をそろえる必要があるか、検索が必要かも見ます。

将来テーマを変えたときに、登録した情報を引き継げるかどうかも確認しておきたいところです。どのプラグインやコードが情報を保存し、どこで画面に表示しているのかを記録しておけば、変更するときに一から調べ直さずに済みます。公開後に項目を追加する場合の作業についても、見積もりの段階で確認しておけます。

納品時には、実際に原稿を編集してみる

完成したら、指定した画面が表示されるかだけでなく、原稿が増えたとき、画像がないとき、見出しが長いときの表示も確認します。自社で更新していく予定なら、担当者が実際に一度編集してみて、プレビューで崩れがないかを見ておきます。

あわせて、カスタマイズした箇所に関わるテーマ更新を、誰が確認するのかも決めておきます。最初の制作費に、将来の修正や継続的な保守まで含まれているとは限りません。標準設定のまま維持する範囲、個別の改修として管理する範囲、公開後の相談先。この三つが分かっていれば、運用の見通しが立ちます。

当社にSWELLの改修をご相談いただく際は、対象のURLと現在の画面、どうしたいのかをお送りください。テーマを活かした改修で進めるのか、独自に作り込む案とも比べるのかを、今後の運用とあわせて整理します。