Microsoft

2017年4月 6日 (木)

PCの時計が1時間進む問題が完全に解決した

前回の続き。 PCの時計が1時間進んでいる問題ですが、 私のPCに関しては問題は完全に解決しました。 わーい。

  • 前回のあらすじ
  • 現状の確認
  • PCメーカーのサポートに問い合わせた→解決
  • 考察など
  • まとめ

前回のあらすじ

  • 自分のPCの時計が1時間進んでいた
  • 原因はPCのファームウェアの設定のせいと確信(thanks to 「「PCの時計が1時間ずれている」の原因 」)。 要するに、四半世紀前ならともかく、現在においてはまったく意味のない"Daylight Savings Enable"がなぜか有効になっているPCがあるということですね。
  • 突如、Microsoftが「修正した」とのニュースが→「えっ?」

現状の確認

Microsoftが修正したとのニュースに「ほんまかいな」と思いつつ、 1日ほど様子を見てました。 しかし、修正は落ちてきませんし、 ツールで覗くとReal-Time Clockの"Daylight Savings Enable"のビットは立ったままです。

念のため、以下の手順で実験をしてみました。

  1. PCのLANから切り離す。WiFiも無効にする(タイムサーバーとの同期を防ぐため)。
  2. Windows上で現在時刻を2017年4月3日午前1:55にセットする。
  3. PC電源を電源を切り、10分放置する。
  4. (10分後に)電源を入れる。
  5. Windows上で時刻を見る。

この結果、時刻は午前2:05頃になっているはずですが、実際には午前3:05頃になっていました。 "Daylight Savings Enable"の仕様通り、午前2時がスキップされています。

(あれ、4月2日だったっけな。 手元に残したメモには4月3日ってあるけど、 "Daylight Savings Enable"の仕様を厳密に解釈すると4月2日が正しいような気がする。 でも、もう直ってしまったので再現させて検証できない… まあ、午前2時がすっ飛ぶ現象が起きたのは確か。)

つまり、時計がずれる問題は直っていない。

PCメーカーのサポートに問い合わせた→解決

ここで意を決して、 PCメーカー(富士通)のサポートに問い合わせを投げました。 問題のPCは富士通 LIFEBOOK WA3/Wです。 これが昨日の夜。

で、今日返事がきました。

(意訳)BIOSアップデートしなはれ。

あー、確かに。 サポートに問い合わせる前に確認するべきでした。 最近、ドライバもほとんどWindows Updateで更新されるので忘れてたよ。

で、サポートページでBIOSを探すと新しいものがありました。 Readmeを見ると、ちゃんと載っているじゃないですか。

■ 5.改版履歴(修正項目)

...略...

(1.20)

  • パソコンの安定性を改善しました。
  • ごく稀に、4月と10月にパソコン内蔵の時計が1時間ずれることがある問題を修正しました。

わーい。 さすがFMVサポート。 こんなくそ面倒くさい問い合わせ分かってもらえるんだろうかと思って、 こんなツイートしてたんですけど、

えらそうなこと言ってほんますいませんでした。

BIOSアップデート後、"Daylight Savings Enable"はちゃんとDisableになっているし、 上記実験をしたら、ちゃんと再起動後の時間が午前2:05になってました。

直った。

考察など

Microsoftが修正したってのは何?

何でしょうねえ… どこかにコミュニケーションミスがあったのかも。 英語サイトを色々検索したんだけど、「修正した」ってニュースは他に無さげだし。 「PCの時計が1時間ずれている」の原因 を書いた人は、 その続編(「PCの時計が1時間ずれている」の原因の解説)で Microsoftのタイムサーバーのマシンでこの現象が発生したんじゃないか、と言ってます。 うーん。 でも、そうだとすると、Windowsの時刻の同期間隔はデフォルトで一週間と聞いているので、 「影響を受けたPCの時計は、日本時間4日未明までに自動で直っているという。」(「PCの時計が1時間ずれる」グローバルで発生「修正した」とMS)なんて言えないんじゃないかな。 よくわからない。

どうして今回だけ騒ぎになった?

