チャットボットの作り方｜4つの手段と7ステップ・選び方の基準

チャットボットの作り方の話をする前に、そのチャットボットを組み込みたかったサービスの話から始めます。ここを飛ばすと、あとの話が全部ぼやけるからです。

一言で言うと、ホテルに泊まっている旅行者が、スマートフォンのチャットから荷物の配送を申し込めるサービスです。

なぜチャットボットを入れたかったのかというと、配送の申し込みは、入力する項目がとにかく多いからです。

→ 送り先の住所
→ 受取人の氏名と連絡先
→ 集荷の日時
→ 受け渡しの日時
→ 荷物の個数、サイズ、中身の申告
→ 支払い方法

フォームにすると、画面が何枚にもなります。 そして画面が増えるほど、途中でやめる人が増え、離脱していきます。旅行中の人が、慣れない言語で、小さな画面で、10項目以上を埋めるのは無理があります。

チャットなら、この手続きを1問ずつガイドできる。 そう考えたのが出発点でした。

ここで、チャットボットの作り方が問題になります。ひと口にチャットボットと言っても、あらかじめ質問と答えの組を用意しておく旧来型と、LLMを使った自由度の高い会話型があります。そして後者が主流になりつつある。だから、LLMベースで作りました。

もうひとつ、前提を補足しておきます。いまのチャットボットは、会話だけを担当していません。 会話をもとに、実際の手続きまで実行します。料金を計算し、集荷枠を押さえ、決済まで走らせる。

そこまでやるものを「チャット」ボットと呼び続けるのは、そのうち無理が出るのかもしれません。 会話は入口で、本体は手続きの実行だからです。いまならチャットエージェントと呼んだほうが自然だと思います。

前置きはさておき、本題に入ります。

作るのは、驚くほど簡単でした。数日で動きます。 そして業務に載せてから、2つのことが起きました。ひとつは事故で、ひとつは費用です。

今日は、その2つに気づいてから何を直したかという話をしていこうと思います。

① 裏側では、3つのシステムが並んで動いている

「裏側では、3つのシステムが並んで動いている」を図解したスライド｜旅行者から見えているのは、チャット画面だけです

チャットボットの作り方の基本をすでにご存じの方は、② 詰まりに気づくまで — 深夜の1件から読み進められます。

チャットボットとは

チャットボットとは、チャット形式の画面で、人の入力に対して自動で応答するプログラムです。問い合わせの一次対応、社内の手続き案内、申し込みの受付などに使われます。

いまのチャットボットは、会話だけを担当しているとは限りません。会話の内容をもとに、料金を計算する、枠を押さえる、決済を進めるといった手続きの実行まで受け持つものが増えています。作り方を選ぶときは、「会話だけか、手続きまでか」を先に決めてください。

チャットボットの種類（AI型とシナリオ型）

	応答のしかた	得意なこと	苦手なこと
シナリオ型（ルールベース）	あらかじめ用意した質問と答えの組、選択肢の分岐	答えが必ず決まっている。想定外を返さない	書いていない聞き方に答えられない
AI型（LLM）	文章を解釈して、その場で答えを作る	言い回しのばらつきに強い	毎回同じ答えとは限らない

どちらか一方で作る必要はありません。答えが決まっている問い合わせはシナリオ型、ばらつく問い合わせはAI型、という分け方が実務では現実的です。

用途で見る5つの型

FAQ型 — よくある問い合わせに答える。もっとも数が多い
処理代行型 — 申し込み、予約、パスワード再発行などの手続きを進める
辞書型 — 登録済みのデータから、正確な値を返す（型番、料金表）
配信型 — キャンペーンやイベントの情報を、こちらから送る
雑談型 — 日常的な話題に応答する

この5つは、作り方の難易度がまったく違います。FAQ型と辞書型は用意した答えを返すだけですが、処理代行型は外部のシステムを実際に動かすため、失敗したときの取り消しまで設計が要ります。

主な活用シーン

顧客からの問い合わせの一次対応 — 営業時間外もその場で返る
社内の問い合わせ — 情シス・総務・人事への繰り返しの質問
申し込み・予約の受付 — 入力項目が多いフォームの代わり
サイト内の案内 — 探している情報のページへ誘導する

