ServiceNow App Engineのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

ServiceNow App Engineのシステム開発は、申請・承認やケース管理などの業務をServiceNowの共通データ基盤とワークフローに載せ、要件整理から定着までを段階的に管理する進め方が成功の近道です。

ローコードで作れるからといって、いきなり画面を作り始めると、権限の抜け、既存機能との重複、連携仕様の追加、現場が使わない機能が発生しやすくなります。本記事では、ServiceNow App Engineのシステムを実務で進める流れを、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズに分け、判断基準、チェック項目、費用相場、見積もりの読み方まで解説します。

▼全体ガイドの記事
・ServiceNow App Engineのシステム開発の完全ガイド

ServiceNow App Engineのシステム開発の全体像

ServiceNow App Engineは、ServiceNow AI Platform上で業務アプリケーションとワークフローを構築・展開・管理するためのローコード開発基盤です。単独のパッケージとして業務を置き換えるというより、すでに利用しているITSM、HR、CSM、ITOMなどのデータや認証、通知、監査の仕組みを活用して、新しい部門業務を追加する位置付けで考えると理解しやすくなります。

ServiceNow App Engineとは、データ、画面、業務ロジック、自動化、セキュリティをガイド付きで組み立てる開発環境です。App Engine Studioだけでなく、Studio IDE、Workspace Builder、モバイル、API・インテグレーション、Automated Test Framework（ATF）、Delegated Development、App Engine Management Center（AEMC）までを含めて、開発ライフサイクル全体を支える基盤として扱います。

向いているのは、申請・承認、問い合わせ・ケース、資産や契約の台帳、点検、入社・異動のオンボーディング、部門横断の依頼管理など、状態と担当者が変化し、履歴を残したい業務です。一方で、複雑なリアルタイム計算、独自の大量データ処理、ServiceNowのデータモデルと合わない業務は、外部サービスやスクラッチ開発を含めて比較する必要があります。

最初に、現行のServiceNow標準機能で対応できる範囲、App Engineで追加する範囲、外部システムに残す範囲を分けます。既存の申請機能やケース機能を確認せずに新しいカスタムアプリを作ると、似たデータが分散し、ユーザーがどちらを使うべきか分からなくなります。判断に迷う機能は、標準機能を優先し、差別化につながる業務だけを追加アプリに寄せるFit to Standardの考え方が安全です。

なお、ServiceNow公式の2026年の価格ページでは、App Engine Foundationにカスタムテーブル15、スコープ付きアプリ3が含まれ、App Engine Primeではそれぞれ無制限と説明されています。これは契約パッケージの比較材料ですが、利用ユーザー、既存契約、環境数、AI機能、追加モジュールによって条件が変わるため、公開定価として開発費に置き換えないことが重要です（出典: ServiceNow「App Engine Pricing」、2026年確認）。

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

開発は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで進めます。小さく始める場合でも、後から必ず必要になる権限、監査、連携、運用の判断を最初から確認し、MVPの範囲と将来拡張の境界を合意しておくことが大切です。

要件整理では、最初に「App Engineを導入すること」ではなく、解決したい業務課題を言語化します。たとえば、申請から承認までの処理時間を何日から何日にするのか、メール依頼を何割減らすのか、対応漏れを何件以下にするのか、監査時にどの履歴を何分以内に出せるようにするのかを決めます。KPIがないと、機能が完成した時点で成功と判断してしまい、使われているかを検証できません。

次に、現行フローを受付、判断、承認、差し戻し、完了、例外、取消しの状態に分けます。担当部署、入力項目、参照データ、期限、通知、添付ファイル、代理承認、監査証跡も表にします。要件整理のチェックポイントは、対象業務の責任者が決まっていること、利用者と管理者を分けていること、個人情報や機密情報の項目を特定していること、ServiceNow標準機能との重複を調査していることです。ここで決められない項目は、未決事項として期限と決定者を置きます。

選定フェーズでは、業務の各機能を、ServiceNow標準、App Engineの設定・ローコード、スクリプトや外部開発、既存システム連携のどれで実現するか比較します。申請・承認の状態管理や通知は標準部品を優先し、独自の計算や外部マスタとの同期だけを連携対象にすると、アップグレード時の影響を抑えやすくなります。画面の見た目だけで選ばず、データモデル、権限、運用者の作業まで含めて評価します。

既存のServiceNow契約がある場合は、App Engine FoundationまたはPrimeの対象範囲、カスタムテーブル数、スコープ付きアプリ数、利用者の定義、IntegrationHubやモバイルなどの追加条件を確認します。開発会社を選ぶ場合は、App Engineの実案件と対象業務、Certified Application Developerなど担当者の資格、標準機能を優先する設計方針、テスト環境と運用支援の有無を質問します。候補を決める前に、PoCで主要ユーザーの操作とデータ権限を確認できると、提案書だけでは見えない差を比較できます。

