LASSIC Media らしくメディア

AIに渡す情報と担当者が判断する場所を決める

問い合わせフォーム営業の自動化では、攻略リスト、自社の提供内容、判定基準をAIへ渡し、営業文の下書きと返信分類案を受け取る設計が考えられます。担当者は受付条件の判断、文面の承認、返信への対応を担います。

工程は、フォーム探索、下書き、承認、送信と記録、返信分類の順です。探索・送信・記録は利用環境で対応が裏付けられた範囲を自動処理へ渡し、それ以外は人が担います。

以下の入力・指示文・出力・修正は、すべて編集部作成の説明用の架空例です。役割分担も設計提案であり、AI実行結果や導入事例ではありません。

入力情報と受付条件から進める案件を選ぶ

主案件A001は、架空企業Bの公式サイト内の問い合わせページです。企業情報は「法人向け研修を案内している」、不明点は「日報の運用方法と集計上の課題」とします。

送り手の架空の営業会社Aには、「営業日報の入力項目と集計手順を整理する支援」と、その説明資料がある設定です。この設定は記事の例だけに使います。

受付条件は企業情報と分けます。A001は業務改善の提案を受け付け、担当者が今回の紹介を許容範囲と判断した設定です。営業禁止のA002は除外し、受付目的が不明なA003は送信を保留します。認証・CAPTCHAに遭遇した場合も自動処理を止め、人へ戻します。

相手の課題が不明でも、課題を断定しない紹介文は作る設計にできます。一方、自社の提供内容がなければ下書きを保留します。

下書きは入力に戻って直してから承認する

A001には次のように指示します。

「確認済みの企業情報と自社の提供内容だけで問い合わせ文を作ってください。相手の課題・実績・効果は補わず、下書き、使用した入力項目、不明点を返してください。必要な情報が欠ければ作成を保留してください。」

誤りを含む出力例を置きます。

下書き：「貴社は日報の集計にお困りと考え、当社の支援をご案内します。」 参照入力：「自社の提供内容」 不明点：「相手の日報運用と集計上の課題」

入力には相手が困っているという情報がないため、次の文へ直します。

「当社は営業日報の入力項目と集計手順を整理する支援を行っています。支援内容の資料をご希望でしたらお知らせください。」

担当者は修正文を入力と受付範囲に照らして承認します。

送信要求と受付完了を分けて記録する

承認後は案件に四つの記録を結びつけます。「確認画面表示」は入力内容を確認する画面、「送信要求」は送信操作の記録、「受付完了」は受付を示すと判断できる表示・応答、「相手返信」は別途受け取った返信です。これはサイト共通の仕様ではなく、編集部の記録設計です。

A001で送信要求だけが残り、受付を示す結果を記録できなかった分岐は「結果不明」とします。完了にも未送信にも決めつけず、自動再送を保留し、承認文面、操作時刻、確認できた表示を担当者へ渡します。

受付完了を記録できた別の分岐でも、相手の閲覧や返信は推定しません。

返信の分類案を担当者の対応につなぐ

ここからはA001で受付完了後に返信を受け取った、別々の仮定分岐です。自社基準を、資料送付の依頼は「資料希望」、面談や日程調整の依頼は「日程調整希望」、明示的な断りは「辞退」、それ以外や文脈不足は「判断保留」とします。

指示文は「返信を自社基準で分類し、分類案、本文中の根拠、判定理由、不明点を返してください。本文にない意思を補わず、基準を満たさなければ判断保留にしてください」です。

返信「支援内容の資料を送ってください。」に対する出力例は「分類案：資料希望／根拠：資料を送ってください／理由：資料送付の依頼がある／不明点：希望する詳しさ」です。担当者が希望内容と資料を照合して対応します。

別の返信「社内で検討します。」を日程調整希望と分類した例では、面談の依頼がないため判断保留へ直します。次の対応が指定されていない旨を残し、担当者が対応の要否を決めます。

修正理由と確認・修正にかかった時間も案件に残します。同等の従来作業より負担が増えるなら、AIの役割を下書きや根拠整理に絞る選択ができます。

不足している情報によって保留する処理を分ける

自社へ当てはめる際は、不明点をすべて埋めるのではなく、その情報がどの処理に必要かを分けます。相手の課題が不明でも、自社の提供内容がそろっていれば、課題を断定しない紹介文を作る設計にできます。自社の提供内容が欠ける場合は下書きを、受付目的や利用条件から今回の提案の許容範囲を判断できない場合は送信を保留します。

