Claude CodeでREUSEのSPDXヘッダ漏れを見つけて付ける手順

自分のリポジトリのソースファイルに、SPDXのライセンスヘッダが付いているかを reuse lint で検査し、足りないファイルへ reuse annotate でヘッダを入れる流れを組みます。Claude Codeに任せるのは、未表記ファイルの洗い出しと分類、そして決まった値でのコマンド実行です。著作権者とライセンスの値そのものは、人が決めて渡します。

REUSEは、各ファイルにライセンスと著作権の情報を機械可読な形で持たせるための推奨事項です。FSFE(Free Software Foundation Europe)が始めた取り組みで、進め方は3段階に整理されています。ライセンスを選んで LICENSES/ に置く。各ファイルにコピーライトとライセンスの情報を付ける。最後に準拠を確認する。このうち2番目と3番目を、検査結果を起点に回すのがこの記事の範囲です。

reuse lintが拾うのは「表記のないファイル」だけではない

reuse lint は、プロジェクトがREUSE仕様に準拠しているかを検査します。検査項目は次のとおりです。

ヘッダの付け漏れは最後の行に当たります。ただ、Missing licensesのように、ヘッダは付いているのにライセンス本文が無い状態も同じ検査で出ます。ヘッダを付ける作業の前に、どの項目が出ているかを切り分けておくと、Claude Codeに渡す依頼が混ざりません。

情報の持たせ方は、ファイル冒頭のヘッダだけではありません。隣に置く .license ファイル、祖先ディレクトリの REUSE.toml、非推奨の .reuse/dep5 でも、情報が紐づいていれば準拠とみなされます。つまり未表記と報告されたファイルが、必ずヘッダを書くべきファイルとは限りません。

出力の形式は選べます。--lines を付けると1エラー1行でファイルパスが先頭に付き、--json ならJSONで出ます。Claude Codeに読ませるなら、この2つが扱いやすい形です。

Claude Codeに任せる範囲と、人が決める範囲

ヘッダの中身は2つの値で決まります。誰の著作物か(SPDX-FileCopyrightText)と、どのライセンスか(SPDX-License-Identifier)です。どちらもコードを読んで確定できる情報ではありません。

REUSEのFAQは、著作権者(copyright holder)と作者(author)を分けて説明しています。著作権者は、その著作物に対する排他的な権利を持つ人です。多くの場合は作者と同じですが、権利が移転していれば別になります。たとえば雇用主が著作権者になる契約なら、コミットした個人の名前をそのまま入れると誤りです。git log の著者名は、候補にはなっても根拠にはなりません。

そのうえで、reuse annotate のマニュアルには注意書きがあります。自動化された工程で使うときは、追加される情報が現実を反映しているかを確認すること。これは人が手で確かめるのが最善、という趣旨です。この記事の分担は、この注意書きに沿っています。

候補を出させるときに拾える根拠は、事実に限ります。リポジトリ直下の LICENSE、既に付いているヘッダ、パッケージ定義の license 項目、同じディレクトリの他ファイルの表記、そのファイルの最初のコミット年。これらを並べるところまでが、Claude Codeの仕事です。根拠が無いファイルは「不明」と書かせ、埋めさせません。

手順:検査、分類、確認、付与、再検査

検査結果を保存する

pipx install reuse
reuse lint --lines > reuse-lint.txt

ここで reuse-lint.txt をコミットしない点に注意します。作業用の一時ファイルなので、終わったら消します。

分類表を作らせる

Claude Codeをプランモードで起動し(Shift+Tab を押してステータスバーが ⏸ plan mode on になるまで切り替えます)、次のように依頼します。

reuse-lint.txt を読み、ヘッダ未表記のファイルを次の3群に分けて表にしてください。
1. コメントを書ける形式で、周囲のファイルから候補が言えるもの
2. バイナリ、JSON、生成物など、ヘッダを書けないもの
3. サードパーティ由来に見えるもの(vendor/、third_party/ 配下、既存の他者の表記)
各行に、候補の著作権者とライセンス、その根拠(参照したファイルや行)を書くこと。
根拠が無いものは「不明」とし、推測で埋めないこと。ファイルは編集しないこと。

出てきた表は、行ごとに根拠のファイルを開いて確かめます。第3群は特に慎重に見ます。他者のコードを自分のプロジェクトに取り込む場合、REUSEのFAQは元のライセンスと著作権者を、そのファイルに記録するよう説明しています。ここへ自分のライセンスを一括で付けると、権利関係を書き換えることになります。

確定した値でヘッダを付ける

値が決まった行から、reuse annotate に渡します。基本形は次のとおりです。

reuse annotate \
  --copyright="Example Corp" \
  --license="Apache-2.0" \
  --year 2024 \
  src/server.py src/client.py

Example Corp と Apache-2.0 は例の値です。実際には手順3で人が確定した値を入れます。コメントの様式は拡張子から自動で選ばれ、C++系なら単一行の // が優先されます。--year を省くと現在の年が入る点も、見落としやすい箇所です。ファイルの初公開年と一致させたいなら、明示します。

