--- title: "その WordPress サイト、なぜその作り方を選びましたか ?" canonical_url: "https://olein-design.com/blog/wordpress-design-and-client-agreement" language: "ja" date_published: "2026-10-29T15:43:49+09:00" date_modified: "2026-10-29T15:43:50+09:00" content_type: "post" author: "久野晃司" taxonomies: category: - "WordPress" --- # その WordPress サイト、なぜその作り方を選びましたか ? 「WordPress で作るので、お客さん自身で更新できます」 Web 制作の提案で使われる言葉ですが、この説明だけでは、編集できる範囲について同じ認識を持てているとは限りません。 例えば、サービス紹介ページを制作する場面を考えてみます。文章や画像を差し替えることはできるものの、説明のまとまりを増やしたり、新しい構成のページを作ったりするには、制作者への依頼が必要になる。そういう設計もあります。 その設計を選ぶことには、理由があるはずです。決まった構成を保ちたいのかもしれませんし、日々の更新で触る場所を絞りたいのかもしれません。 ただ、お客さんが「ページの構成も自分で変えられる」と考えていたら、公開後に認識の違いが表れます。 いま進めている案件で、お客さんが公開後に変更したい箇所を、一緒に操作しながら確認できているでしょうか。 僕は、WordPress の制作方法を考えるとき、それぞれの機能の役割と、その選択によってお客さんができるようになることを、セットで考えたいと思っています。 この記事では、Web 制作者や制作の進行を担当する方に向けて、WordPress の仕組みをどう選び、公開後の運用について何を共有しておきたいかを整理します。以下の設計例は、考え方を説明するための仮の例です。 ## 「更新できる」を、実際の操作まで具体的にする ひとことで「更新」といっても、作業の内容はかなり違います。 - 既存の文章を書き換える。 - 画像を差し替える。 - お知らせを追加する。 - 既存ページに説明や事例を追加する。 - 新しいサービスのページを作る。 - ページ内の順序やレイアウトを変える。 制作者は文章や画像の差し替えを想定していても、お客さんは新しいページの作成まで含めて考えているかもしれません。どちらも「更新できる」という言葉では説明できてしまいます。 **制作前に揃えたいのは、更新という言葉の意味ではなく、誰が、どの操作を、どこまで行うかです。** 「サービスページを更新したい」という要望なら、文章の修正だけなのか、事例を増やすのか、サービスごとに違う構成を作りたいのかまで聞いてみる。実際の作業を思い浮かべられるところまで話せると、必要な編集機能も見えてきます。 ## テンプレート、本文、カスタムフィールドの役割を分けて考える WordPress には、ページを表示するための仕組みも、内容を編集するための仕組みも用意されています。まずは、今回の設計判断に関わる役割を整理しておきます。 ### ページテンプレートは、表示する構造を決める仕組み テンプレートは、ページにどの情報をどのような構造で表示するかを定義するものです。WordPress の見た目や表示を担う「テーマ」の中で使われます。 主に PHP というプログラミング言語で表示を組み立てるクラシックテーマでは、例えば `page-service.php` のようなファイルを使って、特定の固定ページに合わせた表示を用意できます。どのテンプレートを使うかを決める「テンプレート階層」は、WordPress が標準で提供している仕組みです。 ページ固有のレイアウトをテンプレートに定義すること自体は、自然な実装方法です。共通の表示構造を制作者が管理したい場合にも、検討できる選択肢になります。 例えば、PHP テンプレート内で、対象の投稿や固定ページの本文を表示する `the_content()` を使えば、ブロックエディターで編集した本文を表示できます。**テンプレートを使うことと、本文をブロックエディターで編集できることは両立します。** ただし、`the_content()` が表示するのは本文です。テンプレートに直接記述した表示要素まで、本文の編集画面から変更できるようになるわけではありません。 [埋め込みコンテンツ](https://developer.wordpress.org/themes/classic-themes/basics/template-hierarchy/) [埋め込みコンテンツ](https://developer.wordpress.org/themes/classic-themes/basics/the-loop/) ### ブロックエディターは、本文の内容や構成を編集する仕組み ブロックエディターでは、見出し、段落、画像などを「ブロック」という単位で扱い、本文を組み立てます。 ブロックの組み合わせを再利用する「パターン」を用意すれば、毎回ゼロから構成を作る必要もありません。例えば、画像と説明文を組み合わせた紹介欄を、ページに挿入するためのひな型にできます。 編集範囲を調整する仕組みもあります。ブロックの移動や削除を制限するロックや、文章・画像などの内容の編集に操作を絞る設定が、その例です。 ただし、ロックの解除を誰に許可するかも含めた設定が必要です。ロックを付けるだけで、あらゆる変更を防げるわけではありません。 「構成を保ちながら内容を更新したい」という要件についても、ブロックエディターでどこまで実現できるかを検討する余地があります。 編集の自由度を最大にする必要はありません。担当者が行いたい作業と、制作者が管理する範囲に合わせて、使える操作を設計したいところです。 [埋め込みコンテンツ](https://wordpress.org/documentation/article/block-pattern/) [埋め込みコンテンツ](https://developer.wordpress.org/block-editor/how-to-guides/curating-the-editor-experience/block-locking/) ### カスタムフィールドは、投稿に付随する情報を扱う仕組み カスタムフィールドは、投稿や固定ページに付随する情報を保存する仕組みです。こうした情報を「メタデータ」と呼びます。 例えば、イベントの開催日や、商品の型番などです。本文の中で説明するだけでなく、個別の項目として扱いたい情報がある場合に候補になります。 ここで考えたいのは、画面の一部分に表示する情報だからといって、すべてカスタムフィールドで管理する必要があるのか、ということです。 会社紹介の見出し、説明文、画像を、それぞれ別の入力欄にする実装は可能です。ただ、その内容がページ本文を構成するためのものなら、僕はまずブロックエディターで管理する方法を検討したいと考えています。 本文とは別に管理する要件があれば、カスタムフィールドも候補になります。その理由を確認したうえで選びたい、ということです。 WordPress 公式の Developer Blog でも、投稿のメタデータと本文のどちらに保存するかについて、データを条件にして検索・抽出する必要があるか、その投稿の個別ページ以外でも表示するか、といった観点を挙げています。これは設計を考える手がかりであり、保存場所を一律に決めるルールではありません。 **本文を構成する情報なのか、構造化して独立した項目として扱いたい情報なのか。保存場所は、その役割から考えたいところです。** 例えば、開催日を使ってイベントを抽出するなら、日付を独立した項目として管理する理由になります。 一方、別の場所でも使いたいという理由だけで、カスタムフィールドに決める必要はありません。情報の性質と検索・抽出の要件に加えて、どこでどう使うか、担当者が編集しやすいか、将来の構成変更や保守で困らないかまで含めて判断します。 [埋め込みコンテンツ](https://wordpress.org/documentation/article/assign-custom-fields/) [埋め込みコンテンツ](https://developer.wordpress.org/news/2023/03/creating-a-custom-block-that-stores-post-meta/) ## 同じサービス紹介ページでも、運用が違えば設計は変わる ここからは、2つの仮の依頼を比べてみます。どちらも「サービス紹介ページを WordPress で作りたい」という要望ですが、公開後に行いたい作業が異なります。 ### 構成を保ち、文章と画像を更新したい場合 1つ目は、サービス紹介の構成がほぼ決まっていて、担当者は説明文と画像を更新したい、という依頼です。サービスが増えた場合も、同じ構成のページを追加できればよいとします。 この場合は、ページの共通構造をテンプレートで管理し、本文をブロックエディターで編集する方法が考えられます。新しいページには、決まったブロック構成を用意し、内容の編集に操作を絞る設定や、制限を解除できる人の設定を組み合わせます。 この例では、担当者は同じ構成のページを作り、文章と画像を変更できます。一方、ひな型の内部構造にあたる説明欄の追加・削除や並べ替えは、制作者が行う設計にします。新しいページを作れることと、その中の構成を変えられることを分けているわけです。 入力内容を決まった項目に限定する方が運用しやすい要件なら、専用の入力欄を用意する案も比較します。その際も、文章や画像を別々の欄へ分ける理由と、構成を変更するときに必要な作業を説明しておきたいです。 日常的に触る場所を絞れば、担当者は内容の更新に集中しやすくなります。その代わり、構成変更には制作者の作業と費用の確認が必要になる。この条件に双方が納得しているなら、編集範囲を絞る判断には意味があります。 ### 新しいページや説明のまとまりを社内で増やしたい場合 2つ目は、新しいサービスを継続的に追加し、サービスごとに事例や説明の数も変えたい、という依頼です。 この場合、既存の文章と画像を差し替えるだけの設計では、必要な作業を満たせません。ページを追加する操作に加えて、説明のまとまりを増やしたり、順序を変えたりする方法まで考える必要があります。 例えば、[非同期パターン](https://wordpress.org/documentation/article/block-pattern/)という、挿入後はそれぞれ独立して編集できるブロックのひな型を用意する方法があります。この例では、必要なブロックの追加や並べ替えを担当者に許可し、共通の構成から作り始めて、ページごとに説明や事例を増やせるようにします。 一方で、編集できる範囲を広げれば、担当者が判断することも増えます。使えるレイアウトをどこまで用意するか、どの操作を説明するか、公開前に誰が確認するかも、一緒に決めたいところです。 同じ種類のページでも、運用上の要件によって、必要な編集機能は変わります。 ## デザインを決める段階で、更新後の状態も考える こうした編集方法は、**デザインが完成してから初めて考えるより、デザインを検討する段階で共有できるとよい**と思います。 例えば、サービスの特徴を3つ並べたデザインがあるとします。公開後に4つへ増やす可能性はあるでしょうか。説明文が想定より長くなった場合はどう表示するでしょうか。画像を用意できない項目もあるでしょうか。 完成時の見た目だけでは、更新後の状態までは確認できません。 増減する要素や文章量の幅が分かれば、デザイナーは変化を受け止められる見た目を考えられます。実装者も、担当者がどこを操作できるようにするかを検討できます。 すべての変更を予測する必要はありません。**日常的に起こりそうな変更を、デザインと編集機能の両方に織り込むこと**が大切だと考えています。 ## 技術を選ぶ理由を、運用の言葉で共有する **運用上の要望を聞き取り、適した実装方法を判断して提案するのは、専門家である制作者の役割です。** そのうえで、選択した方法によって何を編集でき、何を制作者へ依頼することになるかを説明し、お客さんと運用方法に合意する。ここは分けて考えたいと思っています。 そのとき、「テンプレートにしますか、カスタムフィールドにしますか」と聞くだけでは、判断が難しいですよね。それぞれが公開後の作業にどう影響するのかを説明する必要があります。 例えば、次のように伝える方法があります。 「このページは文章と画像を社内で変更できます。説明欄の数や並び方は固定します。説明欄を増やす場合は、こちらで変更作業を行うので、別途ご相談ください」 あるいは、「用意したひな型を使って、新しいサービスページを作れます。説明欄の追加や並べ替えもできますが、公開前に担当者が見た目を確認してください」と説明することもできます。 お客さんに技術の選択を委ねるのではなく、実際の作業を想像できる説明にする。編集範囲と制約を理解してもらったうえで、役割分担や、どの変更から追加作業・費用が必要になるかを、制作前に確認しておきたいです。 ### 編集範囲は、操作ごとに書き出して確認する 下の表は、1つ目の事例に合わせた説明例です。担当者は構造が固定されたひな型でページを追加でき、その内部構造の変更や制限の解除は制作者が行う、という前提です。WordPress 一般の制約ではなく、この案件で設けた編集範囲を示しています。 | 操作 | この例での担当 | 共有しておく条件 | | --- | --- | --- | | 文章の修正、画像の差し替え | お客さん | 指定した編集箇所で行う | | 構造が固定されたひな型でのページ追加 | お客さん | 内部構造は変えず、内容を入力して公開前に表示を確認する | | ひな型内部の説明欄の追加・削除、順序の変更 | 制作者 | 作業内容と費用を確認してから依頼する | | 既存のひな型にないレイアウトの作成 | 制作者 | デザインと実装の変更範囲を確認する | 表を見せて終わりにせず、できれば**試作ページで操作を確認してもらいたい**です。担当者に文章の修正やページ追加を試してもらい、**予定している作業ができるか、制作者へ依頼する範囲を理解できているかを一緒に確かめます。**もし必要な作業を満たせないなら、制作を進める前に編集範囲や実装方法を見直します。 合意した編集範囲、役割分担、追加費用が生じる条件は、提案資料や操作手順書など、後から確認できる形に残します。金額を事前に決められない変更は、その都度見積もりを確認してから着手するなど、進め方を決めておきます。担当者が交代したときにも、どこまで社内で作業できるのかが分かる状態にしておきたいですね。 また、内容の更新と、WordPress 本体・テーマ・プラグインの更新などの保守は、担当を分けて確認します。文章を編集できることだけでは、保守の担当までは決まりません。追加改修と保守契約で扱う作業の違いも、共有しておく必要があります。 ## 次の案件では、予定している更新を1つ試してみる 今回の話を制作前の確認に使うなら、まず「公開後に、担当者が行いたい更新」を1つ挙げてもらうところから始めるとよいと思います。 その作業を想定したうえで、次の点を確認してみてください。 - 誰が、何を、どのくらいの頻度で変更するのか。 - 本文と、検索や再利用のために分けて管理したい情報を区別できているか。 - 選んだ実装方法で、予定している更新を行えるか。 - 担当者が行う作業と、制作者へ依頼する作業を説明できるか。 - 操作と公開前の確認方法を、担当者と一緒に試せるか。 - 編集範囲、役割分担、追加費用の扱いに合意し、記録できているか。 すでに運用しているサイトなら、まず契約資料や操作手順書と、現在の編集画面を照らし合わせるところまでは自分たちで確認できます。構成の変更など、試すと公開中のページに影響する操作は、テスト用の環境を用意して確認したいところです。 編集した内容が反映されない、必要な入力欄が見つからない、説明欄の追加にどこまで改修が必要か分からない。そうした場合は、まず制作担当者に、現在の編集範囲や操作方法を確認してみてください。設定や、機能を追加するプラグイン、テーマ側の実装まで調べる必要がある場合もあります。 相談前には、対象ページの URL、行いたい変更、現在の編集画面の画像、分かる範囲でのテーマやプラグインの情報を整理しておくと、状況を共有しやすくなります。 制作担当者への確認が難しい場合や、現状を整理しても改修の進め方が分からない場合は、オレインデザインにも[お問い合わせフォーム](https://olein-design.com/contact)からご相談ください。「このページで、この更新をしたい」という情報があれば、確認したい内容を具体的に共有できます。 僕は、本文の管理方法を含めて「なぜその作り方なのか」を説明できることを大切にしたいと考えています。そして、その説明を、お客さんが公開後の作業を判断し、運用方法に合意できるところまで届ける。次の制作案件で話し合うきっかけになれば嬉しいです。