以下の入力項目、承認記録、引き継ぎ方法、評価方法は編集部の設計提案です。案件や返信、画面表示の記録も説明用の架空例です。

総務省・経済産業省の「AI事業者ガイドライン 第1.2版」は、入力データの正確性と必要な場合の最新性を確保し、出力の精度やリスクを理解して利用することを示しています¹。以下の具体的な項目や分岐は、同ガイドラインの指定ではありません。

入力表は、企業情報、自社情報、受付条件を分けて持たせます。既出の架空例を入力欄に対応づけると、次のようになります。確認日時や確認者は記録欄だけを示し、架空の値は補いません。

企業の事業紹介を読んだ記録と、今回の営業提案を受け付けると判断した記録は分けます。情報が不足したときも、文章の根拠に関わるのか、送信先の選別に関わるのかで止める処理が変わります。

紹介文に書かない相手の課題を調べ終えるまで待つ必要はありません。一方、紹介する支援の内容が決まらないまま、企業情報だけから訴求内容を作らせる運用にはしません。

承認記録には修正文と入力の対応を残す

文面が入力にある提供内容と用意できる資料に対応し、今回の紹介が受付の許容範囲に入ると担当者が判断できた場合に、承認へ進める設計にします。完成文だけでなく、参照入力、変更箇所、変更理由、受付範囲との対応を残します。

「AI事業者ガイドライン 第1.2版」では、AIの評価や判断を人が承認する際に、承認する理由や根拠を人自身が独自に考えることが提案されています¹。

承認理由は「読みやすい」「問題なさそう」だけで済ませず、採用する表現を入力へ戻して説明できる形にします。自社の提供内容を書く文は自社情報へ、相手について書く文は企業情報へ戻り、文章の自然さと根拠を分けて判断します。

A001の架空の承認記録は、次のように整理できます。

承認したのは自社の支援と資料を紹介する文面であり、相手にその支援が必要だという判断ではありません。文章から課題の記述を削っても、新たな情報が得られていない限り、その課題は不明のままです。

文面の承認と送信先の判断を分けると、差し戻す理由も絞れます。文章の根拠がそろっていても受付範囲を判断できなければ送信を保留します。受付範囲を判断できても、入力にない実績が文面に加わっていれば修正へ戻します。

引き継ぐ承認記録には、承認した修正文そのものを結びつけます。「修正済み」という表示だけで済ませず、送信記録を読む担当者も、どの内容を送る判断だったか照合できるようにします。

結果不明と受付完了を記録で見分ける

送信要求は残っていても受付を示す結果を記録できない場合は、案件、承認文面、操作時刻、確認できた表示、結果不明とした理由、自動再送を保留していることを一組で渡します。受付結果の記録がないことを、未送信の証拠にはしない設計です。

A001について、結果不明と受付完了の二つの架空記録を比べます。別々の仮定分岐であり、同時に起きた出来事ではありません。どちらも、案件と承認した修正文を記録に結びつけます。

この比較は、対象サイトでの受付完了を保証する判定表ではありません。受付完了を記録できた場合は判断に使った表示・応答を残し、返信は実際に受け取った場合だけ別に追加する、という記録設計です。

MDN Web Docsは、フォームの送信前に必須項目が正しい形式で入力されていることを確かめる重要性を説明しています。また、クライアント側の検証は初期の確認であり、サーバー側でもセキュリティの確認を含む検証を行うべきとしています²。これは検証の設計上の説明であり、すべてのサイトでの実装や受付完了を保証するものではありません。

入力条件を満たしたことは、営業提案の許容や受付完了の代わりに使わない設計にします。必須項目が埋まっていても受付範囲の判断は別に残り、形式上のエラーが出なかったという記録だけで受付完了には変更しません。

認証・CAPTCHAで自動処理を止めた場合は、停止した箇所と、そこまでに確認できた表示を記録します。送信要求と受付結果を分け、停止理由だけから送信済み・未送信を決めません。担当者には操作の続行を一律に依頼せず、残っている判断とその材料を渡します。

辞退と文脈不足では担当者の対応が変わる

ここでは、A001で受付完了後に返信を受け取った場合の架空例を追加します。二つの返信は別の仮定分岐であり、同じ相手から順に届いたものではありません。

一つ目は「今回は提案を見送ります。追加のご連絡は不要です。」です。出力例を次のように置きます。

担当者は「追加のご連絡は不要です。」も対応の根拠として残し、辞退を記録して対応を終了します。辞退理由の詳細が不明でも、断りと追加連絡不要が明示されていれば、この基準では対応を終えられます。不明点があることと、次の対応を決められないことを分けて扱います。

