Windows Copilotを縦タスクバーでもなんとか使えるようにする方法

Windows 11で、さらにWindows 10でも、Copilotが使えるようになりました。

ただとても不思議なことに、タスクバーを左または右に縦型に置いている場合には使えなくなってしまいます。
縦タスクバーの場合は、Win+C のショートカットキーもなぜか使えなくなってしまいます。
一般的なディスプレイは横長なので、わたしは、高さを少しでも節約したくて、いつもタスクバーは縦にして使っています。

そこで、縦タスクバーでも、なんとかWindows Copilotを使えるようにできないか考えてみました。

タスクバーを横に戻してWindows Copilotを起動した状態で、タスクマネージャで調べると、次のコマンドが実行されていることが分かります。

"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" "--single-argument microsoft-edge:///?ux=copilot&tcp=1&source=taskbar"

これをそのままショートカットに設定したら、うまくCopilotを開いたり閉じたりすることができました。
またこれをさらに、短縮化して、

microsoft-edge:///?ux=copilot&tcp=1&source=taskbar

をショートカットに設定しても、Copilotの開いたり閉じたりすることができました。

このショートカットをタスクバーやスタートメニューにピン止めすればとても使いやすくなります。
ショートカットのアイコンイメージは、ネットから適当に検索して設定してやれば、本来の横タスクバーのCopilotアイコンと同じ動きと見た目を実現することができます。

また、参考までに、他の実行方法としては、コマンドプロンプトまたはPowerShellで、コマンドとして

start microsoft-edge:///"?ux=copilot&tcp=1&source=taskbar"

(ダブルクォーテーションで & を含む部分を囲む必要あり)を実行してもOKです。 

Windows Copilotは、人が結果を読むのと同じスピード感で、速すぎず遅すぎずの速度で結果を出してくれるようになっているので、なかなか気が利いていると思います。
Copoilotの画面を出した後、閉じると、ディスプレイの右側がCopilotウィンドウの幅だけ空いたままの状態で元に戻してくれないのは、まだ粗削りなところだと思います。

Windows 11開発者向けイベントがまた突然の告知（今度は急すぎて後で見ることに）

新しい書き込みをするほどでもないか（以前の書き込み）、とも思ったのですが、一点だけメモしておきたい情報があるので、投稿します。

Windows 11の一般向け発表イベントに追加して、わずか4時間後に、開発者向けのWindows 11イベントがありました。
ビデオは、YouTube上の
Join us to see what’s next for developers（約1時間）と、
Blog記事が、
What Windows 11 Means for Developers - Windows Developer Blog (2021-06-24) です。

これもなぜ事前に告知してくれなかった・できなかったのでしょうか（急に言われても、見たくても見れないこともありますよね、私も後で見ます）。
発表イベントの中の後半で突然これが告知されました（リンクも一般的なMicrosoft Learn TVのもので、直リンクが準備できなかったのかと勘ぐってしまいます）。

発表イベントも開発者向けイベントも突然の告知の割には、結局は答え合わせの内容になってしまいました。
また、内容以前に、ストリーミングが安定して繋がりませんでした（やり遂げるためのクォリティが十分ではないと言われても仕方ないと思います、逆説的にそれだけWindowsへの人々の興味が高いという説明では納得できないですよね）。
私は即座にラッキーなことにcnetがYouTubeでミラーしているライブ配信（Microsoft Windows 11 Reveal Event (Crashing / Broken Version) - Original Livestream：更新されたタイトルが泣けます）を発見できたので、そこから視聴しましたが、そこでさえ、時々いわゆる「ピー」状態に（Microsoftからcnetへの送信でさえ不安定）なっていました。

内容的にはWindowsが欠かせないものであることを感情に訴える場面もある、そういう点では分かりやすい内容だったと思います。
しかしながら、いかにも作り込まれたビデオであり、ライブイベント感は全く感じられませんでした（舞台上から居間への瞬間移動効果が、ブラタモリの函館方式の背景画像切り替えで、人物移動をAR的に制御している、というのなら実際にライブなのでしょうが、どう見ても別々のスタジオで収録したビデを編集してつなぎ合わせたようにしか見えませんでした）。
これなら深夜の放送時刻に見る必然性は全くなくて、完成ビデオをBlogやメールで送ってくれれば（早送りとか繰り返しとでじっくり見られて）良いのにと思いました。

