制作物に使った画像・フォント・音源のライセンス条件を、公開前に根拠付きで確かめる

処理の起点を決める

公開予定日の10営業日前に動かします。 入稿票の公開予定日を毎日見て、10営業日前にあたる制作物を拾います。加えて、状態が「校了」に変わったときにも動かします。 校了で素材が確定するためです。

素材が入るたびに動かす設計にはしません。 制作の途中では素材が入れ替わります。点検の単位は素材ではなく、制作物です。 同じ写真でも、Web広告に使うのとカタログに3万部刷るのとでは見る条文が変わります。1回の起動で1つの制作物を処理し、素材の行ごとに繰り返します。

処理が終わった制作物は、台帳の点検状態を「済」にします。変えるのは最後まで成功したときだけです。

入力データを集める

質を決めるのは、上の2つです。 購入区分が空なら条文が絞れず、使い方の6項目が空なら条文と並べる相手がいません。どちらもAIの精度ではなく、記録の有無の問題です。

使い方の情報は、素材側からは取れません。 写真そのものに「何部刷るか」は書かれていないからです。この6項目は制作物の側にしかなく、入稿票から取るしかありません。 「入れた人」を持つのは、どの外注先との取り決めを先に直すべきかを数字で見るためです。

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

ライセンス文書は、提供元ごとに1つの塊としては載せません。条・項の単位に分けて索引に入れます。 引用して返す単位が条文だからです。規約全体を1件として載せると返るのも規約全体になり、担当者が結局その中から該当箇所を探すことになります。 それでは第4章の①が減りません。仕様の面でも同じで、要約モデルは1件あたり最大2,000トークンを受け取るため、長すぎる文字列はトリミングされます。

索引に持たせるのは、条文の本文のほか、提供元、文書の名前、版、発効日、条・項の番号、購入区分です。 版と発効日を持たせるのは、規約が改定されるためです。 取得日より後の版しか無ければ、今の版で判断せず、そう書いて人に回します。

検索の語は3つを組み合わせます。 提供元の名前、購入区分の呼び名、使い方の言葉です。使い方の言葉は入稿票の6項目からそのまま作り、「印刷物 30000部 6か月 国内 改変なし」のような文字列にします。業務の言い回しのままでよいのは、ベクトル検索の側が拾うからです。 「商用利用」「業として」「営利目的」のような言い換えはシノニムマップに持たせます。インデックスのフィールドに関連付け、セマンティックランカーの構成に含めると、再ランク処理中に自動的に適用されるとされています。

AIへ渡す前に整形する

1. 台帳の行の検査 … 提供元と購入区分が入っているかを見ます。空なら検索を始めず、no_record として人へ回します
2. 使い方の6項目の検査 … 空の項目を記録します。その項目について within を出さないようにするためです
3. 提供元名の正規化 … 対応表を引き、表記ゆれを索引側の表記にそろえます
4. 文書の版の選択 … 取得日以前に発効した最新の版を選びます。無ければその旨を持ったまま次へ進みます
5. 検索語の組み立て … 提供元、購入区分、使い方の言葉を1つの文字列にします
6. 候補の切り落とし … 再ランクのスコアで並べ、下位を落とします。ただししきい値は細かくしすぎません
7. 生成AIの出力の切り分け … 素材の種類が「生成AIの出力」の行は、別の区分として分けます

6番目には注意書きがあります。 @search.rerankerScore の分布は条件やランク付けモデルの更新によって変動しうるため、しきい値を細かくしすぎないよう述べられています。「2.8未満を捨てる」のような線引きは、ある日から結果が変わります。 7番目は生成AIで作った素材を他と混ぜないためで、自動で結論を出さず必ず人に回します。

AIに処理させる

させるのは3つです。該当する条文を選び、その原文を引用し、条文の条件と使い方を並べて確認が要る点を挙げることです。

右端の列が、この構成の要です。 check は「条文はあるが決められない」、not_found は「関係する条文が候補に無い」で、前者は人が読んで決めるもの、後者は索引の側を疑うものです。混ぜると、探せていないだけの素材が「問題なし」に紛れます。

2行目がいちばん起きやすい失敗です。 条文が取れなかったときに規約に普通ありそうな内容を1行作って返し、担当者にはそれが引用に見えます。 引用を機能として組むのは、ここを防ぐためです。

指示内容を固定する

あなたは、制作物に使った素材のライセンス条文を探す担当です。
法的な結論を出す立場ではありません。出すのは該当する条文と、
人が確かめるべき点までです。

【この素材】提供元：{source_name}／購入区分：{purchase_tier}／取得日：{acquired_on}
種類：{asset_type}（画像／書体／音源／イラスト／地図／生成AIの出力）

【使い方】媒体：{media}／部数・再生数：{print_run}／掲載期間：{period}
地域：{region}／改変：{modified}／二次配布：{redistribution}

【条文の候補】{clause_candidates}
（各候補に、文書の名前、版、発効日、条・項の番号が付いています）

【やること】
1. 候補のうち、上の使い方に関係する条文だけを選ぶ。
2. 選んだ条文を原文のまま引用する。要約も言い換えもしない。
3. その条文が何を定めているかを、条件として1行で書く。
4. その条件と上の使い方を並べ、次のどれかを付ける。
   within .... 条文の条件と使い方が食い違っていない
   check ..... 条文はあるが情報が足りない、または条文だけでは決められない
   not_found . 候補の中に、この使い方に関係する条文が無い
5. 人が確かめるべき点を、確認事項として箇条書きで書く。

【厳守事項】
- 候補の中に無い条文を書かないでください。それらしい条文を作らないでください。
  見つからなければ not_found とし、何を探したかを書いてください。
- 「使ってよい」「使ってはいけない」と書かないでください。適法か違法かも、
  規約が有効かどうかも書かないでください。判断するのは知財・法務です。
- 引用は原文のままにし、読みやすく直さないでください。条・項の番号と版は、
  候補に付いているものをそのまま写してください。
- 使い方の6項目に空欄があるときは、その項目について within を選ばず、
  check にして足りない項目の名前を確認事項に書いてください。
- 素材の種類が「生成AIの出力」のとき、および取得日より後に発効した版の
  条文しか候補に無いときは、必ず check にしてください。
- 迷ったときに within を選ばないでください。

「候補の中に無い条文を書かない」を最初に置いています。 これを書かないと、候補が薄いときほど規約に普通ありそうな文を作って埋め、しかも、それらしく書かれます。 禁じるのは、候補の外から持ってくることそのものです。

「迷ったときに within を選ばない」を最後に置いているのも意図があります。 4つの区分のうち within だけが人の目を通らずに進むからです。迷いの寄せ先を check にしないと、判断がつかなかったものが黙って公開に進みます。

出力形式を固定する

呼び出しを2回に分けます。引用と構造化出力を同時に使えないためです。 公開ドキュメントは、引用を有効にしたドキュメントと output_config.format を同時に指定すると、APIは400エラーを返すと明記しています。

1回目は、引用を有効にして条文を選ばせます。 各ドキュメントに citations.enabled=true を設定します（要求内のすべてで有効か、すべてで無効かのどちらかです）。条文はカスタムコンテンツとして渡します。平文とPDFは文の単位に自動で分割されますが、カスタムコンテンツは追加の分割をしないためです。条・項で意味が閉じた条文を文で割られると、引用が半分になります。返る cited_text は出力トークンに数えられません。

2回目は、構造化出力で形を整えます。 output_config.format の type に json_schema を指定し、オブジェクトでは additionalProperties を false にします。enum が使えるので、 区分を4つに固定できます。

