2026年5月23日 AWS アップデート情報
はじめに
2026年5月23日、AWSは9件のアップデートを発表しました。本日は、マイグレーション評価の高度化、SageMakerのドメイン管理・ガバナンス強化、セキュリティ運用の自動化、そしてログ分析機能の大幅拡張など、エンタープライズ運用の効率化に直結するアップデートが多数含まれています。
特に注目すべきは、Amazon CloudWatch Logs Insights に追加された13個の新しいコマンドと関数です。これにより、ログ分析の表現力が大きく向上し、従来は前処理が必要だった複雑な解析がクエリ内で完結できるようになります。また、AWS Security Agent がペネトレーションテストの検証スクリプトを自動生成する機能も追加され、セキュリティチームの負荷軽減と対応スピード向上が期待できます。
本記事では、これらの中から特に実務インパクトの大きいアップデートを深掘りし、SRE視点での活用ポイントを解説します。
注目アップデート深掘り
Amazon CloudWatch Logs Insights の新クエリコマンド・関数
Amazon CloudWatch Logs Insights のクエリ言語に、13個の新しいコマンドと関数が追加されました。これにより、ログ分析の柔軟性と表現力が大幅に向上します。
なぜこのアップデートが重要なのか
従来、CloudWatch Logs Insights では基本的な文字列操作や数値演算は可能でしたが、Base64エンコードされたペイロードの解析や、logfmt形式のログパース、ネストされたJSON配列の展開などは、事前にLambdaやログ送信側での変換処理が必要でした。今回の機能追加により、クエリ実行時にその場で高度な変換・解析が可能となり、ログ基盤の設計がシンプルになります。
追加された機能カテゴリ
新機能は以下の3つのカテゴリに分類されます。
1. 文字列・数値関数
startswith/endswith：文字列の接頭辞・接尾辞チェックcase：条件分岐による値の変換regex_replace：正規表現による文字列置換round：数値の四捨五入haversine：GPS座標から距離計算
2. エンコード/デコード関数
base64encode/base64decode：Base64エンコード/デコードurlencode/urldecode：URLエンコード/デコード
3. 解析・分析コマンド
parse logfmt：logfmt形式のログを自動パースexpand：JSON配列を個別レコードに展開relevantfields：高カーディナリティログから重要フィールドを自動抽出
実践例：Base64デコードとlogfmt解析
API Gatewayのアクセスログで、リクエストボディがBase64エンコードされている場合の解析例です。
fields @timestamp, requestId, base64decode(requestBody) as decodedBody
| filter statusCode >= 500
| parse decodedBody "user_id=* action=* result=*" as userId, action, result
| stats count() by userId, action
従来は別途Lambda関数でデコード処理を挟む必要がありましたが、クエリ内で直接デコードできるようになりました。
logfmt形式（key1=value1 key2=value2形式）のログを解析する例：
fields @timestamp, @message
| parse logfmt @message
| filter status="error"
| stats count() by service, error_code
parse logfmtコマンドが自動的にキー・バリューペアをフィールドとして展開するため、スキーマ定義なしで構造化ログとして扱えます。
地理的距離計算の活用
haversine関数を使えば、GPS座標からの距離計算がクエリ内で可能です。配送業務やIoTデバイスの移動分析に有用です。
fields @timestamp, deviceId, latitude, longitude
| sort @timestamp asc
| fields deviceId,
haversine(latitude, longitude,
lag(latitude, 1), lag(lag(longitude, 1), 1)) as distance_km
| stats sum(distance_km) as total_distance by deviceId
このクエリは、各デバイスの連続した位置情報から移動距離を計算し、デバイスごとの総移動距離を算出します。
配列展開による詳細分析
ネストされたJSON配列を個別レコードに展開することで、配列内の各要素を個別に分析できます。
fields @timestamp, requestId, items
| expand items as item
| fields @timestamp, requestId, item.productId, item.quantity, item.price
| stats sum(item.quantity) as total_quantity,
sum(item.price * item.quantity) as total_amount
by item.productId
従来はアプリケーション側で配列を展開してログ出力する必要がありましたが、元のログ構造を保ったまま柔軟に分析できるようになりました。
AWS Security Agent の検証スクリプト自動生成
AWS Security Agent がペネトレーションテストの検出結果に対する検証スクリプトを自動生成する機能を追加しました。
背景：セキュリティ検証の課題
セキュリティチームがペネトレーションテストを実施した際、検出された脆弱性が実際に悪用可能かを検証するには、レポートに記載された再現手順を手動で実行する必要がありました。この作業は以下の課題を抱えていました。
- 手順書の解釈ミスによる検証失敗
- 環境固有のパラメータ設定の煩雑さ
- 機密情報（トークン、パスワード等）の取り扱いリスク
- 複数の検出結果を検証する際の時間コスト
新機能の仕組み
AWS Security Agent は、各検出結果に対して実行可能なスクリプトを自動生成します。生成されたスクリプトには以下が含まれます。
- セットアップ手順：必要なツールや依存関係のインストール方法
- ドキュメント化された環境変数：対象システムのエンドポイント、認証情報などをパラメータ化
- 機密値のマスキング処理：パスワードやAPIキーが平文で保存されない仕組み
利用フロー
AWS の発表では、AWS Security Agent コンソールでペネトレーションテストを実行し、検出された各 finding の Verification Script セクションを展開してスクリプトをダウンロードする流れが示されています。具体的な CLI コマンド名やオプションは AWS Security Agent ユーザーガイド側の記述を確認してください。
利用フローのイメージは次の通りです。
- AWS Security Agent コンソールで対象の finding を開き、Verification Script セクションからスクリプトをダウンロード
- スクリプト内でドキュメント化されている環境変数（対象エンドポイント、認証情報など）を設定
- シェル等から実行し、検証結果を確認
スクリプトを CI/CD パイプラインから呼び出せば、修復後の再検証や定期的なセキュリティリグレッションテストを自動化できます。
従来手法との比較
| 項目 | 従来（手動実行） | 新機能（自動生成スクリプト） |
|---|---|---|
| 検証準備時間 | 検出結果ごとに15〜30分 | 環境変数設定のみ（5分以内） |
| 再現性 | チームメンバー間でばらつき | スクリプト化により一貫性を保証 |
| 機密情報管理 | 手順書に平文記載のリスク | 環境変数経由で安全に管理 |
| 自動化 | 困難 | CI/CDパイプライン統合可能 |
CI/CDパイプラインへの統合方針
検証スクリプトはダウンロード後にローカルや CI ランナーから実行できるため、以下のような運用が考えられます。
- ステージング環境向けに環境変数（エンドポイント、トークン等）を Secret Manager / CI 変数で管理し、スケジュールジョブから呼び出す
- 実行ログとリターンコードを集約し、JUnit などの形式に整形してダッシュボード化する
- インフラ変更（Terraform / CloudFormation の apply）後のステップとして組み込み、既知の脆弱性が再導入されていないかを継続的に検証する
具体的な finding ID の取得・スクリプトの配布方法は、リリース時点ではコンソール経由が中心であるため、自動化を進める際は AWS Security Agent のユーザーガイドで API/CLI 対応状況を確認することを推奨します。
AWS Clean Rooms の変更可能な支払い設定
AWS Clean Rooms が、コラボレーション内の支払い設定を後から変更可能にする機能をサポートしました。
従来の課題
AWS Clean Rooms では、複数の組織が互いにデータを共有せずに共同分析を行う「コラボレーション」を作成できますが、従来はコラボレーション作成時に誰が費用を負担するかを固定する必要がありました。これにより、以下の問題が発生していました。
- プロジェクト進行中にビジネス関係が変化しても、費用分担を調整できない
- 高コストな分析（ML推論、PySpark処理）と低コストな分析（簡易SQL）で負担者を分けられない
- 初期の試験段階と本格運用で負担者を変更したい場合、コラボレーションを再作成する必要
新機能：柔軟な費用分担
新機能では、コスト種別ごとに異なる支払者を指定でき、さらにコラボレーション作成後も変更可能です。
対応するコスト種別：
- SQL クエリ実行コスト
- PySpark ジョブ実行コスト
- ML モデルの学習・推論ジョブのコスト
- 合成データ生成コスト
なお、SQL と PySpark の分析では複数の支払者を事前登録し、分析実行時に支払者を選択できます。ML / 合成データ系のコスト種別については、変更リクエスト経由で支払者の追加・削除が行えます。
チェンジリクエストによるガバナンス
支払い設定の変更はチェンジリクエスト方式で行われ、コラボレーションメンバーの承認後に反映されます。これにより、透明性と合意形成プロセスが担保されます。
変更フロー：
- いずれかのメンバーがチェンジリクエストを作成
- コラボレーションメンバーに通知が送信される
- メンバーが承認すると変更が適用される
活用シナリオ例
シナリオ1：段階的なコスト負担の移行
製薬企業Aと医療機関Bが臨床試験データの共同分析を行う場合：
- 初期段階：製薬企業Aがすべてのコストを負担（実証実験フェーズ）
- 本格運用段階：簡易な統計分析（SQL）は医療機関Bが負担、高度なML推論は製薬企業Aが負担
この切り替えを、コラボレーションを再作成せずに実施できます。
シナリオ2：複数支払者による柔軟な運用
同じコスト種別に対して複数の支払者を事前に登録しておき、分析実行時に選択することも可能です。例えば、小売企業3社が共同でマーケット分析を行う場合：
- SQL クエリの支払者候補：企業A、企業B、企業C
- 実行時に各企業の予算状況に応じて支払者を選択
SRE視点での活用ポイント
CloudWatch Logs Insights の新機能
ログ分析は SRE の日常業務の中核であり、今回の機能追加は以下のシーンで特に効果を発揮します。
インシデント対応の高速化
障害発生時、複数のサービスにまたがるトレースログから根本原因を特定する際、Base64デコードやJSON配列の展開をクエリ内で完結できるため、調査時間を大幅に短縮できます。特に、relevantfieldsコマンドによる自動フィールド検出は、未知のログ構造を持つサードパーティサービスのログ調査で威力を発揮するでしょう。
既存ログ基盤の簡素化検討
現在、ログを構造化するためにLambda関数やFluentdでの前処理を行っている場合、新機能によりログ収集はシンプルに保ち、解析時にクエリで柔軟に処理するアーキテクチャへの移行を検討できます。これにより、ログパイプラインの複雑さとコストを削減しつつ、分析の自由度を高められます。
地理的分散システムの監視
グローバルにデプロイされたIoTデバイスやエッジコンピューティング環境では、haversine関数を活用して、デバイスの移動距離や配置状況をリアルタイムに監視できます。これをCloudWatch アラームと組み合わせれば、異常な移動パターンの検知や、サービスエリア外への逸脱検知が可能になります。
注意点とリスク
新しいクエリ関数は強力ですが、複雑なクエリはスキャンするデータ量が増加し、コストとクエリ実行時間が増大する可能性があります。本番環境で導入前に、過去のログを使用してクエリパフォーマンスを検証し、コスト影響を見積もることを推奨します。また、expandコマンドによる配列展開は、大量の配列要素を持つログで実行すると、結果セットが爆発的に増加するため、適切なフィルタ条件との併用が必須です。
AWS Security Agent の検証スクリプト自動生成
セキュリティ脆弱性の検証プロセスは、SREがセキュリティチームと連携する場面で頻繁に発生します。
ランブックへの組み込み
障害対応ランブックや緊急対応手順書に、生成された検証スクリプトを組み込むことで、誰でも一貫した手順で脆弱性を確認できるようになります。これにより、担当者による対応品質のばらつきを削減し、オンコール対応の負担を軽減できます。
DevSecOpsパイプラインの強化
Terraform や CloudFormation でインフラ変更を適用した後、自動的に検証スクリプトを実行してセキュリティリグレッションがないかを確認するステップを追加できます。これにより、インフラ変更が既知の脆弱性を再導入していないことを継続的に保証できます。
トリアージの優先順位付け
検証スクリプトを実行することで、検出結果が実際に悪用可能な脆弱性かを迅速に判断できます。これにより、誤検知を早期に排除し、真に修復が必要な項目にリソースを集中できます。
導入時の考慮事項
検証スクリプトの実行には、本番環境またはそれに近い環境へのアクセスが必要です。そのため、検証専用の隔離された環境を用意することが推奨されます。また、スクリプトが生成する通信トラフィックが、既存のセキュリティ監視（WAF、IDS/IPS）で誤検知されないよう、事前にホワイトリスト設定を調整する必要があります。
AWS Clean Rooms の支払い設定変更
データコラボレーション環境での費用管理は、複数ステークホルダーが関与するプロジェクトで重要な課題です。
コスト配分の透明性確保
SREがマルチテナント環境やパートナー連携システムを運用する場合、誰がどのリソースを使用し、どれだけのコストが発生しているかを可視化することが求められます。Clean Roomsの新機能により、分析種別ごとのコスト分担を柔軟に設計でき、各パートナーへの適切なチャージバックが可能になります。
プロジェクトフェーズごとの費用戦略
プロジェクト初期段階では、一方の組織がコストを全額負担し、成果が確認できた後に段階的に他の組織も負担するといった戦略を、コラボレーション環境を再構築せずに実現できます。これにより、初期導入のハードルを下げつつ、長期的な費用分担への移行をスムーズに行えます。
リスクと注意点
チェンジリクエストには全メンバーの承認が必要なため、意思決定プロセスが遅延するリスクがあります。事前に支払い設定変更のガバナンスルール（誰が提案できるか、承認期限はどう設定するか）をステークホルダー間で合意しておくことが重要です。また、変更履歴が適切に記録されるため、監査対応やコンプライアンス報告にも活用できます。
全アップデート一覧
まとめ
本日のアップデートは、運用効率化とガバナンス強化が主要テーマとなっています。特に、CloudWatch Logs Insights の機能拡張は、長年ユーザーから要望されていた高度なログ解析機能を提供し、ログ基盤のアーキテクチャ設計に新たな選択肢をもたらしました。
また、AWS Security Agent の検証スクリプト自動生成や、SageMaker Unified Studio の自動プロビジョニング機能は、手動作業の自動化によるヒューマンエラー削減という共通のメリットを提供します。これらは、DevOps・SREチームが「Toil（面倒な手作業）」を削減し、より戦略的な業務に集中するための重要なステップです。
一方、AWS Clean Rooms や SageMaker の新機能は、マルチアカウント・マルチテナント環境でのガバナンスを強化し、エンタープライズ規模でのデータ利活用を支援します。これらの機能は、単なる技術的な拡張ではなく、ビジネスプロセスと密接に連携した設計がなされている点が特徴です。
今後も、これらの新機能を活用した具体的なユースケースや、既存システムへの統合方法について、継続的にキャッチアップしていくことが重要です。