ITIL Foundation（Version 5）用語ノート
試験対策用。用語は「日本語（English）」の形で並べています。
このノートは、Nex Arc Learning の学習ガイド（ITILFND-V5 Study Guide）で扱われている用語を拾い、意味を自分の言葉で短くまとめたものです。ガイドの訳ではありません。試験で問われる正式な英語の定義は、公式資料（ITIL Foundation Version 5 の公式テキスト）で確かめてください。
領域 1／7：主要な用語と定義（Key ITIL terms and definitions）
1. プロダクトとサービスの管理Product and Service Management
- デジタル・プロダクトとサービスの管理digital product and service management
- デジタルのプロダクトやサービスを通じて価値を生むための、組織の専門的な能力のまとまり。以前の ITIL でいう「サービスマネジメント」が発展したもの。プロダクトとサービスを別々ではなく一緒に管理するのが Version 5 の特徴。
- プロダクトproduct
- 組織の資源を組み合わせて、相手に価値を届けられるように作ったもの。サービスはプロダクトの一部を相手に届ける形。
- サービスservice
- 相手が特定のコストやリスクを自分で抱えずに済むようにしながら、価値の共創を可能にする手段。
- デジタル・プロダクト／デジタル・サービスdigital product / digital service
- デジタル技術によって提供・実現されるプロダクトやサービス。「デジタル」は新しい種類ではなく、届け方（経路）が加わっただけ。定義そのものは変わらない。
- グッズ（物品）good
- 価値をもつ形のある物で、所有権を相手に移せるもの。見分けるポイントは「所有権が移るかどうか」。
- 有用性utility
- サービスが「何をするか」。目的に合っているか（fit for purpose）。相手の仕事を助ける、または制約を取り除く機能のこと。
- 保証warranty
- サービスが「どれだけ確実に動くか」。使用に適しているか（fit for use）。可用性・キャパシティ・セキュリティ・継続性で支える。
- ユーザー体験user experience (UX)
- サービスを使っているときに利用者がどう感じるか。価値の4つの特性の1つ。
- 持続可能性sustainability
- 環境・社会・経済の面で、責任ある状態を長く保てるか。価値の4つの特性の1つ。
- サービスの4つの価値特性four value characteristics of a service
- 有用性・保証・ユーザー体験・持続可能性の4つ。
- 継続的改善continual improvement
- プロダクトやサービスを、変わる要求に合わせて良くし続けること。デジタル・プロダクトとサービスの管理の主要概念として独立して扱われる。
- ITIL プロダクトとサービスのライフサイクルITIL Product and Service Lifecycle
- プロダクトやサービスの一生全体を見る考え方。詳しくは第8・9章。
| 特性 | 問い | 合言葉 |
|---|---|---|
| 有用性（utility） | 何をするか | fit for purpose |
| 保証（warranty） | どれだけ確実に動くか | fit for use |
| UX | 使ってどう感じるか | （fit for … ではない） |
| 持続可能性（sustainability） | 長く責任を果たせるか | （fit for … ではない） |
ひっかけ：purpose ＝ 有用性、use ＝ 保証。逆にしやすい。グッズは「所有権が移る」、リソースへのアクセスは「所有権が移らない」。
ITIL を使う4つの立場：企業（enterprises）、マネージドサービスプロバイダー（managed service providers）、デジタル・プロダクトのベンダー（digital product vendors）、管理の専門職（professionals）。それぞれの得るものを区別して問われる。
2. 体験・戦略・変革Experience, Strategy and Transformation
- 体験experience
- 人が組織とのやりとりについて、どう考え、どう感じるか。
- デジタル体験digital experience
- デジタルの経路を通したやりとりで生まれる体験。
- ユーザー体験user experience (UX)
- 特定の1つのプロダクトやサービスを使ったときの体験。
- カスタマー体験customer experience (CX)
- 顧客が組織との関係全体を通じて持つ、すべてのやりとりの体験。
- 信頼trust
- 相手が確実で誠実だと信じられること。
- 人間中心設計human-centred design
- 人のニーズを設計の真ん中に置く考え方。
- 体験レベル合意experience level agreement (XLA)
- 技術的な数値だけでなく、利用者や顧客の体験を目標にする合意。
- 戦略／事業戦略／デジタル戦略strategy / business strategy / digital strategy
- どれも方向を決めるものだが、対象の範囲が違う。戦略は一般の方向づけ、事業戦略は事業全体、デジタル戦略はデジタル技術の活用に関する方向づけ。
- ミッションmission
- 組織がいま何をしていて、なぜ存在するのか（現在）。
- ビジョンvision
- 組織が将来どうなりたいか（未来）。
- パーパス（存在意義）purpose
- 利用者や関係者のために何をするのか、そしてなぜか（誰のためか）。
- VUCAvolatility, uncertainty, complexity, ambiguity
- 変動が激しく、不確かで、複雑で、あいまいな環境のこと。
- リーダーシップleadership
- 人を目標に向かって導くこと。
- 変更change
- プロダクト・サービス・仕事のやり方などを変えること（小さく、積み重ねる変化）。
- 変革transformation
- 組織の動き方そのものを根本から変える、深い変化。
- 通常業務business as usual (BAU)
- すでに確立した業務を、いつもどおり回している状態。
ひっかけ：UX は「1つのプロダクト」、CX は「関係全体」。XLA は体験、SLA はサービスレベル。ミッション＝今、ビジョン＝未来、パーパス＝誰のために・なぜ。変更＝少しずつ、変革＝根本から、BAU＝安定した日常。
3. サービス・オファリングService Offerings
- サービス・オファリングservice offering
- ある利用者グループ向けに、提供するサービスを正式に説明したもの。グッズ・アクセス・サービス・アクションを組み合わせ、組み合わせ方はグループごとに変える。
- グッズの移転transfer of goods
- 形ある物の所有権を利用者に渡すこと。渡したあとは利用者が責任を持つ。例：ノートPCやスマートフォンの支給。
- リソースへのアクセスaccess to resources
- 提供者が持つ資源を、決めた条件で利用者が使えるようにすること。所有権は提供者に残る。例：クラウドストレージ、ネットワーク、アプリ。
- サービス・アクションservice actions
- 利用者のニーズに応えるために提供者が行う作業。例：サービスデスクが依頼を解決する。
- サービス・インタラクションservice interactions
- 提供者と利用者が価値を共創するために関わり合うやり方。
ひっかけ：デジタル・サービスでの主なやりとりは「リソースへのアクセス」。デジタルの提供者は、自動化やセルフサービスでサービス・アクションを減らすことが多い。3つは「所有権が移るか」「だれが作業するか」で見分ける。
4. 価値の共創Value Co-creation
- 価値value
- あるものから感じられる便益・有用さ・大切さ。価値を判断するのは受け取る側。
- 価値の共創value co-creation
- 提供者と利用者が積極的に協力して、いっしょに価値をつくること。成果とコスト・リスクをまとめて比べて判断する。
- コストcost
- 活動や資源にかかるお金。サービスは利用者のコストを減らす面と、新たに課す面の両方がある。
- リスクrisk
- 損害を与えたり、目標達成を難しくしたりするかもしれない出来事。サービスはリスクを減らすだけでなく、新しいリスク（提供者への依存など）も生む。なくすのではなく最適化するもの。
- アウトプットoutput
- 活動が生み出す成果物（形があってもなくてもよい）。例：月次レポート、用意されたサーバー。
- アウトカムoutcome
- 関係者が望む結果。1つ以上のアウトプットによって可能になる。例：よりよい意思決定、受注処理の高速化。
- フィードバックfeedback
- 改善の方向を示し、価値の共創を進める手がかり。
ひっかけ：アウトプットを渡した＝アウトカム達成、ではない。コストを「利用者が払う料金」だけと考えない（サービスが減らすコストもある）。価値に寄与するのは有用性・保証・UX・持続可能性の4つ。
5. サービス関係Service Relationships
- 組織organization
- 独自の機能・権限・関係をもつ人や集団。
- サービス提供者service provider
- サービスを提供する側。
- サービス利用者service consumer
- サービスを受け取って使う側。
- デジタル・プロダクトのベンダーdigital product vendor
- 継続的なサービス関係を運営するのではなく、デジタル・プロダクトを供給する側。
- サービス関係service relationship
- 提供者と利用者が価値を共創するための協力関係。関係の種類や利用者の役割をまとめる大きな枠。
- 基本的／協調的／協働的な関係basic / cooperative / collaborative
- 関係の深さによる3分類。基本的＝標準サービスのやりとり中心、協調的＝共通の目標に向けて連携、協働的＝リスクも成果も分かち合う密な関係。
- スポンサーsponsor
- サービス利用の予算を承認する人。
- 顧客customer
- サービスへの要求を決める人。
- ユーザーuser
- サービスを実際に使う人。
- サービス・ジャーニーservice journey
- 利用者がすべての接点を通して経験する、最初から最後までの道のり。
- サービス品質service quality
- ニーズを満たすことに関わる、サービスの特性の全体。
- サービスレベルservice level
- 合意した目標に対して、期待される・達成された実績を測るもの。
- サービスレベル合意service level agreement (SLA)
- 必要なサービスと期待するサービスレベルを文書で取り決めたもの。
| 基本的 basic | 協調的 cooperative | 協働的 collaborative | |
|---|---|---|---|
| 統合の深さ | いちばん浅い | 中くらい | いちばん深い |
| リスクと報酬 | 別々に持つ | ほぼ別々・努力は連携 | 分かち合う |
ひっかけ：お金を出す＝スポンサー、要求を決める＝顧客、使う＝ユーザー。サービス品質（特性の全体）／サービスレベル（測った値）／SLA（文書の合意）を区別する。
領域 2／7：プロダクトとサービス管理の4つの側面（Four Dimensions）
6. 4つの側面（入門）Introduction to the Four Dimensions
- プロダクトとサービス管理の4つの側面four dimensions of product and service management
- どのプロダクトやサービスにも当てはめる4つの見方。Version 5 での正式な呼び名。
- 組織と人材organizations and people
- 提供者自身の人の面。役割・体制・文化・能力・スキル。外部の契約は含まない。
- パートナーとサプライヤーpartners and suppliers
- サービスに関わる外部の組織との関係と、それを決める契約・合意。例：供給者契約、SIAM（service integration and management）。
- 情報と技術information and technology
- 必要な情報・知識と、サービスの中や管理に使う技術。例：アプリ、データベース、AI、クラウド。セキュリティ・法令順守・適合性を考えて選ぶ。
- バリューストリームとプロセスvalue streams and processes
- 組織自身の活動を、価値を生むようにどう連携させるか。バリューストリーム＝一連の手順、プロセス＝インプットをアウトプットに変える活動のまとまり。
- 全体的なアプローチholistic approach
- 4つの側面を別々ではなく、まとめて考えること。
ひっかけ：4つの側面は「ITIL バリュー・システムの構成要素」ではない（別のモデル）。自社の人＝組織と人材、他社＝パートナーとサプライヤー。どの外部業者が関わるかは「バリューストリームとプロセス」ではない。
7. 内部要因と外部要因Internal and External Factors
- 内部要因internal factors
- 組織が自分で形づくり管理できるもの。4つの側面がこれにあたる。
- 外部要因external factors
- 組織の外から来て、ほぼコントロールできないもの。4つの側面すべてに影響する。PESTLE で分析する。
- PESTLEPolitical, Economic, Social, Technological, Legal, Environmental
- 外部要因を6つに分ける枠組み。
| 分類 | 中身 | 例 |
|---|---|---|
| 政治的 Political | 政府・政策 | 政策、政情の安定、税制 |
| 経済的 Economic | 市場・お金の状況 | 景気、金利、インフレ、為替 |
| 社会的 Social | 社会・人口の傾向 | 人口構成、価値観、生活様式 |
| 技術的 Technological | 技術変化の速さと性質 | イノベーション、自動化 |
| 法的 Legal | 法律・順守の義務 | 労働法、データ保護法 |
| 環境的 Environmental | 環境・持続可能性 | 気候、排出目標 |
ひっかけ：金利は「経済」（政治ではない）。プライバシー法は「法的」（技術ではない）。排出目標は「環境」。自社の社員は内部（組織と人材）で、社会の傾向が「社会的」。
領域 3／7：プロダクトとサービスのライフサイクル（Product and Service Lifecycle）
8. ライフサイクル（入門）Introduction to the Product and Service Lifecycle
- ITIL プロダクトとサービスのライフサイクルITIL Product and Service Lifecycle
- すべてのプロダクトとサービスに、一連の活動がどう当てはまるかを示す、端から端までのモデル。機会の発見から廃止まで。
- 8つの活動discover, design, acquire, build, transition, operate, deliver, support
- 発見・設計・取得・構築・移行・運用・提供・サポート。バリューチェーンの8活動と同じ。
- エコシステム・アプローチecosystem approach
- プロダクトとサービスを1つのライフサイクルで全体的に管理するやり方。従来の順番どおりの「計画→構築→運用（plan-build-run）」に代わるもの。
ひっかけ：活動は順番どおりでも一直線でもない。くり返し使える。同じサービスの別バージョンが同時に別の活動にいてよい。8活動は ITIL v3 の5段階（戦略・設計・移行・運用・継続的サービス改善）に代わるもの。ライフサイクル（一生全体のモデル）、バリューチェーン（運営モデル）、バリューストリーム（個別の道筋）、継続的改善モデル（改善の手順）は別物。
9. ライフサイクル活動の目的と範囲Purpose and Scope of the Lifecycle Activities
| 活動 | グループ | 目的（要点） |
|---|---|---|
| 発見 Discover | つくり出す | 環境・需要・機会を理解し、何が必要かを見極める |
| 設計 Design | 必要を、4つの価値特性を満たす仕様にする | |
| 取得 Acquire | 必要な部品・物品・資源を社内外から手に入れ割り当てる | |
| 構築 Build | 部品を作り、組み合わせ、設定し、テストする | |
| 移行 Transition | 本番に移す | 新規・変更を安全に本番へ移し、使える状態か確かめる |
| 運用 Operate | 本番で価値を保つ | 本番のサービスと部品を、合意した水準で動かし続ける |
| 提供 Deliver | 動いているサービスとその価値を、利用者に届け続ける | |
| サポート Support | 問題・インシデント・問い合わせ・依頼に対応し、通常に戻す |
ひっかけ：Version 5 は昔の「運用」段階を「運用（operate）」と「提供（deliver）」に分けた。移行＝1回きりの展開、提供＝継続的に届ける。サポートは作らない・展開しない（本番のものに対応するだけ）。
領域 4／7：ITIL バリュー・システム（ITIL Value System）
10. バリュー・システムの構成要素Components of the ITIL Value System
- ITIL バリュー・システムITIL Value System (ITIL VS)
- 機会と需要を価値に変える、組織全体のしくみ。5つの構成要素が連携する。ITIL 4 では「サービス・バリュー・システム（Service Value System）」と呼んでいた。
| 構成要素 | 役割 |
|---|---|
| 従うべき原則 Guiding principles | どんな状況でも判断と行動を導く普遍的な推奨 |
| ガバナンス Governance | 統治機関が組織を方向づけ、統制する |
| バリューチェーン Value chain | 価値をつくって届ける、つながった活動の運営モデル |
| 管理プラクティス Management practices | 仕事を行うための組織の資源のまとまり |
| 継続的改善 Continual improvement | 要求が変わっても、すべてを有効に保ち続ける |
ひっかけ：バリューチェーンは構成要素の1つで、バリュー・システム全体ではない。Version 5 の呼び名は「ITIL Value System」。
11. 従うべき原則The ITIL Guiding Principles
- 従うべき原則guiding principle
- どんな状況・取り組みにも当てはまる推奨。7つあり、単独ではなく組み合わせて使う。
| 原則 | 要点 | よくある誤解 |
|---|---|---|
| 価値に着目する Focus on value | すべての活動を関係者の価値につなげる。価値は利用者の視点で決める | 提供側のコストで価値を測る |
| 現状からはじめる Start where you are | 今あるものを評価し、使えるものは再利用する。現状は直接測る | 「何も変えない」「全部作り直す」と読む |
| フィードバックをもとに反復して進化する Progress iteratively with feedback | 小さな単位で進め、前・途中・後にフィードバックを得る | 最後にまとめて一度に出す |
| 協働し、可視性を高める Collaborate and promote visibility | 適切な人を巻き込み、仕事を見えるようにする | 人数が多いほどよいと考える |
| 全体的に考えて取り組む Think and work holistically | サービス・プラクティス・供給者を1つのシステムとして扱う | 一部だけ最適化して全体を損なう |
| シンプルにし、実践的にする Keep it simple and practical | 成果に必要な最小の手順にする。価値のない手順や指標は除く | 「シンプル＝簡単」と考える |
| 最適化し、自動化する Optimize and automate | まず最適化し、そのあと価値がある所を自動化する | ムダな手順をそのまま自動化する |
ひっかけ：最適化が先、自動化はあと。日本語名は資料によって少しずつ違うので、英語名で覚えておくと確実。
12. ガバナンスGovernance
- ガバナンスgovernance
- 組織を方向づけ、統制する手段。日々の管理（management）より上の層で働く。
- 統治機関governing body
- ガバナンスに責任を負う集団（取締役会など）。
- 評価evaluate
- 組織・戦略・ポートフォリオ・関係者との関係の状況を見極める。
- 指示direct
- 戦略を決め、責任を割り当て、方針を定める。
- モニタリングmonitor
- 実績が方針や方向に合っているかを確かめる。
ひっかけ：方針を「決める」＝指示（direct）、守られているか「確かめる」＝モニタリング（monitor）。評価は順守の確認ではない。実際の作業をすることは管理であって、ガバナンスではない。
13. バリューチェーンValue Chain
- バリューチェーンvalue chain
- 価値をつくって届ける、互いにつながった活動の運営モデル。Version 5 では8活動。順番に並んでいるわけではない。
- 運営モデルoperating model
- 組織がどう価値を共創し、どう自分を動かしているかを表すもの。
- インシデントincident
- 計画外のサービス中断、または品質の低下。
- イベントevent
- 意味のある状態の変化。
- サービス要求service request
- あらかじめ合意された、通常の依頼。
- 問題problem
- インシデントの原因、または原因になりうるもの。
- エラーerror
- 欠陥・不具合そのもの。
- 既知のエラーknown error
- 分析が済んだ問題。
- 災害disaster
- 大きな被害を出す突然の出来事。
- リリースrelease
- 使えるようにしたバージョン。
- テストtest
- 要件を満たしているか確かめること。
- 継続的インテグレーションcontinuous integration (CI)
- コードを頻繁にまとめ、自動テストにかけること。
- 継続的デリバリー／継続的デプロイメントcontinuous delivery / continuous deployment
- デリバリー＝いつでも本番に出せる状態を保つ（出すのは判断して）。デプロイメント＝本番への反映まで自動で行う。
- プロダクト仕様product specification
- プロダクトの要件を定めたもの。
- プロダクトのプロトタイプproduct prototype
- アイデアを試すための初期の模型。
- 信頼性reliability
- 時間がたっても意図どおりに動き続ける力。
- SRE／オブザーバビリティsite reliability engineering / observability
- SRE＝ソフトウェア工学のやり方で信頼性を保つ取り組み。オブザーバビリティ＝外に出るデータから、システムの内部状態を理解できる度合い。
| 活動 | 主な成功指標（要点） |
|---|---|
| 発見 Discover | 需要・機会・利用者ニーズをどれだけ理解しているか |
| 設計 Design | 設計が4つの価値特性の要件をどれだけ満たすか |
| 取得 Acquire | 供給者から得た物品・資源の品質 |
| 構築 Build | 仕様どおりに作られ、テストで確かめられたか |
| 移行 Transition | 本番に持ち込んだエラーの数と事業への影響 |
| 運用 Operate／提供 Deliver | 合意したサービスレベルに対する実績 |
| サポート Support | 中断のあと、どれだけ早く通常に戻したか |
ひっかけ：問題（原因）→ 分析済みなら既知のエラー。インシデント（中断・低下）とイベント（状態の変化）、サービス要求（通常の依頼）を混同しない。
14. 管理プラクティスManagement Practices
- 管理プラクティスmanagement practice
- 仕事を行う・目的を果たすための組織の資源（人・プロセス・ツール・情報・パートナー）のまとまり。バリューチェーンの活動に資源を与え、バリューストリームの中で使われる。
- 一般管理プラクティスgeneral management practices
- 一般的な経営管理から取り入れ、組織全体に広く使うプラクティス。
- プロダクトとサービスの管理プラクティスproduct and service management practices
- デジタル・プロダクトとサービスの管理のために特に作られたプラクティス。
- ITIL プラクティス・ガイドITIL Practice Guide
- 1つのプラクティスについての詳しい手引き。目的・主要用語と、4つの側面にそった同じ形式でまとめられている。
- メトリクス（指標）metric
- 管理や改善のために見張ったり報告したりする測定値・計算値。
- 重要成功要因critical success factor (CSF)
- めざす結果を得るために欠かせない前提条件。
ひっかけ：Version 5 のプラクティスは2グループ。個々のプラクティス名の細かい中身は試験範囲外とされる。
15. 継続的改善モデルThe ITIL Continual Improvement Model
| ステップ | やること |
|---|---|
| 1. ビジョンは何か？ What is the vision? | 改善の目的を、組織のビジョンや目標につなげる |
| 2. 現状はどうか？ Where are we now? | 現状を測り、客観的な基準（ベースライン）をつくる |
| 3. どこを目指すのか？ Where do we want to be? | 測れる目標の状態を決める |
| 4. どうやって目標を達成するか？ How do we get there? | 基準から目標へ進む計画を立てる |
| 5. 行動を起こす Take action | 計画を実行する（ふつうは反復して） |
| 6. 目標を達成したか？ Did we get there? | 測定して目標に届いたか確かめる |
| 7. どのように勢いを維持するか？ How do we keep the momentum going? | 成果を定着させ、さらに積み上げる |
ひっかけ：くり返し使う反復のサイクル。ステップ2（基準づくり）と6（結果の確認）を混同しない。7を飛ばさない。継続的改善は「モデル」でもあり、バリュー・システムの「構成要素」でもあり、専用の「プラクティス」もある。改善は全員の責任。
領域 5／7：バリューストリームの特定・マッピング・管理
16. バリューストリームの主要概念Key Concepts of Value Stream Mapping and Management
- バリューストリームvalue stream
- プロダクトやサービスをつくって利用者に届けるための一連の手順。8活動を、特定の場面向けの道筋に組み合わせたもの。
- コア・バリューストリームcore value stream
- 外部の利用者に直接プロダクトやサービスを届ける流れ。
- イネーブリング・バリューストリームenabling value stream
- 社内の受け手に価値を届け、コアの流れを支える流れ。
- バリューストリーム・マッピングvalue stream mapping
- バリューストリームの手順と流れを図にする技法。ある時点の姿を写す。
- バリューストリーム管理value stream management
- バリューストリームを継続的に統制し、最適化する取り組み。
- 複雑性思考complexity thinking
- 仕事の置かれた状況（秩序だった・複雑・混沌）によって、やり方を変える考え方。どこまで標準化し、どこまで試すかの目安になる。
| バリューチェーン | バリューストリーム | プロセス | |
|---|---|---|---|
| 何か | 8活動の運営モデル | 特定のプロダクト・サービス向けの、端から端までの道筋 | 活動の中で使う決まった手順 |
| 範囲 | 組織全体・汎用 | 場面ごと | 再利用できる部品 |
17. バリューストリームの適用Application of Value Streams
- 予測できる（秩序だった）仕事predictable (ordered) work
- 原因と結果がわかっていて、くり返せる仕事。標準化して自動化する。例：パスワードのリセット。
- 複雑な（不確かな）仕事complex (uncertain) work
- 原因と結果があとからしかわからない、新しい仕事。試行・協働・素早いフィードバックで進める。例：新しいデジタル・プロダクトの開発。
ひっかけ：同じ活動が複数のストリームに出てもよいし、1つのストリームに何度出てもよい。需要の種類が違えば別のストリームにする（運用系の例：インシデントの解決、開発系の例：新機能）。複雑な仕事を無理に自動化すると価値が下がる。
18. マッピングと管理の目的Purpose of Value Stream Mapping and Management
- 目的purpose
- 価値の流れを理解し、最適化し、改善し続けること。ムダ・ボトルネック・遅れ・受け渡しを見つけて減らす。
- バリューストリーム・マップvalue stream map
- 手順の順番、仕事と情報の流れ、チーム間の受け渡し、待ち時間、各手順の時間、価値を生む手順とムダな手順を描いた図。ふつうは今の実際の流れを描く。
- リードタイム／待ち時間lead time / waiting time
- 全体にかかる時間と、手が止まっている時間。マップでこれが見えると、改善の的がわかる。
- 付加価値／非付加価値（ムダ）value-adding / non-value-adding (waste)
- 利用者にとって価値を足す手順と、足さない手順。
ひっかけ：マッピング＝時々・ある時点の写真、管理＝継続的。管理はマップの上に「責任者・指標・統制」を加える。マップが気づきを与え、管理がそれを実行に移す。
領域 6／7：ITIL と AI
19. AI 入門Introduction to AI
- 人工知能artificial intelligence (AI)
- ふつうは人の知能が必要な作業をこなす技術。決まったルールに従うだけでなく、学び、推論できる点で従来の自動化と違う。
- AI 成熟度AI maturity
- 組織の AI 活用がどれだけ進み、どれだけきちんと統制されているかの度合い。
- 従来の自動化traditional automation
- あらかじめ決めたルールどおりに手順を実行する。AI ではない。例：決まったルールで依頼を振り分ける。
- 生成 AIgenerative AI (GenAI)
- 文章・画像・コードなど新しいコンテンツをつくる AI。例：ナレッジ記事や返信の下書き。
- エージェント型 AIagentic AI
- 少ない指示で、目標に向かって自分で考え、判断し、行動する AI。人が決めた範囲の中で動き、責任は人に残る。
ひっかけ：生成 AI は「つくる」、エージェント型 AI は「自分で動く」。AI はライフサイクル全体（要件の分析・設計・テスト）とバリューチェーン全体（需要分析・監視・改善）で使える。自動化しても、人が決めた枠の中で動く。
20. ITIL の AI ガバナンスITIL AI Governance
- AI ガバナンスAI governance
- AI を責任をもって、倫理的に、統制のもとで使うための方針・役割・責任・管理策の枠組み。リスク・法令順守・説明責任を扱う。
- 責任ある AIresponsible AI
- 透明性・説明責任・倫理的な利用を重んじる AI の使い方。
- 人による監督human oversight
- AI に任せきりにせず、人が適切に見張り、関わること。
- データ品質／データ・プライバシーdata quality / data privacy
- AI ガバナンスの土台になるもの。
- ITIL AI 能力モデル（6C モデル）ITIL AI Capability Model (6C)
- AI の能力を6つに分類し、それぞれに固有のリスクと管理策を対応させる、評価と育成の道具。6つの名前は公式資料で確認すること。
ひっかけ：AI ツールを導入すること＝ガバナンスではない。6C モデルは能力を「評価・分類」するもの、ガバナンスは使い方を「方向づけ・統制」するもの。
領域 7／7：ITIL とほかのフレームワーク
21. ITIL と DevOpsITIL and DevOps
- DevOpsDevOps
- 開発と運用をつなぎ、価値を途切れず流すための文化とプラクティスのまとまり。ツールではない。自動化と CI/CD が中心。
- CI/CDcontinuous integration / continuous delivery (deployment)
- 頻繁にまとめて自動テストし、いつでも・自動で本番へ出せるようにするやり方。主に構築・移行・提供を速くする。
- 責任の共有shared responsibility
- 開発と運用が、結果への責任を分け合う文化。
ひっかけ：ITIL と DevOps は対立ではなく補い合う。ITIL＝構造・統制・全体の管理、DevOps＝速さと文化。継続的改善は両者の共通の土台（ITIL は継続的改善モデル、DevOps はフィードバックのループ）。
22. ITIL と PRINCE2ITIL and PRINCE2
- プロジェクトproject
- 始まりと終わりが決まった一時的な取り組み。ITIL は変革や大きな変更をプロジェクトに頼る。
- PRINCE2PRojects IN Controlled Environments
- 段階を区切り、役割を決めて進める、構造化されたプロジェクトマネジメント手法。続いているサービスではなくプロジェクトを管理する。
- ビジネス正当性の継続continued business justification
- プロジェクトを続ける理由（事業上の意味）がずっとあることを確かめ続ける、PRINCE2 の土台。
ひっかけ：PRINCE2＝プロジェクト（一時的）、ITIL＝続いているサービス（継続的）。二者択一ではなく補い合う。新しいサービスはプロジェクトで作り、完成したら ITIL で運用・改善する。