チャットボットの自己解決率が伸び悩むと、多くのチームは同じ結論に至ります。「ナレッジが足りないからだ」。そしてFAQを増やし、記事を磨き、検索精度をチューニングする。それでも数字は動かない。

ナレッジ整備が自己解決率の土台であることは間違いありません。私たちも内製チャットボットの7ステップで、最も時間をかけるべきはナレッジ整備だと書きました。

しかし、ある水準から先の伸び悩みは、ナレッジの量や質の問題ではないことが多い。原因は、そもそもナレッジでは解けない問い合わせを、ナレッジで解こうとしていることにあります。

「ナレッジを増やせば上がる」は半分だけ正しい

自己解決率の改善というと、未解決ログを見てナレッジを追加する、という定石があります。この定石は正しく機能します——その問い合わせが「情報を知れば解決する」ものである限り。

「返品期限は何日か」「送料はいくらか」「対応ブラウザは何か」。こうした問い合わせは、答えが誰にとっても同じです。正しいナレッジが1つあれば、検索が当たりさえすれば解決します。ナレッジの追加が効くのはこの領域であり、立ち上げ初期の自己解決率がぐんぐん伸びるのも、この領域を刈り取っているからです。

問題はその先です。ナレッジで解ける問い合わせを刈り取り終えると、残るのは別の種類の問い合わせです。ここにナレッジ追加で挑み続けると、工数だけが積み上がり、数字は動かなくなります。

問い合わせには「情報」と「手続き」の2種類がある

「私の注文はいまどこにあるか」。この問い合わせに、FAQはどう答えられるでしょうか。

書けるのはせいぜい「配送状況はマイページからご確認いただけます」という一般論です。しかし顧客が知りたいのは一般論ではなく、自分の注文の現在地です。答えは人によって違い、その人の注文データを照会しなければ確定しません。つまりこれは情報の問題ではなく、本人確認とシステム照会——個人の特定と手続きの問題です。

「住所を変更したい」「解約したい」「請求書を再発行してほしい」も同じ構造です。顧客のゴールは知ることではなく済ませること。やり方を案内するナレッジは補助にはなりますが、最後の1歩 ” 実行 ” はナレッジの外側にあります。

ここを混同したまま「最新のAIに変えれば解決するのでは」と考えるのも、よくある迷路です。FAQベースで解決しない問い合わせは、最先端のLLMを持ってきても解決しません。ボトルネックはモデルの賢さではなく、本人を特定し、業務システムに手を伸ばせるかどうかだからです。

問い合わせの4象限

この切り分けを、2つの軸で整理します。
横軸は解決に必要なものが一般の情報か本人の情報か。縦軸は顧客のゴールが知ることか済ませることか。

左側の2象限は、ナレッジで解ける領域です。
「返品期限は何日か」（知りたい×一般情報）はFAQとRAGの主戦場。「解約のやり方を知りたい」（済ませたい×一般情報）も、手順ナレッジを正しく整備すれば案内で完結します。

右側の2象限は、ナレッジでは構造的に解けない領域です。
「私の注文はどこか」（知りたい×本人情報）には認証とシステム照会が要ります。「解約したい」（済ませたい×本人情報）には、認証に加えて手続きの実行——業務システムへの書き込み——が要ります。ここで必要な投資はナレッジ運用ではなく、システム連携の開発です。

実務でまずやるべきことは、未解決ログをこの4象限に仕分けることです。未解決の大半が左側なら、打ち手はナレッジ整備で正しい。大半が右側なら、FAQをいくら増やしても1件も解決しません。打ち手が根本から変わります。

• 例（架空のアパレルEC・A社）：
  自己解決率40%で頭打ちになったA社が未解決ログ500件を仕分けると、左側（ナレッジで解ける）は2割しかなく、6割が「注文はどこか」「返品手続きをしたい」という右側の問い合わせだった。ナレッジ追加では数字が動かないはずである。

数字はこう動く

4象限の仕分けは、投資判断の材料にもなります。

右下の照会系は、認証と配送・注文システムへの読み取り連携で解決します。一般に、EC・通販の問い合わせでは配送照会だけで全体の2〜3割を占めることも珍しくなく、ここが繋がるだけで自己解決率は段違いに動きます。
右上の実行系は、書き込みを伴うぶん設計もリスク管理も重くなりますが、「済ませたい」顧客をその場で完結させるため、顧客体験への効果は最も大きい領域です。

• 例：
  A社は配送APIの読み取り連携を実装し、認証済みユーザーの「注文はどこか」にボットが直接答えられるようにした。ナレッジは1本も追加していないが、自己解決率は40%から55%に動いた。次の四半期は返品手続きの自動化（右上）に投資する計画である。

順番も重要です。左側をナレッジで刈り取る→右下を読み取り連携で繋ぐ→右上を実行連携で自動化する。難度とリスクの低い順に進めるこの階段は、内製でもSaaS導入でも変わりません。

私たちは「自己解決率」を分解すべきだと考える

私たちは、自己解決率という1つの数字を追うのをやめ、情報解決率（左側：ナレッジで解けたか）と手続き解決率（右側：照会・実行まで完結したか）に分解して見るべきだと考えています。

1つの数字に混ぜてしまうと、ナレッジ運用チームの努力ではどうにもならない未解決が、ナレッジの成績として計上され続けます。分解すれば、「ナレッジはもう十分に機能している。次はシステム連携の投資判断だ」という会話が、データを根拠にできるようになります。

あなたのチャットボットの未解決ログは、情報の問題でしょうか。それとも手続きの問題でしょうか。自己解決率の伸び悩みに向き合うすべてのチームに、まずこの仕分けから始めることをすすめます。

照会・手続きまで含めたAIエージェントの設計に関心のある方は、お気軽にお問い合わせください。