フォーラム:InstantCommonsを導入したい

出典: 謎の百科事典もどき『エンペディア（Enpedia）』
ナビゲーションに移動 検索に移動
フォーラム:メインページ > InstantCommonsを導入したい 進行中

Wikimedia Commonsの画像をアップロード無しで利用出来る、InstantCommonsという拡張機能の導入を希望させていただきます。なぜこの拡張機能の導入を希望したか、それは「画像を記事に挿入する事の面倒くささ」です。

まず現在の手法で画像を記事に挿入するには

  1. CC BY-SA3.0、4.0またはCC0、パブリックに対応している画像を探す。
  2. 見つけた画像をダウンロードする。
  3. 画像の著者や、その他諸々を記入する。
  4. エンペディアにアップロード。
  5. 画像名をコピペし、記事に挿入する。

この5つの手順を踏む必要があり、この手順を面倒臭いと思った方は私だけではないと思います。実際私もそうです。そこで「アップロード無しで画像を導入出来たら便利だろうな～」と思った方も私だけではないはずです。

そこでInstantcommonsを導入すれば

  1. Wikimedia commonsにアクセスし、画像を探す。
  2. 見つけた画像のファイル名をコピーする。
  3. コピーしたファイル名を通常の画像を貼り付け方法で貼る

たったこれだけの手順で画像を挿入することが出来ます。要するに「アップロード不要」ということです。

日本には「百聞は一見に如かず」ということわざがあります。これは「百の話を聞くよりもそれを実際に見た方が分かりよね」という意味です。このことわざの通り、大体の人は聞くよりも見た方が分かりやすいと考えている方はかなり多いと思います。エンペディアのような、「百科事典系サイト」、人に新しい知識を提供するサイトで「分かりやすさ」は重要な要素のひとつとなるはずです。

またいらっしゃらなかったら大変申し訳ないんですが、画像を追加出来るようになると、編集のモチベーションが上がると言う方、いらっしゃるのではないでしょうか?私もその類いの人間です。もしかなりの数いらっしゃった場合、これにより編集頻度や記事数の増加はもちろん、間違いや問題のある投稿の抑制やコミュニティーの活性化も充分に考えられることだと私は考えています。

Wikimedia commonsにはおよそ数千万の画像があり、よほどマイナーな画像(例えば私のTwitterのアイコン画像等)でなければ、大体の画像は見つかります。更に、画像のファイル容量は全てcoomonsが管理してくれるので、容量で困ることは無い筈です。

日記やあったらいいなリストでも使えたら便利という意見も聞こえてきます。また確かに、もし賛成という形になっても、多忙な最上位スタッフさんたちが導入に動いてくれるかは分かりませんが、やってみる価値はあると思います。どうか、この機会に行動をしてみてはどうでしょうか?沢山の意見お待ちしております。どうぞ、よろしくお願い致します。--❄ Mr.sirokuma（トーク 🐾 投稿記録 / 架空鉄道Wiki ） 2026-02-23T19:36:34 (JST)

  • スタッフさんの時間があるか…(ライセンス更新も終わってない)
  • まあそんなこと気にしてもしょうがないですが、コモンズにはCCじゃない画像もあります。それの対応は…？--RevPi 2026-02-25T07:54:29 (JST)
    • ご指摘の通り、コモンズにはGFDLなど、CC以外のライセンスも含まれています。
