![\"プライマリ検索フィールドなしでインデックス登録されたドキュメント（卸売業者別）\"](\"/assets/images/b2b-search-silent-failures.png\")
B2Bコマース検索には汚い秘密がある。ランキングアルゴリズムが問題になることはほとんどないのだ。
\n結果が悪いと、チームは楽しいレバーに手を伸ばす。ブースト、同義語、埋め込み、リランカー、そして最近ではLLMによるクエリ理解。私自身もそれらすべてのレバーを引いてきた。先週、私は代わりに華やかさのないことをした。4つの本番検索インデックスからすべての製品レコード（HVAC、配管、産業用供給品、ファスナーを取り扱う4つのB2B卸売業者の775,051件のレコード）をダンプし、データそのものを監査したのだ。私は12のAIエージェントを並行して実行し、それぞれに1つの次元（カバレッジ、テキスト品質、品番、ブランド、価格、仕様、カテゴリ、メディア、重複）を割り当てた。
\n結果は、卸売業者のカタログを扱ったことのある人には何の変哲もないものだが、扱ったことのない人には衝撃的だった。しかし、私の心に残ったのはこれだ：修正方法はすでに公開されている。Amazon、DoorDash、Instacartは2年かけて、公開エンジニアリングブログで、LLMを使って大規模な乱雑なカタログをクリーニング、ラベリング、エンリッチする方法を正確に書き綴ってきた。卸売流通業界はほとんど気づいていない。これは奇妙なことだ。なぜなら、彼らのカタログはより乱雑で、クエリはより価値が高く（12ドルの昼食ではなく、4,000ドルのコンデンサーを注文する請負業者）、カタログサイズが実際に経済性を容易にしているからだ。
\nそこで、この投稿はそのプレイブックを卸売流通業界向けに適応させたものだ：B2B検索を壊すデータ問題、今日の午後にコーディングエージェントでそれらを見つける方法、UNSPSC分類を含むLLMでそれらを修正する方法、そして全体のコスト。最後のネタバレ：あなたの推測より2桁安い。
\nマーケットプレイス企業が公開したものの一部：
\n共通の糸は見逃しやすい：LLMの勝利はカタログ側とオフラインにある。これらの企業は、単一のクエリが到着する前にデータをエンリッチする。ディスカバリーシステムは、アーティファクト（カタログ、インデックス、埋め込み）を構築するオフライン側と、それらを検索・ランク付けするオンライン側に分割され、公開されたLLMの価値のほぼすべてがオフラインに置かれている。ランキングレイヤーは、与えられたものと同じくらいしか良くなり得ない。
\n次に、典型的なHVACまたは配管卸売業者のカタログをそれと比較してみよう。それは、ERPエクスポート、サプライヤーのスプレッドシート、購買グループのフィード、そして誰かが10年前に書いたCSVパーサーから継ぎ合わされている。製品の「タイトル」は、倉庫のピッカー向けに書かれた請求書の略語である。そして、それにヒットする検索トラフィックは、検索トラフィックとしてこれ以上ないほど意図密度が高い：半分は正確な品番、残りは「3/4 cxc 90 ell」のような業界用語だ。正直なところ、このプレイブックにこれ以上適した環境は考えられない。クエリは価値があり、データは修正可能で、数十万SKUであれば、カタログ全体に対する完全なLLMパスは数百ドルで済む。数百万ドルではない。数百ドルだ。
\n監査の概要は以下の通り。再現したいと思うだろうから：
\nflowchart TD\n D[\"Raw catalog dump
(JSONL, one record per line)\"] --> C1[\"Per-catalog coverage agents
null rates, distributions, dead fields\"]\n D --> C2[\"Dimension agents
text · part numbers · brands · pricing
specs · categories · media · duplicates\"]\n C1 --> S[\"Synthesis: findings ranked by
severity, with example records\"]\n C2 --> S\n S --> F[\"Fix pipeline: rules + LLM enrichment
+ UNSPSC classification + ingest gates\"]\nプロンプトの前にフォーマットについて一つ注意。以下のすべては、汎用的なダンプで動作する：1行に1つのJSONオブジェクトで、それぞれに一意のidとレコードのフィールドが含まれている。Elasticsearch、OpenSearch、Solr、Algolia、Typesense、PIM、プレーンなデータベースエクスポートなど、どのプラットフォームでも構わない。すべてのプラットフォームがこの形状を生成でき、ここでのすべてのプロンプトはそれに対して実行される。
私が見つけた最悪のものは、誰かが書いた悪いデータではなかった。それは、パイプラインが取り込み時に誰にも知らせずに破壊したデータだった。
\nこれらのカタログは、取り込み時にプライマリ検索テキストを構築する。スクリプト化された正規表現を使用して、製品タイトルから寸法と単位を抽出する。長いタイトルでは、正規表現がエンジンの複雑さの上限を超え、プロセッサが失敗し、レコードは誰も読まないエラーフィールドとプライマリ検索フィールドなしでインデックスに登録される。
\n
全体で、52,570件のレコードがインデックス内にあり、メインのクエリパスから見えなくなっていた。最悪のカタログでは、7製品に1つの割合だ。何も失敗しなかったため、ダッシュボードはそれを捕捉しなかった。パイプラインは毎日、何ヶ月も成功を返し続けていた。
\n同じ系統からのさらに2つの発見。古いミラー：1つのフィールドが真実（アカウントごとの権限マップ）を保持し、2つ目のフラット化されたフィールドがフィルタリング用にそれをミラーリングしている。あるカタログでは、ミラーがレコードの19.85%（31,000のアクティブな製品）でずれていたため、アカウントフィルタリングされた検索から誤って隠されていた。そして、凍結されたカタログ：1つのインデックスが10週間更新されておらず、同じグループの他のインデックスは毎日更新されていた。アップタイムは監視されていた。フレッシュネスは監視されていなかった。
\n修正方法は退屈で、それがポイントだ。派生フィールドのカバレッジ（ソースが空でないのに派生フィールドが空）をアラートする。1つの事実の2つの表現を維持しない。フィルタリング可能なフィールドを書き込み時に導出する。アップタイムを監視するのと同じように、カタログごとにデータの鮮度を監視する。
\nこれを自分のカタログで見つけるためのプロンプトはこちら（Claude Codeまたはcodex exec、仕組みは最後に）：
ここに私の製品カタログのダンプが ./dump/ 内のJSONLファイルとしてあります。各行は1つのJSONレコードで、それぞれに一意の「id」と製品フィールドがあります。私のフィールド/スキーマ定義（ある場合）は schema.json にあります。（プロンプトの残りは、静かなパイプライン障害を見つけるためのストリーミングPythonを書くように指示している）
\nNullチェックは、誰もがすでに持っているデータ品質ツールだ。プレースホルダーはそれらを無効にする。なぜなら、プレースホルダーは入力されているからだ。ただ真実ではないだけだ。
\n私のお気に入りの例：ある313K SKUのカタログでは、ブランドフィールドに741の異なる値があり、99.99%の入力率だった。健全に聞こえる。トップの値は、全レコードの88.8%を占め、「承認済みベンダー」だった。ERPのプレースホルダーだ。最も人気のある実際のブランドは、カタログの0.3%をカバーしていた。したがって、すべてのブランドファセット、ブランドブースト、ブランド認識リライトは、カタログの9割に対して事実上死んでいた。一方、ファセットUIは陽気にも「承認済みベンダー」を一番のブランドフィルターとして提供していた。
\n探し始めると、この種のものはいたるところにある：
\n99999999.000000。そのインデックスの価格の中央値は9900万ドルだった。\"unknown\" という製品名が64件のレコードにあり、それがクエリ「unknown」でランクインする。true が1,516件のライブ製品のテキスト説明フィールドに書き込まれている。エンジンはそれを文字列「true」に強制変換し、それらの製品が「true」で検索可能になった。\"6.71E+11\" として保存されている。Excelの指数表記で、51の無関係な製品がその1つの「識別子」を共有している。さらに15,121件のUPCは先頭のゼロが欠落している。Excelの仕業だ。このカテゴリから私が学んだ教訓：Null率ではなく、フィールドごとのトップN値の分布を監査する。100%入力されたフィールドは88%がガラクタである可能性があり、Nullチェックは決してそれを教えてくれない。次に、取り込み時にセンチネルをブロックリストに登録し、明示的な has_price / has_real_image フラグで実際のNullにマッピングし、境界で型をアサートし、識別子を構造的に検証する。スプレッドシートを通過したことのあるものはすべて疑わしいと扱う。
同じJSONLダンプ。私のカタログのすべてのフィールドについて、トップ20の値の分布を計算する（完全パス、ストリーミング）。（プロンプトの残りは、プレースホルダー、型の不一致、不正な識別子などをフラグするように指示している）
\n卸売業者のカタログは、マーチャンダイザーではなくERPによって書かれている。テキストは請求書の略語だ：PROPRESS 2-1/2X1 CXC RED CPLG、HC HX 18X8 W。あるカタログでは、製品名の3分の1が60%未満の辞書語だった。別のカタログでは、生の名前と説明フィールドが100% nullだった。テキストは派生検索ブロブ内にのみ存在していたため、生のフィールドを読むもの（結果タイトル、埋め込み入力、関連性判断プロンプト）は何も読んでおらず、誰も知らなかった。
![\"4つのB2Bインデックスにわたるフィールドカバレッジ\"](\"/assets/images/b2b-search-field-coverage.png\")
そのヒートマップは、監査から得た私のお気に入りのアーティファクトだ。それらのフィールドのすべてがすべてのスキーマに存在する。数字は、それぞれが実際にどれだけのデータを保持しているかを示している。私が気になる行はML-descriptionsのものだ：スキーマが約束したエンリッチメントレイヤーは、775,051件中18件のドキュメントに入力されていた。18件だ。スコアリングパイプライン内の「エンリッチメントが存在すれば使用する」というすべての分岐は、静かなノーオペレーションだった。スキーマは願望であり、カバレッジだけが事実だ。
\nこのカテゴリは、公開されたプレイブックが最も直接的に適用される場所である（DoorDashの属性抽出、Instacartのオフライン生成）。以下のコストセクションで価格を提示する。しかし、品番ビジネスでは4つのルールが重要であり、以前のエンリッチメントの試みが何を間違えたかから部分的に学んだ：
\n{size, material, connection_type} を出力できる。CXC、ELL、CPLG、「t-stat」はアナライザーレベルの同義語拡張に属し、一度修正すればよい。それらを50万件のレコードに書き換えるためにお金を払わない。同じダンプ。完全なストリーミングパスで、顧客向けフィールド（名前、短い/長い説明）のテキスト品質を評価する。（プロンプトの残りは、効果的なタイトルのカバレッジ、可読性、ジャンク、重複、エンリッチメントの現実をチェックするように指示している）
\nB2B検索トラフィックの半分は、誰かが品番を入力している。完全一致がそこでのすべてであり、それは静かな方法で失敗する。
\nあるカタログでは、インデックスされた品番はレコードの99.99%で内部的な数値SKUだった。メーカーの番号（箱に印刷されているもの）は、フリーテキストの説明内にのみ存在していた。183,000の製品が、顧客が実際に入力する番号では到達できなかった。
\n別のカタログには、バリアント拡張システムがあった：ダッシュを削除し、セグメントを折り畳み、寛容なPN検索が機能するようにバリアントをインデックスする。良いアイデアだ。しかし、ジェネレーターは組み合わせ的であり（製品あたり最大80のバリアント）、11,826のレコードで、ある製品の生成されたバリアントが別の製品の標準的な品番と正確に一致した。ファスナーは残酷なケースだ。なぜなら、句読点が物理的な寸法をエンコードするからだ：702-1-5/32 は1-5/32インチの部品であり、702-15/32 は15/32インチの部品であり、両方とも 7021532 に正規化される。顧客が正確な品番を入力すると、正しい部品とその寸法上のいとこの間でコイン投げになる。
また、このカテゴリには、競合他社の相互参照（「ファーガソンの番号は持っているが、あなたの番号は？」）が、分割されていないパイプ区切りのブロブ（19MU82|Fastenal 0269214|Ferguson M48222407）として、検索不可に設定されたフィールドに保存されている。そのため、コアなB2B販売の動きが機能しない。そして、空白のフォーク（同じ品番が3回インデックスされている：プレーン、NBSPパディング、末尾スペース）に加えて、二重デコードされたUTF-8からの文字化けした双子。
これのほとんどを修正する原則：完全一致は、確率的ではなく構造的にファジーより優先されなければならない。句読点を保持する完全一致節は、正規化されたティアよりも厳密に上位にスコアリングされ、バリアントが標準的なヒットと同点になるフラットな一致は決してない。生成されたバリアントをインデックスする前に標準的なPN空間と照合し、衝突をドロップする。レコードIDを導出する前にUnicode正規化する。相互参照のブロブを配列に分割する。それは1行の取り込みコードであり、クエリのクラス全体をアンロックする。
\n同じダンプ。私のユーザーは品番で検索する。完全一致の整合性を監査する。（プロンプトの残りは、PNフィールド、内部SKU、バリアントの衝突、空白の違い、区切られたブロブをチェックするように指示している）
\n上記に収まらなかったが、一文に値するいくつかのこと：任意の数字をワイヤーゲージ用語に変える同義語ジェネレーター。そのため、REF#259286 は「259286 awg」になり、#8-32 ネジ山は「8 gauge wire」になった（何千ものレコードが、関係のない電気クエリと一致するようになった）。eコマースプラットフォームの内部フラグが検索可能な製品仕様としてインデックスされ、210万のジャンクなキーと値のペアになった。そして、18のスキーマフィールドがどこにも入力されていない。拡張ジェネレーターにはコンテキストゲートが必要だ。死んだスキーマは、誰かがいつか構築するであろう誤った約束である。
ここでは、独自のセクションに値する5番目の問題がある。なぜなら、ここが卸売流通業界がマーケットプレイスに最も遅れを取っている場所だからだ：分類である。
\n私の監査では、カテゴリフィールドが1つのカタログの83%で欠落していた。属性キーにはまったく分類体系がなかった。1つの156Kレコードのカタログに7,068の異なるスペックキーがあり、その64%が10未満の製品で使用され、horse_power と horsepower のようなドリフトが同じ属性をファセット間で分割していた。そして、私が何度も思い返す詳細：4つのカタログのうち2つには、UNSPSCフィールドがスキーマにあり、マッピングされ、準備ができていたが、正確にゼロのレコードに入力されていた。誰かが分類が重要であることを知っていて、スロットを構築し、決して埋めなかった。その理由に賭けてもいい：300KのSKUを手動で分類体系に分類することは、カタログチームの1年の作業であり、そのためロードマップに永遠に残っていたのだ。
B2Bの外にいる人のために説明すると、UNSPSCは国連標準製品・サービスコードであり、調達システムが話す分類体系である。これはコンシューマー検索にはないものだ：あなたの顧客の購買システムがそれを必要とする。パンチアウトカタログ、e調達プラットフォーム、支出分析ツールはUNSPSCコードを中心に構築されている。クリーンなコードを持つカタログを持つ卸売業者は、請負業者や病院の購買システムに接続できる。それがないものは、検索ボックス付きのPDF価格表である。内部的には、カテゴリファセット、カテゴリ範囲のランキング（「ワイヤーゲージとして解析される数値はワイヤーのみをブーストするべき」）、カタログ間の重複排除、およびカテゴリ4のすべての拡張ジェネレーターのコンテキストゲートを動かすものでもある。
\nそして、それは今やバッチジョブである。これはDoorDashがLLMで解決すると説明している問題と同じ形状である（管理された語彙に対する大量ラベリング）。アプローチは直接転送される：
\nコストは書くのが恥ずかしいほど安い。分類は短い出力タスクである：レコードあたり約300の入力トークンと30の出力トークン。Claude Haiku 4.5のバッチAPI価格では、1,000 SKUあたり約17セントだ。私の775Kレコード全体は約130ドルで分類されるだろう。手動作業の1年だったために何年もロードマップに載っていたものが、それを議論するチームランチの費用よりも安いのだ。
\nあなたはB2B卸売業者の製品をUNSPSCに分類します。添付：UNSPSCファミリーリスト（レベル2、約450エントリ）を参照データとして。（プロンプトの残りは、製品レコードごとにUNSPSCファミリー、信頼度、根拠を出力するように指示している）
\n修正パイプラインには、分類ジョブに加えて3つのティアがある。コツは適切なティアに費やすことであり、レコードごとにLLM呼び出しがほとんど必要ないからだ。
\nflowchart LR\n A[\"Tier 0 - Rules
deterministic code
~$0\"] --> B[\"Tier 1 - LLM on unique values
brands · spec keys · units
tens of dollars\"]\n B --> C[\"Tier 2 - LLM per record
titles · attributes · UNSPSC
hundreds of dollars\"]\n C --> G[\"Ingest gates
every fix becomes a validator\"]\nティア0は決定論的コードであり、基本的に無料である。 HTMLを削除し、エンティティをデコードする。センチネルを明示的なフラグで実際のNullに変換する。UPCを修正する（左パディング、指数表記を拒否、チェックデジットを検証）。IDをUnicode正規化する。パイプ区切りの相互参照を分割する。別の製品の標準番号と衝突するPNバリアントをドロップする。死んだスキーマを削除する。エージェントが1セッションでこれらのスクリプトを作成し、このティアは監査で見つかったすべてのものの約半分を修正した。エンリッチメントの前にこれを行う。そうしないと、パイプラインが静かにドロップした製品のタイトルを美しく書き換えるためにお金を払うことになる。
\nティア1は、レコードではなく一意の値に対してLLMを実行する。 これが語彙問題を安くするトリックだ：私の最悪のカタログは313Kレコードあったが、ブランド文字列はわずか741の異なるものだった。ブランド正規化は、741の文字列に対する1つのジョブである。ケースのバリアントをクラスタリングし、サブブランドを親にマッピングし、プレースホルダーをフラグする。313Kの呼び出しではない。各語彙ジョブは一桁のドルであり、その出力は取り込みが永久に適用する静的なエイリアステーブルである。ティア全体を、主にレビューパスに費やされて、フリートで20〜50ドルと呼ぶ。
\n添付：私のブランドおよびメーカーフィールドの完全な異なる値の分布（値、レコード数）。正規化テーブルを生成する。（プロンプトの残りは、正規化テーブルと適用スクリプトを生成するように指示している）
\nティア2はレコードごとのパスである： すべての製品に対する、顧客が読めるタイトル、検索拡張、構造化属性、および復元されたメーカー品番。SKUあたりそれは小さい。約400の入力トークン（レコードと、プロンプトキャッシングがほぼ無料にする共有命令）と250の出力。モデルを選ぶ前に2つのレバーがある：ライブのものをエンリッチする（私の最悪のカタログではレコードのわずか14%がアクティブだった。86%の削減だ）。そして、プロバイダーが持っている場合はバッチAPIを使用する。エンリッチメントにはレイテンシ要件がなく、AnthropicとOpenAIの両方がバッチで50%オフにするからだ。
\n私は2026年に使用する可能性のあるすべてのモデル（Claude、GPT-5.6の3ティア（Sol、Terra、Luna）、Kimi K3、GLM-5.2、Qwen3.5、DeepSeek V4）で同じジョブの価格を調べた。同じワークロード、プロバイダー公表価格、バッチ割引が存在する場合は適用した。
\n![\"モデル別の775K](\"/assets/images/b2b-search-enrichment-cost-by-model.png\")
これらの数字は間違っているように感じたので、再確認しなければならなかった。このプロジェクトの最悪のケース（フロンティアモデル、すべてのSKU、フィルタリングなし）は、約3,800ドルで頭打ちになる。下限は100ドル未満だ：DeepSeek V4-Flashは、まともなドリルの価格でフリート全体をエンリッチするだろう。実際に実行するバージョンはティアを混合する：機械的な大部分には予算モデル（Haiku、Luna、Qwen Flash、DeepSeek）、小さなモデルが低信頼度としてフラグする略語サラダのテールにはミッドティアモデル（Sonnet、Terra、GLM-5.2）、そして品質ゲートとして1〜2%のサンプルをスポットチェックするフロンティアモデル。選択するベンダーに関係なく、ライブSKUで数百ドルになる。
\nチャートが示せない2つの注意点。安いモデルは、その出力が評価に耐える場合にのみ安い。コミットする前に200サンプルの比較を実行する。なぜなら、品番の5%を台無しにする予算モデルは、そうしないフロンティアモデルよりもコストがかかるからだ。そして、あなたのカタログは競争力のあるデータである：価格、相互参照、顧客品番がそれらのレコードに含まれている。したがって、リスト上で最も安いエンドポイントに775Kレコードを送信する前に、各プロバイダーのデータ保持とトレーニング条件を確認する。多くの卸売業者にとって、その確認だけで一部のベンダーが対象外になり、オープンウェイトのオプション（DeepSeek、GLM、Qwen、Kimi）には、データをまったく外部に出せない場合にセルフホストできるという追加の特性がある。
\n約130ドルのUNSPSCパス（同じようにモデル間でスケーリングする。予算ティアでは小銭に落ちる）と語彙作業を追加すると、カタログ変換全体は、かつてマーチャンダイジングチームの1年だった作業に対して、数百ドルから数千ドルの間で実行される。これはInstacartが説明するのと同じオフラインバッチ経済であり、単に卸売カタログの規模で、数字がクレジットカードで支払えるほど小さくなるだけだ。
\n私の監査からの実際のレコードでどのように見えるか：
\nIN: part_number: 1678619\n short_desc: PROPRESS 2-1/2X1 CXC RED CPLG 20685\n brand: (placeholder)\n\nOUT: display_title: 2-1/2\" x 1\" ProPress Copper Reducing Coupling\n search_expansions: [\"copper press fitting\", \"reducing coupling\",\n \"press x press coupling\"]\n attributes: {size_1: {value: 2.5, unit: in},\n size_2: {value: 1, unit: in},\n material: copper, connection: press}\n extracted_mpn: \"20685\"\n unspsc_family: 4017 (pipe fittings)\n confidence: high\nextracted_mpn 行を見てほしい。同じパスが、以前は説明テキストに埋もれていたメーカー品番を復元する。私のカタログの1つでは、それは183,000の製品が箱に印刷された番号で見つけられるようになることを意味する。それだけでバッチジョブの代金を支払う。
あなたはB2B卸売業者の製品レコードを検索用にエンリッチします。各入力レコード（生のERP名、説明、ブランド、品番、カテゴリ）に対して、JSONを生成します。（プロンプトの残りは、display_title、search_expansions、attributes、extracted_mpn、confidenceを出力するように指示している）
\n2つの運用上の注意：共有命令をキャッシュされたプロンプトプレフィックスに配置する（キャッシングはバッチ割引に加えて入力側を最大90%削減する）。そして、JSONスキーマで構造化出力を使用して、解析失敗の税金を決して支払わないようにする。
\n最後のティアは人々がスキップするものであり、それが効果を増幅させるものである。 監査は1回のクリーンアップの価値がある。それが生成するバリデーターは、将来のすべてのフィードの価値がある。修正セッションを次のように終了する：
\n修正したすべての問題を、取り込みパイプラインを大声で失敗させる自動チェックに変える：派生フィールドカバレッジアサーション、センチネルブロックリスト、テキストフィールドの型アサーション、識別子チェックサム検証、PNバリアント衝突チェック、ID衛生ルール、UNSPSCカバレッジ追跡、およびカタログごとのデータ鮮度アラーム。CIが新しいフィードのサンプルに対して実行するテストとしてそれらを出力する。これをスキップすると、同じERPエクスポートが四半期内に同じガベージを再生成し、クリーンアップに2回支払うことになる。私の監査で見つかったバグのうち2つは、明らかに以前に修正されており、そして戻ってきていたからだ。
\n1つのセットアップ手順：カタログをJSONLにダンプする。1行に1つのJSONオブジェクトで、一意の id とレコードのフィールドを持つ。プラットフォームが何であれ（Elasticsearch、OpenSearch、Solr、Algolia、Typesense、PIM、その背後にあるデータベース）、エージェントにエクスポーターを書かせるだけだ：
私のカタログ [説明：検索インデックス名 / データベーステーブル / PIMエクスポート] からすべての製品レコードを ./dump/records-{n}.jsonl に50Kレコードのチャンクでエクスポートするスクリプトを書いてください。各行は1つのJSONオブジェクトで、一意の「id」とすべてのフィールドを持ちます。また、私のフィールド/スキーマ定義（プラットフォームにある場合）を schema.json にエクスポートします。エクスポートされた数がソースの数と一致することを確認してください。Claude Codeを使用すると、任意のカテゴリプロンプトをそのディレクトリのセッションにドロップする。それ自体で分析を書き、実行する。完全なパスで、サンプリングの言い訳はなく、レコードレベルのレシートを持って戻ってくる。「今すぐ修正」と言うと、同じセッションが取り込みバリデーター、バックフィルスクリプト、バッチエンリッチメントジョブを生成する。カテゴリを並列セッションまたはサブエージェントとして実行する。それが私の実行方法であり、監査全体のウォールクロック時間は約12分だった。Codexでは、codex exec が同じプロンプトを使用して読み取り専用の分析パスを処理する。書き込み側の修正は、レビューするセッションに保持する。
私が苦労して学んだ3つのルール：
\nAmazon、DoorDash、Instacartは、慈善事業としてカタログLLMの研究を公開したわけではない。彼らが公開したのは、その技術が一般的であり、堀が実行にあるからだ。そして、その技術は、私が考えられる他のほとんどどこよりも、卸売流通業界にうまく転送される：カタログは完全なパスが安いほど十分に小さく、データは見込みが莫大であるほど十分に悪く、クエリは実際のお金を運び、調達の世界はすでにバッチジョブが約130ドルで入力できるようになった分類体系で実行されている。
\n私の監査が4つの卸売業者カタログにわたって明らかにした数十の問題のうち、ランキングレイヤーから見えるものは一つもなかった。それらのすべてがそれを劣化させていた。それらのインデックスを供給するサプライチェーン（ERPエクスポート、サプライヤーのスプレッドシート、古いCSVパーサー）は、まさに公開されたプレイブックが修正するものである。それを実行する卸売業者は、競合他社がまだコンデンサーコイルを見つけられないカタログで、マーケットプレイス品質の検索を持つことになる。
\n「私のデータに何か問題があるか？」という質問は、かつては誰かの2週間の時間を要した。だから誰もそれを尋ねなかった。今では1つのプロンプトで済む。尋ねてみよう。
", "source_hash": "sha256:beacaae673c45f36f13a5677632c8df46a2339c6bdea51c65c49f762d7f0805c", "model": "deepseek/deepseek-v4-flash", "generated_at": "2026-08-07T08:10:56.237332+00:00" }