ITIL 5でITSMはどう変わる？｜AIの役割を6つで分ける

「ITILは情シスの資格の話で、AIをどう入れるかとは別の問題だと思っていた」「窓口にAIを入れたいが、どこまで任せてよいのかを決める物差しがない」。社内のIT運用を預かる情シスの責任者やAI導入の担当者から、よく聞かれる声です。ITILといえば研修と試験の枠組み、という受け止め方は根強く残っています。ところが、ITILの権利を持つピープルサートが2026年に入って段階的に公開している第5版は、AIを前提に作り直され、AIの働きを6つに分けて、働きごとに人の監督の仕方を変えるという考え方を枠組みの中に入れました。ITILはもう、AIの導入と別の話ではありません。本当は、情シスの運用のどこにAIを入れ、どこで人が止めるかを決める物差しとして使える段階に来ています。この記事では、その6つの働きでITSMの業務に入るAIを仕分け、働きごとに人の承認と引き継ぎの線を決める方法を整理します。

「ITILは資格の話」という見方が外れてきた理由

ITILは長く、情シスの担当者が研修で学び、試験を受ける枠組みとして知られてきました。そのため、AIの導入を考える場面では、ITILの話は後回しにされがちです。ところが、ITILの権利を持つピープルサートは、第5版を「AIを前提に設計した」と説明しています。第5版は2026年に入ってから、学習の単位ごとに段階的に公開が進んでいます。

その前段として、ITILの公式サイトは2025年11月7日に、AIガバナンスについての白書を公開しています。白書は、従来のITのガバナンスだけではAIには足りないとし、その理由として、判断の自律性、中身の見えにくさ、変わり続ける倫理の問題、速く変わる規制の要件を挙げました。そのうえで、AIの働きを6つに分け、働きごとにAI特有のリスクを対応させる考え方を示しています。

さらに、2026年5月8日に公式サイトで紹介された第5版の利用者体験の単位では、この6つの働きを使って「そのAIがどの働きをしているのかを正確に名指しする」ことが求められています。あわせて、判断の境界、人への引き継ぎの決まり、働きごとの記録、人を中心に置くことが挙げられています。AIを入れること自体ではなく、入れた後に人がどう監督するかが、枠組みの言葉で書かれたことになります。

このことから、ITILを「資格の話」として脇に置いておくと、情シスの運用にAIを入れるときの共通の物差しを1つ見落とすことになります。本稿は、試験や資格の話には入らず、この物差しを社内の運用にどう当てはめるかに絞ります。

ITILとITSMを1段落で、そして本稿が扱わない範囲

ITSMは、社内外の利用者に対してITのサービスを安定して届けるための運用の管理のことで、ITILはその進め方を体系にまとめた枠組みです。問い合わせの窓口、障害への対応、依頼の処理、変更の管理、知識の蓄積といった業務を、どういう考え方で回すかを示しています。定義の説明はここまでにとどめ、以降はAIを入れる線引きの話に絞ります。

近い題材を扱った記事がいくつかあるため、本稿が入らない範囲を先に示します。構成の台帳に何を記録するかは「CMDBとは何を記録する台帳？｜AIの構成を追える形に」で扱っています。特定の製品にAIを載せる段階の設計、監視の通知を束ねて異変に気づく仕組み、AIそのものの変更の管理、AIが起こした事故への対応、社内の問い合わせを型で分ける方法、情シスの仕事をどの工程から軽くするかも、それぞれ別の記事にあります。

本稿の切り口はそれらと違い、AIを「何をしているか」という働きで分けることです。問い合わせを内容で分けるのでも、工程の順番で分けるのでもありません。同じ窓口の業務の中にも、下書きを作るAIと、利用者と直接やりとりするAIと、裏で仕組みを操作するAIが混ざります。その違いに応じて、人の関わり方を変えるのが本稿の狙いです。

第5版が入れた、AIの働きを6つに分ける考え方

ITILの白書が示した6つの働きを、日本語で説明します。名前の訳は本稿によるもので、原文の語ではありません。1つめは、文章や手順などを新しく「作る」働きです。2つめは、情報を選び、並べ、重複や古さを「整える」働きです。3つめは、難しい内容を要約したり言い換えたりして「分かりやすくする」働きです。

4つめは、データの中から傾向や異変を見つけて「気づく」働きです。5つめは、利用者と言葉でやりとりする「対話する」働きです。6つめは、複数の仕組みをまたいで、実際に作業を「実行する」働きです。チケットを起票し、別の仕組みの設定を変え、結果を通知する、といった一連の操作をAIが自分で進める場面がこれに当たります。

