Promptfooレビュー：LLM評価・レッドチーミングの使い方と料金

料金とドキュメントは2026年10月13日に確認しました。以下の実例は、テスト用に作成した固定の回答を使い、ローカルで実行したものです。ホスト型機能の評価は公開ドキュメントに基づいており、ログインして製品を試用した結果ではありません。 Promptfooの現行プラン。

Promptfooとは？

Promptfooは、AIモデルやアプリケーションにテスト入力を送り、応答を検証し、結果を比較できる形で表示するオープンソースのコマンドラインツール兼ライブラリです。**評価（eval）**は、回答が要件を満たすかを繰り返し確認するテストです。レッドチーミングでは、あえて要件に違反する動作を引き出そうとします。プロンプト、テスト対象、サンプル、採点ルールを定義し、ローカルの結果画面で確認するか、ビルド工程で結果を利用します。「この変更でサポートボットに不具合が生じていないか」を再現可能な方法で確かめられる点が、このツールの価値です。入門ドキュメントでは、品質評価とセキュリティテストの両方を扱っています。

どんな人に向いている？ 別のツールを選ぶべきなのは？

Promptfooが向いているのは、テスト設定を自分で管理し、顧客が実際に利用するアプリケーションへ接続できる開発者です。ヘルプ記事を検索したり、注文記録を読み取ったり、返金ツールを呼び出したりするサポートボットは、適した対象です。役に立つ回答を返せるかと、安全に操作を実行できるかは、それぞれテストする必要があります。

コードと一緒にレビューできるテスト、プロバイダー間の比較、アプリケーション固有の攻撃的な検証が必要なら、有力な選択肢になります。ただし、何を正しい回答とするかは、誰かが決めなければなりません。どのツールを使うにしても、意味のある評価にはこの作業が欠かせません。

出典：Promptfoo、Braintrust、LangSmith。課金方式が異なるため、同等の機能一式に対する価格比較ではありません。

いま必要なのがリリース前のテスト設計よりも、本番環境の分析をチームで共有することなら、最初の導入先としてはほかのツールを検討してください。 実験のレビューと共通データセットが業務の中心ならBraintrustが候補になります。望ましくない結果の原因を探るために、エージェントがモデルやツールを呼び出した順序を追いたいならLangSmithが候補です。料金と具体的な長所・短所は後述します。

判断の軸は、テスト対象が本番環境にどれだけ近いか、採点の根拠をどれだけ確認できるか、データの取り扱い制約の下でどのセキュリティテストを使えるか、そしてワークフロー全体でいくらかかるかの4点です。連携先が多くても、テスト対象が間違っていれば補いにはなりません。より広い候補の比較は、AIベンチマーク監査ツールの比較記事で扱っています。

OpenAIによる買収で何が変わった？

Promptfooの現在の公式リポジトリには、OpenAIの一員であり、引き続きMITライセンスで提供されると記載されています。日付のある企業発表から今後の方向性は確認できますが、買収の完了日や買収額は示されていません。Promptfooのリポジトリ。

2026年3月9日、PromptfooはOpenAIによる買収に合意したと発表しました。買収完了には通常の条件を満たす必要があるとされていました。同社は、この動きによって中核技術を改善し、モデル層とインフラ層へ統合できるようになると説明しています。同じ発表では、サービスとサポートの継続、オープンソースのツール群の保守、多様なモデルとプロバイダーへの対応継続も約束しています。Promptfooの発表。

これらは同社が表明した方針です。現在のプロバイダードキュメントにも、競合他社のサービスやローカルランタイムが掲載されています。統合に関する説明は今後の方向性として受け止めるべきで、特定のエンタープライズ機能がすでにCLIで使える証拠とはいえません。

導入を判断するときは、所有者の変更と技術上の要件を分けて考えることが大切です。これらの発表を根拠に、PromptfooをOpenAI専用の評価ツールとみなすことはできません。また、予定されているエンタープライズ向け統合を理由に、自分たちのワークフローで確認していない機能へ投資するべきでもありません。現在のパッケージ、導入形態、契約内容を評価してください。

