こんにちは！株式会社雲海設計の技術部です。
「LangSmithを入れてみたが、結局CIに繋がらず使われなくなった」「Promptfooで評価は書けたが、本番のトレースとどう繋ぐかわからない」「商用SaaSは高そうだから内製したいが、どこまで自作すべきか判断できない」——2025年に生成AIの本番運用が広がった結果、2026年に入ってからハーネスエンジニアリング フレームワークの選定相談が、月に何件も入ってくるようになりました。本記事では、主要なハーネスエンジニアリング フレームワークをOSS・商用に分けて比較し、業務要件別の推奨構成と実装目線の選定基準を整理します。
TL;DR
ハーネスエンジニアリング フレームワークは「評価記述・実行・トレース・回帰検知」の4機能で評価する。単機能ツールの組み合わせか統合プラットフォームかで選定軸が変わる
OSSの主軸はPromptfoo / DeepEval / Ragas / OpenAI Evals。商用の主軸はLangSmith / Braintrust / Langfuse Cloud / Arize Phoenix
小規模PoCはPromptfoo + GitHub Actionsで十分。本番運用に入るならトレースSaaS + OSS評価のハイブリッドが2026年の主流
選定の決定打は「データの外部送信可否」「CI統合の容易さ」「コスト構造（トレース数課金 vs 固定）」の3点
RAG用途はRagas、エージェント用途はLangSmithかBraintrust、規制業種ならLangfuseセルフホストが有力候補
なぜ今ハーネスエンジニアリング フレームワークの選定が重要なのか？
結論から言うと、2025年に乱立したLLM評価ツールが2026年に入って機能の重複と差別化が明確になり、選定ミスが運用コストに直結するフェーズに入ったからです。Gartnerが2026年1月に出した「AI Engineering Hype Cycle」でも、LLM Observability/Evaluation領域は「Slope of Enlightenment（啓蒙の坂）」に位置付けられ、本格選定の時期に入ったと明記されています。
選定を誤ると起きる典型的な失敗
ツール乱立：評価はPromptfoo、トレースはLangfuse、ダッシュボードは自作、と分裂して誰もメンテしなくなる
過剰投資：チーム5人なのに商用LangSmith Enterpriseを契約し、月数十万円のトレース課金が積み上がる
規制違反リスク：金融・医療データを米国SaaSに送信していた、と監査で発覚する
そもそもハーネスエンジニアリングの全体像については、ハーネスエンジニアリングとは？LLM時代に必須の新常識を解説と、ハーネスエンジニアリング ベストプラクティスで解説しているので、未読の方は先にそちらを参照してください。
ハーネスエンジニアリング フレームワークが備えるべき4機能とは？
結論として、評価記述（Eval Authoring）／実行（Runner）／トレース（Tracing）／回帰検知（Regression Detection）の4機能を満たせるかが選定の出発点です。多くの失敗は「片方だけ強いツール」を選んで残りを自作で埋めようとして力尽きるパターンです。
4機能の役割整理
| 機能 | 役割 | 欠けると起きる問題 |
|---|---|---|
| 評価記述 | テストケースとアサーションをコード化 | 評価が属人化して再現できない |
| 実行 | 並列・キャッシュ・コスト計測 | 評価1回に数時間、コストも青天井 |
| トレース | 本番リクエストの入出力・中間ステップを保存 | 事故の再現と原因特定が不可能 |
| 回帰検知 | モデル更新やプロンプト変更時の差分検知 | こっそり性能劣化、本番で気付く |
OSS フレームワーク主要4種をどう使い分けるか？
OSS陣営は用途特化型が主流で、組み合わせて使うのが2026年現在のベストプラクティスです。
Promptfoo：軽量CI寄りの評価ランナー
YAMLでテストケースを書き、GitHub Actionsから実行できる軽量ツール。PoCから初期本番まで最もコスパが良い選択肢です。
prompts:
- file://prompts/answer.txt
providers:
- openai:gpt-4o-mini
- anthropic:claude-3-5-sonnet
tests:
- vars:
question: "返品ポリシーは何日以内？"
assert:
- type: contains
value: "14日"
- type: llm-rubric
value: "社内規程に基づいた回答であること"DeepEval：pytest 統合のユニットテスト風
Pythonのpytestと統合され、既存のテストワークフローにそのまま乗せられるのが利点。Hallucination・Faithfulness・Answer Relevancyなど主要メトリクスが組み込みです。
Ragas：RAG特化の定量評価
Context Precision / Recall / Faithfulness / Answer CorrectnessといったRAG固有のメトリクスに強い。RAG案件なら標準で入れて損はありません。RAGの実装設計自体はナレッジ管理×生成AIの実装設計で詳しく扱っています。
OpenAI Evals：標準的だが拡張は手作業
OpenAI公式のフレームワーク。シンプルだが、トレース連携や可視化は別途用意が必要です。社内で完結させたい場合の最小構成として有力です。
商用フレームワークはどう違う？
商用SaaSの強みは「トレース・評価・ダッシュボード・アラート」が統合されている点。OSSの組み合わせで作ると最低でも2〜3週間かかる初期構築が、数時間で立ち上がります。
主要4製品の比較
| 製品 | 強み | 料金感（2026年） | セルフホスト |
|---|---|---|---|
| LangSmith | LangChain連携・エージェント可視化 | $39/seat〜＋トレース課金 | Enterprise のみ可 |
| Braintrust | 評価UIが秀逸・実験比較が高速 | 無料枠あり、従量制 | 不可（SaaS専用） |
| Langfuse Cloud | OSS版あり・データ主権を選べる | $29/月〜＋イベント数 | OSS版でフル機能 |
| Arize Phoenix | OSSベース・OpenTelemetry標準 | OSS無料／Arize AX有償 | 可 |
「ベンダーロックインを避けたいなら、トレース層はOpenTelemetry準拠を選べ」——これは2026年の現場で繰り返し効く原則です。LangfuseとPhoenixはOTel互換のため、後でツール乗り換えがしやすいのが大きな利点です。
業務要件別、推奨構成はどれか？
結論として、チーム規模・データの機密度・LLM呼び出し量の3軸で構成を決めるのが実装目線で最もブレません。
パターンA：5人以下のPoC〜小規模本番
評価：Promptfoo（YAMLでGit管理）
トレース：Langfuse セルフホスト（Docker一発）
CI：GitHub Actions でPRごとに評価実行
月額目安：インフラ費のみで1〜3万円程度
パターンB：20〜50人規模・本格運用
評価：Promptfoo + DeepEval + Ragas（用途別に併用）
トレース：Braintrust または LangSmith
回帰検知：商用ダッシュボードのアラート機能
月額目安：15〜40万円（トレース量による）
パターンC：規制業種・データを外に出せない
評価：DeepEval / Ragas をオンプレ実行
トレース：Langfuse セルフホスト（OSS版でフル機能）
LLM：Azure OpenAI または AWS Bedrock の閉域構成
監査：トレース全件を社内ストレージに保管、Human-in-the-Loopで重要判定
選定フローチャート
graph TD
A[開始] --> B{データ外部送信OK?}
B -- NG --> C[Langfuseセルフホスト + DeepEval]
B -- OK --> D{チーム規模}
D -- 5人以下 --> E[Promptfoo + Langfuse]
D -- 20人以上 --> F{エージェント中心?}
F -- Yes --> G[LangSmith or Braintrust]
F -- No --> H[Braintrust + Ragas]導入時に必ず躓くポイントは？
雲海設計が2025年〜2026年にかけて10件以上のハーネス導入を支援した経験から、ほぼ全ての現場で同じ落とし穴に落ちることが分かっています。
失敗パターンTOP3
評価セットを後回しにする：ツールだけ入れても、ゴールデンデータがなければ動かない。最低30件のテストケースを先に用意する
LLM-as-a-Judgeを盲信する：自動評価器も幻覚する。重要メトリクスは人手レビューと突き合わせる
本番トレースとCI評価が分離する：別ツールで管理すると、本番で起きた事故をCI評価に取り込めない。トレースSaaSのDataset機能で繋ぐ
セキュリティ観点の注意点はAIセキュリティ対策実装ガイド2026で詳述しているので、本番投入前にチェックリストとして使ってください。
まとめ：2026年のハーネス選定はハイブリッドが正解
2026年現在、「OSS評価フレームワーク + トレースSaaS（またはOSSセルフホスト）」のハイブリッド構成が最も実装コストとランニングコストのバランスが取れています。単一ツールに賭けるより、評価レイヤーとトレースレイヤーを分けて、それぞれにベストなものを選ぶ方が、後の乗り換えも容易です。
雲海設計では、DX ソリューションとIT コンサルティングの枠組みで、ハーネスエンジニアリングの初期構築から評価セット整備、CI/CD統合までを伴走支援しています。「PoCは動いたが、本番品質の運用に持っていけない」という段階の企業さまは、ぜひお問い合わせからご相談ください。
よくある質問
Q. ハーネスエンジニアリング フレームワークは内製と外部ツールどちらが良いですか？
A. 評価ロジック自体は内製で良いですが、トレース・ダッシュボード・回帰検知の基盤は既存ツールを使う方が圧倒的に速いです。フルスクラッチは保守要員を最低1人専任で確保できる組織でない限り推奨しません。
Q. LangSmithとBraintrustはどう使い分けますか？
A. LangChain/LangGraphベースのエージェントを多用するならLangSmith、フレームワーク非依存で評価UI重視ならBraintrustが向いています。両者は無料枠があるので、2週間ずつトライアルして決めるのが最短です。
Q. 評価セットは何件あれば本番投入できますか？
A. 最低でも各シナリオ30件、合計100〜300件を目安にしてください。敵対的入力・境界ケース・典型ケースの3種を最低30件ずつ揃えるのが2026年の業界標準です。
Q. オンプレ環境でも動くフレームワークはありますか？
A. Langfuse OSS版・Arize Phoenix・DeepEval・Promptfoo・Ragasはすべてセルフホスト可能です。金融・医療・公共系の案件ではこの組み合わせが定番です。
Q. 既にLangSmithを使っていますが、コストが高くて見直したいです
A. トレース課金が原因のケースが大半です。サンプリング率を10〜30%に下げ、重要シナリオのみ全量取得する方式に変えれば、3〜5割削減できることが多いです。それでも厳しければLangfuseへの移行を検討してください。