Gemini/Copilotを業務の入り口へ、
AI時代の業務オーケストレーターとしてのServiceNow

Geminiとの対話から、
ServiceNowの業務を進める。

ServiceNowとGoogle Cloudは2026年10月27日、業界別の業務フローをGemini Enterpriseにつなぐ提携拡大を発表しました。ServiceNow Action Fabricを通じ、日常使うAIアシスタントから複数の手順を伴う業務を進める構想です。^[1]

今回の主題は、単にServiceNowの中でGeminiのモデルを使うという話ではありません。Gemini Enterpriseを利用者の入口にして、ServiceNowの業務フローへ接続するという説明になっています。

表：両社の共同発表を整理。提供状況は2026年10月27日の発表時点。[1][2]

接続にはMCPサーバーとA2A接続を用いるとされています。Google Cloud Marketplaceでのプラグイン、共同デモ、参照アーキテクチャの公開も計画されています。^[2]

AI連携には、
「取り込む」と「外から動かす」の2方向がある。

ServiceNowとAI各社の提携を一列に並べると、似たニュースに見えるかもしれません。しかし、AIモデルの利用と、AIアシスタントを業務の入口にすることは、異なる連携です。私は、次の2方向に分けると、ServiceNowの狙いが見えやすくなると考えています。

表：連携を読むための整理。方向A・Bは製品の正式な分類ではなく、同じ構成の中で組み合わされる場合もあります。モデル、AIアシスタント、開発基盤は区別しています。

OpenAI / ChatGPT：モデルの組み込みと、MCP接続を分ける

2026年1月20日、ServiceNowとOpenAIは複数年契約による協業を発表しました。発表当時のGPT-5.2を含むモデルをServiceNow AI Platformへ組み込み、業務の自動化や直接的な音声対話を広げる内容で、主に方向Aとして読めます。AI Control Towerは、モデルの適用と業務実行を把握・統制する層として説明されています。^[3]

一方、方向Bについても、ServiceNowのMCP ServerリリースノートはChatGPTをクライアントの例に挙げています。^[8] ただし、モデル利用の契約によって、そのままChatGPTにすべてのServiceNow業務が追加されるわけではありません。利用するクライアント、公開するツール、認証と権限を組み合わせて確認する接続です。

Anthropic / Claude：開発を支えるモデルと、外部クライアントの両面

2026年1月28日の発表では、ClaudeがServiceNow Build Agentのデフォルトモデル、ServiceNow AI Platform全体での推奨モデルの一つとして位置付けられました。自然言語からアプリやワークフローを作る領域を支える、方向Aの分かりやすい例です。^[4]

方向Bにも具体的な手順があります。ServiceNowは、Claude DesktopからService Mapping MCP ServerへカスタムコネクタとOAuthを用いて接続する公式手順を公開しています。^[9] この例は特定のサーバー・用途についてのもので、全機能がワンクリックで使えるという意味ではありません。

Microsoft / Copilot：日常の仕事の入口と、統制領域を広げる連携

Microsoftとの関係には、モデルを利用する方向Aと、Copilotを入口にする方向Bの両方があります。方向Aの例として、Generative AI Controllerの公式資料はAzure OpenAIを接続先に挙げています。^[11] Azure OpenAIを使うことと、Microsoft 365 Copilotを使うことは、別の設計です。

方向Bでは、Knowledge 2024でNow AssistとMicrosoft Copilotの統合が発表され、Teams内のCopilotからNow Assistへ依頼をつなぐ方向が示されました。^[5] 2026年1月更新の設定資料は、従来のDeclarative AgentをCustom Engine Agent（CEA）へ置き換える移行も説明しています。^[10]

2025年11月のIgniteでは、AI Control TowerとMicrosoft Foundry・Copilot Studioの連携、Build AgentからGitHubのMCPサーバーを使う連携などが発表されました。^[6] これらは入口、開発、統制という異なる層の連携です。

さらに2026年5月のKnowledgeでは、AI Control Towerの統制をMicrosoft Agent 365へ広げ、ServiceNowのAIスペシャリストを同Marketplaceで提供する方針が発表されました。役割・権限・責任を持つデジタル従業員として扱う構想も含まれています。^[7]

Google / Gemini：今回の発表は、外部AIを入口にする方向B

Googleについても、Generative AI Controllerの接続先にはGoogle AI StudioやVertex AIが挙げられています。^[11] 一方、今回のニュースはGemini Enterpriseの対話からServiceNowの業務へ進む方向Bの具体化です。モデルの選択肢が増える話と、利用者が仕事を始める場所が広がる話を分けることが重要です。

表：公開情報の整理。契約・発表・設定手順は、それぞれ提供範囲の異なる情報です。同じ深さ・同じ条件の連携であることを示すものではありません。

AI時代のServiceNowを、
業務オーケストレーターとして捉える。

私は、この2方向の連携が広がることで、ServiceNowの役割がより明確になると考えます。利用者がGeminiやCopilotから依頼する場合も、ServiceNow内のAIから始める場合も、仕事には対象の特定、情報の確認、承認、担当への引き継ぎ、実行結果の記録があります。人・AI・既存システムをまたぐ仕事の順序と状態をつなぎ、完了まで進める。それが業務オーケストレーターとしての役割です。

ここで、すべての推論や対話をServiceNowが指揮する、と捉える必要はありません。外部AIが依頼の解釈やツール選択を担い、ServiceNowが公開した業務フローを実行する構成もあります。入口側の判断と、会社として管理する業務の実行を分け、その間に権限と責任の境界を設計することが重要です。

