MetaTweet の現状と展望Copyright © Takeshi KIRIYA (aka @takeshik), All rights reserved.

バージョン 0 (2009/10/11)　クリエイティブ・コモンズ 表示-改変禁止 2.1 日本 適用

この文章は http://metatweet.org / 上で最新版が公開されています。

現在 Twitter 上で精力的に活動している私ですが、ネットの内外を問わず現在特に力を入れているものとして、比較的大規模なソフトウェアの開発―MetaTweet プロジェクト―に取り組んでいます。プロジェクトの開始から決して短くない時間が経過し、また、その進捗も緩やかではあるものの確実に進み、未だ完成には至ってはいませんが既にバイナリをリリースできている段階にあります。しかしながら、このプロジェクトとソフトウェアの概要を知る文章に欠けている節がありました。そこで、本稿では現在私がまさに取り組んでいるプロジェクト、MetaTweet について紹介します。

MetaTweet とは何かMetaTweet は、その表面的な部分のみを捉えるならば、Twitter クライアントと呼ばれるカテ

ゴリに属するソフトウェアです。Twitter クライアントとは、Web サービスである Twitteriを、通常のアプリケーション、あるいは別の Web サービスから利用し、標準の Web インターフェイスよりも多くの機能を提供するソフトウェアを指し、現在日本及び世界で多くの Twitter クライアントが公開されています。

MetaTweet もまた、そのような機能を提供します。しかしながら、MetaTweet は単なるTwitter クライアントではなく、それ以上のものを提供するために計画・設計され、開発を行っています。そして、その方向性を端的に表すキーワードとして、 Intelligent Gateway と Hub

System を掲げています。即ち、単に Twitter という単一のサービスを「利用する」のではなく、あらゆるマイクロブログサービスを横断・横断して高度に処理する (インテリジェント) ことのできる「ゲートウェイ」であり、そしてサービスの中心として存在することのできる「ハブ」となる、単なるアプリケーションではない「システム」を目標に据えています。そして、MetaTweet

はその方向性、目標に見合うだけの、単なる Twitter クライアントとは異なった特徴的な設計を擁しています。

特徴MetaTweet は、以下の特徴を持っています。ここに挙げている特徴は、それぞれ既に本稿が書

かれた時点で既に実現されているものです。

クライアント・サーバモデルMetaTweet と他の一般的な Twitter クライアントとの最大の違いとして、MetaTweet がクライ

アント・サーバ (C/S) モデルを採用していることが挙げられます。MetaTweet システムはサーバとクライアントにより構成されます。サーバはコマンドラインアプリケーション、またはサービ

