英語コミュニティ「en-jp meetup」第12回 参加した話

初心者に優しい英語コミュニティこと「en-jp meetup」の第12回に参加した話です。
en-jp meetup #12 - 2018/04/05(Thu) | en-jp (東京都, 日本) | Meetup

en-jp meetupは、英語を勉強している人のためのミートアップです。自己紹介やLT、懇親会まで含めてすべて英語縛り。ただし、相手の英語や発表内容の評論は禁止で、とにかく積極的に英語を喋ってみようというのが趣旨。なんの問題もなく英語を使いこなしている上級者もいれば、まったく英語には自信がない初心者もいて、ワイワイ英語で話をしている楽しい集まりです。

参加者はIT関係の人が多いですが、LTも含めてテーマの縛りは特になし。私は、前回はねぶた祭りを紹介するLTをやりました。
今回は、仕事でときどき海外(おもにポルトガル)に行っていることについて、どういう経緯でそうなったのかを話させてもらいました。基本的には、以前CLEM (Creators Learning English Meetup)でLTしたものの再演ですが、今回はすべて英語でチャレンジしました。

ポルトガルの話をするのはCLEMも含めて3度目なので、英語でも一応なんとか形にはなったかなとう感じ。

私のスライドは最初に日本語で組み立ててから英語に直すのだけど、それに対して懇親会で、最初から英語で作った方がいいよというアドバイスをもらいました。これはまさにその通りだとわかっていながら、実践には至っていないことです。まだ日本語ベースでないと全体の構成が頭にイメージできないというのが大きな理由です。

スライド作るときって、まず喋りたい内容をばーっと頭に浮かべて、その中から必要なものを取捨選択しながらストーリーを作るので、最初から英語縛りが入っちゃうとイメージを広げる作業そのものが英語力に引っ張られて制限されちゃう。圧倒的なボキャブラリの足りなさが一番の問題だとは思うのだけど。日本語→英語に変換する段階でも、情報量は半分以下に落ちてしまうので、もう少し伝えたいことを直接的に表現できるようになりたいです。

帰り道、渋谷駅の改札で立ち止まっていた外国人観光客の4人組がいたので(自動改札の切符の取り扱いで迷っていたっぽい)、声をかけて、品川に行きたいってことだったのでそのまま一緒に電車に乗りました。イスラエルから来たということだったので、妻が去年行ってすごく良かったと言ってたよーという話をしました。

品川駅別れた直後、今度はスマホ見ながら迷っている外国人がいたので声をかけたら、茅ヶ崎に行きたいということだったので一緒に東海道線に乗りました。ブラジルから来てレストランで働いてるというので、去年サンパウロ行ったよー、お肉がすごく美味しくて感激した、という話をしました。

以前よりは躊躇せずに話しかけられるようになっているので、少しは進歩しているかな。

青森ねぶた祭、全面VR化へ

青森市が、毎年8月に開催している青森ねぶた祭を2020年までに全面VR化する計画を発表しました。

青森ねぶた祭は毎年8月2日から7日の6日間に渡って開催されます。日本最大の夏祭りとも言われ昔から高い人気を集めていますが、それでも近年は観光客の伸び悩みや、踊り手である跳人(はねと)の減少などといった課題を抱えていました。

大型ねぶたを出陣する参加・運行費用の高騰も問題になっています。大型ねぶたの参加団体は22団体ありますが、その参加費用は、ねぶたの制作費も含めて2千万円以上とも言われています。最近では白熱電球の製造停止から、LED電球なども使われるようになり、団体の運営費を圧迫する一因にもなっていました。

そこで青森市では、運営費を抑えつつ、多くの人々に青森ねぶたを体感してもらえるように、祭りそのものを全面的にVR化することを決定したとのことです。企画を提案したA氏は、青森ねぶた祭のVR化について次のように語りました。
「VR化すれば、世界のどこにいても青森ねぶた祭の迫力を味わってもらえる。VRゴーグルを着けることで、遠隔で跳人として参加することもできる。東京オリンピックに向けて、外国人観光客への周知も進めていきたい」

VRねぶたのイメージ
f:id:zinbe:20180401100515j:plain

跳人のVR参加イメージ
f:id:zinbe:20180401100427p:plain

また、青森ねぶた祭とルーツを同じくする弘前市弘前ねぷた祭では、「青森がVRなら弘前プロジェクションマッピングだ」と、対抗して近代化を進める意気込みを見せています。人形型のねぶたを使用する青森ねぶた祭に対して、弘前ねぷた祭で使用するのは扇型の灯篭に絵を描いた扇ねぷたプロジェクションマッピングとの相性は良さそうです。

AndroidにおけるJava API使用の何がフェアユースではなかったのか

昨日の話の続きです。
nebuta.hatenablog.jp

Google翻訳に頼りながら判決文を眺めてみました。素人だし英語苦手なのでいろいろ誤解してるかもしれませんが、そのときはすみません。判決文の全文は以下に公開されています。
http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF

前提

ソフトウェアのAPI著作権法の保護対象になるということは、2015年6月に最高裁判決が出ているので、残念なことですがこれはもう確定していました(正確には、2014年5月に控訴審判決が出て、Google最高裁に上告。翌6月に上告が棄却されて確定した)。

今回の争点は、「GoogleAndroidにおいてJava APIを無断流用したことがフェアユースにあたるか否か」です。米国の著作権法上は、フェアユースであれば著作権の侵害には当たりません。そこでフェアユースだとした地裁の判断に対して、Oracleが不服を申し立てたのがこの控訴審です。

4つの争点

フェアユースか否かの判断材料として、今回は以下の4つ要素がおもな争点として取り上げられています(各要素については後述)。

  • Factor 1: the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes
  • Factor 2: the nature of the copyrighted work
  • Factor 3: the amount and substantiality of the portion used in relation to the copyrighted work as a whole
  • Factor 4: the effect of the use upon the potential market for or value of the copyrighted work

この4つのうち、Factor 1と4については"フェアユースではない"方向に、Factor 2については"フェアユースである"方向にそれぞれ有利で、Factor 3については中立的であると判断されています。

On this record, factors one and four weigh heavily against a finding of fair use, while factor two weighs in favor of such a finding and factor three is, at best, neutral. Weighing these factors together, we conclude that Google’s use of the declaring code and SSO of the 37 API packages was not fair as a matter of law.

(p.54)

ただし、Factor 2については"フェアユースバランシング全体に対してそれほど重要ではない"とも記されています。

The Ninth Circuit has recognized, however, that this second factor “typically has not been terribly significant in the overall fair use balancing."

(p.44)

これらを総合的に判断して、AndroidJava API使用については"フェアユースではない"という結論に至ったとのことです。

Factor 1: The Purpose and Character of the Use

簡単に言えば、AndroidJava APIを使っていることが商業的な性質が強いか否か、ということです。Oracleは、GoogleAndroidで莫大な利益を上げているから商業的だと主張していて、GoogleAndroidオープンソースだしGoogleの利益は検索エンジンによるものだからAndroid自体は非商業的だと反論しています。これに対して控訴裁では、商業的か否かはその利益が金銭的であるかどうかや、直接的に得られるものであるかどうかに依存しないので、Androidは商業的であると結論付けています。

それからもうひとつの大きな論点として、"transformative"であるか否かということも挙げられています。transformativeという用語をうまく解釈できなかったのですが、どうやら新しい価値を与えるような使用方法かどうかということのようです。Oracleは、Googleは単にAPIをコピーしただけだからtransformativeではないと主張していて、Googleスマートフォンという新しいプラットフォームを作ることが目的だったと反論しています。

地裁ではGoogleの"transformativeである"という主張は認められて重く評価されたようですが、控訴審にあたっては逆にGoogleの主張が退けられました。根拠としては、スマートフォンといえども同じAPIを同じ目的で使っていることに変わりはないことなどが挙げられています。

この控訴審にあたってOracleは、数千行のOracleJavaコードがAndroidでそのまま使われているという証拠を提出していて、これも地裁の判断を覆す大きな材料になったようです。

Factor 2: Nature of the Copyrighted Work

APIを設計という行為が創造的なものであるかどうか、という争点です。まず、コンピュータソフトウェア自体は、著作権法で保護されるべき対象という前提はすでに確立されています。そして、APIパッケージの宣言コードとSSO(Structure Sequence Organization)が著作権法の保護対象だということはすでに結論が出ています。

その一方で、APIの宣言とSSOの創造性というのは”最小限のもの”であり、APIというのは創造的な側面だけでなく機能的な側面も重要であることから、これを使用することはフェアユースであるというのがGoogle側の主張です。地裁ではこの主張が認められ、控訴審でも肯定的に判断されました。しかし前述のように、それ自体が全体に対してあまり重要ではないとされています。

Factor 3: Amount and Substantiality of the Portion Used

元の著作物の量的および質的な価値はどれくらいのものか、という争点です。これについては、開発者の負担を軽減するために、既存のAPIを流用するという行為がAndroidプラットフォームを作るにあたって重要であったことはGoogleも認めています。

Factor 4: Effect Upon the Potential Market

AndroidOracleが本来持っていたはずの潜在的な市場での価値をどの程度損ねたのか、という争点です。これは、フェアユースの「元の作品の市場性を著しく損なうことがないようなコピーに限定される」という考え方を反映したものだそうです。

Googleは、Oracleがデバイスメーカーではないことや、まだスマートフォン市場を開拓していなかったことなどを挙げて、AndroidOracleの市場を奪ったことはないと主張しており、地裁もそれを認めていました。しかし控訴審では、スマートフォンOracleの"潜在的な"市場であったことは疑いがなく、デバイスメーカーでないことも(自分で作らなくてもライセンス供与などの方法があるので)意味のない主張だという結論が出されました。

結局、APIはコピーしちゃダメなの?

これらの争点のうち、Factor 1/3/4については"Androidの場合"という前提での話であって、別のケースであれば違った判断がくだされる可能性もあるでしょう。要は、フェアユースと言い切るにはGoogleが儲けすぎていて、Oracleが進出して儲けられる可能性を奪ってるよね、という話です。Oracleの主張が認められた形ですね。

一方でFactor 2は、APIの宣言コードとSSOは(著作権法で保護されるべき)創造性を持っているけど、機能的側面も強いからフェアユース性もある、ということを認めています。ただし、それはフェアユースであるか否かを判断する他の要素に強い影響を与えるものではない、ということです。

もともとフェアユースかどうかは個別の事案で判断される性質のものなので、今回の判決だけですべてのケースが決まるというわけではありません。特に今回は、商業活動であるかや、潜在的な市場価値にどれだけ影響を与えたかということが決め手になっているので、この点が非常に大きな意味を持っていると思います。

AndroidによるJava APIの使用は著作権侵害に該当するという判決

詳しくないので間違いがあったらすみません。

控訴裁判所が、Java APIの使用に関するOracleGoogleの争いに新しい決定を下したようです。Oracleによる「GoogleAndroidによるJava APIの使用はフェアユースには当たらず、同社の著作権を侵害している」という主張を認め、地方裁判所に損害賠償の裁判を差し戻すという判決が出されました。
Oracle wins appeal against Google in copyright case – TechCrunch

今回の判決

判決文は以下にあります。
http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF

最後のConclusionに次のように書かれています。

For the foregoing reasons, we conclude that Google’s use of the 37 Java API packages was not fair as a matter
of law. We therefore reverse the district court’s decisions denying Oracle’s motions for JMOL and remand for a trial on damages. The district court may determine the appropriate vehicle for consideration of infringement allegations regarding additional uses of Android. We dismiss Google’s cross-appeal.

私たちは、Googleの37のJava APIパッケージの使用は、法律上のフェアユースではないと結論づける。したがって、JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定を取り消し、損害賠償の裁判を差し戻す。(後略)

言葉通り、フェアユースではないということは著作権侵害にあたるということなので、最初の損害賠償請求の裁判に戻すよ、ということです。

これまでの経緯

OracleGoogleの争いに関するこれまでの経緯は、2016年7月のJJUGナイトセミナーの様子をレポートした次の記事に詳しくまとめられています。
Google対OracleのJava API訴訟。歴史的経緯とIT業界への影響を考える(その1)。JJUGナイトセミナー - Publickey

重要な部分のみ抜粋すると、

  1. GoogleによるJava使用は特許侵害ではないという判決がでる(2012年5月)
  2. API著作権法で保護されるという判決がでる(2015年6月)
  3. GoogleAndroidにおけるJava API使用はフェアユースにあたるという評決がでる(2016年6月)

最初の2つは、すでに判決が出てしまっているので確定事項です。また、2のAPI著作権法で保護されるというのはJava APIに限定されたものではないので、非常に広範囲に影響するということで大きな話題になりました。

API著作権があるとしても、Androidにおける使用はフェアユースだから著作権法の保護の対象にはならないよ、としたのが3つ目の評決です。判決文のJMOL(Judgment as a Matter Of Law)というのがこの判断のことを指しています。

その後、Oracle地方裁判所に対して新たな審理を求めましたが、2016年9月に棄却されています。これが「JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定」というやつです。そのあたりの経緯やOracleの主張については、下記の記事で解説されています。

オラクル、グーグルによるJava APIの使用めぐり上訴 - ZDNet Japan

今回の控訴裁判所の判決では、"フェアユースに当たる"とした判断そのものが覆されたわけです。なぜ覆されたのかは判決文に書いてあるようですが、難しそうなので読んでいません。誰か読んで教えてください。

追記:
判決文をもう少しちゃんと眺めてみたので、こちらも参考にしてください。
AndroidにおけるJava API使用の何がフェアユースではなかったのか - 我らねぶた馬鹿

今回の判決はあくまでもOracleGoogleの個別事案

勘違いしやすいので注意しなければいけないのは、「API著作権法で保護される」というのは、今回の判決に関係なく2015年にすでに確定してしまっています。

そしてその後にOracleGoogleが争っていたのは、「AndroidにおけるJava APIフェアユースにあたるか否か」という個別の事案であって、この裁判の判決が、世の中にあるそれ以外のすべてのAPIに適用されるというわけではありません。

今後どうなるか

気になるのは今後Androidがどうなるかということですが、これからまた損害賠償請求裁判をやり直すわけなので、すぐにどうこうなってしまうということはないかと思います。ただ、次にGoogleがどう出るかには注目しておいた方がよさそうです。長期的には、GoogleJavaを見限るという極端な展開も含めて、いろんな可能性がまた復活しちゃったなあという感じですね。

JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」に参加した話

3月26日(月)に開催されたJJUGナイトセミナー「Java SE 10 / JDK10リリース特集」に参加してきました。タイトル通り、先日リリースされたJava 10の新機能などについて特集する会で、参加者240人枠の予約がすぐに埋まり、さらにキャンセル待ち200人以上という盛況ぶりでした。やはりみんな関心があるんですね。
【東京】JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」 3/26(月)開催 - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

どうでもいい話だけど、Java 10と書けばいいのか、JDK 10と書けばいいのか、はたまたJava SE 10と書けばいいのか未だに戸惑いますね。

新しいリリースモデルのおさらい

まずはオラクルの伊藤敬さん(@itakash)から、新しくなったJDKのリリースモデルに関するおさらいから。

もういろんなところで言及されているように、OSS版であるOpenJDKについては、年2回6ヶ月毎(3月と9月)のメジャーリリース、3ヶ月毎(1、4、7、10月)のパッチリリースというサイクルになります。原則として各バージョンでリリース期間は重複しないので、次のバージョンが出たらそれまでのバージョンは非サポートになりますが、3年毎にLTS(Long Term Support)版が出ます。直近のLTSは次のJDK 11です。

Oracle JDKは、次のJDK 11以降で新しいリリースモデルが適用されて、以降は有償版のみの提供となります。リリース間隔は3年ごとで、サポート期間はそれぞれ8年間。OpenJDKと同様に3ヶ月毎に(1、4、7、10月)パッチリリースが行われます。なお従来Oracle JDKの有償版にのみ提供されていた機能については、段階を踏んでOpenJDKに移行されるので、Oracle JDKとOpenJDKは同等の内容になります。

これまで無償版のOracle JDKを使っていたユーザは、Oracle JDKを有償サポートで使うか、OpenJDKに移行するかという選択を迫られています。非LTSなOracle JDK 8のサポート期限が2019年1月(個人利用の場合は2020年12月)なので、猶予はそれほどありません。
Oracle Java SE サポート・ロードマップ

ただし、これまでのOracle JDKも無償版に関してはOpen JDKと同等のものだったので、この機会にOpenJDKに移行してしまってもそれほど大きな問題にはならないと思っています。その場合、常に最新機能に追随して6ヶ月毎にアップデートを頑張るか、LTSで3年毎にアップデートするかという選択になりますね。
それよりも問題は、Java 8からJava 9にかけては多くの非互換性が含まれているので、Oracle JDK 8のサポート期限である2019年1月までに移行を完了させられるかということに尽きますね。これから始めるプロジェクトに関しては、Java 9以降(現実的にはJava 11)をターゲットにする想定した方がいいと思います。

JDK 10の追加機能の解説

続いて、David Buckさん(@DavidBuckJP‏)によるJDK 10に追加された新機能の解説。あとから資料が公開されるので細かい話は両略しまし(公開されたらリンクを追加します)。あと、Qiitaのきしださんの記事もよくまとまっていて分かりやすいです。

Java 10新機能まとめ - Qiita

Buckさんの話の大部分は、JEP 286のローカル変数型推論についての話でした。いわゆる、Java版の「var」です。JDK 10以降では、変数の宣言時にvarを指定することで明示的に型を指定しなくてもよくなりました。これはあくまでもイニシャライザの型から自動的に静的型が推測されるだけなので、動的型とは全く違います。型を書かなくてもいいというだけで、内部的には型があります。

varが導入されたことで、Javaのコーディングスタイルは大きく変わる可能性があります。ということで、OpenJDKプロジェクトからvarを使う場合のスタイルガイドが公開されています。Buckさんの解説もこのスタイルガイドを元にしたものです。「Oracle Blogs 日本語のまとめ」に日本語訳があります。

Oracle Blogs 日本語のまとめ: [Java] Style Guidelines for Local Variable Type Inference in Java

ここでもっとも重要なのは、"varはコードの可読性を上げるために使う"ということだと思います。タイプ量を減らすといった目的ではなく、あくまでもコードをシンプルにして読みやすくするために使うということです。明示的な型宣言が無いとコードが読みにくくなりそうですが、実際にはコードを読めば何の型かはすぐに理解できるので問題なく、逆に可読性が上がるという結論が多くの言語で出ているそうです。面白いですね。

Java 10でぼくたちの生活はどうかわるのか

最後に、久保田祐史さん(@sugarlife)ときしだなおきさん(@kis)によるセッション。おもに、新機能や互換性などの情報をどう追っていったらいいかという話や、Java 10に移行する上ので注意点などに関する話。これも資料が公開されるそうなので、細かい話は省略します。

Java 10以降におけるアップデートの手順は

  1. (既存プログラムを)再コンパイルせずに新しいJava環境で動かしてみる
  2. 非対応ライブラリや非推奨APIを洗い出す
  3. 非対応/非推奨部分を代替手段に置き換える

という感じにするのがいいそうです。非対応ライブラリの洗い出しには、jdepsやjdeprscanなどのツールを使います。jdepsはライブラリの依存関係を調べるツールで、deprscanは非推奨なAPIが使われている場合に、それを検出するツールです。

個人的に気になって質問したのは、新バージョンの検証をどれくらいのタイミングで初めていくのがいいかということです。これまではリリースサイクルがゆっくりだったので、JCPが固まって参照実装が出たくらいから検証を始めて、リリース後ある程度こなれてから対応というスパンでも十分でした。新しいリリースサイクルだとあまりのんびりしている時間はなさそうなので、これがどう変わるかということです。

LTSを移行ターゲットにしつつ、その間にリリースされたバージョンを順番に検証していくという形が現実的でしょうか。OpenJDKのリポジトリを追えばリリース前にも検証を進めることは可能だけど、そのサイクルを追うのはさすがにしんどいので、LTS以外は正式リリースを追う形でもいいんじゃないか、というのがきしださんの見解。私も同意です。

また久保田さんは、「まずは Java8 → Java9 を乗り越えること。それさえ乗り越えられれば、その後のバージョン間の差分(新機能とか非互換性とか)はそれほど大きくないので、あまり怖くないはず」とおっしゃっていました。

あと「創るJavaはいつ出るか?」という質問の意図について書こうと思ったけど、長くなったので別の機会にします。

Java Day Tokyo 2018に関するアナウンス

伊藤さんから、Java Day Tokyo 2018関するアナウンスがありました。Java Day Tokyo 2018は5月17日(木)開催。基調講演に、なんとMark Rainhold氏の来日が決まったそうです。これが昨日の一番の驚き。参加登録サイトは近日中に公開予定とのこと。

JJUG CCC 2018 Springに関するアナウンス

JJUGより、 JJUG CCC 2018 Springに関するアナウンスがありました。JJUG CCC 2018は5月26日(土)開催。今月末までCall for Paperを募集中なので、ネタを持っている人は怖がらずに応募して欲しいとのことです。
JJUG CCC 2018 Spring

Eclipse FoundationがJakarta EEプロジェクトに関するサーベイを実施中

去る2017年9月、Oracleはこれまで同社が主導していたJava EEの仕様策定および開発をEclipse Foundationに移行することを発表しました。
それに伴ってEclipse Foundationが新名称を決める投票を実施し、その結果をもって、今後は「Jakarta EE」の名称で開発が行われることが正式に決定しています。
https://mmilinkov.wordpress.com/2018/02/26/and-the-name-is/

現在Eclipse Foundationでは、今後プロジェクトを進めるにあたっての開発者向けのサーベイを実施中です。
Jakarta EE Developer Survey 2018

ごく簡単なアンケートです。期限は2018年3月30日11時59分(太平洋夏時間、日本時間では4月1日3時59分)まで。今後注力していくターゲットを考える上での重要な手掛かりになると思われるので、積極的に参加することをおすすめします。

自転車用スマートロック「LINKA」でセキュリティ向上なるか

実は年明け早々に愛車のMTBを盗まれてしまい、新しいMTBを買う羽目になりました。
もう盗まれるのはイヤじゃ、ということで2重ロックを徹底するべく、自転車用のスマートロック「LINKA Lock」というやつを導入しました。

f:id:zinbe:20180124120850j:plain

LINKA Smart Bike Lock - Lock Smarter, Not Harder – LINKA Smart Locks
簡単に言うと、ペアリングしたスマホBluetooth接続が確立しているときだけ、ボタン一個でロック・アンロックできるという代物です。

その他に、以下のような機能もついています。

  • スマホアプリからアンロックできる
  • 1m以内に近いたときに自動アンロックされるモードがある
  • スマホが無いときはパスコードでもアンロックできる
    • でもパスコードの入力はちょっと面倒
  • 振動を検知してブザーを鳴らせる
  • 自転車を停めた場所(最後にロックが作動した場所)をスマホに表示できる
  • スマホに未接続の状態で一定時間経つと、バッテリー節約のためにスリープモードになる
    • 時間は設定で変更できる

YouTubeの解説動画を見ると、なんとなく様子が分かる。
www.youtube.com

ロックの途中でスポークに当たったりすると、安全装置が働いてロックが中止され、スマホに通知が来ます。
また、近づいたときに自動アンロックする機能があるものの、離れたときの自動ロックしてくれるような機能は無い模様。

もともとKickstarterで資金募集してたもので、今は市販されてるものの、169ドルとちょっと高い(ただし、日本にも無料で届けてくれるみたい)。私はメルカリで中古のものを買いました。

実物はこんな感じ。結構ゴツくて重いです。
f:id:zinbe:20180124120945j:plain

私のMTBにはダボ穴が付いておらず、ブレーキ用ブラケットも無いので、タイラップで無理やり固定しました(一応、公式にもタイラップでOKと説明されています)。
こんな感じで、ちょっと不恰好。
f:id:zinbe:20180201090022j:plain

上の動画の最後にあるようにタイラップを裏側に回した方が見た目が綺麗なんですが、私のはシートステーの幅が広めなためうまくフィットせず、写真のようになりました。
内側の横幅は2.1インチのブロックタイヤでもほんの少し若干余裕がある程度。縦幅は、フェンダーが無ければ余裕でした。

取り付けて1週間ほど経ちましたが、今のところ快適に使えています。
特に、コンビニに寄ったときなどにいちいち鍵を取り出す必要が無いのがいい感じです。
バッテリーは1週間で6%減。この分なら2〜3ヶ月に1回充電すれば足りそうです。充電はmicroUSBでできるので、モバイルバッテリーを繋げば良さそう。
f:id:zinbe:20180201134404p:plain

なお、長時間停めるときには、これとは別にワイヤー錠も併用して2重ロックにしています。

現状の不満点を挙げるとすると、次のような感じです。

  • ロック・アンロックが遅い
    • 開始から完了まで3秒くらいかかる。途中で揺らしたりすると安全センサーが働いちゃうので、動かさずに待つ必要がある。
  • ボタンが固い
    • 指が痛いくらい思いっきり押さないと反応しない
  • スリープからの復帰したときに、Bluetooth接続の反応が悪いことがある
    • スマホのアプリを立ち上げ直すと接続されるので、たぶんスマホ側の問題。仕組み上仕方ないのか

私が買ったのは「ORIGINAL LINKA」の方ですが、春にはGPSラッキング機能も付いた新製品が出るみたいです。
GPS付いてても、通信はどうするんだろうってちょっと疑問ではありますが。

ちなみに、同様のスマートロックで「I LOCK IT」という製品もあります。
Bike Lock - I LOCK IT - The Smart Bike Lock
実は最初はこっちの方が気になっていたんですが、公式サイトからは日本には発送していないということで断念しました。
自動ロック機能があったり、オプションでKye fobスマホいらずの電子キー)があったりして、こっちの方がちょっと高機能な気がします。