2017年8月27日 (日)

IS12Tとわたくし

一昨日、auがこんなツイートを。

4年近く愛用してたよ。 ちょっと感慨深くて、何か書きたくなった。

ただ、まあ、IS12Tの発売がどんなに感無量であったかを書くには、 Windows Phoneの前史から語らねばならなくてですね…

Windows Phone 7まで

元々Microsoftは大昔からスマートフォンを作っていました。 それこそiPhoneが出るよりずっと前から。 当時「スマートフォン」と呼ばれていたものは電話回線につながるPDAみたいな感じだったけど。 日本でも2005年のW-ZERO3で知られるようになりました。 残念ながら住んでいる所が当時ウィルコムのサービスエリア外だったので、 私はW-ZERO3は買いませんでしたが、 その後、ソフトバンクから出たWindows Mobile(現行の"Windows 10 Mobile"ではなく、"Windows Mobile 6"ね)を使ってました。 X01TとかX02Tとか。

そんなこんなしているうちに2007年にiPhoneが出て(日本発売は2008年)、 「スマートフォン」のイメージを塗り替えてしまいました。 Microsoftも「これはいかん」ということで、 スマートフォンOSを刷新することになります。 確か、新しいやつは従来のWindows Mobileじゃなくて、 Zune(Microsoftのメディアプレーヤー)を元に作り直したんじゃなかったっけ。 あのタイルUI(メトロ)もZune起源だったような。 今や本家Windowsにもメトロの後継が入っていますね。

開発は順風満帆とはいかなかったようで、 Windows Mobile 6.5を繋ぎで出さざるを得なくなったり、 Kinという別系統のスマホを発売してたった2カ月でディスコンにするというわけの分からんサイドストーリーがあったり、 なんだかんだで、 2010年にやっとこさ"Windows Mobile 7"改め"Windows Phone 7"が登場しました。

が、今度はなかなか日本で発売されない。

技適の問題もありますが、 当時はまだSIMロック端末が一般的だったので、 キャリアがちゃんと対応機を出してくれないと国内で使い物にならないのです。

IS12T!

で、うーうー唸っているうちに、2011年7月27日、 突然auから「IS12Tを8月25日から発売する」との発表があり、 色めき立つのです。 しかも世界初のWindows Phone 7.5機です。 「Windows Mobileを現代風に作り直すやで」と聞いてからはや3年です。 まさかこの後、国内で次のWindows Phoneが出るのが4年後になるとは思わなかったけど。

開発は東芝ですけど、 直前に東芝と富士通のケータイ部門が事業統合したため、 富士通機種のような扱いになっていました。 でもロゴは"TOSHIBA"だったな。 発売直前に社内割引きで買えるとのアナウンスがあり、 速攻で予約しました。 色はシトロンを選びましたが、 シトロンは入荷待ちで発売当日には入手できないといわれた。 でも、発売翌日に入荷したとの連絡をうけ、 次の日、窓口のある武蔵小杉へ沼津から受け取りに行きました。 契約書を掘り出して確認しましたが、 ちょうど六年前、2011年8月27日でしたね。

感無量でしたねえ。 ぬるぬる動くし、 従来のWindows Mobileからずいぶん「現代的」になってたし。 カラーも気に入ったし。

当時、 スマホではまだあまりカラフルなモデルは出ていなかったように思います。 とくに海外では。 Lumiaが青や群青のWindows Phoneを出してなかなかカッコよかった記憶がありますが、 それでも青系で、 派手な色のスマホはIS12Tが先駆けのように思うけど、どうかな。 Lumiaが黄色とかを出したのはその後じゃなかったっけ。

ただ、機能は仕上がっていない部分もありました。 始めの頃は二三日ごとに再起動していたし、 冬まではSMSの受信はできても送信はできてなかったりして、 妻からのSMSにメールで返信するというはめになり、 iPhone使いの妻に「それは便利なのか?」と煽られたりしてました。 アップデートしているうちに色々直って安定してきましたが。

空白の4年間

