IDSは攻撃を見つけて知らせるまで、IPSは見つけた通信をその場で止めるまでを担当します。両者はまったく別の製品とは限りません。オープンソースのSuricataでは、ルールの先頭に置くaction句を alert にするか drop にするかという1語で切り替わる関係にあります。この記事では、仕組みの差、シグネチャ型とアノマリ型という検知方式、NIST SP 800-94が定める4分類、ファイアウォール・WAF・UTMとの守備範囲の切り分け、そしてAWSのGuardDutyやNetwork Firewallがクラウドでどこまで肩代わりするのかを、導入判断に必要な順で整理しました。
まとめ｜IDS・IPSは侵入を検知・自動遮断する二段目の防御
IDSとIPSの差は、攻撃を見つけた後の動きにあります。IDSは検知して管理者に警告するまで、IPSは検知した通信をその場で自動遮断するまでを担当します。どちらもファイアウォールをすり抜けた通信の「振る舞い」を見張る、境界の内側を守る二段目の網です。宛名（IPアドレス・ポート）で通す・通さないを判定するファイアウォールとは、見ている対象が違います。
実装の面では、IDSとIPSは別々の製品というより同じエンジンの2つのモードです。「どちらを買うか」ではなく「どのルールをどこまで自動で落とすか」が設計の中身になります。
導入時にまず決めるのは、自前で構築するか、UTMの一機能として使うか、監視まで含めて外部に任せるかの3択です。誤検知（正常な通信を攻撃と誤認）への対応や日々のシグネチャ更新は運用の負担になり、機器を置くだけでは守りきれません。検知の穴が残っていないかを外部の目で確かめたい場合は、脆弱性診断・セキュリティ診断で現状の防御構成を含めて調査を受け付けています。
IDSとIPSの基本｜検知だけか自動で遮断まで担うかの役割の差
IDSとIPSは、頭文字の「D（Detection＝検知）」と「P（Prevention＝防御）」がそのまま役割の差を表します。兆候をつかむところは共通で、その後に自動で手を下すかどうかが分かれ目になります。
IDS（不正侵入検知システム）が担う検知と警告どまりの基本動作
IDSは、通信やサーバーのログを監視し、攻撃と疑わしいパターンを見つけると管理者へアラートを上げます。役割は検知と通知までで、通信そのものは止めません。止めないことは弱点にも見えますが、正常な通信を誤って遮断して業務を止めるリスクがない利点でもあります。まず通信を観測して攻撃の傾向を把握したい段階や、既存の通信経路に影響を与えたくない環境での採用が中心です。IPAの情報セキュリティ10大脅威 2026［組織］では、1位がランサム攻撃による被害（11年連続11回目）、4位がシステムの脆弱性を悪用した攻撃でした。侵入の初期段階にあたるスキャンや脆弱性を突く通信を記録に残しておくと、後から侵入経路をたどる材料になります。
IPS（不正侵入防御システム）が担う自動遮断までの一連の動作
IPSは、IDSの検知機能に「その場で遮断する」動作を加えたものです。通信経路の上に置き（インライン構成）、すべての通信を通り道で検査するため、攻撃と判定した通信を人の対応を待たずに破棄する動作です。半面、誤検知が起きると正常な通信まで遮断してしまい、サービス停止につながる点に注意が要ります。Suricataのユーザーガイドには独立した「IPS Mode」の章があり、Linuxではiptablesから渡したNFQUEUE経由でパケットを受け取り、通過か破棄かを決める構成がsuricata.yamlの設定解説に示されています。
Suricataのaction指定で分かれる検知どまりと遮断までの設定差
IDSとIPSの境目は、ルール1行のなかにあります。Suricataのルールはaction・header・optionsの3部で構成され、先頭のactionが一致時の動作を決めます。公式のRules Formatが列挙するactionは、alert・pass・drop・reject・rejectsrc・rejectdst・rejectbothの7種類です。dropはパケットを破棄してアラートを出し、rejectは送信元へRSTまたはICMP到達不能を返します。IPSモードでreject系を指定した場合はdropも同時に有効になる、と注記されています。
# 検知どまり（IDS相当）: アラートを出して通信は通す
alert tcp $EXTERNAL_NET any -> $HOME_NET 3389 (msg:"RDP scan"; flow:to_server; sid:1000001; rev:1;)
# 遮断まで（IPS相当）: 条件は同じで action だけ drop に変える
drop tcp $EXTERNAL_NET any -> $HOME_NET 3389 (msg:"RDP scan blocked"; flow:to_server; sid:1000002; rev:1;)上がIDS相当、下がIPS相当の書き方です。段階導入では、まずalertで数週間ログを取り、誤検知が出なかったルールから順にdropへ切り替えられます。書式とactionの全一覧はSuricata公式ドキュメントのRules Formatにまとまっており、Suricata自体の導入手順はSuricataとは？導入からルール作成・IPSモード運用までで扱っています。
IDSとIPSの違いと、誤検知リスクからみた使い分けの判断基準
両者の違いは下表の通りです。判断の軸は「攻撃を自動で止めたいか」と「誤検知で通信が止まるリスクをどこまで許容できるか」の2点にあります。可用性が最優先の基幹システムでは、いきなり全自動遮断にせず、一定期間ログを観測して誤検知の傾向をつかんでから遮断へ移す進め方が現実的です。
| 観点 | IDS（検知） | IPS（防御） |
|---|---|---|
| 攻撃への動作 | 検知して警告 | 検知して自動遮断 |
| 通信経路上の位置 | 通信を複製し監視 | 通信経路上（インライン） |
| Suricataのaction | alert | drop・reject |
| 誤検知の影響 | アラートの空振り | 正常通信も遮断 |
| 向く場面 | 観測・影響回避重視 | 自動遮断を優先 |
実務では、確度の高いものだけ遮断し、判断が難しいものは警告にとどめる中間設定が多く見られます。ルール単位でactionを選べる以上、製品を分けずに「一部だけIPS」という構成が組めます。
IDS・IPSの検知方式と設置形態｜シグネチャ型とネットワーク型
製品選びで外せないのが、「どうやって攻撃を見分けるか（検知方式）」と「どこに置くか（設置形態）」の2軸です。組み合わせによって、得意な攻撃と守れる範囲が変わります。
シグネチャ型とアノマリ型の2つの検知方式の違いと得意とする攻撃
検知方式は大きく2つに分かれます。シグネチャ型（不正検出型）は、既知の攻撃パターンを登録した「シグネチャ」と通信を照合し、一致すれば攻撃と判定する方式です。既知の攻撃に強く誤検知が少ない半面、シグネチャが未登録の新種の攻撃は見逃します。アノマリ型（異常検出型）は、平常時の通信を「正常」の基準として学習し、そこから外れた振る舞いを異常として検知する方式です。未知の攻撃や内部の不審な挙動をとらえられる一方、正常の幅の設定が甘いと誤検知が増えます。多くの製品は両方を組み合わせ、既知はシグネチャで確実に、未知はアノマリで補う構成が一般的です。シグネチャを外部から更新できるエンジンでは、配信元の選定と更新頻度が検知力を左右します。
ネットワーク型（NIDS/NIPS）とホスト型（HIDS/HIPS）の設置場所
設置形態も2つに分かれます。ネットワーク型（NIDS／NIPS）は、要所に設置してそこを流れる通信全体を監視します。1か所で複数のサーバーやPCをまとめて見張れる反面、暗号化された通信の中身は原則読めません。ホスト型（HIDS／HIPS）は、守りたいサーバーやPCの1台ごとに導入し、そのマシンのログ・ファイル改ざん・プロセスを監視します。端末単位で細かく見られ、暗号化通信も復号後の挙動を追えますが、台数分の導入・運用が要ります。境界の通信全体はネットワーク型、重要サーバー単体はホスト型と、守る対象に応じて併用するのが基本です。端末側の挙動監視を踏み込んで行う製品分類がEDRで、HIDSの発展形として並べると製品比較がしやすくなります。
NIST SP 800-94が示す4分類と無線・振る舞い分析の位置づけ
日本語の解説はネットワーク型とホスト型の2分類で終わることが多いのですが、米国NISTのガイドラインはもう少し細かく切っています。SP 800-94「Guide to Intrusion Detection and Prevention Systems (IDPS)」は、IDPSをnetwork-based（ネットワーク型）、wireless（無線型）、network behavior analysis（ネットワーク挙動分析型）、host-based（ホスト型）の4クラスに分けています。無線型は無線LANのプロトコルを監視し、社内に持ち込まれた不正なアクセスポイントを検知する系統です。挙動分析型はトラフィック量や通信パターンの偏りからDDoSやマルウェアの内部拡散をとらえます。発行は2007年2月でSP 800-31を置き換えたものにあたり、2012年公開のRev.1ドラフトは最終版に至らず2022年7月15日付の注記で撤回されました。分類を4つで持っておくと、無線区間や内部拡散の監視が抜けていないかを点検する軸が1つ増えます。
IDS・IPSで防げる攻撃と、WAFに任せるべき防げない攻撃
IDS・IPSが得意とするのは、通信の振る舞いから見抜ける攻撃です。ポートスキャンやDoS/DDoS攻撃、既知の脆弱性を突く通信、バッファオーバーフローの兆候をとらえます。一方で苦手な領域も明確です。SQLインジェクションやクロスサイトスクリプティングのように、正規のWebリクエスト（HTTPS）に紛れて届く攻撃は、Webアプリの文脈を解さないIDS・IPSでは判定が難しく、WAFの守備範囲になります。暗号化された通信の中身も、ネットワーク型では原則見えません。メールの添付ファイルや正規アカウントの乗っ取りを起点とする標的型攻撃も単独では止めきれません。「何を防ぎ、何を他の製品に任せるか」を分けて設計することが、過信による穴を防ぎます。
IDS・IPSとファイアウォール・WAF・UTMの違いと多層防御での位置
IDS・IPSは単独で完結する製品ではなく、ファイアウォールやWAFと役割を分担して初めて機能します。守る層と目的の違いを押さえると、自社に何が足りていないかが見えてきます。
ファイアウォールとの違い｜通信の宛名判定と中身の振る舞いの検知
ファイアウォールは、通信の送信元・宛先・ポート番号という「宛名」を見て、ルールに従い通す・遮断するを判定します。宛名が許可ルールに合っていれば、中身が攻撃でも通してしまいます。IDS・IPSは、そこを通過した通信の「中身の振る舞い」を検査し、攻撃の兆候を見つけ出す役割です。両者の詳しい仕組みはファイアウォールとは？仕組み・種類とWAF・UTMとの違い、企業の選び方で整理しています。
WAFとの違い｜ネットワーク層の防御とWebアプリ層の防御の分担
WAF（Web Application Firewall）は、Webアプリケーションへの攻撃に特化した防御です。WAFの検知の仕組みや導入判断はWAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方で詳しく扱っています。IDS・IPSが主にネットワーク層〜トランスポート層の通信を監視するのに対し、WAFはHTTPリクエストの中身を解析してアプリ層の攻撃を防ぎます。守る層が違うため両者は競合せず、Webサービスを公開する構成では、ネットワーク層をIDS・IPS、アプリ層をWAFが担う分担が基本です。「IDS・IPSがあればWAFは不要」という判断は、アプリ層の攻撃に無防備な穴を残します。
UTMとの違い｜統合機器の一機能としてのIDS・IPSの位置づけ
UTM（統合脅威管理）は、ファイアウォール・アンチウイルス・Webフィルタリング・IPSなど複数の機能を1台に統合した機器です。IDS・IPSは、UTMを構成する一機能として組み込まれている場合があります。中小規模の拠点では、専用機を単体で導入するよりUTMの中のIPS機能を使うほうが、機器と運用を1台にまとめられて合理的です。UTMの機能構成と選び方はUTMとは？統合脅威管理の機能とファイアウォールとの違い、企業の選び方で解説しています。なお、ここで挙げた4製品はいずれも「境界の内と外を分ける」前提に立つ点で共通し、社内ネットワークを信頼せずに毎回検証するゼロトラストとは出発点が違います。各製品の守備範囲を整理すると次の通りです。
| 製品 | 主に守る層 | 判定の対象 |
|---|---|---|
| ファイアウォール | ネットワーク層 | IP・ポート・通信状態 |
| IDS・IPS | ネットワーク〜TP層 | 攻撃の兆候・振る舞い |
| WAF | Webアプリ層 | HTTPリクエストの中身 |
| UTM | 複数層を統合 | 上記機能を1台で |
クラウドのIDS・IPS｜GuardDutyとNetwork Firewallの役割分担
「クラウドに移したからIDS・IPSは要らない」という説明は、半分だけ当たっています。AWSの2サービスを公式ドキュメントで突き合わせると、肩代わりされる部分と残る部分が分かれます。
GuardDutyが見るログとNIDSが見るパケットという監視対象の差
まず押さえたいのは、GuardDutyがパケットの中身を見る仕組みではない点です。AWSの公式ドキュメントによれば、有効化すると自動で取り込まれる基盤データソースは、CloudTrailの管理イベント・VPCフローログ・DNSログの3つです。保護プランを有効にすると、EKSの監査ログやRDSのログインアクティビティ、EC2・EKS・ECS-FargateのRuntime Monitoringなどが加わります。いずれもログとメタデータであり、パケットのペイロードそのものではありません。NIDSがパケットの中身をシグネチャと突き合わせるのに対し、GuardDutyは「誰がどこへ何回つないだか」の記録から異常を見抜く仕組みです。ペイロード内の攻撃コードを見て止めたい要件は、これだけでは満たせません。
AWS Network FirewallがSuricata互換ルールで担うIPS機能
パケット検査に相当する機能を担うのは、GuardDutyではなくAWS Network Firewallです。公式ドキュメントは、Network FirewallをVPC向けのステートフルなマネージドファイアウォール兼「intrusion detection and prevention service」と定義し、ステートフル検査にオープンソースのIPSであるSuricataを用いてSuricata互換ルールをサポートすると明記しています。インターネットゲートウェイ、NATゲートウェイ、VPNやDirect Connect経由の通信をVPCの境界でフィルタする位置づけです。ここで効いてくるのが、前章で見たactionの互換性になります。オンプレミスのSuricataで書き溜めたルールの考え方が、そのままクラウド側のルールグループに持ち込めます。
オンプレとクラウドの併用環境でIDS・IPSを残すべき判断条件
3者の守備範囲を整理すると下表になります。判断は条件ごとに明確です。ワークロードが完全にVPC内で完結しているなら、専用アプライアンスを持ち込まずGuardDutyとNetwork Firewallの組み合わせで足ります。逆に、拠点間の社内LANや工場ネットワーク、無線区間のように、クラウドのログに一切現れない通信が残っているなら、そこにIDS・IPSは残す必要があります。「不要になった」のではなく「実装の形がマネージドサービスへ置き換わりつつある」と捉えるのが正確です。クラウド側の構成を含めて設計から相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）で対応しています。
| 手段 | 見ているもの | 遮断の可否 |
|---|---|---|
| 従来型IDS・IPS | パケットの中身 | IPSなら可 |
| GuardDuty | ログ・メタデータ | 検知のみ |
| Network Firewall | パケットの中身 | 可（Suricata互換） |
IDS・IPSの導入判断｜自前構築・UTM統合・監視サービスの選び方
ここからはカタログではなく判断の話です。どの形で持つか、そしてアラートを誰が見るかを、条件付きで言い切ります。
自前構築・UTM統合・マネージド監視を規模で分ける選定の基準
導入形態は3つあり、規模と体制で選び分けます。拠点が少なく情シスの人手が限られる中小規模なら、UTMのIPS機能で足りることが多く、専用機を別建てにするのは過剰投資です。自社で技術を持つチームなら、OSSのIDS・IPSを自前構築する選択もあります。SuricataはIDS・IPS・ネットワーク監視を1つで担うエンジンで、公式ドキュメントの現行版は9.0.0-dev（2026年9月時点・安定版は8.0系）です。ただし自前構築はシグネチャ更新と誤検知チューニングを自社で背負う前提になります。24時間の監視まで含めて任せたいなら、マネージド監視サービス（MSS／SOC）に外注するのが、人手をかけずに検知後の対応まで回す現実解です。避けるべき失敗も2つはっきりしています。全ルールをいきなりdropで有効化して業務通信を落とすことと、アラートを受け取る担当者を決めないまま機器だけ導入することです。
アラートを誰が見るか｜SOC・SIEMと接続する運用体制の設計
IDS・IPSは「置いて終わり」ではなく、アラートを見て対処する運用があって初めて効く仕組みです。設計時に決めるべきは3点あります。第1に、アラートの転送先です。単体のコンソールに溜めるだけでは他機器のログと突き合わせられないため、SIEMへ集約して認証ログやEDRと相関させる構成が扱いやすくなります。第2に、一次対応の当番です。夜間・休日にアラートが上がったとき誰が最初に見るかを決めていないと、検知した事実が翌営業日まで放置されます。内製と外注の分岐点はSOCの内製とアウトソースの判断で整理しています。第3に、遮断の解除手順です。誤検知で正常通信を落とした際、誰がどの権限でルールを無効化するかを事前に書いておかないと、障害対応が長引きます。監視設計を組み立てる前に、防御構成の穴を洗い出す脆弱性診断・セキュリティ診断を通しておくと、投資の優先順位が決めやすくなります。
よくある質問
IDS・IPSの検討でよく挙がる質問に回答します。
IDSとIPSの違いは何ですか？
攻撃を検知した後の動作が違います。IDS（不正侵入検知システム）は兆候を検知して管理者に警告するまでを担い、通信そのものは止めません。IPS（不正侵入防御システム）は検知した通信をその場で自動的に遮断します。Suricataではこの差がルール先頭のactionで切り替わり、誤検知を避けたい場合はalert、攻撃を人の対応を待たず止めたい場合はdropが向きます。
IDS・IPSとファイアウォールの違いは何ですか？
見ている対象が違います。ファイアウォールは通信の送信元・宛先・ポート番号といった宛名を見て通す・遮断するを判定する仕組みです。IDS・IPSは、その宛名判定を通過した通信の中身の振る舞いを検査し、攻撃の兆候を見つけます。ファイアウォールが境界の第一関門、IDS・IPSがその内側を見張る二段目という関係で、両者は併用します。UTMのように1台へ統合した製品でも、内部では機能として分かれたままです。
IDS・IPSとWAFはどちらを導入すべきですか？
守る層が違うため、どちらか一方ではなく役割で選びます。IDS・IPSはネットワーク層〜トランスポート層の通信を監視し、WAFはWebアプリへの攻撃をHTTP通信の中身から防ぎます。Webサービスを公開するならアプリ層を守るWAFの優先度が高く、ネットワーク層の監視をIDS・IPSが補完する形が基本です。公開Webを持たない社内システムだけの構成なら、順序は逆になります。
IDS・IPSで防げない攻撃にはどんなものがありますか？
正規のWebリクエストに紛れて届くアプリ層の攻撃（SQLインジェクションなど）は苦手で、WAFの守備範囲です。暗号化された通信の中身も、ネットワーク型では原則見えません。メールの添付ファイル経由のマルウェアや正規アカウントを乗っ取った操作も、振る舞いに現れにくく単独では防ぎきれません。IPAの10大脅威で上位に並ぶランサム攻撃やサプライチェーン経由の侵入は、複数製品の組み合わせで受け止める前提になります。
クラウド環境でもIDS・IPSは必要ですか？
形を変えて必要です。AWSの場合、GuardDutyはCloudTrail管理イベント・VPCフローログ・DNSログを基盤データソースとして異常を検知しますが、パケットの中身までは見ません。ペイロードを検査して遮断する役割は、Suricata互換ルールを使うAWS Network Firewallが担います。一方、クラウドのログに現れない社内LANや無線区間、工場ネットワークが残っているなら、そこには従来型のIDS・IPSが要ります。
関連記事
- ファイアウォールとは？仕組み・種類とWAF・UTMとの違い、企業の選び方：IDS・IPSの前段で通信を許可・遮断する境界防御の仕組み。
- UTMとは？統合脅威管理の機能とファイアウォールとの違い、企業の選び方：IDS・IPSを一機能として統合するUTMの選び方。
- VPNとは？仕組み・種類・メリットとデメリット、企業導入の判断基準：社外から社内へ安全に接続する経路の確保。
- Suricataとは？導入からルール作成・IPSモード運用まで：本記事のルール例を実際に動かす場合のエンジン側の手順。
- DDoS攻撃とは？仕組み・種類とDoS攻撃との違い、企業が取るべき対策を解説：検知だけでは止めきれない大量通信型攻撃の対策。
