コマンドプロンプトが本気を出す──Windows Terminalの機能がOS標準に統合へ
あのレガシーな黒い画面が、静かに進化しようとしている。スクロール速度10倍、画像表示、正規表現検索。しかも、オープンソースコミュニティの手で。
あのレガシーな黒い画面が、静かに進化しようとしている。スクロール速度10倍、画像表示、正規表現検索。しかも、オープンソースコミュニティの手で。
コンソールホストに降りてきたTerminalの恩恵
Windows 11のCanaryチャネル向けビルド29558.1000で、Microsoftがコマンドプロンプトの基盤となる「コンソールホスト」(conhost.exe)に大規模なアップデートを投入した。Windows Terminalで先行していた機能群が、OS標準のコマンドライン環境にまとめて還元される。
ここで重要なのは、タブ機能やカスタムテーマといったTerminal固有のUI機能が来るわけではないという点だ。変わるのはもっと深いレイヤー、つまりテキストの描画エンジンやクリップボード処理、アクセシビリティといったコンソールの「エンジン部分」そのものだ。
Microsoftは公式ブログで「Windows ConsoleはオープンソースのWindows Terminalプロジェクトの一部であり、今回のリリースでオープンソースプロジェクトの変更をすべてWindowsに還元する」と述べている。
地味に聞こえるかもしれない。だが、この変更が効いてくる場面は意外と広い。Terminalがインストールされていない環境、たとえば回復環境やセットアップ直後のPC、あるいは企業の管理用スクリプトが直接叩くレガシーなコンソール層。そうした「古いけど現役」の場所に、モダンな改善が届くことになる。
スクロール速度10倍と画像表示──具体的に何が変わるのか
変更点は十数項目に及ぶが、ユーザーの体感に直結するものをいくつか挙げたい。
| 項目 | 従来 | ビルド29558〜 |
|---|---|---|
| 画像表示 | 非対応 | Sixel対応 |
| 描画エンジン | GDIのみ | Direct3D選択可 |
| 検索 | 基本検索のみ | 正規表現対応 |
| 太字フォント | 非対応 | 対応 |
| スクロール | 標準速度 | 最大10倍高速化 |
| クリップボード | 基本操作のみ | OSC 52対応 |
| ペースト | 文字欠落あり | 修正済み |
| アクセシビリティ | レガシーMSAA | UIA書き直し |
出典:Windows Insider Blog(2026年3月30日)。ビルド29558.1000はCanaryチャネル限定。Direct3DパスはレジストリキーUseDx=1で有効化。
まずスクロール性能の改善。一部のシナリオで最大10倍の高速化が実現するという。巨大なログファイルを追いかけるとき、あの「引っかかる」感覚が大幅に軽減される可能性がある。開発者やシステム管理者にとっては、地味だが毎日効く改善だ。
次に、Sixelベースの画像表示への対応。コンソール上でインライン画像を表示できるようになり、たとえばWinGetがアプリケーションアイコンを表示するといった使い方が可能になる。テキストだけの世界だったコマンドラインに、視覚情報が入り込む。
検索機能も強化された。Find(検索)ダイアログが正規表現に対応し、複雑なパターンマッチングがコンソール内で完結する。エラーコードの抽出や特定文字列のフィルタリングが、外部ツールなしでできるようになるわけだ。
オプションのDirect3D描画パス(レジストリキーで有効化)、太字フォントのレンダリング、クリップボードのOSC 52対応、ペースト時の文字化け修正、アクセシビリティの書き直しなど、変更は広範囲にわたる。
見落とせないアクセシビリティの刷新
派手さはないが、レガシーMSAAの統合とUI Automationの一部が書き直された点は注目に値する。スクリーンリーダーや支援技術との互換性が向上し、F7の履歴ウィンドウやF2/F4の行編集ウィンドウのポップアップ表示も改善された。
コマンドラインの「使いやすさ」は、見える人だけの話ではない。アクセシビリティの書き直しという地味な作業にリソースを割いたこと自体が、このプロジェクトの本気度を示している。
オープンソースが変えたWindowsの作り方
今回のアップデートで見逃せないのは、その出自だ。Microsoftは変更の多くが「Windows Insiderとコミュニティのコントリビューター」によるものだと明言している。GitHubのプルリクエスト番号が逐一記載されているのは、単なる透明性アピールではなく、実際にコミュニティが書いたコードがWindowsのコア部品に取り込まれた証拠だ。
かつてのMicrosoftなら考えにくかった光景だ。Windows Terminalプロジェクトが2019年にオープンソースとして公開されて以来、コンソール周りの開発はGitHubを中心に回ってきた。その成果が「上流」から「本体」へ流れ込む構図は、Linuxカーネルのような開発モデルに一歩近づいたとも言える。
変更の詳細とコントリビューター名は、Windows Command Line Blogに掲載されている。
もちろん、Canaryチャネル限定という点は忘れてはならない。Canaryは最も実験的なInsiderチャネルであり、安定性の保証はない。正式リリースまでには数カ月を要するだろうし、機能が途中で変更・削除される可能性もある。期待しつつも、本番環境への導入は時期尚早だ。
「古い基盤」を捨てずに進化させる戦略
Microsoftには、古いConsole Hostを放棄してWindows Terminalに一本化するという選択肢もあったはずだ。実際、2022年にはWindows Terminalがデフォルトのコマンドラインツールに昇格している。
だが現実には、膨大な企業の自動化スクリプトやデプロイツール、リモート管理の仕組みが今もconhost.exeに依存している。それを無視して「Terminal使ってください」とは言えない。だから、Terminalで培った技術をConsole Hostに逆流させるという判断になった。

この「両方を育てる」アプローチは、エレガントとも面倒とも言える。だが、互換性を壊さずにモダナイズするという意味では、おそらく正しい選択だ。
コマンドプロンプトは何十年もの間、Windowsの「変わらない場所」だった。その場所が変わり始めたことの意味は、数カ月後にはもう少しはっきり見えてくるだろう。
参照元
