AIを業務へ組み込むとき、「関連する情報を探せる」段階と「その情報を使って処理を確定できる」段階の間には、設計上の隔たりがあります。商品を勧めるだけなら十分な検索でも、注文や返金まで任せるなら、別の条件が必要になります。

2026年9月27日公開のVibhor Kumarの「What “AI-Ready” Actually Means」は、AI-readyを、データ・権限・結果・証跡の統制を維持しながらAIを導入できる状態として捉えています。これは著者が示す設計上の考え方です。

では、PostgreSQLを使うアプリケーションでは、何を用意すればその状態へ近づけるのでしょうか。検索から権限判定、データ更新、外部サービスの処理完了までをたどると、AIへ任せる判断とシステムで保証する条件を分けて考えられます。

商品検索では「似ている」と「購入できる」を分ける

たとえば、「旅行向けの軽い防水ジャケット」を探す場面を考えます。ベクトル検索は言葉の意味に近い商品を探せますが、在庫、価格上限、配送地域といった販売条件も満たす必要があります。Kumarが示すのは、意味による候補選びと、SQLによる業務条件の適用を組み合わせる設計です。

この分担を決めるには、価格や在庫の正本となるシステムを先に定めます。説明文の検索用コピーがあっても、注文を受け付ける判断に使う在庫まで同じ鮮度とは限りません。「何を検索するか」に加えて、「どの時点の、どの情報で確定するか」が必要ですね。

実装にも注意点があります。pgvectorのHNSWなどの近似インデックスでは、走査した候補へ後からフィルターを適用するため、条件が厳しいと要求件数より結果が少なくなります。pgvector公式READMEのフィルタリング解説が説明する制約です。

pgvector 0.8.0で追加された反復インデックス走査は、追加の候補を探索する仕組みです。ただし、探索上限があり、指定件数を必ず返す保証ではありません。strict_orderが保証するのも返却結果の距離順であり、近似検索が完全な検索へ変わるわけではありません。走査と順序の仕様を踏まえ、導入時には応答時間と条件適用後の件数を一緒に測るとよいでしょう。

検索できる行と実行してよい操作を別々に制御する

購入候補を絞れても、その利用者が他人の注文を参照したり変更したりできてよいわけではありません。検索条件が業務上正しいことと、実行者に権限があることは別の問題です。

PostgreSQLの行レベルセキュリティ（RLS）は、参照・変更できる行をポリシーで制限します。有効化したテーブルにポリシーがなければ通常アクセスは拒否されますが、スーパーユーザーやBYPASSRLSを持つロールは制限を回避し、テーブル所有者も通常は対象外です。PostgreSQL 18のRLS仕様に従い、検証は実際のアプリケーション用ロールで行う必要があります。

たとえば返金処理なら、注文へのアクセスに加えて、依頼者の本人性、対象注文との関係、委譲された返金上限を実行経路で検証する設計が考えられます。モデルが渡した利用者IDやエージェントIDだけを、権限の証明として扱わないことがポイントです。

返金の重複は、リクエストIDと注文状態の両方で防ぐ

権限がある処理でも、再送や同時実行は起こり得ます。Kumarの返金例は、冪等性キーの重複検出、注文行のロック、上限判定を組み合わせています。冪等性とは、同じ処理を繰り返し要求しても、業務上の効果が重複しない性質です。

SELECT ... FOR UPDATEは対象行をロックし、トランザクション終了まで競合する更新などを待機させます。ただし、待機後に処理を続けてよいかは業務条件で判定します。ロック自体が「返金済みなら拒否する」という規則を作るわけではありません。PostgreSQL 18の行ロック仕様が保証する範囲を区別したいところです。

ここからは掲載コードを読んだうえでの実装上の検討です。同じ冪等性キーの再送は抑止できますが、別のキーなら処理へ進みます。また、例には返金済み状態や累積返金額の検査がありません。そのまま本番用の返金処理にするのではなく、ロック取得後の状態に対して、残額、金額が正であること、同じキーと要求内容の対応などを検証する必要があります。

テストも「同じキーを2回送る」だけでは足りません。「同じ注文へ別々のキーで同時に要求する」を加えると、通信の再送対策と業務上の二重処理対策を分けて確かめられます。これは実測結果ではなく、設計から導ける検証項目です。

Outboxは更新と送信予定をそろえ、外部の完了は別に追う

返金を受け付けるには、注文の更新に加えて決済サービスへの依頼も必要です。DB更新と外部API呼び出しを別々に行うと、一方だけ成功する場面を扱わなければなりません。

Transactional Outboxでは、業務データの変更と送信予定イベントを同じDBトランザクションへ書き込みます。別のワーカーがコミット済みイベントを配送することで、更新と送信予定の不整合を避けます。この仕組みと重複配送への注意は、AWSのTransactional outbox pattern解説でも確認できます。

ここで確定するのは、DB内の変更とイベントの存在です。外部決済の完了まで同じトランザクションで保証するわけではありません。配送先が処理を終えた直後に応答が失われる可能性もあるため、外部側の冪等性や結果照合を含めた設計が必要になります。

返金であれば「依頼を受け付けた」と「決済サービスで返金が完了した」を別の状態として扱う設計が適しています。原文の例ではDB上の状態をrefundedへ更新しますが、それだけを外部決済の完了証拠にはできません。運用では未配送イベントの滞留時間、再試行数、完了結果との不一致を追う、という監視項目が考えられます。

AIの導入判断を、業務が完了する条件へ落とし込む

ここまでの分担を、ひとつの業務フローへ当てはめます。次の表は、商品検索から返金までを想定した設計レビューの例です。

場面	確かめたい条件	条件を守る場所
商品を探す	意味が近く、販売条件を満たす	ベクトル検索とSQL
注文を扱う	実行者が対象へアクセスでき、操作権限も持つ	認証・認可とRLS
返金を受け付ける	再送・同時実行でも業務条件が崩れない	状態検証、行ロック、冪等性管理
決済結果を確定する	外部処理の結果を追跡し、再送にも対応できる	Outbox配送、外部側の冪等性、結果照合

最初から全社のデータをひとつに集める必要はありません。まず一つの業務を選び、正本となる情報、許可する操作、失敗時の再開方法、権限を取り消す方法を具体化する進め方ができます。Kumarの主張を実務へ移すなら、この単位で導入可否を判断すると整理しやすくなります。

評価にも、回答件数だけでなく、業務完了までの時間、人の手直し、復旧の回数、完了した処理あたりの費用を含めたいところです。いずれも一律の合格値があるという意味ではなく、その業務で改善したい結果に合わせて選ぶ指標です。

AI-readyかどうかは、検索機能を備えているだけでは判断できません。候補を見つけた後に、誰が、どの条件で状態を変え、その結果をどう確かめるかまで説明できること。その境界をシステム側に持たせる設計が、モデルを変えても業務の統制を保つ土台になります。

出典

• Title: Vibhor Kumar: What “AI-Ready” Actually Means
• URL: https://postgr.es/p/9vM