漫画の出版社が読者から届く二次創作・ファンアートの利用の問い合わせを、Claude で作品ごとのガイドラインに照らし、返信の下書きを作る

処理の起点を決める

問い合わせが届くたびに、1件ずつ処理します。 下書きが届いた直後にできていれば、担当者は手の空いたときに確認して返せます。

問い合わせの多い時期には、作品ごとにまとめて処理する並びにします。 15分ごとに届いた分を作品で並べ替えてから処理すると、同じガイドラインが続き、キャッシュから読まれる部分が増えます。

ガイドラインの版が変わった日は、その作品の未返信の問い合わせをすべて作り直します。 古い版で作った下書きを新しい版の日に返すと、改めた条項と違う案内を出すことになります。

入力データを集める

質を決めるのは、問い合わせフォームの項目です。 自由記述だけのフォームでは、「グッズを作りたい」に何も書き添えられません。頒布の場所（即売会・通販・知人に配る）、価格、部数、公式の素材（ロゴ・画像）を使うかを選ぶ欄を足すと、当てはめに要る情報の多くがそろいます。

過去の判断の例は、要旨だけを渡します。 「学校の文化祭での展示：非営利・入場無料のため可（2026年3月、編集部確認）」のような1行です。ただし、例をガイドラインの代わりにはさせません。 例と同じ利用でも、版が変わっていればガイドラインが優先します。

データの取得方法を決める

作品の特定は、完全一致から順に照らします。 正式名、略称、愛称の順に照らし、どれにも当たらない、または2つ以上の作品に当たる場合は処理を止めます。 似た名前の作品で、条項が逆の例があるからです。

ガイドラインは、施行日が今日以前の最新の版を取ります。 改定を予告している版を先に使わないためです。

AIへ渡す前に整形する

1. 個人の情報を外す … 問い合わせの文にある氏名、ペンネーム、SNSのアカウント名、メールアドレス、学校名を記号に置き換えます
2. 年齢の手がかりを分ける … 「中学生です」「高校の部活で」といった記述は、外さずに「未成年の可能性あり」の印として別の欄にします
3. フォームの選択項目を文にする … 頒布の場所・価格・部数・公式の素材の有無を、「頒布の場所：即売会」のように並べます
4. URLを外す … 作品の画像や下描きのURLは渡しません。担当者が確認の画面で開きます
5. ガイドラインに条項の番号を振る … 共通の条項は「C-1」、作品で足した条項は「W-1」のように振り、引用の照合に使います

2番目で印を残すのは、返信の書き方に関わるからです。 未成年の可能性がある問い合わせには、頒布や販売に保護者の同意が要ることを添えるかなど、返信の型を変える場合があります。 年齢をAIに推し量らせることはせず、問い合わせの文にある記述だけを印にします。

4番目でURLを渡さないのは、作品の中身の評価をAIにさせないためです。 二次創作の中身が作者の意向に沿うかは、ガイドラインの文面だけでは決まらないことが多く、担当者と編集部が見るものです。

AIに処理させる

させるのは、問い合わせを条項に当てはめて、4つの区分のどれかを選ぶことです。

判定の前に、利用の形を項目に分けて取り出させます。 何を（ファンアート・同人誌・グッズ・動画・その他）、どこで（SNS・即売会・通販・店舗・学校）、有償か無償か、公式の素材を使うか、商用か、の5つです。取り出した項目のどれかが「不明」なら、区分は insufficient_info にします。

1行目がいちばん起きやすい失敗です。 「結婚式のウェルカムボードにキャラクターを描きたい」は、多くのガイドラインに条項がありません。非営利で個人的な利用に見えるので、AIは「問題ないと思われます」と書きがちです。 それを返せば、会社がその場で許諾したと読まれます。条項が無いものは、必ず needs_review にします。

指示内容を固定する

あなたは漫画の出版社のライツ部の読者窓口を補助します。
読者からの問い合わせを、渡された作品のガイドラインの条項だけに照らして判定します。

【手順】
1. 問い合わせから利用の形を5項目で取り出してください。
   what（ファンアート／同人誌／グッズ／動画／その他）、where、paid（有償／無償／不明）、
   official_assets（使う／使わない／不明）、commercial（はい／いいえ／不明）
   問い合わせに書かれていない項目は「不明」とし、推測で埋めないでください。
2. 利用の形に当たる条項を、ガイドラインから選んでください。
3. 区分を1つ選んでください。
   - within_guideline：当たる条項がその利用を認めている
   - not_allowed：当たる条項がその利用を認めていない
   - needs_review：当たる条項が無い、または条項の読み方が分かれる
   - insufficient_info：判定に要る項目が「不明」
4. 返信の下書きを、返信の型に沿って書いてください。

【厳守事項】
- 根拠にした条項は、条項の番号と、条項の本文をそのまま一字一句写して quote に入れてください。
  要約や言い換えを quote に入れないでください。
- 当たる条項が無い利用を「問題ない」「可能と思われます」としないでください。必ず needs_review です。
- 著作権の侵害に当たるか、引用に当たるかについて書かないでください。
- 作品の表現の中身や作者の意向について推測しないでください。
- 過去の判断の例は参考にとどめ、ガイドラインと食い違う場合はガイドラインに従ってください。
  例を根拠に区分を決めた場合は needs_review にしてください。
- 返信の下書きでは、ガイドラインの範囲を超えて利用を認める書き方をしないでください。
  「ガイドラインの範囲でお楽しみください」のように、条項の範囲に限って案内してください。
- insufficient_info の場合は、足りない項目だけを聞き返す文にしてください。
- 未成年の可能性の印がある場合は、その旨を staff_notes に書いてください。返信の型は担当者が選びます。

【返信の型】{reply_templates}
【作品のガイドライン（版・施行日・条項）】{guideline}
【過去の判断の例】{precedents}
【問い合わせ】{inquiry}

「一字一句写す」を明記するのは、照合のためです。 要約を quote に入れられると、プログラムはガイドラインの本文と照らせません。写せない条項を根拠にしていれば、それは当てはめが怪しいという合図です。

「例を根拠にしたら needs_review」も、意図して入れています。 過去の例は便利ですが、例に頼った判定は、ガイドラインの文面からは説明できない判定です。 担当者が見るべきものに回します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "inquiry_id": "Q-2026-10-0217",
  "work_id": "W-031",
  "guideline_version": "2026-04-01",
  "usage": {
    "what": "グッズ",
    "where": "即売会",
    "paid": "有償",
    "official_assets": "使わない",
    "commercial": "いいえ"
  },
  "category": "within_guideline | not_allowed | needs_review | insufficient_info",
  "grounds": [
    { "clause": "C-6", "quote": "", "applies_because": "" }
  ],
  "missing_info": [],
  "reply_draft": "",
  "staff_notes": []
}

1つ目の理由は、grounds の quote をプログラムで照らせることです。 条項の番号の本文と quote を、空白と改行をそろえてから完全一致で比べます。一致しない引用が1つでもあれば、下書きに赤の印を付けます。

2つ目は、区分と返信の型の対応を確かめられることです。 within_guideline なのに返信の下書きに「個別に確認いたします」とある、needs_review なのに「問題ございません」とある、といった食い違いをプログラムが拾います。

3行目は、根拠の無い可否を止めるためです。 可か不可かを言うなら、必ず条項が要ります。条項を挙げられない可否は、needs_review に直します。

よくある3つの問い合わせが、どう分かれるかを例で示します。

2行目の缶バッジのように、短い問い合わせほど聞き返しになります。 フォームの選択項目を足すと、この行が減ります。

システムへ連携する

返信の送信は、問い合わせの管理の仕組みから担当者が行います。 下書きを書き込む欄と、送信の操作を分けておき、承認の操作が無ければ送れないようにします。

ガイドラインの表は、Webで公開している本文と同じ内容にします。 表を更新したら、公開しているページと1字ずつ照らします。読者が読むガイドラインと、AIに渡すガイドラインが食い違えば、返信が読者の手元の条項と合わなくなります。

人が確認する

担当者は、300件すべての返信を確認して送ります。

1. 赤の印を先に見る … 引用が一致しない、条項が存在しない、根拠の無い可否。条項を読み直し、区分を直します
2. needs_review を分ける … 担当者の判断で返せるもの（過去に同じ結論の例があり、版も変わっていないもの）と、編集部・作者の窓口に相談するものに分けます
3. not_allowed の返信を読む … 断る返信は読者の受け止めが重いので、代わりにできること（ガイドラインの範囲の利用）を添えるかを決めます
4. 未成年の印のあるものの返信の型を選ぶ … 保護者の同意に触れるかを決めます
5. within_guideline の返信を読んで送る … 引用の条項と問い合わせの内容が合っているかを見ます

3番目は、AIに任せません。 ファン活動は作品の応援で、断るときの言葉が作品と会社の印象になります。下書きの言い回しを担当者が自分の言葉に直す時間を、ここに取ります。

目標は、300件をならして1件5分です。 within_guideline と insufficient_info の多くは2〜3分で送れ、needs_review と not_allowed に時間を使います。needs_review が全体の3割を超える月は、ガイドラインに足すべき条項があるという合図です。

例外に対処する

5行目を分けるのは、扱う部署が違うからです。 「この同人誌は公式の画像をそのまま使っている」という通報は、利用の問い合わせではなく、権利の侵害への対応の入口です。 返信の下書きを作る流れに乗せると、通報者に「ガイドラインの範囲でお楽しみください」と返すことになります。

構造化出力の公式の案内では、拒否のときや max_tokens で切れたときに、出力がスキーマに合わないことがあるとされています。成人向けの表現を含む二次創作についての問い合わせなどで拒否が起きうるので、拒否は失敗ではなく、担当者が読む合図として扱います。

記録を残す

• 問い合わせの本文（個人の情報を外したもの）と、作品の特定の結果
• 使ったガイドラインの版と、渡した条項の一覧
• Claude API の応答の全文と、指示文の版
• 照合の結果（引用の一致、区分と返信の対応）
• 担当者が直した区分と返信の差分
• needs_review の相談の相手と結論、その結論を過去の判断の例に足したか
• 送った返信の本文と日時

4つ目と5つ目は、同じ問い合わせへの答えを後から説明するためです。 読者が「前はよいと言われた」と書いてきたとき、そのときの版と条項と返信をたどれます。

6つ目は、ガイドラインを育てる材料です。 同じ種類の needs_review が毎月続くなら、その利用はガイドラインに条項として足すべきです。足すかどうかは、作者と編集部が決めます。