本ブログは 2026 年 10 月 7 日に公開された AWS Blog “ Configuring your AI vulnerability harness, Part 2: The steering file ” を翻訳したものです。 この記事では、AI モデルを設定し、経験豊富なセキュリティアナリストと同等の一貫性で、構造化された証拠ベースの脆弱性トリアージを実行させる方法を紹介します。すべての分析セッションで構造的検証、証拠ベースのスコアリング、インフラストラクチャを考慮した優先順位付けを徹底させる 5 つの設定セクションを取り上げ、それぞれの設計上の判断を解説します。アーキテクチャについてはパート 1 の記事「 3 層パイプラインによる検出結果の絞り込み 」で解説しました。この記事では設定を解説します。 この違いが重要なのは、同じフロンティアモデルでも、ある指示では厳密で証拠に基づいたセキュリティ評価を生成する一方で、別の指示ではハルシネーションによる攻撃チェーンや過大な重大度評価を生成してしまうからです。モデルの能力は変わりません。設定によって変えられるのは、モデルの判断です。 ハーネスを構築する中で、私たちはこのことを痛感しました。初期のイテレーションでは、一見もっともらしいものの、精査すると破綻してしまう検出結果が生成されていました。モデルは、存在しない関数で SQL インジェクションを報告したり、構造的な根拠が何もないまま HIGH の信頼度を主張したり、リクエストパス上にブロッキングモードで直接配置されている AWS WAF を無視したりしました。そのままの出力では、エンジニアリングチームの信頼は得られなかったでしょう。 解決策は、より優れたモデルではなく、モデルをより適切に方向付けることでした。 ステアリングファイルとは ステアリングファイルとは、AI コーディングアシスタントがすべてのセッションの開始時に読み込む一連の指示です。規約はツールによって異なります。Kiro は .kiro/steering/ ディレクトリから Markdown ファイルを読み込みます。Claude Code は CLAUDE.md 、Cursor は .cursorrules 、GitHub Copilot は .github/copilot-instructions.md を使用します。ただし、役割はどれも同じで、リポジトリでの作業にモデルがどう取り組むかを方向付ける永続的な指示です。 セキュリティ分析に応用すると、ステアリングファイルはチームのトリアージ手法を機械で実行可能な指示としてエンコードします。個々のエンジニアが手法を一貫して適用することに頼る必要はありません。一度エンコードすれば、モデルがすべての分析に同じ手法を適用します。 今回公開するステアリングファイルは、ハーネスの記事で説明したアーキテクチャの原則を、運用上の指示としてエンコードしたものです。ハーネスの記事で apply infrastructure-aware assessment (インフラストラクチャを考慮した評価を適用する) と述べている部分について、ステアリングファイルでは具体的な方法を明示しています。どのコントロールにどの乗数を対応させるか、乗数をどのように掛け合わせるか、単一のコントロールへの過信を防ぐ下限値をいくつにするかを規定しています。 設定がプロンプトより優れている理由 シングルターンのプロンプト ( find vulnerabilities in this code : このコード内の脆弱性を見つけて) では、モデルはデフォルトの動作のまま出力を生成します。そのデフォルトは、厳密さではなく有用性を重視して最適化されています。何かを見つけるよう依頼されたので、モデルは報告できるものを見つけようとするのです。 ステアリングファイルは、このデフォルトを変更します。具体的には、次の点を定めます。 証拠とみなすもの: 明示的な指示がない場合、モデルは自らの推論を十分な証拠として扱います。ステアリングファイルでは、検出結果を報告する前に、構造的検証 (データフローの確認、関数の存在確認、呼び出しパスの確認) を必須としています。 信頼度の意味: 指示がなければ、モデルは自らの説明が自分にとってどれだけもっともらしく思えるかに基づいて信頼度を割り当てます。ステアリングファイルでは、自己申告の信頼度を、二値の構造的シグナルから計算する式に置き換えます。テイント分析でフローが確認できるか、できないか。コールグラフがエントリポイントからシンクまでつながっているか、いないか。判定はどちらかしかありません。 インフラストラクチャが優先度に与える影響: デフォルトのままでは、モデルは脆弱性をデプロイのコンテキストから切り離して評価します。ステアリングファイルでは、優先度を割り当てる前に Infrastructure as Code (IaC) を解析し、コントロールごとの乗数を適用することを必須としています。 目指しているのは再現性です。誰がいつ分析を実行しても、同じコードベースからは同じ評価済みの検出結果が得られるべきです。重要なのは一貫性です。 重要な 5 つのセクション ステアリングファイルの全文は、関連リポジトリで公開しています。ここでは、特に重要な 5 つのセクションについて、その設計上の判断を説明します。 LLM を信頼するのではなく構造的に検証する Never trust an LLM's self-reported confidence about a vulnerability. Verify claims against the code structure: 1. Do referenced files exist? 2. Do referenced functions exist? 3. Does dataflow confirm the claim? 4. Is there a call path? If a finding fails all structural checks, reject it regardless of how convincing the narrative sounds. これは、ファイル内で最も重要な指示です。この指示がないと、モデルはもっともらしい攻撃チェーンを生成してしまいます。しかし、その攻撃チェーンが参照しているのは、3 コミット前に名前が変更された関数、別のパッケージにあるファイル、あるいはモデルが見落としたサニタイズ処理を通過するデータフローです。 検証したところ、ステアリングなしのモデルによる検出結果の約 30% が、対象リポジトリに存在しないコード構造を参照していました。解釈の誤りではなく、完全に捏造されたパスです。報告前に検証するよう指示したところ、テストでは捏造されたパスはゼロになりました。 ここで重要なのは、セキュリティ分析におけるハルシネーションは些細な問題では済まないという点です。ハルシネーションによる検出結果が 1 件でも開発者に届けば、パイプライン全体の信頼性は急速に損なわれます。捏造された脆弱性を目にしたエンジニアは、その後レポートを読まなくなる可能性が高くなります。 証拠ベースの信頼度スコアリング 次の式は、モデルの直感的な信頼度を、観測可能なシグナルから計算するスコアに置き換えるものです。各要素は二値で、確認済みか未確認かのどちらかです。 confidence = 0.30 * taint_confirms_flow + 0.25 * no_sanitization_found + 0.20 * entry_point_is_public + 0.15 * call_graph_confirms_path + 0.10 * sink_type_matches_category テイントの確認に最も高い重み (0.30) を設定したのは、確認済みのデータフローパス (ユーザーが制御するデータがセキュリティ上重要な操作に到達するという証拠) が、検出結果が本物であることを示す最も有力な予測因子だからです。脆弱性が既知のアプリケーションを対象とした検証では、テイントが確認され、かつサニタイズが見つからなかった検出結果は、89% が悪用可能でした。一方、構造的な確認なしにモデルが HIGH confidence (HIGH の信頼度) と報告した検出結果のうち、悪用可能だったのは 34% にとどまりました。 この式はあくまで出発点であり、固定された標準ではありません。重みには、チーム独自の検証データを反映させてください。既知の真陽性と偽陽性をラベル付けしたデータセットに対してこの式を実行し、適合率 (precision) がチームのノイズ許容度に合うまで調整します。 インフラストラクチャを考慮した評価 このセクションは、よくある過剰な優先順位付け、つまり補完的コントロールが既に導入されているにもかかわらず、脆弱性を緩和前の重大度のまま報告してしまう問題に対処するものです。 score_after_controls = max(0.15, score * block_1 * block_2 * ... * block_n) コントロールは、特定の脆弱性クラスにマッピングされます。SQL インジェクションルールをブロッキングモードで適用した AWS WAF は、SQL インジェクションに対しては STRONG コントロール (乗数 0.25 倍) ですが、デシリアライゼーション攻撃には効果がありません。ステアリングファイルでは、このマッピングをモデルに推測させるのではなく、明示的に規定しています。 攻撃ブロック型コントロールの乗数を掛け合わせ、下限値を 0.15 とすることで、多層防御の考え方をエンコードしています。複数のコントロールを組み合わせれば単一のコントロールよりもリスクは下がりますが、どのような組み合わせでもリスクがゼロになることはありません。下限値を設けることで、脆弱性が完全に緩和されたので無視してよい、とモデルが結論付けるのを防ぎます。 検証を通じてわかった注意点があります。アクセスコントロール (認証と認可) と攻撃ブロック型コントロール (AWS WAF ルールと入力検証) は、果たす役割が異なります。認証が制限するのは、 誰が エクスプロイトを試みられるかです。認証済みのユーザーがエクスプロイトを試みたときに 何が起こるか までは制限しません。 AWS Identity and Access Management (IAM) の認証で保護されていても、コマンドインジェクションはコマンドインジェクションです。攻撃者の母数は小さくなりますが、悪用されたときの影響は変わりません。ステアリングファイルでは、一律の乗数を適用するのではなく、コントロールの種類ごとに特定のスコア構成要素へマッピングすることで、この違いを反映しています。 脅威インテリジェンスの統合 ステアリングファイルでは、 CISA Known Exploited Vulnerabilities (KEV) カタログ と Exploit Prediction Scoring System (EPSS) のシグナルを取り入れ、脅威インテリジェンスが現実的な悪用リスクを示す場合に優先度を引き上げます。 次の表に、ステアリングファイルが認識する主なシグナルと、各シグナルが検出結果のスコアに与えるブーストを示します。各シグナルは、実環境での悪用リスクについて、それぞれ異なる観点から答えを提供します。 CISA KEV – 攻撃者が実環境でその脆弱性を悪用したことを示し、ランサムウェアキャンペーンとの関連の有無も示します。 EPSS – 今後 30 日以内に攻撃者がその脆弱性を悪用する確率を推定します。 公開されている概念実証 (PoC) – 動作するエクスプロイトコードが既に公開されており、攻撃者にとって残りの作業がほとんどないことを示します。 シグナル ブースト 悪用が確認されている (CISA KEV) +0.30 ランサムウェアとの関連あり (CISA KEV) +0.15 EPSS >= 0.5 +0.20 公開 PoC あり +0.10 脅威インテリジェンスがスコアの大半を占めてしまわないよう、ブーストの合計には +0.50 の上限を設けています。攻撃者に狙われているからといって、脆弱性が技術的に悪用しやすくなるわけではありません。しかし、理論上悪用可能な状態から実際に悪用される状態までの期間は非常に短い場合があるため、緊急度は高くなります。 緊急度と重大度は、意図的に区別しています。重大度が中程度の依存関係の脆弱性であっても、ランサムウェアグループに実際に悪用されているのであれば、複雑な前提条件が必要で既知のツールも存在しない、重大度がクリティカルのコードレベルの検出結果よりも迅速に対応する必要があります。 優先度分類 スコアリングで得られるのは数値であり、優先度分類はその数値を判断に変換します。検出結果を受け取る開発者が必要としているのは、この判断です。 次の表は、ステアリングファイルで定義している 4 つのアクション階層を示しています。スコアと証拠のしきい値によって検出結果が該当する階層が決まり、階層ごとに具体的な対応が規定されています。ステアリングファイルでは、これらのしきい値を最終スコアと比較します。最終スコアとは、ベーススコアに攻撃ブロック型コントロールの乗数と、該当する場合は脅威インテリジェンスのブーストを適用した後のスコアです。この記事の前半で紹介した式による信頼度の値でも、スキャナーが報告した重大度でもない点に注意してください。 優先度 基準 アクション P0 スコア >= 0.8、効果的な攻撃ブロック型の緩和策なし 直ちに修正 P1 スコア >= 0.6 または現実的な悪用リスクを示す脅威インテリジェンスあり 今回のスプリントで修正 P2 スコア >= 0.4、部分的な証拠あり 対応余力があるときに調査 P3 スコア < 0.4 または効果的に緩和済み リスクを受容、またはバックログに追加 ファイル内で最も議論を呼ぶ指示は、 Do not file P3 findings as security issues. (P3 の検出結果をセキュリティ課題として起票しない) です。この指示を含めたのは、信頼度の低い検出結果や完全に緩和済みの検出結果までチケットとして起票すると、チームがセキュリティツールを無視するようになるからです。偽陽性や無関係な検出結果がバグとして起票されるたびに、システムの出力に対する関心は薄れていきます。確認済みの検出結果を 10 件出すパイプラインの方が、確証のない検出結果を 200 件出すパイプラインよりも、エンジニアリングチームの注目を集めます。 検証結果 既知の脆弱性を 10 件 (悪用可能なもの 8 件と、インフラストラクチャのコントロールで緩和されているもの 2 件) 含む、検証専用の脆弱なアプリケーションを使ってステアリングファイルをテストしました。このアプリケーションには、SQL インジェクションルールをブロッキングモードで適用した AWS WAF、 Amazon Virtual Private Cloud (Amazon VPC) で分離された AWS Lambda 関数、各エンドポイントでの IAM 認証が含まれています。 ステアリングファイルなしの場合 、モデルは 10 件の脆弱性をすべて検出し、緩和済みの 2 件を正しく低い優先度と判断しました。しかし、重大度は証拠ではなく直感 ( this is a command injection, so it’s CRITICAL : これはコマンドインジェクションなので CRITICAL) に基づいて割り当てられ、主張に対する構造的検証も行われませんでした。 ステアリングファイルありの場合 、モデルは 10 件中 9 件の脆弱性を検出しました (検出しなかったのは、単体テストのコードに意図的に埋め込まれ、定義されているものの呼び出されていないハードコードされた認証情報です)。さらに、緩和済みの 2 件の検出結果を、根拠を文書化したうえで正しく P3 に引き下げ、各検出結果の信頼度の計算過程を示し、主張した各データフローを実際のコードと照合して検証しました。 スコアリングのキャリブレーションには、1 回のイテレーションが必要でした。初期バージョンでは認証を一律の乗数として適用していたため、影響の大きさにかかわらず、IAM で保護されたすべての検出結果が P2 に抑えられていました。そこで、アクセス制限型コントロール (到達可能性のスコア構成要素を低減) と攻撃ブロック型コントロール (信頼度スコア全体を低減) を分けて扱うように修正しました。現在のバージョンでは、IAM 認証で保護されたコマンドインジェクションを正しく P0 に分類します。認証によって到達できるユーザーは限られますが、悪用された場合の影響はリモートコード実行であることに変わりはないからです。 ステアリングファイルの使用方法 ここでは 3 つのオプションを紹介します。常時有効な Kiro のステアリングファイルとして使う方法、同じ内容をオンデマンドで使える Kiro のスキルとして使う方法、そして同じ内容を Claude Code などのアシスタントで利用する方法です。 オプション 1: Kiro のステアリングファイルとして使用する ステアリングファイルを、リポジトリの .kiro/steering/vuln-triage.md に配置します。Kiro の組み込みのデフォルトエージェントを使用するセッションでは、指示が自動的に読み込まれます。コードのセキュリティ問題の分析をモデルに依頼すると、追加のプロンプトなしでこの手法が適用されます。 デフォルトではなくカスタムエージェントを使用している場合、ステアリングファイルは自動的に読み込まれません。エージェントの resources にファイルを明示的に追加する必要があります。 { "resources": ["file://.kiro/steering/**/*.md"] } your-repo/ ├── .kiro/ │ └── steering/ │ └── vuln-triage.md ← steering file ├── src/ ├── cdk/ └── ... また、 ~/.kiro/steering/ に配置すると、単一のリポジトリだけでなく、マシン上のすべてのワークスペースにこの手法を適用できます。 オプション 2: Kiro のスキルとして使用する 毎ターンでコンテキストウィンドウを消費するのではなく、必要なときにだけこの手法を使いたい場合は、スキルとして配置します。Kiro は起動時にスキルの名前と説明だけを読み込み、スキルが有効化された時点で指示の全文を取り込みます。そのため、関係のない会話に指示が入り込むことはありません。 スキルは、 SKILL.md ファイルを含むフォルダです。フォルダ名は、YAML フロントマターの name と一致させる必要があります。 name: vuln-triage description: Structured vulnerability triage methodology with evidence-based scoring and infrastructure-aware prioritization. Use when analyzing code for security vulnerabilities. your-repo/ ├── .kiro/ │ └── skills/ │ └── vuln-triage/ │ └── SKILL.md ← skill file ├── src/ └── ... Kiro のデフォルトエージェントは .kiro/skills/ 内のスキルを自動的に検出するため、設定は不要です。スキルは、Kiro がリクエストと説明を照合して合致すると判断したときに自動的に有効化されるか、スラッシュコマンドで明示的に有効化されます。 vuln-triage という名前のスキルは /vuln-triage として呼び出せるため、エンジニアは必要なときに評価を実行できます。 > /vuln-triage focus on the authentication changes スキルを ~/.kiro/skills/ に配置すると、マシン上のすべてのプロジェクトで使用できます。デフォルトではなくカスタムエージェントを使用している場合、スキルは自動的に読み込まれないため、エージェントのリソース (resources) にスキルを追加する必要があります。 { "resources": ["skill://.kiro/skills/*/SKILL.md"] } オプション 3: 他のツール向けに適応させる この手法は Kiro 専用ではありません。リポジトリには、同じ内容を Claude Code 用の CLAUDE.md ファイルとしても収録しています。また、この原則は、リポジトリから永続的な指示を読み込むアシスタントであれば、どれにでも適用できます。想定されるファイル名と配置場所については、各ツールのドキュメントを参照してください。 ステアリングファイルでは代替できないもの ステアリングファイルが提供するのは手法であり、それを実行する仕組みではありません。検出結果について どう考えるか をモデルに指示しますが、次の機能は提供しません。 プログラムによるテイント追跡: モデルは、コードを読んでデータフローを推定します。一方、専用のテイントトラッカーは、抽象構文木 (AST) に基づいてデータフローを決定論的に確認します。Python のコードベースであれば、Tree-Sitter などのパーサーを基盤とした静的解析ツールでこれを実現できます。それ以外の言語では、モデルによる推定は妥当ではあるものの、確実な根拠にはなりません。 稼働中のインフラストラクチャの検証: ステアリングファイルは、IaC ファイルを解析するようモデルに指示します。しかし、API コールを実行して、デプロイ済みの環境で AWS WAF ルールが Amazon API Gateway にアタッチされていることや、デプロイ後にセキュリティグループが変更されていないことまでは検証できません。 脅威インテリジェンスフィード: このファイルは、 CISA KEV と EPSS のデータを考慮するようモデルに指示します。モデルのトレーニングデータには過去の KEV エントリが含まれていますが、ライブフィードを照会することはできません。最新の悪用状況を把握するには、API 統合が必要です。 実行ベースの検証: ステアリングファイルで得られるのは、評価済みの検出結果です。稼働中の環境に対して PoC を実行し、悪用可能性を確認するには、サンドボックス、リクエスト署名、差分テスト用のインフラストラクチャといった追加のツールが必要です。 これらの機能を加えるごとに、パイプラインの信頼性は高まります。ただし、これらの機能がなくても、ステアリングファイルを使えば、ステアリングなしのモデルと比べて定量的にも優れた結果が得られます。構造化された検出結果、引用された証拠、インフラストラクチャを考慮した優先順位付けです。とはいえ、ステアリングファイルは成熟したハーネスの最初のレイヤーにすぎず、システム全体ではありません。 次のステップ ステアリングファイルを使えば、AI を活用した脆弱性トリアージのための構造化された手法を、今すぐチームに導入できます。既存のツールでそのまま動作し、インフラストラクチャの変更も、新しいサービスも、調達プロセスも必要ありません。 ステアリングファイルは GitHub リポジトリ で公開しています。ぜひ実際に使用し、環境に合わせて調整して、気付いた点をお知らせください。 著者らは、AWS でセキュリティの自動化に取り組んでいます。ここで紹介したパターンは、複数のチームとデプロイ環境で、AI を活用した脆弱性検出システムを構築、検証する中で生まれたものです。 Justin Kontny Justin は AWS の Senior Software Engineer, Security で、ソフトウェア開発への情熱とクラウドセキュリティに関する深い専門知識を兼ね備えています。AI-Driven Development Lifecycle (AIDLC) のプラクティスを用いたエージェンティックなセキュリティソリューションの構築に注力し、セキュリティを障壁からビジネスを後押しするものへと変えることに取り組んでいます。仕事以外では、子どもたちと過ごしたり、アウトドアで体を動かしたりすることを楽しんでいます。 Ievgeniia Ieromenko Ievgeniia は AWS の Software Development Engineer です。デリバリーを遅らせることなくセキュリティポスチャを強化するためのツールやエージェンティック AI システムを構築しています。仕事以外では、旅行やボランティア活動、そしてとてもお利口な愛犬 Pickle とのアウトドアでの冒険を楽しんでいます。 Nidhi Ramakant Nidhi は AWS の Software Development Manager で、セキュリティとエンタープライズアーキテクチャの分野で 20 年の経験があります。お客様が環境をセキュアに保てるよう支援することや、セキュリティ上の意思決定を容易にする創造的なソリューションを構築することに情熱を注いでいます。また、周囲の人材育成にも同じように力を入れています。仕事以外では、番組を一気見したり、子どもたちが安全に探求し学べるよう、セキュアなローカル LLM 向けのアプリをバイブコーディングしたりしています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 10 月 7 日に公開された AWS Blog “ Building your AI vulnerability harness, Part 1 ” を翻訳したものです。 脆弱性スキャナーが検出結果を生成するペースは、手動のトリアージで処理できる速度を上回っています。開発者が多くの依存関係を伴うコードをより多くリリースするにつれて、検出結果の候補も増え続けます。 スキャナーが生成する検出結果の多くは、悪用される可能性が低いものです。重要な検出結果は、エンジニアが分析をやり直さずに直ちに対応できるだけの証拠を添えて、すばやく届ける必要があります。課題は、パイプラインが求めるスピードでシグナルとノイズを見分けることです。 この記事では、検出から対応までのギャップを埋める方法を紹介します。スキャナーが出力した未加工の検出結果を、悪用可能性の証拠が文書化された、優先順位付きの少数の検出結果に絞り込む 3 層のパイプラインを構築しました。関連記事「 ステアリングファイルで実現する証拠ベースの脆弱性トリアージ 」では、このパイプライン内でモデルの動作を制御するステアリングファイルについて取り上げます。この記事では、そのステアリングファイルを取り巻く各層について説明します。 パイプラインの価値は、特定のツールではなく、フィルタリングロジックと証拠の基準から生まれます。そのため、アーキテクチャを変えずに、お使いのスキャナーやモデルに置き換えることができます。お使いの AI プロバイダー、インフラストラクチャスタック、スキャナーの組み合わせは、この記事で使用したものとは異なるでしょう。しかし、各層で何をフィルタリングするか、何を証拠とみなすか、どこでモデルを信頼するのをやめるかといったアーキテクチャ上の判断は、環境にかかわらず応用できます。 テストハーネスとは テストハーネスとは、制御された入力をシステムに与え、出力が期待される動作と一致するかどうかを観察する自動化されたフレームワークです。脆弱性検出に適用する場合、ハーネスは検出結果の候補ごとに悪用可能性を評価するテストを作成し、そのテストを制御された環境で実行して、証拠を記録します。ハーネスはテストのためのインフラストラクチャであり、それが生成する結果そのものではありません。 従来の静的アプリケーションセキュリティテスト (SAST) ツールはパターンマッチングに依存しており、データフロー分析の能力はツールや言語によって異なります。既知のパターンに当てはまるシンクの検出は得意ですが、マルチホップのチェーン、ビジネスロジックの欠陥、コンテキストに依存するサニタイズ、そしてシンクが攻撃者の制御する入力から到達可能かどうかの判断は苦手です。AI で強化した分析は、こうした推論のギャップを補います。具体的には、ファイルをまたいでデータを追跡し、意図を推測し、デプロイコンテキストを考慮します。 概念上の重要な違いは、モデルをコードベースに対して実行するわけではないという点です。コードベースは、特定のプロンプトと共にモデルに渡すコンテキストです。モデルはコードを受け取り、データがどのように流れるか、信頼境界がどこにあるか、セキュリティに関連するパターンが存在するかどうかを推論します。 コンテキストのスコーピングは、このアーキテクチャの中でも難しい部分の 1 つです。コンテキストが多すぎるとモデルの推論ウィンドウを圧迫するおそれがあり、少なすぎると分析に抜けが生じて検出漏れ (false negative) を招くおそれがあるためです。基本的な AWS Lambda 関数であれば、関連するコンテキストは単一のファイルとその AWS Identity and Access Management (IAM) ロールだけで済むかもしれません。一方、共有ライブラリと階層化されたインフラストラクチャを備えた複雑なマイクロサービスの場合、何を含めるかを判断するには、アプリケーションの依存関係グラフを理解する必要があります。デプロイトポロジーをモデルに提供すれば、モデルはそれについても推論できます。例えば、 AWS Cloud Development Kit (AWS CDK) のコンストラクトや AWS CloudFormation テンプレートを追加のコンテキストとして渡す方法があります。一般に、すべてを一度に渡すよりも、まず範囲を狭くして始め、モデルの初期評価で結論が出ない場合にだけ範囲を広げる方が、良い結果が得られます。 パイプラインの構築 セキュリティスキャナーは、実行するたびに大量の検出結果を生成することがあります。その多くは、脆弱性のように見えて実際には問題ではない誤検知 (false positive) です。本当の問題とノイズを区別するために、パイプラインは 3 つの層で検出結果をフィルタリングします。各層では、それぞれ異なる種類の証拠を用います。最終的には、文書化された証拠に裏付けられた、優先順位付きの少数の問題が残ります。 第 1 層: 複数スキャナー間の一致 最初に確認するのは妥当性です。同じコードベースに対して複数のスキャナーをそれぞれ独立して実行します。2 つ以上のスキャナーが同じ検出結果を示した場合、信頼度が高まります。1 つのスキャナーだけが問題を報告し、他のツールがいずれも同じ検出結果を示さない場合は、パイプラインがその検出結果に追加の精査が必要であることを示すフラグを付けます。 複数スキャナー間の一致と呼ばれるこのアプローチは、低コストで信頼度を高められる方法です。既存のツールをそのまま利用でき、新たなインフラストラクチャも必要ありません。 第 2 層: 構造検証 第 2 層では構造を検証します。AI を活用したスキャナーは、脆弱性がどのような仕組みで成立するかについての自らの推論を説明します。例えば、データがある関数から入り、別の関数を経由して、害を及ぼし得る箇所に到達する、といった説明です。ただし、こうした説明が誤っている場合もあります。 検出結果を次の層に進める前に、パイプラインは実際のコードと照合して検証します。スキャナーが言及した関数やファイルが存在するかどうか、そしてスキャナーが説明した経路に沿ってデータが流れ得るかどうかを確認します。確認できない場合、パイプラインはその検出結果を却下します。 この検証ステップでは、コードの抽象構文木 (AST) を使用します。AST とは、コードベース内の関数、ファイル、データフローのつながりを表す構造化されたマップです。このステップは、パイプラインの出力の信頼性を保つのに役立ちます。検証されていない検出結果がレビュー担当者に届くと、チームはすぐに結果を信用しなくなり、ツールのセキュリティ上の価値が損なわれます。 第 3 層: デプロイコンテキスト 最後の層では、デプロイコンテキストを加味します。脆弱性はアーキテクチャというコンテキストの中に存在し、そのアーキテクチャには保護コントロールが含まれている場合があります。こうしたコントロールには、 AWS WAF ルール、ネットワーク分離、認証要件、入力検証などがあります。 この層では、アプリケーションのソースコードと併せて、Infrastructure as Code (IaC) テンプレート (クラウドアーキテクチャを定義する CloudFormation や Terraform のファイルなど) を読み込みます。そのうえで、攻撃者が既存のコントロールを回避して脆弱性を悪用できるかどうかを確認します。 コントロールによって保護のレベルは異なります。該当する攻撃手法を直接ブロックするウェブアプリケーションファイアウォールのルールは、別の種類の脆弱性を対象とするルールよりも強力な緩和策になります。パイプラインは、コントロールの有効性を「はい」か「いいえ」の二択ではなく、段階的な尺度として扱います。 結果 最終的に得られるのは、少数に絞り込まれた検出結果のリストです。各検出結果は 3 つの層をすべて通過しています。つまり、妥当性チェックに合格し、構造がコードと一致し、デプロイコンテキストから悪用可能であることが示されています。層を経るごとに検出結果の数は減り、残った検出結果に対する信頼度は高まります。 原則 このパイプラインを構築する中で、4 つの原則が見えてきました。 証拠の要件を高めながら進める段階的なフィルタリング – 各層では、それぞれ異なる種類の証拠が求められます。第 1 層では検出結果が妥当であることを確認し、第 2 層では構造的に実在するかどうかを判断し、第 3 層ではコンテキストにおいて悪用可能かどうかを分析します。包括的な 1 つの層よりも、焦点を絞った 3 つの層の方が効果的です。層ごとに異なる種類のエラーをとらえられるためです。 インフラストラクチャのコンテキストが優先順位付けを変える – デプロイコンテキストがなければ、重大度がクリティカルな検出結果は、重大度が中程度の検出結果よりも緊急性が高いと考えがちです。しかし、強力な保護コントロールの背後にあるクリティカルな検出結果の方が、インターネットに直接公開されている中程度の検出結果よりも緊急性が低い場合があります。この評価を行うには、パイプラインがアプリケーションのソースコードだけでなく、IaC テンプレートにもアクセスできる必要があります。 独立したツール間の一致は単一ツールの信頼度に勝る – あらゆる種類の脆弱性を確実に検出できるスキャナーは 1 つもありません。あらゆる状況で正しい結果を出せるモデルも存在しません。独立した複数のツールが同じ検出結果で一致した場合、その一致は、1 つのツールが自己申告する信頼度スコアよりも強いシグナルになります。この原則は、どのツールを選んでも概ね当てはまります。 AI が生成した主張は人によるレビューの前に検証が必要 – 言語モデルは、もっともらしく聞こえても正しいとは限らない出力を生成することがあります。AI が生成した検出結果を、人がレビューする前に実際のコード構造と照合して検証することが、有用なシステムと、自信ありげな誤りで信頼を損なうシステムの分かれ目です。 スタックへの適用方法 すべてを一度に構築する必要はありません。すぐに効果が得られるものから順に導入してください。 インデックス作成から始める – エントリポイント、シンク、認証設定を洗い出せる、AST ベースのコードベースのインデックスを構築 (または既存のものを利用) します。実行コストはかからず、AI を使う前の段階でアタックサーフェスのマップが得られます。 複数スキャナーによるトリアージ を追加する – 既に利用している Semgrep 、 CodeQL 、または同等のツールの出力を AST ゲートに通し、さらに大規模言語モデル (LLM) で悪用可能性を分類します。既に実行しているツールの出力をフィルタリングするだけなので、わずかな投資で大幅なノイズ削減を実現できます。 仮説生成を追加する – トリアージが安定したら、スキャナーが見逃す脆弱性 (マルチホップのチェーン、ビジネスロジックの欠陥、パッケージをまたぐデータフロー) を AI 主導で発見する仕組みを追加します。このステップでは、ステアリングの品質が結果を大きく左右します。詳細については、関連記事「 ステアリングファイルで実現する証拠ベースの脆弱性トリアージ 」を参照してください。 インフラストラクチャのコンテキストを追加する – CDK または CloudFormation を解析し、コントロールを脆弱性クラスにマッピングして、乗数を適用します。これにより、優先順位付けの精度が高まります。 ライブ検証を追加する – デプロイ済みの本番前環境のターゲットに対して、構造化された成功基準を設けて、脆弱性の悪用可能性を示す概念実証 (PoC) を実行します。このステップは運用上のオーバーヘッドが最も大きいため、最後のステップとして、信頼度のしきい値を既に満たした検出結果に対してのみ実行してください。 パイプラインは、時間をかけて調整していくものととらえてください。既知の正しい検出結果と誤検知を使って検証し、重みを調整して再実行します。結果は変わっていきます。 このハーネスで解決できないこと ハーネスは検出のためのインフラストラクチャです。どの検出結果が実際の問題である可能性が高く、どれに優先して対応すべきかを把握するのに役立ちます。ただし、ハーネスでは次のことはできません。 コードを修正すること – 修正は別の課題です。ハーネスは、人またはエージェントが対応できるだけの証拠を備えた検出結果を生成しますが、修正作業そのものには専用のツールとプロセスが必要です。 最終的な対応に向けた人によるレビューを代替すること – 3 層のフィルタリングを経た後でも、出力されるのは悪用可能と考えられる検出結果の優先順位付きリストであり、実証済みのエクスプロイトではありません。優先度 0 (P0) の検出結果であっても、コード変更に着手する前にエンジニアがレビューする必要があります。 スキャナーの組み合わせの検出範囲外にある脆弱性クラスを検出すること – 特定の脆弱性カテゴリを対象とするスキャナーが 1 つもなければ、ハーネスがその脆弱性を検出することはありません。AI で強化した仮説生成によってこのギャップの一部は埋められますが、新しい種類の欠陥やビジネスロジックの欠陥を検出できるかどうかは、依然としてモデルがコードだけからどこまで推論できるかに左右されます。 稼働中のインフラストラクチャの状態をデフォルトで検証すること – IaC を解析すれば、何が定義されたかはわかります。しかし、先週 WAF ルールが無効化されたかどうかや、デプロイ後にセキュリティグループが変更されたかどうかはわかりません。ライブ検証は追加で統合するものであり、各層そのものが備える特性ではありません。 これらの制限はいずれも、アーキテクチャが破綻する箇所ではなく、拡張できる箇所を示しています。ハーネスは複数階建てのシステムの 1 階部分にすぎず、建物全体ではありません。 次のステップ この記事では、複数スキャナー間の一致、構造検証、デプロイコンテキストの 3 層からなるパイプラインによって、スキャナーの出力を、チームが対応できる信頼度のより高い少数の検出結果に絞り込む方法を紹介しました。このアーキテクチャは特定のツールに依存しません。応用できるのは、どこでフィルタリングするか、何を証拠とみなすか、どの時点でモデルを信頼するのをやめるか、という考え方です。 モデルが一貫した指示を受け取れば、このアーキテクチャは一貫した結果を生み出します。関連記事「 ステアリングファイルで実現する証拠ベースの脆弱性トリアージ 」では、この手法を機械で実行可能な指示としてまとめたステアリングファイルについて説明します。ステアリングファイルには、信頼度の計算式、インフラストラクチャコントロールの乗数、ハルシネーションによる検出結果がエンジニアに届くのを防ぐのに役立つ検証ゲートが含まれます。適切に作成された指示があれば厳密で証拠に基づいた評価を行うモデルでも、そうした指示がなければ、重大度を過大に評価したり、存在しない攻撃チェーンを作り出したりする可能性があります。能力を判断力へと変えるのは、設定なのです。 脆弱性が公開されてから悪用されるまでの期間は短くなっています。開発ワークフローに自動検出を組み込むことは、チームがそのスピードに遅れずに対応するのに役立ちます。このパイプラインは試行錯誤を重ねて構築したものです。その過程で経験した失敗の一部を避けられるよう、ここで共有します。 この記事で紹介したサービスの詳細については、 AWS Lambda 、 AWS WAF 、 AWS CloudFormation のドキュメントを参照してください。 Nidhi Ramakant Nidhi は AWS の Software Development Manager で、セキュリティとエンタープライズアーキテクチャの分野で 20 年の経験を持っています。お客様の環境のセキュリティ確保を支援することや、セキュリティに関する意思決定を容易にする独創的なソリューションを構築することに情熱を注いでいます。周囲の人材の育成にも同じように力を入れています。仕事以外では、番組を一気に視聴したり、子どもたちが安全に探索しながら学べるよう、安全なローカル LLM 向けのアプリをバイブコーディングしたりしています。 Ievgeniia Ieromenko Ievgeniia は AWS の Software Development Engineer で、デリバリーのスピードを落とすことなくセキュリティポスチャを強化するためのツールやエージェンティック AI システムを構築しています。仕事以外では、旅行やボランティア活動の他、とてもお利口な愛犬 Pickle と一緒にアウトドアを楽しんでいます。 Justin Kontny Justin は AWS の Senior Software Engineer, Security で、ソフトウェア開発への情熱とクラウドセキュリティに関する深い専門知識を兼ね備えています。AI-Driven Development Lifecycle (AIDLC) のプラクティスを用いたエージェンティックなセキュリティソリューションの構築に注力し、セキュリティを障壁からビジネスを後押しするものへと変えることに取り組んでいます。仕事以外では、子どもたちと過ごしたり、アウトドアで体を動かしたりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの梅田です。 AWS Japan パブリックセクターチームでは、2026 年 4 月から、官公庁・自治体・教育・医療などパブリックセクターのお客様に向けて、セキュリティワークショップを月 1 回開催しています。これまでに「 ランサムウェア対策 」「 Claude Mythos 時代の脅威対策 」「 耐障害性ライフサイクル 」を取り上げてきました。第 6 回となる今回は、 AWS WAF を使った Web アプリケーションの防御をテーマにしました。本記事はその開催報告です。 ワークショップの概要 項目 内容 日時 2026 年 9 月 28 日（月）14:30 – 17:30 形式 オンライン 対象 システムアーキテクト、セキュリティ担当者、Web アプリケーション運用担当者 関連サービス AWS WAF, AWS Shield, Amazon CloudFront, Amazon Athena  構成は前半の座学と後半のハンズオンの 2 部です。座学では AWS WAF の仕組みと運用の考え方を解説し、ハンズオンでは WAF ルールの設定からログの分析までを実際に操作していただきました。講師はパブリックセクター 中央省庁担当のソリューションアーキテクト、伊藤 裕史が務めました。 座学: AWS WAF を活用した Web アプリケーションの保護 Bot は「止める」のではなく「見分ける」 Web のトラフィックのうち 30〜51% は、人間以外によるものだという調査があります。Bot の種類も変わってきました。以前からある検索エンジンのクローラーやスパム Bot に加えて、LLM の学習用にコンテンツを集める Bot や、人に代わってブラウジングや買い物をする AI エージェントが増えています。こうした Bot の中には、正規のものも悪意のあるものもあります。そのため「Bot だから止める」という一律の対応ではうまくいきません。種類ごとに適切なアクションを選ぶ必要があります。 図 1: Bot アクティビティの進化 マネージドルールとラベルで細かく制御する AWS WAF では、リクエストを検査するルールを Web ACL に設定します。ルールに一致したリクエストには、Allow、Block、Count、CAPTCHA、Challenge のいずれかのアクションを適用します。ルールを一から自作する必要はありません。AWS が管理・更新する マネージドルールグループ を有効にするだけで、SQL インジェクションやクロスサイトスクリプティングといった代表的な攻撃に対応できます。 Bot 対策には AWS WAF Bot Control ルールグループを使います。Bot Control は、逆引き DNS による検証や振る舞いの分析を組み合わせて、Bot が名乗っているとおりの「検証済みの Bot」かどうかを判別します。判別の結果はラベルとしてリクエストに付与され、後続のルールでそのラベルを条件に使えます。たとえば「利用している監視サービスの Bot は通し、それ以外の監視 Bot は止める」といった細かい制御ができます。 入れて終わりではなく、可視化しながら育てる ルールは、導入してしまえば終わりというものではありません。最初は Count で動かして影響を確かめ、誤検知がないことを確認してから Block に切り替えます。その後も監視を続け、結果に応じてルールを見直していきます。このサイクルを回すことが、WAF 運用の基本になります。 図 2: AWS WAF の運用全体像 運用を支える機能として、AWS WAF には組み込みのダッシュボードがあり、追加の設定なしで使えます。また、AI クローラーや AI エージェントからのアクセスに絞った AI トラフィック分析ダッシュボードも提供されています。このダッシュボードでは、650 以上の Bot とエージェントを識別し、それぞれのアクセス先や検証状況を一覧で確認できます。 図 3: AI トラフィック分析ダッシュボード 座学ではこのほかに、 AWS Shield の Standard と Advanced の違いも紹介しました。 ハンズオン: AWS WAF で Web アプリケーションの防御を強化する ハンズオンでは、公開教材「 AWS WAF を使って Web アプリケーションの防御を強化する 」を使いました。参加者ごとに用意した環境で、次の 3 つに取り組んでいただきました。 Count で動いているマネージドルールを Block に切り替え、SQL インジェクションやクロスサイトスクリプティングを防ぐ Bot Control とラベルを使ったカスタムルールで Bot を制御し、JSON 本文の検査で API への入力を検証する Amazon Athena で WAF のログを分析し、ブロックの多いルールや URI パスを特定する 環境には進捗ダッシュボードが用意されており、ルールを変更するとその効果がすぐに反映されます。 参加者からのフィードバック ハンズオンの難易度については、技術職の方のほとんどから「ちょうど良い」という回答をいただきました。質疑では、「生成 AI 経由の大量リクエストにマネージドな方法で対処できるか」という質問がありました。これに対しては、まず Bot Control が付与するラベルでアクセスの実態を把握し、悪意のない単一の送信元からのアクセスであればレートベースのルールで抑える、という考え方をご紹介しました。 まとめ 今回のワークショップでお伝えしたかったのは、次の 3 点です。 Bot を一律に止めず、種類を見分けて対応する マネージドルールを使って運用の負荷を抑える 可視化しながら、ルールを継続的に見直す 今後も、パブリックセクターのお客様に向けたセキュリティワークショップを引き続き開催していきます。開催が決まりましたら、あらためてご案内します。 AWS WAF の導入・運用や AI Bot への対策についてご相談がある場合は、担当の AWS アカウントチームまでお気軽にお問い合わせください。 著者 梅田 昌太 (Shota Umeda) — AWS Japan, Public Sector, Senior Solutions Architect 田村 健祐 (Kensuke Tamura) — AWS Japan, Public Sector, Solutions Architect

