LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

本番のシステムで不具合が出たのに、社内には原因を追える人がいない。再起動したら直ったけれど、また起きないか不安だ——。開発した会社との契約が終わった業務システムや、担当者が異動したシステムでは、こうした状況が起こりがちです。金融庁のまとめでも、金融機関が2025年度に報告したシステム障害は約1,600件あり、事象別ではソフトウェア障害が39.2%で最も多くなっています。^*1 不具合の原因調査とは、起きた現象を再現し、どの処理がどんな条件で誤った動きをしたのかを突き止めて、直し方の方針を示すまでの作業を指します。

社内に調べられる人がいないとき、外部エンジニアに原因調査を頼むのは現実的なやり方です。ただし万能ではなく、止まった業務をすぐに動かす復旧は、原因調査とは別の仕事です。復旧は保守の契約先や社内の運用担当が受け持つものとして、依頼を分けて考えます。本記事では、外部エンジニアに不具合の原因調査を頼むシステム担当者に向けて、原因調査と復旧の違い、依頼の前にそろえる情報、契約の形、調査結果の受け取り方、そして外部に頼むときに確認したい点を整理します。

不具合の原因調査とは

原因調査の作業は、おおまかに次の4つの段階に分かれます。どの段階まで頼むのかを先に決めておくと、見積りと完了の判断がしやすくなります。

• 現象の確認：利用者からの報告、画面に出たエラー、ログ（システムが動作を時刻とともに書き残した記録）から、何がいつ起きたかを確かめる
• 再現：本番とは別の検証用の環境で、同じ条件のときに同じ現象が起きるかを試す
• 原因の特定：プログラムのどの部分が、どんなデータや操作のときに誤った動きをするかを、ソースコード（プログラムの元の記述）と突き合わせて絞り込む
• 方針の提示：直し方の案と、影響を受ける機能やデータ、同じ誤りを持つ箇所がほかにないかを報告する

修正そのもの、つまりプログラムの書き換えとテスト、本番への反映は、原因調査に続けて同じ人に頼むこともできます。ただ、依頼としては分けておくと、原因が分かった時点で修正の中身と費用を社内で判断できます。

経済産業省の「システム管理基準」（2023年改訂）は、インシデント（業務やサービスが通常どおり動かない出来事）への対応と、その根本原因を突き止めて同じ出来事を防ぐ問題管理を、一つの項目で扱っています。目的は「利用部門と合意した目標内でインシデントを解決し、根本原因を特定して恒久的な対策を講じる」ことで、管理活動の例には「インシデントの根本原因を究明する」ことが挙がっています。^*2

なぜ復旧だけで終わらせないのか

金融庁の「金融分野におけるITレジリエンスに関する分析レポート」（2026年7月）は、金融機関から受け取った障害発生等報告書をもとに、2025年度（2025年4月〜2026年3月）のシステム障害を分析しています。金融庁は、顧客対応や復旧の状況を確かめるとともに、障害の本当の原因と、その後の改善策の報告も受けていると説明しています。^*1 復旧したかどうかだけでなく、なぜ起きたのかまでが報告の対象です。

事象別に見ると、ソフトウェア障害が39.2%、管理面・人的要因が29.3%で、2つを合わせると68.5%になります。^*1 ソフトウェア障害の例として挙がっているのは、外国送金で使う電文（金融機関どうしがやり取りするデータ）の形式が新しくなり、それに合わせてシステムを改修した事案です。仕様が複雑で関係者の理解がずれ、不要な処理が組み込まれたうえ、影響がないことを確かめるテストも十分でなかったため、リリース後に一部の送金処理が滞りました。^*1

同じレポートの事例集には、原因を確かめないまま復旧したと判断した例も載っています。決済アプリを使った取引ができなくなり、データベースサーバー（データを保管し、検索や更新に応じるサーバー）の再起動で解消したものの、翌日に同じ障害が起きた事案です。直前にリリースした案件によって、データベースへの特定の問い合わせが急に増え、サーバーの処理能力を使い切っていました。事例集は、再起動で正常に動いたため復旧したと判断したが「障害原因の特定及び対処ができていなかった」と記しています。^*1

依頼の前にそろえる情報

外部エンジニアは、そのシステムがどう作られ、どう変えられてきたかを知らない状態から調査を始めます。外部エンジニアが最初の数日を情報集めだけに使わずに済むよう、依頼する側で次の情報をそろえておくと進めやすくなります。

システム管理基準は、運用の監視と記録の項目で、ログの管理として「情報システムで発生した問題を識別するためのログを取得、保管及び分析し、適時に必要な対応を行う」ことを挙げています。^*2 ログは決まった期間を過ぎると消えるように設定されていることがあるため、不具合に気づいた時点で、発生時刻の前後の分を別の場所に保存しておきます。

直前の変更を並べておくのは、先に見た2つの事例が、どちらもリリースの後に起きているからです。^*1 変更の記録が部署ごとに散らばっているなら、誰がいつ何を変えたかを一覧にするだけでも、原因調査の最初の手がかりになります。

本番のデータを渡すかどうかも、依頼の前に決めておきます。個人データを含むときは、個人情報保護法にもとづき、委託先での扱いを確かめて監督する手続きが必要になります。進め方は「業務委託エンジニアの情報セキュリティ、個人データを任せる前の確認」で扱っています。再現に必要な項目だけを残し、氏名や連絡先を別の値に置き換えたデータを用意できれば、渡すデータを減らせます。

契約の形をどう決めるのか

