無印吉澤

Site Reliability Engineering（SRE）、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

Mastering Bitcoin（日本語訳 PDF）を読んで解決した疑問点、しなかった疑問点

Bitcoin Blockchain

「ブロックチェーン」という単語をニュースでよく見かけるようになってきたので、そろそろ常識として抑えておこうと思い、Bitcoin の名著として評判の高い "Mastering Bitcoin" を読みました。

Mastering Bitcoin: Unlocking Digital Cryptocurrencies

Mastering Bitcoin: Unlocking Digital Cryptocurrencies

日本語版はまだ発売されていませんが、有志による日本語訳が以下のサイトで公開されていたので、今回はこちらを読みました。レイアウトが少し崩れているところもありますが、全体的に読みやすい訳でした。

また、原著の HTML 版も、オライリーのサイトで公開されています。本書の内容をピンポイントで読み返したり、他の人に紹介するときは、こちらの方が便利そうです。

Bitcoin は独自の用語がいろいろあってわかりづらいのですが、本書は概念的な話から入って、徐々に具体的な話に進んでいくようにうまく書かれていて、非常に読みやすかったです。本書を一通り読み終わってから、Bitcoin やブロックチェーン関係のニュースの内容がだいぶ分かるようになってきました。

例えば、僕が事前に疑問に思っていたことのうち、以下の疑問は本書を読んで解決しました。

  • ブロックチェーンのブロックって何？
  • マイニングとは具体的に何をすること？
  • マシンスペックは毎年上がるから、マイニングは年々簡単になっていくのでは？
  • Bitcoin の取引を管理するサーバがあるんだと思うけど、そのサーバを提供する人のモチベーションは何？
  • Bitcoin の P2P ネットワークが分断しても問題ないの？
  • Bitcoin の採掘額には上限があると聞いたことがあるけど、その上限に達したら Bitcoin は存続できなくなる？
  • 全世界の取引が1個のブロックチェーンにずっと追加されていくと、いつか普通のマシンでは処理できないほどの量になるのでは？
  • ブロックチェーンは全世界に公開されるから、Bitcoin には匿名性はない？
  • 一度行った取引を取り消す手段はある？
  • ブロックチェーンをデータベースのように使う話を最近聞くけど、あれはどういう話？

その一方で、Bitcoin の技術的に細かい点や、Bitcoinを発展させた他のソフトウェアの詳細については、本書には書かれていませんでした。例えば、以下の疑問は解決しませんでした。このあたりは、今後、別の資料を当たってみたいと思います。

  • Bitcoin の取引が行われる P2P ネットワークの構造はどうなっている？
  • Bitcoin はどれくらい DoS 攻撃に強い？ churn 耐性はどれくらいある？
  • Bitcoin の課題を解決したと言われる、他の技術について。例えば proof of stake とは何か？　プライベートブロックチェーンとは何か？

とにかく面白かったです。僕と同じような疑問を持っている方は、是非読んでみることをお勧めします。

Mastering Bitcoin を読んで解決した疑問点

Bitcoin は独自の用語が色々あるので、本書を読むときは、最初から順に読むのが良いと思います。ただ、自分の勉強も兼ねて、本書のどのあたりに疑問への回答があったかをメモしておきます。

ブロックチェーンのブロックって何？

ブロックとは、複数のトランザクション、および1つ前のブロックのハッシュ値などを格納するデータの入れ物のこと。

前のブロックのハッシュ値を参照しているため、一番最初のブロック（ジェネシスブロックと呼ばれる）まで数珠つなぎになっている。このブロックの連なりが、ブロックチェーンと呼ばれる。

トランザクションには、入力となる bitcoin と、出力が書かれている。Bitcoin はお札のようにある程度のまとまりになっているため、通常、出力には相手への支払い額に加えて、自分へのお釣りも書く必要がある。

マイニングとは具体的に何をすること？

ブロックには nonce を格納するための領域がある。マイニングとは、まだ他のブロックに含まれていないトランザクションを新しいブロックに詰めた上で、この nonce を値をいろいろ変えて、ブロックのハッシュ値が一定の値以下になる nonce を探すこと。この「一定の値」を決めるパラメータは difficulty と呼ばれる。

ブロックの作成者は、自分に対して報酬（現在は 25 bitcoin）を与えるトランザクション（generation トランザクション、あるいは coinbase トランザクションと呼ばれる）を作って、ブロックに埋め込むことができる。見事マイニングに成功した場合、このトランザクションを含むブロックが全世界に伝播し、結果的に 25 bitcoin を使えるようになる。

マイニングの結果として得られるハッシュ値は 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4 のようになり、先頭に 0 が並ぶ。

マシンスペックは毎年上がるから、マイニングは年々簡単になっていくのでは？

マシンスペックが上がれば、単位時間あたりに計算できるハッシュ値の数は増えていく。本書の "Mining and Consensus" の節には、2012〜2014年の2年間におけるハッシュパワー（gigahashes per second, GH/s）の急増を示すグラフが載っている。

ハッシュパワーの急増を示す他の話題としては、Bitcoin のブロックヘッダの Nonce フィールドは 4 bytes なので、4,294,967,296 通りの nonce を試せる。しかし、Bitcoin のマイニングが専用 ASIC などで高速化された結果、1 秒以内にすべての nonce を使い尽くして、なおマイニングに成功しないようになってしまった（ちなみに、1秒経過すると Timestamp が変わり、ハッシュ値も変わる）。そのため、現在は generation トランザクションの自由入力欄（Coinbase Dataフィールド）が、extra nonce のために使われている。

しかし、Bitcoin では、一定時間ごとに前述の difficulty が「マイニングにかかる時間が 10 分に近づく」ように調整される。つまり、マシンスペックの向上に合わせて、マイニングは年々難しくなっていく。

difficulty の再計算（difficulty retargeting）は、2,106 ブロックごとに、直前の 2,106 ブロックの作成にかかった時間をもとに行われる。この計算はブロックチェーンを持っていれば行えるので、調整のための中央サーバなどは不要である。なお、ちょうど10分ごとに新しいブロックが作られた場合、2,106ブロックの作成には351時間（＝14日と15時間）かかる。

Bitcoin の取引を管理するサーバがあるんだと思うけど、そのサーバを提供する人のモチベーションは何？

Bitcoin の取引を管理する、ということは、すなわち取引を表す「トランザクション」をまとめた「ブロック」を作ることである。ブロックを作る（すなわちマイニングに成功する）と、前述の報酬が手に入るので、これがサーバを提供する人のモチベーションになる。

また、Bitcoin のトランザクションには、慣例として取引手数料が含まれる（敢えて、入力の額よりも出力の額が小さくなるようにトランザクションを作る）。ブロックを作るサーバは、取引手数料が大きいトランザクションを優先的にブロックに詰め込むことで、マイニング成功時により多くの手数料を入手できる。これもサーバを提供する人のモチベーションになる。

ただ、これは本書にはない話題だが、上記の報酬や手数料は、新しいブロックを作るモチベーションにはなるが、過去のブロックチェーンを保管したり、それらを他のノードに配布するモチベーションにはならない。そのため、「取引の管理」のモチベーションとしては不十分ではないか、という議論があるらしい。

Bitcoin の P2P ネットワークが分断しても問題ないの？

世界の2箇所でほぼ同時にマイニングに成功した場合、あるいはネットワークが一時的に分断された場合に、あるブロックの後続ブロックが世界に2個存在することがありうる。このような状態を "fork" と呼ぶ。

Bitcoin ノードは、複数の後続ブロックを受信すると、そのチェーンの長さまたは累積 difficulty の大きい方を、次にマイニングするブロックの1個前のブロックとして選ぶ。ブロックが2個3個と続いていくと、どこかでチェーンの長さに差が付くため、その時点で fork は解消される。fork はほとんど常に1ブロック以内で解決される。

Bitcoin の採掘額には上限があると聞いたことがあるけど、その上限に達したら Bitcoin は存続できなくなる？

マイニングの報酬は、2009年1月の時点で1ブロック50 bitcoinから始まり、210,000ブロックごとに半減するようになっている。2012年11月に25 bitcoinになり、2016年のどこかで12 bitcoinになる。そして、2140年頃にはすべての bitcoin（20,999,999.98 bitcoin）が発行され終わり、報酬がゼロになる。

