まず、どの作業が面倒なのかを書き出します
カスタマイズの相談は、画面の不満ではなく、実際に手間がかかっている更新作業を書き出すことから始めます。「編集画面が使いにくい」という伝え方では、制作会社も何を作ればよいか決められません。
面倒の種類を3つに分ける
更新作業の手間は、次の3つに分けると整理できます。
| 種類 | 例 |
|---|---|
| 毎回同じ組み立てを手作業で繰り返している | 見出しと画像と説明文の並びを、記事ごとに同じ手順で作っている |
| 入力してよい形が決まっているのに、自由に入力できてしまう | 日付や価格の書き方が担当者ごとに揺れる、画像の大きさが揃わない |
| 入力した結果が公開前に分からない | 編集画面では崩れていないのに、公開したら見た目が変わる |
1つ目は専用のブロックを用意する話、2つ目は入力の制約を付ける話、3つ目は編集画面での表示の確認の話になります。どの種類にあたるかが分かれば、相談の言葉が決まります。
1件の更新にかかる時間を測る
次に、実際にかかっている時間を測ります。感覚ではなく数字で持っておくと、費用をかける判断がしやすくなります。
- 普段の更新作業を1件、時計を見ながら行います (所要時間の目安: 計測そのものは1件分の作業時間だけです)
- 手が止まった箇所と、やり直した箇所をメモします (つまずきやすい点: 迷った時間は作業時間に含めてください。慣れている人の時間だけを測ると、実態より短く出ます)
- 月に何件の更新があるかを数え、合計の時間を出します
月あたりの合計が1時間に届かない作業であれば、カスタマイズの費用に見合わない場合があります。逆に、月に10時間を超えているなら、作る価値がある候補です。
書き出したものを優先順に並べる
最後に、書き出した作業を並べ替えます。並べる基準は2つです。
- 発生する回数が多いか (月に何件か)
- 間違いが起きたときの影響が大きいか (価格や日付の誤りは影響が大きい部分です)
回数が多く、間違いの影響が大きいものが最優先です。回数が少なく影響も小さいものは、カスタマイズせずに手順書を作るだけで足りることがあります。
この一覧が、そのまま相談の材料になります。制作会社に渡すのは、画面の不満ではなく、この一覧です。次のセクションでは、一覧のうちどこまでが変えられる範囲なのかを示します。
編集画面で変えられる部分と、変えにくい部分
入力の形を決める部分は比較的変えやすく、エディタ本体の動きに関わる部分は手間が大きくなります。前のセクションで作った一覧を、この区分に当てはめると、どれが現実的な依頼なのかが見えます。
比較的変えやすいもの
CMSが用意している仕組みの範囲で収まるものは、比較的短い期間で実現できます。
- よく使う構成を専用のブロックとして用意する
- 使わないブロックを編集画面から隠す
- 入力できる項目を限定する (選択式にする、文字数の上限を付ける)
- 画像の大きさや比率を自動でそろえる
- 公開前の確認の画面を、実際の表示に近づける
- 入力の順序を固定したひな形を用意する
これらは、CMSが拡張のために用意している仕組みを使う作業です。本体の動きには手を入れません。
手間が大きいもの
一方で、エディタ本体の動きに関わるものは手間が増えます。
| 依頼の内容 | 手間が大きい理由 |
|---|---|
| 文字の選択や貼り付けの挙動を変える | エディタ本体の処理に関わり、他の機能への影響を確かめる範囲が広くなります |
| 表の編集の操作を独自に作る | 表は選択と結合の処理が複雑で、環境による差も出ます |
| 共同編集や履歴の仕組みを足す | データの持ち方から変わります |
| 本体のバグを直す | 修正を本体に取り込んでもらうか、自社側で回避する判断が必要です |
最後の項目について、実際の例を挙げます。当社のエンジニアは、Meta社が開発するオープンソースのエディタ基盤 Lexical に修正を提供し、2件がマージされています。1件目 (PR #8218、2026年3月13日マージ) は、カーソル位置までスクロールする処理がCSSの scroll-padding を無視していたコアのバグ修正です。固定ヘッダを持つページでカーソルがヘッダの下に隠れる、という多くのサイトで起きる症状の原因でした。2件目 (PR #8215、2026年3月12日マージ) は、表の範囲選択中にマウスがブラウザウィンドウの外に出た場合のエッジケースに対するテスト追加です。いずれもPR番号から誰でも内容と差分を確認できます。
この2件が示しているのは、編集画面の違和感の原因が本体側にある場合があるという点です。その場合、個別のサイトで小細工をしても直らず、本体の処理まで追う作業になります。依頼の範囲を決めるときは、症状が自社の作り込みの問題か、使っている基盤の問題かを切り分けてもらってください。
既製のプラグインで足りる場合の見分け方
作る前に、既製の拡張で足りるかを確かめます。見分け方は次のとおりです。
- 実現したいことが、他社でも同じ形で必要になりそうかを考えます (必要になりそうなら既製の拡張がある可能性が高いです)
- 候補の拡張を探し、更新が続いているかを確かめます (つまずきやすい点: 数年更新されていない拡張は、CMSの更新で動かなくなる場合があります)
- 試しに導入して、自社の作業が実際に短くなるかを測ります (所要時間の目安: 候補2つの比較で半日程度)
既製の拡張で足りる場合は、作る費用が不要になります。足りないのは、自社の業務に固有の項目が入る場合、入力の制約が自社の規則に依存する場合です。自社でよく使う構成を専用のブロックにする作業は、まさにこの固有の部分にあたります。詳しくは後述します。
ブロックエディタで何を作るのか
ブロックエディタのカスタマイズは、自社でよく使う構成を専用のブロックとして用意する作業が中心になります。1から画面を作り替えるのではなく、使う部品を自社向けに差し替えていく形です。
専用のブロックを作る
専用のブロックとは、入力する項目があらかじめ決まっている部品です。たとえば次のようなものです。
| 作るブロックの例 | 入力する項目 |
|---|---|
| 料金の表 | プランの名前、金額、含まれるもの、注記 |
| 事例の紹介 | 業種、課題、実施したこと、担当者の一言、画像 |
| よくある質問 | 質問、回答 |
| 社内向けの注意書き | 本文 (公開はされず、編集画面でのみ表示します) |
| 問い合わせへの案内 | 見出し、説明文、ボタンの文言 |
担当者は、項目を埋めるだけで見た目が整った形で出力されます。前に挙げた「毎回同じ組み立てを手作業で繰り返している」という面倒が、ここで解消されます。
使わないブロックを隠す
次に、使わないブロックを編集画面から隠します。CMSの標準のブロックは数十種類あり、そのほとんどを自社では使いません。選択肢が多いほど、担当者は迷い、記事ごとに違う作りが混ざります。
隠す対象は、自社のデザインに合わない部品、使うと表示が崩れる部品、同じことが専用のブロックでできる部品です。つまずきやすい点は、隠しすぎることです。過去の記事で使われている部品を隠すと、その記事を編集したときに扱えなくなる場合があります。既存の記事で使われている部品を先に調べてから決めてください。
入力の制約を付ける
3つ目は、入力できる形を狭める作業です。
- 選択式にする (業種、カテゴリ、状態などは自由入力をやめます)
- 文字数の上限を付ける (見出しが折り返して崩れるのを防ぎます)
- 必須にする (画像の代替テキスト、公開日などの入れ忘れを防ぎます)
- 画像の大きさや比率をそろえる (アップロード時に自動で整える形にします)
- 日付や金額の書き方を1つに決める
これらは、担当者が複数いる場合に効きます。前に挙げた「入力してよい形が決まっているのに、自由に入力できてしまう」という面倒への対応です。
表示の確認を編集画面で行う
4つ目は、入力した結果を編集画面で確かめられるようにする作業です。専用のブロックを作る場合、編集画面でも公開後と近い見た目で表示する作りにできます。
ただし、完全に一致させることはできません。公開側の画面では、周囲の余白や画面幅、読み込むフォントの違いが出ます。実務的な落としどころは、専用のブロックの中の構成は編集画面で確認でき、全体の見た目は公開前の確認の画面で見る、という分担です。要件として伝えるときは、どちらの精度を求めるのかを決めておいてください。精度を上げるほど費用が増えます。
要件として伝える書き方
要件は、画面の見た目ではなく、入力する項目と入力した結果どう表示されるかの対応で書きます。見た目の指示から入ると、作った後に「思っていたものと違う」が起きやすくなります。
項目と表示の対応を表にする
専用のブロックを依頼する場合は、ブロックごとに次の形で書きます。
| 書く内容 | 例 (料金の表のブロック) |
|---|---|
| ブロックの名前 | 料金の表 |
| 入力する項目 | プランの名前、金額、含まれるもの (複数行)、注記 |
| 必須の項目 | プランの名前、金額 |
| 入力の形 | 金額は半角の数字のみ。注記は100文字まで |
| 表示のきまり | プランは入力した順に横並び。画面が狭い場合は縦に並ぶ |
| 繰り返しの上限 | プランは4つまで |
| 公開しない項目 | 社内向けのメモ (編集画面でのみ表示) |
この形で2つから3つのブロックを書いておけば、見積の前提が揃います。表示のきまりの欄は、デザインの指示ではなく、並び方と折り返しの挙動を書く欄です。色や余白は既存のデザインに合わせる前提で足ります。
現在の手順と、作ってほしい手順を並べる
もう1つ有効な書き方は、作業の手順を前後で並べることです。
- 現在: 見出しを入れる、画像を貼る、説明文を入れる、余白を調整する、スマートフォンでの表示を確認して直す (所要時間 15分)
- 希望: 事例の紹介のブロックを選び、業種と課題と実施したことと画像を入れて終わり (所要時間 5分)
この形で書くと、何を自動化してほしいのかが1行で伝わります。前のセクションで測った時間が、ここで効いてきます。
RFPに書く場合の項目
発注先を複数から選ぶ場合は、提案依頼書 (RFP) の形にまとめます。実務解説資料が共通して挙げるRFPの記載項目は、プロジェクトの背景と目的、現状の課題、目標、システム要件と機能要件、非機能要件、納期とスケジュール、予算規模、選定基準と評価方法、提案書の提出条件、問い合わせ窓口です。機能要件は必須と希望を分けて書く形が挙げられています。
編集画面のカスタマイズの依頼では、このうち現状の課題と機能要件の欄が中心になります。現状の課題の欄に測った時間と件数を書き、機能要件の欄に先の表を入れる形です。
書き方の加減についても指摘があります。実務解説資料が共通して指摘する点として、要件を詳細に書きすぎると特定のベンダの仕様に引き寄せられるリスクがある一方、抽象的すぎると見積もりがベンダごとに大きくばらつくというトレードオフがあり、機能要件は何を実現したいかを中心に記述し、実現手段はベンダの提案に委ねる形式が推奨されています。
編集画面の依頼に当てはめると、「この拡張を使って実装してください」とは書かず、「この項目を入れたら、この並びで表示されるようにしてください」と書く形になります。実現の手段は提案に委ねる方が、既製の拡張で足りる場合の提案も受けられます。