というわけで、 機嫌よくIS12Tを使っていたわけですが、 これに続くWindows Phoneが国内でまったく出てこない。 「Microsoft側の都合」ということでしたが、 具体的な理由は公式に出たことはなかったんじゃないかな。 ストアなどの環境を日本向けに整備するのが追いついていないのではなかろうか、 とか言われていました。 この少し後にWindows Phoneの公式マップとして採用したNokiaのマップとか、 日本の領域はスカスカだったし。

一方、海外ではそれなりにWindows Phoneが出ていました。 Nokiaの力もあったのでしょう。 特に2012-13年頃はヨーロッパでわりとシェアがあったような。 イタリアとかiPhoneよりシェアが多かったはず。

IS12Tにはその後Windows Phone 7.8が配信されましたが、 それが最後。 ハードの世代的にWindows Phone 8にはできない。 主にNokiaがWindows Phone 8機を海外で出すのを横目で見ながら 再びうーうー唸る日々が続きました。

そして、ついに、2014年10月にWindows Phone 7.8のサポートも終了します。 でも、しばらく使い続けてたけど。

復活

2015年早春、マウスコンピューターとかFREETELとかがWindows Phone機の開発を表明します。 まあ、今までの経緯があるので「実物を手にするまで信じひんのやー」という思いでしたが。

ところが、6月、思ったより早くマウスからMADOSMA Q501が発売されました。 もちろん、すぐに入手しました。 またまた感無量です。 4年近くぶりですよ。 IS12Tと比べて、手に取った時あっけらかんと軽いので驚いた覚えがある。

この年、 Windows Phone OSもWindows 10ベースになり、 それに伴いブランドも"Windows 10 Mobile"に変わりました。 このMobile版のWindows 10のリリースに合わせて、 翌年にかけてWindows 10 Mobile機が国内でいくつか出ました。 11月には、Windows 10 Mobileの「日本最速提供」競争が発生していました。

  • 11/24: FREETEL Windows 10 Mobileスマホ「KATANA 01」を発表。
    • 11/25 受付開始
    • 11/30 発売(この時点で最速と思われた)
  • 11/26: ヤマダ電機 Windows 10 Mobileスマホ「Every Phone」を発表。
    • 11/28 発売(この時点で最速と思われた)
  • 11/27: マウスコンピュータ 既存のWindows Phoneスマホ「MADOSMA」へのWindows 10 Mobile搭載を発表。
    • 11/27 既存機の有償アップデート代行を開始。3000円。ダイレクトショップに持込んでアップデート可。
    • 12/04 Windows 10 Mobile搭載MADOSMA発売
    • 12月 既存機へのアップデート配信開始

結局、11/27に既存のMADOSMAをダイレクトショップに持ち込んでアップデートしてもらうと、 一般提供の公式版を「日本最速」で入手することができたようです。

まあともかく、日本では妙に盛り上がっていました。 逆に世界では失速ぎみでしたが。 このあたり、うまく波が噛み合わない。

で、現在

また微妙な空白期に入ってしまいました。 Microsoftはスマートフォンをあきらめていないようですが、 次の動きは2018年以降になりそうです。 Fall Creators UpdateのARM対応に合わせてなにか動きがあるんじゃないかと思っていましたが、 これは外れたようです。 また、どうやら現行の機種は「次のWindows 10 Mobile」にはアップデートできないっぽい。 あらあらという感じですが、 スマホはハードの制約が厳しかろうし。

まあ、またひたすら待つ局面です。 待つけど。 でも、Microsoftももうちょっとロードマップというか、どうするつもりなのか言った方がいいんじゃなかろうか。 おっちゃんは待つけど、パートナーは愛想つかさずに付き合ってくれるんだろうか心配。

再びIS12Tについて

結局、IS12Tは四年近く使い続けました。 その間に妻のiPhoneは3回ほど変わって、 回線もLTEになったりしましたが、 その激動の時代をあまり不満なく使っていたなあ。 スマホに関してはタイルUIが気に入っているし、 タイルのシトロンのカラースキームも好きだった。 さすがに最後の方は回線速度とか色々重かったけど。 電源はもう入れませんが、まだ手元に置いています。

