ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-05-09上級

Antigravity Agent の出力に「自信スコア」を付ける — 確実な処理は自動承認、曖昧な判断だけ人に渡す設計

Antigravity Agent の出力すべてを人がレビューしていては運用が回りません。出力に「自信スコア」を付け、確実なものは自動承認、曖昧なものだけエスカレーションする graduated approval パターンを、実装例とキャリブレーション手法まで含めて解説します。

antigravity435agents90confidence-scoreproduction59human-in-the-loop2

プレミアム記事

Antigravity Agent を本番に投入したあとに最初に直面するのは「すべての出力を人がレビューする運用は持続しない」という現実です。私自身、ある業務自動化のエージェントを運用しはじめて2週間目に、レビュー待ちのキューが300件を超えて、結局そのキューを消化するために週末を潰すという本末転倒な状況を経験しました。

かといって、レビューを完全に外してしまうと、たまに混ざる「自信満々で間違っているケース」が下流の業務やデータベースを汚染して、後から戻す方がよほど高くつきます。ここでよく語られる解は「Human-in-the-loop(HITL)」ですが、HITL は「人を入れる」とだけ書いてあって、誰のどの出力をいつ人に渡すかという肝心の設計は読者に委ねられている、という意見を私は持っています。

この記事で扱うのは、その「いつ人に渡すか」を機械的に判断するための 自信スコア(confidence score) の設計です。出力ごとに 0〜1 のスコアを付け、閾値で「自動承認 / 人間レビュー / 自動拒否」の3層に振り分ける graduated approval(段階的承認)パターンを、Antigravity Agent と Python での実装例まで踏み込んで解説します。

なぜ「全レビュー」も「全自動」も失敗するのか

エージェント運用には3つのモードがあります。それぞれの失敗パターンを先に押さえておきます。

モード1: 全レビュー(フルチェック)

すべての出力を人が見てから次の処理に進めます。最も安全に見えますが、運用 N 日目には必ず破綻します。エージェントが1日100件処理するなら、1件30秒の確認でも50分。10件しか処理しない用途なら成立しますが、それなら最初からエージェント化する旨味が薄いです。

モード2: 全自動(ノーチェック)

「LLM が出した結果を信じる」運用です。短期的には回りますが、必ず「自信を持って間違える」ケースが混ざります。Anthropic や Google の論文でも繰り返し指摘されているとおり、LLM の自信度(モデルが内部で計算する尤度)と、実際の正答率の相関は弱いです。「これは確実です」と語尾を強めるハルシネーションは止められません。

モード3: 段階的承認(graduated approval)

出力ごとにスコアを付け、閾値で振り分けます。

  • スコア >= 0.85: auto-approve(人を介さず次工程へ)
  • 0.55 <= スコア < 0.85: human-review(キューに送る)
  • スコア < 0.55: auto-reject + retry(破棄して別プロンプトで再試行)

このモードは、運用工数を 70% 以上削減しながら、品質劣化を「人がレビューする上位 30〜45%」に集中させる設計です。私はこの方式に切り替えてから、レビューキューが安定して 1 日 30〜50 件で頭打ちになり、自分の開発時間を取り戻せるようになりました。

自信スコアとは何か — 既存の指標との違い

「自信スコア」と聞くと、モデルが返す logprobs を思い浮かべる方が多いと思います。しかし logprobs はテキスト生成の尤度であって、出力内容の正しさを測る指標ではありません。「確信を持って嘘をつく」のが LLM の典型的な失敗様式なので、logprobs 単体ではエスカレーション判断に使えません。

私が運用で使っている自信スコアは、次の3つの独立した観点を組み合わせた合成スコアです。

  • Self-evaluation スコア: 同じモデル、または別モデルに「あなたのこの出力はどれくらい信頼できますか? 0-100で答えてください」と問い直した値
  • Verifiability スコア: 出力がスキーマ検証・型チェック・ドメインルールに通るか
  • Historical similarity スコア: 過去の類似タスクで、エージェントが返した出力が人間レビューで承認された割合

3つを独立に計算して重み付けで合成するのがポイントです。1つの指標に依存すると、その指標を回避するように LLM が「最適化」してしまうことがあるためです。Goodhart の法則(「測定指標が目標になると、それは良い指標でなくなる」)は LLM 運用でも容赦なく発動します。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
self-evaluation・検証可能性・過去承認率の3指標を重み付き合成する自信スコアの実装
ROC的キャリブレーションで auto-approve の精度95%を保つ閾値設計と、3ヶ月の実運用記録
再デプロイ不要の緊急停止スイッチなど、本番で事故を防ぐ運用パターン
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

Agents & Manager2026-07-05
エージェント開発スタックの『既知の正常』を1枚のロックファイルで守る — 可動部が同時に動く時代の変更予算設計
IDEビルド・CLI・モデル・依存が同時に動くと、回帰の原因が特定できなくなります。既知の正常を1枚のロックファイルに固定し、一度に動かす軸を絞る変更予算の設計を、実装コードと運用ログで整理しました。
Agents & Manager2026-05-29
Antigravity 長時間実行エージェントの監視設計 — watchdog と段階的リカバリ
AdMob 収益最適化を 8 週間バックグラウンドエージェントに任せて見えた、長時間タスクが静かに停止する 3 つの故障モード。watchdog タイマーと段階的リカバリの実装メモを残します。
Agents & Manager2026-05-27
Antigravity Agent の Record & Replay — 失敗を3分で再現する本番運用パターン
Antigravity の自律エージェントが本番で失敗した瞬間を、後からオフラインで決定的に再生する Record & Replay の設計と実装。Dolice Labs 4 サイトを並行運用してきた経験から、ストレージ設計・PII マスク・ハーネスのコードまで具体的に解説します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →