JunshuO
ServiceNow Employee

ServiceNow アクションファブリックについて知っておくべきこと

 

ServiceNow Action Fabric を使用すると、Now Platform 上の AI エージェントは、MCP および A2A プロトコルを介して外部エージェントやツールと連携できます。MCP クライアントとしての ServiceNow (外部呼び出し)、MCP サーバーとしての ServiceNow (機能を公開)、Google の A2A プロトコルを介して外部エージェントと連携する ServiceNow エージェントの 3 つのパターンをサポートしています。

 

このシリーズでは、プラットフォームで AI エージェントを最大限に活用できるように、アクションファブリックの各コンセプトを毎週検証します。

 

目次

 

 

第1話:アクションファブリックのイントロ

 

 

問題: 自動化の島

 

今日の企業は複数のアプリケーションを実行しており、それぞれが独自の AI エージェントを出荷しています。これらのエージェントは、プラットフォームの境界を越えて調整できない孤立した自動化サイロを作成します。その結果、複数のベンダーにまたがるモジュール式のワークフローを構築することはできません。

 

解決策: クロスプラットフォームの相互運用性

 

ServiceNow Action Fabric は、ServiceNow を中心に、テクノロジースタック全体のエージェントが相互運用するオーケストレーションを提供します。

 

コンセプトの背後にある技術スタック

 

Action Fabric はプラットフォームに依存せず、次の 3 つのプロトコルを通じて相互運用性を提供します。

 

1. MCP クライアントとしての ServiceNow (送信)

 

ServiceNow AI エージェントは、外部 MCP サーバーへの発信コールを開始し、公開されたツールを検出してコンテキストまたは機能を取得します。これにより、特殊な外部ツールに接続することでエージェントのリーチが拡張されます。

 

2. MCP サーバーとしての ServiceNow (受信)

 

ServiceNow は、ChatGPT や Cursor などの外部クライアントが利用できる MCP ツールとしてその機能を公開しています。Now Assist スキル、カスタムスキル、スクリプト化された API、ナレッジグラフはすべてツールとして利用できるようになります。

 

3. A2A(エージェント2エージェント)

 

Google のオープン Agent2Agent プロトコルを使用すると、2 つの AI エージェントが共有タスクでピアとして調整し、サブタスクを委任し、ターン間でコンテキストを渡すことができます。ServiceNow エージェントは、外部に委任するプライマリエージェントとして、または外部委任を受けるセカンダリエージェントとして機能することができます。

 

↑ 目次に戻る

 

エピソード 2:ServiceNow の MCP

 

 

USB-Cの瞬間としてのMCP

 

Model Context Protocol が登場する前は、すべてのエージェントが各ツールまたはシステムと通信するためにカスタム統合コードを必要としていました。

 

MCP は USB-C の瞬間です。1 つの標準プロトコルであり、どのエージェントも任意の MCP サーバーに接続できます。カスタム統合作業は必要ありません。

 

MCP サーバーとしての ServiceNow

 

既存の ServiceNow 機能は、外部 AI が呼び出すことができるツールになります。MCP サーバーの背後にパッケージ化された Now Assist スキル、スクリプト化された REST API、テーブル API クエリは、MCP を話す外部の LLM またはエージェントからアクセスできるようになります。ディスカバリーは簡単です。エージェントが利用可能なツールを検出したらツール呼び出しを行い、ServiceNow が結果を返します。

 

MCP クライアントとしての ServiceNow

 

ServiceNow は MCP クライアントとして外部に到達し、Microsoft Learn MCP サーバーやその他の MCP 準拠のソースなどの外部サーバーからツールを使用します。

 

MCP は、エンタープライズ自動化フローのインフラストラクチャを提供します。

 

↑ 目次に戻る

 

エピソード 3:MCP クライアントとしての ServiceNow

 

 

ユースケース:解決支援エージェント

 

インシデントを処理するサポートユーザーは、多くの場合、プラットフォームの外部にある情報 (Microsoft アプリケーションドキュメント、ベンダーガイダンス、または外部ナレッジベース) を必要とします。クライアントとしての MCP は、ServiceNow AI エージェントがインシデントワークフロー内に留まりながら外部ツールを検出して使用できるようにすることで、このギャップを埋めます。

 

ワークフローステップ:

 

  1. サポートユーザーがインシデントを処理します。
  2. エージェントが内部スクリプトツールを使用してインシデントコンテキスト (簡単な説明、完全な説明) をプルします。
  3. エージェントは外部 MCP サーバー (このデモでは Microsoft Learn) にアクセスし、そのコンテキストを使用してドキュメント検索を実行します。
  4. ユーザーレビューまたはナレッジ記事作成のための作業メモとしてインシデントにガイダンスが投稿されます。

 

これは、独自の外部MCPサーバーとワークフローに適応するのに十分なメカニズムを明確に示します。

 

技術的実装

 

1. 外部MCPサーバを登録する

 

