AIモデルの「できる／できない」を、ベンダー単位のラベルだけで判断すると危ういかもしれない

「このモデルは検索に対応している」「対応していない」という、ベンダー単位のざっくりした機能表は、思っている以上に当てにならない。筆者は新しいAI API「Muse Spark」の公式発表に、パートナー企業が「引用付き検索の組み込み」に言及していたのを見て、導入の検討を始めた。実際にAPIへweb_search系のパラメータを3通りの方法で渡したところ、今回試したエンドポイントとパラメータでは、いずれも400エラーが返ってきた。同じ検証をGLMとDeepSeekにも行ったが、少なくとも試した設定では検索が実行された形跡は確認できなかった。さらに、以前「検索不可」と分類していたGeminiについても、その分類の根拠が薄かったのではないかという疑問が生まれた。原因はまだ分からず、再検証が必要だという。

AIの鬼の視点で言えば、この記事の本当の主役は「Muse Spark」ではなく、「できる・できない」という分類そのものだ。機能表は一度書かれると、誰も確かめ直さないまま社内の常識になっていく。しかも、モデルの版、エンドポイント、渡すパラメータの組み合わせによって結果が変わるのに、表には一行で「対応」と書かれてしまう。筆者が「名前から受ける期待」に引きずられた、と正直に書いているのも良い。名前の響きで期待し、ドキュメントの一文で期待し、実際に叩いて裏切られる。この順番こそ、AIの導入判断で多くの組織がはまる落とし穴そのものだ。また、空のレスポンスを返して、エラーすら出さない挙動も、デバッグを見落としやすい厄介な性質として記録しておく価値がある。

中小企業の実務に落とすなら、一言で言えば「カタログの丸印を信じる前に、自社の使い方で一度叩いてみる」ことだ。API連携を検討するときは、ベンダーの説明に書かれた機能を、使うモデル名、接続方法、送る形式まで指定した上で実際に試し、確認した日付と結果を社内の記録に残しておく。ひとつのモデルで「検索は使えない」と判断して導入を見送っていた案件があれば、もう一度その判断の根拠を確かめる価値がある。今日の分類が、来月も正しいとは限らないからだ。