2019年3月21日木曜日

RPAの罠


http://www.soumu.go.jp/menu_news/s-news/02tsushin02_04000043.html

総務省によると、RPAには三つの段階があるのだそうだ。クラス1がいわゆるRPA、クラス2はEPA(Enhanced Process Automation)と呼び、自然言語解析などの解析、非構造化データの読み取りや知識ベースの活用。クラス3がCA(Cognitive Automation)で、プロセスの分析や改善、意思決定まで自動化する。

個人的にはちょっと大雑把過ぎるなあ、と思うのだが、逆に言えばまだそんなレベルなのだろう。今のところ、気軽に触れるものは全てクラス1だ。このレベルでは、RPAといえどもプログラミングが必要である。

個人的にも、無料で触れるRPAを幾つか触ってみたが、ハッキリ言って素人お断りの難しさだ。現場での改善など望むのは不可能で、プロに頼むのであればなんでRPAにしなければならないのか、業務プログラムでよいのではないか、とすら思う。

また、例えば事務作業の補助を頼むにしても、実際のところ細かい例外や曖昧なところは一杯あって、クラス1で作ってしまうとそういうところを全部飛ばしてしまい、あまり役に立たないことが多い。

Excelのデータで、ゼロと空白とハイフンにどんな意味があるのかは、グラフによって違ったりする。たまに文字が入っていても人間なら読み取れるが、クラス2までならそもそも無理だ。その条件を最初から抽出するにはデータを全部見なければならないなど、労多くして作業の手間があまり減らないことになる。人間の常識の偉大さを垣間見るだけだ。

こう考えると、クラス3にまで行かないとRPAは殆ど役に立たないのではないか、と思えてくるのだ。ちゃんとした手順はイコールプログラミングであり、細かい例外が一杯あるプログラムは作り辛い。それをAIでチャチャっとやってくれるというのは理想ではあるが、期待通りにAIが動くとは限らないから検証が必要で、その検証に時間をとられれば結局プログラミングをするのと一緒、大して変わらない、というわけだ。

この原因は、世の中が汚いデータで溢れていることもある。見易さを重視して機械可読データとしての価値を無視した神Excelのようなものが主流である以上、RPAの将来は暗い。

2019年3月20日水曜日

監視カメラビジネス


以前より、5Gの評価は価格体系が出るまで保留、と言ってきた。いくら速くてもパケット単価が同じであれば、パケ死までの時間が短くなるだけだ。多少は安くなるだろうことは予測できるが、問題は大々的に安くなるかどうか、である。中途半端な下がり方では、せっかくの宝も持ち腐れで終わるだろう。

そんな中で考えるのが、今までも需要はあったものの、費用対効果の問題で二の足を踏んできたようなものが、5Gの価格低下と共に息を吹き返す可能性である。代表的には、比較的容量の大きいIoTだ。

IoTを設計するときに、無意識に容量節約してしまっているものがある。例えば監視カメラだ。今の監視カメラの多くは有線でつながっている。無線でつながっているものは、常時垂れ流すのではなく、センサや画像解析をローカルで行っていて、インシデント前後で集中して送るようになっているだろう。これはこれで正しいのだが、もし垂れ流しができるのだとしたら、別の用途がある。

監視カメラを設置した当人は防犯にしか興味が無くとも、警察は逃走者追跡に使いたいと思うかもしれないし、気象庁はローカル天気の把握に、消防庁はボヤの早期発見に、と色々用途はある。それを切り売りできるのなら、これは新たなビジネスになるわけだ。

もちろんよこしまな会社は排除するとしても、そういう公共目的で監視カメラ映像を定額で買い取るようなサービスが生まれれば、それ目的で多数監視カメラを設置するというビジネスは成り立つ。これは更に、そういうカメラの標準化にも貢献し、カメラの価格が下がる。太陽電池と組み合わせることで、それこそ設置場所さえ確保すれば電源も通信も不要、なんてことも夢ではない。

設置に関する制約が大いに低減されることで、街どころか田んぼや畑、山中、部屋の中、あらゆる場所に監視カメラが設置され、ビッグデータが日々生まれ、生活が改善されることに繋がるわけだ。

監視社会というと警戒感ばかりが先に立つが、使い方、考え方次第である。

2019年3月19日火曜日

