あなたは「あらゆる方法」を試した。ただ一つを除いて。
あなたがすでに試してきたことを、簡単におさらいしよう。
プロンプトを書き直した。3回、4回。例を追加した。ペルソナを設定した。「禁止事項」リストを何マイルも書いた。
フロンティアモデルにアップグレードした。トークン単価は5倍になった。出力はより自信満々になったが、薄っぺらさは変わらなかった。
メモリをオンにした。コンテキストファイルを作った。ブランドボイス、過去の作品、スタイルガイドを与えた。
そして、その施策のひとつひとつが、数回の良い生成をもたらした後、また粗悪な出力が忍び寄ってくる。
それらはすべて 入力側 の修正だ。生成するものを研ぎ澄まし続けているが、キャッチするべきものを無視している。暗闇に向かって放った高性能な銃は、やはり何も撃ち抜けない。
粗悪な出力は 出力側 の問題だ。モデルが良い仕事を生み出せないわけではない。重要な誰かの目に触れる前に、良い仕事と悪い仕事を見分ける方法がないのだ。
評価ループ（eval loop）がない。品質ベンチマークがない。スコアボードがない。だから、手探りで調整しているだけだ。プロンプトを変えて、「良くなった気がする」。でも、感覚は測定ではない。感覚では、次の50回の生成のどこかに潜む悪い実行をキャッチできない。
だから、自分を責める。プロンプトを責める。エージェントの設定を責める。コンテキストエンジニアリングを責める。足りないのは、AI と働くための層全体であり、あなたはそれを教わったことがなかったのだ。この記事を読み終える頃には、その層があなた自身のマシン上で、Hermes の中で動いているだろう。
なぜ、より良いプロンプトでは修正できないのか（そしてなぜ皆がそれでも試し続けるのか）
プロンプトは仮説であり、出力はその結果だ。そして、評価（eval）こそが、そのループを閉じる唯一のものだ。
そのループがなければ、あなたは永遠に推測し続けることになる。仮説を微調整し、一つの結果を目視で確認し、勝利を宣言する。そして、同じプロンプトが30％の確率で粗悪な出力を生み出していることに永遠に気づかない。なぜなら、あなたは目の前のたった一つの出力しか見ていないからだ。
モデルは非決定的（non-deterministic）だ。同じプロンプトを2回実行すれば、2つの異なる答えが返ってくる。つまり、完璧なプロンプトでさえ、ある割合で粗悪な出力を生み出す。そして、クライアントやユーザーがそれを目にするまで、どの実行が悪いのかあなたにはわからない。
だから、完璧なプロンプトは品質の保証ではなく、ほんの少し確率の高いコイン投げに過ぎない。そして、あなたはそのすべての結果を出荷している。
それでも皆がプロンプトに手を伸ばし続ける理由は単純だ。プロンプトは、あなたが実際に見ることのできる唯一のレバーだからだ。編集できる。そして、編集することは コントロールしているように感じさせる。
測定は目に見えない。誰もそれについてのコースを売ってくれない。誰も「私の出力を10倍にした評価スイート」というバイラルスレッドを投稿しない。だから、会話全体が、それだけでは問題を解決できない一つのレバーに固執し続ける。
AI 出力が一貫してクリーンな人々は、あなたよりプロンプトが上手いわけではない。彼らはあなたが持っていない第二のレバーを持っているだけだ。彼らは、出荷前にすべての出力を基準に対して測定している。そして、その測定こそが、彼らのプロンプトを魔法のように見せているのだ。
粗悪な出力が潜む2つの場所
粗悪な出力は、正確に2つの場所に潜む。そして、ほとんどの人はそのうちの1つしか見ていない。
場所1：あなたのコンテンツ出力
ツイート、記事、メール、ランディングページ、投稿。AI で生成し、自分の名前で公開するすべてのもの。
ここでの粗悪な出力は、技術的には問題がなく、完全に中身が空洞な作品のように見える。そして、タイムライン上の他のすべての AI アカウントと同じように聞こえる。外見は正しいが、内面は空虚だ。
それは公共の場で死んでいくが、なぜかは説明できない。なぜなら、送信ボタンを押したとき、個々の作品はどれも問題なさそうに見えたからだ。
場所2：あなたのプロダクト出力
あなたが出荷した AI 機能、エージェント、チャットボット、サポート応答システム、抽出パイプライン。ユーザーが実際に触れるものだ。
ここでの粗悪な出力は、絶対的な自信を持って間違った答えを返すことのように見える。幻覚を見た数字、壊れた JSON ペイロード、ブランドと合わないトーン、デモでは素晴らしかったのに、3回のデプロイ後には静かに劣化した出力。
それは公共の場で死ぬのではなく、静かに拡大する。すべてのユーザーは少しずつ悪い体験を受け取り、そのほとんどは決してあなたに伝えない。ただ去っていくだけだ。
これらは、同じ治療法を持つ同じ病気だ。
コンテンツの粗悪な出力とプロダクトの粗悪な出力は、どちらも 評価されていない AI 出力が、何のゲートもなしに直接オーディエンスに届いている 状態だ。
唯一の違いは、結果の重大さと可視性だ。コンテンツの粗悪な出力はあなたを大声で恥ずかしめ、プロダクトの粗悪な出力は静かにあなたを蝕む。そして、私たちが Hermes で構築するループは、両方を同じスキルで評価する。だから、あなたは生成するすべてのものに対して、2つではなく1つの品質システムを運用できる。
評価ループとは実際には何か
評価ループ（eval loop）とは、繰り返し可能なテストであり、AI 出力を基準に対して自動的に、毎回、出荷前と出荷後にスコアリングするものだ。
それだけだ。これがすべてだ。そして、これこそが、AI を使って構築するほとんど誰も持っていない層なのだ。
出力を生成する
定義したベンチマークに対してスコアリングする
基準を下回る実行をキャッチする
失敗しているものを修正する
再スコアリングし、合格した出力だけを通す
ソフトウェアエンジニアはこれをずっと持っていた。それはテストと呼ばれる。テストなしでコードを出荷し、本番環境で動くことを「願う」ようなことは決してしない。しかし、今の AI 業界全体がまさにその方法で AI 出力を出荷している。モデルからユーザーへ、雰囲気と祈りだけで。
ほとんど誰も評価ループを持っていない理由は、人口統計的なものだ。今日 AI を使って構築している人々は、コンテンツ、営業、プロダクト、ファウンダーの出身であり、エンジニアリング出身ではない。だから、「出力のテストを書く」という発想は、彼らのツールキットの中に一度もなかったのだ。評価は「本物の」エンジニアのためのインフラとして読まれ、それを最も必要とする人々は、それを欲しがる資格がないと思い込んでいる。
これを、非決定的なものに対するユニットテストと考えてほしい。コードが実行されるかどうかをテストするのではなく、出力が良いかどうか をテストするのだ。そして、悪い実行が一つ紛れ込んでも隠れられないように、十分なケースに対してテストする。
評価ループは3つの場所で実行される。そして、これから行う構築は、その3つすべてに配置する。
- 出荷前：新しいプロンプトやモデルを、保存されたテストケースのセットに対して実行し、悪化していないことを確認する。これは回帰テストであり、ある問題を修正した変更が、静かに他の3つの問題を壊していないかを確認する方法だ。
- 実行時：出力が生成されると同時にスコアリングし、条件付きロジックでユーザーに届く前に失敗をキャッチする。これがガードレールだ。
- 本番環境：実際の実行のサンプルを継続的にスコアリングし、クライアントが苦情を言う1週間前ではなく、品質が劣化し始めたその日にそれを確認できるようにする。
最初の一つはスプレッドシートで立ち上げることができる。しかし、これが第二の仕事にならないように3つすべてを継続的に実行することが、これをエージェントの中に組み込む理由のすべてだ。
品質が数値になった瞬間、粗悪な出力はあなたが感じ続ける感情から、あなたが修正できるバグへと変わる。雰囲気をデバッグすることはできない。0.82 から 0.61 に下がったスコアをデバッグすることはできる。
ベンチマーク：あなたがこれから構築する3つの構成要素
ベンチマークには3つの構成要素がある。コンテンツを評価する場合も、プロダクトを評価する場合も、それらは同じ3つだ。
テストケース：良い出力がどのようなものか（あなたのグラウンドトゥルース）とペアになった実際の入力
指標：出力をスコア（理想的には0から1）に変換する方法
しきい値：これを下回るものは何も出荷しないという線
これら3つを構築すれば、あなたは品質ゲートを持つことになる。どれか一つでも欠ければ、あなたは願望を持っているに過ぎない。このセクションの残りでは、各構成要素の中身について説明する。その後、3つすべてを Hermes に配線する。
コンテンツの場合、テストケースはあなたのゴールドスタンダードだ
あなたの最高の作品を20～50個ピックアップしよう。バンガー（傑作）、ブックマークされた投稿、あなたの名前をすべて賭けてもいいと思う記事。これが「良い」の定義だ。あなたは基準を発明しているのではなく、最高の日に既に達成している基準を抽出しているのだ。
コンテンツの場合、指標はルーブリック（評価基準表）だ
スコアは、その背後にあるルーブリックと同じくらいの価値しかない。だから、何が作品を良いものにしているのか、あなたが実際に信じていることをエンコードしよう。私がコンテンツを評価する際は、4つの基準を使っている。
- 具体的 な何かのやり方を説明している。雰囲気ではなく、読者が明日実行できるアクションである。
- オーディエンスの誰でも理解できる。専門用語の壁がない。内輪の話題がない。
- 構造化され、再現可能で、ステップバイステップである。ただのインスピレーションではない。
- 斬新である。読者は、こんなことができるとは知らなかった。
これら4つの基準の上にあるメタ基準はこれだ。誰かがこれをブックマークして、後で実装しに戻ってくるだろうか？ 答えが「いいえ」なら、たとえ文章がどんなにきれいでも、それは粗悪な出力だ。
秘訣はルーブリックにある。曖昧なルーブリック（「これは良くて魅力的か」）は、曖昧なスコアを生み出す。具体的なルーブリック（「これはコピペ可能なテンプレートやプレイブックを少なくとも一つ含んでいるか」）は、信頼できるスコアを生み出す。判定役（ジャッジ）は、あなたが自分の好みを実際に書き留めた場合にのみ、あなたのセンスを受け継ぐ。
プロダクトの場合、テストケースはログから取得する
あなたの機能が実際に目にする入力を、ログから取得しよう。実際のユーザーセッションからだ。ローンチ日にテストした3つのハッピーパスの例ではない。あなたを困らせるのは変なケースであり、変なケースはログの中にいる。
プロダクトの場合、指標はタスクに一致させる
入力ごとに、正しい出力がどのようなものかを定義する。そして、指標をタスクに一致させる。正しいラベルが一つだけある場合は完全一致、構造が維持されなければならない場合はバリデーター、出力がオープンエンドの場合は意味的類似性と判定役（ジャッジ）を組み合わせる。指標が返すのは数値でなければならない。なぜなら、しきい値を設定できるのは数値だけだからだ。
どちらの場合も、しきい値はあなたが守る線である
0.7 は合理的な開始点だ。0.7 未満のものは、出荷前に作り直すか破棄する。例外はない。しきい値は、あなたが気に入ったからといって0.6を通すことを決して許さない場合にのみ機能する。このすべてのポイントは、深夜の ego による決断を排除することにある。
これがベンチマークだ。では、これを自動で実行できるようにしよう。
Hermes 内部にループを構築する
Hermes には、評価ボタンはない。「粗悪な出力から保護する」をクリックする「品質」というダッシュボードもない。
Hermes が代わりに提供するものは、それよりも優れている。評価ループの生の構成要素であり、あなたが一度組み立てれば、それを所有することになるプリミティブだ。
自分で書いて再利用するスキル、セッションを超えて成長する永続的なメモリ、任意のプラットフォームに配信する組み込みの cron、Slack 内の承認ボタン、そしてコアに組み込まれた自己改善の習慣。
Hermes は自らを「あなたと共に成長するエージェント」と呼び、その成長こそがまさに私たちが構築しようとしているループなのだ。
では、配線しよう。6つのムーブだ。
ムーブ1：Hermes をあなたに届く場所に立てる
インストールして、Telegram に接続する。これは聞こえ以上に重要だ。なぜなら、ゲートはあなたに割り込める場合にのみ機能するからだ。Hermes は20以上のチャンネルで動作し、Slack と Telegram にネイティブの承認ボタンを出荷する。これにより、エージェントはバックグラウンドで作業を行い、あなたの判断が必要な時にあなたの肩を軽く叩くことができる。
ムーブ2：ゴールドスタンダードをメモリにロードする
Hermes は、セッションを超えて成長し、完全なクロスセッション呼び出しが可能な永続的なメモリを持つ。だから、ベンチマークからの20～50の最高の作品は、一度そこに入れれば、そこに留まる。これは通常、スクリーンショットや古い下書きに散らばっている部分だ。ここでは、エージェントの長期記憶となり、クエリ可能で、あなたのスコアが測定されるグラウンドトゥルースとなる。
ムーブ3：ルーブリックをジャッジスキルに変える
これが核心だ。あなたは Hermes に一度、平易な英語で伝える。出力とあなたのルーブリックを受け取り、基準ごとに0から1のスコアと一行の理由を返すスキルを作成するように。これが LLM-as-a-judge だ。エージェントがあなたの LLM を評価する。そして、鋭いルーブリックを持つモデルは、あなたよりも一貫性のある批評家になる。なぜなら、その作品に対する ego がなく、あなたが密かに誇りに思っている一文に執着することがないからだ。
これが一回きりのプロンプトではなく、スキルとして存在する理由は、Hermes のスキルが手続き的記憶だからだ。エージェントはそれを書き、保持し、再利用する。あなたは自分の好みを一度エンコードすれば、それが永遠にすべての出力を評価する。そして、スキルは複利的に効果を発揮する。Nous は、20以上の自己作成スキルを持つエージェントが、同様のタスクを40％速く完了することを発見した。なぜなら、プロセスを再発見する必要がなくなるからだ。あなたのジャッジは、実行すればするほど賢くなる。
ムーブ4：スイートをスプレッドシートではなくスキルにする
あなたのテストケースと指標関数は、Hermes が保持しバージョン管理するスキルになる。指標ライブラリは、タスクが必要とするものなら何でも良い。分類のための完全一致、抽出のための正規表現、構造のための JSON とキー・バリューバリデーター、生成出力のための意味的類似性。
オープンエンドなもののためのあなたのジャッジスキル。Hermes はスコアリングコード自体を書く。あなたがタスクを説明すれば、エージェントが指標を構築する。これらすべては、あなたがなくしてしまうようなシートではなく、エージェントが所有する一箇所に置かれる。
ムーブ5：回帰テストと承認ボタンで出荷をゲートする
これはシステム全体の中で最もレバレッジの効く習慣であり、手動で続けられる人は誰もいない。だから、それをエージェントに任せる。新しいプロンプト、モデルの変更、パイプラインの微調整など、あらゆる変更がスイートをトリガーするように配線する。Hermes はすべてのケースを再実行し、ベースラインに対するスコアの差分を計算し、静かに出荷する代わりに Slack であなたに ping を送る。「スコアが 0.81 から 0.74 に下がりました。2つのケースで回帰が発生しました。承認しますか？」そして、あなたがボタンをタップした場合にのみ進む。
/goal を使えば、それをそのジョブに固定できる。/goal は、ターンをまたいでエージェントを目標に拘束する。そして、より大きなものについては、マルチエージェントかんばんが実行を分解し、並列でスコアリングし、スケジュールすることができる。これにより、ゲートはあなたが実行することを覚えておく必要のあるものではなく、恒常的なプロセスとなる。
ムーブ6：cron で本番環境を監視し、ループを閉じる
Hermes は、任意のプラットフォームに配信する組み込みの cron を持つ。そこで、実際の実行をサンプリングし、同じジャッジスキルでスコアリングし、ラインが下がった瞬間にあなたに DM を送るジョブをスケジュールする。クライアントが苦情を言う1週間前ではなく、劣化が始まったその日にそれをキャッチできる。「評価スコアが下がった」は、あなたが行動を起こせる問題だ。「顧客がイライラしているようだった」は、そうではない。
そして、すべてを複利的にする部分がある。Slack で悪い出力に「よくない」のサムズダウンを付けると、Hermes はそれをスイートスキルに新しいテストケースとして書き戻す。その失敗した実行は、恒久的なチェックになる。そして、自己改善は Hermes の本質であり、後付けの機能ではないため、スイートは毎週自動的に強化される。あなたが眠っている間に、品質の底上げが行われる。
これが実行されると、良い状態は具体的にどのように見えるか。ルーブリックで0.7未満のコンテンツ作品は決して出荷されない。ベースラインを下回る指標を生み出すプロダクトの変更は、あなたが承認するまでデプロイをブロックする。そして、本番環境のスコアラインは横ばいか上昇を続ける。ラインが下がった日は、チャーンが顕在化する週ではなく、Hermes があなたに ping を送る日だ。
誰も聞きたがらない部分
あなたの AI 出力が一貫していない理由は、あなたがプロンプトを書くのが下手だからではない。モデルがまだ十分に賢くないからでもない。
それは、あなたが品質ステップなしで生成ステップを実行しているからだ。あなたはシステムの半分を構築し、うまく機能している半分を責めている。
修正方法は、より良いプロンプトではない。欠けている層だ。「良い」の定義をし、それを数値に変え、すべての出力をそれに対してスコアリングし、基準を下回るものをすべてゲートし、ループを閉じて毎週底上げを行う。そして今、その層は「いつかやるプロジェクト」ではない。あなた自身のマシンで動くエージェントの中での、たった6つのムーブなのだ。
それを実行すれば、粗悪な出力は、あなたにランダムに降りかかるものではなくなり、あなたが玄関先で毎回キャッチするものになる。まるで本物の工場が、欠陥品が顧客に届く前にキャッチするのと同じだ。
プロンプトは決してシステムではなかった。
評価ループこそがシステムであり、Hermes はそれが実行される場所だ。そして今、あなたはそれを手に入れた。
