アプリがエラーを吐いている。原因を調べなくちゃ
でもログが大量すぎてどこを見ればいいかわからない
システムを運用していると、こういう場面に遭遇したことはありませんか？
ログファイルをダウンロードしてgrepで検索する、Excelに貼り付けて目で追う
そんなアナログな方法では追いつかない規模のログを扱うことも今では珍しくありません。
AWSにはこの問題を解決するサービスがあります。それは、Amazon CloudWatch Logs Insightsです。
2026年5月、このサービスに13個の新しいコマンド・関数が追加されました。
今回の記事では、新機能の紹介だけでなく「そもそもどう使うの？」という基本的な使い方も合わせて解説していきます。
CloudWatch Logs Insightsとは何か ログをSQLライクに検索・集計できるサービス
Amazon CloudWatch Logsは、AWSのさまざまなサービス（Lambda、EC2、ECS、API Gatewayなど）が出力するログを一か所に集めて保管するサービスです。
そしてその中に蓄積されたログを、専用のクエリ言語を使って検索・集計・可視化できるのがCloudWatch Logs Insightsです。
「クエリ言語」というとSQLが思い浮かぶと思いますが、Logs InsightsのクエリはまさにSQLに似た独自構文です。
SELECT・WHERE・GROUP BYに相当する操作を、シンプルな記法で書くことが可能です。
使い方は簡単。
AWSコンソールのCloudWatchのメニューから「Logs Insights」を開くと、クエリを入力してログを検索する画面が表示されます。
追加料金なしで利用でき（スキャンしたデータ量に応じた課金のみ）、複数のロググループをまたいで同時に検索することもできます。
普段使いで覚えておきたいCloudWatch Logs Insightsの基本クエリ
新機能の前に、日常的なトラブル調査や運用で実際によく使うクエリを整理しておきましょう。
「Logs Insightsはあまり使ったことないかも」という方の参考になれば幸いです。
エラーログだけを時系列で抽出する
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 100最もよく使う基本形です。
filterでERRORという文字を含むログだけを絞り込み、新しい順に並べて100件表示します。
インシデント発生時には、まずこれを実行してエラーの発生状況を把握するのが定番です。
時間帯ごとのエラー件数を集計する
filter @message like /ERROR/
| stats count(*) as errorCount by bin(5m)
| sort @timestamp ascstatsとbinを使って5分単位でエラー件数を集計します。
「どの時間帯にエラーが急増したか」を把握するのに便利です。
グラフ表示に切り替えると視覚的にスパイクを確認できます。
Lambdaの実行時間・メモリ使用量を集計する
filter @type = "REPORT"
| stats avg(@duration), max(@duration), avg(@maxMemoryUsed) by bin(1h)LambdaのログにはREPORTという実行サマリが自動で記録されます。
このクエリで1時間ごとの平均・最大実行時間とメモリ使用量を確認することができます。
Lambdaのタイムアウトやメモリ不足を事前に察知するのに役立ちます。
特定ユーザーIDのログを追跡する
fields @timestamp, @message
| filter @message like /user_id: 12345/
| sort @timestamp asc例えば「このユーザーだけがエラーになっている」という問い合わせを受けたとき、該当ユーザーIDでフィルタして処理の流れを時系列で追えます。
ログにユーザーIDや注文IDなどを出力する習慣をつけておくと、この種の調査が格段にやりやすくなります。
2026年5月追加の新関数13個 何ができるようになったか
今回追加された13個のコマンド・関数は、3つのカテゴリに分かれています。
文字列・数値関数（6個）
文字列や数値の処理に使う関数が追加されました。
| 関数名 | できること |
|---|---|
| startswith | 文字列が指定した文字で始まるかチェック |
| endswith | 文字列が指定した文字で終わるかチェック |
| round | 数値を指定した桁数で四捨五入 |
| case | 条件に応じて返す値を分岐（SQLのCASE式と同じ） |
| regex_replace | 正規表現にマッチした部分を別の文字列に置換 |
| haversine | 緯度・経度から2点間の距離を計算 |
日常的なログ調査で特に使いやすいのはstartswithとendswithではないでしょうか。
たとえば
といった使い方ができそうです。
caseはSQLを使ったことがある方には馴染みやすい構文ですね。
「ステータスコードが200なら’成功’、400台なら’クライアントエラー’、500台なら’サーバーエラー’」のように、数値や文字列をわかりやすいラベルに変換してから集計する使い方が便利です。
haversineは位置情報を扱うシステム特有の関数です。
GPSの緯度・経度データをログに記録している場合に、2地点間の直線距離をクエリの中で計算できます。
エンコード・デコード関数（4個）
| 関数名 | できること |
|---|---|
| urlencode | 文字列をURLエンコード形式に変換 |
| urldecode | URLエンコードされた文字列を元に戻す |
| base64encode | 文字列をBase64形式にエンコード |
| base64decode | Base64エンコードされた文字列をデコード |
この4つのうち特に実用的なのがbase64decodeではないでしょうか。
AWSのサービスはJWTトークンやペイロードをBase64でエンコードした状態でログに記録することがあります。
これまではログからBase64文字列をコピーして別ツールでデコードする手間がありましたが、base64decodeがあればクエリ内でその場でデコードして中身を確認できます。嬉しいですね。
urldecodeも同様に、URLエンコードされたクエリパラメータをログから読み取るときに便利です。
例えば、「%E3%81%82」のような文字列がちゃんと「あ」と読めるようになります。
解析・分析コマンド（3個）
| コマンド名 | できること |
|---|---|
| parse logfmt | logfmt形式の構造化ログをフィールドに分解 |
| expand | JSONの配列の各要素を個別レコードとして展開 |
| relevantfields | クエリに関連するフィールドだけを自動で絞り込む |
parse logfmtは、key=value形式で構造化されたlogfmtというログフォーマットを扱うためのコマンドです。
GoやRustで書かれたアプリケーションのログはlogfmt形式が多く、これまではparse文で手動パースする必要がありました。
それを専用コマンドで一発で分解してくれます。
expandはJSONのネストされた配列を扱う場面で役立ちそうです。
「1つのログエントリに複数の商品情報が配列で入っている」といったケースで、配列の各要素を個別のレコードとして展開して集計できます。
relevantfieldsは少し毛色が違い、クエリの文脈から自動的に関連するフィールドだけを選んでくれるコマンドです。
フィールドが多いJSONログを扱うとき、毎回fieldsで列を指定しなくてもよくなるので、これも便利ですね。
新関数を使った実践的なクエリ例
新しく追加された関数を使った、実践的なクエリをいくつか見てみましょう。
APIパスのプレフィックスでエラーを分類する（startswith + case）
fields @timestamp, @message
| filter @message like /ERROR/
| parse @message /path=(?P<path>\S+)/
| fields case(
startswith(path, "/api/user"), "ユーザー系API",
startswith(path, "/api/order"), "注文系API",
true, "その他"
) as apiCategory
| stats count(*) by apiCategoryどのAPIパスでエラーが多いかを分類して集計できます。
エラーの多い領域を素早く特定するのに役立ちそうです。
Base64ペイロードをその場でデコードして確認する（base64decode）
fields @timestamp
| parse @message /payload=(?P<encoded>[A-Za-z0-9+/=]+)/
| fields base64decode(encoded) as decodedPayload
| limit 20ログに記録されたBase64ペイロードをコピペして別ツールで確認する手間がなくなります。
セキュリティ調査やAPIのデバッグ時に特に便利でしょう。
CloudWatch Logs Insightsを使いこなすと運用品質が上がる理由
CloudWatch Logs Insightsの強みは、ログの保管場所と分析ツールが同じサービスの中にあることです。
といった別サービスとの連携も選択肢としてありますが、Logs Insightsであれば追加のデータ移動なしにその場で分析を始められます。
特に「障害発生時に1秒でも早く原因を特定する」という用途では、ツールを切り替える手間なくAWSコンソールから直接クエリを実行できる手軽さは非常にありがたいですよね。
今回の13関数追加で、これまでは別ツールに頼らざるを得なかった処理（Base64デコード、logfmtパース、条件分岐）がLogs Insights内で完結するようになりました。
AWSを使ってシステムを運用している方であれば、Logs Insightsを「困ったときだけ使う調査ツール」としてではなく、定期的なパフォーマンス確認や異常検知の習慣的なツールとして取り入れてみてはいかがでしょうか？
基本的なクエリをいくつか手元に持っておくだけで、トラブル対応のスピードがぐっと上がりそうです。
AWSを基礎から学ぶなら、RaiseTechが近道！
