promptfooを社内の検査標準にする？｜合格線は人が決める

「社内で作った生成AIのアプリを公開する前に、何を確かめたのかと聞かれても答えられない」「開発チームごとに試し方が違い、品質の基準がそろっていない」——生成AIのアプリが社内で増え始めた会社の、情報システム部門やAI導入の担当者から聞こえてくる声です。こうした中で、アプリの答えを試験の問題と合格の条件で検査するオープンソースの道具 promptfoo が、2026年3月に OpenAI に加わると発表しました。名の知れた道具を社内の標準にすれば検査の質がそろう、と考えたくなりますが、そうではありません。本当は、道具がそろえてくれるのは検査の形式までで、何を合格とするかを人が決めなければ、品質の基準は何もそろいません。この記事では、2026年10月時点の公式情報をもとに、promptfoo を出荷前の検査の標準にするかどうか、標準にするなら試験の問題と合格線を誰が持つのかを、運用に定着させる順に整理します。

promptfooとは何をする道具か

公式GitHubの説明では、promptfoo は「LLMを使うアプリを評価し、レッドチーミングするための、コマンドで動かす道具とライブラリ」です。2026年10月時点で挙げられている機能は、自動の評価でプロンプトとモデルを試すこと、レッドチーミングと脆弱性の走査、複数の提供元のモデルを横に並べて比べること、CI/CD（変更を取り込むたびに自動で検査と公開を回す仕組み）の中での自動の検査、プルリクエストのコードを生成AIに関わる安全や法令順守の観点で走査すること、です。

仕組みは単純です。検査する側は、アプリに投げる質問（試験の問題）と、返ってきた答えが満たすべき条件（合格の条件）を設定ファイルに書きます。道具はそれを順に投げ、答えを条件に照らして採点し、結果を一覧にします。同じ問題を別のモデルや別のプロンプトに投げて、横に並べて比べることもできます。

ライセンスはMITで、2026年10月時点でも公式GitHubでは新しい版の公開が続いています（10月8日に 0.124.1）。道具そのものに料金はかかりませんが、検査のたびに対象のアプリと採点役のモデルを呼び出すため、問題の数と回す回数に比例して、モデルの利用料が増えていきます。費用の見積もりは、問題の束の大きさと、1か月に検査を回す回数から逆算します。

押さえておきたいのは、promptfoo は答えの良し悪しを自分で判断する道具ではない、という点です。判断の基準は、使う側が書いた問題と条件そのものです。基準を書かなければ何も検査されず、基準が甘ければ甘い検査が、毎回きちんと同じように回り続けます。標準にするかどうかの議論は、この性質を前提に進めます。

日本語の解説がほとんど無いのはなぜか

2026年10月時点で、promptfoo を日本語でまとめた解説はほとんど見当たりません。理由として考えられるのは、まず道具の性格です。画面から操作する業務アプリではなく、設定ファイルを書いてコマンドで動かす開発者向けの道具として作られており、公式の資料も英語です。

次に、検査という仕事の置き場所です。生成AIのアプリを社内で作り始めた会社の多くは、まだ作って動かす段階にあり、出す前の検査を仕組みとして持つところまで進んでいません。検査の道具が話題になるのは、アプリの数が増え、チームごとの品質の差が問題になってからです。

そのため、情報システム部門やAI導入の担当者が promptfoo の名前を聞くのは、開発チームから「これで検査している」と報告されたときか、海外の資料を読んだときが多いはずです。報告を受けた側が、その道具を全社の標準にしてよいのかを判断する材料は、日本語ではほぼ手に入りません。

この記事は、使い方や設定の書き方ではなく、社内の標準にするかどうかを判断する側の目線で書いています。コマンドや設定の例は載せていません。開発チームが道具を試す段階と、会社が標準として認める段階は別のものとして扱います。

2026年3月、OpenAIに加わると発表された

2026年3月9日、promptfoo の公式ブログは、OpenAI に買収されることで合意したと発表しました。発表では、買収の完了には通常の条件を満たす必要があるとしたうえで、promptfoo はオープンソースのまま続けること、どのモデルやアプリにも使える評価・レッドチーミング・静的な走査の道具として維持すること、利用者と顧客に対してサービスと支援の継続性を保つこと、を約束しています。

同じ発表には、OpenAI が promptfoo の中核の技術を、自社のモデルと基盤の層に組み込んで改善していくことも書かれています。あわせて、多様な提供元とモデルへの対応を続ける、と明記しています。

その後、公式GitHubの説明には「promptfoo は OpenAI の一部になった」「オープンソースでMITライセンスのまま」と書かれています。2026年10月時点で公式から確かめられるのはここまでです。有償の企業向けの提供がこの先どうなるかについては、公式の発表に具体的な記載はありません。

社内の標準を選ぶ立場から見ると、この出来事は道具の良し悪しとは別の論点を生みます。検査する道具の提供元が、検査される側のモデルの提供元にもなった、という点です。この論点は、検査の決めごとを一通り見たあとで扱います。

「検査の標準にする」とは何を決めることか

道具を標準にすると聞くと、全チームに同じ道具を入れることだと受け取られがちです。しかし道具をそろえても、試験の問題が各チーム任せで、合格線もばらばらなら、検査の質はそろいません。そろうのは、結果の一覧の見た目だけです。

標準にするとは、少なくとも次の4つを会社として決めることです。どの種類の検査を必ずやるか。試験の問題を誰がどこから集めるか。何点なら出してよいかを誰が決めるか。結果をどこに何年残すか。道具はこの4つを実行して記録する器であって、決めごとの代わりにはなりません。

逆に言えば、この4つが決まっていれば、道具は promptfoo でなくても構いません。道具の選定は、決めごとが固まってからでも遅くないのです。順番を逆にすると、道具の設定項目がそのまま社内の基準になり、なぜその基準なのかを誰も説明できなくなります。

以下では、この4つを運用に定着させる順に、検査の項目、問題作り、合格線、AIの採点の扱い、回す時機、レッドチーミングの位置、外に出る情報、結果の保管、提供元の変化への備え、の順で見ていきます。

検査の項目は、機械で判定できるものから決める

公式ドキュメントは、答えを照らす条件を大きく2種類に分けています。1つは、決まった規則で判定する条件です。答えに特定の語が含まれるか、完全に一致するか、決めた文字の並びの型に合うか、JSONの形になっているか、応答にかかった時間や費用が上限内か、といったものです。自社で書いた判定の処理を使うこともできます。

もう1つは、モデルの力を借りて採点する条件です。決めた評価の観点に沿っているか、事実と食い違っていないか、質問に関係のある答えか、渡した資料に忠実か、といった判定を、別のモデルに採点させます。公式もこれらを、LLMやほかの機械学習のモデルに頼る指標だと明記しています。

検査の項目を決めるときは、まず機械で判定できる条件で拾えるだけ拾い、残った部分にだけモデルの採点を使うという順が扱いやすくなります。決まった規則の判定は何度回しても同じ結果になりますが、モデルの採点は採点役のモデルの癖や更新で揺れるからです。

たとえば社内の規程を答えるアプリなら、答えに出典の文書名が含まれるか、使わないと決めた語が出ていないか、応答が上限の秒数内に返るか、は機械で判定できます。答えの中身が規程の趣旨に合っているかは、モデルの採点か人の確認に回します。どの項目を必須にするかは、アプリの用途ごとに業務の責任者と決めます。

試験の問題は、実際の業務の質問から人が選ぶ

検査の価値は、試験の問題の質で決まります。開発者が思いついた問題だけで試すと、作り手が想定した使われ方しか確かめられません。実際の利用者が投げる質問は、言い回しが崩れていたり、前提が抜けていたり、アプリの範囲の外に踏み出していたりします。

問題の集め方として現実的なのは、試行期間の質問の記録から、業務の担当者と一緒に選ぶことです。よく来る質問、答えを誤ると影響が大きい質問、アプリが断るべき質問、の3つの群に分けて選ぶと、検査の網に偏りが出にくくなります。記録を使うときは、個人名や顧客名を伏せてから問題にします。

問題の候補をAIに作らせることはできますが、どの問題を試験に入れるかは人が決めます。AIが作る問題は、AIが答えやすい形に寄りがちです。業務で本当に困る質問は、現場の担当者の頭の中と、実際の問い合わせの記録の中にあります。

問題は一度作って終わりではありません。公開後に誤答の報告が来たら、その質問を試験に加えます。こうして問題の束は、アプリが実際に間違えた場所の記録として育っていきます。問題の束を誰が管理し、追加と削除を誰が承認するかも、標準の一部として決めておきます。

合格線は、道具の仕組みを知ったうえで人が決める

promptfoo では、1つの問題に複数の条件を付けられます。公式ドキュメントによれば、条件ごとに重みを付けられ（既定は1）、問題の点数は重み付きの平均になります。重みを0にすると、点数に影響させずに記録だけを残せます。

合否の決まり方には2通りあります。問題ごとの合格の点（しきい値）を決めない場合は、重みが0でないすべての条件を満たして初めて合格です。しきい値を決めた場合は、重み付きの点数がその値に届けば、個々の条件の一部を落としていても合格になります。

この仕組みは便利ですが、しきい値と重みの決め方しだいで、同じ答えが合格にも不合格にもなります。重みとしきい値は技術の設定に見えて、実際には「どの誤りなら許すか」という業務の判断です。開発チームの裁量に任せきりにせず、業務の責任者が承認する項目にします。

合格線は、アプリ全体の合格率でも決めておきます。たとえば、使わないと決めた語が出る問題は1件でもあれば出さない、よく来る質問の群は一定の割合以上で合格、のように、群ごとに重さを変えるのが実務的です。何割なら出してよいかを最後に決めるのは、アプリを業務に使わせる責任者です。

AIに採点させる部分は、人の採点と突き合わせてから使う

モデルに採点させる条件は、人が全件を読むより速く、言い回しの違う答えも柔軟に判定できます。その一方で、採点役のモデルも誤ります。公式ドキュメントには、採点役がエラーを返したり判定を出せなかったりした場合に、0点の失敗として扱う条件がある、という記述もあります。

採点役の点を合格線に使う前に、少数の問題で人も採点し、両者が一致するかを確かめます。ずれが大きい観点は、評価の観点の書き方を直すか、その観点だけは人の確認に回します。採点役のAIの癖そのものの扱いは、AIにAIを採点させる線を整理した別の記事に譲ります。

採点役に使うモデルの選び方にも注意が要ります。検査される側と同じモデルに採点させると、同じ癖を見逃しやすくなります。採点役のモデルを変えたときは、以前の結果と点数がずれることがあるため、変えた日と理由を記録に残します。

AIの採点は、合格線の判断を助ける材料の1つです。採点の一部はAIに任せても、出すかどうかを決めるのは人です。この線を標準の文に書いておくと、点数が上がっただけで公開に進む流れを止められます。

リリースのたびに回す。継続的な検査に組み込む位置

検査は、公開前に1回やって終わりではありません。生成AIのアプリは、プロンプトの小さな書き換え、参照する資料の更新、使うモデルの切り替えで、答えが変わります。以前は合格していた問題が、気づかないうちに落ちるようになることがあります。

promptfoo は、CI/CD の中で自動の検査として回せることを、公式が機能として挙げています。変更を取り込む前に試験の問題を回し、合格線を下回れば取り込みを止める、という組み方ができます。組み込む位置は、次の順で決めておくと迷いません。

このうち、止める条件と例外の手続きは、開発チームだけで決めず、業務の責任者の承認を取ることが欠かせません。自動で止まる仕組みがあっても、例外の承認が緩ければ、検査は形だけになります。

回す頻度が上がるほど、モデルの利用料も増えます。毎回の検査は短い問題の束で、大きな変更のときだけ全体を回す、という二段構えにしておくと、費用の増え方を変更の数に比例する範囲に収められます。

レッドチーミングは何を確かめる作業か

promptfoo のもう1つの柱が、レッドチーミングです。わざと攻撃する立場に立ってアプリに問いを投げ、弱点がないかを探す作業を指します。公式ドキュメントは、確かめる対象として、個人情報などの漏れ、指示の乗っ取り、安全のための制限をすり抜けさせる試み、望ましくない内容の生成、権限の確認の抜けといった領域を挙げています。

公式ドキュメントは、こうした検査を、OWASP がまとめたLLMアプリの主な危険の一覧、米国の標準化機関によるAIのリスク管理の枠組み、欧州のAI法といった、整いつつある基準と結び付けて説明しています。また、本番に近い環境で、アプリ全体を通して試すことを勧めています。

社内の標準として決めるのは、レッドチーミングを出荷前の検査に含めるかどうか、含めるならどの領域を必ず見るか、誰が実施を許可するか、の3点です。自社が管理し、実施の許可を書面で得たアプリだけを対象にすることも、標準の文に入れておきます。他社のサービスに無断で試すことは、不正アクセスにあたるおそれがあります。

レッドチーミングの進め方や攻め方の組み立ては、この記事では扱いません。AIをわざと攻撃して弱点を探す手順は、別の記事で詳しく整理しています。ここでは、出荷前の検査の中で、どの領域を必ず確かめたのかを記録に残せる状態にしておくことを押さえてください。

何が外に出るか。既定の設定で送られる情報

公式GitHubは、評価は手元で動き、プロンプトが手元の環境から出ていかないと説明しています。ただし、これは検査の道具そのものの話です。検査の対象のアプリが外部のモデルを呼び出せば、試験の問題はそのモデルの提供元に送られます。採点役に外部のモデルを使う場合も同じです。

レッドチーミングでは、さらに注意が要ります。公式のデータの扱いの説明によれば、自前のモデルの鍵を設定していない既定の状態では、検査の問いの生成と採点に promptfoo 側の推論の仕組みが使われます。生成のためには、設定に書いたアプリの目的、検査の設定、利用者のメールアドレス、入力欄に入れた対象への接続の情報が送られ、採点のためには、対象に送った問いと対象の答え、採点の基準が送られます。

一方で、手元の環境変数に置いたモデルの鍵や、プロンプトに含めない手元のファイルは、既定では送られないとされています。自前のモデルの鍵や別の採点役を設定すれば、promptfoo 側に届くのは通常は利用状況の記録だけになる、という説明です。ただし、一部の検査の項目は promptfoo 側の推論でしか動かず、手元で完結させる設定もネットワークの隔離を保証するものではないと明記されています。入力欄に本物の接続の秘密情報を入れないことも、公式が注意している点です。

利用状況の記録（テレメトリ）も既定で送られます。公式によれば、実行した命令の種類、使った条件の種類、版、CI上での実行かどうか、などで、プロンプト・答え・試験の問題・鍵は含まれず、環境変数で止められます。標準にするなら、どの設定で使うかを情シスが決め、開発チームごとに選ばせないのが安全です。外部に何も出したくない場合は、ネットワークの中で動かす企業向けの提供形態があると公式は説明しています。

結果の保管。何を、何年、誰が見られる場所に残すか

検査の結果は、アプリを出したあとで「出す前に何を確かめたのか」を問われたときの証拠になります。問い合わせや事故の調査で求められるのは、合格率の数字だけではありません。どの問題を、どの版のアプリとモデルに投げ、どの条件で、誰が合格と判断したか、の一式です。

残すものとしては、試験の問題の束の版、合格の条件と重み、しきい値、対象のアプリとモデルの版、採点役のモデル、実行日、結果の一覧、出すと判断した人と日付、が最低限になります。問題の束を差し替えたときも、古い束は消さずに残します。消すと、古い結果と比べられなくなるからです。

結果の中には、問題とアプリの答えがそのまま入ります。問題に業務の記録を使っていれば、伏せたつもりの情報が残っていることもあります。結果の保管場所は、アプリの利用記録と同じ重さで扱い、閲覧できる人を絞ります。開発者の手元のパソコンに結果を置いたままにしないことも、決めておきます。

保管の期間は、アプリの利用を続けている間と、廃止後の一定の期間、というように、社内の記録の規程に合わせて決めます。道具の側の保存の機能に頼るより、社内の記録の置き場に書き出しておく方が、道具を替えたときにも困りません。

検査する道具の提供元が、モデルの提供元にもなった

promptfoo が OpenAI に加わったことで、検査する道具の提供元と、検査の対象になりうるモデルの提供元が同じ会社になりました。社内の標準を選ぶ立場では、これを批判の材料にするのではなく、判断材料の1つとして冷静に扱うのが妥当です。

確かめられている事実を整理すると、公式の発表は、多様な提供元とモデルへの対応を続けること、オープンソースのまま維持すること、を約束しています。道具はMITライセンスで、中身は誰でも読めます。採点の条件も合格線も、使う側が設定ファイルに書くものです。

そのうえで、標準にするなら次の3点を自社で押さえておきます。他社のモデルを使うアプリも同じ条件で検査できているか。採点役のモデルを特定の提供元に固定していないか。検査の基準そのものを、道具の既定値ではなく自社の文書に持っているか。この3点が守られていれば、道具の提供元が誰であっても、検査の中立は自社の側で担保できます。

経営や監査に説明するときも、どの道具を使ったかより、どの基準で誰が判断したかを前に出します。道具の提供元について質問が来たときに、基準が自社の文書にあることを示せれば、議論は短く済みます。

提供元が変わったときの備え

道具の提供元の体制は、今後も変わりえます。今回のように買収で変わることもあれば、オープンソースの開発の勢いが落ちることもあります。標準にした道具が使えなくなっても検査が止まらないように、乗り換えの備えを最初から持っておきます。

備えの中心は、試験の問題の束と合格の条件を、道具の書式に閉じ込めないことです。問題、期待する答えの性質、判定の条件、重みを、表計算や社内の文書の形でも持っておけば、別の道具に移すときは書式の変換だけで済みます。

道具の更新の追い方も決めておきます。公式GitHubの新しい版の公開、ライセンスの記載、説明文の告知を、担当を決めて定期的に確かめます。ライセンスや提供条件の変更に気づくのが遅れることが、乗り換えの準備で一番困る事態です。見直しの目安は、ライセンスが変わったとき、更新が長く止まったとき、自社で使うモデルへの対応が外れたとき、データの扱いの説明が変わったとき、の4つにしておきます。

標準にしたあとで見かける、備えのない状態の例を挙げておきます。

• 開発チームごとに道具の設定を任せ、合格線とその理由が文書に残っていない
• 試験の問題を道具の書式だけで持ち、ほかの形で残していない
• 採点役のモデルを1社に固定し、変えたときの点数のずれを記録していない
• 既定の設定のままレッドチーミングを回し、何が外部に送られたかを誰も把握していない

出す前の検査項目

ここまでの決めごとを、出す前に確かめる項目として1枚にまとめます。標準の文に添付し、アプリを公開するたびに責任者が確認する形で使います。

項目	確かめること	道具で担えること	人が決めること
試験の問題	実際の業務の質問から選んだ束か。誤答の報告を足したか	問題を順に投げ、結果を一覧にする	どの問題を入れるか・外すか
機械で判定する条件	出典の有無・使わない語・形式・応答時間・費用	決まった規則で毎回同じに判定する	どの条件を必須にするか
モデルの採点	観点が業務の言葉で書かれているか。人の採点と突き合わせたか	採点役のモデルで採点する	採点役の点を合格線に使うか
合格線	群ごとの合格の割合と、1件でも出さない条件	重みとしきい値で合否を出す	何割なら出すか
レッドチーミング	必ず見る領域と、実施の許可	決めた領域の問いで検査する	対象と範囲・実施の許可
外に出る情報	既定の設定で送られる情報を把握したか	設定で送り先を変えられる	どの設定で使うか
結果の保管	版・条件・結果・判断者を残したか	結果を一覧として書き出す	保管場所と期間・閲覧者
出すかどうか	上の項目がそろっているか	担えない	公開の可否

表の右端の列は、どの行でも空になりません。道具を標準にしても、人が決める列は1つも消えないということです。その列に担当者の名前が入っていることが、検査が標準として回っている印になります。

この表は、最初から全項目を埋める必要はありません。最初のアプリでは機械で判定する条件と合格線だけを決め、2本目以降でモデルの採点とレッドチーミングを足していく、というように段階を踏む方が定着します。いきなり全項目を必須にすると、検査を飛ばす例外の申請が増えます。例外が増えたら、項目を減らすのではなく、問題の束の大きさと回す頻度を見直します。

まとめ

promptfoo は、生成AIのアプリの答えを試験の問題と合格の条件で検査し、モデルの比較やレッドチーミングまでこなすオープンソースの道具です。2026年10月時点では OpenAI の一部となり、MITライセンスのまま更新が続いています。社内の検査の標準にするかどうかは、道具の機能より先に、検査の項目、試験の問題の集め方、合格線の決め方、回す時機、外に出る情報、結果の保管、提供元の変化への備え、の持ち主を決められるかで判断します。採点の一部はAIに任せてよくても、試験の問題を選ぶのも、合格線を決めるのも、出すかどうかを判断するのも人です。まずは社内で一番使われている生成AIのアプリを1つ選び、実際に来た質問から試験の問題を20問ほど選ぶところから始めてみてください。

• 製品の機能・ライセンス・データの扱いは、promptfoo の公式GitHub、公式ブログ、公式ドキュメントを2026年10月14日に確かめた範囲に基づきます。買収後の提供条件は変わることがあるため、利用前に最新の原文を確かめてください
• レッドチーミングは、自社が管理し、書面で実施の許可を得た対象にだけ行ってください。具体的な進め方は、社内の情報セキュリティの担当者と決めてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。