本ブログは 2026 年 8 月 6 日に公開された AWS Blog “ Agent Skills for Automated Reasoning policies in Amazon Bedrock ” を翻訳したものです。 Amazon Bedrock の自動推論チェック (Automated Reasoning checks) を導入したチームの多くは、ポリシーのライフサイクルをコードで実行したいと考えています。コードで実行すれば、作業の再現性とレビューのしやすさを確保でき、普段使っているコーディングエージェントで進められます。ただし、優れた自動推論ポリシー (Automated Reasoning policy) を作成するにはある程度の習熟が必要で、ライフサイクルにはつまずきやすい制約もあります。ルールは SMT-LIB (自動定理証明器の標準入力形式) のサブセットで記述します。そのうえで、サービスが実際のユーザーの言葉を正しく変換できるようになるまで、変数の説明を調整します。さらに、独自の API と制約を持つビルド、テスト、改善のループを回しながら、ポリシーを仕上げていくことになります。 自動推論チェック は、出力を統計的にサンプリングするのではなく、形式論理に照らして検証するため、こうした労力をかける価値があります。このアプローチにより、AI の回答がルールに準拠していることを数学的な確実性をもって保証できます。以前の記事「 Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1 」では、Amazon Bedrock コンソールを使ってこのループを順に説明しました。最初に試すときや、対象分野の専門家と共同作業するときには、コンソールが適しています。 この記事では、Agent Skills のスイートを使用して、Amazon Bedrock の自動推論ポリシーの構築、テスト、デプロイ、検証をコーディングエージェントからエンドツーエンドで行う方法を説明します。また、このスイートを Amazon Bedrock に対して実行して明らかになった、サービスの動作に関する知見も紹介します。 Agent Skills とは? Agent Skills は、Anthropic が提供する軽量でオープンなフォーマットです。スキルは、専門的な知識とワークフローによってコーディングエージェントの機能を拡張します。その実体は、特定のサービスやドメインを正しく使う方法をエージェントに教える、構造化されたコンテキストパッケージです。これにより、エージェントは、不完全または古い可能性のある一般的なトレーニングデータに頼らずに済みます。各スキルには、検証済みのパターン、避けるべきよくある間違い、ステップバイステップのワークフローが含まれています。このガイダンスがあることで、エージェントはもっともらしい推測ではなく、タスクに適した API 呼び出しを生成できます。フォーマットがオープンなため、スキルは Kiro、Claude Code、Cursor、Codex など、このフォーマットをサポートするあらゆるエージェントにインストールできます。インストール後は、スキルの対象となるタスクをエージェントに依頼すると、スキルが自動的に有効になります。 エージェントが自動推論のライフサイクルに適している理由 自動推論チェックは 2 つのステップで実行されます。この役割分担を理解することが、自動推論チェックを使いこなす鍵です。まず、一連の基盤モデル (FM) が質問と回答を形式論理に変換し、自然言語をポリシー内の変数にマッピングします。次に、SMT (Satisfiability Modulo Theories、充足可能性モジュロ理論) ソルバー、すなわち制約に照らして論理式をチェックする自動推論エンジンが、その論理をルールに照らして検証し、判定を返します。検証ステップは数学的に健全であり、変換が忠実であれば判定は正しくなります。この健全性は、結果の説明可能性も支えています。すべての判定には、その判定を裏付ける、またはそれと矛盾する具体的なルールが併せて返されます。 図 1: 自動推論チェックの仕組み 実際に手間がかかるのは、このチェックを取り巻くライフサイクルです。ソースドキュメントからルールを抽出し、サービスが生成した内容をレビューし、ユーザーの実際の質問のしかたを反映したテストを作成し、失敗の原因を診断して、バージョン管理されたポリシーをガードレールに関連付けてデプロイします。各ステップの API 呼び出しにはそれぞれ固有の形式があり、中にはつまずきやすい制約を持つステップもあります。これは、ルールも失敗パターンも明確な、反復的で細部への注意を要する作業です。このような作業こそ、適切な指示を与えればコーディングエージェントが得意とするものです。 ポリシーのライフサイクル全体にわたる 6 つのスキル このスイートは 6 つの Agent Skills で構成されており、ライフサイクルの各段階に 1 つずつ対応しています。各スキルは、その段階で必要な判断をエージェントに教える短い指示ファイルで、Amazon Bedrock の自動推論 API を呼び出す小さな実行可能スクリプトがそれを支えています。すべてのスキルは、API の仕様、検出結果のタイプ、ルールの構文を説明する 1 つのリファレンスドキュメントを共有しているため、スイート全体でガイダンスの一貫性が保たれます。 図 2: ポリシーのライフサイクル全体にわたる 6 つのスキル ポリシーの作成時には、 builder スキルがソースドキュメントからポリシーを作成し、ルールと変数を抽出します。 reviewer スキルは、ビルドで生成された品質レポートと忠実度レポートを読み取り、ルールの競合、未使用の変数、条件を伴わないアサーションなどの問題を指摘します。 tester スキルはシナリオを生成し、質問と回答のテストを実行して、ポリシーが実際の入力を想定どおりに変換および検証できるかを確認します。 debugger スキルは失敗を診断してポリシーを修正します。その際は、誤った判定の原因はほぼ常にルールではなく変換にある、という原則に基づいて作業します。 ランタイムでは、 deployer スキルがポリシーのスナップショットを番号付きバージョンとして作成し、ガードレールにアタッチします。 validator スキルは、 ApplyGuardrail API を使用して回答をチェックします。さらに、失敗した回答に矛盾するルールをモデルにフィードバックし、回答の妥当性が確認されるまで繰り返す書き換えループを実行することもできます。 スキルの構成 各スキルは、Agent Skills の標準的なレイアウトに従っています。 SKILL.md ファイルには、その段階の中核となる指示が記述されています。これには、スキルを適用するタイミングや、その段階に固有の判断が含まれます。 references/ フォルダには、検出結果のタイプやルールの構文など、より深い内容の資料が格納されており、エージェントは詳細が必要なときにだけこれを読み込みます。 scripts/ フォルダには、Amazon Bedrock の自動推論 API を呼び出す実行可能な Python コードが格納されています。スクリプトはスタンドアロンで動作し、 --help フラグと --dry-run フラグに対応しています。これにより、オペレーションの内容を確認したり、実際に送信されるリクエストを Amazon Bedrock に届く前に検査したりできます。6 つのスキルの基盤となる共有ライブラリは、クライアントの作成、ビルドワークフローのポーリング、検出結果の解析、この記事の後半で説明するビルドスロットの制限の管理といった共通処理を担います。 ポリシードキュメントから検証済みの回答まで 以下のウォークスルーでは、育児休暇の取得資格に関する短い人事ポリシーを例に、ライフサイクル全体を実行します。流れをわかりやすくするために例は簡潔にしていますが、ローンの適格性ポリシーや保険の補償ポリシーなど、回答が明文化されたルールに従う必要がある他のドメインにも同じ手順を適用できます。 前提条件 自動推論チェックが利用可能な AWS リージョンで Amazon Bedrock にアクセスできる AWS アカウント、Amazon Bedrock のコントロールプレーン API とランタイム API に対する権限、スクリプトを実行するための Python と uv が必要です。リージョンごとの機能の提供状況については、Amazon Bedrock ドキュメントの「 自動推論チェック 」を参照してください。 訳注: 2026 年 9 月現在、自動推論チェックがサポートする言語は英語です。最新の対応状況は、Amazon Bedrock ユーザーガイドの「 Amazon Bedrock ガードレールの自動推論チェックとは 」を参照してください。 リポジトリをクローンし、コーディングエージェントにスキルをインストールします。 Claude Code では、スイートをプラグインマーケットプレイスとして追加し、必要なスキルをインストールします。 /plugin marketplace add ./amazon-bedrock-samples/responsible_ai/automated-reasoning-checks-skills /plugin install ar-policy-builder@automated-reasoning-skills Kiro、Cursor、Codex など、このオープンフォーマットをサポートする他のエージェントでは、 npx でインストールします。 # the skills live in a subfolder, so point npx at the full tree URL REPO=https://github.com/aws-samples/amazon-bedrock-samples SUBDIR=responsible_ai/automated-reasoning-checks-skills npx skills add $REPO/tree/main/$SUBDIR --skill '*' どちらの方法でインストールした場合も、ドキュメントからのポリシー作成や失敗したテストのデバッグなど、対応するタスクをエージェントに依頼すると、スキルが自動的に有効になります。 ポリシーの作成とルールの抽出 まず、ルールを平易な言葉で記述した短いソースドキュメントを用意します。例えば、「勤続 12 か月を超えるフルタイム従業員には育児休暇の取得資格があり、パートタイム従業員には資格がない」といった内容です。builder スキルがポリシーリソースを作成し、ドキュメントから形式的なルールと変数スキーマを抽出するビルドを開始します。 uv run create_policy.py --name "hr-leave-policy" \ --description "Validates parental leave eligibility answers" uv run build_from_document.py --policy-arn <policy-arn> \ --file leave-policy.txt --doc-name "Leave Policy" \ --instructions "Capture full-time status and tenure in months; focus on eligibility." ある実行では、3 文のソーステキストから、ビルドによって 6 つのルール、4 つの変数、1 つのカスタム型が抽出されました。この中には、勤続期間が負の値にならないようにする境界ルールも含まれています。 サービスが生成した内容のレビュー ルールの抽出は決定論的ではないため、テストの前に結果をレビューします。reviewer スキルは、品質レポートとポリシー定義を取得し、その内容を要約します。 uv run audit_policy.py --policy-arn <policy-arn> 監査では、ルール、変数、型の数が報告され、構造上の問題が重大度別に示されます。このポリシーでは、未使用の変数が 1 つと、他のルールと変数を共有しないルールセット (disjoint rule set) が 1 つ指摘されました。いずれもエラーではなく、検討の余地がある重大度の低い項目です。また、忠実度レポートが作成されなかったことも報告されます。これは、標準のコンテンツビルドでは忠実度レポートが生成されないためです。対象分野の専門家がソースとの対応関係を確認できるビューが必要な場合は、別のビルドタイプを指定して忠実度レポートをリクエストします。 テストの作成と実行 tester スキルは、質問と回答のテストを作成し、完了したビルドに対して実行します。テストでは、ユーザーがたずねそうな質問、モデルが返しそうな回答、想定される判定を指定します。 uv run create_test.py --policy-arn <policy-arn> \ --input "I'm full-time with 18 months. Am I eligible for leave?" \ --output "Yes, you are eligible for parental leave." \ --expected VALID uv run run_tests.py --policy-arn <policy-arn> テストワークフローは、想定される判定と実際の判定、およびそれらが一致したかどうかを返します。このポリシーでは回答が VALID と判定され、実際の結果は想定どおりでした。 ガードレールに関連付けたデプロイと回答の検証 ポリシーがテストに合格したら、deployer スキルが変更不可能な番号付きバージョンとしてスナップショットを作成し、ガードレールにアタッチします。その後、validator スキルが実際の回答をチェックします。 uv run create_version.py --policy-arn <policy-arn> uv run deploy_guardrail.py --policy-arn <policy-arn> \ --policy-version 1 --guardrail-name hr-leave-guardrail uv run validate_response.py --guardrail-id <guardrail-id> --guardrail-version 1 \ --question "I'm full-time with 18 months. Am I eligible for parental leave?" \ --answer "Yes, you are eligible for parental leave." validator スキルは検出結果を返し、チェックが実行されたことを確認します。この例では回答が VALID と判定され、裏付けとなるルールが添付されていました。これが、検証済みの回答の監査証跡として保持する情報になります。 スイートの実行から学んだこと Amazon Bedrock に対してライフサイクル全体を実行したところ、特に重要な教訓が 2 つ得られました。どちらもスキルの動作に反映されています。 1 つ目は、説明可能性がこの機能の中核にあるということです。すべての判定では、その根拠となるルール、すなわち VALID の回答には裏付けとなるルールが、 INVALID の回答には矛盾するルールが返されます。validator スキルはこれらをログに記録します。これにより、検証済みの回答には、許可された理由を示す数学的に検証可能な証明が添えられます。また、拒否された回答については、違反したルールがそのまま書き換えステップに引き継がれます。次の図は、このランタイムの書き換えループを示しています。チェックは VALID 以外の判定を、回答が違反したルールとともに返します。モデルはそのルールを使って回答を書き換え、回答の妥当性が確認されるまでチェックが繰り返されます。 図 3: ランタイムの書き換えループ 2 つ目は、 SATISFIABLE という判定は失敗ではないということです。自動推論では、ポリシーと矛盾しない回答と、ポリシーから論理的に導かれる回答を区別します。例えば、「十分な勤続期間を持つフルタイム従業員には資格がある」というルールがあるとします。資格があると主張する回答はポリシーと矛盾しませんが、ポリシーによって証明されるわけではありません。そのため、サービスは VALID ではなく SATISFIABLE を返します。この結果を失敗と解釈すると、正しいルールまで変更してしまうことになります。debugger スキルにはこの区別が組み込まれているため、エージェントはサービスの定義どおりに判定を解釈できます。 スキルが自動的に対処する実用上の制約についても、1 つ触れておきます。1 つのポリシーで同時に実行できるビルドワークフローの数には制限があり、長時間にわたって改善を繰り返すと、この上限に達することがあります。スキルは各ビルドの前に、完了済みの最も古いビルドを削除してスロットを自動的に解放します。そのため、エージェントが複数回の改善を進めても、上限に達して処理が止まることはありません。 クリーンアップ 継続して料金が発生しないように、作成したリソースを依存関係の順序に従って削除します。テストケース、ビルドワークフロー、バージョンのいずれかが残っている間は、ポリシーを削除できないためです。まずテストケースを削除し、次にビルドワークフローと番号付きバージョン、続いてポリシー、最後にガードレールを削除します。スキルでリソースを削除する場合も、この順序に従います。Amazon Bedrock コンソールからすべてのリソースを削除することもできます。 まとめ 自動推論チェックは、AI の回答に対して検証可能かつ説明可能な判定を提供しますが、その判定の品質は背後にあるポリシーによって決まります。この記事で紹介した Agent Skills を使うと、ポリシー作成のライフサイクル全体をコードで扱えるようになります。ポリシーの構築、レビュー、テスト、デバッグ、デプロイ、検証が、コーディングエージェントで実行でき、人がレビューできる反復可能なステップになります。このアプローチは、育児休暇の例や特定のエージェントに限定されません。金融、保険、ヘルスケアなど、さまざまなドメインのポリシーに適用でき、スキルは普段使っているコーディングエージェントにインストールできます。 まずは次の手順から始めてみてください。 コードリポジトリ から、コーディングエージェントにスキルをインストールします。 builder スキルに独自のポリシードキュメントを指定し、品質レポートをレビューします。 ユーザーの実際の質問のしかたを反映した質問と回答のテストを追加し、すべて合格するまでポリシーを改善します。 バージョン管理されたポリシーをガードレールに関連付けてデプロイし、ランタイム用のスキルで回答を検証します。 さらに詳しく知りたい場合は、次の関連リソースを参照してください。 「 Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1 」(コンソールでのワークフロー) 「 Amazon Bedrock の自動推論チェックが変える生成 AI のコンプライアンス 」(コンプライアンスの観点) 「 自動推論チェックで回答を書き換えてハルシネーションを抑えるチャットボットのリファレンス実装 」(ランタイムのリファレンス実装) ドキュメント: 「 Amazon Bedrock 自動推論チェックのユーザーガイド 」および「 Amazon Bedrock API リファレンス 」 著者について Adewale Akinfaderin Adewale は、AWS の Amazon Bedrock チームで生成 AI を担当する Sr. Data Scientist です。基盤モデルと生成 AI アプリケーションのイノベーションに取り組んでいます。再現可能なエンドツーエンドの AI/ML 手法を専門とし、学際的な課題に対してスケーラブルなソリューションを構築できるよう、世界中のお客様を支援しています。物理学の大学院学位を 2 つ、工学の博士号を持っています。 Nafi Diallo Nafi は Amazon Web Services の Sr. Applied Scientist です。信頼できる AI ソリューションに向けた AI の安全性、形式的検証、ガードレールの実装を専門としています。Amazon Bedrock 上の生成 AI およびエージェント型システムの信頼性の評価と改善に豊富な経験があります。また、AWS の Women in AI and ML (WAIML) 組織で北米の Regional Lead を務め、支部の成長を支援するとともに、地域全体で WAIML のミッションを推進しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 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 が担当しました。

Amazon プライムデー 2026 はプライム会員限定で、2026 年 6 月 23 日から 26 日まで開催され、35 を超えるカテゴリーで数百万件のお得な情報が提供されました。 AWS がどのようにプライムデー ( 2016年 、 2017年 、 2019年 、 2020年 、 2021年 、 2022年 、 2023年 、 2024年 、 2025年 ) を支えてきたかをご紹介する毎年恒例の取り組みの一環として、お客様の素晴らしいショッピング体験を実現した AWS のサービスと、トップクラスの実績を記録したメトリクスをご紹介します。 数値で見るプライムデー 2026 例年通り、プライムデーは AWS によって支えられています。最も興味深いメトリクスと、驚異的なメトリクスをいくつか紹介します。 Amazon Elastic Compute Cloud (Amazon EC2) と AWS Graviton – Amazon プライムデー 2026 の開催中、AWS Graviton は Amazon.com が使用する Amazon EC2 コンピューティングの最大 49% を担いました。 Amazon Elastic Block Store (Amazon EBS) – プライムデー 2026 の開催中、当社の高性能ブロックストレージサービスである Amazon EBS の I/O オペレーションはピーク時に 24.8 兆回に達し、1 日あたりのデータ量は 1 エクサバイトを超えました。 AWS Lambda – AWS Lambda は、プライムデー 2026 の開催中、1 日あたり 2.3 兆件を超える呼び出しを処理しました。 Amazon Elastic Container Service (ECS) および Fargate – プライムデー 2026 の開催中、Amazon ECS は AWS Fargate 上で 1 日平均 1 億 5,830 万件のタスクを起動しました。これは、前年のプライムデーにおける平均から 47.7% 増加した数値です。 Amazon CloudFront – Amazon CloudFront は、プライムデー 2026 のグローバル開催中 2.1 兆件を超える HTTP リクエストを処理しました。これは、リクエスト総数が 2025 年のプライムデーと比較して 5% 増加した数です。 Amazon DynamoDB – フルマネージドのサーバーレス分散型 NoSQL データベースである Amazon DynamoDB は、Alexa、Amazon.com のサイト、すべての Amazon フルフィルメントセンターなど、トラフィック量の多い複数の Amazon のプロパティとシステムを支えています。2026 年 6 月 23 日から 6 月 26 日まで開催されたプライムデー 2026 の期間中、DynamoDB は 59 兆件を超えるリクエストを処理しました。DynamoDB は、1 桁ミリ秒のレスポンスを提供し、ピーク時には 1 秒あたり 1 億 9,200 万件のリクエストを処理しながら、高可用性を維持しました。 Amazon Aurora – プライムデーでは、PostgreSQL、MySQL、DSQL 向けにグローバル規模で高いパフォーマンスと可用性を実現するために構築されたリレーショナルデータベース管理システム (RDBMS) である Amazon Aurora が、数千億件のトランザクションを処理し、5,491 テラバイトのデータを格納し、1,194 テラバイトのデータを転送しました。 Amazon ElastiCache – プライムデーの開催中、Amazon ElastiCache が、ピーク時には 1 日あたり 2,300 兆件を超えるリクエスト、1 分間に 2.1 兆件を超えるリクエストを処理しました。 Amazon Kinesis Data Streams – フルマネージドサーバーレスデータストリーミングサービスである Amazon Kinesis Data Streams は、プライムデー 2026 の開催中に、ピーク時には 1 秒あたり 9 億 8,800 万件のレコードを処理しました。 Amazon Simple Notification Service (SNS) – アプリケーション間およびアプリケーション対人通信用のフルマネージドパブ/サブメッセージングサービスである Amazon SNS は、プライムデー 2026 の開催中、1 日あたり 5 兆通のメッセージを配信しました。 Amazon Simple Queue Service (Amazon SQS) – マイクロサービス、分散システム、サーバーレスアプリケーション向けのフルマネージドメッセージキューイングサービスのである Amazon SQS は、プライムデー 2026 の開催中、ピーク時に 1 秒あたり 2 億 1,300 万件のメッセージを受信しました。 AWS CloudTrail – AWS CloudTrail は、ガバナンス、コンプライアンス、およびオペレーション監査のために、1 日あたり数十億件の API アクティビティイベントを処理しています。プライムデー 2026 の開催中、その件数はわずか 4 日間で 3.6 兆件に急増し、プライムデー 2025 と比較して 44% 増加しました。 AWS CloudWatch – Amazon CloudWatch は、プライムデー 2026 の開催中、1 日あたり 2.15 千兆件を超えるメトリクス観測データを処理しました。 Amazon GuardDuty – プライムデー 2026 の開催中に、Amazon GuardDuty は、1 時間あたり平均 14.08 兆件のログイベントをモニタリングしました。これは、昨年のプライムデーと比較すると 59% の増加です。 AWS Fault Injection Service (FIS) – 当社は、プライムデーにおいて Amazon.com が高可用性を維持できるようにするため、44,000 件を超える AWS FIS 実験を実施しました。これは、2025 年に実施した数の 6 倍超です。 スケールするための準備 同様のビジネスクリティカルなイベント、製品のリリース、移行の準備をしている場合は、 AWS Countdown Premium を活用することをお勧めします。小売業界の繁忙期から主要なスポーツイベント、選挙、医療保険の加入期間に至るまで、最も重要な時期に完璧な体験を提供できるよう支援します。当社のエキスパートが、セキュリティとパフォーマンスを維持しながら大量のトラフィックの急増に対処できるよう、インフラストラクチャの管理を支援します。お客様のチームと連携し、インフラストラクチャの拡張、需要の急増時のコストの最適化、セキュリティ対策の強化、リアルタイムの需要の監視を行います。詳細については、 ビジネスクリティカルイベントに関する AWS Countdown Premium をご覧ください。 2027 年も、どのような記録が破られるか本当に楽しみです! — Channy 原文は こちら です。