i Twitter (http://twitter.com) とは、2009 年現在世界最大のマイクロブログサービスであり、日本においても普及が進んでいる。詳細は割愛。

スやデーモンとして起動し、外部のサービスに接続してデータを取得・蓄積します。そしてクライアントは通常のアプリケーションとしてサーバから間接的にデータを取得し、ユーザに提示します。このモデルのメリットは、負荷のかかる部分、あるいは長時間に渡って運用される可能性のある部分をサーバとし、ユーザに対するインターフェイスをクライアントとして分離することにより、長時間の運用にも耐え ii、またパフォーマンスがユーザインターフェイスによって無駄に低下することを回避することができます。副次的な効果として、クライアントの選択が自由になり、携帯端末からサーバ上のデータを取得するといったことも可能となります。

データベースの利用私が常々考えていたことの一つとして、Twitter クライアントはコストを掛けてデータを取得し

ているのに、ソフトウェアを終了させるとそのデータが破棄されてしまうのは大いなる無駄ではないか？というものがありました。そして、それは非常に勿体ないことに映りました。また、少なくとも Twitter では、過去のデータを取得するのは現在のデータを取得するのに比べ困難です 。MetaTweet は、取得したデータの貯蔵先としてデータベースを採用しています。MetaTweet システムを停止させても、それまでに取得したデータは破棄されることなく、バックエンドのデータベースに保存されます。これにより、取得したデータをアーカイブ化することができ、有用に活用することが可能となります。

高度な抽象性・モジュールシステムMetaTweet はサーバ、(標準として用意される) クライアント共に高度に抽象化されています。

MetaTweet のサーバは単体では何の有用な機能も持たないまでに機能を削ぎ落とされています。外部サービスとの接続・データの取得、データの出力、クライアントとの通信、バックエンドのデータベースとの接続など、あらゆる機能は自由にロード・アンロードできるモジュールとして提供されます。クライアントはほとんどの機能が関数として定義され、キーバインド、メニュー項目、ユーザインターフェイスなどの主要な構造を自由に変更・追加することができます。この設計はあらゆるサービス・状況・用途に MetaTweet が対応でき、自由に機能を追加して拡張できることを意味します。

サービス中立かつ高度なデータモデルMetaTweet はあらゆるサービスに対応することが可能であり、さらにバックエンドにデータベ

ースを採用しているため、そのデータ構造はあらゆるサービスのデータ構造を表現できるように高度かつ抽象に設計されています。サービス上のあらゆる概念は統一的な構造として表現され、それらを横断的に扱うことができます。また、この設計は個々のサービスでは表現できない概念を付加し、より高度に蓄積したデータを利用することが可能となります。また、サービス中立な設計によりソフトウェアが特定のサービスに依存することを回避し、新規サービスの出現、あるいは既存サービスの消滅に対し強靱となります。そして、この MetaTweet のデータモデルは標準ライブラリのみで実装されており、他のソフトウェアからも容易に利用することができるものとなっています。

ii ユーザインターフェイスとロジックの分離という観点からも相応しいと考えます。

フリーソフトウェアMetaTweet はライセンスに GNU Lesser General Public License (GNU 劣等一般公衆利用許諾書)iiiを適用していますiv。つまり、MetaTweet はフリー (自由) ソフトウェアであり、なおかつオープンソースソフトウェアです。従って、誰でも MetaTweet を自由に実行し、頒布し、改変し、その改変を頒布することができます。MetaTweet のソースコードはインターネット上に公開されており、然るべき条件に従い自由に利用し改変することができます。

先進ユーザのための先進環境複数サービスへの対応、クライアント・サーバモデルの採用、あるいはデータベースの利用など、それぞれの特徴だけを挙げれば、同じようにその特徴を持つソフトウェアは確かに存在します。しかしながら、全体として上に上げたような特徴を全て具えるソフトウェアは MetaTweet

以外には存在しないのではないか、あるいは万が一あったとしても世界中に片手で数えるほど、と自負しています。

MetaTweet は誰でも使い始めることができるシステムを目指しますが、その提供するものは決して万人向けではないと考えています。他のソフトウェアには無い先進的な取り組みと、それら先進的な取り組みに魅力を感じる、他のソフトウェアでは満足できないユーザをメインターゲットに据えています。

開発言語および環境MetaTweet は C# 言語v バージョン 3.0 および Microsoft .NET Frameworkvi 3.5 によって開

発されており、開発環境として Microsoft Visual Studio 2008 を使用しています。Microsoft

Windows XP 以降での動作および開発を想定しています。また、計画として、サーバ部分をMonoviiにより Unix環境上で動作させることも長期的な目標としています。将来的には C# 4.0

および .NET Framework 4.0 に移行する予定です。MetaTweet は SourceForge.netviiiによってホストされており、Web サイト、ファイル公開、

ソースコードリポジトリなどの機能を利用しています。ソースコードは Subversion によってバージョン管理されています。

各種URI以下に MetaTweet に関する URI を示します。

MetaTweet 公式サイト

http://www.metatweet.org/

MetaTweet の公式Web サイト。

iii http://www.gnu.org/licenses/lgpl-3.0.html(日本語の参考訳: http://sourceforge.jp/magazine/07/09/05/017211)iv システムの一部に GNU LGPL 以外のライセンスを適用したコードや、第三者によるライブラリが含まれていますが、それら全てフリーソフトウェア/オープンソースソフトウェアの定義に合致するものです。v http://msdn.microsoft.com/ja-jp/vcsharp/default.aspxvi http://msdn.microsoft.com/ja-jp/netframework/default.aspxvii Mono Project (Novell) による .NET環境のフリーな実装 (http://www.mono-project.com/)。viii フリーソフトウェア/オープンソースソフトウェアプロジェクトのためのホスティングサービス(http://sourceforge.net/)。

MetaTweet プロジェクトページ

http://sourceforge.net/projects/metatweet/

SourceForge.net 上のプロジェクトページMetaTweet ソースコード Subversion リポジトリ

http://svn.metatweet.org/svnroot/metatweet/

Subversion バージョン管理システムによるソースコードの公開場所リポジトリ上には各種ドキュメントも存在します。

歴史MetaTweet の名が初めて登場したのは 2008 年 11月 24 日のことでしたix。もっとも、それ以前から Twitter のデータのアーカイブ化などのアイデアは既に浮かんでおり、Twitter クライアントの開発に参加したりする中で様々な手段による実現も考えていましたが、最終的には自分でTwitter クライアントを一から設計するのが最善であるという結論に落ち着きました。そのため、この時点で MetaTweet のあり方はおおかた既に決定付けられていました。そして同年の 12月15 日に SourceForge.net にプロジェクトを登録し、翌日、最初のコードをコミットして公開しました。

2009 年 2月 1 日に最初のバイナリリリースであるバージョン 0.1 を公開し、初めてシステムとして動作可能な状態となりました。現在は 6月 16 日にリリースされた 0.7 が最新のリリースで、バージョンを経る毎にシステムの設計も見直され、より洗練されたものとなっています。最後のリリースから大分間が開いてしまっていますが、現在も活発に開発が続いており、目下次のバージョンのリリースに向けて作業を行っています。

MetaTweet の構造MetaTweet を俯瞰する情報として、MetaTweet を大きく特徴付ける要素、モジュールシステムとオブジェクトモデルについて、やや技術的に踏み込んで解説します。

モジュールシステムMetaTweet の高度な抽象性・拡張性の源となるのがモジュールシステムです。モジュールは、

サーバによってロードされる、モジュールとしての機能を提供するインターフェイスを実装した型を含むライブラリとして定義されます。そして、更にその基本インターフェイスを実装するいくつかの抽象クラスが存在し、それによってモジュールはいくつかの種類に大別されます。

フロー (Flow) モジュールMetaTweet において、データの取得および蓄積は所謂パイプラインとしてモデル化されていま

す。即ち、外部のサービスからデータを取得 (入力) し、何段階かのデータ整形を経て、最後に任意の形式で出力を行う、というモデルです。フローモジュールはこの流れを担当するモジュールで、サーバで実行されるリクエストに基づき、サーバによって受動的に実行されます。そしてフローモジュールはそのパイプライン上での役割に基づき、更に 3 つに大別されます。即ち、外部のサービスや内部のデータベースなどからデータを取得してくる先端部分に当たるインプット

ix http://twitter.com/takeshik/status/1020632145

(Input) フロー、インプットフローから渡されたデータを加工・整形する中間部分に当たるフィルタ (Filter) フロー、最後にデータを任意の形式で出力する末端部分に当たるアウトプット (Output) フローです。サーバリクエスト内において、インプットフローおよびアウトプットは必ず 1 つ存在する必要がありますが、フィルタフローは 0 もしくは 1 以上存在することができます。

上において (サーバ) リクエストとは、サーバの内外で発行される、フローモジュールによるデータ処理の実行を要求するためのデータ構造で、URI に類似した文字列で表すことができます。リクエストは、実行するフローモジュール毎に、利用するストレージモジュール (後述)、フローモジュールの名前および実行する処理の名前 (セレクタ)、およびモジュールに渡す引数のセットを連結させた物として定義されます。

以下はリクエストを表す文字列の例です:

/!twitter/statuses/home_timeline?count=100/!/.xml?encoding=utf-8

これは、twitterとして表されるインプットフロー内の/status/home_timeline という名前の処理に count=100という引数を渡し、その結果を、同じ twitterとして表される (/!/ は前と同じ名前のフローを用いる省略記法です) アウトプットフロー内の /.xmlという名前の処理に encoding=utf-8 という引数を渡し、その出力を処理全体の結果とするものです。

サーバント (Servant) モジュールサーバントモジュールは、サーバ内で継続的な動作を行うためのモジュールです。サーバント

モジュールは、その動作として開始および停止が定義されており、それ以外の動作の内容については特に定義されておらず自由です。主な用途として、タイマ処理による一定時間毎・特定時間のリクエストの送出、Web サーバや MetaTweet クライアントとの通信といったネットワークサービスの実行、データストリーミングの入出力などが想定されています。

ストレージ (Storage) モジュールストレージモジュールは、MetaTweet のバックエンドとなるデータベースおよび、データベー

ス上のデータをソースとする汎用データモデルであるストレージオブジェクトを管理するモジュールです。ストレージモジュールはフローモジュールの入出力として用いられることでサーバリクエストを構成します。

ストレージモジュールは、MetaTweetオブジェクトモデルにおけるストレージのラッパです。MetaTweetオブジェクトモデルおよびストレージについては後述します。

以上の 3 つがモジュールの種別となります。MetaTweet のモジュールは基本的には上の 3 つのどれかに属することとなります。

モジュールマネージャMetaTweet サーバにおいて、モジュールを管理するシステムがモジュールマネージャです。モ

ジュールマネージャは、モジュールを含むライブラリのロード及びアンロード、モジュールオブジェクトの生成および破棄を担当します。

モジュールは基本となるインターフェイスを実装するクラスであり、実際に使用する際には通常のクラスと同様にオブジェクトを生成する必要があります。モジュールマネージャはモジュー

ルであるクラスから実際にモジュールオブジェクトを生成し、識別可能な名前を付け、その名前およびモジュールの型からモジュールオブジェクトを検索するといった機能を提供します。

オブジェクトモデルMetaTweet はサービス中立のソフトウェアであり、データのアーカイブ化に主眼を置いており、

その保存のためにデータベースを採用しています。つまり、MetaTweet のデータ構造は厳密かつ抽象に定義される　必要があることを意味します。

MetaTweet で使用されるデータ構造は MetaTweetオブジェクトモデルと称されるもので、その操作はオブジェクト指向に基づいています。従ってオブジェクトモデルは O/R マッピングの機能を内包しています。当初は ADO.NET DataSet によるデータ構造に独自の O/R マッパを実装していましたが、効率性、安全性、将来性の観点からこれを放棄し、10月 3 日 (リビジョン 373)

に O/R マッパに ADO.NET Entity Framework を採用し、また同時にデータベースの構造もより抽象度の高い設計に改めました。10月 8 日 (リビジョン 378) には旧来のデータ構造を破棄し、オブジェクトモデルの完全なリプレースを達成しました。現在は各種モジュールを新しいデータ構造に適合させるためにコードを書き直している状況です。本稿ではこの新しいオブジェクトモデルに基づき解説を行います。

MetaTweetオブジェクトモデルは、2 つの基本となるデータ構造と、それらの関係をタグ付けする 5 つのデータ構造、計 7 つのテーブル/オブジェクトによって構成されます。

アカウント (Account)アカウントは、MetaTweetオブジェクトモデルの頂点となるデータ構造で、個々のサービス毎

のユーザを表現します。現実に同一のユーザであろうとも、サービスが異なれば別のアカウントとして表現されます。

アカウントは以下によって構成されます:

アカウント ID (AccountId)

(サービス単位ではなく) アカウント全体で一意なグローバル一意識別子 (GUID)。 レルム (Realm)

アカウントが所属しているサービスを表す文字列。アカウントは、アカウント ID によって識別されます。

アクティビティ (Activity)アクティビティは、アカウントによって行われた、あるいは関連した行動や情報を表します。例えば、ユーザの登録、名前の変更、プロフィールの変更、各種投稿行為などが含まれますが、これに限られません。アクティビティは累積的に記録されます。つまり、データはある時点での最新のデータのみが保持されるのではなく、古いデータと併存する形で新しいデータが追加されていきます。これにより、ある時点でのユーザの情報を取得したり、あるいはユーザの情報を追跡したりといったことが可能となります。

アクティビティは以下によって構成されます:

アカウント (AccountId)

アクティビティが行われた主体となるアカウント。 タイムスタンプ (Timestamp)

アクティビティが行われた日時。 カテゴリ (Category)

アクティビティが表す情報の分類を表す文字列、例えば投稿、名前 (の変更)、ユーザ画像 (の変更) など。

サブ ID (SubId)

上に挙げた 3 つの要素だけで一意にアクティビティを識別できない場合に設定される他、投稿などに付与される一意の ID を表す文字列。

ユーザエージェント (UserAgent)

アクティビティが行われたソフトウェア (クライアント) を識別する文字列。null許容。 値 (Value)

文字列で表される、アクティビティの持つ情報。null許容。 データ (Data)

バイト配列で表される、アクティビティの持つ情報。null許容。アクティビティは、アカウント ID、タイムスタンプ、カテゴリ、サブ ID によって識別されま

す。

この 2 つが MetaTweetオブジェクトモデルにおける中心的なデータ構造です。次に挙げる 5

つのデータ構造は全てこの 2 つのデータ構造に対するメタ情報を表現します。

アノテーション (Annotation)アノテーションは、アカウントに対する文字列によるメタ情報を表します。アノテーションは以下によって構成され、また、以下の全てによって識別されます:

アカウント (AccountId)

アノテーションを付与するアカウント。 名前 (Name)

付与する追加情報を表す文字列。

リレーション (Relation)リレーションは、あるアカウントと、別のアカウントとの関係と、その関係を表す文字列によ

るメタ情報を表します。リレーションは以下によって構成され、また、以下の全てによって識別されます:

アカウント (AccountId)

リレーションを付与する一方のアカウント。 名前 (Name)

付与する関係を表す文字列。 他方のアカウント (RelatingAccountId)

リレーションを付与される他方のアカウント。

マーク (Mark)マークは、あるアカウントと、あるアクティビティとの関係と、その関係を表す文字列による

メタ情報を表します。マークは以下によって構成され、また、以下の全てによって識別されます:

アカウント (AccountId)

マークを付与するアカウント。 名前 (Name)

付与する関係を表す文字列。 アクティビティ

(MarkingAccountId, MarkingTimestamp, MarkingCategory, MarkingSubId)

マークを付与されるアクティビティ。

リファレンス (Reference)リファレンスは、あるアクティビティと、別のアクティビティとの関係と、その関係を表す文字列によるメタ情報を表します。

リファレンスは以下によって構成され、また、以下の全てによって識別されます:

アクティビティ (AccountId, Timestamp, Category, SubId)

リファレンスを付与するアクティビティ。 名前 (Name)

付与する関係を表す文字列。 別のアクティビティ

(ReferringAccountId, ReferringTimestamp, ReferringCategory, ReferringSubId)

リファレンスを付与されるアクティビティ。

タグ (Tag)タグは、アクティビティに対する文字列によるメタ情報を表します。タグは以下によって構成され、また、以下の全てによって識別されます:

アクティビティ (AccountId, Timestamp, Category, SubId)

タグを付与するアカウント。 名前 (Name)

付与する追加情報を表す文字列。

あるサービスにおける全ての概念は、上に挙げたオブジェクトモデルの構造によって表現されます。Twitter を例に挙げれば、ユーザはアカウント、つぶやき、その他ユーザ情報はアクティビティ、フォローはリレーション、favorite はマーク、reply はリファレンス、などとなります。もちろん、MetaTweet側でオブジェクトモデルに則ってデータ構造を拡張することは可能であり、そうすることでそのサービス自体では本来表現できない、より高度なメタデータを保持することが可能となります。

そして、MetaTweetオブジェクトモデルはサーバ部分をはじめとした他のライブラリとは独立しており、依存関係も標準ライブラリ以外は存在せず、そのため、他のソフトウェアからも容易にアクセスし、または組み込んで利用することが可能です。

MetaTweet の現状及び課題MetaTweet はプロジェクトの開始から既に 10ヶ月近く経過し、決して少なくない量のコード資産を蓄積しました。また、そのままの状態で動作可能なバイナリパッケージのリリースも存在します。

サーバ部分に関しては設計及び実装に関して、未確認の不具合の存在を考慮しなければ、ほぼ完成された状態です。本稿が書かれている時点での最新のパッケージリリースであるバージョン0.7 の時点で、十分な動作状況となっています。Monoへの対応は現時点では完全には出来ていないと考えられますが、大部分は互換性が取れていると推測され、また、対応を行うべき部分も限られており、十分着手可能な状態です。オブジェクトモデルに関しては前述の通り全面的にリプレースされたばかりの状態で、機能と

しては必要程度の実装がなされていますが、本格的な完成度という点では今しばらくの時間が必要と考えています。各種モジュール類はオブジェクトモデルの変更により少なくない変更が必要となっており、ま

た Twitter 向けのフローモジュールを OAuth に対応させたものとするために、現在再実装を行っています。また、MetaTweet のサービス中立の特性を発揮するという点において、Twitter 以外の他のサービスへの対応を行う必要性も感じています。

クライアントは現在雛形が完成していますが、サーバとの通信およびデータの表示を中心とした具体的実装は未だ未着手であり、また、データのフィルタリングに関連した設計は現在検討を重ねている状況です。早急に実装する必要がありますが、作業順序としては上に挙げた課題に続

く最後のものとなってしまうと考えています。MetaTweet の今後の課題は決して少なくはありませんが、十分に解決が可能なもののみである

と見込んでいます。

MetaTweet の未来現在の課題と同様に、MetaTweet が歩むべき今後についても検討を行っています。MetaTweet

は単なるソフトウェアで終わるものではなく、一個のシステム、一個のプラットフォームとして設計され、また、そこまで育ち得るものと確信しています。そして、MetaTweet の特長たる先進性のために、これからも積極的に新しい機能を取り入れる必要があると考えています。以下に、今後実装する予定の機能を列挙します。

Web サービスとしての MetaTweetMetaTweet はクライアント・サーバモデルに基づくシステムであり、クライアントの選択の自由が存在します。そこで、MetaTweet サーバを HTTP や他のプロトコルのサーバとして動作させ、他のコンピュータやスマートフォン、携帯電話などに MetaTweet のサービスを提供させることで、統一した環境をユーザに提供することが可能になり、他のソフトウェアとの大きな差別化となると考えています。

サーバ間通信世界中に多くのユーザが存在する以上、単独のサーバでは全ての情報を把握することは不可能

です。そこで、他の MetaTweet サーバと接続しネットワークを形成し、蓄積したパブリックなデータについて交換することで、「世界のすべてを把握する」状態に一歩でも近づける素地を形成する計画を検討しています。また、現在流行しているクラウドコンピューティングとも関連することが可能でないかと思われます。

アクセス制御MetaTweet が大量のデータを扱うにつれ、誰が、何のデータを取得しようとするかについて把握し、制御する必要性が生まれてくるのは必然です。MetaTweet のサーバが高度化し、複数のクライアントからの要求を受け付ける可能性が当然にある以上、MetaTweet サーバのリソースにアクセスするユーザ、及びその認証、そしてアクセス権限の設定の機構を用意する必要性があると考えています。

独立したサービスの運用MetaTweet が独立したデータ構造を保有するという観点から一歩進んで、MetaTweet それ自身が独自のマイクロブログサービスを運用するということも理論上は可能です。そうすることによるメリットについては微妙な点もありますが、少なくとも技術的には興味深い選択肢であると思います。

最後に長々と自らのプロジェクトについて語りました。MetaTweet はその開始から短くない時間が経

ちました。その成果物は、十中八九掛けた時間量に見合ってはいないと思います。しかしながら、このプロジェクトは決して単なる思いつきでもなく、また使い捨てのプロジェクトとするつもりもありません。たとえ時間が掛かろうとも、その目標である「プラットフォームとしての完成」に向けて、これからも邁進する所存です。

MetaTweet の存在とその意義、そして私の MetaTweetへの愛を少しでも感じて頂けたなら幸いです。