境界を優先した LLM プロダクト基盤 LAPIS 〜 運用と評価をプラットフォームに引き取り、プロダクトチームにドメインを託す 〜
概要
生成 AI 機能を各プロダクトが独立開発する段階では、ログ/トレース、レート制限、冪等性、コスト管理、出力品質の評価までチームごとに再実装されます。それはプラットフォームエンジニアリングが引き取るべき問題です。 ログラスでは LLM プロダクト基盤「LAPIS」を能力単位に分けた6サービス構成として構築しました。 ・LLM Gateway: 認証・テナント × プロダクト単位の予算ベースレート制限・冪等性 ・コンテキスト管理: テナント or 個人単位のコンテキスト管理・配信 ・同期 Agent: HITL + SSE 対応の実行基盤 ・非同期 Agent: 自律実行型の実行基盤 ・外部接続ツール: 各種 MCP Server ・評価基盤: Agent 出力の品質評価 境界設計はコード共有よりサービス境界を優先し、重複を許容して独立進化と障害分離を確保。サービス分割の判断基準を実例を踏まえて紹介します。 そして、その分割を支えるのが LLM オブザーバビリティです。インフラ観測は OTel+Datadog、顧客データを含むプロンプト/レスポンスは Langfuse のみに記録する2層構造とし、送信先を「データの国内所在」の法務基準で明文化。Gateway が全リクエストを自動計装するため、プロダクトチームは基盤に接続するだけで観測と評価の入口を得て、託されたドメインとプロンプト設計に集中できます。 またAgent ワークロードでは1会話内で LLM 呼び出しとツール実行が多発し、素朴な計装では会話が分断されます。会話 ID を OTel Baggage で伝搬し Langfuse Session に対応付ける「会話単位の観測」を、Agent SDK 越しのヘッダ注入の工夫と共に解説します。 LLM の非決定論的な振る舞いを扱っても、プラットフォームエンジニアリングの原則は変わりません。分散システム運用の延長線上に堅牢な LLM プロダクト基盤は築ける — そのための実装知を、以下の切り口で持ち帰って頂ければと思います。 ・能力単位のサービス境界と共有/重複の判断基準 ・インフラ観測と LLM 観測を分ける2層オブザーバビリティ ・OTel Baggage + Agent SDK による会話単位トレース
LLM o11yMicroservicesLLM GWAgentOpenTelemetryDatadogLangfuseOTel BaggageMCPContext Management
スピーカー
株式会社ログラス エンジニア (LLM Architect)。12 年の SIer キャリア(基幹システム / マイクロサービス / ML) で身につけたenterprise品質を大事に、経営管理 SaaS を支える社内 LLM プロダクト基盤「LAPIS」の設計・実装を担当。技術を事業に繋げることを軸に、複数プロダクトを支える LLM プラットフォームの境界設計と運用に取り組んでいます。