ChatGPTが基幹システムを『操作する』側に回った——OpenAI×ServiceNowが示す、エージェント統制の置き場所

「読む」アシスタントが、「操作する」実行者になった

homulaは、エンタープライズ企業のAIエージェント導入を、接続先システムの権限設計やガバナンス要件まで含めて一気通貫で設計するAIインテグレーターです。

2026年10月28日、OpenAIとServiceNowが提携の拡大を発表しました。要点を一言で言えば、ChatGPTが、企業の基幹システムの中でインシデントを調べ、変更のリスクを評価し、レコードを更新する「実行者」になったということです（OpenAI: OpenAI and ServiceNow expand partnership）。これまで多くの企業で、ChatGPTは「下書きを書く」「要約する」という“読み書きの相棒”でした。それが、承認フローや監査の対象になるべき基幹システムの操作に手を伸ばし始めた——ここが今回の本質です。

本稿は、この発表を「事実」と「homulaの分析・見解」を分けて整理し、日本企業がエージェントの接続と統制をどこに置くべきかという観点から読み解きます。

発表されたこと——「今あるもの」と「2027年に予定のもの」

今回の拡大は、両社が2026年1月20日に結んだ複数年契約（3年）の上に積み増すものです。1月の合意は、OpenAIのフロンティアモデルをServiceNow AIプラットフォームに統合し、enterprise顧客にとっての“推奨モデル”にする、というものでした（Business Wire: ServiceNow and OpenAI collaborate（2026-01-20））。10月28日の発表は、そこに「ChatGPTからServiceNowを操作する」導線を足したものと整理できます。

あわせて、OpenAIはServiceNowの Control Tower Alliance に創設メンバーとして参画し、両社とも社内業務にそれぞれの製品を全面展開する計画を示しました（OpenAI）。ServiceNowが「システム・オブ・アクションをあらゆるAIエージェントに開放する」という文脈は、同社のAction Fabric発表で示されたものです（ServiceNow: opens its full system of action to every AI Agent、Reworked: ServiceNow launches Action Fabric）。なお、この発表はServiceNowがGoogle Cloudとの提携拡大を公表した翌日でもあり、基幹プラットフォーム各社が「どのAIからでも叩ける入口」を競って整えている局面がうかがえます。

なぜ重要か——「どの従業員でも接続しうる」という配布モデル

技術的な接続自体は、特段新しい話ではありません。SalesforceやServiceNowは2026年春の時点で、プラットフォームをヘッドレス化してMCP経由で任意のエージェントに開く方向へ動いていました（この分岐の全体像は基幹システムへの「エージェント・アクセス」で割れる判断軸で詳述しています）。今回が一段違うのは、接続の主役がChatGPTという、最も広く使われている消費者級アシスタントであり、しかもそれが**OpenAIのマーケットプレイス（アプリストア型）**から配布される点です。

ここに、日本企業が見落としがちな論点が二つあります。

第一に、「読む」から「操作する」への質的な跳躍です。 インシデントの要約を受け取るのと、インシデントのステータスを更新し、変更を承認経路に乗せるのとでは、事故が起きたときの影響がまるで違います。後者は、本来なら誰が・いつ・どの権限で実行したかが監査に残るべき操作です。アシスタントが入口になった瞬間、その操作ログが“人”ではなく“ChatGPT”名義で積み上がる危うさが生まれます。

第二に、配布がマーケットプレイス型であることです。 アプリストアのように「つなぐだけ」で使えるということは、裏を返せば、情シスが把握しないまま、現場の従業員が自分のChatGPTを基幹システムに結びつけてしまう経路が増えるということです。これは、以前に取り上げた「シャドーMCP」——見えないエージェント接続が統制の外で増殖する問題——の、より身近で起こりやすい形だと見ています。便利さと野良化は、同じ導線の裏表です。

統制はモデルではなく「実行層」が握る

では、この操作をどう安全にするのか。今回の設計で注目すべきは、安全性をモデル（ChatGPT）側ではなく、プラットフォーム＝実行層の側で担保していることです。

