AIエージェントのスケーリング、PoCから本番環境へどう進める？

ミドリ： タツヤさん、PoCで動いてたAIエージェントを本番環境に出したら、急にパフォーマンスが落ちたって話をよく聞くんですけど……。

タツヤ： あるあるだね。McKinseyの調査によると、AIプロジェクトの約74%がPoCから本番環境への移行段階でスケーリングに失敗してる。

ミドリ(surprised)： 74%！ そんなに多いんですか。

タツヤ： PoCでは数十件のリクエストを処理するだけで十分だけど、本番環境では数百〜数千の同時リクエストを安定処理しながら、レスポンスタイムを一定に保って、コストも管理しないといけない。まったく別の世界なんだよ。

スケーリングで直面する4つの壁

ミドリ(thinking)： 具体的にどんな問題が起きるんですか？

タツヤ： 大きく4つある。

1. レイテンシの増大

タツヤ： LLM（大規模言語モデル）へのAPI呼び出しは、通常のデータベースクエリと比べて桁違いに時間がかかる。1回のリクエストで複数回のLLM呼び出しが発生するマルチステップエージェントだと、レイテンシ（応答遅延）が数秒から数十秒になることも珍しくない。同時リクエストが増えるとAPIのレート制限にぶつかって、さらに遅くなる。

2. コストの非線形的増加

ミドリ： コストも比例して増えるんですか？

タツヤ： 比例どころか、非線形に増えることがある。LLM APIの課金はトークン数ベースだから、リクエスト数に比例する部分もあるんだけど、マルチエージェント構成だとエージェント間の通信にもトークンが消費される。スケール前に月額10万円だったAPI費用が、10倍のトラフィックで月額200万円になるケースも報告されてるよ。

ミドリ： 10倍じゃなくて20倍に……。

3. 品質の劣化

タツヤ： 負荷が増えると、タイムアウトやリトライが発生して、コンテキスト情報の欠落やエラーハンドリングの不備が品質劣化を引き起こす。キャッシュやバッチ処理で最適化したはずが、個別のリクエストの応答品質が下がるケースもある。

4. 運用の複雑化

タツヤ： コンポーネント数が増えると、デプロイ、監視、トラブルシューティングの難易度が急上昇する。どこがボトルネックなのか特定するだけでも、十分な可観測性（オブザーバビリティ）の基盤がなければ困難だよ。

ミドリ： PoCとは次元が違う問題ばかりですね。じゃあどうすればいいんですか？

3段階アプローチで攻略する

タツヤ： 一度に大規模化するのは絶対NG。段階的にスケールさせるのが成功の鍵だよ。3段階で説明しよう。

第1段階：垂直スケーリング（スケールアップ）

タツヤ(nodding)： まずは単一インスタンスの処理能力を最大限に引き出す。アーキテクチャを変えずにできるから、最も少ない労力で効果がある。

ミドリ(thinking)： 具体的に何をするんですか？

タツヤ： 4つの施策がある。

ミドリ： これだけでどれくらい改善するんですか？

タツヤ： この段階だけでスループット（単位時間あたりの処理件数）を2〜3倍に改善できるケースが多い。コスパ最高だよ。

第2段階：水平スケーリング（スケールアウト）

ミドリ(confused)： それでも足りなくなったら？

タツヤ： 複数のインスタンスに負荷を分散させる。いくつかのパターンがある。

ロードバランサー + 複数ワーカー構成：

最もシンプルなパターン。ロードバランサーがリクエストを複数のエージェントインスタンスに振り分ける。

ミドリ： すぐにレスポンスが要らないタスクはどうするんですか？

タツヤ(nodding)： いい質問。メッセージキューを使う。RabbitMQやAmazon SQSでリクエストをキューに入れて、ワーカーが順次処理する方式。レポート生成や大量データ分析に向いてる。ピーク時でもリクエストの取りこぼしを防げるのがメリット。

タツヤ： さらにオートスケーリング。トラフィック量に応じてインスタンス数を自動的に増減させる。AWS Auto Scaling、Google Cloud Run、Kubernetes HPAなどを使う。

第3段階：マルチエージェントアーキテクチャ

ミドリ： 最終段階は？

タツヤ(thinking)： 処理の複雑性が増して、単一エージェントではカバーしきれなくなったら、複数の専門エージェントを連携させるアーキテクチャに移行する。3つの設計パターンがある。

