ITサービスマネージャ試験 のナレッジマップ
ITサービスマネージャ試験 の主要概念 48 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。
概念一覧（48）
インシデント管理
サービスの計画外の中断や品質低下（インシデント）に対し、合意されたサービスレベル内でできるだけ迅速にサービスを回復させることを目的とするプロセス。記録・分類・調査・回復・クローズという流れで進め、暫定回避策も用いる。根本原因の究明は問題管理の役割であり、インシデント管理はあくまで復旧を最優先する。
前提: サービスの計画（サービスマネジメントの計画）、ワークアラウンド（暫定回避策）
関連: 問題管理
ITIL
ITサービスマネジメントにおけるベストプラクティスをまとめたフレームワーク。インシデント管理や変更管理などサービス運用の進め方を体系化する。最新のITIL 4（2019年）では、価値共創を中心とする「サービスバリューシステム（SVS）」と34の「プラクティス」に再構成されている（従来のプロセス群はプラクティスとして継承）。
稼働率
システムが正常に稼働している時間の割合。稼働率＝MTBF÷(MTBF＋MTTR) で求められ、故障間隔が長く修復時間が短いほど高くなる。可用性の代表指標で、SLA の合意値（例 99.9%）としても用いる。
前提: 平均故障間隔（MTBF）
構成品目（CI）
構成品目（CI）は、構成管理の対象として個別に識別・管理される構成要素で、ハードウェア・ソフトウェア・文書・サービスなど多様な粒度を取り得る。各CIは属性（種別、版数、状態など）を持ち、他のCIとの相互関係を通じてサービス構成を形づくる。ITサービスマネージャはどこまでをCIとして管理するか（管理粒度）を設計し、細かすぎて維持できない状態と、粗すぎて影響分析に使えない状態の均衡を判断する。
問題管理
一つ以上のインシデントの根本原因（問題）を特定し、恒久的な対策と再発防止を図るプロセス。すでに発生したインシデントに反応するリアクティブと、傾向分析などで未然に防ぐプロアクティブの両面をもつ。迅速な回復を狙うインシデント管理とは目的が異なり、原因除去に主眼を置く。
関連: インシデント管理
インシデント管理と問題管理
インシデント管理は、発生した障害を迅速に検知し、サービスをできるだけ早く復旧させる活動。問題管理は、インシデントの根本原因を特定し、再発防止策を講じる活動。目的（早期復旧 vs 再発防止）が異なる点が重要。
平均故障間隔（MTBF）
修理して使い続けるシステムで、ある故障から次の故障までの平均稼働時間。値が大きいほど故障しにくく信頼性が高い。総稼働時間÷故障回数で算出する。
ヘルスチェック
ロードバランサや冗長化構成において、配下のサーバや機器が正常に応答可能かを定期的に確認する仕組み。TCP接続確立の可否を見るL4ヘルスチェックと、HTTPリクエストを送信しステータスコードや応答内容まで検証するL7ヘルスチェックがあり、異常検知した対象は振り分け・切替の対象から自動的に除外される。
前提: フェールオーバーとフェールバック
関連: ロードバランサ（L4/L7）
可用性管理（サービスマネジメントの）
合意した目標可用性を満たすようサービスと構成品目を設計・測定・改善する活動。稼働率は平均故障間隔と平均修復時間から稼働率＝MTBF÷（MTBF＋MTTR）で求め、直列構成では各要素の可用性の積、並列（冗長）構成では1−（1−a）のn乗で全体の可用性を評価する。単一障害点（SPOF）を排除して冗長化することが設計の要点となる。ITサービスマネージャは目標可用性を監視し、冗長化の投資対効果を判断する。
変更のリスク評価と切り戻し（バックアウト）
変更を実施する前に、その変更がサービスや他の構成品目へ及ぼすリスクと影響を評価し、失敗時に変更前の状態へ確実に戻すための切り戻し（バックアウト）計画を必ず用意しておく統制。切り戻し計画には手順・所要時間・判断基準（いつ中止して戻すか）を含め、実施可能であることを事前に確認する。ITサービスマネージャは切り戻し計画の存在と実効性を変更承認の前提条件とし、稼働中サービスの可用性を守る判断を行う。
前提: 構成品目（CI）
CMDB（構成管理データベース）
CMDB（構成管理データベース）は、構成品目（CI）とその属性、およびCI間の相互関係を記録するデータベースで、構成管理の中核となる情報基盤である。変更やリリースの影響分析、インシデントの原因追跡、サービス構成の可視化に用いられ、情報の正確さと最新性が価値を左右する。ITサービスマネージャはCMDBの記録範囲と更新プロセスを設計し、変更管理と連動して実態との乖離（ドリフト）を防ぐことで、影響評価の信頼性を担保する。
前提: 構成品目（CI）
ITIL4の7つの指針原則
あらゆる状況で適用できるITIL4の行動指針で、価値に着目する・現状からはじめる・フィードバックをもとに反復して進化する・協働し可視性を高める・包括的に考え取り組む・シンプルにして実践的にする・最適化し自動化するの7つから成る。組織の目的や構造に依存せず普遍的に使える。サービスマネージャは改善や意思決定の場面でこれらを判断の拠りどころとし、過剰設計や局所最適を避ける。
サービスバリューチェーン（SVC）
SVSの中核をなす一連の相互接続した活動で、計画・改善・エンゲージ・設計及び移行・取得及び構築・提供及びサポートの6活動から成る。個々の需要ごとにこれらの活動を柔軟に組み替えてバリューストリームを形成し、価値を生み出す。サービスマネージャは対象サービスの要求に応じてどの活動をどう連結するかを設計し、無駄のない価値提供の流れを組み立てる。
前提: 要求実現（サービス要求）
既知の誤り（KEDB）
根本原因または回避策が判明した問題を「既知の誤り」と呼び、それらを蓄積した情報基盤が既知の誤りデータベース（KEDB）である。KEDBを参照することでサービスデスクや技術チームは既知の障害に対する回避策を即座に適用でき、インシデントの迅速な回復に役立つ。
関連: ワークアラウンド（暫定回避策）
要求実現（サービス要求）
計画外の中断ではなく、あらかじめ手順・承認・コストが定められた定型的な利用者要求（アカウント発行、標準ソフトウェアの導入、情報提供など）を処理するプロセス。障害対応であるインシデント管理や、変更管理を要する非定型の変更とは区別して扱う。
前提: インシデント管理
サービスの計画（サービスマネジメントの計画）
サービスマネジメントを効果的に運営するために、方針・目的・提供範囲・必要資源・役割責任・スケジュールをあらかじめ定める活動。JIS Q 20000のPDCAではPlanに相当し、以降の運用・監視・改善の土台となる。サービスマネージャは事業目標や顧客要求を計画に落とし込み、限られた資源をどのサービスにどう配分するかを決め、後続のプロセスが整合して動く前提を整える。
ワークアラウンド（暫定回避策）
根本原因を除去する恒久対策が完了する前に、サービスを一時的に回復・維持するために用いる暫定的な回避策。インシデントの影響を軽減して業務を継続させる目的で適用し、有効な回避策はKEDBに記録して再利用する。
関連: 既知の誤り（KEDB）
サービスデスク
利用者からの問い合わせ・障害報告を受け付ける単一の窓口（シングルポイントオブコンタクト）。利用者が複数の連絡先を使い分ける必要をなくし、対応の一元管理を可能にする。
SLAとSLM
SLA（サービスレベル合意書）は、サービス提供者と利用者の間でサービス品質の水準（稼働率や応答時間など）を取り決めた合意文書。SLM（サービスレベル管理）は、SLAの内容を継続的に監視・見直しする活動。
前提: 稼働率、サービスレベル管理（SLM）
平均修復時間（MTTR）
故障が発生してから復旧するまでの平均時間。値が小さいほど早く復旧でき、保守性（メンテナンス性）が高い。総修復時間÷故障回数で算出する。稼働率＝MTBF÷(MTBF＋MTTR) の分母に含まれ、MTBF（平均故障間隔）と対にして信頼性・保守性を評価する。
前提: 稼働率、平均故障間隔（MTBF）
ロードバランサ（L4/L7）
複数サーバへ負荷を分散する装置。L4ロードバランサはIPアドレスとポート番号までで振り分ける。L7ロードバランサはHTTPのURLパスやCookie等アプリケーション層の情報を解釈でき、パスベースの振り分けやCookieによるセッション維持（パーシステンス）を実現する。ヘルスチェックで異常サーバを自動的に振り分け対象から除外する。
関連: ヘルスチェック
構成管理
成果物・文書・ベースラインのバージョンを識別・記録し、承認された変更のみを反映して整合性を保つ活動。統合変更管理と連携し、どの版が正式なベースラインかを常に一意に追跡できるようにする点で重要。
前提: 統合変更管理
RPO（目標復旧時点）
障害発生時にどの時点のデータまで復旧できればよいかという目標値。RPOが短いほど許容できるデータ損失が少なく、より高頻度なバックアップやレプリケーションが必要になる。RTO（復旧までの時間）とセットでBCPの目標を定める。
RTO（目標復旧時間）
障害や災害の発生からどれだけの時間内に業務やシステムを復旧させるかという目標値。RPO（どこまでのデータ時点に戻すか）とは異なる軸で、BCPやDR計画のバックアップ方式・復旧手順を決める基準になる。
変更の種別（標準・通常・緊急変更）
サービスマネジメントにおける変更を承認経路とリスクで分類した3種別。標準変更は事前承認済みの低リスクな定型変更で都度の承認が不要、通常変更はCABがリスク・影響・スケジュールを評価してから承認、緊急変更はサービス停止など切迫した事態に対しECABが迅速に承認し事後に文書化する。ITサービスマネージャは各変更を適切な種別に振り分け、標準変更を増やすことで承認の遅延と評価コストを下げつつ統制を保つ判断が求められる。
構成管理（サービスマネジメントの）
サービスを構成する構成品目（CI）を識別・記録・管理し、CI間の相互関係を把握する活動。正確な構成情報を維持することで、変更やリリースの影響分析、インシデントの原因追跡、可用性設計の根拠となる。財務価値の把握を主目的とするIT資産管理とは目的が異なり、構成管理はサービス提供に必要な関係と状態の正確さを主眼とする。ITサービスマネージャは構成情報の正確さと鮮度を保つ統制を設計し、他の管理活動がそれを信頼して判断できる状態を維持する。
前提: 構成品目（CI）
イベント管理
監視ツールが検知したサービスや構成要素の状態変化（イベント）を、正常を示す情報・注意を要する警告・対応が必要な例外に分類し、適切な対応へつなぐプロセス。しきい値監視によりインシデントの予兆を早期に捉え、自動対応や通知の起点となる。
ITILの4つの側面
サービスと価値を効果的に成立させるために欠かせない4つの観点で、組織と人材・情報と技術・パートナと供給者・バリューストリームとプロセスから成る。どれか一つでも欠けるとサービスの価値が損なわれるため、全側面をバランスよく点検する必要がある。サービスマネージャは新サービスや改善の検討時に、技術だけでなく人材や供給者、業務の流れまで漏れなく評価する。
前提: ITIL
サービスバリューシステム（SVS）
ITIL4の中核概念で、需要と機会を入力として価値を出力する組織全体の仕組み。中心にサービスバリューチェーンを置き、その周囲を7つの指針原則・ガバナンス・継続的改善・プラクティスが取り囲む。サービスマネージャは個々の活動を局所最適するのではなく、需要から価値創出までの全体像をSVSとして俯瞰し、部分間の整合をとって運営を判断する。
ITサービス継続管理（ITSCM）
ITSCM（ITサービス継続管理）は、災害や大規模障害などの事態が起きても、合意したRTO（目標復旧時間）およびRPO（目標復旧時点）の範囲内でサービスを復旧できるよう、継続計画の策定・維持・演習を行う活動で、事業継続計画（BCP）の一部を担う。復旧手段・代替設備・優先復旧順序を事前に定め、定期的な演習で計画の実効性を検証する。ITサービスマネージャは事業影響度分析に基づいて復旧目標を定め、投資と復旧速度の均衡を判断する。
最大許容停止時間（MTPD/MAO）
最大許容停止時間（MTPD、またはMAO：最大許容停止時間）は、事業が受容できるサービス停止の最大の長さで、これを超えると事業へ回復不能または深刻な損害が及ぶ限界を表す。復旧目標であるRTO（目標復旧時間）は、余裕を持たせるためMTPD/MAOより短く設定しなければならない。ITサービスマネージャは事業影響度分析からMTPD/MAOを見積もり、それを上限としてRTOと復旧戦略・投資を設計する判断を行う。
前提: RTO（目標復旧時間）
リリース及び展開管理
承認された変更を本番環境へ提供するために、リリース単位でビルド・テストを行い、計画に沿って展開する活動。展開方式には一斉展開、段階展開、パイロット（先行）展開があり、リスクと影響範囲に応じて選ぶ。ビルド・テストと本番展開を分離し、リリースパッケージの品質を確認してから展開することで、失敗の影響を限定する。ITサービスマネージャはリリース単位と展開方式を設計し、切り戻しやサービス停止時間を織り込んで移行を統制する。
サービスデスクとSPOC（単一窓口）
サービスデスクは利用者とサービス提供者をつなぐ単一の連絡窓口（SPOC）として機能し、問い合わせや障害連絡を一元的に受け付ける。窓口を一つに集約することでたらい回しを防ぎ、記録・状況把握・オーナーシップを一元管理して対応品質と利用者満足を高める。
サービスレベル管理（SLM）
SLA（サービスレベル合意）の策定・監視・レビュー・改善を継続的に回すプロセス。合意したサービスレベル目標に対する達成状況を測定し、未達や変化があればレビューを通じて是正や再交渉につなげる。サービスマネージャはSLMを通じて顧客期待と提供能力の均衡を保ち、OLAやUCといった裏側の合意がSLA目標を支えられているかを点検する。
前提: サービスレベル目標（SLO）
フェールオーバーとフェールバック
フェールオーバーは主系に障害が生じたとき、処理を自動的に待機系へ切り替えて可用性を維持する仕組み・動作を指す。フェールバックは主系が復旧した後、待機系で継続していた処理を本来の主系へ戻すことをいう。システムアーキテクトはフェールオーバー時のデータ整合性やセッション引継ぎ、フェールバック時の再切替に伴う瞬断を設計上考慮する。
継続的サービス改善（CSI）
KPIやメトリクスの測定結果をもとに、サービスとプロセスを継続的に見直し改善していく取組み。現状測定・目標との差分分析・改善策の実施・効果確認をPDCAとして繰り返す。サービスマネージャは思いつきの改善ではなく、データに基づいて改善対象の優先順位を判断し、小さな改善を積み重ねてサービス価値を継続的に高める。なお「CSI（継続的サービス改善）」はITIL v3の専用ライフサイクル段階の用語であり、ITIL4では独立した段階ではなく指針原則・実践としての『継続的改善（Continual Improvement）』へ発展的に統合されている。
前提: ITIL、ITIL4の7つの指針原則
JIS Q 20000とサービスマネジメントシステム（SMS）
サービスマネジメントシステム（SMS）は、サービスマネジメントの方針・目的・計画・プロセスを体系化した仕組みで、PDCAサイクルで運用・改善する。JIS Q 20000-1はSMSに対する要求事項を定めた規格で、第三者認証の基準となる。ITILがベストプラクティス集であるのに対し、JIS Q 20000は満たすべき要求事項という位置づけの違いがあり、サービスマネージャは両者を目的に応じて使い分ける。
前提: ITIL
ナレッジ管理（SKMS）
既知の誤り、対応手順、FAQといったナレッジを組織的に蓄積・共有し、対応の効率と品質を高めるプロセス。これらを支える情報基盤がサービスナレッジ管理システム（SKMS）で、必要な情報を適切な担当者へ適時に届け、判断の再現性と一次解決率の向上を狙う。SKMSはCMS（構成管理システム）やCMDBを包含する上位の知識基盤（DIKWモデル＝データ・情報・知識・知恵の階層に基づく）であり、既知の誤りそのものは主にKEDB（既知の誤りデータベース）で管理される。
プロアクティブ問題管理
インシデントが発生する前に潜在的な原因を見つけ出し、除去してインシデントの発生を未然に防ぐ問題管理の側面。過去のインシデント傾向分析や監視データの分析から弱点を特定し、対策を先手で講じる。発生後に反応するリアクティブ問題管理と対をなす。
前提: 問題管理
サービスレベル目標（SLO）
SLAの中で顧客と合意する、測定可能なサービスレベルの目標値。可用性や応答時間、復旧時間などを具体的な数値やしきい値として定め、達成状況を客観的に判定できるようにする。サービスマネージャは実現可能かつ顧客価値に見合うSLOを設定し、監視で達成度を測り、未達傾向があれば改善や合意見直しの判断材料とする。
キャパシティ管理とボトルネック診断
回線・機器のトラフィック量や利用率を継続的に監視し、将来の増設要否を予測・計画するプロセス。ボトルネック診断では、経路上の各区間の利用率・遅延・廃棄率を比較し、最も処理能力に対する負荷率が高い（待ち行列理論上ρが1に近い）区間を特定して増強対象を絞り込む。SNMPやNetFlow等によるトラフィック統計収集が実務上の基礎データとなる。
前提: SNMP
SNMP
ネットワーク機器を監視・管理するプロトコル。マネージャがエージェントへ定期的に問い合わせるポーリング（GET）に加え、エージェントが事象発生時に自発的に通知するトラップを持つ。管理情報はMIB（OIDで識別）で構造化される。SNMPv3は認証と暗号化を備え、平文のコミュニティ名に依存する v1/v2c の弱点を解消する。
統合変更管理
変更要求を受け付け、影響範囲（スコープ・スケジュール・コスト・品質）を評価し、変更管理委員会などで承認・却下・保留を決定してベースラインへ反映するプロセス。無秩序な変更（スコープクリープ）を防ぎ、変更の影響を組織全体で一貫して管理する点で重要。
クラスタリング（HAクラスタ・負荷分散クラスタ）
複数のサーバを相互に連携させ、利用者からは1つのシステムとして見えるよう束ねる技術。HA（高可用性）クラスタは一部ノードが障害でも他ノードへフェールオーバーして稼働を継続することを目的とし、負荷分散クラスタは要求を複数ノードに振り分けてスループットと同時処理能力を高めることを目的とする。システムアーキテクトは可用性要求か性能要求かに応じて構成を選び、共有ディスクの有無やスプリットブレイン対策を設計する。
前提: フェールオーバーとフェールバック
SIEM（セキュリティ情報イベント管理）
ファイアウォール・IDS/IPS・サーバー・エンドポイントなど複数の機器から出力されるログを一元的に収集・相関分析し、単体のログでは気付けない攻撃の兆候をアラートとして可視化する仕組み。SOCの監視業務の中核基盤となる。
前提: イベント管理
CAB（変更諮問委員会）とECAB
CAB（変更諮問委員会）は通常変更のリスク・影響・スケジュールを評価し、実施可否を助言する常設の会議体で、技術・業務・利用者など関係する立場を集めて意思決定を支える。ECAB（緊急変更諮問委員会）はCABを招集する余裕がない緊急変更のために、必要な少数の権限者だけで構成し迅速に承認する小規模編成である。ITサービスマネージャはCABの付議基準と構成を設計し、緊急時にはECABへ切り替えて評価の質と速度を両立させる。
インシデントのライフサイクル
インシデントが検知・記録されてからクローズされるまでの一連の段階。検知・記録、分類と優先度付け、調査・診断、解決・回復、クローズという流れで進む。各段階を確実に踏むことで対応漏れを防ぎ、履歴を残して問題管理やナレッジ蓄積に活用する。
前提: 問題管理
サービス資産管理（SACM）
SACM（サービス資産管理及び構成管理）は、サービス提供に用いるサービス資産と、その構成情報を一体で管理する活動である。資産の識別・管理と、構成品目（CI）およびCI間の相互関係の管理を統合し、変更・リリースの影響分析や統制の基盤とする。ITサービスマネージャは資産と構成の記録を単一の正として維持し、実態との乖離を防ぐプロセスを設計することで、意思決定が信頼できる情報に基づくよう担保する。
前提: 構成品目（CI）