ServiceNow App Engineのシステム開発の完全ガイド

ServiceNow App Engineは、業務アプリを開発する基盤です。導入時には、作るシステムの種類、標準機能との境界、開発と運用の3点を整理します。

そのうえで、開発の進め方、費用、開発会社の選び方を順に説明します。各テーマの詳細は、下の関連記事もご覧ください。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

ServiceNow App Engineの概要

ServiceNow App Engineは、単独で完結する業務パッケージではありません。既存のServiceNow製品と同じ基盤の上で、カスタムアプリを作成・展開する開発基盤です。

ITサービス管理、従業員向けサービス、顧客対応、IT運用などのデータやワークフローにつなぐと、標準機能だけでは足りない業務を拡張できます。

ServiceNow全体との関係

ServiceNowには、IT部門向けのITSMやITOM、人事サービス、顧客サービスなど、用途ごとの標準アプリケーションがあります。

App Engineは、別の業務システムを作るものではありません。共通のデータモデル、認証、ワークフロー、通知、監査の考え方を引き継いで、アプリを加えるものです。

既存のServiceNowを使う企業では、別のログイン画面を行き来する手間や、システム間で同じデータを重複して持つことを減らせます。

開発を支える主な機能

App Engine Studioでは、データ、画面、ロジック、自動化、セキュリティを構成できます。アプリの設計から運用まで、機能を役割に応じて使い分けます。

開発と業務フロー：Studio IDEとFlow Designerによる開発
画面とモバイル：UI Builderとモバイル機能の利用
機能テスト：Automated Test Framework（ATF）による自動化
アプリ管理：App Engine Management Centerで申請、審査、ライフサイクル、展開を管理
開発権限：Delegated Developmentで現場に一部を委譲し、IT部門の統制を残せます

ServiceNow日本語公式のアプリケーション開発プラットフォーム情報（2026年確認）には、App Engineの機能構成が示されています。

「ローコードだから安い」とは限らない理由

ローコードなら画面やフローを短時間で組み立てやすい一方、作業がすべて自動で終わるわけではありません。

業務要件の整理とデータ設計に加え、ロールとACL、外部API連携の作業が必要です。さらに、テスト、移行、教育も必要です。特に、複数部門が台帳を使う場合は、閲覧権限、例外処理の記録、将来のアップグレード確認が欠かせません。

開発費は、画面作成の速さだけでなく、運用開始後も安全に変更できる仕組みを含めて評価します。

ServiceNow App Engineで作れるシステムの種類

業務の受付・管理・連携という用途から、アプリの形を整理できます。

活用範囲は、申請フォームから複数部署のケース管理や外部連携まで広がります。「何を作るか」と「どの程度独自に開発するか」の2軸で整理すると、標準機能との境界をはっきりさせられます。

申請・承認・ケース管理アプリ

購買申請や設備利用申請、契約審査のように、受付から完了まで一定の流れがある業務に向いています。入社手続きや社内問い合わせも当てはまります。

入力内容に応じて承認者を変えたり、期限前に通知したり、対応履歴を一か所で管理したりできます。メール転送やExcelの更新を減らしながら、処理件数、滞留日数、差し戻し理由を把握できます。

台帳・ポータル・モバイルアプリ

資産や拠点、取引先の管理のように、登録・検索・更新・履歴管理が中心の業務にも向いています。資格や設備点検、リスクの管理も当てはまります。

利用者向けポータルでは、担当部署を意識せずに申請や問い合わせを受け付けられます。現場の点検では写真や位置情報を登録でき、紙のチェックシートからの転記も減らせます。

まず、基幹データの正本をどのシステムに置くかを決めておく必要があります。そうしないと、台帳を増やすだけの設計になりかねません。

外部連携を中心とした業務アプリ

人事や会計などの外部システムとAPIでつなぎ、受付や承認の前後だけをApp Engineに集約できます。販売、購買、認証も連携先になります。

App Engineには入力や判断、通知を置き、監査証跡も残します。計算や正式なマスタ管理は、専門システムに任せます。

連携方式は、REST API、IntegrationHub、定期インポートなどから選びます。そのうえで、エラー時の再送や重複登録、タイムアウトのほか、個人情報の送受信も設計します。

標準拡張・新規アプリ・スクラッチの使い分け

選択肢は、標準機能の設定やApp Engineによる標準機能の拡張のほか、新規スコープ付きアプリや別基盤でのスクラッチ開発があります。

