AIに1件ずつ分析してもらったら、お客様に出すレポートが劇的に改善しました

2026年8月7日 2026年8月7日

blueleaf

弊社では、あるメーカー様に AIチャットボットを導入いただいております。製品ページで、お客様が型番や仕様について質問できる仕組みです。

この記事は、月次レポートを作った話の2本目です。 1本目のデザイナーがいない会社でも、お客様向けのきれいなスライドは作れます（Claude Design）では、見た目をどう整えたかを書きました。こちらは、中身がどう変わったかの話です。どちらから読んでも大丈夫です。

先日、この運用について「月次レポートを毎月お出しする」ことを決めました。

出来上がったものは、これまで自分が出せていた報告書とは別物になりました。この記事では、何が変わって、なぜ変わったのかを紹介したいと思います。

件数の報告から、原因の分析と改善提案まで出せるようになりました

先に結論から書きます。

	これまで出せていた範囲	今回出せた範囲
数字	件数・前月比・種類の内訳	同じ（ただし全自動で出る）
分析	時間の許す範囲で、目立つものを拾う	答えられなかった問い合わせを1件残らず確認し、原因まで分類
提案	気づいた範囲で数点	改善提案9件。それぞれに作業日数の目安と、誰の作業かを明記
効果	—	「直すとどうなるか」を実データで試算

上段の「数字」だけを見ると、これまでと変わりません。変わったのは、その下の3行の中身と量です。

これは、資料が厚くなったという話ではありません。お客様が受け取ったあと、次に何をすればいいかが書いてある資料になったということです。

そして弊社の側から見ると、次の商談の入口にもなっています。実績をご報告するだけの資料であれば、読んで終わりです。しかし「次に何をすると、どれくらいの手間で、何が良くなるか」まで書いてあれば、そのままご相談につながります。毎月お出しするものが、お客様との接点を作り続けてくれる。受託を主にしている立場では、ここも小さくない意味を持ちます。

変えたのは、AIの賢さではなく「目を通せる量」

なぜ書けるようになったのか。理由は単純でした。

これまでは、全部を見ることができなかったからです。

月に届く問い合わせを1件ずつ開いて、中身を読んで、なぜ答えられなかったのかを調べて、分類する。頭では必要だと分かっていても、受託開発と並行してこれを毎月やる時間は取れません。

もちろん、手作業でもまったく分析していなかったわけではありません。時間の許す範囲で目立つものを拾い、気づいた点はお伝えしていました。ただ、選んで見ている以上、そこから漏れたものは最後まで見えません。 どこまで見られたかが、その月に取れた時間で決まってしまう状態でした。

今回まずやったのは、数字を出す作業を人の手から完全に外すことでした。件数、前月比、内訳、日別の推移。こうした数字とグラフは、すべてデータベースへの集計スクリプトの出力だけを根拠にします。AIにも人にも数えさせません。

そして、そこで浮いた時間を「早く終わらせること」に使いませんでした。 これまで切り落としてきた1件ずつの分析を、まるごとAIに任せました。人がやるのは、上がってきた分析を確認して、資料に載せるかどうかを判断することです。

AIに任せたことで速くなった、という話ではありません。これまで量的に不可能だった仕事が、可能になったという話です。

全部見ると、粗い分類が崩れる

全件を見ると、何が起きるか。実例を書きます。

答えられなかった問い合わせについて、最初に出てきた分類はこういうものでした。

型番のご照会（該当データなし）／現在の製品情報に無い型番

それらしく見えます。件数も付いています。これまでなら、たぶんこのまま資料に載っていました。

ところが1件ずつ実データと突き合わせると、この中に性質のまったく違うものが3種類混ざっていました。

製品情報に型番が存在しない — 製品データそのものの追加が必要
型番は存在するが、聞かれた内容に答える情報が無い — 製品は登録済みなので、足りない項目（部品の単価や価格改定の履歴など）を追加すれば答えられる
他社製品からの照会 — 自社製品ではないので、他社型番との対応表をご用意いただければご案内できる

3つとも、必要な打ち手が違います。 ひとまとめに「該当データなし」と書いてしまうと、お客様は何を用意すればいいのか判断できません。

逆に、ここまで切り分けて出せれば、原因ごとに対策が決まります。 どこに手を打てば何が解決するのかが見えるので、限られた予算や工数を、効くところから順に割り当てられるようになります。

