HigLabo
Latest posts
ServiceNow Action Fabricはなぜ「MCP接続管理」だけでは足りないのか──Anthropic連携で見える実行権限の再設計
ServiceNowとAnthropicの関連発表が示した論点
ServiceNowとAnthropicに関する関連発表や報道をめぐるAIニュースは、単なる新機能の追加として見るだけでは不十分です。とくにServiceNow Action FabricやAnthropic連携を検討する立場では、MCP接続先の把握だけでなく、外部AIとつながった先で誰の権限で業務が実行され、問題発生時に誰が責任を負うのかをどこまで再設計すべきかが論点になります。
今回の論点は、「AIを業務システムにつなげる」段階から、「AIがどこまで業務を実行してよいか」を決める段階へ進みつつあることです。問い合わせ要約や回答案生成に加え、一般論としてはチケット更新、承認依頼、タスク起票といった操作も想定されるからこそ、接続管理だけでは足りなくなります。
Action Fabricは「つなぐ」だけでなく「業務を動かす」前提で見る必要がある
Action Fabricを理解するうえで重要なのは、「つなぐ仕組み」と「動かす仕組み」を分けて考えることです。Anthropicが提唱するModel Context Protocol（MCP）のようなツール接続の標準化は、どのツールやデータソースにAIがアクセスできるかを整理する発想に近い一方で、Action Fabricは、接続先のシステムで業務アクションを扱うための連携や実行の仕組みを含む文脈で位置づけられます。
社内システムに接続できるだけなら、それは入口の整備にすぎません。実際の現場では、誰の権限でレコードを更新するのか、承認が必要な処理はどこで止めるのか、操作履歴をどう残すのかまで決める必要があります。
要するに、Action Fabricはコネクタ管理だけで完結する話ではありません。AIエージェントが業務フローの一部に入るなら、連携は機能要件ではなく、運用設計そのものの問題になります。
MCPのような接続管理だけでは業務運用の安全性は担保できない
MCPのような接続管理やツール接続の標準化が重要なのは間違いありません。どのAIがどのシステムに触れられるかを可視化し、接続先を統制することは、出発点として必要です。
ただし、それだけでは「つながっているが、どう使うかは未整理」という状態にとどまります。企業で本当に問題になるのは、その先で何を実行できるのか、誰の権限で実行されるのか、問題が起きたとき誰が責任を負うのかが曖昧なまま残ることです。
たとえばAIが人事システムの情報を参照できるとしても、閲覧だけなのか、更新までできるのかでリスクは大きく変わります。さらに、更新後に誤りが見つかった場合、AI提供企業、接続基盤、利用部門、承認者のどこが責任主体なのかが曖昧だと、現場は自動化を止めがちです。
この点は、モデルの性能向上だけでは解決しません。安全なモデルであっても、業務権限の境界設計は多くの場合で利用企業側にも必要になり、最終的な運用責任は契約や統制設計に依存します。
Anthropic連携で前面に出る「実行権限」の設計
Anthropicのような高性能モデルと業務基盤が結びつくと、AIは「答えるだけ」の存在ではなくなりうります。ただし、自然言語で依頼を受け、内容を理解し、適切なツールを選び、実際の操作候補を返す流れは、モデル自体の能力だけでなく、ServiceNow側のオーケストレーションやエージェント機能を含む構成として捉える必要があります。
ここで問われるのが、AIにどこまで実行を許すのかという権限設計です。AIが提案までに留まるなら人が最終確認できますが、自動実行まで進むなら、権限の出し方は一段厳密であるべきです。
たとえば「この重大インシデントを担当部署へエスカレーションして」という指示は、一見すると単純です。しかし実際には、優先度判定、通知先の選定、既存ルールとの整合、緊急連絡の必要性など、多くの判断が含まれます。
NIST AI RMFは、こうした場面でのガバナンス、役割定義、リスク管理を考える参考になります。権限設計では、社員アカウントの延長だけでは足りません。AI専用の実行主体を設けるのか、ユーザー代理として限定実行するのか、危険操作は必ず人の承認を挟むのかを分けて考える必要があります。
責任の所在は運用設計の中に埋め込まれる
責任の問題は抽象論ではありません。たとえばカスタマーサポートで、AIが問い合わせ内容を読んで返金対象と判断し、そのまま処理を進めたとします。もし判断ミスで本来不要な返金が行われた場合、「AIが間違えた」で終わらせることはできません。
現場では、責任はもっと細かく分かれます。返金条件を定義した業務部門、実行権限を与えたシステム管理者、監査ログを設計した情報システム部門、最終承認を省略した運用ルールなど、複数の設計要素が関わります。
AIは引き金になっても、責任は運用設計に埋め込まれています。だからこそ、導入時点で責任分界を明確にしておかなければ、現場は安心して自動化を進められません。
別の例として、IT運用でAIが障害チケットを自動クローズしたケースも考えられます。軽微な定型作業なら効率化になりますが、根本原因の確認前にクローズすると、再発時の追跡が難しくなります。
監査や内部統制を重視する企業ほど、実行責任の所在を事前に定義しておく必要があります。
企業が見直すべき設計は接続・権限・責任・監査の4点
企業が今見直すべきなのは、接続管理、権限管理、責任分界、監査設計を別々ではなく一体で考えることです。AIニュースでは新しい連携機能に目が向きがちですが、実運用ではこの4つがそろって初めて安全に回ります。
実務では、少なくとも次の論点を整理しておきたいところです。とくにITSM責任者、AIガバナンス担当者、エンタープライズアーキテクト、情報システム部門長は、AIエージェントごとに閲覧・更新・承認実行の3段階で、権限と責任分界を整理した運用表を作成すると判断しやすくなります。
- AIが参照できる情報と更新できる情報を分ける
- 自動実行してよい処理と、人の承認が必要な処理を分ける
- AI専用アカウントや代理実行の権限範囲を最小化する
- AIエージェントごとに閲覧・更新・承認実行の3段階で権限と責任分界を整理する
- 失敗時に追跡できる操作ログと判断ログを残す
- 例外時に人へ切り戻すフローを先に決めておく
OWASPのLarge Language Model Applications向けTop 10は、こうした設計を直接定めるものではありませんが、LLMアプリケーションの一般的なリスク観点を整理する参考になります。この設計があると、Anthropicのような高性能AIを活用しても、現場の不安はかなり減ります。逆に言えば、MCPのような接続管理だけを整えても、実行権限と業務責任が空白なら、大規模導入は進みにくいでしょう。
本当に問われているのはAI時代の責任設計である
今回のAIニュースが示したのは、企業の関心が「AIをつなげる方法」から「AIに何を任せるか」へ移っていることです。ServiceNow Action Fabricを評価する際も、コネクタ数や連携のしやすさだけでなく、実行権限、承認、監査、責任分界まで含めて見る必要があります。
とくにAnthropic関連発表のようにAIが業務文脈を深く扱える構成が注目されるほど、便利さと統制は切り離せません。接続管理は土台ですが、それだけでは足りません。
落ち着いて見ると、このニュースの本当の価値は、新しい接続そのものではなく、企業がAI時代の責任設計に本気で向き合うきっかけを与えた点にあります。ServiceNow Action FabricやAnthropic連携を検討するなら、MCP接続先の把握に加えて、AIエージェントごとの閲覧・更新・承認実行の3段階で運用表を整え、実行権限と業務責任をどこまで再設計するかを先に決めることが次の行動になります。