CloudWatch Logs Insightsに追加された新コマンド・関数23個を検証してみた（2026年6月版）

はじめに

2026年6月8日、Amazon CloudWatch Logs Insightsに23個の新コマンド・関数が追加されました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-cloudwatch-logs-insights-new/

前回の記事では5月21日発表の13個を紹介しましたが、わずか1か月足らずで更に大幅な追加です。

https://dev.classmethod.jp/articles/cloudwatch-logs-insights-new-commands-functions-2026/

5月と6月で追加された機能の傾向を比較すると、クエリ言語としての方向性が見えてきます。

5月が「ログを読みやすくする」機能群だったのに対し、6月は「ログから答えを出す」機能群と言えます。

今回追加された新機能の一覧は以下のとおりです。

※ 公式は「23 new query commands and functions」としています。上記はparse CSV/XML/multi等を個別に展開しているため項目数が前後します。公式は構文拡張等をまとめてカウントしており、本記事では公式の「23」をそのまま使用します。

本記事ではこれらを実際に動かし、動作結果を確認していきます。

検証環境

• リージョン： us-east-1
• ロググループ： /test/insights-new-2026-06
• テストデータ： JSON形式、CSV形式、XML形式、時系列データ。架空のユーザーID・サービス名・IPアドレスを使用しています（IPはRFC 5737 TEST-NET、RFC 1918プライベート範囲、8.8.8.8等の公知アドレスで構成）

ハッシュ関数（md5, sha256）

md5 と sha256 はフィールドの値からハッシュ値を生成する関数です。ログ内のユーザーIDなどをハッシュ化して表示したい場合に使えます。

fields user_id, md5(user_id) as md5_hash, sha256(user_id) as sha256_hash
| limit 3

md5は128bit（16進32文字）、sha256は256bit（16進64文字）の文字列が返されました。

文字列関数（strcontains, split）

split

split は文字列を指定した区切り文字で配列に分割します。

fields tags, split(tags, ',') as tag_array
| limit 3

カンマ区切りのタグ文字列が配列形式（["prod","warning","us-east-1"]）で展開されました。

strcontains

strcontains は文字列に特定の部分文字列が含まれるかを判定します。ドキュメントでは第3引数に true を指定するとcase-insensitive（大文字小文字を区別しない）検索になるとされています。

fields service,
  strcontains(service, 'auth') as has_auth_lower,
  strcontains(service, 'AUTH') as has_AUTH_upper,
  strcontains(service, 'AUTH', true) as has_AUTH_ci
| filter ispresent(service)
| sort service
| limit 5

基本動作（第1・第2引数のみ）は正常です。auth-service に対して strcontains(service, 'auth') が 1 を返しています。

しかし、筆者環境では第3引数 true（case-insensitive モード）の効果を確認できませんでした。strcontains(service, 'AUTH', true) は auth-service に対して 0 を返しており、大文字小文字を区別したまま動作しているように見えました。引数自体はシンタックスエラーにならず受け付けられましたが、指定しても結果は変わりませんでした。

条件ロジック（if）

if は条件に基づいて値を返す関数です。if(条件, 真の場合の値, 偽の場合の値) の構文で、三項演算子のように使えます。

fields service, response_time,
  if(toNumber(response_time) > 1000, 'slow', 'fast') as speed
| limit 5

レスポンスタイムが1000msを超えるリクエストを slow と分類できました。

前回（5月）追加の case 関数との使い分けとしては、if は単一条件の二択、case は多分岐に適しています。

変換関数（toNumber, toInt, toLong, toDouble）

文字列フィールドを数値型に変換する関数が4種類追加されました。それぞれの型変換の違いを確認します。

整数値の変換

fields response_time,
  toInt(response_time) as rt_int,
  toLong(response_time) as rt_long,
  toDouble(response_time) as rt_double,
  toNumber(response_time) as rt_number
| filter ispresent(response_time)
| limit 5

整数値の場合は4関数とも同じ結果でした。変換に失敗した場合（not_a_number）はエラーにならずnullが返ります。

小数値の変換（型の違いが顕著）

parse @message /latency=(?<lat_val>[\d.]+)/
| display lat_val,
    toInt(lat_val) as lat_int,
    toLong(lat_val) as lat_long,
    toDouble(lat_val) as lat_double,
    toNumber(lat_val) as lat_number
| filter ispresent(lat_val)

小数を含む値で違いが現れました。

• toInt / toLong: 小数点以下を切り捨てました（正の値のみ検証。負数でのfloor vs truncateの挙動は未確認です）
• toDouble / toNumber: 小数点以下を保持し、今回の検証範囲では同様の結果でした
• 型名からは、toIntとtoLongの差は32bit整数の範囲（約21億）を超える値などで現れる可能性がありますが、今回のテストデータでは差を確認できませんでした

用途としては、小数精度が不要な集計には toInt/toLong、小数を保持したい計算には toDouble/toNumber を使い分けることになります。

IP関数（ipv4ToNumber, isPrivateIP, isPublicIP, isReservedIP）

IPアドレスの数値変換と分類判定を行う4つの関数が追加されました。VPCフローログやALBアクセスログの分析に便利です。

fields ip,
  ipv4ToNumber(ip) as ip_num,
  isPrivateIP(ip) as is_private,
  isPublicIP(ip) as is_public,
  isReservedIP(ip) as is_reserved
| limit 10

※ パブリックIPの一部は下位オクテットをマスクしています（実際の検証では完全なIPアドレスを使用）。

今回用意したIPアドレスについては、期待した分類結果になることを確認できました。結果から読み取れる分類基準は以下のとおりです。

• Private（isPrivateIP = 1）: RFC 1918で定義されたプライベートアドレス範囲
  • 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16
• Reserved（isReservedIP = 1）: 特殊用途に予約されたアドレス範囲
  • 169.254.0.0/16（リンクローカル）、100.64.0.0/10（CGN / Shared Address）
  • 192.0.2.0/24（TEST-NET-1）、203.0.113.0/24（TEST-NET-3）
• Public（isPublicIP = 1）: 今回試した範囲では、Private / Reservedに該当しない一般的なパブリックIPアドレスが 1 と判定されました

今回検証したIPv4アドレスの範囲では、3つの分類のいずれか1つだけが 1 になり、排他的な関係でした。ipv4ToNumber はIPアドレスを32bit整数に変換する関数です。IPレンジによるフィルタリング（ipv4ToNumber(ip) >= X and ipv4ToNumber(ip) <= Y）に活用できます。

分析関数（rate, count_over_time, sum_over_time, offset, histogram）

時系列データの分析に関連する5つの機能が追加されました。

count_over_time

count_over_time は時間範囲ごとのレコード数をカウントします。

filter metric = 'cpu_usage'
| stats count_over_time(*) as cot by bin(2m)

今回のbin集計条件では count(*) と同等の結果でした。

sum_over_time

sum_over_time は時間範囲ごとの合計値を算出します。

filter metric = 'cpu_usage'
| stats sum_over_time(value) as sot by bin(2m)

こちらも sum(value) と同等の結果でした。count_over_time/sum_over_time は時系列分析向けの命名と見られます。ただし今回のbin集計条件では count(*)/sum() との動作の違いを確認できず、完全に同じ動作かどうかは断定できません。

histogram

histogram は by 句のグルーピング関数として使い、数値フィールドをバケットに分けて集計します。

filter metric = 'cpu_usage'
| stats count(*) as cnt by histogram(value, 50)

第2引数がバケット幅で、結果にはバケットの下限値が表示されます。バケット幅を25に変更すると、より細かい分布が見えます。

filter metric = 'cpu_usage'
| stats count(*) as cnt by histogram(value, 25)

histogram は stats の集計関数ではなく by 句のグルーピング関数である点に注意してください。bin が時間軸のバケット化なのに対し、histogram は数値軸のバケット化です。

offset

offset は bin() の修飾子で、bin境界のアライメント（開始位置）をずらします。

filter metric = 'cpu_usage'
| stats count(*) as cnt by bin(5m) offset 5m

構文は by bin(5m) offset 5m のようにbinの後ろに付けます。関数ではなく修飾子です。offset を使うとbin境界の開始位置をずらせるため、業務時間帯に合わせた集計区切りを設定できます。

rate

rate はbin内の数値フィールドの変化率を算出する関数です。rate(field, period) の構文で、第2引数に時間単位（1s, 1m, 2m 等）を指定します。

filter metric = 'cpu_usage'
| stats rate(value, 1s) as rate_1s, rate(value, 1m) as rate_1m, rate(value, 2m) as rate_2m by bin(5m)

テストデータは2分間隔で値が+10ずつ増加する時系列です。結果から、periodによる値の比率は rate_1s : rate_1m : rate_2m = 60 : 1 : 0.5 でした。rate はbin内のフィールド値の合計変化量をperiodの秒数で割った値を返しています。periodが短いほど大きい値になります。

なお、第2引数に数値（60）を指定するとエラーになります。1m のような時間単位で指定する必要があります。

パース構文（parse CSV, parse XML, parse multi, values, addtotals）

ログのパース機能が大幅に拡張されました。CSV、XML、複数マッチの3つの新しいパースモードと、集計補助の values・addtotals が追加されています。

parse CSV

parse @message CSV as alias1, alias2, ... の構文でCSV形式のログを列ごとに分割します。

filter @logStream = 'test-csv-stream'
| parse @message CSV as ts, lvl, svc, val
| display ts, lvl, svc, val

カンマ区切りの各値が順番にエイリアスへ格納されました。ヘッダー行とデータ行の区別はなく、全行がパース対象です。

parse XML

XML形式のログは、XPath風のパス式でフィールドを抽出します。

