1. 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 システムはサーバとクラ
イアントにより構成されます。サーバはコマンドラインアプリケーション、またはサービスやデーモ
Twitter (http://twitter.com) とは、
i
2009 年現在世界最大のマイクロブログサービスであり、日本においても普及
が進んでいる。詳細は割愛。

2. ンとして起動し、外部のサービスに接続してデータを取得・蓄積します。そしてクライアントは通常
のアプリケーションとしてサーバから間接的にデータを取得し、ユーザに提示します。このモデルの
メリットは、負荷のかかる部分、あるいは長時間に渡って運用される可能性のある部分をサーバとし、
ユーザに対するインターフェイスをクライアントとして分離することにより、長時間の運用にも耐
えii、またパフォーマンスがユーザインターフェイスによって無駄に低下することを回避することが
できます。副次的な効果として、クライアントの選択が自由になり、携帯端末からサーバ上のデータ
を取得するといったことも可能となります。
データベースの利用
私が常々考えていたことの一つとして、Twitter クライアントはコストを掛けてデータを取得して
いるのに、ソフトウェアを終了させるとそのデータが破棄されてしまうのは大いなる無駄ではない
か？というものがありました。そして、それは非常に勿体ないことに映りました。また、少なくとも
Twitter では、過去のデータを取得するのは現在のデータを取得するのに比べ困難です。MetaTweet は、
取得したデータの貯蔵先としてデータベースを採用しています。MetaTweet システムを停止させて
も、それまでに取得したデータは破棄されることなく、バックエンドのデータベースに保存されます。
これにより、取得したデータをアーカイブ化することができ、有用に活用することが可能となります。
高度な抽象性・モジュールシステム
MetaTweet はサーバ、(標準として用意される) クライアント共に高度に抽象化されています 。
MetaTweet のサーバは単体では何の有用な機能も持たないまでに機能を削ぎ落とされています。外
部サービスとの接続・データの取得、データの出力、クライアントとの通信、バックエンドのデータ
ベースとの接続など、あらゆる機能は自由にロード・アンロードできるモジュールとして提供され
ます。クライアントはほとんどの機能が関数として定義され、キーバインド、メニュー項目、ユーザイ
ンターフェイスなどの主要な構造を自由に変更・追加することができます。この設計はあらゆるサ
ービス・状況・用途に MetaTweet が対応でき、自由に機能を追加して拡張できることを意味します。
サービス中立かつ高度なデータモデル
MetaTweet はあらゆるサービスに対応することが可能であり、さらにバックエンドにデータベー
スを採用しているため、そのデータ構造はあらゆるサービスのデータ構造を表現できるように高度
かつ抽象に設計されています。サービス上のあらゆる概念は統一的な構造として表現され、それらを
横断的に扱うことができます。また、この設計は個々のサービスでは表現できない概念を付加し、よ
り高度に蓄積したデータを利用することが可能となります。また、サービス中立な設計によりソフト
ウェアが特定のサービスに依存することを回避し、新規サービスの出現、あるいは既存サービスの消
滅に対し強靱となります。そして、この MetaTweet のデータモデルは標準ライブラリのみで実装され
ており、他のソフトウェアからも容易に利用することができるものとなっています。
フリーソフトウェア
MetaTweet はライセンスに GNU Lesser General Public License (GNU 劣等一般公衆利用許諾書)iii
ユーザインターフェイスとロジックの分離という観点からも相応しいと考えます。
ii
iii
http://www.gnu.org/licenses/lgpl-3.0.html
(日本語の参考訳: http://sourceforge.jp/magazine/07/09/05/017211)

3. を適用しています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 サイト。
MetaTweet プロジェクトページ
http://sourceforge.net/projects/metatweet/
SourceForge.net 上のプロジェクトページ
MetaTweet ソースコード Subversion リポジトリ
http://svn.metatweet.org/svnroot/metatweet/
Subversion バージョン管理システムによるソースコードの公開場所
iv
システムの一部に GNU LGPL 以外のライセンスを適用したコードや、第三者によるライブラリが含まれて
いますが、それら全てフリーソフトウェア/オープンソースソフトウェアの定義に合致するものです。
v
http://msdn.microsoft.com/ja-jp/vcsharp/default.aspx
vi
http://msdn.microsoft.com/ja-jp/netframework/default.aspx
vii
Mono Project (Novell) による .NET 環境のフリーな実装 (http://www.mono-project.com/)。
viii
フリーソフトウェア/オープンソースソフトウェアプロジェクトのためのホスティングサービス
(http://sourceforge.net/)。

4. リポジトリ上には各種ドキュメントも存在します。
歴史
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 つに大別されます。即ち、外部のサービスや内部のデ
ータベースなどからデータを取得してくる先端部分に当たるインプット (Input) フロー、インプット
フローから渡されたデータを加工・整形する中間部分に当たるフィルタ (Filter) フロー、最後にデー
タを任意の形式で出力する末端部分に当たるアウトプット (Output) フローです。サーバリクエスト
内において、インプットフローおよびアウトプットは必ず 1 つ存在する必要がありますが、フィルタ
フローは 0 もしくは 1 以上存在することができます。
上において (サーバ) リクエストとは、サーバの内外で発行される、フローモジュールによるデータ
処理の実行を要求するためのデータ構造で、URI に類似した文字列で表すことができます。リクエス
ix
http://twitter.com/takeshik/status/1020632145

5. トは、実行するフローモジュール毎に、利用するストレージモジュール (後述)、フローモジュールの
名前および実行する処理の名前 (セレクタ)、およびモジュールに渡す引数のセットを連結させた物
として定義されます。
以下はリクエストを表す文字列の例です:
/!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 はサービス中立のソフトウェアであり、データのアーカイブ化に主眼を置いており、そ

6. の保存のためにデータベースを採用しています。つまり、MetaTweet のデータ構造は厳密かつ抽象に
定義される 必要があることを意味します。
MetaTweet で使用されるデータ構造は MetaTweet オブジェクトモデルと称されるもので、その操
作はオブジェクト指向に基づいています。従ってオブジェクトモデルは O/R マッピングの機能を内
包しています。当初は ADO.NET DataSet によるデータ構造に独自の O/R マッパを実装していまし
たが、効率性、安全性、将来性の観点からこれを放棄し、 月 3 日 (リビジョン 373) に O/R マッパに
10
ADO.NET Entity Framework を採用し、また同時にデータベースの構造もより抽象度の高い設計に改
めました。10 月 8 日 (リビジョン 378) には旧来のデータ構造を破棄し、オブジェクトモデルの完全
なリプレースを達成しました。現在は各種モジュールを新しいデータ構造に適合させるためにコー
ドを書き直している状況です。本稿ではこの新しいオブジェクトモデルに基づき解説を行います。
MetaTweet オブジェクトモデルは、 つの基本となるデータ構造と、
2 それらの関係をタグ付けする
5 つのデータ構造、計 7 つのテーブル/オブジェクトによって構成されます。

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 つのデータ構造に対するメタ情報を表現します。

8. アノテーション (Annotation)
アノテーションは、アカウントに対する文字列によるメタ情報を表します。
アノテーションは以下によって構成され、また、以下の全てによって識別されます:
 ア カ ウ ン ト (AccountId)
アノテーションを付与するアカウント。
 名 前 (Name)
付与する追加情報を表す文字列。
リレーション (Relation)
リレーションは、あるアカウントと、別のアカウントとの関係と、その関係を表す文字列によるメ
タ情報を表します。
リレーションは以下によって構成され、また、以下の全てによって識別されます:
 ア カ ウ ン ト (AccountId)
リレーションを付与する一方のアカウント。
 名 前 (Name)
付与する関係を表す文字列。
 他 方 の ア カ ウ ン ト (RelatingAccountId)
リレーションを付与される他方のアカウント。
マーク (Mark)
マークは、あるアカウントと、あるアクティビティとの関係と、その関係を表す文字列によるメタ
情報を表します。
マークは以下によって構成され、また、以下の全てによって識別されます:
 ア カ ウ ン ト (AccountId)
マークを付与するアカウント。
 名 前 (Name)
付与する関係を表す文字列。
 ア ク テ ィ ビ テ ィ
(MarkingAccountId, MarkingTimestamp, MarkingCategory, MarkingSubId)
マークを付与されるアクティビティ。
リファレンス (Reference)
リファレンスは、あるアクティビティと、別のアクティビティとの関係と、その関係を表す文字列
によるメタ情報を表します。
リファレンスは以下によって構成され、また、以下の全てによって識別されます:
 ア ク テ ィ ビ テ ィ (AccountId, Timestamp, Category, SubId)
リファレンスを付与するアクティビティ。
 名 前 (Name)
付与する関係を表す文字列。
 別 の ア ク テ ィ ビ テ ィ

9. (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 以外の他のサービ
スへの対応を行う必要性も感じています。
クライアントは現在雛形が完成していますが、サーバとの通信およびデータの表示を中心とした
具体的実装は未だ未着手であり、また、データのフィルタリングに関連した設計は現在検討を重ねて
いる状況です。早急に実装する必要がありますが、作業順序としては上に挙げた課題に続く最後のも

10. のとなってしまうと考えています。
MetaTweet の今後の課題は決して少なくはありませんが、十分に解決が可能なもののみであると
見込んでいます。
MetaTweet の未来
現在の課題と同様に、MetaTweet が歩むべき今後についても検討を行っています。MetaTweet は単
なるソフトウェアで終わるものではなく、一個のシステム、一個のプラットフォームとして設計され、
また、そこまで育ち得るものと確信しています。そして、MetaTweet の特長たる先進性のために、これ
からも積極的に新しい機能を取り入れる必要があると考えています。以下に、今後実装する予定の機
能を列挙します。
Web サービスとしての MetaTweet
MetaTweet はクライアント・サーバモデルに基づくシステムであり、クライアントの選択の自由
が存在します。そこで、MetaTweet サーバを HTTP や他のプロトコルのサーバとして動作させ、他の
コンピュータやスマートフォン、携帯電話などに MetaTweet のサービスを提供させることで、統一し
た環境をユーザに提供することが可能になり、他のソフトウェアとの大きな差別化となると考えて
います。
サーバ間通信
世界中に多くのユーザが存在する以上、単独のサーバでは全ての情報を把握することは不可能で
す。そこで、他の MetaTweet サーバと接続しネットワークを形成し、蓄積したパブリックなデータに
ついて交換することで 「世界のすべてを把握する」
、 状態に一歩でも近づける素地を形成する計画 を
検討しています。また、現在流行しているクラウドコンピューティングとも関連することが可能でな
いかと思われます。
アクセス制御
MetaTweet が大量のデータを扱うにつれ、誰が、何のデータを取得しようとするかについて把握し、
制御する必要性が生まれてくるのは必然です。MetaTweet のサーバが高度化し、複数のクライアント
からの要求を受け付ける可能性が当然にある以上、MetaTweet サーバのリソースにアクセスするユ
ーザ、及びその認証、そしてアクセス権限の設定の機構を用意する必要性があると考えています。
独立したサービスの運用
MetaTweet が独立したデータ構造を保有するという観点から一歩進んで、MetaTweet それ自身が
独自のマイクロブログサービスを運用するということも理論上は可能です。そうすることによるメ
リットについては微妙な点もありますが、少なくとも技術的には興味深い選択肢であると思います。

11. 最後に
長々と自らのプロジェクトについて語りました。MetaTweet はその開始から短くない時間が経ち
ました。その成果物は、十中八九掛けた時間量に見合ってはいないと思います。しかしながら、このプ
ロジェクトは決して単なる思いつきでもなく、また使い捨てのプロジェクトとするつもりもありま
せん。たとえ時間が掛かろうとも、その目標である「プラットフォームとしての完成」に向けて、これ
からも邁進する所存です。
MetaTweet の存在とその意義、そして私の MetaTweet への愛を少しでも感じて頂けたなら幸いで
す。