製品に組み込んだOSSのライセンス条件を、リリース前に点検する

処理の起点を決める

リリース用のタグが付いたときを起点にします。あわせて、週1回の定期実行も入れます。タグだけにすると、開発中に入った依存の発覚がリリース直前になるためです。

差分が0件のときは何も通知しません。毎回レポートが来ると読まれなくなります。

入力データを集める

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

SBOM： リポジトリの依存関係グラフから出力します。GitHubでは、依存関係グラフの内容をSBOMとして書き出す機能があり、画面からの出力、REST API、ワークフローの3通りで取得できます。書き出される形式は業界標準のSPDXで、版・パッケージ識別子・ライセンス・依存の経路・著作権表示を含みます。

ライセンス条文： SPDXのライセンス一覧を使います。この一覧は、よく使われるライセンスと例外について、短い識別子・正式名称・ライセンス本文・恒久URLを組にして持ち、機械可読のデータファイルも配布されています。自社で条文を集めて回る必要はありません。

判断台帳： 社内で持ちます。列は「部品名／版の範囲／配布形態／判断／条件／判断日／判断者」です。この台帳が、2年目以降の工数を決めます。

配布形態の定義： これは人が決める情報です。製品ごとに「自社運用のみ」「顧客環境へ設置」「機器に組み込んで出荷」のどれかを登録しておきます。ここを開発者に毎回聞いている限り、自動化は完成しません。

AIへ渡す前に整形する

1. 識別子の正規化 … 表記が Apache 2.0 Apache License 2.0 Apache-2.0 と揺れます。SPDXの短い識別子（Apache-2.0 MIT GPL-3.0-only BSD-3-Clause など）に寄せます
2. 未知の識別子の分離 … 一覧にないもの、NOASSERTION のように不明とされたものは、AIに渡さず人へ回します。ここを推測させると事故になります
3. 差分の抽出 … 前回SBOMと比べ、新規・版上げ・削除に分けます。版上げはライセンス変更が起きうるので、同じ部品でも再判定の対象にします
4. 重複の集約 … 同じ部品が複数の経路から入ることがあります。部品と版で1件にまとめ、経路は付帯情報として持ちます
5. デュアルライセンスの展開 … 「AまたはB」で提供されるものは、選択肢を両方残したまま次へ渡します

AIに処理させる

処理の役割を分けます。

プログラムにさせること： SBOMの取得、差分、識別子の正規化、台帳の照合、未知の分離。ここはすべて機械的な処理で、AIを使いません。 判定の入口を安定させるためです。

LLMにさせること：

LLMに「使ってよい／だめ」を言わせません。 出させるのは「何が発動し、何を確かめる必要があるか」までです。可否は人が決めます。

指示内容を固定する

あなたは、ソフトウェア製品に組み込まれたオープンソースの
ライセンス条件を整理する担当者です。

【厳守事項】
- 可否の結論を書かないでください。発動する条件と、
  確認すべき点を挙げるところまでが役割です。
- 条文に書かれていないことを補わないでください。
  条文から読み取れない点は unclear に列挙してください。
- 法令の解釈、判例、一般論を持ち出さないでください。
  参照するのは、渡されたライセンス条文だけです。
- ライセンス識別子を書き換えないでください。
- 提供された配布形態以外の場合を想定しないでください。

【製品の配布形態】
{distribution_form}

【今回増えた部品】
{new_components}

【該当するライセンス条文】
{license_texts}

【同じ製品にすでに入っている部品とライセンス】
{existing_components}

【過去の判断（同じ部品・近い版）】
{past_decisions}

「可否の結論を書かない」の1行が、この構成の要です。 ライセンスの可否は、自社の事業判断と契約の問題です。AIに結論を出させると、その結論が独り歩きします。

出力形式を固定する

{
  "component": "",
  "version": "",
  "license_ids": [],
  "distribution_form": "",
  "obligations": [
    {
      "type": "attribution | source_disclosure | modification_notice | patent | other",
      "triggered": "yes | no | depends",
      "condition": "",
      "source_clause": ""
    }
  ],
  "conflicts_with": [],
  "unclear": [],
  "past_decision_ref": "",
  "needs_human": true
}

source_clause に、判断のもとにした条文の箇所を必ず入れさせます。これがないと、人が確かめるのに条文を最初から読むことになり、削減になりません。

needs_human は既定で true です。

システムへ連携する

最後の行を省かないでください。 表示義務があると判定しただけでは、義務は果たされません。製品に同梱する表示ファイルまでつないで、はじめて業務が閉じます。

人が確認する

全件、人が確定します。段階的な自動確定もしません。

理由は、ライセンスの判断が事業判断だからです。同じライブラリでも、自社運用なら問題なく、顧客環境へ設置するなら条件が付くことがあります。この判断は、製品の出し方と顧客との契約を知っている人にしかできません。

確認を速くするための設計が重要です。

• レポートを 「未知」「要判断」「過去どおり」の3つに分けて出す
• 「過去どおり」は一覧で見せ、1件ずつ開かせない
• 「要判断」には、条文の該当箇所を引用して添える
• 前回からの差分だけを出す。全件を毎回並べない

これらがないと、レポートが長くなり、読まれなくなります。

例外に対処する

記録を残す

• SBOM（リリースごと。製品に何が入っていたかの記録になります）
• ライセンス条文の取得日と版
• AIが出した論点と、引用した条文の箇所
• 人が下した判断、判断者、判断日、理由
• 人がAIの整理を訂正した箇所

最後の項目は精度の実測値になります。「表示義務の判定はそのまま通るが、組み合わせの指摘は半分が的外れ」と分かれば、どこを直すかが決まります。

SBOMそのものの保存は、別の意味でも効きます。 脆弱性が公表されたときに「自社製品のどの版に入っているか」を即答できる状態になります。