ひとことで言うと
SaaSアプリ(Salesforce・Zendesk・ServiceNow・Slackなど)とAWSサービス(主にS3・Redshift)の間で、コードを書かずにデータを転送するサービスです。GenAI文脈では、Knowledge Basesが直接コネクタを持たないSaaSのデータを、RAGの取り込み対象であるS3へ着地させる前段として使われます。
要するに、荷受け場です。SaaS側の倉庫(Salesforceなど)から荷物(レコード)を定期便または随時便で運び込み、S3という共通の集積所に降ろします。Knowledge Basesはこの集積所(S3)からしか荷物を取り込めないので、SaaSの荷物を直接RAGに食わせたいときはAppFlowが荷受け場の役目をします。
なぜ生まれたか
RAGの精度は「何を食わせるか」で決まりますが、Bedrock Knowledge Basesが標準で持つコネクタ(S3・SharePoint・Confluence・Google Drive・OneDrive・Web Crawler)に無いSaaSの社内データは、そのままでは取り込めません。
| 摩擦 | AppFlow 側の受け皿 |
|---|---|
| Knowledge Basesが直接つながらないSaaS(Salesforce・Zendeskなど)のデータを使いたい | AppFlowでS3に転送し、S3データソースとしてKnowledge Basesに取り込ませる |
| SaaS側の変更をイベントとして他システムに流したい | Salesforceのプラットフォームイベント・CDCイベントをEventBridgeへ発行 |
| 転送データをインターネット経由にしたくない | PrivateLinkによるプライベートなデータ転送 |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| SaaSデータをRAGの取り込み対象にする | AppFlow→S3→Knowledge BasesのS3データソースとして同期 | D1 |
| SaaS変更イベントをGenAI処理の起点にする | AppFlow→EventBridgeパートナーイベントバス→ルールで振り分け | D2 |
| 分析用データレイクへの集約 | 複数SaaS(Salesforce・Marketo・ServiceNow・Zendesk)から週次でS3へ集約、Glue Data Catalogでカタログ化 | D1 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| Salesforceの案件データをRAGの根拠として使いたい | AppFlowでS3へ転送し、S3データソースとしてKnowledge Basesに取り込ませる | Knowledge BasesがSalesforceに直接接続できると考える(標準コネクタに無い) |
| SaaSのデータを都度ポーリングしたくない | スケジュール実行のフロー、または変更イベントをEventBridge経由で受け取る | Lambdaで定期的にSaaS APIをポーリングする自前実装 |
| SaaSデータの転送をインターネットに出したくない | PrivateLinkでプライベート転送 | VPNやインターネット経由の転送のまま運用する |
| 取り込んだデータを他の分析・ML基盤からも探せるようにしたい | Glue Data Catalogへのカタログ化 | S3に置くだけでカタログ登録を省略する |
AppFlowはKnowledge Basesの正式なデータソースの一覧には入っていません。試験のシナリオで「SaaSのデータをKnowledge Basesに直接つなぐ」ように読める選択肢が出ても、正しい経路は「AppFlowでS3に降ろしてから、S3をデータソースとしてKnowledge Basesに設定する」の2段構えです。1段で済む選択肢は簡潔に見えて誤りである可能性が高いところです。
実務でどう使うか
- 転送はノーコードで組めますが、コネクタが対応していないSaaSには使えません。 カスタムコネクタSDK(Python/Java)で自作することもできますが、標準コネクタで足りるかを先に確認するのが定石です
- フローはオンデマンド・スケジュール・イベントトリガーのいずれかで実行します。 RAGの鮮度要件(「最新版だけを検索対象にしたい」)に応じて、スケジュールの粒度を決めます
- CloudFormationでフローとコネクタプロファイルを管理できます。 複数環境(開発・本番)でのSaaS接続をコードとして再現したい場合に使います
週次集約フローには容量の目安があります。公式の利用例では、複数SaaSから週次で集約する場合に1フローあたり最大100GB程度が想定されています。これを超える規模のデータをRAGの取り込み対象にするなら、フローの分割やスケジュールの見直しが要ります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Bedrock Knowledge Basesの標準コネクタ | 標準コネクタ(SharePoint・Confluence・Google Drive・OneDrive・Web Crawler)は文書系。AppFlowはSalesforceなどの業務SaaSのレコードデータが対象で、経由地としてS3を挟む |
| AWS Glue | AppFlowはSaaS⇔AWSの「転送」が主役。Glueは転送後のデータの品質検証・カタログ化・ETL変換が主役。実務では両方を組み合わせる |
| EventBridge | AppFlowは定期/随時のデータ転送そのもの。EventBridgeはAppFlowが発行したイベントを条件で振り分ける配送層 |
想起チェック
Q1. SalesforceのデータをRAGの根拠として使いたい。Knowledge Basesに直接つなげる?
つなげません。 AppFlowでS3にデータを転送してから、S3をデータソースとしてKnowledge Basesに取り込ませる2段構えが必要です。
Q2. SaaS側の変更をイベント駆動でGenAI処理の起点にしたい。何を組み合わせる?
AppFlowがSaaSのプラットフォームイベント・CDCイベントをEventBridgeのパートナーイベントバスへ発行し、ルールで対象のイベントだけを下流(Lambda・Step Functionsなど)へ振り分けます。