こんにちは
最近、ソフトウェアの脆弱性に関する報告を目にする機会がとても増えています。
2026年10月には、PHP の脆弱性に関する報告で世界中の多くのウェブサイトが大きな影響を受ける自体が発生したり、Node.js や Linux の脆弱性も非常に報告されています。
▼ php2shell の脆弱性に関する報告
▼ Node.js の脆弱性に関する報告
▼ Linux の脆弱性に関する報告
特に最近では、AI を活用したサイバー攻撃が注目されており、中国の AI 企業によるオープンウェイトモデルの公開などを背景に、高性能な AI を比較的低コストで利用できる環境が整いつつあります。 攻撃者が AI を利用して脆弱性の調査や攻撃手法の検討を効率化できるようになれば、これまで以上に攻撃の規模や速度が拡大していく可能性は十分に考えられます。
こうした状況を踏まえると、サイバーセキュリティを取り巻く環境がまた一段階変化していることを実感します。
私自身も普段の業務でセキュリティに関することをより意識する機会が多くなり、改めてセキュリティを守ることがソフトウェアエンジニアの専門性を発揮するフィールドの一つとして、より重要度が増してきたのかなと思います。
ここで、企業が自社システムのセキュリティを守るために、本当に必要はことはなんでしょうか。
セキュリティに精通した専門人材や、脆弱性を検知するための人的・システム的な仕組みは当然重要なのですが、 私はそれ以上に、自社システムを継続的に、そして素早く変更できるような開発体制を持っていることが重要だと考えています。
攻撃側と防御側の非対称性について
サイバー攻撃を仕掛ける攻撃者は、攻撃対象のシステムの脆弱性を見つけることができれば、攻撃を大量・並列に仕掛けることができる一方で、 防御側は、攻撃者が見つけた脆弱性を修正するためには、システムの変更や修正を行う必要があります。
システムの変更や修正を行うためには、特に大規模な組織であればあるほど、以下のようなプロセスが必要となることが多いです：
- 脆弱性の調査
- 影響範囲の確認
- 修正方法の検討 & 実施
- 既存機能に問題がないかの確認
- リリース後に問題がないかの確認
また、これらを行う一つ一つに部署間の承認プロセスが必要となる場合も多く、たった一つのセキュリティパッチを適用するだけでも、多くの調整が必要になってしまう実感があります。
開発組織のアジリティが必要
最も理想的な状態は、自社の開発チームがオーナーシップを持ち、影響範囲の調査や必要な修正を自律的に行い、自動テストを通して素早くリリースする、という一連の対応が連続的にできる体制が作られていることです。 そのような体制を作るためには、何が必要なのでしょうか？
自分はこれまでの経験から、以下のようなことが重要だと考えています：
- 各種自動テストの整備
- ci/cd パイプラインの整備
- 内部品質を十分に満たしたナレッジの蓄積
- 開発チームの自律性を高めるための組織文化の醸成
順に一つずつ見ていきましょう。
各種自動テストの整備
まず、最も重要だと考えているのが、各種自動テストの整備です。
システムの規模が大きければ大きいほど、システムの変更や修正を行う際に、既存機能に問題がないかを確認するためのテストが必要です。 しかし、自動テストが十分に整備されていないシステムでは、ライブラリのバージョンを更新するだけでも、既存の機能に問題がないかを人手で確認する必要が出てきてしまいます。
一方で、ユニットテストやインテグレーションテスト、E2E テストなどが適切に整備されていれば、変更による影響を自動的に検証することができます。
これが一番効いてくるのが、Dependabot や Renovate などの依存ライブラリの自動更新ツールを利用したときです。
これらのツールを利用すれば、依存パッケージの更新を自動的に Pull Request として作成してくれるのですが、更新後の動作確認を毎回人手で行う必要があるのであれば、そこが大きなボトルネックとなってしまい、作ったは良いもののメンテナンスが十分にされないシステムとなる可能性が高いです。 適切に自動テストが整備されている場合、自動テストが通過すれば既存機能に問題がないことは確認できるため、セキュリティパッチの適用や依存ライブラリの更新を素早く行うことができます。
また、自動テストは単に存在していれば良い、という訳ではなく、適切にメンテナンスされていることが重要です。
例えば、モックばかりを利用してテストを実装していた場合、実際の実装とモックの振る舞いが乖離してしまい、テストは成功しているにもかかわらず、本番環境では不具合が発生する、自動テストが使い物にならない、といったケースも十分にあり得ます。 また、仕様変更に合わせてテストコードが正しくメンテナンスされていなければ、現在のシステムの振る舞いを正しく検証できなくなってしまいます。
自動テストは単なる品質確認の手段ではなく、システムの仕様を表現する「動作するドキュメント」としての役割を持っている、と捉えることが重要だと思います。
そうした自動テストの存在が、開発チームに対して「安心してシステムを変更できる」という安心感を与え、セキュリティ対応のアジリティを高めることに繋がると思います。
自動テストの書き方や考え方については、以下の書籍が分かりやすいので、もし興味あれば参照してください
CI/CD パイプラインの整備
次に重要なのが、CI/CD パイプラインの整備です。
自動テストが十分に実装されていたとしても、それを開発者が毎回手動で実行する必要があったり、リリース作業に多くの手続きが必要だったりする場合、十分なアジリティを確保することはできません。
CIが成功していることが確認できれば素早く本番リリースのプロセスを迅速に進められるようになりますし、デプロイ手順についても自動化しておくことにより、素早い対応が可能になります。
単純にデプロイを自動化するだけでなく、段階的なリリースやロールバックの仕組み、リリース後のモニタリングなども含めて、日々の開発活動の延長線上で実施できる状態にしておくことが寛容だと思います。
最近は MCP や API と AI エージェントが協同することで、一昔前では難しかった自動化ができるようになっています。 このあたりについても適切に整備されていることが、セキュリティを守っていくためにも当然重要になると思います。
内部品質を十分に満たしたナレッジの蓄積
自動テストや CI/CD について触れてきましたが、これらの仕組みを有効に機能させるためには、ソフトウェアの内部品質が十分に確保されている必要があります。
例えば、モジュール間の依存関係が複雑に絡み合って、一つの機能を変更するだけでシステム全体に影響が及んでしまうようなスパゲッティコードを想像してみてください。 こうしたシステムでは、そもそも自動テストを実装すること自体が難しくなってしまいます。 特定の機能だけを独立して検証することが難しかったり、テストを実行するために大量のモックを準備する必要があったりします。
一方で、適切にモジュール化され、関心事が分離されたソフトウェアであれば、変更の影響範囲を把握しやすく、個々の責務に応じた自動テストを組みやすくなります。
自分自身の実務経験でも、行数が大きく依存関係が複雑な関数やクラスは、有効な自動テストを書くことが難しいです。 自動テストが仕様を表現する動くドキュメントとして有効に機能させるためには、SOLID原則を意識した実装に対して自動テストを実装することが非常に有効です。
こうした変更容易性の高いソフトウェアを構築するためには、適切な設計を日頃から意識的に行っていくとともに、継続的なリファクタリングを行っていくことが重要です。 変更容易性の高いソフトウェアは機能開発のアジリティを高めるのもありますが、セキュリティ面でも当然、変化に素早く追随して安全性を担保し続けていくために有効な手法です。
そして、もう一つ重要なのが、システムに関するナレッジの蓄積です。
アーキテクチャや設計上の意思決定、システムの運用に必要な知識を、組織として継続的に蓄積していくことが重要です。 最近は AI エージェントによる実装が開発のベースとなってきたと思いますが、AI が実装判断をする上でも、AI が参照できる形で整理しながら蓄積していくことが重要です。 AI に適切にセキュリティを担保させていくためにも、またシステム全体がより素早くセキュリティの穴を塞げるようにするためにも、ナレッジの蓄積という観点が非常に大事なように思います。
開発チームの自律性を高めるための組織文化の醸成
最後に、組織の話です
ここまで言及してきた技術的基盤が整っていたとしても、開発チームが自律的に行動できるチームになっていなければ、その効果を十分に発揮することはできないと思います。
例えば、重大な脆弱性が発見された際に、開発チームが自ら影響範囲を調査して、必要な対応を判断して、修正からリリースまで進められる体制になっているでしょうか。 それとも、上長や他部署からの指示がなければ行動できない状態になっているでしょうか？
当然前者のような開発組織の方が良いですよね、私は日々の仕事を通して、システム・組織・人の3つを同時に変えていくことが必要だと言っていますが、当然ながら組織をいかにクリーンな体制にしていくか、というのが非常に重要だと思います。
もちろん、セキュリティ対応には一定のリスク評価や管理が必要ですし、全ての判断を開発チームが独断で行えば良いという訳ではありません。 ただ、あらかじめ権限や責任の範囲を明確にし、一定の条件を満たす変更については開発チームが自律的に判断して実行できる仕組みを整えることはできるはずです。
そのためには、組織のサイロ化を解消し、コミュニケーションラインをできる限り少なくすることが重要だと思います。
開発、運用、セキュリティ、事業部門がそれぞれ独立していて、何かを変更するたびに複数の部署を横断して調整しなければならない状態では、対応速度は遅くなると言わざるを得ません。
特に開発を外部のベンダーに大きく依存している場合に、この問題がさらに複雑になると思います。
外注そのものが悪いという話ではないのですが、技術的な知識を十分に持たない担当者がベンダーコントロールを行っている場合、ソフトウェアの内部品質をどこまで適切に評価できてますでしょうか。 外注を行う場合はベンダーに対して自動テストの整備や CI/CD の構築を適切に要求し、内部品質を継続的に評価できる体制が整っていれば、外部の技術力も活用しながら十分な開発のアジリティを確保することは可能だと思うのですが、 その観点が抜けて、システムの開発費用をいかに安く抑えるかという点だけで判断してしまうと、こうした内部品質への投資は削減対象になりやすいです。
ライブラリを更新するたびに人手で QA を行う必要があったり、軽微な修正であっても大規模リリース調整が必要になったりするような環境だと、重大な脆弱性が発生されても、迅速にパッチを適用できない状態になってしまいます。
こうした問題を考えると、自社に一定の内製開発体制を構築して、システムに対する一定のオーナーシップを自社の開発チームが持つことは大事だろうと思います。
AI によってシステムのセキュリティが重要度を増しているからこそ、開発サイクル全体の体制にもっと目を向けて正常化していく必要があるように思います。
おわりに
こうして見ていくと、AI 時代においてもモダンなソフトウェア開発組織を構築するために重要とされている概念が、継続して重要であることに気づくと思います。
軽微な機能変更すら数週間かかるような組織が、重大な脆弱性が発見された時だけ突然スピーディに対応できるとは考えにくいのではないでしょうか。
もちろん、セキュリティに精通した専門人材や、脆弱性を検知するための仕組みは必要です。 ただ、どれだけ優れたセキュリティ人材が脆弱性を発見し、適切な対策を提案できたとしても、それを実際のシステムに適用できなければ本質的にはあまり解決には向かっていかないのかなと思います。
セキュリティ上の問題を発見する能力と、それを解決するためにシステムを変更できる能力の両方が伴うことが必要に思います。
最近の脆弱性報告ラッシュを見て、自分が考えたことを整理してみました。こういった世界に向けて、少しでも改善できるように仕事をしていかなとですね。