AWS WAF に AI トラフィック収益化機能が含まれるようになりました。これにより、デジタルコンテンツの所有者とパブリッシャーは、保護されたウェブコンテンツに AI ボットやエージェントがネットワークエッジで直接アクセスした場合に課金できます。この機能により、コンテンツ所有者とパブリッシャーは、オリジンインフラストラクチャを変更したり、アプリケーションコードを作成したりすることなく、コンテンツパス、ボットカテゴリ、または検証階層ごとにリクエストごとの料金を設定できます。コンテンツ所有者は、エージェントタイプごとにきめ細かなアクセスポリシーを定義したり、ステーブルコインで好みのウォレットに支払いを回収したり、収益やボットアクティビティを単一のダッシュボードから監視したりできます。 現在、多くのコンテンツプロバイダーにおいて AI ボットのトラフィックがウェブトラフィックの 50% 以上を占めており、AI 固有のクローラーは前年比で 300% 以上増加しています。コンテンツをインデックスし、測定可能な参照トラフィックをパブリッシャーのウェブサイトに返す従来の検索エンジンのクローラーとは異なり、AI ボットは同じコンテンツを消費して AI インターフェイスで要約と回答を生成するため、元のソースにトラフィックをほとんどまたはまったく送り返しません。パブリッシャーは、そのトラフィックを処理するためのインフラストラクチャ費用を負担しますが、通常はこれらの費用を相殺するページビュー、広告インプレッション、またはサブスクリプションコンバージョンは発生しません。 AWS WAF Bot Control では、既にボットのアクティビティを可視化し、トラフィックをブロックまたはレート制限する機能をお客様に提供していますが、料金設定や AI エージェントからの支払いの回収は、これまで不可能でした。AI トラフィック収益化は、そのギャップを埋める新しい Bot Control 機能です。コンテンツ所有者とパブリッシャーは、カスタムの支払いインフラストラクチャを構築したり個別のライセンス契約を交渉したりすることなく、AWS WAF コンソールから直接料金ルールを設定し、サードパーティーの支払い統合を通じて AI エージェントから支払いを回収できます。支払い決済および検証フローは、Coinbase の x402 Facilitator によって提供されます。アカウントへの直接支払いと Machine Payments Protocol (MPP) サポートのための Stripe との統合が間もなく開始されます。 AI トラフィック収益化の開始方法 収益化を設定する前に、CloudFront ディストリビューションに関連付けられているウェブ ACL で AWS WAF Bot Control が共通レベルまたはターゲットレベルで有効になっていることを確認します。Bot Control は、収益化ルールが依存するエージェント分類を提供します。まだ設定していない場合は、「 ウェブ ACL への AWS WAF Bot Control マネージドルールグループの追加 」ドキュメントを参照してください。AWS マネジメントコンソールで [WAF & Shield] に移動し、左側のナビゲーションペインで [保護パック (ウェブ ACL)] を選択して開始します。 保護パックは、AI トラフィック収益化の中核となる構成単位です。収益化の対象となるコンテンツパス、各エージェント検証階層に課金される内容、受け入れる支払い方法、適用されるライセンス条件を定義します。作成するには、 [保護パック (ウェブ ACL) を作成] を選択します。 [アプリについて教えてください] で、コンテンツを説明するアプリカテゴリを 1 つ以上選択し ([コンテンツと公開システム]、[E コマースとトランザクションプラットフォーム]、[エンタープライズとビジネスアプリケーション] など)、 [アプリフォーカス] を選択します。AWS WAF はこれらの選択を使用して、お客様の設定に適したセキュリティ保護を推奨します。 [保護するリソースを選択] で [リソースを追加] を選択し、CloudFront ディストリビューションなどのリージョンリソースまたはグローバルリソースをこの保護パックに関連付けます。このステップはスキップして、後でリソースを追加することができます。 [初期保護を選択] で、アプリのカテゴリとリソースの選択に基づいて、AWS WAF マネージドルールパッケージから選択します。パッケージの代わりに個別のルールを選択することもできます。 [名前と説明] に、保護パックの名前と任意の説明を入力します。 オプションで、 [カスタマイズ保護パック (ウェブ ACL)] を展開し、料金階層、支払い方法、コンテンツ範囲、ライセンス条件などの追加設定を行います。 終了したら、 [保護パック (ウェブ ACL) を作成] を選択します。 保護パックが導入されたら、料金戦略を立てる前に、AI トラフィック分析ダッシュボードを確認して、AI ボットトラフィックがコンテンツに与える影響を理解してください。WAF & Shield コンソールで、左側のナビゲーションペインの [AI トラフィック分析] に移動します。ドロップダウンから保護パック (ウェブ ACL) を選択し、ダッシュボードに入力します。 AI トラフィック分析ダッシュボードは、ボットトラフィック概要パネルに表示されるトラフィックを、 すべてのボットリクエスト 、 AI ボットリクエスト 、 検証済み AI ボットトラフィック 、 未検証 AI ボットトラフィック の 4 つのカテゴリに分類します。ダッシュボードには、消費された帯域幅、推定月間コスト、ピークリクエスト率などのインフラストラクチャへの影響メトリクスが表示されます。パスごとのヒートマップには、AI ボットのアクティビティが最も多いコンテンツパスが時間単位で示され、情報に基づいた料金決定を行うために必要なデータを取得できます。 AWS WAF Bot Control は、GptBot、Claude-Web、Perplexity-Bot を含む 650 種類以上の AI ボットとエージェントを分類し、それぞれに検証階層を割り当てます。 検証済み – ウェブボット認証 (WBA) Ed25519 暗号署名によって身元が確認されたか、ユーザーエージェントとドメイン名の既知のセットを使用して文書化されたIP範囲から取得されたエージェント。 未検証 – ユーザーエージェントマッチング、行動フィンガープリンティング、IP レピュテーションによって認識されるが、身元は暗号で確認されていないエージェント。 トラフィックパターンを確認したら、 [保護パック (ウェブ ACL)] に戻り、リストから保護パックを選択し、右側のパネルで [AI 収益化を設定] を選択して料金設定とアクセスポリシーを設定します。各保護パックは、定義された一連のコンテンツパスに適用される料金、エージェントポリシー、利用可能な支払い方法、ライセンス条件を定義します。複数の保護パックを作成し、同じディストリビューション内のさまざまなコンテンツゾーンに異なる価格を適用できます。作成したら、ウェブ ACL を開いて [保護パックを追加] を選択して、保護パックをウェブ ACL に関連付けます。 パック内のエージェント検証レベルごとに、 [収益化] (402 を料金付きで返す)、 [許可 (無料アクセスを許可)] 、 [ブロック (アクセスを完全に拒否)] 、 [カウント (課金せずにログ記録)] 、 [CAPTCHA (パズルを提示して人間の送信者であることを検証)] 、 [チャレンジ (クライアントがボットではなくブラウザであることを確認)] の 6 つのアクションのいずれかを割り当てることができます。 [収益化設定を編集] ページで、次の内容を設定します。 [支払い決済] で、ステーブルコイン決済用のブロックチェーンネットワークを 1 つ以上選択します。自社で管理されているか、コインベースなどのウォレットプロバイダーがホストしているかにかかわらず、サポートされているネットワーク上のすべてのウォレットアドレスを使用できます。ネットワークごとに、ウォレットアドレスを入力し、USDC で 1 ページあたりの基本料金 を設定します。 [ネットワークを追加] を使用して複数のネットワークを追加できます。AWS はコンテンツ収益に対する支払い処理や手数料の徴収は行いません。支払いは自己管理されるか、ウォレットプロバイダーによって管理されます。 収益化 ルールが受信リクエストと一致すると、AWS WAF は HTTP 402 支払いが必要な応答を返します。レスポンス本体には、マシン間決済用の x402 オープンプロトコルを使用した JSON 形式の機械可読価格マニフェストが含まれます。マニフェストには、USDC でのコンテンツ料金、Base や Solana などの受け入れ可能なブロックチェーンネットワーク、宛先ウォレットアドレス、最大支払いタイムアウト、支払いスキームが含まれます。 x402 互換のエージェントランタイムであれば、このフローを自律的に完了できます。クライアントは、選択した支払いネットワークで署名済みの支払い承認を送信します。AWS WAF はそれを検証し、コンテンツを取得し、サードパーティーのファシリテーターサービスと統合してオンチェーンでの支払いを行い、応答を提供します。 収益化 アクションは、Amazon CloudFront ディストリビューションに関連付けられたウェブ ACL でのみサポートされていることに注意してください。リージョナルウェブ ACL への 収益化 ルールの追加はサポートされていません。 通貨モード の切り替えは収益化設定ページから直接利用できるため、 リアル モードと テスト モードはいつでも切り替えることができます。本番環境に移行する前に、非プロダクショントラフィックでテストモードを使用し、料金設定、ウォレット設定、x402 決済フローを検証してください。なお、テストモードでは引き続き x402 の支払いが適用されますが、これらの支払いは、faucet.circle.com などの蛇口から取得したテスト資金を使用して、Base Sepolia や Solana Devnet などのテストネットで行うことができます。テストモードを有効にするには、保護パック設定で [通貨モード] を [テスト] に切り替えます。AWS WAF は実際の価格マニフェストを返し、設定されたテストチェーンで本番環境と同じように支払いフロー全体を実行します。すべてのイベントは CurrencyMode: TEST を使用してログ記録されます。設定に問題がなければ、通貨モードをリアルに戻して実際の支払いの処理を開始します。 [通貨モード] を [リアル] に切り替えたら、左側のナビゲーションペインで [AI アクセス収益化] に移動して、収益化の結果をリアルタイムで追跡します。 AI アクセス収益化 ダッシュボードには、実際の通貨モードからのアクティビティのみが反映され、テストトランザクションは表示されないことに注意してください。 収益ダッシュボードには、 総収益 、 検証済みボット と 未検証ボット 別の収益、 リクエストあたりの平均が表示されます。 上位収益源 パネルでは収益をボットカテゴリ別にグループ化し、AI アクセスパターンパネルでは発生した収益に基づいてコンテンツパスをランク付けします。 決済 タブを使用して、プロバイダーごとに支払いを調整し、支払い方法の配分と失敗した支払い試行を確認します。 今すぐご利用いただけます AI トラフィックの収益化は、Amazon CloudFront のお客様において、標準の AWS WAF 料金を超える追加料金なしでご利用いただけるようになりました。この機能は、AWS WAF ウェブ ACL が Amazon CloudFront ディストリビューションに関連付けられているすべてのエッジロケーションで利用できます。 AI トラフィックの収益化の詳細については、「 AWS WAF デベロッパーガイド 」を参照してください。 – Esra 原文は こちら です。

本記事は 2026 年 5 月 5 日 に公開された「 Amazon Aurora DSQL for global-scale financial transactions 」を翻訳したものです。 Amazon Aurora DSQL を使えば、強い整合性と低レイテンシーを両立しながら、複数の AWS リージョンにまたがるグローバル規模の金融トランザクションを実行できます。従来はこの選択にコストが伴いました。夜間のリコンシリエーションバッチ、手動フェイルオーバー手順、顧客残高や決済を扱うシステムでの短時間のデータ不整合リスクなどです。Amazon Aurora DSQL はグローバルに整合性のある強い耐久性を持つトランザクションを、アクティブ-アクティブの可用性とサーバーレス運用で提供し、従来のトレードオフを解消します。 本記事ではまず、分散整合性に対する従来のアプローチが金融ワークロードで不十分な理由を検証します。次に Amazon Aurora DSQL のアーキテクチャが分散整合性の課題にどう対処するかを説明し、3 つの本番ユースケース (勘定系、グローバル支出管理、デジタル通貨インフラストラクチャ) に適用します。最後に実装上の考慮事項と、 Amazon Aurora DSQL 無料利用枠 での始め方を紹介します。 金融サービスデータベースに求められる要件の変化 金融データベースには常に整合性と可用性が求められてきました。変わったのは運用環境です。10 年前、トランザクション処理のほとんどはリージョナルでした。銀行の中央台帳は 1 つのデータセンターで稼働し、トレーディングシステムは単一の取引所に対応し、日次バッチによる突合処理は当たり前のものとして受け入れられていました。現在、顧客は地理的に分散した拠点間でのリアルタイムな可視性を求め、規制当局は取引報告の期限を厳格化し、マルチリージョンでの可用性はもはや付加価値ではなく競争上の必須要件となっています。 よくあるシナリオで課題を説明します。あるリージョンの口座から引き落とし、別のリージョンの口座に入金する処理を、単一のトランザクションで実行する必要があります。従来の解決策は 2 フェーズコミット (2PC) で、コーディネーターノードが各参加者から合意を集めてからコミットします。動作はしますが、コーディネーターが単一障害点となり、ラウンドトリップ全体にわたってロックを保持し、部分的な障害にはテストが困難で運用コストの高いリカバリロジックが必要です。リージョン間ではコーディネーターのラウンドトリップに数百ミリ秒が加わり、クロスリージョントランザクション中のロック競合が最も重要なタイミングでスループットを制限する可能性があります。 多くのチームが代替手段として選ぶのは、非同期レプリケーションによる結果整合性、競合解決を伴うマルチプライマリ構成、あるいは専用の分散データストアです。これにより 2PC の調整負荷は回避できますが、その負担はアプリケーション開発者にのしかかります。共有状態を扱うサービスすべてに冪等性、競合解決、突合ロジックを実装しなければなりません。一時的な不整合を許容し、それを運用リスクモデルに織り込むチームもあります。分析やキャッシュのワークロードでは合理的なトレードオフですが、顧客残高、決済、取引を直接扱う場合には正当化が難しくなります。 Amazon Aurora DSQL はこの 2 つのアプローチの間を埋めます。2PC の調整負荷なしに強い整合性を提供し、結果整合性の突合負債も発生しません。 Amazon Aurora DSQL のアーキテクチャと金融サービスへの意義 Amazon Aurora ストレージエンジンの利点を、AWS リージョン間の分散運用向けに拡張した形で利用できます。 Amazon Aurora DSQL の紹介 でアーキテクチャの詳細を解説しています。ここでは金融サービスワークロードで最も重要な特性に焦点を当てます。 アクティブ-アクティブのマルチリージョン設計です。クラスターをデプロイした全リージョンで読み書きが可能です。各リージョンのノードは対等なピアとしてトランザクションを受け付け、書き込みトランザクションはリージョン間およびウィットネスリージョンに同期レプリケートされます。 ウィットネスリージョン は、軽量かつ中立的な第三の拠点で、コミットの判定に参加することで 3 拠点間のクォーラム（多数決）を維持し、トランザクションの永続性を確認します。クォーラムには 3 つの参加者のうち少なくとも 2 つの合意が必要なため、3 リージョンが必要です。2 つのアクティブリージョンのうち 1 つが停止しても、残りのアクティブリージョンとウィットネスリージョンで過半数を構成できるため、中断やデータ損失なくトランザクションのコミットが継続されます。もしウィットネスなしの 2 リージョン構成だったら、1 リージョンが失われた時点で、処理中のトランザクションがコミットされたのかどうかすら確認できなくなります。 マルチリージョンクラスターにより、データベースレイヤーで最大 99.999% の可用性を実現します。マルチリージョン運用を必要とするレジリエンス戦略において、手動フェイルオーバー、プライマリ/セカンダリの調整、フェイルオーバー後のデータ突合の構築・維持が不要になります。これは、各リージョンで独立して動作するアクティブ-アクティブのアプリケーション層と組み合わせると最も効果的で、スタック全体がすべてのレイヤーで集中的な調整なしにリージョン障害を吸収できるようになります。 サーバーレスで運用・スケーリング。キャパシティプランニング、レプリカ管理、シャーディング戦略の設計は不要です。コンピュート、コミット、ストレージの各レイヤーが独立して自動的にスケールします。Amazon Aurora DSQL は消費したコンピュートと I/O に対して課金されます。マーケットオープンや四半期末のスパイク時に使用した分だけ支払い、閑散期のアイドルには課金されません。予測困難な需要パターンを持つ金融ワークロードでは、従来のプロビジョニング型データベースアーキテクチャと比較して大幅なコスト削減が見込めます。 整合性モデル。トランザクションは最寄りのリージョンでローカルに実行され、Amazon Aurora DSQL は変更を伴うトランザクションのコミット時にのみリージョン間で調整します。整合性モデルはスナップショット分離を伴う楽観的同時実行制御 (OCC) で、トランザクション実行中にロックを保持しません。読み取り専用トランザクションはローカルのレイテンシーで完了し、リージョン間調整なしに一貫性のあるスナップショットを参照できます。書き込みトランザクションはコミット時にのみクロスリージョン調整コストが発生するため、調整ウィンドウは最小限に抑えています。 代わりに、各トランザクションはデータの一貫したスナップショットに対して動作し、Amazon Aurora DSQL はコミット時にのみ競合をチェックします。2 つのトランザクションが同じ行を変更した場合、一方が正常にコミットされ、もう一方はシリアライゼーションエラーとなり、アプリケーション側でリトライします。 この特性は以降のユースケースで重要です。通常は異なる行 (異なる口座、異なる取引) に触れるワークロードでは、競合は最小限です。同じ行を頻繁に更新するワークロードでは、カウンターをインプレースで更新するのではなく新しい行を追加するなど、行レベルの競合を減らすスキーマ設計が有効です。 Amazon Aurora DSQL のドキュメント で OCC 向けスキーマパターンの詳細なガイダンスを提供しています。 PostgreSQL 互換性。PostgreSQL を使用しているチームは、既存の SQL 構文、ドライバー、クライアントライブラリを Amazon Aurora DSQL でそのまま使用できます。本記事の例では馴染みのある PostgreSQL パターンを使用しており、既存のリレーショナルスキーマを最小限の変更で移行できます。Amazon Aurora DSQL が現在サポートしていない PostgreSQL 機能については、 Amazon Aurora DSQL の使用に関する考慮事項 を参照してください。 金融サービスのユースケース 以下のユースケースに共通するテーマは、複雑なマルチデータベースアーキテクチャを単一のグローバルに整合性のあるデータレイヤーに置き換え、突合プロセスや手動フェイルオーバー手順を排除する点です。異なるのは具体的な運用コンテキストと規制上の要件です。 勘定系と台帳の整合性 勘定系アプリケーションは、顧客口座、残高、トランザクションの正確なリアルタイム台帳を管理します。地理的に分散して運用する大規模銀行は、従来はリージョンごとに別々の勘定系を運用するか、バッチ処理でデータを同期していました。 これには 2 つの問題があります。プライマリリージョンがダウンすると、トランザクション処理が停止するか、データ損失を伴うフェイルオーバーが発生します。通常運用時でも、あるリージョンでの残高クエリが別のリージョンで処理された最近のトランザクションを反映していない場合があります。規制当局と顧客は、リージョン間での継続的な可用性とリアルタイムの正確性を期待しています。 Amazon Aurora DSQL は、各支店やリージョンのアプリケーションがローカルエンドポイントに読み書きを行い、更新は全リージョンに自動伝播することで、この問題を解決します。米国東部 (オハイオ) で処理された入金は、米国西部 (オレゴン) から照会する窓口担当者にも即座に表示されます。あるリージョンが利用不能になっても、残りのリージョンはデータ損失も手動フェイルオーバーもなくトランザクション処理を継続します。データベースが単一のグローバルに整合性のある状態を提供するため、システム間の突合なしに全リージョンから規制報告を作成できます。 具体例として、2 つの口座間の資金移動を考えます。従来のマルチリージョンアーキテクチャでは、リージョナルデータベース間の部分的な障害に対処するために、Saga パターン、メッセージキュー、補償トランザクションが必要になる場合があります。Amazon Aurora DSQL では単一の ACID (原子性、整合性、分離性、耐久性) トランザクションに簡素化できます。 以下のスキーマは、Amazon Aurora DSQL の分散アーキテクチャ向けに最適化されたいくつかの設計選択を示しています。UUID 主キーはリージョン間でのシーケンシャル ID の調整負荷を回避します。CHECK 制約はアプリケーションコードではなくデータベースレベルでビジネスルールを適用します。TIMESTAMPTZ 列はどのリージョンがトランザクションを処理しても一貫したタイムスタンプを提供します。これらの例ではわかりやすさのためにリテラル値を使用しています。本番環境では SQL インジェクションを防ぐため、データベースドライバーを通じたパラメータ化クエリを必ず使用してください。アプリケーションコードで送金開始前に十分な残高があることを検証する必要があります。以下の SQL は Amazon Aurora DSQL playground でインタラクティブに実行できます。 -- Schema: simplified core banking ledger CREATE TABLE accounts ( account_id UUID PRIMARY KEY, customer_id UUID NOT NULL, balance NUMERIC(18,2) NOT NULL CHECK (balance >= 0), currency VARCHAR(3) NOT NULL, updated_at TIMESTAMPTZ DEFAULT NOW() ); CREATE TABLE transactions ( transaction_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), from_account UUID NOT NULL, to_account UUID NOT NULL, amount NUMERIC(18,2) NOT NULL, description TEXT, created_at TIMESTAMPTZ DEFAULT NOW() ); -- Funds transfer as a single ACID transaction BEGIN; UPDATE accounts SET balance = balance - 500.00, updated_at = NOW() WHERE account_id = 'acct-1234' AND balance >= 500.00; UPDATE accounts SET balance = balance + 500.00, updated_at = NOW() WHERE account_id = 'acct-5678'; INSERT INTO transactions (from_account, to_account, amount, description) VALUES ('acct-1234', 'acct-5678', 500.00, 'Funds transfer'); COMMIT; 口座の更新と取引き録は、アプリケーションがどのリージョンに接続していても原子的にコミットされます。送金元の残高が不足している場合、CHECK 制約で弾かれトランザクション全体がロールバックされます。片方の口座だけが引き落とされ、もう片方に入金されていない、そんな中間状態は起こりません。Saga オーケストレーション、補償トランザクション、夜間の突合バッチは不要です。 振替は通常、異なる口座行を操作するので、異なる口座に対する並行トランザクションは Amazon Aurora DSQL の楽観的同時実行モデルで競合なくコミットされます。まれに 2 つのトランザクションが同時に同じ口座を対象とするケースでは、OCC がコミット時に競合を検出し、一方のトランザクションがリトライされます。アプリケーション側でロックを取る必要はなく、整合性は保たれます。 グローバル支出管理と法人カードシステム 現代の支出管理サービスは、世界中の数千の企業のあらゆる金融取引を承認・追跡する集中的な意思決定レイヤーとして機能します。カードの利用、ACH (Automated Clearing House) 送金、電信送金、経費精算のいずれも、残高、与信限度額、加盟店管理、リスクスコア、会計マッピングに対する複数のトランザクション更新を発生させます。これらの操作は異なるロケーションから数秒以内に発生することが多く、わずかな不整合 (例: 承認判定に対して残高更新が遅れる) でも取引の拒否、過剰支出、不正リスクの露出につながります。 Amazon Aurora DSQL を使えば、リージョン間で単一のグローバルに整合性のある台帳を維持できます。各リージョンがローカルで書き込みを受け付け、同じグローバルに整合性のあるトランザクションセットの一部としてコミットします。これは、異なるリージョンにデプロイされた複数の決済プロセッサーや銀行パートナーと連携する場合に特に有用です。最大の価値は、統合された台帳と突合レイヤーにあり、リージョナルデータベース間のバッチ同期なしにグローバルに整合性のある残高ビュー、支出管理、会計記録を維持できます。 デジタル通貨インフラストラクチャ グローバルなデジタル通貨発行体は、複数のリージョン、ブロックチェーン、銀行パートナーにまたがる発行、償還、送金、決済をサポートする常時稼働サービスを運用しています。これらのサービスは、トークン供給量、顧客残高、取引状態を正確に追跡するリアルタイム台帳の維持が不可欠です。発行（ミント）、焼却（バーン）、送金イベントを取引所、決済プロセッサー、銀行パートナーの近くでローカルに処理でき、Amazon Aurora DSQL がそれらを原子的にコミットしてグローバルに可視化します。流通供給量、顧客残高、取引履歴はリージョン間で継続的に同期されます。 AWS 無料利用枠で始める 永続的な AWS 無料利用枠 と、分散データベース設計の専門知識がなくても開発を加速する AI スキルを利用できます。無料利用枠には毎月 100,000 Database Processing Units (DPU) と 1 GB のストレージが無料で含まれ、開発環境の運用や小規模アプリケーションのサポートに十分な容量です。 Amazon Aurora DSQL AI スキル は、分散ワークロード向けのスキーマ設計、外部キーなしの参照整合性、初日から本番対応のアプリケーション構築を支援します。Kiro や Claude Code などの AI コーディングツールと連携し、分散トランザクション向けに最適化されたスキーマ設計、レジリエントなマルチリージョンアプリケーションアーキテクチャの構築、既存の PostgreSQL ワークロードの Amazon Aurora DSQL への移行などのタスクについてインタラクティブなガイダンスを提供します。 Amazon Aurora DSQL スキルの全セットについては、 Amazon Aurora DSQL ステアリングガイド を参照してください。 まとめ 本記事では、Amazon Aurora DSQL がグローバルに分散した ACID トランザクション、最大 99.999% の稼働率を持つアクティブ-アクティブの可用性、サーバーレス運用を単一のマネージドサービスで実現する方法を紹介しました。2 フェーズコミットと結果整合性の限界にアーキテクチャがどう対処するかを説明し、金融サービスチームが構築する 3 つの本番パターン (原子的なクロスリージョン送金を行うコアバンキング台帳、グローバルに整合性のある経費管理システム、リージョン間で流通供給量と残高を同期するデジタル通貨プラットフォーム) に適用しました。 実際に試すには、 Amazon Aurora DSQL サービスページ から無料利用枠クラスターを作成し、 開発者ガイド で接続設定、クエリパターン、スキーマ設計を確認してください。アーキテクチャの詳細や機能比較については Amazon Aurora DSQL のドキュメント を参照し、移行のビジネスケース構築については AWS アカウントチームにご相談ください。 著者について Trevor Spires Trevor は、AWS の金融サービス担当シニアソリューションアーキテクトです。キャピタルマーケットおよびフィンテックのお客様と密接に連携し、コアインフラストラクチャと AI システムのクラウドでのスケーリングとセキュリティ確保を支援しています。 Raluca Constantin Raluca は、Amazon Aurora DSQL を専門とする AWS のシニアデータベースエンジニアです。Oracle、MySQL、PostgreSQL、クラウドネイティブソリューションにわたる 18 年のデータベース経験を持ち、データベースのスケーラビリティ、パフォーマンス、リアルタイムデータ処理に注力しています。 Jigna Gandhi Jigna は、AWS の金融サービス担当シニアソリューションアーキテクトです。フィンテック、Web3、銀行組織と密接に連携し、最新の金融プラットフォームを支えるスケーラブルでセキュアかつレジリエントなクラウドおよび AI ソリューションを設計しています。 Narendra Reddy Bathina Narendra は、AWS の金融サービス担当テクニカルアカウントマネージャーです。フィンテックのお客様と連携し、データベース、ストレージ、クラウドオペレーションの豊富な現場経験を活かして、本番システムのレジリエンス、パフォーマンス、スケーラビリティの向上を支援しています。 Viraj Padte Viraj は、AWS の金融サービス担当シニアソリューションアーキテクトです。さまざまなフィンテックのお客様と連携し、コアビジネスおよび AI を活用したプラットフォームとソリューションを支えるエンタープライズ対応のインフラストラクチャを設計しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

はじめに お久しぶりです！3年目社員の藤岡、山本です。 2026年4月15日〜17日に東京ビッグサイトで開催中の「 AI・人工知能EXPO【春】 」に参加してきました。会場の雰囲気と印象に残ったセッションの学びをまとめます。 生成AIに加えて、AIエージェントやフィジカルAIまで幅広いテーマが扱われており、単に最新技術を眺めるだけでなく、「AIをどう業務に組み込むか」を考えるうえでも刺激の多いイベントでした。 前回は、2025年夏に開催された AI博覧会 Summer 2025 に参加し、その内容を社内ブログ記事としてまとめています。ぜひ、そちらも参照ください！ 前回の記事：AI博覧会 Summer 2025 に参加してきました！ AI・人工知能EXPO 会場入口の様子1 AI・人工知能EXPO 会場入口の様子2 AI・人工知能EXPOとは 開催日： 2026年4月15日（水）〜 17日（金）10:00〜17:00 会場： 東京ビッグサイト（西展示棟） 関連URL： AI・人工知能EXPO【春】公式サイト AI・人工知能EXPO【春】 は、NexTech Week 2026内で開催されている日本最大級のAI技術専門展です。今回のNexTech Week 2026では、全46講演、300社が出展しており、生成AI、AIエージェント、RAG、AIインフラ、ロボットなど、業務活用に直結する技術・サービスが幅広く集まっていました。 前回のイベントとの違い 前回参加した AI博覧会 Summer 2025 が生成AIの活用事例や社会実装によりフォーカスしていたのに対して、今回は AI エージェント、データ基盤、ロボティクスまで含む、より広い技術領域を扱っていたのが印象的でした。会場も東京ビッグサイトで3日間開催と規模が大きく、関連展示までまとめて見られる構成でした。 なぜ参加したの？ 現在、山本と藤岡は社内の AI CoE（Center of Excellence） というバーチャルチームに所属し、AIの社内活用推進や、実際の開発への導入支援を行っています。そのため、AI関連の最新情報をキャッチアップしたいという思いから、今回のイベントに参加し、社内に持ち帰れる学びやヒントを得ることを目的にしました。 ニフティで社外イベントに参加するには 今回も前回のイベント参加時と同じように ・藤岡・山本 「前回より大きい日本最大級のAIイベントがあるらしいんですが、行ってもいいですか？」 ・上司 「いいね。ぜひ知見持って帰ってきてください！」 社外イベントへの参加は、まずはこんな感じで気軽に相談すればOKが出ることが多いです。参加して得た知見を社内に持ち帰って共有する文化があるので、「行って終わり」ではなく、学びをチームや会社の成長につなげやすいのもニフティらしさだと感じています。 現地の様子 会場は東京ビッグサイトで、セミナーと展示を行き来しながら回れる構成でした。AIエージェントや生成AIに関するセッションの注目度は高く、業務効率化だけでなく、組織変革や新しい働き方までテーマが広がっているのが印象的でした。 まずはセミナーを中心に回りながら、気になるブースや関連領域の展示も見て回りました。 会場内の展示エリア入口の様子 セッション 特に印象に残ったのは、以下の2つのセッションです。 アプローチはそれぞれ違うのですが、どちらも「これまでAIとどう付き合ってきたか」「これからどう共存していくか」を改めて考えるきっかけになる内容でした。 1. フィジカルAIがもたらす産業変革 NVIDIAの荒井 謙さんは、フィジカルAIを「現実世界と相互作用し、自律的に判断・行動するAI」として整理し、ロボットや自動運転に限らず幅広い領域に広がる概念だと紹介していました。 実現には、モデル学習、実世界でのデプロイ、デジタルツイン／シミュレーションの3つの計算環境が重要で、現実データ収集のコストや危険を補うためにシミュレーションや世界基盤モデルの活用が鍵になります。 現在はまだ立ち上がり期ですが、生成AIと同様に今後急速に発展し得る領域として、監視・点検・製造・物流などへの波及も含め継続してウォッチしたいと感じました。 セッションの様子 2. なぜ企業はClaudeを選ぶのか——Anthropicの安全性という価値 Anthropic Japanの岡田 大志さんによる講演では、Claudeを「便利な生成AI」としてではなく、 企業が重要な仕事を任せられるAI として成立させるために、 安全性をどう設計し、どう検証し、運用に組み込むか が語られていました。 特に印象に残ったのは、Constitutional AI（憲法AI）やRed Teamなどで判断基準やテストを体系化している点に加えて、 安全性を優先できるように組織の仕組み自体にもガードレールを入れている 点です。たとえば、公益性を組織の目的に組み込むことや、長期的な利益を担保するための独立した仕組み（株主の意向が強く働きやすい場面でも、安全性へのコミットが揺らぎにくい構造）が紹介されていました。 AI活用バーチャルチームメンバーとして、社内展開を考えるうえでも、ツール単体の機能比較ではなく、アクセス統制・監査・データ保護・人の確認といった ガバナンス込みで設計する重要性 を改めて感じました。 セッションの様子 企業展示ブース 展示エリアには多くの企業が出展しており、生成AI、AIエージェント、データ基盤、ロボティクスなど幅広いテーマのブースが並んでいました。実際に見て回ると、単なる技術デモではなく、 教育・運用・現場導入まで含めてAIをどう業務に組み込むか を具体化した展示が多かったのが印象的でした。 展示ブース入口の様子 1. 株式会社KIZASHI 株式会社KIZASHIのブースでは、生成AIパスポート風の問題に答えながら「生成AIリテラシー診断」を体験でき、いまの理解度を手触り感をもって把握できる展示になっていました。生成AI活用普及協会（GUGA）に認定されている取り組みとのことで、学習コンテンツと診断をセットで提供している点も印象的でした。 ブースの様子 体験後にはノベルティで「生成AIパスポート」の書籍もいただけました。 そして何より、ブース内の診断を実際に受けてみたところ……なんとランキング5位にランクイン。会場でその場のノリのまま挑戦できる感じも含めて、かなり楽しかったです。 5位に入賞…！（名前は藤岡のニックネームです） 2. FlashIntel Japan株式会社 FlashIntel Japanのブースでは、CS（カスタマーサポート）業務を主戦場にした音声AIエージェントの展示が行われていました。音声モデル Chroma と FlashAI Voice Agents を軸に、営業コールや問い合わせ対応など「電話」を起点にした業務を、ナレッジベース化〜FAQ生成〜応対への反映まで一気通貫で支える構成がわかりやすかったです。 ブースの様子 特に印象に残ったのは、デモで体験できた“人に近い自然な音声”と低遅延な受け答えでした。 当社でもCSを内製で運営していることもあり、「一部でも試してみると面白そうだな」と素直に感じました。 FlashIntel Japan のデモ画面 他のEXPOも隣接して同時開催 NexTech Week 2026【春】は、AI・人工知能EXPOを含む 合計5つの展示会 で構成されています。1回の来場登録でまとめて見られるので、AI単体というより「周辺の技術・人材・実装」まで一気に俯瞰できるのが良さでした。 ブロックチェーン EXPO ：Web3、NFT、DAOなど、ブロックチェーン技術のビジネス活用を扱う展示会。 量子コンピューティング EXPO ：量子計算の研究から産業応用まで。まだ先の技術に見えつつも「触れておく価値」がある領域。 AI時代の人材・組織改革 EXPO ：旧「デジタル人材育成支援EXPO」。リスキリングや人材開発、組織づくりなど、導入を支える“人と仕組み”側の展示。 ヒューマノイドロボット EXPO ：人と共に働く次世代ロボットの実装・活用にフォーカスした新設EXPO。 ヒューマノイドロボット EXPOの様子1 ヒューマノイドロボット EXPOの様子2 今回のイベント参加で学んだこと 今回のイベントで特に印象的だったのは、フィジカルAIが想像以上に実用段階へ進んでいたことです。これまではXなどで見かける「まだ使えないロボット」の印象を持っていましたが、実際には着実に技術が前進しており、世界基盤モデルのような考え方も含めて、今後さらに広がっていきそうだと感じました。また、AI活用は特定の業界に閉じた話ではなく、さまざまな分野へ発展しており、業種が違っていても参考にできるアプローチが多くありました。現場ごとの多様なニーズに応える製品も多く、AIがより具体的な業務課題の解決に近づいていることを実感しました。 反省点 ブースがかなり多いので、あらかじめ自分たちが興味のある分野を絞っておくことで、当日落ち着いて回ることができると感じた フィジカルAIが世間的に注目されているのは知っていたが、事前知識不足により内容が難しく感じた こんなところにあのキャラクターが,,,! まとめ AI・人工知能EXPO【春】 は、最新技術を眺める場であると同時に、 これからの仕事の進め方をどう変えていくか を考える場でもありました。今回の参加を通じて強く感じたのは、AI活用の価値は新しい技術そのものよりも、それを現場の業務や組織の流れの中でどう定着させるかにあるということです。セッションや展示で得た気づきを、単なるイベント参加の思い出で終わらせず、今後の業務や社内でのAI活用推進にどうつなげていくかが大切だと改めて感じました。 ニフティのAI活用について ニフティでは、所属部署や職種を越えて有志が集まるAI活用のバーチャルチームが活動しています。日々の開発や業務改善の延長線上でAIを活用し、技術トレンドを「見て終わり」にせず、実際の業務にどう生かすかまで試せる土壌があります。だからこそ、AIに興味がある方、業務の中で新しい活用を試してみたい方、技術を使って働き方を変えていきたい方は、ぜひ一緒に挑戦しましょう！実際に手を動かしながら社内のAI活用を前に進めていける仲間を募集しています。 AI活用バーチャルチームについては、こちらのインタビュー記事でも紹介されています。 AI活用バーチャル チーム のインタビュー記事