RASP（実行時アプリケーション自己保護）とは？WAFとの違いと導入判断を実装視点で解説

RASPは、アプリケーションが動いている実行環境の内側に監視の目を差し込み、攻撃が成立する直前の処理を止める防御の仕組みです。通信を手前で弾くWAFとは、見ている場所も判定の根拠も違います。この記事では、バイトコード計装がシンク関数を捉える原理、Log4Shellで検知根拠の差がどう効いたか、JVMエージェントの実装手順とレイテンシの見積もり方、2026年時点で製品名がADRへ移った事情までを実装視点でまとめました。RASPを見送るべき条件も代案とセットで示します。

まとめ｜RASPを本番へ入れる条件とWAFで足りる境界の結論

結論を先に置きます。RASPが投資に見合うのは、コードへ手を入れられない稼働中のアプリを抱えている場合です。改修の予算も窓口も無いレガシーなJavaアプリで、脆弱性が公表されるたびに緊急対応を強いられている。この状態なら、起動オプションを1行足すだけで防御層が乗るRASPの価値は明確です。

逆に、開発チームが手元にあって自由に直せるアプリなら順序が違います。まず出荷前に潰す。SASTとDASTをパイプラインへ入れて脆弱性そのものを減らし、境界にはWAFを置く。RASPを重ねるのは、それでも残る「直せないが動き続ける処理」に対してです。順番を飛ばすと、直せる脆弱性を遮断ログで隠したまま運用することになります。

規模に関係なく効く見送り条件もあります。本番サーバへ再起動を伴う変更を入れられない現場では、RASPは選べません。エージェントの差し込みが起動時の処理だからです。

RASPの定義と計装の仕組み｜アプリ内部から攻撃を検知して止める範囲

名前が長いわりに、やっていることは単純です。アプリの中に見張りを置く。それだけです。

実行時アプリケーション自己保護という定義と防御の対象になる攻撃の範囲

RASPはRuntime Application Self-Protectionの略で、日本語では「実行時アプリケーション自己保護」と訳されます。Gartnerが2012年に提唱した用語。実行時の計装によってアプリケーション内部の情報を使い、攻撃を検知して遮断する技術を指します。外部の装置ではなく、守る対象そのものへ機能を組み込む点が名前に表れています。

実装形態は、アプリケーションサーバへ組み込まれるライブラリまたはエージェント。ソースコードの書き換えは不要です。防御の対象になるのは、SQLインジェクション、コマンドインジェクション、パストラバーサル、安全でないデシリアライズ、クロスサイトスクリプティングといったアプリ内部の処理として観測できる攻撃。OWASP Top 10 2025年版の10項目のうち、実行時に危険な処理へ到達する型のリスクが守備範囲です。

裏返すと、アプリの外側で完結する攻撃には届きません。ネットワーク層のDDoS、認証情報の総当たり、クラウド側の設定不備。いずれも境界の装置やクラウド側の仕組みで別途塞ぐ前提になります。

バイトコード計装でシンク関数をフックする検知原理と誤検知が減る理由

Javaの場合、RASPエージェントはjava.lang.instrumentのAPIを使い、クラスがロードされる瞬間にバイトコードを書き換えます。書き換える先は、危険な操作を実際に行う関数群。SQL実行、ファイルアクセス、外部コマンド起動、デシリアライズといった、攻撃の「結果」が発生する地点です。この地点をセキュリティの用語でシンクと呼びます。

シンクへ到達した時点で、エージェントは渡された引数とそこへ至る実行コンテキストを見ます。SQL文が組み立てられた結果、リクエストパラメータ由来の文字列がクエリの構文構造そのものを変えていれば、それはインジェクション。文字列がパターンに一致するかではなく構文木として意味が変わったかで判定できる点が、誤検知の少なさにつながります。

技術基盤としては、テスト環境で脆弱性を見つけるIASTのエージェントによる実行時検査とほぼ同じ計装です。分かれるのは目的。検査は修正チケットを作るために動き、防御は攻撃を止めるために動きます。

