新型コロナウイルス接触確認アプリのソースコードを請求してみた

厚生労働省の「新型コロナウイルス接触確認アプリ」が公開された。

かねて話題になっていたように、ある程度匿名性を保ったままbluetoothで他のデバイスが近隣に留まったことを認識する方式らしく、割と安心できそうかと思う。

またITMediaの記事によればCOVID-19 Japanという有志によるオープンソースプロジェクトを元にしているそうだ。 ただし、記事を読む限りでは完全にオープンソースプロジェクトそのままというわけではなく「COVID-19 Radar」の技術を核として厚生労働省がベンダーに開発を委託したとある。

そうなると、いくつか気になる点がある。

  • 「COVID-19 Radar」のソースは公開されているからプライバシー等への懸念がある場合にはそれを読んで確認すれば良い、というような意見もあるが、「COVID-19 Radar」と「新型コロナウイルス接触確認アプリ」がその点において同一であるという確証はない。 利用規約には「COVID-19 Radar」のgithubリポジトリへのポインタとそのライセンス上の要請に従う旨は書いてあるが、修正の有無や修正版のソースの所在は明確でない。
  • 有志が集ってTech Giants各社が支援してオープンソースで作り上げたという折角の良い話なので、オープンソースライセンスへの尊重は守りたい。

そういうわけなので、「新型コロナウイルス接触確認アプリ」のソースコードを請求してみた。 「COVID-19 Radar」はMozilla Public License 2.0で公開されているので、「新型コロナウイルス接触確認アプリ」のうち「COVID-19 Radar」を元につくった部分については利用者がソースコードを得られるはずだ。

アプリ内には特にソースコード取得方法については言及がなかったので、問い合わせ窓口として記述されているメールアドレスに開示請求メールを送った。しばらく返事を待ってみようと思う。

追記

こういう、ほぼそのまま使い物になるOSSプロダクトに手を入れてリリースするっていう場合、ロゴやプライバシーポリシーをOSSにしないで済ませるためのメインラインのごく近くを走り続けるforkみたいなのを想像する。ただ、COVID-19 Radarのリポジトリを見ると既に厚生労働省のロゴやプライバシーポリシーが入っているのでそうではないらしい。

更に追記

更新が少し遅くなったが、その後問い合わせ窓口から次のような返信を貰った

本アプリにつきましてはオープンソースで開発をしており、[Covid-19 Radar]としては既に各種情報は公開済で誰もが確認できる状況になっております。 今後開発元であった[Covid-19 Radar]から国に主幹が移管されていきますが、今回のアプリケーションとしての公開方法や場所については現在検討中となります。

この返信自体に疑いを持つ人もいるようだが、ひとまず個人的には信頼できると感じている。

巨大数論の面白み ―― 現代思想 「巨大数の世界」

『現代思想2019年12月号 特集=巨大数の世界』を読んだ。かのフィッシュ氏による巨大数論解説に始まり、巨大基数や組合せ論や、古代ギリシャ以来もしくは仏教における巨大数、巨大数や数学的実体の存在論、永遠についての時間論、はたまたジンバブエドルなどを網羅している。巨大な概念を愛好する向きにはたまらない一冊である。またそれらのトピックが単に巨大であるという理由で任意に集められたわけではなく一定の相互関係を持っている点は注目に値する。

思想史ないし数学史の延長上における巨大数の位置付けは「情報社会にとって『数』とは何か」という大黒岳彦氏の論で述べられていて、これも大変勉強になった。現代の、なかんずくヒルベルト以降の数学が経験的世界から離陸して形相を契機とするようになったというのは確かにそうだし、その流れの中で数学が閉じた自己言及的円環をなす過程で数学基礎論が生まれたというのはきっとそうなのだろう。これに対して一般に巨大数への関心が質料的契機を持つというのもまた間違いない。

一方で巨大数論のファンとしてはやはり、フィッシュ氏の意味での巨大数論が興味深いのは円環を経験的世界にある意味で接地させる奇妙なバイパスとして機能している点にある。 大きな数が面白いのはそれが経験的世界から見て著しく大きいからに他ならないが、その大きな数を競うというアマチュアの遊びが比較的すぐに純粋数学の自己言及的円環を成立させる要たる基礎論の言葉によって理論化されるというのは感動的というほかない。これは純粋数学の力強さを象徴するようでもあり、離陸した円環が落とす影が経験的世界において意味を持つ(おそらくは論で言うところの「下への超越性」によって)ことが、プラトン的な数と経験的世界の紐帯をほそぼそと復活させるようでもあり、そうして興味深いとともにアマチュアの営みがそこへ繋がることがいささか小気味よくもある。

巨大数論の面白み

私にとっては巨大数論の面白みは「寿司 虚空編」004 p.11の「ωだ」の一言に集約される。まさにこの1コマを見たために巨大数論のファンになった。

「ω」だ 小林銅蟲, 2015, 寿司 虚空編 004, p.11

この感動を伝えるには、まず巨大数論のある種の退屈さを述べなければならないだろう。

巨大数が数学の主流から見てトリヴィアルであるのは確かである。任意に大きな自然数は存在するのだし、純粋数学の円環の一部としての必然性も無しにたかが大きな数を作って何が面白いのだろうか。実際、私は現在の日本の巨大数論が生まれた場のすぐ近くまで寄りながらさしたる関心を払わなかった記憶がある ―― 本書におけるp.19「巨大数論発展の軌跡」によれば、現在の日本の巨大数論は2ちゃんねる数学板の「一番でかい数出した奴が優勝」スレに始まっているそうだ。私も同時期に数学板に出入りしていたからこのスレタイは見覚えがあるが、敢えて深く読み込もうとは思わなかった。

一方でそこには素朴な楽しみがあったはずだ。p.82「歴史的に見た巨大数の位置付け」やp.109「巨大数の経験」で仏典の例が挙げられているように、大きな数はそれが擬似的に経験の限界を超越するゆえに人の興味を引く。こうして生まれた大きな数を挙げる遊びが、まさに遊びであるがためにその後につながっていく。

任意に大きな自然数は存在するが、この遊びで勝つためには有限の手続きでその数を述べられなければならない。また、グラハム数Gを挙げることは容易だがこれはG+1に負ける。しかしまたG+1+1+1と後者を挙げていく戦略はもちろんG+Gに負ける。そしてそれらのどれよりもGGが強い。 こうして、大きな数を挙げる遊びはより急速に増大する関数を構成することにすぐさま帰着する。そして、後者から加法を、加法から乗法を、乗法から指数を構成していく過程は空集合から順序数を構成する過程と同型となり、言われてみればほとんど当たり前なのだが、このように巨大数を挙げたり2つの巨大数を比較することは順序数のそれと対応付けられるようだ。そして遂に、現在の巨大数論の先端はωを超えてε0に対応する関数に至る。 巨大数論はそれがアマチュアの遊びに由来することによってむしろ必然的に、順序数や、計算可能関数や、ラムダ計算といった非自明な説明を必要とする。

つまりは、p.14の対談における鈴木真治氏のコメントにまったく同感で、たかだか有限の数――それも大きなものを挙げて勝つという他愛もない遊び――が超限順序数のような無限の世界のものと結びつくというただその一点が何とも愛おしくてならない。

転職エントリ(1年後)

Nianticに転職して1年あまりが過ぎた。

2018年の9月からNianticで働いているのだが、そういえば転職エントリーを書きそびれていた。 転職して以来、相変わらずサーバーサイドの開発をしていている。なお、開発しているのはIngressでもPokémon GOでもハリー・ポッター:魔法同盟でもない。

Nianticとの関わり

Ingressは2014年12月から続けていて、Pokémon GOも日本での正式リリース日からぼちぼちやってきているものの、それにしてもNianticで働くようになるとは思ってもみなかった。 Pokémon GOがなんかえらく流行り始めたときも、自分とは関係ない話だと思いつつGoogle Maps時代の知り合いが何人か関わっているのを思い出して無責任に祝福していたぐらいである。知り合いへのご祝儀のつもりでポケコインを1万円分ぐらい買って、行動圏内にルアーモジュールを設置しまくったのを覚えている。

転職後に変わったことといえば、Ingressのイベントに参加するようになったりPokémon GOのプレイ頻度が増えたことぐらいだろうか。やはり社内でこれらの話題に触れる機会が増えると自然と関心が湧いてくるので。最近もField Test福井に参加してきた。

転職時に思ったこと

こうしてみると以前からNianticに若干の縁はあったのだが、もちろん転職時には他の会社も検討した。検討してみて、いくつかの点に魅力を感じてNianticを選ぶことになった。たとえば、東京オフィスにいる人達の半分くらいは顔見知りで、彼らと一緒に働くのは楽しそうだと思ったこと。色々と興味深い解くべき技術的課題を持っていて面白そうだったこと。 なかんずく、見知らぬ土地に出かけたり歩いたり、人と関わることを促進するような未来像・理想を語っていること。こういう性質はひょっとしたらエコーチェンバー現象を抑制する1つの解になるかもしれない。

1年経ってみた感想としても、こういう自らミッションステートメントを掲げてきちんと計画して、真面目にミッションに向けて取り組んでいる組織ってのはやはり良いもんだと思う。

