150人規模の現場で業務を回していると、こういう状況って本当によく起きる。
- 業務の判断が必要なのに、リーダーが他の対応で席を外している
- 一般社員ではその判断ができない、でも業務は進めないといけない
- 一度止まった業務が、数時間経ってもリーダーの手が空かず、結局私のところに回ってくる
いわば、“リーダーの不在＝判断の遅延”という構造。
これを放置すると、現場の混乱や不満につながり、心理的負担にもなる。だから私は、 「判断の補助ができるBotを構築しよう」 と考えた。
この記事では、私がPythonで実装したBotによって、どうやって“判断のボトルネック”を技術的に吸収したか、その一部始終を記録していきます。
🤷♂️ 判断待ちが現場を止める瞬間
日常的な業務の中には、“誰でもできる”作業と、“判断が必要な”作業があります。
例えば：
| 業務内容 | 判断が必要か | 誰ができるか |
|---|---|---|
| 対応ログの記入 | × | 一般社員 |
| 報告書の提出 | ○（内容確認） | リーダー以上 |
| クライアントへの返答 | ○（文面調整） | スーパーバイザー |
| マニュアルにない例外対応 | ○（判断） | リーダー or 管理者 |
ここで問題になるのは、「リーダーが今いない」場合。
現場は、“聞きたいけど聞けない”“答えを待っているけど誰も返さない”という空気になる。結果的に業務が止まる、質問が蓄積する、ストレスが増える。
この空白を埋める存在として、私はBotの導入を進めました。
🤖 Botってどこまでできるのか？
私が構築したBotは、ただのFAQ回答ではなく、「業務上の曖昧さに対して、判断補助となる情報を提供する」という役割を持たせました。
Botが担った機能は次のようなものでした：
| 機能 | 内容 |
|---|---|
| 質問の分類 | 入力された質問を、業務カテゴリ別に分ける（対応／書類／判断／例外） |
| 回答履歴の検索 | DB化された過去の対応事例を検索し、似たケースを提示 |
| 業務フローの提示 | どの判断段階にいるかを図解や選択形式で示す |
| 「今聞くべきか」の判定 | 質問内容の緊急性に応じて、「Botで解決できる」「リーダーに聞くべき」を示す |
| 感情ケアコメント | ユーザーの入力に対し、「今は不安かと思いますが、こちらの事例をご参考にどうぞ」など、安心を添えるメッセージ |
つまり、“判断に必要な材料”をBotが提示することで、「完全な答えを出す」のではなく「先に動ける一歩を示す」構造にしたわけです。
🔧 Botの実装概要（技術部分）
ここで少し技術的な話も。
私が使ったのはPython＋Flaskをベースにした簡易WebチャットBot。データは社内対応履歴から抽出したログをSQLiteに格納。文章ベースの検索は以下のような流れで構築しました。
1. 質問の類似度判定（簡易自然言語処理）
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity
def find_similar(question, corpus):
vectorizer = TfidfVectorizer()
vectors = vectorizer.fit_transform([question] + corpus)
similarities = cosine_similarity(vectors[0:1], vectors[1:])
return corpus[similarities.argmax()]
- 入力された質問とDB内の事例をTF-IDFで比較
- 類似度が高い対応履歴を引っ張ってBotの参考回答に使用
2. 回答生成ロジック（テンプレベース）
def generate_response(similar_case, category):
templates = {
"判断系": "似たような対応例が以下にあります。状況が近いかご確認ください：",
"操作系": "操作手順はこちらになります → マニュアルリンクを参照してください",
"例外対応": "このケースは特殊ですが、過去対応では△△という判断でした",
}
return templates[category] + similar_case
- 業務カテゴリに応じたトーンで応答
- 柔らかめの表現＋補足情報をセットに
📚 DBに蓄積していた対応履歴の構成
Botの判断精度を高めるため、私がDBに整理していた履歴項目はこうです：
| 項目 | 内容 |
|---|---|
| 質問文 | 実際に入力された内容（曖昧な言葉も含む） |
| 業務カテゴリ | 判断系／操作系／例外処理など |
| 担当者 | 当時の対応者（リーダー or 管理者） |
| 対応結果 | どう処理されたか、何を伝えたか |
| 備考 | この対応が今も有効か（ルール更新あり・なし） |
| 登録日 | 履歴の鮮度把握のためのタイムスタンプ |
これにより、Botは“誰かが対応した記録”から判断材料を引っ張ってきて、「この事例、参考になるかも」と提示できるようになっていた。
🧠 リーダーの負荷がどう変わったか
Botを導入したことで、リーダーたちからは以下のような反応がありました：
- 「Botが一次対応してくれるだけで、後の確認がすごくラクになる」
- 「Botが判断補助してくれるおかげで、“迷ったら聞く”の質が上がった」
- 「Bot履歴で“何が過去に起きたか”が見えるので、説明工数が減った」
結果的に、“リーダーしかわからない”案件が減り、リーダーが戻ってきた時点で、話の前提がすでに整っている状態になっていました。
これは、Botが単に「答える」のではなく、「土台を作る」役割を担っていたからこそだと思っています。
💬 一般社員の意識にも変化が起きた
Botは技術的な仕掛けだけじゃなく、心理的な安心感にも寄与していました。
- 「誰に聞けばいいか分からないとき、Botが話を聞いてくれる」
- 「Botに聞いてみたら、似た事例が出てきて助かった」
- 「Botが言ってたから聞くハードルが下がった」
一番大事なのはここで、Botの存在が “相談してもいいんだ”という空気を作ったことだったんです。
人に直接聞くのは緊張する。でもBotなら、気軽に聞ける。結果的に、業務の滞りが減り、相談文化が育った。
✍️ 締めに：Botは判断者の代わりではなく“判断を支えるパートナー”
Botは完璧じゃない。曖昧なケースには対応できないこともある。でも、Botが**「準備をする」「ヒントを出す」「前提を整える」ことは十分にできる**。
それが現場にとっては、判断者の不在をカバーし、タイミングを逃さずに次のアクションへ進める力になる。
Botは人の代わりをするものじゃない。**人が動きやすくなるための“支え”**なんです。だから私は、「Botがいるから安心」「Botで予習しておける」という状態を作ることを目的に設計していました。
そして結果的に、業務が止まりにくくなり、判断者の負荷が軽減され、現場全体がスムーズに回るようになったのです。
📘 次回予告：
第9回｜社内Q&AのDB化と“育てるチャットボット”への挑戦
── 質問が資産になる。その記録から始まるナレッジの蓄積とBotの進化設計