まず、標準機能で対応できる範囲を確定します。次に、独自性が高く、共通ワークフローや監査を活かせる部分をApp Engineで補うと堅実です。

データ量や性能要件、特殊な計算、法令上の保存要件がServiceNowのモデルと合わない場合は、別基盤も含めて総保有コストで比較します。

ポイント

迷ったときは、まず標準機能で対応できる範囲を確定し、独自性が高く共通ワークフローや監査を活かせる部分だけをApp Engineで補う形を基準にします。

ServiceNow App Engineのシステム開発の進め方

成果の測り方と作る範囲を先にそろえる構成です。

短納期で進めるには、画面を作る前に成果指標と標準機能との境界を決めておくことが大切です。そのうえで、小さな範囲で検証します。

委託する場合は、企画や設計、実装ごとに成果物を分けて合意しておくと、ローコード案件のスコープクリープを抑えられます。テスト、移行、運用の成果物も同じ考え方で分けます。

▶ 詳細はこちら：ServiceNow App Engineのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

企画・要件定義で決めること

企画では、App Engineを導入すること自体ではなく、達成したい業務成果を中心に置きます。

現状を確認するために、帳票やメール、Excelなどの資料を集めます。承認規程や例外処理の資料も含めます。

利用者や業務オーナーに加えて、ServiceNow管理者、セキュリティ担当、データ管理者にも、早い段階から参加してもらいます。

目標：承認時間を何日から何時間にするか、未処理を何％減らすか、履歴を何分で検索するかを決めます。
対象範囲：現行業務を洗い出し、標準機能、App Engine、外部システムのどれで担うかを分けます。
要件と検証：関係者と条件を文書にまとめ、重要業務をMVPで試す形にします。

移行データと連携先、ピーク時の件数は記録しておきます。保存期間や稼働後の責任者も控えておきます。成功条件を決めておくと、後から出る追加要望を判断しやすくなります。

利用者の反応を確かめてから、二つ目以降の業務へ広げます。

データモデル・権限・連携の設計

データモデル、権限、外部連携の順で設計し、移行や運用に必要な情報をはっきりさせます。

データと移行：項目や状態、参照、履歴の保存先を決め、欠損や重複を調べます。
権限：管理者、申請者、承認者、担当者、監査閲覧者を分けたうえで、最小権限、代理承認、異動時の無効化、個人情報のマスキングを確認します。
外部連携：認証と送受信項目を設計し、停止時の再処理を用意します。
連携条件：実行頻度、再送、相関ID、監視担当を定めます。
個人情報：所在、保持期間、委託先、国外移転、削除対応を決めます。

主要なテーブルを設計し、項目や状態、参照関係を決めます。重複を防ぐルールも定めます。

登録者や担当部署、更新日時の保存先も決めます。状態履歴と添付、例外理由は、どこに残すかを決めておきます。

移行の前に、コード変換や欠損値、重複を洗い出します。文字コードや更新日時、照合方法も確かめたうえで、少量データでリハーサルします。

公式資料では、App Engine Studioでロールを定義し、テーブルの読み取りや更新の権限、ポータルやワークスペースへのアクセスを付与します（出典：ServiceNow公式「Add application security」、2026年3月更新）。

連携先の停止に備えて、一時保存や再処理の仕組みを設けます。個人情報の所在、保持期間、委託先・再委託先は、契約と運用に反映します。国外移転や削除要求への対応も含めます。

開発・テスト・リリース

標準機能を優先して実装し、開発環境で確認してから本番へ展開します。主な工程は、実装、テスト、運用の順に進みます。

実装：標準テーブルやテンプレートを優先し、Flow DesignerとUI Builderを使います。
テスト：急ぐ場合でもテストは削らず、対象をMVPに絞って品質を保ちます。
運用：利用率や処理時間、滞留件数を測り、差し戻し率、権限エラー、連携失敗も確かめます。

独自スクリプトは、必要性を説明できる部分に限ります。環境間の移送方法を決め、命名、バージョン、所有者を統一します。依存関係と廃止基準もそろえます。

確認対象には、権限不足、差し戻し、二重送信があります。連携先が停止した場合や添付容量を超えた場合も、確認が必要です。同時更新とタイムアウトも対象に入ります。

非本番環境では、ATFのデプロイメントテストスイートとScoped App Definitionsのインスタンススキャンを実行できます（出典：ServiceNow公式「Testing applications in AEMC」、2025年8月更新）。

