configuration-validation

構成の検証

概要

構成の検証は、ServiceNow のデプロイメントの品質を維持し、エラーを防ぐために不可欠です。このスキルでは、カタログアイテム、ワークフロー、ビジネスルール、その他の構成をデプロイ前に検証する体系的な方法を学びます。

• どのような問題を解決しますか？ 構成エラー、依存関係の不足、参照切れをユーザーに影響したり本番環境の問題を引き起こしたりする前に検出します
• このスキルは誰が使うべきですか？ ServiceNow 構成の品質保証を担当する管理者、開発者、リリースマネージャー
• どのような成果が期待できますか？ 正しく動作する検証済みの構成、包括的なエラー検出、デプロイメントへの信頼

前提条件

• 必要な ServiceNow のロール：admin または特定の管理者ロール（catalog_admin、workflow_admin）
• 構成テーブル（sys_script、wf_workflow、sc_cat_item）への読み取りアクセス
• ServiceNow の構成タイプに関する理解
• 関連するスキル：admin/schema-discovery（構造の理解に役立ちます）

手順

ステップ 1：構成タイプの特定

検証が必要な構成のタイプを特定します。タイプごとに検証要件が異なります。

構成タイプとテーブル：

構成タイプ	テーブル	主な検証項目
カタログアイテム	sc_cat_item	変数、ワークフロー、価格
カタログ変数	item_option_new	タイプ、参照、選択肢
ワークフロー	wf_workflow	アクティビティ、遷移、条件
ビジネスルール	sys_script	スクリプト構文、条件、タイミング
UI ポリシー	sys_ui_policy	条件、アクション、トリガー
クライアントスクリプト	sys_script_client	スクリプト構文、タイプ、テーブル
スクリプトインクルード	sys_script_include	クライアントからの呼び出し可否、スコープ
ACL	sys_security_acl	条件、スクリプト、ロール

ステップ 2：カタログアイテムの検証

カタログアイテムの完全性、適切な構成、依存関係の動作を検証します。

MCP ツールを使用する場合：

Tool: SN-Validate-Configuration
Parameters:
  type: catalog_item
  sys_id: <catalog_item_sys_id>
  checks:
    - variables
    - workflows
    - pricing
    - approvals
    - fulfillment

REST API を使用する場合：

# Get catalog item details
GET /api/now/table/sc_cat_item/<sys_id>?sysparm_display_value=all

# Get associated variables
GET /api/now/table/item_option_new?sysparm_query=cat_item=<sys_id>&sysparm_fields=name,type,mandatory,reference,order

# Get associated workflows
GET /api/now/table/wf_workflow?sysparm_query=table=sc_req_item^published=true&sysparm_fields=name,sys_id

カタログアイテムの検証チェックリスト：

チェック項目	説明	重大度
有効ステータス	アイテムが有効で、表示されている	重大
カテゴリ	有効なカテゴリが割り当てられている	高
変数	必須の変数がすべて存在する	重大
変数の順序	変数に重複しない順序値が設定されている	中
変数の参照	参照フィールドが有効なテーブルを指している	重大
ワークフロー	フルフィルメントワークフローが存在し、公開されている	高
承認ルール	承認グループ／ユーザーが存在する	高
価格	価格と定期価格が有効である	中
短い説明	文字数制限内である	低
アイコン	有効なアイコンまたは画像がある	低

ステップ 3：変数の検証

カタログ変数の適切な構成と機能を検証します。

MCP ツールを使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: item_option_new
  query: cat_item=<catalog_item_sys_id>
  fields: name,question_text,type,mandatory,reference,order,variable_set

変数タイプの検証ルール：

タイプ	必須フィールド	よくあるエラー
1（はい／いいえ）	question_text	なし
5（選択ボックス）	question_text、choices	選択肢がない
6（1 行テキスト）	question_text、max_length	長さが過剰
8（参照）	question_text、reference	無効なテーブル参照
9（日付）	question_text	日付形式の問題
14（マクロ）	macro	マクロが見つからない
18（ルックアップ）	reference、lookup_table	テーブルの不一致
21（リストコレクター）	reference、list_table	リスト構成が無効

変数の選択肢を検証：

Tool: SN-Query-Table
Parameters:
  table_name: question_choice
  query: question=<variable_sys_id>
  fields: text,value,order

判断基準：

• タイプが 5（選択ボックス）で、選択肢がない場合 → エラー：選択肢がありません
• タイプが 8（参照）で、参照先テーブルが存在しない場合 → エラー：参照が無効です
• mandatory=true で、default_value が空の場合 → 警告：デフォルト値のない必須フィールドです

