Skip to main content

3つの競合戦略でチェックアウトのレイテンシを改善する

遅いチェックアウトAPIに対して3つのDevinセッションを並列に競わせます — それぞれ異なる最適化に取り組み、最良のアプローチを本番に反映します。
AuthorCognition
CategoryDevin 最適化
Features高度
1

課題と成功基準を定義する

あなたの checkout API（POST /api/checkout）は p99 レイテンシが 1.8 秒で、ユーザーはカートを放棄しており、SLA 目標は 400ms です。これを改善するための有効な手段はいくつかあります。キャッシュ、クエリ最適化、非同期処理、コネクションプーリングなどです。ですが、実際に試してみるまでどれが最適かわからず、順番に試していくと、結果が出るまでに数日かかってしまいます。そこで、Advanced Devin を使って 3 つのセッションを並列に起動し、それぞれに異なる戦略を試させます。3 つすべてが完了したら、Advanced Devin が結果を比較し、最も優れたアプローチを採用してリリースするか、それぞれの最良の部分を組み合わせて 1 つの PR にまとめます。始めるには、Devin homepage のエージェントピッカーから Advanced を選択し、Start Batch Sessions タブをクリックします。
2

各セッションがそれぞれ異なる修正内容に向かうように誘導するプロンプトを作成してください

3 つのセッションを実行する価値は、それぞれが本当に異なるアプローチを探索できているかどうかにかかっています。発散を促すようにプロンプトを書き、具体的な戦略を提案しつつ、「best（最良）」の意味を定義して、結果を直接比較できるようにしましょう。良いマルチストラテジープロンプトを書くためのヒント:
  • 「best」を順位付きの評価基準で定義する。 レイテンシ、エラー率、複雑さ、一貫性といった比較軸を列挙することで、Devin が単純に速度だけを優先することを防げます。
  • 具体的な戦略を提案する。 「キャッシュ、クエリ書き換え、非同期処理」などの選択肢を示すことで、それぞれのセッションを異なる方向性に誘導できます。
  • ベンチマーク用コマンドを含める。 各セッションが自分の結果を測定するための再現可能な方法が必要です — npm run bench、k6 run load-test.js、または簡単な curl ループなど。
  • コードへのパスを示す。 src/routes/checkout.ts のようなファイルパスを指定することで、3 つのセッションすべてが同じ地点から開始できます。
3

結果を比較して勝者を決定する

3つのセッションがすべて完了すると、Advanced Devin があなたの基準に照らして成果物を並べてレビューします。使用した戦略、ベンチマークの数値、トレードオフなどを比較し、最も優れたものを選ぶか、それらを統合して最終的な PR にまとめます。チェックアウトのレイテンシ問題についての比較結果は、次のとおりです。
セッション 1 — Redis レスポンスキャッシュ
  戦略:       シリアライズされたカート＋在庫ルックアップを Redis に
              TTL 30s でキャッシュし、繰り返しリクエストの DB をバイパス
  p99:        1.8s -> 320ms  (合格 — 82% 削減)
  エラー:     変化なし
  複雑度:     +1 依存関係 (ioredis)、新規ファイル 2 件
  トレードオフ: 最大 30s 間、在庫データが古くなる可能性あり；Redis メモリ 40MB

セッション 2 — クエリ最適化＋コネクションプーリング
  戦略:       N+1 クエリを単一の JOIN に置き換え、PgBouncer
              コネクションプール (25 接続) を追加
  p99:        1.8s -> 580ms  (不合格 — 400ms を依然超過)
  エラー:     変化なし
  複雑度:     新規依存関係なし、クエリがよりシンプルに
  トレードオフ: 特になし — DB 負荷が全体的に低下

セッション 3 — 非同期注文処理
  戦略:       決済処理とメールをバックグラウンドキュー (BullMQ) に移動し、
              在庫確認後すぐに 202 を返す
  p99:        1.8s -> 190ms  (合格 — 89% 削減)
  エラー:     変化なし
  複雑度:     +1 依存関係 (bullmq)、新規ファイル 3 件、webhook ハンドラー
  トレードオフ: チェックアウトが結果整合性になる；決済確認用の webhook が必要

判定: セッション 1 と 3 はいずれも 400ms 目標を達成。セッション 2 の
クエリ修正は有効だが、単独では不十分。

最終 PR: セッション 2 のクエリ最適化 (コストなし、純粋な改善) と
セッション 3 の非同期処理を組み合わせ。決済＋メールをキューに移動し、
N+1 クエリを修正。最終 p99: 150ms。PR #412 オープン済み。
Advanced Devin が統合版の PR を作成する前に、各セッションごとの PR を個別にレビューできます。どちらか一方のアプローチだけを取りたい場合は、Devin に「Session 3 のアプローチで進めて、統合はスキップして」と伝えてください。
4

1つの問題に対して3つの戦略を並行して試すタイミング

適しているケース — 複数の有効なアプローチが存在する場合:
  • キャッシュ、クエリチューニング、アーキテクチャ変更のいずれもが有効になりうるパフォーマンスボトルネック
  • 明確なトレードオフがあるアーキテクチャ上の意思決定（モノリスの分割、状態管理の再設計など）
  • データ量が多い問題に対するアルゴリズム選定（異なるインデックス方式、ランキング手法、ML アプローチなど）
適していないケース — 解決策が明らかな場合:
  • 根本原因が明確なバグ修正
  • 標準的な CRUD エンドポイントの追加
  • 依存関係や設定ファイルの更新
このパターンは、単一セッションの 3 倍の ACU を使用します。本来であれば数日かけてアプローチを順番に試すような問題に限定して使ってください。単純なタスクであれば、単一の Devin セッションの方が速く、かつコストも低くなります。advanced_mode を batch に設定することで、API 経由でバッチセッションを起動することもできます。これは、性能劣化に対して複数の修正案を自動的に競争させる CI パイプラインへの統合に便利です。提案に対してあなたの承認を待たずに Devin を完全自律的に実行したい場合は、bypass permissions フラグを有効にして、セッションが自動承認され継続実行されるようにします。