オーケストレーションからOSへの逆進化


FaaS(Function As A Service)を構成するだけが目的のサーバ群を自動で構成する。これには、まずLinuxを入れ、Dockerを入れ、Kubernetesを入れ、KLRを入れるのが順当だ。だが、最初からこれだけを目的とするのであれば、もっとシンプルな専用のOSを一つ入れるだけで全部済む、というような仕掛けができるのではないか。

既に動いているシステムサービス内に新たなサーバが加わったら、自動でそのOSをインストールして再起動すれば、リソースとして割り当てられる、という仕組みだ。ファンクションが動けば良いだけなので、実行環境の隔離さえできていればよい。極端な話、素のLinuxで、実行空間分離さえできていればよいことになる。

ストレージとネットワークのドライバ、セキュリティ、権限管理はローカルで入るが、上位のサービスは全てアプリとし、単一故障点のない分散ソフトとしておく。そうすれば、サーバがどう壊れても入れ替わっても、システムは堅牢だ。

SIも殆ど不要になる。故障の検知も制御ソフトに入るし、ネットワーク接続の検知も自動。壊れれば取替え、負荷警告が出れば追加するだけ。これなら誰でもできる。

上位の機能として何が必要かは、既にオーケストレーションツールには分かっているから、今更作りこむ必要はないだろう。

余計なミドルが入らないことによってソフトがシンプルになり、性能が上がり、使い勝手も上がる。そんなふうになったら、ネットワーク負荷がない分、オンプレミスの方が有利だ。上手くすれば、オンプレミスがクラウドに対抗する、復権する手段として、これは伸びていくのではないか。

2019年3月18日月曜日

高セキュリティ決済体系


クレジットカード詐欺被害が、だんだん深刻になってきている。特にオンラインでカード番号を晒すのは、相当に危険になってきたと認識している。

しかし、クレジットカードは捨てがたいところがあって、定期的引き落としにはほとんどこれ一択と言っていい。口座振替は設定や解除がオンラインでできないし、他の手段ではそもそも選択肢がない。決済全体で俯瞰して、最適な方法が欲しい。

これらを整理すると、以下のようになる。皆、従来のものと似ているが、少しずつ違う。
  1. Suica系交通カード。定期券が設定でき、それ以外に電子マネーチャージができる。電子マネーチャージは、後述のバーチャルクレジットカードで行う。チャージは買い物には使用できず、全て交通系の決済のみに使用される。オサイフケータイで可。その場合は、パスワード等でのロックも選択可。
  2. 認証付き電子マネー。決済要求に対して毎回スマホに通知が来て、認証しないと決済できない、あるいはあらかじめ次の一回のみ許可する設定ができる。後者の場合、タイムアウトで前者に戻る。このチャージにも、後述のクレジットカードを使う。オサイフケータイで可。その場合は、パスワード等でのロックも選択可。
  3. リアル(物理的カードのある)クレジットカード。決済要求に対して毎回スマホに通知が来て、認証しないと決済できない、あるいはあらかじめ次の一回のみ許可する設定ができる。後者の場合、タイムアウトで前者に戻る。異なるブランドで1枚ずつ。例えばVISAとMaster。
  4. バーチャルクレジットカード。幾つでも発行でき、オンラインでのみ使用する。機能として①支払先限定(最後の支払先を記憶し、そこからの引き落とし要求のみに対応する。入金(為替差益還元、組み戻し)には常時対応する)要否、②決済要求に対するセキュリティ対応(リアルクレジットカード相当)要否、が各々選択できる。
使い方、使い分けはこうなる。
  1. 公共料金、インフラ料金、スポーツクラブや塾などの会費といった定期的な引き落としには、支払先限定、都度確認不要のバーチャルクレジットカードを用いる。支払先ひとつにカード番号一個を発行する。
  2. 交通系の支払いには、Suica系交通カードを使用する。チャージには、支払先限定、都度確認不要のバーチャルクレジットカードを用いる。
  3. 店舗等での都度支払いには、認証付き電子マネーか、リアルクレジットカードを用いる。認証付き電子マネーのチャージには、支払先限定、都度確認必要のバーチャルクレジットカードを割り当てる。
  4. オンライン決済では、バーチャルクレジットカードを用いる。これもECサイト毎に別の番号を割り当て、支払先限定機能を有効にする。都度確認については、著名なサイトではオフにしても良いが、通常はオンにする。
