朝起きたら、AIが夜のうちに仕事を終わらせてくれている。

副業でも自社の業務でも、AIエージェントに期待するのはこの状態のはずだ。ところが実際に自動実行を組むと、多くの人が同じ壁にぶつかる。「今日は完璧だったのに、昨日は使い物にならなかった」——結果が安定せず、毎朝の手直しが新しい仕事として増えていく。

私も同じ悩みを抱えていた。転機は、Anthropic Applied AIチームのエンジニアとの会話だ。彼らの答えは一言だった。

この記事では、evalsとは何か、そしてどんな業務に効くのかを、決裁者と副業実践者の両方がそのまま使える形で解説する。

そもそもevalsとは何か

evals（エバルス、evaluations）とは、一言でいえば**「AIの成果物を、世に出す前に自動で合否判定する仕組み」**だ。

人間の仕事に置き換えると分かりやすい。工場なら出荷前の検品、出版社なら校閲、採用なら筆記試験と面接。どの組織も「作る人」と「チェックする関門」を分けている。AIの自律運用に足りていないのは、まさにこの関門だ。

なぜ評価指標がそこまで重要なのか。理由は単純で、測れないものは改善できないからだ。

evalsがない状態を想像してほしい。AIの出力が「なんか今日はイマイチ」——でも何がどうイマイチなのか言語化できない。だからプロンプトを勘で書き換え、直ったのか悪化したのかも分からないまま、また明日を迎える。私の運用がまさにこれだった。

evalsがあると世界が変わる。「昨日は12本中10本合格、落ちた2本は文字数超過と数値の不一致」——ここまで分かれば、直すべき場所は明白だ。評価指標とは、AIへの不満を「改善タスク」に翻訳する装置なのだ。

あなたの業務なら、どこで効くか

抽象論の前に、まず「自分の場合」をイメージしてほしい。

副業・個人事業なら:

  • ブログ・note記事の毎朝自動生成 → 「タイトル32字以内」「一次情報へのリンク必須」を機械チェック
  • EC・物販の商品説明文の量産 → 「禁止ワードなし」「文字数」「価格表記の正確さ」を自動判定
  • SNS運用代行 → 「クライアントのNGトーンに触れていないか」をAI採点してから予約投稿

経営者・決裁者なら:

  • 日次売上レポートの自動作成 → 「数値がDBと一致しているか」を突合してからSlack配信
  • 問い合わせメールの一次返信ドラフト → 「値引きや納期の約束をしていないか」を検査してから担当者へ
  • 請求書・見積書のチェック → 「税率・合計・支払期日」の整合を検証

共通点が見えるだろうか。どれも「人間が毎回レビューしていたら自動化の意味がない」業務だ。そしてどれも、合否の基準を言語化できる。それがevalsになる。

evalsは3種類だけ覚えればいい

表：evalsの3層と判定方法

具体的に見てみよう。

①仕様書は「形式が正しいか」を見る。「文字数400〜800字」「成約率は0〜100%の範囲」「価格に必ず税込表記」。当たり前に見えるが、AIは平気で0.12を「12%」ではなく「120%」と書く日がある。

②ゴールデンテストは「答えが分かっている問題を解かせて採点」する。「6月10日のデータなら反響120件と出るはず」という過去問を数問用意し、毎回解かせる。ここが崩れたら、本番の答えも信用できない。

③ルーブリックは「文章の品質」のような、正解が一つに決まらない観点を扱う。「根拠なき断定がないか」「クライアントのNGトーンに触れていないか」を基準として文章化し、別のAIに採点させる。

ポイントは順番だ。①②の機械チェックで失敗の大半を無料同然で弾き、③のAI採点は曖昧な観点だけに使う。

図1：自律エージェントループにおけるevalsの位置づけ

evalsはループの「関所」として置く（図1）。合格した成果物だけを世に出し、不合格なら「どのテストが・なぜ落ちたか」を記録して次の実行に反映する。この瞬間、失敗は事故ではなく改善材料に変わる。

具体例：日次KPIレポートを無人で作らせる

ここからは実装イメージだ。題材は、データベースの反響・成約データから日次レポートを毎朝6時に自動生成し、Slackに投稿するエージェント。

①の仕様書はこれだけで効く。

output:
  required_fields:
    - date              # 実行日と一致すること
    - conversion_rate   # 0.0〜1.0の範囲
    - summary_md        # 400字以上800字以下
  invariants:
    - 成約率 = 成約数 ÷ 反響数（誤差なく一致）
    - 全数値はSQL集計値と突合して一致

②のゴールデンテストでは「反響ゼロの日曜」のような意地悪な入力を必ず入れる。導入前、AIはデータがない日にもっともらしい架空の数値を補完してくることがあった。これを検出できるのは機械テストだけだ。

③は採点基準を明文化してAIに渡す。

以下を1〜5点で採点。全観点4点以上で合格。
A. 数値がすべて元データと一致しているか
B. 「〜と思われます」等の根拠なき推測がないか
C. 社外にそのまま出せる敬体か

今夜から始める最小構成（副業実践者向け）

「開発者じゃないと無理では？」——そんなことはない。実際、最初の一歩はプログラミングというよりチェックリストの言語化だ。

**Step 1（今夜・15分）：**いつもAIに任せている作業を1つ選び、「これが守られていなかったら没」という条件を3つ書き出す。例：ブログ記事なら「タイトル32字以内／見出しが3つ以上／事実の記述に出典リンク」。

**Step 2（明日・30分）：**その3条件をAIへの指示文の末尾に「納品前セルフチェック」として貼る。さらに、生成のたびに別チャットで「この基準で採点して。1つでも4点未満なら不合格と、理由を書け」と採点させる。これだけで③のルーブリック運用が始まっている。

**Step 3（今週末）：**文字数や必須項目のような機械判定できる条件は、簡単なスクリプトに落とす（この部分こそAIに書かせればいい）。ここまでできれば、冒頭の図1のループはもう半分完成だ。

大事なのは、ツールを揃えることではなく「没の条件」を先に決めること。基準がない自動化は、量産される失敗にすぎない。

**ここまでの30秒まとめ：**evalsとは「AIの成果物に機械的な関所を置くこと」。①仕様書 ②正解データとの照合 ③AI採点の3種類があり、①②で大半を弾き、③は曖昧な品質だけに使う。始め方は「没の条件を3つ書く」から。

検証してみた結果

※以下のグラフは、筆者が検証用に構築したデモ環境での計測例です（実案件データではありません）。

図2：evals合格率の推移

evalsなしの期間は合格率が40〜80%を乱高下した。失敗に気づくのは翌朝、壊れたレポートを見たときだ。導入後は「evalsが失敗を特定→仕様を1行直す」を毎日繰り返すことで、初日62%→12日目以降94%で安定した。

図3：失敗カテゴリ別の改善効果

カテゴリ別に見ると（図3）、フォーマット違反やデータ欠損時の異常動作は機械チェックでほぼ根絶。一方、文章表現のゆらぎはAI採点で大幅に減るがゼロにはならない。白黒つくものは機械に、曖昧なものだけAIにという分担がそのまま結果に出た。

決裁者が押さえるべき3点

ここまで読んで「うちでもやりたい」と思ったら、投資判断に必要なのは次の3点だけだ。

**1. コストはほぼゼロから始まる。**①②はただのプログラム実行。③のAI採点も1件数円で、月次では数百円規模。壊れた成果物が顧客や役員に届くリスクと比べれば議論の余地はない。

2. 完璧なevalsは不要。1本目は今日書ける。「JSONとして読めること」だけでもいい。失敗が起きるたびに、その失敗を検出するテストを1本足す。2週間後、それはそのまま業務の仕様書になっている。

**3. 仕様の書き換えまでAIに任せない。**改訂案を出させるのは有効だが、採用判断は人間が握る。検証中、AIがテストを通すためだけに基準を緩く書き換えた（合格率は上がるが品質は下がる）ケースがあった。関所の設計者と受験者は分ける——人間の組織と同じだ。

まとめ：賢いAIより、良い関所

自律運用の安定性を決めるのは、モデルの賢さではなくevalsの設計だ。仕様書・ゴールデンテスト・ルーブリックのうち、まず1本でいい。「機械的に合否を判定できる関所」を置いた瞬間、あなたのAIは「たまに当たる自動化」から「改善が積み上がる資産」に変わる。

明日の朝、手直しから始めるか。合格済みの成果物を受け取るか。分かれ目は今日の1本のevalだ。