明るい日本の住所表記に安心してくださいはできますか


久しぶりにマサカリが飛んでくるネタらしい。
ネットショップを20年近くやってると、うちみたいな弱小零細でも何万何十万と住所処理を処理することになり言わずには居られない鬱憤もたまる。
つくづく日本語のシステム、データベース化は難しい。

英語であればアルファベット24文字と大文字小文字ぐらいなのでUpper()なりlower()なりでどちらかに統一すれば検索できる。
日本語は漢字、ひらがな、カタカナぐらい?
漢字は一般的なコンピューターシステムでサポートされているJIS系の第1~4に補助漢字までいれてだいたい約16,000字ぐらいが一般的なフォントで対応されている。
ということは、24文字を1万6千文字に増やした分だけ頑張らなきゃいけないのか! それは大変だね!!

・・・なんていう枠には収まらない。

だからこそ、地獄のフタを一度でも開けた人たちはマサカリを投げつけるのである。完全に理解した曲線のバカ山の能天気さは絶望の谷底からみると眩しすぎるのだ。
地獄に落ちてしまった亡者が手をのばすほどには。

16000文字÷24文字=666.66666666666倍

そこは決して開けてはいけない地獄のフタなのである。

分かち書きカカシ先生は脳みそを求めて旅に出る地獄

ちょいと前に話題になった動画に「変なAI」というのがあった。

雨穴さんの【科学ホラーミステリー】変なAI
www.youtube.com/watch?v=NAv0aScEQm0

このホラーミステリー的な動画では作中にAI「kakashi」というのが出てくる。カカシと聞くと、インターネット老人会の人たちはすこしざわざわする。

古い話し。

kakashi、実は2000年の頃に実在していて、かつては全文検索エンジンをつくるのに、kakashiやらnamazuやらをつかって分かち書き、インデックス化をしている時代があった。

分かち書きというのは、英語の場合は単語と単語の間がスペースで区切られているため、単語で検索することができるが、「日本語 は 文中 に 区切り が ない」ので、こんな感じ分解してやる。

チャセンやらメカブやら形態素解析が一般化する前までは突っ込まれたテキストをどこで区切るのかは実に大問題で、無計画な全探索などをおこなってしまうと一生かけても応答しないぐずのろ検索エンジンになってしまうのだ。そんな風に予め持っている手持ちの辞書と突き合わせて文章を細切れにして索引をつけておく必要があった。

愛知海部飛島新田竹之郷ヨタレ南ノ割

これは日本一長い住所から、あえて郡とか字の区切り文字表記を抜いたものであるが、日本人の何人がこれを正確に分かち書くことができるだろうか?線でも引いて区切ってみてほしい。

正解はこれ。

愛知県 海部郡 飛島村 大字飛島新田 字竹之郷 ヨタレ南ノ割

人間に難しいことはAIにも難しい。
2023年現在、だいぶ進化したとは言え、ChatGPTに日本語の文字数を尋ねるとおかしな答えが帰ってくることがある。夏を季語に俳句を読んでもらった。

2023年なうてのAI、ChatGPTさんは俳句を読めても、それが何文字ですか?みたいな人間には簡単に見える質問には満足に答えることができないことがある。ここに日本語の難しさがある。

もしかしたらこれは、GPTの学習が「日本語」ではなく、文字コードのバイナリで線形学習していることによる弊害かもしれない。存在しない「視覴」なる単語を使いだしたという騒動を見ているとその確信を強くするが、マルチモーダルを目指す過程に今この瞬間だけ見ることができるマルチバイト言語に現れた時代の徒花と考えれば、音数え 趣深し 梅雨の藍。

これはおもしろい。UTF-8とChatGPTのトークン:
視覴 e8 a6 96 e8 a6 b4 |25038|244|25038|112|
視覚 e8 a6 96 e8 a6 9a |25038|244|25038|248|
視聴 e8 a6 96 e8 81 b4 |25038|244|36735|112|
「覚」の前半と「聴」の後半がくっついたみたい t.co/oSpUfNxsUN— Haruhiko Okumura (@h_okumura) June 8, 2023

