本ブログは 2025 年 7 月 24 日に公開された AWS Blog “ AWS Security Incident Response: The customer’s journey to accelerating the incident response lifecycle ” を翻訳したものです。 2025 年 8 月 1 日: この記事は、AWS WAF と AWS Shield への誤った言及を削除するために再公開されました。 効果的なセキュリティインシデント対応プログラムを構築し、維持するうえで、組織が直面する課題は増え続けています。 IBM と Morning Consult の調査によると、セキュリティチームは 2 つの大きな課題に直面しています。1 つは、リソースの制約とアラート疲れにより、50% を超えるセキュリティアラートが未対応のままになっていることです。もう 1 つは、誤検知 (フォールスポジティブ) が調査時間の 30% を占め、真陽性 (トゥルーポジティブ) と判定された脅威への対応が遅れていることです。 調査レポート「 2024 IBM Cost of a Data Breach Report 」によると、組織がセキュリティイベントを特定して封じ込めるまでに、平均 258 日を要していました。同レポートでは、SOC (セキュリティオペレーションセンター) チームの半数近くが、調査時点までの 2 年間で検出と対応にかかる時間が長くなったと報告しています。さらに 80% が、手動での脅威調査が対応時間に大きく影響していると回答しています。 こうした課題がある一方で、「2024 IBM Security Services Benchmark Report」によると、成熟したインシデント対応能力を持つ組織では、平均解決時間 (MTTR) が 50% 短縮され、インシデントあたり最大 58% のコスト削減を実現しています。これらの改善は、脅威の検出と封じ込めを加速する自動化されたワークフロー、統合ツール、効率化されたコミュニケーションプロセスの導入によってもたらされています。 この記事では、実環境を想定したシナリオを通じて、 AWS Security Incident Response がインシデント対応ライフサイクルのあらゆるステップを加速し、すぐに効果をもたらす仕組みを紹介します。また、 Amazon GuardDuty 、 AWS Security Hub 、 AWS Systems Manager といった他の AWS ネイティブサービスとの統合方法や、サードパーティーによる脅威の検出結果を取り込み、自動化されたモニタリング、トリアージ、封じ込めの機能に組み込む方法についても説明します。 AWS Security Incident Response による支援 AWS Security Incident Response は、2024 年 12 月にリリースされた Tier 1 サービスです。お客様向けに専用に構築された AWS ネイティブのセキュリティインシデント対応ソリューションであり、検出と対応 (GuardDuty と Security Hub)、管理とガバナンス (Systems Manager) の分野の他の AWS サービスと組み合わせることで、より大きな効果を発揮します。また、AWS Security Incident Response は、サービス固有のパートナースペシャライゼーションプログラムを通じて AWS パートナーとも統合されています。詳細については、 AWS Security Incident Response のドキュメント を参照してください。 AWS Security Incident Response は、セキュリティイベントの発生前、発生中、発生後を通じて効率的なインシデント管理機能を提供し、セキュリティポスチャを強化することで、既存のサービスを補完します。 主な課題 AWS Security Incident Response は、次の 3 つの一般的な課題に対応します。 アラート疲れ : 自動化されたモニタリングとインテリジェントなトリアージにより、アラート疲れを軽減し、セキュリティ調査を加速できます。誤検知が減ることで、セキュリティチームの燃え尽きの防止にも役立ちます。 アクセスとコミュニケーションの分断 : AWS マネジメントコンソールのアクセス許可管理を簡素化し、インシデント対応チームのコミュニケーションを一元化することで、アクセスの分断に関する問題を解決できます。 セキュリティスキルのギャップ : 認証情報の侵害、データ流出、ランサムウェアなどのインシデントに対応する AWS のセキュリティエキスパートに 24 時間 365 日アクセスできるため、クラウドセキュリティに関するスキルのギャップを埋めることができます。AWS Security Incident Response サービスを利用することで、セキュリティチームは目の前のセキュリティ課題に対処しながら、戦略的かつ長期的な備えと運用の改善にも引き続き注力できます。 サービスの統合 AWS Security Incident Response は、AWS のセキュリティサービスを補完し、それらと統合することで、包括的なインシデント対応機能を提供します。このサービスは、次のものとシームレスに連携します。 検出サービス : GuardDuty、Security Hub 管理ツール : Systems Manager サードパーティーソリューション : Security Hub の統合機能と  AWS Security Incident Response パートナースペシャライゼーションプログラム を通じて連携 訳注: 本記事で説明している AWS Security Hub は、翻訳時点 (2026 年 10 月) では AWS Security Hub CSPM に名称が変更されており、同じ名前の新しい AWS Security Hub が別途提供されています。AWS Security Incident Response は、サードパーティーの検出結果を AWS Security Hub CSPM 経由で取り込みます。参照: 「 ほぼリアルタイムの分析とリスクの優先順位付けが可能な AWS Security Hub が一般公開されました 」、「 ステップ 4: 既存のツールと統合する – AWS Security Incident Response ユーザーガイド 」 この統合により、組織のクラウドジャーニー全体を通じて、セキュリティイベントにかかる時間、コスト、影響を最小限に抑える効率的なインシデント対応機能を構築できます。また、人員の追加、トレーニング、ツールのメンテナンスへの投資の削減にも役立ちます。 独自の機能 AWS Security Incident Response サービスでは、次のものが提供されます。 AWS Security Incident Response Engineering (SIRE) チームの専門知識 API とコンソールを通じて利用できるツール セキュリティインシデントに対処するための効率化されたプロセス 前提条件 この記事で説明する機能を実装する前に、次の条件を満たしていることを確認してください。 適切な AWS Identity and Access Management (IAM) のアクセス許可を設定済みであること インシデント対応チームの連絡先を設定済みであること 通知チャネルを設定済みであること (オプション) アカウントと AWS リージョンで GuardDuty を有効化済みであること (オプション) アカウントとリージョンで Security Hub を有効化済みであること (オプション) 自動アクションに必要な AWS CloudFormation StackSets をデプロイ済みであること これらの前提条件を満たしておくことで、このサービスの自動検出、トリアージ、対応の機能を最大限に活用できます。 このサービスは、独自のサービスインフラストラクチャ内で自動化されたモニタリングと分析の機能を提供しており、GuardDuty と Security Hub の検出結果を自動的にトリアージできます。 AWS アカウントで自動封じ込めアクションを実行するには、まず必要な CloudFormation StackSets をデプロイし、適切な IAM アクセス許可を設定する必要があります。これにより、このサービスの検出機能を活用しつつ、環境内で実行される自動アクションを完全に制御できます。この自動化は、既知の CIDR 範囲 (ネットワークを定義する特定の IP アドレス範囲) や IP アドレスなど、お客様が設定する変数に基づいてカスタマイズできます。また、GuardDuty の抑制ルールを実装して、誤検知やアラートの量を減らすこともできます。その結果、このサービスは、既存のセキュリティインシデント対応プログラムやツールを補完する強力な手段となります。 AWS Security Incident Response のセットアップ クラウド管理者は、 AWSSecurityIncidentResponseFullAccess のアクセス許可を使用して、サービス内にインシデント対応チームを設定済みです。このサービスは、チームに追加された個人、パートナーまたはマネージドセキュリティサービスプロバイダー (MSSP)、その他の連絡先に通知を送信します。これにより、迅速にエスカレーションして必要な関係者にアラートを送り、イベントに対応できます。 ベストプラクティスとして、チームは AWS Security Incident Response のケース内の情報へのアクセスと管理に必要な最小限の権限を設定します。これにより、セキュリティとコンプライアンスの要件を満たしつつ、チームメンバーがケースの詳細、検出結果、調査データに適切なレベルでアクセスできるようになります。AWS Security Incident Response には、ケースごとに誰がどのアクションを実行できるかを制限できるよう、 CreateCaseComment (調査にメモを追加する) や  GetCase (ケースのメタデータを取得する) など、複数の API アクションが用意されています。開発環境とテスト環境向けには、ロールベースのアクセス制御に使用できる AWSSecurityIncidentResponseCaseFullAccess や AWSSecurityIncidentResponseReadOnlyAccess などのロールベースのポリシーが AWS から提供されています (図 1 を参照)。本番環境では、セキュリティ要件に基づき、最小権限の原則に従ったカスタム IAM ポリシーを作成することをお勧めします。 図 1: セキュリティインシデント対応のアクセス許可ポリシー AWS Security Incident Response サービスの設定後、セキュリティチームは、図 2 に示すように、このサービスからの通知を受け取る E メール配信リストまたはエイリアスを確認します。また、今後は追加の通知メカニズムとして PagerDuty や Jira などのサービスを追加できるよう、 Amazon EventBridge との統合を活用するタスクをバックログに登録しています。 図 2: コンソールを使用してインシデント対応チームのメンバーシップを管理する 不審なアクティビティの検出と対応 AWS Security Incident Response のセットアップから数日後の午前 2 時、このサービスは GuardDuty の検出結果を通じて、一連の不審なアクティビティを検出します。具体的には、IAM ユーザーの異常な動作 (図 3 に示すようなもの)、不明な IP アドレスからの通常とは異なる API コール、アカウントの通常のベースラインから逸脱した Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの大量作成などです。このアクティビティのパターンは、 GuardDuty 拡張脅威検出 がモニタリングしている既知の脅威の動作と一致します。このサービスがなければ、セキュリティチームはアカウントとリージョンをまたいで、これらの個別の検出結果を手動で分析し、相関付ける必要があります。しかし、このサービスを使用すれば、不審なアクティビティのパターンが自動的に特定されます。 図 3: 不審と思われるアクティビティのパターン 異常な動作の 1 つは、身に覚えのない EC2 インスタンスの大量作成です。これらのインスタンスには SSH キー (リモートアクセスに使用される安全な認証情報) が設定され、インターネット接続を許可するセキュリティグループ設定 (ネットワークトラフィックを制御するファイアウォールルール) も適用されています。このシナリオ例を使用して、このサービスの自動化されたモニタリング、トリアージ、封じ込めの機能、アクセス管理、カスタム統合用の API アクション、コラボレーションツール、そして 24 時間 365 日対応の AWS セキュリティエキスパートがどのように連携し、AWS 環境全体のセキュリティインシデント対応の課題への対処を支援するのかを順を追って見ていきましょう。 Incident Response Timeline     dateFormat HH:mm     axisFormat %H:%M          section Detection     GuardDuty Alerts          :02:00, 15m     Automated Analysis        :after Detection, 10m          section Investigation     Case Creation             :02:25, 5m     Team Notification         :02:30, 5m     Initial Assessment        :02:35, 25m          section Response     AWS SIRE Engagement       :03:00, 30m     Resource Tagging          :03:30, 15m     Containment Actions       :03:45, 30m          section Resolution     Threat Elimination        :04:15, 30m     Service Restoration       :04:45, 45m     Documentation             :05:30, 30m 初期検出が完了したら、次のフェーズでは、インシデントの全容を把握するために、セキュリティの検出結果を一元化して分析します。 セキュリティ検出結果の一元化: 体系的なアプローチ GuardDuty を有効化したリージョンで、検出結果の生成が開始されます。 注: GuardDuty は、アカウントとリージョンで有効化されている必要があります。セットアップ手順については、 GuardDuty のドキュメント を参照してください。 AWS Security Incident Response は GuardDuty と統合されているため、これらの検出結果は手作業なしで自動的にサービスに送信され、内部での処理、分析、自動トリアージが行われます。このサービスの プロアクティブな対応とアラートのトリアージ 機能は、アカウントの過去のアクティビティに基づくベースライン、GuardDuty の具体的な検出結果タイプ、アカウント間の相関パターンなど、複数の要素を分析します。この例では、環境の通常のパターンから大きく逸脱した、異常な EC2 インスタンス作成アクティビティを特定しました。 このサービスが真陽性を特定すると、AWS Security Incident Response のケースが自動的に作成され (図 4 を参照)、先ほど設定したインシデント対応チームに通知が送信されます。大きなメリットは、このサービスが個別のイベントを相関付け、インスタンスの作成とセキュリティグループの変更を結び付けることで、潜在的なセキュリティイベントの全体像を描き出せる点です。 図 4: 自動化されたインシデント修復フロー 月次サービスレポートに記録されているとおり、このプロアクティブなモニタリングと分析は、アラート疲れを軽減し、SOC チームにインテリジェントなトリアージ機能を日々提供することで、目に見えるメリットをもたらします。このサービスの自動分析と相関付けの機能により、セキュリティイベントの発生時に迅速に対応するための土台が整うため、チームはアラートの手動調査に時間を費やすことなく、戦略的なセキュリティイニシアチブに集中できます。このサービスの機能は、次の 2 つの点で強固なセキュリティの維持に役立ちます。 設定したリージョン全体にわたる包括的なモニタリング。 サードパーティーのセキュリティツールとの統合。この自動化されたアプローチにより、セキュリティイベントにかかる時間、コスト、影響が軽減されます。 調査が初期検出から詳細な分析へと進むなかで、GuardDuty との統合により、脅威のパターンに関する重要なインサイトが得られます。 検出からアクションへ: GuardDuty との統合 セキュリティチームが内部の検出メカニズムから得られた情報に対応するなかで、AWS Security Incident Response は、次の 3 つの主要なステップでセキュリティの検出結果を処理します。 GuardDuty のアラートを分析して、実際のセキュリティ脅威を特定する GuardDuty 拡張脅威検出を使用して関連するイベントを相関付け、脅威のパターンを特定する 初期アクション (ログの削除や不正なアクセス手段の作成) から、データ窃取の試みが疑われる段階に至るまで、脅威のシーケンスを追跡する 今回のイベントでは、AWS CloudTrail ログの削除から始まり、続いて不正なアクセスキーが作成されました。脅威が進行するにつれて、このサービスは Amazon Simple Storage Service (Amazon S3) オブジェクトへの不審なアクセスパターン、データ流出が疑われる試み、さらに高度な回避手法と永続化メカニズムを特定しました。これらのシグナルはそれぞれ MITRE ATT&CK® の特定の戦術、技術、手順 (TTP) に直接対応しており、ランサムウェアの疑いがある脅威が体系的に進行していることを示しています。AWS Security Incident Response の検出結果と MITRE ATT&CK® フレームワークとの詳細なマッピングについては、「 Mapping AWS security services to MITRE frameworks for threat detection and mitigation 」を参照してください。 このサービスは相関付けと分析を支援し、CloudTrail 証跡の削除、新しいアクセスキーの作成、S3 オブジェクトを標的とした不審なアクションなどのパターンを評価します。GuardDuty の AI と機械学習 (AI/ML) の機能が一定期間にわたってこうした懸念すべきパターンを検出すると、このサービスはお客様に代わって AWS Security Incident Response のケースを自動的に作成して状況をエスカレーションします。これにより、追加のリソースが投入され、この状況に重点的に対処できるようになります。その後、前の手順で定義したインシデント対応チームに、トリアージ済みの新しいイベントが作成されたことが E メールやその他の方法 (図 5 を参照) で通知され、チームは調査を開始します。 メリットの 1 つは、影響を受けるアカウント全体のコミュニケーションをこのサービスが調整することです。複数のアラートに振り回されたり、断片的な情報をつなぎ合わせてランサムウェアインシデントの疑いがある事象の範囲を把握しようとしたりする必要はありません。GuardDuty 拡張脅威検出が脅威のシーケンスの包括的なビューを提供し、AWS Security Incident Response のケースがこれらのシグナルをトリアージするための一貫した単一のチャネルとなります。さらに、世界各地のチームがオンラインになって対応に加わる際の調整にも役立ちます。 図 5: インシデントアラートメッセージ その他の例と詳細については、「 Amazon GuardDuty Extended Threat Detection のご紹介: AI/ML 攻撃シーケンスを識別し、クラウドセキュリティを強化 」を参照してください。 注: Security Hub のワークフローは、前述の GuardDuty のモニタリングとエスカレーションのプロセスと同様のため、ここでは簡潔さを優先して詳細を省略しています。両サービスは緊密に統合されており、同様の運用パターンを共有しています。GuardDuty の検出結果は、検出から 5 分以内に Security Hub に送信されます。Security Hub は、複数の AWS サービスとサードパーティーのパートナーからの検出結果を集約することで、セキュリティのカバレッジを強化します。 脅威のパターンが特定されたら、お客様のチームは次のフェーズに進み、専門知識と高度な調査機能を得るために AWS SIRE に協力を依頼します。 インシデント対応ケースを通じた AWS SIRE との連携 お客様のチームはイベントの調査を続けるなかで、追加の支援が必要だと判断します。アカウント内で必要な権限を持つユーザーが、AWS がサポートするケースを作成して支援を依頼します。 AWS Security Incident Response のケースでは、コンソール内でワンクリックでケースをエスカレーションするだけで AWS SIRE との直接的なコミュニケーションチャネルが確立され (図 6 を参照)、専門知識をすぐに利用できます。ケースがエスカレーションされると、AWS SIRE は 15 分以内に受領を確認し、インシデント対応ケースを通じて対応を開始します。そして、高度なツールと専門知識を活用し、ログ記録機能が限られている環境であっても、アカウント全体のパターンを分析します。この連携により、次のことが実現します。 ブリッジコール (ビデオ会議) によるリアルタイムのコラボレーション 高度なアーティファクト分析とパターン認識 調査と封じ込めのための技術的なガイダンス セキュリティポスチャを改善するための推奨事項 図 6: AWS SIRE との連携 図 6 は、セルフマネージドのケースとしてリゾルバーを Self に設定した場合の、アカウントでの表示例です。 シナリオに戻ると、複数のアカウントで十分なログ記録が有効になっておらず、調査に利用できるデータが限られていることが判明します。AWS SIRE は専門的なツールを通じて追加のインサイトを提供できますが、セキュリティの可視性の確保、コンプライアンス要件への対応、徹底したインシデント調査のためには、アカウント全体で包括的なログ記録を維持することが引き続き重要です。AWS SIRE の機能は適切なログ記録の実践を補完するものであり、それに代わるものではありません。AWS SIRE は通常はお客様から見えないパターンやアクティビティを把握できるため、この機能はインシデントの範囲を理解するのに役立ちます。 コラボレーションは、AWS SIRE が独自のツールを使用して環境を分析し、手元のログで確認できる範囲を超えて異常なパターンを探すところから始まります。AWS SIRE はインシデント対応ケースを通じて、次の方法でインシデントの範囲を把握できるよう支援します。 調査結果を共有する 追加の調査の方向性を提案する 他の環境で見られた同様の EC2 インスタンス作成パターンを示す分析を共有する AWS SIRE はインシデント対応ケースを使用してブリッジコールを設定し、AWS SIRE のチームとお客様のチームが集まってリアルタイムでコラボレーションできるようにします。この通話では、AWS SIRE がアーティファクトとサービスデータについて進行中の分析結果を共有し、何が起きたのか、なぜ起きたのか、今後同様の問題をどう防ぐのかを理解できるよう支援します。また、今後のセキュリティポスチャの改善に向けて、アカウント全体に適切なログ記録を実装するためのガイダンスも提供します。 インテリジェントなタグ付けによるインシデントの管理 AWS SIRE が分析を開始すると、お客様のチームはインシデントケース ID を使用して、リアルタイムでリソースにタグを付けていきます。この体系的なタグ付けは、アカウント全体で不審な EC2 インスタンスを追跡して管理するうえで非常に重要です。タグを使用することで、調査全体を通じて影響を受けたリソースを明確に記録しながら、隔離ポリシーを迅速に実装し、コストを追跡できます。 チームが採用したタグベースのアプローチは、影響を受けたリソースを追跡し、隔離ポリシーを実装するのに役立ちます。インシデントケース ID のタグを使用してインシデントに関連するリソースをすばやく特定し、対象を絞ったアクセス制御と封じ込め対策を適用しました。また、タグはインシデントに関連するコストの追跡にも役立つため、財務チームはイベントによる財務上の影響を正確に把握できます。 AWS Security Incident Response サービスと連携して作業を進めるなかで、インシデントケース ID をプライマリタグキーとして使用すると (図 7 を参照)、影響を受けたアカウント全体でリソースを一貫した方法で相関付けられることがわかりました。調査が必要な特定のリソースを AWS SIRE にすばやく伝えられるため、AWS SIRE と連携する際に特に役立ちます。封じ込め後も、これらのタグはインシデント後の分析を支え、インシデントから得た知見に基づいて対象を絞ったセキュリティコントロールを実装するのに引き続き役立ちます。 図 7: インシデントタグ Systems Manager との統合による自動封じ込めのオプション AWS SIRE と協力してインシデントの範囲を把握する一方で、Systems Manager を使用して脅威を自動的に封じ込めることもできます。チームは必要な CloudFormation StackSets を事前に組織全体へデプロイしているため、Systems Manager を通じて Amazon EC2 の封じ込めアクションを実行できます。 セットアッププロセスでは、特定の IAM ロールと Systems Manager の設定を含む CloudFormation StackSets をアカウント全体にデプロイする必要がありました。このインフラストラクチャにより、AWS Security Incident Response サービスはお客様に代わって封じ込めアクションを実行できます。これらのアクションは、元に戻す ( undo ) 機能を使う場合と同様に、必要に応じて取り消せるため、システムを以前の状態に復元できます。 事前にデプロイした CloudFormation StackSets を通じて承認されていれば、AWS Security Incident Response サービスは Systems Manager に封じ込め対策の実装を要求できます。封じ込めアクションを実行するには、お客様による明示的な承認と、事前に設定された適切な IAM アクセス許可が必要です。このサービスは、タグが付けられた不審なインスタンスのセキュリティグループとネットワークアクセスを変更してインスタンスを隔離すると同時に、フォレンジック分析に使用する証拠の完全性を維持できるよう、インスタンスの状態を保持します。 封じ込めプロセスは、次の 3 つのステップで行われます。 隔離 : 侵害されたインスタンスをセキュリティグループから削除する 保全 : 影響を受けたシステムのバックアップコピー (スナップショット) を作成する 調査 : Systems Manager を使用してシステム情報を収集する これらのアクションは必要に応じて元に戻すことができるため、正当なワークロードに対する封じ込めの判断にも柔軟に対応できます。 自動化機能により、複数のインスタンスにわたる封じ込め手順が効率化され、影響を受けたリソースの封じ込めにかかる時間を短縮できます。このサービスは各アクションの詳細なログをインシデント対応ケースに記録するため、チームは封じ込め作業の状況を明確に把握できます。 この対応機能と AWS SIRE からのガイダンスを組み合わせることで、インシデントの拡大を数時間ではなく数分で封じ込めることができます。Systems Manager との統合により、調査用の証拠を保全しながら、封じ込めアクションを確実に実装できます (図 8 を参照)。 図 8: 封じ込めアクション用の Systems Manager ドキュメント 解決と教訓 インシデントが解決に向かうにつれて、チームは体系的なプロセスに沿って、封じ込めの確認、脅威の緩和、サービスの復旧を進めます。AWS Security Incident Response のケースを通じて AWS SIRE と連携しながら、影響を受けたリソースを保護し、通常の運用を安全に再開できるよう、構造化されたアプローチを実践します。直ちに実施する解決アクションは、主に次の 3 つのカテゴリに分類されます。 Systems Manager による検証を通じた封じ込めの確認 セキュリティグループの変更が適用されていることを検証する 影響を受けたインスタンスのネットワーク隔離を確認する 自動封じ込めアクションが成功したことを検証する Systems Manager のログで封じ込めアクションの完了を確認する 影響を受けたリソース全体で脅威が緩和されたことの検証 GuardDuty の検出結果を分析し、新たな不審なアクティビティがないことを確認する タグ付けされたリソースを調べ、完全に封じ込められていることを確認する 不正アクセスの試みが停止していることを検証する 永続化メカニズムが削除されていることを確認する 不正な IAM アクセスが残っていないかを確認する サービスの復旧とアクセス制御の正常化 検証済みのベースラインに基づいて、正当なワークロードのアクセスを復元する 更新されたセキュリティグループ設定を実装する 影響を受けた IAM 認証情報とアクセスキーをリセットする クリーンであることが検証されたリソースについて、通常のネットワーク接続を再確立する インシデント後のステータスを反映するようにリソースタグを更新する 文書化とレポート作成 インシデントが解決に至ると、AWS Security Incident Response サービスは包括的なインシデントタイムラインを作成します。このドキュメントによってレポート作成プロセスが迅速化され、経営幹部、規制当局、サイバー保険会社向けに必要なレポートを、すべてインシデント対応ケース内からすばやく作成できます。 インシデント対応ケースには、GuardDuty 拡張脅威検出が初期段階の脅威のシーケンスを特定した時点から始まる、イベントの完全なタイムラインが記録されます。不審な EC2 インスタンスの作成が検出された瞬間から、観測された MITRE ATT&CK® の戦術、Systems Manager との統合を通じて実装された封じ込めアクション、そして最終的に効果が確認された解決手順に至るまで、インシデント対応の各ステップが文書化されます。 長期的な改善: このインシデント後の共同レビュープロセスを通じて、チームは次の取り組みを行います。 AWS SIRE の推奨事項に基づいて、ログ記録を強化する 同様のインシデントを防ぐためにセキュリティコントロールを更新する 教訓に基づいてインシデント対応プロセスを改善する 対象を絞った改善によってセキュリティポスチャを強化する まとめ この例では、AWS Security Incident Response サービスが、自動化された検出、トリアージ、封じ込め、アクセス管理、連携した対応の機能によって、セキュリティ運用をどのように強化できるかを紹介しました。このサービスは AWS Security Hub や Amazon GuardDuty と統合されているため、セキュリティイベントを効率的に処理できます。さらに、オプションで AWS SIRE にエスカレーションすれば、貴重な専門知識と専門的なツールを活用でき、インシデント対応ライフサイクルのあらゆる段階を加速し、セキュリティポスチャを強化するのに役立ちます。 AWS Security Incident Response サービスは、包括的なセキュリティ運用戦略の重要な要素として、次のような測定可能なメリットをもたらします。 自動化された相関付けと機械学習により、誤検知を最小限に抑えながら優先度の高いセキュリティリスクを特定する継続的な脅威モニタリング 自動検出と連携した対応によるインシデント対応時間の短縮 AWS SIRE との直接的なコラボレーションによる調査機能の強化 効率的かつ迅速な封じ込め レポート作成要件への迅速な対応を支援する、包括的なインシデントの記録と監査証跡 インシデントあたり最大 58% のコスト削減 セキュリティインシデントへの備え、対応、復旧をより迅速かつ効率的に行うには、今すぐ AWS Security Incident Response のページにアクセスするか、AWS アカウントチームに連絡してディスカッションの日程を調整してください。 その他のリソース セキュリティインシデント対応能力をさらに向上させるために、チームで活用できるその他の AWS リソースを紹介します。 イベント発生前 AWS Customer Playbook Framework : セキュリティイベントから得られた AWS SIRE の教訓を活用した、一般公開されている対応フレームワーク Assisted Log Enabler : Amazon VPC フローログ、AWS CloudTrail、Amazon Elastic Kubernetes Service の監査ログと Authenticator ログ、Amazon Route 53 Resolver クエリログ、Amazon S3 サーバーアクセスログ、Elastic Load Balancing ログなどのログの有効化を支援するツール イベント発生中 Athena Security Analytics Bootstrap : Amazon Athena をすばやくセットアップし、S3 バケットにアーカイブされた AWS サービスログを調査したいお客様向けのツール イベント発生前または発生後 AWS CIRT announces the release of five publicly available workshops   Jason Hurst Jason は、AWS CIRT の Senior Incident Responder 兼 Knowledge Manager です。人材の育成に情熱を注いでおり、地元の技術系カレッジで非常勤講師も務めています。余暇には 3 匹の愛犬と過ごすのを楽しんでいます。 Christopher Rae Christopher は AWS の Principal Worldwide Security Specialist として、AWS セキュリティソリューションの導入を加速し、拡大するためのグローバルなビジネス開発戦略の策定と実行を推進しています。サイバーセキュリティと新興テクノロジーの融合に情熱を注いでおり、戦略的リーダーシップを担う役職で、メディア、エンターテインメント、通信業界の世界中のお客様にセキュリティ製品とサービスを提供してきた 20 年以上の経験があります。 Nooms Charania Nooms は AWS Global Services Security の Sr. PMT – ES です。イェール大学で MBA を取得しており、USC でエンジニアリングのバックグラウンドを培いました。テクニカルプロダクトマネジメントを専門としており、MBA プログラム在学中に AWS でインターンを経験しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

こんにちは。ファインディ株式会社のプロダクトマネジメント室GenAI Enablementチームで、社内のデータ・AI活用を推進している山家です。 2026年10月5日（月）に、CTO室データソリューションチームとプロダクトマネジメント室GenAI Enablementチームの共催で、採用イベント 「ファインディにおけるデータ活用とAIがもたらす現場変革のリアル」 を、ファインディ本社でオフライン開催しました。 findy-inc.connpass.com この記事では、イベントを企画した背景と当日の4本のセッションを、参加できなかった方にもイメージが伝わるようにまとめます。あわせて、それぞれのチームが抱える課題と今後についても紹介します。 イベント開催の背景 データソリューションチーム セッション1: AIエージェントのためのデータ品質Ops セッション2: 2025年に事業部化したプラットフォーム事業部でのデータ活用 現在とこれから データソリューションチームの今後 GenAI Enablementチーム セッション3: データ問い合わせエージェントと求人推薦システムから見る、当社のデータ活用事例 セッション4: 領収書OCRを作ったら、OCR以外の仕事が本体だった GenAI Enablementチームの今後 まとめ イベント開催の背景 ファインディでは事業の広がりとともに、データ基盤やデータモデリングを整える仕事と、生成AIで現場の業務そのものを変える仕事の両方が進んでいます。データソリューションチームは全社の共通データ基盤とその品質を、GenAI Enablementチームは現場の業務にAIを届けることを担っています。 2つのチームは所属組織は違えど、密接に関係しています。AIが適切に動作するにはデータの品質が欠かせず、AIやデータを現場で使ってもらうには業務への埋め込みの設計が欠かせません。今回のイベントを、両チームがどのような課題に向き合い、どのように取り組んでいるかをお話しする機会にしました。 セッションは4本立てで、データソリューションチームとGenAI Enablementチームが2本ずつお話ししました。 データソリューションチーム データソリューションチームからは、AIエージェントに向けたデータ品質の運用と、新設事業部でのデータ活用の立ち上げについてお話ししました。 セッション1: AIエージェントのためのデータ品質Ops 登壇者: 田頭 speakerdeck.com AIエージェントにデータを使わせるために、dbtモデルの品質をどう運用しているかを紹介しました。データの使われ方は、人がLookerやSQLで集計する形から、AIエージェントに質問する形へ変わってきています。そのなかで、利用者側ではどのモデルを使えばよいかをエージェントに伝えられないという課題がありました。運用側でも、重要なモデルと検証用のモデルが同列に扱われ、ビルドが失敗したときにすぐ対応すべきか判断できませんでした。 そこで、dbtモデルを、算出する数値の用途で4段階のTierに分けました。テストやdescriptionといった品質要件は、工数のかかるものほど上位のTierに限定して求め、Tier 4だけはAIエージェントに使わせません。各Tierの用途と品質要件は次のとおりです。 Tier 用途 テスト description テスト失敗時の対応 AIエージェントの利用 Tier 1 外部公表数値・KPIの決定 主キー・外部キー・整合性 全カラムと計算ロジック 当日対応 可 Tier 2 部門の意思決定・定常レポート 主キー・主要な外部キー キー・指標カラム 週次で確認 可 Tier 3 部門オペレーション・データ抽出 主キー（推奨） モデルのみ ベストエフォート 可 Tier 4 アドホック・個人検証 要件なし 要件なし 要件なし 不可 Tier 1の起点の選び方では、AIと人の役割を分けています。LookerとBigQueryのクエリ履歴からClaude Codeのスキルが候補を出し、KPIに実際に使われているかはデータエンジニアが事業部に確認して決めます。確定した起点から dbt ls --select +<起点> で上流のモデルを列挙し、Tier 1を確定します。 現状、Tierはデータエンジニアの運用ルールとして使われている段階で、AIエージェントがTierを参照する仕組みはまだありません。今後は計算ロジックや用語集をKnowledge Catalogに集め、AIエージェントがTierの高いモデルと必要なコンテキストを取得して分析できる形を目指しています。 セッション2: 2025年に事業部化したプラットフォーム事業部でのデータ活用 現在とこれから 登壇者: 出相 speakerdeck.com 2025年に発足したプラットフォーム事業部で、データ活用をゼロから立ち上げている取り組みを紹介しました。発足当初は事業部付きのアナリストがおらず、事業部向けにデータを見る基盤もない状態でした。 最初に取り組んだのは、身近でデータに困っていると話していたカンファレンス集客の担当者の作業です。開催のたびに、業務に必要な対象リストを手作業で抽出し（1回約15分）、重複を関数で確認する（約30分）作業がありました。今後も開催数の増加が見込まれる中、これらの作業負荷がさらに高まることが課題でした。そこで、ヒアリングで必要なデータを把握し、BigQueryの共通基盤に集約、dbtでモデル化、Lookerで可視化するまでを一気通貫で整備しました。担当者へのヒアリングによると、リスト抽出にかかる時間は2〜3分に短縮され、重複率はダッシュボードで一目で分かるようになりました。 この1人との定例を起点に、困りごとを聞き、データを揃え、効果を見せ、その担当者の紹介で次の担当者へつなぐという循環を回して、事業部全体へ広げています。基盤の全体設計から入るのではなく、1つの業務を解いて次の相談を引き出す進め方です。 一方で、整えたデータが使われないという課題や、社内でNotionの活用が進みはじめるという状況の変化も出てきました。今後はNotionを入口に、Lookerのセマンティックレイヤーや共通データ基盤へたどれる状態を目指し、メタデータ・導線・定義の整備に取り組んでいきます。 データソリューションチームの今後 データソリューションチームが目指すのは、経営から現場まで、同じ正しい数字で意思決定できる状態です。共通データ基盤を作るだけで終わらせず、その数字が何を意味し、どこから来たのかを説明できるところまでを自分たちの仕事と考えています。 そのためにまず、指標を説明できる状態にします。KPIが何を表し、どのように計算されているのかを誰でも確かめられるようにします。そのうえで、数字が正しいことを前提に、予算と実績のズレを早く見つけられるようにします。ズレに気づいた人やAIが、すぐ次のアクションに移れる状態を目指しています。 Tierは運用ルールとして使われ始めた段階です。定期的な見直しや、計算ロジック・用語集をKnowledge Catalogへ集める取り組みはこれからです。AIエージェントが正しいデータを参照できるかを実際の問いで確かめながら、メタデータを育てていきます。 並行して、GenAI Enablementチームと協力しながら、AX（AIが業務を進め、人が要所で判断する形への業務の作り直し）と、データ基盤のセルフサービス化を進めています。AIや人が自分の手で課題を解決できるようなデータ基盤を目指していきます。 少数精鋭のチームなので、単発の作業で終わらせず、自動化や型化で横に広げられる仕組みにすることを大切にしています。経営と事業の意思決定に直結するデータ基盤を一緒に育てていけるデータエンジニアを募集しています。 GenAI Enablementチーム GenAI Enablementチームからは、社内向けの求人推薦と経費処理を例に、現場の業務にAIを組み込む取り組みをお話ししました。 セッション3: データ問い合わせエージェントと求人推薦システムから見る、当社のデータ活用事例 登壇者: 山家 speakerdeck.com 社内向けの求人推薦システムを例に、作った仕組みが現場で使われるための置き方を紹介しました。当日は時間の都合でお話しできませんでしたが、社内のデータ問い合わせに答えるエージェントを作った事例も登壇資料に載せているので、あわせてご覧ください。 転職事業では、ユーザーサクセス（US）が面談後に求人を紹介しています。担当者は紹介する求人を記憶と経験をたどって探しており、掲載求人が増えるほど追いつかなくなっていました。そこで、候補者ごとの推薦求人リストを出す仕組みを作りました。仕組みは次の図のとおりです。 求人票とUS面談メモをEmbeddingでベクトル化し、類似度で求人を並べたうえでフィルタをかけています。全体をBigQuery上のバッチで回しており、手法自体はシンプルなものにしています。 業務への導入方法はかなり意識をしました。以前作った検索系機能は現場の業務フローの外にあり、使われませんでした。そこで推薦では、面談メモを書いた後、紹介する求人を選ぶタイミングで、USが普段使うSalesforce上に観点ごとに分けて求人を出しました。推薦が引き受けるのは探す手間だけで、選んで紹介するのはUSのままです。その結果、USへのアンケートでは求人探索の工数が40%弱削減され、推薦経由の紹介も毎日生まれています。 ただし、使われることは成功と同じではありません。紹介求人の多くはカスタマーサクセス（CS）経由で、推薦が速くしたのはUSが自分で探す部分だけでした。現在は事業部全体にヒアリングし、事業のあるべき姿から逆算して、どのように業務を自動化していくかを計画しています。 セッション4: 領収書OCRを作ったら、OCR以外の仕事が本体だった 登壇者: 奥田 speakerdeck.com 秘書チームの経費処理を、生成AIでどう改善したかを紹介しました。月約160枚の領収書について、日付から予定を探し、参加者とその属性を確認し、経費区分を考えてSaaSへ転記する作業がありました。OCRで日付や金額を読み取れても、判断材料はカレンダー・組織図・人事情報に分かれたままです。 そこで、処理ごとに担い手を分けました。GASがSlackに投稿された領収書を取得し、Geminiが画像の読み取りと予定候補の選択を担います。参加者はGoogleカレンダーから、部門・役職・入社日は社員情報APIから取得し、決まった条件はコードで適用します。兼務は複数部門として扱い、入社日が取れなければその情報が必要な判定はしません。最後は秘書チームが判定理由と予算の利用状況を確認して区分を確定します。秘書チームの概算では、確認作業が月160分削減されました。 エラーの扱いも見直しました。判定できた、判断材料が足りない、取得処理に失敗した、の3つを分けて残し、情報不足なら人への確認、取得失敗なら再実行や調査へ進めるようにしています。 GenAI Enablementチームの今後 GenAI Enablementチームは、現場へのヒアリングから、社内データの接続、人が確認できる運用づくりまでを一気通貫で担います。 今は事業部全体の業務フローを、AIが主体で進め、人が要所で判断する形へ再設計しています。まずは担当者がAIの提案を確認・修正して使います。その記録で徐々にAIの精度を上げながら、AIに任せる範囲を広げていきます。 そのために欠かせないのが、データPdMとデータサイエンティストです。データPdMは、業務の中でどんなデータを生み、売上につなげるかを事業部と決めます。データサイエンティストは、今のやり方とAIを比べて効果を測り、任せる範囲を広げる根拠をつくります。事業責任者やPdMと会話しながら、データと実装を行き来して価値を届けたい方を募集しています。 まとめ 今回のイベントでは、データ品質の運用から、新設事業部でのデータ活用の立ち上げ、現場業務へのAIの組み込みまで、4名の視点からお話ししました。どのセッションにも共通していたのは、技術そのものよりも、データやAIを業務のどこにどうつなぐかを軸に進めてきたことです。仕組みは作るだけでは使われず、品質の優先度付けや業務フローへの埋め込み、人が確認できる運用まで設計して初めて現場が変わると考えています。 セッション後の懇親会でも、登壇では話しきれなかった失敗談を含め、参加者の皆さんと実務の話で盛り上がりました。こうした話ができるのは、オフライン開催ならではだと感じています。 参加してくださった皆さん、ありがとうございました！ ファインディでは、データとAIの力で現場を変えていく仲間を募集しています。今回のイベント内容に少しでも興味を持っていただけた方は、ぜひお気軽にカジュアル面談などでお話ししましょう。 データソリューションチームの求人はこちら。 herp.careers GenAI Enablementチームの求人はこちら。 herp.careers herp.careers