設定の仕組みと対応プロバイダー

Promptfooでは、何を測定するつもりだったのかを、テスト設定として共有できます。YAML形式にはprompts、providers、testsがあり、個々のテストにvarsと任意のassertルールを指定します。プロバイダーは、モデルやアプリケーションを呼び出すアダプターです。{{question}}のような変数を使うと、テスト入力をプロンプトへ埋め込めます。設定ガイド。

サポートボットなら、現在のプロンプトと修正案に同じ質問と採点ルールを適用してください。条件が違うと、スコアが高くなったのは後の実行で簡単な質問が与えられたから、という可能性が残ります。プロンプトの文面、検索の動作、モデル、ツールの権限は、一度にいずれか1つずつ変更します。

ローカルの比較表では、スコアが変わった回答を個別に確認できます。短くしたプロンプトが未入力の注文IDを尋ねなくなったのか、安価なモデルが不確かな配達日を事実として伝えたのか。具体的にどの動作が悪化したのかを調べるために、この画面を使います。どちらの問題も、平均値だけでは見落とすおそれがあります。

どのプロバイダーに対応している？

Promptfooのプロバイダー一覧には、幅広い連携先が掲載されています。主な例は次のとおりです。

• モデルAPI： OpenAI、Anthropic、Google AI Studio、Google Vertex AI、Azure OpenAI、Amazon Web Services Bedrock、Cohere、Mistral AI、DeepSeek、Alibaba Cloud Qwen、AI21 Labs、Meta Model API、MiniMax、Moonshot Kimi、xAI、IBM WatsonX。
• ホスティング・推論サービス： Amazon SageMaker、Groq、Cerebras、Fireworks AI、Together AI、Hugging Face、OpenRouter、Replicate、Perplexity AI、NVIDIA NIM、Databricks、Snowflake Cortex、Cloudflare AI。
• ローカルランタイム： Ollama、llama.cpp、llamafile、LocalAI、Docker Model Runner、vLLM、Transformers.js。
• アプリケーション用アダプター： HTTP、WebSocket、Python、JavaScript、シェルコマンド、Model Context Protocolサーバー、ドキュメントに記載されたエージェントSDK連携。

これは代表例です。リンク先の一覧には、ほかのゲートウェイや特定用途のプロバイダーも含まれています。認証方式や利用可能なオプションは、各アダプターの説明で確認してください。プロバイダーに対応していても、そのアカウントで全モデルを利用できるわけではありません。

モデル単体ではなく、サポートアプリケーション全体をテストする

PromptfooのHTTPアダプターではリクエストを組み立て、transformResponseで回答を抽出できます。たとえば、json.outputを指定します。カスタムPythonプロバイダーから既存のアプリケーションコードを呼び出すこともできます。サポートボットの動作が検索、セッション状態、認可、ツール実行に左右される場合、こうした接続方法が重要になります。HTTPプロバイダーのドキュメント。

実際の顧客が尋ねるような質問を、これらの機能が働く経路に通し、応答を評価します。アプリケーションが使うべきものと同じ権限制限のあるIDとテスト用の固定レコードを含めてください。検索層を通さずにモデル単体をテストしても、ある顧客が別の顧客の注文情報を取得できるかどうかは、ほとんど分かりません。

したがって、アダプターの実装は、接続できれば終わりという作業ではありません。権限を決定するコンテキストを維持し、顧客に表示されるフィールドを抽出し、実行された操作を別途確認する必要があります。最終回答で丁寧に拒否しても、それ以前に権限のない返金を実行していたなら、その操作を取り消したことにはなりません。

Promptfooの使い方：サポートボットの回答を評価する

Promptfooは、すでに生成された回答も評価できます。モデルを繰り返し呼び出して費用をかける前に、ここから始めるとよいでしょう。echoプロバイダーは渡されたテキストをそのまま返すため、アサーションで回答を直接検証できます。Echo自体はモデルにリクエストを送りません。ただし、採点役のLLMを追加すれば、その限りではありません。Echoプロバイダーのドキュメント。

以下の例では、テスト用に作成した固定の回答を使います。顧客ログでも、モデルが生成したとする出力でもありません。サポート方針では、返金を希望する利用者にSettings、Billing、Request refundの順に進むよう案内するとします。注文状況を確認できない場合は、発送済みだと断言せず、サポートへの問い合わせを案内する必要があります。

次の内容をpromptfooconfig.yamlとして保存します。

description: Support bot answer checks
prompts:
  - '{{answer}}'
providers:
  - echo
tests:
  - description: Approved refund instructions
    vars:
      answer: 'Open Settings, choose Billing, and select Request refund.'
    assert:
      - type: icontains-all
        value: [Settings, Billing, Request refund]
  - description: Escalate an unknown order status
    vars:
      answer: 'I cannot verify your order status. Please contact support.'
    assert:
      - type: icontains
        value: contact support
      - type: not-icontains
        value: has shipped
  - description: Reject an invented order status
    vars:
      answer: 'Your order has shipped. Please contact support if needed.'
    assert:
      - type: icontains
        value: contact support
      - type: not-icontains
        value: has shipped

ここで使っているのは、ドキュメントに記載されたアサーション型です。icontainsは大文字と小文字を区別せずに文字列を検査し、icontains-allは指定したすべてのフレーズが含まれることを求めます。not-という接頭辞は判定を反転させます。アサーションのリファレンス。

ドキュメントで前提とされているNode.js >=22.22.0を用意して、次を実行します。

npx promptfoo@latest eval -c promptfooconfig.yaml -o support-results.json
npx promptfoo@latest view

スタートガイドには評価とビューアーのコマンドが、レッドチームのクイックスタートにはNodeの要件が記載されています。評価の実行が終了してから、別のコマンドとしてビューアーを起動してください。

本レビューのローカル実行では、意図した結果が得られました。返金案内は合格、注文状況を確認できないと伝える回答も合格、発送状況を捏造した回答は不合格でした。最後の回答にはサポートへの問い合わせを促すフレーズも含まれていましたが、禁止した主張があるため合格にはなりません。この結果から確認できるのは、サンプルの設定とアサーションが機能したことです。実際のモデルの信頼性については何も示していません。

この区別が大切です。採点処理を信頼する前に、必ず合格すべき回答と、必ず不合格になるべき回答を入力してください。両方が合格するなら、モデルを比較する前にテストを直します。テストの仕組みを最初にデバッグするための道具として、評価対象のモデルを使うべきではありません。

文字列の一致から、サポート品質の評価へ

Promptfooのモデル採点型アサーションは、文字列の一致だけでは捉えられない基準を評価できます。llm-rubricは文章で定めた評価基準に沿って採点し、factualityは回答を参照用の記述と比較します。採点に使うプロバイダーも明示的に選択できます。モデル採点型アサーション。

このボットなら、渡された注文情報だけを使うこと、情報が足りないときはそれを認めること、許可された次の行動を案内することを評価基準にすると有用です。採点役には関連する方針と参照用の事実を渡してください。それがなければ、発送に関する主張が正しいかどうかを推測させることになります。

厳密な要件には結果が一意に決まるチェックを残し、表現に幅がある部分は内容を判断させます。上のサンプルでは、「荷物はお届けに向かっています」という意味の“your parcel is on its way”は検出できません。逆に、誤りを訂正するために禁止フレーズを引用した適切な文を、不合格にする可能性もあります。これらは選んだチェックの限界であり、ボットが安全か危険かを示す証拠ではありません。

次に、固定の回答を収集済みの回答に置き換えるか、アプリケーション用プロバイダーを接続します。既知の不適切な回答は、採点ロジックのテストとして残してください。プロンプトを変更しただけで、気づかないうちに合格の定義まで変わってはいけません。

Promptfooのレッドチーミング：アプリケーションの権限境界を検証する

Promptfooのレッドチームワークフローでは、攻撃的な入力を生成して対象に送信し、問題のある動作をレビューできる形で示します。プラグインで検証したい動作を選び、ストラテジーで攻撃の届け方を変えます。ドキュメントに記載されたテスト対象には、HTTPエンドポイント、ブラウザー操作、モデルやカスタムコードへの直接接続があります。レッドチームのクイックスタート。

サポートボットの通常の評価では、返金対象の顧客に正しい手順を案内できるかを確かめます。レッドチーミングで問うのは、顧客がボットを誘導し、他人の記録を開示させたり、方針を回避させたり、接続先のツールを不正に使わせたりできるかです。Promptfooのドキュメントは、間接的なプロンプトインジェクション、データ漏えい、不正アクセス、ツールの悪用など、アプリケーション層の脅威を扱っています。レッドチームガイド。

書き込み権限を持つエージェントは、管理されたテスト環境で検証し、チャットの記録に加えて操作後のレコードも確認します。回答だけのテストでは、権限のないツール操作を見逃す可能性があります。一方で、採点役が期待するほど親切に聞こえなくても、拒否が正しい場合もあります。

問題を修正したら、その検出事例を回帰テストに追加します。新たな問題を探す探索と、既知の問題が再発していないかを調べる再実行は、分けて扱ってください。このリリース工程については、AIエージェントのセキュリティ評価を実施するガイドでさらに詳しく説明しています。

CIとレポート：テストの失敗をリリースの停止条件にする

Promptfooは、コード変更時に自動チェックを実行する継続的インテグレーション（CI）に組み込めます。ドキュメントには、通常の評価、レッドチームスキャン、保存済みプローブの再実行、JSON・HTML・JUnitなどの形式へのエクスポートが記載されています。CI/CDガイド。

システムプロンプトや検索の動作を変更したときは、固定した回帰テスト群を使います。新しいケースを見つけたいときは、より広範な攻撃生成を別に実行してください。比較のたびに新しい攻撃を混ぜると、スコアが変化した理由を特定しづらくなります。アプリケーションの品質が下がったのか、テストが難しくなったのか、切り分けられなくなるためです。

ドキュメントに記載されたCLIのデフォルトでは、テストが失敗した場合や合格率のしきい値を満たさない場合の終了コードは100で、それ以外のエラーは1です。合格率のしきい値はデフォルトで100%ですが、これらの設定は変更できます。CIジョブでは失敗のステータスを正しく引き継ぎ、レポートが正常に保存されたことをテストの合格と取り違えないようにします。CLIリファレンス。

リリースの判定ルールでは、重大な誤動作と通常の品質上の不足を分けて扱います。それ以外の回答が役に立っていても、不正アクセスを平均値の中に埋もれさせてはいけません。リリースを止める各ケースに担当者を割り当て、証拠を保存し、変更後に同じケースを再実行してください。

レポートに価値があるのは、ほかの人がその結論を検証できるからです。結果と一緒に、アプリケーションのリビジョン、設定、テストデータ、採点役の選択も保存します。この情報がなければ、次にモデルやプロンプトを変更したとき、合格したレポートの結果を再現できなくなることがあります。

Promptfooの料金：Community・Enterprise・On-Premise

Promptfooには3つのプランがあります。有料プランは見積もりが必要で、公開中の料金ページには、どちらもドル建ての開始価格は記載されていません。2026年10月13日にPromptfooの料金ページで確認しました。

プローブの利用枠で何ができる？

Promptfooでは、レッドチーム評価中に対象へリクエストを送ると、プローブとしてカウントされます。内部で行う生成や採点の呼び出しは、プローブには含まれません。推論に関するドキュメントによると、ローカルモデルを含め、推論を自分で管理していても利用上限のカウントは続きます。推論と利用上限。

利用枠の数字を、そのまま異なるセキュリティシナリオの数として説明してはいけません。対象へ繰り返しリクエストを送るストラテジーと、単一ターンのケースでは、枠の消費のしかたが異なります。検証できる範囲は、アプリケーション、選んだ攻撃、実行時に送るリクエストに左右されます。対象を接続してから実測したリクエスト数を基に、必要量を見積もってください。

月額費用と回答あたりの費用をどう考える？

Promptfooのライセンスが無料でも、対象モデルの推論、攻撃生成、モデルによる採点、インフラ、失敗の調査には費用がかかります。月額の総費用は、これらのうち何を自分で運用し、何を外部から購入するかによって変わります。テストランナーが無料でも、プロバイダーの利用料金までなくなるわけではありません。

今回の実例では、評価した固定回答あたりのモデル推論費用は$0です。Echoはモデルを呼び出さず、チェックも結果が一意に決まる方式だからです。この結果は、LLMで採点するテスト群には当てはまりません。採点役が各回答を読む構成にした時点で、その使用量も評価の予算に含まれます。Echoの動作仕様。

比較のために示すと、BraintrustのStarterで公表されている超過料金は、1,000スコアあたり$2.50で、追加の1スコアあたり$0.0025と計算できます。これは採点の料金であり、合格したサポート回答を得るための総費用ではありません。モデルの利用とデータ処理には別の課金単位があります。Braintrustの料金。

費用を比較する際の分母は、サポート方針に照らして合格した回答数にすると有用です。その評価にかかった費用を合格回答数で割り、失敗の調査費用も見える形で併記します。実行費用が安くても、捏造された注文情報を合格にしてしまうなら、最適化する対象を間違えています。

導入前に押さえたい制約

Promptfooで特に注意したいのは、スキャナーがローカルで動くことと、セキュリティ検証の全工程がローカルで完結することは別だという点です。データの取り扱いに関するドキュメントは、対象への呼び出し、生成、採点を分けて説明しています。ホスト型の採点には、テストプロンプト、対象の応答、判定基準が送信される場合があります。

重要なテストの一部には、ホスト型の推論が必要です。 同じドキュメントでは、bola、bfla、indirect-prompt-injectionなどをリモート専用のプラグインとして挙げています。それぞれ、リソースへのアクセス、機能の実行権限、外部コンテンツを通じて届く指示に関わるものです。リモート生成を無効にすると利用できる検証範囲が狭まります。また、無効化フラグはネットワーク分離を保証するものではありません。取り扱いに制約のあるサポート用データセットを使うなら、完全にローカルでテストすると約束する前に、この点を解決しておく必要があります。

推論を自分で管理しても、プローブの上限はなくなりません。 これはデータの送信先とは別の制約です。推論のドキュメントには、独自の推論構成でも使用量をカウントすると明記されています。「オープンソースだから、ホスト型の攻撃サービスも無制限に使える」と考えてはいけません。

採点処理が、誤った動作を高く評価することもあります。 今回の実例で検出できるのは、発送を示す特定のフレーズであって、根拠のない配送関連の主張すべてではありません。採点役にLLMを使うと柔軟性が増す一方、別のモデルによる解釈が加わります。適切か不適切かについて責任あるサポート担当者の合意が得られる例を使い、評価基準を調整してください。

回答のテストでは、操作の失敗を見逃すことがあります。 対象アダプターが最終テキストしか返さないなら、そのテキストだけから、エージェントが正しいアカウントを使ったか、正しいレコードを変更したかは判断できません。ツールの利用が成功条件に含まれる場合は、操作の証拠やアプリケーションの状態確認を追加します。