これも分からない。 ただ、検索してみると、過去にも時間がずれたという声はあるし、 私も、前に時間がずれて「あれー」と思いながら直したことをぼんやり思い出したし、 実は以前から結構発生してたのではなかろうか。 今回、声が目立ってニュースにも取り上げられたということかも。

あと、最近広く採用されたBIOSにそういう設定のものがあったのかも知れない。

メーカーはもっと広く知らせるべきでは

と思うんだけど、 BIOSアップデートだとするとあんまり安易に勧められないしなあ。 Windows Updateでなんとかならんのだろうか。 ボードのファームウェアとなるとWindows Updateレベルでは難しいのかな。

結局、PC側の原因で問題が発生するのはどういう場合?

  • RTCの"Daylight Savings Enable"がEnableで、
  • RTCがずれるタイミングでPCが動いておらず(停止 or スリープ)、
  • その後PCを起動した場合(電源投入 or スリープ解除)

は確実に起こるかな。 OSがRTCと同期するとずれた時刻がOSに伝わる。

PCが稼働中にRTCがずれた場合はよくわからない。 OSがRTCに書き込む機会があるかどうかに依存するでしょう。

Windowsだけの問題?

いや、違うと思う。 ボード上のRTCがずれるんだから、 ずれた後に起動すれば例えばLinuxでも時間がずれるでしょう。

ただ、Linuxとかの場合、 どういうタイミング・方法でntpサーバーと同期しているのか知らないので、 その影響はよくわからない。 Windowsより短い期間で同期しているマシンが多いような気がする。 知らんけど。

まとめ

PCの時計がずれて直っていない人は、 PCメーカーからBIOSの更新が出ていないか確認してはどうでしょうか。

ただ、 BIOSアップデートは無条件にお勧めできるものでもないので、 アップデートするかどうかは注意事項をよく読んでからお決めください。

2017年4月 4日 (火)

PCの時計が1時間進む問題が発生したので調べてみた(もう答は出た、と思ったけどなんか混迷している)

昨日(4月3日)、私のPCの時計が1時間進んでいるのに気が付きました。 どうやら、同じ目にあっている人が多数いたようです。

「PCの時計が1時間ずれている」報告多数 (ITMedia)

気持ち悪いので少し調べてみました。 なんですけれど、今日タイムライン上で以下の記事を知りました。 答はこれで決まりでしょう。 (と思ったんだけど、今ちょっとわけわからん状態になっている。「で、どうするよ」の項で後述)

「PCの時計が1時間ずれている」の原因 (Tactful Answer)

ですが、せっかく簡単な実験などしていたので、 書き残しておきます。

  • 観察
  • 実験
  • で、どうするよ

観察

4月3日夜、家の帰ってPCをスリープから復帰させてしばらくして、時計が1時間ずれていることに気づきました。 家にPCが数台ありますが、自分のノートPC1台のみ時計が進んでました。

で、イベントログの「システム」でスリープ前後を見ると、 以下のようなログが残っていました。

時刻 ログ
2017/04/03 0:32:53
システムがスリープ状態になります。

スリープの理由: アプリケーション API
2017/04/03 0:32:54
システムがスリープ状態から再開されました。
2017/04/03 20:57:35
システム時刻は ‎2017‎-‎04‎-‎02T15:32:54.726613700Z から ‎2017‎-‎04‎-‎03T11:57:35.500000000Z に変更されました。

変更の理由: システム時刻がハードウェア クロックと同期されました。

時刻はUTCで出ていますが、 日本時間に直すと、 4/03 0:32にスリープしています。 その後、スリープから復帰し、直後にハードウェアクロックと同期しています。 この際のハードウェアクロックの時刻は20:57です。 「再開しました」ログのタイムスタンプが0:32:54なのは、クロック同期前なので、スリープ時点の時刻が出てしまっているのでしょう。

記録されたスリープ時の時刻は前夜の記憶通りで正しいものです。 一方、PCを再開したのは20時前でした。 つまり、復帰時にハードウェアクロックが1時間進んでいる。

復帰時のハードウェアクロックが進んでいるので、 OSではなくPCのクロックの問題なんだろうと思って、 以下のようなツイートをしました。

実験