AI エージェントスタジオで、**[設定] > [MCP サーバーの管理]** に移動します。
このランディングページでは、外部 MCP サーバーが登録され、ServiceNow が公開ツールを検出できるようになります。

 

  • 認証タイプを選択します: OAuth 2.0 または API キー。
  • API キーの場合は、サーバーの URL とキーを入力します。
  • 保存されたサーバーが利用可能なオプションとして表示されます。

 

2. AI エージェントを作成する

 

AI エージェントがその機能を理解できるように、明確で意味のあるロールの説明を使用して新しい AI エージェントを追加します。初期試行ではデフォルト設定が有効です。

 

3. インシデントコンテキストの内部スクリプトツールの追加

 

インシデント番号を使用してインシデントの詳細 ([簡単な説明] フィールドと [説明] フィールド) をフェッチする簡単なスクリプトツールを構成します。エージェントが実行前に確認できるように、監視対象として設定します。

 

4. MCP サーバーツールを追加する

 

ツールタイプ「MCP ツール」を追加し、登録された MCP サーバーを選択します。ServiceNow は、サーバーに対して `tools/list` ディスカバリー呼び出しを行います。公開されているすべてのツールがオプションとして表示されます。

 

5. 結果を投稿するためのスクリプトツールを追加

 

MCP ツールから返されたインシデント番号と解決内容を取得し、結果をインシデント作業メモとして書き込む 2 つ目のスクリプトツールを構成します。

 

6. テストする

 

推論パネルを有効にした場合:

 

  • エージェントがインシデントコンテキストをプルし、実際の問題を特定します。
  • 監視中ツールは、続行する前に確認のために一時停止します。
  • エージェントが検索クエリを提案し、確認を要求します。
  • 確認すると、エージェントは MCP ツールを呼び出して外部サーバーに到達し、インシデントまたは内部ナレッジベースでは利用できないドキュメントベースのガイダンスを返します。
  • エージェントが作業メモにガイダンスを自動的に投稿します。

 

結果: サポートユーザーは、ServiceNow を離れることなく、外部から調達した関連する解決ガイダンスをインシデントで直接受け取ることができます。

 

外部コンテキスト、データ、または機能を必要とするエージェントは、管理された認証の下で登録された MCP サーバーを介して到達し、結果をトリガーされたレコードまたはワークフローに取り込むことができます。

 

↑ 目次に戻る

 

エピソード 4:MCP サーバーとしての ServiceNow

 

 

ServiceNow では、スキル、REST API、フロー、サブフロー、アクション、およびナレッジグラフを、Claude や ChatGPT などの外部 MCP クライアント用のツールとして公開できます。

 

ユースケース:外部 AI のツールプロバイダーとしての ServiceNow

 

このシナリオでは、メカニズムが可視化されたままになります。

 

  1. ServiceNow 内に新しい MCP サーバーを登録し、ツールを接続します (インシデントのルックアップと変更から開始)。
  2. 外部 AI アクセスを有効にする安全な受信統合パス (OAuth、JWT トークン、ユーザースコープアクセス) を設定します。
  3. カスタムコネクタを使用して、外部 AI クライアント (このデモでは Claude) を ServiceNow MCP サーバーに接続します。
  4. カスタムスクリプト化された REST API をツールとして公開してサーバーを拡張します。
  5. テスト:自然言語からのインシデントの作成、作業メモの追加、カスタム REST API を介したデータのプル、すべて ServiceNow の外部から。

 

技術的実装

 

1. MCP サーバーコンソールを開きます

 

AI アドミンロールが必要です。インスタンスには Zurich パッチ 9 以降、またはオーストラリアパッチ 2 以降が必要です。すぐに利用可能な「クイック検索」MCP サーバーには、カスタムサーバーをビルドする前に MCP サーバーの動作を理解するためのサンドボックスが用意されています。

 

2. 新しい MCP サーバーを作成する

 

わかりやすい名前と簡単な説明を入力します。保存すると、サーバーの URL が自動的に入力されます。これは、外部クライアントが接続するエンドポイントです。ガバナンスでは、1 つの大きな MCP サーバーよりも複数の MCP サーバーを優先します。これにより、アクセス境界がクリーンに保たれます。

 

3. サーバーにツールを追加する

 

シンプルに始めましょう。このデモでは、インシデントレコードのルックアップツールとインシデント変更ツールの 2 つのツールが追加されています。

 

4. インバウンド統合の設定 (マシン ID コンソール)

 

これにより、外部エージェントが新しい MCP サーバーに対して認証できるようになります。

 

  • マシン ID コンソールを開き、アプリケーションレジストリエントリを設定します。
  • 認証コード権限許可タイプを選択。
  • リダイレクト URL を入力。
  • 生成されたクライアント ID とクライアントシークレットをコピーします。
  • デモの範囲は広いです。本番環境では API スコープをロックダウンする必要があります。
  • トークン形式を JWT に切り替えます (MCP サーバー接続で現在想定されています)。

 

