LASSIC Media らしくメディア

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

外部エンジニアに加わってもらった開発で不具合が出て、ひとまず直った。けれども、同じ不具合がまた起きないと言えるだけの手当てができているのかは分からない——。外部エンジニアが関わる不具合の再発防止とは、直したあとに、同じ原因で同じ不具合を起こさないための対策を決め、社内と委託先の手順や取り決めに組み込み、終えたかどうかを確かめるところまでを指します。

本記事では、開発の現場を預かるマネージャーに向けて、総務省の電気通信事故検証会議がまとめた検証報告に載る事例をもとに、当面の対処と恒久の対処の分け方、同じ原因を他の箇所で探す点検、開発の手順と記録の直し方、委託先との取り決め、使っている製品の不具合情報の追い方を整理します。

再発防止で決めること

手がかりにするのは、総務省の電気通信事故検証会議が2026年7月17日に公表した「令和7年度電気通信事故に関する検証報告」です。^*2 電気通信事業者から報告された事故を有識者が検証したもので、報告書は、検証が電気通信事故の再発防止に寄与することを目的としており、事故の責任を問うために行うものではないと付け加えています。^*1 対象は通信の事故ですが、当事者でない事業者の取組にも反映されるよう、できる限り一般化して書いたとしています。

報告書に並ぶ再発防止策を読むと、決めていることは大きく4つに分けられます。いま起きている不具合を止める当面の対処、原因そのものを取り除く恒久の対処、同じ原因が他の箇所に潜んでいないかの点検、そして対策ごとの完了日です。外部エンジニアが関わった不具合でも、この4つを社内で持っておけば、報告書が注意の呼びかけだけで終わるのを防ぎやすくなります。

4つのうち、外部エンジニアに頼めるのは主に原因の調べと対策の作業です。どの対策を採るか、いつまでに終えるか、終えたことを誰がどう確かめるかは、発注する側が決めておきます。

同じ教訓が繰り返し載る

令和7年度に報告された重大な事故は6件で、前年度と同じ数でした。発生の要因で分けると、人為要因が3件、設備要因が2件、外的要因が1件です。^*1 報告書は、過去の教訓と似た事故がこの年度も起きていることから、過去の教訓の内容も取り込みながら教訓をまとめたとしています。教訓ごとに、新しく示したものか、過去の報告書で似た教訓を示したもの（再掲）かが付記されています。

その付記を数えると、令和7年度の教訓22件のうち、本年度新規が10件、過去の教訓の再掲が12件でした。^*1 委託先や製品の提供元など組織の外の関係者と情報を共有する体制についての教訓は、2015年度から2024年度までの6つの年度の報告書に挙げた教訓の再掲とされています。一度教訓として書かれたことでも、別の会社、別の現場で同じ形の事故が起きているということです。

社内の不具合でも同じことが言えます。再発防止策を報告書に書いても、それが手順書や契約の文言、点検の予定に落ちていなければ、担当者が替わったときに消えてしまいます。外部エンジニアは契約の終了とともに現場を離れるので、なおさら対策を人の記憶ではなく、手順や記録の側に残しておく必要があります。

当面の対処と恒久の対処を分ける

再発防止策を決めるときは、まず当面の対処と恒久の対処を分けて書きます。前者はいま起きている不具合を止めるための手当てで、後者は同じ原因で再び起きないようにするための手当てです。

報告書に載っている、ビジネスチャットのサービスが断続的にオフラインになった2025年4月の事故がわかりやすい例です。クラウド事業者が提供するデータベースの書き込み用のサーバが故障し、全ての処理が止まりました。データベースの一部の機能のバグとの関連が推定されたものの、クラウド事業者からは未知のバグで詳細な条件は開示できないという回答を受けており、事故との因果関係は不明とされています。^*1

この事業者は暫定の対処として、手動の切り替え（フェイルオーバー）で一時的に復旧させ、原因と推定された機能を無効にしました。恒久の対処には、クラウド事業者と直接連絡が取れる体制の整備、サービス品質の保証（SLA）を含む契約上の責任範囲と補償の確認、障害時の影響範囲を小さくするためのデータベースの分割の検討などを挙げています。^*1 分割は報告書の時点でも対応中です。

原因が特定できなくても、当面の対処だけで終わらせず、恒久の対処として何をするかは決められる、という例です。外部エンジニアに調べてもらって原因が絞り切れなかった場合も、影響を小さくする構成の変更や連絡体制の見直しは、恒久の対処の候補として検討できます。

同じ原因を他の箇所でも探す

恒久の対処と並んで報告書で目立つのが、同じ原因が他の箇所に潜んでいないかの点検です。水平展開とも呼ばれます。

2025年10月に携帯電話会社のメールが使いにくくなった事故では、ゲートウェイサーバのIPv6用の領域の設定が、本来設定すべき値より小さい初期値のままになっていました。2020年にIPv6の設定を追加したとき、この領域がIPv4と共通の管理だと思い込み、初期値のまま残してしまったためです。^*1

この事業者は、問題の出たサーバの設定値を広げただけでは終わらせていません。他のシステムを含む全てのサーバの設定状況を点検し、さらに、不備のあった開発のマニュアルが適用された過去の開発案件についても、同じリスクが残っていないかを点検しています。^*1 別の事故では、同じ事象が起こりうる他の装置を確かめる点検を、再発防止策の一つとして完了日つきで挙げた事業者もありました。

外部エンジニアが関わった不具合なら、同じ人やチームが担当した他の機能、同じ時期に同じ手順で作った箇所、同じ設定の雛形を使った環境が点検の候補になります。点検の範囲は社内で決め、作業には原因の調べを担当した外部エンジニアに加わってもらうと進めやすくなります。

開発の手順と記録を直す

同じメールの事故で、報告書は原因を2段に分けています。直接的な原因は、要件を決める段階で設計書の案のレビューにインフラの担当チームが呼ばれず、インフラの装置への影響の検討がされなかったことで、開発のマニュアルの記載が不明瞭だったとされています。その奥の原因として、レビューへの参加の記録や影響検討の結果など、開発の工程を実施した結果を残していなかったことが挙げられています。^*1 対策も、この2段のそれぞれに付けられています。

表のとおり、対策の多くは個々の設定の修正ではなく、レビューに誰を呼ぶか、何を記録に残すか、試験で何を確かめるかといった手順の変更です。報告書の教訓も、レビューへの参加の要否をマニュアルで明確にし、マニュアルに沿って実施されているかを品質管理の部門が確かめられるよう、証跡確認の手順を整えることが望ましいとしています。^*1

外部エンジニアに開発を頼んでいるなら、設計のレビューに社内の誰が加わるか、外部エンジニアが残すレビューや試験の記録の形を発注のときに決めておきます。そうしておけば、次に不具合が出たときも、工程をさかのぼって確かめられます。

委託先との取り決めに入れる

社外の作業者の誤りが原因になった事故もあります。2026年1月の携帯電話の通信障害では、データセンターの無停電電源装置（UPS）の点検で、装置メーカーの作業担当者が手順書にない作業をした結果、フロアの電源が失われました。^*1

この事業者の恒久の措置は、データセンター事業者の側で再発防止策が講じられることを確保する、という形を取っています。作業当日の事前の打ち合わせで役割分担を明確にし、接続箇所の2way確認を義務にすること、稼働中の設備に影響する全ての作業を製造業者・作業立会者・作業責任者の間で事前に承認することなどです。^*1

報告書は教訓として、委託先にも同じ取組を守ってもらうため、「SLA（Service Level Agreement）等において委託先からの役務提供に係る保証、障害発生時の迅速な通知、現用設備に影響を与えるおそれのある作業の事前通知等について規定することが望ましい」としています。^*1 この教訓は2016年度と2017年度の報告書に挙げた教訓の再掲です。

外部エンジニアに頼む開発に置き換えると、本番の環境に触れる作業の事前の連絡と承認、不具合に気づいたときの連絡の期限、手順書に沿わない作業をしないことを、契約や発注の書面に入れておく形になります。ただし、不具合の責任をどちらが負うか、直す費用をどう扱うかは、契約の定めによって変わります。個別の判断は、契約書をもとに法務の担当者や弁護士に確かめてください。

製品の不具合情報を追う

外部エンジニアが作ったものだけでなく、使っている製品の不具合が原因になることもあります。2026年2月のメールサービスの事故では、仮想化基盤のスイッチのバグで2台の両系とも通信できなくなりました。このバグは公開されていたものでしたが、事前に把握できていませんでした。^*1 事業者はファームウェアを更新したうえで、情報が公開されたときに速やかに把握できる体制を整えています。

報告書は教訓として、ハードウェアやソフトウェアの障害情報について製品の提供元と定期的に情報を交換する場を設けることや、保守の契約を先回りして情報を得られる形に見直すことを挙げています。外部に委託する場合については、「定期的な業務報告、監査等の委託業務の適正性を確保するための仕組みを構築することが望ましい」としています。^*1

外部エンジニアに保守まで頼んでいるなら、使っているライブラリや製品の不具合情報をどの頻度で確かめ、定期の報告に入れてもらうかを決めておきます。公開済みの不具合を見落とす余地を減らせます。

外部に頼むときに確認しておきたい点

不具合のあとで外部エンジニアに再発防止の作業を頼むなら、頼む前に社内で決めておきたいのは、当面の対処と恒久の対処のどこまでを頼むか、他の箇所の点検の範囲、対策ごとの完了日と完了を確かめる人の3つです。障害が起きたときにすぐ対応してもらうことや現地に来てもらうことまで期待するなら、それが契約で提供される範囲に入っているかを先に確かめます。

原因の調べを頼むときに渡す情報は外部エンジニアに不具合の原因調査を頼む手順で扱っています。

原因をたどる分析の進め方は外部人材活用の失敗の原因分析にまとめました。

障害が起きたときの手順書の整え方は運用保守の障害対応手順整備で整理しています。

まとめ：再発防止で確かめておきたい3つの点

外部エンジニアが関わった不具合の再発防止を進めるうえで、確かめておきたい点は3つに整理できます。第一に、当面の対処と恒久の対処を分け、対策ごとに完了日を決めて記録すること。第二に、直した箇所だけでなく、同じ設定や同じ手順で作った他の箇所も点検し、レビューや記録の手順まで直すこと。第三に、本番に触れる作業の事前の承認や不具合の連絡を委託先との取り決めに入れ、責任の扱いは契約と専門家に確かめることです。この3点を踏まえておけば、「再発防止策は書いたのに、同じ原因の不具合がまた起きた」という事態を避けやすくなります。点検や手順の見直しを担う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：総務省 電気通信事故検証会議「令和7年度電気通信事故に関する検証報告」（PDF）（https://www.soumu.go.jp/main_content/001082649.pdf）。出典：電気通信事故検証会議（令和8年7月）。はじめに、1.(2)イ(ア)(ウ)(オ)(カ)の各事故の発生原因と再発防止策、1.(5)ウ 発生要因別、2. 令和7年度に発生した事故から得られた教訓等（冒頭、ア(ア)、カ、ス、各教訓の本年度新規・再掲の付記）を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：総務省 報道資料「『令和7年度電気通信事故に関する検証報告』の公表」（https://www.soumu.go.jp/menu_news/s-news/01kiban05_02000403.html）。出典：総務省 総合通信基盤局、令和8年7月17日。公表日と検証会議の目的を参照（確認日2026年10月2日）（2026年10月確認）

Tweet