しかし、前述の通り、マイニングを行う Bitcoin ノード（マイナー）には、採掘による報酬とは別に手数料収入がある。将来的にはこちらがマイナーの主なインセンティブになると予想されている。

全世界の取引が1個のブロックチェーンにずっと追加されていくと、いつか普通のマシンでは処理できないほどの量になるのでは？

Bitcoin クライアントのリファレンス実装である Bitcoin Core は、ブロックチェーンの完全なコピーを保持するようになっている。このデータは 2013 年後半の時点で約 16 GB ある。最新のグラフは Bitcoin Blockchainサイズ（blockchain.info） で公開されている。本日時点では約55GB。

これは本書にない話題だが、ブロックサイズの最大値 MAX_BLOCK_SIZE は 1,000,000 バイトで、これは小さすぎるので 2,000,000 バイトに拡張しようという動きがある（参考：ビットコイン・クラシック、ハード・フォーク、Segwitまわりについて。 | ビットコイン＆ブロックチェーン研究所）。ただ、それでもファイルサイズの伸びは高々2倍になる程度ではないかと思う。

ブロックチェーンは全世界に公開されるから、Bitcoin には匿名性はない？

Bitcoin のトランザクションに含まれる払い元や払い先（Bitcoin アドレス）は、個人を指し示すものではない。また、Bitcoin アドレスごとに秘密鍵-公開鍵のペアを変更することもできる。しかし、すべての取引はブロックチェーンから追跡可能なので、強い匿名性はない。

強い匿名性を目指して、Bitcoin 以外の仮想通貨（Alt coin と呼ばれる）がいくつか作られている。本書では Zerocoin/Zerocash, CryptoNote, ByteCoin, Monero, Darkcoin の名前が挙げられている。技術的な詳細は解説されていない。

一度行った取引を取り消す手段はある？

具体的な記載はないが、本書の内容を一通り読むと、基本的に取り消す手段はない、ということがわかる。ただ、大量のハッシングパワーを確保して、51%攻撃（コンセンサス攻撃）と呼ばれる攻撃に成功すると、取引を取り消すことが可能である。取引を取り消した bitcoin を別のトランザクションに含めてしまえば、本来正当なはずのトランザクションは、将来的に拒否され続ける。

ブロックチェーンをデータベースのように使う話を最近聞くけど、あれはどういうこと？

Bitcoin のトランザクションデータに、デジタル公証人サービス、株券、スマートコントラクトのようなアプリケーションのためのデータを格納しようとする人たちが現れた。

Bitcoin の支払いと無関係なデータをブロックチェーン上に記録することは物議を引き起こしたが、妥協策として、Bitcoin Core クライアントのバージョン 0.9 では、OP_RETURN オペレーターが導入された。このオペレーターを用いることで、80バイトのデータをトランザクションアウトプットに追加できる。

また、仮想通貨以外を主目的とするブロックチェーンが新たに登場している。本書では DNS の代替として作られた Namecoin と、汎用的な契約処理の実行基盤として作られた Ethereum が紹介されている。

無印吉澤(旧)の RSS へのアクセスを、このブログにリダイレクトするよう設定しました

お知らせ

移転から1年近く経過し、はてなブログを使っていて特に問題も無いので、無印吉澤(旧)の RSS フィードに対するアクセスを、このブログに転送するように設定しました。

リダイレクトされてきた皆様お久しぶりです。実は1年くらい前から更新再開してました。最近は Embulk というバルクローダの話、HashiCorp の環境構築ツール Otto の話、ガジェットを使って健康になる話などを書いてます。よかったらこのあたりからご覧ください。

Embulk というバルクローダの話

HashiCorp の環境構築ツール Otto の話

ガジェットを使って健康になる話

余談：リダイレクト設定による RSS リーダへの影響

リダイレクトの方法ですが、具体的には .htaccess に以下の設定を書くだけで大丈夫でした。

Redirect 301 /index.rdf http://muziyoshiz.hatenablog.com/feed

設定してから1日待って、ユーザの多そうな Feedly と Live Dwango Reader（旧Livedoor Reader）で確認してみたところ、うまく転送できてるみたいです。

