APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

さくらのAI EngineをLangfuse Cloudで可視化・評価設定してみた

こんにちは。クラウド事業部の遠見です。

  • 本記事は、「さくらのAI Engine」をLangfuse Cloudで可視化・評価設定する検証を実施したエンジニアが、内容をできる限り客観的に共有することを目的に作成しました。

前回の記事では、さくらのAI Engineをさくらのクラウド上にセルフホストしたLangfuseで可視化する構成を検証しました。

techblog.ap-com.co.jp

今回は3つのテーマを組み合わせて検証します。

1つ目は、Langfuse Cloud Japanです。
2026年4月27日、Langfuse Cloudが東京リージョンでのマネージドサービスを開始しました。
セルフホストと同様に「データが国内に留まる」構成を、インフラ構築なしで実現できます。

langfuse.com

langfuse.com

2つ目は、Evaluation(LLM-as-a-Judge)です。
Langfuseには、モデルの出力品質をLLMで自動評価する機能があります。
当初はさくらのAI EngineのモデルをEvaluator(評価者モデル)として使う、国産AI完結の評価パイプラインの構築を目指しました。
しかし今回の検証では、いくつかの制約があることがわかりました。
その過程も含めてレポートします。

3つ目は、Prompt Managementです。
プロンプトをコードから切り離してLangfuseで管理し、コードを変更せずに本番のプロンプトを更新できる仕組みを構築します。
今回はさくらのAI Engineと組み合わせた構成で、プロンプトとトレースの紐づけまでを確認します。


目次


はじめに

LangfuseのセルフホストとCloudの使い分け

前回の記事では、Langfuseのセルフホスト構成を構築した際、「データが完全にさくらのクラウド内で完結する」という点にメリットを感じました。
一方で、実際の運用を考えると以下のような課題もあります。

  • サーバーの管理・メンテナンスを自分たちでやるのは大変ではないか?
  • Langfuseのバージョンアップへの追従コストはどのくらいかかるか?
  • インフラコストを固定費ではなく従量課金にしたい

こうしたニーズに応えるのが、今回試すLangfuse Cloudです。
データを東京リージョンに置いたまま、インフラ管理なしでLangfuseを使えます。

それぞれの特徴を整理すると、以下のようになります。

観点 セルフホスト Cloud
セットアップ 高い(インフラ構築が必要) 低い(サインアップのみ)
運用負荷 高い(バージョンアップ・監視が必要) なし(マネージド)
コスト インフラ固定費 従量課金(無料枠あり)
データの所在 自社クラウド内で完結 東京リージョン(国内)
カスタマイズ性 高い(設定を自由に変更可能) Langfuse側に依存
ベンダーロックイン なし(いつでも移行可能) なし(OSSなので移行可能)

どちらを選ぶかはチームの状況次第です。

「手軽に始めたい」「運用負荷を下げたい」場合はCloud、「データをさくらのクラウドに完全に閉じたい」「細かい設定を自分でコントロールしたい」場合はセルフホストが向いています。

OSSであるLangfuseはどちらの選択肢も取れるため、状況の変化に応じて移行もできます。


「OSSなのにCloud?」という疑問

Langfuse CloudがSaaSとして提供されていることに、「OSSなのになぜ?」と違和感を覚える方もいるかもしれません。
しかし、「OSS」と「SaaS」という提供形態は矛盾するものではありません。

Langfuseのようなプロダクトは「Open Core + SaaS」というビジネスモデルを採用しています。

  • コードはOSSとして公開(MITライセンス)→ 誰でも自分のサーバーで動かせる
  • 同じコードをベンダー自身がSaaSとして運営 → ホスティングをお任せできる
項目 セルフホスト Cloud(SaaS)
コード 公開(MITライセンス) OSS版をベースに運用
実行環境 自分のサーバー ベンダーの環境
運用管理 自己責任(構築・アプデ) お任せ(保守不要・即利用)
主なメリット データの完全自社管理 運用コストの削減

つまり「OSS」とはコードのライセンス形態の話であって、デプロイ方法の話ではありません。

「CloudはSaaSだからOSSじゃない」ではなく、「OSSだからこそCloudとセルフホストの両方が選べる」という構造です。

ベンダーロックインのリスクが低い点も、このモデルの魅力です。


LLM Observabilityツールの選び方

LLM Observabilityのツールは、大きく2つに分かれます。

