วิธีตรวจจับลายน้ำ Claude (และทำไมผลลัพธ์ที่ไม่มีลายน้ำถึงไม่ได้พิสูจน์อะไร)

ขณะนี้ Anthropic ได้ฝังเครื่องหมายที่เครื่องอ่านได้ในเอาต์พุตของ Claude คำถามสำคัญคือจะตรวจสอบเครื่องหมายเหล่านั้นอย่างไร คำตอบ ณ เดือนสิงหาคม 2026 คือ Anthropic ให้คำมั่นว่าจะรองรับการตรวจจับ แต่ยังไม่ได้เผยแพร่เครื่องมือสาธารณะ โดยศูนย์ช่วยเหลือระบุว่าจะมีเอกสารทางเทคนิคตามมา

ลองใช้ Apidog วันนี้

ช่องว่างนี้สำคัญ เพราะมีความต้องการเครื่องมือตรวจจับ Claude อยู่แล้ว แต่เครื่องมือที่มีในตลาดส่วนใหญ่เป็นตัวจัดประเภทจากบุคคลที่สามซึ่งใช้การคาดเดาทางสถิติ ไม่ใช่การอ่านเครื่องหมายอย่างเป็นทางการ การสับสนระหว่างสองสิ่งนี้อาจนำไปสู่การกล่าวหาผู้ใช้หรือนักเรียนอย่างผิดพลาดจากข้อความที่พวกเขาเขียนเอง

บทความนี้อธิบายความแตกต่างระหว่างเครื่องหมายทั้งสองประเภทของ Claude สิ่งที่ตรวจสอบได้จริงในวันนี้ และวิธีออกแบบ API สำหรับตรวจสอบแหล่งที่มาโดยไม่ตีความสัญญาณอ่อนเป็นคำตัดสิน หากคุณกำลังเพิ่มการตรวจสอบแหล่งที่มาลงใน API, Apidog ช่วยให้คุณเปลี่ยนการตรวจสอบเหล่านี้เป็น assertion ที่รันได้ทุกครั้งในขั้นตอน build

เครื่องหมายสองแบบ เรื่องราวการตรวจจับสองแบบ

Claude ทำเครื่องหมายเนื้อหาด้วยสองวิธี ซึ่งมีคุณสมบัติและขอบเขตการตรวจสอบต่างกันโดยสิ้นเชิง

	ลายน้ำข้อความฝังตัว	เมทาดาต้า C2PA ที่ลงนามแล้ว
คืออะไร	สัญญาณทางสถิติที่ถักทอในข้อความที่สร้างขึ้น	Manifest ที่ลงนามด้วยการเข้ารหัสและแนบมากับไฟล์
ใช้กับ	ข้อความที่สร้างขึ้นทั้งหมด	ประเภทไฟล์ที่รองรับ: .svg, .png, .jpg
รอดจากการคัดลอก-วาง	ใช่	ไม่ ไฟล์คือภาชนะของข้อมูล
รอดจากการเข้ารหัสใหม่	ใช่ เพราะข้อความยังเป็นข้อความ	ไม่ โดยทั่วไปจะถูกถอดออก
ตรวจจับได้ในวันนี้	ยังไม่มีเครื่องมือสาธารณะ มีเพียงคำมั่นว่าจะรองรับการตรวจจับ	ได้ ด้วยเครื่องมือ C2PA มาตรฐาน
บอกคุณว่า	เนื้อหาอาจถูกประมวลผลโดย Claude	ไฟล์ถูกประมวลผลโดย Claude และมีการแก้ไขหรือไม่

ลายน้ำข้อความมีความคงทนกว่า แต่ยังไม่มีตัวอ่านสาธารณะ ส่วน C2PA manifest เปราะบางกว่า เพราะอาจหายไปเมื่อไฟล์ผ่านระบบประมวลผล แต่คุณสามารถอ่านและตรวจสอบได้ทันทีด้วยเครื่องมือมาตรฐาน

