重大なインシデントの早期解決と再発防止について
AI生成の参考答案（架空）
問題・答案ともに独自教材です。実際のIPA過去問・公式解答ではありません。年度・季節は教材の整理用ラベルです。論述構成を学ぶために過去問AIが生成した架空の参考例で、合格を保証するものではありません。論述の骨格・業種事例の参考としてご活用ください。
問題概要
ITサービスマネージャは、自身が責任を持つITサービスにおいて、業務影響度の大きい重大インシデント（メジャーインシデント）を、限られた情報と時間制約のもとで早期に解決し、サービスを安定状態に復旧させる責務を負う。同時に、再発防止のための問題管理を主導し、根本原因を究明したうえで恒久対策をサービス基盤に組み込む必要がある。
全文を表示
業種を選択してください
製造業の参考答案例
約 2,022 字序論（設問ア）
私が責任を担っていたのは、自動車部品メーカA社のMES、品質管理、在庫管理を結ぶITサービスである。国内3工場、海外2工場が本社のクラウドDBを利用し、私はITサービスマネージャとして運用を統括した。目標は対象生産時間帯の可用性99.97％以上、製造指示の応答3秒以内であり、可用性が下回る場合や応答時間が超える場合に重大影響がある。 月曜早朝、特定SQLの処理時間が急増し、各工場へ指示を配信できなくなった。発生30分後には主力工場のラインが停止した。90分後に承認済み指示を使う限定運転を再開したが、クラウド経由の全機能復旧は発生4時間20分後だった。約2,400台分の生産計画に影響し、直接損失は約8,200万円と試算された。 私は限定運転の再開と全面復旧を区別し、工場別の安全な継続範囲を確認しながら、業務回復と原因調査を並行して進める必要があった。
本論（設問イ）
私は監視通知と工場からの連絡を受け、指示配信が複数拠点で止まったことから重大インシデントを宣言した。対応責任者、記録係、技術班、工場連絡担当を決め、品質保証部と工場長へ影響を確認した。共有DBの問題を疑ったが、原因を断定せず、工場ごとの指示到達状況と安全に継続できる作業を一覧にした。 技術班は復旧班と調査班に分けた。復旧班には新しい指示の無制限な再要求を抑え、失敗要求と未配信指示を保存させた。DBを突然停止して別の処理まで壊さないよう、影響の少ない集計処理から止める。工場には承認済みの指示だけを用いる限定運転を提案し、工場長と品質保証部が適用版を確認した範囲で90分後に再開した。未知の設計変更を推測して製造することは認めなかった。 私は15分ごとに判明事実、影響、実施中の対応、次回更新時刻を共有した。海外工場には現地の営業開始を待たず当番へ連絡し、顧客には営業窓口から初報を出した。復旧予定が未確定な段階で時刻を約束せず、限定運転と通常サービスの違いを説明した。 調査班は障害前後のSQL実行計画、統計更新履歴、CPU、I/O、待機情報を採取した。問題SQLで読み取る行数が急増し、統計情報の更新直後に結合順序とアクセス方法が変わったことを確認した。更新前の統計と計画を検証環境で比較し、同じデータと同時実行条件で遅延を再現した。統計更新があったという時系列だけで原因とせず、計画変更と性能劣化の対応を確かめた。 復旧は検証済みの計画へ戻す方法をDB担当と確認し、変更記録を残して適用した。待機要求を一度に解放せず、指示配信を工場ごとに再開する。未配信件数、重複指示、品質履歴を照合し、発生4時間20分後に全機能を復旧した。限定運転中の実績も回収して通常運用へ戻した。 原因は統計更新を実負荷と独立に実行していた運用と、重要SQLの計画変化を事前評価していなかった変更管理にあった。私は復旧操作で証拠を消さないようログを保全し、担当者個人のミスだけで調査を終わらせず、更新前の試験と承認が抜けた経緯を確認した。 課題は、限定運転中の指示と復旧後の配信が重なり、同じロットを二重に製造するリスクだった。私は工場ごとに最後に受領した指示番号と処理済み番号を控えさせ、再開位置を品質保証部と突合してから配信を許可した。
結論（設問ウ）
私は再発防止をDB設定、監視、変更管理、連絡の四つに分けた。統計更新は日本の深夜なら安全とはせず、全工場の負荷を見て承認した保守時間へ移した。更新を止め続けると統計が古くなって別の計画が悪化し得るため、更新頻度と重要SQLの性能を併せて評価した。ここで古くなるのは最適化用の統計情報であり、業務データそのものではない。 重要SQLは検証済み計画を基準として監視し、計画固定を用いる場合もデータ量の増加に応じて見直す。実行時間、読取行数、待機件数を比較し、統計更新前後に代表処理を試験する手順を変更管理へ追加した。計画固定で将来の性能問題を全て排除できるとは考えなかった。 対策後の12か月では同じ原因の全面停止はなく、計画変化を事前確認した事例を3件記録した。私は今回の260分停止を含む期間と対策後の観測期間を分け、停止時間を含めない可用性の数字で当該年度の達成を主張しなかった。代替運転で生産できても、契約上のサービスが利用不能ならその時間を都合よく除外しない。 改善点は海外拠点の初動権限だった。現地が参照できる監視情報と、安全に実施できる一次対応を明記し、当番間の引継ぎ訓練を行う。主要顧客とも初報の窓口、内容、更新間隔を合意する。今後は訓練後の自信に関するアンケートだけでなく、影響把握、連絡、限定運転への判断に要した時間で改善を測る。復旧の速さと、正しい製造指示・履歴を維持できたかを別々に評価する。 残る課題として、生産品種が変わると代表SQLの試験だけでは負荷を再現できない。新製品の立上げ時にはロット数と履歴量を試験条件へ反映し、工場側の変更計画も性能試験の入力にする。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
建設業の参考答案例
約 2,015 字序論（設問ア）
私が責任を担っていたのは、ゼネコンB社のBIM／CIM、施工実績、現場タブレットを結ぶクラウドサービスである。約350現場、2,800台の端末が利用し、私はITサービスマネージャとして継続性と性能を管理した。 火曜9時、機械ベンダの外部API認証が失敗し、連携要求の再試行が急増した。共通の処理資源を使い切ったため、本来は外部APIに依存しない図面参照や施工指示にも影響が広がった。約280現場の午前作業が停止または遅延し、直接損失は約4,500万円と試算された。 発生2時間30分後に図面参照を部分復旧し、3時間後には新規入力を再開したが、滞留データの照合を含む通常運用への全面復旧は5時間30分後だった。私は現場の安全を確保する代替運用と、外部API障害が内部全体へ波及した原因の究明を並行して進めた。
本論（設問イ）
私は現場報告とAPI監視を照合し、重大インシデントを宣言した。現場連絡、復旧、原因調査、記録の担当を分け、現場所長に停止工程と安全上の制約を確認した。紙図面を使う場合も版と有効性を責任者が照合し、最新変更を確認できない工程は止める。作業再開の判断は技術班だけで行わず、現場責任者と合意した。 復旧班は外部APIの再試行を制限し、連携処理を共通ワーカから切り離した。機器実績の取込みは保留しても図面参照を提供できるよう、機能ごとの依存関係を確認する。並行して機械ベンダへ旧認証方式の暫定提供を依頼し、必要な接続条件を確認した。契約上の権利を推測して迫るのでなく、影響と必要な復旧期間を具体的に伝えた。 私は15分間隔で部分復旧の範囲と残る制約を所長向けに共有し、発注者には事業部の統一窓口から連絡した。2時間30分後に図面参照が戻り、3時間後に入力を再開したが、未送信や再送済みの実績が残るため、全機能正常と発表しなかった。取引識別子で重複を除き、現場件数と集計値を照合して、5時間30分後に全面復旧を宣言した。 調査班は認証失敗の応答、トークン取得履歴、設定変更、APIの公開情報を保存した。機器ベンダの変更内容を確認すると、新しいトークン取得方式への移行が行われていた。通知履歴も調べたところ、ベンダからの通知は旧担当者のメールへ届いていたが、共有窓口への引継ぎがなく、変更管理へ登録されていなかった。通知が全くなかったとする初期認識を訂正し、受信と対応の責任が空白だったことを原因とした。 さらに再試行数と共通ワーカの使用量を時系列で比較し、認証失敗を繰り返す処理が資源を占有したことを確認した。検証環境で認証失敗を発生させ、再試行制限がないと図面要求まで滞留することを再現した。外部の変更だけでなく、機能間の資源分離と失敗時の制御が不十分だったために全現場へ波及したのである。 私は通知の受領、影響評価、試験、承認、適用確認の各工程を洗い出した。現場の代替運用についても、手順書があるかだけでなく、通信断中に読めるか、図面の版を確認できるかを調査対象にした。 復旧時の課題は、端末内に残った施工実績が再送され、出来高を二重計上するリスクだった。私は現場・端末・実績番号で保留一覧を作らせ、同じ番号の内容が異なる場合は自動統合せず現場責任者へ照会した。
結論（設問ウ）
私は外部連携の処理資源を図面参照と分離し、再試行回数、待ち時間、同時接続数に上限を設けた。認証失敗が続けば連携を止めて保留し、現場へ状態を表示する。模擬障害で図面参照が継続することと、復旧後の再送で重複が生じないことを確認した。 変更通知は共有窓口で受け、担当者と代行者が影響評価を記録する。主要ベンダとは事前通知の対象、期間、互換期間を合意し、契約で得られない部分は合成監視と試験環境で補う。監視は単なるHTTP応答だけでなく、認証と代表データの取得まで実行する。ただし通知や監視で仕様変更そのものをなくせるとは評価しなかった。 代替手順はオフラインPDFとして配布し、各端末で開けることを確認した。対策後12か月の類似障害3件では平均15分以内に検知し、最大40分以内に代替運用へ移れた。私は代替運用と契約上の全面復旧を区別し、これらの時間だけから年間可用性を算出しなかった。工程遅延の回避額も、発生しなかった損失を確定利益として計上しない。 残った課題は、一部現場で手順書は読めても最新図面や変更情報を取得できないことだった。手順書のダウンロード不能という既に解消した問題と混同せず、承認済み図面の事前配布、到達確認、通信断時の作業制限を追加する。全図面を無条件に古いまま使わせない。今後は所長だけでなく作業者も訓練に参加し、指示の版確認から実績の回収までを評価する。各現場の未受領資料も一覧で確認する。 再試行を止めたまま実績の欠落に気付かないリスクも残る。現場別の最終受信時刻と保留件数を監視し、通信が戻っても未送信が残る端末を所長へ提示する。完了報告はサーバの稼働だけで閉じない。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
金融業の参考答案例
約 2,001 字序論（設問ア）
私が責任を担っていたのは、地方銀行C行のインターネットバンキングである。利用者約58万人がWebとアプリから認証基盤、勘定系API、外部決済へ接続し、私はITサービスマネージャとして運用を統括した。可用性99.99％と主要取引の応答1秒以内を行内の目標として管理していた。 祝日正午、SMSによる多要素認証コードの到着が遅れ、振込時の認証が有効時間内に完了しない事象が発生した。約2時間続き、振込操作失敗は累計約8,400件、問合せは平常の約9倍になった。SMSの委託先は当時一社だった。 私は認証を省略して振込を続けるのではなく、安全性を維持しながら送信滞留を解消し、顧客へ再操作と取引状態の確認方法を伝える必要があった。復旧と並行して、送信APIの応答だけでは見えない配送遅延を調べた。
本論（設問イ）
私はSMS遅延の監視とコールセンタの報告を照合し、重大インシデントとして対策会議を招集した。認証、取引、外部事業者との連絡、顧客案内、記録の担当を決める。取引成立前の認証失敗か、成立後に応答を確認できないものかを区別し、振込を繰り返すよう一律には案内しなかった。法務・コンプライアンス担当には報告要否と必要な手続の確認を依頼した。 復旧班は一社のSMS送信キューを調査し、期限切れの認証コードと繰り返し要求が滞留を増やしていることを確認した。認証要求の再送回数を制限し、期限切れ分を配信対象から除き、委託先へ処理能力の回復を依頼した。当時存在しない別事業者へ即時切替したとは扱わない。現在有効な要求を優先して処理し、同じ取引の複数コードが同時に有効にならないよう制御した。 私は15分ごとにコールセンタへ説明文を共有し、公式サイトにも利用できる機能と制約を掲載した。顧客にはコードを他人へ伝えないこと、取引履歴で成立状況を確認することを案内し、問い合わせが集中しても認証手続を弱めない方針を統一した。90分後から到着時間が改善し、2時間後に新しい認証要求が通常どおり完了することと、滞留処理の照合を確認して復旧した。 調査班はAPI受付時刻、配送通知、コード入力、認証成功・失敗の時刻を同じ要求識別子で結び付けた。APIが受付を返しても実際の到着が遅れる例があり、委託先の配送経路で滞留していた。利用者の再送操作が送信量を増やし、遅れて届く旧コードで失敗する循環も確認した。個人の認証コードを調査資料へ露出させず、必要な識別子と状態だけで追跡した。 根本原因は一社依存に加え、監視がAPIの受付応答に偏り、配送完了と認証成功率を捉えていなかったことである。私は委託先と事象の時間帯を突合し、検証環境で配送を遅らせて再送時の挙動を再現した。サーバを増やすだけでは末端配送が改善しないことを確認し、認証要求の流量制御、期限管理、配送経路の多重化を恒久策の候補にした。復旧判断の根拠と残る顧客対応も記録した。 復旧時の課題は、到着の遅れたSMSを正常な新規要求と誤認するリスクだった。私は認証要求の発行順と失効時刻を照合し、旧コードの入力が拒否されることを試験用口座で確認した。顧客の実口座では試験取引を行わなかった。
結論（設問ウ）
私はSMS委託先の追加と切替設計を段階的に実施した。事業者が異なっても最終的な配送経路が共通する場合があるため、独立性を確認する。切替時は現在の認証要求を管理し、旧経路から遅れて届いたコードが使えないようにする。コードの有効時間や試行回数を緩める方法では可用性を確保しなかった。 監視にはAPI受付だけでなく、配送通知の遅延、合成端末への到着、認証成功率を加えた。配送通知も全端末の到着を完全に証明するとは限らないため、顧客報告と合わせて判断する。委託先の障害、配送遅延、遅着コード、再送増加を試験し、切替後に二重の認証状態が残らないことを確認した。 対策後12か月に同種の大規模滞留はなかった。私は障害がなかった事実と、訓練で切替が成功した事実を別々に評価し、今後も絶対に起こらないとはしなかった。今回の2時間停止を含む期間と観測期間は区別し、可用性は契約の対象時間と停止定義から集計する。問合せ9倍は平常比800％増であり、900％増とは記載しない。 改善点は案内準備の不足だった。平常時から承認済みFAQを用意し、サイト、窓口、広報で同じ状態情報を使う。ただし自動応答が未確認の復旧時刻を作らないよう情報源を限定する。今後は技術復旧時間だけでなく、顧客が取引状態を確認できるまでの時間、初報までの時間を訓練で測る。新しい可用性目標を定める際は必要な構成と費用を評価し、数値を引き上げただけで信頼性が改善したとは扱わない。 残る課題は、配送遅延の監視が特定の携帯網だけを代表してしまうことである。複数網の合成端末で観測し、網ごとに遅延を比較する。端末数の増加による費用も委託先評価へ含め、重要な顧客層の見落としを防ぐ。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
流通・小売の参考答案例
約 2,028 字序論（設問ア）
私が責任を担っていたのは、小売D社の店舗POSと在庫管理サービスである。D社は約1,200店舗、8,000台のPOSを持ち、一日約180万件の取引を扱う。私はITサービスマネージャとして店舗と外部決済の連携を管理していた。 土曜の繁忙時間帯、決済代行サービスとの通信が断続的に切れた。約180店舗でレジ対応が混乱し、待ち時間は最大40分、問合せは平常の6倍になった。発生2時間後に主要カードの決済を部分再開し、2時間40分後に全体の復旧と取引照合を完了した。機会損失は約3,800万円と試算したが、対象範囲の明確でない月間売上比は付けなかった。 私は現金等の代替運用を案内する一方、応答がなくても課金済みの可能性がある取引を再決済しない管理が必要だった。早期再開だけでなく、二重請求を防いで取引の確定状態を回復することを重視した。
本論（設問イ）
私は複数店舗の報告と決済監視を照合し、重大インシデントを宣言した。決済代行への連絡、POS側の調査、店舗案内、取引照合の班を設け、店舗運営と広報を対策会議に参加させた。影響するカード種と取引状態を確認し、新規取引は利用可能な現金等の手段へ案内する。応答不明の取引は未確定として保存し、顧客にもう一度支払ってもらう前に状態を照会する方針を徹底した。 店舗へは15分ごとに状況と次回更新時刻を伝え、店頭掲示の文面を本部で統一した。利用可能な決済手段と、既に操作した顧客への案内を分ける。広報は未確認の復旧時刻を発表せず、コールセンタは注文番号等を基に確認窓口へ引き継ぐ。カード番号等を一般のチャットで集めないよう連絡項目を限定した。 復旧班は決済代行の保守作業と障害時刻を確認した。通信が切れた要求を無制限に再送せず、取引識別子で実行状態を照合する。別経路の準備は進めたが、現在の代行で成立した可能性のある取引をそのまま別代行へ送り直すことはしなかった。確実に未実行と分かった新規要求から代替方法を検討する。発生2時間後に主要カードの新規決済が戻り、保留分の照合を続けて2時間40分後に通常運用へ復帰した。 調査班はPOS、集約サーバ、代行側の受付と確定の記録を要求識別子で突合した。代行の保守変更後に通信断が増え、受付後に結果が返らない取引も存在した。通知履歴を調べると保守情報は個別担当者へ届いていたが、店舗繁忙日との照合と影響評価に回っていなかった。単に外部が故障したという結論ではなく、通知を受けて判断する運用が機能していなかったと整理した。 私は検証環境で確定後の応答を失わせ、POSが未確定状態を保持できるか試した。その結果、担当者の再操作に依存する部分があり、二重課金防止と取引照合を恒久策へ加えた。単一代行への依存、保守通知の処理漏れ、曖昧な応答時の取引管理を別の原因として扱った。 復旧後も店舗別の保留件数と照合差分を確認し、返金等が必要な場合の責任者を定めた。売上が再開した時刻だけで顧客対応を完了とせず、誤請求の有無を確認した記録を残した。 照合の課題は、決済代行の確定時刻と店舗の障害時刻のずれにより、対象取引が漏れるリスクだった。私は時刻の差を確認して抽出期間に余裕を持たせ、取引識別子と金額で照合した。差額だけが一致する相殺を正常とは扱わなかった。
結論（設問ウ）
私は決済代行を二社化したが、自動切替は確実に未実行の新規要求を対象とした。元の経路で実行済みか不明なら状態を照会し、解消まで保留する。代行をまたぐ同じ識別子だけで重複が防げるとは考えず、店舗側の取引状態管理と照合を共通化した。試験には確定直後の通信断、遅い応答、取消し、返金を含めた。 保守通知は共有窓口で受け、繁忙日、影響機能、代替手段を担当者が評価する。通知形式の自動取込みに失敗した場合の手動確認も設けた。契約では通知期間と緊急変更の連絡方法を協議し、通知を受信しただけで準備完了とはしない。店舗には現金切替と未確定取引の確認手順を別々に訓練した。 対策後12か月の類似障害2件では、新規決済経路の復帰が最大8分になった。私は復帰時間と保留取引の解消時間を分けて測り、経路切替が速くても二重請求があれば成功ではないと評価した。今回の160分停止を含む期間とは分けて可用性を集計する。機会損失の回避額だけで投資十分とは断定せず、初期費、継続費、発生頻度の想定を並べて検討した。 改善点は複数代行の照合・契約管理の負担だった。年次で費用と効果を見直し、カード種別の対応範囲も確認する。また店舗、広報、コールセンタの合同訓練で初報と案内の一致を測る。現金を持たない顧客や支払済みの可能性がある顧客にも適切に案内できることを確認し、決済を再開する技術だけでなく、取引を正しく終える運用を改善する。 残る課題として、返金の成立後に応答だけが失われる場合もある。返金を再操作する前に元決済と返金番号を照会する手順を訓練へ加え、売上と返金を別々に追跡する。顧客への精算説明も記録に残す。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
通信業の参考答案例
約 1,980 字序論（設問ア）
私が責任を担っていたのは、通信事業者E社の法人向け5Gマネージドサービスである。約180件のスライス契約を運用し、私はネットワーク運用本部のITサービスマネージャとして、契約ごとの品質と継続性を管理した。 木曜3時15分、製造業向け4スライスで遅延が通常の約5msから200ms以上へ増え、合意した10ms以下を満たせなくなった。品質検査に支障が出て、一社では生産ラインの一部が停止した。前夜の設定変更との関連が疑われたが、初動では原因を断定しなかった。 発生2時間30分後に迂回経路で主要な通信を改善し、3時間後に通常構成への復帰作業を終えた。その後の顧客側確認を含む全面復旧は3時間50分後だった。私は設定を戻した時刻と、顧客の業務が契約品質で利用できると確認した時刻を分けて管理した。
本論（設問イ）
私はスライス別監視の通知と顧客報告を照合し、重大インシデントとして対応を開始した。障害情報を顧客、サービス、利用資源の対応表へ重ね、影響4社と同じ資源を共有する契約を調べた。原因が不明でも対象顧客へ初報を行い、専任窓口を置いて事実と次回更新時刻を伝えた。契約品質や法的な報告要否は、それぞれ契約・法務担当と確認した。 技術班を設定復元、代替経路、原因調査に分けた。私は各班の操作が競合しないよう変更責任者を一本化し、実行前に対象資源と切戻し条件を記録させた。迂回経路の空き容量と他顧客への影響を確認し、単に経路が通るだけで切替しなかった。復旧操作の前に設定差分、カウンタ、ログを保存し、原因調査の証拠を確保した。 代替経路への切替で2時間30分後に主要通信の遅延が改善した。設定復元も進め、3時間後には通常構成への復帰作業を終えたが、顧客の測定点で確認中と案内した。各社の代表通信で遅延、損失、到達性を確認し、3時間50分後に全面復旧を宣言した。顧客の生産再開時刻はITの復旧時刻と別に記録し、通信を戻しただけで業務影響が消えたとはしなかった。 原因調査では前夜の変更前後の設定を比較した。ルーティング最適化のルールが特定スライスのトラフィック分類にも適用され、本来の低遅延経路ではなく混雑する共有経路へ送っていた。対象スライスのキュー長、転送先、遅延の変化を時刻で突合し、変更が適用されていないスライスとの違いを確認した。検証環境で同じ分類条件と負荷を与えて遅延を再現し、旧設定へ戻すと解消することを確かめた。 私は変更申請と試験記録も確認した。装置単位の疎通試験はあったが、共通ルールが契約別の品質へ及ぼす影響を評価していなかった。承認時にも装置が稼働するかに偏り、顧客のサービス経路と負荷条件を確認する担当が明確でなかった。技術的な設定誤りと、影響評価・受入試験の不足を区別して根本原因とした。復旧後は監視値と顧客確認を記録へ添え、調査結果を関係部門と共有した。 復旧の課題は、迂回によって別の契約へ混雑を移すリスクだった。私は対象4スライスだけでなく、迂回先を共有する契約の遅延と損失も監視対象にした。悪化時には追加切替を止める基準を設け、顧客ごとの優先度を独断で変更しなかった。
結論（設問ウ）
私は設定変更の申請項目に、影響する顧客・スライス・経路・品質条件を加えた。共通ルールの変更は装置単位の試験だけで承認せず、対象と非対象の両スライスで負荷をかける。別チームのレビュー担当が分類条件と優先度を確認し、検証結果、適用手順、切戻し条件をそろえてから変更する。 監視には契約ごとの測定点と閾値を設定し、全契約の平均値だけで良否を判断しない。シミュレーション環境は本番との差を一覧にし、実機でしか分からない点は限定適用と監視で補う。環境を作れば全て再現できるとはせず、構成変更後も試験データと設定を更新する責任者を定めた。 対策後12か月に同じ原因の事象はなく、変更時の事前検証で経路への想定外影響を発見できた。私は今回の230分の品質違反を含む期間と対策後を分けて集計した。平均可用性が良くても、最高水準99.999％を約束する個別契約の達成を証明するものではないため、契約ごとの対象時間と違反時間を報告する。賠償回避額も前提付きの推計とした。 改善点は検証環境の維持負担と、顧客側の復旧確認だった。試験の実施率だけでなく、発見した不備と維持費を比較する。また顧客と連絡窓口、測定手順、生産再開の判断責任を合意し、合同演習を行う。今後は技術班の作業完了から顧客確認までに要した時間も評価する。変更管理、監視、対外連絡を一つの手順につなげ、同じ設定誤りを防ぐだけでなく影響の拡大も抑える。判定根拠も残す。 残る課題は測定点の違いによる認識のずれである。端末から接続先までのどの区間を測るか、時刻同期と集計間隔を顧客と再確認する。短時間の品質違反が長い平均に埋もれないよう、契約の評価単位で記録を残す。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
公共・自治体の参考答案例
約 2,005 字序論（設問ア）
私が責任を担っていたのは、人口約45万人のF市の住民ポータルと業務連携サービスである。登録者約18万人、年間申請約24万件を扱い、私はITサービスマネージャとして運用を統括した。 市独自給付の申請期限前の月初朝、アクセスが集中し、通常約0.5秒の応答が最大30秒を超えた。外部確認サービスの流量制限と、待ち処理がDB接続を保持する実装が重なり、接続プールが枯渇した。午前中の失敗は約3,800件、問合せは平常の12倍となった。実在制度の対象条件と混同しないため、本事例の対象は市独自給付とする。 発生3時間30分後に応答が改善し、4時間後に機能の再開作業を終えた。未確定申請の照合を含めた全面復旧は4時間10分後だった。私は住民の申請機会を守る代替受付と、未処理・二重受付を防ぐ復旧を優先した。
本論（設問イ）
私は監視アラートと窓口報告を照合し、重大インシデントを宣言した。申請の影響範囲と受付済み・未確定の件数を確認し、担当課、広報、窓口、技術班を集めた。期限と代替受付の扱いは所管課の権限で決定してもらい、PMや技術担当の独断で制度の期限を変えなかった。承認された窓口・郵送の案内を住民へ提供した。 広報は公式Web、SNS、地域FMを用い、問い合わせ窓口へ同じ説明文を渡した。私は判明した事実と未確定事項を分け、復旧時刻を約束できない間は次回更新時刻を示した。複数経路は既に初動で使っていたため、後から広報の単一路線依存が技術障害の原因だったとは整理しなかった。 技術班は内部処理と外部連携の二班に分けた。内部班は接続プールの使用数、DBのCPU・メモリ、クエリ待ちを採取し、外部応答を待つ間も接続が占有される処理を特定した。接続数を増やすだけではDBを過負荷にするため、受付の同時実行数と再試行を制限し、処理済みの接続を確実に返す応急修正を検証した。保留申請を永続化し、利用者が何度送っても同じ受付番号で追跡できるようにした。 外部班は流量制限の応答と契約上の上限を確認した。委託先の制限設定変更と通知経路を調べ、暫定的に許される要求量を協議する。無制限な解除を求めるのではなく、相手側の容量も踏まえて段階的に送る。3時間30分後に応答が改善し、4時間後に機能を再開したが、未確定申請が残ることを明示した。重複と欠落を照合して4時間10分後に通常運用へ戻した。 調査では、期限前の要求集中、外部の流量制限、内部の接続保持を時系列で突合した。検証環境で外部応答を遅らせると、通常時の負荷でも接続が枯渇することを再現した。負荷予測不足だけでなく、外部待ちをDB取引の外へ分離していない設計と、失敗時の再試行制御の不足が原因だった。 私は変更通知の受領記録と負荷試験計画も点検した。通知が運用条件の見直しへつながらず、正常応答だけの試験で承認していた。外部の制限値変更と内部の滞留が組み合わさる条件を、恒久策の試験へ追加した。 代替受付の課題は、窓口とオンラインの両方へ出した申請を重複処理するリスクだった。私は所管課と本人・申請を対応付ける確認項目を決め、紙受付番号を復旧後の記録へ引き継いだ。重複の疑いだけで一方を削除せず、担当課が内容を確認した。
結論（設問ウ）
私は外部照会を待つ間にDB接続を保持しない処理へ変更し、接続プールと受付数をDBの実測容量に合わせた。要求は受付番号付きで保存し、外部連携を非同期に処理する。申請済み、確認中、完了を分けて表示し、未完了を成功と誤認させない。再試行は間隔と上限を設け、復旧後に一斉送信しない。 試験には期限前の集中、外部応答遅延、流量制限、途中再起動を含めた。接続数を200から750へ増やせば解決するという数値先行の対策は採らず、CPU、メモリ、待ち時間、処理完了率を見て設定を決めた。外部委託先との通知窓口と担当者を明確にし、変更時には制限値と再試行条件を再評価する。 対策後12か月に同種の停止はなく、次の繁忙期も申請を処理できた。私は障害がないことに加え、負荷試験で接続が回収されること、保留申請が欠落なく完了することを評価した。今回の250分の影響を含む期間と対策後は分け、対象時間が異なる可用性をそのまま比較しなかった。 改善点は代替受付の処理能力だった。広報経路は複数あっても、窓口へ案内された住民が集中すると対応が追い付かない。今後は紙受付の担当、処理容量、後日の入力・照合を訓練し、給付担当課と期限前の準備を行う。問合せの多かった説明は事前FAQへ反映する。障害がなかった期間の問合せ減を全て広報の成果とはせず、初報時間と案内の一致を測る。技術的な回復と、住民が申請を完了できることの双方を継続して確認する。 残る課題は、受付できたことと審査完了を混同する住民への案内である。紙受付にも確認可能な番号を渡し、審査中の状態と次の連絡方法を示す。技術班の処理完了件数だけで給付業務の完了を報告しない。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
医療・ヘルスケアの参考答案例
約 2,049 字序論（設問ア）
私が責任を担っていたのは、550床、職員約2,000名のO病院の電子カルテ、処方、会計、看護支援等を結ぶ医療情報基盤である。私はITサービスマネージャとして運用を統括した。 午前2時15分、処方データの反映失敗を検知し、2時45分には複数病棟で過去オーダも参照できなくなった。連携サーバのRAID5でディスク2台が故障し、バックアップ後の約25時間、約1,800件の処方情報を読み取れない状態だった。3時に医療安全管理者と代替運用へ切り替え、4時30分に緊急委員会を開いた。 私の優先課題は、過去の処方だけを根拠に投薬せず、医師の最新指示を確認して診療を継続することと、処方の変更・取消しを含めた正しいデータ復旧だった。障害発生から18時間後に照合を含む復旧を完了したが、その間には投薬の遅れが生じ、患者影響の評価も医療者と進めた。
本論（設問イ）
私は障害通知を受けた時点で当直の医療安全責任者へ連絡し、2時45分に複数病棟への影響を確認して重大インシデントを宣言した。ITの復旧班と医療側の業務継続班を分け、指示と記録を一つの時系列にした。3時に紙の代替手順へ移したが、過去オーダをそのまま再実施するのではなく、医師が患者と最新の投薬指示を確認し、薬剤師と看護師が照合する手順とした。 紙の指示には患者識別、日時、指示者、変更・取消しの別を記録した。薬剤部への伝達後に受領を確認し、実施結果も残す。既に実施した投薬を復旧後に二重実施しないよう、未実施と実施済みを分けた。私は院内連絡で利用不能な機能と代替手順を伝え、医療者が安全上継続できないと判断する診療は制限してもらった。 復旧班は故障ディスク、ストレージ管理ログ、監視通知、バックアップ結果を保全した。RAID5は一台の故障には耐えるが二台ではデータを再構成できない。一本目の故障通知と交換依頼が適切に処理されたか、二本目の発生までの状態を調べた。機器故障だけでなく、冗長性が失われた状態を速やかに解消する運用と、復元可能なデータ範囲の管理を原因分析の対象にした。 復元は隔離環境でバックアップを戻し、復元時点以降の差分を周辺システムの記録と紙指示から再構成した。約1,800件の再入力作業は4時間を要したが、その前後に環境復元と照合があり、全体の復旧は18時間後だった。最新変更、取消し、実施済みの区別を医師・薬剤師・看護師が役割を分けて確認し、件数が合っただけで完全復元とは判断しなかった。 私は復旧した処方を診療部門と確認してから通常運用へ戻した。患者への健康影響は医療安全部門が継続して評価し、投薬遅延があったのに影響ゼロと断定しなかった。個人情報の報告要否も外部漏えいの有無だけで決めず、医療情報の滅失・毀損と復元状況を法務・個人情報担当へ提示した。必要な報告と本人対応を確認する間も、判断根拠と判明時刻を保存した。 4時30分の委員会では代替運用の安全性、復旧優先順位、外部連絡を確認し、技術者だけで業務上の完了を決定しない体制にした。 再入力の課題は、同じ患者の変更前後の処方を取り違えるリスクだった。私は患者識別子だけでなく指示時刻と変更番号を対応付ける照合表を用意し、医療者が有効な指示を確定できない記録は保留した。IT担当が薬剤や用量を推定して補うことは認めなかった。
結論（設問ウ）
私はRAID6への変更と別サーバ室への複製を設計したが、RAID6や複製はバックアップの代わりではない。誤削除や破損が複製される可能性も考え、独立したバックアップと復元試験を設けた。故障通知の受領、交換期限、未対応時の上位連絡を明確にし、冗長性が失われたまま放置しない。 バックアップ間隔は4時間へ短縮したが、それでも最大4時間分の差分が残り得る。医療部門と許容できるデータ損失と復旧時間を確認し、メッセージ履歴の保存と再処理を組み合わせた。四半期の試験ではサーバを起動するだけでなく、処方の変更・取消し、実施済み記録まで復元して照合する。 6か月間に同種の停止はなかった一方、短い観測期間だけで再発リスクが消えたとはしなかった。今回の18時間という復旧時間、再構成の工数、投薬遅延を評価資料にした。投資4,500万円の承認では、単位が合わない外来損失の掛算や、未確認の行政処分を根拠にせず、復旧能力、業務制限、構成維持費を比較した。 改善点は代替手順の複雑さだった。各職種の確認事項を分けた運用カードを作り、当直体制で試した。医師の最新指示確認を省略せず、電子復旧後の二重実施防止まで含める。医療安全部門への連絡も時間が経つまで待つ条件にはせず、診療情報への影響を認めた時点で行う。今後は障害後の報告判断に必要な情報も訓練で収集し、復旧、医療安全、個人情報対応を並行して進める能力を確認する。 残る課題は、休日の少人数体制でも照合担当を確保することだった。応援招集までの暫定分担を医療部門と定め、未照合記録を次の当直へ引き継ぐ訓練を行う。入力件数を急ぐために独立した照合を省くことはしない。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
IT・情報サービス業の参考答案例
約 2,107 字序論（設問ア）
私が責任を担っていたのは、約8,200店舗が利用するP社のSaaS型EC基盤である。私はSREチームのサービスマネージャとして可用性と性能を統括した。 大型セール開始日の正午、注文確定APIの応答が通常80msから1,500msへ悪化し、エラー率が0.8％から18％になった。調査するとPostgreSQLの在庫DBで、集計処理の前処理が明示的な表ロックを保持し、注文更新を待たせていた。通常の集計SELECTがMVCC下で注文更新と排他的に競合したという事例ではない。 前日の変更でバッチが夜間固定から随時実行になり、セールと重なった。私は発生19分後に当該処理を停止し、ロック解消と滞留回復を含め24分後に正常化を確認した。推計損失は対象顧客の申告する毎時4,300万円を単純比例するなら24分で1,720万円となるが、実損とは区別して扱った。
本論（設問イ）
私はエラー監視と複数店舗の報告から重大インシデントを宣言し、オンコールのSREとDB担当に復旧作業を指示した。CTO、開発、サービスデスクへ影響を共有し、記録と顧客案内の担当を分ける。注文APIの失敗が新規取引か応答不明かを確認し、重複注文が発生しないよう再操作の案内を統一した。 DB担当には現在の待機とブロッカを確認させた。pg_stat_activityとpg_locksを突合すると、集計バッチの前処理が明示的に取得したACCESS EXCLUSIVEロックを長いトランザクション中に保持していた。通常のSELECTの読取りロックが注文更新と競合したのではなく、この強い表ロックが更新を妨げていた。私は終了させる処理の所有者とロールバック影響を確認し、集計の遅延より注文停止の影響が大きいと判断して19分後に停止を承認した。 停止後すぐに全体復旧とせず、トランザクションの取消し、ロックの解放、待機要求の減少を監視した。過剰な再試行を抑え、注文確定件数と在庫更新を照合する。5分後、発生から24分で応答約90msと通常のエラー水準を確認し、復旧を通知した。サービスデスクには未確定注文を確認する手順も渡し、課金や在庫だけが二重に更新されていないか調べた。 私は30分以内に初報と復旧状況を公開し、大口顧客には窓口を分けて連絡した。発生時刻、影響、回復時刻、残る確認事項を示し、根拠のない補償額を即断しなかった。SLA違反や返金は当月の他停止、契約上の対象時間と除外、補償条件を確認して判断する。24分の障害だけから月次99.9％違反と30％返金を決めることはしなかった。 原因調査では前日の変更申請、実行時刻、SQL、ロック保持の時系列を保存した。検証環境で前処理と注文更新を重ね、同じ待機が起こることを再現した。随時実行への変更はコード変更ではないため影響評価から漏れ、集計に業務テーブルの強いロックを必要とする設計も見直されていなかった。 私は運用時刻の変更とSQL設計の問題を別々に記録し、バッチ停止という暫定策だけで終わらせなかった。集計の要件を確認し、業務テーブルをロックせずにスナップショットから計算する案を恒久対策へ進めた。 停止操作の課題は、ロック解放を急ぐほど長いロールバックで負荷が増すリスクだった。私は取消しの進捗とI/Oを監視させ、別のバッチを重ねて停止しなかった。待機要求を段階的に受け入れ、タイムアウトした注文が再試行されても一度だけ確定することを照合した。
結論（設問ウ）
私は集計の前処理から業務テーブルへの強いロックを除き、参照用データへ処理を分離した。読取専用レプリカでは書込みや強いロックを伴う処理をそのまま実行できないため、前処理の方式自体を変更する。集計値は遅延を許容する業務であることを合意し、基準時刻を表示した。長時間クエリとトランザクションには上限を置いた。 変更管理はコードだけでなく、ジョブ時刻、実行頻度、権限、設定を対象にした。セール期間の変更制限と緊急承認手順を定め、業務の依存関係をレビューする。試験では同時注文、集計、取消し、再試行を重ね、単体性能だけで承認しない。障害訓練は承認した検証環境から始め、中止条件と復旧責任を定めた。 対策前後の各観測期間で同種インシデントの月平均は3.2件から0.4件へ下がり、削減率は87.5％である。私は0件になったとは評価せず、残る待機の原因を調査した。今回の19分は停止判断まで、24分が正常化までであり、損失推計を行う場合も対象時間を合わせる。顧客の契約継続や新規獲得は別要因を含むため、補償提案だけの成果としなかった。 改善点は夜間の招集体制だった。初動を行うオンコールと、追加専門家の招集を分け、代行者と連絡期限を明記した。今後は検知、ブロッカ特定、停止判断、取引照合までの時間を演習で測る。復旧判断の速さだけでなく、停止の安全性と注文・在庫の整合を評価し、運用変更も事業影響に基づいて審査する。 残る課題は、参照用データの更新遅延が在庫判断へ混入することである。集計画面にはデータ基準時刻を表示し、注文時の引当は引き続き正規の在庫更新処理で行う。集計の高速化と在庫の正確性を別の確認項目にした。
試験制度・公式過去問の確認: IPA 情報処理技術者試験