Forbes記事が示した「不都合な構造」
Forbes JAPANに掲載された記事「なぜ多くのAIエージェントは実際の業務フローで失敗するのか」は、AIエージェントの失敗原因について、ある明確な立場をとっている。
モデルの性能が足りないのではない。アーキテクチャの設計が欠けているのだ、と。
具体的には、制約（constraints）、検証（validation）、可観測性（observability）、そして人間へのエスカレーション（human escalation）。これらの設計が不在のまま、エージェントが業務フローに投入されている。それが失敗の本質だという主張である。
この指摘は正しい。そして、多くの実務者にとって既視感のある話でもある。
数字を見てみよう。McKinseyが2025年11月に発表した「The State of AI in 2025」によれば、AIエージェントを少なくとも試している組織は62%に達する一方、全社規模でAIを展開できている企業はわずか7%にとどまる[1]。Gartnerも2025年6月、「2027年末までにエージェンティックAIプロジェクトの40%以上が、コスト増大・不明確なビジネス価値・不十分なリスク管理を理由に中止される」と予測している[2]。
「導入」と「定着」の間に、深い溝がある。
だが本稿で注目したいのは、この溝の正体である。この溝は、本当に技術的成熟度の差なのだろうか。それとも、もっと別の構造があるのではないか。
「チャットボット思考」の延長で設計していないか
多くの企業がAIエージェントを導入するとき、暗黙のうちに「チャットボット思考」を引きずっている。つまり、質問に対して適切に答えるシステムをつくる、という発想だ。
しかしAIエージェントは、チャットボットではない。それはタスクを実行し、判断を下し、業務プロセスの中で意思決定に関与する存在である。Forbes記事が指摘する「制約の設計」とは、この違いに対する認識の欠如を突いている。
チャットボットの設計思想では「正しい回答を返すかどうか」が評価軸になる。だがエージェントの設計思想では「何を、どこまで、自分で決めてよいか」が評価軸にならなければならない。
この転換ができていない組織は、いくら高性能なモデルを使っても、業務フローの中でエージェントが暴走するか、逆に何の役にも立たないかの二択に陥る。Gartnerが2025年9月に発表した調査でも、75%の組織がAIエージェントのパイロットまたは展開を行っているにもかかわらず、完全自律型エージェントの導入を検討・実施しているのはわずか15%にすぎないと報告されている[3]。
検証レイヤーの欠落──静かな失敗
Forbes記事がもう一つ重視しているのが、検証レイヤーの問題である。
AIエージェントの失敗は、しばしば「静かに」起きる。サーバーがダウンするわけでもなく、エラーメッセージが出るわけでもない。ただ、間違った判断が、間違ったまま業務フローを流れていく。
ある業界関係者はこれを「HTTPステータスコード200の恐怖」と表現していた。システム上は「成功」と記録される。しかし実態としては、エージェントが誤った前提でタスクを完了し、その結果が次の工程に渡っている[4]。
ここで求められるのが、可観測性（observability）の設計だ。エージェントの判断プロセスを事後的に追跡可能にすること。どの情報を参照し、どのツールを呼び出し、どの分岐を選んだのかを記録すること。
これは技術的にはトレーシングやログの話である。だが、その設計思想の根底にあるのは「このエージェントの判断を、誰が、いつ、どうやって検証するのか」という問いである。
エスカレーションという名の「未回答の問い」
Forbes記事の中で、筆者が最も注目したのがエスカレーション（human escalation）の話だった。
エスカレーションとは、AIエージェントが「自分では判断できない」と認識し、人間に判断を引き渡す設計のことである。技術的にはconfidence thresholdやfallback mechanismとして実装される。
だが、ここには技術論では回収しきれない問いが潜んでいる。
「エスカレーションする」とは、結局、誰が最終的に決めるのか？
AIエージェントが「判断できない」と宣言したとき、その判断を引き受ける人間は誰なのか。その人間には、引き受けるだけの権限と情報と文脈が渡されているのか。そもそも、その「引き渡し」は設計されているのか。
多くの現場で起きているのは、エスカレーション設計の不在である。エージェントは止まる。しかし、誰に渡すのかが決まっていない。渡された側も、何をどう判断すればいいかの情報が揃っていない。
Forbes記事はこれを「アーキテクチャの問題」として整理した。その整理は的確だ。
しかし、筆者はもう一歩踏み込みたい。
これは本当に「技術問題」なのか
制約の設計、検証レイヤー、可観測性、エスカレーション。Forbes記事が挙げたこれらの論点は、いずれも正しい。
だが、ここで立ち止まって考えてみてほしい。
制約とは何か。「このエージェントが判断してよい範囲」の定義である。
検証とは何か。「この判断が妥当だったかを確認する仕組み」である。
可観測性とは何か。「判断のプロセスを後から追跡できること」である。
エスカレーションとは何か。「判断を人間に引き渡す設計」である。
これらはすべて、「判断」という行為をめぐる設計の話ではないか。それは、コードの設計ではなく、判断の設計の話である。
モデルの性能ではない。アーキテクチャの設計でもない──少なくとも、純粋な技術設計の話だけではない。
ここにあるのは、判断の構造が設計されていない という問題である。
誰が決めるのか。どこまでをAIに任せ、どこからを人間が引き受けるのか。その境界線は、どのような基準で引かれているのか。
Forbes記事が「アーキテクチャの問題」と呼んだものの奥に、もっと根本的な問いがある。それは、技術の問いではなく、組織の判断構造の問いである。
この問いに、名前はあるか
Forbes記事は、問題の所在を正確に描写した。しかし、その問題を統合的に扱う概念は提示していない。
制約・検証・可観測性・エスカレーション。これらはバラバラの技術要素ではなく、一つの設計思想の下に統合されるべきものだ。
その設計思想に、名前がある。
それが Decision Design（判断の設計） である。
Decision Designは、判断という行為そのものを設計対象とする思想だ。
その中心にあるのがDecision Boundary（判断の境界） という概念である。誰が決めるのか。
どこまでを任せ、どこからを引き受けるのか。
その線を、無自覚のまま放置せず、意図的に設計すること。それがDecision Designである。
詳細版について
本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。