「with AI」で働くための
インフラは、誰がつくるのか。

5月のProject Arcが、
10月に一般提供へ進んだ。

Arcは、今回初めて登場した構想ではありません。ServiceNowは2026年5月5日のKnowledge 2026で、企業向けの自律型デスクトップエージェント「Project Arc」を発表していました。OpenShellによる保護とAI Control Towerによる管理は、当初から示されていた方向です。^[5]

2026年10月21日の発表は、そのArcが一般提供へ進んだ節目と、統制連携の拡張を伝えるものです。社員が目標を渡し、AIが計画・実行・確認を続ける働き方を、企業が管理できる形で提供する方向が具体化しています。^[1]

ローカルAIは、
AIのコストをゼロにするのか。

公式発表は、RTX Spark上のローカルモデルで日常業務を処理し、より高度なタスクにはフロンティアモデルを使う方向を示しています。^[1]ローカルと高性能モデルを使い分ける、ハイブリッドな構成として読む必要があります。

外部クラウドの従量課金モデルを利用する場合、高度な処理には引き続きトークン等に応じた費用が発生します。ローカルへ移した処理では、その外部モデルへの呼び出しを減らせますが、端末側の計算資源や運用の費用は残ります。発表だけから、クラウド側のモデル構成・課金方式や削減率を確定することはできません。

利用料の一部が、設備・運用費へ移る

ローカル推論の能力を確保するには、対応する計算資源が必要です。自社で購入するなら、初期の設備投資、償却、保守、電力、更新費を考慮します。リースや共有サービスを選ぶ場合は、別の費用構造になります。

従業員ごとの端末に配置するのか、チームや組織で資源を共有するのかによっても、稼働率と管理負担は変わります。RTX Spark相当の専用機を一人一台置くことが必須と発表されているわけではありません。対応環境、同時実行数、応答時間、データの扱いを基に設計する論点です。

表はNumberによる評価観点です。製品の見積もりや特定の会計処理を示すものではありません。

Numberは、トークン単価に加え、品質を保って一つの仕事を完了するまでの総コストで比較すべきだと考えます。どの処理をローカルに寄せ、どの条件で高度なモデルへ渡すかが、その評価を左右します。

なぜNVIDIAと組むのか。
肝は、強制をServiceNowの外へ出すこと。

AIが複数のアプリや外部サービスを使うようになると、企業のルールをServiceNowの中で管理するだけでは、実行時のすべての操作を制御できるとは限りません。ルールを決める場所と、実際のアクセスを止める場所を結び付ける必要があります。

今回の構想を読むうえで、私たちが重視するのは次の役割分担です。

SICT：Super Intelligence Control Tower。図は両社の発表を踏まえた整理で、AI Passportを介した連携には将来提供の内容を含みます。[1][2]

NVIDIAは、OpenShellの実行ソフトウェアに加え、BlueField DPU上のSentryによる監視とポリシー強制を含む参照アーキテクチャを発表しています。^[2]OpenShellの技術資料でも、通信・ファイル・プロセスなど、実行環境で制限を適用する仕組みが説明されています。^[3][4]

例えば、「顧客情報を参照して回答案をつくることは許すが、外部への送信は承認が必要」という業務ルールがあります。このルールを実行時の制御に落とすなら、参照先、使える操作、承認後の許可を具体化し、その条件を守らせる地点が必要です。

ServiceNowが業務上の判断を扱い、NVIDIA側がAIの実行環境で強制する。管理画面でルールを定義することと、その外側で実際に守らせることを分担する。ここに、両社が組む意味があると考えます。

「with AI」のインフラ標準になる可能性

社員が日々の仕事をAIへ任せる働き方には、どのモデルを使うかに加え、誰の権限で動くか、何を許すか、問題があればどこで止めるかを共通に扱う土台が必要です。

Numberは、今回のArcとNVIDIAの連携が、「with AI」で働くためのインフラ設計のデファクトスタンダードになる可能性に注目しています。業務の判断と実行側の強制を分けて接続する設計は、多数のエージェントを運用する企業にとって、繰り返し必要になるからです。

ただし、すでに標準の地位が確立したという意味ではありません。NVIDIAの発表には他の企業ソフトウェアとの取り組みも含まれます。^[2]Arcが広く使われること、外部エージェントにも統制が届くこと、異なる基盤との相互運用、費用に見合う運用実績が、その可能性を見極める条件になります。

また、操作の許可は、成果の正確さを保証しません。アクセス停止によって既に送信・変更した内容が元に戻るわけでもありません。実行制御と、業務品質や是正対応は、それぞれ運用として整える必要があります。

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

1. AIへ任せる仕事と、使うモデルを分ける

対象業務を操作に分け、ローカルで扱う情報と処理、外部モデルに渡せる情報、高度なモデルへ切り替える条件を整理します。判断の難しさだけでなく、機密性、応答時間、再実行の頻度も含めて確認します。

2. 業務ルールを、実行時に判定できる条件へ翻訳する

参照・作成・変更・送信・確定の権限を分け、対象、上限、有効期間、承認者を明確にします。その条件をどのシステムや実行環境で強制するかを対応付けます。現在利用可能な構成と、将来のAI Passport連携で目指す構成は区別します。

3. 配置と費用を、実際の仕事で比較する

端末側や共有環境に必要な計算資源、クラウド利用量、保守と統制の工数を見積もります。利用者数だけでなく、同時に動くエージェント数と稼働率を確認し、機器購入・リース等の選択肢も含めて、一件の仕事を完了するまでの費用を評価します。

4. 拒否・停止・再開と、業務品質を確かめる

許可外の操作が止まるか、承認を要する操作で待てるか、権限の変更が反映されるかを試します。止まった仕事の引き継ぎ、既に行った操作の確認、再開の責任者も決めます。設定変更によって再作成等が必要な範囲は、導入対象の仕様に即して確認します。

「with AI」を日常の働き方にするには、実行能力、計算資源、統制、運用を一緒に設計する必要があります。Numberは、この全体を業務へ接続することが、今回の発表から考えるべき実務上の論点だと捉えています。