ServiceNow Japan で開催中の開発者チャレンジ「#BuildWithBuildAgentTokyo」に参加しました、takagiko です。
今回は、ServiceNow の無償でお試しができる PDI（Personal Developer Instance）の Build Agent を使って、Qualys の脆弱性スキャン結果（XML）を取り込み、見つかった脆弱性ごとにインシデントを自動起票するアプリ を作ってみました。
私がやったのは、チャットで要件を伝え、Build Agent から返ってきた設計案の確認ポイントに答え、実装計画を承認したことだけです。それだけで、カスタムテーブル・Script Include・Scripted REST API・React 製の UI Page・ロールと ACL・メニューまで、アプリ一式が出来上がりました。
#BuildWithBuildAgentTokyo とは？
グローバルで開催されてきた開発チャレンジ「#BuildWith」の日本版です。ServiceNow の Build Agent に自然言語で話しかけて（バイブコーディングで）アプリを作り、その体験をブログや SNS でシェアしよう、という企画です。開催期間は 2026年9月7日〜10月16日です。
スキャンしてよいのは、自分の資産だけです
この記事では Qualys Community Edition の導入方法・使い方については扱いませんが、脆弱性スキャンは、自分が所有している、または明確に許可を得た機器・ネットワークに対してのみ実施してください。他人の資産や、許可を得ていない環境へのスキャンは、不正アクセス禁止法などに抵触するおそれがあります。会社の資産であっても、事前に情報システム部門やセキュリティ部門の承認を得てから実施しましょう。
加えて、Community Edition では インターネット側からのPerimeter Scanning（外部スキャン）も無償枠内で実行できる ため、グローバル IP を指定するだけで外部から診断できてしまいます。指定した IP が本当に自分の管理下にあるか（共用ホスティングや CDN、ロードバランサーで他社と IP を共有していないか）、クラウド上の資産であれば各クラウド事業者が定めるスキャンのルールに反しないかを、必ず確認してください。
作ったもの
ひとことで言うと、「Qualys Community Edition のスキャン結果 XML」を「担当者が決まったインシデント」に変換するアプリ です。
「Qualys XML 取り込み」画面で XML ファイルを選んで「解析・プレビュー」を押すと、Severity 3 以上の脆弱性だけを抽出し、IP アドレスで CMDB の CI と照合した結果を一覧表示します。
内容を確認して「インシデント作成」を押すと、1つの脆弱性につき1件のインシデント を作成し、作成したインシデントへのリンクと取り込み履歴を表示します。
| 機能 | 内容 |
|---|---|
| 対象の絞り込み | 脆弱性（VULN 要素）のうち Severity 3・4・5 のみ。INFO 要素（情報収集結果）や Severity 1・2 は対象外 |
| CI 照合 | XML の IP/@value と、cmdb_ci_computer（子クラスを含む）の ip_address を完全一致で照合 |
| 自動アサイン | CI が一意に見つかったら、影響を受ける CI を設定し、CI の「サポートグループ」「サポート担当者」をインシデントの「アサイン先グループ」「アサイン先」に設定 |
| スキップ | CI が見つからない、または複数見つかった検出は登録せず、プレビューで ⚠ 表示 |
| 優先度 | Severity に応じて影響度・緊急度を設定（5 → 1・1／4 → 2・1／3 → 2・2） |
| 履歴 | 取り込み履歴と、検出ごとの処理結果（作成したインシデントへのリンク付き）をカスタムテーブルに保存 |
なぜ「ServiceNow」で「Qualys」なのか？
1. 脆弱性スキャンは「見つけて終わり」になりがち
脆弱性スキャナーは脆弱性を 見つける のは得意ですが、「誰が・いつまでに・どう直すか」を管理する仕組みは別に必要です。スキャン結果のレポートを回覧して終わり…では、対応漏れがあっても気づけません。
2. ServiceNow の CMDB には「担当者」がいる
ServiceNow の CMDB には、機器ごとの サポートグループ や サポート担当者 が登録されています。スキャン結果の IP アドレスを CMDB と突き合わせれば、脆弱性を 「担当部署/担当者が決まったチケット」 に変換でき、自動でアサインができます。
3. Qualys Community Edition なら無料で試せる
Qualys には無料で使える Community Edition があります。発表時のニュースリリースのとおり、内部16アセット・外部3アセット・Webアプリ1件 までをスキャン回数無制限で診断でき、内部スキャン用の仮想スキャナーが1台付きます。いわゆる試用版ではないので、利用期限の制限はありません。
今回は、手元の PC を内部スキャンした結果を XML でエクスポートして使いました。
ServiceNow には、Security Operations の Vulnerability Response（脆弱性対応） という専用の製品があり、Qualys との連携も用意されています。なお Vulnerability Response は、2025年12月に提供が始まった v30 系から Unified Security Exposure Management（USEM） へと進化し、脆弱性だけでなく設定不備やクラウド・コンテナのリスクといった「エクスポージャー」を1つのアーキテクチャで扱うようになりました（今後の Brazil リリースでは USEM が前提になるとアナウンスされています）。
しかし、Qualys Community Edition はAPIアクセス不可 のため、ServiceNow からのAPI連携ができません。本記事のアプリは、ServiceNow の ITSM の範囲のみで Qualys Community Edition からのエクスポートXMLファイルを使って 半自動で簡易的 な脆弱性管理の体験をするためのものです。本格的な脆弱性管理においては、商用版のQualysやTenable等の脆弱性スキャナと、ServiceNowの USEM をAPI連携で組み合わせることで、より高度な自動化が可能です。
注意：ITIL の考え方では、脆弱性を「インシデント」で扱うのは本来は適切ではありません
ITIL でいうインシデントは「サービスの計画外の中断、またはサービス品質の低下」を指します。脆弱性が見つかっただけの段階ではサービスはまだ止まっていないので、厳密にはインシデントには当たりません。ITIL の考え方に沿うなら、脆弱性は潜在的なリスクとして扱い、パッチ適用などの対応は変更管理（Change）で進め、実際に悪用されて被害が出た時点でセキュリティインシデントとして扱うのが自然です。
ServiceNow の Vulnerability Response（USEM）も同じ考え方で、検出結果は脆弱性一致アイテム（Vulnerable Item）などの専用レコードで管理し、修復タスクから変更要求（Change Request）を作って対応する流れになっています。
本記事のアプリは、追加製品なしで ITSM の範囲だけで体験することを優先して、あえてインシデントとして起票 しています。そのまま運用すると、インシデントの件数や MTTR といった指標が歪み、SLA やエスカレーションの運用にも影響します。実際に試す場合は、カテゴリやアサイン先を分ける、集計から除外するなど、通常のインシデント管理と混ざらない工夫をおすすめします。
環境
| 項目 | 内容 |
|---|---|
| ServiceNow | PDI（Australia リリース） |
| Build Agent | Build Agent (Trial) 2.3.3 |
| 脆弱性スキャナー | Qualys Community Edition（スキャン結果を XML でエクスポート） |
事前準備：スキャン対象の PC を CMDB に登録
照合用に、スキャン対象の PC を cmdb_ci_computer に登録しておきます。IP アドレス（172.31.0.2）、サポートグループ（Hardware）、サポート担当者（Beth Anglin）を設定しました。
Build Agent でアプリを作る
Step 1. ServiceNow Studio から Build Agent を起動
ServiceNow Studio で新しいアプリの作成を始めると、作成方法として「自分で」「Now Assist を使用」「クリエータースタジオを使用」が選べます。「Now Assist を使用」を選んで「チャットを開始」を押すと、右側に Now Assist のパネルが開き、ビルドエージェント（Build Agent）と対話できるようになります。
Step 2. サンプル XML を添付して、まずは「設計だけ」を依頼
Qualys のスキャン結果 XML を添付して、要件を伝えます。
添付ファイルは 100K 文字で切り詰められる
ServiceNow のドキュメント「Supported file types for Build Agent」には「Up to 10 MB per attachment.」と明記されていますが、約 800KB の XML を添付したところ「Content will be truncated to 100K characters for the AI.」という警告が表示され、100K 文字に切り詰められて AI に渡されました。10MB まで添付できても、AI が読めるのは 100K 文字までと考えておいたほうがよさそうです（影響は「やってみて分かったこと」で後述します）。
ポイントは、いきなり作らせずに「既存設定の読み取り調査と設計案の提示まで」に留めてもらう ことです。実際に送ったプロンプトはこちらです。
Qualysのスキャン結果XMLをアップロードし、Severityが3以上の検出脆弱性レコードを、1検出レコードにつき1件の標準インシデントとして登録する機能を作成したいです。
今回は既存設定の読み取り調査と設計案の提示までにしてください。
アプリケーション、テーブル、フィールド、スクリプト、フロー、インシデントなどの作成・変更や、XMLの実取り込みは、私が設計を確認して実装を指示するまで行わないでください。
Qualysのスキャン結果XMLのサンプルを添付します。
以下を、承認後に実装する機能の要件として扱ってください。
・日本語の「Qualys XML取り込み」画面を用意する。
・利用者がXMLファイルを選択し、「解析・プレビュー」を実行する。
・プレビューで対象検出、照合したCI、アサイン予定グループ、登録可否を確認できる。
・「インシデント作成」を明示的に実行したときだけ [incident] テーブルへ登録する。
・取り込み履歴と各検出の処理結果、作成済みインシデントへのリンクを確認できる。
・脆弱性(VULN)のみを対象にする。
・severity属性が 3、4、5を処理対象とする。Severity 1、2は対象外とする。
・1つの検出要素につき1件のインシデントを作成する。
・[cmdb_ci_computer] テーブルを継承先も含めて検索し、XMLのIP/@valueとCIのip_addressを完全一致で照合する。
・CIが一意に見つかった場合：
incident.cmdb_ci = 該当CIのsys_id
incident.assignment_group = 該当CIの support_group
incident.assignment_to = 該当CIの supported_by を入れる。
Step 3. Build Agent が既存スキーマを調べて「設計提案書」を作成
送信すると、Build Agent はインスタンスから incident や cmdb_ci_computer のテーブルスキーマを取得し、XML の構造分析と合わせて「調査結果と設計提案書」をまとめてくれました。
設計提案書には、次のような内容が含まれていました。
- Qualys XML の構造分析（VULN 要素から取得できる属性の一覧）
-
incidentとcmdb_ci_computerの既存フィールドの調査結果 - 全体アーキテクチャ（UI Page → Scripted REST API → Script Include → テーブル）
- カスタムテーブル設計（取り込み履歴・検出記録）
- 画面レイアウト案、REST API 設計、処理フロー（シーケンス図）
- インシデントのフィールドマッピング、Severity → 影響度／緊急度のマッピング案
- 検討事項・確認ポイント（8項目）と、実装で使用するメタデータの一覧
人間の開発チームでいえば、要件を伝えたら基本設計書をレビューに出してくれた、という感覚です。
設計提案書のスクリーンショット（クリックで展開）
Step 4. 確認ポイントに回答する
設計提案書の最後には「特に確認いただきたい点」として、caller_id（必須）に設定するユーザーの方針や、CI 未検出・複数一致時のポリシー、カテゴリの値などが挙げられていたので、チャットで回答しました。
| 確認ポイント | 回答 |
|---|---|
| 問い合わせユーザー（caller_id） | セッションユーザー（実行者本人） |
| CI 未検出／複数一致の場合 | どちらもスキップ（プレビューで ⚠ 表示） |
| 同じ XML を2回取り込んだ場合 | 警告なしで二重に作成して OK |
| INFO 要素 | 完全に除外 |
| カテゴリ | category に「Qualys脆弱性」という選択肢を追加して設定。subcategory は空 |
| 権限制御 | 専用ロール x_<vendor>_qualys_admin を作成 |
| XML のサイズ | 最大10ホスト程度なので、大規模なスキャンは考慮不要 |
Severity → 影響度／緊急度のマッピングは特に指定せず、提案どおりのまま進めてもらいました。
Step 5. 実装計画を承認する
回答を送ると、Build Agent は「これは大規模な実装になりますので、まず計画を立てます」と、5ステップの実装計画を提示して承認待ち（Waiting for approval）になりました。内容を確認して Approve plan を押します。
- アプリケーション作成と Fluent SDK ドキュメント調査
- テーブル・ロール・ACL・ChoiceSet の実装
- Scripted REST API・Script Include の実装
- UI Page（React）の実装
- Application Menu の追加・ビルド・デプロイ
Step 6. サブエージェントを使って実装
承認すると、アプリケーション「Qualys XML Importer」が作成され、ServiceNow SDK の Fluent（TypeScript でアプリのメタデータを定義する仕組み）のドキュメントを読み込んでから実装が始まりました。
テーブル・ロール・ACL（3ファイル）、Script Include と REST API（6ファイル）、UI Page（9ファイル）の作成は、それぞれ サブエージェントに委譲 され、1ステップあたり1分前後で完了していきます。
Step 7. ビルドエラーは自力で修正、でもインストールで 401…
ビルドでは、メニューの roles の型・CSS 変数・configuration project のモジュール設定でエラーが出ましたが、Build Agent がエラー内容から原因を特定して自分で修正し、再ビルドで成功しました。
ところが、インスタンスへのインストールでは 認証エラー（401）が繰り返し発生。Build Agent は何度もリトライした後、「ビルドは成功しているが、認証エラーでインストールが完了していない。認証が回復し次第、再度デプロイ可能」と状況をまとめて、いったん作業を終えました。
このときの実装結果まとめには、作成したメタデータの一覧とプロジェクト構成も載っていました。
src/
├── client/ ← React UI Page
│ ├── index.html, main.tsx, app.tsx, app.css
│ ├── services/api.ts
│ └── utils/fields.ts
├── fluent/ ← Fluent メタデータ定義
│ ├── tables/, security/, choices/
│ ├── rest-api/, script-includes/
│ ├── ui-pages/, menu/
│ └── index.now.ts
└── server/ ← サーバーサイドスクリプト
├── script-includes/qualys-xml-parser.js
└── rest-api/parse-handler.js, create-handler.js, history-handler.js
時間をおいてから「認証が回復していると思います。再度インストールを実行してインスタンスにデプロイしてください。」と伝えると、今度は Build & Install が成功しました。401 エラーは、時間をおいて実行することで解消できました。
PDI はリソースが少ないため、負荷が集中するとこういうことがあります。インストールで 401 エラーが続く場合は、時間をおいてから再実行してみてください。
さらに、デプロイ後には UI の診断（ページの読み込み、React アプリの起動、REST API の呼び出し、CSS の適用、コンソールエラーの有無）まで自動で確認し、アクセス方法と利用フローを教えてくれました。
作られたもの
最終的に、次のメタデータが作成されました。
| 種別 | 名前 | 概要 |
|---|---|---|
| テーブル | x_2084533_qualys_0_import_log |
取り込み履歴 |
| テーブル | x_2084533_qualys_0_finding |
検出記録（1脆弱性＝1レコード） |
| ロール | x_2084533_qualys_0.qualys_admin |
本アプリの利用ロール |
| ACL | 2テーブル × read / write / create / delete | 計8件 |
| Script Include | QualysXmlParser |
XML 解析・CI 照合・インシデント作成のロジック |
| Scripted REST API | Qualys Import API |
POST /parse・POST /create・GET /history
|
| UI Page | qualys_import |
React 製の日本語「Qualys XML 取り込み」画面 |
| アプリケーションメニュー | Qualys XML取り込み |
XML取り込み／検出記録／取り込み履歴 |
処理の流れはシンプルで、UI Page（React）から Scripted REST API を呼び出し、Script Include で XML の解析・CI の照合・インシデントの作成を行います。
[UI Page：Qualys XML 取り込み（React）]
│ ① XML ファイルを選択して「解析・プレビュー」
▼
[POST /api/x_2084533_qualys_0/qualys_import/parse]
│ XML を解析 → Severity 3 以上の VULN を抽出 → IP アドレスで cmdb_ci_computer を照合
▼
[プレビュー表示]
│ ② 内容を確認して「インシデント作成」
▼
[POST /api/x_2084533_qualys_0/qualys_import/create]
│ 取り込み履歴・検出記録を登録 → CI が一意に決まった検出だけインシデントを作成
▼
[incident]＋[取り込み履歴]＋[検出記録]
動作確認
ナビゲーターで「qualys」と検索すると、「Qualys XML取り込み」メニューが追加されています。
その後、脆弱性（VULN 要素）を含む別のスキャン結果 XML で試したところ、Severity 3 以上の8件（7-Zip と Google Chrome の脆弱性）が抽出され、すべて CI に一致しました。「インシデント作成」で8件のインシデントが作成されたのは、冒頭のスクリーンショットのとおりです。
作成されたインシデントを一覧で見ると、Severity に応じた優先度（Severity 5 → 1 - 重大、4 → 2 - 高、3 → 3 - 中）が付き、カテゴリ・アサイン先グループ・アサイン先も設定されています。
インシデントを開くと、「影響を受ける CI」には照合した PC が入り、説明欄には QID・Severity・IP・ホスト名・CVE に続けて、診断内容・影響・対応策・検出結果が整理されて入っています。
修正なしの１ターンで、ほぼ完ぺきなものが出来上がったと思います。
１点だけ気になった点は、category は「Qualys脆弱性」にしてくださいと書いたのに、qualys_vulnerability と表示されていたことです。日本語の translation を作り忘れた感じでしょうか。
参考までに、この後 Build Agent に直してと言ったらすぐ修正してくれました。
やってみて分かったこと・Tips
1. 「まずは設計だけ」と頼むのがおすすめ
いきなり「作って」と頼むこともできますが、「調査と設計案の提示まで」と区切ったことで、既存スキーマを調べたうえでの設計提案書と確認ポイントが返ってきました。人間はそれをレビューすることで、人間とAIの認識のズレを実装前に潰せます。
2. 添付できるサイズと、AI が読める量は別物
前述のとおり、ドキュメント上は1添付あたり 10MB までとされていますが、実際には 100K (10万) 文字で切り詰められました。今回のサンプル XML には VULN 要素も含まれていたのですが、100K 文字で切り落とされてしまい、Build Agent には「INFO 要素のみで VULN 要素がない」と扱われてしまったようです。サンプルデータは、処理対象の要素（今回なら VULN）が 100K 文字以内に収まるよう、小さく切り出して渡すのが確実です。
それでも、VULN 要素を処理する設計・実装が今回一発でうまくいったのは、モデルが Qualys の出力のXMLデータ構造を知っていたか、検索して調べてくれたからだと思います。
3. 多少の書き間違いは吸収してくれる
プロンプトでは incident.assignment_to と書いてしまいましたが（正しくは assigned_to）、Build Agent はスキーマを確認したうえで assigned_to に正しくマッピングしてくれていました。
4. エラーは自己修復。ただし環境要因は人間の出番
ビルドエラーは自力で直してくれましたが、インスタンスへの認証エラー（401）は Build Agent のリトライだけでは解消しませんでした。PDI はリソースが少ないため、負荷が集中するとこういうことがあります。時間をおいて実行することで解消できたので、エラーが続くときは少し待ってから再実行を指示しましょう。
まとめ
- Build Agent に日本語で要件を伝えるだけで、スキーマ調査 → 設計 → 実装 → ビルド → デプロイ まで、一気通貫でアプリが出来上がりました。
- 「設計提案書と確認ポイント → 回答 → 計画の承認 → 実装」という流れは、まさに開発チームとのやり取りそのものです。ドキュメントの品質も含め、もう十分に実用段階にあると感じました。
- CMDB を持つ ServiceNow だからこそ、スキャン結果からCMDBを見て「担当者が決まったチケット」に変換できます。ITSMの範囲で追加費用なしで気軽に試すことができる脆弱性管理の第一歩として、ぜひ Build Agent で試してみてください🛡️
📣 ServiceNow World Forum Tokyo 2026
2026年10月27日（火）〜28日（水）には、グランドプリンスホテル新高輪で ServiceNow World Forum Tokyo 2026 が開催されます。最新プロダクトの紹介や導入事例、開発者向けのセッションなどが予定されていて、#BuildWithBuildAgentTokyo の優秀作品は会場の Vibe Code ラウンジで紹介されるそうです。