ものになるモノ、ならないモノ(21)マッシュアップの落とし穴。
誰がために結び付けるのか
山崎潤一郎
2007/12/25
WEB 2.0ブームとともにWebサイト運営者の間で一般化し、多くの人気サービスを生み出した「マッシュアップ」によるWebサイト構築手法。そんな構築手法に警鐘を鳴らす出来事があった
音楽CD交換コミュニティとして、2007年1月から運営を開始した「diglog」は、Amazon Web ServicesからAPIの停止、加えてアマゾン・アソシエイト・プログラムの契約解除を受けて、2007年9月末をもってサービス停止に追い込まれた。
diglogは、サービスの根幹となるCDのデータベース情報をAmazon Web Servicesが提供するAPIに依存していると同時に、収益の多くの部分をアマゾン・アソシエイト・プログラムに頼っていたために、サービスを停止せざるを得ない状況に至ったのだ。
時間を超越した多対多のCD物々交換コミュニティ
この問題を理解するためには、diglogが提供していたサービスの概要を知る必要がある。diglogを一言でいえば、CDの物々交換を仲介するサービスだ。
登録ユーザーは、所有するCDのリストをサイト内に作成する。その際、CD検索に使われているのが、Amazon Web Servicesから取得していたCDのデータベース情報だった。
ユーザーは、所有するCDリストと同時に「欲しいCD」のリストも同時に作成する。すると、全ユーザーの「所有CD」と「欲しいCD」との間で自動的にマッチングが行われ、マッチングが成立した時点で所有者に通知があり、diglog側が用意する郵送キットを利用してCDを送付するのだ。
ただ、単に「欲しい」と「所有」のマッチングといっても、一対一の交換を仲介するだけでは、リアルな物々交換をしているのと大差なく、ネットのコミュニティの特長を生かし切れない。マッチングした者同士、お互いが双方の欲しいCDを、そのタイミングで所有している可能性は低く、マッチングそのものがほとんど起きない可能性があるからだ。また、たとえほかのユーザーが所有していたとしても、三角関係の物々交換になり話が非常にややこしくなる。
そこで、diglogでは「もらえる権利」という仕組みを導入した。例えば、Aさんの「所有CD」とBさんの「欲しいCD」との間でマッチングが成立し、AさんからBさんにそのCDが送付されたとする。Bさんは、それで満足だが、Aさん側の「欲しい」CDをBさんはもちろん、ほかの誰も所有していなかった場合は、Aさんは、取られ損ということになる。
そこで、Aさんに「もらえる権利」を付与する。将来、ユーザーの誰かがAさんの「欲しい」CDを登録した時点で、Aさんはその「もらえる権利」を行使できるという仕組みだ。
ネットのコミュニティとCDのデータベースを巧みに利用し、時間を超越した多対多の物々交換コミュニティを作り上げた秀逸なサービス、それがdiglogだったというわけだ。
音楽著作権や著作隣接権には抵触していない
アマゾンから契約解除通知があってから、閉鎖に至るまでの経緯やdiglog側の対応は、「アマゾンによるCDデータ提供打切りについて」に示されている。アマゾン側は、契約解除の理由として、Amazonアソシエイト・プログラム運営規約の「4. 紹介料」の項目に違反しているとdiglogに通知している。
しかし、この項目を詳細に読んでも、どの部分がdiglogサービスの何に違反しているのかは、よく分からない。diglogを運営していたムニンワークスの松井俊輔氏も「アマゾンの主張が理解できない」と困惑する。
これに対しアマゾンジャパンの広報は、この件に関する筆者の問い掛けに対し、「各個別案件についての詳細な説明は控えさせてもらう」とにべもない。ただ、「アソシエイト・プログラムは、アソシエイトに参加しているウェブサイトからAmazon.co.jpへトラフィックを誘導し、販売を促進するプログラム。このサービスの趣旨に違反する態様でのアソシエイト様のサービス利用はお断りしている」と付け加えていることから、次のような停止理由が想像できる。
まず思い浮かぶのは、音楽関連サービスという点で、CDの物々交換という仕組みが、著作権や著作隣接権に抵触しており、その部分が大きな理由なのではないかという可能性だ。
しかし、diglogサービスに関して日本音楽著作権協会(JASRAC)送信部の小島芳夫氏は、「オークションなどでもCDのやりとりはされている。それと同じ考え方で、譲渡権の消尽により著作権は及ばない」とコメントしており、著作権的には問題はなさそうだ。また、譲渡権の消尽したCDをやりとりしているわけだから、著作権と同様に、著作隣接権の面でも問題があるとは思えない。
アルバムのカバーアートにも権利があり、そこに問題が!?
ここで気になる点が1つある、それはアルバムのカバーアートだ。diglogでは、CDがリスト表示される際、タイトルなどと同様にアマゾンのAPIから引いてきたカバーアートも表示されていた。
カバーアートは、レコード会社やアーティストが権利を有するれっきとした著作物。それをサイト上に表示し自社ビジネスに利用するとなると、各権利者の許諾が必要となる。現に、CDジャーナルやAMGデータベースといった商用で提供されている音楽データベースをネットで利用する場合、「カバーアートの許諾は各権利者から取る」ことが要求される。
diglogでは、サイト上に表示されるカバーアートの許諾は取っていなかったということなので、権利者の側がそれを問題にしたのかもしれない。あるいは、アマゾンの側で問題になる前に手を打ったとも考えられる。
それ以上に、diglogが提供していたCDの物々交換というモデルも問題だったのだろう。CDの流通・販売エコシステムの受益者の側から見ると、このモデルが「敵」と思われても仕方ない。物々交換ではないが、例えば、ブックオフが登場したときは、既存の出版流通や販売の側から大きな反発があったようにだ。
diglogの契約解除の背景には、このようなCD販売側からの反発があったと考えることができる。ましてや、アマゾンがAPIで提供しているCDのデータベースが、前述のような商用のものが基になっているとすれば、アマゾンでお金を払って構築したデータベースを「敵」であるdiglogに無料で使わせて「塩を送る」道理はない。
その一方で、diglogは、物々交換サービスだけでなく、一種の音楽情報サイトとして、アマゾン・アソシエイト・プログラムを経由して「CDの販売にも貢献していた」(松井氏)のも事実。そういった貢献も、物々交換モデルという大きな問題の前では、評価されなかったということだろうか。
リスクを考えないで始めてしまった点が甘かった
ムニンワークスの松井氏は、今回のアマゾンの措置に対し「非常に残念」としながらも、「CDデータベースという、サービスの根幹を他社のAPIに頼ってしまったわれわれの考えの甘さが招いたこと。ユーザーの皆さまには申し訳ないことをした」と、自分たちに非があることを認めている。
また、「2006年11月にプレ公開サイトを作ってAmazon Web Servicesとアマゾン・アソシエイト・プログラムの申請を行い、それが承認された安心感から、このようなリスクを考えないで始めてしまった点も甘かった」(松井氏)とも付け加える。
ただ、アマゾン側も、diglogのプレ公開サイト(物々交換であることを明記)を確認した上で、Amazon Web Servicesとアマゾン・アソシエイト・プログラムを承認したわけだから、もし、問題があるのであれば、その時点で承認を出さなければよいと思うのだが……。そのあたりのチェックはどうなっているのか、アマゾン側がそれを教えてくれないだけに、真相は闇の中だ。
diglogを運営していたムニンワークスは、平均年齢24歳の大学時代の仲間3人が中心となって設立された京都のベンチャー企業だけに、今回のことは、「若さ故」といってしまえばそれまでだが、マッシュアップでサイトを構築することのリスクにもっと目を向けるべきであったのは確かだ。
API提供元とWin‐Winになるビジネスモデルが基本
APIの停止といえば、YouTubeから動画の提供を停止されたニコニコ動画の例が記憶に新しい。ニコニコ動画の場合は、その後、自社で「SMILEVIDEO(スマイルビデオ)」という動画インフラを構築することでサービスを継続したわけだが、これは、資本力のある東証一部上場企業ドワンゴを親会社に持っているからこその力業であり、稀有(けう)な例といえる。
特に、「YouTubeの切断から約1週間で立ち上げた」(ニワンゴの西村博之氏)というから、資本力はもとより、その人的パワーもベンチャーからするとうらやましい限りだ。
マッシュアップでサービスを構築する理由の1つに、資本力の乏しさを知恵と汗で補うという部分がある。だからこそ、ネットに新しい可能性を見いだした志のある若い人々が多くのマッシュアップサイトを生み出しているわけだ。しかし、今回のようなことがあると、リスクに神経質になるあまり、面白いアイデアが埋もれてしまう可能性もある。
ほかのマッシュアッパーは、リスクについてどのように考えているのだろうか。ネット上に点在する辞書や辞典を集めて、横断検索サービスを提供しているWeblioというサービスがある。これも大学を出たての若いベンチャー経営者たちが構築したサービスだ。ウェブリオ代表の辻村直也氏は、マッシュアップサイトのリスクについて次のように話してくれた。
「データ提供打ち切りのリスクについては、常に頭の中にある。しかし、Weblioの場合、元データの提供者(辞書や辞典のサイト)とは、直接交渉して許諾を得ているので、アマゾンやGoogleからAPI提供を受ける場合のような、無機質な関係とは少しニュアンスが異なる。ただ、お互いにメリットを見いだせる関係を築けるように心掛けている」(辻村氏)
さらに、「出張JAWS」で「Mash up Award 2nd」(サン・マイクロシステムズ主催)の最優秀賞を獲得したフェアリーウェア代表の黒田哲司氏は、「マッシュアッパーにとってはショックな事件」としつつも、「マッシュアップでサービスを作る場合は、APIの提供元とWin‐Winになるようなビジネスモデルを構築することが基本」と、diglogの甘さを指摘する。
diglogを閉鎖してしまったムニンワークスは、現在、「受託開発の仕事で食いつないでいる」(松井氏)状態だ。それと同時に、diglog再開に向けた努力を行っている。無料のAPIではなく、商用データベースを利用する道も模索しているようだが、資本力に乏しいだけに「黒字化するまで体力が持たないだろう」(松井氏)というのが、実情だ。
また、仮にdiglogをあきらめるにしても「次回も、自分たちの手で作ったサービスを事業の中心にしたい」(松井氏)と、新しいアイデアを温めている最中だという。そして、松井氏は、取材の最後に付け加えてくれた。「今度は、われわれはもちろん既存のビジネスも含めて、みんながハッピーになれるモデルを考えたい」と。
| 著者の山崎潤一郎氏は、テクノロジ系にとどまらず、株式、書評、エッセイなど広範囲なフィールドで活躍。独自の着眼点と取材を中心に構成された文章には定評がある。 近著に「株は、この格言で買え!-株のプロが必ず使う成功への格言50」(中経出版刊)がある。 著者ブログ 「家を建てよう」 |
ネットワークコラム:ものになるモノ、ならないモノ バックナンバー
- 第1回 社内ブログはナレッジマネジメントとして機能するか
- 第2回 1ギガ、本当に「現時点ではそんなもん不要」なのか?
- 第3回 ライブドア無線LANに疑問をぶつけてみました
- 第4回 IrDA、Bluetoothを反面教師にしたZigBeeの実力は?
- 第5回 月額1000万円が300万になる新・映像配信って?
- 第6回 一家に1つのレイヤ2ネットワークの時代はやってくるか
- 第7回 ネットの“あちら側”から迫る見えない亡霊をどうする?
- 第8回 Pマークは暗黒な大人社会の印籠以上になれるか?
- 第9回 API公開のずいぶん前からすでにWeb2.0でした
- 第10回 Webちらし、国産RSSリーダーと人工知能化の野望
- 第11回 国内の総合辞書検索屋への挑戦者、ウェブリオとは?
- 第12回 集合知の独自検索で真実を導く、Kizasi
- 第13回 マイクロフォーマット=Web2.0の真打ちとなるか?
- 第14回 電力線というありモノでLAN構築!の現在過去未来
- 第15回 FONはAP持ち寄り型のWiFiコミュニティを形成するか
- 第16回 セカンドライフと実社会の経済格差=100倍の価値は
- 第17回 次々と中小企業がネットビジネスから脱落する理由
- 第18回 プロバイダが考える安全なファイル転送のかたち
- 第19回 「はてな」を作り出す人的ネットワークの仕組みとは
- 第20回 携帯メールポータビリティは開国を迫る黒船となるか
- 第21回 マッシュアップの落とし穴。誰がために結び付けるのか
- 第22回 モバイルビジネスのオープン化はこれからが本番
- 第23回 ECネットワークは、ネット紛争の“遠山の金さん”
- 第24回 日本のインディよ! iPhoneにカワイイ系で打って出よ
- 第25回 iPhone 3Gでソフトバンクのネットワークが心配だ
- 第26回 「着うた」とiTunes Storeの直接対決はあるのか
- 第27回 モバイル「レイヤ2」の付加価値がもたらすメリットとは
- 第28回 2010年、本当にプロバイダビジネスは崩壊するのか?
- 第29回 Androidのオープン性でガラパゴスから脱出しよう
- 第30回 霞ヶ関も導入する!?クラウドの本質を理解する
- 第31回 ニッポンのiPhoneアプリヒットメーカーたちに続け!
- 第32回 WiMAXのカバー率が7割になった2010年を想像しよう
- 第33回 iPhoneSkypeとケータイ、通話に向いてるのはどっちだ
- 第34回 検索全盛の時代だから、ドメインの有用性を考えよう
- 第35回 2012年、2000万ユーザーが2カ所に集中するとき
- 第36回 iPhoneアプリに広告を挿入してガッチリもうけるのだ
- 第37回 iPhoneアプリ内課金導入でガッチリもうけるのだ
- 第38回 Androidアプリはビジネスになるのか
- 第39回 電子出版をめぐる4つの疑問
- 第40回 App Storeの運営方針は第2ステージへ
- 第41回 iPad、モバイルルータや電子書籍へのインパクトは?
- 第42回 フェムトセル無料配布で浮上した「ただ乗り」問題
- 第43回 インディ開発者よ、「ドコモマーケット」で稼ごうぜ!
- 第44回 「韓ドロイド」に見る1年後のAndroidアプリビジネス
- 第45回 エモーショナルな文字入力を可能にした「7notes」
TechTargetジャパン
- 実機では測定できない性能を測定? (2012/2/7)
システムの完成前に、達成し得る性能値や必要なサーバリソースを知るには? その解となる「性能シミュレーション技法」を解説 - 性能チューニング個所の検討 (2012/1/30)
アプリのチューニングや環境増強で、どの程度改善が見込める? 今回からは「実際に活用できる性能対策」を解説します - 遅いところを直すだけでいいのですか? (2012/1/24)
負荷が集中したときの性能ボトルネックを改善するのに、アプリケーションサーバとDB、どちらを優先すべきでしょう? - cloudfoundry.comを使ってみよう (2012/1/19)
VMwareが提供するPaaSプラットフォーム「CloudFoundry」。注目を集めるこの基盤を活用してPaaSを構築!
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -
