# AIエージェント開発の意思決定ポイント # 同期 vs 非同期 ⚡ 🎯 ポイント LLMエージェントの設計、最初に決めるべきは「同期で返すか、非同期にするか」です。 ここを間違えると、後からアーキテクチャ全体を作り直す羽目になります。従来のWeb APIなら「100msで返る」が前提でしたが、エージェントは数秒から数十分までレイテンシが振れます。この特性が、同期/非同期の選択を避けて通れない最初の分岐点にしています。 📋 概要 同期はクライアントがHTTPリクエストを送り、接続を維持したまま結果を受け取る方式です。状態はリクエストスコープで管理され、ジョブキューもチェックポイントストアも不要です。一方、非同期はジョブIDを即座に返し（HTTP 202）、バックグラウンドワーカーが処理を担当します。結果はポーリング・Webhook・SSE・WebSocketで通知されます。実行状態は外部ストアにチェックポイントとして永続化されます。 🔍 意思決定のポイント 判定の主軸は2つあります。 1️⃣ **レイテンシ予算** が最も重要な判定軸です。LLMのp99レイテンシがクライアントの待機許容を超えるかどうかで決まります。 - 対面で5〜10秒、API連携で30秒以内に収まる → 同期 - 上記を超える、または所要時間が読めない → 非同期 - 短い処理は成功するが長い処理は失敗する二峰性分布 → ハイブリッド 2️⃣ **リトライコストの大きさ** が副次的な判定軸です。 - 失敗時にフルリスタートで問題ない → 同期で十分 - 途中再開が必要、リスタートのコストが大きい → 非同期 人間の承認フローが途中に入る場合、同期の接続保持は非現実的で、非同期が必須になります。 💡 要点と詳細 🟢 **同期の強み**はシンプルさです。デバッグはスタックトレースで追え、テストは関数の入出力で検証でき、デプロイはステートレスHTTPとして扱えます。可動部品が少ないほどトラブルシューティングも容易です。テキスト分類、情報抽出、単純Q&A、要約、構造化出力生成など、LLM1回＋軽量ツール0〜2回で完結するタスクに最適です。 🟡 **非同期の強み**は耐久性とスケーラビリティです。処理時間に上限がなく、ワーカーが失敗しても最後のチェックポイントから再開できます。人間の承認待ち（数分〜数日）がワーカーを消費しません。水平スケールもキューワーカーの追加だけです。ただしSQS・Redis Streams・Temporalなどのジョブキュー、チェックポイントストア、結果ストア、通知メカニズムが必要で、分散トレーシングを含むデバッグの複雑性が代償です。 ⚖️ トレードオフ | 観点 | 同期 | 非同期 | |---|---|---| | インフラの複雑性 | 低い（HTTPのみ） | 高い（キュー＋ストア＋通知） | | デバッグ難度 | スタックトレースで完結 | 分散トレーシングが必須 | | 耐障害性 | クラッシュで全ロス | チェックポイントから再開可 | | スケール | 接続保持がボトルネック | ワーカー追加で水平拡張 | | 人間の承認 | 非現実的 | 自然に対応 | 🛠️ ユースケース 🔵 **同期が向くケース**: テキスト分類、情報抽出、単純Q&A、要約、構造化出力生成。数秒で確実に終わる処理。 🔴 **非同期が向くケース**: マルチツールチェーン、クロスSaaSプロセス、人間承認ワークフロー、30秒超のタスク。 🟣 **ハイブリッド**: 内部は非同期パイプラインで構成し、閾値以内なら同期レスポンス、超えたらジョブIDを返す自動切替。レイテンシが二峰性分布を示す場合に特に有効です。 📌 **デフォルト戦略**: 迷ったらまず同期から始めましょう。レイテンシが限界を超えた時点で非同期に移行する方が、逆方向より安全です。同期→非同期の移行は容易ですが、非同期→同期へのロールバックは不要なインフラを残します。 #AIエージェント# #ソフトウェアアーキテクチャ#