ステップ 4：ワークフローの検証

ワークフローの完全性、遷移の適切さ、行き止まりがないことを検証します。

MCP ツールを使用する場合：

Tool: SN-Validate-Configuration
Parameters:
  type: workflow
  sys_id: <workflow_sys_id>
  checks:
    - activities
    - transitions
    - conditions
    - end_states

REST API を使用する場合：

# Get workflow details
GET /api/now/table/wf_workflow/<sys_id>?sysparm_display_value=all

# Get workflow activities
GET /api/now/table/wf_activity?sysparm_query=workflow_version.workflow=<sys_id>&sysparm_fields=name,activity_definition,x,y

# Get workflow transitions
GET /api/now/table/wf_transition?sysparm_query=workflow_version.workflow=<sys_id>&sysparm_fields=from,to,condition

ワークフロー検証チェックリスト：

チェック項目	説明	重大度
公開済み	ワークフローが公開され、有効になっている	Critical
開始アクティビティ	Begin アクティビティがちょうど 1 つある	Critical
終了アクティビティ	End アクティビティが 1 つ以上ある	Critical
孤立したアクティビティ	すべてのアクティビティに入力遷移がある	High
行き止まりのアクティビティ	End を除くすべてのアクティビティに出力遷移がある	High
条件の網羅性	すべての分岐条件が網羅的である	High
アクティビティスクリプト	スクリプトの構文が有効である	Critical
タイムアウトハンドラー	長時間実行されるアクティビティにタイムアウトが設定されている	Medium
ロールバックアクティビティ	承認が却下された場合に適切に処理される	Medium

孤立したアクティビティを検出する：

Tool: SN-Query-Table
Parameters:
  table_name: wf_activity
  query: workflow_version.workflow=<sys_id>^activity_definition.name!=Begin
  fields: sys_id,name

# Then check each activity has incoming transition
Tool: SN-Query-Table
Parameters:
  table_name: wf_transition
  query: to=<activity_sys_id>
  fields: sys_id

ステップ 5：ビジネスルールの検証

ビジネスルールの設定、構文、パフォーマンスに関する考慮事項が適切であることを検証します。

MCP ツールを使用する場合：

Tool: SN-Validate-Configuration
Parameters:
  type: business_rule
  sys_id: <business_rule_sys_id>
  checks:
    - syntax
    - conditions
    - performance
    - scope

REST API を使用する場合：

# Get business rule details
GET /api/now/table/sys_script/<sys_id>?sysparm_fields=name,when,collection,active,script,filter_condition,order

ビジネスルール検証チェックリスト：

チェック項目	説明	重大度
有効	ルールが有効である	Info
テーブル	有効なテーブル参照である	Critical
実行タイミング	適切なタイミング（before／after／async）である	High
条件	フィルター条件が有効である	High
スクリプト構文	JavaScript エラーがない	Critical
Before での GlideRecord	before ルールでは GlideRecord の更新を避ける	High
Current.update()	before ルールでは使用を避ける（再帰が発生するため）	Critical
変更の確認	効率化のために .changes() を使用している	Medium
順序	適切な order 値である	Medium
スコープ	適切なアプリケーションスコープである	High

よくあるビジネスルールのアンチパターン：

// ANTI-PATTERN 1: current.update() in before rule
// Causes infinite recursion
(function executeRule(current, previous) {
  current.priority = 1;
  current.update(); // BAD! Remove this line
})(current, previous);

// ANTI-PATTERN 2: Unnecessary GlideRecord in before rule
(function executeRule(current, previous) {
  var gr = new GlideRecord('incident');
  gr.get(current.sys_id);
  gr.priority = 1;
  gr.update(); // BAD! Just set current.priority = 1
})(current, previous);

// ANTI-PATTERN 3: No changes() check
(function executeRule(current, previous) {
  // Runs on every update even if priority didn't change
  notifyPriorityChange(current.priority);
})(current, previous);

// CORRECT: Check if field changed
(function executeRule(current, previous) {
  if (current.priority.changes()) {
    notifyPriorityChange(current.priority);
  }
})(current, previous);

ステップ 6：UI ポリシーの検証

UI ポリシーの設定とアクションの完全性が適切であることを検証します。

MCP ツールを使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sys_ui_policy
  query: sys_id=<ui_policy_sys_id>
  fields: short_description,table,conditions,active,global,inherit

UI ポリシーのアクションを取得する：

Tool: SN-Query-Table
Parameters:
  table_name: sys_ui_policy_action
  query: ui_policy=<ui_policy_sys_id>
  fields: field,mandatory,visible,disabled

UI ポリシー検証チェックリスト：

チェック項目	説明	重大度
有効	ポリシーが有効である	Info
テーブル	有効なテーブル参照である	Critical
条件	条件が有効で、テスト可能である	High
アクションの存在	少なくとも 1 つのアクションが定義されている	High
フィールド参照	アクションのフィールドがテーブルに存在する	Critical
逆状態への対応	ポリシーが true と false の両方の状態に対応している	Medium
順序	同じフィールドに対して競合するポリシーがない	Medium

ステップ 7：スクリプトインクルードの検証

スクリプトインクルードの設定とアクセス性が適切であることを検証します。

MCP ツールを使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sys_script_include
  query: sys_id=<script_include_sys_id>
  fields: name,api_name,client_callable,access,active,script

スクリプトインクルード検証チェックリスト：

チェック項目	説明	重大度
有効	スクリプトインクルードが有効である	Info
名前の規約	命名規約に従っている	Medium
API 名	一意で説明的である	Medium
クライアント呼び出し可能	必要な場合に限る（セキュリティリスク）	High
構文	JavaScript の構文が有効である	Critical
Prototype パターン	適切なクラスパターンを使用している	Medium
ドキュメント	JSDoc コメントがある	Low
依存関係	参照されているスクリプトインクルードが存在する	High

ステップ 8：ACL の検証

アクセス制御リストのセキュリティ設定が適切であることを検証します。

MCP ツールを使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sys_security_acl
  query: name=incident
  fields: name,operation,type,active,condition,script,role

ACL 検証チェックリスト：

チェック項目	説明	重大度
有効	ACL が有効である	Info
操作	有効な操作タイプである	Critical
ロール	少なくとも 1 つのロールまたは条件がある	Critical
条件	条件式が有効である	High
スクリプト	使用されている場合、スクリプトが有効である	High
カバレッジ	すべての操作が対象になっている	Medium
継承	* ACL が適切に使用されている	Medium

ステップ 9：検証レポートの生成

すべての検証結果をまとめて、包括的なレポートを作成します。

検証レポートのテンプレート：

# Configuration Validation Report

## Summary
- Configuration: [Name]
- Type: [Catalog Item / Workflow / Business Rule]
- Date: [Date]
- Validator: [Name]

## Overall Status: [PASS / FAIL / WARNING]

## Detailed Findings

### Critical Issues (Must Fix)
1. [Issue description and remediation]
2. [Issue description and remediation]

### High Priority Issues (Should Fix)
1. [Issue description and remediation]

### Medium Priority Issues (Consider Fixing)
1. [Issue description and remediation]

### Low Priority Issues (Nice to Have)
1. [Issue description and remediation]

## Validation Details

### Component 1: [Name]
- Status: [PASS/FAIL]
- Checks Performed: [List]
- Issues Found: [List]

### Component 2: [Name]
- Status: [PASS/FAIL]
- Checks Performed: [List]
- Issues Found: [List]

## Recommendations
1. [Recommendation]
2. [Recommendation]

## Sign-off
- [ ] All critical issues resolved
- [ ] All high priority issues resolved or documented
- [ ] Configuration approved for deployment

ツールの使用方法

MCP ツール（Claude Code/Desktop）

ツール	目的	使用するタイミング
SN-Validate-Configuration	包括的な検証	主な検証ツール
SN-Query-Table	構成テーブルのクエリ	詳細な調査
SN-Get-Table-Schema	テーブル構造の把握	フィールド参照の検証

REST API（ChatGPT/Other）

エンドポイント	メソッド	目的
/api/now/table/sc_cat_item	GET	カタログ項目の検証
/api/now/table/item_option_new	GET	変数の検証
/api/now/table/wf_workflow	GET	ワークフローの検証
/api/now/table/sys_script	GET	ビジネスルールの検証
/api/now/table/sys_ui_policy	GET	UI ポリシーの検証
/api/now/table/sys_script_include	GET	スクリプトインクルードの検証
/api/now/table/sys_security_acl	GET	ACL の検証

ネイティブツール（Claude Code）

ツール	目的
Bash	検証スクリプトの実行
Read	検証テンプレートの読み取り

ベストプラクティス

