AIエージェントが本当に機能しているかどうかの測り方

目次

2026年5月更新。

TL;DR: ほとんどのオペレーターは評価を完全にスキップし、エージェントが機能していると思い込んでいます。私のフレームワーク：5〜10個の既知の入力と期待される出力のゴールデンセットを構築し、合否基準を平易な言葉で定義し、毎週ログを確認する。10回の実際の実行前に複雑な評価システムを構築しないこと——それがモメンタムを殺すワナです。

[オペレーターの視点] 私はコンサルティングブランドとPickleland（テキサス州プフルーグヴィルのピックルボール施設）で30以上の本番AIエージェントを運用しています。ある時点で、エージェントの動作確認に費やす時間が実際に使う時間よりも長くなっていることに気づきました。これが私が行き着いた評価フレームワークです——博士号不要、カスタム評価プラットフォーム不要、Python不要。

誰も話さない問題：エージェントは静かに劣化する

人間の従業員が仕事を間違えると、通常は気づきます。AIエージェントがゴミを生成し始めると、静かに、大規模に、何かが十分に壊れて人間がやっと確認するまで、ゴミを生成し続けます。

モデル更新後に「AIとして」という免責事項を追加し始めたコンテンツエージェントがありました。プロンプト変数名が変更されてチケットリンクを含めなくなったイベントプロモーターエージェントもありました。どちらも大きな音を立てて失敗しませんでした。どちらも静かに劣化しただけです。

解決策はNASAレベルの監視システムを構築することではありません。蓄積する前に劣化を検知するシンプルで再現可能なチェックを持つことです。

評価とは何か（オペレーター向け）

エンジニアはモデルでベンチマークを実行することを「eval」と言います。オペレーターにとっては、もっとシンプルなことを意味します：エージェントが構築した目的通りのことをまだしているかどうかを教えてくれる再現可能なテスト。

3つのコンポーネント：

1. ゴールデンセット — すでに見たことのある5〜10個の本物の入力と、良いことがわかっている期待される出力
2. 合否基準 — 何が合格かを定義する平易な言葉のルール
3. 定期チェック — あなたまたはアシスタントが実際にリズムを持ってテストを実行する

それだけです。フレームワークは不要。必要なのはシステムです。

ゴールデンセットの構築

本番ログから取り出します。すでに良い出力がどのようなものか知っている5〜10個の本物の入力を見つけます。これがあなたのグラウンドトゥルースです。

私のコンテンツパイプラインエージェントのゴールデンセットは、手動で書いた際にボイスチェックリストを通過した5つの公開済み記事です。PickleのlandイベントプロモーターのゴールデンセットはFacebookの過去の投稿のうち、平均以上のエンゲージメント（コメント＋シェア、いいねだけではない）を得た5件です。

良いゴールデンセットのルール：

• 本物の入力、発明した仮説ではない
• 少なくとも1つのエッジケースを含む（複雑な入力、短い入力、通常とは異なるフォーマットの入力）
• 期待される出力を記録しておく——スクリーンショット、テキストファイル、スプレッドシートの行
• ゴールデンセットから削除しない；追加のみ

エージェントが最後に正常に動作していることが確認された時点で、「良い」とはどのようなものだったかを正確に書き留めます。それが期待される出力になります。

合否基準の定義

曖昧な基準は無意味です。「出力は良いはず」は、合理化するので常に合格します。

非専門家が評価できるチェックリスト項目として基準を書きます。以下はコンテンツパイプラインエージェントに使う実際の基準です：

コンテンツエージェントの合否チェックリスト：

• 最初の100語以内にTL;DRがある
• 「今日の急速に変化する世界では」や「AIとして」などのフレーズがない
• 少なくとも1つの具体的な数字や統計がある
• 語数が800〜2000の間
• すべての内部リンクが解決される（404なし）

Pickleのlandイベントプロモーター向け：

イベントプロモーターの合否チェックリスト：

• イベント名がソースカレンダーと一致する
• 日付と時間が正確
• チケットリンクが存在し、壊れていない
• コピーが280語以内
• 一般的な填空フレーズを使っていない

5つのチェックリスト項目のうち4つが通過すれば、実行は合格です。3つ以下なら失敗で、次の実行前に調査します。

Claudeを審査員として使用する

出力が長い、または複雑なエージェントには、Claude Sonnetを自動化された審査員として使います。手動レビューより速く、見落としがちなものを検出します。

コンテンツエージェントに使用する審査プロンプトはこちらです：

You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards.

Evaluate the following post against these criteria:
1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO)
2. Contains at least one concrete number or specific example (YES/NO)
3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO)
4. Word count is between 800 and 2000 words (YES/NO)
5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO)

For each criterion, respond YES or NO with one sentence of explanation.
At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise.

Post to evaluate:
---
{{post_content}}
---

これをCloudflare Workerとして実行します。最新のドラフトを取得し、このプロンプトを起動し、結果をGoogle Sheetsに書き込みます。プロセス全体は8秒かかり、1回の実行コストは約$0.003です。

イベントプロモーター向けの審査プロンプトはよりシンプルです：

You are checking an AI-generated Facebook event post for accuracy and quality.

Source data:
- Event name: {{event_name}}
- Date: {{event_date}}
- Time: {{event_time}}
- Ticket URL: {{ticket_url}}

Generated post:
---
{{generated_post}}
---

Check:
1. Does the post correctly state the event name? (YES/NO)
2. Does the post correctly state the date and time? (YES/NO)
3. Does the post include the exact ticket URL? (YES/NO)
4. Is the post under 280 words? (YES/NO)
5. Is the tone inviting without using generic filler phrases? (YES/NO)

Output PASS if all 5 are YES, FAIL if any are NO. List which items failed.

どこを見るか：Cloudflare Workerログ

Cloudflare Workersでエージェントを実行している場合（私は軽量なエージェントのほとんどをそうしています）、組み込みのログテールが最良の友です。始めるためにサードパーティのログサービスは不要です。

週次スポットレビューで確認する内容：

• エラーと例外 — クラッシュやタイムアウトが発生したもの
• トークン数 — 実行が突然通常の3倍のトークンを使用した場合、何かが変わった
• レイテンシの急上昇 — 突然の遅延は通常、プロンプトが長くなったかモデルが苦労していることを意味する
• 出力長のドリフト — 平均出力が600語から200語に落ちた場合、エージェントの動作が変わった

毎週月曜の朝にこれに15分かけます。Notionに簡単なチェックリストがあります：各エージェントのログを開く、異常を記録する、先週のベースラインとトークン使用量を比較する。これがプロセス全体です。

スプレッドシート評価：見栄えは悪いが機能する

自動化がなかった頃は、Google Sheetsで評価を実行していました。新しいエージェントの最初の4週間にはまだ使用しています。

構造：

週に5行。10分かかります。2回連続で不合格なら、続ける前にエージェントを止めてプロンプトを修正します。

これは恥ずかしいほどのローテクです。3つのプロンプト回帰を本番に達する前に発見した方法でもあります。

やってはいけないこと

10回の実際の実行前に評価システムを構築しない。 2回しか実行していないエージェントのために、2週間かけて洗練された評価パイプラインを構築しているファウンダーを見てきました。本物の本番データを持つまで、「良い」とはどのようなものかについて十分にわかっていません。

発明した合成入力で評価しない。 合成テストケースは、本番が投げかけてくる奇妙なエッジケースを見逃します。常に実際のログから始めます。

すべてを評価しない。 失敗が実際に痛い3〜5つのエージェントを選びます——顧客向け出力、公開投稿するもの、支払いをトリガーするもの。余力ができるまで内部ユーティリティエージェントはスキップします。

早期に自動化しすぎない。 実際に使うスプレッドシートは、チェックを忘れるDatadogダッシュボードに勝ります。手動で始め、チェックを10回実行して何を本当に探しているかを知った後で自動化します。

オペレーターの結論

評価はエンジニアリングレベルでなくても有用です。5〜10個の本物の入力のゴールデンセット、合否基準のチェックリスト、毎週月曜15分のログチェックは、エージェントドリフトの80%が蓄積する前に捕捉します。そこから始めてください。評価なしにエージェントを運用し続けているなら、目隠しで飛行しています——いつか何かが十分公開的に失敗して、20分を費やしておけばよかったと思うでしょう。