AWSブログリレー：AWS AppSync入門〜GraphQL APIの「リゾルバー」と多データソース連携の仕組みを解説〜

AWS Top Engineer/Ambassadorによるレビュー

アイレット25卒社員によるAWSブログリレーのAWS AppSync編です。
この記事は、AWS Top Engineerであるアジャイル事業部小巻玖美さんにレビューいただきました！

▼レビューいただいた方の投稿記事：
iret.media

AWS AppSyncとは

AWS AppSyncは、Amazon Web Servicesが提供するマネージドなGraphQL (グラフキューエル) APIサービスです！
＊以降、本文中では「AppSync」と表記します。

AppSyncを利用することで開発者はサーバーの構築、運用、スケーリングといったインフラ管理をAWSに任せつつ、柔軟で高性能なAPIを迅速に構築できます。

AppSyncは、単にGraphQL APIの窓口を作るだけでなく、データベースへの接続、リアルタイム通信、オフライン対応、セキュリティ設定など、現代のアプリケーション開発に必要なバックエンド機能を包括的に提供します。

また、DynamoDBやLambdaなどのバックエンドで発生した更新イベントをトリガーに、クライアントへ自動で変更を通知できる「AppSync Events」もサポートしており、イベント駆動アーキテクチャを簡単に構築できます。

AppSync EventsはGraphQL APIではなく、AppSyncのサブスクリプション機能と違ってスキーマ定義を必要としない、独立したPub/Sub専用のAPI機能である点が特徴です。

そもそもGraphQLとは？

GraphQLは、APIのためのクエリ言語（問い合わせ言語）」です！
従来のREST APIでは、例えば「ユーザー情報」を取得する際に、アプリ側が必要としているのが「名前」だけだとしても、サーバー側で定義された「住所」や「電話番号」など、すべてのデータが返ってくることがあります。これをオーバーフェッチと呼びます。

また、逆に「ユーザー名」と「その人の投稿一覧」など複数の情報を取得したい場合、/users/1と/users/1/postsのように複数のAPIを呼び出す必要があり、これをアンダーフェッチと呼びます。

GraphQLでは、クライアント（アプリ側）が「ユーザーの名前と投稿タイトルだけ欲しい」といった形で、必要なデータ構造を1回のリクエストで明記できます。サーバーはその指定に沿ってデータを返すため、通信が効率化され、特にモバイルアプリなどでパフォーマンスの向上が期待できます。

もちろん、REST APIでも工夫すれば同様のことは可能ですが、実装方法がAPIごとに異なり標準化されていません。
GraphQLは、この柔軟なデータ取得を統一された仕組みとして実現できる点が大きな特徴です！

AppSyncの主な機能とメリット

AppSyncは、先ほど説明したGraphQLサーバーをAWS上で簡単に構築・運用できるマネージドサービスです。
サーバー管理やスケーリングなどの複雑な作業をAWSが自動で行うため、開発者はアプリケーション開発に専念できます！
ここでは、AppSyncの主な機能とその特徴を紹介します。

1. サーバー管理が不要（フルマネージド）

最大の特長は「サーバーレス」であることです。
OSの更新、セキュリティパッチの適用、アクセス増減に応じたスケーリングなど、サーバー運用に関わる管理はすべてAWSが自動で実施します。
そのため、開発者はインフラを意識せず、アプリケーションの機能開発に集中できます！

2. 多様なデータソースとの柔軟な連携

AppSyncはAPIの「ゲートウェイ」として機能し、実際のデータはさまざまなソースから取得・操作できます。
これにより、クライアントは複数のシステムを意識することなく、統一されたGraphQL APIを通してデータにアクセスできます！

Amazon DynamoDB（高速なNoSQLデータベース）
AWS Lambda（既存ロジックや複雑な処理の呼び出し）
Amazon Aurora Serverless（リレーショナルデータベース）
Amazon OpenSearch Service（検索エンジン）
HTTPエンドポイント（既存のREST APIや外部サービス）
AWS Step Functions（ワークフローの実行）

3. リアルタイムデータ通信（サブスクリプション）

AppSyncの強力な機能のひとつが「GraphQLサブスクリプション」です。
サーバー上のデータが追加・更新・削除された際、その変更をクライアントへ即座にプッシュ通知することができます。
この仕組みにより、チャット、株価更新、スポーツ速報、配送トラッキングなど、リアルタイム性が求められるアプリを容易に構築できます！

4. オフライン対応とデータ同期

モバイルアプリでは、オフライン環境でも操作を継続できることが重要です。
AppSyncは「AWS Amplify DataStore」と組み合わせることで、強力なオフライン・同期機能を提供します。
オフライン中の変更（投稿や編集）はデバイス内に保存され、オンライン復帰時に自動的にサーバーと同期することができます！

