ミッションクリティカルとは、停止、機能低下、誤作動が人命や利用者・企業の損失に直結し、継続的な正常稼働を最優先するシステムや業務のことです。ビジネスクリティカルやセーフティクリティカルとの関係は、財務・安全への影響や、出典が採用する分類体系によって異なります。いずれにしても「止められない」と言うだけでは設計は決まりません。本記事では、意味と違いを押さえたうえで、年間停止時間、RTO、RPO、MTBF・MTTRに落とし込み、実際の障害事例から冗長化の落とし穴と採用の境界を判断できる形に整理します。
まとめ
- ミッションクリティカルかどうかは、技術や規模ではなく、停止時の金銭的損失、人命・安全への影響、法令・監督上の要請、代替手段の有無で判定します。
- 人命に関わる場合はセーフティクリティカル、組織内の損失にとどまる場合はビジネスクリティカルと呼び分けることがありますが、境界は出典ごとに異なります。社内では言葉ではなく影響度と数値で定義します。
- IPAの非機能要求グレードは、社会的影響の大きさで稼働率99%・99.99%・99.999%の3類型を置いています。99.999%は年間約5分の停止です。
- 稼働率だけでは要件不足です。RTOで停止許容時間、RPOで許容できるデータ損失の時点を定めます。
- 東証arrowheadは二重化していても切替の設定値で終日停止し、CrowdStrikeの事例では同じ配信が多数の端末に同時に届きました。冗長化は切替と障害の独立性まで試験して初めて効きます。
- 冗長化や地理分散は、安全上の要件と法令・監督上の要請を満たしたうえで、停止リスクの低減効果と追加コストを比較して採用範囲を決め、採用しない機能は残存リスクを明記します。
ミッションクリティカルの意味と判定基準
停止・機能低下・誤作動で判定するNTTの定義
NTT技術ジャーナル2005年12月号は、停止だけでなく、機能低下と誤作動も判定対象に含めています。影響が人命の喪失や利用者・企業の損失に直結し、継続的な正常稼働が最優先されるものがミッションクリティカルシステムです。売上に関係するという理由だけで、すべての業務システムが該当するわけではありません。
実務では、停止時の損失額、安全への影響、契約違反、監督上の要請、代替手段の有無を確認します。翌営業日に手作業で処理でき、損失も限定される社内ツールに五つの9を求める設計は過剰です。反対に、短時間の誤作動でも人命や決済に影響する機能は、利用時間が短くても対象になります。
金融・製造・医療・交通・通信の業界別対象
金融では勘定系や決済、製造では生産制御、医療では診療を支えるシステム、交通では鉄道の運行管理や航空管制、通信ではネットワーク制御が代表例です。名称ではなく停止結果で判断します。たとえば金融庁の中小・地域金融機関向け監督指針II－3－4－1－2（9）は、業務への影響が大きい重要システムについて、オフサイトバックアップ等を事前に用意し、障害時に速やかに業務を継続できる態勢を求めています。
金融決済では復旧期限も具体的です。主要行等向け監督指針III－8－2は、特に重要な金融決済機能を当日中に再開する計画かを着眼点にしています。金融システムの監視や夜間処理の考え方は、金融システムの運用とは？24時間365日監視・夜間バッチ運行と委託範囲の決め方でも解説しています。
NISTとMicrosoftに見るミッションクリティカルなワークロードの範囲
NIST CSRC Glossaryは、NIST SP 800-60 Vol.1 Rev.1を出典に、国家安全保障システム、または情報の喪失・悪用・開示・不正アクセス・改変が政府機関の任務に重大な支障（debilitating impact）を与える情報を処理する通信・情報システムをmission criticalとしています。政府機関向けの定義ですが、任務への影響で範囲を切る考え方は民間でも使えます。
クラウドの設計ガイドでは、対象を「システム」より細かい単位で呼びます。MicrosoftのAzure Well-Architected Frameworkのミッションクリティカルなワークロードは、ワークロードを共通のビジネスプロセスを支えるアプリケーションリソースの集まりと定義し、ミッションクリティカルという語を、利用不能や性能不足に伴う重大な財務コスト（ビジネスクリティカル）または人的コスト（安全性クリティカル）を表す重要度スケールとして説明しています。「ミッションクリティカルなアプリケーション」も、1本のプログラムではなく、API、データストア、ネットワークを含む一続きの業務機能として範囲を決めます。
ビジネスクリティカル・セーフティクリティカル・ノンミッションクリティカルとの違い
停止時の影響で並べた4つの区分
MicrosoftはAzureのゾーン冗長化ガイドで、ワークロードに重要度を付ける4段階の分類例（Mission-critical、Business-critical、Business-operational、Administrative）を示しています。次の表は、Microsoftの下位2区分をまとめ、安全への影響を表すセーフティクリティカルを比較用に併記したものです。各行は相互排他的な順位ではなく、セーフティクリティカルとミッションクリティカルは重なる場合があります。
| 区分 | 停止したときの影響 | 例 |
|---|---|---|
| セーフティクリティカル | 重傷・人命の喪失につながり得る | 飛行制御、緊急通報 |
| ミッションクリティカル | 事業の壊滅的な損害か人命へのリスク | 勘定系、決済、運行管理 |
| ビジネスクリティカル | 一定の金銭的損失やブランド毀損 | 受発注、顧客管理 |
| 業務補助・管理系 | ある程度の停止を許容できる | 社内ポータル、分析 |
セーフティクリティカルの定義には、たとえばNASA-STD-8739.8Bの「不適切に実行・構築されたり未修正のまま残されたりすると、重傷、重大な損害、任務の失敗を引き起こし得るもの」があります。ノンミッションクリティカルは、ITmediaの情報システム用語事典によると、ジェフリー・ムーアのコア／コンテキスト分析の用語で、ミッションクリティカル業務以外のすべて、つまり失敗しても企業の存続や成長に直接深刻なダメージを及ぼさない業務を指します。ただし、ムーアの業務分類と上のMicrosoftの重要度分類は別の枠組みであり、ビジネスクリティカル以下を一律に対応付けることはできません。
出典によって変わるビジネスクリティカルの位置
ビジネスクリティカルがミッションクリティカルより下なのか、その一部なのかは、出典によって違います。IT用語辞典 e-Wordsは、社会インフラの停止のような深刻な社会的損失にはつながらないが、その組織にとって致命的に重要なものをビジネスクリティカルと呼ぶ場合があると説明します。IBMは、障害時に利用者が頼れる代替手段があるかどうかで両者を分けています。一方、前述のAzure Well-Architected Frameworkは、ビジネスクリティカルをミッションクリティカルという重要度スケールの一部として扱います。
用語の定義をそろえる作業に時間をかける必要はありません。社内の分類表では区分名の横に「停止許容時間」「データ損失の許容範囲」「代替手段」を必ず書き、区分名だけで要件が決まる状態を避けます。発注先との会話でも、「ビジネスクリティカルだから」ではなく「RTO 4時間、RPO 15分」のように数値で伝えた方が見積もりがぶれません。
可用性を数値化する稼働率・RTO・RPO
IPA非機能要求グレードのモデルシステム3類型
日本のシステム開発で区分の物差しとして使いやすいのが、IPAの非機能要求グレード2018です。グレード表のモデルシステムシートは、社会的影響の大きさで3つの典型を置き、それぞれに稼働率の目安を付けています。
| モデルシステム | 稼働率 | 復旧時間・復旧地点の例 |
|---|---|---|
| 社会的影響が殆ど無い | 99% | 週次バックアップから |
| 社会的影響が限定される | 99.99% | 1営業日以内 |
| 社会的影響が極めて大きい | 99.999% | 数時間で障害発生時点まで |
「社会的影響が極めて大きいシステム」は、国民生活・社会経済活動の基盤となり、不特定多数の人が利用するインフラシステムを想定しており、大規模災害時はDRサイトでの業務継続が求められます。狭い意味のミッションクリティカルはこの類型に当たります。企業内の基幹システムを想定した「影響が限定される」類型でも稼働率は99.99%で、社外の取引先に影響が出る基幹業務は、ここを出発点にレベルを上下させます。具体的な使い方はIPAの非機能要求グレードとは？6大項目238メトリクスとグレード表の使い方で解説しています。
99.9%と99.99%で変わる年間停止時間
IPAの3類型の間にある99.9%を含めて年間停止時間に直すと、次のとおりです。9が1つ増えるごとに許容停止時間は10分の1になります。表は平年365日を基準にした概算です。
| 稼働率 | 年間停止時間 | 目安 |
|---|---|---|
| 99% | 約87.6時間 | 約3.65日 |
| 99.9% | 約526分 | 約8時間46分 |
| 99.99% | 約53分 | 1時間未満 |
| 99.999% | 約5分 | 五つの9 |
99.999%は目標値として見栄えがよい一方、保守作業を含むか、計画停止を除くかで実績は変わります。業務が許容できる停止時間から逆算し、測定範囲と除外条件を合意しなければ、稼働率だけを掲げても運用判断には使えません。
NIST SP 800-34 Rev.1に基づくRTOとRPOの分離
NIST SP 800-34 Rev.1では、RTOは許容不能な影響が生じるまでシステム資源が利用不能でいられる最大時間、RPOは障害後にデータを復旧すべき障害発生前の時点です。RTOは「いつまでに再開するか」、RPOは「どこまでのデータを戻すか」と分けると混同しません。
当日中の再開を求める業務でも、直前の取引データを失ってよいとは限りません。逆に、データ更新が少ない処理はRPOを長く取れても、利用者向け機能のRTOは短い場合があります。バックアップ頻度だけでなく、復元手順と切替時間を別々に決めます。
ISO/TR 12489:2013によるMTBF・MTTRと稼働率
ISO/TR 12489:2013の3.1.30と3.1.31は、MTBFを修理可能なアイテムで連続する故障間の期待時間、MTTRを故障したアイテムの修理達成までの期待時間と定義しています。IBM Cloud DocsはMTBFを平均稼働時間、MTTRを平均修復時間として扱い、次の式を示します。これは修復時間を含むISO/TR 12489:2013のMTBF定義とは異なる慣用です。
可用性 = MTBF / (MTBF + MTTR)可用性を上げる道は二つあります。故障間隔を延ばすか、修復時間を短くするかです。故障を完全に防ぐ設計だけに費用を寄せず、監視、切替、自動復旧、交換手順によってMTTRを縮める方が費用対効果に合う場合があります。MTTRの詳しい計算はMTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策を実装目線で解説【2026年版】を参照してください。
冗長化していても止まった障害事例
東証arrowhead 2020年10月1日の自動切替不全
東京証券取引所の売買システムarrowheadは、2020年10月1日に終日売買を停止しました。日本取引所グループが2020年11月30日に公表した調査委員会の報告書によると、共有ディスク装置（NAS）1号機のメモリ故障に対し、2号機への自動切替が働きませんでした。要件定義書は機器故障時も30秒以内の切替完了を求めていましたが、「オンパニック」という設定値がFalseになっていたため、パニック通知を受けた2号機で即時・標準のどちらのテイクオーバーも発動しなかったと報告書は説明しています。
報告書は、製品仕様の変更後もマニュアルが改訂されず、従来の設定を踏襲したことや、パニック通知を伴う故障条件を試験していなかったことも指摘しています。機器を2台並べても、想定した故障の種類ごとに切替を試験していなければ、二重化は計算上の可用性にとどまります。
全銀システム2023年10月10日の中継コンピュータ障害
全国銀行データ通信システムでは、中継コンピュータ（RC）を新機種へ移行した直後の営業日、2023年10月10日に障害が起きました。全銀ネットとNTTデータの2023年12月1日の報告によると、10の加盟金融機関と全銀システムの間でテレ為替業務が全面的にできなくなりました。原因は、テーブル作成処理で一時的に確保する作業領域が不足し、内国為替制度運営費の付加・チェック処理が異常終了したことです。
代替手段は計画どおり用意されていました。それでも、2023年10月18日公表の資料では、媒体やデータファイルの用意に通常想定以上の時間がかかり、10月11日の通信終了時点で、影響を受けた金融機関が送信側となる取引のうち10日分49万件、11日分38万件（いずれも概算）が未処理でした。代替手段は「ある」だけでなく、実際の取引量を処理できる速さで回るかまで訓練しておく必要があります。
CrowdStrike 2024年7月19日の同時配信障害
2024年7月19日、CrowdStrikeがFalconセンサー向けに配信した設定データ（Rapid Response ContentのChannel File 291）により、多数のWindows端末が停止しました。Microsoftの2024年7月20日のブログは、影響を受けた端末を850万台、全Windows端末の1%未満と推計しています。CrowdStrikeの根本原因分析（2024年8月6日）では、21個の入力を想定した定義に対して20個しか渡されず、範囲外のメモリ読み取りが起きたことが原因とされています。
同じソフトウェアと同じ配信経路を使う系統では、共通の不具合を含む更新が適用されると、複数系統が同時に停止するおそれがあります。CrowdStrikeは再発防止策として、カナリア試験を通過したものから段階的に配信範囲を広げる方式を挙げました。ミッションクリティカルな系統では、ベンダーから届く更新を本番の全系統へ一斉に適用しない運用を、冗長化と同じ重みで設計します。
可用性要件を満たす設計と費用の境界
独立2系統で99%を99.99%へ引き上げる多重化
NTT技術ジャーナルは、単体の信頼性と保守性の向上に加え、サブシステムの多重化を可用性向上策に挙げています。単体可用性99%の独立した2系統を利用できる構成なら、両方が利用不能になる確率から99.99%と計算できます。
可用性 = 1 - (1 - 99%) × (1 - 99%) = 99.99%この計算は障害が独立している前提です。同じ設定、同じ移行作業、同じ配信元に依存する系統は、共通原因障害で同時に止まるおそれがあります。また東証の事例は2系統の同時故障ではなく、1号機の故障時に2号機への自動切替が働かなかったものです。切替が成立しなければ、2系統あっても計算どおりの可用性は出ません。台数を増やすだけでは不十分で、障害領域を分離し、フェイルオーバーが成立する構成まで確認します。
Amazon EC2とGoogle Compute Engineの99.99%適用条件
クラウドのSLAは、サービス名だけでなく配置条件まで読まなければなりません。Amazon Compute Service Level Agreement（2022年5月25日更新）は、同一リージョンの2つ以上のAZへ全稼働インスタンスを同時配置した構成を月間99.99%以上とし、単一インスタンスは99.5%以上としています。
Google Compute Engine SLA（2026年10月14日更新）も、Premium Tierではストックホルムを除くリージョンの複数ゾーン配置を月間99.99%以上としています。単一インスタンスは、メモリ最適化ファミリーが99.95%以上、その他のファミリーが99.9%以上です。単一障害点を残した構成に、複数ゾーン向けの数値を当てはめてはいけません。SLAの条文の読み方と契約への落とし方はSLA（サービスレベル合意）とは？定義・SLOとの違い・要件と稼働率保証を解説で整理しています。
サービスクレジット10%から100%と停止損失の差
Amazon EC2のリージョンレベルSLAでは、月間稼働率が99.0%以上99.99%未満なら10%、95.0%以上99.0%未満なら30%、95.0%未満なら100%のサービスクレジットです。Google Compute Engineの複数ゾーン構成でも、Premium Tierのストックホルム以外のリージョンでは、同じ稼働率帯に10%、25%、100%のクレジットを定めています。
クレジットは対象サービスの月額料金に対する補填であり、停止中の売上、復旧作業、人命への影響を回復するものではありません。SLAの数値を自社サービスの事業継続保証と同一視する設計は採用できません。停止損失が大きいなら、利用者側で冗長化と復旧手順を持つ必要があります。
オフサイトバックアップと縮退運転の採用境界
地理分散は拠点障害に備えられますが、遠隔拠点、データ複製、切替試験の費用が増えます。金融庁監督指針II－3－4－1－2（9）がオフサイトバックアップ等を求める対象は「業務への影響が大きい重要なシステム」です。全システムを同水準にせず、影響度で対象を絞る考え方が読み取れます。金融機関でのDR構成の具体例は金融システムのサーバー構成｜可用性・DR設計とクラウド移行の判断基準で扱っています。
完全復旧まで全機能を維持する必要がなければ、決済受付や安全制御など中核機能だけを残す縮退運転も候補です。追加系統の費用が許容停止損失を上回り、手作業や縮退運転でRTOを満たせる機能には、全面的な地理分散を採用しません。BCP全体での評価はBCPとは？事業継続計画の意味と防災計画との違い、RTO・RLOの決め方で確認できます。
要件定義から運用までの設計判断
RASと性能を両立させる優先順位
NTT技術ジャーナルは、ミッションクリティカルシステムに高品質要件と高性能要件の両立を求め、品質指標としてReliability、Availability、ServiceabilityからなるRASを挙げています。止まりにくさだけでなく、利用できる割合と保守のしやすさを一組で扱う考え方です。
優先順位は業務影響、RTO・RPO、障害領域の分離、復旧手順、性能の順に具体化します。Microsoftも高い信頼性には大きなコストのトレードオフが伴い、すべてのワークロードで妥当とは限らないとして、設計判断をビジネス要件で決めるよう勧めています。可用性の設計指標は可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】で補足しています。
FISC第14版を起点にした金融システムの統制
金融機関のシステムでは、FISCの金融機関等コンピュータシステムの安全対策基準・解説書（第14版）が設計・運用の基準として参照されます。開発、導入、運用等で必要と考えられる安全対策を基準として示し、基準項目ごとに具体例を交えて解説する資料です。第14版の改訂点はFISC安全対策基準とは？第14版の改訂点と金融システム開発での対応範囲にまとめています。
金融システムでは、SLAだけを根拠に構成を決めず、監督指針とFISC安全対策基準を要件・統制へ対応付けます。設計書に稼働率を書く段階で終えず、切替、バックアップ復元、当日中の再開、委託先を含む連絡手順まで運用可能な形に落とす必要があります。
冗長化を採用しない機能の明示と残存リスク
冗長化には二重の設備費だけでなく、データ同期、監視、切替試験、構成変更の工数が伴います。要件を超えて系統を増やすと、構成の複雑さが保守性を下げ、切替手順そのものが障害原因になり得ます。多重化の前提と構成差は冗長化とは？二重化との違い・種類と構成、企業の設計判断まで解説【2026年版】で整理しています。
例えば、RTOを4時間、RPOを1営業日とする社内帳票機能を想定します。単一構成からの復旧と手作業の代替でこの条件を満たせるなら、常時稼働の待機系を省く案を比較対象にできます。その場合は「対応しない」のではなく、復旧手順、バックアップ、責任者、残存リスクを明記します。耐障害性との違いはフォールトトレラントとは？耐障害性の仕組みと高可用性・フェイルオーバーとの違いを実装目線で解説を参照してください。
ミッションクリティカルなシステムを開発会社に委託するときの確認点
ミッションクリティカルな案件では、機能の見積もりよりも、非機能の約束と試験の範囲で発注先の差が出ます。提案書やレビューの場で、次の点を数値と手順で答えられるかを確認します。
- 稼働率、RTO、RPOを、IPA非機能要求グレードなどの共通の物差しで合意し、計画停止の扱いを含めて書面に残しているか
- 切替試験を、東証の事例のような故障の種類ごとに設計し、本番と同じ設定値で実施する計画があるか
- 移行や機種更改の直後に障害が出たとき、旧環境へ戻す手順と判断期限が決まっているか
- OS、ミドルウェア、セキュリティ製品の更新を段階的に適用し、全系統へ一斉に入れない運用になっているか
- 代替手段（手作業、媒体、縮退運転）で、実際の取引量を何時間処理できるかを訓練で確かめているか
- クラウドのSLAと自社の稼働率目標の差を、誰がどの構成で埋めるかという責任分界が書かれているか
「冗長構成です」という回答だけでは判断できません。試験計画書と障害時の連絡体制図を提案段階で求めると、運用まで見据えた会社かが分かります。金融機関の勘定系周辺や決済のように、監督指針とFISC安全対策基準への対応まで求められる案件は、金融システム開発の支援でも要件定義から相談を受けています。
よくある質問
ミッションクリティカルとは簡単に言うと何ですか？
止まったり誤作動したりすると、人命や利用者・企業に重大な損失が出るため、継続的な正常稼働を最優先するシステムや業務のことです。利用頻度の高さではなく、停止結果と代替手段の有無で判定します。
「mission critical」の英語の意味は何ですか？
「任務（mission）の遂行に不可欠な（critical）」という意味で、ITシステムに限らず組織の任務を止める対象全般に使われます。名詞の前に置くときは「mission-critical system」のようにハイフンで結ぶ表記もありますが、意味は変わりません。
ミッションクリティカルなシステムの言い換えは？
文脈により「止められないシステム」「社会インフラシステム」「基幹系システムの中でも停止影響が大きいもの」などと言い換えられます。金融では勘定系や決済系がこれに当たります。ただし基幹システムがすべてミッションクリティカルとは限らないため、要件を伝える場面では言い換えより、稼働率、RTO、RPOの数値で示す方が誤解を防げます。
ミッションクリティカル性とはどういう意味ですか？
システムや業務が組織の任務にとってどれだけ欠かせないかという重要度の度合いを指します。英語ではcriticalityと表し、Microsoftはワークロードごとにcriticality ratingを付け、ミッションクリティカル、ビジネスクリティカルなどに分類する例を示しています。度合いが高いほど、許容停止時間が短く、冗長化や訓練への投資が大きくなります。
「critical」単独ではどのような意味ですか？
criticalには文脈により「重大な」「危機的な」「批判的な」などの意味があります。mission criticalでは「任務の成否に関わる重大な」という方向で読むのが自然です。ただし、criticalという語だけで稼働率99.999%などの水準が決まるわけではありません。停止損失、RTO、RPOを個別に数値化します。
