この記事では、CADをJavaScriptだけの試験として扱わず、ServiceNow上で業務アプリを設計、実装、保守するための資格として整理します。CSAとの違い、開発部品の使い分け、PDIで作るべき練習アプリまで順番に確認します。
- CADはJavaScriptだけの試験ではなく、ServiceNow上で業務アプリを設計・実装・保守できるかを見る資格です。
- CSAの土台、スクリプティング、アプリ開発、セキュリティ、移送とテストを順番に積むのが安全です。
- PDIでは小さなアプリを作り、UI制御、サーバー処理、再利用ロジック、権限をまとめて確認します。
CADとは何を証明する資格か
CADは、Now Platform上でアプリケーションを設計し、データモデル、UI、セキュリティ、自動化、連携、配備まで考えられる開発者かを確認する資格です。一般的なJavaScript力だけでなく、ServiceNow特有の実装判断が問われます。
CADとCSAの違い
| 観点 | CSA | CAD |
|---|---|---|
| 主な役割 | 管理・設定の基礎 | 開発・実装の判断 |
| 中心論点 | ナビゲーション、データ、ユーザー、カタログ | アプリ設計、スクリプト、UI、セキュリティ、配備 |
| 学習方法 | 公式基礎とPDI操作 | 小さなアプリを作って検証 |
| つまずき | 用語の関係 | 機能の使い分けと実行タイミング |
CADで問われる技術領域
- データモデルとテーブル設計
- Client Script、UI Policy、Data Policyの使い分け
- Business Rule、Script Include、GlideAjaxの役割
- Flow Designerと従来型スクリプトの判断
- ACL、Application Scope、Cross-Scopeの考え方
- Update Set、Git連携、ATFによる変更管理とテスト
開発機能の使い分け表
| 機能 | 主な使いどころ | 注意点 |
|---|---|---|
| UI Policy | 画面上の表示・必須・読み取り専用制御 | セキュリティ制御には使わない |
| Client Script | クライアント側の動的制御 | サーバーデータ取得にはGlideAjaxなどを検討 |
| Business Rule | レコード保存・更新時のサーバー処理 | 実行タイミングを理解する |
| Script Include | 再利用するサーバー側ロジック | 直書きの増殖を防ぐ |
| Flow Designer | 業務フローの自動化 | 複雑なロジックは設計判断が必要 |
PDIでやるべき実装練習
最小アプリを1つ作り、テーブル、フォーム、UI Policy、Client Script、Business Rule、Script Include、ACL、Flow Designer、Update Setを順番に触ると、個別機能ではなくアプリ開発の流れとして理解できます。
CADはJavaScript試験ではなく、実装判断の試験
CADで問われるのは、JavaScriptを書けるかだけではありません。ServiceNow上で、どのデータモデルを作り、どのUI制御を使い、どこにサーバー処理を書き、どの権限で守り、どう移送し、どう保守するかを判断できるかが重要です。
一般的なWeb開発経験があっても、ServiceNow固有のApplication Scope、Client Script、UI Policy、Business Rule、Script Include、ACL、Flow Designer、Update Setの関係を知らないと、CADの問題文は読みづらくなります。
| 領域 | CADで見る判断 | PDIで確認すること |
|---|---|---|
| データモデル | Table、Field、Relationshipをどう設計するか | Scoped AppでCustom Tableを作る |
| UI制御 | UI Policyで足りるか、Client Scriptが必要か | 必須、非表示、値変更を試す |
| サーバー処理 | Business RuleかScript Includeか | 更新時処理と再利用ロジックを分ける |
| セキュリティ | ACL、Application Scope、Cross-Scopeをどう扱うか | Role有無で表示と更新を変える |
| 配布と保守 | Update Set、Source Control、App Repositoryをどう使うか | 変更を保存し、戻せる状態にする |
CSAの土台を飛ばさない理由
CADはCSAの上に乗る資格として考えた方が自然です。CSAでTable、Record、Role、ACL、Catalog、Flowの基本が曖昧なままCADに入ると、スクリプトやアプリ設計が断片的な暗記になります。
たとえばClient Scriptを学ぶ前に、フォームとフィールドが何を表すかを理解している必要があります。Business Ruleを学ぶ前に、レコードの挿入、更新、削除がどのタイミングで起こるかを理解する必要があります。ACLを学ぶ前に、RoleとGroupの関係を説明できる必要があります。
PDIで作るとよい練習アプリ
CAD対策では、機能を単体で触るより、小さな練習アプリにまとめる方が効率的です。たとえば「備品申請管理アプリ」を作り、Custom Table、Form、UI Policy、Client Script、Business Rule、Script Include、Flow、ACLを少しずつ追加します。
この形にすると、どの機能がどの責任を持つのかが見えます。UI Policyは画面制御、Client Scriptはクライアント側の動的処理、Business Ruleはレコードイベント、Script Includeは再利用ロジック、Flowはプロセス自動化、ACLはアクセス制御です。
CADの出題範囲を、機能名ではなく責務で見る
CADの学習では、機能名を並べるより、責務で分けると理解しやすくなります。データをどう持つかはTableとField。画面をどう動かすかはUI PolicyとClient Script。サーバー側でどう処理するかはBusiness RuleとScript Include。誰に何を許すかはACLとApplication Scope。変更をどう運ぶかはUpdate SetやSource Controlです。
責務で整理すると、問題文で何を問われているかが見えます。フォーム上の表示制御なのか、データ保護なのか、レコード更新時の処理なのか、再利用ロジックなのか。ここを読み分ける力が、CADの実装判断につながります。
| 責務 | 主な機能 | 判断の問い |
|---|---|---|
| 画面制御 | UI Policy、Client Script | コードを書かずに済むか |
| サーバー処理 | Business Rule、Script Include | いつ実行し、再利用するか |
| 権限制御 | Role、ACL、Scope | 誰が何をできるべきか |
| 自動化 | Flow、Subflow | プロセスとして流すべきか |
| 移送・保守 | Update Set、Source Control、ATF | 変更を安全に管理できるか |
保守できる実装を意識する
CADでは、動くものを作るだけでは不十分です。Business Ruleに同じ処理を何度も書くと、変更時に壊れやすくなります。Client Scriptでデータ保護をしようとすると、サーバー側の安全性が不足します。スコープやACLを意識しないと、想定外のアプリに影響を出す可能性があります。
練習アプリを作るときも、なぜこの機能を選んだかをメモしてください。UI Policyで足りるのにClient Scriptを書いていないか。共通処理をScript Includeへ切り出しているか。権限はACLで守っているか。この視点がCADらしい学習になります。
CADでよくある誤解
CADをJavaScriptの資格だと考えると、学習の中心がずれます。もちろんスクリプトは重要ですが、ServiceNowでは標準機能で済ませる判断も同じくらい重要です。UI Policyで足りる制御にClient Scriptを書く、Flowで表現できる業務処理を無理にBusiness Ruleへ寄せる、ACLではなくClient Scriptで隠して安全だと思う、といった誤解は避ける必要があります。
もう一つの誤解は、アプリが動けばよいという考え方です。CADでは、スコープ、権限、再利用、移送、テストまで含めて保守できるかが大切です。PDIで練習するときも、動いた瞬間で終わらせず、なぜその設計にしたのかを説明できる状態にしてください。
- UI制御とデータ保護を混同しない
- Business Ruleに処理を詰め込みすぎない
- 共通ロジックはScript Includeへ寄せる
- ScopeとACLを設計の最初から意識する
- Update SetやSource Controlで変更管理を確認する
CADを責務で分解する
CAD対策では、機能名を覚えるだけでは足りません。どの責務をどの機能に持たせるかを判断する必要があります。画面上の振る舞いはUI PolicyやClient Script、サーバー側の処理はBusiness RuleやScript Include、アクセス制御はRoleやACL、業務プロセスはFlowやSubflow、移送と保守はUpdate SetやSource Control、ATFで考えます。
この責務分解ができると、問題文の読み方が変わります。たとえば「フォーム上で項目を必須にする」ならUI Policyで足りるかもしれません。「レコード更新時に関連レコードを作る」ならBusiness RuleやFlowが候補になります。「複数箇所から同じサーバー処理を使う」ならScript Includeが候補です。
| 責務 | 候補機能 | 判断のポイント |
|---|---|---|
| 画面制御 | UI Policy、Client Script | コード不要で済むか、クライアント側でよいか |
| サーバー処理 | Business Rule、Script Include | 実行タイミングと再利用性 |
| データ設計 | Table、Field、Relationship | 業務データをどう持つか |
| アクセス制御 | Role、ACL、Application Scope | 誰がどのデータを扱うか |
| 自動化 | Flow、Subflow | 業務プロセスとして管理するか |
| 保守 | Update Set、Source Control、ATF | 変更を安全に運び、確認できるか |
JavaScript経験者が注意する点
一般的なJavaScript経験がある人はCADで有利ですが、そのままWeb開発の感覚を持ち込むと危険です。ServiceNowでは、クライアント側で動くClient Scriptと、サーバー側で動くBusiness RuleやScript Includeを分けて考える必要があります。さらに、クライアント側で項目を隠しても、データ保護にはなりません。アクセス制御はACLで考える必要があります。
また、ServiceNowの開発ではApplication Scopeが重要です。どのアプリの中で作ったファイルか、別スコープからアクセスできるか、Cross-Scopeの制限に引っかからないかを意識しないと、実装は動いても保守しづらくなります。
PDIで作る練習アプリの設計
CAD対策では、単機能を触るだけでなく、小さなアプリを作って責務を分けるのがおすすめです。たとえば備品申請管理アプリを作り、申請テーブル、フォーム制御、承認Flow、更新時のBusiness Rule、再利用処理のScript Include、RoleとACL、Update Setを入れます。これだけでCADの主要論点をかなり横断できます。
- Scoped Appを作り、Custom Tableを一つ作る
- Formに必須項目と表示制御を設定する
- UI Policyで済む制御とClient Scriptが必要な制御を分ける
- Business RuleからScript Includeを呼ぶ小さな処理を作る
- RoleとACLで閲覧・更新範囲を変える
- Flowで承認や通知を動かす
- Update SetまたはSource Controlで変更を管理する
CADで避けたい実装パターン
CADの学習では、動けばよいという考え方から離れる必要があります。Business Ruleに同じ処理を何度も書く、Client Scriptでデータ保護をしたつもりになる、条件なしで重い処理を動かす、Scopeを意識せずグローバルに作る、移送やテストを考えずPDIだけで終える、といったパターンは避けるべきです。
よくある質問
CADはJavaScriptだけ勉強すればよいですか？
JavaScriptの基礎は役立ちますが、それだけでは不十分です。Client Script、Business Rule、Script Include、ACL、Flow Designerをどこで使うかの判断が重要です。
PDIではどんなアプリを作るとよいですか？
小さな申請管理アプリを作り、テーブル、フォーム、UI Policy、Client Script、Business Rule、ACL、Flow Designerを一通り触ると理解しやすくなります。
CSA合格前にCADへ進んでもよいですか？
開発経験があれば先に触ることはできますが、ServiceNowの標準機能や権限、データ構造の土台が弱い場合はCSA相当の理解を先に固める方が安全です。