入力項目が多いフォームの代わりに使うのは、効果が見えやすい使い方です。画面が何枚にもなるフォームは、枚数が増えるほど途中でやめる人が増えます。チャットなら1問ずつ聞けます。

チャットボットの作り方は大きく4種類

作る手段は、次の4つに分かれます。

作り方	要る技術	向いている用途
Excelなどの表計算	ほぼ不要	社内で試す簡易なFAQ型。まず形を見たいとき
ノーコードツール	画面の設定のみ	FAQ型・配信型。運用も現場で回したいとき
API連携	一部プログラミング	自社のシステムと繋ぎたいとき
プログラミング	設計から実装まで	独自の処理や、手続きの実行まで持たせたいとき

4つは排他ではありません。ノーコードツールで会話の入口を作り、手続きの部分だけAPIで自社システムに繋ぐ、という組み方が実務では多くなります。

作り方1｜Excelなどの表計算で作る

質問と答えの組を表に並べ、キーワードで引く形です。本番運用というより、答えの中身を先に固める用途で使います。

メリットは、誰でも書けて、すぐ直せること。デメリットは、同時に多くの人が使えないことと、言い回しのばらつきに一切対応できないことです。ここで作った表は、後でどの手段に移っても資産として使えます。

作り方2｜ノーコードツールで作る

画面の操作だけで、会話の流れと回答を設定します。プログラミングは要りません。

メリットは、立ち上がりが速く、運用の担当者が自分で直せること。デメリットは、ツールが用意していない連携ができないことと、件数や機能に上限があることです。無料枠から始める場合は、上限に当たったときの移行先を先に見ておいてください。

作り方3｜APIを組み合わせて作る

LLMのAPIや、チャット基盤のAPIを呼び出して組み立てます。自社の基幹システムや決済と繋ぐなら、この段階からが現実的です。

メリットは、既存の仕組みに載せられること。デメリットは、繋ぐ先が増えるほど作業量が増えることです。見積もりがぶれるのは、ほぼこの連携の本数です。

作り方4｜プログラミングで作る

言語とフレームワークを選び、会話の制御から実装します。Pythonがよく使われるのは、ライブラリと公開されている情報が多いためです。

メリットは、やりたいことに制限が無いこと。デメリットは、作った後の保守を自社で持ち続けることです。作る費用より、動かし続ける費用のほうが後から効きます。

4つの作り方をどう選ぶか

判断の材料は4つです。

会話だけか、手続きの実行までか — 実行まで持たせるならAPIかプログラミング
自社システムと繋ぐ必要があるか — 繋ぐならノーコードでは届かないことがある
誰が直し続けるか — 現場が直すならノーコード、開発チームがいるなら自作
止まったときに、人が引き取れるか

4つ目が抜けやすい項目です。チャットボットは必ず答えられない場面に当たります。そのときに人へ渡す経路を、作り方を決める段階で確保しておいてください。後から足すと、会話の履歴を人が読める形にするところからやり直しになります。

作る前に決めておくこと

着手前に、次の5つを文章にしておきます。

導入の目的 — 問い合わせ件数を減らすのか、受付を24時間にするのか
対象の質問 — 実際に来ている質問を、そのまま集める
答えの出どころ — どの資料・どのシステムの値を根拠にするか
運用の担当 — 誰が回答を直し続けるか
人へ渡す条件 — どうなったら人に代わるか

2つ目は、想像で作らないでください。実際に来ている質問をそのまま集めると、そのまま公開前のテスト項目になります。想像で作った質問は、答えやすい質問になりがちです。

チャットボットの作り方の手順（7ステップ）

	やること	終わったと言える状態
1. 目的と対象を決める	何を減らしたいか、どの質問に答えるか	実物の質問が一覧になっている
2. 作り方を選ぶ	4つの手段から選ぶ	連携する先の本数が分かっている
3. 会話パターンを洗い出す	質問と答え、分岐、例外	答えられない場合の文面も決まっている
4. 答えの根拠を整える	資料の整理、データの用意	古い版が混ざっていない
5. 作って動かす	実装・設定と動作確認	1で集めた質問が通る
6. テストする	関係者で実際に触る	答えられなかった質問が記録されている
7. 公開して運用する	効果測定と改善	直す担当と頻度が決まっている

