PLATEAU 利用ライセンスとクレジット表記

「山手線 3Dジオラマ」では、国土交通省の都市3DデータであるPLATEAUを、建物モデルとしてそのまま組み込んでいます。また、背景地図にはOpenStreetMap由来のタイルを、3D描画にはThree.js、地図描画にはMapLibre GL JSを、各種OSSを積み重ねる形で運用しています。

これらは本当にありがたい存在なのですが、ライセンスの条件を一つでも守り忘れると、運営としての信頼を一気に失いかねない領域でもあります。この記事では、PLATEAUを中心としたクレジット表記のまとめと、私が実際にライセンス表記を誤ってGitHubで冷や汗をかいた話を書きます。

PLATEAU の利用条件は CC BY 4.0

PLATEAUのデータは、原則としてクリエイティブ・コモンズ表示 4.0 国際（CC BY 4.0）の条件で提供されています。つまり、以下の条件を満たせば、商用・非商用を問わず自由に利用できます。

条件の要旨は、出所の明示（著作者名、作品名、ライセンス種別）、変更した場合はその旨を明示、という2点です。PLATEAUのハンドブックでは、サイト上のわかりやすい場所に「出典：国土交通省『PLATEAU』」と表示するよう推奨されています。

サイトでの実際の表記例

私のサイトではフッターに、以下のような表記を入れています。表示位置は「クレジットページ」へのリンクだけでも可とされていますが、フッターに直書きしておく方がユーザーにも優しいと感じました。

<footer>
  <p>
    出典：
    <a href="https://www.mlit.go.jp/plateau/">
      国土交通省 Project PLATEAU
    </a>（CC BY 4.0 に基づき利用）
    <br>
    背景地図：©
    <a href="https://www.openstreetmap.org/copyright">
      OpenStreetMap contributors
    </a>
  </p>
</footer>

PLATEAUの利用規約には、「データを加工した場合にはその旨を表示」という条件もあります。私はPLATEAUのLOD2建物データをThree.jsで表示するため、Blenderで不要なディテールを削って軽量化しています。これは「加工」にあたるので、クレジットページで「※本サイトではPLATEAUデータを加工・軽量化して使用しています」と明記しました。

OpenStreetMap の ODbL と両立させる

背景地図のタイルはOpenStreetMap（OSM）由来ですが、ここで一つ注意点があります。OSMのデータは ODbL（Open Database License） で提供されており、これはCC BY系とは別系統のライセンスです。

ODbL の要求事項は（非専門家向けに要約すると）、「出典明記」「改変しデータベース化したものは同じODbLで公開」「DRMで利用を制限しない」の3点です。タイル画像を使っているだけなら、データベース化にはあたらないとの見解が一般的で、出典明記だけで実務的には十分とされています。

PLATEAU と OSM を重ねるときの表記順

地図上に2つのデータソースを重ねる場合、どちらを先に書くかで迷いました。調べた限り優先順位の厳密なルールはないようなので、「建物モデルはPLATEAU、背景地図はOSM」と役割を明示する方針にしました。ユーザーから見て「何がどこ由来なのか」がわかることが重要です。

OSS のフッター表記が必須なライブラリ

実はOSSにも、ライセンス条文をサイトのどこかに含めなければならないものが多くあります。私が利用しているもので該当するものを整理すると、次のようになります。

Three.js はMIT License。条文と著作権表示を「配布物に含める」ことが求められます。Webアプリの場合、配布物 ≒ クライアントに送信されるファイルなので、 LICENSE.txt を公開パス（/third-party-licenses.htmlなど）に置いておくのが実務上の落とし所です。

MapLibre GL JS はBSD 3-Clause。MITと同じく、著作権表示と条件文をドキュメントに含める必要があります。MapLibreは内部で attribution 表示を自動的に地図の右下に出す仕様があり、これは消してはいけないルールです（無効化するとライセンス違反になる可能性があります）。

さらに、glTFモデルをProxyするためのPako（圧縮ライブラリ）はMIT、DRACOLoader経由のDraco decoder はApache 2.0、Webフォントは各フォントの規約と、個別に確認が必要です。

<!-- /third-party-licenses.html -->
<h1>Third Party Licenses</h1>

<h2>Three.js</h2>
<pre>
The MIT License

Copyright © 2010-2026 three.js authors
...（ライセンス原文）...
</pre>

<h2>MapLibre GL JS</h2>
<pre>
Copyright (c) 2020, MapLibre contributors
All rights reserved.
...（BSD-3-Clause 原文）...
</pre>

GitHub でライセンスを誤って指摘された話

恥ずかしい話ですが、私は一時期、別プロジェクトのライセンステキスト（あるOSSのMIT条文）を流用してコピペしていました。Copyright行だけ書き換えて使っていたのですが、GitHubのIssueで見知らぬ方から「このライセンステキストは ○○ 由来で、著作権行は書き換えてはいけません。またコピペ元のORIGINAL著作権表示が欠落しています」と丁寧に指摘されたのです。

冷や汗が吹き出しました。MITはとても緩いライセンスですが、「著作権表示とライセンス条文を、そのまま、配布物に含める」というただ一つの条件は厳然として存在します。これを軽視したら、OSSコミュニティに対する最低限の礼儀も守れていません。該当のライセンス表記は全て原文に差し替え、このIssueを提起してくれた方にはお礼のコメントを返しました。この経験以降、OSSを追加するたびに npx license-checker を回して各ライセンスの原文を確認するのがルーティンになりました。

ads.txt と AdSense ポリシー対応

AdSenseを導入している以上、Googleが定めるポリシーにも従う必要があります。広告と直接関係はないのですが、サイトの「運営者情報」や「プライバシーポリシー」を明示することが、AdSenseポリシーで強く推奨されています。これは形式的なコンテンツというより、実質的な信頼性を示す要素になります。

私のサイトでは、/about.html（運営者情報）、/privacy.html（プライバシーポリシー）、/terms.html（利用規約）、そして今回新たに /third-party-licenses.html をフッターからリンクする形にしました。

ads.txt の設置

AdSenseを使う場合、ルートに /ads.txt を設置することで広告在庫の真正性を担保できます。内容はAdSenseの管理画面からコピーして貼り付けるだけですが、ここも「一行に自分のPublisher IDを記載する」という素朴なテキストファイルです。

# /ads.txt
google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

これを置き忘れていた時期に、AdSenseの管理画面で「ads.txtステータス：認証されていません」の赤い警告が出続けていて、数日間「広告収益の一部が失われているかもしれない」と肝を冷やしました。

robots.txt の設定

ライセンスと直接は関係ないのですが、関連する話題として robots.txt も整備しました。サイトのクロールを拒否する意図はないものの、/assets/models/ 以下の巨大なバイナリファイルを検索ボットに無駄クロールされるのは通信費的にも避けたかったからです。

# /robots.txt
User-agent: *
Allow: /
Disallow: /assets/models/
Disallow: /assets/audio/

Sitemap: https://mini-trains.com/sitemap.xml

sitemap.xml も置いておくと、Search Consoleのインデックス登録が若干スムーズになるという小話もあります。

ライセンスチェックを自動化する

npmパッケージが数十個を超えてくると、手動で全てのライセンスを確認するのは現実的ではなくなります。私は license-checker と license-checker-rseidelsohn を併用して、ビルド時にライセンス一覧を自動生成するようにしました。

# package.json の scripts
"licenses:list": "license-checker --production --json > third-party.json",
"licenses:summary": "license-checker --production --summary"

--production オプションを付けると、dependencies のみ（開発依存を除外）でチェックしてくれます。クライアントに配布されるのは production ビルドの成果物だけなので、ライセンス表示義務もそこに閉じると考えるのが一般的な解釈です。ただし、これを過信して開発依存を完全に無視すると、内部ツールで使っているGPL系ライブラリの存在を見落とすリスクがあるので、年に1回は全体チェックをかけています。

NOTICE ファイルを尊重する

Apache 2.0ライセンスのライブラリは、NOTICE ファイルがソースに含まれる場合、その内容を配布物に同梱する義務があります。Dracoデコーダや一部のAWS SDKはApache 2.0なので、これらを使うプロジェクトでは third-party-licenses.html にNOTICEの内容を含める必要があります。私は最初「LICENSEだけ書けばいい」と思っていて、NOTICEのことを完全に見落としていました。

商用利用と非商用利用の境界

最後に、一番判断に悩んだ部分です。PLATEAUは商用利用を許可していますが、AdSenseで収益を得ているサイトは商用になるのか？答えは「Yes」です。ですが、CC BY 4.0は商用利用に制限を設けていないため、表示義務を果たせば問題ありません。

対して、車両モデルのベースに配布フリーの3DCG素材を使う場合、素材サイトによっては「商用利用NG」「クレジット必須」「再配布NG」などの条件が付くことがあります。私は一度、素材サイトの利用規約を読み落として、「商用利用には別途ライセンス料が必要」というモデルをうっかりサイトで使いそうになり、アップロード直前で気づいて差し替えたことがありました。数分の確認を怠ると、一気に法的リスクにつながる領域です。

クレジットページの運用

現在のクレジットページでは、「データ」「ライブラリ」「素材」の3カテゴリで区分けして、それぞれの条件を明示するようにしています。一覧性が高いので、自分で振り返るときも、外部の方が確認するときもフェアだと思います。

まとめ

ライセンス周りは、最初は「なんとなくクレジットを書けばいい」と思いがちですが、実際に調べてみるとデータソースとライブラリごとに細かい要件があり、一度整理しておくと後が楽になります。
特にCC BY系のデータとBSD/MIT系のOSSは、表記の仕方が微妙に異なるので、サイト立ち上げ直後に /third-party-licenses.html を用意しておくのが強くおすすめです。OSSと公的データに敬意を払いつつ、安心して運営を続けていきたいと思います。

Yamanote 3D Diorama

PLATEAU のライセンス整理