ServiceNow App Engineのシステム開発の発注/外注/依頼/委託方法について

ServiceNow App Engineの発注は、業務整理と委託範囲の決定、要件提示、契約・見積比較の順に進めます。この順で決めると、開発と運用の費用と責任を判断できます。

基盤の特徴から委託先の確認まで、各段階で決めることを示します。全体像は完全ガイドもご覧ください。

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

ServiceNow App Engineのシステムの概要

App Engine Studioで組み立てるデータ、画面、ロジック、自動化、セキュリティを5つのパネルで示した図。
5つの要素を組み合わせて業務アプリを構成します。

ServiceNow App Engineは、ServiceNow AI Platform上で業務アプリとワークフローを構築・展開・管理するローコード基盤です。ITSMやHR、CSM、ITOMなどと同じデータ・ワークフロー基盤を使います。

パッケージではなく業務アプリを追加する基盤

App Engineは単独の業務パッケージではありません。ServiceNowを利用中の企業では、既存のデータやワークフローにつなげて業務部門へ広げられる場合があります。別のスクラッチシステムを増やさずに済むこともあります。

具体的には、人事申請や購買依頼のような申請業務のほか、総務への問い合わせや設備点検も対象になります。契約台帳やオンボーディング、部門間のケース管理なども対象業務です。

App Engine Studioでは、ガイドに沿ってデータと画面を組み立て、ロジックや自動化、セキュリティも構成します。

たとえば、申請者がフォームに入力すると、条件に応じて承認者へ通知が届きます。担当部門が処理し、履歴と監査ログを残す流れも、同じ基盤で設計できます。

また、ServiceNowをITSMで使う企業には利点があります。別のクラウドへデータや認証を分散させず、標準のユーザーやロール、通知、レポートを使えます。

ただし、標準機能と重なる業務をApp Engineで作ると、申請や台帳が重複して運用が複雑になることがあります。そのため、発注の前に業務の配置先を分けておきます。

  • 既存モジュール:標準機能で対応する業務
  • App Engine:追加する業務
  • 外部システム:外部に残す業務

2026年のFoundationとPrimeの違い

2026年のServiceNow公式価格ページには、App Engine FoundationとApp Engine Primeが載っています(出典:ServiceNow公式「App Engine Pricing」、2026年)。

  • Foundation:カスタムテーブル15個とスコープ付きアプリ3個を含む構成
  • Prime:カスタムテーブルとスコープ付きアプリが無制限
  • Primeの追加機能:Foundationの機能に加え、App Engine Management CenterやProcess Miningを含む構成
  • Primeの追加機能:Mobile PublishingやPlatform Analytics Advancedなども含む

公式ページは一律の定価を載せておらず、個別見積もりです。価格は、利用ユーザーや既存契約、必要なモジュールによって変わります。さらに、環境数やAI機能、契約期間でも変わります。

発注先の開発費とは別に、ServiceNowのライセンス、追加モジュール、保守契約を分けて確認します。IntegrationHubなどの連携機能も、項目を分けて扱います。

ポイント

ServiceNow App Engineを使うかは、業務を標準機能、App Engine、外部システムのどこに置くかで判断します。ライセンスは個別見積もりのため、開発費とは別の項目として扱います。

ServiceNow App Engineの発注形態と進め方の選び方

MVPから始め、要件定義、設計・開発、テストを経てリリースする流れを示した図。
各段階で決める内容を順に積み上げます。

発注形態は、内製、ベンダーの伴走支援、要件定義から開発・運用までの一括委託から選びます。経験があり対象業務が明確であれば、内製や伴走型が合いやすいです。

一方で、App Engineが初めての場合や、複数部門・外部システムをまたぐ場合は、一括委託も選択肢になります。その場合も、発注者側に意思決定者を置きます。

内製・伴走支援・一括委託の使い分け

方式によって、社内に何が残るか、どんな専門性が必要か、どこまでを誰が受け持つかが変わります。

  • 内製:現場の改善を取り入れやすく、運用ノウハウが社内に残ります。
  • 伴走支援:社内担当者が業務知識と判断を担い、ベンダーが設計や教育を支援する形
  • 一括委託:要件定義から保守までの責任の範囲を、一つの契約にまとめやすい方式

内製では、データモデルやロール、ACLの設計を経験した担当者が必要です。加えて、IntegrationHubとATF、インスタンス間の移送を扱える担当者も欠かせません。

伴走支援では、ベンダーが設計レビューや難しい連携を支援し、テストや教育にも関わります。そのため、将来の市民開発者を育てたい企業と相性がよい方式です。

