「賢いのに本番に出せない」——話題は能力から信頼性へ
2026年の後半、エンタープライズAIの議論の重心が明確に動いた。モデルがどれだけ賢いか、ではなく、そのエージェントを本番の業務に預けられるかへと問いが変わったのだ。
象徴的だったのが、7月14〜15日に開かれた VentureBeat の年次カンファレンス VB Transform 2026 での一幕だ。AmazonのAGI Autonomy研究ラボを率いるBryan Silverthorn氏は、企業がエージェント導入をためらう理由を「技術が賢くないからではなく、予測可能でないからだ」と言い切った。同氏が引いたCiscoの調査では、**85%の企業がエージェントを試験導入している一方、本番に載せられたのはわずか5%**にとどまる。(VentureBeat)
homula はエンタープライズ向けのAIエージェント・インテグレーターとして、まさにこの「PoCは通ったのに本番で止まる」局面に何度も立ち会ってきた。本稿では、いま業界が「評価ギャップ（evaluation gap）」と呼び始めた現象の正体と、日本企業が本番運用に進むために評価と統制をどう設計すべきかを整理する。
「評価ギャップ」とは何か——社内テストは通り、現場で崩れる
評価ギャップとは、エージェントの自律性（できること）が、企業がそれを検証できる速度を追い越してしまう状態を指す。VentureBeatは連載の中で、この差が広がっていること自体をエンタープライズAIの構造的リスクとして挙げている。(VentureBeat)
問題の核心は、社内の評価スイートを満点で通過したエージェントが、実際の現場では崩れることにある。同誌の報道によれば、内部評価を通過したにもかかわらず顧客に影響する障害を起こしたAI機能を、実に半数近くの企業が経験しているという。ベンチマークの単発スコアは高くても、それは「うまくいったときの一回」を測っているに過ぎず、同じ依頼を千回繰り返したときの失敗率を保証しない。
「デモは動く」は本番の証明にならない。ベンチマークの成功率は最良ケースの一点であり、実運用が要求するのは「毎回・大量に・想定外の入力でも」壊れない再現性だ。ここを取り違えると、PoCの成功がそのまま本番の失敗の伏線になる。
信頼性を4つに分解する——一貫性・頑健性・予測可能性・安全性
「信頼性を上げる」という言葉は曖昧だ。VB Transform 2026 で示された枠組みの価値は、それを測定可能な4つの軸に分解した点にある（Silverthorn氏はこの整理をプリンストン大学の研究に基づくものとして紹介した）。
| 軸 | 問い | 本番で崩れる典型例 |
|---|---|---|
| 一貫性 (Consistency) | 同じ入力で同じ結果を返すか | 同一の依頼が日によって別の結論になる |
| 頑健性 (Robustness) | 想定外の入力でも破綻しないか | 表記ゆれ・欠損データで処理が暴走する |
| 予測可能性 (Predictability) | 失敗の仕方が事前に読めるか | どこで止まるか分からず運用が張り付く |
| 安全性 (Safety) | 誤作動しても被害が限定されるか | 権限を越えてツールやデータに触れる |
重要なのは、この4軸が標準ベンチマークのスコアとは別物だということだ。ベンチマーク上位のモデルでも、一貫性や予測可能性が低ければ本番には出せない。逆に言えば、企業が投資すべきは「より賢いモデル」ではなく、この4軸を計測し、閾値を割ったら止める仕組みである。
なぜ「導入前テスト」だけでは足りないのか——評価を運用へ
評価ギャップが厄介なのは、一度きりの導入前テストでは埋まらない点にある。理由は3つある。
- 入力分布が動く——本番の依頼は、テスト時に想定した分布から時間とともにずれていく（ドリフト）。テストが緑でも、三か月後の現場は別物だ。
- モデルとツールが更新される——基盤モデルの差し替えやMCPで繋いだツールの仕様変更で、昨日まで通っていた挙動が静かに変わる。
- 失敗が可視化されにくい——「間違った答えを自信満々に返す」タイプの失敗は、例外もエラーログも吐かないまま業務に流れ込む。
だからこそ、評価は「リリース前の関門」から「運用に埋め込まれた継続的な計測」へと重心を移す必要がある。実運用の推論と並走して品質を判定し、**監査に耐える機械可読な判定記録（なぜ合格/不合格か）**を残す——これが評価ギャップを埋める実務の方向だ。以前の記事「モデルを賢くしても壊れる——長時間AIエージェントの信頼性を決める『コンテキストエンジニアリング』」で触れた文脈設計が「壊れにくくする」側だとすれば、本稿の評価は「壊れたことを取りこぼさない」側の備えにあたる。
統制の視点——「壊れても被害が出ない」設計
信頼性のうち安全性は、モデルを賢くしても解けない。Silverthorn氏が示した処方箋は、モデルの賢さに賭けるのではなく、周囲のインフラを分離・サンドボックス化し、たとえ誤作動しても実害が出ないように設計するという考え方だった。実際、同カンファレンスの調査では、エージェント導入時の最大の懸念として回答者の40%が「ツールやデータへの不正・想定外アクセス」を挙げたという。(VentureBeat)
ここで効くのが、エージェントとツールの間に「制御点」を置く設計だ。具体的には——
- 権限の最小化（RBAC）: エージェントごと・タスクごとに、触れてよいツールとデータを絞る。
- 承認ゲート: 破壊的・不可逆な操作は人の承認を挟み、「誤作動が即・実害」にならないようにする。
- 監査ログ: 誰が・どのエージェントが・いつ・何をしたかを、後から追える形で残す。
これは、本番投入前の検証を「証明書」として持ち回る発想（Workdayの『Agent Passport』で論じた）とも地続きだ。入口（何を許すか）と実行時（実際に何をしたか）の両方に統制を置いて初めて、安全性は運用可能な状態になる。
homulaの観点——PoCの先で壊れないための「運用の設計」
評価ギャップは、homula が支援の現場で最も多く出会う壁でもある。私たちは戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化を一気通貫で支援するが、**価値が問われるのは常に「PoCの先」**だ。壊れないエージェントは、賢いモデルからではなく、次のような運用の設計から生まれる。
- 成功基準を先に決める: 「AIエージェント・ブートキャンプ」では、業務棚卸しとプロトタイプ構築、ROI試算を3〜5日で行う。何をもって合格とするか（許容失敗率・対象範囲）を最初に定義しておくことが、後の評価ギャップを小さくする。
- 統制を後付けにしない: Agens Control が提供する承認フロー・DLP・5年分の監査ログ・RBACは、上で述べた「壊れても被害が出ない設計」をそのまま製品化したものだ。誤作動を賢さで防ぐのではなく、制御点で受け止める。
- 接続はゼロビルドで、統制は締める: Agens はMCPを活用し200以上のツールと構築ゼロで接続する。接続の速さと、権限・監査の締めを両立させることが、拡大局面での安全性を支える。
賢いモデルを選ぶことと、本番で壊れないことは別の課題だ。homula が担うのは後者——評価と統制を運用に織り込み、内製化まで見据えて設計する部分である。
まとめ——分水嶺は「能力」ではなく「検証できるか」
Gartnerは、2026年までにエンタープライズ・アプリの40%がタスク特化型AIエージェントを組み込む（2025年時点の5%未満から急増）と予測する一方、(Gartner) 2027年末までにエージェント型AIプロジェクトの4割超が中止されるとも見ている。この二つの数字の間にあるのが、まさに評価ギャップだ。
- 話題の重心は「賢さ」から「信頼性」へ移った。導入を止めているのは能力ではなく予測可能性である。
- 信頼性は一貫性・頑健性・予測可能性・安全性の4軸に分解して計測する。ベンチマークのスコアとは別物だ。
- 評価は導入前の一度きりではなく、運用に埋め込んだ継続計測へ。監査に耐える判定記録を残す。
- 安全性はモデルの賢さでは解けない。**制御点（RBAC・承認ゲート・監査ログ）**で「壊れても被害が出ない」状態を作る。
エージェントを本番に載せられる企業と、PoCで止まる企業を分けるのは、モデルの選定ではない。自分たちのエージェントを検証し続けられる運用を、最初から設計しているかである。
「PoCは動いたが、本番に出す踏ん切りがつかない」——その距離を埋めるのは、賢いモデルではなく評価と統制の設計です。homula は、成功基準の定義から運用・内製化まで伴走します。