和田裕介さんは、人気サイト「ボケて」を初めとした、様々なWebサービスを手がけるエンジニアです。和田さんには震災を受けて、自身が開発したWebサービスを振り返りながら、自分自身の経験と、これからWebサービスが防災に果たすべき役割を見通していただきました。
3.11。その時、その後。インターネット上に展開するWorld Wide Web、いわゆる「Web」は強力な情報通達網としての役割を担いました。当然「負」の部分もあることも承知ですが、Webが災害に役に立つというある程度の事実が発見された瞬間と言えるでしょう。ただ、Webをどのように活用すればいいのか？は震災発生後当初、みんなが模索状態でした。筆者は被災者の身元を確認するWeb上のサービス「anpiレポート」を作成・運用した経験から、災害時に求められるWebの形、そしてWebの興味深いアーキテクチャを考察していきたいと思います。まずは、anpiレポートをつくるまでの経緯から紹介しましょう。
情報が無いという状況
震災発生時、私は当時の「オフィス」である鎌倉の実家でPCに向かって作業をしていました。揺れが起こった時に「これはタダゴトでは無い」と感じ廊下に飛び出ると、近くを走る湘南モノレールのレールが見た事の無い「たわみ」方をしていたのを非常に印象深く覚えています。落ち着いた頃、実家の隣に祖母の家があったので様子を見に行きました。ちょうど、叔母が遊びに来ている時だったので、祖母と叔母の二人がそこにはいました。「だいじょうぶだった？」話しかけるのですが、どうも二人は今の状況に納得がいっていない雰囲気がありました。聞くところによると「何が起こったのが分からない」らしいのです。つまり、情報が二人には無かった。
地震が起きた瞬間に鎌倉地区は一帯停電になり、作業をしていたPCはおろか、冷蔵庫からテレビまでもが使用不可能になりました。その時に私が頼りにしていたのが、iPhone端末でした。SoftBankの電波は生きていたので、TwitterやFacebookのフィードを見ると東北沖で巨大な地震が起きた事は明らかです。ところが、祖母と叔母の二人はそれすらも分からなかった。しばらくすると津波の様子の動画がソーシャルフィードに流れてきていたので、それをみんなで見たりしました。ようやく二人は納得した様子。ここで私が把握出来たのは災害時に情報が無いという状況は、少なくとも人を不安にさせるということでした。
Webエンジニアの出来ること
停電が復旧し、東京へ行っていた父親がようやく帰って来た翌日から。自分はもちろんピンピンしているし、身内の不幸も聞かない、けれども、やはり、普段の仕事が手に付きません。少し遠い日本の東北でまだまだ大変な状況があることが気になる。そこで、Webエンジニアの自分として何か出来ることは無いか？と模索を始めました。Webエンジニアにとって、この場合の手段はWebをつくって公開することです。まずつくったのは「picpray」というサイトです。
当時Twitterでハッシュタグ「#prayforjapan」をつけたツイートが大量に流れていました。そこには世界中から日本の被災者へ向けてのメッセージが写真付きで投稿されていました。その写真をダラダラと一覧で見る事が出来るサイトです。これほどまでに多くの人が日本のことを思ってくれているのか、と思うと圧巻でした。ただ、このWebが、今やれる全てのことか？と聞かれると満足出来ない節もあり、また、特に世の中のウケも良かったわけでもないので、モヤモヤとしていました。
anpiレポート
そんな最中、同じくTwitterからヒントが出てきました。Twitterを眺めていると「#anpi」というハッシュタグを付けて安否情報のやり取りをしていているツイートが大量に流れているのです。そこには身元を確認したい人、自分の消息情報を投稿していると様々でした。事実、Twitterの公式Blogでもその当時「#anpi」等のハッシュタグをそのような利用ケースとして使うように推奨していました。例えば以下のような具合です。
- #jjhelpme: 救助要請
- #hinan: 避難情報
- #anpi: 安否確認
ただ疑問を持ったのが、この「#anpi」のタグがついたツイートはTwitter上の情報という性質上「流れ」やすく、検索がしにくく、再利用性が低いのではないかと思ったのです。そこで、考えたのは「#anpi」というハッシュタグのツイートをボランティアの方を含めて人力でまとめてレポート化するサービス「anpiレポート」です。
仕組みは至って簡単です。レポートを作成したい人はTwitterログインを利用して、anpiレポートにログイン。「#anpi」ハッシュタグの付いたツイートのURL、そこに記載されている安否に関わる人の名前と場所が必須項目になっているので入力。すると表形式のレポートに追加される。いわば、特化したTwitterまとめサイトをみんなでつくるような具合です。Twitterログインのプログラムなど、今までつくってきたWebアプリのソースコードを流用し、素早く開発を進め、15日の朝に正式にリリースしました。
anpiレポートはまさに私が祖母と叔母を見て思ったクリティカルな「情報」を扱う今自分がやるべきサービスだと自覚しました。当時Google Person Finderと呼ばれるGoogleの提供する安否確認サービスが巨大なデータベースとなっていましたが、それでも取りこぼしを拾える立ち位置にいました。そこで、ある程度戦略的にanpiレポートを広めていく必要があります。
まずは、情報を集めることに注力しました。一見して価値のあるのはその仕組みではなく、そこにあるデータ量がモノを言います。公開前からもFacebookを通じて友達にテスト使用を手伝ってもらいましたが、公開後は本格的にFacebookグループを作成し、誰でもウェルカムな状況とし、色々な方々にレポート作成の協力を募りました。そして、ある程度レポートの量が溜まって来たところで多くの人に見てもらうようプレスリリースを打ちました。結果以下のようなニュースメディアに掲載されたり、Yahoo!の震災関連ページから大きなトラフィックをもらうことになります。
平行して、機能の追加も行います。そのうちの一つが「Web API」の提供です。
Web APIの可能性
anpiレポートに限らず、今回の震災関連、そして今のWebのおいて「Web API」は重要なキーワードです。若干テクニカルな話題なので、少し解説をしましょう。そもそもAPIとは「Application Programming Interface」の略で、とあるシステムやコンポーネントを外部から操作するための境目を定めた仕様のことです。と言うとなんのこっちゃって感じですが、例えば、車を運転する時にハンドルとアクセルとブレーキというものがあって、ハンドルは方向を指示するために左右に回す、アクセルは踏むと前に進んで、止まる時にはブレーキを踏むものだよ、と普段私たちが「車」に対してアクションを起こす「インターフェース」のようなものを指します。
Web APIとはWeb上のリソース、つまりそのサービスが持っている情報や仕掛けを操作するためにプログラミングで操作可能なAPIです。例えば、自分のサイト上にYouTubeで検索した動画の一覧をダイナミックに表示をしたければ「YouTube Data API」を使えばそれが実現可能です。YouTubeにある巨大な動画共有データをプログラミングで操作し、自サイトに取り込むことが出来るのです。
anpiレポートでも早い段階からWeb APIを提供していました。登録されたレポート情報を他のサイトでも利用してもらうためです。例えば、あるURLにアクセスするとプログラムから利用しやすい「JSON」もしくは「XML」というフォーマットでデータの取得が出来ます。
{"next_page":null,
"entries": [{
"person_name":"対象となる方のお名前",
"tweet_screen_name":"ツイートした人のID",
"memo":null,
"tweet_url":"http://twitter.com/xxx/status/0123456789",
"person_yomi":null,
"person_sex":"male",
"person_age":null,
"person_place":"宮城県石巻市蛇田",
"editor_screen_name":"yusukebe",
"created_on":"1300153005",
"id":"6"
}]
}
このWeb API提供のおかげで、3月15日のリリース当日にも関わらず、anpiレポートの携帯版がFacebookの友達の作成で完成していました。私自身、同じようなものをつくる事は可能でしたが、諸々の手間が省ける「助かる」展開となったのです。また、anpiレポートは後ほどGoogle Person Finderの特別APIを利用することが可能となったので、登録情報の「被り」等の確認などがスムーズにいくようになりました。
疎結合というアーキテクチャ
このようにWeb APIを活用してanpiレポート、及びその周辺が非常にうまく回っていました。一重にWeb APIがそもそも「疎結合」なアーキテクチャをとっているから成り立つのではないかと感じています。
上記で解説したWeb APIの仕組みによると、Webサービスとプログラムのやり取りだけ決めて、中身をどのように実現するかどうか？には関与しない、というのが正しいインターフェースのあり方です。ありとあらゆる変更がそれぞれに影響し合うような繫がり方が密結合だとすると、Web APIにおける「インターフェースさえ共通認識があればお互い影響し合わない」というのが疎結合と言えます。
anpiレポートの例で言えば「こんな形式でデータ出力するから自由に使ってね」とサイト上にドキュメントとして記載しておけば、あとはどのように利用してもらっても構わないというわけです。特に、震災時に有益な情報として捉えていただければ、あとはサーバーが耐えれれば、いくらでも活用してもらいたいという一心でした。
ところで、いわゆる営利目的の企業が公開しているAPIは制限が強かったり、その会社の戦略が見えてくるのですが、今回のボランタリーなケースや公共性の高い組織が持っている情報はどんどんとWeb APIで公開されると良いかと楽観的に思っています。地震関連では「J-SHIS 地震ハザードステーション」がWeb APIを公開しています。
地震予測などの情報も取得出来て面白く、その他サービスと組み合わせて新しいサービスを考えることも出来ると可能性を感じます。決して私たち個人では得る事の出来ない情報がそこにはあります。
その後
anpiレポートは1年間程度運用し、実際、役に立ったという声を20人弱の方からいただき、個人情報の観点からサービスを停止、ドメインをそのまま失効させました。まだ復興は続いているという現状を真摯に捉えつつも、anpiレポートにまつわる物語はシェアする意味があるかもとキーボードをタイプしてみた次第です。Webが災害時に役に立ったという事実を受け止めつつ、よりよいWebをつくりだして行きたいですね。
和田 裕介 / 株式会社ワディット代表取締役 / 株式会社オモロキCTO
1981年生まれ。大学院卒業後に父親とワディットを立ち上げ、株式会社オモロキではCTOとしてWebアプリケーション開発を担当する。小粒なWebサービスをいくつも開発してきた。代表作はWeb音楽プレイヤーの「君のラジオ」。また、オモロキでは、人気お笑いサイト「ボケて」のシステム開発を務めている。YAPC::Asia 2012では60ほどのトークセッション中、ベストトーク賞1位を獲得した。著書に『Webサービスのつくり方 ～「新しい」を生み出すための33のエッセイ』（技術評論社）がある。