• 昇格前に検証する： インスタンス間で移行する前に、必ず構成を検証します
• 自動検証を使用する： CI/CD パイプラインに自動検証を実装します
• 例外を文書化する： 受け入れた検証警告を文書化します
• データを使用してテストする： 空のレコードではなく、現実的なテストデータを使用して検証します
• 依存関係を相互参照する： 参照されているすべてのオブジェクトがターゲット環境に存在することを確認します
• バージョン管理： 更新セットのドキュメントとともに検証レポートを保管します
• ITIL との整合性： 変更管理プロセスの一環として検証を実施します

トラブルシューティング

よくある問題 1：検証で誤検知が発生する

症状： 実際には正常に動作する構成が、検証で問題として検出されます
原因： 検証ロジックが有効な構成をすべて考慮していません
解決策： 該当する検証ルールを確認し、例外処理を追加します

# Check if the "error" is actually valid
Tool: SN-Query-Table
Parameters:
  table_name: <relevant_table>
  query: sys_id=<object_sys_id>
  display_value: all

よくある問題 2：ターゲットインスタンスに依存関係が不足している

症状： 開発環境では動作する構成が、テスト環境や本番環境では検証に失敗します
原因： 依存関係が更新セットに含まれていません
解決策： sys_update_xml をクエリして、関連するすべてのレコードを特定します

Tool: SN-Query-Table
Parameters:
  table_name: sys_update_xml
  query: update_set=<update_set_sys_id>
  fields: type,target_name,name

よくある問題 3：スクリプトの構文エラーが検出されない

症状： 無効な JavaScript が検証を通過しますが、実行時に失敗します
原因： 基本的な構文チェックでは、すべての JavaScript エラーを検出できません
解決策： ServiceNow の構文チェッカーまたはバックグラウンドスクリプトのテストを使用します

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    try {
      eval('<script_content>');
      gs.info('Syntax check passed');
    } catch(e) {
      gs.error('Syntax error: ' + e.message);
    }

よくある問題 4：ワークフローの検証がタイムアウトする

症状： ワークフローの検証に時間がかかりすぎる、または失敗します
原因： アクティビティと遷移が多数ある複雑なワークフローです
解決策： 検証を小さな単位に分割します

# Validate activities separately
Tool: SN-Query-Table
Parameters:
  table_name: wf_activity
  query: workflow_version.workflow=<sys_id>
  limit: 50
  offset: 0

# Then transitions
Tool: SN-Query-Table
Parameters:
  table_name: wf_transition
  query: workflow_version.workflow=<sys_id>
  limit: 100

例

例 1：カタログ項目の完全な検証

# Step 1: Get catalog item details
Tool: SN-Query-Table
Parameters:
  table_name: sc_cat_item
  query: sys_id=abc123
  fields: name,short_description,active,category,workflow
  display_value: all

# Result:
name: "New Laptop Request"
active: true
category: "Hardware"
workflow: "Standard Laptop Fulfillment"

# Step 2: Validate variables
Tool: SN-Query-Table
Parameters:
  table_name: item_option_new
  query: cat_item=abc123
  fields: name,question_text,type,mandatory,reference,order

# Result:
- laptop_type (Select Box, mandatory) - OK
- memory_size (Select Box) - OK
- justification (Multi-line, mandatory) - OK
- manager_approval (Reference to sys_user) - OK

# Step 3: Validate variable choices exist
Tool: SN-Query-Table
Parameters:
  table_name: question_choice
  query: question.cat_item=abc123
  fields: question.name,text,value

# Result:
laptop_type choices: Standard, Developer, Executive - OK
memory_size choices: 8GB, 16GB, 32GB - OK

# Step 4: Validate workflow exists and is published
Tool: SN-Query-Table
Parameters:
  table_name: wf_workflow
  query: name=Standard Laptop Fulfillment
  fields: name,published,active

# Result:
published: true
active: true - OK

# Final Status: PASS - All validations passed

例 2：ビジネスルールのパフォーマンス検証

# Step 1: Get business rule
Tool: SN-Query-Table
Parameters:
  table_name: sys_script
  query: name=Auto Assign Critical Incidents
  fields: name,when,collection,active,script,filter_condition

# Result:
name: "Auto Assign Critical Incidents"
when: "before"
collection: "incident"
filter_condition: "priority=1"
script: (see below)

