モノタロウが約2800万点の商品を対象にした「購買エージェント」を、プロジェクト開始から4か月で限定公開まで持っていった事例が公開されました。目を引くのは開発期間の短さですが、私が重要だと考えるのは「AIに任せない範囲を先に決めた」という設計判断のほうです。生成AIを業務に組み込もうとしている開発会社にとって、ここは再現できる部分があります。
要点 (出典の事実のみ)
- モノタロウは事業者向け間接材ECで、取扱商品は約2800万点。生成AIを組み込んだ「購買エージェント」を開発し、プロジェクト開始の2025年12月から4か月後、2026年3月末に開発完了・限定的な本番公開に至った。
- 設計方針は全てをLLMに任せないハイブリッド。長年作り込んできた自社の検索エンジンと蓄積した顧客データ基盤を土台に、追加で必要な部分だけにAIを使う構成とした。AI機能は Amazon Bedrock を採用し、APIで接続している。
- 動作は、ユーザーの要望が「具体的な商品検索か、やりたいことか」を判定 → 顧客属性などからコンテキストを追加 → 生成AIが検索クエリを作成 → 自社の検索エンジンで商品検索 → 再度生成AIが検索結果に根拠を付加、という流れ。
- レスポンスは開発当初の約30秒から公称約8秒へ短縮。サブエージェントによる内部の並列処理と、結果が出そろう前に1行目の表示を開始する工夫による。
- 開発着手の動機は危機感だった。常務執行役CTOの普川泰如氏は「汎用的なAIチャットの普及によって、お客さまが当社のWebサイトに来たときには、既に商品を特定しているケースが増えている。これによって、当社のWebサイトでお客さまのデータを収集できなくなる」と述べている。
- 前提として2024年にベクトル検索を追加し、検索結果が0件だったケースが70%減少していた。また業種・職種や購買履歴を使い、「手袋」の検索で医療系にはニトリル手袋、製造業には耐熱・耐切削の手袋を上位に出す作り込みがある。建設業界の顧客が「ねこ」と検索すると一輪車を出す、といった業界用語への対応も行っている。
- 課題も明言されている。型番検索や用途検索には改善余地があり、生成AIの検索結果にはばらつきがあり再現性がないため、全ログを保存して追跡するオブザーバビリティの強化が必要としている。全ユーザー公開時にはトークンのコスト増が見込まれ、小規模言語モデル(SML)の検討も視野に入れている。
「AI任せにしない」は消極策ではなく、責任範囲の設計
この事例は「AIを控えめに使った慎重な例」として読まれがちですが、私はそうは読みません。確率的に振る舞う部品と、決定的に振る舞う部品を、意図的に分けた設計だと見ています。
生成AIに検索そのものをやらせると、精度・速度・コストのすべてがモデルの挙動に人質を取られます。モノタロウの構成では、クエリの意図解釈と結果への根拠付けという曖昧さを扱う仕事だけをAIに渡し、2800万点から実際に商品を引く仕事は自社の検索エンジンが持っています。ここが分かれていると、「間違った商品が出た」ときに原因がクエリ生成側なのか検索側なのかを切り分けられます。全部LLMに通す構成では、この切り分けができません。
普川氏が「結果にばらつきがあり再現性がない」「全ログを保存して追いかけるオブザーバビリティが必要」と述べているのも示唆的です。これは実際に運用に乗せた人しか出てこない言葉です。 デモが動くことと業務に乗ることの差が、この2文に凝縮されています。
4か月で出せた理由は、速く作ったからではない
短期リリースの理由として挙げられているのは、機能を役割ベースに分解してコンポーネント化し、開発するものとしないものを分離したことです。これは順序が本質だと思います。速く作る技術があったのではなく、作らないものを先に決めたから4か月で済んだ、という話です。
そして「作らなくてよい」と判断できた最大の理由は、既に強力な検索エンジンと顧客データが手元にあったことです。同社は「フルスタックEC」と呼ぶ内製体制を敷き、システム開発だけでなくデータ分析やカスタマーサポート、事業部門まで社内に持っています。4か月の裏には、それ以前の長い蓄積があります。 ここを飛ばして「うちも4か月で」と考えると、たいてい失敗します。
この構図は、私が最近続けて書いている「AI投資はどこで回収されるか」という観点と一致します。シーメンスが過去最高益を出したのはAIを作っていない層だったし、ByteDanceが収益化のために選んだのは業務の入口を押さえる組織再編でした。モノタロウも同じで、AIそのものではなく、AIに渡せる自社データを持っていたことが効いています。
開発会社の事業判断にどう効くか
三つ挙げます。
一つ目。提案の構成を「LLMでやること/やらないこと」の線引きから始める。 顧客に生成AIを提案するとき、モデルの選定や精度の話から入ると比較検討が長引きます。「どの処理を確率的な部品に任せ、どこを既存の決定的な仕組みに残すか」を最初に握れば、見積もりも運用設計もそこから決まります。モノタロウの構成はそのまま説明資料に使える形をしています。
二つ目。顧客が持っているデータ資産を、AI導入の前提条件として棚卸しする。 モノタロウが強かったのは、業種・職種・購買履歴・口コミという、外部のAIが持っていないデータを持っていたからです。逆に言えば、この蓄積が無い状態でエージェントを作っても、汎用AIチャットに勝てる要素がありません。AIが業務基盤なしには機能しないという話と同じ構造で、社内RAGの構築でも費用の大半は結局データ整備側に寄ります。
三つ目。運用と観測を見積もりに入れる。 再現性の無さとオブザーバビリティの必要性は、モノタロウほどの体制でも課題として残っています。生成AIを組み込む案件では、監視基盤が人間スケールの前提のままだと破綻します。ログ保存・追跡・コスト監視を初期構築に含めていない提案は、公開後に必ず追加費用の話になります。SMLへの移行検討まで言及されているのは、トークンコストが運用フェーズの主要な変動費になることを示しています。
誤読しやすい点
「AIに全部任せないのが正解」と一般化するのは早いと思います。モノタロウの判断が合理的なのは、任せなくて済むだけの検索エンジンとデータが既にあったからです。何も無い状態から始める会社が同じ構成を真似ると、単に開発量が増えるだけになります。手元に何があるかによって、AIに渡すべき範囲は変わります。
もう一つ、この事例で見逃せないのが開発の動機です。汎用AIチャットの普及で顧客が自社サイトに来る前に商品を決めてしまい、自社で顧客データを収集できなくなるという危機感が出発点でした。これはECに限らず、AIの主導権がモデルから業務の入口へ移っている流れの中で、多くのBtoB事業者が次に直面する課題だと考えています。同じくBtoBで基幹API連携を核にしたミスミのAIチャットと並べて読むと、業界としての方向が見えてきます。
出典: 「2800万点から目当ての1品へ」 モノタロウが4カ月で実装した、AI任せにしない独自検索機能 (ITmedia エンタープライズ、2026年8月6日／AWS Summit Japan 2026 での常務執行役CTO 普川泰如氏の講演を編集部が再構成)
