セキュリティを強くしたのに、なぜ現場は抜け道を探し始めるのか——安全な方法を、自然に選ばれる業務へ変える

この記事はこんな人へ

セキュリティ対策を強化したのに、現場の不満や例外申請が増えている人

ルールを守らない社員に、何度注意しても行動が変わらず困っている人

情シス・セキュリティ部門と、現場部門の対立を減らしたい人

安全性と利便性のどちらを優先すべきか、判断に迷っている人

ゼロトラスト、SASE、端末認証、生成AIなどの導入を「使われる仕組み」まで設計したい人

プロローグ

正直に言う。

私は昔、セキュリティルールを守らない人を見ると、腹を立てていた。

なぜ、決められた手順を使わないのか。

なぜ、承認されていないツールを使うのか。

なぜ、わざわざ危険な方法を選ぶのか。

規程を読めば、書いてある。

研修でも、説明した。

それなのに、現場は抜け道を探す。

個人のクラウドストレージへファイルを置く。

自分のスマートフォンへデータを送る。

パスワードをメモに書く。

承認されていない生成AIへ、業務情報を入力する。

私は思っていた。

「セキュリティ意識が低い」

「危機感が足りない」

「もっと教育しなければならない」

だが、あるプロジェクトで、考えが変わった。

新しいセキュリティ対策を導入した直後だった。

技術的には、以前より安全になった。

認証を増やした。

アクセスできる端末を制限した。

ファイルを送る手順も厳格にした。

ログも残るようにした。

設計書だけを見れば、間違いなく強くなっていた。

ところが、一か月後。

現場へのヒアリングで、こんな声が出てきた。

「急ぎのときだけ、別の方法を使っています」

「正式な手順だと、今日中に終わらないんです」

「本当はいけないと思っています。でも、お客様を待たせられないので」

その瞬間、私は気づいた。

現場は、セキュリティを破りたかったのではない。

仕事を終わらせたかったのだ。

問題は、人の意識だけではなかった。

安全な道より、危険な抜け道のほうが、仕事を進めやすい構造になっていた。

第一章　正規ルートを使うと、仕事が終わらない

ある現場では、社外の関係者へ大容量ファイルを送るために、次の手順が必要だった。

送付先を申請する。

上長の承認をもらう。

セキュリティ担当の確認を待つ。

専用システムにファイルを登録する。

相手に受け取り方を説明する。

有効期限内にダウンロードされたか確認する。

通常業務なら、これでも対応できる。

しかし、夕方になって、顧客からこう言われたらどうだろう。

「明日の朝までに、この資料を送ってください」

担当者の頭に、二つの選択肢が浮かぶ。

一つは、正式な手順を守り、間に合わない可能性を受け入れること。

もう一つは、使い慣れた別のツールで、今すぐ送ること。

将来起きるかもしれない情報漏洩と、目の前で確実に起きる納期遅延。

人は、どちらを重く感じるだろう。

多くの場合、目の前の損失である。

これは単純なモラルの問題ではない。

行動経済学では、人が将来の利益や損失よりも、目の前の利益や負担を強く評価しやすい傾向を「現在バイアス」と呼ぶ。

情報漏洩は、将来起きるかもしれない。

上司や顧客からの催促は、今すぐやってくる。

だから、現場は目の前の仕事を終わらせる方法を選ぶ。

セキュリティルールを知らないからではない。

知っていても、現在の負担のほうが大きく見えるのだ。

第二章　ボタンを一つ増やすことは、現場では「一つ」ではない

セキュリティ部門から見ると、小さな変更に見えることがある。

認証を一回追加する。

申請項目を一つ増やす。

警告画面を一枚表示する。

上長承認を追加する。

「安全のためだから、この程度は仕方がない」

そう考える。

だが、現場で一日に何十回も操作する人にとって、その「一つ」は、一つではない。

一回二十秒の追加操作でも、一日三十回なら十分になる。

認証に失敗する。

承認者が会議中で止まる。

警告文の意味が分からず、毎回読む。

通信状態によって、画面が戻る。

こうした小さな摩擦が積み重なる。

一つひとつは我慢できる。

しかし、一定の水準を超えたところで、人は別の経路を探し始める。