5. 強力なセキュリティと認証

APIのセキュリティは極めて重要です。
AppSyncは複数の認証・認可方式をサポートし、誰がどのデータにアクセスできるかを柔軟に制御できます！

Amazon Cognito（ユーザー認証・管理）
AWS IAM（AWSリソースへのアクセス制御）
APIキー（簡易的なアクセス制御）
OpenID Connect（外部認証プロバイダー連携）

AppSyncの仕組み：リゾルバーとデータソース

AppSyncの中核を担うのが「リゾルバー（Resolver）」です！
クライアントからGraphQLクエリが送信されると、AppSyncはスキーマ定義に従い、その処理を担当するリゾルバーを呼び出します。

# クライアントからのGraphQLクエリ例
query GetUser {
  getUser(id: "1") {
    name
    email
  }
}

このクエリを受け取ったAppSyncは、対応するリゾルバーを実行します。
リゾルバーはリクエスト内容をバックエンドの「データソース」（例：DynamoDB、Lambda など）に渡し、その応答をGraphQLのレスポンス形式に変換してクライアントへ返します。

# 返却されるレスポンス例
{
  "data": {
    "getUser": {
      "name": "Taro Yamada",
      "email": "taro@example.com"
    }
  }
}

リゾルバーでは、クライアントからのリクエストをデータソースに渡し、
その応答をGraphQLレスポンスに変換するための処理（マッピング）を定義します。
この処理は、VTL (Velocity Template Language) または JavaScript で記述できます。
VTLは宣言的で高速なテンプレート記述に適しており、
JavaScriptはより柔軟なロジックを実装したい場合に利用されます。

料金体系

※以下の料金は、2025年10月22日時点での米ドル表示（東京リージョン含むアジアパシフィック地域）を基にしています。
為替レートおよびリージョン別料金により実際の請求額が異なる可能性がありますので、必ず
AWS AppSync 料金ページ
をご確認ください。

AppSyncの料金は、他のサーバーレス型サービス同様に「従量課金制」を採用しています。固定費やライセンス料はなく、APIの呼び出し回数やリアルタイム通信の送受信等、実際に使用した分に対してのみ課金されます。

主な料金要素は次の4つ（＋その他バックエンドサービスの利用料金）です！

1. クエリおよびデータ変更オペレーション（GraphQL API）

GraphQL APIにおける基本料金項目です。クライアントから送信される Query および Mutation のリクエスト数に応じて課金されます。
目安として、US $4.00／100万回 の単価が公式に提示されています。

2. リアルタイムオペレーション（GraphQL API）

サブスクリプション機能などリアルタイム通信に関する料金です。以下のような2つの要素から成ります。

2-1. リアルタイムアップデート

サーバーからクライアントへ送信されたメッセージの総数に応じて課金されます。
たとえば、1件のデータ更新を100人のユーザーが購読している場合、その更新は100回分のアップデートとしてカウントされます。
単価は US $2.00／100万回 です。

2-2. リアルタイム接続時間

クライアントが WebSocket などでリアルタイム通信を維持している「分数（connection-minutes）」に基づく料金です。
目安として、US $0.08／100万分 という単価が提示されています。

3. AppSync Events（Pub/Sub API）

これは、AppSyncのGraphQL API（クエリやサブスクリプション）とは別に提供される、スキーマ不要のPub/Sub専用API機能の料金です。
発行・購読・接続などの操作数に応じて課金され、単価は US $1.00／100万回 です。
また、WebSocket 接続時間も同様に課金されます（上記 2-2 と同じ単価）。

4. キャッシング（オプション）

API応答を高速化するためのサーバーサイドキャッシュを有効にした場合、選択したインスタンスタイプおよび実行時間に応じて時間単位で課金されます。

インスタンスタイプ	vCPU	メモリ (GiB)	料金（米ドル／時間）
cache.small	1	1.55	US $0.044
cache.medium	2	3.22	US $0.089
cache.large	2	12.3	US $0.298
cache.xlarge	4	25.05	US $0.595
cache.2xlarge	8	50.47	US $1.189
cache.4xlarge	16	101.38	US $2.379
cache.8xlarge	32	203.26	US $4.758
cache.12xlarge	48	317.77	US $6.775

5. その他の料金

AppSync 自体の料金に加えて、バックエンドで呼び出す以下のような AWS サービスにも別途料金が発生します：

AWS Lambda：実行時間・リクエスト数に応じた料金
Amazon DynamoDB：読み書きキャパシティユニット（RCU/WCU）・ストレージ料金等
Amazon Aurora Serverless：Data API リクエスト数や ACU 時間に応じた料金
データ転送量：AppSync からインターネットへのアウトバウンド送信に対して別途転送料金あり

無料利用枠について

AppSync には、アカウント作成から 12 ヶ月間有効な無料利用枠があります（2025年10月時点）。

クエリ／データ変更オペレーション：25 万件
リアルタイムアップデート：25 万回
接続分数（connection-minutes）：60 万分

小規模なアプリ開発や検証用途なら、この枠内で十分に運用可能です！

ユースケース

AppSyncは、複数のデータソースを統合し、リアルタイム性・柔軟性を備えたAPIを最小限の開発工数で構築できる点が特長です。
特にBFF (Backend for Frontend)として、Web・モバイル双方に最適化されたAPIを提供するケースで多く採用されています。

ユースケース1：リアルタイム更新が必要なアプリケーション

例：チャットアプリ、ライブコメント、IoTダッシュボードなど

AppSyncは、GraphQLのSubscriptionを通じてリアルタイム通信を実現します。
サーバーやWebSocketの管理を行う必要はなく、データ更新をトリガーにクライアントへ自動で配信できます。

さらに、軽量なPub/Sub用途ではAppSync Eventsを利用することで、GraphQLスキーマを定義せずにより低コストでリアルタイム通信を構築可能です！

主なデータソース： DynamoDB、Lambda、AppSync Events

ユースケース2：モバイル・業務アプリのオフライン対応

AppSyncは、AWS Amplify DataStoreと連携することで、ネットワークのない環境でも操作可能なオフラインアプリを実現します。
端末内でのローカル操作とクラウド側のデータ同期が自動的に処理されるため、開発者は同期ロジックを意識する必要がありません。

主なデータソース： DynamoDB

ユースケース3：複数のバックエンドを統合するBFF（Backend for Frontend）

1つのフロントエンドアプリが、RDS、DynamoDB、外部APIなど複数のデータソースにアクセスする場合、
AppSyncをBFFとして導入することで、GraphQL経由で1回のリクエストから必要なデータを統合的に取得できます！

これにより、フロント側のAPI呼び出し回数を削減し、バックエンドの構成もシンプルになります。

主なデータソース： Lambda、RDS、DynamoDB、HTTPエンドポイント

コンソールでAppSyncのリアルタイム機能を使ってみた

ここでは、AWSマネジメントコンソールからAppSync GraphQLを作成する手順をスクリーンショット付きで紹介します！

1. AppSync APIの作成

AWS AppSyncのコンソールを開き、「APIを作成」をクリックします。「Event API または GraphQL API を作成」画面が表示されるので「GraphQL API」を選択します。

APIタイプが「GraphQL API」であることを確認し、データソースとして「Design from scratch」を選択します。「次へ」をクリックします。

任意のAPI名を入力し、「次へ」をクリックします。

「後でGraphQLリソースを作成」を選択し、「次へ」をクリックします。

設定内容を確認し、「APIを作成」をクリックします。

これで、AppSync APIの準備が完了しました！

2. スキーマとデータソース作成

APIを作成したら、次に「スキーマ（APIの設計図）」と「データソース（データの接続先）」を設定します。今回はデータベースを使わない「None」データソースを利用します！

2-1. スキーマの定義

まず、左側メニューから「スキーマ」を選択します。

エディタに、あらかじめ用意した以下のGraphQLスキーマを貼り付けます。
これは「送信するメッセージの型(MessageInput)」と「返ってくるメッセージの型(Message)」を定義し、sendMessageというMutationとonSendMessageというSubscriptionを定義しています。

# 1. APIが「返す」データの型 (出力用)
# 送信するメッセージの型
type Message {
    name: String!
    messages: String!
}

input MessageInput {
    name: String!
    messages: String!
}

type Mutation {
    # Messageオブジェクトを引数として受け取る
    sendMessage(input: MessageInput!): Message
}

type Query {
    # (Queryは使わないが、スキーマ定義に必要)
    getMessages: [Message]
}

type Subscription {
    # sendMessageが実行されたらMessageオブジェクトを受け取る
    onSendMessage: Message
        @aws_subscribe(mutations: ["sendMessage"])
}

スキーマを貼り付けたら、右上にある「スキーマを保存」ボタンをクリックして保存します。

2-2. データソースの作成

次に、リゾルバーを紐付けるためのデータソースを作成します。
左側メニューから「データソース」を選択し、「データソースを作成」ボタンをクリックします。

「新しいデータソースを作成」画面で、以下の2点を設定します。

データソース名：任意の名前を入力します
データソースタイプ：ドロップダウンから「なし(None)」を選択します

設定したら、右下の「作成」ボタンをクリックします。

これで、スキーマとデータソースの準備が完了しました！

3. リゾルバーのアタッチ

スキーマとデータソースを準備したら、最後に「どのMutationが呼ばれたら、どのデータソースを動かすか」を紐付ける「リゾルバー」を設定します！

3-1. Mutationにリゾルバーをアタッチ

左側メニュー「スキーマ」に戻ります。
右側の「リゾルバー」一覧から、MutationセクションにあるsendMessage(…)の横の「アタッチ」ボタンをクリックします。

「Attach resolver（リゾルバーをアタッチ）」画面が開きます。
「データソース名」のドロップダウンから、先ほど作成したデータソースを選択します。

リゾルバーランタイムはデフォルトの「AppSync JavaScript (APPSYNC_JS)」のままでOKです。下にスクロールして「作成」ボタン（または「リゾルバーを作成」）をクリックします。

3-2. リゾルバーコードの記述

リゾルバーコードのエディタ画面に移動します。

ここに、クライアントから渡されたデータをそのまま購読者に横流しするためのJavaScriptコードを貼り付けます。

リクエスト (request.js)

/**
 * Sends a request to the attached data source
 * @param {import('@aws-appsync/utils').Context} ctx the context
 * @returns {*} the request
 */
export function request(ctx) {
    // クライアントから渡された引数 (ctx.args.input) を payload として渡します
    return { payload: ctx.args.input };
}

レスポンス (response.js)

/**
 * Returns the resolver result
 * @param {import('@aws-appsync/utils').Context} ctx the context
 * @returns {*} the result
 */
export function response(ctx) {
    // リクエストから渡された payload (ctx.result) をそのまま返します
    return ctx.result;
}

コードを貼り付けたら、右上の「保存」ボタンをクリックします。

これで全ての準備が完了です。左側メニューの「スキーマ」に戻ると、sendMessageの横が、アタッチしたデータソース名に変わっていることが確認できます！

4. 動作確認：リアルタイム通信をテストする

いよいよ、作成したリアルタイムAPIの動作確認を行います。
AppSyncの「クエリ」エディタは、Mutation（送信）とSubscription（待機）を同時にテストできます。この機能を使って、リアルタイムでメッセージが届くか試してみましょう。

※このテストを分かりやすく行うため、ブラウザのタブ（またはウィンドウ）を2つ開いて、同じ「クエリ」エディタ画面を並べて表示することをお勧めします！

4-1. クエリエディタの準備

まず、左側メニューから「クエリ」を選択します。
エディタ（左側のペイン）に、これから実行する「待機用クエリ(Subscription)」と「送信用クエリ(Mutation)」の両方のクエリ文を貼り付けます。

上記の画像のように、2つのウィンドウで同じ画面を開いておくと確認が簡単です。

subscription ListenForMessages {
  onSendMessage {
    name
    messages
  }
}

mutation Sendmessages {
  sendMessage(input: {name: "MY", messages: "Hello everyone"}) {
    name
    messages
  }
}

4-2. 【タブ1：待機側】Subscriptionの実行

まず、片方のタブ（待機側）で、実行ボタン（▶）のプルダウンから「ListenForMessages」（Subscription）を選択し、実行します。
これを実行することでサーバーからの通知を待つ状態になります。

4-3. 【タブ2：送信側】Mutationの実行

次に、もう片方のタブ（送信側）で、実行ボタン（▶）のプルダウンから「Sendmessages」（Mutation）を選択し、実行します。
nameやmessagesの値は、クエリ文を直接編集して好きな文字列に変えてみましょう。

4-4. リアルタイム受信の確認

「Sendmessages」を実行した瞬間、【タブ1：待機側】の結果ウィンドウに、送信したデータがJSON形式でプッシュ通知されます！

これで、DynamoDBなどのデータベースを一切使わなくても、AppSyncのリアルタイム機能（Pub/Sub）が正しく動作していることが確認できました。

まとめ

今回は、AWS AppSyncの概要から、GraphQLが解決する課題、主な機能、料金、そしてコンソール上で試せるリアルタイム通信のデモまでを紹介しました。

AppSyncの魅力は、これまで構築・運用が難しかったGraphQLサーバーやWebSocket通信、オフライン同期といった仕組みを、完全マネージドなサーバーレスで簡単に実現できる点にあります。

また、DynamoDB・Lambda・RDSなど複数のデータソースを統合し、クライアントからの1回のリクエストで必要なデータを効率的に取得できる柔軟性も大きな特徴です！

この記事が、AppSync導入を検討される方やGraphQLを活用した開発に興味のある方の参考になれば幸いです。