CMSの必須項目は「常に必須」でよいのか

条件付き必須・公開時必須・いずれか必須から考える入力ルール設計

CMSで入力項目を設計するとき、多くの場合は項目ごとに「必須」か「任意」かを決めます。

しかし、実際のWebサイト運用では、同じ項目が常に必須になるとは限りません。特定の選択肢を選んだときだけ必要になる項目もあれば、下書きでは空欄のまま保存できても、公開時には入力されていなければならない項目もあります。

こうした入力条件をすべて「必須」か「任意」かの二択で扱うと、入力できない画面や、必要な情報が抜けたまま公開できる画面が生まれます。

CMSの入力ルールは、項目単体ではなく、選択内容、コンテンツの状態、保存・公開などの操作と組み合わせて設計する必要があります。

この記事の要点

• CMSの必須条件には、常時必須だけでなく、条件付き必須、公開時必須、いずれか必須などがあります。
• すべてを必須にすると下書きや段階的な入力を妨げ、すべてを任意にすると公開時の入力漏れを防げません。
• 入力中、保存時、公開時、日時指定公開時のどこで検証するかを分けて考える必要があります。
• 頻出する入力ルールは、案件ごとの個別開発ではなく、管理可能な設定として扱うことで制作・保守の負担を抑えられます。
• 特殊な要件まで一律に設定化する必要はなく、共通化できる範囲と個別実装する範囲を分けることが重要です。

「必須」と「任意」だけでは表現できない入力条件

CMSに登録する情報は、コンテンツの種類や更新状況によって必要になる条件が変わります。

例えば、リンクを登録する入力画面で「CMS内のページ」「外部サイト」「ファイル」のいずれかを選択できるとします。

「外部サイト」を選んだ場合にはURLが必要ですが、「CMS内のページ」を選んだ場合にはURLは不要です。URLを常に必須にするとCMS内のページへリンクできず、任意にすると外部サイトを選んだままURLを入力せずに公開できてしまいます。

必要なのは、URLフィールドを単純に必須または任意にすることではありません。

リンク先の種類が「外部サイト」の場合に、URLを必須にする。

という、条件と入力項目を組み合わせたルールです。

実際のCMS運用で必要になる必須条件

入力ルールには、いくつかの代表的なパターンがあります。

条件付き必須

特定の項目が指定された場合に、関連する項目を必須にします。

例として、申込方法で「外部フォーム」を選択した場合だけ、外部フォームのURLを必須にするケースがあります。「電話受付」を選択した場合には電話番号、「メール受付」を選択した場合にはメールアドレスが必要になります。

入力項目の表示・非表示だけでなく、選択した方法に必要な情報がそろっているかまで確認する必要があります。

公開時必須

コンテンツの作成途中では空欄を許可し、公開するときだけ入力を必須にします。

担当者が複数いる運用では、一人の担当者が基本情報を入力して下書き保存し、別の担当者が確認情報や公開用の情報を追加することがあります。この場合、作成途中からすべての項目を必須にすると、下書きを保存できません。

一方、すべてを任意にすると、公開に必要な情報が不足したまま公開できてしまいます。下書き保存に必要な条件と、一般公開に必要な条件は分けて設計する必要があります。

いずれか必須

複数の項目のうち、少なくとも一つの入力を求めます。

問い合わせ先として電話番号、メールアドレス、問い合わせフォームのURLを用意し、いずれか一つが登録されていればよい場合、各項目を個別に必須にはできません。

必要なのは、それぞれの項目に必須設定を付けることではなく、項目の組み合わせを一つの入力条件として扱うことです。

組み合わせに対する制約

必須条件だけでなく、同時に入力してはいけない項目や、値の関係を確認する条件もあります。

例えば、CMS内のページと外部URLを同時に指定できないようにする、掲載終了日を掲載開始日より後の日付にする、チェック項目の選択数に上限を設けるといった条件です。

こうしたルールは、フィールド一つだけを見ても判断できません。複数の項目をまとめて検証する必要があります。

すべてを必須にすると入力できず、任意にすると漏れが起きる

入力条件を細かく設計しない場合、よく取られる方法は二つあります。

一つは、必要になる可能性がある項目をすべて必須にする方法です。入力漏れは減らせますが、使用しない項目にも入力が必要になり、仮の値や意味のない文字列が登録される原因になります。また、情報がそろう前の下書き保存も難しくなります。

もう一つは、入力を妨げないようにすべて任意にする方法です。更新担当者の自由度は上がりますが、公開時に本当に必要な情報がそろっているかをCMSでは保証できません。確認をマニュアルや担当者の注意に委ねることになります。

どちらか一方へ寄せるのではなく、どの状態で何が必要になるのかを入力ルールとして定義することが重要です。

入力中・保存時・公開時を分けて考える

入力ルールを決める際は、「何を確認するか」だけでなく、「いつ確認するか」も設計します。

入力中

選択内容に応じて項目を表示したり、必要な入力を案内したりする段階です。更新担当者が迷わず入力するための支援に当たります。

保存時

CMSへデータを保存してよいかを確認する段階です。保存時点で成立していなければならないデータの組み合わせや、入力形式を検証します。

公開時

一般公開してよい状態かを確認する段階です。下書きでは許容していた未入力を、公開時にはエラーとして扱う場合があります。

日時指定公開時

日時指定公開は、更新担当者が編集画面を開いていない状態で実行されることがあります。管理画面上のJavaScriptだけで入力を確認している場合、実際の公開処理では同じ条件が検証されない可能性があります。

公開時の必須条件を設けるなら、手動公開だけでなく、日時指定公開を含めた公開経路で適用されるかを確認する必要があります。

要件定義では入力ルールまで記載する

CMS要件定義書にフィールドの名称と形式だけを記載しても、実際の入力条件は伝わりません。

少なくとも、次の内容を整理します。

確認項目	決める内容
条件	どの選択や状態でルールを適用するか
対象	どの入力項目を表示・必須・禁止にするか
組み合わせ	すべて満たすのか、いずれかを満たせばよいのか
実行時点	入力中、保存時、公開時のどこで確認するか
エラー	何が不足しているかをどう伝えるか
既存データ	新しいルールを既存コンテンツへどう適用するか
公開経路	手動公開、日時指定公開などに同じ条件を適用するか

この対応関係が明示されていれば、実装方法を検討しやすくなり、テスト項目や運用マニュアルにも反映できます。

個別開発と設定をどう使い分けるか

条件付き必須や項目間の検証は、JavaScriptやCMSプラグインの個別開発でも実装できます。案件固有の特殊なUIや、他のシステムと連携する複雑な処理には、個別開発が適しています。

一方、条件付き必須、公開時必須、いずれか必須などは、多くのCMS案件で繰り返し発生する要件です。案件ごとに実装すると、要件が変わるたびにコードの調査、修正、影響確認、テストが必要になります。

頻出する入力ルールをCMSの管理画面から設定できれば、制作会社は案件固有のコードを増やさずに要件へ対応できます。運用開始後の変更も、個別実装の解析からではなく、現在の設定を確認するところから始められます。

重要なのは、すべてのカスタマイズを設定へ置き換えることではありません。

頻出する要件は共通の設定で扱い、特殊な要件だけを個別に実装する。

この境界を設けることで、CMSの柔軟性を維持しながら、制作と保守の負担を抑えられます。

複雑な入力ルールが不要な場合もある

入力項目が少なく、すべてのコンテンツで同じ条件を適用できる場合は、CMS標準の必須設定だけで十分です。

また、入力条件が一つだけで今後変更される可能性が低く、継続して保守できる体制がある場合は、個別のカスタマイズが合理的なこともあります。

入力ルールを増やすこと自体を目的にするのではなく、次の点から必要性を判断します。

• 選択内容によって必要な項目が変わるか
• 下書きと公開で必要な情報が異なるか
• 複数項目の組み合わせを確認する必要があるか
• 入力漏れが公開ページの不備につながるか
• 運用開始後に条件が変更される可能性があるか
• 個別実装を継続して保守できるか

Mixedでの考え方

Mixedでは、CMS案件で繰り返し発生する管理画面構造と入力ルールを、案件ごとの個別開発から共通の設定へ移すことを重視しています。

MyAdminPackでは、条件付き必須、公開時必須、いずれか必須、同時入力禁止、チェック数の上限・下限、日付の前後関係などを、CMSの管理画面から設定できます。入力中、保存時、公開時の判定を分け、更新パターンに応じた管理画面の構造と入力条件を組み合わせて設計します。

MyAdminPackは、自由なJavaScriptカスタマイズをすべて置き換えるものではありません。頻出する管理画面要件を標準化し、案件固有の実装を本当に必要な範囲へ絞るためのプラグインです。

まとめ

CMSの入力項目は、単純に「必須」か「任意」かを決めるだけでは、実際の運用に合わないことがあります。

選択内容、コンテンツの状態、複数項目の関係、保存・公開のタイミングを整理し、どの条件で何を求めるのかを入力ルールとして設計する必要があります。

すべてを必須にして入力を妨げるのでも、すべてを任意にして確認を担当者へ委ねるのでもなく、必要な場面で必要な条件をCMS側に持たせる。そのうえで、頻出する要件は設定として管理し、特殊な要件だけを個別実装することが、継続しやすいCMS運用につながります。