やまやまブログDEVELOPMENT & BUSINESS JOURNAL
お問い合わせ

IT技術ブログ

社員が自分で更新できるCMSの設計。入力欄の切り方、プレビュー、下書きと承認、画像の自動リサイズ、更新マニュアルで「更新されなくなるサイト」を防ぐ

社員が自分で更新できるCMSを作るための設計をまとめました。自由入力を減らす入力欄の切り方、本番と同じ見た目のプレビュー、下書きと承認、画像の自動リサイズ、更新マニュアルの作り方を、実装例つきで。

公開日 最終更新日 by 津嘉山 洸

この記事の結論：社員が自分で更新できるCMSにするには、操作の説明を増やすより、間違えようのない入力画面を作る方が効きます。具体的には、①日付・分類・地域など値が決まっているものを本文から外して選ぶ欄にし、自由入力を本文だけに絞る、②公開前に本番と同じ見た目で確かめられるプレビューを用意する、③間違えると困る種類にだけ下書きと承認を入れる、④画像は元の写真を上げるだけで、表示用の大きさと形式がCMSか配信側で自動で作られるようにする、⑤入力欄の横の説明文と、1枚の更新マニュアルを用意する、の5つです。サイトの更新が止まる理由の多くは「怖くて触れない」「手間がかかる」ことなので、この2つを設計で取り除きます。

この記事は、ホームページを社内で更新したい中小企業の担当者と、そのCMSを組む制作者に向けた設計のまとめです。WordPressでもmicroCMSなどのヘッドレスCMSでも使える考え方として書き、製品ごとの設定は例として添えます。各製品の機能は、記事の最後に挙げた公式ドキュメントと照らし合わせています（2026年10月3日時点）。

サイトの更新が止まるのは、担当者が「崩すのが怖い」と「手間が多い」と感じるから

公開したあとに更新されなくなるサイトは、担当者のやる気より、更新の画面の作りに原因があることがほとんどです。CMSの設計で取り除くべきなのは、次の2種類のつまずきです。

つまずき 画面で起きていること 設計で取り除く方法
崩すのが怖い どこまで触ってよいか分からない。押すとすぐ公開される 触れる欄を限る。プレビューと下書きを用意する
手間が多い 写真を縮める、日付の書き方をそろえる、などを毎回手で行う 値は選ぶだけにする。画像は自動で縮める
誰に聞けばよいか分からない 作った人が社外にいて、質問の窓口がない マニュアルに連絡先と、よくある迷いを書く

この表の右の列を1つずつ実装していくのが、以下の各節です。

入力欄は、記事の種類ごとに分け、値が決まっているものは選ぶ欄にする

入力画面は「お知らせ」「導入事例」「スタッフ紹介」「よくある質問」のように更新する中身の種類ごとに分け、それぞれ必要な欄だけを並べます。1つの大きな本文の欄に何でも書かせる作りが、見た目のばらつきと迷いの元になります。

お知らせと導入事例を例にすると、欄の切り方は次のようになります。

種類 欄 欄の形 決めておくこと
お知らせ 題名 1行の文字（上限あり） 一覧で折り返さない文字数を上限にする
お知らせ 分類 選択（例：営業日・新サービス・メディア掲載） 新しい分類を足すのは管理者だけにする
お知らせ 掲載の終了日 日付（空欄も可） 過ぎたら一覧から自動で消す
お知らせ 本文 装飾を絞った文章の欄 見出しは2段階まで、文字色は使えなくする
導入事例 業種・地域 選択 一覧の絞り込みと同じ選択肢を使う
導入事例 困っていたこと・行ったこと・その後 3つの文章の欄 順番を画面で固定し、書く中身を欄の説明に書く
導入事例 写真 画像（複数・代わりの文字は必須） 掲載の許可を取った写真だけを上げる決まりを書く

自由入力を減らすと、担当者が書くことが減るだけでなく、一覧の絞り込みや並べ替えも作りやすくなります。たとえば「地域」を本文に書いてもらうと検索の絞り込みに使えませんが、選ぶ欄にすれば、そのまま「大阪」「兵庫」のような地域ごとの一覧ページを作れます。

製品の側でも、この切り方を支える機能があります。microCMSのテキストの欄は、必須・文字数の上限・正規表現による入力の制限・説明文を設定でき、リッチエディタは使えるツールバーのボタンを絞れます。WordPressでは、投稿の種類ごとにエディターで使えるブロックを絞ることができます。

functions.php（お知らせでは段落・見出し・画像・リストだけを使えるようにする例）php
add_filter( 'allowed_block_types_all', function ( $allowed, $context ) {
    if ( $context->post && $context->post->post_type === 'news' ) {
        return array( 'core/paragraph', 'core/heading', 'core/image', 'core/list' );
    }
    return $allowed;
}, 10, 2 );

写真のように、1枚ごとに許可の範囲まで記録したい中身の場合は、さらに欄が増えます。式場の写真を例にした欄の持ち方は、式場の写真を例にした、掲載の許可を記録する入力欄の設計で扱っています。

プレビューは、本番と同じテンプレートで、下書きのまま確かめられるようにする

プレビューは、公開ページと同じテンプレートで下書きを表示する専用の入口として作ります。管理画面の中の簡易な表示だけだと、スマホでどう折り返すか、一覧にどう並ぶかが分からず、担当者は結局「公開してから確かめる」ようになります。

  • WordPressは、標準のプレビューが本番と同じテーマで表示されるので、追加の作業はほぼいりません
  • ヘッドレスCMSは、開発側でプレビューの画面を作ります。microCMSの場合、管理画面の「画面プレビュー」に飛び先のURLを設定し、そこに埋め込まれたコンテンツのIDと下書き用の鍵（draftKey）を使って、表のサイトの側が下書きを取りに行きます
  • プレビューのページは検索に載らないようにし（noindex）、下書き用の鍵を含むURLを社外に送らない決まりにしておきます

プレビューには、スマホの幅で見るためのボタンか、スマホで開けるURLを用意しておくと親切です。更新担当の多くは、パソコンの管理画面で書き、閲覧者の多くはスマホで読むからです。

下書きと承認は、間違えると困る種類にだけ入れる

承認の流れは、料金・契約の条件・採用の条件のように、誤りが問題になる種類に限って入れます。全種類に入れると、承認する人が不在のあいだ更新がすべて止まり、「更新されないサイト」を自分で作ることになります。

種類 下書きの保存 公開の前の承認 理由
お知らせ・ブログ あり なし（担当者が公開） 早く出すことの方が大事。誤りはすぐ直せる
導入事例 あり あり 相手先の確認や写真の許可が絡む
料金・サービス内容 あり あり 誤りがそのまま契約の問題になる
採用情報 あり あり 労働条件の表示に誤りがあると困る

製品ごとの仕組みは次のとおりです。

  • WordPress：権限の段階（ロール）で分けます。「寄稿者」は記事を書けても公開できず、レビュー待ちとして提出し、「編集者」以上が公開します
  • microCMS：レビュー申請の機能があり、公開の前に申請し、指名したレビュアーが差分を見て承認すると公開されます。公式の説明では、すべての料金プランで使える機能です
  • Strapi：Draft & Publish を有効にすると、下書きと公開中の版が分かれ、公開の操作をするまで表に出ません

承認を入れる種類には、承認する人を2人以上決めておきます。1人だけだと、その人の休みがそのまま更新の止まる期間になります。

画像は元の写真を上げるだけにし、表示用の大きさと形式は自動で作る

更新担当には、スマホで撮った写真をそのまま上げてもらい、縮小・形式の変換・切り抜きはCMSか配信の側で自動で行います。画像を手で縮める作業を求めると、そこで更新が止まるか、重いままの写真が載って表示が遅くなります。

作り方 自動で行われること 気をつけること
WordPress 上げた画像から複数の大きさを作り、srcset で出し分ける。長い辺が2560pxを超える画像は自動で縮める テーマで使わない大きさまで作られるので、不要な大きさは止める
microCMSなどの画像API 画像のURLに幅や形式の指定を付けると、その大きさで返す 指定を付け忘れると元の大きさのまま配られる
静的なサイトのビルド（例：Astro） ビルドのときに幅ごとの画像を書き出す 画像が増えるとビルドの時間が延びる

