国際ID

住基カードが失敗し、政府はマイナンバーカードの普及に躍起になっている。資料によると既に1700万枚が発行されているようで、意外と普及しているなあ、というのが正直な感想だ。マイナンバーそのものは既に役所や会社で使われているのだろうが、カードとなると確定申告くらいしか利用シーンが思いつかない。コンビニ交付にも使えるのかもしれないが、住民票や戸籍謄本が必要になるシーンなんてそれこそ何年かに一回だろうから、カードを作る方が手間が掛かる。

そこで、健康保険証などに使えるようにと普及策を図っているのだけれども、そもそもマイナンバーカードって国民IDじゃないんだよね、というのがどうも引っ掛かる。海外在住の日本人は持てず、逆に定住外国人は持てるわけだ。住んでなくても健康保険証は一時帰国時に必要だし、その時に戸籍謄本が欲しいことだってあるだろうに。

転じて外国を見てみると、国民IDカードなるものを発行している国は、そんなに多くない。先進国でもだ。そこで考えるのだけれども、この国際化社会の時代、サービスの電子化に当たり、国民かどうか、その国に住んでいるかどうかというのは、昔よりも重要性が低下してきているのではないだろうか。IDカードを発行する云々の前に、ID自体の設計はこれで良いのだろうか、考え直す時期ではないだろうか。

この参考となるのが、イギリスやオーストラリア等のIDである。オーストラリアを例にすると、まずIDは誰でも取得できる。それこそGmailのメールアドレスがあれば、パスワードと複数の認証フレーズ(最初に飼ったペットの名前等)だけで登録できてしまう。

しかし、IDとパスワードだけでは、使えるサービスはInbox(郵便受け)、求職、家探しなど、基本的なことだけだ。そのIDと本格的なサービス(例えば年金など)を結び付けるには、あらかじめ年金サービス側でサービスに加入しておいて、そのIDを登録する必要がある。更に、パスワード認証だけではダメで2要素認証を必要とする、など、IDとの紐付けにはセキュリティ的な条件がある。

しっかりした認証を通ったIDを通じて既存のサービスを登録する、その登録段階にも認証があれば、文句はないだろう。基本的にはこういう考えだ。色々なネットワークサービスには自社IDではなくGoogle IDを使えるようなものがあるが、あれをもう少し厳格にしたような感じである。

この例が意味しているのは、本人認証のためのIDと、特定のサービスに加入していること(国民であること、住民であることも含め)を示すIDとは別だ、ということである。更に言うなら、IDは重要だがIDカードは重要ではない。カードの所持は認証の一手法であり、近年ではスマホ認証なども進化してきている。将来的に生体認証の精度が上がってそれだけでOKになる可能性すらある。本人認証のためのID、IDの認証手段、特定のサービスへの加入証明は、全部独立して考えられるべきだ。

そう考えると、オーストラリアの手法は非常に合理的だ。だがもう一歩足りないのは、それがオーストラリア人のことしか考えていない、ということだ。先に話した通り、もう国際化の時代なのだから、世界中のあらゆる市民に開放すべきなのだ。

これに最も近い位置にあるのがGoogleだから、これを基にして考えてみる。まず、AndroidはFIDO2認定を受けたので、これを最高のセキュリティとみなす。今でもGoogleは多数のオンラインサービスにID登録を許していて、それは一覧で見ることができる。ここを少々改造する。

登録をする時と実際に使う時の各々で、必要な認証のレベルを設定できるようにする、というのが改造の内容である。例えば確定申告のIDとして使いたい時、まずマイナンバーのサイトから「Google IDを使う」ボタンを押すと、Googleのサイトが開き、「登録しますか？」と出る。ここで「はい」と押すと、確定申告の場合は生体認証が必須とされているので、スマホで指紋認証すると登録できる。実際に使用するときも、同じく指タッチする。

サービス側は、Googleのセキュリティ管理体制を審査し、信用に足ると思えば「認定」を行う。もちろんセキュリティ段階に応じた使用制限付きだ。この場合は指紋認証を登録と使用各々で使うこと、であるが、こういった具体的なものではなく、セキュリティレベルXの認証を登録と使用で使うこと、といった抽象的な表現になる。例えば指紋でなく虹彩認証が開発されたとして、それが指紋より劣っていると思えば、それは認定の対象にならない、というわけだ。もちろんこの審査は随時可能であり、必要とあらば認定を取り下げることもできる。しかし各々のサイトには既に登録しておいてからGoogleと接続するため、IDが切り離されるだけで、使えなくなるわけではない。

こういったサイトはGoogleだけでなく、多くの民間・公的な企業・機関が設立可能であり、相互接続もできるようにする。こうすると、国が直接認定せずとも、相互信頼性が確保できれば接続できることになる。例えばマイナンバーでオーストラリアのMyGovにログインできる、というような体験ができることになる。

また、不正使用の危険が国際的になるため、証跡管理は必要になる。これは、単純にはID連携をした者(自治体等)が、どのIDを信頼してどんな手続きをしたのかのログを取ることである。電子署名等は当然であるが、ID連携者が加害者である場合もあり得るので、ブロックチェーンのようなゼロトラストの概念を導入することが望ましいと考えられる。

このIDは、本人が希望しない限りID連携を行わない。マイナンバーカードで問題になった基本4情報(名前、住所、生年月日、性別)すら、デフォルトでは提示しない。ID業者自体はID同士の連携は行うが、自らは情報をもたない(持ってもよいが)。こういうサービスであれば、国民も納得するのではないか。

ブレーキ踏み間違い防止策

高齢者がブレーキを踏み間違える事故が多発しているが、これを防止する策を考えてみた。

仕掛けは簡単だ。ダッシュボードのフチにLEDライトを仕込み、アクセルを踏むと青、ブレーキを踏むと赤に光るようにする。もし間違えてアクセルを踏んでしまったら、青く光るからすぐに分かる。たったこれだけだ。

明かりの強さは、踏んだ強さに比例するように、アナログ的に段階を付けることにする。強く踏むと明るく光る。ダッシュボード一杯に線状に広げればどうやったって目に入るし、同乗者も直ぐに気付くことができる。監視カメラがあれば外に光が漏れ、踏み間違いか故障かも直ぐに分かる。運転者としては、普段からも光っているので、色と感覚が結びつき、より間違いにくくなるはずだ。もちろん、高齢者でなくとも十分に役に立つはずだ。

この仕掛けは、法律で義務化せずとも、自動車用品専門店で後付けにすることができるだろう。法令的には問題ないはずなので、今すぐにでも検討してほしいと思う。

動く軌道上を走る列車

リニアモーターカーが車輪を使わないのは、車輪による摩擦力で前進できる速度の限界が300km/時とか350km/時とかで、それより早く走ろうとすると滑って速度が出ないからだそうだ。だとすれば、動く歩道(無限軌道)の上を走るようにすれば、その限界を超えられないだろうか。これが本提案の骨子だ。

話はこうなる。駅の中間地点を境にして、動く軌道を設置する。最初は停止しているが、列車が動き出すと、それに呼応して動く軌道も動き始める。こうすると、列車本来のスピードに加え、動く軌道の動くスピードが加算され、より速く走れるというわけだ。

もっと極端に言うと、列車自体はただ軌道上に乗っているだけで、車輪すらない、軌道だけで進むようなものがあっても良いかもしれない。原理的に考えれば、軌道を回す速度には限界はないからだ。だがまあ、空気抵抗はあるわけだし、動く軌道が500km/時で進めるとも思えない。なによりも、いざというときに自ら動けないのは不安だ。車体にも駆動機構をつけるべきではあるだろう。

軌道は端の部分で裏(下)に折り返すことになるので、従来のようなロングレールは使えない。これはいわゆる「ガタンガタン」という騒音の原因になる。これを緩和しないとうるさくてしょうがないし、磨耗の原因にもなる。これを解消するためには、軌道の上面では各レールを後ろから押すようにして動かすようにする。こうすると軌道上面ではレールがくっつくので音がしない。また熱でレールの長さに誤差が生じても常にくっついたままになり、下では離れるようになるので、曲がる心配がない。

但し、軌道と軌道の繋ぎ目では音がしてしまうのは仕方がなく、しかもその距離は通常のレールのつなぎ目より遥かに長い。そこで、レールは2本ではなく4本以上として、つなぎ目の位置を前後にずらす。これによって、一つの車輪が浮いても他の車輪が接しているために大きくは落ち込まず、音のタイミングが分散するので目立たなくなる。この二つの機構はカーブでも役に立つ。

