はじめに
セカンドライフは、オンラインゲームの類ではなく、3次元オブジェクトのレンダリング・ツール、モデリング・ツールであり、作成したオブジェクトを共有するための空間を提供するストレージ・サービスであると考えるべきです。そして、オブジェクトにLSL（Linden Scripting Language）と呼ばれる専用のスクリプト言語を実行させられる、一種のアプリケーション実行環境であるとも捉えられます。
ところが、経験あるアプリケーション開発者であれば、すぐにLSLが貧弱であまり実用的ではないということに気が付くでしょう。LSLは柔軟性に乏しく、簡単な計算と用意された関数の呼び出し、定められているイベントの実装程度の機能しか持ちません。クラスや構造体のようなユーザー定義型を作ることはできず、ポインタを使った多態性のあるコードを書くこともできません。
こうした制限からLSLはデータ処理に弱く、加えてサーバ環境で実行されることからデータサイズやパフォーマンスの面でも制限が多く見られます。スクリプトが確保できる変数の領域は16KBまでであり、関数を通して受け渡しする文字列のサイズや、サーバに負担のかかる関数の遅延などの制限もあります。
よって、LSLが対象としているプログラムは、オブジェクトを動かしたり、プログラムからオブジェクトのプロパティを変更したり、ちょっとした演出や効果といったものが中心となります。ビジネス・アプリケーションを考えた場合LSLの制限は大きな障害となるでしょう。
LSL単体では実現が難しい処理や膨大な情報量を扱う方法は、Webと連携することです。幸い、セカンドライフはネットワーク上の孤島ではありません。驚くことに、LSLはEメールの送受信、HTTPリクエスト、そしてXML-RPCによるサービスの公開が可能になっています。こうした機能を使えばWebサービスを通して間接的にデータベースや高度なビジネスロジックを利用できるようになります。
LSLは、オブジェクトからWebへの要求と、Webからオブジェクトへ要求という双方向通信が可能です。この機能を駆使することで、翻訳や辞書の問い合わせ処理といった複雑で膨大な情報を扱うプログラムをセカンドライフの世界で実現することができます。
なお、Eメールは唯一セカンドライフの外部と送受信の両方が可能な通信方法ですが、データの交換には適さないため本稿では割愛します。プログラム的なデータの交換では、セカンドライフから外部へ通信を行うHTTPリクエストと、外部からセカンドライフへ通信を行うXML-RPCを使います。
情報ソースをWebと共有する
最近は見かけなくなりましたが、一年ほど前からセカンドライフの世界に多くの企業が参入しているというニュースが流れています。Dell、IBM、トヨタ、日産といった大企業から、多くの中小企業も参入していますが、実際にセカンドライフに参入している企業の土地や店舗に行くと、自社ビルと看板を立てて満足してしまっている感が否めません。定期的な販促イベントが行われているのかもしれませんが、普段は閑散としています。
自社ビル、看板、商品テクスチャを貼るだけの静的なコンテンツではユーザーはすぐに飽きてしまいます。しかし、常に自分の土地にオンラインのアバターを配置し、新しい情報をセカンドライフの世界で発信し続けるのはコストがかかります。
こうした問題を解決するために、本稿では「セカンドライフ＋Web」によるコンテンツを管理を提案いたします。LSLを用いて定期的にHTTPリクエストを送りWebサーバから情報を取得する仕組みを一度作れば、情報の管理はすべてWebベースで行うことができるようになり、セカンドライフ内での情報更新をすべて自動化できます。
また、セカンドライフの世界のデータをWebサーバに送ることで、来客者数やコンテンツの利用者の情報などを集計することができます。加えて、セカンドライフの情報をブラウザなどで視覚化することもできるでしょう。セカンドライフ内のアバターとWebページの利用者がリアルタイムで同じ情報を共有することも可能です。