ちなみに今回初めて知ったんですが、どちらの RSS リーダも、http://muziyoshiz.hatenablog.com/feed から作られた情報と、http://muziyoshiz.jp/index.rdf から作られた情報は、リダイレクトしたあとも別物として管理しているみたいです。例えば、Feedly だとこんな感じになってます。

旧ブログは未だに100〜200名くらい subscribe してくれている方がいるので、新旧のデータが統合されて読者急増！となるかと思ったら、そうはならないみたいです。まあ、Feedly の URL を見る限り、こういう設計じゃ新旧のデータが統合されないのも仕方ないですね……。

タニタの Health Planet から新しいデータだけエクスポートして Google Spreadsheet にポコポコ足していく方法

Embulk Health Planet
f:id:muziyoshiz:20160111234201p:plain:w300

これまでのあらすじ

最近ウェストが気になってきたので、計測結果を Web サイト（Health Planet）に自動アップロードしてくれるタニタの体重計を買ったところ、そのサイトにエクスポート機能がなかった……。で、しぶしぶ Embulk output plugin を書いたら、とりあえず動いたのだった。

muziyoshiz.hatenablog.com

今回の内容

体重計（体組成計）の測定結果と一緒に、腹囲の測定結果や、ちょっとしたメモを記録したくなってきました。しかし、Health Planet のほうには自由記入欄のようなものはありません。

色々考えた結果、@ さん作の kataring/embulk-output-google_spreadsheets で Google Spreadsheet にデータを入れて、そこに手入力用の列を足すことにしました。これがうまくいったので、今回はその方法をご紹介します。

この記事を書いた時点のバージョン

OS X でしか試してませんが、Windows でも多分動くと思います。

事前準備

結構いろいろ用意する必要があります。

  • Health Planet API の準備
  • Google Drive API の準備
  • Google Spreadsheet ファイルの作成
  • Google Spreadsheet ファイルのパーミッション設定

Health Planet API の準備

前回の記事（Health Planet からデータをエクスポートするための embulk-input-healthplanet プラグイン）に詳しく書いたので、そちらをご覧ください。以下の情報が揃っていれば OK です。

  • Health Planet のログイン ID およびパスワード
  • 上記のアカウントで作成した Client ID および Client Secret

Google Drive API の準備

以下の手順で API を準備します。ただ、Google Developer Console の画面デザインはときどき変わるみたいなので、もし以下の手順と違っていたら、同じ機能を探してください。

Drive API の有効化

まず、以下の手順で Drive API を有効化します。Sheets API というものもありますが、embulk-output-google_spreadsheets が使うのはそっちじゃないのでご注意ください。

  • Google Developer Console にログインする
  • 何か適当な名前のプロジェクトを作る（名前は、例えば healthplanet とかでいい）
  • 「Google API を利用する」書かれたリンクなどから API Manager に移動して、Drive API を検索
  • Drive API の表示画面で、「API を有効にする」ボタンをクリック
f:id:muziyoshiz:20160123201213p:plain

Drive API に接続するための認証情報の作成

次に、以下の手順でサービスアカウント ID と、P12 キーを入手します。

  • API Manager のサイドバーから、認証情報の画面へ移動
  • 「新しい認証情報」ボタンを押し、「サービスアカウントキー」を選択
  • サービスアカウントとして「新しいサービスアカウント」を選択し、アカウント名を記入
    • アカウント名はなんでも良い。このアカウント名によってサービスアカウント ID が決まる
    • 例えば exporter というアカウント名を入力すると、サービスアカウント ID は exporter@healthplanet-xxxx.iam.gserviceaccount.com のようになる
  • キーのタイプとして P12 を選択
  • 拡張子 .p12 のファイルのダウンロードが始まるので、好きな場所に保存する
    • このファイルは二度とダウンロードできないので、なくしてしまったら認証情報の作成からやり直し
  • 秘密鍵のパスワードが表示されるので、メモする（※今回は特に使いません）
f:id:muziyoshiz:20160123201219p:plain

Google Spreadsheet ファイルの作成

Health Planet からエクスポートしたデータを追記する先を、Google Spreadsheet に作成します。

ファイルの URL は以下のような形式になります。 {{spreadsheet_id}} の部分がこの Spreadsheet ファイルの ID です。あとで使うのでメモしてください。

https://docs.google.com/spreadsheets/d/{{spreadsheet_id}}/edit