# Step 2: Analyze script for anti-patterns
Script Content:
```javascript
(function executeRule(current, previous) {
  var gr = new GlideRecord('sys_user_group');
  gr.addQuery('name', 'Critical Incident Team');
  gr.query();
  if (gr.next()) {
    current.assignment_group = gr.sys_id;
  }

  // ISSUE FOUND: GlideRecord query in before rule
  // This runs on EVERY insert of P1 incident
})(current, previous);

Step 3: 推奨事項の生成

検出された問題：

1. WARNING: before ルール内の GlideRecord クエリ
   • 影響：インシデント作成時のパフォーマンス低下
   • 推奨事項：グループの sys_id をシステムプロパティにキャッシュするか、gs.getProperty() を使用します

推奨される修正：

(function executeRule(current, previous) {
  // Use cached value instead of query
  var criticalTeamId = gs.getProperty('x_app.critical_team_sys_id');
  if (criticalTeamId) {
    current.assignment_group = criticalTeamId;
  }
})(current, previous);

最終ステータス：WARNING - パフォーマンスの問題が検出されました

### Example 3: Workflow Dead-End Detection

Step 1: ワークフローアクティビティの取得

ツール：SN-Query-Table パラメーター： table_name: wf_activity query: workflow_version.workflow=wf123 fields: sys_id,name,activity_definition.name

結果：

• act1: 開始
• act2: タスクの作成
• act3: 承認
• act4: 承認された場合（分岐）
• act5: リクエストの履行
• act6: 終了
• act7: 拒否メールの送信

Step 2: すべての遷移の取得

ツール：SN-Query-Table パラメーター： table_name: wf_transition query: workflow_version.workflow=wf123 fields: from.name,to.name,condition

結果：

• 開始 -> タスクの作成
• タスクの作成 -> 承認
• 承認 -> 承認された場合
• 承認された場合 -> リクエストの履行（条件：承認済み）
• 承認された場合 -> 拒否メールの送信（条件：拒否）
• リクエストの履行 -> 終了

ステップ 3：問題を分析する

問題が見つかりました：行き止まりのアクティビティ

• 「Send Rejection Email」（act7）に出力先の遷移がありません
• そのため、拒否後にワークフローが停止します

推奨事項：

「Send Rejection Email」から「End」への遷移を追加してください

最終ステータス：失敗 — ワークフローに行き止まりのアクティビティがあります

### Example 4: ACL Coverage Validation

ステップ 1：テーブルのすべての ACL を取得する

ツール：SN-Query-Table パラメーター： table_name: sys_security_acl query: name=x_app_custom_table fields: name,operation,type,active,admin_overrides,role.name

結果：

• x_app_custom_table（読み取り） - ロール：x_app.user - 有効
• x_app_custom_table（書き込み） - ロール：x_app.admin - 有効
• x_app_custom_table（作成） - ロール：x_app.admin - 有効
• x_app_custom_table（削除） - ロール：x_app.admin - 有効
• x_app_custom_table.*（読み取り） - ロール：x_app.user - 有効

ステップ 2：カバレッジを分析する

対象の操作：

• read：はい
• write：はい
• create：はい
• delete：はい

フィールドレベル ACL：

• .（すべてのフィールド）：はい

ステップ 3：不足を確認する

問題が見つかりました：行レベルの制限がありません

• x_app.user ロールを持つすべてのユーザーが、すべてのレコードを読み取れます
• レコードレベルのセキュリティのため、条件の追加を検討してください

推奨事項：

レコードをユーザーごとに制限する場合は、次の条件を追加してください： created_by=javascript:gs.getUserID()

最終ステータス：警告 — 行レベルのセキュリティを検討してください

## Related Skills

- `admin/schema-discovery` - Understanding table structures for validation
- `admin/update-set-management` - Managing validated configurations
- `admin/batch-operations` - Fixing validation issues in bulk
- `admin/deployment-workflow` - Deploying validated configurations

## References

- [ServiceNow Instance Scan](https://docs.servicenow.com/bundle/utah-application-development/page/build/instance-scan/concept/instance-scan.html)
- [Catalog Item Best Practices](https://docs.servicenow.com/bundle/utah-servicenow-platform/page/product/service-catalog-management/concept/c_ServiceCatalogBestPractices.html)
- [Workflow Best Practices](https://docs.servicenow.com/bundle/utah-servicenow-platform/page/administer/workflow-administration/concept/c_WorkflowBestPractices.html)
- [Business Rule Best Practices](https://docs.servicenow.com/bundle/utah-application-development/page/script/server-scripting/concept/c_BusinessRuleBestPractices.html)
- [ACL Best Practices](https://docs.servicenow.com/bundle/utah-platform-security/page/administer/contextual-security/concept/access-control-best-practices.html)