はじめに 普段 AI エージェントに作業を任せるとき、コンテキストを AGENTS.md などの . ...

本記事は 2026 年 4 月 15 日 に公開された「 Get to insights faster using Notebooks in Amazon SageMaker Unified Studio 」を翻訳したものです。 本記事では、Amazon SageMaker Unified Studio のノートブックがインフラの設定を簡素化し、インサイト獲得までの時間を短縮する仕組みを紹介します。住宅価格データの分析、スケーラブルなデータテーブルの作成、分散プロファイリング、機械学習 (ML) モデルの学習を、単一のノートブック環境で行う流れをご覧いただけます。 データサイエンティストやアナリストは、分析を始めるまでにインフラ設定と複数データソースの認証管理に何日も費やすことがしばしばあります。Amazon Simple Storage Service (Amazon S3)、Amazon Redshift、Snowflake、ローカルファイルにまたがるデータを扱う場合、認証設定の繰り返し、コンピュートスケーリングの手動判断、ツール切り替えの手間が積み重なり、インサイト獲得が遅れます。 Amazon SageMaker Unified Studio のノートブックは、12 以上のデータソースへの即時アクセス、ローカルから分散処理までのコンピュートスケーリング、AI によるコード生成を、単一のブラウザベース環境で提供します。ポリグロットプログラミング、マルチエンジンコンピュート、AI 支援による開発を活用し、疑問からインサイトまでの道のりを短縮する方法を解説します。 Amazon SageMaker Unified Studio のノートブックとは Amazon SageMaker Unified Studio のノートブックは、データ分析、探索、エンジニアリング、機械学習ワークフローのためのインタラクティブな環境を提供します。統合された 5 つの機能を備えています。 ポリグロットプログラミング : 同じノートブック環境で Python と SQL を相互に切り替えながらコードを書けます 統合されたデータアクセス : Amazon S3、AWS Glue Data Catalog、Apache Iceberg テーブル、Snowflake や BigQuery などのサードパーティソースに保存されたデータへ即座に接続できます ネイティブな可視化 : Python や SQL の結果から直接チャートを作成し、没入感のあるデータ分析ができます AI による開発支援 : SageMaker Data Agent を通じて自然言語プロンプトでコードを生成できます。データ分析、データサイエンス、ML タスク向けの的確なチャットインターフェイスを備えています 柔軟なコンピュート : ニーズの拡大に応じて、基本的なインスタンスから GPU 搭載環境までスケールできます アーキテクチャ 本セクションでは、ノートブックのアーキテクチャを説明します。ノートブックは、複数のコンピュートエンジン、多様なデータソース、AI アシスタントを統合したクラウドネイティブアーキテクチャにより、ブラウザベースのシンプルさでエンタープライズ規模の分析を実現します。 プレゼンテーション層 Amazon SageMaker Unified Studio 経由でノートブックインターフェイスにアクセスします。コード実行用のコードセル、ドキュメント用のマークダウンセル、チャートやテーブル用の可視化セルを備えた、使い慣れたインターフェイスで操作できます。 コンピュート層 専用のノートブックサーバーがカーネルのライフサイクルとセッション状態を管理します。主要コンポーネントには、コード補完用の Language Server、データサイエンスライブラリをプリロードした Python 3.11 ランタイム、Python、PySpark、SQL の実行を同じノートブック内で処理する Polyglot Kernel が含まれます。作成した各ノートブックは、永続的な Amazon Elastic Block Store (Amazon EBS) ストレージにバックアップされます。 実行層 ノートブックは複数の実行エンジンをサポートし、コードを最適な処理エンジンに自動的にルーティングします。インメモリ実行は、小規模なデータセットや迅速なプロトタイピングを処理します。Amazon Athena 経由の Apache Spark は、Spark Connect を介した大規模分析向けの分散処理を提供します。Amazon Athena (Trino)、Amazon Redshift、Snowflake、BigQuery へのネイティブ接続により、SQL クエリを処理します。 データ統合 AWS ネイティブ (Amazon S3、AWS Glue、Amazon Athena、Amazon Redshift) とサードパーティ (Snowflake、BigQuery、PostgreSQL、MySQL) を含む 12 以上のデータソースに統一的にアクセスできます。サポートされている最新のデータソースについては、 Connect to data sources を参照してください。 AI 層 SageMaker Data Agent は、2 つのモードで利用できます。複数ステップの分析ワークフロー向けの Agent Panel と、セル単位のコード生成に特化した Inline Assistance です。詳細は Accelerate context-aware data analysis and ML workflows with Amazon SageMaker Data Agent を参照してください。 作業を保護するため、セキュリティはアーキテクチャ全体に組み込まれています。データアクセスは AWS Identity and Access Management (AWS IAM) の権限に従います。ノートブックとエージェントは、利用が許可されたデータソースにのみアクセスできます。コンポーネント間の通信は暗号化チャネルを使用し、ノートブックのストレージは保存時に暗号化されます。AI エージェントには、破壊的な操作を防ぐガードレールが組み込まれており、コンプライアンスと監査のためにやり取りをログに記録します。 前提条件 始める前に、以下が必要です。 Amazon SageMaker Unified Studio のリソースを作成する権限を持つ AWS アカウント。必要な権限の詳細は、 Set up IAM-based domains を参照してください。 Python プログラミングと SQL クエリの基本的な知識 データ分析の概念と ML ワークフローの理解 サンプルの住宅データセットへのアクセス (ウォークスルー内で提供) ノートブックを使い始める まず、 Amazon SageMaker コンソール を開き、 Get started を選択します。 データとコンピュートへのアクセス権を持つ既存の AWS Identity and Access Management (AWS IAM) ロールを選択するか、新規ロールを作成するかを求められます。本ウォークスルーでは、 Create a new role を選択し、他のオプションはデフォルトのままにします。 Set up を選択します。環境の準備には数分かかります。 ユースケース 本記事では、ノートブックと SageMaker Data Agent を使って以下を実行します。 データセットの操作: サンプルデータセット housing.csv をアップロードし、データエクスプローラーで探索 ポリグロットプログラミング: DuckDB 経由で SQL によるデータフレームのクエリ AWS Glue によるマルチエンジンアクセス: AWS Glue テーブルを作成し、Athena SQL/Spark エンジンで分散処理を実行 高度な分析: Athena Spark でデータプロファイリング AI 支援による開発: Data Agent でプロファイリングと ML のコードを生成 ML ワークフロー: Random Forest モデルを学習し、結果を評価 まずインターフェイスを見て、コア機能を確認しましょう。 インターフェイスの理解 ノートブックのインターフェイスは、コード実行用のセルとドキュメント用のマークダウンという、使い慣れたノートブック規約に従っています。ノートブック内では、現在のプログラミング環境 (Python 3.11 など) とコンピュートプロファイルの仕様を確認できます。このインターフェイスでは以下ができます。 ファイルの参照、データカタログの探索、サードパーティ接続の管理を通じてデータにアクセス ノートブックのコンテキスト内で作成された変数を監視 ワークロード要件に応じて仮想 CPU と RAM を調整し、GPU インスタンスまでオンデマンドでコンピュートリソースをスケール Python パッケージを必要に応じてインストールおよび設定してパッケージを管理 データセットの操作 本ウォークスルーでは、 このページ からダウンロードできる housing.csv サンプルデータセットを使用します (リンク先ではファイル名が canvas-sample-housing.csv になっています)。左パネルの Files アイコンを選択し、 Local タブを選択します。 Local タブでノートブックに CSV ファイルをアップロードします。 ノートブックはデータ資産への即時アクセスを提供します。データエクスプローラーを使えば、AWS Glue Data Catalog、Amazon S3 テーブルカタログ、Amazon S3 バケット、設定済みのサードパーティ接続を参照できます。 3 点リーダーのオプションメニューを選択します。 Read as dataframe を選択し、ノートブックに挿入されたセルを実行して結果を確認します。 import pandas as pd <<df_csv_xxxx>> = pd.read_csv('housing.csv') <<df_csv_xxxx>> データフレームを返すと、ノートブックは自動的なデータプロファイリングを備えたリッチなテーブル形式で表示します。 ポリグロットプログラミング: Python と SQL を同時に ノートブックのもっとも強力な機能の 1 つが、Python と SQL の相互運用性です。データを Python のデータフレームに読み込んだ後、すぐに SQL でクエリできます。たとえば、海への近さ別に人口と世帯数の合計を計算するには、次のように実行します。 select sum(population) ,sum(households),ocean_proximity from<<df_csv_xxxx>> group byocean_proximity ノートブックのオートコンプリート機能はコンテキスト内のデータフレームを認識するため、SQL クエリを直感的に書けます。 この SQL クエリは DuckDB (インメモリの SQL データベースエンジン) 上で実行され、個別のインストールやサーバー保守は不要です。DuckDB は軽量な設計で、Python、Java、その他の環境に組み込めるため、迅速な対話型データ分析に適しています。分散処理が必要な場合は、データセット用の AWS Glue テーブルを作成した後、Apache Spark や Trino などのエンジンを使用できます。 データセット用の AWS Glue テーブルを作成する AWS Glue テーブルを作成すると、Amazon Athena SQL (Trino) や Amazon Athena Spark など、AWS Glue カタログ対応のさまざまなエンジンでデータセットをクエリできます。これらのエンジンは、それぞれのワークロード要件に対して最適な価格性能比を提供します。 まず AWS Glue データベースを作成します。ノートブックで新しいセルを作成するために SQL を選択し、 Amazon Athena (SQL) を選びます。 次の SQL を実行してデータベースを作成します: create database demo; 次に、データエクスプローラーに移動し、左上の +Add を選択して Create table を選びます。先ほど作成したデータベースを選択し、テーブル名を入力します。先ほど使用した housing.csv データセットファイルをアップロードします。サイドパネルで Next を選択して、テーブルを作成します。 次に、Amazon Athena SQL を使って新しいセルでサンプル SQL クエリを実行してみましょう。 select sum(population) , sum(households), ocean_proximity fromdemo.housing group by ocean_proximity Athena Spark による高度な機能 住宅価格を予測する ML モデルを構築する前に、データセットをさらに分析し、追加のインサイトを得るためにデータプロファイリングを実行しましょう。高度な探索には、ノートブック内で Amazon Athena Spark を使用できます。そのために、組み込みの Spark セッションを持つ新しい Python セルを作成します。次のコードを実行して Spark のバージョンを確認します。 # Verify Spark version spark.version SageMaker Data Agent によるデータプロファイリング 定型的なコードを手動で書く代わりに、組み込みの生成 AI 機能を活用できます。 プロンプト : 「Perform data profiling and create visualization for housing table」 AI アシスタントは、基本統計の算出、列単位のプロファイリング、データ型の分析、欠損値の検出を含む、包括的なプロファイリングコードを生成します。 エージェントは AWS Glue Data Catalog にアクセスし、housing テーブルの構造を把握したうえで、対象の列とデータ型に合わせたプロファイリングコードを生成しました。この文脈認識により、汎用的なコードスニペットを自環境向けに調整する際にありがちな試行錯誤が減ります。生成されたコードを確認して実行します。応答が速いため、分析を効率的に反復できます。 エラーが発生した場合は、次の図のように Fix with AI で解決できます。実行時にエラーが発生すると、 Fix with AI 機能がトレースバックを分析し、根本原因を診断して修正済みコードを生成するため、分析を止めずに進められます。 ML モデルの学習 次に、Data Agent を使って住宅価格を予測するモデルの学習コードを生成します。 プロンプト: 「Generate code to train a model that predicts housing prices. Use table housing.」 AI アシスタントは、次のようなエンドツーエンドのコードを生成します。 Amazon Athena Spark を使って AWS Glue カタログから住宅データを読み込み、pandas に変換 文字列型の列を数値化し、One-Hot エンコーディングでエンコードし、欠損値を除去 Random Forest モデルを学習して住宅価格の中央値を予測 モデル性能を評価 (RMSE、MAE、R-square) 予測に対する重要度が高い上位 10 個の特徴量を表示 この複数ステップのオーケストレーションにより、データアクセスからモデル評価までのワークフロー全体を任せられ、開発時間を数時間短縮できます。 エラーが発生した場合は、結果のトレースバックセクションにある Fix with AI で解決できます。 このワークフローでは、ノートブックの統合機能を紹介しました。ローカルからファイルをアップロードし、マルチエンジンアクセス用に AWS Glue テーブルを作成し、Amazon Athena Spark で分散プロファイリングを実行し、AI 支援による ML 開発で住宅価格を予測しました。これらすべてを、ツールを切り替えずに 1 つのノートブック環境で行いました。 主なメリットとベストプラクティス Amazon SageMaker Unified Studio のノートブックには、いくつかの利点があります。 インサイト獲得までの時間短縮 : 従来の環境では、分析を始める前に設定に数時間かかることもあります。ノートブックはこうした負荷を回避し、すぐに作業を始められます。 コラボレーションの向上 : 一貫した環境でノートブックを共有でき、再現性が確保され、「自分の環境では動く」問題が減ります。 複雑性の低減 : データソースや処理エンジンごとに別々のツールを使い分けるのではなく、複数のデータソースとコンピュートエンジンに 1 つのインターフェイスからアクセスできます。 AI による開発の加速 : タスク特化型のコードを生成し、的確な提案を受けられるため、繰り返しのコーディング作業にかかる時間を減らせます。 スケーラブルな性能 : メガバイトからペタバイト規模のデータセットを、適切なコンピュートリソースで処理できます。データ量の増加に応じてシステムが自動的にスケールします。 ベストプラクティス まずは小さめのインスタンスから始め、ニーズの拡大に合わせてスケールアップする形で、適切な コンピュートプロファイル で開始する。 繰り返し作業や複雑な操作には、自然言語プロンプトで AI アシスタントを活用する 。 大規模処理には Amazon Athena Spark、データウェアハウスには Amazon Redshift、その他特定のワークロードには専用エンジンを使うなど、 エンジンを戦略的に組み合わせる 。 マークダウンセルを使い、コードと並行して 作業内容を文書化する ことで、生きたドキュメントを作る。 複雑なワークフローを論理的なステップに分割し、 複数のセルで整理する ことで、可読性とデバッグ性を高める。 クリーンアップ 今後の課金を避けるため、本ウォークスルーで作成したリソースを削除します。 Amazon SageMaker Unified Studio コンソールで、Notebook ページに移動する ノートブックを削除する AWS Glue Data Catalog から demo データベースと housing テーブルを削除する 本ウォークスルーで作成した Amazon SageMaker Unified Studio ドメインを削除する 本ウォークスルー用に新しい IAM ロールを作成した場合は、IAM コンソールから削除する まとめ 本記事では、Amazon SageMaker Unified Studio のノートブックが作業効率を高め、インサイトをより速く提供する仕組みを紹介しました。使い慣れたノートブックインターフェイスに、エンタープライズ規模のコンピュート、マルチエンジンサポート、生成 AI 支援を組み合わせることで、チームはデータと AI のワークフローを効率化できます。 Python と SQL の統合、多様なデータソースへの即時アクセス、的確なコード生成機能により、ノートブックは現代のデータチームにとって価値あるツールになります。探索的データ分析、複雑なデータパイプラインの構築、ML モデルの学習を、単一の直感的な環境で必要な柔軟性とパワーを備えて実行できます。 使い始める準備はできましたか? Amazon SageMaker Unified Studio で最初のノートブックを作成 し、数分でデータ分析を始めましょう。 追加機能を探る: 季節分解と予測を用いた時系列分析ワークフロー テキスト分類や感情分析のための自然言語処理パイプライン ML モデルのバージョン管理のための Amazon SageMaker Model Registry との統合 ペタバイト規模の処理に対応する高度な Spark 最適化手法 詳細情報: Amazon SageMaker Unified Studio Administrator Guide Amazon SageMaker Unified Studio User Guide Notebooks in SageMaker Unified Studio Use the SageMaker Data Agent Pricing information 著者について Praveen Kumar Praveen Kumar は AWS の Principal Analytics Solutions Architect で、クラウドベースのサービスを用いた最新のデータおよび分析アプリケーションの設計、構築、実装に精通しています。関心領域はサーバーレステクノロジー、データガバナンス、データドリブンな AI アプリケーションです。 Majisha Namath Parambath Majisha Namath Parambath は Amazon SageMaker の Principal Engineer で、AWS で 10 年以上の経験を積んでいます。エージェント型システムを重視した包括的なデータ分析とインタラクティブな機械学習機能を提供する次世代サービス、Amazon SageMaker Unified Studio の重要な取り組みを主導しています。専門はシステム設計、アーキテクチャ、部門横断の実行で、エンタープライズ規模でのセキュリティ、パフォーマンス、信頼性に注力しています。エンジニアリング以外では、読書、料理、スキーを楽しんでいます。 Siddharth Gupta Siddharth Gupta は SageMaker の Unified Experiences で生成 AI を率いており、AI システムが複雑なタスクをユーザーに代わって自律的に実行する、エージェント型体験の推進に注力しています。以前は AWS でエッジ機械学習ソリューションを率いていました。彼の仕事は、開発者やデータサイエンティストが AI とやり取りする方法の改善、より直感的なデータ統合の実現、機械学習モデルを構築・デプロイするためのより良いツール作りに焦点を当てています。University of Illinois at Urbana-Champaign 出身で、Yahoo、Glassdoor、Twitch で豊富な経験を積んでいます。 LinkedIn で連絡できます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

この記事は、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 機能に接続し、実験から本番へと進んでいく方法について、現場に根ざした実践的な視点を持っています。