パスワードを忘れた? アカウント作成

raycyさんのトモダチの日記。

13349275 journal
日記

akiraaniの日記: 本日のねためも 1

日記 by akiraani

ラジオに見えない! 音にこだわったカッコイイラジオがついに発売!(ASCII.jp)
 ああ、吉田アナが進めてクラウドファンディングで資金調達してた例のラジオ、ようやく製品化までこぎ着けたんだ。DTMF音の反応とかは番組の作り次第では面白そうではあるんだけど、実際問題としてわざわざラジオ本体に実装せずとも、ネット配信のラジオアプリが独自に実装した方が汎用性は高いんだよなぁ……。

「じゃじゃ丸」や「スーチーパイ」が追加! バンナムの「カタログIPオープン化プロジェクト」にジャレコ作品登場(ITmedia)
 へー、いつの間にか作品追加されてたのか。しかもジャレコ作品かぁ。スーチーパイとか、普通に園田健一さんが権利持ってるのかと思ったら、ゲームだと買切りになるのかね。

Atariの新型ゲーム機「Ataribox」写真公開(ITmedia)
 古いゲームを遊べる環境を提供するというのが主軸なのかな。少なくとも、今になってハードのスペック戦争やらプラットフォーム戦争に参加する目的で作ってるというのは考えにくいし、どっちかというとシンプルさが前面に出てる印象を受ける。

AIが答案分析、理解度別に復習教材――奈良市立の小学校が導入(ITmedia)
 小学校はひとりの担任が全科目見るからなぁ。担任教師が不得意な科目をこういうサービスで底上げして均質化というのはけっこう有効かもしれないな。まあ、データがそろってなんぼの世界だから、最初のうちは思ったように成果が出ないかもしれないけど、データを積み重ねていけば、そのうち通信教育なんかに使えるレベルになるんじゃないかな。

機内へのノートPC持ち込みが禁止だと? よろしいならばHoloLensだ!(PC Watch)
 今はHololensの価格もあってネタでしかないけど、HMDが高解像度対応してもっと廉価になればディスプレイの制約からは解放されるわけで、モバイル用の環境ってのは一新されるんじゃないかという気がする。覗き見のリスクとかも回避できるし、場所を取らないから狭い電車内とかでも気軽に作業できる。

マンガデザインの「コミPo!」がSurface Dialをサポート(PC Watch)
 Surface StudioでコミPoとかなんの冗談ですかって話ではあるけど、回転が制御可能なデバイスってのはコミPoだと確かに便利だろうなぁ。Dial単品購入して他の環境で使うことも一応できるんだし、対応しておくにこしたことはない……んだろうけど、コミPoはとりあえず体系と輪郭のバリエーション増やして欲しいんだよな。最近さわってないけど、今どんな感じなんだろう。

カラー・ドワンゴの「スタジオQ」は、アニメ業界の“人不足”問題を解決できるか(AV Watch)
 ネット配信向けに需要そのものは増えているってことか。東京での集中体勢が貧乏クリエーターにきついのは物価の問題もあるからなぁ。教育環境含めて地方でも運営可能な環境ができれば確かに心強いよね。

声優の茅原実里、ブログで熱愛報道を認める ファンからは「おめでとう!」「お幸せに!」と祝福の声(ITmedia)
 センテンススプリング砲不発、というか、アイドル声優というくくりにされる人でも大抵はこんな感じの反応なのは何が違うんだろうね。はき違えた熱狂的ファンが暴走するみたいな話もあるにはあるんだけど、良くも悪くも、キャラと中の人、二次元と三次元は切り離されて考えられてるんだろうなぁ。

13349158 journal
日本

yasuokaの日記: 戸籍統一文字152650はUnicode 10.0のどこに行ったのか

日記 by yasuoka

私(安岡孝一)の6月22日の日記の読者から、戸籍統一文字152650はUnicode 10.0に収録されたのか、という趣旨の御質問をいただいた。そもそもこの字は『新大字典』からの収録で、『新大字典』第1刷(1993年3月11日発行、講談社)では検字番号76に収録されている。検字番号76は