Androidアプリ、Amazon Fireアプリが動きます、のところだけはサプライズ（PanosがOne More Thingと言っていましたね、全体的にオマージュを狙っていると言うか。。。）でした。
そこまでできるのなら、

• Raspberry PiをWindows 11がGUIを含めてサポートします、とか
• Apple Silicon Mac用Windows 11を出します、とか

まで、すそ野を広げて、頑張ってほしかったです。
AMDやArmには触れられませんでした（Intelに忖度か？）。
11は単なる改善版ではなくて、Windows 10を後方互換のために継続し、それとは別の全く新しいコンパクトなOSを出す、でもよかったのでは、と思います（この点は冷静に分析して、後方互換が必要不可欠と判断したのでしょう、Windows Updateをなんとか高速化するので実現したら許してねという仕切りでしょうか）。

結局Windows 10 22H1レベルのもの、もともとはWindows 10の定期アップデートで提供してほしかったような内容を、わざわざWindows 11と名前を変えて、従来のシュリンクラップ（MS Officeも2022を出す）と同じ発想の中で出してきただけですね、という少し残念な結果となってしまいました。
革新にはもう少し時間が必要なのかもしれません（Windowsが現在の生活の中で不可欠な面はお認めしますが）。

[2021-06-26] 新しいユーザインターフェースが特徴と言われていますが、従来のアプリ、たとえばメモ帳（Notepad）やMSOffice、APIとしては古いWin32/WinRTと現行のUWPに頑張って追いついてきたアプリが、そのまま「新しいユーザインターフェース」で表示されるのなら、ものすごく良いのですが、そうはならなさそうです。
現在のWindows 10でもUWPアプリと、Win32アプリ、それと独自UIのMSOfficeでは全然見た目や操作性（タイトルバーの色が付いたりつかなかったり透明だったりや、クローズボタンのサイズがバラバラなどなど）が統一されていなくて、寄せ集めのＯＳを日々使わされている感覚でガッカリと言うかイライラします。
Linuxでもウィンドウマネージャを入れ替えたらウィンドウを操作する基本のタイトルバーは統一されるのに、Windowsではあえてバラバラにできるのが不思議なくらいです。
Windows 11では新しいユーザインターフェースをWinUI3で提供と言っているので、これを使うようにアプリを書き換える必要があります。
またユーザインターフェース系統のバリエーションが増えてしまって、画面がますます混沌とするだけですね。

[2021-07-07] みなさ～ん、デフォルトのたった1枚のデスクトップピクチャ（壁紙）のカッコ良いイメージだけに惑わされちゃだめですよ。

単なる答え合わせの会になってほしくないWhat's next for Windowsイベント、ところでなぜBuildと別枠で発表することにしたのでしょうね、期待が膨らみますね

「窓から見える外の世界、未来へ飛び出そう」、私にはそんな風に見えました。

近頃の発表イベントは事前リークと言うか漏洩が多くて、答え合わせのようにしかならなくて、ライブで見ていてとても残念な思いばかりです。
来週の「Join us to see what's next for Windows」にはそうはなってほしくないものです。

とは言え、私からも予想をひとつ（やはり予想する誘惑にはあらがい難いですね）。
Chrome OSのような、Edge OSの予感がします。
もしそうなればEdgeは先見の明のあるネーミングというか、最初からそう見据えられていたのかもしれません。
MSOfficeもすでにスマホOS版もあるし、クラウド版もキッチリ動くようになっています。
WindowsもPCのOSとしての形に固執することが無くなっていると思います。

ところでなぜ直前のBuildイベントで一緒に発表しなかった、あるいはできなかったのでしょう。
わざわざ独立したイベントになっているからには大きな話題（大きな変化？）を期待してしまいます。
Buildの元々の内容へのしわ寄せを気にしたのでしょうか（そんなことはなくて、どちらも周到に準備してるはず）。
Satyaの会長就任後の初仕事として、華を持たせたかったのでしょうか。

