Analyzegear
自社サイトの問い合わせフォームには、直近1年で554件が届いていました。ところが中身を数えると、98.2%（544件）が営業・売り込み。自治体の企業誘致アンケート、相互リンク依頼、求人掲載の勧誘、投資の案内。問題は営業そのものではなく、その中に、本当に対応が必要な相談が数件だけ埋もれていることでした。全部に目を通すのは非現実的、かといって流し読みすると拾うべきものを見落とす。この「取りこぼしを防ぐ」ためにAIで仕分けを組んだ話を、技術者向けにまとめます。
先に断っておくと、これは「拾って人が見る」トリアージであって、自動対応ではありません。営業を自動で捨てる運用もしていませんし、返信を自動送信する機能はそもそもコードとして持っていません。あくまで「人が見るべき問い合わせを絞る」だけの仕組みです。決済者・非エンジニア向けの要約版は 実績ページの事例（問い合わせ554件から、対応すべき10件を拾う） にあります。
最初のつまずき ― 「分類の正確さ」を測っても何も分からない
当初は素直に「分類の正解率」を指標に置くつもりでした。ところが分布を見て手が止まります。直近1年の554件は、こう割れていました。
| 種別 | 件数 |
|---|---|
| 営業・売り込み | 544 |
| 採用 | 5 |
| 取材・掲載 | 3 |
| その他 | 2 |
| 開発・制作の相談 | 0 |
| 保守・障害 | 0 |
この分布だと、「全部を営業と答えるだけで98%正解」になります。正解率98%と書いても、何も証明していません。そこで指標を「554件から対応が必要なものを拾えるか」＝取りこぼさないか、に置き換えました。この案件で一番効いた判断は、コードでもプロンプトでもなく、指標を目的に合わせ直したことだったと思います。
構成 ― 個人情報を「最初から持たない」設計にした
- Laravel 13 / PHP 8.3 / SQLite（docker 不要の小さな検証環境）
- 分類：
claude-haiku-4-5。返信下書き：claude-sonnet-5 - データ取得：wp-cli 経由で本文のみエクスポート → マスクして取り込み → 一時ファイルは削除
- コスト管理：全コールのトークンと円を記録。月次上限3,000円で自動停止
- 送信：実装していない（送信の口をコードとして持たない）
個人情報の扱いは実装より先に決めました。AIに渡すデータを増やしてから絞るのではなく、最初から持たない方針です。MW WP Form の氏名・会社名・電話・メールの各項目はそもそも取り込まず、本文だけを取り込みます。そのうえで本文に混ざる連絡先を伏せ字にし、マスク前の原文は保存しません（保持180日・社内限定）。
| マスク対象 | 件数 |
|---|---|
| URL | 774 |
| メールアドレス | 149 |
| 電話番号 | 90 |
| 郵便番号 | 30 |
| 合計 | 1,043箇所（漏れ0） |
評価設計 ― 層化抽出と「正解を先に付ける」
精度は人が採点して確かめました。ここで全体からランダムに50件選ぶと、ほぼ全部が営業になり、拾う側の性能がまったく見えません。そこで層化抽出にしました。AIが「営業以外」と拾った10件（全件）＋「営業」と判定した40件（ランダム）の計50件です。
採点で守ったのは、AIの判定を採点画面に出さないことと、どちらの層かを伏せることです。AIの答えを見てから正解を決めると、それに引きずられて「正解」が動き、測ったことになりません。この点はG1（AI外観監視）で「正解ラベル自体が間違っていた」件と同じ問題意識で、正解は先に確定させておく必要があります。
| 人: 要対応 | 人: 営業 | |
|---|---|---|
| AI: 要対応 | 2 | 8 |
| AI: 営業 | 0 | 40 |
結果として、554件のうちAIが拾ったのは10件（1.8%）。分類コストは0.24円/件（554件で133円）、平均2.6秒/件でした。「人が見る量が554件→10件」というのがこの仕組みの実測値で、ここに満足度や応答時間の改善のような数字は付けていません（後述のとおり測っていないため）。
「正解率を上げる修正」が、目的を悪化させた
誤りの8件を見ると、5件が「採用」でした。「求人掲載しませんか」という採用を売り込む営業を、採用の問い合わせと読んでいたのです。そこでプロンプトに2段階で手を入れました。
- v2：「送信者が売り込んでいるなら、話題が何であっても営業」という判断基準を明示
- v3：v2に加えて「迷ったら拾う側に倒す」を追加
変更はプロンプトだけ。同じ50件・同じ正解で測り直しています。
| 条件 | 正解率 | 拾った中の本物 | 取りこぼし | コスト/件 |
|---|---|---|---|---|
| v1（最初の版） | 42/50（84%） | 2/10 | 0件 | 0.244円 |
| v2（売り込む側かを明示） | 46/50（92%） | 0/2 | 2件 | 0.314円 |
| v3（v2＋迷ったら拾う） | 46/50（92%） | 0/2 | 2件 | 0.358円 |
正解率は84%→92%に上がったのに、拾うべき2件を両方とも取りこぼしました。コストも上がっています。取りこぼしたのはメディア運営会社からの掲載依頼2件で、人は「対応すべき」、AI（v2/v3）は「メディアが自社サービスを売り込んでいる」と読みました。「迷ったら拾え」と明示しても変わらない、人の判断と割れる本質的にグレーな案件です。
一致率だけを見ていたら「改善した」と誤認していました。目的は取りこぼさないことなので、最初の版に戻しています。同じサンプル・同じ正解で並べたから、悪化に気づけたケースでした。
自信度は当てにならなかった ― タスク依存という現実
AIは分類ごとに自信度（0〜100）を返します。正解した42件は平均94、誤った8件は平均77。差はあります。でも「自信が高いものは人が見なくてよい」という足切りには使えませんでした。誤りの中に 92 / 92 / 95 が混ざっているからです。ここで足切りすると、その誤りごと人の目から外れます。
これは対照的な結果で、同じ設計思想で作ったG1（画像判定）では、誤報がきれいに低確信度側へ寄り、確信度60で足切りすると人に上がる誤報が0になりました。ところがテキスト分類のこのタスクでは効かない。「確信度で足切りする」という設計は、そのタスクで確信度が正誤と相関して初めて成立する——相関するかどうかは、タスクごとに実測しないと分かりません。
固有名詞はAIに書かせない ― コードで差し込む
返信下書きも作りますが（送信は必ず人）、ここでも実測でハマりました。下書きの本文に自社名をAIに書かせたところ、3件中3件で誤り。「アナライズガイア」「アナライズガー」「アナライズガア」と、それらしく崩れます。自信を持って崩すので、下書きをそのまま読むと気づきにくい。
// NG: 社名を本文ごとAIに生成させる → 3/3 で誤記
// OK: プレースホルダで書かせ、確定文字列をコードで差し込む
$body = str_replace('{{company}}', config('app.company_name'), $aiDraft);
// この方式に変えたところ 12件中0件社名・商品名のような間違えてはいけない固有名詞は、AIに書かせずコードで差し込む。当たり前のようでいて、生成AIを実務に入れると必ず踏むポイントです。なお下書きは作りましたが、返信下書きの採用率は測っていません。そもそも要対応が2件しかなく、率を出せる母数がないためです。
ダミーと実データを構造で分ける
画面のスクリーンショットに実際の問い合わせを1件も写さないため、表示はすべてダミーデータで固めています。ここで危ないのが、集計にダミーが混ざったまま数字を出してしまうことです。対策として、ダミーと実データを構造（フラグ）で分け、集計対象にダミーが混入したら数値を出さずに止めるガードを入れました。テストは21件で、マスク・機械点検・枠外カテゴリの排除・差し込み・仕分け指標に加え、「ダミー混入時に集計が止まること」も含めています。
数値の母数と、書いていないこと
すべて実測値です。誇大にならないよう母数と条件を添えます。554件→10件・98.2%（544件）が営業は「直近1年分（2025-09〜2026-09）・コーポレートの問い合わせフォーム」の値。2/10・取りこぼし0/40 は「50件の層化抽出を人が採点」した内訳で、本当に要対応だったのは2件のみ、率として出すには母数が小さすぎます。84%→92% は「同じ50件・同じ正解で指示だけを変えた」比較、0.24円・2.6秒は「554件の平均」です。
そして、測っていないので書かないこと。「返信下書きの採用率は◯%」は書けません（要対応が2件しかなく未計測）。「取りこぼしはゼロ」も率としては出せません（40件の抽出で0件、真陽性はn=2）。「一次応答が◯分速くなった」も導入前の対応時間を記録しておらず不可。そして「営業を自動で捨てられる」「問い合わせ対応を自動化」とは書けません——捨てる運用はしておらず、送信機能も実装していない。拾ったものを人が見るだけです。満足度・売上・検索順位のような数字も、この検証では扱っていません。
他の案件に持っていける設計
- 指標を目的に合わせる。偏ったデータでは正解率が意味を失う。「何のための仕組みか」から指標を決める。
- 同じサンプル・同じ正解で条件を比べる。改善のつもりが悪化していないかは、これでしか分からない。
- 正解はAIの答えを見る前に付ける。後から付けると測ったことにならない。
- 固有名詞はAIに書かせない。社名・商品名はプレースホルダで書かせ、確定文字列をコードで差し込む。
- ダミーと実データを構造で分ける。混ざったら集計を止める。
この仕組みは、問い合わせ・応募・申込など「量が多く、その大半が対応不要」な受信箱に応用できます。決済者・非エンジニア向けの要約は 実績ページの事例 に、AI活用の他の事例は AI活用ページ にまとめています。既存の受信箱へのAI導入のご相談は お問い合わせ から。