{
  "creative_id": "", "asset_id": "", "source_name": "", "purchase_tier": "",
  "asset_type": "image | font | audio | illustration | map | ai_output",
  "usage": { "media": [""], "print_run": 0, "period": "", "region": "",
             "modified": false, "redistribution": false },
  "clauses": [
    { "topic": "commercial | media_region | print_run | period | credit | modification | ai_training",
      "document_title": "", "doc_version": "", "clause_ref": "",
      "cited_text": "", "condition": "", "verdict": "within | check | not_found" }
  ],
  "open_points": [""],
  "overall": "within | check | not_found | no_record"
}

clauses の verdict はAIが付け、overall はワークフローが規則で決めます。 層を分けておくと、方針が変わったときに直すのは規則だけで済みます。規則は単純で、記録が無いか購入区分が空なら no_record、not_found が1つでもあれば not_found、check があれば check（ai_output は常にここ）、すべて within で6項目に空が無いときだけ within です。

なお、数値や文字列の長さの制約（minimum、maxLength など）はサポートされていません。 print_run に上限を持たせられないため、部数の比較はワークフロー側で行います。

システムへ連携する

公開を管理するシステムへは書き込みません。 点検の結果で公開を自動で止めたり通したりすると、条文が見つからなかっただけの素材で公開が止まり、逆に探せていないものが黙って通ります。 公開の可否は人が決め、提供元への問い合わせも文面の下書きまでにします。

素材台帳への書き戻しは、点検の記録だけです。 素材の行そのものは書き換えません。購入区分が空だったときに、AIが推定した区分で埋めないということです。

人が確認する

人が開くのは check ／ not_found ／ no_record のものだけです。 within のものは一覧で流し見ます。全件を開く設計では、第10章の7.5時間に収まりません。

1. no_record を先に見る … 外注先が入れたものが大半で、外注先へ一覧を求めるか制作担当に聞きます
2. not_found を次に見る … 索引に載っていないのか、探し方が合っていないのかを分けます
3. check の条文を読む … 引用された原文を読み、使い方と並べて判断します。ここが知財・法務の本来の仕事です
4. 生成AIの出力を確かめる … 提供元とプランを確かめ、出力の扱いを個別に見ます
5. 区分を覆したら記録する … どの素材の、どの条文を、どちらに変えたかを残します

3番目の時間を削らないでください。 狙いは判断を速くすることではなく、判断の前の探す時間を無くすことです。目標は150件をならして1件3分、開くのは2割5分前後という想定で、それより多い月は台帳の記録か索引の範囲が足りていません。

例外に対処する

n8n では、ワークフローごとに Workflow Settings でエラーワークフローを設定できます。 エラートリガーノードから始めるワークフローで、失敗したワークフローとエラーの詳細（実行ID、実行のURL、エラーメッセージ、失敗したノード、ワークフローのIDと名前）を受け取ります。ただし手動実行ではテストできず、自動のワークフローが失敗したときだけ動きます。 execution.id と execution.url は実行がデータベースに保存されている必要があります。 意図的に止めたい条件は、Stop and Error ノードで失敗させて同じ仕組みに寄せます。

記録を残す

• 素材台帳の行の写し（提供元、購入区分、取得日、入れた人）と点検した日時
• 引用した条文の全文（cited_text）と、文書の名前・版・発効日・条項の番号
• 検索基盤に投げた語と、返ってきた候補の並び（@search.rerankerScore を含む）
• AIが付けた verdict、規則が付けた overall、人が区分を覆した記録
• 提供元別・外注先別の no_record と not_found の発生率

2つ目が、この構成でいちばん重要なログです。 後日、提供元や第三者から問い合わせが来たときに、「公開の時点で、この版のこの条文を見て判断した」と示せるかどうかが変わります。今の規約を見せても、当時の条件の説明にはなりません。

最後の行は、取り決めを見直す材料です。 特定の外注先だけ no_record が高いなら、素材一覧の提出を発注書に書き込む相手がそこだと分かります。