この記事は、2026 年 5 月 28 日に AWS Artificial Intelligence Blog で公開された記事「 Automate AML alert triage with Amazon Quick and Snowflake Cortex AI 」（著者: Nidhi Gupta、Ebbey Thomas、Vipin Mohan、Zahir Gadiwan）を翻訳したものです。 AWS と Snowflake 上でシステムを運用する金融機関は、 Snowflake の AI Data Cloud と AWS のクラウドインフラストラクチャを組み合わせた 緊密に統合されたフレームワーク のメリットを享受できます。このフレームワークには、 Amazon Simple Storage Service (Amazon S3) 、 AWS Glue 、 Amazon SageMaker 、 Amazon Bedrock といった AWS サービスとの統合も含まれます。AWS サービスと Snowflake の間には 50 を超えるネイティブ統合が用意されており、組織はデータセキュリティを維持しながら、価値実現までの時間を短縮するコンプライアンスワークフローを構築できます。 本記事では、金融サービスにおいて最も労働集約的なワークフローの 1 つであるマネーロンダリング対策 (Anti-Money Laundering; AML) のアラートトリアージを自動化し、この統合が実際に機能する様子をご紹介します。 Amazon Quick Flows と Snowflake Cortex を Amazon Quick の Model Context Protocol (MCP) 統合で接続し、トリアージワークフローを構築していきます。私たちのテスト環境では、Amazon Quick を使用して構築した自動化ワークフローによって、アラート調査に要する時間が 30〜90 分から 5 分未満に短縮されました。実際の結果は、アラートの複雑さやデータ量によって異なる場合があります。 AI の活用が成熟するにつれ、最も大きな効果を生む導入形態は単体のアシスタントにとどまらないことがわかってきました。効果が大きいのは、チームがすでに使用しているツールをまたいでオーケストレーションする再現性のあるワークフローであり、複数ステップの手作業プロセスをワンクリックの体験へと変えるものです。Amazon Quick は、生成 AI を活用したチャットエージェント、リサーチ機能、タスク自動化のための Quick Flows、プロセス自動化のための Amazon Quick Automate を提供するエンタープライズ AI サービスであり、ネイティブインデックス、カスタムナレッジベース、ユーザーがアップロードしたファイルなど複数のソースからデータを集約します。Amazon Quick の一部である Quick Flows は、ユーザーのリクエストを標準化された MCP プロトコル（オープンなプロトコル標準）の呼び出しに変換し、OAuth 認証によるエンタープライズレベルのセキュリティを維持しながら、カスタムコネクタを不要にします。AML のトリアージは、入力の収集、調査の実行、出力の生成という同じ構造化されたステップを毎回たどるため、Quick Flows が適しています。この MCP ベースのアプローチは、FinOps のコストトリアージ、SRE のインシデント対応、コンプライアンス調査など、現在チームが手作業でシステム間を橋渡ししている再現性のあるワークフローにも同様に適用できます。 中規模から大規模の銀行の AML アナリストは、通常、1 件のアラートあたり 30〜90 分をかけて手作業でデータを収集し、対応判断の記述 (narrative) を作成しています。 業界の調査 によると、金融機関では一般に AML アラートの 90〜95% が誤検知 (false positive) であることが判明しており、効率的なトリアージが極めて重要になります。この規模の手作業による調査プロセスは、コンプライアンスチームに大きな負荷をもたらしかねません。自動化により、アナリストはより効率的にアラートを処理し、調査時間を短縮しながら、コンプライアンス基準を維持できます。 ソリューションの概要 次の図は、Model Context Protocol (MCP) を通じて Amazon Quick と Snowflake を接続する、エンドツーエンドの統合アーキテクチャを示しています。 図 1: Model Context Protocol を通じた Snowflake マネージド MCP サーバーと Amazon Quick の統合 このソリューションは、Amazon Quick Flows をオーケストレーションレイヤーとして使用し、Amazon Quick が管理する接続を通じて、 OAuth 認証 を備えた Snowflake マネージド MCP サーバー 経由で Snowflake Cortex Agent に到達します。Cortex Agent は調査作業を担い、 Cortex Analyst を通じて構造化された取引データを分析し、 Cortex Search を通じて非構造化のコンプライアンス文書を分析します。一方 Quick Flows は、入力の検証、推論ロジック、書式化された出力の提示を担当します。 図 2: AML アラートトリアージワークフロー: MCP アクションステップを備えた Amazon Quick Flows が Snowflake Cortex Agents (Cortex Analyst と Cortex Search) を呼び出す Quick Flow の入力ステップから調査ブリーフの完成までの、エンドツーエンドのアナリスト体験は次のとおりです。アナリストは公開されたフローを開き、アラート ID（例: ALT-2026-03-02-002 ）を入力し、必要に応じて対象期間を指定します。するとフローは次の処理を実行します。 入力を検証し、アラートが存在することを確認します。 MCP を通じて Snowflake Cortex Agent を呼び出し、取引データ、顧客プロファイル、過去の履歴、コンプライアンスポリシーを横断してアラートを調査します。 構造化された調査ブリーフ（アラートの概要、取引パターン、顧客プロファイル、過去の SAR、ポリシーの参照、リスクスコア、対応判断の推奨、記述のドラフト）を生成します。 実装 このセクションでは、Snowflake のデータレイヤーの準備から Quick Flows のオーケストレーションの構成まで、AML トリアージワークフローを構築する手順を説明します。まず開始前に必要な前提条件から始め、各ステップが前のステップの上に積み上がっていきます。最後まで進めると、アナリストがすぐに利用できる、完全に機能するエンドツーエンドの自動調査パイプラインが完成します。 前提条件 MCP アクションコネクタを構成できる Amazon Quick アカウント。 Cortex Agents、Cortex Search、および Snowflake マネージド MCP サーバー機能にアクセスできる Snowflake アカウント 。 AGENT 、 MCP SERVER 、 CORTEX SEARCH SERVICE 、 SECURITY INTEGRATION の各オブジェクトを作成する権限が必要です。 Snowflake 上の AML データ。取引モニタリングのアラート（Actimize、Norkom、社内ルールエンジンなどの取引モニタリングシステム (Transaction Monitoring System; TMS) から取得）、顧客・口座のマスターデータ、顧客確認 (Know Your Customer; KYC) / 顧客デューデリジェンス (Customer Due Diligence; CDD) の記録が必要です。あわせて、アラート、取引、顧客、対応判断の各ディメンションをモデル化したセマンティックビューが必要です。 Snowflake 上のコンプライアンス文書のコーパス。銀行秘密法 (Bank Secrecy Act; BSA) / AML ポリシーマニュアル、疑わしい取引の届出 (Suspicious Activity Report; SAR) の提出ガイドライン、過去の調査メモ、規制ガイダンス（FinCEN のアドバイザリ、FFIEC BSA/AML マニュアルの抜粋など）を、Cortex Search でインデックス化するためのテーブルにロードしておきます。 SQL、Snowflake の管理、および AWS Identity and Access Management (IAM) の概念に関する知識。 ステップ 1: AML セマンティックビューを準備する (Snowflake) Cortex Analyst は、コンプライアンスチームがアラートや調査をどのように捉えているかに沿った セマンティックビュー を与えたときに、最もよく機能します。Snowflake マネージド MCP サーバーは、 Cortex Analyst でのセマンティックビュー の利用をサポートしています。Snowsight で AI & ML 、 Semantic Views の順に移動し、Snowflake の AML テーブル（ディメンションとメジャー）に対して セマンティックビューを作成 します。 アラートのメタデータ: alert_id、alert_date、rule_name、rule_category、severity、status、alert_score。 取引の詳細: txn_id、txn_date、txn_type、amount、currency、channel、originator、beneficiary、beneficiary_country。 顧客プロファイル: customer_id、full_name、risk_rating、country、industry、onboarding_date、pep_flag、sanctions_flag。 口座のアクティビティ: account_id、account_type、current_balance、avg_monthly_volume、status。 対応判断の履歴: 過去のアラート、過去の SAR、直近の対応判断の結果、アナリストのメモ。 アラート、取引、顧客、口座、対応判断の間にリレーションシップ（結合）を定義しておくと、エージェントは 1 回のクエリでデータモデルを横断できるようになります。 ステップ 2: コンプライアンス文書用の Cortex Search サービスを構築する (Snowflake) AML のトリアージは、非構造化データのコンテキストに大きく依存します。コンプライアンス文書のコーパスに対して Cortex Search サービスを作成し、エージェントがトリアージのたびに関連するポリシーのセクション、SAR 提出用のテンプレート、過去の調査メモを取得できるようにします。 CREATE OR REPLACE CORTEX SEARCH SERVICE aml_policy_search ON search_content ATTRIBUTES doc_type, effective_date, regulatory_body WAREHOUSE = AML_WH TARGET_LAG = '1 hour' EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0' AS ( SELECT doc_id, doc_type, effective_date, regulatory_body, content AS search_content FROM FINCRIMES_DB.AML_SCHEMA.COMPLIANCE_DOCS ); インデックス化する文書には、自組織の BSA/AML ポリシーマニュアル、SAR の提出基準額と記述のテンプレート、FinCEN のアドバイザリ、FFIEC BSA/AML マニュアルの抜粋、過去の調査メモ（必要に応じてマスキングしたもの）、制裁・PEP スクリーニングのガイダンスなどが含まれます。 ステップ 3: AML トリアージ用の Cortex Agent を作成する (Snowflake) 取引のセマンティックビュー (Cortex Analyst) とコンプライアンス文書の検索サービス (Cortex Search) を横断して オーケストレーションする Cortex Agent を作成します。エージェントの仕様には、自組織の調査手法をコード化したシステム指示のブロックが含まれます。このブロックは意図的に設けられたもので、カスタマイズされることを前提としています。ここで示すデフォルトの指示は一般的な AML トリアージのワークフローを反映したものですが、本番環境に導入する前に、自組織固有の手順、エスカレーション基準、規制上の義務に合わせて調整してください。 システム指示のブロック内の番号付きステップを確認し、自組織のワークフローに当てはまらないステップは順序を入れ替えるか削除してください。管轄区域や適用される規制フレームワークなど、組織固有のコンテキストを追加します。レスポンス形式のブロックは、自組織のケース管理システムが期待する出力構造に合わせて更新してください。また、 sample_questions のブロックは、自組織の環境における代表的なアラート ID やクエリパターンに更新しておくと、テスト時にエージェントの挙動を検証しやすくなります。 オーケストレーションの予算 (budget) は控えめに設定し、エージェントが Amazon Quick の MCP タイムアウト制約（現時点では 300 秒）に十分収まる範囲で完了するようにしてください。エージェントを作成したら、Snowsight で Cortex Analyst ツールが使用するデフォルトのウェアハウスを更新します。 CREATE OR REPLACE AGENT aml_triage_agent COMMENT = 'Daily AML alert triage agent' FROM SPECIFICATION $$ orchestration: budget: seconds: 120 tokens: 16000 instructions: system: | You are an AML alert triage assistant for a regulated financial institution. Your job is to: (1) Retrieve and summarize the flagged transaction pattern. (2) Pull the customer profile and account activity baseline. (3) Check for prior alerts, SARs, or investigations on this customer. (4) Retrieve relevant policy sections and SAR filing thresholds. (5) Produce a structured investigation brief with a risk score and disposition recommendation. Never fabricate transaction data. If data is missing, say so. response: | Always use this output format: 1. Alert Summary (alert ID, rule, severity, date) 2. Transaction Pattern (amounts, counterparties, channel, frequency) 3. Customer Profile (risk rating, onboarding, country, industry) 4. Prior History (past alerts, SARs, dispositions) 5. Policy Reference (applicable thresholds, guidance) 6. Risk Assessment (score 1-10, rationale) 7. Disposition Recommendation (close / escalate / file SAR) 8. Draft Narrative (2-3 paragraphs for case notes or SAR) sample_questions: - question: "Review alert ALT-2026-03-02-002" answer: "I will pull the transaction details, customer profile, check prior history, and produce an investigation brief." tools: - tool_spec: type: cortex_analyst_text_to_sql name: TxnAnalyst description: TxnAnalyst - tool_spec: type: cortex_search name: PolicySearch tool_resources: TxnAnalyst: semantic_view: FINCRIMES_DB.AML_SCHEMA.AML_SEMANTIC_VIEW PolicySearch: name: FINCRIMES_DB.AML_SCHEMA.AML_POLICY_SEARCH $$; 上記の system 指示の内容は次のとおりです。「あなたは規制対象の金融機関における AML アラートトリアージアシスタントです。あなたの役割は、(1) 検知された取引パターンを取得して要約する、(2) 顧客プロファイルと口座アクティビティのベースラインを取得する、(3) この顧客に関する過去のアラート、SAR、調査の有無を確認する、(4) 関連するポリシーのセクションと SAR の提出基準額を取得する、(5) リスクスコアと対応判断の推奨を含む構造化された調査ブリーフを作成する、ことです。取引データを決して捏造しないでください。データが欠けている場合は、そのことを明示してください。」 また response ブロックでは、常に次の出力形式を使用するよう指示しています。1. アラートの概要（アラート ID、ルール、深刻度、日付）、2. 取引パターン（金額、取引相手、チャネル、頻度）、3. 顧客プロファイル（リスク格付け、口座開設、国、業種）、4. 過去の履歴（過去のアラート、SAR、対応判断）、5. ポリシーの参照（適用される基準額、ガイダンス）、6. リスク評価（1〜10 のスコアとその根拠）、7. 対応判断の推奨（クローズ / エスカレーション / SAR の提出）、8. 記述のドラフト（ケースメモまたは SAR 用に 2〜3 段落）。 ステップ 4: Snowflake マネージド MCP サーバーを作成する Snowflake Cortex Agents は、外部の MCP クライアントに自動的に公開されるわけではありません。Amazon Quick に検出させたいツールを列挙した MCP SERVER オブジェクトを作成します。 CREATE OR REPLACE MCP SERVER aml_mcp_server FROM SPECIFICATION $$ tools: - title: "AML Triage Agent" name: "aml_triage" type: "CORTEX_AGENT_RUN" identifier: "FINCRIMES_DB.AML_SCHEMA.AML_TRIAGE_AGENT" description: "Runs the AML alert triage agent for daily compliance investigation." - title: "Transaction Analyst" name: "txn_analyst" type: "CORTEX_ANALYST_MESSAGE" identifier: "FINCRIMES_DB.AML_SCHEMA.AML_SEMANTIC_VIEW" description: "Governed natural-language queries over transaction monitoring data." - title: "Policy Search" name: "policy_search" type: "CORTEX_SEARCH_SERVICE_QUERY" identifier: "FINCRIMES_DB.AML_SCHEMA.AML_POLICY_SEARCH" description: "Search BSA/AML policy, SAR guidelines, and prior investigation notes." $$; 各 description の内容は、上から順に「日次のコンプライアンス調査のために AML アラートトリアージエージェントを実行する」、「取引モニタリングデータに対するガバナンスの効いた自然言語クエリ」、「BSA/AML ポリシー、SAR ガイドライン、過去の調査メモを検索する」です。 ステップ 5: Amazon Quick 用に Snowflake OAuth を設定する Amazon Quick は MCP 統合で OAuth をサポートしています。Snowflake のマネージド MCP サーバーは OAuth 2.0 をサポートしていますが、動的クライアント登録 (Dynamic Client Registration) はサポートしていないため、Amazon Quick では手動構成のオプションを使用します。 Snowflake で OAUTH タイプの SECURITY INTEGRATION を作成し、Amazon Quick のリダイレクト URL を登録します。 -- CREATE ROLES CREATE OR REPLACE ROLE IDENTIFIER('AML_MCP_ROLE'); -- Create a security integration for quicksight CREATE OR REPLACE SECURITY INTEGRATION aml_quick_oauth TYPE = OAUTH OAUTH_CLIENT = CUSTOM ENABLED = TRUE OAUTH_CLIENT_TYPE = 'CONFIDENTIAL' OAUTH_REDIRECT_URI = 'https://{region}.quicksight.aws.amazon.com/sn/oauthcallback' OAUTH_ISSUE_REFRESH_TOKENS = TRUE OAUTH_REFRESH_TOKEN_VALIDITY = 86400 PRE_AUTHORIZED_ROLES_LIST = ('AML_MCP_ROLE'); デプロイ先のリージョンにおける正確な URL を Amazon Quick コンソールで確認し、それに合わせて上記コマンドの OAUTH_REDIRECT_URI の値を更新してください。 次のコマンドを実行して、クライアント ID とクライアントシークレットを取得します。 SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('AML_QUICK_OAUTH'); OAUTH_CLIENT_ID と OAUTH_CLIENT_SECRET の値を記録しておきます。 次のコマンドを実行して、Snowflake の OAuth エンドポイントの値を取得します。 DESC INTEGRATION aml_quick_oauth; OAUTH_AUTHORIZATION_ENDPOINT と OAUTH_TOKEN_ENDPOINT の値を記録しておきます。 ステップ 6: 最小権限のアクセス制御を適用する (Snowflake) Amazon Quick の MCP アクセス用に専用のロールを作成します。MCP サーバーと、その配下のツールに対して USAGE を付与します。MCP サーバーへのアクセス権があっても、そこで公開されるツールへのアクセス権が自動的に付与されるわけではありません。 CREATE OR REPLACE USER {quickuser} PASSWORD='{password}' DEFAULT_ROLE = AML_MCP_ROLE DEFAULT_WAREHOUSE='{DEFAULT_WAREHOUSE}'; GRANT USAGE ON DATABASE FINCRIMES_DB TO ROLE AML_MCP_ROLE; GRANT USAGE ON SCHEMA FINCRIMES_DB.AML_SCHEMA TO ROLE AML_MCP_ROLE; GRANT USAGE ON MCP SERVER FINCRIMES_DB.AML_SCHEMA.AML_MCP_SERVER TO ROLE AML_MCP_ROLE; GRANT USAGE ON AGENT FINCRIMES_DB.AML_SCHEMA.AML_TRIAGE_AGENT TO ROLE AML_MCP_ROLE; GRANT SELECT ON SEMANTIC VIEW FINCRIMES_DB.AML_SCHEMA.AML_SEMANTIC_VIEW TO ROLE AML_MCP_ROLE; GRANT USAGE ON CORTEX SEARCH SERVICE FINCRIMES_DB.AML_SCHEMA.AML_POLICY_SEARCH TO ROLE AML_MCP_ROLE; ステップ 7: Snowflake MCP サーバーを Amazon Quick に登録する Amazon Quick コンソールで Connectors に移動し、 Connect to your team タブを選択します。 Model Context Protocol のタイルにあるプラス (+) アイコンを選択して、セットアップを開始します（図 3）。 図 3: Amazon Quick の Connectors ページ: 新しい MCP 統合を追加するために Model Context Protocol のタイルを選択する Snowflake MCP サーバーのエンドポイントを入力します。 https://<account_url>/api/v2/databases/FINCRIMES_DB/schemas/AML_SCHEMA/mcp-servers/AML_MCP_SERVER 図 4: Amazon Quick の MCP 統合: Snowflake MCP サーバーのエンドポイント URL を入力する Next を選択します。 User authentication (OAuth) を選択し、 Manual configuration を選択します。Snowflake の SECURITY INTEGRATION から取得したクライアント ID とシークレット、および Snowflake の OAuth 認可 URL とトークン URL を入力します。 Create and continue を選択します。Amazon Quick が MCP サーバーに接続し、利用可能なツールを検出します。 図 5: Amazon Quick の MCP 統合: Snowflake の認証情報を入力した OAuth 手動構成のフィールド ステップ 6 で作成した Snowflake ユーザーを使用して、Snowflake に認証する必要があります。 図 6: Snowflake の認証情報を使用して Snowflake にサインインする Snowflake-managed MCP server tools （Cortex Agent、Cortex Analyst、Cortex Search）に対応する、検出されたアクションの一覧を確認して確定します。これらのツールが調査作業を担い、Quick Flow は自身で定義したワークフローのロジックに基づいて、それらをアクションステップとして呼び出します。 図 7: 検出されたツール (aml_triage、txn_analyst、policy_search) を表示する Amazon Quick の MCP 統合確認ページ ステップ 8: AML トリアージの Quick Flow を構築する Quick Flows に移動し、 Create flow を選択します。ワークフローは自然言語で記述することも、ビジュアルエディタを使用してステップごとに構築することもできます。このフローは、入力ステップ、MCP アクションステップを含む Reasoning group、出力ステップ、そして任意のフォローアップチャットという 4 つのセクションで構成されます。 入力ステップ: アラート ID を収集する アナリストにアラート ID（例: ALT-2026-03-02-002 ）と任意の対象期間の入力を促す User input ステップを追加します。これによってフローは再現性があり、自己説明的なものになります。すべての実行が同じ構造化された入力から始まるため、アナリスト間でプロンプトのばらつきが生じません。 図 8: Quick Flow エディタ: アナリストからアラート ID と任意の対象期間を収集するように構成された入力ステップ Reasoning group: MCP を通じてアラートを調査する アラートを調査するための分岐ロジックを含む Reasoning group を追加します。この例で Reasoning group を使用するのは、 CRITICAL のアラートを BSA オフィサーによる即時レビューへエスカレーションする、 HIGH_RISK_GEO のアラートに強化レビューを適用する、過去の SAR が見つかった場合にエスカレーションを推奨するといった、条件付きのトリアージ経路をフローがサポートできるようにするためです。ワークフローが常に条件分岐なしで同じ aml_triage アクションを実行する場合は、入力ステップの直後に Snowflake MCP のアプリケーションアクションを配置することで、Reasoning group を使わずにこのフローを構築することもできます。 図 9: Quick Flow エディタ: 調査ロジックを含む Reasoning group を追加する Reasoning group 内に Application actions ステップを追加し、ステップ 7 で作成した Snowflake MCP 統合を選択します。 aml_triage アクションを選択します。そして、このアクションステップ用のプロンプト指示を記述します。 Investigate alert {alert_id} using the AML triage agent. Pull the customer profile, summarize the flagged transaction pattern, check for prior alerts and SARs, retrieve relevant BSA/AML policy sections, and produce a structured investigation brief with a risk score and disposition recommendation. Use the eight-section output format: Alert Summary, Transaction Pattern, Customer Profile, Prior History, Policy Reference, Risk Assessment, Disposition Recommendation, Draft Narrative. このプロンプトの内容は次のとおりです。「AML トリアージエージェントを使用してアラート {alert_id} を調査してください。顧客プロファイルを取得し、検知された取引パターンを要約し、過去のアラートと SAR を確認し、関連する BSA/AML ポリシーのセクションを取得して、リスクスコアと対応判断の推奨を含む構造化された調査ブリーフを作成してください。出力は 8 セクション形式（アラートの概要、取引パターン、顧客プロファイル、過去の履歴、ポリシーの参照、リスク評価、対応判断の推奨、記述のドラフト）を使用してください。」 図 10: Quick Flow エディタ: Snowflake 統合の aml_triage ツールを呼び出す MCP アクションステップを含む Reasoning group {alert_id} 変数のデフォルト値は入力ステップから自動的に設定されますが、手動で上書きすることもできます。Reasoning group には、さまざまなアラートのシナリオに対応するための追加の分岐ロジックを、自然言語の指示として含めることができます。 深刻度が CRITICAL のアラートの場合、Reasoning group はエージェントに対して、制裁リストを確認し、そのケースを BSA オフィサーによる即時レビュー対象としてフラグを立てるよう指示します。アラートのカテゴリが HIGH_RISK_GEO の場合、エージェントは受益者の国を最新の FATF 高リスク管轄区域リストと照合し、OFAC スクリーニングのガイダンスを取得します。顧客に過去の SAR の記録がある場合、エージェントは過去の調査の記述を取得し、クローズではなくエスカレーションを推奨します。 出力ステップ: 調査ブリーフを提示する 調査ブリーフを書式化してアナリストに提示する Output ステップを追加します。出力には、Cortex Agent のレスポンスに含まれる 8 つのセクションすべてが含まれます。アナリストはブリーフをレビューでき、さらに Quick Flows はエージェント型ランタイムをサポートしているため、フローとチャットしながら出力を改善できます。 図 11: Quick Flow エディタ: 8 つのセクションすべてを含む書式化された調査ブリーフを表示する出力ステップ ステップ 9: フローを公開して共有する フローのテストが完了したら、 Share and Publish を選択して、フローライブラリで利用できるようにします。その後、コンプライアンスチームと共有します。 図 12: Quick フローを共有して公開する アナリストは、ライブラリからフローを開くか、Amazon Quick のチャットインターフェイスから呼び出すことができます。すべてのアナリストが同じ構造化されたトリアージワークフローを実行するため、プロンプトエンジニアリングの経験の有無にかかわらず、一貫した監査対応可能な調査ブリーフが生成されます。 ステップ 10: ワークフローをテストする AML Alert Triage Flow を開き、テスト用のアラートで実行します。アラート ID を入力し、Start ボタンを選択して、フローを実行します。フローは MCP を通じて Snowflake Cortex Agent を呼び出します。エージェントは内部で Cortex Analyst と Cortex Search をオーケストレーションし、構造化された調査ブリーフを返します。 図 13: Quick フローをテストする 図 14: AML トリアージ Quick Flow から生成された出力 ブリーフをレビューした後、アナリストはチャットインターフェイスを使ってフォローアップの質問を行い、最終化する前に出力を改善できます。次のような質問例でインターフェイスをテストしてみてください。 「これらの国はどの FATF リストに掲載されていますか。行動要請 (call to action) ですか、それとも監視強化 (increased monitoring) ですか」 「この顧客について、過去の調査では何が判明しましたか」 図 15: フォローアップの質問に対する Quick フローからのレスポンス セキュリティとガバナンスに関する考慮事項 フローをコンプライアンスチームと共有する前に、対処しておくべきセキュリティとガバナンスの考慮事項がいくつかあります。 アクセス制御の観点では、MCP 統合は OAuth で認証されたロール ( AML_MCP_ROLE ) の権限で動作します。このロールの権限は、MCP サーバー、エージェント、セマンティックビュー、検索サービスに対する最小限の USAGE と SELECT に限定し、 SYSADMIN や ACCOUNTADMIN の付与は避けてください。 Cortex AI は Snowflake のセキュリティ境界内でデータを処理するため、データが Snowflake アカウントの外に出ることはありません。規制対象の金融データについて、Snowflake のリージョンが自組織のデータレジデンシー要件を満たしていることを確認してください。 多くの管轄区域では、AML の調査データは漏えい禁止 (tipping-off) の規制対象となります。つまり、疑わしい取引の届出を行おうとしている、または行ったという事実を、当該顧客や関係者に知らせることが禁じられています。Quick Flow は権限を与えられたコンプライアンス担当者のみと共有し、組織全体のフローライブラリに公開したり、顧客対応のロールに公開したりしないでください。 監査の観点では、Amazon Quick が MCP ツールの呼び出しとフローの実行をログに記録し、Snowflake の ACCESS_HISTORY ビューと ACCOUNT_USAGE ビューが Cortex Agent によって実行されたすべてのクエリを記録します。これらを組み合わせることで、検査官のレビューに対応できる調査の監査証跡が得られ、フローの各実行が個別に追跡可能なイベントとして残ります。 このフローは調査ブリーフと対応判断の推奨のドラフトを生成しますが、SAR の提出やケースのクローズはすべて、人間のコンプライアンスアナリストがレビューし承認する必要があります。このフローは調査を加速するものであり、自動的に意思決定を行うものではありません。 Cortex Agent が使用する LLM モデルを文書化し、モデルインベントリでバージョン管理するとともに、 SR 11-7 / OCC 2011-12 に従って自組織の AI/ML モデルリスク管理フレームワークに含めてください。 Snowflake の OAuth 認証情報は自組織のキーローテーションポリシーに従ってローテーションし、リフレッシュトークンの有効期間は、運用上のニーズを満たす最短の期間に設定してください。 調査手法が進化したら、フローを更新して再公開してください。Quick Flows は反復的な改善をサポートしており、アナリストは自動的に最新バージョンを利用できます。 チャットエージェントではなく Quick Flows を選ぶ理由 Quick Flows は、毎回同じ調査ステップを強制します。これがこのソリューションの中核となる設計判断です。チャットエージェントはプロンプトの指示に緩やかに従うため、各アナリストのリクエストの表現によって出力が変動します。一方フローは決定的な結果を実現します。誰が実行しても、すべてのアラートが同じ構造化された入力、同じ推論ロジック、同じ書式の出力を通ります。 この一貫性こそが、調査ブリーフをデフォルトで監査対応可能なものにしています。フローの各実行は、個別にログに記録されたイベントです。Reasoning group における条件分岐は、 CRITICAL のアラートを強化ステップに振り分け、過去に SAR がある顧客を自動的にエスカレーションするもので、チャットエージェントでは確実に再現できないロジックを強制します。トリアージワークフローの範囲外のアドホックな質問については、同じ Snowflake MCP 統合が Quick のチャットエージェントでも同様に機能します。Quick Flows とチャットエージェントは同じ基盤を共有しており、ユースケースに応じたインターフェイスの違いにすぎません。 リソースのクリーンアップ このソリューションをプロトタイプとして構築した場合は、継続的な露出と課金を避けるために、次のリソースを削除してください。 Amazon Quick で、AML Alert Triage フローを 削除または非公開にします 。 Amazon Quick で、Snowflake MCP サーバーへの 統合を削除します 。 Snowflake で、ツールを外部に公開する必要がなくなった場合は MCP SERVER オブジェクトを削除 (DROP) します 。 Snowflake で、OAuth に使用した SECURITY INTEGRATION を無効化または削除 (DROP) します 。 Snowflake で、ワークフローを廃止する場合は Cortex Agent 、 Cortex Search サービス 、およびテストデータのテーブルを削除 (DROP) します。 まとめ 本記事では、Snowflake マネージド MCP サーバーを通じて Snowflake Cortex Agent に接続する Amazon Quick Flows を使用して、日次の AML アラートトリアージワークフローを構築する方法をご紹介しました。構造化された入力ステップから、フローは MCP を通じて Cortex Agent を呼び出し、Cortex Analyst（構造化された取引データと顧客データ用）と Cortex Search（BSA/AML ポリシーと過去の調査メモ用）をオーケストレーションして、リスクスコアと対応判断の推奨を含む完全な調査ブリーフを提示します。 プロンプトの表現によって出力が変動するチャットエージェントとは異なり、Quick Flows は入力の検証、推論ロジック、書式化された出力を組み込んだ、予測可能で再現性のあるシーケンスを強制します。これにより、アナリストはプロンプトエンジニアリングを習得しなくても一貫した高品質のトリアージを実行でき、ワークフローをワンクリックでチーム全体に配布できます。すべてのアナリストが同じ構造化されたトリアージを実行します。出力形式は予測可能で、各実行は個別の監査可能なイベントとなります。同時に、Quick Flows のエージェント型ランタイムにより、アナリストはワークフローとチャットして出力を改善したりフォローアップの質問をしたりできるため、構造化されたプロセスの厳密さと会話型インターフェイスの柔軟性を両立できます。 ここでの鍵となるパターンは、Snowflake マネージド MCP サーバーを通じて Cortex Agent を MCP ツールとして公開し、Amazon Quick から OAuth で接続することです。この同じ MCP 統合は Quick Flows、チャットエージェント、Amazon Quick Automate をまたいで機能するため、日次のトリアージ用の構造化されたフローから始めて、ニーズの拡大に応じてアドホックなチャットエージェントやエンタープライズ規模の自動化へと広げていくことができます。 まずは、 Using Amazon Quick Flows 、 MCP integration 、 Snowflake-managed MCP server 、および Amazon Quick ユーザーガイド をご覧ください。Amazon Quick の機能の詳細については、 Amazon Quick のドキュメント を参照し、 Amazon Quick コミュニティ もぜひフォローしてください。 著者について Nidhi Gupta Nidhi は AWS の Senior Partner Solutions Architect で、データと分析を専門としています。お客様やパートナーが AWS 上で Snowflake のワークロードを構築し最適化する支援をしています。Nidhi は本番リリースとデプロイをリードしてきた豊富な経験を持ち、データ、AI、ML、生成 AI、高度な分析に注力しています。 Ebbey Thomas Ebbey は AWS の Senior Generative AI Specialist Solutions Architect です。ISV やお客様と協力して AI エージェントの実践的なユースケースを見極め、それを本番品質の生成 AI ソリューションへと仕上げています。Ebbey はシラキュース大学でコンピュータエンジニアリングの学士号と情報マネジメントの修士号を取得しました。仕事以外では、コーヒー、アウトドア、ワークアウト、ロードトリップ、そして家族と過ごす時間を楽しんでいます。 Vipin Mohan Vipin は Amazon Web Services の Principal Product Manager で、エージェント型 AI のプロダクト戦略をリードしています。数千のお客様に提供される AI/ML プロダクト、コンテナプラットフォーム、検索技術の構築を専門としています。仕事以外では、プロダクトマネージャーを志す人たちのメンターを務め、金融投資や起業に関する読書を楽しみ、2 人の子供の目を通して世界を探検することを楽しんでいます。 Zahir Gadiwan Zahir は Snowflake でクラウドサービスプロバイダー向けのパートナーソリューションエンジニアリングをリードしています。クラウドパートナーやお客様と密接に連携し、ガバナンスの効いたエンタープライズデータを実世界の AI 成果へと変える支援をしており、セキュアでスケーラブルなアーキテクチャに特に注力しています。組織がモダンな AI 体験を Snowflake のガバナンスされたデータと AI 機能に接続し、実験から本番へと進んでいく方法について、現場に根ざした実践的な視点を持っています。

本記事は「 How We Learned to Trust an AI Agent to Triage Production Incidents 」を翻訳したものです。 ある日曜日の午前 2 時 33 分（PDT）、フロンティアモデルの可用性アラームが発報しました。本番のレスポンスがストリームの途中で止まりはじめ、監視システムが自動でチケットを起票しました。 その 13 分 35 秒後、午前 2 時 46 分（PDT）には、根拠のある診断がチケット上に載っていました。ストリームが本番バグかキャパシティのスケーリングのいずれかによってエラーを出さずに停止していること、顧客に影響が出ていること、競合する仮説がすべて排除されていること、そして裏付けとなる証拠を添えた推奨される次のアクション、が書き出されていました。 オンコールエンジニアが打ち込んだのは 1 文だけでした。「エスカレーションを起票して」か「本番バグを対処して」か。本当の貢献は、仕上がったブリーフを読み、そこに浮かび上がった判断を吟味し、意思決定することでした。 調査を行ったのは、 Kiro CLI 上で動く AI エージェントでした。本記事は、私たちのチーム、すなわちエージェントを中心に仕事の進め方を再設計している フロンティアチーム の 1 つが、どのようにして本番チケットキューをエージェントに任せられるようになったのか、そして今なお何をエージェントにやらせていないのかについて書いたものです。 仕事: 大規模に、午前 2 時に、トリアージする 私たちのチームは Kiro のデータプレーン、つまり Kiro の IDE 、 CLI 、 Web 、 iOS 、 Kiro Crew からのすべてのエージェンティックなチャットリクエストを、複数リージョンにまたがるモデル群（Anthropic、OpenAI、GLM、Qwen、DeepSeek、MiniMax。いずれも Amazon Bedrock 上でホスト）へと運ぶ配信経路を運用しています。各モデルには、それぞれ可用性、レイテンシー、スロットリング、キャッシュ、合成プローブのアラームが備わっています。 アラームが発報したら、誰かがそれをトリアージしなければなりません。これは本物か、何が壊れたのか、誰が影響を受けているのか。1 件の可用性の低下は、キャパシティイベントかもしれないし、不正アクセス攻撃、まずいデプロイ、あるいはチューニングを誤ったアラームかもしれません。そして各仮説は、それぞれ別のロググループ、別のアカウント、別のクエリ言語の中に存在します。優れたトリアージとは、500 個の問いのうちどの 5 個を最初に問うべきかを知っていることです。なぜなら、それぞれの結果が次のクエリを決めるからです。 トリアージは仮説探索であり、ツールを備えたエージェントはまさにそのために作られています。長年蓄積してきた Runbook、アラーム Wiki、ポストインシデントのメモは、すでにエージェントのコンテキストへの投資になっていました。この仕事は読み取り中心です。エージェントのツール呼び出しの 96.9% は読み取り（安全で、可逆で、並列化できる）で、残りはゲートをかけられます。そしてトリアージは繰り返されます。学んだことを書き留めるエージェントは、システムの知識を複利で積み上げていきます。午前 3 時の疲れた人間には、それができません。 システム: Kiro ハーネスを取り巻く markdown と MCP サーバー オーケストレーションフレームワークもなければ、ファインチューニングしたモデルもなく、専用のエージェントランタイムもありません。システムは Kiro CLI、すなわち 私たちが顧客に提供しているのと同じ CLI を、自分たちのオペレーションに向け、エンジニアがコードと同じように書いてレビューする 3 種類のプレーンなファイルで設定したものです。 エージェント設定 : モデル、ツール、そして運用ルールを記した markdown のステアリングファイル。各ルールは一度下した人間の判断であり、以降はそれが適用されます。 Model Context Protocol （MCP） サーバー : エージェントがツール（ReadOnly の AWS アカウント、ログ、チケット、パイプライン、コードレビュー、Slack）に接続できるようにします。 スキル と知識 : 面白いのはここで、次に取り上げます。 ハーネスの周りには、チケットキューを監視し、チケット 1 件につき 1 つのヘッドレス Kiro CLI セッションを起動する、常駐のディスパッチャーが 1 つ配置されています。モデルはアーキテクチャ上の決定ではなくランタイムパラメータです。主任調査官（lead investigator）は利用可能な最も強力なモデルで動き、ファンアウトの作業は高速で安価なモデルで動くサブエージェントの群れに回され、本当に曖昧な判断は 3 つのプロバイダーのモデルからなる評議会（council）へ並列に投げかけられます。意見の不一致は、さらに証拠を集めよというシグナルとして扱われます。 図 1: トリアージのパイプライン。アラームがチケットになり、ディスパッチャーがエージェントセッションを起動し、エージェントはスコープを絞った ReadOnly ツールで調査してチケットに証拠を書き戻す。 スキルは巨大なプロンプトの代わりに段階的開示（progressive disclosure）をもたらす 対照的に、スキルは 1 つの状況のための markdown の手順書です。エージェントのコンテキストが抱えているのは全 107 個のスキルのインデックスだけで、チケットが合致したときに、その 1 つのスキルの手順書全体を読みます。何もかもをシステムプロンプトに詰め込むやり方は、10 個目の Runbook あたりで破綻します。コンテキストが、発報していない 99 個のアラームのための指示で埋まってしまうからです。以下は、あるレートリミットのインシデントの後に書かれた、要約した抜粋の例です。 # Provider rate limit driving an AVAILABILITY alarm [evolved: step 4 added after that night's investigation] Key insight: a 429 is normally a client-side Error, not a Fault. But with the provider's token allocation exhausted, its 429s reach customers as 5xx faults, so never pre-filter to status=5xx: a 429 flood can be 20x larger. Procedure (last two of four steps): 3. Error-mode fork: overload → wait, the provider auto-scales in about an hour; hard quota → waiting will NOT clear it, request a raise 4. Attribute 429s per cell: a few hot cells = quota problem, every cell warm = capacity problem 知識はコストによって階層化されています。常に必要な事実は常時ロードされ、手順書はオンデマンドでロードされ、コンパイル済みの過去の調査が何百件も検索可能なアーカイブに収められています。この階層化が生存を可能にします。長い調査は、何よりもまずコンテキスト枯渇によって死ぬからです。 ある調査の解剖 あの午前 2 時 33 分のアラームに戻りましょう。エージェントが踏むすべてのステップはログに記録され、投稿するすべての主張は、それを生み出したクエリへのリンクを持ちます。 図 2: 分刻みで見た調査。アラームから診断の投稿まで 13 分 35 秒。人間による調査であれば始まってすらいなかった時間帯である。 より深い価値は、誰も手作業ではやらない仕事にあります。その 1 週間前、別の新しいモデルのアラームは、モデル全体に及ぶキャパシティイベントのように見えました。すべてのストリームエラーを、リクエスト ID でルーティングレコードと突き合わせたところ、エージェントはエラーの 96.5% が私たちの分離された配信セルのうちわずか 2 つに由来し、残りのセルではエラーがゼロだったことを突き止めました。生き残った仮説「セルごとのクォータが不均等」は ReadOnly の認証情報で確認され、上流の依存関係に潜んでいたバグを露呈させました。エンジニアでも同じことはできますが、週末の夜に、インシデント対応の最中に、何十ものアカウントをまたいで、というのは無理です。 フライホイール: 人間が作り、エージェントが回す このシステムを毎週改善しているのは、その周りを回るループです。エンジニアがエージェントを導き、その学びをキュレーションします。 図 3: フライホイール（調査する、記録する、コンパイルする、進化させる）。次の同一アラームは、前回が終わったところから始まる。ステップ 1 からではない。 これを回し続けるための仕組みが 4 つあります。 修正はレッスンになる。 各修正は一度だけ保存され、その後のすべてのセッションに注入されます（数千の完了済みランに対して数百の修正であり、メモリの必要量を削減します）。そしてエージェントは、自分を誤らせたドキュメントにパッチを当てます。プロンプトのバグはドキュメントのバグから生まれたものだからです。 調査は知識になる。 クローズされたチケットは、その後のセッションが真っ先に照会するアーカイブへと蒸留されます。 エージェントがスキルを作成し、人間がレビューする。 新規のインシデントの後、エージェントは新しい手順書か差分（delta）を作成します。レートリミットの手順書は、まさにその同じ夜にこの方法でセルごとのステップを得ました。エンジニアと夜間ジョブが、 もう 1 つのコードベースとまったく同じように ライブラリをキュレーションします。 エージェント間での状態共有。 条件付き書き込みのエスカレーショントラッカーによって、同じインシデントを観測している 10 個の並列エージェントは、上流チケットを 10 件ではなく 1 件だけ起票します。 その一方で、このループが私たちを裏切ったこともあります。レッスン取り込みのパイプラインは、かつてセッション終了時に保留状態だったテキストをそのまま受け入れていました。そのため中断されたセッションが、生のチケットコメントを一字一句そのまま修正ストアに書き込み、その後のセッションがそれを運用上の知恵として誤って学習してしまいました。修正策は、書き込み前のスキーマ検証と、夜間のクリーンアップでした。キュレーションと慎重な管理を欠くと、学習パイプラインはゴミを、知識と同じくらい効率よく複利で積み上げてしまいます。 何にコストがかかり、何を取り戻すのか Kiro はエージェントを、顧客が購入するのと同じ単位であるクレジットで計測します。代表的な 1 か月で約 250 件の調査が生まれ、無人で、中央値 13.6 分で完了しました。支出は 自制ではなく構造によって制限されます 。すなわち、セッションのタイムアウト、スタック検知、同時実行数の上限、そしてファンアウト用の安価なモデルです。すべて合わせても、月々の請求額は私たち自身の最上位サブスクリプション 9 個分に相当し、取り戻した時間はブリーフのレビュー、エージェントの修正、根本原因の修正へと注がれます。 私たちが間違えたこと（ あなたが学べるように ） エージェントは、あなたのドキュメントのバグをマシンの速度で受け継ぐ。 リファレンスドキュメントの古くなった 1 行が、人間が気づく前に複数のチケットへ伝播しました。私たちの修正策は より良いモデルとは関係なく、新しい習慣でした 。セッションがおかしくなったら、それを修正し、何が自分を誤らせたのかを問い、そのドキュメントを直す。一度きり 5 分をかけるほうが、毎週 5 分を失うよりましです。 自信ありげな中途半端な答えは、間違った答えよりコストが高い。 どのモデルアップグレードよりも役立ったステアリングルールが 1 つあります。エージェントは結論を述べる前に、競合する仮説を検証して排除しなければならない、というものです。さらに算術・アラーム状態・重複についての自動チェックによって、以前は人間がレビューで捕まえなければならなかったカテゴリまるごとのエラーが取り除かれました。人々が信頼するのは、自分で検証できる出力であって、正確さについての主張ではありません。 簡潔さが信頼を築く。 初期のエージェントは、ステップごとの作業をすべて顧客に見えるスレッドへ投稿していました。内容は正確でしたが、体験としてはノイズが多いものでした。今では、見えるスレッドには短い投稿を 1 つだけ、詳細はすべてワークログに送っています。パートナーチームはエージェントを、その最良の調査ではなく、その最悪のコメントで評価するのです。 自律性に単一の設定は存在しない。 ある 1 週間で、私たちはエージェントを 権限付与と抑制の両方向で 修正しました。「コードレビューを作成する許可をいちいち求めるのをやめろ。そのレビュー自体が承認だ」と、「チケットを解決したり深刻度を変えたりするな。それをやるのは人間だけだ」です。すべてのアクションにはそれ専用のルールが必要であり、エージェントのステアリングファイルはそれらのルールの一覧なのです。 セキュリティはプロンプトだけでなく、インフラから生まれる。 すべての無人セッションは、ロールの許可リスト（allowlist）を通じてデフォルトで ReadOnly になり、Admin 権限のリクエストはエラーを返します。各認証情報は 1 セッションのために発行され、エージェントが宣言したタスクにスコープが絞られるため、セッションは自分がリクエストした API しか呼び出せません。 これからどこへ向かうのか 今日、エージェントはトリアージを行います。そしてますます、修復も行うようになっています。修正のためのコードレビューやしきい値のチューニングを、同じハーネス上で、必須の人間レビューを経る形でドラフトを作成します。そしてシステム全体が markdown、MCP サーバー、そして素の Kiro CLI でできているため、私たちが自分たち自身のために行うすべての改善は、 私たちが提供する製品にも関係します 。 オンコールのローテーションは今も存在しますが、仕事は変わりました。もはや午前 2 時 33 分に調査を始めるのではなく、午前 2 時 46 分に完了した調査をレビューするのです。オンコールエンジニアのポケベルは、エージェントがすでに行った仕事のための意思決定キューになりつつあります。 Swami Sivasubramanian 氏によるフロンティアチームに関する記事 は、開発チームにとっての第一歩として「エージェントのコンテキストに投資する」ことを挙げています。私たちのチケットキューは、オペレーションのためにエージェントに投資する 1 つの例です。 これがフロンティアエンジニアの新しい生活の 1 日目であり、まだ続きがあります。

本記事は「 Continuous Prompt Evaluation: How We Use LLM Judges and Live Signals to Improve Kiro Agent Quality 」を翻訳したものです。 課題: システムプロンプトの挙動は予測が難しい プロンプトの挙動を網羅的に検証するのは困難です。システムプロンプトは、モデル・ツール・コードベース・タスク・ユーザーのあらゆる組み合わせにまたがって動作しますが、どんなテストスイートでもそれをすべてカバーすることはできません。単独で見れば妥当に思える指示が、プロンプトの作成者が想定していなかったケースで意図しない挙動を引き起こすことがあります。また、あるシナリオを改善する変更が、別のシナリオを悪化させることもあります。 プロンプトの陳腐化（staleness）は、この広範な問題の一例にすぎません。ある指示は、すでにまれで観測しにくい問題を引き起こしているかもしれませんが、新しいモデルがその指示をより厳密に守るようになると、より明確に有害なものになります。新しいツール、ワークフロー、ユーザーの利用パターンも、同じ潜在的な欠陥を表面化させることがあります。 ベンチマークは引き続き重要な品質シグナルですが、日々の開発業務で現れるすべての挙動を捉えることはできません。私たちに必要だったのは、実際のワークフロー上で問題を検出し、繰り返し現れるパターンを分類し、それをプロンプトの指示までたどり、モデルや利用状況の変化に合わせて修正を検証する仕組みでした。 システムの全体像 本記事は、人手で作成されたシステムプロンプトや設定の変更を評価することに焦点を当てています。自動的なトラジェクトリマイニング、変更の自動生成、ハーネス全体の自己改善については扱いません。このワークフローは、ベンチマーク結果と、社内の開発者による数千件の Kiro との会話を LLM で分析した結果を組み合わせ、タスク完遂・検証・ツール利用における改善機会を特定します。以下の 4 つのステージからなります。 診断（Diagnose） : 頻度の高い不満カテゴリを特定し、それをプロンプトの指示までたどる 設計（Design） : 分離して評価できるよう、狙いを絞ったプロンプト変更を設計する テスト（Test） : 社内トラフィック上で、統制されたコホートに対して変更をテストする 評価（Evaluate） : 各コホートを LLM ジャッジで評価し、不満や挙動品質の問題の変化を測る 図 1: プロンプト評価の 4 ステージのサイクル。プロンプト・ユーザーの挙動・モデルの能力が変化するのに合わせて繰り返す。 4 ステージのプロンプト評価サイクル 上の図は、以下で説明する 4 つのステージをまとめたものです。プロンプト・ユーザーの挙動・モデルの能力が変化するたびに、このサイクルを繰り返します。 1. 診断（Diagnose）。 現在の社内トラフィックにジャッジを実行し、繰り返し現れる不満パターンを特定・分類します。そのうえで、頻度の高いクラスタごとに、原因となっているプロンプトの指示や、欠けている指示までたどります。たとえば、繰り返し現れる「タスクが未完了」という不満は、エージェントに対して計画を実行するのではなく説明するよう促していたガイダンスに起因していました。 2. 設計（Design）。 診断された問題に対して、狙いを絞った変更候補を作成します。候補は多くの場合、安全性・検証・トーン・挙動のいずれかに対応するもので、各候補はテスト前に、意図する挙動とリグレッションのリスクを明示します。 3. テスト（Test）。 候補をコントロール（対照群）と、分離したコホートで比較します。有用な場合には、相互作用が見えてくる可能性のある「候補を組み合わせたコホート」でも比較します。実験の設計とサンプルサイズによって、その結果が方向性を示すだけのものか、より広い結論を支持できるものかが決まります。 4. 評価（Evaluate）。 同一の LLM ジャッジのルーブリックを各コホートに適用し、不満率と挙動品質の問題の発生率を比較します。得られた証拠にもとづいて、各候補を採用（ship）・修正（revise）・却下（reject）します。 LLM-as-judge: 重要なものを測る 私たちは、社内の会話を 15 の挙動ディメンションでスコアリングする評価フレームワークを構築しました。たとえば以下のようなものです。 タスクの完遂度（Task completeness） 主張の正確性（Claim accuracy） （エージェントは断定する前に検証したか？） コードスタイルの遵守（Code style adherence） 失敗し続けているアプローチの認識（Recognition of repeated unsuccessful approaches） 破壊的アクションのフラグ付け（Destructive-action flagging） ツール利用の適切さ（Tool use appropriateness） 検証の挙動（Verification behavior） （テストの実行、コンパイルの確認） このジャッジは、会話からの明示的な証拠を必要とします。すなわち、修正・不満・放棄されたタスク・確認などです。曖昧な会話はどちらのバリアントにも不利に数えないことで、比較の一貫性を保ち、過剰な偽陽性（false positive）の判定を避けるために保守的な設計にしています。 図 2: LLM ジャッジが会話を読み取る仕組み。左にチャットのやり取り、中央に不満の判定基準、右に分類された挙動品質の出力が並ぶ。 図中に示したジャッジのプロンプトは、あくまで最小限の説明用の例であり、実際の評価で使われているものではありません。 ジャッジは主に 2 つのシグナルを測定します。 明示的な不満（Explicit dissatisfaction）: ユーザーは明確に不満を表明したか、会話を放棄したか、あるいはエージェントの作業をやり直したか？ これは会話中の明示的なフィードバックからのみ推定され、ツールの結果が示唆するものやアンケートのスコアからは推定しません。 挙動品質の問題（Behavioral quality issues）: エージェントは 15 の品質基準のいずれかを満たさなかったか？ 例としては、コードを先に読まずに主張する、タスクを完遂する前に止まる、プロジェクトの既存パターンを無視する、などがあります。 両方のメトリクスは、コントロール群とトリートメント群で同一のルーブリックを用いるため、同じ評価設計の中で構成どうしを一貫して比較できます。 図 3: 会話はストレージからコホートごとのバケットを経て不満ジャッジへ流れ、ジャッジはコホートごとの不満率と挙動問題の件数を出力する。 A/B 実験のインフラ プロンプトの変更をリリースする前に、社内トラフィック上で構成どうしを別々のコホートで比較します。これらの実験では、サービスが、対象となる社内開発者を、ユーザー識別子の決定的なハッシュを使って安定的なユーザーバケットに割り当てます。この割り当ては、観測された会話の結果とは独立しています。各バケットは、ある実験において 1 つのプロンプトバリアントに対応します。 ジャッジのパイプラインは、記録された実験の割り当てにもとづいて会話を分析し、すべてのコホートに同一のルーブリックを適用します。安定的な割り当てはプロンプト実験内のコホート選択を統制しますが、ライブトラフィックにおけるすべてのバイアスや相互作用の要因を取り除くわけではありません。正確な割り当てとサンプルサイズは実験ごとに異なるため、結論の強さはその比較で得られた証拠に依存します。分離された小さな候補コホートは、本番への影響を精密に推定するものというより、方向性を示す診断（directional diagnostics）にとどまります。 ある迅速に進めた社内デプロイでは、安全性・検証・トーン・挙動の 4 カテゴリにわたる 27 個のプロンプト変更候補をスクリーニングしました。安定したコントロールを、分離した候補コホートと、候補を組み合わせたコホートと比較しました。小さな分離コホートは、起こりうるリグレッションを局在化させるための方向性の診断であって、個別に影響を推定できるだけの検出力を持つものではありませんでした。悪化を示した候補は修正または削除し、組み合わせたコホートや、より大規模な追試の比較によって、より広い結論を支持しました。 ジャッジのパイプラインは会話の結果をスコアリングするため、ユーザーから見える設定の選択肢どうしを比較することもできます。私たちはこれを使って、デフォルトの reasoning effort レベルを評価しました。コード修正やデバッグといった一般的なタスクでは、より高い effort レベルで改善が見られました。reasoning effort レベルの設定について詳しくは、 reasoning effort のドキュメント を参照してください。 直近サイクルの結果 以下の数値は、社内の実験レベルの比較で観測されたデルタ（差分）です。これらは今回の評価サンプルを説明するものであり、普遍的な本番効果の推定値として読むべきではありません。 初回のモデル＆プロンプト実験 Kiro CLI （最初に評価したモデル＆プロンプト構成）: 明示的な不満シグナル: 5% 減少 挙動品質の問題: 32% 減少 タスク完遂の問題: 10.6% 減少 Kiro IDE （最初に評価したモデル＆プロンプト構成）: 挙動品質の問題: 20% 減少 タスクの未完了配信: 21% 減少 失敗し続けているアプローチ: 36% 減少 スタイルの不一致: 54% 減少 より新しいモデルでの再検証 再検証は、初回の実験とは別の問いに答えるものです。初回の実験は、最初に評価したモデル＆プロンプト構成に対するプロンプト変更の効果を測りました。再検証は、モデルをアップグレードした後でも同じ変更が依然として役立つかどうかをテストします。 より新しいモデル＆プロンプトのベースラインは、同じルーブリック (評価基準表) のもとですでに挙動品質の問題が少なく、プロンプトが上乗せできる余地（headroom）が小さくなっていました。したがってここでの改善幅が初回サイクルより小さいのは設計上の想定どおりであり、リグレッションではありません。その難しいベースラインに対してさえ、同じプロンプト変更は依然として両方のシグナルを正しい方向へ動かしました。挙動品質の問題をさらに 4% 減らし、明示的な不満を 2.6 パーセントポイント改善しました。私たちはこの結果を、モデルアップグレード後も変更が依然として役立つという方向性の確認であって、精密な本番推定値ではない、と読んでいます。 より新しいモデルは、一部の指示をより文字どおりに守るようにもなりました。特に低い effort レベルでその傾向が顕著で、以前のモデル向けにチューニングされたガイダンスが、あらゆるケースでそのままきれいに引き継がれるわけではありませんでした。そこで私たちは、モデルアップグレードのたびにそれを新しいモデル＆プロンプト構成として扱います。既知の不満ケースを再現し、過去にうまくいったケースをリグレッションチェックとして使い、挙動品質・不満・リグレッション・効率を測定し、ロールアウト前に再チューニングします。 自前のエージェントシステムを評価するチームへの示唆 ライブ利用の評価はベンチマークを補完する。 標準的なベンチマークは引き続き有用です。社内フィードバックは、実際のユーザーセッションからシステムプロンプト改善の機会を明らかにします。そうしたセッションには、標準的なベンチマークが同時には捉えないディメンションがしばしば含まれます。たとえば、ユーザー固有のワークスペースのコンテキスト、実際の本番サービスとのやり取り、別々の作業セッションをまたいで再開される会話、その他の現実世界のノイズなどです。 方向性のスクリーニングには分離コホートを使う。 小さな候補コホートはリグレッションの局在化に役立ちますが、より広い結論を導く前には、組み合わせたコホートと、十分な検出力を持つ追試の比較が必要です。 プロンプトの効果はモデル依存である。 同じ変更が、あるモデルバージョンでは挙動品質の問題を 32% 減らし、別のバージョンでは 4% 減らしました。モデルをアップグレードするたびに再検証のパスが必要です。 不要になったガイダンスは廃止する。 最も大きな改善のいくつかは、古くなった制約を取り除くことから生まれます。行数の上限や、非推奨になったツールの回避策などです。プロンプトはシンプルなほうが、モデルの挙動と整合させ続けるのが容易になります。 これが Kiro ユーザーにとって意味すること これらの変更によって、Kiro はタスク全体を完遂し、うまくいっていないアプローチを軌道修正し、プロジェクトの既存のコードスタイルに従う可能性が高くなります。また、次に進む前に変更がコンパイルできてテストが通ることを検証し、リスクのあるアクションの前には確認を取りつつ、安全な作業はそのまま進めるようにもなります。私たちはこのプロンプト評価を、プロンプトとモデルが変化するたびに繰り返し行い、デプロイ前に更新を検証しています。

「金融リファレンスアーキテクチャ日本版」は、2022 年 10 月に v1.0 を公開して以来、多くの金融機関のお客様 や パートナー様 にご利用いただいてきました。勘定系や顧客チャネル、データ分析基盤といった金融サービスのワークロードについて、AWS 上で FISC 安全対策基準を踏まえたシステム設計を検討する際のガイドやサンプルを提供しています。 今回、その内容を刷新した v2 を GitHub 上で リリース しました。v2 では、コンテンツをエンジニアが読むためだけのものから、エンジニアと AI エージェントが同じように読んで使えるものへと作り直しています。 金融リファレンスアーキテクチャ日本版 の 概要 「金融リファレンスアーキテクチャ日本版」は、金融システムの「高い信頼性が必要なミッションクリティカル領域」の維持と強化につなげていただくためのアセットです。セキュリティとガバナンスの確保、レジリエンスの強化、モダナイゼーションの加速、コンプライアンスへの対応といった、日本の金融機関のエンジニアが向き合う作業を支援するコンテンツで構成されています。 金融リファレンスアーキテクチャ日本版 v2 での進化 金融リファレンスアーキテクチャ日本版 v2 は AIエージェントフレンドリーなコンテンツ提供形態へと刷新し、そのナレッジを Agent Skills (エージェントスキル) の形式で提供します。エンジニアの皆様 に加えて、皆様が利用する AI エージェント や 生成AIツールからも扱えるナレッジへと進化しました。 v2 での主な変更点は次のとおりです。 Agent Skills を中核に据えた提供形態への刷新 31 のスキルをカテゴリ別に収録 サイバーレジリエンスと FSI Lens for FISC のスキルを追加 Webアプリケーションツール「GameDay Plan Generator 」の公開 Agent Skills を中核とした提供形態への刷新 v2 で最も大きく変わったのは、ナレッジの提供形態です。金融システムに求められるセキュリティ、可用性、コンプライアンスの知見を、Agent Skills というオープン標準のフォーマットを利用して提供しています。Agent Skills は、生成 AI を用いた開発ツールが解釈できる形式で手順や設計方針を記述する 仕様 です。同じコンテンツを、設計を検討するエンジニアが読むだけでなく、そのエンジニアが日々使う AI エージェントにも渡して利用できます。 この形式を選んだ背景には、金融 IT の開発現場で AI エージェントや生成 AI ツールの利用が広がってきたことがあります。v2 では、想定する利用者に、金融 IT のエンジニアやアーキテクトに加えて、それらの担当者が利用する AI エージェントや生成AIツールを据えました。設計原則やベストプラクティスを人が読んで理解するだけでなく、設計や開発を支えるAIエージェントにも同じ知識を渡すことで、人と AI の双方の能力を広げることを目的としています。 これにより、構成の検討や設計レビューの場で、AI エージェントが FISC 安全対策基準やリファレンスアーキテクチャを踏まえた回答を返せるようになり、検討の出発点を素早く用意できます。 31のスキルをカテゴリ別に収録 v2 では、v1 で扱ってきたワークロードに加えて、AWS を利用する金融 IT エンジニアの日々の作業を支援するナレッジを含め、現時点で 31 のスキルを収録しています。金融のビジネスワークロードから、それらを支える共通基盤、生成 AI、セキュリティ、情報収集の支援までを一つのカタログにまとめています。主なカテゴリと代表的なスキルは次のとおりです。 コンテンツカテゴリ 主な Agent Skills 金融ワークロード 勘定系（Banking Core）、モバイルバンキング、コンタクトセンター、Capital Marketのオーダー管理、マーケットデータ配信、保険データ分析、クレジットカードイシュア 共通基盤 ガバナンスベース、ハイブリッドクラウド（AWS Outposts）、メインフレーム連携、金融オープン API（FAPI）、データレイク 生成 AI 生成 AI プラットフォーム、生成 AI ユースケース セキュリティとレジリエンス サイバーレジリエンス、ランサムウェア対策、FISC 安全対策基準からのAWS Security Agent セキュリティ要件定義生成、AWS Payment Cryptography 導入ガイド、AWS 操作のセキュリティガード Well-Architectedフレームワーク FSI Lens for FISC 情報収集の支援 AWS 新機能やブログ、セキュリティ情報の取得、日本銀行の統計、金融庁の公表情報、国内のセキュリティ注意喚起の取得 業務支援と汎用ツール お客様固有のコンテキスト管理、Working Backwards によるプロダクト企画、MCP ツールの呼び出し、スキル定義ファイル (SKILL.md) のドキュメントファイル化 全 31 スキルの一覧は、リポジトリの スキル一覧 で確認できます。 v2 で新たに加えたコンテンツ サイバーレジリエンスとランサムウェア対策の スキル 近年のサイバーレジリエンスとランサムウェア対策への関心とニーズの高まりを受けて、レジリエンスのスキルを充実させました。サイバーレジリエンスのスキルでは、論理的に隔離したバックアップやアカウントをまたいだ復旧、ネットワークの自動隔離といったアプローチを扱います。ランサムウェア対策のスキルは、保護、検知、対応、復旧、そして組織としての対応という 5 つのフェーズで整理し、それぞれをサブスキルに分けて提供します。インシデントのどの段階を検討しているかに応じて、必要なスキルだけを AI エージェントに読み込ませられます。 FSI Lens for FISC のスキル FSI Lens for FISC は、AWS Well-Architected Framework を金融向けに拡張し、FISC 安全対策基準に沿って設計を点検するための評価軸 (レンズ) です。運用上の優秀性、セキュリティ、信頼性の 3 本の柱で構成し、各ベストプラクティスには FISC の実務基準の番号を対応づけています。v2 では 2025 年 3 月に公開された第 13 版を元にスキルとして提供し、AIエージェントに渡してレビューに活用することができます。今後、2026 年 3 月に公開された第 14 版をもとにした更新も予定しています。 Webアプリケーションツール GameDay Plan Generator 金融リファレンスアーキテクチャ日本版 v2 は、「Agent Skillsを中心としたAIエージェントフレンドリーなナレッジを提供する」とお伝えしましたが、コンテンツはそれだけにとどまりません。v2 を構成するコンテンツの1つとして、障害対応訓練の計画立案を支援する「 GameDay Plan Generator 」を公開しました。レジリエンスは設計しただけでは十分とは言えず、それを試す訓練があってこそ確かなものになります。このツールは、その訓練の準備にかかる手間を軽減することを狙ったものです。 使い方はシンプルで、AWS CloudFormation テンプレート または 構成図 を渡すだけで、次のものをまとめて生成します。 障害シナリオの一覧と、シナリオごとに「なぜそれを試すのか」という理由 AWS Fault Injection Service の実験テンプレート 訓練中に監視すべき観測ポイントの定義 検知、復旧、影響把握、コミュニケーションの 4 つの軸からなる評価基準 シナリオ一覧やタイムラインを載せた HTML のダッシュボード 生成した結果はダッシュボード上で確認でき、対話しながらシナリオを調整できます。本ツールの特徴は、 Amazon Bedrock を使って、ルール定義だけではカバーが困難な連鎖的な障害や単一障害点を分析し、シナリオを補強する点です。Bedrock を利用できない環境では、ルールベースの生成に切り替えて動作します。訓練計画の初版を短時間で用意できるため、設計から訓練までを一続きの流れとして支える道具として活用いただけます。 まとめ v2 のコンテンツ種類 と GitHub リポジトリ v2 は現時点で、以下の種類のコンテンツを提供しています： 金融ワークロードにおける設計上のポイントやリファレンスアーキテクチャを記述した、ガイダンスとしてのAgent Skills AWSを利用する金融ITエンジニアの日々の作業を支援する、ツールとしてのAgent Skills 特定の用途における金融ITエンジニアを支援する、Webアプリケーション また、v2からは、v1と異なり、複数のリポジトリで そのコンテンツを提供する形になりました。 GitHub リポジトリ： aws-samples/sample-fsi-reference-architecture-jp Agent Skills を提供します。リポジトリをクローンすれば、収録したスキルをそのまま参照でき、対応する開発ツールから AI エージェントに読み込ませることもできます。あわせて、v2のコンテンツ全体を紹介するポータルとしての役割も持ちます。 GitHub リポジトリ： aws-samples/sample-fsi-reference-architecture-jp-gameday-plan-generator   Webアプリケーションツール「GameDay Plan Generator」を提供します。このように、コンテンツによっては個別のリポジトリで公開します。 いずれのコンテンツも v1 と同様に MIT-0 (MIT No Attribution) ライセンスのもとで公開しており、エージェントスキルの多くは日本語と英語の両方で用意しています。なお、収録しているサンプルコードは設計や動作を検証するためのもので、本番環境でそのまま利用することは想定していません。 おわりに 金融リファレンスアーキテクチャ日本版 v2 は、今後も継続的な拡充を予定しています。まずはリポジトリをクローンし、お手元の AI エージェントに関心のあるスキルを読み込ませてみてください。ぜひ、ご質問やフィードバックをGitHub の Issue などでお寄せください。 本ブログ記事は、AWS のソリューションアーキテクト 松原武司 が執筆しました。

本記事は、2026 年 8 月 18 日に Brian Beach が公開した「 Close the laptop, keep the agent: building with cloud sessions 」を翻訳したものです。 Kiro は cloud sessions（preview）をリリースしました。これは、自分のマシンで AI エージェントを動かすときにずっと引っかかっていた 1 つの問題、つまりマシンそのものに縛られる問題を解決してくれます。cloud sessions を使えば、エージェントはラップトップではなくクラウドのサンドボックス上で動きます。エージェントはリポジトリをクローンし、作業をこなし、席にいるかどうかに関係なく走り続けます。ふたを閉じても、電車に飛び乗っても、まったく別のマシンに乗り換えても、セッションには何も影響ありません。Kiro Web を使ったことがある方には、この感覚は馴染みがあるはずです。今回新しいのは、これが CLI と IDE にも広がった点です。CLI、IDE、ブラウザーのどれからでも様子を確認して作業を再開できます。すべてが同じ場所に存在する 1 つのエージェントだからです。 本記事では、実際のタスクを最初から最後まで見ていきます。すでに顧客、商品、注文の機能を備えた既存の EC アプリに、決済 API を追加するタスクです。私は Kiro CLI から作業を進めます。ここが自分にとっていちばん落ち着く場所だからです。ただし、ここで紹介する内容は IDE の Agent Focus Mode でもまったく同じように動きます。同じハーネス、同じエージェント、同じセッションで、好きな画面 (サーフェス) を選べます。 まずは有効化から 機能を探しに行く前に少しだけお知らせです。IDE では、Agent Focus Mode を開くとサイドバーに Cloud Session セクションが表示されます。CLI では、 --cloud フラグを付けて起動します。 組織で IAM Identity Center を使っている場合は、Kiro プロファイルを設定した AWS アカウントで、管理者が Settings > Kiro Settings から Cloud Sessions (Preview) を有効化します。以前に Kiro Web (Preview) を有効化していた組織では、Cloud Sessions もすでに有効化されているため、追加の操作は不要です。この 1 つのトグルで、Kiro Web、Agent Focus Mode、CLI の cloud sessions がまとめてカバーされます。詳細は Cloud sessions governance を参照してください。 AWS コンソールの Kiro Settings 画面で Cloud Sessions (Preview) を有効化する。 スイッチ 1 つで準備完了です。 設定について一言 すでに触れたとおり、セッションはクラウドのサンドボックスで動きます。つまり、ローカルマシンの中まで見に行って設定を取ってくることはできません。たとえば、エージェントスキルがそうです。 Kiro をローカルで実行すると、設定は 2 つの場所から読み込まれます。ワークスペース側の .kiro/skills と、個人プロファイル側の ~/.kiro/skills/ です。cloud sessions では、ワークスペースのスキルはリポジトリの中にあるので一緒に付いてきます。しかし、ローカルプロファイルのスキルは付いてきません。代わりに、セッションはクラウドプロファイルで定義したスキルを使います。クラウドプロファイルは Kiro Web で管理します。まだクラウドプロファイルを設定していなければ、まず app.kiro.dev にアクセスして、そこでスキルを設定してください。私のプロファイルには「Python Coding Standards」というスキルを設定してあるので、どのマシンから始めてもエージェントがこのスキルを適用してくれます。 Kiro Web の Skills 設定画面。クラウドプロファイル側でスキルを管理する。 ですから、クラウドでの作業に必要なスキルは、クラウドプロファイルに登録しておきましょう。ステアリングファイル、カスタムエージェント、その他 .kiro/ フォルダーに置くものについても同じです。 CLI を立ち上げてリポジトリを取り込む cloud session の起動は、フラグ 1 つで済みます。 kiro-cli chat --cloud セッションが起動したら、 /repo を使って作業したいリポジトリを Kiro に伝えます。リポジトリは 1 つでも複数でも指定できるので、変更が複数のプロジェクトにまたがるときに便利です。今回は GitHub を使っていますが、GitLab も利用でき、同じセッション内でプロバイダーを混在させることもできます。ここでは brianjbeach/fastapi-demo を選びます。 CLI の /repo コマンドで brianjbeach/fastapi-demo リポジトリを選択する。 Kiro がリポジトリをサンドボックスにクローンし、開発の準備が整います。 プロンプト（音声機能の力を少し借りて） 何をしたいかを伝えましょう。プロンプトはこちらです。 EC アプリケーションに決済 API を追加してください。顧客が保留中の注文に対して支払えるようにします。決済には、金額、支払い方法、タイムスタンプを記録します。支払いが成功したら、注文のステータスは confirmed に遷移するようにしてください。 これを全部タイプする代わりに、新しい音声機能を使いました。 /voice と入力してから、あとは声に出して話すだけで、Kiro が文字起こししてくれます。詳しくは voice docs で確認できます。キーボードを叩き続けなくても、意図をまるごと 1 段落分プロンプトに流し込める、なかなか気の利いた方法です。 CLI で /voice コマンドを使い、音声プロンプトを文字起こしする様子（鮮明な動画は 原文記事 を参照）。 ここからが良いところです。エージェントはクラウドで走り始めたので、私は自由の身です。エージェントが働いている間、私はジムに行ってこようと思います。 というのは冗談で、実はジムには行きません。SNS を延々とスクロールして時間を溶かします。どちらにしても要点は変わりません。もう何もラップトップに縛られていない、ということです。 どこからでも様子を確認 セッションはクラウド上にあるので、どのクライアントからでも様子を確認できます。ちょっと Kiro Web に行って、進み具合を見てみましょう。 Kiro Web から cloud session の進捗を確認する。 ここが本当に自分のワークフローを変えたところです。セッションはマシンから完全に切り離されています。ラップトップのふたを少しだけ開けたまま「スリープしないでくれ」と祈りながら廊下を歩く必要はもうありません。長時間ジョブを生かしておくためだけに、空いているターミナルで caffeinate を走らせておく必要もありません。「このパソコンには触らないで」の付箋を貼る必要もありません。作業はクラウドで行われ、そのままクラウドに残り、私がまったく別の場所にいる間もコツコツと進んでいきます。 続きから再開する 作業に戻る準備ができたら、いちばん手近なクライアントからまったく同じセッションを再開します。 CLI からは、最初に起動したときと同じコマンドを使います。 kiro-cli chat --cloud --resume あるいは IDE の Agent Focus Mode からも再開できます。cloud sessions パネルに、実行中および過去のセッションが一覧表示されます。そこからクリック 1 つでこのセッションに戻り、何が作られたかのサマリーを確認できます。 IDE の Agent Focus Mode で cloud sessions パネルから同じセッションを再開する。 完成した成果物はこちらです。新しい payments.py 、モデルとストアの更新、 POST /payments/ エンドポイント、そして支払い成功後に confirmed へ遷移する注文。読み解くのに苦労するコードの山ではなく、そのままレビューできる PR です。私が席を外して別のことをしていた間に、頼んだとおりのものが仕上がっていました。 まとめ cloud sessions は、セッションの起動方法としてはささやかな変化ですが、作業の感覚としては大きな変化をもたらします。エージェントは、ラップトップで面倒を見続けるプロセスではなくなり、CLI、IDE、Web、モバイルアプリのいずれからも触れる、クラウドでただ動き続ける存在になります。ある場所で起動し、別の場所で確認し、たどり着いたどこででも仕上げる。そんな流れが可能です。 管理者に AWS コンソールで cloud sessions を有効化してもらい、クラウドプロファイルのスキルを整えたうえで、 kiro-cli --cloud で試してみてください。実際のタスクを起動したら、ラップトップを閉じて、その気持ち良さを味わってみてください。詳細は cloud sessions docs を参照してください。Cloud Sessions は US East (N. Virginia) の us-east-1 リージョンでのみ利用できます。 翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 2026 年 8 月 21 日 に公開された「 Increase your cluster density with Memory Tiering in Amazon Elastic VMware Service 」を翻訳したものです。 Amazon Elastic VMware Service (Amazon EVS) で Memory Tiering を使ってクラスター密度を高めると、AWS インフラのコストを削減できます。Amazon EVS は VMware Cloud Foundation (VCF) 9.0 および 9.1 をサポートするようになりました。VMware Cloud Foundation (VCF) 9.0 で導入された Memory Tiering は、高速な NVMe デバイスを DRAM に加えて第 2 のメモリ階層として使用する ESX の新機能です。現在利用できる 2 つの Amazon EVS インスタンスタイプ (i4i.metal と i7i.metal-24xl) の両方で Memory Tiering を有効化できます。本記事では、Memory Tiering とは何か、クラスターのサイジング方法がどのように変わるか、そして Amazon EVS 上で稼働する VCF 9.1 デプロイで Memory Tiering を有効化・無効化する方法を詳しく説明します。 VCF 9.1 における Memory Tiering の概要 Memory Tiering は ESX カーネルに統合されたホストレベルの機能で、ハイパーバイザーに 2 つのメモリ階層を提供します。物理ホストの DRAM で構成される Tier 0 と、同じホストの NVMe で構成される Tier 1 です。メモリ管理層の階層化アルゴリズムは両方の階層のページアクティビティを監視し、頻繁にアクセスされる (ホットな) ページを DRAM に保持し、アクセス頻度の低い (コールドな) ページを低速な NVMe 階層に移動します。ホストのメモリ消費量が DRAM 容量の約 80% に達すると、コールドページの NVMe への階層化が始まります。ページの分類はアクセスの新しさとアクセス頻度の両方に基づくため、ワークロードが実際に使用するワーキングセットは DRAM に保持され、アイドル状態のメモリは低速な階層に置かれます。 Memory Tiering をメモリスワップと混同しないでください。スワップはランダムにページを選択し、ゲストストレージとデバイスを共有することが多い仕組みです。一方 Memory Tiering は専用の直接接続 NVMe とページエージング技術を使用し、極端な負荷時の安全弁としてだけでなく、予測可能なパフォーマンスを提供します。階層化の対象は VM のメモリページのみで、カーネルメモリは対象になりません。 VCF 9.1 では、Memory Tiering は vSphere Configuration Profiles (Desired State Configuration とも呼ばれます) を使用して構成し、クラスター内のすべてのホストに一貫して適用されます。ホストごとの ESX CLI コマンドやスクリプトを維持する必要はありません。VCF 9.1 では Tier 1 のソフトウェアミラーリングも追加され、追加の RAID ハードウェアなしで階層化されたメモリの冗長性を確保できます。 Amazon EVS が Memory Tiering をサポートする仕組み Amazon EVS は、お客様の Amazon Virtual Private Cloud (Amazon VPC) 内でベアメタルインスタンス上に VCF を直接実行します。Memory Tiering は、Amazon EVS が現在提供する 2 つのインスタンスタイプ (i4i.metal と i7i.metal-24xl) の両方でサポートされます。どちらのインスタンスタイプの NVMe も、階層化によって生じる持続的な書き込みアクティビティに必要な書き込み耐性を備えているため、追加のドライブ適格性確認は不要です。 Amazon EVS のホストハードウェアと一般的なオンプレミスホストには、アーキテクチャ上の重要な違いがあります。オンプレミスでは、Memory Tiering 専用の NVMe デバイスをホストに追加できます。Amazon EVS では、両方のインスタンスタイプのローカル NVMe を、デプロイ時に vSAN が使用します。ドライブを Memory Tiering に使用するには、まず vSAN から取り除いてからメモリ階層に割り当てる必要があります。Amazon EVS はハイパーコンバージドストレージアーキテクチャを使用しているため、Memory Tiering に割り当てる容量は vSAN から取り除く容量になります。NVMe を Memory Tiering に使うか vSAN に使うかのトレードオフについては、次のセクションで詳しく説明します。 Memory Tiering がクラスターサイジングに与える影響 クラスターのサイジングで物理メモリが制約になる場合、Memory Tiering を使うとホストを追加せずにクラスターの実効メモリ容量を増やせます。Memory Tiering によってサイジングの計算や Amazon EVS でデプロイするホスト数がどう変わるかを理解しているかどうかが、計画的なデプロイと過剰コミットになったデプロイの分かれ目です。 2 つの階層が組み合わさって実効メモリになる仕組み 2 つの階層を組み合わせることで実効メモリが得られます。まず必要な数値は DRAM の総量、つまり高速な Tier 0 メモリです。次に必要な数値は、階層化に割り当てる NVMe デバイス、つまり Tier 1 メモリになる容量です。この 2 つの数値を組み合わせた最終的な数値が実効メモリで、ハイパーバイザーが VM に提供できる総量、すなわち DRAM と NVMe 階層を合計した値です。 合計に追加される NVMe デバイスの量は、1 つのホスト設定である DRAM-to-NVMe 比率で決まり、これはティアサイズの割合として表されます。Amazon EVS の VCF 9.1 では、デフォルトの 1:1 比率 (ティアサイズ 100%) が使用されます。1:1 比率を使用すると、NVMe 階層は DRAM と同じ量を提供します。DRAM が 1 TB のホストで 1:1 比率を使うと、NVMe 階層が 1 TB 追加され、実効メモリは 2 TB になります。これがデフォルト比率で実効メモリを 2 倍にする仕組みです。 以下の表は、ホストあたり 1 TB の DRAM を持つ 4 ホストクラスターの例です。計算をわかりやすくするために丸めた数値を使用しています。実際に環境をサイジングする際は、お使いのインスタンスタイプの実際の DRAM 容量に置き換えてください。 指標 Memory Tiering なし Memory Tiering あり (1:1 比率) DRAM (Tier 0) 4 TB 4 TB NVMe 階層 (Tier 1) 0 TB 4 TB 実効メモリ (Tier 0 + Tier 1) 4 TB 8 TB (DRAM の 2 倍) 表 1: デフォルトの 1:1 比率によるクラスターの実効メモリ (4 ホストクラスターの例) 重要な制約はアクティブメモリ アドレス可能なメモリを 2 倍にしても、適切な分析なしにすべてのワークロードを 2 倍にできるわけではありません。サイジングは、VM が現在使用しているページを示すアクティブメモリの指標に基づいて行います。アクティブメモリを、アイドルメモリを含む消費メモリと混同しないでください。ほとんどのワークロードでは、アクティブメモリは消費メモリの 10% から 30% の範囲に収まります。良好なパフォーマンスを得るには、ワークロードのアクティブメモリを DRAM 階層内に収める必要があります。Broadcom の ガイダンス では、階層化導入前のアクティブメモリが既存の DRAM 容量の 0% から 50% の範囲にあるホストやクラスターを特定し、機能を有効化した後もアクティブメモリを DRAM の約 50% 未満に保つことを推奨しています。 この目安を 4 ホストの例に当てはめてみましょう。階層化導入前のクラスターが消費率 80%、アクティブ率 20% で稼働しており、階層化後に VM 密度を 2 倍にしたとします。消費メモリは 3.2 TB から 6.4 TB に増加しますが、これは 8 TB の実効容量で吸収できます。アクティブメモリは 0.8 TB から 1.6 TB に増加し、これは 4 TB の DRAM 階層の 40% で、50% の目標値内に収まっています。この構成例では、アクティブメモリを DRAM 内に保ったまま、クラスターで VM を 2 倍収容できます。 指標 導入前 (ベースライン) 導入後 (VM 密度 2 倍) 消費メモリ 3.2 TB 6.4 TB アクティブメモリ 0.8 TB 1.6 TB DRAM に対するアクティブメモリの割合 20% 40% (目標値 50% 未満) 表 2: アクティブメモリが DRAM 内に収まる場合の統合の余地 Amazon EVS における vSAN のトレードオフ Amazon EVS では、この追加メモリは無償で得られる容量ではありません。vSAN はデプロイ時にすべてのローカル NVMe を確保するため、Memory Tiering に再割り当てするドライブはすべて vSAN データストアから取り除かれることになります。4 ホストの例では、ホストあたり 1 TB の NVMe をメモリ階層に移動すると、クラスターの vSAN 生容量が 4 TB 減少します。つまり、ストレージ容量とメモリ容量を交換していることになります。 機能を有効化する前に、vSAN に制約がないことを確認する必要があります。回収を予定しているドライブを失っても十分な空き容量とポリシー上の余裕が vSAN データストアにあるか、また完全なデータ退避後もストレージ容量がワークロードと可用性の要件を満たし続けるかを確認してください。クラスターの vSAN 容量にすでに余裕がない場合、ストレージの問題を解決するまでは Memory Tiering が適切な選択ではない可能性があります。ローカルストレージの減少による影響を抑えるために、 Amazon FSx for NetApp ONTAP のような外部ストレージを追加することもできます。 ガイダンス 別の設定を裏付けるアクティブメモリの履歴データがない限り、デフォルトの 1:1 DRAM-to-NVMe 比率を使用してください。NVMe 階層のサイズは DRAM と同等以上にする必要があります。 Memory Tiering が有効な場合はメモリオーバーコミットを使用しないでください。2 つの仕組みは互いに競合し、負荷がかかった際にパフォーマンスを低下させる可能性があります。 ページを NVMe 階層から取得する必要があるため、vMotion や DRS の操作にかかる時間は長くなります。ただし、移行中に稼働中の VM のパフォーマンスへの影響はほとんどありません。 本記事の前半で説明した、放棄する vSAN 容量を、サイジングを行うたびに必ず考慮してください。 Amazon EVS の VCF 9.1 デプロイで Memory Tiering を有効化する Amazon EVS で Memory Tiering を有効化する作業は 2 段階のプロセスです。まず NVMe デバイスを vSAN から回収し、次にクラスター全体に適用する Desired State Configuration のドラフトでメモリ階層を構成します。構成の適用時にホストがメンテナンスモードに入るため、これらの手順は通常無停止で実行できますが、スケジュールされたメンテナンスウィンドウ内で実施することをお勧めします。 前提条件 Amazon EVS (i4i.metal または i7i.metal-24xl) 上で稼働している VCF 9.1 デプロイ クラスターの構成プロファイルを管理する管理者権限 各ホストのメンテナンスウィンドウ中に自動化がワークロードをライブマイグレーションできる、vMotion 対応の VM 回収予定のドライブの完全なデータ退避を吸収できる、十分な vSAN の空き容量 ステップ 1: vSAN から NVMe ドライブを削除する 図 1: vSAN ディスク管理、ホストディスク表示 図 2: 削除する NVMe ディスクの選択 図 3: 完全なデータ退避を選択 図 4: ディスク削除の進行状況 図 5: vSAN 再同期のステータス 図 6: NVMe 削除後のディスクグループ ステップ 2: vSphere Configuration Profiles を有効化して Desired State を作成する 図 7: Configure タブの vSphere Configuration Profiles 図 8: リファレンスホストからの構成の作成 図 9: 事前チェックの結果 ステップ 3: ドラフトを作成して MEMTIER を構成する 図 10: ドラフトエディタの MEMTIER 設定 図 11: NVMe 構成設定 図 12: ホスト固有のデバイス選択 図 13: 構成の概要 ステップ 4 (オプション): ソフトウェアミラーリングを有効化する 冗長性を確保するには、ホストごとにプライマリのミラーとして 2 台目の NVMe デバイスを選択します。ホストごとに同等容量の NVMe デバイスが 2 台必要で、いずれも vSAN から回収したものを使用します。 ステップ 5: 事前チェック、適用、確認 図 14: 変更の適用と修復 図 15: ホストの修復の進行状況 図 16: Memory Tiering の容量を示すクラスターサマリー Amazon EVS の VCF 9.1 デプロイで Memory Tiering を無効化する Memory Tiering を無効化する作業は、有効化の手順を逆に行うものです。Desired State のドラフトで memtier 設定を無効にし、必要に応じて回収した NVMe デバイスを vSAN に戻してストレージ容量を復元します。有効化と同様に、修復中はホストがメンテナンスモードに入る必要がありますが、これらの手順は通常無停止で実行できます。スケジュールされたメンテナンスウィンドウ内で実施することをお勧めします。 ステップ 1: Desired State のドラフトで MEMTIER を無効化する Desired State > Configuration > Draft > Create Draft の順に進みます。MEMTIER を選択し、enable を FALSE に設定します。保存して事前チェックを行い、Apply Changes and Remediate を実行します。ホストは順番に修復されます。 ステップ 2 (オプション): NVMe ドライブを vSAN に戻す ストレージ容量を回復したい場合は、cluster > Configure > vSAN > Disk Management から解放された NVMe デバイスを vSAN のディスクグループに戻し、vSAN のリバランスを実行させます。 ステップ 3: 確認する クラスターの Summary タブで Tier 1 の容量が表示されなくなっていること、ドライブを戻した場合は vSAN の容量が復元されていることを確認します。 まとめ 本記事では、VCF 9.1 における Memory Tiering とは何か、ESX カーネルが自動管理する第 2 のメモリ階層として NVMe を提供する方法、そして Amazon EVS が i4i.metal と i7i.metal-24xl で Memory Tiering をサポートする仕組みを説明しました。デフォルトの 1:1 比率で実効メモリが 2 倍になる一方、アクティブメモリは DRAM 内に収める必要があるというサイジングの計算方法も確認しました。また、Amazon EVS 特有のトレードオフ、つまり vSAN がローカル NVMe を所有しているため、Memory Tiering に割り当てる容量は vSAN から取り除く容量になるという点も見てきました。最後に、vSphere Configuration Profiles と vSAN のディスク管理ワークフローを使用して、Memory Tiering を有効化・無効化する手順を確認しました。 Memory Tiering を使うと、アクティブメモリが DRAM 内に収まり、vSAN データストアが再割り当てされた容量を吸収できるという条件のもとで、インスタンスタイプを変更したりノード数を増やしたりせずに、Amazon EVS クラスターの実効メモリを増やし、ハードウェアとライセンスのコストを削減できます。メモリの両階層と VM のストレージ要件を考慮してサイジングを行い、有効化後はクラスターの Summary タブでアクティブメモリの利用率を確認して、Memory Tiering が環境で効果を発揮しているかを確かめてください。 著者について Ron Wedel Ron Wedel は AWS のシニアソリューションアーキテクトです。20 年以上にわたり仮想化技術に携わり、パートナーやお客様が AWS への次の一歩を踏み出す支援に情熱を注いでいます。AWS ソリューションアーキテクトとして、VMware 環境、ネットワーキング、コンピューティングインフラの最適化を専門としています。これらの技術に関する幅広い知識を基盤に、お客様が AWS 上でモダンなインフラを構築・拡張できるよう支援しています。 Allan Scott Allan Scott は AWS のシニアスペシャリストソリューションアーキテクトで、企業のクラウド変革の取り組みを支援することに情熱を注いでいます。2022 年に AWS に入社以来、Infrastructure Migration and Modernization チームで中心的な役割を担い、22 年間の業界経験を活かして複雑な技術課題の解決に取り組んでいます。AWS ソリューションアーキテクトとして、VMware 環境、ネットワーキング、コンピューティングインフラの最適化を専門としています。これらの技術に関する幅広い知識を基盤に、企業向け移行を支援するアプローチを確立し、複雑な技術課題を乗り越えながら事業変革を推進するクラウドソリューションを実現しています。 James Selwood James Selwood は 19 年間の業界経験を AWS に持ち込み、Infrastructure Migration and Modernization チームでシニアスペシャリストソリューションアーキテクトとして活躍しています。2019 年に AWS に入社以来、VMware、ネットワーキング、コンピューティングインフラに関する知識を活かして、お客様のクラウド変革を支援しています。AWS ソリューションアーキテクトプロフェッショナルとして、AWS サービスを活用したインフラ移行の最適化をお客様に提供することに力を注いでいます。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

本ブログは 株式会社JAPANNEXT 様、 クラスメソッド株式会社 、Amazon Web Services Japan 合同会社が三社共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクトの田中里絵です。 AI を活用して日常業務を効率化していきたい、と多くのお客様からお聞きします。一方で、AI ツールを導入するだけではなかなかうまくいかず、これまで馴染んできた業務プロセスと AI ツールをいかに統合させていくのかに悩んでいる、というお声もいただきます。 本記事では、JAPANNEXT 様が Amazon Connect Customer と Amazon Bedrock を活用し、二つの部門で電話対応業務を刷新した事例を紹介します。ツールを導入するだけでなく、現場でどう使われるか、将来の IT 基盤にどう繋げるかを、お客様、パートナー、AWS の三社でワクワクしながら議論して仕組みづくりをしました。ぜひ楽しんでお読みください。 株式会社 JAPANNEXT について JAPANNEXT 様は、千葉県いすみ市に本社を置く液晶ディスプレイ（液晶モニター）メーカーです。2016 年に JAPANNEXT ブランドのモニターを発売し、ブランド 10 周年を迎えられました。大型ディスプレイ、4K ディスプレイ、ゲーミングモニター、モバイルモニターなど多様なラインナップの製品を提供されていて、良いものを最高のコストパフォーマンスで届けるという考え方が製品づくりの軸になっています。年間 150 を超える新製品を発売するスピーディーなビジネスが強みです。 事業拠点は、統合により廃校となったいすみ市の小学校を利活用した本社です。このユニークな本社に加え、いすみ鉄道の菜の花保全活動への協賛や、リファビッシュ品（再生品）をふるさと納税の返礼品として提供する取り組みなど、テクノロジーと地域活性化の両輪で事業を展開されています。 写真：本社エントランス（左）、学校の雰囲気が残る社屋内 – 想いをつないで （中央）、リフレッシュルーム – ON／OFF 両方全力で（右） JAPANNEXT 様が直面していた課題と背景 多様な製品ラインナップを持つ JAPANNEXT 様には、購入前の製品選定のご相談から設置方法、保証や修理まで、多様な問い合わせが寄せられます。従来、1 日あたり平均 80 件の営業問い合わせを、5 名の営業アシスタント様が固定電話を介して受けていました。担当者の不在でお客様をお待たせしたり、適切な担当者へのルーティングに時間がかかったりするため、問い合わせがつながるまでに数分を要していました。また、伝言やチーム内での情報連携は属人的に行われていたため、誰が、いつ、どんな問い合わせを受けているのかをチームとして把握しきれないという課題もありました。 購入後のお問い合わせを受けるカスタマーサポートでも、情報連携に関する課題を抱えていました。エージェントは受電後にお客様対応を行い、内容を記録して CRM に入力しますが、これに 1 件あたり 15 分を要し、記録の粒度も担当者によりまちまちでした。このために問い合わせ内容がデータとして蓄積されづらく、対応の振り返りや傾向の把握が進みづらい状況にありました。重要度の高いお問い合わせをスーパーバイザーに即時連携したい場面でも、通話終了後に記録・共有する業務フローでは 10 分程度のタイムラグが避けられませんでした。 これらの課題を解決するため、既存 PBX システムの更改は 2024 年ごろから検討に挙がっていました。しかしながら、着信時に発信元のお客様情報が CRM の画面に自動で表示される連携機能を日常的に利用しており、次期システムでも同等の体験を実現できるかが重要な要件となり、技術選定を難しくしていました。さらに、既存 CRM の更改も考慮する必要があり、相互に連携するシステムをどう入れ替えていくかの整理も必要な状況でした。 ソリューション選定の経緯 技術選定の中心に据えたのは、2 つの方針です。1 つは、クラウド型のコンタクトセンターを採用し、物理的な電話デバイスから PC 上のソフトウェアを介した受電へ切り替えること。もう 1 つは、対応内容の記録と連携に、AI による文字起こしを活用することです。 この方針のもとで選定したのが、クラウド型のコンタクトセンターサービスである Amazon Connect Customer でした。オンプレミスの PBX 基盤や固定電話を必要とせず、問い合わせを自動でルーティングし効率的に対応を振り分けられること、通話の文字起こしや感情分析といった AI 通話分析機能（Amazon Connect Customer Contact Lens）をフルマネージドで使えること、そして従量課金により低価格でスタートできることが、選定のポイントとなりました。 選定の過程で重要な論点になったのが、課題の段でも触れた CRM との連携です。お客様の中でも議論を重ね、ユーザーからみて従来と同等以上の体験が得られると確認できたことで、最終的には CRM 自体の更改も同時に進めることを決断されました。 AWS パートナーとの協業 Amazon Connect Customer、Amazon Bedrock、新 CRM との導入支援と連携を総合的にお願いできる導入パートナーとして、AWS プレミアティアサービスパートナーであるクラスメソッドとの協業を決定し、AWS サービスの設計とともに CRM 更改も含めたプロジェクト計画を進めていきました。 本プロジェクトの技術リードの大野様は次のように述べています。 「AWS の知見、AI に対する知見、細かな要件のすり合わせに加え、CRM の更改も見据えた支援をしてくれるという点が非常に大きなポイントでした。」 ソリューションの構成 営業支援のユースケースでは、Amazon Bedrock が要約機能を担いました。Amazon Connect Customer の文字起こしと Amazon Bedrock によるカスタマイズされた要約を組み合わせて、AWS Lambda で担当者が日常的に使っているチャットツールへ連携し、イベントドリブンアーキテクチャによって終話後数分で届きます。必須の要件として残ったお客様情報の表示は、CRM から Amazon Connect に定期連携するロジックを追加で作成しました。 この構成の設計を主導したクラスメソッド様は、設計の狙いを次のように語っています。 「本プロジェクトで最も重視したのは、『CRM が変わっても、継続活用できる設計にする』という点でした。Amazon Connect Customer との連携を疎結合に設計することで、CRM に依存しない柔軟な環境を実現しています。 通話要約のモデルは、精度と運用面を総合的に考慮して Claude を提案しました。大野様が日常的に活用され、JAPANNEXT 様の社内指針でも推奨されていたことが重なり、現場に最も馴染みやすい選択になったと感じています。 また、オペレーターの役割と状況を丁寧にヒアリングし、ルーティングプロファイルを部門ごとに分離することを提案しました。営業時間外の対応についても、カレンダー管理や追加手順を共有することで、お客様が自走して運用を続けられる体制を整えました。」 図：営業部門で利用する新システムのアーキテクチャー概要 導入の成果 先行して運用を開始した営業部門では、初日から前向きなフィードバックが得られました。具体的には、次のような効果が生まれています。 1 日の電話対応件数が 15 % 増加 担当者への電話引き継ぎに要していた時間が、自動ルーティング機能によりゼロに 不在着信や業務時間外の着信も可視化され、引き継ぎ漏れがゼロに 1 件あたりの対応時間短縮の結果、担当者の残業時間が 15 % 削減 数字に表れない変化もあります。対応そのものに集中できるようになり、通話しながらの情報検索や応対品質の振り返りも可能になったことで、単なる問い合わせへの受け答えにとどまらず、情報収集や分析など顧客体験を高める取り組みに時間を割く余裕が生まれています。 プロジェクトを推進された大野様は、SE の視点から効果をこう分析されています。 「Amazon Connect Customer を導入してから、記録に追われなくなったことで、電話対応とエスカレーション判断を、担当者がいずれも落ち着いて対応できるようになりました。就業時間に目途が付きやすくなり、働きやすさも向上したとフィードバックを得られています。また、物理的な電話が撤廃されたことで、執務室の静音化という副次効果もありました」 リーダー業務には、問い合わせ対応に加え外部との調整作業がありますが、導入後はこの業務にも変化が生まれました。主運用部門担当の高野様、植村様およびチームリーダー押尾様からは、次のような声が寄せられています。 「電話のピーク対応処理が従来の80件程度から100件／日可能になり、加えて受話できなかった問い合わせもガイドによりメール問い合わせ担当へ振り替わるため、業務量が平準化されました。これにより担当者がリーダーのサポートも出来るようになりました。またチームリーダーは本業務と問い合わせ対応のサポートも並行作業で可能となりました。今までは不可能か、とても難しかったことです。」 また、営業部門での成果を受け、フェーズ 2 としてカスタマーサポート部門への展開を進めました。開発段階から現場担当者を交えてクラスメソッド様と要件定義を重ね、標準的な機能を中心に活用してカスタマイズを最小限にするために、運用側の見直しも含めた機能の選定や社内調整を積み重ねました。 この要件定義に参加したコーチングリーダーの本良様は、その経験を次のように語っています。 「現場の意見を取りまとめ、クラスメソッド様のエンジニアと密に会話を重ねることで、要望がかたちになっていきました。ユーザーとシステム、両方の立場や悩みを経験できたことも大きな収穫です。この仕組みは、カスタマーサポートとシステム部門がワンチームで築き上げたものです。」 写真：プロジェクトにご尽力された高野様（写真左）、本良様（写真右） お客様の声と今後のお取り組み 一連の取り組みについて、伊丹様、剣持様、大野様から、それぞれ次のような声をいただいています。 伊丹様「単に業務効率が向上しただけではなく、問い合わせ内容が漏れなく記録されることで、今後の営業活動の分析やさらなる向上が見込めるようになりました。これから本格化するカスタマーサポートへの展開にも、大いに期待しています。」 剣持様「JAPANNEXT では、毎年 150～200 機種の新商品を発売し、市場に無いものでもチャレンジして製品開発、発売を行っています。それを支える社内システムは自社開発が基本姿勢ですが、クラスメソッド様、Amazon Web Services Japan 様との連携で新しい仕組みをスピーディーに構築することが出来ました。あわせてカスタマーサポートも刷新し、これまで担当者ごとに散在していた顧客との接点が、営業組織全体で共有できる情報基盤になりました。今後はこの基盤を活かし、外部の有識者の知見も取り入れながら、新たな顧客開拓につなげていきます。」 大野様「本共創の立ち上げを経験したことで、JAPANNEXT 社内全体で『新しい考え方がないか？』といったことを考える雰囲気が醸成され始めました。単に効率改善のためだけのプロジェクトに留まらず、仕組みづくりに様々なステークホルダーを交えて取り組めたことが最大の成果でした。」 クラスメソッド様からは、次のようなフィードバックをいただいています。 「単なるツールの入れ替えではなく、業務課題そのものに向き合いながら仕組みを作り上げられた点が良かったと考えております。電話対応の現場で何が起きているかを丁寧にヒアリングし、ツールと業務プロセスを一緒に設計することで、担当者が『記録に追われる仕事』から解放される仕組みが生まれました。今後も JAPANNEXT 様の業務改善に継続的に伴走していきます。」 今後 JAPANNEXT 様は、RMA（返品や交換）の一連の作業を担うチームにも、Amazon Connect Customer の利用を広げていく想定です。また、本プロジェクトで導入された CRM のさらなる活用や、クラウドに蓄積され始めたデータをビジネスに活用を目指して継続的にお取り組みをしていくご想定です。 まとめ 本事例では、業務の目的に立ち返って、機能と運用の両面から設計を重ねたことが、初日から現場に定着する仕組みにつながりました。AI 活用を検討される際は、ツールの選定とあわせて、現場の運用にどう溶け込ませるかの議論に、ぜひ時間をかけてみてください。AWS へのご相談もお待ちしています。 コンタクトセンターの業務刷新や AI 活用に興味を持たれた方は、 Amazon Connect Customer の製品ページ や、 Amazon Bedrock の製品ページ をご覧ください。 株式会社JAPANNEXT : General Manager 伊丹 利政 氏（写真中央左）、Senior System Engineer 大野 浩司 氏（写真中央右）、Head of Sales & Marketing 剣持 開 氏（写真右から2番目） クラスメソッド株式会社 : 営業 平田 梨紗（写真右） Amazon Web Services Japan : アカウントマネージャー 倉知 達哉（写真左）、ソリューションアーキテクト 田中 里絵（写真左から2番目） ソリューションアーキテクト　田中里絵

本ブログは、仰星監査法人様のご協力のもと、株式会社 Sapeet と Amazon Web Services Japan が執筆しました。 はじめに ノーコード・ローコードツールの普及により、多くの企業が迅速に AI アプリケーションを構築できるようになりました。 プロトタイプを素早く形にし、ユーザーの声を得ながら改善を重ねる。この立ち上げ期のスピードは、ノーコードツールならではの大きな価値です。 一方で、プロダクトが成長しチームが拡大するフェーズでは、Git ベースのバージョン管理やコードレビューといったソフトウェア開発のプラクティスを取り入れたいというニーズが高まってきます。 本記事では、ノーコード AI プラットフォーム Dify で立ち上げ、環境分析調査時間を大幅に削減した生成 AI ツールを、プロダクトの成長に合わせて Amazon Bedrock AgentCore と Strands Agents SDK によるコードベースのアーキテクチャへ移行した株式会社 Sapeet の事例をご紹介します。 Dify で築いた約 1 年間の開発資産と設計思想を活かすことで、わずか 2 週間で基盤移行を完了した取り組みです。 株式会社 Sapeet について 株式会社 Sapeet（以下、Sapeet）は、AI 技術を活用したソリューションを提供するテクノロジー企業です。 同社は仰星監査法人様向けに、生成 AI を活用した環境分析ツールを開発・提供しています。 監査業務における環境分析プロセスを AI で効率化し、分析品質の向上と業務負担の軽減を実現するプロダクトです。 本プロダクトの立ち上げ期の取り組みについては、過去記事「 仰星監査法人様の AWS 生成 AI 活用事例：株式会社 Sapeet 様支援のもと、Dify を用いて生成 AI アプリを構築し、機微な情報を扱えるセキュアな環境でクライアント情報の収集・環境分析調査時間の 87% 削減を実現 」で詳しく紹介しています。本記事は、その後のプロダクト成長フェーズにおける進化を描いた続編です。 Dify による立ち上げと、次のフェーズで見えてきた課題 Sapeet はこのツールを、ノーコード AI プラットフォーム Dify と Amazon Bedrock を組み合わせて AWS 上に構築しました。 ワークフローを可視化しながら少人数で素早くプロトタイピングできる Dify の強みを活かして開発を進め、環境分析調査時間の大幅な削減という成果を実現しました。導入後も改善を重ね、約 1 年間にわたってプロダクトを育ててきました。 一方、プロダクトが成長し、チームでの開発とプロダクション運用のフェーズに入るにつれ、新たなニーズが見えてきました。 これらは特定のツール固有の問題というより、プロトタイプから本格運用へ移行する際に多くの開発現場で生じる、フェーズの変化に伴う課題です。 課題 1: チーム開発におけるバージョン管理 チームで開発を進める中で、Git ベースの差分管理やプルリクエストによるコードレビューを取り入れたいというニーズが高まりました。 当時の開発体制では作業者ごとの変更差分の把握が難しく、リグレッションや、意図した変更が反映されないといった事象も発生していました。 課題 2: ワークフローの複雑化への対応 機能追加に伴いワークフローのノードが増え、管理の複雑さが増していきました。 アプリを分割して開発する際の同期や結合にも工夫が必要になり、チームでの分業を支える仕組みづくりが課題となっていました。 課題 3: プロダクトに最適な UX の追求 プロダクトの進化に伴い、チャット形式にとどまらない、業務に最適化した専用 UI を提供したいという要望が強まりました。 また、開発効率をさらに高めるため、途中実行やログ出力を活用したデバッグのしやすさも求められるようになりました。 こうした課題は、Dify の欠点ではなく、プロダクトのフェーズが変わったことによるトレードオフです。 重要なのは、フェーズに応じて最適なツールを見極めることです。Sapeet は、立ち上げ期を支えた Dify の資産を活かしながら、次のフェーズに向けてコードベースへの移行を決断しました。 ソリューション: Amazon Bedrock AgentCore + Strands Agents SDK への移行 選定の決め手: ノード親和性 ― Dify の設計思想をそのまま活かす Amazon Bedrock AgentCore は、AI エージェントのビルド・デプロイ・運用をスケーラブルに実現するフルマネージドプラットフォームです。 サーバーレスランタイム、マネージドメモリ、ツールゲートウェイ等を提供し、フレームワークに依存しない柔軟な構成が可能です。 Strands Agents SDK は、オープンソースの AI エージェント SDK（Python / TypeScript）です。 モデル・ツール・プロンプトの 3 要素でエージェントを構築でき、Amazon Bedrock がデフォルトのモデルプロバイダーとして統合されています。 Sapeet がこの組み合わせを選定した最大の理由は、ノード親和性です。 Dify のブロック繋ぎ型ワークフローと、Strands Agents SDK のノードベース実行は構造的に類似しています。 Dify で 1 つの LLM ノードにプロンプトを書いて入出力を次のノードに繋いでいた構成が、Strands Agents でもほぼそのまま表現できます。 つまり、Dify 上で 1 年間かけて磨き上げてきたワークフローの設計思想が、そのままコードベースへの移行資産になったのです。 また、モデル基盤には立ち上げ期から Amazon Bedrock を利用していたため、今回の移行ではオーケストレーション層とホスティング環境の進化に集中できました。 移行プロセス: 2 週間で基盤移行を完了 移行は 2026 年 4 月に開始しました。 まず 1 ヶ月をかけて技術検証を実施し、その上でメイン実装エンジニア 1 名が集中して開発することで、実質 2 週間で基盤移行を完了し、 結合テストを含めても約 2 ヶ月という短期間で構築を終えました。 この速さを支えたのが、前述のノード親和性です。ゼロからの再設計ではなく、既存ワークフローの「翻訳」に近い形で移行を進められました。 予想外の収穫: Toolkit とエコシステム 移行を進める中で、AgentCore の Toolkit によるデプロイの容易さが予想以上のメリットとなりました。 Dockerfile 不要で動作確認が可能であり、エコシステムの充実により導入・お試しのハードルが低いことも評価されています。 Sapeet の堀ノ内様も「Toolkit を活用することでデプロイが想像以上に簡単になり驚いた」と、エコシステムによる開発者体験の良さを語ります。 CDK L2 Construct による統一管理 インフラ管理には AWS CDK の L2 Construct（aws-cdk-lib/aws-bedrockagentcore、AWS CDK v2.221.0 以降で利用可能）を採用しました。 AgentCore でエージェントをホスティングし、Amazon Elastic Container Service（Amazon ECS）でバックエンドとフロントエンドをホスティングする構成を、単一の CDK プロジェクトから一括でデプロイできるようにしています。 これにより、バージョン管理・コードレビューがインフラを含めて一元化されました。 開発メンバーも「インフラ全体を 1 つの CDK プロジェクトでまとめて管理できるようになったので、構成がシンプルになった。」と、インフラ管理の一元化による開発効率の向上を実感されています。 導入効果 移行により、以下の効果を実現しました。 観点 移行前 移行後 バージョン管理 作業者ごとの変更差分の把握が困難 Git ベースの差分管理・ロールバック可能 コードレビュー レビューフローの確立が困難 PR ベースのレビューフロー確立 UI / UX チャット形式の表示 専用画面での観点別タブ表示（PEST、5 フォース等）に改善 なお、実行時間については、基盤の移行に伴う遅延が懸念されましたが、処理時間の 8 割以上を LLM の推論時間が占めるため、移行前と体感でほぼ同等の水準を維持できています。 さらに、将来的には Amazon S3 + AWS Lambda + AgentCore 構成への最適化による、コスト効率の改善を見込んでいます。 お客様の声 移行後、Sapeet の開発メンバーの方々からは下記のコメントをいただいています。 「コード管理機能やレビューを通して、差分がわかりますし、これまでのソフトウェア開発のベストプラクティスに沿った形でやっていけるようになった」村上 大昌 様（AI Solution 事業部 Senior Project Manager） 「リリースしたいバージョンを確実に選んで反映できるようになった」津守 優 様（AI Solution 事業部 Engineer） 「Strands Agents の Graph 機能を使うことで処理が順番に流れるワークフローを構築でき、Dify 上でのノードを繋げていく形と同じ構成を取りやすかった。AgentCore へのデプロイも簡単で、エコシステムが充実しており導入がしやすい」堀ノ内 司 様（AI Solution 事業部 Engineer） 今後の展望 Sapeet は、移行した生成 AI 環境分析ツールの本番適用を経て、継続的な改善サイクルを回していきます。 2026 年 8 月以降のアップデートを機に、実際の利用者からのフィードバック収集を進めていく予定です。また、環境分析以外にも複数テーマで AI 開発を進めており、その一部は Strands Agents SDK を活用してすでに本番リリースを迎えています。 ノーコードで素早く立ち上げ、成長に合わせてコードベースへ移行するスキームを社内で確立し、他プロジェクトへ横展開していく方針を掲げています。 まとめ 本事例から得られる示唆は以下の通りです。 フェーズに応じたツール選定 — ノーコードは迅速な立ち上げに、コードベースはチーム開発・品質管理のフェーズに強みを発揮する。どちらが優れているかではなく、プロダクトの成長段階に応じた見極めが重要 ノード親和性を活かした段階的移行 — 既存のワークフローと構造的に類似するフレームワークを選ぶことで、これまでの設計資産を活かし、移行コストを最小化できる 開発スピードとガバナンスの両立 — Amazon Bedrock AgentCore + CDK による統一管理で、開発スピードを保ちながらコードレビュー・バージョン管理を実現 エコシステムの活用 — Toolkit やマネージドサービスを活用することで、インフラ構築の負担を最小限に抑えられる ノーコードツールで AI アプリケーションを立ち上げ、プロダクトの成長とともに次のフェーズを迎えつつある方は、Amazon Bedrock AgentCore と Strands Agents SDK によるコードベースへの移行をぜひご検討ください。 実際に手を動かして試したい方には、 Amazon Bedrock AgentCore ワークショップ : 基本から高度なエージェント開発まで  をご活用ください。エージェントの構築からデプロイ、運用に必要な観測・評価まで、約 2 時間のハンズオンで体験できます。

2026 年 8 月 21 日、 AWS Glue 6.0 の一般提供について発表しました。これにより、価格が以前の AWS Glue バージョンよりも 30% 低くなり、 Apache Iceberg v3 の機能が完全にサポートされるようになりました。AWS Glue 6.0 は、完全に近代化されたランタイム、Apache Spark 4.1、Python 3.12、および Scala 2.13 に基づいて構築されており、より高速なパフォーマンスを実現しています。 このリリースにより、AWS Glue は、完全にサーバーレスのマネージド型の Spark サービスで最も完全な Iceberg v3 実装を実現するとともに、ETL オーサリングを簡素化し、 PySpark のパフォーマンスを向上させ、1桁ミリ秒のレイテンシーでリアルタイムストリーミングを可能にする新機能も提供します。 AWS Glue 6.0 の新機能は何ですか AWS Glue 6.0 は、Iceberg 1.11.0 をベースに構築された完全なApache Iceberg v3仕様を提供します。主な特長は、シュレッダ処理をサポートする VARIANT データ型です。これにより、半構造化データ用の従来の文字列データ型の列と比較して、クエリの読み取りパフォーマンスが向上します。 VARIANT  のシュレッディングを使用すると、スキーマをフラット化しないで JSON、ログ、イベントデータを保存してクエリできます。これにより、スキーマが変更されたときに重複するデータコピーやカスタム解析コード、パイプラインが破損することがなくなります。この機能により、チームが半構造化データの大規模処理の方法が変わります。 Iceberg v3 のその他の機能には以下が含まれます。 幾何学と地理データタイプ : GIS分析、ロケーションインテリジェンス、および地理空間データパイプラインのネイティブ空間処理をマネージド Spark で直接有効にします。 ナノ秒精度のタイムスタンプ : 標準ミリ秒を超える精度を必要とする IoT センサーデータ、科学計算、および高頻度の金融ワークロードをサポートします。 未知の型処理 : パイプラインに障害が発生することなく、予期しないスキーマや、進化するスキーマを含むデータを処理できるため、上流のスキーマ変更に対する回復力が高まります。 AWS Glue 6.0 には、最新のランタイムエンジンである Spark 4.1 の最も重要なアップグレードも含まれています。 Spark 宣言型パイプライン : Spark 宣言型パイプラインでは、ETLオーサリングへのシンプルなアプローチが導入されています。データエンジニアは変換を宣言してデータをどのように表示するかを指定し、エンジンは実行順序と最適化を自動的に決定します。これにより、パイプライン開発の複雑さが軽減され、手動によるオーケストレーションのオーバーヘッドがなくなります。 アローネイティブ Python UDF と UDTF : AWS Glue 6.0 では、Python ユーザー定義関数 (UDF) とユーザー定義テーブル関数 (UDTF) の Arrow ネイティブ実行が導入されました。これにより、Python と JVM 間のシリアル化のオーバーヘッドがなくなり、複雑な変換での PySpark のパフォーマンスが向上します。 リアルタイムストリーミングモード : AWS Glue 6.0 では、ステートレスストリーミングのユースケース向けに、1桁ミリ秒のレイテンシーを実現するリアルタイムストリーミングモードが導入されています。Glue に最適化された実行機能を備えた Spark 4.1 のリアルタイムモードに基づいて構築されたこの機能は、リアルタイムのイベント処理、低遅延のデータ変換パイプライン、および時間に敏感なデータルーティングをサポートします。 AWS Glue 6.0 の開始方法 AWS Glue 6.0 を使用するのに、API を変更する必要はありません。 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS Glue Studio 、 Amazon SageMaker Unified Studio 、および優先する IDE から create-job または update-job API で既存の --glue-version パラメーターを使って、新しいバージョンを選択することができます。 AWS Glue 6.0 ジョブを AWS Glue Studio コンソール で開始するには、[AWS Glueジョブ] を開き、 ジョブ詳細 タブで、バージョン Glue 6.0 – Spark 4.1、Scala 2、Python 3 をサポート を選択します。AWS Glue 6.0で新しい AWS Glue ジョブを作成することで、改善によるメリットを受けること、および既存の AWS Glue ジョブを移行することもできます。 AWS Glue 6.0 を AWS Glue Studio ノートブックで使用したり、Jupyter Notebook を介してインタラクティブセッションを開始したりするには、 %glue_version マジックで 6.0 を設定してください。 また、AWS Glue Studio の Spark アップグレードエージェント を使用して既存のジョブを Glue 6.0 にアップグレードしたり、既存の Glue ジョブの自動アップグレード機能を使用して自動的に Glue 6.0 にアップグレードしたりすることもできます。 詳細については、AWS ドキュメントの 「AWS Glue 6.0 バージョンの詳細」 および 「AWS Glue for Spark ジョブの AWS Glue バージョン 6.0 への移行」 を参照してください。 今すぐご利用いただけます AWS Glue 6.0 は現在、AWS Glue が運用されているすべての AWS リージョンで一般的に利用可能です。リージョンごとの提供状況や今後のロードマップについては、 リージョン別の AWS 提供機能 にアクセスしてください。API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 クローラー (データの検出) と抽出、変換、ロード (ETL) ジョブ (データの処理と読み込み) には、時間単位の料金を秒単位で請求します。AWS Glue データカタログの場合は、メタデータの保存とアクセスにシンプルな月額料金を支払う必要があります。最初の 100 万個のオブジェクトは無料で、最初の 100 万個のアクセスは無料です。詳細については、 AWS Glue 料金表ページ をご覧ください。 AWS Glue Studio コンソール でお試しいただいた後、 AWS re:Post for AWS Glue または通常の AWS サポート窓口までフィードバックをお寄せください。 – Channy 原文は こちら です。

本ブログは 2026 年 8 月 25 日現在の内容を基に記載しております。記載内容については今後変更される可能性があります。 こんにちは ! テクニカルインストラクターの室橋です。AWS クラウドの知識やスキルを証明する方法としての「 AWS 認定 」はご存知の方も多いかと思います。しかし、2025 年末より AWS Skill Builder に順次コースが追加されている「マイクロクレデンシャル」という新しいスキル証明については、まだご存じない方や、AWS 認定との違いがよくわからないという方もいらっしゃるかもしれません。 この記事では、マイクロクレデンシャルとは何か、AWS 認定との違い、そしてどう組み合わせて活用できるかをわかりやすく解説します。 マイクロクレデンシャルって何 ? マイクロクレデンシャルとは、 AWS Skill Builder 上で取得できる、特定の技術領域に特化した実践スキルの証明 です。 AWS 認定が広い範囲の知識とスキルを体系的に問うのに対し、 マイクロクレデンシャルは「その技術を実際に使えるか」にフォーカスしています。 ハンズオンラボを使用した実践的な評価を通じて、 特定のサービスや技術を「知っている」だけでなく「使える」ことを証明できます。 現在提供されているマイクロクレデンシャルの例を挙げると、以下のようなものがあります。 AWS データレイクハウスの実証 (2026 年 7 月末に新規追加) : AWS Glue ETL インジェスト、Apache Iceberg テーブルの最適化、AWS Lake Formation ガバナンスのトラブルシューティングを行い、故障した E コマースレイクハウスプラットフォームを診断して修正します。Amazon Athena、AWS Glue、Apache Iceberg、Amazon EventBridge、AWS Lake Formation、Amazon Data Firehose を含むデータ分析サービスの習熟度を実証する必要があります。 AWS データストリーミングの実証 (2026 年 7 月末に新規追加) :リアルタイムインジェスト、イベントストリーミング、ストリーム処理、データ配信パイプライン、ポイズンピル処理、スキーマ駆動型フォーマット変換のトラブルシューティングを行い、故障したヘルスケアストリーミングインフラストラクチャを診断して修正します。Amazon Kinesis Data Streams、Amazon MSK、Amazon Data Firehose、Amazon Managed Service for Apache Flink、AWS Glue を含むデータ分析サービスの習熟度を実証する必要があります。 AWS データビジュアライゼーションの実証 (2026 年 7 月末に新規追加) : 機械学習を活用した予測の設定、行レベルおよび列レベルのセキュリティの実装、再利用可能な SQL ビューの構築、テーブル計算と条件付き書式を含むダッシュボードの公開を行い、ストリーミングプラットフォームの分析レイヤーを構築します。Amazon QuickSight、Amazon Athena、Amazon Redshift Serverless、AWS Glue Data Catalog を含むデータ分析サービスの習熟度を実証する必要があります。 AWS MLOps の実証 (2026 年 5 月末に新規追加) : Amazon SageMaker AI、Amazon Elastic Container Registry、Amazon API Gateway、AWS Lambda、Amazon CloudWatch を含む機械学習サービスの習熟度を実証する必要があります。 AWS エージェンティック AI の実証 (2026 年 5 月末に内容更新) : Amazon Bedrock AgentCore、Amazon Bedrock Guardrails、Amazon Cognito、AWS Lambda、Amazon OpenSearch Service を含むエージェンティック AI サービスの習熟度を実証する必要があります。 AWS アプリケーションネットワークの実証 : Elastic Load Balancing、Amazon VPC Lattice、Amazon API Gateway、Amazon CloudFront、Amazon Elastic Container Service (Amazon ECS) を含むネットワーキングサービスの習熟度を実証する必要があります。 AWS インシデント対応の実証 : AWS CloudTrail、AWS Identity and Access Management、Amazon EC2、Amazon S3、Amazon RDS、AWS Config を含むセキュリティサービスの習熟度を実証する必要があります。 AWS サーバーレスの実証 : Amazon CloudFront、AWS CodeBuild、AWS CodePipeline、Amazon DynamoDB、AWS Lambda、Amazon Simple Storage Service、Amazon Simple Notification Service、Amazon Simple Queue Service、AWS Step Functions、AWS WAF を含むサーバーレスサービスの習熟度を実証する必要があります。 いずれも、特定のユースケースや技術領域に絞り込んだ内容になっているのが特徴です。 注意 : 各マイクロクレデンシャルには制限時間が設けられており、 途中で中断することはできません。 開始する前に、まとまった時間をしっかり確保してから取り組んでください。また、不合格になった場合は再受験までに 25 日間 の間隔を空ける必要があります。 十分に準備を整えてから臨むようにしましょう。 なお、本番に取り組む前に、 AWS マイクロクレデンシャル – お試し版  で動作環境や出題の雰囲気をあらかじめ確認することができます。初めて挑戦する方はまずこちらから試してみることをおすすめします。お試し版にも少しハードルを感じる場合は AWS のテクニカルインストラクターがマイクロクレデンシャルについて紹介している  無料の動画コース で雰囲気をつかんでいただくのも良いでしょう。 マイクロクレデンシャルのもう一つの大きな魅力は、 AWS Skill Builder から無料で挑戦できる 点です。リリース当初は有料サブスクリプションが必要でしたが、現在は Skill Builder にアクセスさえできれば誰でも無料で挑戦できます。また、登場してまだ日が浅いコンテンツということもあるため、早い段階で取得すれば、実践スキルを持つエンジニアとして差別化を図れます。 さらに、マイクロクレデンシャルに合格すると Credly からデジタルバッジが発行 されます。LinkedIn などの SNS やプロフィールでシェアすることで、実践スキルをアピールする際に役立てることができます。 AWS 認定との違い マイクロクレデンシャルと AWS 認定は、どちらも「AWS のスキルを証明するもの」ですが、目的や評価の観点が異なります。 比較項目 AWS 認定 マイクロクレデンシャル 対象範囲 幅広いサービスと概念を網羅 特定の技術・ユースケースに特化 評価方法 選択式の試験 ハンズオンラボ・実践的な課題 証明できること 広範な知識やスキルを「理解、所持している」こと 特定スキルを「実際に使える」こと 学習範囲 幅広い学習が必要 特定領域に集中した利用や学習が必要 取得場所 AWS 認定試験会場 / オンライン試験 AWS Skill Builder 一言でまとめると、 AWS 認定は「知識の幅」、マイクロクレデンシャルは「スキルの深さ」を証明するもの と言えます。 こんな方におすすめ マイクロクレデンシャルは、 すでに AWS 認定 (Associate レベル以上) を保有している方が次のステップとして取り組むのに最適 です。 AWS 認定は幅広い知識やスキルを体系的に証明するものですが、「実際の現場でそのサービスを使いこなせるか」という実践面はカバーしていません。 Associate レベル以上の認定を持つ方は前提となる知識の土台がすでにあるため、マイクロクレデンシャルのハンズオン評価に取り組む準備ができている と言えます。 逆に、認定未取得の状態でマイクロクレデンシャルに挑戦すると、前提知識の不足から難易度が高く感じる可能性があります。まずは関連する AWS 認定の学習で知識の土台を固め、その上でマイクロクレデンシャルで実践スキルを証明するのが効率的な進め方です。 AWS 認定と関係性の深いマイクロクレデンシャルはこれ 各マイクロクレデンシャルは、特定の AWS 認定と内容的なつながりを持っています。関連する AWS 認定の学習をしながらマイクロクレデンシャルに取り組むと、理解がより深まります。 マイクロクレデンシャル 関連するAWS認定 AWS データレイクハウスの実証 DEA (Data Engineer – Associate) AWS データストリーミングの実証 DEA (Data Engineer – Associate) AWS データビジュアライゼーションの実証 DEA (Data Engineer – Associate) AWS MLOps の実証 MLA (Machine Learning Engineer – Associate) AWS エージェンティック AI の実証 ・DVA (Developer – Associate) ・MLA (Machine Learning Engineer – Associate) AWS アプリケーションネットワークの実証 ・SOA (CloudOps Engineer – Associate / 旧 SysOps Administrator – Associate) ・ANS (Advanced Networking – Specialty : 2026 年 12 月 31 日に試験終了) AWS インシデント対応の実証 ・SOA (CloudOps Engineer – Associate / 旧 SysOps Administrator – Associate) ・SCS (Security – Specialty) AWS サーバーレスの実証 DVA (Developer – Associate) たとえば、 AWS Certified Data Engineer – Associate (DEA) の取得を目指している方であれば、 データレイクハウス・データストリーミング・データビジュアライゼーション の 3 つのマイクロクレデンシャルがすべて関連しています。 認定試験の勉強と並行して取り組むことで、実践的なスキルも同時に身につけられるのではないでしょうか。 まとめ: 両方合わせることで「知識」と「スキル」の両方を証明できる AWS 認定とマイクロクレデンシャルは、それぞれ単独でも価値がありますが、 組み合わせることでより説得力のあるスキル証明 になります。 AWS 認定 : 「このサービス群を体系的に理解している」という広い知識・スキルの証明 マイクロクレデンシャル : 「この技術を実際の場面で使える」という実践的なスキルの証明 たとえば、AWS Certified Machine Learning Engineer – Associate (MLA) を持ちながら AWS MLOps Demonstrated も取得していれば、「機械学習の知識があり、MLOps の実践的な運用もできる」と示せます。採用担当者やプロジェクトのステークホルダーに対しても、より具体的な能力をアピールできます。   AWS 認定 マイクロクレデンシャル 強み 知識やスキルの幅・体系性 実践スキルの深さ 活用シーン キャリアの基盤づくり、転職・昇進のアピール 特定プロジェクトへのアサイン、専門性の強化 ぜひ、AWS 認定の学習を進めながら、関連するマイクロクレデンシャルにも取り組んでみてください。知識とスキルの両輪を揃えることで、AWS エンジニアとしての市場価値をさらに高めることができます。 まずは自分が目指している、もしくは所持している AWS 認定に対応するマイクロクレデンシャルから始めてみるのがおすすめです。 著者について 室橋 弘和 (Hirokazu Murohashi) AWS トレーニングサービス本部 Technical Instructor 兼 Customer Success Manager Cloud Quest とデカ盛りのお店巡りをこよなく愛するマン。老眼鏡が必要になってきました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 気づけば 8 月も残りわずかとなりました。朝晩には少しずつ秋の気配も感じられますね。今週は国内のお客様事例が豊作です。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、8 月 17 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「PKUTECH が Amazon Bedrock を活用して実現した AI-CSPM「Egeria-Security」のセキュアな設計」を公開 PKUTECH 様は、システムインテグレーション事業を展開し、生成 AI を活用した自社プロダクト開発に注力する企業です。従来の CSPM ツールには、チェックの根拠がブラックボックス化しやすく、カスタムルール作成のハードルが高いという課題がありました。AI-CSPM「Egeria-Security」は、自社のコンプライアンス文書を起点に Amazon Bedrock でスキャンポリシーを自動生成することでこれを解決しています。PoC では取り込んだ観点の約 50〜60% のポリシー自動生成を確認し、MVP 完成までの期間も想定 12〜18 ヶ月から約 4〜6 ヶ月に短縮されました。ハルシネーション対策や閉域推論など、機密データを扱う AI SaaS の設計判断も具体的に語られています。 AWS生成AI国内事例ブログ「株式会社日新 × AWS：人とAIが協働する新しい物流「オプティマAI」」を公開 株式会社日新様は、1938 年創業のグローバルな国際物流企業です。貿易書類の作成・照合や HS コード (税番) の判定に、多大な時間と専門知識を要する課題がありました。「人とAIの協働」をコンセプトに、Amazon Bedrock の RAG で税番候補を根拠付きで提示する「オプティマHS」と、AI-OCR で貿易書類を照合する「オプティマAI-OCR」を実用化しています。AI が候補を提示し人が最終判断する設計で、生産性向上とノウハウ継承を両立しました。将来は顧客と日新の AI 同士が MCP などで連携する、サプライチェーン全体の最適化を構想しています。 AWS生成AI国内事例ブログ「サンリオのエンジニア 6 名が 2 日間で体感した AI 駆動開発の可能性 — AI-DLC Unicorn Gym 座談会」を公開 サンリオ様のデジタル事業開発部と開催した、AI 駆動開発ライフサイクル (AI-DLC) 体験ワークショップのレポートと座談会記事です。2 チーム 6 名が Kiro を活用して実プロダクトを題材に全フェーズを体験し、inception 開始から本番マージまで約 5 時間で完了したストーリーもあります。AI との対話の結果「あえて実装しない」判断に至った話など、AI で実装が速くなるほど「何を作らないか」に価値が生まれるという気づきが印象的です。 AWS生成AI国内事例ブログ「Amazon Bedrock とロボティクスで目指す「未来の実験室」 ― AWS Summit Japan 2026 の Physical AI ―」を公開 コニカミノルタ様と共同執筆した、AWS Summit Japan 2026 での Physical AI 展示の解説記事です。「緑色を作ってください」という自然言語の指示を Amazon Bedrock 上の基盤モデルが構造化し、ロボットアームがフィルムを重ねて目標色に近づける閉ループ実験を紹介しています。LLM の役割を中間表現への変換に絞り、座標制御は決定論的な制御層に任せる設計で、軽量モデルでも安全性と速度を両立している点が読みどころです。 AWS生成AI国内事例ブログ「【開催報告】AWS Summit Japan 2026 レポート：SUMCO が挑む、Amazon Redshift × 生成 AI による半導体ウェーハ製造 DX」を公開 AWS Summit Japan 2026 に出展された SUMCO 様のブース展示を共同で振り返る開催報告です。半導体ウェーハ製造のビッグデータを Amazon Redshift 中核の基盤に集約し、データ加工の仕組み「RedPulse」と、生成 AI で自然言語データ解析を行う「SynchroFabAI」により、組織全体のデータ活用の底上げを図る取り組みを紹介しています。厳しいセキュリティ要件下でデータと生成 AI の活用を検討する製造業の方におすすめです。 ブログ記事「AWS Bedrock LLM Day Japan【開催報告】」を公開 2026 年 7 月 28 日に東京で開催された「AWS Bedrock LLM Day Japan」の開催報告です。最新アップデートの紹介に加え、NEC 様 (Claude Cowork を 2 週間で 12 万人規模に本番展開)、丸紅様、ファストドクター様、リクルート様、jinjer 様の 5 社が本番運用の実践知を共有しました。生成 AI を PoC から本番へスケールさせるヒントが凝縮されています。 ブログ記事「AWS ジャパン地域創生支援プログラム（LEAP by AWS ジャパン）を発表 — 地域経済のAIトランスフォーメーションを包括支援」を公開 地域経済の AI トランスフォーメーションを包括支援する日本独自の新プログラム「LEAP by AWS ジャパン」が発表されました。地域企業の AI・クラウド活用支援 (条件を満たせば最大 5 万 US ドル相当の AWS クレジット)、地域 IT サービス企業のスキル強化、デジタル人材育成、地域データ活用支援の 4 つのメニューで構成されます。8 月 18 日から 28 日に全国 8 か所で開催される「デジタル社会実現ツアー」でも順次紹介されます。 ブログ記事「どの Kiro アプリを選べばいい？」を公開 Kiro は IDE、CLI、Web、Mobile、Kiro Crew という複数のアプリとして利用できます。本記事では、これらが単一のエージェントハーネスに接続する「玄関口」であることを解説し、用途に応じて使い分けるための判断フレームワークを紹介しています。どのアプリでも同じエージェントと設定が付いてくるので、Kiro をどこから触るか迷っている方はぜひご一読ください。 サービスアップデート Amazon Quick の Microsoft 365 拡張機能が一般提供開始 Excel、PowerPoint、Word、Outlook の中で Amazon Quick が直接タスクをこなす Microsoft 365 拡張機能が一般提供開始されました。ピボットテーブルの作成、組織テンプレートに沿ったスライド生成、変更履歴付きの文書編集、受信トレイの整理といった作業を、Quick が持つ業務データを踏まえて AI に任せられます。東京リージョンを含む 6 リージョンで利用可能です。 Amazon Quick がカスタム権限のデフォルト拒否に対応 Amazon Quick のカスタム権限に、新しい AI 機能をユーザーに届く前に自動で制限するガバナンス設定 Deny by default が追加されました。これまで新機能はリリースと同時に全ユーザーが利用可能になるため、管理者は事後の対応を迫られていました。カスタム権限プロファイルで AI 機能カテゴリを制限しておけば、以後の新機能はリリース時点で自動的に拒否され、管理者が準備できたものから個別に許可できます。詳細は こちらのドキュメント をご参照ください。 AWS Security Agent が予算コントロールと検出結果の再検証に対応 AI エージェントが Web アプリケーションの脆弱性を自律的にテストする AWS Security Agent (現在は AWS Continuum の一部) が、タスク時間の上限設定と検出結果の再検証に対応しました。テストは上限に達するとそれまでの検出結果を保持したまま停止するため、コストを予見しながらペネトレーションテストを実行できます。また修正のデプロイ後に特定の検出結果だけを再検証して解消済みかどうかの判定を得られるようになり、フルテストの再実行なしで修正確認が完結します。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock が OpenAI モデルの API サポートを拡大し Cross Region Inference を導入 OpenAI の GPT-5.6 (Sol、Terra、Luna) が bedrock-runtime エンドポイントに対応し、Responses、Chat Completions、Converse の各 API から利用できるようになりました。あわせて Global および Geo (US) の Cross Region Inference に対応し、容量管理なしで高いスループットと低いトークン単価を利用できます。ログやコスト配分を他のモデルと共通の仕組みで扱える点も嬉しい改善です。 Amazon Bedrock で OpenAI GPT-5.6 Sol の値下げを発表 Terra、Luna に続き、GPT-5.6 Sol の API 価格が引き下げられました。入力は 100 万トークンあたり 4 USD (20% の値下げ)、出力は 20 USD (33.3% の値下げ) となり、少なくとも 2026 年 11 月 21 日までこの価格が適用されます。エージェンティックコーディングに強いモデルを、大量トークンを消費するワークロードでも使いやすくなりました。 Amazon Bedrock が SpaceXAI Grok 4.6 をサポート コーディングやエージェントタスク向けのフロンティアモデル SpaceXAI Grok 4.6 が Amazon Bedrock で利用可能になりました。US Geo と Global の Cross Region Inference に対応し、データ処理を米国内に保ちながらのスケールと、需要ピーク時の高スループットを両立できます。 AgentCore payments が Amazon Bedrock AgentCore で一般提供開始 AI エージェントが有料の API、MCP サーバー、コンテンツを自律的に発見・支払いできる AgentCore payments が一般提供開始されました。Coinbase や Stripe Privy のウォレット統合、インフラレイヤーで強制される支払い上限、AgentCore Observability による可観測性を備え、「取引するエージェント」を本番で安全に運用できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore の Web Search がフィルタリング機能を追加、東京リージョンに拡大 AI エージェントの回答を最新の Web 情報でグラウンディングする AgentCore の Web Search Tool が、東京リージョンとアイルランドリージョンに拡大されました。あわせてツール呼び出しごとにドメインの許可/除外リストや公開日の期間を指定できるようになり、情報源と鮮度に統制が求められるエージェントを構築しやすくなりました。国内でエージェントを運用している方には待望のアップデートです。 Amazon SageMaker の生成 AI 推論レコメンデーションが SageMaker AI Studio で利用可能に 生成 AI モデルのデプロイに最適なインスタンスや最適化戦略を提案する Generative AI Inference Recommendations が、SageMaker AI Studio からノーコードで利用できるようになりました。ユースケースと最適化目標を選ぶだけで実 GPU 上のベンチマークが実行され、計測データ付きの推奨構成が返ります。数週間かかっていた構成探索を数時間に短縮でき、東京リージョンを含む 7 リージョンで利用可能です。 AWS Console-to-Code が対応サービスを 32 に拡大、クロスリージョン記録に対応 コンソール操作を記録して IaC コードに変換する Amazon Q Developer の Console-to-Code が、対応サービスを 6 から 32 へ拡大しました。リージョンやブラウザタブをまたいだ操作も 1 つのリストに統合して記録できるようになり、マルチリージョン構成も文脈を失わずにコード化できます。詳細は こちらのドキュメント をご参照ください。 Kiro の週次アップデート (Web の Okta / Microsoft Entra ID 対応、CLI 2.19 ほか) Kiro Web が Okta と Microsoft Entra ID によるサインインに対応し、既存の OIDC アプリケーションの設定追加だけでチーム利用を開始できるようになりました (Kiro Pro 以上)。Kiro CLI 2.19 では、スペックレビューのマウス操作対応と、接続断やスロットリングからの自動復旧が入り、長時間セッションの安定性が向上しています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

