AIが隣で働く。だから、止められる仕組みも。
ServiceNow Brasilリリースを、統制と本番運用から読み解く。

Brasilは、
AIに仕事を任せる土台を整えるリリース。

ServiceNowのBrasilリリース（公式表記：Brazil）を、私は「エージェントAIの統制と本番運用」へ踏み込むリリースと捉えています。「AIエージェントのガバナンス元年」と呼びたくなるほど、仕事を進める機能と、それを管理する機能の両方が目立ちます。

もちろん、ガバナンスが今回初めて登場したわけではありません。ZurichやAustraliaで進んできたAI活用を受け継ぎ、日々の仕事へ広げるための管理を厚くした。その流れとして見ると、機能のつながりが分かりやすくなります。

AI Agent Studioの再設計、AI Specialistから成るAutonomous Workforce、アプリを作るBuild AgentとAutonomous Engineer、外部の処理を呼び出すMCP連携。いずれも、AIが一つの回答を返すだけでなく、仕事を進めるための仕組みです。Autonomous Workforceでは、対応に自信が持てない依頼を人へ引き継ぐ設計も説明されています。^{[3][4] [25]}

その裏側には、AI Control Towerの停止・ポリシー・費用管理、AI Risk and Compliance、アクセス制御や認証の強化があります。任せる仕事が増えるほど、誰が責任を持ち、どこで止められるかも具体的にする。私は、この組み合わせが今回の中心だと考えています。^{[2][15][16][17]}

公式動画も、「作る」から「使う」までをつないでいた

約51分の公式配信では、障害後の振り返りアプリをAutonomous Engineerで作る計画を示し、Arcで脆弱性と社内情報を調べ、MCP経由で振り返りの処理を呼び出す流れが紹介されました。後半は新しい画面の枠組みLuxと、アップグレードの準備です。^[1]

新機能を個別に紹介するだけでなく、「会社で決めた仕事を、使い慣れた場所からAIへ頼む」という場面になっていました。障害の振り返りは、今回のリリース全体を理解する一つの例です。

管理者が見るべきは、
「動かせるか」と「止められるか」。

① AI Control Tower：止める役割を、運用に組み込む

AI Security Operatorという専用ロールで、AI Stewardの広い権限を持たずにエージェントを停止できるようになります。Azure AI Foundryとの接続では、同基盤上のエージェントにもポリシーとキルスイッチを及ぼします。部門単位の明示的ブロック、サービス別の単価設定、設計時のセキュリティ態勢の指標も追加されています。^[2]

ArcもControl TowerとNVIDIA OpenShellによる統制の下で動く位置付けです。^[7] ただし、どんな外部AIでも無条件に即停止できるわけではありません。接続先、停止の仕組み、必要な権限を確かめて初めて、「誰が止めるか」を運用手順に書けます。

AI Risk and Complianceでは、未管理のAI資産のリスク分類や、導入から保守・廃止までの管理手順を更新しています。費用を見る人、リスクを判断する人、停止する人の役割をそろえておくことが大切です。^[17]

② AI Agent Studio：最初から何でも許さない

Studioは作成・配備・評価の流れを再設計しました。同時に、MCPサーバーをエージェントの道具へ加える前に、アクセスルールと使ってよいツールを定義する仕組みを整えています。MCPは、AIが外部の情報や処理を利用するための接続方式です。つなぐ先が増えるほど、接続後に何をさせるかまで決める必要があります。^[3]

新規・初期化した環境では、エージェント、ワークフロー、スキル等のAI向けアクセス制御が、原則拒否のdeny-by-defaultへ変わります。対象はgen_ai_agent、gen_ai_workflow、gen_ai_skill、flow、flow_action。ただし、後二つはAIから呼び出す場合の制御です。既存環境をそのまま更新しても、この初期設定へ一律に切り替わるわけではありません。^[3][18]

Application Runtime Policyは、開発中のカスタムアプリが実行時に使う資源を、生成したポリシーで確認・制御するものです。認証ではAzure・Google CloudへのWorkload Identity Federationが加わり、Patch 1には機密性の高い依頼を扱うAI音声エージェントへの追加認証も記載されています。対象を分けて確認したい強化です。^[15][16]

③ Build Agent / Autonomous Engineer：仕様からテストまで

Autonomous Engineerは、要件を読み、不明点を聞き、受入条件を含む作業計画を作ります。人が承認すると実装とATF（自動テスト）の生成・実行を進め、人の判断が必要な箇所を返します。テストスイートの作成・実行、Box MCP連携、規制市場向けProtected Platform対応も記載されています。^[4]

受託開発でも、作成の速さに加えて、要件を明確にする力とレビューの仕方が効いてきます。自動テストが通ることと、業務に必要な品質を満たすことは同じではありません。なお、Trialの既定導入やBuild Agentの自動更新と、Autonomous Engineerの利用権は別です。後者は先行提供の案内、AI Workflow Factoryの契約、別アプリの有効化を確認します。^[4][19]

④ Developer Sandboxes：並行して作る場所も整える

10月更新では、非本番インスタンスごとに無償のSandboxライセンス4枠が案内されています。AEMCでのライセンス割当と、必要なプラグイン設定が前提です。REST APIでは環境の作成・削除・状態確認を扱えます。^[5][23]

人やAIが並行して変更を作るなら、作業場所も分けたいところです。個別に試し、共有環境へ戻すときに確かめる。CI/CDや並行開発を考えるうえで、地味ですが大切な変更です。

