端的に言えば、デモが一度成功しても AI エージェントの信頼性については何も証明されません。問うべきは、タスクを一度完了できたかではなく、毎回正しく完了できるかだからです。Microsoft が 2026 年 8 月 20 日に発表した研究では、最も強力なモデルは各タスクを一度だけ実行した場合に 65.36% のスコアを記録しましたが、二十回の試行すべてに合格したのはタスクの 25.25% だけでした。この差こそ、会議であなたを感心させるエージェントと、顧客データを安心して任せられるエージェントとの距離そのものです。
Microsoft が実際に作ったもの
このツールは Thinkingbox という名前で、MIT ライセンスのもと GitHub で公開されたオープンソースのテスト環境です。発想はシンプルかつ巧みです。ツールをエージェントに直接組み込むのではなく、MCP 互換のサーバーとして定義し、専用のバックエンドデータベースを持つ隔離されたセッション内でエージェントを実行し、実行の全トレースを記録します。
本質は採点の仕方にあります。このフレームワークは、エージェントが「やった」と言った内容を読むのではなく、タスク終了後にデータベースで実際に何が変わったかを確認します。この違いは技術的な細部ではありません。エージェントは実際には行われなかった作業について説得力のある要約を書くのが非常に得意であり、会話の記録に基づく評価はどれも、実行の質ではなく文章の質を測っているにすぎません。
この環境の上にチームは Thinkingbox-bench というベンチマークを構築しました。これは五つの領域にわたる 507 件のポリシー条件付きワークフローを含みます。小売と EC、旅行とホスピタリティ、自動車保険、ネオバンクの社内 IT サポート、そしてコンサルティング会社の IT と人事のサポートです。各タスクは、プロプライエタリとオープンウェイトの両方を含む十二のモデルで、それぞれ二十回実行されました。
この数字が経営者にとって重要な理由
店舗の返品リクエストの処理をエージェントに任せたと想像してください。成功率 65% は書類の上では許容範囲に見えます。しかし運用上は、リクエストの三分の一が誤った結果に終わることを意味します。返金が二重に発行される、在庫を戻さずに注文がクローズされる、あるいはポリシー上認められていない顧客に例外が適用される、といった具合です。
さらに悪いことに、この研究での失敗は明らかなクラッシュではありませんでした。論文は、多くの失敗がきれいに終了し、妥当に見える手順を踏んでいたにもかかわらず、システムの最終状態は誤っていたと明確に記述しています。エラーメッセージも停止もなく、監視ダッシュボードで点灯するものも何もありません。あるのは普通に読めるログと、静かに誤った状態になったデータだけです。
システムを止める失敗は厄介ですが、目に見えます。フローを最後まで完了させてデータを誤った状態のまま残す失敗こそが本当にコストを生みます。なぜなら、それに気づくのは一か月後の照合作業のときだからです。
これは、よくある失望の原因も説明しています。パイロットが合格するのは、きれいなデータでタスクを一度実行しただけだからです。実際の運用は、蓄積された乱雑な状態に対して同じタスクを何千回も実行することであり、65% と 25% の差が表れるのはまさにそこです。
エージェントを導入する前にすべきこと
- 一回のデモではなく、繰り返しの実行を求める。同じデータで同じタスクを二十回連続実行することを受け入れ基準にしてください。それを拒むベンダーは、それ自体で何かを物語っています。
- 返答の文章ではなく、データの状態を測る。タスク後にデータベースのレコードがどうなっているべきかを事前に定義し、実際の状態と比較してください。エージェント自身の要約を読むだけで満足してはいけません。
- 簡単なタスクだけでなく、ポリシーをテストする。業務の大半は自由なものではなく、返品期限、与信限度額、優先顧客向けの例外といったルールに縛られています。制約なしで成功するエージェントも、最初の現実的な条件で崩れることがあります。
- 自社の事例でテストセットを作る。ここ数か月の実際の事例を二十件選び、スタッフを戸惑わせた変わったケースも含めて、固定のテストスイートにしてください。どのモデルも導入前と毎回のアップデート後にそれを実行します。
- 権限は段階的に与える。まずは提案するが実行はしないエージェントから始め、次に影響の小さい操作を任せ、実際の測定記録が積み重なるにつれて範囲を広げます。権限は印象ではなく、データによって獲得されるべきものです。
Origami での取り組み方
AI エージェントを含むシステムを構築する際、私たちはエージェントを他のソフトウェアコンポーネントと同じように扱います。自動テストスイート、各操作の後にデータベースの状態を確認する検証チェック、そして信頼度のしきい値を超えたときに人へ引き継ぐ明確なポイントを用意します。モデル自体はコードに溶接されたものではなく、差し替え可能な設定のままにしておきます。今日の最良のモデルが三か月後も最良とは限らないからです。
この研究から得るべき結論は、エージェントが使えないということではありません。私たちがエージェントを評価してきた物差しが間違っていたということです。今日のエージェントは、明確に定義され継続的に測定される範囲の中では強力なツールですが、説得力のあるデモだけを根拠に重要なプロセスを任されると非常に脆弱です。違いはモデルにあるのではなく、それを取り巻くエンジニアリングの規律にあります。
出典
- 研究論文：One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows — arXiv（2026 年 8 月 20 日公開）
- オープンソースリポジトリ：GitHub の microsoft/thinkingbox
よくある質問
AI エージェントが「一度成功する」ことと「信頼できる」ことの違いは何ですか？
一度成功するとは、エージェントがタスクを正しく進める道筋を見つけられるということです。信頼性とは、毎回の実行で正しい道筋を見つけられるということです。Microsoft の研究では、最も優れたモデルが一度成功したのはタスクの 65.36% でしたが、二十回の試行すべてに合格したのは 25.25% だけでした。この差こそが、実際の業務に耐えうるかどうかを決めます。
自社のシステムに接続する前に、AI エージェントをどうテストすればよいですか？
同じデータで同じタスクを二十回連続で実行し、エージェントの返答を読むだけでなく、実行のたびにデータベースの状態を確認してください。また、単純化された理想的な例ではなく、例外的なケースやポリシー上の制約を含む自社記録の実際の事例を使ってください。
これは、ビジネスで AI エージェントを使うのは安全ではないという意味ですか？
いいえ。ただし、権限の範囲は印象ではなく測定に基づいて広げるべきだということです。まずは提案するだけで実行しないエージェントから始め、次に影響の小さい操作を許可し、繰り返しのテスト結果で一貫性が証明されるにつれて権限を段階的に広げていきます。
ビジネスにとって最も危険な AI エージェントの失敗はどのようなものですか？
エラーメッセージを一切出さずにきれいに終了しながら、データを誤った状態のまま残すサイレントな失敗です。たとえば、在庫を戻さずに注文をクローズしてしまうケースです。研究論文には、多くの失敗がこの種のものだったと記録されています。だからこそ、クラッシュを監視するだけでなく、データの状態を確認する必要があります。
GoogleでOrigamiをフォロー
Origamiを優先ソースに追加すると、Google検索やトップニュースで私たちの記事が優先的に表示されます。