というわけで、 IS12Tに感謝しつつ、 Windows 10 Mobileの存続を切に祈念しております。

2017年8月 9日 (水)

「認証プロキシ爆発しろ!」が自動構成スクリプトに対応しました

認証プロキシをなんとかするためのツールであるところの「認証プロキシ爆発しろ!」ですが、 プロキシ設定の自動構成スクリプトに対応しました。 自動構成スクリプト(.pacファイル)によって複数のプロキシを使い分けているような環境では、 「認証プロキシ爆発しろ!」は自動構成スクリプトの内容に応じた適切なプロキシに対して中継を行うようになりました。

今回のバージョンアップに伴って、設定の変更が必要になります。 以下、それも含めた説明など。

  • ユーザーへの影響
  • 従来の動きと問題点
  • 新しい動き
  • 設定変更の必要性
  • 問題など

ユーザーへの影響

現在「認証プロキシ爆発しろ!」をお使いの方のうち、 以下の条件に該当する方は設定変更の必要があります。

  • コントロールパネルの「インターネットオプション」-「接続」-「LANの設定」の「自動構成」 (Windows 10の「設定」で言えば「ネットワークとインターネット」-「プロキシ」の「自動プロキシセットアップ」)が 有効になっている環境下で「認証プロキシ爆発しろ!」をお使いの方。

と言っても、 ver 1.0.17.0以降のGUI版「認証プロキシ爆発しろ!」を起動すると、 変更の必要のある場合は「設定を推奨値にするか?」という画面が出ますので、 「はい」を押せばほとんどの場合大丈夫です。

設定変更の必要性の詳細を知りたい方は、 以下の説明をお読みください。

従来の動きと問題点

従来の「認証プロキシ爆発しろ!」において、 通信の中継先となるプロキシ(「実際のプロキシ」)はひとつだけでした。 通信の中継を開始する際に、 「実際のプロキシ」のアドレスを自動検出し、 そのアドレスに対して中継を行っていました。

一方、 多くの環境では自動構成スクリプト(.pacファイル)によるプロキシの自動構成が行われています。 この自動構成スクリプトでは、 通信元のアドレスや通信先のURLに応じて複数のプロキシを使い分けるということができます。 「認証プロキシ爆発しろ!」はこのような環境で複数存在する「実際のプロキシ」を使い分けて中継を行うことができませんでした。

というか、 私がこのツールをふだん使っている環境で、 近々複数のプロキシの使い分けが必須になりそうな状況でして、 そのために真面目に対応する気になったんですけれどもね。

新しい動き

PCのユーザー環境でプロキシ設定の自動検出や自動構成スクリプトが有効になっており、 かつ、 「認証プロキシ爆発しろ!」の「認証プロキシ」設定が「自動検出する」になっている場合、 「認証プロキシ爆発しろ!」は自動構成スクリプトが返す「実際のプロキシ」に対して中継を行うようになりました。

新旧比較

設定変更の必要性

変更が必要になる設定は、 「認証プロキシ爆発しろ!」の設定の「プロキシ」-「システム設定書換え」-「中継時の設定」にある以下の二つの項目です。

  • ローカルアドレスにはプロキシサーバーを使用しない
  • 次で始まるアドレスにはプロキシを使用しない

従来は「認証プロキシ爆発しろ!」を通す必要のないアドレスをここに指定していました。

今後、自動構成スクリプトが有効な環境においては、 いったんすべてのhttp通信は「認証プロキシ爆発しろ!」が中継し、 その内部で自動構成スクリプトの結果に応じて切り分けを行います。 その切り分けには「プロキシを通さない」という判断も含まれます。

なので、この場合、 上の「中継時の設定」は原則不要になります。 ぜんぶ「認証プロキシ爆発しろ!」を通せばよい。 まあ、全通信を中継するオーバーヘッドを考えると、 「プロキシを通さないことが確実なアドレス」は指定してもよいかもしれません。 「ローカルアドレスにはプロキシサーバーを使用しない」ぐらいが実用的ではないでしょうか。 ということで、新しい設定の推奨値は『「ローカルアドレスにはプロキシサーバーを使用しない」のみ有効』にしています。

