Anthropic のあるクライアントは、たった 1 つのポジションに対して 24 時間で 2,740 件の応募を受け取りました。
手書きのプロンプトでは、そんな長期間は正しく機能し続けられません。
応募書類に目を通す採用担当者は、「バックエンド 5 年、スタートアップ経験、Python に強い」というプロンプトから始めます。
ところが 2 日後、最初のバッチを確認した彼らは、実際にはゼロから製品を作り上げた人材を求めていることに気づきます。
プロンプトはすでに時代遅れで、まだ 2 番目の 100 件すら読んでいないのです。
最も速く製品をリリースするチームは、そのようなプロンプトの書き方をやめました。
彼らは、ユーザーが実際に下す判断をプロンプトが監視し、背景で自動的に書き換わるシステムを構築したのです。
ユーザーが自分の選好が変わったことに気づく頃には、プロンプトもそれに合わせてすでに変わっています。
これは、人間が価値判断を下し、モデルがそれを支援するあらゆる場面で機能します。
採用、サポートのトリアージ、コンテンツモデレーション、コードレビュー、案件評価などです。
以下に、その構築方法を段階的に説明します。
プロンプトは設定ファイルではなく、見習いである
まず、皆さんの考え方を変える必要があります。
設定ファイルというのは、一度設定したらあとは放っておくものです。
一方、見習いはあなたの仕事ぶりを観察し、あなたが実際に何を重視しているかを理解し、調整します。
あなたのプロンプトは後者であるべきです。
Nick Mayhew が Anthropic のステージで披露したシステムでは、見習いは単なる Markdown ファイルです。
彼らはそれを「理想的な候補者プロフィール」と呼んでいます。
重み付けも、ルールも、フローチャートもありません。単に、採用担当者が誰を採用しようとしているのかを平易な英語で記述しているだけです。
採用担当者が候補者を承認または却下するたびに、システムはそれをログに記録します。
「この人は Python の経験が十分ではない」といったコメントもすべて保存されます。
プロフィールへの手動編集もすべて保存されます。
この判断結果の蓄積が、プロンプトが更新されるためのトレーニングシグナルとなります。
1 回の判断ではなく、100 回の判断が重要な理由
最初に思いつくのは、アクションがあるたびにプロンプトを更新することです。しかし、それは避けるべきです。
1 回の判断はノイズです。たった 1 回の却下では、ユーザーが本当に望んでいることはほとんどわかりません。原因は以下のいずれかである可能性があります。
- ユーザーが疲れていた、または気が散っていた
- 入力内容が、ユーザーの本当の選好とは無関係な点で特殊だった
- クリックを誤った
- 明白なケースを素早く処理した
- 意図的にシステムをテストしていた
こうした状況でプロンプトを書き換えると、幻影を追いかけることになります。
100 回の判断はシグナルです。
「ユーザーがスタートアップ経験のない候補者を次々と却下している」というパターンが見えてきます。
それは一時的な気分ではなく、選好です。これで初めて更新を行います。
Nick はステージでこの点を明確に述べていました。
パターンは、毎回のクリックではなく、100 ～ 200 回の判断ごとに見え始めるのです。
コスト面も重要です。
高性能なモデルをすべてのアクションで実行すると、予算はあっという間に消耗します。
バッチ単位で実行することで、システムを本番環境で稼働し続けられます。
システムを 1 つの大きなエージェントではなく、2 つの層に分割する
評価、学習、更新をすべて同時に行う巨大なエージェントを 1 つ作りたくなる誘惑にかられます。
しかし、それはスケールせず、持っていないトークンまで消費します。
実用的なパターンは、まったく異なる役割を持つ 2 つの層です。
下層は評価者です。安価で高速で、すべての入力に対して実行されます。
採用のケースでは、Haiku が現在のプロフィールと照らし合わせてすべての CV をスコアリングします。
1 日に何千件も処理します。狭い仕事です。入力を受け取り、現在のプロンプトを適用し、構造化された判定を返します。
上層は見習いです。より低速で、より高性能で、めったに実行されません。
人間が下した判断のみを監視します。
バッチごとに、次の 1 つの質問をします。「プロンプトは、ユーザーが実際に選択しているものとまだ一致しているか？」
もし一致していなければ、プロンプトを書き換えます。
ほとんどのチームはこの分割を省略します。
すべてのリクエストのホットパスにフロンティアモデルを置くため、コストが爆発的に増加し、システムは棚上げになります。
評価と学習を分割することが、システムを本番環境で存続させる鍵なのです。
プロンプトはルールではなく、散文で書く
ここで、ほとんどの自己改善システムは静かに消滅します。
設定ファイル（経験年数 30%、企業規模 20%、学歴 10%、キーワードフラグ）を書きたくなるのが本能です。
厳密に感じられます。しかし、モデルが実際に更新できないシステムを生み出します。更新できる数値以外に何もないからです。
そして、数値は採用担当者がなぜ「ノー」と言ったのかを捉えられません。
実用的な形式は、Markdown での平易な英語です。
「私たちは、製品をゼロから立ち上げた経験があり、理想的には 50 人未満のスタートアップで働いたことのある人材を求めています。」
「特定の技術スタックよりも、強力なエンジニアリング文化が重要です。」
「レッドフラグ：従業員数 1,000 人以上の企業でしか働いたことがない。」
これこそ、見習いが実際に書き換えられるプロンプトです。
文章を追加したり、削除したり、表現を調整したりできます。
重み付けされた採点基準表では、そのようなことはできません。
フィードバックループこそが製品そのものである
これら 4 つの要素が整えば、システムは自律的に動作します。
ユーザーが判断を下します。評価者が現在のプロンプトに基づいてスコアリングします。
100 回の判断ごとに、見習いが判断結果の蓄積を読み、プロンプトを書き換えます。
次のバッチの入力は、新しいバージョンのプロンプトに対して評価されます。
ユーザーはプロンプトについて考える必要はまったくありません。
人間にしかできない判断を下し続けるだけでいいのです。
プロンプトは背後で自動的に更新されます。
これこそ、多くのチームが Claude システムをリリースする際に見逃している部分です。
彼らはプロンプトを完成させるべき成果物として扱います。
最も多く製品をリリースするチームは、プロンプトを常に学習し続けるレイヤーとして扱います。
初日からこの方法で構築すれば、言葉の調整に何週間も費やすことはなくなります。
製品のリリースに時間を使えるのです。
フォローしていただき、私の Telegram チャンネルにご登録ください：
