JieGouは9部門向けスターターパックを出荷し、各パックに7-10レシピと2-5ワークフロー。合計約150レシピと40ワークフロー。各レシピを手書きし、リアルな入力でテストし、出力品質を評価し、出荷に十分な品質になるまでイテレーション — チームのフルタイムの仕事です。
より良いアプローチが必要でした。そこでRecipe Factoryを構築：テンプレートを大規模に生成、テスト、評価、プロモートする自動パイプラインです。
パイプライン
Recipe Factoryは5つのステージを実行：
1. カタログ → 生成
すべてのレシピはカタログ内の仕様から始まります：タイトル、説明、対象部門、期待される入力フィールド、期待される出力フィールド、品質基準。生成ステージは各仕様を取り、LLMを使用して完全なレシピを生成：洗練されたプロンプトテンプレート、詳細な入力スキーマ、構造化出力スキーマ。
2. 生成 → テストデータ
生成された各レシピに対し、2回目のLLMコールが3-5の合成テスト入力を生成。典型ケース、エッジケース（最小入力、異常に長い入力、曖昧な入力）、部門固有シナリオをカバー。
3. テストデータ → テスト実行
各レシピが合成テスト入力を使用して実際のLLMに対して実行。テンプレートでは問題なく見えるがランタイムで失敗する問題をキャッチ：スキーマ不一致、オフターゲット出力、コンテキスト制限超過。
4. テスト実行 → 評価
ここでLLM-as-judgeが登場。別のLLMが各テスト結果を5つの次元で評価：
- スキーマ準拠 — 出力が期待スキーマに一致するか
- 完全性 — 出力が入力のすべての側面に対応しているか
- アクション可能性 — 出力が有用か、追加作業なしで行動可能か
- フォーマット品質 — 整理され、明確に書かれ、適切な詳細度か
- 一貫性 — 複数テスト入力にわたり一貫した構造の出力か
各次元に0-100のスコア。全体スコアは加重平均。
5. 評価 → プロモート
全体75以上、各次元50以下なしのレシピがFirestoreのデモアカウントにプロモート。不合格レシピは手動レビューとイテレーションにフラグ。
LLM-as-Judgeから学んだこと
プロンプトの特異性は長さより重要。 短くより具体的なプロンプトが、スキーマ準拠とフォーマット品質で一貫して高スコア。何をすべきか正確に言う200語のプロンプトは、すべてのエッジケースをカバーする500語のプロンプトを上回ります。
出力スキーマが最も重要な品質レバー。 詳細な出力スキーマ — フィールド説明、enum制約、ネストされたオブジェクト構造 — を持つレシピが完全性と一貫性で有意に高スコア。
エッジケーステスト入力が脆弱性を明らかにする。 標準テストケースは通常動作します。エッジケース — 最小入力、異常なフォーマット、オプションフィールドの欠落 — が実世界条件で壊れるレシピを露出。
評価基準にはキャリブレーションが必要。 最初のパスは寛大すぎました。凡庸な出力のレシピが85+のスコア。各スコアレベルがどう見えるかの具体例で評価プロンプトを厳格化しました。
ユーザーにとっての意味
Recipe Factoryは内部ツールですが、効果はユーザー向けです。スターターパックのすべてのレシピは：
- 品質基準を定義する仕様から生成
- エッジケースを含むリアルな入力でテスト
- 5つの品質次元にわたるLLMジャッジによる評価
- 品質閾値を満たした場合のみプロモート
スターターパックをインストールする時、レシピは粗いドラフトではありません。最も一般的な問題をあなたに届く前にキャッチする自動品質パイプラインを通過しています。
とはいえ、出発点です。チーム固有の用語、品質基準、出力の好みはファクトリーが知り得ないものです。レシピはカスタマイズされるよう設計されています — ファクトリーが高いベースラインで開始することを保証するため、カスタマイズは修復ではなく改善になります。