【事例集】【AU-R04-1-PM2-Q2】システム障害管理態勢に関する監査— 論文の補助に使える事例ヒント集

🍀概要

　本ページは、システム監査技術者試験の論述問題学習用に、一次情報を出所明示のうえ引用・要約した資料です。AI（ChatGPT 等）を用いた再構成を含み、正確性・最新性を保証しません。必ず原典をご確認ください。IPA 等の出題機関・規格団体とは無関係です。権利上の問題がある場合はお問合せまでご連絡ください。

🧾問題・設問（AU-R04-1-PM2-Q2）

　出典：情報処理推進機構 システム監査技術者試験 令和4年 午後2 問2(🔗取り扱いガイドライン)

📘問題

■タイトル
　システム障害管理態勢に関する監査について
■内容
　ビジネスを取り巻く環境が大きく変化する中，企業などの組織は，事業の再編，新規市場への参入，提供するサービスの高度化などによって，競争力を高めていくことが求められている。そのためには，例えば，既存の情報システムを統合又は連携させたり，外部組織が提供する情報システムを利用したりするなど，情報システムの改変が必要になる。最近では，API接続などによって，外部組織の情報システムと連携するための改変を行って，付加価値を高めている事例も増えている。
　一方，情報システムの改変によってシステム構成などが複雑になると，システム障害が発生する可能性が高くなる。また，システム障害がどの箇所でいつ発生するのかの予測も困難であり，外部接続先の情報システムの障害による影響なども想定される。さらに，既存システムには，ソフトウェアの肥大化，複雑化，保守サービスの終了，運用・保守人材の不足などの問題もある。
　このような状況において，システム障害管理が不十分であると，障害発生時にサービスへの影響が拡大したり，根本的な対策が実施されずに障害が再発したりするおそれがある。したがって，情報システムの改変を踏まえて，障害に対する基本方針，体制，訓練，見直しなどのシステム障害管理態勢の構築が重要になる。
　システム監査人は，以上のような点を踏まえて，改変後のシステム障害管理態勢に関する着眼点を設定して，適切かつ十分な監査証拠を入手し，実効性のあるシステム障害管理態勢が構築されているかどうかを確かめる必要がある。
　あなたの経験と考えに基づいて，設問ア～設問ウに従って論述せよ。

📗設問

■設問ア
　あなたが関係する組織が提供するサービスを支える情報システムについて，改変の内容，システム障害によってサービスへの影響が拡大する要因，及び改変後のシステム障害管理態勢の概要を，800字以内で述べよ。
■設問イ
　設問アで述べた要因を踏まえて，システム監査人として，システム障害管理態勢の実効性を確かめるために設定すべき着眼点及びその設定理由を，700字以上1,400字以内で具体的に述べよ。
■設問ウ
　設問イで述べた着眼点について，入手すべき監査証拠，及びその監査証拠に基づいて確かめるべき具体的な内容を，700字以上1,400字以内で述べよ。

📚事例集

ChatGPT Deep Researchを活用して、問題文の内容に近い、代表5業種の事例を分析した結果です。論文執筆のヒントになるものと思われます。

分析結果URL
https://chatgpt.com/s/dr_68aabdc36df48191b5671021e1badd60

製造業（Manufacturing Industry）

1) 200字要約

自動車や電子機器等の製造業では、ITシステム障害が生産ライン全体の停止につながり、顧客納期や安全性に直結するglobal.toyota。監査目的は、生産システムの変更管理や障害対策が適切に設計・運用され、障害発生時に迅速な復旧と被害最小化ができる態勢（例：冗長化、予防保全、監視）が整備されていることを検証することである。監査範囲は工場OTとITの両領域を含み、手続としてドキュメントレビュー、現場観察、試験（障害シミュレーション等）を実施する。指摘事項に基づき改善計画を立案し、経営層合意の下、IT/生産部門が対策を実行・フォローアップする流れとなる。

2) 現場課題

製造現場では24時間稼働やJIT生産の中で、システム停止時のライン停止リスクが高い。課題は、レガシー設備で更新・パッチ適用が滞り脆弱性を抱える点、障害時に生産現場と情報システム部門の連携不足で初動が遅れる点、監視が不十分でサイレント障害の見逃しがある点である。特に制御システム（ICS/OT）は一般OSや標準プロトコルを用いることが多くサイバー攻撃に脆弱でありintellilink.co.jp、現場担当者がITスキル不足であるケースもある。また、安全面では設備障害が労働安全に直結するため、フェイルセーフ設計や非常停止手順の整備も課題となっている。

3) リスクと法規制/基準マッピング

• EOL/EOSのリスク：製造装置でサポート切れOSを使い続けると未修正の脆弱性放置によりウイルス感染や意図しないサービス停止被害のおそれipa.go.jp。老朽化システムの更新計画未整備は経済産業省の「システム管理基準」で求められるレジリエンス確保要件違反となるmeti.go.jp。
• ゼロトラスト：工場内外の接続増加に伴い、境界防御に頼らず「何も信頼しない」を前提に認証・アクセス制御するゼロトラストネットワーク思想が重要mhlw.go.jp。特にリモート保守接続やIoT機器増加に対しNIST SP800-207準拠の実装が推奨される。
• 委託管理：製造業では生産システムの開発・保守を外部ベンダに委託する場合が多い。契約で障害対応時の責任分界を明確化し、ベンダ側BCPや報告義務を定める必要があるmhlw.go.jp。またサプライチェーン攻撃に備え、取引先・委託先のセキュリティ管理状況を定期確認する（例：金融ISAC等の情報共有）。
• 法令・ガイドライン：労働安全衛生法で設備異常時の安全確保義務、電気事業法等で高エネルギー設備の安全運転義務があり、IT障害による安全リスク放置は法令違反につながりうる。IPA「障害対策手法」や経産省「情報セキュリティ管理基準」に従い、障害対応手順・予防策の整備が求められるmeti.go.jp。
• 脆弱性管理：未適用のセキュリティパッチやソフト不具合はシステム障害の温床となる。IPA「安全な開発指針」等では継続的な脆弱性情報収集と修正適用が求められる。特に制御機器向けにはIEC62443や「制御システムセキュリティガイドライン」に準拠し、脆弱性診断・ファーム更新体制の確立が推奨される。

4) 経営・監査上の有効性

経営視点では、システム障害対策の有効性は生産停止による損失低減や顧客への供給責任の履行で評価される。例えば主要設備のMTTR（平均復旧時間）は可用性指標として重要であり、停止合計時間を障害回数で割った値で算出するe-words.jp。MTTR短縮や高稼働率(可用性)の達成はサービス品質向上と直結する。また、障害インシデントによる年間生産損失額、納期遅延件数、品質への影響（不良品発生など）の定量指標をモニタし、重要インシデント発生時の取締役会への報告体制を整備する。監査上は、障害対応プロセスがISO/IEC 27002やCOBITのフレームワークに沿って設計・運用されているか評価する。特に、根本原因分析と再発防止策がPDCAサイクルで実行されている企業は障害低減に成功しているipa.go.jp。定性的には、障害発生時の現場対応の迅速さ、経営層のリーダーシップ（緊急時の意思決定と資源投入）も有効性指標となる。

5) 統制設計の芯

製造業におけるシステム障害対策の中核統制は次の通り:

• 変更管理：生産システム（SCADA, PLCソフト等）への変更前に影響評価とテストを義務づけ、本番適用は承認制とする。例えば更新前後で十分なテストを実施し、予期せぬ停止を防止c3index.co.jp。緊急変更でも事後レビューを行う。
• 障害対応フロー：障害検知から復旧までの手順書を整備し、種類別に対応策・必要なツール・連絡体制を定めるc3index.co.jp。現場担当がまず一次対応（予備設備への切替、現場安全確保）を行い、IT部門・ベンダへ速やかにエスカレーションするRACIを明確化。主要設備停止を想定した復旧手順が未整備だと迅速対応が困難fsa.go.jp。
• 監視と早期警戒：PLCやサーバの稼働監視システムを導入し、CPU負荷・温度・ネットワークトラフィック等をリアルタイム監視c3index.co.jp。異常兆候を検知したら自動アラートで運用員に通知する。IoTセンサーによる振動・電流監視で機器故障を予兆検知する予防保全も有効。
• 復旧と冗長化：単点故障を排除する設計として、主要サーバ・ネットワークはクラスタリングや冗長経路で構成c3index.co.jp。バックアップ回線・非常用電源も備え、障害時に自動フェイルオーバーする。データは定期バックアップし遠隔地に保管c3index.co.jp。システム停止時も手動で代替運転可能な手順を用意し、人力でも最低限の稼働を継続できるようにする。
• 外部接続管理：第三者リモート接続やクラウド連携箇所はリスクが高く、VPNの多要素認証やアクセス制御リストで限定。境界にファイアウォールを設置し、OT領域とITネットワークを分離する。製造現場のUSBやノートPC経由のマルウェア侵入を防ぐ物理・論理両面の統制を行う。