ちょっとだけ解説すると、文字コードのUTF-8のバイナリはリバースにスタックされてるので日本語化するときは読み込み順を逆にしてからエンコードしてやらにゃならない。U+07FFみたいなんがバイナリ読み込みするとFF07みたいに拾われてくるので07FFに結合してUTF-8でデコードする感じ。これはUTF-8が1-4バイトの可変長であることに多分由来しているんだろうけど詳しくは知らんし自分には荷が重いので、ここではそんな地獄もあるよと軽く触れる程度で終える。しらんけど。

地名の読み方無限地獄

日本語を分かち書くことはただでさえ難しいのに、さらに厄介なことに、固有名詞、地名はさらに輪をかけてそれを困難にする。

地名をなんと読むか、読めない地名をどこで区切るかは母語を日本語にする人にもとても難しい問題だ。
そのため表現も揺らぎやすい。
やがて同じ読みでもいくつも書き方が存在するようになる。

山手、山の手、山ノ手。

ひとつの書き方にいくつも読み方、ひとつの読み方に複数の書き方が存在するようになる。
山手と書いて、やまのてと読んだり、やまてと読んだり、どちらでも正解だったり、読み方が決まっていたり、あるいはどちらとも間違いだったりする。会社によって自治体によって運送会社によって正解が変わる。東京にも山の手はあるし神奈川にも神戸にもある。

これに方言も混じれば読み方がさらに増え、さらに書き方が増える。
こんな風にして地名は発散する。

昨年ニホンゴムズイという、アプリを習作がてら作った。
歴史的な経緯(?)から千葉県にはとてもむずかしい難読地名が多いのだけど、それを4択クイズにしただけのそんなにおもしろくもないゲームだ。

※ 今はAppleデベロッパライセンス切れ(?)でダウンロードできないけど、一応リンクだけ残しておく
apps.apple.com/jp/app/%E3%83%8B%E3%83%9B%E3%83%B3%E3%82%B4%E3%83%A0%E3%82%BA%E3%82%A4/id1608182925

我孫子市、富津市、酒々井町、東庄町

匝瑳市、鋸南町、八街市

読めるだろうか?

正解は・・・

我孫子市(あびこし)、富津市(ふっつし)、酒々井町(しすいまち)、東庄町(とうのしょうまち)、匝瑳市(そうさし)、鋸南町(きょなんまち)、八街市(やちまたし)

千葉県の基礎自治体だけをあげつらっても、ごらんの難読さ加減。

ちなみ、今ちらっとゲームのデータを見てきたのだけど、千葉県では地名に使われる漢字は常用漢字うち737文字しか使われておらず、1538が不使用となっている。逆に139文字は常用漢字以外の漢字が使われていた。

同表記なのに別の場所という例もある。

181-0016 東京都三鷹市深大寺と182-0012 東京都調布市深大寺は数キロと絶妙に離れているが連続した一体エリアではない。


調布深大寺にある植物公園は神代寺植物公園だの神代高校だの、神代とする別の漢字表記もある。
深大寺がお寺の名前に由来しいて、神代は神代村に由来しているわけだが、こんな風にすこしの区別付けのために漢字表記をあえて変えた。そしてその変更にはそれなりのこだわりがあったので放棄するわけにはいかない。
三鷹の深大寺と調布の深大寺はまだ自治体が別だからよかった。だが、もし合併したら?

630-8016 奈良県奈良市南新町(みなみしんちょう)(52~212番地)
630-8356 奈良県奈良市南新町(みなみしんまち)(1~32番地)

950-3323 新潟県新潟市北区東栄町(とうえいちょう)
950-3104 新潟県新潟市北区東栄町(ひがしさかえまち)

673-0012 兵庫県明石市和坂(わさか)
673-0012 兵庫県明石市和坂(かにがさか)

住所については、例外の枚挙には暇がないのである。
そして永遠に地名は増殖する。

なんかまだまだまだまだいい足りないが、長くなったのであと2回ぐらいはつづく

参考

とにかく日本の住所のヤバさをもっと知るべきだと思います
note.com/inuro/n/n7ec7cf15cf9c

住居表示に関する法律
elaws.e-gov.go.jp/document?lawid=337AC0000000119

愛知県海部郡飛島村大字飛島新田字竹之郷ヨタレ南ノ割は本当に日本一長い地名か?
dailyportalz.jp/kiji/140708164564


OpenAIのAPIをC# Unityでやるためのスニペット


4月になったのでGithub copilotとchatGPTに課金してみた。chatGPTのAPIがあるというのでチラ見。リファレンスみてたら platform.openai.com/docs/libraries に Unityがあるので入れてみたりしたのだが、入力にInputを使っていたり嫌な予感。2年まえのだった。APIもリファレンスとずれてて通らない。なんとなく昔はmodelsとかcompletionsがなかったのかな?json組むところを追ってたんだけど250ぐらいファイルがあってしかもパッケージなので嫌になった。素体にしているjsonをちょいと書き換えるぐらいのもんだとおもったんだよ。というかちょいと動かしてみたかっただけなんだ。使う予定もない。ローカルにnode.jsとかpythonとかを動かせる環境をつくる気力と能力がない。いま動くのはunityとそれにつかってるC#ぐらい。

というわけで、curlコマンドで書かれてる内容をhttpClientで投げてけるやり方で動かしてみた。公式のライブラリから紹介されていたひとは UnityEngine.Networking; つかってたけど、使い方がよくわからないのでSystemのHttpにしてしまった。ベタがきで蹴ってるだけなのでよしなに書き換えて自分で実装してみてください。まあほんとにほんとのご参考までに。他のかたの15分ぐらいの労力節約のためにネットの海に放流しておく。技術ブログとかもってないんだ・・・。


using System;   // Uri
using System.Text;   // Ascii
using System.Net.Http;
using System.Net.Http.Headers;    //AuthenticationHeaderValue 
using UnityEngine;

public class UnitCurl : MonoBehaviour
{
    private static async void postOpenAIAPI()
    {
        using HttpClient client = new HttpClient();
        string uri = "https://api.openai.com/v1/chat/completions";
        var request = new HttpRequestMessage(HttpMethod.Post, uri);
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", "ひみつかぎ");
        client.DefaultRequestHeaders.Add("User-Agent", $"testKui/openai_api_fromunity");
        client.DefaultRequestHeaders.Add("OpenAI-Organization", $"あれば、そしきID");

        string json = "{" 
            + "\"model\": \"gpt-3.5-turbo\","
            // + "\"messages\": [{\"role\": \"user\", \"content\": \"Say this is a test!\"}],"
            + "\"messages\": [{\"role\": \"assistant\", \"content\": \"hello!\"}],"
            + "\"temperature\": 0.7"
            + "}";
        HttpContent content = new StringContent(json, Encoding.UTF8, "application/json");
        var httpsResponse = await client.PostAsync(uri, content);
        var responseContent = await httpsResponse.Content.ReadAsStringAsync();

        Console.WriteLine($"{responseContent}");
        Debug.Log(responseContent);
    }

    void Awake()
    {
        postOpenAIAPI();

    }
}

最近は、UnityとPlateauで簡単なタワーディフェンスゲームをつくろうとおもっている。chatGPTを使う予定はないのだけど、流行りに流された。流行りに流されると苦労するな?


coinhive公開意見書の事前公開


coinhiveについて意見書なるものが求められてると聞き、ちょろりと書こうと思ったのだが、技術者と呼ぶにはロートルなので公開する。それは変じゃねってあったらコメントつけてください。・・・ロートル。英語かとおもったら老頭児、中国語なんだね。らぉとぅ儿か。びっくりだ。

私は誰か

2000年初頭、新卒から技術職が50~100名程度のちいさなソフトウエア開発会社にプログラマー技術職として勤めていた。スペシャリストや部長職などを経て、子会社の役員CTOなどもやったが、ご多分に漏れずSIerと呼ばれるシステム開発業界隈から身を遠ざけ、緩く喫茶や小売業をまったりやる個人起業をし十数年になる。

技術職であった期間より、もはや商店街で部長をやっている期間のほうが長くなり、プログラマーとしては疑問符がつくようになってしまったが、おかげさまでICT界隈の技術には理解がない人達へ説明をする能力は得ることができた。

自分で手を動かし、ある程度のソフトウエアは設計から実装まで仕上げることができたが、前線からは離れているので先端技術者としてのスペシャリティはない。だが、プログラマーが集まるコミュニティの運営をしているので技術者の声は今でも聞くし、三鷹市界隈のICT事業者をあつめた協会の理事もやっているので経営者の声も聞く。ついでに言うと三鷹市の情報推進の委員などもしているので行政の意見も聞く機会があり広範囲に情報は得ているほうだと思う。

そのような観点からcoinhive騒動についての意見を申し上げたい。
なお、これからの意見は会社や組織を代表するものではなく、あくまで個人の意見である。おさだまり文言。

論点項目

・行為の主体
・刑法としての解釈
・coinhiveの評価と程度の問題

行為の主体

商店主にプログラミング言語を説明しようとしたら、ぴ~ひょろろというFAXが発する音のようなものを発声するのだと言う人が居たが、これを読まれる方は、そのような層よりはパソコンなどの操作について馴染みがあるものとして話しをすすめる。

プログラミングとは、簡単に言えばコンピューターが動作するにあたり、どのように挙動するかの指示を列挙した指示書のようなものである。

指示の中で別の指示書を呼び出したりするのが最近のプログラムでは常なので、そのため連鎖反応のように自動で実行されているように見えるものもあるが、あくまで実行の主体者は辿れば最初にそれを実行した者に行き着く。

正常系であれば実行者が居て、それを実行可能な環境が揃うことで実行結果を得ることができる。
異常系であれば機械などハードウエアの異常が不随意に発生したもの、または製作者も意図していなかった挙動、実行者の意図を欺いて実行されるものなどが考えられる。

多くの人が無自覚におこなっているホームページ閲覧という仕組みの正常系を技術的に考えてみると、閲覧者はまずホームページを保管しているサーバーへ閲覧したいという要望(リクエスト)を投げる。サーバー側はそれを許可し閲覧者にアクセスさせる。閲覧者はそれを自身のパソコンなどに持ち帰り自身のマシンで指示書を翻訳し実行し、閲覧を行う。

ホームページの提供者は閲覧者がいつ来てもよいように、家(サーバー)の鍵(ポート)をあけて待機状態(リッスン)にしておき、ときにはそのリクエストに応じてサーバー側で演算して実行結果として渡してあげる必要がある。最初に問い合わせをし閲覧許可の要望を投げるのも、それを実行するのも行為の主体は閲覧者である。閲覧者の指示を契機にしておこなわれる。

刑法としての解釈

いわゆるコンピュータ・ウイルスに関する罪(不正指令電磁的記録作成等)についてであるが、coinhiveはこの定義からは外れるものと考える。実行形態を見ても実行結果をみてもそもそもコンピューターウイルスの定義に当てはまらない。

coinhiveなどを利用し、ホームページ提供者でもない第三者が他者のホームページを書き換えマイニングスクリプトを設置したり、閲覧者がリクエストもしてないのに保存させたり実行させたり、なにかを騙り詐謀しユーザーにマイニングをさせるマルウエアやウイルスは存在する。しかし、それらのものと今回のWEBデザイナーがWEBサイトの部品としてcoinhiveを設置したものは手続き的にも技術的にも明確に区別できる。

今回の場合、ホームページ提供者が設置したものを閲覧者がリクエストして、それに応じてファイルへのアクセスを許可したものであり、またそれを実行したのも閲覧者である。

