ServiceNow App Engineのシステム開発は、業務課題を整理し、標準機能と追加開発の範囲を分けることから始まります。その後は6つのフェーズを順に進めます。
費用は規模と前提によって大きく変わるため、見積もりを比べる前に、各フェーズで何を決めるかを押さえておくことが大切です。
▼全体ガイドの記事
・ServiceNow App Engineのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ServiceNow App Engineのシステム開発の全体像
ServiceNow App Engineは、ServiceNow AI Platform上で業務アプリケーションとワークフローを構築・展開・管理する基盤です。ローコードで開発できる点も特徴です。
既存のITSM、HR、CSM、ITOMなどのデータや、認証、通知、監査の仕組みを活用し、新しい部門業務を追加する位置付けです。そのため、単独のパッケージで業務全体を置き換えるものではありません。
ServiceNow App Engineの概要
ServiceNow App Engineは、データ、画面、業務ロジック、自動化、セキュリティをガイド付きで組み立てる開発環境です。App Engine Studioに加えて、Studio IDE、Workspace Builder、モバイル、API・インテグレーションも含まれます。
Automated Test Framework（ATF）やDelegated Developmentも含まれます。さらに、App Engine Management Center（AEMC）も備え、開発ライフサイクル全体を支えます。向いている業務には、次のようなものがあります。
- 状態と担当者が変わる業務：申請・承認、問い合わせ・ケース管理
- 履歴を残す業務：資産・契約の台帳、点検、入社・異動のオンボーディング
- 部門をまたぐ業務：依頼管理など、複数部門で進捗を共有する業務
一方で、複雑なリアルタイム計算や独自の大量データ処理には、合わない場合があります。ServiceNowのデータモデルに合わない業務は、外部サービスやスクラッチ開発も含めて比べます。
標準機能と追加アプリの分け方
機能の置き場所は、次のように分けます。
- 標準機能：既存の申請・ケース機能で対応できる範囲と、重複の回避
- 追加アプリ：差別化につながる業務に絞り、Fit to Standardを基本とした範囲
- 外部システム：ServiceNow内に追加せず、外部に残す範囲
既存機能を確認しないままカスタムアプリを作ると、似たデータが分散し、ユーザーがどの機能を使うか迷うおそれがあります。そのため、判断に迷う機能は標準機能を優先し、差別化につながる業務だけを追加アプリに寄せます。
ServiceNow公式の2026年の価格ページでは、App Engine Foundationにカスタムテーブル15とスコープ付きアプリ3が含まれます。一方、App Engine Primeでは、どちらも無制限と説明されています（出典: ServiceNow「App Engine Pricing」、2026年確認）。
この情報は契約パッケージを比べるための材料です。条件は利用ユーザーや既存契約によって変わり、環境数やAI機能、追加モジュールでも変わります。そのため、公開定価を開発費としてそのまま当てはめないようにします。
ServiceNow App Engineのシステム開発の進め方
要件整理で決めた内容を、設計・開発で形にして稼働させます。選定、テスト、定着も、この流れの中で順に扱います。
- 選定：要件整理の次に、Fit to Standardと開発方式を比べる段階
- テスト：設計・開発の後に、業務シナリオと権限を検証する段階
- 定着：稼働の後に、市民開発とガバナンスを両立させる段階
小さく始める場合でも、権限、監査、連携、運用の判断は初期に確認しておきます。あわせて、MVP（Minimum Viable Product）の範囲と将来拡張の境界も合意します。
1. 要件整理：業務課題とKPIの設定
要件整理では、App Engineの導入そのものではなく、解決したい業務課題を言葉にします。たとえば、申請から承認までの処理時間を何日から何日にするか、メール依頼を何割減らすかを決めます。
対応漏れを何件以下に抑えるか、監査時にどの履歴を何分以内に出せるかも決めておきます。KPIを決めていないと、機能の完成だけで成功と判断することになり、利用状況を検証できません。
現行フローは、受付、判断、承認、差し戻しなどの状態に分けて整理します。完了や例外、取消しも、状態ごとに区切ります。
担当部署や入力項目、期限は表にまとめます。さらに、通知や添付の扱い、代理承認、監査証跡も表に加えます。
- 責任者と利用者：対象業務の責任者の決定と、利用者・管理者の区分
- 情報の扱い：個人情報・機密情報に当たる項目の特定
- 標準機能との重複：ServiceNow標準機能で対応できる範囲の確認
決まらない項目は未決事項として記録し、決定期限と決定者を置きます。
2. 選定：Fit to Standardと開発方式の比較
各機能の実現方法は、標準部品を優先して選びます。その際は、データや権限、運用まで含めて見ます。
- 実現方式：ServiceNow標準、App Engine設定・ローコード、スクリプト・外部開発、既存連携の比較
- 連携範囲：独自計算や外部マスタ同期への絞り込みと、アップグレードの影響の抑制
- 評価軸：画面だけでなく、データモデル、権限、運用者の作業まで含めた評価
- 標準部品：申請・承認の状態管理や通知での優先利用
既存契約がある場合は、App Engine FoundationまたはPrimeの対象範囲を確かめます。カスタムテーブル数、スコープ付きアプリ数、利用者の定義も、あわせて押さえます。
IntegrationHubやモバイルなどについては、追加条件がかかるかどうかも調べます。
開発会社には、App Engineの実案件と対象業務を尋ねます。また、担当者がCertified Application Developerなどの資格を持つかも確認します。
標準機能を優先する設計方針や、テスト環境と運用支援の有無も確かめます。候補を決める前にPoCを行うと、主要ユーザーの操作やデータ権限を試せるため、提案書だけでは見えない差を比べられます。
3. 設計・開発：データと権限の先行設計
画面より先に、データモデルと状態遷移を決めます。そのうえで、履歴や訂正のルールを固め、保存期間や削除の扱いも定めます。
- データ設計：テーブル、項目、参照関係、必須入力、重複判定の決定
- 画面作成：データ設計のあとに、UI BuilderやWorkspace Builderで行う構築
- 項目追加：KPIへの効果、データ品質、将来の保守負担の見極め
権限設計では、アプリのロール、テーブルの読み取り・作成・更新の権限、画面やワークスペースへのアクセスを分けます。
権限は、所属、担当、案件の機密区分に応じた最小権限を基本にします。特に、管理者が全件を閲覧できる設定は避けます。
権限設計の手順は、ServiceNow公式資料でも示されています（出典: ServiceNow「Add security in App Engine Studio」、2026年3月更新）。
4. テスト：業務シナリオと権限の検証
テストでは、開発者だけでテストを終えず、業務責任者にも受入基準を確認してもらいます。正常系以外の業務シナリオや権限、データの扱いも、テスト対象に含めます。
テストを削って納期を短く見せる提案は、稼働後の障害対応費用も含めて再評価します。
- 業務シナリオ：差し戻し、代理承認、期限超過、重複登録、連携先停止
- アクセスと添付：権限外の閲覧、退職者アカウント、添付ファイルの扱い
- テスト環境：マスキングするか、ダミーデータを使う
テスト後に残ったデータも削除します。開発、テスト、本番は分けたうえで、承認済みの変更だけをパイプラインで移送します。
AEMCでは、テスト環境へのデプロイ時にApplication Deployment Test Suiteを実行できます。さらに、Scoped App DefinitionsのInstance Scanも実行できます。
ATFとスキャンの結果は、デプロイメント要求から確認できます（出典: ServiceNow「Testing applications in AEMC」、2025年8月更新）。
5. 稼働：段階展開と切り戻しの準備
本稼働は全社一斉ではなく、対象の部門や業務を絞って段階的に展開します。あわせて、リリース判定と稼働直後の確認項目も決めておきます。
- リリース判定：受入テストと権限レビューの完了、重大な未解決不具合がないこと
- 稼働準備：連携監視、問い合わせ窓口、操作マニュアル
- 稼働後の指標：ログイン数、申請完了率、処理時間、差し戻し率、連携・権限エラー、問い合わせ件数
切り戻しでは、旧画面に戻すだけでは足りません。新アプリのデータや途中状態の申請をどう扱うかも決めておきます。
連携先へ送信済みのデータの訂正方法と、利用者への通知内容も定めます。また、AEMCのデプロイメント要求では、承認・拒否やChange Managementとの連携を管理できます。
発注側は、自社の変更管理ルールとつなぎ、責任者を明確にします（出典: ServiceNow「Manage deployment requests」、2026年3月更新）。
6. 定着：市民開発とガバナンスの両立
納品を完了地点にせず、利用状況を月次で確認して改善します。
- 利用状況：Excelやメールへの回帰、入力省略、承認の滞りの確認
- 改善と研修：責任者と改善バックログの更新、申請から問い合わせまでの流れに沿った操作研修
- ガバナンス：受付、データ分類、命名規則、ロールとACLのレビュー、ATF、公開承認のルール
- AI生成物：機密情報を入れないこと、人によるレビュー、テスト結果と承認記録の保存
市民開発者に任せる場合でも、自由に本番公開できる状態は避けます。また、所有者が不在になったときの引き継ぎや、利用率が低いアプリの廃止基準も定めます。
ServiceNow App Engineのシステム開発の費用相場
ServiceNow App Engineの費用は、ライセンス費用と開発費用を分けて考えます。公式価格ページはFoundationとPrimeを示しますが、円建ての一律定価ではなく、利用条件に応じた個別見積もりです。
ここで示す開発費は、一般的な業務システム開発の相場をもとに、要件整理や権限、連携の工数から組み立てた推定レンジです。テストや移行の工数も加えています。なお、ServiceNowの公式価格ではありません。
規模別の開発費の目安
規模別の推定費用と期間は、対象部門や連携、移行の範囲によって変わります。さらに、監査の範囲でも違いが出ます。
小規模開発は、1部門の申請・承認や台帳、簡易ポータルを既存インスタンス上に作る想定です。
- PoC・小規模：300万〜1,000万円、1〜3か月程度
- 中規模：1,000万〜5,000万円、3〜6か月程度
- 大規模：5,000万円〜1億円以上、6か月〜1年以上の場合がある
簡易な技術検証だけなら、100万〜300万円程度に収まる可能性があります。ただし、本番品質の要件定義や受入テスト、運用設計を含まないことがあり、本開発と金額だけで比べることはできません。
小規模開発は、既存認証や標準テーブルを使い、外部連携と移行を限定できることが前提です。中規模開発には、複数部門のワークフローや外部APIが含まれます。さらに、通知やダッシュボード、データ移行も含みます。
大規模案件には、全社業務の段階展開や複雑な連携・監査設計が含まれます。
複数インスタンスや厳格な監査がある場合、6〜12か月以上かかることがあります。モバイルや複数の基幹連携を含む場合も、同じ目安になります（出典: NotebookLM「業務システム全般_15」Q&Aを基にした2026年の推定）。
ライセンス・開発・連携・保守の費用の分け方
見積もりは費目ごとに分けて、含まれる作業を確認します。根拠のない月額や総額を断定せず、見積もりに含まれる作業と前提を並べて比べます。
- ライセンス：契約、利用ユーザー・利用量、追加モジュール、IntegrationHub、AI、モバイル、環境数
- 開発：要件定義、環境・データ設計、画面・フロー、連携、移行、ATF、教育、リリース
- 保守：問い合わせ、障害対応、アップグレード調査、脆弱性対応、追加アプリ審査
一般的な業務システムの費用配分では、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度が初期検討の目安です。
App Engineでは、画面を作る作業だけでなく、既存データとの関係やロールとACLの設計が費用を左右します。
保守費は、初期開発費の年15〜25%程度を目安に置けます。ただし、SLAや対応時間の条件で変わり、アップグレードや追加改修の範囲でも変動します。
公式事例の数字と前提条件
自社のユーザー数や申請件数を当てはめると、単純な開発費の比較より効果を判断しやすくなります。既存ライセンスや削減対象も、同じ前提に含めます。
公式事例の数字は、見積もり相場を断定するためのものではなく、実現可能性を考える材料です。
- Welcome.US：既存基盤や専任体制などの条件下で、コンセプトからローンチまで6週間
- Qlik：App Engine活用によるライセンス費用回避の事例
Welcome.USではユーザーテスト、ストーリーボード、能力マッピングを使いました。
Welcome.USは、緊急性の高い目的と既存基盤がそろっていた事例です。専任の関係者と複数パートナーが協働しています（出典: ServiceNow「Welcome.US Customer Story」、2026年確認）。
Qlikは、App Engine上で20のカスタムアプリを運用し、280ユーザーで月平均19,000件のリクエストを処理しました。
これらは個別の事例で、どの企業でも同じ期間や効果が得られるという意味ではありません。また、Qlikはマーケティング業務の移行で、16万2,000米ドルのライセンス費用を回避したとされています（出典: ServiceNow「Qlik App Engine Customer Story」、2026年確認）。
ServiceNow App Engineの見積もりを取る際のポイント
見積もりは総額の安さではなく、各フェーズと成果物の範囲で比べます。ローコード案件では、画面作成の金額が目立ちやすい一方で、データ移行や権限レビューが別料金になる場合があります。テストや教育、稼働後の改善も、別料金かどうかを確かめます。
RFPや相談資料に現行フローと前提条件を書き、同じ範囲で複数社に提案を依頼します。
見積もり前の業務・データ・非機能要件の整理
発注の前に、業務・データ・非機能要件を整理して、見積もりの条件をそろえます。ただし、ServiceNow基盤の認証取得だけでは、自社の権限や委託先管理は完了しません。
- 業務情報：フロー、対象部門・利用者数、申請・ケース、現行帳票、利用モジュール、KPI、希望時期
- 連携・移行：API、認証、送受信項目、頻度、再送、責任分界、履歴年数、重複・欠損、照合担当
- 非機能・契約：認証、権限、監査、保全、復旧、データ所在、再委託、関連法令
連携先の一覧と移行対象データ、権限区分も用意します。非機能要件には、SSOと多要素認証を含めます。
暗号化や脆弱性対応、障害通知の条件も、見積もりの前提として明記します。国外移転の扱いも書き添えます。
個人情報や請求情報を扱う場合は、個人情報保護法、電子帳簿保存法、インボイス制度など、関係する法令と契約条件を確認します。
複数社の見積もりの比べ方
各社の費用項目と成果物を同じ前提にそろえ、見積もりを比べます。
- 費目と範囲：ライセンス、要件定義、開発、連携、移行、テスト、教育、保守の費目と範囲
- 見積条件：前提、除外事項、成果物、検収条件、追加変更の単価、ATF本数
- 実施体制：担当者の資格と実績、実際の稼働割合
既存環境の調査を初期費用に含めるか、API連携を別プロジェクトにするかは、会社ごとに異なります。また、運用の引き継ぎ時間も確認します。
候補会社には、App Engineの対象業務やユーザー規模、連携数を尋ねます。稼働後の利用率やアップグレード対応も、あわせて聞いておきます。
保守を別会社へ移す場合は、設定情報や設計書、テスト仕様書の引き渡し条件を契約に記載します。運用手順書やソースコード、成果物も対象になります。
追加費用と失敗リスクの確認
見積もりでは、安さの裏に潜む省略と、機能の盛り込みすぎによる費用増を先に見ておきます。
- 省略リスク：安さを優先すると、短い要件定義やテスト環境・権限レビューの省略が起きる場合がある
- 追加費用：作らない機能、将来拡張の条件、変更要求の承認者、MVPの受入基準の決定
- 契約条件：ライセンスと受託範囲、障害・変更の定義、データ返却、権利と移管の明記
機能を盛り込みすぎると、スコープクリープが起き、使われない画面や複雑なスクリプトが増えます。
契約では、再委託先とデータの扱いを確認します。秘密保持やインシデント通知も押さえ、重要な判断は議事録と変更管理票に残します。
設定やコードの権利、著作権法27条・28条に関係する利用条件、別ベンダーへの保守移管の可否は、契約前に協議します。契約終了時の扱いも、あわせて定めます。
ServiceNow App Engineのシステム開発でよくある質問
期間や費用は一律には決まりません。既存契約や対象業務、連携の範囲に加えて、権限、テスト、運用体制から判断します。
ServiceNow App Engineはノーコードで開発できますか？
App Engineはローコード開発基盤です。テンプレートやガイド付き部品を使い、多くの画面やフローを効率よく作れます。
業務要件やデータモデルは、自動で正しく決まるものではありません。権限やAPI連携、テスト、リリース承認も、自動では決まりません。
標準部品で足りない部分は、スクリプトや外部連携で補います。さらに、必要に応じてServiceNowに詳しい開発会社のレビューを受けます。
ServiceNow App Engineの開発期間はどのくらいですか？
既存インスタンスを使い、1部門の申請・承認などに絞ったPoCや小規模開発なら、1〜3か月程度が推定目安です。
複数部門や外部API、データ移行を含む場合は、3〜6か月程度です。監査やモバイルを含む場合も、3〜6か月程度です。さらに、複雑な全社展開では6か月〜1年以上になることがあります。
Welcome.USの6週間は、明確な目的と専任体制、既存基盤やパートナーがあったという条件付きの実績です。そのため、自社の期間は要件とテストの範囲に当てはめて見積もります。
ServiceNow App Engineの開発を内製化できますか？
内製化は可能ですが、市民開発者とIT部門の役割分担が必要です。市民開発者は業務を理解し、IT部門はプラットフォーム、セキュリティ、リリースを管理します。
全社の誰もが本番公開できる状態にはせず、対象業務を一つに絞ります。そのうえで、開発標準や命名規則、権限レビューを整えます。ATFやアプリの申請・承認の流れも、あわせて決めておきます。
初期設計やガバナンスを外部会社に支援してもらい、段階的に運用を移管する方法もあります。
App Engineで個人情報を扱うときの注意点は何ですか？
個人情報を扱うときは、次の内容を要件に入れておきます。
- アクセス制御：最小権限、SSO・多要素認証、アクセスログ
- データの保存：保存期間、暗号化、バックアップ
- 外部との関係：国外移転、再委託、インシデント通知
要件に入れるだけでなく、業務ごとに閲覧範囲をテストします。ServiceNow基盤のセキュリティ認証があっても、自社のロール設計やデータ分類が適切とは限りません。
AI機能を使う場合は、入力データの扱いや生成結果のレビュー、本番投入の承認記録も確認します。
まとめ
ServiceNow App Engineの開発は、ローコードの速さだけで判断しません。業務課題とKPIを定め、標準機能との境界から定着までを一つの計画にまとめます。その計画には、データモデル、権限、連携、テスト、リリースの判断も含めます。
特に要件整理で決めた内容は、費用や期間、品質に大きく響きます。現場の利用率も、要件整理の内容で左右されます。
着手前に確認する項目
着手前には、対象業務とKPIを確かめます。加えて、利用者と責任者、標準機能との重複、App Engineの契約範囲も確認します。
さらに、カスタムテーブルとアプリ数、外部連携を整理します。移行データやロールとACLも、あわせて整理します。
非機能要件とATFを含むテスト計画、段階展開と切り戻しも確認します。教育や保守窓口もあらかじめ確かめておきます。そのうえで、RFPと見積もりの前提をそろえると、価格差を作業範囲の差として説明できます。
小さく始めて、測定しながら広げる方法
重要度の高い一つの業務をMVPとして選び、利用状況を測りながら改善します。
- 測定項目：利用率、処理時間、例外件数、問い合わせの推移
- 投資判断：公式事例を自社の前提に置き換えて読むこと
- 計画：ライセンス、開発、連携、保守の分離と、テストとガバナンスの確保
この進め方によって、Excelやメールへの回帰を防ぎ、App Engineを継続して使える業務基盤へ育てていきます。
▼全体ガイドの記事
・ServiceNow App Engineのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。