“PoC は動くのに本番で死ぬ” — 2026 年の AI 開発に残る最大の課題
2026 年 4 月、LayerX エンジニアブログに掲載された「“なんとなく改善”からの脱却。Langfuse で作る、精度を改善し続けられる AI 開発基盤」 という記事が、Zenn Trending 上でも大きな話題となりました。著者はバクラク事業部のソフトウェアエンジニアで、要点は次の一言に集約されます。
精度は微妙だが、それっぽい挙動をするもの は簡単に作れるが、お客様に継続的に使っていただける、安定した精度改善を続けられる機能 を作るのは想像よりずっと難しい。
これは 2026 年の事業会社で AI 機能を開発している人なら、誰もが痛いほど頷く言葉です。LLM は確率的に動くため、普通のソフトウェアと同じ発想で「バグが起きたら直す」「テストで守る」だけでは回りません。精度を定量的に測る基盤と、再現性を持って改善できる実験環境が、本番運用には不可欠になってきました。
この記事は、LayerX や ZOZO など、日本の事業会社で実際に採用が広がっている Langfuse を軸に、「PoC 止まり」を卒業するための LLMOps 基盤の作り方をまとめたものです。
Langfuse とは —— 4 つの柱でできている
Langfuse はオープンソースの LLM Observability / LLMOps プラットフォームです。クラウド版とセルフホスト版の両方があり、LayerX は社員数無制限で SSO 対応のセルフホストを決め手に採用したと公開しています。
機能は大きく 4 つの柱に整理できます。
| 柱 | 解決する課題 | 主要機能 |
|---|---|---|
| Observability（可観測性） | 何が起きているか分からない | トレース・スパン・メタデータ収集、デコレータでの自動計測 |
| Prompt Management | プロンプト更新で都度デプロイが必要 | プロンプトの Git ライクなバージョン管理、A/B 配信 |
| Datasets / Experiments | 精度を比べる定量軸がない | 評価用データセット、Experiment Runner SDK |
| LLM-as-a-Judge | 定性評価を人手でやる負荷 | 別 LLM を判定役に回す自動評価 |
これらが一つの UI に統合されているのが Langfuse の強みです。PoC → 本番 → 継続改善のすべてのフェーズで同じダッシュボードを見ながら会話できるため、PdM・エンジニア・QA・ビジネス側が同じ数字で議論できます。
Python で計測するだけなら、本当に @observe デコレータを付けるだけです。
from langfuse.decorators import observe
from langfuse.openai import openai # OpenAI SDK の薄いラッパ
@observe()
def summarize_invoice(text: str) -> str:
"""請求書 OCR の後処理要約。トレースは自動記録される。"""
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "以下の請求書データを構造化して返してください。"},
{"role": "user", "content": text},
],
)
return response.choices[0].message.contentこのコードだけで、Langfuse の UI には 入力 / 出力 / トークン数 / レイテンシ / コスト が自動で記録されます。初回セットアップから”最初の 1 トレース”までは、本当に 30 分もかかりません。
LayerX 事例に学ぶ 3 層評価設計
Langfuse を導入しただけでは、実は精度改善は回りません。どう測るかを設計してはじめて改善サイクルが回ります。LayerX の一連の記事から学べる「3 層評価設計」を整理すると次のとおりです。
層 1 ── オフライン評価（Datasets + Experiments）
- 期待出力をセットにした評価用データセットを Langfuse 上に用意
- プロンプトやモデルを変えた結果を、同じデータセットで一斉実行
- LayerX の Experiment Runner SDK の記事 でも、実験管理の具体実装が詳しく公開されています
ここで押さえたいのは「事前に決めた指標で判定する」こと。雰囲気で「良くなった」と言わない文化を、基盤レベルで強制できます。
層 2 ── オンライン A/B（Prompt Management）
- 本番トラフィックをプロンプトバージョン A/B に分岐
- ユーザー行動（保存率・再実行率・クレーム率）と一緒に Langfuse にトレース
- 統計的に有意差がついたら勝者にスイッチ
層 3 ── ユーザーフィードバック（Scores API）
- ユーザーの「👍 / 👎」や「スコア 1〜5」を Langfuse の Score API に送る
- Observability 上で実際の体験評価と内部指標のギャップを検証
- LLM-as-a-Judge を合わせると、人手レビューのボトルネックを大幅に軽減できる
3 層を同時に走らせることで、事前の期待・統計的効果・実際の体験の 3 つが同じダッシュボードに並びます。これが「PoC は良かったのに本番で死ぬ」問題の根本治療です。RAG 系の精度改善テクニックとの掛け合わせは RAG 最適化パターンカタログ 2026 にまとめているので、合わせて読むと全体像がクリアになります。
Langfuse vs 他の LLMOps ツール ── 2026 年 4 月版の棲み分け
「Langfuse 一択か？」というと、実はそんなことはありません。自社の状況に合わせた選定が必要です。代表的な 4 つのツールを整理します。
| ツール | 提供形態 | 強み | 向いているケース |
|---|---|---|---|
| Langfuse | OSS / SaaS / Self-host | OSS・SSO 対応セルフホスト・4 つの柱が統合 | データ持ち出しに制約がある日本企業、自社基盤に組み込みたい |
| LangSmith | SaaS（LangChain 公式） | LangChain / LangGraph との密な統合 | LangChain 中心のエージェント開発 |
| Helicone | SaaS / Self-host | プロキシ方式でアプリ改修ほぼ不要 | 既存アプリに最短で可観測性を足したい |
| Arize Phoenix | OSS | エンタープライズ向けのフレキシブルな評価 | MLOps 文化がすでに根付いている組織 |
LayerX の採用理由「ユーザー数無制限 SSO 対応のセルフホスト」が、日本の中堅〜大企業に刺さっているポイントです。ライセンス費の予見性が高く、情シスが監査しやすいセルフホスト構成に乗せられる、というのは現場の選定では意外と大きな決め手になります。
ちなみに、モデル側の選択肢として日本語特化 LLM を検討している方は NII「LLM-jp-4」で自社専用 AI を持つ方法 も併せてチェックしてみてください。オンプレ＋日本語 LLM＋Langfuse という構成は、データ持ち出しに制約のある業界でも現実解になりつつあります。
発注者として “AI 精度改善” を定量化するチェックリスト
LLM 機能の開発を外注する場合、受託先が精度改善を定量化できるかは、契約前に必ず確認したい観点です。以下のチェックリストをそのまま提案依頼書に貼って構いません。
- Observability ツール：どのツール（Langfuse / LangSmith / Helicone 等）を使い、誰が見るか
- 評価用データセット：誰が・いつまでに・何件用意するか
- 成功指標の定義：オフライン評価の合格ラインを数値で約束できるか
- A/B テスト設計：本番投入前後でどのユーザーに何割配るか
- 改善サイクルのリードタイム：プロンプトを更新して本番に反映するまでの所要時間
- ユーザーフィードバックの集約経路：👍 / 👎 や NPS をどう AI 開発に戻すか
これらを受託先と事前に握っておくだけで、「“なんとなく改善” しました」という報告が出てくる頻度は激減します。AI エージェント時代の要件定義全般は Spec・Context・Harness 三層設計 でも扱っていますので、合わせて参考にしてみてください。
まとめ
- 2026 年の AI 機能開発の最大の課題は、PoC で動くのに本番で精度が揺らぐこと。これを解くには、定量評価・実験管理・ユーザーフィードバックが同じ基盤に乗る必要がある。
- Langfuse は Observability / Prompt Management / Datasets / LLM-as-a-Judge の 4 つの柱が一つの UI に統合された LLMOps プラットフォーム。OSS・SSO 対応セルフホストが日本企業にフィットしやすい。
- LayerX 事例の3 層評価設計（オフライン評価 + オンライン A/B + ユーザーフィードバック）をそのまま自社に輸入できる。
- 受託先を選ぶときは「Observability ツール」「評価データセット」「成功指標」「A/B テスト」「改善リードタイム」「フィードバック経路」の 6 項目を必ず握る。
GleamHub では Langfuse を中心とした LLM Observability 基盤の設計・実装・チーム伴走までワンストップで支援しています。「PoC は動くのに、本番に出したら品質が安定しない」と悩む PdM・EM の方は、ぜひ一度状況をお聞かせください。
