この事例の要点
| テーマ | ServiceNow開発の |
|---|---|
| 課題 | 開発では |
| 取り組み | Build Agent・AI Agentを |
| 製品・技術 | ServiceNow Build Agent、 |
| 発表の場 | ServiceNow World Forum Tokyo 2026 |
| 今後 | 自社で |
株式会社シスラボは、
ServiceNow World Forum Tokyo 2026では、
-
開発全体の
時間と 手戻りを 減らすために 業務アプリケーションの
開発では、 プログラムを 書くこと 以外にも、 多くの 時間が 使われています。 既存の 仕組みの 調査、 要件の 整理、 業務部門との 認識合わせ、 テストや 修正も 欠かせません。 例えば、
同じ 「案件管理」でも、 管理する 情報や 数字を 確定する タイミング、 閲覧できる 範囲は 組織によって 異なります。 前提が 曖昧なまま開発が 進めば、 実装後につくり直しが 必要になることがあります。 Build Agent・AI Agentの
活用では、 作成する 作業の 速さに 加え、 確認の 待ち時間や 手戻りを 減らせるかも 重要です。 シスラボは、 要件を 整理し、 形にし、 確かめる 一連の 進め方を 見直す可能性を 探っています。 -
Build Agentで、
要件を アプリケーションへ Build Agentは、
自然言語による 指示をもとに、 ServiceNow上の アプリケーション作成や 変更を 支援する 開発機能です。 公式ドキュメントでは、
つくりたい内容を 説明し、 Build Agentが 提示する 計画を 確認したうえで、 作成を 進める 流れが 紹介されています。 利用者の 役割や 必要なデータ、 実現したい状態を 伝え、 生成された 内容に フィードバックしながら 具体化できます。 期待しているのは、
検討している 内容を、 関係者が 確かめられる 形にするまでの 時間を 短くできることです。 早い段階で 画面や 動きを 確認できれば、 足りない情報や 業務に合わない部分を 具体的に 話し合えます。 -
既存アプリケーションの
改善にも 活用する 稼働中の
ServiceNowにも、 管理項目の 追加や 処理の 見直し、 画面の 改善など、 さまざまな要望が 生まれます。 Build Agentでは、
対象の アプリケーションに 対して 変更内容を 伝え、 生成された 変更を 確認しながら 改修を 進められます。 アプリケーションの 形式によっては、 利用に 向けた 変換などの 準備が 必要です。 改修では、
変更する 箇所と 維持すべき動作を 明らかにすることが 大切です。 一つの 項目を 別の 処理や 帳票、 連携先が 使っている 場合もあります。 現在の
仕様が 生まれた 理由や 関連する 業務を 理解して おくことが、 Build Agentへの 指示や 変更内容の 確認にも 役立ちます。 -
AI Agentで、
情報の 確認から 処理の 実行までを 考える ServiceNowの
AI Agentは、 与えられた 役割や 指示に 沿って、 情報の 取得や 分析、 処理の 実行などを 行うための 仕組みです。 AI Agent Studioでは、
役割や 使用する ツールを 設定し、 動作を テストできます。 複数の AI Agentで、 一つの 目的に 向けて 作業を 分担させる 構成も 用意されています。 開発業務では、
必要な情報の 収集、 記録の 整理、 条件に 沿った 確認などが、 AI Agentの 活用を 検討できる 作業です。 実際に 任せるには、 参照する 情報や ツール、 完了と 判断する 条件を 設計し、 動作を 確かめる 必要があります。 公式ドキュメントでも、
担う 作業を 明確にし、 目的に合う ツールと 説明を 用意することが 重視されています。 AI Agentが 進める 範囲と、 人の 確認につなぐ場面を 決めることが、 業務に 組み込むための 出発点になります。 -
業務の
目的と 条件を、 AIに 伝えられる 形にする 誰が、
どの 場面で 使うのか。 何を 判断できるようにしたいのか。 どのような例外に 対応する 必要があるのか。 AIへの 指示を 考えることは、 こうした 前提を 整理する 機会にもなります。 同じ情報を
扱う 仕組みでも、 担当者の 日々の 対応を 支えるのか、 管理者が 部門全体の 見通しを 判断するのかによって、 必要な情報や 見せ方は 変わります。 ServiceNowの
公式ガイドラインでも、 実装前の 要件整理、 明確な計画、 データや 画面を 含む設計、 具体的な用語による 指示が 推奨されています。 業務を
理解する 人と ServiceNowの 構造を 理解する 人が 協力し、 Build Agentや AI Agentに 目的と 条件を 伝えられる 形にすることが、 開発の 重要な役割になります。 -
生成した
内容を 確かめ、 修正につなげる Build Agentが
生成した アプリケーションも、 業務に 沿った 検証が 必要です。 情報が 正しく 保存されるか、 適切な利用者だけが 閲覧・更新できるか、 入力不足や 処理失敗に 対応できるかを 確認します。 公式ドキュメントには、
変更内容や 差分の レビューに 加え、 対応する 環境で ATFと 呼ばれる 自動テストの 仕組みを 使い、 Build Agentが テスト作成や 実行を 支援する 流れも 示されています。 繰り返す確認の
負担を 減らせる 可能性がある 一方、 何を テストし、 どの 状態を 正しいと 判断するかは、 人が 業務の 目的に 照らして 考える 必要があります。 重要な条件が
テストから 抜けていれば、 成功したという 結果だけでは 品質を 判断できません。 AIの 支援を 活かすためにも、 確認すべき観点を 明確にすることが 大切です。 -
コストと
期間は、 開発全体で 確かめる 実装が
速くなっても、 修正や 確認に 時間がかかれば、 開発全体での 効果は 小さくなります。 効果を 確かめる 際には、 準備、 実装、 レビュー、 テスト、 修正までを 含めて 見ることが 重要です。 また、
特定の 担当者だけが 扱える 状態では、 その 後の 改修や 引き継ぎに 負担が 残ります。 同じような作業でも 効果を 再現できるか、 ほかの メンバーが 理解し、 改善を 続けられるかも 確認したい点です。 自社検証では、
Build Agent・AI Agentを 活用しやすい作業と、 人の 知識や 判断が 必要な場面を 見極め、 実際の 開発に 取り入れられる 方法を 考えています。 -
自社の
知見を、 お客様の 開発と 改善へ シスラボは、
自ら Build Agent・AI Agentを 使い、 期待した 結果にならない場面にも 向き合いながら、 指示の 伝え方や 確認方法、 既存の 開発・運用への 組み込み方を 考えています。 お客様ごとに、
業務や 既存環境、 関わる 部門や 運用体制は 異なります。 その 背景を 理解し、 AIを 活用できる 場面を 見極めることが、 成果につながると 考えています。 開発や
確認の 負担を 減らし、 着手を 待っていた 改善に 取り組めるようにすることを 目指して、 自社で 得た 知見を、 お客様の ServiceNow開発や 継続的な改善、 内製開発の ご支援につなげていきます。