オーケストレーター型： 中央の指揮者エージェントがリクエストを分析して、専門エージェントにタスクを振り分ける。

パイプライン型： エージェントが直列に連結されて、前段の出力が次段の入力になる。

イベント駆動型： エージェント間がイベントで疎結合に連携。

キャッシング戦略 ── 3つのレベル

ミドリ： さっきキャッシングの話がありましたけど、もうちょっと詳しく知りたいです。

タツヤ： キャッシングはスケーリングにおいて最も費用対効果が高い施策の一つ。3レベルで実装するのがおすすめだよ。

レベル1：完全一致キャッシュ

タツヤ： 入力が完全に一致するリクエストにキャッシュ済みの応答を返す。FAQやテンプレート応答など、同じ質問が繰り返されるユースケースに有効。

レベル2：セマンティックキャッシュ

タツヤ： 入力テキストのエンベディング（意味的な数値表現）を比較して、意味的に類似したリクエストにもキャッシュを適用する。「送料はいくらですか」と「配送料を教えてください」みたいな表現違いにも対応できる。

ミドリ： 同じ質問を別の言い方で聞いても、キャッシュが効くんですね。

タツヤ： ただし類似度の閾値は0.95以上を推奨。低すぎると誤ったキャッシュヒットが発生する。エンベディングモデルの計算コストはLLM呼び出しの1/100以下だから、十分ペイするよ。

レベル3：パーシャルキャッシュ

タツヤ： マルチステップ処理の中間結果をキャッシュする。たとえばRAGパイプラインの検索結果をキャッシュして、LLMの生成部分だけを毎回実行する、というやり方。

パフォーマンス目標を数値で定義する

ミドリ： スケーリングの目標ってどう設定するんですか？

タツヤ： SLI（サービスレベル指標）を定義して、SLO（サービスレベル目標）として数値化する。こんな感じ。

指標目標値（SLO）測定方法
レスポンスタイム（P95）5秒以内アプリケーションログ
可用性99.9%（月間ダウンタイム約43分以内）ヘルスチェックエンドポイント
エラー率1%未満エラーログ集計
スループット100 RPS（リクエスト/秒）ロードバランサーメトリクス
キャッシュヒット率40%以上キャッシュサーバーメトリクス

ミドリ(thinking)： P95って何ですか？

タツヤ： リクエストの95%がこの時間以内に完了するということ。平均値だと外れ値に引きずられるから、P95の方が実際のユーザー体験を正確に反映する指標なんだ。

やってはいけない3つのアンチパターン

ミドリ： 逆に「これはやるな」っていうのはありますか？

タツヤ： 3つある。覚えておいて。

アンチパターン1：早すぎる最適化

タツヤ(thinking)： 十分なトラフィックデータがない段階で複雑なアーキテクチャを構築すると、実際のボトルネックとは違う場所を最適化してしまう。まずは垂直スケーリングで対応して、データに基づいて判断しよう。

アンチパターン2：モノリシックなマルチエージェント

タツヤ： 複数エージェントを導入したのに密結合で独立スケーリングができない状態。各エージェントは独立してデプロイ・スケール可能な設計にすること。

アンチパターン3：キャッシュの無効化を怠る

タツヤ： 古いキャッシュが返され続けて、最新の情報が反映されない問題。TTL（有効期限）を適切に設定して、データ更新時にキャッシュを明示的に無効化する仕組みを入れておくこと。

ミドリ： キャッシュは入れっぱなしじゃダメなんですね。

まとめ：段階的に攻める

ミドリ： 今日の話をまとめるとどうなりますか？

タツヤ： AIエージェントのスケーリングは、一度に大規模化するんじゃなくて段階的に進めるのが鉄則。

ミドリ： まずは第1段階から試してみます！

タツヤ(thinking)： そうそう。第1段階だけで2〜3倍になるケースが多いから、焦って複雑なアーキテクチャに手を出す前にまずそこから。データを見てから次のステップを判断しよう。

次のアクション

現在のAIエージェントのパフォーマンスを測定し、上記のSLI/SLOと比較してみてください。最もギャップが大きい指標に対して、第1段階の施策から着手することをお勧めします。

Shimanto AI Solutionsでは、AIエージェントのパフォーマンス診断とスケーリング設計の支援を行っています。PoCから本番移行でお悩みの方は、お気軽にご相談ください。段階的なスケーリングロードマップを一緒に策定いたします。