企業のセキュリティといえば、少し前まで「SOCを厚くする」「EDRを入れる」「怪しい通信を止める」といった話が画面の中心に来やすかったと思います。もちろん、いまもそれらは重要です。ただ、システム開発や運用の現場にいるIT技術者ほど、もうそれだけでは回らない感覚を持っている人が増えているはずです。
クラウドが前提になり、SaaSが増え、ソフトウェアのサプライチェーンが複雑になり、生成AIまで業務に入り始めた今、企業のリスクは単純な「外からの攻撃」だけでは片付きません。脆弱性管理の遅れ、設定不備、委託先の事故、製品の設計段階での欠陥、従業員の判断ミス、AI利用時の情報漏えい——入口が増えたぶん、「検知して叩く」運用だけに寄せるほど、現場と統制側の両方が疲れる構図になりやすいのです。
そこで多くの企業で進んでいるのは、セキュリティを「防御技術の話」に閉じず、経営・開発・運用・人材育成まで含めた継続的な仕組みとして捉え直す方向です。重要なのは、単にセキュリティを強く見せることではなく、変化の激しい環境でも事業を止めずに進められる状態をどう設計するか、という問いに置き換わりつつあります。
なぜ難しくなったのか——境界が溶けたあとの「守る対象」
オンプレ中心の時代は、社内ネットワークと社外ネットワークの境界をどう守るかが議論の主役でした。いまはクラウド、リモートアクセス、モバイル端末、API連携、委託先環境、海外拠点、IoT機器まで含めて守る前提になり、守るべき対象はシステムだけでなく、データ、ID、ソフトウェアのサプライチェーン、顧客向け製品そのものまで広がっています。多くの企業で起きているのは、攻撃の高度化そのもの以上に、守る対象の広がりと責任の分散です。
この状況で「問題が起きたら検知して対処する」「ルールを厳しくして統制する」「セキュリティ部門が全部チェックする」という従来型の組み合わせだけを続けると、どこかで破綻しやすくなります。理由は単純で、現場のスピードに承認やレビューが追いつかず、結果として形だけの統制になりやすいからです。開発現場がセキュリティを「面倒な壁」と感じ、セキュリティ側が現場を危なっかしい存在と見る——そうなると協力ではなく消耗が始まります。多くの企業が今まさに変えようとしているのは、まさにこの力学のほうだと言えます。
国際的な規制や製品責任の議論も、同じ方向の圧力になっています。たとえばEUのサイバーレジリエンス法（Cyber Resilience Act）のような文脈では、出荷後のパッチ供給だけでなく、設計から保守までを通したセキュリティが問われます。筆者は別稿で、製品セキュリティとPSIRTを事業にどう実装するかを整理しています（公開記事は 筆者のQiita記事一覧 からタイトル「製品セキュリティは情シス業務で終わらない——CRA時代にPSIRTを事業実装する」で辿れます）。
「モグラ叩き」に似た運用から、攻撃面を減らす戦略へ
IT技術者にとってわかりやすい比喩にすると、従来型のセキュリティ運用は、しばしば障害対応に追われる運用チームに似ています。アラートが上がり、調査し、封じ込め、再発防止を書く。しかし次のアラートが来る。このループだけで回していると、組織は常にモグラ叩きになり、根本原因の解消に投資する余力が残りにくくなります。監視やインシデント対応は必要ですが、それだけに比重が寄るほど、疲弊と技術的負債が積み上がるのです。
そこで多くの企業が比重を移し始めているのが、事後対応よりも事前抑止です。不要な公開資産を減らす。IDと権限を最小化する。脆弱性対応の遅延を可視化する。設定不備を継続的に検出する。開発段階でセキュリティ要件を組み込む。調達や委託の段階でサプライヤー要件を明確化する。これらは一見バラバラに見えますが、共通項は**「起きたあとに強くなる」だけではなく、そもそも攻撃される面積を減らす**という戦略のずらし方です。ネットワーク、クラウド、アプリ、ID管理、製品開発のすべてに関わる話であり、IT部門だけでは完結しません。
成熟度を段階的に上げるための枠組みとして、国際的にはNIST Cybersecurity Framework 2.0のように「Govern（統治）」を含めた全体像が示されており、ソフトウェア開発に特化した整理としてはOWASP SAMM（Software Assurance Maturity Model）のようなモデルが参照されがちです。どちらも「ツールを足す」より先に、プロセスと責任の置き方を言語化する用途で効きます。
ライフサイクルに埋め込む——セキュリティを非機能要件として扱う
多くの企業が目指している形は、セキュリティを単発の監査や点検ではなく、ライフサイクル全体の活動として回すことです。システムであれば、企画でリスクを考え、設計で要件に落とし、実装でチェックし、リリース前に確認し、運用中に監視と改善を続け、障害や事故の学びを次の開発へ返す。製品やサービスでも同様で、リリース時点の安全だけではなく、運用後の脆弱性対応、パッチ供給、サポート体制、サプライチェーンまで含めて守り続ける必要があります。
この発想は、品質保証やSREの考え方にかなり近いです。セキュリティを後工程で「チェックされるもの」から、設計・実装・運用に組み込まれた非機能要件へ位置づけ直す。IT技術者の視点では、単なる統制強化というより、あとから止められないために、最初から作り方を変える話だと捉えると腹落ちしやすいと思います。
エージェント型のAIが業務に入るほど、「誰がログインしたか」だけでは説明が足りない場面が増えます。筆者は別稿で、エージェンティックAI時代にセキュリティが防御から統制へ寄っていく論点を整理しました（エージェンティックAI時代のセキュリティは防御から統制へ）。本稿の「ライフサイクルに埋め込む」とは、統制の話を単発のルールではなく、変更管理と観測可能性の設計として続ける、という意味でもつながります。
一律の禁止では進まない——可視化と例外管理の設計
ここで多くの企業がぶつかるのが、セキュリティとスピードの衝突です。現場はクラウドを使いたい。新しいSaaSを試したい。データ分析や生成AIも活用したい。一方で統制側は事故を恐れて止めたくなる。この対立を「現場が無責任」「統制側が保守的」とラベル貼りしても、設計は前に進みません。本質は、一律の厳格ルールでは、業務ごとに違うリスクを扱い切れないことにあります。
だから最近の企業では、単純な禁止だけに頼らず、リスクを見える化しながら柔軟にコントロールする方向へ進んでいます。重要資産ごとにリスクレベルを分ける。脆弱性や対応状況をダッシュボードで追えるようにする。例外申請をゼロにするのではなく、根拠付きで残す。部門ごとに成熟度が違う前提で統制を設計する。AI利用も全面禁止ではなく、利用条件・禁止事項・レビュー対象を分ける。言い換えると、ガチガチの統制から状況適応型のガバナンスへの移行です。現場に裁量を渡す代わりに状態を見えるようにし、逸脱したら早く気づけるようにする。この設計がないと、DXもAI活用も掛け声だけで止まりがちになります。
生成AIのリスクは、IPAの「情報セキュリティ10大脅威」でも組織向けに顕在化してきています（「情報セキュリティ10大脅威 2026」を決定（IPAプレスリリース））。AIだけを特別扱いしすぎず、結局は既存の情報セキュリティ、法務、品質保証、監査と接続して整理するほうが回りやすい、というのが現場の感触に近いと思います。
足りないのは専門家「だけ」ではない——職種ごとの「セキュリティが足された人材」
人材の話になると、つい「セキュリティ人材が足りない」で終わりがちです。ただ、現実の企業で本当に不足しがちなのは、純粋な専門家だけではありません。開発、運用、インフラ、クラウド、製品企画、調達、品質保証など、それぞれの持ち場でセキュリティを理解して判断できる人が薄いと、どれだけ中央の専門チームを増やしてもボトルネックが残ります。
開発者であれば、認証認可の基本、安全な実装パターン、依存ライブラリのリスク、秘密情報の扱い、脆弱性報告を他人事にしない姿勢。運用担当であれば、権限管理の設計、ログの意味の判断、設定変更のリスク見積もり、復旧と証跡保全の優先順位。マネージャーであれば、セキュリティを納期の敵ではなく品質の一部として扱うこと、リスクを言語化して経営判断につなぐこと、インシデント報告を責めずに受け止めること。求められているのは一部のスーパースターではなく、各職種にセキュリティが足された人材です。この前提に立つと、研修の設計も評価の設計も変わってきます。
ランサムウェアのような侵害後の動き方は、別稿で「速度」と「復旧設計」に寄せて整理しています（2025年のセキュリティ最前線：ランサムウェア対策の完全ガイド：AI時代の攻撃から組織を守る実践的な方法）。本稿が扱うのはその手前で、入口を増やさない・広げないための組織と育成の話です。両方を分けて読むと、地図がつながります。
研修を回すだけでは育たない——役割・レベル・業務の三層
多くの企業が育成でつまずくパターンは、「全員に同じeラーニングを受けさせた」で終わることです。知識の配布にはなっても、実務能力の底上げにはつながりにくいのが普通です。効きやすい設計は、まず誰に何を求めるのかを役割ごとに分けること。次に、初学者に高度な脅威分析を求めないように、初級・中級・実践・統括のような段階を用意すること。最後に、研修を受けたかではなく、実際にレビューできたか、改善提案ができたか、インシデント対応で行動できたかを見ること、の三層です。
IT技術者にとって大事なのは、セキュリティ教育を別枠の「講義」から切り離さないことです。IaC、CI/CD、クラウド運用、障害対応、製品開発のワークフローのなかに、セキュリティの学びと実践を埋め込む。この形にしないと、現場の知識は定着しません。AIとセキュリティの整理図として三つの箱に分ける話は、別稿で扱っています（AIセキュリティは「三つの仕事」に分けると腹落ちする——守る・律する・戦わせる）。育成設計でも同様に、いま話しているのはどの箱かを先に合わせると、期待値がズレにくくなります。
強い組織を作るのは、ツールだけではなく「報告できる空気」
セキュリティの成熟度を左右する要因として、意外に見落とされがちなのが心理的安全性です。どれほど高度な仕組みを入れても、現場が「報告したら怒られる」「ミスを言うと評価が下がる」「事故は隠したほうが得だ」と感じていれば、組織は脆くなります。逆に強い企業は、インシデントやヒヤリハットを早く上げられます。小さな異常の段階で相談できるから、大事故になる前に止められるのです。
セキュリティ部門の役割も、ここで変わります。警察のように監視と摘発だけを強調すると、現場から見て「見つかったら困る部署」になりやすく、重要な情報ほど上がってこなくなります。統制や監査は必要ですが、その前に一緒に解く支援部門として機能できるかが、長期的な防御力に効いてきます。チームの効果性と心理的安全性の基礎研究として広く参照される整理は、re:Work（Google）のチームの効果性に関するガイドにもまとまっています。セキュリティ文脈では直訳の話ではありませんが、「報告が早い組織ほど復旧が速い」という現場感覚と接続しやすいと思います。
IT技術者が今日から意識したい四つの軸
この流れのなかで、IT技術者に求められる役割は以前より大きくなっています。単に実装する人、運用する人ではなく、リスクとスピードの両方を理解して設計できる人が価値を持ちます。意識の置き場所は、次の四つに集約できます。
第一に、セキュリティを後付けではなく設計要件として扱うことです。認証、権限、ログ、秘密情報、依存関係、障害時の復旧まで、最初から同じテーブルに乗せる。第二に、検知より前に攻撃面を減らす発想を持つことです。不要な公開、不要な権限、放置された資産、曖昧な責任分界を減らす。第三に、自分の職種に必要なセキュリティを学ぶことです。全員が脅威ハンターになる必要はありませんが、自分の業務に関わるリスクは理解しておく。第四に、報告しやすい空気を壊さないことです。事故やミスを個人の責任だけに押し込める文化は、結局システムを弱くします。
問いを置き換える——「どれだけ厳しく守れるか」から「どれだけ進めるか」へ
これからの企業に必要なのは、セキュリティの理想論ではなく、現実の開発、運用、製品提供、サプライチェーン、AI活用のなかで、止めずに守るための仕組みです。事後対応中心から事前抑止へ比重をずらす。セキュリティをライフサイクルに埋め込む。一律統制だけに頼らず、可視化と例外管理を設計する。専門家だけでなく各職種の実務者を育てる。心理的安全性を含めた組織文化を整える。これらはセットで効きます。
セキュリティは、強い製品や強いインフラを作るための制約条件です。同時に、継続して事業を回すための設計能力でもあります。だからこそ今、多くの企業で問われているのは「どれだけ厳しく守れるか」ではなく、どれだけ現実に即して、守りながら前へ進めるかなのだと思います。関連テーマは 筆者のQiita記事一覧 から、タイトルで辿っていただくと、権限設計や製品セキュリティ、AI統制の別角度ともつなげやすくなります。
作成日: 2026年4月20日