ですが、InstantCommonsを導入すると、画像をクリックした先の『ファイルページ』に元のライセンス情報が自動で同期・表示されます(例)。
つまり、私たちが手動でライセンスを書き換えたり明記したりしなくても、システム側で適切にライセンス元を表示してくれるため、著作権の面はカバー出来ると存じております。--❄ Mr.sirokuma（トーク 🐾 投稿記録 / 架空鉄道Wiki・トーク ） 2026-02-25T16:23:03 (JST)
  • いえ、EPにはCCの画像しか投稿できない決まりなんで、そこに触れないかなーと。--RevPi 2026-02-25T16:37:35 (JST)
  • P.S.これはファイルページではない(確かメディアビューアだった気がする)であります。エンペでは導入されてないであります。--RevPi 2026-02-25T16:40:57 (JST)
  • メディアビューワを導入していない場合はこんな感じになります。また、EnpediaにはCCの画像しか投稿できませんが、そもそもEnpediaに投稿されたファイルではないため、InstantCommonsで挿入できるファイルはライセンス規定の適用対象外だと思います。--Yaakiyu.jp (トーク) 2026-02-25T17:56:20 (JST)
  • 賛成票を入れておきます。理由としては上に返信した通り法的問題が無さそうであることと、スタッフが導入してくれる見込みが低いのは事実ですが、スタッフの方の時間がもしできたら「合意は既に取れているのであとは導入だけ」という状況になっている方が良いと感じたからです。--Yaakiyu.jp (トーク) 2026-02-25T17:56:20 (JST)
  • ご提示のように、同拡張機能が導入できれば確かに便利ではあり、その反面デメリットも多々あったりします。ただ、それを議論する前に、大前提として、そもそもその拡張機能が本サイトに導入可能なものなのか、その可否を検証しておく必要があると思います。同機能を導入すると、ライセンスに関係なくCommonsにあるすべての画像が使えるようになるわけですが（ライセンスで使える画像を限定する機能とかないよね？）Enpediaでそういう運用って可能なのでしょうか。Enpediaはサーバーが日本国内にあるため日本の法令を遵守する必要があるはずで、それゆえWikipediaと同じ運用をすれば権利上の問題は発生しないというわけにはいきません。少し前まであったYouTubeやniconicoの動画読み込みでさえ、いろいろ制約が多くて複雑だったことを思うと、そのあたりの折り合いをつけることって可能なのかなあと気になるところです。◆また、いざ導入するとなった場合、「Enpedia:著作権」をはじめとして、Enpedia内部の方針やシステムメッセージ等もかなり変更する必要があります。下手したら、14年前の3rd開設にむけての議論で（フォーラム:新ウィキについての議論/ライセンス）「CC-BY-SA 3.0 Unported を、全名前空間一律に適用する」と決めたところからひっくり返す必要があるぐらいなので、かなり大変だと思います。そのあたりも、何をしなければならないのか、とりあえずは大雑把にでいいので精査しておく必要があるかなと感じます。--Written By 360度 (Talk) 2026-02-25T18:02:55 (JST)
    • 追記 私は法令関係はまったく門外漢なのでこれはぜんぜん分からない人なりの意見です。あと、新ウィキについての議論のくだりは、やるとなったらそれぐらいやること多いぞっていうことを表現するために挙げたに過ぎず、別に「CC-BY-SA 3.0 Unported を、全名前空間一律に適用する」というのが金科玉条だと思っているというわけではないです。--Written By 360度 (Talk) 2026-02-26T16:23:54 (JST)
    • 返信 360度さん、非常に重みのある、かつ本質的なご指摘をありがとうございます。
お話を伺って、単に「便利になるから」という理由だけで進められることではなく、エンペディアが長年守ってきた「CC BY-SA 3.0 一律適用」という大原則や、日本国内の法律との兼ね合いなど、乗り越えるべき「非常に高い壁」があることを改めて痛感いたしました。
特に、14年前の開設時の議論まで遡るような大事な決まり事については、私のような後発の利用者には分からないことも多く、安易な提案でスタッフさんやコミュニティに過大な負担をかけてしまうリスクを再認識しました。
その上で、360度さんが懸念されている点について、私なりに「どうにか解決して、より良いエンペディアにできないか」と考えたことをお伝えさせてください。

1.ライセンスの決まりと「外部参照」の整理について

エンペディアの「一律適用」というルールは、これまで「サーバー内に保存・蓄積される自前のコンテンツ」を対象にしてきたものと解釈しています。一方でInstantCommonsは、技術的には「コモンズにある画像を窓から覗く（インラインリンク）」という仕組みです。画像を新しくサーバーに取り込むわけではなく、YouTubeの埋め込みと同じような「外部リソースを表示しているだけ」という形に整理できれば、今のライセンス方針を根底から変えずとも、例外規定などで対応できる余地はないでしょうか。

2.日本の法律（著作権法）との折り合いについて

サーバーが日本国内にある以上、日本の法律を守ることは絶対に必要だと思います。過去に動画の埋め込みで苦労されたお話も伺っておりますが、最近の法解釈や判例では、公式な仕組みを使った表示であれば、画像そのものを複製して再送信しているわけではないので、著作権侵害には当たらないという考え方も有力です。もちろん、エンペディアとしてどこまでリスクを許容するか、具体的な精査は必要ですが、調べてみる価値はあると考えています。

3.方針の書き換えや作業コストについて

