カリフォルニア州フォンタナの3PL事業者は昨春、「現場のSOPの質問には何でも答える」AIアシスタントに約$45,000を投じた。デモは完璧。ベンダーのパイロット報告書は94%の満足度をうたっていた。稼働開始から30日後、安全管理者がログを調べると、回答の4件に1件近くに何かしらの誤りがあった——誤った積み上げ高さ、誤った温度しきい値、誤った顧客の梱包ルール。アシスタントはどれも自信満々、体裁の整った引用付きで回答していた。
ベンダーが資料に載せない部分がここからだ。検索拡張型の倉庫アシスタントは、言語モデルが愚かだから失敗するのではない。周りのエンジニアリングが未完成のままだったから失敗する。この1年でこの手の導入がつまずくのを4件見てきたが、失敗パターンは一貫していて、もはや暗唱できるほどだ。
誤答は本当はどこから生まれるのか
最初の失敗ポイントはリトリーバル（検索）であり、私が見てきた被害の大部分はここにある。倉庫の文書——SOP、設備マニュアル、顧客SLA——は通常、固定サイズのチャンク（500トークンずつ）に刻まれ、ベクターストアに埋め込まれる。作業員が「フォークリフトはコールドチェーン区画内で充電できるか」と尋ねると、システムは屋外の充電小屋向けに書かれた3年前のバッテリー室ポリシーを取り出し、権威ありげでまったく適用できない回答を組み立てる。チャンクは文脈を失い、埋め込みは表面的な類似性しか理解していない。
2つ目の失敗ポイントは文書のバージョン管理で、こちらは陰湿だ。倉庫の文書はITの想定より速く変わる。顧客マネージャーの一言でSOPがv2からv3になり、誰かが新しいフォームを壁に貼り出す。古いPDFは「置き換え済み」のフラグも適用日のフィルターもなく知識ベースに残る。モデルにはどのバージョンが最新か分からない——単にスコアの高い断片を組み立てるだけだ。フォンタナでは、アシスタントが積み上げ制限について「SOP v3.2 第4節」を引用したことがある。その倉庫がv3.2を作ったことは一度もない。モデルはv2の節とv3の節を融合させてバージョン番号を捏造したのだ。ハルシネーションは「無」からではなく、半分だけ真実の断片から組み立てられることが多い。
3つ目の失敗ポイントは知識の境界だ。作業員は知識ベースの外の質問をする：地域の最低賃金の変更、隣の人材派遣会社の時給、HRポリシー。設計の良いアシスタントなら「それは分かりません——上長に聞いてください」と言うべきだ。だがデフォルト設定のモデルは「知らない」と言うのを嫌う。でっち上げる。そしてでっち上げた数字には小数点が付いてくるから、信用できそうに見える。
ゴールデンセット：モデル選びの前に50〜100問を用意せよ
いま私が事業者に伝えるアドバイスは率直だ。モデル選びから始めるな。評価セットから始めろ。
レシピは単純だ。シフトリーダーと安全管理者に、「間違えたら人が怪我をする」質問を各20問ずつ挙げてもらう：積み上げ制限、通路のクリアランス、危険物の隔離距離、コールドチェーンのアラームしきい値、顧客ごとの梱包ルール。次に、従業員が実際に尋ねた3か月分の質問を集め、上位30〜50件を取る。これで50〜100項目になり、各項目にベテラン作業員とコンプライアンス責任者が承認した「ゴールデン回答」を付ける——条項番号と適用バージョンまで。
このセットには3つの役割がある。1つ目、稼働前に実行する。ゴールデン回答との完全一致率が85%を下回れば、ローンチはしない。2つ目、モデル交換、リトリーバルの変更、文書更新のたびに再実行する。一つを直して他を壊さないためだ。3つ目——これが一番重要だ——ベンダー契約に書き込む。受入精度、拒否率、引用カバレッジを支払条件に紐づける。
私が見た中で最も真剣な契約は、1日あたり最低50問の30日パイロットを定め、受入条件はゴールデンセットで≥90%の精度、拒否率は5%〜15%だった。拒否率の下限に注目してほしい。「分からない」と一言も言わないアシスタントは、たまに辞退するアシスタントより遥かに危険だ。拒否は健全さの信号であり、失敗ではない。
モデルを責める前にリトリーバルを直せ
回答がおかしくなると、大半のチームはもっと大きなモデルに手を出す。私の経験では、10回中8回は問題はリトリーバルにあり、モデルが濡れ衣を着せられている。
まずチャンキング戦略を変えろ。固定トークン数で刻むのをやめる。文書の自然な構造に沿って刻む：SOPは節・条項ごとに、設備マニュアルはトラブルシューティング手順のひとまとまりごとに。真ん中で切られた条項は、どんなに良い埋め込みでも救えない。実際、セマンティック・チャンキングは最も安上がりな精度改善だ——ほとんどコストがかからない。
次にメタデータ・フィルタリングを追加する。取り込み時に文書へタグを付ける：バージョン、適用日、適用サイト、適用ゾーン。意味マッチングの前に最新の適用バージョンに絞り込む。古いバージョンは削除しない——監査で必要になるかもしれない——が「置き換え済み」としてマークし、デフォルトで検索対象から除外する。フォンタナの現場はまさにこの変更を行い、幽霊のバージョン番号はほぼ消えた。
もう一つ、過小評価されている手がある：高頻度・高リスクの質問に決定論的な高速レーンを与える。積み上げ高さ、通路幅、アラームしきい値——そんな質問は二三十件ほどだ。ベクトル検索を完全に迂回する完全一致Q&Aペアに登録する。これはズルではない。最も危険な質問を確率的システムから決定論的システムへ移しているのだ。
アシスタントに「不確かさ」を認めさせる3つのルール
リトリーバルを直しても、モデルはときどき作話する。ハルシネーションは希望では制御できない。3つの厳格なルールで制御する。
1つ目、引用の義務化。すべての回答は出典文書と条項を明記し、リンクは実際の本文にたどり着かなければならない。評価では、検証可能な引用のない回答は無条件で不正解とする。このルール一つでベンダーはリトリーバルを真面目に作らざるを得なくなる。でっち上げの余地がなくなるからだ。
2つ目、信頼度しきい値以下は拒否。取り出した文書のスコアが関連性のカットオフを下回る場合、または複数の情報源が矛盾する場合は、アシスタントは「知識ベースに明確な答えがありません——シフトリーダーにエスカレーションしました」と回答し、質問を人に回す。しきい値は保守的に設定する。倉庫の現場では、誤答のコストは無回答のコストより常に高い。
3つ目、定期的な人間による抜き打ちチェック。稼働開始後1か月目は毎日ランダムな実際のQ&Aを20件、人間がチェック。2か月目は週30件。3か月安定したら週10件。ミスはすべてパイプラインに戻す——リトリーバルの問題ならチャンキングとタグを直し、文書の問題なら知識ベースを更新し、境界の問題なら拒否ルールを追加する。監査証跡を残す。安全管理が聞いてきたときに必要になる。
作るべきでない倉庫もある
ここからはベンダーが嫌がる話だ。すべての倉庫がAI Q&Aアシスタントを作るべきではない。
30人未満の現場は作るべきではない。SOPはバインダー1冊に収まり、ベテランは現場にいて、通路越しに声をかけるほうが速くて無料だ。SOP自体がぐちゃぐちゃな倉庫も作るべきではない——誤った文書、期限切れの文書、矛盾した文書をAIに食わせれば、機械速度で自信満々の混乱が生まれるだけだ。そして1日20問未満の現場もやる必要はない：評価セットの維持、抜き打ちチェック、文書ガバナンスの手間は、節約できるQ&Aの時間より高くつく。
適合するのは、複数シフトで顧客ごとにSOPが実質的に異なる100人以上の現場だ——離職率が高く、夜勤は聞ける人がいなく、顧客固有の要件が山積み。それでも正直に位置づけよう：判断を代わりに下すマネージャーではなく、いつでも調べられるデジタルなベテランだ。
何かにサインする前に、一つの問いに答えてほしい：ベテランの作業員は、ラップトップを開かずに最新のSOPバージョンを見つけられるか。見つけられないなら、AIにもできない。AIはただ、誤った回答をもっと速く出すだけだ——本物に見える引用付きで。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