問題など

「認証プロキシ爆発しろ!」による中継下で、 IEやChromeでは問題がないのに、 Edgeで「プロキシサーバーに接続できません」というエラーが出ることがあります。 現在気づいているケースとしては以下があります。

  • 新しいタブを開いた際の「新しいタブ」ページの「マイ フィード」の項
  • プロキシの内側にあるサイトのページ(外部ページは問題ない)

後者の正確な条件はよくわかりません。 ひょっとしたら、Active Directoryのドメインが関係しているのかも。

この問題の原因は分かりません。 このケースではそもそも「認証プロキシ爆発しろ!」に接続が来ていません。 Edgeが内部でプロキシの要不要をどう判定しているのかが謎。

あと、 ほとんどのhttp通信を「認証プロキシ爆発しろ!」に通すことになるので、 以前よりオーバーヘッドがかかるようになります。

現状、(httpsではない)普通のhttpではレスポンスを返す際にチャンク転送をサポートしていない(まとめて返している)ので、 体感的に遅く感じる場合があります。 これは以前からの問題なんだけど、今回の変更でより目立ちやすくなったかも。

そのうちなんとかしたい。

2017年5月14日 (日)

Windows 10 Mobileユーザーを一時的に増やした話

上の娘の機種変更時のつなぎにWindows 10 Mobileを使った話。 と、おまけで、Windows 10 Mobileをめぐる最近の状況についてちょっと思うところなど。

経緯など

うちには子供が三人います。 下の二人にはエントリーモデルのWindows 10 Mobileを持たせています。 このあたりの経緯は過去に書きました。

子供らの「つなぎ携帯」をWindows 10 Mobileにしてみた話

一方、 上の娘はiPhoneを使っています。 このiPhoneの契約が二年縛りの更新月を迎えました。 で、今になってみると、 うちの他の回線はすべてMVNOにしてしまったし、 こいつもMVNOにして通信料を節約したい。 ところが、都合の悪いことに、このiPhoneはSIMロック解除対応前のものです。

どうしたもんかと、色々費用をシミュレーションしたり娘と話し合ったりして、 「SIMフリーのiPhone SEに乗り換えよう」という結論に達しました。

AppleのiPhone下取りキャンペーン使って乗り換えるぞー。 なに?Apple Storeだとその場で下取分を割引するけど、 オンラインだとApple Storeギフトカードになる? ギフトカードなぞいらん、キャッシュよこせー。 よーし、ゴールデンウィーク中に一家で東京に行く機会があるから、 その時Apple Storeに押し掛けるぞー。 ということで、機種切り替えがゴールデンウィーク中にスケジュールされたのでした。

で、四月の終わり近くにキャリアにMNPの申し込み電話をしました。 例によって転出を思いとどまらせようとするような会話にテキトーに対応していたのですが、 一つ気になる指摘がありました。 予定では切り替えは5月上旬になるのですが、 となると、数日の利用のために5月分の基本料が丸ごと取られてしまうらしい。 「なので、切替えは月のなるべく遅くにした方が...」などとお勧めしてくれるのですが、 こちらは別のことを思いつくわけです。

ピコーン

回線は4月中に切り替え、 iPhone SEを入手するまではWindows 10 Mobileでつなごう。

娘に打診したところ、「一週間ぐらいなら」とOKが出ました。 妹と弟が使っていることもあり、多少の興味はあるようで、まんざらでもなさげ。

機種

機種はMADOSMA Q501を使います。 私がInsider Program入れて遊んでいるやつです。 ちょうど、Creators Updateに相当する10.0.15063.251が降ってきたところでした。 これに対して「電話のリセット」したところ、 都合よいことにOSバージョンは巻き戻らず、 ProductionなCreators Update機ができあがりました。 当時まだ国内のほとんどのProductionな電話にCreators Update降ってきてなかったのに。

