AI Agent 試験導入が本番に進めない理由：欠けている四つの実行基盤

結論から言うと： 本番に進めない agent 試験導入が負けるのは、ほとんどの場合モデルではない――その下に四つの層、すなわち意味、権限、承認、監査が欠けているからだ。より強いモデルではこれは解決しない。解決するのはその四層だ。

あのプロジェクトは、デモの日に満場の喝采を浴びた。

旗振り役だった業務責任者の陳さんは、はっきり覚えている。カスタマーサポート agent が、その場で七つ八つの難しい質問に、速く正確に答え、会議室で拍手が起きた。経営層はその場で投資拡大を即決し、予算をつけ、人をつけた。それは彼のキャリアでも数少ない輝かしい瞬間だった。

四か月後、このプロジェクトはひっそりと停止された。予算は埋没コストとして記され、陳さんの経営層内での信頼度も、それに連れて一段下がった。

それを殺したのはモデルではない――モデルはずっとよく戦っていた。あるリリースレビューで法務が発した一つの問いだ。「この agent が A 顧客に答えるとき、B 顧客の情報を一緒に使わないことを保証できるか? それができないことを、どうやって 証明 するのか?」

誰も証明できなかった。それが必ず漏洩するからではなく、システムの中に、それを阻止したり、事後にそうしたかどうかをはっきりさせたりできる場所が、そもそも一つもなかったからだ。その瞬間、陳さんはようやく悟った。最初から最後まで、問題はモデルにはなかったのだ。

彼は一人ではない。業界レポートの数字には幅があるが、同じ傾向を示している。多くの agent 試験導入は本番前で止まり、多くは測定可能なリターンを出せないまま終わる。これほど多くの輝かしい瞬間が、最後には同じ静かな結末へと歩いていった。

より強いモデルに替えても、なぜ効かないのか

この成績表を前にして、ほとんどのチームの第一反応は同じだ。モデルが強くない。そこでより大きなモデルに替え、より精密なプロンプトに調整し、より複雑なオーケストレーションを載せる。

通過率はほとんど動かない。問題はたいていモデルの外側にあるからだ。試験導入から本番までの多くの作業は、データエンジニアリング、ガバナンス、フロー統合、計測であり、モデル自体はその一部にすぎない。多くの試験導入は「賢くない」ことで死ぬのではなく、モデルの足元にいくつかの層が欠けていることで死ぬ――そしてその数層は、どれほど強いモデルに替えても補えない。それらはそもそもモデルの側にはないからだ。

まず PoC で素早く検証する、それの何が間違っているのか?

ここで、非の打ちどころなく聞こえる一つの反論を受け止めなければならない。まずデモを作り、PoC を回して価値を検証するのは、もともと正しいやり方だ。いきなりデモを過剰に作り込むべきだとでも言うのか?

PoC そのものは間違っていない。間違っているのは 検証する対象が間違っている ことだ。

陳さんのあのデモが検証したのは「モデルがうまく答えるか」だった――そしてこれこそ、プロジェクト全体の中で最も心配する必要のない部分だ。それが検証しなかった、そして設計上わざと触れなかったのが、生死を本当に決めるあの四層(権限、定義、承認、痕跡)だ。こうして PoC は経営層に 誤った自信 を与えた。デモがこれほどスムーズなのだから、投資を拡大してもリスクは大きくないだろう、と。四か月後にようやく皆が気づいた。デモのスムーズさと本番の実現可能性は、ほとんど相関しないのだ。

だから正しい PoC は、「モデルが正しく答えられるか」だけを問うべきではなく、もっと「この答えを、権限・承認・痕跡がすべて揃った本物の環境で、安全に正しい人へ届けられるか」を問うべきだ。検証する対象を間違えれば、デモが美しいほど、深く埋まった落とし穴になる。

デモは、生まれつきあの四層を必要としない――だからあなたを騙す