① 汎用APMの延長線

すでにAPMやインフラ監視ツールを導入しているチームが、そこにLLM監視機能を追加するアプローチです。
インフラメトリクスとLLMのレイテンシを同じダッシュボードで相関分析できる点が強みです。

② LLM専用 × OSS Cloud

LLMアプリ開発に特化して設計されたツールです。
プロンプト管理・バージョン管理・LLM-as-judgeによる評価など、LLM開発サイクルに必要な機能が最初から揃っています。
OSSであれば、セルフホスト版とクラウド版を状況に応じて使い分けられ、ベンダーロックインのリスクも低く抑えられます。

選び方の目安としては、以下のようなアプローチが考えられます。

状況 向いているアプローチ
すでにAPMツールを導入済み 汎用APMの延長
LLMアプリ専用に始めたい・コストを抑えたい LLM専用OSS Cloud
データを完全に自社管理したい LLM専用OSSのセルフホスト
データを国内に置きつつ運用負荷を下げたい LLM専用OSS Cloud(国内リージョン) ← 今回
  • 汎用APMも国内対応している場合があります。
  • 今回は「LLM特化の機能」と「国内データ保持」の両立にフォーカスしています。

Evaluationとは

LangfuseのEvaluation機能では、LLMの出力品質を自動評価できます。
Evaluatorとして別のLLMを使う手法を「LLM-as-judge」と呼びます。

今回は以下の構成で評価パイプラインの構築を試しました。

項目 内容
被評価モデル gpt-oss-120b / llm-jp-3.1-8x13b-instruct4 / preview/Phi-4-mini-instruct-cpu
Evaluator Anthropic Claude (claude-haiku-4-5)

今回の構成とゴール

本検証では、前回構築したチャットアプリを再利用し、Langfuse Cloudを活用して以下の3点を目指します。

No. 項目 内容
1 インフラ管理なしでの国内運用 東京リージョンのLangfuse Cloudへ移行し、動作確認をする
2 Evaluation (LLM-as-a-Judge) 各モデルの出力品質を可視化・スコアリングする(※今回は制約により過程のレポートまで)
3 Prompt Management プロンプトをコードから分離し、Langfuse上で管理・更新できる仕組みを構築する

Evaluationについては、今回の検証内では「Evaluatorの選定制約」や「SDKバージョンの制約」により、スコアの付与まで至りませんでした。
本記事ではその過程をレポートします。

検証環境

環境 項目 バージョン
ローカル OS Windows 11 Home 25H2
PowerShell 7.5.5
Python 3.12.4
uv 0.11.7
Langfuse SDK 2.60.10 (※Evaluationにはv3以上が必要)
Langfuse Cloud ホスト 3.171.0
プラン Hobby(無料)

langfuse.com

構成図


事前準備

さくらのAI Engineのアカウント作成・トークン取得

以下の記事と同様の手順です。

techblog.ap-com.co.jp

Langfuse Cloudのアカウント作成

ブラウザで jp.cloud.langfuse.com にアクセスします。

[Sign up]からアカウントを作成します。

[Data Region]で「JP」が選ばれていることを確認し、その他の項目を入力します。
入力が終わったら、[Sign up]をクリックします。

アンケートが表示されます。
任意の値を入れるか、[Skip]をクリックします。

Langfuseのポータルが表示されます。

URLが jp.cloud.langfuse.com であることを確認してください。

Organizationを作成します。

[Organizations] > [New Organization]をクリックします。

[Organization name]には、任意の値を入力します。
[Type]には、今回は個人での登録・学習目的なので、[Personal]を選択します。

プランは、[Hobby]で作られています。

[Organization Members]は、初回は自分しかいないので、そのまま[Next]をクリックします。

[New Project]では、[Project name]に任意の値を入力し、[Create]をクリックします。

Setupが完了すると、[Project Settings]の画面に遷移します。

APIキーの発行

[APIキー] > [Create new API keys]からAPIキーを発行します。

[Create API Keys]ダイアログでは、[Note]に任意の値を入力し、[Create API Keys]をクリックします。

以下の3つをコピーして保管します。

  • Public Key:pk-lf-...
  • Secret Key:sk-lf-...
  • Host URL:https://jp.cloud.langfuse.com

本番検証のWebアプリ作成

.envの変更だけで移行が完了します。
前回はTerraformでサーバー構築をしましたが、今回はサーバー構築・維持が不要になります。