สิ่งที่คุณตรวจสอบได้ในวันนี้: C2PA Manifest

หาก Claude สร้างภาพหรือ SVG และระบบปลายทางไม่ได้เขียนไบต์ของไฟล์ใหม่ C2PA manifest จะยังอยู่ในไฟล์ คุณสามารถตรวจสอบได้อย่างน้อยสามวิธี

1. ตรวจสอบในเบราว์เซอร์

ลากและวางไฟล์ลงใน หน้า Verify ของ Content Credentials

เครื่องมือจะอ่าน manifest และรายงานข้อมูล เช่น:

• ผู้ลงนาม
• การอ้างสิทธิ์ในไฟล์
• สถานะความถูกต้องของลายเซ็น

วิธีนี้เหมาะสำหรับตรวจสอบไฟล์รายไฟล์ระหว่างการดีบั๊กหรือการตรวจสอบด้วยมือ

2. ตรวจสอบจากบรรทัดคำสั่งด้วย c2patool

c2patool คือ CLI อ้างอิงจากโปรเจกต์ C2PA ใช้ตรวจสอบไฟล์ในเครื่องหรือใน CI ได้

# อ่านข้อมูลสรุปของ manifest
c2patool report.png

# แสดงรายละเอียดระดับ JUMBF แบบเต็ม เหมาะสำหรับดีบั๊ก pipeline
c2patool report.png -d

ผลลัพธ์ที่ควรแยกให้ชัดมีสามกรณี:

1. Manifest ถูกต้อง — ได้ JSON ที่อธิบายผู้สร้างการอ้างสิทธิ์ การยืนยัน และสถานะลายเซ็น
2. ไม่มี manifest — ไม่มีข้อมูลแหล่งที่มาให้ตรวจสอบ
3. Manifest เสียหายหรือไม่ผ่านการตรวจสอบ — มี manifest อยู่ แต่ไฟล์อาจถูกแก้ไขหลังการลงนาม

กรณีที่สามมีประโยชน์มาก เพราะแยก "ไม่มีแหล่งที่มา" ออกจาก "แหล่งที่มาที่ถูกทำลาย" ได้

3. ตรวจสอบจากโค้ดของคุณ

ไลบรารี c2pa ห่อหุ้มตรรกะเดียวกันสำหรับ Rust, Python, JavaScript และ C คุณจึงเรียกการตรวจสอบจาก request handler, worker หรือชุดทดสอบได้โดยตรง

ตัวอย่างแนวคิดสำหรับ service:

async function verifyProvenance(file) {
  const result = await verifyC2PA(file);

  return {
    provenance: {
      status: result.manifest ? "verified" : "absent",
      standard: "c2pa",
      signer: result.signer ?? null,
      signature_valid: result.signatureValid ?? false,
      checked_at: new Date().toISOString()
    }
  };
}

แนวทางนี้อยู่เบื้องหลังการ สร้าง AI image detector API ด้วย C2PA และ classifier: ใช้ manifest เป็นหลักฐานที่ตรวจสอบได้เมื่อมีอยู่ และใช้ classifier เป็นเพียงสัญญาณเสริมเมื่อไม่มี manifest

สิ่งที่คุณยังตรวจสอบไม่ได้ในวันนี้: ลายน้ำข้อความ

ยังไม่มีตัวอ่านสาธารณะสำหรับลายน้ำข้อความฝังตัวของ Claude

Anthropic ระบุว่าจะสนับสนุนผู้ใช้และบุคคลที่สามในการตรวจจับเครื่องหมายตามข้อกำหนดของ Code of Practice และจะเปิดเผยรายละเอียดในเอกสารทางเทคนิคในอนาคต จนกว่าจะถึงเวลานั้น ให้ถือหลักต่อไปนี้:

