ページの先頭です

ページ内を移動するためのリンク
本文へ (c)

ここから本文です。

ServiceNowとOutlook予定表を連携してみた

初めに

本記事の目的

業務において、ServiceNow上のデータとOutlookMicrosoft Exchange)の予定表を同期させたいという要件は少なくありません。通常であればServiceNowが提供する「Spoke」を利用するのが一般的ですが、ライセンスや環境の制約により利用できないケースもあります。

本記事では、Spokeを利用せず、フルスクラッチでServiceNowOutlookを連携させる方法について、実際の実装事例をもとに解説します。

この記事で分かること

  • ServiceNowからMicrosoft Graph API※経由でOutlook予定を作成・更新・削除する仕組み
  • 「委任されたアクセス許可(Delegated permissions)」環境下での認証・トークン管理の実装
  • API連携開発における具体的な考慮点と運用上の注意点

Microsoft Graph APIとは
Microsoft Graph API
は、Microsoft 365のサービスのデータにアクセスするためのRESTful Web APIです。

ライター:加藤 耕志マルク
2021年入社。ServiceNowなどを使った開発業務を主に担当。

目次

なぜ ServiceNow × Outlookを連携するのか

連携しない場合に発生する典型的な運用課題

今回開発した「INNOVATION SHOWCASE予約システム」の事例では、従来、以下のような運用課題を抱えていました。

  • 手動対応による工数増大: システムで予約を受け付けた後、運営メンバーが手動でOutlook予定表を開き、内容を転記・編集していた。
  • 更新・キャンセルの反映漏れ: 予約内容の変更やキャンセルが発生した際、Outlook側の修正を忘れるリスクがあった。

これらの課題は予約システムに限らず、インシデント管理や承認フローでも同様です。連携がない場合、ServiceNow上では承認されているのに予定表が確保されていない、あるいは担当者の予定が空いているように見えて実は作業が入っているといった「情報の不整合」が起き、チケット管理やリソース調整が属人化してしまいます。

INNOVATION SHOWCASE予約システムとは
本システムは、弊社営業社員がINNOVATION SHOWCASEにお客様をご案内するためのアテンド予約を行うシステムです。
INNOVATION SHOWCASE
についてはこちらの記事をご覧ください。

運用改善・自動化によるメリット

Outlook連携を自動化することで、上記運用課題が解決されるとともに以下のメリットが得られます。

  • 対応スピード向上: ステータス変更と同時に予定表が更新されるため、タイムラグがなくなり、顧客や社員への対応スピードが向上します。
  • 作業ミスの撲滅: 手動転記による入力ミスや更新漏れをシステム的に防ぐことができます。

連携アーキテクチャ概要

本事例におけるシステム連携の全体像です。ServiceNow上のステータス変更をトリガーに、Graph APIを介してOutlookへリクエストを送信します。

処理の流れは以下の通りです。

  • ServiceNowの予約テーブルで作成・更新・削除が発生。
  • Business Rule(図中④)が起動し、Script Include(図中⑤)がAPI用データを構築。
  • 保存されたRefreshTokenを用いてAccessTokenを取得(図中②)(AccessTokenの期限が切れていた場合)。
  • Graph APIを叩き、Outlook予定表を操作。(図中⑥)

実現できるユースケース一覧

  • 承認ワークフローを Outlook予定表と連動

申請書が「承認」ステータスになった時点で、関係者のOutlook予定表に会議通知を自動送付したり、期限をタスクとして登録したりすることが可能です。

  • 技術者のリソース管理(Outlook予定との統合)

フィールドサービス管理などにおいて、ServiceNowで作業員(技術者)をアサインした際、その作業日時を技術者本人のOutlookカレンダーへ自動登録します。これにより、ダブルブッキングを防ぎ、正確なリソース管理が可能になります。

連携の準備

Exchange(Microsoft 365)側の準備

Graph APIを使用するには、Azure ADEntra ID)へのアプリ登録が必要です。

通常、バックグラウンド処理には「アプリケーションのアクセス許可」が推奨されますが、今回は諸事情により「委任されたアクセス許可」を使用しました。

  • 委任されたアクセス許可: ユーザーの権限でAPIを実行します。初回にユーザーによるログインが必要です。
  • アプリケーションのアクセス許可: 管理者の同意のみで動作し、ユーザー操作は不要です。可能な限りこちらが推奨されます。

ServiceNow 側の準備

ServiceNow側では認証に、Connections and Credentialsを利用するのが標準的だと思いますが、諸事情でこの機能を利用できなかったので、今回はフルスクラッチで認証周りを実装しました。

特に「委任されたアクセス許可」ではRefreshTokenの維持管理が重要になるため、API連携用のユーザーで初回ログインを行い、RefreshTokenを取得・保存する仕組みを用意しました。

