« 2017年5月 | トップページ | 2017年10月 »

2017年8月

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月 | トップページ | 2017年10月 »