エージェントの「完了しました」は、
事実ではなく主張である。

「隣にあるものを測って、本物だと言う」

誤報は、嘘ではなく検証の失敗として生まれます。エージェントは検証らしき行為を実行し、その結果を誠実に報告している。ただ、測っている対象が本物ではない。複数製品を半年運用した実環境で、同じ構造の誤報が繰り返し観測されました。

リダイレクトの手前を測る

curl を -L なしで叩き、転送前の応答を根拠に「正常配信」と報告する。転送先の本体は一度も見ていない。

単位を読み違える

アクセス解析の events 数を「訪問者数」として報告する。数字自体は本物なので、報告だけ読むと疑う理由がない。

APIの成功を「実在」と呼ぶ

APIが成功を返したことを根拠に「投稿されています」と報告する。リクエストが受理されたことと、相手側に残ったことは別の事実。

沈黙の欠落

パーサが途中の数行を例外も出さずに読み飛ばしたまま「全件クリーン」。検査は正しく走った——欠けた母集団に対して。

「検証コマンドを実行せよ」という規律は、検証を実行させることはできても、検証が対象を測れているかを保証しません。検証層をエージェントの内側に置く限り、検証そのものが最適化・省略の対象になります。

このハーネスがすること

Claude Code / Agent SDK のフックに差し込むハーネスとして設計しています。判定材料は、エージェントの提出物（ログ・トレース・自己申告）ではなく、外部の実状態です。

• デプロイ先の実応答・DBの実レコード・API相手側に残った状態を、決め打ちのプローブで測る
• LLMに判定させない。決定的なコマンドで測り、主張と実測を突き合わせる
• 突合結果を履歴として蓄積する。エージェント別・タスク別に「主張と実測が食い違った率」が見える

実行の前に守るガードレールでも、出力の品質を採点するevalsでもありません。事後に、外側から、決定的に測る層です。

正直な線引き — 50行の自作で足りる人は、自作でよい

先に、作らなくていい人の話をします。一人で1〜2製品を回していて、成果物がリポジトリの中で完結しているなら、たぶん自作フックで足ります。次の範囲は無料・小規模な自作が現にカバーしています。

• 完了語と実行痕跡のテキスト照合（50行のStop hookで実装できます）
• 「検証コマンドを打て」という規律のプロンプト注入
• リポ内のテスト結果・diffを根拠にした、実装者と検証者の分離
• CI上の決定的チェック（lint・テスト・シークレットスキャン）

この範囲の方を引き込むつもりはありません。まず50行から始めるのが正しいと思います。

自作の外に残るのは、外部実状態のプローブ集（測り方の罠を、罠ごと吸収した状態で保守され続けるもの）、食い違い率の履歴、製品やリポを跨いだ横断ダッシュボードと共有、そして検証層それ自体の保守——検証層は、黙って壊れると全てが崩れる場所です。その線引きより向こうで困っている方の話を聞かせてください。

待機リスト

メールアドレスだけで登録できます。あわせて「何に一番困っているか」を1問だけ（任意）聞いています。回答の分布が、そのまま設計の順番を決めます。