• ไม่มีเครื่องมือใดที่บอกได้อย่างเป็นทางการว่าข้อความใดมีลายน้ำของ Claude
• ผลิตภัณฑ์ที่อ้างว่าตรวจจับ “ข้อความที่สร้างโดย Claude” ในวันนี้กำลังใช้ classifier ไม่ได้อ่านสัญญาณอย่างเป็นทางการ
• classifier มี false positive ที่ได้รับการบันทึกไว้เป็นอย่างดี และมักผิดพลาดมากขึ้นกับนักเขียนที่ไม่ได้ใช้ภาษาอังกฤษเป็นภาษาแม่ รวมถึงงานเขียนที่เป็นทางการหรือมีโครงสร้างชัดเจน

ให้มองว่านี่คือสถานะ “ยังไม่พร้อม” ไม่ใช่ “ไม่มีวันพร้อม” เมื่อ Anthropic เปิดเผยกลไกตรวจจับ รูปแบบที่เหมาะสมคือเรียกการตรวจสอบจากฝั่งเซิร์ฟเวอร์ของคุณ แล้วส่งผลลัพธ์กลับเป็นสัญญาณ ไม่ใช่คำตัดสินเรื่องผู้เขียน

ในทางตรงกันข้าม Google เลือกแนวทางต่างออกไปสำหรับ SynthID Text โดยเปิดเผยซอร์สโค้ดพร้อมเครื่องมือตรวจจับอ้างอิง ทำให้บุคคลที่สามใช้งานได้โดยไม่ต้องขอสิทธิ์เข้าถึง นี่คือแผนการทำเครื่องหมายข้อความที่บุคคลที่สามตรวจสอบได้ในวันนี้ ความแตกต่างนี้อธิบายเพิ่มเติมใน ลายน้ำของ Claude vs ChatGPT vs Gemini

ข้อผิดพลาดในการให้เหตุผลที่ทำให้เวิร์กโฟลว์การตรวจจับล้มเหลว

ผลลัพธ์จากการตรวจจับมีลักษณะไม่สมมาตร แต่ระบบจำนวนมากกลับปฏิบัติต่อผลลัพธ์เชิงบวกและเชิงลบเหมือนมีความหมายเท่ากัน

เครื่องหมายที่ตรวจพบเป็นหลักฐานเชิงบวกที่อ่อนแอ

เครื่องหมายบอกได้เพียงว่าเนื้อหา อาจ ถูกประมวลผลโดย Claude ไม่ได้พิสูจน์ว่า Claude เป็นผู้เขียน

ตัวอย่างเช่น นักวิจัยอาจเขียนร่างงาน 3,000 คำเองทั้งหมด แล้วส่งให้ Claude ช่วยตรวจไวยากรณ์ ผลลัพธ์อาจมีเครื่องหมาย แต่แนวคิด งานวิจัย และการรายงานยังเป็นงานของมนุษย์ทั้งหมด เครื่องหมายไม่สามารถแยกกรณีนี้ออกจากพรอมป์ต์อย่าง “เขียนบทความ 3,000 คำให้ฉัน” ได้

เนื้อหายังอาจถูกแก้ไข อ้างอิง หรือรวมเข้ากับเอกสารขนาดใหญ่หลังผ่าน Claude การพบเครื่องหมายในไฟล์บอกได้เพียงว่าบางส่วนของเนื้อหาถูกประมวลผลในช่วงเวลาหนึ่ง

ไม่พบเครื่องหมาย ไม่ใช่หลักฐานว่าเนื้อหาเป็นของมนุษย์

Anthropic ระบุว่าข้อความที่ Claude สร้างขึ้นอาจไม่มีเครื่องหมายที่ตรวจจับได้ในหลายกรณี เช่น:

• มาจากโมเดลที่เผยแพร่ก่อนรองรับการทำเครื่องหมาย
• ข้อความถูกแก้ไขหรือถอดความอย่างหนัก
• ข้อความถูกแปลหรือผสมกับงานเขียนอื่น
• ข้อความสั้นเกินไปสำหรับสัญญาณที่น่าเชื่อถือ
• เมทาดาต้าของไฟล์ถูกลบจากการแปลงฟอร์แมต บันทึกใหม่ หรือภาพหน้าจอ
• เนื้อหามาจากแพลตฟอร์มหรือประเภทไฟล์ที่ไม่รองรับเครื่องหมายประเภทนั้น

กรณีเหล่านี้เป็นเรื่องปกติ ไม่ใช่ความพยายามหลีกเลี่ยงระบบ: คำตอบสั้น ย่อหน้าที่แปลแล้ว ภาพหน้าจอ และไฟล์ที่ CDN ปรับขนาด ล้วนเกิดขึ้นใน pipeline ทั่วไป

กฎที่ควรใช้คือ:

ผลลัพธ์เชิงบวกอาจช่วยจำกัดขอบเขตการตรวจสอบ แต่ผลลัพธ์เชิงลบไม่ได้ยืนยันอะไรเกี่ยวกับแหล่งที่มา

อย่าสร้างนโยบายที่ลงโทษผู้ใช้จากผลการตรวจสอบเชิงลบ เพราะผิดทั้งในเชิงเทคนิคและเชิงการออกแบบระบบ ปัญหาเดียวกันเกิดขึ้นกับภาพแล้ว ตามที่อธิบายใน ทำไมการตรวจจับภาพ AI ถึงล้มเหลว

การสร้างการตรวจจับเข้าสู่บริการอย่างเหมาะสม

เมื่อเพิ่มการตรวจสอบแหล่งที่มาลงในผลิตภัณฑ์ สิ่งสำคัญไม่ใช่แค่อัลกอริทึม แต่คือวิธีที่ API ของคุณแสดงผลจากสัญญาณที่ไม่สมบูรณ์

1. ส่งคืนสัญญาณ ไม่ใช่คำตัดสิน

หลีกเลี่ยง response แบบนี้:

{
  "ai_generated": true
}

API ของคุณมักไม่สามารถพิสูจน์ข้ออ้างนี้ได้อย่างเพียงพอ ให้ส่งคืนข้อเท็จจริงที่ตรวจสอบได้แทน:

{
  "provenance": {
    "c2pa": "verified",
    "signer": "...",
    "checked_at": "..."
  }
}

ออกแบบ schema ตามสิ่งที่ระบบสังเกตได้จริง ไม่ใช่ตามข้อสรุปที่ผู้ใช้ต้องการให้ระบบตัดสิน

2. บันทึกสิ่งที่ตรวจสอบและเวลา

ผลลัพธ์การตรวจสอบแหล่งที่มาอาจเปลี่ยนได้เมื่อ:

• เครื่องมืออัปเดต
• รายการความเชื่อถือเปลี่ยน
• ไฟล์ถูกส่งผ่าน pipeline ใหม่
• ข้อกำหนดมาตรฐานเปลี่ยน

จัดเก็บผลลัพธ์พร้อม timestamp และเวอร์ชันเครื่องมือ เช่นเดียวกับผลการสแกนไวรัส

3. แยกสถานะ absent ออกจาก invalid

อย่ายุบทุกกรณีลงเป็น boolean เดียว

• absent หมายถึงไม่พบ manifest และไม่ได้บอกอะไรเกี่ยวกับแหล่งที่มา
• invalid หมายถึงพบ manifest แต่การตรวจสอบล้มเหลว
• verified หมายถึงพบ manifest และลายเซ็นผ่านการตรวจสอบ
• unavailable หมายถึงระบบตรวจสอบทำงานไม่ได้หรือเรียกเครื่องมือไม่สำเร็จ

การแยกสถานะช่วยให้ทีม downstream ตัดสินใจได้ถูกต้อง

4. ยอมให้ผ่านเมื่อการตรวจสอบล้มเหลว ไม่ใช่ตีความเนื้อหา

หากบริการยืนยันหยุดทำงาน อย่าทำเครื่องหมายทุกไฟล์ว่า “ไม่ยืนยัน” โดยไม่มีร่องรอย

แยกให้ชัดระหว่าง:

• “ตรวจสอบแล้วและไม่พบ manifest”
• “ไม่สามารถตรวจสอบได้”

ตัวอย่าง response ขั้นต่ำที่ใช้งานได้:

{
  "asset_id": "img_9f2c41",
  "provenance": {
    "status": "verified",
    "standard": "c2pa",
    "signer": "Anthropic",
    "signature_valid": true,
    "checked_at": "2026-08-11T09:14:22Z",
    "tool": "c2patool/0.9"
  },
  "notes": "Provenance indicates the file was processed by Claude. It does not establish authorship."
}

ฟิลด์ notes ไม่ใช่เพียงข้อความตกแต่ง หาก API ส่งข้อมูลแหล่งที่มาให้ทีมอื่น คำเตือนต้องอยู่ใน response ที่โค้ดของพวกเขาอ่านได้ ไม่ใช่ซ่อนอยู่ในเอกสารที่ไม่มีใครเปิด

การทดสอบการตรวจสอบเพื่อให้มั่นใจว่ายังทำงานได้

การตรวจสอบแหล่งที่มาเป็นฟีเจอร์ที่มักเสียหายอย่างเงียบ ๆ ตัวอย่างเช่น มีคนเพิ่มขั้นตอนปรับขนาดรูปภาพ แล้ว manifest ถูกลบออก ทุกไฟล์จึงเริ่มตอบกลับด้วย status: "absent" โดยไม่มี error และ dashboard อาจยังดูปกติ

เพิ่มอย่างน้อยสี่กรณีต่อไปนี้ในชุดทดสอบ

1. ไฟล์ที่มี manifest ถูกต้อง
   
   อัปโหลดไฟล์ fixture ที่มี manifest ถูกต้อง แล้วตรวจสอบว่า status เป็น verified และ signature_valid เป็น true

2. ไฟล์ที่ถูกตัดเมทาดาต้าออก
   
   อัปโหลดไฟล์เดียวกันหลังลบเมทาดาต้า ตรวจสอบว่า status เป็น absent ไม่ใช่ error และไม่ใช่ verified

3. ไฟล์ที่ถูกแก้ไขหลังการลงนาม
   
   แก้ไขไบต์ในไฟล์ที่ลงนามแล้ว ตรวจสอบว่า response รายงานสถานะเสียหาย และแยกออกจากกรณีไม่มี manifest

4. ไฟล์ยังรักษา manifest หลังผ่าน delivery pipeline
   
   อัปโหลดไฟล์ที่ลงนามแล้ว ดาวน์โหลดกลับผ่านเส้นทางปกติของคุณ และตรวจสอบว่า manifest ยังผ่านการยืนยัน กรณีนี้ช่วยจับ regression จาก CDN หรือระบบปรับขนาดรูปภาพ ซึ่งอธิบายไว้ใน API ของคุณกำลังลบเมทาดาต้า C2PA

ตัวอย่างแนวคิดของ assertion:

pm.test("C2PA manifest must be verified", () => {
  const body = pm.response.json();

  pm.expect(body.provenance.status).to.eql("verified");
  pm.expect(body.provenance.signature_valid).to.eql(true);
  pm.expect(body.provenance.standard).to.eql("c2pa");
});

ใน Apidog คุณสามารถเก็บทั้งสี่กรณีเป็น test scenario พร้อม binary fixture ยืนยัน JSON response ด้วย การยืนยันมาตรฐาน และรัน scenario ผ่าน apidog-cli ใน CI เพื่อให้การเปลี่ยนแปลง pipeline ที่ลบ manifest ทำให้ build ล้มเหลว

การเชื่อมชุดทดสอบนี้เข้ากับ CI ใช้แนวทางเดียวกับการ ทำงานอัตโนมัติของการทดสอบ API ใน GitHub Actions คุณสามารถดาวน์โหลด Apidog เพื่อสร้างและรันทดสอบกับ endpoint ของคุณเอง

คำถามที่พบบ่อย