MNPしたMVNOのnano SIMをmicro SIMアダプタかませてMADOSMA Q501に載せ、 娘のMicrosoftアカウントを指定し、 OutlookをiCloudのメールアカウントと接続。 あとは好きに設定せいや、 と渡したら、 次の朝にはあっさり実運用しとりました。 この時点でCreators UpdateのWindows 10 Mobile機使っている女子高生って、 日本に数人いるかどうかじゃないか?

というわけで、 わが家におけるWindows 10 Mobileシェアは80%に達しました。

我が家のスマホシェア

圧倒的ではないか、Windows 10 Mobileは。 こまるわー、寡占が進んでこまるわー。

あとは妻だけだけど、 妻は私がX01T時代にメール一本打つのに苦労してたの見てあきれてたからなあ。 今回も上の娘に「Windows Phoneにしたらメール打つのも苦労するで」とか言ってたし(もう今はあまりメール使っていないくせに)、 なかなか手ごわそう。

感想など

娘に一週間ほど使ってみた感想を聞きました。 良い点。

  • タイルのGUIはわかりやすい。
  • 一通りのことは問題なくできる。

悪い点。

  • アプリが少ない。今ゲームとかしてないからいいけど、ゲーム好きな人は困るんじゃないか?(まあねえ)
  • 一部アプリの動きがもっさりしている(まあ、元々そんなに高スペックでもないし)
  • カメラがあんまりきれいじゃない(これはW10Mというよりこの機種の弱い点だな)

その後

予定通り、一週間ぐらいでiPhone SEに移行しました。 家庭内シェアも元に戻ってしまった。

まあ、上の娘もWindows 10 Mobile使ってみてくれたから、よしとするのです。

ちなみに、四月中のMNP切り替えは失敗しました。 元iPhoneのバックアップ等に手間取って、 「当日中の切り替え締め切り」刻限に間に合わず、 5月1日切り替えになってしまった。 あかんやん。

(おまけ)最近のWindows 10 Mobileの話題について

Microsoftの最近の四半期決算にからんで、 「MicrosoftがPhoneビジネスを6月までに終わらせると言った」とか「証券取引委員会に提出した書類で投資項目からWindows Phoneが消えている」といった話が出ており、 またぞろ「Windows Phoneは終わった」みたいに言われています。

Microsoft’s 10Q SEC filing confirms investment in Windows Phone has ended (MSPoweruser)

ざっと見てみたけど、 記述対象となる期間からして、これらは多分Lumiaビジネスを畳んだことを指しているんじゃないかな。 実際、Microsoftの2017会計年度(2017年6月迄)を越えて作業予定があるように見える。 現状、秋のFall Creators Updateに向けてWindows 10 MobileのInsider Preview配信も進んでいるし、 つい最近もSurface Phoneの生存も確認されたし。

Nadella: “We’ll make more phones, but they will not look like phones that are there today.” (MSPoweruser)

今後、Mobileは"Windows 10"の一部分(おそらくはARM版の一部)として活動するんじゃないかな。 Intelがモバイル向けSoCやめちゃったから、 ARM版Windowsを是が非でも何とかしなければならなくなっているしねえ。

で、まあ、Surface Phoneは2017年中に出るのか、2018年になるのか分からないけど、 ハイエンドになるんだろうなあ、と思っています。 一方、あまり具体的な根拠はないんだけど、 Fall Creators Update世代では久々にサードベンダーからハードが出るんじゃないかという気がしています。 関係者のタイムラインとか眺めていると、 なにか動いているんじゃないかなあ、という気がしている。 もちろん、はっきり書いたりしていないんだけど。

なんにせよ、Windows 10ベースのスマホが存続してくれることを切に祈念いたしております。

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周年おめでとうございます。

2017年3月 4日 (土)

SourceTreeでGit LSFを使うには

【要約】「リポジトリ」-「Git LFS」メニュー

分かれば簡単だけど、しばらく迷ってうろうろしたので覚え書き。

SourceTreeはGit LFSに対応していると聞いたのに、 どうやればリポジトリの扱いをGit LFSモードにできるのかが分かりませんでした。 「リポジトリ設定」の画面にも設定ないし。 ヘルプとか検索かけても出てこないし。

