本記事は 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 がレビューしました。

はじめに こんにちは、リテールハブ開発部でバックエンドエンジニアをしているホシと申します。 現在、Laravel などを利用しながら小売アプリ開発に取り組んでいます。 少し前になりますが、先日3月17日にLaravel13がリリースされました。 （ https://laravel.com/docs/13.x/releases ） 昨年にもLaravel12について、バージョンアップ内容などを記事にしたのですが、 今年も新バージョンについてお話しできればと思います。 前回同様にまずはサポート期限の一覧を記載します。 1年サイクルでリリースしているのと、サポート期間はあっという間に過ぎてしまうことがわかります。 毎年のバージョンアップは大変でも2年ごとくらいには実施した方が良さそうです。 Laravel13の機能の紹介やバージョンアップ方法などはすでにたくさんあるとは思いますが、 本記事では、Laraveをバージョンアップする際にどんなことが必要かを調べてみたのと、 今回のLaravel13の大きな特徴として「破壊的変更を抑えつつ、AI時代向けにLaravelを進化させたバージョン」のようなので、 AI関連の気になる機能についても、あまり詳しくない私を含め、なるべくわかるような内容にできればと思います。 Laravel13のバージョンアップよりも、PHPバージョンアップが大変？ 今回もLaravelのバージョンアップ自体は破壊的変更も少なく、比較的低コストでできるようなのですが、 今回のバージョンでは、PHPが8.3からになりました。 PHP8.2以下の場合、ここが実は一番手間がかかる対応なのかもしれません。 まずはPHP8.3に変更することが問題なくできるかを調べるのが先になります。 また、今回のタイミングでできれば8.4まで上げることができれば、 今後のバージョンアップもスムーズにしやすくなるので、なるべく最新にしたいところです。 ただ、8.5まで上げてしまうとまだサポートしていないものなどでうまく行かない可能性も高くなるので、 8.4で試してみるのがバランスが良いのかなと思いました。 バージョンアップする際の対応項目 先ほどはPHPを上げる方が大変かもと記載していますが、 laravelの変更点もカバーすることを考えるとどちらもそれなりに対応は必要そうです・・・。 以下に現環境で必要な対応項目を整理してみました。 1. ランタイム / 環境の確認 PHP を最低 8.3（推奨 8.4）に統一 composer.json Dockerfile PHP 拡張・PECL（Swoole / OpenSwoole）が PHP 8.3/8.4 対応バージョンか確認 ECS タスク定義側で参照している base image / runtime も同期 2. 現在使用しているLaravelは全て13に対応しているか laravel/sanctum laravel/octane laravel/tinker laravel/boost laravel/pint など、使用しているもの全てが「13」に対応しているか確認しておく。 (上記は一部最新の情報ではないかもしれませんので参考程度にしてもらえると幸いです。) 3. 周辺ライブラリ（互換確認・場合によりバージョンアップ） sentry/sentry-laravel aws/aws-sdk-php など、周辺ライブラリがまだ未対応などがありそうなので、調べておく必要あり。 4. テスト / 静的解析（バージョンアップ対応） PHPUnit: 12.x（Pest 3 が要求） Pest: 3.0 へ移行 tests/Pest.php の uses() / プラグイン構成見直し Larastan phpstan.neon のルール再調整必須 mockery/mockery fakerphp/faker など、テストに関する変更は調べる限り、いろいろ見直しも必要そうです。 ちょっとここは詳しくないので、実際には試行錯誤しながらやらないと詰まりそうな雰囲気も感じています。 5. コード内の修正・確認が必要そうなところ（一部抜粋） Carbon 3 への移行（Laravel 12 から Carbon3.x を使用する必要あり） → now(), Carbon::parse() を使う全箇所を回帰テスト Eloquent / Query Builder → クエリの修正は不要の見込み Container / Service Provider → bootstrap/providers.php に記載すること推奨されていて、 Validation → カスタムルールがある場合、問題ないか確認など Authentication / Authorization → Hash::make の確認、Sanctum トークン形式の互換性確認など Octane → State leak / メモリリークなどが起きないかなど あまり特殊な処理などはしていないのですが、Carbon系は特にたくさん使っているのでよくみた方が良さそうでした。 テスト実行して問題ないか全体を確認は必須ですが、 基本的には利便性向上、追加機能系なので動かなくなるなどほぼほぼなさそうです。 メモリリークとかそういったものがすぐにはわかりにくいのでここもしっかり確認はした方が安全かなと思います。 6. CI / Docker / デプロイ バージョンを変えるなどは必須だと思いますが、 あとは環境やもともと記載している内容に合わせての変更になると思います。 ここは実際に動かしながら修正・動作確認して間違いの無いようにしたいです。 7. アップデート手順 もし複数バージョンアップの場合は、アップデート手順として推奨されているのは、 Laravelでも段階アップデートが安全なようなので、12 → 13 のように段階アップデートにするか、 一気に上げる方法にするかは変更、確認コストを見て決めていけると良いかなと思います。 Laravel 13の気になる機能：AIサポート ここからは、Laravel 13で一番気になったAI関連機能についてお話しできればと思います。 特に注目したいのは以下です。 Laravel AI SDK Embeddings Vector Search Semantic Search 今までは、様々なライブラリや外部サービスを組み合わせてAI検索などを実現する必要がありましたが、 Laravel13では、Laravel標準に近い形で実装できるようになっています。 ただ、Laravel13自体がAIモデルを持っているわけではなく、実際には外部のAIサービスを利用してEmbedding生成や意味検索を行います。 Laravel13では、それらをLaravelらしいAPIで扱いやすくなった、というイメージです。 また、Laravel側でAIサービスの差異をある程度吸収できるため、将来的に利用するAIモデルやサービスを変更しやすくなる可能性があります。 従来のように各AIサービスごとに個別実装するよりも、Laravelアプリへ組み込みやすくなったのかなと思いました。 Embeddingsとは？ そもそも、上記の各AIに関連するワードについてもしっかりと理解できていなかったので調べてみました。 Embeddingsとは、文章をAIが扱いやすい数値データに変換する仕組みです。 例えば、 「胃に優しい料理」 という文章を、AIが意味を比較できるベクトルデータに変換します。 内部的には： [0.183, -0.929, 0.442, ...] みたいな大量の数値になります。 この数値化はすでに大量の文章、単語関係、文脈を学習済みのモデルを利用することで実現できています。 use Illuminate\Support\Str; // 検索したい文章をEmbedding化する $embedding = Str::of('胃に優しい料理')->toEmbeddings(); 以下のwhereVectorSimilarTo() は、内部で検索文をEmbedding化し、保存済みEmbeddingとの意味距離を比較するイメージです。 use Illuminate\Support\Facades\DB; $recipes = DB::table('recipe_embeddings') ->whereVectorSimilarTo('embedding', '胃に優しい料理') ->limit(10) ->get(); このようなEmbedding生成やVector SearchをLaravelらしいAPIで扱いやすくなりました。 また、DB保存はPostgreSQLのpgvectorを利用してデータを保存したりします。 他にもいろいろあるようなのですが、ただMySQLだと、すでにVector Search関連機能が追加され、Embeddingを利用した類似検索自体は可能なのですが、 最適化やパフォーマンス面ではpgvectorなどを利用する方が現状は良いようです。 そのため、もしすでにMySQLを使用している場合は使い分けが一番コスト面、メリットの点で良いのかなと思います。 これにより、単なる文字一致ではなく、 数値の近似値の比較をすることができるようになり、 胃に優しい ↓ 雑炊、豆腐、うどん、茶碗蒸し のように、意味が近いものを検索しやすくなります。 Vector Searchとは？ Vector Search（ベクトル検索）は、 ベクトル同士の距離を比較して、近いものを探す技術です。 つまり、 検索文 ↓ Embedding（数値化） ↓ DB内のベクトルと距離比較 ↓ 近いものを取得 という流れになります。 意味が近い文章ほど、数値的にも近い位置に配置されるため、Semantic Search「意味検索」をしているようになります。 LIKE検索と意味検索の違い 従来のLIKE検索は、文字が一致するものを探します。 WHERE name LIKE '%豆腐%' これは商品名やコード検索には強いです。 一方、意味検索は、 疲れている時に食べたい 夜でも重くない 夏バテでも食べやすい のような曖昧な検索に向いています。 これにより、レシピや記事など様々な情報を持っているものから キーワード検索のような文字列一致ではなく、意味検索をできることから キーワード検索では拾えないような曖昧な検索にも対応できるようになります。 ハイブリッドがバランス良い 意味検索は強力な検索ですが、上記の商品名やコード検索には弱く、 どちらにもメリット、デメリットがあるため、 LIKE検索から切り替えるのではなく、組み合わせるのが一番バランスが良いかなと思います。 まずLIKE検索 結果が少なければVector Search 重複を除いて結果を返す 商品名検索ならLIKE検索で十分なことも多いです。 一方、レシピ検索や記事検索のように「意味」や「状況」で探したいものは、Vector Searchと相性が良いです。 上記は例になりますが、ここは工夫の余地の大きいところでもあり、 仕様や検索内容、実施頻度、パフォーマンスなどを考慮して実現できるようにしたいです。 精度を上げるポイント ここは私は勘違いしていましたが、 Vector Searchは、データ件数よりも説明文や属性情報が重要です。 確かにいくら大量にデータがあっても、１つ１つの情報が少ないと意味を持たせられないと思いました。 悪い例： 麻婆豆腐 良い例： 辛味が強く、ご飯が進む中華料理。 豆腐とひき肉を使った定番メニュー。 満足感があり、夕食向き。 このように、AIが理解しやすい説明を持たせることで検索精度が上がります。 精度検証の進め方 ここまででとりあえず試してみたいと思った際は、最初から大規模に導入する必要はありません。 検証の際も大量のデータというよりは、１つ１つのデータ量が揃っているかが重要で、 その上で、まずは小さく試すのが良さそうです。 500〜3000件程度のデータを用意 検索クエリを30〜100個作る LIKE検索とVector Searchを比較する 上位5件に納得できる結果があるか確認する 最初は厳密な評価指標より、人間が見て「使えそうか」を確認するだけでも十分です。 最後に いかがでしたでしょうか。 今回のバージョンアップはAI関連の進化が大きな特徴だったことがよくわかりました。 私でも実際に簡単なAI検索であれば、比較的低コストで実装もできそうなので、導入も気軽にできます。 もちろん精度アップや検証面はどうしても最初は大変かと思いますが、少しずつ試しながらノウハウも蓄積しつつ 少しずつ規模を大きくしつつ、応用していくのが大事かなと思いました。 ただ肝心のバージョンアップはそこまでコード改修は不要なものの、 全体を見るとやることは多いので、しっかり時間を確保して対応が必要かなと思います。 今後のLaravelバージョンアップの際にぜひ少しでも参考にしていただければ幸いです。 最後までお読みいただき、ありがとうございました。