3で「答えられない場合の文面」を決めておいてください。決めていないと、答えられない質問にも何かを答えてしまいます。沈黙より、間違った回答のほうが後始末が重くなります。

LLMで作る場合に増える工程

AI型（LLM）で作るときは、シナリオ型に無い工程が3つ増えます。

自社データを答えさせる仕組み — 資料を検索して渡す（RAG）。用意しないと一般論しか返らない
指示（プロンプト）の設計 — 何を答えてよく、何を答えないかを指示に書く
回答精度の検証 — 集めた質問に対して、合っているかを1件ずつ確認する

3つ目を省くと、公開してから確認することになります。AI型は、間違いも同じ調子で返します。文面を見ただけでは、合っているものと外れているものが区別できません。

ツールを選ぶときの比較ポイント

見るところ	なぜ効くか
自社データとの連携のしやすさ	回答の質は、渡せる資料で決まる
回答を直せる機能があるか	公開後は直し続ける作業のほうが長い
答えられなかった質問が残るか	改善の材料は、ここからしか出てこない
人へ引き継げるか	有人対応への切り替えができるか
上限と料金の増え方	件数・利用者数が増えたときにいくらになるか

機能の一覧では差が出ません。差が出るのは1つ目です。カタログに載っている連携先の数ではなく、自社がいま使っているシステムの名前があるかで見てください。

無料で作る方法と、無料枠の注意点

無料プランやオープンソースを使えば、費用をかけずに始められます。形を見て社内で合意を取る段階では、有効な選択です。

注意するのは3点です。件数や利用者数の上限、入力した内容が学習に使われる設定になっていないか、そして有料に移るときに作ったものを引き継げるか。引き継げないツールで作り込むと、移行がそのまま作り直しになります。

自作するメリット

やりたいことに合わせて作れる — 既製品の機能に縛られない
他の用途に展開できる — 一度作れば、別の窓口にも載せられる
利用が増えても、費用の増え方を自分で決められる

3つ目は見落とされがちです。既製品は利用者数や件数で料金が上がる形が多いのに対し、自作は処理のしかたを変えることで費用を抑えられます。

自作するデメリット

運用と保守を、自社で持ち続ける
作れる人が要る — 開発と、公開後に直す人
形になるまで時間がかかる
高い精度を求めるほど難易度が上がる

自作するかどうかは、作る費用ではなく「直し続けられるか」で判断してください。公開後に直す人がいない自作は、半年で使われなくなります。

リスク1｜誤った回答（ハルシネーション）

AI型では、根拠が無いときも同じ調子で答えます。料金、期日、条件といった具体的な値ほど、間違いの影響が大きくなります。

対策は、精度を上げることではなく、答えさせる範囲を絞ることです。値を返す質問は、渡した資料やシステムの値からしか答えさせない。資料に無いときは「分かりません」と返す文面を、先に決めておいてください。

リスク2｜個人情報・機密情報と不正アクセス

チャットには、利用者が思わぬ情報を書き込みます。氏名、連絡先、注文番号、社内の資料の中身。

会話のログをどこに、どのくらい残すかを先に決めてください。あわせて、外部のAPIへ送る内容が学習に使われない設定になっているかを確認します。手続きまで実行するタイプでは、本人確認をどこで行うかも設計の対象になります。

リスク3｜複雑な対話には応答できない

条件が絡み合う相談や、例外の判断は、チャットボットだけでは処理しきれません。

「できないこと」を先に決めて、そこで人に渡してください。全部に答えさせようとすると、答えられない質問にも何かを答える状態になります。

運用と改善のしかた

担当者を決める — 直す人がいないと、内容は古くなる一方
答えられなかった質問を集める — 改善の材料はここにしかない
定期的に更新する — 料金や手続きが変わったら、その日に直す
有人対応と併用する — 渡す条件を明文化する
効果を測る — 問い合わせが人に回った件数で見る