2026 年 6 月 12 日、TOPPAN 株式会社の皆さまを対象に、AWS のハンズオンワークショップ Accelerating Smart Product SDLC with AI Agent Workshop を開催しました。本ワークショップは AI エージェント Kiro CLI を使い、ソフトウェア開発ライフサイクル（SDLC）の主要フェーズを AI と協調しながら回す体験型のワークショップです。 生成 AI をソフトウェア開発の中で個別に取り入れる動きは広がってきました。一方で、要件定義からテスト、リリース、運用まで含めた SDLC 全体に AI をどう組み込むかは、多くの開発現場が模索しているテーマです。本ワークショップは、その問いに対して 1 つの具体的な進め方を示すものです。本記事では、TOPPAN 株式会社の皆さまが当日体験した内容と、現場のエンジニアとしてつかんだ手応えを、寄稿いただく形でお届けします。 ワークショップの位置づけ 最初に、本ワークショップについて アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト の三好から少しだけご紹介させていただきます。 スマートプロダクト開発と聞くと、ハードウェア寄りの特殊な世界に見えるかもしれません。しかし本ワークショップが提示するのは、ハード固有の話ではなく、 多くのソフトウェア開発に共通する SDLC（Research → Plan → Development → Release → Operation）に AI エージェントをどう組み込むか というテーマです。題材として、ビルや施設の空調機器を制御する HVAC（Heating, Ventilation, and Air Conditioning：冷暖房・換気・空調）コントロールシステムを用いていますが、そこで得られる学びは、業務システムでも Web アプリケーションでも、SaaS でも応用できます。 特別な開発手法を新たに導入するのではなく、今ある SDLC の各フェーズに AI エージェントを自然に溶け込ませる ── それが本ワークショップの狙いです。 ワークショップは SDLC の各フェーズに対応した複数のラボで構成されており、今回は半日で SDLC の流れを体感できるよう、Lab1（Research）、Lab2（Plan）、Lab4（Release）をピックアップして実施しました。Lab3（Development）と Lab5（Operation）も Workshop Studio のカタログページ で公開されているので、ご興味のある方はそちらでお試しいただけます。 AI エージェントとして使うのは Kiro CLI で、 人間が「何を作るか」「どう作るか」を判断し、AI が手を動かす ── この役割分担を徹底する形になっています。 それでは、お待たせしました。ここからは、ワークショップに参加された TOPPAN 株式会社 IoT ソリューション事業部 ICT 本部の加納・大石の両氏による寄稿です。当日のリアルな手応えを、どうぞお楽しみください！ ※※※　以下、TOPPAN 株式会社 IoT ソリューション事業部 ICT 本部 所属の 加納・大石 両氏による寄稿です。※※※ 参加の背景 TOPPAN 株式会社の 加納・大石 です。私たちの部門では、「自社プロダクトの企画・開発」「クライアントワーク」を中心に、ハードとソフトを組み合わせた、IoT ソリューション事業 を展開しています。 加納: 私は、受託事業から自社サービスまで、IoT ソリューションを中心としたさまざまな事業領域 で フルスタックエンジニアとして自社ソリューションや社内システムの設計・開発などを担当しています。バイブコーディングによる開発が浸透する中、開発時に AI へ与えるコンテキストや AI が生成するコンテキストが、各開発者のローカルに閉じてしまう点に課題を感じていました。その結果、開発で用いる AI の思想やアウトプットに開発者間のばらつきが生じ、引き継ぎが難しくなる場面も見てきました。そこで改めて、一人の開発者が AI を活用するフェーズから一歩進み、「チームとして AI を組み込んだ開発プロセスを確立すること」や「AI 開発の再現性」を課題として捉えるようになりました。 大石: 私は、主に自社プロダクトの開発領域 で 生成 AI を組み込んだ Web アプリケーション開発を担当している入社 2 年目のジュニアエンジニアです。近年、生成 AI を開発に取り入れる動きは社内でも広がっています。一方で、実装やテストを除く、要件定義や設計、運用といった他フェーズでの本格的な活用には十分に踏み込めていませんでした。入社して 1 年は、ひたすらコーディングで AI を使ってきましたが、2 年目になり最近では、「仕様駆動開発」の手法を取り入れ始め、AI エージェントをコーディング以外の開発プロセスへどのように組み込めるか考える機会が多くなりました。 こうした課題を抱える中で、AWS から本ワークショップの案内をいただきました。SDLC 全体に AI を組み込むという発想は、まさに私たちが模索していたテーマでした。AI との真の協調へとどう移行するか、その実感を得たいという思いで参加しました。 ワークショップの全体像 参加メンバーは 20 名、開発エンジニアとプロジェクトマネジメントをメイン業務とするメンバーを中心に構成され、各自が手元の Kiro CLI を操作しながら進めました。参加者をエンジニアに限定しない点には、こだわりがありました。プロジェクトを牽引しマネジメントする立場のメンバーにも、生成 AI を組み込んだ開発プロセスの概念理解に加え、マネジメント手法も併せてアップデートする必要があると考えたためです。 今回のワークショップの題材となる HVAC コントロールシステムは、温度センサーやアクチュエーターを持つ典型的な組み込みシステムですが、その内側にあるのは「要件があり、設計があり、実装・テスト・リリース・運用がある」という、ごく一般的なソフトウェア開発の構造です。だからこそ、ここで得られる体験は、私たちが普段手がけている開発にも素直に持ち帰れると感じました。 当日の体験：実施したラボの振り返り Lab1: Research ── レガシーコードを AI に読ませ、HTML モックで新 UI を高速試作 大石: 私は、最近になって AI を活用した開発の難しさを感じていました。プロンプトだけでは自分が想像しているものと AI が解釈したものにギャップが生じることが多く、実装後に画面を見てから「思ったのと違う」と気づき、そこからまた修正するというやり取りが発生していました。Lab1 では、実装に入る前に AI が HTML で画面イメージをサクッと作成し、認識をすり合わせながら実装に進める手法を体験し、これまで課題に感じていた実装後の手戻りを減らせると思いました。 レガシーコードの画面 AI を使って検討した画面 大石: AI 駆動開発に馴染みのないメンバーでも、開発における AI 活用の基本概念を学べました。さらにハンズオン形式だったことで、人間が思考しながら AI に実行させる、まさに AI 駆動開発のプロセスを実践的に体験できました。 Lab2: Plan ── 既存コードから設計書をリバースエンジニアリングし、次世代仕様へ 加納: GitLab での Issue 管理自体を Kiro に実施させることによって、人間側は要件の精緻化などに時間をかけることができ、かつ開発コンテキストを継続的に管理できると学びました。 加納: 生成 AI が登場した当初は、AI を活用した開発は新規プロジェクトと相性が良いイメージを受けた一方で、既存プロジェクトへの導入にはまだ課題が多いと感じていました。しかし今回の Lab2 を通じて、AI 駆動開発の進化に驚きました。特に現状システムの実態と、仕様変更や改修の積み重ねによって、システムの実態と設計書をはじめとしたドキュメント類の間にはギャップが生じやすい点を踏まえると、リバースエンジニアリングという視点はシステムとの整合性を高められ、実務でも効果的に活用できる可能性を感じました。 Lab4: Release ── AWS MCP Server を活用し、AI と CI/CD パイプラインを構築 大石: AWS CodeBuild や AWS CodePipeline に触れたことがなかったため、AWS の CI/CD のサービスを実際に扱えたのがまず良かったです。さらに、MCP と AI を活用して CI/CD パイプラインをスピーディーに構築できる点が非常に興味深かったです。 加納: 日々進化している AWS サービスに追従して CI/CD を構築するには、相応の知識が必要でした。ですが AWS MCP Server を使うことで、最新情報を AI に参照させながら進められ、手戻りを大幅に減らせると実感しました。さらに、エラーが出ても AI が内容を参照して修正できるため、設定完了までほぼ自律的に動作させることができました。 加納: Lab4 の体験は、私たちがいま課題としている「チームにおける AI を活用した開発手法の確立」に向けて、大きなヒントになりました。設計の背景や意思決定の理由を Issue に記録しながら進めることで、チームとして AI を活用した開発をどのように運用するかのイメージが一気に具体化しました。さらに、開発者が日頃利用しているコードツールやチケット管理ツールと連携しながら学べたことも、得られた気づきを現場で試しやすいと感じました。 学び ワークショップを通じて、私たちは特に以下の 3 点を持ち帰りました。 ① AI を組込み「速さ」と「再現性」を両立する秘訣は、プロセスと意思決定の透明化 ハンズオンを通じて、チケット管理ツールと連携した AI 駆動開発の体験では、チームとして AI を使いこなすことで、AI 開発の「再現性」がコード生成の速さ以上に恩恵をもたらしてくれると思いました。 直面している課題、「チームにおける AI を活用した開発手法の確立」に対して、設計の意図や AI とのやり取りを記録として残し、誰がどのように判断したのかをプロジェクト管理ツールと連携させながら運用していく SDLC は、これまでに発想がなかったアプローチだったため、非常に勉強になりました。身をもってそのプロセスを実践することができたため、一人のスキルに依存しないチームでの開発プロセスを具体的にイメージすることができました。 ② AI が真価を発揮するのは新規開発だけでない、リバースエンジニアリングで「生きた設計書」を実現する 長年更新されていない設計書や、複雑化した既存コードの解読は、多くの開発現場を悩ませる課題です。今回のハンズオンでは、現状のソースコードを AI に読み解かせ、ドキュメントとして再構築するリバースエンジニアリングの威力を目の当たりにしました。この使い方は、保守運用段階や途中参画のプロジェクトにおいて、チーム全体のシステム理解を飛躍的に高めます。常にシステムの全体像と整合性を把握できる状態を保つことができ、属人化を防ぎつつ保守運用を効率化する有効性は、新たな発見でした。 ③ ツールが進化しても変わらないもの、顧客の「信頼」を守るのはリスクと向き合う人間の姿勢 TOPPAN 内には、生成 AI を高度に活用して開発を進めるチームがいる一方で、活用の適用範囲や進め方を検討しているメンバーもおり、状況はさまざまです。プロジェクトの特性上、より堅牢なセキュリティ環境が求められ「このデータを AI に渡してよいか」という判断の迷いに直面することもしばしばです。こうした、セキュリティやガバナンス基準を整備し適切に管理された環境をつくることは、早急に対応すべきであることを実感しました。 どれほど AI が手軽で優秀になろうとも、最終的なデータの取り扱いやリスクを「判断」するのは人間にしかできない役割です。個人利用の枠を脱し、組織として AI を定着させるには、この「顧客の信頼を守る」という揺るぎない基準をチーム全体で確立し、運用する仕組みが最大の鍵となります。 これからの展望 今回得た手応えを踏まえ、社内の開発プロセスへ段階的に取り込んでいく予定です。これまで AI 駆動開発に馴染みのないメンバーは、まず AI エージェントを活用した業務プロセスを取り入れるところから着手します。そのうえで、個人の AI 活用から組織への仕組みへと発展させていきたいです。並行して、AI を活用した開発を実行していく人間のリテラシーが最も重要だと感じているため、教育にも力を入れていきたいです。 今回学んだ開発手法は、あくまで “AI エージェントによる開発手法の一例” と捉えています。そのため、弊社の中でも各開発現場ごとに合ったやり方を工夫していくことが必要と感じました。メンバーの成熟度などに応じて、どこまで厳格にルールを整備するかは試行錯誤する必要がありそうです。例えば、開発チームに新人メンバーがいる場合は、skills などで厳密なワークフローを提示することも検討しています。 AI エージェントによる開発は、開発速度、正確性の向上が期待できます。その効果をチームとして高めていくために、一人の開発者に閉じずに、コンテキストが共有できる、「チームにおける AI を活用した開発プロセス」を実際の案件にも適用していくことが中期的な目標です。 (寄稿ここまで) — 本ワークショップに興味を持たれた方は、 Accelerating Smart Product SDLC with AI Agent Workshop をご覧ください。ソフトウェア開発ライフサイクル（SDLC）の主要フェーズを AI と協調しながら回すワークショップを体験いただけます。 著者 TOPPAN 株式会社 加納 広太 TOPPAN 株式会社 IoT ソリューション事業部 ICT 本部・フルスタックエンジニア（フロント / バック / クラウドインフラ） 入社以来、自社ソリューションの開発・保守に従事。クラウドインフラを強みとしつつ、バックエンド／フロントエンドを含む Web アプリケーションの設計・開発を担当。直近では、生成 AI を前提とした開発フローの整備や、開発者が生成 AI を効率的に活用するための支援に取り組んでいる。 大石 尋斗 TOPPAN 株式会社 IoT ソリューション事業部 ICT 本部・ジュニアエンジニア AWS の利用を開始して約 1 年。入社 2 年目で AWS 認定資格、SAP（AWS Certified Solutions Architect – Professional）を取得。業務では生成 AI を組み込んだアプリケーション開発に従事し、新規機能開発および改修を担当。フロント／バック／クラウドインフラまで、幅広い領域をカバーしている。 アマゾンウェブサービスジャパン 合同会社 三好 史隆 アマゾンウェブサービスジャパン 合同会社 技術統括本部 自動車・製造 ソリューション部 ソリューションアーキテクト システム構築のためのアーキテクチャ提案や人材育成のためのワークショップ提供など、技術的な面からお客様のクラウド活用をご支援しています。

イントロダクション 「変化を歓迎する」──それはアジャイルが一貫して大切にしてきた姿勢です。そしていま、生成 AI の急速な普及は、ソフトウェア開発に大きな変化をもたらしています。AI コーディングエージェントが日常のツールとなり、要件定義から実装、運用に至るまでのプロセス全体が再定義されつつあります。求められる人材のスキルも、内製化と外部パートナーの役割分担も、そのあり方が問い直されています。 だからこそ、計画に固執せず変化に適応し、短いサイクルで小さく試して学びを回し続けるアジャイルの真価が、AI 時代にこそ問われています。AI を開発のどこに委ねるのか、スピードと品質をどう両立するのか、文化を組織にどう根付かせるのか、各社の試行錯誤を持ち寄り、対話する場としてのイベントを開催しました。本記事ではその様子をご紹介します。 イベント概要 2026 年 6 月 9 日、AWS 麻布台オフィスにて「FY26 アジャイルへの取り組み 異業種情報交換イベント」を開催しました。本イベントには、株式会社サイバーエージェント様、東海旅客鉄道株式会社様、株式会社日立ハイテク様、富士フイルムホールディングス株式会社様の 4 社から、アジャイルに取り組んでいる実務者の方々にご参加いただきました（以降、参加企業名については情報保護の観点から、A 社、B 社などのアルファベット表記とします）。 参加各社が扱うプロダクトは、サプライチェーン最適化のための DX 基盤、社内向け AI プラットフォームなど多岐にわたり、業界や組織文化も大きく異なります。各社それぞれの特徴あるスタイルでアジャイル開発を推進されている点が印象的でした。 ラウンドテーブル ラウンドテーブルでは、6 つのテーマで議論を行いました。 AI、開発のどこに使っていますか？ 各社共通して、コーディング支援とドキュメント生成は確かな成果が出始めている領域として挙がりました。一方、要件定義の上流や組織横断の意思決定を伴う領域では、AI を活かしきるための運用設計がまだ模索中であることが共有されました。A 社様からは「生成 AI 支援から自動化へ」、すなわち AI に手伝ってもらう段階から AI に任せる段階への移行が次のチャレンジとして語られ、B 社様からは、AI を前提とした内製プラットフォームの社内展開で月単位の業務削減効果を計測している事例が紹介されました。AI 活用は「何に使うか」だけでなく「フィードバックをどう次の改善に回すか」が決定的に重要、という認識が共有されました。 アジャイル文化の浸透、最初の突破口は何でしたか？ 複数社から共通して挙がったのは、「動くものを早期に見せる」ことの強さです。机上の説明では伝わらない価値も、実際に動くプロダクトを目にすると一気に理解が進む、という経験は各社に共通していました。C 社様からは運用改善ワークショップを起点に Phase 分けで段階的に進め、現場の納得感を醸成しながら自動化アジャイルを浸透させている取り組みが、D 社様からは、3 年前にスクラムを始めた当初に社内の評価制度や承認プロセスとの摩擦を一つずつ解消してきた経緯が紹介されました。組織特性によってアプローチは異なりますが、「小さな成功を見せる」「現場の納得を起点に広げる」という点で各社の経験は一致していました。 スピードと品質、どう両立していますか？ A 社様からは、シフトレフト活動による後工程不良の低減と、リリーススピード重視で生まれた技術負債の精算を並行して進める取り組みが紹介されました。デプロイ頻度を継続的に伸ばす中で品質を担保し続けるための仕組み作りの重要性が強調されました。B 社様からは、機能規模の拡大に伴い毎週リリースが困難になりつつあり、リリースサイクルの見直しが必要になってきている、というリアルな悩みが共有されました。C 社様からは、ゲートキーパー型からガードレール型への運用転換、すなわち「事前審査で止める」のではなく「動きながらガードレールで守る」という発想転換が紹介されました。「品質を確保することが結果的にスピードアップにつながる」という、スピードと品質を二項対立で捉えない視点が印象的でした。 アジャイルの成果、社内にどう説明していますか？ A 社様からは、アクティブ開発者数、開発ステップ数、マージ済 MR 数、変更リードタイム、デプロイ頻度といった開発生産性指標を継続的に計測し、KLOC のような従来指標も含めた複数の物差しで価値を語るアプローチが共有されました。B 社様からは社内利用時間の業務削減効果や全社 MAU といったユーザー側の指標で価値を語る取り組みが、C 社様からは自動化による工数削減率など運用自動化ならではの ROI の見せ方が、D 社様からは、プレスリリースや AWS Summit といった外部発信を通じて社内に対しても「成果が世の中に届いている」ことを可視化する効果が紹介されました。経営層への説明においては、開発側と顧客・利用側の指標を組み合わせて多角的に価値を提示することの重要性が、改めて確認されました。 新メンバーの立ち上がり、何を工夫していますか？ A 社様からは、新規メンバーがスクラムチームへ参画する際の早期立ち上がりが現在進行形の課題として提起され、ドキュメント整備、ペア作業、徐々に責任範囲を広げる段階的アプローチが共有されました。C 社様からは運用改善ワークショップを通じて新規メンバーが業務全体像を可視化するところから始める手法が、D 社様からは自社内スクラムマスターの養成と、開発・運用・広報を並行して進める中で各役割を体験的に学ぶ仕組みが紹介されました。技術力だけでなく自律性と改善マインドを育てる重要性は過去にも取り上げられてきましたが、今回は「AI ツールに早く慣れることが立ち上がりを加速する」という新しい視点も加わりました。 ふりかえり、形骸化させない秘訣は？ お悩みのポイントは「同じ話の繰り返しになる」「アクションが実行されない」というものでした。これに対し、フォーマットを定期的に変える、外部ファシリテーターを入れる、アクションのオーナーと期限を必ず決める、次回冒頭で前回アクションをレビューする、といった具体的な工夫が共有されました。A 社様からは品質指標の推移を見ながらふりかえることで感覚的な議論ではなくデータドリブンなふりかえりを目指している取り組みが、B 社様からは Slack や Notion を活用してフィードバックを日常的に集め、ふりかえりを「2 週間に 1 度の特別なイベント」ではなく「常時走るプロセス」にする取り組みが紹介されました。「ふりかえりは儀式ではなく改善のエンジン」という言葉が印象的に残ったテーマでした。 参加者の声 イベント終了後のアンケートでは、多くの参加者から高い満足度と前向きなコメントをいただきました。 自分たちだけが持っている知見だけに捉われている部分があったので、各会社様の話を聞けて有意義な時間となった スピードと品質の両立において、品質を確保することによって手戻りが減少し、スピードアップにもつながること 他社の使用ツール、振り返り方法、要件定義から実装に移るまでのフロー、AI の活用方法を知れた 組織の制約の中でアジャイルを進める工夫をいろいろ伺えてよかった、今後の活動に活かしていきたい 一方で、「ディスカッションの時間がもう少しあると良い」「もう少し参加社数が多くても良い」など、次回に向けた建設的なご要望もいただきました。これらの声は次回イベントの企画に活かしてまいります。 まとめ 今回のイベントを通じて、いくつかの重要な気づきが共有されました。第一に、AI はアジャイルを置き換えるものではなく、アジャイルの中に組み込まれて進化を加速させるパートナーであるということです。第二に、スピードと品質は二項対立ではなく相互強化の関係にあるということです。品質を担保する仕組みが手戻りを減らし、結果的にスピードを生みます。第三に、アジャイルの成果を語る言葉は多角的でなければならないということです。開発側、顧客側、運用側の指標を組み合わせて経営層に価値を提示する力が問われます。そして最後に、「自律と改善」のマインドセット、小さな成功を積み重ねる実践的アプローチ、業界を越えた情報交換の重要性、これらは AI 時代になっても変わらないアジャイルの本質です。本イベントで参加各社が得た知見が実務に反映され、次の一歩につながることを期待しています。

Amazon Bedrock で OpenAI GPT-5.6 モデルが 25 を超える AWS リージョンから利用可能になり、クロスリージョン推論 (CRIS) に対応しました。クロスリージョン推論に対応する GPT-5.6 のモデルは Sol、Terra、Luna の 3 つで、それぞれ性能とコストのバランスが異なります。 この対応で日本拠点のお客様にとって特に重要なのは、 東京リージョン (ap-northeast-1) と大阪リージョン (ap-northeast-3) が、グローバル推論プロファイルの呼び出し元 (ソース) リージョンに含まれている ことです。すでに東京リージョンで Amazon Bedrock をお使いのお客様は、 アプリケーションの接続先リージョンを変更することなく、いま使っている環境のまま GPT-5.6 を呼び出せます。 本記事では、GPT-5.6 モデルの概要、地理的 (Geographic) 推論プロファイルとグローバル推論プロファイルの違い、そしてそれが日本拠点のお客様にとって具体的に何を意味するのかを整理します。あわせて、導入を判断する前に必ず把握しておくべきデータの所在とレイテンシの論点を扱い、最後に Amazon Bedrock コンソールで試す手順を紹介します。 コード例、IAM ポリシー、SCP、クォータ管理といった実装の詳細は、関連記事「 東京リージョンから Amazon Bedrock の OpenAI GPT-5.6 を呼び出す実装ガイド 」で解説しています。 Amazon Bedrock の GPT-5.6 Amazon Bedrock の GPT-5.6 ファミリーには、汎用のモデルと、サイバーセキュリティに特化したモデルがあります。本記事で扱うのは、クロスリージョン推論に対応する 3 つの汎用モデル (Sol、Terra、Luna) です。 3 つのモデルに共通する仕様は次のとおりです。 入力はテキストと画像、出力はテキスト コンテキストウィンドウは 100 万トークン 推論 (reasoning) モード、サーバーサイドツール呼び出し、プロンプトキャッシュに対応 OpenAI Responses API、OpenAI Chat Completions API、Amazon Bedrock Converse API から呼び出し可能 ストリーミングは Responses API と Chat Completions API の stream=True 、および ConverseStream に対応 モデル間の主な違いは、位置づけと対応リージョンです。対応リージョンは呼び出し方 (In-Region / Geo / Global) ごとに異なるため、次の表ではその区分で整理しています。最新の提供状況は、後述のドキュメントリンクからご確認ください。 GPT-5.6 Sol GPT-5.6 Terra GPT-5.6 Luna 位置づけ 最も高性能。エージェント用途・コーディング向け バランス型。日常的な本番ワークロード向け 高速・低コスト。大量処理向け In-Region (リージョン内) 対応 us-east-1 、 us-east-2 us-east-1 、 us-east-2 、 us-west-2 us-east-1 、 us-east-2 、 us-west-2 Geo ( us. ) 対応 us-east-1 、 us-east-2 、 us-west-1 、 us-west-2 同左 同左 Global ( global. ) 対応 東京・大阪を含む商用リージョン全体 同左 同左 料金はモデルごとに異なります。最新の単価は Amazon Bedrock の料金 ページをご確認ください。各モデルの提供リージョンの正式な一覧は、 Amazon Bedrock のリージョン別モデルサポート ページをご参照ください。 GPT-5.6 におけるクロスリージョン推論の仕組み クロスリージョン推論自体は Amazon Bedrock でかねてより提供されているもので、新機能ではありません。 推論プロファイル (inference profile) を通じて動作します。推論プロファイルは、モデルと、Amazon Bedrock がリクエストをルーティングできる AWS リージョンの組み合わせを定義した論理的な識別子で、生のモデル ID の代わりに指定します。 お客様はソースリージョンからプロファイルを呼び出し、Amazon Bedrock がそのリクエストを宛先リージョンにルーティングして、そのリージョンの計算リソースで処理します。 クロスリージョン推論は、第一義的にはキャパシティのための仕組みです。 1 つのリージョンで利用可能なキャパシティに縛られるのではなく、より広い計算リソースのプールを利用できるようにすることで、スループットを高め、負荷がかかった状況でも安定した性能を維持しやすくします。 GPT-5.6 のローンチでは、2 種類のクロスリージョン推論プロファイルが導入されました。この 2 つは、 データがどこで処理されうるか が異なり、その違いがコンプライアンス上の主要な判断ポイントになります。 Geo (地理的) 推論プロファイル ： us. のように地理コードが接頭辞として付きます (例: us.openai.gpt-5.6-terra )。推論処理をあらかじめ定義された地理的範囲内のリージョンに限定します。リクエストはソースリージョンから入り、その地理的範囲内の宛先リージョンにのみルーティングされます。データレジデンシー要件のあるワークロードでも、境界の内側で複数リージョンにスケールできます。 グローバル推論プロファイル ： global. が接頭辞として付きます (例: global.openai.gpt-5.6-terra )。そのモデルが展開されている、サポート対象のすべての AWS 商用リージョンに対して、リアルタイムのキャパシティ状況に基づいてリクエストをルーティングできます。最も広いキャパシティプールを利用でき、地理的な処理要件がないワークロードに適した選択肢です。 どちらのプロファイルでも、リクエストはすでに Amazon Bedrock を呼び出しているリージョンからプロファイル ID を指定して送信し、どのバックエンドリージョンが処理するかは Amazon Bedrock が決定します。レスポンスは同じ呼び出しの中で返ります。 アプリケーションのコード側で、どの宛先リージョンが処理したかを追跡する必要はありません。 補足として、次の点を押さえておいてください。 請求とクォータの消費は、どのバックエンドリージョンが処理したかに関係なく、お客様のアカウントに対して記録されます。 そのため、支出とスループットは引き続き 1 つのビューで把握できます。 グローバル CRIS を経由するデータは、そのモデルの対象リージョン群をまたいで処理される可能性があります。 処理を特定の地理的範囲に限定するデータレジデンシー要件がある場合は、該当する地理の Geo プロファイル (例: us.openai.gpt-5.6-terra ) を使うか、単一リージョンへの直接呼び出しを使ってください。 クロスリージョン推論の仕組みそのものについては、Amazon Bedrock の クロスリージョン推論のドキュメント で解説されています。GPT-5.6 の各リージョンがどの呼び出し方 (In-Region / Geo / Global) に対応しているかは、 リージョン別モデルサポート ページのリージョン別の対応表をご確認ください。 ソースリージョンと宛先リージョン まず押さえておきたいのは、 us. プロファイルのソースリージョンは米国とカナダのリージョンに限られており、東京リージョンと大阪リージョンは含まれていない 点です。つまり、東京リージョンから us.openai.gpt-5.6-terra を呼び出すことはできません。 これは仕組み上の制約ではなく、提供状況によるものです。 ご自身の環境で呼び出せるプロファイルは、次のコマンドで確認できます。 aws bedrock list-inference-profiles --region ap-northeast-1 \ --query "inferenceProfileSummaries[?contains(inferenceProfileId, 'gpt-5.6')].[inferenceProfileId,status]" \ --output table 一方で、 東京リージョンと大阪リージョンは、グローバル推論プロファイルのソースリージョンに含まれています。 以下の表は、グローバル推論プロファイル ( global.openai.gpt-5.6-sol / -terra / -luna ) を呼び出せるソースリージョンと、リクエストが処理されうる宛先リージョンの一覧です。ルーティングの内容は Sol、Terra、Luna の 3 モデルで共通です。 ソースリージョン 宛先リージョン 米国 : us-east-1 、 us-east-2 、 us-west-2 、 us-west-1 カナダ : ca-central-1 欧州 : eu-north-1 、 eu-west-3 、 eu-west-1 、 eu-central-1 、 eu-south-2 、 eu-south-1 、 eu-west-2 、 eu-central-2 アジアパシフィック : ap-southeast-4 、 ap-southeast-2 、 ap-northeast-1 (東京) 、 ap-northeast-3 (大阪) 、 ap-northeast-2 、 ap-south-1 、 ap-south-2 、 ap-southeast-1 、 ap-southeast-3 、 ap-southeast-7 、 ap-southeast-5 、 ap-east-2 中東 : me-central-1 、 il-central-1 南米 : sa-east-1 仕組み上はサポート対象の AWS 商用リージョン全体が対象。実際の処理先はモデルがデプロイされているリージョン ( us-east-1 、 us-east-2 、 us-west-2 ) 各プロファイルのルーティング対象リージョンの正式な一覧は、 リージョン別モデルサポート ページの GPT-5.6 の対応表をご確認ください。クロスリージョン推論プロファイル全般の仕様 (オプトインリージョンの扱いや、ソースリージョンによって宛先が変わる場合があることなど) は、 推論プロファイルのサポート対象リージョンとモデル ページに記載されています。 日本拠点のお客様にとって、これが何を意味するか 具体的なメリットは次の 3 点です。 1. 既存の Amazon Bedrock 利用環境をそのまま使える すでに東京リージョンで Amazon Bedrock をお使いであれば、エンドポイントもリージョン設定も、VPC エンドポイントも、CloudTrail の集約先も、いま使っているものがそのまま使えます。アプリケーションコードで変えるのは modelId (または model ) パラメータに渡す文字列だけ です。 - model_id = "anthropic.claude-...." + model_id = "global.openai.gpt-5.6-terra" 米国リージョン側にスタックやエンドポイントを追加で用意する必要はありません。 ただし、 コード以外に必要な準備が 2 つあります。 ひとつは IAM ポリシーで、グローバル推論プロファイルの呼び出しには 3 つのステートメントが必要です。もうひとつは、利用可能リージョンを制限する SCP を使っている場合の除外設定です。いずれも 実装ガイドの記事 で解説しています。 2. 単一リージョンより広いキャパシティプールを使える グローバル推論プロファイルは、リアルタイムのキャパシティ状況に基づいてルーティングします。特定リージョンの需要が高まっている時間帯でも、単一リージョンに固定した呼び出しに比べてスロットリングの影響を受けにくく、負荷時のスループットが安定しやすくなります。新しいモデルの提供開始直後は需要が集中しやすいため、この効果は特に大きくなります。 3. 運用の可観測性は東京リージョンに残る リクエストがどのリージョンで処理されても、CloudTrail のイベント、モデル呼び出しログ、CloudWatch メトリクス、Service Quotas はすべて ソースリージョンである東京 に記録されます。監視・課金・クォータ管理のダッシュボードを日本国外に分散させる必要はありません。 日本拠点のお客様が事前に理解しておくべきこと グローバル CRIS の利点と引き換えに、必ず理解しておくべき論点が 2 つあります。導入判断の前に、社内のセキュリティ・コンプライアンス担当と共有してください。 推論処理は日本国外のリージョンで行われる これが最も重要な点です。東京リージョンからグローバル推論プロファイルを呼び出した場合、 推論処理はモデルがデプロイされているリージョンで実行されます。 プロンプトと生成結果は、処理のために日本国外に送信されます。 執筆時点では、GPT-5.6 がデプロイされているのは米国の 3 リージョン ( us-east-1 、 us-east-2 、 us-west-2 ) です。 グローバル推論プロファイルという名称は「全世界のリージョンにルーティングしうる仕組み」を指しますが、実際にリクエストが到達できるのはモデルが配置されているリージョンに限られます。したがって東京から呼び出した GPT-5.6 のリクエストは、米国内で処理されます。 ただし、 この前提は将来にわたって保証されるものではありません。 グローバル推論プロファイルの宛先はモデルの展開状況に追随するため、対応リージョンが増えれば処理先も変わりえます。加えて、どのリージョンが処理するかはリアルタイムのキャパシティ状況に基づいて Amazon Bedrock が自動的に選択し、 お客様が処理先リージョンを指定することはできません。 そのため、データレジデンシーの観点では「現時点で米国内に収まっている」ことを設計の前提に置くのではなく、 地理的範囲を限定しない仕組みである という理解でご検討ください。処理範囲を確実に限定する必要がある場合は、グローバル推論プロファイルではなくジオ推論プロファイルが適切な選択肢です。 特定のリージョンで処理する必要がある場合、一般には「そのリージョンのモデルを直接呼び出す」という選択肢があります。ただし 東京・大阪リージョンから GPT-5.6 を直接呼び出す方法は提供されていません。 bedrock-runtime エンドポイントは推論プロファイルの指定を求め、生のモデル ID を受け付ける別のエンドポイント ( 実装ガイドの記事 で解説) は東京・大阪では GPT-5.6 を利用できません。そのため、処理リージョンを日本国内に固定する必要があるワークロードでは、別のモデルを検討してください。 あわせて、 不正利用検知の目的で入力プロンプトと出力結果が保存される場合がある 点を、社内のコンプライアンス担当と共有してください。GPT-5.6 を含む一部のモデルでは、自動不正利用検知の分類器がフラグを立てたトラフィックが最大 30 日間保持されます (詳細は後述の「セキュリティとコンプライアンス」を参照)。 ここで、 リージョンをまたぐデータと、ソースリージョンに留まるデータを区別しておくことが重要です。 データ 保存先 出典 モデル呼び出しログ (リクエスト・レスポンスの全文を含む) ソースリージョン (東京) モデル呼び出しのモニタリング CloudTrail イベント、CloudWatch メトリクス ソースリージョン (東京) グローバルクロスリージョン推論 不正利用検知でフラグが立った入力・出力 (最大 30 日間) 宛先リージョン (推論処理が行われたリージョン) 不正使用の検出 モデル呼び出しログについては、配信先として指定できるのが 同一アカウント・同一リージョンの Amazon S3 または CloudWatch Logs のみ である点がドキュメントに明記されています。そのため、プロンプトとレスポンスの全文を保管したい場合でも、その保管先は東京リージョン内に収まります。 一方で、 不正利用検知のために保持されるコンテンツは、処理が行われた宛先リージョン側に保存されます。 不正使用の検出のドキュメントには次のように記載されています。 If cross-region inference is enabled for these models, retained inputs and outputs are stored in destination regions (i.e., the region where your inference request is processed). この点はデータレジデンシーの検討で見落としやすいため、コンプライアンス担当と共有しておくことを推奨します。なお、リージョンをまたいで転送されるリクエストは AWS のネットワーク内を暗号化されて流れ、パブリックインターネットを経由しません。 判断のための整理は次のとおりです。 ワークロードの要件 推奨される選択 データ処理を日本国内に限定する必要がある 執筆時点では GPT-5.6 で要件を満たせません。 日本ジオ ( jp. ) の推論プロファイルが提供されている他のモデル、または東京リージョンで In-Region 呼び出しに対応した他のモデルを検討してください データ処理を特定の地理的範囲に限定したい Geo プロファイルが該当します。ただし GPT-5.6 に提供されるのは us. (米国) のみで、 東京からは呼び出せません 。米国リージョンをソースとして呼び出す構成が必要です 処理リージョンを 1 つに固定したい 東京・大阪をソースとする GPT-5.6 では実現できません。 クロスリージョン推論では処理先を指定できず (仕様上の挙動であり設定で変更できません)、日本リージョンから GPT-5.6 を直接呼び出す方法も提供されていません。別のモデルをご検討ください 地理的な処理要件はない グローバル CRIS が最適です。 最も広いキャパシティプールを利用できます レイテンシに処理先までのネットワーク往復が加わる 処理が日本国外のリージョンで行われるため、東京から呼び出す場合、ネットワークの往復時間がリクエストごとに上乗せされます。処理先が米国リージョンであれば、太平洋を往復する分の時間が加わります。 また、複数の処理先候補の中からリクエストごとに選択されるため、レイテンシは一定ではありません。 対話型 UI のように応答の速さが体験に直結するワークロードでは、次の対策が有効です。 ストリーミングを使う ： stream=True または converse_stream を使うことで、最初のトークンが届いた時点から表示を開始できます。ネットワークの往復は最初の 1 回に集約されるため、体感の待ち時間を大きく削減できます。 プロンプトキャッシュを活用する ：長い共通プレフィックス (システムプロンプトや few-shot 例) の再処理を省けるため、キャッシュ対象部分の処理時間を短縮できます。 実測する ：一般的な目安ではなく、実際のプロンプトサイズと出力長で、本番と同じ経路で計測してください。処理先が変動する性質上、 平均値だけでなく p90 / p99 も併せて確認すること を推奨します。Converse API のレスポンスには metrics.latencyMs が含まれるため、まずは短いプロンプトで往復を確認し、その後に本番相当の負荷で計測するとよいでしょう。 ストリーミングとプロンプトキャッシュの具体的な実装方法は、 実装ガイドの記事 で解説しています。 重要なのは、これがトレードオフであって欠陥ではないという点です。 バッチ処理、非同期のドキュメント処理、エージェント的なワークフロー、社内ツールなど、数百 ms のレイテンシが問題にならないワークロードは多く、そうしたケースではグローバル CRIS のキャパシティ上の利点がそのまま享受できます。一方、ミリ秒単位の応答性が要件であれば、その要件を先に確認してから設計してください。 セキュリティとコンプライアンス クロスリージョン推論は、同一リージョン内での直接呼び出しと同じ Amazon Bedrock のセキュリティモデルを使用します。リクエストは AWS Identity and Access Management (IAM) の認証情報で認証され、IAM ポリシーによってロールが呼び出せる推論プロファイルを制御できます。 Amazon Bedrock はチップレベルで実施される ゼロオペレーターアクセス (ZOA) セキュリティモデルを採用しており、AWS のオペレーターがお客様のプロンプトや生成結果にアクセスすることはできません。すべてのモデル呼び出しはお客様の IAM ポリシー配下で実行され、VPC エンドポイント経由で VPC からプライベートに到達でき、AWS CloudTrail に記録されます。データ境界ポリシーによって、アカウントやネットワークの境界をまたぐデータの流出を防ぐこともできます。 Amazon Bedrock は既定でゼロデータ保持 (ZDR) のモデルを採用しており、モデルへの入力と出力を保存しません。ただし GPT-5.6 を含む一部のモデルでは、自動不正利用検知の分類器がフラグを立てたトラフィックが、オフラインでの不正利用検知のために最大 30 日間保持されます。 クロスリージョン推論を使う場合、 保持されるコンテンツは宛先リージョン (推論処理が行われたリージョン) に保存されます。 保持されたデータは AWS が保存・処理し、お客様が明示的に許可しない限りサードパーティのモデルプロバイダーと共有されることはありません。要件に応じて、完全な ZDR の適用を AWS のアカウントチームに相談できる場合があります。 対象となるモデルと仕組みの詳細は、Amazon Bedrock ユーザーガイドの 不正使用の検出 をご参照ください。 Amazon Bedrock コンソールで GPT-5.6 を試す GPT-5.6 を最も手軽に試せるのは、Amazon Bedrock コンソールのプレイグラウンドです。コードや SDK のセットアップは不要です。プロンプトを送信し、推論パラメータを調整し、モデルを切り替えながら、API 統合の前に各モデルの感触を確かめられます。 モデルセレクターには地理的推論プロファイルとグローバル推論プロファイルの両方が表示されるため、コードを書く前にどちらのクロスリージョン推論オプションも試せます。 東京リージョンから試す手順: Amazon Bedrock コンソールを開き、 リージョンセレクターでアジアパシフィック (東京) ap-northeast-1 を選択します 。 ナビゲーションペインの Test の下から Playground を選択します。 ページ中央の Select model を選択します。 OpenAI GPT-5.6 Sol を検索し、 Global OpenAI GPT-5.6 Sol を選択して Apply を選択します。 プロンプトを入力し、 Run を選択して応答を生成します。 まとめ この記事では、Amazon Bedrock の OpenAI GPT-5.6 におけるクロスリージョン推論の仕組みと、東京・大阪リージョンをソースとして使う場合に押さえるべき論点を整理しました。 GPT-5.6 には 3 つのモデルがあります。要求の厳しいエージェント用途とコーディングには Sol、日常的な本番ワークロードには Terra、大量処理とレイテンシに敏感なアプリケーションには Luna です。 日本拠点のお客様にとって、この対応の実際的な意味は次の 3 点に集約されます。 グローバルキャパシティへのアクセス ：東京リージョンと大阪リージョンはグローバル推論プロファイルのソースリージョンに含まれます。アプリケーションの接続先リージョンを変更することなく、いま使っている環境から GPT-5.6 を呼び出せます。 スループットの改善 ：グローバル推論プロファイルはリアルタイムのキャパシティ状況に基づいてルーティングするため、単一リージョンに固定した呼び出しよりも広い計算リソースのプールを利用できます。需要が集中する時間帯でも性能が安定しやすくなります。 可観測性はソースリージョンに集約される ：呼び出しログ、CloudTrail、CloudWatch メトリクス、Service Quotas はすべて東京リージョンに記録されます。監視基盤を日本国外に分散させる必要はありません。 一方で、 グローバル CRIS を使うと推論処理は日本国外のリージョンで実行されます。 執筆時点で GPT-5.6 がデプロイされているのは米国の 3 リージョンのため、実際の処理は米国内で行われますが、グローバル推論プロファイルは地理的範囲を限定しない仕組みであり、処理先を指定することもできません。データレジデンシー要件があるワークロードには適さず、レイテンシには処理先までのネットワーク往復が加わります。導入前に、この点を社内のセキュリティ・コンプライアンス担当と共有してください。 なお、 GPT-5.6 に日本ジオ ( jp. ) の推論プロファイルは提供されていません。 推論処理を日本国内に限定する必要がある場合は、 jp. プロファイルが提供されている他のモデル、または東京リージョンで In-Region 呼び出しに対応した他のモデルをご検討ください。実際の導入時には、記事中の list-inference-profiles コマンドと AWS 公式ドキュメントで最新の対応状況をご確認ください。 次のステップ Amazon Bedrock コンソールを 東京リージョン で開き、Playground から Global OpenAI GPT-5.6 Sol にテストプロンプトを送ってみてください。 実装に進む場合は、関連記事「 東京リージョンから Amazon Bedrock の OpenAI GPT-5.6 を呼び出す実装ガイド 」で、3 種類の API のコード例、IAM ポリシー、SCP、クォータ管理を解説しています。 本番ワークロードのサイジング前に、 Amazon Bedrock の料金 ページで GPT-5.6 の最新単価を確認してください。 問題が発生した場合やコミュニティに質問したい場合は、 AWS re:Post で検索または投稿するのが有効です。 著者について 本橋 和貴 (Motohashi, Kazuki) は、AWS Japan の機械学習ソリューションアーキテクトです。AI/ML 領域には9年ほど携わっており、最近は主に自動車業界のお客様を対象にAWS の生成 AI/ML サービスのご利用をサポートしています。博士 (理学)。

デジタル庁は2026年6月12日、『行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（第2.0版）』（政府ガイドライン）を公開しました。本ガイドラインは「デジタル社会推進標準ガイドライン（DS-920）」の一つとして、政府機関による生成AIの安全かつ効果的な活用方法を包括的に示すものです。 第1.0版の枠組みを踏襲しつつ、対象範囲とリスク管理を実態に合わせて拡張・精緻化したのが第2.0版です。今回の改定では、対象とする生成AIが音声・画像にも拡大されたほか、セキュリティ要件の強化が盛り込まれ、調達チェックシートの要求事項も29項目から33項目に拡充されています。AWS は、政府機関の調達担当者とパートナー企業向けに、政府ガイドラインの調達チェックシートの各要件に対する回答例を提供します。この回答例は、Amazon Bedrock を活用したオープンソースアプリケーション『 Generative AI Use Cases（GenU） 』を用いた 生成AIアプリケーション に対応し、政府機関の調達プロセスとパートナー企業の提案書作成を支援します。 １．政府ガイドライン（第2.0版）の概要 政府ガイドライン策定・改定の背景 政府における 生成AI の活用は、行政サービスの効率化や質の向上に大きな可能性をもたらします。一方で、情報漏えいや不適切な出力などのリスクも存在するため、適切なガバナンスとリスク管理が不可欠です。今回の政府ガイドラインは、 生成AI の利活用促進とリスク管理を表裏一体で進めることを目的として策定されました。 第2.0版では、「AI事業者ガイドライン（第1.2版）」や「人工知能関連技術の研究開発及び活用の推進に関する法律」、同法に基づく「人工知能基本計画」「AI指針」など、最新の法令・指針の動向を踏まえて内容が更新されています。主な改定点は次のとおりです。 対象とする生成AIの範囲を拡大（従来のテキスト生成AIに加え、入力＝テキスト・音声、出力＝テキスト・画像・音声に対応。画像・動画生成やAIエージェント等もAIガバナンスの枠組みの対象に） 高リスク判定のリスク軸を見直し（従来の4軸から3軸へ整理。「要機密情報・個人情報の学習等の有無」の軸を整理・統合） セキュリティ確保に関する記載の拡充（ISMAP の活用、システム監査、要機密情報保護のための権限管理、生成AIの特性を考慮したログ取得 等） 調達チェックシート・契約チェックシートの詳細説明を整理 調達チェックシートとは 政府ガイドラインの中核となるのが「調達チェックシート（生成AIシステム用）」（別紙３）です。これは、政府機関が 生成AIシステム を調達する際に、事業者に対して確認すべき要件を体系化したものです。チェックシートには、納入事業者のAIガバナンス、適切なインプット・アウトプットやデータの取扱い、偽誤情報の出力防止を含む品質確保、生成AIシステム特有のリスクケース発生時の対応、国民等が利用する場合の適切な取扱い（生成AIによる出力であることの表示等）、個人情報や知的財産の保護、セキュリティや説明可能性の確保といった観点から、調達時の要求事項とその対策例が整理されています。 政府機関の企画者は、この調達チェックシートを参照して調達仕様書に要求事項を盛り込み、提案書を評価します。事業者にとっては、政府が求める技術要件を明確に把握し、適切な提案を行うための指針となります。第2.0版では要求事項が29項目から33項目に拡充され、ベンダーロックイン回避のためのアーキテクチャ要件（#12）、知的財産保護の生成段階／学習段階の分離（#24, #25）、インシデント発生後の封じ込め・復旧能力（#27）が新たに追加されています。いずれも、生成AIを「導入して終わり」にせず、調達後の運用・移行・インシデント対応まで見据えた要件強化といえます。あわせて、調達契約時に確認すべき事項を整理した「契約チェックシート（生成AIシステム用）」（別紙４）、ユースケースのリスクレベルを簡易的に判定する「高リスク判定シート」（別紙１）も用意されています。 主要なポイント ［対象範囲］ 対象システム：本ガイドラインが対象とする生成AI（原則として入力はテキスト・音声、出力はテキスト・画像・音声）を構成要素とする政府情報システム 適用開始：2026年9月1日施行（CAIO の対応事項は2026年6月30日までに必要な措置、AIガバナンスの枠組みの対象は2026年7月1日から適用） 対象外：特定秘密・重要経済安保情報・秘密文書として取扱う情報、安全保障や公共の安全・秩序の維持といった機微な情報を扱う政府情報システム ［ガバナンス体制の構築］ AI統括責任者（CAIO）：各府省庁に設置し、生成AIシステムのライフサイクルを通じた統括監理を担う 先進的AI利活用アドバイザリーボード：政府横断で調達・利活用状況の把握、高リスク案件への助言、ベストプラクティスの発信等を実施 AI相談窓口：デジタル庁が技術的・専門的観点から各府省庁を支援 ［リスク管理の仕組み］ 高リスク判定：3つのリスク軸（業務の性格／利用範囲／職員等による出力判断）でリスクレベルを評価 調達チェックシート：調達・契約時の要件確認を体系化 インシデント対応：生成AIシステム特有のリスクケースへの対応体制 ２．AWS のサンプル回答 – GenU を活用した調達チェックシート要件対応例 GenU の特徴 AWS では、政府機関の生成AI活用を支援するため、 GenU という Amazon Bedrock を活用したオープンソースのアプリケーション実装を提供しています。 GenU は最短10分でデプロイが完了する迅速な導入が可能で、セキュリティ・統制機能を標準搭載した安全性重視の設計となっています。また、チャット、RAG、文書生成、翻訳など多様なユースケースに対応しており、使った分だけの従量課金制によりスモールスタートでコスト効率よく始めることができます。 AWS サンプル回答の活用方法 政府ガイドラインでは、政府機関の生成AIシステムの調達時に「調達チェックシート」の活用が求められています。 AWS では、このチェックシートの各項目に対して、GenUを活用した場合の具体的な対応例をサンプル回答として提供し、政府機関とパートナー企業の皆様を支援いたします。サンプル回答の見方については補足資料をご参照ください。 GenUを活用した場合の具体的な対応例をサンプル回答 ［政府機関職員の皆様へ］ 調達・契約時での活用：Amazon Bedrock を活用した応札企業の技術提案と AWSサンプル回答 の対応例を照合し、データプライバシー保護や有害情報制御などの重要要件への技術的実現可能性を客観的に評価 ［パートナー企業の皆様へ］ 提案書作成での活用：調達チェックシート要件に対する Amazon Bedrock での技術的対応方針を検討し、適切な技術構成と実装方法を提案書に記載する際の参考資料として活用 ３．まとめ 政府ガイドライン（第2.0版）は、安全で効果的な 生成AI 活用のための重要な指針です。 AWS のサンプル回答は、この政府ガイドラインで示された調達チェックシート要件に対する AWS としての技術的考え方と対応例をまとめた参考資料として、政府機関の調達担当者とパートナー企業の提案書作成者にご活用いただけます。 参考情報： Generative AI Use Cases JP (GenU) Amazon Bedrock 公共機関における生成 AI の活用案 行政の進化と革新のための生成AIの調達·利活用に係るガイドライン（第2.0版） お問い合わせ 政府機関向けの 生成AI 導入に関するご相談は、 AWSパブリックセクター までお気軽にお問い合わせください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料は政府ガイドラインの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 著者： Makoto Uehara (AWS Japan, Public Sector, Senior Manager, Solutions Architect) Atsushi Kimura (AWS Japan, Public Sector, Proposal Manager)