5. 外部クライアント(Claude)からの接続構築

 

  • Claude のコネクタ設定で、カスタムコネクタを追加します。
  • 名前を付け (「ServiceNow MCP」など)、MCP サーバー URL、クライアント ID、およびクライアントシークレットを貼り付けます。
  • コネクタは登録されていますが、まだ接続されていません。認証はまだ必要です。
  • 接続時に、ServiceNow 認証情報の入力を求められます。これにより、接続はユーザースコープに維持されるため、外部 AI には特定のユーザーアカウントが表示する資格があるもののみが表示されます (受信要求からの昇格された権限は表示されません)。

 

6. Now Assist スキルを MCP サーバーに添付する

 

インシデントを作成するための自然言語クエリを受け入れるカスタム分析スキルを作成します。新しいツールを作成し、「分析スキル」タイプとしてマークし、MCP サーバーを接続します。1 つのツールで複数の MCP サーバーに接続して、コンテキストを再利用できます。

 

7. スクリプト化された REST API をツールとして公開する

 

Now Assist スキル以外にも、既存のスクリプト化された REST API、フロー、サブフロー、アクション、およびナレッジグラフを MCP ツールとして公開できます。このデモでは、インシデントに関連付けられたシンプルなスクリプト化された REST API がツールとして登録され、同じ MCP サーバーにタグ付けされ、説明が付けられて保存されます。

 

8. コネクタのツールリストを更新

 

Claude側に戻り、MCPサーバーのツールリストを更新します。新しく追加されたツールは自動的に表示されます。再接続は必要ありません。リフレッシュするだけです。

 

9. エンドツーエンドのテスト

 

  • 自然言語からインシデントを作成します。 「私のMacBookが極端に遅い」と「本当に優先度が高い」という指示に対し、Claude は MCP サーバーを呼び出して利用可能なツールを検出し、要求をインシデント作成ツールと照合してインシデントを作成します。
  • 作業メモを追加: 「このインシデントにコメントを追加できますか?」Claude はインシデント変更ツールを特定し、コメントを追加します。
  • カスタム REST API ツールを使用してデータをプル: Claudeはスクリプト化されたREST APIツールを呼び出し、期待される結果を返し、カスタム公開ツールが組み込みツールと同様に機能することを確認します。

 

結果: ログインしているユーザーの権限で動作する外部 AI クライアントは、ServiceNow UI を開かずに ServiceNow レコードを作成および更新し、カスタム API を呼び出します。

 

Action Fabric の MCP サーバーの方向性により、既存のプラットフォームへの投資 (スキル、API、ナレッジグラフ) が、組織やユーザーが好むあらゆる AI ツールの再利用可能なインフラストラクチャになります。

 

↑ 目次に戻る

 

エピソード 5:ServiceNow の A2A (Agent2Agent)

 

 

このシリーズのこの時点で、Action Fabric と MCP は古いニュースです。ServiceNow は MCP クライアントとして外部ツールに手を差し伸べたり、MCP サーバーとして機能して独自の機能を外部に公開したりできます。次の質問、つまり Sayan が今回取り組む質問は、ツール呼び出しだけでは不十分で、実際に 1 つの AI エージェントが別のエージェントと対話する必要がある場合に何が起こるかということです。

 

A2A とは何ですか?

 

A2A は、AI エージェント間の直接的なピアツーピアコラボレーションのための Google のオープンスタンダードです。MCPとは形が違います。MCP は、関数を呼び出すようなツール (要求、応答、実行) と対話するエージェントです。A2A はエージェントが別のエージェントと対話して構造化されたコンテキストを引き継ぎ、もう一方のエージェントが独自の作業を行い、レポートを返します。その交換は 1 往復で終わる必要はありません。ジョブが実際に終了するまで、実際のマルチターン会話として実行できます。

 

MCP のジョブ

 

Claude が ServiceNow にクエリを送信し、ナレッジ記事のリストを要求しているところを想像してください。スキルをビルドし、ツールとしてラップし、サーバーに接続します。1 回のコールインで 1 回のクリーンな結果が得られます。これは教科書的なMCPジョブです:単一の回答を返す単一の関数です。

 

A2A のジョブ

 

さて、まったく別の場所 (Google ADK、LangGraph など、あらゆるフレームワークで構築) に住んでいるエージェントに旅行の計画を依頼するところを想像してみてください。そのエージェントは、最初の試行でフライトの旅程を渡すつもりはありません。どこから出発するのか、どこへ向かうのか、いつ、飛行機や電車に乗るのか、という疑問が戻ってきます。あなたが答えると、それは選択肢を見て行き、あなたが何かにたどり着くまで行ったり来たりし続けます。このマルチターンで、解決するまで話し続けるパターンこそが、A2Aの地位を築くところです。

 

ServiceNow が両面での役割を果たす仕組み

 

ServiceNow は、既に MCP クライアントおよび MCP サーバーになる方法を知っています。A2A は同じ基盤の上に 2 番目のパターンを追加し、ServiceNow はそのどちらかの側に配置できます。

 