公式事例には、カスタムアプリ20個を280ユーザーが使い、月平均19,000件を処理した例があります。

別の例では、解決時間を35パーセント短縮しました（出典：ServiceNow公式顧客事例、確認日2026年8月）。

これらは、既存の基盤や専任の体制、対象業務が明確な事例です。自社の納期や効果を約束する数字としては扱わないでください。

ポイント

開発は、成果指標と対象範囲を決めてから、重要業務のMVPを小さく試して広げる流れで進めます。委託時は工程ごとの成果物を分けて合意します。

ServiceNow App Engineの費用相場とコストの内訳

導入費は、ライセンスと開発、外部連携に分けて考えます。データ移行、教育、保守運用も、導入費の内訳に含めます。公式価格ページには一律の公開定価はなく、契約内容に応じたカスタム見積もり方式です。

ここで示す開発費は公式価格ではありません。2026年の業務システム開発の一般的な相場と、App Engine案件で発生しやすい工数から組み立てた推定レンジです。

▶ 詳細はこちら：ServiceNow App Engineのシステム開発の見積相場や費用/コスト/値段について

ライセンス費用の個別見積もり

公式価格ページには、App Engine FoundationとApp Engine Primeがあります。それぞれの機能や上限、契約条件を確認します。

Foundation：カスタムテーブル15個とスコープ付きアプリ3個が含まれます。
Prime：両方が無制限で、管理機能やAIを使う機能も加わります。
見積条件：ユーザーや契約、環境、機能、期間などの条件で金額が変わります。

プラン構成は、公式価格ページに示されています（出典：ServiceNow公式「App Engine Pricing」、2026年確認）。

金額は、利用ユーザーや既存契約、追加モジュールによって変わります。環境数や契約期間、サポート範囲でも変わるため、パッケージ名だけでは予算を断定できません。

見積もりでは、IntegrationHubとモバイル公開、分析、AI利用の条件を分けます。ライセンス費と作業費をまとめると、ユーザーやアプリ数が増えたときの増額条件が見えにくくなります。

規模別の開発費と期間の目安

規模によって開発費と期間は異なります。下の目安は、ライセンス費や保守費を含まない開発費の推定です。

小規模：300万〜1,000万円、1〜3か月。1部門の申請・承認や簡易台帳が目安です。
中規模：1,000万〜5,000万円、3〜6か月。複数部門のワークフローや連携を含みます。
大規模：5,000万円〜1億円以上、6か月〜1年以上。全社展開などが目安です。

中規模の場合は、通知や移行、ダッシュボードが含まれます。大規模では、複数インスタンスに加えて、複雑な監査や連携、モバイルも含まれます。

既存のインスタンスで、標準テンプレートを使った簡易検証だけを行う場合は、100万〜300万円程度に収まる可能性もあります。これは、本番品質のテストや移行、運用設計を十分に含まないPoC向けの金額です。

公式事例には、コンセプトからローンチまで6週間の例があります。ただし、この例はユーザーテストや専任エンジニアがいて、目的と既存基盤も明確なケースです。自社の見積もりでは、前提条件も比べます。

初期費用以外のランニングコスト

稼働後の費用は、運用・保守・開発体制に分けて見積もります。

運用：ライセンス更新や環境管理、監視、バックアップが継続します。
保守：初期開発費の年15〜25パーセントが目安です。
内製化支援：市民開発者の教育やレビューにも費用がかかります。

問い合わせや改修のほかに、アップグレードの影響調査や脆弱性対応、教育も必要です。保守費は、対応・受付時間や対象アプリ数で変わるうえ、改修範囲や復旧目標によっても変わります。

月額保守では、問い合わせや設定・開発変更、障害対応、アップグレードのどこまでを含むかを確認します。

受付や命名、データ・権限の決まりがないと、重複テーブルや不要な連携が生まれます。設計レビューやテスト、廃止の基準が欠けても、同じ問題につながります。

アプリが増えても管理できる状態を作ることが、長期的なコスト抑制につながります。

ポイント

費用は、ライセンス、規模別の開発費、稼働後の保守費に分けて比べます。金額は条件で変わるため、同じ前提の見積もりを並べて比べることが大切です。

ServiceNow App Engineの開発会社・サービスの選び方

知名度や見積金額だけでなく、設計・テスト・運用を一つの責任範囲として任せられるかを見ます。ServiceNowを導入できることと、App Engineで業務アプリを安全に増やせることは、同じではありません。

