Microsoftの新しいOutlook、Classic版なら即時にできる操作に10秒もかかる

 (windowslatest.com)
1 ポイント 投稿者 GN⁺ 7 시간 전 | 1件のコメント | WhatsAppで共有
  • Windows 11の新しいOutlookでは、メール通知をクリックしてもそのメールにすぐ移動できず、Outlook Classicなら即時に処理できる流れで約10秒の遅延が発生する
  • 遅延の核心はWebView2ベースの構造にあり、通知クリック後にアプリ起動、受信トレイの読み込み、認証、メールスレッドの表示、レンダリングの過程を経る必要がある
  • リソース使用量の差も大きく、新しいOutlookはアイドル状態でも10個のプロセスと490〜636MBのRAMを使う一方、Outlook Classicは単一プロセスで117〜148MB RAM程度にとどまる
  • Microsoftは機能強化を続け、企業向けの強制移行期限も2027年3月まで延期したが、通知の遅延は機能不足というよりWebアプリ構造の制約に近い
  • 通知からすぐメールを開く必要がある業務フローなら、現時点ではOutlook Classicのほうが安定した選択肢であり、Classic Outlookは2029年4月までサポートされる

Windows 11の通知で明らかになった新しいOutlookの遅延

  • Windows 11には2種類のOutlookが共存している
    • Outlook Classic: 従来のWin32デスクトップアプリで、パワーユーザーに多く使われているバージョン
    • 新しいOutlook: MicrosoftがWindowsメールの将来として推進しているWebView2ベースのアプリ
  • 新しいメールが届くと、Windows 11の右下に通知バナーが表示され、バナーや通知センターの項目をクリックするとそのメールへ直接移動できるはずである
  • Outlook Classicは通知をクリックすると、そのメールをほぼ即座に開く
  • 新しいOutlookはアプリを開いて受信トレイ全体を読み込んだ後、通知が指していた特定のメールが画面に表示されるまで約10秒かかる
  • スタートメニューから新しいOutlookを直接開き、新着メールを探してクリックすれば約5秒で済むため、通知経由の直接移動より手動操作のほうが速い

WebView2構造が生む処理経路

  • 新しいOutlookはMicrosoft EdgeのWebView2ランタイム上で動作し、Chromiumベースのレンダリングエンジンを使っている
  • 通知クリックのような単純な操作でも、ブラウザに近い流れを通過する
    • Webレイヤーの初期化または再開
    • 認証
    • 関連メールスレッドの読み込み
    • Webエンジンによるレンダリング
  • MicrosoftはWebView2アプリの性能問題を診断するためのDelayed Message Timing APIをテストしたが、Outlookの通知クリック過程でこのAPIの利用は確認されていない
  • タスクマネージャー基準では、新しいOutlookは10個の個別プロセスとして実行される
    • WebView2 Manager
    • 複数のWebView2 Utilityプロセス
    • WebView2 GPU Process
    • WebView2 Service Worker など
  • 同じ作業において、Outlook Classicは単一のより小さなプロセスで動作する

メモリとCPU使用量の差

  • 新しいOutlookはアイドル状態で490MB〜636MB RAMを使用する
    • セッションごとの数値はメールボックスの大きさによって変わる
  • Outlook Classicは同条件で約117MB〜148MB RAMを使用する
  • メモリ使用量だけを見ると、新しいOutlookはOutlook Classicの約4倍に達する
  • CPU使用率にも差がある
    • 新しいOutlook: アイドル状態で約4%
    • Outlook Classic: アイドル状態で1%未満
  • これらの数値は、両アプリを同時に開いた状態でタスクマネージャーにより測定した値である

Microsoftの移行推進とアップデート

  • Microsoftは従来のUWP Mail and Calendarアプリを新しいOutlookへ置き換える方針を強く進めており、2024年末にMail and Calendarアプリは正式終了した
  • 企業向けの移行も進行中だが、強制オプトアウト期限は当初の2026年4月から2027年3月へ延期された
  • 新しいOutlookはリリース以降、いくつかの機能差を縮めてきた
  • 2026年7月予定の.PSTインポートアップデートでは、ローカルアーカイブファイルのカレンダー項目と連絡先を取り込めるようになる
  • Microsoftは2026年6月初旬、新しいOutlookへの移行理由として15の生産性機能を示しており、オフラインアクセス、Copilot統合、高速検索、改善されたカレンダー制御が含まれている