この6つは、どれか1つに分類するための箱ではありません。実際の仕組みでは、1つのAIが複数の働きを兼ねることがよくあります。たとえば窓口の対話のAIは、利用者の質問を分かりやすく言い換え、回答を作り、利用者と対話しています。大事なのは、1つの仕組みの中で、どの働きをどの場面で使っているかを分けて書き出すことです。

白書は、この6つの働きにAI特有のリスクを対応させています。働きが違えば、起きうる失敗の種類も、失敗したときの影響の大きさも違う、という考え方です。だからこそ、働きごとに人の監督の仕方を変える、という発想が出てきます。

従来のITのガバナンスだけでは足りないとされた理由

白書は、AIのガバナンスを4つの見方で整理しています。1つめは判断の権限とリスクの管理、2つめは倫理の原則と責任あるAI、3つめはデータの統治と性能の管理、4つめは規制の順守と運用の基準です。これまでのITのガバナンスは、主に仕組みの変更や権限の管理を対象にしてきましたが、AIでは判断そのものの扱いが加わります。

情シスの運用で特に効くのは、1つめの判断の権限です。これまでの自動化は、人が書いた手順のとおりに動くものでした。AIは、与えられた目的に向かって、手順にない判断を自分で下すことがあります。誰の判断としてその操作が行われたのかが、見えにくくなるのです。白書が判断の自律性を最初の課題に挙げたのは、このためだと読めます。

2つめの見えにくさも、運用の現場の問題に直結します。AIがなぜその回答を返したのか、なぜその障害を重大と見たのかが、後から説明できないことがあります。運用の記録として残すべきなのは、AIの出した結果だけでなく、その結果を人が採用したのか、修正したのか、退けたのかという判断の記録です。

つまり、AIのガバナンスは、既存の運用の決まりに「AIの項目」を1行足すだけでは済みません。働きごとに、誰が判断の権限を持つのか、どこで人が止めるのかを決め直す必要があります。次の節から、その決め直しを働き別に進めます。

ITSMの業務に、どの働きが入るか（本稿の整理）

ここからは、ITSMの主な業務に6つの働きを当てはめます。この当てはめは本稿の整理で、ITILの原文に書かれた対応ではありません。自社の業務に合わせて読み替えてください。

業務	入りやすい働き	AIに任せやすい作業	人が持つ判断
問い合わせの窓口	分かりやすくする・対話する・作る	質問の言い換え、回答の下書き、よくある質問への一次応答	利用者への最終回答、人に引き継ぐ条件
障害への対応	気づく・分かりやすくする	兆しの候補出し、経緯の要約	優先度の確定、利用者への告知の内容
依頼の処理	実行する・作る	申請の項目の確認、定型の処理の準備	本番の仕組みで実行するかどうか
変更の管理	分かりやすくする・気づく	変更の申請の要約、影響が出そうな箇所の候補出し	変更の承認
知識の蓄積	整える・作る	重複や古い記事の指摘、記事の下書き	公開してよい内容かの判断

表から分かるのは、同じ業務の中に複数の働きが入ることです。窓口の業務では、裏で質問を言い換える働きと、利用者と直接やりとりする働きとで、間違えたときの影響が違います。言い換えの誤りは担当者が気づけば直せますが、対話の誤りは利用者に直接届きます。働きで分けて見ると、承認を挟むべき場所が業務の単位より細かく見えてきます。

この整理を作るときは、まず自社でAIを使っている、または使う予定の場面を全部書き出し、場面ごとに働きを付けます。働きの付け方に迷う場面は、AIの出した結果が人の確認を経ずに外に出るのか、仕組みを変えるのかを問うと決めやすくなります。

「作る」働き：回答と手順書の下書きまで

作る働きは、回答の文面、手順書、障害の報告書の下書きなど、新しい文章を生み出す場面です。情シスの運用では最も使いやすく、効果も見えやすい働きです。担当者が一から書いていた文面の土台をAIが用意し、担当者が直して使う、という形がとれます。

この働きで起きやすい失敗は、もっともらしい誤りです。存在しない設定の項目名や、社内では使っていない手順を、自然な文章で書いてしまうことがあります。そのため、作る働きの出力は下書きとして扱い、人が確かめてから使うことを原則にします。特に、手順書や設定の説明のように、そのとおりに操作されるものは、確かめる人を決めておきます。

AIに下書きを作らせるときは、根拠にした社内の記事や過去のチケットを、出力の中に示させます。根拠のない下書きは、確かめる人がどこを見ればよいか分かりません。根拠が示されていれば、確かめる作業は「元の記事と合っているか」を見るだけで済みます。