ほとんどの人が、家に金庫や水道のタンクを持ったりしない（でも持とうと思えば持つことは何ら難しくない、持とうと思えば自由に持てる）という、人の世のインフラ機能。
人とコンピュータの関係性も、そういう感じに確実にシフトしてきています。
金庫製造者は金融業者に、コンピュータ製造者はクラウドサービス提供者に仕事を取られる、という側面はあるにせよ、この流れが一度始まってしまうと、だれにも止められません。
人が同じことをするのに、全く違う業界の提供物・提供サービスを使うようになる、そういう流れの中でWindowsもワクワクする進化を見せて欲しいと思いました（MicrosoftもPCパッケージソフトウェアと周辺機器・PCから、サーバアプリへ、そしてクラウドサービスへ業態を広げてきました）。

発表されるのがWindows 11だとしても、それはいくつか発表されるもののうちのひとつであってほしいものです。

[2021-06-25] 発表イベント後の所感を投稿しました。

Linuxのsudoの脆弱性CVE-2021-3156への対応方法 - Windows 10 WSLの場合

Linuxコマンドで特権操作を行う場合によく使うsudoコマンドに脆弱性CVE-2021-3156が発見されました。
ITmediaの記事（sudoにパスワード不要で特権昇格が可能な脆弱性が見つかる 2021-01-28）と、JPCERTの記事（sudoの脆弱性（CVE-2021-3156）に関する注意喚起）に、情報が公開されています。

ほぼすべてのLinux系/UNIX系OSに影響があると思います。
macOSに関してはまだ情報が出ていないですが注意が必要と思います（macOSにはsudoeditコマンドがないので直接の影響が少ない可能性があります）。

JPCERTによると

% sudoedit -s /

のコマンドで簡易的に影響を調べることができるようです。
sudoedit: から始まるメッセージが表示されると問題があり、
usage: のメッセージが表示されると問題は対策済みです。

わたしも早速、自分のPCに対策をインストールしました。
Windows 10のWSL1 Ubuntuの場合の手順です（おそらくWSL2でも同じ）。

