Amazon Quick と Snowflake Cortex AI によるマネーロンダリング対策のアラートトリアージの自動化

この記事は、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）を入力し、必要に応じて対象期間を指定します。するとフローは次の処理を実行します。

1. 入力を検証し、アラートが存在することを確認します。
2. MCP を通じて Snowflake Cortex Agent を呼び出し、取引データ、顧客プロファイル、過去の履歴、コンプライアンスポリシーを横断してアラートを調査します。
3. 構造化された調査ブリーフ（アラートの概要、取引パターン、顧客プロファイル、過去の 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 では手動構成のオプションを使用します。

1. 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 の値を更新してください。

2. 次のコマンドを実行して、クライアント ID とクライアントシークレットを取得します。

   SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('AML_QUICK_OAUTH');

   OAUTH_CLIENT_ID と OAUTH_CLIENT_SECRET の値を記録しておきます。

3. 次のコマンドを実行して、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 とチャットエージェントは同じ基盤を共有しており、ユースケースに応じたインターフェイスの違いにすぎません。

リソースのクリーンアップ

このソリューションをプロトタイプとして構築した場合は、継続的な露出と課金を避けるために、次のリソースを削除してください。

1. Amazon Quick で、AML Alert Triage フローを削除または非公開にします。
2. Amazon Quick で、Snowflake MCP サーバーへの統合を削除します。
3. Snowflake で、ツールを外部に公開する必要がなくなった場合は MCP SERVER オブジェクトを削除 (DROP) します。
4. Snowflake で、OAuth に使用した SECURITY INTEGRATION を無効化または削除 (DROP) します。
5. 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 コミュニティもぜひフォローしてください。

著者について

Zahir Gadiwan

Zahir は Snowflake でクラウドサービスプロバイダー向けのパートナーソリューションエンジニアリングをリードしています。クラウドパートナーやお客様と密接に連携し、ガバナンスの効いたエンタープライズデータを実世界の AI 成果へと変える支援をしており、セキュアでスケーラブルなアーキテクチャに特に注力しています。組織がモダンな AI 体験を Snowflake のガバナンスされたデータと AI 機能に接続し、実験から本番へと進んでいく方法について、現場に根ざした実践的な視点を持っています。