事の省略形。片仮名「コト」の代用として用いる。

と書いてあるので、つまりU+30FF「KATAKANA DIGRAPH KOTO」として、Unicode 10.0に収録されていることになる。ただ、ややこしいのは戸籍統一文字902840との関係だろう。902840は、JIS X 0213の1-2-24(ヿ)由来の非漢字として、戸籍統一文字に収録されている。一方、152650は、『新大字典』の検字番号76由来だから、こちらは漢字として戸籍統一文字に収録されている。これらを両方とも、そのままU+30FFに対応させると、妙なバッティングを起こしてしまって、さすがにちょっとマズイことになりそうだ。うーん、Variation Selectorを提案するしか無いのかなぁ…。

13348487 journal
数学

yasuokaの日記: 電子行政におけるJIS第1・第2・第3・第4水準漢字

日記 by yasuoka

私(安岡孝一)の2014年8月28日の日記の読者から、榎並利博の「数字は語る 縦割り行政の弊害 人名や地名で 増え過ぎた漢字」(週刊ダイヤモンド, 第105巻, 第25号 (2017年7月1日), p.26)を読んでみてほしい、との御連絡をいただいた。読んでみたのだが、「数字は語る」というタイトルなのに、出てくる数字がどうもおかしいものばかりで、かなり閉口した。

アルファベットが26文字なのに対して、日本の漢字はいったい幾つあるのだろうか。その答えは誰にも分からない。

「アルファベットが26文字」ということは、小文字その他を数えなくていいということだから、それなら「日本の漢字」も、常用漢字2136字を基本とすればいいと思う。

それでは漢字を電子的に扱うことができないため、漢字をコード化して整理したのがJIS第一水準と第二水準である。

第3水準漢字や第4水準漢字もあるんだけど、あれは「漢字をコード化して整理した」ものじゃないの?

JISでは全ての漢字を約6000字に絞ったため、似た字形も同じコードが付けられた。例えば、しめすへんは「示」と「ネ」という書き方があるが、それを使った漢字は、同じ漢字とみなされた。

「約6000字に絞った」って何の話? たとえば「神」と「神」には、JIS X 0213では別のコード(1-89-28と1-31-32)が付けられているんだけど?

住民基本台帳ネットワークシステムの構築時、全国の住民基本台帳の漢字が住基統一文字として整理され、その数は1万9563字であった。

『住民基本台帳ネットワーク統一文字とその問題点』にも書いたけど、住基統一文字の漢字数は、運用開始時点では19434字だった。その後、2012年に入管漢字131字が増えて、現在の漢字数は19565字。榎並の言う19563字って何なんだろう?

さらに、戸籍法改正で戸籍がデジタルデータ化され、戸籍で使用される漢字が戸籍統一文字として整理された。その数は5万5269字もある。

2012年4月16日の日記にも書いたが、戸籍統一文字の漢字数は、現在55271字。その前は2010年11月30日に、55267字から55270字へと、3字が同時に追加されている。

つまり漢字を表現するコード体系としてJIS、住基統一文字、戸籍統一文字の3種類が存在し、これは経済産業省、総務省、法務省という省庁縦割りをそのまま反映している。その3種類のコード体系を統合し重複を省いたのが、5万8712字に整理された文字情報基盤である。

だったら、省庁縦割りが解消されたんだから、それでいいと思うんだけど。ただし、文字情報基盤の漢字数は、現在は58861字。

私たちは税金で約6万字の漢字を維持管理していることに関心を払うべきではないだろうか。電子行政における莫大な漢字を、使い慣れたJIS第一水準と第二水準の範囲に法的に制限するように改める時期が来ている。

いや、そんな時期は来てないと思うし、それに、第3水準漢字や第4水準漢字もあるんだけど。私が3年ほど前に書いた『電子行政における第3・第4水準漢字』が、よっぽど気に障ったのかしら?

13347533 journal
日記