監視モードと遮断モードの切り替えで変わる本番適用時の影響範囲の広さ

RASPには通常2つの動作モードがあります。検知した内容をログへ出すだけの監視モード（モニタリング）と、該当する処理を実際に止めてリクエストを失敗させる遮断モード（ブロッキング）です。

運用上はまったく別物として扱う必要があります。監視モードの最悪はログの増加とわずかな性能低下ですが、遮断モードの最悪は正常な業務処理の停止。動的にSQLを組み立てる古い実装や、意図的にファイルパスを受け取る管理画面は、正常な処理でもシンクの引数が攻撃パターンに近づきます。

実務では、業務のピーク期間を含めて監視モードで最低2〜4週間回してから遮断へ切り替えます。切り替え単位も全体一括ではなく検知種別ごと。SQLインジェクションの遮断だけ先に有効化し、パストラバーサルは監視のまま残す粒度で制御できる製品なら、切り戻しの範囲が小さく済みます。

RASPとWAFの違い｜境界防御と内部防御で分かれる検知根拠と誤検知の量

「WAFがあるならRASPは要らないのでは」という問いが最初に来ます。答えは、守れる攻撃の種類が違うので置き換えにはならない、です。

検知根拠で分かれるシグネチャ照合と実行コンテキスト判定の精度差

WAFは通信経路の手前に立ち、受信したリクエストの中身を既知の攻撃パターン（シグネチャ）と照合します。アプリがそのリクエストをどう処理するかは見えません。アプリに触れずに導入できる一方、正常なリクエストが偶然パターンに一致すれば誤検知になる。WAF導入後のチューニング工数は、この構造に由来します。

境界側の仕組みをどう選ぶかは、WAFの種類とIPS・IDSとの守備範囲の違いを先に整理しておくと判断しやすくなります。RASPは、そこで取りこぼす層を埋める位置づけ。併用する場合の役割分担は、WAFで量を削り、RASPで質を見る形になります。スキャナや自動化された攻撃の大半をWAFが手前で落とし、通り抜けた少数だけをRASPが内部で判定するため、遮断ログに残るのが本当に見るべき事象に絞られるからです。

Log4Shellのような未知の攻撃でWAFの空白期間をRASPが埋める境界

差が最も分かりやすく出たのが、2021年12月に公表されたLog4Shell（CVE-2021-44228）です。Apache Log4j 2のJNDIルックアップを悪用するこの脆弱性は、攻撃文字列の表現方法がいくつもあり、WAFの署名が出た直後から回避パターンが次々に見つかりました。署名を作っては迂回される、という追いかけっこです。

RASP側の見え方は違いました。攻撃文字列がどう難読化されていようと、JNDIのルックアップ処理が外部へ接続しようとする瞬間は変わりません。その処理をシンクとして押さえていれば、入力の形に関係なく止まります。攻撃の「入口」ではなく「結果」を見る設計がそのまま効いた形です。

ただし万能ではありません。エージェントが押さえていないシンクを経由する攻撃、ビジネスロジックの欠陥を突く不正な業務操作、認可の設計ミスによる情報参照。実行時の防御は、既知の危険な処理パターンを網羅した範囲での防御にとどまります。

RASPの導入手順｜JVMエージェントの差し込みと監視モードからの段階投入

導入作業そのものは半日で終わります。時間がかかるのはその後です。

JVMへjavaagentを差し込む起動オプションの設定と確認の手順

Javaアプリケーションの場合、実装作業はアプリの起動コマンドへエージェントのオプションを追加するところから始まります。ビルド成果物には触れません。

1. エージェントのアーカイブと接続用の設定ファイルをアプリケーションサーバへ配置する
2. 起動スクリプトまたはコンテナのエントリポイントへ、エージェント読み込みのJVMオプションを追加する
3. 設定ファイルへ管理サーバの接続先とアプリ識別子を書き、動作モードを監視に指定する
4. 再起動し、起動ログの初期化メッセージと管理画面への対象アプリの出現を確認する
5. 検証環境へ既知の攻撃パターンを1件送り、検知イベントが上がるところまで確認する

