Keep Working事例：ブラインド評価に勝ったカードだけを配る、ワンボタンのプロンプトデッキ

Keep Workingは「送信ボタンの隣にあってほしかったボタン」です。長いLLMセッションの47分目、モデルにもうひと押し必要なのは分かっているのに、良いプロンプトを考える気力が残っていない。Keep Workingはそれをカードとして差し出します。Spaceで次のプロンプト、Sで同じカテゴリーの一段鋭い版、Cでコピー、Fでカードを裏返して「なぜこのプロンプトが効くのか」の解説。すべてのカードに共有可能なパーマリンクがあり、最初のカードはサーバーサイドでレンダリングされるため、ページは最初の描画から使い物になります。

ライブ版はこちらで公開しています：keepworking.urbanodx.com

品質基準：出荷の前に評価

デッキは見た目より小さく作ってあります。意図的にです。デッキは2つの階層で構成されています。

コア：4カテゴリー、約86プロンプト。 すべてのコアカテゴリーは、「本当に合っていますか？」と「直前の回答の誤りを見直してください」という2つのベースラインに対し、3つの独立したモデルが審査するブラインド対決で勝っています。判定の総数は184件です。

実験枠：12カテゴリー、約275プロンプト。 有望だが未検証、あるいは結果を悪化させると判明したもの。明示的なオプトインでのみ使えます。

デフォルトの抽選はコア階層だけを使います。実験枠からコアへの昇格には新しい評価が必須で、評価の履歴はリポジトリに残しています。デッキを一時的に悪化させたイテレーションも含めてです。このプロダクトの背景にある正直な発見はこうです。プロンプト術の大半は、ごく単純なベースラインとのブラインドテストに負ける。だからデフォルトのデッキには、合格したものしか入れない。

一つのデータセット、三つの接点

Keep Workingは小さなFastAPIサービスです。Webアプリ、JSON API、CLIがすべて同じプロンプトファイルを読むため、どの接点でも内容が常に一致します。ファイルはコンテナに読み取り専用でマウントされており、再ビルドなしでデッキを差し替えられます。対話型のAPIドキュメントは/docsに標準搭載で、/healthはプロンプト数とカテゴリー数を返すため、死活監視にそのまま使えます。

この事例が示すこと

最小スケールでの評価規律。 クライアントのAIワークフローに適用しているのと同じ評価セットの考え方です。ブラインドテストでベースラインに勝てないパターンは、デフォルトとして出荷しない。ワークフロー版の話はAIワークフローにおける人のレビューに書きました。

APIファーストのプロダクト設計。 一つの正規データセットがWeb UI、ドキュメント付きJSON API、CLIに供給され、初日からヘルスレポートを備えています。

小ささは出荷可能性。 正直な評価を通ったワンボタンのプロダクトは、誰もテストしていない巨大なプロンプト集より役に立ちます。

この規律をあなたのAIワークフローに適用するのが、まさに私たちの仕事です。固定スコープのAI Workflow Teardownは、何かを作り始める前に、あなたのプロセスのどのステップがブラインド評価を生き残るかを教えてくれます。