効果を「チャットボットが応答した件数」で測らないでください。応答件数は公開直後に必ず増えます。人へ回った件数が減っていなければ、作業の量は変わっていません。

LINE・Slackなど外部ツールとの連携

自社サイトの中だけでなく、利用者がすでに使っているアプリの中に置くこともできます。社内向けならSlackやTeams、顧客向けならLINEが典型です。

新しい画面を1つ増やすより、すでに毎日開いているところに置くほうが使われます。ただし連携先が増えるほど、同じ回答を複数の経路で保守することになる点は見込んでおいてください。

チャットボットの作り方に関するよくある質問

Q. チャットボットは自作できますか。
できます。Excel、ノーコードツール、API連携、プログラミングの4通りがあり、会話だけならノーコードで足ります。手続きの実行や自社システムとの連携まで持たせるなら、API以上が現実的です。

Q. シナリオ型とAI型は、どちらを選べばよいですか。
答えが必ず決まっている問い合わせはシナリオ型、言い回しがばらつく問い合わせはAI型です。1つの窓口の中で両方が混ざるのが普通なので、質問の種類ごとに分けて考えてください。

Q. 無料で作れますか。
無料プランやオープンソースで始められます。ただし件数の上限、入力内容が学習に使われないか、有料へ移るときに引き継げるかの3点を先に確認してください。

Q. 作るのにどのくらい時間がかかりますか。
会話だけのFAQ型なら数日でも形になります。時間がかかるのは、繋ぐ先のシステムの本数と、答えの根拠になる資料を整える工程です。

Q. 公開したあと、何をすればよいですか。
答えられなかった質問を集めて、直し続けてください。効果は応答件数ではなく、人へ回った件数が減ったかで測ります。

旅行者から見えているのは、チャット画面だけです。裏側では3つが同時に動いています。

→ チャット — 旅行者とやりとりし、料金と集荷時間を決める
→ 決済 — カードの利用枠を押さえ（与信）、注文が確定したら実際に請求する。2段階です
→ 業務システム — 運営スタッフが見る管理画面。今日どの部屋から何個の荷物を集荷して、どこへ送るのか。その一覧を見て、人が動きます

申し込みが成立すると、この3つに同じ1件の記録が並びます。チャットに会話が残り、決済に与信が立ち、業務システムに注文が立つ。

3つが揃って、はじめて取引が成立したことになります。

標準構成で作る

チャットボットの作り方を調べると、出てくる手順はほぼ共通です。

→ LLMのAPIを取得する
→ 手元の文書やサービス情報を検索できるようにする（RAG）
→ 会話の入口を作る

構成としてはこうなります。

利用者の入力 → キーワード判定 → LLM（外部API） → 回答／申し込み処理

この構成で作ったものは、きちんと動きました。数日で立ち上がり、料金を答え、集荷時間を決め、決済まで進む。デモも通ります。

ここまでが、チャットボットの作り方の教科書どおりの整理です。型を選び、手段を選び、会話を洗い出し、作って、直し続ける。手順としては、これで揃っています。

この記事の後半で扱うのは、この標準構成のまま業務に載せた1件で、公開後に起きた2つのことです。ひとつは事故で、ひとつは費用でした。

② 詰まりに気づくまで — 深夜の1件

動くものができたので、実際の業務に接続します。

最初の異常は、警告として現れませんでした。 現れたのは、3つのシステムのあいだのズレです。

深夜、決済側には3万円を超える与信が1件立っています。 旅行者のカードの利用枠が、その金額ぶん押さえられている、ということです。

ところが、業務システムの注文一覧に、その1件だけが出てきません。 前後の時間帯の注文は、普通に並んでいます。1件だけ、無い。

集荷に行く先が分からない。そもそも注文があったことに気づけない。旅行者はカードを押さえられたまま、荷物は誰にも引き取られない。

最初は表示の不具合を疑いました。次にキャッシュ、次に権限。どれも違いました。

たどり着いた答えは、想定していたどの仮説とも違いました。その注文は、チャットのLLM経由で作成されていました。しかも、そのとき荷物預かりのサービスは、システム上は受付を止めていたのです。

つまり、こういう順番で起きていました。

