Claudeで返品・返金の規程と対応事例を突き合わせ、判断ぶれを点検する
返品・返金・交換の規程PDFと過去の対応事例をClaudeのProjectsに置き、案件ごとに根拠条文つきの可否案を出させる手順です。担当者ごとの判断ぶれと、特定商取引法との食い違いも洗います。
返品・返金・交換の問い合わせで判断がぶれる原因の多くは、規程が曖昧なことと、過去の対応が共有されていないことにあります。規程PDFと過去の対応事例をClaudeのProjectsに置けば、案件ごとに「どの条文に当たるか」を示した可否案を出させ、同じ規程で担当者の結論がどこまで割れているかも一覧にできます。
この記事では、Projectsへの資料の置き方、可否案を出させる指示、事例集を使った判断ぶれの点検、規程そのものと特定商取引法の食い違いを洗う順に進めます。返信文を整える段階はClaudeで問い合わせ返信を作る手順にあり、ここでは返信の前にある「可否の判断」を扱います。
規程と事例をProjectsに置くと何が変わるか
Projectsは、チャット履歴とナレッジベースを持つ独立した作業スペースです。ナレッジに置いた資料は、そのプロジェクト内のすべてのチャットで使われます。
返品・返金の判断に向く理由は2つあります。
- 規程が毎回の前提になる。貼り直さなくても、どのチャットでも同じ規程が参照される
- 事例集を置ける。過去にどう判断したかが、規程の読み方の手がかりになる
ただし限界もあります。プロジェクト内でもチャット同士の文脈は共有されません。共有したい情報はナレッジに入れる必要があります。ある案件で「この場合は例外にした」と決めても、それをナレッジに書き足さなければ、次のチャットでは反映されません。
Claudeに任せるのは、可否の「案」と根拠条文の提示までです。返金に応じるかどうかは会社の意思決定なので、最終判断は担当者が行います。
特定商取引法の返品ルールを前提に置く
通信販売の返品には、規程より先に法律の枠があります。規程を点検するなら、この枠をナレッジに入れておく必要があります。特定商取引法第15条の3は、通信販売の契約について次のように定めています。
| 論点 | 条文の内容 | 規程で確かめる点 |
|---|---|---|
| 返品できる期間 | 条文の内容商品の引渡しを受けた日から起算して8日を経過するまで、申込みの撤回または契約の解除ができる | 規程で確かめる点起算日が「引渡し」になっているか |
| 例外 | 条文の内容事業者が返品の特約を広告に表示していた場合は、この限りでない | 規程で確かめる点特約がサイトの表示にも載っているか |
| 返送の費用 | 条文の内容撤回等があった場合、引取りまたは返還の費用は購入者の負担 | 規程で確かめる点送料負担の書き方が条文と合っているか |
第11条は、広告に表示すべき事項のひとつとして、申込みの撤回または解除に関する事項を挙げています。特約がある場合は、その内容も含みます。
つまり、規程の社内版で「開封後は返品不可」と決めていても、その特約をサイトの広告に表示していなければ、特約として効かない可能性があります。社内規程と広告表示の食い違いは、担当者の判断ぶれより先に潰したい論点です。サイトから申し込む契約では、広告の表示に加えて、最終確認画面での特約の表示も要件になります。表示の側の点検は特定商取引法の通信販売の表示義務をClaudeで点検する方法で扱っています。
返品特約と契約不適合は別の話
消費者庁の「通信販売における返品特約の表示についてのガイドライン」は、返品特約を、商品が契約の内容に適合している場合の返品についての特約と位置づけています。商品が種類または品質に関して契約の内容に適合しない場合の販売業者の責任は、別の特約として表示するものです。ガイドラインは、両者の区別がつかない表示だと、適合している状態での返品特約だけを定めたものと解されると述べています。
規程でいえば、「気が変わった」型の返品と「不良品・違うものが届いた」型の返品を、別の章に分けておく必要があります。1つの条文に混ぜると、Claudeも担当者も同じ迷い方をします。この区別は、次に作る判断表の列にそのまま使えます。
Projectsに何を置くか
ナレッジには、次の4種類を置きます。
ナレッジに置く4つの資料
返品・返金・交換の規程
社内規程のPDFまたはテキスト。条番号が振ってあるものが向きます。
判断表
規程を「状況、条件、結論、条番号」の表に直したもの。規程の本文より、これを先に読ませます。
対応事例集
匿名化した過去の対応記録。案件ID、状況、結論、理由、担当者ID(氏名でなく記号)を1行にします。
法令メモ
特定商取引法第15条の3などを、自分の言葉で要約したテキスト。出典の条番号を付けます。
事例集には、顧客の氏名・住所・注文番号を入れません。案件IDと状況の要約だけにします。顧客の個人情報を扱う設定の確認は、Claudeで問い合わせ返信を作る手順に整理があります。
規程PDFにも注意点があります。Claudeは100ページ以下のPDFなら文字と図表の両方を解析しますが、101〜1000ページでは文字のみを処理します。規程の別表が画像の表だと、長い規程では読まれないことがあります。表はテキストで書き直したものを併せて置くのが確実です。
有料プランでは、ナレッジが上限に近づくと自動でRAGモードになり、容量が最大10倍まで広がります。事例が数千件に増えても置き続けられますが、RAGで必要な部分だけが読まれる形になるため、規程の全条文を一度に見比べる点検は、判断表のような小さな資料に分けておくほうが安定します。
プロジェクトの指示文
指示文は、プロジェクトの「Set project instructions」から保存します。保存した指示は、そのプロジェクトのすべてのチャットで使われます。返品・返金の判断では、根拠を必須にする指示が効きます。
あなたは返品・返金・交換の問い合わせを、社内規程と照らして
可否の案にする担当補助です。
- 結論は「可」「不可」「要確認」のいずれか1つで始める
- 根拠は規程の条番号で示す。該当する条文がなければ
「規程に記載なし」と書き、推測で埋めない
- 事例集に近い案件があれば、案件IDを挙げる。
なければ「近い事例なし」と書く
- 「気が変わった」型と「不良品・誤送」型を分けて判断する
- 最終判断は担当者が行う。判断に迷う点を最後に列挙する「規程に記載なし」と書かせる一行が要点です。これがないと、条文のない場面でもそれらしい根拠をつけた回答が返りやすくなります。
案件ごとに根拠条文つきの可否案を出させる
問い合わせ1件につき1チャットを使い、案件の状況を貼ります。プロジェクト内のチャットは新規に作るたびに履歴が分かれるので、案件同士が混ざりません。
次の案件の可否案を出してください。
- 購入から5日後に連絡。商品は未開封
- 注文はサイトから。特約の表示は商品ページにあり
- 顧客の希望は返品と全額返金回答の形は、例えば次のようになります。これは出力形式の例であり、実際の回答は規程と事例の内容によって変わります。
結論: 可
根拠: 返品規程第3条(未開封・到着後8日以内)
近い事例: 案件ID 0142(未開封、到着後6日、返品可)
返送費用: 規程第5条により顧客負担
要確認: 返金額に初回送料を含めるかは規程に記載なし注目するのは最後の「要確認」の行です。規程に書かれていない論点を拾えていれば、規程の穴を見つける道具としても使えています。「要確認」が続けて出る論点は、判断ぶれの温床として次の節で扱います。
事例集で担当者ごとの判断ぶれを点検する
過去の事例集を使うと、ぶれを一覧にできます。ただし、ナレッジに置いた事例集はそのプロジェクトのどのチャットからも読めるため、同じプロジェクトで再判定させても実際の結論は隠せません。再判定は、事例集を置いていない点検用のプロジェクト(ナレッジは規程・判断表・法令メモだけ)で行います。手順は次のとおりです。
判断ぶれの点検手順
- 1
事例を整える
事例集を、案件ID・状況・実際の結論・理由・担当者IDの5列にそろえます。
- 2
規程だけで再判定させる
事例集から案件IDと状況の2列だけを書き出したファイルを作り、点検用プロジェクトのチャットに添付します。規程と判断表だけで結論を出させるので、実際の結論と理由と担当者IDはそのプロジェクトのどこにも置きません。
- 3
実際の結論と照らす
Claudeの案と実際の結論が食い違った件を、表にします。
- 4
食い違いを3つに分ける
担当者の判断ぶれ、規程の曖昧さ、規程にない例外対応のどれに当たるかを、1件ずつ人が決めます。
2番目の手順で実際の結論を渡さないのは、答えに引きずられて辻褄を合わせることを避けるためです。「読まないでください」と頼むだけでは隠せないので、列そのものを渡しません。点検用プロジェクトのチャットでは、依頼文を次のようにします。
添付のファイルは、案件IDと状況の2列だけを書き出したものです。
各案件を、ナレッジの規程と判断表で再判定してください。
結果は 案件ID / 再判定の結論 / 根拠条番号 / 要確認の有無 の表にします。その後、事例集を置いた元のプロジェクトのチャットに再判定の表を添付し、実際の結論と突き合わせます。
再判定の表と事例集の「実際の結論」を比べ、食い違う案件を抜き出して
ください。食い違い方を「規程の条文が曖昧」「担当者ごとの運用差」
「規程にない例外」のどれかに仮分類し、担当者IDごとの件数も出してください。仮分類はあくまで案です。人が1件ずつ確認する前提で、担当者IDの件数は「誰が悪いか」の評価でなく、研修やマニュアルで補う論点を探すために使います。特定の担当者に偏って食い違う場合も、その担当者だけが違うのか、その担当者が難しい案件を引き受けているのかは、件数からは分かりません。
同じ手順で、近いパターンの点検を別の規程にも広げられます。例えば旅費規程の日当・宿泊費の上限で出張精算を点検する手順は、規程を表にして行ごとに当てる点で同じ型です。
規程そのものと法令の食い違いを洗う
可否案の点検が終わったら、規程自体を法令メモと突き合わせます。ナレッジに法令メモがあるチャットで、規程の条文ごとに次を確認させます。
規程の各条文を、法令メモの特定商取引法第15条の3と比べてください。
- 返品期間の起算日が「引渡しを受けた日」と合っているか
- 返送費用の負担の書き方が条文と矛盾していないか
- 特約を定める条文が、サイト表示と同じ内容か
矛盾の疑いがある条文は、条番号と理由を表にしてください。Claudeが示す食い違いの疑いは、法的な判断ではありません。疑いが出た条文は、条文の原文と消費者庁のガイドラインで確かめ、必要なら専門家に相談する流れにします。利用規約側の免責条項を同じ方法で洗う手順は、消費者契約法で利用規約の不当条項を点検する手順にまとまっています。
点検で気をつけたいこと
運用でつまずきやすい点を挙げます。
- 規程を改定したら、ナレッジの規程と判断表を差し替える。古い規程が残ると、古い条文を根拠にした案が出る
- 決まった例外対応は、事例集に1行足す。チャット内で決めただけでは次のチャットに引き継がれない
- チームで使うなら、TeamまたはEnterpriseプランでプロジェクトを共有する。「Can view」は閲覧とプロジェクト内でのチャットまでで、「Can edit」の人がナレッジや指示を編集できる。事例集を編集できる人を絞れば、事例の勝手な書き換えを避けられる
- Freeプランは作れるプロジェクトが5つまで
- 完了した点検のプロジェクトはアーカイブできる。共有設定やナレッジは保持される
個人情報の扱いは、事例集を匿名化する段階で決まります。顧客が特定できる情報を入れない運用を先に決めてから、ナレッジを作ります。
まとめ
規程と事例をProjectsに置くと、返品・返金の判断は「担当者の記憶」から「条番号で説明できる案」に移せます。効果が大きいのは、可否案そのものより、事例の再判定で見つかる規程の曖昧さのほうです。食い違いが集中する条文は、担当者の教育でなく規程の書き直しで解消できる可能性が高く、特定商取引法の条文と照らす作業も同じ判断表で済ませられます。