本記事は 2026 年 10 月 1 日に公開された “ Introducing filtered export from Amazon DynamoDB to Amazon S3 ” を翻訳したものです。 本日、 Amazon DynamoDB のフィルター付きエクスポート機能をリリースしました。これにより、テーブルのキャパシティを消費することなく、必要な項目と属性のみをエクスポートできるようになりました。 Amazon Simple Storage Service (Amazon S3) へのエクスポートは、2020 年のリリース以来、テーブル内のすべての項目を書き出してきました。2023 年に追加された増分エクスポートは、特定の時間枠内で変更されたすべての項目を書き出します。 フィルター付きエクスポートでは、同じ ExportTableToPointInTime リクエストに FilterSpecification が追加され、必要なアイテムと属性のみを取得するための式を指定できます。エクスポートは、一致するデータを S3 に書き込みます。テーブルではなく、ポイントインタイムリカバリ (PITR) バックアップから読み取るため、テーブルキャパシティを消費せず、本番トラフィックにも影響を与えません。 本投稿では、フィルター付きエクスポートを紹介し、問題のあるデプロイの後に単一テナントのデータを復旧するために、4 TB 丸ごとリストアするのではなく 1 回の増分エクスポートで行う方法を解説します。さらに 2 つのパターンを示します。1 つは顧客連絡先属性を除外したテナント履歴の共有、もう 1 つは特定時点のエクスポートと S3 インポートを使用した別リージョンへのテナント移行です。 DynamoDB の Amazon S3 へのエクスポートの概要 Amazon DynamoDB は、サーバーレスでフルマネージドな分散型 NoSQL データベースで、どのような規模でも 1 桁ミリ秒のパフォーマンスを実現します。Amazon S3 へのエクスポートは PITR バックアップから読み込むため、どのような規模のエクスポートでも読み込みキャパシティーを消費せず、アプリケーションのスループットと競合することもありません。 フル (非増分) エクスポートでは、PITR ウィンドウ内の特定の時点に存在していたすべての項目が書き込まれます。PITR ウィンドウは最大 35 日間まで遡ることができます。増分エクスポートでは、少なくとも 15 分、最大 24 時間離れた 2 つの時点の間で変更された項目が書き込まれ、各項目の新しいイメージと、オプションで古いイメージが含まれます。 どちらも改行区切りの DynamoDB JSON または Amazon Ion をバケットに書き込み、エクスポートの内容を記述した manifest-summary.json ファイルと、サービスが生成したエクスポート ID 配下に、各データファイルをアイテム数とチェックサムとともに一覧表示する manifest-files.json ファイルを出力します。 Amazon Athena は圧縮されたデータファイルを直接読み取るため、データフォルダ上にテーブル定義を作成するだけで、SQL でエクスポートをクエリできます。 フィルター付きエクスポートのご紹介 これまで、エクスポートの単位はテーブルでした。数百のテナントを保持するマルチテナントテーブルから 1 つのテナントを復元するには、すべてをエクスポートしてから後段でサブセットを選択するか、テナントのパーティションに対して Query を実行して現在の状態のみを取得する必要がありました。 フィルター付きエクスポートは、選択条件をエクスポートリクエストに移します。このリクエストには、Query や Scan ですでに使用している式構文を利用した 5 つのフィールドを持つ FilterSpecification オブジェクトが追加されます。 フィールド 役割 KeyConditionExpression Query のセマンティクスに従って、1 つのパーティションキー値を選択し、オプションでソートキー条件を指定します。エクスポートが読み取るパーティションを制限するため、エクスポートで処理されるデータが少なくなります。 FilterExpression Scan で使用する演算子を用いて、キー属性と非キー属性の両方に条件を指定します。読み取り後に各アイテムに適用されるため、処理されるデータ量を削減せずに、書き込む内容を選択します。キー属性は、KeyConditionExpression が指定されていない場合にのみ指定できます。 ProjectionExpression 書き込む属性の名前を指定します。 ExpressionAttributeNames 属性名の置換トークンです。この記事の例では、Status などの名前は予約語であるため、すべての名前にエイリアスを設定しています。 ExpressionAttributeValues 属性値の置換トークンです。 キー条件式は Query で記述するものと同じですが、2 つの操作は読み取る対象が異なります。Query は現在のテーブルを 1 ページずつ読み取り、読み取りキャパシティーを消費します。一方、フィルター付きフルエクスポートは、選択した時点の PITR バックアップを読み取り、その時点でのパーティションを返します。フィルター付き増分エクスポートは、指定した期間内に変更された項目を返し、各項目について期間開始前と終了時点の状態を含めます。結果は S3 に書き込まれ、同一アカウントでも別アカウントでも可能で、テーブルキャパシティーを消費せず、ページネーションやアップロードのコードを書く必要もありません。 フィルタリングは、フルエクスポートと増分エクスポートの両方に適用できます。ExportType で FULL_EXPORT または INCREMENTAL_EXPORT を選択し、FilterSpecification で対象の項目と属性を選択します。DescribeExport は適用された FilterSpecification を返し、フィルター付きエクスポートはフルエクスポートと同じ AWS Identity and Access Management (IAM) 権限を使用します。 次のスクリーンショットは、DynamoDB コンソールでエクスポートをリクエストする際のフィルターオプションを示しています。 図 1: Amazon DynamoDB コンソールにおけるポイントインタイムエクスポートのフィルターオプション 前提条件 この記事を進めるには、以下の前提条件を満たしている必要があります。 PITR が有効な DynamoDB テーブルを持つ AWS アカウント 。この例では、米国東部 (バージニア北部) リージョン (us-east-1) にある FieldServiceData という名前のテーブルを使用します。 この例では、amzn-s3-demo-bucket と、移動先として欧州 (アイルランド) リージョン (eu-west-1) にある 2 つ目のバケット amzn-s3-demo-destination-bucket を使用します。 テーブルからのエクスポートとバケットへの書き込みを許可する認証情報が設定された AWS Command Line Interface (AWS CLI)。 影響評価セクションのための Amazon Athena へのアクセス。 問題のあるデプロイ後の特定のテナントの復旧 AnyCompany Field Ops は、顧客企業のフィールドサービス作業指示書を管理する SaaS (software as a service) プロバイダーです。1 つの DynamoDB テーブル FieldServiceData が、すべてのテナントの作業指示書を保持しています。TenantId がパーティションキーで、WorkOrderId がソートキーです。各アイテムは、Status、Priority、CustomerEmail、CustomerPhone、AmountDue (セント単位)、および UpdatedAt (アプリケーションが書き込みのたびに付与する ISO 8601 形式のタイムスタンプ) を保持しています。テーブルは数百のテナントにまたがり、約 4 TB です。 9 月 10 日 13:55 UTC、チームは請求照合サービスの新バージョンをデプロイします。これには、まず tenant-4213 に対して実行するようフラグが設定されたデータ移行ジョブが含まれています。ジョブは 14:02 UTC に開始されます。不具合により、AmountDue が誤った乗数で再計算され、アクティブなワークオーダーに対して Status が COMPLETED に設定されてしまいます。14:42 UTC、テナントは残高の誤りとクローズされたワークオーダーを報告します。オンコールエンジニアがジョブを停止し、14:50 UTC までにロールバックが完了します。tenant-4213 に属する約 48,000 件のアイテムが誤った値を保持することになり、他のテナントには影響がありませんでした。 チームは、ジョブの最初の書き込みが行われる前の 14:00 UTC 時点における tenant-4213 のアイテムを必要としています。PITR リストアを実行すると、テーブルの 4 TB のコピーが作成されますが、そのうちテナントに属するのは約 2 GB です。テナントのパーティションに対する Query は、現在の状態のアイテムを返します。破損が発生した時間帯に対する増分エクスポートでは、NEW_IMAGE と OLD_IMAGE、およびテナントのパーティションキーをキー条件式として使用します。これにより、14:00 から 14:45 UTC の間に変更されたテナントのアイテムのみが、時間帯開始前の状態と時間帯終了時点の状態と共に書き出されます。1 回のエクスポートで、影響を受けたアイテム群とインシデント発生前のコピーの両方を取得できます。 エクスポートのリクエスト 以下の AWS CLI コマンドでエクスポートをリクエストします。ウィンドウは UTC の 14:00 から 14:45 までで、ジョブの書き込みをカバーし、増分エクスポートに必要な最低 15 分の要件を満たしています。キー条件はテナントのパーティションキーを選択し、リカバリには完全なアイテムが必要なため、リクエストにはフィルターやプロジェクションは含まれません: aws dynamodb export-table-to-point-in-time \ --table-arn arn:aws:dynamodb:us-east-1:111122223333:table/FieldServiceData \ --export-type INCREMENTAL_EXPORT \ --incremental-export-specification '{ "ExportFromTime": "2026-09-10T14:00:00Z", "ExportToTime": "2026-09-10T14:45:00Z", "ExportViewType": "NEW_AND_OLD_IMAGES" }' \ --s3-bucket amzn-s3-demo-bucket \ --s3-prefix exports/tenant-4213-recovery/ \ --export-format DYNAMODB_JSON \ --client-token tenant-4213-recovery-20260910 \ --filter-specification '{ "KeyConditionExpression": "#tid = :tid", "ExpressionAttributeNames": {"#tid": "TenantId"}, "ExpressionAttributeValues": {":tid": {"S": "tenant-4213"}} }' エクスポートステータスの確認 ExportTableToPointInTime は ExportArn を返し、エクスポートはバックグラウンドで実行されます。DescribeExport はステータスを報告します: aws dynamodb describe-export \ --export-arn arn:aws:dynamodb:us-east-1:111122223333:table/FieldServiceData/export/01789052952000-1a2b3c4d レスポンスには両方の仕様が反映されています。 { "ExportDescription": { "ClientToken": "tenant-4213-recovery-20260910", "DestinationType": "S3", "EndTime": "2026-09-10T15:24:03.985000+00:00", "ExportArn": "arn:aws:dynamodb:us-east-1:111122223333:table/FieldServiceData/export/01789052952000-1a2b3c4d", "ExportFormat": "DYNAMODB_JSON", "ExportManifest": "exports/tenant-4213-recovery/AWSDynamoDB/01789052952000-1a2b3c4d/manifest-summary.json", "ExportStatus": "COMPLETED", "ExportType": "INCREMENTAL_EXPORT", "FilterSpecification": { "ExpressionAttributeNames": {"#tid": "TenantId"}, "ExpressionAttributeValues": {":tid": {"S": "tenant-4213"}}, "KeyConditionExpression": "#tid = :tid" }, "IncrementalExportSpecification": { "ExportFromTime": "2026-09-10T14:00:00+00:00", "ExportToTime": "2026-09-10T14:45:00+00:00", "ExportViewType": "NEW_AND_OLD_IMAGES" }, "ItemCount": 48627, "S3Bucket": "amzn-s3-demo-bucket", "S3Prefix": "exports/tenant-4213-recovery/", "S3SseAlgorithm": "AES256", "StartTime": "2026-09-10T15:09:12+00:00", "TableArn": "arn:aws:dynamodb:us-east-1:111122223333:table/FieldServiceData", "TableId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } } ItemCount は、ウィンドウ内で変更された tenant-4213 の項目数であり、テーブルやテナントの項目数ではありません。 Amazon S3 での出力の確認 エクスポートでは増分エクスポートのレイアウトが使用され、マニフェストはエクスポート ID フォルダ配下に、データファイルはプレフィックス配下の data フォルダに配置されます: s3://amzn-s3-demo-bucket/exports/tenant-4213-recovery/AWSDynamoDB/ 01789052952000-1a2b3c4d/ _started manifest-files.json manifest-files.md5 manifest-summary.json manifest-summary.md5 data/ 6nrravgomiyjpnjumsmzc3w2ve.json.gz du5kedq3ee7dlbixg2crj4pawe.json.gz ... 各データファイルの各行は、ウィンドウ内で変更された tenant-4213 の 1 つの項目を表しており、OldImage (14:00 UTC 直前の状態) と NewImage (ウィンドウ終了時の状態) が含まれています。以下のレコードはそのような項目の 1 つで、読みやすさのために複数行にフォーマットされています。 { "Metadata": {"WriteTimestampMicros": {"N": "1789049381000000"}}, "Keys": {"WorkOrderId": {"S": "WO-0010041"}, "TenantId": {"S": "tenant-4213"}}, "OldImage": { "WorkOrderId": {"S": "WO-0010041"}, "TenantId": {"S": "tenant-4213"}, "CustomerPhone": {"S": "+1-206-555-0142"}, "Priority": {"S": "URGENT"}, "CustomerEmail": {"S": "diego_ramirez@example.com"}, "UpdatedAt": {"S": "2026-09-09T22:17:03Z"}, "AmountDue": {"N": "48250"}, "Status": {"S": "IN_PROGRESS"} }, "NewImage": { "WorkOrderId": {"S": "WO-0010041"}, "TenantId": {"S": "tenant-4213"}, "CustomerPhone": {"S": "+1-206-555-0142"}, "Priority": {"S": "URGENT"}, "CustomerEmail": {"S": "diego_ramirez@example.com"}, "UpdatedAt": {"S": "2026-09-10T14:09:41Z"}, "AmountDue": {"N": "4825000"}, "Status": {"S": "COMPLETED"} } } OldImage がないレコードはウィンドウ内で作成された項目であり、NewImage がないレコードは削除を示します。他のテナントのデータは含まれないため、このリカバリ用プレフィックスをインシデント対応チームと共有できます。 Amazon Athena による影響の評価 以下の Athena ステートメントは、エクスポートデータに対してテーブルを定義します。各イメージカラムは DynamoDB JSON 構造を反映しており、すべての属性はフィールド名が型記述子となる構造体 (struct) です: CREATE EXTERNAL TABLE tenant_4213_window ( Metadata struct<WriteTimestampMicros:struct<N:string>>, Keys struct<TenantId:struct<S:string>, WorkOrderId:struct<S:string>>, OldImage struct< Status:struct<S:string>, Priority:struct<S:string>, AmountDue:struct<N:string>, UpdatedAt:struct<S:string> >, NewImage struct< Status:struct<S:string>, Priority:struct<S:string>, AmountDue:struct<N:string>, UpdatedAt:struct<S:string> > ) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe' LOCATION 's3://amzn-s3-demo-bucket/exports/tenant-4213-recovery/AWSDynamoDB/data/'; 次のクエリでは、ウィンドウ内のテナント自身のアクティビティとジョブによる書き込みを分離します。ジョブは Status を COMPLETED に設定し、AmountDue を乗算したため、Status が COMPLETED に変更され、同時に AmountDue も変更されたレコードは破損の痕跡を示しています。どちらか一方のみが変更された更新や、OldImage のない挿入は、通常のアプリケーショントラフィックです。 SELECT Keys.WorkOrderId.S AS work_order_id, OldImage.Status.S AS status_before, CAST(OldImage.AmountDue.N AS bigint) AS amount_before, CAST(NewImage.AmountDue.N AS bigint) AS amount_now, NewImage.UpdatedAt.S AS written_at FROM tenant_4213_window WHERE OldImage IS NOT NULL AND NewImage IS NOT NULL AND NewImage.Status.S = 'COMPLETED' AND OldImage.Status.S <> 'COMPLETED' AND OldImage.AmountDue.N <> NewImage.AmountDue.N; その結果が、修復対象の作業指示のリストとなります。ライトバックのステップではコード内で同じシグネチャが適用されるため、このクエリは本番環境へ書き込まれる前のレビューとして機能します。 インシデント発生前の項目の書き戻し 以下のスクリプトは、エクスポートのデータファイルを S3 からストリーミングで読み込み、破損の兆候を持つレコードを選別し、各 OldImage を PutItem で書き戻します。条件式により、UpdatedAt が破損ウィンドウ内に収まっている場合にのみアイテムが置き換えられます。ロールバック後に顧客やアプリケーションが更新した作業指示書はそのまま残されます。 """Write pre-incident items back for the work orders the deployment changed.""" import gzip import json import boto3 BUCKET = "amzn-s3-demo-bucket" DATA_PREFIX = "exports/tenant-4213-recovery/AWSDynamoDB/data/" TABLE = "FieldServiceData" WINDOW_START = "2026-09-10T14:02:00Z" WINDOW_END = "2026-09-10T14:42:00Z" s3 = boto3.client("s3", region_name="us-east-1") ddb = boto3.client("dynamodb", region_name="us-east-1") def export_records(): pages = s3.get_paginator("list_objects_v2").paginate(Bucket=BUCKET, Prefix=DATA_PREFIX) for page in pages: for obj in page.get("Contents", []): if not obj["Key"].endswith(".json.gz"): continue body = s3.get_object(Bucket=BUCKET, Key=obj["Key"])["Body"] with gzip.GzipFile(fileobj=body) as gz: for line in gz: yield json.loads(line) def corrupted(record): old, new = record.get("OldImage"), record.get("NewImage") if old is None or new is None: return False # insert or delete inside the window: not the job's work return ( new["Status"]["S"] == "COMPLETED" and old["Status"]["S"] != "COMPLETED" and old["AmountDue"]["N"] != new["AmountDue"]["N"] ) restored = skipped = 0 for record in filter(corrupted, export_records()): try: ddb.put_item( TableName=TABLE, Item=record["OldImage"], ConditionExpression="#ua BETWEEN :ws AND :we", ExpressionAttributeNames={"#ua": "UpdatedAt"}, ExpressionAttributeValues={":ws": {"S": WINDOW_START}, ":we": {"S": WINDOW_END}}, ) restored += 1 except ddb.exceptions.ConditionalCheckFailedException: skipped += 1 print(f"restored {restored}, skipped {skipped}") PutItem はアイテム全体を置き換えるため、部分的な失敗の後にスクリプトを再実行しても、追加の管理処理なしで同じ最終状態に収束します。以下の出力は、同じインシデントをシードした小さなテーブルに対して連続して 2 回実行した結果です。2 回目の実行では、復元されたすべてのアイテムが再度対象期間前の UpdatedAt を保持していることが確認されるため、条件チェックに失敗し、何も書き込まれません。 restored 3, skipped 0 restored 0, skipped 3 古いイメージはウィンドウ開始前の項目の状態です。written_at がジョブの書き込み時刻のいずれでもないレコードは、ウィンドウ内で他の処理によっても変更されています。一括書き戻しの前にそれらを確認してください。 選択した属性を使用した 1 つのテナントの履歴の共有 AnyCompany Field Ops は、パートナー分析チームに tenant-7788 の作業指示履歴を提供することに合意します。この合意では顧客の連絡先情報は対象外です。ProjectionExpression で書き出す属性を指定することで、CustomerEmail と CustomerPhone は共有バケットに到達することがありません: aws dynamodb export-table-to-point-in-time \ --table-arn arn:aws:dynamodb:us-east-1:111122223333:table/FieldServiceData \ --s3-bucket amzn-s3-demo-bucket \ --s3-prefix exports/tenant-7788-partner-share/ \ --export-format DYNAMODB_JSON \ --client-token tenant-7788-partner-share-20260910 \ --filter-specification '{ "KeyConditionExpression": "#tid = :tid", "ProjectionExpression": "#tid, #wo, #st, #pri, #amt, #ua", "ExpressionAttributeNames": { "#tid": "TenantId", "#wo": "WorkOrderId", "#st": "Status", "#pri": "Priority", "#amt": "AmountDue", "#ua": "UpdatedAt" }, "ExpressionAttributeValues": {":tid": {"S": "tenant-7788"}} }' エクスポートされた各項目には、投影された 6 つの属性のみが含まれ、それ以外は含まれません。 {"Item":{"AmountDue":{"N":"18250"},"Priority":{"S":"URGENT"},"Status":{"S":"IN_PROGRESS"},"TenantId":{"S":"tenant-7788"},"UpdatedAt":{"S":"2026-09-12T09:15:40Z"},"WorkOrderId":{"S":"WO-0081120"}}} プロジェクションはインクルードリストです。共有する項目を指定し、除外した属性はバケットに届くことはありません。値を検査するわけではないため、個人情報を含むフリーテキストフィールドは、除外しない限りそのまま通過します。宛先バケットは、別のアカウントや別のリージョンに配置することもできます。 1 つのテナントを別リージョンへ移行する AnyCompany Field Ops のあるテナントが事業拠点をヨーロッパに移転し、データもヨーロッパで保持するよう依頼してきました。特定の時点のフィルター付きフルエクスポートにより、該当テナントのアイテムが eu-west-1 のバケットに書き出され、S3 からのインポートで同リージョンのテーブルにロードされます。他のテナントは現状のまま維持されます。次のコマンドは、合意された切り替え時刻時点のテナントデータを eu-west-1 のバケットにエクスポートします。 aws dynamodb export-table-to-point-in-time \ --table-arn arn:aws:dynamodb:us-east-1:111122223333:table/FieldServiceData \ --export-time 2026-09-14T00:00:00Z \ --s3-bucket amzn-s3-demo-destination-bucket \ --s3-prefix exports/tenant-5501-relocation/ \ --export-format DYNAMODB_JSON \ --client-token tenant-5501-relocation-20260914 \ --filter-specification '{ "KeyConditionExpression": "#tid = :tid", "ExpressionAttributeNames": {"#tid": "TenantId"}, "ExpressionAttributeValues": {":tid": {"S": "tenant-5501"}} }' 出力はフルエクスポートのレイアウトに従います。すべてのデータファイルはエクスポート ID のフォルダ配下に配置され、各行には Item フィールドでラップされた 1 つのアイテムが格納されます。プロジェクションがないため、すべての属性が含まれます。 以下のコマンドは、エクスポートを eu-west-1 の新しいテーブルにインポートします。S3 からのインポート機能は DynamoDB JSON のエクスポートファイルを直接読み取り、指定されたキースキーマでテーブルを作成します。 aws dynamodb import-table \ --region eu-west-1 \ --s3-bucket-source S3Bucket=amzn-s3-demo-destination-bucket,S3KeyPrefix=exports/tenant-5501-relocation/AWSDynamoDB/01789376400000-5e6f7a8b/data/ \ --input-format DYNAMODB_JSON \ --input-compression-type GZIP \ --table-creation-parameters '{ "TableName": "FieldServiceData", "AttributeDefinitions": [ {"AttributeName": "TenantId", "AttributeType": "S"}, {"AttributeName": "WorkOrderId", "AttributeType": "S"} ], "KeySchema": [ {"AttributeName": "TenantId", "KeyType": "HASH"}, {"AttributeName": "WorkOrderId", "KeyType": "RANGE"} ], "BillingMode": "PAY_PER_REQUEST" }' S3 からのインポートでは新しいテーブルが作成されるため、グローバルセカンダリインデックスは TableCreationParameters で宣言します。エクスポート時刻からカットオーバーまでの間に us-east-1 に到達したテナントの書き込みについては、トラフィックを切り替える前にアプリケーション側で再適用または処理しきる必要があります。テナントのアイテムは、アプリケーションが削除するまでソーステーブルに残ります。 料金 フィルター付きエクスポートは、フルエクスポートおよび増分エクスポートと同じ料金体系で、GB あたりの単価も同じであり、フィルタリングに対する追加料金は発生しません。フィルター付きエクスポートは、同じテーブルのフルエクスポートよりも低コストになる可能性があります。キー条件式がパーティションキーを指定している場合、エクスポートはテーブル全体ではなく、そのキーを含むパーティションのみを読み取ります。課金はマッチしたデータに対して行われますが、現在のエクスポートに適用されている 1 回のエクスポートあたり 10 MB の最小課金対象データ量が適用されます。キー以外の属性に対するフィルターは、エクスポートが読み取るデータを削減しません。 Amazon S3 では、エクスポートが書き込むオブジェクトのストレージとリクエストが課金され、Amazon Athena ではスキャンされたバイト数に応じて課金されます。リカバリエクスポートは、45 分間のウィンドウで変更されたテナントのアイテム (それぞれ 2 つのイメージ (変更前と変更後) を含む) を保持しますが、同じウィンドウのフィルターなしの増分エクスポートでは、すべてのテナントの変更が保持されます。リロケーションエクスポートはそのテナントの 2 GB を保持しますが、フルエクスポートでは 4 TB のテーブル全体が書き込まれることになります。エクスポートはテーブルの読み取りキャパシティを消費しません。フィルター付きエクスポートに必要な PITR 継続的バックアップは、標準の PITR 料金で課金されます。 考慮事項 以下の点に注意してください。 フルエクスポートと同じ要件として、ソーステーブルで PITR を有効にする必要があります。エクスポートは PITR ウィンドウ内の任意の時点を対象にでき、PITR ウィンドウは最大 35 日間に及びます。 キー条件式は Query のセマンティクスに従います。パーティションキーの値を 1 つ、等価条件のみで指定し、オプションでソートキー条件を指定できます。フィルター式は読み取り後に適用されるため、エクスポートが処理するデータ量を減らすことなく、書き込まれる内容を選択します。 キー条件式で許可されていない非等価条件をパーティションキーに適用したい場合は、代わりにフィルター式で表現してください。フィルター式は、キー条件式でそのキーが使用されていない場合に限り、パーティションキーまたはソートキーの属性を参照できます。 フィルター付きエクスポートは、リリース時点ではセカンダリインデックスでは動作しません。これはフルエクスポートと同様です。 エクスポートはフルエクスポートと同じ一貫性モデルを持ちます。リクエストされた時刻までのすべての書き込みがパーティション間で結果整合性をもってキャプチャされ、エクスポートはトランザクションを認識しません。 フルエクスポートと同じモデルに従い、クロスアカウントおよびクロスリージョンの宛先がサポートされます。 クリーンアップ 継続的な料金が発生しないように、この記事で作成したリソースを削除してください。DynamoDB は、バケットからエクスポート出力を削除することはありません。以下のコマンドでエクスポートされたオブジェクトを削除します: aws s3 rm s3://amzn-s3-demo-bucket/exports/tenant-4213-recovery/ --recursive aws s3 rm s3://amzn-s3-demo-bucket/exports/tenant-7788-partner-share/ --recursive aws s3 rm s3://amzn-s3-demo-destination-bucket/exports/tenant-5501-relocation/ --recursive 以下のステートメントは、メタデータのみを保持する Athena テーブルを削除します: DROP TABLE tenant_4213_window; 本手順に沿うためだけに作成した場合は、以下のコマンドで eu-west-1 のインポート済みテーブルを削除します: aws dynamodb delete-table --region eu-west-1 --table-name FieldServiceData この投稿用にソーステーブルを作成した場合は、同様に削除するか、PITR を無効化してください。PITR は有効化されている間、標準料金で課金が継続されるためです。エクスポートタスクのメタデータは、90 日後に DescribeExport および ListExports から取得できなくなります。 まとめ 本記事では、エクスポートを 1 つのパーティションキー、条件に合致するアイテム、選択した属性セットに絞り込めるフィルター付きエクスポートを紹介しました。4 TB のテーブルから、障害発生期間にわたる 1 回の増分エクスポートで単一テナントのアイテムを復旧し、変更されたアイテムとインシデント前の状態を同時に取得できました。それらを Amazon Athena で確認し、条件付き PutItem で古いイメージを書き戻しました。同じ形式のリクエストで、選択した属性のみを使ってテナントの履歴を共有したり、特定時点のエクスポートと S3 インポートを用いてテナントを別のリージョンへ移行することもできます。 フィルター付きエクスポートは、すべての商用リージョンでご利用いただけます。使用を開始するには、 Amazon S3 への DynamoDB データのエクスポート を参照してください。また、どのようなデータをエクスポートしているか、コメントでお知らせください。 著者について Lee Hannigan Lee はアイルランドのドニゴールを拠点とするシニア Amazon DynamoDB データベースエンジニアです。ビッグデータと分析技術の強固な基盤に支えられた、分散システムに関する豊富な専門知識を有しています。 Anugrah Prakash Anugrah はシアトルを拠点とする Amazon DynamoDB チームのシニアプロダクトマネージャーです。テクノロジーとプロダクトマネジメントのバックグラウンドを持ち、お客様と密に協力して長期的な価値を提供する機能を定義することを楽しんでいます。仕事以外では、旅行、ハイキング、テクノロジーに関する読書を楽しんでいます。 翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。