運用の仕事は残ります。 テストケースを維持し、検出結果を調査し、どの問題があれば公開を止めるのかを決める担当者が必要です。マネージドのダッシュボードを導入すれば、その作業を連携しやすくはなります。しかし、テストで守らせるべき返金方針や顧客データへのアクセスルールまで、用意してくれるわけではありません。

Promptfooの代替ツール

Braintrust：評価作業をチームで共有したい場合

Braintrustは、トレース、実験、データセット、採点を共有プラットフォームにまとめたツールです。同僚と変更内容をレビューし、観測した動作を評価データに変える作業が日常的にあるなら、候補になります。この用途では、設定ファイルを中心に進める方式よりも、幅広い機能をまとめたBraintrustを先に検討する価値があります。

Starterは**$0/月で、処理データ1 GB**、10,000スコア、14日間の保存を含みます。Proは**$249/月で、5 GB、50,000スコア、30日間の保存を含み、Enterpriseは個別見積もりです。Starterの超過料金はデータが$4/GB**、スコアが**$2.50/1,000です。Proでは$3/GB**、$1.50/1,000と記載されており、保存期間の延長は別料金です。Braintrustの現行プラン。

注意点は、料金が複数の要素で決まることです。スコア、処理データ、保存期間、モデル使用量について、想定する負荷を見積もる必要があります。すぐに必要なのが、小規模でレビューしやすいテスト群とアプリケーションへの攻撃的な検証なら、Promptfooを優先してください。期待する動作を書き出す作業を避けるためだけに、共有プラットフォームを導入するべきではありません。

LangSmith：エージェントの実行過程を調べたい場合

LangSmithは、トレース、データセット収集、アノテーション、オンライン・オフライン評価を提供します。回答に至る一連の出来事を調べることが業務の中心なら、適しています。サポートエージェントは、間違ったレコードを取得した後でも、もっともらしい文を返すことがあります。その原因を調査する際、実行トレースは有用な証拠になります。

Developerは**$0/シート/月で、1シートに限定され、従量課金が発生する前に月間5,000件のベーストレースを利用できます。Plusは$39/シート/月で、月間10,000件のベーストレースを含み、シートを追加できます。公表されている利用枠は合計であり、シート数を掛けた数ではありません。Enterpriseは個別見積もり**です。LangSmithの料金。

レビュー担当者が増えるチームでは、従量課金が続くうえに、シートの追加費用もかかる点が制約になります。いまの目的が、攻撃的な検証範囲を明示した自動リリースチェックなら、Promptfooを優先してください。LangSmithのトレース、Braintrustのスコア、Promptfooのプローブは、それぞれ異なる出来事を数えています。同じテスト実行回数のように利用枠を比べると、予算を見誤ります。

結論：テストを自分たちで管理できるなら導入する価値がある

開発者がレビューし、繰り返し実行できる明確な品質チェックと攻撃的なテストが必要なら、Promptfooはサポートボットやエージェントのプロジェクトで役立ちます。データの流れ、検証範囲、運用方式が要件に合うなら、Communityから始めてください。共同作業、管理機能、導入環境の要件から具体的な必要性が生じたときに、マネージド機能を購入するとよいでしょう。

最も困っている点が変われば、選ぶツールも変わります。 安全で正しい回答とは何かを説明できないなら、まず方針とサンプルを整えます。説明はできるのに失敗を再現できないなら、Promptfooは妥当な次の一手です。失敗はすでに再現できており、課題が共同分析や実行過程の追跡にあるなら、BraintrustやLangSmithも合わせて検討してください。

次にすることは、代表的なサポートの質問を保存し、許容できる回答と禁止する操作を定義し、意図的に不適切な回答を入れて不合格になることを確認することです。その後、実際のアプリケーションを接続し、データへのアクセス境界を調べ、リリースを止めるべきセキュリティケースを追加します。スコアを見る前に、リリースの判定ルールを公開しておきましょう。

導入前によくある質問

AIシステムの開発記録や運用の現場から得た実践的な知見は、ニュースレターに登録してお読みください。