作る働きに承認を挟む場所は、下書きを作る時点ではなく、下書きが外に出る時点です。下書きを作らせること自体は自由にしてよく、利用者に送る前、手順書として公開する前に、人の確認を必ず通す、という線を引きます。

「整える」働き：知識の重複と古さを指摘させる

整える働きは、社内の知識の記事や手順書を並べ直し、重複している記事や古くなった記事を見つける場面です。知識の記事は、書き足されることはあっても、見直されることが少なく、同じ内容の記事が何本もある、手順が古いまま残っている、といった状態になりがちです。

AIは、大量の記事を読み比べて、似た記事の組を挙げたり、古い製品名や手順が残っている記事に印を付けたりするのが得意です。ただし、どちらの記事を残し、どちらを消すかを決めるのは人です。似て見える2本の記事が、実は対象の部署や条件が違っていて、両方必要な場合があるからです。

この働きの落とし穴は、AIが指摘だけでなく、統合や削除まで自動で進めてしまう設定です。知識の記事は、窓口の対話のAIが回答の根拠として使っていることもあります。記事を消すと、対話のAIの回答まで変わってしまいます。整える働きは指摘までにとどめ、統合と削除は記事の持ち主が決める線を引きます。

指摘の結果は、記事の持ち主ごとに振り分けて渡すと動きやすくなります。指摘の一覧が情シスの担当者1人に集まると、量が多すぎて手が付かなくなるからです。

「分かりやすくする」働き：チケットの要約と言い換え

分かりやすくする働きは、長いチケットのやりとりを要約したり、利用者の書いた分かりにくい質問を言い換えたり、技術的な説明を利用者向けの言葉に直したりする場面です。担当の引き継ぎや、上の階層への報告のたびに、経緯を読み直す手間を減らせます。

この働きで注意したいのは、要約で落ちる情報です。要約は短くするほど、条件や例外が落ちます。障害の経緯の要約で、「一部の利用者だけ」という条件が落ちると、影響の範囲を読み違えます。そのため、要約には元のチケットへの参照を必ず付け、判断に使う前に元を確かめられる形にしておきます。

言い換えも同じです。利用者の質問を言い換えるとき、AIが質問の意図を取り違えると、その後の回答の作成も対話も、取り違えた意図のまま進みます。言い換えの結果を利用者に見せて確かめる、担当者が元の質問と並べて読む、といった確かめ方を、場面に応じて決めておきます。

分かりやすくする働きは、それ自体では外に出ず、仕組みも変えません。そのため承認は軽くしてよい働きです。ただし、その結果が別の働きの入力になるときは、後ろの働きの重さに合わせて確かめる必要があります。要約が変更の承認の材料になるなら、要約の確かめ方も承認の一部になります。

「気づく」働き：障害の兆しは候補として出させる

気づく働きは、監視のデータやチケットの傾向から、障害の兆しや、同じ原因から来ていそうな問い合わせの組を見つける場面です。人が見落とすような小さな変化を拾えるのが強みで、障害への対応を早める効果が期待できます。

ITILの公式サイトで紹介された利用者体験の単位では、利用者の体験を左右する場面では、気づく働きと対話する働きに、人の注意深い監督が要るとされています。気づく働きの誤りには、異変を見落とす誤りと、異変でないものを異変とする誤りの両方があります。後者が続くと、担当者が通知を見なくなり、本当の異変も見落とされます。

そのため、気づく働きの出力は「候補」として扱います。AIが挙げた兆しを、障害として扱うかどうか、優先度をどう付けるかは人が確定します。優先度は、利用者への影響、業務の重要さ、回避策の有無といった、AIが見ているデータの外にある事情で決まることが多いからです。

監視の仕組みそのものの作り方は本稿では扱いませんが、気づく働きを入れるときに決めておくべきことは1つです。AIの候補を誰が見て、どのくらいの時間で確定するか、です。候補が出ても誰も見ないなら、その働きは入れていないのと同じです。

「対話する」働き：利用者への最終回答は人が送る

対話する働きは、窓口のチャットや、障害の状況を利用者に知らせる連絡のように、AIが利用者と直接言葉を交わす場面です。人の担当者がいない時間にも一次の応答ができるため、窓口の負担を大きく減らせる働きです。

一方で、6つの働きの中で、誤りが最も直接に利用者に届く働きでもあります。利用者体験の単位の紹介では、障害の状況を利用者ごとに合わせて知らせる場面を例に、人の理解を欠いた自動の応答にならないよう、人の監督が要るとしています。公式の紹介は、AIは人が信頼して使えるときにはじめて価値を生む、と述べています。

線の引き方としては、よくある質問への一次応答はAIに任せ、利用者の業務に影響する判断を含む回答は、人が確かめてから送る形が現実的です。たとえば、権限の付与を認めるか、障害の復旧の見込みをいつと伝えるか、といった回答は、AIが下書きを作り、人が送ります。

もう1つ決めておくべきなのが、AIの対話から人に引き継ぐ条件です。利用者が同じ質問を繰り返している、利用者が不満を示している、回答の根拠になる記事が見つからない、といった条件を決めておき、当てはまったら人に渡します。条件を決めずに対話のAIを入れると、利用者がAIとのやりとりから抜け出せなくなります。

「実行する」働き：本番で動かすかを先に決める

実行する働きは、複数の仕組みをまたいで、AIが実際に操作を進める場面です。依頼のチケットを読み、アカウントの仕組みで権限を付与し、結果を利用者に知らせる、といった一連の処理を、AIが自分で進めます。うまく動けば、依頼の処理を大きく速くできます。

ただし、6つの働きの中で、失敗したときの影響が最も大きい働きです。作る働きの誤りは下書きの誤りで済みますが、実行する働きの誤りは、本番の仕組みの状態を変えてしまいます。権限を誤って付与する、設定を誤って変える、といった誤りは、気づくまでの間ずっと影響が続きます。

そのため、この働きについては、本番の仕組みで動かしてよいかどうかを、働きを入れる前に人が決めます。最初は検証の環境だけで動かす、本番では実行の直前に人の承認を挟む、元に戻せる操作だけを任せる、といった段階を、業務ごとに決めます。権限の段階の上げ下げの設計そのものは本稿では扱いませんが、少なくとも「この業務の実行は本番で動かしてよい」と決めた人と日付を残しておきます。

この働きでは、AIの操作の記録が特に重要です。AIがどの仕組みで何を変えたのかを、人が後からたどれる形で残します。記録の残し方が決まっていない段階で本番に入れないことが、最も確かな歯止めになります。

働きごとに、人の承認をどこに挟むか

ここまでの6つの働きを比べると、承認を挟む場所の考え方が見えてきます。基準になるのは、AIの出力が人の確認を経ずに外に出るか、仕組みの状態を変えるか、の2つです。どちらにも当たらない働きは承認を軽くし、どちらかに当たる働きは、その手前に承認を置きます。

この基準で並べると、分かりやすくする働きと整える働きは、出力が社内にとどまり、仕組みも変えないため、承認は軽くてよい側に入ります。作る働きは、下書きの段階では軽く、外に出る時点で承認を置きます。気づく働きは、候補を確定する時点で人が入ります。対話する働きは、業務に影響する回答の手前で人が入ります。実行する働きは、本番で動かすこと自体の承認と、操作の直前の承認の2段で人が入ります。

気をつけたいのは、承認を重くしすぎることです。すべての働きの出力に人の承認を求めると、承認する人が追いつかず、確認が形だけになります。承認は、影響の大きい場所に絞って厚くするほうが、結果として監督が効きます。働きで分けるのは、そのための仕分けでもあります。

承認を置く場所を決めたら、承認する人を役割で決めます。個人の名前で決めると、異動や休みのたびに承認が止まります。窓口の責任者、変更の承認者、知識の記事の持ち主、といった役割に結び付け、役割ごとに代わりの人を決めておきます。

AIから人に引き継ぐ条件と、働きの記録を書いておく

利用者体験の単位の紹介が求めているのは、判断の境界、人への引き継ぎの決まり、働きごとの記録です。社内の運用に置き換えると、AIがどこまで判断してよいか、どんな条件で人に渡すか、そのAIがどの働きをしているか、を文書にしておく、ということです。

引き継ぎの条件は、働きごとに書きます。対話する働きなら、利用者が不満を示した、同じ質問が繰り返された、回答の根拠が見つからない。気づく働きなら、候補の重大さが一定以上と見込まれる。実行する働きなら、操作の対象が決めた範囲の外にある、操作が失敗した。条件が書かれていない引き継ぎは、実際には起きません。AIは、止まるべき場面を自分では判断できないからです。

働きの記録は、AIの仕組みごとに1枚ずつ作ります。書く項目は、その仕組みが使う働き、入力にする情報、出力の行き先、承認を挟む場所、人に引き継ぐ条件、持ち主です。持ち主の欄が空の記録は作らないことを決まりにしておきます。持ち主のいないAIの仕組みは、問題が起きたときに誰も止められません。

