ITヘルプデスクは、AIが真っ先に成果を出せる領域のはずだった。

ヘルプデスクは、企業内でAIが最初に成果を上げる場所になると広く期待されていました。ところが多くの企業にとって、そこは最初に行き詰まる場所になってしまいました。この壁を突破した企業は、作業を「説明するだけ」のAIをやめ、実際に作業を「実行し」、それを確かに実行したことを証明する記録を残すAIを導入したのです。

「自分で解決してください」は、そもそも約束の全体ではありませんでした。長年、セルフサービスとは「検索し、読み、フォームに記入し、待つ」ことを意味し、作業そのものは依然として従業員が行っていました。新しい世代のツールはデモでは見栄えがよく、本番環境では失敗しました。本当に重要な数字は、実際にどれだけのリクエストが解決されたかです。

壁を突破した企業は、より鋭い問いを立てました。「どのボットが最も速く回答するか」ではなく、「AIに自社のシステム・オブ・レコード上で安全にアクションを実行させ、しかもその後で正しいことを行ったと証明させるには何が必要か」です。勝者を分けるのはモデルではなくアーキテクチャであり、自社データへのガバナンスの効いたアクセスこそが、リクエストを最初から最後まで解決させ、その作業内容を提示させることを可能にします。

これまでのツールはいずれも、チケットのライフサイクルの一つのステップを自動化しただけで、チケットが本来届けるはずのサービスそのものではありませんでした。「より賢いモデル」が答えなのかを検証するため、本ガイドはEnterprise-Benchを用います。同一のエージェントタスクを典型的なパイロットの1倍から256倍までのデータ規模で実行し、精度・効率・安全性を同時に採点します。クリーンなパイロット用ツールから実際の本番用ツールへの移行は精度を18〜19ポイント下げ、最先端モデルを丸ごと世代分引き上げても加わったのはわずか1ポイントでした。

最も明快な検証、すなわち4つの連鎖したレコード（課題 → コンポーネント → チケット → アカウント → ARR）をたどってオープンな課題を売上インパクト順にランク付けするタスクでは、同じモデル・同じデータで、ガバナンスの効いた取得が80〜95%、MCPツールチェーンはわずか10%でした。後者は末端のコンポーネントを誤った親の下にまとめ、データに存在しなかった課題とアカウントの組み合わせをでっち上げました。

違いは、モデルがデータに到達する方法です。ガバナンスの効いた取得は、ソースデータを統合ナレッジグラフへ取り込んで同期し、スキーマにセマンティックなメタデータを注釈付けし、ローカルの分析用ストアに対してSQLで実行します。エージェントのコンテキストに入るのは結果セットのみです。本ガイドは、データが増えても精度92〜97%が保たれ、1回の回答あたりのコストも上昇しないと報告しています。