本記事は 2026 年 8 月 17 日 に公開された「 Amazon Aurora DSQL observability concepts and usage with Amazon CloudWatch 」を翻訳したものです。 Amazon Aurora DSQL は Amazon CloudWatch Database Insights による可観測性の強化に対応しました。実際に体感するパフォーマンスや支払うコストに直結する、時間ベースのパフォーマンス診断が利用できます。 Amazon Aurora DSQL の可観測性は、DSQL クラスターの動作について具体的な改善につながる洞察を提供することを目指しています。本記事では、可観測性モデルとそのパフォーマンス・コストとの関係、そして CloudWatch Database Insights、PromQL、DSQL システム診断 AI スキルを実際に使う方法を解説します。 なぜ時間ベースの可観測性なのか Aurora DSQL は、リクエストの処理に費やした時間とリソースを反映する DPU (Distributed Processing Units) に基づいたオンデマンド料金モデルを採用しています。そのため DSQL では、データベースがユーザーのために処理を行っているときにのみ DPU が発生します。この課金モデルにより、セッションがどこで時間を費やしているかを把握することが極めて重要になります。DSQL の可観測性モデルは、まさにこの点を示してくれます。 DSQL の可観測性は、すべての開発者が気にするであろう「時間はどこで費やされているのか」に明確に答える、直接的なシグナルを提供することに重点を置いています。その大部分は時間という概念を軸に構築されており、観測する内容と体感する内容を直接結びつけます。時間はパフォーマンスにおいて最も重要な単位です。さらに、DSQL のオンデマンド料金モデル、つまり使った分だけ支払うという仕組みとも直接相関します。これは完全に意図されたもので、この相関により、観測可能なパフォーマンスと歩調を合わせてコストを管理できます。クエリが速いほど、消費する DPU は少なくなります。 DSQL は実績のあるアプローチを基盤としています。時間ベースの可観測性は、商用データベース、PostgreSQL、MySQL など、数年にわたり多くのデータベースで成果を上げてきました。DSQL はこの実績あるモデルを、分散 SQL 環境にネイティブに持ち込み、数百ものカウンターによる混乱を招くこともありません。 DASH の紹介 DSQL Active Session History (DASH) は、クラスター内のセッションのアクティビティを監視することで、可観測性メトリクスを支えています。DASH はクラスター内のすべてのアクティブなセッションを 1 秒ごとにサンプリングし、1 分間隔で集計したデータポイントを CloudWatch OTel メトリクスとして発行します。次のいずれかに該当する場合、セッションはアクティブとみなされます。 セッションが CPU を実際に消費している セッションが待機イベント (ストレージ待機やコミット待機など) でブロックされている セッションがトランザクション内にあるが、アプリケーションからのリクエストを待っている これらの状態はいずれもトランザクションのレイテンシーと DPU に影響します。DPU は DSQL の課金単位であり、その大部分はクエリの処理に費やした時間を反映します。DPU はアクティブなセッション時間に比例するため、クエリが待機に費やす時間 (または非効率な処理に費やす時間) を減らすことが、そのままコスト削減につながります。 各サンプルには追加のコンテキストが含まれ、特に重要なのはサンプル取得時点で実行されていた SQL テキストの先頭 256 文字です。これにより、サンプル取得時に何が実行され、何を待っていたかがわかります。 DASH は 1 秒に 1 回サンプリングします。一見すると粗く感じるかもしれません。しかし実際には、この頻度で「クラスター内で時間はどこに費やされているのか」という基本的な問いに答えられます。DASHはサンプリングによる統計的な全体像を提供することで、診断のオーバーヘッドを最小限に抑えつつ、ほとんどのパフォーマンス診断シナリオで根本原因を確実に浮き彫りにします。本記事の後半で示す PromQL の例が、これを実際に示しています。 DASH はデフォルトですべての Aurora DSQL クラスターで有効化されており、追加コストはかかりません。クラスターを作成した瞬間から可観測性データが得られます。 CloudWatch Database Insights Amazon CloudWatch Database Insights は、DASH データを直感的に扱う手段を提供します。2 つの重要な問い、つまり「セッションが最も多くの時間を費やしているのはどこか」「最もアクティブな SQL 文はどれか」に答えます。 図 1: 待機イベント別のデータベース負荷と最もアクティブな SQL 文を表示する CloudWatch Database Insights AWS は Aurora DSQL 向けに 1 分間隔メトリクスの CloudWatch Database Insights Standard Mode を追加料金なしで提供し、すべてのクラスターでデフォルトで有効化します。DSQL は DASH データを 15 か月間保持します。これにより、トレンド分析、キャパシティプランニング、そして長期間でしか表面化しない散発的な問題の調査に十分な履歴を確保できます。 CloudWatch Database Insights は、Amazon Relational Database Service (Amazon RDS) や Amazon Aurora (非 DSQL) のデータベースと同じ、使い慣れたビューを表示します。上部のペインには、その期間中にサンプリングされた待機イベントについて、Average Active Sessions (AAS) を使った DBLoad のタイムラインが表示されます。 RDS や Aurora (非 DSQL) のデータベースとの顕著な違いは、 Max vCPU のラインがない点です。DSQL は弾力的にスケールするため、キャパシティの上限が固定されていません。そのため、システムの健全性は本記事の後半で説明する別の方法で判断します。 下部のペインには、その期間中に最もアクティブだった SQL が表示されます。これは、サンプル取得時にその SQL 文を実行していた Average Active Sessions の数で定義されます。RDS や Aurora とは異なり、DSQL のビューには現在、累積 SQL 統計や実行計画情報へのドリルダウンは含まれていません。 待機イベント DSQL の待機イベントは、コミュニティ版 PostgreSQL と比べて数が少ないです。待機イベントのリストは、より細かい粒度を実現するために今後増える可能性はありますが、たとえば PostgreSQL 18 で現在定義されている 273 個に近づくことはまずないでしょう。これは、DSQL のクエリプロセッサ (QP) がラッチ ( LWLock )、データロック、IPC を管理する必要がないためです。これらはコミュニティ版 PostgreSQL で定義されている待機イベントの大半を占めています。次の表に、現在の DSQL の待機イベント一覧を示します。 待機名 説明 OnCpu セッションは外部からの入力を待っておらず、CPU 上で実際に実行しています。これには解析、プランニング、式の評価、結果の処理が含まれます。 ClientRead セッションはオープンなトランザクション内でアイドル状態にあり、アプリケーションが次の SQL 文またはコミット / ロールバックコマンドを送信するのを待っています。 ClientRead 待機が頻繁または長時間にわたる場合、アプリケーションの過剰なラウンドトリップや、必要以上に長く開いたままのトランザクションを示していることがよくあります。 ClientWrite 結果がネットワーク経由でデータベースからアプリケーションへ送信されています。 ClientWrite が高い場合、大きな結果セットや、アプリケーションとデータベース間のネットワークレイテンシーを示していることがあります。 Commit セッションはコミットを開始し、コミットサービスからの確認応答を待っています。応答は成功か、アボート (シリアライゼーションエラー) のいずれかです。どちらの結果も Commit 待機を経て発生します。 FkExistenceCheck セッションは参照先の外部キーの行が存在するかを検証しています。この検証には、関係を確認するための読み取りが必要です。 PgSleep アプリケーションが明示的に pg_sleep() を呼び出したため、セッションがスリープしています。これはアプリケーション起因の待機であり、データベースが課す待機ではありません。 ScatteredBatchRead セッションはストレージからのバッチ読み取りを実行し、連続していない複数のキーを 1 回のストレージ呼び出しで取得しています。 SequentialScanRead セッションはストレージから連続した範囲のキーを読み取っています。これは必ずしもフルテーブルスキャンを意味しません。比較的小さな連続キー範囲を対象とする場合もあります。 SingleRead セッションはストレージから単一のタプル (ポイントルックアップ) を読み取っています。このイベントは、バッチサイズ 1 の ScatteredBatchRead にほぼ置き換えられており、現在の DSQL バージョンではまれです。 StartTransaction セッションは分散トランザクションを開始する準備をしています。 UniqueConstraintCheck セッションは一意キー制約を検証しており、重複をチェックするためにストレージの読み取りが必要です。これは、主キー以外の列に対する一意制約と、新しい行の挿入時の主キー制約の両方に適用されます。 表 1: DSQL の待機イベント SQL 文 DSQL は SQL 文を Query ID で参照します。Query ID は、QP が SQL テキストに基づいて生成する一意のクエリ ID を base32 でエンコードしたものです。DSQL は DASH データ内のすべての SQL に Query ID を割り当てます。SQL テキストは正規化された形式で記録され、リテラル値を $ プレフィックス付きの数値識別子に置き換えられます。 PromQL による直接クエリ PromQL は、Database Insights を使う代わりに、基盤となる DASH データを直接クエリする手段です。DSQL は DASH データを CloudWatch OTel メトリクスとして公開しており、Amazon CloudWatch Query Studio で PromQL を使ってクエリできます。これにより Database Insights と同じ情報に加え、カスタム分析用の追加ディメンションが得られます。 次の PromQL の例では、3 つの一般的なユースケースを扱います。1 つ目は、どの待機イベントが最も多くの時間を蓄積しているかの特定です。2 つ目は、待機に最も多くの時間を費やしているクエリの発見です。3 つ目は、ストレージ待機で最も長く待っているクエリの特定です。Query Studio でこれらのクエリを試す前に、必ず my_cluster_id を実際のクラスター ID に置き換えてください。 Average Active Sessions によるデータベース負荷 avg by("db.wait.event") ({"db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="my_cluster_id"}) 図 2: 待機イベント別にグループ化した Average Active Sessions によるデータベース負荷 Average Active Sessions 上位 5 クエリ topk(5, avg by("db.query.normalized_text") ({"db.active_sessions.avg","@resource.aws.auroradsql.cluster_id"="my_cluster_id"})) 図 3: Average Active Sessions 別の上位 5 クエリ Average Active Sessions と待機イベント別の上位 5 クエリ topk(5, avg by("db.query.normalized_text", "db.wait.event") ({"db.active_sessions.avg","@resource.aws.auroradsql.cluster_id"="my_cluster_id"})) 図 4: Average Active Sessions と待機イベント別の上位 5 クエリ Average Active Sessions とストレージ待機別の上位 5 クエリ topk(5, sum by("db.query.normalized_text") ({"db.active_sessions.avg","db.wait.event"=~"S.*Read|.*Check","@resource.aws.auroradsql.cluster_id"="my_cluster_id"})) 図 5: Average Active Sessions とストレージ待機別の上位 5 クエリ アプリケーションの健全性 他の AWS リレーショナルデータベースサービスでは、インスタンス内の vCPU 数と同じだけのセッションが CPU 上にある状態は、健全ではない兆候です。アプリケーションからの要求が利用可能なコンピューティングを上回ると、レイテンシーが悪化します。前述のとおり、DSQL にはクラスターが需要に合わせて弾力的にスケールするため Max vCPU という概念がありません。そのため、アプリケーションの健全性を判断する別の方法が必要です。 まず、AAS の観点で健全なシステムがどのようなものかを考えてみましょう。これに唯一の答えはありません。アプリケーションごと、そしてそのアプリケーションの負荷ごとに異なります。あるアプリケーションは、5 つのセッションが同時にアクティブでストレージ読み取りを待っているときは正常に動作し、10 のセッションがストレージ読み取りを待っているときは動作が悪化するかもしれません。別のアプリケーションは、500 のセッションがストレージ読み取りを待っていても完璧に動作するかもしれません。重要な考え方は、アプリケーションごとに正常動作時の AAS プロファイルが異なるということです。待機セッションの具体的な数だけでは、健全性の低さを示すことにはなりません。 DSQL の弾力的なスケーリングの性質からも、ある日は 100、翌日は 1,000 の待機セッションがあったとしても、必ずしも健全性の低下を示すわけではありません。単にシステムが 10 倍のトランザクションを処理していることを意味するだけかもしれません。では、どうやって健全性を判断すればよいのでしょうか。 答えは、絶対的な数値ではなく、時間の経過に伴う待機イベントの割合を比較しなければならないということです。たとえば、健全なアプリケーションが次の表のような待機プロファイルを示すと仮定します。 待機イベント 待機セッション数 SequentialScanRead 40 Commit 10 OnCpu 50 表 2: 正常時の待機イベントの割合 忙しい日にはこれらの数値がそれぞれ 80、20、100 に増えるかもしれません。相対的な割合は同じままで、システムの負荷が 2 倍になっても健全であることを示しています。DSQL は追加の負荷に対応して自動的にスケールします。しかし、待機プロファイルが次の表のようになる日があれば、何かがおかしくなったとわかります。 待機イベント 待機セッション数 SequentialScanRead 90 Commit 3 OnCpu 7 表 3: 異常時の待機イベントの割合 このケースでは、アプリケーションの変更や SQL プランの変更によって、セッションが変更の処理やコミットよりもデータのスキャンに多くの時間を費やすようになった可能性が高いです。待機イベントの割合が期待される分布から大きく外れているため、これは健全でない状態です。 複雑に思えるかもしれませんが、実際には Database Insights を使えば視覚的に素早く把握できます。一貫した色の割り当てにより、通常の動作がどのようなものかをすぐに見分けられるようになります。もちろん、本番システムを適切に管理するには目視での確認だけでは不十分なため、自動アラームの設定をお勧めします。これらのアラームは、待機イベントごとの AAS の上限 / 下限のしきい値として CloudWatch で設定できます。より詳細な分析を行うには、生データに対してトレンドクエリを実行し、待機の分布を時系列で確認してください。 DSQL システム診断 AI スキル Agent Plugins for AWS の一部である databases-on-aws プラグインを使うと、DSQL システム診断のヘルスチェックが簡単になります。設定後は、さまざまな期間にわたって DSQL クラスターのパフォーマンスチェックをリクエストできます。これにより、CloudWatch MCP サーバーを使って選択した複数の期間の DASH データを分析するワークフローが起動します。エージェントにインストールすると、次のようなプロンプトを発行できます。 「us-east-1 の DSQL クラスターのパフォーマンスをチェックして、markdown レポートを作成して」 スキルはその後、履歴のベースラインと比較します。デフォルトでは、直近 1 時間、昨日の同じ時間帯、先週の同じ時間帯が対象ですが、次のようなプロンプトで変更できます。 「直近 4 時間のパフォーマンスをチェックして、先週の月曜日と比較して」 Markdown レポートの例は次のとおりです。 図 6: DSQL システム診断 AI スキルが生成した Markdown パフォーマンスレポートの例 このレポートの例では、さらに先の部分で、特定のクエリを実行計画が不適切な候補として指摘しています。 図 7: 実行計画が不適切な候補となるクエリを指摘するレポート 特定のクエリに問題がありそうな場合、スキルは SQL に特化した詳細な診断ワークフローを自動的に開始し、その SQL 文に関する診断情報を報告します。 まとめ DSQL の時間ベースの可観測性アプローチは、セッションがどこで時間を費やしているかを直感的に把握でき、観測結果をパフォーマンスの体感やコストに直接結びつけることができます。CloudWatch Database Insights による視覚的な概要把握、PromQL による DASH データの直接クエリ、DSQL スキルによる自動分析のいずれを使っても、ボトルネックのすばやい特定からクエリの最適化、DSQL クラスターの安定運用まで対応できるツールが揃っています。ぜひこれらのツールを活用して、DSQL クラスターのパフォーマンス改善に役立ててください。 著者について James Morle AWS のプリンシパルエンジニアで、Amazon Aurora DSQL に取り組んでいます。データベースのパフォーマンスとスケーラビリティに関する数十年の経験を持ち、世界最大級で最も要求の厳しいトランザクションデータベースシステムをいくつも構築してきました。開発者と運用者の双方にとってデータベースの可観測性を直感的で実用的なものにすることに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

本ブログは 2026 年 7 月 8 日に公開された AWS Blog “ The CISO’s guide to post-quantum mandates and migrations ” を翻訳したものです。 現在、十数の主要国・地域がポスト量子暗号 (PQC) の導入ガイダンスを公開しています。CISO であれば、既に移行計画をかなり進めており、最も難しい部分はアルゴリズムの変更そのものではないとご存じでしょう。リーダーシップにおける本当の課題は、大規模で複雑な組織全体で協調的な変革を推進することです。非対称暗号は、あらゆるプロトコル、あらゆるベンダー依存関係、そして目立たないところで鍵交換やデジタル署名を担っているあらゆるレガシーシステムに組み込まれているからです。このガイドでは、コンプライアンス期限を守りながら組織のセキュリティガバナンスをモダナイズするプログラムを実現する必要がある CISO、CTO、その他のシニアリーダー向けに、規制の背景と戦略的プレイブックを提供します。 多忙な経営層向けの概要 本記事の重要なポイントは次の 5 つです。 トップから始める。 暗号のモダナイゼーションを、明確なタイムラインと測定可能なマイルストーンを持つエンタープライズリスクの低減として位置づけ、取締役会レベルのスポンサーシップを確保します。この取り組みの責任を担い、優先順位付けの基準を設定し、事業部門横断でデリバリーを調整する中央集約型のプログラムオフィスを立ち上げます。 すべてをインベントリ化するのではなく、依存関係を分類する。 ワークロードレベルで理解すべきことは 3 つです。プロバイダーが代わりにアップグレードしてくれるもの、期限内にアップグレードされず置き換えが必要なもの、そして自組織が所有し直接対応しなければならないものです。移行範囲を削減する最速の方法は、可能な限り暗号の責任を最初のカテゴリ (プロバイダーが代わりにアップグレードしてくれるもの) に移すことです。 暗号テレメトリに投資する。 移行作業と並行して可視化の仕組みとモニタリングを整備します。この能力は不可欠ですが、移行の勢いを犠牲にしてはいけません。アルゴリズムの使用状況、PQC カバレッジ率、移行速度をワークロードレベルで追跡します。テレメトリは複数年にわたるプログラムを通じて取締役会のスポンサーシップを維持し、中央チームが優先順位を設定するためのフィードバックループを提供します。 一度きりのコンプライアンスではなく、俊敏性のために構築する。 目標は PQC を一度デプロイすることにとどまるべきではありません。暗号の移行は繰り返し発生する運用上の要件になるため、標準の進化に合わせてプロトコル、アルゴリズム、鍵長を切り替えられる組織的な体制を築きます。 セキュリティとガバナンスのモダナイゼーションとして扱う。 徹底したパッチ適用の規律、信頼性の高い 継続的インテグレーションと継続的デリバリー (CI/CD) 、自動化されたライフサイクル管理は、PQC 移行の後も長く活用できる能力です。これらは、脆弱性が発見されるまでの期間が数週間から数時間へと短縮される、AI によって加速された脅威に対応するために必要な能力と同じです。アルゴリズムをオンデマンドで切り替えられる組織は、AI 主導の新たなエクスプロイトに対するパッチ適用も可能です。 以下、プレイブックの全容を説明します。 グローバルな規制動向 2024 年 8 月、 NIST は、鍵カプセル化 (ML-KEM)、格子ベースのデジタル署名 (ML-DSA)、ハッシュベースの代替署名方式 (SLH-DSA) をカバーする最初の 3 つのポスト量子標準を公開しました。これらの標準は、ほとんどの国・地域が移行期限を設定する際に参照するベースラインとなっています。米国、欧州連合、英国、ドイツ、フランス、オーストラリア、カナダ、日本、韓国、インド、シンガポール、UAE はいずれも正式なガイダンスを公開しています。金融サービス業界の FS-ISAC や通信業界の GSMA のような業界団体も、独自の追加タイムラインを設けています。 これらのタイムラインは国・地域によって異なりますが、いずれも同じ方向を向いています。ほとんどの地域では、2027 年までに新規調達において PQC への対応準備を求めており、完全な移行の期限は業界や地域に応じて 2030～2035 年に設定されています。国境を越えて事業を展開する組織にとって、事業を行う各国・地域の具体的な要件に対応することは、コンプライアンスと競争上のポジショニングの両面で不可欠です。 Amazon Web Services (AWS) は、「 Migration to quantum-resistant cryptography 」ページの FAQ セクションで、地域ごとの規制と期限を詳しく整理して公開しています。 移行のスコープ設定 歴史的に見ると、暗号の移行は予想よりはるかに長い時間がかかってきました。SHA-1 の廃止は、最初に脆弱性が公表されてから主要なブラウザが最終的に拒否するまで、約 20 年を要しました。MD5、3DES、RC4 も、移行が急務であるという明確な技術的コンセンサスがあったにもかかわらず、組織の対応が遅いという同じパターンをたどりました。また、これらの移行は、現在利用できるモダンなクラウドインフラストラクチャ、自動化されたオーケストレーション、リアルタイムのテレメトリがない時代に行われました。これらの能力を活用する組織は、より速く移行しながら、同時に将来に備えたセキュリティ基盤を構築できます。 移行のスコープ設定という課題は、明確に 2 つの系統に分かれます。1 つ目は、TLS、IPsec、SSH のような有効期間の短い認証プロトコルまたは暗号化プロトコルの一部としてアルゴリズムをネゴシエートするソフトウェアシステムです。これらのワークロードについては、クラウド中心のライフサイクル管理、自動パッチ適用、集中化されたライブラリのアップグレードにより、過去の暗号移行よりも容易になっています。マネージドサービスは透過的にアップグレードを処理でき、テレメトリツールによってエンドポイント全体のアルゴリズム使用状況をリアルタイムで可視化できます。CI/CD パイプラインを使用すれば、確実なロールバック経路を確保しながら段階的なロールアウトが可能です。モダンなクラウドインフラストラクチャを持つ組織にとって、暗号移行のこの側面を高速に実行できる環境は、かつてないほど整っています。 移行対象の 2 つ目の系統は、長期間使用される組み込みシステムです。これは、鍵とアルゴリズムのコードを含むファームウェアが書き込まれ、その場でのアップデートができないデバイスです。この対象範囲を削減する最速の方法は、暗号ワークロードをマネージドサービスにオフロードすることです。これにより、プロバイダーがハードウェアの更新サイクルを引き受け、移行したワークロードの分だけ計画対象のデバイスが減ります。専用ハードウェア上に残るものについては、年次の設備投資 (capex) レビューに量子への備えを組み込みます。量子技術の進歩は決まったスケジュールで訪れるわけではないため、量子ハードウェアの進展に照らして、組み込みの暗号資産を毎年評価してください。運用上問題なく何年も使えるデバイスもあれば、脅威が現実化するまでの期間が短くなるにつれて置き換えの前倒しが必要になるデバイスもあります。年次評価を行うことで、早期の廃止は予算外の緊急事態ではなく、計画されたビジネス上の意思決定になります。 戦略的プレイブック 以下のプレイブックは、組織の状況に合わせて適用できる PQC 移行への戦略的アプローチの概要です。各ステップは、企業全体の足並みをそろえ、不明確な点を実行可能なフレームワークで解消し、プログラムへの予算確保と計画どおりの進行を維持するための測定可能な進捗を実現するように設計されています。 取締役会レベルのコミットメントを確保する CISO は、格子ベースのアルゴリズムに関する技術説明としてではなく、規制コンプライアンスと競争上のリスクに紐づくビジネスリスクの議論として、PQC を取締役会に提起する必要があります。その際には、誤解を正すことが重要です。取締役会レベルでよくある誤解の 1 つは、PQC 移行には保管中のすべてのデータの再暗号化が必要だというものです。これは事実ではありません。標準の 256 ビット対称暗号で暗号化された保管中のデータは、量子コンピュータに対して脆弱ではありません。この区別は実際の変更範囲を大幅に絞り込むものであり、スコープを過大に設定することを防ぐため、早い段階で伝えるべきです。 規制のタイムラインは具体的に提示してください。例えば、 CNSA 2.0 が 2027 年 1 月までに新製品での PQC 採用を義務付けていること、そしてこれらのタイムラインが金融サービス、ヘルスケア、政府、防衛といった規制対象の業種では調達の関門として機能することを説明します。また、規制対象の業種に属する売上とワークロードをマッピングすることで、組織のリスクエクスポージャーを定量化できます。例えば、公共部門の顧客との既存契約や進行中の商談を、リスクにさらされているビジネスの定量的なデータとして活用できます。 これを実践するとどのようになるか、例を示します。1 つ目に、規制対象の業種において、PQC コンプライアンスの文言が既に含まれている、または更新時に含まれる見込みの既存契約を特定します。それに紐づく売上を計算し、18 か月以内の更新日をコンプライアンスクリフ (期限切迫リスク) として洗い出します。2 つ目に、進行中のパイプラインを確認します。PQC への対応準備を既に参照している RFP、ベンダーアンケート、調達要件はありますか? 自組織がコンプライアンスを実証できず、競合他社が実証できる場合、そのパイプラインの価値は、選定対象から除外されるリスクにさらされます。3 つ目に、規制が発効しつつある業種における獲得可能な市場機会の総額を算定し、準備ができていなければどの程度の市場を取り逃すことになるかを示します。顧客がベンダー契約に PQC への対応準備要件を盛り込むようになっている中、コンプライアンスを実証できない組織は、将来のビジネスで選定対象から除外されるリスクがあります。 最後に、取締役会レベルのスポンサーシップのもとで、専任の人員とベンダー予算を要求します。これは既存のセキュリティ運用に吸収されるサイドプロジェクトであってはなりません。四半期ごとに定量的な成果をリーダーシップレベルで追跡する経営層レビューを優先してください。 専任の移行リーダーを任命する セキュリティ、エンジニアリング、コンプライアンス、調達にまたがる部門横断的な責任範囲を持つ暗号のセンターオブエクセレンス (CoE) を立ち上げます。プログラム全体をエンドツーエンドで所有し、経営層に直接報告する移行リーダーを任命します。PQC はネットワーキング、アイデンティティ、アプリケーション開発、ベンダー管理、コンプライアンスのすべてに同時に影響するため、これらの領域から代表者を集めてチームを構成してください。 このチームに、暗号ポリシー、ライブラリの使用、移行タイムラインに関する組織標準を設定する権限を与えます。また、同チームにベンダーやサプライヤーとの連携機能を持たせ、PQC への対応準備に関するクラウドプロバイダーやサードパーティベンダーとの関係を、責任を持つ 1 つのチームが推進できるようにします。 このチームに資金を投じ、各事業部門がゼロから作り直すのではなく再利用できる、中央集約型の対応パターンの整備を推進する役割を持たせてください。同チームが、リファレンス実装、承認済みのライブラリバージョン、テストフレームワーク、ロールアウトプレイブックを所有します。あるチームが特定のワークロードタイプの移行パターンを解決したら、中央チームがそのソリューションをパッケージ化し、組織内のすべての類似ワークロードに展開します。 依存関係を分類し、移行対象範囲を削減する 明示的に義務付けられている国・地域を除き、ボトムアップの包括的な暗号インベントリを推奨するガイダンスには注意してください。その作業は数か月を費やし、実際の移行を遅らせる可能性があります。代わりに、依存関係を 3 つのカテゴリに分類します。 他者が代わりにアップグレードしてくれるワークロード。マネージドクラウドサービス、 Software as a Service (SaaS) プロバイダー、および PQC ロードマップを積極的に進めているインフラストラクチャベンダーがここに該当します。自組織の役割は、プロバイダーのタイムラインを検証し、確実に履行されるようにすることです。 他者がスタックを所有しているが、期限内にアップグレードされないワークロード。これらは置き換えが必要なベンダー依存関係であり、計画上の耐用年数が終わる前に置き換える可能性もあります。置き換えの意思決定を調達や設備投資のサイクルに早期に組み込めるよう、今すぐ洗い出してください。 自組織が所有し、自らアップグレードしなければならないワークロード。これらについては、その場でアップグレードするか、暗号レイヤーがマネージドになるクラウドへモダナイズするかを判断します。 最初の 2 つのカテゴリはベンダーリスク評価プログラムの範疇です。3 つ目のカテゴリが、自組織内で管理し、逆算スケジュールで完了まで推進すべきワークストリームです。どの依存関係が検証済みか、どの置き換えが進行中か、自己管理のスタックのうちどれにアップグレード計画があるかを追跡します。この 3 カテゴリモデルは、際限のない棚卸し作業に陥ることなく、中央チームに明確な意思決定フレームワークを提供します。 オブザーバビリティを構築し、進捗を継続的にモニタリングする 暗号の状況を可視化することは、計画、実行、そして監査人へのコンプライアンス実証に不可欠です。ただし、オブザーバビリティをワークロード移行の前提条件にすべきではなく、移行の勢いを犠牲にしないよう、並行するワークストリームとして捉えるべきです。可視化ツールが整備された後は、それまでに完了したすべての作業を遡って示すとともに、組織レベルの進捗をリアルタイムで把握できるようになります。 多くの組織は TLS から着手します。TLS は通常、最も広範に展開された暗号であり、ウェブアプリケーション、API、マイクロサービス全体で転送中の機密データを保護する主要なメカニズムだからです。サービスログのメタデータフィールドを使ってポスト量子と従来型の TLS トラフィックを区別し、すべてのエンドポイントにわたるアルゴリズム使用状況を示す TLS メトリクスダッシュボードの構築を推進してください。「 AWS Config を使用したポスト量子暗号 (PQC) 対応の自動化 」で紹介している PQC Readiness Scanner は、この種の可視化ツールを構築・デプロイする方法の一例です。時間の経過とともに、同じオブザーバビリティを IPsec、SFTP、SSH などの他のトランスポートプロトコルにも拡張します。 全社共通の KPI を設定した継続的な評価プログラムを確立し、その結果を経営層レビューに反映できるようにしてください。テレメトリは棚卸しに役立つだけでなく、複数年にわたるプログラムを通じて取締役会のスポンサーシップを維持するための、経営層レベルの進捗メトリクスも提供します。いくつかの例を挙げます。 TLS 1.3 と ML-KEM 鍵交換を使用している TLS 接続の割合 定義したカテゴリ全体での PQC カバレッジ率 検証済みのベンダータイムラインと未確認のものの比率 新しい依存関係が非準拠として検出されてから修復までの時間 PQC カバレッジ率をワークロードレベルおよび組織レベルで追跡してください。これらのメトリクスにより、PQC 移行は一度きりのプロジェクトから継続的なガバナンス機能へと変わります。パッチ適用サイクル、脆弱性 SLA、コンプライアンス状況を既に管理しているのと同じ形です。目標は、将来の暗号移行を、そのたびに新しいプログラムを立ち上げるのではなく、日常的な運用作業として吸収できる恒常的な能力を育てることです。 ベンダー、規制当局、業界団体と連携する PQC 移行は組織の境界を越えるものであり、サプライチェーン全体での協調した動きが必要です。クラウドプロバイダーと PQC ロードマップについて対話し、どのサービスが既に PQ-TLS をサポートしているか、どれがロードマップにあるか、いつサポートが見込まれるかを把握してください。サードパーティのソフトウェアベンダーや SaaS プロバイダーに対しては、PQC サポートのタイムラインについて明確な質問を投げかけ、今後は調達要件やベンダー契約に PQC への対応準備を盛り込んでください。 自組織が属する国・地域の規制当局や標準化団体と連携し、自組織の業界に適用される具体的なタイムライン、コンプライアンスの仕組み、監査の期待事項を把握してください。金融サービス、通信、ヘルスケア、重要インフラにはそれぞれセクター固有の PQC ワーキンググループがあり、同業組織がアプローチや教訓を共有しているため、業界フォーラムにも参加してください。この協調的なアプローチは、社内に消極的なステークホルダーがいる場合に、移行に必要な投資を獲得する助けにもなります。 所有するワークロードの優先順位を付けてロードマップを策定する すべてを一度に移行しようとするのではなく、段階的なアプローチを採用してください。リスクとユースケースに基づいてワークロードの優先順位を付けます。「 AWS ポスト量子暗号への移行計画 」ブログ記事に、この優先順位付けの例が紹介されています。ロードマップの実行にあたっては、あらゆる段階で信頼性の高いリリースとロールバックの仕組みを構築してください。PQC アルゴリズムはパフォーマンスやサイズの特性が異なるため、本番環境の負荷下で予期しない挙動が現れる可能性があります。レガシーな依存関係が移行の障害になる前に特定してください。カスタム TLS ライブラリやハードコードされた暗号スイートを使用しているシステムは、プロセスの早い段階で洗い出しておく必要があります。 PQC の対象範囲を削減する最速の方法は、カスタムの暗号スタックを完全に排除することです。マネージドサービスに移行したワークロードの分だけ、チームが手動でアップグレードしなければならないワークロードが減ります。AWS は既に、パフォーマンスへの影響を体感できないほど抑えつつ、複数のサービスエンドポイントでポスト量子鍵交換を提供しており、 AWS Key Management Service (AWS KMS) と AWS Private Certificate Authority を通じてポスト量子署名も提供しています。クラウドのコンピューティング環境やオンプレミス環境の独自コードについては、 AWS-LC のようなオープンソースの暗号ライブラリが、本番利用可能で FIPS 140-3 検証済みの PQC 実装を提供しており、チームは今すぐ採用できます。 クリプトアジリティを備えた企業へ移行する クリプトアジリティ (暗号の俊敏性) とは、アルゴリズムの切り替え、プロトコルの更新、暗号の変更を、専用プログラムとしてではなく通常業務として吸収できる運用能力です。暗号標準は今後も進化し続けます。アルゴリズムは廃止され、置き換えられていきます。この能力を今のうちに構築した組織は、次回の移行時に新たなプログラムを必要としません。 クリプトアジリティには、4 つの分野での卓越性が求められます。 パッチ適用とアップグレードの規律: 現在、フリート全体で一貫したパッチ適用サイクルを維持できていない場合、PQC 移行はそのギャップをエンタープライズ規模で顕在化させます。成熟した脆弱性管理プログラムは、既存の運用の自然な延長として PQC を取り入れます。 確実なロールバックを伴う段階的リリース: PQ アルゴリズムは署名と鍵のサイズが大きく、パフォーマンスプロファイルも異なります。変更を段階的にデプロイし、本番環境で挙動を検証し、想定どおりに動作しない場合に確実にロールバックできる必要があります。 一貫した CI/CD パイプライン: 非対称暗号に触れるすべてのアプリケーションは評価が必要で、場合によっては更新されたアルゴリズムやライブラリで再構築・再デプロイが必要になります。不安定なデプロイプロセスや手動のデプロイプロセスは、移行全体の妨げになります。 自動化されたセキュリティライフサイクル管理: 証明書のライフサイクル、鍵のローテーション、シークレットの保管、署名操作、コンプライアンス検証は、すべてマシンスピードで動作しなければなりません。現在は機能している手動プロセスも、セキュリティ要件が進化するにつれて破綻します。 これらは必ずしも PQC 固有の投資ではありません。適切に運営されているセキュリティ組織の基盤となる能力です。AI によって脆弱性の発見と悪用の速度が加速する中、クリプトアジリティを運用体制に組み込んでいる組織は、AI によって加速された脅威への対応において有利な立場にあります。優れたセキュリティリーダーは、脅威の状況が進化する中で組織に必要な運用上のレジリエンスを構築する契機として、PQC を活用できます。 まとめ PQC 移行は、次世代のエンタープライズセキュリティプログラムがどのように構築され、測定されるかを決定づけるものになります。過去のどの暗号移行よりも速くこの移行を実行するための技術ツールは既に存在します。今行動する組織は調達要件を形作り、業界の競争基準を設定することになります。先送りする組織は、タイムラインの圧縮、コストの増加、選択肢の減少に直面することになります。 AWS は、PQC 移行のプロセスを進めるお客様を支援します。最新のガイダンスと資料は「 Migration to quantum-resistant cryptography 」でご覧いただけます。 AWS Security Assurance Services と AWS プロフェッショナルサービス は、お客様自身のアプリケーションとワークロードのアップグレードを支援する専門的なガイダンスと、検証済みの実装アプローチを提供します。まずは、無料の Post-Quantum Readiness Accelerator の紹介ミーティング をリクエストできます。 Rushir Patel Rushir は AWS でワールドワイドのデータ保護ビジネス開発を率いており、AWS の暗号、アイデンティティ、データ保護サービスの市場開拓戦略を推進しています。サイバーセキュリティ、クラウド、AI で 15 年以上の経験を持ち、コーポレートファイナンスと電気工学のバックグラウンドがあります。仕事以外では、ガーデニング、スキー、ワイン、旅行を楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 8 月 11 日に公開された AWS Blog “ Accelerate cyber defense with OpenAI and AWS: Daybreak Red & Daybreak Blue now available to eligible customers on Amazon Bedrock ” を翻訳したものです。 サイバー防御者がこれほど多くの能力を手にしたことはありません。そして、その能力がこれほど必要とされたこともありません。フロンティアモデルは、コードベース全体にわたって推論を行い、脆弱性を根本原因まで追跡し、数分で修正案を提案できるようになりました。しかし、同じ能力は攻撃者も利用できます。そのため、脆弱性が開示されてから悪用されるまでの期間はますます短くなっています。防御者は、広範囲に及ぶ不慣れなコードベースでも後れを取らずに対応し、どの検出結果が重要かを検証し、確実に機能するパッチをリリースすることが求められます。しかもこれらすべてを、機密性の高いコードや脆弱性データを自らが管理・監査できる環境内に保持したまま行わなければなりません。もはや課題は潜在的な問題を見つけることではなく、どれが本当の問題かを見極めて修正し、その対応を攻撃者に悪用される前の限られた時間内に完了させることにあります。 AWS は、セキュリティを最初から組み込むという原則に基づいて一貫して事業を行ってきました。これは AI についても同様です。お客様は、推論から完全自律型のエージェントまで、さまざまなワークロードを Amazon Bedrock で実行しています。そこに適用されるインフラストラクチャ、コントロール、ガバナンスは、お客様が AWS 全体で信頼して利用しているものと同じです。本日 (2026 年 8 月 11 日)、AWS と OpenAI は、この基盤をサイバー防御にも広げます。OpenAI の Daybreak Red と Daybreak Blue を、対象のお客様向けに Amazon Bedrock で提供開始しました。Daybreak Red は、サイバーセキュリティ専用にトレーニングされたモデルである GPT-5.6 Cyber へのアクセスを提供します。Daybreak Blue は、安全対策を防御的なサイバーセキュリティ業務向けに調整した GPT-5.6 Sol へのアクセスを提供します (訳注: 一般提供されている GPT-5.6 Sol とは提供形態が異なり、利用には後述の Trusted Access for Cyber への登録が必要です)。どちらも、OpenAI のサイバー防御イニシアチブである Daybreak の一部であり、防御者にフロンティア AI への統制されたアクセスを提供します。Daybreak には、エージェント型ツール、アプリケーションのレッドチーム演習、検出結果から検証済みの修正へと進むための支援サービスが含まれます。 「AWS と OpenAI は、防御者が優位に立つべきだという考えを共有しています。この提携により、OpenAI の Daybreak Red と Daybreak Blue を Amazon Bedrock で提供します。AWS のセキュリティチームは現在、両方のモデルを使用してソースコードの分析、脆弱性の発見、レッドチームの調査を行っています。Amazon Bedrock 上でのこの作業は、AWS が他のすべての重要なワークロードに適用しているのと同じインフラストラクチャコントロールのもとで実行されます。これらのモデルが進化を続けるにつれて、防御者が Amazon Bedrock 上でこれらのモデルを使ってできることも進化していくでしょう」 — AWS Security Vice President John Sheehan 許可を得た高度なサイバーセキュリティ業務向けの専用モデル 脆弱性の発見から修正までの道のりは長いものです。悪用可能性の確認、脆弱なコンポーネントへの到達経路の追跡、リグレッションを引き起こさずに根本原因に対応する修正の開発、現実的な条件下でその修正が機能することの検証、そして開示後の限られた期間内でのパッチのリリースが必要です。防御者には、これらすべてのステップを加速できるモデルが必要です。しかし、サイバーセキュリティは本質的にデュアルユース (防御にも攻撃にも利用可能) です。脆弱性の再現やエクスプロイトチェーンのリバースエンジニアリングを求めるリクエストは、意図の善悪にかかわらず同じように見えるため、汎用モデルはリクエストを拒否することでこの曖昧さを解消します。Daybreak Red と Daybreak Blue は、誰がモデルを使用しているのか、作業がどこで行われるのか、そのアクセスをどのような安全対策が管理しているのか、というコンテキストによってこの問題を解決します。 ほとんどのセキュリティチームにとって、Daybreak Blue が適切な出発点になります。Daybreak Blue は、脆弱性の発見、検出エンジニアリング、インシデント対応をサポートします。Daybreak Red は、脆弱性調査、エクスプロイトの再現、対策の開発といった高度なタスク向けに設計されています。これらのタスクでは、拒否しきい値 (モデルがリクエストを拒否する基準) を下げつつ、それに見合った強力な本人確認、モニタリング、アクセスコントロールを組み合わせることで、調査のスピードと深さを高められます。 OpenAI によると、セキュリティ研究者は Daybreak Red を通じて GPT-5.6 Cyber を使用し、Chrome で使用されている JavaScript エンジンである V8 において、これまで知られていなかった 2 つの脆弱性を特定しました。これらを連鎖させると、メモリ破壊とヒープサンドボックスエスケープを引き起こす可能性がありました。最初の脆弱性は修正され、CVE-2026-15903 として公開されました。これは、2026 年に V8 CTF で成功したわずか 4 件のゼロデイエントリのうちの 1 つです。 すでに信頼している基盤の上で実行 サイバーセキュリティのワークロードでは、独自のソースコード、未修正の脆弱性の詳細、本番システムからのライブテレメトリといった、最も機密性の高い情報をモデルに入力します。これらの情報がモデルを通過する前に、それがどこに送られ、誰が見ることができるのかを確実に把握しておく必要があります。 両モデルは、高いパフォーマンス、セキュリティ、信頼性を実現するために構築された Amazon Bedrock の次世代推論エンジン上で動作します。ゼロオペレーターアクセス (ZOA) はチップレベルで強制されるため、AWS のオペレーターであっても推論中のプロンプトや出力にアクセスすることはできません。データは転送中および保管中に暗号化されます。アクセスは AWS Identity and Access Management (IAM) ポリシーによって管理され、AWS CloudTrail に記録され、仮想プライベートクラウド (VPC) エンドポイントを経由します。組織レベルでデータ境界ポリシーを設定することで、アカウントやネットワークの境界を越えたデータの流出を防ぐことができます。 推論データはモデルトレーニングに使用されず、どちらのモデルでも OpenAI とのデータ共有にオプトインする必要はありません。 自動不正使用検出 のために、分類器によってフラグが付けられたトラフィックは AWS によって最大 30 日間保持され、プログラムによって処理されます。これらのモデルでゼロデータ保持を必要とする場合は、AWS アカウントチームを通じてリクエストできます。詳細については データ保持 を参照してください。 利用開始方法 Daybreak Red: GPT-5.6 Cyber と Daybreak Blue: GPT-5.6 Sol を、次の AWS リージョン の Amazon Bedrock で、対象のお客様向けに提供開始しました: 米国東部 (オハイオ)。これらのモデルを利用するには、OpenAI の Trusted Access for Cyber への登録が必要です。登録するには、OpenAI にご連絡いただくか、対象条件については AWS アカウントチームにお問い合わせください。承認された後は、AWS アカウントチームと連携して AWS 側でアクセスをリクエストしてください。詳細については、 ドキュメント を参照してください。 Amazon Bedrock 上の GPT-5.6 ファミリー全体の詳細については、「 Get started with OpenAI GPT-5.6 Sol, Terra, and Luna on Amazon Bedrock 」を参照してください。 Amazon Bedrock がお客様をどのように支援できるかにご興味がある方は、 お問い合わせ ください。 著者について Tanvi Girinath Tanvi は Amazon Web Services (AWS) で Amazon Bedrock を担当するプロダクトマーケティングマネージャーです。お客様が Amazon Bedrock を使用して AI アプリケーションやエージェントを導入し、スケールするための支援を行っています。 Saurabh Trikande Saurabh は Amazon Web Services (AWS) で Amazon Bedrock を担当するシニアプロダクトマネージャーです。主要プロバイダーのフロンティアモデルによる推論を、あらゆる規模のお客様にとってパフォーマンス、セキュリティ、コスト効率に優れたものにする取り組みを主導しています。 Chris Dickens Chris は OpenAI の Member of Product Staff として OpenAI API を担当しています。Amazon Bedrock における AWS との連携にも取り組んでおり、OpenAI のフロンティアモデルを開発者が広く利用できるようにする活動を行っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

AWS では、AI を活用した新しいソフトウェア開発手法「 AI-DLC（AI-Driven Development Life Cycle） 」を提唱しています。AI-DLC は、AI を単なる補助ツールとしてではなく、要件定義から設計・実装・テストまでの開発ライフサイクル全体に組み込みながら、人間が主導権を握る（Human-in-the-Loop）ことを前提とした開発手法です。この AI-DLC を短期間で体験・実践いただくワークショップが「AI-DLC Unicorn Gym（以下 UG）」です。 2026 年 6 月 11 日〜12 日、株式会社サンリオ デジタル事業開発部の皆様と 2 日間の「サンリオ AI-DLC UG」を開催しました。本記事では、開催レポートと、参加メンバーの皆様に体験を語っていただいた座談会の様子をお届けします。 1. サンリオ AI-DLC Unicorn Gym 開催レポート サンリオ AI-DLC Unicorn Gym 参加メンバー サンリオのデジタル事業開発部は、「キャラフォリオ」（公式とファンがつながる創作プラットフォーム）や「オモイデバッジ」（イベント参加記録・ユーザー交流 SNS）など、デジタルプロダクトの企画・開発を担っています。2025 年から開発の内製化に舵を切り、少数精鋭のチームで Claude Code を中心とした AI 活用開発を実践してきました。個人の生産性向上の先にある「チームとして、上流工程からどう AI を組み込むか」という課題への答えを求めて AI-DLC に着目されたことが、今回の開催のきっかけです。 当日はデジタル事業開発部 プロダクト開発課 シニアマネージャー 倉井 龍太郎 氏をはじめとする 2 チーム 6 名のエンジニアとプロダクトマネージャーが参加し、実際のプロダクトを題材に AI-DLC の全フェーズを体験しました。ツールには Kiro を利用し、AI エージェントを中心に据えた開発ワークフローを実践しています。AWS 側はアカウントマネージャーの荻原 賢大、ソリューションアーキテクトの山澤 良介・瀧田 直斗が各チームに伴走しました。 チーム テーマ 技術構成 成果 チーム A （オモイデバッジ） オモイデバッジ 管理機能拡張 — パッケージ詳細への URL リンク設置 TypeScript / Kiro inception から本番マージまで 約 5 時間 で完了。デプロイ済み。 チーム B （新規アプリ） 新規アプリの立ち上げ TypeScript / Kiro 管理者向け管理画面まで構築完了 チーム A の成果 — 「作らない」判断と、約 5 時間での本番マージ チーム A では 2 つのユーザーストーリーを検討しました。1 つ目は、AI と一緒に価値と実現方法を掘り下げた結果「機能を実装しなくても運用でカバーできる」と判断し、あえて実装しないことを選択。AI で実装が速くなるほど「何を作らないか」の判断に価値が生まれることを示す成果となりました。 2 つ目のストーリー「パッケージ詳細への URL リンク設置」では、AI-DLC の全フェーズを一気通貫で体験しました。 時刻 フェーズ 内容 Day 2 10:59 Inception インタビュー型の add-inception スキルを作成 Day 2 13:59 Inception AI のインタビューを受けて inception ドキュメントを作成・マージ Day 2 15:03 Construction 既存の設計スキルで設計書を作成し、自律実装へ Day 2 15:58 マージ backend / API / 管理画面 / アプリの実装をマージ inception 開始から本番マージまで 約 5 時間 2. 座談会 — 参加メンバーに聞く 荻原（AWS） 今回の AI-DLC UG が実現した経緯を教えてください。 倉井氏（サンリオ） 日頃から Claude Code を使って開発していましたが、個人の生産性は上がっても「チームとして、上流工程からどう AI を組み込むか」がずっと課題でした。AWS の AI-DLC のブログを見つけたとき、まさにこれだと思って、すぐにミーティングで相談しました。 荻原（AWS） AI にインタビューされながらユーザーストーリーを作るプロセスはどうでしたか。 チーム A メンバー（サンリオ） 「何を・誰に・どんな価値を・どう検証するか」を AI が順番に聞いてくれるので、抜け漏れを防げました。価値のコンフリクトや成功指標など、一人では飛ばしがちな観点を確実に通過できたのが大きいです。またインタビューをスキル化し、改善ステップも組み込んだので、誰がやっても同じ品質のインセプションプロセスを踏めるようになりました。 荻原（AWS） AI-DLC を体験したことで、今後の開発にどう活かしていきたいですか。 倉井氏（サンリオ） 大きく 2 つあります。1 つ目は、インセプションプロセスで言語化することで、企画側の目的をしっかり理解した上で開発が進められ、手戻りを大幅に減らせること。2 つ目は、ユーザーストーリーを書くことでプロジェクトメンバー全員が同じ情報を持った上で開発が進むことです。非常にスムーズでした。 チーム A メンバー（サンリオ） 今後は実際の開発フローに PM の作業も組み込みたいと考えています。PM・エンジニアの「作業」をエージェントに任せて、人間は設計とレビューに専念する — それが目指す姿です。 倉井氏（サンリオ） 内製化を進める中で「少人数でいかに大きな価値を届けるか」が常に課題です。AI-DLC はそのための方法論として非常に手応えを感じました。AI-DLC の旅はまだ始まったばかりです。 3. 今後の展開と AWS の支援 サンリオ デジタル事業開発部では、今回の UG で得た知見を実プロダクト開発に本格導入していく予定です。 Inception の標準化 — 今回作成したインタビュー型スキルをチーム標準プロセスとして運用開始 「人間は設計とレビュー」モデルの実践 — AI が実行し、人間が監視・判断する AI-DLC の本質を日常の開発に浸透させる ワークショップを運営して感じたのは、AI-DLC の Inception フェーズが Amazon の Working Backwards （お客様の体験から逆算して考える手法）と本質を同じくする、ということです。「誰に・どんな価値を・なぜ届けるのか」を AI のインタビューに答えながら言語化し、チーム全員で合意する。AI が「問い」を投げかけることで議論の抜け漏れが構造的に防げるため、経験の浅いチームでも質の高い要件定義ができるようになります。 AWS は、サンリオの AI 活用パートナーとして、UG で作成したスキルの実プロダクトへの適用と AI 駆動開発の定着を引き続き支援してまいります。倉井氏をはじめ、ご参加いただいた皆様、ありがとうございました。 本記事は、2026 年 6 月 11 日〜12 日に開催した「サンリオ AI-DLC Unicorn Gym」および参加メンバーの皆様との座談会をもとに構成しました。 著者プロフィール 荻原 賢大 アマゾン ウェブ サービス ジャパン合同会社 営業部 広域事業部門。株式会社サンリオを担当するアカウントマネージャー。お客様のビジネス変革を技術で支援することに情熱を注いでいます。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への展開にも取り組んでいます。 山澤 良介 AWS のソリューションアーキテクトとして、製造業を中心にエンタープライズ企業の支援をしています。その活動の傍ら、最近は Claude Code / Cowork の国内展開に向けた技術支援やコンテンツ作成に取り組んでいます。

本記事は 2026 年 8 月 20 日 に公開された「 Long-term system tables retention in Amazon Redshift with Amazon S3 Tables 」を翻訳したものです。 Amazon Redshift のシステムテーブルは、実行されたすべてのクエリ、確立されたすべての接続といった運用シグナルを継続的に記録します。収集したデータは、データウェアハウス全体の可観測性、パフォーマンス分析、コンプライアンス監査を支えます。しかしこれまで、システムテーブルがこの重要なデータを保持できる期間はわずか 7 日間で、独自の回避策なしに長期的なコンプライアンス対応や監査を行うのは困難でした。 Amazon Simple Storage Service ( Amazon S3 ) の機能である Amazon S3 Tables と Amazon Redshift システムテーブル の統合により、システムテーブルのログデータが自動的に Amazon S3 Tables に配信され、 Apache Iceberg 形式で保存されます。Amazon Redshift システムテーブルの保持期間を現在の 7 日間の上限を超えて設定でき、独自の ETL パイプラインやクラスターリソースを消費することなく、コンプライアンス対応、監査、ウェアハウス横断の可観測性を長期にわたって実現できます。データはオープンかつ堅牢で、Amazon Redshift、 Amazon Athena 、 AWS Glue 、 Amazon EMR 、その他の Apache Iceberg 対応エンジンからクエリできます。 本記事では、Amazon Redshift システムテーブルの統合がどのようにログデータを Amazon S3 Tables に配信するのかを解説します。本機能は、RA3 および RG のプロビジョンドクラスターと Amazon Redshift Serverless ワークグループでサポートされています。 課題 Amazon Redshift を運用していると、システムテーブルの保持期間が 7 日間に制限されていることに起因する運用上の課題によく直面します。 クエリの傾向が把握しにくい: 同じクエリの 30 日前と現在のパフォーマンスを比較したいことがあります。パフォーマンスが徐々に変化する場合、長期的なベースラインがあれば、場当たり的なトラブルシューティングではなく、データに基づいた根本原因分析が可能になります。 変更前後の比較: 新しいワークロードの追加、インスタンスタイプの変更、 Workload Management (WLM) キューの調整を行う際には、その影響を正確に測定したくなります。保持期間を延長すれば、必要なベースラインデータを残しておけます。 季節性を考慮したキャパシティプランニング: 月末のスパイク、四半期末の急増、年間のピークを把握して計画するには、数か月分の履歴データが必要です。保持期間を延長すると、数か月から数年にわたる季節的なパターンが見えてきます。 独自 ETL パイプラインの負荷: 保持期間の制限を回避するため、システムテーブルのデータを 1 時間ごとまたは 1 日ごとに Amazon Redshift マネージドストレージ内の永続テーブルにコピーする独自パイプラインを構築するチームもあります。こうしたパイプラインはクラスターリソースを消費し、本番ワークロードと競合し、継続的なエンジニアリング保守を必要とします。Amazon Redshift がシステムテーブルのスキーマやデータ共有の設定を更新すると、パイプラインには手作業での対応が必要になり、記録に欠落が生じます。 コンプライアンス要件: 規制対象の業界では、数か月から数年に及ぶ監査証跡の保持が求められます。7 日間の上限のもとでこの要件を満たすには、独自のインフラが必要でした。Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、この課題が解決されます。 仕組み Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、Amazon Redshift システムテーブルのデータを Apache Iceberg 形式で自動的に Amazon S3 テーブルに書き込むフルマネージド機能です。パーティショニング、圧縮、保持期間の管理は AWS が自動的に処理します。ログの書き込み処理は独立したバックグラウンドプロセスで実行され、本番ワークロードとのリソース競合を抑えます。パイプラインの管理は AWS が代行します。 本機能はリリース時点で 25 を超えるシステムビューをサポートしています。サポート対象のシステムビューについては ドキュメント を参照してください。 セットアップ Amazon Redshift コンソールから Amazon S3 Tables とのシステムテーブル統合を有効にするには、次の手順に従います。 Amazon Redshift コンソールを開き、[System table integrations] ページに移動します。プロビジョンドクラスターまたは Serverless ワークグループの詳細ページからもアクセスできます。 Create System table integration を選択します。設定ウィザードが起動します。 本機能を有効にする Amazon Redshift プロビジョンドクラスターまたは Amazon Redshift Serverless ワークグループを選択します。   図 1: システムテーブル統合ウィザードでの Amazon Redshift データウェアハウスの選択 Available system tables リストから公開するシステムビューを選択します。個々の SYS_* ビューを選ぶか、 Select all supported system tables を選択して、現在および将来サポートされるすべてのビューを公開します。すべてを選択した場合、将来追加される新しいビューは設定を変更しなくても自動的に含まれます。   図 2: [Available system tables] リストから公開するシステムビューを選択 デプロイモデルを選択します。Amazon S3 Tables でのデータの整理方法を選びます。 データウェアハウスごと・システムテーブルごとに個別の S3 テーブル : 各ウェアハウスのデータを専用のテーブル群に保持します。 データウェアハウス横断でシステムテーブルごとに共有の S3 テーブル : アカウント内の複数のウェアハウスのデータを共有のテーブル群に集約します。 必要に応じて、AWS Key Management Service (AWS KMS) のカスタマーマネージドキーで暗号化を設定します。デフォルトでは、データは Amazon S3 マネージドキー (SSE-S3) で暗号化されます。 変更を保存します。Amazon Redshift は選択したビューの Amazon S3 Tables への公開を開始し、一定の間隔で新しいレコードを追加し続けます。 統合が有効になっているかを確認するには、次のようにします。 クラスターまたはワークグループの詳細ページに移動します。 統合のステータスと、各ビューの最終取り込み時刻を確認します。 公開されたデータは Amazon S3 Tables コンソールからも確認できます。 有効化すると、Amazon Redshift は本番ワークロードとは別の独立したバックグラウンドプロセスを通じて、定期的にログデータを Amazon S3 テーブルに書き込みます。保持されたログのクエリを開始するには、AWS Glue Catalog を介して Amazon Redshift 環境と Amazon S3 Tables のデータを接続する初回セットアップが必要です。次の手順を実行します。 AWS Glue Data Catalog と Amazon S3 Tables へのアクセスに必要な権限を持つ AWS Identity and Access Management (IAM) ロールを作成し、Amazon Redshift クラスターまたは Amazon Redshift サーバーレスネームスペースに関連付けます。 AWS Glue Data Catalog で、ログが格納されている Amazon S3 Tables データベースを指すリソースリンクを作成します。 Amazon Redshift で、リソースリンクを参照する外部スキーマを作成します。 CREATE EXTERNAL SCHEMA <schema_name> FROM DATA CATALOG DATABASE '<resource_link_database>' IAM_ROLE '<iam_role_arn>'; 設定が完了すると、使い慣れた 2 部構成の表記法で過去のシステムテーブルデータをクエリできます。 SELECT * FROM <schema_name>.<table_name>; Amazon S3 Tables へのアクセスは読み取り専用のため、監査証跡の整合性は本質的に保たれます。 IAM ポリシーの例を含む詳細なセットアップ手順については、 S3 Tables と Data Catalog の統合の有効化 を参照してください。 データは Apache Iceberg 形式で保存される システムテーブルのデータは、オープンテーブル形式である Apache Iceberg で保存されるため、互換性のあるクエリエンジンを自由に選べます。可観測性や監査のデータを、すでに使っているツールでそのまま扱えます。 運用データは次のサービスで分析できます。 Amazon Redshift: S3 テーブルバケットを AWS Glue Data Catalog と統合したうえで、Amazon Redshift でリソースリンクを指す外部スキーマを作成し、保持されたテーブルをクエリします。 Amazon Athena: インフラのプロビジョニングなしで、過去のログに対してサーバーレスの SQL クエリを実行します。 AWS Glue: 運用データを基盤に、自動化されたデータ処理・変換ジョブを構築します。 Amazon EMR: 複雑なウェアハウス横断分析のために、Spark ベースの分析を大規模に実行します。 データは Amazon S3 Tables にオープンな Apache Iceberg 形式で保存されるため、Amazon Redshift、Amazon Athena、自然言語クエリ用の AI エージェントスキル、 Amazon SageMaker Unified Studio 、Iceberg 対応エンジン、ビジネスインテリジェンス (BI) ツール、可観測性システムなど、さまざまな手段でクエリできます。 コスト効率 Amazon Redshift から Amazon S3 Tables へのログ配信に追加費用はかかりません。料金が発生するのは、Amazon S3 Tables のストレージ、メンテナンス、および選択したエンジンでのデータのクエリに対してのみです。 ソリューションの概要 以下のシナリオでは、Amazon Redshift システムテーブルと Amazon S3 Tables の統合が、Amazon Redshift 環境全体でよくある運用・コンプライアンス・可観測性の課題をどのように解決するかを紹介します。また、本機能のために専用のスキル querying-aws-redshift を用意し、AWS MCP Server に組み込みました。これにより、Amazon S3 Tables から Amazon Redshift システムテーブルをクエリできます。 シナリオ 1: クエリの傾向を長期的に追跡する 数か月から数年分の SYS_QUERY_HISTORY データを保持しておけば、個々のクエリのパフォーマンスを長期間にわたって追跡できます。あるクエリの実行時間、キュー時間、リソース消費量を、日単位・週単位・月単位で比較できます。 パフォーマンスが劣化し始めた時期を正確に特定し、新しいスキーマ、データ量の急増、同時実行ワークロードの追加といった変更と関連付けられます。保持期間を延長することで、トラブルシューティングは事後対応から、先を見据えたデータドリブンな根本原因分析へと変わります。 シナリオ 2: 変更前後のワークロードへの影響を評価する 新しい ETL パイプライン、インスタンスタイプの変更、Workload Management (WLM) キューの調整、アドホッククエリを実行するアナリストチームの追加など、ワークロードの変更はいずれもシステムに影響します。問われるのはいつも、その変更がパフォーマンスにどう影響したかです。 Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、自信を持ってデータに基づいた意思決定ができます。 SYS_QUERY_HISTORY をクエリして、変更前の数週間と変更後の数週間で、実行時間、キューでの待機時間、同時実行スケーリングのイベントを比較します。2 週間前に新しいレポートワークロードを導入し、既存のクエリへの影響を把握したい場合、それを確認するためのデータはすでに揃っており、独自パイプラインは一切不要です。 シナリオ 3: 可観測性ダッシュボードを構築する システムテーブルのデータは Apache Iceberg で保存され、AWS Glue でカタログ化されます。つまり、Apache Iceberg を読み取れる可観測性ツールやビジネスインテリジェンス (BI) ツールから直接接続できます。経営層向けのレポートとして、ワークロードの分散傾向を Amazon Quick Sight で可視化できます。より深い分析や、運用データからの AI 主導のインサイト生成には、Amazon SageMaker Unified Studio を利用します。AWS のサービスにとどまらず、使い慣れたサードパーティの可観測性システムや BI ツールを接続して、クエリ量の追跡、接続パターンの監視、異常検知のアラート設定、あるいは Amazon Redshift の運用データとアプリケーションレベルのログの相関分析も行えます。 可観測性や監査のデータを、すでに使っているツールでそのまま活用できます。堅牢で構造化された運用データに、好みのツールから直接アクセスできます。 シナリオ 4: 季節性を踏まえてキャパシティを計画する ワークロードの需要は 1 年を通じて変動します。月次決算、四半期末のレポート、年間の計画サイクル、プロモーションイベントはいずれも予測可能な使用量のスパイクを生みますが、それはパターンを見て取れるだけの履歴データがあってこそです。 保持期間を延長すれば、複数のビジネスサイクルにまたがる使用状況の傾向を分析できます。キャパシティの上限に常に近づくのはいつかを特定し、需要が四半期ごとにどう変化するかを測定し、プロビジョニング済みのリソースが実際の使用量と見合っているかを検証できます。 シナリオ 5: コンプライアンスの監査証跡を維持する 規制対象の業界にとって、保持期間の延長は、整合性を標準で備えたフルマネージドの監査証跡をもたらします。 SYS_CONNECTION_LOG はすべての認証試行を記録します。 SYS_USERLOG はユーザーアカウントの変更を記録します。 SYS_QUERY_HISTORY はウェアハウスに対して実行されたすべてのクエリを記録します。 保持期間は、90 日、1 年、あるいは数年など、組織のデータ保持ポリシーに合わせて設定します。読み取り専用のアクセスポリシーにより、書き込み後のレコードが管理者を含む誰かによって改変されるのを防げます。 シナリオ 6: ウェアハウス群全体で運用の可観測性を一元化する 複数の Amazon Redshift ウェアハウスを運用している場合、運用データを統合的に把握できるメリットがあります。本機能は、組織構造に合わせて 2 つのデプロイパターンをサポートします。 ウェアハウスごとの個別テーブル: 各ウェアハウスが専用の Amazon S3 テーブルに書き込むため、コンプライアンス上の配慮が必要な環境向けに完全なデータ分離を実現します。複数のウェアハウスをまとめてクエリするには、 UNION 操作が必要です。 共有テーブル: 同じアカウント・同じ AWS リージョン内のウェアハウスが、共有された 1 組の Amazon S3 テーブルに書き込み、データは warehouse_name 列で区別されます。ウェアハウスで絞り込めば、クラスター横断の分析をすぐに行えます。 ベストプラクティス プライバシー上の理由でログの分離が必要なウェアハウスを特定し、それらには ウェアハウスごとの個別テーブル オプションを選択します。残りのウェアハウスには、管理を簡素化するために 共有テーブル (集約) オプションを使用します。 保持期間はコンプライアンス要件に合わせます。ストレージコストを抑えるため、コンプライアンス要件を満たす最小限の保持期間を設定します。 保持されたシステムテーブルをクエリする際は、 warehouse_account_id 、 warehouse_region_name 、 warehouse_namespace_arn 、 warehouse_name 、 s3_tables_ingestion_time などのメタデータ列で絞り込み、スキャン範囲を減らしてパフォーマンスを高めます。複数のウェアハウスにまたがる大量の履歴データをクエリする場合は、特に重要です。 監査証跡の整合性は、標準で備わる読み取り専用アクセスに任せます。保持期間や暗号化の設定は、Amazon S3 Tables の設定 API で管理します。 暗号化の方針は早い段階で計画します。設定後の変更には統合の再作成が必要になるため、暗号化キーはセットアップ時に慎重に選びます。将来的にウェアハウスを集約する見込みがあるなら、最初から共有の AWS KMS キーを選んでおきます。 まとめ Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、独自の ETL パイプラインをフルマネージドのソリューションに置き換え、Amazon Redshift の運用データを保持します。Apache Iceberg ベースのストレージへの自動保存、オープン形式でのクエリ、標準で備わる監査整合性により、数か月から数年分の可観測性データをフルマネージドで得られます。 AWS Management Console 、 AWS Command Line Interface (AWS CLI) 、 AWS SDK から有効にできます。 詳しくは、 Amazon Redshift システムテーブルのドキュメント を参照してください。 著者について Nidhi Nayak Nidhi は、AWS のシニアテクニカルアカウントマネージャーです。エンタープライズのお客様がスケーラブルで高性能なクラウドアプリケーションを構築し、クラウド運用を最適化できるよう支援しています。データ分析の分野で 10 年以上の経験を持ち、現在は Amazon Redshift と、Redshift への生成 AI の統合に注力しています。 Raza Hafeez Raza は、Amazon Redshift のシニアプロダクトマネージャー (テクニカル) です。エンタープライズのデータウェアハウスの構築と最適化に 15 年以上携わり、あらゆる規模のお客様にとってクラウド分析を使いやすく、コスト効率の高いものにすることに情熱を注いでいます。 Shubham Purwar Shubham は、AWS の Analytics スペシャリストソリューションアーキテクトです。AWS プラットフォーム上でスケーラブルかつ安全で高性能な分析ソリューションを設計・実装し、お客様がデータの潜在能力を最大限に引き出せるよう支援しています。AWS の分析サービスに関する深い専門知識を活かし、お客様と協力して個別のビジネス要件を明らかにし、具体的なインサイトをもたらしてビジネスの成長を促すカスタマイズされたソリューションを構築しています。プライベートでは、家族と過ごしたり世界中を旅行したりするのが好きです。 Amrita Singh Amrita は、米国ソルトレイクシティを拠点とする AWS のシニアテクニカルアカウントマネージャーです。Amazon Redshift を専門とし、エンタープライズのお客様がデータウェアハウス環境をパフォーマンス、スケーラビリティ、コスト効率の面で最適化できるよう支援しています。お客様と直接連携してクラウド活用のガイダンスや技術支援を提供し、AWS のサービスによって柔軟性、スケール、耐障害性を高められるよう手助けしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。