ServiceNowのAction Fabricは、UIで動いていた業務プレイブックを「ヘッドレス」に開放し、外部のどのエージェントからでも叩けるようにする仕組みです。重要なのは、そのときUIと同じ権限とビジネスルールが、プラグイン経由の操作にもそのまま効くという点です。ServiceNow自身は、UIで動くパスワードリセットのプレイブックを、同じ権限のままClaudeからも実行できる、という例を挙げています（Reworked）。

この発想は、homulaが一貫して主張してきた**「制御点は、モデルの賢さではなく、接続と実行の層に置く」という考え方と一致します。モデルは乗り換え可能な部品です。今日はChatGPT、明日はClaudeやGeminiかもしれない。だからこそ、どのモデルが来ても効く中立の統制レイヤー**を、自社側に持っておくことが要になります。MCPは、その「中立の接続標準」として機能します。

日本企業がいま置き直すべき制御点

この発表を、単なる海外の提携ニュースで終わらせないために、実務の判断軸を4つに絞ります。

1. 接続の棚卸し：自社のSoR（ERP・CRM・ITSM）に対して、いまどのアシスタント・エージェントが接続可能になっているかを可視化する。「つなげる状態」が既に存在しているかを、まず知る。
2. 最小権限で開く：マーケットプレイスから「全機能」をつなぐのではなく、公開する操作を業務単位で絞る。読み取りと更新を分け、破壊的な操作には承認を挟む。
3. 配布経路の管理：従業員が各自でSoRに接続することを、放置も全面禁止もせず、承認付きの導線に乗せる。野良接続を減らす最善手は、正規の便利な道を用意することです。
4. 実行の監査：誰（どのアカウント・どのエージェントID）が、いつ、どの操作をしたかを、人の操作と同じ粒度で残す。アシスタント名義の操作が“誰の責任か”を曖昧にしないこと。

homulaの観点——「接続」と「統制」を同じ設計で握る

homulaは、この手の変化を**「接続の便利さ」と「統制の厳しさ」を分離させない**かたちで実装してきました。

• Agens（MCPを活用したエンタープライズ向け統合プラットフォーム）は、200以上のツールと構築ゼロで接続します。ServiceNowのようなSoRを含め、「どこに・どの経路でつなぐか」を設計の対象にできます。
• Agens Control は、承認フロー・DLP・5年分の監査ログ・RBACを提供します。今回のような「アシスタントがSoRを操作する」導線に対して、最小権限・承認ゲート・実行証跡という関所を、モデルに依存せず自社側で効かせられます。
• 入口としては、AIエージェント・ブートキャンプ（業務の棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結）が有効です。「どの業務を、どのSoRに、どの権限でつなぐか」を小さく検証してから広げる——最短5日のPoCから本番運用、内製化まで伴走します。

技術スタックとしても、homulaは n8n / Dify / LangGraph などを用い、特定ベンダーに縛られないかたちで統合・統制の層を組みます。ChatGPTが実行者に回る流れは止まりません。だからこそ、実行層の設計主導権を自社に残すことが、本番化の分かれ目になります。

まとめ

OpenAI×ServiceNowの今回の拡大は、「最も普及したアシスタントが、基幹システムの操作者になる」という転換を、はっきり可視化しました。ポイントは次の3つです。

• ChatGPTが読むだけでなく操作する側へ回り、マーケットプレイス経由で誰でも接続しうる配布モデルになった。
• 安全性は**モデルではなく実行層（Action Fabric＝既存の権限・業務ルール）**で担保される設計になっている。
• 日本企業は、接続の棚卸し・最小権限・配布経路の管理・実行の監査を、モデル非依存の中立レイヤーで自社に握るべき。

便利さを取りに行くほど、統制を同じ設計の中に組み込む重要性が増します。アシスタントがSoRの正面口に立つ時代の“関所”を、どこに・誰の手で置くか——その判断が、本番化の成否を分けます。

---

自社の基幹システムに、どのアシスタント・エージェントが接続しうるのか。その棚卸しと、承認・監査・最小権限の設計から、homulaが伴走します。

無料相談を予約する

Agens Controlで承認・監査・ガバナンス設計を見る

MCP活用支援の詳細を見る