→ ① 荷物預かりは、システムとしては受付を閉じていた
→ ② それでも旅行者が「荷物を預けたい」と打った。LLMは、良かれと思って案内した
→ ③ 話が進んで決済まで到達し、カードの与信は押さえられた
→ ④ ところが業務システム側は、閉じているサービスの注文を受け付けない。注文レコードが作られなかった

決済だけが成立して、注文が存在しない。 客のカードは押さえられているのに、運営側のどこを見ても、その取引の痕跡が無い。いちばん気持ちの悪い壊れ方です。

この時点で、疑いが確信に変わりました。LLMは99.9%までなら持っていける。ただし、100%が要求される処理では、予期しない動き方をすることがある。

精度の問題ではありません。 99.9%は達成できている。問題は、残った0.1%がエラーとして飛ばない形で残ることでした。

この1件は、監視では見つからない

なぜ発見が遅れたのかというと、そもそも監視の対象になっていなかったからです。

→ 例外は出ていない
→ 画面も落ちていない
→ ログにもエラーが無い

壊れたものを探す仕組みは、全部すり抜けます。 見つかったのは、決済の明細と業務システムの注文一覧を、人が並べて突き合わせたからでした。

「無いものを数える」作業をしていなければ、この事故は翌月も翌々月も起き続けていたことになります。

③ 請求書が届いて、2つ目に気づく

「請求書が届いて、2つ目に気づく」を図解したスライド｜事故を追いかけている最中に、その月のAPIの請求が届きました

事故を追いかけている最中に、その月のAPIの請求が届きました。思っていたより高い。

内訳を見て理由が分かりました。旅行者は、荷物の話だけをしているわけではなかったのです。

→ 「近くにおいしい店はある？」
→ 「明日の天気は？」
→ 「チェックアウトは何時？」

どれも荷物の配送とは関係ありません。それでも全部、外部のAPIに投げて、丁寧に答えて、きちんと課金されていました。

雑談1件あたりの金額は、わずかです。ただ、件数が多い。そして、この構成では雑談も申し込みも同じ経路を通るので、安く済ませる方法がありません。

年度で予算を組む組織にとって、「使った分だけ」はいちばん扱いにくい費用です。上限も下限も読めないからです。

④ 詰まりの原因を、1つに特定する

別々の問題に見えますが、原因は共通でした。

利用者の入力 → キーワード判定 → LLM（外部API）
                              ↑
                    ここに、分岐も停止もない

→ 入力がそのままLLMに届く
→ LLMが解釈して、LLMが答える
→ 途中に、止める場所も分ける場所も無い

だから「これは答えてはいけない」を実装する場所が無く、「これは安く処理する」を実装する場所も無い。

制御点がゼロです。プロンプトで縛る対処が最初に出ますが、上限があります。プロンプトは指示であって、機構ではないからです。

⑤ 直してみる — 前段に、分類器を1枚

そこで、構成を1箇所だけ変えました。

変更後

利用者の入力 → キーワード判定 → オンデバイス分類器 → （確信度が低いときだけ）LLM

間に挟んだのは、分類専用の小さなモデルです。会話を生成する能力はありません。入力がどのカテゴリに属するかだけを判定します。

重要なのは、確信度も一緒に出させることです。

→ 確信度が閾値を超えたら、そのまま機械的に処理する
→ 確信度が閾値を下回ったら、LLMに回す

作業としては、モデルを1つ追加して分岐を1本書いただけです。

そして、事故そのものへの対処も三段で立てました。

→ 閉じているサービスを、LLMに通させない
→ 通ってしまったら、黙殺せずエラーを返す
→ それでも通過したら、運用のタスク画面に出す

現場で立てた方針は、これだけです。素朴だと思います。

あとで知った — この形には、すでに名前がついていた

素朴な解のつもりでしたが、調べてみると同じ構造が、いま最も研究されている省コスト設計そのものでした。

1つ目。安いモデルから順に試し、確信が持てないときだけ高いモデルへ渡す構成は、カスケード（LLM cascade）と呼ばれています。2023年の FrugalGPT という論文が提案した形で、安いモデルの応答に対して0〜1の信頼スコアを出し、閾値を下回ったら次のモデルへ上げていく。

報告されている効果が、なかなかのものです。最も高性能な単体モデルと同等の性能を、最大98%のコスト削減で達成した。あるいは同じコストのまま精度を4%上げた。

2つ目。入力の難易度を先に判定して、強いモデルと弱いモデルに振り分ける構成は、ルーティング（model routing）と呼ばれます。2024年の RouteLLM がよく知られていて、強いモデルが勝つ確率を予測するモデルと、コストの閾値で振り分けを決める。閾値を上げれば弱いモデルへ多く流れて安くなり、下げれば強いモデルへ流れて品質が上がる。

閾値ひとつで、コストと品質のどこに立つかを決められる。 「最初は保守的に低く置いて、実績を見て絞る」という現場のやり方は、まさにこのつまみを回す作業でした。名前を知らないまま、同じことをしていたわけです。

3つ目が、いちばん面白いところでした。

「入力の意図を分類器で判定してから処理を分ける」——これは、LLM以前の対話システムが標準でやっていた設計です。

当時のパイプラインは、こうなっていました。

→ 自然言語理解（NLU） — ドメイン判定・意図検出・スロット充填
→ 対話状態追跡 — 利用者がいま何を求めているかを保持
→ 対話ポリシー — 次に何をするかを決める
→ 応答生成

そして意図分類は、「対話管理への必須の入力」と位置づけられていました。分類できなければ、次に何をするかが決まらないからです。

LLMが賢すぎたので、この層をまるごと捨てました。 分類しなくても、全部投げれば答えてくれるからです。

→ 分類器を捨てた → 制御点が消えた
→ 制御点が消えた → 答えてはいけないものに答えるようになった
→ そして費用も、分類していないぶんだけ全部が高い経路を通った

つまり今回やったのは、発明ではありませんでした。一度捨てた層を、「確信度」という一項目だけ足して戻しただけです。

そして、この「確信度で分岐する」の一項目が、古い設計を最新のカスケードに変えているところです。昔の意図分類は、当たったか外れたかの二値でした。確信度を出させると、外れそうなときだけ賢い方に逃がせます。

事故対策の三段（通させない／エラーを返す／運用画面に出す）も、似た話でした。

ガードレールの設計は、単一のフィルタを最後に足すのではなく、リクエストの経路上に複数の制御を重ねるのが定石だとされています。入力フィルタ・出力検証・エスカレーションモジュールという層に分けておくと、片方を差し替えても他方に影響しない、という理由です。

そして3段目については、はっきりこう書かれているものがあります。「ガードレールが確信を持てないときに、人間のレビュアーへ回す」。

確信が持てないときに逃がす。カスケードでやっていることと、まったく同じ発想です。逃がす先が大きいモデルか人間かの違いしかありません。

ただし正直に書いておくと、「防止・検知・エスカレーション」という決まった三点セットの呼び名があるわけではありません。 層の切り方は文献によって違います。共通しているのは「1枚では足りない」という一点だけです。

新しい理屈は、ひとつも要りませんでした。

⑥ 結果

ルーティング精度：99%

意地悪な問題を多く用意したデータセットでも、約8割を分類器が処理しました。実利用では、外部APIの呼び出しを8割以上削減できる見込みです。

別の検証では、ホテルの問い合わせ（タオルはどこか、荷物を送りたい、観光プランを知りたい）を振り分ける用途で、容量100MB程度のモデルで、精度95%から97%まで来ています。

100MBです。 巨大なモデルは要りませんでした。

なぜ両方が同時に良くなったのかというと、理由は3つに分かれます。

→ 精度側：「答えてはいけない質問」を、プロンプトのお願いではなく分岐の条件として実装できるようになった。受付不可カテゴリに落ちれば、LLMに到達すらしない
→ 費用側：よくある問い合わせほど分類器が確信を持てる。そして、よくある問い合わせほど件数が多い。件数の多い側から順に、費用ゼロの経路に流れる
→ 予算側：分類器は外部APIを呼ばないので、使っても使わなくても費用が変わらない。従量から固定へ寄る

⑦ 現場で使うなら、このフォーマット