利用者には、
「AIが隣で働く」体験へ。

Arc：ポータルの外へ出てくるServiceNow

Arcは、個人の仕事を継続して引き受けるデスクトップのAIエージェントです。公式動画では、ServiceNowのCMDBとMicrosoft 365の予定をまたぎながら、調査やレビューの準備を進めていました。Webポータルを開いて一件ずつ操作する使い方から、自分の手元で仕事を頼む体験へ広がります。^[1][7]

10月21日の一般提供発表ではEmployeeWorksの一部とされ、Macは対応済み、Windowsは数週間以内の予定でした。動画での両OSへの言及と、自社で実際に利用できる状態は分けて確認します。隔離された実行環境と企業側のポリシーが組み合わされる点も、個人向けAIとの違いです。^[7]

Otto：話の続きから、仕事を進めやすくする

Ottoパネルのpremium chatでは、一つの会話で複数の操作ビューを切り替え、生成したファイルをプレビューし、選んだ文章へ追質問できます。ワークスペースで別のレコードへ移っても、会話の文脈を維持する改善もあります。^[8]

Virtual Agent側には、プロフィールの既定言語に合わせた非英語の音声文字起こしと、有人担当者への接続待ちを取り消すボタンが加わります。日本語での利用は、対応言語・プロバイダー・設定を自社環境で確認します。premium chatが既定かつ唯一の選択肢になるのは対象となる新規顧客で、Now LLM providerを使う場合には例外があります。既存顧客全員の画面が一斉に置き換わる、という話ではありません。^[9]

EmployeeWorks：探すだけでなく、申請や承認まで

EmployeeWorks Web Appは、タスクや申請を期間・種別・期日等で絞り、会話でもフィルターを操作できます。トピック階層のパンくず、承認・チェックリスト・電子署名等のタスク画面へのAIチャット支援も進みます。^[10][11]

「先週の申請を探したい」「この承認の内容を確認したい」といった仕事を、会話と画面を使い分けて進める方向です。ただし、Employee Centerの即時廃止や、一律の置き換えが発表されたという意味ではありません。Luxも共通した画面体験を支える枠組みとして見ると、つながりが分かります。既存Workspace・Service Portalについては、公式解説で廃止計画はないと説明されています。^[24]

普段の対応業務にも、小さな改善がある

• 人事ケース：ワークノートやコメントの下書き・推敲をAIが支援します。^[11]
• 返答待ちのインシデント：指定回数の通知後も返答がなければ自動解決する仕組みがあります。資料では新規初期構築のzboot環境への適用とされ、解決後の自動クローズとは別です。^[12]
• 担当者への割当通知：ワークスペースの外で作業していても、新しい作業項目を受信箱で把握できます。^[13]
• Tech Lounge：Ottoへ自然な言葉で頼み、予約やウォークアップの受付体験へ進めます。^[14]

ITSMでは、変更を止める・まとめて進める機能も

Change lockdownは、重大障害や決算期等に、進行中の変更要求の全部または一部を保留にする仕組みです。ロックダウン期間と重なる変更を競合として検知し、期間外へ再設定すると処理を再開できます。Scaled changeは、多数の構成アイテム（CI）に対する変更を子レコードへ展開し、日程・競合・承認を調整します。^[6]

AI導入とは別に、ITSMの運用改善として検討できる機能です。たとえば決算処理を守る変更凍結なら、対象サービスと例外の扱い、保留した変更を誰が再調整するかまで決めておくと使いやすくなります。

Brasilの機能を有効活用するために

管理者には「AIを止められる」、利用者には「AIが隣で働く」。私は、この二つをセットで考えるのが、Brasilを生かす出発点だと思います。

新機能を使うために

① 一つの仕事と、その責任者を選ぶ

障害の振り返り、人事ケースの下書き、申請の確認など、身近な仕事から始めます。使ってよい情報、AIが実行してよい操作、完了条件、人へ返す条件をそろえる。記録が残らない、確認者が決まらない状態なら、まずそこを整えます。

② 許可するだけでなく、止める訓練をする

対象AIの停止権限を誰が持つか、連携先でも止まるか、再開は誰が判断するかを確認します。費用、誤った出力、権限外の操作の兆候も見ます。機能があることと、有効化されて運用できることは別です。

アップグレードの準備

③ 本番環境と非本番環境を近づける（フルクローンしておく）

アップグレードを試す前に、本番環境から非本番環境へフルクローンし、設定やカスタマイズ、検証に必要なデータをできるだけそろえます。インスタンスの容量が許す範囲で監査ログや添付ファイルも含め、本番に近い状態で更新にかかる時間と業務への影響を確かめましょう。^[1]

クローン後は、通知や外部連携が意図せず動かないよう、非本番用の設定も確認します。同じBrasilでも、新規環境と既存から更新した環境ではAI向けACLの初期状態が違うため、本番に近い権限と接続条件で検証することが大切です。ファミリー、パッチ、Storeアプリの版も記録しておきます。

④ 廃止／非推奨化される機能を知る

これらを一括して「全部削除された」と理解すると、移行判断を誤ります。既存のチャットや開発手順、モデル設定を棚卸しし、影響があるものから移行を考える。新機能の導入だけでなく、今ある業務を守る準備も進めたいところです。

AIへ任せる範囲と、会社が責任を持つ範囲を一緒に広げる。その準備を支えるリリースとして見ると、Brasilで何を先に試すかが選びやすくなるのではないでしょうか。

Brasilのリリースノートはこちら ↗