が、まあ、気づけば簡単で、 メニューに「リポジトリ」-「Git LFS」という項目がありました。 そのサブメニューの「Initialize Repository」から始めれば、 あとはだいたい見当ついた。

それだけ。

2017年1月26日 (木)

認証プロキシをなんとかするためにツールを作っている話

【要約】認証プロキシをなんとかするためにツールを作ってGitHubで公開した。

経緯

社内ネットワークからhttp/httpsで外部に出る際にはプロキシを通さなければならない、 という環境は多いと思います。 こういうプロキシの中にはユーザー名とパスワードを入れないと通してくれないタイプのものがあります。 認証プロキシというやつですね。 これは本当に頭痛のタネです。

さすがにブラウザとかは認証プロキシに対応しているのですが、 これに対応していないソフトウェアも結構あります。 今時いろんなソフトウェアがhttp/httpsで通信していまして、 特に開発系のツールは必要なコンポーネントをhttp経由で自動的に取ってくるみたいな動作をすることが多いのです。 こういうソフトウェアの多くが素の状態では認証プロキシを通らない。 家で試すと特に問題なく動くツールが、 会社環境だと意味不明なエラーで動かなくなったりします。

ここ二三年、 わけのわからないエラーが出るたびに、 どれが引っかかっているのか調べ、 その設定方法を調べ、 ちまちまと設定しては乗り切っていました。 結果、あちこちの設定ファイルに認証プロキシのパスワードが埋め込まれて、 なにかが間違っているような気がするわけですが、 まあ、仕方ないね。

が、最近Visual Studio 2017 RCのアップデートが認証プロキシ環境内で帰ってこなくなり、 対処方法が皆目わからないという事態が発生するに至って、 我慢の限界を越えました。 こんなもん、やっとれるかーーーーーーーー。

というわけで

ツールを作りました。

これはWindowsのデスクトップ上でローカルプロキシとして動作します。 動かすと、現在のユーザーのプロキシ設定を書き換え、 自分をプロキシとして登録し、 ソフトウェアからの通信を中継します。 で、本来の認証プロキシが認証を要求すると、 通信元のソフトウェアに帰ることなく認証情報をつけてリクエストを再送信します。 結果として、 ソフトウェアが普通のプロキシにふつうに対応していれば、 そのまま通信できます。 中継はタスクトレイのアイコンから簡単にON/OFFできます。

これは認証プロキシを回避するものではありません。 認証プロキシに対応していないソフトウェアのhttp/https通信を中継して、 正しく認証プロキシを通すようにするものです。

効能としては以下の通り。

  • 認証プロキシ環境内で認証プロキシ非対応ソフトウェアを利用することができます。
  • 認証プロキシのパスワードをあちこちに書かなくてすみます。 パスワードは暗号化された状態で設定ファイル一箇所にあれば十分です。 (まあ、元々認証プロキシのパスワードはあんまり安全でないやり方でやりとりされますので、気休めではありますが)
  • 仮想化ソフトウェア(Hyper-Vなど)が定義したマシン内ネットワークに対する(通常)プロキシとして利用できます。 これを利用すると、 「プロキシの設定を埋め込んだままのイメージを公開してしまった!」という事故をやらかしても、 パスワードが埋め込まれないため、多少状況はましになります。

GitHub上で公開しています

設定ウィンドウとかまだ実装できていないけど、 とりあえず役立つ程度には動いているので(Visual Studio 2017 RCのアップデートもできたし)、 tu公開します。 モノはGitHub上にあります。 ツール名は「認証プロキシ爆発しろ!(英語名は MAPE: May Authentication Proxy Explode)」です。

ipponshimeji/MAPE (GitHub)

詳細な説明とかは、 以下のページから。

目次 - 認証プロキシ爆発しろ! (GitHub)

手っ取り早くどういうものか知りたい方は、特に以下のページを。

認証プロキシでお困りの方はお試しくださいまし。

ちなみに