現在の選択肢と残る制約

  • 新しいOutlookはスタートメニューから素早く開ける点や複数の機能で改善が見られるものの、通知処理の体験はまだOutlook Classicの水準に達していない
  • 通知クリック後にすぐメールを開く流れでは、WebView2アーキテクチャが生む追加ステップが体感的な遅延につながる
  • MicrosoftはWindowsネイティブアプリ向けにWinUIへさらに注力しており、ネイティブ版Outlookの可能性にも言及している
  • Windows 11の通知センターにWindows 10に近いカレンダーのagenda viewを戻す機能も予定されており、この機能もWebView2ベースになる見込みである
  • 迅速な通知処理が業務フローで重要なら、Outlook Classicのほうが信頼できる選択肢であり、Classic Outlookは2029年4月までサポートされる

関連記事

1件のコメント

 
GN⁺ 7 시간 전
Hacker Newsの意見

  • 2019年まで約20年間、WindowsをメインのOSとして使い、LinuxサーバーにはSSHでよく入っていたが、デスクトップとして住み着く場所ではないと感じていた。
    2019年にPCを新調した際、Linux環境に慣れようとUbuntuデスクトップとWindowsのデュアルブートを構成したが、ドライバや周辺機器の設定で苦労するだろうという予想に反して、数日間いくつか設定を検索するだけで済み、残りはうまく動いた。
    数週間後、Windowsパーティションに戻る用事が一度もなかったことに気づき、1か月後にはWindowsのSSDをフォーマットしてLinuxのストレージとして追加した。
    Linuxへの移行が面倒そうでためらっていたなら、選択肢があるうちに一度試してみる価値はある。少なくとも2019年の時点で十分に洗練されていたし、New Outlookの件のように、Microsoftは大多数のユーザーが離れられないと見て、ユーザー体験を改善する動機が薄れているように思える

    • もう20年たったのかと気づいた。2006年ごろ、Windows Vistaは避けられないと見てLinuxへ移った記憶がかすかにある。
      あれこれいじることには興味がなく、仕事と余暇に使える実用的なコンピューターが必要なだけだ。Linuxも完璧ではないが、WindowsやmacOSを使わざるを得ないときに投げつけられる雑多なものの量は、ほとんど滑稽なくらいだ
    • 「少なくとも2019年からは洗練されていた」という言い方は、2019年の時点でもLinux側ですでに言われていた。いつも「ここ数年でかなり良くなった」という調子だが、その言い方が間違っているという意味ではない。
      今ではLinuxデスクトップがどれほど改善されたかより、Microsoftがどれほど台無しにしたかが市場シェアを左右していると思う
    • 同意する。レガシーソフトウェアのためにWindowsが必要なときもあるが、99%のユースケースではLinuxはよく動き、より高速で、プライバシーもより尊重してくれる
    • ほぼ同じ経験だ。4年目になるがUbuntuを満足して使っている。たまに些細な問題はあるが、軽く検索するかAIで解決できるし、ここにいる私たちはどうせハッカーでもある
    • こういう成功談でいちばん気に入っている点は、NautilusがWindowsで昔からできていた機能、たとえばRDPセッションを3段またいでテキストとファイルをコピー＆ペーストすることすら真似できないことだ。
      たまにGoogle Docsを開いたりSSHターミナルを使ったりする程度の人は問題を感じないだろうが、毎日本当に仕事をしている立場では問題になる

  • OutlookはWebView2ベースだから、あらゆるWebアプリのように遅いのだ、という話をする人がいるが、FastmailもWebベースのメールクライアントを提供していて、Outlook Classicと同じくらいかそれ以上に速い。
    New Outlookが単純にひどい。読み込み順序がおかしく、すべてのウィンドウですべてをレンダリングし、不要なデータまで読み込むのでいら立つ

    • New Outlookを実際のWebブラウザで outlook.office.com として実行すると、重いデスクトップクライアントよりはるかに速い。
      おまけにLinuxでもちゃんと動く。昔のOutlookに比べて欠けている機能が多少あるのは理解できるが、基本的な会社メールの処理には十分合っている。
      これでもう職場でWindowsを使う理由は0になったので、今回ばかりはMicrosoftがよくやったと心から応援したくなる
    • Fastmailクライアントは起動してしまえば良いが、よくできたネイティブアプリほどではない。
      初回起動はずっと遅いし、iOS/iPadOSアプリも同じWebアプリだったと記憶しているが、バグがかなり多くて、WebViewが固まったり、閉じて開き直すまで読み込みアニメーションから先に進まないことがある
    • どういうわけか、学んだはずの教訓を失ってしまったようだ。以前は、全体を表示するのに時間がかかると分かっていれば、レンダリングされたものから可能な部分を先に見せていた。
      たとえば長いレポートなら、200ページ全部が終わるまで待つのではなく、各ページがレンダリングされるたびに表示できるようにしていた。速く感じられることは、実際に速いことと同じくらい重要なことが多かった
    • Gmailにはかつて低帯域・高性能なWebメールインターフェースがあり、実質的に初期UIだった。
      稲妻のように速く、メモリもほとんど使わず、メールもほぼ即座に開いた。続いていた間は素晴らしかった
    • Web技術を使うという決定と、性能や使いやすさを気にしないという決定は、理論上は別物だが、現実にはよく一緒に下される。
      スタイルのないテキストをボタン代わりに使うような結果にまでなる

  • 「旧式の」Outlookの起動画面にも理由はあった。SSDが普及する前は起動に時間がかかっていたからだ。
    昔のWindowsはHDDでも十分使えたし、SSDが登場すると何もかも即座に開いて衝撃的なほど速くなった。ところが今では、AHCIのレイテンシコストすらない20Gbps超のSSDがあっても、メール1通を開くには足りない。
    それだけ基準が底まで落ちたということだ

    • Windowsだけの問題ではなく、Microsoft全体の問題だ。
      Outlookで返信を押すと、返信ウィンドウが開く前に最初の文の半分を入力できてしまう。M4 Proでもそうだ。
      ほぼ毎回、Outlookがバックグラウンドで何かを終える前に入力した文の半分が消えてしまい、最初の文を書き直さなければならない。同じ端末のほかのメールクライアントではこんなことは起きない。
      8文字のキーボードバッファを使っていた1982年でもないのに、人間がコンピューターの入力処理より速くタイプできてしまうべきではない
    • なぜこんなエンシティフィケーションが起きるのか分からない。
      Outlookの予定イベントを複製しようとしたのだが、Teamsリンク付きの会議を不規則な新しい時刻に繰り返し必要としていて、定期予定にはできない状況だった。
      Outlookネイティブではそれができず、Teamsでイベントを複製するしかなかった。おそらくTeamsが新しい会議IDを必要とするからなのだろうが、なぜOutlookネイティブでそれができないのか理解できない。たぶんWebベースだからだろうが。
      ユーザーの必要ではなく、変化そのものと金のために変えるのは嘆かわしい
    • より簡単で高速なソフトウェア開発フレームワークによって、クソソフトウェアを出荷するコストが下がった。
      ソフトウェア品質をどう測るかは誰もよく分かっていないが、アジャイル開発はソフトウェアの産出量を測ることを非常に簡単にし、企業はそれを優先する。
      AIベースの開発で開発者の効率が上がっても実際の製品が良くならない理由もここにある。ただクソをより速く量産するために使われるだけだ

  • 新しい職場で Windows 11 を使い始めたが、業務用システムでは notepad.exe を開くのに 3〜4 秒かかる。最後のタブを閉じて開き直しても同じだ。
    しかも AI 文章作成用のアプリ内課金まで入っている

    • Windows 自体も非常に遅いが、その上に CrowdStrike のような 企業向けセキュリティツール や、遅くてバグの多い社内 DNS まで載ると、使いものにならないレベルになる。
      もう時間どおりに何かをするには WSL を使うしかない
    • 残念だ。ここに兄弟コメントが述べている企業向けセキュリティスタック、つまり EDR/XDR、アプリ制御、ファイアウォール、生産性監視ツールのようなものが問題をさらに悪化させる。
      次に、PC の大量購入時にデスクトップのユーザー体験を守る人はたいていおらず、その場その場の戦略は一番安いトイレットペーパーを選ぶようなものだ。
      CFO の分析で魅力的に見えた安価な PC に、もともと限られた性能の 50% を食い潰すセキュリティソフトまで載っている
    • Microsoft がなぜこうなるのか、最終目標を理解するのが難しい。会社全体がただの邪魔者のようになるまで、どれだけ雑に物を作れるかを見せられている気分だ
    • メモ帳を Notepad2e に置き換える人もいると読んだ。個人的にはテキストエディタとして vim を使っている。
      https://github.com/ProgerXP/Notepad2e
    • 多くの企業は何らかのツールでアプリ実行の 許可リスト を有効にしている。Microsoft も 1 つ提供しているようだし、CrowdStrike などもある。
      遅延はバックエンドアプリケーションや、ときにはウェブサーバー呼び出しまで介在するためである可能性が高い。これに加えて、ファイルを開くたびにリアルタイムスキャンまで入る

  • Microsoft の品質がどうしてここまで低いのか本当に気になる。技術的負債、締め切り、官僚主義のせいだろうか。
    この会社は ドッグフーディング という用語を生み、すべてのバグが潰れるまで Exchange を全社員に使わせていた会社だ。
    職場で次世代のウェブメールアプリを作っているが、ユーザー体験の境界ケースは多くても、コア UI の性能はロケット科学ではない。
    バグを減らし、最後の性能改善を行い、Outlook 対応を追加するためにプレイテストの協力を探している。
    https://housecat.com/
    このメールアプリは「変形可能」で、inbox zero に到達するためのカスタムワークフローや UI ウィジェットを作れる点が売りだ

    • 以前 Exchange だった組織で働いている。これは私見だ。
      品質問題に単一の原因はない。何十年にもわたる 数千の小さな判断と問題 が複合的に積み重なり、プラットフォームが扱う機能の複雑さ・範囲・影響力・巨大な規模とトラフィックが掛け合わさった結果だ。
      エンジニアリング文化は顧客の下位互換性を非常に重視しており、それには十分な理由があるが、プラットフォームと意思決定全体に良い面でも悪い面でも染み込んでいる。
      そのため、内部的に大きく改善できる明確なプラットフォーム転換には投資されにくいか、コストが高すぎると判断される。
      それでもなお働きやすい場所ではあるし、自分の仕事が数十億人の仕事生活に少しでも直接貢献していることは誇りに思うが、社内外の顧客双方のプラットフォーム利用体験を改善するにはまだ道のりが長い
    • クリックしたが、「独自の AI エージェントを持つメールアプリ」という文句を見て閉じた。また 1 つの AI の無理やりな押し込み に見えた。
      Outlook もすでにこういうものを提供しているが、ひどい出来だ。文脈が重要なのに、その文脈はいろいろな場所に埋もれていて、アクセス権があってもまともに扱えない
    • ある時点で品質管理を諦めたように見える。理由は分からないが、Microsoft はもう何年も前から下り坂だった。
      AI のガラクタが増え、Microsoft が「microslop」のようになったことで、その流れがさらに増幅しただけだ

  • Microsoft は昔から性能に無頓着だった。逸話が 2 つある。
    昔 Microsoft で働いていた友人に、ある Microsoft 製スイートがあまりに遅いと不満を言ったところ、無造作に「Intel の株を買え。みんな PC をアップグレードすることになる」と答えた。
    もう 1 つは、15 年ほど前に地域の集まりで Yahoo で働いていた長年の友人と交わした会話だ。Yahoo と Microsoft の検索契約が実際にはどう動いていたかを説明してくれたが、Microsoft のエンジニアに問題を提起しても反応がなかったという。
    欧州のユーザーが search.yahoo.de で検索すると、リクエストは EU データセンターの Yahoo サーバーに送られ、契約上そのリクエストは Virginia の Microsoft サーバーへ転送される。ところが EU からのリクエストなので、その Microsoft サーバーがさらに EU の Microsoft サーバーへ要求を送り、結果は EU の Microsoft サーバーから Virginia の Microsoft サーバーへ、そこから再び EU の Yahoo サーバーへ戻る。
    結局、検索リクエスト 1 件につき 大西洋を 4 回往復 することになり、遅延は約 1500ms だったという。Yahoo の社内目標は 300ms 未満だったのに、この遅延急増を Microsoft 側に伝えても、ただ肩をすくめるだけだったという話だ

    • 検索を Virginia に送ったのは 監視目的 だった。その点ははっきり認識しておくべきだ

  • Mac 向け「Legacy Outlook」の最新バージョンに大きなバグが入った。「legacy Outlook for Mac でメールに返信または転送すると、元のメッセージが本文に含まれない」というバグだ。
    https://support.microsoft.com/en-us/topic/replying-to-or-for...
    そのせいで結局 New Outlook というゴミを使うよう強いられたが、実際ゴミだ。犬のように遅く、あらゆる操作に 1 秒ずつかかる。
    どうしてボタンを全部並べ替え、フォントまで変えるのか分からない。昔のインターフェースをそのまま 1:1 でコピーすればいいだけではないのか。
    この新バージョンを 2 週間以上使わなければならないなら、別のクライアントに乗り換えるつもりだ。もしかすると、人々を移行させるためにわざとこんな致命的なバグを入れているのかもしれない

    • 本当に信じられないほど腹立たしい。「サポート」で提案されている解決策が「このバグを入れる前のバージョンにダウングレードできます」のように見えると、なおさらだ。
      新しいゴミに乗り換える気はまったくなく、もう メールクライアント 自体を丸ごと変えるつもりだ

  • 電卓が開くのに体感できる秒単位の時間がかかるようになったのが、Windows 10での最後の限界だった。
    家ではもう何年も Linuxだけ を使っていて、その選択が正しかったことを思い出させてくれる記事タイトルが比較的コンスタントに出ている

    • 2019年から家ではLinuxだけを使っている。ただ、仕事はWindowsでやらなければならず、Windowsがひどく、アップデートのたびにさらに悪くなっていることを毎日思い知らされる。
      WSLだけがどうにか耐えられる状態にしてくれている。家のPCの前に座れるときは、長く楽に息をつけるような気分になる
    • 幸い、今でもクラシック電卓に戻せる: https://win7games.com/#calc
    • ありがたいことにその問題は改善したが、電卓のインスタンスが理由もなく複数立ち上がる奇妙なバグはまだ残っている
    • 2023年ごろに移行したが、Windowsを離れる決断を疑わせる記事タイトルや逸話やコメントや兆候は一つも見ていない。
      Linuxで理由もなく何かが動かない最悪の日でさえ、Windowsよりましだ

  • 毎朝、業務メールを確認するためにOutlookを起動している。開くときもあれば、何も表示されず、画面上にも読み込みダイアログがなく、まるで起動していないかのようなまま 5分後 に開くこともある。
    WindowsとMacの両方で起きる。
    UIをレンダリングする前にアップデート確認をしているようで、アップデートがあると、UIを見せる前にダウンロードと適用を終わらせなければならないようだ。アプリを開こうとしているユーザーの立場では、壊れて読み込みできていないように見える。
    メールにアクセスしたいのにアプリが開かず、先にアップデートすると決められてしまうと5分待たされるので、ものすごくつらい。拒否する選択肢を出すか、バックグラウンドで透過的に処理して、準備ができたら再起動するか尋ねる方式であるべきだ。
    Officeでファイルを保存しようとしても同じようにもどかしい。ローカル保存ではなく OneDrive に保存させようとするダークなユーザー体験が入り込んでいる

  • Microsoftには非常に高速に動くネイティブアプリを作れる人材が十分いるのに、いまだにWeb移植性の論理に引っ張られている。周知のとおり、その主張は今でも概して事実ではなく、きれいに扱いにくい 非決定的な遅延とエラー をあらゆる形で持ち込む。
    正直なところ、開発者が10人を超えて関わるほぼすべてのアプリで似たようなものだ。依存関係の増大と一貫した設計の欠如が、じわじわと殺していく構造になっている。
    それでも、他の人が言っていたようにFastmailのようにブラウザでまともに動くものもあるので、不可能ではない

    • ネイティブソフトウェアをうまく作るのは非常に難しい。
      サポートしなければならないプラットフォームだけでも最低でWindows、Mac、iPhone、Androidの4つある。フロントエンドだけでも最低 異なるエンジニア4人 が必要だ。
      さらに複数のバックエンドエンジニアが必要で、共有できることもあるが、常にそうとは限らない。Androidの独特なランタイム要件は十分に特殊なので、データベースがC++で書かれているからといって、Windowsバックエンドと同じC++データベースという意味にはならない。
      最後に、デザイナーは各ネイティブプラットフォーム固有の要素を共通のデザイン言語に統合し、すべてのプラットフォームで同じビジョンを持たせようとする。するとエンジニアは4つのプラットフォームで同じように動くUIを作ることになり、結局は事実上カスタムの「ブラウザ」を作っているようなものになる
    • ネイティブアプリを作っても台無しにするだろう
    • 問題はプラットフォームではない。有能なエンジニアリングチームなら、シングルスレッドのjQuery Webアプリ であっても、これよりはるかにましなものを作れる