記録の下書きは、AIに作らせることができます。仕組みの設定や説明の資料を読み込ませ、項目ごとに埋めさせます。ただし、承認の場所と引き継ぎの条件は、AIが資料から推測して埋めてよい項目ではありません。そこは人が決めて書きます。

ITIL 4のまま続けるか、第5版に寄せるか

社内の運用の手順や研修の教材をITIL 4に沿って作ってきた組織では、第5版に寄せるかどうかが問題になります。ピープルサートの案内では、ITIL 4は今後も引き続き提供されるとされており、確認した範囲では終了の時期は示されていません。急いで全部を書き換える必要はありません。

判断の目安は、AIを運用にどこまで入れているかです。AIをまだ試しの段階でしか使っていないなら、ITIL 4の手順のまま、AIの部分だけ本稿のような働きの仕分けを足す形で足ります。窓口や依頼の処理でAIが本番で動いている、または動かす予定があるなら、働きの分け方とガバナンスの考え方だけでも、先に社内の手順に取り込む価値があります。

寄せるときに避けたいのは、版の書き換えそのものが目的になることです。手順書の用語を新しい版に合わせても、承認の場所と引き継ぎの条件が決まっていなければ、AIの監督は何も変わりません。書き換える順番は、用語ではなく、AIが入っている業務の承認と引き継ぎの決まりからにします。

研修の版をどうするかは、社内の共通の言葉をどちらに合わせるかの判断です。AIの働きを6つで呼び分ける言葉を、情シスと業務部門で共有できると、どのAIに何を任せているかの会話がしやすくなります。どの版で研修するかは、この共通の言葉の効き目と、教材を作り直す手間を比べて決めます。

働き別・人が持つ判断のチェックリスト

最後に、働きごとに人が持つ判断を一覧にします。AIの仕組みを入れるとき、またはすでに入っている仕組みを見直すときに、この表の右の列が全部埋まっているかを確かめてください。

働き	AIに任せてよい範囲	人が持つ判断	確かめる問い
作る	回答、手順書、報告書の下書き	外に出す前の確認	下書きの根拠が示されているか
整える	重複や古い記事の指摘	記事の統合と削除	指摘が持ち主ごとに届いているか
分かりやすくする	チケットの要約、質問の言い換え	要約を判断に使う前の照合	元のチケットへの参照があるか
気づく	障害の兆しの候補出し	障害として扱うか、優先度の確定	候補を見る人と時間が決まっているか
対話する	よくある質問への一次応答	業務に影響する回答、人への引き継ぎ	引き継ぎの条件が書かれているか
実行する	検証の環境での処理、承認後の操作	本番で動かすか、操作の直前の承認	操作の記録をたどれるか

この表を使って見直しを進める手順は、次のとおりです。

見直しでよく見つかる失敗も挙げておきます。

• AIを1つのものとして扱う：下書きのAIと実行のAIに同じ承認をかけ、重い側の監督が足りなくなる
• すべての出力に承認を求める：承認が追いつかず、確認が形だけになる
• 引き継ぎの条件を書かない：利用者が対話のAIから抜け出せず、不満が窓口の外に出る
• 働きの当てはめを原文と混ぜる：社内の整理をITILの規定のように扱い、見直せなくなる

• 6つの働きと4つの見方は、ITILの公式サイトの白書の紹介（2025年11月7日）に基づきます。日本語の名前は本稿の訳です
• 判断の境界、引き継ぎの決まり、働きの記録、気づく働きと対話する働きの監督は、ITILの公式サイトの紹介（2026年5月8日）に基づきます
• ITIL 4の提供が続くことは、ピープルサートの案内に基づきます（2026年10月3日に確認）。業務への当てはめは本稿の整理です

まとめ

ITILは資格の話でAIの導入とは別、という見方は、第5版で外れつつあります。ピープルサートは第5版をAIを前提に設計したと説明し、ITILの公式サイトはAIの働きを作る、整える、分かりやすくする、気づく、対話する、複数の仕組みをまたいで実行する、の6つに分ける考え方と、AIガバナンスの4つの見方を示しました。情シスの運用にAIを入れるときは、窓口、障害、依頼、変更、知識の各業務に入るAIを働きで仕分け、出力が外に出るか、仕組みを変えるかで承認の場所を決めてください。要約、下書き、重複の指摘、兆しの候補出しはAIに任せ、根拠を示させます。複数の仕組みをまたぐ実行を本番で動かすか、承認をどこに挟むか、人に引き継ぐ条件、障害の優先度の確定、変更の承認、利用者への最終回答は人が決めます。働きごとの記録に持ち主を書くことが、その線を守り続ける出発点です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。