パイロットで動いたエージェントが、なぜ本番に届かないのか。
複数のエンタープライズAI調査が繰り返し示す数字がある。AIエージェントのPoC（概念実証）が本番稼働に移行できる割合は15〜20%程度に留まるというものだ。技術的には動いている。精度も出ている。それでも、承認が下りない、展開が止まる、組織が踏み切れない。
残りの80〜85%をブロックしているのは何か。
失敗の種類が違う
このギャップを「精度不足」や「コスト問題」で説明しようとすると、どこかで詰まる。パイロット段階で精度が出ているにもかかわらず、本番化が止まるケースが多いからだ。
本番環境で問われるのは、「このエージェントが何をするか」ではなく、「このエージェントが何をしないか」だ。
エラーが起きたとき、誰が責任を持つか。想定外の入力に対して、エージェントはどう振る舞うか。判断が自動化される範囲と、人間が介在すべき範囲の境界線はどこか。これらが設計されていないエージェントは、技術的に優れていても、組織として受け入れられない。
これは信頼の問題だが、もう少し正確に言えば、信頼を設計していないことの問題だ。
信頼アーキテクチャの3要件
「信頼アーキテクチャ」という言葉は、まだ定義が固まっていない。ただ、実践的な文脈で使われるとき、以下の3つの設計要件に収束することが多い。
観測可能性（Observability）
エージェントが何をやったか、なぜその判断をしたかを、人間がたどれること。ブラックボックスな推論プロセスは、失敗したときに原因を特定できない。原因が特定できなければ、再発防止も、責任の所在も曖昧になる。
介入可能性（Interruptibility）
エージェントの実行フローに、人間が介入できるポイントが設計されていること。自律性が高いほど、この設計は難しくなる。しかし、介入できないシステムは承認されない。これはAI固有の問題ではなく、金融の取引システムや医療機器の承認プロセスと同じ論理だ。
失敗の限定性（Blast Radius）
エージェントが誤動作したときの影響範囲を、あらかじめ設計で制限しておくこと。権限の最小化、サンドボックス化、ロールバックの設計がこれに当たる。
この3つが揃ったとき、エージェントは「動くもの」から「任せられるもの」に変わる。
信頼はプロダクト設計の問題でもある
ここで注目したいのは、信頼アーキテクチャが技術的な要件であると同時に、プロダクト設計の問題でもあるという点だ。
UXの文脈では、ユーザーが「操作できる」と感じることが信頼の条件になる。コントロールを手放すことへの不安は、インタフェースの設計で緩和できる。AIエージェントにおける信頼も、同じ構造を持っている。
エージェントが自律的に動くほど、人間が介在できる「ポイント」をUIや運用フローの中に意図的に設計しないと、ユーザーも組織も離れていく。これは感情的な問題ではなく、設計の問題だ。
「Copilot → Assistant → Autonomous Agent」という自律性の段階が語られるとき、前のステージでこの信頼設計が積み上げられているかどうかが、次のステージへの移行可否を決める。信頼アーキテクチャは、自律性スペクトラム全体を通貫する設計思想になりうる。
隣接領域との共鳴
この問題は、AIエージェント固有の話ではない。
RPAはかつて同じ壁に当たった。業務の自動化は技術的には容易だったが、「誰が監視するか」「失敗したときの業務フローはどうなるか」が設計されていないツールは、パイロット後に廃棄された。Airbnbのデザインシステムや、Figmaのプラグインエコシステムが定着したのも、「何でもできる」ではなく「この範囲では安心して任せられる」という境界を設計したからだと言える。
信頼アーキテクチャは、AIエージェントの課題を解くための概念にとどまらず、自律的なシステムが組織に受け入れられるための普遍的な設計パターンとして機能する可能性がある。
今後、エージェントの能力が向上するにつれて、この設計の重要性はさらに増す。エージェントが高度になるほど人間の監視コストは上がる。そのコストを下げながら信頼を担保するには、アーキテクチャレベルで信頼を組み込むしかない。
パイロット段階の85%が本番に届かない理由は、技術の問題ではなかった。信頼を設計していなかったことの問題だ。
そして信頼は、後から付け加えるものではなく、最初からアーキテクチャに織り込むものだ。
コメント