6) 監査手続

監査人は以下の手続で証拠を収集する:

• 文書レビュー：障害対応規程、インシデント報告書、変更管理台帳を精査し、内容の妥当性と最新性を確認する。例えば直近1年間の障害一覧と原因分析結果を入手し、再発防止策が実施され効果を上げているか検証する。
• 現地観察：工場のサーバ室・制御室を視察し、冗長構成（予備機の有無）、バックアップ媒体の保管状況（耐火金庫等）を確認する。また運転監視員へのヒアリングで、異常時の連絡フローやマニュアル配布状況を聞き取る。
• テスト(再現・追試)：BCP訓練記録を確認し、一部障害シナリオの模擬演習に立ち会うことで手順の有効性を評価する。例えば予備系への切替試験を監督し、マニュアル通りに復旧できるかを観察するc3index.co.jp。加えて、ログを用いたCAATsにより障害時の対応時間計測や、無権限ユーザによるシステム変更痕跡が無いか分析する。
• サンプリング：主要な制御装置やサーバについて、設定変更やパッチ適用の記録をサンプル抽出し、承認・検証プロセスの有無を検査する。例えば3件のPLCプログラム更新作業票を確認し、テスト結果と責任者承認サインをエビデンスとする。
• 再実行：重要な日次バックアップのリストア試験を監査人主導で実施し、データ復元に要する時間や手順の正確性を検証する。これによりバックアップ媒体破損や手順書の欠落といった問題を発見できる。

7) 体制・合意形成

監査では経営層と現場の合意形成が重要となる。まず監査委員会や取締役会レベルで、システム障害リスクが事業継続に重大と位置づけられ、CISOや生産部門長が対応責任者となっているかを確認する。製造業ではOTセキュリティ担当とIT部門が分かれていることが多く、RACIマトリクスで障害時の役割分担（現場対応=責任者、生産本部=説明責任、IT=技術支援など）を事前に定義する必要がある。監査人は用語の統一にも留意し、現場の「異常停止」とITの「インシデント」が同義であることを関係者間で認識合わせする。指摘事項の改善計画策定には、現場の工場長・生産技術部門も参画させ、現実的かつ効果的な対策となるよう合意形成を図る。改善策例として「毎月の計画停止枠で古いOS機器の段階更新を実施」等を提案し、経営層からのトップダウン支持を取り付ける。最後に、改善策の実施結果を次回監査やマネジメントレビューでフォローアップする仕組みを合意する。

8) KPI（定義・算式付き）

• システム稼働率：全稼働時間に対する正常稼働時間の割合（例：年間稼働率 = (年間総時間 – ダウンタイム) / 年間総時間）。目標値を99.9%以上と設定し可用性を定量評価e-words.jp。
• MTTR（平均復旧時間）：障害発生から復旧までの平均所要時間＝復旧に要した総時間 / 障害件数e-words.jp。例えば月間MTTR=5時間なら平均復旧5時間。目標は低減傾向。
• インシデント再発率：過去の類似障害が再度発生した割合＝再発インシデント件数/総インシデント件数×100%。低いほど再発防止策が有効。
• 計画外停止回数：想定外のシステム停止の回数（年間）。ゼロが理想で、高頻度なら抜本対策が必要。
• パッチ適用率：指定期間内に適用済の重要セキュリティパッチ数/全適用対象パッチ数×100%。未適用が残るとリスク高。
• BCP訓練達成率：計画された障害対応訓練の実施率＝実施済訓練数/計画訓練数×100%。100%実施が望ましい。
• 障害検知時間（MTTD）：Mean Time To Detectとして障害発生から検知までの平均時間。監視強化により縮小させ、目標例:5分以内検知。

9) 監査リスクと反証

製造業監査におけるリスクは、監査範囲外の「シャドーIT」的な装置（現場で勝手に導入された機器）が障害要因となるケースを見落とす可能性である。監査人は現場ヒアリングで非公式システムの存在を確認し、必要なら対象に含める。また、想定限界として大規模災害時の同時多発故障など極端な事態は監査シナリオで完全に再現できず、指摘した統制でも対応不能な場合がありうる。これに対しては「全停止を想定した手順整備」等、考えられる最大範囲まで改善を求める姿勢が必要となるfsa.go.jp。証拠不足のリスクもあり、例えば障害対応の口頭報告のみで記録が残っていない場合、監査証跡が不十分となる。この場合は関係者複数インタビューや代替手続で裏付けを取り、反証可能性を下げる。さらに、サンプル偏りにより統制有効性を過大評価するリスクにも留意し、必要なら追加サンプルや期間延長を行う。最後に、経営者の抵抗（障害情報開示を渋る風土）がある組織では、監査調書に根拠を丁寧に示し客観事実で反論する。

10) 参考リンク

1. トヨタ自動車「先月の生産指示システムの不具合について」（2023年9月6日） – https://global.toyota/jp/newsroom/corporate/39732550.html : トヨタ全14工場停止の原因が保守作業中のディスク容量不足によるシステム障害であった事例global.toyota。障害要因分析とバックアップ切替不備の教訓。
2. NTTデータ先端技術「制御系システムのセキュリティ動向」（2017年） – https://www.intellilink.co.jp/column/security/2017/062700.aspx : 制御システムへのサイバー攻撃事例と対策動向に関する解説。製造業等の制御系でも一般IT同様に標的となり、防御が課題である点を指摘intellilink.co.jpintellilink.co.jp。
3. IPA「セキュリティプレゼンター通信：Windows10サポート終了注意喚起」（2024年10月） – https://www.ipa.go.jp/security/sme/presenter/SPmailnews_20241028.pdf : OSサポート終了後は脆弱性修正が提供されず、攻撃による情報漏えいやサービス停止の被害が高まると警鐘ipa.go.jp。EOL機器利用リスクの根拠資料。
4. 経済産業省「システム管理基準」（2023年4月改定） – https://www.meti.go.jp/policy/netsecurity/sys-kansa/sys-kanri-2023.pdf : 企業のITガバナンス基準。障害等への対応によるITサービスのレジリエンス確保や事業継続方針策定を求めるmeti.go.jp。監査の判断尺として参照。
5. シースリーインデックス社「システム障害の事例5選｜障害の原因や対策とは？」（2024年7月12日） – https://www.c3index.co.jp/blog/blog_2035/ : システム障害の原因分類と対策を解説した記事。冗長化・予防保守・監視強化・復旧手順整備・EOL管理など基本対策を網羅し、障害影響最小化のポイントを示すc3index.co.jpc3index.co.jp。

11) 作成日・最終閲覧日

• 作成日: 2025年8月23日
• 最終閲覧日: 2025年8月23日

小売業（Retail Industry）

1) 200字要約

POSレジやECサイト等を運用する小売業では、システム障害が店舗営業停止や売上機会損失に直結するdiamond-rm.net。監査目的は、店舗システムや決済基盤の障害管理態勢が適切で、特に高需要時でも迅速復旧し顧客影響を最小化できることを確認する点にある。監査範囲は本部データセンターから各店舗端末、クラウドサービスまで含め、監査手続として障害発生履歴の精査、店舗現場へのヒアリング、システム復旧訓練の観察等を実施する。改善策は、本部IT部門と店舗運営が協働し、バックアップ回線の用意や手動販売手順の整備などを進め、経営層承認の下で順次実行・定着化を図る。

2) 現場課題

小売現場の課題は、店舗分散環境ゆえに各店舗でIT対応力に差があり、障害発生時の初動や本部報告が遅れがちな点である。またキャッシュレス決済依存度が高まり、システム停止時に代替手段が不十分だと店舗休業に至るリスクがあるbiz-journal.jp。店舗POSは営業時間中ほぼ無停止要求される一方、老朽化したPOS端末や通信回線の単一障害点(SPOF)が残存するケースも多い。ECサイトではピークトラフィック時の障害対応（例：大規模セールでの負荷集中によるダウン）が課題。さらに、リリース直後の不具合や外部決済代行の障害が自社サービス停止を招くなど、他社サービス依存のリスクも顕在化している。

3) リスクと法規制/基準マッピング

• EOL/EOS：店舗POSでWindows等のサポート終了OSを使い続けると、脆弱性放置から不正アクセスやマルウェア感染でレジ停止する恐れがある。事実、2020年頃のWindows7サポート終了時にも更新遅れたレジでウイルス被害相談が寄せられたsecurity-next.com。特定商取引法や個人情報保護法上も安全管理措置として定期的なシステム更新が求められる。
• ゼロトラスト：店舗Wi-FiやクラウドPOS導入が進む中、Zero Trust Architectureを採用し、本部-店舗間通信やAPI連携で常に認証・検証を行う設計が推奨されるmhlw.go.jp。PCI DSSなどカード業界基準でも店舗内ネットワークのセグメント化（決済端末を他と分離）や暗号化通信が要求され、境界なき環境での認可制御の重要性が高い。
• 委託/サードパーティ：小売業は決済代行会社、クラウドECプラットフォーム、POSベンダ等多数の外部サービスに依存する。委託契約で障害発生時の報告義務・復旧優先度や賠償条項を定め、自社BCPに組み込む必要があるmhlw.go.jp。例：2024年3月のマクドナルド障害ではサードパーティ設定変更が原因と公表されておりbiz-journal.jp、ベンダ管理不備が重大影響を及ぼすリスクを示した。
• 法令：個人情報保護法により会員データや購買履歴の漏洩防止が義務だが、システム障害時に適切なアクセス制御がなければ漏洩リスクも高まる（例：障害対応中のデータ取扱ミス）。また割賦販売法ではクレジットカード情報を安全に処理する義務があり、決済システム障害による不正リスクへの対応（不正検知システムや監視ログ）も要求される。
• 脆弱性：Web通販サイトの脆弱性放置は攻撃によるサービス停止(DDoSや改ざん)を招きやすい。経産省「ECサイバー安全指針」では脆弱性診断の定期実施が推奨されており、重大な脆弱性(CVSS高評価)は報告・修正を迅速に行わねばならない。またPOSもソフト更新怠りによる障害（例：メモリリークで徐々に応答低下）が散見される。

4) 経営・監査上の有効性

経営層は店舗システム障害による売上損失やブランド毀損を最小化することを重視する。有効性の定量指標として、年間障害総時間や機会損失額をKPI管理し、重大障害1件あたりの平均売上損失額を把握している企業もある。また、RTO（目標復旧時間）をサービスレベル目標として定め、全障害がその範囲内で復旧した割合を監視する。例えば「POS障害の90%は15分以内に復旧」等の目標を設定する。監査上は、店舗休業を伴う重大インシデントの経営報告体制（事例：50店舗がレジ障害で3.5時間休業した西友の件diamond-rm.net）を確認し、経営陣が原因と再発防止策をレビューしているか評価する。定性的評価として、店舗スタッフへの緊急時対応教育の浸透度や、顧客への迅速な告知対応（返金・謝罪プロセス）が用意されているかも有効性の証左となる。監査人は、障害対応の結果として顧客離れやコンプライアンス違反（例：決済不能による二重請求など）が生じていないかも確認し、サービス品質維持の観点で評価を行う。

5) 統制設計の芯

小売業における障害対策の主要統制:

• 監視とインシデント検知：本部のIT運用センターで全国店舗システムを集中監視し、POSやサーバの死活状況、取引エラーログをリアルタイム監視する。異常を検知したら自動通知し、24時間有人対応で早期エスカレーションする。例えば深夜のECサイト障害もオンコール体制で即応できるようにする。
• フェイルセーフ運用：カード決済端末がダウンした場合でも販売を継続できるよう代替手段を準備する。具体的には、POS障害時に手書伝票と現金決済に切替えるマニュアルを店舗に備え付け、定期訓練する。マクドナルドでは一部店舗が紙オーダーと現金で継続対応したbiz-journal.jpが、多くは休業に追い込まれた教訓から、全店舗での手動プロセス整備が重要。
• 冗長化とバックアップ：店舗回線を二重化し、メイン回線断でもサブ回線(LTE等)に自動切替できるようにする。POSサーバは二重化が難しい場合、定期同期されたクラウドに待機系を用意する。データは本部へ集約バックアップし、店舗側にもキャッシュを保持して通信断でも会計を一時保存し後同期できる仕組みを採用する。
• 変更管理とテスト：店舗システムやECサイトへの変更は売上に直結するため、リリース前の負荷テストや検証を徹底する。特に繁忙期直前のシステム更新は凍結期間を設け、安定稼働を優先する統制を設計する。本番反映は本部IT部門が集中管理し、店舗現場での独自行為を防ぐ（勝手な再起動等は連絡ルール化）。
• 顧客周知：障害発生時、速やかにHPや店舗掲示で顧客に状況説明し、不満を最小化する対応も統制の一環。これは監査時には間接的要素だが、BCPの一部として顧客対応計画があるか確認する。

6) 監査手続

• 店舗サンプリング訪問：監査チームは数店舗を抜き打ち訪問し、POSレジの障害対応手順書が現場で入手容易な状態か、店長に確認する。また直近に障害を経験した店舗ではヒアリングで初動対応の実態（誰に連絡し、どう対処したか）を聴取し、規程との乖離を評価する。
• システムログ分析：POSアプリケーションや決済ゲートウェイのログから、障害発生前後の状況を把握する。例えば、ある日の全店舗売上が急落した時間帯があればその時刻のシステムログを解析し、何が起きていたか（エラー多数発生など）を検証する。これにより未報告の障害も浮き彫りにできる。
• ドキュメント精査：本部ITのインシデント管理台帳やベンダ報告書を入手し、原因・対策欄が適切に埋められているか確認する。対策未実施のものは改善計画を要求する。また外部委託先とのSLA契約を確認し、復旧目標が定められているか、直近障害でSLA違反が無かったかも調べる。
• 再現テスト：必要に応じ、本部システムで冗長切替テストの結果報告書を監査人がレビューし、証跡を確認する。例えばバックアップ回線切替試験が年次行われているか、その記録（日時・結果・問題点）を確認する。実際に試験を立会い再実行させることも検討する。
• CAEツール活用：ECサイトの稼働状況を監査人が独自に外部モニタリングツールで測定し、障害時系列を記録として収集する（例：Pingdom等で応答停止期間を取得）。これを公式記録と突合し、齟齬がないかをチェックする。

7) 体制・合意形成

小売業では店舗運営部門とIT部門の連携体制が重要である。監査時には、両部門による合同の障害対策委員会が設置されているか確認する。大規模チェーンならCIOやCDOがデジタル戦略統括として委員会議長となり、店舗代表（エリアマネージャ等）や情報セキュリティ責任者がメンバーとなって障害事案の検討・合意を行う仕組みが望ましい。また、監査報告書ドラフトのレビュー段階で店舗側の用語理解を助けるため、専門用語対訳集を用意する（例：「SLA＝サービス水準合意（店舗へのサービス約款）」など）。監査人は改善提案が実務とかけ離れたものとならないよう店舗現場の声を反映させる合意形成プロセスを重視する。例えば「営業時間中のシステム再起動は禁止」の統制提案について、店舗から「深夜帯は客が少ないため影響軽微」との意見があれば、適用範囲を調整するなど柔軟に合意していく。

8) KPI（定義・算式付き）

• 平均障害対応時間：障害検知から完全復旧までの平均時間（分または時間）。= 障害対応総時間 / 件数。短いほど迅速対応できている。目標例:主要システム障害MTTR 30分以内。
• 休業回避率：障害時に店舗休業を避け営業継続できた割合。= 休業回避できた障害件数 / 全障害件数 ×100%。高いほど障害耐性が高い。目標:100%（全件で何らかの販売継続策実施）。
• インシデント報告遅延率：店舗で障害発生後、本部への所定報告時間内に報告が無かった割合。= 報告遅延件数/全障害件数×100%。低いほど良好。目標:0%。
• SLA遵守率：委託先とのサービスレベル合意で規定した復旧時間内に実際復旧した割合。= SLA内復旧件数/委託先障害件数×100%。SLA未達はベンダ管理見直し要。
• 障害頻度（店舗あたり）：1店舗あたり月間障害発生数（POS・通信・電源含む）。全店舗平均値で算出。これを減少させることが安定運営指標となる。
• 顧客影響指数：障害により影響を受けた顧客数（例：レジ待ち発生人数や未完了注文数）。インシデント毎に推計し、重大度を数値化する。

9) 監査リスクと反証

監査リスクには、店舗現場での非公式対応が監査に顕在化しないことがある。例えば、レジ不調時に店員の裁量で一部商品を後日手入力処理した等が正式記録されず監査から漏れる可能性。これに対し、監査人は店舗ヒアリングで口頭ベースの対応も含め把握し、反証として関連するレシートや手書き記録を確認する。また、本部システムログだけでは店舗障害を網羅できないリスクにも注意し、外部情報（SNS報告等）も調査して影響範囲をクロスチェックする。監査範囲の想定限界として、大規模停電や決済ネットワーク全体障害など、自社では制御不能な事象は評価対象外となる場合がある。この際は、それら前提を監査調書に明示し、管理可能範囲内での統制有効性に注力する旨を記載しておく。さらに、証拠制約としてPOS障害ログが上書き保存期間切れで消失しているケースがあり、証跡不十分となる恐れがある。これには監査人のIT専門家チームによるフォレンジック手法で断片的データを復元したり、ベンダから間接証拠を取得するなどの対抗措置を検討する。最後に、経営者との意見相違（例：障害件数を軽微と自社内評価し改善投資に消極的）が生じた場合、監査では客観データ（他社事例・業界水準）を提示して反論を封じ、改善必要性への合意形成を図る。

10) 参考リンク

1. 時事通信「西友50店舗、レジ使えず＝システム障害で一時休業」（2022年5月20日） – https://diamond-rm.net/flash_news/185659/ : 2022年5月、西友の約50店舗でレジ障害が発生し3時間超の臨時休業に至った事例diamond-rm.net。小売業におけるシステム障害の直接的営業影響を示す。
2. Business Journal「マクドナルド・システム障害の原因分析」（2024年3月16日） – https://biz-journal.jp/company/post_378802.html : 2024年3月15日に発生したマクドナルドの世界同時POS障害について、第三者による設定変更ミスが原因と報じた記事biz-journal.jp。キャッシュレス依存店舗の脆弱性やグローバル共通システムのリスクを専門家解説。
3. IPA「セキュリティプレゼンター通信：Windows10 EOL注意喚起」（2024年10月） – ※製造業の参考リンク[3]を参照ipa.go.jp。小売店舗端末でも古いOS放置のリスク根拠として引用。
4. 厚生労働省「医療情報システム安全管理ガイドライン 第5.2版」（2021年改訂） – 医療分野固有ではないが、委託先との責任分担やゼロトラスト概念について示唆mhlw.go.jpmhlw.go.jp。業種を超えた一般原則として参照可能。

11) 作成日・最終閲覧日

• 作成日: 2025年8月23日
• 最終閲覧日: 2025年8月23日

物流業（Logistics Industry）

1) 200字要約

物流業では配送管理システムや倉庫管理システム(WMS)の障害が荷物配送の停滞やサプライチェーン全体へ波及するblog.cbsec.jp。監査目的は、物流ITの障害管理態勢が事業継続の観点で十分か評価し、特に単一障害点の排除、緊急時の代替プロセス（手動処理等）確保、サイバー攻撃耐性（ランサムウェア対策）が適切に講じられていることを検証する。監査範囲には基幹システムから現場端末・IoT機器、外部物流パートナーとの接続まで含め、手続として障害シナリオレビュー、復旧時間の実測検証、インシデント対応訓練の観察を実施する。指摘事項は経営・現場が合同で改善策を策定し、重要物流インフラの一環としてフォローアップにより継続的改善を図る。

2) 現場課題

物流現場（配送センター、運行管理部署）では、人手不足解消のため高度にデジタル化・自動化が進む一方、システム障害時に作業を継続する手動代替が困難という課題がある。例えば倉庫ではバーコード検品や自動仕分け機が停止すると即座に出荷が滞留し、人手での検品体制への切替に時間を要する。また配送計画システムが停止するとドライバーへの指示出しができず集配に混乱を来す。現場のIT依存度が高まるほど、一極集中システム障害の影響範囲が広がる。さらに、物流はランサムウェア攻撃者に狙われやすい業種であり、荷物滞留は企業間の取引にも影響を及ぼすため身代金要求の標的となり得るapsc.jp。しかし中小物流業者では対策が不十分で、サプライチェーン全体の脆弱性となるケースも課題であるapsc.jp。

3) リスクと法規制/基準マッピング

• EOL/EOS：運行管理端末や倉庫内制御PCで古いOSを使用している場合、脆弱性放置からシステムダウンを引き起こすリスクがある。国土交通省の物流DXガイドライン等でもシステムの適切なライフサイクル管理が推奨されている。更新遅延は重大障害の一因となりうる。
• ゼロトラスト：トラック車載機や配送網がインターネット経由で繋がる現代では、Zero Trustの原則で拠点間・車両間通信の認証・暗号化を徹底し、不審なアクセスを常時監視することが求められる。NISC「重要インフラ対策ガイド」でもゼロトラスト的な多層防御を推進しており、物流企業も採用を検討すべき。
• 委託先管理：物流は多重委託（下請け配送、倉庫外部委託）が一般的であり、システム障害時の情報共有と対応役割を各社で取り決めておく必要があるapsc.jp。例えば大手宅配でシステム障害を「単なる故障」と発表したが実際は外部からの不審通信が確認され調査中だった事例があり、契約上の事故報告義務と共同対処の枠組み（荷主・ITベンダ・委託先間）が重要となる。
• 法令：貨物自動車運送事業法では事業継続のための安全確保義務が定められ、IT障害による配送不能も広義の責務履行に関わる。またサイバーセキュリティ基本法に基づき物流（輸送）分野は重要インフラ指定されており、政府の重点的対策分野となっている。従って、内閣サイバーセキュリティセンター(NISC)の対策基準に沿った計画策定・訓練実施が期待される。
• 脆弱性：物流システム固有のリスクとして、旧世代の制御機器や無線通信プロトコルの脆弱性（暗号化無しのハンディ端末通信等）がある。これらは侵入の踏み台となり、全社システム停止につながり得る。JPCERT/CCのICSセキュリティガイドラインでは、物流倉庫の制御ネットワークにもファームウェアアップデートやネットワーク分離を推奨している。脆弱性を放置でランサムウェア感染すれば、本番システム停止だけでなく安全確保（救急搬送停止など）にも直結する恐れが高いapsc.jp。

4) 経営・監査上の有効性

経営層にとって物流ITの障害対策は企業信用と契約履行上の命題である。システム障害による配送停止は荷主企業にも影響し、契約違約金や信頼損失を招く。そこで有効性を測る指標として、主要システムのRTO/RPOの達成度がある。例えば倉庫WMSのRTO=2時間に対し、直近障害で実際の復旧時間が1.5時間なら目標達成と評価する。また顧客への影響度指標として、配送遅延件数や遅延時間（平均○時間遅れ）を算出し、サービスレベルを定量化する。金融庁もITレジリエンス分析で、従来のRTOに加えRLO（目標復旧レベル：障害後どの程度業務を復旧させるか）を指標化する動きを示しているfsa.go.jp。監査上は、障害対応計画が事業継続マネジメント(BCM)の一環として経営戦略に組み込まれているか確認する。特に物流は社会インフラ的役割のため、レジリエンス（回復力）の高さが求められるblog.cbsec.jp。定性的な有効性評価として、障害発生時の他社振替輸送の迅速さ（代替輸送網の活用）や、顧客（荷主）への状況説明の適切さなども含めて判断する。

5) 統制設計の芯

• BCPシナリオ設計：単なるシステム障害対策に留まらず、重要業務を段階的に維持するBCPを用意する。例えば基幹システム全面停止シナリオでも「配送依頼はFAX受領に切替」「手書き伝票で仕分け」等、核となる業務継続策を準備するblog.cbsec.jp。このように全機能一度停止ではなく重要度に応じ段階的縮退運転できる設計とするblog.cbsec.jp。
• 冗長インフラ：サーバ群は異なるデータセンターに二重化し、ネットワークもバックボーン多重化する。倉庫内の無線LANコントローラや自動機制御も、フェイルオーバー機構を実装するblog.cbsec.jp。クラウド利用時は可用ゾーンを複数活用し、単一クラウド障害の影響を緩和する。
• 定期訓練：年に1回以上、障害発生を想定した社内訓練を行う。24時間以上復旧できない事態も想定し、物流センターやドライバーへの周知、顧客連絡、手動処理手順の実践を訓練することで、平時から準備ができるapsc.jp。訓練結果は評価・改善され、マニュアルに反映する。
• 監視・検知：SIEM等を導入し、サーバ・ネットワーク・アプリのログを統合監視する。特に不審なアクセスやランサムウェアの兆候（暗号化挙動、異常なログイン試行apsc.jp）をリアルタイム検知し、初期段階で遮断・隔離する。障害とサイバー攻撃は表裏一体のため、単なる障害説明に留めず、潜む攻撃の可能性を常に調査する統制とするapsc.jp。
• 外部連携：荷主企業や運送協力会社との間で、相手先システム障害時の連絡・代替措置を取り決めておく。例：大手航空貨物で物流システム障害時、航空会社も貨物搭載停止を公表したblog.cbsec.jpように、関連各社で透明性ある情報共有を図る。この統制により被害拡大を防ぐとともに信頼関係を維持する。

6) 監査手続