ディレクトリごと付ける場合は -r(--recursive)を使います。拡張子が未知でコメント様式を決められないファイルには、中断するか、--skip-unrecognised で飛ばすか、--fallback-dot-license で .license ファイルを作るかを選べます。

reuse annotate には、もう一つ挙動の注意があります。ヘッダは冒頭に入りますが、シバン(#!)やXML宣言のような既存の先頭行は避けられます。そして、コピーライトやライセンスを含む別のヘッダが既にあると、それが置き換えられます。置き換えを避けたいときは --no-replace で新しいヘッダを追加します。第3群のファイルに誤って実行すると、元の表記が消えるので、対象のパスは必ず手順3の表で絞ります。

reuse lint が通ったあとは、reuse spdx -o reuse.spdx でSPDX形式の部品表(SBOM)も書き出せます。FAQでは、これをライセンス表記が揃ったことの成果物として案内しています。なお、この出力は人が確定した表記をそのまま写すだけなので、値が誤っていれば誤りごと出力されます。

ヘッダを書けないファイルの扱い

画像や動画、JSONのようにコメントを書けないファイルにも、情報は必要です。FAQによれば、方法は2つあります。隣に cat.jpg.license のような .license ファイルを置いて、その中にヘッダを書く。または REUSE.toml で指定する。

ディレクトリ単位でまとめて指定するなら、REUSE.toml が向きます。

version = 1
 
[[annotations]]
path = "resources/img/*"
SPDX-FileCopyrightText = "2024 Jane Doe <jane@example.com>"
SPDX-License-Identifier = "CC0-1.0"
 
[[annotations]]
path = ["poetry.lock", "requirements.txt"]
SPDX-FileCopyrightText = "NONE"
SPDX-License-Identifier = "CC0-1.0"

これはFAQにある例に沿った形で、値は例示です。2つ目のブロックは、機械生成のファイルに著作権者なし(NONE)を宣言する書き方で、FAQでも計算機生成のファイルの例として載っています。

precedence キーも覚えておくと便利です。override はファイル内の誤った情報を上書きします。aggregate は、ファイルの冒頭の表記を残したまま、情報を追加します。翻訳者が提供した .po ファイルのように、ヘッダを直接編集したくないときに使います。

Claude Codeにこの設定を作らせるときも、考え方は同じです。パスの束ね方(glob)はClaude Codeが提案してよい部分で、著作権者とライセンスの値は人が決めます。globが広すぎると、本来は別のライセンスであるファイルまで同じ表記で覆われます。

繰り返し使うための設定

同じ作業を何度も回すなら、約束事をCLAUDE.mdに書いておくと、毎回の依頼が短くなります。

## REUSE(ライセンス表記)
- ソースの SPDX ヘッダは reuse lint で検査する。
- 著作権者とライセンスの値は、推測で決めない。根拠が無いファイルは「不明」として報告する。
- reuse annotate は、人が確定した値を渡されたときだけ実行する。
- vendor/ と third_party/ 配下には reuse annotate を実行しない。

claude -p で非対話に回す場合は、権限も絞ります。--allowedTools に書けるのは、確認なしで使わせたいツールです。検査だけを自動にして、書き込みを伴う reuse annotate は確認の対象に残す設定が考えられます。

{
  "permissions": {
    "allow": [
      "Bash(reuse lint *)",
      "Bash(git diff *)",
      "Bash(git status *)"
    ],
    "ask": [
      "Bash(reuse annotate *)"
    ]
  }
}

askルールは、該当ツールを使うたびに確認を求めます。.claude/settings.json に置けば、reuse annotate だけが毎回止まり、人が値を見てから進められます。

つまずきやすい点

依存パッケージのライセンスは対象外です。REUSEのFAQは、依存先のライセンスを確認する用途には別のツールが必要だと述べています。依存関係の一覧とGPL系の混入は、OSSライセンスを一覧にして点検する手順の領分です。こちらは自分のリポジトリのファイル単位の表記です。

準拠しても、ライセンスが正しいとは限りません。 reuse lint が確かめるのは、情報が機械可読な形で付いていることです。選んだライセンスが依存先と矛盾していないか、契約上の権利者が合っているかは、検査の外にあります。

SPDXに無いライセンスは LicenseRef- で書きます。FAQでは、独自のライセンスを LICENSES/LicenseRef-MyLicense.txt のように置き、ヘッダで LicenseRef-MyLicense と参照する方法を説明しています。

一度で終わらせず、差分で確かめます。検査結果を渡して修正を回す型は、lycheeでリンク切れを直す手順と同じです。検査が決まった基準で拾い、Claude Codeが分類と実行を担い、最後に再検査と git diff で締めます。

まとめ

SPDXヘッダの付け漏れは、reuse lint が機械的に拾えます。拾えないのは、そのファイルを誰が書き、どのライセンスで出すかという判断です。Claude Codeは、一覧の作成と、確定した値でのコマンド実行に使います。値の確定は人が受け持つと、権利関係を黙って書き換える事故を避けられます。Claude Codeの権限設定で reuse annotate だけを確認対象に残せば、その分担がセッション中にも崩れません。