はじめに こんにちは。リテールハブ開発部の清水です。 私たちのチームでは、外部システムと深夜帯にCSVをやり取りするバッチシステムを開発・運用しています。 これらのバッチ群は適切な順番で適切な設定で実行することが求められるのですが、 新メンバーがジョインしたとき、これをローカル環境で実際に動かして確かめるのはハードルが高いと感じていました。 本記事ではこのようなバッチシステムを動作確認しやすくするために考えた点をご紹介します。 対象のバッチシステム 本番のインフラ構成イメージ ローカル開発環境 Docker Composeで FTP / S3互換ストレージ / MySQL を立てて、Goバッチがそれらに対して動作する形です。 動作確認が大変な理由 外部システム連携であること 外部システム側のフォーマット仕様書は手元にあるのですが、仕様書を読むだけだとピンとこない箇所がそれなりにあります。 さらに本物のCSVは非常にカラム数が多い上、センシティブな情報も含まれるので、軽い気持ちで実物を見るのはためらわれるものです。 こういった状況から気軽にローカルで試すためのテストデータを作成することのハードルがかなり高いです。 バッチ処理を複数に分けていること リトライしやすさを優先して、CSV取得・ETL変換・計算処理・CSVエクスポート・FTP送信・ファイル送信履歴更新とバッチを6つに分けています。 途中まで処理したファイルは都度S3に設置する形を取っています。 初見だと「どの順番でどの環境変数で動かせばいいんだっけ？」と混乱しやすいです。 一度ローカルで一通り実行してみるのがいちばん早いのですが、その「一度通す」までのお膳立てが意外に重い、というのが課題でした。 工夫1: テストデータ作成用コマンドを実装 JSONからテストデータを生成するmakeコマンドを用意しました。 make gen-testdata CONFIG=test_20260507.json { " a ": " 2026-05-07 ", " b ": [ { " c ": " TEST_001 ", " d ": [ { " e ": 1 , " f ": " 10:30:00 ", " g ": [ { " h ": 1 , " i ": 2 , " j ": 500 } ] } ] } ] } JSONを差し替えるだけでさまざまなテストケースを切り替えられます。 本物のCSVに触らずにテストできるようになり、テストデータ作成のハードルがだいぶ下がりました。 実際に使用するときは人間がJSONを用意するのではなく、Claude Codeに「こういうテストケースのデータを作って」と指示を出すとこちらのコマンドが使われる形になります。 工夫2: Claude Codeでオンボーディングスキルを作成 スキルのディレクトリ .claude/skills/onboarding/ ├── SKILL.md ├── references/ │ ├── architecture.md │ └── batch-pipeline.md └── scripts/ ├── check_env.sh └── check_step.sh SKILL.md がスキル本体で、 references/ 以下にアーキテクチャ説明やパイプラインの全体像を、 scripts/ 以下に通過判定用のスクリプトを置いています。 大まかな内容 Phase 1: 環境チェック Docker / docker compose / make / コンテナの起動・healthy 状態をスクリプトで判定する Phase 2: アーキテクチャ説明 + 動作確認 references/ 以下のドキュメントで全体像を伝えてから、6本のバッチを1本ずつ手で動かしてもらう こだわったポイント 実際に手で動かせるようにする 私はどうしてもコードを読むだけでは理解できないと感じることが多いので、ローカル環境で立ち上げて一通り動作させることにこだわりました 表示されたコマンドをコピーして、別タブのターミナルで実行して進める形にしました 通過判定をスクリプトで行う 最初は「ステップごとに Claude Code がユーザーに確認して、その回答を信じて進める」くらいの素朴な作りで考えていました 実際にはまだ前のステップが完了していない (例: DB初期化を忘れている) のに気づかず進んでしまい、後段でエラーになってからようやく手戻りが発生する、ということが起こりました おわりに 新メンバーが触れたときに迷子になりがちな部分を、テストデータ作成コマンドとオンボーディングスキルでだいぶ楽にできた手応えがあります。 特にスキル側では、ステップごとの通過判定をスクリプトに寄せたことで、Claude Codeが「分かったつもり」で先に進んでしまう問題を防げました。 同じように複雑なシステムの動作確認に悩まれている方の参考になれば嬉しいです。