本ブログは 2026 年 4 月 16 日に公開された AWS Blog “ How Automated Reasoning checks in Amazon Bedrock transform generative AI compliance ” を翻訳したものです。 規制業界のコンプライアンスチームは、手作業のレビューに数週間を費やし、外部コンサルタントにも費用を支払っていますが、AI の出力に形式的な証明がない場合には、依然として監査上のギャップに直面します。 Amazon Bedrock Guardrails の自動推論チェック (Automated Reasoning checks) は、確率的な AI 検証を数学的な検証に置き換えることでこの課題に対処し、AI が生成した判断を、正しさを証明でき、監査も可能な結果へと変えます。 この記事では、規制業界で確率的な AI 検証が不十分となる理由と、自動推論チェックが 形式的検証 によって数学的に証明された結果を提供する仕組みを説明します。さらに、6 つの業界のお客様がこのテクノロジーを活用して形式的に検証された監査可能な AI 出力を実現している事例と、利用を開始する方法も紹介します。 コンプライアンスの課題 規制業界は、失敗の代償が大きいコンプライアンスの課題に直面しています。病院は放射線安全規制に対応しなければなりません。金融機関は EU AI 法 に基づいて AI リスクを分類します。保険会社は補償範囲に関する質問に答えていますが、回答を誤ると規制上の責任を問われかねません。手作業のレビュー、高額なコンサルタント、従来型のプロセスはスケールしません。 生成 AI やエージェンティック AI ソリューションを構築する多くのチームは、LLM-as-a-judge パターン、つまり 2 つ目の大規模言語モデル (LLM) に最初のモデルの出力を評価させる手法に頼りがちです。直感的な方法ではありますが、このアプローチには 根本的な限界 があります。確率的なシステムが別の確率的なシステムを検証しても、規制業界が求める形式的で監査可能な保証は得られないのです。 自動推論チェックが定義済みのルールと制約に対して証明可能なコンプライアンスを実現する仕組み Amazon Bedrock Guardrails の自動推論チェックは、数理論理学に基づく 形式的検証手法 を適用し、AI が生成した出力を定義済みのルールと制約に照らして検証します。これにより、すべてのリクエストに対して、正しさを証明でき、監査も可能な評価結果が得られます。 例を挙げて考えてみましょう。AI アシスタントが、顧客の保険金請求は補償対象だと回答したとします。LLM-as-a-judge のアプローチでは、2 つ目のモデルがその回答をレビューして「妥当と思われる」と判断するだけです。一方、自動推論チェックでは、その回答がポリシー内のすべてのルールと整合していることを数学的に証明します。ルール違反があれば、どのルールにどのような理由で違反しているのかを正確に特定します。 図 1: 定理証明、型システム、モデル検査、抽象解釈、シンボリック実行、SMT 問題の求解、SAT 問題の求解を含む自動推論の分類。SAT 問題と SMT 問題の求解が自動推論チェックの基盤を形成します   自動推論は、与えられた前提から論理的な結論を自動的に導き出すアルゴリズムを開発する分野です。 形式的検証 (システムが仕様を満たすことを数学的に証明する手法)、 充足可能性判定 (satisfiability solving。論理式を充足できるかどうかを判定する手法)、 数理論理学 といった分野で数十年にわたり蓄積された研究成果を基盤としています。 これと同じ基盤は、ハードウェア設計の検証、暗号プロトコルの健全性の証明、安全性に直結するソフトウェアにおける仕様違反箇所の正確な特定にも使われています。自動推論チェックは、これらの手法を生成 AI に適用したものです。 自動推論チェックは、ニューラルネットワークと論理的推論を組み合わせ、AI の出力を定義済みのルールと制約に照らして検証することで、確率的な応答を形式的に検証された監査可能なアーティファクトへと変換します。AWS は、AI アプリケーションを保護するための複数の 責任ある AI ツールの 1 つとして、自動推論チェックを提供しています。 自動推論ポリシー (Automated Reasoning policy) の設定方法と検証の実際の動作を詳しく知りたい場合は、 「Minimize generative AI hallucinations with Amazon Bedrock Automated Reasoning checks」 を参照してください。 訳注: 上記の記事はプレビュー期間中 (2025 年 4 月) に公開されたものです。一般提供開始後の機能に基づいた手順は、日本語版ブログの「 Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1 」で確認できます。 図 2: Amazon Bedrock の自動推論チェック。ポリシーのエンコード、出力の変換、形式的検証エンジン、結果の生成という 4 段階のプロセスを示しています。 業界での活用例 ヘルスケア、金融、エネルギー、保険、教育といった分野の組織が、自動推論チェックを使って AI の出力を検証し、監査にそのまま使えるエビデンスとともにコンプライアンス上の判断を説明しています。 オペレーションエンジニアリング: Amazon Logistics Amazon Logistics では、エンジニアリングレビューの所要時間を約 8 時間から数分へ短縮しながら、すべての判定について形式的なコンプライアンス検証を得られるようになりました。Amazon Logistics の Sustainability Engineering チームは、Amazon のデリバリーステーションネットワーク全体への電気自動車充電ポイント (EVCP) の展開を主導しています。設置提案は、それぞれ地域固有の規制と社内技術仕様を満たす必要があります。以前は、レビュー 1 件ごとに対象分野の専門家がエンジニアリングパラメータを手作業で照合し、約 8 時間を費やしていました。 チームは AWS と協力し、自動推論チェックを活用した生成 AI 支援の設計レビューポータルを構築しました。このポータルは技術仕様を自動推論ポリシーへ変換し、変数、型、条件を明示的に定義した厳密な論理ルールを作成します。そして、提案書から抽出したエンジニアリングパラメータを形式的な数学的推論によって検証します。ドキュメントインテリジェンスレイヤーは Amazon Bedrock の Claude が担い、構造化されていない提案書からデータを抽出して構造化します。 「意思決定を行うのは引き続き当社の専門家です。ツールの動作は完全に可視化されており、あらゆる推奨事項をトレース、検証、妥当性確認できるという確信を持てます」 – AMZL、Sr. Sustainability Engineer、Paula Garcia Carrasco 対象分野の専門家は、煩雑なパラメータの照合ではなく、エンジニアリング上の判断に集中できるようになりました。 詳細は Amazon Logistics の導入事例をご覧ください 。 金融サービス: Lucid Motors と PwC Lucid Motors は、予測の生成にかかる時間を数週間から 1 分未満へ短縮し、わずか 10 週間で 14 の AI ユースケースを全社規模にスケールしました。電気自動車メーカーである同社は、PwC および AWS と協力して、AI ネイティブな財務予測・分析ソリューションを構築しました。財務チームが抱えていたのは、予測サイクルに数週間の手作業を要し、急速に変化する市場環境へ迅速に対応できないという、多くの企業に共通する課題でした。 PwC と AWS は共同で、Amazon Bedrock 上に機械学習 (ML) ベースの予測エージェントを構築しました。さらに自動推論チェックを形式的検証レイヤーとして適用し、モデルの出力があらかじめ定義された財務上のルールと制約に従っていることを数学的に検証しました。このアプローチにより、確率的な AI だけでは見逃しかねない論理的な不整合を検出できます。 財務チームは、レポートを数週間待つのではなく、リアルタイムでビジネス上の意思決定に積極的に関与できるようになりました。 「PwC と AWS とともに、Lucid はクラウド環境をイノベーションのためのプラットフォームへと変えています……PwC のチームは予測ツールを迅速に構築し、数週間かかっていた手作業を 1 分未満に短縮しました」 – Lucid、Head of Business Finance、Aditya Baheti 氏 Lucid Motors の導入事例をご覧ください。 ヘルスケア: 規制の複雑さへの対応 ヘルスケア組織は規制と安全に関する厳しい監督の下で事業を運営しており、厳格な内部統制、文書化、継続的な監査が求められます。臨床、業務、安全の各基準にわたってコンプライアンスを確保する作業はヘルスケアチームに大きな負担となり、本来の患者ケア業務から時間と労力を奪っています。 Fortive のヘルスケア事業会社は、テクノロジーを活用した安全性とコンプライアンスのソリューションを通じて、顧客がこの複雑さに対処できるよう支援することに注力しています。Fortive はイノベーション戦略の一環として、自動推論などの AI 主導のアプローチがよりプロアクティブなコンプライアンス管理をどう支援できるかを評価しています。ポリシーを要件に照らして決定論的に検証し、潜在的なギャップを早期に可視化することで、監督業務の効率化、手作業の削減、そして厳密性を損なわない意思決定の迅速化を実現できる可能性があります。 「自動推論を評価したことで、その強みと、最も価値を発揮する課題の種類の両方をより深く理解でき、確率的な AI を超えて数学的な確実性へと進むことができました」 – Fortive、Data Science & AI Leader、Gaurav Mantro 氏 教育: First Education & Technology Group (FETG) と PwC FETG は、ルール設定の作業を最大 80%、継続的なコンプライアンスの運用負荷を 50% それぞれ削減し、応答レイテンシーを 8～13 秒から 1.5 秒へ最適化しました。MarsLadder AI 学習システムを運営する First Education & Technology Group (FETG) は、PwC および AWS と協力して、生徒向け生成 AI のための責任ある AI ガバナンスレイヤーを構築しました。従来のモデレーション手法やキーワードフィルター、確率的な分類器では、文脈と意図が重要となる Safer Technologies 4 Schools (ST4S) フレームワークを確実に適用できませんでした。 PwC は自動推論チェックを決定論的な検証レイヤーとして実装し、ST4S の原則をデータ保護と生徒の安全を網羅する 10 個の形式論理ルールへ変換しました。このシステムは、AI が生成したすべての応答を学習者に届く前に検証し、確率的な判断を数学的に証明可能なコンプライアンスへ置き換えます。 このソリューションは、教育分野の規制当局が ST4S フレームワークの遵守のために求める、数学的に証明可能なコンプライアンスのエビデンスを提供します。 教育における責任ある AI に関する PwC の導入事例をご覧ください。 自動推論チェックを採用するその他の業界 他の規制業界の組織も、コンプライアンスを強化するために自動推論チェックを採用しています。 金融サービス (EU AI 法): EU AI 法に基づいて AI リスクを分類する組織は、自動推論チェックを使って、一貫性のない手作業のレビューから、形式的に検証でき、監査にも対応できるコンプライアンスワークフローへ移行しています。詳細は 「PwC and AWS Build Responsible AI with Automated Reasoning on Amazon Bedrock」 をご覧ください。 エネルギー・公益事業: 電力事業者は、AI が生成した停電の分類を北米電力信頼度協議会 (NERC) および米国連邦エネルギー規制委員会 (FERC) の規制要件に照らして検証し、個々のディスパッチ判断を形式的検証で裏付けています。 このユースケースに関する PwC との re:Invent セッションをご覧ください 。 製薬とライフサイエンス: プロフェッショナルサービス企業は、AI 主導のマーケティングコンテンツ向けに数学的に裏付けられる検証レイヤーを構築し、コンテンツの主張が承認済みの根拠資料に基づいていることを確認しています。 保険: 保険会社は、約款の記述に対して形式的に推論する顧客向けチャットボットを構築し、確率的な近似ではなく検証可能な補償判定を提供しています。 まとめ この記事では、Amazon Bedrock Guardrails の自動推論チェックが、監査にそのまま使えるエビデンスとともに数学的に証明可能な検証を提供する仕組みを説明しました。規制業界でコンプライアンスアシスタントを構築するチームや、既存の AI ワークフローに形式的検証レイヤーを追加したいチームにとって、このテクノロジーは確率的な確信から数学的な証明へ進むための道筋となります。 自動推論チェック は、AWS の他の責任ある AI 機能を補完します。例えば、検索拡張生成 (RAG) のための Amazon Bedrock ナレッジベース 、コンプライアンス追跡のための AWS Audit Manager 、モデルガバナンスのための Amazon SageMaker AI などです。 訳注: AWS Audit Manager はメンテナンスモードへの移行が公表されており、2026 年 4 月 30 日以降は新しいアカウントでこのサービスをセットアップできません。セットアップ済みのアカウントでは引き続き利用できます。参照: AWS Audit Manager 可用性の変更 、 AWS Audit Manager とは 開始方法 使ってみる: セットアップのガイダンスについては、 自動推論チェックのドキュメント をご覧ください。 訳注: 2026 年 9 月現在、自動推論チェックがサポートする言語は英語です。最新の対応状況は、Amazon Bedrock ユーザーガイドの「 Amazon Bedrock ガードレールの自動推論チェックとは 」を参照してください。 実践的な手順については、 「Minimize generative AI hallucinations with Amazon Bedrock Automated Reasoning checks」 を参照してください。 チャットボットは、自動推論チェックのフィードバックを使い、正しさを証明できる回答に到達するまでユーザーに確認の質問をしながら、回答を繰り返し書き換えることができます。 始めるには、 「自動推論チェックで回答を書き換えてハルシネーションを抑えるチャットボットのリファレンス実装」 を参照してください。 エージェントを使えば、自動推論ポリシーを改善するプロセス全体を自然言語で対象分野の専門家に案内できます。そうしたエージェントの オープンソースのサンプル をご覧ください。 お客様の成果を見る: Amazon Logistics の導入事例 | 教育における責任ある AI に関する PwC の導入事例 | AWS の責任ある AI のリソース Amazon Bedrock の機能の詳細: Amazon Bedrock Guardrails | Amazon Bedrock AgentCore AI ライフサイクル全体にわたるガイダンスと責任ある AI のベストプラクティス: AWS Well-Architected 責任ある AI レンズ 自動推論チェックがお客様のコンプライアンスのユースケースにどう役立つかについては、担当の AWS アカウントチームにお問い合わせください。準備として、AI の出力に形式的検証が必要となるコンプライアンスワークフローを、重要度の高い順に 3 つ挙げておくとよいでしょう。 図 3: Amazon Bedrock の自動推論によるコンプライアンスチェックのリファレンスアーキテクチャ。 ユーザーは Amazon CloudFront 経由でアプリケーションにアクセスします。CloudFront は Amazon Simple Storage Service (Amazon S3) の静的ホスティングから React フロントエンドを配信します。 Amazon Cognito がユーザーを認証し、JWT トークンを発行します。CloudFront は下流のリクエストに対して認証を強制します。 ユーザーは、地域、施設タイプ、ライセンスカテゴリを指定してコンプライアンスチェックのリクエストを送信します。CloudFront はそのリクエストを AWS Lambda にルーティングします。 Lambda は、地域、施設タイプ、ライセンスカテゴリをキーとして Amazon DynamoDB のルールエンジンにクエリを実行し、該当する規制ルールを正確に取得します。 Lambda はルールをプロンプトに挿入し、Amazon Bedrock を呼び出します。ナレッジベースは、Amazon S3 に保存された検証済みの規制文書から RAG のコンテキストを提供します。 生成されたコンプライアンスチェックリストは Amazon Bedrock の自動推論チェックに送信されます。自動推論チェックはルールを形式論理モデルにコンパイルし、各項目を数学的に検証します。この検証は確率的ではなく、証明可能です。 検証済みの項目は Amazon S3 に保存され、ユーザーに返されます。無効な項目は、モデルによって修正版が再生成されます (最大 3 回まで再試行)。対象範囲外の項目は理由付きで自動的に除外されます。 2 つ目の DynamoDB テーブルには顧客施設のプロファイルが保存されており、リクエストごとにデータを再アップロードすることなく、ID で病院を検索できます。 Amazon EventBridge スケジューラが設定可能なスケジュールで Lambda のウェブクローラーを起動し、政府の規制関連ウェブサイトをスクレイピングして、ポリシーの変更に関する情報を収集します。 スクレイピングしたコンテンツは Amazon Bedrock のポリシー差分エージェントに送信され、変更内容が検出されます。更新されたルールは DynamoDB に書き込まれ、新しい文書はナレッジベースに再インデックスされます。 自動推論チェックの検証証明を含むコンプライアンスレポートは DynamoDB に保存され、監査証跡、フィルタリング、ダウンロードのために [レポート] タブからアクセスできます。 謝辞 本取り組みに貢献いただいた Suresh Kanan、Tonny Ouma、Laurie Kasper、Stefano Buliani に特に感謝します。 著者について Nafi Diallo Nafi Diallo は Amazon Web Services の Senior Automated Reasoning Architect で、信頼できる AI ソリューションのための AI の安全性、形式的検証、ガードレールの実装を専門としています。Amazon Bedrock 上の生成 AI およびエージェンティック AI システムの信頼性を評価し、向上させる豊富な経験を持っています。また、AWS の Women in AI and ML (WAIML) 組織で北米地域の Regional Lead を務め、チャプターの成長を支援しながら、地域全体で WAIML のミッションを推進しています。 Aishwarya Natarajan Aishwarya Natarajan は、ジョージア州アトランタを拠点とする AWS の Solutions Architect で、産業用 IoT と AI/ML の専門知識を活かして自動車・製造業界を担当しています。クラウドテクノロジーを使ってお客様独自のビジネス課題の解決を支援することに情熱を注いでいます。余暇には家族や友人と過ごしたり、新しい場所を訪れたりすることを楽しんでいます。 Adewale Akinfaderin Adewale Akinfaderin は Amazon Bedrock の Generative AI 担当 Sr. Data Scientist で、AWS における基盤モデルと生成 AI アプリケーションの進化に貢献しています。再現可能でエンドツーエンドの AI/ML 手法、実践的な実装、そして世界中のお客様が学際的な課題に対してスケーラブルなソリューションを策定・開発できるよう支援することを専門としています。物理学分野で大学院の学位を 2 つ、工学の博士号を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は、 Timestream for InfluxDB 3 workload analysis and best practices を翻訳したものです。 Amazon Timestream for InfluxDB 3 のデプロイメントにおいて、適切なインスタンスサイズの選択は、時系列インフラストラクチャを設計する上で最も影響の大きい判断の 1 つです。インスタンスが小さすぎるとクエリパフォーマンスの低下や取り込みのボトルネックにつながり、大きすぎると未使用のキャパシティに対して余分なコストを支払うことになります。 本記事では、デプロイメントのサイジングの選び方について解説します。このガイドを参考に、お客様のビジネスユースケースに合った Timestream for InfluxDB 3 の構成を選択してください。Amazon Timestream for InfluxDB 3 を今すぐ使い始めるには、 ドキュメント をご覧ください。 サイジングのガイダンス パフォーマンス特性の理解 Amazon Timestream for InfluxDB 3 のデプロイメントに適切なインスタンスサイズを選択するには、ワークロードパターンごとのデータベースの挙動を把握することが重要です。 時系列データベースのパフォーマンスは、相互に関連する多くの要因に左右されます。クエリの複雑さはパフォーマンスに大きく影響します。直近のデータに対するシンプルな集計は、数か月分の履歴データにまたがる複雑な分析クエリとはパフォーマンスが異なります。データモデルも大きく影響します。数百万のユニークなタグの組み合わせを持つ高カーディナリティのデータセットは、低カーディナリティのモニタリングデータとは異なるパフォーマンス特性を示します。バッチサイズ、取り込みレート、ラインプロトコルポイントの構造といった書き込みパターンもパフォーマンスに影響します。 同時実行される操作には、固有の考慮事項があります。複数のアプリケーションがデータベースに同時にクエリを実行しながらデータの取り込みも継続している場合、取り込みとクエリ処理の間でリソースのバランスを取る必要があります。クエリの時間範囲も大きな影響を与えます。InfluxDB 3 のキャッシュとインメモリ最適化により直近のデータへのクエリは非常に高速であり、履歴データへのクエリ（Enterprise クラスターの場合）はコンパクター（圧縮を行うコンポーネント）と Parquet ストレージを使用して効率的に取得します。 本記事の目的は、お客様のワークロードに対する正確な予測を提供することではなく、デプロイメントの出発点となる情報を提供することです。 データとクエリに関する考慮事項 クエリと取り込みのパフォーマンスを向上させるには、以下の点を考慮してください。 カーディナリティが低い場合（ユニークなタグの組み合わせが少ない場合）、クエリがフィルタリングする必要のある系列が少なくなるため、パフォーマンスが向上する可能性があります。InfluxDB 3 ではカーディナリティは問題ではなくなりましたが、カーディナリティが際限なく増加してもパフォーマンスに影響がないわけではありません。クエリ操作のメモリ使用量が増え、圧縮パフォーマンスにも影響する可能性があります。 クエリがシンプルな場合（集計ではなく単一フィールドの取得など）、InfluxDB 3 の Last Value Cache の恩恵を受け、大幅に高速なレスポンスタイムが得られます。クエリが生データに対して数時間または数日にわたる集計を行う場合、データサイズの増加に伴いクエリパフォーマンスは低下します。可能な限り処理エンジンを使用して ダウンサンプリング を行い、クエリ結果として表示したい形式に合わせてデータを事前にフォーマットしてください。 書き込みバッチが大きい場合（medium から 4xlarge インスタンスでは 1 バッチあたり 5,000 ポイント、より大きなインスタンスでは 1 バッチあたり 10,000 ポイント以上）、リクエストあたりのオーバーヘッドが減少するため、書き込みスループットが向上します。 クエリが直近のキャッシュウィンドウを超える長い時間範囲や履歴データを対象とする場合、すべてのエディションで利用可能な ダウンサンプリング と、Enterprise エディションで利用できるコンパクター（圧縮を行うコンポーネント）により、良好なパフォーマンスを維持できます。 同時読み取りユーザーが少ない場合、多数の同時操作にリソースが分散されないため、クエリあたりのパフォーマンスが向上します。 デプロイメントの監視 インスタンスのデプロイ後、サイジングの妥当性を検証し、最適化の余地がないかを確認するため、パフォーマンスをモニタリングすることが重要です。Amazon CloudWatch は、CPU 使用率やメモリ使用量など、Timestream for InfluxDB 3 の重要なメトリクスを提供します。InfluxDB 3 の処理エンジンに含まれる System Metrics Plugin は、CloudWatch と同様のサーバーレベルのパフォーマンスデータを収集します。これには、詳細な CPU 統計（全体およびコアごと）、メモリ使用量の内訳、ディスク I/O パフォーマンス、ネットワークインターフェイス統計が含まれます。詳細な長期メトリクスについては、CloudWatch が 10 秒ごとに同じ粒度でメトリクスを記録するのに対し、System Metrics Plugin は カスタムスケジュール を設定できるため、CloudWatch よりも適しています。 データベース固有のパフォーマンスメトリクスについてより深い洞察を得るには、メトリクスエンドポイントをスクレイピングすることで、クエリパフォーマンス、書き込みスループット、その他のサービスレベル指標を詳細にモニタリングするための包括的な内部メトリクスを収集できます。Timestream for InfluxDB インスタンスの /metrics エンドポイントをスクレイピングする包括的なメトリクス収集ソリューションを提供しています。このソリューションは、 Telegraf を実行する Amazon EC2 インスタンスをデプロイし、クエリパフォーマンス、書き込みスループット、メモリ使用パターンなどの内部エンジンメトリクスを継続的に収集した後、CloudWatch に取り込み、事前設定された Grafana ダッシュボードで可視化します。ダッシュボードには、インスタンスのサイジング仕様に基づく主要パフォーマンス指標をモニタリングするパネルが含まれており、サイジングの判断の検証と最適化の機会の特定に役立ちます。 デプロイメントの手順、設定オプション、サンプルスクリプトについては、 GitHub リポジトリ をご覧ください。リポジトリには、Telegraf の設定から Grafana ダッシュボードの作成まで、セットアッププロセスを自動化する AWS CDK アプリケーションが含まれています。 サイジングの始め方 最初にデプロイメントを計画する際は、以下のアプローチを推奨します。 ベースライン要件を見積もる : 予想される書き込みレート（1 秒あたりのポイント数）とクエリの同時実行数（同時クエリ数）を計算します。データ量の増加や負荷のスパイクに備え、バッファを持たせてください。 開始するインスタンスサイズを選択する : 理想的な条件でインスタンスサイズを決定するための目安として、以下を参考にしてください。ニーズにおおよそ合致するインスタンスをデプロイし、パフォーマンスに応じて調整します。 書き込み（1 秒あたりの行数） 読み取り（1 秒あたりのクエリ数） インスタンスクラス ~35,000 ~40 db.influx.medium <100,000 ~140 db.influx.large ~120,000 ~290 db.influx.xlarge ~130,000 ~400 db.influx.2xlarge ~140,000 ~425 db.influx.4xlarge <200,000 <430 db.influx.8xlarge ~200,000 <430 db.influx.12xlarge ~210,000 ~430 db.influx.16xlarge ~230,000 ~430 db.influx.24xlarge 直近のデータモニタリング（3〜5 日間）に重点を置いたワークロードの場合は、db.influx.xlarge から始めてください。 書き込みスループットやクエリの同時実行数がより高い要件には、db.influx.2xlarge または db.influx.4xlarge を検討してください。 最大スループットが必要な場合は、db.influx.8xlarge や db.influx.24xlarge で評価してください。 履歴データの保持と分析が必要な場合は、適切なインスタンスサイズで Enterprise エディションを選択してください。 インスタンスサイズとワークロード特性に応じて、デプロイメント用の パラメータグループ を作成し設定します。 本番相当のデータでテストする : 本番環境のカーディナリティと時間範囲に一致するデータセットをロードし、実際のクエリパターンを実行してパフォーマンスを検証します。 モニタリングと調整 : CloudWatch メトリクスと System Metrics Plugin を使用して、CPU、メモリ、クエリレイテンシー、書き込みスループットを監視します。リソース使用率が常に高い場合やパフォーマンスが低下している場合は、スケールアップしてください。 本番レベルで稼働する正常なインスタンスは、CPU とメモリの使用率が平均で 40%〜70% の間であるべきです。 通常 40% を下回っており、ワークロードが安定している場合は、オーバープロビジョニングです。 70% の閾値を超えるスパイクがある場合は、最適化またはスケーリングを検討してください。クエリは書き込みよりも CPU 使用率に大きな影響を与えることに留意してください。 ワークロードの変化に応じて、短時間のダウンタイムを伴いますがインスタンスサイズのスケールアップまたはスケールダウンが可能です。控えめな構成から始め、注意深くモニタリングし、お客様固有のユースケースから得られる実際のパフォーマンスデータに基づいて調整してください。 まとめ Amazon Timestream for InfluxDB 3 のデプロイメントを効果的にサイジングするには、スループット要件、クエリパターン、コストの考慮事項のバランスを取る必要があります。Amazon Timestream for InfluxDB 3 がお客様のビジネスニーズにどのように応えるかを判断する出発点として、本記事を活用してください。ワークロードパターン、クエリの複雑さ、履歴データのニーズを分析することで、要件に合った適切な構成を選択できます。 今すぐ Amazon Timestream for InfluxDB のドキュメント にアクセスし、ビジネスが求めるパワー、柔軟性、スケーラビリティを備えた時系列ワークフローの構築を始めましょう。 著者について Victor Servin Victor は AWS の Amazon Timestream チームのシニアプロダクトマネージャーです。プロダクトレッドグロース戦略やスケーラブルなアーキテクチャでスタートアップを支援してきた長年の専門知識を持ち、データドリブンなアプローチで Timestream のような分析プロダクトの普及を推進しています。豊富な経験とカスタマーサクセスへの取り組みにより、お客様が効率的に目標を達成できるようサポートしています。 Forest Vey Forest は Improving 社のチームリードです。時系列およびサーバーレステクノロジーの経験を持ち、クラウド開発と組み込みシステムへの情熱が高まっています。ソフトウェア開発の学習以外の時間では、友人とのロッククライミングやハイキングを楽しんでいます。 Trevor Bonas Trevor は Improving 社のシニアソフトウェア開発者です。時系列データベースと ODBC ドライバーの開発経験があります。プライベートでは小説の執筆や、ゲーム開発にも取り組んでいます。 Fred Park Fred は Improving 社のシニアソフトウェア開発者で、時系列データベースと AI エージェントのオブザーバビリティを専門としています。VR やクラウドサービスから量子コンピューティングまで幅広いバックグラウンドを持ち、新しいテクノロジーに惹かれています。コーディング以外の時間は、ハイキングに出かけたり友人と音楽を作ったりしています。 本記事の翻訳はクラウドサポートエンジニアの平出が担当しました。

2026 年 9 月 28 日週、 OpenAI を搭載した Amazon Bedrock マネージドエージェントのパブリックプレビュー を発表しました。これは、AWS ネイティブで AWS リソースと統合されるように設計された OpenAI の Agents API のカスタマイズ版に基づいて構築されています。すでに使用している ID、権限、ガバナンスコントロールを使用して完全に AWS 内で動作する OpenAI モデル用に最適化されたエージェントを構築できるようになりました。 実行環境として、既存の開発マシン、コンテナ、またはコンピューティング環境を使用するセルフホストコンピューティング、または AWS アカウントのマネージドランタイムセッションと設定可能なストレージ用の Amazon Bedrock AgentCore Runtime を選択できます。詳細については、 Amazon Bedrock のドキュメント を参照してください。 さらに、Amazon Bedrock に新しいフロンティアモデルを追加して、モデルの選択肢を広げています。 OpenAI GPT-6.1 Sol : GPT-6 Sol のアップグレード版である GPT-6.1 Sol は、エージェント型コーディング、コンピューター操作、専門業務で非常に高いパフォーマンスを発揮します。OpenAI によると、要求の厳しい評価において、約 5 分の 1 のコストで GPT-6 Astra に迫る性能を発揮し、開発者は高性能なエージェントを大規模に構築、実行する余地をより多く確保できます。詳細については、 GPT-6.1 Sol モデルカード をご覧ください。 OpenAI GPT-6 Astra UltraFast モード : Ultrafast は GPT-6 Astra のプレミアム速度階層で、速度が最も重要なワークロード向けに構築されています。OpenAI によると、Ultrafast は API で最大 6 倍高速な推論を実現し、最大 300 トークン/秒を実現します。Amazon Bedrock 推論エンジンは、本番環境のワークロードに必要なパフォーマンス、セキュリティ、信頼性を提供します。詳細については、 GPT-6 Astra モデルカード をご覧ください。 Anthropic Claude Sonnet 5.5 : Claude Sonnet 5.5 は、より高性能で効率的な Sonnet であり、Sonnet 5 から一段進化しているため、すでに Sonnet を利用して開発しているチームにとって自然なアップグレードとなります。コーディング能力が向上しており、同じセッション内で Claude を使って機能の構築や修正を行ったり、出力を要件と照合して検証したりするなど、より大きなコーディング戦略の一環として、範囲が明確に定義されたタスクを完了するのに適しています。詳細については、 Claude Sonnet 5.5 モデルカード をご覧ください。 SpaceXAI Grok 4.7 : Grok 4.7 は Grok 4.6 をベースに、混在する文書の処理を改善し、計画とエラー回復によってリポジトリ規模のコーディングの信頼性を高め、フォーム入力やポータルナビゲーションを行うブラウザ操作エージェントを強化しています。詳細については、 Grok 4.7 モデルカード をご覧ください。  9 月 28 日週のリリース 私が注目したリリースをいくつかご紹介します。 AWS Well-Architected Agent (preview) : AWS 環境を分析し、アプリケーションのコスト、セキュリティ、パフォーマンス、レジリエンスを改善するための、的確でコンテキストに応じた推奨事項を提供する AI エージェントサービスを利用できます。エージェントはお客様のインフラストラクチャを分析し、お客様固有のビジネス目標を理解し、状況に応じた推奨事項を提示します。 Amazon Aurora PostgreSQL は Apache Iceberg および Parquet データの直接クエリをサポートします : 既存の PostgreSQL アプリケーションとツールを使用して、抽出、変換、ロード (ETL) パイプラインやデータの複製を行うことなく、運用データと、Apache Iceberg および Parquet 形式でデータレイクに保存されているデータをまとめて直接クエリできます。 Amazon S3 Tables は Apache Iceberg V3 のすべてのデータ型をサポートします : Amazon S3 Tables では、Iceberg V3 仕様で定義されている列のデフォルト値に加え、geometry、geography、unknown、nanosecond timestamp の各データ型がサポートされるようになりました。地理空間座標とナノ秒精度のイベント時間を、文字列や整数でエンコードする代わりにネイティブに保存できるようになりました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS サービス可用性アップデート AWS のサービスまたは機能の可用性が変更された場合、運用への影響を最小限に抑えられるよう、 AWS Product Lifecycle Changes で、利用可能な代替手段に関するガイダンスと移行サポートをお客様に提供します。次のライフサイクル変更は、2026 年 9 月 29 日に更新されました。 メンテナンスフェーズへの移行 (2026 年 10 月 29 日以降、新規のお客様は利用できなくなります): Amazon Chime SDK SIP Media Application Amazon WorkSpaces Secure Browser サンセットフェーズに入るサービス: Amazon Managed Blockchain (2027 年 9 月 29 日サポート終了) Amazon DevOps Guru (2027 年 9 月 30 日サポート終了) AWS Backint Agent for SAP ASE (2027 年 9 月 29 日サポート終了) AWS Infrastructure Composer (スタンドアロンコンソールのサポート終了: 2026 年 12 月 7 日) サポート終了を迎えるサービス (2026 年 9 月 29 日現在): Amazon Mechanical Turk 私たちは、可用性の変化がお客様の業務に影響を与える可能性があることを理解しています。具体的なガイダンスについては、関連するサービスドキュメントを参照するか、AWS サポートにお問い合わせください。 AWS のその他のニュース 興味深いと思われるその他のプロジェクトやニュース項目をいくつかご紹介いたします。 Kiro ワークフローの紹介 : Kiro のワークフローでは、複雑なタスクを最初から最後まで複数のエージェントで実行でき、監督も少なくて済みます。Kiro 自体の開発にもワークフローを使用しており、新しいクラウド設定、クラウドセッション、ワークフローエクスペリエンスの大部分をこれらのワークフローで構築しています。 Strands Decider のご紹介 : Strands Decider は、意思決定モデルまたはシステム 1 モデルと呼ばれる新しいクラスのモデルの 1 つで、今月初めに TypeSafe AI が Jev を発表して以来、大きな注目を集めているタイプのモデルです。Strands Decider 2B は、迅速な実験、ローカル開発、イノベーションに最適化された、小規模なオープンソースの意思決定モデルです。 AWS パートナー向けの新しい FDE パスウェイ : 6 月 30 日、AWS は 10 億ドルの投資に支えられた Forward Deployed Engineering (FDE) 組織を発表し、Partner-Led FDE の取り組みを通じて、この実践的なデリバリーアプローチを AWS パートナーにも拡大しました。現在、AWS パートナーは、本番環境向けのエージェンティック AI の提供に必要な実践的能力を認定する 3 つの新しい Partner FDE パスウェイと認証情報を活用して、その専門性を体系的に構築し、検証できるようになりました。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント ( AWS re:Invent 、 AWS Community Days など) を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 10 月 5 日週のニュースは以上です。10 月 12 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! — Channy 原文は こちら です。

本ブログは 2026 年 10 月 5 日に公開された AWS Blog “ AWS Continuum sets a new standard in autonomous code security ” を翻訳したものです。 AI モデルは、能力が向上するにつれて、より多くのセキュリティ脆弱性を発見し、それらを悪用するためのますます巧妙な攻撃経路を特定するようになっています。その結果、防御側にはこれまで以上に迅速な対応が求められています。セキュリティチームは現在、既存のプロセスで想定していた以上の数の潜在的な脆弱性に直面しています。脆弱性ごとに調査と再現を行い、修正を作成したうえで、その修正が想定どおりの動作を損なわずに脆弱性を解消できるかをテストで確認しなければなりません。 AWS Continuum for code vulnerabilities は、マシンスピードで動作する自律型セキュリティによって、この作業を加速します。Continuum を具体的な公開基準で評価するために AWS が選んだのが CyberGym-E2E です。このベンチマークでは、エージェントが実際のコードベースから脆弱性を見つけ、動作する概念実証 (proof of concept) でそれを実証し、プロジェクトのテストでカバーされている動作を損なわずに修正することが求められます。Continuum は、ベンチマークの制限時間である 90 分以内に 920 件中 819 件のタスクをパスし、エンドツーエンドの成功率 89.0% を達成しました。これは、従来の公開最高値である 65.9% を 23.1 ポイント上回る新たな基準です。 脆弱性ライフサイクル全体の測定 多くのセキュリティベンチマークは、単一のタスクを切り離してテストします。検出ベンチマークは、システムが疑わしいコードを特定できるかどうかをテストし、パッチ生成ベンチマークは、既知の欠陥を前提として修正を求めます。CyberGym-E2E の前身である CyberGym も既知の脆弱性を前提としており、エクスプロイト生成に重点を置いています。これに対して CyberGym-E2E は脆弱性ライフサイクル全体を評価するもので、システムには脆弱性を特定して実証したうえで、テスト済みの修正を作成することが求められます。このように評価範囲が広いため、セキュリティチームが実際に取り組む作業をより忠実に反映しています。 CyberGym-E2E の各タスクでは、実際のオープンソースプロジェクトの脆弱なリビジョンと、そのビルドとテストに必要なツールを含むコンテナにエージェントが配置されます。エージェントはソースの調査と変更はできますが、脆弱性の説明、概念実証、クラッシュログ、元のパッチは一切与えられません。外部ネットワークへのアクセスはブロックされ、保護されたベンチマークファイルも変更できません。エージェントは 90 分以内に、脆弱性を実証する入力とソースコードのパッチを提出する必要があります。ベンチマーク全体は、139 のオープンソースプロジェクトで過去に OSS-Fuzz によって検出された脆弱性に基づく 920 件のタスクで構成されています。プロジェクトのコード行数の中央値は 600,000 行を超えます。 このベンチマークでは、各提出物を次の 4 つの累積的なステージで評価します。 S1 では、脆弱なプログラムをクラッシュさせる入力をエージェントが生成したかどうかを確認します。 S2 では、エージェントが作成したパッチによってそのクラッシュが防止されるかどうかを確認します。 S3 では、パッチを適用したプロジェクトが引き続き機能テストにパスするかどうかを確認します。 S4 では、ベンチマークで選定された特定の過去の脆弱性もパッチによって修正されるかどうかを確認します。 CyberGym-E2E では、S3 をエンドツーエンドの成功を測る主要な指標と定義しています。S4 は診断用の指標です。リポジトリには実在する脆弱性が複数含まれている場合があり、エージェントがベンチマークで選定された対象とは異なる実在の欠陥を見つけて修正することもあるためです。 Continuum が新たな基準を確立 Continuum for code vulnerabilities は、CyberGym-E2E のすべてのステージで新たな基準を打ち立てました。次の表は、そのパフォーマンスを従来の公開最高値と比較したものです。 ステージ 評価内容 Continuum 従来の公開最高値 差分 S1 脆弱性の発見と再現 92.5% 67.9% +24.6% S2 生成した入力によるクラッシュの修正 89.6% 66.2% +23.4% S3 テスト対象の機能の維持 89.0% 65.9% +23.1% S4 ベンチマークで選定された脆弱性も修正 37.8% 26.2% +11.6% ベンチマークでエンドツーエンドの成功を測る主要な指標である S3 では、Continuum は 920 件中 819 件のタスクをパスしました。成功率 89.0% は、従来の公開最高値である 65.9% を 23.1 ポイント上回っています。この結果には、基盤となるフロンティアモデルの能力と、マルチエージェントのセキュリティシステムとしての Continuum の設計の両方が反映されています。次のセクションでは、このシステムがモデル単体の能力に加えてどのような価値をもたらしているのかを説明します。 公式の結果である 89.0% は、CyberGym-E2E の 90 分の制限時間を適用したものです。制限時間を超えてタスクの継続を許可した場合、Continuum のエンドツーエンドのパス率は 93.7% に達しました。この結果は、長時間の分析を最後まで完了できれば、対応できる範囲がさらに広がる可能性があることを示しています。 評価は、CyberGym-E2E のネットワーク分離と提出物レビューの要件に従って実施しました。実行中は外部からの情報取得をブロックしました。また、実行後にトラジェクトリ (エージェントの実行履歴) をレビューし、タスクの成功が、公開済みの過去の修正を取得した結果ではなく、脆弱性分析によるものであることを確認しました。 エンドツーエンドのセキュリティを実現するハーネス設計 Continuum for code vulnerabilities は、コード脆弱性ライフサイクルの主要なフェーズである発見、検証、修復を中心に構成されたマルチエージェントシステムです。各フェーズでは、そのフェーズで必要となる証拠と判断に合わせて調整された専用のエージェントを使用します。システムは証拠を次のフェーズへ引き継ぐため、各フェーズでは前のフェーズまでに完了した作業を基に処理を進められます。 発見フェーズでは、Continuum がリポジトリを分析し、脆弱性の候補となる検出結果を作成します。エージェントは、詳しく調査すべきコードパスを特定し、各候補を裏付けるソースコード上の証拠を記録します。 検証フェーズでは、専用のエージェントが、候補となる検出結果が実際のセキュリティ問題であることを実証しようとします。エージェントは概念実証を構築して脆弱なプログラムに対して実行し、観測された動作がその検出結果を裏付けるかどうかを判断します。これにより、コードレベルの潜在的な弱点が、実行して確認できる証拠へと変換されます。 修復フェーズでは、エージェントが脆弱性の根本原因を突き止め、パッチを作成します。その後 Continuum は、パッチによって実証済みの不具合が防止されること、そしてプロジェクトの機能テストに引き続きパスすることを確認します。つまり、修正は、脆弱性の立証に使用したものと同じ証拠に基づいて評価されます。 これらのフェーズが連携することで、疑わしいコードから実証済みの脆弱性、テスト済みの修正に至るまでを一貫してたどれる記録が作成されます。このアーキテクチャにより、Continuum は一貫した証拠の基準を維持しながら、ツール、指示、チェック、モデルを各フェーズに合わせて調整できます。また、複数のモデルの相互補完的な強みを活用し、新しいモデルが利用可能になりしだい取り込めるマルチモデルのアプローチにも対応しています。 お客様の環境では、Continuum はコードレベルの証拠を、サービスの露出状況、ネットワークパス、アクセス許可、設定など、利用可能なデプロイコンテキストと組み合わせることもできます。このコンテキストは、本番環境への影響が限定的な脆弱性と、直ちに対応が必要なセキュリティ上の露出とを区別するのに役立ちます。CyberGym-E2E はコードレベルのプロセスを評価するもので、デプロイコンテキストは提供されません。そのため、こうしたより広範な優先順位付けの機能はベンチマークの評価範囲外となります。 CyberGym-E2E のその先へ CyberGym-E2E は、複雑で多段階にわたるプロセスを、再現可能なタスクと、コードを実行して検証できる結果を備えた大規模な公開ベンチマークとして形にすることで、セキュリティ評価を前進させています。タスクの構築、スコアリング、提出基準について CyberGym-E2E の作成者が行った綿密な取り組みは、エンドツーエンドの進歩を測定するための具体的な基盤をこの分野にもたらしています。 920 件のタスク全体で評価の一貫性と再現性を保つため、CyberGym-E2E は C および C++ プロジェクトのメモリ安全性の脆弱性に焦点を当てています。サニタイザーが検出したクラッシュを欠陥の客観的な証拠とし、その後のチェックで、修正が概念実証による脆弱性の再現を防ぎ、プロジェクトのテストでカバーされる機能を維持しているかどうかを判断します。この設計上、多くのプログラミング言語や脆弱性クラスは、必然的にベンチマークの現在の範囲外となります。その中には、本番システムで観測される、最も一般的かつ影響の大きいバグクラスの多くも含まれます。これらの領域を評価するには、別のタスク環境と、同様に厳密な検証方法が必要になります。 AWS が考えるエンドツーエンドのセキュリティは、テスト済みのコードレベルの修正を作成するだけにとどまりません。本番システムでは、サービスの露出状況、ネットワークパス、アクセス許可、設定などのデプロイコンテキストによって、その脆弱性のリスクが限定的なのか、直ちに対応が必要なのかが決まることが少なくありません。今後の評価では、自律型システムがこうしたコンテキストを踏まえて推論し、デプロイされたシステムの安全性への影響に応じて検出結果に優先順位を付けられるかどうかをテストする必要があります。 CyberGym-E2E の価値は、データセットそのものだけにとどまりません。CyberGym-E2E は、エンドツーエンドのセキュリティを独立したタスクとして定義し、測定する価値があることを示しています。そのためには、範囲、証拠、何をもって成功とみなすかについて難しい設計判断が必要になりますが、CyberGym-E2E は、こうした判断を検討するための具体的な出発点をこの分野に提供しています。このシステムレベルの視点は、 Deception Benchmark に関する AWS の取り組みを補完するものです。Deception Benchmark は、範囲はより狭いものの関連する能力、つまり個々のフロンティアモデルが実際の脆弱性と安全なコードをどの程度確実に区別できるかを評価します。両者は、モデルとシステムの両方のレベルでセキュリティパフォーマンスを検証します。 AWS Continuum for code vulnerabilities が、チームによる脆弱性の 発見、検証、優先順位付け、修復 をマシンスピードでどのように支援するかについては、 A WS Continuum 製品ページ をご覧ください。 Alexander Greaves-Tunnell Alec は、AWS Continuum for code vulnerabilities の設計と評価に携わるサイエンティストです。AWS では、検索、セキュリティ、オブザーバビリティの分野にわたるプロジェクトを主導し、既存のモデルの知識だけでは対応できない複雑なアプリケーション領域に最先端の AI を適用してきました。学術的なバックグラウンドは統計学です。 Neha Rungta Neha は、複雑なシステムを対象とするマシン推論を大規模に実現することにキャリアを捧げてきたサイエンティスト兼ビルダーです。自動推論、形式的検証、セキュリティ、AI にわたる研究に取り組み、Cedar、IAM Access Analyzer、Continuum などのシステムの構築に携わってきました。現在は、LLM、形式手法、エージェント型システムを組み合わせ、次世代のマシン推論の開拓に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 8 月 14 日に公開された「 How Autodesk migrated 2.3 billion documents to Amazon OpenSearch Service using Migration Assistant and intelligent routing 」を翻訳したものです。 OpenSearch は、検索、分析、セキュリティモニタリング、オブザーバビリティのアプリケーション向けのオープンソースソフトウェアスイートで、Apache License 2.0 で提供されています。Amazon OpenSearch Service は、OpenSearch および Elasticsearch エンジンを AWS クラウド上でデプロイ、スケール、運用できるマネージドサービスです。お客様は OpenSearch Service 上で数十億ドキュメント規模の検索ワークロードを運用しています。単一のインデックスが数百万から数十億のドキュメントを保持する場合、そのインデックスを収容する OpenSearch Service ドメインのトポロジーを計画する必要があります。本記事では、Autodesk が Amazon OpenSearch Service 上の単一インデックスの Elasticsearch 7.1.1 ドメインを、Migration Assistant for Amazon OpenSearch Service と、各クエリを該当データを持つシャードへ振り分けるルーティング層を使って、4 つのマルチインデックス OpenSearch Service ドメインへ再設計した方法を紹介します。 Autodesk は、建築・エンジニアリング・建設 (AEC)、製品設計・製造、メディア・エンターテインメントという 3 つの業界に跨るお客様にサービスを提供するテクノロジー企業です。Autodesk のミッションは 「誰もが、どこでも、あらゆるものをデザインし、創造できるようにする」 ことであり、お客様がプロジェクト、専門分野、業界の境界を越えて働けるよう支援しています。 Autodesk Forma (旧 Autodesk Construction Cloud、ACC) は、クラウドベースの建設管理・コラボレーションシステムです。世界中のお客様が、ドキュメント管理、入札管理、数量算出、コーディネーション、設計コラボレーション、プロジェクト管理、現場コラボレーションといったワークフローに Autodesk Forma を利用しています。Autodesk Forma は Amazon OpenSearch Service を使って、数百万のユーザーに検索体験を提供しています。お客様がデータを追加するにつれ、Forma が OpenSearch Service に保存するデータも増加します。OpenSearch Service ドメインでは、 インデックス がデータの保存と整理の単位です。インデックスが 100 TB に達すると、インデックスがパフォーマンスのボトルネックとなり、スケールが難しくなります。Autodesk Forma の成長にともない、Forma データ管理 (Forma data management、旧 Autodesk Docs) はパフォーマンスとスケーリングの限界に達しました。このコンポーネントは、プロジェクトカタログ全体へのアクセスと検索を担っています。 Autodesk の出発点 Forma データ管理は、Amazon OpenSearch Service 上の単一の Elasticsearch 7.1.1 ドメインで、1 つのインデックスを使って稼働していました。このドメインは 100 台を超える データノード 上に約 100 TB のデータを保持し、 プライマリシャード は 400 を超え、 レプリケーションファクター は 1 でした。シャードの平均サイズは 200 GB でした。この規模とドメインが本番稼働中であることから、シャードの追加、インデックスの追加、データのリバランスといったチューニング手法は現実的ではありませんでした。 単一インデックス・単一ドメインの設計は、今後のデータ増加に対して 3 つの課題を抱えていました。 クエリパフォーマンス – データの増加にともない、クエリのレイテンシーが時間とともに悪化していました。 垂直スケーリング – 既存のインスタンスクラスで利用できる最大の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスサイズに、すでに達していました。 水平スケーリング – ルーティングの仕組みがないため、ノードを追加すると OpenSearch Service ドメインが管理するクラスター内に ホットノード が発生しました。 インテリジェントルーティングを備えたマルチドメインアーキテクチャ 垂直または水平スケーリングで短期的にはクエリパフォーマンスに対処できますが、どちらも根本にある単一インデックス・単一ドメインのスケーラビリティ限界を解消しません。ルーティングキーを使った水平スケーリングのアプローチなら、より大きなハードウェアを必要とせずに、各クエリがどのシャードにアクセスするかを制御できます。Autodesk のチームはこのアプローチを採用し、本番トラフィックに影響を与えることなく検索サービスを再設計しました。 図 1: インテリジェントルーティングを備えたマルチドメインアーキテクチャ このアーキテクチャには次の特性があります。 OpenSearch 2.19 の Amazon OpenSearch Service ドメインが 4 つ。各ドメインは m7i.4xlarge.search ノード 24 台で稼働。 インデックスは合計 24 (ドメインあたり 6)。 インデックスあたり約 9,500 万ドキュメント。 プライマリストレージは 52 TB。元の単一インデックスドメインのプライマリストレージより 37% 小さく、主な理由は移行時に削除済みドキュメントをスキップしたこと。 この構成では、水平にスケールした 4 つの OpenSearch Service ドメインと、各クエリをそのプロジェクトのデータを持つドメインへ振り分けるルーティング層を使います。 アーキテクチャでは、プロジェクトごとに 1 レコード、計数百万件のルーティングレコードを保存する Amazon DynamoDB テーブルを使用します。プロジェクトとは Forma データ管理における主要なワークスペースで、チーム、データ、ドキュメント、モデル、ワークフロー、権限、課題、コラボレーション活動がまとめて置かれる場所です。Forma アプリケーションは Amazon DynamoDB テーブルでプロジェクトとドメインの対応を参照し、正しいドメインに検索クエリを発行します。 数百万件のレコードを 4 つのドメインへ再配分するのは困難な作業でした。プロジェクトをインデックスへ均等に割り当てるため、チームはビンパッキングアルゴリズムを使いました。ビンパッキングアルゴリズムは、大きさの異なるアイテムを固定数の箱 (ビン) に詰め、無駄を最小化して均等な分布を得るアルゴリズムです。チームが扱ったのは、プロジェクトあたりのドキュメント数が数件から数百万件までさまざまな数百万のプロジェクトと、それぞれ約 4 億ドキュメントを目標とする 24 のインデックスです。チームは、ワークロードの過去の利用メトリクスを使う層別ビンパッキングアルゴリズムを実装しました。このアルゴリズムにより、移行計画時のリソースの過剰割り当てや不足を避けられます。過剰割り当てを避けるため、チームは 95 パーセンタイル (P95) の利用メトリクスを使いました。アルゴリズムを適用した結果、各 OpenSearch Service ドメインの使用率は約 49% となり、2 倍の成長余地が残りました。アプリケーションは ルーティングキーに基づくクエリ を使い、インデックス内のすべてのシャードではなく関連するシャードだけを検索します。 このアーキテクチャには次のメリットがあります。 水平スケーラビリティ – 必要に応じてドメインとインデックスを追加できる。 効率的なルーティング – クエリはドメイン内のすべてのシャードではなく、特定のシャードにだけ到達する。 影響範囲の縮小 – 1 つのドメインが利用不能になっても影響を受けるトラフィックは約 25% にとどまり、単一ドメイン設計のような全面ダウンタイムにはならない。 独立したスケーリング – 各ドメインをその負荷パターンに応じてスケールできる。 検索スレッドの増加 – 4 つのドメインを合計した検索スレッドプールは、1 つのドメインより大きい。 移行の手順 以下のセクションでは、Autodesk のチームが移行を完了するまでに踏んだ 4 つのステップを説明します。 ステップ 1: プロジェクトをサイズで分類する チームはプロジェクトを現在のドキュメント数で 4 つのサイズカテゴリに分け、6 か月分のデータを収集してカテゴリごとの成長係数を算出し、1 年先まで外挿しました。 カテゴリ ドキュメント数の範囲 全体に占める割合 P95 成長係数 根拠 TINY 0〜1,000 95.0% 3.82 倍 小規模 (TINY) プロジェクトの成長が最も速い SMALL 1,000〜10,000 4.3% 2.11 倍 中程度の成長を見込む MEDIUM 10,000〜100,000 0.66% 1.72 倍 相対的に成長は緩やか LARGE 100,000 以上 0.05% 1.38 倍 すでに成熟しており成長は最小限 合計 — 100% — — この表から、プロジェクトの 95% は TINY である一方、ドキュメント量の大半を占めるのは LARGE プロジェクトであることがわかります。カテゴリによる層別化によって、アルゴリズムは各カテゴリを適切に扱えます。 Autodesk のチームは、成長を見積もるためにプロジェクトあたりのドキュメント数を 6 か月間にわたって分析しました。カテゴリごとの P95 成長係数を使うことで、プロジェクトの 95% をカバーしつつ過剰なプロビジョニングを避ける、保守的なキャパシティプランが得られます。 ステップ 2: インターリーブ配置 LARGE プロジェクトをすべて先に処理すると、インデックス間に偏りが生じます。この偏りを避けるため、ビンパッキングアルゴリズムはカテゴリをラウンドロビンでインターリーブします。チームは次の順序で、ドキュメントを Amazon OpenSearch Service ドメインに均等に分配しました。 各カテゴリ内でプロジェクトを大きいものから順に並べ替える。 カテゴリごとにキューを作る。キューは先入れ先出しのデータ構造で、1 つのカテゴリの並べ替え済みプロジェクトを保持する。 ラウンドロビンでプロジェクトを配分する。LARGE から 1 つ、次に MEDIUM、SMALL、TINY から 1 つずつ取り出し、これを繰り返す。 ステップ 3: 負荷分散を考慮したベストフィット インターリーブの後、チームは各プロジェクトの予測サイズを計算し、プロジェクトをインデックスに割り当てました。手順は次のとおりです。 将来の推定サイズを 現在のサイズ × 成長係数 で計算する。 優先度付きキューを使って、空き容量が最も大きいインデックスを見つける。優先度付きキューでは各要素が優先度を持つ。ここでは各インデックスの優先度は、そのインデックスの空き容量である。通常のキューと異なり、優先度付きキューは最初に挿入された要素ではなく、優先度が最も高い要素を先に返す。 空き容量が最も大きいインデックスにプロジェクトを割り当てる。 インデックスの推定負荷を更新し、新しい容量で優先度付きキューに再挿入する。この再挿入により、次のプロジェクト割り当てに向けてキューが正確に保たれる。 以上の 3 ステップにより、次の結果が得られました。 アルゴリズムは数百万のプロジェクトを 99.999% のルーティング精度で配分した。 インデックス間のプロジェクト配分のばらつきは 0.15% に収まった。 成長係数を適用した後の各ドメインの容量使用率は 49.1% で、将来の成長に向けて 50.9% の余裕が残った。 アルゴリズムは数百万件のプロジェクト割り当てを約 10 分で計算した。 チームは、リアルタイムのクエリルーティングのために、プロジェクトとインデックスの割り当てマッピングを Amazon DynamoDB に保存しました。ルーティングは、アプリケーションがドメインのリソースをどう使うか、そして各ドメインのパフォーマンスを左右します。ルーティングを使うと、アプリケーションはそのプロジェクトのルーティングキー ( projectId ) に一致するシャードだけを検索します。ルーティングがなければ、同じクエリがインデックス内のすべてのシャードを検索することになり、ドメインのリソースを浪費してクエリも遅くなります。チームはシャードサイズもチューニングしました。これは大規模プロジェクトで最も重要になります。最大規模のプロジェクトの 1 つは 700 万ドキュメントを保持し、1 ドキュメントあたり約 40 KB、合計で約 280 GB でした。このプロジェクトのデータを 20〜25 GB のシャードに分割するため、チームは routing_partition_size を 12 に設定しました。 ステップ 4: Migration Assistant for Amazon OpenSearch Service による移行 Autodesk のチームは、23 億ドキュメントの移行に Migration Assistant for Amazon OpenSearch Service の スナップショットと再インデックス による方式を使いました。Migration Assistant for Amazon OpenSearch Service は移行のプロファイルに合わせて適応し、 AWS Identity and Access Management (IAM) のアクセス許可の境界、 Amazon Virtual Private Cloud (Amazon VPC) のサポート、そして移行に必要なセキュリティポリシーを提供します。Migration Assistant for Amazon OpenSearch Service は、AWS Fargate を使う Amazon Elastic Container Service (Amazon ECS) 上でアプリケーションを動かす 400 を超えるタスクと統合されました。 本番の切り替え前に、チームは概念実証 (PoC) を複数回繰り返し、移行設定をチューニングしてスループットを 18 GB/時から 228 GB/時に引き上げました。最初の PoC では m7g.large.search ノードで 18 GB/時でした。その後の各イテレーションで、水平スケール、より大きなインスタンス ( m7g.2xlarge.search と m7g.4xlarge.search )、ドメインをまたいだ並列書き込み、移行中のレプリカ数ゼロを追加しました。4 回目となる最終の PoC で 228 GB/時に達しました。PoC を複数回行ったことで、チームは最適なインスタンスサイズとインスタンスクラスを選定でき、23 億ドキュメントをダウンタイムなし、お客様に影響するインシデントなしで 6 時間で移行できました。 移行後の分析 ルーティングを有効にして 23 億ドキュメントを移行した後、シャードは次のような状態になりました。 指標 結果 目標 状態 プライマリシャード総数 4,325 — ✓ 総データサイズ 52.11 TB 約 52 TB ✓ 目標どおり 平均シャードサイズ 12.34 GB 10〜15 GB ✓ 最適 シャードサイズの中央値 11.9 GB 10〜15 GB ✓ 最適 最適範囲 (10〜15 GB) のシャード 75.5% 70% ✓ 目標超過 ホットシャード (30 GB 超) 12 (0.28%) 1% 未満 ✓ 範囲内 小さすぎるシャード (10 GB 未満) 528 (12.2%) 15% 未満 ✓ 範囲内 ドメイン間のバランス ばらつき 2.3% 5% 未満 ✓ 目標内 ノード間のバランス (標準偏差) 0.78〜1.12 シャード 2 未満 ✓ 目標内 次の表は、移行前と移行後のアーキテクチャを比較したものです。 観点 旧 (単一ドメイン) 新 (インテリジェントルーティングを備えた 4 ドメイン) シャードサイズ 平均 200 GB 平均 12.34 GB (94% 削減) クエリのブロードキャスト先 400 超のすべてのシャード 約 12 シャード (97% 削減) 最適範囲のシャード 0% 75.5% ドメイン間のバランス 該当なし (単一ドメイン) ばらつき 2.3% ストレージ 83.3 TB 52 TB P99 クエリレイテンシー (全体) 17 秒 5 秒 チームは 23 億ドキュメントを約 6 時間で移行しました。移行時に削除済みドキュメントを除外したため、ストレージは 83.3 TB から 52 TB へと約 37% 減少しました。移行により、平均 12.34 GB のシャードが 4,325 個生成され、4 つのドメインに分散されました。シャードの 75.5% が 10〜15 GB の範囲に収まりました。移行前の 210 GB と比べると、新しいアーキテクチャが大きすぎるシャードの問題を解決していることが確認できます。このシャードサイズは、検索レイテンシーを主要なパフォーマンス目標とする場合の 一般的なガイダンス に沿ったものです。ドメイン間のばらつきが 2.3% (ドメインあたり 12.85〜13.15 TB) であることから、データが均等に分散されていることが確認できます。 移行後、 projectId ルーティングキーを含むクエリは関連するシャードだけ (通常はインデックスあたり 180 シャード中 12) をスキャンするため、シャード全体の検索負荷が 93% 減少します。ルーティングは各ドメイン内の CPU とメモリの使用も均等化します。インデックスあたり 12 という routing_partition_size により、インデックスごとに適切なシャード数が得られました。全体の P99 レイテンシーは 17 秒から 5 秒へと 72% 改善しました。そのうち検索クエリの P99 は 2,500 ms から 200 ms へと 92% 改善しました。 学んだこと PoC のイテレーションからいくつかの教訓が得られました。より大きなインスタンスタイプは短期的にはクエリパフォーマンスの助けになりますが、クエリルーティングと水平スケーリングの組み合わせの方が、持続的に高いスループットを生み出します。バルクロード中はレプリカを無効化し、リフレッシュ間隔を長くして書き込みのオーバーヘッドを減らします。アプリケーションをスケールアウトする際は、移行の途中でサービスの制限に当たらないよう、十分な IP アドレスとサブネットの容量 を計画します。アプリケーションと OpenSearch Service ドメインの間の VPC ルーティング設定を検証します。水平スケールアウトの前に、OpenSearch Service のデータノード容量を AWS Support に確認します。Amazon DynamoDB ベースのルーティング層はクエリあたり約 20 ms のルーティングレイテンシーを追加しますが、全体の検索レイテンシーを削減し、水平スケールを可能にします。 まとめ 本記事では、Autodesk のチームが 23 億ドキュメントを単一インデックスのドメインから 4 つのマルチインデックスの Amazon OpenSearch Service ドメインへ、約 6 時間で移行した方法を紹介しました。 マルチドメインアーキテクチャへの移行や最新の OpenSearch バージョンへの更新は、従来は複雑な作業でした。また、本番トラフィックを移す前に移行の結果を予測することも難しいものでした。Migration Assistant for Amazon OpenSearch Service は、移行をワークフロー駆動で再現可能にし、切り替え前の検証をより簡単にすることで、こうした課題に対処します。 Migration Assistant for Amazon OpenSearch Service と Amazon DynamoDB ベースのインテリジェントルーティングを組み合わせることで、バランスの取れたシャードと検索クエリパフォーマンスの向上を実現しました。PoC を複数回行ったことで、本番切り替えの前にルーティングのバグ、サービスクォータの制約、インフラストラクチャのプロビジョニングの不足を見つけることができました。 OpenSearch Service ドメイン間で大規模なデータセットを移行する予定があれば、Migration Assistant for Amazon OpenSearch Service を利用できます。詳細は Migration Assistant for Amazon OpenSearch Service のドキュメント を参照してください。 著者について Ambarish Rao Ambarish は Autodesk Search Team の Principal Engineer で、プネーを拠点としています。金融データ、物流、そして現在は設計・製造の分野で 11 年の経験を持ち、中規模から大規模の分散システムに携わってきました。検索の仕事をしていないときは、水泳やバドミントン、子どもたちへの教育ボランティア、あるいはプネーで一番のビリヤニ探しを楽しんでいます。 Chengsi Xie Chengsi は Autodesk Search Team の Software Development Engineer です。スケーラブルな分散検索プラットフォームの構築に注力しています。問題の根本原因を掘り下げ、システムの挙動を理解することを楽しんでいます。仕事以外では、ランニング、バドミントン、ハイキングなどのアウトドア活動で体を動かし、活力と地に足のついた感覚を保っています。 Manoj Kale Manoj は Amazon Web Services の Senior Solutions Architect です。お客様が AWS 上でスケーラブルで回復力のあるソリューションを設計・構築できるよう支援しています。クラウドアーキテクチャ、AI/ML、DevOps を専門とし、お客様とともに複雑な技術課題を解決することを楽しんでいます。仕事以外では、家族との時間や旅行を楽しみ、旅行記や写真でその記録を残しています。 Anirudh Gupta Anirudh は Amazon Web Services の Technical Account Manager です。エンタープライズのお客様と密接に連携し、AWS 上でのワークロードの設計、最適化、運用を支援しています。お客様のインフラストラクチャのモダナイズと、AWS 上での分散システムのスケールを支援することに情熱を注いでいます。 Priyanshi Omer Priyanshi は Amazon Web Services の Solutions Architect です。お客様が AWS 上でスケーラブルで回復力のあるソリューションを設計・構築できるよう支援しています。クラウドアーキテクチャ、AI/ML、DevOps を専門とし、お客様とともに複雑な技術課題を解決することを楽しんでいます。 翻訳はソリューションアーキテクトの久野康貴が担当しました。原文は こちら です。

本ブログは 2026 年 8 月 3 日に公開された AWS Blog “ Automated Reasoning policy refinement in Amazon Bedrock ” を翻訳したものです。 Amazon Bedrock で自動推論ポリシー (Automated Reasoning policy) を改善する作業は、これまで診断、手作業での編集、再テストを繰り返す手動のサイクルでした。本日 (2026 年 8 月 3 日)、このサイクルのうち診断と修正の作業を自動化するポリシーの自動改善を発表します。改善エンジンが失敗したテストを診断し、形式論理の修正案を提示します。どの変更も、お客様が承認してから反映されます。 自動推論チェック (Automated Reasoning checks) は、Amazon Bedrock Guardrails において形式検証を使用して回答の正しさを証明します。自然言語から形式論理への変換があいまいでなければ、最大 99% の検証精度を実現します。これは「 自動推論チェックを使用して、AI のハルシネーションを最小限に抑え、最大 99% の検証精度を実現: 今すぐご利用いただけます 」で報告したとおりです。使い始めるには、ソースドキュメントから自動推論ポリシーを構築し、テストケースで検証します。お客様からは、この反復的なチューニングがポリシー開発における最大のボトルネックになっているという声が寄せられていました。 この記事では、2 つの新しい改善モードを解説します。ルールの問題に対応する Iterative Refinement (反復的な改善) と、言語の問題に対応する Ambiguous Variable Refinement (あいまいな変数の改善) です。各モードについて、API ワークフロー全体 (開始、ポーリング、取得) と、失敗するポリシーを合格するポリシーに変えるための再現可能なコンソール手順を紹介します。 自動推論チェックとは何か 自動推論チェックは自然言語を形式論理に変換し、自動推論の技術を適用して次のいずれかの検出結果を生成します。 VALID 、 INVALID 、 SATISFIABLE 、 IMPOSSIBLE 、 TRANSLATION_AMBIGUOUS です。ポリシーの仕組みについて詳しくは、「 自動推論チェックを使用して、AI のハルシネーションを最小限に抑え、最大 99% の検証精度を実現: 今すぐご利用いただけます 」を参照してください。 訳注: 2026 年 9 月 13 日時点の Amazon Bedrock API リファレンスでは、自動推論チェックが返す検出結果 (finding) として、本文で挙げた 5 種類に加えて NO_TRANSLATIONS と TOO_COMPLEX が定義されており、合計 7 種類があります。参照: GuardrailAutomatedReasoningFinding – Amazon Bedrock API Reference この記事で重要となる概念は、 2 ステップの検証パイプライン です。まず、 変換 (translate) ステップでは、ポリシー内の変数の説明を使用して、自然言語の入力/出力を変数の割り当てにマッピングします。次に、 検証 (validate) ステップでは、それらの割り当てに形式ルールを適用します。テストが失敗したときは、根本原因はこの 2 つのステップのいずれかにあり、各改善モードはそれぞれ異なるステップを対象としています。図 1 はこのパイプラインを最初から最後まで示しています。 図 1: 自動推論チェックが実行時に応答を検証する仕組み。自動推論チェックは、ポリシーの変数の説明を使用して自然言語を変数に変換し、それらの変数をポリシーの形式ルールに照らして検証し、検出結果を返します。この 2 ステップのパイプラインがあるため、改善には 2 つのモードが存在します。 ポリシーのテスト。 ポリシーにテストを追加して検証します。各テストは、入力/出力テキストと期待する結果で構成されます。テストは個別にも一括でも実行できます。失敗結果を見れば、ポリシーが意図からどこで逸脱しているかが正確にわかります。 ポリシーに改善が必要な理由: 2 つの失敗モード 2 ステップのパイプラインを思い出してください。 変換 (自然言語から変数の割り当てへ) と、それに続く 検証 (形式論理から検出結果へ) です。テストの失敗は、このいずれかのステップが予期しない結果を生成したことを意味します。自動推論チェックは、各ステップに明確に対応する 2 種類の失敗シグナルを提示します。 失敗モード 1: ルールの問題 (論理が誤っている) ルールの問題による失敗では、変換は正しく機能しています。適切な変数に適切な値が入っているのに、検証結果が期待と一致しません。問題はルールにあり、ルールが緩すぎる、厳しすぎる、あるいはまったく存在しないというケースです。具体的には、不足しているルールや緩すぎるルールが誤った回答を通してしまい、 INVALID を期待していたのに SATISFIABLE が返される場合です。逆に、過度に厳格なルールが正しい回答をブロックし、 SATISFIABLE を期待していたのに INVALID が返される場合もあります。 考え方: システムは質問を完全に理解していたものの、誤った論理を適用しました。修正すべきなのは ルール です。 失敗モード 2: 変換のあいまいさ (言語が誤っている) テストが TRANSLATION_AMBIGUOUS を返す場合、検証エンジンは動作しますが、どの解釈に従うかによって結果が変わります。自然言語の入力をポリシーの変数にどうマッピングするかで変換モデル間の判断が分かれ、競合する各解釈がそれぞれ異なる検証結果につながるケースもあります。検出結果には、それぞれ独自の変換と結論を持つ 2 つ以上の選択肢が示され、さらに解釈が実際にどこで分かれるかを示す differenceScenarios も提示されます。よくある根本原因としては、変数定義の重複 (「tenure」と「years of service」など)、説明があいまいであること、値の形式が一貫していないこと (「5%」に対して 5 と 0.05 のどちらを使うかなど) が挙げられます。 失敗とモードの対応 次の表は、どの改善モードがどの失敗タイプに対応するかをまとめたものです。 失敗モード 根本原因 改善モード 動作内容 ルールの問題 論理が誤っている Iterative Refinement ルールまたは変数の追加、編集、削除を提案する 変換のあいまいさ 言語があいまいである Ambiguous Variable Refinement 複数の解釈を 1 つにまとめる、より明確な変数の説明を提案する システムが単一の変換を決定できない場合は、 Ambiguous Variable Refinement を使用します。続く 2 つのセクションでは、各モードについて、何をするのか、いつ使うのか、レビューゲートはどう機能するのか、そしてプログラムからどう起動するのかを順に説明します。ルールの問題による失敗のほうが多いため、まず Iterative Refinement から始めます。 Iterative Refinement: ルールの修正 論理が誤っているためにテストが失敗する場合 (変換は問題ないが検証結果が期待と一致しない場合)、問題はルールにあります。 Iterative Refinement ( ITERATIVELY_REFINE_POLICY ) は診断と修正のサイクルを自動化するため、各ルールを手作業でたどり、修正内容を推測し、形式論理を手で編集する必要がなくなります。 10～30 個のルールを持つポリシーを考えてみましょう。従来は、1 つの修正のために、対象分野の専門家が手動で診断し、SMT-LIB で記述された形式論理を手作業で編集することを何度も繰り返す必要がありました。この作業は今では、レビューして承認するだけの 1 ステップに集約され、形式論理を手で書く必要はなくなります。 仕組み Iterative Refinement は 3 つの入力を受け取ります。1 つ目は既存のポリシー定義 (現在のルール、変数、型) です。2 つ目は、本来どう動作 すべき かを記述した信頼できる自然言語テキストを含むソースドキュメントです。3 つ目の入力は任意で、望む変更を明示的に指示する自然言語のフィードバックです。 例えば、フィードバックフィールドには次のような内容を記述できます。 「改訂版ドキュメントのセクション 3 に規定されているとおり、育児休暇の勤続期間要件を 12 か月から 6 か月に更新してください」 。 これらの入力を受けて、改善エンジンは現在のルールがソースドキュメントとフィードバックからどのように逸脱しているかを分析します。そして、ポリシーを整合させる一連の変更候補 (新しいルール、編集されたルール、追加された変数) を提案します。 収束ループ Iterative Refinement は名前が示すとおり反復処理を行います。内部では、エンジンが変更候補を生成し、保存済みのテストへの影響をシミュレートし、これまで失敗していたテストが合格するようになったかを確認し、そうでなければ調整します。1 回のリクエストで複数の内部サイクルが発生することもあります。特に、1 つのルールの修正が他のルールに波及する場合にそうなります。ただし、この反復は 内部的に 行われます。中間段階の試行は 1 つずつ表示されず、進行を管理する必要もありません。受け取るのは収束後の結果、つまりどのルールが変わり、どの変数が変わり、その変更がテストスイート内のすべてのテストにどう影響するかを正確に示す差分案です。 レビューゲート 収束後、 [Review policy changes] 画面が表示されます。 次に、 [Accept changes] または [Discard changes] を選択します。承諾すると、変更が DRAFT ポリシーに書き込まれます。破棄すると、すべてが元のまま維持されます。 前提条件と使用する場面 Iterative Refinement では、ポリシーに少なくとも 1 つのテストが追加されている必要があります。失敗したテストのシグナルがなければ、改善の手がかりが得られないからです。このモードは、変換が正しい (適切な変数と適切な値) にもかかわらず検証結果が予期しないものである場合に使用します。検出結果が TRANSLATION_AMBIGUOUS の場合には使用しないでください。それは言語の問題であり、 Ambiguous Variable Refinement で対処するほうが適切です。 API からの実行 改善処理は非同期のビルドワークフローとして実行されます。AWS SDK for Python (Boto3) を使用する場合、フローは 4 つのステップで構成されます。現在のポリシー定義をエクスポートし、ワークフローを開始し、完了をポーリングし、提案された変更を取得します。 buildWorkflowType には ITERATIVELY_REFINE_POLICY を設定します。 iterativeRefinementContent ブロックは、1～5 個のソースドキュメント (必須) と、最大 4,000 文字の任意のフィードバックを受け取ります。 import boto3 bedrock = boto3.client("bedrock") # Export the current policy definition (required input to the workflow). policy_definition = bedrock.export_automated_reasoning_policy_version( policyArn=policy_arn, )["policyDefinition"] with open("hr-leave-policy.pdf", "rb") as f: source_document = f.read() response = bedrock.start_automated_reasoning_policy_build_workflow( policyArn=policy_arn, buildWorkflowType="ITERATIVELY_REFINE_POLICY", sourceContent={ "policyDefinition": policy_definition, "workflowContent": { "iterativeRefinementContent": { "documents": [ { "document": source_document, "documentName": "hr-leave-policy.pdf", "documentContentType": "pdf", } ], "feedback": "Update the tenure requirement from 12 to 6 months per section 3.", } }, }, ) build_workflow_id = response["buildWorkflowId"] この呼び出しは、提案された変更ではなく buildWorkflowId を即座に返します。ワークフローは SCHEDULED から BUILDING へ移行し、最終的に COMPLETED 、 FAILED 、または CANCELLED に到達します。収束にかかる時間はポリシーのサイズに応じて通常 1 分から数分です。ステータスが終端状態に達するまで get_automated_reasoning_policy_build_workflow をポーリングします。その後、 get_automated_reasoning_policy_build_workflow_result_assets で収束した提案を取得します。更新されたルールを確認するには POLICY_DEFINITION アセットを、アクションログを確認するには BUILD_LOG をリクエストします。 import time while True: workflow = bedrock.get_automated_reasoning_policy_build_workflow( policyArn=policy_arn, buildWorkflowId=build_workflow_id, ) status = workflow["status"] if status in ("COMPLETED", "FAILED", "CANCELLED"): break time.sleep(10) if status == "COMPLETED": assets = bedrock.get_automated_reasoning_policy_build_workflow_result_assets( policyArn=policy_arn, buildWorkflowId=build_workflow_id, assetType="POLICY_DEFINITION", ) proposed_definition = assets["buildWorkflowAssets"]["policyDefinition"] 返されるポリシー定義は提案された DRAFT であり、新しい定義の全体です。これをコミットするには、この定義を指定して update_automated_reasoning_policy を呼び出します。何が変わったかを確認するには、ワークフローを開始する前にエクスポートしたポリシー定義との差分を取ります。コンソールの [Review policy changes] 画面は、この開始・ポーリング・取得という同じ手順をラップし、[Accept changes] ボタンと [Discard changes] ボタンで操作できるように差分を表示しています。 Ambiguous Variable Refinement: 言語の修正 Iterative Refinement はルールの問題に対応しますが、失敗するテストのすべてがルールの問題であるとは限りません。変換そのものが不安定な場合、ルールをいくら編集しても解決しません。この場合は、ポリシーが変数を説明するために使っている言語を修正する必要があります。それを行うのが Ambiguous Variable Refinement です。このモードも同じ非同期の開始・ポーリング・取得パターンに従い、同じレビューと承諾の画面に到達します。違いは提案内容です。提案は変数の説明とマージを中心とし、ポリシーの一貫性を保つために必要に応じてルールと型の更新も適用されます。 テストが TRANSLATION_AMBIGUOUS の結果を生成する場合 (この記事の前半にある失敗モード 2 を参照してください)、競合する変換が異なる検証結果につながっています。あいまいさは、検証対象のコンテンツ自体の表現方法から生じることもあります。このセクションでは、ポリシー変数におけるあいまいさに焦点を当てます。 仕組み ポリシー変数の問題に起因する変換のあいまいさは、通常いくつかの根本原因から生じます。重複する変数は、2 つの変数が同じ概念を記述している場合に発生します。例えば、tenureMonths (「従業員が何か月働いているか」) と monthsOfService (「従業員の勤続月数」) はどちらも雇用期間をとらえています。その結果、どちらを使うべきかについて、変換モデル間で判断が分かれます。説明が不完全なケースは、変数の説明があいまいすぎて変換を導けないときに起こります。値の形式が一貫していないケースでは、「5%」を interestRate = 5 とすべきか interestRate = 0.05 とすべきかをシステムが判断できず、あいまいさが生じます。変数名に論理が埋め込まれていると混乱を招きます。timelyReportingNotFeasible のような名前は既に否定を含んでいるため、肯定のケースを表現するには否定の否定が必要になります。変換モデルはしばしばこの 2 つの否定のうち 1 つを取りこぼします。 これらは最も一般的なパターンにすぎません。検出は既知の問題の固定リストと照合するのではなく、ポリシーの変数を実際に変換で使用して行われるため、変換の不一致を引き起こす変数レベルの問題は、ここに挙げた以外のものも表面化し得ます。 Ambiguous Variable Refinement を実行すると、どの変数の説明や重複する定義が不一致の原因になっているかを特定し、複数の解釈を 1 つの正確な定義にまとめる、改善された説明を提案します。 改善された説明には、単位変換のルール、同義語、別の表現、明示的な形式のガイダンスが盛り込まれます。次のビフォー/アフターの例は、典型的な提案を示しています。 変更前 変更後 (提案) tenureMonths: 「従業員が何か月働いているか」 tenureMonths: 「従業員が継続して雇用されている期間の月数 (1 か月未満の端数は含めません)。ユーザーが勤続年数に言及した場合は月数に変換します (例: 2 年 = 24 か月)。この変数は、雇用期間、勤続期間、在社期間、または勤続年数への言及をとらえます」 重複する変数が検出された場合は、マージも提案されることがあります。一方の変数が削除され、それを参照するルールは残った変数を使用するように更新されます。 レビューゲート Iterative Refinement と同様に、何も適用される前に提案された変更をレビューします。 また、[Test results] も表示されます。以前は TRANSLATION_AMBIGUOUS を返していたテストが、確定的な VALID 、 INVALID 、または SATISFIABLE の結果を生成するようになります。 [Accept changes] または [Discard changes] を選択します。承認するまで、DRAFT ポリシーには一切の変更が加えられません。 使用する場面 Ambiguous Variable Refinement は、テストが TRANSLATION_AMBIGUOUS の結果を生成する場合、または VALID / INVALID の検出結果を確認したときに、変換が誤った変数に値を割り当てていることが判明した場合に使用します。変換が正しいのに検証結果が予期しないものである場合には使用しないでください。それはルールの問題であり、 Iterative Refinement の対象です。 API からの実行 Ambiguous Variable Refinement は、同じ非同期の開始・ポーリング・取得パターンを使用します。 buildWorkflowType には RESOLVE_POLICY_AMBIGUITIES を設定します。このモードはポリシーの変数を直接分析するため、ソースドキュメントも追加済みのテストも必要とせず、workflowContent は省略できます。ただし、現在のポリシー定義は sourceContent に引き続き必要です。 Iterative Refinement の場合と同様に、前述の export_automated_reasoning_policy_version を使ってまずエクスポートしてください。 response = bedrock.start_automated_reasoning_policy_build_workflow( policyArn=policy_arn, buildWorkflowType="RESOLVE_POLICY_AMBIGUITIES", sourceContent={ "policyDefinition": policy_definition, }, ) build_workflow_id = response["buildWorkflowId"] Iterative Refinement と同様に、レスポンスは buildWorkflowId です。ステータスが終端状態に達するまで get_automated_reasoning_policy_build_workflow をポーリングします。その後、 get_automated_reasoning_policy_build_workflow_result_assets を assetType="POLICY_DEFINITION" とともに呼び出して、提案された変数の説明とマージを取得します。 while True: workflow = bedrock.get_automated_reasoning_policy_build_workflow( policyArn=policy_arn, buildWorkflowId=build_workflow_id, ) status = workflow["status"] if status in ("COMPLETED", "FAILED", "CANCELLED"): break time.sleep(10) if status == "COMPLETED": assets = bedrock.get_automated_reasoning_policy_build_workflow_result_assets( policyArn=policy_arn, buildWorkflowId=build_workflow_id, assetType="POLICY_DEFINITION", ) proposed_definition = assets["buildWorkflowAssets"]["policyDefinition"] 承諾するまで、変更は提案の状態にとどまります。 すべての変更はお客様が承認: ヒューマンインザループのゲート 両方の改善モードには、譲れない共通の性質が 1 つあります。 お客様が承認するまで、いかなる変更も反映されません。 改善エンジンが持つのは 提案する権限 で、分析し、診断し、提案できます。お客様が持つのは コミットする権限 です。DRAFT ポリシー、ひいては本番環境に何を反映するかを決めるのはお客様です。 5 ステップのループ どの改善モードを使用する場合も、ワークフローは同じ 5 ステップのパターンに従います。第 1 にテストです。保存済みのテストを現在のポリシーに対して実行します。第 2 に確認です。どのテストが期待した結果と一致しないかを特定します。第 3 に提案です。システムがルールまたは変数の説明に対する修正候補を生成します。第 4 にレビューです。提案された差分とテストへの影響を確認します。第 5 に適用です。変更を承諾して DRAFT に適用するか、拒否して何も変更しないかを選びます。 承諾した後は、他のテストを壊さずに問題が解決したことを確認するため、再テストを行います。このようにして、各サイクルの進展が後戻りせずに積み重なっていきます。サイクルごとに、テストに合格するポリシーに近づくか、新たな診断情報が得られるかのいずれかです。 レビュー画面で確認できる内容 レビュー画面では、変更内容そのものだけでなく、その変更の 波及効果 を把握できます。この画面は 2 つの問いに同時に答えます。エンジンは何を提案したのか、そしてその提案は、重視しているすべてのテストにどう影響するのかです。 提案は 3 つのセクションで示されます。 [Changes to rules] には、追加、編集、削除されたルールが、それぞれの形式論理の式とともに一覧表示されます。 [Changes to variables] には、更新された変数の説明と、追加または削除された変数が表示されます。変更前の文言と提案された文言が並べて示されるため、両者を直接比較できます。 [Changes to custom variable types] は、ポリシーの列挙型に対する変更を扱います。 これらの変更とあわせて、画面には [Test results] セクションが表示され、保存済みのテストとその変更前後の結果が一覧化されます。各行には期待される検出結果と、変更前後でテストが合格したかどうかが示されます。行の [View findings] を選択すると、検出結果そのものを確認できます。このビューは画面上で最も重要な指標です。失敗していたテストが合格し、合格していたテストが引き続き合格しているのであれば、安心して承諾できます。 Fidelity Report による検証 変更を適用した後は、 Fidelity Report (忠実度レポート、 GENERATE_FIDELITY_REPORT ) を生成し、更新後のポリシーがソースドキュメントを引き続き忠実に表現しているかを検証します。このレポートは 3 つの測定値を提供します。 カバレッジスコア (0.0～1.0) は、ソースドキュメントのどれだけがポリシーに反映されているかを示します。 精度スコア (0.0～1.0) は、ルールが元のドキュメントの意図にどれだけ忠実に一致しているかを示します。 ルールごとのグラウンディング は、各ルールを、その裏付けとなるソースドキュメント内の具体的な記述に、根拠とともに結び付けます。 改善の前後で Fidelity Report を比較してください。精度スコアが低下している場合、提案された修正がソース資料から逸脱している可能性があり、拒否するかさらに反復すべきというシグナルになります。 原則 自動改善が加速するのは、失敗を診断し修正候補を生成する 作業 です。ただし、ガードレールが適用するルールを変更する 権限 は、引き続きお客様が保持します。すべての修正は、お客様が承諾すると決めるまで提案のままです。 エンジンの方向付け: ソースドキュメントとカスタムフィードバック 適切な修正へより早くたどり着けるようコンテキストを提供すれば、両方のモードを望む方向に導けます。 ソースドキュメント Iterative Refinement を起動するときは、ポリシーが表現すべきグラウンドトゥルースを表すソースドキュメントを指定します。コンソールでは、そのための 3 つのモードが用意されています。 [Recently used] は以前にアップロードしたドキュメントを再選択し、 [Upload] は新しい PDF またはテキストファイルを受け取り、 [Enter text] は貼り付けたコンテンツを直接受け取ります。ドキュメントが明確で焦点が絞られているほど、提案も正確になります。 カスタムフィードバック: 明示的な if-then ガイダンス 何を修正すべきかをシステムに正確に伝える 自然言語のフィードバック を提供することもできます。効果的なフィードバックは具体的で検証可能です。「勤続期間のルールを修正してください」のようなあいまいなフィードバックは、エンジンに過大な裁量を与えてしまいます。次のような具体的で検証可能な代替案と比べてみてください。「従業員がフルタイムで、6 か月 (12 か月ではなく) を超えて勤務している場合、育児休暇の対象となるべきです」。 フィードバックは制約として機能します。システムは、ソースドキュメントとガイダンスの両方を満たす変更を生成します。両者が矛盾する場合は、その矛盾がレビュー用にフラグ付けされます。 ソースドキュメントとフィードバックを同時に指定することもできます。ドキュメントの情報量が多い場合、フィードバックによって重要な特定のセクションにシステムの注意を集中させられます。 エンドツーエンドのウォークスルー このセクションでは、各改善モードに対応する 2 つのウォークスルーを紹介します。この 2 つを合わせることで、両方の失敗タイプに対する再現可能なワークフローが得られます。 前提条件 Amazon Bedrock の自動推論チェックでポリシーの自動改善を使用するには、次の前提条件を満たしていることを確認してください。 有効な AWS アカウント 自動推論チェックが利用可能な AWS リージョンの確認と、そのいずれかのリージョンにおける Amazon Bedrock へのアクセス 訳注: 2026 年 9 月現在、自動推論チェックがサポートする言語は英語です。最新の対応状況は、Amazon Bedrock ユーザーガイドの「 Amazon Bedrock ガードレールの自動推論チェックとは 」を参照してください。 自動推論ポリシーを作成、表示、改善し、Amazon Bedrock Guardrails を操作するための IAM アクセス許可 強制したいルールを記述したソースドキュメントから作成された、アカウント内の自動推論ポリシー。手順の詳細については、「 自動推論ポリシーを作成する 」を参照してください。このポリシーには少なくとも 1 つのテストが追加されている必要があります。Iterative Refinement は診断を進めるために失敗したテストのシグナルを必要とします。テストを追加するには、「 自動推論ポリシーをテストする 」を参照してください。 ウォークスルー A: Iterative Refinement によるルールの問題の修正 休暇の取得資格を定める人事ポリシーに、失敗するテストがあります。アシスタントは、 勤続 8 か月のパートタイム従業員が育児休暇の対象になる と回答します。テストは INVALID を期待していますが、ポリシーは VALID を返します。 ステップ 1: テストを検証する Amazon Bedrock コンソールで [Automated Reasoning] に移動し、ポリシーを開きます。 [Tests] タブを選択し、次に [Validate all tests] を選択します。図 2 に結果を示します。4 つのテストのうち 3 つは合格し、育児休暇のテストは予期しない VALID の検出結果で失敗します。 図 2: 検証後の [Tests] タブ。4 つのテストのうち 3 つが合格 (75%) ステップ 2: 失敗した検出結果を確認する 失敗したテストの検出結果を開き、図 3 に示す変換内容を確認します。変数は正しくとらえられています。 monthsOfContinuousService = 8 employmentStatus = PART_TIME 図 3: 失敗したテストの検出結果。変換が変数を正しくとらえていることがわかる 検出結果が VALID となっているのは、根拠となる唯一のルールが継続勤務 6 か月後に資格を付与しており、パートタイム従業員を除外するルールが存在しないためです。変換に問題はなく、論理が誤っているため、これはルールの問題です。 ステップ 3: ポリシーを改善する [Refine policy] を選択し、次に [Automatically refine policy] を選択します。 改善タイプを Iterative Refinement に設定します。 次の 3 つのモードのいずれかを使用して、ソースドキュメントを指定します。 [Recently used] [Upload] (新しいバージョンをアップロード) [Enter text] (該当する段落を貼り付ける) 必要に応じて、修正の焦点を絞るためのカスタムフィードバックを追加します。例: 「 パートタイム従業員を育児休暇の対象外とすることを明示するルールを追加してください 」。 入力の準備ができたら、 [Start] を選択します。 図 4 は、改善タイプを選択し、ソースドキュメントを添付し、カスタムフィードバックを入力した設定完了時の状態を示しています。 図 4: ソースドキュメントとカスタムフィードバックを指定した Iterative Refinement の設定 ステップ 4: 変更をレビューして承諾する 収束が完了すると、 [Review policy changes] 画面が表示されます。 [Changes to rules] には、削除されたルール 1 件と追加されたルール 1 件の 2 つの変更が一覧表示されます。エンジンは、継続勤務のみで資格を付与していたルールを削除しました。 monthsOfContinuousService が 6 以上の場合、 isEligibleForParentalLeave は true になります そして、パートタイム従業員を除外するルールを追加しました。 employmentStatus が PART_TIME と等しい場合、 isEligibleForParentalLeave は false になります [Test results] では、パートタイムのテストが [Failed] から [Passed] に変わり、他の 3 つのテストは [Passed] のままです。図 5 は承諾前の画面を示しています。 図 5: [Review policy changes] 画面。[Changes to rules] には、削除された勤続期間のみによる資格ルールと、追加されたパートタイム除外ルールが一覧表示され、[Test results] にはパートタイムのテストが Failed から Passed に変わり、リグレッションがないことが示されています。 [Accept changes] を選択します。 ステップ 5: 修正を確認する [Tests] タブに戻り、再度 [Validate all tests] を選択します。 図 6 に期待される結果を示します。これまで失敗していたテストが合格し、合格率は 100% に達します。 図 6: 改善後の [Tests] タブ。4 つのテストすべてが合格 (100%) テストが引き続き失敗する場合やリグレッションが発生した場合 1 回の改善サイクルですべての失敗が解消されることや、リグレッションが発生しないことは保証されません。これまで失敗していたテストが依然として失敗する場合、または以前は合格していた他のテストが失敗するようになった場合は、次の手順を行ってください。 レビュー画面で [Discard changes] を選択します。 エンジンが前回とは異なる形で何を修正すべきかを説明する、より具体的なカスタムフィードバックを追加します。例: 「このルールは、パートタイム従業員の資格期間を短縮するだけで済ませず、育児休暇の対象から完全に除外すべきです」 。 ソースドキュメントを、失敗しているルールに対応する正確なセクションに絞り込みます。 これらの絞り込んだ入力で、再度 Iterative Refinement を実行します。 2 回か 3 回試してもテストが合格しない場合は、手作業による編集に切り替えてください。失敗した検出結果の変換内容とルールのトレースを手がかりに、ポリシーエディタで該当するルールを手で編集します。 ステップ 6: レポートを生成してデプロイする [Generate Fidelity Report] を選択し、前回のレポートとスコアを比較します。 結果に問題がなければ、デプロイ用に 番号付きバージョン を作成します。 ウォークスルー B: Ambiguous Variable Refinement による言語の問題の修正 同じ人事ポリシーを使いますが、今回はテストが TRANSLATION_AMBIGUOUS を返します。検出結果には 2 つの選択肢が示されます。 一方は「2 years of service」を tenureMonths = 24 と解釈しました。 もう一方は monthsOfService = 24 と解釈しました。 この 2 つの選択肢から、変数の重複が明らかになります。tenureMonths と monthsOfService はどちらも雇用期間を記述しており、どちらを使うべきかについて変換モデル間で判断が一致しません。この重複があいまいさの根本原因です。 ステップ 1: ポリシーを改善する [Refine policy] を選択し、次に Ambiguous Variable Refinement を選択します。 図 7 に示すように、このモードではソースドキュメントは必要ないため、設定は 1 つの選択だけで完了します。 図 7: ソースドキュメントを必要としない Ambiguous Variable Refinement の設定 [Start] を選択します。 ステップ 2: 変更をレビューして承諾する [Review policy changes] 画面で、提案された変数のマージをレビューします。 monthsOfService が削除されます。 ルールが tenureMonths を参照するように更新されます。 tenureMonths の説明が次のように拡張されます。 「従業員が継続して雇用されている期間の月数 (1 か月未満の端数は含めません)。ユーザーが勤続年数に言及した場合は月数に変換します (例: 2 年 = 24 か月)。この変数は、雇用期間、勤続期間、在社期間、または勤続年数へのすべての言及をとらえます」 [Test results] では、これまであいまいだったテストが確定的な VALID の結果を生成するようになります。 [Accept changes] を選択します。 ステップ 3: 修正を確認する [Tests] タブに戻り、再度 [Validate all tests] を選択します。 図 8 に確認結果を示します。これまで TRANSLATION_AMBIGUOUS を返していたテストが、確定的な VALID の検出結果を生成し、合格するようになります。 図 8: あいまいな変数の改善を適用した後の [Tests] タブ ステップ 4: レポートを生成してデプロイする [Generate Fidelity Report] を選択し、前回のレポートとスコアを比較します。 結果に問題がなければ、デプロイ用に番号付きバージョンを作成します。 注意 どちらの改善モードでも、テストが合格することや、提案された変更がリグレッションを引き起こさないことは保証されません。テストが合格しない場合や、合格していた他のテストが失敗するようになった場合は、変更を破棄して再度試すことができます。 ベストプラクティスと実際のユースケース 改善エンジンは、明確なシグナルと範囲の限定された変更を与えたときに最も効果を発揮します。次のプラクティスはその方法を示し、ユースケースはそれが効果を発揮する場面を示します。 ベストプラクティス 次のプラクティスは、改善がうまくいかなくなる最も一般的な 2 つのパターンから導かれたものです。あいまいな失敗シグナルで改善を実行してしまうケースと、意図した以上にポリシーを変更させてしまうケースです。 モードを選ぶ前に変換内容を読む。 まず失敗した検出結果を開き、変数の割り当てを確認します。適切な変数に適切な値が入っているのに結果が誤っている場合は、 Iterative Refinement で対処すべきルールの問題です。割り当てが誤っている場合、または検出結果が TRANSLATION_AMBIGUOUS の場合は、 Ambiguous Variable Refinement で対処すべき言語の問題です。変換内容を確認せずに症状だけでモードを選ぶことが、誤った箇所を「修正」してしまう改善の最も多い原因です。 入力の範囲を絞って変更を限定する。 ポリシーの一部分 (例えば育児休暇の資格) に範囲を絞ったソースドキュメントに対して改善を実行します。修正が必要なルールが 1 つだけの場合は、具体的な if-then 形式のフィードバックを組み合わせます。焦点の絞られた入力は、「勤続期間のルールを修正してください」のようなあいまいなガイダンスで 40 ページのハンドブック全体をエンジンに与える場合よりも、範囲が限定されレビューしやすい提案を生み出します。 差分よりも [Test results] を信頼する。 レビュー画面には、変更されたルールと、保存済みのすべてのテストへの影響の両方が表示されます。判断の決め手となるのは [Test results] パネルです。失敗していたテストが合格に転じ、合格していたテストがそのまま合格を維持しているときに承諾してください。きれいに見える差分でも、それによって以前は合格していたテストが失敗するようになるなら、それは修正ではありません。 バージョンを作成する前に Fidelity Report を比較する。 改善処理はテストを合格させるように最適化します。その最適化により、ルールがソースドキュメントの実際の記述から離れてしまうことがあります。承諾した後は、改善前の実行結果と精度スコアを比較してください。スコアの低下は逸脱のシグナルであり、やり直しを盲目的に繰り返すのではなく、拒否して反復すべき理由になります。テストが合格し、レポートの内容にも問題がなければ、番号付きバージョンを作成して変更を本番環境に昇格させます。 実際のユースケース これらのパターンは規制業界全体に当てはまります。人事制度の適用対象を判定するシナリオでは、従業員ハンドブックが毎年更新されます。Iterative Refinement が新しいドキュメントを取り込んでルールの変更を提案するため、人事チームは形式論理に触れることなくレビューできます。金融サービスでは、debtToIncomeRatio と DTI のような重複する変数が、顧客の多様な表現に対して変換のあいまいさを引き起こします。Ambiguous Variable Refinement はそれらを統合し、決定論的な検証を可能にします。臨床プロトコルが改訂された場合、ヘルスケアのコンプライアンスチームは新しいガイドラインをアップロードします。Iterative Refinement がルールの更新を提案し、チームは本番環境へ反映する前に提案を検証します。製造業の品質保証では、公差が時間とともに厳しくなります。チームはポリシーを反復的に改善しながら、バージョン管理されたスナップショットと Fidelity Report を通じて監査証跡を維持します。 まとめ 規制対象の領域に生成 AI を投入するチームは、隠れたコストを支払ってきました。それがポリシーのメンテナンスです。 ポリシーの自動改善は、変更を承認する権限をお客様に残したまま、必要な作業量を減らします。 ルールと言語の二分法。 論理が誤っている場合 (ルールが緩すぎる、厳しすぎる、または存在しない場合) は、 Iterative Refinement がソースドキュメントとフィードバックに基づいた形式論理の修正案を提示します。言語が誤っている場合 (変数の重複、あいまいな説明、一貫性のない形式) は、 Ambiguous Variable Refinement が、競合する解釈を 1 つにまとめる正確な変数定義を提案します。 承認ゲート。 どちらの場合も、システムが提案し、お客様が決定します。提案されたすべての変更は、差分 と 、保存済みのテストへの影響を示すレビュー画面に表示されます。明示的な承認がなければ、DRAFT ポリシーにも、まして本番環境にも変更は届きません。作業は自動化され、権限はお客様の手に残ります。 次のステップ テストを追加した自動推論ポリシーをまだお持ちでない場合は、まずソースドキュメントからポリシーを作成し、重要なシナリオをカバーするテストを追加してください。リンクについては、「 前提条件 」セクションを参照してください。ポリシーと少なくとも 1 つの失敗するテストが手元にあれば、今日のうちに失敗するテストを 1 つ選び、その検出結果を確認してみてください。変換が正しいのに結果が誤っている場合は、焦点を絞ったソースドキュメントを用意して Iterative Refinement を実行します。結果が TRANSLATION_AMBIGUOUS の場合は、 Ambiguous Variable Refinement を実行します。 提案を承諾し、再テストを行い、前後で Fidelity Report を比較してください。形式論理を 1 行も手で書くことなく、あいまいでない変換において最大 99% の精度で検証された、より緻密なポリシーが得られます (「 自動推論チェックを使用して、AI のハルシネーションを最小限に抑え、最大 99% の検証精度を実現: 今すぐご利用いただけます 」を参照してください)。 リソース 開始する: セットアップのガイダンスについては、「 自動推論チェックのドキュメント 」を参照してください。または、 Amazon Bedrock コンソール で既存のポリシーを開き、 [Refine policy] を選択してください。このサービスの詳細については、 Amazon Bedrock をご覧ください。 実践的なウォークスルー: 手順を追ったガイドについては、「 How to minimize generative AI hallucinations with Automated Reasoning checks 」を参照してください。 訳注: 上記の記事はプレビュー期間中 (2025 年 4 月) に公開されたものです。一般提供開始後の機能に基づいた手順は、日本語版ブログの「 Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1 」で確認できます。 回答を書き換えるチャットボット: チャットボットは、自動推論チェックのフィードバックを利用して回答を反復的に書き換え、証明可能に正しい回答に到達するまでユーザーに確認の質問を投げかけることができます。「 自動推論チェックで回答を書き換えてハルシネーションを抑えるチャットボットのリファレンス実装 」と、 GitHub のサンプルコード を参照してください。 ポリシー形式化エージェント: エージェントは、自動推論ポリシーを改善するプロセス全体を自然言語で対象分野の専門家に案内できます。そのようなエージェントの オープンソースサンプル を参照してください。 コードサンプル: GitHub の 自動推論チェックのサンプル をご覧ください。 お客様の成果: Amazon Logistics の導入事例 | PitCrew の導入事例 | PwC の教育分野における責任ある AI の導入事例 | AWS の責任ある AI に関するリソース Amazon Bedrock の機能に関する詳細情報: Amazon Bedrock Guardrails | Amazon Bedrock AgentCore 責任ある AI のガイダンス: AWS Well-Architected Responsible AI Lens 99% という精度の数値について 冒頭とまとめのセクションで引用している 99% という数値は、自然言語から形式論理への変換があいまいでない場合に、正しい検出結果 ( VALID 、 INVALID 、または SATISFIABLE ) が得られる割合を測定した検証精度を指します。この数値は一般提供開始のお知らせ「 自動推論チェックを使用して、AI のハルシネーションを最小限に抑え、最大 99% の検証精度を実現: 今すぐご利用いただけます 」(AWS News Blog、2025 年 8 月 6 日) で初めて公開されました。 著者について Nafi Diallo Nafi は Amazon Web Services の Senior Applied Scientist で、AI の安全性、自動推論、信頼できる AI ソリューションのためのガードレール実装を専門としています。Amazon Bedrock 上の生成 AI およびエージェンティックシステムの信頼性を評価し改善する分野で豊富な経験を持っています。また、AWS の Women in AI and ML (WAIML) 組織の北米地域リードも務め、チャプターの成長を支援しながら、地域全体で WAIML のミッションを推進しています。 Ferhat Erata Ferhat は AWS AI Labs の Applied Scientist で、大規模言語モデルと形式的推論を組み合わせたニューロシンボリックシステムを構築し、生成 AI およびエージェンティック AI を検証可能にする取り組みを行っています。その研究は AI の安全性とセキュリティ、自動形式化、検証済みコード生成にまたがり、検証器のフィードバックを用いて推論モデルを事後学習させ、出力を形式仕様に整合させています。Ferhat はイェール大学でコンピュータサイエンスの博士号を取得しており、NeurIPS、ICML、AAAI、ACL の査読者を務めています。 Fernando Galves Fernando は AWS の Senior Applied AI Architect で、金融サービスやその他の規制業界の企業が生成 AI およびエージェンティック AI を実験段階から本番環境へ移行できるよう支援しています。AI のセキュリティ、ガバナンス、評価を専門とし、お客様との取り組みは AWS のエージェンティック AI サービスのセキュリティ方針に直接反映されています。ソフトウェアエンジニアリング、サイバーセキュリティ、機械学習にわたる 25 年以上の経験を持ち、以前は大手銀行や小売企業で利用されるクラウドベースの生体認証および不正防止システムを構築していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 10 月 1 日に公開された “ Share Systems Manager documents across your AWS Organization with AWS RAM ” を翻訳したものです。 はじめに Automation ランブックや Run Command ドキュメントといった AWS Systems Manager (SSM) ドキュメントを AWS Organization 全体で運用している場合、どのアカウントがそれらを実行できるかを決める必要があります。これまでは、 ModifyDocumentPermission API を使って、ドキュメントごとに個々のアカウント ID のリストを指定して共有するしかありませんでした。この API で指定できるのは 1 ドキュメントあたり最大 1,000 アカウント ID（1 回の呼び出しでは 20 件）です。新しいアカウントをプロビジョニングしたり、組織単位 (OU) の構成を変更したりするたびに、誰かが手作業でそのリストを更新しなければなりませんでした。アカウント数が増えるほど、この保守作業も増えていきます。 AWS Systems Manager は、 AWS Resource Access Manager (AWS RAM) を通じて組織全体または特定の OU に SSM ドキュメントを共有できるようになりました 。リソース共有を作成してドキュメントを追加し、共有先となる組織または OU を選択します。アカウントが組織に参加したり組織から外れたりしても、共有の状態は自動的に同期されます。アカウント ID 単位ではなく組織構造単位でアクセスを管理できるようになり、アカウントごとの共有リストを維持する必要はなくなります。 今回のリリースで何が変わるかを、次の表にまとめます。 項目 変更前（アカウント ID による共有） 変更後（AWS RAM による共有） 共有先 個々のアカウント ID 組織、OU、または個々のアカウント アカウント数の上限 1 ドキュメントあたり 1,000 1 リソース共有あたり最大 5,000 プリンシパル メンバー構成の変更 手作業での更新が必要 組織 / OU のメンバー構成と自動で同期 組織外への共有 招待の仕組みなし 組織外のアカウントには AWS RAM の招待が必要 コスト 無料 無料 このブログでは、この共有モデルの仕組みを説明し、エンドツーエンドの例を通して手順を追い、大規模環境でこのパターンを運用するためのベストプラクティスを紹介します。 前提条件 このブログの例をそのまま試すには、次のものが必要です。 少なくとも 2 つのアカウントを持つ AWS Organization（中央アカウントと、OU 内のメンバーアカウント 1 つ） AWS RAM で AWS Organizations とのリソース共有が有効になっていること（初回のみの設定作業です。AWS RAM ユーザーガイドの AWS Organizations 内でリソース共有を有効にする を参照してください） 中央アカウントで SSM ドキュメントと AWS RAM リソース共有を作成するための IAM 権限 SSM ドキュメント（Automation 型および Run Command 型）に関する基本的な知識 AWS RAM および SSM ドキュメントの共有に追加料金はかかりません。 AWS RAM によるドキュメント共有の仕組み 次の図は、SSM ドキュメントが所有元のアカウントから組織内のメンバーアカウントへ渡り、それらのアカウントで実行されるまでの流れを示しています。図のあとに続く番号付きの手順で、各段階を説明します。 図 1. ドキュメントを所有するアカウントが、SSM ドキュメントを組織単位の AWS RAM リソース共有で共有し、組織内のメンバーアカウントが Automation または Run Command でその共有ドキュメントを実行する。 AWS RAM リソース共有を作成する 。ドキュメントを所有するアカウントで、AWS RAM コンソールまたは CLI からリソース共有を作成します。このアカウントは、組織の管理アカウントや委任管理者である必要はありません。単に SSM ドキュメントを作成・所有しているアカウントでかまいません。管理アカウントまたは RAM の委任管理者で行う必要があるのは、前提条件に挙げた「AWS Organizations とのリソース共有の有効化」だけです。 SSM ドキュメントを追加する 。1 つ以上の SSM ドキュメントをリソース共有に追加します。 マネージドアクセス許可 (managed permission) をアタッチする 。AWS RAM は、共有されたドキュメントに対して利用側アカウントが実行できるアクションを定義したマネージドアクセス許可をアタッチします。既定では AWSRAMPermissionSsmDocument がアタッチされます。許可するアクションを絞り込みたい場合は、別のマネージドアクセス許可をアタッチするか、カスタマーマネージドアクセス許可を作成できます。 プリンシパルを選択する 。ドキュメントの共有先として、組織全体、特定の OU、または個々のアカウントを選びます。 アクセスが許可される 。組織内のアカウントであれば、アクセスは即座に有効になります。組織外のアカウントの場合は、利用側がまず AWS RAM の招待を承諾します。 共有されたドキュメントのすべてのバージョンが共有先のアカウントから利用できるため、バージョニングのために追加で設定することはありません。既定では、利用側はドキュメントの既定バージョンを実行し、新しい既定バージョンを公開すればその変更が自動的に反映されます。利用側は、実行時にバージョン番号を指定して特定のバージョンを実行することもできます。 # Create a resource share aws ram create-resource-share \ --name "central-ops-ssm-documents" \ --principals "arn:aws:organizations::111111111111:ou/o-exampleorg/ou-ab12-workloads" \ --resource-arns "arn:aws:ssm:us-east-1:222222222222:document/SSM-Automation-AD-Join" \ --region us-east-1 --permission-arns を省略すると、AWS RAM が既定のマネージドアクセス許可 AWSRAMPermissionSsmDocument を自動でアタッチします。共有されると、メンバーアカウントは完全な ARN を指定してそのドキュメントを検出し、実行できるようになります。 ウォークスルー: 中央管理の Active Directory ドメイン参加ランブックの共有 Windows の EC2 インスタンスを Active Directory (AD) ドメインに参加させるのは、日常的な運用作業です。過去の 2 つのブログ、 Simplifying Active Directory domain join with AWS Systems Manager と Event-driven Active Directory domain join with Amazon EventBridge では、1 つの Automation ランブックで、手動・スケジュール・イベントのいずれかによってインスタンスをドメインに参加（または離脱）させる方法を紹介しました。この例では、そのランブックをさらに一歩進めます。各アカウントにランブックをコピーするのではなく、中央のチームが一度だけ作成し、AWS RAM 経由でメンバーアカウントに共有します。ノードをドメインに参加させる必要のあるアカウントは、共有されたランブックを ARN で指定して実行し、保守すべきランブックは 1 つだけになります。 シナリオ 中央の ID 管理チームが、関連ブログで紹介した AD ドメイン参加ランブックを所有しています。このランブックは、対象インスタンスが Windows であることを確認し、Join か Unjoin の指定に応じて処理を分岐させ、コンピューターをドメインに追加する、または削除する PowerShell を実行し、結果をインスタンスにタグ付けして、再起動または停止します。このチームは以前、このランブックを 300 を超えるアカウント ID と共有し、組織に変更があるたびにリストを更新していました。AWS RAM による共有を使えば、Workloads OU に一度共有するだけで、その OU に現在属しているアカウントと今後追加されるアカウントのすべてがランブックを実行できます。 このランブックは、 ssm-automation-custom-ad-domain-join-unjoin リポジトリ で CloudFormation テンプレートとして公開されています。このテンプレートを中央アカウントにデプロイして、ランブック（この例では SSM-Automation-AD-Join という名前にします）と、AD の認証情報を保持する Secrets Manager のシークレットを作成します。 このランブックは、対象インスタンスにアタッチされたインスタンスプロファイルを使って Secrets Manager から AD の認証情報を読み取ります。共有されたランブックを実行する各メンバーアカウントでは、インスタンスにインスタンスプロファイルを設定しておく必要があります。ドメイン名・参加用アカウント・対象 OU を保持するシークレットへのアクセス権限が必要です。ランブックを共有してもこれらの認証情報は共有されないため、各アカウントが自分の AD シークレットにどう到達するかは別途設計してください。 AWS RAM でのランブックの共有 コンソールの場合: 中央アカウントで AWS RAM コンソールを開きます。 リソース共有を作成 を選びます。 Name に名前を入力します（例: platform-ad-join-docs ）。 リソース でリソースタイプとして SSM Documents を選び、 SSM-Automation-AD-Join ランブックを選択します。 次へ を選びます。 マネージド型アクセス許可 では、既定の AWSRAMPermissionSsmDocument のままにします。利用側アカウントが実行できるアクションを絞り込みたい場合は、別のマネージド型アクセス許可を選びます。 次へ を選びます。 プリンシパルにアクセス権限を付与する で、次の操作を行います。 プリンシパル で 自分の組織内でのみ共有を許可 を選びます。 プリンシパルタイプの選択 で 組織単位 (OU) を選びます。 ドキュメントの共有先となる OU ID を入力します。 追加 を選び、 次へ を選びます。 確認と作成 で内容を確認し、 リソース共有を作成 を選びます。 AWS CLI の場合: # Create a resource share aws ram create-resource-share \ --name "platform-ad-join-docs" \ --resource-arns "arn:aws:ssm:us-east-1:222222222222:document/SSM-Automation-AD-Join" \ --permission-arns "arn:aws:ram::aws:permission/AWSRAMPermissionSsmDocument" \ --principals "arn:aws:organizations::111111111111:ou/o-exampleorg/ou-ab12-workloads" \ --region us-east-1 --permission-arns 引数は省略可能です。省略した場合、AWS RAM が AWSRAMPermissionSsmDocument を自動でアタッチします。 CloudFormation の例: Resources: ADJoinDocumentShare: Type: AWS::RAM::ResourceShare Properties: Name: platform-ad-join-docs AllowExternalPrincipals: false Principals: - arn:aws:organizations::111111111111:ou/o-exampleorg/ou-ab12-workloads ResourceArns: - !Sub arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:document/SSM-Automation-AD-Join CloudFormation を使えば、リソース共有を Infrastructure as Code として管理し、SSM ドキュメントと一緒にバージョン管理できます。 メンバーアカウントからのランブック実行 オンデマンドで実行する場合: Workloads OU 内のいずれかのメンバーアカウントから、ランブックの完全な ARN を指定し、 DomainJoinActivity に Join を設定して、テスト用の Windows インスタンスをドメインに参加させます。 aws ssm start-automation-execution \ --document-name "arn:aws:ssm:us-east-1:222222222222:document/SSM-Automation-AD-Join" \ --parameters "InstanceId=i-0abc123def456,DomainJoinActivity=Join,AutomationAssumeRole=arn:aws:iam::333333333333:role/SSMAutomationRole" \ --region us-east-1 ランブックはインスタンスが Windows であることを確認し、ドメインに参加させ、 ADJoined=Join-complete のタグを付けて、インスタンスを再起動します。 起動時に自動実行する場合: コマンドを手作業で実行せず、インスタンスの起動に合わせてドメイン参加を行えます。共有したランブックを Event-driven Active Directory domain join with Amazon EventBridge のイベント駆動パターンと組み合わせます。メンバーアカウント側で EventBridge ルールを作成し、新しいインスタンスが running 状態になったときに共有ランブックを ARN で起動します。 ベストプラクティス 大規模環境で SSM ドキュメントを共有するための指針（バージョニング、ガバナンスのガードレール、移行を含む）は、AWS Systems Manager ユーザーガイドの Best practices for shared SSM documents を参照してください。 従来の共有方式からの移行 すでに ModifyDocumentPermission でアカウント ID のリストを指定してドキュメントを共有している場合も、最初からやり直す必要はありません。Systems Manager コンソールには移行をガイドする機能があり、既存の共有ドキュメントを AWS RAM リソース共有に変換できます。すでにそのドキュメントを利用しているアカウントのアクセスは中断されません。移行後は共有が組織の状態と同期して保たれ、アカウント ID のリストを保守していたスクリプトは廃止できます。手順の詳細は、AWS Systems Manager ユーザーガイドの Migrate an existing shared document to AWS RAM を参照してください。 クリーンアップ ランブックの共有を停止するには、リソース共有からランブックを削除します。 aws ram disassociate-resource-share \ --resource-share-arn "arn:aws:ram:us-east-1:222222222222:resource-share/abc123" \ --resource-arns "arn:aws:ssm:us-east-1:222222222222:document/SSM-Automation-AD-Join" リソース共有からランブックを削除すると、メンバーアカウントはその ARN を参照する実行を開始できなくなります。共有ランブックを対象にしている利用側アカウントの EventBridge ルールやスケジュールされたタスクは、次回の実行で失敗します。 サンプルの CloudFormation テンプレートからランブックをデプロイした場合は、ランブック、Secrets Manager のシークレット、およびそのスタックが作成した IAM リソースを削除するため、中央アカウントでそのスタックを削除してください。スタック削除時に共有ランブックが参照されていない状態にするため、先にリソース共有を削除してください。CloudFormation コンソールで対象のスタックを選んで 削除 を選ぶか、次のコマンドを実行します（スタック名は実際に使用したものに置き換えてください）。 aws cloudformation delete-stack \ --stack-name SSM-Automation-Demo \ --region us-east-1 まとめ AWS RAM を通じて SSM ドキュメントを共有すれば、アカウントごとの共有リストを管理する運用上の負担がなくなります。このパターンは、初期セットアップ、パッチ適用、インシデント対応、構成を定めた通りに保つ運用など、あらゆる運用ユースケースに適用できます。中央アカウントで一度作成し、AWS RAM で組織または OU に共有し、メンバーアカウントは ARN を指定してそのドキュメントを実行する、という形です。 Simplifying Active Directory domain join with AWS Systems Manager と Event-driven Active Directory domain join with Amazon EventBridge と併せて読むことで、全体像がつながります。ドメイン参加ランブックを一度作成し、AWS RAM で組織全体に共有し、任意のメンバーアカウントから ARN で実行する、という流れです。 ぜひ試してみてください。すでに環境で使っているカスタム SSM ドキュメントや Automation ランブックを 1 つ選び、AWS RAM でサンドボックス用の OU に共有して、メンバーアカウントから完全な ARN を指定して実行してみましょう。そのアカウントにコピーを保持しなくてもドキュメントを実行できることを確認したら、現在チームで共有している残りのドキュメントにも同じパターンを広げてください。 著者について Erik Weber AWS Cloud Operations サービスの Sr. World-wide Specialist Solutions Architect。AWS Systems Manager、AWS Config、AWS CloudTrail、AWS Audit Manager を専門としています。仕事以外では、ハイキング、料理、サイクリングに情熱を注いでいます。 Ali Alzand AWS の Senior Infrastructure Migration & Modernization Specialist Solutions Architect で、エンタープライズのお客様が Microsoft ワークロードを AWS に移行・モダナイズし、運用できるよう支援しています。Infrastructure as Code と、AWS Systems Manager、EC2 Image Builder、AWS CloudFormation を使った大規模な自動化を専門としています。また、Amazon EventBridge と AWS Lambda を使い、応答性が高く疎結合なイベント駆動アーキテクチャを設計しています。仕事以外では、友人とのバーベキューや、街で新しい料理を見つけることを楽しんでいます。 Daniel Liu AWS の Sr. Technical Product Manager で、AWS Systems Manager を専門としています。お客様が大規模なクラウド運用をより簡単かつ安全に自動化できるようにすることに注力しています。仕事以外では、旅行、釣り、テニスを楽しんでいます。 Luis Rodriguez Montilla AWS の Cloud Operations の Senior Specialist Solutions Architect で、クラウドプラットフォームエンジニアリングに 10 年以上携わってきました。AWS の大規模なグローバル企業のお客様が、ガバナンスとオブザーバビリティの課題を大規模な環境で解決できるよう支援しています。仕事以外では旅行とスポーツが好きで、空いた時間は家族や友人と過ごしています。 Yonghui Min Amazon Web Services (AWS) の Software Development Manager で、AWS Systems Manager 内のチームを率いています。スケーラブルなクラウド管理ソリューションの構築に情熱を持ち、お客様が AWS 環境全体で運用ワークフローを簡素化・自動化できるよう支援することに注力しています。 翻訳はソリューションアーキテクトの村田が担当しました。

本ブログは 株式会社アテナ 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 はじめに みなさんこんにちは。AWS の大松と倪 (ニオ) 、アテナ デジタル戦略部の河野拓矢です。 みなさんは普段、生成 AI を何に使っていますか？ 個人で趣味や効率化、あるいは新しい挑戦をするために使ってる人もきっと多いでしょう。いろんなことに使えて楽しいですよね。。。ところが、会社全体で使うとなると話は別です。 業務で生成 AI を活用している方も多いと思います。しかし、生成 AI を全社に広げようとすると、席数で契約したライセンスのうち、ほとんど使わない社員の分まで毎月費用がかかったり、その一方で、よく使う社員ほど利用上限に達してしまう状況が発生し効率的に利用できていなかったりしてませんか？ また、ID 管理やデータの機密情報の扱いなど、さまざまな面で苦慮していませんか？ 本記事では、アテナ様が非エンジニアの社員を中心とした生成 AI の全社利用基盤を Amazon Bedrock を利用して構築した事例を紹介します。 特徴は、社員が普段使っている Microsoft Entra ID のアカウントと連携することで、 ID 管理の運用負担を増やすことなく、ユーザーおよび管理者に負担の少ないアクセス環境を実現した点です。また、AI クライアントの振る舞いも端末管理の仕組みから一括で統制しています。 本ブログでは、どのように設計して課題を解決したのか、そして PoC（概念実証）で実測したコストから何が見えたのかを共有します。 席数契約で生成 AI を全社展開する難しさ アテナ様は、企業とその顧客とのコミュニケーションを支える BPO サービスを提供している企業です。 DM の企画から印刷・封入・発送までを一括で担うメーリングサービスでは年間 1 億 5,000 万通、東京・大阪・名古屋の物流センターを使うロジスティクスサービスでは年間 500 万個を取り扱っています。 書類受付から電話対応までを引き受けるカスタマーサポートサービス、全世界 220 ヵ国以上の国旗を扱うナショナルフラッグサービスも展開し、延べ 1,500 社以上の業務を受託してきました。 同社は 2025 年頃から、生成 AI を日常業務のサポートとして全社で活用してきました。利用者の大半はエンジニアではなく、現場の業務担当者です。Claude の Team プラン（Standard シート、1 席あたり月額 25 ドル）も 100 名弱で契約し、業務に取り入れていました。 転機は 2026 年 6 月頃です。デジタル戦略部の河野様は、Claude Code をデジタル戦略部だけでなく全社で使ってもらいたいと考えました。しかし、Claude と Amazon Bedrock を組み合わせて全社展開するための情報が少なく、パッケージとして提供している企業もほとんどありませんでした。そこで河野様は自ら構築することを決め、コストとセキュリティを含めた提案を経営層に行い、了承を得て開発に着手しました。 全社展開を検討する中で、課題は 4 つに整理されました。 課題 1: 席数契約の固定費と利用の偏り 席数契約では、実際に使っているかどうかにかかわらず契約人数分の費用が毎月確定します。使わない社員の分まで費用がかかる一方で、よく使う社員はトークンの利用上限に達して作業が止まることがありました。Enterprise プランも検討しましたが、1 席あたり月額 20 ドルに加えてトークンの従量課金となるため、使わない社員の固定費が残る構造は変わりません。 課題 2: ID 運用のコスト 利用者の大半が非エンジニアであり、入社・異動・退職のたびに棚卸しも必要になります。そのため本システムのために新たなユーザー管理基盤を用意することは、現実的ではありませんでした。 課題 3: 認証情報の扱い 静的な API キーを配布すれば手軽に動作しますが、キーが端末に長期間残ります。BPO 事業者として顧客の機密情報を扱う立場から、静的な API キーを端末に長期保存させる運用は避けたいと考えていました。 課題 4: 機密情報とデータレジデンシー 業務で機密情報を扱うため、Web 検索や Web ページ取得の機能を経由して情報が外部に出ることは避けたいと考えていました。 入力内容がモデルの学習に使われないこと、そしてデータの処理を日本国内に限定することも要件でした。 一方で、同社には活かせる資産がありました。 Microsoft Entra ID を全社の ID 基盤として運用しており、その管理はインフラ部が担っています。端末管理も、MDM（モバイルデバイス管理）とレジストリ配布によって一元化する運用が確立していました。全社展開を実現するには、「コストを実際の利用に連動させる」「ID と端末の統制を既存の運用にそのまま載せる」「機密情報を外に出さず、処理を日本国内に閉じる」の 3 点を同時に満たす必要がありました。 選択肢を比べて見えた、Amazon Bedrock を選ぶ決め手 アテナ様は Amazon Bedrock に決める前に、複数の選択肢を比較しています。 いずれも技術的には実現できる方法ですが、同社の環境や利用者像と照らし合わせると、それぞれに見送る理由がありました。 検討した選択肢 見送った理由 Claude の Team / Enterprise プランを継続・拡大する 使用量の少ない社員の分も固定費用が発生し、コストの最適化にならない Amazon Elastic Compute Cloud (Amazon EC2) 上に Claude Code を導入し、リモートデスクトップで接続して使う 同社の環境に合わず、コストと運用負担の面で断念 利用者ごとに IAM ユーザーを発行して権限を整理する 同社の環境に合わず、コストと運用負担の面で断念 API を直接呼び出す、または AWS Cloud Development Kit (AWS CDK) などで独自に開発する 利用者は技術者ではないため、操作画面をゼロから作る必要がある ローカル LLM を自社で運用する 求める用途を満たすにはサーバースペックが大きくなりすぎ、現実的でない IAM Identity Center や Organizations と連携した ID・権限管理 個別の ID 管理基盤の運用負担の面で断念 その上で Amazon Bedrock を選んだ理由は 4 つあります。 理由 1 : データの処理を日本国内に閉じられる Amazon Bedrock の日本国内クロスリージョン推論を使うと、推論リクエストは東京リージョンと大阪リージョンにのみルーティングされます（ 日本国内クロスリージョン推論のご紹介 ）。呼び出しログは自社の AWS アカウント内に保管でき、モデルプロバイダーが利用者のプロンプトや出力にアクセスすることもありません（ Amazon Bedrock のデータ保護 ）。 同社が検討した範囲では、既存のアプリケーションを使いながら日本国内に閉じた形で生成 AI を活用できる環境は Amazon Bedrock だけでした。データの処理が国内にとどまることは、BPO 事業者として顧客と契約を結ぶうえでも強みになります。 理由 2: 既存のアプリケーションをそのまま使える Claude Desktop の接続先を Amazon Bedrock に向けるだけで、利用者は使い慣れた画面のまま業務を続けられます。非エンジニアが使う前提では、独自の画面を開発・保守しなくてよい点は大きな利点でした。 理由 3: 既存の ID 基盤をそのまま使える Entra ID と連携できるため、入社・異動・退職といった社員のライフサイクルの管理を既存の ID 運用に一元化できます。 理由 4: 使った分だけの従量課金である 使わない社員の費用は発生しません。よく使う社員にどこまで使ってもらうかは、自社で上限やモデルの選び方を設計して決められます。 設計の参考にしたのは、AWS のブログ記事「 Claude Code on Amazon Bedrock のデプロイパターンとベストプラクティス 」です。同記事では認証方式を比較したうえで、本番環境向けには ID プロバイダー (IdP) と IAM を直接連携させる方式が推奨されています。 アテナ様はこの比較をもとに自社の IdP を直接連携させるパターンを選択しました。実装には、同記事で紹介されている Guidance for Claude Code with Amazon Bedrock を参考にしています。 Claude Desktop × Amazon Bedrock の全体像 アテナ様が構築したのは、Claude Desktop のバックエンドを Amazon Bedrock に向け、認証を Entra ID の OIDC フェデレーションで通す構成です。利用者から見れば普段どおりアプリケーションを起動して Entra ID にサインインするだけですが、その裏側では毎回、有効期限付きの一時的な認証情報が発行されています。 図: Claude Desktop × Amazon Bedrock の構成 認証とモデル呼び出しの流れは次のとおりです。 Claude Desktop が、MDM で配布されたレジストリ設定に従ってプロファイルを読み込み、 credential_process のヘルパーを実行する ヘルパーが Entra ID に対して OIDC でサインインする 取得した ID トークンを AWS Security Token Service (AWS STS) に渡す AssumeRoleWithWebIdentity によって、フェデレーション用の IAM ロール（例: FederatedRole ）の一時的な認証情報（有効期限 12 時間）を取得する その認証情報で、日本国内クロスリージョン推論のプロファイルを経由して Claude のモデルを呼び出す 呼び出しログを Amazon CloudWatch Logs と Amazon Simple Storage Service (Amazon S3) に保存し、 AWS Key Management Service (AWS KMS) のキーで暗号化する この構成のポイントは、端末に静的な API キーも、長期間有効な認証情報も置かない点にあります。端末側にあるのは「どこにサインインしに行くか」という設定情報だけです。 IAM ロールの権限は、日本国内の推論プロファイルを経由したモデル呼び出しに絞り込んでいます。IAM ロールの有効期限は 12 時間で、Entra ID 側のセッション保持時間（12〜24 時間程度）と整合するように設定しています。退職者の Entra ID アカウントを無効化すれば、発行済みの認証情報が有効期限を迎えた時点で Amazon Bedrock への到達経路が閉じ、AWS 側で個別の後処理をする必要もありません。 利用させる機能も絞り込んでいます。許可しているのはチャットとコーディング支援（Claude Code）で、それ以外の機能は意図的に無効化しています。Web 検索と Web ページ取得は禁止し、特定業務の自動化に必要な Playwright MCP だけを許可リスト方式で使えるようにしました。Claude Code は作業の途中で Web 検索を使うことがあるため、機密情報が外部に持ち出される経路をあらかじめ塞いでいます。 統制の「置き場所」を決めるまでの 2 週間 河野様は 2026 年 6 月の本格着手から 2～3 か月で構成を完成させました。設計と開発は河野様が担当し、社内のセキュリティ管理者が設計内容をレビューして抜けの有無を確認する体制で進めました。その中で最も時間を要したのは、実装そのものではなく、「どの設定を、どこで統制するか」の見極めと、その検証の繰り返しでした。 生成 AI の全社展開では、統制できる場所が複数に分かれます。ID 基盤である Entra ID、AWS、端末のレジストリ、そしてアプリケーション自体の設定です。しかも、Amazon Bedrock 側では制御できても Claude 側では制御できない、あるいはその逆といった違いがあり、それらを横並びで比較した資料は見当たりませんでした。 そのため、設計した統制内容をセキュリティ管理者がレビューし、指摘事項に基づいて河野様がレジストリや設定ファイルを調整し、モックを作って挙動を 1 つずつ確かめ、再度レビューに回す、というサイクルを繰り返しました。利用者の作業を妨げない可用性と、情報を外に出さない機密性の両立点を細かく詰めていく作業であり、この設計に 2 週間程度を費やしています。前述のガイダンスに同梱されているものを利用することで、一から認証の仕組みを作らずに済み、多くの時間をこの統制の検討に充てることができました。 最終的に、次のように整理しました。 統制したいこと 統制した場所 アテナ様での設定 誰が使えるか(入社・異動・退職) Entra ID 既存の ID 運用をそのまま利用(管理はインフラ部) AWS 上で何ができるか IAM ロールと AWS STS 有効期限 12 時間の一時的な認証情報。日本国内の推論プロファイル経由の呼び出しのみ許可 端末の接続先と使える機能 端末のレジストリ(MDM で配布) 接続先(Amazon Bedrock、東京リージョン)の固定、許可するモデル、トークン使用量の上限、Web 検索・Web ページ取得の禁止、Playwright MCP の許可 操作時の確認表示などの細かな挙動 アプリケーションの管理設定ファイル 操作の許可・拒否を確認する表示の出方を調整 記録・監視・コスト AWS の各サービス 呼び出しログの保管と暗号化、予算超過の通知、脅威検知、セキュリティ状況の可視化 端末側の統制を MDM に寄せた理由について、河野様はこう説明しています。 「手作業で設定すると運用負担がかかり、分かる人にしかできない。MDM ならこのレジストリキーを入れればいいと明確なので、管理を一元化できてシンプルで綺麗な構成になった」。(参考: Configuration reference – Anthropic ) ID 基盤・端末管理・AWS 権限という 3 つのレイヤーを、それぞれが得意な場所で統制するという役割分担です。AWS 側をどれだけ堅牢に作っても、アクセス元の端末が統制されていなければリスクは残ります。端末側の統制まで踏み込んでいる点が、この構成の特徴です。 全社への配布方法も、企業ごとの事情に合わせて組み合わせられるようにしました。ディレクトリの権限を厳格に管理している企業であれば、MDM でそのまま配布できます。一方、アテナ様の環境では MDM による配布に時間がかかるため、初回のセットアップは実行ファイルやバッチにまとめ、各自に実行してもらう方法も用意しました。 初回セットアップ後のモデルの更新などは、レジストリキー 1 行程度の変更を MDM で配布するだけで済みます。この組み合わせにより、利用者の作業を最小限に抑えたまま、4 名のスモールスタートから 28 名の PoC、そして全社へと段階的に広げられる仕組みになっています。 ユーザー別のコスト把握では、途中で方針転換がありました。当初は Amazon Bedrock 全体にコスト配分タグを付ければユーザー別の内訳が取れると考えていましたが、実際には取得できず、モデル別の設定が必要だと分かりました。IAM プリンシパル単位のコスト配分も検討しましたが、同社の環境の構成上、利用できませんでした。 そこで、Amazon S3 に保存した呼び出しログを集計し、利用者別・モデル別の費用を算出する方法を取っています。後述する PoC のコスト実測も、この方法で行いました。 セキュリティとコストの統制も組み込んでいます。呼び出しログは CloudWatch Logs と Amazon S3 の両方で 90 日間保持し、いずれも AWS KMS のカスタマーマネージドキーで暗号化しています（キーの自動ローテーションは 365 日）。 AWS Budgets では、全体の利用金額があらかじめ決めたしきい値を超えるとメールで通知されるようにしました。IAM ロール、OIDC プロバイダー、ログ配信、KMS キー、Budgets の設定は AWS CloudFormation のスタックとして管理しており、構成をコードから再現できます。脅威検知には、既存のワークロード向けに有効化していた Amazon GuardDuty を流用しました。さらに、AWS 環境全体のセキュリティ状況を見通すために AWS Security Hub を追加しています。 実測で見えた「使う人に投資する」という考え方 アテナ様は 2026 年 9 月 7 日に 28 台へ配布し、PoC を開始しました。コストについては当初の見込みとは異なる、しかし全社展開の判断に役立つデータが得られました。業務面と利用者の意識面では、想定を超える変化も起きています。 総額よりも「利用の偏り」が見えた 2026 年 9 月 7 日から 9 月 17 日までの 9 営業日、社内の有志 22 名に Amazon Bedrock 経由の Claude Desktop を使ってもらい、費用を実測しました。費用は、自社アカウントの Amazon S3 に保存された呼び出しログを全件集計して算出しています。 比較対象は Claude の Team プランの席単価（月額 25 ドル）です。 ※ 月額換算は「実績 ÷ 9 営業日 × 20 営業日」で算出した推定値です。 実作業の回数は利用者の操作に伴う呼び出しの数で、クライアントが自動で発行する接続確認などの呼び出しは除外しています。 結果は、「従量課金にすればコストが下がる」という当初の見込みとは異なるものでした。22 名の月額換算の合計は Team プラン 22 席分の約 3.9 倍となり、22 名のうち 12 名は席単価を上回っています。参加者の中央値でも、席単価の約 1.7 倍でした。 ただし、今回の参加者は利用意欲の高い有志が中心です。また、Team プランには利用上限がある一方、今回の PoC では 1 人あたり 300 万トークンの上限の範囲内で自由に使ってもらっており、単純な比較はできません。従来のプランでは、よく使う社員ほど利用上限に達して作業が止まることがありました。 むしろ、はっきり見えたのは利用の偏りです。1 稼働日あたりの費用は、最も多い利用者と最も少ない利用者で約 51 倍の開きがありました。上位 2 名だけで、全体の費用の約半分を占めています。 費用を分けた要因は、利用回数だけではありません。上位モデル（Claude Opus）の利用割合が 99% の利用者は 1 回あたり約 0.25 ドルだったのに対し、実作業の回数が最も多かった利用者（1,609 回）は Claude Opus の利用割合が 2% で、1 回あたり約 0.07 ドルにとどまりました。モデルの選び方によって、1 回あたりの費用に 3 倍以上の差が出ています。 アテナ様はこの結果を、総額の削減よりも、利用実態に応じたコスト配分を判断する材料として捉えています。Amazon Bedrock では利用者別・モデル別の費用を実測できるため、誰にどのモデルとどの上限を割り当てるかを、データに基づいて決められます。 河野様は、従量課金になったことで使う人に正しく投資できるようになった点を強みに挙げています。 全社約 200 名に展開すれば利用の少ない社員の割合が増えるため、全体の平均では Team プランの席単価を下回る可能性もあると同社は見ています。ただし、これは PoC から直接導いた結果ではなく、利用の少ない社員が多数を占めるという前提に基づく仮説です。 なお、日本国内クロスリージョン推論は、グローバルのクロスリージョン推論と比べて単価が 10% 高く設定されています（ 日本国内クロスリージョン推論の料金 ）。同社はこの差額を、データの処理を国内に閉じるための対価と位置づけています。 業務時間の半分程度を削減し、提案の作り方も変わった 業務面の効果も表れています。河野様の体感では、業務時間の半分程度を削減でき、生まれた時間をレガシーシステムの刷新に充てられるようになりました。 提案や見積もりのスピードも上がっています。社内資料の約 9 割は AI を使って作成されるようになり、提案資料や社内説明資料、分析に活用されています。 今では顧客ごとに分析したうえで、より最適な提案内容を組み立てられるようになりました。 使い心地はほぼそのまま、顧客への説明はむしろ簡単になった 利用者の使い心地は、従来のブラウザ版の Claude.ai とほとんど変わりませんでした。導入当初は、操作の許可・拒否を確認する表示が従来より多いと感じる声がありましたが、アプリケーションの管理設定ファイルを調整して解消しています。 自分でフォルダを作成して AI に読み込ませられる点は便利だと好評で、より快適に使えるようになったという声も上がっています。ブラウザ版で使っていたプロジェクト機能の役割は社内のファイルサーバーがほぼ置き換え、従来の業務の流れに近い形で使えるため、利用者は戸惑わずに移行できました。 また、利用するリージョンを日本国内に限定しているため、同社の顧客に対して AI の利用を説明しやすくなったという声もあります。 非エンジニアが自ら AI の振る舞いを設計し始めた 予想外だったのは、ブラウザ版 から Claude Desktop に変更することで、カスタマイズの余地が増え、利用者が Claude について自ら学ぶようになったことです。 これまで、AI への指示や前提をまとめておく CLAUDE.md のような設定ファイルを使っていたのは開発者だけで、説明してもなかなか響きませんでした。ところがチャットとコーディング支援の機能を公開すると、4 名のスモールスタートの段階から、非エンジニアの社員が自分のファイルサーバーに CLAUDE.md を置き、フォルダ構成を工夫しながら AI の振る舞いを自ら作り始めました。「毎回同じ出力をさせるにはどうすればよいか」といった相談も増え、AI の仕組みを理解しようとするやり取りが社内で活発になっています。Playwright MCP を公開した際も、ブラウザ自動化の意味が分からなかった社員が各自で使い方を工夫し始め、AI リテラシーを積み上げるきっかけになりました。 組織の文化にも変化が表れています。以前は知っている人に聞いて作業を進めていましたが、ナレッジを AI に蓄積し、まず AI に確認してから作業を進める文化が生まれつつあります。特に営業部門は中間層が少なく若手が多いため、業務を回すために AI を活用する場面が増えています。以前全社に公開していた SaaS 型の AI サービスでは、利用者から要望が上がっても「自社で作っているものではないので対応できない」で終わっていました。 今回の構成はカスタマイズの自由度が高く、利用者の意見をデジタル戦略部が反映できるため、利用者との一体感や、受け入れられているという安心感にもつながっています。 推進責任者と経営層の声 推進責任者の河野様は、次のように振り返ります。 本環境の設計・開発は私が担当しましたが、社内調整や PoC にご協力いただいた方々がいなければ、形にすることはできなかったと思います。 おかげさまで、社員が安心して AI を活用できる環境を整えることができ、心より嬉しく思っております。 AWS 大松様、倪 (ニオ) 様をはじめ、ご協力いただいたすべての方に感謝申し上げます。 経営層からは、次のコメントが寄せられています。 人材の確保が難しい昨今、業務での AI 活用は必須だと考えています。 一方で、BPO 企業である当社にとって、セキュリティは何よりも優先すべきものです。 その両立を可能にするのが、この Amazon Bedrock の環境です。 今後は AI を組み込んだ業務設計を進め、セキュリティを最優先に構築したこの環境を基盤として、お客様へのサービス展開を広げていきます。 (左から、AWS 大松、アテナ河野様、倪 (ニオ)) 今後の展開、全社へ 向けた利用ルールの整備 全社への配布に向けて、PoC の結果をもとに 2 つの対策を進めています。 1 つ目は、費用が高くなる利用の抑制です。 費用の要因がモデルの選び方と利用回数の両方にあることから、トークン使用量の上限に加えて、既定のモデルを Claude Sonnet とし、Claude Opus は必要なときだけ許可するといった利用ルールを検討しています。 2 つ目は、PoC 期間中に一度も利用しなかった社員へのフォローです。 使い方やインストール方法が分からないことが原因と推測されるため、ハンズオン形式で操作を体験し、実際の業務での使い方をイメージできる機会を設ける予定です。 長期的には、この環境を基盤に AI を組み込んだ業務設計を進め、顧客向けのサービス展開を広げていく方針です。 まとめ 本記事では、アテナ様が Amazon Bedrock と Microsoft Entra ID を組み合わせ、非エンジニアの社員を中心とした生成 AI の全社利用基盤を構築した事例を紹介しました。 ポイントは 3 つです。 OIDC ID プロバイダーと AWS STS を使えば、端末に静的な API キーを置かないフェデレーション構成を組めます。 統制できる場所は ID 基盤、AWS、端末のレジストリ、アプリケーションの設定に分かれるため、「何をどこで統制するか」を先に整理することが設計の鍵になります。AWS 側をどれだけ堅牢に作っても、端末が統制されていなければリスクは残ります。 従量課金の価値は総額の削減だけではありません。利用者別・モデル別の費用が見えることで、使う人に正しく投資する判断ができるようになります。 河野様は、この構成は多くの企業にとって参考になると考えており、その条件として 3 点を挙げています。ID 基盤をすでに使っていること、MDM で端末を一括管理していること、そして生成 AI を使う人に正しく投資する方針を持つことです。また、機密情報を扱う企業にとっては、この水準の構成でなければ全社展開そのものが難しいとも指摘しています。 生成 AI の全社展開というと、「どのサービスを使うか」から検討を始めがちです。しかし河野様は、本当に問われるのは「既存の ID 運用と端末管理にどう載せ、どう統制していくか」だと話します。同じ課題を抱える企業にとって、本記事がその検討の一助となれば幸いです。 より詳しく知りたい方は、以下のリンクもご参照ください。 Claude Code on Amazon Bedrock のデプロイパターンとベストプラクティス Guidance for Claude Code with Amazon Bedrock（GitHub） Amazon Bedrock で日本国内に閉じた Anthropic Claude 4.5 の推論が可能に！日本国内クロスリージョン推論のご紹介 Amazon Bedrock の詳細 AWS Identity and Access Management (IAM) の詳細 AWS Budgets の詳細 AWS Security Hub の詳細 アテナ様の公式サイト 著者 大松 宏之 テクニカルソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。好きなサービスは、AWS Direct Connect と AWS Client VPN です。 倪 木強 (ニオ　ミッチェル) アカウントマネージャーとして、日本の中堅企業のお客様の IT 活用をビジネスの成果につなげるご支援をしています。好きなサービスは Amazon Simple Storage Service (Amazon S3) で、データをどこに置くかを決めることがそのまま活用の設計になる点に惹かれています。 アテナ デジタル戦略部 河野拓矢 社内外のシステムについて提案、開発から保守まで担当させて頂いております。 好きな動物はあざらしです。 好きなサービスはAWS CloudFormationです。  

by Koshiro Fujikawa | on 1 10月 2026 | in AWS Payment Cryptography, Financial Services, Security, Identity, & Compliance, General 本ブログはイージャイズ株式会社（旧ルミーズ株式会社）とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの藤川です。 キャッシュレス決済の普及にともない、決済端末を安全に運用するための「鍵管理」の重要性がこれまで以上に高まっています。カード情報を扱う事業者にとって、暗号鍵をいかに安全に、かつ効率的に管理するかは、セキュリティとコストの両面で大きな経営課題となっています。 決済ソリューションを幅広く展開する イージャイズ株式会社 （以下、イージャイズ様）は、新しい決済端末「salo-02」と次世代決済ネットワーク基盤「aegise2.0」の開発にあたり、鍵管理の中核として AWS Payment Cryptography （以下、APC）を採用されました。本記事では、リモートキーインジェクション（RKI）を題材に、APC 採用に至った経緯と選定理由、そして得られた効果についてご紹介します。本記事は、2026 年 7 月に開催されたカードセキュリティフォーラムにおける、イージャイズ株式会社 開発部 部長 大池 絢輔 氏のご講演内容をもとに構成しています。 お客様の状況と検証に至る経緯 イージャイズ様は、長野県小諸市に本社を構え、2001年以来約 25 年にわたり決済サービスを提供してきた PSP（Payment Service Provider）です。EC 決済からスタートし、現在では対面決済、コールセンター向けの MOTO（Mail Order / Telephone Order）決済ソリューションなど、幅広い決済シーンに対応しています。「決済にプラス α の付加価値をつけて、今までになかったソリューションを形にする “Payment SIer”」を掲げ、全国 20,000 社以上への導入実績と、PCI P2PE 認定をはじめとする高いセキュリティへの取り組みを強みとしています。 こうした事業を支えてきたのが、自動精算機や自動販売機向けのマルチ決済端末「salo」シリーズです。しかし、先代端末である「salo-01」の運用には、鍵管理の面で以下の課題がありました。 salo-01 では、暗号鍵を端末に注入する方式が「ダイレクトキーインジェクション」のみに限られていました。これは、端末を 1 台ずつ HSM（Hardware Security Module）にケーブルで直接つないで鍵を注入する方式です。この運用には、次のような負担が伴っていました。 ファシリティコスト ：キーインジェクションを行う専用の設備・部屋が必要であり、その要件と維持コストが重い 運用コスト ：鍵の初期設定・注入はデュアルコントロール（複数人での相互牽制）が前提となるため、作業のたびに複数名の稼働が必要 再注入の非効率 ：出荷後の端末が不具合や調査でセンドバック（返送）されるたびに、鍵の再注入作業が発生する。初期入荷時のようにまとまった台数をまとめて処理できず、不定期に返ってくる 1 台のためにも複数名で作業を強いられていた 大池氏は当時をこう振り返ります。「特に、既存で動いている端末が返ってきた際の鍵の再注入は一番重い作業でした。数百台・数千台をまとめて注入するならまだしも、不定期に返ってくる 1 台のために毎回デュアルコントロールで人を集めなければならない。効率の悪い作業を強いられていました」 ソリューション／構成 これらの課題を解決するため、イージャイズ様は後継機「salo-02」の開発において、鍵注入方式を「リモートキーインジェクション（RKI）」を必須要件とする方針を打ち出しました。RKI は、端末を一か所に集めることなく、遠隔で安全に鍵を注入できる仕組みです。 この RKI を実現する基盤として、イージャイズ様は salo-02 の開発と並行して進めていた次世代決済ネットワーク基盤「aegise2.0」を活用しました。aegise2.0 は、決済に必要な機能（ゲートウェイ、加盟店管理など）をモジュール化し、オフライン／オンラインを問わず必要なだけ組み合わせて利用できるプラットフォームです。その機能の一つとして構築した TMS（Terminal Management System：ターミナルマネジメントシステム）の中に、RKI の機能を組み込みました。 そして、この新たに構築した鍵管理環境の中核に採用されたのが、AWS Payment Cryptography（APC）です。APC は、決済業界特有の暗号処理と鍵管理をフルマネージドで提供するサービスで、事業者が物理 HSM を自前で保有・運用する必要をなくします。 RKI の流れと構成 salo-02 における RKI は、以下のシンプルな流れで実現されています。 鍵の要求 ：決済端末 salo-02 が端末内で秘密鍵を生成し、CSR（証明書署名要求）を作成。クライアント証明書で接続し、CSR を添付して鍵をリクエストする。この入口には AWS IoT Core を利用しており、TMS の機能（アプリケーション／ファームウェアの配布など）と共通の基盤として活用している 端末の検証 ：鍵発行エンジンが Private CA を用いて端末の正当性を検証する 鍵の導出とラップ ：APC が BDK（Base Derivation Key）から IPEK（Initial PIN Encryption Key）を導出し、①で受け取った端末の公開鍵を使って TR-34 形式でラップする。鍵は平文のまま暗号境界の外に出ない 鍵の配送 ：TR-34 でラップ済みの IPEK を、IoT Core 経由で端末へ配送する 端末内での展開 ：端末内で鍵を展開し、KCV（Key Check Value）で自己検証したうえで DUKPT 鍵を有効化する APC を選定した理由 大池氏は、数ある選択肢の中から APC を選定した理由を、以下の 3 つの観点から説明しています。 理由① セキュリティ APC は、セキュリティ面で以下の準拠・認定状況を備えています。 PCI DSS の準拠対象サービス  PCI PIN・PCI 3DS の準拠対象サービス すべての暗号処理を、PCI PTS HSM 基準に準拠したペイメント HSM 上で実行 PCI P2PE の準拠対象サービスであり、APC 自体が Decryption Management コンポーネント認定を取得 大池氏は、イージャイズ様にとって特に大きかったのは 4 番目の認定だったと語ります。「弊社は複数の P2PE ソリューションを持っており、それらの鍵を APC で管理するにあたっては、P2PE の Decryption Management コンポーネント認定が必須条件でした。この認定を取得しているクラウド型 HSM はほぼ存在しない状況でしたので、APC がこの認定を取得されているというのは非常に嬉しいことでした」 「P2PE の Decryption Management は非常にハイレベルなセキュリティ認定です。ここまでの認定は不要という事業者様も多いかもしれませんが、それだけハイレベルな環境で鍵が管理されているということは、一つの安心材料になるのではないでしょうか」（大池氏） 理由② 性能・拡張性・運用 もともとオンプレミスの HSM で構築・運用していたため、クラウド化によって性能が低下するのではないかという懸念がありました。しかし、実際に検証を進める中で、以下の点で実運用に十分な水準であることが確認されました。 処理性能：物理 HSM と遜色ない処理性能を確認。復号処理は数ミリ秒から十数ミリ秒程度で完了し、条件によっては APC の方が速いというテスト結果も得られた 拡張性・可用性：マネージドサービスであるため、台数や容量を自前で抱える必要がない。端末数や取引量の増加に対して、基盤側が自動的にスケールする 運用負荷の軽減：HSM の物理管理、鍵セレモニー、DR（災害復旧）構成を自前で持たなくてよい。オンプレミスで複数台の HSM を運用する場合、各 HSM に同じ鍵を入れ、そのバックアップを厳格な手順のもとデュアルコントロールで管理する必要があり、運用が非常に煩雑になる。APC であれば、基本的に APC に鍵を置いておくだけでよく、鍵管理の運用が大幅に軽減される 理由③ 既存鍵の移管性 salo-02 はすべて新規の鍵で運用するため、APC で直接鍵を作成すれば済みます。しかし、イージャイズ様は「既存のオンプレミス HSM で動いている鍵の移管先にもなれること」も選定条件としていました。 APC は、TR-34 / TR-31 でラップした鍵をインポート／エクスポートする機能を標準で備えています。この形式で暗号化したキーブロックをインポートすればよく、将来的には他サービスの既存鍵も APC に集約できる見込みです。 なお、鍵をアルゴリズムで安全に分割してマニュアル入力する「キーコンポーネント」方式についても、現在は Physical Key Exchange として APC が正式にサポートしています。紙のキーコンポーネントを PCI PIN / P2PE の物理・論理セキュリティ要件を満たす AWS の施設に送付すると、訓練を受けた AWS のキーカストディアンがオフライン HSM を用いた鍵セレモニーを実施し、電子形式に変換して APC へ安全に取り込むことができます。大池氏は「ここで足踏みをされていた事業者様もかなり多かったのではないかと思いますので、そのハードルがぐっと下がったのは非常に朗報だと感じています」と語ります。 導入効果 APC を鍵管理の中核に据えたことで、イージャイズ様は以下のような効果を得られました。 鍵の「注入」と「復号」を一つの APC で完結：APC が保持する 1 つの BDK（Base Derivation Key：大元の鍵）から、鍵注入（RKI）フェーズでは IPEK を導出して端末へ配送し、取引（復号）フェーズでは同じ BDK から取引鍵を導出してカードデータを復号する。注入も復号も、この 1 つの鍵に由来する 鍵管理の一元化：従来はインジェクション用と復号用で環境（部屋・HSM）を分け、それぞれに同じ鍵を入れて管理する煩雑な運用が必要だった。APC に BDK を 1 つ置いておけば、その鍵で注入も復号も行えるため、鍵管理を完全に一元化できる。鍵基盤を二重に持つ必要がなく、複数箇所で鍵を共有する必要もない バックアップ運用の削減：キーコンポーネントを用いたバックアップ運用がほぼ不要となり、「APC で 1 回鍵を作れば、それで完結する」という運用に倒せるようになった ファシリティ・運用コストの削減：ダイレクトキーインジェクションで必要だった専用設備や、センドバック時の非効率な再注入作業から解放された 今後の展望 大池氏は、今回構築した RKI と復号の仕組みが salo-02 専用のものではないことを強調します。 「この仕組みは、aegise2.0 の TMS（RKI ／復号 + APC）の一機能として構築しているため、salo-02 以外の端末にも接続できる機構になっています。自社・他社を問わず、複数の決済端末が同じ TMS に接続可能です」 これにより、決済端末のメーカーが自らキーインジェクション設備を用意する、あるいはメーカーに委託するといった従来の選択肢に加えて、イージャイズ様のようなサービスを利用する、または事業者自身で組み立てるという選択肢が現実的になりました。 「鍵管理・キーインジェクションのハードルが従来よりもだいぶ下がりました。APC の登場によって、決済に関わる事業者が非常に多くの選択肢を持てるようになったのではないかと考えています」（大池氏） イージャイズ様は今後も、決済セキュリティと鍵管理の分野で培ってきた知見を活かし、AWS のマネージドサービスを活用しながら、より安全で柔軟な決済ネットワーク基盤の提供を目指していきます。 AWS Payment Cryptography は、決済処理に必要な暗号処理と鍵管理をクラウド上でフルマネージドに提供するサービスです。詳しくは AWS Payment Cryptography の製品ページ をご覧ください。 このブログの著者 中島 智広（Nakashima, Tomohiro）シニアセキュリティソリューションアーキテクト 藤川 高志朗（Koshiro, Fujikawa）アカウントマネージャー