設計・開発では、画面より先にデータモデルと状態遷移を決めます。テーブル、項目、参照関係、必須入力、重複判定、履歴の保存期間、削除や訂正のルールを設計し、その上でUI BuilderやWorkspace Builderなどの画面を作ります。現場から「この項目も追加してほしい」と要望が出たときは、KPIへの効果、データ品質への影響、将来の保守負担を確認してから採用します。

権限設計では、アプリのロール、テーブルの読み取り・作成・更新権限、画面やワークスペースへのアクセスを分けて確認します。管理者だから全件閲覧できるという単純な設定にせず、所属、担当、案件の機密区分などを条件にした最小権限を基本にします。ServiceNow公式ドキュメントでも、App Engine Studioでロールとテーブル権限、画面・ワークスペースのアクセスを設計する手順が示されています（出典: ServiceNow「Add security in App Engine Studio」、2026年3月更新）。

テストは、正常系だけでなく、差し戻し、代理承認、期限超過、重複登録、連携先停止、権限外の閲覧、退職者アカウント、添付ファイルの扱いまでシナリオ化します。開発者の確認だけで終わらせず、業務責任者が受入基準を確認し、テストデータを本番データと分離します。個人情報を扱う場合は、マスキングされたデータやダミーデータを用い、テスト後の残存データも削除します。

開発・テスト・本番のインスタンスを分け、承認済みの変更だけをパイプラインで移送します。ServiceNow公式のAEMCでは、テスト環境へのデプロイ時にApplication Deployment Test SuiteとScoped App DefinitionsのInstance Scanを実行でき、ATFの結果やスキャン結果をデプロイメント要求から確認できます（出典: ServiceNow「Testing applications in AEMC」、2025年8月更新）。テストを削って短納期に見せる提案は、稼働後の障害対応費用まで含めて再評価する必要があります。

本稼働では、全社一斉展開よりも、対象部門や業務を絞った段階展開が基本です。リリース判定の条件として、受入テストの完了、重大な未解決不具合がないこと、権限レビューの完了、連携監視の設定、問い合わせ窓口の準備、操作マニュアルの公開を明文化します。稼働直後に見る指標は、ログイン数、申請完了率、処理時間、差し戻し率、連携エラー、権限エラー、問い合わせ件数です。

切り戻し手順は、単に旧画面へ戻すだけでは不十分です。新アプリに登録されたデータをどう扱うか、途中状態の申請を誰が処理するか、連携先へ送ったデータをどう訂正するか、利用者へ何を通知するかまで決めます。AEMCのデプロイメント要求では、承認・拒否やChange Managementとの連携を管理できるため、自社の変更管理ルールとつなげて責任者を明確にします（出典: ServiceNow「Manage deployment requests」、2026年3月更新）。

定着フェーズでは、納品を完了地点にせず、利用状況を見ながら改善します。利用者がExcelやメールに戻っていないか、入力が省略されていないか、承認が滞っていないかを月次で確認し、業務責任者と改善バックログを更新します。操作研修は機能説明だけでなく、実際の申請、差し戻し、代理処理、検索、問い合わせの流れを使って行うと、現場が自分の業務に置き換えて理解しやすくなります。

市民開発者にアプリ作成を任せる場合も、自由に本番へ公開できる状態は避けます。アプリの受付、データ分類、命名規則、ロールとACLのレビュー、ATFの実施、公開承認、所有者不在時の引き継ぎ、利用率が低いアプリの廃止基準を運用ルールにします。AIで生成した画面やロジックを使う場合は、入力データに機密情報を含めないこと、生成物を人がレビューすること、テスト結果と承認記録を残すことを必須にします。

ServiceNow App Engineのシステム開発の費用相場

ServiceNow App Engineの費用は、ライセンス費用と開発費用を分けて考えます。ServiceNowの公式価格ページはFoundationとPrimeのパッケージを示していますが、公開された一律の円建て定価ではなく、利用条件に応じた個別見積もりです。以下の開発費は、一般的な業務システム開発の相場と、App Engineで発生しやすい要件整理、権限、連携、テスト、移行の工数から組み立てた推定レンジであり、ServiceNowの公式価格ではありません。

1部門の申請・承認、台帳、簡易ポータルを既存インスタンス上に作るPoCや小規模開発は、開発費300万〜1,000万円程度が一つの推定目安です。期間は1〜3か月程度ですが、既存の認証や標準テーブルを使い、外部連携と移行を限定できることが前提です。簡易な技術検証だけなら100万〜300万円程度に収まる可能性もありますが、本番品質の要件定義、受入テスト、運用設計を含まない場合があるため、金額だけで本開発と比較してはいけません。

複数部門のワークフロー、外部API、通知、ダッシュボード、データ移行を含む中規模開発は、1,000万〜5,000万円程度、期間は3〜6か月程度が推定レンジです。要件が複雑で、複数インスタンス、厳格な監査、モバイル、複数の基幹連携を含む場合は6〜12か月以上になることがあります。全社業務を段階展開し、複雑な連携や監査設計を含む大規模案件は、5,000万円〜1億円以上、6か月〜1年以上を見込むことがあります（出典: NotebookLM「業務システム全般_15」Q&Aを基にした2026年の推定）。

見積書では、まずApp Engineのライセンス、利用ユーザーや利用量、追加モジュール、IntegrationHub、AI機能、モバイル、環境数を確認します。次に、要件定義、環境構築、データ設計、画面・フロー開発、API連携、移行、ATFを含むテスト、教育、リリースを開発費として分けます。最後に、問い合わせ、障害対応、アップグレード影響調査、脆弱性対応、追加アプリの審査を保守費として確認します。

一般的な業務システムの費用配分を応用すると、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度が初期検討の目安になります。ただしApp Engineでは、画面の実装よりも、既存データとの関係、ロールとACL、外部連携、ATF、リリースパイプライン、教育が費用を左右します。保守費は初期開発費の年15〜25%程度を目安に置けますが、SLA、対応時間、アップグレード、追加改修の範囲で変動します。根拠のない月額や総額を断定せず、含まれる作業と前提を並べて比較してください。

公式事例の数字は、見積相場の断定ではなく、実現可能性を考える材料です。ServiceNow公式のWelcome.US事例では、ユーザーテスト、ストーリーボード、能力マッピングを使い、コンセプトからローンチまで6週間で進めたと紹介されています。緊急性の高い目的、既存基盤、専任の関係者、複数パートナーの協働がそろった事例であり、すべての企業が6週間で稼働できるという意味ではありません（出典: ServiceNow「Welcome.US Customer Story」、2026年確認）。

また、Qlikの事例では、App Engine上で20のカスタムアプリを運用し、280ユーザー、月平均19,000件のリクエストを処理し、マーケティング業務の移行で16万2,000米ドルのライセンス費用回避を得たとされています。自社のユーザー数、申請件数、既存ライセンス、削減対象を当てはめて効果を試算すると、単純な開発費比較よりも投資判断がしやすくなります（出典: ServiceNow「Qlik App Engine Customer Story」、2026年確認）。

ServiceNow App Engineの見積もりを取る際のポイント

ServiceNow App Engineの見積もりは、総額の安さではなく、どのフェーズと成果物が含まれているかで比較します。特にローコード案件では、画面作成の工数だけが目立ち、データ移行、権限レビュー、テスト、教育、リリース後の改善が別料金になっていることがあります。RFPや相談資料に現行フローと前提条件を記載し、同じ範囲で複数社に提案を依頼してください。

発注前に用意する資料は、業務フロー図、対象部門と利用者数、申請やケースの種類、現行帳票、既存ServiceNowの利用モジュール、連携先一覧、移行対象データ、権限区分、KPI、希望時期です。連携先については、APIの有無、認証方式、送受信項目、頻度、エラー時の再送、責任分界を整理します。データ移行では、件数だけでなく、過去履歴を何年分移すか、重複や欠損をどう扱うか、移行後に誰が照合するかを決めます。

非機能要件は、SSOと多要素認証、最小権限、監査ログ、バックアップ、データ保持期間、暗号化、脆弱性対応、障害通知、復旧目標、国外移転・データ所在、再委託の条件を明記します。個人情報や請求情報を扱う場合は、個人情報保護法、電子帳簿保存法、インボイス制度など、自社業務に関係する法令と契約条件を確認します。ServiceNowの認証や基盤の認証取得だけで、自社のアクセス権限や委託先管理まで完了するわけではありません。

複数社を比較するときは、ライセンス販売、要件定義、開発、連携、移行、テスト、教育、保守の費目をそろえます。開発会社によって、既存ServiceNowの調査を初期費用に含めるか、API連携を別プロジェクトにするか、ATFを何本作るか、運用引き継ぎを何時間含めるかが異なります。見積書の金額だけでなく、前提、除外事項、成果物、検収条件、追加変更の単価を横並びにします。

候補会社には、App Engineの実績を件数だけでなく、対象業務、ユーザー規模、連携数、稼働後の利用率、アップグレード対応まで確認します。担当者の資格や実績が提案時だけのものではないか、実際に誰が何割稼働するかも質問します。保守を別会社へ移管する可能性がある場合は、設定情報、設計書、テスト仕様書、運用手順書、ソースコードや成果物の引き渡し条件を契約に記載します。

見積もりの安さを優先すると、要件定義が短く、テスト環境がなく、権限レビューが省略されることがあります。反対に、機能を盛り込みすぎるとスコープクリープが起こり、利用されない画面や複雑なスクリプトが増えます。見積もり段階で「今回作らない機能」「将来拡張する条件」「変更要求の承認者」を明確にし、MVPの受入基準を決めておくと、追加費用の発生点を管理できます。

契約では、ServiceNowのライセンスと受託開発の範囲を分け、障害と仕様変更の定義、再委託先、データの取り扱い、秘密保持、インシデント通知、契約終了時のデータ返却を確認します。受託開発で作った設定やコードの権利、著作権法27条・28条に関係する利用条件、別ベンダーへの保守移管可否も、納品後ではなく契約前に協議します。重要な判断を口頭で済ませず、議事録と変更管理票に残してください。

ServiceNow App Engineのシステム開発でよくある質問

ここでは、ServiceNow App Engineの進め方を検討する企業から寄せられやすい質問に回答します。期間や費用を一律に決めるのではなく、既存契約、対象業務、連携、権限、テスト、運用体制という条件から判断することがポイントです。

App Engineはローコード開発基盤であり、テンプレートやガイド付きの部品を使って多くの画面やフローを効率よく作れます。ただし、業務要件の整理、データモデル、権限、API連携、テスト、リリース承認までを自動で正しく決めるものではありません。標準部品で足りない部分だけをスクリプトや外部連携で補い、必要に応じてServiceNowに詳しい開発会社のレビューを受ける進め方が現実的です。

既存インスタンスを利用し、1部門の申請・承認などに絞ったPoCや小規模開発なら、1〜3か月程度が推定目安です。複数部門、外部API、データ移行、監査、モバイルを含むと3〜6か月程度、複雑な全社展開では6か月〜1年以上になることがあります。Welcome.USの6週間という公式事例は、明確な目的と専任体制、既存の基盤・パートナーがあった条件付きの実績なので、自社の期間見積もりには要件とテストの範囲を当てはめてください。

内製化は可能ですが、業務を理解する市民開発者と、プラットフォーム、セキュリティ、リリースを管理するIT部門の役割分担が必要です。最初から全社の誰でも本番公開できるようにせず、対象業務を一つに絞り、開発標準、命名規則、権限レビュー、ATF、アプリの申請・承認を整えます。初期設計やガバナンスだけを外部会社に支援してもらい、段階的に運用を移管する方法も選択肢になります。

最小権限、SSO・多要素認証、アクセスログ、保存期間、暗号化、バックアップ、国外移転、再委託、インシデント通知を要件に含め、業務ごとに誰が何を見られるかをテストします。ServiceNowの基盤側にセキュリティ認証があっても、自社のロール設計やデータ分類が適切になるとは限りません。AI機能を使う場合は、入力データの取り扱い、生成結果のレビュー、本番投入の承認記録も確認してください。

まとめ

ServiceNow App Engineのシステム開発は、ローコードの速さだけで判断せず、業務課題とKPIを定め、標準機能との境界、データモデル、権限、連携、テスト、リリース、定着までを一つの計画として進めます。特に要件整理で決めたことが、費用、期間、品質、現場の利用率を大きく左右します。

着手前には、対象業務とKPI、利用者と責任者、標準機能との重複、App Engineの契約範囲、カスタムテーブルとアプリ数、外部連携、移行データ、ロールとACL、非機能要件、ATFを含むテスト計画、段階展開、切り戻し、教育、保守窓口を確認してください。これらをRFPと見積書の前提にそろえると、会社ごとの価格差を作業範囲の差として説明できます。

最初は重要度の高い一つの業務をMVPとして選び、利用率、処理時間、例外件数、問い合わせを測定しながら改善する進め方が適しています。ServiceNow公式事例の短期間や大きな効果は参考になりますが、自社の前提に置き換えて判断することが必要です。ライセンス、開発、連携、保守の費用を分け、テストとガバナンスを削らない計画にすることで、Excelやメールへの回帰を防ぎ、App Engineを継続的に使える業務基盤へ育てられます。

▼全体ガイドの記事
・ServiceNow App Engineのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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