AIを広げるために、統制をつなぐ。
Control Tower AllianceでServiceNowが目指すもの。

AIを安全に広げるための、
11社から始まる連合。

ServiceNowは2026年10月28日、Control Tower Allianceを発表しました。AI、クラウド基盤、セキュリティ、ガバナンス、価値の測定、トークンの利用量計測などを担う企業と、企業のAI導入・拡大を支援する取り組みです。^[1]

創設メンバーは、Anthropic、Amazon Web Services（AWS）、Cisco、HiddenLayer、Kong、NVIDIA、Okta、OpenAI、Stripe、WitnessAI、Zenityの11社です。特定のAIモデルだけに寄せるのではなく、AIを仕事に使う際に必要な複数の技術領域を束ねた構成になっています。

中心に置くのは、ServiceNow Super Intelligence Control Towerです。企業で使われるAIを見つけ、守り、統制し、動作を観測し、効果を測るための共通の管理層として説明されています。Allianceは、その役割をパートナーの技術と組み合わせて広げる位置付けです。

共同開発・事前統合・共同販売の3つで進める

表：公式発表の3方式を整理。すべての創設メンバーが同じ販売・サポート条件になるという意味ではありません。[1]

発表では、掲載前に審査・認定・統合テストを経たソリューションを提供する仕組みが説明されています。既存のServiceNow StoreやWorkflow Data Network Partner Passportと並存する取り組みであり、それらを一律に置き換えるものではありません。

AIコントロールタワーの覇権へ。
機能だけでなく、連合をつくる。

統制やコスト管理のツールは、以前からあった

AIを統制し、コストを管理する道具が、今回初めて登場したわけではありません。これまでも、技術のレイヤーごとに専門の製品や実践がありました。まず、その背景を押さえておきます。

表：理解のための役割別整理。製品カテゴリーの境界は重なっており、各製品が記載した機能だけを持つという意味ではありません。

Kongはモデル呼び出しの費用計算、Langfuseはトークンと費用の追跡を提供しています。HiddenLayerはエージェントの実行時保護へ、IBMもエージェントのライフサイクル管理へ取り組んでいます。^[2][3][4][5]「従来製品はチャットの入出力しか扱えない」と、一括りにすることもできません。

一方で、開発、セキュリティ、法務・リスク、財務では、使う記録も評価の単位も違います。製品を揃えていても、同じエージェントについて、業務責任者・権限・費用・検出された問題・是正状況を一続きに確認できるとは限りません。「なかった」のではなく、役割ごとに発達した仕組みを、全社の仕事としてつなぐ課題が残っている。私は、そのように捉えています。

モデルの管理から、行動するエージェントの管理へ

文章を生成するだけでなく、エージェントが複数のツールを呼び、データを更新し、処理を繰り返すようになると、管理する対象も広がります。「誰の権限で何を実行したか」「想定外の動作をどこで止めるか」「一つの仕事が完了するまでにいくら使ったか」を、つなげて把握する必要があります。

MicrosoftもEntra ID Governanceでエージェントの識別情報を統制する仕組みを説明しており、ServiceNowだけがこの課題に向き合っているわけではありません。^[7]比較すべきなのは「管制塔」という呼び名より、自社のAIと既存システムをどこまで管理でき、問題を誰の行動につなげられるかだと考えます。

覇権候補としてのServiceNowは、連合づくりから動く

私は、ServiceNowをAIコントロールタワーの覇権候補の一つとして見ています。今回の発表で注目したいのは、新機能の数以上に、既存の専門技術を持つ企業を、自らをハブにする連合へ集めたことです。ゲートウェイ、ID、セキュリティ、実行時制御、利用量・課金を、それぞれの得意な企業とつなごうとしています。

その組織づくりは、名前を並べるだけではありません。共同開発、審査・認定、エージェントの識別や安全策の共通基準、販売・サポートの経路までを整える。技術を使える形にするために、企業間の役割と協業の仕組みを先に組み立てる動きとして読めます。

ServiceNowがハブになる意義は、資産やサービスの情報と、担当者・承認・タスク・是正の履歴を業務として結び付けられる点にあると考えます。AIの問題を見つけてダッシュボードへ出すだけでなく、誰が判断し、誰が対応し、何をもって完了とするかへ落とし込む。その接続を、既存の業務基盤とパートナー網で広げる構想です。

私は、今回の連合を、単に参加企業が増えたニュースとしては見ていません。企業のAIは、モデルだけで動くわけではありません。APIやツールを呼び、認証を受け、データに触れ、クラウドの計算資源を使います。それぞれの境界で、何を許すかを実際に守らせる必要があります。

会社としての判断を、技術の実行地点まで届ける。その結果を、業務と責任の記録へ戻す。Control Tower Allianceの意義は、この往復を複数の企業と作ろうとしていることにあると考えます。

参加企業のコメントから見える、異なる制御の役割

表：公式発表中の各社コメントを整理。独立した性能検証や、すべての機能の一般提供を確認したものではありません。[1]

例えば、Oktaの説明にある「新たなトークン要求の遮断」は、すでに実行中の処理や発行済みの認証情報が、あらゆる接続先で即時無効になることまで意味するものではありません。何が止まり、何が残るのかを確認することが、運用では重要になります。