万が一RefreshTokenが失効してしまった場合に備え、運用担当者が簡単にトークン取得できるよう、専用のWidgetを作成しました。

連携フローの実装手順

実際に開発を行った際の手順を4つのステップに分けて解説します。いきなりすべてを実装するのではなく、APIの疎通確認から段階的に進めるのがポイントです。

Step 1. Scripts Background でのPoC

まずは本格的なコーディングの前に、ServiceNowからOutlookAPIが正しく叩けるかを確認します。

Scripts - Background」を使用し、最低限のコードでテストを行います。

  • 準備: PostmanCurlなどを使い、手動で一時的なAccessTokenを取得します。
  • 実行: スクリプト内でトークンをハードコーディングし、簡単なJSON(タイトルと日時のみなど)を組み立ててGraph APIのエンドポイントへPOSTします。
  • 確認: 実際にOutlook予定表に予定が作成されるかを確認します。ここでJSONの構造や必須項目(件名、開始・終了時刻など)の仕様を把握します。

Step 2. 認証周りの Script Include 作成

OAuthトークンの管理を行う専用のScript Includeを作成します。今回はSpokeを使わないため、この部分が肝となります。

  • 機能: Credentialsテーブルに保存されたRefreshTokenを読み込み、Graph APIのトークンエンドポイントへリクエストを送って新しいAccessTokenを取得する関数を実装します。
  • 期限管理: 毎回取得するのではなく、「現在のAccessTokenが有効か?」を判定し、切れている場合のみ再取得するロジックを組み込みます。取得後はCredentialsテーブルを更新します。

Step 3. API連携用の Script Include 作成

Step 1で検証したロジックと、Step 2の認証機能を組み合わせ、実業務で使えるAPI連携用Script Includeを作成します。

  • データ整形: 予約テーブルのレコード(GlideRecord)を受け取り、Outlookが要求するJSON形式(Subject, Body, Start/End Time, Attendeesなど)に変換する関数を作ります。
  • CRUDの実装: 作成(POST)、更新(PATCH)、削除(DELETE)の各メソッドを用意します。
  • エラーハンドリング: API呼び出しが失敗した場合のログ出力や、リトライ処理(必要な場合)についても考慮します。

Step 4. トリガーとなる Business Rule (BR) の作成

最後に、予約テーブル上の操作を検知してスクリプトを起動させるBusiness Ruleを作成します。

  • 条件設定: 予約テーブルに対し、Insert(作成)、Update(更新)、Delete(削除)の各操作が行われた際に発動するように設定します。
  • 実行タイミング: 外部API連携は処理時間を要するため、ユーザーの操作画面をブロックしないよう Async(非同期)での実行を推奨します。
  • 処理: Step 3で作成したScript Includeを呼び出し、変更があったレコードの情報を渡します。これにより、ServiceNow上の操作が自動的にOutlookへ反映されるようになります。

運用でつまずきやすいポイント(落とし穴)

今回のフルスクラッチ開発で特に考慮が必要だったポイントです。

  • API連携失敗時のリカバリー:

API連携が失敗した時の動きについて、あらかじめ決めておく必要があります。
自動で再同期してくれる仕組みを作るのが理想的ではありますが、工数や運用によっては「一旦エラー通知だけ飛ばして、あとは手動で直す」というシンプルな運用にするのも手だと思います。

  • RefreshTokenの有効期限:

「委任されたアクセス許可」の場合、RefreshTokenにも有効期限や無効化の条件があります。定期的にAPIが利用される環境であれば自動更新されますが、長期間利用がないとトークンが失効し、再度の手動認証が必要になる点に注意が必要です。

応用例:ここまで自動化できる

今回の予約システム連携をベースに、さらなる自動化も検討できます。

  • 技術者アサインの最適化

予定表の空き状況をServiceNowから参照することで、空いている技術者を自動でアサインし、そのまま予定を押さえるといった双方向の連携もGraph APIで実現可能です。

  • メンテナンス予定の自動作成

定期的なメンテナンス計画(Change Management)が決まった時点で、全関係者のOutlookに予定を配布し、変更があった場合も即座に同期することで、連絡漏れによるトラブルを防ぐことができます。

まとめ

今回は、ServiceNowSpokeが利用できない環境において、「委任されたアクセス許可」とGraph APIを用いてOutlook連携をフルスクラッチで実装しました。

  • 制約があっても実現可能: 標準機能が使えなくても、APIの仕様を理解すれば要件を満たすことができます。
  • 自動化の効果: 予約管理業務における手動工数を削減し、情報の即時反映を実現しました。

同じような制約環境でServiceNowOutlookの連携を検討されている方の参考になれば幸いです。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

RECOMMEND