NISTは、人間中心のサイバーセキュリティ研究において、使いにくいセキュリティの仕組みが、利用者の誤り、いら立ち、回避行動につながり得ると説明している。認証に関する最新のガイダンスでも、使いにくさから生まれる対処行動や想定外の回避策が、セキュリティ統制の効果を下げる可能性が指摘されている。

つまり、利便性は、セキュリティの敵ではない。

使いやすさそのものが、セキュリティ統制を機能させるための条件なのだ。

第三章　警告を増やすほど、警告が見えなくなる

危険を減らすために、警告を増やす。

一見、正しい対策に見える。

しかし、あらゆる操作で警告を出すと、人は内容を読まなくなる。

「この操作にはリスクがあります」

「外部サイトへ接続します」

「機密情報が含まれていないことを確認してください」

「本当に実行しますか」

最初は読む。

二回目も読む。

しかし、毎日何度も表示されると、次第に「OKを押す画面」として処理される。

本当に危険な場面でも、反射的に閉じるようになる。

これは、認知能力が低いからではない。

限られた注意力を、本来の仕事へ振り向けているからだ。

人間の注意力には限界がある。

判断を何度も求められると、次第に考えることをやめる。

NISTの研究では、セキュリティ上の判断を繰り返し求められることで生じる「セキュリティ疲労」が、無力感や危険な行動につながり得ることが示されている。

つまり、警告を増やすことは、必ずしも安全を増やさない。

重要度の低い警告が、本当に重要な警告から注意力を奪うこともある。

セキュリティ対策は、ルールの総量ではなく、現場に要求する判断回数まで含めて設計しなければならない。

第四章　「ルールを破った人」を探しても、構造は変わらない

セキュリティ事故や違反が発覚すると、組織は原因を探す。

誰がやったのか。

なぜ確認しなかったのか。

研修を受けていたのか。

本人は反省しているのか。

もちろん、重大な故意や不正があれば、個人の責任を明確にしなければならない。

しかし、通常業務の中で同じような回避行動が繰り返されているなら、個人だけを見ても問題は解決しない。

一人が私物端末を使った。

その人を注意した。

翌月、別の人が同じことをした。

また注意した。

この状態は、「問題のある人が次々に現れた」のではない。

正規ルートで処理できない業務が、そのまま残っている可能性が高い。

人を入れ替えても、同じ構造の中では、同じ行動が再生産される。

見るべきなのは、違反者の性格だけではない。

違反が起きた直前に、どのような業務上の圧力があったのか。

正規手順では、何分、何時間、何日かかったのか。

承認は、どこで止まったのか。

安全な代替手段は、すぐ見つけられたのか。

ルールを守ることで、本人にどのような不利益が発生したのか。

そこまで見て、初めて構造が分かる。

第五章　そういうことだったのか——正規ルートが「険しい山道」になっていた

ここで、一つの比喩を置きたい。

山の中に、二本の道がある。

一つは、安全な正規ルート。

もう一つは、崖沿いを通る危険な近道。

当然、管理者は正規ルートを使ってほしい。

そこで、危険な近道に「通行禁止」の看板を立てる。

しかし、正規ルートには問題がある。

入口が分かりにくい。

何度もゲートを通らなければならない。

通行許可を取るのに半日かかる。

荷物を持っている人には歩きにくい。

夕方になると閉鎖される。

一方、危険な近道は、すぐ見つかる。

許可もいらない。

短時間で目的地に着く。

この状態で「必ず正規ルートを歩いてください」と研修を繰り返したら、どうなるだろう。

何人かは守る。

慎重な人は、時間をかけて正規ルートを歩く。

しかし、急いでいる人は近道を使う。

一度近道を使って問題が起きなければ、次も使う。

やがて、その道は踏み固められる。

後から来た人も、「みんなが使っているから」と通り始める。

抜け道は、ルールへの反抗から生まれたのではない。

正規ルートの摩擦が、危険な道を育てていたのだ。

そういうことだったのか、と私は思った。

現場へ必要だったのは、もう一枚の禁止看板ではなかった。

安全な道を、最も短く、最も分かりやすい道へ変えることだった。

第六章　安全な方法を「デフォルト」にする

人は、毎回すべての選択肢を比較しているわけではない。

最初から選ばれているもの。

普段から使っているもの。

周囲の人も使っているもの。

変更に手間がかからないもの。

そうした選択肢を、そのまま使う傾向がある。

これが、デフォルト効果である。

この性質を無視すると、セキュリティは個人の注意力に依存する。