WSLを起動して
$ sudoedit -s /                    ##状態の確認
[sudo] password for xxxx:
sudoedit: /: not a regular file    ##問題があることが分かります
$
$ sudo apt-get install sudo        ##インストール済みのsudoのバージョンを確認
Reading package lists... Done
Building dependency tree
Reading state information... Done
sudo is already the newest version (1.8.21p2-3ubuntu1.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$    ##WSL Ubuntu 18.04での対策済バージョンは1.8.21p2-3ubuntu1.4なので古いことが分かります
$    ##以下、対策のインストール方法
$
$ sudo apt-get update              ##レポジトリ情報の最新化
$ sudo apt-get upgrade sudo        ##sudoのバージョンアップ
$
$ sudoedit -s /                    ##対策結果の確認        
usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...
$                                  ##OK
$

まだ実際の攻撃は検知されていないようですが、早めの対策が必須です。

[2021-02-02] 問題はsudoeditに限定されるようです（参考記事：GIGAZINE - 「sudo」コマンドに特権昇格の脆弱性、各ディストリビューションの対応一覧）。

Windows 10 2004/20H2の新しいIMEはあきらめて古いIMEに戻しました

Windows 10は順調に改善を続けているかと思いきや、たまに前のバージョンに戻したくなるような明らかな改悪が紛れ込んでくることがあります。

先日、PCをWindows10 1909から20H2にアップデートしました。
IMEが新しくなり、スマホに近い予測変換が使いやすいと最初は気に入って使っていました。
でもどうしても目に付く問題があり、古いIMEに戻しました。

今回のIMEが早熟だったことはMicrosoft自身も明らかに認めているようで、設定画面に「以前のバージョンのMicrosoft IMEを使う」の項目が堂々と存在しますし、KB4564002（URLがyou-might-have-issuesですよ）でも未解決の問題が残っていることを認めています。
正式バージョンのハズなのに、ちょっと不思議な状況ですね。

わたしが新しいIMEを使っていてどうしても許容できなかったふるまいは以下です。

• 「CPU」のようにすべて大文字のアルファベットを入力するときは、
  Shift-C、Shift-P、Sift-U と入力して、
  Shiftを離すのが遅れて（あるいは離すのを省略して）Shift-Returnと入力することがよくあります。
  従来のIMEではShift-Returnでも副作用なく確定動作をしていたはずです。
  
• 新しいIMEでは、確定動作に加えて余分な改行文字が入力され、さらに悪いことに入力モードが英数に切り替わってしまいます。
• その上、アプリによって微妙に動作が違い、
  Wordの場合、Shift-Returnつまり強制改行が入力されます。
  TeraPadの場合には、入力位置に改行が入力され、入力した文字は次の行に送られます。
  メモ帳の場合には、これも入力文字の前に改行が挿入され、入力モードが英数に替わり、通常のモード切替ではかなに戻せなくて、Alt-Shift 2回で一度IME無しにしてから日本語IMEに切替えた後でないとかな入力モードに出来なくなります。

勝手に変換モードが変わってしまったり、余分な改行が入力されてしまうは、入力効率に大きく影響します。

以前のIMEのように、詳細なキーカスタマイズができるのなら、まだ回避する手段もあったと思いますが、それも今回は無くなっています。
そのうえ、変換キーの置き換えも、以前はremapkeyなどでレジストリ定義だけで出来ていた（私はF13を変換キーに定義して、CapsLockと右AltをF13にしていました、ちなみにUSキーボードの場合です）のですが、新しいIMEではPoｗerToysを常駐させないといけなくなっています。

もう少し、パワーユーザの意見を聞くなど、事前に対策を立てられなかったのでしょうかね、と思います。

 

[2025-10-17] Windows 11に移行した現在は気持ち悪さは解消しているので新しいIMEを使っています。

macOSの方と言えば、スペース入力を半角スペースにどうしても固定できないので、Google日本語入力に頼ってしまっています。

Windows 10でメモ帳（Notepad）のデフォルト漢字コードがUTF-8になって、全文検索されない問題への解決策 - htmlインデクサを使用

WindowsのテキストファイルもようやくShift-JISからUTF-8に移行してきました。
Windows 10 1903から、メモ帳（Notepad.exe）のデフォルト漢字コードがUTF-8になりました（それも従来のWindowsのBOM付きではなくて、LinuxやmacOSと同じBOMなしのUTF-8）。
これはとてもとても良いことだと思います。

しかしながら非常に残念なことに、Microsoftさんの片手落ちで、デスクトップ検索（全文検索）からUTF-8のテキストファイルが検索で引っかからなくなってしまっているのです。
Shift-JISやUTF-8N（BOM付き、従来のWindowsのUTF-8）のファイルは問題ないのに、メモ帳の現在のデフォルトのUTF-8ファイルがダメなのです。

最悪、自分でIFilterを書こうかとまで思ったのですが（nkfみたいに自動文字コード識別）、いい方法を思いつきました。

従来からHTMLファイルは文字コードの自動判別機能を持っていて、当然Shift-JISにもUTF-8にも対応しています。
テキストファイル用のデフォルトのIFilterを使わずに、HTMLファイル用のIFilterに差し替えればと思い、やってみたところ、すこぶる良好です。
（エンジニア用のメモ：Windows Platform SDKのfiltdumpでも検証しましたが、HTMLなので改行コードが無視されるという違いはありますが、キッチリ漢字文字を認識できるようになります。）

設定にはRegeditを使います。
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.txt\PersistentHandler の内容を HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.html\PersistentHandler の内容で置き換えればよいです。

つまり手順としては、次の内容をコピペし、 classes-txt-handler.reg というファイルに「UTF-16 LE (BOM付き)」で保存して（図のひとつめのアイコンになること）、ダブルクリックしてください。

（.reg ファイルに保存したときに、メモ帳のアイコンではなくて、レジストリのアイコンになることが肝要です。拡張子を表示していないと classes-txt-handler.reg.txt というファイルになる間違いが起こりがちですので要注意です。）

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.txt\PersistentHandler]
@="{eec97550-47a9-11cf-b952-00aa0051fe20}"
"既定.save"="{5e941d80-bf96-11cd-b579-08002b30bfeb}"
"既定.html"="{eec97550-47a9-11cf-b952-00aa0051fe20}"

