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を追加する手段が案内されています。ただし、どこへ保存するかだけで影響範囲が限定されるわけではありません。指定内容の確認は必要です。参考：WordPress公式「CSS」。

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

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

この記録は制作会社だけのためのものではありません。担当者が交代したとき、不要になったCSSを残し続けるか、標準設定へ戻すかを考える材料になります。少量の改修でも、保存場所が分からない状態は避けたいところです。

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

親テーマのファイルを直接編集すると、更新によって変更が上書きされるおそれがあります。WordPress公式は、元のテーマを変更せずに拡張する方法として子テーマを説明しています。参考：WordPress公式「Themes」。

依頼時には「子テーマで対応します」という説明に加えて、何を変更するのか、更新時にどのページを確認するのか、修正が必要になった場合の対応を聞いておくとよいでしょう。設定変更だけで済む部分まで、子テーマで作り込む必要があるとは限りません。

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

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

例えば事例を数件掲載するだけなら、通常の投稿とカテゴリーで運用できる可能性があります。一方、担当者に必ず入力してほしい項目が多く、専用の一覧や検索条件も必要なら、別の投稿形式や入力項目を設計する意味が出てきます。件数だけでなく、入力の統一と検索の必要性で判断します。

将来テーマを変更したときも、登録した情報を引き継げるかは確認しておきたい点です。どのプラグインやコードが情報を保存し、どこで画面に表示しているかを記録しておくと、変更時に調べ直す手間を減らせます。制作後に項目を追加する場合の作業も、見積もりの段階で確認できます。

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

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

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

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