機密情報を送るたびに、社員自身が適切なツールを探す。

生成AIを使うたびに、入力してよい情報か判断する。

システムへ接続するたびに、認証方式を選ぶ。

毎回、正解を選んでもらう。

これでは、いつか間違える。

逆に、安全な方法を初期状態にできれば、注意力に頼る場面を減らせる。

会社が承認したファイル共有サービスを、業務端末からすぐ使えるようにする。

機密区分に応じて、送信や共有の可否を自動判定する。

社内で利用できる生成AIを、最初から業務メニューに置く。

危険度の高い操作だけ、追加認証や承認を求める。

不要な選択肢を、利用者に見せない。

CISAが推進するSecure by Design／Secure by Defaultも、安全確保の負担を利用者だけに背負わせず、安全な設定を初期状態に組み込む考え方を重視している。

「注意して使ってください」は、設計ではない。

安全な選択肢が、最初から選ばれやすくなっていること。

そこまでつくって、初めて運用設計になる。

第七章　セキュリティと利便性は、反対側にあるのか

セキュリティと利便性は、トレードオフだと言われる。

安全にすれば不便になる。

便利にすれば危険になる。

確かに、その関係が避けられない場面はある。

だが、すべてを二者択一にすると、設計を止めてしまう。

本当に確認すべきなのは、

「誰の、どの操作に、どれだけの摩擦を置くのか」

である。

すべての社員に、すべての操作で、同じ強さの統制をかける必要はない。

公開情報を見るだけの操作。

社内情報を扱う操作。

個人情報や機密情報を外部へ送る操作。

管理者権限で設定を変更する操作。

危険度は違う。

危険度が違うのに、すべてへ同じ重さの認証や承認を置けば、日常業務に過剰な摩擦が生まれる。

そして、現場は抜け道を探す。

必要なのは、セキュリティを弱くすることではない。

リスクの高い場所へ、強い統制を集中させることだ。

低リスクの操作は、軽く、速くする。

高リスクの操作は、止める、確認する、記録する。

例外が必要な業務には、正式な例外ルートを用意する。

一律に厳しくするのではなく、リスクに応じて摩擦を配分する。

これは、セキュリティと利便性の妥協ではない。

限られた注意力と統制力を、守るべき場所へ集中させる設計である。

第八章　現場が抜け道を使ったときに確認する五つの問い

抜け道が見つかったとき、最初から「ルール違反」として閉じると、現場は次の抜け道を隠すようになる。

まず、次の五つを確認する。

一　何を終わらせようとしていたのか

本人が達成しようとしていた業務目的を確認する。

「ファイルを私物端末へ送った」ではなく、

「外出先から、顧客へ期限内に回答しようとしていた」

まで見る。

違反行為と業務目的を分ける。

二　正規ルートでは、どこで止まったのか

操作が分からなかったのか。

権限がなかったのか。

承認者が不在だったのか。

処理時間が長かったのか。

相手側が正式な方式を使えなかったのか。

「使いにくい」という言葉を、具体的な摩擦へ分解する。

三　抜け道は、どれだけ速かったのか

正規ルートが三十分、抜け道が二分なら、現場が抜け道へ流れる理由がある。

感覚ではなく、時間と操作数を測る。

四　同じ状況は、他の人にも起きるか

一人だけの特殊事情なのか。

同じ業務を担当する人なら、誰でも起こり得るのか。

再現性があるなら、個人の問題ではなく、業務設計の問題として扱う。

五　安全な代替経路を、標準化できないか

抜け道を禁止するだけで終わらせない。

正規ルートの短縮。

事前承認。

自動判定。

代理承認。

緊急時の例外申請。

相手先向けの簡単な手順。

安全に仕事を終わらせる経路をつくる。

この五つを確認すると、違反の裏側にある構造が見え始める。

第九章　セキュリティ摩擦を可視化する

セキュリティ対策を導入したら、インシデント件数だけを見てはいけない。

次の数字も見る必要がある。

一つの業務を終えるまでの操作数。

追加認証を求められる回数。

承認完了までの時間。

差し戻し率。

ヘルプデスクへの問い合わせ数。

例外申請の件数。

非承認ツールの利用状況。

業務が止まった時間。

これらは、単なる利便性の指標ではない。

抜け道が発生する前兆である。

特定の申請だけ問い合わせが多い。

