製品開発の協力会社のサイバー対策を見る5項目｜製品の脆弱性リスクに備える

製品開発で協力会社のサイバー対策が重要になる理由

製品開発を外部の協力会社と進めるとき、確認すべき項目は技術力、開発実績、品質管理、納期対応、量産への移行能力だけではありません。電子機器や通信機能を持つ製品、ソフトウェアを組み込んだ製品、ネットワークと接続する製品が増えるなかで、協力会社のサイバー対策も重要な評価項目になっています。

製品開発では、設計図面、回路情報、ソースコード、仕様書、試験結果、製造条件、顧客情報など、多くの重要情報を社外と共有します。開発を効率化するためには情報共有が欠かせませんが、共有範囲が広がるほど、不正アクセス、誤送信、アカウントの不正利用、端末の紛失などによって情報が外部へ流出する可能性も考える必要があります。

さらに注意したいのが、情報管理だけではなく、開発した製品そのものに脆弱性が残るリスクです。通信機能や制御機能を備えた製品では、設計時には問題なく動作していても、使用しているソフトウェアや通信処理などに後から問題が見つかる場合があります。開発完了時点だけを確認して終わるのではなく、設計、試作、評価、量産、出荷後までを含めて管理できる体制が求められます。

協力会社を選ぶ際には、「サイバー対策をしていますか」と質問するだけでは十分な判断材料になりません。重要なのは、どの情報をどのように管理し、誰がアクセスでき、問題が発生した場合にどのように対応するのかを具体的に確認することです。

サイバー対策について専門部署を持っている会社であっても、実際の製品開発プロジェクトで運用されていなければ意味がありません。反対に、大規模な組織ではなくても、開発データの管理、アクセス権限、脆弱性確認、インシデント対応などについてルールを定め、継続して運用している協力会社であれば、開発リスクを抑えやすくなります。

ここでは、「製品開発 協力会社」で検索し、設計や試作、ソフトウェア開発、量産準備などを任せる企業を探している担当者に向けて、協力会社のサイバー対策を見る際に確認したい5つの項目を解説します。

1．開発データと機密情報の管理方法を確認する

最初に確認したいのは、製品開発に関係するデータをどのように管理しているかです。サイバー対策というと、外部からの攻撃を防ぐことに意識が向きがちですが、製品開発では日常的な情報の取り扱いが重要になります。

協力会社には、仕様書、図面、試験データ、画像、設計変更情報など、さまざまな情報を渡す可能性があります。そのため、まず確認したいのは、受け取ったデータをどこへ保存し、誰が閲覧できる状態にするのかという基本的な運用です。

例えば、担当者が自由に個人用の記録媒体へコピーできる状態になっていたり、退職者や別案件の担当者が長期間アクセスできる状態になっていたりすると、情報管理上のリスクが高まります。開発案件ごとに保存場所やアクセス範囲が整理され、必要な担当者だけが情報へアクセスできる仕組みになっているかを確認することが重要です。

また、社外へデータを送る場合の方法も確認しておきたいポイントです。重要な設計情報を担当者個人の判断だけで外部へ送信できる状態では、誤送信や送付先の間違いを完全に避けることは難しくなります。重要情報を扱う際の承認手順や共有方法が決められているかを見ることで、実際の運用レベルを把握しやすくなります。

さらに、協力会社が再委託を行う場合には、その先で情報がどのように扱われるかも確認が必要です。製品開発では、機構設計、回路設計、ソフトウェア開発、試作加工、評価などを複数の企業が分担することがあります。発注先だけで適切に管理されていても、再委託先へ無制限にデータが渡ってしまえば、管理範囲は急速に広がります。

そのため、再委託する場合に発注元への事前確認が必要なのか、再委託先にも同等の情報管理を求めているのか、渡す情報を必要最小限に制限しているのかを確認しておくと安心です。

開発終了後のデータの扱いも重要です。プロジェクト終了後にデータをそのまま残すのか、一定のルールに基づいて保管するのか、返却や削除を行うのかをあらかじめ決めておけば、契約終了後に不必要な情報が残り続けるリスクを減らせます。

