SNUG東京ミートアップ イヤーエンドパーティー25でこの記事をテーマにLT登壇させていただきました!
この記事は ServiceNow アドベントカレンダー 2025 の12月14日分の記事として執筆しています。
企業内では、建物や会議室、プロジェクターなどの共有備品、さらには社用車といった各種リソースの管理をGoogle Workspace(Googleカレンダー)で行い、申請や承認のフローはServiceNowで管理する、という構成を取っているケースが多くあります。
しかし、これらのシステムが分断された状態で運用されていると、
- Google管理コンソールでの手動による会議室・備品・車両リソースの作成・修正
- 手入力による入力ミス
- 誰が・いつ・なぜ作成・変更したのかといった履歴が残りにくい
- 会議室・備品・社用車の予約管理がシステム上で分断されている
- 特に共有備品は変更スパンが短く、そのたびにGoogle Workspace管理者が手作業で修正対応を行う必要がある
といった課題が発生しがちです。
共有備品は、「台数の増減」「設置場所の変更」「故障による一時停止」「管理部門の変更」など、会議室や建物に比べて情報の変更頻度が高いリソースです。
そのたびにGoogle Workspace管理者が管理コンソール上で個別に修正する運用を続けていると、管理者の工数が積み重なり、属人化や対応遅延の原因にもなります。
そこで本記事では、ServiceNowのカタログ申請を起点として、会議室や共有備品といった各種リソースをGoogle Calendar上に自動作成・反映する仕組みを構築しました。
この仕組みにより、
- 利用者からの申請
- 承認フロー
- Google側へのリソース作成・更新
までをすべて自動化でき、Google Workspace管理者が個別に手作業でリソース管理を行う必要がなくなります。
本記事では、その具体例として、ServiceNow × Google Workspace連携によるリソース作成の自動化構成と実装ポイントを解説します。
本記事ではGoogle Workspaceを例に紹介していますが、構成自体は「ServiceNow + OAuth2 + REST API」という汎用パターンなので、OAuth 2.0でトークンを出してくれてREST API公開されているサービスであれば応用が可能です。
目次
概要
【ServiceNow申請 → Calendar Resource(会議室など)の作成】が完全自動化されます。
Calendar Resourceが作成されると、Google Calendarの会議室一覧に表示され、予約ができるようになります。
前提
-
Google Workspaceで建物が管理されていること
- リソースの作成には建物の情報(ビルディングID、階の名前)が必要になります
-
ServiceNowで統合ハブが使えること
- REST APIを使用した機能実装に必要です
Google側の接続設定
今回の構成では、OAuth 2.0クライアントを使用します。
Google Cloud プロジェクト作成
Google CloudとServiceNowの連携に使用するプロジェクトを作成します。
- Google Cloud Consoleで新規プロジェクト作成
- 「APIとサービス」→「ライブラリ」から以下APIを有効化
- 「APIとサービス」→「認証情報」→「認証情報を作成」から「OAuthクライアントID」を作成(OAuth同意画面が未構成の場合は作成してください)
- アプリケーションの種類:ウェブアプリケーション
- 名前:任意の名前
- 承認済みのリダイレクトURI:https://{instance}.service-now.com/oauth_redirect.do
- クライアントIDとクライアントシークレットを控える
ServiceNow側の接続設定
ServiceNowのバージョンはZurichです。
OAuthプロバイダーの設定
Google Cloudと接続するためのOAuthプロバイダーを作成します。
-
アプリケーションレジストリ[oauth_entity]に新規レコードを追加しOAuthプロバイダーを作成
-
以下の内容でOAuthプロバイダーを構成
- 名前:任意の名前
- クライアントID:Google Cloud Projectの認証情報作成で控えたクライアントID
- クライアントシークレット:Google Cloud Projectの認証情報作成で控えたクライアントID
- 認証URL:https://accounts.google.com/o/oauth2/v2/auth?access_type=offline&prompt=consent&include_granted_scopes=true
- トークンURL:https://oauth2.googleapis.com/token
- デフォルトの権限許可タイプ:権限コード
-
OAuthエンティティスコープ[oauth_entity_scope]に以下2つを追加
- https://www.googleapis.com/auth/admin.directory.resource.calendar
- https://www.googleapis.com/auth/calendar
OAuth認証の設定
次に、OAuth認証のリフレッシュトークンを保存するための認証情報を作成します。
-
OAuth2.0認証情報[oauth_2_0_credentials]を作成
- 名前:任意の名前
- OAuthエンティティプロファイル:OAuthプロバイダーのデフォルトOAuthエンティティプロファイル
-
作成したOAuth2.0認証情報の関連リンクから「OAuthトークンの取得」をクリックし、初回認可を行う
接続情報&資格情報エイリアスの設定
Flow actionで使いやすいよう接続エイリアスを作成します。
- 接続情報&資格情報エイリアス[sys_alias]を作成
- 名前:任意の名前
- タイプ:接続と資格情報
- 接続タイプ:HTTP
- 関連リストの接続[sys_conncection]タブから接続情報を新規作成
- 名前:任意の名前
- 接続タイプ:HTTP(S)接続
- 認証情報:OAuth認証の設定手順1で作成したOAuth2.0認証情報
- 接続エイリアス:手順1で作成した接続情報&資格情報エイリアス
- 接続URL:https://admin.googleapis.com
疎通確認に使用するカスタムアクション
接続構成が正しく行えているかの確認、本番リリース時にGoogle Workspace側のデータを変更せず疎通確認する場合に使えるカスタムアクションを紹介します。
リソースの一覧取得(Admin SDK Directory APIの疎通確認)
Admin SDK Directory APIのMethod: resources.calendars.listを使用します。
- Workflow Studioで新規アクションを作成
- アクション名:任意
- RESTステップを作成
このステップでリソースリストを取得します。- 接続の詳細
- 接続:接続エイリアスを使用
- 接続エイリアス:作成した接続エイリアス
- ベースURL:https://admin.googleapis.com
- 要求の詳細
- ビルド要求:手動
- リソースパス:/admin/directory/v1/customer/my_customer/resources/calendars
- HTTPメソッド:GET
- 接続の詳細
カレンダーの一覧取得(Calendar APIの疎通確認)
Calendar APIのCalendarList: listを使用します。
- Workflow Studioで新規アクションを作成
- アクション名:任意
- RESTステップを作成
このステップでカレンダーリストを取得します。- 接続の詳細
- 接続:接続エイリアスを使用
- 接続エイリアス:作成した接続エイリアス
- ベースURL:https://www.googleapis.com
- 要求の詳細
- ビルド要求:手動
- リソースパス:/calendar/v3/users/me/calendarList
- HTTPメソッド:GET
- 接続の詳細
リソース作成に使用するカスタムアクション
リソースの作成・カレンダーの設定を行うカスタムアクションを作成します。
リソースの新規作成
Admin SDK Directory APIのresources.calendars.insertを使用します。
-
Workflow Studioで新規アクションを作成
- アクション名:任意
- 入力
- resource_name : リソース名
- building_id : ビルディングID
- floor_name : 階の名前
- capacity : 収容人数
- resource_category : リソースのカテゴリ(会議室かそれ以外か)
-
RESTステップを作成
このステップでリソースを作成します。- 接続の詳細
- 接続:接続エイリアスを使用
- 接続エイリアス:作成した接続エイリアス
- ベースURL:https://admin.googleapis.com
- 要求の詳細
- ビルド要求:手動
- リソースパス:/admin/directory/v1/customer/my_customer/resources/calendars
- HTTPメソッド:POST
- ヘッダー
- Content-Type:application/json
- 要求コンテンツ
- 要求タイプ:テキスト
- 要求本文[テキスト]
以下情報など参考に要求本文を設定してください。
-
リソース ID : ~ 新しいリソースを作成する際は、この項目を空のままにしておけば ID が自動的に生成されます
リソースIDが空でも自動生成されるとありますが、私の環境ではリソースIDを指定しないとエラーが発生したため、事前にスクリプトステップでUNIXタイムを使いリソースIDを作成して対処しました。
リソースIDはユニークな文字列になれば何でもよいです。参考のスクリプトを記載しておきます。リソースID作成スクリプトの例
(function execute(inputs, outputs) { outputs.resourceid = '' + new Date().getTime(); //文字列型となるようにしています。出力変数にはresourceidを設定してください。 ))(inputs, outputs);
設定例{ "kind": "admin#directory#resources#calendars#CalendarResource", "resourceId": "{UNIXタイムなど一意な文字列}", "resourceName": "{resource_name}", "resourceCategory": "{resource_category}", "capacity": "{capacity}", "buildingId": "{building_id}", "floorName": "{floor_name}" }
- 接続の詳細
-
JSON Parserステップを作成(オプション)
出力にレスポンスを設定したい場合はJSON Parserステップを作成してください。- ソースデータ:RESTステップの応答本文
RESTステップでテストを行い、得られた応答本文を貼り付けて「ターゲットを生成」を実行してください。
- ソースデータ:RESTステップの応答本文
リソースのタイムゾーン設定(オプション)
Google Workspaceでグローバル拠点を管理している場合は必要になります。
Calendar APIのCalendars: patchを使用します。
- Workflow Studioで新規アクションを作成
- アクション名:任意
- 入力
- calendar_id:リソース作成レスポンスのresourceEmail
- timezone:IANAタイムゾーン形式(Asia/Tokyoなど)
- RESTステップを作成
このステップでタイムゾーンを設定します。- 接続の詳細
- 接続:接続エイリアスを使用
- 接続エイリアス:作成した接続エイリアス
- ベースURL:https://googleapis.com
- 要求の詳細
- ビルド要求:手動
- リソースパス:/calendar/v3/calendars/{calendar_id}
- HTTPメソッド:PATCH
- ヘッダー
- Content-Type:application/json
- 要求コンテンツ
- 要求タイプ:テキスト
- 要求本文[テキスト]
- 接続の詳細
カタログアイテム
ユーザーから会議室の作成を受け付けるカタログアイテムを作成します。
必要なカタログ変数の例は以下
| 名前 | タイプ | 備考 |
|---|---|---|
| resource_name (会議室の名前) | 1行テキスト | ユーザーの自由入力でよいと思います |
| resource_category (リソースのカテゴリ) | 選択ボックス | 会議室(CONFERENCE_ROOM) or その他(OTHER) |
| building_id (建物) | 選択ボックス | Google Workspaceで管理している建物のビルディングID |
| floor_name (階) | 選択ボックス | building_idに紐づく階の名前 |
| timezone (タイムゾーン) | 選択ボックス | IANAタイムゾーン形式(Asia/Tokyoなど) |
building_idの選択に基づいてfloorの選択肢が動的に変わるよう設定するとよいと思います。
フローの中で先述の各アクションを必要に応じて呼び出してください。
まとめ
ServiceNowからGoogle Calendar上に会議室や共有備品といった各種リソースを自動作成・反映する仕組みを紹介しました。
リソースの更新や削除はREST Resource: resources.calendarsのupdateやpatch、deleteで実装できます。
認証方式にはOAuth2.0を使用しましたが、Google側にサービスアカウントとドメイン全体の委任(DWD)、ServiceNow側にJWTベアラーを設定する方式でも構築可能です。
認証方式は組織の運用ポリシーなどに応じて適切なものを選択してください。
また、今回はGoogle Workspaceを例にしましたが、構成自体は「ServiceNow + OAuth2 + REST API」という汎用パターンなので、OAuth2.0でトークンを出してくれて、REST APIが公開されているサービスであれば応用が可能です。
本記事は初心者でもそのまま実装できることを目指し、なるべく省略せずGoogle Cloudのプロジェクト作成やServiceNowのアプリケーションレジストリの作成から説明しています。
この記事が読者の皆さんの実装のヒントや課題解決の手助けとなれば幸いです。
もしご質問やフィードバックがございましたら、ぜひコメント欄でお知らせください。