一括委託では、業務判断まで任せきりにすると、現場が使わないシステムになるおそれがあります。

発注者側は、業務責任者とServiceNow管理者、セキュリティ担当を参加させ、週次で決める体制を用意します。

RFPの業務目的と非機能要件の書き分け

RFPでは、「何を作るか」より先に「何を改善したいか」を明記します。そうすると、候補会社が同じ条件で提案できます。

  • 目的・KPI:申請処理の平均日数短縮、メール依頼のポータル集約、対応漏れの削減、監査での承認履歴確認
  • 現状:対象部門、利用者数、月間申請件数、Excel・メール運用、承認経路、例外処理
  • 機能:フォーム、申請・承認、担当割り当て、通知、検索、一覧、ダッシュボード、モバイル

機能要件には、データ移行とAPI連携も記載します。非機能要件では、SSO・多要素認証と最小権限を指定します。さらに、監査ログやバックアップ、データ保持期間も指定します。

可用性や性能、脆弱性対応のほか、インシデント通知、再委託、障害時の連絡時間も、非機能要件に含めます。

AI機能を使う場合は、入力データの扱いと生成結果のレビューを、RFPに記載します。また、本番投入の承認者やログの保存範囲も、RFPに含めます。

MVPの決め方と段階的な進め方

最初から全社の業務を置き換えず、重要度が高く関係者が協力しやすい業務を一つ選び、MVPに絞ります。

  • 要件定義:現行業務を一覧にし、標準機能、App Engine、外部連携の範囲を決めます。
  • 設計・開発:データモデルと画面、Flow DesignerやWorkflow Studioの自動化を実装します。
  • テスト:正常系のほか、権限不足や承認者不在、重複申請を確認します。

ロールやACL、通知、APIの設定も、設計・開発の段階で行います。また、連携先停止、移行後の検索、アップグレードの影響も、テストの対象です。

ServiceNow公式ドキュメントでは、こうしたテストを、App Engine Management Centerからテスト環境へデプロイする際に実行できると説明されています。具体的には、Application Deployment Test SuiteとScoped App Definitionsのインスタンススキャンが対象です(出典:ServiceNow公式ドキュメント、2025年更新)。

納品日を早めるためにテストや移行を削る提案は、避けます。

ポイント

発注形態は、社内に何が残るかと、どこまでを誰が受け持つかで選びます。RFPには業務目的と非機能要件を分けて書き、MVPは重要な一業務に絞ると迷いにくくなります。

ServiceNow App Engine開発の契約形態と費用相場の考え方

小規模、中規模、大規模の開発規模ごとに推定費用レンジを並べた横棒図。
対象範囲の広がりに応じて費用帯も上がります。

発注費用は、ライセンス費と開発費、連携・移行費、保守運用費に分けて比較します。ライセンス料金は、利用条件に応じた個別見積もりになり、一律の価格ではありません。

ライセンス費を開発会社の作業費と一緒にすると、本番稼働に必要な費用が後から増える場合があります。そのため、見積書では項目を分けておきます。

準委任と請負の工程ごとの使い分け

要件の確定度と成果物の完成責任を踏まえて、工程ごとに契約形態を選びます。

  • 準委任:作業時間や専門家の支援に対して報酬を支払う形態
  • 請負:合意した成果物を完成させ、検収を受ける形態

準委任は、要件が変わりやすい場面に向きます。たとえば、初期調査や業務整理、アーキテクチャ検討がそれにあたります。また、内製化支援や運用改善も準委任の場面になります。

成果物の完成責任や受け入れ基準を別に定めないと、作業時間だけが増えるおそれがあります。このため、契約や発注書には、月次の作業報告と稼働予定を残します。課題一覧と意思決定事項も、契約や発注書に記載します。

請負は、確定した要件に基づく画面やワークフロー、テスト仕様書、移行手順書などの開発に適しています。要件が変わった場合の扱いも、あらかじめ決めておきます。

要件定義は準委任、仕様確定後の開発は請負とする組み合わせもあります。契約書では、著作権や設定・ソースコードの帰属と利用権を確認します。設計書と引き継ぎ資料も対象です。

規模別の開発費の推定レンジ

下の金額は、2026年の業務システム開発相場と、App Engine案件で発生しやすい設定や連携、権限、テスト工数を踏まえた推定です。ServiceNowの公式価格ではありません。

