データとAPIの具体例

提供されたデータ

東京メトロオープンデータAPI（以下、メトロAPI）では、以下のデータの取得が可能です。

図１　提供されたデータ一覧

APIとデータについて

ここで、メトロAPIとデータについて興味深いポイントを幾つかまとめてみます。

1. データの取得方法
2. メトロAPIとデータの形式
3. 動的なデータと静的なデータ
4. 具体的なデータの例

1.データの取得方法

図２　端末とメトロAPIの間に開発者のエンドポイントがある場合のシステム概要

　図２はメトロAPIを利用するシステムの一例です。注目点は２つあり、１つめは、エンドポイントが２つあることです。ここで、エンドポイントとは、アプリケーションがAPIを使ってデータを取得する際のデータが保存されている場所です。より具体的には、そのデータの場所を示すURIとなります。

　２つめの注目点は、トークンですが、これは登録を行うと払い出される文字列で、これを使いメトロAPIにアクセスすることで、図１のデータを取得できる仕組みです。

　なお、東京メトロのエンドポイントは公開されていますが、図２や図３でそこから右の運行システムや列車に関する情報は公開されていません。

エンドポイントについての議論

　東京メトロオープンデータ活用コンテストが始まった際に、開発者向けフォーラム（2017.2.11現在でも登録した開発者向けに提供中）で、「apiへの直接アクセス」と言うトピックで議論されたトピックですが、要は図３のような構成ではなく、必ず図２の「開発者のエンドポイント」を作成することと言うルールが当初のガイドラインにありました。

　これに対しては、「図３のシステムであれば、端末上のアプリだけ開発すれば良いが、図２のシステムではエンドポイントまで開発しなければならず開発の敷居が高い」等の声があがり議論があった結果、最終的にはどちらのシステムでも認められることとなりました。

図３　端末がメトロAPIに直接アクセスする場合のシステム概要

エンドポイントはどうあるべきか

　上記のような議論を踏まえ、エンドポイントがどうあるかを考えるとポイントは、①データへのアクセスの権利、②システムへの負荷、③データが動的か静的か、（また現時点でのメトロAPIの利用料は無料でありあてはまりませんが）、一般的なAPI利用を考えた際の、④API利用料金の４点となります。

　①のデータへのアクセスの権利については、メトロAPIの場合には、トークンがポイントとなります。誰もがメトロAPIにアクセスできる訳ではなく、登録することで開発者がトークンを入手でき、そのトークンを使うことでメトロAPIにアクセスできるようになります。オープンデータなのだから（トークンなどなくても）だれでもオープンにアクセスできるべきと言う議論はあると思うのですが、例えば悪意をもった開発者が開発者のエンドポイントや、端末上のアプリケーションで改ざんしたデータを配布した際にメトロAPIの利用を停止する手段を残しておくことは一理あると思われます。

　②のシステムの負荷については、図２では開発者が自前で、端末からのアクセスを受けるエンドポイント（具体的には、AWSやHeroku等のサイト）を構築する必要があり、図３では東京メトロのエンドポイントが端末からのアクセスを受ける必要があります。この際のアクセスが多量になれば、それを捌くだけのリソースが必要となり、コストがかかることになります。そこで、図２のような開発者毎のエンドポイントのシステムでレイヤーを作るような事も必要になってきますが、この際にも例えば、端末から受けたアクセスを、そのまま上位のエンドポイントに問い合わせると負荷分散の意味では効果がありません。このような負荷分散の観点からは、例えばDNSやプロキシのシステムのようなキャッシュの導入が効果的になってきます。キャッシュについては膨大なノウハウの蓄積があり、静的なデータだけではなく、動的なデータについても有効な手法があります。

　③データが動的な静的かについては、別途、今回のメトロAPIの具体的なデータとともに議論したいと思います。

　④API利用料金については、メトロAPIは無料で利用可能なため関係のない話となるのですが、例えばAPI問い合わせ毎に利用料がかかるシステムであれば、問い合わせの回数を少なくするためにキャッシュを利用する等の動機付けになるかもしれません。アプリケーションでの課金や、サービスのビジネスモデルにも関係する話となってきます。

　以上、有効活用可能なオープンデータを提供するためには、不正利用対策や、適切なシステムの負荷分散、提供するデータの性質、課金形態は少なくても検討が必要になってきます。