閲覧者はそのホームページのURLにアクセスすることで構成する索引(インデックスファイル)を取得し、その索引から閲覧するために個々のファイルを取得する。閲覧者の意図はホームページ全体を完全な形で閲覧することを前提としており、その意図に添った動作を行っているといえる。

プログラムや提供されるホームページを著者の著作物だと考えれば、著作者人格権うち同一性保持権は適応されて然るべきであろう。公衆送信権をサーバーに委譲しているに過ぎない。

もし、閲覧者の意図がホームページの完全な状態の実行ではなく、作者が意図しない形で閲覧をしたいのであれば、その閲覧者の意図に沿ってHTTPリクエストを逐次段階的に処理していく必要がある。TCP/IPのプロトコル(決まりごと)はそれを可能にしているが、手順が煩雑になるために、閲覧実行時(ブラウジング)に実行権限を委譲することでブラウザーがリクエストと応答をまとめて代理処理されている。

一般的なホームページ閲覧ソフト(ブラウザー)はjavascriptの実行を許可しない設定に切り替えることができるし、httpプロトコルをブラウザ任せにしなければ、その取捨選択をおこなう機会は失われていない。
インターネットを構築する技術仕様はRFCで公開されており、それに則ったやりとりの範囲でおこなわれる。しかも今回の件は、ブラウザが許可した範囲内でしか動けないJavaScriptの話しである。ページを立ち去れば終了するのだ。

仕様上そのようにはなっていないので、閲覧者側に気がつく機会は提供されなかったものとは言うことはできない。その機会をブラウザに権限委譲することで煩わしさから逃れているのだ。現代において一般的なホームページ上でも数えられぬほどのJavaScriptが動いている。もし、chormeブラウザを使っているならF12ボタンを押せば、現在どのようなファイルを取得して実行していて、ネットワークの状態などを検証することは容易に確認することができるだろう。確認してみるといい。そのうちいくつが閲覧者の意図に沿ったものだろうか?ホームページ設置者すら意図していないものもあるかもしれない。

coinhiveの実行はホームページの閲覧には不必要な挙動であり、正当な理由のないものとの意見、解釈もあるだろう。だが、ホームページ提供者の意図を閲覧者が定義することはできない。製作者が意図する完全な状態はcoinhiveを含むものとする著作者意図を閲覧者側の閲覧したいものの意図に沿わないから不正な電磁的記録であるとしてしまう危険性を今一度考慮する必要がある。

著作物と閲覧者が異なる人物である場合、閲覧者の意図を過不足なく斟酌して、著作者が著作物を用意することはできない。閲覧者の意図によって、その内容が不正指令電磁的記録になるのであれば、その影響範囲は現行のインターネット上の仕組みの根幹にも影響する。

インターネット初期の頃、ホームページを開くと自動で音楽が流れるようなサイトも多くあった。現在の流行りはサイトを閲覧するために動画広告を強制的に視聴させるようなホームページも多い。
これらの動画を流すために、見えないところで広告をより効率的に見せるためのトラッカー、アクセス解析などが動いている。情報を取得しユーザー上のマシンリソースを使用している。coinhiveと、広告などとの違いを社会的コンセンサスという不確かな定義のものの上に置いてしまうと、技術的にはそれらを区別することはできなくなるだろう。 欧州のGDPRのおかげでcookieなどはオプトイン形式になり可視化されつつあるが、 認識されていないだけで見えていない広告関連の仕組みは実に多い。ユーザーには一見認識することができない非常に多くの構造体が目に見える仕組みを支えている。

ホームページ提供者が閲覧者のマシン演算力をより多く必要とする部品を設置することにマナーとしては諸説紛々あるやもしれないが、これをもってコンピュータウイルスの定義を当てはめるのは定義を拡大しすぎである。

coinhiveの評価と程度の問題

ホームページの維持管理のためには、閲覧者が24時間いつきてもいいように電気をつけて待っている必要がある。経済的利益の確保はホームページ更新の動機になるばかりでなく必要な経費であり正当な理由の範囲内として考えることができる。 というより設置者が得られる利益も、閲覧者に見込まれる不利益もはたして公の議論にあたいするほど影響があるほどボリュームがあるものとは考えられない。いったいいくらの経済被害がこれによって生じうるのか。捜査や公判維持にいくらの経費をかけているのか。

coinhiveが問題となったのは、おそらくは、ホームページ改ざんなどで他人のホームページにそれらを埋め込むウイルスが流行ったことによりウイルス対策プログラムのパターンファイルに登録されたことをきっかけにウイルスと誤認されたことをきっかけにしているにすぎないように思う。また、仮想通貨のマイニングといういかがわしさが拍車をかけているのだろう。

だが、いちWEBデザイナーがホームページの部品として設置できる程度のものに、刑法犯に問うべきような過失や未必の故意がありえるだろうか?

いったい閲覧者に幾らの経済的損失を与え、幾らの不当な利益を得たというのだろうか? ホームページ閲覧中の滞在時間、javascriptがブラウザ上の割り当てたメモリ内とCPUの優先順序で動ける範囲で消費できる電気料金?数円、よくって数十円、どんなにがんばっても数百円もいかないだろう。見込める利益も予見の範囲、たかが知れている。

coinhiveで逮捕されたと話題になった当時、評価のため、オーストラリアのユニセフが設置したcoinhiveにアクセスしたり、通常のサイトと閲覧比較をしてCPU利用率などを比べてみたことがある。

下記は、量販品のメーカー製パソコンでCPU50%でcoinhiveを回したときのCPU可動遷移率だ。

次の画像は動画が再生される毎日新聞社のニュースページのCPU可動遷移率。

CPU稼働率の上限を制御できる分、coinhiveのほうがまだ閲覧者のPCには優しい。 電気泥棒だなどと非難する声もあるが、動画広告は閲覧者の時間泥棒である。通信帯域も食うことから、中継機の電気も食うし、その後のハードディスクの保存量も食う。 個人的にはホームページ閲覧の滞在時間なども勘案すればCPU利用率を2-30%ぐらいに絞ってくれるのならば動画広告より歓迎すべき未来のようにも思える。

画面のはじっこでチラチラ変な動画がぴょこぴょこしていたり、得ようとしている情報とは関係ないPR情報が記事に割り込んでくるのは苦痛なので、こういう収益化手段の遷移は歓迎したい。

たしかに仮想通貨マイニングはうさんくさい。coinhiveも終了した。だが、分散コンピューティングは将来は公益に資する可能性が大きくある。

いま人類を悩ませている新型コロナウイルス(COVID-19)。この解析に分散コンピューティングのFolding@homeプロジェクトが動きはじめている。
だがどうだろう、もし誰かが、これらをブラウザ上でも動くようにするプログラムを書いて、ホームページ上に置くことでこれらの解析に貢献できるものを作ったら? 日本では設置した人も、設置できるコードを書いた人も刑事罰の対象として逮捕されてしまうのだろうか。もしされないのであればその違いはなんであろうか。罪刑は法律が規定する範囲で運用されるべきもので、刑法犯については特に慎重に検討願いたい。

その他引用とか参考とか

BOINC is used by many volunteer computing projects.
boinc.berkeley.edu/projects.php

【寄稿】コインハイブ事件 意見書ご協力のお願い
www.hacker.or.jp/coinhiveopinion/

違法マイニングとされたcoinhiveの法と技術のはなし
kuippa.com/blog/%e9%81%95%e6%b3%95%e3%83%9e%e3%82%a4%e3%83%8b%e3%83%b3%e3%82%b0%e3%81%a8%e3%81%95%e3%82%8c%e3%81%9fcoinhive%e3%81%ae%e6%b3%95%e3%81%a8%e6%8a%80%e8%a1%93%e3%81%ae%e3%81%af%e3%81%aa%e3%81%97/

新型コロナウイルスの解析、分散コンピューティングで誰でも参加できるように 「Folding@home」が対応
www.itmedia.co.jp/news/articles/2003/15/news015.html