• มีเครื่องมือตรวจจับลายน้ำ Claude อย่างเป็นทางการหรือไม่?
  
  ไม่มีเครื่องมือที่เปิดเผยต่อสาธารณะ ณ เดือนสิงหาคม 2026 Anthropic ให้คำมั่นว่าจะสนับสนุนการตรวจจับสำหรับผู้ใช้และบุคคลที่สาม และระบุว่าจะแชร์รายละเอียดในเอกสารทางเทคนิคที่กำลังจะออกมา

• ฉันสามารถใช้เครื่องมือตรวจจับข้อความ AI เพื่อค้นหาลายน้ำของ Claude ได้หรือไม่?
  
  ไม่ได้ เครื่องมือเหล่านั้นเป็น classifier ทางสถิติที่คาดเดาว่าข้อความดูเหมือนเขียนโดยเครื่องจักรหรือไม่ ไม่ได้อ่านเครื่องหมายของ Anthropic และมี false positive โดยเฉพาะกับนักเขียนที่ไม่ใช่เจ้าของภาษาอังกฤษ รวมถึงงานเขียนที่เป็นทางการหรือมีรูปแบบชัดเจน

• ฉันจะตรวจสอบไฟล์สำหรับเมทาดาต้า C2PA ของ Claude ได้อย่างไร?
  
  รัน c2patool <file> ในเครื่อง หรือลากไฟล์ไปที่หน้า Verify ของ Content Credentials ทั้งสองวิธีจะแสดงผู้ลงนามและสถานะของลายเซ็น

• ถ้าไฟล์ไม่มี C2PA manifest แสดงว่าเป็นงานของมนุษย์หรือไม่?
  
  ไม่ใช่ Manifest มักหายไปจากการปรับขนาด การเข้ารหัสใหม่ การแปลงฟอร์แมต ภาพหน้าจอ และ image CDN การไม่มี manifest ไม่ได้พิสูจน์แหล่งที่มา

• ลายน้ำข้อความรอดจากการแก้ไขหรือไม่?
  
  รอดได้บางส่วน ลายน้ำอาจติดไปกับการคัดลอกและวาง และคงอยู่ผ่านการแก้ไขบางรูปแบบ แต่การถอดความ การแปล หรือการย่อให้สั้นมากอาจทำให้สัญญาณต่ำกว่าระดับตรวจจับ ดูรายละเอียดเพิ่มเติมได้ใน ลายน้ำของ Claude รอดจากการคัดลอก วาง และแก้ไขหรือไม่

• ฉันควรทำอะไรจนกว่าการตรวจจับข้อความจะเปิดตัว?
  
  ตรวจสอบ C2PA สำหรับไฟล์ที่เกี่ยวข้อง บันทึกผลและเวลาที่ตรวจสอบ หลีกเลี่ยงนโยบายที่พึ่งพาการตรวจจับข้อความ และออกแบบ response schema ไว้ล่วงหน้าเพื่อเพิ่มการตรวจสอบข้อความอย่างเป็นทางการในอนาคตโดยไม่ต้องเปลี่ยน API contract

ประเด็นสำคัญ

วันนี้คุณตรวจสอบแหล่งที่มาของไฟล์ Claude ได้ด้วยเครื่องมือ C2PA มาตรฐาน แต่ยังตรวจสอบลายน้ำข้อความของ Claude ไม่ได้

สิ่งที่ควรสร้างในตอนนี้คือ:

• การตรวจสอบไฟล์ด้วย C2PA
• response ที่รายงานสัญญาณและสถานะจริง
• การแยก verified, absent, invalid และ unavailable
• ชุดทดสอบที่ป้องกัน pipeline ลบ manifest โดยไม่รู้ตัว
• นโยบายที่ไม่ตีความผลลบว่าเป็นหลักฐานว่าเนื้อหาเป็นของมนุษย์

เครื่องหมายเป็นเพียงเบาะแสว่าเนื้อหาอาจผ่านกระบวนการใดมา ไม่ใช่การพิสูจน์ความเป็นผู้แต่ง