EUサイバーレジリエンス法（CRA）を改めて取り上げる本稿では、製品開発の内部で何が起きているのかを検証する必要があります。2026年初頭にかけて、CRAはソフトウェアやスマートデバイスの作り方そのものに根本的な転換を迫っています。MVP（実用最小限の製品）を出荷して、後からセキュリティホールをパッチで塞ぐ時代は、公式に終わりました。
「セキュリティ・バイ・デザイン／デフォルト」の義務化
これまで、サイバーセキュリティの負担は不公平にも消費者側に押し付けられてきました。CRAはこの力学を反転させ、デジタルセキュリティを物理的な製品安全と同等に扱います。デバイスには今後、「Security by Design and by Default」を備えることが求められます。
これは、出荷時点（箱から出してすぐ）で最大限のセキュリティ設定が有効になっている製品を出荷することを意味します。メーカーは、既知の悪用可能な脆弱性や、ハードコードされたデフォルト認証情報（「admin/admin」とはお別れです）を含むデバイスを出荷することが法的に禁止されます。さらにメーカーには、製品の想定ライフサイクルに見合う「合理的な期間」にわたりセキュリティアップデートを提供する義務が課されます。一般に、ほとんどの商用電子機器では最低5年が見込まれます。これらのアップデートは迅速に、可能な限り自動で、かつ完全に無償で提供されなければなりません。
SBOMとエンド・オブ・ライフ（EOL）危機
2026年にエンジニアリングチームが取り組む最大級の運用上のハードルは、Software Bill of Materials（SBOM）要件かもしれません。現代のスマートデバイスはゼロから作られることは稀で、数十のサードパーティライブラリ、オープンソースフレームワーク、独自の依存関係を寄せ集めて構築されています。
CRAの下では、EU向けに出荷するすべての製品について、完全で機械可読なSBOMを維持しなければなりません。しかし可視化は第一歩にすぎません。2026年の本当の危機は、エンド・オブ・ライフ（EOL）の依存関係をめぐるものです。たとえばスマートホームハブが、古いNode.jsや、メンテナがもはやセキュリティパッチを提供しないレガシーなC++ライブラリに依存している場合、脆弱性が見つかれば、パッチ適用の法的責任はそれでもあなたにあります。
2026年に向けた具体的なアクションプラン
エンジニアリングチームは、法務が整理するのを待ってはいられません。いまコードを出荷しているなら、次の4つのステップを直ちに実行する必要があります。
- オープンソース依存関係の監査：完全なSBOMを生成します。製品の宣言サポート期間が終了する前に、EOLに到達している（または到達する）すべてのコンポーネントを特定します。
- CRAの影響範囲をマッピング：EOLコンポーネントごとに、チームに問いかけてください。もし明日このライブラリに重大なCVEが出たら、24時間以内にパッチを当てられるか？答えが「いいえ」なら、コンプライアンス上のギャップがあります。
- 脆弱性対応インフラの確立：第14条のタイムラインに対応するための社内ワークフローを構築します。実際に悪用されている脆弱性に対する厳格なエスカレーション経路を定義し、週末や祝日のインシデントに対応できる複数の権限ある報告担当者を指名します。
- EOLコードの保護または置換：レガシーフレームワークから移行する（多くの場合12〜24か月かかります）、オープンソースコードに自前でパッチを書くための社内知見を構築する、または延長サポートの商用プロバイダーと契約する、のいずれかが必要です。
SBOMスニペット設定例（SPDX形式）：
{
“SPDXID”: “SPDXRef-DOCUMENT”,
“spdxVersion”: “SPDX-2.3”,
“creationInfo”: {
“created”: “2026-01-15T10:00:00Z”,
“creators”: [“Organization: Kokobo Engineering”]
},
“name”: “Kokobo-Smart-Gateway-SBOM”,
“dataLicense”: “CC0-1.0”,
“packages”: [
{
“SPDXID”: “SPDXRef-Package-1”,
“name”: “OpenSSL”,
“versionInfo”: “3.1.2”,
“downloadLocation”: “NOASSERTION”,
“licenseDeclared”: “Apache-2.0”
}
]
}
CRAは単なるコンプライアンスのチェックリストではなく、ソフトウェア・サプライチェーンの根本的な再設計です。