で、今朝(4/04)、ちょっと実験をしてみました。 出勤前に、PCに以下の操作をしました。

  1. PCをLANから切り離す(WiFiも無効にする)
  2. PCを再起動し、Windowsは起動させず、BIOS画面で時間を4/02 23:30にする
  3. 電源を切る

夜、帰宅後に電源を投入し、そのままBIOS画面を出して時間を確認しました。 すると、予想通り、朝ずらした時間から予期される時間よりも1時間進んでいました。

LANに繋がず、OSも動かしていない状態で時計が進んだので、 OSもタイムサーバーも無関係。

この結果は、 冒頭に紹介した記事(「PCの時計が1時間ずれている」の原因 )の説明と整合します。

で、どうするよ

先の記事の説明に従って自分のPCを調べたところ、 確かにPCの"Daylight Savings Enable"設定が有効になっていました。 これが有効だと、4月と10月にPCのクロックがずれます。 つまり、この先も半年ごとに時間がずれることになります。 自分はツールで設定を変更するとして、 一般ユーザーとかどうするんだろうか。 これは多分工場出荷時の設定がこうなっているんだろうから、 メーカーのサポートに連絡した方がいいんだろうか、 とか思っていたところ、 Microsoftが修正(!)したとのニュースが。

「PCの時計が1時間ずれる」グローバルで発生「修正した」とMS (ITMedia)

いったい、どうやって? Windowsから"Daylight Savings Enable"を無効化してくれるのか? まさか、強制的に時刻同期させて終わりじゃないよな? 半年後またずれるし。

疑いをもちつつWindows Updateを試みましたが、 なにも落ちてきません。 念のため、先のツールで再チェックしましたが、 "Daylight Savings Enable"は有効のままです。

謎。しばらく様子見。

あともう一つ疑問があって、 なんで今回のみ騒ぎに? そういえば、このPCにしてから時計がずれていたことが以前にもあって、 「あれー」と思いながら時計を合わせたような覚えがぼんやりとあるんだけど、 今回これほど騒ぎになったのはなんでだろう? 最近よくPCに採用されているボードがこの設定になっているとか?

2017年3月26日 (日)

Windows Mobileしんでしまうん?

最近、 Windows 10 Mobileを採用していたスマホが、 新モデルではAndroidに鞍替えしていた、 ということが立て続けに2件ありました。

で、「やっぱりねー」みたいな雰囲気を感じるので、 私の見るところなど書こうと思います。 状況は厳しいけど、まだ終わる状況じゃないと思ってます。 ただ、結果的に「空白期間」が生じてしまっているので、 もっとうまく立ち回れないもんですかねえ、 というような話。

なお、これは私がニュース等を見てて個人的に思ったことを書いています。 勤務先はスマートフォンに関連している部署もありますが、 私はそことはほとんど関係ないし(というか関係あったら勝手なこと書けない)。

話は2016年始めの頃から。

2016年始めの時点

あれは2016年の始めだったか。 「Microsoftはスマホを諦めている。はやくそれを公式に認めるべき」みたいな記事が海外で出てました(ちょっと検索してみたけど、探し出せなかった)。 まあ、苦戦しているのは確かだけど、 現在進行形で戦略遂行中で、 次の施策もまだある状況で「諦めてる」と決めつけるのはひどいなあ、と思った憶えがあります。

この頃、 前の年にリリースしたWindows 10をやっとこさでスマホにもロールアウトしたところでした。 これにより、 PCもスマホもその他デバイスも、 Windows系デバイスは「Windows 10」というプラットフォームで統一され、 同じプログラミングモデル(UWP)アプリを書けるようになりました。

で、次の施策は以下だと見られていました。

  • アプリの拡充支援
  • Surface Phone

アプリの拡充支援策としては、例えばAndroidやiOS向けアプリを簡単に向けに移植する「ブリッジ」を提供しようとしていました。 が、結果としてはあまりうまくいっているように見えません。 「Windows Bridge for Android」はキャンセルされました。 「Windows Bridge for iOS」(現在v0.2)は開発が続いていますが、「使った!」という話をまだあまり聞きません。 まあ、アプリ拡充は今となってはWindows 10 MobileだけでなくUWP全体の問題になるので、 この点についてはWindows 10 Mobileの動向がどうあろうともMicrosoftは頑張ってくれるでしょう。

一方、Surface Phoneは、公式にはMicrosoftは発表していません(開発していることは認めているんだっけ?)。 この時点では、PCにおけるSurfaceのように、 新しいコンセプトを提案するようなモデルになると期待されていました。 いや、まあ、今でもそれは同じなんですけど、 登場時期が当初予想されていたより大幅に遅れており、 遅れた結果、もっと切実な問題が起こっていると思います。 これについては次の項で。

2016年夏-秋

2016年夏、MicrosoftはLumiaを作っている元Nokia部門をリストラしました。 また、Lumiaブランドのデバイスの販売を2016年末で終わらせてしまいました。 これは結構衝撃だった。 日本ではLumiaを販売していませんが、 世界的には出荷されているWindows Phone/Windows 10 Mobile機の大多数はLumiaであり、 その「大多数」の供給が無くなるわけだから。

私は、本来この時期にSurface Phoneを出す予定だったのではないかと思っています。 ここでLumiaからSurfaceへのブランド切り替えをする予定だった。 ところが、Surface Phoneが大きく遅れた一方、 Lumiaは次の計画が無いのでラインを継続させておくわけにもいかず、予定通り終了。 おかげで、Windows 10 Mobileは主流となる機種が不在になってしまった。

なぜSurface Phoneが遅れたかは、外部からは知りようがないです。 ただ、以前にわりと信じられていた噂には、 Surface PhoneはIntelのCPUを採用している、というものがありました。 そのため、2016年春のIntelのモバイル向けSoCからの撤退決断はSurface Phoneを直撃し、計画変更を余儀なくされるのでは、 と見る向きもありました。 そう言われてみれば、 冒頭のAndroidに鞍替えした件に関連して、 「今年のSnapDragon 600番台はMicrosoftのWindows 10 Mobileのサポート対象から外れていた」という証言があり、 素人目には「Intelを主力CPUにしようとしてリソースつぎ込み、一方SnapDragonのサポートは絞ってて、あてが外れたんじゃないのかよ」とか疑ったりもするのです。 知らんけど。

で、(再企画したかもしれない)Surface Phoneは(早くとも)2017年秋になるといわれています。 2017年秋といえば、Windows 10のRedstone 3のタイミングです。 Redstone 3といえば、 大きめのアップデートと言われており、 Redstone 2 and Redstone 3 are going to be heavily focused on "innovation around mobile phones."といわれるやつでもあり(ただし、この記事ではSurface Phoneは2017年4月リリースになっている)、 ARM版Windowsの復活であり、 x86エミュレーターが載るわけであり、 このあたりが次のキモだと思うのです。 Surface Phoneにx86エミュレーターが載るかどうかはわからんけど。 素のWindows 10にARM版が復活することで、 よりPC/タブレットとの差が無くなっていく方向に進んでいくんじゃないかな。 ひょっとすると、その先は「Mobile」カテゴリは無くなって、 「Windows 10」でスマホもカバーすることになるかも知れない。

今後の見込み

というわけで、まだ次の計画があるんだから、「諦めた」状況ではないだろう、と思っています。 つい最近もWindows Mobileのプログラムマネージャーの求人しているし

とりあえず、Surface Phone待ちかなあ。 私的には、もうSurface Phoneは「新しいコンセプトを提案してくれるデバイス」ではなく、 「Microsoftがスマホにコミットしていることを宣言するデバイス」として期待を一身に集めております。 本家が主力ブランド(Lumia)を止めて次をどうするか明らかにしていない現状では、 周りもコミットできないでしょう。 でも今年の秋だから、まだ遠い。

何にせよ、 今後の計画の説明なしにLumiaを販売停止すると、「撤退だ!」と思う人もいるでしょうし、 シェアが小さい状況でこんな空白期間ができてしまったらただでさえ心もとないエコシステムが消えてしまいそうで気が気ではありません。 もしSurface Phoneがずるずると伸びると、空白期間はさらに広がっていくことになります。 なんかもうちょっとうまくメッセージとか出せないもんでしょうか。 Microsoftがデバイス出せない状況なのだからパートナー頼みなのに、 パートナーさんに「梯子を外された」とか感じさせてはあかんだろう、と思うのです。 本当にたのんます。