また、このファイルの1行目に、以下の内容を記載します。タブ区切りで示していますが、実際は11列に分けて書きます。列の名前が少しでも変わるとアップロードできなくなるので、最初はこのまま書いてください。

測定日時 モデル   体重  体脂肪率    筋肉量   筋肉スコア 内臓脂肪レベル2  内臓脂肪レベル1  基礎代謝量 体内年齢    推定骨量
f:id:muziyoshiz:20160123201628p:plain

Embulk の filter プラグインでカラム名を変えて、列名をそのカラム名と同じにすれば、上記と違う列名でも登録できます。ただ、この文章の意味がわからない場合はいじらないのが無難です。

Google Spreadsheet ファイルのパーミッション設定

最後に、サービスアカウントがこのファイルにアクセスできるように、パーミッションを設定します。これで、準備は完了です。

  • Spreadsheet ファイルの右上に表示されている「共有」ボタンをクリック
  • サービスアカウント ID（メールアドレス形式）を入力し、「完了」をクリック
    • このとき、権限は「編集可能」のままにしておくこと

設定ファイル

ここまでの準備が完了したら、以下の情報が手元に揃っているはずです。

  • Health Planet のログイン ID
  • Health Planet のパスワード
  • Client ID
  • Client Secret
  • サービスアカウント ID
  • P12 キー
  • Spreadsheet ファイルの ID

これらの情報を、以下の Embulk の設定ファイルの、{{ }} で囲まれた場所に記載してください。設定ファイルの名前はなんでもいいですが、この例では embulk-healthplanet.yml とします。

happyturn% cat embulk-healthplanet.yml
in:
  type: healthplanet
  login_id: {{Health Planet のログイン ID}}
  password: {{Health Planet のパスワード}}
  client_id: {{Client ID}}
  client_secret: {{Client Secret}}
  lang: ja
exec: {}
out:
  type: google_spreadsheets
  service_account_email: '{{サービスアカウント ID}}'
  p12_keyfile: '{{P12 キーが置かれた場所のファイルパス}}'
  spreadsheet_id: '{{Spreadsheet ファイルの ID}}'
  default_timezone: Asia/Tokyo

エクスポート処理の実行方法

以下のコマンドを実行すると、エクスポート処理が実行されます。

$ embulk run embulk-healthplanet.yml -o embulk-healthplanet.yml

設定に成功していれば、以下の図のように、エクスポートしたデータが Spreadsheet ファイルにポコポコ追加されていきます。

f:id:muziyoshiz:20160123201222p:plain

また、コマンドの実行が完了すると、embulk-healthplanet.yml のなかに、最後に取得したデータの計測日時が記録されます。そのため、同じコマンドをもう1回実行すると、新しいデータだけがエクスポートされて、同じファイルの末尾に追加されます。バッチファイルとか作って、1日1回くらいのペースで自動実行させておきましょう。

まとめ

こんな感じで、Embulk を使って、タニタの体重計の測定結果をいろいろいじれる環境が整いました。すでに追加された行については、値をいじったり、他の列にメモなどを追加したりしても大丈夫なので、他のデータ（腹囲とか運動記録とか）と組み合わせて色々遊んでみたいと思います。

参考文献

2016-02-02追記：launchd での定期実行

何度か動かして、特に問題無さそうなので、Mac OS Xでlaunchdでcronのように定期実行するメモ - launchd.plistの作成とか(tweeeetyのぶろぐ的めも) と A launchd Tutorial を参考に、launchd で 30 分ごとに定期実行するようにしました。

Launchd setting for embulk-output-healthplanet

Health Planet からデータをエクスポートするための embulk-input-healthplanet プラグイン

Embulk Health Planet
f:id:muziyoshiz:20160111234201p:plain:w300

きっかけ：エクスポート機能がほしい

最近、測定結果を自動的にアップロードしてくれる体重計が欲しくなり、

  • 単独で Wi-Fi 接続して、測定結果をアップロードできる Withings
  • アップロードに専用スマホアプリが必要だが、測定できる項目が多い、タニタの上位機種（RDシリーズ）

のいずれかで悩んだ結果、タニタの innerscan DUAL RD-902（若干安い型落ち品）を買いました。

