ひとことで言うと
GraphQL API と、その上に乗るリアルタイム配信（サブスクリプション、または schema 不要の Events）をマネージドで提供するサービスです。生成AI自体は作りませんが、エージェントやモデルが生成した結果をクライアントへプッシュする配線としてAIP-C01の実装ドメインに顔を出します。
要するに、放送設備です。API Gateway が「呼ばれたら答える受付」だとすると、AppSync は「誰かが更新したら、購読者全員に自動で知らせる放送局」。バックエンドが Mutation を発行すると、AppSync が WebSocket 接続を保っている購読者に配信します。接続の維持・スケーリングは AppSync 側の仕事です。
なぜ生まれたか
もともとはモバイル/Webアプリのオフライン同期・リアルタイム更新のための GraphQL サービスです。GenAI 文脈での摩擦点は、エージェントの応答やツール実行の進捗を、生成が終わるまでUIに何も見せられないという問題です。
| 摩擦 | AppSync 側の受け皿 |
|---|---|
| 生成中の状態をクライアントに伝えたい | Mutation をトリガーに Subscription が配信（@aws_subscribe） |
| GraphQLスキーマを組む余裕がない単純な配信 | AppSync Events（スキーマ不要のWebSocket Pub/Sub。チャンネル単位で発行/購読） |
| モバイル/Webアプリを素早く組みたい | Amplify がAppSyncを土台に使う（試験のスキル文にも明記） |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| エージェントの応答をUIへリアルタイム表示 | Lambda リゾルバがMutationを発行 → Subscriptionで購読中クライアントへ配信 | D2 |
| チャット・通知・進捗表示の配信基盤 | AppSync Events（namespace/channelで認可・OnPublish/OnSubscribeハンドラ） | D2 |
| Amplifyアプリのバックエンド | AmplifyクライアントがAppSyncのWebSocket接続管理を自動で扱う | D2 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| エージェントの処理状況をリアルタイムでUIに反映したい | AppSync のSubscription（Mutationトリガー）でプッシュ配信 | クライアントにポーリングさせる案（レイテンシとAPI呼び出し回数が増える） |
| GraphQLは要らないが、通知だけWebSocketで配りたい | AppSync Events（スキーマ不要のPub/Sub） | GraphQLスキーマを最小限用意してSubscriptionを流用する（過剰設計） |
| Amplifyでノーコードにアプリを組みたい | AmplifyがAppSyncを基盤に使う構成を選ぶ | API Gateway＋独自WebSocket実装を手組みする案 |
| モバイルオフライン時のデータ同期が要る | AppSyncのオフライン同期機能 | API Gatewayでキャッシュを持たせる案（同期の仕組みを持たない） |
AppSyncはFMを呼び出しません。試験のシナリオでよくあるのは「AppSyncがBedrockを直接呼ぶ」ように読める選択肢ですが、実際はLambdaリゾルバ経由でBedrockを呼び、その結果をMutationとして流し込む形が普通です。AppSync自体は配信層であって推論層ではない、という役割の境界を崩さないことが分岐条件になります。
実務でどう使うか
- サブスクリプションはMutationの「後追い」です。 Mutationの選択セットに含まれないフィールドは、Subscription側でも配信されません。ストリーミング表示をしたいなら、Mutation側の型設計で「部分テキスト＋完了フラグ」のような形を最初から用意しておく必要があります
- WebSocketペイロードは240KBが実用上の目安です。 Pure WebSocketsクライアント（現在の標準経路。2022年1月にMQTT over WebSocketsは廃止済み）はこの上限で動きます。大きな生成結果を一度に流し込まず、チャンク単位で配信する設計が必要です
- Amplifyのバックエンドとして使う場合、接続管理やスケーリングはAppSync任せにできます。 自前でWebSocketサーバーを組む選択肢と比べて、実装コストの差がそのまま試験の判断軸になります
認可はSubscriptionのフィールド単位でも効きます。接続時の認可（IAM・Cognito・Lambdaオーソライザー）だけでなく、フィールドレベルのリゾルバでも呼び出し元の権限を見られます。「誰でも購読できるが、見えるフィールドは呼び出し元次第」という設計を怠ると、生成結果に含まれる機微な情報が意図せず全購読者に届きます。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| API Gateway（WebSocket API） | AppSyncはGraphQL＋Pub/Sub配信に特化しマネージド度が高い。API GatewayのWebSocket APIは接続IDの管理を自分で書く分、自由度が高い |
| AppSync Events | 同じAppSyncの機能だが、GraphQLスキーマを書かずにチャンネル単位のPub/Sub配信だけが欲しい時に選ぶ軽量版 |
| Amazon SNS | SNSはトピック単位のfan-out通知（Lambda・SQS・メール等の多様な購読者向け）。AppSyncはWebSocket接続を保持し続けるクライアントへのリアルタイム配信に特化 |
想起チェック
Q1. エージェントの生成途中の状態をブラウザにリアルタイムで見せたい。AppSyncでの基本パターンは？
Lambdaリゾルバが生成の進捗をMutationとして発行し、クライアントはそのMutationに紐づくSubscriptionを購読して受け取ります。AppSyncがWebSocket接続の維持とスケーリングを引き受けます。
Q2. GraphQLスキーマを書く余裕がなく、単純な通知配信だけしたい。何を選ぶ？
AppSync Eventsです。スキーマ不要で、チャンネル単位のPub/SubをWebSocket/HTTPで扱えます。