候補先には、近い実案件や担当者の資格と稼働率を具体的に確認します。標準機能を優先する方針や内製化支援、アップグレード対応についても、確かめます。

App Engineの実績と担当者の確認

ServiceNow全般の導入実績から、App Engineの開発力を読み取るのは難しいです。案件の内容と、担当者がどこまで関わったかを確かめます。

実績：申請・承認、ケース、台帳、モバイル、API連携の経験の有無
設計・担当：標準機能の使い分けや、担当者の資格・稼働を確認します。
引き継ぎ：成果物や別の保守先への移管条件の取り決め

カスタムテーブルやスコープ付きアプリの設計も聞きます。可能であれば、画面や要件定義書のサンプルを見せてもらい、テスト計画や運用引き継ぎ資料も確認します。

提案した専門家が実装やレビューに参加するかを確認します。認定や開発経験のほか、稼働予定や再委託の有無も確かめます。特に、自社の案件に誰が何時間関わるかを押さえておきます。

担当が交代する際の引き継ぎ方法や、別の保守先へ移せるドキュメントの範囲も、契約前に決めます。

見積もりの範囲と前提の比較

見積内訳は、要件定義から保守まで工程ごとに確認します。各工程の作業と費用が分かるように並べてもらいます。各社の前提や成果物も比べます。

見積範囲：対象外の作業と、追加費用が発生する条件を明示してもらいます。
提案条件：業務や件数、連携、移行の範囲、納品物、受入基準を示します。
契約条件：著作権法第27条・第28条の権利と第三者部品の扱い、再委託先の責任、契約終了後の保守移管を合意します。

「連携一式」と書かれている場合は、対象システムや件数を確認します。テストケースやリハーサル回数、障害修正の扱いも確かめます。対象外の作業が不明なままだと、後工程で総額が膨らむ可能性があります。

RFPには、業務フローや利用者数、月間処理件数を記載します。連携先や移行データ量、SLA、セキュリティ要件も書き込みます。

納品物には、設定一覧やデータモデル、ロール・ACL一覧を含めます。API仕様とテスト結果、運用・リリース手順も加えます。コードや設定の引き渡し条件も取り決めます。

内製化・運用・ガバナンスの視点

自社で安全に変更できる体制を作り、委託先の運用支援も確認します。

社内体制：アプリの審査、使ってよいデータや命名、本番変更の責任を決めます。
運用支援：教育やレビュー、影響調査、棚卸し、廃止支援を確認します。
提案比較：同じ業務、利用者数、連携条件のもとで各社を評価します。

価格や期間、実績だけでなく、標準機能の扱いや権限の説明も比べます。テスト、文書の品質、障害時の連絡経路も、同じ質問票で確かめます。

候補先には、管理者や市民開発者向けの教育、レビュー会、アップグレード前の調査が含まれるか確認します。複数社のPoC提案は、同じ条件で比べると判断しやすくなります。

▶ 詳細はこちら：ServiceNow App Engineのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：ServiceNow App Engineのシステム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、近い実案件と担当者の資格で絞り込みます。見積もりは対象外の作業と前提をそろえて比べ、引き継ぎ条件は契約前に決めておきます。

失敗しないためのセキュリティ・運用チェック

権限と情報の扱いをアプリ単位で見直す視点が並びます。

企業向け基盤の認証やセキュリティ認証が整っていても、自社アプリの設計ミスは防げません。そのため、アプリ単位の権限と監査ログ、データ保持を、自社規程に沿って確認します。連携認証やAI入力データの扱いも、自社規程に沿って点検します。

権限・監査・データ保護の確認

権限や法定記録、AI利用は、自社規程に照らして点検します。基盤の認証だけでは、自社アプリの設計ミスを防げません。

申請者と承認者、担当者を分けるほか、管理者と監査閲覧者も区別します。テーブルや添付のほか、ポータルやワークスペースへのアクセスも確認します。

管理者権限は普段は使わず、異動や退職のときはアカウントを無効化します。代理承認は記録し、機密項目の閲覧は制限します。

権限管理：役割別のアクセスや管理者権限を、定期的に棚卸しします。
情報保護：個人情報や法定記録の利用、保存、削除の点検
AI利用：入力区分、結果レビュー、学習条件、責任者を決めます。

権限は四半期ごとに見直し、不要なロールや休眠アプリは削除します。個人情報を扱う場合は、利用目的や保存期間、訂正・削除の方法を確認します。アクセス記録と委託先の管理も確かめます。