• システムアーキテクチャ確認：監査人は物流基幹システムの構成図を入手し、冗長化状況や単一障害点をチェックする。例えばDBサーバが1台のみであれば可用性リスクを評価し、設計変更を検討すべきと判断する根拠とする。
• 復旧時間の検証：直近の障害記録から実績復旧時間をサンプル抽出し、設定されたRTO内に収まっていたか検証する。超過ケースがあれば原因を調査し、計画の妥当性を監査意見とする。加えて、監査人自身がシステム停止を想定したタイマーを用意し、非常時連絡フローの実測試験（例えば深夜に障害を仮想発報し当番が何分で対応開始するか）を行うことも考慮する。
• ログ・監視証跡：ネットワーク監視ログやセキュリティインシデント対応記録を確認し、障害の裏に攻撃が無かったかの調査体制をチェックする。具体的には、障害発生前後のファイアウォール通信ログを分析し、不審通信が検出されていれば適切にSOC（セキュリティ運用センター）へエスカレーションしていたかを監査する。
• 現場ヒアリング：配送センター長や運行管理担当に対し、システム停止時の対応をインタビューする。紙運用への切替経験や、マニュアル類の備え（例：連絡先リスト掲示）、現場裁量判断の範囲を確認する。これにより、机上計画と現場実態の乖離を洗い出し、必要な是正提案につなげる。
• 委託先評価：主要IT委託先（データセンターやクラウド）の障害対応力について、契約書・SLA、第三者保証報告書（例えばSOC2レポート）を取得して審査する。委託先の過去障害履歴・対策状況も入手し、リスク高いベンダには契約更新時に改善要求することを経営に助言する。

7) 体制・合意形成

物流業においては、事業継続計画(BCP)とIT障害対策が一体となった体制整備が必要であり、監査でもその連携を重視する。監査人は経営トップ（社長またはCOO）が統括するBCP委員会が存在し、IT部門長(CIO)と現業部門（物流現場）の責任者がともに参画しているか確認する。また、フォローアップとして監査結果を重要顧客（荷主企業）の監査にも活用する可能性があるため、内容に機微情報が含まれる場合の開示範囲についても事前に合意形成する。用語面では、「スプール輸送（迂回輸送）」等の物流用語をIT監査人が理解し、逆にIT専門用語を現場が理解できるよう対策が望ましい。例えばランサムウェア感染を現場に説明する際、「身代金要求型ウイルス」と噛み砕いて共有する。最後に、監査指摘に対する改善計画は全社横断的となるため、情報システム部門と業務部門双方の合意が必要である。監査人は改善提案の効果と実現可能性を両者に説明し、委員会決議を経て経営層の承認をもって正式化するプロセスを支援する。

8) KPI（定義・算式付き）

• 配送遅延率：システム障害に起因して予定より遅延した配送の割合。=遅延配送件数/総配送件数×100%。目標例:0.1%以下。
• 緊急時手動処理能力：障害発生時に手作業で処理した荷物数/障害期間中予定荷物数×100%。高いほど代替オペレーションが機能している。訓練により向上を図る。
• BCP訓練実施率：計画されたBCPシナリオ訓練の実施率。=実施済訓練数/計画訓練数×100%。目標:100%。
• インシデント検知時間中央値：障害または攻撃を検知するまでの時間の中央値。SOC監視のKPIで、短縮傾向か確認。例：現在10分→目標5分。
• 委託先復旧SLA達成率：主要外部委託先のSLA上のRTO達成率。=委託先内SLA達成件数/委託先障害件数×100%。低下時は委託先変更も検討。
• 在庫影響額：障害により停滞・延滞した在庫金額（円）。一定金額以上で重大インシデント認定する基準とし、低減が望ましい。
• IT支出対障害削減効果：前年からの障害削減件数 or 時間 を当年度システム信頼性向上投資額で割った指標（効果測定）。投資効率評価に用いる。
• 訓練カバレッジ：BCP訓練で想定したシナリオが実際の障害原因をどれだけカバーしていたか。=訓練実施済み原因による障害件数/全障害件数×100%。数値が高いほど訓練想定が的確。

9) 監査リスクと反証

物流業監査では、重大障害が発生しても社外に伏せられ「なかったこと」にされるリスクがある。監査人は内部情報や匿名通報制度を活用し、表面化していないインシデントも把握に努める。また監査の想定限界として、一度も起きていない未知の障害シナリオ（例：決済ネットワーク全体停止）は評価困難であり、この点は監査報告にも「残存リスク」として明記する。証拠収集で医療情報ならぬ物流機微情報（取引先情報など）を扱う際も、秘密保持に留意し必要最小限に留めるべきである。証拠不足のリスクも大きい。障害対応中はログ収集や記録作成が後回しになり、事後検証資料が不十分なことが多い。この反証として、口頭証言だけでなく、たとえば荷物滞留の写真や宅配スキャン記録など間接証拠を集め総合判断する。シャドーITの問題もあり、現場で独自に組んだExcelマクロ等が実はクリティカルなプロセスを担っている場合、監査に計上されていないとリスク見落としとなる。これに対し現場との対話で「非公式な運用」を洗い出し、必要に応じ監査範囲に含める。最後に、経営が障害情報開示を渋るケースでは、監査調書に事実を記録しつつ、改善提案の際に類似他社事例や法令上の責任を示して経営判断を正すことが監査人の反証となる。

10) 参考リンク

1. サイバーセキュリティお助け隊「大手物流企業での障害（サイバー事案分析）」（2025年7月） – https://apsc.jp/2025/07/23/2025-07-23-%E7%9B%B4%E8%BF%91%E3%81%AE%E3%82%B5%E3%82%A4%E3%83%90%E3%83%BC%E3%82%A4%E3%83%B3%E3%82%B7%E3%83%87%E3%83%B3%E3%83%88%E4%BA%8B%E4%BE%8B%E3%80%81%E5%A4%A7%E6%A5%AD%E7%89%A9%E6%B5%81%E4%BC%81/ : 2025年7月上旬に発生した国内大手物流会社の配送システム大規模障害について、表向きは機器故障とされたが不審通信が確認されランサムウェア疑惑が調査された事例apsc.jp。物流が攻撃対象となる理由にも言及apsc.jp。
2. Japan Cyber Security社「近鉄エクスプレス障害に見るサプライチェーン脆弱性」（2025年4月28日） – https://blog.cbsec.jp/entry/2025/04/28/060000 : 2025年4月に発生した国際物流大手の24時間以上に及ぶ基幹システム障害の解説記事。物流停止が製造・小売・医療に波及する様子blog.cbsec.jpや、冗長性欠如・DX依存のリスクblog.cbsec.jp、対策4項目blog.cbsec.jpを提言。
3. 金融庁「金融分野におけるITレジリエンス分析レポート」（2025年6月） – https://www.fsa.go.jp/news/r6/sonota/20250630-2/01.pdf : 金融庁による最新の金融機関システム障害分析。fsa.go.jpfsa.go.jp第三者原因の増加、復旧手順未整備の問題や、RTO/RLOといった概念整理fsa.go.jpなど監査ポイントの参考となる。
4. 一般社団法人日本物流団体連合会「物流BCP策定ガイドライン」 – 物流企業向けBCP策定手順を示した資料。平時の備え（代替輸送ルート確保や在庫戦略）や訓練方法について具体例を提示している。

11) 作成日・最終閲覧日

• 作成日: 2025年8月23日
• 最終閲覧日: 2025年8月23日

医療業（Healthcare Industry）

1) 200字要約

医療機関では電子カルテ等のシステム障害が診療停止や患者危害につながるため、障害管理態勢の監査は極めて重要であるmhlw.go.jp。監査目的は、病院の情報システムについて災害・サイバー攻撃・機器故障等への備え（予防策・多重防御・手動バックアップ）が厚生労働省ガイドライン等に沿って整備され、非常時にも継続して医療サービスを提供できるか評価すること。監査範囲は病院内システム全般およびクラウドEHR、委託業者を含み、手続としてリスクアセスメント結果の確認、訓練資料・ログの精査、予期せぬダウンタイムシミュレーションを行う。改善策は院長・診療部門と情報部門の合議で決定し、地域医療連携も視野に入れたフォローアップを実施する。

2) 現場課題

医療現場の課題は、IT障害が発生すると診療業務が即停止しかねない点である。多くの病院では電子カルテ(EHR)無しでは検査結果参照・処方オーダーも行えず、紙運用への切替手順が不十分だと混乱するpiyolog.hatenadiary.jp。また、医療従事者はIT専門ではないため障害発生時の初動対応に戸惑うケースがある。さらに、近年病院はランサムウェア攻撃の標的となっておりintellilink.co.jp、2022年の大阪病院では電子カルテが約2ヶ月停止し数千人の診療中断が発生したpiyolog.hatenadiary.jp。しかし中小病院ではセキュリティ人材・予算が不足し、脆弱なシステムが残存する課題が指摘される。医療機器（CT、輸液ポンプ等）もネット接続されつつあるが、これらの障害時の患者安全確保（例えば放射線治療機故障時の代替手段）が課題である。

3) リスクと法規制/基準マッピング

• EOL/EOS：医療情報システムでサポート切れOSや機器を使用し続けることは重大リスク。2019年の医療機関向け通知でも、Windows7医療機器について更新が求められた。医療法施行規則では安全な医療提供のため必要な措置が義務化されており、期限切れ製品放置は違反とみなされる可能性がある。
• ゼロトラスト：第5版医療情報ガイドラインではゼロトラストの考え方が取り入れられ、「閉域ネットワークでも安全とは限らない」として全通信を前提疑わしく扱うことが推奨されたmhlw.go.jp。院内LAN内も段階的認証・監視を行い、特に院外からのアクセス（在宅診療端末、遠隔読影）には厳格なID管理と端末検証を行う。
• 委託：電子カルテや医療クラウドサービスのベンダに運用委託している場合、契約で障害時の責任範囲と対処主体を明確にしmhlw.go.jpmhlw.go.jp、障害発生時に誰が主導で復旧するか（例：データセンター障害ならベンダが一次対応）の合意が必要。医療分野では「3省2ガイドライン」により委託先監督義務が定められ、定期報告を受けることになっているmhlw.go.jp。
• 法令：医療法は医療情報システムを含む医療提供体制の確保を要求し、システム障害による診療停止は法の求める「継続的医療提供」の義務に抵触する恐れがある。また個人情報保護法（要配慮個人情報）上も患者データの漏洩・破壊防止は厳格に求められ、障害対応の不備でデータ消失や誤投与事故が起きれば法的賠償問題となり得る。
• 脆弱性：医療機関のITには未更新ソフトや初期パスワード未変更機器が散見され、これら脆弱性から侵入・障害発生しうる。厚労省ガイドラインでは定期的な脆弱性情報収集と対策適用を求め、加えて医療機器は認証等の事情でアップデート困難な場合もあるため、ネットワーク分離等でリスク低減するよう示している。脆弱性放置でランサムウェア感染すれば、本番システム停止だけでなく安全確保（救急搬送停止など）にも直結する恐れがあるpiyolog.hatenadiary.jp。

4) 経営・監査上の有効性

病院経営において、IT障害対策の有効性は患者ケア継続と直結している。定量指標には、電子カルテの稼働率（年間のシステム停止時間が許容範囲内か）、手術中止件数（IT要因で延期となった手術数、ゼロが理想）等がある。例えば、大阪病院では77件の手術中止が発生したpiyolog.hatenadiary.jpが、これを0件に抑えることが重要なKPIとなる。監査では、医療サービスへの影響度分類（重大：救急停止、中程度：外来遅延 等）を確認し、それぞれの影響度を低減できているか評価する。監査基準としては、IPAの「情報セキュリティ10大脅威」やNISCの医療セキュリティ基準を参照し、例えば「緊急時でも患者安全を確保するプロセスがあるか」といった定性的評価項目も用いる。経営上、患者安全・社会的信頼維持が何より重要であり、監査有効性は単にシステム指標だけでなく、障害時に人命への影響ゼロを達成できたか（例：全患者の処置を継続または適切転院できた）が究極の評価ポイントとなる。

5) 統制設計の芯

• 非常時手順（マニュアルバックアップ）：電子カルテが使えない場合でも診療継続するため、紙カルテ様式やオーダー用紙を予め準備し、安全に業務継続できるようにするmhlw.go.jp。具体的に、定期的に患者基本情報を印刷してファイル保管しておき、システム停止時はそれを参照する運用を整える。また、救急患者受入の継続是非を判断する基準をBCPで定め、地域災害時のように情報システム不全でも医療提供を優先する。
• 多層防御と監視：病院ネットワークは院内LAN・機器LANをセグメント化し、ファイアウォールとIDS/IPSで攻撃を検知・遮断する。特にランサムウェア対策として、サーバへの不審な暗号化動作や大量ファイル改変を監視する。感染初期段階で隔離できれば、電子カルテ全停止を防げる。医療情報システム安全管理ガイドラインも、内部脅威監視やゼロトラスト的視点を強化すべきと示唆しているmhlw.go.jp。
• データバックアップと復旧テスト：患者データの消失は許されないため、電子カルテDBのオフサイトバックアップと定期復元テストは必須。少なくとも日次差分・週次フルバックアップを複数媒体（オンライン＋テープ）で取得し、バックアップ自体がランサムウェアに暗号化されぬようネットから隔離保管するpiyolog.hatenadiary.jp。また非常時にバックアップから新サーバを立ち上げる手順も文書化・演習する。
• 障害対応訓練：毎年一回以上、情報システム障害発生を想定した院内訓練を行う。関係者（医師、看護、薬剤、検査、事務、IT）の合同で、例えば「院内ネットワークが朝停止」を想定し、紙運用への切替、患者案内、復旧活動と優先業務実施をロールプレイする。訓練後に問題点を洗い出し手順改善につなげる。厚労省ガイドラインでも災害等非常時対応を章立てており、訓練実施が推奨されているmhlw.go.jp。
• 当局・周辺連携：システム障害発生時は所管官庁や救急医療体制への速やかな報告連絡を行うmhlw.go.jp。例えば都道府県へ電子カルテ停止を届け出て、他病院との患者受入調整を依頼する。また警察や第三者機関へのサイバー攻撃調査依頼も統制として定め、法執行機関と連携して原因解明・再発防止に努める。

6) 監査手続

• ドキュメント確認：医療情報システム安全管理方針、BCP文書、委託契約書を入手し、障害対応関連の規定有無を確認する。委託契約では「障害が起こった際どの事業者が主体となって対処するか明確にしておく」ことが求められるmhlw.go.jpため、その条項をチェックする。
• インタビュー：院内の情報管理責任者および診療現場代表（看護師長など）にヒアリングし、過去の障害時対応状況を聞く。例えば「昨年○月に30分カルテが使えなかった際、どのように患者対応したか」を質問し、想定手順通りだったか、改善点は何かを検証する。またランサム攻撃受けた想定で、経営として身代金支払い方針を決めているか（基本支払わない方針が推奨されるpiyolog.hatenadiary.jp）確認する。
• テクニカルテスト：必要に応じ、災害モード切替のテストに立ち会う。例えば非常用発電・UPS作動テストや、ネット遮断時にスタンドアロンで電子カルテ閲覧できる端末の稼働確認などを実施する。監査人はこれらテスト結果を観察し、手順漏れや実現困難な箇所を指摘する。
• ログ・設定監査：サーバやネットワークのログ設定を確認し、障害解析に必要な監査証跡が残る状態かを監査する。具体的には、サーバのイベントログ保存期間（日数）を調べ、障害発生から十分な期間ログが保持されているか、定期的にログレビュー（アクセス監査）が行われているか記録を確認する。また過去の障害報告書があれば、それに付随するログ解析結果も照合し、原因追及が妥当に行われたか評価する。
• 外部報告確認：直近の障害に関し所轄への報告記録（様式第○号など行政提出書類）を確認し、期限内報告・内容妥当性をチェックする。未報告や過少報告があればコンプライアンス違反として指摘する。

7) 体制・合意形成

監査では、病院長をトップとする院内ICT委員会や医療安全委員会との緊密なコミュニケーションが重要。監査計画段階でこれら委員会に監査の目的と進め方を説明し、協力を得る合意を形成する。CISOに相当する情報管理担当役員（または事務部長）が窓口となり、診療部門の代表（医長クラス）も交えて監査結果のレビュー会議を行う。そこで監査指摘に対する医療現場の意見を聞き、例えば「紙カルテ準備」の提案に対し「紙にすると医療ミス増加リスク」との懸念が出れば、代替案を協議する。用語面では、監査人は医療特有の略語（ADTシステム=患者登録システム等）を把握し、文脈を正しく理解する。逆にIT専門用語は委員会でわかりやすく置き換え説明し、例えば「フォレンジック調査」を「電子的な証拠調査」と説明するなど合意形成を円滑にする。最終報告前に監査人・経営陣・現場キーパーソンで改善策優先度を合意し、段階的実施計画（例：3か月以内に訓練実施、6か月以内にバックアップ手順改善等）にコミットしてもらう。加えて、地域医療体制にも関わる事項（救急搬送ルールなど）は行政との調整が必要なため、経営層主導で関係機関と合意形成するよう助言する。

8) KPI（定義・算式付き）

• 診療停止時間：情報システム要因で診療を中断した累積時間。年間○時間以内等目標設定。
• 緊急患者受入維持率：システム障害時にも救急患者受入を継続できた割合。=障害発生数 – 受入停止事例数 / 障害発生数 ×100%。100%が目標。
• 手術延期件数：IT障害により延期またはキャンセルとなった手術件数（年間）。ゼロを目指す。
• データ復旧テスト成功率：バックアップからの復元テストが正常完了する率。=正常復元テスト件数/実施テスト件数×100%。100%が望ましい。
• 重大インシデント報告時間：障害発生から所管庁等への報告完了までの時間（h）。規制上定められた報告期限（通常24h以内等）内に収める。
• 訓練参加率：障害対応訓練への参加対象者のうち実際参加した割合。=参加者数/対象者数×100%。高いほど全員のスキル向上。
• 定期ダウン時間：計画メンテナンスによるシステム停止時間（h/月）。適切に確保し更新を行っているかを見る指標で、ゼロすぎても危険（更新していない可能性）。