設定を反映するには、もう一つおまじないが必要です。
スタートメニューを開いた状態で index と入力して出てくる [インデックスのオプション] を起動して、「xxx個のインデクスが作成されました」のところのファイル数をまずはメモしておいてください。
[詳細設定] ボタンを押し、[再構築] を押して、検索インデックスを作り直してください。
[インデックスのオプション] の画面に進捗状況が表示されます（私の場合は完了までに24時間くらいかかりました）。

上記regファイルには、オリジナルの設定値を「規定.save」のところに書き込んでありますので、元に戻したくなった時（将来、標準でUTF-8がサポートされた暁に）はその値を「@」のところにコピーしすればよいです。

あと、Windows 7の頃は検索ツールで、PC上のファイルもOutlookのメールもまとめて検索出来ていたのですが、（古い話ですが）Windows 8＋Outlook 2013以降はそういうことができる画面がなくなってしまいました。
ファイルの検索はスタートメニューかWindows Explorerで、メールの検索はOutlookで、と分断されてしまっていました。
しかしながら、Windows OSの検索インデックスDBはどちらの内容も取り込んでいるので、何とかできないかというのは当然の思い（Windows 7を知らない世代はそういうものと思っているかもしれませんが）でして、じつは何とかする方法があります。

次の内容をコピペして indexed-Locations.search-ms というファイルに保存してください（ここでも拡張子に注意、図の2つめのアイコンになること）。

<?xml version="1.0"?>
<persistedQuery version="1.0">
  <query>
    <kindList>
      <kind name="item" />
    </kindList>
    <scope knownScopeID="{f60163ce-2b8d-458d-ab2c-40f215767514}" />
  </query>
</persistedQuery>

この水色アイコンをダブルクリックするとWindows Explorerの窓が開きます。
検索ボックスにキーワードを入力してReturnを押すと、全ファイル・全メールからの全文検索ができるようになります。
このファイルを [スタートメニューにピン止め] しておけばすぐに呼び出せてとても便利です。
（Windows 7のことを覚えているひと向け：当時は検索結果のメールアイテムをダブルクリックすると開けたのですが、今はもうダブルクリックできなくなりました。残念ながらOutlookの中で再度 [すべてのメールボックス] で検索して開く必要があります。）


全文検索のデスクトップ検索については、最初はWindowsが先行し、途中Google Desktop Searchの時代があり（PCのファイルの内容までもがGoogleの検索エンジンに持っていかれるので私は到底使えませんでした）、今ではmacOSの方がキッチリ動いています。
今回紹介した設定で多少なりともWindows Desktop Search（WDS）が使い物になれば良いな、と願います。

[2024-03-19] regファイルはUCS-2またはUTF-15 LE BOM付きにしないと漢字データが文字化けするので追記しました。

Windows 10 2004 Fluent Designアイコンはマットなしでやっと活きる

Windows 10の新しいアイコンデザインに関連して、少し古めのこんな記事がありました。

• A new look for Windows 10 Start menu: Live Tiles ditched in leaked preview build | ZDNet 2019-07-25（上の図）

現状のWindows 10では、特にタブレットモードの時にライブタイルを表示するためのマット（座布団）を、ライブタイルではない通常のアプリアイコンの周りに必ず表示しています。
ライブタイルがあまり人気がないようなので、マットも廃止する方向の可能性があるとのことです。
特にSurface Neo用のWindows 10Xでは確実にそうなりそうです。

• デュアルスクリーンAndroid：Surface Duo SDKの仕組み| ITIGIC 2020-02-27（下の図、一緒にSurface Duoのホーム画面メニューも）