もとより私はオフラインのように豊穣でオンラインのように便利で安全な世界ってものを望んできた。 リンク先の文書を書いたときに比べれば、なるほど状況はやや変わっていて最早オンラインとオフラインを分けることが無意味になってきてはいる。何しろ今日では常時のインターネット接続が実質的な基本的人権とすらなりつつあるのだから。それにしても、「ネットワーク化済み実在とネットワーク未接続実在」とでも読み替えればもうしばらくは通じるだろう。 いずれにせよNianticの語る未来像は私が望むそれと通じるし、前掲記事中でも触れられているARのような技術は当然にその有力な構成要素であると思われる。

これまでの私の経験則によれば、こういうなんとなく自分の好みな方向の美意識や社会的問題意識に基づいた未来像に協力しておくと、そのうちに自らリードしたいと思うようなすごくのめり込めるものに行き当たって、しばらくは楽しめるはずだ。そういうわけで、当面はこういう未来像を実現する上で私ができる役割を果たしてみたいと思ったのだった。

念のため: この記事は筆者の個人的な経験および意見について述べており、筆者の雇用主とは一切関係ありません。

福井行

IngressField Testがあるので福井に行ってきた。 Field Testは国内でも数か所で実施されるのでどこに行こうか結構迷ったのだけど、結果としては福井で正解であった。なんだか、自分でも思った以上に福井と縁があったので、終始それを感じて楽しめたのである。

さて、まず福井につくなり駅の階段で迎えてくれるのが永和システムマネジメントの広告である。Rubyといえばesm, esmといえば福井が本社なので、最初からそこはかとない安心感と親近感を覚えさせてくれる。

次に、階段を降りたところにいるのが見慣れた恐竜博士の像。ながらく表参道で働いていたのだけれども、昼休みによく歩いたあたりに福井のアンテナショップがあって、その前にも恐竜博士がいたものだった。見慣れた姿を本場で見ることができて感激する他ない。

聞けば、福井駅には恐竜博士があと3体いるそうな。改札口をでたところにも確かに居た。他にもえちぜん鉄道福井駅にもいるのを後に発見するが、残り1体は所在がわからなかった。

さて、メインのField Test中にポータルを周る際には福井のエージェントのかたがたとご一緒できて(途中ではぐれたけど)、とてもありがたかった。なんとかメダルを獲得できたけれども、時間内に3000m歩くという項目はかなりギリギリだった。記録上は3017mとなっている。

天気にも恵まれて適度に曇って暑すぎず、良いIngress日よりだったように思う。FT福井の中の人には改めて感謝したい。

FT福井の翌日、この日は当初からあちこち見て回るつもりでいた。さて福井といって思い出すのは福井県民が活躍する『ミカるんX』であろう。いやかなり偏った見解かもしれないけど、あの作品のファンなので。そういうわけで聖地巡礼としてソースカツ丼を食べて、恐竜博物館に行かなければならない。

恐竜博物館については良い評判を聞いていたものの、実際にはその期待をもはるかに上回った。常設展示場にはいるとすぐに圧倒的な物量の化石骨格標本が目に入る。よく見渡せば古生物学だけに限らず地質学全般の展示もあり、標本の種類も解説も凝っており、完全に堪能しようと思ったら1日ではまるで足りないことが分かってくる。 残念ながらそこまで時間はないのでめぼしいところだけ見たものの、ぜひまた来たいものである。

Ingressポータルを巡りながら勝山駅まで歩き、えち鉄で福井に戻る。

ソースカツ丼ヨーロッパ軒を薦められたので、その晩に行ってみた。

時間管理研修の話

ある社内研修の一コマだった。 私は受講対象者ではないんだけど、良く覚えていない謎の理由によりオブザーバーとして参加していた。 ちょうど講師が「重要でなく緊急でもないもの」「重要でないが緊急のもの」「重要だが緊急でないもの」「重要で緊急のもの」って例の話*1をしていたときだった。話がだいぶすすんでそろそろ次の話題に行こうかというところで、はたと気づいた。私を含めて参加者の半分ぐらいがラップトップを開いてメールやSlackをチェックしながら聴いている。これはどうしたことだろう。

この手のメールチェックってのは往々にして「重要でないが緊急なもの」か「重要でも緊急でもないもの」だ。少なくとも私がやってたのはそうだった。 そこで、その場で参加者に訊いてみた。「私も含めてみんなメールチェックしてたけど、それって重要で緊急なものですか? もしそうだったらお忙しいところ参加頂いていて大変申し訳ないんだけど、全員がそうって訳でもないんでは?」 すると、全員が「重要でないが緊急なもの」をやっていた。

一方で研修なんてものはおおよそ緊急でなく、でも会社はそれが重要だと思ってなけなしの研修予算と研修時間枠を使って投資している。つまりこれは「重要だが緊急でないもの」だ。 仮に参加者が「こんな聞き飽きた話はくだらねー」と思っていたとしても、会社はそう思ってないのだから、ならば速やかに「この研修くだらねー」という適切なフィードバックを与えるのは重要な仕事だ。

なんということだろう。我々は「重要でないが緊急なもの」より「重要だが緊急でないもの」を大切にしよう、という話をまさに聞き、うんうんそうだよなと思いながら、最後の最後まで疑問を持つことなくその逆をやっていた。つまり今まさに間違った優先順位を付けて、「重要だが緊急でないもの」について成果を出してなかった。

おそらくこれこそが、「重要だが緊急でないもの」に時間を割こうという話なんだろう。この話はきちんと説明されれば当たり前のことを言っている。漫然と聞いていたら誰もそこにさしたる疑問を抱かない。ただし、それを我がこととして引きつけて考えるには集中が必要だ。どんなに当たり前の話に聞こえたとしても、それを理解するの思考リソースを割く必要を感じなかったとしても、受講した時間から真に価値を引き出すためにはそれを真剣に考えることが必要だった。

バックグラウンドで思考する」ってやりかたもあるが、そのために必要なフォアグラウンドタスクはアルキメデスの昔から典型的には入浴とか散歩とか落ちものゲーとかそういうやつで、メールチェックや定例会議ではない。 「重要だが緊急でないもの」にきちんと取り組むには、「重要でないが緊急なもの」を明確に排除して存分に取り組む時間を意識的に作らねばならない。

我々は、図らずもその意味を研修の中で実証したのだった。

*1:ビジネス書で引用されすぎていてどこが元ネタなのかよく把握してなかったんだけど、今調べた限りでは『7つの習慣』なのかな?

ブロックによるRuby内DSLの起源

言語内宣言的DSLを構築するRubyの能力がいつからできたものなのか、ふと疑問に思った。

この手の記法で一番古くからあるものとして思いつくのはTk bindingだが、これはいつ頃からあったんだろう。 そう思って古いRubyを見てみた。fj.sourcesにて最初に世界に向けて流されたというruby 0.9.5を見てみると、sample/tkhello.rbに次のような例が既にある。

TkButton.new {
   text 'hello'
   command proc{print "hello\n"}
   pack('fill'=>'x')
}

MatzがLispを意識していて1LispDSLが盛んに構築されていたことを考えると、これはMatz単独の発明ではないかもしれない。でも、この時点で既にブロックというRubyの機能を用いて宣言的にものを記述するという発想はあったことは分かる。

たとえブロックという制御構文を自作するための記法があったとしても、宣言的語彙を構築するという意思がなければAPIはこんな感じの筈だからだ。

TkButton.new {|btn|
   btn.text = 'hello'
   btn.command = proc{print "hello\n"}
   btn.pack = {'fill'=>'x'}
}

ChefやVagrantfileRSpecといった現代のDSLを知っているとすこし物足りないのは確かであるものの、基本的な形はRubyが最初に一般に投稿された1995年の時点で完成していたことが分かる。

ただし、この発想が更に一歩進んで臨界点を超えて広まり出すにはRakeを待つ必要がある。そして、最後の部品である表現能力のさらなる探索はRSpecによってもたらされたと言うべきであろう。


  1. そもそもRubyにはMatzLispというあだ名があったわけだけど、割とあとのほうになるまで、nilが空配列と同等に扱われるケースが広く残っていたりというあたりが思い当たる。

Corporate Reliability Engineering

最近、SRE - Site Reliability EngineeringのアナロジーとしてCorporate Reliability Engineeringというのを考えられないかみたいな話を社内でしている。

SREは伝統的なシステム運用チームの仕事を再定義したものだ。SREはシステムの安定だけを至上目的にするのではなく、際限なく増え続ける運用タスクを真面目にこなすことを目的にするのではない。開発チームを巻き込んで適切なシステム安定度を見いだし、より少ない手間でシステムを安定運用するための開発を自ら行なう。運用のルーチンワークに費やす時間を全体の50%に抑えるように努力する。そして残り50%で今後もその配分を保つ為の開発や、更に上を目指すための仕組み作りを行なう。

同じ発想は業務システムや社内セキュリティ、更にはコーポレート部門にも適用できるのではないか。つまり、業務システムを運用して社内業務を回すとか社内セキュリティを保つ業務、あるいは人材を募集したり経費を処理したり業務についても、際限なく増え続けるタスクを間違いなくこなすことを目的にしないやり方があるのではないか。 相対する部門と共同でより少ない手間で適切なエラーレートを保って回していく仕組みを作り続けるのが重要で、それに時間の50%を使うべきではないか。

うちの会社はWeb系スタートアップ文化から出発している一方で、急速に規模を拡大している関係上で管理すべき物はしっかり管理する必要に迫られている。そこで、管理が物事を堅苦しくしたり管理コストが線形以上のオーダーで爆発したりしないためには、SREの思想が必要なんではないか、という話を最近している。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム