モジュール単位で項目（フィールド）は何個まで追加できる？DB上限と実務ガイドライン

VtigerCRMCRM

VtigerCRM（オープンソース版）をカスタマイズして業務システムを構築する際、「顧客管理や案件管理にフィールド（カスタム項目）をどこまで増やせるのか？」 という疑問や、フィールド追加時にエラーが発生して困った経験はないでしょうか。

結論から言うと、「MySQL/InnoDBの仕様上の上限」 と 「実務運用・パフォーマンス上の推奨上限」 の2つの視点を理解して設計する必要があります。

本記事では、データベース（MySQL 8 / InnoDB）の制限を踏まえつつ、VtigerCRM 8.x における安全なフィールド設計ガイドラインと、エラー発生時の回避策を分かりやすく解説します。

1. 前提：VtigerCRMのカスタム項目はDBの「列追加」

VtigerCRMでは、管理画面の「レイアウトエディタ」等からカスタムフィールドを追加すると、データベース上ではモジュール専用の拡張テーブル（vtiger_<module>cf 例：vtiger_leadscf, vtiger_accountscf など）に カラム（列）として直接 ALTER TABLE 追加 されます。

そのため、項目数の上限は MySQL（InnoDB）のテーブル仕様制限 を直接受けることになります。

2. データベース側のハード制限（MySQL 8 / InnoDB）

カスタムフィールドを追加し続けた場合、以下の4つの制限に直面します。

制限項目上限値VtigerCRMにおける影響
(A) カラム数上限最大 1,017 列理論上の最大列数。ただし、これに達する前に別の制限（行サイズ）でエラーになります。
(B) 行サイズ上限最大 65,535 bytes【最重要】 1行あたりの定義合計バイト数上限。この制限を超えると「Row size too large」エラーが発生します。
(C) 文字コード（utf8mb4）最大 4 bytes / 文字近年の標準である utf8mb4 は1文字あたり最大4バイト計算になるため、VARCHAR(255) を多用すると行サイズを急速に消費します。
(D) インデックス接頭辞長最大 3,072 bytes検索対象としてインデックスを追加する際、複合キーや長い文字列列で引っかかる場合があります。

ポイント：

実際には「1,017個」追加できるわけではなく、utf8mb4 環境下での 65,535 バイト（行サイズ上限） が実質的な上限の壁となります。

3. 実務における推奨項目数ガイドライン（Vtiger 8.x 向け）

データベースのエラーが出ないとしても、1つのモジュールに大量のフィールドを詰め込むと、画面の描画遅延、入力ストレス、メンテナンス性の低下 を招きます。

実務上は以下の基準を目安に設計することを推奨します。

【推奨項目数の目安（1モジュールあたり）】

〜80項目       ： 快適運用（推奨）
81〜150項目    ： 許容範囲（ブロック分割などのレイアウト工夫が必要）
151〜250項目   ： 要リファクタ（子モジュール化やテーブル分割を検討）
251項目以上    ： 非推奨（設計見直し・別モジュールへの切り出しが必須）

UI・運用面のベストプラクティス

  • 一覧画面（ListView）： 表示列数は 8〜15列 程度に抑える（横スクロール過多を防ぐ）
  • 詳細・編集画面： 同時表示は 30〜60項目 を目安にし、アコーディオンブロックでの折りたたみや、関連タブ（子モジュール）への分散を検討する

4. なぜ「Picklist」や「文字列」を増やすと上限に達しやすいのか？

例えば、選択肢（Picklist）項目を追加した場合、内部的には VARCHAR(255) 等でカラムが作成されるケースがあります。

  • VARCHAR(255) × 4 bytes（utf8mb4） ≒ 約 1,020 bytes / 1カラム
  • 理論計算上、VARCHAR(255) だけを追加していくと 約60〜70項目 追加したあたりで 65,535 bytes の行サイズ上限に近づき始めます。

テキストエリア（TEXT型）や長文項目は行外（オフページ）に保管されるため行サイズ消費は少なくて済みますが、通常のテキスト項目やドロップダウンリストの乱立 は行サイズ枯渇の主な原因となります。

5. フィールド追加エラー（Row size too large）への対処法

もしレイアウト編集時に Row size too large や DDL 実行エラーが発生した場合、以下の優先順位で対策を検討してください。

①【最善策】使っていない項目の整理・削除

長年運用していると、使われなくなった古いカスタムフィールドが残っているケースが多々あります。不要な項目を削除し、テーブルの空き容量（バイト数）を確保します。

②【推奨】関連モジュール（1対1 / 1対多）へ切り出し

1つのモジュールに「基本情報」「契約情報」「保守情報」「アンケート回答」などをすべて詰め込んでいる場合、カスタムモジュール（例：契約詳細、ヒアリングシート等）を作成して関連タブで紐付ける 構成へ移行します。

③【応急処置・技術的対応】カラム型の見直し（文字数短縮）

すでに稼働中でリファクタリングが難しい場合の緊急対応として、DB側の vtiger_<module>cf テーブルで、サイズが過剰な VARCHAR(255) を VARCHAR(50) や VARCHAR(100) に縮小、または TEXT 型へ変更して行内バイト数を減らす方法があります。

(※DB直接変更を伴うため、バックアップを取り十分な検証の上で実施してください)

6. まとめ

  • VtigerCRMのカスタム項目はDBの列追加（ALTER TABLE）となるため、MySQLの行サイズ上限（65,535 bytes） が制約になる
  • utf8mb4環境では、VARCHAR(255) 形式の項目を多数追加すると数十〜100項目程度でも上限に近づく可能性がある
  • 運用品質・表示速度を保つためにも、1モジュールあたり80〜150項目以内 を目安に設計する
  • 項目が膨らむ場合は、1つのモジュールに抱え込まず カスタムモジュールを活用した分割・リレーション設計 を行う

CRM導入初期のテーブル設計段階からこの制限を考慮しておくことで、将来的な拡張エラーやパフォーマンス低下を防ぐことができます。

タイトルとURLをコピーしました