金額は、既存インスタンスの有無や対象部門、利用者数で変わります。外部APIやデータ移行、監査要件によっても差が出ます。そこで、予算の初期検討に使い、最終的には同じRFPで見積もりを取ります。

  • 小規模:1部門の申請・承認、台帳、簡易ポータル、少数の権限で300万〜1,000万円程度
  • 中規模:複数部門のワークフロー、外部API、通知、ダッシュボード、データ移行を含み1,000万〜5,000万円程度
  • 大規模:全社業務、複数インスタンス、複雑な連携・監査、モバイル、段階展開を含み5,000万円〜1億円以上となる可能性

出典は、NotebookLMのリサーチノートにある2026年の業務システム開発相場です。上の金額は、この相場と案件条件をもとにした推定です。

ライセンス以外のランニングコスト

候補会社には、ライセンス販売の部分と開発・保守の部分を分けた見積書を依頼します。初期費用では、契約費と、追加機能や運用にかかる費用を確認します。

  • 環境:ServiceNow契約費、開発・検証用の利用条件
  • 追加機能:IntegrationHubなどの連携機能、AI機能、モバイル
  • 利用・運用:追加ユーザー、データ保管、監視、サポート

Primeの管理機能が増えても、総額は対象ユーザーや契約範囲によって変わります。

保守では、問い合わせや障害対応、権限変更、軽微な改修が発生します。加えて、アップグレードの影響調査や脆弱性対応、テスト再実行、利用状況の確認もあります。

初期開発費の年15〜25%程度を、保守費の検討材料にする方法があります。ただし、これは契約範囲を決める一般的な目安で、料金を断定するものではありません。

月間の対応時間やSLA、休日対応を明記します。追加開発の単価と、契約終了時の引き継ぎも書いておきます。

ポイント

契約は、要件が固まっているかで準委任と請負を工程ごとに分けます。費用はライセンス費と開発費を混ぜず、保守の範囲や別途作業まで見積書でそろえると、総額を同じ条件で比べられます。

委託先選定と見積比較の確認項目

委託先は、App Engineの実務経験やServiceNowの認定・パートナー情報を確認して選びます。知名度や見積総額は、それらと並べて判断します。加えて、担当者の稼働、標準機能を優先する設計、テスト・運用体制も確認します。

提案の場では、営業担当だけでなく、要件定義の担当者やアプリ開発者が説明できるかも見ます。ServiceNow管理者と連携担当者についても、それぞれ説明できるかを確認します。

実案件・認定・担当者の確認

候補の実績や認定は、確認できる資料と、実際に参加する担当者の体制で評価します。

  • 実績:作成業務、標準・カスタムの区分、利用者数・運用期間、外部連携、アップグレード対応
  • 非公開時:匿名化した画面や成果物サンプル、プロジェクト体制、テスト計画
  • 認定・ランク:候補選定の材料にはなりますが、資格の数だけで品質が決まるわけではありません。

NRIは2025年11月27日に、ServiceNowから認定を取得しました。この認定は、App Engine分野では国内初のValidated Practice認定で、NRIが2026年4月16日に発表しています(出典:NRI公式発表、2026年)。

自社案件に参加する担当者について、認定や経験年数、稼働率、再委託の有無を確認します。

見積書の工程・成果物・除外事項の読み比べ

見積書は工程ごとに分けてもらい、成果物やレビュー回数を記載してもらいます。また、発注者が用意する資料、ServiceNow環境の前提、対象ユーザー数・データ件数も書いてもらいます。

  • 工程:要件定義、現行調査、基本設計、データモデル、画面・ワークフロー設定
  • 実装・移行:API連携、権限設計、データ移行、テスト、教育、リリース
  • 運用:保守、各工程の成果物とレビュー回数

要件定義やテスト、移行が「別途」となっている場合は、注意が必要です。マニュアルやリリース後の安定化支援が別途扱いの場合も、確認が必要です。特に、別途作業が多いと、開発費が低くても総額が上がります。

高額な提案には、標準機能の活用や運用設計、教育、移管まで含まれている可能性もあります。そのため、同じ範囲にそろえて比べます。

権限・テスト・引き継ぎの評価

App Engineでは、画面やデータの権限設計と、テスト結果を確認します。

  • 画面・データ:表示する内容とテーブルの読み書きを、業務単位で設計
  • 権限:ロール、ACL、ワークスペースへのアクセスを、業務単位で分ける
  • 閲覧範囲:人事・契約情報を、申請者、承認者、担当者、管理者、監査担当で分ける
  • 権限テスト:権限マトリクス、テストアカウント、拒否すべき操作の結果を納品物に含める提案かを評価