協力会社を評価するときは、「秘密保持契約を結んでいるから大丈夫」と考えるのではなく、その約束を実際の業務でどのように実現しているのかを見ることが大切です。規定の有無だけではなく、担当者が普段どのようにデータを扱っているかまで確認できると、より実態に近い評価ができます。

2．製品に組み込むソフトウェアの脆弱性管理を確認する

通信機能や制御機能を持つ製品を開発する場合には、製品に組み込まれるソフトウェアの管理方法を確認する必要があります。

製品開発では、すべての機能を一から作るとは限りません。既存のソフトウェア部品や一般的なライブラリなどを組み合わせて開発することもあります。こうした方法は開発期間の短縮や品質の安定に役立つ一方、使用している構成要素に問題が見つかった場合には、製品側への影響を確認する必要があります。

そこで協力会社に確認したいのが、製品へ組み込んでいるソフトウェアの構成を把握しているかどうかです。

開発担当者しか構成を把握しておらず、納品後には何を使用していたか分からなくなる状態では、問題発生時の調査に時間がかかります。製品のどの機能でどのようなソフトウェア構成を使用しているかを管理し、必要に応じて確認できる体制になっていることが重要です。

脆弱性が見つかった場合の対応方法も確認します。問題が公表された際に、それが自社製品へ影響するか調査する仕組みがあるのか、影響がある場合にどのような手順で修正を検討するのかを確認すると、協力会社の対応力が見えてきます。

特に注意したいのが、「開発時点で正常に動作したため問題ない」という考え方です。機能試験に合格していることと、将来にわたって脆弱性が発生しないことは同じではありません。製品出荷後に新しい問題が判明する可能性も考え、後から調査できる状態を作っておく必要があります。

また、開発時には意図していなかった機能が残っていないかを確認することも重要です。試作時の確認用機能や開発用の設定が量産版に残っていると、不要なリスクにつながる可能性があります。試作段階と量産段階で設定を分け、製品として不要な機能を整理できる運用になっているかを見ることが有効です。

通信を行う製品では、外部との接続部分も確認対象になります。どの通信経路を使用し、どのような情報を送受信し、どの範囲からアクセスできるのかを設計段階で整理している協力会社であれば、後工程で問題が見つかる可能性を抑えやすくなります。

発注側としても、「安全な製品にしてください」という抽象的な要求だけではなく、想定する利用環境や接続方法を共有することが大切です。社内ネットワークだけで使う製品と、インターネットを経由して利用する製品では、考えるべきリスクが異なります。利用条件を発注側と協力会社で共有したうえで対策を検討することが、現実的なサイバー対策につながります。

3．開発環境とアクセス権限の管理体制を確認する

3つ目の確認項目は、開発環境へのアクセス管理です。

製品開発では、多くの担当者がデータを扱います。機構設計者、回路設計者、ソフトウェア担当者、試験担当者、生産技術担当者などが、それぞれ必要な情報へアクセスしながら開発を進めます。そのため、アクセスできる人を適切に管理していなければ、意図しない情報閲覧やデータ変更が起きる可能性があります。

確認したいのは、担当者ごとに必要な権限を設定しているかどうかです。全員がすべてのデータを閲覧・変更できる状態にするのではなく、業務に必要な範囲へアクセスを限定することが基本になります。

プロジェクトへ途中参加した担当者、配置転換した担当者、退職した担当者などの権限がどのように変更されるかも重要です。アカウントだけが残り続ける状態を避けるためには、人員変更と権限変更を連動させる運用が必要です。

認証方法も確認するとよいでしょう。パスワードだけに依存するのではなく、重要なシステムでは追加の認証方法を利用するなど、アクセス先の重要度に合わせて対策を取っているかを見ることで、管理レベルを判断できます。

開発用端末についても確認が必要です。担当者が使用する端末に対して、ソフトウェア更新、端末管理、外部記録媒体の利用、持ち出しなどのルールが設けられているかを確認します。

在宅勤務や外出先から開発作業を行う場合には、社外からどのように開発環境へ接続するのかも重要になります。外出先から自由に接続できる状態と、決められた方法で認証したうえでアクセスする状態では、リスクが大きく異なります。

ソースコードや設計データの変更履歴を残しているかも確認しておきたいポイントです。誰がいつ変更したか分からない状態では、問題が発生した際の原因調査が難しくなります。変更履歴が確認できれば、意図しない変更が行われた場合でも影響範囲を追いやすくなります。

さらに、開発環境と実際に製品へ組み込むデータを作る環境をどのように管理しているかも重要です。開発途中のファイルと正式版が混在していると、誤ったバージョンを量産へ渡すリスクがあります。最終的にどのデータが正式版なのかを識別でき、承認後のデータが適切に管理されているかを確認することが大切です。

サイバー対策では高度な技術対策ばかりに注目しがちですが、日常的なアカウント管理や版管理が不十分であれば、大きな問題につながることがあります。協力会社を選定する際には、現場の運用として権限管理が定着しているかを見ることが重要です。

4．インシデント発生時の連絡・対応体制を確認する

どれだけ対策を行っても、トラブルの可能性を完全になくすことはできません。そのため、協力会社選定では問題を起こさないための対策だけでなく、問題が起きた場合の対応力も確認する必要があります。

確認したいのは、まず異常を発見した際の社内連絡体制です。開発担当者が不審な挙動や情報の誤送信などに気付いた場合、誰へ報告し、どのような判断を行うのかが明確になっているかを確認します。

連絡先が曖昧だったり、担当者が個人で判断して対応したりする体制では、初動が遅れる可能性があります。社内で責任者や報告経路が決められている会社であれば、問題発生時の対応を進めやすくなります。

発注側への連絡条件も重要です。協力会社側でサイバーセキュリティ上の問題が発生しても、それが自社案件に関係しているか判断できるまで連絡されないケースも考えられます。しかし、発注側としては、自社データが関係している可能性があれば早い段階で状況を把握したい場合があります。

そのため、契約前に「どのような事象が発生した場合に連絡するのか」「どの程度の時間内に初報を行うのか」「調査結果をどのように共有するのか」といった基本的な考え方を確認しておくことが有効です。

初報の時点ですべての原因が判明しているとは限りません。重要なのは、確定情報が少ない段階でも、影響の可能性があることを共有できる体制です。その後、調査が進むにつれて影響範囲や原因、再発防止策などを更新していく形が現実的です。

製品側で脆弱性が見つかった場合には、さらに対応範囲が広がります。すでに出荷した製品への影響を確認し、必要であれば修正版を準備し、利用者へどのように反映するかを検討する必要があります。

このとき、製品の構成情報や出荷したバージョンが管理されていなければ、どの製品が影響を受けるか判断しにくくなります。したがって、インシデント対応力を見る際には、単に緊急連絡先の有無だけではなく、製品情報を追跡できる仕組みまで確認することが重要です。

過去に問題が起きた経験がある場合には、その際にどのような改善を行ったかを聞く方法もあります。ただし、事故経験の有無だけで協力会社を評価するのは適切ではありません。重要なのは、問題を分析し、運用改善へつなげる仕組みを持っているかどうかです。

サイバー対策は、問題を隠さず共有できる関係づくりも重要になります。発注側が一方的に責任を追及する姿勢だけでは、初期段階の情報が共有されにくくなる可能性があります。問題発生時に必要な情報を速やかに共有し、双方で対応できる関係を契約段階から作っておくことが大切です。

5．納品後も継続して脆弱性へ対応できるか確認する

製品開発のサイバー対策で見落とされやすいのが、納品後の対応です。

従来の機械部品であれば、図面どおりに製造され、検査に合格して納品された時点で開発案件が一区切りになるケースもあります。しかし、ソフトウェアを含む製品や通信機能を持つ製品では、出荷後に新しい脆弱性が発見される可能性があります。

そのため、協力会社を選ぶ際には、開発完了後にどこまで対応できるかを確認することが重要です。

