4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ServiceNowのString型におけるMax Lengthの挙動を検証する

4
Posted at

ServiceNowで文字列を取り扱うときには、長さをどのように設計するか?に少しクセがあります。久々にアプリ開発を進めていくにあたって、改めて現行仕様を整理してみたいと思います。

検証環境

  • ServiceNowリリース:Australia Patch 1
  • UI:UI16
  • Diagnostics Pageに表示されたDatabase version:5.8.20-MariaDB
  • 検証日:2026年7月10日

考え方・違い

文字列長 <= 255

  • UI16 Formで開いた場合に単一行として表示される
    image.png

  • データベース上はVARCHAR型。

  • List画面ではGroup Byによるグルーピング対象、レポーティング機能でも円グラフ・棒グラフ等での分類項目として設定可能
    image.png

  • 少なくともUI16のForm/List上で直接入力する限り、設定した文字列長を超える入力は受け付けなかった

文字列長 >= 256

  • UI16 Formで開いた場合に複数行扱いで表示される
    image.png

  • データベース上はMEDIUMTEXT型。

  • List画面ではGroup Byによるグルーピング対象外、レポーティング機能でも円グラフ・棒グラフ等での分類項目として設定不可
    image.png

  • Form画面、List画面いずれでも、設定したMax Lengthを超える文字列を入力・保存できる

テーブル作成後の文字列長の変更

1.文字列長255以下での拡張・縮小

拡張

初期に文字列長40として作成した列に関して45文字に拡張してみます。
image.png

拡張結果がデータベースにも波及し、45文字でも保存できるようになりました。
image.png

縮小

公式ドキュメントでは、文字列ベースのデータ型間の変更は、切り捨てによるデータ損失が発生しない場合に限り可能とされています。

では40文字に戻してみます。40文字を超過しているデータが存在している、ということで変更が適用できませんでした。
image.png

対象となるデータを一旦削除・データパッチすることにより、文字列長の変更を適用できるようになります。

2.文字列長255以下から256以上への拡張

拡張

元々単一行だった項目が複数行で表示されるようになり、正常に動作します。
image.png

このとき、もしList画面で該当項目をGroup Byする条件が保存されていたり、該当項目を元にした円グラフが作成されていたらどうなるでしょうか?それらは利用できなくなってしまうのでしょうか?

今回の検証では、255以下のときに保存していたGroup By条件とレポートは、Max Lengthを256以上へ変更した後も実行できました。ただし、256以上の項目は新規のGroup Byやレポートの分類項目として選択できません。正式な利用対象ではない項目を、既存設定を経由して使い続ける設計は避けた方がよいと考えます。

image.png

縮小

先ほどと同様、設定する文字列長を超えるデータが存在していると変更を適用できません。

255以下に戻すと、再び単一行として表示されるようになりました。

文字列長256以上での拡張・縮小

拡張

特に問題なく拡張できます。

では、どこまで拡張できるのでしょうか?
2026/07/10時点での公式情報を確認すると以下の記述があります。

The maximum length of mediumtext is 16,777,215 bytes
Why ServiceNow fields accept string inputs that exceed the max_length value

テーブル定義情報を格納しているsys_dictionaryのMax Length項目はInt型で定義されているため、Int型の最大値である2,147,483,647が最大長のようです。一方で、MEDIUMTEXT型の最大バイト数の定義があるので、そちらの上限に先に到達します。
この検証を行うとPDIに負荷をかける可能性があるので実施しません。

縮小

文字列長256以上での縮小(例えば4,000→256など)は、そもそもUI上での入力制限という面では変わらないため、自由にできそうな気がします。
が、そんなことはありません。

500文字以上の文字列が格納されている列に対して、500文字への縮小を行おうとするとエラーとなり実行できません。これは推測ですが、255文字以下のVARCHAR型と、256文字以上のMEDIUMTEXT型を区別することなく、共通でのエラーチェック処理が入っているのではないかと思います。ただ、実際にはこの縮小を行ってもユーザー体験は全く変わらないため、そもそも実施する意味はあまりありません。
image.png

まとめ

ServiceNowのString項目は、Max Lengthが255以下か256以上かによって、UI上の表示形式やデータベース型のマッピング、Group By・レポートでの扱いが変わります。

実務上は、次の方針で考えるのがよさそうです。

  • コード、名称、分類値など、Group Byやレポートの集計軸として使用する項目は255以下にする
  • 申請理由、詳細説明、備考などの自由記述項目は256以上にする
  • 特に256以上のStringでは、DictionaryのMax Lengthを厳密な保存上限として扱わない
  • 文字数の上限を業務ルールとして厳密に保証する必要がある場合は、Dictionaryの設定だけに頼らず、別途バリデーションを実装する
  • 255/256の境界をまたぐ変更は、画面表示、DB型のマッピング、Group By、レポートでの利用可否に影響するため、できるだけ初期設計時に決めておく
  • 既存項目のMax Lengthを縮小する場合は、変更後の長さを超えるデータが存在しないことを事前に確認する

ServiceNowのString項目を設計する際は、「最大で何文字入力するか」だけでなく、その項目を分類・集計に使用する短い文字列として扱うのか、自由記述の長文として扱うのかを先に決めることが重要ですね!

基礎基本の内容でしたが改めて実検証を行うことで理解を深めることができました。

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?