物流業のSCS対応で固有の制約は、24時間稼働で止められないことと倉庫の自動化設備が古いまま動いていることです。止めずにできる対策（多要素認証、アカウント棚卸し、ログ取得、教育）を先に片付け、停止を伴うものは繁閑差を見て計画します。更新できない制御系は、ネットワークを分離して接続経路を限定する代替の統制で対応してください。
SCS評価制度の★取得について、現状アセスメントからギャップ分析、技術対策の実装、申請サポートまでをワンストップでご支援しています。
SCS評価制度 対応支援 を見る →SCS評価制度 総合ガイド物流業が問われる理由
物流事業者は、荷主の事業活動の内側にある情報を大量に扱います。誰が、何を、いつ、どこへ、どれだけ運んだかという情報は、荷主にとって競争上の機密であり、同時に荷主の顧客の個人情報でもあります。
加えて、物流が止まると荷主の事業が止まります。攻撃者から見れば、荷主本体より防御が手薄で、かつ停止させたときの影響が大きい標的になり得ます。この構造から、荷主は自社と同等の水準を物流パートナーに求めるようになっています。
とくに次の立場では要求される可能性が高くなります。
- 3PLとして荷主の在庫データや出荷情報を預かっている
- 製造業のサプライチェーンに組み込まれ、部品の供給に関わっている
- 医薬品・食品など、トレーサビリティが求められる分野を扱っている
荷主からの要求水準
荷主からの要求は、SCSの★指定だけでなく、独自のチェックシートや監査の形で来ることもあります。複数の荷主と取引していると、要求がばらつきます。
対応の方針は、荷主ごとに作り分けず、最も厳しい要求を自社の標準に据えることです。個別対応を積み上げると管理が破綻し、新規の要求が来るたびに一から作業することになります。
また、契約に情報の取り扱い条項や報告義務が定められていることがあります。主要荷主の契約書から該当条項を抜き出して一覧にしておくと、インシデント発生時に契約書を探す時間を省けます（インシデント対応計画の作り方）。
止められない現場という制約
物流現場の多くは24時間、あるいは早朝から深夜まで稼働しています。「メンテナンス時間を取って全台にパッチを当てる」という進め方が通用しません。
そこで、止めずにできるものと、停止が必要なものを分けて計画します。
| 区分 | 対策例 | 進め方 |
|---|---|---|
| 止めずにできる | 多要素認証の有効化、アカウント棚卸し、ログの取得と保存、従業員教育、共有設定の見直し | すぐ着手する。稼働への影響がない |
| 短時間の停止で済む | 端末単位のパッチ適用、EDRの展開 | シフトの切れ目や台数を分けて段階的に |
| まとまった停止が必要 | サーバー更改、ネットワーク構成の変更、制御系の更新 | 繁閑差のある時期を選び、年間計画に載せる |
重要なのは、止められないことを理由に何も進めない状態を避けることです。上段だけでも要求事項のかなりの部分が埋まります。
倉庫の自動化設備
自動倉庫、ソーター、コンベヤの制御系は、製造業のOT環境と同じ課題を抱えます。
- 古いOSで動いている：導入時のまま、サポートが終了したOSで稼働していることがある
- 更新できない：メーカー保証の関係で勝手にパッチを当てられない
- 止められない：稼働中は物理的に触れない
これらは「更新する」以外の方法で守る必要があります。現実的な代替の統制は次のとおりです。
| 統制 | 内容 |
|---|---|
| ネットワーク分離 | 制御系と業務系を分け、直接通信させない |
| 接続経路の限定 | 保守用の接続を特定の端末・特定の時間に限定し、記録を残す |
| 持ち込み媒体の管理 | 保守作業でのUSB使用を申請制にし、事前にスキャンする |
| ベンダーの管理 | 設備メーカーの保守要員も、アクセス管理と記録の対象に含める |
設計の考え方は製造業のOTセキュリティと共通します。更新できないこと自体は不適合になりません。更新できない理由を把握し、代替の統制を設計して記録していることが求められます。
車載端末とドライバーの私物端末
物流業に特有なのが、社外で使われる端末の多さです。
- 車載端末・ハンディターミナル：紛失や盗難のリスクが高い。遠隔でのデータ消去ができるか
- ドライバーの私物スマートフォン：配送アプリや連絡手段として使われている
- 協力会社・傭車のドライバー：自社の管理外の端末で業務情報に触れる
私物端末は、禁止しても実態が変わりにくい領域です。禁止するより、業務データを端末に残さない設計にするほうが現実的です。配送情報は業務アプリ内でのみ扱い、端末への保存やスクリーンショットを制限します。
あわせて、退職・契約終了時にアクセス権を停止する手順を決めてください。ドライバーの入れ替わりが多い事業所では、ここが最も抜けやすい項目です。端末管理の実装はIntuneでの対応が参考になります。
対応の進め方
| 順序 | やること |
|---|---|
| 1 | 荷主から預かっている情報と、その保存先・アクセス範囲を棚卸しする |
| 2 | 止めずにできる対策（多要素認証、アカウント棚卸し、ログ、教育）を実施する |
| 3 | 制御系の構成を把握し、分離と接続経路の限定を設計する |
| 4 | 車載端末・私物端末の扱いと、退職時の停止手順を決める |
| 5 | 停止が必要な対策を年間計画に載せる |
1と2は費用も停止も伴いません。ここを先に終わらせると、残りの投資判断がしやすくなります。
なお、個々の評価基準の文言はIPAが公開する★3の評価基準（81基準）に定義されています。本記事はその文言の解説ではなく、要求を満たすために実務でどう設計するかを整理したものです。申請前には必ず公開されている最新の基準を参照してください。
よくある質問
物流業もSCS評価制度の対象になりますか？
荷主から求められれば対象になります。とくに3PLとして顧客の在庫データや出荷情報を預かる立場、あるいは重要インフラや製造業のサプライチェーンに組み込まれている事業者は、調達要件として問われる可能性が高くなります。
24時間稼働で止められない現場では、どう対策すればよいですか？
止めずに実施できるものから着手します。多要素認証の有効化、アカウントの棚卸し、ログの取得と保存、教育の実施は稼働への影響がありません。停止を伴うパッチ適用や機器の更改は、繁閑差のある時期を選んで計画的に行います。
倉庫の自動化設備もセキュリティ対策の対象ですか？
対象に含めて考えてください。自動倉庫やソーターの制御系は、サポートが終了したOSで動いていることがあり、更新も容易ではありません。更新できない場合は、ネットワークを業務系と分離し、接続できる端末と経路を限定するという代替の統制で対応します。
ドライバーの私物スマートフォンをどう扱えばよいですか？
業務データを私物端末に保存させない設計にするのが現実的です。配送情報は業務アプリ内でのみ扱い、端末への保存やスクリーンショットを制限します。退職時にアプリのアクセス権を停止する手順もあわせて決めてください。
何から着手すればよいですか？
荷主から預かっている情報が何で、どのシステムに保存され、誰がアクセスできるかの棚卸しからです。物流業では基幹システム、荷主ごとの専用システム、表計算ファイルに情報が分散していることが多く、可視化だけで対応範囲が絞り込めます。
まとめ
物流業のSCS対応では、24時間稼働という制約と、古いまま動いている自動化設備の2つが固有の難所になります。止められないことを理由に停滞させないため、多要素認証・アカウント棚卸し・ログ取得・教育といった稼働に影響しない対策から先に片付けてください。
制御系は更新できないことを前提に、ネットワーク分離と接続経路の限定という代替の統制で対応します。更新できないこと自体は不適合になりません。理由を把握し、代替策を設計して記録していることが求められます。車載端末と私物端末は、禁止より「データを端末に残さない」設計のほうが機能します。
自社の現在地を項目単位で確認したい場合は、SCS★3 セルフチェック（無料・登録不要） ↗で26要求事項・81評価基準への適合率を測れます。