本記事は 2025 年 10 月 21 日 に公開された「 Overview and best practices of multithreaded replication in Amazon RDS for MySQL, Amazon RDS for MariaDB, and Amazon Aurora MySQL 」を翻訳したものです。 マルチスレッドレプリケーション (MTR) は、MySQL のバイナリログレプリケーション性能を向上させる機能です。 Amazon Aurora MySQL-Compatible Edition 、 Amazon Relational Database Service (Amazon RDS) for MySQL 、Amazon RDS for MariaDB など、高スループットのデータベースで特に効果を発揮します。標準的なレプリケーション構成はもちろん、 Amazon RDS Blue/Green デプロイ のような最新の運用手法でも活用でき、ダウンタイムを抑えたデータベースのアップグレードや変更に役立ちます。 本記事はシリーズの第 1 回として、パラレルレプリケーション技術を中心に MySQL レプリケーションを詳しく解説します。まず MySQL レプリケーションの仕組みを概観し、マルチスレッドレプリケーションの詳細を解説します。そして、主要な設定オプションと最適化のベストプラクティスを紹介します。 第 2 回 では、マルチスレッドレプリケーションの監視について取り上げます。 MySQL バイナリログレプリケーションの概要 次の図は、シングルスレッドレプリケーションにおける MySQL レプリケーションのアーキテクチャを示しています。 ソースとレプリカの各コンポーネントを詳しく見ていきましょう。 ソース側 バイナリログが有効な状態で DML (Data Manipulation Language)、DCL (Data Control Language)、DDL (Data Definition Language) がソースで実行されコミットされると、MySQL はステートメントまたはトランザクションをイベントとしてバイナリログファイルに永続化します。永続化されたイベントは、レプリカがダンプスレッドを通じて取得します。 注: Amazon RDS for MySQL では、 バックアップ保持期間がゼロ以外に設定 されていればバイナリログはデフォルトで有効です。一方、Aurora MySQL では バイナリログを明示的に有効化 する必要があります。 バイナリログダンプスレッド – レプリカが接続すると、ソースデータベースはレプリカごとにバイナリログの内容を送信するスレッドを作成します。ソースで SHOW PROCESSLIST を実行すると、Binlog Dump スレッドとして確認できます。 レプリカ側 IO スレッド – レプリカは IO (レシーバー) スレッドを作成してソースに接続し、バイナリログの更新を取得します。IO スレッドはソースの Binlog Dump スレッドから送信された更新を読み取り、レプリカの リレーログ を構成するローカルファイルにコピーします。SHOW REPLICA STATUS の出力では Replica_IO_running として表示されます。シングルスレッドレプリケーションでも MTR でも IO スレッドは 1 つだけで、ボトルネックになることはほとんどありません。 SQL (アプライヤー) スレッド – リレーログを読み取り、レプリカのデータベースに適用します (通常のクライアントと同様)。シングルスレッドレプリケーション (MySQL 8.0.27 以前のデフォルト) では SQL スレッドは 1 つだけです。MTR では複数の SQL スレッドが動作します。 レプリカでバイナリログが有効な場合、SQLスレッドはリレーログのトランザクションを適用してコミットしますが、このときレプリカ自身のバイナリログへの書き込みも発生します。バイナリログの負荷によりレプリケーション遅延が発生する可能性があります。 MTR の概要 MTR を有効にする ( slave_parallel_workers または replica_parallel_workers を 1 より大きい値に設定する) と、SQL スレッドはコーディネータースレッドと複数のワーカースレッドの 2 種類に分かれます。コーディネータースレッドはリレーログからイベントを読み取り、イベントの依存関係を分析して、ワーカースレッドに並列実行を割り当てます。イベントの依存関係はソースインスタンス側で追跡され、データの整合性を保ちつつレプリカ上で安全に並列実行できるイベントが判断されます。ワーカー (アプライヤー) スレッドはレプリケーションの実行部分を担い、レプリカ上でトランザクションを再生します。コーディネーターとワーカーに分離することで、レプリケーションイベントの並列処理を効率化できます。 次の例では、パラメータ replica_parallel_workers を 4 に設定しています。リードレプリカで Select * from information_schema.processlist where User='system user'; を実行すると、合計 6 つのスレッドが出力されます。IO スレッド 1 つ、コーディネータースレッド 1 つ、ワーカースレッド 4 つです。 IO_THREAD: レプリケーションチャネルごとに 1 つ (以下の出力では Id: 419) SQL スレッド: コーディネータースレッド: レプリケーションチャネルごとに 1 つ (以下の出力では Id: 420) ワーカースレッド: チャネルごとに replica_parallel_workers で指定した数 (以下の出力では Id: 421-424) select * from information_schema.processlist where User='system user'; +------+-----------------+--------------------+------+---------+--------+----------------------------------------------------------+-----------------------+ | Id | User | Host | db | Command | Time | State | Info | +------+-----------------+--------------------+------+---------+--------+----------------------------------------------------------+-----------------------+ | 419 | system user | connecting host | NULL | Connect | 494497 | Waiting for source to send event | NULL | | 420 | system user | | NULL | Query | 9 | Replica has read all relay log; waiting for more updates | NULL | | 421 | system user | | NULL | Query | 9 | Waiting for an event from Coordinator | NULL | | 422 | system user | | NULL | Query | 494925 | Waiting for an event from Coordinator | NULL | | 423 | system user | | NULL | Query | 494925 | Waiting for an event from Coordinator | NULL | | 424 | system user | | NULL | Query | 494925 | Waiting for an event from Coordinator | NULL | +------+-----------------+--------------------+------+---------+--------+----------------------------------------------------------+-----------------------+ MTR の仕組み MTR はレプリケーション依存関係の追跡に基づいており、データの整合性を維持しながらレプリカサーバー上でトランザクションを安全に並列実行できるかを判断します。MySQL では依存関係の追跡に COMMIT ORDER と WRITESET という 2 つの主要な方式を提供しています。 COMMIT_ORDER 依存関係追跡は、ソースサーバーでの グループコミット のタイミングに基づきます。ソースが書き込む依存関係情報は論理タイムスタンプとしてバイナリログイベントに記録されます。各トランザクションには依存関係の判断に使う 2 つの論理タイムスタンプがあります。 sequence_number – 各バイナリログの最初のトランザクションは 1、2 番目は 2、と続きます。バイナリログファイルごとに 1 から振り直されます。 last_committed – 現在のトランザクションと競合する、直近にコミットされたトランザクションの sequence_number を指します。この値は常に sequence_number より小さくなります。 次のコードブロックは、 mysqlbinlog でデコードしたバイナリログの簡略化されたスニペットです。上の例では、シーケンス番号 2347、2348、2349、2351 のトランザクションはレプリカ上で並列実行が可能です。いずれも last committed タイムスタンプがこれらより前のトランザクションを指しているためです。シーケンス番号 2350 のトランザクションは 2348 に依存しているため、2347、2348、2349、2351 と並列にレプリケートすることはできません。 #308741 15:23:45... last committed=2345 sequence number=2346 #308741 15:23:45... last committed=2346 sequence number=2347 #308741 15:23:45... last committed=2346 sequence number=2348 #308741 15:23:45... last committed=2346 sequence number=2349 #308741 15:23:45... last committed=2348 sequence number=2350 #308741 15:23:45... last committed=2345 sequence number=2351 COMMIT_ORDER は、ソースサーバーの同時実行ワークロードが多い環境や、 binlog_group_commit_sync_delay パラメータでグループコミットサイズを大きく設定している場合に効果的です (詳細は後述)。ただし、タイミングに大きく左右され、実際のデータアクセスパターンの独立性は考慮しないため、実環境では期待ほどの並列度を達成できないことがあります。 WRITESET は、COMMIT ORDER のコミット時間ウィンドウによる単純な判定を超えた、より高度な依存関係追跡方式です。行レベルで実際のデータ変更を追跡します。トランザクションが変更した各行に対して、MySQL はユニークなハッシュを生成します。トランザクションのハッシュの集合がライトセット (write set) を構成します。ライトセットが重複しないトランザクションは、ソースでの実行順序やセッション、コミットタイミングに関係なく、レプリカ上で並列実行できます。時間的な関係ではなく実際のデータ依存関係を追跡するため、レプリカでのレプリケーション並列度を大幅に向上でき、COMMIT ORDER と比較して性能とスループットの改善が期待できます。ただし、WRITESET が COMMIT ORDER を上回らないケースもあり、ベストプラクティスのセクションで詳しく解説します。 MTR の設定とベストプラクティス MTR は RDS for MySQL 5.7、8.0、8.4、Amazon RDS for MariaDB 10.0.5 以上、Aurora MySQL バージョン 3、Aurora MySQL バージョン 2.12.1 以上でサポートされています。ただし、MTR を最大限に活用するには、ソースサーバーとレプリカサーバーの両方を新しいバージョンにアップグレードすることを強く推奨します。本記事執筆時点では、ソースサーバーに RDS MySQL 5.7.44 以上、Aurora MySQL 2.12.5 以上、RDS MySQL 8.0.35 以上、Aurora MySQL 3.10.0 以上を使用すると最適な性能が得られます。レプリカサーバーには RDS MySQL 8.0.35 以上、Aurora MySQL 3.10.0 以上の使用を推奨します。以下では、RDS for MySQL、RDS for MariaDB、Aurora MySQL 環境で MTR を最適化するための主要な設定パラメータとベストプラクティスを紹介します。バージョン間の用語変更により、パラメータ名が異なる場合があります。 ソース側 binlog_transaction_dependency_tracking 有効な値は COMMIT_ORDER 、 WRITESET 、 WRITESET_SESSION です。 COMMIT_ORDER と WRITESET についてはすでに説明しました。 WRITESET_SESSION は WRITESET と同じですが、追加の制約があります。同一クライアントセッションでコミットされた 2 つのトランザクションは並列に適用されません。 Improving the Parallel Applier with Writeset-based Dependency Tracking で確認できるように、ソース側の同時実行ワークロードが高い環境では WRITESET と COMMIT_ORDER の性能は同程度ですが、同時実行性が低い環境では WRITESET の方が高い性能を示します。実際のアプリケーションは、高スレッド数で実行するよう設計された sysbench などのベンチマークテストよりも同時 DML レベルが低い傾向にあるため、この点は実運用で特に重要です。 WRITESET (アプリケーション要件に応じて WRITESET_SESSION ) の設定を推奨します。 WRITESET を使用できず、MySQL が非 WRITESET にフォールバックするケースもあります。 プライマリキーまたはユニークキーのないテーブル – WRITESET 依存関係追跡は、変更された行を一意に識別する機能に依存しています。プライマリキーやユニークキーがないと、トランザクションによる変更のフルセットを正確に追跡できません。WRITESET の使用有無にかかわらず、パフォーマンスの問題を避けるため、すべての InnoDB テーブルにプライマリキーまたはユニークキーを設定してください。詳細は プライマリキーの最適化 を参照してください。 DDL ステートメントを含むトランザクション – CREATE TABLE や ALTER TABLE などの DDL ステートメントは、データではなくデータベーススキーマを変更します。スキーマ変更は通常のデータ変更と同じ方法では追跡しにくく、依存関係追跡の精度に影響します。DML の多い期間中は DDL 操作を最小限に抑えるか避けることを推奨します。レプリケーション性能だけでなく、データベース管理全般のベストプラクティスとしても有効です。 外部キー関係で親テーブルにアクセスするトランザクション – 外部キー関係を持つ子テーブルのデータをトランザクションが変更する場合、親テーブルへの変更がライトセットに完全にキャプチャされない可能性があり、依存関係追跡が不完全になることがあります。 binlog_transaction_dependency_history_size メモリに保持する行ハッシュの上限数を設定するパラメータです。特定の行を最後に変更したトランザクションの検索に使われ、上限に達すると履歴はパージされます。 4xlarge 以上の大きなインスタンスクラスではこのパラメータを増やすことができます。ただし、値が大きすぎるとメモリ消費の増加や依存関係追跡の CPU 使用率上昇でパフォーマンスが低下する可能性があります。トレードオフを把握するため十分なテストを行ってください。 binlog_format バイナリロギング形式を設定するシステム変数で、 STATEMENT 、 ROW 、 MIXED のいずれかを指定できます。 binlog_format は MySQL 8.0.34 で非推奨となり、将来のバージョンで削除される予定です。行ベース以外のロギング形式も将来削除される可能性があります。RDS for MySQL、RDS for MariaDB、Aurora MySQL では、性能と互換性の観点から binlog_format=Row の使用を推奨します。 binlog_group_commit_sync_delay binlog_group_commit_sync_delay は、バイナリログのコミットがディスクに同期されるまでの待機時間 (マイクロ秒) を設定します。 binlog_transaction_dependency_tracking = COMMIT_ORDER と組み合わせると特に効果的です。 binlog_transaction_dependency_tracking = WRITESET の場合は依存関係追跡に影響しません。ソース側のコミットプロセスにわずかな遅延を導入し、各グループコミットにより多くの書き込みをバッチ処理することで、コミットウィンドウが拡大しレプリカでの並列実行が増えます。ただし、ソースサーバーのトランザクションレイテンシも増加するため、クライアントアプリケーションの性能に影響する可能性があります。レプリケーション性能と許容できるトランザクションレイテンシのバランスを見つけるため、十分なテストを推奨します。 トランザクションサイズ MySQL では、適切なトランザクションサイズの維持が性能最適化の鍵です。大きなトランザクションはロックを長時間保持して他の操作をブロックし、システム全体のスループットを低下させます。また、 RollbackSegmentHistoryListLength を増加させ、データベース全体の性能に影響を与える可能性があります。MTR の観点では、大きなトランザクションはレプリカでの並列性を大幅に制限し、レプリケーション遅延を引き起こします ( replica_pending_jobs_size_max のセクションで詳述)。可能な限り大きなトランザクションを避け、大量データの変更が必要な場合は小さなチャンクに分割して個別のトランザクションで処理してください。 レプリカ側 binlog_format Aurora MySQL はクラスター内レプリケーションやバックアップ/リカバリにバイナリログを必要としません。ダウンストリームレプリケーションがなければ、DB クラスターパラメータグループで binlog_format を OFF に設定し、バイナリロギングを無効にすることでレプリケーション性能が向上します。 binlog_format を OFF に設定すると、データベース内の binlog_format セッション変数はデフォルト値の ROW にリセットされます。RDS for MySQL や RDS for MariaDB のレプリカサーバーでも、 自動バックアップを無効化 してバイナリロギングをオフにすることで同様の性能向上が得られます。ただし、レプリカのポイントインタイムリカバリができなくなるトレードオフがあります。 replica_parallel_type または slave_parallel_type 指定可能な値: LOGICAL_CLOCK – ソースがバイナリログに書き込むタイムスタンプに基づいて、レプリカ上でトランザクションを並列に適用します。トランザクション間の依存関係を論理タイムスタンプで追跡し、可能な限り並列化します。 DATABASE – 異なるデータベースを更新するトランザクションを並列に適用します。データが複数のデータベースにパーティショニングされ、独立して同時に更新される場合にのみ適しています。クロスデータベース制約がある場合、レプリカ上で制約違反が発生する可能性があります。 DATABASE を使う特定の理由がなければ、依存関係をより細かく追跡し並列性に優れた LOGICAL_CLOCK を推奨します。RDS for MySQL 8.0 と Aurora MySQL 3 のすべてのバージョンで、デフォルト値は LOGICAL_CLOCK です。 replica_parallel_workers または slave_parallel_workers 1 より大きい値を設定するとレプリカで MTR が有効になり、レプリケーショントランザクションを並列実行するアプライヤースレッド数を指定します。RDS for MySQL 8.0.27 および Aurora MySQL 3.04.0 以前は、デフォルト値は 0 で、レプリカはシングルワーカースレッドで動作します。RDS for MySQL 8.0.27 および Aurora MySQL 3.04.0 以降は、デフォルト値が 4 になり、レプリカはデフォルトでマルチスレッド動作します。 replica_parallel_workers の最適値はハードウェアとワークロード特性によって異なります。 2xlarge 以上のサーバーであればワーカースレッド 4 から始め、監視を通じてチューニングしてください。チューニングについては 次回の記事 で取り上げます。高く設定しすぎるとロック競合などにより、かえって性能が低下する可能性があります。 replica_parallel_workers の変更は即座に反映されず、 mysql.rds_stop_replication と mysql.rds_start_replication でレプリケーションを再起動する必要があります。前述のとおり、プライマリキーのないテーブルは replica_parallel_workers が 1 より大きいレプリカでさらに大きな性能低下を引き起こす可能性があります。 replica_pending_jobs_size_max レプリカサーバー上でワーカースレッドの適用待ちイベントを保持するキューの最大メモリを設定します。ソフトリミットのため、通常のワークロードに合わせて設定できます。異常に大きなイベントがこのサイズを超えると、すべてのワーカースレッドのキューが空になるまでトランザクションが保留され、大きなトランザクションの完了まで後続のトランザクションもブロックされます。イベント処理は保証されますが、ワーカーの同時実行性が大幅に低下しレプリケーション遅延につながります。一般的なイベントサイズを十分に処理できる値を設定してください。また、マルチスレッドレプリカでは、 MySQL ドキュメント に記載のとおり、大きなパケットによるレプリケーション障害を防ぐため、ソースの max_allowed_packet 設定以上の値を設定すべきです。 aurora_binlog_replication_sec_index_parallel_workers (Aurora MySQL のみ) Aurora MySQL バージョン 3.06 以上で利用可能です。複数のセカンダリインデックスを持つ大きなテーブルのレプリケーション性能を改善するため、スレッドプールを導入してセカンダリインデックスの変更をバイナリログレプリカ上で並列に適用します。 aurora_binlog_replication_sec_index_parallel_workers DB クラスターパラメータで、セカンダリインデックス変更を適用する並列スレッドの総数を制御します。デフォルトは 0 (無効) です。有効化にインスタンスの再起動は不要で、 進行中のレプリケーションを停止 し、並列ワーカースレッド数を設定してからレプリケーションを再開します。 aurora_in_memory_relaylog (Aurora MySQL のみ) Aurora MySQL バージョン 3.10 で、バイナリログレプリカ向けのインメモリリレーログキャッシュのサポートが拡張されました。 バージョン 3.05 で最初に導入されたこの機能は、バイナリログレプリケーションのスループットを最大 40% 向上させます。インメモリリレーログキャッシュは、シングルスレッドバイナリログレプリケーション、 GTID 自動ポジショニング が有効なマルチスレッドレプリケーション、そしてバージョン 3.10 以降は replica_preserve_commit_order = ON のマルチスレッドレプリケーション (GTID なしでも可) でデフォルト有効です。 replica_preserve_commit_order または slave_preserve_commit_order replica_preserve_commit_order (または slave_preserve_commit_order ) を ON に設定すると (MySQL 8.0.27 以降のデフォルト)、トランザクションはレプリカのリレーログに記録された順序で実行・コミットされます。トランザクションシーケンスのギャップを防ぎ、ソースと同じトランザクション履歴をレプリカ上で保持します。 replica_preserve_commit_order=ON に設定すると、実行中のワーカースレッドは先行するすべてのトランザクションがコミットされるまで待機します。待機中のステータスは Waiting for preceding transaction to commit と表示されます。レプリカの並列性がわずかに低下する可能性がありますが、データの整合性のため、特にコミット順序に依存するアプリケーションでは有効にすることを推奨します。 最後に、予期しない停止に対する耐障害性を高めるため、ソースでグローバルトランザクション識別子 (GTID) レプリケーションを有効にし、レプリカでも GTID を許可することを推奨します。有効にするには、ソースとレプリカの両方で gtid_mode を ON_PERMISSIVE に設定します。GTID ベースのレプリケーションの詳細は、 GTID ベースのレプリケーションの使用 を参照してください。 まとめ 本記事では、MySQL レプリケーションと MTR の仕組み、主要な設定パラメータ、ベストプラクティスを解説しました。 次回の記事 では、パラレルレプリケーションの監視方法を紹介します。 著者について Huy Nguyen Huy は、AWS サポートのシニアエンジニア。Amazon RDS と Amazon Aurora を専門とし、AWS Cloud でのスケーラブルかつ高可用性なソリューション構築を支援しています。 Arun Gadila Arun は、AWS のクラウドサポートデータベースエンジニア II。RDS for MySQL、Aurora MySQL、RDS for SQL Server を専門とし、3 年半以上の経験があります。RDS MySQL と Aurora MySQL の Subject Matter Expert (SME) として認定されています。 Marc Reilly Marc は、Amazon Aurora MySQL チームのシニアデータベースエンジニア。 この記事は、Solutions Architect の Shinya Sugiyama が翻訳を担当しました。

本記事は 2026 年 10 月 5 日 に公開された「 Materialize once, query anywhere: Introducing Iceberg materialized views in Amazon Redshift 」を翻訳したものです。 Amazon Redshift は Apache Iceberg との統合を段階的に深めてきました。今年初めには、AWS Graviton を搭載した Amazon Redshift RG を発表しました。RG にはデータレイク向けにゼロから設計・統合されたベクトル化クエリエンジンが搭載されています。スキャンを別のフリートに送信するのではなく、ベクトル化された Parquet スキャン、スマートプリフェッチ I/O サブシステム、パーティションおよびファイルレベルのプルーニング、改良されたブルームフィルター、JIT Analyze による Iceberg 統計の自動収集を活用し、クラスター上でネイティブにスキャンを実行します。これらを組み合わせることで、 RA3 と比較して Apache Iceberg クエリが最大 2.4 倍高速化 され、vCPU あたりのコストは 30% 低く、データレイククエリにテラバイト単位のスキャン課金も発生しません。このパフォーマンス基盤の上で、 INSERT 、 CTAS 、 UPDATE 、 DELETE 、 MERGE による完全な ACID 準拠の Iceberg テーブルへの直接書き込みも可能です。アクセス制御は、外部スキーマの IAM ロールを通じた AWS Identity and Access Management (IAM) 権限、またはエンジン横断できめ細かな制御を行う AWS Lake Formation で管理できます。 Amazon Redshift は Iceberg マテリアライズドビューの作成と更新にも対応しました。マテリアライズドビュー (MV) は、コストの高い結合や集計を一度だけ事前計算し、その結果を Amazon Simple Storage Service (Amazon S3) または Amazon S3 Table Buckets 上の標準的な Apache Iceberg テーブルとして、AWS Glue Data Catalog に登録した状態で格納します。おなじみの SQL ( CREATE MATERIALIZED VIEW ... USING ICEBERG ) で作成でき、Amazon Athena、Amazon EMR 上の Apache Spark、AWS Glue をはじめとする Iceberg 互換エンジンからすぐにクエリできます。Amazon Redshift はインクリメンタルリフレッシュで MV を最新に保ち、結果は AWS Glue Data Catalog 上の通常の Iceberg テーブルであるため、他のカタログテーブルと同様にガバナンスや検出が可能です。 あるチームが Amazon Redshift で分析を行っているケースを考えてみましょう。変換処理はすでに Amazon Redshift SQL で書かれており、メンバーは Amazon Redshift に精通し、クエリエンジンへの投資も行っています。足りないのは、コストの高い事前計算済みの結果を、組織内の他のエンジン (Spark を使うデータサイエンスチームや Athena を使うアドホックレポーティングチームなど) と共有する手段です。データのエクスポートや別の変換スタックの構築なしにはそれができません。すでに運用しているエンジンから相互運用性と高速化を両立させたい、というのがこのチームの課題です。 Iceberg マテリアライズドビューを使えば、普段書いている SQL で Amazon Redshift 上に MV を作成するだけで、事前計算された結果がオープンな Iceberg テーブルとして格納されます。Spark や Athena のチームは、コピーや別パイプラインを管理せずに同じ結果を直接読み取れます。新しいデータが到着すると、インクリメンタルリフレッシュが変更分のみを再計算します。最もコストの高いクエリに対する単一の信頼できるデータソースを、すべてのエンジンで共有できるようになります。Amazon Redshift チームは 1 つのエンジンでエンドツーエンドの変換パイプラインを実行し、MV を生データ、クレンジング済みデータ、サービングレイヤー間のビルディングブロックとして活用できます。複数のエンジンをステージごとにつなぎ合わせる必要はありません。 オープンか高速かの二択ではありません。レイテンシーに敏感なダッシュボード向けには、Iceberg マテリアライズドビューを Amazon Redshift Managed Storage (RMS) にロードし、ネイティブな RMS マテリアライズドビューとして利用できます。 Iceberg MV と Amazon Redshift (RMS) マテリアライズドビューの使い分け Iceberg マテリアライズドビューは Amazon Redshift の標準的なマテリアライズドビューを置き換えるものではなく、異なるニーズに対応します。Amazon Redshift マテリアライズドビューは結果を Amazon Redshift Managed Storage (RMS) に格納し、Amazon Redshift からの高速な読み取りに最適化されています。一方、Iceberg マテリアライズドビューは結果をオープンな Iceberg テーブルとして Amazon S3 に格納し、任意のエンジンから読み取れます。結果をどこでどのように使うかに応じて選択してください。 Amazon Redshift (RMS) マテリアライズドビューを使う場面: クエリを Amazon Redshift からのみ実行する場合。 最も低い読み取りレイテンシーが必要な場合。インタラクティブなダッシュボードやサブ秒のルックアップでは、RMS からの読み取りは Amazon S3 上の Iceberg テーブルからの読み取りよりも大幅に高速です。 Amazon Redshift のみのワークロードで最もシンプルな選択肢を求める場合。 Iceberg マテリアライズドビューを使う場面: 事前計算した結果を Amazon Redshift 以外のエンジン (Athena、Spark、Amazon SageMaker AI、サードパーティエンジン) からデータのコピーなしに読み取りたい場合。 相互運用性のために Apache Iceberg を標準化しており、高速化を Amazon Redshift 専用のストレージ形式に依存させたくない場合。 エンドツーエンドのパイプラインを 1 つのエンジンで実行し、すべての下流コンシューマーが同じオープンな結果を共有する構成にしたい場合。 両者は補完関係にあります。 一般的なパターンとして、まずオープン性とエンジン横断アクセスのために Iceberg マテリアライズドビューでデータを構築・変換し、最もパフォーマンスが求められる結果だけを RMS マテリアライズドビューにロードしてインタラクティブなダッシュボードに使います。データはデフォルトでオープン、必要なところだけ高速にする構成です。 本記事では、以下の内容を扱います。 Iceberg マテリアライズドビューの意義と主なユースケース インクリメンタルリフレッシュとエンジン横断アクセスの仕組み 前提条件の設定 (IAM、Amazon S3、AWS Glue) 最初の Iceberg マテリアライズドビューの作成 Amazon Athena と PyIceberg からのエンジン横断アクセスの検証 このソリューションでは以下の AWS サービスを使用します。 Amazon Redshift (Serverless またはプロビジョニングされた RG) AWS Glue Data Catalog Amazon S3 (汎用バケットまたは Amazon S3 Tables) AWS Identity and Access Management (IAM) AWS Lake Formation (オプション、ガバナンス付きアクセス制御用) ソリューションの概要 Iceberg マテリアライズドビューを使えば、Amazon Redshift で集計を一度計算し、結果を Amazon S3 または Amazon S3 Table Buckets 上の標準的な Apache Iceberg テーブルとして格納できます。Iceberg 互換エンジンは、事前計算された結果を直接クエリできます。 図 1: Iceberg 互換エンジンが Amazon S3 から事前計算済みの MV を直接クエリ Amazon Redshift Serverless と Amazon Redshift RG で動作 Iceberg マテリアライズドビューは以下の環境でサポートされます。 Amazon Redshift Serverless – フルマネージドでオートスケーリングするコンピューティング。MV のリフレッシュとアドホッククエリを容量計画なしに並行実行できる、ワークロードが変動する環境に適しています。 Amazon Redshift RG (AWS Graviton 搭載のプロビジョニングインスタンス) – AWS Graviton プロセッサ上で動作するプロビジョニングクラスターで、独自に構築・統合されたベクトル化クエリエンジンを搭載。 データレイクワークロードで RA3 インスタンスと比較して最大 2.4 倍のパフォーマンスを vCPU あたり 30% 低い価格で実現 します。 注: Amazon Redshift RA3 および DC2 インスタンスタイプでは Iceberg マテリアライズドビューはサポートされません。 Amazon Redshift が Serverless またはプロビジョニングされた RG インスタンスで重い計算を一度実行します。すべての Iceberg 互換エンジン (Athena、Spark、SageMaker、AWS Glue) は、Amazon S3 または Amazon S3 Tables から事前計算済みの Iceberg MV を標準的な Amazon S3 の読み取りコストで利用できます。コンシューマー側に追加のコンピューティング課金は発生しません。 ユースケース Iceberg マテリアライズドビューは、分析、コスト最適化、AI ワークロードにわたるさまざまなパターンをサポートします。 1. 最適化を共有するメダリオンアーキテクチャ 課題: Bronze → Silver → Gold アーキテクチャでは、Silver/Gold レイヤーでの最適化は計算を実行したエンジンだけが恩恵を受けます。 Iceberg MV の場合: Amazon Redshift RG がインクリメンタルリフレッシュ付きで Silver と Gold レイヤーを Iceberg MV として計算します。出力は Amazon S3 上の標準的な Iceberg テーブルなので、追加のコンピューティングなしにすべてのコンシューマーが恩恵を受けます。 2. エージェント型 AI、フィーチャーストア、生成 AI ワークロードの強化 課題: AI エージェント、機械学習 (ML) パイプライン、生成 AI アプリケーションは、移動平均、顧客生涯価値、エンゲージメントスコアなどの事前計算済みフィーチャーを、データウェアハウスへの直接接続なしにフレームワークが利用できる形式で必要とします。 Iceberg MV の場合: 重い計算 (複雑な結合、ウィンドウ関数、統計集計) は Amazon Redshift Serverless または RG で一度だけ実行されます。ウィンドウ関数や COUNT、SUM 以外の集計を使用するマテリアライズドビューは、リフレッシュのたびにインクリメンタルではなく全体が再計算されます。MV が計算されて標準的な Iceberg テーブルとして Amazon S3 に格納されると、さまざまなコンシューマーがネイティブにアクセスできます。 Amazon SageMaker ノートブックとトレーニングジョブ は、JDBC ドライバー不要で PyIceberg を通じて Amazon S3 からフィーチャーを直接読み取ります。 Amazon Bedrock エージェント は、Retrieval Augmented Generation (RAG) 用の構造化データとして事前計算済みの分析結果にアクセスします。 Amazon EMR 上の Apache Spark は、大規模 ML トレーニングパイプライン向けに spark.table() でフィーチャーを利用します。 Amazon Athena は、アドホック分析やダッシュボード向けにマテリアライズ済みフィーチャーへのサーバーレス SQL アクセスを提供します。 インクリメンタルリフレッシュでフィーチャーを最新に保てます。インクリメンタルリフレッシュの対象条件については、 Apache Iceberg テーブルとして格納されたマテリアライズドビュー を参照してください。 3. コンピューティング統合によるコスト最適化 課題: 同じ集計を複数のエンジン (Amazon Redshift、Athena、Spark、サードパーティツール) で個別に再実行すると、各エンジンで重複したコンピューティングに課金が発生し、コンシューマーの数に比例してコストが増加します。 Iceberg MV の場合: Amazon Redshift Serverless または RG の 1 回のリフレッシュで集計を一度だけ計算します。コンシューマーは事前計算済みの結果を Amazon S3 から標準的なストレージ読み取りコストで直接読み取り、エンジン間の重複コンピューティングを解消します。統合するコンシューマーエンジンの数に応じてコスト削減効果は拡大します。 4. データ移動なしのガバナンス付きデータ共有 課題: チーム間で分析結果を共有するには、データのコピーやエンジン固有の共有メカニズムが必要です。 Iceberg MV の場合: 出力は AWS Lake Formation で管理されます。単一の権限モデルでアクセスを付与し、コンシューマーは好みのエンジンを使用できます。 5. 分析エンジン全体で単一の信頼できるデータソース 課題: 複数のチームが Spark、Amazon Redshift、Athena、カスタムツールにわたって同じ指標を個別に再計算し、不整合な数値が生まれます。 Iceberg MV の場合: 1 つの CREATE MATERIALIZED VIEW ... USING ICEBERG で Amazon Redshift Serverless または RG 上で指標を一度だけ計算します。すべてのエンジンが Amazon S3 から同じ Iceberg テーブルを読み取り、同じ数値、同じスナップショットで、突合作業は不要です。 仕組み Iceberg MV は Amazon Redshift のネイティブなマテリアライズドビュー機能を USING ICEBERG 句で拡張します。 CREATE MATERIALIZED VIEW awsdatacatalog.analytics.daily_revenue USING ICEBERG LOCATION 's3://amzn-s3-demo-analytics/daily_revenue/' PARTITIONED BY (day(order_date)) AS SELECT order_date, region, SUM(amount) AS total_revenue, COUNT(*) AS transaction_count FROM awsdatacatalog.source.transactions GROUP BY 1, 2; MV は Amazon S3 Table Buckets にも格納できます。 LOCATION 句を省略すると、Amazon S3 Tables がストレージを自動管理します。 インクリメンタルリフレッシュ Amazon Redshift はリフレッシュ間で Iceberg スナップショット ID を追跡します。 REFRESH MATERIALIZED VIEW の実行時に、変更されたソースパーティションを特定し、差分のみを再計算します。 インクリメンタルリフレッシュをサポートするパターン: GROUP BY 付きの SUM および COUNT 集計 集計なしのクエリ (行レベルの差分追跡) Iceberg テーブル間の INNER JOIN フルリフレッシュとなる構文 (サポートはされています): DISTINCT、外部結合、ウィンドウ関数、サブクエリ 集合演算 (UNION ALL、UNION、INTERSECT、EXCEPT) MIN、MAX、AVG、COUNT(DISTINCT)、SUM(DISTINCT) GROUPING SETS、ROLLUP、CUBE クロスクラスターリフレッシュ MV は作成したクラスターに紐付きません。適切な IAM ロールを持つ Amazon Redshift クラスターや Serverless ワークグループからリフレッシュできます。複数のクラスターが同じ MV を同時にリフレッシュしようとした場合、Amazon Redshift は AWS Glue Data Catalog を通じて調整し、一度に 1 つのリフレッシュのみが成功するようにして競合を自動的に防止します。同時実行の処理の詳細については、 Amazon Redshift Iceberg マテリアライズドビュー のドキュメントを参照してください。 エンジン横断アクセス 結果は標準的な Iceberg テーブルであり、特別なドライバーは不要です。以下の例のように、さまざまなエンジンから MV を読み取れます。 Amazon Athena: SELECT * FROM analytics.daily_revenue WHERE region = 'us-east'; Amazon EMR 上の Apache Spark: spark.table("analytics.daily_revenue").filter(col("region") == "us-east") Amazon SageMaker / PyIceberg: from pyiceberg.catalog import load_catalog catalog = load_catalog("glue", **{"type": "glue"}) df = catalog.load_table("analytics.daily_revenue").scan().to_pandas() 前提条件 Iceberg MV のセットアップには IAM、Amazon S3、AWS Glue の設定が必要です。以下の手順に従って環境を準備してください。 コンソールのスクリーンショット付きの詳細な手順については、Amazon Redshift ドキュメントの Iceberg マテリアライズドビューの開始方法 を参照してください。 設定するリソースの一覧は以下の通りです。 リソース 用途 作成するステップ IAM ロール (IcebergMvDefiner) MV 操作用の definer ロール (2 サービスの信頼ポリシー) ステップ 1–2 S3 バケット Iceberg MV データ (Parquet ファイル) の格納 ステップ 3 AWS Glue データベース AWS Glue Data Catalog で MV メタデータを管理 ステップ 4 クラスターロールの関連付け Amazon Redshift クラスターに definer ロールの引き受け権限を付与 ステップ 5 ステップ 1: IAM ロールの作成 以下の信頼ポリシーを持つ IcebergMvDefiner という名前の IAM ロールを作成します。2 つのサービスプリンシパルが必要な点に注意してください。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "redshift.amazonaws.com", "glue.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } 2 つのプリンシパルが必要な理由: Amazon Redshift はマテリアライズドビュー操作を実行するためにロールを引き受ける必要があります。AWS Glue はマテリアライズドビューの definer ロールに代わって、ベーステーブルの権限を確認する必要があります。 ステップ 2: IAM ポリシーのアタッチ IcebergMvDefiner ロールに以下のスコープ付きインラインポリシーをアタッチします。Iceberg マテリアライズドビュー操作に必要な最小限の権限を提供します。 S3 アクセス (バケットにスコープ): s3-mv-access という名前のインラインポリシーを作成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::<>", "arn:aws:s3:::<>/*" ] } ] } AWS Glue Data Catalog アクセスポリシー (データベースにスコープ): glue-mv-access という名前のインラインポリシーを作成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetPartitions", "glue:BatchGetPartition" ], "Resource": [ "arn:aws:glue:<>:<>:catalog", "arn:aws:glue:<>:<>:database/<>", "arn:aws:glue:<>:<>:table/<>/*" ] } ] } IAM PassRole ポリシー (definer ロールにスコープ): mv-access という名前のインラインポリシーを作成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::<>:role/IcebergMvDefiner" } ] } ステップ 3: S3 バケットの作成 MV ストレージ用の S3 バケットを作成します。命名規則として iceberg-mv- を推奨します。デフォルト暗号化 (SSE-S3) を有効にし、パブリックアクセスをすべてブロックしてください。 ステップ 4: AWS Glue データベースの作成 AWS Glue Data Catalog に iceberg_mv という名前のデータベースを作成します。シンプルな create-database コマンドを使用します。データベースはデフォルトで IAM_ALLOWED_PRINCIPALS を継承し、Amazon Athena などのエンジンからのアクセスが可能です。 ステップ 5: ロールと Redshift の関連付け IcebergMvDefiner ロールを Amazon Redshift クラスターまたは Serverless 名前空間に関連付けます。 aws redshift modify-cluster-iam-roles --cluster-identifier --add-iam-roles arn:aws:iam:::role/IcebergMvDefiner ステップ 6: 大文字小文字の区別の設定 Amazon Redshift クラスターに接続し、以下を実行します。 SET enable_case_sensitive_identifier TO FALSE; 最初の Iceberg MV の作成 前提条件が整ったら、外部スキーマ、ベースの Iceberg テーブル、最初のマテリアライズドビューを作成できます。 ステップ 7: 外部スキーマの作成 CREATE EXTERNAL SCHEMA iceberg_schema FROM DATA CATALOG DATABASE 'iceberg_mv' REGION '<>' IAM_ROLE 'arn:aws:iam:::role/IcebergMvDefiner'; ステップ 8: サンプルデータ付き Iceberg ベーステーブルの作成 CREATE TABLE iceberg_schema.orders USING ICEBERG LOCATION 's3://<>/iceberg_mv_blog/orders' AS SELECT 1 AS id, 'us' AS region, 100 AS amount UNION ALL SELECT 2, 'eu', 200 UNION ALL SELECT 3, 'jp', 150; ステップ 9: Iceberg マテリアライズドビューの作成 CREATE MATERIALIZED VIEW iceberg_schema.sales_by_region USING ICEBERG LOCATION 's3://<>/iceberg_mv_blog/sales_by_region' AS SELECT region, SUM(amount) AS total, COUNT(*) AS num_orders FROM iceberg_schema.orders GROUP BY region; ステップ 10: MV の内容の確認 SELECT * FROM iceberg_schema.sales_by_region; 図 2: リージョン別に集計されたマテリアライズドビューの初回クエリ結果 ステップ 11: インクリメンタルリフレッシュのテスト ベーステーブルに新しい行を挿入し、MV をリフレッシュします。 INSERT INTO iceberg_schema.orders VALUES (4, 'us', 300), (5, 'eu', 50); REFRESH MATERIALIZED VIEW iceberg_schema.sales_by_region; SELECT * FROM iceberg_schema.sales_by_region; 図 3: 新しい行の挿入とリフレッシュ後のマテリアライズドビュークエリ結果 エンジン横断での検証 マテリアライズドビューは AWS Glue Data Catalog 上の標準的な Iceberg テーブルとなり、Amazon Redshift への接続なしに互換エンジンからアクセスできます。 Amazon Athena: SELECT * FROM iceberg_mv.sales_by_region WHERE region = 'us'; 図 4: Amazon Athena からのマテリアライズドビューのクエリ Amazon SageMaker / PyIceberg: from pyiceberg.catalog import load_catalog catalog = load_catalog("glue", **{"type": "glue"}) df = catalog.load_table("iceberg_mv.sales_by_region").scan().to_pandas() print(df) Amazon EMR 上の Apache Spark: spark.table("iceberg_mv.sales_by_region").filter(col("region") == "us").show() ビジネスケース 以下の表は、複数のエンジンで共通の集計を計算する代表的なシナリオを示しています。 比較項目 従来型 (サイロ化) Serverless/RG での Iceberg MV コンピューティングコスト 月額約 $7,500 (4 エンジン) 月額約 $1,500 (1 回のリフレッシュ) 指標の整合性 3～4 バージョン 1 バージョン 新しい指標の追加所要時間 数日 (エンジンごと) 数時間 (1 つの定義) ガバナンス エンジンごとの ACL IAM + オプションで Lake Formation コスト試算は、中規模の集計 (入力 1 TB、出力 100 GB) を Athena ($5/TB スキャン)、Amazon EMR 上の Spark ($0.096/hr × 4 ノード)、Amazon Redshift Serverless (8 RPU)、サードパーティエンジンの 4 つで日次実行する想定です。実際の削減額はワークロードにより異なります。 現在の制限事項 サポートされる SQL 構文、インクリメンタルリフレッシュの対象条件、既知の制限事項の最新リストについては、Amazon Redshift ドキュメントの Apache Iceberg テーブルとして格納されたマテリアライズドビュー を参照してください。 (オプション) Lake Formation ガバナンスの追加 組織でエンジン横断の一元的なアクセス制御が必要な場合は、IAM のみの設定に加えて AWS Lake Formation ガバナンスをレイヤーとして追加できます。Iceberg MV に対する Lake Formation 権限は粗粒度 (データベースおよびテーブルレベル) です。きめ細かなアクセス制御 (行フィルター、列フィルター) は Iceberg マテリアライズドビューではサポートされません。以下の追加手順は、本記事のウォークスルーと同じ環境で検証済みです。 IAM ロールの信頼ポリシーに lakeformation.amazonaws.com を追加します (redshift.amazonaws.com と glue.amazonaws.com に加えて)。 ロールのインラインポリシーに lakeformation:GetDataAccess を追加します。 S3 バケットを Lake Formation データロケーションとして登録します。 aws lakeformation register-resource --resource-arn arn:aws:s3::: --role-arn arn:aws:iam:::role/IcebergMvDefiner --region AWS Glue データベースを空の CreateTableDefaultPermissions で再作成します (Lake Formation がテーブルレベルのアクセス制御の権限を持つようになります)。 aws glue delete-database --name iceberg_mv --region aws glue create-database --region --database-input '{"Name":"iceberg_mv","CreateTableDefaultPermissions":[]}' definer ロールに Lake Formation 権限を付与します。S3 バケットへの DATA_LOCATION_ACCESS、データベースへの CREATE_TABLE/DESCRIBE/ALTER/DROP、テーブルへの ALL (付与オプション付き) を設定します。 Lake Formation の詳細な手順については、 Amazon S3 Tables と Iceberg マテリアライズドビューの合理化された権限の使い方 を参照してください。 クリーンアップ 継続的な課金を避けるため、本記事のウォークスルーで作成したリソースを削除してください。 DROP MATERIALIZED VIEW iceberg_schema.sales_by_region; DROP TABLE iceberg_schema.orders; DROP SCHEMA iceberg_schema; 注: DROP MATERIALIZED VIEW は AWS Glue カタログのエントリを削除しますが、Amazon S3 上の基盤データは削除されません。データを削除するには、Amazon S3 プレフィックスを手動で削除してください。 aws s3 rm s3://<>/iceberg_mv_blog/ --recursive まとめ Iceberg マテリアライズドビューは、オープンレイクハウスの約束をさらに前進させます。最適化そのものがポータブルになるのです。Amazon Redshift は Serverless または AWS Graviton 搭載の RG インスタンスで重い計算を一度だけ実行し、他のすべてのエンジンや ML パイプラインが追加のコンピューティングなしにその恩恵を受けます。まず 1 つの MV から始めてみてください。初めてエンジン間で数値が一致するのを確認できるはずです。そこからスケールしていきましょう。 参考資料 Getting started with Iceberg materialized views (Amazon Redshift documentation) Getting started with Apache Iceberg write support in Amazon Redshift (AWS Blog, Nov 2025) Achieve 2x faster data lake query performance with Apache Iceberg on Amazon Redshift How to use streamlined permissions for Amazon S3 Tables and Iceberg materialized views Meet Amazon Redshift RG 著者について Sudipta Bagchi AWS の SQL Analytics 担当シニアスペシャリストソリューションアーキテクトです。Amazon Redshift とオープンレイクハウスパターンを活用した高パフォーマンスの分析アーキテクチャ設計を支援しています。 Dhaval Shah AWS の SQL Analytics 担当シニアスペシャリストソリューションアーキテクトです。AI と大規模分析を支えるデータ基盤の構築を支援しています。 Srishti Mittal AWS のプロダクトマネージャーです。オープンデータレイクの高パフォーマンス化と分析エンジン間の相互運用性に注力しています。Apache Iceberg などのオープンテーブルフォーマットのプロダクト戦略をリードし、顧客やフィールドチームと連携して実際のデータレイクの課題をプロダクト機能に反映しています。 Gaurav Saxena AWS の Database Services (DBS) Amazon Redshift チームのプリンシパルエンジニアです。 Andre Hernich AWS の Database Services (DBS) Amazon Redshift チームのプリンシパルソフトウェアエンジニアです。 この記事は Kiro が翻訳を担当し、Solutions Architect の Yui Numazawa がレビューしました。

AWS Skill Builder に新しく登場した「SAP Generative AI on AWS」コースは、SAP のビジネスデータと AI サービスの間のギャップを埋めるのに役立ちます。多くの場合、両方の領域を理解できるスキルを持つ専門家が不足しており、その結果、AI の取り組みが遅れ、競争優位を逃してしまうことがあります。 SAP アーキテクト、クラウドエンジニア、あるいはこの領域をリードする技術者の方であれば、このコースはまさにあなたのような専門家のために設計されています。本コースは 4 つのモジュールに加え、6 つの検証済みコンピテンシー領域、そして SAP と AWS 環境にまたがる 15 以上のアーキテクチャパターンをカバーしています。 SAP Generative AI on AWS (Level 200) は AWS Skill Builder で受講申し込みが可能になりました。この 90 分の中級コースは、SAP 環境と AWS の生成 AI サービスを結び付けます。生成 AI ソリューションの設計、実装、最適化に役立ちます。 本記事では、このコースが何をカバーしているのか、誰を対象としているのか、そして SAP ワークロード向けの実践的な生成 AI スキルをどのように習得できるのかを解説します。 本コースは、明確に定義された学習の段階を通じてスキルを構築します。各モジュールではまず概念を紹介し、それを実際の文脈の中で示します。次に、シナリオベースの演習を通じてそれを適用します。各段階の知識確認テストにより、次に進む前に学んだ内容を活用できることを検証します。この「教える・示す・適用する・検証する」というサイクルは、事実を暗記するのではなくパターンを体得するのに役立ちます。受講後は、ご自身の SAP 環境ですぐに活用できるスキルが身に付きます。 学べる内容 この 90 分のコースは、SAP ソリューションアーキテクト、クラウドアーキテクト、技術リーダー、および AWS の専門家を対象に設計されています。特に SAP のお客様と協働する方々に焦点を当てています。AWS サービスを用いて SAP 環境内で生成 AI ソリューションを設計、実装、最適化するための実践的なガイダンスを得られます。受講者は、各段階の知識確認テストを通じて検証される 6 つの主要なコンピテンシー領域で習熟度を高めることができます。 主な学習目標は次のとおりです。 AWS 上の SAP データを用いて、生成 AI ワークロードをサポートするデータアーキテクチャを設計する SAP と AWS がどのように協業して SAP のお客様に生成 AI を提供しているかを評価する SAP システムで生成 AI ソリューションを実装するための適切な AWS サービスを選択する エージェント型 AI ソリューションのアーキテクチャパターンを適用する NIST 標準に準拠したセキュリティおよびガバナンスのフレームワークを実装する AWS Well-Architected Framework の原則を用いて実装上の課題を乗り越える コースモジュール 本コースは、専門家による講義と、各段階でのハンズオンのデモンストレーション、シナリオベースの評価、実践的なワークサンプルを組み合わせています。各モジュールは基礎的な概念から応用パターンへと段階的に進むため、学んだ内容をご自身の SAP 環境に直接マッピングするのに役立ちます。知識確認テストにより、次のモジュールに進む前に理解度を検証します。このアプローチにより、理解を段階的に検証していきます。受講者は学んだパターンを自身の SAP 環境に適用できます。次の 4 つのモジュールを、各段階での理解度を検証する知識確認テストとともに進めていきます。 モジュール 1: AI のためのデータ基盤（約 20 分） このモジュールでは、AWS Well-Architected Generative AI Lens の原則を用いて、信頼性の高いデータアーキテクチャを設計する方法を学びます。生成 AI ライフサイクル全体にわたるデータ品質と準備の要件を扱います。また、パフォーマンス最適化のアプローチも取り上げます。コスト最適化のためのリアルタイム処理とバッチ処理のトレードオフを確認します。さらに、信頼性の高い AI 運用のためのエンタープライズセキュリティおよびガバナンスのフレームワークにも触れます。最後に、持続可能な AI ワークロードのための AWS データ基盤ツールの選定に関するガイダンスを提供します。本モジュールでは、AWS Glue Zero-ETL、AWS Lake Formation、Amazon Bedrock Knowledge Bases、および Amazon Quick がどのように連携できるかを探求します。これらのサービスは、SAP の生成 AI 統合のためのデータ基盤を構築します。 モジュール 2: SAP 環境における生成 AI（約 20 分） SAP と AWS がどのように協業して SAP のお客様に生成 AI を提供しているかを学びます。SAP-AWS AI Co-Innovation Program は、Amazon Bedrock、SAP BTP、クラウドクレジット、および技術コンサルティングへのアクセスを提供します。本モジュールでは、3 つの基盤の柱の上に構築された SAP の Business AI フレームワークを検討します。また、SAP BTP の Generative AI Hub が Amazon Bedrock、そして AI Core、AI Launchpad とどのように統合されるかについても説明します。 本モジュールでは、SAP BTP のリファレンスアーキテクチャを扱います。主要なコンポーネントには、CAP ベースのバックエンド、類似性検索のための SAP HANA Cloud Vector Engine、および Retrieval Augmented Generation（RAG）パターンが含まれます。また、SAP BTP と AWS IoT SiteWise および AWS IoT Greengrass との統合についても取り上げます。これらのサービスは、エッジからビジネスプロセスに至るイベント駆動型のアーキテクチャをサポートします。プラットフォームアーキテクチャ、データガバナンス、運用効率にわたるスケーラビリティの考慮事項も含みます。さらに、本モジュールはデータ保護、脆弱性管理、脅威防止を網羅する NIST 準拠のセキュリティにも触れます。 モジュール 3: AWS 環境における SAP との生成 AI（約 20 分） SAP BTP と Joule を用いた SAP 連携ソリューションと、最大限の柔軟性を実現する AWS ネイティブの独立したアプローチという、2 つの補完的な実装経路を学びます。本モジュールでは次の内容を扱います。 AWS SDK for SAP ABAP は、Amazon Bedrock の基盤モデルとのネイティブな ABAP 統合を提供します。SAP 開発者は使い慣れたプログラミングパラダイムを用いて生成 AI アプリを作成できます。 Amazon Quick は、SAP のビジネスユーザーおよび技術ユーザーが疑問に答え、それに基づいて行動するのを支援する AI 搭載アシスタントを提供します。SAP アプリケーションと AWS サービスにまたがるデータを接続します。 Amazon Bedrock AgentCore は、AI エージェントを大規模にデプロイするためのモジュール型サービスを提供します。例外処理の自動化、タスクのオーケストレーション、および定型的な ERP 例外処理に対応します。 マルチエージェントワークフロー は、スーパーバイザーエージェントが専門化されたサブエージェントを調整し、複数のシステムにまたがる複雑な SAP ビジネスプロセスを処理します。 Strands Agents SDK は、オープンソースでモデルに依存しない SDK であり、SAP と AWS 環境にまたがるネイティブな Model Context Protocol（MCP）サポートを備えた AI エージェントの構築を可能にします。 ワークフローオーケストレーションのための Amazon Quick は、Quick Flows と Quick Automate を使用します。これらは定型的なタスクを自動化し、複雑な複数ステップのワークフローを処理します。 本モジュールでは、デュアルなエージェント型 AI 経路についても扱います。Amazon Bedrock AgentCore は、SAP システムと非 SAP システムにまたがるクロスシステムのオーケストレーションを処理します。SAP Joule Studio は、SAP ビジネスプロセスに深く根ざしたエージェントをサポートします。いずれも相互運用性のために MCP や Agent-to-Agent（A2A）プロトコルを含むオープン標準をサポートします。Joint Reference Architectures（JRA）は、インテリジェントなソリューションを展開するための実証済みのブループリントを提供します。 モジュール 4: 実装とベストプラクティス（約 20 分） 制御された自律性、包括的なオブザーバビリティ、リソース効率、分散型の回復性、そして安全なインタラクション境界など、Well-Architected Generative AI Lens の設計原則を SAP の生成 AI 実装に適用する方法を学びます。 本モジュールは、エグゼクティブスポンサーシップの整合、部門横断的なステークホルダーの関与、および測定可能な ROI に対応する AI 戦略と計画のフレームワークに焦点を当てます。SAP の財務決算プロセスの強化という実践的な例が、これらの概念を説明します。また、本番環境向けのモニタリングとメンテナンスのフレームワークについても扱います。AI 固有の指標には、トークン消費コスト、モデルのパフォーマンス、推論レイテンシー、ユーザー導入分析、およびビジネスインパクトの測定が含まれます。 このコースが重要な理由 2 つの戦略的経路 本コースはデュアルなアプローチを提示します。連携した実装のために SAP BTP と Joule を使用するか、柔軟性のために AWS ネイティブの AI ソリューションを使用します。本コースでは、それぞれのアプローチをいつ使うべきか、そしてそれらを効果的に組み合わせる方法を扱います。 包括的なカバレッジ データ基盤から実装、セキュリティ、ガバナンス、そしてエージェント型 AI の機能まで、本コースは SAP 環境における生成 AI ソリューションのエンドツーエンドのライフサイクルをカバーします。 実践的な実装ガイダンス 本コースには、SAP と AWS の Joint Reference Architectures（JRA）、実証済みのパターン、戦略的計画のフレームワーク、および各段階での習熟度を確認する知識確認テストが含まれます。 大規模なエージェント型 AI Amazon Bedrock AgentCore、マルチエージェントワークフロー、Strands Agents SDK、および SAP Joule Studio を、プラットフォーム間の相互運用性をサポートするオープン標準（MCP、A2A）とともに用いて、SAP 環境で AI エージェントをデプロイする実践的な理解を得られます。 このコースを受講すべき方 本コースは次のような方に最適です。 生成 AI 機能の統合を目指す SAP ソリューションアーキテクト AWS 上で AI 搭載の SAP ソリューションを設計するクラウドアーキテクト AI トランスフォーメーションの取り組みを計画する技術リーダー AI インフラストラクチャを実装する SAP Basis およびプラットフォームエンジニア AI ワークロードの基盤を構築するデータアーキテクト SAP のお客様を支援する AWS ソリューションアーキテクト 前提条件: 基礎的な AWS の知識（AWS Cloud Practitioner 以上）、SAP システム（S/4HANA、BTP、または ECC）の基本的な理解、AI/ML の概念への親しみ、およびエンタープライズアーキテクチャの経験。 今すぐ始めましょう SAP Generative AI on AWS (Level 200) は AWS Skill Builder で提供されています。AWS Skill Builder のサブスクライバーは、すぐにこのコースに登録できます。専門家による講義、デモンストレーション、ハンズオンガイダンス、および評価を通じて、包括的な知識を提供します。 SAP on AWS 向けの生成 AI スキルを伸ばす準備はできましたか？ AWS Skill Builder でこのコースにアクセスし、今日から学習の旅を始めましょう。 関連リソース: AWS Training and Certification AWS Skill Builder SAP on AWS Amazon Bedrock AWS Well-Architected Framework 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

メインフレーム基幹系システムの AWS 移行を真剣にご検討中のお客様向けのイベント「AWS Mainframe Modernization Day Tokyo 2026」を 2026 年 9 月 17 日(木) に開催しました。本ブログでその概要を紹介します。 本イベントは以下の三部で構成しました。 Part 1: AWS セッション Part 2: お客様セッション Part 3: お客様同士の交流会 Part 1: AWS セッション 冒頭のオープニングは、アマゾンウェブサービスジャパン合同会社 (以下、AWS) WWSO EAMM シニアマネージャーの Shajan Miah からウェルカムメッセージと全体の流れの案内がありました。 (1)a. 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ: AWS データセンター アマゾンデータサービスジャパン合同会社 (以下、ADS) のデータセンターエンジニアリングオペレーション部門シニアマネージャー 中台拓也は、AWS クラウドサービスを支える物理インフラの全体像を紹介しました。日本には東京・大阪の 2 つのリージョンがあり、各リージョンは最低 3 つのアベイラビリティゾーン (AZ) で構成され、低遅延レプリケーションと災害リスク分散を両立するよう 100km 以内に配置されています。データセンターの建物はグローバル共通のモジュラー型ブロック設計を採用し、ラック密度の将来的な増加に備えた構造耐荷重マージンや、ベンダー依存を排した自社開発のバックアップ電源制御ロジック、大型 UPS を廃止したラックレベルの小型 UPS / バッテリーモジュールによる障害影響範囲の最小化など、独自の垂直統合技術が特徴です。物理セキュリティは境界・インフラ・データの 3 層モデルで構成されています。運用面では、事前構成済みラックの搬入から自動プロビジョニングまでの完了や、障害対応に目標時間を設定しています。すべてのハードウェア作業を ADS 社員が直接担当することで継続的なプロセス改善を実現しています。 (1)b. 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ: メインフレーム技術者のための AWS Nitro System 入門 AWS ソリューションアーキテクト 阿部純一郎は、メインフレームの知見を持つエンジニアを対象に、メインフレームとクラウドインフラの設計思想を両者の共通点と違いに着目して紹介しました。AWS Nitro System とメインフレームアーキテクチャは、仮想化と I/O 処理を汎用プロセッサからオフロードするという同一の設計哲学に収斂していると考えられます。2017 年以前にリリースされた Amazon EC2 インスタンスは Xen ハイパーバイザーを採用しており、リソース競合や機能リリースの遅延等の課題に直面していました。これを Nitro Cards (IBM Z のチャネルサブシステムに相当)、Nitro Hypervisor (PR/SM に相当)、Nitro Security Chip の 3 つのコンポーネントで解決しました。性能面では NVMe / TCP/IP 標準インタフェースによる OS 互換性の維持や最大 200 Gbps の帯域幅、独自の Scalable Reliable Datagram (SRD) プロトコルによるマルチパス分散を紹介し、セキュリティ面ではオペレーターアクセスの排除、API ベースの監査可能な運用、Nitro Enclaves による機密処理の隔離、Instance Attestation による改ざん検証といった二重の保護ドメインを説明しました。講演の締め括りでは、IBM Z の主要概念と Nitro System の対応関係を対比的に一覧表で示し、メインフレームエンジニアが AWS の設計を直観的に理解できるよう提示しました。 (2) セキュリティ ~ 「なんとなく不安」の正体を、ご一緒に AWS シニアスペシャリストソリューションアーキテクト 松崎博昭は、聴講者自身がクラウドセキュリティを客観的に評価できるエビデンスベースのフレームワークを提供することを目的として解説しました。顧客が抱える 3 つの不安——「AWS スタッフにデータを見られないか」「監査証跡の可視性が失われないか」「セキュリティ対応範囲が増えないか」——に対し、データの暗号化に加え、規則ではなく仕組みで守る設計、AWS CloudTrail による不変の操作ログ (最低 90 日間削除不可)、そして責任共有モデルにより、修正適用などの手作業は AWS 側に移り、顧客の手元には運用判断が残ること(変わるのは「見張る」部分で、そこは自動で回る)を、それぞれ before / after 形式で解説しました。さらに、外部監査人により年間 2,600 項目以上の監査を実施しており、 SOC 2、ISO 27001、ISMAP のレポートは顧客が AWS コンソールから直接ダウンロードできます。また、公に報じられたクラウドのセキュリティ事故についても、基盤そのものが破られたのではなく、アクセス許可や公開設定といった「鍵の掛け方」が問われた事例を挙げ、守るべき対象と守り方は移行後も変わらないという文脈で共有責任の境界を示しました。最小権限・アクセス制御・ログ・鍵分離といった既存のセキュリティ原則は、そのまま AWS に移行可能です。暗号化・Amazon GuardDuty・IAM の権限点検といった備え付けの機能を示したうえで、判断は顧客自身が行うものであり、疑問点は担当のアカウントチームや社内のクラウド推進組織に持ち込めること、つまり「一人にはしない」と締め括りました。 (3) 安定稼働を実現する AWS のアプローチ: レジリエンシー AWS 部長 兼 シニアソリューションアーキテクト 大村幸敬は、AWS におけるレジリエンシーの全体像を概説しました。メインフレームがハードウェア冗長による故障防止 (フォールトトレランス) を志向するのに対し、障害は起こり得るものとして迅速な復旧を設計するのがレジリエンスの考え方です。大手証券会社のシステム障害を契機に、日本の金融庁が「止まってはならない」方針からレジリエンス志向へ舵を切った実例がこの考え方を裏付けています。AWS のインフラは汎用 IA サーバーを基盤としつつ、マルチ AZ 配置 (単一リージョン内の約 100km 以内の 3 拠点) や責任共有モデルによるアーキテクチャ設計で高可用性を実現しています。ディザスターリカバリー (DR) については、バックアップ&リストアからマルチサイトアクティブ/アクティブまでの 4 パターンを、コストと RTO-RPO のトレードオフとともに提示しました。高額な待機ハードウェアを購入しておく必要が無く、DR 環境を常時稼働させずにコストを抑制することができます。さらに、システム外のレジリエンスとして、AWS Professional Services、Business Support+ / Enterprise Support、2025 年 12 月リリースの AWS Unified Operations により、日本語対応した専門支援体制を提供しています。 (4) 安定稼働を実現する AWS のアプローチ: 運用の高度化 続いて、大村幸敬は、メインフレームやオンプレミス環境での常識とは異なる、運用に関する新たな考え方を提示しました。第一のテーマとして、AWS を単なるインフラではなく IT のツールボックスと位置づけ、Amazon Connect 等のマネージドサービスによるハードウェアコストの削減と運用負荷の軽減、AWS CloudTrail / AWS Config による自動監査証跡を紹介しました。一方で、ツールは変わってもインフラ/ネットワークエンジニアの必要性が変わらない点も重要です。第二のテーマでは、AWS の大規模な冗長サーバー/ストレージプールを活かしたスナップショットによる環境の即時クローン、Infrastructure-as-Code (AWS CloudFormation) による 30 分以内の環境再構築、AI 支援テスト自動化や新たな AWS Security Agent (設計レビュー・コードレビュー・自動ペネトレーションテスト) を、メインフレーム環境ではコスト制約の大きいテスト環境拡張の代替手段として提示しました。第三のテーマでは、従来型モニタリングからオブザーバビリティへの転換を掲げ、人間の直感では対応困難な未知の障害の根本原因を AI で診断するアプローチを紹介しました。AWS・マルチクラウド・オンプレミス環境を横断してインシデント対応・予防・サイト信頼性エンジニアリング (SRE) タスクを自律的に実行するサービスとして新たにリリースされた AWS DevOps Agent は、既に日本の複数の顧客に採用されています。 (5) デモ: 今、生成 AI でメインフレーム何処まで何ができるのか? AWS メインフレームモダナイゼーションスペシャリストソリューションアーキテクト 皆川元は、2 つのデモを実施しました。1 つ目のデモでは、Amazon Quick を用いた COBOL プログラム仕様書の自動生成と、データ項目に対する変更の影響調査を実演しました。後者は、従来の grep や RAG に基づく方式とは異なり、AWS Transform for mainframe によるデータリネージュ (※) に基づいてデータの上流および下流を辿るアプローチを取りました。2 つ目のデモでは、AWS Transform によるレガシーコードのリバースエンジニアリングと、AI エージェント Kiro によるフォワードエンジニアリングを組み合わせた Reimagine アプローチを紹介しました。CardDemo アプリケーションの VSAM にアクセスするバッチ処理を S3 / DynamoDB / Java / Python による構成へ移行し、Kiro が CI/CD パイプラインまで自動生成する実例で、この手法の実用性を示しました。 (※) データリネージュ (data lineage): アプリケーションから抽出した CRUD に基づいており、データソース、ジョブ、プログラム間の関係をマッピングすることで、データのライフサイクルをトレースできる (6) AWS セッションまとめ これまでの AWS セッションの総括として、独自設計のデータセンターによる迅速な障害検知と復旧、AWS Nitro System による性能分離とセキュリティ、そしてセキュリティ、レジリエンシー、運用の高度化という 3 つの累積的メリットを振り返りました。メインフレームがこれまで 50 年にわたり支持されてきた信頼性・安全性・運用安定性を、AWS が最新のクラウドアーキテクチャで再現できることを示し、次の 50 年の安定稼働を支える信頼できるパートナーとしての AWS を位置づけて締め括りました。 Part 2: お客様セッション 王子イメージングメディア株式会社 神崎工場 事務部 グループマネージャーの野中伸恭氏は、現在実施中のモダナイゼーションに至った経緯と判断の過程を紹介しました。過去 2 回のメインフレーム刷新が現行システムのスパゲッティコード分析で頓挫した教訓から、3 回目は同じマイグレーション手法を避け、経営判断のもと業務そのものを刷新する方針に転換しました。オンプレミスでハードウェアの調達コストを試算したところ、社内承認を得るのが困難と判断し、AWS クラウドを採用しました。「小さく作って駄目なら作り直せる」柔軟性とアジャイル方式を武器に、現行メインフレームの契約更新時期である 2028 年から逆算した計画で構築を進めています。社内のコンセンサス確立を図るべく、現場メンバーの業務ノウハウを活かしつつ 70% の自動化を目指す方針を社内に示したところ、紙帳票の廃止や業務の断捨離を求める声がむしろ多いことがわかりました。2〜3 回の試行錯誤を経て、現在では全社が同じ方向を向いており、AWS Transform for mainframe による現行アプリケーションの仕様の確認や Kiro による AI 駆動開発も活用しながら、順調に前倒しで進行中とのことです。 Part 3: オフィスツアーとお客様同士の交流会 来場したお客様をフロア内でご案内し、麻布台ヒルズのオフィスのコンセプトを紹介しました。 続いて、交流会では、業種や業界を超えてお客様同士で共通の課題が話され、取り組みが共有されていました。 登壇したスピーカーも交えて、活発に質問や意見交換が行われました。セッションではカバーしきれなかった個別の技術相談やアイディアに、大いに盛り上がりました。 おわりに 本イベントでは、ミッションクリティカルワークロードの AWS 移行後の安定稼働にフォーカスした内容を提供しました。 メインフレームから AWS への移行は、お客様それぞれのゴールと課題があり、移行パターンや移行ソリューションも個々に異なります。AWS は、移行を推進するビルディングブロックとなるサービスを提供し、Professional Services (ProServe) による伴走型支援が可能です。更に、AWS 移行の実績を多く持つ経験豊富な AWS パートナーが end-to-end の移行ソリューションを提供しています。 AWS 移行に関するご相談は、担当営業もしくは AWS の担当者 にお問い合わせください。

みなさんこんにちは。ソリューションアーキテクトの大村です。 AWS Japanでは、AIを使ってアプリケーションのモダナイゼーションを進める取り組みを「AI-Driven Modernization」と呼び、お客様やパートナーの皆様と一緒に進めています。このブログでは、AI-Driven Modernizationの考え方と、その中核となるツールとしてAWS Samplesに公開した「AI Modernization Flow（AIMF）」をご紹介します。 AI Modernization Flowは、古い技術スタックで動いているシステムの移行作業を、KiroやClaude CodeといったAIエージェントに決められた手順で進めさせるためのワークフローです。 GitHubで公開しており（ https://github.com/aws-samples/sample-ai-modernization-flow ）、どなたでも手元のコードで試せます。 AI-Driven Modernizationとは モダナイゼーションという言葉が指す範囲は広く、インフラのクラウド移行を指すこともあれば、業務の見直しを指すこともあります。私たちはAI-Driven Modernizationを 「従来は過大な工数やコストで断念していたアプリケーションのモダナイゼーションをAIによって実現すること」 と定義しています。 10年、20年と稼働してきた業務システムでは、言語ランタイムやフレームワーク、ライブラリが古くなっていきます。サポートが終了した技術スタックを使い続けると、保守できる人材の確保が難しくなり、変更のたびに時間とコストが膨らみます。それでもアプリケーションの改修を伴う移行は大がかりな開発プロジェクトになるため、多くのシステムで後回しにされてきました。 この前提が、AIによって変わりつつあります。人が数ヶ月かけていたコード解析も、AIなら数時間です。存在しない、あるいは古くなったドキュメントやテストも、AIがコードから作れます。これまで費用対効果が合わずに見送ってきた移行も、AIを使えば現実的な選択肢になります。 2つのアプローチ：RefactorとReimagine AI-Driven Modernizationでは、移行のゴールに応じて2つのアプローチを使い分けます。 Refactor（技術スタックの最新化）：ビジネスロジックは変えずに、言語ランタイムやフレームワーク、ライブラリを新しくします。AIエージェントが既存コードを分析し、変換と検証を進めます。 Reimagine（再構築）：AIエージェントが既存コードから仕様書を起こし、その仕様をもとに新しいアーキテクチャで作り直します。 どちらの場合も、移行後に業務が同じように動くことを確かめる受け入れテストが欠かせません。この受け入れテストの自動化にもAIを使います。 今回公開したAI Modernization Flow は、このうちRefactorを担うツールです。 AIに「移行して」と頼むだけでは何が足りないのか コーディングエージェントに「このアプリをJava 21に移行して」と頼めば、それらしいコードは返ってきます。しかし、私たちがお客様と一緒に試す中で、ビルドもテストも通ったのに一部の機能が動かない、AIが移行先で機能を勝手に削る、なぜこの実装にしたのか後から誰も説明できない、といった問題を繰り返し見てきました。作業の品質が担当者の移行スキルに大きく左右されることも分かりました。 なかでも見つけにくいのが、エラーを出さずに機能が失われる不具合（サイレント障害）です。たとえばWebフレームワークのStrutsを7系に上げたところ、新しく既定で有効になったセキュリティ設定のために、画面に表示されるはずの値が空になりました。例外は出ず、HTTPのステータスは200で、単体テストもすべて成功していましたが、実際は正しい実装を行えておらず、この検出には人による画面操作や自動E2Eテストの追加が必要でした。 このように、AIを活用した移行プロジェクトを成功させるには、AIに変換させる技術に加えて、移行プロジェクトの進め方を知っていることが必要です。両方の知見を持つ人はまだ多くありません。AI Modernization Flowは、移行プロジェクトの進め方とAIに守らせる作業規律を「型」としてAIエージェントに与え、使う人のスキルに左右されずに一定の品質で移行作業を進められるようにします。 AI Modernization Flow (AIMF) の特徴 分析から最終確認までをAIがガイドする AIMFは、移行作業を6つの段階(Phase)で進めます。 Phase 0a 分析 現行コードから構成を把握し、技術的負債を分析する Phase 0b 移行判断の材料 移行先の候補と規模・リスクをまとめ、移行方針を決める Phase 1 準備 現新比較の方式を決定し、非機能要件の検討範囲を決める Phase 2 計画 作業計画を作り、成功基準を確定する Phase 3 実施 作業計画に従って段階的に移行し、段階ごとに検証する Phase 4 最終確認 全機能を検証し、別の視点からも確かめる 開始時に必要な情報は、対象のソースコードの場所だけです。移行先の技術スタックは、事前に指定することも、現行システムを分析した結果を見てから決めることもできます。Phase 0aの分析にはAWS Transform customを使います。複数のサブシステムのリポジトリを並列に分析した場合は Phase 0b で結果を統合することが可能です。 作業は途中で止めることもできます。Phase 0bで止めれば、移行先の候補と比較、概算規模、主要なリスク、移行方針の案が得られます。まずアセスメントだけを行い、移行に着手するかどうかや予算を判断する、という使い方ができます。 人が判断すべき場面で止まる AIの判断をすべて人がレビューすると、承認待ちばかりで作業が進みません。AIMFは、後戻りにかかるコストに応じて判断を3段階に分けています。ユニット内部の実装は、検証が通ればAIがそのまま進めます。インターフェースやデータ形式の変更、機能の除外、Phaseの境界では、AIが作業を止めて選択肢と影響を示し、人の判断を求めます。止まるかどうかは、AI自身ではなく、あらかじめ決めた条件で判定します。 人に意思決定を求めるのは、ドメイン知識を伝承するための仕組みでもあります。移行をすべてAIに任せると、移行の過程で今後の保守担当者に業務の知識を引き継ぐ機会も失われます。既存システムに詳しい担当者と新しい技術スタックに詳しいエンジニアが一緒に判断し、その理由をADRに残すことで、知識は移行後の保守へ引き継がれます。 作業完了は検証スクリプトによるテストで判定する 各工程の完了は、実際の動作の結果を確認して判定します。例えばビルドが成功しただけでは完了とせず、アプリケーションを動かして自動テストによって動作を確かめた時点で完了とします。 文章で書いたルールは、AIが「守りました」と自己申告するだけで通ってしまうことがあります。そこでAIMFは、守らせたい規律をできるだけ検証スクリプトに置き換えています。先ほど例に出したサイレント障害に対しては、手を入れるべき箇所を台帳にまとめて未対応をゼロにすることと、利用者の操作の流れをブラウザで再現するテストを、完了の条件にしています。 判断と知見と作業内容を記録に残す AIMFは、設計判断をADR（Architecture Decision Record）として記録します。「なぜこの技術を選んだか」「なぜこの機能を対象外にしたか」を後から確認できます。作業中に得られた知見をプラクティスとして記録し、以後の作業に活用します。作業内容の記録はworklogに、現在の作業状態はsession-contextに記録します。担当者が交代しても、日をまたいでも、またエージェントが途中で終了してしまった場合でも作業を再開できます。 3層の構成 AIMFは、移行の進め方を定めるMethod、移行ドメインごとの知見をまとめたPlaybook、AIに守らせる作業規律を実装したHarnessの3層でできています。Playbookは現在、次の3つを用意しています。 Javaモダナイゼーション（Java 8/11、javax名前空間からJava 21、Jakarta EEへ） .NET Frameworkからモダン .NETへ C言語のSolaris x86からAmazon Linuxへの移植 新しい移行ドメインに使う場合は、MethodとHarnessはそのままで、Playbookだけを追加します。お客様の開発標準や過去の移行で得た知見をPlaybookに加えていくほど、次の移行の質が上がります。 実際の移行記録から AIMFを使うと、移行したコードとは別に、何を判断し、何を検証したかの記録が残ります。OSSのアプリケーションを移行した例を紹介します。 Apache Roller（Java） Apache Roller は、Javaで書かれたオープンソースのブログ用CMSです。Java 11、Java EE（javax）、Struts 2.5、Spring 5で構成された約15万行のアプリケーションを、Java 21、Jakarta EE 10、Struts 7、Spring 6、PostgreSQL 17の構成へ移行しました。分析から最終確認までにかかったのは、人とのやり取りを含めて4日間でした。作業時間は日中のみです。 移行の終わりに、AIは画像にあるような移行完了報告を作成します。表はその一部で、作業計画で決めた成功基準ごとに、何で確かめたかが書かれています。 成功基準 確認方法と結果 既存の単体テスト 157件成功。OAuth 1.0の除去に伴い1件を正当に減らした javaxからjakartaへの全面移行 検証スクリプトで残存0件を確認 主要画面の動作 ブラウザ操作のE2Eテストで、ユーザー登録、ログイン、ブログ作成、記事投稿、画像のアップロード、コメントまでを確認 セキュリティ既定値によるサイレント障害がないこと 実際に見つかった複数の障害を修正し、再発を検出する検証スクリプトを追加 性能・リソースリーク・耐障害性 移行後の独立したタスクとして延期（人が判断し、ADRに記録） 報告には、完了した項目だけでなく、対応を保留した項目とその理由も書かれています。この場合は、メンテナンスが終了したXML-RPCやOpenIDといった古いプロトコルについては、AIが選択肢と影響を示し、人が「恒久的に除去する」と判断した経緯がADRに残りました。 これらの移行完了報告やADRは、お客様やプロジェクトの関係者に「何を判断し、どこまで確かめたか」を説明する材料として使えます。 AIMFでできること・できないこと AIMFが向いているのは、ビジネスロジックを変えずに古くなった技術スタックを更新する移行(Refactor)です。既存コードを使わずに新しい言語やアーキテクチャで作り直す場合は、既存コードから仕様を生成して再開発を行うReimagineのアプローチが適しています。 Refactor型アプローチでは基本的にビジネスロジックを変更しないため、従来と同様のテストを行うことで品質を確認します。一方で、従来のテストが手動であった場合、移行作業自体がAIによって迅速に行えても、テストに多大な時間や工数を要してしまい、その効果が限定的になる場合があります。この課題を解決する方法としてWeb画面を操作する受入れテストを、Playwrightで自動化することが考えられます。 Reimagineの際のAIによる仕様生成、受け入れテストの自動化 (UAT Automation) についてはAWS担当営業へご相談ください。 現在のAIMFは、アプリケーション自体の移行を対象にしています。アプリケーションを稼働させるクラウド環境の設計と構築は、AIMFの対象外です。 ただし、クラウドへ移すときには、アプリケーション側の修正が必要になることがあります。たとえば、オンプレミスで動いていたWebアプリケーションをAmazon CloudFrontやApplication Load Balancerの配下で動かす場合、アプリケーションが出力するURLのパスや、セッション管理の仕組みを見直す必要があるかもしれません。こうした修正はAIMFのフローに明示されていませんが、アプリケーションの移行が完了した後に、クラウド環境に合わせた設計と修正をAIエージェントに指示すれば進められます。 性能試験や障害試験を行うかどうかは、Phase1で決める非機能要件の範囲によって変わります。性能や耐障害性を対象にすれば、その検証もAIMFの完了条件に加わります。ただし、本番に近い条件で性能や耐障害性を確かめるには、移行先のインフラ構成が決まっている必要があります。そのため、インフラの設計と合わせて、アプリケーション移行後のフェーズで計画するのがお勧めです。 AIMFは、使えば最適なモダナイゼーションが自動で完成する魔法の道具ではありません。AIの推奨に従えば動くものはできますが、その技術スタックがお客様のシステムにとって適切かどうか、その後もメンテナンスし続けられるかどうかは、アプリケーション開発の知識を持つ人が判断する必要があります。モダナイゼーションを実際に進めるには、プロジェクトとしての体制と予算も必要です。お客様の内製チーム、あるいはSIパートナーと一緒に進める体制を前提としています。 よくいただく質問 Q. オンプレミスで動いているシステムにも使えますか。 A. 使えます。AIMFはソースコードを分析して移行するため、現在の稼働環境は問いません。 Q. 社内の開発標準やコーディング規約を守らせられますか。 A. 守らせられます。規約や命名規則をMarkdownのファイルとして所定の場所に置くと、AIが参照しながら作業します。確実にルールを守らせるにはLint等を併用するよう指示してください。 Q. 移行後の品質を、お客様や社内にどう説明すればよいですか。 A. AIMFの作業内容については、移行完了報告、ADR、検証結果などが説明の材料になります。しかし移行したシステムの品質は、適切なテストを行うことでしか保証はできません。AIMFの中では実装にあたってのベースラインとして現行システムと新システムの動作比較（現新比較）テストの方針を確認し、その範囲でテストを計画・実施して作業を行います。それ以外の必要なテストについてはAIMFとは別に検討、実施が必要です。 Q. すぐに移行する予定はありませんが、何から始めればよいですか。 A. Phase 0のアセスメントのみの実行から始めるのがお勧めです。内部で使用しているAWS Transform custom の comprehensive code analysisによる分析は数十万行のコードでも1-2時間程度で結果が出ます。現行システムの技術的負債と移行の規模感が分かり、移行計画や予算を検討する材料になります。 利用方法 現時点で対応しているコーディングエージェントはKiroとClaude Codeです。ワークスペース（移行対象のソースコードを置くディレクトリの親）で次のコマンドを実行すると、AIエージェント用のルールと作業記録用のリポジトリが準備されます。 cd /path/to/workspace git clone https://github.com/aws-samples/sample-ai-modernization-flow.git ./sample-ai-modernization-flow/install.sh --project myapp-1.0 ¥ --playbook java-modernization --lang ja あとはワークスペースでAIエージェントを起動し、ソースコードの場所を伝えて「Phase 0aからアセスメントを開始して」と指示します。プロジェクトの情報はAIが起動時のインタビューとソースコードの読み取りで埋めるので、設定ファイルを手で書く必要はありません。 ドキュメントは読者に合わせて用意しています。AIMFの考え方を知りたい方は「 基本コンセプト 」、全体像を知りたい方は「 かんたん解説 」から、実際に使う方は「 使い方 」からお読みください。 AWSと一緒に AI-Driven Modernization を始めましょう このブログでは、AWS Japanが取り組むAI-Driven Modernizationと、技術スタックの更新を行うツールとしてAI Modernization Flowをご紹介しました。 AI Modernization Flow を実際に使うと、AIを使ったモダナイゼーションの進め方を具体的に体験できます。まずお手元のコードのアセスメントや移行方針の検討にご利用ください。そして一度AIMFを使って移行作業を行ってみてください。AIを使えばモダナイゼーションの作業は多大な時間と工数を要する一本道の作業ではなくなります。一度移行作業を試して知見をPlaybookに溜めた後、もう一度同じコードに対して移行作業を行っても良いのです。そうして得られた知見をもとに、本格的なPoCや、移行計画の立案に取り組んでみてください。 AWS Japanでは、AI-Driven Modernizationを進めるためのご相談を受け付けています。Refactor型モダナイゼーションではAIMFを使ったアセスメントおよびPoCを、そしてReimagineや受け入れテストの自動化についてもご相談いただけます。 保守期限が迫っているシステムがある、移行したいが規模が読めない、AIでどこまでできるのか試してみたい、といった方は、ぜひAWSの担当営業またはソリューションアーキテクトにご相談ください。SIパートナーの皆様からのご相談も歓迎します。 What’s next AIMFはお客様からのフィードバックをもとに、Playbookの拡充やフローの改善を続けていきます。AIモデルの進化に合わせてフローも変わっていくため、利用する際はGitHubで最新の安定版をご確認ください。 ぜひ手元のコードで試してみてください。GitHubのIssue、またはAWSの担当者までフィードバックをお寄せください。 著者：大村 幸敬（AWS Japan, Manager, Specialist Solutions Architect）