【重要】
.envには機密情報が含まれます。
GitHubなどで管理する場合は、誤って公開リポジトリにプッシュしないよう、必ず.gitignoreに追加されていることを確認してください。

セルフホストからCloudへの移行

環境変数の設定

.envに以下を設定します。

# さくらのAI Engine
SAKURA_API_KEY=さくらのAI Engineのアカウントトークン

# Langfuse Cloud 
LANGFUSE_PUBLIC_KEY=pk-lf-xxxxxxxx
LANGFUSE_SECRET_KEY=sk-lf-xxxxxxxx
LANGFUSE_HOST="https://jp.cloud.langfuse.com"

動作確認

FastAPIサーバーを起動します。

uv run uvicorn app:app --host 0.0.0.0 --port 8000 --reload

http://localhost:8000にアクセスします。

チャット画面から各モデルへ質問を送ります。

用途 モデル 開発元
動作確認・デバッグ preview/Phi-4-mini-instruct-cpu Microsoft
本番デモ gpt-oss-120b OpenAI
本番デモ(国産モデル) llm-jp-3.1-8x13b-instruct4 LLM-jp(国立情報学研究所など)

参考:チャットアプリ実行結果

preview/Phi-4-mini-instruct-cpu

gpt-oss-120b

llm-jp-3.1-8x13b-instruct4


【検証】LangfuseダッシュボードでTracesを確認する

jp.cloud.langfuse.com のダッシュボードにアクセスし、トレースが記録されていることを確認します。

確認ポイントは以下です。

項目 記録内容
Input / Output プロンプトと応答内容
Model 使用したモデル名
Usage トークン数(Input / Output / Total)
Latency レイテンシ(ms単位)

ちなみに、私の環境ではチャット実行からLangfuse Cloudのトレースが確認できるまで、約10分かかりました。

また[Cost]カラムについては、前回の検証で「さくらのAI Engineの料金をLangfuseに反映する」を実施していますので、気になる方は以下をご確認ください。

techblog.ap-com.co.jp


【検証】LLM-as-a-JudgeでEvaluationを設定する

同じ質問に対する3モデルの出力を、LLM-as-a-Judgeでスコアリングすることを目指します。
※今回は設定までを行い、実際のスコア確認は次の機会とします。

EvaluatorにさくらのAI Engineのモデルを利用できなかった件

LangfuseのLLM-as-a-Judge機能は、内部的に評価結果を構造化データとして受け取るため、EvaluatorにはOpenAI形式の「ツール呼び出し(Tool Calling)」への対応が必須とされています。

langfuse.com

The gateway must support tool calling in the OpenAI format for LLM-as-a-Judge evaluations to work.

今回、さくらのAI Engineのモデル(gpt-oss-120bllm-jp-3.1-8x13b-instruct4)をEvaluatorに設定して試みましたが、[Default model configuration]の保存ができませんでした。

これは、API側がOpenAI互換のツール呼び出し(およびそれによる構造化出力)をサポートしていないことが原因である可能性が高いと考えられます。

そこでEvaluatorのみ、ツール呼び出しを安定して実行できるAnthropicのClaude(claude-4-5-haiku)を使用しました。
これにより被評価モデルはさくらのAI Engine(国内完結)、EvaluatorはAnthropicという構成になります。

EvaluatorにAnthropicを使う場合、評価対象のInput・OutputがAnthropicのAPIに送られます。
機密情報や個人情報を含むデータを扱う場合は注意が必要です。

さくらのAI EngineをEvaluatorに登録する

前項で記載したように、さくらのAI Engineのモデルを最終的なEvaluatorに設定することはできませんでした。
ただ、その過程も情報取得していたので、今回はナレッジとして記載したいと思います。

[LLM-as-judge] > [Create Evaluator]をクリックします。

[Set up evaluator]には、まだ何も登録されておらず、その旨の警告が表示されています。
[Set up]をクリックします。

[Default model configuration]ダイアログが表示されます。
[Add LLM Connection]をクリックします。

[New LLM Connection]ダイアログが表示されます。
以下の項目を入力します。

項目 設定値
LLM adapter openai
Provider name sakura(任意の名前)
API Key さくらのAI EngineのAPIキー
API Base URL https://api.ai.sakura.ad.jp/v1
Enable default models オフ(OpenAIのデフォルトモデルが混入すると国内完結にならないため)
Custom models llm-jp-3.1-8x13b-instruct4