なぜデモのスムーズさは、これほど徹底的に本番から乖離するのか? 良いデモは、いかなるガバナンスの問題も 発動しない ように設計されているからだ――それはエクスポートされたデータを一つ使い、一人に見せるだけで、「このユーザーはこのレコードを見られるか」「このステップは先に承認すべきか」を問いにいかない。

ここから残酷な系が導かれる。成功したデモの一つひとつが、それが将来失敗する原因を、体系的に隠している。 あなたが見たものが美しいほど、隠されたあの数層は深い。本番データに接続したその瞬間、環境は一変し、成否を決めるのは、モデルの足元にこの四層があるかどうかだ。

それが答えられなければならないこと	欠けているのはどの層か	欠けるとどうなるか
「顧客」とは結局何を指すのか? 定義はどこにあるのか?	① 意味層	見当違いの答え、定義の衝突、業務が認めない
A 顧客の情報が B 顧客に使われないか?	② 権限層	越権漏洩、法務が一票で否決
このステップは先に人の承認を待つべきか?	③ フローと承認の層	止めるべきが止まらず、誰も動かせない
この操作は誰が、いつ、何に基づいて行ったのか?	④ 監査層	証拠を出せず、コンプライアンスが直接阻止

陳さんのあのプロジェクトは、②の行で死んだ。

なぜこの四層はいつも欠席するのか

ではなぜ最初から作っておかないのか? 従来のやり方では、どの層も大きな塊の 横断的な 硬い工事だからだ。意味層は十数のシステムのデータを統一されたオブジェクトモデルに整合させねばならず、権限層は各アプリのコードに散らばったルールを一貫したポリシーにまとめねばならず、承認は既存の体系に接続せねばならず、監査は人と AI の動作を同じ一冊の帳簿に集約せねばならない。それらはある機能の一部ではなく、すべての機能の下に敷かれた土台だ――汚くて遅く、しかもすべてデモには見えない部分だ。

さらに悪いことに、多くのチームは 試験導入ごとにこの四層を個別に作り直す。今回が終わり、シナリオを替えれば、四層を一から作り直す。予算と忍耐が、すべて土台を繰り返し作ることに費やされる。

あなたの試験導入が本番に進めるかを判断するのに、四か月待つ必要はない。四層それぞれに一つずつ問えば十分だ。

1. 意味:別の人が agent に同じ業務質問をして、定義は一致するか? それとも各自バラバラに答えるか?
2. 権限:それが、各人に自分が見る権限のあるデータだけを見せることを、証明 できるか?
3. 承認:高リスクの動作で、それは自動的に止まって人のサインを待つか、それとも直接やってしまうか?
4. 監査:それがやったことを適当に一つ選んで、完全な経緯を取り出せるか?

四つすべてに「はい」と答えられれば、本番に進める可能性はかなり高い。一つでも「わからない」があれば、陳さんと同じリスクに近い。

成功する試験導入はどんな見た目か

一つの反例を見る価値がある。それと陳さんとの違いが、ちょうどモデルにはないからだ。

別のある会社が、ほとんど同じカスタマーサポート agent を作った。使ったモデルはむしろ少し素朴なものだった。だが彼らは「モデルに美しく答えさせる」から始めず、まず四層を統一されたランタイムの上に作った。顧客、注文、作業指示はすべて同じ一組のオブジェクト(意味が揃った)。agent は質問するオペレーターの身分で行動し、そのオペレーターが見る権限のあるデータしか見られない(権限が揃った)。返金が上限超過なら自動で人手に回す(承認が揃った)。動作のたびに同じ一冊の帳簿に落ちる(監査が揃った)。

彼らのデモの日は、陳さんほど派手ではなかった――安定して答えたが、驚きはなかった。だがリリースレビューで法務が同じあの問いを発したとき、プロジェクトマネージャーはその場で権限セットと一本の監査記録を取り出し、agent はオペレーターの身分でしか、オペレーターが見る権限のあるデータしか見られず、越権はランタイムにその場で阻止され痕跡が残ることを証明した。法務はうなずき、プロジェクトは通過した。

違いはここにある。成功した試験導入は、モデルだけで勝ったのではなく、あの四層を前もって作っておいたから、「どう証明するのか」と問われても耐えられたのだ。 陳さんが負けたのは技術的な含有量ではなく、順序だ――彼は最も心配する必要のないもの(モデル)を前に置き、本当に生死を決めるもの(四層)を最後に残した。

まず冷や水を:四層が揃っても、成功は保証されない

ここで正直に一言。さもないと、また万能薬になってしまう。

変更管理の側面もある。人が使わない、フローが変わらない、組織が認めない場合、四層が揃っていても成功は保証されない。これは「四層の欠如で死ぬ」と矛盾せず、一つのことの両面だ。法務が放行を許さず、業務が定義を認めないシステムは、組織に採用される入場券すら手にできない。だが逆に、四層が揃ったのは入場券を手にしただけで、試合に勝ったことにはならない。

技術的な準備は 必要 条件であって、十分 条件ではない。四層は agent の動作を制御可能、追跡可能、説明可能にし、そうして組織はようやく それを信頼し、採用できる可能性が出てくる――だが本当に定着させるには、なお誰かがフローの変更を推進し、誰かが習慣を変える意志を持たねばならない。誰かが「この四層を補えば、試験導入は必ず成功する」と言うなら、それは過剰な約束だ。それが取り除くのは技術的な死因であって、組織的な死因は取り除けない。

出口:四層はランタイムから来る、プロジェクトごとに作り直すのではない

勝率を変えるのは、より強いモデルではなく、この四層を、プロジェクトごとの自作工事ではなく、ランタイムに最初から備わった能力にすること だ。

ある設備の修理依頼シナリオを取ろう。あなたはオブジェクトとその権限を宣言するだけだ。

export const RepairTicket = ObjectSchema.create({
  name: 'ops_repair_ticket',
  label: '修理依頼書',
  fields: {
    device: Field.lookup('ops_device', { label: '設備', required: true }),
    cost: Field.currency({ label: '修理費用', min: 0 }),
  },
});

残りの四層はランタイム(ObjectOS)が揃える。意味層――この宣言そのものが、agent が業務を理解する拠り所だ。権限層――誰が修理依頼書を読み書きできるかを、ランタイムが呼び出しのたびに強制検証する。フローと承認の層――「修理費用が上限超過なら承認を経る」は、オブジェクトにぶら下がった宣言的フローで、自動で一時停止してサインを待つ。監査層――人と agent の動作のたびに、同じ一冊の帳簿に落ちる。次のシナリオに替えても、この四層は作り直さず、オブジェクトをいくつか宣言し直すだけでいい。

陳さんのあのプロジェクトがこう作られていたら、法務のあの問いは死刑にはならなかった。彼はその場で権限セットを取り出し、agent は質問者の身分でしか、質問者が見る権限のあるデータしか見られないことを証明できた――②の層がもともと足元にあったからだ。

結び

本番に進んだ試験導入が頼ったのは、ほとんどの場合、最良のモデルだけではない。頼ったのは、モデルの足元のあの四層――意味、権限、フロー、監査――がしっかりそこにあること、そして組織が本当にそれを使い始めたことだ。前者は入場券、後者は試合で、両方とも必要だ。

だからもしあなたの agent 試験導入がまた行き詰まったら、慌ててモデルを替えるのはやめよう。陳さんが四か月後にようやく問えるようになったあの問いを問おう。その足元の四層は、いったい何層作ったのか? これはプロンプトをもう一版調整するよりもずっと節約になり、一つのプロジェクトと一人の信頼を救うこともできる。

npm i -g @objectstack/cli && os start

オブジェクトとその権限を一つ宣言し、agent にそれを使わせてみよう――あの四層がもう足元にあり、あなたが書いたのは数十行だけだと気づくはずだ。