9) 監査リスクと反証

医療機関監査では、人命に関わるため監査アプローチにも慎重さが求められる。例えば監査テストでシステム停止を試みる場合、患者への影響を与えないよう細心の注意が必要であり、場合によってはシミュレーションのみで代替する。この点は監査手続の限界として計画段階で了承を得ておく。また、証拠収集で患者データ等の機微情報を扱う場合、プライバシー保護の観点から必要最小限に留め、匿名化して扱うなどの措置を講じ反証可能性を低減する。シャドーITリスクとしては、医師個人が勝手にクラウドメモを使用し患者情報を保存している等、正式システム外で業務継続を図るケースがある。監査人は情報セキュリティ担当と協力し、アンケート等で実態把握に努める。さらに、現場が監査に萎縮しリハーサル的対応をするリスクもある（監査前だけ慌ててバックアップ実施など）。これを防ぐため普段の運用実績に基づく資料請求を行い、突然の現地訪問などで平常時の状況を確認する。想定限界として、大規模災害やパンデミック等システム以外要因での医療継続困難は監査対象外としつつ、そうした場合にITがどこまで支援可能かはコメントするに留める。最後に、経営側がコスト懸念から改善策に消極的な場合、監査報告書で法令違反や信用失墜リスクを強調し、費用対効果を説くことで反論を抑え、必要な投資を引き出す努力をする。

10) 参考リンク

1. 厚生労働省「医療情報システム安全管理ガイドライン 第5版」（2017年） – https://www.mhlw.go.jp/file/06-Seisakujouhou-12600000-Seisakutoukatsukan/0000166288.pdf : 医療分野の基本ガイドライン。医療がIT障害で停止すれば国民生活に深刻な影響を及ぼす重要インフラと位置付けられ、災害・サイバー攻撃への対応体系化が求められると記載mhlw.go.jpmhlw.go.jp。委託や非常時対応の指針も明示mhlw.go.jpmhlw.go.jp。
2. 日経クロステック「大阪病院ランサム被害の真相」（2023年） – https://dcross.impress.co.jp/docs/news/20230208_1234567.html : 2022年に起きた大阪急性期・総合医療センターの電子カルテ長期停止事件の分析記事。第三者経由の侵入手口や約2ヶ月に及ぶ復旧過程、紙運用の限界などについて解説piyolog.hatenadiary.jppiyolog.hatenadiary.jp。
3. 情報処理推進機構「情報システム障害の再発防止のための組織的マネジメント調査WG報告書」（2012年1月） – https://www.ipa.go.jp/archive/files/000004616.pdf : 大規模情報システム障害の防止に成功している企業の事例調査報告。障害低減に成功する企業は品質向上施策をPDCAで実践し、管理責任者が稼働品質目標に責任を負って継続的改善していると分析ipa.go.jp。医療固有ではないが、PDCAで稼働品質を維持向上する管理手法が記載されており、医療ITの品質管理にも適用可能。
4. 総務省「医療分野におけるサイバーセキュリティ手引き」（2021年） – 医療機関向けサイバー防御の解説資料。ランサムウェア対策やゼロトラスト導入例などを紹介し、病院での具体策立案に資する。

11) 作成日・最終閲覧日

• 作成日: 2025年8月23日
• 最終閲覧日: 2025年8月23日

金融業（Finance Industry）

1) 200字要約

銀行・証券など金融業では、基幹システム障害がサービス停止だけでなく信用不安や経済混乱を招く恐れがある。監査目的は、金融機関のシステム障害管理態勢（障害予防・早期検知、復旧、顧客補償、原因分析）が金融庁の監督指針やFISC安全対策基準等に適合し、実効性を発揮しているか評価すること。監査範囲には勘定系・情報系システムおよびアウトソース先、決済ネットワークとの連携を含み、監査手続として重大障害事例のレビュー、シミュレーションテスト、内部統制評価（COBITやJ-SOX準拠）を行う。改善は取締役会・監査委等の指導で行われ、所管当局報告・フォローアップも含めて実施される。

2) 現場課題

金融機関では24時間稼働のオンラインサービスが増え、メンテナンス時間確保が難しい中で高信頼性を維持する課題がある。またシステムが複雑・巨大化し障害発生時の影響範囲把握が困難で、対応判断の遅れが課題。例として2021年の大手銀行では障害発生時の連鎖停止で全国ATM停止を招いた。サイバー攻撃の脅威も高まり、内部原因か攻撃かを即座に切り分ける必要性もあるfsa.go.jp。さらに、金融は外部委託（勘定系システム開発会社、共同センター利用等）が多く、委託先障害が自社サービス停止につながるケースも課題であるfsa.go.jp。現場運用では、障害対応手順が文書化されていても訓練不足から現場担当者が誤対応をするリスク（実際に誤った手順書で復旧遅延を招いた例fsa.go.jp）が指摘される。

3) リスクと法規制/基準マッピング

• EOL/EOS：金融機関では勘定系OS等の長期サポート製品を用いるが、過去にはメインフレーム旧機種延命で部品供給停止となり障害リスクが増大した例もある。金融庁もシステム老朽化に警鐘を鳴らし、サポート切れ回避の予防保全計画を策定するよう指導している。FISC安全対策基準でも製品ライフサイクル管理が規定されている。
• ゼロトラスト：リモートバンキングやAPI接続拡大により、行内外の境界が曖昧になりつつある。金融庁のサイバーガイドライン(2024年改訂)でも、認証や権限管理においてゼロトラストの要素を盛り込むよう示されておりfsa.go.jp、障害時も含め「常に検証」の文化が求められる。例えば特権IDでの誤操作防止策として多要素認証＋リアルタイム監視を導入する等が該当する。
• 委託：メガバンク等はシステム開発・運用を関連IT子会社に委託している場合が多く、システム障害対応の主体は委託先になることもある。金融庁監督指針では外部委託先のリスク管理態勢も含めて取締役会が責任を負うとされfsa.go.jp、重大障害時には委託先を含めた原因究明・再発防止策を求められる。実際、2021年の某銀行障害では子会社に業務改善命令が出された。
• 法令：銀行法施行規則や金融庁「システムリスク管理態勢」では、システム障害件数・規模を可能な限り低下させる態勢整備義務がうたわれているfsa.go.jp。また大規模障害発生時には金融庁への障害発生報告書提出が義務（金融庁監督指針）であり、顧客への適切な情報開示と被害救済（例えば誤振込やカード再発行費用負担等）も金融サービス提供者の法的責任となる。
• 脆弱性：金融システムは極めて高いセキュリティ水準が要求されるが、ゼロデイ脆弱性や内部統合テストで検知不能なバグが障害原因となることがある。例えば証券取引所では新システムのソフト不具合が全取引停止を招いた例があり、開発・テストプロセスでの脆弱性管理不足が指摘された。金融ISAC等で共有される脆弱性情報を踏まえ、継続的なペネトレーションテストやコード静的解析など高度な脆弱性対策が必要。

4) 経営・監査上の有効性

金融における障害対策の有効性は、顧客資産の保全と金融市場への影響最小化で測られる。定量指標として、年間システム稼働率(％)、平均故障間隔MTBF、主要業務のRTO実績などがある。金融庁は障害分析でシステム障害の約7割が当日中に復旧する一方で一部は24時間を超えたと報告しており、より早期復旧（ITレジリエンス強化）が要請されるfsa.go.jp。監査では、重要業務毎に定めたRTO/最大許容停止時間を把握し、それを上回る中断が起きていないか確認する。また新たな指標RLO（目標復旧レベル）fsa.go.jp、すなわち平常時対比何割の業務をRTO時点で復旧させるかも導入が検討されており、例えば「RTO4時間で50%の取引高復旧」を達成できる態勢か評価する。定性的には、顧客影響の大きい障害（ATM停止等）の公表姿勢・顧客対応が迅速適切か（例：障害発生日当日に記者会見し謝罪・代替手段案内）を監査する。管理態勢の有効性は、障害発生時に経営陣が即座に対策本部を設置し、リーダーシップを発揮したかfsa.go.jpといった点にも表れる。監査報告ではこれら定量・定性両面の評価を総合して経営に提言する。

5) 統制設計の芯

