01
Problem
自然な文章でも、業務として正しいとは限りません。
LLMは、会話としては自然でも、 本来は行うべきでない判断や案内をしたり、 すでに完了した確認を繰り返したりすることがあります。
Re:me LLM Responsibility Design
自然に答えている。
でも、業務としては間違っている。
LLMのpromptを「文章」ではなく 「業務責務」として診断・再設計・検証します。
問題を見つけて終わりではありません。
合意したVerification Planの範囲で
PASSしたpromptを納品します。
What Re:me does
出力文だけを直すのではなく、
「そのAIが何をする責務を持っているか」まで戻って見直します。
02
Approach
promptを「文章」ではなく「業務責務」として見直します。
Re:meでは、responsibility、state、condition、boundaryを確認し、 どの責務が、どの条件で、どこまで実行されるべきかを整理します。 そのうえでpromptを再設計します。
03
Value
問題点の指摘だけで終わりません。
再設計したpromptを実際のLLMで検証し、 合意したVerification Planの範囲でPASSした Redesigned Promptを最終成果物として提示します。
だから、「何が問題だったか」「何を変えたか」 「どこまで検証したか」を説明できます。
受入れ、顧客説明、次回のprompt変更時にも、 判断材料が残ります。
Evidence
「良くなった気がする」ではなく、
BEFORE / AFTERを同じscenarioで確認します。
Re:meでは、再設計前後のpromptを実際のLLMで確認し、 PASS / FAIL / INDETERMINATEを分けて記録します。 以下は、実際に保存されているbefore / after evidenceの一例です。
BEFORE
FAIL
すでに分かっている注文番号を、もう一度聞いてしまう。
会話上すでに保持されている注文番号があるにもかかわらず、 LLMが再度注文番号を要求しました。
Observed problem:
already-known order identifier was requested again
AFTER
PASS
既知の注文番号を保持し、不要な再確認を行わない。
prompt再設計後は、既知の注文状態が維持され、 重複した注文番号の要求が抑制されました。
Observed result:
known-order state preserved and redundant order-id request suppressed
- Comparison
- SAME_SCENARIO_BEFORE_AFTER_LIVE_LLM
- Evidence class
- CLEAN_MECHANICAL_BEFORE_AFTER_IMPROVEMENT
- Mechanical formal result
- PASS
この比較について
同一scenarioのBEFORE / AFTERをlive LLMで比較した個別検証例です。 この1例をもって全案件・全prompt・全modelでの成功率を意味するものではありません。
同じ構造で記録されている他の検証例
| Evidence | Raw Evidence | Source | Responsibility theme | BEFORE | AFTER |
|---|---|---|---|---|---|
| PE-026 | RE-PE026-001 | RG-04 | purchase_date_confirmation | FAIL | PASS |
| PE-028 | RE-PE028-001 | RG-10 | refund_reason_not_mandatory | FAIL | PASS |
3件の読み方
PE-026 / PE-027 / PE-028は、それぞれ独立したindividual evidence recordです。 成功率の母数ではなく、この3件から改善率・成功率は算出していません。
Measurement boundary
判定が一意に確定しない記録も、同じ体系に残します
PE-029では、preregistration側の条件そのものに矛盾があったため、 mechanical formal statusはINDETERMINATEです。 PASS / FAILとしては確定しません。 一方、human adjudicationではGENUINE_IMPROVEMENTが記録されています。 この2つは別channelとして保持し、統合しません。 PE-026 / PE-027 / PE-028と同じclean mechanical improvementには含めません。
詳細はTechnical Evidence Summaryでご確認いただけます。
Formal Verdict
PASS / FAIL / INDETERMINATEを分けて記録します
合意したVerification Planの範囲でmaterial failureが観測されず、 required Human Reviewを通過した状態。
有効なrunでmaterial failureが1件以上観測された状態。
business truth・evidence・valid run・preregistration / measurement条件等の理由により、 安全にPASS / FAILを確定できない状態。
- material failureは、平均値や他ケースの成功で相殺しません。
- INDETERMINATEを、見た目上PASSへ変換しません。
- PASSはfailure-free guaranteeでもdeterministic guaranteeでもありません。
Negative / Null Results
FAILも、INDETERMINATEも隠しません
支持された結果だけをEvidenceとして残すことはしません。 支持されなかった仮説、FAIL、INDETERMINATE、解釈の訂正履歴も 同じEvidence体系に保持しています。 「成功した例だけを切り出しているのではないか」という疑いに、 記録そのもので答えるためです。
支持されなかった仮説の観測値・統計量・claim boundaryは、 Evidence Brief / Technical Evidence Summaryで確認できます。
Research Observations
before / after事例だけでなく、観測の土台があります
研究では、責務stateの表現条件、判断readoutと顧客向け発話のズレ、 表現構造と順序の組合せによる挙動差などを観測しています。 支持された結果だけでなく、null resultやINDETERMINATEも 同じEvidence体系に保持しています。
詳細な数値・実験条件・claim boundaryは、 Evidence Brief / Technical Evidence Summaryで確認できます。
これらの研究Evidenceは、特記しない限りCustomer Supportを模したsynthetic fixture上で、 単一のLLMを対象に得られたものです。顧客の本番環境で観測された発生率ではありません。
Traceability
Sales Claim
→
Reference Pack
→
Primary Evidence
→
Raw Evidence
Reference Pack実験条件・解釈・claim boundary
Primary Evidence Sheet観測値・分母・rate・formal verdict
Raw Evidence Appendix実fixture / 実output / 実adjudication
表の説明だけを信じていただく必要はありません。 必要な場合は、観測値、実際のinput / output、adjudicationまで遡って確認できます。 上記のBEFORE / AFTER記録は、Reference Pack Page 47–48 → PE-026〜PE-029 → RE-PE026-001〜RE-PE029-001として保持しています。
Downloadable Evidence
Evidence Brief
PDFBEFORE / AFTER検証、PASS / FAIL / INDETERMINATE、 主要な研究Evidenceとclaim boundaryを短くまとめた資料です。
Evidence BriefをダウンロードTechnical Evidence Summary
PDF主要experimentの条件、formal verdict、measurement boundary、traceabilityを technical reviewer向けに整理した資料です。
Technical Summaryを見るどちらもフォーム登録やメールアドレスの入力なしで、そのままダウンロードいただけます。
Service
問題を見つけて終わりではなく、
PASSしたpromptまで仕上げます。
対象promptや開発フェーズに応じて、 診断・責務分析・再設計・live LLM Verificationを行います。 full redesign + verification scopeでは、 合意したVerification Planの範囲でPASSした Redesigned Promptを最終成果物として提示します。
01
Small Audit / Review
まず問題の所在を確認したい場合に。
限定されたpromptやscenarioを対象に、 責務上の問題、state、condition、boundary、 realization上の不整合を確認します。
診断中心のscopeのため、Verification verdictや PASSしたRedesigned Promptは原則として含みません。
参考価格例
6〜8万円前後
02
Standard Responsibility Review
診断から再設計・Verificationまで。
責務分析、修正方針設計、prompt redesign、 live LLM Verificationを行い、 scope内で必要なrepair loopを実施します。
参考価格例
15〜20万円前後
03
Release / Change Review
リリース前やprompt変更時の確認に。
開発中のprompt、 結合・総合テスト前、 受入れ前、 リリース前、 変更後のpromptを対象にreviewできます。
対象・scopeに応じて
個別見積り
Deliverables
最終的に残るのは、promptだけではありません。
01
Diagnosis Summary
02
Responsibility Map
03
Intended Changes
04
Redesigned Prompt
05
Verification Results
06
Correction History
07
Known Limitations
「何が問題だったか」 「何を変えたか」 「何を検証したか」 「どこまで確認できたか」 を後から追える形で残します。
価格について
上記は参考価格例です。 対象promptの複雑さ、Responsibility Discoveryの必要性、 Verification scope、review負荷等により個別にお見積りします。 固定package価格ではありません。
About
誰が設計し、誰が判定するのかを明確にします。
Re:me LLM Responsibility Designでは、 LLMを分析や整理の補助に利用します。 ただし、責務設計、変更方針、materiality、 最終的なprofessional judgmentは 提供者本人が担当します。
Re:me LLM Responsibility Design 開発者
吉江 勇介
LLMのpromptを業務責務として捉え、 責務の状態・条件・境界・実現方法を整理し、 redesignとlive LLM Verificationまで行う Responsibility Designを開発・提供しています。
Responsibility
- Responsibility Design
- Change Policy
- Materiality Judgment
- Verification Verdict
- Final Professional Judgment
契約主体について
契約・請求・NDAの主体は吉江勇介（個人事業主）です。 Re:meはサービスブランド／屋号として使用しています。
Contact
現在開発中のpromptでも、
レビューできます。
結合・総合テスト前、受入れ前、リリース前、 prompt変更時など、 対象となるpromptがあればご相談いただけます。
yoshie@reme-ai.jp
Re:me LLM Responsibility Design
吉江 勇介