TANITA 【筋肉の「質」がわかる】 デュアルタイプ体組成計 インナースキャンデュアル ブラック RD-902-BK

TANITA 【筋肉の「質」がわかる】 デュアルタイプ体組成計 インナースキャンデュアル ブラック RD-902-BK

タニタの製品は、専用スマホアプリを通して、測定データをタニタのサイト Health Planet へ自動的にアップロードするのですが、このアプリもサイトも、データのエクスポート機能を提供してません。しかし、データを取得するための API (Health Planet API) は提供されていました。

そこで、今回はこの Health Planet API 経由でデータをエクスポートするための Embulk input plugin を作ってみました。

注意事項

先にお断りしておくと、Health Planet API ver. 1.0 は「体水分率」に対応していませんでした。そのため、この embulk-input-healthplanet も体水分率はエクスポートできません。体水分率が必要な場合は、その値だけ手作業でエクスポートしてください。

また、現在の embulk-input-plugin version 1.0.0 は体組成計のデータ（innerscan）のみエクスポート可能です。私はタニタの歩数計や血圧計を持ってないので、そちらのエクスポート機能の開発予定は今のところありません。

使用手順

1. Health Planet のアカウント作成

まずは、Health Planet の「新規会員登録」のページからアカウントを作成してください。余談ですが、体重計を持っていなくてもアカウントは作れます。

2. Client ID および Client Secret の取得

場所が見つけづらいのですが、ログインしてから以下の順に進むと、アプリケーションの新規登録ページを表示できます。

  • 画面右上の「登録情報の確認・変更」リンク
  • 「サービス連携」リンク
  • 「アプリ連携」欄の下にある「アプリケーション開発者の方はこちら」リンク
  • 「新規登録」ボタン

新規登録画面では、以下のように入力してください。アプリケーションタイプを「クライアントアプリケーション」にする以外は、特に気にしなくても大丈夫です。

  • アプリケーションタイプ: クライアントアプリケーション
  • サービス名: (任意。自分が区別できる名前なら何でもOK)
  • メールアドレス: (自分のメールアドレス)
  • 説明: (空欄)

新規登録が完了すると、Client ID と Client Secret が画面に表示されます。

3. Embulk のインストール

Embulk をインストールしていない場合は、Embulk の "Quick Start" の手順に従ってインストールしてください。Linux & Mac & BSD と、Windows ではインストールコマンドが異なります。

4. embulk-input-healthplanet のインストール

以下のコマンドを実行して、embulk-input-healthplanet プラグインをインストールしてください。このコマンドは OS 共通です。

$ embulk gem install embulk-input-healthplanet

5. Embulk の設定ファイルの作成

エクスポート結果を CSV ファイルに出力する場合は、以下の内容で config.yml ファイルを作成してください。また、この設定を使う場合は、事前に healthplanet ディレクトリを作成してください。

in:
  type: healthplanet
  login_id: (手順1で作成したログイン ID)
  password: (手順1で作成したパスワード)
  client_id: (手順2で作成した Client ID)
  client_secret: (手順2で作成した Client Secret)
exec: {}
out:
  type: file
  path_prefix: ./healthplanet/
  file_ext: csv
  formatter:
    type: csv
    default_timezone: 'Asia/Tokyo'

6. 実行

config.yml ファイルを置いたディレクトリで、以下のコマンドを実行してください。コマンドの実行に成功すると、healthplanet ディレクトリに CSV ファイルが出力されます。

$ embulk run config.yml

上記のコマンドは、1回実行するたびに、すべてのデータを Health Planet からエクスポートします。1回エクスポートしたデータは今後エクスポートしたくない場合は、以下のように -o オプションを指定してください。

$ embulk run config.yml -o config.yml

出力されるカラム名と、日本語名の対応は以下の通りです。カラム名は、タニタの英語サイトにあったものをそのまま採用しました。

カラム名 日本語名
time 測定日時
model 体組成計のモデル（手入力の場合は 00000000）
weight 体重 (kg)
body fat % 体脂肪率 (%)
muscle mass 筋肉量 (kg)
muscle score 筋肉スコア
visceral fat level 2 内臓脂肪レベル2(小数点有り、手入力含まず)
visceral fat level 1 内臓脂肪レベル(小数点無し、手入力含む)
basal metabolic rate 基礎代謝量 (kcal)
metabolic age 体内年齢 (才)
estimated bone mass 推定骨量 (kg)

