Codex use case
AI アプリケーションへの評価テストの追加
Codex を使って、期待する動作を検証する Promptfoo 評価スイートを作成します。
AI アプリケーションを調べて評価対象の動作を特定し、実行可能な Promptfoo 評価スイートを追加するよう Codex に依頼します。
Best for
- プロンプト、モデル呼び出し、ツール、検索機能、エージェント、製品要件のいずれかがすでにあり、繰り返し実行できる評価スイートがまだない AI アプリケーション
- モデル、プロンプト、検索処理、エージェントのいずれかの変更を予定しており、pull request のマージ前に回帰テストを実行したいチーム
- 毎回手作業で確認している項目を評価ケースとしてリポジトリにコミットする必要がある品質レビュー
Contents
AI アプリケーションへの評価テストの追加
Codex を使って、期待する動作を検証する Promptfoo 評価スイートを作成します。
AI アプリケーションを調べて評価対象の動作を特定し、実行可能な Promptfoo 評価スイートを追加するよう Codex に依頼します。
AI アプリケーションを調べて評価対象の動作を特定し、実行可能な Promptfoo 評価スイートを追加するよう Codex に依頼します。
Related links
Best for
- プロンプト、モデル呼び出し、ツール、検索機能、エージェント、製品要件のいずれかがすでにあり、繰り返し実行できる評価スイートがまだない AI アプリケーション
- モデル、プロンプト、検索処理、エージェントのいずれかの変更を予定しており、pull request のマージ前に回帰テストを実行したいチーム
- 毎回手作業で確認している項目を評価ケースとしてリポジトリにコミットする必要がある品質レビュー
Skills & Plugins
- 評価スイートの作成、評価対象への接続、実行、品質確認に使う `$promptfoo-evals` と `$promptfoo-provider-setup` を含むプラグイン
| Skill | Why use it |
|---|---|
| Promptfoo | 評価スイートの作成、評価対象への接続、実行、品質確認に使う `$promptfoo-evals` と `$promptfoo-provider-setup` を含むプラグイン |
Starter prompt
はじめに
AI アプリを新しく開発するときも、既存のアプリを変更するときも、期待どおりに動作するかを確認する必要があります。評価テストを使うと、一連のシナリオを体系的に検証し、リリース前にリグレッションを検出できます。
AI アプリの評価テストは Promptfoo で実行できます。テストの作成や保守には Codex を活用できます。
使い方
Codex で Promptfoo プラグインの $promptfoo-evals スキルを使うと、AI アプリの動作を 1 つ選び、繰り返し検証できる評価スイートを作成できます。Promptfoo からアプリを呼び出せる状態になっていない場合は、$promptfoo-provider-setup を使って、テストしたい処理経路にスイートを接続できます。
Codex はアプリの実装を調べ、不具合を見つけやすいテストケースを提案し、Promptfoo の設定とテストデータを追加できます。さらに、スイートをローカルで実行し、次回以降も使えるコマンドを提示できます。
この方法は、評価したい動作が具体的な場合に特に適しています。たとえば、サポート回答の品質、検索結果に基づくグラウンディング、分類器が出力するラベル、ツール呼び出し、JSON の構造、ビジネスルールの遵守、プロンプトやモデルの移行後も期待どおりに動作するかどうかなどです。
最初の実装では、コードとテストデータをレビューできる形にまとめます。具体的には、promptfooconfig.yaml または同等の設定ファイル、小規模な evals/ ディレクトリ、テストケース、アプリの呼び出しに必要なアダプター、npm run evals などのローカル実行用コマンドを用意します。
評価対象の選定
まず、ユーザーに対してアプリが保証する動作を 1 つ選びます。AI システム全体を一度に評価するよう Codex に依頼するのは避けてください。小規模なスイートなら結果を信頼しやすく、レビューや継続的な実行も容易です。
最初の評価対象には、次のようなものが適しています。
- 正確性: 分類、抽出、要約、ルーティング、変換の正確さ
- グラウンディング: 回答が検索で取得した文書や引用元の情報に基づいているか
- ツールの使用: 適切なツールを選択し、有効な引数を渡し、ツールのエラーを処理できるか
- 形式やビジネスルール: JSON スキーマ、フィールド名、ビジネスルールで定めた制限、UI に表示する文言の仕様を守っているか
- プロンプトやモデルの移行: プロンプト、モデル、システムメッセージ、検索設定を変更しても、重要なケースが期待どおりに動作するか
製品要件、バグ報告、サポートからエスカレーションされた案件、または機密情報を取り除き、チームが安心してリポジトリにコミットできる事例を出発点にします。
評価計画の依頼
Codex には、ファイルを編集する前にアプリの実装を調べてもらいます。対象の処理経路、フィクスチャ、アサーション、アダプター、実行コマンドを明記した計画を依頼してください。ファイルが追加される前に、評価対象の取り違えや、検証として不十分なテストケースに気づけます。
実装前に計画をレビューします。Promptfoo が呼び出すアプリの処理経路またはエンドポイント、最初に用意するテストケース、アサーション、Codex が作成するファイル、ローカル実行用コマンド、必要なシークレットやサービスが明記されているかを確認してください。ユーザーが実際に使うアプリの処理経路を通さず、モデルを直接テストする計画になっている場合は、それが意図したものか Codex に確認します。
実装、実行、改善
計画に問題がなければ、Codex に実装を依頼します。最初の実装はシンプルにまとめます。設定、テストケース、フィクスチャ、必要に応じて対象アプリを呼び出すアダプター、実行コマンドを用意し、そのコマンドを実際に実行したことがわかる結果を残します。
アプリを呼び出す小規模なスイートの構成例を示します。
evals/
promptfooconfig.yaml
tests/
cases.yaml
providers/
provider.js # only if the built-in provider cannot call the app directly
アプリの動作を変更する前にスイートを実行します。この時点での結果を基準にすると、現状のアプリがすでにテストに失敗しているのか、アサーションの調整が必要なのか、アプリを呼び出すアダプターに問題があるのかを判断できます。アサーションが些細な違いで失敗したり、判定条件が曖昧だったりする場合は調整してください。その際、製品の実際の不具合は引き続き検出できるようにします。
初回の実行後は、リリース前にスイートを使ってアプリの変更前後の動作を比較します。バグやリリース要件、製品レビューを通じて、今後も維持したい動作が明らかになったら、その都度テストケースを追加します。ローカル実行用コマンドが安定して動作するようになったら、CI またはリリース時のチェックリストに追加するよう Codex に依頼します。
Related use cases
API 連携のアップグレード
Codex を使って、既存の OpenAI API 連携を最新の推奨モデルと API 機能に対応させ、リリース前に既存の動作に問題が生じていないか確認します。
未対応の脆弱性の修正
チケット管理ツールや脆弱性報告システムから承認済みの指摘を取り込みます。Codex Security プラグインで指摘を 1...
インシデントの調査と修正の検証
機密情報を取り除いたインシデントの調査資料と、テストを実行できる環境を Codex Cloud に渡します。Codex Cloud...