ツール紹介

• Datadog：SaaS型で手軽に始められ、可視化・トレース・アラートなど機能が豊富。多数のクラウド/ミドルウェアに対応。
• Langfuse：LLMアプリケーションのトレーシング・評価・コスト分析を統合的に支援。LangChainやOpenAIとの連携が容易。
• LangSmith：LLMアプリケーションに特化したトレース・評価・デバッグプラットフォーム。LangChain製。プロンプトのテストや評価指標の記録に強み。
• Prometheus：時系列データベースを使用してメトリクスを収集・保存し、高度なクエリ機能と柔軟なアラート機能を備えている。
  

主要なLLMOpsツールの比較表

4社のLLMOps実践事例のご紹介

Datadog/any株式会社

1.会社・事業のご説明
any株式会社は、「チームウィルで、一歩先の世の中へ」をビジョンとして掲げ、個人のノウハウを引き出し、組織全体のパフォーマンスを最大化するAIナレッジプラットフォーム「Qast」を開発しています。AIでエンタープライズ企業のナレッジマネジメントサイクル効率化にチャレンジしています。

2.Datadogを活用したLLMOpsのご紹介

アーキテクチャ図

3.アーキテクチャ設計の背景・意図

弊社プロダクトの「Qast」は、B2B SaaSのWebアプリケーションで、インフラ環境としてAWS上にて構築されています。バックエンドの複数のサービスがマイクロサービスとして、Fargate on ECSで構築されており、全体の処理のほとんどがマイクロサービス間通信で占められています。Qastの開発に関わるメンバーはすでに20名を超えており、こういった分散アプリケーションのObservabilityを高めることは、AIに限らず日常的な運用を効率化するうえでは急務でした。

なかでもQast AIの処理は、RAGにおけるEmbedding、Hybrid Searchなどの手法を取り入れており、精度検証やレイテンシなどを監視することが必要になります。Embeddingのような非同期系のタスクについては、AWS SQSを利用した同時実行制御やリトライ管理を行っており、サービスをまたいだ処理のためTraceabilityの確保が非常に重要でした。

◆なぜそのツールを選択したのか
以前はAWS標準のCloudWatchを中心とし、サーバの死活管理にかぎりMackerelを採用していました。しかしながら前述した背景を踏まえ、分散アプリケーションの監視において広く採用されているDatadogを導入することにしました。DatadogはLLM ObservabilityといったAI関連の機能も充実しており、今後の将来性も高いと判断しました。

◆実際にどのように運用をしているのか
非常に多くの機能を活用していますが、なかでもDatadog APMによるTracingとLoggingが強力です。例えば、Embedding処理においては、AWS SQSを経由したキューイングなど、複数のサービスをまたいで処理が行われます。DatadogのAPMによってどの箇所で処理が失敗したか、レイテンシが高くなったかを判断できます。またAIの精度検証については、現時点ではオフライン評価にとどまっており、モデル選定やプロンプトチューニングはLangSmithを利用して調整をしています。

◆ご執筆者のご情報

• お名前: 荒川聖悟
• 役職: テックリード
• X（旧Twitter）アカウント名: @adsholoko
  
  

Langfuse/KDDIアジャイル開発センター株式会社

1.会社・事業のご説明
KDDIアジャイル開発センター株式会社は、従業員規模101名〜300名のエンジニア組織を持つ企業です。私が所属するチームでは、法人営業組織向けのAIエージェントの開発に取り組んでいます。平日日勤帯に主に利用されるLLMアプリケーションを運用し、Amazon Bedrockを基盤モデルとして、LangChain + LangGraphとBoto3経由でのConverse API実装が混在する環境でサービスを提供しています。

2.Langfuseを活用したLLMOpsのご紹介

アーキテクチャ図

3.アーキテクチャ設計の背景・意図
弊社では、AIエージェント開発において複数の重要な課題に直面していました。まず、ユーザーの質問に対して期待する回答が得られない場合、その原因がプロンプトにあるのか、中間で呼び出されるツールの結果によるものなのかが判断できず、開発難易度が大幅に上がっていました。特にLLMを多段で呼び出すアプリケーションでは、中間処理の可視化が困難でした。また、運用上変更の多いプロンプトをソースコードから切り離して管理し、デプロイを伴わない迅速なデリバリーを実現する必要がありました。さらに、ユーザーフィードバックやドメインエキスパートによる評価をLLMの回答と紐づけて分析し、サービス機能ごとの生成コストを正確に算出する仕組みが不可欠でした。

◆なぜそのツールを選択したのか
Langfuse選定の最大の決め手はセルフホステッド運用が可能な点でした。LangSmithもセルフホステッド版がありますが、エンタープライズライセンスが必要であるのに対し、LangfuseはOSS版が利用できるため、セキュリティ要件を満たしながらコストメリットを享受できました。技術的な観点では、ObserveデコレーターをはじめとするLangfuse SDKの充実により、観測したい関数にデコレーターを付けるだけで比較的手軽に可視化を実装できる点も高く評価しました。LangChainやLangGraph専用のCallbackも提供されており、実装の簡便性が他ツールと比較して優れていました。

◆実際にどのように運用をしているのか
現在、開発チームではLangfuseをほぼ毎日活用し、新機能開発時のAIエージェントワークフロー構築やデバッグ、コスト分析に利用しています。プロダクトオーナーやステークホルダーは週次でLangfuseから集計された利用状況やコストデータを確認し、サービス機能のブラッシュアップや予算・プライシング検討に活用しています。また、CI/CDパイプラインと連携させることで、プロンプトの他環境デプロイ自動化、機能ごとの詳細な利用状況・コスト通知をSlackへ配信する仕組みを構築し、運用効率を大幅に向上させました。開発工数は導入前と比較して1/3〜2/3程度に削減されたと実感しています。

◆ご執筆者のご情報

• お名前: 伊野瀬出（いのせ いずる）
• 役職:25新卒ソフトウェアエンジニア
• 所属: KDDIアジャイル開発センター
• X（旧Twitter）アカウント名: @i_inose0304
  
  

LangSmith/ 株式会社Algomatic

1.会社・事業のご説明
Algomaticは生成AIを軸に複数の事業開発を行うテクノロジーカンパニーです。営業AIエージェント「アポドリ」や、採用AIエージェント「リクルタ」などのプロダクトを展開しています。さらに、AI Transformation(AX)事業では、各業界に特化した生成AIの業務適用とシステム開発を支援しています。

2.LangSmith活用の背景・意図
当社ではLangSmithを実業務システムではなく、PoC環境で活用しています。PoCでは仮説検証を高速に繰り返す必要があり、専用のオブザーバビリティツールを自前で作り込む余裕はありません。一方で実験・実証試験が増えるにつれ、どのプロンプト・どのモデル設定で精度が改善したかといった履歴管理が煩雑化していました。特に生成AIの特性上、複数回実行時に結果が変わることがあるということで結果を保存することの重要性が高まっていました。
こういった履歴管理が煩雑化している状況では、結果の比較検証が時間がかかり、効果的な改善施策の特定や迅速な意思決定に支障をきたしていました。そこでオブザーバビリティツールを導入することで、トレースや評価を標準化し、PoCの高速サイクルを維持しつつ実験成果を一元管理できる体制を整える必要がありました。

◆なぜそのツールを選択したのか
PoC環境でのオブザーバビリティツール選定にあたり、MLflow、Langfuse、LangSmithを比較検討しました。当時DifyでのPoCを実施しており、互換性があったLangfuseとLangSmithが最終候補となりました（現在はOpikとWeaveも対応）。両者を比較した結果、導入の簡単さからLangSmithを選定しました。LangSmithは特に当社が複数案件で活用していたLangChain・LangGraphとの親和性が高く、実行ステップごとの入出力を含む詳細なトレース情報を確認できます。またデータセットに対する評価結果を視覚的に確認できるダッシュボード機能により、複数の実験結果の比較や精度への影響を一覧性高く把握でき、PoC環境での高速な仮説検証に適していました。