ユーザ体験はさほど複雑にならず、むしろサインや暗証番号不要となる可能性すらある。詐欺被害の可能性を大きく減らすことができ、既存の店舗やECサイトの仕掛けも殆ど弄らなくて済む。確認の仕掛けとしては費用が掛かるが、詐欺被害への補填や保険を充てれば、誰の負担も増えないだろう。

これらのサービスは別々でも良いが、単一の銀行が対応してくれるとポイントが共通化できるなど有利だ。オンライン銀行、例えばジャパンネットバンクはきわめて近いサービスを行っているのだが、まだ足りない。もう少しがんばってくれないだろうかと思う。

2019年3月17日日曜日

ブロックチェーン遺書


遺書のデジタル化に関しては、意見は色々とあるものの、日本としてはまだ具体的な動きはない。遺書情報そのものに関しては動きがあるようだが、遺書そのものがデジタル化されるわけではない。

日本ほど遺書の運用が厳重でないところでは、この動きがあるようだ。遺書そのものというよりは、死をトリガーとしたスマートコントラクトで仮想通貨を送金する、といった応用が考えられているようだ。仕掛けとしては面白いが、法が絡んでいないために正式なものとは認めがたい。ここはやはり国が制定すべきであろう。

ブロックチェーンには欠点も色々あって、必ずしも未来の技術とは言い切れない。しかし、こと「遺書」に関しては適切だと考える。その理由は以下の通りだ。
  1. 遺書は、一生のうちそう何回も作り直すものではない。せいぜい数十回が上限であり、平均すれば数回というところだろう。分量だってせいぜい数枚から数十枚で納まる。また、人口も平均余命も大きくは変化しないから、データが増える速度は予測可能且つ大変動しない。ブロックチェーンの大きな欠点の一つである、「台帳の容量が永遠に増え続ける」「計算速度が遅い」といった問題は、問題にならない。
  2. 保管が重要であって、システムは大して複雑ではない。極端な話、PDFで保存すればよいだけだ。高度な計算を必要としない点は、ノードの単価に有利に働く。
  3. 改ざんの可能性は、ブロックチェーンへの参加者の信頼性で決定される。遺書であれば官庁自治体のチェーンにすべきだろうから、51%攻撃などということはあり得ない。
  4. 一方で通常のコンピュータシステムでは、クライアントサーバやバックアップ等、複雑なSIをしなければならない。同質のクライアントをインストールするだけでよいブロックチェーンは、システム構成上有利だ。特に自治体で構成すれば数千に分散するので、DR(ディジャスタリカバリ)は完璧だ。保守もほぼ必要ない。
ここで、遺書の性質を改めて考えてみる。病気が重くなって気が変わって云々、という時に、PCを立ち上げてパスワードを入れて、…といった操作を強要するような制度では人に優しくないと言える。紙に書いた自筆、署名入りの遺書が最後には有効である、という原則は外せないだろう。かといって、全部紙のままでスキャンするだけ、というのであれば、あましシステム化する意味が無い。

この折衷案として考えられるのは、次の通りだ。
  1. 紙による遺書とデジタル遺書の両方を認め、検認の手続きも行う前提とする。例えば、デジタル遺書と紙の遺書が両方発見されたとして、どちらが後に作られたものかをもって最終的に有効な遺書を決定する作業は残す。検認が完了した時点で、有効な遺書が決定するが、これが紙だった場合には、改めてその内容をスキャンし、デジタルで入力するものとする。
  2. デジタル遺書は、単純にマイナンバーポータルから入れば良いというものではなく、いわゆる遺言信託の一形態として設定する。
  3. デジタルにするからには、事前にその有効性は自動で確認しておきたい。抜け漏れ、無効になる、慰留が発生する全ての可能性は、作成時点で検証可能にする。もちろんそのための前提(相続人の特定や年齢、犯罪歴など)も入力が必要だ。
  4. 財産は、項目をいれておけばその時点での価値を自動計算できるようにしておく。例えば通帳の残高や土地の時価などだ。
  5. 死亡通知と共に、相続人への通知が行くように、全相続人のマイナンバーを設定しておく。このために、遺言信託の執行者にはマイナンバーへのアクセスを許可する。
  6. 次に、相続人全員の合意を得て、執行が一部修正される。最終結果がまたこのシステムに載るようにする。
  7. 執行の大部分がオンラインで行えるよう、デジタルになっているものはできるだけマイナンバーに繋げて執行する。
こんなところだろうか。こう書いてみると、まだまだアナログな部分は多く、人手も時間も掛かることが分かる。世の中はまだまだデジタル化の余地がある。

2019年3月16日土曜日

花粉ブロックバイザー


https://www.thanko.jp/shopdetail/000000003233

かなりインパクトのある商品だが、もう少し考えれば普段使いできるのではないだろうか。

だいぶ前だが、「ウルトラマン」で、科特隊の面々が、通常のヘルメットのままで宇宙に出る、というシーンがあった。当然、首のところに隙間ができる。子供心に「空気が漏れてるよ」と思ったのだが、随分後になって解説があり、あれはエアーカーテンによって気密を保つ仕掛けになっているのだそうだ。まあそれだってありえない話なのだが、ここにヒントがある。

要は目と鼻に届かなければよいので、その周囲の空気が陽圧(大気圧より高い気圧)であれば、埃も花粉も入って来れない。必ずしも布で覆わずとも、また隙間があっても良いはずだ。

そこで考えるのが、次のような仕掛けだ。まず、サンバイザーにフィルターとファンを載せ、顔の前面を透明マスクで覆うところまでは同じ。但し、その面積はずっと小さく、口まで届かずとも、鼻の下まで伸びていれば良いし、目の部分は横まで覆われていれば良く、頬を覆う必要はない。

透明マスクは顔には接しておらず、水中ゴーグルのような密閉用のゴムやシリコンもなく、隙間は開いたままだ。但し顔の形に合わせたカーブがあり、その隙間は1cm程度に抑えられている。メガネをしている人が多いことを考慮し、そのスペースは空けてある。つまりメガネの上から掛けられる。

サンバイザーに仕込まれたファンは小さいもので、エアフローも少ないが、鼻で呼吸をする際に入る量の数倍程度は確保される。バッテリーはせいぜい4時間も持てば十分である。バッテリーも軽くし、バイザーの上に乗せられる程度にする。

これなら違和感はずっと少なく、効果は殆ど変わらないはずだ。ぜひ本案見て頂き、サンコーの(来年の?)新作に期待する。

2019年3月15日金曜日

多重生活空間保護


https://japan.cnet.com/article/35132139/
https://japan.cnet.com/article/35117340/

宅配荷物を家の中に置くAmazon Key、留守の間に家事代行を頼むMANOMA。このように鍵を他人に預ける制度が普通に出てくると、家の方も工夫が必要ではないか、と思えてきた。

最初のエリアはAmazon Key用、つまり宅配荷物を置くためだけの空間だ。家の外ではなく玄関内、というのが第一の関門だが、玄関の鍵は他人に委託可能。この場合はAmazonに委託する。当然完全には信用できないので、荷物を置くところしかできない。

第二のエリアは家事代行用で、リビングダイニングである。ここには更に鍵がないと入れないが、いわゆる日常生活空間になる。但し貴重品や機微なプライバシー情報にはアクセスできないものとする。

第三のエリアはプライベート空間だ。多くの場合は寝室が相当する。ここには金庫などがあり、家事代行業者であっても留守の時には入れさせないようにする。

第三のエリアは生体認証がベストだろう。第一、第二に関しては、電子錠だと便利だ。臨機応変に対処できるし、直ちに無効にすることもできる。

この対処は、通常のマンションであっても工夫次第で可能である。通常のマンションなら、玄関を入ると老化に繋がっていて、各部屋にはドアがある。この各々のドアに鍵を掛ければよいから、中古でも改造で対処できる。その鍵がインテリジェントキーであれば、後はソフトで幾らでも対応できる。

注目の投稿:

日本の石油需給・財政・産業構造への影響分析(2026年8月版)

ナフサの現状 から2ヶ月強、AIをClaudeに変えて、改めて分析したレポートをお知らせする。 ---------   2026年ホルムズ海峡危機   日本の石油需給・財政・産業構造への影響分析   作成日:2026年8月9日   分析対象期間:2026年2月〜2027年以降(予...

人気の投稿: