公開データの二次利用とライセンス判断

データを外部プラットフォーム（SNS・API・公的サイト等）から取得して提供するツールを採用するとき、またはその型の事業を自分で設計するときは、機能・価格・収益性より先に「上流がデータを商用ライセンス化・課金化できる構造か」を見る。

なぜ

• 収益性が高くても上流の一存で消える。実例: Reddit 痛点分析の専業 SaaS が、需要不足ではなく Reddit Data API の商用価格化（1,000コール単位の従量課金）で経済性が崩れ、月次収益数万ドル・有料顧客1万超のままサービス終了した（2025）
• 同じ構造は公的データにもある（配布物の営利利用制限で主柱商品を失う型）。データ依存型は「規約の二層確認（サイト規約＋ファイル本文の権利表記）」と「課金化可能性」の両方を見ないと片方のリスクが残る
• 代替ツールが「公式 API を使わない」ことを売りにする場合、それは課金リスクを規約違反リスクに付け替えただけで、リスクが消えたわけではない

適用

• ツール選定時: データ源の利用規約と API 価格の改定履歴を確認する。上流が過去に課金化・規約強化をしたプラットフォーム（SNS 系が典型）に依存するツールは、長期のワークフローの中核に置かない（代替経路を持つか、自前で公式無料枠を叩く）
• 事業設計時: 主柱商品が依存するデータ源の規約・課金化可能性の検証を最優先ゲートに置く。公的機関のオープンデータ（法令・告示・調達実績等、著作権の対象外か明示的オープンライセンスのもの）は、このリスクが構造的に低い側
• 検証方法: 「このデータ源が明日商用 API 課金を始めたら原価はいくらになるか」を見積もり、営業利益が消えるなら依存を設計段階で分散する

公開データの二次利用について権利者へ許諾を問い合わせると、返答が規約の別項を引いたものになることがある。典型は、複製・再配布の可否を尋ねたのに「当サイトはリンクフリーなので特段の許諾なく利用できる」という趣旨の回答が返る形。組織のサイト利用規約はたいてい「リンクについて」「著作権について」「免責事項」が別項として並んでおり、リンクの自由と、データを複製・改変・送信することの可否は別の項が支配している。前者だけを答えた回答を後者の許諾として使うと、根拠のない前提の上に実装が積み上がる。

判断手順

1. 自分がやろうとしている行為を、規約の語彙へ翻訳する。データを取り込んで自サイトから配信するのは「リンク」ではなく複製・改変・送信にあたる。
2. 規約ページの全項目を一次情報で読む。回答文の引用範囲ではなく、ページに何項あり、どの項が自分の行為を支配するかを確かめる。著作権の項に「個人的使用と著作権法上認められる場合を除き、許諾なく複製・頒布・改変することはできない」といった条項が残っていれば、リンクの項は自分の行為をカバーしていない。
3. 回答が自分の行為に触れていないと分かったら、行為を明示して再照会するのが原則。それでも進める判断をするなら、判断したという事実と根拠を記録に残す。

ファイル本文の注記が規約を上書きすることがある

サイト全体の規約がオープンライセンスでも、配布ファイル本文の一文（「この名簿を営利目的で使用することは御遠慮ください」等）がその適用を外していることがある。規約側が「特記がない限り」という条件付きなら、その注記は特記に当たると読むのが自然。サイトの規約ページだけでなく、配布物そのものの本文も読む。同種の注記が複数の配布元で共通して現れるなら、個別のミスではなくその種の資料に共通する運用と見てよい。

進める判断をしたときに実装へ落とすもの

• 規約が課している条件（出典表示の文言など）は、ページごとの手書きではなく設定の一箇所に定数化し、全ページで機械的に検証できる形にする。手書きは1ページ抜けても気づけない。
• 照会文と回答は証跡として保管する（リポジトリには置かない）。
• 取り下げ要請が来たときに、そのデータだけを1コミットで落とせる構造にしておく。ソース単位・種別単位で分離した設計は、そのまま撤収単位になる。

自前データで学習したモデルでも、学習に使ったフレームワークや起点にした事前学習重みのライセンスが「成果物（学習済み重み）にも及ぶ」と主張されていることがある。代表例が AGPL 系の検出フレームワーク（2026年時点の ultralytics/YOLO など）で、公式見解として「学習済みモデルはデフォルトで AGPL、ソース非公開の商用 SaaS 利用は別途商用ライセンス必須」と明記している。

落とし穴

• 「自分のデータで学習したから自分のもの」という直感はベンダーの主張と衝突しうる。特に公式配布の事前学習重みから fine-tune した場合は派生物としての結びつきが強い
• Web クライアント推論（ブラウザでの ONNX 実行等）は、静的配信ディレクトリへの配置時点で「重みの配布」に該当する。本番前の preview 環境でも配布は始まっている
• ONNX 等への形式変換はライセンス上の性質を変えない

確認手順

1. 学習ツールチェーン全体（フレームワーク・事前学習重み・変換ツール・推論ランタイム）を列挙し、それぞれのライセンスをパッケージメタデータで確認する
2. copyleft 系（GPL/AGPL）が含まれる場合は、ベンダーの公式ライセンスページで「学習済みモデルへの適用主張」を一次確認する（主張の有無と内容は時点で変わるため、判断時に再確認する）
3. モデルの重みに個別ライセンス記載がない OSS は、コードのライセンスを準用できるか不明な場合があり、厳密を期すなら作者確認まで行う

判断基準

• 商用配布が必要で copyleft を避けたい場合の選択肢は (1) ベンダーの商用ライセンス購入 (2) permissive（Apache-2.0/MIT）なアーキテクチャでの再学習。学習パイプライン（素材・合成・評価）をフレームワーク非依存に資産化してあれば、載せ替えはモデル定義の差し替え+学習数回で済み、(2) のコストは小さい
• アーキテクチャ選定の段階でライセンスを選定基準に含めると後戴しがない（精度・速度だけで選ぶと配布段階で詰まる）

公的機関が公開するデータを事業の原資にするとき、サイト全体の利用規約だけを読んで「商用可」と結論すると見誤る。

機序

日本の各省庁サイトの利用規約は、多くが「著作権は特記されていない限り当庁に帰属し、権利表記の記載がない限り公共データ利用規約（PDL1.0）に準拠する」という条件付きの書き方をする。つまり配布ファイル側に一文でも特記があれば、サイト全体の規約はそのファイルに適用されない。

実例では、2つの省庁の同種の名簿（片方は PDF、もう片方は Excel）の本文に、一字一句ほぼ同じ「この名簿を営利目的で使用することは御遠慮ください」という注記が入っていた。同じ制度の別のリスト（別省庁）には同種の注記が無く、文書の種類単位で運用が違うことが対比で分かった。

確認の手順

1. サイト全体の利用規約を読む。「特記」「権利表記」の語があれば条件付きと見なす
2. 配布ファイルを実際に開いて本文の注記を読む。PDF ならテキスト抽出して「※」で始まる行を全部拾う。Excel なら先頭数行と表外のセルを見る。ヘッダ行だけを見て本文を飛ばさない
3. 同じ制度の別ソースと見比べる。一方にだけ注記があれば、それはその文書固有の運用で、規約の一般論では覆せない
4. 同種のデータを複数の発行元で確かめる。同じ文言が複数で見つかれば、その文書種別に共通する運用と判断でき、他を探すコストを節約できる

判断基準

• 「御遠慮ください」は法的禁止ではなく要請の文言だが、事業の主柱をその上に建てるなら同じこと。後から指摘されたときに主力商品を止めることになる
• 「使うなら許諾を取ってください」と「使用は御遠慮ください」は全く別物。前者は手続きが用意されており待てば可否が出るが、後者は窓口の話ではない。同じ「許諾待ち」として扱わない
• 確認は実装の前にやる。パース検証が済んでいても、使えなければその工数は回収できない

落とし穴

一度「規約クリア」と計画書に書くと、その結論が後の意思決定の前提として再利用され、誰も検証し直さなくなる。確認したのがサイト規約だけなのか、配布ファイル本体まで見たのかを、根拠として残す。