ChatGPTで、ITSMを高度化する。
トラブル調査から、将来の開発・変更管理へ。

ChatGPTとの対話を、
統制された業務実行につなぐ。

ServiceNowとOpenAIは2026年10月28日、協業の拡大を発表しました。中心となるのは、Action Fabricを介してChatGPTからServiceNowの業務へ接続するプラグインです。類似インシデントの検索、変更リスクの評価、対象レコードの更新などを例示し、実行と統制はServiceNow側に残ると説明しています。^[1]

協業の対象は対話だけではありません。セキュリティ分野の共同開発、AI Workflow FactoryへのCodex連携、音声によるAIリスク評価も含まれます。両社は相互の社内活用も計画し、OpenAIはControl Tower Allianceの創設メンバーとして参加します。

表：2026年10月28日の公式発表を整理。[1]

ChatGPTとの接続から、
開発・セキュリティへ広がる協業。

Gemini・Copilotの記事では、外部AIを入口に、ServiceNowの業務へつなぐ意義を整理しました。今回は、その接点にChatGPT向けの専用プラグインが加わった発表として読めます。対話の入口と、企業の権限・記録に基づく実行を分ける考え方は共通です。

今回、私が注目したいのは、その先です。協業は、Codexによる開発、サイバーセキュリティ、音声でのリスク評価へも広がっています。提供時期はそれぞれ異なりますが、調査で得た情報を修正や対処へつなぎ、その結果を業務の記録へ戻す可能性が見えます。

まずは、ChatGPTを使ったトラブル調査をどう設計できるか。その先に、Codexによる修正と変更管理をどうつなげるか。以下では、日本企業での使い方を、この順序で考えてみます。

ChatGPTを調査のUIに、
社内外の情報を突き合わせる。

私の現場感では、日本企業が日常業務で使う生成AIはCopilotやGeminiが圧倒的に多く、ChatGPTを業務用生成AIとして利用するケースは、そこまで多くないと感じています。そのため、日本企業における今回のOpenAI連携の主なユースケースは、システム開発やサイバーセキュリティの分野が中心になるのではないでしょうか。

※個人の感想です。執筆者が接する現場に基づく見方であり、日本市場全体の利用率や用途別の構成を示す統計ではありません。

こうした見方から、日本企業への適用として、私はまず、ITのトラブル対応に注目しています。インシデントを起票し、ServiceNow ITSM上で対応担当者をアサインする。その担当者がChatGPTをUIに必要な情報を集め、原因の仮説と確認手順を整理する運用です。担当と対応責任を明確にした上で、AIを調査へ組み込みます。

調査では、今起きている症状だけでなく、対象サービスの構成と依存関係、過去の類似インシデント、既存の問題レコード、直近の変更履歴が手掛かりになります。そこへ、ベンダーの障害情報や既知の不具合といった公開情報を合わせ、何から確かめるべきかを絞り込んでいきます。

ChatGPTをUIに、社内の業務情報と外部の公開情報を突き合わせ、根拠のある原因仮説を作る。今回の連携によって、こうした運用を設計していく道筋が具体的になると考えます。

Action Fabricは、ServiceNowの業務情報と操作への接点

公式発表は、ChatGPTから類似インシデントを検索し、変更リスクを評価し、対象レコードを更新する例を挙げています。^[1] この接続を担うのがAction Fabricです。ChatGPT側の対話や推論と、ServiceNow側で管理する業務の文脈・権限・実行をつなぐ役割として読めます。

自社で公開するツールと権限が対応していれば、CMDBや問題レコードなども調査へ組み込む設計が考えられます。一方、公開情報はChatGPT側の検索等、別の取得経路で集める想定です。すべての情報がAction Fabricを通る、という構成ではありません。

トラブルの受付から、原因仮説の検証・記録まで

1. インシデントを起票する
   担当者や既存の受付経路から、ServiceNow ITSMへ症状、発生時刻、対象、影響を記録する。
2. 対応担当者をアサインする
   ServiceNow ITSM上で自社の振り分けルールに従い、担当グループ・担当者を決定。対応責任と、誰が調査を進めるかを明確にする。
3. 担当者がChatGPTで調査対応する
   アサインされた担当者がChatGPTをUIに調査を開始。Action Fabricを介し、権限のあるServiceNowの情報を参照し、類似インシデントに加え、対応可能な範囲でCMDB、既存の問題、変更履歴を確認する。
4. 公開情報と突き合わせる
   ChatGPT側の検索等で、ベンダーの障害情報や既知の不具合を確認。製品・バージョン・時刻の一致と情報の信頼性を確かめる。
5. 原因候補と確認手順を整理する
   確認できた事実と推測を分け、候補ごとの根拠、不足情報、次に行う確認を示す。
6. 人が検証し、対応を判断する
   運用担当が証拠を確認。追加調査、回避策、エスカレーションを判断し、必要な変更は自社の承認・変更管理へつなぐ。