Windows環境で認証プロキシをなんとかするにはFiddlerを使う技とかもありますが、 以下の理由から独立したツールを作りました。

  • Fiddlerを使う場合、Fiddlerのスクリプトをいじる必要(しかもちょっと複雑)があり、 非開発者な人に「これを使えばなんとかできます」とか言いにくい。
  • 自動構成スクリプトでプロキシが設定されている環境では、 Fiddlerのプロキシ設定書き換えは「次で始まるアドレスにはプロキシを使用しない」を設定してくれない。 認証プロキシが設置されているような環境では自動構成スクリプトを利用していることが多いでしょうから、 これは面倒の元になりがちです。

なお、Fiddler自体は便利なデバッグツールとして利用させていただいております。

【2017年4月11日追記】

上にはこう書きましたが、 「次で始まるアドレスにはプロキシを使用しない」に相当する設定がありました。 すいません。

2016年12月 8日 (木)

Microsoft Cognitive Servicesがうらやましいのでパチもんを作ってみた

Fujitsu Advent Calendar 2016の8日目です。 なお、このエントリは個人の立場で書いております。

ディープラーニング関連の話を書こうと思います。 とはいえ、あまり技術的なものではないです。 技術的にすごい話は11日目のsakaiakiraさんや、 他の方が書くでしょう。 ここでは、ディープラーニングを勉強していて湧き上がる心の叫びのようなものを取り上げ、 その勢いでとあるサービスを特に意味なく実装することを試みます。

思うこと

要約すると、だいたい以下になるんですけど、

  • MicrosoftのCognitive Servicesがうらやましいという妬み
  • 自分がろくなデータを持っていないという悲憤

念のため。 これは私個人の話です。 富士通としてはディープラーニングをばりばりやっているところがあるはず。

今、多くのソフトウェア開発者がそうだと思いますが、 私もディープラーニングをぼちぼち勉強したりしております。 私としては、 ディープラーニングそのものももちろん興味深いのですが、 それをプラットフォームにしたり、 サービスにしたりといった方面により興味を持っています。

そういう意味で、 各クラウドの機械学習サービスだとか、 Microsoft Cognitive Servicesだとか、 GoogleのCloud Vision APIだとかを「いいなー」と見ています。

特に、 Microsoft Cognitive Servicesいいですね。 このCognitive Servicesには色々なサービスが含まれています。 LUIS(Language Understanding Intelligent Service)とかも重要そうですが、 私のお気に入りはEmotion APIです。 ディープラーニングの面白さがシンプルに出ていると思う。

Emotion APIは、 画像を送りつけると、 その中から人間の顔を検出し、 どういう感情を持っているかを推測します。 こんな感じ。

Emotion APIの画面

この例では、 お子さんの顔を検出して、 "happiness"とか"anger"とか8種類の観点での「確率」を計算しています。 この値はこの裏で動いている学習済みモデルの計算結果であり、 正確には確率とは言えないと思うんだけど、 全部足すと1になるように調整されているようなので、 確率っぽい数字になっています。 ここでは「確率」と言っちゃいます。 この例では"surprise"成分90%ですね。

Emotion API本体はJSONを返すWeb APIですが、 以下のWebページでAPIの動きを試すことができます(上の図はこのページ)。

Emotion API (Microsoft Cognitive Services)

Emotion APIは今年春先のBuildイベントで発表されました。 その際に私は「ほほう」と思ったもんで、 いろんな画像を突っ込んでみてブログを書きました。

Microsoft Cognitive ServicesのEmotion APIを使ってみた (使って色々思いを馳せた編) (2016年4月2日)

でですね、 こういうのを提供できるっていうのは、 大量に自前データを持っているからだと思うのです。 Microsoftも色々言われながら、 Bingやめなかったのが生きてますね。 API化するなら、自前データだよなあ(「自前って何」と考えると意外と難しいけど)。

ひるがえって自分なのですが、 いろいろお勉強して、 いっちょやってみよー、 と周りを見回すと、 ろくなデータがないのです。 今まで生きてきて私は何をしていたのだろうかと思ってしまいます。 ディープラーニング学習させるには、 従来とは桁違いの量のデータが必要だと思います。 かろうじて量があるのはテキストベースのデータなのですが、 自然言語は一筋縄ではいかないしなあ。 今の業務上も、あんまり処理するよによさげなデータが出てこない。