欠点は線路のキロ単価だろう。リニアモーターカーよりはローテクだろうが価格は匹敵する可能性がある。耐故障性も気になる。だがまあ、空想の世界としては面白そうだ。

海上に住む権利

海の上に住む、川の上に住むという風習は、新しいものではない。しかし現代では、川岸や海岸にも権利があり、好き勝手に住むことはできない。埋め立てずに柱を立てて海上住宅を作るにも、船を係留してそこに住むにも、関連各所への許認可や費用は発生するだろう。

もし海岸に土地を持っているとしたら、その土地を掘って湖のようにしてから海と繋げ、敷地内に海を広げてしまうということは可能だろう。その海の上に船を浮かべ、そこに住むとしたら、法的な扱いはどうなるのだろう。

まず、そこが海とみなされるのかどうか。その海の占有使用権や漁業権、水利権、係留権はどうなるのか。掘った土地の面積は、税法や登記上、減るのか。そこにごみを捨てたらどうなるのか。浮かべた船は住居とみなされるのか。入ってきた海水は自由に扱ってよいのか。など等。

なぜこんなことを考えたのかと言えば、地震対策だ。地震が起きても水の上なら揺れは緩和される。もし津波が来ても、入り江になっているから津波がそこで高くなることはない。想定より高くなって溢れても船の中だから、基本的には係留を解いて海に向かって進んでいれば、たとえ内陸まで流されても水が引くまでには海まで脱出できる。海岸にいれば、流された建物などに当たることはないだろう。せいぜい流木に気をつけるくらいで済む。

更には、地震があったらその時点で沖に避難することもできるだろう。万一内陸に取り残されても、双胴船にしておけばひっくりかえることはなく、とりあえず命は助かる。その後の避難生活も、とりあえずはそこでできるだろう。

郵便物や宅配ピザは届けてくれるだろうが、インフラはダメだろうから自前である。これを例えば、トイレの汚物をそのまま海に流すとすると、敷地内だから勝手なのか、海だから不法投棄になるのか、などは、確認しないと設計できないことになる。ちなみに糞便は魚の餌になるので、ちょっとした漁場になる期待もある。もしダメなら入り口にゲートを設ければ何とかならないだろうか。

電源を太陽電池にして水を海水逆浸透膜にすれば、電気水道はOK。ただ、海水を勝手に使ってよいのか、ろ過後の濃い海水をその場に捨ててよいのかが分からない。

海岸には二束三文のところもある。船は仕方ないので特注で作るとしても、建築基準法は関係ないし固定資産税も安いだろう。権利や資金周りが上手くいくなら試してみたい気もするのだ。

AGIアーキテクチャ

汎用人工知能（Artificial General Intelligence)のアーキテクチャについて、こんなものはどうだろう、というアイデアがある。 

基本は従来の専用AIだ。それはフィードバックがあってもなくても良い。普通のニューラルネットワークである。その層数や入力量は、通常のものよりずっと大きくなるだろう。まずは単純化のために、画像認識を例に挙げる。

そのAIは、画像用の入力と回答出力、そしてコマンド入力からなっている。コマンド入力を除く部分は、通常の画像認識AIと同じである。まず教師付きデータを大量に用意し学習させる。出力は自然言語(テキスト)である。

コマンド入力が少し違うところで、これも自然言語(テキスト)である。学習はコマンドもセットで行う。つまり、同じ画像でもコマンドと答えの異なる教師データが複数あるわけだ。例えば、「これは猫か？」「はい」と、「この動物はどちらを向いているか？」「右」などである。

これを大量に学習させていくと、想定した答えに対してはだいたい合った答えを出すようになる。ここから先が問題で、このコマンドセットが正確に合っていなくても、つまりコマンドセットにない新しいコマンドを与えても、それなりに正しい答えを出せるようになるのではないか、というのがこの主旨だ。つまり、「この動物は右を向いているか？」「はい」という学習データがなくても「はい」と答えてくれるのではないか、ということだ。

コマンドセットは自然言語なので、多くの単語と文法を含んでいる。そしてその組み合わせも無限にある、だから無理だ、と想像してしまいがちだ。しかし考えてみれば、同じ猫の画像なんてそもそも存在しない。黒猫と三毛猫のどちらも猫と認識するには、そういった無限の画像に対する学習記憶が残っているからだ。これが言語には及ばない理由はない。