著作権の方針やシステムメッセージを書き換える作業が、スタッフさんにとって膨大な負担になるという点も、仰る通りだと思います。ですが、もし「やってみる価値はある」と判断いただけるのであれば、その修正案の下書きを作ったり、直すべき場所を全て洗い出したりする作業は、提案者である私や賛同してくださる方々が率先して行いたいと考えています。スタッフさんの負担をできるだけ減らして、「あとは最終確認して適用するだけ」という状態まで準備するつもりです。
何回も言いますが、日本には「百聞は一見に如かず」ということわざがあります。エンペディアのような知識を伝えるサイトで「分かりやすさ」は非常に重要な要素だと思います。画像があることで記事の解像度が上がり、百科事典としての質が飛躍的に高まることは間違いありません。
また、私自身もそうですが、画像を手軽に追加できるようになれば、編集のモチベーションが上がるという方もたくさんいらっしゃるのではないでしょうか。それによって編集頻度や記事数が増えるのはもちろん、コミュニティの活性化にも繋がると信じています。
確かに14年前の決定は重いものですが、今の時代に合わせた「より良いエンペディア」を目指すために、まずは「何をクリアすれば導入できるのか」というリストを作るところから始めてみることはできないでしょうか。
長くエンペディアを支えてこられた皆様の知恵を、ぜひお借りできれば幸いです。どうぞ、よろしくお願い致します。--❄ Mr.sirokuma（トーク 🐾 投稿記録 / 架空鉄道Wiki・トーク ） 2026-02-25T19:41:07 (JST)
  • 返信 Yaakiyu.jp (トーク)です。360度さんのご指摘や、Mr.sirokumaさんの返信に基づき、現在の争点について、私が調査した内容も踏まえて整理しました。
  1. 外部参照の場合にエンペディアのライセンスの制限が適用されるのかどうか
    • こちらについては、YouTubeの埋め込みの話が出ている通り「適用されない」が正しいと思っています。つまり、ウィキメディアコモンズにアップロードされているファイルのなかで、ライセンスが指定されているもの(パブリックドメインを除く)に関しては、InstantCommonsのシステム上でそのライセンスに則った表示が行われるため著作法的な問題は発生し得ません。
      • なお、この埋め込みの話についてフォーラム内を探してみたのですが、YouTube/ニコニコ動画の埋め込みおよび制限に関する議論を見つけることができませんでした。(私が新参者なので昔の話を知らないというのもあります...)どなたか教えていただけると幸いです。
  2. エンペディアで日本国の著作権法に則ることにした場合、コモンズでアップロードされているファイルすべてが使用可能なのか
    • これが最大の懸念点になります。コモンズでは、ライセンスに関する規定の通り、パブリックドメイン以外に関しては厳格なライセンスルールが定まっており、これらのライセンスの条件はInstantCommonsの機能でクリアすることが可能です。しかし、パブリックドメインは各法域によって基準が異なるため、簡単に使用可能であると結論づけることはできません。もちろん、コモンズのサーバーがアメリカにあり、それを参照読み込みしているだけであることを理由に法令違反ではないと主張することは可能です(し、エンペディアのサーバーが停止されるほどの事態になることはないでしょう)が、エンペディアが主に日本国民が使うサイトである以上、ある程度の疑義は残るでしょう。
    • コモンズに存在するパブリックドメインのファイルはすべて、「米国と著作物の本国においてパブリックドメインである」ことが条件になっています。しかしここには日本は含まれていないため、「米国および著作物の本国であってパブリックドメインであっても、日本ではパブリックドメインにならない(著作権で保護される)」ものは存在します。これについては日本語版ウィキソースのヘルプページが最も詳しく解説していますが、このようなコモンズのファイルを使用できるかどうかという議論は日本語版ウィキペディア・ウィキソース双方で検索しても見当たりませんでした。誰も気にしないのかもしれません...
    • 一例ですが、「コモンズ上でパブリックドメインとされるファイルのうち、日本国の著作権法ではパブリックドメインではないもの」を投稿禁止にし、即時削除の対象に加える・一度発覚したファイルは日本でPDとなる期日のメモと共に編集フィルターでブラックリスト化する、といった対応が可能かもしれません。ただし、管理者の皆様方の負担がある程度増えてしまう可能性があります。(これはどの程度厳格にチェックするかにもよります。)
  3. インスタントコモンズを使うことになった場合、改定が必要なシステムメッセージ・方針はどれほど存在するのか
    • 私が見る限りではそれほど多くありません。例えばページフッターには「コンテンツは、特に記載されていない限り、クリエイティブ・コモンズ 表示-継承のもとで利用可能」(インスタントコモンズは特に記載されているケースに該当)だったり、編集画面の警告文では「Enpediaへの投稿はすべて、クリエイティブ・コモンズ 表示-継承 （詳細はEnpedia:著作権を参照）のもとで公開したと見なされる」（インスタントコモンズによる画像は「Enpediaへの投稿」に含まれない）だったりします。改変が必要なページを以下にまとめてみました。
    1. Enpedia:著作権 - コモンズのファイルが使用でき、外部読み込みに該当する旨の記載が必要です。(Enpedia:免責事項の「外部読み込み」節は抽象化されているため変更不要と考えています)
    2. MediaWiki:Uploadtext、ヘルプ:編集の仕方#画像をアップロードしよう - 「コモンズですでに存在する画像は(ほとんどが?)そのまま使えるよ」という文章を入れた方が良いでしょう。
    3. MediaWiki:edittools - コモンズからのファイルの移入という制度が不要になるため、コモンズテンプレートの部分を取り除く必要があります。
    4. テンプレート:ウィキメディア・コモンズ - 「現在は移入が不要」という内容の記述が必要。
      • すでに移入された画像について、削除も選択肢のうちの一つですが、物理的なサーバー負荷は消えない(Enpedia:サーバー負荷を気にしすぎない#気にすべき負荷も参照)ため削除しなくても良いかもしれません。
        • 個人的見解としては、「常にコモンズの画像を追従すること」が目的になっているような画像を削除する程度で十分でしょう。(その場合はMediaWiki:filedelete-reason-dropdownに一時的に理由を増やす必要が発生するかも)
      • なお、移入後に改変されたファイルが1つでも存在するのであれば、テンプレートの廃止はしない方がよい(もしくは特例のみsubstして廃止？)と思われます。
    5. さらに、上記で提案したような削除方針の追加を行う場合には、Enpedia:運用細則#削除の方針、MediaWiki:deletereason-dropdown、MediaWiki:revdelete-reason-dropdownの編集が必要になります。
  4. 14年前の議論を今からひっくり返すようなことになるのか
    • これに関しては新参者の私が言うのも何ですが、2023年にCC BY-SA 4.0をファイル名前空間で認める決定をした際にすでに覆っていないでしょうか...？
  • なかなかの長文になってしまいましたが以上です。私個人としては非常に導入してほしい機能ですので、ぜひ議論が活発に、そして良い方向に進むことを願っております。--Yaakiyu.jp (トーク) 2026-02-25T22:27:26 (JST)
  • 追記もしインスタントコモンズを導入することになれば、一緒にフォーラム:アメリカ合衆国政府の著作物も解決できそうですね。(エンペディアで使えるかどうかは置いておいて、とりあえずコモンズにアップロードしなさい、となるので)--Yaakiyu.jp (トーク) 2026-02-25T23:01:26 (JST)
  • 情報 昔は、記事のなかに YouTube を埋め込むことができました（YouTube#その他雑学 で今でも読み込まれていますが、これは例外）。そのころは、埋め込まれた YouTube の周りを目立つように黄色い線で囲って「これは外部から読み込んだ動画です。Enpedia のライセンスとは別に管理されています」（大意）というメッセージが表示されていました。........この理屈で問題なしと思われていたのですが、2019年に NexTone（JASRACと並ぶ音楽著作権管理団体）から警告があったため、安全を取って「埋め込み機能」が無効化されました。（相前後して YouTube の利用規約の改訂もあったような気がするが？　記憶があいまいだ）　← この経緯を記載したフォーラムは、おそらくないと思います。Discord の過去ログをあさって確認できました。（こういう仕様変更こそ「Enpedia:過去の出来事」や「エンペディア」などにメモしておくべきなのですが.....誰も書いていなかったようです。）-- BadEditor 2026-02-26T13:08:01 (JST)
    • 2019年4月28日に埋め込み機能が停止された経緯については、一応「利用者:篠田陽司/Enpedia (任意団体)#2019年度上期」の冒頭部分にその経緯の一端が書いてあります。◆ちなみに、機能が停止して以降は、ページ内に動画を埋め込みたい場合は Enpedia:管理者への依頼 へ個別に「動画モード切替依頼」を提出依頼するシステムになりましたが（Special:diff/205242）、実際にこの依頼が提出されたのは、おそらく2020年11月8日の Good-flavor さんの依頼一件のみ。しかもそれも、2024年にrxyさんにより却下されていて（Special:diff/879850）、使われた実績は現在までゼロ件。なんなら、それを最後に Enpedia:管理者への依頼 のページから「動画モード切替依頼」のセクション自体が自然消滅していて、フォーラム:特殊な操作の依頼 へも継承されず、現在に至るっていう感じだと思います。私の知る限りでは。--Written By 360度 (Talk) 2026-02-26T16:16:34 (JST)
      • 分かりやすいまとめ、ありがとうございます👍️-- BadEditor 2026-02-26T17:10:44 (JST)
  • これはHTMLにcommonsのURLが入るだけらしいですので、著作権は問題ありません、たぶん。--RevPi 2026-02-27T07:58:22 (JST)
  • コメント 著作権やライセンスはクリアしていてもEnpediaに投稿することができない画像、たとえば即時削除の14に該当するような画像をInstantCommonsで使用された場合はどうでしょうか。Google AdSenseのポリシーを考えると、アップロードそのものだけでなく、ページに当該画像が表示されること自体が問題になるかもしれません。この場合、おそらく版指定削除で該当版を権限保持者が削除しなければならない可能性もあると思います。画像のアップロードと違い、IP利用者でも新規利用者でもファイル名さえ分かれば即座に画像を表示できてしまう以上、悪用された場合のリスクは大きいと懸念します。特に、広告収入が主な収入源であるEnpediaにとって、それなりに影響が大きいのではないでしょうか。
また、当初から気になっているのですが「InstantCommonsを導入することで面倒くさい手順を省略できる」という点について、私自身は最も面倒で重要な作業は「ライセンス情報の確認」だと考えています。コモンズでライセンスが提示されているからといって、それを常に鵜呑みにし、正しさの担保までコモンズに押し付けるのは少々危険ではないでしょうか。自ら撮影した画像であっても、第三者の権利（著作権や人格権など）を侵害していないかどうかを確認する必要がありますし、第三者がアップロードした画像であればなおさら慎重に確認すべきだと思います。そういった意味では、InstantCommonsにより享受できるメリットはEnpediaのサーバを圧迫しないという点が中心であり、手軽さはそれほど変わらず、むしろ管理側の負担は変わらないか大きくもなり得るのではないか、という印象を受けました。
ほとんど杞憂に近い意見ですが、Enpediaの規模を考えたうえでは安全側に倒しておいてもよいのではないかと思います。もし導入するのであれば、リスクを吸収できる仕組みをあらかじめ設けたうえでの導入が望ましいと感じています。--EJ204 (トーク) 2026-02-28T11:20:56 (JST)

返信 EJさんの懸念点、「事故が起きた場合のリスク管理」は、サイト運営を考える上で重要な視点だと思います。

ただ一方で、いくつか整理したい点があります。
まず、Wikimedia commonsにも、確かに即時削除の方針の14に準する、画像は含まれていますが、これらは「該当医学的な性器画像、戦争や事故の記録写真、芸術的裸体、社会運動の現場写真」です。上記の画像たちは、百科事典的文脈においては正当な説明資料となり得るものです。センシティブではありますが、教育的・記録的価値があるという理由で掲載されているものであり、即時削除14に該当するような露骨なポルノや単なる猟奇画像とは明確に区別されるべきものだと考えています。
Wikimedia Commons は世界的に運営されているサイトであり、削除体制・管理体制はEnpediaよりもはるかに大規模かつ体系化されています。明確にポリシー違反となる画像が長期にわたり放置される可能性は低いと言えるのではないでしょうか。
また、「Commonsに身を委ねるのは危険」という点についてですが、具体的にどの部分がどのように危険なのかを、もう少し明確にしたいと感じています。

私が考えられる可能性は以下の3点です。

  1. 違法画像が表示される可能性
  2. 日本法上パブリックドメインでない画像の問題
  3. 広告ポリシーとの衝突
もし広告ポリシーの問題であれば、それはInstantCommons固有の問題というより、「百科事典としてどこまでの表現を許容するか」という運営方針全体の問題にも関わるのではないかと思います。ローカルアップロードであっても、同種の画像は理論上掲載可能であり、構造的なリスクは本質的に同じとも言えます。

さらに、InstantCommonsを導入しない場合でも、現在は利用者がCommonsから画像をダウンロードし、ローカルに再アップロードしているケースがあります。その場合、Commonsの判断を事実上信頼している点は同じであり、「参照か再アップロードか」という技術的違いに過ぎないとも考えられます。むしろ、再アップロードの過程でライセンス記載ミスなどが発生するリスクの方が現実的ではないでしょうか。

もちろん、悪用リスクや広告停止リスクを完全にゼロにすることはできません。しかし、「ゼロではないリスク」を理由に全面的に否定するのか、それとも一定の対策（表示ラベル、ガイドライン整備、削除フローの明確化など）を前提に運用可能性を探るのかは、別の議論ではないかと考えています。

もし具体的に想定されているリスク事例があれば、それを共有していただければ、対策の可否も含めてより建設的な議論ができるのではないでしょうか。--❄ Mr.sirokuma（トーク 🐾 投稿記録 / 架空鉄道Wiki・トーク ） 2026-03-01T12:30:40 (JST)

    • 返信 EJ204です。ご丁寧な整理ありがとうございます。私が懸念している点がうまく伝わっていなかった部分もありそうなので、少し項目を分けて補足させてください。
      • まず、即時削除14とコモンズのセンシティブ画像についてですが、コモンズに「百科事典的文脈では正当な資料となり得る」センシティブ画像があること自体は理解していますし、その存在を否定したいわけではありません。一方で、Google AdSenseについて解説しているページによれば、その画像が医学的な内容を含むものであってもNGと判断されるおそれがあるとされています。つまり「世界的な規模で管理・運営されているコモンズ由来だから」あるいは「医学的・学術的な目的だから」という評価はそのまま問題がないというわけではなく、最終的にはGoogle AdSenseがどう判断するかという問題になります。評価軸が異なるもの同士を同じ基準で安全だとみなすことはできないのではないか、というのが私の考えです。その上で、Google AdSenseが判断する項目にアップロードの有無ではなく表示の有無もあるのではないか、という懸念もあります。そして、そもそも方針のやってはいけないことの項目に「著作権を侵害する情報や他者の信用を傷つける情報、わいせつ物、その他の違法な情報を投稿すること、」として記載されており、これを遵守している限りAdSenseのポリシー違反との整合はできるのではないでしょうか。
      • 次に、ローカルアップロードとの構造が「本質的に同じではないか」という点についてです。確かに、現状でも利用者がコモンズから画像をダウンロードし、ライセンスを確認したうえでローカルにアップロードする運用は行われています。その意味ではすでに現状でもコモンズを前提にした運用が行われているわけで、その点自体は否定していません。ただ、その場合でも移入元のコモンズ側で後から何らかの問題が発覚する可能性はありますし、現在の運用自体もリスクを孕みうる行為であると考えています。一方、ローカルアップロードの利点として、著作権以外の権利を侵害していない前提であれば、何らかの理由でコモンズ側で削除されたとしても、適法に移入されたコンテンツがEnpedia側に残ることはむしろメリットとも言えます。適法にライセンスされていたものは、原則として遡って無効とすることはできないからです。サーバ容量も無視できない問題ですが、であれば一定期間使用されていないファイルは除去するなど、スタッフによって機能を追加しなくともコミュニティだけで対応できる施策を検討することもできるのではないでしょうか。
      • ローカルアップロードとInstantCommonsにおいて、私が大きな違いだと感じているのはローカルアップロードが自動承認された利用者以上に限られているのに対し、InstantCommonsはその制限がなく、IP利用者や新規利用者でもファイル名さえ分かれば即座に画像を表示できてしまう点です。ゼロリスクでなければだめだと言うつもりはありませんが、仮に悪意を持って使用された場合のリスクの大きさを、どこまで許容できるのかという問題だと考えています。
      • 「一定の対策を前提に運用可能性を探るのかは、別の議論ではないか」とのご意見もありましたが、私は導入前の時点でリスク評価を行うべきだと考えています。少なくとも、導入前にどのようなリスクがあり、それを運用でフォローできるのか、それともリスクが大きすぎて導入すべきでないのか、という評価は行う必要があります。そしてそのためにはメリットだけでなく、考え得るデメリットも同じように材料として議題に挙げることが公平な議論につながると考えます。その上で、私は、ベネフィット（利便性）よりもリスク（AdSenseや悪用の件）の方が大きいと感じており、それをあいまいなまま導入することはできない、という見方をしています。一見は百聞に勝りますが、それだけ力がある情報であれば取り扱いは慎重になるべき、と考えます。--EJ204 (トーク) 2026-03-02T19:05:42 (JST)


返信　現在の議論ではInstantCommons特有のリスクと一般的な表示リスクが区別されていないため、まずその点を整理します。

まず、AdSenseとコモンズの基準が異なる点についてはその通りだと思います。「コモンズで許容されている＝AdSenseでも問題ない」とは言えません。ただし問題は、それがInstantCommons固有のリスクかどうかだと考えます。AdSenseが判断するのはアップロード経路ではなく表示内容である以上、ローカルアップロードであっても同じ画像が表示されていれば評価上のリスクは本質的に変わらないのではないでしょうか。現状でもコモンズ由来の画像をローカルに移入して表示している以上、表示を前提としたリスク構造は既に存在していると考えます。
次に、「表示そのものがリスクではないか」という点ですが、これもInstantCommons導入によって初めて生じるものではなく、現行運用でも同様に成立します。AdSenseとの整合を図るのであれば、即時削除基準やコンテンツ方針を明確化することで対応すべきであり、導入の是非とは切り分けて検討できる問題ではないでしょうか。
ローカルアップロードの利点についても理解しております。適法に取得されたライセンスが原則遡及無効にならない点はその通りです。ただし、コモンズ側で問題が発覚した場合にEnpedia側だけに残り続けることは、管理負担や説明責任を増やす側面もあります。必ずしもローカルが一方的に優位とは言い切れないと考えます。
また、IPや新規利用者が即座に画像を表示できる点についてですが、これは技術的に制御不能なものではありません。不正利用フィルター（AbuseFilter）を用いれば、未自動承認利用者による外部画像の呼び出しを制限することは可能です。ローカルアップロードが自動承認利用者以上に限定されているのと同様に、InstantCommonsの利用条件も運用で引き上げることができます。
したがって、「IPでも表示可能である」という一点のみで構造的に危険と判断するのはやや過大評価ではないかと考えます。リスクは確かにありますが、重要なのはゼロかどうかではなく、管理可能かどうかではないでしょうか。
導入前にリスク評価を行うべきという点には同意します。その上で、現時点で挙げられている懸念は、技術的・運用的に一定程度コントロール可能であり、直ちに導入不可とする決定的な理由にはならないと考えております。--❄ Mr.sirokuma（トーク 🐾 投稿記録 / 架空鉄道Wiki・トーク ） 2026-03-03T15:55:07 (JST)
A. エッチな画像、グロテスクな要素を含む画像、人によって不愉快になる画像などのことですが、特に定義はありません。たとえば「ゴキブリ」の画像にこのテンプレートを使ってあげると、読者に優しいのではないでしょうか。
Q. そもそも、エンペディアにはポルノ画像・グロ画像をアップしてはいけないのではありませんか？
A. 露骨なポルノ画像・グロ画像は削除の対象になりますが、何もかも全てを禁じるルールはありません。じゃあ「露骨なもの」と「そうでないもの」の線引きってどこよ？　と聞かれたら、過去のエンペディアンたちは全く気にしてこなかったので、特に基準がありません。

テンプレート:センシティブな画像から引用。--❄ Mr.sirokuma（トーク 🐾 投稿記録 / 架空鉄道Wiki・トーク ） 2026-03-12T13:32:15 (JST)

  • 横槍>一定期間使用されていないファイルは除去する
削除しても裏では残っているので、サーバー容量の削減にはなりません。完全に削除するにはスタッフさんにやってもらう必要があり、手間が大きいです。--RevPi 2026-03-03T16:00:31 (JST)
  • Yaakiyu.jpです。前回僕がここに書き込んでからしばらく時間が経ってしまいましたが、その間に議論されていた点などについて自分の意見を述べます。
  1. Google Adsenseの規約について
    • Adsenseを利用するサイトが従うべきパブリッシャー向けコンテンツポリシーには、性的に露骨なコンテンツ(sexually explicit content)が含まれています。が、そもそも「どこからが露骨なのか」が曖昧ですし、「違反したら即アカウント停止なのか」も曖昧です。
    • これについてポリシーの解釈がどうなるのか、コミュニティで聞いてみたのですが、論点をずらされて有効な回答が得られませんでした。他の質問も確認してみましたが、「ウィキサイトは基本的にネット上の他のサイトから集めた情報を載せる場所であるため広告審査に通らない」というのが一般的な状況のようです。(参考)
    • Enpediaが最初にAdsenseによる広告表示を開始した頃と比べると相当状況が変わっているのでしょう。このようなオリジナルコンテンツに対する厳しい条件にEnpediaが適合しているとは考えられませんから...
    • 以上の調査が何を意味するかというと、「一度Adsenseを止められてしまうと再開するのは非常に難しい」ということです。安全を取るのであれば、性的なコンテンツは一律禁止としたほうが良いのかもしれません。
  2. InstantCommonsの悪用のリスクについて
    • 悪用のリスク自体は避けようのない問題です。現在例示されているような「広告ポリシー違反の画像をわざと表示する」ものの他にも、「動画等のサイズの大きなファイルを大量に表示させてサイトに負荷をかける」といった行為も想定されます。さらに、不正利用フィルターは管理者しか編集できず、日々増えていくコモンズの画像に追従し続けるだけの人的リソースがエンペディアには不足していると感じています。
    • そこで、簡単かつ確実な悪用対策が一つあります。「コモンズ上にある、広告ポリシー違反となり得る画像と同名のファイルをエンペディア上で作成する」ことです。技術的には、ファイルリダイレクトを用いてそれらのファイルページを「この画像は禁止されています」と表示された画像に転送させることで可能です。この方法ならば、自動承認された利用者全員が悪用防止に協力することができ、さらに(直接MediaWikiのシステムを利用することになるため)フィルターによる防止よりも高速に処理できることが期待されます。
      • これは、将来的にbotによる運用を行うことを想定しています。コモンズで特定のカテゴリを指定し、そのカテゴリ内に含まれる画像全てを自動追従して悪用防止リダイレクトを作成する、といった流れで運用することができます。
    • 悪用防止リダイレクトを作成したあとにコモンズの画像が変更されてエンペディア上で利用できるようになった場合はリダイレクトの削除が必要になりますが、そのような場合は非常にまれでしょう。
  • 上記のシステムはあくまで一例ですが、この程度の対策を行えばInstantCommonsは利用可能であり、そのリターンはリスクに見合っている、もしくはそれを上回っていると考えています。--Yaakiyu.jp (トーク) 2026-03-12T08:42:45 (JST)
    • 悪用防止リダイレクト、いいですね！なんですが、「ファイル名前空間のリダイレクトページ作成」は自動承認がいらないので、正常な画像呼び出しを妨害できる可能性があります。--RevPi 2026-03-13T07:54:59 (JST)
      • 返信そうなんですか!?ファイルアップロードが自動承認されたユーザーだけだったので、リダイレクト作成も同じだと思ってました...
      ならこの案はあまり意味がないかもしれませんね。--Yaakiyu.jp (トーク) 2026-03-13T13:59:50 (JST)
      • まあ、「未承認利用者のファイル名前空間のページ作成を禁止する」とすればなんとかなるのでは…？--RevPi 2026-03-13T20:51:58 (JST)

課題[編集]

yaakiyu.jpさんがとても丁寧にまとめてくださったので、それを参考に課題をリスト化しました。編集どうぞ。

  • EPのライセンスの方針
  • 済適用されず問題なし
  • その他方針・公式文書
  • 法律
  • あまり問題になることはない
  • だってエスケープ転載は今違法
  • 日本の著作権法で使えない画像の削除が必要
  • 管理
  • 管理者諸氏の負担が増える可能性
  • ライセンス不適合ファイルの対処
  • commonsにあるけどEnpediaの方針でNGなものの対処
  • サーバーへの負荷
  • 済

--RevPi 2026-02-26T07:51:07 (JST)

  • 返信(2026:02-26T07:51:07時点での版宛) サーバー負荷については、私が調べた限りですが、「プライマゼロ、プラスになる可能性もある」と感じました。
まず、「Wikimedia commonsのAPIをいちいち叩くため、負荷がかかる」という点ですが、これはほとんど気にならない程度の負荷しかかからないと判断致しました。
これはなぜかというと、'MediaWikiにはキャッシュ機能があり、これを異常な回数で破棄、またはひとつのページに一気に100枚の画像を貼り付ける等という行為を行わなければ、まずそよ風程度の負荷しかかかりません。かかったとしても、数秒の画像表示の遅延程度です。
また、「プライマイゼロ」という表現をした理由としては、個々で画像をアップロードすることに比べ、CPUの負担が減るという事にあります。これはどういうことか言うと、通常、画像をアップロードして、リサイズする場合、リサイズする時に少し負荷がかかってしまいます。ですが、Instantcommonsを使用すれば、リサイズ等の画像処理は全てcommons側がやってくれる為、負荷軽減になる。という点からです
以上の点から、サーバーへの負荷は「限りなく少ない。または、逆に軽減になる可能性」もある、というのが私の結論です。どうか、議論の参考にしていただければ幸いです。よろしくお願い致します。--❄ Mr.sirokuma（トーク 🐾 投稿記録 / 架空鉄道Wiki・トーク ） 2026-02-26T22:55:13 (JST)
  • 返信(RevPiさん宛) 課題に「管理者への負担が増える可能性」と書かれておりますが、これはなぜそう思ったのでしょうか。お聞かせ願いたいです--❄ Mr.sirokuma（トーク 🐾 投稿記録 / 架空鉄道Wiki・トーク ） 2026-02-27T22:14:28 (JST)
    • おそらく僕が言及しているからですね。日本国内でPDではない画像について削除対象とする案の中で「ただし、管理者の皆様方の負担がある程度増えてしまう可能性があります。」と述べています。--Yaakiyu.jp (トーク) 2026-02-27T23:44:32 (JST)
      • 返信 申し訳ありません、その点を見落としておりました。
その上で一点申し上げたいのですが、私は、「InstantCommonsを導入した場合、ローカルへの画像アップロード自体が減少する可能性が高い」と考えられます。
現在は、
  1. コモンズで画像を探す
  1. ダウンロードする
  2. ライセンス情報を確認する
  3. ローカルに再アップロードする
という工程が必要ですが、InstantCommonsがあればこの再アップロード工程が不要になります。
その結果、
  1. ローカルに蓄積されるファイル数が増えにくくなる
  2. 管理者によるライセンス確認や削除対応の対象件数が減少する
  3. ライセンス記載ミスや不備への対応も減る
といった、管理作業の母数自体が減る可能性もあります。
確かに、日本法との整合性の問題などで一定の確認作業は必要になるかもしれません。しかし一方で、「ローカルアップロードが減ること:による負担軽減」という側面もあるのではないでしょうか。
管理負担が増える可能性だけでなく、「減少する可能性も併せて検討すべきではないか」と考えます。--以上のコメントは、Mr.sirokuma (トーク) さんが投稿したものです。
      • ライセンス不適合ファイルの対処は一時的ではありますが、なにせ数が多いので、膨大な作業が必要かもしれません。ライセンス記載ミスや不備への対応が減っても、それ以上に増える可能性があります。また、commonsにも日夜画像がupされているので、対応に終わりはありません。--RevPi 2026-02-28T11:01:31 (JST)
      • Youtubeの時みたいに「これはWikimediacommonsより呼び出されています。本文とはライセンスが異なる場合があります。」みたいに出せたらいいんじゃないですかね。--RevPi 2026-02-28T13:33:24 (JST)
「https://enpedia.org/w/index.php?title=フォーラム:InstantCommonsを導入したい&oldid=1184917」から取得