別紙1-1. 用語の定義

2026/02/25 公開

1. 用語の定義

本文書における用語の定義を下表に示す。

またGCASガイド全体で利用している共通的な用語については、「はじめにお読みください」の「用語集」に掲載している。本ページの用語と合わせて参照することをお勧めする。

表別紙1-1 本ガイドにおける用語の定義

No	カテゴリ	用語	説明
1	本ガイド固有の定義	運用モダン化	クラウド環境の特性を活かし、協働と学習による継続的改善、自動化による品質向上と効率化、利用者体験を中心とした品質管理を実現する運用の進化。本ガイドの中核概念。
2	本ガイド固有の定義	インシデント	サービス提供に影響を及ぼした事象。本ガイドでは、システム障害やセキュリティ侵害等を含む包括的概念として定義し、ユーザーやサービスの利用に支障をきたす事象全般を指す。
3	本ガイド固有の定義	非インシデント	冗長化や自動復旧などの設計によりサービス提供への影響を回避した事象。障害や異常が発生してもユーザーには影響がなかったもの。
4	本ガイド固有の定義	事象	システム運用中に発生するあらゆる出来事。正常な動作によるものも異常な状態も含む。インシデントと非インシデントの総称。
5	本ガイド固有の定義	インシデント対応チーム	インシデント発生時に、原因究明とサービスの早期復旧を行う担当者の集まり。本ガイドでは、システム障害対応とセキュリティインシデント対応の両方を含む広義の概念として定義。
6	本ガイド固有の定義	技術的恒久対策	インシデントの再発防止のため、人手に依存せず技術的な仕組みで問題を根本的に解決する対策。本ガイドでは、人的リソースに依存する運用回避策ではなく、自動化やシステム設計の改善等を優先することを推奨。
7	インシデント管理	現場指揮官（インシデントコマンダー）	インシデント対応チーム全体を統括し、解決に向けた意思決定を行い、インシデント解決に導く責任者。全権限を委任され、全体を俯瞰して適切な判断を行う。
8	インシデント管理	コミュニケーションリード	各種ステークホルダーとコミュニケーションを取る窓口担当者を取りまとめリードする役割。現場指揮官と連携し、情報を適切にエスカレーションする。
9	インシデント管理	オペレーションリード	インシデントの確認・調査および復旧作業を担う実作業担当者を取りまとめリードする役割。現場指揮官の指示を効果的に実行させる。
10	インシデント管理	ポストモーテム	インシデント発生後に実施する振り返り活動。「失敗」ではなく「学習と改善の機会」として捉え、技術的な恒久対策を策定する。
11	インシデント管理	ブレームレス文化	インシデント発生時に「誰が悪いか」ではなく「何が悪かったか」に焦点を当てる文化。人を責めずシステムやプロセスの改善に注力する考え方。
12	インシデント管理	FMEA（故障モード影響解析）	Failure Mode and Effects Analysisの略。システムに発生しうる障害モードを体系的に洗い出し、その影響度と発生頻度を評価する手法。信頼性設計の妥当性評価に使用される。
13	インシデント管理	5 Whys（5回のなぜ）	「なぜ」を5回繰り返すことで根本原因を特定する分析手法。インシデントの振り返りで根本原因を見つけるために使用される。
14	インシデント管理	CSIRT（Computer Security Incident Response Team）	セキュリティインシデントを対応するチーム。本ガイドのインシデント対応チームは、セキュリティとシステム障害の両方を含む広義の概念として使用。
15	自動化・DevOps	Zero Touch Production	本番環境に人が直接ログインすることなく運用を行う状態。IaCやCI/CDパイプラインによる自動化で、人的ミスとセキュリティリスクを排除する運用形態。
16	自動化・DevOps	パイプライン	ソースコード取得から静的解析、テスト、デプロイまでの一連の処理を自動実行する仕組み。CI/CDの中核となる概念。
17	自動化・DevOps	ブランチ戦略	Gitリポジトリにおけるブランチの作成・管理・統合の運用方針。IaCでは環境（開発・検証・本番）ごとにブランチを用意する方式が一般的。
18	自動化・DevOps	コードレビュー	ソースコードの品質を確保するため、実装者以外の担当者がコードを確認し問題点を指摘するプロセス。IaCでもアプリケーションと同様に実施される。
19	自動化・DevOps	静的解析	プログラムを実行せずにソースコードを分析し、セキュリティリスクやベストプラクティスからの逸脱を検出する手法。IaCのパイプラインで自動実行される。
20	自動化・DevOps	GitHub Flow / GitLab Flow	Gitリポジトリを使った開発フローの代表的な手法。ブランチ戦略の具体的な実装方式として参照される。
21	自動化・DevOps	ロールバック	システムやアプリケーションを以前の正常な状態に戻す操作。デプロイやシステム変更で問題が発生した際に、変更前の状態に復元することで、サービスを迅速に復旧させる。
22	自動化・DevOps	ドリフト	IaCで管理しているインフラの定義（コード）と、実際の環境の状態が乖離すること。手動で設定変更を行うと発生し、IaCの管理が機能しなくなる原因となる。
23	自動化・DevOps	冪等性（べきとうせい）	同じ操作を何回実行しても、結果が同じになる性質。システム運用では、スクリプトやAPIが冪等性を持つことで、実行回数に関わらず安全に操作できる。例：「サーバーを起動する」は冪等（既に起動済みなら何もしない）、「カウンターを+1する」は非冪等（実行毎に値が変わる）。
24	自動化・DevOps	リトライ	処理が失敗した際に、自動的に再試行すること。一時的なネットワーク障害やタイムアウトなど、再試行により成功する可能性がある場合に有効。ただし、無限にリトライしないよう、回数や間隔の制御が必要。
25	自動化・DevOps	Feature Flag	アプリケーションの機能を動的に有効化・無効化できる仕組み。コードのデプロイと機能の公開を分離することで、問題発生時に即座に機能を無効化でき、リスクを低減できる。フィーチャートグルとも呼ばれる。
26	サービス品質管理	SLO（Service Level Objective）	サービスレベル目標。KPIを達成するために、システムが満たすべき具体的な技術的目標値。例：「申請処理の成功率が99%以上」
27	サービス品質管理	SLI（Service Level Indicator）	サービスレベル指標。SLOの達成状況を計測するための具体的な測定方法と計算式。例：「HTTP 5XXエラー数 / 全リクエスト数」
28	サービス品質管理	SLA（Service Level Agreement）	サービスレベル合意。サービス提供者と利用者の間で締結されるサービス品質の保証基準。SLOを基に設定され、契約上の保証水準を示す。
29	サービス品質管理	KGI（Key Goal Indicator）	重要目標達成指標。組織やプロジェクトの最終的な目標を示す指標。KPIの上位概念。
30	サービス品質管理	CSF（Critical Success Factor）	重要成功要因。KGIを達成するために必要となる重要な要素。KGIとKPIの間に位置する概念。
31	サービス品質管理	CUJ（Critical User Journey）	クリティカルユーザージャーニーの略。利用者が達成しようとする最も重要で核となるタスクや目標に至る一連の体験。SLO設定の基礎となる。
32	サービス品質管理	RPO（Recovery Point Objective）	目標復旧時点。障害発生時にどの時点までのデータを復旧させるかの目標値。データ損失の許容範囲を示す。
33	サービス品質管理	RTO（Recovery Time Objective）	目標復旧時間。障害発生からシステムを復旧させるまでの目標時間。サービス停止の許容時間を示す。
34	サービス品質管理	APM（Application Performance Monitoring）	アプリケーション性能監視の略。アプリケーションの性能を監視するツール。レスポンスタイムやエラー回数等を自動収集し、SLI計測に活用される。
35	サービス品質管理	パーセンタイル	データを小さい順に並べたときの位置を示す統計指標。90パーセンタイルは、データの90%がその値以下であることを示す。ばらつきが大きい指標の評価に使用。
36	サービス品質管理	ダッシュボード	SLIやSLOの達成状況をリアルタイムで可視化するツール。関係者間での情報共有と問題の早期発見を支援する。
37	サービス品質管理	PITR（Point-in-Time Recovery）	ポイントインタイムリカバリの略。データベース等を任意の過去の時点の状態に復旧する機能。定期バックアップでは復旧できない、バックアップ間の時点への復旧が可能になる。
38	組織・体制	仕様内製型	事業者への依存が大きく、仕様策定等を職員が担当するプロジェクト形態。インシデント対応では事業者が現場指揮官を担うことが多い。
39	組織・体制	ブリッジ型	職員が要件定義や設計の主要部分を担当し、事業者が開発チームとして参画するプロジェクト形態。職員が現場指揮官を担うことが望ましい。
40	組織・体制	完全内製型	職員のみで開発と運用を行うプロジェクト形態。職員がインシデント対応の全てを担当する。
41	設計・アーキテクチャ	SPOF（Single Point of Failure）	単一障害点。システムの中で、そこが故障するとシステム全体が停止してしまう箇所。冗長化設計により排除すべき要素。
42	設計・アーキテクチャ	オートスケール	システムの負荷に応じて、自動的にリソース（サーバーインスタンス等）を増減させる仕組み。負荷急増への自動対応を実現する。
43	設計・アーキテクチャ	冗長化	システムの重要な構成要素を複数用意し、一部が故障してもサービスを継続できるようにする設計手法。可用性向上の基本的アプローチ。
44	設計・アーキテクチャ	フェイルオーバー	稼働中のシステムに障害が発生した際、自動的に予備システムに切り替える仕組み。データベース等で特に重要。
45	設計・アーキテクチャ	サーキットブレーカー	障害が発生したコンポーネントへのリクエストを一時的に遮断し、障害の連鎖を防ぐ設計。カスケード障害の防止に有効。
46	設計・アーキテクチャ	カスケード障害	1つのコンポーネントの障害が連鎖的に他のコンポーネントに波及していく現象。サーキットブレーカー等で防止する。
47	設計・アーキテクチャ	ヘルスチェック	システムやアプリケーションが正常に動作しているかを定期的に確認する仕組み。異常検知時に自動再起動等の対応を行う。
48	設計・アーキテクチャ	バルクヘッドパターン（Bulkhead Pattern）	システムを複数の独立した区画に分割し、一部の障害が全体に波及しないようにする設計パターン。障害影響の局所化に使用される。
49	その他重要概念	耐障害性ゾーン	クラウドコンピューティングにおける主要な概念の一つであり、クラウドプロバイダーによって提供される、独立した障害ドメイン（物理的な場所やインフラストラクチャ）を指す。システムの冗長化設計において、高可用性を実現する場合は、２つ以上の耐障害性ゾーンでシステムを構成することが重要である。耐障害性ゾーンは、AWSとAzureではAvailability Zone、Oracle Cloud InfrastructureではAvailability Domain、Google CloudとさくらクラウドではZone、と呼ぶ。
50	その他重要概念	リージョン	CSPが提供するサービスの地理的な提供単位。複数の耐障害性ゾーンで構成される。災害対策では複数リージョンの活用を検討する。
51	その他重要概念	パラメータシート	Excelや Word等にインフラの設定値を記載し、手動作業でインフラ設定を行う従来の管理方法。IaCへの移行により不要になる。
52	その他重要概念	外形監視	ネットワークの外部から実際の利用者と同様の方法でシステムにアクセスし、動作を確認する監視手法。利用者視点での品質確認に有効。
53	その他重要概念	アラート疲れ（Alert Fatigue）	過剰なアラート通知により、重要なアラートを見逃したり対応が遅れたりする状態。通知頻度の最適化（一般に5件/週以内）により防止する。
54	その他重要概念	V字モデル	各設計段階に対応するテスト段階を定義し、設計で意図した内容がテストで検証されることを確保する開発プロセスモデル。信頼性設計の検証に活用。
55	その他重要概念	スクラム	アジャイル開発手法の一つ。短い期間（スプリント）で反復的に開発を進める。本ガイドでは2章のGCASにおける事例の説明で言及。

← 運用モダン化実践ガイドに戻る