LLMOpsアーキテクチャパターン

ストーリー

田

田中VPoE

ツールの選定ができたら、次はそれらをどう組み合わせてアーキテクチャを設計するかだ。LLMOpsには典型的なアーキテクチャパターンがいくつかある

あなた

従来のマイクロサービスアーキテクチャとはどう違うんですか？

あ

田

田中VPoE

基本的な考え方は同じだが、LLM固有の要素が加わる。API Gatewayの役割が拡張されること、プロンプト管理が独立したコンポーネントになること、そして品質評価のフィードバックループが組み込まれることが大きな違いだ

LLMOpsリファレンスアーキテクチャ

全体構成

LLMOps リファレンスアーキテクチャ:

┌──────────────────────────────────────────────────────────┐
│                    クライアント層                         │
│  Web App / Mobile / Slack Bot / API Consumer             │
└────────────────────────┬─────────────────────────────────┘
                         │
┌────────────────────────▼─────────────────────────────────┐
│                  AI Gateway 層                            │
│  認証・認可 | レート制限 | ルーティング | キャッシュ        │
│  フォールバック | ロードバランス | コスト追跡              │
└────────┬───────────────┬──────────────┬──────────────────┘
         │               │              │
┌────────▼───┐  ┌────────▼───┐  ┌──────▼─────────┐
│ LLM Provider│  │ LLM Provider│  │ Self-hosted    │
│ (OpenAI)    │  │ (Anthropic) │  │ Model (vLLM)   │
└─────────────┘  └─────────────┘  └────────────────┘
         │               │              │
┌────────▼───────────────▼──────────────▼──────────────────┐
│                オブザーバビリティ層                        │
│  ログ収集 | トレーシング | メトリクス | アラート            │
└────────────────────────┬─────────────────────────────────┘
                         │
┌────────────────────────▼─────────────────────────────────┐
│                  評価・改善層                              │
│  品質評価 | ドリフト検出 | A/Bテスト | フィードバック収集   │
└──────────────────────────────────────────────────────────┘

パターン1: 中央集権型 AI Gateway

すべてのLLMリクエストを単一のAI Gatewayに集約するパターンです。

項目	内容
概要	全サービスが共通のAI Gatewayを経由してLLMにアクセス
メリット	コスト一元管理、ポリシー統一、運用の集約
デメリット	単一障害点リスク、チーム間の調整コスト
適した組織	中小規模、LLM利用サービスが5つ以下

パターン1: 中央集権型

Service A ──┐
Service B ──┼──→ AI Gateway ──→ LLM Providers
Service C ──┘        │
                     ▼
              共通モニタリング
              共通コスト管理
              共通ポリシー

設計のポイント

ポイント	説明
高可用性設計	Gatewayは単一障害点になるため、マルチAZ・オートスケーリング必須
テナント分離	サービスごとにAPIキー・クォータ・レート制限を分離
優先度制御	ビジネスクリティカルなサービスにリソースを優先配分

パターン2: サイドカー型

各サービスにLLMOps機能をサイドカーとして注入するパターンです。

項目	内容
概要	各サービスにLLMOpsプロキシをサイドカーとしてデプロイ
メリット	サービスごとの独立性、チーム自律性、障害分離
デメリット	設定の一貫性担保が難しい、全体のコスト把握に工夫が必要
適した組織	大規模、マイクロサービス文化、チーム自律性重視

パターン2: サイドカー型

┌─────────────────┐  ┌─────────────────┐
│ Service A       │  │ Service B       │
│ ┌─────────────┐ │  │ ┌─────────────┐ │
│ │ LLMOps      │ │  │ │ LLMOps      │ │
│ │ Sidecar     │─┼──┼─│ Sidecar     │─┼──→ LLM Providers
│ └─────────────┘ │  │ └─────────────┘ │
└────────┬────────┘  └────────┬────────┘
         │                    │
         ▼                    ▼
    集中ログ収集 ←────→ 集中ログ収集

パターン3: ハイブリッド型（推奨）

中央集権型とサイドカー型を組み合わせた実用的なパターンです。

項目	内容
概要	共通機能はAI Gatewayに集約し、サービス固有の機能はサービス側で管理
メリット	共通ポリシーの一貫性とチーム自律性の両立
デメリット	アーキテクチャの複雑性
適した組織	中〜大規模、段階的にLLMOps基盤を成熟させたい組織

パターン3: ハイブリッド型

                    ┌──────────────────────┐
                    │    AI Gateway        │
                    │  (共通機能)           │
                    │  - 認証・認可         │
                    │  - レート制限         │
                    │  - コスト追跡         │
                    │  - フォールバック     │
                    └──────────┬───────────┘
                               │
              ┌────────────────┼────────────────┐
              │                │                │
    ┌─────────▼──────┐ ┌──────▼────────┐ ┌─────▼──────────┐
    │ CS-AI Service  │ │ FAQ Bot       │ │ Code Review AI │
    │ ┌────────────┐ │ │ ┌──────────┐  │ │ ┌────────────┐ │
    │ │プロンプト   │ │ │ │RAG管理   │  │ │ │品質ルール  │ │
    │ │管理        │ │ │ │          │  │ │ │管理        │ │
    │ └────────────┘ │ │ └──────────┘  │ │ └────────────┘ │
    └────────────────┘ └──────────────┘ └────────────────┘

Gateway層とサービス層の責務分離

責務	AI Gateway（共通）	サービス層（個別）
認証・認可	統一的なAPIキー管理	サービス固有の権限チェック
レート制限	グローバルなレート制限	サービス固有の制限
コスト管理	全体のコスト追跡・予算管理	サービス別のコスト配分
フォールバック	プロバイダ障害時の自動切替	ビジネスロジック依存のフォールバック
プロンプト管理	—	サービスごとに管理
品質評価	共通メトリクス収集	ドメイン固有の品質基準

非同期処理パターン

LLMの応答は時間がかかるため、非同期処理パターンも重要です。

パターン	説明	適した場面
同期リクエスト	クライアントがLLM応答を待機	チャットUI、リアルタイム応答
ストリーミング	SSE/WebSocketで段階的に応答	チャットUI、長文生成
ジョブキュー	リクエストをキューに入れ非同期処理	バッチ処理、レポート生成
イベント駆動	LLM処理結果をイベントとして発行	ワークフロー、パイプライン

非同期ジョブキューパターン:

Client ──→ API ──→ Queue ──→ Worker ──→ LLM Provider
  │                           │
  │         Job ID            │  結果を保存
  │ ←─────────────            │
  │                           ▼
  │                      Result Store
  │         結果取得          │
  │ ──────────────────────→   │
  │ ←─────────────────────    │

障害対応パターン

サーキットブレーカー

状態	動作
Closed	正常にリクエストを転送。エラー率を監視
Open	一定のエラー率を超えたら即座にフォールバックに切替
Half-Open	一定時間後に少量のリクエストを試行し、復旧を確認

フォールバック戦略

フォールバックチェーン:

1. Primary: GPT-4o (高品質)
   │ 失敗 or タイムアウト
   ▼
2. Secondary: Claude 3.5 Sonnet (代替)
   │ 失敗 or タイムアウト
   ▼
3. Tertiary: GPT-4o-mini (軽量モデル)
   │ 失敗 or タイムアウト
   ▼
4. Degraded: キャッシュ応答 or 定型応答
   │ 失敗
   ▼
5. Error: エラーメッセージを返却

まとめ

ポイント	内容
3つのパターン	中央集権型、サイドカー型、ハイブリッド型から組織規模に応じて選択
ハイブリッド推奨	共通機能はGateway、個別機能はサービス側で管理する責務分離が実用的
非同期処理	LLMの応答遅延を考慮し、ストリーミングやジョブキューを使い分ける
障害対応	サーキットブレーカーとフォールバックチェーンで可用性を確保する

チェックリスト

3つのアーキテクチャパターンの違いを説明できる
ハイブリッド型のGateway層とサービス層の責務分離を理解した
非同期処理パターンの使い分けを把握した
サーキットブレーカーとフォールバック戦略を理解した

推定読了時間: 30分