【ポイント】
さくらのAI EngineをEvaluatorに使うことで、被評価モデルもEvaluatorも国内完結・完全国産になります。
今回は、Evaluatorに国産のllm-jp-3.1-8x13b-instruct4を使い、「国産モデルが国産モデルを評価するとどうなるか」を検証したいと思いました。

入力が完了したら、[Create Connection]をクリックします。

再び、[Default model configuration]ダイアログが表示されます。
[Provider]と[Model name]に今回登録したものがすでに入力されていましたが、[Save]をクリックしてみました。
しかし、反応がありませんでした。

[Set up evaluator]の警告も残ったままでした。

[Settings] > [Project Settings] > [LLM Connections]を確認すると、登録はされていることが確認できました。

AnthropicのClaudeをEvaluatorに登録する

そこで、EvaluatorをAnthropicのClaudeに切り替えて試してみました。

Anthropic APIはClaude.aiのサブスクリプションとは別課金となるため、console.anthropic.comでクレジットの購入が必要です。

[LLM Connections] > [Add LLM Connection]をクリックします。

[New LLM Connection]で、以下の項目を入力します。

項目 設定値
LLM adapter anthropic
Provider name sakura-claude(任意の名前)
API Key Anthropic APIキー

入力が完了したら、[Create connection]をクリックします。

[LLM Connections]にsakura-claudeが追加されています。

[LLM-as-a-Judge]に移動し、[Default model configuration]をsakura-claudeに切り替えます。
モデルは、Haikuで試してみることにしました。
理由は以下です。

  • LLM-as-a-Judgeの評価はシンプルなスコアリングなので高性能モデルは不要
  • コストが安いのでたくさん評価しても費用が抑えられる
  • 速度も速い

入力が完了したら、[Save]をクリックします。

[Set up evaluator]に反映されました。

Evaluatorの設定

以下の3つのEvaluatorを設定します。

項目 内容
Correctness 回答の正確さ
Helpfulness 回答の役立ち度
Hallucination 事実誤認・事実に基づかない回答

設定手順

Evaluatorの一覧から、[Correctness]をクリックします。

Observationsタブで開きますが、「Please verify your SDK version」が出ていました。
ObservationsモードはJS SDK v4+またはPython SDK v3+が必要とのことです。
今回の検証で使っているLangfuse Python SDKのバージョンはv2.60.10なので、それによって制限がかかっている可能性があります。

Experimentsタブに切り替えても、警告は出ています。
それでも、試しにEvaluatorを設定してみることにしました。

Variable Object Field
{{query}} Input
{{generation}} Output
{{ground_truth}} Input(正解データなしのため代用)

入力が完了したら、[Execute]をクリックします。

同様に、[Helpfulness]、[Hallucination]も設定します。

最終的には以下のようになりました。

この状態で、各トレースに対してEvaluationスコアが付与されているか、Tracingページを見てみましたが、確認できませんでした。

再度チャットを実行し、新しいトレースを取得してみましたが、それでも確認することはできませんでした。

SDKのv2→v3の変更は、コードの修正が必要な破壊的変更を含むため、今回はここまでとしました。

状況をまとめると、以下の通りです。

項目 状況
Evaluatorの設定(Claude Haiku) ✅ 完了
スコアの付与・確認 SDK v3へのアップグレードが必要

【検証】Prompt Managementを設定する

Prompt Managementは、プロンプトをコードから切り離してLangfuseで管理することができます。

主な目的は以下のとおりです。

機能 メリット
バージョン管理 プロンプトの変更履歴を残せる。「v1→v2に変えたら品質が下がった」という場合に即ロールバックできる
コード変更なしで更新 本番環境のプロンプトをLangfuseの画面上で変えるだけで即反映できる。デプロイ不要
チームで共有 エンジニア以外(プロンプトエンジニアやビジネス担当)がプロンプトを管理できる
A/Bテスト 複数バージョンのプロンプトを比較検証できる

今回の検証では、sakura-chat-promptを作り、それをLangfuseで管理することで、「質問への回答スタイルを変えたい」と思ったときにコードを触らず、Langfuseの画面だけで変更できるようになる設定までを確認しました。

プロンプトの登録

[Prompts] > [Create Prompt]をクリックします。

[Create new prompt]ダイアログで、以下を入力します。

