結論：CADは「JavaScript力」ではなく「実装判断」の試験
ServiceNow CAD（Certified Application Developer）に向けて勉強を始めると、多くの人がまず「JavaScriptを完璧にしなければ」と身構えます。けれど、この試験で本当に問われているのはそこではありません。CADが測っているのは、Now Platform上で業務アプリケーションを設計・実装・保守する力、言い換えれば「目の前の要件を、どの機能のどの責務に割り当てて実装するか」を判断する力です。
ここを取り違えると、勉強の方向がずれます。GlideRecordの細かいメソッドを暗記しても、「この要件はClient Scriptで処理すべきか、Business Ruleに持っていくべきか」を即答できなければ、CADの設問には太刀打ちできません。逆に、構文の引き出しが多少薄くても、責務の切り分けが身についていれば、選択肢を消去法で正しく絞れます。
CADの設問は「とりあえず動く」では合格点をくれません。同じ挙動を実現する実装が複数ある中で、「保守できる実装はどれか」「権限・スコープ・配備まで含めて破綻しないのはどれか」を選ばせてきます。だからこの記事は、知識の羅列ではなく、PDI（Personal Developer Instance）で実際に小さなアプリを一本組みながら、機能を責務で分解して身体に入れる順で構成しています。読み終えたとき、あなたが目指す状態は「機能名を言える」ではなく「なぜその機能を選び、なぜ他を捨てたかを一文で説明できる」です。
CSAからCADへ——変わる視点（運用者から開発者へ）
CSA（Certified System Administrator）を取った人がCADに進むとき、勉強量が増えるというより、見る角度が変わります。
CSAで身につけたのは「標準機能を理解して、設定で業務を回す」視点でした。テーブル、フォーム、リスト、ロール、グループ、Service Catalog——これらを「どう使うか」を知っていれば運用者として機能します。CSAの学習者は基本的に「何を使うか」を覚えることでゴールに近づけました。
CADで求められるのは、その一段手前の判断です。要件を読んで、「この処理は画面側か、サーバー側か」「単発で書くべきか、共通化して再利用すべきか」「権限はロールで足りるか、ACLで絞るか」「変更はどう持ち運ぶか」を、制約から逆算して決める。CSAが「使い方を選ぶ」なら、CADは「実装する場所を要件の制約から選ぶ」のです。
この視点転換は、CSAの土台があって初めて成立します。テーブル・フォーム・ロール・ACLの基礎が曖昧なままCADの実装判断に進むと、選択肢の意味そのものが読めません。CSAの基礎は飛ばさないでください。ここを固めた上で、開発者として「責務をどこに置くか」を考え始めるのが、最短の入口です。
開発機能を「責務」で分解する
CADの勉強で最初にやるべきは、機能を名前で覚えることではなく、責務（その機能が引き受ける仕事）で束ね直すことです。Now Platformの開発機能は、ざっくり「画面」「データ」「再利用」「自動化」「権限」「配備」の6つの責務に整理できます。
画面の責務：Client Script と UI Policy
ユーザーが触るフォームの挙動は、まずこの2つで考えます。
UI Policy は、コード量を増やさずに「表示／非表示」「必須／任意」「読み取り専用」を制御するための機能です。条件に応じてフィールドの状態を切り替えるだけなら、スクリプトを書かずにUI Policyで完結させるのが第一選択です。
Client Script は、ブラウザ側でフォームの値変更・表示補助・入力支援を行うときに使います。単純な表示制御ならUI Policy、複雑な値操作や動的な処理が必要ならClient Script、という線引きが基本になります。
判断軸はシンプルです。「値の操作がどれだけ複雑か」。それと、もうひとつ決定的な問いがあります——「保存時にも強制したいのか」。ここで「画面だけでなくサーバーでも担保したい」となった瞬間、答えは画面の責務を越えます。Client Scriptはブラウザを閉じれば効きません。セキュリティや整合性の担保をClient Scriptに任せてはいけない、という原則はここから来ます。
Client Scriptでサーバー側のデータを取りに行きたくなったら、同期処理でフォームを止めるのではなく、GlideAjax で非同期にServer側へ問い合わせます。GlideAjax はClient Scriptと、AbstractAjaxProcessor を継承したScript Includeをペアで使う仕組みです。
// Client Script 側：マネージャー名をサーバーから取得
var ga = new GlideAjax('AssetRequestUtils');
ga.addParam('sysparm_name', 'getManagerName');
ga.addParam('sysparm_user', g_form.getValue('requested_by'));
ga.getXMLAnswer(function(answer) {
g_form.setValue('approver', answer);
});データの責務：Business Rule と Data Policy
レコードが保存・更新されるときのサーバー側の挙動は、こちらで考えます。
Business Rule は、保存時や更新時のサーバー側処理を担います。実行タイミング（before / after / async、表示時のdisplay）を理解しているかが要点です。before insert/updateなら保存前に値を補正でき、afterなら確定後の関連処理に向きます。Business Ruleの中では current（今の操作対象レコード）と previous（変更前の値）を使えます。
// Business Rule（before）：申請時に概算費用を自動補正
(function executeRule(current, previous) {
if (current.quantity > 0 && current.unit_price > 0) {
current.estimated_cost = current.quantity * current.unit_price;
}
})(current, previous);Data Policy は、UI Policyと混同されやすいですが責務が違います。UI Policyが画面上の見た目（必須・読み取り専用）を制御するのに対し、Data Policyはフォーム経由でもインポートやAPI経由でも効く、データそのものの制約です。「画面でだけ必須」と「どの経路でも必須」を区別する設問は頻出なので、ここは一文で言い分けられるようにしておきます。
再利用の責務：Script Include
同じロジックを複数箇所から呼ぶなら、Script Include に切り出します。Business Ruleの中に判定ロジックを直書きして、似た処理を別のルールにもコピーする——これが後で必ず効いてくる負債です。共通の判定や計算はScript Includeに集約し、Business RuleやGlideAjaxから呼び出す形にします。
// Script Include：再利用する判定・取得ロジック
var AssetRequestUtils = Class.create();
AssetRequestUtils.prototype = Object.extendsObject(global.AbstractAjaxProcessor, {
isHighValue: function(cost) {
return parseInt(cost, 10) >= 100000; // 高額判定（しきい値10万）
},
getManagerName: function() {
var userId = this.getParameter('sysparm_user');
var gr = new GlideRecord('sys_user');
if (gr.get(userId)) {
return gr.manager.getDisplayValue();
}
return '';
},
type: 'AssetRequestUtils'
});自動化の責務：Flow Designer
承認・通知・タスク作成といった業務フロー寄りの処理は、スクリプトで書くより Flow Designer で整理するのが基本方針です。Business Ruleとの線引きは「レコード保存に近い処理か、それとも承認・通知・タスク作成など業務の流れか」。前者はBusiness Rule、後者はFlow（必要に応じてSubflowで部品化）に寄せます。ただし、フローの中に複雑なロジックを詰め込みすぎると保守しづらくなるため、判定や計算はScript Includeに逃がし、Flowは「流れの編成」に徹させる設計判断が要ります。
なお申請系の入口設計では、Catalog Item（Request/RITMとして申請処理に乗せる）と Record Producer（通常テーブルへ直接レコードを作る）の使い分けも問われます。承認やフルフィルメントに乗せたいならCatalog Item、単にレコードを作りたいだけならRecord Producer、と覚えておきます。
権限の責務：ACL（とロール）
アクセス制御は、ロールとACLの責務差を押さえます。ロールは「機能利用の大枠」を与えるもの、ACL は「テーブル・フィールド単位」でロール・条件・スクリプトを使ってアクセスを制御するものです。前述のとおり、権限の担保をClient Scriptで代用してはいけません。画面で隠しても、APIやリストから触れてしまえば意味がないからです。「誰が何にアクセスできるか」はACLで決める、が原則です。
配備の責務：Update Set と Source Control
作ったものをどう運ぶかも、CADの守備範囲です。Update Set は変更をインスタンス間で持ち運ぶ仕組み、Source Control（Gitリンク）はスコープドアプリをリポジトリで版管理する仕組みです。どちらで変更を追跡・移送するか、そして後述するATFでテストできる状態にしてあるか——「変更を安全に管理・テストできるか」までがCADの問う範囲だと考えてください。
PDIで作る練習アプリ：備品申請アプリを段階的に組む
ここからは手を動かします。CADは座学だけでは身につきません。PDI上に 備品申請アプリ を一本作り、上で分解した6責務を一通り通します。大事なのは完成度ではなく、「どの要件を、どの機能で実装したのか」を後から説明できることです。
PDIは無料で取得でき、開発機能をフルに試せます。以下のステップで、最小構成から積み上げます。
ステップ1：Scoped Appと練習テーブルを作る まずStudio（またはApp Engine Studio）でスコープドアプリを新規作成し、u_asset_request（備品申請）テーブルを1枚用意します。フィールドは品目、数量、単価、概算費用、申請者、承認者、状態など最小限で構いません。ここで「グローバルではなく自分のスコープに作る」という感覚を持つことが、後のApplication Scopeの理解に効いてきます。
ステップ2：フォームの表示制御をUI Policyで組む 「状態が『申請中』のときだけ承認者を必須にする」「却下理由は却下時のみ表示」といった見た目の制御を、まずUI Policyで実装します。スクリプトを書かずにどこまでできるかを体感するのが狙いです。
ステップ3：入力支援をClient Scriptで足す 次に、UI Policyでは難しい動的な補助——たとえば「品目を選んだら既定の単価を埋める」「申請者を選んだら承認者をサーバーから引いて初期表示する」をClient Scriptで実装します。後者では前掲の GlideAjax を使い、サーバー（Script Include）に問い合わせます。ここで「画面で完結する補助」と「サーバーに聞く必要がある補助」の違いを実機で確認します。
ステップ4：保存時の処理をBusiness Ruleで担保する 概算費用（数量×単価）の自動計算を、画面任せにせず before のBusiness Ruleでサーバー側でも確定させます。これで「ブラウザを閉じても、APIから入れても値が崩れない」状態になります。ステップ3の画面補助とステップ4のサーバー担保の二段構えを、自分の言葉で説明できるようにします。
ステップ5：共通ロジックをScript Includeへ切り出す 高額判定（しきい値以上か）やマネージャー取得など、複数箇所から使う判定を AssetRequestUtils（Script Include）に集約し、Business RuleとGlideAjaxの両方から呼びます。コピペで散らばっていたロジックが一箇所に集まる感覚を掴みます。
ステップ6：承認・通知をFlow Designerで組む 「高額申請ならマネージャー承認 → 承認されたら購買担当へタスク作成 → 申請者へ通知」という流れをFlowで実装します。判定（高額か否か）はScript Includeを呼び、Flowは流れの編成に徹させます。Business Ruleに全部書く案と比べて、どちらが読みやすく直しやすいかを体験してください。
ステップ7：ACLでアクセス範囲を絞る 申請者は自分のレコードのみ閲覧・編集可、承認者は承認系フィールドのみ更新可、といった制御をACLで設定します。Client Scriptで隠していたものを、本来あるべきACLに置き換える練習にもなります。
ステップ8：Update SetまたはSource Controlで変更を追跡する ここまでの変更がUpdate Setに正しく載っているか、あるいはSource Controlでコミットできるかを確認します。「作って終わり」ではなく「別インスタンスへ運べる状態か」までを締めくくりに確認します。
このアプリは小さくて構いません。完璧を目指すより、各ステップで「なぜこの機能を選び、なぜ他を捨てたか」をメモに残すことのほうが、CAD対策としては何倍も価値があります。
JavaScript経験別の学習順（経験者／未経験者）
同じCADでも、出発点によって最短ルートは変わります。自分のタイプに合わせて入口を選んでください。
JavaScript未経験の人は、構文を全部やろうとせず、必要な最小範囲に絞ります。順番は、(1) 変数・条件分岐・関数・配列・オブジェクトを最小限、(2) フォームの値取得、(3) サーバー側のレコード操作（GlideRecord）、(4) 関数の再利用パターン、の順。複雑な非同期処理、外部ライブラリ、フロントエンドフレームワークは後回しで構いません。ServiceNowで使うJavaScriptは限定的なので、汎用の入門書を一冊やり切る前に、Now Platform上での値取得とGlideRecordに早く触れたほうが定着します。
Web開発の経験がある人は、JavaScript構文の復習は飛ばして構いません。代わりに最初から、Client ScriptとBusiness Ruleの「実行場所の違い」、GlideRecordの挙動、g_form APIの差分に集中します。経験者が一番つまずくのは構文ではなく、「同じJavaScriptでもクライアントとサーバーで動く文脈が完全に分かれている」という前提です。ここを軽視すると、サーバーとクライアントの挙動の期待がずれます。
ServiceNow運用の経験がある人（CSA保持者など）は、テーブル設計、ACLの仕組み、Update Setの移送ロジック、Flowと標準機能の責務分離を優先します。この層への注意は一つだけ——「コード量を増やす前に、標準機能で足りるかを見る」。運用経験があるとつい設定で解こうとせずスクリプトに行きがちですが、CADはむしろ「書かずに済ませる判断」を評価します。
Application Scope・Update Set・Source Control・ATF（テスト）
開発者として避けて通れないのが、スコープと配備とテストの三点セットです。
Application Scope は、アプリごとの名前空間と境界です。自分のスコープで作ったものが、意図せず他のアプリに影響したり、逆に他スコープのリソースに触れられなかったり——このクロススコープの挙動を理解していないと、「動いたはずなのに本番で壊れる」設問に引っかかります。ステップ1でスコープドアプリにこだわったのは、この感覚を早く持つためです。
Update Set と Source Control は、変更の運び方の二択です。Update Setは設定変更をXMLとしてまとめてインスタンス間で移送する古典的な方法、SourceControlはスコープドアプリをGitリポジトリに紐づけてコミット・ブランチで管理する方法です。チーム開発やCI寄りの運用ではSource Control、単発の移送ではUpdate Set、という整理ができていれば十分です。
ATF（Automated Test Framework） は、作った機能が壊れていないかを自動で検証する仕組みです。フォーム操作やレコード生成、サーバーロジックの結果を、テストとして記録・再実行できます。CADの観点では「変更を安全にテストできる状態にしてあるか」が問われるので、備品申請アプリの主要動線（申請→承認→通知）をATFで1本でも組んでおくと、知識が実感に変わります。
CADで避けたい実装パターン（二重実装・スコープ無視など）
CADの誤答は、知識不足というより「やりがちな悪い実装」を選んでしまうことで起きます。代表的なものを潰しておきます。
- ロジックの二重実装：同じ判定や計算を複数のBusiness Ruleにコピペで持つ。直すときに片方を直し忘れます。共通化はScript Includeへ。
- Client Scriptでの権限・整合性担保：画面で隠す・止めるだけで、サーバー側（ACL／Business Rule）で担保しない。APIやリストから素通りされます。
- Application Scopeの無視：スコープを意識せず作り、意図しないクロススコープの影響を生む。境界を前提に設計します。
- 似た機能の取り違え：Data Policy・UI Policy・ACLを混同する。「画面の見た目」「経路を問わないデータ制約」「アクセス制御」と責務で言い分けます。
- 標準機能を飛ばしてスクリプト：UI PolicyやFlowで足りる場面でいきなりコードを書く。CADは「書かない判断」を評価します。
- 『動けばよい』で止める：保守性・スコープ・配備・テストまで含めて破綻しないか、を最後に必ず点検します。
これらを避ける一番の練習は、実装するたびに「捨てた選択肢がなぜダメか」を一文で言えるようにすることです。JavaScript経験者ほど、ServiceNowの実行タイミングを理解する前に高度なScript Includeパターンに飛びつきがちですが、そこは意識して踏みとどまってください。
CADの学習順は「土台→領域別演習→総合模試」で組む
CSA範囲を確認した後、PDIでUI制御・サーバー処理・ACL・Flow・REST・配布を一度ずつ作り、領域別ドリル、60問の総合模試へ進みます。各段階では、作ったもの、迷った判断、公式資料で確認したページを記録してください。
経験別の勉強時間、5フェーズの具体的な配分、公式Blueprintの現行比率は、ServiceNow CADの難易度と勉強時間で詳しく整理しています。
よくある質問
Q. CADの前にCSAは必須ですか？ 制度上の必須要件かどうかは公式の最新情報を確認してほしいのですが、学習効率の面では強く推奨します。CADの設問はテーブル・ロール・ACLといったCSA範囲を前提に書かれており、ここが曖昧だと選択肢の意味自体が読めません。CSAの土台は飛ばさないのが結局の近道です。
Q. JavaScriptが苦手でも合格できますか？ できます。CADはJavaScriptの巧拙より「どの機能をどの責務で使うか」を問う試験だからです。未経験者向けの学習順（変数・条件・関数 → フォーム値取得 → GlideRecord → 再利用）で必要十分な範囲に絞り、PDIで動かして覚えるのが現実的です。構文の網羅より、実装判断を言語化できる状態を優先してください。
Q. PDIの練習アプリはどこまで作り込むべきですか？ 作り込み度よりも、6責務（画面・データ・再利用・自動化・権限・配備）を一通り通すことを優先します。備品申請アプリ程度の小さな題材で構いません。完成度より、「この要件をこの機能で実装した／他を捨てた理由」を説明できることがゴールです。その説明が、そのまま試験での判断力になります。