これはまた、そもそもAGIなんてものは存在しないのだ、人間は高度な専用AIに過ぎないのだ、という主張にもなる。上の例では「猫」「動物」「右」しか出てこないが、この語彙が三千になり、学習データが何兆もあれば、中学生レベルの受け答えはできるようになるのではないか。そもそも中学生レベルでは知らない言葉も多く、大人の会話はできないかもしれないが、それでも彼らは一人前の人間である。それと同じではないのか、ということだ。

この先にあるのは、「気を利かせる」「新しいことを考え出す」アーキテクチャだが、基本的にはこの延長である。聞いていないことを答えた時に、それが人から見て適切であれば報酬が貰えるような仕掛けを組み込めば、やはり教師付き学習とその後の追加学習によって、色々な性格のAIを生み出すことができるだろう。

本当の問題はアーキテクチャなのではなくて、(アーキテクチャと学習の)物量だったのだ、と思い知る日が来るのかもしれない。

AWSの弱みと逆転の可能性

Googleが少し追い上げてきているらしいが、世のクラウドはAWSが席巻している。これを逆転する方法は無いものか、考えてみた。

可能性はある。それは、AWSが余りにも肥大化してしまったことだ。この肥大化とは、使われている量的な話ではなく、機能が増えすぎてしまった、というところである。つまり、これは「イノベーションのジレンマ」を引き起こす元凶になりうるわけだ。

サービスであるので、使い続けないといけない。一度立ち上げたサービスはなかなか止められない。新しいサービスのみに統一する必然性が無いので、何時まで経っても古いものを捨てられないのだ。

その逆転策の基本方針は簡単で、抽象度を上げたシンプルな開発基盤を作ることである。例えばEC2を見せないことだ。アプリケーションは全てLambdaで記述し、データベースはサービスとして提供する、といったように、レスポンス(スケールアウト)、可用性(障害時の実マシンやネットワーク切り替え、バックアップ等)といったいわゆる非機能要件を実現するための仕掛けを全て隠し、要求事項をソースコードで示すだけ、とする。

また、オンプレミスとクラウドの扱いについても、オンプレミスにはアプライアンスを積み重ねるだけとし、SIの必要性を極限まで落としておく。非機能要件には、可用性やスピードの他、このオンプレミスアプライアンスの使い方、課金方法、セキュリティの程度、非常時の運用(クラウドに逃がす、リストア等)等が書かれている。

また、自社クラウドとAWSとの相互シームレス移行をサポートしておく。AWSへの移行はできる(だが遅い、高い)としておけば、顧客としては一応安心できるし、AWS以外のMSやGoogleクラウドとの相互移行もサポートしておけば、より安心だろう。

こうなると、AWSなどのクラウド業者はいわゆる土管に成り下がるわけだ。移行がリアルタイムレベルで簡単になれば、いつかあった値下げ合戦もまた起こるだろうし、安易に縮小すれば信頼を一気に失うから、まさにジレンマに陥れることができる。

消防ドローン

消防庁が、消防飛行艇の予算を試算したそうだ。初期費用380億円、維持管理費は年間20億円。これに対して消防庁の予算は100億円なのだそうだ。

これを聞いて、直ぐに「じゃあドローンにしたらどうだ」と思った。100kg級のドローンを作ってもせいぜい数百万円、例えば200万円として、これを百台作っても2億円にしかならない。これで10トンの水を運ぶことができる。

消防飛行艇が活躍する場は、山火事や大震災後の火災などだろうが、逆に言えばこれに限られる。ドローンなら普段の火災から活躍でき、大規模火災には集団で取り組めばよい。一度にドカンと落とすことも、バケツリレー式に連続して、あるいは帯状に落として避難者の退路を確保するなど、様々な投下パターンが組めるし、飛行艇では無理な量も数でカバーできる。

ここで問題になりそうなのは、火事だから当然上昇気流があるわけで、煙も発生しているはずだ。つまり飛行機ですら安定しないのに、それより小さいドローンで大丈夫か、というところだろう。

その心配はアタリだが、対応不可能な理由ではない。工夫することで幾らでも対処可能だろう。また、百機がぶつからないように操縦する必要はあるが、これはコンピュータ制御が必要になるだろう。それも既に類似の技術はあり、本質的な困難ではない。