TL;DR 信頼できるエージェントAIは「良いモデルやプロンプト」ではなく、コンテキストとオーケストレーションのハーネスを明示設計することで生まれる――Bayer×Thoughtworksの製薬システムPRINCEの実装知です。🧪 タイトル: Building Reliable Agentic AI Systems URL: ポイント 🧭 逐次エージェント＋一時停止点：意図確認→Think&Plan→Researcher→Reflection→Writerの流れで段階的に検証 🔁 3種類の内省ループ：プロセス(軌道)・データ(証拠の十分性)・ドラフト(出力の完全性)で別々の失敗を捕捉 🔎 ハイブリッド検索：クエリ拡張n=5、意味0.7＋キーワード0.3の加重、bge-rerankerで約20→7件に再ランク 🗃️ 構造化はText-to-SQL：SELECTのみ許可、最大3回の自己修正、1クエリ50件以下に制限 🛟 ハーネス工学：PostgreSQL/DynamoDBで状態永続化、障害点から再開、プロバイダ自動フォールバック 📌 文単位の引用＋RAGASとLangfuseで評価。本番トラフィックも毎日バッチでハルシネーション検出 🏷️ NERで試験PDFから実体抽出、信頼度スコアで高信頼は自動更新・低信頼は人手レビューへ 「大きなコンテキスト窓でも選択性は要る」という割り切りが現場感あります。 #AIエージェント# #LLMOps#

# 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エージェント# #ソフトウェアアーキテクチャ#

AIエージェントをエンタープライズシステムに組み込むプラクティス 【非同期ジョブ＋負荷制御】 💡 「全部リアルタイム」は破綻する。長時間処理をジョブ化し、優先度キューで負荷を制御すれば、スパイクにも耐えるエージェント基盤が手に入ります。 🔥 解決する課題 - 数十秒〜数分のエージェント処理でHTTPタイムアウトが発生する - スパイク時に全ユーザーのレイテンシが悪化し、サービスが崩壊する - 低優先度のバッチ処理がリアルタイム対話の品質を巻き添えにする - LLM呼び出しコストがスパイク時に制御不能になる 🏗️ 提案パターン リクエスト受信時にジョブIDを即時返却し、処理をバックグラウンドキューに投入します。進捗はSSE/WebSocketでストリーム通知し、完了時にWebhookやSlackでコールバックします。優先度キューでリアルタイム対話を最優先にし、バックグラウンド処理は後回しにします。さらに「オンライン知性」と「オフラインバッチ知性」を分離し、夜間バッチで大型モデルによる重い分析を実行、日中はその結果を即座に参照する構成が効果的です。 ✅ 選定条件 - 向き：処理が数十秒超、大量並列処理、スパイクのあるマルチテナント環境 - 不向き：会話的・数秒で完結する対話（ジョブ化のオーバーヘッドが体験を損なう） ⚠️ 落とし穴 - DLQ（Dead Letter Queue）を用意しないと、失敗ジョブがサイレントに消える - オフラインバッチの結果鮮度を管理しないと、古い分析結果で誤った判断を招く - テナント別クォータを設けないと、特定テナントの暴走が全体に波及する 🛠️ 実装方針 1. メッセージキュー（SQS / RabbitMQ / Kafka）でジョブを受け付け、即座にジョブIDを返却するAPIを構築します 2. ワークフローエンジン（Temporal / AWS Step Functions）でジョブの進捗管理・リトライ・DLQを一元化します 3. 優先度キューでリアルタイム対話とバックグラウンド処理を分離し、テナント別クォータ（Token Bucket / Sliding Window）を設定します 4. SSE/WebSocketで進捗をストリーム通知し、完了時はWebhook/Slackコールバックで結果を届けます 5. 夜間バッチ（Airflow等）で大型モデルによる重い分析を実行し、結果ストア（Redis / DynamoDB）経由で日中のオンラインエージェントが即座に参照できるようにします #AIエージェント# #エンタープライズアーキテクチャ#