filter @message like /<event>/
| parse @message XML '/event/level' as xlevel
| parse @message XML '/event/service' as xsvc
| parse @message XML '/event/code' as xcode
| display xlevel, xsvc, xcode

構文は parse @message XML '/要素/パス' as alias です。今回確認した範囲では /event/level のような単純な要素パスで値を取得できました。parse @message XML as doc のようなドキュメントオブジェクト全体の取得やドット記法でのアクセスはエラーになりました。複数フィールドを抽出する場合は、上記のように parse を複数回パイプして使用します。

parse multi

parse multi は正規表現の1行内の全マッチを個別レコードに展開します。key=value形式のログパースに威力を発揮します。

filter @message like /^level=/
| parse @message /(?<kname>\w+)=(?<kval>\S+)/ multi
| stats count(*) by kname

元データは3行で、各行に4つのkey=valueペアがあります。multi を付けることで3行 × 4ペア = 12レコードに展開され、キー名ごとの集計ができました。

multi なしの場合は1行につき最初のマッチのみが抽出されます。

parse @message /(?<kname>\w+)=(?<kval>\S+)/
| display kname, kval

今回試した正規表現ベースの parse multi では、名前付きキャプチャグループ (?<name>...) を使うことで期待通りに抽出できました。一方、ドキュメントに記載のある as alias multi 構文は筆者環境ではシンタックスエラーになりました。

values

values はグループごとの重複なし（distinct）の値をまとめて返す集計関数です。

filter ispresent(service) and ispresent(level)
| stats values(service) as services by level

今回のAPI結果ではカンマ区切りの文字列表現として確認できました。グループ内の一意な値を一覧する場合に便利です。

addtotals

addtotals は各行の数値フィールドを合計した列を追加するコマンドです。なお、表示されている列だけでなくクエリ中に存在する全数値フィールドも合算対象になるため、表示列の単純合計と Total の値は一致しないことがあります。

filter ispresent(response_time)
| fields toNumber(response_time) as rt, toNumber(response_time) * 2 as rt2
| addtotals
| limit 5

デフォルトでは Total という列名で行合計が追加されます。addtotals fieldname=RowSum で列名をカスタマイズ可能です。

col=true を指定すると列合計行も追加されるはずですが、get-query-results APIのレスポンスには列合計行は含まれませんでした。コンソールUIでのみ表示される可能性があります。

その他（limit any, statsコマンド最大10段）

limit any

limit any は順序保証なしに任意のN件を返す構文です。通常の limit が直前の sort 順（未指定時はタイムスタンプ降順と見られる動作）で先頭N件を返すのに対し、limit any は順序が不要な場合により早く結果を得られる可能性があります。

fields service, level, ip | limit any 2

大量のログがあるロググループで素早くサンプルを取得したい場合に有用です。

statsコマンド最大10段

stats をパイプで複数回つなげられる範囲が拡張され、Standard log classでは最大10段まで使用できるようになりました。

filter ispresent(service)
| stats count(*) as cnt by service, level
| stats sum(cnt) as level_total by level
| stats max(level_total) as max_level_total, min(level_total) as min_level_total

3段のstatsをパイプで接続しています。1段目でサービス×レベルごとのカウント、2段目でレベルごとの合計、3段目で最大・最小を算出しました。

ドキュメントによると、Standard log classでは最大10段、Infrequent Access log classでは最大2段まで使用可能です。後続の stats では前段で定義したフィールドのみ参照可能で、sort や limit は最後の stats の後に配置する必要があります。

実用的な例として、時間帯ごとのメッセージ文字数の集計から傾向を把握するパターンを紹介します。

fields strlen(@message) as msg_len
| stats sum(msg_len) as total_chars by bin(5m)
| stats max(total_chars) as peak, min(total_chars) as lowest, avg(total_chars) as average

5分ごとのメッセージ文字数の合計を算出し、その中からピーク・最小・平均を取得しています。ログがASCII中心であれば、おおよそのメッセージサイズ傾向を見る用途にも使えます。このような「集計結果をさらに集計する」パターンが1クエリで完結するようになりました。

まとめ

5月に13個、6月に23個と、CloudWatch Logs Insightsのクエリ言語は短期間で大きく拡充されています。

今回追加された機能では、IP分類、CSV/XMLパース、histogram、複数段の stats などが含まれていました。ログを検索するだけでなく、集計・判定・傾向把握までクエリ内で行いやすくなっています。検証した範囲では、従来Athenaや外部ツールで後処理していたような分析の一部も、Logs Insightsだけで完結できる場面が増えそうです。

一方で、記事執筆時点の筆者環境では、strcontains の第3引数によるcase-insensitive検索は期待通りに動作しませんでした。

CloudWatch Logs Insightsは、「ログを検索・確認するツール」から、より分析用途にも使いやすいクエリ環境へと進化している印象です。今回の追加により、日々の調査や一時分析で使える場面がさらに広がりそうです。

参考リンク

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html