プライマリエージェントとしての ServiceNow。 ここでは、ServiceNow の AI エージェントがワークフローを実行するオーケストレーターであり、外部エージェント (Google エージェント、AWS エージェント、任意のフレームワーク上に構築されたエージェント) に連絡します。エージェントを検出し、エージェントが実行できるすべてを引き出し、それを実行してタスクを委任するという単純な手順です。その場合、ServiceNowがプライマリエージェントになり、それが呼び出したものがセカンダリエージェントになります。

 

セカンダリエージェントとしての ServiceNow。 裏返せば、ServiceNow も同様に簡単に呼び出される可能性があります。エージェントスタジオに AI エージェントを登録して検出可能にすると、外部のサードパーティエージェントが AI エージェントを見つけて実行し、作業を委任できます。これは同じ相互運用性であり、逆方向に実行されるだけです。

 

これが A2A の核心です: MCP は依然としてクリーンな単一の関数呼び出しを所有しています。A2Aとは、実際の仕事を別のエージェントに任せて最後までやり遂げることを意味し、その瞬間に手が届くものです。

 

↑ 目次に戻る

 

エピソード 6:プライマリエージェントとしての ServiceNow

 

このシリーズの最後のエピソードでは、「A2A」では、ServiceNow AI エージェントを、作業を委任する側または委任された作業を受け取る側のいずれかとして、エージェント間のやり取りのどちらかの側に座ることができます。このエピソードでは、その前半をライブビルドで実践し、ServiceNow がプラットフォームの外にいるエージェントに手を差し伸べ、実際のタスクを任せます。

 

ユースケース:外部フライトエージェントの検出と呼び出し

 

このデモの外部エージェントは、Google のエージェント開発キットで構築されたシンプルな AI エージェントで、Vertex AI を推論モデルとして使用し、URL で公開します。その URL にヒットすると、エージェントカードが返されます。これは、エージェントが何をするのか、どのように到達するのかを構造化した説明です。その上に API キーがあるため、ServiceNow にはアクセスできます。

 

目標は、ServiceNow がそのエージェントを検出し、機能をプルして呼び出すことです。この際、ServiceNow がプライマリエージェントとして機能し、Google が構築したエージェントがセカンダリエージェントとして機能します。

 

技術的実装

 

1. 検出可能性をオンにする

 

AI エージェントスタジオ内の [設定] の下に、「外部 AI エージェント」というセクションがあります。ここで検出可能性をオンにして、ServiceNow がプラットフォーム外に登録されているエージェントに連絡できるようにします。逆方向に実行される 2 番目のトグルがあり、外部エージェントが ServiceNow に登録されているエージェントを検出できるようにします。

 

このトグルをオンにしても、ServiceNow のすべてのエージェントが外部に公開されるわけではありません。これは逆の働き方で、その特定のエージェントに入り、個別に露出をオンにしない限り、何も露出されません。

 

2. 外部エージェントを登録する

 

エージェントカードの URL を手にして、[作成と管理] に移動し、外部エージェントを追加するオプションを選択します。新しいプロバイダーを追加し、既知の URI (エージェントカードアドレス) を貼り付けます。

 

3. 認証情報の設定

 

詳細設定では、認証が 2 つの別々のタイミングに分割されます。ディスカバリー時に使用される認証情報のセットと、実行時に使用される別の認証情報のセットです。この特定のエージェントは公開検出可能に設定されているため、検索するために認証情報は必要ありません。検出を押すと、エージェントが表示されます。

 

4. 何が戻ってきたかを見てください

 

検出されたエージェントを開くと、最初に基本情報が表示されます。エージェントの種類や簡単な説明などです。エージェントカード自体にドロップすると、エージェントが公開するスキル、実際の接続 URL、エージェントが実行されるトランスポートプロトコル (この場合は JSON-RPC) などの詳細など、さらに多くの情報が表示されます。エージェント名刺は、他のエージェントが読み取ってエージェントの業務内容とその構成方法を理解できるデジタル名刺と考えてください。

 

5. アクティブ化する

 

エージェントをアクティブ化すると、スキルディスカバリーが開始されます。この場合、意味のあるスキルの 1 つ、検索機能が戻ってきます。ディスカバリーが完了すると、ほとんどの構成はエージェントカードから提供されたものから自動的に入力されますが、名前を変更したり、必要に応じて調整したりできます。

 

6. 実行のための認証を追加する

 

通信プロトコルは独自に機能します。そこから、実際にエージェントを呼び出すために必要な認証を追加します。基本認証または API キーはどちらも機能します。このデモでは、認証情報として既に保存されている API キーを使用します。

 

エージェントの呼び出しに使用された接続 URL が、エージェントの検出に使用されたエージェントカードの URL と同じではありません。接続 URL はエージェントカード自体の内部から取得されるため、ディスカバリーが実行されると自動的に入力されますが、別のアドレスが別のジョブを実行しています。

 