同じことが別の項目でも起きました。「取替検索が機能しておりません」という原案は、1件ずつ確認すると 3分の2は正しく回答できていました。 機能していないのではなく、特定の条件でだけ答えられていない。事実として違いますし、お客様の受け取り方も変わります。

粗い分類は、間違っているようには見えません。 ただ、受け取った側が次に動けないので、報告としては役に立ちません。全件見て初めて、その中の分かれ目が見えました。

見えたから、提案が書けた

原因まで分かると、そこから先が書けます。

最終的に、改善提案を9件まとめました。そして、それぞれに 作業日数の目安 と、こちら側の作業かお客様側の作業か を添えました。

たとえば「部品単価表をご提供いただければ、プログラム修正で対応できます。作業は1〜2日です」といった形です。

ここまで書くのは、「こうすると良くなります」だけでは、お客様が社内で検討にかけられないからです。どれくらいの手間がかかるのか、自社側で用意するものは何か。それが並んで初めて、次の会議の議題になります。

実際、今回の提案の多くはデータ整備なので、手を動かすのはお客様側でした。そこも隠さず書いています。

言い切る前に、実データで確かめる

提案には「これを直すとどうなるか」も付けました。ここでも全件の照合が土台になっています。

課題のひとつに「あるコードが登録されていない資料が大量にあり、製品ページに表示できていない」というものがありました。AIが出してきた効果の見積もりは「答えられなかった問い合わせが減る」というものです。

筋は通っています。資料が表示されれば、それで答えられる質問が増えるはずですから。

念のため、今月答えられなかった問い合わせを1件ずつ実データと突き合わせてもらいました。 すると、このコードの欠落が直接の原因だったと言える例は、ひとつも見つかりませんでした。

そこで書き方を変えました。答えられなかった件数が減る、とは書かない。代わりに 「製品ページに表示される資料の件数が増える」 という、実際に確かめられる効果だけを書く。改善する価値は変わりませんが、言えることを、確かめられた範囲まで狭めました。

逆に別の2件は、「このデータをいただければ、この分の問い合わせに答えられるようになります」と 実件数を根拠に書けました。これも、全件見ていなければ出せない数字です。

深く踏み込むほど、確かめる手間も増える

いいことばかりではありません。踏み込むほど、確認しなければならないことが増えます。

正直に書くと、この日1日で、AIが事実と違うことを断定した場面が5回ありました。 分母を取り違える、完全一致だけで照合して「該当なし」と結論づける、参照すべきデータの片方しか見ない。5回とも私が中身を確認して差し戻しています。

5つとも形は違いますが、中身は同じでした。「データがありません」という誤った断定です。存在するデータを「無い」と報告することは、お客様に不要な作業をお願いすることと同じなので、これは通せません。

なので、確かめる側にも手を打ちました。

書いた本人には見直させないこと。 PDFにする前に、別々のAIを2つ立てて、お客様の担当者を演じさせて読ませました。ひとつは Claude Fable、もうひとつは OpenAI の Codex です。役の指示は両方とも同じで、「Web担当者（技術者ではない）として読み、分からなかった言葉と数字を挙げてほしい」というものです。

同じ役を与えたのに、拾ってくるものが違いました。

	得意だったこと
Claude Fable	数値の矛盾・不整合の検出。「このページは13件なのに、次のページでは81件になっている」といった食い違いを見つけたのはこちらでした
Codex	網羅性と、費用対効果の視点。「データをお渡しすると、回答率は何%上がるのですか」という、お金を払う側の問いはこちらから出ました

これは以前、仕様書のレビューを観点ごとに分けたときにも同じことをしています。書いた本人ではなく、経緯を知らない相手に読ませる。

さらに、AIの原案をそのまま載せないことも徹底しました。実際に次の5か所は却下しています。

AIの原案	却下した理由
「他社製品の型番にお答えできていません」	他社の製品なのだから、答えられないのは当然です
「取替検索が機能しておりません」	言い過ぎです。3分の2は回答できていました
「こちらで改修を進めさせてください」	お客様の合意なく工数を使う提案はできません
「これはメーカー様の製品ではありません」と断定する記述	手元のデータだけでは判定できません
見出し「追加確認が必要だった件数」	初めて読む方に伝わりません