二つ目は「その件はお願いします。」です。この例では、「その件」が何を指すか分かる過去のやり取りを入力に含めていないものとします。

肯定的に見える言葉だけで資料送付や面談の希望を補わず、担当者へ渡します。既存のやり取りに依頼対象を特定できる情報があれば、担当者が該当箇所を返信に結びつけて分類・対応を選びます。その情報がなければ判断保留を維持し、推測で資料送付や日程調整へ進めません。

担当者が分類案を変える場合は、変更後の分類名と、判断に使った本文や文脈を残します。明示された断りを受けて終了した案件と、依頼対象が分からず保留した案件を、同じ「対応なし」にまとめない運用です。

修正理由から入力・基準・任せる範囲を見直す

修正や差し戻しが続くときは、必要な入力の不足、基準の曖昧さ、任せる範囲の広さを分けて考えます。記録には案件と工程を軸に、修正前後、判断の変更、差し戻し理由を結びつけます。

A001の下書きについて、架空の記録例を整理します。

この例では、紹介に必要な自社の提供内容は入力済みです。相手の課題を必ず収集する扱いにはせず、入力外の課題を補わない文章基準と、入力に戻って承認する手順を見直します。

一方、紹介する自社の提供内容が入力から抜けていた場合は、言い回しを直す前に入力項目を整えます。必要な情報を渡していない問題と、渡した情報を越えて記述した問題では、直す場所が異なります。

返信分類でも、必要な文脈を担当者が持っているのに入力へ渡していなかった場合は、文脈の渡し方を直します。基準自体が曖昧だった場合は、どの記述があれば分類でき、何がなければ保留するかを具体化します。根拠のない返信まで分類できるよう、基準を緩める運用にはしません。

入力と基準を整えても同じ作り直しが続く工程では、AIに任せる範囲を縮めます。例えば返信分類なら、根拠箇所と不明点の整理だけを受け取り、分類は担当者が決める方法があります。

確認に使った時間と修正に使った時間も分け、同じ案件・工程・修正理由に結びつけます。書き直す量は少なくても入力との照合に時間がかかる場合と、照合は短くても書き直しが多い場合を見分け、任せる範囲を選ぶ材料にします。

同じ完了範囲で比べて続ける工程を選ぶ

評価では、同程度の案件条件、同じ完了範囲、同じ品質基準をそろえます。入力準備や差し戻し処理を含む担当者の作業時間を従来作業と比べ、確認・修正時間はその内訳として見ます。

下書き作成なら、担当者が入力との一致を確かめ、必要な修正を終えて承認するまでを比較の終点にします。返信分類なら、根拠を読んで担当者が分類と対応を判断するまでです。案が返ってくる速さだけで、実務の負担が減ったとは評価しない方法です。

案件条件は件数だけでそろえず、提供内容や受付条件がそろった案件と、不足情報があって保留した案件を分けます。返信も、依頼内容が明示されたものと、文脈を読み直す必要があるものを分けて比べます。

担当者の総作業時間には、入力を整える時間、出力を確認する時間、文面や分類を修正する時間、差し戻しや引き継ぎを処理する時間を含めます。確認・修正時間を内訳として残す場合は、総作業時間へ二重に加算しません。文章を直す時間が短くても、入力準備へ負担が移っていないかを見ます。

品質基準も比較の両側でそろえます。入力にない課題や実績を採用しないこと、受付範囲を判断できない案件を送信へ進めないこと、分類に根拠がなければ保留することを共通にします。従来作業で行っていた確認を省いた結果を、同じ品質での時間短縮とは扱いません。

保留件数を減らすことだけも目標にしません。必要な条件に従って保留したのか、渡すべき情報が欠けて止まったのかを分け、適切な保留を残しながら、情報の渡し忘れや曖昧な基準による差し戻しを見直します。

続けるかどうかは工程ごとに選べます。下書きの修正が少なくても返信分類の作り直しが続くなら、下書きは残し、返信は根拠整理だけにする選択があります。条件をそろえた比較で担当者の負担が増える工程は、人が担う範囲を広げます。必要な品質まで仕上げる負担を基準に、分担を決める考え方です。

入力から対応まで根拠をたどれる分担へ

自社へ当てはめる出発点は、完成した営業文だけでなく、何を渡し、何を根拠に直したかを一続きで見ることです。入力不足なら入力を、基準が曖昧なら基準を直し、それでも確認負担が増える工程は任せる範囲を縮めます。必要な品質まで仕上げる負担を基準に、担当者が対応を決められる分担を選びましょう。