通販の注文を購入時の返品条件に戻して確認し、人が根拠と不足資料を残すデモ

想定した課題・業務フロー

問い合わせ時の現行FAQが、購入時にも表示されていたとは限りません。旧版の条件を今の条件で置き換えず、名入れ商品の購入者都合と破損・品違いを分け、何を誰に確認するかを根拠と一緒に残すことを課題にしました。

実施内容

架空の返品条件2版・現行FAQ・注文8件を読み合わせた検証ラボをもとにしたデモです。コードによる暦日差と版候補の確認、保存資料の閲覧、理由・担当付きの判断、照合一覧・社内の確認依頼・採用した返信案・履歴のJSON書き出し、手動取り込みを加えています。精度・正答率・正しさや導入の可否は評価しておらず、時間短縮・費用効果も測定していません。

架空の条件と、注文ごとに戻る根拠

• 旧版V1は9月1〜30日の注文、新版V2は10月1日以降の注文の設定です。通常雑貨Gの購入者都合は、到着翌日を1日目として旧版は14暦日、新版は7暦日以内に連絡する設定で、返送到着の期限ではありません。新版は過去注文の旧版を置き換えません。
• R1〜R7には購入時の商品ページ・最終確認画面の保存資料P1〜P7がある設定です。実際の表示記録を人が確認した結果ではありません。R8は注文日・商品群・保存資料が欠けており、版や群を推測せず確認待ちにします。
• R3は9月30日注文のV1、R4は10月1日注文のV2です。どちらも申出日は10月ですが、申出日で版を選びません。コードが示す注文日による版の候補と、購入時の保存資料を人が確かめます。
• 名入れ雑貨NのR5は購入者都合の対象外候補です。差2日でも通常雑貨の期限・送料を流用しません。破損のR6は差15日を拒否理由にせず、品違いのR7には名入れの除外を使わず、品質担当の確認待ちにします。
• 期限・費用負担は架空の設定で、公的資料から導いた条件や転用するためのひな形ではありません。返品条件の適法性や表示方法の適否、表示要件の網羅は確認していません。

デモで加えた人の記録と、変更後の扱い

• 条件表V1・V2、10月15日時点の現行FAQ、注文と保存資料、先に固定した想定表を見比べます。「保存資料を開く・不足を確認」で原記録の設定を開き、人が版・候補・理由・担当・確認チェックを入力します。確認待ちでは確認先と終了に必要な資料も必須です。
• 人の入力欄は空から始まります。返信案は読み取り専用の下書きから写して採用し、記録後は入力を消して二重記録を防ぎます。保存資料を開いていない注文、注文日と保存資料の版が不一致の注文、必須項目が欠けた判断は記録できません。
• 人が採用した返信案に「返金いたします」「返品はお受けできません」などの限られた要確認語句が残ると、記録を止めます。語句の検出は確認の印であり、送ってよいかの判定ではありません。返信案は送信しません。
• 注文の編集・追加、CSV貼り付け、条件表・FAQの編集を試せます。変更した注文は再整理待ちになり、保存済み候補は使えません。条件表・FAQの編集は全注文が対象です。AIは再処理しません。
• 架空データと生成AIへの指示をコピーし、人が作った候補JSONや任意の生成AIで別途作った出力を手動で取り込めます。アプリから外部へ接続せず、取り込んだ文章は命令として実行せず文字列として表示します。
• 入力・候補の変更や候補の版の切り替えで判断を無効にし、記録者を「コード（入力・候補の変更）」として履歴に残します。編集して元に戻しても古い候補は復活しません。入力と判断はブラウザのメモリー内だけで、再読み込みで消えます。

実演モードと、意図的な誤りの教材

• 実演モードは事前に用意したAIの出力例の再生です。その場でAIを呼ばず、外部APIやAPIキーは使いません。「現行FAQのみ」「購入時の版・条項付き」「意図的な誤りの教材」を切り替え、根拠・不足資料・確認先・返信案と想定表を比べます。
• 教材は、R3で申出日から新版を選ぶ、R6の破損に購入者都合の期限を使う、R7の品違いに名入れの除外を使う、R8の欠けた注文日・商品群・版を補う候補です。R6の返信案には拒否の確定、R8には返金の約束も混ぜています。
• 教材は照合用に意図して入れた候補で、AIの自然な失敗を観察した結果や、AI・コードが誤りを検出できた結果ではありません。
• 比較用のFAQ版は「確認待ち」だけを記録でき、教材の版では「条件に合う候補」を記録できません。FAQのみの書き出しには comparison: true、教材には teaching: true が付きます。

使った技術

Node.js、JavaScript、ブラウザの画面、CSV、JSON。Node.js 22以上で動き、npm startでローカルサーバーを起動します。追加の依存パッケージやAPIキーは不要です。MIT Licenseで公開されています。元の検証ラボの短いJavaScriptは「申出日−到着日」のUTCの暦日差だけを計算し、AIを呼ばず、返品可否を判定しませんでした。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボの(a)は現行FAQだけを使ったため、旧版対象のR1・R3が7暦日の条件に合わない候補となり、旧版の14暦日で合う候補という想定と反対になりました。残る6件も購入時の版は未照合でした。ただし、名入れの例外と破損・品違いの区別はFAQから残せました。
• 購入時の版・条項を残しても、R8の欠けた表示資料は戻りません。R6・R7にも商品状態や注文仕様の確認が残ります。日付差だけでは、期限や費用の適用を決められません。

検証から得た学び

• 問い合わせ時の現行FAQと購入時の表示を分け、注文日・保存資料・版・条項・理由・不足資料・確認先を残す必要がありました。元の検証ラボの(b)は8件の版・主な候補・理由・不足資料・確認先が想定表と一致しましたが、同じAIが先に想定表を固定した自己照合で、人の評価・独立評価や正答率ではありません。全8件が人の確認待ちです。
• 破損・品違いに購入者都合の期限や名入れの除外を流用しないこと、欠けた購入時の表示を推測で補わず人が集めることが重要でした。(b)の新たな取り違えや想定表の修正、候補の再試行はありませんでした。
• 元の検証ラボの返信案を同じAIが読み合わせた範囲では、返品・返金の約束、受付拒否の確定、送料や期限適用の確約は見つかりませんでした。そうした文言がないことと、送信してよいことは別で、送信はしていません。
• 元の検証ラボのコードは暦日差の計算だけです。保存資料を開く操作、記録の必須項目と止める条件、要確認語句の印、意図的な誤りの教材、再整理待ちと判断の無効化、確認依頼・履歴の書き出し、手動取り込みはデモで加えたものです。

同様の取り組みが向いている条件

• 購入時の返品条件と現在のFAQを分け、注文・商品群・申出理由ごとに根拠へ戻りたい場合。
• 購入時の表示記録と注文の対応を人が確かめ、表示管理担当・品質担当への不足資料と確認先を残せる場合。
• 表示記録の保存と追跡、権限管理、記録の永続化、個人情報の管理、責任者の確認手順、専門家への法的な確認を別途用意できる場合。

補足

返品・返金の可否、期限の適用、送料等の費用負担、条件の適法性・表示方法の適否を判定する機能はありません。返信の送信、返金・受付の確定、返送の指示、条件表の原本への書き戻し、外部接続の機能もありません。実際の画面・表示履歴、複数商品の注文、交換履歴、注文日時の境界、長い規約、OCRは元の検証ラボで試していません。向いている条件は仕組みと限界から整理したもので、実案件への適用を確認したものではありません。