社内のAI機能に「この答えは違う」と返せる仕組みを作るなら、ボタンを置くだけでは足りません。集めるべきは「どの入力に」「どの出力が返り」「何が正しかったか」の3項目で、この3つが揃っていない報告は、後から誰が見ても再現できず改善に使えません。逆にこの3項目さえ揃っていれば、報告件数が週に数件でも、修正の優先順位は付けられます。
この記事では、受注開発でAI機能を組み込むときに、利用者からの指摘を受け取る画面の作り方、集めた声の分類のしかた、そして改善へ回す運用の流れを、実装で詰まりやすい箇所と合わせて整理します。
フィードバック機能とは、何を集める仕組みか？
ここで言うフィードバック機能とは、AIが出した答えに対して利用者が評価や訂正を返せる入口のことです。チャット画面の親指アイコン（良い・悪いの評価ボタン）が代表例ですが、業務システムでは評価だけでは使えません。
理由は単純で、「悪い」だけが記録されても、開発側は何を直せばよいか判断できないからです。プロンプト（AIへの指示文）の問題なのか、参照しているデータが古いのか、そもそもAIに任せるべきでない質問だったのか、区別が付きません。
そこで、最低限そろえたい項目を次のように定めます。
| 項目 | 内容 | 取得方法 |
|---|---|---|
| 入力 | 利用者が送った質問、アップロードした書類、対象レコードのID | システム側で自動記録 |
| 出力 | AIが返した本文、参照した文書名、信頼度や判定区分 | システム側で自動記録 |
| 正しい答え | 利用者が「本当はこうだった」と考える内容 | 利用者が入力（任意だが強く促す） |
前の2つは自動で取れます。人に書かせるのは3つ目だけにする。ここを分けて設計するかどうかで、報告が集まるかどうかが変わります。入力内容を利用者に書き写させる仕様にすると、まず書かれません。
報告ボタンはどこに、いくつ置く？
置き場所は「AIの出力が表示されている、その場」です。別画面の問い合わせフォームに誘導すると、そこへ移動する手間の分だけ報告は減ります。出力の直下に、小さくても常に見える形で置きます。
選択肢の数は、迷わせない範囲で絞ります。設計の出発点としては次の3択を推奨します。
- 違う — 内容が事実と異なる、または的外れ
- 足りない — 方向は合っているが情報が不足している
- この質問には答えてほしくない — AIが扱うべきでない領域だった
3つ目を入れておくと、AIの誤答は「答えない条件」で減らすで整理したような「答えない条件」を後から足すための材料になります。誤答を減らす最も確実な方法は、答える範囲を狭めることです。その範囲を決めるのは、現場からの「これは聞いていない」という声です。
押した後の画面は、自由記述欄を1つだけ出し、未入力でも送信できるようにします。必須にすると、押す直前でやめる人が出ます。件数を取るのが先、内容の濃さは後です。
「良い」ボタンは要るか
要ります。ただし目的が違います。「違う」だけを集めると、全体のうちどれくらいが問題なのかが分かりません。良い評価も記録しておくと、機能ごとの手応えの差が見えます。ただし、良い評価が多いことをもって精度の証拠とするのは避けます。押す人は偏るためです。
集めた声はどう分類する？
報告が溜まり始めたら、原因の種類で仕分けます。ここを「AIの精度が悪い」の一言でまとめると、どこを触ればよいか分からないまま時間が過ぎます。受注開発の現場で実際に手を動かす単位に合わせて、次のように分けます。
| 分類 | 典型的な症状 | 直す場所 |
|---|---|---|
| データ不足 | 社内にしかない情報を知らない、古い規程を答える | 参照データの追加・更新 |
| 指示の不備 | 形式が揃わない、長すぎる、余計な前置きが付く | プロンプト・出力テンプレート |
| 検索の失敗 | 正しい文書が社内にあるのに引けていない | 検索の設計（分割単位・索引・キーワード） |
| 範囲外 | 人事評価や与信など、AIに判断させるべきでない質問 | 受付条件・人への引き継ぎ |
| 利用者側の誤解 | AIは正しいが、使い方が想定と違う | 画面の説明文・教育 |
分類の作り方そのものは、顧客の声をAIで仕分ける話と同じ考え方です。顧客の声のAI分類は改善の打ち手から逆算するで書いたとおり、分類は「打ち手が違うかどうか」で分けるのが基本です。直す場所が同じなら、呼び方が違っても同じ箱に入れて構いません。
最初のうちは、分類も人が手で付けます。週に十数件なら、担当者が5分で仕分けられます。件数が増えて手に負えなくなってから、分類自体をAIに任せる判断をすれば十分です。
改善へ回す流れはどう組む？
仕組みが止まる一番の原因は、報告が溜まるだけで誰も見ない状態です。これを防ぐには、見る日と見る人を先に決めます。次のような流れを、運用開始と同時に動かします。
- 週次で棚卸し — 担当者が1週間分の報告を開き、上の表の分類を付ける
- 再現を確認 — 同じ入力をもう一度AIに通し、今も同じ誤りが出るか見る
- 振り分け — その場で直せるもの（データ更新、説明文の修正）と、開発側に渡すものを分ける
- 反映 — 直したら、同じ入力で検証して結果を記録する
- 返す — 報告した人に「直しました」「これは仕様です」と短く返す
最後の「返す」を省くと、報告は数週間で止まります。返答が来ない入力欄に書き続ける人はいません。全件に返せないなら、週に1回、社内チャットで「今週直したもの」を3行だけ流す形でも効果があります。
また、2番目の再現確認は必ず入れてください。AIの出力は同じ入力でも揺れることがあり、一度きりの誤りを追いかけて設計を変えると、別のところが壊れます。再現しない報告は「要観察」として置いておき、同じ種類が3件集まった時点で着手する、といった基準を決めておくと判断が早くなります。
検証用の問題集を育てる
報告のうち、再現した誤りと正しい答えの組み合わせは、そのまま検証用の問題集になります。プロンプトを変えたときやモデルを切り替えたときに、この問題集を通して以前の誤りが再発していないかを確認します。
たとえば次のような場面です。利用者から「出張旅費の上限を間違えて答えた」という報告が3件来たとします。規程の該当箇所を参照データに追加して解消したあと、半年後にモデルを新しいものへ切り替える。このとき問題集がなければ、同じ質問がまた間違うかどうかを誰も確かめません。報告を資産に変えるとは、こういうことです。
実装で詰まりやすい箇所はどこ？
設計そのものより、周辺で止まることが多い箇所を挙げます。
個人情報と機密の扱い。報告には入力内容がそのまま保存されます。顧客名や取引条件が含まれる可能性があるため、保存先、閲覧できる人、保存期間を先に決めます。個人情報保護法で定められた安全管理措置の考え方や、総務省・経済産業省のAI事業者ガイドラインが示す透明性の論点とも関わる部分です。社外のサービスに報告ログが送られる構成になっていないか、契約前に確認しておく価値があります。
報告が来ない。ボタンを置いても、最初の1か月は数件ということがあります。使われていないのか、満足しているのか、押しにくいのかを切り分けるには、利用回数そのものを併せて見る必要があります。利用が落ちているなら、使われなくなるAIの共通点4つと立て直し方で挙げた原因のほうを先に疑います。
報告が多すぎる。逆に大量に来る場合、大半は同じ原因であることがよくあります。まず分類し、上位の2つか3つに絞って手を付けます。全件対応を目指すと、優先順位が崩れて何も終わりません。
報告した人が特定される不安。誰が押したか記録するかどうかは、組織の文化次第です。記録するなら、評価に使わないことを明示します。匿名にするなら、追加の聞き取りができなくなる点を踏まえておきます。
改善の担当が不在になる。週次の棚卸しを属人化させると、担当者の異動で止まります。手順と判断基準を文書にしておき、引き継げる形にしておくことが前提です。
まとめ
AI機能に「この答えは違う」と返せる仕組みを作るときの要点を整理します。
- 集めるのは入力・出力・正しい答えの3項目。前2つは自動記録し、人に書かせるのは正解だけにする
- ボタンは出力の直下に置き、選択肢は「違う」「足りない」「答えてほしくない」の3択から始める
- 集めた声は直す場所で分類する。データ、指示、検索、範囲外、誤解の5つが出発点になる
- 週次の棚卸し、再現確認、反映、報告者への返答までを1つの流れにする。返答を省くと報告は止まる
- 再現した誤りと正解の組は検証用の問題集として残し、モデル変更時の確認に使う
- 報告ログに含まれる個人情報や機密の保存先と期間を、実装前に決めておく
精度を上げる作業の多くは、モデルを変えることではなく、現場が気付いた「違う」を拾い直すことです。その導線を最初の設計に組み込んでおくと、運用が始まってからの改善が、推測ではなく事実に基づいて進みます。