電子帳簿保存法やインボイス制度の対象業務では、検索要件や改ざん防止、証憑の保存責任を、業務・法務・経理の担当者が確認します。

AIによる部品生成や要約では、入力データの機密区分を決めます。生成結果のレビューや学習利用の条件、誤りの責任者も決めておきます。

よくある失敗と対策

標準データやワークフローと重複すると、二重入力と二重保守が発生します。要件定義を短縮しすぎると、例外処理や権限が本番直前に見つかることがあります。

標準機能の重複：比較表で既存機能を確かめてから作ります。
要件・品質不足：例外や権限、移行、テスト、教育を初期の計画に含めます。
運用の複雑化：担当者を置き、棚卸しと回帰テストを続けます。

移行後の未照合や、テスト環境を使わない本番変更、教育不足によるExcelへの回帰も起きます。開発初期には、対象外リストや権限表、連携エラー一覧を作ります。移行リハーサルやATFを含むテスト計画、受入基準も用意します。

アプリごとに業務と技術のオーナーを置き、稼働後の利用率と処理時間を測ります。四半期ごとの棚卸しと、アップグレード前の回帰テストも予定します。

ポイント

基盤の認証が整っていても、アプリごとの権限や監査、データ保持は別に確かめる必要があります。判断は自社規程に沿って行います。

よくある質問（FAQ）

費用、開発体制、既存システムとの関係に分けて回答します。契約や業務要件で変わる部分は、公式資料と個別見積もりで確認してください。

ServiceNow App Engineの料金はいくらですか？

FoundationかPrimeか、利用ユーザーや既存契約によって変わる個別見積もりです。追加機能や環境数、AI機能、契約期間も影響します。公開されている一律の定価からは判断できません。

開発費は別途かかります。小規模は300万〜1,000万円、中規模は1,000万〜5,000万円、大規模は5,000万円〜1億円以上が目安です。

これは開発費の推定であり、ライセンスや連携、移行、保守まで含めた総額ではありません。

現場部門だけでServiceNow App Engineを開発できますか？

テンプレートやApp Engine Studioを使い、現場部門が業務担当者としてアプリ作成に参加できます。

データモデルやロール・ACL、外部連携の設計は、IT部門や専門家がレビューする体制が必要です。テストやリリース、個人情報の扱いも、同じ体制で見ます。

現場のスピードとITの統制を両立させるため、責任分担を決めます。申請と審査、開発から本番展開までの各段階について、担当を明確にします。

既存のServiceNowや他システムと連携できますか？

連携できます。ServiceNow AI PlatformのAPIや、IntegrationHub、定期インポートなどを使えます。

申請・承認・通知・監査証跡をApp Engineに集約する一方で、正式なマスタや計算処理は既存システムに残す構成も可能です。

要件定義では、連携先の認証やデータの正本、同期時期を決めます。失敗時の再送や重複防止、個人情報の送受信範囲も定めます。

開発期間を短くするにはどうすればよいですか？

まず対象業務を一つに絞り、成果指標と利用者を早めに決めます。データ項目や承認経路、対象外も、早い段階で決めておきます。

標準テンプレートや既存ワークフローを優先し、開発・テスト・本番を分けてMVPを利用者に試してもらいます。

公式事例の6週間は参考になりますが、専任体制や既存基盤といった前提があります。自社で見積もる際は、要件確定、連携、移行、テストまで含めて考えます。

まとめ

ServiceNow App Engineは、ServiceNow AI Platformのデータやワークフロー、認証を使う開発基盤です。

監査やテスト、展開の仕組みも活かしながら、部門業務をローコードで追加できます。

申請・承認やケース管理、台帳などの業務に向いています。ポータルやモバイル、外部連携の場面でも使えます。導入前には、標準機能との境界と業務成果を決めておきます。

導入判断で外せないポイント

費用は、個別見積もりのライセンス費と規模別の開発費、連携・移行費、教育・保守費に分けて比較します。

開発会社は、App Engineの実績と担当者の専門性で選びます。そのうえで、権限・テスト・移行の設計力や内製化支援、納品物、保守移管の条件を比べます。

導入後の成果測定と段階的な拡大

重要業務のMVPから始め、非本番環境でのテストと権限レビューを行います。利用率や処理時間を測りながら段階的に広げると、長く使える業務システムにつながります。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。