原因調査は、始める時点では、原因が見つかるかどうかも、見つかるまでの日数も分かりません。この性質が契約の形の選び方にかかわります。民法の請負は、当事者の一方が「ある仕事を完成することを約し」、相手方がその結果に報酬を払う契約です。^*3 これに対して準委任は、法律上の行為ではない作業を任せる契約で、委任の決まりが当てはめられます。受ける側は「善良な管理者の注意をもって」、つまり専門家として当然払うべき注意を払って作業する義務を負いますが、仕事の完成までは約束しません。^*3

結果を約束しにくい原因調査は、準委任で、作業時間の上限と報告に書く項目を決めて頼むと、双方が約束することがはっきりします。準委任でも成果に報酬を払う形にできますが^*3、「原因を特定した報告書の提出」を成果にするなら、原因が見つからなかったときの報酬の扱いまで決めておきます。決めていないと、あとで食い違いが起きます。

報告の義務は民法にも書かれています。受任者は、委任者の請求があれば「いつでも委任事務の処理の状況を報告し」、終わった後は「遅滞なくその経過及び結果を報告しなければならない」とされています。^*3 契約書では、中間報告の頻度と、最後の報告書に書く項目を具体的に決めておきます。

もう一つ確かめたいのは、元の開発会社との契約です。請負で作ってもらったシステムの不具合が、契約で約束した品質に合わないもの（契約不適合）に当たるなら、元の開発会社に直すよう求められる場合があります。ただし民法は、注文者が不適合を知った時から1年以内に通知しないと、直すよう求めることなどができなくなると定めています。^*3 契約書で別の期間を定めている場合もあるため、外部エンジニアに頼む前に元の契約書の条項を確かめ、当てはめに迷うときは弁護士などの専門家に相談してください。

調査結果の受け取り方

調査の最後に受け取る報告書は、社内で修正を判断するための材料です。次の項目がそろっていれば、調査に立ち会っていない人が読んでも同じ判断ができます。

最後の「確かめられなかった点」は、省かれやすい項目です。先の事例集の例のように、原因が特定できていないのに解決したと扱うと、同じ障害がまた起きます。^*1 未確認の点が報告書にはっきり書かれていれば、追加の調査をするか、監視を強めて様子を見るかを社内で選べます。

報告を受けたら、原因の説明と根拠がつながっているかを確かめます。「このログのこの時刻に、この処理が、このデータで失敗している」と一続きに説明されていれば、社内の担当者にも判断がつきます。説明が分からないまま受け取らないよう、報告の後に質問する時間も契約に入れておくとよいでしょう。失敗の原因を仕事の任せ方からたどる手順は「外部人材活用の失敗の原因分析、直接原因と根本原因の違い」で扱っています。

つまずきやすい点

一つ目は、原因調査と復旧を同じ依頼に混ぜてしまうことです。業務が止まっているときに先に必要なのは、業務を動かす対応です。夜間や休日に誰が対応するか、現地に来てもらう必要があるかは、保守の契約や社内の運用体制で決めることです。原因調査を頼む相手がそこまで引き受けるかどうかは、原因調査の依頼とは別に、契約の前に確かめておきます。

二つ目は、本番環境の権限を広く渡してしまうことです。原因調査でまず要るのは、ログを読む権限と、検証用の環境です。本番のデータを書き換えられる権限は、修正を反映する段階で、作業する日時を決めてから渡します。作業が終わったら、渡した権限をいつ取り消すかも決めておきます。

三つ目は、調査の期限を決めないことです。原因がすぐに見つからないと、調査が何週間も続くことがあります。「最初の5営業日で中間報告を受け、その時点で続けるかを決める」のように、区切りの時点と、続けるかを判断する人を先に決めておくと、費用と時間の見通しを立てやすくなります。

まとめ：不具合の原因調査で確かめておきたい3つの点

外部エンジニアに不具合の原因調査を頼むうえで、確かめておきたい点は3つに整理できます。第一に、現象、発生の日時、直前の変更、ログをそろえてから依頼すること。第二に、原因が見つかるかどうかを約束しにくい作業であることを踏まえ、作業時間の上限と報告に書く項目を決めて契約すること。第三に、原因と判断した根拠と、確かめられなかった点まで書いた報告書を受け取ることです。この3点を踏まえておけば、「再起動で直ったと思っていたら、翌週また同じ障害が起きた」という事態を避けやすくなります。調査を任せる人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：金融庁「金融分野におけるITレジリエンスに関する分析レポート」（https://www.fsa.go.jp/news/r8/sonota/20260730/01.pdf）。出典：金融庁「金融分野におけるITレジリエンスに関する分析レポート」（2026年7月）。第2編 第1章 図表1（障害事象別割合（全業態））と脚注1・2（報告件数約1,600件、調査中・未記入の約100件は集計の対象外）、第2節（外国送金の電文方式に係るシステム改修の事案）、補論1 第3章第1節7（障害原因未特定による障害の再発）を参照（2026年9月確認）
2. *2　参考：経済産業省「システム管理基準」（令和5年4月26日改訂）（https://www.meti.go.jp/policy/netsecurity/sys-kansa/sys-kanri-2023.pdf）。出典：経済産業省「システム管理基準」。Ⅱ.5.5 インシデント管理・問題管理（管理活動の例6 根本原因の究明）と、Ⅱ.5.7 運用の監視と記録（管理活動の例4 ログの管理）を参照（2026年9月確認）
3. *3　参考：e-Gov法令検索「民法」（https://laws.e-gov.go.jp/law/129AC0000000089）。出典：民法（明治29年法律第89号）第632条（請負）、第637条（担保責任の期間の制限）、第643条（委任）、第644条（受任者の注意義務）、第645条（受任者による報告）、第648条の2（成果等に対する報酬）、第656条（準委任）を参照（2026年9月確認）

Tweet