7. テストする

 

保存すると、エージェントはアクティブで検出可能として表示されます。トリガーされると、オーケストレーターはこれを外部エージェントコールとして即座に認識します。実行には外部としてフラグが付けられ、ServiceNow の外部に存在するエージェントに連絡し、結果が返されます。

 

結果: ServiceNow はエージェントカードを検出して、エージェントをアクティブ化し、そのエージェントに対する呼び出しを実行します。オーケストレーターは、交換全体を単純なツール呼び出しではなく、エージェント間のハンドオフとして扱います。これが実際にはプライマリエージェントの役割です。ServiceNow はエージェントを検索し、エージェントが実行できることを引き出し、タスクをエージェントに委任します。

 

↑ 目次に戻る

 

エピソード 7:セカンダリエージェントとしての ServiceNow

 

 

前回のエピソードでは、ServiceNow がプライマリエージェントとして主導権を握り、外部エージェントに連絡してタスクを引き継ぎました。このエピソードは方向性を完全に逆転させます。ここでは、ServiceNow が呼び出されています。エージェントスタジオに登録された AI エージェントは外部エージェントが検出可能になり、別の ServiceNow インスタンスがプライマリエージェントとして機能します。

 

ユースケース:クロスインスタンスインシデントルックアップ

 

セットアップでは、2 つの ServiceNow インスタンスを使用します。セカンダリインスタンスには、従業員番号を取得し、対応するユーザーを検索し、オープンインシデントを要約するシンプルな AI エージェントがあります。プライマリインスタンスでは、別のエージェントがセカンダリエージェントを検出し、セカンダリインスタンスの UI に触れることなく同じ情報を取得するために呼び出します。

 

これにより、デモはセカンダリエージェントの仕組みと、反対側からの接続の確立に焦点を当てることができます。

 

技術的実装

 

1. エージェントを構築する

 

セカンダリインスタンスの AI エージェントスタジオで、AI エージェントを作成します。これは従業員番号を受け取り、ユーザーテーブルにクエリを実行して一致するレコードを検索し、そのユーザーのすべてのオープンインシデントをプルして要約します。

 

2. 検出可能性を有効にし、エージェントカードの URL を取得する

 

**[設定] > [外部 AI エージェント]** に移動し、同期通信モードが選択された状態で検出可能性がオンになっていることを確認します。また、 sn.ai.external.agents プロパティが true に設定されていることを確認します。これにより、外部エージェントがそのインスタンスに登録されているエージェントとやり取りできるようになります。

 

次に、エージェント自体を開き、この特定のエージェントを外部で検出可能にするプロパティを切り替えます。設定すると、エージェントカードの URL が自動的に生成されます。この URL は、接続を確立するためにプライマリインスタンスで必要になります。

 

3. エージェントをローカルでテストする

 

接続する前に、エージェントをセカンダリインスタンスで直接実行して、エージェントが単独で機能することを確認します。従業員番号を渡して検証し、エージェントがユーザーを見つけて、(監視ツールの確認により) そのユーザーのオープンインシデントをすべて取得します。これにより、エージェントを検出する準備ができていることを確認します。

 

4. セカンダリインスタンスで認証を設定する

 

外部エージェントが呼び出す前に、次の 3 つの要素を準備する必要があります。

 

REST API キー: REST API キーを作成して名前を入力し、適切なユーザーに関連付けます。A2A スコープが含まれていることを確認します。

 

受信認証プロファイル: 認証プロファイルを作成し、認証パラメーターを API キーのヘッダーに設定します。これにより、着信要求の認証情報がプラットフォームに通知されます。

 

API アクセスポリシー: REST API アクセスポリシーモジュールで、新しく作成された認証プロファイルを A2A のすぐに利用可能なレコードに追加する必要があります。これにより、受信 A2A 要求が適切に認証されるように、すべてがリンクされます。

 

5. プライマリインスタンスから登録する

 

プライマリインスタンスに切り替えて、このインスタンスに外部エージェントへのアクセスを許可するプロパティを有効にします。AI エージェントリストに移動し、新しい外部エージェントを作成して、セカンダリインスタンスからエージェントカードの URL を貼り付け、名前を入力します。

 

検出時に、エージェントの詳細 (説明、機能、スキル、接続 URL、および転送プロトコル (以前と同じ) を表示する完全なエージェントカード) がフェッチされます。エージェントがアクティブ化され、スキルディスカバリーが実行され、セカンダリエージェントに登録されているツール (ユーザールックアップ、インシデントルックアップ) が自動的に表示されます。

 

6. 接続を構成する

 

ここで詳細が重要です。

 

再試行ポリシー: デフォルトの HTTP 再試行ポリシーに設定します。

 

構成テンプレート: 「セカンダリボット静的トークン構成」を選択します。これは非常に重要です。これがないと、フローは実行用のセカンダリインスタンスに対して認証されません。

 