セキュリティに加えて、利用量と価値も見る

今回の発表では、価値の測定やトークンの利用量計測も連合の対象に含まれています。私は、ここにも注目しています。AIを全社へ広げる際、実行権限だけでなく、どの業務にどれだけ費用を使い、何が改善したかを説明できることが必要だからです。

費用が安いAIを選べばよい、という話ではありません。再処理や人の確認が増えれば、モデルの単価が低くても業務全体のコストは上がります。処理件数、完了率、手戻り、所要時間、人の確認時間と利用料を、同じ業務単位で見られることが重要だと考えます。

AIエージェントの統制とコスト管理を、
経営のセキュリティ議題へ。

私は、サイバーセキュリティが経営課題の一丁目一番地となった今、AIエージェントの統制とコスト管理を、サイバーセキュリティの主要アジェンダとして経営が扱う必要があると考えています。開発チームの技術選定や、現場の便利なツールの管理だけで完結する話ではありません。

業務データにアクセスし、外部へ送信し、システムを更新するAIエージェントには、情報漏えい、不正操作、業務停止につながるリスクがあります。同時に、想定外の繰り返し処理や不正利用は、APIや計算資源の費用を増大させる可能性があります。権限・行動・支出を別々に見るだけでは、同じ異常の全体像を捉えにくくなります。

もちろん、すべてのコスト最適化がセキュリティ業務になるわけではありません。予算や投資効果は財務・事業部門の責任も伴います。その上で、異常な利用、費用の急増、権限の逸脱を共通の対象として扱い、経営の判断へつなぐことが重要だと考えます。

導入の承認だけでなく、止める判断にも経営が関与する

利用部門は成果、IT部門は接続と安定性、セキュリティ部門は脅威とアクセス、財務部門は費用を見る。それぞれの専門性を残しながら、共通の判断基準を持たせることが経営の役割です。CIO・CISO・CFOと業務責任者が、どのリスクを許容し、どの条件で停止し、誰が再開を承認するかを決めます。

例えば、顧客情報へアクセスする営業AIで、深夜の大量呼び出しと費用の急増を検知した場合。単なる予算超過として扱うのか、認証情報の悪用やループの可能性として調査するのか。接続を止めた時に営業をどう継続するのか。部門間の判断が必要になるため、事前の権限委譲と報告ルールが欠かせません。

経営が見るのは、ツールの数より運用の実態

経営会議では、台帳の登録数だけでなく、責任者の分からないエージェントが残っていないか、重要業務で停止・復旧の試験を行えているか、予算の急増や重大な逸脱に対応できているかを見るべきだと考えます。完了率や生産性と合わせて、リスクと費用を同じ業務単位で確認します。

ServiceNowが企業間の連合を組むように、利用企業も社内の責任と意思決定を組み立てる。外側のエコシステムと、内側の経営・業務・IT・セキュリティ・財務の体制。その両方が揃って初めて、AIの管制塔は自社で機能するものになると考えます。

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

経営スポンサーと、部門横断の責任体制を決める

まず、AIエージェントの統制とコスト管理を誰が経営へ報告するかを明確にします。業務、IT、セキュリティ、財務、必要に応じて法務・リスクの責任者を揃え、導入・例外承認・緊急停止・復旧・予算の判断権限を決めます。既存のサイバーセキュリティ会議体に、この議題を組み込むことも現実的な出発点です。

最初からすべてのAIを一元管理しようとするより、まず一つの業務を選び、誰が何を許可し、どこまで記録するかを揃えるところから始めたいと考えます。技術の連合が整っても、自社の業務責任と運用ルールを代わりに決めてくれるわけではありません。

① AI・業務・責任者を対応付ける

使っているAIとエージェント、用途、利用部門、責任者、参照データ、接続先、契約と費用負担を整理します。部署で別々に持っている台帳も、共通の識別子と項目で対応付けます。登録した時点で終わらせず、追加・変更・廃止の際に更新する担当と手順を決めます。

② 実行権限と、停止・復旧のルールを決める

参照、提案、更新、外部送信など、操作ごとに許可範囲を定めます。人の承認が必要な場面、異常を判断する基準、遮断する対象、代替手順、再開条件を決め、実際に試します。停止後に既存のトークンや進行中の処理がどう扱われるかも、接続先ごとに確かめます。

③ 業務成果と費用を、同じ単位で測る

一件の問い合わせ、一件の見積もりなど、対象業務の単位を決めます。AIの利用回数だけでなく、完了までの時間、手戻り、人の確認時間、品質、利用料を導入前後で見ます。判断基準を揃えてから、どの範囲へ広げるかを決める方が、改善につながりやすいと考えます。

地道な整備を、AIで速く進める

過去の申請、構成情報、契約、対応記録から、台帳や権限表の候補をAIに整理させることは考えられます。部門ごとに異なる用語を対応付け、ルールの抜けや例外を探す下書きにも使えます。ただし、候補を業務責任者が確認し、採用した内容と理由を残します。

AIを安全に使うための管理を増やすだけでなく、安全に使える業務を増やしていく。私は、経営の関与のもとで責任体制、共通の記録、日々の運用を整えることが、今回のControl Tower Allianceを自社の価値へつなげる出発点だと考えています。