HigLabo
Latest posts
AIニュース解説：ServiceNow AI Control Tower拡張で何が起きた？MCP台帳だけでは足りない理由
ServiceNowのAI Control Tower拡張が示した、次のボトルネック
ServiceNowのAI Control Tower拡張は、AI活用の状況を可視化し、ガバナンスを強める管理・統制基盤として注目されています。特に今後、SAPやWorkdayのような業務システムとの連携が広がるなら、「どのAIがどのシステムにつながっているか」を把握する管理台帳の整備は重要になります。本稿ではそれを便宜上「MCP台帳」と呼びます。
ただし、今回のAIニュースで本当に重要なのは、MCP接続先管理を整えただけでは運用が回らないという点です。業務アプリ連携の後に必要になるのは、「誰が・どの業務で・どこまで実行してよいか」を定める実行権限設計です。何が起きたのか、なぜ総務部門が先に詰まりやすいのか、そして実務で必要になる権限設計の考え方を整理します。
AI導入で止まりやすいのは「接続後の実行範囲」
結論から言うと、ServiceNowのAI Control Tower拡張は、AIを安全に業務へ入れるための管理面を前進させる動きです。ですが、SAPやWorkdayのような基幹・人事系システムと連携した瞬間、課題は接続そのものより「実行してよい範囲」へ移ります。
たとえば、AIが総務の問い合わせに答えるだけなら比較的管理しやすいでしょう。しかし、異動申請の下書き作成、従業員情報の取得、申請の代理起票まで任せると、閲覧と実行の境界が急に複雑になります。
この論点は単なるAIニュースではなく、生成AIの実装段階で起きる統制の問題です。ServiceNowを導入済みで、総務・人事・ITSM領域へAIエージェントを広げたい情報システム部門長、ITSM責任者、AIガバナンス担当者ほど、接続完了がむしろ設計のスタートになります。
AI Control Tower拡張が示す「業務実行の入口」の論点
AI Control Towerは、AI活用の状況を可視化・監視し、統制しやすくする仕組みとして捉えると分かりやすいです。ここでいうMCP台帳は、本稿で便宜上、AIが利用する接続先やツールの一覧を把握する管理帳簿のようなものを指しています。
MCPはModel Context Protocolの略で、AIが外部ツールやデータとやり取りするための共通的な接続の枠組みです。たとえるなら、AI向けの「USB規格」に近い発想です。どこにつながるかは整理しやすくなりますが、「つないだ後に何をしてよいか」までは自動で決まりません。
SAPのような基幹業務、Workdayのような人事業務との連携が広がると、AIの守備範囲は一気に実務へ近づきます。つまり、今回の拡張そのものが業務実行機能を直接広げるとまでは言い切れませんが、今後こうした連携が進むほど、AIが参照だけでなく業務実行にどう関与するかが運用上の論点になります。
MCP台帳だけでは運用できない理由
MCP台帳が得意なのは、「何とつながっているか」の管理です。これは非常に大切です。
ただ、現場運用で本当に問題になるのは、「誰の指示で、どの条件なら、どこまで実行してよいか」です。
たとえば総務部門で、AIに「新入社員の入社手続きを進めて」と依頼した場面を考えます。そうした台帳を整備すれば、Workdayの従業員情報、SAPの費用処理、ServiceNowの申請フローといった接続先を把握しやすくなります。
しかし、それだけでは、AIが社員番号を見てよいのか、扶養情報に触れてよいのか、備品申請を代理送信してよいのかは決められません。
ここで必要なのは、接続台帳だけでなく権限台帳を含む権限モデルです。「参照は可、更新は不可」「本人申請のみ可、代理申請は部長承認後のみ可」のように、業務単位で実行条件を切る必要があります。
総務部門が先に詰まりやすい3つの場面
総務部門が先に詰まりやすい場面は、大きく3つあります。
- 人事情報の参照。総務は従業員の所属、勤務地、雇用区分、連絡先など、複数システムに散った情報を扱います。AIに横断検索を許すと便利ですが、閲覧範囲を広く取りすぎると、不要な個人情報まで見えてしまいます。
- 申請の代理実行。「出張申請を代わりに起票して」「入社準備タスクをまとめて流して」といった依頼は自然です。ただ、起票と承認は別権限です。AIが代理で作業した場合でも、誰の権限で動いたのかを監査できなければ運用は止まります。
- 横断処理。異動時には、人事マスター更新、座席変更、PC手配、権限付与が連動します。このとき一部は総務、別の一部は情報システム、さらに一部は各部門長の承認対象です。AIが一気通貫で実行するほど、権限の境界があいまいになりやすくなります。
SAP・Workday連携で難しくなる実行権限設計
実行権限設計が難しい理由は、システムごとに権限の粒度と考え方が違うからです。簡略化すると、ServiceNowではワークフローやロール、SAPでは業務機能にひもづく権限、Workdayでは人事データや業務プロセスに関わるアクセス制御といった考え方が重要になります。
これらをAIエージェント1つの動作に束ねると、最小権限の設計は一気に難しくなります。
ここで区別すべきなのは、少なくとも4種類あります。
- 閲覧権限
- 更新権限
- 承認権限
- 代理・委任権限
人が業務をするときは暗黙に区別できても、AIに任せる場合はルールとして明文化しないと危険です。
たとえば「住所変更を手伝うAI」でも、制度説明を返すだけなのか、変更画面を開くのか、申請を下書きするのか、提出まで行うのかで必要権限は別です。AI導入で失敗しやすいのは、この差を「同じ支援業務」として一括りにしてしまうことです。
先に作るべきなのは、業務ごとの許可ルールと権限台帳
実務上の結論は明確です。MCP台帳は必要ですが、それより先に「業務単位の許可ルール」を作るべきです。つまり、システム単位ではなく、入社手続き、異動、住所変更、備品申請といった業務単位で、AIに許す行為を定義します。
検討段階では、連携対象ごとに閲覧・更新・承認実行の3段階で権限台帳を作成すると進めやすくなります。
最初の設計では、少なくとも次の4つを決めると進めやすくなります。
- 誰が依頼できるか
- AIは何を参照できるか
- どこまで下書きできるか
- 最終実行には誰の承認が必要か
この4点を業務ごとに表にするだけでも、総務・情シス・監査の会話はかなり具体化します。
また、ログ設計も重要です。AIが「何を見て、どの判断で、どの操作を提案または実行したか」を後から追える状態にしないと、権限設計は机上のルールで終わります。
接続管理から実行権限設計へ、論点は移っている
今回のAIニュースは、AI連携が進んだという明るい話で終わりません。むしろ、企業が次に向き合うべき課題が、接続管理から実行権限設計へ移ったことを示しています。
特に総務部門は、個人情報と横断業務の交点にいるため、ボトルネックが表面化しやすい領域の一つです。
AIを安全に現場へ入れるには、「つながっている一覧」より「この業務でここまで許す」を先に決めることが近道です。派手ではありませんが、ここを曖昧にしない企業ほど、生成AIを長く安定して使えます。
まずはServiceNow、SAP、Workdayなど連携対象ごとに、閲覧・更新・承認実行の3段階で権限台帳を作成し、総務・人事・ITSMのどこで実行を止めるかを明文化するとよいでしょう。
地味な設計こそ、いちばん効く。今回のニュースは、その現実をはっきり示しているように見えます。