「社内の在庫や価格を答えるチャットAIを導入したら、実際には存在しない在庫数を、まるで確かめたかのような口調で回答してしまった」——業務にAIを組み込んだ会社が、ほぼ例外なく最初にぶつかる壁です。しかもタチが悪いのは、間違っているのに自信満々なこと。人間なら「たぶん」と付けるところを、AIは断定口調で答えるので、受け取った側は信じてしまいます。
この「それっぽい嘘（幻覚）」や、ときに「勝手に処理を実行してしまう暴走」は、AIの性能が低いから起きるのではありません。判断も実行も、丸ごとLLM（大規模言語モデル）に任せている設計そのものが原因です。2026年7月、フードデリバリーの DoorDash が自社の会話型AIアシスタントの設計を公開し、その要点は一言でいえば「LLMだけに頼らない」でした。本記事では、なぜ丸投げが危ないのか、そして業務AIを作る・発注するときに何をAIに任せ、何を任せないかを整理します。
なぜ「LLMに丸投げ」は嘘と暴走を生むのか
LLMは、文脈に対してそれらしい言葉の並びを生成する機械です。人間のように「知らないことは調べる」「数字は台帳で確認する」といった態度は、そのままでは持っていません。だから、在庫数や料金のような正確さが命の情報まで生成に任せると、モデルは平気で「ありそうな数字」を作ってしまいます。これが幻覚の正体です。
実行も同じです。「この操作をしてよいか」の判断までLLMに委ねると、確認を挟まずに処理を走らせ、取り返しのつかない結果を招きます。AIエージェントが権限を持つほどこのリスクは大きくなります（この観点はAIエージェントが本番データを消した事件から学ぶガードレール設計でも扱いました）。つまり、精度と実行をLLMに預けるほど、システムは不安定になるのです。
DoorDashの答え — 正確さが要る部分をAIの外に出す
DoorDash の設計が示すのは、LLMを言葉を扱う係に限定し、正確さが要る仕事はAIの外の確定的な仕組みに任せるという分担です。具体的には次のような組み合わせになっています。
| 仕事 | 任せる相手 |
|---|---|
| 在庫確認・価格計算・カート操作などの業務処理 | 確定的なロジック（毎回同じ結果を返す仕組み） |
| 「ブランド名で商品を探す」など名指しの検索 | キーワード検索（透明で速い） |
| 「似たものを探す」など曖昧な検索 | 意味ベースの検索（セマンティック検索） |
| 会話の言い回し・意図のくみ取り | LLM |
ポイントは二つあります。一つは、業務ロジックをLLMのプロンプトの中ではなく、外側のツール（部品）として持つこと。カート操作や在庫照会は決まった手順で動く部品にし、LLMはその部品を呼び出すだけにします。もう一つは、キーワード検索と意味検索を組み合わせるハイブリッド検索。名指しで探したいものは正確なキーワード検索、曖昧な要望は意味検索、と使い分けます（検索の作り込みはRAG最適化パターンカタログが参考になります）。そして重要な操作の前には確認のステップを挟み、AIが勝手に実行しない構造にしています。
発注者の確認点 — 「何を任せないか」が設計に入っているか
業務AIを外注する、あるいは社内で作らせるとき、成果物の良し悪しを分けるのは「AIに何を任せ、何を任せないかの線引き」が設計に入っているかです。ここが曖昧なまま「とりあえずLLMに全部聞く」構成になっていると、デモは動いても本番で嘘と暴走が出ます。発注時に次を確認してください。
- 在庫・料金・残高など正確さが要る数字は、生成ではなく確定的な仕組みから取っているか
- 検索は名指しと曖昧を使い分けているか（全部を意味検索に寄せていないか）
- データを変える操作・お金が動く操作の前に、確認や承認のステップがあるか
- AIが「分からない」と言える設計か（無理に答えさせていないか）
最も危険なのは「全部AIにやらせれば賢いはず」という発想です。実際は逆で、精度が要る部分ほどAIの外に出すほど、システムは信頼できるものになります。デモの見栄えではなく、この線引きがあるかで判断してください。仕上がりの品質を担保する仕組みはAI成果物のQAガバナンスも併せて確認しておくと安心です。
AIチャットボットを入れたが誤答が怖くて本番に出せない、社内問い合わせや業務処理をAI化したいが暴走が不安——そうした段階であれば、グリームハブの開発・AI・自動化のご相談へお気軽にお声がけください。どこまでをAIに任せ、どこを確定ロジックで固めるかの線引きから、本番で崩れない設計までご一緒に組み立てます。