Windows 10 Mobileに将来性はある?

まあ、現状苦しいのは確かだけど、 ぼちぼちスマホ市場の状況も変わりつつあり、 まったく目が無いわけではないと思ってます。

iOSとか、そろそろMacとの関係をどうするんだということが問題になってくるんじゃないかな。 新しいモノを世に出す際には、その目的のために鋭く割り切ったようなモノでなければ認知されることはないでしょうが、 いったんブレイクして色々な人が使い始めると、色々な要求に対応せざるを得なくなり、どんどん肥大化していきます。 iPod/iPhoneはその目的を実現するために後にiOSとなるシステムを作ってそれを活用したわけですが、 iPhoneがブレイクして成長した結果、いいかげんiOSも巨大になっているように見えます。 一方、少なくとも先進国ではスマホが飽和しつつあるようです。 成長が鈍ってくると、iOSとOS Xが「二重投資」に見えてきてきつくなるんじゃないかな。

で、iOSに限らず、 PC的なものとスマホやその他デバイスと、少なくともOSは統合しようぜ、 という流れが出てくるんじゃないかと思っています。 となると、Windows 10で各種デバイスのコード統合が済んでいるWindowsは、システム的には一周回って半歩先んじている状況にならないかな。

まあ、それでもアプリ不足をなんとかする必要はあるし、 優位点が生きる状況にするにはマーケティングが必要だし、 そもそも続けていなければ優位点もへったくれもありませんが。

まとめ

使い続けたいので、なんとか存続してください。 まあ、IS12Tの後、4年放置されたのに比べるとまだ何てことないけど(強がり)。

あと、MADOSMA信じてます。

2017年3月 7日 (火)

OAナガシマのおっさんの話(Visual Studio 20周年記念)

Visual Studioは今年で20周年だそうで、 #MyVSStory などというハッシュタグもできていました。

おおっと思ったので、こんなことを書きました。

で、OAナガシマのおっさんのことをちょっと思い出したので、書き残しておこうかなと思います。 実はそんなによく知らないし、 人柄を表すようなエピソードとかも無いんだけど、 大昔、おっさんを店頭で見かけていた頃の話。

OAナガシマとは

私が沼津に来たのは90年代始めの頃です。 地元の人に「沼津のパソコンショップならここ」と教えてもらったのがOAナガシマでした。 「OAナガシマ」という店名からして、 OA事務機器屋が出自なのでしょう。 (そういえば、当時DOS/V雑誌に怪しげな広告を載せていた「大西ジム」も高砂の商店街の文房具屋(ジム = 事務)でした。何回か行ったことある。今検索したら、まだ元気でやっているらしい)

その頃の店は沢田のバイパス沿いにあり、まあ、いわゆるDOS/Vショップでした。 世界的には、ちょうどPC/AT互換機上でWindowsがブレイクした頃です。 日本ではNECやら富士通やら東芝やらが独自規格のパソコンを出しており、 それらは結局PC/AT互換(いわゆる「DOS/V機」)になっていくのですが、 その時点ではDOS/Vはまだ立ち上がりかけの頃でした。 Windowsが盛り上がっており、海外で面白そうな機器やソフトが出るのに、 日本は独自規格のせいでなかなか利用できない。 Windows 3.1とか、USで発売されてから国内発売されるまで1年以上かかったなあ。 各社版の対応に手間取っている、とかの噂でした(本当かどうかは知らない)。 「鎖国状態」とか言われたりしてましたね。今ならガラパゴスか。 お好きな方はPC/AT互換機を個人輸入したりしてましたが、 そういう「DOS/V」世界の窓口がDOS/Vショップでした。 秋葉原ならたくさん店もあるんでしょうが、 地方なもんで、 近所にOAナガシマがあるのはとてもありがたかった。

なんか、DR-DOS買ったこととか思い出した。 冷やかしのつもりで店番してたおっさんに声をかけたら、 勢いに乗せられて気づいたら買ってて、 しばらくDR-DOS使ってたよ。

さて、時は1992年

Windowsはまだ16-bitの3.xの時代。 ちょうどアメリカでVisual Basic 1.0(これがまたちょっとした衝撃だった)が出た翌年。 私は「某言語でVisual Basicみたいのを作ろう」というプロジェクトに配属されました。 当時のWindows開発環境は、コマンドラインベースのMicrosoft C 6.0 + Windows SDK。 デバッガ(Code View)はこんな感じ。 (Microsoftのフォーラムの質問にCode Viewの画面イメージがあったので引用)

Code Viewの画面

せっかくWindowsがGUIを導入したのに、開発環境はキャラクタベースです。 ついでに言うと、会社支給のパソコンはFMRという独自規格。 それに富士通が出しているFMR用のDOSとWindowsとWindows SDKを入れて頑張るわけです。 (ちなみに、富士通の「DOS/V機」であるFMVは翌年秋の発売でした)

そんな中、 このプロジェクトが調査用に購入していたソフトウェアの中にQuick C for Windowsがあって、 これを動かしてみて私は衝撃を受けました。 フルGUIだし、「統合」されていて、ビルドからデバッグまでその上ですべてできる。 Windowsが普及し始めたころで、当時はWebとかもまだ広がってないためググるわけにもいかず、 Petzold本とかを頼りにプログラムを書いて色々挙動を確認するんですが、 この「ちょっと書いて動かしてデバッガで状況を見る」ということがGUI上で一目瞭然にストレスなくがんがん回せる。 生産性、という言葉では気が済まない、なにかパラダイムシフトのようなものが頭の中で起こりました。 目から鱗。

巧みな操作で計算機リソースを効率的に使う、 というのがスマートだと思っていました(まわりの達人的な人はほとんど共用ワークステーションとかにぶら下がってたし)。 しかし、考えたらこれは「パーソナル」なコンピュータなので、 CPUを自分の都合のためにぶん回すのは大正義である、 いや、自分が仕事を遂行するためにぶんぶんぶん回すべきである。 能天気にカーソルキー押しっぱなしてスクロールするのはCPUを無駄に使う頭悪そうなやり方だけど、 それで簡単に目的の場所に行けるならいいじゃないか。 「パーソナル」用機械を好きに使ってさっさと仕事しろよ、ということに思い至ったのでした。

人によってはVisual Basicが目から鱗だったりするようですが、 私はQuick C for Windowsだったなあ(いやまあ、Visual Basicも凄かったけど)。

ということで、 同じく調査用に海外から購入してたGateway 2000のマシン(鉄の筐体、純白の4DX2-66V)を占有し、 DOS/VとWindowsを入れ、Quick Cでごりごりプログラムを書いていました。

そんなこんなしているうちに

アメリカでVisual C++ 1.0が出ました。 「むっちゃ欲しい」と思うわけです。 IDEも進化しているみたいだし、CもC++になっているし。 でも日本では発売していない。

で、とある日曜日にOAナガシマに行ったら、 なんということでしょう。 置いてあるんですね。 でかい箱がでーんと置いてある。 おっさん、どこからモノを引っ張ってきたんだと思いました。 しかも、US価格から想定した値段よりかなり安い。 バッタもんじゃなかろうかとも疑ってまじまじと見てみましたが、どう見ても本物。 結局買いました。 両手でないと持てない大きさで、重かった。 開けてみると、中にはみっしりとWindows APIのマニュアルが入ってた。

当時の写真を探したら、箱が写っているものが一枚ありました。 あまりに部屋が乱雑で全景を出すのはアレなので、一部切り出しますが、箱の奥行をお察しください。

Visual C++の箱

探してみたら、フロッピーディスクまだありましたよ。

Visual C++のインストールフロッピーディスク

安かった理由は謎です。 仕入れ経路で誰か何か間違えてたか。 実はアップグレード版か何かだったりして。