「現場で使うなら、このフォーマット」を図解したスライド｜ここまでを、そのまま使える形に落とします

ここまでを、そのまま使える形に落とします。設計時にこの表を埋めてください。

表1：カテゴリ定義表

#	カテゴリ名	例となる入力	処理	確信度の閾値	LLMに回すか
1	施設案内	「タオルはどこ」	定型回答を返す	0.85	下回ったら回す
2	配送依頼	「荷物を送りたい」	申込フォームへ誘導	0.90	下回ったら回す
3	周辺情報	「観光プランを教えて」	検索して要約	0.70	下回ったら回す
4	受付不可	受付終了後の申込	停止して有人へ	0.60	回さない
5	金銭・取消不可	決済、キャンセル	停止して有人へ	0.60	回さない
6	対象外	「今日の天気は」	対象外と返す	0.80	回さない

4・5・6の行が、この表の本体です。 1〜3は誰でも作ります。答えない行を持っているかどうかが、事故の有無を分けます。

閾値は最初、保守的に低く置いてください（＝LLMに回す割合を多めに）。運用実績を見て絞ります。いきなり高く置くと、確信していないのに機械処理する事故が出ます。

この表は、カスケードの設計書でもあります。閾値の列が、どこで上のモデルへ逃がすかの定義になっているからです。

閾値は最初、保守的に低く置いてください（＝LLMに回す割合を多めに）。運用実績を見て絞ります。いきなり高く置くと、確信していないのに機械処理する事故が出ます。カスケードの研究でも、閾値の調整が性能とコストの分岐点になると言われています。 ここは一度で決まりません。

表2：通り抜けたときに、気づく仕組み

表1は防止の層です。ただし、防止だけでは足りません。

冒頭の3万円の事故は、表1があっても通り抜けたときに気づけません。だから同時にこれを作ります。

突き合わせるもの	頻度	拾う条件	通知先
決済明細 ⇄ 注文台帳	毎日	片方にしか無い行	運用担当
問い合わせログ ⇄ 回答ログ	毎日	回答が無い行	運用担当
分類器の確信度分布	週次	閾値付近が増えていないか	開発担当

1行目が、あの事故を見つける唯一の手段でした。「壊れたものを探す」ではなく「無いものを数える」。実装は地味ですが、これしかありません。

そしてエスカレーションの層として、もう1つ足します。

条件	動作
表1の4・5に落ちた	処理を止めて、運用のタスク画面に出す
表2で片方にしか無い行を検出	同じタスク画面に出す
分類器の確信度が閾値付近で振動	週次レポートに出す

「エラーを返して終わり」にしないのが要点です。 止めたものが人の目に入る場所へ必ず出る。この列があるかどうかで、事故が「起きなかった」になるか「気づかれないまま続く」になるかが分かれます。

防止・検知・エスカレーション。この3層が揃って、初めて設計と呼べます。 表1だけだと、防止しかありません。

手順（この順で作る）

→ 1. 過去の問い合わせを分類し、上位で8割を占めるところまでカテゴリを作る（多くの場合5〜10）
→ 2. 表1に、答えない行（受付不可・金銭・対象外）を先に書く
→ 3. 分類器を作り、確信度を出させる。閾値は低めから
→ 4. LLMに回す経路を作る（ここで初めてLLMが出てくる）
→ 5. 表2の突き合わせを実装する
→ 6. 元データの構造を直す

最後の6が、精度で詰まったときの本命です。AIが自動生成した議事録には見出しがありません。 文章としては読めるのに構造が無いので、どこで区切るかが決まらない。ある現場での当座の対応は、見出し記号を機械的に差し込んで、そこで区切るという、およそ美しくない処置でした。

元データに構造が無い状態では、モデルを変えても検索精度は上がりません。

⑧ この設計が効き続ける理由

最後に、なぜこのフォーマットを推すのかを書きます。

モデルが入れ替わっても、無駄にならないからです。

これは願望ではなく、実験で確かめられています。ルーティングの研究では、ある強弱のモデルの組で訓練したルーターが、下のモデルを入れ替えてもテスト時に性能を保ったという結果が報告されています。

