AIエージェント時代のITILサービスデザイン
サービスカタログは「人向け」から「人とAI向け」へ進化する
CopilotやAgentic AI、MCP（Model Context Protocol）などの登場により、ITサービスの利用形態は大きく変わろうとしています。
これまでITサービスは「人間が理解し、人間が申請し、人間が実行する」ことを前提に設計されていました。しかし今後は、AIエージェントが利用者に代わってサービスを発見し、申請し、実行する世界が現実になりつつあります。
この変化は、ITILにおけるサービスデザインやサービスカタログ管理、サービス構成管理（CMDB）の在り方にも大きな影響を与えるでしょう。
これまでのサービスデザイン
従来のサービスカタログは、人間が読むための情報でした。
例えばPC貸与サービスを考えてみます。
サービス名：
PC貸与サービス
利用方法：
ポータルから申請
提供期間：
5営業日以内
問い合わせ：
Service Desk
利用者はこの内容を理解し、自ら申請を行います。
サービス構成管理も同様です。
サービス
├─ サーバ
├─ ネットワーク
└─ データベース
運用担当者がサービスの依存関係を把握し、障害分析や変更管理に利用することが目的でした。
つまり、サービスデザインの対象は「人間が利用するサービス」だったのです。
AIエージェント時代に何が変わるのか
AIエージェントが普及すると、利用者は個別のサービスを探して申請する必要がなくなります。
例えば利用者は次のように依頼します。
新入社員に必要なITサービスをすべて手配して
するとAIエージェントは次のような処理を実行します。
- 利用可能なサービスを検索
- 必要条件を確認
- 承認ルートを特定
- サービスを申請
- 結果を利用者へ報告
利用者はサービス名すら意識しないかもしれません。
サービスを選択する主体が人間からAIへ移ることで、サービス定義そのものを見直す必要が生じます。
サービスカタログからCapability Catalogへ
※なお、Capability Catalogという名前のプラクティスはITIL4にはありません。あしからず。
従来のサービスカタログは、人間に対して次を説明するものでした。
- 何を提供するか
- どう申請するか
- どこへ問い合わせるか
しかしAIエージェントは説明文を読むのではなく、実行可能な能力（Capability）を理解する必要があります。
今後のサービスカタログは、人間向けとAI向けの二層構造になると考えられます。
人間向け
service:
name: Microsoft 365
description: メールとコラボレーション環境
owner: IT部門
AI向け
service:
id: M365-001
actions:
- create-user
- assign-license
- remove-user
inputs:
employeeId:
type: string
outputs:
account:
type: object
AIにとって重要なのは説明文ではありません。
重要なのは、
- 実行可能なアクション
- 入力パラメータ
- 出力結果
- 制約条件
です。
つまりサービスカタログは、
提供サービス一覧
から
AIエージェントが実行可能な能力一覧
へ進化していくことになります。
機械可読なサービス定義の重要性
AIエージェントがサービスを利用するためには、自然言語だけでは不十分です。
構造化された定義が必要になります。
有力な候補としては以下があります。
- JSON Schema
- YAML
- OpenAPI
- AsyncAPI
- Schema.org
- MCP Tool Definition
例えばユーザー作成サービスは以下のように表現できます。
service: UserProvisioning
intent:
create_employee_account
inputs:
employeeName:
type: string
department:
type: string
outputs:
accountId:
type: string
sla:
fulfillment: 10m
AIエージェントはこの定義から、
- 必要な入力値
- SLA
- 出力情報
を理解し、自律的にサービスを呼び出すことができます。
サービスデザインの成果物も変わる
従来のサービスデザインでは、主な成果物は次のようなものでした。
従来
- 業務フロー
- SLA
- 運用手順書
- サービス設計書
一方、AIエージェント時代では以下の重要性が高まります。
AI時代
- API定義
- OpenAPI仕様
- MCPツール定義
- Semantic Schema
- Policy as Code
- Agent Contract
つまり、
人が運用するための設計
から
AIが理解し実行できる設計
へ設計対象が広がるのです。
CMDBの進化
サービス構成管理（Service Configuration Management）も変化します。
現在のCMDBは主にインフラ資産を管理しています。
サービス
├─ サーバA
├─ サーバB
└─ DB
しかしAIサービスでは依存関係が大きく異なります。
サービス
├─ API
├─ AI Tool
├─ Knowledge Base
├─ LLM
├─ Vector DB
└─ Workflow
生成AIサービスの例です。
生成AIサービス
├─ Azure OpenAI
├─ MCP Server
├─ Vector Database
├─ RAG Repository
├─ Prompt Library
├─ Guardrail Engine
└─ Identity Provider
今後のCMDBでは、このようなAI関連コンポーネントも構成アイテム（CI）として管理対象になるでしょう。
さらに、
- AIモデル
- データソース
- プロンプト
- エージェント
- ツール群
を含むサービス全体のデジタルツインへ進化していく可能性があります。
UXからAXへ
これまでサービスデザインではUX（User Experience）が重視されてきました。
利用者
↓
サービスデスク
↓
担当者
↓
実行
しかしAIエージェントが介在する世界では、
利用者
↓
AI Agent
↓
サービスカタログ
↓
ツール呼び出し
↓
結果返却
という流れになります。
その結果、サービスデザインはUXだけではなく、
AX（Agent Experience）
を考慮する必要があります。
AXとは、
- AIがサービスを検索しやすいか
- AIが必要な情報を取得できるか
- AIが安全に実行できるか
- AIが結果を解釈できるか
を設計する考え方です。
※本記事では、AIエージェントがサービスを発見・理解・実行しやすい体験を Agent Experience（AX）と呼ぶます。
今後のサービスデザインは、
UX + AX
の最適化を目指す活動になるでしょう。
将来のAIネイティブサービスカタログ
将来的には、サービスカタログそのものがAIネイティブな形式になる可能性があります。
service: EmployeeOnboarding
providedFor:
- human
- ai-agent
capabilities:
- create-account
- assign-license
- request-pc
approval:
manager-required
execution:
autonomous
security:
zero-trust
tool-endpoint:
mcp://onboarding
このような定義があれば、AIエージェントはサービスの能力と実行条件を理解し、自律的に処理を進めることができます。
まとめ
AIエージェント時代のサービスデザインでは、従来の「人が利用するサービス」の設計だけでは十分ではありません。
重要になるのは次の5つです。
- 人間向けサービス設計（UX）
- AI向けサービス設計（AX）
- OpenAPIやMCPを活用した機械可読なサービス定義
- AI・データ・ナレッジを含む構成管理
- サービスカタログのCapability Catalog化
ITILの観点で見ると、
- サービスカタログ管理は「サービス一覧管理」から「AIが利用可能な能力の管理」へ
- サービス構成管理は「インフラ中心のCMDB」から「AI・データ・ツールを含むデジタルツイン型CMDB」へ
進化していくと考えられます。
つまり次世代のサービスデザインとは、
「サービス利用者だけでなく、AIエージェントもサービスコンシューマとして捉え、人とAIが協働する価値共創システムを設計する活動への進化である」
と言えるのではないでしょうか。