◆実際にどのように運用をしているのか
運用面では設定に変更を加えたタイミングではGitHub Actionsを用いて自動でテストを回す機構を採用しています。また実証試験期間中は基本的に毎日トレースなどを確認しています。監視指標はカスタム評価を中心に設計し、質問への回答可否を判定するルールベース評価から、LLM as a Judgeによる状況に応じた採点まで幅広く活用しています。精度向上のためのPDCAサイクルを高速化に寄与できている一方で、課題としてトレース量の最適な制御方法を模索中です。過剰なトレース生成によりログの視認性が低下する場合があり、今後はサンプリング率の調整など、効率的なトレース管理の仕組みを検討していく予定です。

◆ご執筆者のご情報

• お名前: 渋谷 優介
• 役職:AIエンジニア
• 所属: Algomatic AI Transformation
• X（旧Twitter）アカウント名: @sergicalsix
  
  

PrometheusとGrafana Labsオブザーバビリティスタック/GMOペパボ株式会社

1.会社・事業のご説明
GMOペパボ株式会社は、「もっとおもしろくできる」を企業理念に掲げ、インターネットで個人の表現活動を支援するサービスを展開する企業です。主な事業として、国内最大級のレンタルサーバー「ロリポップ！」、ネットショップ作成サービス「カラーミーショップ」、ハンドメイドマーケット「minne」、オリジナルグッズ作成・販売サービス「SUZURI」、ライブ配信支援サービス「Alive Studio」など多様なサービスを運営しています。これらのサービスを通じて、個人クリエイターから中小企業まで幅広いユーザーの創造的な活動を技術とサポートで支え、日本のインターネット文化とクリエイターエコノミーの発展に大きく貢献しています。

2.PrometheusとGrafana Labsを活用したLLMOpsのご紹介

アーキテクチャ図

3.アーキテクチャ設計の背景・意図
GMOペパボでは、長年にわたりデータセンターでのオンプレミスサーバー運用を通じて蓄積した知見を活かし、独自のプライベートクラウド基盤を構築しています。この基盤上に、内製ツールを用いてKubernetesクラスタを自動プロビジョニングする仕組みを実装し、アプリケーションデリバリーの高速化を実現しました。現在、社内の多くのシステムがこのKubernetes環境で稼働しており、AI関連サービス（DifyやAI Slack bot）も同環境で運用しています。Self-hosted Sentry や Grafana Labs のプロダクトに関しても、Kubernetes で自律的に運用できるため、これらのツールにおいても運用負荷を増やすことなく価値を提供することが可能となっています。

◆なぜそのツールを選択したのか
オブザーバビリティツールとして、用途に応じてDatadogとGrafana Labs が開発する Grafana, Loki, Tempo といった OSSツール群を使い分けています。各サービスの本番環境ではDatadogをメインに採用し、データの統合による恩恵を受けています。一方、高トラフィックであり Datadog をヘビーに活用するとコストがかかりすぎてしまうようなサービスに対し、Self-hosted Sentry を提供し、社内で使用する Bot や運用ツールなどには OSSツール群を Kubernetes クラスタ上でアドオンとして提供しています。用途別にツールを使い分けることにより、すべてのシステムに対し可観測性を高めるアプローチを取ることが可能となっています。

◆実際にどのように運用をしているのか
内製プロビジョニングツールにより、各KubernetesクラスタにはデフォルトでOSSの監視ツール群がデプロイされます。これらツールのバージョンアップや障害対応は、Kubernetes に専門性を持つ有志で集まった「k8s-chapter」が主体となって実施しています。所属組織に依存しない運用体制を構築することにより、知見の共有やツールの開発などによる、レバレッジの効いた運用を実現しています。

◆ご執筆者のご情報

• お名前: 高橋 拓也
• 役職: プリンシパルエンジニア
• 所属: GMOペパボ株式会社 技術部 技術基盤グループ
• X（旧Twitter）アカウント名:@takutaka1220