日本企業への適用を考えると、対話の入口を変えるだけでは解決しない問題があります。部署によって同じ設備の呼び名が違う、問い合わせ先の判断を一部の人だけが知っている、対応後の結果が別のExcelに残る。こうした状況では、AIが依頼を受け付けても、その後の確認待ちは残ってしまいます。

CopilotとGeminiを入口にする、もう一つの意味

私の現場感では、日本の大企業ではTeamsを中心に日々の連絡や会議を進めるケースが多く、中堅企業やベンチャー企業ではGoogle Workspaceを仕事の基盤にしているケースもよく見られます。どの対話型AIが業務に定着するかを考える際、この既存の仕事の場との近さは重要です。

Microsoft 365を使う組織ではCopilot、Googleの環境を使う組織ではGeminiが、日常業務で利用されるAIの有力な候補になります。利用者に新しい業務画面を覚えてもらうだけでなく、普段の対話の延長で仕事を依頼できるようにする。その接点を押さえることには、大きな意味があると考えます。

利用される可能性の高いAIの入口から、ServiceNowの業務へつながる状態を作る。CopilotとGeminiの両方を入口にできれば、顧客がどちらの仕事環境を選んでいても、ServiceNowは裏側で業務をつなぐ役割を担いやすくなります。私は、こうした連携が、業務オーケストレーターとしてのServiceNowの位置を固めることに役立つと見ています。

現場の言葉を、共通の記録につなげる

現場で使う言葉を、すべてシステム用語へ置き換える必要はありません。「レジ横の端末」といった表現から対象設備を候補として示し、必要な確認をした上で正しい記録へつなぐ。そのために、店舗、設備、契約、担当、過去の対応などの関係を整えておく必要があります。

同じ問題が複数の入口から報告されても、同じ設備・案件・顧客の情報として扱えることが重要です。入口のAIが増えるほど、裏側のデータと業務の意味を揃える価値は高まると考えます。ただし統制はServiceNowだけで完結するとは限りません。MicrosoftやGoogle等の管理機能と、どちらが何を制御し、どこに記録を残すかを合わせて設計します。

前回のCPQ記事とつながる、営業での使い方

前回のCPQ記事では、営業の「経験と勘」を組織知として使い、見積もりから生産・提供、サポートと追加提案までをつなぐ意義を考えました。今回は、その業務の入口にGemini Enterpriseという選択肢が加わる話として読むことができます。

商談の内容から構成と見積もりへ進めても、参照する商品・価格・契約が古ければ確認のやり直しになります。見積もりをどこから依頼したかにかかわらず、確定した条件が受注や提供へ渡り、その後の結果を次の提案へ戻せることが重要です。

現場の創意工夫を、誰でも使える業務へ

店舗や営業、ITの担当者は、それぞれの現場で経験を積み、仕事を進めるための工夫を持っています。AIとの対話を通じて判断の理由や不足する情報を取り出し、確認した知識を共通の業務へ戻せれば、その工夫を他の人にも広げられます。

私は、今回の連携の可能性を、画面の切り替えが減ることだけに置きたくありません。普段使うAIから、組織として蓄積した知識と業務を利用できるようにする。その上で、依頼から完了までのどこに待ち時間や手戻りがあるかを見つけ、改善し続けることを目指したいと考えます。

自社で運用するために、
まず整えること。

GeminiやCopilotが業務の入口になっても、自社で運用するために必要な土台は変わりません。ServiceNow上に業務を記録できるように標準化し、共通マスタを整え、タスクの運用ルールを決める。この地道な取り組みが最も重要だと考えています。

業務を、共通の記録として残せるようにする

同じ依頼でも、部署ごとに記録する内容が違い、対応結果がメールやExcelに散らばっていては、AIも業務の状況を正しく把握できません。何を受け付け、どの情報を記録し、何をもって完了とするか。現場の仕事を、ServiceNow上で状態と経緯を追える形へ標準化する必要があります。

すべての現場を一律の手順に揃えるという意味ではありません。共通に記録する項目と、業務ごとに必要な違いを整理し、例外も理由とともに残せるようにすることが重要です。

共通マスタと、タスクの運用ルールを整える

顧客、組織、拠点、設備、製品、サービスなどについて、同じ対象を同じものとして扱える共通マスタを整えます。既存システムを正本とする場合も、識別子と対応関係、更新する責任者を明確にします。入口のAIが変わっても、参照する業務の事実がぶれないようにするためです。

その上で、タスクを誰が受け取り、どの状態へ進め、いつ引き継ぎ、どこで承認するかを決めます。担当が決まらない、期限を過ぎた、追加情報が必要といった場合の扱いも含めて、運用ルールにします。自然な回答を返せること以上に、仕事が宙に浮かず、最後まで進む仕組みが必要です。

地道な整備も、各駅停車から新幹線へ

地道なアプローチと書きましたが、その進め方まで従来と同じである必要はありません。AIの登場によって、これまでは各駅停車で一つずつ進めていた整備に、新幹線を使えるようになってきたと感じています。

例えば、過去の対応記録や業務マニュアルから共通の手順と例外の候補を抽出する。部署ごとの用語を比較してマスタの対応候補を作る。タスクの状態や引き継ぎ条件、記録項目の下書きを整理する。こうした作業にAIを使えば、人は候補の確認と、業務として何を採用するかの判断へ時間を使いやすくなります。

AIが作った候補を現場と管理者が確認し、小さな範囲で試し、結果を次の整備へ戻す。共通マスタの正しさやタスクの責任をAI任せにするのではなく、整備と検証のサイクルを速く回していく使い方です。

目的地も、整えるべき土台も変わらない。ただし、そこへ向かう速度は変えられる。GeminiやCopilotとの接続だけで終わらせず、AIを使って業務の標準化そのものを進めることが、ServiceNowを業務オーケストレーターとして生かすための、とっかかりになると考えます。