分析：AI エージェントがデモから本番へ移るとき、実際に何が変わったのか

エージェントの案件には見慣れた曲線がある。最初の週にプロトタイプが驚くようなことをやってのける。6 週目には誰も想定しなかった入力でもっともらしい戯言を出し、チームはモデルをもう一つ足すか諦めるかで揉めている。

反対側に抜けた案件は、より良いモデルを見つけたのではない。問題の形を変えたのだ。

デモを殺す算数

各ステップを 95% の確率で正しくこなす作業を考えよう。判断を要する開かれた手順としては良い数字だ。

3 ステップつなげば約 86% の実行が成功する。20 ステップなら 3 分の 1 ほど。50 ステップなら 8% だ。

デモは 5 ステップ版を一度見せ、うまくいかなかった 2 回は人が静かにやり直した。本番は 20 ステップ版を、誰も見ていない状態で 1 万回回す。

以降のすべてはこの算数への対応である。

生き残った導入の共通点

狭い領域。 「運用を処理せよ」ではなく「この二つの請求システムを照合せよ」。分岐が少なく、ツールが少なく、誤りようが少ない。本番に耐えたエージェントはほぼ例外なく、それを正当化したデモより野心が小さい。

安い検証。 単独の予測因子として最も強い。コーディングエージェントが最初に成立したのは、テストが客観的で自動的な信号を与えるからだ — 人を介さずに試し、確認し、やり直せる。検証が高くつく領域（法的意見、価格の判断）では人が結果を確認せねばならず、レバレッジに上限が生じ、事業の採算計算が変わる。

モデルの «外» にある権限境界。 読みは広く、書きは狭く。金銭・顧客への連絡・削除・デプロイには承認の門。これはプロンプト内の指示ではなくランタイムで強制する。信頼できない内容を読むエージェントは、指示が汚染されうるエージェントだ。

予算。 最大ステップ数、最大実時間、最大トークン。誤ったツール応答に嵌って回り続けるエージェントは、終わりのない課金事故である。

再生できるログ。 すべての呼び出しと結果を保存する。問題が起きたとき「実際に何をしたか」が即座に答えられねばならない — 直すためにも、増えつつある監査要求のためにも。

評価が大人になった

最も目立たず最も重要な変化だ。初期のエージェント開発は «見て» 評価していた。それは規模に耐えず、退行を捕まえられない。

いまの実務は 軌跡（trajectory） を記録することだ — 実際の実行の手順・ツール呼び出し・結果を丸ごと保存し、プロンプト・モデル・ツール構成が変わるたびに再生する。各軌跡には «正しい実行はこういう形だ» という表明が付く。新しいモデル版は公開ベンチマークの点が良いからではなく、記録した軌跡の集合を壊さないから採用される。

第二の変化は ステップ単位の採点 だ。エンドツーエンドの合格率は「何かがおかしい」と教える。ステップ単位の点数は「検索ツールが月曜に古い結果を返す」と教える。

ツールがインフラになった

一時期はエージェント製品ごとに独自のコネクタを書いていた。Model Context Protocol がツールの公開を標準インターフェースに変えた。サーバーが提供内容を告知すれば、互換のあるクライアントはどれでも使える。その結果、統合作業はアプリごとの接着剤から、一度作って保守する再利用サーバーへ移った。

実務的な効果は地味で大きい。面白い問いが「私のエージェントをこのシステムにどうつなぐか」から「私のエージェントにこのシステムで何を許すべきか」へ移った。それはガバナンスの問いであり、正しい問いだ。

うまくいかなかったこと

知られていないので、はっきり書いておく価値がある。

• 長時間の自律運用。 開かれた目標を与えて何時間も放置すると今も漂流し、誤った方向転換の代償が静かに積み上がる。
• 検証が高くつく作業。 正しいかどうかを知るために人が全文を読まねばならないなら、エージェントが節約したのは «仕事» ではなく «タイピング» だ。
• 変動の大きい環境。 レイアウトが変わるウェブサイト、一貫しないエラーを返すシステム、文書化されていない例外を含む業務。
• 目的のないエージェントの群れ。 マルチエージェント構成は、サブタスクが本当に別のツールと文脈を要するときに効く。単一エージェントでできる仕事に適用すれば、調整の失敗が増えるだけだ。

正直な要約

エージェントは、目標が明確で、領域が狭く、結果の確認が安く、影響範囲がモデルの善意以外の何かで制限されているときに、今日きちんと働く。それは実在し、拡大しているカテゴリだ — そして製品発表の「エージェンティック」が匂わせるより小さいカテゴリでもある。

うまく出荷しているチームは、ほぼ例外なく、それを先に受け入れた側だった。