まず確認したいのは、納品した製品のソフトウェア構成やバージョンを追跡できるかどうかです。どの製品にどのバージョンが組み込まれているか分からなければ、問題が見つかったときに影響範囲を特定することが難しくなります。

次に、脆弱性情報をどのように把握するかを確認します。使用している構成要素に関する問題が見つかった際に、それを確認する担当者や手順があるかを見ることが重要です。

さらに、修正が必要と判断された場合の対応方法も確認しておきます。修正版をどのように作成し、どのように検証し、どのように提供するのかを事前に整理しておけば、実際に問題が発生した際の混乱を減らせます。

製品によっては、利用者側で簡単にソフトウェアを更新できない場合もあります。工場設備や現場設備へ組み込まれる機器などでは、停止時間や作業条件を考慮しながら更新を行う必要があります。そのため、更新機能を設計する段階から、将来の保守方法を検討することが重要です。

どの程度の期間サポートするかについても、発注側と協力会社で認識を合わせておく必要があります。製品の販売期間や使用期間が長い場合には、開発終了後も一定期間は問い合わせや調査が発生する可能性があります。

契約上の開発期間だけを見て協力会社を選ぶと、数年後に問題が発生した際、当時の担当者がいなくなり、構成情報も残っていないという状況が起こり得ます。担当者個人の記憶に頼らず、設計情報や変更履歴を組織として管理しているかを確認することが重要です。

また、協力会社が使用しているソフトウェア部品を変更する場合のルールも確認するとよいでしょう。開発途中で構成が変わった場合に発注側へ共有される仕組みがあれば、知らない間に製品構成が変わるリスクを抑えやすくなります。

製品のサイバー対策は「出荷時点で安全だったか」だけではなく、「出荷後に問題が見つかったとき対応できるか」まで含めて評価する必要があります。長期間使用される製品ほど、この視点が重要になります。

製品開発の協力会社を選ぶときはサイバー対策をどう評価するか

ここまでの5項目を確認すると、協力会社のサイバー対策を見る際には、単純にセキュリティ設備の有無を比較するだけでは不十分であることが分かります。

重要なのは、実際の製品開発プロセスの中で対策が機能しているかどうかです。

例えば、情報管理について高度なルールがあったとしても、開発担当者が理解していなければ十分とはいえません。反対に、分かりやすいルールを決め、担当者が日常的に守っている企業であれば、安定した運用を期待しやすくなります。

協力会社を評価する際には、最初から完璧な回答を求めるよりも、具体的な運用を質問する方法が有効です。

「開発データはどこへ保存していますか」「新しく担当者が参加した場合、誰がアクセス権を付与しますか」「担当者が退職した場合、いつ権限を停止しますか」「製品に組み込んでいるソフトウェア構成は後から確認できますか」「脆弱性が見つかった場合、誰が影響を調査しますか」といった質問をすると、実際の運用が見えやすくなります。

回答が抽象的な場合には、具体的な手順を聞いてみることが重要です。「適切に管理しています」という説明だけでは、実態を判断できません。誰が、いつ、どのように確認しているのかまで説明できる企業であれば、ルールが実務へ定着している可能性が高くなります。

また、製品の性質によって必要な対策レベルを変えることも重要です。通信機能を持たない単純な機械部品と、外部ネットワークへ接続する機器では、必要となる確認項目が異なります。

すべての協力会社へ同じ要求を課すのではなく、扱う情報の重要度、製品の利用環境、通信機能の有無、製品が停止した場合の影響などを考慮して評価項目を設定することが現実的です。

開発初期にリスクを整理しておくことで、必要以上に対策を複雑化することも、必要な対策を見落とすことも避けやすくなります。

サイバー対策を理由に開発速度を落とさないためには、開発工程へ自然に組み込むことも重要です。設計完了後にまとめて確認するのではなく、仕様決定、基本設計、詳細設計、試作、量産移行などの節目で確認を行えば、後工程で大きな修正が発生する可能性を減らせます。

協力会社選びでは、技術力とサイバー対策を別々に考えるのではなく、「安全性を含めて製品を設計できる開発力」として評価することがポイントです。

契約と開発プロセスにサイバー対策を組み込む

適切な協力会社を選定できても、発注後の進め方が曖昧では十分な対策になりません。サイバー対策に関する重要事項は、可能な範囲で契約や開発ルールへ反映しておくことが大切です。

まず整理したいのが、情報の取り扱い範囲です。どの情報を機密情報として扱うのか、再委託先へ共有してよい情報は何か、プロジェクト終了後に情報をどう扱うのかを明確にします。

次に、開発成果物の管理範囲を整理します。ソースコード、設計データ、設定情報、試験結果、構成情報など、後から製品を保守するために必要な資料が何かを決めておくことが重要です。

納品物を完成した製品やプログラムだけに限定すると、将来問題が発生した際に調査材料が不足する可能性があります。開発時の判断根拠や構成情報をどこまで残す必要があるかを、製品の重要度に応じて決めておきます。

変更管理も重要です。開発途中で通信仕様や使用するソフトウェア構成が変更された場合、誰が承認し、どのように履歴を残すのかを決めておけば、意図しない変更を抑えやすくなります。

試作から量産へ移行する際には、開発用設定が残っていないか、不要な機能が有効になっていないか、正式版のソフトウェアが正しく組み込まれているかを確認する工程を設けることも有効です。

さらに、問題発生時の連絡方法を決めておきます。通常の開発連絡とは別に、緊急時の担当者や連絡経路を整理しておけば、異常発生時に連絡先を探す時間を減らせます。

サイバー対策は発注側だけ、または協力会社だけで完結するものではありません。発注側が利用環境や重要情報を十分に伝えていなければ、協力会社も適切な対策を設計できません。

例えば、製品がどのようなネットワークへ接続されるのか、どの程度の期間使用されるのか、停止した場合にどのような影響があるのかといった情報は、対策を検討するうえで重要です。

また、開発途中で利用方法が変わった場合には、その変更を協力会社へ共有する必要があります。当初は閉じた環境で使用する予定だった製品を、後から外部ネットワークへ接続することになれば、想定すべきリスクも変わります。

つまり、協力会社のサイバー対策を評価することは、発注先を審査して終わる活動ではありません。発注側と協力会社が製品のライフサイクルを通じて情報を共有し、設計や運用を更新していくことが重要です。

まとめ

製品開発の協力会社を選ぶ際には、設計力、試作対応、品質管理、量産能力などに加えて、サイバー対策も確認する必要があります。

特に確認したいのは、開発データや機密情報をどのように扱っているか、製品に組み込むソフトウェアの構成や脆弱性を管理できるか、開発環境へのアクセス権限を適切に管理しているか、問題発生時の連絡・対応体制があるか、そして納品後も継続して脆弱性へ対応できるかという5つの項目です。

これらは個別に存在するものではありません。情報管理ができていても製品構成を追跡できなければ、脆弱性発見時の調査に時間がかかります。製品構成を管理していても、問題発生時の連絡ルールがなければ初動が遅れる可能性があります。開発から出荷後まで一貫した仕組みとして管理できているかを見ることが重要です。

また、協力会社へ要求するだけではなく、発注側も製品の利用環境、想定する通信方法、重要な情報、必要な保守期間などを明確に伝える必要があります。サイバー対策は、発注側と協力会社が共通の前提を持って進めることで実効性を高めやすくなります。

製品開発が進むほど、設計情報、試験結果、現場で得られた写真や記録など、扱うデータは増えていきます。開発後の施工、設置、点検、維持管理まで含めて考える場合には、現場側の情報を整理し、必要な担当者が確認できる状態を作ることも重要です。

現場写真・位置情報・施工記録を管理するLRTK Phoneを活用すれば、現場で取得した情報を位置と結び付けて整理しやすくなります。製品開発だけでなく、その後の設置や施工、点検、維持管理まで情報をつなげていきたい場合には、サイバー対策とあわせて、現場情報をどのように記録・共有・管理するかも検討してみてください。