ある時間帯だけ、非承認ツールの利用が増える。

同じ理由の例外申請が続く。

それは、現場がルールへ反抗しているのではない。

正規ルートに、設計上の欠陥があることを知らせている可能性がある。

私は、これを「セキュリティ摩擦台帳」として記録することを勧めたい。

記録する項目は、難しくない。

対象業務。

守る情報。

正規手順。

所要時間。

現場が感じる負担。

発生している回避行動。

回避した場合のリスク。

改善案。

改善後の測定結果。

セキュリティ部門だけで作らない。

現場、情シス、業務責任者、必要に応じて法務や監査も入り、一緒に見る。

抜け道を密告する台帳ではない。

抜け道が生まれる前に、摩擦を見つける台帳である。

第十章　研修より先に、道を直す

誤解のないように言えば、セキュリティ教育は必要だ。

フィッシング。

パスワード。

情報の持ち出し。

生成AIへの入力。

インシデント報告。

知らなければ判断できないことはある。

しかし、教育だけで解決しようとすると限界がある。

正式な手順に二時間かかるのに、

「ルールを守りましょう」

と伝えても、現場の摩擦は消えない。

毎日何度も認証を求めながら、

「認証疲れに注意しましょう」

と言っても、構造は変わらない。

承認されたAIが使いにくいまま、

「未承認AIは禁止です」

と伝えれば、利用は見えない場所へ移る。

研修で人を変える前に、道を直す。

安全な道を短くする。

入口を分かりやすくする。

危険な場所だけ、確実に止める。

間違えても、すぐ戻れるようにする。

それでも必要な知識を、必要な場面で渡す。

この順番が大切である。

第十一章　優しいセキュリティは、弱いセキュリティではない

「現場に配慮する」と言うと、ルールを緩くすることだと誤解される。

違う。

優しいセキュリティとは、何でも許可することではない。

人間が間違える前提で、被害が大きくならない構造をつくることだ。

危険な操作を、最初からできなくする。

必要な権限だけを渡す。

異常があれば検知する。

間違えたとき、早く報告できるようにする。

報告した人を、最初から犯人として扱わない。

回復手順を用意する。

一人の注意力に、組織全体の安全を預けない。

優しいまま、壊れない。

それは、人に甘くすることではない。

人を責めなくても守れるほど、構造を強くすることである。

エピローグ

以前の私は、ルールを守らない人に、もっと注意を求めていた。

研修を増やす。

警告を増やす。

承認を増やす。

記録を増やす。

増やすほど、安全になると思っていた。

しかし、現場で起きていたのは逆だった。

守るための手順が増えすぎて、守れない業務が生まれていた。

判断を求めすぎて、人が考えなくなっていた。

安全な道が遠すぎて、危険な近道が選ばれていた。

抜け道は、現場の敵意ではなかった。

仕事を止めないための、現場なりの適応だった。

もちろん、危険な行為を放置していいわけではない。

だが、禁止するだけでは、別の抜け道が生まれる。

大切なのは、抜け道を塞ぐことと同時に、正規ルートを歩ける道へ変えることだ。

安全な方法が、一番見つけやすい。

一番速い。

一番迷わない。

特別な注意力を使わなくても、自然に選べる。

そこまで設計できたとき、セキュリティは現場の障害ではなくなる。

セキュリティと利便性を、対立させなくていい。

見るべきなのは、人の意識の低さではない。

安全な方法を選びにくくしている、意思決定の構造である。

人を責めるより、構造を見る。

抜け道を叱るより、正規の道を歩きやすくする。

それが、二十年PMとして現場を見てきた私が考える、これからのセキュリティ設計である。

さて。

あなたの組織で、現場が使っている「抜け道」は何だろう。

そして、その抜け道より、正規ルートは本当に歩きやすくできているだろうか。

本記事を含む一連の記事は、書籍化を視野に入れながら執筆を続けている。

人を責めるより、構造を見る。

今日も少し、優しくなれる。

参考資料

NIST｜Human-Centered Cybersecurity
https://csrc.nist.gov/Projects/human-centered-cybersecurity

NIST｜Security Fatigue
https://www.nist.gov/publications/security-fatigue

NIST SP 800-63B｜Customer Experience Considerations
https://pages.nist.gov/800-63-4/sp800-63b/customer/

CISA｜Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default
https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf