今年初め、主要な最先端AIモデルが2026年の米国数学オリンピックで約95%のスコアを記録した。しかしその後、人間のパネリストの98%以上が解くことのできた一連の視覚パズルでは、スコアが0.5%未満にとどまった。このギャップは、これらのシステムがどのように動作するのか、そして購入しようとしているAIがデモ通りの性能を発揮するかどうかについて、多くのことを教えてくれる。
著名なAI研究者であるアンドレイ・カーパシー（Andrej Karpathy）は、これを「ギザギザの知性（jagged intelligence）」と呼んでいる。モデルが、専門家が苦労するような問題に難なく正解する一方で、子供でも一目でわかるような問題で失敗する現象のことだ。私は、それほど学術的ではない方向から同じ結論に達した。私は毎週、調達、法務、財務、リスク管理のチームとともに、自律型エージェントの売り込みを受けており、それらのエージェントがどこで真価を発揮し、どこで静かに崩壊していくかを見てきた。
私が学んだことは次の通りだ。モデルが最高のパフォーマンスを発揮するのは、タスクがこれまでに何度も目にしてきたパターンに似ている場合だ。数学オリンピックの問題は、大規模言語モデル（LLM）のトレーニングデータにある何千もの問題と似ているため、参考にできるものが豊富にある。一方、斬新なパズルは見たこともないようなものなので、推測するしかない。モデルに思考させてそこから抜け出させることはできないのだ。
変えることができるのは、モデルに渡す素材だ。
パターン・マッチャーに優れたパターンを与える
ビジネスにおいて、その素材とはデータである。チームが問う内容、例えば、あるサプライヤーがすべての契約を通じて実際にどれだけのコストを生んでいるのか、どの更新契約が最も大きなリスクを抱えているのかといった問いには、異なる場所に保管された情報を結合する作業が必要になる。
散在する事実を結合することは、データ内であらかじめ結合が行われていない限り、まさにこれらのモデルが最も苦手とすることだ。豊富で構造化され、関連付けられた情報をモデルに与えれば、慣れ親しんだパターンに基づいて実用的な仕事をしてくれる。しかし、連携を想定して設計されていない6つのシステムから得た断片を与えれば、自信たっぷりに無意味な回答を出力する。勝負は、モデルが関与するはるか前に決まっているのだ。
多くの買い手はこの点を過小評価している。デモではそこが隠されるからだ。私が訪れる多くの企業には同じ問題がある。契約書は共有ドライブに置かれ、ベンダーデータは法務部門と連携しない調達ツール内にあり、リスク評価は誰かが四半期に1度更新するスプレッドシートにある。義務事項は抽出されたことがなく、契約更新は追跡されていない。それが企業がエージェントの上に載せる実際のデータ環境であるなら、販売サイクルでは奇跡のように見えたエージェントが、6カ月後には期待外れに映る理由は理解できる。
いくつかのAPIとチャットインターフェースでこれらのシステムを接続するだけでは、この問題は解決しない。断片化したデータを接続しているように見せるだけで、推論に適した状態に整えることにはならないからだ。このような議論を18カ月続けてわかったことは、データの基盤が今日のエンタープライズAIにおける最大の制限要因の一つであるということだ。導入がうまくいくケースと行き詰まるケースを分けるのは、どのモデルを上に載せるかではない。その下にあるデータが整っていたかどうかだ。文脈のないパターンマッチングは、知性というよりも、類語辞典を使った推測に近い。
契約を結ぶ前に問いかけるべき質問
多くのリーダーは、自社がAIを受け入れる準備ができているかを問いかける。しかし、より適切な質問は、すでに依存しているソフトウェアが準備できているかどうかだ。
どの企業にも、他社よりも構造化の作業を熱心に行ってきたベンダーが存在する。提供するドメイン全体で、関連性があり、最新で、明確に定義された関係性の中にデータを保持しているベンダーもあれば、レコードを個別のテーブルに保存し、その間のAPIレイヤーを「統合」と呼んでいるだけのベンダーもある。これら2つは同じではなく、エージェントがどちらのデータの上に載るかによって、そのパフォーマンスは大きく異なる。
業務のいかなる部分にAIレイヤーを追加するにしても、まずは既存のシステムのうち、どのシステムがそのドメインにおける主要なデータセットを真に結びつけているかを確認することだ。別々に保持されているのでもなく、スケジュールに沿って同期されているのでもなく、システムがレコードを単に保存するだけでなく、それらがどう関連しているかを理解できるようにモデル化されている必要がある。そこにおいて初めて、エージェントは推論するに値するものを手にする。そこから始めるのだ。
現在のベンダーの誰もその作業を行っていない場合、自社で構築することはお勧めしない。データを適切に接続することはベンダーの核となる仕事であり、自社の仕事ではないからだ。例えばHubSpotが連絡先、取引、会社間の関係を管理しているように、あるドメインを所有するベンダーは、数千社もの顧客にわたってそれらのレコードがどう関連しているかをモデル化することに何年も費やしてきた。それを社内で再構築することは、ベンダーが最も得意とすべき業務を、より少ないデータと時間で引き受けることを意味し、しかもそのソフトウェアに料金を支払い続けている状態になる。そうではなく、次にシステムを選定する際には、この接続性を必須要件として扱うべきだ。
いかなる契約書に署名する前にも、すべてのリーダーが実行できるシンプルなテストがある。技術的な知識は不要だ。情報は実際にどのシステムから来ているのかを尋ねること。AIエージェントがどこかに記録されているため確実に知っている回答と、自ら導き出した回答はどれかを尋ねること。2つのシステムで意見が一致しない場合にどう対応するかを尋ねること。そして、ビジネスにとって重要だが、AIエージェントがこれまでに見たことのない事態が発生したときに何が起きるかを尋ねることだ。もし回答が曖昧であれば、そのエージェントは失敗する可能性が非常に高い。まずはデータを修復すべきであり、さもなければ自覚のないままエージェント化への移行（エージェンティック・シフト）から取り残されることになるかもしれない。
この次のフェーズから最大の恩恵を受けるのは、最も賢いエージェントを持つ企業ではないと私は信じている。そうではなく、推論するに値する基盤を構築するという、地味な作業をやり遂げた企業になるだろう。
