# AIエージェントをソフトウェアに組み込むプラクティス # Short DB Transaction, Long Agent Session｜長セッション・短トランザクション 🎯 LLMの推論中にDBトランザクションを開いたままにしていませんか？数秒〜数十分の待機でコネクションプールが枯渇し、システム全体が止まります。 🔥 解決する課題 従来のWebアプリではリクエスト処理がミリ秒で完結するため、トランザクション=リクエストスコープで問題ありませんでした。しかしAIエージェントのLLM呼び出しは数秒〜数十分に及びます。その間トランザクションを開いたままにすると、コネクションプール枯渇・デッドロック・ロック競合・トランザクションタイムアウトが同時多発します。P99レイテンシがP50の数倍になることもあり、「平均的には問題ない」設計でもテール側で障害が発生します。 💡 提案パターン LLM推論の間はトランザクションもコネクションも保持しません。DB読取を短トランザクションで行いコミット・コネクション返却した後にLLMを呼び出し、推論結果を再び短い独立トランザクションで書き込みます。ステップ間の中間状態は外部ステートストア（Redis、DynamoDB等）に永続化し、クラッシュ後の再開を可能にします。楽観的ロック（versionカラム等）でLLM推論中のデータ競合に対処し、悲観的ロックの長時間保持は避けます。 ✅ 選定条件 使うとき： - エージェントがLLM呼び出しの前後でDB読み書きを行う - LLM呼び出し1回あたりの所要時間が概ね1秒を超える - 同時セッション数がコネクションプールサイズの半分に達しうる 使わないとき： - LLMを使わない従来のCRUD処理 - 単一トランザクションでアトミックに完結しなければならない操作（銀行間送金等） ⚠️ 落とし穴 - 読取と書込の間に他プロセスが同じ行を更新する可能性があります。楽観的ロックを必ず併用してください - コネクションプールサイズは「同時セッション数」ではなく「同時トランザクション実行中のステップ数」で計算します。本パターンにより同時セッション数の10-20%で運用可能です - 不可逆な操作を含むセッションでは、ステートストアにディスク永続化を持つストアを選んでください 🔧 実装方針 - DB読取→コミット→コネクション返却→LLM呼び出し→再取得→結果書込の順で、LLM推論中はトランザクションもコネクションも保持しません - 楽観的ロック（versionカラムやupdated_at）を書込トランザクションに含め、LLM推論中のデータ競合をリトライで解決します - ステップ間の中間状態は外部ステートストア（Redis、DynamoDB、RDB上のセッションテーブル等）に永続化し、クラッシュ後の再開を可能にします - コネクションプールサイズは同時セッション数ではなく同時トランザクション実行中のステップ数で設計します（概ね同時セッション数の10-20%） - 不可逆性が高いセッションではディスク永続化を持つステートストアを選定し、耐久性要件に合わせます #AIエージェント# #ソフトウェアアーキテクチャ#