アイコンにはそれ自体の形があるので、本来はマットは不要なはずで、現状のWindows 10の表示方式が実は不思議な方式だったのかもしれません。
クリックエリアを確実に広げる意味はあったのかもしれませんが。

Windows 10 2004 Fluent Designアイコンの実際の見た目は、すべて水色の豆粒で区別しずらい

当初Fast Ring向けといわれていたFluent Designの新デザインのアイコンですが、Windows 10 1909でも徐々に展開されてきています。

前回のポストではアイコンだけを抜き出した見た目の比較でした。
その状態では、

• 現在のアイコン：モノクロでべったりしていて少し格好悪い
• 新アイコン：よくデザインされていてわかりやすそう

という印象が確かにありました。

しかし、右のキャプチャのように、実際の画面に表示される場面で見てみると、必ずしも先ほどの印象通りではない事に気づきます。
カレンダーアイコンは、確かに単体としては頑張ってデザインされていると感じましたが、実際の画面の中では、何か周りにうずもれてしまってせっかくのディテールが全く生きていないように感じます。
個々のアイコンがモノトーンなのが災いしているようです。
最近のFull HDや4Kの高解像度モニターでは、モノトーンで描いたディテールは視認できなくて、アイコン全体が単なる色合いの豆粒にしか見えないようです。
その上、多くのアプリアイコンが水色系なので、余計に区別がつきにくいです。

• 現在のアイコン： 個々のアプリアイコンが図案としてはっきり区別しやすい
• 新アイコン：実際の画面上ではぼんやりしてしまい区別しずらい、特に標準アプリはすべて水色なのでモノトーンで図案がはっきりしない新アイコンではすべてが水色の豆粒のように見える

これなら、旧アイコンのように白の単色の図形での表現の方が視認性が高いと言わざるを得ないです。
右のキャプチャでも上のカレンダーアイコンよりも、下のクイックアクションのアイコンの方がはっきり区別しやすいですね。
皆さんはどう感じるでしょうか。

Windows 10 2004のFluent Designアイコンと従来のMetroアイコンを比べてみる

Microsoft Designのブログ(副題Introducing the new Windows 10 icons in Fluent Design 2020-02-21)で発表されたように、Windows 10 Version 2004 (20H1)では、アイコンデザインが新しくなります。
ブログには新アイコンが掲載されているのですが、対応する旧アイコン（現状のアイコン）がありません。
どうしても比較したくて、対比イメージを作りました。

[English version of this post]

Windows 10 1803とOutolookの相性で文字化けする問題がようやく解決か KB4340917 17134.191

Windows 10の春秋の定期バージョンは、新機能は少なめだけれども昔に比べれば安定してきていたので、わたしはリリースされるとすぐに適用するようにしていました。

ところが、Windows 10 version 1803 (April 2018 Update / Redstone 4 / RS4)に限って言えば、致命的な問題のために他の人には到底勧められない状態でした。

先日、ようやくこの問題に対する修正パッチがリリースされました。
おおよそ3ヶ月かかりました。

ご参考のため、どんな問題なのかを説明しておきます。
Outlookで日本語を入力中に、文字列が勝手に確定してしまい、さらにその文字列が重複して入力されて、入力が完全に崩れてしまうのです。
再変換（マウス右クリックや、アプリキー）すれば入力が無駄にならない部分もありますが、重複して入力されるタイミングがランダムなため、崩れ具合がまちまちで、多くの場合は全部入力しなおしになってしまいます。
非常にゆっくりと入力すれば起こりにくくなったりすることもあり、動作が一貫しません。
予測入力の開始文字数を長くしたり（デフォルト3文字を5文字など）、予測入力自体をOFFにしても完全には改善しません。

日常的に一番よく使うかもしれないアプリであるOutlookでこの有様。
それも、常に問題が出続けるのであれば、完全に使い物にならないのでバージョンを元に戻すのですが、Outlookを再起動したりすると出なくなったりするのが厄介者。
問題が激しくなったにはメモ帳やWordで入力してコピペとかで、ぐっと我慢して使っていました。