接続 URL の確認: 接続レコードを開き、URL を確認します。次の値で終わる場合 /.well-known/agent.json これは、実行 URL ではなくディスカバリー URL です。実行 URL の終了が異なります。間違った URL を取得すると、実行が失敗します。

 

認証情報: セカンダリボット静的トークン認証情報を作成し、セカンダリインスタンスから API キーを貼り付けます。次に、接続レコードの認証情報をこの新しい認証情報で上書きします。ヘッダー名が正しいことを確認してください。セカンダリインスタンスの受信認証プロファイルには、このデータが必要です。ここで OAuth 2.0 を使用して認証することもできます。これは、通常のマシン ID コンソールとアプリケーションレジストリのフローに従います。

 

7. エンドツーエンドのテスト

 

テストを完了するには、プライマリインスタンスに戻り、エージェント構成を保存し、アクティブであることを確認してからテストをトリガーする必要があります。オーケストレーターはこれを外部エージェントコールとして認識し、セカンダリインスタンスに到達します。

 

反対側のエージェントが仕事をし、従業員番号に基づいてユーザーを検索し、一致を確認してオープンインシデントを取得します。やり取り全体は、A2Aの特徴であるマルチターンの会話として行われます。プライマリエージェントが尋ねると、セカンダリエージェントが応答して確認が行われ、最終結果がインシデント番号とステータスとともに返されます。

 

これは、Now Assist、仮想エージェントとして、または他のチャネルを介して実行できます。

 

ServiceNow はセカンダリエージェントとして機能し、別のインスタンスから受信 A2A 要求を受信して認証し、独自のエージェントロジックを実行して、マルチターン交換を通じて結果を返します。

 

↑ 目次に戻る

 

シリーズのまとめ

 

このシリーズでは 7 つのエピソードにわたって、Action Fabric がサポートするすべての機能について説明しました。ServiceNow は MCP クライアントとして外部に手を差し伸べて外部ツールを利用し、ServiceNow は外部 AI が呼び出す MCP サーバーとして独自の機能を公開し、ServiceNow はプライマリエージェントとセカンダリエージェントの両方として A2A を通じてエージェント間のコラボレーションに参加しています。

 

MCP サーバーモードでは、既に構築したスキル、API、ナレッジグラフを取得し、組織が実行するすべての AI ツールで利用できるようにします。MCP クライアントモードでは、エージェントがワークフローを離れることなく外部コンテキストを取り込むことができます。A2A を使用すると、エージェントは、まったく異なるプラットフォーム上にいるエージェントに実際の作業を引き継いだり、エージェントから作業を受け取ったりすることができます。

 

アクションファブリックは、組織が構築しているすべての AI エージェントエコシステムに ServiceNow プラットフォームを参加させるための一連のプロトコルと構成です。仕組みは慎重に設計されており、認証はユーザースコープであり、検出可能性はエージェントごとにオプトインされ、ガバナンスはすべてのステップであなたと一緒にいます。

 

↑ 目次に戻る

 

よく寄せられる質問

 

ServiceNow アクションファブリックは何に使用されますか?

 

ServiceNow Action Fabric を使用すると、AI エージェントがベンダーの境界を越えて相互運用可能となり、ServiceNow 上に構築されたエージェントが Microsoft、SAP、Salesforce、その他のプラットフォームのエージェントやツールと連携できるようになります。ネットワークセンターで ServiceNow とのクロスプラットフォームエージェントオーケストレーションを提供します。実用的な成果:単一のワークフローが複数のベンダーのエージェントにまたがるもので、カスタムのポイントツーポイント統合が不要になります。

 

Action Fabric と MCP の違いは何ですか?

 

MCP (モデルコンテキストプロトコル) は、AI システム間でツールを公開および使用するためのオープンスタンダードです。Action Fabric は、Google の A2A プロトコルとともに MCP を Now Platform 上の管理機能として実装する ServiceNow フレームワークです。MCP はプロトコルです。アクションファブリックは、ServiceNow がプラットフォーム認証、スコーピング、エージェントオーケストレーションでこのプロトコルを使用できるようにする方法です。

 

ServiceNow の MCP と A2A の違いは何ですか?

 

MCP はツールレベルで動作し、AI エージェントが Now Assist スキル、スクリプト化された REST API、ナレッジグラフ検索などの個々の機能を検出して呼び出すことができます。A2A (Agent2Agent、Google のオープンプロトコル) はエージェントレベルで動作するため、ServiceNow AI エージェントは完全な外部エージェントに委任したり、コラボレーションしたりできます。Action Fabric では、MCP は双方向のツールアクセスをカバーし、A2A はピアツーピアエージェントのインタラクションをカバーします。

 

ServiceNow エージェントは ChatGPT または Cursor と会話できますか?

 

はい (双方向)。ServiceNow が MCP サーバーとして機能する場合、ChatGPT や Cursor などの外部クライアントは、OAuth とユーザースコープの適用に従って、Now Assist スキル、スクリプト化された REST API、ナレッジグラフを検出して呼び出します (呼び出し元には、その ID が付与されているもののみが表示されます)。ServiceNow が MCP クライアントとして機能すると、AI エージェントスタジオに登録されているエージェントは外部に到達し、登録された外部 MCP サーバー上のツールを呼び出します。

 

アクションファブリックは Now Assist の一部ですか?

 

いいえ。アクションファブリックと Now Assist は別個ですが、補完的です。Now Assist は、プラットフォーム上で実行される生成 AI スキルを提供します。Action Fabric は、これらのスキルを外部 AI システムに公開し、ServiceNow エージェントが外部ツールを使用できるようにする相互運用性レイヤーです。実際には、Now Assist スキルは Action Fabric MCP サーバーを介して公開されるツールになります。

 

ServiceNow が MCP クライアントとして機能するとはどういう意味ですか?

 

ServiceNow AI エージェントは、外部 MCP サーバーへの送信接続を開始し、公開されたツールを検出して、それらを呼び出して ServiceNow 内に存在しない情報または機能を取得します。エージェントは引き続きワークフローを制御できます。外部サーバーは、ツール呼び出しと結果を提供します。

 

外部 MCP サーバーの登録時に ServiceNow がサポートする認証はどれですか?

 

[MCP サーバーの管理] ページでは、OAuth 2.0 と API キー認証がサポートされています。API キー認証の場合は、サーバーの登録時にサーバーの URL とキーを直接入力します。

 

MCP クライアントとしての ServiceNow と MCP サーバーの違いは何ですか?

 

ServiceNow は MCP クライアントとして、外部ツールまたはデータをプルする発信コールを開始します。MCP サーバーである ServiceNow は受信側にあり、外部の AI クライアントが接続して Now Assist スキル、スクリプト化された REST API、ナレッジグラフなどの公開ツールを呼び出します。

 

Now Assist スキル以外に MCP ツールとして公開できるものは何ですか?

 

スクリプト化された REST API、フロー、サブフロー、アクション、およびナレッジグラフはすべて、インシデントレコードなどのテーブルルックアップとともに MCP ツールとして登録できます。

 

外部 AI はどのツールを呼び出すべきかを知る必要がありますか?

 

いいえ。それがMCPディスカバリーのポイントです。クライアントは MCP サーバーを呼び出し、使用可能なツールリストを取得して、自然言語要求を適切なツールと自動的に照合します。たとえば、「コメントを追加」はインシデント作成ツールではなく、インシデント変更ツールを呼び出す必要があると認識します。

 

複数の MCP サーバー間で同じツールを再利用できますか?

 

はい。複数のユースケースに関連する場合、単一のツールで複数の MCP サーバーに接続できます。

 

ServiceNow の A2A とは?

 

A2A (Agent2Agent) は、AI エージェント間の直接的なピアツーピアコラボレーションのための Google のオープンプロトコルです。Action Fabric 内では、単一のツール呼び出しの代わりに構造化されたコンテキストを使用して、ServiceNow AI エージェントが外部エージェントにタスクを引き渡したり、外部エージェントからタスクを受信したりできます。

 

A2A は MCP とどう違うのですか?

 

MCP は、関数を呼び出すのと同様に、1 つの要求、1 つの応答というツールを呼び出すエージェントです。A2Aはエージェントが別のエージェントを呼び出すことで、構造化されたコンテキストを渡し、もう一方のエージェントが独自のプロセスを実行し、タスクが完了する前に複数のターンを行ったり来たりすることができます。

 

A2A の代わりに MCP に手を伸ばす必要があるのはどのような場合ですか?

 

1 回の関数呼び出しで必要なものが得られた場合、MCP が仕事をしてくれます: ServiceNow がナレッジ記事のリストを Claude に返すような、クエリーの入力とクリーンな結果の出力です。

 

MCP の代わりに A2A に手を伸ばす必要があるのはどのような場合ですか?

 

タスクを 1 回の電話で完了するのではなく、別のエージェントと実際にやり取りする必要がある場合 (たとえば、出張計画などの複数ステップのジョブを外部エージェントに委任し、外部エージェントが作業を完了する前にフォローアップの質問をするなど)。

 

ServiceNow が A2A における「プライマリエージェント」であるとはどういう意味か?

 

AI エージェントがオーケストレーターとして機能する場合、ServiceNow はプライマリエージェントです。外部エージェントを検出し、そのエージェントの機能を取得してから、タスクを実行して委任します。

 

ServiceNow が A2A における「セカンダリエージェント」であるとはどういう意味か?

 

外部エージェントが介入する場合、ServiceNow はセカンダリエージェントになります。AI エージェントがエージェントスタジオに登録され、検出が有効になると、外部エージェントがそのエージェントを見つけて実行し、作業を委任できるようになります。

 

ServiceNow をプライマリエージェントとセカンダリエージェントの両方にすることはできますか?

 

はい。2 つのパターンは排他的ではありません。同じ ServiceNow インスタンスがプライマリエージェントとして外部エージェントを呼び出し、セカンダリエージェントとして外部エージェントによって検出可能になるという 2 つのパターンがあります。

 

A2A はエージェント間のマルチターン会話をサポートしていますか?

 

はい、それがポイントです。A2A 交換は、1 回のコール後に停止するのではなく、2 人のエージェントが一緒にタスクを処理している間に、複数のターンにまたがって実行できます。

 

ServiceNow はどのような種類の外部エージェントと A2A を介して通信できますか?

 

フレームワークに関係なく、A2A プロトコルを話すように構築されたエージェント (Google ADK、LangGraph、AWS ベースのエージェント、または標準をサポートするその他のもの) と通信できます。

 

ServiceNow の A2A セットアップにおけるエージェントカードとは何ですか?

 

エージェントカードは、外部エージェントが既知の URI で公開する構造化された説明です。エージェントの作業内容、公開するスキル、接続 URL、および使用する転送プロトコルが示されます。ServiceNow は、外部エージェントを呼び出す前に外部エージェントを理解するために、このカードを読み取ります。

 

ServiceNow に外部エージェントの検出をさせるにはどうすればよいですか?

 

AI エージェントスタジオで、[設定] > [外部 AI エージェント] で検出可能性をオンにし、[作成と管理] に移動して新しいプロバイダーを追加し、エージェントの既知の URI を貼り付けます。検出を保存して実行すると、エージェントの詳細がプルされます。

 

検出可能性をオンにすると、すべての ServiceNow エージェントが外部に公開されますか?

 

いいえ。検出可能性設定をオンにしても、トグルがまったく機能しなくなるだけです。個々のエージェントにアクセスして、その特定のエージェントのエクスポージャーをオンにしない限り、何も露出されません。

 

エージェントカードの URL と接続 URL の違いは何ですか?

 

エージェントカードの URL は、エージェントを検出してその詳細を読み取るために使用する既知のアドレスです。接続 URL は、そのエージェントに対する呼び出しの実行に使用される実際のエンドポイントであり、ディスカバリーの完了後にエージェントカード内から自動的に入力される別のアドレスです。

 

外部エージェントの登録時に 2 セットの認証情報があるのはなぜですか?

 

ServiceNow がエージェントカードを検索して読み取ろうとしているディスカバリー時に、1 セットの認証情報が適用されます。ServiceNow が実際にエージェントを呼び出してタスクを実行する実行時に、別のセットが適用されます。エージェントは、最初のステップに必要な認証情報なしで公開検出できますが、実行には API キーなどの認証が必要です。

 

外部エージェントの呼び出しにはどのような認証オプションを使用できますか?

 

登録された外部エージェントの実行認証情報を設定する場合は、ベーシック認証と API キー認証の両方がサポートされます。

 

検出された外部エージェントをアクティブ化するとどうなりますか?

 

アクティブ化すると、そのエージェントに対するスキルディスカバリーがトリガーされます。エージェントが公開するスキルはすべて取り込まれて表示されます。残りの構成のほとんどは、その時点でエージェントカードから自動入力されます。

 

これはどのような外部エージェントと連携できますか?

 

既知の URI で適切なエージェントカードを公開するエージェント。

 

2 つの ServiceNow インスタンスは A2A を介して相互に通信できますか?

 

はい。1 つのインスタンスがプライマリエージェントとして機能し、もう 1 つのインスタンスがセカンダリエージェントとして機能します。プライマリインスタンスはエージェントカードの URL を介してセカンダリインスタンスのエージェントを検出し、この 2 つは他のエージェント間やり取りと同様に A2A を介して通信します。

 

受信 A2A 要求のセカンダリインスタンスにはどのような認証が必要ですか?

 

A2A スコープを含む REST API キー、API キーのヘッダーに設定された受信認証プロファイル、およびその認証プロファイルを含めるように更新されたすぐに利用可能な A2A API アクセスポリシーの 3 つです。外部エージェントが呼び出す前に、3 つすべてが整っている必要があります。

 

「セカンダリボット静的トークン構成」とは何ですか?なぜそれが重要なのですか?

 

これは、プライマリインスタンスのセカンダリエージェントへのリンクを設定するときに、接続レコードで選択する構成テンプレートです。これがないと、認証フローは実行時に機能せず、ディスカバリーは成功しても実際のエージェントコールは失敗します。セカンダリインスタンスからの API キーを保持するセカンダリボット静的トークン認証情報とペアリングします。

 

Now Assist または仮想エージェントを介してセカンダリエージェントを表面化できますか?

 

はい。エージェントがアクティブになって作業したら、Now Assist、仮想エージェント、またはエージェントスタジオでサポートされているその他のチャネルを介してエージェントを公開できます。

 

↑ 目次に戻る


この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-advocate-blog/servicenow-action-fabric-a-detailed-wal...。

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-advocate-blog/servicenow-action-fabric-a-detailed-wal...。