画像APIを使う場合は、指定の付け忘れが起きないよう、テンプレートの側で必ず関数を通すようにします。

src/lib/cms-image.ts（microCMSの画像URLから srcset を作る例）ts
// 更新担当は元の写真を上げるだけ。幅ごとのWebPはURLの指定で受け取る
const WIDTHS = [480, 800, 1200];

export function cmsSrcset(url: string): string {
  return WIDTHS.map((w) => `${url}?w=${w}&fm=webp ${w}w`).join(', ');
}

export function cmsSrc(url: string, width = 800): string {
  return `${url}?w=${width}&fm=webp`;
}

切り抜きの位置がずれると困る写真（人物や商品）は、一覧のサムネイルの縦横比を1つに決め、その比率で見たときのプレビューを画面に出しておくと、担当者がその場で写真を選び直せます。画像の代わりの文字（alt）は、必須の欄にしておきます。

更新マニュアルは、入力欄の説明文と、1枚の手順書に分けて作る

マニュアルは、欄ごとの書き方をCMSの画面の中の説明文に書き、それ以外の流れと連絡先だけを1枚の手順書にまとめます。分厚いマニュアルは読まれず、画面を変えたときに直されないまま古くなります。

入力欄の説明文に書くこと：

  • その欄に書く中身の例（「導入前に困っていたことを、相手の言葉で2〜3文」など）
  • 書いてはいけないこと（個人名、許可を取っていない写真、未確定の日付）
  • 文字数の目安と、一覧でどう表示されるか

1枚の手順書に書くこと：

項目 書く中身
種類ごとの流れ 下書き → プレビュー → （承認） → 公開、の順と、どの画面のどのボタンか
公開したあとに見る所 スマホで公開ページを開き、一覧と詳細の両方に出たか
間違えて公開したとき 非公開に戻す操作と、誰に知らせるか
困ったときの連絡先 社内の担当と、制作を頼んだ会社の窓口
更新の目安 種類ごとに、どのくらいの間隔で見直すか

手順書の最後には、種類ごとの「最後に更新した日」を確かめる方法も書いておきます。CMSの一覧画面を更新日の順に並べるだけでも、止まっている種類がひと目で分かります。

作る前に、誰が何をどの頻度で更新するかの表を埋める

入力欄の設計は、更新する人と中身が決まっていないと始められません。制作を頼む前に、次の表を社内で埋めておくと、CMSの選び方も入力欄の切り方もそこから決まります。

種類 更新する人 頻度の見込み 承認する人 写真の有無
（例）お知らせ 総務の担当者 月に数回 なし ときどき
（例）導入事例 営業の担当者 四半期に1本 部門長 あり

株式会社bundlyzeでは中小企業のサイト制作とあわせて、業務システムを要件定義の段階から保守運用まで受け持っています。どちらも、使う人の手順から画面を組み立てる点は同じです。更新担当が迷わない入力画面までまとめて頼みたいときは、bundlyzeのホームページ制作からご相談ください。

設計の根拠にした製品の公式ドキュメント一覧（2026年10月3日に照合）

よくある質問

自由に書ける本文の欄は、まったく無くした方がよいですか？

無くす必要はありません。本文のような長い文章は自由に書ける欄に残し、その中で使える見出しの段階や装飾のボタンを絞ります。日付・分類・地域など、値が決まっているものを本文から外して専用の欄にするのが、崩れにくくするいちばんの近道です。

承認の流れは、すべての更新に入れるべきですか？

すべてに入れると、承認者が忙しいときに更新が止まります。料金や契約の条件、採用の条件など、間違えると困る情報を持つ種類だけに承認を入れ、お知らせのような軽い更新は担当者がそのまま公開できるようにするのが現実的です。

更新マニュアルは、紙やPDFで作った方がよいですか？

置き場所は、更新担当がすぐ開ける所なら形式は問いません。ただし、入力欄の横に出せる説明文はCMSの画面の中に書き、マニュアルには操作の流れと、困ったときの連絡先を書く、と役割を分けると、画面を変えたときの直し漏れが減ります。