Microsoftは早い段階でこの問題（不具合）を公開していました。

•  Windows 10 April 2018 Update (バージョン 1803) を適用後、Outlook での文字入力に問題が発生する – Outlook Support Team Blog JAPAN 2018-05-23
  https://blogs.technet.microsoft.com/outlooksupportjp/2018/05/23/windows-10-april-2018/

ところが、待てど暮らせど一向に修正されず、3ヶ月経ってようやく修正プログラムが公開されました。

• 対処方法 (2018/7/25 update) Windows 10 の修正プログラム KB4340917 (OS Build 17134.191)  を適用することで、本現象が回避いたします。
  https://support.microsoft.com/ja-jp/help/4340917
  Windows 10 2018-07累積更新プログラムその2 KB4340917 - Microsoft Outlook などのアプリケーションで、日本語入力中に文字列が意図せず確定される IME の問題を修正します。 2018-07-27

早速、今日適用し、様子見を開始しました。
パッチは、問題が修正されたり、新しい機能が提供されたりするうれしい面もありますが、新たな問題を引き起こす可能性もあります。
そういえば、Windows 10 1803はリリース直前に問題が見つかり、何度かリリースが延期されたりしていましたね。
もしも追加の情報が見つかったらここでお知らせしたいと思います。

[2018-08-10] パッチを適用して一週間経ちました。その間、文字化けの現象は起こっていません。

Windows 10へのアップグレード、MSI WindPad 110W

多分に漏れず、私もギリギリになってしまいました。
Windows 7/8タブレットの研究用に4年前に手に入れていたMSI WindPad 110Wで普通に動きました。

順序として、アップグレード作業なので、最初にWindows 7 Home Premiumを入れ直してから、右のページのアップグレードツールを実行してアップグレードしました。
これは、細切れになっていたパーティションをきれいにしたい意図もありました。
7のクリーンインストールで組み込みのWi-Fiドライバがなくて通信できないので、BuffaloのUSB Wi-Fiを接続して急をしのぐハプニングもありました。

実は、Windows 10のバージョン1511（2015年11月版、いわゆるTH2、Threshold 2）からは、アップグレードしなくても、Windows 10のクリーンインストールでWindows 7/8のプロダクトキーをそのまま使えるようになっているのを知ったのは、後の祭りでした。
これは、後で別環境で試してみたら、その通りでしたので、今後同様のセットアップをする方は、Windows 10のクリーンインストールが良いと思います。
もちろん、これは7月29日(金)までの期間限定の機能なので、それ以降はプロダクトキーの入力はできるけれども、ライセンス認証で失敗するという動きになると予想されます。

さて、Windows 10の使い勝手は、Windows GUIでそのままタッチパネルに対応した7や、消化不良の8、などに比べて、さすがにやっとまともになってきたと感じました。
タブレットモードに切り替えると、アプリがフル画面になって、よりタブレットの雰囲気になります。
仮想ゲストでは何度もWindows 10は触っていたのですが、タブレットの実機ではやはり感覚が違います。

Windows Updateが動いている（勝手に動きます）間は、使い物になりませんが、それ以外は、かなりスムーズに動きます。
ピンチアウト・ピンチインによる拡大縮小操作も使えます（なぜかEdgeブラウザだけはできません、IE 11、Firefox、SRWare Iron(Chromeのプライバシー強化版)ではちゃんと使えるのに）。
1280x800のディスプレイでもスプリットビューが使えます。
Windows 10ではデフォルトでは隠されている、休止状態（Hibernate） は pwercfg -h on コマンドで設定できました（Windows TenForumsの参照記事）。
画面の自動回転は、SKUSoftさんのwpdgpotツールで出来るようになりました（参照記事）、回転時に画面が消えて書き換わるのは変わりませんが。

現時点ではローカルアカウントしか設定していないので、Insider Previewビルドへの更新はできませんが、おいおい設定して、いち早く最新版に更新できるようにしたいと思います（Cortanaを試すのにもMicrosoftアカウントが必要です）。
Windows 10はOS as a Serviceですからね。