製品に組み込んだOSSの一覧（SBOM）とライセンス本文から、取扱説明書・製品同梱用のライセンス表示文書の下書きを作り、表示漏れを機械で確かめる

処理の起点を決める

ビルドのCIがSBOMを保存したことを起点にします。 出荷や更新の候補のビルドだけを対象にし、開発中の毎日のビルドでは動かしません。下書きがリリースの判定の会議より前にそろっていれば、表示文書が出荷の足を止めなくなります。

1つの版で動くのは1回です。同じ版のSBOMが再度保存されたら、前の下書きを上書きせず、版の中の通し番号を上げて作り直します。 どのSBOMから作った下書きかが、後から追えるようにするためです。

もう1つの起点は、知財の担当が確認待ちの部品の判断を入力したときです。 判断が入るたびに組み立てと突き合わせをやり直し、すべての部品が判断済みになった時点で、確認の画面に下書きを出します。

入力データを集める

質を決めるのは、いちばん下の表示の決まりです。 ライセンスごとにまとめるか部品ごとに並べるか、前文に何を書くか、ソースコードの入手方法をどこに書くか。この決まりを文書にしておかないと、AIは毎回違う構成で書きます。

著作権表示は、SBOMの項目だけに頼りません。 SPDXの著作権表示は任意の項目で、空のときは NOASSERTION と同じ意味になります。SBOMの値と、ソースから取り出した候補を両方持ち、どちらを使うかは知財の担当が部品ごとに一度決めて、次の版から引き継ぎます。

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

ライセンスの原文は、部品のソースにあるものを使います。 同じMITライセンスでも、著作権表示の行は部品ごとに違います。MITライセンスは、著作権表示とこの許諾の表示を、ソフトウェアのすべての複製または重要な部分に含めることを条件にしています。一般的なMITの本文を1つ載せて済ませると、部品ごとの著作権表示が落ちます。

NOTICEファイルは、ファイル名で探して取り出します。 Apacheライセンス2.0の第4条(d)は、元の作品の配布物にNOTICEのテキストファイルがある場合、派生物に帰属の表示の読める写しを、派生物と一緒に配布するNOTICEファイル、ソースや文書、または派生物が表示する画面のいずれかに含めることを求めています。この構成では、取扱説明書と画面の両方に入れる前提で組み立てます。

AIへ渡す前に整形する

1. SBOMの読み込みと検査 … SPDXの形式として読めるかを確かめ、部品の名前と版の重複を除きます
2. 差分の作成 … 前の版のSBOMと比べ、追加・削除・版の変更・ライセンスの変化を一覧にします。開発の担当の「変更した部品の一覧」と照らし、一覧に無い変化に印を付けます
3. 判断の要る部品の抽出 … 結論のライセンスが NOASSERTION か NONE、申告と結論が違う、ライセンスの式に OR を含む、ソースコードの提供の申し出が要るライセンス（GPL・LGPLなど）。前の版で知財が判断済みで、版もライセンスも変わっていない部品は除きます
4. 原文の取り出し … ライセンスのファイル、著作権表示の候補、NOTICEファイルを部品ごとに取り出し、取り出したままの文字で保存します。 改行や空白も変えません
5. 差し込み記号の割り当て … 部品ごとに {{LICENSE:部品ID}} {{COPYRIGHT:部品ID}} {{NOTICE:部品ID}} の記号を割り当てます
6. AIに渡す情報の絞り込み … AIには部品の名前・版・ライセンスの識別子・差し込み記号・表示の決まりだけを渡し、ライセンスの原文は渡しません

6番目が、この構成でいちばん効く前処理です。 原文を渡さなければ、AIは原文を書き換えようがありません。AIが見るのは「どの部品が、どのライセンスで、どの記号か」だけです。

3番目のGPLの部品の扱いは、手順書に書いておきます。 GPLv2の第3条は、目的コードや実行形式で配布する場合に、対応するソースコードを添えるか、少なくとも3年間有効な書面による申し出を添えるなどのいずれかを求めています。どの方法を取るかは製品ごとに知財が決めることで、AIに選ばせません。

AIに処理させる

させるのは、表示文書の構成を決め、前文と各まとまりの説明の文を書き、差し込み記号を正しい位置に置くことだけです。

5行目は、指示に書いておかないと起きます。 部品が300あると、AIは「ほか多数のライブラリ」とまとめようとします。まとめた瞬間に、突き合わせが漏れとして止めます。 止まるのは正しい動きですが、毎回止まらないように指示で禁じておきます。

指示内容を固定する

あなたはメーカーの知財部で、製品に同梱するOSSライセンス表示文書の下書きを作る担当です。
渡された部品の一覧と表示の決まりだけを使ってください。

【作るもの】
1. 前文（表示の決まりの定型に沿う）
2. ライセンスの識別子ごとのまとまり。まとまりの中に、部品ごとの項目を置く
3. 部品ごとの項目には、部品名、版、そして渡された差し込み記号を置く
   {{COPYRIGHT:部品ID}} → {{NOTICE:部品ID}}（あれば）→ {{LICENSE:部品ID}}
4. ソースコードの入手方法の欄には {{SOURCE_OFFER}} だけを置く
5. 確認用に、前の版からの変更点を箇条書きで要約する

【厳守事項】
- ライセンスの本文、著作権表示、NOTICEの文を書かない。差し込み記号だけを置く。
- 差し込み記号は、渡された一覧にあるものだけを使う。新しい記号を作らない。
- 渡されたすべての部品を、1つずつ項目にする。
  「ほか」「その他のライブラリ」のようにまとめない。省略しない。
- 部品名と版は、渡された文字のまま書く。表記を整えない。
- ライセンスの識別子が "NOASSERTION" の部品は一覧に含まれていない。
  含まれていた場合は、項目にせず unresolved に入れる。
- どのライセンスに当たるか、どの義務があるかを書かない。
- 前文に、法的な保証や責任についての文を足さない。

【部品の一覧】{components}
【表示の決まり】{rules}
【前の版からの差分】{diff}

「部品名と版は渡された文字のまま」を入れるのは、突き合わせを文字列で行うからです。 libxml2 を LibXML2 に整えられると、突き合わせが漏れと判定します。整えた文字が正しいかではなく、元と一致するかで見る設計です。

「前文に法的な保証や責任の文を足さない」は、生成AIが前文を「丁寧に」書くと起きる問題への対処です。 「本ソフトウェアは現状のまま提供され…」のような文は、各ライセンスの本文に書かれています。前文で別の言い回しを足すと、本文との食い違いが生まれます。

出力形式を固定する

構造化出力で、次の形に固定します。 公式のページでは、構造化出力は指定した JSON スキーマに従わせる機能で、Chat Completions API では response_format、Responses API では text.format でスキーマを定義するとされています。すべての項目を必須にし、オブジェクトには additionalProperties: false を設定することが求められ、スキーマは最大100個のオブジェクトのプロパティ、5段の入れ子までとされています。

{
  "preamble": "",
  "groups": [
    {
      "license_id": "Apache-2.0",
      "components": [
        { "component_id": "", "name": "", "version": "",
          "placeholders": ["{{COPYRIGHT:…}}", "{{NOTICE:…}}", "{{LICENSE:…}}"] }
      ]
    }
  ],
  "source_offer_placeholder": "{{SOURCE_OFFER}}",
  "unresolved": [ { "component_id": "", "reason": "" } ],
  "change_summary": [ "" ]
}

1つ目の理由は、placeholders を突き合わせの対象にできることです。 組み立ての前に、すべての部品の記号がそろっているか、一覧に無い記号が無いかを数えます。記号がそろっていれば、原文は必ず入ります。

2つ目は、部品の数がスキーマの上限に当たらないことです。 部品は components の配列の要素として並べるので、部品が300あってもプロパティの数は増えません。部品ごとにキーを作る形にすると、上限に当たります。

組み立ての後の突き合わせは、次の表で行います。

3つ目の理由は、unresolved で、AIが扱えなかった部品を拾えることです。 前処理で外したはずの部品が混ざっていた場合も、ここに出ます。

システムへ連携する

文書の管理システムへの登録は、知財の担当が行います。 自動で登録すると、確認前の下書きが「最新版」として開発の担当に渡ります。出荷物に載る文書は、人の確認を経た版だけにします。

ソースの保管庫とビルドのCIは読み取りだけです。SBOMのライセンスの値が誤っていると分かっても、この構成からは直しません。 開発の担当に、SBOMを出す側の設定を直してもらいます。

人が確認する

人が見るのは、確認待ちの部品、突き合わせで止まった箇所、前の版からの差分の3つです。

1. 確認待ちの部品 … NOASSERTION、申告と結論の違い、OR を含むライセンス、ソースの提供の申し出が要るもの。ライセンスの判断と、ソースの提供の方法を決めます
2. 突き合わせで止まった箇所 … 部品の欠け、原文の不一致。多くは原文の取り出しの誤りで、取り出しの設定を直します
3. 前の版からの差分 … 追加・削除・版の変更。開発の担当の一覧に無い変化を、とくに見ます
4. 前文とまとまりの説明の文 … 定型から外れた文が無いかを読みます

下書きの全文を読み直すことはしません。 本文と著作権表示は原文のまま差し込まれ、突き合わせで確かめられています。全文を読む設計にすると、180分が45分には収まりません。

判断の結果は、部品と版の組み合わせで記録し、次の版に引き継ぎます。 同じ部品の同じ版が次の機種に入っても、同じ判断をもう一度しないで済みます。 ただし、部品の版が上がったら、ライセンスが変わっていなくても判断をやり直します。 版が上がるとNOTICEファイルや著作権表示が変わることがあるからです。

例外に対処する

上の2行が大半を占めます。 2行目はとくに、ライセンスのファイルを持たない小さな部品や、他の部品にファイルが同梱されている部品で起きます。ここはAIでは埋まらないので、知財の担当が入手元を確かめます。

記録を残す

• 下書きを作ったSBOMのファイルと、その版・通し番号
• 取り出したライセンスの原文・著作権表示・NOTICEの原文（取り出したままの文字）
• AIへの入力（部品の一覧・表示の決まり・差分）と出力のJSONの全文
• 組み立てた下書き（取扱説明書用・画面用）と、突き合わせの結果
• 確認待ちの部品ごとの知財の判断と、判断した人・日付
• 確定した文書と、それを載せた機種・版・出荷日

最後の行は、問い合わせへの備えです。 出荷後に「この機種のこの版に入っている部品の表示を見たい」と言われたとき、どのSBOMから作り、誰がどう判断した文書かを、すぐに示せます。