卸売業の商品問い合わせ、AIが在庫や納期を言い切らない仕組み

AIを活用して商品問い合わせに自動応答させる場合、在庫や納期を確実に保証しないことが重要です。まずは「商品説明」と「在庫照会」を分離し、参照時点・引当者・確約者を明示した回答テンプレートを作成しましょう。

商品説明と在庫照会を分ける

商品説明はどこまでAIに任せられるか

AIは商品カタログや仕様書を元に、魅力的な商品説明文を生成できます。ただし、在庫数や出荷可能日といったリアルタイム情報は含めないように指示します。たとえば「この商品は高品質な素材を使用しています」までで止め、在庫情報は別プロセスで取得させます。

担当者はAIに与えるプロンプトに「在庫・納期は含めない」旨を明記し、生成結果をレビューするフローを設けます。これにより、誤った在庫情報が顧客に伝わるリスクを防げます。

次に、商品説明の品質を保つために、定期的にカタログデータを更新し、AIの学習ベースを最新化します。更新作業は商品部門が中心となり、変更点をドキュメント化してAI開発チームに共有します。こうした情報管理体制が整えば、AIは常に正確な商品特徴だけを伝えることが可能です。

在庫情報の参照時点を明示する方法

在庫照会はリアルタイムデータベースへのクエリで取得し、取得した時点のタイムスタンプを必ず回答に付加します。たとえば「2026年10月16日 10:05時点の在庫は5個です」と表示すれば、顧客は情報が古い可能性を認識できます。実装は、在庫管理システムのAPIを呼び出すミドルウェアを介し、AIが取得したデータを加工してテンプレートに埋め込む形がシンプルです。

この際、システム担当者はタイムスタンプ形式や時差の扱いを統一し、社内マニュアルに記載します。顧客対応マニュアルにも「在庫は参照時点の情報であり、変動する可能性があります」旨を追記し、問い合わせ時に自動で提示できるようにします。

引当と確約者の役割分担のポイント

在庫が確保できたかどうかは「引当担当者」が判断し、最終的に顧客へ提示できるかは「確約者（営業または受注担当）」が決定します。AIはあくまで情報提供者であり、確約権限は持ちません。したがって、AIの回答には「※在庫は引当確認中です」や「※確約は営業担当が行います」などの文言を必ず入れます。

役割分担を明確にするために、社内フロー図を作成し、AIが回答を生成した後に引当担当へ自動通知し、確約者が最終チェックを行うプロセスを設定します。このプロセスは業務マニュアルに掲載し、担当者間で合意を得たうえで運用開始します。

納期を確約する前の確認を設計する

納期情報の取得フローを可視化する

納期は生産計画や物流状況に左右されるため、AIが直接算出せず、ERPや物流システムから取得した予測値を参照します。まずは「受注→生産計画→出荷予定」の各段階で必要なデータ項目を洗い出し、取得APIを設計します。取得した納期は「予測値（例：±2日）」として表示し、確定ではないことを明示します。

可視化の手段としては、フローチャートを社内Wikiに掲載し、担当者がどのタイミングでデータが更新されるかを一目で把握できるようにします。フローチャートは定期的にレビューし、システム変更があれば即時更新します。

「最新保証なし」表示の具体例

顧客に対しては、納期情報に必ず「※本情報は取得時点の予測であり、最新保証はありません」といった注釈を付けます。具体例としては、"2026年10月20日出荷予定（取得時点：10月16日）※最新保証なし" のように、取得日時と注釈を同時に提示します。

この注釈はテンプレート化し、AIが自動で付与できるように設定します。テンプレートは営業部門と協議のうえ、顧客が混乱しない表現に統一します。注釈の有無はシステム側でフラグ管理し、抜けがないか定期的にチェックリストで確認します。

顧客への回答テンプレート作成手順

まずは顧客が最も知りたい情報（商品名、在庫数、納期予測）を列挙し、各項目に対する注釈ルールを決めます。次に、テンプレートエディタでプレースホルダー（{{product_name}}、{{stock_time}}、{{lead_time}}）を配置し、注釈文を固定文として組み込みます。

完成したテンプレートは、AIの出力後に自動置換エンジンが実行し、最終的なメッセージとして顧客に送信します。テンプレート変更時は変更履歴を残し、営業担当が承認したうえで本番環境に反映させます。これにより、回答内容の一貫性と注釈の徹底が保証されます。

##導入時に確認すべき内部体制と資料は？

連携仕様と承認の条件を揃える

担当者の権限と承認プロセスの設定

AI導入前に、商品説明作成、在庫照会、納期提示のそれぞれに責任者を決めます。権限は「閲覧のみ」「編集可」「確約可」の3段階に分け、システム上でロールベースのアクセス制御を設定します。承認プロセスは、AIが生成した回答が顧客に送信される前に、必ず担当者のレビューを経るようにワークフローを組み込みます。

このプロセスは、業務フロー図と承認ルート表にまとめ、関係者全員に周知します。承認が遅延した場合の代替手段（例：自動返信で保留旨を伝える）も事前に定義しておくと、顧客対応の遅れを防げます。

必要なデータ連携仕様書の作り方

AIが参照する在庫・納期データは、既存の基幹システムからAPIで取得します。仕様書には、エンドポイントURL、リクエストパラメータ、レスポンス項目、エラーハンドリング方法を詳細に記載します。特に「取得時点」のタイムスタンプ項目は必須です。

作成手順は、①要件定義（どのデータが必要か）②システム担当者とのヒアリング③ドラフト作成④関係部門レビュー⑤最終版承認、の5ステップです。完成した仕様書は、開発チームと運用チームが共有できるリポジトリに保管し、改訂履歴を管理します。

セキュリティリスクと対策のチェックリスト

AIが外部に情報を出す際のリスクは、機密情報漏洩や不正改ざんです。IPAのガイドラインに基づき、以下の項目をチェックリスト化します：①入力データのサニタイズ、②出力内容の検閲、③通信の暗号化（TLS）、④アクセスログの取得、⑤異常検知アラートの設定。

チェックリストは、導入前のテストフェーズで全項目が合格したことを証明するレポートを作成し、経営層に提出します。レビューは、組織のリスク管理方針に合わせて年1回程度実施することが一般的ですが、システムに大きな変更が生じた際は都度実施し、リスクが新たに生じていないか確認します。

##運用開始後の評価と改善はどう行うか？

公開後の確認と異常時の対応を決める

AI応答の正確性をモニタリングする指標

主な指標は「在庫情報の参照時点ずれ率」「納期予測の誤差率」「顧客クレーム件数」の3つです。参照時点ずれ率は、AIが提示した在庫数と実際の在庫数の差を取得時点で比較し、％で算出します。納期予測の誤差率は、予測納期と実際出荷日との差日数を平均化したものです。

これらの指標は、ダッシュボードに可視化し、月次レビューで目標値（例：ずれ率5％未満）を設定します。指標が目標を超えた場合は、原因分析を行い、プロンプトやデータ取得ロジックの見直しを実施します。

誤情報が出たときの対応フロー

誤情報が顧客に届いたら、まずは自動的に「謝罪と訂正」のテンプレートメールを送信し、担当者にアラートを上げます。担当者は誤情報の内容と原因を特定し、社内の「情報訂正手続き書」に記録します。その後、修正済みの正しい情報を再送し、顧客の理解を得ます。

フローの各ステップは、業務マニュアルにフローチャートとして掲載し、担当者が手順を迷わず実行できるようにします。また、同様の誤情報が再発しないよう、原因がシステム設定かプロンプトかを判別し、必要な改善策を速やかに適用します。

外部専門家への相談タイミングと判断基準

AIの回答精度が一定期間改善せず、指標が目標を大きく下回る場合は、外部のAIコンサルタントやセキュリティベンダーに相談します。判断基準は、例えば「指標が3か月連続で目標に達しない」または「顧客クレームが月10件を超える」など、組織の実情に合わせて設定します。

相談時には、現在のフロー図、チェックリスト、指標レポートをまとめた資料を用意し、課題の概要と期待する支援内容を整理します。外部専門家からの提案は、社内の意思決定プロセスに沿って評価し、必要に応じてシステム改修や運用ルールの刷新を行います。