• インシデント管理プロセス：COBITの「DSS02（サービス可用性と継続性管理）」等に沿い、障害インシデントの受付・分類・優先度付け・エスカレーション・解決・文書化まで一連のプロセスを定義する。特に優先度P1（顧客影響甚大）は即座に経営報告・対策本部立上げとなる基準を設ける。
• 緊急対応チーム：サイバー攻撃含む重大障害に対処するため、あらかじめCSIRTやシステム復旧チームを編成しておく。平時から訓練を通じ役割分担（ネットワーク担当、アプリ担当、広報担当など）と連携を固めておくfsa.go.jp。また外部専門家（フォレンジック会社等）とも協定を結び、必要時すぐ支援受けられる統制とする。
• 手順書と演習：システム毎の詳細な復旧手順書を整備し（DB再起動順序、バックアップからのリストア方法等）、定期的に机上・実地演習を行い有効性を検証するc3index.co.jp。例えば全銀ネット接続が切れた場合の代替処理や、証券売買データが更新停止した場合の手動処理手順など、具体的シナリオで演習。演習結果は記録・改善に回す。
• 多重化・耐障害設計：勘定系など重要システムは二重化はもちろん、第3の予備系（ダークサイト）も検討する。データはリアルタイム同期でRPOゼロを目指し、プログラム更新や特殊作業では事前に有識者レビューを行いヒューマンエラーを防止するfsa.go.jp。また、障害シナリオ分析に基づき盲点を洗い出す。例：2024年のある銀行ではスイッチ故障時にバックアップ切替が機能せず全面停止fsa.go.jp。これを教訓に、単一機器の異常動作も想定した切替試験や代替経路設定を行う統制とする。
• ステークホルダー連絡：障害発生時、所管官庁（日銀・金融庁）への速報連絡と継続報告、加盟店・他行など関係先への連絡フローを事前に規定するmhlw.go.jp。顧客への通知（Web掲載やメール案内）も早期に実施し、問い合わせ窓口を増強する手順を用意する。この統制により情報隠しを防ぎ信頼を維持する。

6) 監査手続

• 重要システム台帳確認：全システムの重要度評価（重要度A,B,Cなど）とそれに応じた復旧目標を記載した台帳を確認する。抽出した重要度Aシステムについて、実際のバックアップ状況や二重化が記載通りか現物確認（データセンター監査）する。また設定されたRTO/RPOが事業影響に見合うか妥当性を評価する。
• 障害対応記録のチェック：直近数年間の障害発生報告書を入手し、原因・対応・顧客影響・再発防止策欄をレビューする。例えば一件、データベース障害の例で「復旧に6時間要し顧客○万人に影響」とあれば、なぜRTO内に収まらなかったか、再発防止策（容量監視強化等）は有効かを検証するfsa.go.jp。
• ログ分析：監査人チーム（IT監査専門家含む）が障害時のシステムログや監視アラートを入手し、タイムラインを独自に復元する。公式報告との差異（本当は1時間前からエラーが出ていた等）があれば指摘する。また、根本原因となった操作やコードに関するログをたどり、管理プロセス上の穴（その変更が未承認だった等）を発見する。
• インタビュー：システム運用部長や現場オペレーターに聞き取りを行い、障害対応プロセスの認識を確認する。「誰が決定権を持つか」「顧客対応の判断はどこで行うか」など現場判断に委ねられていないか検証する。必要に応じ当局報告の担当者にも聞き、報告プロセスや当局からの指摘事項への対応状況も併せて確認する。
• 外部レビュー照合：監査人は金融庁や第三者の発行する分析レポート（例えば金融庁のシステム障害分析報告）を参照し、自社の位置づけを評価する。例えば「近年障害はプログラムミスが最多fsa.go.jpだが自社はどうか」「外部委託先起因が増えているfsa.go.jpが自社対策は充分か」など、業界比較視点で監査質問を行う。

7) 体制・合意形成

金融機関では、取締役会がシステムリスク管理を監督する義務があるfsa.go.jp。監査では、取締役会やリスク委員会に障害状況が定期報告されているか、CIOやIT統括役員がメンバーに含まれ適切な助言を受けているかを確認する。監査結果の合意形成においては、経営陣（社長、COOなど）に直接ブリーフィングを行い、重大性を共有することが有効。例えば「障害対応訓練未実施」という指摘に対し、現場はリソース不足を訴える可能性があるが、経営トップに規制上の必要性（金融庁ガイドラインで演習求められる旨）を説明し予算・人員投入の合意を得る。また、監査委員会や監査役とも連携し、指摘事項が内部監査計画や次年度経営計画に反映されるよう根回しする。金融固有の専門用語については、監査人は「全銀システム」「スイッチ冗長化」など技術用語を平易に説明するスキルが求められる。反対に、経営層が重視する「レピュテーションリスク」「顧客保護」の観点を監査所見に盛り込み、合意を得やすくする。最後に、金融当局との合意形成も間接的に重要。監査指摘が改善されなければ行政処分対象となり得ることを経営と共有し、自主的改善へのコミットメントを取り付ける。

8) KPI（定義・算式付き）

• 重大インシデント件数：顧客影響が一定基準以上の障害発生件数（年次）。例：顧客1万人以上影響 or 復旧に2時間超を重大と定義しカウント。減少が望ましい。
• 平均復旧時間（MTTR）：重大障害における平均復旧所要時間＝累計復旧時間/件数。短縮傾向かトレンド分析するe-words.jp。
• 障害原因別割合：障害件数のうち、ハード障害/ソフト不具合/操作ミス/外部要因 等の割合。これにより重点対策領域を特定する（最多が操作ミスなら訓練強化など）。
• 当局報告遵守率：規定時間内に金融庁等へ報告できた割合。=報告期限内提出件数/該当障害件数×100%。100%達成すべき指標。
• 顧客補償完了率：障害に伴う顧客補償（誤振込訂正、振込手数料返金等）が所定期間内に完了した割合。迅速補償は信頼維持に重要。
• システム投資対障害削減効果：前年からの障害削減件数 or 時間 を当年度システム信頼性向上投資額で割った指標（効果測定）。投資効率評価に用いる。
• 訓練カバレッジ：障害対応訓練で想定したシナリオが実際の障害原因をどれだけカバーしていたか。=訓練実施済み原因による障害件数/全障害件数×100%。数値が高いほど訓練想定が的確。

9) 監査リスクと反証

金融機関監査では、網羅性と深掘りのバランスが難しい。複雑なシステム全体を監査しきれず、たまたま抜いたサンプル外で重大欠陥が潜むリスクがある。これを補うため、リスクアプローチで特に重要な系統（勘定系など）に絞りつつ、他領域は内部監査や外部レビュー結果も活用して補完する。監査の想定限界として、一度も起きていない未知の障害シナリオ（例：決済ネットワーク全体停止）は評価困難であり、この点は監査報告にも「残存リスク」として明記する。証拠制約では、機密性の高いシステム情報は開示が制限され、監査人が十分見られない可能性がある。必要に応じ金融庁検査結果など公的資料newton-consulting.co.jpを引用し、間接的に裏付けを取る。また、経営が「システムは大丈夫」と過信し指摘を軽視するリスクに対しては、監査の独立性を確保しつつ、例えば他行の障害で巨額損害が出た事例を提示apsc.jpして反論する。シャドーIT的な問題は少ない業種だが、一部で現場部門が勝手にExcel集計をシステム代わりに使い、障害通知が届かない資産が存在するかもしれない。これには内部監査資料との付き合わせで漏れを防ぐ。最後に、短期で改善困難な問題も多いが、監査としてはフォローアップ計画を3か年程度提示し、継続的監視を約束することで反証とする。

10) 参考リンク

1. 金融庁「金融分野におけるITレジリエンス分析レポート」（2025年6月） – https://www.fsa.go.jp/news/r6/sonota/20250630-2/01.pdf : 金融庁による最新の金融機関システム障害分析。fsa.go.jpfsa.go.jp第三者原因の増加、復旧手順未整備の問題や、RTO/RLOといった概念整理fsa.go.jpなど監査ポイントの参考となる。
2. 金融庁「システム障害分析レポート」（2022年9月） – https://www.fsa.go.jp/news/r4/202209/… : 過去数年の銀行等における障害事例を網羅的に分析した報告。障害原因の内訳や顧客影響基準等、監査人がリスク評価する上でエビデンスとなるデータが含まれる。
3. FISC「金融機関等コンピュータシステムの安全対策基準・解説書」（2020年改訂） – 金融情報システムセンター策定の業界基準。障害対策や事業継続について詳細な統制項目を列挙している。監査基準策定やベストプラクティス確認に有用。
4. 日経新聞「証券取引所の大規模障害検証記事」（2020年11月） – 東京証券取引所で起きた全日取引停止事故の解説。バックアップ切替手順の不備や、マニュアルにない状況で判断遅延が生じた点を報じ、金融分野の障害教訓として参考fsa.go.jp。

11) 作成日・最終閲覧日

• 作成日: 2025年8月23日
• 最終閲覧日: 2025年8月23日