コンテナ運用なら、エージェントをイメージへ焼き込むか、初期化用コンテナから共有ボリューム経由で渡すかの選択です。前者は再ビルドが要る代わりに構成が単純、後者は既存イメージを変えずに済む代わりにマニフェストが増えます。更新頻度の低いアプリなら前者で十分。

Node.jsと.NETで異なるフック方式と対応言語で候補が絞られる関門

製品選定の第一関門は、機能比較ではなく対応言語です。RASPは言語ランタイムの内部構造に依存するため、対応範囲が製品ごとにはっきり分かれます。

Javaは実装が最も揃っています。JVMの標準的な計装APIが公開されており、どの製品も対応。.NETはCLRのプロファイリングAPIを使う方式で、主要製品が対応しています。Node.jsはモジュール読み込みをラップして危険な関数を置き換える方式が中心で、対応製品は減少。PythonやRubyではさらに限られ、機能範囲もJavaと同等ではありません。

選定は「候補を並べて比較する」より先に、自社のランタイムで動く製品を洗い出す作業から始まります。複数言語が混在するマイクロサービス構成なら、全サービスに同一製品を入れられない事態も起こりうる。その場合はRASPを主要言語のサービスに限定し、残りは境界側で守る割り切りが要ります。

監視モードで誤遮断の芽を潰してから遮断へ切り替える段階投入の設計

監視モード期間中の作業は、検知イベントを1件ずつ「本物の攻撃」「正常処理の誤検知」「判断保留」へ仕分けること。この仕分けが遮断モードへ移る際の設定になります。

誤検知として仕分けたものは、除外ルールへ落とします。除外の単位は検知種別とエンドポイント、あるいは呼び出し元のクラスやメソッド。「SQLインジェクションの検知を全体で無効化する」といった広い除外にすると、防御層としての意味が消えます。狭く、根拠を書いて除外する。この記録が引き継ぎ資料にもなります。

誤検知の温床になっている実装を直す方向も、並行して検討に値します。動的SQLの組み立てが誤検知を生んでいるなら、それは本当に脆弱性である可能性も高い。DASTで擬似攻撃を投げて出荷前に確認する工程と突き合わせれば、遮断で覆い隠すべきか修正すべきかの判断がつきます。

実行時オーバーヘッドの見積もり｜本番投入の可否を分ける負荷と障害リスク

本番のアプリに常駐する以上、性能と可用性への影響は避けて通れません。ここを測らずに入れると、後で外す羽目になります。

レイテンシとメモリの増加量を実測する負荷試験の組み立てと合格基準

ベンダーが公表する「オーバーヘッドは数%」という数値は、一般的なワークロードでの値です。シンクの呼び出し頻度が高い処理ほど影響が出るため、自社アプリでの実測が要ります。エージェント無効・監視モード・遮断モードの3条件で同一シナリオを流し、次の値を比較してください。

• レスポンスタイムの中央値と95パーセンタイル値（平均値だけ見ると裾の悪化を見落とす）
• ヒープ使用量とGCの発生頻度・停止時間
• アプリケーションの起動完了までの時間（計装はクラスロード時に走るため起動が延びる）
• CPU使用率のピーク値

合格基準は性能要件から逆算して先に決めます。95パーセンタイル値の悪化を要件の余裕分の何割まで許容するか、起動時間の延びがオートスケールの応答性に響かないか。測定後に決めると、出た数字へ基準のほうが寄ります。

エージェント障害でアプリごと落とさないための縮退設定と切り戻し手順

RASPエージェントはアプリと同じプロセス内で動くため、エージェント側の不具合がアプリの停止に直結しうる構造です。管理サーバへの接続断、設定配信の失敗、エージェント自身の例外。これらが起きたときの挙動を導入前に確認しておきます。

確認すべき設定は3つ。管理サーバへ到達できないときに検知を止めてアプリを継続するか、エージェント内部で例外が出たときその処理を素通しするか、遮断モードを再起動なしで監視モードへ戻せるか。3つ目が特に効きます。誤遮断が起きた深夜に再起動しないと止められない仕組みでは、対応が遅れるからです。

最終手段は、起動オプションからエージェントの指定を外して再起動する切り戻し。この手順は運用ドキュメントへ書くだけでなく、検証環境で一度実行しておいてください。試していない手順は必要な場面で使えません。

RASPからADRへの再編｜製品名の変化と検知情報のSOC連携という新しい役割

2026年時点で製品を探すと、RASPという名前の製品が見つかりにくくなっています。カテゴリ名が動いているためです。

Contrast ProtectがADRへ改称した経緯と検知情報の出力先の変化

Contrast Securityは2024年初頭にApplication Detection and Response（ADR）という枠組みを提唱し、従来のRASP製品であるContrast ProtectをContrast ADRへ改称しました。名前だけの変更ではありません。変わったのは検知情報の出口です。

従来のRASPは、攻撃を止めてログを残す閉じた仕組みでした。ADRでは検知事象をMITRE ATT&CKの戦術へマッピングし、SIEMやXDRへ流し込んで運用の一部として扱います。同社は2025年12月4日にDatadog Cloud SIEMとの連携、2026年4月22日にGoogle Security Operationsとの統合を発表しており、出力先の整備が製品価値の中心へ移りました。

選定への影響は具体的です。SOCやSIEMが自社に無いなら、ADR側の連携機能はほぼ使いません。その状態で選ぶと費用の大半が遊びます。すでにSIEMを運用しているなら、アプリ層の検知が既存のインシデント対応フローへ乗る点は実質的な差になります。

DatadogのAAPとDynatraceで分かれるAPM基盤との相乗り前提

もう一系統の潮流が、APM（アプリケーション性能監視）のエージェントに防御機能を相乗りさせる方式です。DatadogはApplication Security Management（ASM）をApp and API Protection（AAP）へ改称し、APIディスカバリやポスチャ管理まで含む範囲へ広げました。Dynatrace Application Securityも同じ構造です。

利点は、エージェントが増えないこと。すでにAPMを入れている環境なら、新たなプロセス内計装を追加せずに防御機能を有効化でき、オーバーヘッドの追加分もゼロから入れる場合より小さく収まります。

制約は、その監視基盤に乗っていることが前提になる点。APMを別ベンダーで運用している現場や、コスト面でAPMを入れていない現場では選べません。専業ベンダー製品を単体で入れるか監視基盤ごと寄せるかという、より上位の意思決定に接続します。

商用を買う前に感触を掴みたい場合、オープンソースのOpenRASP（JavaとPHPに対応）という選択肢もあります。ただし2026年8月時点でnpmパッケージへの新規リリースが直近12か月なく、本番の防御層に据えるのは厳しい判断。検証と学習の用途に限定してください。

RASPを採用すべき現場と見送る現場｜受託開発での採用条件と代替設計

ここまでの内容を、発注や技術選定の場面で使える判断に落とします。結論は明快に分かれます。

改修できないレガシーJavaアプリという採用が投資に見合う条件

採用を勧められるのは、次の条件が重なる場合です。稼働中のJavaまたは.NETアプリで、ソースの改修に時間か費用がかかる。脆弱性の公表ごとに緊急対応が発生している。再起動が計画的に取れる。

この条件下でのRASPは「直せないものを直したことにする」仕組みではなく、「直すまでの時間を買う」仕組みとして働きます。JVM内で仮想パッチを当ててCVEをコード変更なしに無害化する方式を持つWaratekでは、RASP Agentが25.7系（2026年5月時点）、Java Agentが25.6系（2026年2月時点）。Oracleの四半期パッチ適用を待てないアプリで、現実的な選択肢になります。

費用対効果も、防御の性能ではなく緊急対応の削減量で測るのが適切です。年に何回、何人日の緊急対応が発生していたか。そこから逆算した数字が、ライセンス費用と比較すべき値になります。

新規開発でRASPを見送りWAFと脆弱性診断へ寄せるべき条件と代案

新規開発の案件でRASPを最初から入れる提案は、原則として見送るべきです。理由は費用ではなく、順序として誤っているためです。

