今からでも間に合う？システム開発のセキュリティ対策の進め方

「話題の情報漏洩、うちのシステムは大丈夫だろうか」と不安を感じている方も多いのではないでしょうか。

2026年は、取引先や委託先へのサイバー攻撃が、自社の情報漏洩につながる事例も見られます。システムを発注する企業にも、委託先の管理を含めたセキュリティ対策が求められています。

すでに稼働しているシステムでも、今から対策を加えることは可能です。ただし、後から加えると費用がかさみやすい対策もあるため、進め方には工夫が必要です。

この記事では、既存システムに今からセキュリティ対策を加える進め方と、これから開発するシステムで工程ごとに対策を組み込む方法を、開発会社の視点から解説します。

発注前に開発会社へ確認しておきたいポイントもまとめているので、対策の第一歩として役立ててください。

今、システム開発でセキュリティ対策が求められている背景

ここ数年で、セキュリティ対策は「大企業だけの話」ではなくなりました。中小企業の発注担当者も知っておきたい、3つの変化を紹介します。

委託先や取引先を経由した情報漏洩が増えている

最近の情報漏洩では、攻撃の入り口が自社ではなく、委託先や取引先、保守の経路になっているケースが目立ちます。

2026年にも、システムの再委託先がランサムウェアの被害を受けて委託元の情報に漏洩のおそれが生じた事例や、病院の保守用VPNを経由して侵入された事例が報じられました。

開発の現場でよく見かけるのは、「保守のために用意した入り口」が、作った当時の設定のまま残っているケースです。

保守用の接続は普段使わないため点検の対象から漏れやすく、気づかないうちに侵入口になっていることがあります。

取引先からセキュリティ対策の証明を求められる流れがある

経済産業省は、企業のセキュリティ対策を見える化する「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」を、2026年度末に始める予定です。

対策状況は★の段階で示され、取引先の選定や契約の場面で活用される見込みです。

• ★3：すべての企業が最低限実装すべき対策の水準
• ★4：サプライチェーンを構成する企業が標準的に目指す水準
• ★5：より高度な対策が求められる企業の到達目標

制度の詳細は今後も更新される見込みですが、大手の取引先から一定の★を求められる可能性は十分にあります。

実務でも、取引先のセキュリティチェックシートで「ログを何日保存しているか」「管理画面に多要素認証があるか」など、システムの機能に関わる質問を受けるケースが増えています。

こうした項目は、社内ルールを整えるだけでは「対応済み」と答えられず、システム側に機能がなければ対応が難しい場合があります。

これから開発するシステムには、こうした質問に答えられる機能を最初から組み込んでおきましょう。

セキュリティの不備で開発会社の責任が問われた判例もある

セキュリティ対策の不備は、発注側と開発会社の間のトラブルにもつながります。

2014年には、SQLインジェクションと呼ばれる攻撃でカード情報が流出した事件で、必要な対策をしていなかった開発会社に損害賠償を命じる判決が出ました（東京地裁 平成26年1月23日判決）。

一方で、この判決では発注側にも一定の落ち度があったとして、賠償額が減らされています。

発注側が「当然やってくれているはず」と思っていた対策が、契約上は対象外だったというケースもあります。

対策の範囲を書面に残しておくことは、開発会社と発注側の双方を守ることにつながります。

稼働中のシステムに今からセキュリティ対策を加える進め方

すでに使っているシステムでも、対策が十分でないと気づいた時点から手を打つことはできます。費用をできるだけ抑えながら進めるための手順を紹介します。

脆弱性診断とソースコードの確認で弱点を洗い出す

外部に公開している画面であれば、ソースコードが手元になくても、外側からの脆弱性診断は受けられます。

一方で、見つかった弱点を根本から直すには、次のような資料が必要です。

• システムのソースコード
• 設計書などの資料
• OS・ミドルウェア・ライブラリのバージョンとサポート期限
• 保守を担当している会社と契約の内容

資料がそろっていないシステムでは、改修の前にプログラムを読み解く調査が必要になり、その分の費用と期間がかかります。

他社が開発したシステムでも、ソースコードがあれば別の開発会社が調査や改修を引き受けられる場合があります。反対に、ソースコードの所在が分からないまま時間がたつと、弱点が見つかっても直せない状態になるおそれがあります。

開発した会社と連絡が取りにくい場合も、まずはソースコードと資料の所在を確認することから始めましょう。

使っていない機能を止めて対策の対象を絞る

診断で見つかった弱点を一度にすべて直すのは、費用の面でも現実的ではありません。

開発会社として最初に提案することが多いのは、直す前に「使っていないものを止める」ことです。

止める・消す候補	よくある状態
使われていない画面や機能	過去のキャンペーン用ページや旧機能が公開されたまま
テスト用のページやデータ	開発時の確認用ページが本番環境に残っている
不要なアカウントやAPIキー	連携をやめた外部サービス用の認証情報が有効なまま

使われていない画面でも、公開されている限りは攻撃の入り口になります。

止めるだけで済むものは改修よりも費用がかからず、修正が必要な範囲そのものを減らせます。

そのうえで、外部に公開している画面や個人情報を扱う機能から順に修正を進めます。

サポートが終了したOSやソフトは修正版が提供されなくなるため、Windows Server 2016（2027年1月に延長サポート終了予定）のように期限が近いものは移行の計画も急ぎたいところです。

改修で対応するか作り直すかを判断する

対策を進めるなかで、改修だけでは対応しきれないケースも出てきます。

開発の現場で判断の分かれ目になりやすいのは、権限のチェックやデータベースへのアクセスが、共通の仕組みにまとまっているかどうかです。

共通の仕組みにまとまっていれば、その部分を直すだけで全画面に対策が行き渡るため、改修で対応しやすくなります。

反対に、画面ごとにばらばらに書かれている場合は、同じ修正を何十か所にも入れることになり、作り直しと費用が変わらないこともあります。使っているフレームワーク自体のサポートが終了していて、新しいバージョンに上げられない場合も同様です。

見た目が古いかどうかではなく、作りの中身で判断しないと、費用の見積もりを誤るおそれがあります。

セキュリティ対策を後付けするときに費用を抑えるポイント

後付けのセキュリティ対策は、進め方を工夫することで費用を抑えやすくなります。開発会社の視点から、押さえておきたい3つのポイントを紹介します。

緊急性を判断したうえで、計画的な改修をまとめる

セキュリティ対策の中には、後から加えやすいものと、データの持ち方や全画面の処理に関わるため改修範囲が広がりやすいものがあります。

範囲が広がりやすいのは、次のような対策です。

改修範囲が広がりやすい対策	後付けで必要になる作業
権限の設計	全画面とデータの取り出し方の見直し、幅広いテスト
パスワードの保存方式	保存方法の変更と、利用者へのパスワード再設定の案内
データの暗号化	既存データの変換作業と、移行中の停止時間の確保

こうした対策を単独で進めると、テストや停止の準備にかかる手間がそのまま費用に上乗せされます。

予定している機能追加やサーバーの入れ替えと同じタイミングで進めれば、テストや停止の時間をまとめられます。

改修の予定がある場合は、セキュリティ対策もあわせて開発会社に相談しておきましょう。

セキュリティ製品とプログラムの修正を使い分ける

WAF（Webアプリケーションを守るファイアウォール）などのセキュリティ製品は、プログラムを直さずに導入できるため、比較的早く対策を始められます。

ただし、製品で防ぎやすい攻撃と防ぎにくい攻撃があります。

• 防ぎやすい：SQLインジェクションなど、決まったパターンを持つ攻撃
• 防ぎにくい：ログインした利用者が、本来見られない他人のデータを開く操作
• 防ぎにくい：設計上の抜けを突いた、通常の操作と見分けがつかない攻撃

WAFは通信の中身から攻撃らしいパターンを見つける仕組みのため、普通の操作に見える攻撃は見分けにくい場合があります。

権限の抜けのように、システムの作りに原因がある弱点は、プログラムの修正で対応するのが基本です。

まずは製品で既知の攻撃を防ぎ、その間にプログラムの修正を計画的に進めると、費用と期間を分散できます。

ログの整備から始めて事後対応の負担を減らす

後付けの対策を考えるときは、万が一の漏洩時にかかる対応まで視野に入れておくと、優先すべきことが見えてきます。

個人情報の漏洩が起きると、個人情報保護法にもとづいて、個人情報保護委員会への報告や本人への通知が必要になる場合があります。

• 原因と範囲を特定する調査（フォレンジック調査）
• 個人情報保護委員会への速報・確報の作成
• 対象となる本人への通知と、問い合わせ窓口の設置
• システム停止中の業務の遅れと、取引先への説明

法令上の報告対象となる個人データの漏えい等では、事態を知った後、速やかに速報を行います。目安はおおむね3〜5日以内です。確報は原則30日以内、不正の目的による行為のおそれがある場合は60日以内とされています。報告対象となる場合は、本人への通知も必要です。

このときログが残っていないと漏洩の範囲を絞り込めず、影響範囲の特定が難しくなり、調査や対象者への対応が広範囲に及ぶおそれがあります。

操作ログの記録や保存先の見直しは、権限設計の作り直しなどに比べて改修範囲が小さく済むことが多く、後付けでも取り組みやすい対策です。

新規開発では工程ごとにセキュリティ対策を組み込む

これからシステムを開発する場合は、最初から対策を組み込むことで、後付けの費用を抑えられます。発注側が関わるべきポイントもあわせて確認しておきましょう。

企画・要件定義：セキュリティ対策の範囲を決める

セキュリティ対策の出発点は、「何を」「誰から」守るのかを決めることです。

ただし、「個人情報を扱うので対策は厚めに」という伝え方だけでは、どの程度の対策が必要かを判断しにくくなります。

どの情報を、誰が、どこから見るのかまで具体的に伝えると、必要な対策の範囲がはっきりします。

たとえば社内のパソコンからだけ使うシステムと、外出先のスマートフォンからも使うシステムでは、ログインの仕組みや通信の守り方が大きく変わります。取引先にも画面を公開するなら、他社のデータが見えないようにする権限設計も欠かせません。

使う人と使う場所は業務を知る発注側だからこそ判断できるため、要件定義の段階で開発会社と一緒に整理しましょう。

設計・開発：画面に見えないセキュリティ対策を組み込む

開発会社として、設計の段階で特に押さえておきたい対策は次のとおりです。

• 権限の判定は画面ではなくサーバー側で行う
• パスワードは元に戻せない形（ハッシュ化）で保存する
• 多要素認証を導入し、必要に応じて接続元の制限も組み合わせる
• エラー画面に内部の情報を表示しない
• 使っている外部ライブラリとバージョンを一覧で管理する

どれも画面の見た目には表れないため、完成品を操作するだけでは、対策されているかを確かめるのは難しいでしょう。

特に権限の判定を画面側だけで行っていると、URLの数字を書き換えるだけで他人のデータが見えてしまうことがあります。

こうした問題は後から直すと全画面に影響するため、設計書の段階で対策の方針が書かれているかを確認しておくと安心です。

IPAが公開している「安全なウェブサイトの作り方」などのガイドラインを基準にしているかどうかも、対策の水準を測る目安になります。

テスト・リリース前：脆弱性診断の方法を使い分ける

開発が終わったら、リリース前に脆弱性診断を行い、見つかった問題を直してから公開します。

診断には、ツールで自動的に調べる方法と、専門家が手作業で調べる方法があります。

ツール診断は既知の弱点を広く見つけるのが得意な一方、「一般社員が管理者のデータを見られる」といった権限の抜けは、手作業でないと見つかりにくい傾向があります。

予算に限りがある場合は、ツール診断を全体に行い、ログインや個人情報を扱う画面だけ手作業で確認するといった組み合わせも考えられます。

診断で見つかった問題の修正と再確認の期間まで、リリース前のスケジュールに入れておきましょう。

リリース後の運用で続けるセキュリティ対策

セキュリティ対策は、リリースしたら終わりではありません。

運用を続けるなかで、守りを保つために取り組みたい対策を紹介します。

アップデートを先送りしない仕組みをつくる

システムが使っているOSやミドルウェア、ライブラリには、弱点を修正した新しいバージョンが定期的に公開されます。

ところが実際の現場では、「更新したら動かなくなるかもしれない」という不安から、アップデートが見送られているケースも見られます。

アップデートを先送りするほど、すでに公表されている弱点が残ったままになり、まとめて更新するときの作業量も大きくなります。

本番と同じ構成の検証環境があれば、更新後の動作を事前に確かめられるため、こまめなアップデートに踏み切りやすくなります。

保守契約にアップデートと動作確認が含まれているか、検証環境が用意されているかを確認しておきましょう。

アカウントとログの管理でセキュリティを保つ

運用中の情報漏洩は、外部からの攻撃だけでなく、アカウントの管理不足から起きることもあります。

退職者のアカウントが残っていないか、権限が必要以上に広くなっていないかは、定期的に確認したいポイントです。

• 退職・異動のときにアカウントの削除や権限の変更を行う
• 共有アカウントをやめ、一人ひとりにアカウントを発行する
• 操作ログを、システムが動くサーバーとは別の場所にも保存する
• 運用方針として保存期間などを決め、必要な設定や保存先をシステムに反映する

ログについては、「記録している」だけでは足りない場合があります。

漏洩の調査では、侵入の時期が数か月前までさかのぼることも珍しくありません。ログがサーバーの中にしかないと、攻撃者に消されて調査ができなくなるおそれもあります。

ログの保存場所と保存期間は運用ルールではなくシステムの設計で決まるため、開発時に依頼しておきましょう。

定期的にセキュリティ対策を見直す

攻撃の手口は年々変わるため、開発時には十分だった対策も、数年たつと不足することがあります。

見直しのタイミング	見落とされやすい確認ポイント
社内で決めた周期の定期点検	退職者や取引終了先のアカウント、使われなくなったAPIキーが残っていないか
機能の追加・改修のとき	新しく追加したライブラリや外部サービスとの連携に弱点がないか
大きな漏洩事件が報じられたとき	同じ製品やVPN機器を自社でも使っていないか
OS・ミドルウェアのサポート終了前	移行やバージョンアップの計画と予算が確保されているか

見直しというとシステムの中身ばかりに目が向きがちですが、実際には「つないだまま忘れられたもの」が穴になっているケースも見られます。

製品・バージョンの台帳を確認し、不明な場合は開発会社や保守会社に問い合わせることをおすすめします。

見直しの際は、IPAが2026年3月に公表した「中小企業の情報セキュリティ対策ガイドライン」第4.0版の自社診断などを物差しにすると、不足している点を客観的に把握できます。

改修のたびに対策を確認せず機能を足していくと、気づかないうちに弱点が増えていくことがあります。

発注前に開発会社へ確認しておきたいセキュリティのポイント

新規開発でも既存システムの改修でも、発注の段階で開発会社とセキュリティ対策の認識をそろえておくことが大切です。

相談や見積もりの際に確認しておきたいポイントを紹介します。

見積もりにセキュリティ対策が含まれているか確認する

見積もりの金額だけで比べると、セキュリティ対策の範囲の違いに気づきにくくなります。

見積もりや提案を受けるときは、次のような点を具体的に聞いておくと比較しやすくなります。

• どのガイドラインや基準をもとに対策を設計するか
• 脆弱性診断を行うか、行う場合はツールか手作業か
• 操作ログの保存場所と保存期間はどうなっているか
• リリース後のアップデート対応は保守に含まれるか

同じような機能でも、対策の範囲によって見積もり額は変わります。

見積もりによってはセキュリティ対策が別料金や対象外になっている場合もあるため、金額だけで比べないよう注意が必要です。

回答の内容を比べることで、各社がセキュリティにどれだけ配慮しているかも見えてきます。

開発中の確認方法と報告のタイミングを決める

発注した後も、セキュリティ対策が予定どおり進んでいるかを確認できる仕組みがあると安心です。

たとえば設計書のレビューの場で、権限の判定方法やパスワードの保存方法を説明してもらうと、専門知識がなくても対策の考え方を把握できます。

報告を受けるタイミングを工程ごとに決めておくと、問題が見つかったときにも早めに手を打てます。

分からない用語があれば、遠慮なく開発会社に質問して構いません。発注側が理解できる言葉で説明してくれるかどうかも、相談先を選ぶときの手がかりになります。

責任の範囲と保守の内容を契約で明確にする

情報漏洩が起きたときに、どこまでが開発会社の責任になるのかは、契約の内容によって変わります。

先ほどの判例のように、対策の範囲があいまいなままだと、トラブルになったときに双方の主張が食い違いやすくなります。

特に保守契約は、障害対応だけが対象で、セキュリティのアップデートは含まれていないケースもあるため、内容を一度確認しておくと安心です。

「セキュリティ対策一式」のような書き方では、何が含まれているのかを後から確認しにくくなります。

対策の内容や脆弱性診断の有無、リリース後のアップデート対応などは、契約書や仕様書に具体的に書いておきましょう。

まとめ

システム開発のセキュリティ対策は、すでに稼働しているシステムでも今から始めることができます。

既存システムでは、脆弱性診断で弱点を把握し、影響の大きいところから優先順位をつけて段階的に進めるのが現実的な方法です。

後付けでも、改修の時期をまとめたり、セキュリティ製品とプログラムの修正を使い分けたりすることで、費用を抑えながら進められます。

これから開発するシステムであれば、企画・要件定義の段階から工程ごとに対策を組み込むことで、こうした負担を抑えられます。

情報漏洩が起きれば改修費だけでは済まない負担につながるおそれがあるため、気になった時点で早めに動くことが大切です。

「何から始めればいいか分からない」という場合は、まず開発会社に現状を相談するところから始めてみてください。

セキュリティに配慮したシステム開発なら株式会社アレグビット

セキュリティ対策は、新規開発では初期から組み込むことで、既存システムでは優先順位をつけて進めることで、費用と情報漏洩のリスクを抑えやすくなります。

一方で、「自社のシステムにどこまで対策が必要か分からない」「今のシステムが安全なのか不安」といった声も多く聞かれます。

アレグビットでは、新しいシステムの開発だけでなく、既存システムの見直しや改善についても無料でご相談いただけます。

• 他社開発システムの改善・機能追加も対応可能
• 小さなPoCや自動化ツールの導入からでもOK
• 技術選定やAIツール導入のご相談のみでも大歓迎

現在のシステムの状況をお聞きしたうえで、無理のない進め方をご提案します。

セキュリティ対策を含めたシステム開発や改善をお考えの方は、お気軽に株式会社アレグビットまでお問い合わせください。