ともかく、 Visual C++というアイテムを手に入れた私は絶好調でぶいぶいいわせながら開発したのでした。 当時まだ私物ソフトの使用禁止とかルール化される前でしたね。 まあ、仕上げには会社設備のMSCでコンパイルするようにはしてたけど。

その後

Visual C++はVisual Basicと統合されてVisual Studioになりました。

一方、 OAナガシマの方は、どんどん店が増えていきました。 本店は沢田から今ある大諏訪に移り、 ZOAという名前で静岡県以外にも店を出すようになりました。 今の正式な社名は「株式会社ZOA」のようですね。 その頃にはもうおっさんを店頭で見ることはなくなりました。 そういえば、Windows 2000の発表時には、 マイクロソフトの発表資料に他のメーカーやショップに並んで、 おっさんのコメントが載っていたなあ。 今検索して探し出したプレスリリースには社名しか出ていないけど、 当時のリリースではこのコメントがおっさんの名前入りで出てて、Webニュース経由で見てのけぞった記憶がある。

そして、一、二年前、 店の営業時間を確認するためにOAナガシマのサイトを見に行って、 間違って「会社概要」を開いてしまったら、 代表者の名前がおっさんじゃなくなっていました。 引退したのかな、とも思ったのですが、 気になったのでIRを見てみたら、 2013年の夏におっさんが亡くなったとの知らせが出ていました。

昔の沢田の店も、 去年更地になり、 ポルシェの店になりました。

その頃(もう四半世紀前)からすると、 PCをめぐる状況も、 OSやソフトや開発環境のあり方もずいぶん変わりました。 一方、その頃作っていたそのソフトは、 幸運にも気に入ってくれた人が結構おり、 バージョンを重ね、 まだ稼働しているものもあります。 ソフトウェアが世に出るのはいろんな人の仕事やら偶然やらが積み重なった結果なのですが、 あのソフトには「おっさんがVisual C++をどっかから引っ張ってきてくれた」という要素も入っているのです。

ということで、 おっさんのご冥福をお祈りします。 と同時に、Visual Studio 20周年おめでとうございます。

2016年5月30日 (月)

「りんな」の仕組みをもうちょっと詳しく調べてみた

5月25日に、de:code 2016のセッション「りんなを徹底解剖。"Rinna Conversation Services" を支える自然言語処理アルゴリズム」に参加してきました。 人気のセッションで入場制限になりましたが、ぎりぎり立ち見で参加することができました。 セッションビデオや資料はまだ公開されていませんが、 ニュース記事は以下のものなどが出ています。

今まで、 「女子高生AI bot」たる「りんな」の背後にディープラーニングや機械学習が働いている、 ということは聞いていましたが、 具体的な解説は見かけませんでした。 で、このセッションでは技術解説もあるらしい、 ということで聞いてきたわけです。

セッションは上の記事にもある通り、とても面白い内容でした。 ただ、私は最近ディープラーニングを勉強し始めたこともあり、 ディープラーニングを使っている具体的な場所をもう少し特定できんものだろうか、と思ったのでした。 そこで、 週末にセッション中で言及された論文を元に、 もう少し詳しく調べてみました。 まあ、この論文も、言語処理学会の年次大会(NLP2016)の20分枠の一般発表資料らしく、わりとざっくりした感じですけれども。

ということで、 以下、セッションと論文を突き合わせて考えた私の理解。 まだ説明読んですべてがぱっと分かるような境地ではないので、正しいかどうか自信ないけど。

チャットワーカー

今回調べる対象は、チャットワーカーです。 言葉を入力とし、言葉を出力とする部分。

りんなのフレームワーク

りんな:女子高生人工知能」から「図2. りんなのフレームワーク」

まず、りんなのシステムは、 インターネットから収集した「対話ペア」を学習ネタとして保持しています。 論文では「対話ペア」は厳密に定義されていませんが、リクエストとレスポンスからなる言葉によるやり取りと考えてよいでしょう。 後の話から考えて、 「対話ペア」のプールは「女子高生的ないい感じの会話」が選択されて大量に集められているんじゃないかな。

その上で、チャットワーカーは以下の二つのモデルを対話のエンジンとして使います。

  • ランキングモデル
  • 生成モデル

ランキングモデル

ランキングモデルは検索システムに似たシステムで、 対話ペアの中から、ユーザー入力(リクエスト)に最も類似するものを選び、そのレスポンスを返します。 その類似度(ランキング)を決定するランカーは以下の素性を使います。

  • 翻訳モデル(説明略)
  • 文の長さ
  • AIM言語モデル(説明略)
  • GRU類似度

この最後の「GRU類似度」の計算にRNN(ディープラーニングの技法のひとつ)が用いられています。 de:codeのセッションやその記事で「DSSM + RNN-GRU」として特に詳しく解説されている部分がここに相当します。 大量の「いい感じの対話ペア」を学習させることで、 ユーザー入力に対する各レスポンスの「類似度」(すなわち、「いい感じ対話度」)が出力されるニューラルネットを用意した、ということでいいのかな。 この部分の詳細な説明は、最初に挙げた記事を参照してください。

なお、ランカー自身はブースティング決定木として学習されます。

生成モデル

生成モデルは翻訳システムに似たシステムです。 リクエストを翻訳元言語、 レスポンスを翻訳先言語とみなして 統計的機械翻訳のような枠組みで対話ペアを学習させ、 リクエストからレスポンスを生成させます。

原理的にはここの学習でもRNNとか使うやり方もあるんじゃないかと思いますが、 論文には特にディープラーニングを使っているとは書いていません。

セッションで「りんなが詠む俳句はストックしているのではなく、その場で生成している」という話がありましたが、 俳句の生成は生成モデルを使っているのかな? ランキングモデルから俳句をひねり出せそうな気がしないし。 もしそうなら、その場合リクエストとして何を入力しているんだろう?

ランキングモデルと生成モデルの使い分け

特に書いていないです。 ランキングモデルで選択した対話ペアのランク値があまりに低い場合には生成モデルで生成している、とかかな。 あるいは簡単な言い換えを実現するためとかに生成モデルを使うのかな。 「犬かわいい」から犬を猫に置き換えて「猫かわいい」へ置き換え、とか。 まあ、よくわからん。

思うことなど

もしこの理解が正しいとしてですが…

ディープラーニングの使いどころが思っていたものと違いました。 「いい感じ」を直接学習しているわけではなく、 既存の対話ペアの類似度を算出するのに使われており、その値がランキング判断の一要素として採用されるわけですね。

チャットワーカーは、 大量の「いい感じの女子高生っぽい対話ペア」を様々な技法で学習・活用することでいい感じの対話を実現しているということになります。 りんなのコンセプトが「Emotional AI」ということで、 なんらかの「感情値」みたいなものを計算しているのかと思ってたんですが、 こういう風に「いい感じのもの」を集めて学習させればいいのか。 なるほど。 それとも、一般にbot類はそういう風に作るものなのかな? 知らんけど。

また、このやり方だと、 ちょっと前に起きた、Microsoftの別のbotである"Toy"が不適切な会話を学習してしまった、 というような事件は原理的に起こりにくい、のかな。

あと、 りんなはあまり複雑なステータスは保持しておらず、 入力に対して反射的に回答している、 ということになります。 「その話さっきしたよ」みたいなことが発生するだろうけど、 あまり整合性のある会話を要求されないから、いいのか。

一般に、ディープラーニングをやるには正しくラベル付けられたデータを学習ネタとして大量に用意することが一苦労です。 りんなの場合、「女子高生的ないい感じの対話ペア」を大量に用意しているということになります。 ネガティブな対話ペアを学習させるわけにはいかんので。 この対話ペアの選別ってどうやっているのかな。 手作業じゃあないよな。

余談

「りんな」の名前は"RNN"に由来する、という話があるそうですよ。 セッションで技術部分を説明したりんな開発者のWuさん(上の論文の筆頭著者)はその話について「さて、どうですかね~(ふふふ)」みたいな反応でした。

さらに、セッションスピーカーの砂金さんが「一説によると」として、 「りんな」の名前の由来は"RNN"と開発者の坪井一菜さんの"Kazuna"から来ているらしいと紹介していました。 こちらは、同じくスピーカーだった坪井さんにその場で否定されていましたが。