このところ 日本の デジタル系システムの欠陥があらわになる事態が相次いでいます。
日本のソフトウェアの開発技術力が 諸外国と比較して そこまで低いというわけではないですが、世界が進歩するスピードに比較して成長が遅く、追いつき追い越されしてしまっていると見えます。
技術者のスキルに上下の幅が大きく、世界と対峙できる一流のスキルの持ち主が 一握りの数いる一方で、国内で広く普及するシステムの管理者全てに対しては その高い基礎力が 浸透していないという傾向があるように見えます。
「あまりにも初歩的」と見えるような不具合が出てきてニュースになってしまうのは、上級者が診断してそう思うのであって、初級者のレベルでは難しすぎて対処できない、あるいは問題の発生を想定できないというわけです。
日本に限った話ではないかもしれませんが、昔からテクノロジー脅威論のようなものは根強くあります。
オバケと同じで「よく分からないもの = 怖いもの」というような思い込みもありますが、迂闊に よく分からないシステムを導入すると、問題が生じても現場が対応できず、専門家に相談しないと解決せず、そのたびに 時間やお金がかかるので、結局導入しないほうが良かったという事態が少なくないからです。
これは「ニワトリが先かタマゴが先か」のような話で、システムを使えば使うほどノウハウや技術力は高まりトラブルにも対応しやすくなるのに、導入しないから能力が上がらずトラブルへの対応ができないという悪循環が生じるというものです。
危険な火の特性を学んで安全に使いこなすのが人間であり、火を恐れて近づかないのは動物の振る舞いです。近づくことを怖れる人が増えるのは、安全に使いこなすための方法を教える側と 学ぶ側の間の コミュニケーションの問題にあります。
日本語環境の特異性
日本では日本語という世界に類を見ない特殊な言語を使用しています。
多くのシステムには日本独自の機能が いつも必要で、これが長年システム導入の壁となっていました。海外製のコンピュータの多くは英語圏の少ない文字種にのみ対応しており、日本語や中国語など 膨大な漢字を扱うシステムとは 元来 相性が悪いのです。
このため日本で問題が生じた場合には まず文字種(文字コード)に起因する問題かどうかを切り分け、その上で日本語環境でだけ起こる問題であれば 日本の開発者(日本語と海外の言語知識を要する)がその対応をしなければならないということになります。
日本のコンピュータ利用者は 英語圏の利用者よりも トラブルに遭う確率が多く、修正されるまでの待ち時間も その修正工程の都合で全体として長くなる傾向があります。
またOSや接続先のメインシステム側 いわば土台の方に アップデート(改修)があれば、それに日本語独自の改修を加えた環境でも正しく動作するか 日本の技術者が日本で情報を集めてテストを実施・修正を施すというアップデートサイクルの負担もありました。国内でのアップデートや日本語対応したソフトの配布は常に一定期間遅れて受け取るというのが一般的でした。
近年になって、インターネットを使って最新の開発中のプロトタイプ(試作版)を共有したりするような仕組みが簡単にできるようになり、また企業間の国境や言語を超えた連携も強化され、こういった開発サイクルの問題は各言語を超えてうまく調整されるようにはなってきています。
各国語のソフトの開発関係者はあらかじめ土台側の変更情報をネット経由で入手し、本体がアップデートされると同時にそれに対応した新バージョンをすぐに提供するということが 中小零細企業などでも手をつけやすい環境となっているということです。
年齢が高い人で、コンピュータ利用経験が多少ある人の中にも苦手意識を持つ人が いるのは、知識がないと言うことに限らず、そういう改善がない昔の苦い経験をしたことが理由となっていることもあるかもしれません。
しかし、日本国内には 依然として いわゆるレガシーシステムと呼ばれる歴史的遺物が現役で動作しています。特に大昔に構築された国や自治体・銀行など金融系のシステムなどには そのような新システムとはうまく連携が取れないものが多く存在します。これをトラブル無く移行するのは 新旧両方のシステムに精通していないと 簡単ではありません。
Unicode(ユニコード)
初期のシステムでは 0〜9、A-Z、a〜zに簡単な記号を加えたASCIIという127種類の文字種のみが用いられ、現代でもいろいろなところにその名残がありますが、これは1バイトつまり8ビット(電気のON/OFFスイッチを8個並べたもの)で収めることができ、半導体や通信用の配線など発達していない過去においては効率が良かったことに理由があります。
日本語では漢字も含めると文字種が非常に多いことから、1バイトでは そのまま受け渡しすることができません。1バイトは最大で256種類の文字しか扱えないので カタカナまでが限界で、これをどうにかする最初の試みが2バイト文字で、JISやEUC-JPとかShift_JISあたりの規格があります。2バイト使えば最大で65535種類が表現可能ですが、データ転送の誤りの検出やなどの用途で全てを使うことはできません。戸籍用の旧字体などを扱うには足りず、各メーカーが独自の調整を行い、Lets-Jとか色々なコードが存在しています。
文字コードが違うというのは、たとえばあの文字を1番とするか、1001番とするか、電気信号のパターンに対する割り当てがメーカーごとに違うということで、これが いわゆる文字化けの原因になります。さらにコードによっては容量を小さくするためにモード切り替えという特殊なマークを用いるものがあります。これは後に続く文字が次のマークまでの間を全て英字とするとか、一種の命令の意味があります。こういった命令のところに特別なパターンが組み込まれると、単に文字化けでは済まずコンピューターに動作異常を起こしたり害を与えることもあります。
こうした事情から1980年代くらいから ISOにて統一コード策定の動きが出てくることになります。これがのちのUnicodeという統一規格の前身になります。しかしこれが正しく策定され、普及するには 実に長い時間がかかります。
コードの違いは、それぞれの開発会社にとってみれば、データファイルを持っていても そこからデータを抜き出して簡単に他社製品への乗り換えができないという 囲い込みに役立つもので、積極的に変換して欲しいものではない面があります。しかし利用者からすれば優れた他社製品の機能があっても使用できないという不便の極みです。
インターネットによっていろんなアプリを手軽にダウンロードしてインストールできるようになったり、異なる企業とのファイルのやり取りが盛んになるにつれ、この文字コードが違うことによる不便さが利用者の間で顕著になり、やがて統一規格対応への期待が強くなっていきます。
そうした期待に応える形でだんだんと各社製品からUnicodeの読み書き対応が進み、現在では日本語だけで無く中国語の漢字やアラビア文字やベトナム語やハングルなど世界中の言語を表現可能となっています。
不自由な日本語データ環境が蔓延っていたところが、いよいよ2010年くらいにスマートフォンの登場によって決定的となります。
スマートフォン以前のi-modeなどの時代にはインターネットでは容量の小さいShift_JISなどが主流でしたが、これでは日本語と英語以外の多言語に対応することができません。利用者がいちいち正しい文字コードを指定したりしなくてはならず、間違えると先に挙げたような動作異常を起こすリスクもあります。
しかしUnicodeであれば共通する文字コードで世界中の言語が表示できます。このことは世界市場を制覇するためには重要で、プログラムについては共通で、文字表示の部分だけ翻訳者に対応してもらえば、そのシステムは世界中に展開できるということになります。
しかし世界規模で活動することを考えていないような小規模な開発会社では、わざわざ外国語に対応するのはテストやサポートが面倒で、それ以上にメリットはありません。特に英語圏の開発会社の場合、英語にだけ対応していれば 世界の3分の1程度はカバーできます。そのため英語以外の文字が入いることが想定されていないようなソフトウェアもしばしば見受けれます。
絵文字という変化球
近年この統一コードの普及を不可逆的にしたのが絵文字の存在です。
絵文字は 日本のケータイ各社が小さいデータ量でアイコンを表示するのに開発したものですが、この絵文字はUnicodeにも収録されていて、文字化けすることなく世界中の人が見ることができるようになりました。
絵文字(emoji) は 漢字と違って 勉強していなくても 意味が分かるので、漢字の読めない外国人の目にも とまり、特にTwitterなどのSNSや YotuTubeや通販系のサイトのレビューなど 利用者が自由にコメントできるようなCGMサイトでは 言語や国籍を問わず 誰もが利用するようになっています。
このことは世界の開発会社に影響をもたらし、もともとUnicodeが必要ないような英語ユーザー向けのシステムでも、Unicode対応ソフトウェアを積極的に開発する動機となっています。
どこかで入手した気に入った絵文字を貼り付けたら エラーになってしまうようでは 利用者の不満になる可能性があるためです。
ビット列
Unicodeに対応したシステムが世界的に増えることは、１つの可能性を秘めています。パスワードの文字照合の問題です。
ここに、ある文字コードで “a” という文字をコードにしたとき(電気信号の並びで表して)に 01という並びだったとしましょう。そうすると “aa” は 0101ということになります。
ここでもし、別の文字コードで “あ” という文字が 0101という並びであればどうでしょう。
この “aa” と “あ” は 明らかに違う文字ですが、文字コードを限定していないシステムでは、この全く違う文字列を誤判定して同一とみなしてしまう可能性があります。
また 別のシステムでは “あ” を 11100011と表現するとしましょう。そうなるとさっきのシステムの0101とは一致しないため、パスワードが違うと判定されてしまいます。
しかし仮に全てのシステムで統一して UnicodeとくにUTF-8などの可搬性が高い表現を用いるのだとしたら、このような誤判定のリスクがありません。
日本人の多くは、アルファベットを日常的に使用してはいないため、パスワードで英数字での入力を求められると 何を入れて良いのか困る人が たくさんいます。マイナンバーの申請などでもパスワードをどうすれば良いのか分からなくて困った人が大勢 いたと言いますが、アルファベットの運用に不慣れであることをよく示しています。
またアルファベットをよくわかっていても日本語をローマ字にしてしまうと別の問題が生じてしまいます。
したがって、もし可能であればパスワードに日本語の すくなくとも ひらがなだけでも利用できれば、かなり多くの人が自分好みの強いパスワードを思いつくことができるでしょう。
好きな座右の銘でも 有名人の言葉でも、過去の歌人が読んだ俳句の冒頭などでも良いです。
日本語パスワードの強度
もし 日本語で例えば ひらがなをパスワードに使用可能とした場合、その強さはどの程度でしょうか。
たとえば一番簡単な例として数字のみを考えてみます。キャッシュカードなどでは4桁の数値0000〜9999までの1万通りの数値が使われます。もしキャッシュカードを何者かが盗んだとして、これを全国のATMを順に回って、1台で2回、1日10店舗回れば、10000÷20=500で、長くても およそ1年半ほどあれば正しい番号に辿り着けるということです。もし数百万とかそれなりの金額が入っていることが明らかな口座なら十分狙われうるレベルです。
しかし仮に ひらがな なら ワ行のゐとかゑとかヤ行のイ エと濁点を除いても46種あり、同じ4桁でも46×46×46×46=で4,477,456通り存在します。これを同じペースで全部試そうとすれば500年くらいかかってしまいますから、到底現実的ではなく、誰もやらないでしょう。
もしアルファベットの26文字と、数字0〜9の組み合わせなら36文字ですが、36の4乗で1,679,616通りですから、それより3倍程度強力であるということになります。
年齢で50代前後の人だったらご存知かもしれませんが、昔のTVゲームでセーブ機能がなかった時代、初代のドラゴンクエストなどでは「ふっかつのじゅもん」と称して ひらがな でゲーム進行の復元パスワードを表現されていました。これを１文字でも間違って書き写してしまったら、ものすごい時間をかけても復活できないと言う事態に陥ります。ひらがなの強力さは身を持って体験していることでしょう。
現在主力とされるパスワードの世界では、アルファベット大文字小文字と数字と記号を混ぜて使用せよと指示するものが多いですが、要はこのように1字あたりに使える文字種が多くなればなるほど推測の難易度が 非常に高くなるためです。
しかし日本人にとって扱いにくい英数字などよりも、ひらがな カタカナ さらに 漢字を混ぜれば、ゆうに1文字でも数千種類あり、5文字程度でも1京(1億の1億倍)を超える膨大な組み合わせが実現可能です。
覗き見の防止
ただ、入力の問題もあります。
一般にパスワードを入力する場面では、その入力蘭が下のようなパスワードフィールドが使用されることが多いです。
これは入力している最中に誰かが後ろから見ているかもしれないということを考慮したもので、入力した文字が•(middle dot/中黒)で伏せ字になります。このような入力欄が使われてきた背景には、もともとパソコンが貴重で、複数人で共用されている環境が多かったということに起因しています。
複数人が使用するパソコンは 関係する全員が使用可能なように 誰でも入いれる場所に設置されます。これはすぐに覗き見される可能性があることになります。
この理屈で言うと、漢字変換には変換候補を表示しないといけないため、パスワードとしては使用できないと言うことになります。
しかし現代はその状況は全然変わっていて、1人1台のパソコンが与えられている企業は珍しくありませんし、個人ではスマートフォンなども合わせて2台以上が使用可能な人もいます。
加えてスマートフォンの場合は パソコンと違って画面の向きを片手で簡単に変えられることから、周囲の人から見えないようにするのは簡単です。
そもそもスマートフォンの場合、キーボードが画面上に表示されますから、パスワード入力蘭を隠したところで、入力している文字が何であるかは画面が見えるなら 読み取り可能です。
よってシステムの特性にもよりますが、特にプライベートな利用が想定されるものについては 常にパスワードを見えないようにすることに あまり意義がないというふうに状況が変化してきているということです。実際 Googleにしても Facebookにしても、ログインのためのパスワード入力欄に、一時的に見えるようにするためのボタンがついていたりと「見やすい」環境を用意しています。
その意味では 漢字入力のために一時的に候補が見えたとしても実害は小さいと言えるわけです。
それにもし漢字がダメでも、フリック入力を使用するか、パソコンでも かな入力を用いた場合、ひらがなに関しては1ストロークで入力が可能であり、表示は必要ありません。
こうして考えると実際のところ今や パスワード入力に際して 日本語等の複雑な文字種を利用することは、十分な材料が すでにそろって来ていると言えるのです。
チェック ディジット
パスワードに限ったものではありませんが、4987832325782のような 何かの会員番号であったり、人間が記憶するのが難しい文字の羅列の誤りを検出する仕組みの１つとして、チェックディジット(check digit) という仕組みがあります。日本語では確認番号とか検証番号などと呼びますが、人為的な入力ミスのほか、バーコードの読み取りミスや、クレジットカードの読み取りミスなどほかのところでも活用されています。
非常に単純な例をあげます。
たとえば渡したい番号全体が 1234567890 という番号であったとしましょう。
ここで、全ての桁の数字の合計値をとると 1+2+3+4+5+6+7+8+9+0 = 45 となります。ここでこの下一桁の5をとって、末尾に付け加えます。すると 12345678905 の11桁の数字列を得ることができます。
こうすると、たとえば 13345678905 のように一字 間違っていれば、合計値の計算が合わなくなるため、番号全体が不正であることが分かります。
この例だと最後の数字が欠けていたときに最後の桁を適当に入力した場合、10分の1の確率で正解します。しかし9と8が逆転しているような場合にはその誤りは発見できません。現実にはこれよりももっと複雑な計算方式が用いられ、文字の抜け落ちやよくある誤りが 発見しやすいように工夫されています。
このチェックディジットは、不正検知に使用することもできます。計算方法を秘密にしておいて関係者にのみ その仕組みを共有しておくのです。そうすると利用者がデタラメな番号を入力しても、大部分はエラーとして はじくことができます。
エラーが一定回数発生したとき、その相手からは連続して入力することを拒否するようにすれば、それ以上の試行はできなくなります。
この方式の優れた点は、100%正確性を保証するものではない代わりに、何か背後のシステムと通信を取る必要がなく非常に高速であるところです。バーコードの読み取りなどではちょっとした光の反射や影などで頻繁に読み取り結果が崩れる可能性がありますが、データベースなどに いちいち問い合わせ検索するのではないので 通信が発生せず、その場で直ちに無効かどうかの判定が可能です。
ちょうど先頃 日本に導入されたワクチン予約システムでは、適当な予約番号を入れて予約できてしまうような問題が報告されて問題になったりしています。しかし予約番号そのものに強力なチェックディジットを設けられていれば、何も裏のシステムと通信を行わずとも多くの不正な入力をブロックすることが可能です。
このときに問題となりうるのが 先に挙げた１文字あたりの文字種の多さです。0〜9までの10個の数字でそこがチェックディジットだとわかれば10%の確率で当たることになりますが、もし ひらがなであれば 46分の1で2%程度まで確率を下げることができます。
ひらがな5文字をコードとすれば、それだけで46の5乗で 約2億通りのコードを生み出せます。このうちのいくつかのコードについてはダミーとしておき、最初から存在しないものとしておくと、確率はもっと下げることができます。
日本ではデジタル化と言うと高齢者や子供に扱いが難しいと言ったりしますが、少なくとも パスワードやコードの管理の問題については ひらがな・カタカナを用いるだけで ずいぶん簡単になります。”37598942″ みたいな番号よりか “アキステノ”の方が短くて楽なわけです。
このように、日本語という言語とシステムとをうまく組み合わせると、日本人に扱いやすく、しかもセキュリティ的にも強いものを実現できる可能性は大いにあります。
特に外国人の知らないような日本語の単語をパスワードなどに使うと、英単語よりも予測がしづらくなります。ローマ字でももちろん実現は可能ですが、その場合ヘボン式や複数の異なるルールが存在するために正しいものを選択しづらいと言う問題がありますが、ひらがな のみで表記が揺らぐことは あまりありません。
最近ではただのパスワードではなく生体認証のようなものものや、二要素認証のようなものも導入されてはいますが、それでも たとえばメール接続やFTP、インターネット契約など、パスワードを何人かで共有しないと費用対効果の合わないようなケースもありますから、完全に消えて無くなることは相当先の話です。
しかしこれらのほとんどは ずっと半角英数字と記号しか使えず、日本人を含む非英語圏の利用者にとっては扱いにくく、ついつい誰かの誕生日や記念日だとか、パスワード使い回しの甘いセキュリティの設定へと誘惑します。
絵文字をきっかけとしたUnicodeの広がりがパスコードの世界に広がれば、その力を強化することができます。多くの文字種を使いこなす日本人であればこそ、世界で提供されるソフトウェアに対して導入を主張しても良いのではないでしょうか。日本人向けに提供される日本製のソフトウェアであれば なおのことです。