ServiceNow にナレッジを溜めていても、普段 Teams や Outlook で仕事をしている人にとっては「わざわざ ServiceNow を開く」というひと手間が意外と大きな壁になります。
Microsoft が公式に提供している Copilot コネクタを使うと、ServiceNow のナレッジ記事を Microsoft 365 側にインデックスして、Copilot から出典付きで引っ張ってこられるようになります。
今回は ServiceNow の無料開発者インスタンス（PDI）を使って、実際に接続できるところまでやってみました。手順そのものより、どこでつまずくかのほうが役に立つと思うので、そのあたりも含めて書いていきます。
全体の流れ
作業する画面が3つに分かれます。ここを最初に押さえておくと迷いません。
- ServiceNow — ナレッジを用意して、外から読める状態にする
- Microsoft 365 管理センター — コネクタを作って記事を取り込む
- Copilot Studio — エージェントのナレッジ ソースとして追加する
特に1と2を行ったり来たりするので、ブラウザのタブは分けておくと楽です。
まずは開発者インスタンスを用意する
今回は個人用ということでまずは無料で利用できるインスタンスの用意から始めました。
ServiceNow は Personal Developer Instance（PDI） という無料の個人用インスタンスを配っていて、これがフル機能の非本番環境として使えます。管理者権限付きで、クレジットカードの登録も不要です。
アカウントを作る
まずは ServiceNow Developer Program のサイトにアクセスします。
メールアドレスがあれば登録できます。登録の途中で「Do you code?（コードを書きますか）」といった質問が出てきますが、これは表示される学習コンテンツをパーソナライズするためのもので、インスタンスの機能が変わるわけではありません。あとから設定で変更もできるので、深く考えずに進めて大丈夫です。
インスタンスを払い出す
サインインしたら、画面右上の Start building をクリックします。これでインスタンスの払い出しが始まります。そこそこ待ち時間が発生します。
数分待つと「Your instance is ready!」というポップアップが出て、次の3点が発行されます。
- インスタンス URL —
https://<インスタンス名>.service-now.comの形式 - ユーザー名 —
admin固定 - パスワード — 自動生成された文字列
パスワードは自分で決めたものではないので、必ず控えておいてください。後述の管理画面からいつでも確認できます。
バージョンを選べる場合は、最新のものを選んでおけば問題ありません。ただし PDI は数に限りがあるため、希望のリリースが払い出せないこともあります。そのときは古いバージョンを取得してから upgrade するか、順番待ちに登録する形になります。
「Manage my instance」は作業画面ではありません
ここが最初のつまずきポイントでした。
Developer サイトの Manage my instance という画面には、インスタンスの状態やプラグインの一覧が表示されます。一見すると設定画面のように見えるのですが、これはインスタンスを管理するための外側の画面です。
実際の設定作業は、そこに表示されている Instance URL をクリックした先で行います。
https://<インスタンス名>.service-now.com私は最初これを混同して、プラグイン一覧の画面でナレッジベースを探してしまいました。ざっくり言えば、こういう役割分担になっています。
| 画面 | できること |
|---|---|
| Developer サイト（Manage my instance） | プラグインの有効化、スリープからの復帰、バージョン確認、パスワード確認 |
| インスタンス URL の中 | ナレッジ、カタログ、フロー、OAuth などすべての設定作業 |
プラグインを追加したいとき
PDI はほぼベースラインの状態で払い出されるため、標準では入っていない機能があります。Employee Center や HRSD などを使いたい場合は、Manage my instance 画面の下部にある Plugins for your instance から検索して有効化します。今回は特に利用しませんが、今後何か使いたい場合は覚えておくと良いかもしれません。
インスタンスの中からではなく Developer サイト側から操作する、というのが少し独特なところですね。
ナレッジベースと記事を作る
ServiceNow にログインしたら、左上の「All」メニューから作業を始めます。ここは検索ボックス付きのメニューになっていて、機能名を打ち込むのが一番速いです。
ナレッジベースからまずは作業をしています。基本的に新規で作成する場合は、New から作成します。入力するのは実質3つだけです。
- Title — ナレッジベースの名前
- Owner / Managers — 自分
- Publish flow — 検証なら
Knowledge - Instant Publish（承認なしで即公開）
保存すると関連タブが増えるので、そこでカテゴリを作り、記事を1本書いて Publish します。
ここでひとつだけ必ず確認しておきたいのが、保存後に現れる Can Read タブです。ここに Any User が入っていれば大丈夫。新規作成の場合は自動で入るので、通常は確認するだけで済みます。
なぜこれが重要なのかは、後半の「つまずいたポイント」で触れます。
シンプルか、詳細設定か
Microsoft 365 側でコネクタを作るとき、「ユーザー条件の設定に基づいて選択します」という分岐があります。ここでシンプルを選ぶか詳細設定を選ぶかで、この先の作業量が大きく変わります。
今回は学習も兼ねて詳細設定で進めました。
以降の「ACL」「Scripted REST API」「リソース」の3つは、詳細設定を選んだ場合にだけ必要になる作業です。シンプルを選んだ方は読み飛ばしていただいて構いません。
ACL、API、リソースの関係
この3つはセットになっていて、入れ子の関係になっています。
- リソース — 「このユーザーはどの条件に合致するか」を返す処理の本体
- Scripted REST API — リソースを置くための器。単体ではリソースを作れません
- ACL — そのエンドポイントを実行してよいかを決める鍵
つまり、中身を置くために器が要り、器を使えるようにするために鍵が要る、という構造です。作成順が ACL → API → リソースになるのは、API を保存するときに Default ACLs が必須項目になっているためですね。
ACL を作る
ACL の作成画面を開くには、まず右上のアバターから Elevate role で security_admin に昇格しておく必要があります。これをしないと画面が出てきません。
設定内容はシンプルです。
| 項目 | 値 |
|---|---|
| Type | REST_Endpoint |
| Operation | execute |
| Name | 分かりやすい名前 |
| Requires role | admin（本番なら専用ロール） |
Scripted REST API を作る
System Web Services > Scripted REST APIs から New で作成します。API ID には microsoft_copilot を指定します。ここは Microsoft 側で決められている値なので、変更できません。
Default ACLs には標準の Scripted REST External Default と、先ほど作った ACL の両方を入れておきます。
保存すると Base API path が確定して、こんな形になります。
/api/<API名前空間>/microsoft_copilotこの <API名前空間> の部分がインスタンスごとに割り当てられた値で、あとで Microsoft 365 側に入力するので控えておきましょう。
リソースを登録する
API を保存すると Resources タブが現れるので、そこで New。
- Name:
GetAllUserCriteria - Relative path:
/user_criteria - Script: Microsoft Learn に掲載されているものをそのまま使います
スクリプトの中身は、リクエストで渡されたユーザーの sys_id を受け取り、アクティブな User Criteria のうち合致するものだけを配列で返す、という処理です。全文は Microsoft Learn の「ServiceNow Knowledge Copilot connector」のセットアップ ページに掲載されているので、そちらからコピーしてください。
保存前に、Requires authentication と Requires ACL authorization の両方にチェックが入っていることを確認します。ここが抜けると認証が効きません。
OAuth のインバウンド登録
ここが今回一番のハマりどころでした。
Machine Identity Console の Inbound integrations から New integration を選び、OAuth – Authorization code grant を選択します。管理者がブラウザ上で承認する方式なので、これが正解です。
入力する項目はこのあたりです。
- Provider name: Microsoft
- Redirect URLs: 後述の固定値
- Auth scope:
useraccount - This is a public client: オフのまま
リダイレクト URL は画面に出てきません
Microsoft 365 側の設定画面を見ても、貼り付けるべきリダイレクト URL がどこにも表示されないんです。実はこれ、固定値が決まっています。
https://gcs.office.com/v1.0/admin/oauth/callbackこれを ServiceNow 側の Redirect URLs に手で登録します。ここが漏れていると、認可のボタンを押した瞬間にエラーで止まってしまいます。知らないとまず気づけないところなので、覚えておくと良いと思います。
Auth scope を空にしない
もうひとつ、地味ですが厄介なのがこちらです。
Auth scope を空のままにしても、認可自体は成功してしまいます。ところがクロールの段階になると全件失敗する、という挙動になります。エラーメッセージと症状が結びつかないので、原因にたどり着くまでに時間がかかるタイプの設定です。
useraccount はサインインユーザーが到達できる全リソースへのアクセスを許可するスコープなので、本来は慎重に扱うべきものです。ただコネクタは十数個のテーブルを読む必要があるため、実質これ以外の選択肢がありません。本番環境では、サービス アカウント側のテーブル権限で絞る必要があるでしょう。ただ今回の趣旨とは外れるのでスルーで。
保存したら、Client ID とクライアント シークレットを控えておきます。
Microsoft 365 管理センターでコネクタを作る
ここからは Microsoft 側の作業です。Copilot → コネクタ → ギャラリーから「ServiceNow ナレッジ」を選びます。
入力するのは次の項目です。
- 表示名
- ユーザー条件（シンプル / 詳細設定）
- API 名前空間（詳細設定の場合のみ）
- ServiceNow URL（末尾のスラッシュは付けない）
- 認証の種類 → OAuth 2.0
- クライアント ID / シークレット
認証の種類は初期状態で「フェデレーション資格情報」が選ばれていますが、これは Entra ID と ServiceNow の間に信頼関係を構成する方式で、検証には少し重いです。OAuth 2.0 に切り替えるのが現実的でしょう。
あとは「認可」をクリックしてポップアップで ServiceNow にサインインし、通知にチェックを入れて作成すれば完了です。
Copilot Studio でエージェントに追加する
後は作成したコネクタをエージェント側で設定するだけです。
ただし、ナレッジが参照されるまでにコネクタを管理センターから追加して、１時間程度はかかったので、少し時間を空けてからテストをしないと結果が何も帰ってこなくなりますのでご注意ください。
つまずいたポイント
実際にやってみて詰まった箇所をまとめておきます。
ユーザーのマッピングに失敗する
コネクタのエラー タブに「マッピングの式が無効であるか、このプロパティを持つ Azure AD ユーザーがいないため、ユーザー マッピングに失敗しました」というエラーが大量に並びました。
これは ServiceNow ユーザーのメールアドレスを Entra ID の UPN または Mail 属性と突き合わせる仕組みで、PDI のデモデータには実在しない架空のユーザーが大量に入っているため、当然全部失敗します。
自分のアカウントさえマッピングできていれば検証は進められるので、ServiceNow 側の自分のユーザー レコードの Email を、Copilot で使う Microsoft 365 アカウントのアドレスに合わせておきましょう。
単純に反映を待つ必要がある
そして最後に、これが意外と大きいのですが、Graph へのインデックス完了と Copilot からの検索可能タイミングは別物です。
私の場合は大体１時間程度はかかっていたと思います。（途中で抜けていたので正確な時間は覚えてないですが、大体それくらいだったかなと）
ついでにチケットも繋いでみる
ナレッジが通ったので、同じギャラリーにある「ServiceNow チケット」も試してみました。
こちらは task テーブルとその子テーブル（incident など）をインデックスするコネクタです。設定してみて驚いたのですが、ナレッジ版より圧倒的に簡単でした。事前に Client ID とsecretを手に入れておけばOKです。
- Scripted REST API は不要
- ACL も不要
- API 名前空間の入力欄すらない
- OAuth 登録はナレッジ版のものをそのまま使い回せる
ServiceNow 側で新しくやることは、ほぼありません。認証情報を入れて認可するだけで、あっさりインデックスまで通りました。
ただし注意点として、添付ファイルとコメント（work notes 含む）はインデックスされないらしい。また読み取り専用なので、Copilot からインシデントを起票したり更新したりはできません。それをやりたい場合は、Copilot Studio でエージェントでツールなりの利用が必要です。
いかがでしたでしょうか
まとめると、ServiceNow 側で本当に必要な設定は次の2つに集約されます。
- ナレッジベースの Can Read — 誰に見せるかを定義する
- OAuth のインバウンド登録 — 外から読むための認証を用意する
残りは Microsoft 365 側の画面でコネクタを追加する作業をすればOKです。
一度繋がってしまえば、普段使っている Copilot から社内のナレッジが出典付きで返ってくるようになります。ServiceNow のアカウントを持たない人にも情報を届けられるという意味で、問い合わせ対応の負荷を下げる効果は大きいのではないでしょうか。
無料の開発者インスタンスで最後まで試せるので、興味のある方はぜひ触ってみてください。参考になれば幸いです。
コメント