---
sourceDocument: オーストラリア ServiceNow AI Platform の機能
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/servicenow-platform

 Release :

    - australia

ft:locale :

    - ja-JP

ft:publication_title :

    - オーストラリア ServiceNow AI Platform の機能

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# カスタマイズと構成

# カスタマイズと構成 {#ariaid-title1}

* リリースバージョン: Australia
* 
* 更新日 2026年03月12日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：14分

ServiceNowアプリケーションのカスタマイズと構成には重要な違いがあります。ServiceNowプラットフォームはカスタマイズと構成に対応するように構築されていますが、その方法は、ServiceNowサポート、将来のServiceNowプラットフォームバージョンへのアップグレード、およびServiceNowプラットフォームの機能に大きな影響を与える可能性があります。  
カスタマイズに関する一般的なルールは次のとおりです。

* アプリケーションの本来の意図を拡張する場合にのみ、アプリケーションをカスタマイズします。たとえば、 ITSM に IT 機能を追加しますが、出張ワークフローは追加しません。アプリケーションを過度にカスタマイズするのではなく、クリエータースタジオ や ServiceNow スタジオ などのApp Engine製品を使用して新しいアプリケーションを作成します。
* アプリケーションをカスタマイズする前に、できる限り設定してください。
* すぐに利用可能な機能にコードを追加したり、その他の変更を加えたりした場合、それらの機能を所有するものになります。
{#customization-vs-configuration-concepts__ul_ynr_n4h_1fc}

## 構成とは {#customization-vs-configuration-concepts__what-is-configuration}

構成とは、ServiceNowインスタンスでのベースラインインストールの一部であるフローやコードを変更することなく、ServiceNowビルトインツールと機能を使用してアプリケーションの動作を変更するプロセスです。

構成には、 ServiceNow 組み込みツールを使用してテーブルなどを追加したり、インスタンス全体のパラメーターを設定したり、コードがベースラインコードインストールを変更しない限り、コードを使用してアプリケーションの機能を拡張してビジネスニーズを満たすという形式をとることができます。プラットフォーム全体が、構成コードを追加できるように設計されています。

ワークフロースクリプトなどのコードを追加すれば、ベースラインコードのインストールが変更されなくても、そのコードを所有することになります。これには、 ServiceNow プラットフォーム全体に与える影響を所有することも含まれます。追加されたコードから発生する問題は、デバッグ ServiceNow サポートの範囲外です。

構成を元に戻しても、ベースラインコードを変更する必要はありません。  
構成例を次に示します。

* フォーム:テーブル、フィールド、データタイプ、デフォルト値、およびフィールドの依存関係を構成して、キャプチャして表示するデータを構成します。
* UI 要素:レイアウトの変更、関連リストの追加、ボタンの追加、フィールド名の変更。
* サービスカタログ:顧客がサービスや製品オファリングなどのカタログアイテムを要求できるポータルを構成します。
* ACL:権限のないユーザーがフォームやデータにアクセスできないようにします。
* システムプロパティ値:すべてのユーザーのアプリケーションのエクスペリエンスを変更します。
{#customization-vs-configuration-concepts__ul_qjc_w4h_1fc}

## カスタマイズとは {#customization-vs-configuration-concepts__what-is-customization}

カスタマイズとは、 ServiceNow インスタンスでのベースラインインストールの一部であるフローまたはコードに加えられた変更です。ServiceNow製品またはコードを使用してアプリケーションをカスタマイズします。

コードを追加すれば、ベースラインインストールが変更されなくても、そのコードを所有することになります。これには、 ServiceNow プラットフォーム全体に与える影響を所有することも含まれます。  
カスタマイズの例を次に示します。

* スクリプティング:JavaScript を使用したスクリプティングによって ServiceNow をカスタマイズします。これには、ベースラインコードを変更する複雑なロジックを使用したクライアントスクリプト、サーバーサイドスクリプト、ビジネスルールの作成が含まれます。
* カスタムテーブル:標準テーブルに収まらない特殊なデータに対応するカスタムテーブルを開発します。
* 統合:API や Web サービスなどの外部システムとの統合をカスタマイズして、シームレスなデータ交換を実現します。
* ウィジェットとポータル:独自の機能とユーザーエクスペリエンスを提供するカスタムウィジェットとポータルを作成します。
* ワークフロー: ワークフロースタジオを使用してワークフローを作成および変更します。プレイブック、フロー、アクション、ディシジョンテーブル、統合を 1 つの設計環境から作成および管理して、タスクを自動化します。新しいバージョンのフローにアップグレードするには、カスタマイズを再適用する必要があります。
{#customization-vs-configuration-concepts__ul_chv_dph_1fc}

## カスタマイズと構成のためのツール {#customization-vs-configuration-concepts__tools-customization-and-configuration}

ServiceNow には、 ServiceNow アプリケーションのすぐに利用可能な動作を変更するための、ビジネスルールなどの多くのツールと機能が用意されています。アプリケーションをカスタマイズするか構成するかは、使用方法によって異なります。これらのツールを使用してインストールされているコードベースを変更すると、カスタマイズが構成されます。これらのツールを使用して、フローを変更しないコードを追加するか、インストールされたコードベースが構成を構成します。どちらの場合も、追加するコードと、それが ServiceNow プラットフォームに与える影響はユーザーが所有します。  
ServiceNow ツールには次のものが含まれます。

* UI ポリシー:ユーザー入力に従って、フォーム上のフィールドと属性の可視化を動的に変更します。
* ビジネスルール:指定された条件に基づいてアクションを自動的にトリガーします。
* UI アクション:ボタン、コンテキストメニューアイテム、またはクリックされたときに特定のアクションを実行するその他の UI 要素を追加して、フォームやリストを拡張およびカスタマイズします。
* クライアントサイドスクリプト:フォームまたは UI ページで特定のアクションが発生したときに、ユーザーのブラウザー内で実行されるスクリプト。
* サーバーサイドスクリプト:ServiceNow サーバーまたはデータベースで実行されるスクリプト。たとえば、データベースクエリの実行時にレコードフィールドを更新します。
{#customization-vs-configuration-concepts__ul_bnt_3ph_1fc}

## パーソナライゼーションとは {#customization-vs-configuration-concepts__what-is-personalization}

パーソナライズとは、ユーザーがすぐに利用可能なアプリケーションツールを使用して、アプリケーションのルックアンドフィールを自分だけに変更することです。アドミニストレーターはすべてのユーザーのルックアンドフィールを変更でき、それが構成と見なされます。パーソナライズの例としては、ユーザーがダークモードを使用することを選択したり、表示するテーブル列を選択したりすることが挙げられます。

パーソナライズしても、 ServiceNow インスタンスでのベースラインコードのインストールは変更されません。そのため、パーソナライズがカスタマーサポートに影響を与えたり、新しい ServiceNow バージョンへのアップグレードを妨げたりすることはありません。

## ServiceNow製品のカスタマイズの影響 {#customization-vs-configuration-concepts__ramifications-customize-sn-products}

ServiceNowプラットフォームは非常に柔軟で、幅広いビジネス要件を満たすためのカスタマイズと構成を受け入れるように構築されています。ただし、 ServiceNow アプリケーションのカスタマイズ方法は、 ServiceNow サポート、将来の ServiceNow プラットフォームバージョンへのアップグレード、およびプラットフォームの機能に大きな影響を与える可能性があります。ServiceNowアプリケーションをカスタマイズする代わりに、クリエータースタジオ や ServiceNow スタジオ などのApp Engine開発製品を使用して新しいアプリケーションを作成することを検討してください。

ServiceNow プラットフォームは、アプリケーションのタスク処理方法、複数のブラウザーでのフォームのレンダリング方法、および全体的なユーザーエクスペリエンスにおいてアプリケーションをサポートするフレームワークを使用します。ServiceNow は、フレームワークの完全性を利用して、一貫した方法でサポートを開発し、提供します。カスタマイズすると、このフレームワークが損なわれたり、プラットフォームの機能が変更されたり、ワークフローやアップグレード性が損なわれたりする可能性があります。  
カスタマイズにより、プラットフォームでsys_update_xmlレコードが作成され、顧客アップデートテーブルに保存されます。プラットフォームはすべてのカスタマイズをマークし、 ServiceNow プラットフォームの新しいバージョンに更新するとカスタマイズされたレコードをスキップします。つまり、カスタマイズを手動で更新する必要があります。手動更新は、新しいプラットフォームバージョンへの更新に必要な時間とリソースに大きな影響を与える可能性があります。  
注:  
カスタマーアップデートテーブルには、新しいカタログアイテムや新しいワークフローの作成など、構成メタデータの変更や追加も含まれています。

詳細については、「[Customer Updates table](https://www.servicenow.com/docs/access?context=r_CustomerUpdatesTable&version=australia&pubname=australia-platform-security&ft:locale=en-US)」を参照してください。カスタマイズの数が増えると、カスタマイズの管理が著しく複雑になることに注意してください。

インストールされたコードベースのカスタマイズは、カスタムコードが新しいプラットフォームバージョンに簡単に移行できない可能性があるため、コストがかかり、技術的負債が発生し、アップグレードサイクルが長くなり、将来のプラットフォームアップグレードが複雑になる可能性があります。カスタムコードによって、 ServiceNow プラットフォームの標準機能が意図しない方法で変更される可能性があります。カスタマイズのデマンドを慎重に評価し、明確なビジネス価値があり代替案がない場合にのみカスタマイズに頼ってください。可能な限り、代わりに構成を使用してカスタマイズを避けてください。  
製品をカスタマイズする場合:

* 今後のカスタマイズを維持する責任はユーザーにあります。
* カスタマーサービス \& サポート では、カスタムコードに起因する問題はサポートされません。それが問題の原因である場合、サポート チームはすぐに利用可能なコードに戻すようにアドバイスする可能性があります。
{#customization-vs-configuration-concepts__ul_myt_wwh_1fc}

## カスタマイズのサポートに対する カスタマーサービス \& サポート のスタンスは何ですか? {#customization-vs-configuration-concepts__customer-support-stance-customization}

カスタマイズに対する ServiceNow カスタマーサービス \& サポート スタンスは、コードを追加すれば、そのコードとその結果を所有するということです。どうしてですか？カスタマーサポートはカスタムビジネスロジックを理解しておらず、予想される動作がわからず、すぐに利用可能なインスタンスで問題を再現できず、カスタマーサポートエンジニアは認定された実装スペシャリストではないため、カスタマイズされたコードロジックをレビューする資格もありません。

## カスタマイズの代替手段 {#customization-vs-configuration-concepts__alternatives-to-customization}

拡張のための要件とアイデアがある場合は、インストールされているコードベースをカスタマイズする代わりに、次のことができます。

* カスタマイズではなく構成を使用します。
* ServiceNow開発チームに拡張要求を送信します。各要求は評価され、承認された場合は将来のリリースに組み込まれます。
* 必要な機能を処理する App Engine 開発者向け製品を使用してアプリを作成します。
{#customization-vs-configuration-concepts__ul_aby_xyh_1fc}

## カスタマイズの代わりに App Engine 開発者製品を使用する場合 {#customization-vs-configuration-concepts__when-use-app-engine-dev-products}

会社が ServiceNow プラットフォームに新しい機能を追加する必要がある場合は、ITSM などの既存のアプリケーションをカスタマイズしたり、クリエータースタジオ や ServiceNow スタジオ などのApp Engine開発者製品を使用して新しいアプリケーションを作成したりできます。どのパスを選択するかについての簡単なガイドラインは次のとおりです。

* カスタマイズによってアプリケーションの目的が拡張される場合は、カスタマイズする方が適しています。たとえば、ITSM に IT 機能を追加できます。
* カスタマイズによってアプリケーションの目的が拡張されない場合は、App Engine 開発者向け製品を使用して新しいアプリケーションを作成することをお勧めします。たとえば、 ITSM ワークフローを再利用して出張要求ワークフローを作成しないでください。
{#customization-vs-configuration-concepts__ul_v2l_hzh_1fc}

たとえば、 ITSM は IT の問題を処理するように設計されています。出張要求を処理するようにカスタマイズすることは、 ITSMの当初の意図を超えています。IT と出張要求のワークフローは異なるため、ITSMをカスタマイズするのではなく、クリエータースタジオ や ServiceNow スタジオ などのApp Engine開発者ツールを使用して出張要求アプリを作成することをお勧めします。

## App Engine開発者向け製品の使用例 {#customization-vs-configuration-concepts__examples-when-use-app-engine}

ServiceNow 製品は、その用途に従って使用すると最高の効果を発揮します。アプリケーションを大幅にカスタマイズして再利用する場合は、App Engine 開発者向け製品を使用して新しいアプリケーションを作成することをお勧めします。  
次のシナリオは、既存の ServiceNow アプリケーションを大幅にカスタマイズするよりも、新しいアプリケーションを作成する方が効果的な場合を示しています。

* どの製品ワークフローにも適合しないアプリの新しいユースケースがある。
* すぐに利用可能なアプリケーションを大幅にカスタマイズして構築できるユースケースがあるが、既存のアプリケーションの用途と一致していない。
* 会社には、OOTB 製品ワークフローとは別のユーザーグループまたはビジネスプロセスがあります。
{#customization-vs-configuration-concepts__ul_e42_mzh_1fc}

## ServiceNow製品のカスタマイズに関するガイドライン {#customization-vs-configuration-concepts__guidelines-for-customization}

カスタマイズする必要がある場合は、次の提案を検討してください。

* 最初に構成オプションを最大化します。
* オブジェクトのコピーは避けてください。代わりに、 サービスポータル ウィジェットや再利用するように指定されているその他のアイテムを除き、可能な限りその場のオブジェクトを更新してください。
* デフォルトは「編集前に追加」です。つまり、たとえば、既存のフィールドのタイプを変更するのではなく、フォームにフィールドを追加する必要があります。すぐに利用可能なオブジェクト、メソッド、またはクラスを追加するときは、それらと同じ名前を使用しないでください。
* フォームに追加するフィールドの数を最小限に抑えます。フォームのフィールドが多いほど、ロードに時間がかかることがあります。
* カスタマイズする前に、元のレコードをバックアップとしてエクスポートします。将来復元する必要がある場合に備えて、すぐに利用可能なsys_idを追跡してください。
* スコープ対象のアプリケーションを新しいカスタム開発のデフォルトとして使用します。
* すべてのカスタマイズを文書化します。カスタマイズした理由 (ビジネス上の根拠を含む) を説明するコメントを追加します。アップグレードする前にすべてのコメントを確認して、すぐに利用可能なコードに戻すことができるかどうかを判断します。
* すべてのカスタマイズのテストを作成します。可能な場合は、すべてのカスタマイズに対して自動テストフレームワーク (ATF) テストを作成します。
* ヘルススキャンを定期的に使用して、不要なカスタマイズを特定します。
* 競合の解決と意思決定を更新に適切に記録できるように、必要に応じてベースラインオブジェクトをカスタマイズする必要があります。非表示のカスタマイズにより、元に戻すか結合する必要がある場合に、アドミニストレーターが今後のアセスメントで更新を見落とす可能性があります。
* すべてのユースケースのカスタマイズをテストします。パフォーマンステストと意図しない結果の導入を含めます。
* アドミニストレーターは、 ServiceNow プラットフォームのアップグレード後にカスタマイズが機能することを確認し、どのようなカスタマイズが行われたかを追跡する責任があります。
{#customization-vs-configuration-concepts__ul_bbx_4zh_1fc}

## アップグレード時のカスタマイズの処理 {#customization-vs-configuration-concepts__handling-customizations-when-you-upgrade}

カスタマイズにより、プラットフォームでsys_update_xmlレコードが作成され、顧客アップデートテーブルに保存されます。これらのレコードは、プラットフォームバージョンのアップグレード時に更新されません。ServiceNowServiceNow アップグレードモニターでスキップされたレコードとしてマークします。アップグレードされたインスタンスに正常に移植されたことを確認するには、スキップされた変更を手動で処理する必要があります。詳細については、「[Customer Updates table](https://www.servicenow.com/docs/access?context=r_CustomerUpdatesTable&version=australia&pubname=australia-platform-security&ft:locale=en-US)」を参照してください。  
ビジネス上の根拠を含むすべてのカスタマイズを文書化したと仮定して、文書化されたインベントリを取得し、アップグレードモニターで特定されたスキップされたレコードと比較します。スキップされたレコードの原因となったリスクの低い変更 (フィールドラベルやフォームレイアウトなど) を除外した後、次を行うかどうかを決定する必要があります。

* 各カスタマイズを保持する
* すぐに利用可能な状態に戻す
* カスタマイズをベースシステムと結合して競合を解決します
{#customization-vs-configuration-concepts__ul_byy_b13_1fc}