ソースコード (GitHub)

https://github.com/muziyoshiz/embulk-input-healthplanet

実装方法

init メソッドのなかで、以下の順に HTTP リクエストを送信し、アクセストークン access_token を取得しています。/oauth/auth から approval.do までは JSESSIONID などのクッキーを渡さないと動作しないため、Ruby の HTTP ライブラリ Faraday に、faraday-cookie_jar を組み合わせて実装しました。

  • GET https://www.healthplanet.jp/oauth/auth
    • クッキー JSESSIONID が返されて、ログイン画面が表示される
  • POST https://www.healthplanet.jp/login_oauth.do
    • loginId および passwd を POST すると、セッション情報にログイン情報が格納される
    • 隠しパラメータの send (値は1) と url (最初にアクセスしたのと同じURL) を設定しないと、ログイン情報が正しくても処理に失敗する
    • ログインに成功すると、url に含まれる URL への 302 Redirect が返される
  • GET https://www.healthplanet.jp/oauth/auth
    • 最初と同じ URL にアクセスする
    • ログイン後の JSESSIONID をクッキーとして渡すと、今度は oauth_token を含むページが表示される
  • POST https://www.healthplanet.jp/oauth/approval.do
    • oauth_token パラメータを渡すと、トークンの取得に必要な code が返される
  • POST https://www.healthplanet.jp/oauth/token
    • 上記の code パラメータを渡すと、アクセストークン access_token が返される

アクセストークンの取得後は、以下の URL にアクセスして、体組成計のデータを取得しています。JSON のパーサには、（Nokogiri と違って）libxml2 がなくても動作する Oga を採用してみました。

  • GET https://www.healthplanet.jp/status/innerscan.json
    • 体組成計のデータを JSON 形式で取得する
    • この API は最大で3ヶ月分のデータしか返さないため、この URL への HTTP リクエストを複数実行し、データを3ヶ月区切りで取得している
    • デフォルトでは1年前のデータから取得するが、これはプラグインの next_from パラメータで変更可能

タニタへの問合せ結果（2016-01-13追記）

このプラグインの開発中に、Health Planet API ver. 1.0 が「体水分率」に対応していないことに気付いたため、タニタの問合せ窓口へ以下のように報告しました。

Health Planetにデータのエクスポート機能がないため、Health Planet API を使ってエクスポートを行おうとしています。
その際に気付いたのですが、現在のAPIは「体水分率」を出力する機能がないようです。
APIの機能不足について、そちらでは認識されていますでしょうか？　また、体水分率のサポート予定がありましたらお教えください。よろしくお願いします。

これに対して、タニタからは以下のように、「この不具合を修正する気はない」旨の回答が返ってきました。

このたびは、お問い合わせいただきありがとうございます。
お問い合わせいただきました件につきましてご連絡させていただきます。
　
誠におそれ入りますが、
「Health Planet API」は無料での配布のため、サポートは致しかねます。
　
また、お問い合わせいただきました内容につきましても
回答致しかねますので、何卒ご理解を賜りますようお願いいたします。
　
今後とも弊社ならびに弊社製品をご愛顧のほど、宜しくお願い申し上げます。

自分なりにこの回答を解釈すると、Health Planet は innerscan という有料の体組成計が提供するサービスの一部ではなくて、無料のおまけ、という位置づけのようです。サービスとしての体重計を期待していたので、この回答には心底がっかりしました。

私はもう買ってしまったので仕方ないですが、サービスとしての体重計を期待するなら Withings の方がよさそうです。少し調べた感じでは、Can I export my data to a csv file? – Withings によると、こちらはエクスポート機能があるようです。

Withings Smart Body Analyzer ネットワーク対応 体重計 ( Bluetooth Wi-Fi 機能 / 超薄型 / BMI 体脂肪 心拍数 測定可 / ブラック ) WS-50

Withings Smart Body Analyzer ネットワーク対応 体重計 ( Bluetooth Wi-Fi 機能 / 超薄型 / BMI 体脂肪 心拍数 測定可 / ブラック ) WS-50

参考文献