7. 調査経緯・結果をインシデントへ自動反映する
   ChatGPTでの調査対応に伴う確認結果と対応経緯を、Action Fabric経由の許可された更新操作で自動記録する設計とする。原因を確定できない場合も、残る仮説と次の担当を残す。

図：発表を踏まえた運用設計例。起票・担当者のアサイン後、担当者がChatGPTで調査し、経緯・結果をインシデントへ自動反映する流れです。インシデント起票は既存の受付経路を想定しており、プラグインによる起票を確認したものではありません。公開情報の検索はAction Fabricとは別経路を想定しています。

2027年のCodex連携は、修正から変更管理へ広がる可能性

今回のChatGPTプラグインと、2027年に予定されるAI Workflow FactoryへのCodex連携は別です。Codex連携は、現時点で提供済みの機能としては扱えません。

その上で、私は、この先にはさらに大きな可能性があると考えています。原因調査で得た情報から、Codex等で修正コードと試験の案を作り、人がレビュー・試験し、ServiceNowの変更申請・影響確認・承認・実施結果の記録へつなげる流れです。

図：2027年予定のCodex連携を踏まえた将来の設計例。発表が、この一連の標準機能や一般提供を約束しているという意味ではありません。

修正コードの作成から変更管理まで、一気通貫で対応できるポテンシャルがある。ただし、その実現には、人のレビュー・承認、既存の開発・配備基盤との接続、案件と証拠の対応付けが必要です。私は、まず原因調査と記録の往復を整え、その先に開発と変更管理を広げる順序が現実的だと考えます。

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

CMDBの構成・依存関係と、過去の対応記録を整えておくことは、調査の前提です。その上で、今回の連携を自社で運用するために見直したいのは、誰が調査を担当し、何を参照でき、どの情報を更新してよいかという権限と責任の設計です。

影響範囲の確認は幅広に、更新できる範囲は厳格に。私は、この方針を基本に置きたいと考えています。調査に必要な情報へ横断的にたどれることと、実際に記録や状態を変更できることは、分けて設計する必要があります。

① 調査担当と、情報を更新する責任者を明確にする

インシデントを受け付けた後、どのグループ・担当者が調査を進めるかを明確にします。さらに、関連するサービスや構成アイテム、問題・変更の各レコードについて、誰が情報の内容に責任を持ち、更新を判断するかを整理します。調査担当者が、関連情報すべての更新責任者である必要はありません。

調査の結果、別の担当領域に原因の可能性が見つかった場合も、誰へ確認・引き継ぎを依頼すればよいかが分かる状態にします。ChatGPTをUIにしても、対応責任や引き継ぎ先を曖昧にしないことが重要です。

② 影響範囲の確認に必要な参照権限を、横断的に見直す

担当する機器やアプリだけを見ていては、その先のサービスや利用部門への影響を把握できない場合があります。CMDBの依存関係、関連サービス、過去のインシデント、既存の問題、直近の変更履歴を、調査に必要な範囲で横断して参照できるかを確認します。

ここでいう「幅広に」は、全情報を無条件に開放することではありません。調査という目的に応じて必要な関連情報を見渡せるようにしつつ、機密性の高い情報や個人情報は、閲覧制限・マスキング等で扱いを分けます。外部AIへ送信してよい範囲も、社内で閲覧できる範囲とは別に確認します。

③ 更新権限は、担当・レコード・項目・操作で限定する

参照できる情報が増えても、そのすべてを変更できる必要はありません。担当するインシデントの調査経緯を追記する権限と、CMDBの構成・依存関係を書き換える権限、問題の原因を確定する権限、変更を承認する権限は分けます。誰が、どのレコードの、どの項目を、どの条件で更新できるかを定めます。

ChatGPTからインシデントへ自動反映する場合も同じです。調査メモや確認結果の追記と、担当変更・状態変更・解決やクローズを分け、自動更新してよい操作と、人の確認・承認を要する操作を決めます。AI経由の操作にも担当者の役割と権限の境界を適用し、共通の接続アカウントを使う場合も、その権限が実際の担当者の許可範囲を広げない設計を確認します。

④ 広く調べられ、越権して更新できないことを試す

一つのサービスやチームで、担当者ごとの参照・更新の組み合わせを検証します。関連サービスの情報を参照して影響を調べられるか。一方、担当外のレコードや保護された項目の更新は拒否されるか。更新できない場合に、権限のある責任者へ確認を依頼できるかを確かめます。

自動反映では、誰の操作として何を更新したかを追えることと、担当者が交代した後に権限が適切に切り替わることも確認します。将来のCodex連携で修正コード作成から変更管理へ広げる際も、この責任と権限の整理が土台になります。

調査に必要な視野は広げる。更新の責任と権限は曖昧にしない。私は、担当者を明確にし、参照と更新を分けて見直すことが、ChatGPTとServiceNowを実務で生かすための、最初の一歩だと考えています。