自分が書いたコードではない部分——委託先の作業や、組み込んだクラウド基盤、外部のソフト部品——が原因で不具合が起きても、案件の中で説明を求められるのはそこに関わるエンジニアです。デジタル庁が2025年にまとめた資料には、調達の上流で起きたごく一部の問題が、広い範囲まで伝わっていった実例が記録されています。この記事では、その実例と、参画前・参画中に確かめられる項目を整理し、自分の担当外が原因の事故にどう備えるかを見ていきます。

1. 自分が書いていない部分から事故は来る

案件に入るときに見えている範囲は限られている

受託や準委任で開発・運用に関わる案件では、自分が担当する範囲は契約書やタスク一覧で区切られています。ですが、実際に動くシステムは、自分が書いたコードだけで成り立っているわけではありません。外部から取り入れたソフト部品、委託先が担当する工程、クラウド事業者が提供する基盤——これらが積み重なって、ようやく1つのサービスになっています。

自分の担当分だけを見ていれば十分だと感じる場面は多いはずです。しかし、事故が起きたときに説明を求められる範囲は、担当した工程だけにとどまりません。担当した工程だけを説明するよりも、上流でどんな仕組みが動いているかを把握しておくほうが、説明の負担は小さくなります。案件に関わっている以上、上流で何が起きているかを知っておくことが、次の一手につながります。

たとえば、クラウド事業者の設備でトラブルが起きても、案件の契約上は「クラウドの管理は事業者の責任」と整理されている場合があります。それでも、クライアントから見れば、案件に入っているエンジニアが状況を把握し、説明できる立場にあることを期待されます。ここで慌てないためには、上流にどんな部品や事業者が関わっているかを事前に知っておくことが役に立ちます。ソフトウェアの更新プログラム、クラウドの設備、委託先の作業体制——どれも自分が直接操作していない部分ですが、案件を支える土台になっています。

事故は上流から伝わってくる

デジタル庁が2025年に公開したグッドプラクティス集は、政府情報システムを対象に、委託先やソフト部品、クラウド基盤といった「調達の上流」で起きた問題が、どのように下流へ伝わっていくかを整理した資料です。ここに載っている実例を見ると、上流のごく一部が崩れただけで、影響がサービス全体まで広がっていく流れが見えてきます。

図の作成：Remogu編集部。資料が示す上流から下流への伝わり方を整理したもので、統計データではありません

この流れを知っておくと、事故が起きたときに「どこまでが自分の担当範囲か」を整理しやすくなります。次の章では、実際に資料に記録されている3つの実例を見ていきます。

2. 資料に載っている3つの実例

クラウド基盤の障害と、監視製品への攻撃

1つ目は、クラウド基盤に関わる障害です。ある行政サービスでは、ストレージ装置のファームウェア不具合によるハードウェア故障が原因でサービスが停止し、復旧までに約1週間を要した事例が記録されています¹。事業者名や自治体名は資料に記載されていないため、この記事でも特定はしません。

2つ目は、ネットワークやシステムの監視に使う製品への攻撃です。この製品の更新プログラムに不正なコードが仕込まれ、利用していた約18,000の組織に影響が及んだ事例が記録されています²。自分が直接使っていない製品でも、委託先や取引先が使っていれば、影響が回り込んでくることを示す例です。

無承認の再委託

3つ目は、委託先の管理に関わる事例です。公的機関が個人情報のデータ入力業務を国内の業者に委託したところ、その業者が許可を得ずに海外の業者へ再委託し、個人情報が海外に渡っていたことが発覚した事例が記録されています³。委託した相手が、さらに別の相手に業務を渡していないかは、発注する側からは見えにくい部分です。再委託そのものを禁止する内容ではありません。むしろ、委託先がさらに別の相手に業務を渡す場合に、発注側の許可や確認を経ることが前提になっているという点がポイントです。

3つの実例に共通しているのは、事故の発生源が、自分が直接操作している画面の外側にあるという点です。ストレージ装置の製造、監視製品の配布経路、委託先の管理体制——いずれも案件の中で日常的に目にする範囲ではありません。だからこそ、上流で何が使われているかを一度確認しておくことに意味があります。委託先が1社にとどまっているか、さらに先へ業務が渡っていないかを尋ねる、それだけでも状況の見え方は変わります。

3つの実例を並べて見る

ここまで見た3つの実例は、原因になった部分も、表に出る影響の種類もそれぞれ異なります。ハードウェアの不具合、ソフトウェアの更新プログラム、委託先の管理体制——事故の入り口は一つに絞れません。次の表は、この3つの実例を「原因になった部分」と「影響」で並べたものです。自分の案件がどの入り口に近いかを確認する参考にしてください。

実例	原因になった部分	影響
クラウド基盤の障害	ストレージ装置のファームウェア不具合1	サービス停止、復旧に約1週間
監視製品への攻撃	更新プログラムへの不正なコードの混入2	約18,000の組織に影響
無承認の再委託	許可のない海外業者への再委託3	個人情報の海外への流出

出典：デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」（2025年6月19日）をもとに作成

3つの実例からわかるのは、事故の原因になった部分は案件ごとに違うということです。次の章では、原因の一つになりやすい「データセンターの立地」について、資料が示す考え方を見ていきます。

3. どこに置くかで変わること

データセンターの立地は国内が基本

政府情報システムを対象にした資料では、データセンターの設置場所について、国内であることを基本とすると示されています⁴。ここでいう「基本」は政府情報システムを前提にした整理であり、民間の案件すべてに当てはまる要件として一般化されているわけではありません。ただし、データがどこに保存されるかを確認する視点そのものは、業務委託で関わる案件でも参考になります。

他国を使う場合に確かめる観点

資料では、他国にデータセンターがある場合には、各国の法令や規制を調査し、コンプライアンスを確保するためのポリシーを策定すると示されています⁵。立地が変われば、適用される法令も変わります。案件に関わるエンジニアの立場で、この調査やポリシー策定そのものを担う場面は多くありませんが、「今使っている基盤のデータがどこに置かれているか」を把握しておくことは、説明を求められたときの備えになります。

立地を把握していないと、クライアントから問い合わせを受けたときにすぐ答えられず、確認に時間がかかってしまいます。反対に、事前に把握していれば、質問を受けたその場で答えられる範囲が広がります。契約が変わるたびに立地を調べ直すよりも、参画時に一度確認しておくほうが、後の負担は小さくなります。

立地による違いを並べて見る

データセンターの立地は、「国内が基本」か「他国を使う場合」かで、確認しておきたい観点が変わります。次の表は、資料に示された2つの前提を並べたものです。自分が関わる案件のクラウド基盤がどちらに近いかを確認しておくと、事故が起きたときの説明にも困りにくくなります。

立地	資料が示す考え方
国内	設置場所は国内であることを基本とする4
他国の場合	各国の法令や規制を調査し、コンプライアンスを確保するためのポリシーを策定する5

出典：デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」（2025年6月19日）をもとに作成

立地について確認したら、次に見ておきたいのは、契約と技術面での取り決めです。

4. 契約と暗号で確かめること

データの保存場所と転送の規則を契約に盛り込む

資料では、データの保存場所や転送に関する規則を明確にし、契約に盛り込むと示されています⁶。案件に参画する前や参画中に、データがどこに保存され、どのような経路で転送されるのかが契約や仕様に明記されているかを確認しておくと、後から把握していなかったという状況を避けやすくなります。

暗号化の技術的な観点

技術的な対策としては、CRYPTREC暗号リストに掲載されている暗号、またはこれと同等の暗号を用いて利用者データを暗号化することが挙げられています⁷。個別のアルゴリズム名までは資料に記載されていないため、この記事でも特定のアルゴリズムには触れません。個別のアルゴリズムを議論するよりも、最新のリストに沿っているかを確認するほうが、案件の実務では扱いやすい観点です。

契約面と技術面、それぞれで確かめる項目

契約面での取り決めと、技術面での対策は、どちらか一方だけでは十分になりません。契約で保存場所や転送規則を明確にしていても、暗号化の方式が古いままでは技術的な不安が残ります。逆に暗号化だけを整えても、委託先が許可なく再委託していれば、契約上の取り決めが機能しません。次の表は、確認しておきたい項目を契約面と技術面に分けて整理したものです。

クライアントとの打ち合わせで「データの保存先はどこですか」「暗号化の方式は最新のリストに沿っていますか」と尋ねられる場面を思い浮かべてみると、契約書の一文を思い出せるかどうかで、答えられる範囲は大きく変わってきます。日頃から契約や仕様の該当箇所を確認しておくことは、事故の有無に関わらず、案件を進める上での安心材料になります。

確認する面	資料が示す項目
契約面	データの保存場所・転送に関する規則を明確にし契約に盛り込む6
技術面	CRYPTREC暗号リストに掲載された暗号、または同等の暗号での暗号化7

出典：デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」（2025年6月19日）をもとに作成

5. リモート・フリーランス案件でどう関わるか

参画前に確かめておきたい項目

ここまで見てきた実例と観点を、案件に参画する立場から整理すると、確認しておきたいことは大きく3つに絞られます。1つは、自分が使う基盤やソフト部品が、どこの委託先やクラウド事業者によって提供されているかです。2つ目は、データがどこに保存され、どう転送されているかが契約や仕様に明記されているかです。3つ目は、暗号化の方式が最新の基準に沿っているかです。すべてを自分1人で調査する立場になるとは限りませんが、クライアントと協議しながら確認できる範囲を広げておくことは、参画後の安心材料になります。

リモートでも確認は進められる

これらの確認事項は、常駐が前提の作業ではありません。契約書や仕様書の記載を確認したり、委託先やクラウド基盤に関する情報をクライアントと共有したりする作業は、リモートの環境でも進めやすい領域です。常駐して確認するよりも、契約書や仕様書をオンラインで共有しながら確認するほうが、記録として残しやすいという利点もあります。Remoguでは、案件の90%以上がフルリモート可能です⁸。場所に縛られずに、こうした確認や協議を含む案件に関わりたい場合、まずは自分の経験に近い条件の案件を確認してみることが、次の一歩になります。

契約や仕様を確認する習慣を持っておくことは、技術力とは別の評価軸になります。指示された作業だけをこなすよりも、上流で何が使われているかまで目を配れる関わり方のほうが、クライアントとの協議の場面で頼られやすくなります。積み上げてきた経験を、こうした確認の視点にも広げておくと、参画先を選ぶときの判断材料も増えていきます。

6. まとめ

自分が書いていない部分——委託先の作業、クラウド基盤、組み込んだソフト部品——が原因の事故であっても、案件に関わっている以上、説明を求められる場面は避けられません。資料に記録された3つの実例は、事故の入り口が一つに絞れないことを示しています。データセンターの立地、契約に盛り込む規則、暗号化の技術的な対策——確認できる項目を1つずつ押さえておくことが、事故が起きたときの備えになります。

これらの確認は、事故そのものをなくすためのものではなく、事故が起きたときに自分の立ち位置を説明できるようにするための備えです。委託先が誰に何を渡しているか、データがどこに保存されているか、暗号化の方式が最新かどうか——1つずつ尋ねる習慣をつけておくことが、案件に関わる上での安心につながります。

こうした確認や協議を含む案件に、リモートの環境から関わりたいと感じている場合は、まず自分の経験に合う条件の案件を確認してみることから始めてみましょう。

7. よくある質問

サプライチェーンリスクとは何ですか

案件で使うソフト部品や、委託先、クラウド基盤といった外部の要素を経由して事故や被害が広がるリスクを指します。デジタル庁のグッドプラクティス集では、政府情報システムを対象に、こうした上流の問題が下流へどのように伝わるかが整理されています¹。自分が直接管理していない部分が起点になる点が、通常の不具合対応と異なります。案件によって、上流にどのような部品や委託先が関わっているかは異なるため、まずは自分の案件を支えている要素を把握しておくことが出発点になります。

自分の担当外が原因の事故でも、責任を問われますか

この記事で参照している資料は、政府情報システムを対象にした整理であり、個々の案件における法的な責任の範囲を判断するものではありません。誰にどこまでの責任が生じるかは案件の契約内容によって異なるため、この記事では断定はできません。ここで紹介した確認項目は、事故が起きた際に自分の担当範囲を説明しやすくするための備えとして参考にしてください。具体的な責任の範囲について気になる場合は、契約時にクライアントと協議し、担当範囲を文書で確認しておくことをおすすめします。

再委託は禁止されていますか

資料に記録されている事例は、許可を得ずに海外の業者へ再委託されたことが問題になったものです³。再委託そのものを禁止する内容ではなく、委託先がさらに別の相手に業務を渡す場合には、発注する側の許可や確認を経ることが前提になっているという点がポイントです。案件に関わる立場からは、委託先が別の相手に業務を渡す予定があるかどうかを、契約の段階でクライアントに確認しておくと、後から状況が分かりにくくなることを避けやすくなります。

海外のクラウドは使えませんか

資料が示す「データセンターの設置場所は国内であることを基本とする」という考え方は、政府情報システムを前提にした整理です⁴。民間の案件すべてに一般化できるものではありません。他国にデータセンターがある場合は、各国の法令や規制を調査し、ポリシーを策定するという観点が示されています⁵ので、立地に応じた確認が必要になるという点を押さえておくとよさそうです。特定のクラウド事業者が優れているかどうかを判断する材料ではなく、自分が関わる案件のデータがどこに置かれているかを確認する視点として受け取っておくと使いやすくなります。

リモートの案件でも、こうした確認に関われますか

契約や仕様の確認、委託先やクラウド基盤に関する情報の共有は、常駐でなくても進めやすい作業です。Remoguでは、案件の90%以上がフルリモート可能です⁸。リモートの環境から、こうした確認や協議を含む案件に関わりたい場合は、まず自分の経験に合う条件を確認してみることをおすすめします。場所にとらわれずに関われる案件が増えれば、契約や仕様を確認する時間も、これまでより確保しやすくなります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」DS-203 表2 事例（2025年6月19日）
＊2 デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」DS-203 表2 事例（2025年6月19日）
＊3 デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」DS-203 表2 事例（2025年6月19日）
＊4 デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」DS-203 国内法以外の法令及び規制が適用されるリスクへの管理的対策（2025年6月19日）
＊5 デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」DS-203 国内法以外の法令及び規制が適用されるリスクへの管理的対策（2025年6月19日）
＊6 デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」DS-203 国内法以外の法令及び規制が適用されるリスクへの管理的対策（2025年6月19日）
＊7 デジタル庁「政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理 及び その対策のグッドプラクティス集」DS-203 国内法以外の法令及び規制が適用されるリスクへの技術的対策（2025年6月19日）
＊8 Remoguサイト公開情報（フルリモート可能案件の割合）