従来のレイヤー7トラフィック管理は通常、URL、メソッド、ヘッダー、ソースアドレスで決定します。そのモデルはクラシックなWebアプリケーションには十分なことが多いですが、モダンなAPIアーキテクチャでは重要な区別が通常リクエストボディ内のフィールドにあります。テナントID、ユーザーロール、トランザクションタイプ、サービス名、またはファイルアップロードのメタデータはヘッダーにはなく、JSON、XML、フォーム、マルチパートのペイロードにあります。
その可視性なしには、オペレーターは悪い選択肢に追い込まれます。トラフィック管理の前に追加のAPIゲートウェイを配置するか（新たなホップ、ライセンス、運用負担が増える）、決定値をヘッダーに持ち上げるためにアプリケーション自体を変更するかです。レガシーおよびビジネスクリティカルなバックエンドにとって、その変更はしばしば実行不可能です。
ボディ検査をセキュリティのみに限定しても問題は解決しません。WAAPがコンテンツを読めてもルーティングエンジンが同じ値を使用できなければ、セキュリティポリシーとトラフィックポリシーが二つの別々の世界になります。その結果、ロジックの重複、一貫性のないルール、エラーのリスク増大が生じます。
正しいモデルは、ボディパーサー機能をルール言語のネイティブな部分にすることです。JSONPath、XPath、フォームパラメータ、JWTクレーム、正規表現、マップ/リストチェックが同じ式ツリーに共存し、単一の式がトラフィックアクションとWAAPスコアの両方を制御すべきです。
TR7コンテンツ認識ルールはこのギャップを埋めます：ボディ内のフィールドは単なる検査データではなく、決定を直接制御するシグナルになります。
TR7はコンテンツ認識を別のアドオンとしてではなく、トラフィックとセキュリティのルール言語のネイティブな部分として扱います。
JSONQUERY、XMLQUERY、XMLPATHEXISTS、PARAM、JWTHEADER、JWTPAYLOADはルール言語の一級関数です。オペレーターはカスタムコードを書くことなくボディコンテンツを条件に変換し、それらの条件を直接トラフィックまたはセキュリティアクションに結びつけます。
JSON、XML、マルチパートのペイロードはランタイムで解析され、読み取り可能な値としてルールエンジンに提供されます。オペレーターはリクエストのすべてのバイトに対して粗いregexを実行するのではなく、意味のあるフィールドで決定します。
TR7では、ボディフィールドに対して書かれた式がルーティング、ヘッダー操作、WAAPシグネチャスコアリングのいずれも制御できます。この共有モデルにより、トラフィックルールとセキュリティルール間のロジックの重複が削減されます。
ADCモードではボディを読み取り、適切なシナリオではレスポンス側で書き換えることができます。WAAPモードではボディは決して変更されません — 読み取られ、スコアリングされ、ポリシー閾値を超えるとブロックされます。
コンテンツ認識ルールは構造化されたペイロードデータを読み取り可能な条件と強制可能なアクションに変換します。
JSONQUERY関数は標準JSONPathセマンティクスを使用してJSONボディフィールドを評価します。オペレーターは`$.user.role`、`$.items[0].sku`、`$.tenant_id`などの値を条件として使用し、vServiceルーティング、ヘッダー操作、WAAPスコアリングに結びつけられます。APIトラフィックはエンドポイントだけでなく、リクエストの実際のビジネス的意味によって制御されます。
XMLQUERY、XMLPATHTYPE、XMLPATHEXISTSはXMLボディに対してXPathクエリを実行します。SOAPエンベロープ内のサービス名、アクションノード、オペレーションフィールドがルーティングとセキュリティの決定を制御できます。これはレガシーバックエンドを変更せずにサービスレベルのディスパッチとポリシーを適用するのに特に価値があります。XMLペイロードはルールエンジン内の構造化データになり、脆弱な正規表現への依存が減ります。
PARAM関数はクエリ文字列、フォームエンコードされたボディ、フォームフィールドをルール条件に変換します。マルチパートパーサーはファイルアップロードのメタデータ（フィールド名、コンテンツタイプ、サイズ）をポリシーに提供します。このパターンはSaaSポータル、ドキュメントアップロードフロー、ユーザー固有のトランザクションロジックに役立ちます。フォームが持つビジネスコンテキストに基づいてトラフィックをルーティングまたはブロックできます。
JWTHEADERとJWTPAYLOADはトークンのヘッダーとペイロードフィールドをJSONPathクエリ可能な値として提供します。ユーザーロール、テナント、認可レベル、カスタムクレームがトラフィックとセキュリティの決定への入力になります。必要なクレームをエッジで強制し、クレームが欠落したリクエストを失敗させ、ロールベースのトラフィックを専用のバックエンドグループに誘導できます — アプリケーションコードにアクセスロジックを埋め込まずに済みます。
MAP_STR、MAP_REG、MAP_SUB、MAP_IP、MAP_BEG、MAP_ENDは大量の値セットに対する高速ルックアップを提供します。LIST_STR、LIST_REG、LIST_SUB、LIST_IP、LIST_BEG、LIST_ENDはリストベースのチェックに同じモデルを提供します。テナントリスト、許可サービス名、IPレンジ、パターングループを個別の条件としてではなく中央で管理でき、大規模なルールセットが維持しやすくなります。
BODY_SIZE、JSON_DEPTH、XML_DEPTH、JSON_KEY_COUNT、XML_NODE_COUNTはパーサーが動作する前に保護的な制限を定義します。サイズが大きすぎる、深くネストされた、または膨張したペイロードはバックエンドに到達する前に拒否されます。JSON_DEPTHのデフォルトは32でポリシーレベルで調整可能です。同じ制御がリソース消費とパーサーレベルの悪用の両方を管理します。
JSON_MUST_ARGS、JSON_ALLOWED_ARGS、FORM_MUST_ARGS、FORM_ALLOWED_ARGSは期待されるフィールドの存在と予期しないフィールドの不在を検証します。悪いパターンを検索するだけでなく、受け入れ可能なリクエストの形状を宣言するモデルです。必要なフィールドの欠落や予期しないパラメータをポリシーごとに拒否できます。このコントラクト認識アプローチは重要なトランザクションエンドポイントで特に価値があります。
ADCモードでは、modifyResponseアクションがレスポンスボディに正規表現ベースの置換を適用します。個人データのマスキング、リンクの書き換え、外部利用者向けの内部アドレスの適応に使用されます。WAAPモードではボディは決して変更されません — 読み取りとスコアリングのみです。この分離により、同一プラットフォームでトラフィックの柔軟性とセキュリティの整合性が両立します。
コンテンツ認識はルール構文だけではなく、バッファ管理、パースキャッシング、監査の可視性、エッジケースの動作もカバーします。
ボディコンテンツはパース前にバッファリングされ、関連するJSON、XML、またはマルチパートパーサーがそのバッファで実行されます。デフォルトのボディバッファは16 KBで、より大きなJSONまたはXMLペイロード用にシステムパラメータを引き上げることができます。制限を超えると、リクエストは413で拒否され、バックエンドは過大なペイロードを受け取りません。
同一リクエスト内で読み取られたJSONPathとXPathの結果はトランザクションスコープの変数スペースにキャッシュされます。あるルールがボディフィールドを読み取ると、後続のルールは同じフィールドでパーサーを再実行しません。これにより、長いルールチェーンにおけるレイテンシと処理コストが削減されます。
WAAPモードではボディは読み取られますが決して変更されません。コンテンツはシグネチャ、スコアリング、閾値ロジックに供給されます；閾値を超えるとリクエストはブロックされます。セキュリティ層はリクエストの整合性をエンドツーエンドで保持しながらコンテンツ認識シグナルに基づいて動作できます。
チャンクされたPOSTリクエストのパースはチャンク再組み立て完了後に開始されるため、ボディフィールドは完全で一貫したペイロードとして評価されます。チャンクトラフィックは若干の追加レイテンシが発生する場合がありますが、バックエンドは部分的で制御されていないペイロードストリームから保護されます。
GraphQLは現在JSONPathを通じて処理されています：ボディ内のオペレーション名やフィールドリストなどのフィールドをルール条件に使用できます。これにより、ミューテーションとクエリの分割などの実用的なエッジ決定が可能になります。ディープスキーマ検証はこの機能のスコープ外です。
どのルールがどのボディフィールドを読み取ったかが監査ログに記録されます。運用チームは特定のリクエストがなぜルーティング、拒否、またはスコアリングされたかをSIEMでトレースできます。このトレーサビリティにより、コンテンツ認識ルールがブラックボックスのように動作するのを防ぎます。
SaaSチームはJSONボディ内のtenant_idフィールドに基づいて別々のバックエンドプールにトラフィックを振り分けられます。テナントの分離はアプリケーションコードを変更せずに実現でき、トラフィックポリシーはエッジで管理されます。
銀行や政府のシステムでは、XMLエンベロープ内のアクションノードが異なるサービスグループへのディスパッチを制御できます。レガシーサービスコントラクトを維持しながら、トラフィック決定がコンテンツ認識になります。
エンジニアリングチームはoperationNameフィールドに基づいてクエリとミューテーションを別々のソースに誘導できます。読み取り重視と書き込み重視のオペレーションが専用のバックエンドグループに配置されます。
重要なアプリケーションでは、JWTペイロード内のロールとテナントクレームをエッジで強制できます。必要なクレームが欠落したリクエストはバックエンドに到達せず、有効なクレームを持つリクエストは適切なトラフィックポリシーの下に配置されます。
JSON、XML、マルチパート、JWTフィールドにわたるコンテンツ認識ルーティングとセキュリティ。お客様自身のサービスでのライブセットアップをご案内します。