新規開発なら、脆弱性そのものを作らない側に投資したほうが回収が早い。SASTでコードを検査してCI/CDへ組み込む工程を先に整え、リリース前に外部から診断を入れる。この2つで、RASPが遮断することになる脆弱性の大半は出荷前に消えます。残りへ境界側のWAFを置けば初期構成としては十分。

どこまで検査すれば足りるかの線引きは、システムの重要度と扱うデータで変わります。判断材料が足りない段階なら、脆弱性診断・セキュリティ診断の実施範囲を相談するほうが製品比較より先に片付きます。診断の結果「改修できない箇所が残る」と分かった時点が、RASPを検討する正しいタイミングです。

受託案件でRASPの運用責任を発注側と分担する取り決めの決め方

受託開発でRASPを導入するなら、契約時に決めないと後で揉める論点が3つあります。誤遮断時の一次対応を誰がやるか。検知イベントの日常確認を誰が回すか。バージョン更新を誰の判断で実施するか。

実務上は、遮断モードの有効化と除外ルールの追加を発注側の承認事項にするのが無難です。開発ベンダーが単独で遮断を有効化すると、業務停止時の責任所在が不明瞭になります。逆に検知イベントの一次確認は、内部構造を知る開発側が担うほうが判断が速い。

バージョン更新は、検証環境での動作確認と簡易な負荷試験を挟む前提で、年2回程度の定期作業として保守契約へ含めます。この工数を見込まずに契約すると、更新の止まったエージェントが本番に残り続けます。

よくある質問

RASPの導入検討でよく挙がる質問を、実装と運用の観点から整理しました。

RASPを入れればWAFは不要になりますか？

置き換えにはなりません。RASPはアプリの実行環境内で動くため、到達前の層で完結する攻撃を見られません。大量のスキャン、DDoS、認証の総当たりは境界側で落とす必要があります。実務上はWAFで量を削ってRASPで質を見る併用が基本で、RASP導入を理由にWAFを解約する判断は避けてください。

RASPは本番環境の性能にどれくらい影響しますか？

ベンダーの公表値は数%程度ですが、自社アプリでの実測が必要です。影響が大きく出るのは、SQL実行やファイルアクセスといったシンクの呼び出し頻度が高い処理。大量のクエリを発行するバッチでは公表値より大きく振れます。エージェント無効・監視・遮断の3条件で負荷試験を流し、95パーセンタイル値とGC停止時間を比較してから本番へ入れてください。

RASPとIASTは何が違いますか？

計装の技術はほぼ同じですが、目的と稼働先が分かれます。IASTはテスト環境で動き、脆弱性を見つけて修正チケットを作る検査ツール。RASPは本番環境で動き、攻撃を検知して止める防御ツールです。同一ベンダーが設定切り替えで両方を提供する例もあるため、「どちらのモードで買うのか」を明確にしてから見積もりを比較してください。

RASPの導入にはどれくらいの期間がかかりますか？

エージェントを差し込んで検知が上がるところまでなら1日で終わります。時間がかかるのはその先。監視モードでの検知イベントの仕分けに2〜4週間、除外ルールの整備と遮断モードへの段階切り替えにさらに数週間かかります。負荷試験と切り戻し手順の検証まで含めると、本番で遮断を有効化するまで2〜3か月が現実的な計画です。

ソースコードが手元にないアプリでもRASPは導入できますか？

導入できます。RASPはコンパイル済みのバイトコードをロード時に書き換える方式のため、ソースコードは不要。この性質こそが、改修できないレガシーアプリでRASPが選ばれる理由です。ただし起動設定を変更する権限と、再起動を実施できる運用体制は要ります。保守契約で構成変更が禁じられている場合は事前に保守元へ確認してください。

関連記事

• WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説：併用する境界側の選定基準
• IASTとは？SAST・DASTとの違いと実行時検査の実装・導入判断を実装視点で解説：同じ計装を検査側で使う設計
• SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説：出荷前にコード側で塞ぐ工程
• DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説：擬似攻撃を投げる検査
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：外注時の費用感と進め方