委託先の事故は、本当に委託先だけの責任なのか

議題

システム開発、運用、保守、物流、カスタマーサポート、決済。

今のサービスは、自社だけで完結することの方が少なくなっています。

だから企業は、専門領域を外部の会社へ委託します。

そこで、つい生まれやすい感覚があります。

「そこは委託先の管理範囲です。」

「委託先の事故なので、こちらでは防げませんでした。」

本当に、それで終わる話でしょうか。

業務を外注することはできます。

しかし、サービスを提供する責任まで外注できるわけではありません。

2026年10月、NECは、システム開発・保守を委託している企業がサイバー攻撃を受け、窃取された正規アカウントの認証情報が悪用されたことで、顧客システムへの不正アクセス、システム停止、情報漏えいが発生したと公表しました。

委託先の端末から正規アカウントを使って顧客環境へ侵入され、関係者間で利用していたクラウドストレージ内の情報も漏えいしたとされています。

参考：
NEC「委託先への不正アクセスに起因するお客さまのシステム障害、情報漏えいに関するお詫び」
IPA「情報セキュリティ10大脅威 2026」
IPA「ビジネスパートナーや委託先等を含めたサプライチェーン全体の状況把握及び対策」

「委託した」は「管理しなくてよい」ではない

委託する理由は、専門性、コスト、スピード、リソース不足などさまざまです。

もちろん、外部の専門会社を使うこと自体は悪いことではありません。

問題は、

「任せた瞬間に、自社の管理対象から外したつもりになること」

です。

プロジェクトマネジメントでは、成果物だけを見ていては足りません。

その成果物を作るために、

誰がアクセスできるのか
どの端末から接続するのか
どんな権限を持っているのか
認証情報はどう管理されているのか
データはどこに保存されているのか
再委託先は存在するのか
事故時の連絡経路は決まっているのか

まで含めて考える必要があります。

契約書に「セキュリティ対策を適切に行うこと」と書いただけでは、管理したことにはなりません。

自社が強くても、つながった先が弱ければ侵入口になる

IPAの「情報セキュリティ10大脅威 2026」では、組織向け脅威の第2位に、

「サプライチェーンや委託先を狙った攻撃」

が挙げられています。

攻撃者から見れば、最も強固な場所から入る必要はありません。

つながっている中で、一番入りやすい場所を探せばよいのです。

本社のセキュリティを強化しても、

委託先のPCが脆弱
共有アカウントを使っている
多要素認証がない
必要以上の権限を与えている
クラウド共有範囲が広い
退職者のアカウントが残っている

といった状態であれば、そこが入口になる可能性があります。

セキュリティの強さは、自社だけの平均点ではなく、つながっている仕組みの弱い部分で決まります。

これはセキュリティだけの話ではない

私は、この構造はプロジェクト全般に共通していると思っています。

例えば、

配送会社に任せた結果、顧客への配送品質が落ちた
開発会社に任せた結果、障害対応が遅れた
広告代理店に任せた結果、ブランド表現が崩れた
コールセンターに任せた結果、顧客対応品質が落ちた
外部倉庫に任せた結果、在庫精度が悪化した

顧客から見れば、

「どの会社へ委託しているか」

は基本的に関係ありません。

顧客が契約しているのは、発注元の企業であり、そのサービスです。

顧客から見れば、委託先も含めて一つのサービスです。

外注で最も危険なのは「責任の空白」

問題が起きたとき、よくあるのが責任の押し合いです。

発注側は、

「委託先の作業です。」

委託先は、

「発注元からそこまで指示されていません。」

さらに再委託先がいれば、

「自分たちは指定された作業だけをしています。」

こうして、誰も全体を見ていない状態が生まれます。

プロジェクトで怖いのは、責任者がいないことではありません。

責任者がいるように見えて、実際には誰も全体責任を持っていないことです。

発注側が確認すべきこと

では、発注側は何を管理すべきでしょうか。

最低限、次のような項目は確認対象になります。

接続経路：どこから自社環境へ接続するのか
権限：必要最小限になっているか
認証：個人ID、多要素認証、共有アカウントの有無
端末：委託先端末の管理水準
データ：何を渡し、どこに保存するのか
再委託：誰まで業務・データが渡るのか
監視：異常アクセスを検知できるか
事故対応：連絡、遮断、調査の役割分担
定期確認：契約時だけでなく継続的に確認しているか

IPAも、ビジネスパートナーや委託先を含むサプライチェーン全体について、対策状況を把握し、契約上の役割と責任範囲を明確化することを求めています。

「信用する」と「確認しない」は違う

長年付き合っている委託先。

大手企業。

実績のある会社。

担当者も優秀。

だから大丈夫。

プロジェクトでは、こうした「信用」がいつの間にか「確認しない理由」へ変わることがあります。

しかし、本来の信用とは、確認しなくてよいという意味ではありません。

信用しているから任せる。

責任があるから確認する。

この二つは両立します。

管理するのは会社ではなく「境界」

私は、外部委託の管理で重要なのは、会社単位で見ることではなく、

自社と外部の境界を見ること

だと思っています。

どの情報が渡るのか。

どのシステムにつながるのか。

誰が操作できるのか。

どこまで戻ってこられるのか。

ここを管理する。

なぜなら、事故は会社の組織図ではなく、

情報、権限、作業、責任のつながり

を通って発生するからです。

コンサルタントやPMが見るべき範囲

PMが見る範囲を、自社メンバーと自社タスクだけに限定すると、プロジェクトの本当のリスクは見えません。

開発会社。

物流会社。

決済会社。

SaaS。

広告会社。

コールセンター。

再委託会社。

サービスを成立させる以上、すべてプロジェクト構造の一部です。

組織図の外にいるからといって、プロジェクトの外にいるわけではありません。

まとめ

委託先で事故が起きたとき、直接的な原因が委託先にあることはあります。

しかし、それだけで話を終わらせると、本当の再発防止にはつながりません。

発注側にも、

なぜその権限を与えていたのか
なぜその接続方法だったのか
なぜそこまでデータを渡していたのか
なぜ異常を検知できなかったのか
なぜ定期確認をしていなかったのか

という問いが残ります。

委託先を管理するということは、委託先を疑うことではありません。

顧客に提供するサービス全体に責任を持つということです。

仕事は外注できます。

作業も外注できます。

専門知識も外から借りることができます。

しかし、

「自社のサービスとして提供する責任」だけは、外注できません。

プロジェクトマネジメントとは、自社の中だけを管理することではありません。

顧客へ価値を届けるまでにつながる、すべての関係者と境界を管理すること。

そこまでが、プロジェクトなのだと思います。

議題