PromptfooでLLMの評価とレッドチーム試験を一つにする
プロンプト、エージェント、RAG をテストします。 AI のレッド チーム化/侵入テスト/脆弱性スキャン。 GPT、Claude、Gemini、DeepSeek などのパフォーマンスを比較します。コマンドラインとCI/CD統合によるシンプルな宣言型構成。 OpenAI と Anthropic によって使用されます。
ひと目でわかる
- これは何？
- promptfoo/promptfooの宣言的な評価設定、モデル比較、脆弱性スキャン、CLIとCI連携をREADMEから確認する。
- 誰に向いている？
- プロンプト、エージェント、RAGの応答を複数モデルで比較し、同じ評価をCLIやCIで繰り返したいチームに向きます。多くのLLMプロバイダーでAPIキーが必要なため、秘密情報の注入とログ管理を先に設計してください。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
評価と攻撃試験を同じ設定で扱う
promptfoo/promptfooは、プロンプト、エージェント、RAGをテストするCLIとして説明されています。GPT、Claude、Gemini、DeepSeekなどを比較し、宣言的な設定をCLIとCI/CDで実行できます。レッドチーム、ペネトレーション、AIの脆弱性スキャンも機能範囲に含まれます。
評価値は、設定したプロンプト、テストケース、採点方法の結果です。モデル名を並べるだけで優劣が決まるわけではありません。業務で許容する正解、拒否、根拠、遅延、費用をテストケースとして明示し、モデルやプロンプトの変更でどの項目が動いたかを記録します。
Quick Startをそのまま小さく試す
READMEの入口は npm install -g promptfoo と promptfoo init --example getting-started です。生成された例のディレクトリで評価を実行し、結果を確認します。brew install promptfoo、pip install promptfoo、npx promptfoo@latestも案内されていますが、版を固定したいCIでは実行環境を明示します。
最初は秘密情報を含まないテストケースを使い、設定ファイル、入力、評価結果を保存します。結果の画面だけで判断せず、どのプロバイダーへどの入力が送られ、採点が何を見ているかを確認すると、評価の再現条件が見えます。
APIキーとモデル比較の現実
Quick Startは、多くのLLMプロバイダーがAPIキーを要求し、環境変数へ設定するよう案内しています。OpenAI、Anthropic、Azure、Bedrock、Ollamaなどを横並びで比較できます。サービスごとに認証方式、モデル名、コンテキスト長、料金、レート制限が違うため、同じ設定名だけでは比較になりません。
CIではキーを設定ファイルへ書かず、実行環境の秘密管理から注入します。プロンプトやRAG文書に個人情報が含まれる場合、外部プロバイダーへ送るテストとローカルモデルのテストを分けます。出力ログにキーや機密入力が残らないことも確認します。
RAGとエージェントの採点を分解する
Promptfooはプロンプトとモデルだけでなく、エージェントやRAGもテスト対象にしています。RAGでは検索された文書、回答の根拠、未回答時の挙動を別の観測点にします。エージェントではツールの選択、引数、呼び出し順、停止条件を確認し、最終文だけを採点しないようにします。
READMEは自動評価やセキュリティ脆弱性レポートを挙げていますが、採点の正しさを自動で保証するとは述べていません。誤検知と見逃しを人手で再確認できるケースを残し、モデル版や評価設定を固定して比較可能にします。
レッドチーム結果をCIへ接続する
脆弱性スキャンとレッドチーム試験は、プロンプトインジェクションや危険な出力などを発見する入口になります。READMEにはセキュリティ脆弱性レポートを生成できるとあります。検出項目、攻撃入力、採点基準、失敗時の扱いはテスト対象のアプリケーションに合わせて定義します。
CIへ入れる時は、安定したスモーク評価と時間のかかる探索評価を分けます。失敗したケースの入力、モデル応答、ツール実行、判定理由を保存し、修正後に同じケースを再実行します。外部サービスの一時障害をプロンプト回帰と誤認しないよう、エラー状態も記録します。
MITライセンスとOpenAI参加後の確認
READMEはPromptfooがOpenAIの一部になった後もオープンソースかつMITライセンスだと説明しています。利用条件はLICENSEで確認しますが、これは評価結果の正確性、外部モデルの規約、入力データのプライバシーを保証しません。
リリース更新時はCLI版、設定ファイル、プロバイダー、評価結果の形式を同時に確認します。自社の代表ケースでベースラインを取り、スコアだけでなく入力、出力、費用、遅延、セキュリティ判定を比較します。READMEにある導入の容易さと、本番の品質管理を同じものとして扱わないことが採用の前提です。
導入判定では、promptfoo init --example getting-startedで作った設定を固定し、同じテストケースを二つのモデルで評価します。APIキーは環境変数から注入し、設定ファイル、評価結果、入力、モデル版を保存します。RAGでは検索根拠と回答を別に採点し、エージェントではツール名、引数、順序、停止条件を確認します。レッドチームの失敗ケースはCIのスモーク評価へ一つずつ追加し、外部APIのエラーとプロンプト回帰をログの状態から区別します。
Promptfooの版、評価設定、モデル版、APIエラーを保存します。スコアの変化だけでなく、根拠、ツール呼び出し、費用、遅延、脆弱性判定を同じケースで比較できる状態にします。
Promptfooの評価結果には設定、入力、モデル、採点結果を添付します。APIキーをログへ出さず、同じRAG根拠とエージェントのツール履歴をモデル変更の前後で比較し、CIの失敗理由を再現します。
編集部の結論
プロンプト、エージェント、RAGの応答を複数モデルで比較し、同じ評価をCLIやCIで繰り返したいチームに向きます。多くのLLMプロバイダーでAPIキーが必要なため、秘密情報の注入とログ管理を先に設計してください。まず npm install -g promptfoo、promptfoo init --example getting-started、評価実行の順で試し、結果の保存形式、モデル差、脆弱性レポートの根拠を確認してからCIへ広げます。
コミュニティノート