ServiceNow公式のQlik事例では、App Engine上のカスタムアプリ20個を280ユーザーが利用し、月平均19,000件のリクエストを処理しています。

同事例では、課題解決時間が35%短縮され、ライセンス費用16万2,000ドルの回避につながったと紹介されています(出典:ServiceNow公式Qlik事例、2026年確認)。

ただし、数字をそのまま他部門へ当てはめるのではなく、複数部門で使い続けるための設計を見ます。受付や担当振り分け、進捗の管理が、その中心になります。セキュリティルールと運用改善の設計も見ておきます。

契約終了後に自社で運用できるよう、アプリ定義や設定一覧、データモデルを引き渡してもらいます。ロール・ACL一覧やAPI仕様、テスト結果も必要です。

移行手順と障害対応手順、アップグレード影響調査の方法も対象です。著作権や設定の利用権、第三者ライセンスは契約書に記載します。再委託先やデータ削除、別ベンダーへの保守移管は、契約書で定めます。

ベンダーロックインを避けることは、将来の交渉力と安全な運用につながります。

ポイント

委託先は、App Engineの実務経験や担当者の体制を確かめたうえで、見積もりを同じ範囲でそろえて比べます。総額だけで決めると、テストや移行、保守の抜けに気づきにくくなります。

よくある質問(FAQ)

外注では、費用だけでなく、既存ServiceNowとの関係や契約範囲を確認します。将来の内製化やセキュリティも、外注時に確かめておく事項です。よくある疑問に順に答えます。

ServiceNow App Engineは自社だけで開発できますか?

可能です。ただし、ServiceNowの管理経験がある担当者がいて、業務要件を整理し、権限設計やテスト、リリース管理を社内で担えることが条件になります。

最初はベンダーの伴走でMVPを作り、設計レビューや教育を受けながら段階的に内製へ移す方法が現実的です。

ローコードなら開発費は必ず安くなりますか?

必ず安くなるとは限りません。画面作成の工数は抑えられても、業務整理やデータモデル、複雑な承認には工数がかかります。外部APIや権限の設計、移行、テストにも手間がかかり、教育や運用設計も見込む必要があります。

標準機能を活用し、対象業務を絞り、将来の変更を見越して設計すると、開発費だけでなく総保有コストも抑えられます。

発注前にServiceNowのライセンスを契約すべきですか?

先に契約を決めるより、対象業務と利用者、必要なテーブル数を整理します。そのうえで、スコープ付きアプリやAI・連携機能、環境数を、ServiceNowと開発会社に確認します。

既存契約で使える機能と、追加契約が必要な機能を分けて、個別見積もりの前提条件を文書に残します。

見積もりは何社から取ればよいですか?

比較できるRFPを用意し、3社程度から取ると、価格と提案内容の違いを把握しやすくなります。

社数を増やすより、App Engineの実績や担当者、標準機能の方針、テスト・移行・保守の範囲を、同じ質問で確認します。

提案内容に大きな差がある場合は、最安値を選ぶ前に前提条件と除外事項をそろえます。

まとめ

発注時は、ローコードという言葉だけで安さや納期を判断せず、既存ServiceNowの標準機能との役割分担を決めます。次に、業務目的とKPIを整理します。

RFPでは、機能要件と非機能要件を分けて提示します。契約と見積もりでは、総額と責任の分け方を確かめます。

発注判断での総額と責任の分け方

費用は、ライセンス費と開発費、連携・移行費、保守運用費に分けて見ます。規模別の推定レンジは、小規模が300万〜1,000万円、中規模が1,000万〜5,000万円、大規模が5,000万円〜1億円以上です。

契約は、準委任と請負を工程に応じて使い分けます。成果物と検収、変更管理について合意します。著作権や設定・ソースコードの引き渡しも、合意事項に含めます。

見積書では、要件定義や権限、テストの範囲を確かめます。移行や教育、保守の範囲も、それぞれ見ておきます。そのため、合計金額だけで判断しないようにします。

最初に相談する重要業務のMVP

最初に、現場が困っている業務を一つ選びます。そのうえで、利用者数や月間件数、承認経路を整理します。現行資料や連携先、セキュリティ条件も、材料としてそろえます。

複数社を比べるときは、実案件の経験や担当者の認定を見ます。標準機能を優先する方針や、テスト・運用の範囲も比べます。小さく始め、利用状況と成果を確認してから効果が見えた業務へ広げると、定着につながります。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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