そこを工夫してデータを探し出したり、 公開情報をあさったり、 データを持っている誰かのところに出向いたり、 なんとか考えるんだ、というのは分かります。 分かります。 が、個人的にブログでぶっちゃけるぐらいはいいだろう。 「きちんとラベル付けられた大量で自前のかっこいいデータがほしい!(なるべく汎用API化できそうなやつ)」

ということで

以上で言いたいことは大体尽くしているのですが、 それだけではなんですので、 この思いをコードに託し、 Emotion APIの如きサービスを立ち上げてみました。

このサービスは、 顔の画像を送りつけると、 いくつかの観点それぞれに該当する「確率」を返します。 Emotion APIが"happiness"とか"anger"の「確率」を返すのと同様です。 その分類の数はEmotion APIの8分類をはるかに凌駕する10分類です。

では、そのサービスを試してみましょう。 Web APIももちろん用意していますが、 とっつきやすいWeb GUIもあります。 操作はEmotion APIの画面と一緒です。 先程のEmotion APIのお子さんの画像を入れてみると、こんな感じ。 スタイルが本物に比べるとしょぼいけど、気にしない。

Digit APIの画面

はい。 このサービスでは、 顔がどの数字(0-9)に一番似ているかを判定します。 顔の領域の検出機能は残念ながらありません。 というか、入力画像が顔であるかどうかも実は気にしていません。

お察しの通り、 このサービスはディープラーニングにおける"Hello World"たるMNISTをそのまま動かしています。 0-9の手書き数字を認識させるというやつですね。 手書き数字を識別するために訓練されたモデルに 何の関係もない画像を無慈悲に流し込むという鬼畜のごとき所業です。 CNNの無駄遣い。 しかも、 MNISTの入力に合わせるため、 入力画像は問答無用に28 x 28のグレースケールにリサイズします。

要するに、 学習すべきいけてるデータを持たないので、 思い余ってMNISTをそのままAPIにしてみました。 サービスのURLは以下です。

Ipponshimeji Cognitive Services - Digit API

【2017年1月17日追記】 このサービスの稼働は年末で終了させました。

モデルの学習は、 Microsoft Cognitive Toolkit (CNTK)を使っています。 以下のサンプルの03_OneConvDropout.cntkをほぼそのまま実行しています。

CNTK/Examples/Image/GettingStarted/ (GitHub)

ただし、最後の出力だけ変えています。 目的がクラス分けではないので、各ノードの値をSoftmaxを通して「確率」が出力となるようにしています。 この変更も含め、 サービスのソースもGitHubに置いています

CNTKの評価ライブラリの利用については、 はまったところもあるので、 覚えていればまたブログに書きたい。

注意事項など

このサービスはアドベントカレンダーの期間中くらいは動かすつもりです。 Azure Web AppsのB1インスタンス1個(1コア)で弱々と動かしています。 スケールさせるような余裕はありません。 まあ、そんなことはないと思いますが、アクセスする酔狂な人が大量にきたらパンクするかもしれない。

また、判定した画像は保存していません。 ローカルマシンのファイルをアップロードして判定させた場合でも、 そのファイルは保存しません。 メモリ上だけで処理しています。 ただ、「全体でリクエストがいくつあったか」「判定結果」だけはログを取ります。 どの数字に似た画像が多いのかはちょっと興味あるし。

あと、再度念押しですが、このサービスは個人的に勉強がてら作って試しているものです。

おわりに

このサービスの実用性はまったく無いんですけど、 せっかく作ったので、 「誰の顔が一番数字の4に近いか」勝負とか、 忘年会の余興にでもご活用ください。

何人かの写真をぱしゃぱしゃ撮って、 スコアを出して順位をつけるスマホアプリとか作ってくれてもええんやで。

«子供に持たせるスマホとしてWindows 10 Mobileは結構いいですよという話