minetの日記: 夏休みだなぁ(学生が)

日記 by minet

学生が朝いなくなって通勤電車が楽になったけど、夕方は混んでるなぁ。
う〜ん風物詩。

13347119 journal
日記

akiraaniの日記: ブラックリストを共同で運用したほうが「有利」になる理由 13

日記 by akiraani

予約無断キャンセル者の電話番号を集める「予約キャンセルデータベース」が登場 関連の話。

 この手のデータベースは業界全体で共有する前提で運用、データ収集をしたほうが良い。理由は複数ある。
 主なものをあげると以下

  • 規模の大きさがデータベースの信頼性に直結するから
  • 一社当たりの運用コストが下がるから
  • 不正なデータの介入を防ぐには独立した相互監視運用が不可欠だから

 ブラックリストって言ってますが実際に必要になるのは信用調査なわけで、前科のある番号登録して終わり、ですむわけがないんですね。ノウハウの積みかねも必要だし、スケールメリットもものすごく効いてくる。ベンダ各社がサービスとして実装するより、独立運用する会社立ち上げたほうがどのプレイヤーにもメリットは大きい。

 予約無断キャンセルDBの例を簡単にモデル化して考えてみると理解しやすいかと思います。
 関係者は
 ・飲食店
 ・予約サイトベンダ
 ・利用者
 の三つ

 わかりやすくモデル化するために、以下の状況であると仮定します。
 ・予約サイトベンダ(以下ベンダ)は大手のA社、B社、C社の三社がそれぞれシェア30%、その他の零細サイトのシェア合計が10%。
 ・A社~C社はそれぞれDB運用が可能な技術力を持っているが、零細サイトにはその技術力はない
 ・DBは運用コスト1でブラックリストの登録削除が、運用コスト2で1に加えてAIによる新規利用者の信頼度予測が、運用コスト3で2に加えてドタキャン発生時のキャンセル料徴収ができる
 ・DB運用コストはすべて飲食店から支払われる利用料でまかなわれ、飲食店業界全体で5のコストを負担できる余地がある。
 ・DBの網羅度はシェアに比例する

ケース1:大手3社が個別にDBを運用する場合
  大手3社のどれかが先駆けてDBを運用してシェアを奪おうとしても、すぐに他の大手2社がキャッチアップするため長期視点では差別化や囲い込みは不可能
  飲食店の利用料から徴収できるDB運用コストはシェア30%の場合1.5、技術的にDB実装ができない零細サイトのシェアを奪ったとしても、運用コスト2は確保できない
  採算ベースを維持する限り、ブラックリストの登録削除のみの運用までしか実装できない。広告などのマネタイズで赤字を補填するなどの営業努力で2まで確保しても新規客の信頼度予測までで、キャンセル料徴収までは難しい
  登録されるデータ数も各社のシェア分しかないため、リストの網羅度も低い

ケース2:予約キャンセルDBを運用するD社を大手ベンダ3社が合弁で設立し、D社を独自採算で運営する場合
     ※:DB利用に当たってD社は10%のマージンを取るものとする
  大手三社と零細含めたすべてのベンダがD社と契約する場合、飲食店の利用料からD社のマージン10%を加えても3.3のコストで、キャンセル料徴収まで実装できる。
  すべての予約ベンダがD社のサービスを利用すると、大手1社あたりの利用料は1弱でキャンセル料徴収まで可能、登録数は100%と信頼性も高くなる。

 もちろん、モデル化している部分(各社のシェアとかマージンとかコストとか)にはいろんなパターンが考えられますが、DB運用可能な技術力を持ち、一定以上のシェアを持つベンダが2社以上あった場合、必ずケース2の方が低コストで高品質のサービスを提供することが可能となりす。
 DB運用を行うことのできる大手が1社しかない、もしくは1社で大半のシェアを独占している場合に限り、ケース1のほうがシェア拡大ができると言うメリットが生まれますが、ドックイヤーなこの業界でそんなことはありえないですよね。

typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...