promptfooは、LLMを組み込んだアプリのプロンプトとモデルの出力を、YAMLで書いたテストケースで採点するオープンソースのCLIです。2026年10月4日時点の最新版は0.123.1、ライセンスはMITで、評価に加えて攻撃的な入力を自動生成するレッドチーミングも同じツールで回せます。この記事では、インストールからpromptfoo evalの初回実行、決定論的な検査とllm-rubricの書き分け、自社APIを評価対象にする接続、GitHub Actionsでの合否判定、外部に送られる情報の止め方、そして採用を見送る条件までを、コピーして動かせる設定例とあわせて整理します。
まとめ：promptfooで最初に書く設定と、採用を決める2つの条件
最初に書くのはpromptfooconfig.yaml1枚です。プロンプト、呼び出すモデル、テストケース、合否の条件（アサーション）の4つをこのファイルに並べ、promptfoo evalを叩けば比較表が出ます。アサーションは文字列一致やJSON検査のような機械的な検査を先に置き、意味の良し悪しを測るllm-rubricは後から重ねる順序が扱いやすい構成です。
採用を決める条件は2つ。プロンプトの変更がプルリクエスト単位で発生していること、そして評価結果を「合格か不合格か」の終了コードでCIに返したいことです。この2つに当てはまるなら、promptfooは導入の手間に対して得るものが大きいツールです。
逆に、評価資産がPythonのテストコードとして既にあり、本番トレースの保存と採点を1つの基盤にまとめたい現場では、promptfooを主役にしないほうが整理しやすくなります。
promptfooの守備範囲と、2026年10月時点の版数・OpenAI参加後の位置づけ
promptfooが担う評価とレッドチーミング、担わないトレース保存の境界線
promptfooが担うのは、リリース前に固定したテストケースへ出力を流し込み、採点して比較する工程です。公式ドキュメントの概要では、プロンプトやモデルの評価、レッドチーミングによる脆弱性検査、モデルの並列比較、CI/CDへの組み込みが主な用途として挙げられています。評価はローカルで実行され、プロンプトが手元の環境から外へ出ない設計です。
担わないのは、本番トラフィックの入出力を蓄積して検索する役割です。そこはLangfuseのようなトレース基盤の機能と使い方の領分で、promptfooは採点器として後ろに置く形になります。評価指標やデータセット設計といった上流の考え方はLLM評価の指標とデータセット設計の進め方にまとめており、本記事はpromptfoo固有の設定に絞ります。
0.123系の版数・MITライセンスと、OpenAI参加後もOSSが続く根拠
GitHubのpromptfooリポジトリをAPIで確認したところ、2026年10月4日時点の最新リリースは0.123.1（2026年9月18日公開）、スター数は25,680、ライセンスはMITでした。npmレジストリ上の同版はNode.jsの要件を22.22.0以上としています。0.x系のまま頻繁に版が上がるため、CIでは版を固定して使うのが前提です。
運営面では、2026年3月9日の公式ブログでOpenAIへの参加が発表されました。同記事は、オープンソースの評価・レッドチーミングツールを維持し、複数のプロバイダーとモデルへの対応を続けると明言しています。
インストールからpromptfoo evalの初回実行まで、検証環境の作り方と手順
ここからは手を動かす工程です。Node.jsとLLMのAPIキーが1つあれば、10分ほどで最初の比較表まで進めます。
Node.js 22.22以上を前提に、npxとbrewとpipで導入する手順の違い
READMEが案内する導入経路は4つあります。グローバルに入れるnpm install -g promptfoo、brew install promptfoo、pip install promptfoo、そしてインストールせずに実行するnpx promptfoo@latestです。チームで版を揃えるなら、リポジトリのpackage.jsonに開発依存として固定し、npx経由で呼ぶ形が扱いやすくなります。
node -v # v22.22.0 以上を確認
npm install --save-dev [email protected]
export ANTHROPIC_API_KEY=sk-ant-... # 評価対象と採点に使うキー
npx promptfoo init --example getting-started
cd getting-started
npx promptfoo eval
npx promptfoo view # ブラウザで比較表を開く
promptfoo viewはローカルにWeb画面を立ち上げ、テストケースとモデルの組み合わせごとに合否と出力を並べて見せます。
promptfooconfig.yamlの4要素とモデル比較の最小構成
設定ファイルの骨格は、プロンプト、プロバイダー、テストケース、アサーションの4要素です。設定キーはそれぞれprompts、providers、testsと、その中のassertです。下の例は、問い合わせ文を1文で要約させ、2つのClaudeモデルを並べて比べる最小構成になります。モデルIDの書式はAnthropicプロバイダーの仕様に従い、anthropic:messages:の後ろにモデル名を続けます。
# promptfooconfig.yaml
description: 問い合わせ要約の回帰テスト
prompts:
- "次の問い合わせを、担当部署が分かる1文に要約してください。\n\n{{inquiry}}"
providers:
- anthropic:messages:claude-sonnet-5-5
- anthropic:messages:claude-haiku-4-5-20251001
tests:
- vars:
inquiry: 先月分の請求書が届いていません。再発行をお願いできますか。
assert:
- type: contains
value: 請求
- type: llm-rubric
value: 経理部門が担当すべき内容だと読み取れる1文になっている
{{inquiry}}はvarsの値で置き換わります。テストケースを増やすときはtestsに項目を足すか、CSVやJSONLへ切り出して読み込ませます。
アサーションの書き分けと、決定論的な検査にllm-rubricを重ねる設定
合否の判定方法は2系統に分かれます。どちらを主にするかで、実行時間と費用が1桁変わります。
contains・is-json・javascriptによる機械的検査を先に置く理由
アサーションの仕様では、equals・contains・regex・is-json・javascript・cost・latencyなどが決定論的な検査として並んでいます。採点にLLMを呼ばないので、費用はかからず結果もぶれません。
出力をJSONで受け取るアプリなら、まずis-jsonで形式を、次にjavascriptで必須キーの有無を確かめます。ここで落ちる出力は意味を問う前に壊れているため、llm-rubricに回す必要がありません。各アサーションにはweight（既定1.0）で重みを、metricで集計用の名前を付けられ、画面上で「形式」「内容」のように分けて点数を追えます。
llm-rubricの採点モデル指定と、thresholdが合否を変える仕組み
llm-rubricは、自然文で書いた基準を別のLLMに渡して採点させる方式です。モデル採点の仕様によれば、採点用のモデルは環境にある認証情報から自動で選ばれ、--graderオプション、defaultTest.options.provider、アサーション単位のproviderの3か所で上書きできます。
defaultTest:
options:
provider: anthropic:messages:claude-sonnet-5-5 # 採点器を固定する
tests:
- vars:
inquiry: ログイン画面でパスワードを3回間違えてロックされました。
assert:
- type: llm-rubric
value: 情報システム部門への依頼として要約され、個人を責める表現がない
threshold: 0.8
採点結果はpass・score・reasonの3項目で返ります。thresholdを書かなければpassだけで合否が決まり、書けばpassが真かつscoreが閾値以上のときに限り合格です。採点器を自動選択に任せると、CI環境に置いたキー次第で採点モデルが変わるため、必ず明示してください。採点器を信用してよい条件はLLM-as-a-Judgeの仕組みと採点の偏りで扱っています。
自社のLLMアプリをHTTPプロバイダーで評価対象にする接続設定と注意点
モデル単体ではなく、検索やツール呼び出しを含む自社アプリ全体を測りたい場面では、アプリのAPIをそのまま評価対象にします。
httpsでのAPI呼び出しとtransformResponseによる出力抽出例
HTTPプロバイダーの仕様では、id: httpsにURL・メソッド・ヘッダー・本文を書き、本文の{{prompt}}にテストケースのプロンプトが入ります。応答JSONから評価したい部分を取り出すのがtransformResponseです。
providers:
- id: https
label: support-bot-staging
config:
url: https://staging.example.com/api/chat
method: POST
headers:
Content-Type: application/json
Authorization: "Bearer {{env.STAGING_TOKEN}}"
body:
message: "{{prompt}}"
transformResponse: json.answer
接続先は本番ではなく、ステージング環境を指定してください。評価は同じ入力を何十回も送るため、本番に向けると利用量の集計や監視アラートを汚します。トークンはCIのシークレットから環境変数で渡します。
GitHub ActionsとCLIの終了コードで、プロンプト変更をPRごとに検査する
評価は1回走らせて終わりではなく、プロンプトが変わるたびに繰り返して初めて回帰検出の役に立ちます。
promptfoo-action v1の入力と、版を固定せずに動かしたときに起きる差分
公式のGitHub Action連携はpromptfoo/promptfoo-action@v1で、2026年10月4日時点の最新タグはv1.3.4（2026年6月15日）です。action.ymlを確認すると、必須の入力はgithub-tokenとconfigの2つで、promptfoo-versionの既定値はlatestになっています。
name: prompt-eval
on:
pull_request:
paths: ["prompts/**", "promptfooconfig.yaml"]
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: promptfoo/promptfoo-action@v1
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
config: promptfooconfig.yaml
promptfoo-version: 0.123.1
anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
promptfoo-versionを省くと、ある日のPRだけ新しい版で採点され、プロンプトを変えていないのにスコアが動く事態が起きます。版を上げるときは、プロンプト変更と別のPRに分けてください。ワークフローの基本的な書き方はGitHub Actionsでの自動テストの設定手順で確認できます。
終了コード100とPROMPTFOO_PASS_RATE_THRESHOLDの合格基準
コマンドラインの仕様では、promptfoo evalはテストが1件でも失敗するか、合格率がPROMPTFOO_PASS_RATE_THRESHOLDを下回ったときに終了コード100を返し、それ以外のエラーでは1を返します。閾値の既定値は100%、つまり1件の失敗も許しません。
PROMPTFOO_PASS_RATE_THRESHOLD=95 npx promptfoo eval -c promptfooconfig.yaml -o results.json
echo $? # 100 なら品質不合格、1 なら設定や接続の失敗
100は「出力が基準に届かない」、1は「評価そのものが動いていない」なので、CIの失敗通知を出し分けられます。llm-rubricを含むテストは揺らぎがあるため、閾値は100%ではなく90〜95%から始め、--repeatで同じケースを複数回流して揺れ幅を見てから詰めるのが現実的です。失敗したケースだけを再実行する--filter-failingも、原因の切り分けで手数を減らします。回帰検査の範囲の決め方はリグレッションテストの範囲選定と自動化と同じ考え方が通用します。
レッドチーミング機能の実行手順と、社外へ送信される範囲の確認ポイント
promptfooのもう1つの柱が、攻撃的な入力を自動で作って自社アプリに当てるレッドチーミングです。便利な反面、データの流れを把握せずに回すと社内規程に触れます。
redteam init・run・reportの3工程とプラグイン別の既定生成数5件
レッドチーミングのクイックスタートでは、promptfoo redteam init --no-guiで設定を作り、promptfoo redteam runで攻撃を実行し、promptfoo redteam reportで結果を見る3工程が案内されています。攻撃の種類を決めるのがプラグイン、生成した入力をジェイルブレイクやインジェクションの型で包むのがストラテジーです。
設定の仕様によれば、プラグイン1つあたりの生成数（numTests）の既定値は5件です。プラグインを20個選べば100件、ストラテジーを重ねればさらに倍々で増え、その全件が評価対象のアプリを呼び出します。攻撃手法そのものの整理はAIレッドチーミングの実施手順とツール選定に譲ります。
攻撃文のリモート生成とテレメトリ、社外に出る情報を止める環境変数
評価（eval）はローカルで完結しますが、レッドチーミングの攻撃文は既定でpromptfoo側のリモートサービスが生成します。止めるにはPROMPTFOO_DISABLE_REDTEAM_REMOTE_GENERATION=trueを設定し、redteam.providerに自社で契約したモデルを明示的に指定してください。公式は、この場合に生成の質が下がりうると注記しています。
export PROMPTFOO_DISABLE_REDTEAM_REMOTE_GENERATION=true
export PROMPTFOO_DISABLE_TELEMETRY=1
export PROMPTFOO_DISABLE_UPDATE=1
npx promptfoo redteam run
テレメトリの仕様では、送信されるのはパッケージの版やCI上で動いているかといった情報で、プロンプト・モデル出力・テストケース・APIキーは送らないと明記されています。それでも、顧客データを含むテストケースを扱う環境では3つの変数を既定で入れておき、セキュリティ審査で説明できる状態にしておくべきです。
promptfooを採用する条件と見送るべき場面、外部委託時の成果物の決め方
ここからは判断を言い切ります。promptfooは強力ですが、すべての現場の評価基盤になるわけではありません。
採用してよい3条件と、Community版の月1万プローブで足りる規模
次の3条件がそろうなら採用してください。プロンプトをファイルとしてGitで管理していること、変更がPR単位で入ること、評価対象をHTTP経由かモデルAPI経由で呼べること。この状態なら、設定ファイル1枚とワークフロー1本で回帰検査が回り始めます。
費用面では、料金ページのCommunity版が無料で評価機能をすべて含み、レッドチーミングは月10,000プローブまで使えます。SSOやチームでの結果共有が要る段階でEnterprise、データを自社基盤から一切出せない場合にOn-Premiseを検討する順で十分です。
promptfooを見送る場面：Python中心の評価資産とトレース前提の運用
見送るべき場面は2つです。1つは、評価ロジックがPythonのテストコードとして既に積み上がっている現場。YAMLのpythonアサーションで呼び出せはしますが、二重管理になります。RAGの指標をそのまま使いたいなら、Ragasのように指標が揃ったライブラリを主にしたほうが早く進みます。
もう1つは、オフラインの回帰検査より本番トラフィックのサンプリング採点が主目的の場合です。promptfooは固定したテストケースを流す道具で、本番ログを溜めて採点結果を書き戻す仕組みは持ちません。この場合はLLMOpsで整理したトレース・評価・コスト管理の型を先に組み、promptfooはリリース前の関門に限定して置くのが妥当です。
評価設計を外部に任せるとき、promptfooの設定一式を成果物に含めさせる理由
LLMアプリの開発を委託するなら、納品物にpromptfooconfig.yaml、テストケースのCSV、GitHub Actionsのワークフローの3点を含めるよう見積段階で指定してください。これがあれば、受け入れ時に自社の環境で同じ評価を再実行でき、合格率という数字で検収できます。逆に「品質は確認済み」という報告書だけでは、次にプロンプトを直したときに何を回せばよいか分かりません。
評価の型づくりを含めてLLMを組み込んだ業務システムの開発を相談したい場合は、生成AI導入支援で要件の整理から引き受けています。依頼前に「この出力なら合格」と言える例を5件ほど書き出しておくと、テストケースの初版がすぐ作れます。
よくある質問
promptfooの導入時によく出る疑問を5つ取り上げ、設定と判断の基準とあわせて回答します。
promptfooは無料で使えますか？
使えます。本体はMITライセンスのOSSで、料金ページのCommunity版は評価機能をすべて含み、レッドチーミングは月10,000プローブまで無料です。ただし評価対象や採点に使うLLMのAPI利用料は別途かかり、llm-rubricは採点のたびにモデルを呼びます。
OpenAIに買収された後も、Claudeなど他社モデルの評価に使えますか？
使えます。2026年3月9日の公式ブログはOpenAIへの参加を発表すると同時に、複数のプロバイダーとモデルへの対応を続けると明言しています。2026年10月時点のAnthropicプロバイダーの仕様にも、現行のClaudeモデルIDが記載されており、他社モデルへの対応を確認できる状態です。方針の変化に備えるなら、CIで使う版を固定し、更新時にリリースノートを確認する運用にしておけば影響を受けにくくなります。
promptfooの設定ファイルはどこに置けばよいですか？
評価対象のプロンプトと同じリポジトリの直下にpromptfooconfig.yamlとして置くのが基本です。プロンプト本体は別ファイルに切り出して設定から参照すると、差分がPRで読みやすくなります。テストケースが数十件を超えたらCSVに分け、業務担当者も表計算ソフトで追記できる形にしてください。
llm-rubricの採点結果が実行ごとに揺れるときはどうすればよいですか？
まず採点器をdefaultTest.options.providerで明示して固定します。次に--repeatで同じケースを3回程度流し、どのケースで合否が割れるかを確認してください。割れるケースは基準文が曖昧なことが多く、「丁寧である」のような抽象語を「謝罪の一文を含む」のような観察できる条件へ書き直すと収まります。
DeepEvalとpromptfooはどちらを選べばよいですか？
プロンプトをファイルで管理し、YAMLとCLIで比較・回帰検査を回したいならpromptfoo、評価をPythonのテストコードとして書き、pytestの流れに乗せたいならDeepEvalが合います。チームの主要言語と、評価を誰が書くか（開発者だけか、業務担当者も触るか）で決めると迷いません。
関連記事
- プロンプトインジェクションとは？仕組み・種類・対策をわかりやすく解説：レッドチーミングで当てる代表的な攻撃の仕組みと防ぎ方を解説しています。
- RAGASとは？RAG評価フレームワークの指標・0.4系の実装手順・導入判断【2026年版】：RAGの指標をPythonで測る場合の実装手順と、promptfooとの使い分けの参考になります。