項目 設定内容
Name sakura-chat-prompt
Type Chat
System欄 あなたは優秀なAIアシスタントです。以下の質問に日本語で丁寧に答えてください。
User欄 {{question}}
Commit message 初回バージョン

入力が完了したら、[Create prompt]をクリックします。

以下のように作成されます。

コードの変更

このプロンプトをコードから呼び出すように変更します。

改修のポイントとしては、これまではソースコード内にプロンプト(messages)を直接記述していましたが、LangfuseのPrompt Management機能を使うようにすることです。

プロンプトの動的取得

コードにプロンプト文言を書く代わりに、Langfuse上で設定した名前(ID)を指定して取得します。
compileメソッドを使うことで、プロンプト内の変数({{question}}など)に実際のユーザー入力を安全に埋め込むことができます。

prompt = langfuse.get_prompt("sakura-chat-prompt")
compiled_messages = prompt.compile(question=req.message)

トレーサビリティの向上(Prompt Link機能)

trace.generationの引数に、prompt=promptを追加します。
これにより、Langfuseの管理画面上で「どのバージョンのプロンプトを使って生成された回答か」が自動で紐付けられます。
評価の際に「v2のプロンプトは精度が高い」といった分析が容易になります。

generation = trace.generation(
    ...
    input=compiled_messages,
    prompt=prompt, # ここで取得したプロンプトオブジェクトを渡す
)

LLMクライアントへの受け渡し

Langfuseから取得・コンパイルしたメッセージをそのままLLM APIの引数に渡します。
SystemプロンプトやUserプロンプトの構成をLangfuse側で自由に変更しても、アプリケーション側のコードを一切修正する必要がなくなります。

response = sakura_client.chat.completions.create(
    model=req.model,
    messages=compiled_messages, # コンパイル済みメッセージを渡す
)

今回利用しているコードとの変更点をまとめると、以下のようになります。

+    # プロンプトをLangfuseから取得
+    prompt = langfuse.get_prompt("sakura-chat-prompt")
+    compiled_messages = prompt.compile(question=req.message)
+
     # Generation(LLM呼び出し単位)
     generation = trace.generation(
         name="sakura-llm-call",
         model=req.model,
-        input=[{"role": "user", "content": req.message}],
+        input=compiled_messages,
+        prompt=prompt,
     )
 
     try:
         response = sakura_client.chat.completions.create(
             model=req.model,
-            messages=[{"role": "user", "content": req.message}],
+            messages=compiled_messages,
         )

動作確認

[Prompts]から先ほど作成したプロンプト(sakura-chat-prompt)を表示します。
[Linked Generations]タブでトレースが表示されていれば、プロンプトとトレースが紐づいていることが確認できます。

トレースの詳細画面を確認すると、タグにPrompt: sakura-chat-prompt - v1と表示されています。
その下の[Preview]タブでは、[System]欄に今回設定したプロンプトが記載されています。

これで、正常に動作していることが確認できました。


まとめ

今回は、さくらのAI EngineとLangfuse Cloudを組み合わせたLLM Observabilityの検証として、LLM-as-a-Judgeの設定とPrompt Managementを試みました。

Evaluatorについては、さくらのAI Engineを使う「完全国内完結」の構成を目指しましたが上手くいかず、EvaluatorのみAnthropicのClaude Haikuを使用しました。
またスコアの付与には、おそらくLangfuse Python SDK v3以上が必要であり、実際の評価結果の確認は次回の検証に持ち越しとなりました。

Prompt Managementについては、sakura-chat-promptをLangfuseで管理し、コードからプロンプトを取得してトレースと紐づけるところまで確認できました。
プロンプトのバージョン管理や、コードを変更せずに本番のプロンプトを更新できる仕組みの土台ができた形です。

うまくいかなかった部分も多かったですが、それ自体が今後の課題の整理につながりました。
時間が許すなら、次回はSDKをv3にアップグレードし、3モデルの品質スコアを実際に比較する検証を行いたいと思っています。

また、Langfuseにはまだ試してみたい機能があります。

  • Experiments:プロンプトとモデルの組み合わせを実験管理できる

引き続き、学習していきたいと思います。


お知らせ

現在、弊社はさくらインターネットとパートナー契約を締結しています。 www.ap-com.co.jp

一緒に働いていただける仲間も募集中です! www.ap-com.co.jp

本記事の投稿者: s_tomi