振り分けの判断は、振り分けられる相手が変わっても生き残る。 モデルの顔ぶれが毎月変わる市場で、これはかなり重い意味を持ちます。

→ どのモデルを使うかは、四半期ごとに最適が変わります
→ でも「どこで判断を分けるか」は、業務が変わらない限り変わりません
→ だから表1と表2は、モデルを差し替えてもそのまま使えます

賢いモデルを選ぶ作業は、選んだ瞬間から陳腐化が始まります。カテゴリと閾値と突き合わせを設計する作業は、資産として残ります。

そして、この記事で書いたことのうち本当に新しいものは、ひとつもありません。

→ カスケードは2023年に提案されている
→ ルーティングは2024年に整理されている
→ 意図分類にいたっては、LLM以前の対話システムの標準構成

新しかったのは、それを一度全部捨てたことの方でした。LLMが賢すぎたので、分類も、状態管理も、方針決定も要らないように見えた。実際、要らないように動きます。業務に載せるまでは。

標準構成が悪いのではありません。標準構成は、制御点を1つも持っていないだけです。 1枚足せば、そこから先は設計の対象になります。

なお、冒頭の「今日の天気は？」は、分類器を入れるとカテゴリ6「対象外」で一瞬で弾かれるようになります。

弾かれた画面は、少し寂しいです。丁寧に天気を答えていた頃の方が、愛嬌はありました。愛嬌に課金していたわけですが。

以上です。

チャットボットの作り方よくある質問

チャットボットは自作できますか？

できます。作り方は大きく4種類で、Excelなどの表計算、ノーコードツール、API連携、プログラミングです。会話だけを担当させるならノーコードツールで足ります。申し込みや決済のような手続きの実行、自社システムとの連携まで持たせるなら、API連携以上が現実的です。判断の分かれ目は、繋ぐ先の本数と、公開後に誰が直し続けるかです。

シナリオ型（ルールベース）とAI型は、どちらを選べばよいですか？

答えが必ず決まっている問い合わせはシナリオ型、言い回しがばらつく問い合わせはAI型です。シナリオ型は想定外を返さない代わりに、書いていない聞き方に答えられません。AI型はばらつきに強い代わりに、毎回同じ答えとは限りません。1つの窓口の中で両方が混ざるのが普通なので、質問の種類ごとに分けて考えてください。

チャットボットは無料で作れますか？

無料プランやオープンソースを使えば費用をかけずに始められます。確認するのは3点です。件数や利用者数の上限、入力した内容が学習に使われない設定になっているか、有料プランへ移るときに作ったものを引き継げるか。引き継げないツールで作り込むと、移行がそのまま作り直しになります。

チャットボットを作るのに、どのくらい時間がかかりますか？

会話だけのFAQ型なら数日でも形になります。時間がかかるのは、繋ぐ先のシステムの本数と、答えの根拠になる資料を整える工程です。あわせて、公開前に「答えられない場合の文面」を決めておいてください。決めていないと、答えられない質問にも何かを答えてしまいます。

チャットボットを公開したあとは、何をすればよいですか？

答えられなかった質問を集めて、直し続けてください。改善の材料はそこにしかありません。効果を測るときは、チャットボットが応答した件数ではなく、人へ回った件数が減ったかで見ます。応答件数は公開直後に必ず増えるので、それだけでは作業が減ったかどうかを判定できません。

チャットボットの標準的な作り方を教えてください。

LLMのAPIを取得し、社内文書を検索できるようにして、会話の入口を作る構成です。RAGと呼ばれる形で、数日あれば動くものができます。まずはこれで作って構いません。ただし業務に入れる前に、この記事の改良版まで進めてください。標準構成のままだと、想定外の質問に答えてしまう問題と、費用が利用量に比例して読めなくなる問題が同時に出ます。

オンデバイス分類器とは何ですか？

端末やサーバー内で動く、分類専用の小さなモデルです。会話を生成する能力はなく、入力がどのカテゴリに属するかだけを判定します。容量が小さく高速で、外部APIを呼ばないため呼び出し費用が発生しません。実運用では、確信度を一緒に出させて、閾値を超えたものは機械処理、下回ったものだけLLMに回す、という使い方をします。